# mulesoft Mule Runtime - Full Documentation # AMQP Connector への移行 他のコネクタと同様、AMQP Connector も一新され、Mule 3 トランスポートモデルから、簡便な UX や DataSense に完全対応するメッセージ情報を特長とする操作ベースのコネクタに進化しています。 つまり、AMQP を使用すると、他のコネクタと同じように接続や設定を行えるだけでなく、メッセージのパブリッシュやコンシュームも構造されたメッセージ情報に基づくため簡便になります。 ## [](#ConfiguringTheConnector)コネクタの設定 3.x のトランスポート設定から Mule 4 の AMQP Connector 設定に移行するということは、基本的にはほぼ同じパラメーターを使用しながら、より一貫性のある方法で宣言することになります。Mule 4 では AMQP Connector の一定のパラメーターが変更されています。 たとえば、メッセージのコンシュームに使用するパラメーターは 'consumer-config' グループで宣言されますが、一般的な認証パラメーターは一般グループで設定されます。また、コネクタの動作に影響するパラメーター (config に存在) が、接続の確立方法にのみ影響するパラメーター (接続レベルで存在) と区別されています。 Mule 3 の例: コネクタの設定 ```xml ``` Mule 4 でも、実際に適用するコンテキストに同じパラメーターを設定すれば、これと同じ設定にすることができます。 Mule 4 の例: コネクタの設定 ```xml ``` `fallbackAddresses`​ はサポートされなくなりました。 ## [](#SendingMessages)メッセージの送信 Mule 4 の新しいアプローチでは、AMQP の 'publish' 操作に入力パラメーターのみを利用して、パブリッシュする AMQP メッセージのビルドを完成させます。 たとえば、本文にペイロードの一部のみが記載された、優先度の高い AMQP メッセージを送信し、このメッセージをグループに関連付ける場合、次の手順を実行する必要があります。 <1>) ​`transform`​ を使用して、メッセージ本文となるものをペイロードに設定します。 <2>) 生成されたストリームを文字列に変換して、テキストメッセージとして送信します。 <3>) AMQP プロパティに ​`priority`​ を、AMQP メッセージの優先度を設定するキーとして設定します。 Mule 3 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (1) (2) (3) ``` Mule 4 でも、AMQP Connector を次のとおり設定すれば、同じ結果を得ることができます。 Mule 4 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (2) (1) #[output application/json --- { order_id: payload.id, supplier: payload.warehouse }] (3) ``` 次の違いに注意します。 1) メッセージの ​`body`​ はインラインで作成され、ペイロードには変更がないため、​`transform`​ コンポーネントは必要ありません。 2) コネクタが変換出力を自動的に処理できるため、​`object-to-string`​ トランスフォーマーも排除されています。 3) 優先度は AmqpMessage 操作のプロパティとして設定され、ユーザーが正確なキーを把握している必要はありません。 上記をまとめると、3.x で AMQP トランスポートを使用してメッセージをパブリッシュするときは、AmqpMessage ペイロードとアウトバウンドプロパティを利用して AMQP メッセージの作成を設定するため、トランスポートがどのように機能するのかの詳しい知識が必要でした。4.x では AMQP Connector が、設定可能な各要素をその要素が属するスコープのパラメーターとして公開するため、AMQP のすべての機能がより明確な形で公開されます。 ## [](#ListeningForNewMessages)新規メッセージのリスン AMQP トランスポートの ​`inbound-endpoint`​ では、指定したキューの新しい AMQP メッセージを待機できます。このリスナーの出力では、ペイロードにメッセージの本文、​`AMQP Attributes`​ に AMQP のすべてのヘッダーとプロパティが記載されます。 Mule 3 の例: メッセージのリスン ```xml (2) (3) (4) ``` この場合は、メッセージをリスンして、新たに定められた形式に適合させます。 1) inboundProperties に含まれているメタデータを使用して MuleMessage を変換し、新たな API で求められる新しい JSON 形式にペイロードを適合させます。 2) 変換されたペイロードを JSON 文字列に変換します。 3) ペイロードを定義済みのエクスチェンジにパブリッシュします。 Mule 4 に同じコードを実装すると次のようになります。 Mule 4 の例: メッセージのリスン ```xml (1) (2) #[output application/json --- { items: payload, costumer: attributes.properties.userProperties.costumer_id, (3) type: attributes.headers.type }] ``` この場合、フローのコンポーネント数が減り、メッセージペイロードを異なる形式でパブリッシュするために変更する必要がありません。
1新しいメッセージの定義はインラインで行われるため、新しいメッセージ本文の JSON のみが作成されます。
2ここではメッセージの 'inboundProperties' ではなく、'attributes’ POJO を使用しています。このため、AMQP メッセージの 'headers' が 'properties' と区別されます。
## [](#ConsumingMessages)メッセージのコンシューム Mule 3 の AMQP トランスポートでは、特定の宛先からのメッセージをフローの途中でコンシュームすることがサポートされていなかったため、この対処法として「Mule Requester Module」をアプリケーションに追加し、このモジュールがフローの途中のメッセージのコンシュームを処理していました。 たとえば、AMQP キューを公開する場合、アプリケーションは次のようになりました。 Mule 3 の例: フローの途中のメッセージのコンシューム ```xml ``` 留意点: - AMQP メッセージに関するすべてのメタデータは完全に失われるため、CorrelationId をログに記録するためには、ヘッダーを取得する構文を把握している必要があります。 - この要求には AMQP とキューの設定の両方が必要です。 Mule 4 には、'consume' 操作を使用して、フローの途中のメッセージをコンシュームする機能が標準装備されています。この操作は前述のリスナーとよく似ていますが、相違点はフローのどの時点でも使用できることです。 Mule 4 の例: フローの途中のメッセージのコンシューム ```xml ``` ## [](#要求-応答の実行)要求-応答の実行 AMQP では ​`reply_to`​ プロパティを使用して、RPC パターンを実装できます。この場合は、クライアントがその場で作成した一時的な専用応答キューを使用するか、既存のキューを使用します。 ### [](#一時的な自動削除非公開応答キューを使用した要求-応答)一時的な自動削除非公開応答キューを使用した要求-応答 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`​ 要素の操作のインラインで実行され、送信メッセージに影響する変換や設定はすべてこの要素の一部として行われます。 ### [](#明示的な応答先キューを使用した要求-応答)明示的な応答先キューを使用した要求-応答 Mule 4 では、replyTo プロパティを指定した明示的な ​`reply-to`​ キューを使用して、要求応答を実行できます。 Mule 4 の例: 明示的な応答先を使用した要求-応答の実行 ```xml #[output application/xml --- { data: payload, costumer: attributes.queryParams.costumer_id }] ``` ## [](#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 にパブリッシュします。
## [](#EnforcingExistenceQueueExchanges)キューやエクスチェンジの存在の強制 Mule 3 では、​`activeDeclarationsOnly`​ を false に設定している場合に、宣言されたキューまたはエクスチェンジが存在しなければ、AMQP Connector が 404 エラーを記載した ​`ShutdownSignalException`​ をスローします。Mule 4 では、​`createFallbackQueue`​ と ​`createFallbackExchange`​ パラメーターを使用して、キューやエクスチェンジを強制的に存在させることができます。 ```xml ``` # AMQP Connector への移行 他のコネクタと同様、AMQP Connector も一新され、Mule 3 トランスポートモデルから、簡便な UX や DataSense に完全対応するメッセージ情報を特長とする操作ベースのコネクタに進化しています。 つまり、AMQP を使用すると、他のコネクタと同じように接続や設定を行えるだけでなく、メッセージのパブリッシュやコンシュームも構造されたメッセージ情報に基づくため簡便になります。 ## [](#ConfiguringTheConnector)コネクタの設定 3.x のトランスポート設定から Mule 4 の AMQP Connector 設定に移行するということは、基本的にはほぼ同じパラメーターを使用しながら、より一貫性のある方法で宣言することになります。Mule 4 では AMQP Connector の一定のパラメーターが変更されています。 たとえば、メッセージのコンシュームに使用するパラメーターは 'consumer-config' グループで宣言されますが、一般的な認証パラメーターは一般グループで設定されます。また、コネクタの動作に影響するパラメーター (config に存在) が、接続の確立方法にのみ影響するパラメーター (接続レベルで存在) と区別されています。 Mule 3 の例: Connector の設定 ```xml ``` Mule 4 でも、実際に適用するコンテキストに同じパラメーターを設定すれば、これと同じ設定にすることができます。 Mule 4 の例: Connector の設定 ```xml ``` `fallbackAddresses`​ はサポートされなくなりました。 ## [](#SendingMessages)メッセージの送信 Mule 4 の新しいアプローチでは、AMQP の 'publish' 操作に入力パラメーターのみを利用して、パブリッシュする AMQP メッセージのビルドを完成させます。 たとえば、本文にペイロードの一部のみが記載された、優先度の高い AMQP メッセージを送信し、このメッセージをグループに関連付ける場合、次の手順を実行する必要があります。 <1>) ​`transform`​ を使用して、メッセージ本文となるものをペイロードに設定します。 <2>) 生成されたストリームを文字列に変換して、テキストメッセージとして送信します。 <3>) AMQP プロパティに ​`priority`​ を、AMQP メッセージの優先度を設定するキーとして設定します。 Mule 3 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (1) (2) (3) ``` Mule 4 でも、AMQP Connector を次のとおり設定すれば、同じ結果を得ることができます。 Mule 4 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (2) (1) #[output application/json --- { order_id: payload.id, supplier: payload.warehouse }] (3) ``` 次の違いに注意します。 1) メッセージの ​`body`​ はインラインで作成され、ペイロードには変更がないため、​`transform`​ コンポーネントは必要ありません。 2) Connector が変換出力を自動的に処理できるため、​`object-to-string`​ トランスフォーマーも排除されています。 3) 優先度は AmqpMessage 操作のプロパティとして設定され、ユーザーが正確なキーを把握している必要はありません。 上記をまとめると、3.x で AMQP トランスポートを使用してメッセージをパブリッシュするときは、AmqpMessage ペイロードとアウトバウンドプロパティを利用して AMQP メッセージの作成を設定するため、トランスポートがどのように機能するのかの詳しい知識が必要でした。4.x では AMQP Connector が、設定可能な各要素をその要素が属するスコープのパラメーターとして公開するため、AMQP のすべての機能がより明確な形で公開されます。 ## [](#ListeningForNewMessages)新規メッセージのリスン AMQP トランスポートの ​`inbound-endpoint`​ では、指定したキューの新しい AMQP メッセージを待機できます。このリスナーの出力では、ペイロードにメッセージの本文、​`AMQP Attributes`​ に AMQP のすべてのヘッダーとプロパティが記載されます。 Mule 3 の例: メッセージのリスン ```xml (2) (3) (4) ``` この場合は、メッセージをリスンして、新たに定められた形式に適合させます。 1) inboundProperties に含まれているメタデータを使用して MuleMessage を変換し、新たな API で求められる新しい JSON 形式にペイロードを適合させます。 2) 変換されたペイロードを JSON 文字列に変換します。 3) ペイロードを定義済みのエクスチェンジにパブリッシュします。 Mule 4 に同じコードを実装すると次のようになります。 Mule 4 の例: メッセージのリスン ```xml (1) (2) #[output application/json --- { items: payload, costumer: attributes.properties.userProperties.costumer_id, (3) type: attributes.headers.type }] ``` この場合、フローのコンポーネント数が減り、メッセージペイロードを異なる形式でパブリッシュするために変更する必要がありません。
1新しいメッセージの定義はインラインで行われるため、新しいメッセージ本文の JSON のみが作成されます。
2ここではメッセージの 'inboundProperties' ではなく、'attributes’ POJO を使用しています。このため、AMQP メッセージの 'headers' が 'properties' と区別されます。
## [](#ConsumingMessages)メッセージのコンシューム Mule 3 の AMQP トランスポートでは、特定の宛先からのメッセージをフローの途中でコンシュームすることがサポートされていなかったため、この対処法として「Mule Requester Module」をアプリケーションに追加し、このモジュールがフローの途中のメッセージのコンシュームを処理していました。 たとえば、AMQP キューを公開する場合、アプリケーションは次のようになりました。 Mule 3 の例: フローの途中のメッセージのコンシューム ```xml ``` 留意点: - AMQP メッセージに関するすべてのメタデータは完全に失われるため、CorrelationId をログに記録するためには、ヘッダーを取得する構文を把握している必要があります。 - この要求には AMQP とキューの設定の両方が必要です。 Mule 4 には、'consume' 操作を使用して、フローの途中のメッセージをコンシュームする機能が標準装備されています。この操作は前述のリスナーとよく似ていますが、相違点はフローのどの時点でも使用できることです。 Mule 4 の例: フローの途中のメッセージのコンシューム ```xml ``` ## [](#要求-応答の実行)要求-応答の実行 AMQP では ​`reply_to`​ プロパティを使用して、RPC パターンを実装できます。この場合は、クライアントがその場で作成した一時的な専用応答キューを使用するか、既存のキューを使用します。 ### [](#一時的な自動削除非公開応答キューを使用した要求-応答)一時的な自動削除非公開応答キューを使用した要求-応答 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`​ 要素の操作のインラインで実行され、送信メッセージに影響する変換や設定はすべてこの要素の一部として行われます。 ### [](#明示的な応答先キューを使用した要求-応答)明示的な応答先キューを使用した要求-応答 Mule 4 では、replyTo プロパティを指定した明示的な ​`reply-to`​ キューを使用して、要求応答を実行できます。 Mule 4 の例: 明示的な応答先を使用した要求-応答の実行 ```xml #[output application/xml --- { data: payload, costumer: attributes.queryParams.costumer_id }] ``` ## [](#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 にパブリッシュします。
## [](#EnforcingExistenceQueueExchanges)キューやエクスチェンジの存在の強制 Mule 3 では、​`activeDeclarationsOnly`​ を false に設定している場合に、宣言されたキューまたはエクスチェンジが存在しなければ、AMQP Connector が 404 エラーを記載した ​`ShutdownSignalException`​ をスローします。Mule 4 では、​`createFallbackQueue`​ と ​`createFallbackExchange`​ パラメーターを使用して、キューやエクスチェンジを強制的に存在させることができます。 ```xml ``` # AMQP Connector への移行 他のコネクタと同様、AMQP Connector も一新され、Mule 3 トランスポートモデルから、簡便な UX や DataSense に完全対応するメッセージ情報を特長とする操作ベースのコネクタに進化しています。 つまり、AMQP を使用すると、他のコネクタと同じように接続や設定を行えるだけでなく、メッセージのパブリッシュやコンシュームも構造されたメッセージ情報に基づくため簡便になります。 ## [](#ConfiguringTheConnector)コネクタの設定 3.x のトランスポート設定から Mule 4 の AMQP Connector 設定に移行するということは、基本的にはほぼ同じパラメーターを使用しながら、より一貫性のある方法で宣言することになります。Mule 4 では AMQP Connector の一定のパラメーターが変更されています。 たとえば、メッセージのコンシュームに使用するパラメーターは 'consumer-config' グループで宣言されますが、一般的な認証パラメーターは一般グループで設定されます。また、コネクタの動作に影響するパラメーター (config に存在) が、接続の確立方法にのみ影響するパラメーター (接続レベルで存在) と区別されています。 Mule 3 の例: コネクタの設定 ```xml ``` Mule 4 でも、実際に適用するコンテキストに同じパラメーターを設定すれば、これと同じ設定にすることができます。 Mule 4 の例: コネクタの設定 ```xml ``` `fallbackAddresses`​ はサポートされなくなりました。 ## [](#SendingMessages)メッセージの送信 Mule 4 の新しいアプローチでは、AMQP の 'publish' 操作に入力パラメーターのみを利用して、パブリッシュする AMQP メッセージのビルドを完成させます。 たとえば、本文にペイロードの一部のみが記載された、優先度の高い AMQP メッセージを送信し、このメッセージをグループに関連付ける場合、次の手順を実行する必要があります。 <1>) ​`transform`​ を使用して、メッセージ本文となるものをペイロードに設定します。 <2>) 生成されたストリームを文字列に変換して、テキストメッセージとして送信します。 <3>) AMQP プロパティに ​`priority`​ を、AMQP メッセージの優先度を設定するキーとして設定します。 Mule 3 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (1) (2) (3) ``` Mule 4 でも、AMQP Connector を次のとおり設定すれば、同じ結果を得ることができます。 Mule 4 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (2) (1) #[output application/json --- { order_id: payload.id, supplier: payload.warehouse }] (3) ``` 次の違いに注意します。 1) メッセージの ​`body`​ はインラインで作成され、ペイロードには変更がないため、​`transform`​ コンポーネントは必要ありません。 2) コネクタが変換出力を自動的に処理できるため、​`object-to-string`​ トランスフォーマーも排除されています。 3) 優先度は AmqpMessage 操作のプロパティとして設定され、ユーザーが正確なキーを把握している必要はありません。 上記をまとめると、3.x で AMQP トランスポートを使用してメッセージをパブリッシュするときは、AmqpMessage ペイロードとアウトバウンドプロパティを利用して AMQP メッセージの作成を設定するため、トランスポートがどのように機能するのかの詳しい知識が必要でした。4.x では AMQP Connector が、設定可能な各要素をその要素が属するスコープのパラメーターとして公開するため、AMQP のすべての機能がより明確な形で公開されます。 ## [](#ListeningForNewMessages)新規メッセージのリスン AMQP トランスポートの ​`inbound-endpoint`​ では、指定したキューの新しい AMQP メッセージを待機できます。このリスナーの出力では、ペイロードにメッセージの本文、​`AMQP Attributes`​ に AMQP のすべてのヘッダーとプロパティが記載されます。 Mule 3 の例: メッセージのリスン ```xml (2) (3) (4) ``` この場合は、メッセージをリスンして、新たに定められた形式に適合させます。 1) inboundProperties に含まれているメタデータを使用して MuleMessage を変換し、新たな API で求められる新しい JSON 形式にペイロードを適合させます。 2) 変換されたペイロードを JSON 文字列に変換します。 3) ペイロードを定義済みのエクスチェンジにパブリッシュします。 Mule 4 に同じコードを実装すると次のようになります。 Mule 4 の例: メッセージのリスン ```xml (1) (2) #[output application/json --- { items: payload, costumer: attributes.properties.userProperties.costumer_id, (3) type: attributes.headers.type }] ``` この場合、フローのコンポーネント数が減り、メッセージペイロードを異なる形式でパブリッシュするために変更する必要がありません。
1新しいメッセージの定義はインラインで行われるため、新しいメッセージ本文の JSON のみが作成されます。
2ここではメッセージの 'inboundProperties' ではなく、'attributes’ POJO を使用しています。このため、AMQP メッセージの 'headers' が 'properties' と区別されます。
## [](#ConsumingMessages)メッセージのコンシューム Mule 3 の AMQP トランスポートでは、特定の宛先からのメッセージをフローの途中でコンシュームすることがサポートされていなかったため、この対処法として「Mule Requester Module」をアプリケーションに追加し、このモジュールがフローの途中のメッセージのコンシュームを処理していました。 たとえば、AMQP キューを公開する場合、アプリケーションは次のようになりました。 Mule 3 の例: フローの途中のメッセージのコンシューム ```xml ``` 留意点: - AMQP メッセージに関するすべてのメタデータは完全に失われるため、CorrelationId をログに記録するためには、ヘッダーを取得する構文を把握している必要があります。 - この要求には AMQP とキューの設定の両方が必要です。 Mule 4 には、'consume' 操作を使用して、フローの途中のメッセージをコンシュームする機能が標準装備されています。この操作は前述のリスナーとよく似ていますが、相違点はフローのどの時点でも使用できることです。 Mule 4 の例: フローの途中のメッセージのコンシューム ```xml ``` ## [](#要求-応答の実行)要求-応答の実行 AMQP では ​`reply_to`​ プロパティを使用して、RPC パターンを実装できます。この場合は、クライアントがその場で作成した一時的な専用応答キューを使用するか、既存のキューを使用します。 ### [](#一時的な自動削除非公開応答キューを使用した要求-応答)一時的な自動削除非公開応答キューを使用した要求-応答 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`​ 要素の操作のインラインで実行され、送信メッセージに影響する変換や設定はすべてこの要素の一部として行われます。 ### [](#明示的な応答先キューを使用した要求-応答)明示的な応答先キューを使用した要求-応答 Mule 4 では、replyTo プロパティを指定した明示的な ​`reply-to`​ キューを使用して、要求応答を実行できます。 Mule 4 の例: 明示的な応答先を使用した要求-応答の実行 ```xml #[output application/xml --- { data: payload, costumer: attributes.queryParams.costumer_id }] ``` ## [](#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 にパブリッシュします。
## [](#EnforcingExistenceQueueExchanges)キューやエクスチェンジの存在の強制 Mule 3 では、​`activeDeclarationsOnly`​ を false に設定している場合に、宣言されたキューまたはエクスチェンジが存在しなければ、AMQP Connector が 404 エラーを記載した ​`ShutdownSignalException`​ をスローします。Mule 4 では、​`createFallbackQueue`​ と ​`createFallbackExchange`​ パラメーターを使用して、キューやエクスチェンジを強制的に存在させることができます。 ```xml ``` # AMQP Connector への移行 他のコネクタと同様、AMQP Connector も一新され、Mule 3 トランスポートモデルから、簡便な UX や DataSense に完全対応するメッセージ情報を特長とする操作ベースのコネクタに進化しています。 つまり、AMQP を使用すると、他のコネクタと同じように接続や設定を行えるだけでなく、メッセージのパブリッシュやコンシュームも構造されたメッセージ情報に基づくため簡便になります。 ## [](#ConfiguringTheConnector)コネクタの設定 3.x のトランスポート設定から Mule 4 の AMQP Connector 設定に移行するということは、基本的にはほぼ同じパラメーターを使用しながら、より一貫性のある方法で宣言することになります。Mule 4 では AMQP Connector の一定のパラメーターが変更されています。 たとえば、メッセージのコンシュームに使用するパラメーターは「consumer-config」グループで宣言されますが、一般的な認証パラメーターは一般グループで設定されます。また、コネクタの動作に影響するパラメーター (config に存在) が、接続の確立方法にのみ影響するパラメーター (接続レベルで存在) と区別されています。 Mule 3 の例: コネクタの設定 ```xml ``` Mule 4 でも、実際に適用するコンテキストに同じパラメーターを設定すれば、これと同じ設定にすることができます。 Mule 4 の例: コネクタの設定 ```xml ``` `fallbackAddresses`​ はサポートされなくなりました。 ## [](#SendingMessages)メッセージの送信 Mule 4 の新しいアプローチでは、AMQP の「publish」操作に入力パラメーターのみを利用して、パブリッシュする AMQP メッセージのビルドを完成させます。 たとえば、本文にペイロードの一部のみが記載された、優先度の高い AMQP メッセージを送信し、このメッセージをグループに関連付ける場合、次の手順を実行する必要があります。 <1>) ​`transform`​ を使用して、メッセージ本文となるものをペイロードに設定します。 <2>) 生成されたストリームを文字列に変換して、テキストメッセージとして送信します。 <3>) AMQP プロパティに ​`priority`​ を、AMQP メッセージの優先度を設定するキーとして設定します。 Mule 3 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (1) (2) (3) ``` Mule 4 でも、AMQP Connector を次のとおり設定すれば、同じ結果を得ることができます。 Mule 4 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (2) (1) #[output application/json --- { order_id: payload.id, supplier: payload.warehouse }] (3) ``` 次の違いに注意します。 1) メッセージの ​`body`​ はインラインで作成され、ペイロードには変更がないため、​`transform`​ コンポーネントは必要ありません。 2) Connector が変換出力を自動的に処理できるため、​`object-to-string`​ トランスフォーマーも排除されています。 3) 優先度は AmqpMessage 操作のプロパティとして設定され、ユーザーが正確なキーを把握している必要はありません。 上記をまとめると、3.x で AMQP トランスポートを使用してメッセージをパブリッシュするときは、AmqpMessage ペイロードとアウトバウンドプロパティを利用して AMQP メッセージの作成を設定するため、トランスポートがどのように機能するのかの詳しい知識が必要でした。4.x では AMQP Connector が、設定可能な各要素をその要素が属するスコープのパラメーターとして公開するため、AMQP のすべての機能がより明確な形で公開されます。 ## [](#ListeningForNewMessages)新規メッセージのリスン AMQP トランスポートの ​`inbound-endpoint`​ では、指定したキューの新しい AMQP メッセージを待機できます。このリスナーの出力では、ペイロードにメッセージの本文、​`AMQP Attributes`​ に AMQP のすべてのヘッダーとプロパティが記載されます。 Mule 3 の例: メッセージのリスン ```xml (2) (3) (4) ``` この場合は、メッセージをリスンして、新たに定められた形式に適合させます。 1) inboundProperties に含まれているメタデータを使用して MuleMessage を変換し、新たな API で求められる新しい JSON 形式にペイロードを適合させます。 2) 変換されたペイロードを JSON 文字列に変換します。 3) ペイロードを定義済みのエクスチェンジにパブリッシュします。 Mule 4 に同じコードを実装すると次のようになります。 Mule 4 の例: メッセージのリスン ```xml (1) (2) #[output application/json --- { items: payload, costumer: attributes.properties.userProperties.costumer_id, (3) type: attributes.headers.type }] ``` この場合、フローのコンポーネント数が減り、メッセージペイロードを異なる形式でパブリッシュするために変更する必要がありません。
1新しいメッセージの定義はインラインで行われるため、新しいメッセージ本文の JSON のみが作成されます。
2ここではメッセージの「inboundProperties」ではなく、「attributes」 POJO を使用しています。このため、AMQP メッセージの「headers」が「properties」と区別されます。
## [](#ConsumingMessages)メッセージのコンシューム Mule 3 の AMQP トランスポートでは、特定の宛先からのメッセージをフローの途中でコンシュームすることがサポートされていなかったため、この対処法として「Mule Requester Module」をアプリケーションに追加し、このモジュールがフローの途中のメッセージのコンシュームを処理していました。 たとえば、AMQP キューを公開する場合、アプリケーションは次のようになりました。 Mule 3 の例: フローの途中のメッセージのコンシューム ```xml ``` 留意点: - AMQP メッセージに関するすべてのメタデータは完全に失われるため、CorrelationId をログに記録するためには、ヘッダーを取得する構文を把握している必要があります。 - この要求には AMQP とキューの設定の両方が必要です。 Mule 4 には、「consume」操作を使用して、フローの途中のメッセージをコンシュームする機能が標準装備されています。この操作は前述のリスナーとよく似ていますが、相違点はフローのどの時点でも使用できることです。 Mule 4 の例: フローの途中のメッセージのコンシューム ```xml ``` ## [](#要求-応答の実行)要求-応答の実行 AMQP では ​`reply_to`​ プロパティを使用して、RPC パターンを実装できます。この場合は、クライアントがその場で作成した一時的な専用応答キューを使用するか、既存のキューを使用します。 ### [](#一時的な自動削除非公開応答キューを使用した要求-応答)一時的な自動削除非公開応答キューを使用した要求-応答 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`​ 要素の操作のインラインで実行され、送信メッセージに影響する変換や設定はすべてこの要素の一部として行われます。 ### [](#明示的な応答先キューを使用した要求-応答)明示的な応答先キューを使用した要求-応答 Mule 4 では、replyTo プロパティを指定した明示的な ​`reply-to`​ キューを使用して、要求応答を実行できます。 Mule 4 の例: 明示的な応答先を使用した要求-応答の実行 ```xml #[output application/xml --- { data: payload, costumer: attributes.queryParams.costumer_id }] ``` ## [](#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 にパブリッシュします。
## [](#EnforcingExistenceQueueExchanges)キューやエクスチェンジの存在の強制 Mule 3 では、​`activeDeclarationsOnly`​ を false に設定している場合に、宣言されたキューまたはエクスチェンジが存在しなければ、AMQP Connector が 404 エラーを記載した ​`ShutdownSignalException`​ をスローします。Mule 4 では、​`createFallbackQueue`​ と ​`createFallbackExchange`​ パラメーターを使用して、キューやエクスチェンジを強制的に存在させることができます。 ```xml ``` # AMQP Connector への移行 他のコネクタと同様、AMQP Connector も一新され、Mule 3 トランスポートモデルから、簡便な UX や DataSense に完全対応するメッセージ情報を特長とする操作ベースのコネクタに進化しています。 つまり、AMQP を使用すると、他のコネクタと同じように接続や設定を行えるだけでなく、メッセージのパブリッシュやコンシュームも構造されたメッセージ情報に基づくため簡便になります。 ## [](#ConfiguringTheConnector)コネクタの設定 3.x のトランスポート設定から Mule 4 の AMQP Connector 設定に移行するということは、基本的にはほぼ同じパラメーターを使用しながら、より一貫性のある方法で宣言することになります。Mule 4 では AMQP Connector の一定のパラメーターが変更されています。 たとえば、メッセージのコンシュームに使用するパラメーターは「consumer-config」グループで宣言されますが、一般的な認証パラメーターは一般グループで設定されます。また、コネクタの動作に影響するパラメーター (config に存在) が、接続の確立方法にのみ影響するパラメーター (接続レベルで存在) と区別されています。 Mule 3 の例: コネクタの設定 ```xml ``` Mule 4 でも、実際に適用するコンテキストに同じパラメーターを設定すれば、これと同じ設定にすることができます。 Mule 4 の例: コネクタの設定 ```xml ``` `fallbackAddresses`​ はサポートされなくなりました。 ## [](#SendingMessages)メッセージの送信 Mule 4 の新しいアプローチでは、AMQP の「publish」操作に入力パラメーターのみを利用して、パブリッシュする AMQP メッセージのビルドを完成させます。 たとえば、本文にペイロードの一部のみが記載された、優先度の高い AMQP メッセージを送信し、このメッセージをグループに関連付ける場合、次の手順を実行する必要があります。 <1>) ​`transform`​ を使用して、メッセージ本文となるものをペイロードに設定します。 <2>) 生成されたストリームを文字列に変換して、テキストメッセージとして送信します。 <3>) AMQP プロパティに ​`priority`​ を、AMQP メッセージの優先度を設定するキーとして設定します。 Mule 3 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (1) (2) (3) ``` Mule 4 でも、AMQP Connector を次のとおり設定すれば、同じ結果を得ることができます。 Mule 4 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (2) (1) #[output application/json --- { order_id: payload.id, supplier: payload.warehouse }] (3) ``` 次の違いに注意します。 1) メッセージの ​`body`​ はインラインで作成され、ペイロードには変更がないため、​`transform`​ コンポーネントは必要ありません。 2) コネクタが変換出力を自動的に処理できるため、​`object-to-string`​ トランスフォーマーも排除されています。 3) 優先度は AmqpMessage 操作のプロパティとして設定され、ユーザーが正確なキーを把握している必要はありません。 上記をまとめると、3.x で AMQP トランスポートを使用してメッセージをパブリッシュするときは、AmqpMessage ペイロードとアウトバウンドプロパティを利用して AMQP メッセージの作成を設定するため、トランスポートがどのように機能するのかの詳しい知識が必要でした。4.x では AMQP Connector が、設定可能な各要素をその要素が属するスコープのパラメーターとして公開するため、AMQP のすべての機能がより明確な形で公開されます。 ## [](#ListeningForNewMessages)新規メッセージのリスン AMQP トランスポートの ​`inbound-endpoint`​ では、指定したキューの新しい AMQP メッセージを待機できます。このリスナーの出力では、ペイロードにメッセージの本文、​`AMQP Attributes`​ に AMQP のすべてのヘッダーとプロパティが記載されます。 Mule 3 の例: メッセージのリスン ```xml (2) (3) (4) ``` この場合は、メッセージをリスンして、新たに定められた形式に適合させます。 1) inboundProperties に含まれているメタデータを使用して MuleMessage を変換し、新たな API で求められる新しい JSON 形式にペイロードを適合させます。 2) 変換されたペイロードを JSON 文字列に変換します。 3) ペイロードを定義済みのエクスチェンジにパブリッシュします。 Mule 4 に同じコードを実装すると次のようになります。 Mule 4 の例: メッセージのリスン ```xml (1) (2) #[output application/json --- { items: payload, costumer: attributes.properties.userProperties.costumer_id, (3) type: attributes.headers.type }] ``` この場合、フローのコンポーネント数が減り、メッセージペイロードを異なる形式でパブリッシュするために変更する必要がありません。
1新しいメッセージの定義はインラインで行われるため、新しいメッセージ本文の JSON のみが作成されます。
2ここではメッセージの「inboundProperties」ではなく、「attributes」 POJO を使用しています。このため、AMQP メッセージの「headers」が「properties」と区別されます。
## [](#ConsumingMessages)メッセージのコンシューム Mule 3 の AMQP トランスポートでは、特定の宛先からのメッセージをフローの途中でコンシュームすることがサポートされていなかったため、この対処法として「Mule Requester Module」をアプリケーションに追加し、このモジュールがフローの途中のメッセージのコンシュームを処理していました。 たとえば、AMQP キューを公開する場合、アプリケーションは次のようになりました。 Mule 3 の例: フローの途中のメッセージのコンシューム ```xml ``` 留意点: - AMQP メッセージに関するすべてのメタデータは完全に失われるため、CorrelationId をログに記録するためには、ヘッダーを取得する構文を把握している必要があります。 - この要求には AMQP とキューの設定の両方が必要です。 Mule 4 には、「consume」操作を使用して、フローの途中のメッセージをコンシュームする機能が標準装備されています。この操作は前述のリスナーとよく似ていますが、相違点はフローのどの時点でも使用できることです。 Mule 4 の例: フローの途中のメッセージのコンシューム ```xml ``` ## [](#要求-応答の実行)要求-応答の実行 AMQP では ​`reply_to`​ プロパティを使用して、RPC パターンを実装できます。この場合は、クライアントがその場で作成した一時的な専用応答キューを使用するか、既存のキューを使用します。 ### [](#一時的な自動削除非公開応答キューを使用した要求-応答)一時的な自動削除非公開応答キューを使用した要求-応答 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`​ 要素の操作のインラインで実行され、送信メッセージに影響する変換や設定はすべてこの要素の一部として行われます。 ### [](#明示的な応答先キューを使用した要求-応答)明示的な応答先キューを使用した要求-応答 Mule 4 では、replyTo プロパティを指定した明示的な ​`reply-to`​ キューを使用して、要求応答を実行できます。 Mule 4 の例: 明示的な応答先を使用した要求-応答の実行 ```xml #[output application/xml --- { data: payload, costumer: attributes.queryParams.costumer_id }] ``` ## [](#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 にパブリッシュします。
## [](#EnforcingExistenceQueueExchanges)キューやエクスチェンジの存在の強制 Mule 3 では、​`activeDeclarationsOnly`​ を false に設定している場合に、宣言されたキューまたはエクスチェンジが存在しなければ、AMQP Connector が 404 エラーを記載した ​`ShutdownSignalException`​ をスローします。Mule 4 では、​`createFallbackQueue`​ と ​`createFallbackExchange`​ パラメーターを使用して、キューやエクスチェンジを強制的に存在させることができます。 ```xml ``` # AMQP Connector への移行 他のコネクタと同様、AMQP Connector も一新され、Mule 3 トランスポートモデルから、簡便な UX や DataSense に完全対応するメッセージ情報を特長とする操作ベースのコネクタに進化しています。 つまり、AMQP を使用すると、他のコネクタと同じように接続や設定を行えるだけでなく、メッセージのパブリッシュやコンシュームも構造されたメッセージ情報に基づくため簡便になります。 ## [](#ConfiguringTheConnector)コネクタの設定 3.x のトランスポート設定から Mule 4 の AMQP Connector 設定に移行するということは、基本的にはほぼ同じパラメーターを使用しながら、より一貫性のある方法で宣言することになります。Mule 4 では AMQP Connector の一定のパラメーターが変更されています。 たとえば、メッセージのコンシュームに使用するパラメーターは「consumer-config」グループで宣言されますが、一般的な認証パラメーターは一般グループで設定されます。また、コネクタの動作に影響するパラメーター (config に存在) が、接続の確立方法にのみ影響するパラメーター (接続レベルで存在) と区別されています。 Mule 3 の例: コネクタの設定 ```xml ``` Mule 4 でも、実際に適用するコンテキストに同じパラメーターを設定すれば、これと同じ設定にすることができます。 Mule 4 の例: コネクタの設定 ```xml ``` `fallbackAddresses`​ はサポートされなくなりました。 ## [](#SendingMessages)メッセージの送信 Mule 4 の新しいアプローチでは、AMQP の「publish」操作に入力パラメーターのみを利用して、パブリッシュする AMQP メッセージのビルドを完成させます。 たとえば、本文にペイロードの一部のみが記載された、優先度の高い AMQP メッセージを送信し、このメッセージをグループに関連付ける場合、次の手順を実行する必要があります。 <1>) ​`transform`​ を使用して、メッセージ本文となるものをペイロードに設定します。 <2>) 生成されたストリームを文字列に変換して、テキストメッセージとして送信します。 <3>) AMQP プロパティに ​`priority`​ を、AMQP メッセージの優先度を設定するキーとして設定します。 Mule 3 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (1) (2) (3) ``` Mule 4 でも、AMQP Connector を次のとおり設定すれば、同じ結果を得ることができます。 Mule 4 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (2) (1) #[output application/json --- { order_id: payload.id, supplier: payload.warehouse }] (3) ``` 次の違いに注意します。 1) メッセージの ​`body`​ はインラインで作成され、ペイロードには変更がないため、​`transform`​ コンポーネントは必要ありません。 2) コネクタが変換出力を自動的に処理できるため、​`object-to-string`​ トランスフォーマーも排除されています。 3) 優先度は AmqpMessage 操作のプロパティとして設定され、ユーザーが正確なキーを把握している必要はありません。 上記をまとめると、3.x で AMQP トランスポートを使用してメッセージをパブリッシュするときは、AmqpMessage ペイロードとアウトバウンドプロパティを利用して AMQP メッセージの作成を設定するため、トランスポートがどのように機能するのかの詳しい知識が必要でした。4.x では AMQP Connector が、設定可能な各要素をその要素が属するスコープのパラメーターとして公開するため、AMQP のすべての機能がより明確な形で公開されます。 ## [](#ListeningForNewMessages)新規メッセージのリスン AMQP トランスポートの ​`inbound-endpoint`​ では、指定したキューの新しい AMQP メッセージを待機できます。このリスナーの出力では、ペイロードにメッセージの本文、​`AMQP Attributes`​ に AMQP のすべてのヘッダーとプロパティが記載されます。 Mule 3 の例: メッセージのリスン ```xml (2) (3) (4) ``` この場合は、メッセージをリスンして、新たに定められた形式に適合させます。 1) inboundProperties に含まれているメタデータを使用して MuleMessage を変換し、新たな API で求められる新しい JSON 形式にペイロードを適合させます。 2) 変換されたペイロードを JSON 文字列に変換します。 3) ペイロードを定義済みのエクスチェンジにパブリッシュします。 Mule 4 に同じコードを実装すると次のようになります。 Mule 4 の例: メッセージのリスン ```xml (1) (2) #[output application/json --- { items: payload, costumer: attributes.properties.userProperties.costumer_id, (3) type: attributes.headers.type }] ``` この場合、フローのコンポーネント数が減り、メッセージペイロードを異なる形式でパブリッシュするために変更する必要がありません。
1新しいメッセージの定義はインラインで行われるため、新しいメッセージ本文の JSON のみが作成されます。
2ここではメッセージの「inboundProperties」ではなく、「attributes」 POJO を使用しています。このため、AMQP メッセージの「headers」が「properties」と区別されます。
## [](#ConsumingMessages)メッセージのコンシューム Mule 3 の AMQP トランスポートでは、特定の宛先からのメッセージをフローの途中でコンシュームすることがサポートされていなかったため、この対処法として「Mule Requester Module」をアプリケーションに追加し、このモジュールがフローの途中のメッセージのコンシュームを処理していました。 たとえば、AMQP キューを公開する場合、アプリケーションは次のようになりました。 Mule 3 の例: フローの途中のメッセージのコンシューム ```xml ``` 留意点: - AMQP メッセージに関するすべてのメタデータは完全に失われるため、CorrelationId をログに記録するためには、ヘッダーを取得する構文を把握している必要があります。 - この要求には AMQP とキューの設定の両方が必要です。 Mule 4 には、「consume」操作を使用して、フローの途中のメッセージをコンシュームする機能が標準装備されています。この操作は前述のリスナーとよく似ていますが、相違点はフローのどの時点でも使用できることです。 Mule 4 の例: フローの途中のメッセージのコンシューム ```xml ``` ## [](#要求-応答の実行)要求-応答の実行 AMQP では ​`reply_to`​ プロパティを使用して、RPC パターンを実装できます。この場合は、クライアントがその場で作成した一時的な専用応答キューを使用するか、既存のキューを使用します。 ### [](#一時的な自動削除非公開応答キューを使用した要求-応答)一時的な自動削除非公開応答キューを使用した要求-応答 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`​ 要素の操作のインラインで実行され、送信メッセージに影響する変換や設定はすべてこの要素の一部として行われます。 ### [](#明示的な応答先キューを使用した要求-応答)明示的な応答先キューを使用した要求-応答 Mule 4 では、replyTo プロパティを指定した明示的な ​`reply-to`​ キューを使用して、要求応答を実行できます。 Mule 4 の例: 明示的な応答先を使用した要求-応答の実行 ```xml #[output application/xml --- { data: payload, costumer: attributes.queryParams.costumer_id }] ``` ## [](#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 にパブリッシュします。
## [](#EnforcingExistenceQueueExchanges)キューやエクスチェンジの存在の強制 Mule 3 では、​`activeDeclarationsOnly`​ を false に設定している場合に、宣言されたキューまたはエクスチェンジが存在しなければ、AMQP Connector が 404 エラーを記載した ​`ShutdownSignalException`​ をスローします。Mule 4 では、​`createFallbackQueue`​ と ​`createFallbackExchange`​ パラメーターを使用して、キューやエクスチェンジを強制的に存在させることができます。 ```xml ``` # AMQP Connector への移行 他のコネクタと同様、AMQP Connector も一新され、Mule 3 トランスポートモデルから、簡便な UX や DataSense に完全対応するメッセージ情報を特長とする操作ベースのコネクタに進化しています。 つまり、AMQP を使用すると、他のコネクタと同じように接続や設定を行えるだけでなく、メッセージのパブリッシュやコンシュームも構造されたメッセージ情報に基づくため簡便になります。 ## [](#ConfiguringTheConnector)コネクタの設定 3.x のトランスポート設定から Mule 4 の AMQP Connector 設定に移行するということは、基本的にはほぼ同じパラメーターを使用しながら、より一貫性のある方法で宣言することになります。Mule 4 では AMQP Connector の一定のパラメーターが変更されています。 たとえば、メッセージのコンシュームに使用するパラメーターは「consumer-config」グループで宣言されますが、一般的な認証パラメーターは一般グループで設定されます。また、コネクタの動作に影響するパラメーター (config に存在) が、接続の確立方法にのみ影響するパラメーター (接続レベルで存在) と区別されています。 Mule 3 の例: コネクタの設定 ```xml ``` Mule 4 でも、実際に適用するコンテキストに同じパラメーターを設定すれば、これと同じ設定にすることができます。 Mule 4 の例: コネクタの設定 ```xml ``` `fallbackAddresses`​ はサポートされなくなりました。 ## [](#SendingMessages)メッセージの送信 Mule 4 の新しいアプローチでは、AMQP の「publish」操作に入力パラメーターのみを利用して、パブリッシュする AMQP メッセージのビルドを完成させます。 たとえば、本文にペイロードの一部のみが記載された、優先度の高い AMQP メッセージを送信し、このメッセージをグループに関連付ける場合、次の手順を実行する必要があります。 <1>) ​`transform`​ を使用して、メッセージ本文となるものをペイロードに設定します。 <2>) 生成されたストリームを文字列に変換して、テキストメッセージとして送信します。 <3>) AMQP プロパティに ​`priority`​ を、AMQP メッセージの優先度を設定するキーとして設定します。 Mule 3 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (1) (2) (3) ``` Mule 4 でも、AMQP Connector を次のとおり設定すれば、同じ結果を得ることができます。 Mule 4 の例: 優先度が設定されたメッセージをグループの一部として送信 ```xml (2) (1) #[output application/json --- { order_id: payload.id, supplier: payload.warehouse }] (3) ``` 次の違いに注意します。 1) メッセージの ​`body`​ はインラインで作成され、ペイロードには変更がないため、​`transform`​ コンポーネントは必要ありません。 2) コネクタが変換出力を自動的に処理できるため、​`object-to-string`​ トランスフォーマーも排除されています。 3) 優先度は AmqpMessage 操作のプロパティとして設定され、ユーザーが正確なキーを把握している必要はありません。 上記をまとめると、3.x で AMQP トランスポートを使用してメッセージをパブリッシュするときは、AmqpMessage ペイロードとアウトバウンドプロパティを利用して AMQP メッセージの作成を設定するため、トランスポートがどのように機能するのかの詳しい知識が必要でした。4.x では AMQP Connector が、設定可能な各要素をその要素が属するスコープのパラメーターとして公開するため、AMQP のすべての機能がより明確な形で公開されます。 ## [](#ListeningForNewMessages)新規メッセージのリスン AMQP トランスポートの ​`inbound-endpoint`​ では、指定したキューの新しい AMQP メッセージを待機できます。このリスナーの出力では、ペイロードにメッセージの本文、​`AMQP Attributes`​ に AMQP のすべてのヘッダーとプロパティが記載されます。 Mule 3 の例: メッセージのリスン ```xml (2) (3) (4) ``` この場合は、メッセージをリスンして、新たに定められた形式に適合させます。 1) inboundProperties に含まれているメタデータを使用して MuleMessage を変換し、新たな API で求められる新しい JSON 形式にペイロードを適合させます。 2) 変換されたペイロードを JSON 文字列に変換します。 3) ペイロードを定義済みのエクスチェンジにパブリッシュします。 Mule 4 に同じコードを実装すると次のようになります。 Mule 4 の例: メッセージのリスン ```xml (1) (2) #[output application/json --- { items: payload, costumer: attributes.properties.userProperties.costumer_id, (3) type: attributes.headers.type }] ``` この場合、フローのコンポーネント数が減り、メッセージペイロードを異なる形式でパブリッシュするために変更する必要がありません。
1新しいメッセージの定義はインラインで行われるため、新しいメッセージ本文の JSON のみが作成されます。
2ここではメッセージの「inboundProperties」ではなく、「attributes」 POJO を使用しています。このため、AMQP メッセージの「headers」が「properties」と区別されます。
## [](#ConsumingMessages)メッセージのコンシューム Mule 3 の AMQP トランスポートでは、特定の宛先からのメッセージをフローの途中でコンシュームすることがサポートされていなかったため、この対処法として「Mule Requester Module」をアプリケーションに追加し、このモジュールがフローの途中のメッセージのコンシュームを処理していました。 たとえば、AMQP キューを公開する場合、アプリケーションは次のようになりました。 Mule 3 の例: フローの途中のメッセージのコンシューム ```xml ``` 留意点: - AMQP メッセージに関するすべてのメタデータは完全に失われるため、CorrelationId をログに記録するためには、ヘッダーを取得する構文を把握している必要があります。 - この要求には AMQP とキューの設定の両方が必要です。 Mule 4 には、「consume」操作を使用して、フローの途中のメッセージをコンシュームする機能が標準装備されています。この操作は前述のリスナーとよく似ていますが、相違点はフローのどの時点でも使用できることです。 Mule 4 の例: フローの途中のメッセージのコンシューム ```xml ``` ## [](#要求-応答の実行)要求-応答の実行 AMQP では ​`reply_to`​ プロパティを使用して、RPC パターンを実装できます。この場合は、クライアントがその場で作成した一時的な専用応答キューを使用するか、既存のキューを使用します。 ### [](#一時的な自動削除非公開応答キューを使用した要求-応答)一時的な自動削除非公開応答キューを使用した要求-応答 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`​ 要素の操作のインラインで実行され、送信メッセージに影響する変換や設定はすべてこの要素の一部として行われます。 ### [](#明示的な応答先キューを使用した要求-応答)明示的な応答先キューを使用した要求-応答 Mule 4 では、replyTo プロパティを指定した明示的な ​`reply-to`​ キューを使用して、要求応答を実行できます。 Mule 4 の例: 明示的な応答先を使用した要求-応答の実行 ```xml #[output application/xml --- { data: payload, costumer: attributes.queryParams.costumer_id }] ``` ## [](#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 にパブリッシュします。
## [](#EnforcingExistenceQueueExchanges)キューやエクスチェンジの存在の強制 Mule 3 では、​`activeDeclarationsOnly`​ を false に設定している場合に、宣言されたキューまたはエクスチェンジが存在しなければ、AMQP Connector が 404 エラーを記載した ​`ShutdownSignalException`​ をスローします。Mule 4 では、​`createFallbackQueue`​ と ​`createFallbackExchange`​ パラメーターを使用して、キューやエクスチェンジを強制的に存在させることができます。 ```xml ``` # Anypoint Enterprise Security (AES) の機能の移行 Mule 4 では、Anypoint Enterprise Security Module が次の各種のモジュールに分割されました。 - [Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.3/securing#cryptography-module)​ - Mule 3 の Cryptography Module と Signature Module の代わりに導入されました。 - [Secure Configuration Properties Module](https://docs.mulesoft.com/jp/mule-runtime/4.3/secure-configuration-properties)​ - Mule 3 のセキュアプロパティプレースホルダーの代わりに導入されました。 - [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ - Mule 3 Filters Module の機能が組み込まれています。 - [OAuth2 プロバイダー](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​ - Mule 3 の OAuth2 プロバイダーの代わりに導入されました。 Mule 4 への移行方法についての詳細は、上記の各モジュールのドキュメントを参照してください。 # Anypoint Enterprise Security (AES) の機能の移行 Mule 4 では、Anypoint Enterprise Security Module が次の各種のモジュールに分割されました。 - [Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.4/securing#cryptography-module)​ - Mule 3 の Cryptography Module と Signature Module の代わりに導入されました。 - [Secure Configuration Properties Module](https://docs.mulesoft.com/jp/mule-runtime/4.4/secure-configuration-properties)​ - Mule 3 のセキュアプロパティプレースホルダーの代わりに導入されました。 - [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ - Mule 3 Filters Module の機能が組み込まれています。 - [OAuth2 プロバイダー](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​ - Mule 3 の OAuth2 プロバイダーの代わりに導入されました。 Mule 4 への移行方法についての詳細は、上記の各モジュールのドキュメントを参照してください。 # Anypoint Enterprise Security (AES) の機能の移行 Mule 4 では、Anypoint Enterprise Security Module が次の各種のモジュールに分割されました。 - [Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.5/securing#cryptography-module)​ - Mule 3 の Cryptography Module と Signature Module の代わりに導入されました。 - [Secure Configuration Properties Module](https://docs.mulesoft.com/jp/mule-runtime/4.5/secure-configuration-properties)​ - Mule 3 のセキュアプロパティプレースホルダーの代わりに導入されました。 - [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ - Mule 3 Filters Module の機能が組み込まれています。 - [OAuth2 プロバイダー](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​ - Mule 3 の OAuth2 プロバイダーの代わりに導入されました。 Mule 4 への移行方法についての詳細は、上記の各モジュールのドキュメントを参照してください。 # Anypoint Enterprise Security (AES) の機能の移行 Mule 4 では、Anypoint Enterprise Security Module が次の各種のモジュールに分割されました。 - [Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.6/securing#cryptography-module)​ - Mule 3 の Cryptography Module と Signature Module の代わりに導入されました。 - [Secure Configuration Properties Module](https://docs.mulesoft.com/jp/mule-runtime/4.6/secure-configuration-properties)​ - Mule 3 のセキュアプロパティプレースホルダーの代わりに導入されました。 - [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ - Mule 3 Filters Module の機能が組み込まれています。 - [OAuth2 プロバイダー](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​ - Mule 3 の OAuth2 プロバイダーの代わりに導入されました。 Mule 4 への移行方法についての詳細は、上記の各モジュールのドキュメントを参照してください。 # Anypoint Enterprise Security (AES) の機能の移行 Mule 4 では、Anypoint Enterprise Security Module が次の各種のモジュールに分割されました。 - [Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.7/securing#cryptography-module)​ - Mule 3 の Cryptography Module と Signature Module の代わりに導入されました。 - [Secure Configuration Properties Module](https://docs.mulesoft.com/jp/mule-runtime/4.7/secure-configuration-properties)​ - Mule 3 のセキュアプロパティプレースホルダーの代わりに導入されました。 - [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ - Mule 3 Filters Module の機能が組み込まれています。 - [OAuth2 プロバイダー](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​ - Mule 3 の OAuth2 プロバイダーの代わりに導入されました。 Mule 4 への移行方法についての詳細は、上記の各モジュールのドキュメントを参照してください。 # Anypoint Enterprise Security (AES) の機能の移行 Mule 4 では、Anypoint Enterprise Security Module が次の各種のモジュールに分割されました。 - [Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.8/securing#cryptography-module)​ - Mule 3 の Cryptography Module と Signature Module の代わりに導入されました。 - [Secure Configuration Properties Module](https://docs.mulesoft.com/jp/mule-runtime/4.8/secure-configuration-properties)​ - Mule 3 のセキュアプロパティプレースホルダーの代わりに導入されました。 - [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ - Mule 3 Filters Module の機能が組み込まれています。 - [OAuth2 プロバイダー](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​ - Mule 3 の OAuth2 プロバイダーの代わりに導入されました。 Mule 4 への移行方法についての詳細は、上記の各モジュールのドキュメントを参照してください。 # Anypoint Enterprise Security (AES) の機能の移行 Mule 4 では、Anypoint Enterprise Security Module が次の各種のモジュールに分割されました。 - [Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.9/securing#cryptography-module)​ - Mule 3 の Cryptography Module と Signature Module の代わりに導入されました。 - [Secure Configuration Properties Module](https://docs.mulesoft.com/jp/mule-runtime/4.9/secure-configuration-properties)​ - Mule 3 のセキュアプロパティプレースホルダーの代わりに導入されました。 - [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ - Mule 3 Filters Module の機能が組み込まれています。 - [OAuth2 プロバイダー](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​ - Mule 3 の OAuth2 プロバイダーの代わりに導入されました。 Mule 4 への移行方法についての詳細は、上記の各モジュールのドキュメントを参照してください。 # API Manager で管理されるアプリケーションの移行 API Manager で管理される既存の Mule 3 アプリケーションを Mule 4 に移行するには、次の手順を使用します。 1. [移行の準備](#prepare-migration) 既存の Mule 3 アプリケーションの設定方法に基づいて、移行を準備するための前提条件を慎重に確認します。 2. [移行方法の決定](#determine-migration-approach) いくつかの要素に基づきます。たとえば、ダウンタイムの確保、適用済みポリシーの削除、コントラクトの移行、移行用インスタンスの作成が移行に必要かどうかに基づきます。 3. [移行の実行](#perform-migration) アプリケーションを移行します。 ## [](#prepare-migration)Mule 3 アプリケーションを移行するための準備 API で管理される既存の Mule 3 アプリケーションを Mule 4 に移行する前に、次のガイドラインを慎重に確認して判断します。 - Mule 3 アプリケーションの管理方法: 基本エンドポイント、インテグレーションアプリケーション、または複雑なプロキシ このシナリオでアプリケーションを移行するには、まず ​[API ゲートウェイの移行方法を確認](https://docs.mulesoft.com/mule-runtime/latest/)​して準備を整えてから、​[Mule 4 に移行](https://docs.mulesoft.com/mule-runtime/latest/)​します。 - アプリケーションの保護方法: デフォルトポリシーまたはカスタムポリシー カスタムポリシーを Mule 3 API に適用している場合、​[「API ポリシーの移行」](https://docs.mulesoft.com/mule-runtime/latest/)​に従います。標準プロキシを適用している場合、API Manager UI を使用してプロキシを再作成できます。 - API を分類しているかどうか API を分類していない場合、まず ​[API インスタンスを環境に分類](https://docs.mulesoft.com/jp/api-manager/latest/classify-api-task)​します。 ## [](#determine-migration-approach)移行方法の決定 API Manager で管理される Mule 3 アプリケーションを移行するには、新しい API インスタンスを作成します。Mule 4 に移行する前に、次の要素を慎重に考慮して、要件に最も適した方法を決定します。
移行要素 API インスタンスの作成

ダウンタイムが必要

いいえ

適用済みポリシーの削除が必要

いいえ

コントラクトの移行が必要

はい

API インスタンスで API メトリクスを継続

いいえ
## [](#perform-migration)移行の実行 次のインスタンスを使用して、Mule 3 アプリケーションを移行できます。 - [新しい API インスタンス](#migrate-with-new-api) ### [](#migrate-with-new-api)新しい API インスタンスを使用した移行 次の図に示された提案の概要を参照し、新しい API インスタンスを使用して、Mule 4 上で独立した Mule Runtime インスタンスを設定します。 ![new instance migration mule4](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/new-instance-migration-mule4.png) Mule アプリケーションがプロキシではない場合、この同じ提案が移行手順に適用されます (ただし、バックエンドコンポーネントはありません)。 新しい API インスタンスを使用して Mule 3 API を Mule 4 に移行する手順は、次のとおりです。 1. API Manager の ​**\[API Administration (API 管理)\]**​ ページで、​**\[Manage API (API を管理)\]**​ > ​**\[Create new API (新しい API を作成)\]**​ を選択します。 インスタンスの表示ラベルを使用してこの新しい API インスタンスを識別します。 2. **\[Endpoint Configuration (エンドポイント設定)\]**​ ウィンドウの ​**\[Mule version (Mule バージョン)\]**​ で ​`Mule 4`​ を選択し、保存します。 3. API Manager の左側のナビゲーションペインで、アラート、SLA 階層、ポリシーを API に適用します。 4. API でコントラクトベースのポリシー (クライアント ID 適用ポリシーなど) を使用している場合、API インスタンスの​[コントラクトを移行します](#migrate-contracts)​。 5. API の設定が完了している場合は、Mule 4 アプリケーションを開始して、要求を送信します。 6. アプリケーションの検証が正常に終了したら、Mule 3 アプリケーションをアンデプロイします。 ### [](#migrate-contracts)コントラクトの移行 新しい API インスタンスを作成してアプリケーションを移行する前に、既存の API コントラクトを新しい Mule 4 環境に移行します。 **タスクの前提条件** コントラクトを移行する前に、次のロールを持っていることを確認します。 - ルート組織の組織のシステム管理者 - ソース API とのコントラクトがあるすべてのアプリケーションのアプリケーションオーナー Anypoint Platform UI を使用してコントラクトを移行する手順は、次のとおりです。 1. **API Manager**​ > ​**\[Client Applications (クライアントアプリケーション)\]**​ に移動して、アプリケーションを選択します。 **\[Contracts (コントラクト)\]**​ 項目で ​`API`​ オプションが選択されていることを確認します。 2. 右側のナビゲーションで、​**\[Owners (オーナー)\]**​ 項目までスクロールダウンして、自分の名前を追加します。 3. **\[Exchange (交換)\]**​ で、API インスタンスを選択し、アクセス権を要求します。 4. **API Manager**​ で、自分にアクセス権を付与します。 要求承認プロセスを自動化する手順は、次のとおりです。 1. アプリケーションのオーナーを追加します。 ```text curl 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations//applications//owners' \ -H 'Content-Type: application/json;charset=UTF-8' \ -H 'Authorization: Bearer ' \ --data-raw '{"id":"/applications//contracts' \ -H 'authorization: bearer ' \ -H 'content-type: application/json' \ --data-raw '{"apiId":"","environmentId":"","instanceType":"api","acceptedTerms":true,"organizationId":"","groupId":"","assetId":"","version":"","versionGroup":""}' ``` 3. コントラクトを承認します。 ```text curl 'https://anypoint.mulesoft.com/apimanager/xapi/v1/organizations//environments//apis//contracts//approve' \ -H 'Authorization: Bearer ' \ -H 'Content-Type: application/json;charset=UTF-8' \ --data-raw '{}' ``` ## [](#最新の-mule-3-バージョンへの移行)最新の Mule 3 バージョンへの移行 Mule 4 への移行準備が整っておらず、Mule 3 の最新バージョンに移行する必要がある場合は、[「Upgrading Mule Runtime Engine(Versions 3.x to 3.n) (Mule Runtime Engine のアップグレード (バージョン 3.x から 3.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-versions)を参照してください。 移行先の Mule バージョンのリリースノートを慎重に確認してください。同じ API インスタンスを参照する同じアプリケーションを使用して新しい Mule Runtime を開始すると、既存の API は最新の Mule 3.x バージョンですぐに管理されます。API Manager で追加の手順を実行する必要はありません。 # API Manager で管理されるアプリケーションの移行 API Manager で管理される既存の Mule 3 アプリケーションを Mule 4 に移行するには、次の手順を使用します。 1. [移行の準備](#prepare-migration) 既存の Mule 3 アプリケーションの設定方法に基づいて、移行を準備するための前提条件を慎重に確認します。 2. [移行方法の決定](#determine-migration-approach) いくつかの要素に基づきます。たとえば、ダウンタイムの確保、適用済みポリシーの削除、コントラクトの移行、移行用インスタンスの作成が移行に必要かどうかに基づきます。 3. [移行の実行](#perform-migration) アプリケーションを移行します。 ## [](#prepare-migration)Mule 3 アプリケーションを移行するための準備 API で管理される既存の Mule 3 アプリケーションを Mule 4 に移行する前に、次のガイドラインを慎重に確認して判断します。 - Mule 3 アプリケーションの管理方法: 基本エンドポイント、インテグレーションアプリケーション、または複雑なプロキシ このシナリオでアプリケーションを移行するには、まず ​[API ゲートウェイの移行方法を確認](https://docs.mulesoft.com/mule-runtime/latest/)​して準備を整えてから、​[Mule 4 に移行します](https://docs.mulesoft.com/mule-runtime/latest/)​。 - アプリケーションの保護方法: デフォルトポリシーまたはカスタムポリシー カスタムポリシーを Mule 3 API に適用している場合、​[「API ポリシーの移行」](https://docs.mulesoft.com/mule-runtime/latest/)​に従います。標準プロキシを適用している場合、API Manager UI を使用してプロキシを再作成できます。 - API を分類しているかどうか API を分類していない場合、まず ​[API インスタンスを環境に分類します](https://docs.mulesoft.com/jp/api-manager/latest/classify-api-task)​。 ## [](#determine-migration-approach)移行方法の決定 API Manager で管理される Mule 3 アプリケーションを移行するには、新しい API インスタンスを作成します。Mule 4 に移行する前に、次の要素を慎重に考慮して、要件に最も適した方法を決定します。
移行要素 API インスタンスの作成

ダウンタイムが必要

いいえ

適用済みポリシーの削除が必要

いいえ

コントラクトの移行が必要

はい

API インスタンスで API メトリクスを継続

いいえ
## [](#perform-migration)移行の実行 次のインスタンスを使用して、Mule 3 アプリケーションを移行できます。 - [新しい API インスタンス](#migrate-with-new-api) ### [](#migrate-with-new-api)新しい API インスタンスを使用した移行 次の図に示された提案の概要を参照し、新しい API インスタンスを使用して、Mule 4 上で独立した Mule Runtime インスタンスを設定します。 ![new instance migration mule4](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/new-instance-migration-mule4.png) Mule アプリケーションがプロキシではない場合、この同じ提案が移行手順に適用されます (ただし、バックエンドコンポーネントはありません)。 新しい API インスタンスを使用して Mule 3 API を Mule 4 に移行する手順は、次のとおりです。 1. API Manager の ​**\[API Administration (API 管理)\]**​ ページで、​**\[Manage API (API を管理)\]**​ > ​**\[Create new API (新しい API を作成)\]**​ を選択します。 インスタンスの表示ラベルを使用してこの新しい API インスタンスを識別します。 2. **\[Endpoint Configuration (エンドポイント設定)\]**​ ウィンドウの ​**\[Mule version (Mule バージョン)\]**​ で ​`Mule 4`​ を選択し、保存します。 3. API Manager の左側のナビゲーションペインで、アラート、SLA 階層、ポリシーを API に適用します。 4. API でコントラクトベースのポリシー (クライアント ID 適用ポリシーなど) を使用している場合、API インスタンスの​[コントラクトを移行します](#migrate-contracts)​。 5. API の設定が完了している場合は、Mule 4 アプリケーションを開始して、要求を送信します。 6. アプリケーションの検証が正常に終了したら、Mule 3 アプリケーションをアンデプロイします。 ### [](#migrate-contracts)コントラクトの移行 新しい API インスタンスを作成してアプリケーションを移行する前に、既存の API コントラクトを新しい Mule 4 環境に移行します。 **タスクの前提条件** コントラクトを移行する前に、次のロールを持っていることを確認します。 - ルート組織の組織のシステム管理者 - ソース API とのコントラクトがあるすべてのアプリケーションのアプリケーションオーナー Anypoint Platform UI を使用してコントラクトを移行する手順は、次のとおりです。 1. **API Manager**​ > ​**\[Client Applications (クライアントアプリケーション)\]**​ に移動して、アプリケーションを選択します。 **\[Contracts (コントラクト)\]**​ 項目で ​`API`​ オプションが選択されていることを確認します。 2. 右側のナビゲーションで、​**\[Owners (オーナー)\]**​ 項目までスクロールダウンして、自分の名前を追加します。 3. **\[Exchange (交換)\]**​ で、API インスタンスを選択し、アクセス権を要求します。 4. **API Manager**​ で、自分にアクセス権を付与します。 要求承認プロセスを自動化する手順は、次のとおりです。 1. アプリケーションのオーナーを追加します。 ```text curl 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations//applications//owners' \ -H 'Content-Type: application/json;charset=UTF-8' \ -H 'Authorization: Bearer ' \ --data-raw '{"id":"/applications//contracts' \ -H 'authorization: bearer ' \ -H 'content-type: application/json' \ --data-raw '{"apiId":"","environmentId":"","instanceType":"api","acceptedTerms":true,"organizationId":"","groupId":"","assetId":"","version":"","versionGroup":""}' ``` 3. コントラクトを承認します。 ```text curl 'https://anypoint.mulesoft.com/apimanager/xapi/v1/organizations//environments//apis//contracts//approve' \ -H 'Authorization: Bearer ' \ -H 'Content-Type: application/json;charset=UTF-8' \ --data-raw '{}' ``` ## [](#最新の-mule-3-バージョンへの移行)最新の Mule 3 バージョンへの移行 Mule 4 への移行準備が整っておらず、Mule 3 の最新バージョンに移行する必要がある場合は、​[「Upgrading Mule Runtime Engine(Versions 3.x to 3.n) (Mule Runtime Engine のアップグレード (バージョン 3.x から 3.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-versions)​を参照してください。 移行先の Mule バージョンのリリースノートを慎重に確認してください。同じ API インスタンスを参照する同じアプリケーションを使用して新しい Mule Runtime を開始すると、既存の API は最新の Mule 3.x バージョンですぐに管理されます。API Manager で追加の手順を実行する必要はありません。 # API Manager で管理されるアプリケーションの移行 API Manager で管理される既存の Mule 3 アプリケーションを Mule 4 に移行するには、次の手順を使用します。 1. [移行の準備](#prepare-migration) 既存の Mule 3 アプリケーションの設定方法に基づいて、移行を準備するための前提条件を慎重に確認します。 2. [移行方法の決定](#determine-migration-approach) いくつかの要素に基づきます。たとえば、ダウンタイムの確保、適用済みポリシーの削除、コントラクトの移行、移行用インスタンスの作成が移行に必要かどうかに基づきます。 3. [移行の実行](#perform-migration) アプリケーションを移行します。 ## [](#prepare-migration)Mule 3 アプリケーションを移行するための準備 API で管理される既存の Mule 3 アプリケーションを Mule 4 に移行する前に、次のガイドラインを慎重に確認して判断します。 - Mule 3 アプリケーションの管理方法: 基本エンドポイント、インテグレーションアプリケーション、または複雑なプロキシ このシナリオでアプリケーションを移行するには、まず ​[API ゲートウェイの移行方法を確認](https://docs.mulesoft.com/mule-runtime/latest/)​して準備を整えてから、​[Mule 4 に移行します](https://docs.mulesoft.com/mule-runtime/latest/)​。 - アプリケーションの保護方法: デフォルトポリシーまたはカスタムポリシー カスタムポリシーを Mule 3 API に適用している場合、​[「API ポリシーの移行」](https://docs.mulesoft.com/mule-runtime/latest/)​に従います。標準プロキシを適用している場合、API Manager UI を使用してプロキシを再作成できます。 - API を分類しているかどうか API を分類していない場合、まず ​[API インスタンスを環境に分類します](https://docs.mulesoft.com/jp/api-manager/latest/classify-api-task)​。 ## [](#determine-migration-approach)移行方法の決定 API Manager で管理される Mule 3 アプリケーションを移行するには、新しい API インスタンスを作成します。Mule 4 に移行する前に、次の要素を慎重に考慮して、要件に最も適した方法を決定します。
移行要素 API インスタンスの作成

ダウンタイムが必要

いいえ

適用済みポリシーの削除が必要

いいえ

コントラクトの移行が必要

はい

API インスタンスで API メトリクスを継続

いいえ
## [](#perform-migration)移行の実行 次のインスタンスを使用して、Mule 3 アプリケーションを移行できます。 - [新しい API インスタンス](#migrate-with-new-api) ### [](#migrate-with-new-api)新しい API インスタンスを使用した移行 次の図に示された提案の概要を参照し、新しい API インスタンスを使用して、Mule 4 上で独立した Mule Runtime インスタンスを設定します。 ![new instance migration mule4](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/new-instance-migration-mule4.png) Mule アプリケーションがプロキシではない場合、この同じ提案が移行手順に適用されます (ただし、バックエンドコンポーネントはありません)。 新しい API インスタンスを使用して Mule 3 API を Mule 4 に移行する手順は、次のとおりです。 1. API Manager の ​**\[API Administration (API 管理)\]**​ ページで、​**\[Manage API (API を管理)\]**​ > ​**\[Create new API (新しい API を作成)\]**​ を選択します。 インスタンスの表示ラベルを使用してこの新しい API インスタンスを識別します。 2. **\[Endpoint Configuration (エンドポイント設定)\]**​ ウィンドウの ​**\[Mule version (Mule バージョン)\]**​ で ​`Mule 4`​ を選択し、保存します。 3. API Manager の左側のナビゲーションペインで、アラート、SLA 階層、ポリシーを API に適用します。 4. API でコントラクトベースのポリシー (クライアント ID 適用ポリシーなど) を使用している場合、API インスタンスの​[コントラクトを移行します](#migrate-contracts)​。 5. API の設定が完了している場合は、Mule 4 アプリケーションを開始して、要求を送信します。 6. アプリケーションの検証が正常に終了したら、Mule 3 アプリケーションをアンデプロイします。 ### [](#migrate-contracts)コントラクトの移行 新しい API インスタンスを作成してアプリケーションを移行する前に、既存の API コントラクトを新しい Mule 4 環境に移行します。 **タスクの前提条件** コントラクトを移行する前に、次のロールを持っていることを確認します。 - ルート組織の組織のシステム管理者 - ソース API とのコントラクトがあるすべてのアプリケーションのアプリケーションオーナー Anypoint Platform UI を使用してコントラクトを移行する手順は、次のとおりです。 1. **API Manager**​ > ​**\[Client Applications (クライアントアプリケーション)\]**​ に移動して、アプリケーションを選択します。 **\[Contracts (コントラクト)\]**​ 項目で ​`API`​ オプションが選択されていることを確認します。 2. 右側のナビゲーションで、​**\[Owners (オーナー)\]**​ 項目までスクロールダウンして、自分の名前を追加します。 3. **\[Exchange (交換)\]**​ で、API インスタンスを選択し、アクセス権を要求します。 4. **API Manager**​ で、自分にアクセス権を付与します。 要求承認プロセスを自動化する手順は、次のとおりです。 1. アプリケーションのオーナーを追加します。 ```text curl 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations//applications//owners' \ -H 'Content-Type: application/json;charset=UTF-8' \ -H 'Authorization: Bearer ' \ --data-raw '{"id":"/applications//contracts' \ -H 'authorization: bearer ' \ -H 'content-type: application/json' \ --data-raw '{"apiId":"","environmentId":"","instanceType":"api","acceptedTerms":true,"organizationId":"","groupId":"","assetId":"","version":"","versionGroup":""}' ``` 3. コントラクトを承認します。 ```text curl 'https://anypoint.mulesoft.com/apimanager/xapi/v1/organizations//environments//apis//contracts//approve' \ -H 'Authorization: Bearer ' \ -H 'Content-Type: application/json;charset=UTF-8' \ --data-raw '{}' ``` ## [](#最新の-mule-3-バージョンへの移行)最新の Mule 3 バージョンへの移行 Mule 4 への移行準備が整っておらず、Mule 3 の最新バージョンに移行する必要がある場合は、​[「Upgrading Mule Runtime Engine(Versions 3.x to 3.n) (Mule Runtime Engine のアップグレード (バージョン 3.x から 3.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-versions)​を参照してください。 移行先の Mule バージョンのリリースノートを慎重に確認してください。同じ API インスタンスを参照する同じアプリケーションを使用して新しい Mule Runtime を開始すると、既存の API は最新の Mule 3.x バージョンですぐに管理されます。API Manager で追加の手順を実行する必要はありません。 # API Manager で管理されるアプリケーションの移行 API Manager で管理される既存の Mule 3 アプリケーションを Mule 4 に移行するには、次の手順を使用します。 1. [移行の準備](#prepare-migration) 既存の Mule 3 アプリケーションの設定方法に基づいて、移行を準備するための前提条件を慎重に確認します。 2. [移行方法の決定](#determine-migration-approach) いくつかの要素に基づきます。たとえば、ダウンタイムの確保、適用済みポリシーの削除、コントラクトの移行、移行用インスタンスの作成が移行に必要かどうかに基づきます。 3. [移行の実行](#perform-migration) アプリケーションを移行します。 ## [](#prepare-migration)Mule 3 アプリケーションを移行するための準備 API で管理される既存の Mule 3 アプリケーションを Mule 4 に移行する前に、次のガイドラインを慎重に確認して判断します。 - Mule 3 アプリケーションの管理方法: 基本エンドポイント、インテグレーションアプリケーション、または複雑なプロキシ このシナリオでアプリケーションを移行するには、まず ​[API ゲートウェイの移行方法を確認](https://docs.mulesoft.com/mule-runtime/latest/)​して準備を整えてから、​[Mule 4 に移行](https://docs.mulesoft.com/mule-runtime/latest/)​します。 - アプリケーションの保護方法: デフォルトポリシーまたはカスタムポリシー カスタムポリシーを Mule 3 API に適用している場合、​[「API ポリシーの移行」](https://docs.mulesoft.com/mule-runtime/latest/)​に従います。標準プロキシを適用している場合、API Manager UI を使用してプロキシを再作成できます。 - API を分類しているかどうか API を分類していない場合、まず ​[API インスタンスを環境に分類](https://docs.mulesoft.com/jp/api-manager/latest/classify-api-task)​します。 ## [](#determine-migration-approach)移行方法の決定 API Manager で管理される Mule 3 アプリケーションを移行するには、新しい API インスタンスを作成します。Mule 4 に移行する前に、次の要素を慎重に考慮して、要件に最も適した方法を決定します。
移行要素 API インスタンスの作成

ダウンタイムが必要

いいえ

適用済みポリシーの削除が必要

いいえ

コントラクトの移行が必要

はい

API インスタンスで API メトリクスを継続

いいえ
## [](#perform-migration)移行の実行 次のインスタンスを使用して、Mule 3 アプリケーションを移行できます。 - [新しい API インスタンス](#migrate-with-new-api) ### [](#migrate-with-new-api)新しい API インスタンスを使用した移行 次の図に示された提案の概要を参照し、新しい API インスタンスを使用して、Mule 4 上で独立した Mule Runtime インスタンスを設定します。 ![new instance migration mule4](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/new-instance-migration-mule4.png) Mule アプリケーションがプロキシではない場合、この同じ提案が移行手順に適用されます (ただし、バックエンドコンポーネントはありません)。 新しい API インスタンスを使用して Mule 3 API を Mule 4 に移行する手順は、次のとおりです。 1. API Manager の ​**\[API Administration (API 管理)\]**​ ページで、​**\[Manage API (API を管理)\]**​ > ​**\[Create new API (新しい API を作成)\]**​ を選択します。 インスタンスの表示ラベルを使用してこの新しい API インスタンスを識別します。 2. **\[Endpoint Configuration (エンドポイント設定)\]**​ ウィンドウの ​**\[Mule version (Mule バージョン)\]**​ で ​`Mule 4`​ を選択し、保存します。 3. API Manager の左側のナビゲーションペインで、アラート、SLA 階層、ポリシーを API に適用します。 4. API でコントラクトベースのポリシー (クライアント ID 適用ポリシーなど) を使用している場合、API インスタンスの​[コントラクトを移行します](#migrate-contracts)​。 5. API の設定が完了している場合は、Mule 4 アプリケーションを開始して、要求を送信します。 6. アプリケーションの検証が正常に終了したら、Mule 3 アプリケーションをアンデプロイします。 ### [](#migrate-contracts)コントラクトの移行 新しい API インスタンスを作成してアプリケーションを移行する前に、既存の API コントラクトを新しい Mule 4 環境に移行します。 **タスクの前提条件** コントラクトを移行する前に、次のロールを持っていることを確認します。 - ルート組織の組織のシステム管理者 - ソース API とのコントラクトがあるすべてのアプリケーションのアプリケーションオーナー Anypoint Platform UI を使用してコントラクトを移行する手順は、次のとおりです。 1. **API Manager**​ > ​**\[Client Applications (クライアントアプリケーション)\]**​ に移動して、アプリケーションを選択します。 **\[Contracts (コントラクト)\]**​ 項目で ​`API`​ オプションが選択されていることを確認します。 2. 右側のナビゲーションで、​**\[Owners (オーナー)\]**​ 項目までスクロールダウンして、自分の名前を追加します。 3. **\[Exchange (交換)\]**​ で、API インスタンスを選択し、アクセス権を要求します。 4. **API Manager**​ で、自分にアクセス権を付与します。 要求承認プロセスを自動化する手順は、次のとおりです。 1. アプリケーションのオーナーを追加します。 ```text curl 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations//applications//owners' \ -H 'Content-Type: application/json;charset=UTF-8' \ -H 'Authorization: Bearer ' \ --data-raw '{"id":"/applications//contracts' \ -H 'authorization: bearer ' \ -H 'content-type: application/json' \ --data-raw '{"apiId":"","environmentId":"","instanceType":"api","acceptedTerms":true,"organizationId":"","groupId":"","assetId":"","version":"","versionGroup":""}' ``` 3. コントラクトを承認します。 ```text curl 'https://anypoint.mulesoft.com/apimanager/xapi/v1/organizations//environments//apis//contracts//approve' \ -H 'Authorization: Bearer ' \ -H 'Content-Type: application/json;charset=UTF-8' \ --data-raw '{}' ``` ## [](#最新の-mule-3-バージョンへの移行)最新の Mule 3 バージョンへの移行 Mule 4 への移行準備が整っておらず、Mule 3 の最新バージョンに移行する必要がある場合は、​[「Upgrading Mule Runtime Engine(Versions 3.x to 3.n) (Mule Runtime Engine のアップグレード (バージョン 3.x から 3.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-versions)​を参照してください。 移行先の Mule バージョンのリリースノートを慎重に確認してください。同じ API インスタンスを参照する同じアプリケーションを使用して新しい Mule Runtime を開始すると、既存の API は最新の Mule 3.x バージョンですぐに管理されます。API Manager で追加の手順を実行する必要はありません。 # API Manager で管理されるアプリケーションの移行 API Manager で管理される既存の Mule 3 アプリケーションを Mule 4 に移行するには、次の手順を使用します。 1. [移行の準備](#prepare-migration) 既存の Mule 3 アプリケーションの設定方法に基づいて、移行を準備するための前提条件を慎重に確認します。 2. [移行方法の決定](#determine-migration-approach) いくつかの要素に基づきます。たとえば、ダウンタイムの確保、適用済みポリシーの削除、コントラクトの移行、移行用インスタンスの作成が移行に必要かどうかに基づきます。 3. [移行の実行](#perform-migration) アプリケーションを移行します。 ## [](#prepare-migration)Mule 3 アプリケーションを移行するための準備 API で管理される既存の Mule 3 アプリケーションを Mule 4 に移行する前に、次のガイドラインを慎重に確認して判断します。 - Mule 3 アプリケーションの管理方法: 基本エンドポイント、インテグレーションアプリケーション、または複雑なプロキシ このシナリオでアプリケーションを移行するには、まず ​[API ゲートウェイの移行方法を確認](https://docs.mulesoft.com/mule-runtime/latest/)​して準備を整えてから、​[Mule 4 に移行します](https://docs.mulesoft.com/mule-runtime/latest/)​。 - アプリケーションの保護方法: デフォルトポリシーまたはカスタムポリシー カスタムポリシーを Mule 3 API に適用している場合、​[「API ポリシーの移行」](https://docs.mulesoft.com/mule-runtime/latest/)​に従います。標準プロキシを適用している場合、API Manager UI を使用してプロキシを再作成できます。 - API を分類しているかどうか API を分類していない場合、まず ​[API インスタンスを環境に分類します](https://docs.mulesoft.com/jp/api-manager/latest/classify-api-task)​。 ## [](#determine-migration-approach)移行方法の決定 API Manager で管理される Mule 3 アプリケーションを移行するには、新しい API インスタンスを作成します。Mule 4 に移行する前に、次の要素を慎重に考慮して、要件に最も適した方法を決定します。
移行要素 API インスタンスの作成

ダウンタイムが必要

いいえ

適用済みポリシーの削除が必要

いいえ

コントラクトの移行が必要

はい

API インスタンスで API メトリクスを継続

いいえ
## [](#perform-migration)移行の実行 次のインスタンスを使用して、Mule 3 アプリケーションを移行できます。 - [新しい API インスタンス](#migrate-with-new-api) ### [](#migrate-with-new-api)新しい API インスタンスを使用した移行 次の図に示された提案の概要を参照し、新しい API インスタンスを使用して、Mule 4 上で独立した Mule Runtime インスタンスを設定します。 ![new instance migration mule4](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/new-instance-migration-mule4.png) Mule アプリケーションがプロキシではない場合、この同じ提案が移行手順に適用されます (ただし、バックエンドコンポーネントはありません)。 新しい API インスタンスを使用して Mule 3 API を Mule 4 に移行する手順は、次のとおりです。 1. API Manager の ​**\[API Administration (API 管理)\]**​ ページで、​**\[Manage API (API を管理)\]**​ > ​**\[Create new API (新しい API を作成)\]**​ を選択します。 インスタンスの表示ラベルを使用してこの新しい API インスタンスを識別します。 2. **\[Endpoint Configuration (エンドポイント設定)\]**​ ウィンドウの ​**\[Mule version (Mule バージョン)\]**​ で ​`Mule 4`​ を選択し、保存します。 3. API Manager の左側のナビゲーションペインで、アラート、SLA 階層、ポリシーを API に適用します。 4. API でコントラクトベースのポリシー (クライアント ID 適用ポリシーなど) を使用している場合、API インスタンスの​[コントラクトを移行します](#migrate-contracts)​。 5. API の設定が完了している場合は、Mule 4 アプリケーションを開始して、要求を送信します。 6. アプリケーションの検証が正常に終了したら、Mule 3 アプリケーションをアンデプロイします。 ### [](#migrate-contracts)コントラクトの移行 新しい API インスタンスを作成してアプリケーションを移行する前に、既存の API コントラクトを新しい Mule 4 環境に移行します。 **タスクの前提条件** コントラクトを移行する前に、次のロールを持っていることを確認します。 - ルート組織の組織のシステム管理者 - ソース API とのコントラクトがあるすべてのアプリケーションのアプリケーションオーナー Anypoint Platform UI を使用してコントラクトを移行する手順は、次のとおりです。 1. **API Manager**​ > ​**\[Client Applications (クライアントアプリケーション)\]**​ に移動して、アプリケーションを選択します。 **\[Contracts (コントラクト)\]**​ 項目で ​`API`​ オプションが選択されていることを確認します。 2. 右側のナビゲーションで、​**\[Owners (オーナー)\]**​ 項目までスクロールダウンして、自分の名前を追加します。 3. **\[Exchange (交換)\]**​ で、API インスタンスを選択し、アクセス権を要求します。 4. **API Manager**​ で、自分にアクセス権を付与します。 要求承認プロセスを自動化する手順は、次のとおりです。 1. アプリケーションのオーナーを追加します。 ```text curl 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations//applications//owners' \ -H 'Content-Type: application/json;charset=UTF-8' \ -H 'Authorization: Bearer ' \ --data-raw '{"id":"/applications//contracts' \ -H 'authorization: bearer ' \ -H 'content-type: application/json' \ --data-raw '{"apiId":"","environmentId":"","instanceType":"api","acceptedTerms":true,"organizationId":"","groupId":"","assetId":"","version":"","versionGroup":""}' ``` 3. コントラクトを承認します。 ```text curl 'https://anypoint.mulesoft.com/apimanager/xapi/v1/organizations//environments//apis//contracts//approve' \ -H 'Authorization: Bearer ' \ -H 'Content-Type: application/json;charset=UTF-8' \ --data-raw '{}' ``` ## [](#最新の-mule-3-バージョンへの移行)最新の Mule 3 バージョンへの移行 Mule 4 への移行準備が整っておらず、Mule 3 の最新バージョンに移行する必要がある場合は、​[「Upgrading Mule Runtime Engine(Versions 3.x to 3.n) (Mule Runtime Engine のアップグレード (バージョン 3.x から 3.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-versions)​を参照してください。 移行先の Mule バージョンのリリースノートを慎重に確認してください。同じ API インスタンスを参照する同じアプリケーションを使用して新しい Mule Runtime を開始すると、既存の API は最新の Mule 3.x バージョンですぐに管理されます。API Manager で追加の手順を実行する必要はありません。 # API Manager で管理されるアプリケーションの移行 API Manager で管理される既存の Mule 3 アプリケーションを Mule 4 に移行するには、次の手順を使用します。 1. [移行の準備](#prepare-migration) 既存の Mule 3 アプリケーションの設定方法に基づいて、移行を準備するための前提条件を慎重に確認します。 2. [移行方法の決定](#determine-migration-approach) いくつかの要素に基づきます。たとえば、ダウンタイムの確保、適用済みポリシーの削除、コントラクトの移行、移行用インスタンスの作成が移行に必要かどうかに基づきます。 3. [移行の実行](#perform-migration) アプリケーションを移行します。 ## [](#prepare-migration)Mule 3 アプリケーションを移行するための準備 API で管理される既存の Mule 3 アプリケーションを Mule 4 に移行する前に、次のガイドラインを慎重に確認して判断します。 - Mule 3 アプリケーションの管理方法: 基本エンドポイント、インテグレーションアプリケーション、または複雑なプロキシ このシナリオでアプリケーションを移行するには、まず ​[API ゲートウェイの移行方法を確認](https://docs.mulesoft.com/mule-runtime/latest/)​して準備を整えてから、​[Mule 4 に移行](https://docs.mulesoft.com/mule-runtime/latest/)​します。 - アプリケーションの保護方法: デフォルトポリシーまたはカスタムポリシー カスタムポリシーを Mule 3 API に適用している場合、​[「API ポリシーの移行」](https://docs.mulesoft.com/mule-runtime/latest/)​に従います。標準プロキシを適用している場合、API Manager UI を使用してプロキシを再作成できます。 - API を分類しているかどうか API を分類していない場合、まず ​[API インスタンスを環境に分類します](https://docs.mulesoft.com/jp/api-manager/latest/classify-api-task)​。 ## [](#determine-migration-approach)移行方法の決定 API Manager で管理される Mule 3 アプリケーションを移行するには、新しい API インスタンスを作成します。Mule 4 に移行する前に、次の要素を慎重に考慮して、要件に最も適した方法を決定します。
移行要素 API インスタンスの作成

ダウンタイムが必要

いいえ

適用済みポリシーの削除が必要

いいえ

コントラクトの移行が必要

はい

API インスタンスで API メトリクスを継続

いいえ
## [](#perform-migration)移行の実行 次のインスタンスを使用して、Mule 3 アプリケーションを移行できます。 - [新しい API インスタンス](#migrate-with-new-api) ### [](#migrate-with-new-api)新しい API インスタンスを使用した移行 次の図に示された提案の概要を参照し、新しい API インスタンスを使用して、Mule 4 上で独立した Mule Runtime インスタンスを設定します。 ![プロキシやロードバランサーなどのコンポーネントが含まれる、Mule 3 から Mule 4 への移行が表示されている図](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/new-instance-migration-mule4.png) Mule アプリケーションがプロキシではない場合、この同じ提案が移行手順に適用されます (ただし、バックエンドコンポーネントはありません)。 新しい API インスタンスを使用して Mule 3 API を Mule 4 に移行する手順は、次のとおりです。 1. API Manager の ​**\[API Administration (API 管理)\]**​ ページで、​**\[Manage API (API を管理)\]**​ > ​**\[Create new API (新しい API を作成)\]**​ を選択します。 インスタンスの表示ラベルを使用してこの新しい API インスタンスを識別します。 2. **\[Endpoint Configuration (エンドポイント設定)\]**​ ウィンドウの ​**\[Mule version (Mule バージョン)\]**​ で ​`Mule 4`​ を選択し、保存します。 3. API Manager の左側のナビゲーションペインで、アラート、SLA 階層、ポリシーを API に適用します。 4. API でコントラクトベースのポリシー (クライアント ID 適用ポリシーなど) を使用している場合、API インスタンスの​[コントラクトを移行します](#migrate-contracts)​。 5. API の設定が完了している場合は、Mule 4 アプリケーションを開始して、要求を送信します。 6. アプリケーションの検証が正常に終了したら、Mule 3 アプリケーションをアンデプロイします。 ### [](#migrate-contracts)コントラクトの移行 新しい API インスタンスを作成してアプリケーションを移行する前に、既存の API コントラクトを新しい Mule 4 環境に移行します。 **タスクの前提条件** コントラクトを移行する前に、次のロールを持っていることを確認します。 - ルート組織の組織のシステム管理者 - ソース API とのコントラクトがあるすべてのアプリケーションのアプリケーションオーナー Anypoint Platform UI を使用してコントラクトを移行する手順は、次のとおりです。 1. **API Manager**​ > ​**\[Client Applications (クライアントアプリケーション)\]**​ に移動して、アプリケーションを選択します。 **\[Contracts (コントラクト)\]**​ 項目で ​`API`​ オプションが選択されていることを確認します。 2. 右側のナビゲーションで、​**\[Owners (オーナー)\]**​ 項目までスクロールダウンして、自分の名前を追加します。 3. **\[Exchange (交換)\]**​ で、API インスタンスを選択し、アクセス権を要求します。 4. **API Manager**​ で、自分にアクセス権を付与します。 要求承認プロセスを自動化する手順は、次のとおりです。 1. アプリケーションのオーナーを追加します。 ```text curl 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations//applications//owners' \ -H 'Content-Type: application/json;charset=UTF-8' \ -H 'Authorization: Bearer ' \ --data-raw '{"id":"/applications//contracts' \ -H 'authorization: bearer ' \ -H 'content-type: application/json' \ --data-raw '{"apiId":"","environmentId":"","instanceType":"api","acceptedTerms":true,"organizationId":"","groupId":"","assetId":"","version":"","versionGroup":""}' ``` 3. コントラクトを承認します。 ```text curl 'https://anypoint.mulesoft.com/apimanager/xapi/v1/organizations//environments//apis//contracts//approve' \ -H 'Authorization: Bearer ' \ -H 'Content-Type: application/json;charset=UTF-8' \ --data-raw '{}' ``` ## [](#最新の-mule-3-バージョンへの移行)最新の Mule 3 バージョンへの移行 Mule 4 への移行準備が整っておらず、Mule 3 の最新バージョンに移行する必要がある場合は、​[「Upgrading Mule Runtime Engine(Versions 3.x to 3.n) (Mule Runtime Engine のアップグレード (バージョン 3.x から 3.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-versions)​を参照してください。 移行先の Mule バージョンのリリースノートを慎重に確認してください。同じ API インスタンスを参照する同じアプリケーションを使用して新しい Mule Runtime を開始すると、既存の API は最新の Mule 3.x バージョンですぐに管理されます。API Manager で追加の手順を実行する必要はありません。 # API Manager で管理されるアプリケーションの移行 API Manager で管理される既存の Mule 3 アプリケーションを Mule 4 に移行するには、次の手順を使用します。 1. [移行の準備](#prepare-migration) 既存の Mule 3 アプリケーションの設定方法に基づいて、移行を準備するための前提条件を慎重に確認します。 2. [移行方法の決定](#determine-migration-approach) いくつかの要素に基づきます。たとえば、ダウンタイムの確保、適用済みポリシーの削除、コントラクトの移行、移行用インスタンスの作成が移行に必要かどうかに基づきます。 3. [移行の実行](#perform-migration) アプリケーションを移行します。 ## [](#prepare-migration)Mule 3 アプリケーションを移行するための準備 API で管理される既存の Mule 3 アプリケーションを Mule 4 に移行する前に、次のガイドラインを慎重に確認して判断します。 - Mule 3 アプリケーションの管理方法: 基本エンドポイント、インテグレーションアプリケーション、または複雑なプロキシ このシナリオでアプリケーションを移行するには、まず ​[API ゲートウェイの移行方法を確認](https://docs.mulesoft.com/mule-runtime/latest/)​して準備を整えてから、​[Mule 4 に移行](https://docs.mulesoft.com/mule-runtime/latest/)​します。 - アプリケーションの保護方法: デフォルトポリシーまたはカスタムポリシー カスタムポリシーを Mule 3 API に適用している場合、​[「API ポリシーの移行」](https://docs.mulesoft.com/mule-runtime/latest/)​に従います。標準プロキシを適用している場合、API Manager UI を使用してプロキシを再作成できます。 - API を分類しているかどうか API を分類していない場合、まず ​[API インスタンスを環境に分類します](https://docs.mulesoft.com/jp/api-manager/latest/classify-api-task)​。 ## [](#determine-migration-approach)移行方法の決定 API Manager で管理される Mule 3 アプリケーションを移行するには、新しい API インスタンスを作成します。Mule 4 に移行する前に、次の要素を慎重に考慮して、要件に最も適した方法を決定します。
移行要素 API インスタンスの作成

ダウンタイムが必要

いいえ

適用済みポリシーの削除が必要

いいえ

コントラクトの移行が必要

はい

API インスタンスで API メトリクスを継続

いいえ
## [](#perform-migration)移行の実行 次のインスタンスを使用して、Mule 3 アプリケーションを移行できます。 - [新しい API インスタンス](#migrate-with-new-api) ### [](#migrate-with-new-api)新しい API インスタンスを使用した移行 次の図に示された提案の概要を参照し、新しい API インスタンスを使用して、Mule 4 上で独立した Mule Runtime インスタンスを設定します。 ![プロキシやロードバランサーなどのコンポーネントが含まれる、Mule 3 から Mule 4 への移行が表示されている図](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/new-instance-migration-mule4.png) Mule アプリケーションがプロキシではない場合、この同じ提案が移行手順に適用されます (ただし、バックエンドコンポーネントはありません)。 新しい API インスタンスを使用して Mule 3 API を Mule 4 に移行する手順は、次のとおりです。 1. API Manager の ​**\[API Administration (API 管理)\]**​ ページで、​**\[Manage API (API を管理)\]**​ > ​**\[Create new API (新しい API を作成)\]**​ を選択します。 インスタンスの表示ラベルを使用してこの新しい API インスタンスを識別します。 2. **\[Endpoint Configuration (エンドポイント設定)\]**​ ウィンドウの ​**\[Mule version (Mule バージョン)\]**​ で ​`Mule 4`​ を選択し、保存します。 3. API Manager の左側のナビゲーションペインで、アラート、SLA 階層、ポリシーを API に適用します。 4. API でコントラクトベースのポリシー (クライアント ID 適用ポリシーなど) を使用している場合、API インスタンスの​[コントラクトを移行します](#migrate-contracts)​。 5. API の設定が完了している場合は、Mule 4 アプリケーションを開始して、要求を送信します。 6. アプリケーションの検証が正常に終了したら、Mule 3 アプリケーションをアンデプロイします。 ### [](#migrate-contracts)コントラクトの移行 新しい API インスタンスを作成してアプリケーションを移行する前に、既存の API コントラクトを新しい Mule 4 環境に移行します。 **タスクの前提条件** コントラクトを移行する前に、次のロールを持っていることを確認します。 - ルート組織の組織のシステム管理者 - ソース API とのコントラクトがあるすべてのアプリケーションのアプリケーションオーナー Anypoint Platform UI を使用してコントラクトを移行する手順は、次のとおりです。 1. **API Manager**​ > ​**\[Client Applications (クライアントアプリケーション)\]**​ に移動して、アプリケーションを選択します。 **\[Contracts (コントラクト)\]**​ 項目で ​`API`​ オプションが選択されていることを確認します。 2. 右側のナビゲーションで、​**\[Owners (オーナー)\]**​ 項目までスクロールダウンして、自分の名前を追加します。 3. **\[Exchange (交換)\]**​ で、API インスタンスを選択し、アクセス権を要求します。 4. **API Manager**​ で、自分にアクセス権を付与します。 要求承認プロセスを自動化する手順は、次のとおりです。 1. アプリケーションのオーナーを追加します。 ```text curl 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations//applications//owners' \ -H 'Content-Type: application/json;charset=UTF-8' \ -H 'Authorization: Bearer ' \ --data-raw '{"id":"/applications//contracts' \ -H 'authorization: bearer ' \ -H 'content-type: application/json' \ --data-raw '{"apiId":"","environmentId":"","instanceType":"api","acceptedTerms":true,"organizationId":"","groupId":"","assetId":"","version":"","versionGroup":""}' ``` 3. コントラクトを承認します。 ```text curl 'https://anypoint.mulesoft.com/apimanager/xapi/v1/organizations//environments//apis//contracts//approve' \ -H 'Authorization: Bearer ' \ -H 'Content-Type: application/json;charset=UTF-8' \ --data-raw '{}' ``` ## [](#最新の-mule-3-バージョンへの移行)最新の Mule 3 バージョンへの移行 Mule 4 への移行準備が整っておらず、Mule 3 の最新バージョンに移行する必要がある場合は、​[「Upgrading Mule Runtime Engine(Versions 3.x to 3.n) (Mule Runtime Engine のアップグレード (バージョン 3.x から 3.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-versions)​を参照してください。 移行先の Mule バージョンのリリースノートを慎重に確認してください。同じ API インスタンスを参照する同じアプリケーションを使用して新しい Mule Runtime を開始すると、既存の API は最新の Mule 3.x バージョンですぐに管理されます。API Manager で追加の手順を実行する必要はありません。 # API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。SOAP または REST API からデータをコンシュームするには、以下のプロセスを参照してください。 ## [](#soap-api-からのデータのコンシューム)SOAP API からのデータのコンシューム 独自の Anypoint Connector を持たない SOAP API からデータをコンシュームするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を設定します。 コネクタは API の WSDL ファイルから取得したホスト、ポート、およびアドレスメタデータを使用して、Mule アプリケーション内からサービスをコンシュームするために必要な接続設定を提供します。 詳細は、​[「Web Service Consumer Connector」](https://docs.mulesoft.com/web-service-consumer-connector/latest/)​を参照してください。 ## [](#rest-api-からのデータのコンシューム)REST API からのデータのコンシューム 以下のプロセスでは、REST API をコールするための HTTP Request Connector の設定に焦点が当てられています。これは、Mule アプリケーションが REST API をコンシュームする方法の基本構造、必要な最小限の設定、コンシューム方法の例、動的要求の設定方法、HTTP Content-Type とエンコードの管理方法、カスタムヘッダーの操作方法、およびセキュリティ要件を理解するのに役立ちます。 Mule アプリケーション内で REST API からデータをコンシュームするには、HTTP 要求用 Anypoint Connector (HTTP Request Connector) を設定できます。 同じ REST API に何度も接続したり、複雑な認証プロトコルを持つ API を使用したりする場合は、​[Mule SDK を使用して独自のコネクタを開発](https://docs.mulesoft.com/mule-sdk/latest/)​することを考慮してください。接続先の API のコネクタが [Anypoint Exchange](https://anypoint.mulesoft.com/exchange/)​ にすでに存在するかどうかを確認します。Anypoint Studio の \[Mule Palette (Mule パレット)\] を使用して Exchange 内を検索できます。 ## [](#基本構造)基本構造 REST API をコンシュームする Mule アプリケーションは次の要素で構成されます。 - 要求をビルドするように設定された 1 つ以上のメッセージプロセッサー - REST API をコールするように設定された HTTP Request 操作 - 応答を受け入れて処理するように設定された 1 つ以上のメッセージプロセッサー ![REST API のコンシュームフロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-consume-rest-api-flow.png) Figure 1. REST API のコンシュームフロー。 要求をビルドするアプリケーションの部分と応答を処理するアプリケーションの部分を設定します。 ## [](#最小限の設定)最小限の設定 コンシュームする REST API には、その API を記述する [RAML](http://raml.org)​ ファイルが必要です。これにより、HTTP Connector はスマート提案をユーザーにあらかじめ提供できます。 RAML ファイルでは、以下を定義します。 - Authentication (認証) - アウトバウンド HTTP エンドポイントを設定するためのベース URI - Scope (スコープ) アプリケーションは認証ログイン情報に基づいて、たとえば、コールを特定のリソースの GET 要求のみに制限したり、リソースへのアクセスを制限したりできます。 - リソース アウトバウンド HTTP エンドポイントのリソースのパスを設定する必要があります。 - メソッド POST を HTTP アウトバウンドエンドポイントのデフォルトメソッドとして受け入れたり、そのデフォルトを、リソースでサポートされているメソッドに変更したりできます。 - Input validation (入力規則) 通常、POST および PUT コールの場合、API は、入力形式 (JSON、XML など) がそのスキーマに一致していることを要求します。 Mule Runtime Engine で、以下を定義または設定できます。 - Output format (出力形式) HTTP Request 操作の後、メッセージプロセッサーをフローに含めて、フローで API からの応答を受け入れて使用可能な形式に変換する必要があります。 - Redirect (リダイレクト) API でリダイレクトを使用する場合、HTTP Request 操作でリダイレクトを有効にします。 - Timeout (タイムアウト) - Headers for methods (メソッドのヘッダー) ほとんどの場合、POST、PUT、DELETE 要求にはヘッダーが必要です。 - URI およびクエリパラメーター - エラー処理 要求操作の設定方法についての詳細は、​[HTTP Connector のドキュメント](https://docs.mulesoft.com/http-connector/latest/#input-sources)​を参照してください。 ### [](#rest-api-のコンシュームの例)REST API のコンシュームの例 次の例では、 [JSONPlaceholder API](https://jsonplaceholder.typicode.com/todos/1)​ をコンシュームします。この例には、HTTP Request Connector の設定のみが示されています。これを正常に機能させるには、フロー内でメッセージをトリガーする 1 つ以上のメッセージソースと、応答を受け入れる 1 つ以上のメッセージプロセッサーを設定する必要があります。詳細は、​[「REST API の例」](https://docs.mulesoft.com/jp/mule-runtime/4.3/rest-api-examples)​のドキュメントを参照してください。 この API の例について説明します。 - この API は認証を必要としません。 - ベース URL は ​`jsonplaceholder.typicode.com`​ です。 - この API は開発目的のモック API です。 - `id=1`​ のユーザーに関する情報を取得するには要求が次のようになっている必要があることをこのサンプル API 要求は示しています。 https://jsonplaceholder.typicode.com/users/1 URL の各部は次のとおりです。 - Protocol (プロトコル): `http` - API Base URL (API のベース URL): `jsonplaceholder.typicode.com` - Resource path (リソースパス): `/users/1` - Query Parameters (クエリパラメーター): この場合は \[None (なし)\]。 このコールを Mule アプリケーションに実装するには、HTTP Request 操作を設定します。 ### [](#anypoint-studio-での-http-request-操作の設定)Anypoint Studio での HTTP Request 操作の設定 1. Studio の \[Mule Palette (Mule パレット)\] から、HTTP Request Connector をアプリケーションに追加します。 2. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、​**\[Host (ホスト)\]**​ の値として ​`jsonplaceholder.typicode.com`​ を指定します。 3. **\[Port (ポート)\]**​ の値を 80 に設定します。 4. **\[OK\]**​ をクリックします。 ![「Host (ホスト)」 と 「Port (ポート)」 を含む 「HTTP Request configuration (HTTP 要求設定)\]](_images/mruntime-consume-rest-api-configuration-1.png) Figure 2. \[Host (ホスト)\] と \[Port (ポート)\] を含む \[HTTP Request configuration (HTTP 要求設定)\]。 1. HTTP Request 操作のプロパティエディター > \[General (一般)\] タブから \[Request (要求)\] セクションに移動して、​**\[Path (パス)\]**​ 項目に ​`/users/1`​ を追加します。 最初のステップでホストを指定することで識別を開始した URL は、このパスの指定により完了します。 1. **\[Method (メソッド)\]**​ ドロップダウンリストからメソッドを選択します (この例では ​`GET`​)。 2. アプリケーションを保存します。 ![HTTP 要求の GET メソッドとパス](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-consume-rest-api-configuration-2.png) Figure 3. HTTP 要求の GET メソッドとパス。 ### [](#xml-での-http-request-操作の設定)XML での HTTP Request 操作の設定 次の XML コードは、例の HTTP Request 操作の設定を示しています。 ```xml <...> ``` ### [](#json-応答の例)JSON 応答の例 JSONPlaceholder API の例の JSON 応答の構造は次のとおりです。 ```json { "userId": 1, "id": 3, "title": "fugiat veniam minus", "completed": false } ``` HTTP Request 操作の ​**\[Advanced (詳細)\]**​ タブでデータを変換できます。また、対象変数を定義することもできます (デフォルトは \[Payload (ペイロード)\])。 この API に RAML ファイルが関連付けられている場合、その RAML ファイルをコネクタの設定要素で参照できます。これを設定し、コールする動詞とアセットを選択したら、Studio は出力に対応するメタデータを公開します。フローの他の要素とのインテグレーションが簡略化されます。 ## [](#dataweave-式を使用した動的要求の設定)DataWeave 式を使用した動的要求の設定 ほとんどのユースケースで、API へのコールをメッセージのデータに基づいて動的に変更することが求められます。この動的要求は、DataWeave 式を使用して設定できます。 「REST API のコンシュームの例」に記載されている設定例では、要求は URL 内でハードコード化されていました。 https://jsonplaceholder.typicode.com/users/1 次の GET 要求の例では、コールは、DataWeave 式 ​`#[payload.user_id]`​ を使用してメッセージのペイロードからユーザー ID を抽出するように Mule Runtime Engine に指示しています。 https://jsonplaceholder.typicode.com/users/#\[payload.user\_id\] ### [](#anypoint-studio-での動的要求の設定)Anypoint Studio での動的要求の設定 Anypoint Studio を使用して同じ操作を実行するには、目的の DataWeave 式 (この場合は ​`#['/users/' ++ payload.user_id]`​) を使用してパス設定を変更します。 ![「Path (パス)」 項目で DataWeave 式を使用して動的要求を設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-consume-rest-api-configuration-3.png) Figure 4. \[Path (パス)\] 項目で DataWeave 式を使用して動的要求を設定。 クエリパラメーター、URI パラメーター、または HTTP メソッドでも動的要求を設定できます。 また、​[設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties)​を使用して、このいずれかの動的要求を設定することもできます。 ### [](#xml-での動的要求の設定)XML での動的要求の設定 次の XML 形式のサンプルコードは、動的要求の設定を示しています。 ```xml <...> ``` ## [](#http-content-type-およびエンコード)HTTP Content-Type およびエンコード POST 要求を送信すると、Mule Runtime Engine は、本文の Content-Type とエンコードに関する次のルールに従います。

Content (コンテンツ)

ルール

String​、​char[]`​、​Reader​ または同様のコンテンツ*

* エンドポイントでエンコードが明示的に設定されている場合、Mule Runtime Engine はそのエンコードを使用します。 * エンドポイントでエンコードが明示的に設定されていない場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ からエンコードを決定します。 * Content-Type​ メッセージプロパティが設定されていない場合、Mule Runtime Engine は Mule コンテキストのデフォルト設定を使用します。 * Content-Type​ の場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ を送信しますが、実際のエンコードが設定されます。

バイナリコンテンツ

エンコードは関連しません。Mule Runtime Engine は ​Content-Type​ を次のように設定します。

  • Content-Type​ プロパティがメッセージで設定されている場合、Mule Runtime Engine は、定義されているコンテンツタイプを使用します。

  • Content-Type​ プロパティがメッセージで設定されていない場合、Mule Runtime Engine は「application/octet-stream」を ​Content-Type​ として設定します。
## [](#カスタムヘッダー)カスタムヘッダー API によっては、要求と共にカスタムヘッダー (開発者キーなど) を渡す必要があります。クエリパラメーターと同様に、HTTP Connector でヘッダーを要求に追加できます。 たとえば、コンシュームしている API が開発者キーを必要とする場合、ヘッダー名 ​`accessKey`​ を使用して、そのキーを要求のヘッダーとして指定します。 Anypoint Studio を使用して、プロパティを追加してカスタムヘッダーを設定できます。 ### [](#anypoint-studio-でのカスタムヘッダー)Anypoint Studio でのカスタムヘッダー Studio でカスタムヘッダーを設定するには、次の手順を参照してください。 - HTTP Request 操作のプロパティエディターで、​**\[Headers (ヘッダー)\]**​ タブを選択します。 - **\[Add (追加)\]**​ をクリックします。 - **\[Name (名前)\]**​ と ​**\[Value (値)\]**​ を定義します。どちらも、式またはプロパティプレースホルダーを使用して定義できます。 ![Studio でのカスタムヘッダーの設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-consume-rest-api-configuration-4.png) Figure 5. HTTP Request 操作のプロパティエディターで、\[Custom Headers (カスタムヘッダー)\] を設定します。 ## [](#セキュリティ要件)セキュリティ要件 コールしている API が複雑な認証プロトコルを必要とする場合、独自のコネクタをビルドしてその API をコンシュームできます。それ以外の場合は、基本認証ログイン情報を設定するか、グローバル HTTPS Connector を設定して、API のセキュリティ要件を満たすことができます。 ### [](#基本認証)基本認証 コールしている REST API が基本認証ログイン情報の提供を要求する場合、アウトバウンド HTTP エンドポイントの設定内で基本認証ログイン情報を指定できます。 1. Studio で \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[Authentication (認証)\] で ​**\[Basic Authentication (基本認証)\]**​ を選択します。 3. ユーザー名とパスワードを入力します。これらをプロパティプレースホルダーとして設定することもできます。 4. **\[OK\]**​ をクリックします。 ![mruntime consume rest api configuration 7](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-consume-rest-api-configuration-7.png) ### [](#https-設定)HTTPS 設定 コンシュームしている REST API が、HTTPS を介して受信要求が到着することを要求する場合、Mule アプリケーションでグローバル HTTPS 要求コネクタを設定し、そのコネクタを要求操作で参照できます。 次の例では、HTTPS 要求コネクタを設定し、Java キーストアファイル (JKS) を作成し、​[TLS を設定します](https://docs.mulesoft.com/jp/mule-runtime/4.3/tls-configuration)​。 #### [](#https-用-http-request-connector-の設定)HTTPS 用 HTTP Request Connector の設定 1. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、\[General (一般)\] タブ > \[Connection Configuration (接続設定)\] セクションに移動します。 2. **\[Protocol (プロトコル)\]**​ で ​**\[HTTPS\]**​ を選択します。 3. **\[OK\]**​ をクリックします。 ![HTTPS 要求コネクタの設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-consume-rest-api-configuration-5.png) Figure 6. HTTPS 要求コネクタの設定。 #### [](#キーストアファイルの作成)キーストアファイルの作成 Java インストールの bin ディレクトリにある Java keytool を使用して、通信を認証するためのキーストアファイルを作成します。 1. コマンドラインを使用して、使用しているマシンの Java インストールディレクトリに移動します。 2. 次のコマンドを実行します。 keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks 1. 2 つのパスワードを作成するように促されたら作成し、後で使用するために覚えておきます。 このアクションにより、​`keystore.jks`​ という名前の ​`jks`​ ファイルがローカルディレクトリに作成されます。 2. `keystore.jks`​ ファイルを配置します。 - Studio を使用する場合、​`keystore.jks`​ ファイルを Studio の Package Explorer の ​`appname/src/main/resources`​ ディレクトリに配置します。 - Mule Runtime Engine で XML を使用し、ファイルを複数のアプリケーションで使用する場合、​`MULE_HOME/conf`​ ディレクトリにファイルを配置します。 - Mule Runtime Engine で XML を使用し、ファイルをこのアプリケーション内で使用する場合、​`yourappname/src/main/resources`​ ディレクトリにファイルを配置します。 1. グローバル HTTPS 要求コネクタでキーストアを参照します。 次に、このコネクタはフロー内で HTTP アウトバウンドエンドポイントにより参照されます。 #### [](#tls-を設定する)TLS を設定する 以下の手順に従って、TLS を設定します。 1. Studio で、\[Global Elements (グローバル要素)\] ビューに移動します。 2. **\[Create (作成)\]**​ を選択し、「TLS Context (TLS コンテキスト)」を検索します。 3. \[Key Store Configuration (キーストア設定)\] セクションで、キーストア設定の \[Type (種別)\] をドロップダウンメニューから選択します。たとえば、デフォルトの種別である ​**\[JKS\]**​ (Java キーストア) を選択します。 4. キーストアを ​`appname/src/main/resources`​ ディレクトリに配置している場合は、​**\[Path (パス)\]**​ にキーストアの名前を指定し、それ以外の場合は ​`"/keystore.jks"`​ を指定します。 5. **\[Key Password (キーパスワード)\]**​ と ​**\[Password (パスワード)\]**​ には、キーストアファイルの作成時に作成したパスワードを入力します。 6. **\[OK\]**​ をクリックします。 ![TLS を設定する](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-consume-rest-api-configuration-6.png) Figure 7. TLS を設定します。 1. \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[TLS Configuration (TLS 設定)\] で ​**\[Global Reference (グローバル参照)\]**​ と、以前作成した ​**\[TLS context (TLS コンテキスト)\]**​ 値を選択します。 TLS コンテキストはインラインで作成することもできます。 ![HTTP 要求設定での TLS の設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-consume-rest-api-configuration-8.png) Figure 8. HTTP 要求設定での TLS の設定。 # API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。SOAP または REST API からデータをコンシュームするには、以下のプロセスを参照してください。 ## [](#soap-api-からのデータのコンシューム)SOAP API からのデータのコンシューム 独自の Anypoint Connector を持たない SOAP API からデータをコンシュームするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を設定します。 コネクタは API の WSDL ファイルから取得したホスト、ポート、およびアドレスメタデータを使用して、Mule アプリケーション内からサービスをコンシュームするために必要な接続設定を提供します。 詳細は、​[「Web Service Consumer Connector」](https://docs.mulesoft.com/web-service-consumer-connector/latest/)​を参照してください。 ## [](#rest-api-からのデータのコンシューム)REST API からのデータのコンシューム 以下のプロセスでは、REST API をコールするための HTTP Request Connector の設定に焦点が当てられています。これは、Mule アプリケーションが REST API をコンシュームする方法の基本構造、必要な最小限の設定、コンシューム方法の例、動的要求の設定方法、HTTP Content-Type とエンコードの管理方法、カスタムヘッダーの操作方法、およびセキュリティ要件を理解するのに役立ちます。 Mule アプリケーション内で REST API からデータをコンシュームするには、HTTP 要求用 Anypoint Connector (HTTP Request Connector) を設定できます。 同じ REST API に何度も接続したり、複雑な認証プロトコルを持つ API を使用したりする場合は、​[Mule SDK を使用して独自のコネクタを開発](https://docs.mulesoft.com/mule-sdk/latest/)​することを考慮してください。接続先の API のコネクタが [Anypoint Exchange](https://anypoint.mulesoft.com/exchange/)​ にすでに存在するかどうかを確認します。Anypoint Studio の \[Mule Palette (Mule パレット)\] を使用して Exchange 内を検索できます。 ## [](#基本構造)基本構造 REST API をコンシュームする Mule アプリケーションは次の要素で構成されます。 - 要求をビルドするように設定された 1 つ以上のメッセージプロセッサー - REST API をコールするように設定された HTTP Request 操作 - 応答を受け入れて処理するように設定された 1 つ以上のメッセージプロセッサー ![REST API のコンシュームフロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-consume-rest-api-flow.png) Figure 1. REST API のコンシュームフロー。 要求をビルドするアプリケーションの部分と応答を処理するアプリケーションの部分を設定します。 ## [](#最小限の設定)最小限の設定 コンシュームする REST API には、その API を記述する [RAML](http://raml.org)​ ファイルが必要です。これにより、HTTP Connector はスマート提案をユーザーにあらかじめ提供できます。 RAML ファイルでは、以下を定義します。 - Authentication (認証) - アウトバウンド HTTP エンドポイントを設定するためのベース URI - Scope (スコープ) アプリケーションは認証ログイン情報に基づいて、たとえば、コールを特定のリソースの GET 要求のみに制限したり、リソースへのアクセスを制限したりできます。 - リソース アウトバウンド HTTP エンドポイントのリソースのパスを設定する必要があります。 - メソッド POST を HTTP アウトバウンドエンドポイントのデフォルトメソッドとして受け入れたり、そのデフォルトを、リソースでサポートされているメソッドに変更したりできます。 - Input validation (入力規則) 通常、POST および PUT コールの場合、API は、入力形式 (JSON、XML など) がそのスキーマに一致していることを要求します。 Mule Runtime Engine で、以下を定義または設定できます。 - Output format (出力形式) HTTP Request 操作の後、メッセージプロセッサーをフローに含めて、フローで API からの応答を受け入れて使用可能な形式に変換する必要があります。 - Redirect (リダイレクト) API でリダイレクトを使用する場合、HTTP Request 操作でリダイレクトを有効にします。 - Timeout (タイムアウト) - Headers for methods (メソッドのヘッダー) ほとんどの場合、POST、PUT、DELETE 要求にはヘッダーが必要です。 - URI およびクエリパラメーター - エラー処理 要求操作の設定方法についての詳細は、​[HTTP Connector のドキュメント](https://docs.mulesoft.com/http-connector/latest/#input-sources)​を参照してください。 ### [](#rest-api-のコンシュームの例)REST API のコンシュームの例 次の例では、 [JSONPlaceholder API](https://jsonplaceholder.typicode.com/todos/1)​ をコンシュームします。この例には、HTTP Request Connector の設定のみが示されています。これを正常に機能させるには、フロー内でメッセージをトリガーする 1 つ以上の Mule イベントソースと、応答を受け入れる 1 つ以上のメッセージプロセッサーを設定する必要があります。詳細は、​[「REST API の例」](https://docs.mulesoft.com/jp/mule-runtime/4.4/rest-api-examples)​のドキュメントを参照してください。 この API の例について説明します。 - この API は認証を必要としません。 - ベース URL は ​`jsonplaceholder.typicode.com`​ です。 - この API は開発目的のモック API です。 - `id=1`​ のユーザーに関する情報を取得するには要求が次のようになっている必要があることをこのサンプル API 要求は示しています。 https://jsonplaceholder.typicode.com/users/1 URL の各部は次のとおりです。 - Protocol (プロトコル): `http` - API Base URL (API のベース URL): `jsonplaceholder.typicode.com` - Resource path (リソースパス): `/users/1` - Query Parameters (クエリパラメーター): この場合は \[None (なし)\]。 このコールを Mule アプリケーションに実装するには、HTTP Request 操作を設定します。 ### [](#anypoint-studio-での-http-request-操作の設定)Anypoint Studio での HTTP Request 操作の設定 1. Studio の \[Mule Palette (Mule パレット)\] から、HTTP Request Connector をアプリケーションに追加します。 2. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、​**\[Host (ホスト)\]**​ の値として ​`jsonplaceholder.typicode.com`​ を指定します。 3. **\[Port (ポート)\]**​ の値を 80 に設定します。 4. **\[OK\]**​ をクリックします。 ![「Host (ホスト)」 と 「Port (ポート)」 を含む 「HTTP Request configuration (HTTP 要求設定)\]](_images/mruntime-consume-rest-api-configuration-1.png) Figure 2. \[Host (ホスト)\] と \[Port (ポート)\] を含む \[HTTP Request configuration (HTTP 要求設定)\]。 1. HTTP Request 操作のプロパティエディター > \[General (一般)\] タブから \[Request (要求)\] セクションに移動して、​**\[Path (パス)\]**​ 項目に ​`/users/1`​ を追加します。 最初のステップでホストを指定することで識別を開始した URL は、このパスの指定により完了します。 1. **\[Method (メソッド)\]**​ ドロップダウンリストからメソッドを選択します (この例では ​`GET`​)。 2. アプリケーションを保存します。 ![HTTP 要求の GET メソッドとパス](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-consume-rest-api-configuration-2.png) Figure 3. HTTP 要求の GET メソッドとパス。 ### [](#xml-での-http-request-操作の設定)XML での HTTP Request 操作の設定 次の XML コードは、例の HTTP Request 操作の設定を示しています。 ```xml <...> ``` ### [](#json-応答の例)JSON 応答の例 JSONPlaceholder API の例の JSON 応答の構造は次のとおりです。 ```json { "userId": 1, "id": 3, "title": "fugiat veniam minus", "completed": false } ``` HTTP Request 操作の ​**\[Advanced (詳細)\]**​ タブでデータを変換できます。また、対象変数を定義することもできます (デフォルトは \[Payload (ペイロード)\])。 この API に RAML ファイルが関連付けられている場合、その RAML ファイルをコネクタの設定要素で参照できます。これを設定し、コールする動詞とアセットを選択したら、Studio は出力に対応するメタデータを公開します。フローの他の要素とのインテグレーションが簡略化されます。 ## [](#dataweave-式を使用した動的要求の設定)DataWeave 式を使用した動的要求の設定 ほとんどのユースケースで、API へのコールをメッセージのデータに基づいて動的に変更することが求められます。この動的要求は、DataWeave 式を使用して設定できます。 「REST API のコンシュームの例」に記載されている設定例では、要求は URL 内でハードコード化されていました。 https://jsonplaceholder.typicode.com/users/1 次の GET 要求の例では、コールは、DataWeave 式 ​`#[payload.user_id]`​ を使用してメッセージのペイロードからユーザー ID を抽出するように Mule Runtime Engine に指示しています。 https://jsonplaceholder.typicode.com/users/#\[payload.user\_id\] ### [](#anypoint-studio-での動的要求の設定)Anypoint Studio での動的要求の設定 Anypoint Studio を使用して同じ操作を実行するには、目的の DataWeave 式 (この場合は ​`#['/users/' ++ payload.user_id]`​) を使用してパス設定を変更します。 ![「Path (パス)」 項目で DataWeave 式を使用して動的要求を設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-consume-rest-api-configuration-3.png) Figure 4. \[Path (パス)\] 項目で DataWeave 式を使用して動的要求を設定。 クエリパラメーター、URI パラメーター、または HTTP メソッドでも動的要求を設定できます。 また、​[設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties)​を使用して、このいずれかの動的要求を設定することもできます。 ### [](#xml-での動的要求の設定)XML での動的要求の設定 次の XML 形式のサンプルコードは、動的要求の設定を示しています。 ```xml <...> ``` ## [](#http-content-type-およびエンコード)HTTP Content-Type およびエンコード POST 要求を送信すると、Mule Runtime Engine は、本文の Content-Type とエンコードに関する次のルールに従います。

Content (コンテンツ)

ルール

String​、​char[]`​、​Reader​ または同様のコンテンツ*

* エンドポイントでエンコードが明示的に設定されている場合、Mule Runtime Engine はそのエンコードを使用します。 * エンドポイントでエンコードが明示的に設定されていない場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ からエンコードを決定します。 * Content-Type​ メッセージプロパティが設定されていない場合、Mule Runtime Engine は Mule コンテキストのデフォルト設定を使用します。 * Content-Type​ の場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ を送信しますが、実際のエンコードが設定されます。

バイナリコンテンツ

エンコードは関連しません。Mule Runtime Engine は ​Content-Type​ を次のように設定します。

  • Content-Type​ プロパティがメッセージで設定されている場合、Mule Runtime Engine は、定義されているコンテンツタイプを使用します。

  • Content-Type​ プロパティがメッセージで設定されていない場合、Mule Runtime Engine は「application/octet-stream」を ​Content-Type​ として設定します。
## [](#カスタムヘッダー)カスタムヘッダー API によっては、要求と共にカスタムヘッダー (開発者キーなど) を渡す必要があります。クエリパラメーターと同様に、HTTP Connector でヘッダーを要求に追加できます。 たとえば、コンシュームしている API が開発者キーを必要とする場合、ヘッダー名 ​`accessKey`​ を使用して、そのキーを要求のヘッダーとして指定します。 Anypoint Studio を使用して、プロパティを追加してカスタムヘッダーを設定できます。 ### [](#anypoint-studio-でのカスタムヘッダー)Anypoint Studio でのカスタムヘッダー Studio でカスタムヘッダーを設定するには、次の手順を参照してください。 - HTTP Request 操作のプロパティエディターで、​**\[Headers (ヘッダー)\]**​ タブを選択します。 - **\[Add (追加)\]**​ をクリックします。 - **\[Name (名前)\]**​ と ​**\[Value (値)\]**​ を定義します。どちらも、式またはプロパティプレースホルダーを使用して定義できます。 ![Studio でのカスタムヘッダーの設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-consume-rest-api-configuration-4.png) Figure 5. HTTP Request 操作のプロパティエディターで、\[Custom Headers (カスタムヘッダー)\] を設定します。 ## [](#セキュリティ要件)セキュリティ要件 コールしている API が複雑な認証プロトコルを必要とする場合、独自のコネクタをビルドしてその API をコンシュームできます。それ以外の場合は、基本認証ログイン情報を設定するか、グローバル HTTPS Connector を設定して、API のセキュリティ要件を満たすことができます。 ### [](#基本認証)基本認証 コールしている REST API が基本認証ログイン情報の提供を要求する場合、アウトバウンド HTTP エンドポイントの設定内で基本認証ログイン情報を指定できます。 1. Studio で \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[Authentication (認証)\] で ​**\[Basic Authentication (基本認証)\]**​ を選択します。 3. ユーザー名とパスワードを入力します。これらをプロパティプレースホルダーとして設定することもできます。 4. **\[OK\]**​ をクリックします。 ![mruntime consume rest api configuration 7](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-consume-rest-api-configuration-7.png) ### [](#https-設定)HTTPS 設定 コンシュームしている REST API が、HTTPS を介して受信要求が到着することを要求する場合、Mule アプリケーションでグローバル HTTPS 要求コネクタを設定し、そのコネクタを要求操作で参照できます。 次の例では、HTTPS 要求コネクタを設定し、Java キーストアファイル (JKS) を作成し、​[TLS を設定します](https://docs.mulesoft.com/jp/mule-runtime/4.4/tls-configuration)​。 #### [](#https-用-http-request-connector-の設定)HTTPS 用 HTTP Request Connector の設定 1. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、\[General (一般)\] タブ > \[Connection Configuration (接続設定)\] セクションに移動します。 2. **\[Protocol (プロトコル)\]**​ で ​**\[HTTPS\]**​ を選択します。 3. **\[OK\]**​ をクリックします。 ![HTTPS 要求コネクタの設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-consume-rest-api-configuration-5.png) Figure 6. HTTPS 要求コネクタの設定。 #### [](#キーストアファイルの作成)キーストアファイルの作成 Java インストールの bin ディレクトリにある Java keytool を使用して、通信を認証するためのキーストアファイルを作成します。 1. コマンドラインを使用して、使用しているマシンの Java インストールディレクトリに移動します。 2. 次のコマンドを実行します。 keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks 1. 2 つのパスワードを作成するように促されたら作成し、後で使用するために覚えておきます。 このアクションにより、​`keystore.jks`​ という名前の ​`jks`​ ファイルがローカルディレクトリに作成されます。 2. `keystore.jks`​ ファイルを配置します。 - Studio を使用する場合、​`keystore.jks`​ ファイルを Studio の Package Explorer の ​`appname/src/main/resources`​ ディレクトリに配置します。 - Mule Runtime Engine で XML を使用し、ファイルを複数のアプリケーションで使用する場合、​`MULE_HOME/conf`​ ディレクトリにファイルを配置します。 - Mule Runtime Engine で XML を使用し、ファイルをこのアプリケーション内で使用する場合、​`yourappname/src/main/resources`​ ディレクトリにファイルを配置します。 1. グローバル HTTPS 要求コネクタでキーストアを参照します。 次に、このコネクタはフロー内で HTTP アウトバウンドエンドポイントにより参照されます。 #### [](#tls-を設定する)TLS を設定する 以下の手順に従って、TLS を設定します。 1. Studio で、\[Global Elements (グローバル要素)\] ビューに移動します。 2. **\[Create (作成)\]**​ を選択し、「TLS Context (TLS コンテキスト)」を検索します。 3. \[Key Store Configuration (キーストア設定)\] セクションで、キーストア設定の \[Type (種別)\] をドロップダウンメニューから選択します。たとえば、デフォルトの種別である ​**\[JKS\]**​ (Java キーストア) を選択します。 4. キーストアを ​`appname/src/main/resources`​ ディレクトリに配置している場合は、​**\[Path (パス)\]**​ にキーストアの名前を指定し、それ以外の場合は ​`"/keystore.jks"`​ を指定します。 5. **\[Key Password (キーパスワード)\]**​ と ​**\[Password (パスワード)\]**​ には、キーストアファイルの作成時に作成したパスワードを入力します。 6. **\[OK\]**​ をクリックします。 ![TLS を設定する](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-consume-rest-api-configuration-6.png) Figure 7. TLS を設定します。 1. \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[TLS Configuration (TLS 設定)\] で ​**\[Global Reference (グローバル参照)\]**​ と、以前作成した ​**\[TLS context (TLS コンテキスト)\]**​ 値を選択します。 TLS コンテキストはインラインで作成することもできます。 ![HTTP 要求設定での TLS の設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-consume-rest-api-configuration-8.png) Figure 8. HTTP 要求設定での TLS の設定。 # API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。SOAP または REST API からデータをコンシュームするには、以下のプロセスを参照してください。 ## [](#soap-api-からのデータのコンシューム)SOAP API からのデータのコンシューム 独自の Anypoint Connector を持たない SOAP API からデータをコンシュームするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を設定します。 コネクタは API の WSDL ファイルから取得したホスト、ポート、およびアドレスメタデータを使用して、Mule アプリケーション内からサービスをコンシュームするために必要な接続設定を提供します。 詳細は、​[「Web Service Consumer Connector」](https://docs.mulesoft.com/web-service-consumer-connector/latest/)​を参照してください。 ## [](#rest-api-からのデータのコンシューム)REST API からのデータのコンシューム 以下のプロセスでは、REST API をコールするための HTTP Request Connector の設定に焦点が当てられています。これは、Mule アプリケーションが REST API をコンシュームする方法の基本構造、必要な最小限の設定、コンシューム方法の例、動的要求の設定方法、HTTP Content-Type とエンコードの管理方法、カスタムヘッダーの操作方法、およびセキュリティ要件を理解するのに役立ちます。 Mule アプリケーション内で REST API からデータをコンシュームするには、HTTP 要求用 Anypoint Connector (HTTP Request Connector) を設定できます。 同じ REST API に何度も接続したり、複雑な認証プロトコルを持つ API を使用したりする場合は、​[Mule SDK を使用して独自のコネクタを開発](https://docs.mulesoft.com/mule-sdk/latest/)​することを考慮してください。接続先の API のコネクタが [Anypoint Exchange](https://anypoint.mulesoft.com/exchange/)​ にすでに存在するかどうかを確認します。Anypoint Studio の \[Mule Palette (Mule パレット)\] を使用して Exchange 内を検索できます。 ## [](#基本構造)基本構造 REST API をコンシュームする Mule アプリケーションは次の要素で構成されます。 - 要求をビルドするように設定された 1 つ以上のメッセージプロセッサー - REST API をコールするように設定された HTTP Request 操作 - 応答を受け入れて処理するように設定された 1 つ以上のメッセージプロセッサー ![REST API のコンシュームフロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-consume-rest-api-flow.png) Figure 1. REST API のコンシュームフロー。 要求をビルドするアプリケーションの部分と応答を処理するアプリケーションの部分を設定します。 ## [](#最小限の設定)最小限の設定 コンシュームする REST API には、その API を記述する [RAML](http://raml.org)​ ファイルが必要です。これにより、HTTP Connector はスマート提案をユーザーにあらかじめ提供できます。 RAML ファイルでは、以下を定義します。 - 認証 - アウトバウンド HTTP エンドポイントを設定するためのベース URI - Scope (スコープ) アプリケーションは認証ログイン情報に基づいて、たとえば、コールを特定のリソースの GET 要求のみに制限したり、リソースへのアクセスを制限したりできます。 - リソース アウトバウンド HTTP エンドポイントのリソースのパスを設定する必要があります。 - メソッド POST を HTTP アウトバウンドエンドポイントのデフォルトメソッドとして受け入れたり、そのデフォルトを、リソースでサポートされているメソッドに変更したりできます。 - Input validation (入力規則) 通常、POST および PUT コールの場合、API は、入力形式 (JSON、XML など) がそのスキーマに一致していることを要求します。 Mule Runtime Engine で、以下を定義または設定できます。 - Output format (出力形式) HTTP Request 操作の後、メッセージプロセッサーをフローに含めて、フローで API からの応答を受け入れて使用可能な形式に変換する必要があります。 - Redirect (リダイレクト) API でリダイレクトを使用する場合、HTTP Request 操作でリダイレクトを有効にします。 - Timeout (タイムアウト) - Headers for methods (メソッドのヘッダー) ほとんどの場合、POST、PUT、DELETE 要求にはヘッダーが必要です。 - URI およびクエリパラメーター - エラー処理 要求操作の設定方法についての詳細は、​[HTTP Connector のドキュメント](https://docs.mulesoft.com/http-connector/latest/#input-sources)​を参照してください。 ### [](#rest-api-のコンシュームの例)REST API のコンシュームの例 次の例では、 [JSONPlaceholder API](https://jsonplaceholder.typicode.com/todos/1)​ をコンシュームします。この例には、HTTP Request Connector の設定のみが示されています。これを正常に機能させるには、フロー内でメッセージをトリガーする 1 つ以上の Mule イベントソースと、応答を受け入れる 1 つ以上のメッセージプロセッサーを設定する必要があります。詳細は、​[「REST API の例」](https://docs.mulesoft.com/jp/mule-runtime/4.5/rest-api-examples)​のドキュメントを参照してください。 この API の例について説明します。 - この API は認証を必要としません。 - ベース URL は ​`jsonplaceholder.typicode.com`​ です。 - この API は開発目的のモック API です。 - `id=1`​ のユーザーに関する情報を取得するには要求が次のようになっている必要があることをこのサンプル API 要求は示しています。 https://jsonplaceholder.typicode.com/users/1 URL の各部は次のとおりです。 - Protocol (プロトコル): `http` - API Base URL (API のベース URL): `jsonplaceholder.typicode.com` - Resource path (リソースパス): `/users/1` - Query Parameters (クエリパラメーター): この場合は \[None (なし)\]。 このコールを Mule アプリケーションに実装するには、HTTP Request 操作を設定します。 ### [](#anypoint-studio-での-http-request-操作の設定)Anypoint Studio での HTTP Request 操作の設定 1. Studio の \[Mule Palette (Mule パレット)\] から、HTTP Request Connector をアプリケーションに追加します。 2. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、​**\[Host (ホスト)\]**​ の値として ​`jsonplaceholder.typicode.com`​ を指定します。 3. **\[Port (ポート)\]**​ の値を 80 に設定します。 4. **\[OK\]**​ をクリックします。 ![「Host (ホスト)」 と 「Port (ポート)」 を含む 「HTTP Request configuration (HTTP 要求設定)\]](_images/mruntime-consume-rest-api-configuration-1.png) Figure 2. \[Host (ホスト)\] と \[Port (ポート)\] を含む \[HTTP Request configuration (HTTP 要求設定)\]。 1. HTTP Request 操作のプロパティエディター > \[General (一般)\] タブから \[Request (要求)\] セクションに移動して、​**\[Path (パス)\]**​ 項目に ​`/users/1`​ を追加します。 最初のステップでホストを指定することで識別を開始した URL は、このパスの指定により完了します。 1. **\[Method (メソッド)\]**​ ドロップダウンリストからメソッドを選択します (この例では ​`GET`​)。 2. アプリケーションを保存します。 ![HTTP 要求の GET メソッドとパス](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-consume-rest-api-configuration-2.png) Figure 3. HTTP 要求の GET メソッドとパス。 ### [](#xml-での-http-request-操作の設定)XML での HTTP Request 操作の設定 次の XML コードは、例の HTTP Request 操作の設定を示しています。 ```xml <...> ``` ### [](#json-応答の例)JSON 応答の例 JSONPlaceholder API の例の JSON 応答の構造は次のとおりです。 ```json { "userId": 1, "id": 3, "title": "fugiat veniam minus", "completed": false } ``` HTTP Request 操作の ​**\[Advanced (詳細)\]**​ タブでデータを変換できます。また、対象変数を定義することもできます (デフォルトは \[Payload (ペイロード)\])。 この API に RAML ファイルが関連付けられている場合、その RAML ファイルをコネクタの設定要素で参照できます。これを設定し、コールする動詞とアセットを選択したら、Studio は出力に対応するメタデータを公開します。フローの他の要素とのインテグレーションが簡略化されます。 ## [](#dataweave-式を使用した動的要求の設定)DataWeave 式を使用した動的要求の設定 ほとんどのユースケースで、API へのコールをメッセージのデータに基づいて動的に変更することが求められます。この動的要求は、DataWeave 式を使用して設定できます。 「REST API のコンシュームの例」に記載されている設定例では、要求は URL 内でハードコード化されていました。 https://jsonplaceholder.typicode.com/users/1 次の GET 要求の例では、コールは、DataWeave 式 ​`#[payload.user_id]`​ を使用してメッセージのペイロードからユーザー ID を抽出するように Mule Runtime Engine に指示しています。 https://jsonplaceholder.typicode.com/users/#\[payload.user\_id\] ### [](#anypoint-studio-での動的要求の設定)Anypoint Studio での動的要求の設定 Anypoint Studio を使用して同じ操作を実行するには、目的の DataWeave 式 (この場合は ​`#['/users/' ++ payload.user_id]`​) を使用してパス設定を変更します。 ![「Path (パス)」項目で DataWeave 式を使用して動的要求を設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-consume-rest-api-configuration-3.png) Figure 4. \[Path (パス)\] 項目で DataWeave 式を使用して動的要求を設定。 クエリパラメーター、URI パラメーター、または HTTP メソッドでも動的要求を設定できます。 また、​[設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties)​を使用して、このいずれかの動的要求を設定することもできます。 ### [](#xml-での動的要求の設定)XML での動的要求の設定 次の XML 形式のサンプルコードは、動的要求の設定を示しています。 ```xml <...> ``` ## [](#http-content-type-およびエンコード)HTTP Content-Type およびエンコード POST 要求を送信すると、Mule Runtime Engine は、本文の Content-Type とエンコードに関する次のルールに従います。

コンテンツ

ルール

String​、​char[]`​、​Reader​ または同様のコンテンツ*

* エンドポイントでエンコードが明示的に設定されている場合、Mule Runtime Engine はそのエンコードを使用します。 * エンドポイントでエンコードが明示的に設定されていない場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ からエンコードを決定します。 * Content-Type​ メッセージプロパティが設定されていない場合、Mule Runtime Engine は Mule コンテキストのデフォルト設定を使用します。 * Content-Type​ の場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ を送信しますが、実際のエンコードが設定されます。

バイナリコンテンツ

エンコードは関連しません。Mule Runtime Engine は ​Content-Type​ を次のように設定します。

  • Content-Type​ プロパティがメッセージで設定されている場合、Mule Runtime Engine は、定義されているコンテンツタイプを使用します。

  • Content-Type​ プロパティがメッセージで設定されていない場合、Mule Runtime Engine は「application/octet-stream」を ​Content-Type​ として設定します。
## [](#カスタムヘッダー)カスタムヘッダー API によっては、要求と共にカスタムヘッダー (開発者キーなど) を渡す必要があります。クエリパラメーターと同様に、HTTP Connector でヘッダーを要求に追加できます。 たとえば、コンシュームしている API が開発者キーを必要とする場合、ヘッダー名 ​`accessKey`​ を使用して、そのキーを要求のヘッダーとして指定します。 Anypoint Studio を使用して、プロパティを追加してカスタムヘッダーを設定できます。 ### [](#anypoint-studio-でのカスタムヘッダー)Anypoint Studio でのカスタムヘッダー Studio でカスタムヘッダーを設定するには、次の手順を参照してください。 - HTTP Request 操作のプロパティエディターで、​**\[Headers (ヘッダー)\]**​ タブを選択します。 - **\[Add (追加)\]**​ をクリックします。 - **\[Name (名前)\]**​ と ​**\[Value (値)\]**​ を定義します。どちらも、式またはプロパティプレースホルダーを使用して定義できます。 ![Studio でのカスタムヘッダーの設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-consume-rest-api-configuration-4.png) Figure 5. HTTP Request 操作のプロパティエディターで、\[Custom Headers (カスタムヘッダー)\] を設定します。 ## [](#セキュリティ要件)セキュリティ要件 コールしている API が複雑な認証プロトコルを必要とする場合、独自のコネクタをビルドしてその API をコンシュームできます。それ以外の場合は、基本認証ログイン情報を設定するか、グローバル HTTPS Connector を設定して、API のセキュリティ要件を満たすことができます。 ### [](#基本認証)基本認証 コールしている REST API が基本認証ログイン情報の提供を要求する場合、アウトバウンド HTTP エンドポイントの設定内で基本認証ログイン情報を指定できます。 1. Studio で \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[Authentication (認証)\] で ​**\[Basic Authentication (基本認証)\]**​ を選択します。 3. ユーザー名とパスワードを入力します。これらをプロパティプレースホルダーとして設定することもできます。 4. **\[OK\]**​ をクリックします。 ![mruntime consume rest api configuration 7](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-consume-rest-api-configuration-7.png) ### [](#https-設定)HTTPS 設定 コンシュームしている REST API が、HTTPS を介して受信要求が到着することを要求する場合、Mule アプリケーションでグローバル HTTPS 要求コネクタを設定し、そのコネクタを要求操作で参照できます。 次の例では、HTTPS 要求コネクタを設定し、Java キーストアファイル (JKS) を作成し、​[TLS を設定します](https://docs.mulesoft.com/jp/mule-runtime/4.5/tls-configuration)​。 #### [](#https-用-http-request-connector-の設定)HTTPS 用 HTTP Request Connector の設定 1. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、\[General (一般)\] タブ > \[Connection Configuration (接続設定)\] セクションに移動します。 2. **\[Protocol (プロトコル)\]**​ で ​**\[HTTPS\]**​ を選択します。 3. **\[OK\]**​ をクリックします。 ![HTTPS 要求コネクタの設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-consume-rest-api-configuration-5.png) Figure 6. HTTPS 要求コネクタの設定。 #### [](#キーストアファイルの作成)キーストアファイルの作成 Java インストールの bin ディレクトリにある Java keytool を使用して、通信を認証するためのキーストアファイルを作成します。 1. コマンドラインを使用して、使用しているマシンの Java インストールディレクトリに移動します。 2. 次のコマンドを実行します。 keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks 1. 2 つのパスワードを作成するように促されたら作成し、後で使用するために覚えておきます。 このアクションにより、​`keystore.jks`​ という名前の ​`jks`​ ファイルがローカルディレクトリに作成されます。 2. `keystore.jks`​ ファイルを配置します。 - Studio を使用する場合、​`keystore.jks`​ ファイルを Studio の Package Explorer の ​`appname/src/main/resources`​ ディレクトリに配置します。 - Mule Runtime Engine で XML を使用し、ファイルを複数のアプリケーションで使用する場合、​`MULE_HOME/conf`​ ディレクトリにファイルを配置します。 - Mule Runtime Engine で XML を使用し、ファイルをこのアプリケーション内で使用する場合、​`yourappname/src/main/resources`​ ディレクトリにファイルを配置します。 1. グローバル HTTPS 要求コネクタでキーストアを参照します。 次に、このコネクタはフロー内で HTTP アウトバウンドエンドポイントにより参照されます。 #### [](#tls-を設定する)TLS を設定する 以下の手順に従って、TLS を設定します。 1. Studio で、\[Global Elements (グローバル要素)\] ビューに移動します。 2. **\[Create (作成)\]**​ を選択し、「TLS Context (TLS コンテキスト)」を検索します。 3. \[Key Store Configuration (キーストア設定)\] セクションで、キーストア設定の \[Type (種別)\] をドロップダウンメニューから選択します。たとえば、デフォルトの種別である ​**\[JKS\]**​ (Java キーストア) を選択します。 4. キーストアを ​`appname/src/main/resources`​ ディレクトリに配置している場合は、​**\[Path (パス)\]**​ にキーストアの名前を指定し、それ以外の場合は ​`"/keystore.jks"`​ を指定します。 5. **\[Key Password (キーパスワード)\]**​ と ​**\[Password (パスワード)\]**​ には、キーストアファイルの作成時に作成したパスワードを入力します。 6. **\[OK\]**​ をクリックします。 ![TLS を設定する](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-consume-rest-api-configuration-6.png) Figure 7. TLS を設定します。 1. \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[TLS Configuration (TLS 設定)\] で ​**\[Global Reference (グローバル参照)\]**​ と、以前作成した ​**\[TLS context (TLS コンテキスト)\]**​ 値を選択します。 TLS コンテキストはインラインで作成することもできます。 ![HTTP 要求設定での TLS の設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-consume-rest-api-configuration-8.png) Figure 8. HTTP 要求設定での TLS の設定。 # API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。SOAP または REST API からデータをコンシュームするには、以下のプロセスを参照してください。 ## [](#soap-api-からのデータのコンシューム)SOAP API からのデータのコンシューム 独自の Anypoint Connector を持たない SOAP API からデータをコンシュームするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を設定します。 コネクタは API の WSDL ファイルから取得したホスト、ポート、およびアドレスメタデータを使用して、Mule アプリケーション内からサービスをコンシュームするために必要な接続設定を提供します。 詳細は、​[「Web Service Consumer Connector」](https://docs.mulesoft.com/web-service-consumer-connector/latest/)​を参照してください。 ## [](#rest-api-からのデータのコンシューム)REST API からのデータのコンシューム 以下のプロセスでは、REST API をコールするための HTTP Request Connector の設定に焦点が当てられています。これは、Mule アプリケーションが REST API をコンシュームする方法の基本構造、必要な最小限の設定、コンシューム方法の例、動的要求の設定方法、HTTP Content-Type とエンコードの管理方法、カスタムヘッダーの操作方法、およびセキュリティ要件を理解するのに役立ちます。 Mule アプリケーション内で REST API からデータをコンシュームするには、HTTP 要求用 Anypoint Connector (HTTP Request Connector) を設定できます。 同じ REST API に何度も接続したり、複雑な認証プロトコルを持つ API を使用したりする場合は、​[Mule SDK を使用して独自のコネクタを開発](https://docs.mulesoft.com/mule-sdk/latest/)​することを考慮してください。接続先の API のコネクタが [Anypoint Exchange](https://anypoint.mulesoft.com/exchange/)​ にすでに存在するかどうかを確認します。Anypoint Studio の \[Mule Palette (Mule パレット)\] を使用して Exchange 内を検索できます。 ## [](#基本構造)基本構造 REST API をコンシュームする Mule アプリケーションは次の要素で構成されます。 - 要求をビルドするように設定された 1 つ以上のメッセージプロセッサー - REST API をコールするように設定された HTTP Request 操作 - 応答を受け入れて処理するように設定された 1 つ以上のメッセージプロセッサー ![REST API のコンシュームフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-consume-rest-api-flow.png) Figure 1. REST API のコンシュームフロー。 要求をビルドするアプリケーションの部分と応答を処理するアプリケーションの部分を設定します。 ## [](#最小限の設定)最小限の設定 コンシュームする REST API には、その API を記述する [RAML](http://raml.org)​ ファイルが必要です。これにより、HTTP Connector はスマート提案をユーザーにあらかじめ提供できます。 RAML ファイルでは、以下を定義します。 - 認証 - アウトバウンド HTTP エンドポイントを設定するためのベース URI - Scope (スコープ) アプリケーションは認証ログイン情報に基づいて、たとえば、コールを特定のリソースの GET 要求のみに制限したり、リソースへのアクセスを制限したりできます。 - リソース アウトバウンド HTTP エンドポイントのリソースのパスを設定する必要があります。 - メソッド POST を HTTP アウトバウンドエンドポイントのデフォルトメソッドとして受け入れたり、そのデフォルトを、リソースでサポートされているメソッドに変更したりできます。 - Input validation (入力規則) 通常、POST および PUT コールの場合、API は、入力形式 (JSON、XML など) がそのスキーマに一致していることを要求します。 Mule Runtime Engine で、以下を定義または設定できます。 - Output format (出力形式) HTTP Request 操作の後、メッセージプロセッサーをフローに含めて、フローで API からの応答を受け入れて使用可能な形式に変換する必要があります。 - Redirect (リダイレクト) API でリダイレクトを使用する場合、HTTP Request 操作でリダイレクトを有効にします。 - Timeout (タイムアウト) - Headers for methods (メソッドのヘッダー) ほとんどの場合、POST、PUT、DELETE 要求にはヘッダーが必要です。 - URI およびクエリパラメーター - エラー処理 要求操作の設定方法についての詳細は、​[HTTP Connector のドキュメント](https://docs.mulesoft.com/http-connector/latest/#input-sources)​を参照してください。 ### [](#rest-api-のコンシュームの例)REST API のコンシュームの例 次の例では、 [JSONPlaceholder API](https://jsonplaceholder.typicode.com/todos/1)​ をコンシュームします。この例には、HTTP Request Connector の設定のみが示されています。これを正常に機能させるには、フロー内でメッセージをトリガーする 1 つ以上の Mule イベントソースと、応答を受け入れる 1 つ以上のメッセージプロセッサーを設定する必要があります。詳細は、​[「REST API の例」](https://docs.mulesoft.com/jp/mule-runtime/4.6/rest-api-examples)​のドキュメントを参照してください。 この API の例について説明します。 - この API は認証を必要としません。 - ベース URL は ​`jsonplaceholder.typicode.com`​ です。 - この API は開発目的のモック API です。 - `id=1`​ のユーザーに関する情報を取得するには要求が次のようになっている必要があることをこのサンプル API 要求は示しています。 https://jsonplaceholder.typicode.com/users/1 URL の各部は次のとおりです。 - Protocol (プロトコル): `http` - API Base URL (API のベース URL): `jsonplaceholder.typicode.com` - Resource path (リソースパス): `/users/1` - Query Parameters (クエリパラメーター): この場合は \[None (なし)\]。 このコールを Mule アプリケーションに実装するには、HTTP Request 操作を設定します。 ### [](#anypoint-studio-での-http-request-操作の設定)Anypoint Studio での HTTP Request 操作の設定 1. Studio の \[Mule Palette (Mule パレット)\] から、HTTP Request Connector をアプリケーションに追加します。 2. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、​**\[Host (ホスト)\]**​ の値として ​`jsonplaceholder.typicode.com`​ を指定します。 3. **\[Port (ポート)\]**​ の値を 80 に設定します。 4. **\[OK\]**​ をクリックします。 ![「Host (ホスト)」 と 「Port (ポート)」 を含む 「HTTP Request configuration (HTTP 要求設定)\]](_images/mruntime-consume-rest-api-configuration-1.png) Figure 2. \[Host (ホスト)\] と \[Port (ポート)\] を含む \[HTTP Request configuration (HTTP 要求設定)\]。 1. HTTP Request 操作のプロパティエディター > \[General (一般)\] タブから \[Request (要求)\] セクションに移動して、​**\[Path (パス)\]**​ 項目に ​`/users/1`​ を追加します。 最初のステップでホストを指定することで識別を開始した URL は、このパスの指定により完了します。 1. **\[Method (メソッド)\]**​ ドロップダウンリストからメソッドを選択します (この例では ​`GET`​)。 2. アプリケーションを保存します。 ![HTTP 要求の GET メソッドとパス](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-consume-rest-api-configuration-2.png) Figure 3. HTTP 要求の GET メソッドとパス。 ### [](#xml-での-http-request-操作の設定)XML での HTTP Request 操作の設定 次の XML コードは、例の HTTP Request 操作の設定を示しています。 ```xml <...> ``` ### [](#json-応答の例)JSON 応答の例 JSONPlaceholder API の例の JSON 応答の構造は次のとおりです。 ```json { "userId": 1, "id": 3, "title": "fugiat veniam minus", "completed": false } ``` HTTP Request 操作の ​**\[Advanced (詳細)\]**​ タブでデータを変換できます。また、対象変数を定義することもできます (デフォルトは \[Payload (ペイロード)\])。 この API に RAML ファイルが関連付けられている場合、その RAML ファイルをコネクタの設定要素で参照できます。これを設定し、コールする動詞とアセットを選択したら、Studio は出力に対応するメタデータを公開します。フローの他の要素とのインテグレーションが簡略化されます。 ## [](#dataweave-式を使用した動的要求の設定)DataWeave 式を使用した動的要求の設定 ほとんどのユースケースで、API へのコールをメッセージのデータに基づいて動的に変更することが求められます。この動的要求は、DataWeave 式を使用して設定できます。 「REST API のコンシュームの例」に記載されている設定例では、要求は URL 内でハードコード化されていました。 https://jsonplaceholder.typicode.com/users/1 次の GET 要求の例では、コールは、DataWeave 式 ​`#[payload.user_id]`​ を使用してメッセージのペイロードからユーザー ID を抽出するように Mule Runtime Engine に指示しています。 https://jsonplaceholder.typicode.com/users/#\[payload.user\_id\] ### [](#anypoint-studio-での動的要求の設定)Anypoint Studio での動的要求の設定 Anypoint Studio を使用して同じ操作を実行するには、目的の DataWeave 式 (この場合は ​`#['/users/' ++ payload.user_id]`​) を使用してパス設定を変更します。 ![「Path (パス)」 項目で DataWeave 式を使用して動的要求を設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-consume-rest-api-configuration-3.png) Figure 4. \[Path (パス)\] 項目で DataWeave 式を使用して動的要求を設定。 クエリパラメーター、URI パラメーター、または HTTP メソッドでも動的要求を設定できます。 また、​[設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties)​を使用して、このいずれかの動的要求を設定することもできます。 ### [](#xml-での動的要求の設定)XML での動的要求の設定 次の XML 形式のサンプルコードは、動的要求の設定を示しています。 ```xml <...> ``` ## [](#http-content-type-およびエンコード)HTTP Content-Type およびエンコード POST 要求を送信すると、Mule Runtime Engine は、本文の Content-Type とエンコードに関する次のルールに従います。

コンテンツ

ルール

String​、​char[]`​、​Reader​ または同様のコンテンツ*

* エンドポイントでエンコードが明示的に設定されている場合、Mule Runtime Engine はそのエンコードを使用します。 * エンドポイントでエンコードが明示的に設定されていない場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ からエンコードを決定します。 * Content-Type​ メッセージプロパティが設定されていない場合、Mule Runtime Engine は Mule コンテキストのデフォルト設定を使用します。 * Content-Type​ の場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ を送信しますが、実際のエンコードが設定されます。

バイナリコンテンツ

エンコードは関連しません。Mule Runtime Engine は ​Content-Type​ を次のように設定します。

  • Content-Type​ プロパティがメッセージで設定されている場合、Mule Runtime Engine は、定義されているコンテンツタイプを使用します。

  • Content-Type​ プロパティがメッセージで設定されていない場合、Mule Runtime Engine は「application/octet-stream」を ​Content-Type​ として設定します。
## [](#カスタムヘッダー)カスタムヘッダー API によっては、要求と共にカスタムヘッダー (開発者キーなど) を渡す必要があります。クエリパラメーターと同様に、HTTP Connector でヘッダーを要求に追加できます。 たとえば、コンシュームしている API が開発者キーを必要とする場合、ヘッダー名 ​`accessKey`​ を使用して、そのキーを要求のヘッダーとして指定します。 Anypoint Studio を使用して、プロパティを追加してカスタムヘッダーを設定できます。 ### [](#anypoint-studio-でのカスタムヘッダー)Anypoint Studio でのカスタムヘッダー Studio でカスタムヘッダーを設定するには、次の手順を参照してください。 - HTTP Request 操作のプロパティエディターで、​**\[Headers (ヘッダー)\]**​ タブを選択します。 - **\[Add (追加)\]**​ をクリックします。 - **\[Name (名前)\]**​ と ​**\[Value (値)\]**​ を定義します。どちらも、式またはプロパティプレースホルダーを使用して定義できます。 ![Studio でのカスタムヘッダーの設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-consume-rest-api-configuration-4.png) Figure 5. HTTP Request 操作のプロパティエディターで、\[Custom Headers (カスタムヘッダー)\] を設定します。 ## [](#セキュリティ要件)セキュリティ要件 コールしている API が複雑な認証プロトコルを必要とする場合、独自のコネクタをビルドしてその API をコンシュームできます。それ以外の場合は、基本認証ログイン情報を設定するか、グローバル HTTPS Connector を設定して、API のセキュリティ要件を満たすことができます。 ### [](#基本認証)基本認証 コールしている REST API が基本認証ログイン情報の提供を要求する場合、アウトバウンド HTTP エンドポイントの設定内で基本認証ログイン情報を指定できます。 1. Studio で \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[Authentication (認証)\] で ​**\[Basic Authentication (基本認証)\]**​ を選択します。 3. ユーザー名とパスワードを入力します。これらをプロパティプレースホルダーとして設定することもできます。 4. **\[OK\]**​ をクリックします。 ![mruntime consume rest api configuration 7](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-consume-rest-api-configuration-7.png) ### [](#https-設定)HTTPS 設定 コンシュームしている REST API が、HTTPS を介して受信要求が到着することを要求する場合、Mule アプリケーションでグローバル HTTPS 要求コネクタを設定し、そのコネクタを要求操作で参照できます。 次の例では、HTTPS 要求コネクタを設定し、Java キーストアファイル (JKS) を作成し、​[TLS を設定します](https://docs.mulesoft.com/jp/mule-runtime/4.6/tls-configuration)​。 #### [](#https-用-http-request-connector-の設定)HTTPS 用 HTTP Request Connector の設定 1. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、\[General (一般)\] タブ > \[Connection Configuration (接続設定)\] セクションに移動します。 2. **\[Protocol (プロトコル)\]**​ で ​**\[HTTPS\]**​ を選択します。 3. **\[OK\]**​ をクリックします。 ![HTTPS 要求コネクタの設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-consume-rest-api-configuration-5.png) Figure 6. HTTPS 要求コネクタの設定。 #### [](#キーストアファイルの作成)キーストアファイルの作成 Java インストールの bin ディレクトリにある Java keytool を使用して、通信を認証するためのキーストアファイルを作成します。 1. コマンドラインを使用して、使用しているマシンの Java インストールディレクトリに移動します。 2. 次のコマンドを実行します。 keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks 1. 2 つのパスワードを作成するように促されたら作成し、後で使用するために覚えておきます。 このアクションにより、​`keystore.jks`​ という名前の ​`jks`​ ファイルがローカルディレクトリに作成されます。 2. `keystore.jks`​ ファイルを配置します。 - Studio を使用する場合、​`keystore.jks`​ ファイルを Studio の Package Explorer の ​`appname/src/main/resources`​ ディレクトリに配置します。 - Mule Runtime Engine で XML を使用し、ファイルを複数のアプリケーションで使用する場合、​`MULE_HOME/conf`​ ディレクトリにファイルを配置します。 - Mule Runtime Engine で XML を使用し、ファイルをこのアプリケーション内で使用する場合、​`yourappname/src/main/resources`​ ディレクトリにファイルを配置します。 1. グローバル HTTPS 要求コネクタでキーストアを参照します。 次に、このコネクタはフロー内で HTTP アウトバウンドエンドポイントにより参照されます。 #### [](#tls-を設定する)TLS を設定する 以下の手順に従って、TLS を設定します。 1. Studio で、\[Global Elements (グローバル要素)\] ビューに移動します。 2. **\[Create (作成)\]**​ を選択し、「TLS Context (TLS コンテキスト)」を検索します。 3. \[Key Store Configuration (キーストア設定)\] セクションで、キーストア設定の \[Type (種別)\] をドロップダウンメニューから選択します。たとえば、デフォルトの種別である ​**\[JKS\]**​ (Java キーストア) を選択します。 4. キーストアを ​`appname/src/main/resources`​ ディレクトリに配置している場合は、​**\[Path (パス)\]**​ にキーストアの名前を指定し、それ以外の場合は ​`"/keystore.jks"`​ を指定します。 5. **\[Key Password (キーパスワード)\]**​ と ​**\[Password (パスワード)\]**​ には、キーストアファイルの作成時に作成したパスワードを入力します。 6. **\[OK\]**​ をクリックします。 ![TLS を設定する](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-consume-rest-api-configuration-6.png) Figure 7. TLS を設定します。 1. \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[TLS Configuration (TLS 設定)\] で ​**\[Global Reference (グローバル参照)\]**​ と、以前作成した ​**\[TLS context (TLS コンテキスト)\]**​ 値を選択します。 TLS コンテキストはインラインで作成することもできます。 ![HTTP 要求設定での TLS の設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-consume-rest-api-configuration-8.png) Figure 8. HTTP 要求設定での TLS の設定。 # API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。SOAP または REST API からデータをコンシュームするには、以下のプロセスを参照してください。 ## [](#soap-api-からのデータのコンシューム)SOAP API からのデータのコンシューム 独自の Anypoint Connector を持たない SOAP API からデータをコンシュームするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を設定します。 コネクタは API の WSDL ファイルから取得したホスト、ポート、およびアドレスメタデータを使用して、Mule アプリケーション内からサービスをコンシュームするために必要な接続設定を提供します。 詳細は、​[「Web Service Consumer Connector」](https://docs.mulesoft.com/web-service-consumer-connector/latest/)​を参照してください。 ## [](#rest-api-からのデータのコンシューム)REST API からのデータのコンシューム 以下のプロセスでは、REST API をコールするための HTTP Request Connector の設定に焦点が当てられています。これは、Mule アプリケーションが REST API をコンシュームする方法の基本構造、必要な最小限の設定、コンシューム方法の例、動的要求の設定方法、HTTP Content-Type とエンコードの管理方法、カスタムヘッダーの操作方法、およびセキュリティ要件を理解するのに役立ちます。 Mule アプリケーション内で REST API からデータをコンシュームするには、HTTP 要求用 Anypoint Connector (HTTP Request Connector) を設定できます。 同じ REST API に何度も接続したり、複雑な認証プロトコルを持つ API を使用したりする場合は、​[Mule SDK を使用して独自のコネクタを開発](https://docs.mulesoft.com/mule-sdk/latest/)​することを考慮してください。接続先の API のコネクタが [Anypoint Exchange](https://anypoint.mulesoft.com/exchange/)​ にすでに存在するかどうかを確認します。Anypoint Studio の \[Mule Palette (Mule パレット)\] を使用して Exchange 内を検索できます。 ## [](#基本構造)基本構造 REST API をコンシュームする Mule アプリケーションは次の要素で構成されます。 - 要求をビルドするように設定された 1 つ以上のメッセージプロセッサー - REST API をコールするように設定された HTTP Request 操作 - 応答を受け入れて処理するように設定された 1 つ以上のメッセージプロセッサー ![REST API のコンシュームフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-consume-rest-api-flow.png) Figure 1. REST API のコンシュームフロー。 要求をビルドするアプリケーションの部分と応答を処理するアプリケーションの部分を設定します。 ## [](#最小限の設定)最小限の設定 コンシュームする REST API には、その API を記述する [RAML](http://raml.org)​ ファイルが必要です。これにより、HTTP Connector はスマート提案をユーザーにあらかじめ提供できます。 RAML ファイルでは、以下を定義します。 - 認証 - アウトバウンド HTTP エンドポイントを設定するためのベース URI - Scope (スコープ) アプリケーションは認証ログイン情報に基づいて、たとえば、コールを特定のリソースの GET 要求のみに制限したり、リソースへのアクセスを制限したりできます。 - リソース アウトバウンド HTTP エンドポイントのリソースのパスを設定する必要があります。 - メソッド POST を HTTP アウトバウンドエンドポイントのデフォルトメソッドとして受け入れたり、そのデフォルトを、リソースでサポートされているメソッドに変更したりできます。 - Input validation (入力規則) 通常、POST および PUT コールの場合、API は、入力形式 (JSON、XML など) がそのスキーマに一致していることを要求します。 Mule Runtime Engine で、以下を定義または設定できます。 - Output format (出力形式) HTTP Request 操作の後、メッセージプロセッサーをフローに含めて、フローで API からの応答を受け入れて使用可能な形式に変換する必要があります。 - Redirect (リダイレクト) API でリダイレクトを使用する場合、HTTP Request 操作でリダイレクトを有効にします。 - Timeout (タイムアウト) - Headers for methods (メソッドのヘッダー) ほとんどの場合、POST、PUT、DELETE 要求にはヘッダーが必要です。 - URI およびクエリパラメーター - エラー処理 要求操作の設定方法についての詳細は、​[HTTP Connector のドキュメント](https://docs.mulesoft.com/http-connector/latest/#input-sources)​を参照してください。 ### [](#rest-api-のコンシュームの例)REST API のコンシュームの例 次の例では、 [JSONPlaceholder API](https://jsonplaceholder.typicode.com/todos/1)​ をコンシュームします。この例には、HTTP Request Connector の設定のみが示されています。これを正常に機能させるには、フロー内でメッセージをトリガーする 1 つ以上の Mule イベントソースと、応答を受け入れる 1 つ以上のメッセージプロセッサーを設定する必要があります。詳細は、​[「REST API の例」](https://docs.mulesoft.com/jp/mule-runtime/4.7/rest-api-examples)​のドキュメントを参照してください。 この API の例について説明します。 - この API は認証を必要としません。 - ベース URL は ​`jsonplaceholder.typicode.com`​ です。 - この API は開発目的のモック API です。 - `id=1`​ のユーザーに関する情報を取得するには要求が次のようになっている必要があることをこのサンプル API 要求は示しています。 https://jsonplaceholder.typicode.com/users/1 URL の各部は次のとおりです。 - Protocol (プロトコル): `http` - API Base URL (API のベース URL): `jsonplaceholder.typicode.com` - Resource path (リソースパス): `/users/1` - Query Parameters (クエリパラメーター): この場合は \[None (なし)\]。 このコールを Mule アプリケーションに実装するには、HTTP Request 操作を設定します。 ### [](#anypoint-studio-での-http-request-操作の設定)Anypoint Studio での HTTP Request 操作の設定 1. Studio の \[Mule Palette (Mule パレット)\] から、HTTP Request Connector をアプリケーションに追加します。 2. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、​**\[Host (ホスト)\]**​ の値として ​`jsonplaceholder.typicode.com`​ を指定します。 3. **\[Port (ポート)\]**​ の値を 80 に設定します。 4. **\[OK\]**​ をクリックします。 ![「Host (ホスト)」 と 「Port (ポート)」 を含む 「HTTP Request configuration (HTTP 要求設定)\]](_images/mruntime-consume-rest-api-configuration-1.png) Figure 2. \[Host (ホスト)\] と \[Port (ポート)\] を含む \[HTTP Request configuration (HTTP 要求設定)\]。 1. HTTP Request 操作のプロパティエディター > \[General (一般)\] タブから \[Request (要求)\] セクションに移動して、​**\[Path (パス)\]**​ 項目に ​`/users/1`​ を追加します。 最初のステップでホストを指定することで識別を開始した URL は、このパスの指定により完了します。 1. **\[Method (メソッド)\]**​ ドロップダウンリストからメソッドを選択します (この例では ​`GET`​)。 2. アプリケーションを保存します。 ![HTTP 要求の GET メソッドとパス](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-consume-rest-api-configuration-2.png) Figure 3. HTTP 要求の GET メソッドとパス。 ### [](#xml-での-http-request-操作の設定)XML での HTTP Request 操作の設定 次の XML コードは、例の HTTP Request 操作の設定を示しています。 ```xml <...> ``` ### [](#json-応答の例)JSON 応答の例 JSONPlaceholder API の例の JSON 応答の構造は次のとおりです。 ```json { "userId": 1, "id": 3, "title": "fugiat veniam minus", "completed": false } ``` HTTP Request 操作の ​**\[Advanced (詳細)\]**​ タブでデータを変換できます。また、対象変数を定義することもできます (デフォルトは \[Payload (ペイロード)\])。 この API に RAML ファイルが関連付けられている場合、その RAML ファイルをコネクタの設定要素で参照できます。これを設定し、コールする動詞とアセットを選択したら、Studio は出力に対応するメタデータを公開します。フローの他の要素とのインテグレーションが簡略化されます。 ## [](#dataweave-式を使用した動的要求の設定)DataWeave 式を使用した動的要求の設定 ほとんどのユースケースで、API へのコールをメッセージのデータに基づいて動的に変更することが求められます。この動的要求は、DataWeave 式を使用して設定できます。 「REST API のコンシュームの例」に記載されている設定例では、要求は URL 内でハードコード化されていました。 https://jsonplaceholder.typicode.com/users/1 次の GET 要求の例では、コールは、DataWeave 式 ​`#[payload.user_id]`​ を使用してメッセージのペイロードからユーザー ID を抽出するように Mule Runtime Engine に指示しています。 https://jsonplaceholder.typicode.com/users/#\[payload.user\_id\] ### [](#anypoint-studio-での動的要求の設定)Anypoint Studio での動的要求の設定 Anypoint Studio を使用して同じ操作を実行するには、目的の DataWeave 式 (この場合は ​`#['/users/' ++ payload.user_id]`​) を使用してパス設定を変更します。 ![「Path (パス)」 項目で DataWeave 式を使用して動的要求を設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-consume-rest-api-configuration-3.png) Figure 4. \[Path (パス)\] 項目で DataWeave 式を使用して動的要求を設定。 クエリパラメーター、URI パラメーター、または HTTP メソッドでも動的要求を設定できます。 また、​[設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties)​を使用して、このいずれかの動的要求を設定することもできます。 ### [](#xml-での動的要求の設定)XML での動的要求の設定 次の XML 形式のサンプルコードは、動的要求の設定を示しています。 ```xml <...> ``` ## [](#http-content-type-およびエンコード)HTTP Content-Type およびエンコード POST 要求を送信すると、Mule Runtime Engine は、本文の Content-Type とエンコードに関する次のルールに従います。

コンテンツ

ルール

String​、​char[]`​、​Reader​ または同様のコンテンツ*

* エンドポイントでエンコードが明示的に設定されている場合、Mule Runtime Engine はそのエンコードを使用します。 * エンドポイントでエンコードが明示的に設定されていない場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ からエンコードを決定します。 * Content-Type​ メッセージプロパティが設定されていない場合、Mule Runtime Engine は Mule コンテキストのデフォルト設定を使用します。 * Content-Type​ の場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ を送信しますが、実際のエンコードが設定されます。

バイナリコンテンツ

エンコードは関連しません。Mule Runtime Engine は ​Content-Type​ を次のように設定します。

  • Content-Type​ プロパティがメッセージで設定されている場合、Mule Runtime Engine は、定義されているコンテンツタイプを使用します。

  • Content-Type​ プロパティがメッセージで設定されていない場合、Mule Runtime Engine は「application/octet-stream」を ​Content-Type​ として設定します。
## [](#カスタムヘッダー)カスタムヘッダー API によっては、要求と共にカスタムヘッダー (開発者キーなど) を渡す必要があります。クエリパラメーターと同様に、HTTP Connector でヘッダーを要求に追加できます。 たとえば、コンシュームしている API が開発者キーを必要とする場合、ヘッダー名 ​`accessKey`​ を使用して、そのキーを要求のヘッダーとして指定します。 Anypoint Studio を使用して、プロパティを追加してカスタムヘッダーを設定できます。 ### [](#anypoint-studio-でのカスタムヘッダー)Anypoint Studio でのカスタムヘッダー Studio でカスタムヘッダーを設定するには、次の手順を参照してください。 - HTTP Request 操作のプロパティエディターで、​**\[Headers (ヘッダー)\]**​ タブを選択します。 - **\[Add (追加)\]**​ をクリックします。 - **\[Name (名前)\]**​ と ​**\[Value (値)\]**​ を定義します。どちらも、式またはプロパティプレースホルダーを使用して定義できます。 ![Studio でのカスタムヘッダーの設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-consume-rest-api-configuration-4.png) Figure 5. HTTP Request 操作のプロパティエディターで、\[Custom Headers (カスタムヘッダー)\] を設定します。 ## [](#セキュリティ要件)セキュリティ要件 コールしている API が複雑な認証プロトコルを必要とする場合、独自のコネクタをビルドしてその API をコンシュームできます。それ以外の場合は、基本認証ログイン情報を設定するか、グローバル HTTPS Connector を設定して、API のセキュリティ要件を満たすことができます。 ### [](#基本認証)基本認証 コールしている REST API が基本認証ログイン情報の提供を要求する場合、アウトバウンド HTTP エンドポイントの設定内で基本認証ログイン情報を指定できます。 1. Studio で \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[Authentication (認証)\] で ​**\[Basic Authentication (基本認証)\]**​ を選択します。 3. ユーザー名とパスワードを入力します。これらをプロパティプレースホルダーとして設定することもできます。 4. **\[OK\]**​ をクリックします。 ![mruntime consume rest api configuration 7](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-consume-rest-api-configuration-7.png) ### [](#https-設定)HTTPS 設定 コンシュームしている REST API が、HTTPS を介して受信要求が到着することを要求する場合、Mule アプリケーションでグローバル HTTPS 要求コネクタを設定し、そのコネクタを要求操作で参照できます。 次の例では、HTTPS 要求コネクタを設定し、Java キーストアファイル (JKS) を作成し、​[TLS を設定します](https://docs.mulesoft.com/jp/mule-runtime/4.7/tls-configuration)​。 #### [](#https-用-http-request-connector-の設定)HTTPS 用 HTTP Request Connector の設定 1. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、\[General (一般)\] タブ > \[Connection Configuration (接続設定)\] セクションに移動します。 2. **\[Protocol (プロトコル)\]**​ で ​**\[HTTPS\]**​ を選択します。 3. **\[OK\]**​ をクリックします。 ![HTTPS 要求コネクタの設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-consume-rest-api-configuration-5.png) Figure 6. HTTPS 要求コネクタの設定。 #### [](#キーストアファイルの作成)キーストアファイルの作成 Java インストールの bin ディレクトリにある Java keytool を使用して、通信を認証するためのキーストアファイルを作成します。 1. コマンドラインを使用して、使用しているマシンの Java インストールディレクトリに移動します。 2. 次のコマンドを実行します。 keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks 1. 2 つのパスワードを作成するように促されたら作成し、後で使用するために覚えておきます。 このアクションにより、​`keystore.jks`​ という名前の ​`jks`​ ファイルがローカルディレクトリに作成されます。 2. `keystore.jks`​ ファイルを配置します。 - Studio を使用する場合、​`keystore.jks`​ ファイルを Studio の Package Explorer の ​`appname/src/main/resources`​ ディレクトリに配置します。 - Mule Runtime Engine で XML を使用し、ファイルを複数のアプリケーションで使用する場合、​`MULE_HOME/conf`​ ディレクトリにファイルを配置します。 - Mule Runtime Engine で XML を使用し、ファイルをこのアプリケーション内で使用する場合、​`yourappname/src/main/resources`​ ディレクトリにファイルを配置します。 1. グローバル HTTPS 要求コネクタでキーストアを参照します。 次に、このコネクタはフロー内で HTTP アウトバウンドエンドポイントにより参照されます。 #### [](#tls-を設定する)TLS を設定する 以下の手順に従って、TLS を設定します。 1. Studio で、\[Global Elements (グローバル要素)\] ビューに移動します。 2. **\[Create (作成)\]**​ を選択し、「TLS Context (TLS コンテキスト)」を検索します。 3. \[Key Store Configuration (キーストア設定)\] セクションで、キーストア設定の \[Type (種別)\] をドロップダウンメニューから選択します。たとえば、デフォルトの種別である ​**\[JKS\]**​ (Java キーストア) を選択します。 4. キーストアを ​`appname/src/main/resources`​ ディレクトリに配置している場合は、​**\[Path (パス)\]**​ にキーストアの名前を指定し、それ以外の場合は ​`"/keystore.jks"`​ を指定します。 5. **\[Key Password (キーパスワード)\]**​ と ​**\[Password (パスワード)\]**​ には、キーストアファイルの作成時に作成したパスワードを入力します。 6. **\[OK\]**​ をクリックします。 ![TLS を設定する](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-consume-rest-api-configuration-6.png) Figure 7. TLS を設定します。 1. \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[TLS Configuration (TLS 設定)\] で ​**\[Global Reference (グローバル参照)\]**​ と、以前作成した ​**\[TLS context (TLS コンテキスト)\]**​ 値を選択します。 TLS コンテキストはインラインで作成することもできます。 ![HTTP 要求設定での TLS の設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-consume-rest-api-configuration-8.png) Figure 8. HTTP 要求設定での TLS の設定。 # API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。SOAP または REST API からデータをコンシュームするには、以下のプロセスを参照してください。 ## [](#soap-api-からのデータのコンシューム)SOAP API からのデータのコンシューム 独自の Anypoint Connector を持たない SOAP API からデータをコンシュームするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を設定します。 コネクタは API の WSDL ファイルから取得したホスト、ポート、およびアドレスメタデータを使用して、Mule アプリケーション内からサービスをコンシュームするために必要な接続設定を提供します。 詳細は、​[「Web Service Consumer Connector」](https://docs.mulesoft.com/web-service-consumer-connector/latest/)​を参照してください。 ## [](#rest-api-からのデータのコンシューム)REST API からのデータのコンシューム 以下のプロセスでは、REST API をコールするための HTTP Request Connector の設定に焦点が当てられています。これは、Mule アプリケーションが REST API をコンシュームする方法の基本構造、必要な最小限の設定、コンシューム方法の例、動的要求の設定方法、HTTP Content-Type とエンコードの管理方法、カスタムヘッダーの操作方法、およびセキュリティ要件を理解するのに役立ちます。 Mule アプリケーション内で REST API からデータをコンシュームするには、HTTP 要求用 Anypoint Connector (HTTP Request Connector) を設定できます。 同じ REST API に何度も接続したり、複雑な認証プロトコルを持つ API を使用したりする場合は、​[Mule SDK を使用して独自のコネクタを開発](https://docs.mulesoft.com/mule-sdk/latest/)​することを考慮してください。接続先の API のコネクタが [Anypoint Exchange](https://anypoint.mulesoft.com/exchange/)​ にすでに存在するかどうかを確認します。Anypoint Studio の \[Mule Palette (Mule パレット)\] を使用して Exchange 内を検索できます。 ## [](#基本構造)基本構造 REST API をコンシュームする Mule アプリケーションは次の要素で構成されます。 - 要求をビルドするように設定された 1 つ以上のメッセージプロセッサー - REST API をコールするように設定された HTTP Request 操作 - 応答を受け入れて処理するように設定された 1 つ以上のメッセージプロセッサー ![REST API のコンシュームフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-consume-rest-api-flow.png) Figure 1. REST API のコンシュームフロー。 要求をビルドするアプリケーションの部分と応答を処理するアプリケーションの部分を設定します。 ## [](#最小限の設定)最小限の設定 コンシュームする REST API には、その API を記述する [RAML](http://raml.org)​ ファイルが必要です。これにより、HTTP Connector はスマート提案をユーザーにあらかじめ提供できます。 RAML ファイルでは、以下を定義します。 - 認証 - アウトバウンド HTTP エンドポイントを設定するためのベース URI - Scope (スコープ) アプリケーションは認証ログイン情報に基づいて、たとえば、コールを特定のリソースの GET 要求のみに制限したり、リソースへのアクセスを制限したりできます。 - リソース アウトバウンド HTTP エンドポイントのリソースのパスを設定する必要があります。 - メソッド POST を HTTP アウトバウンドエンドポイントのデフォルトメソッドとして受け入れたり、そのデフォルトを、リソースでサポートされているメソッドに変更したりできます。 - Input validation (入力規則) 通常、POST および PUT コールの場合、API は、入力形式 (JSON、XML など) がそのスキーマに一致していることを要求します。 Mule Runtime Engine で、以下を定義または設定できます。 - Output format (出力形式) HTTP Request 操作の後、メッセージプロセッサーをフローに含めて、フローで API からの応答を受け入れて使用可能な形式に変換する必要があります。 - Redirect (リダイレクト) API でリダイレクトを使用する場合、HTTP Request 操作でリダイレクトを有効にします。 - Timeout (タイムアウト) - Headers for methods (メソッドのヘッダー) ほとんどの場合、POST、PUT、DELETE 要求にはヘッダーが必要です。 - URI およびクエリパラメーター - エラー処理 要求操作の設定方法についての詳細は、​[HTTP Connector のドキュメント](https://docs.mulesoft.com/http-connector/latest/#input-sources)​を参照してください。 ### [](#rest-api-のコンシュームの例)REST API のコンシュームの例 次の例では、 [JSONPlaceholder API](https://jsonplaceholder.typicode.com/todos/1)​ をコンシュームします。この例には、HTTP Request Connector の設定のみが示されています。これを正常に機能させるには、フロー内でメッセージをトリガーする 1 つ以上の Mule イベントソースと、応答を受け入れる 1 つ以上のメッセージプロセッサーを設定する必要があります。詳細は、​[「REST API の例」](https://docs.mulesoft.com/jp/mule-runtime/4.8/rest-api-examples)​のドキュメントを参照してください。 この API の例について説明します。 - この API は認証を必要としません。 - ベース URL は ​`jsonplaceholder.typicode.com`​ です。 - この API は開発目的のモック API です。 - `id=1`​ のユーザーに関する情報を取得するには要求が次のようになっている必要があることをこのサンプル API 要求は示しています。 https://jsonplaceholder.typicode.com/users/1 URL の各部は次のとおりです。 - Protocol (プロトコル): `http` - API Base URL (API のベース URL): `jsonplaceholder.typicode.com` - Resource path (リソースパス): `/users/1` - Query Parameters (クエリパラメーター): この場合は \[None (なし)\]。 このコールを Mule アプリケーションに実装するには、HTTP Request 操作を設定します。 ### [](#anypoint-studio-での-http-request-操作の設定)Anypoint Studio での HTTP Request 操作の設定 1. Studio の \[Mule Palette (Mule パレット)\] から、HTTP Request Connector をアプリケーションに追加します。 2. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、​**\[Host (ホスト)\]**​ の値として ​`jsonplaceholder.typicode.com`​ を指定します。 3. **\[Port (ポート)\]**​ の値を 80 に設定します。 4. **\[OK\]**​ をクリックします。 ![\[Host (ホスト)\] と \[Port (ポート)\] を含む \[HTTP Request configuration (HTTP 要求設定)\]](_images/mruntime-consume-rest-api-configuration-1.png) Figure 2. \[Host (ホスト)\] と \[Port (ポート)\] を含む \[HTTP Request configuration (HTTP 要求設定)\]。 1. HTTP Request 操作のプロパティエディター > \[General (一般)\] タブから \[Request (要求)\] セクションに移動して、​**\[Path (パス)\]**​ 項目に ​`/users/1`​ を追加します。 最初のステップでホストを指定することで識別を開始した URL は、このパスの指定により完了します。 1. **\[Method (メソッド)\]**​ ドロップダウンリストからメソッドを選択します (この例では ​`GET`​)。 2. アプリケーションを保存します。 ![HTTP 要求の GET メソッドとパス](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-consume-rest-api-configuration-2.png) Figure 3. HTTP 要求の GET メソッドとパス。 ### [](#xml-での-http-request-操作の設定)XML での HTTP Request 操作の設定 次の XML コードは、例の HTTP Request 操作の設定を示しています。 ```xml <...> ``` ### [](#json-応答の例)JSON 応答の例 JSONPlaceholder API の例の JSON 応答の構造は次のとおりです。 ```json { "userId": 1, "id": 3, "title": "fugiat veniam minus", "completed": false } ``` HTTP Request 操作の ​**\[Advanced (詳細)\]**​ タブでデータを変換できます。また、対象変数を定義することもできます (デフォルトは \[Payload (ペイロード)\])。 この API に RAML ファイルが関連付けられている場合、その RAML ファイルをコネクタの設定要素で参照できます。これを設定し、コールする動詞とアセットを選択したら、Studio は出力に対応するメタデータを公開します。フローの他の要素とのインテグレーションが簡略化されます。 ## [](#dataweave-式を使用した動的要求の設定)DataWeave 式を使用した動的要求の設定 ほとんどのユースケースで、API へのコールをメッセージのデータに基づいて動的に変更することが求められます。この動的要求は、DataWeave 式を使用して設定できます。 「REST API のコンシュームの例」に記載されている設定例では、要求は URL 内でハードコード化されていました。 https://jsonplaceholder.typicode.com/users/1 次の GET 要求の例では、コールは、DataWeave 式 ​`#[payload.user_id]`​ を使用してメッセージのペイロードからユーザー ID を抽出するように Mule Runtime Engine に指示しています。 https://jsonplaceholder.typicode.com/users/#\[payload.user\_id\] ### [](#anypoint-studio-での動的要求の設定)Anypoint Studio での動的要求の設定 Anypoint Studio を使用して同じ操作を実行するには、目的の DataWeave 式 (この場合は ​`#['/users/' ++ payload.user_id]`​) を使用してパス設定を変更します。 ![\[Path (パス)\] 項目での DataWeave 式を使用した動的要求の設定](_images/mruntime-consume-rest-api-configuration-3.png) Figure 4. \[Path (パス)\] 項目で DataWeave 式を使用して動的要求を設定。 クエリパラメーター、URI パラメーター、または HTTP メソッドでも動的要求を設定できます。 また、​[設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties)​を使用して、このいずれかの動的要求を設定することもできます。 ### [](#xml-での動的要求の設定)XML での動的要求の設定 次の XML 形式のサンプルコードは、動的要求の設定を示しています。 ```xml <...> ``` ## [](#http-content-type-およびエンコード)HTTP Content-Type およびエンコード POST 要求を送信すると、Mule Runtime Engine は、本文の Content-Type とエンコードに関する次のルールに従います。

コンテンツ

ルール

String​、​char[]`​、​Reader​ または同様のコンテンツ*

* エンドポイントでエンコードが明示的に設定されている場合、Mule Runtime Engine はそのエンコードを使用します。 * エンドポイントでエンコードが明示的に設定されていない場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ からエンコードを決定します。 * Content-Type​ メッセージプロパティが設定されていない場合、Mule Runtime Engine は Mule コンテキストのデフォルト設定を使用します。 * Content-Type​ の場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ を送信しますが、実際のエンコードが設定されます。

バイナリコンテンツ

エンコードは関連しません。Mule Runtime Engine は ​Content-Type​ を次のように設定します。

  • Content-Type​ プロパティがメッセージで設定されている場合、Mule Runtime Engine は、定義されているコンテンツタイプを使用します。

  • Content-Type​ プロパティがメッセージで設定されていない場合、Mule Runtime Engine は「application/octet-stream」を ​Content-Type​ として設定します。
## [](#カスタムヘッダー)カスタムヘッダー API によっては、要求と共にカスタムヘッダー (開発者キーなど) を渡す必要があります。クエリパラメーターと同様に、HTTP Connector でヘッダーを要求に追加できます。 たとえば、コンシュームしている API が開発者キーを必要とする場合、ヘッダー名 ​`accessKey`​ を使用して、そのキーを要求のヘッダーとして指定します。 Anypoint Studio を使用して、プロパティを追加してカスタムヘッダーを設定できます。 ### [](#anypoint-studio-でのカスタムヘッダー)Anypoint Studio でのカスタムヘッダー Studio でカスタムヘッダーを設定するには、次の手順を参照してください。 - HTTP Request 操作のプロパティエディターで、​**\[Headers (ヘッダー)\]**​ タブを選択します。 - **\[Add (追加)\]**​ をクリックします。 - **\[Name (名前)\]**​ と ​**\[Value (値)\]**​ を定義します。どちらも、式またはプロパティプレースホルダーを使用して定義できます。 ![Studio のカスタムヘッダー設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-consume-rest-api-configuration-4.png) Figure 5. HTTP Request 操作のプロパティエディターで、\[Custom Headers (カスタムヘッダー)\] を設定します。 ## [](#セキュリティ要件)セキュリティ要件 コールしている API が複雑な認証プロトコルを必要とする場合、独自のコネクタをビルドしてその API をコンシュームできます。それ以外の場合は、基本認証ログイン情報を設定するか、グローバル HTTPS Connector を設定して、API のセキュリティ要件を満たすことができます。 ### [](#基本認証)基本認証 コールしている REST API が基本認証ログイン情報の提供を要求する場合、アウトバウンド HTTP エンドポイントの設定内で基本認証ログイン情報を指定できます。 1. Studio で \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[Authentication (認証)\] で ​**\[Basic Authentication (基本認証)\]**​ を選択します。 3. ユーザー名とパスワードを入力します。これらをプロパティプレースホルダーとして設定することもできます。 4. **\[OK\]**​ をクリックします。 ![接続タイムアウト、応答バッファサイズ、TLS の設定が表示されている HTTP 要求](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-consume-rest-api-configuration-7.png) ### [](#https-設定)HTTPS 設定 コンシュームしている REST API が、HTTPS を介して受信要求が到着することを要求する場合、Mule アプリケーションでグローバル HTTPS 要求コネクタを設定し、そのコネクタを要求操作で参照できます。 次の例では、HTTPS 要求コネクタを設定し、Java キーストアファイル (JKS) を作成し、​[TLS を設定します](https://docs.mulesoft.com/jp/mule-runtime/4.8/tls-configuration)​。 #### [](#https-用-http-request-connector-の設定)HTTPS 用 HTTP Request Connector の設定 1. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、\[General (一般)\] タブ > \[Connection Configuration (接続設定)\] セクションに移動します。 2. **\[Protocol (プロトコル)\]**​ で ​**\[HTTPS\]**​ を選択します。 3. **\[OK\]**​ をクリックします。 ![プロトコル、ホスト、ポート、永続接続の設定が表示されている HTTP 要求](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-consume-rest-api-configuration-5.png) Figure 6. HTTPS 要求コネクタの設定。 #### [](#キーストアファイルの作成)キーストアファイルの作成 Java インストールの bin ディレクトリにある Java keytool を使用して、通信を認証するためのキーストアファイルを作成します。 1. コマンドラインを使用して、使用しているマシンの Java インストールディレクトリに移動します。 2. 次のコマンドを実行します。 keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks 1. 2 つのパスワードを作成するように促されたら作成し、後で使用するために覚えておきます。 このアクションにより、​`keystore.jks`​ という名前の ​`jks`​ ファイルがローカルディレクトリに作成されます。 2. `keystore.jks`​ ファイルを配置します。 - Studio を使用する場合、​`keystore.jks`​ ファイルを Studio の Package Explorer の ​`appname/src/main/resources`​ ディレクトリに配置します。 - Mule Runtime Engine で XML を使用し、ファイルを複数のアプリケーションで使用する場合、​`MULE_HOME/conf`​ ディレクトリにファイルを配置します。 - Mule Runtime Engine で XML を使用し、ファイルをこのアプリケーション内で使用する場合、​`yourappname/src/main/resources`​ ディレクトリにファイルを配置します。 1. グローバル HTTPS 要求コネクタでキーストアを参照します。 次に、このコネクタはフロー内で HTTP アウトバウンドエンドポイントにより参照されます。 #### [](#tls-を設定する)TLS を設定する 以下の手順に従って、TLS を設定します。 1. Studio で、\[Global Elements (グローバル要素)\] ビューに移動します。 2. **\[Create (作成)\]**​ を選択し、「TLS Context (TLS コンテキスト)」を検索します。 3. \[Key Store Configuration (キーストア設定)\] セクションで、キーストア設定の \[Type (種別)\] をドロップダウンメニューから選択します。たとえば、デフォルトの種別である ​**\[JKS\]**​ (Java キーストア) を選択します。 4. キーストアを ​`appname/src/main/resources`​ ディレクトリに配置している場合は、​**\[Path (パス)\]**​ にキーストアの名前を指定し、それ以外の場合は ​`"/keystore.jks"`​ を指定します。 5. **\[Key Password (キーパスワード)\]**​ と ​**\[Password (パスワード)\]**​ には、キーストアファイルの作成時に作成したパスワードを入力します。 6. **\[OK\]**​ をクリックします。 ![トラストストアおよびキーストアの設定が表示されている TLS 設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-consume-rest-api-configuration-6.png) Figure 7. TLS を設定します。 1. \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[TLS Configuration (TLS 設定)\] で ​**\[Global Reference (グローバル参照)\]**​ と、以前作成した ​**\[TLS context (TLS コンテキスト)\]**​ 値を選択します。 TLS コンテキストはインラインで作成することもできます。 ![TLS とプロキシの詳細が含まれる HTTP 要求設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-consume-rest-api-configuration-8.png) Figure 8. HTTP 要求設定での TLS の設定。 # API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。SOAP または REST API からデータをコンシュームするには、以下のプロセスを参照してください。 ## [](#soap-api-からのデータのコンシューム)SOAP API からのデータのコンシューム 独自の Anypoint Connector を持たない SOAP API からデータをコンシュームするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を設定します。 コネクタは API の WSDL ファイルから取得したホスト、ポート、およびアドレスメタデータを使用して、Mule アプリケーション内からサービスをコンシュームするために必要な接続設定を提供します。 詳細は、​[「Web Service Consumer Connector」](https://docs.mulesoft.com/web-service-consumer-connector/latest/)​を参照してください。 ## [](#rest-api-からのデータのコンシューム)REST API からのデータのコンシューム 以下のプロセスでは、REST API をコールするための HTTP Request Connector の設定に焦点が当てられています。これは、Mule アプリケーションが REST API をコンシュームする方法の基本構造、必要な最小限の設定、コンシューム方法の例、動的要求の設定方法、HTTP Content-Type とエンコードの管理方法、カスタムヘッダーの操作方法、およびセキュリティ要件を理解するのに役立ちます。 Mule アプリケーション内で REST API からデータをコンシュームするには、HTTP 要求用 Anypoint Connector (HTTP Request Connector) を設定できます。 同じ REST API に何度も接続したり、複雑な認証プロトコルを持つ API を使用したりする場合は、​[Mule SDK を使用して独自のコネクタを開発](https://docs.mulesoft.com/mule-sdk/latest/)​することを考慮してください。接続先の API のコネクタが [Anypoint Exchange](https://anypoint.mulesoft.com/exchange/)​ にすでに存在するかどうかを確認します。Anypoint Studio の \[Mule Palette (Mule パレット)\] を使用して Exchange 内を検索できます。 ## [](#基本構造)基本構造 REST API をコンシュームする Mule アプリケーションは次の要素で構成されます。 - 要求をビルドするように設定された 1 つ以上のメッセージプロセッサー - REST API をコールするように設定された HTTP Request 操作 - 応答を受け入れて処理するように設定された 1 つ以上のメッセージプロセッサー ![REST API のコンシュームフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-consume-rest-api-flow.png) Figure 1. REST API のコンシュームフロー。 要求をビルドするアプリケーションの部分と応答を処理するアプリケーションの部分を設定します。 ## [](#最小限の設定)最小限の設定 コンシュームする REST API には、その API を記述する [RAML](http://raml.org)​ ファイルが必要です。これにより、HTTP Connector はスマート提案をユーザーにあらかじめ提供できます。 RAML ファイルでは、以下を定義します。 - 認証 - アウトバウンド HTTP エンドポイントを設定するためのベース URI - Scope (スコープ) アプリケーションは認証ログイン情報に基づいて、たとえば、コールを特定のリソースの GET 要求のみに制限したり、リソースへのアクセスを制限したりできます。 - リソース アウトバウンド HTTP エンドポイントのリソースのパスを設定する必要があります。 - メソッド POST を HTTP アウトバウンドエンドポイントのデフォルトメソッドとして受け入れたり、そのデフォルトを、リソースでサポートされているメソッドに変更したりできます。 - Input validation (入力規則) 通常、POST および PUT コールの場合、API は、入力形式 (JSON、XML など) がそのスキーマに一致していることを要求します。 Mule Runtime Engine で、以下を定義または設定できます。 - Output format (出力形式) HTTP Request 操作の後、メッセージプロセッサーをフローに含めて、フローで API からの応答を受け入れて使用可能な形式に変換する必要があります。 - Redirect (リダイレクト) API でリダイレクトを使用する場合、HTTP Request 操作でリダイレクトを有効にします。 - Timeout (タイムアウト) - Headers for methods (メソッドのヘッダー) ほとんどの場合、POST、PUT、DELETE 要求にはヘッダーが必要です。 - URI およびクエリパラメーター - エラー処理 要求操作の設定方法についての詳細は、​[HTTP Connector のドキュメント](https://docs.mulesoft.com/http-connector/latest/#input-sources)​を参照してください。 ### [](#rest-api-のコンシュームの例)REST API のコンシュームの例 次の例では、 [JSONPlaceholder API](https://jsonplaceholder.typicode.com/todos/1)​ をコンシュームします。この例には、HTTP Request Connector の設定のみが示されています。これを正常に機能させるには、フロー内でメッセージをトリガーする 1 つ以上の Mule イベントソースと、応答を受け入れる 1 つ以上のメッセージプロセッサーを設定する必要があります。詳細は、​[「REST API の例」](https://docs.mulesoft.com/jp/mule-runtime/4.9/rest-api-examples)​のドキュメントを参照してください。 この API の例について説明します。 - この API は認証を必要としません。 - ベース URL は ​`jsonplaceholder.typicode.com`​ です。 - この API は開発目的のモック API です。 - `id=1`​ のユーザーに関する情報を取得するには要求が次のようになっている必要があることをこのサンプル API 要求は示しています。 https://jsonplaceholder.typicode.com/users/1 URL の各部は次のとおりです。 - Protocol (プロトコル): `http` - API Base URL (API のベース URL): `jsonplaceholder.typicode.com` - Resource path (リソースパス): `/users/1` - Query Parameters (クエリパラメーター): この場合は \[None (なし)\]。 このコールを Mule アプリケーションに実装するには、HTTP Request 操作を設定します。 ### [](#anypoint-studio-での-http-request-操作の設定)Anypoint Studio での HTTP Request 操作の設定 1. Studio の \[Mule Palette (Mule パレット)\] から、HTTP Request Connector をアプリケーションに追加します。 2. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、​**\[Host (ホスト)\]**​ の値として ​`jsonplaceholder.typicode.com`​ を指定します。 3. **\[Port (ポート)\]**​ の値を 80 に設定します。 4. **\[OK\]**​ をクリックします。 ![\[Host (ホスト)\] と \[Port (ポート)\] を含む \[HTTP Request configuration (HTTP 要求設定)\]](_images/mruntime-consume-rest-api-configuration-1.png) Figure 2. \[Host (ホスト)\] と \[Port (ポート)\] を含む \[HTTP Request configuration (HTTP 要求設定)\]。 1. HTTP Request 操作のプロパティエディター > \[General (一般)\] タブから \[Request (要求)\] セクションに移動して、​**\[Path (パス)\]**​ 項目に ​`/users/1`​ を追加します。 最初のステップでホストを指定することで識別を開始した URL は、このパスの指定により完了します。 1. **\[Method (メソッド)\]**​ ドロップダウンリストからメソッドを選択します (この例では ​`GET`​)。 2. アプリケーションを保存します。 ![HTTP 要求の GET メソッドとパス](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-consume-rest-api-configuration-2.png) Figure 3. HTTP 要求の GET メソッドとパス。 ### [](#xml-での-http-request-操作の設定)XML での HTTP Request 操作の設定 次の XML コードは、例の HTTP Request 操作の設定を示しています。 ```xml <...> ``` ### [](#json-応答の例)JSON 応答の例 JSONPlaceholder API の例の JSON 応答の構造は次のとおりです。 ```json { "userId": 1, "id": 3, "title": "fugiat veniam minus", "completed": false } ``` HTTP Request 操作の ​**\[Advanced (詳細)\]**​ タブでデータを変換できます。また、対象変数を定義することもできます (デフォルトは \[Payload (ペイロード)\])。 この API に RAML ファイルが関連付けられている場合、その RAML ファイルをコネクタの設定要素で参照できます。これを設定し、コールする動詞とアセットを選択したら、Studio は出力に対応するメタデータを公開します。フローの他の要素とのインテグレーションが簡略化されます。 ## [](#dataweave-式を使用した動的要求の設定)DataWeave 式を使用した動的要求の設定 ほとんどのユースケースで、API へのコールをメッセージのデータに基づいて動的に変更することが求められます。この動的要求は、DataWeave 式を使用して設定できます。 「REST API のコンシュームの例」に記載されている設定例では、要求は URL 内でハードコード化されていました。 https://jsonplaceholder.typicode.com/users/1 次の GET 要求の例では、コールは、DataWeave 式 ​`#[payload.user_id]`​ を使用してメッセージのペイロードからユーザー ID を抽出するように Mule Runtime Engine に指示しています。 https://jsonplaceholder.typicode.com/users/#\[payload.user\_id\] ### [](#anypoint-studio-での動的要求の設定)Anypoint Studio での動的要求の設定 Anypoint Studio を使用して同じ操作を実行するには、目的の DataWeave 式 (この場合は ​`#['/users/' ++ payload.user_id]`​) を使用してパス設定を変更します。 ![\[Path (パス)\] 項目での DataWeave 式を使用した動的要求の設定](_images/mruntime-consume-rest-api-configuration-3.png) Figure 4. \[Path (パス)\] 項目で DataWeave 式を使用して動的要求を設定。 クエリパラメーター、URI パラメーター、または HTTP メソッドでも動的要求を設定できます。 また、​[設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties)​を使用して、このいずれかの動的要求を設定することもできます。 ### [](#xml-での動的要求の設定)XML での動的要求の設定 次の XML 形式のサンプルコードは、動的要求の設定を示しています。 ```xml <...> ``` ## [](#http-content-type-およびエンコード)HTTP Content-Type およびエンコード POST 要求を送信すると、Mule Runtime Engine は、本文の Content-Type とエンコードに関する次のルールに従います。

コンテンツ

ルール

String​、​char[]`​、​Reader​ または同様のコンテンツ*

* エンドポイントでエンコードが明示的に設定されている場合、Mule Runtime Engine はそのエンコードを使用します。 * エンドポイントでエンコードが明示的に設定されていない場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ からエンコードを決定します。 * Content-Type​ メッセージプロパティが設定されていない場合、Mule Runtime Engine は Mule コンテキストのデフォルト設定を使用します。 * Content-Type​ の場合、Mule Runtime Engine はメッセージプロパティ ​Content-Type​ を送信しますが、実際のエンコードが設定されます。

バイナリコンテンツ

エンコードは関連しません。Mule Runtime Engine は ​Content-Type​ を次のように設定します。

  • Content-Type​ プロパティがメッセージで設定されている場合、Mule Runtime Engine は、定義されているコンテンツタイプを使用します。

  • Content-Type​ プロパティがメッセージで設定されていない場合、Mule Runtime Engine は「application/octet-stream」を ​Content-Type​ として設定します。
## [](#カスタムヘッダー)カスタムヘッダー API によっては、要求と共にカスタムヘッダー (開発者キーなど) を渡す必要があります。クエリパラメーターと同様に、HTTP Connector でヘッダーを要求に追加できます。 たとえば、コンシュームしている API が開発者キーを必要とする場合、ヘッダー名 ​`accessKey`​ を使用して、そのキーをリクエストヘッダーとして指定します。 Anypoint Studio を使用して、プロパティを追加してカスタムヘッダーを設定できます。 ### [](#anypoint-studio-でのカスタムヘッダー)Anypoint Studio でのカスタムヘッダー Studio でカスタムヘッダーを設定するには、次の手順を参照してください。 - HTTP Request 操作のプロパティエディターで、​**\[Headers (ヘッダー)\]**​ タブを選択します。 - **\[Add (追加)\]**​ をクリックします。 - **\[Name (名前)\]**​ と ​**\[Value (値)\]**​ を定義します。どちらも、式またはプロパティプレースホルダーを使用して定義できます。 ![Studio のカスタムヘッダー設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-consume-rest-api-configuration-4.png) Figure 5. HTTP Request 操作のプロパティエディターで、\[Custom Headers (カスタムヘッダー)\] を設定します。 ## [](#セキュリティ要件)セキュリティ要件 コールしている API が複雑な認証プロトコルを必要とする場合、独自のコネクタをビルドしてその API をコンシュームできます。それ以外の場合は、基本認証ログイン情報を設定するか、グローバル HTTPS Connector を設定して、API のセキュリティ要件を満たすことができます。 ### [](#基本認証)基本認証 コールしている REST API が基本認証ログイン情報の提供を要求する場合、アウトバウンド HTTP エンドポイントの設定内で基本認証ログイン情報を指定できます。 1. Studio で \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[Authentication (認証)\] で ​**\[Basic Authentication (基本認証)\]**​ を選択します。 3. ユーザー名とパスワードを入力します。これらをプロパティプレースホルダーとして設定することもできます。 4. **\[OK\]**​ をクリックします。 ![接続タイムアウト、応答バッファサイズ、TLS の設定が表示されている HTTP 要求](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-consume-rest-api-configuration-7.png) ### [](#https-設定)HTTPS 設定 コンシュームしている REST API が、HTTPS を介して受信要求が到着することを要求する場合、Mule アプリケーションでグローバル HTTPS 要求コネクタを設定し、そのコネクタを要求操作で参照できます。 次の例では、HTTPS 要求コネクタを設定し、Java キーストアファイル (JKS) を作成し、​[TLS を設定します](https://docs.mulesoft.com/jp/mule-runtime/4.9/tls-configuration)​。 #### [](#https-用-http-request-connector-の設定)HTTPS 用 HTTP Request Connector の設定 1. \[HTTP Request Configuration (HTTP 要求設定)\] ウィンドウで、\[General (一般)\] タブ > \[Connection Configuration (接続設定)\] セクションに移動します。 2. **\[Protocol (プロトコル)\]**​ で ​**\[HTTPS\]**​ を選択します。 3. **\[OK\]**​ をクリックします。 ![プロトコル、ホスト、ポート、永続接続の設定が表示されている HTTP 要求](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-consume-rest-api-configuration-5.png) Figure 6. HTTPS 要求コネクタの設定。 #### [](#キーストアファイルの作成)キーストアファイルの作成 Java インストールの bin ディレクトリにある Java keytool を使用して、通信を認証するためのキーストアファイルを作成します。 1. コマンドラインを使用して、使用しているマシンの Java インストールディレクトリに移動します。 2. 次のコマンドを実行します。 keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks 1. 2 つのパスワードを作成するように促されたら作成し、後で使用するために覚えておきます。 このアクションにより、​`keystore.jks`​ という名前の ​`jks`​ ファイルがローカルディレクトリに作成されます。 2. `keystore.jks`​ ファイルを配置します。 - Studio を使用する場合、​`keystore.jks`​ ファイルを Studio の Package Explorer の ​`appname/src/main/resources`​ ディレクトリに配置します。 - Mule Runtime Engine で XML を使用し、ファイルを複数のアプリケーションで使用する場合、​`MULE_HOME/conf`​ ディレクトリにファイルを配置します。 - Mule Runtime Engine で XML を使用し、ファイルをこのアプリケーション内で使用する場合、​`yourappname/src/main/resources`​ ディレクトリにファイルを配置します。 1. グローバル HTTPS 要求コネクタでキーストアを参照します。 次に、このコネクタはフロー内で HTTP アウトバウンドエンドポイントにより参照されます。 #### [](#tls-を設定する)TLS を設定する 以下の手順に従って、TLS を設定します。 1. Studio で、\[Global Elements (グローバル要素)\] ビューに移動します。 2. **\[Create (作成)\]**​ を選択し、「TLS Context (TLS コンテキスト)」を検索します。 3. \[Key Store Configuration (キーストア設定)\] セクションで、キーストア設定の \[Type (種別)\] をドロップダウンメニューから選択します。たとえば、デフォルトの種別である ​**\[JKS\]**​ (Java キーストア) を選択します。 4. キーストアを ​`appname/src/main/resources`​ ディレクトリに配置している場合は、​**\[Path (パス)\]**​ にキーストアの名前を指定し、それ以外の場合は ​`"/keystore.jks"`​ を指定します。 5. **\[Key Password (キーパスワード)\]**​ と ​**\[Password (パスワード)\]**​ には、キーストアファイルの作成時に作成したパスワードを入力します。 6. **\[OK\]**​ をクリックします。 ![トラストストアおよびキーストアの設定が表示されている TLS 設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-consume-rest-api-configuration-6.png) Figure 7. TLS を設定します。 1. \[HTTP Request configuration (HTTP 要求設定)\] ウィンドウに移動します。 2. \[TLS Configuration (TLS 設定)\] で ​**\[Global Reference (グローバル参照)\]**​ と、以前作成した ​**\[TLS context (TLS コンテキスト)\]**​ 値を選択します。 TLS コンテキストはインラインで作成することもできます。 ![TLS とプロキシの詳細が含まれる HTTP 要求設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-consume-rest-api-configuration-8.png) Figure 8. HTTP 要求設定での TLS の設定。 # API ゲートウェイの移行 このセクションでは、API ゲートウェイに関連する機能の移行について説明します。以下のトピックを取り上げます。 - [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-autodiscovery) - [API Manager で管理される Mule 3 アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migrate-mule3-apimanager) - [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-policies) - [API ゲートウェイの移行: プロキシ](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-proxies) - [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-runtime-config) ## [](#関連情報)関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-core) # API ゲートウェイの移行 このセクションでは、API ゲートウェイに関連する機能の移行について説明します。以下のトピックを取り上げます。 - [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-autodiscovery) - [API Manager で管理される Mule 3 アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migrate-mule3-apimanager) - [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-policies) - [API ゲートウェイの移行: プロキシ](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-proxies) - [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-runtime-config) ## [](#関連情報)関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-core) # API ゲートウェイの移行 このセクションでは、API ゲートウェイに関連する機能の移行について説明します。以下のトピックを取り上げます。 - [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-autodiscovery) - [API Manager で管理される Mule 3 アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migrate-mule3-apimanager) - [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-policies) - [API ゲートウェイの移行: プロキシ](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-proxies) - [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-runtime-config) ## [](#関連情報)関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-core) # API ゲートウェイの移行 このセクションでは、API ゲートウェイに関連する機能の移行について説明します。以下のトピックを取り上げます。 - [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-autodiscovery) - [API Manager で管理される Mule 3 アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migrate-mule3-apimanager) - [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-policies) - [API ゲートウェイの移行: プロキシ](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-proxies) - [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-runtime-config) ## [](#関連情報)関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-core) # API ゲートウェイの移行 このセクションでは、API ゲートウェイに関連する機能の移行について説明します。以下のトピックを取り上げます。 - [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-autodiscovery) - [API Manager で管理される Mule 3 アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migrate-mule3-apimanager) - [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-policies) - [API ゲートウェイの移行: プロキシ](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-proxies) - [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-runtime-config) ## [](#関連情報)関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-core) # API ゲートウェイの移行 このセクションでは、API ゲートウェイに関連する機能の移行について説明します。以下のトピックを取り上げます。 - [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-autodiscovery) - [API Manager で管理される Mule 3 アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migrate-mule3-apimanager) - [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-policies) - [API ゲートウェイの移行: プロキシ](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-proxies) - [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-runtime-config) ## [](#関連情報)関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-core) # API ゲートウェイの移行 このセクションでは、API ゲートウェイに関連する機能の移行について説明します。以下のトピックを取り上げます。 - [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-autodiscovery) - [API Manager で管理される Mule 3 アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migrate-mule3-apimanager) - [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-policies) - [API ゲートウェイの移行: プロキシ](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-proxies) - [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-runtime-config) ## [](#関連情報)関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-core) # API ゲートウェイの移行: Autodiscovery Autodiscovery 要素は Mule 4 のリリース後に更新されています。 - API は、名前とバージョンではなく、ID で参照されます。 - API をランタイムから作成できなくなりました。 HTTP リスナーと Autodiscovery 要素を備えたシンプルな Mule アプリケーションは次のように定義されます。 Mule 3 の例: すべての設定可能な属性 ```xml This is a test API tag1 tag2 ``` Mule 4 の例: すべての設定可能な属性 ```xml ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-policies) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-runtime-config) # API ゲートウェイの移行: Autodiscovery Autodiscovery 要素は Mule 4 のリリース後に更新されています。 - API は、名前とバージョンではなく、ID で参照されます。 - API をランタイムから作成できなくなりました。 HTTP リスナーと Autodiscovery 要素を備えたシンプルな Mule アプリケーションは次のように定義されます。 Mule 3 の例: すべての設定可能な属性 ```xml This is a test API tag1 tag2 ``` Mule 4 の例: すべての設定可能な属性 ```xml ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-policies) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-runtime-config) # API ゲートウェイの移行: Autodiscovery Autodiscovery 要素は Mule 4 のリリース後に更新されています。 - API は、名前とバージョンではなく、ID で参照されます。 - API をランタイムから作成できなくなりました。 HTTP リスナーと Autodiscovery 要素を備えたシンプルな Mule アプリケーションは次のように定義されます。 Mule 3 の例: すべての設定可能な属性 ```xml This is a test API tag1 tag2 ``` Mule 4 の例: すべての設定可能な属性 ```xml ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-policies) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-runtime-config) # API ゲートウェイの移行: Autodiscovery Autodiscovery 要素は Mule 4 のリリース後に更新されています。 - API は、名前とバージョンではなく、ID で参照されます。 - API をランタイムから作成できなくなりました。 HTTP リスナーと Autodiscovery 要素を備えたシンプルな Mule アプリケーションは次のように定義されます。 Mule 3 の例: すべての設定可能な属性 ```xml This is a test API tag1 tag2 ``` Mule 4 の例: すべての設定可能な属性 ```xml ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-policies) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-runtime-config) # API ゲートウェイの移行: Autodiscovery Autodiscovery 要素は Mule 4 のリリース後に更新されています。 - API は、名前とバージョンではなく、ID で参照されます。 - API をランタイムから作成できなくなりました。 HTTP リスナーと Autodiscovery 要素を備えたシンプルな Mule アプリケーションは次のように定義されます。 Mule 3 の例: すべての設定可能な属性 ```xml This is a test API tag1 tag2 ``` Mule 4 の例: すべての設定可能な属性 ```xml ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-policies) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-runtime-config) # API ゲートウェイの移行: Autodiscovery Autodiscovery 要素は Mule 4 のリリース後に更新されています。 - API は、名前とバージョンではなく、ID で参照されます。 - API をランタイムから作成できなくなりました。 HTTP リスナーと Autodiscovery 要素を備えたシンプルな Mule アプリケーションは次のように定義されます。 Mule 3 の例: すべての設定可能な属性 ```xml This is a test API tag1 tag2 ``` Mule 4 の例: すべての設定可能な属性 ```xml ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-policies) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-runtime-config) # API ゲートウェイの移行: Autodiscovery Autodiscovery 要素は Mule 4 のリリース後に更新されています。 - API は、名前とバージョンではなく、ID で参照されます。 - API をランタイムから作成できなくなりました。 HTTP リスナーと Autodiscovery 要素を備えたシンプルな Mule アプリケーションは次のように定義されます。 Mule 3 の例: すべての設定可能な属性 ```xml This is a test API tag1 tag2 ``` Mule 4 の例: すべての設定可能な属性 ```xml ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-policies) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-runtime-config) # API ゲートウェイの移行: Mule Runtime の設定 Mule 4 では、API ゲートウェイの Runtime の設定プロパティが変更されています。 Mule 3 を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.platform_base_uri=https://anypoint.mulesoft.com/apiplatform -M-Danypoint.platform.coreservice_base_uri=https://anypoint.mulesoft.com/accounts -M-Danypoint.platform.contracts_base_uri=https://anypoint.mulesoft.com/apigateway/ccs -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` Mule 4 以降を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.base_uri=https://anypoint.mulesoft.com -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-policies) # API ゲートウェイの移行: Mule Runtime の設定 Mule 4 では、API ゲートウェイの Runtime の設定プロパティが変更されています。 Mule 3 を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.platform_base_uri=https://anypoint.mulesoft.com/apiplatform -M-Danypoint.platform.coreservice_base_uri=https://anypoint.mulesoft.com/accounts -M-Danypoint.platform.contracts_base_uri=https://anypoint.mulesoft.com/apigateway/ccs -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` Mule 4 以降を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.base_uri=https://anypoint.mulesoft.com -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-policies) # API ゲートウェイの移行: Mule Runtime の設定 Mule 4 では、API ゲートウェイの Runtime の設定プロパティが変更されています。 Mule 3 を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.platform_base_uri=https://anypoint.mulesoft.com/apiplatform -M-Danypoint.platform.coreservice_base_uri=https://anypoint.mulesoft.com/accounts -M-Danypoint.platform.contracts_base_uri=https://anypoint.mulesoft.com/apigateway/ccs -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` Mule 4 以降を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.base_uri=https://anypoint.mulesoft.com -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-policies) # API ゲートウェイの移行: Mule Runtime の設定 Mule 4 では、API ゲートウェイの Runtime の設定プロパティが変更されています。 Mule 3 を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.platform_base_uri=https://anypoint.mulesoft.com/apiplatform -M-Danypoint.platform.coreservice_base_uri=https://anypoint.mulesoft.com/accounts -M-Danypoint.platform.contracts_base_uri=https://anypoint.mulesoft.com/apigateway/ccs -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` Mule 4 以降を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.base_uri=https://anypoint.mulesoft.com -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-policies) # API ゲートウェイの移行: Mule Runtime の設定 Mule 4 では、API ゲートウェイの Runtime の設定プロパティが変更されています。 Mule 3 を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.platform_base_uri=https://anypoint.mulesoft.com/apiplatform -M-Danypoint.platform.coreservice_base_uri=https://anypoint.mulesoft.com/accounts -M-Danypoint.platform.contracts_base_uri=https://anypoint.mulesoft.com/apigateway/ccs -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` Mule 4 以降を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.base_uri=https://anypoint.mulesoft.com -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-policies) # API ゲートウェイの移行: Mule Runtime の設定 Mule 4 では、API ゲートウェイの Runtime の設定プロパティが変更されています。 Mule 3 を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.platform_base_uri=https://anypoint.mulesoft.com/apiplatform -M-Danypoint.platform.coreservice_base_uri=https://anypoint.mulesoft.com/accounts -M-Danypoint.platform.contracts_base_uri=https://anypoint.mulesoft.com/apigateway/ccs -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` Mule 4 以降を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.base_uri=https://anypoint.mulesoft.com -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-policies) # API ゲートウェイの移行: Mule Runtime の設定 Mule 4 では、API ゲートウェイの Runtime の設定プロパティが変更されています。 Mule 3 を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.platform_base_uri=https://anypoint.mulesoft.com/apiplatform -M-Danypoint.platform.coreservice_base_uri=https://anypoint.mulesoft.com/accounts -M-Danypoint.platform.contracts_base_uri=https://anypoint.mulesoft.com/apigateway/ccs -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` Mule 4 以降を API ゲートウェイとして機能させるためには、​`wrapper.conf`​ で設定プロパティを次のとおり定義する必要があります。 ```text -M-Danypoint.platform.client_id=clientId -M-Danypoint.platform.client_secret=clientSecret -M-Danypoint.platform.base_uri=https://anypoint.mulesoft.com -M-Danypoint.platform.analytics_base_uri=https://analytics-ingest.anypoint.mulesoft.com ``` ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: ポリシー](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-policies) # API プロキシの移行 ## [](#performing_migration)プロキシの移行の実行 プロキシの移行を実行するこの例では、Mule Migration Assistant (MMA) を使用します。 この手順では、ツールの​ [前提条件​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 プロキシを移行するための MMA コマンドは、Mule アプリケーションを移行するための標準の [コマンドラインオプション (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ を使用します。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-proxy/ \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-proxy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-proxy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-proxy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - プロキシ POM ファイル。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、プロキシ XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにプロキシ XML ファイルが含まれます。​`mule`​ ディレクトリと同じレベルで、移行したプロキシに必要な DataWeave ファイルまたはその他のファイル用の ​`resources`​ ディレクトリが作成されます。 アーティファクトを適切にデプロイするには、プロキシ XML で定義された設定ファイルが ​`resources`​ ディレクトリに存在する必要があります。​`test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したプロキシを Exchange にアップロードできます。カスタムアプリケーションのアップロードについての詳細は、 [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/exchange/to-publish-assets-maven)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムプロキシを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行​_後_​: - ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がプロキシの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はプロキシアプリケーションのベースディレクトリの名前です。たとえば、​`mytestproxy/src/main/app/proxy.xml`​ 内のプロキシの場合、​`artifactId`​ は ​`mytestproxy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

api-platform-gw:tags​

Mule 4 では、API の自動作成は無効です。

api-platform-gw:description

Mule 4 では、API の自動作成は無効です。
これらの各要素では、子要素も削除されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にプロキシファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がプロキシの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#raml_proxy_migration)RAML プロキシの移行 RAML プロキシ要素は REST プロキシ要素に移行されます。
Mule 3 Mule 4

proxy:raml-proxy-config​。

rest-validator:config​。

proxy:raml​。

rest-validator:validate-request​。

apikit:mapping-exception-strategy​。

rest-validator:validate-request​ 要素を含むフロー内の ​on-error-continue​ 要素を使用する ​error-handler​。
`error-handler`​ 要素には、​`on-error-continue`​ 要素の次の型が含まれます。
型 Status Code

REST-VALIDATOR:BAD_REQUEST​

400

REST-VALIDATOR:RESOURCE_NOT_FOUND​

404

REST-VALIDATOR:METHOD_NOT_ALLOWED​

405

HTTP:TIMEOUT

504
Mule 3 要素に見つからない例外は、Mule Migration Assistant によってオートコンプリートされます。 ### [](#wsdl_proxy_migration)WSDL プロキシの移行 WSDL プロキシの移行は、WSDL プロパティの属性値の移行で構成されます。Mule 3 では、ほとんどの値は属性値として定義された関数を使用して抽出されます。Mule 4 には同等のプロセスがないため、ほとんどのプロパティはデフォルト値に移行され、​`service`​ キーワードで始まる WSDL ファイルの値を使用して手動で設定する必要があります。 一部のプロパティは、よりわかりやすい方法で値を抽出するために名前が変更されています。次に例を示します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.name]

${service.port}

![wsdl(p['wsdl.uri']).targetNamespace]​

${service.namespace}

![wsdl(p['wsdl.uri']).services[0].name]​

${service.name}
次のようなその他のプロパティは、MMA によって提供される WSDL 関数拡張の連動関係を使用する DataWeave 式に移行され、期待値を抽出します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].port]

#[Wsdl::getPort('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].host]

#[Wsdl::getHost('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].path]

#[Wsdl::getPath('${wsdl.uri}','${service.name}','${service.port}')]
## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-core) [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/exchange/to-publish-assets-maven) # API プロキシの移行 ## [](#performing_migration)プロキシの移行の実行 プロキシの移行を実行するこの例では、Mule Migration Assistant (MMA) を使用します。 この手順では、ツールの​ [前提条件​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 プロキシを移行するための MMA コマンドは、Mule アプリケーションを移行するための標準の [コマンドラインオプション (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ を使用します。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-proxy/ \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-proxy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-proxy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-proxy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - プロキシ POM ファイル。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、プロキシ XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにプロキシ XML ファイルが含まれます。​`mule`​ ディレクトリと同じレベルで、移行したプロキシに必要な DataWeave ファイルまたはその他のファイル用の ​`resources`​ ディレクトリが作成されます。 アーティファクトを適切にデプロイするには、プロキシ XML で定義された設定ファイルが ​`resources`​ ディレクトリに存在する必要があります。​`test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したプロキシを Exchange にアップロードできます。カスタムアプリケーションのアップロードについての詳細は、 [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/exchange/to-publish-assets-maven)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムプロキシを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行​_後_​: - ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がプロキシの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はプロキシアプリケーションのベースディレクトリの名前です。たとえば、​`mytestproxy/src/main/app/proxy.xml`​ 内のプロキシの場合、​`artifactId`​ は ​`mytestproxy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

api-platform-gw:tags​

Mule 4 では、API の自動作成は無効です。

api-platform-gw:description

Mule 4 では、API の自動作成は無効です。
これらの各要素では、子要素も削除されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にプロキシファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がプロキシの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#raml_proxy_migration)RAML プロキシの移行 RAML プロキシ要素は REST プロキシ要素に移行されます。
Mule 3 Mule 4

proxy:raml-proxy-config​。

rest-validator:config​。

proxy:raml​。

rest-validator:validate-request​。

apikit:mapping-exception-strategy​。

rest-validator:validate-request​ 要素を含むフロー内の ​on-error-continue​ 要素を使用する ​error-handler​。
`error-handler`​ 要素には、​`on-error-continue`​ 要素の次の型が含まれます。
型 Status Code

REST-VALIDATOR:BAD_REQUEST​

400

REST-VALIDATOR:RESOURCE_NOT_FOUND​

404

REST-VALIDATOR:METHOD_NOT_ALLOWED​

405

HTTP:TIMEOUT

504
Mule 3 要素に見つからない例外は、Mule Migration Assistant によってオートコンプリートされます。 ### [](#wsdl_proxy_migration)WSDL プロキシの移行 WSDL プロキシの移行は、WSDL プロパティの属性値の移行で構成されます。Mule 3 では、ほとんどの値は属性値として定義された関数を使用して抽出されます。Mule 4 には同等のプロセスがないため、ほとんどのプロパティはデフォルト値に移行され、​`service`​ キーワードで始まる WSDL ファイルの値を使用して手動で設定する必要があります。 一部のプロパティは、よりわかりやすい方法で値を抽出するために名前が変更されています。次に例を示します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.name]

${service.port}

![wsdl(p['wsdl.uri']).targetNamespace]​

${service.namespace}

![wsdl(p['wsdl.uri']).services[0].name]​

${service.name}
次のようなその他のプロパティは、MMA によって提供される WSDL 関数拡張の連動関係を使用する DataWeave 式に移行され、期待値を抽出します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].port]

#[Wsdl::getPort('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].host]

#[Wsdl::getHost('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].path]

#[Wsdl::getPath('${wsdl.uri}','${service.name}','${service.port}')]
## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-core) [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/exchange/to-publish-assets-maven) # API プロキシの移行 ## [](#performing_migration)プロキシの移行の実行 プロキシの移行を実行するこの例では、Mule Migration Assistant (MMA) を使用します。 この手順では、ツールの​ [前提条件​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 プロキシを移行するための MMA コマンドは、Mule アプリケーションを移行するための標準の [コマンドラインオプション(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ を使用します。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-proxy/ \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-proxy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-proxy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-proxy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - プロキシ POM ファイル。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、プロキシ XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにプロキシ XML ファイルが含まれます。​`mule`​ ディレクトリと同じレベルで、移行したプロキシに必要な DataWeave ファイルまたはその他のファイル用の ​`resources`​ ディレクトリが作成されます。 アーティファクトを適切にデプロイするには、プロキシ XML で定義された設定ファイルが ​`resources`​ ディレクトリに存在する必要があります。​`test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、「​[POM の移行](#pom_migration)​」で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したプロキシを Exchange にアップロードできます。カスタムアプリケーションのアップロードについての詳細は、 [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/exchange/to-publish-assets-maven)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムプロキシを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行​_後_​: - ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がプロキシの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はプロキシアプリケーションのベースディレクトリの名前です。たとえば、​`mytestproxy/src/main/app/proxy.xml`​ 内のプロキシの場合、​`artifactId`​ は ​`mytestproxy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

api-platform-gw:tags​

Mule 4 では、API の自動作成は無効です。

api-platform-gw:description

Mule 4 では、API の自動作成は無効です。
これらの各要素では、子要素も削除されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にプロキシファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がプロキシの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#raml_proxy_migration)RAML プロキシの移行 RAML プロキシ要素は REST プロキシ要素に移行されます。
Mule 3 Mule 4

proxy:raml-proxy-config​.

rest-validator:config​。

proxy:raml​.

rest-validator:validate-request​。

apikit:mapping-exception-strategy​.

rest-validator:validate-request​ 要素を含むフロー内の ​on-error-continue​ 要素を使用する ​error-handler​。
`error-handler`​ 要素には、​`on-error-continue`​ 要素の次の型が含まれます。
型 状況コード

REST-VALIDATOR:BAD_REQUEST​

400

REST-VALIDATOR:RESOURCE_NOT_FOUND​

404

REST-VALIDATOR:METHOD_NOT_ALLOWED​

405

HTTP:TIMEOUT

504
Mule 3 要素に見つからない例外は、Mule Migration Assistant によってオートコンプリートされます。 ### [](#wsdl_proxy_migration)WSDL プロキシの移行 WSDL プロキシの移行は、WSDL プロパティの属性値の移行で構成されます。Mule 3 では、ほとんどの値は属性値として定義された関数を使用して抽出されます。Mule 4 には同等のプロセスがないため、ほとんどのプロパティはデフォルト値に移行され、​`service`​ キーワードで始まる WSDL ファイルの値を使用して手動で設定する必要があります。 一部のプロパティは、よりわかりやすい方法で値を抽出するために名前が変更されています。次に例を示します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.name]

${service.port}

![wsdl(p['wsdl.uri']).targetNamespace]​

${service.namespace}

![wsdl(p['wsdl.uri']).services[0].name]​

${service.name}
次のようなその他のプロパティは、MMA によって提供される WSDL 関数拡張の連動関係を使用する DataWeave 式に移行され、期待値を抽出します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].port]

#[Wsdl::getPort('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].host]

#[Wsdl::getHost('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].path]

#[Wsdl::getPath('${wsdl.uri}','${service.name}','${service.port}')]
## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-core) [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/exchange/to-publish-assets-maven) # API プロキシの移行 ## [](#performing_migration)プロキシの移行の実行 プロキシの移行を実行するこの例では、Mule Migration Assistant (MMA) を使用します。 この手順では、ツールの​ [前提条件​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 プロキシを移行するための MMA コマンドは、Mule アプリケーションを移行するための標準の [コマンドラインオプション (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ を使用します。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-proxy/ \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-proxy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-proxy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-proxy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - プロキシ POM ファイル。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、プロキシ XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにプロキシ XML ファイルが含まれます。​`mule`​ ディレクトリと同じレベルで、移行したプロキシに必要な DataWeave ファイルまたはその他のファイル用の ​`resources`​ ディレクトリが作成されます。 アーティファクトを適切にデプロイするには、プロキシ XML で定義された設定ファイルが ​`resources`​ ディレクトリに存在する必要があります。​`test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したプロキシを Exchange にアップロードできます。カスタムアプリケーションのアップロードについての詳細は、 [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/exchange/to-publish-assets-maven)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムプロキシを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行​_後_​: - ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がプロキシの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はプロキシアプリケーションのベースディレクトリの名前です。たとえば、​`mytestproxy/src/main/app/proxy.xml`​ 内のプロキシの場合、​`artifactId`​ は ​`mytestproxy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

api-platform-gw:tags​

Mule 4 では、API の自動作成は無効です。

api-platform-gw:description

Mule 4 では、API の自動作成は無効です。
これらの各要素では、子要素も削除されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にプロキシファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がプロキシの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#raml_proxy_migration)RAML プロキシの移行 RAML プロキシ要素は REST プロキシ要素に移行されます。
Mule 3 Mule 4

proxy:raml-proxy-config​。

rest-validator:config​。

proxy:raml​。

rest-validator:validate-request​。

apikit:mapping-exception-strategy​。

rest-validator:validate-request​ 要素を含むフロー内の ​on-error-continue​ 要素を使用する ​error-handler​。
`error-handler`​ 要素には、​`on-error-continue`​ 要素の次の型が含まれます。
型 Status Code

REST-VALIDATOR:BAD_REQUEST​

400

REST-VALIDATOR:RESOURCE_NOT_FOUND​

404

REST-VALIDATOR:METHOD_NOT_ALLOWED​

405

HTTP:TIMEOUT

504
Mule 3 要素に見つからない例外は、Mule Migration Assistant によってオートコンプリートされます。 ### [](#wsdl_proxy_migration)WSDL プロキシの移行 WSDL プロキシの移行は、WSDL プロパティの属性値の移行で構成されます。Mule 3 では、ほとんどの値は属性値として定義された関数を使用して抽出されます。Mule 4 には同等のプロセスがないため、ほとんどのプロパティはデフォルト値に移行され、​`service`​ キーワードで始まる WSDL ファイルの値を使用して手動で設定する必要があります。 一部のプロパティは、よりわかりやすい方法で値を抽出するために名前が変更されています。次に例を示します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.name]

${service.port}

![wsdl(p['wsdl.uri']).targetNamespace]​

${service.namespace}

![wsdl(p['wsdl.uri']).services[0].name]​

${service.name}
次のようなその他のプロパティは、MMA によって提供される WSDL 関数拡張の連動関係を使用する DataWeave 式に移行され、期待値を抽出します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].port]

#[Wsdl::getPort('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].host]

#[Wsdl::getHost('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].path]

#[Wsdl::getPath('${wsdl.uri}','${service.name}','${service.port}')]
## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-core) [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/exchange/to-publish-assets-maven) # API プロキシの移行 ## [](#performing_migration)プロキシの移行の実行 プロキシの移行を実行するこの例では、Mule Migration Assistant (MMA) を使用します。 この手順では、ツールの​ [前提条件​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 プロキシを移行するための MMA コマンドは、Mule アプリケーションを移行するための標準の [コマンドラインオプション (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ を使用します。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-proxy/ \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-proxy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-proxy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-proxy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - プロキシ POM ファイル。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、プロキシ XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにプロキシ XML ファイルが含まれます。​`mule`​ ディレクトリと同じレベルで、移行したプロキシに必要な DataWeave ファイルまたはその他のファイル用の ​`resources`​ ディレクトリが作成されます。 アーティファクトを適切にデプロイするには、プロキシ XML で定義された設定ファイルが ​`resources`​ ディレクトリに存在する必要があります。​`test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したプロキシを Exchange にアップロードできます。カスタムアプリケーションのアップロードについての詳細は、 [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/exchange/to-publish-assets-maven)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムプロキシを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行​_後_​: - ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がプロキシの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はプロキシアプリケーションのベースディレクトリの名前です。たとえば、​`mytestproxy/src/main/app/proxy.xml`​ 内のプロキシの場合、​`artifactId`​ は ​`mytestproxy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

api-platform-gw:tags​

Mule 4 では、API の自動作成は無効です。

api-platform-gw:description

Mule 4 では、API の自動作成は無効です。
これらの各要素では、子要素も削除されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にプロキシファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がプロキシの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#raml_proxy_migration)RAML プロキシの移行 RAML プロキシ要素は REST プロキシ要素に移行されます。
Mule 3 Mule 4

proxy:raml-proxy-config​。

rest-validator:config​。

proxy:raml​。

rest-validator:validate-request​。

apikit:mapping-exception-strategy​。

rest-validator:validate-request​ 要素を含むフロー内の ​on-error-continue​ 要素を使用する ​error-handler​。
`error-handler`​ 要素には、​`on-error-continue`​ 要素の次の型が含まれます。
型 Status Code

REST-VALIDATOR:BAD_REQUEST​

400

REST-VALIDATOR:RESOURCE_NOT_FOUND​

404

REST-VALIDATOR:METHOD_NOT_ALLOWED​

405

HTTP:TIMEOUT

504
Mule 3 要素に見つからない例外は、Mule Migration Assistant によってオートコンプリートされます。 ### [](#wsdl_proxy_migration)WSDL プロキシの移行 WSDL プロキシの移行は、WSDL プロパティの属性値の移行で構成されます。Mule 3 では、ほとんどの値は属性値として定義された関数を使用して抽出されます。Mule 4 には同等のプロセスがないため、ほとんどのプロパティはデフォルト値に移行され、​`service`​ キーワードで始まる WSDL ファイルの値を使用して手動で設定する必要があります。 一部のプロパティは、よりわかりやすい方法で値を抽出するために名前が変更されています。次に例を示します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.name]

${service.port}

![wsdl(p['wsdl.uri']).targetNamespace]​

${service.namespace}

![wsdl(p['wsdl.uri']).services[0].name]​

${service.name}
次のようなその他のプロパティは、MMA によって提供される WSDL 関数拡張の連動関係を使用する DataWeave 式に移行され、期待値を抽出します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].port]

#[Wsdl::getPort('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].host]

#[Wsdl::getHost('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].path]

#[Wsdl::getPath('${wsdl.uri}','${service.name}','${service.port}')]
## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-core) [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/exchange/to-publish-assets-maven) # API プロキシの移行 ## [](#performing_migration)プロキシの移行の実行 プロキシの移行を実行するこの例では、Mule Migration Assistant (MMA) を使用します。 この手順では、ツールの [前提条件](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 プロキシを移行するための MMA コマンドは、Mule アプリケーションを移行するための標準の [コマンドラインオプション (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ を使用します。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-proxy/ \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-proxy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-proxy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-proxy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - プロキシ POM ファイル。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、プロキシ XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにプロキシ XML ファイルが含まれます。​`mule`​ ディレクトリと同じレベルで、移行したプロキシに必要な DataWeave ファイルまたはその他のファイル用の ​`resources`​ ディレクトリが作成されます。 アーティファクトを適切にデプロイするには、プロキシ XML で定義された設定ファイルが ​`resources`​ ディレクトリに存在する必要があります。​`test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したプロキシを Exchange にアップロードできます。カスタムアプリケーションのアップロードについての詳細は、 [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/exchange/to-publish-assets-maven)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムプロキシを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行​_後_​: - ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がプロキシの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はプロキシアプリケーションのベースディレクトリの名前です。たとえば、​`mytestproxy/src/main/app/proxy.xml`​ 内のプロキシの場合、​`artifactId`​ は ​`mytestproxy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

api-platform-gw:tags​

Mule 4 では、API の自動作成は無効です。

api-platform-gw:description

Mule 4 では、API の自動作成は無効です。
これらの各要素では、子要素も削除されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にプロキシファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がプロキシの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#raml_proxy_migration)RAML プロキシの移行 RAML プロキシ要素は REST プロキシ要素に移行されます。
Mule 3 Mule 4

proxy:raml-proxy-config​。

rest-validator:config​。

proxy:raml​。

rest-validator:validate-request​。

apikit:mapping-exception-strategy​。

rest-validator:validate-request​ 要素を含むフロー内の ​on-error-continue​ 要素を使用する ​error-handler​。
`error-handler`​ 要素には、​`on-error-continue`​ 要素の次の型が含まれます。
型 Status Code

REST-VALIDATOR:BAD_REQUEST​

400

REST-VALIDATOR:RESOURCE_NOT_FOUND​

404

REST-VALIDATOR:METHOD_NOT_ALLOWED​

405

HTTP:TIMEOUT

504
Mule 3 要素に見つからない例外は、Mule Migration Assistant によってオートコンプリートされます。 ### [](#wsdl_proxy_migration)WSDL プロキシの移行 WSDL プロキシの移行は、WSDL プロパティの属性値の移行で構成されます。Mule 3 では、ほとんどの値は属性値として定義された関数を使用して抽出されます。Mule 4 には同等のプロセスがないため、ほとんどのプロパティはデフォルト値に移行され、​`service`​ キーワードで始まる WSDL ファイルの値を使用して手動で設定する必要があります。 一部のプロパティは、よりわかりやすい方法で値を抽出するために名前が変更されています。次に例を示します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.name]

${service.port}

![wsdl(p['wsdl.uri']).targetNamespace]​

${service.namespace}

![wsdl(p['wsdl.uri']).services[0].name]​

${service.name}
次のようなその他のプロパティは、MMA によって提供される WSDL 関数拡張の連動関係を使用する DataWeave 式に移行され、期待値を抽出します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].port]

#[Wsdl::getPort('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].host]

#[Wsdl::getHost('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].path]

#[Wsdl::getPath('${wsdl.uri}','${service.name}','${service.port}')]
## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-core) [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/exchange/to-publish-assets-maven) # API プロキシの移行 ## [](#performing_migration)プロキシの移行の実行 プロキシの移行を実行するこの例では、Mule Migration Assistant (MMA) を使用します。 この手順では、ツールの [前提条件](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 プロキシを移行するための MMA コマンドは、Mule アプリケーションを移行するための標準の [コマンドラインオプション (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ を使用します。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-proxy/ \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-proxy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-proxy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-proxy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - プロキシ POM ファイル。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、プロキシ XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにプロキシ XML ファイルが含まれます。​`mule`​ ディレクトリと同じレベルで、移行したプロキシに必要な DataWeave ファイルまたはその他のファイル用の ​`resources`​ ディレクトリが作成されます。 アーティファクトを適切にデプロイするには、プロキシ XML で定義された設定ファイルが ​`resources`​ ディレクトリに存在する必要があります。​`test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したプロキシを Exchange にアップロードできます。カスタムアプリケーションのアップロードについての詳細は、 [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/exchange/to-publish-assets-maven)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムプロキシを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行​_後_​: - ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がプロキシの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はプロキシアプリケーションのベースディレクトリの名前です。たとえば、​`mytestproxy/src/main/app/proxy.xml`​ 内のプロキシの場合、​`artifactId`​ は ​`mytestproxy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

api-platform-gw:tags​

Mule 4 では、API の自動作成は無効です。

api-platform-gw:description

Mule 4 では、API の自動作成は無効です。
これらの各要素では、子要素も削除されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にプロキシファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がプロキシの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#raml_proxy_migration)RAML プロキシの移行 RAML プロキシ要素は REST プロキシ要素に移行されます。
Mule 3 Mule 4

proxy:raml-proxy-config​。

rest-validator:config​。

proxy:raml​。

rest-validator:validate-request​。

apikit:mapping-exception-strategy​。

rest-validator:validate-request​ 要素を含むフロー内の ​on-error-continue​ 要素を使用する ​error-handler​。
`error-handler`​ 要素には、​`on-error-continue`​ 要素の次の型が含まれます。
型 Status Code

REST-VALIDATOR:BAD_REQUEST​

400

REST-VALIDATOR:RESOURCE_NOT_FOUND​

404

REST-VALIDATOR:METHOD_NOT_ALLOWED​

405

HTTP:TIMEOUT

504
Mule 3 要素に見つからない例外は、Mule Migration Assistant によってオートコンプリートされます。 ### [](#wsdl_proxy_migration)WSDL プロキシの移行 WSDL プロキシの移行は、WSDL プロパティの属性値の移行で構成されます。Mule 3 では、ほとんどの値は属性値として定義された関数を使用して抽出されます。Mule 4 には同等のプロセスがないため、ほとんどのプロパティはデフォルト値に移行され、​`service`​ キーワードで始まる WSDL ファイルの値を使用して手動で設定する必要があります。 一部のプロパティは、よりわかりやすい方法で値を抽出するために名前が変更されています。次に例を示します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.name]

${service.port}

![wsdl(p['wsdl.uri']).targetNamespace]​

${service.namespace}

![wsdl(p['wsdl.uri']).services[0].name]​

${service.name}
次のようなその他のプロパティは、MMA によって提供される WSDL 関数拡張の連動関係を使用する DataWeave 式に移行され、期待値を抽出します。
Mule 3 Mule 4

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].port]

#[Wsdl::getPort('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].host]

#[Wsdl::getHost('${wsdl.uri}','${service.name}','${service.port}')]

![wsdl(p['wsdl.uri']).services[0].preferredPort.addresses[0].path]

#[Wsdl::getPath('${wsdl.uri}','${service.name}','${service.port}')]
## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-core) [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/exchange/to-publish-assets-maven) # API ポリシーの移行 Mule 4 では、ポリシーが大幅に変更されています。 ## [](#ポリシーの動作の定義)ポリシーの動作の定義 3.x では、特定のポリシー内のロジックが 2 つのブロックに分割されています。次のポリシーまたはフローの前に実行されるブロックと、その後に実行されるブロックです。 Mule 3 の例 ```xml ``` Mule 4 では、ポリシーが ​`before`​ と ​`after`​ ブロックに分けられなくなりました。 ポリシーは次のポリシーまたはフローに明示的にジャンプするフローとして機能するようになり、ポリシー内でこのジャンプを定義する必要があります。 Mule 4 では、次の設定で同じ動作を実行できます。 Mule 4 の例 ```xml ``` 注意点: - ロジックは同じブロックに配置されます。フローの前に動作を挿入するには、単に ​`execute-next`​ 要素の前にロジックを配置します。フローの後に動作を挿入するには、その要素の後にロジックを配置します。 - `http-policy:source`​ 要素の ​`propagateMessageTransformations`​ 属性: Mule 4 以降、フローを実行する前に Mule メッセージ (ペイロードまたは属性) を変更しても、デフォルトではフローに反映されません。反映されるようにするには、​`propagateMessageTransformations`​ を ​`true`​ に設定する必要があります。 - `pointcut`​ 要素が、ポリシー設定ファイルで定義されなくなりました。現在は、ポリシーが API Manager から取得されたときに、API ゲートウェイがこの要素を解決します。 エンドポイントとアプリケーションの ​`pointcut`​ 要素を使用できなくなり、その代わりになるものもありません。 ## [](#ポリシーテンプレートの-exchange-へのアップロード)ポリシーテンプレートの Exchange へのアップロード 3.x では、ポリシーが定義されると XML ファイルが生成され、そのファイルを API Manager にアップロードする必要があります。 Mule 4 では、ポリシーの動作が定義されると、そのポリシーをポリシーテンプレート JAR にパッケージ化して Exchange にアップロードし、API Manager で使用可能にする必要があります。 1. ポリシーテンプレート JAR を生成する Maven プロジェクトの作成方法は、記事​[「Packaging a Custom Policy (カスタムポリシーのパッケージ化)」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package)​に記載されています。 2. JAR の Exchange へのアップロード方法は、記事​[「Uploading a Custom Policy to Exchange (カスタムポリシーの Exchange へのアップロード)」](#api-manager::custom-policy-uploading-to-exchange.adoc)​に記載されています。 以前と同様、ポリシーテンプレート JAR が Exchange にアップロードされると、JAR がアップロードされたのと同じ組織に属する API の API Manager に表示されます。 ## [](#performing_migration)ポリシーの移行の実行 ポリシーの移行を実行するこの例では、GitHub オープンソースプロジェクトである Mule Migration Assistant (MMA) を使用します。この手順では、ツールの​ [前提条件​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 ポリシーを移行するための MMA コマンドは、Mule アプリケーションを移行するための一般的な [コマンドラインオプション (GitHub)​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ とは 1 つの重要な点で異なります。 - MMA の ​`-projectBasePath`​ では、ポリシー XML ファイルと YAML ファイルの両方が同じディレクトリ内にある必要があります。次の例では、ポリシーファイルが ​`src/main/policy`​ 内にあることが想定されています。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-policy/src/main/policy \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-policy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-policy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-policy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - ポリシー POM ファイル。 - ポリシー YAML ファイル。POM ファイル内にある ​`artifactId`​ 値に名前が変更されます。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、ポリシー XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにポリシー XML ファイルが含まれ、​`template.xml`​ に名前が変更されます。​`mule`​ ディレクトリと同じレベルで、移行したポリシーに必要な DataWeave ファイルまたはその他のファイルを含む ​`resources`​ ディレクトリが作成される場合があります。 `test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したポリシーを Exchange にアップロードできます。カスタムポリシーのアップロードについての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムポリシーを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行後: ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がポリシーの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はポリシー XML ファイルの親ディレクトリの名前になります。たとえば、​`src/main/mytestpolicy/policy.xml`​ 内のポリシーの場合、​`artifactId`​ は ​`mytestpolicy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

policy:before-exception

Mule 4 では動作を再現できません。

policy:pointcut​

リソースと API のポイントカットは、Mule Runtime Engine によって自動的に解決されます。Mule 4 では、アプリケーションとエンドポイントのポイントカットに同等のものはありません。

policy:data​

この動作は、Mule Runtime Engine によって自動的に解決されます。
これらの各要素では、子要素も削除されます。 ### [](#elements_migrated_to_other_structures)他の構造に移行される要素 `delay-response`​ 要素の子要素として複数の ​`rate-limit`​ 要素が見つかった場合、調整要素 ​`fixed-time-frame-algorithm`​ はレート制限形式に移行されます。 さらに、調整 SLA ポリシーはサポートされなくなったため、​`delay-response`​ 要素が ​`sla-based-algorithm`​ 要素の子として見つかった場合、ポリシーはレート制限 SLA 形式に移行されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にポリシーファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がポリシーの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#yaml_migration_issues)YAML の移行の問題 次の問題が発生する可能性があります。
事例 理由

YAML の編集エラー

詳細は、MMA のスタック追跡を使用してください。

複数の YAML が見つかった

MMA では、プロジェクトのベースパスに 1 つの YAML ファイルのみが必要です。これは、ポリシー YAML として解釈されます。 プロジェクトに複数の YAML が必要な場合は、追加の YAML ファイルを別のディレクトリに保存する必要があります。

YAML が見つからない

MMA では、移行の開始時にプロジェクトのベースパスに YAML ファイルが必要です。何も見つからない場合、移行プロセスの早い段階で別のエラーが発生していた可能性があります。
### [](#threat_protection_migration_issues)脅威保護の移行の問題 次の問題が発生する可能性があります。
事例 理由

ポリシーが XML 脅威保護種別か JSON 脅威保護種別かを判断できなかった

脅威保護ポリシーでは、移行する脅威保護の種別は要素 ​xml-policy​ と ​json-policy​ によって決まります。いずれか 1 つのみが存在する必要があります。いずれも存在しない場合、移行レポートにエラーメッセージが表示されます。

要素 ​structure​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​structure​ が必要です。

要素 ​values​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​values​が必要です。
### [](#client_id_enforcement_migration_issues)クライアント ID 適用の移行の問題 次の問題が発生する可能性があります。
事例 理由

クライアント ID 適用の移行要素が無効

validate-client​ 要素の ​basicAuthEnabled​ 属性が存在しないか ​false​ の場合、MMA では ​validate-client​ 要素に ​clientSecret​ または ​clientId​ 属性が存在する必要があります。
### [](#spring_limitations)Spring の制限 MMA によって Mule 3 ポリシーの ​`spring:bean`​ 要素が ​`resources`​ ディレクトリの ​`template-beans.xml`​ ファイルに移行される場合でも、​`template-beans.xml`​ を参照する ​`spring-module:config`​ 要素がカスタムポリシーに追加される場合でも、Spring Bean の手動移行を実行する必要があります。Mule 4 ではポリシーでの Bean の宣言はサポートされておらず、ポリシーのデプロイに失敗します。 ### [](#known_issues)既知の問題 MMA には、次の既知の問題があります。 - 拡張子が ​`.yml`​ のポリシー YAML ファイルを使用するポリシーは検出されない。 - ポリシー YAML ファイルの必須項目が自動入力されない。 - `mule:processor`​ 要素が移行されない。 - `byte-array-to-string-transformer`​ 要素が移行されない。 - `expression-component`​ 要素が移行されない。 - `mulexml:object-to-xml-transformer`​ 要素が移行されない。 - 移行した要素 ​`ee:transform`​ にスキーマの場所の URI が追加されない。 - アンダースコアで始まる DataWeave 式は引用符が付けられないため、ポリシーが失敗する。 ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-core) [レート制限および調整ポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling) [レート制限 SLA ベースポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies) [Exchange へのカスタムポリシーのアップロード](https://docs.mulesoft.com/api-manager/2.x/custom-policy-uploading-to-exchange) # API ポリシーの移行 Mule 4 では、ポリシーが大幅に変更されています。 ## [](#ポリシーの動作の定義)ポリシーの動作の定義 3.x では、特定のポリシー内のロジックが 2 つのブロックに分割されています。次のポリシーまたはフローの前に実行されるブロックと、その後に実行されるブロックです。 Mule 3 の例 ```xml ``` Mule 4 では、ポリシーが ​`before`​ と ​`after`​ ブロックに分けられなくなりました。 ポリシーは次のポリシーまたはフローに明示的にジャンプするフローとして機能するようになり、ポリシー内でこのジャンプを定義する必要があります。 Mule 4 では、次の設定で同じ動作を実行できます。 Mule 4 の例 ```xml ``` 注意点: - ロジックは同じブロックに配置されます。フローの前に動作を挿入するには、単に ​`execute-next`​ 要素の前にロジックを配置します。フローの後に動作を挿入するには、その要素の後にロジックを配置します。 - `http-policy:source`​ 要素の ​`propagateMessageTransformations`​ 属性: Mule 4 以降、フローを実行する前に Mule メッセージ (ペイロードまたは属性) を変更しても、デフォルトではフローに反映されません。反映されるようにするには、​`propagateMessageTransformations`​ を ​`true`​ に設定する必要があります。 - `pointcut`​ 要素が、ポリシー設定ファイルで定義されなくなりました。現在は、ポリシーが API Manager から取得されたときに、API ゲートウェイがこの要素を解決します。 エンドポイントとアプリケーションの ​`pointcut`​ 要素を使用できなくなり、その代わりになるものもありません。 ## [](#ポリシーテンプレートの-exchange-へのアップロード)ポリシーテンプレートの Exchange へのアップロード 3.x では、ポリシーが定義されると XML ファイルが生成され、そのファイルを API Manager にアップロードする必要があります。 Mule 4 では、ポリシーの動作が定義されると、そのポリシーをポリシーテンプレート JAR にパッケージ化して Exchange にアップロードし、API Manager で使用可能にする必要があります。 1. ポリシーテンプレート JAR を生成する Maven プロジェクトの作成方法は、記事​[「Packaging a Custom Policy (カスタムポリシーのパッケージ化)」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package)​に記載されています。 2. JAR の Exchange へのアップロード方法は、記事​[「Uploading a Custom Policy to Exchange (カスタムポリシーの Exchange へのアップロード)」](#api-manager::custom-policy-uploading-to-exchange.adoc)​に記載されています。 以前と同様、ポリシーテンプレート JAR が Exchange にアップロードされると、JAR がアップロードされたのと同じ組織に属する API の API Manager に表示されます。 ## [](#performing_migration)ポリシーの移行の実行 ポリシーの移行を実行するこの例では、GitHub オープンソースプロジェクトである Mule Migration Assistant (MMA) を使用します。この手順では、ツールの​ [前提条件​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 ポリシーを移行するための MMA コマンドは、Mule アプリケーションを移行するための一般的な [コマンドラインオプション (GitHub)​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ とは 1 つの重要な点で異なります。 - MMA の ​`-projectBasePath`​ では、ポリシー XML ファイルと YAML ファイルの両方が同じディレクトリ内にある必要があります。次の例では、ポリシーファイルが ​`src/main/policy`​ 内にあることが想定されています。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-policy/src/main/policy \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-policy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-policy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-policy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - ポリシー POM ファイル。 - ポリシー YAML ファイル。POM ファイル内にある ​`artifactId`​ 値に名前が変更されます。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、ポリシー XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにポリシー XML ファイルが含まれ、​`template.xml`​ に名前が変更されます。​`mule`​ ディレクトリと同じレベルで、移行したポリシーに必要な DataWeave ファイルまたはその他のファイルを含む ​`resources`​ ディレクトリが作成される場合があります。 `test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したポリシーを Exchange にアップロードできます。カスタムポリシーのアップロードについての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムポリシーを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行後: ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がポリシーの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はポリシー XML ファイルの親ディレクトリの名前になります。たとえば、​`src/main/mytestpolicy/policy.xml`​ 内のポリシーの場合、​`artifactId`​ は ​`mytestpolicy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

policy:before-exception

Mule 4 では動作を再現できません。

policy:pointcut​

リソースと API のポイントカットは、Mule Runtime Engine によって自動的に解決されます。Mule 4 では、アプリケーションとエンドポイントのポイントカットに同等のものはありません。

policy:data​

この動作は、Mule Runtime Engine によって自動的に解決されます。
これらの各要素では、子要素も削除されます。 ### [](#elements_migrated_to_other_structures)他の構造に移行される要素 `delay-response`​ 要素の子要素として複数の ​`rate-limit`​ 要素が見つかった場合、調整要素 ​`fixed-time-frame-algorithm`​ はレート制限形式に移行されます。 さらに、調整 SLA ポリシーはサポートされなくなったため、​`delay-response`​ 要素が ​`sla-based-algorithm`​ 要素の子として見つかった場合、ポリシーはレート制限 SLA 形式に移行されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にポリシーファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がポリシーの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#yaml_migration_issues)YAML の移行の問題 次の問題が発生する可能性があります。
事例 理由

YAML の編集エラー

詳細は、MMA のスタック追跡を使用してください。

複数の YAML が見つかった

MMA では、プロジェクトのベースパスに 1 つの YAML ファイルのみが必要です。これは、ポリシー YAML として解釈されます。 プロジェクトに複数の YAML が必要な場合は、追加の YAML ファイルを別のディレクトリに保存する必要があります。

YAML が見つからない

MMA では、移行の開始時にプロジェクトのベースパスに YAML ファイルが必要です。何も見つからない場合、移行プロセスの早い段階で別のエラーが発生していた可能性があります。
### [](#threat_protection_migration_issues)脅威保護の移行の問題 次の問題が発生する可能性があります。
事例 理由

ポリシーが XML 脅威保護種別か JSON 脅威保護種別かを判断できなかった

脅威保護ポリシーでは、移行する脅威保護の種別は要素 ​xml-policy​ と ​json-policy​ によって決まります。いずれか 1 つのみが存在する必要があります。いずれも存在しない場合、移行レポートにエラーメッセージが表示されます。

要素 ​structure​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​structure​ が必要です。

要素 ​values​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​values​が必要です。
### [](#client_id_enforcement_migration_issues)クライアント ID 適用の移行の問題 次の問題が発生する可能性があります。
事例 理由

クライアント ID 適用の移行要素が無効

validate-client​ 要素の ​basicAuthEnabled​ 属性が存在しないか ​false​ の場合、MMA では ​validate-client​ 要素に ​clientSecret​ または ​clientId​ 属性が存在する必要があります。
### [](#spring_limitations)Spring の制限 MMA によって Mule 3 ポリシーの ​`spring:bean`​ 要素が ​`resources`​ ディレクトリの ​`template-beans.xml`​ ファイルに移行される場合でも、​`template-beans.xml`​ を参照する ​`spring-module:config`​ 要素がカスタムポリシーに追加される場合でも、Spring Bean の手動移行を実行する必要があります。Mule 4 ではポリシーでの Bean の宣言はサポートされておらず、ポリシーのデプロイに失敗します。 ### [](#known_issues)既知の問題 MMA には、次の既知の問題があります。 - 拡張子が ​`.yml`​ のポリシー YAML ファイルを使用するポリシーは検出されない。 - ポリシー YAML ファイルの必須項目が自動入力されない。 - `mule:processor`​ 要素が移行されない。 - `byte-array-to-string-transformer`​ 要素が移行されない。 - `expression-component`​ 要素が移行されない。 - `mulexml:object-to-xml-transformer`​ 要素が移行されない。 - 移行した要素 ​`ee:transform`​ にスキーマの場所の URI が追加されない。 - アンダースコアで始まる DataWeave 式は引用符が付けられないため、ポリシーが失敗する。 ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-core) [レート制限および調整ポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling) [レート制限 SLA ベースポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies) [Exchange へのカスタムポリシーのアップロード](https://docs.mulesoft.com/api-manager/2.x/custom-policy-uploading-to-exchange) # API ポリシーの移行 Mule 4 では、ポリシーが大幅に変更されています。 ## [](#ポリシーの動作の定義)ポリシーの動作の定義 3.x では、特定のポリシー内のロジックが 2 つのブロックに分割されています。次のポリシーまたはフローの前に実行されるブロックと、その後に実行されるブロックです。 Mule 3 の例 ```xml ``` Mule 4 では、ポリシーが ​`before`​ と ​`after`​ ブロックに分けられなくなりました。 ポリシーは次のポリシーまたはフローに明示的にジャンプするフローとして機能するようになり、ポリシー内でこのジャンプを定義する必要があります。 Mule 4 では、次の設定で同じ動作を実行できます。 Mule 4 の例 ```xml ``` 注意点: - ロジックは同じブロックに配置されます。フローの前に動作を挿入するには、単に ​`execute-next`​ 要素の前にロジックを配置します。フローの後に動作を挿入するには、その要素の後にロジックを配置します。 - `http-policy:source`​ 要素の ​`propagateMessageTransformations`​ 属性: Mule 4 以降、フローを実行する前に Mule メッセージ (ペイロードまたは属性) を変更しても、デフォルトではフローに反映されません。反映されるようにするには、​`propagateMessageTransformations`​ を ​`true`​ に設定する必要があります。 - `pointcut`​ 要素が、ポリシー設定ファイルで定義されなくなりました。現在は、ポリシーが API Manager から取得されたときに、API ゲートウェイがこの要素を解決します。 エンドポイントとアプリケーションの ​`pointcut`​ 要素を使用できなくなり、その代わりになるものもありません。 ## [](#ポリシーテンプレートの-exchange-へのアップロード)ポリシーテンプレートの Exchange へのアップロード 3.x では、ポリシーが定義されると XML ファイルが生成され、そのファイルを API Manager にアップロードする必要があります。 Mule 4 では、ポリシーの動作が定義されると、そのポリシーをポリシーテンプレート JAR にパッケージ化して Exchange にアップロードし、API Manager で使用可能にする必要があります。 1. ポリシーテンプレート JAR を生成する Maven プロジェクトの作成方法は、記事​[「Packaging a Custom Policy (カスタムポリシーのパッケージ化)」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package)​に記載されています。 2. JAR の Exchange へのアップロード方法は、記事​[「Uploading a Custom Policy to Exchange (カスタムポリシーの Exchange へのアップロード)」](#api-manager::custom-policy-uploading-to-exchange.adoc)​に記載されています。 以前と同様、ポリシーテンプレート JAR が Exchange にアップロードされると、JAR がアップロードされたのと同じ組織に属する API の API Manager に表示されます。 ## [](#performing_migration)ポリシーの移行の実行 ポリシーの移行を実行するこの例では、GitHub オープンソースプロジェクトである Mule Migration Assistant (MMA) を使用します。この手順では、ツールの​ [前提条件​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 ポリシーを移行するための MMA コマンドは、Mule アプリケーションを移行するための一般的な [コマンドラインオプション (GitHub)​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ とは 1 つの重要な点で異なります。 - MMA の ​`-projectBasePath`​ では、ポリシー XML ファイルと YAML ファイルの両方が同じディレクトリ内にある必要があります。次の例では、ポリシーファイルが ​`src/main/policy`​ 内にあることが想定されています。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-policy/src/main/policy \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-policy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-policy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-policy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - ポリシー POM ファイル。 - ポリシー YAML ファイル。POM ファイル内にある ​`artifactId`​ 値に名前が変更されます。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、ポリシー XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにポリシー XML ファイルが含まれ、​`template.xml`​ に名前が変更されます。​`mule`​ ディレクトリと同じレベルで、移行したポリシーに必要な DataWeave ファイルまたはその他のファイルを含む ​`resources`​ ディレクトリが作成される場合があります。 `test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したポリシーを Exchange にアップロードできます。カスタムポリシーのアップロードについての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムポリシーを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行後: ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がポリシーの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はポリシー XML ファイルの親ディレクトリの名前になります。たとえば、​`src/main/mytestpolicy/policy.xml`​ 内のポリシーの場合、​`artifactId`​ は ​`mytestpolicy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

policy:before-exception

Mule 4 では動作を再現できません。

policy:pointcut​

リソースと API のポイントカットは、Mule Runtime Engine によって自動的に解決されます。Mule 4 では、アプリケーションとエンドポイントのポイントカットに同等のものはありません。

policy:data​

この動作は、Mule Runtime Engine によって自動的に解決されます。
これらの各要素では、子要素も削除されます。 ### [](#elements_migrated_to_other_structures)他の構造に移行される要素 `delay-response`​ 要素の子要素として複数の ​`rate-limit`​ 要素が見つかった場合、調整要素 ​`fixed-time-frame-algorithm`​ はレート制限形式に移行されます。 さらに、調整 SLA ポリシーはサポートされなくなったため、​`delay-response`​ 要素が ​`sla-based-algorithm`​ 要素の子として見つかった場合、ポリシーはレート制限 SLA 形式に移行されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にポリシーファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がポリシーの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#yaml_migration_issues)YAML の移行の問題 次の問題が発生する可能性があります。
事例 理由

YAML の編集エラー

詳細は、MMA のスタック追跡を使用してください。

複数の YAML が見つかった

MMA では、プロジェクトのベースパスに 1 つの YAML ファイルのみが必要です。これは、ポリシー YAML として解釈されます。 プロジェクトに複数の YAML が必要な場合は、追加の YAML ファイルを別のディレクトリに保存する必要があります。

YAML が見つからない

MMA では、移行の開始時にプロジェクトのベースパスに YAML ファイルが必要です。何も見つからない場合、移行プロセスの早い段階で別のエラーが発生していた可能性があります。
### [](#threat_protection_migration_issues)脅威保護の移行の問題 次の問題が発生する可能性があります。
事例 理由

ポリシーが XML 脅威保護種別か JSON 脅威保護種別かを判断できなかった

脅威保護ポリシーでは、移行する脅威保護の種別は要素 ​xml-policy​ と ​json-policy​ によって決まります。いずれか 1 つのみが存在する必要があります。いずれも存在しない場合、移行レポートにエラーメッセージが表示されます。

要素 ​structure​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​structure​ が必要です。

要素 ​values​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​values​が必要です。
### [](#client_id_enforcement_migration_issues)クライアント ID 適用の移行の問題 次の問題が発生する可能性があります。
事例 理由

クライアント ID 適用の移行要素が無効

validate-client​ 要素の ​basicAuthEnabled​ 属性が存在しないか ​false​ の場合、MMA では ​validate-client​ 要素に ​clientSecret​ または ​clientId​ 属性が存在する必要があります。
### [](#spring_limitations)Spring の制限 MMA によって Mule 3 ポリシーの ​`spring:bean`​ 要素が ​`resources`​ ディレクトリの ​`template-beans.xml`​ ファイルに移行される場合でも、​`template-beans.xml`​ を参照する ​`spring-module:config`​ 要素がカスタムポリシーに追加される場合でも、Spring Bean の手動移行を実行する必要があります。Mule 4 ではポリシーでの Bean の宣言はサポートされておらず、ポリシーのデプロイに失敗します。 ### [](#known_issues)既知の問題 MMA には、次の既知の問題があります。 - 拡張子が ​`.yml`​ のポリシー YAML ファイルを使用するポリシーは検出されない。 - ポリシー YAML ファイルの必須項目が自動入力されない。 - `mule:processor`​ 要素が移行されない。 - `byte-array-to-string-transformer`​ 要素が移行されない。 - `expression-component`​ 要素が移行されない。 - `mulexml:object-to-xml-transformer`​ 要素が移行されない。 - 移行した要素 ​`ee:transform`​ にスキーマの場所の URI が追加されない。 - アンダースコアで始まる DataWeave 式は引用符が付けられないため、ポリシーが失敗する。 ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-core) [レート制限および調整ポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling) [レート制限 SLA ベースポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies) [Exchange へのカスタムポリシーのアップロード](https://docs.mulesoft.com/api-manager/2.x/custom-policy-uploading-to-exchange) # API ポリシーの移行 Mule 4 では、ポリシーが大幅に変更されています。 ## [](#ポリシーの動作の定義)ポリシーの動作の定義 3.x では、特定のポリシー内のロジックが 2 つのブロックに分割されています。次のポリシーまたはフローの前に実行されるブロックと、その後に実行されるブロックです。 Mule 3 の例 ```xml ``` Mule 4 では、ポリシーが ​`before`​ と ​`after`​ ブロックに分けられなくなりました。 ポリシーは次のポリシーまたはフローに明示的にジャンプするフローとして機能するようになり、ポリシー内でこのジャンプを定義する必要があります。 Mule 4 では、次の設定で同じ動作を実行できます。 Mule 4 の例 ```xml ``` 注意点: - ロジックは同じブロックに配置されます。フローの前に動作を挿入するには、単に ​`execute-next`​ 要素の前にロジックを配置します。フローの後に動作を挿入するには、その要素の後にロジックを配置します。 - `http-policy:source`​ 要素の ​`propagateMessageTransformations`​ 属性: Mule 4 以降、フローを実行する前に Mule メッセージ (ペイロードまたは属性) を変更しても、デフォルトではフローに反映されません。反映されるようにするには、​`propagateMessageTransformations`​ を ​`true`​ に設定する必要があります。 - `pointcut`​ 要素が、ポリシー設定ファイルで定義されなくなりました。現在は、ポリシーが API Manager から取得されたときに、API ゲートウェイがこの要素を解決します。 エンドポイントとアプリケーションの ​`pointcut`​ 要素を使用できなくなり、その代わりになるものもありません。 ## [](#ポリシーテンプレートの-exchange-へのアップロード)ポリシーテンプレートの Exchange へのアップロード 3.x では、ポリシーが定義されると XML ファイルが生成され、そのファイルを API Manager にアップロードする必要があります。 Mule 4 では、ポリシーの動作が定義されると、そのポリシーをポリシーテンプレート JAR にパッケージ化して Exchange にアップロードし、API Manager で使用可能にする必要があります。 1. ポリシーテンプレート JAR を生成する Maven プロジェクトの作成方法は、記事​[「Packaging a Custom Policy (カスタムポリシーのパッケージ化)」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package)​に記載されています。 2. JAR の Exchange へのアップロード方法は、記事​[「Uploading a Custom Policy to Exchange (カスタムポリシーの Exchange へのアップロード)」](#api-manager::custom-policy-uploading-to-exchange.adoc)​に記載されています。 以前と同様、ポリシーテンプレート JAR が Exchange にアップロードされると、JAR がアップロードされたのと同じ組織に属する API の API Manager に表示されます。 ## [](#performing_migration)ポリシーの移行の実行 ポリシーの移行を実行するこの例では、GitHub オープンソースプロジェクトである Mule Migration Assistant (MMA) を使用します。この手順では、ツールの​ [前提条件​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 ポリシーを移行するための MMA コマンドは、Mule アプリケーションを移行するための一般的な [コマンドラインオプション (GitHub)​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ とは 1 つの重要な点で異なります。 - MMA の ​`-projectBasePath`​ では、ポリシー XML ファイルと YAML ファイルの両方が同じディレクトリ内にある必要があります。次の例では、ポリシーファイルが ​`src/main/policy`​ 内にあることが想定されています。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-policy/src/main/policy \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-policy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-policy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-policy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - ポリシー POM ファイル。 - ポリシー YAML ファイル。POM ファイル内にある ​`artifactId`​ 値に名前が変更されます。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、ポリシー XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにポリシー XML ファイルが含まれ、​`template.xml`​ に名前が変更されます。​`mule`​ ディレクトリと同じレベルで、移行したポリシーに必要な DataWeave ファイルまたはその他のファイルを含む ​`resources`​ ディレクトリが作成される場合があります。 `test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したポリシーを Exchange にアップロードできます。カスタムポリシーのアップロードについての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムポリシーを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行後: ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がポリシーの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はポリシー XML ファイルの親ディレクトリの名前になります。たとえば、​`src/main/mytestpolicy/policy.xml`​ 内のポリシーの場合、​`artifactId`​ は ​`mytestpolicy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

policy:before-exception

Mule 4 では動作を再現できません。

policy:pointcut​

リソースと API のポイントカットは、Mule Runtime Engine によって自動的に解決されます。Mule 4 では、アプリケーションとエンドポイントのポイントカットに同等のものはありません。

policy:data​

この動作は、Mule Runtime Engine によって自動的に解決されます。
これらの各要素では、子要素も削除されます。 ### [](#elements_migrated_to_other_structures)他の構造に移行される要素 `delay-response`​ 要素の子要素として複数の ​`rate-limit`​ 要素が見つかった場合、調整要素 ​`fixed-time-frame-algorithm`​ はレート制限形式に移行されます。 さらに、調整 SLA ポリシーはサポートされなくなったため、​`delay-response`​ 要素が ​`sla-based-algorithm`​ 要素の子として見つかった場合、ポリシーはレート制限 SLA 形式に移行されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にポリシーファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がポリシーの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#yaml_migration_issues)YAML の移行の問題 次の問題が発生する可能性があります。
事例 理由

YAML の編集エラー

詳細は、MMA のスタック追跡を使用してください。

複数の YAML が見つかった

MMA では、プロジェクトのベースパスに 1 つの YAML ファイルのみが必要です。これは、ポリシー YAML として解釈されます。 プロジェクトに複数の YAML が必要な場合は、追加の YAML ファイルを別のディレクトリに保存する必要があります。

YAML が見つからない

MMA では、移行の開始時にプロジェクトのベースパスに YAML ファイルが必要です。何も見つからない場合、移行プロセスの早い段階で別のエラーが発生していた可能性があります。
### [](#threat_protection_migration_issues)脅威保護の移行の問題 次の問題が発生する可能性があります。
事例 理由

ポリシーが XML 脅威保護種別か JSON 脅威保護種別かを判断できなかった

脅威保護ポリシーでは、移行する脅威保護の種別は要素 ​xml-policy​ と ​json-policy​ によって決まります。いずれか 1 つのみが存在する必要があります。いずれも存在しない場合、移行レポートにエラーメッセージが表示されます。

要素 ​structure​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​structure​ が必要です。

要素 ​values​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​values​が必要です。
### [](#client_id_enforcement_migration_issues)クライアント ID 適用の移行の問題 次の問題が発生する可能性があります。
事例 理由

クライアント ID 適用の移行要素が無効

validate-client​ 要素の ​basicAuthEnabled​ 属性が存在しないか ​false​ の場合、MMA では ​validate-client​ 要素に ​clientSecret​ または ​clientId​ 属性が存在する必要があります。
### [](#spring_limitations)Spring の制限 MMA によって Mule 3 ポリシーの ​`spring:bean`​ 要素が ​`resources`​ ディレクトリの ​`template-beans.xml`​ ファイルに移行される場合でも、​`template-beans.xml`​ を参照する ​`spring-module:config`​ 要素がカスタムポリシーに追加される場合でも、Spring Bean の手動移行を実行する必要があります。Mule 4 ではポリシーでの Bean の宣言はサポートされておらず、ポリシーのデプロイに失敗します。 ### [](#known_issues)既知の問題 MMA には、次の既知の問題があります。 - 拡張子が ​`.yml`​ のポリシー YAML ファイルを使用するポリシーは検出されない。 - ポリシー YAML ファイルの必須項目が自動入力されない。 - `mule:processor`​ 要素が移行されない。 - `byte-array-to-string-transformer`​ 要素が移行されない。 - `expression-component`​ 要素が移行されない。 - `mulexml:object-to-xml-transformer`​ 要素が移行されない。 - 移行した要素 ​`ee:transform`​ にスキーマの場所の URI が追加されない。 - アンダースコアで始まる DataWeave 式は引用符が付けられないため、ポリシーが失敗する。 ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-core) [レート制限および調整ポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling) [レート制限 SLA ベースポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies) [Exchange へのカスタムポリシーのアップロード](https://docs.mulesoft.com/api-manager/2.x/custom-policy-uploading-to-exchange) # API ポリシーの移行 Mule 4 では、ポリシーが大幅に変更されています。 ## [](#ポリシーの動作の定義)ポリシーの動作の定義 3.x では、特定のポリシー内のロジックが 2 つのブロックに分割されています。次のポリシーまたはフローの前に実行されるブロックと、その後に実行されるブロックです。 Mule 3 の例 ```xml ``` Mule 4 では、ポリシーが ​`before`​ と ​`after`​ ブロックに分けられなくなりました。 ポリシーは次のポリシーまたはフローに明示的にジャンプするフローとして機能するようになり、ポリシー内でこのジャンプを定義する必要があります。 Mule 4 では、次の設定で同じ動作を実行できます。 Mule 4 の例 ```xml ``` 注意点: - ロジックは同じブロックに配置されます。フローの前に動作を挿入するには、単に ​`execute-next`​ 要素の前にロジックを配置します。フローの後に動作を挿入するには、その要素の後にロジックを配置します。 - `http-policy:source`​ 要素の ​`propagateMessageTransformations`​ 属性: Mule 4 以降、フローを実行する前に Mule メッセージ (ペイロードまたは属性) を変更しても、デフォルトではフローに反映されません。反映されるようにするには、​`propagateMessageTransformations`​ を ​`true`​ に設定する必要があります。 - `pointcut`​ 要素が、ポリシー設定ファイルで定義されなくなりました。現在は、ポリシーが API Manager から取得されたときに、API ゲートウェイがこの要素を解決します。 エンドポイントとアプリケーションの ​`pointcut`​ 要素を使用できなくなり、その代わりになるものもありません。 ## [](#ポリシーテンプレートの-exchange-へのアップロード)ポリシーテンプレートの Exchange へのアップロード 3.x では、ポリシーが定義されると XML ファイルが生成され、そのファイルを API Manager にアップロードする必要があります。 Mule 4 では、ポリシーの動作が定義されると、そのポリシーをポリシーテンプレート JAR にパッケージ化して Exchange にアップロードし、API Manager で使用可能にする必要があります。 1. ポリシーテンプレート JAR を生成する Maven プロジェクトの作成方法は、記事​[「Packaging a Custom Policy (カスタムポリシーのパッケージ化)」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package)​に記載されています。 2. JAR の Exchange へのアップロード方法は、記事​[「Uploading a Custom Policy to Exchange (カスタムポリシーの Exchange へのアップロード)」](#api-manager::custom-policy-uploading-to-exchange.adoc)​に記載されています。 以前と同様、ポリシーテンプレート JAR が Exchange にアップロードされると、JAR がアップロードされたのと同じ組織に属する API の API Manager に表示されます。 ## [](#performing_migration)ポリシーの移行の実行 ポリシーの移行を実行するこの例では、GitHub オープンソースプロジェクトである Mule Migration Assistant (MMA) を使用します。この手順では、ツールの​ [前提条件​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 ポリシーを移行するための MMA コマンドは、Mule アプリケーションを移行するための一般的な [コマンドラインオプション (GitHub)​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ とは 1 つの重要な点で異なります。 - MMA の ​`-projectBasePath`​ では、ポリシー XML ファイルと YAML ファイルの両方が同じディレクトリ内にある必要があります。次の例では、ポリシーファイルが ​`src/main/policy`​ 内にあることが想定されています。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-policy/src/main/policy \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-policy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-policy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-policy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - ポリシー POM ファイル。 - ポリシー YAML ファイル。POM ファイル内にある ​`artifactId`​ 値に名前が変更されます。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、ポリシー XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにポリシー XML ファイルが含まれ、​`template.xml`​ に名前が変更されます。​`mule`​ ディレクトリと同じレベルで、移行したポリシーに必要な DataWeave ファイルまたはその他のファイルを含む ​`resources`​ ディレクトリが作成される場合があります。 `test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したポリシーを Exchange にアップロードできます。カスタムポリシーのアップロードについての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムポリシーを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行後: ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がポリシーの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はポリシー XML ファイルの親ディレクトリの名前になります。たとえば、​`src/main/mytestpolicy/policy.xml`​ 内のポリシーの場合、​`artifactId`​ は ​`mytestpolicy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

policy:before-exception

Mule 4 では動作を再現できません。

policy:pointcut​

リソースと API のポイントカットは、Mule Runtime Engine によって自動的に解決されます。Mule 4 では、アプリケーションとエンドポイントのポイントカットに同等のものはありません。

policy:data​

この動作は、Mule Runtime Engine によって自動的に解決されます。
これらの各要素では、子要素も削除されます。 ### [](#elements_migrated_to_other_structures)他の構造に移行される要素 `delay-response`​ 要素の子要素として複数の ​`rate-limit`​ 要素が見つかった場合、調整要素 ​`fixed-time-frame-algorithm`​ はレート制限形式に移行されます。 さらに、調整 SLA ポリシーはサポートされなくなったため、​`delay-response`​ 要素が ​`sla-based-algorithm`​ 要素の子として見つかった場合、ポリシーはレート制限 SLA 形式に移行されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にポリシーファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がポリシーの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#yaml_migration_issues)YAML の移行の問題 次の問題が発生する可能性があります。
事例 理由

YAML の編集エラー

詳細は、MMA のスタック追跡を使用してください。

複数の YAML が見つかった

MMA では、プロジェクトのベースパスに 1 つの YAML ファイルのみが必要です。これは、ポリシー YAML として解釈されます。 プロジェクトに複数の YAML が必要な場合は、追加の YAML ファイルを別のディレクトリに保存する必要があります。

YAML が見つからない

MMA では、移行の開始時にプロジェクトのベースパスに YAML ファイルが必要です。何も見つからない場合、移行プロセスの早い段階で別のエラーが発生していた可能性があります。
### [](#threat_protection_migration_issues)脅威保護の移行の問題 次の問題が発生する可能性があります。
事例 理由

ポリシーが XML 脅威保護種別か JSON 脅威保護種別かを判断できなかった

脅威保護ポリシーでは、移行する脅威保護の種別は要素 ​xml-policy​ と ​json-policy​ によって決まります。いずれか 1 つのみが存在する必要があります。いずれも存在しない場合、移行レポートにエラーメッセージが表示されます。

要素 ​structure​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​structure​ が必要です。

要素 ​values​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​values​が必要です。
### [](#client_id_enforcement_migration_issues)クライアント ID 適用の移行の問題 次の問題が発生する可能性があります。
事例 理由

クライアント ID 適用の移行要素が無効

validate-client​ 要素の ​basicAuthEnabled​ 属性が存在しないか ​false​ の場合、MMA では ​validate-client​ 要素に ​clientSecret​ または ​clientId​ 属性が存在する必要があります。
### [](#spring_limitations)Spring の制限 MMA によって Mule 3 ポリシーの ​`spring:bean`​ 要素が ​`resources`​ ディレクトリの ​`template-beans.xml`​ ファイルに移行される場合でも、​`template-beans.xml`​ を参照する ​`spring-module:config`​ 要素がカスタムポリシーに追加される場合でも、Spring Bean の手動移行を実行する必要があります。Mule 4 ではポリシーでの Bean の宣言はサポートされておらず、ポリシーのデプロイに失敗します。 ### [](#known_issues)既知の問題 MMA には、次の既知の問題があります。 - 拡張子が ​`.yml`​ のポリシー YAML ファイルを使用するポリシーは検出されない。 - ポリシー YAML ファイルの必須項目が自動入力されない。 - `mule:processor`​ 要素が移行されない。 - `byte-array-to-string-transformer`​ 要素が移行されない。 - `expression-component`​ 要素が移行されない。 - `mulexml:object-to-xml-transformer`​ 要素が移行されない。 - 移行した要素 ​`ee:transform`​ にスキーマの場所の URI が追加されない。 - アンダースコアで始まる DataWeave 式は引用符が付けられないため、ポリシーが失敗する。 ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-core) [レート制限および調整ポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling) [レート制限 SLA ベースポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies) [Exchange へのカスタムポリシーのアップロード](https://docs.mulesoft.com/api-manager/2.x/custom-policy-uploading-to-exchange) # API ポリシーの移行 Mule 4 では、ポリシーが大幅に変更されています。 ## [](#ポリシーの動作の定義)ポリシーの動作の定義 3.x では、特定のポリシー内のロジックが 2 つのブロックに分割されています。次のポリシーまたはフローの前に実行されるブロックと、その後に実行されるブロックです。 Mule 3 の例 ```xml ``` Mule 4 では、ポリシーが ​`before`​ と ​`after`​ ブロックに分けられなくなりました。 ポリシーは次のポリシーまたはフローに明示的にジャンプするフローとして機能するようになり、ポリシー内でこのジャンプを定義する必要があります。 Mule 4 では、次の設定で同じ動作を実行できます。 Mule 4 の例 ```xml ``` 注意点: - ロジックは同じブロックに配置されます。フローの前に動作を挿入するには、単に ​`execute-next`​ 要素の前にロジックを配置します。フローの後に動作を挿入するには、その要素の後にロジックを配置します。 - `http-policy:source`​ 要素の ​`propagateMessageTransformations`​ 属性: Mule 4 以降、フローを実行する前に Mule メッセージ (ペイロードまたは属性) を変更しても、デフォルトではフローに反映されません。反映されるようにするには、​`propagateMessageTransformations`​ を ​`true`​ に設定する必要があります。 - `pointcut`​ 要素が、ポリシー設定ファイルで定義されなくなりました。現在は、ポリシーが API Manager から取得されたときに、API ゲートウェイがこの要素を解決します。 エンドポイントとアプリケーションの ​`pointcut`​ 要素を使用できなくなり、その代わりになるものもありません。 ## [](#ポリシーテンプレートの-exchange-へのアップロード)ポリシーテンプレートの Exchange へのアップロード 3.x では、ポリシーが定義されると XML ファイルが生成され、そのファイルを API Manager にアップロードする必要があります。 Mule 4 では、ポリシーの動作が定義されると、そのポリシーをポリシーテンプレート JAR にパッケージ化して Exchange にアップロードし、API Manager で使用可能にする必要があります。 1. ポリシーテンプレート JAR を生成する Maven プロジェクトの作成方法は、記事​[「Packaging a Custom Policy (カスタムポリシーのパッケージ化)」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package)​に記載されています。 2. JAR の Exchange へのアップロード方法は、記事​[「Uploading a Custom Policy to Exchange (カスタムポリシーの Exchange へのアップロード)」](#api-manager::custom-policy-uploading-to-exchange.adoc)​に記載されています。 以前と同様、ポリシーテンプレート JAR が Exchange にアップロードされると、JAR がアップロードされたのと同じ組織に属する API の API Manager に表示されます。 ## [](#performing_migration)ポリシーの移行の実行 ポリシーの移行を実行するこの例では、GitHub オープンソースプロジェクトである Mule Migration Assistant (MMA) を使用します。この手順では、ツールの [前提条件](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 ポリシーを移行するための MMA コマンドは、Mule アプリケーションを移行するための一般的な [コマンドラインオプション (GitHub)​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ とは 1 つの重要な点で異なります。 - MMA の ​`-projectBasePath`​ では、ポリシー XML ファイルと YAML ファイルの両方が同じディレクトリ内にある必要があります。次の例では、ポリシーファイルが ​`src/main/policy`​ 内にあることが想定されています。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-policy/src/main/policy \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-policy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-policy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-policy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - ポリシー POM ファイル。 - ポリシー YAML ファイル。POM ファイル内にある ​`artifactId`​ 値に名前が変更されます。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、ポリシー XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにポリシー XML ファイルが含まれ、​`template.xml`​ に名前が変更されます。​`mule`​ ディレクトリと同じレベルで、移行したポリシーに必要な DataWeave ファイルまたはその他のファイルを含む ​`resources`​ ディレクトリが作成される場合があります。 `test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したポリシーを Exchange にアップロードできます。カスタムポリシーのアップロードについての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムポリシーを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行後: ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がポリシーの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はポリシー XML ファイルの親ディレクトリの名前になります。たとえば、​`src/main/mytestpolicy/policy.xml`​ 内のポリシーの場合、​`artifactId`​ は ​`mytestpolicy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

policy:before-exception

Mule 4 では動作を再現できません。

policy:pointcut​

リソースと API のポイントカットは、Mule Runtime Engine によって自動的に解決されます。Mule 4 では、アプリケーションとエンドポイントのポイントカットに同等のものはありません。

policy:data​

この動作は、Mule Runtime Engine によって自動的に解決されます。
これらの各要素では、子要素も削除されます。 ### [](#elements_migrated_to_other_structures)他の構造に移行される要素 `delay-response`​ 要素の子要素として複数の ​`rate-limit`​ 要素が見つかった場合、調整要素 ​`fixed-time-frame-algorithm`​ はレート制限形式に移行されます。 さらに、調整 SLA ポリシーはサポートされなくなったため、​`delay-response`​ 要素が ​`sla-based-algorithm`​ 要素の子として見つかった場合、ポリシーはレート制限 SLA 形式に移行されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にポリシーファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がポリシーの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#yaml_migration_issues)YAML の移行の問題 次の問題が発生する可能性があります。
事例 理由

YAML の編集エラー

詳細は、MMA のスタック追跡を使用してください。

複数の YAML が見つかった

MMA では、プロジェクトのベースパスに 1 つの YAML ファイルのみが必要です。これは、ポリシー YAML として解釈されます。 プロジェクトに複数の YAML が必要な場合は、追加の YAML ファイルを別のディレクトリに保存する必要があります。

YAML が見つからない

MMA では、移行の開始時にプロジェクトのベースパスに YAML ファイルが必要です。何も見つからない場合、移行プロセスの早い段階で別のエラーが発生していた可能性があります。
### [](#threat_protection_migration_issues)脅威保護の移行の問題 次の問題が発生する可能性があります。
事例 理由

ポリシーが XML 脅威保護種別か JSON 脅威保護種別かを判断できなかった

脅威保護ポリシーでは、移行する脅威保護の種別は要素 ​xml-policy​ と ​json-policy​ によって決まります。いずれか 1 つのみが存在する必要があります。いずれも存在しない場合、移行レポートにエラーメッセージが表示されます。

要素 ​structure​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​structure​ が必要です。

要素 ​values​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​values​が必要です。
### [](#client_id_enforcement_migration_issues)クライアント ID 適用の移行の問題 次の問題が発生する可能性があります。
事例 理由

クライアント ID 適用の移行要素が無効

validate-client​ 要素の ​basicAuthEnabled​ 属性が存在しないか ​false​ の場合、MMA では ​validate-client​ 要素に ​clientSecret​ または ​clientId​ 属性が存在する必要があります。
### [](#spring_limitations)Spring の制限 MMA によって Mule 3 ポリシーの ​`spring:bean`​ 要素が ​`resources`​ ディレクトリの ​`template-beans.xml`​ ファイルに移行される場合でも、​`template-beans.xml`​ を参照する ​`spring-module:config`​ 要素がカスタムポリシーに追加される場合でも、Spring Bean の手動移行を実行する必要があります。Mule 4 ではポリシーでの Bean の宣言はサポートされておらず、ポリシーのデプロイに失敗します。 ### [](#known_issues)既知の問題 MMA には、次の既知の問題があります。 - 拡張子が ​`.yml`​ のポリシー YAML ファイルを使用するポリシーは検出されない。 - ポリシー YAML ファイルの必須項目が自動入力されない。 - `mule:processor`​ 要素が移行されない。 - `byte-array-to-string-transformer`​ 要素が移行されない。 - `expression-component`​ 要素が移行されない。 - `mulexml:object-to-xml-transformer`​ 要素が移行されない。 - 移行した要素 ​`ee:transform`​ にスキーマの場所の URI が追加されない。 - アンダースコアで始まる DataWeave 式は引用符が付けられないため、ポリシーが失敗する。 ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-core) [レート制限および調整ポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling) [レート制限 SLA ベースポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies) [Exchange へのカスタムポリシーのアップロード](https://docs.mulesoft.com/api-manager/2.x/custom-policy-uploading-to-exchange) # API ポリシーの移行 Mule 4 では、ポリシーが大幅に変更されています。 ## [](#ポリシーの動作の定義)ポリシーの動作の定義 3.x では、特定のポリシー内のロジックが 2 つのブロックに分割されています。次のポリシーまたはフローの前に実行されるブロックと、その後に実行されるブロックです。 Mule 3 の例 ```xml ``` Mule 4 では、ポリシーが ​`before`​ と ​`after`​ ブロックに分けられなくなりました。 ポリシーは次のポリシーまたはフローに明示的にジャンプするフローとして機能するようになり、ポリシー内でこのジャンプを定義する必要があります。 Mule 4 では、次の設定で同じ動作を実行できます。 Mule 4 の例 ```xml ``` 注意点: - ロジックは同じブロックに配置されます。フローの前に動作を挿入するには、単に ​`execute-next`​ 要素の前にロジックを配置します。フローの後に動作を挿入するには、その要素の後にロジックを配置します。 - `http-policy:source`​ 要素の ​`propagateMessageTransformations`​ 属性: Mule 4 以降、フローを実行する前に Mule メッセージ (ペイロードまたは属性) を変更しても、デフォルトではフローに反映されません。反映されるようにするには、​`propagateMessageTransformations`​ を ​`true`​ に設定する必要があります。 - `pointcut`​ 要素が、ポリシー設定ファイルで定義されなくなりました。現在は、ポリシーが API Manager から取得されたときに、API ゲートウェイがこの要素を解決します。 エンドポイントとアプリケーションの ​`pointcut`​ 要素を使用できなくなり、その代わりになるものもありません。 ## [](#ポリシーテンプレートの-exchange-へのアップロード)ポリシーテンプレートの Exchange へのアップロード 3.x では、ポリシーが定義されると XML ファイルが生成され、そのファイルを API Manager にアップロードする必要があります。 Mule 4 では、ポリシーの動作が定義されると、そのポリシーをポリシーテンプレート JAR にパッケージ化して Exchange にアップロードし、API Manager で使用可能にする必要があります。 1. ポリシーテンプレート JAR を生成する Maven プロジェクトの作成方法は、記事​[「Packaging a Custom Policy (カスタムポリシーのパッケージ化)」](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package)​に記載されています。 2. JAR の Exchange へのアップロード方法は、記事​[「Uploading a Custom Policy to Exchange (カスタムポリシーの Exchange へのアップロード)」](#api-manager::custom-policy-uploading-to-exchange.adoc)​に記載されています。 以前と同様、ポリシーテンプレート JAR が Exchange にアップロードされると、JAR がアップロードされたのと同じ組織に属する API の API Manager に表示されます。 ## [](#performing_migration)ポリシーの移行の実行 ポリシーの移行を実行するこの例では、GitHub オープンソースプロジェクトである Mule Migration Assistant (MMA) を使用します。この手順では、ツールの [前提条件](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc#prerequisites)​を満たしている必要があります。MMA の完全なユーザードキュメントについては、 [「Migration to Mule 4 (Mule 4 への移行)」(GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ を参照してください。 ポリシーを移行するための MMA コマンドは、Mule アプリケーションを移行するための一般的な [コマンドラインオプション (GitHub)​](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tool-procedure.adoc#options)​ とは 1 つの重要な点で異なります。 - MMA の ​`-projectBasePath`​ では、ポリシー XML ファイルと YAML ファイルの両方が同じディレクトリ内にある必要があります。次の例では、ポリシーファイルが ​`src/main/policy`​ 内にあることが想定されています。 コマンドラインの呼び出し: ```console $ java -jar mule-migration-assistant-runner-0.5.1.jar \ -projectBasePath /Users/me/AnypointStudio/workspace-studio/my-mule3-policy/src/main/policy \ -muleVersion 4.1.5 \ -destinationProjectBasePath /Users/me/my-dir/my-migrated-policy ``` MMA では、​`-destinationProjectBasePath`​ オプションを使用して移行したプロジェクトのディレクトリが作成されます。​`my-migrated-policy`​ は、コマンドを呼び出す前には​_存在しない_​必要があります。すでに存在するフォルダーを指定すると、移行は次のようなエラーで失敗します。 ​`Exception: Destination folder already exists. (例外: 宛先フォルダーがすでに存在しています。)` 移行が正常に実行されると、次のようなメッセージが表示されます。 成功した移行 ```console Executing migration... ... ======================================================== MIGRATION SUCCESS ======================================================== Total time: 11.335 s Migration report: /Users/me/my-dir/my-migrated-policy/report/summary.html ``` 移行が正常に完了すると、宛先フォルダーには次の内容が含まれます。 - ポリシー POM ファイル。 - ポリシー YAML ファイル。POM ファイル内にある ​`artifactId`​ 値に名前が変更されます。 - [Mule 移行レポート (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-report.adoc)​ (​`summary.html`​) を含む ​`report`​ ディレクトリ。 このレポートで提供されるものと同じ情報は、ポリシー XML ファイルにコメントとして含まれています。 - MMA コマンドで設定された ​`-muleVersion`​ 値と一致する ​`minMuleVersion`​ 値が設定された ​`mule-artifact.json`​ ファイル。 - `src`​ ディレクトリ。移行したコンテンツが含まれます。 `src`​ ディレクトリには、​`main`​ および ​`test`​ ディレクトリが含まれます。​`main`​ 内では、​`mule`​ ディレクトリにポリシー XML ファイルが含まれ、​`template.xml`​ に名前が変更されます。​`mule`​ ディレクトリと同じレベルで、移行したポリシーに必要な DataWeave ファイルまたはその他のファイルを含む ​`resources`​ ディレクトリが作成される場合があります。 `test`​ ディレクトリには、テスト設定ファイルが含まれます。 移行に成功したら、​[POM の移行](#pom_migration)​で説明されているように、POM ファイルを変更する必要があります。POM ファイルに適切な組織 ID が設定されたら、​`mvn clean install`​ を使用してコンパイルできます。コンパイルに成功した場合、​`maven clean deploy`​ を使用して移行したポリシーを Exchange にアップロードできます。カスタムポリシーのアップロードについての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 ### [](#pom_migration)POM の移行 POM ファイルの移行により、カスタムポリシーを Exchange にアップロードするために必要な要素が含まれるようにファイルが変更されます。 移行後: ``​ および ​``​ 要素の ​`{orgId}`​ 値は、Anypoint Platform にある組織 ID に置き換えられます。 組織 ID を取得する方法についての詳細は、​[「Exchange へのカスタムポリシーのアップロード」](#api-manager::custom-policy-uploading-to-exchange.adoc)​を参照してください。 デフォルトでは、Exchange URL は本番環境に設定されます。 ```xml {orgId} https://maven.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven ``` EU バージョンの URL の場合、移行後に URL を手動で設定する必要があります。 - EU の URL テンプレート: `https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/{orgId}/maven` MMA がポリシーの POM ファイルを見つけられない場合、新しい POM ファイルが作成されます。このファイルでは、ポリシーの ​`artifactId`​ はポリシー XML ファイルの親ディレクトリの名前になります。たとえば、​`src/main/mytestpolicy/policy.xml`​ 内のポリシーの場合、​`artifactId`​ は ​`mytestpolicy`​ です。 ### [](#dependency_and_plugin_versions)連動関係およびプラグインバージョン 連動関係およびプラグインバージョンは MMA によってデフォルトで設定されており、必要に応じて手動で変更できます。 ### [](#not_migrated_elements)未移行の要素 いくつかの要素は、Mule 3 から Mule 4 に移行されません。
要素 理由

policy:before-exception

Mule 4 では動作を再現できません。

policy:pointcut​

リソースと API のポイントカットは、Mule Runtime Engine によって自動的に解決されます。Mule 4 では、アプリケーションとエンドポイントのポイントカットに同等のものはありません。

policy:data​

この動作は、Mule Runtime Engine によって自動的に解決されます。
これらの各要素では、子要素も削除されます。 ### [](#elements_migrated_to_other_structures)他の構造に移行される要素 `delay-response`​ 要素の子要素として複数の ​`rate-limit`​ 要素が見つかった場合、調整要素 ​`fixed-time-frame-algorithm`​ はレート制限形式に移行されます。 さらに、調整 SLA ポリシーはサポートされなくなったため、​`delay-response`​ 要素が ​`sla-based-algorithm`​ 要素の子として見つかった場合、ポリシーはレート制限 SLA 形式に移行されます。 ### [](#common_migration_issues)一般的な移行の問題 移行中にポリシーファイルが見つからない場合、MMA は次のようなメッセージを出力します。 失敗した移行 ```console Executing migration... ... =============================================================================== MIGRATION FAILED =============================================================================== Total time: 3.008 s Exception: Cannot read mule project. Is it a Mule Studio project? com.mulesoft.tools.migration.engine.exception.MigrationJobException: Cannot read mule project. Is it a Mule Studio project? at com.mulesoft.tools.migration.engine.project.MuleProjectFactory.getMuleProject(MuleProjectFactory.java:50) at com.mulesoft.tools.migration.engine.MigrationJob.generateSourceApplicationModel(MigrationJob.java:116) at com.mulesoft.tools.migration.engine.MigrationJob.execute(MigrationJob.java:80) at com.mulesoft.tools.migration.MigrationRunner.main(MigrationRunner.java:83) =============================================================================== ``` ### [](#pom_migration_issues)POM の移行の問題 MMA がポリシーの POM モデルを見つけられない場合、Mule 3 の既存の POM からモデルが生成されるか、Mule 3 POM がない場合はモデルが作成されます。MMA が既存の POM を使用している場合、不正な POM 定義が検出されると POM モデルの作成プロセスが失敗します。POM モデル障害に関する情報については、POM モデルの変更時の MMA ステップに関する前のエラーメッセージを確認する必要があります。 ### [](#yaml_migration_issues)YAML の移行の問題 次の問題が発生する可能性があります。
事例 理由

YAML の編集エラー

詳細は、MMA のスタック追跡を使用してください。

複数の YAML が見つかった

MMA では、プロジェクトのベースパスに 1 つの YAML ファイルのみが必要です。これは、ポリシー YAML として解釈されます。 プロジェクトに複数の YAML が必要な場合は、追加の YAML ファイルを別のディレクトリに保存する必要があります。

YAML が見つからない

MMA では、移行の開始時にプロジェクトのベースパスに YAML ファイルが必要です。何も見つからない場合、移行プロセスの早い段階で別のエラーが発生していた可能性があります。
### [](#threat_protection_migration_issues)脅威保護の移行の問題 次の問題が発生する可能性があります。
事例 理由

ポリシーが XML 脅威保護種別か JSON 脅威保護種別かを判断できなかった

脅威保護ポリシーでは、移行する脅威保護の種別は要素 ​xml-policy​ と ​json-policy​ によって決まります。いずれか 1 つのみが存在する必要があります。いずれも存在しない場合、移行レポートにエラーメッセージが表示されます。

要素 ​structure​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​structure​ が必要です。

要素 ​values​ が見つからなかった

脅威保護ポリシーでは、​xml-policy​ 要素に子要素の ​values​が必要です。
### [](#client_id_enforcement_migration_issues)クライアント ID 適用の移行の問題 次の問題が発生する可能性があります。
事例 理由

クライアント ID 適用の移行要素が無効

validate-client​ 要素の ​basicAuthEnabled​ 属性が存在しないか ​false​ の場合、MMA では ​validate-client​ 要素に ​clientSecret​ または ​clientId​ 属性が存在する必要があります。
### [](#spring_limitations)Spring の制限 MMA によって Mule 3 ポリシーの ​`spring:bean`​ 要素が ​`resources`​ ディレクトリの ​`template-beans.xml`​ ファイルに移行される場合でも、​`template-beans.xml`​ を参照する ​`spring-module:config`​ 要素がカスタムポリシーに追加される場合でも、Spring Bean の手動移行を実行する必要があります。Mule 4 ではポリシーでの Bean の宣言はサポートされておらず、ポリシーのデプロイに失敗します。 ### [](#known_issues)既知の問題 MMA には、次の既知の問題があります。 - 拡張子が ​`.yml`​ のポリシー YAML ファイルを使用するポリシーは検出されない。 - ポリシー YAML ファイルの必須項目が自動入力されない。 - `mule:processor`​ 要素が移行されない。 - `byte-array-to-string-transformer`​ 要素が移行されない。 - `expression-component`​ 要素が移行されない。 - `mulexml:object-to-xml-transformer`​ 要素が移行されない。 - 移行した要素 ​`ee:transform`​ にスキーマの場所の URI が追加されない。 - アンダースコアで始まる DataWeave 式は引用符が付けられないため、ポリシーが失敗する。 ## [](#関連情報)関連情報 [API ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways) [API ゲートウェイの移行: Autodiscovery](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-autodiscovery) [API ゲートウェイの移行: Mule Runtime の設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways-runtime-config) [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-core) [レート制限および調整ポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling) [レート制限 SLA ベースポリシー](https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies) [Exchange へのカスタムポリシーのアップロード](https://docs.mulesoft.com/api-manager/2.x/custom-policy-uploading-to-exchange) # API 仕様からのアプリケーションのビルド アプリケーション開発ライフサイクル中に APIkit を使用して API 仕様から Mule REST API または SOAP API をビルドできます。 次のモデリング言語に基づいて API を開発します。 - RAML (RESTful API Modeling Language) - WSDL (Web Service Description Language) - OData (APIkit OData 拡張を使用した OData 対応 API) - OAS (Open API 仕様) Anypoint Studio で APIkit を使用し、RAML または WSDL 仕様ファイルのインポートに基づいて Mule フローの作成を自動化することで、API の設計と実装を簡略化できます。API を生成したら、API をテストするコールを実行した後、実装を最終処理できます。 また、APIkit は、Apache Maven を使用してアプリケーションをビルドするのに役立つほか、既存のアプリケーション用のフローを生成するための CLI ツールも提供します。ただし、このいずれかのタスクを実行する前に、APIkit の基本構造を学習し、APIkit プロジェクトを開始するときに Mule フローを生成するスキャフォールディング手法を理解する必要があります。 ## [](#apikit-の構造)APIkit の構造 APIkit を使用する REST または SOAP Studio プロジェクトには、次の部分があります。 - REST または SOAP インターフェース - メインフロー - バックエンドフロー ![REST Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-rest-studio-project.png) Figure 1. REST Studio プロジェクト。 ![SOAP Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-soap-studio-project.png) Figure 2. SOAP Studio プロジェクト。 ### [](#rest-インターフェース)REST インターフェース REST リソースとアクション間のリレーションは、​_リソースとアクション_​のペアリングと呼ばれます。このインターフェースは、REST サービスにより要求された内部データアセットを公開します。また、このインターフェースは API を定義し (データを含むまたはデータにアクセスするリソースを指定します)、外部データに対するアクション (GET、PUT など) を指定します。 ### [](#soap-インターフェース)SOAP インターフェース WSDL ファイルで定義されたインターフェースでは、多くのサービスが公開されます。各サービスには一連の操作が含まれます。基盤となるデータ種別は、WSDL ファイル内のスキーマまたはインポートされた XSD ファイルで定義された XML です。 ### [](#メインフロー)メインフロー API のメインフローでは、次の機能が管理されます。 - HTTP 用 Anypoint Connector (HTTP Connector) を使用して API を公開する。 - HTTP 要求に基づいてインターフェースとバックエンドフロー間で要求を転送する。 - 要求を受け入れて、応答を送信し、インターフェースと API プロセス間の通信を促進する。 メインフローは HTTP Listener コンポーネントと APIkit (REST または SOAP) Router コンポーネントで構成されます。APIkit Router は、提供された定義に対して要求を検証し、メッセージを強化し (メッセージにデフォルト値を追加するなど)、要求をフローに転送する主要なメッセージプロセッサーです。また、ユーザー要求の転送中、検証中、または処理中にエラーが発生した場合、ルーターはエラーメッセージを出力します。 ![REST API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-rest-main-flow.png) Figure 3. REST API メインフロー。 ![SOAP API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-soap-main-flow.png) Figure 4. SOAP API メインフロー。 ### [](#バックエンドフロー)バックエンドフロー REST 用の APIkit は、RAML ファイル内のリソースとアクションのペアリングごとにバックエンドフローを生成します。 SOAP 用の APIkit は、WSDL 内の操作ごとにバックエンドフローを生成します。 次の例では、RAML インターフェースは GET 要求のユーザーを受け取ります。バックエンドフローはデータベースにアクセスし、ID でユーザーを参照します。 ![REST API バックエンドフロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-rest-backend-flows.png) Figure 5. REST API バックエンドフロー。 ### [](#コールの実行)コールの実行 REST API の場合、API Console を使用して API へのコールを実行します。 SOAP API の場合、SoapUI などの SOAP テストツールを使用して、API へのコールを実行します。 ## [](#apikit-プロジェクトを開始して-mule-フローを作成)APIkit プロジェクトを開始して Mule フローを作成 Studio で新しい APIkit プロジェクトを開始するときに、API 定義ファイルをインポートするオプションがあります。ファイルをインポートすると、APIkit スキャフォールディングメカニズムによって API のさまざまなフローが生成されます。Anypoint Studio で APIkit プロジェクトを開始する方法は 3 つあります。 ### [](#api-定義ファイルを使用して新しい-apikit-プロジェクトを開始)API 定義ファイルを使用して新しい APIkit プロジェクトを開始 既存の RAML または WSDL ファイルをインポートするか、ファイルの URL を参照してプロジェクトを開始する場合、次の方法を使用します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択します。 5. **\[Location (場所)\]**​ で、次のいずれかを実行します。 - Design Center で ​`api.raml`​ ファイルを作成している場合は、​**\[Design Center\]**​ を選択します。必要に応じて Anypoint Platform にログインし、​`api.raml`​ を選択します。 - Design Center で RAML ファイルを作成していない場合は、​**\[Browse Files (ファイルを参照)\]**​ を選択し、テキストエディターで作成した RAML または WSDL ファイルを選択します。WSDL ファイルの場合、ドロップダウンメニューからサービスとポートを選択するか、デフォルトを受け入れます。 1. \[Location (場所)\] のデフォルトオプションを受け入れて、​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様が選択された \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ](_images/mruntime-start-apikit-project-1.png) Figure 6. API 仕様を選択している \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディング手法によって以下が生成されます。 - 基本設定ファイルおよび Mule XML 設定ファイルを含むアーキタイプ - API の実装 RAML ベースの API の場合、RAML ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - HTTP Listener を含むメインフロー - APIkit Router コンポーネント - エラーハンドラー - RAML の連動関係 (Studio などの特定の場所から Design Center などの別の場所に変更をプッシュまたはプルします) - REST のリソースとアクションのマッピングを含むバックエンドフロー WSDL ベースの API の場合、WSDL ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - SOAP Router - SOAP エラー応答テンプレート - SOAP メッセージテンプレートを含むバックエンドフロー 次の図は APIkit スキャフォールディングを示しています。 ![RAML スキャフォールディング](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-raml-scaffolding.png) Figure 7. RAML スキャフォールディング。 ![WSDL スキャフォールディング](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-wsdl-scaffolding.png) Figure 8. WSDL スキャフォールディング。 Studio では、REST API APIkit プロジェクトは次のようになります。 ![Package Explorer とキャンバスセクションを含む REST API Anypoint Studio UI。](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-rest-api-studio-apikit.png) Figure 9. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の REST API。 この図で示されている 5 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`api.raml`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. APIkit Router を含むメインフロー。 3. APIkit Console 4. エラー処理 5. リソースメソッドごとに生成されたフロー。 生成された最小限のフローは、REST 契約で要求されるコミュニケーション操作を満たします。 Studio では、SOAP API APIkit プロジェクトは次のようになります。 ![Package Explorer とキャンバスセクションを含む SOAP API Anypoint Studio UI。](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-soap-api-studio-apikit.png) Figure 10. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の SOAP API。 この図で示されている 4 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`example.wsdl`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. SOAP Router を含むメインフロー。 3. SOAP エラー応答テンプレート 4. SOAP メッセージテンプレートを含む、生成されたバックエンドフロー。 APIkit プロジェクトを作成したら、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#新しい-apikit-プロジェクトを開始)新しい APIkit プロジェクトを開始 API 仕様ファイルなしで APIkit プロジェクトを開始し、後で API 仕様ファイルをプロジェクトに追加できる場合、この方法を使用します。APIkit は骨格 RAML ファイルと XML 設定ファイルを生成します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE。ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択​_しない_​でください。 これにより、バックエンドファーストの APIkit 設計が作成されます。 5. その他のデフォルトのオプションを受け入れて ​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様のない \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ](_images/mruntime-start-apikit-project-2.png) Figure 11. \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディングによって、次のコンポーネントを含む骨格 RAML ファイルおよび XML 設定ファイルが生成されます。 - メインフロー ​`` - メインフローの HTTP Listener 設定 - APIkit Router コンポーネント - エラーハンドラー 後で API 仕様をバックエンドファーストの APIkit 設計に追加し、バックエンドフローを生成して、アプリケーションのビルドを続行できます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#バックエンドフローを生成して新規-apikit-プロジェクトを開始)バックエンドフローを生成して新規 APIkit プロジェクトを開始 このタスクを実行するには、次の前提条件を満たしている必要があります。 - Studio (RAML エディター) で RAML ファイルを作成した - HTTP Listener および APIkit Router コンポーネントを含むメインフローを作成した Studio で RAML ファイルを作成するときに、バックエンドフローの生成は省略可能です。RAML ベースの API ではエラー処理が自動的に生成されます。APIkit プロジェクトを開始するには、バックエンドフローをメインフローから生成する必要があります。次の手順に従います。 1. Package Explorer で、プロジェクト名を右クリックします。 2. **\[Mule\] > \[Generate Flows From REST API (REST API からフローを生成)\]**​ を選択します。 ![Mule プロジェクトからのバックエンドフローの生成](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-start-apikit-project-3.png) Figure 12. Mule プロジェクトからのバックエンドフローの生成。 APIkit スキャフォールディング手法によってバックエンドフローがメインフローの後に生成されます。次に、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ## [](#アプリケーションワークフローのビルド)アプリケーションワークフローのビルド APIkit の基本構造とスキャフォールディング手法を理解したら、次のワークフローを参考にして、APIkit プロジェクトの作成、Mule フローの生成、API へのコールの実行、および実装の最終処理を行って、目的のアプリケーションをビルドします。 - [REST 用の APIKit を使用した REST API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-rest) - [SOAP 用の APIKit を使用した SOAP API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-soap) さらに次のことができます。 - [既存の Mule プロジェクトの APIkit プロジェクトへの変換](https://docs.mulesoft.com/jp/apikit/latest/apikit-workflow-convert-existing) 既存の APIkit バックエンドファーストの設計への API 仕様の追加、API 定義ファイルの定義、メインフローの作成、バックエンド REST API フローの生成、アクションへの RAML リソースのマップを行います。 - [APIkit 4.x タスクの実行](https://docs.mulesoft.com/jp/apikit/latest/key-configurations) APIkit プロジェクトの変更、API コンソールのカスタマイズ、ヘッダーの設定、RAML ファイルの取得、機能以外の要件の実行、ロードバランサーの設定を行います。 - [APIkit OData 拡張を使用した OData 対応 API の作成](https://docs.mulesoft.com/jp/apikit/latest/creating-an-odatav4-api-with-apikit) OData 要求を処理する Mule フローを生成します。 - [Maven を使用した APIkit プロジェクトの作成](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-scaffolding-reference) 既存の Apache Maven プロジェクトに APIkit コンポーネントを追加します。 ## [](#api-からのデータのコンシューム)API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。ガイドラインについては、​[「API からのデータのコンシューム」のドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.3/consume-data-from-an-api)​を参照してください。 ## [](#関連情報)関連情報 - [APIkit](https://docs.mulesoft.com/jp/apikit/latest/) - [APIKit エラー処理](https://docs.mulesoft.com/jp/apikit/latest/apikit-error-handling-reference) # API 仕様からのアプリケーションのビルド アプリケーション開発ライフサイクル中に APIkit を使用して API 仕様から Mule REST API または SOAP API をビルドできます。 次のモデリング言語に基づいて API を開発します。 - RAML (RESTful API Modeling Language) - WSDL (Web Service Description Language) - OData (APIkit OData 拡張を使用した OData 対応 API) - OAS (Open API 仕様) Anypoint Studio で APIkit を使用し、RAML または WSDL 仕様ファイルのインポートに基づいて Mule フローの作成を自動化することで、API の設計と実装を簡略化できます。API を生成したら、API をテストするコールを実行した後、実装を最終処理できます。 また、APIkit は、Apache Maven を使用してアプリケーションをビルドするのに役立つほか、既存のアプリケーション用のフローを生成するための CLI ツールも提供します。ただし、このいずれかのタスクを実行する前に、APIkit の基本構造を学習し、APIkit プロジェクトを開始するときに Mule フローを生成するスキャフォールディング手法を理解する必要があります。 ## [](#apikit-の構造)APIkit の構造 APIkit を使用する REST または SOAP Studio プロジェクトには、次の部分があります。 - REST または SOAP インターフェース - メインフロー - バックエンドフロー ![REST Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-rest-studio-project.png) Figure 1. REST Studio プロジェクト。 ![SOAP Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-soap-studio-project.png) Figure 2. SOAP Studio プロジェクト。 ### [](#rest-インターフェース)REST インターフェース REST リソースとアクション間のリレーションは、​_リソースとアクション_​のペアリングと呼ばれます。このインターフェースは、REST サービスにより要求された内部データアセットを公開します。また、このインターフェースは API を定義し (データを含むまたはデータにアクセスするリソースを指定します)、外部データに対するアクション (GET、PUT など) を指定します。 ### [](#soap-インターフェース)SOAP インターフェース WSDL ファイルで定義されたインターフェースでは、多くのサービスが公開されます。各サービスには一連の操作が含まれます。基盤となるデータ種別は、WSDL ファイル内のスキーマまたはインポートされた XSD ファイルで定義された XML です。 ### [](#メインフロー)メインフロー API のメインフローでは、次の機能が管理されます。 - HTTP 用 Anypoint Connector (HTTP Connector) を使用して API を公開する。 - HTTP 要求に基づいてインターフェースとバックエンドフロー間で要求を転送する。 - 要求を受け入れて、応答を送信し、インターフェースと API プロセス間の通信を促進する。 メインフローは HTTP Listener コンポーネントと APIkit (REST または SOAP) Router コンポーネントで構成されます。APIkit Router は、提供された定義に対して要求を検証し、メッセージを強化し (メッセージにデフォルト値を追加するなど)、要求をフローに転送する主要なメッセージプロセッサーです。また、ユーザー要求の転送中、検証中、または処理中にエラーが発生した場合、ルーターはエラーメッセージを出力します。 ![REST API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-rest-main-flow.png) Figure 3. REST API メインフロー。 ![SOAP API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-soap-main-flow.png) Figure 4. SOAP API メインフロー。 ### [](#バックエンドフロー)バックエンドフロー REST 用の APIkit は、RAML ファイル内のリソースとアクションのペアリングごとにバックエンドフローを生成します。 SOAP 用の APIkit は、WSDL 内の操作ごとにバックエンドフローを生成します。 次の例では、RAML インターフェースは GET 要求のユーザーを受け取ります。バックエンドフローはデータベースにアクセスし、ID でユーザーを参照します。 ![REST API バックエンドフロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-rest-backend-flows.png) Figure 5. REST API バックエンドフロー。 ### [](#コールの実行)コールの実行 REST API の場合、API Console を使用して API へのコールを実行します。 SOAP API の場合、SoapUI などの SOAP テストツールを使用して、API へのコールを実行します。 ## [](#apikit-プロジェクトを開始して-mule-フローを作成)APIkit プロジェクトを開始して Mule フローを作成 Studio で新しい APIkit プロジェクトを開始するときに、API 定義ファイルをインポートするオプションがあります。ファイルをインポートすると、APIkit スキャフォールディングメカニズムによって API のさまざまなフローが生成されます。Anypoint Studio で APIkit プロジェクトを開始する方法は 3 つあります。 ### [](#api-定義ファイルを使用して新しい-apikit-プロジェクトを開始)API 定義ファイルを使用して新しい APIkit プロジェクトを開始 既存の RAML または WSDL ファイルをインポートするか、ファイルの URL を参照してプロジェクトを開始する場合、次の方法を使用します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択します。 5. **\[Location (場所)\]**​ で、次のいずれかを実行します。 - Design Center で ​`api.raml`​ ファイルを作成している場合は、​**\[Design Center\]**​ を選択します。必要に応じて Anypoint Platform にログインし、​`api.raml`​ を選択します。 - Design Center で RAML ファイルを作成していない場合は、​**\[Browse Files (ファイルを参照)\]**​ を選択し、テキストエディターで作成した RAML または WSDL ファイルを選択します。WSDL ファイルの場合、ドロップダウンメニューからサービスとポートを選択するか、デフォルトを受け入れます。 1. \[Location (場所)\] のデフォルトオプションを受け入れて、​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様が選択された \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ](_images/mruntime-start-apikit-project-1.png) Figure 6. API 仕様を選択している \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディング手法によって以下が生成されます。 - 基本設定ファイルおよび Mule XML 設定ファイルを含むアーキタイプ - API の実装 RAML ベースの API の場合、RAML ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - HTTP Listener を含むメインフロー - APIkit Router コンポーネント - エラーハンドラー - RAML の連動関係 (Studio などの特定の場所から Design Center などの別の場所に変更をプッシュまたはプルします) - REST のリソースとアクションのマッピングを含むバックエンドフロー WSDL ベースの API の場合、WSDL ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - SOAP Router - SOAP エラー応答テンプレート - SOAP メッセージテンプレートを含むバックエンドフロー 次の図は APIkit スキャフォールディングを示しています。 ![RAML スキャフォールディング](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-raml-scaffolding.png) Figure 7. RAML スキャフォールディング。 ![WSDL スキャフォールディング](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-wsdl-scaffolding.png) Figure 8. WSDL スキャフォールディング。 Studio では、REST API APIkit プロジェクトは次のようになります。 ![Package Explorer とキャンバスセクションを含む REST API Anypoint Studio UI。](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-rest-api-studio-apikit.png) Figure 9. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の REST API。 この図で示されている 5 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`api.raml`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. APIkit Router を含むメインフロー。 3. APIkit Console 4. エラー処理 5. リソースメソッドごとに生成されたフロー。 生成された最小限のフローは、REST 契約で要求されるコミュニケーション操作を満たします。 Studio では、SOAP API APIkit プロジェクトは次のようになります。 ![Package Explorer とキャンバスセクションを含む SOAP API Anypoint Studio UI。](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-soap-api-studio-apikit.png) Figure 10. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の SOAP API。 この図で示されている 4 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`example.wsdl`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. SOAP Router を含むメインフロー。 3. SOAP エラー応答テンプレート 4. SOAP メッセージテンプレートを含む、生成されたバックエンドフロー。 APIkit プロジェクトを作成したら、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#新しい-apikit-プロジェクトを開始)新しい APIkit プロジェクトを開始 API 仕様ファイルなしで APIkit プロジェクトを開始し、後で API 仕様ファイルをプロジェクトに追加できる場合、この方法を使用します。APIkit は骨格 RAML ファイルと XML 設定ファイルを生成します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE。ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択​_しない_​でください。 これにより、バックエンドファーストの APIkit 設計が作成されます。 5. その他のデフォルトのオプションを受け入れて ​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様のない \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ](_images/mruntime-start-apikit-project-2.png) Figure 11. \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディングによって、次のコンポーネントを含む骨格 RAML ファイルおよび XML 設定ファイルが生成されます。 - メインフロー ​`` - メインフローの HTTP Listener 設定 - APIkit Router コンポーネント - エラーハンドラー 後で API 仕様をバックエンドファーストの APIkit 設計に追加し、バックエンドフローを生成して、アプリケーションのビルドを続行できます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#バックエンドフローを生成して新規-apikit-プロジェクトを開始)バックエンドフローを生成して新規 APIkit プロジェクトを開始 このタスクを実行するには、次の前提条件を満たしている必要があります。 - Studio (RAML エディター) で RAML ファイルを作成した - HTTP Listener および APIkit Router コンポーネントを含むメインフローを作成した Studio で RAML ファイルを作成するときに、バックエンドフローの生成は省略可能です。RAML ベースの API ではエラー処理が自動的に生成されます。APIkit プロジェクトを開始するには、バックエンドフローをメインフローから生成する必要があります。次の手順に従います。 1. Package Explorer で、プロジェクト名を右クリックします。 2. **\[Mule\] > \[Generate Flows From REST API (REST API からフローを生成)\]**​ を選択します。 ![Mule プロジェクトからのバックエンドフローの生成](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-start-apikit-project-3.png) Figure 12. Mule プロジェクトからのバックエンドフローの生成。 APIkit スキャフォールディング手法によってバックエンドフローがメインフローの後に生成されます。次に、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ## [](#アプリケーションワークフローのビルド)アプリケーションワークフローのビルド APIkit の基本構造とスキャフォールディング手法を理解したら、次のワークフローを参考にして、APIkit プロジェクトの作成、Mule フローの生成、API へのコールの実行、および実装の最終処理を行って、目的のアプリケーションをビルドします。 - [REST 用の APIKit を使用した REST API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-rest) - [SOAP 用の APIKit を使用した SOAP API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-soap) さらに次のことができます。 - [既存の Mule プロジェクトの APIkit プロジェクトへの変換](https://docs.mulesoft.com/jp/apikit/latest/apikit-workflow-convert-existing) 既存の APIkit バックエンドファーストの設計への API 仕様の追加、API 定義ファイルの定義、メインフローの作成、バックエンド REST API フローの生成、アクションへの RAML リソースのマップを行います。 - [APIkit 4.x タスクの実行](https://docs.mulesoft.com/jp/apikit/latest/key-configurations) APIkit プロジェクトの変更、API コンソールのカスタマイズ、ヘッダーの設定、RAML ファイルの取得、機能以外の要件の実行、ロードバランサーの設定を行います。 - [APIkit OData 拡張を使用した OData 対応 API の作成](https://docs.mulesoft.com/jp/apikit/latest/creating-an-odatav4-api-with-apikit) OData 要求を処理する Mule フローを生成します。 - [Maven を使用した APIkit プロジェクトの作成](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-scaffolding-reference) 既存の Apache Maven プロジェクトに APIkit コンポーネントを追加します。 ## [](#api-からのデータのコンシューム)API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。ガイドラインについては、​[「API からのデータのコンシューム」のドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.4/consume-data-from-an-api)​を参照してください。 ## [](#関連情報)関連情報 - [APIkit](https://docs.mulesoft.com/jp/apikit/latest/) - [APIKit エラー処理](https://docs.mulesoft.com/jp/apikit/latest/apikit-error-handling-reference) # API 仕様からのアプリケーションのビルド アプリケーション開発ライフサイクル中に APIkit を使用して API 仕様から Mule REST API または SOAP API をビルドできます。 次のモデリング言語に基づいて API を開発します。 - RAML (RESTful API Modeling Language) - WSDL (Web Service Description Language) - OData (APIkit OData 拡張を使用した OData 対応 API) - OAS (Open API 仕様) Anypoint Studio で APIkit を使用し、RAML または WSDL 仕様ファイルのインポートに基づいて Mule フローの作成を自動化することで、API の設計と実装を簡略化できます。API を生成したら、API をテストするコールを実行した後、実装を最終処理できます。 また、APIkit は、Apache Maven を使用してアプリケーションをビルドするのに役立つほか、既存のアプリケーション用のフローを生成するための CLI ツールも提供します。ただし、このいずれかのタスクを実行する前に、APIkit の基本構造を学習し、APIkit プロジェクトを開始するときに Mule フローを生成するスキャフォールディング手法を理解する必要があります。 ## [](#apikit-の構造)APIkit の構造 APIkit を使用する REST または SOAP Studio プロジェクトには、次の部分があります。 - REST または SOAP インターフェース - メインフロー - バックエンドフロー ![REST Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-rest-studio-project.png) Figure 1. REST Studio プロジェクト。 ![SOAP Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-soap-studio-project.png) Figure 2. SOAP Studio プロジェクト。 ### [](#rest-インターフェース)REST インターフェース REST リソースとアクション間のリレーションは、​_リソースとアクション_​のペアリングと呼ばれます。このインターフェースは、REST サービスにより要求された内部データアセットを公開します。また、このインターフェースは API を定義し (データを含むまたはデータにアクセスするリソースを指定します)、外部データに対するアクション (GET、PUT など) を指定します。 ### [](#soap-インターフェース)SOAP インターフェース WSDL ファイルで定義されたインターフェースでは、多くのサービスが公開されます。各サービスには一連の操作が含まれます。基盤となるデータ種別は、WSDL ファイル内のスキーマまたはインポートされた XSD ファイルで定義された XML です。 ### [](#メインフロー)メインフロー API のメインフローでは、次の機能が管理されます。 - HTTP 用 Anypoint Connector (HTTP Connector) を使用して API を公開する。 - HTTP 要求に基づいてインターフェースとバックエンドフロー間で要求を転送する。 - 要求を受け入れて、応答を送信し、インターフェースと API プロセス間の通信を促進する。 メインフローは HTTP Listener コンポーネントと APIkit (REST または SOAP) Router コンポーネントで構成されます。APIkit Router は、提供された定義に対して要求を検証し、メッセージを強化し (メッセージにデフォルト値を追加するなど)、要求をフローに転送する主要なメッセージプロセッサーです。また、ユーザー要求の転送中、検証中、または処理中にエラーが発生した場合、ルーターはエラーメッセージを出力します。 ![REST API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-rest-main-flow.png) Figure 3. REST API メインフロー。 ![SOAP API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-soap-main-flow.png) Figure 4. SOAP API メインフロー。 ### [](#バックエンドフロー)バックエンドフロー REST 用の APIkit は、RAML ファイル内のリソースとアクションのペアリングごとにバックエンドフローを生成します。 SOAP 用の APIkit は、WSDL 内の操作ごとにバックエンドフローを生成します。 次の例では、RAML インターフェースは GET 要求のユーザーを受け取ります。バックエンドフローはデータベースにアクセスし、ID でユーザーを参照します。 ![REST API バックエンドフロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-rest-backend-flows.png) Figure 5. REST API バックエンドフロー。 ### [](#コールの実行)コールの実行 REST API の場合、API Console を使用して API へのコールを実行します。 SOAP API の場合、SoapUI などの SOAP テストツールを使用して、API へのコールを実行します。 ## [](#apikit-プロジェクトを開始して-mule-フローを作成)APIkit プロジェクトを開始して Mule フローを作成 Studio で新しい APIkit プロジェクトを開始するときに、API 定義ファイルをインポートするオプションがあります。ファイルをインポートすると、APIkit スキャフォールディングメカニズムによって API のさまざまなフローが生成されます。Anypoint Studio で APIkit プロジェクトを開始する方法は 3 つあります。 ### [](#api-定義ファイルを使用して新しい-apikit-プロジェクトを開始)API 定義ファイルを使用して新しい APIkit プロジェクトを開始 既存の RAML または WSDL ファイルをインポートするか、ファイルの URL を参照してプロジェクトを開始する場合、次の方法を使用します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択します。 5. **\[Location (場所)\]**​ で、次のいずれかを実行します。 - Design Center で ​`api.raml`​ ファイルを作成している場合は、​**\[Design Center\]**​ を選択します。必要に応じて Anypoint Platform にログインし、​`api.raml`​ を選択します。 - Design Center で RAML ファイルを作成していない場合は、​**\[Browse Files (ファイルを参照)\]**​ を選択し、テキストエディターで作成した RAML または WSDL ファイルを選択します。WSDL ファイルの場合、ドロップダウンメニューからサービスとポートを選択するか、デフォルトを受け入れます。 1. \[Location (場所)\] のデフォルトオプションを受け入れて、​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様が選択された \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ](_images/mruntime-start-apikit-project-1.png) Figure 6. API 仕様を選択している \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディング手法によって以下が生成されます。 - 基本設定ファイルおよび Mule XML 設定ファイルを含むアーキタイプ - API の実装 RAML ベースの API の場合、RAML ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - HTTP Listener を含むメインフロー - APIkit Router コンポーネント - エラーハンドラー - RAML の連動関係 (Studio などの特定の場所から Design Center などの別の場所に変更をプッシュまたはプルします) - REST のリソースとアクションのマッピングを含むバックエンドフロー WSDL ベースの API の場合、WSDL ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - SOAP Router - SOAP エラー応答テンプレート - SOAP メッセージテンプレートを含むバックエンドフロー 次の図は APIkit スキャフォールディングを示しています。 ![RAML スキャフォールディング](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-raml-scaffolding.png) Figure 7. RAML スキャフォールディング。 ![WSDL スキャフォールディング](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-wsdl-scaffolding.png) Figure 8. WSDL スキャフォールディング。 Studio では、REST API APIkit プロジェクトは次のようになります。 ![Package Explorer とキャンバスセクションを含む REST API Anypoint Studio UI。](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-rest-api-studio-apikit.png) Figure 9. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の REST API。 この図で示されている 5 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`api.raml`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. APIkit Router を含むメインフロー。 3. APIkit Console 4. エラー処理 5. リソースメソッドごとに生成されたフロー。 生成された最小限のフローは、REST 契約で要求されるコミュニケーション操作を満たします。 Studio では、SOAP API APIkit プロジェクトは次のようになります。 ![Package Explorer とキャンバスセクションを含む SOAP API Anypoint Studio UI。](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-soap-api-studio-apikit.png) Figure 10. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の SOAP API。 この図で示されている 4 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`example.wsdl`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. SOAP Router を含むメインフロー。 3. SOAP エラー応答テンプレート 4. SOAP メッセージテンプレートを含む、生成されたバックエンドフロー。 APIkit プロジェクトを作成したら、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#新しい-apikit-プロジェクトを開始)新しい APIkit プロジェクトを開始 API 仕様ファイルなしで APIkit プロジェクトを開始し、後で API 仕様ファイルをプロジェクトに追加できる場合、この方法を使用します。APIkit は骨格 RAML ファイルと XML 設定ファイルを生成します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE。ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択​_しない_​でください。 これにより、バックエンドファーストの APIkit 設計が作成されます。 5. その他のデフォルトのオプションを受け入れて ​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様のない \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ](_images/mruntime-start-apikit-project-2.png) Figure 11. \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディングによって、次のコンポーネントを含む骨格 RAML ファイルおよび XML 設定ファイルが生成されます。 - メインフロー ​`` - メインフローの HTTP Listener 設定 - APIkit Router コンポーネント - エラーハンドラー 後で API 仕様をバックエンドファーストの APIkit 設計に追加し、バックエンドフローを生成して、アプリケーションのビルドを続行できます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#バックエンドフローを生成して新規-apikit-プロジェクトを開始)バックエンドフローを生成して新規 APIkit プロジェクトを開始 このタスクを実行するには、次の前提条件を満たしている必要があります。 - Studio (RAML エディター) で RAML ファイルを作成した - HTTP Listener および APIkit Router コンポーネントを含むメインフローを作成した Studio で RAML ファイルを作成するときに、バックエンドフローの生成は省略可能です。RAML ベースの API ではエラー処理が自動的に生成されます。APIkit プロジェクトを開始するには、バックエンドフローをメインフローから生成する必要があります。次の手順に従います。 1. Package Explorer で、プロジェクト名を右クリックします。 2. **\[Mule\] > \[Generate Flows From REST API (REST API からフローを生成)\]**​ を選択します。 ![Mule プロジェクトからのバックエンドフローの生成](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-start-apikit-project-3.png) Figure 12. Mule プロジェクトからのバックエンドフローの生成。 APIkit スキャフォールディング手法によってバックエンドフローがメインフローの後に生成されます。次に、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ## [](#アプリケーションワークフローのビルド)アプリケーションワークフローのビルド APIkit の基本構造とスキャフォールディング手法を理解したら、次のワークフローを参考にして、APIkit プロジェクトの作成、Mule フローの生成、API へのコールの実行、および実装の最終処理を行って、目的のアプリケーションをビルドします。 - [REST 用の APIkit を使用した REST API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-rest) - [SOAP 用の APIKit を使用した SOAP API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-soap) さらに次のことができます。 - [既存の Mule プロジェクトの APIkit プロジェクトへの変換](https://docs.mulesoft.com/jp/apikit/latest/apikit-workflow-convert-existing) 既存の APIkit バックエンドファーストの設計への API 仕様の追加、API 定義ファイルの定義、メインフローの作成、バックエンド REST API フローの生成、アクションへの RAML リソースのマップを行います。 - [APIkit 4.x タスクの実行](https://docs.mulesoft.com/jp/apikit/latest/key-configurations) APIkit プロジェクトの変更、API コンソールのカスタマイズ、ヘッダーの設定、RAML ファイルの取得、機能以外の要件の実行、ロードバランサーの設定を行います。 - [APIkit OData 拡張を使用した OData 対応 API の作成](https://docs.mulesoft.com/jp/apikit/latest/creating-an-odatav4-api-with-apikit) OData 要求を処理する Mule フローを生成します。 - [Maven を使用した APIkit プロジェクトの作成](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-scaffolding-reference) 既存の Apache Maven プロジェクトに APIkit コンポーネントを追加します。 ## [](#api-からのデータのコンシューム)API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。ガイドラインについては、​[「API からのデータのコンシューム」のドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.5/consume-data-from-an-api)​を参照してください。 ## [](#関連情報)関連情報 - [APIkit](https://docs.mulesoft.com/jp/apikit/latest/) - [APIkit エラー処理](https://docs.mulesoft.com/jp/apikit/latest/apikit-error-handling-reference) # API 仕様からのアプリケーションのビルド アプリケーション開発ライフサイクル中に APIkit を使用して API 仕様から Mule REST API または SOAP API をビルドできます。 次のモデリング言語に基づいて API を開発します。 - RAML (RESTful API Modeling Language) - WSDL (Web Service Description Language) - OData (APIkit OData 拡張を使用した OData 対応 API) - OAS (Open API 仕様) Anypoint Studio で APIkit を使用し、RAML または WSDL 仕様ファイルのインポートに基づいて Mule フローの作成を自動化することで、API の設計と実装を簡略化できます。API を生成したら、API をテストするコールを実行した後、実装を最終処理できます。 また、APIkit は、Apache Maven を使用してアプリケーションをビルドするのに役立つほか、既存のアプリケーション用のフローを生成するための CLI ツールも提供します。ただし、このいずれかのタスクを実行する前に、APIkit の基本構造を学習し、APIkit プロジェクトを開始するときに Mule フローを生成するスキャフォールディング手法を理解する必要があります。 ## [](#apikit-の構造)APIkit の構造 APIkit を使用する REST または SOAP Studio プロジェクトには、次の部分があります。 - REST または SOAP インターフェース - メインフロー - バックエンドフロー ![REST Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-rest-studio-project.png) Figure 1. REST Studio プロジェクト。 ![SOAP Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-soap-studio-project.png) Figure 2. SOAP Studio プロジェクト。 ### [](#rest-インターフェース)REST インターフェース REST リソースとアクション間のリレーションは、​_リソースとアクション_​のペアリングと呼ばれます。このインターフェースは、REST サービスにより要求された内部データアセットを公開します。また、このインターフェースは API を定義し (データを含むまたはデータにアクセスするリソースを指定します)、外部データに対するアクション (GET、PUT など) を指定します。 ### [](#soap-インターフェース)SOAP インターフェース WSDL ファイルで定義されたインターフェースでは、多くのサービスが公開されます。各サービスには一連の操作が含まれます。基盤となるデータ種別は、WSDL ファイル内のスキーマまたはインポートされた XSD ファイルで定義された XML です。 ### [](#メインフロー)メインフロー API のメインフローでは、次の機能が管理されます。 - HTTP 用 Anypoint Connector (HTTP Connector) を使用して API を公開する。 - HTTP 要求に基づいてインターフェースとバックエンドフロー間で要求を転送する。 - 要求を受け入れて、応答を送信し、インターフェースと API プロセス間の通信を促進する。 メインフローは HTTP Listener コンポーネントと APIkit (REST または SOAP) Router コンポーネントで構成されます。APIkit Router は、提供された定義に対して要求を検証し、メッセージを強化し (メッセージにデフォルト値を追加するなど)、要求をフローに転送する主要なメッセージプロセッサーです。また、ユーザー要求の転送中、検証中、または処理中にエラーが発生した場合、ルーターはエラーメッセージを出力します。 ![REST API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-rest-main-flow.png) Figure 3. REST API メインフロー。 ![SOAP API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-soap-main-flow.png) Figure 4. SOAP API メインフロー。 ### [](#バックエンドフロー)バックエンドフロー REST 用の APIkit は、RAML ファイル内のリソースとアクションのペアリングごとにバックエンドフローを生成します。 SOAP 用の APIkit は、WSDL 内の操作ごとにバックエンドフローを生成します。 次の例では、RAML インターフェースは GET 要求のユーザーを受け取ります。バックエンドフローはデータベースにアクセスし、ID でユーザーを参照します。 ![REST API バックエンドフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-rest-backend-flows.png) Figure 5. REST API バックエンドフロー。 ### [](#コールの実行)コールの実行 REST API の場合、API Console を使用して API へのコールを実行します。 SOAP API の場合、SoapUI などの SOAP テストツールを使用して、API へのコールを実行します。 ## [](#apikit-プロジェクトを開始して-mule-フローを作成)APIkit プロジェクトを開始して Mule フローを作成 Studio で新しい APIkit プロジェクトを開始するときに、API 定義ファイルをインポートするオプションがあります。ファイルをインポートすると、APIkit スキャフォールディングメカニズムによって API のさまざまなフローが生成されます。Anypoint Studio で APIkit プロジェクトを開始する方法は 3 つあります。 ### [](#api-定義ファイルを使用して新しい-apikit-プロジェクトを開始)API 定義ファイルを使用して新しい APIkit プロジェクトを開始 既存の RAML または WSDL ファイルをインポートするか、ファイルの URL を参照してプロジェクトを開始する場合、次の方法を使用します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択します。 5. **\[Location (場所)\]**​ で、次のいずれかを実行します。 - Design Center で ​`api.raml`​ ファイルを作成している場合は、​**\[Design Center\]**​ を選択します。必要に応じて Anypoint Platform にログインし、​`api.raml`​ を選択します。 - Design Center で RAML ファイルを作成していない場合は、​**\[Browse Files (ファイルを参照)\]**​ を選択し、テキストエディターで作成した RAML または WSDL ファイルを選択します。WSDL ファイルの場合、ドロップダウンメニューからサービスとポートを選択するか、デフォルトを受け入れます。 1. \[Location (場所)\] のデフォルトオプションを受け入れて、​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様が選択された \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ](_images/mruntime-start-apikit-project-1.png) Figure 6. API 仕様を選択している \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディング手法によって以下が生成されます。 - 基本設定ファイルおよび Mule XML 設定ファイルを含むアーキタイプ - API の実装 RAML ベースの API の場合、RAML ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - HTTP Listener を含むメインフロー - APIkit Router コンポーネント - エラーハンドラー - RAML の連動関係 (Studio などの特定の場所から Design Center などの別の場所に変更をプッシュまたはプルします) - REST のリソースとアクションのマッピングを含むバックエンドフロー WSDL ベースの API の場合、WSDL ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - SOAP Router - SOAP エラー応答テンプレート - SOAP メッセージテンプレートを含むバックエンドフロー 次の図は APIkit スキャフォールディングを示しています。 ![RAML スキャフォールディング](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-raml-scaffolding.png) Figure 7. RAML スキャフォールディング。 ![WSDL スキャフォールディング](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-wsdl-scaffolding.png) Figure 8. WSDL スキャフォールディング。 Studio では、REST API APIkit プロジェクトは次のようになります。 ![Package Explorer とキャンバスセクションを含む REST API Anypoint Studio UI。](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-rest-api-studio-apikit.png) Figure 9. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の REST API。 この図で示されている 5 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`api.raml`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. APIkit Router を含むメインフロー。 3. APIkit Console 4. エラー処理 5. リソースメソッドごとに生成されたフロー。 生成された最小限のフローは、REST 契約で要求されるコミュニケーション操作を満たします。 Studio では、SOAP API APIkit プロジェクトは次のようになります。 ![Package Explorer とキャンバスセクションを含む SOAP API Anypoint Studio UI。](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-soap-api-studio-apikit.png) Figure 10. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の SOAP API。 この図で示されている 4 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`example.wsdl`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. SOAP Router を含むメインフロー。 3. SOAP エラー応答テンプレート 4. SOAP メッセージテンプレートを含む、生成されたバックエンドフロー。 APIkit プロジェクトを作成したら、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#新しい-apikit-プロジェクトを開始)新しい APIkit プロジェクトを開始 API 仕様ファイルなしで APIkit プロジェクトを開始し、後で API 仕様ファイルをプロジェクトに追加できる場合、この方法を使用します。APIkit は骨格 RAML ファイルと XML 設定ファイルを生成します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE。ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択​_しない_​でください。 これにより、バックエンドファーストの APIkit 設計が作成されます。 5. その他のデフォルトのオプションを受け入れて ​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様のない \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ](_images/mruntime-start-apikit-project-2.png) Figure 11. \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディングによって、次のコンポーネントを含む骨格 RAML ファイルおよび XML 設定ファイルが生成されます。 - メインフロー ​`` - メインフローの HTTP Listener 設定 - APIkit Router コンポーネント - エラーハンドラー 後で API 仕様をバックエンドファーストの APIkit 設計に追加し、バックエンドフローを生成して、アプリケーションのビルドを続行できます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#バックエンドフローを生成して新規-apikit-プロジェクトを開始)バックエンドフローを生成して新規 APIkit プロジェクトを開始 このタスクを実行するには、次の前提条件を満たしている必要があります。 - Studio (RAML エディター) で RAML ファイルを作成した - HTTP Listener および APIkit Router コンポーネントを含むメインフローを作成した Studio で RAML ファイルを作成するときに、バックエンドフローの生成は省略可能です。RAML ベースの API ではエラー処理が自動的に生成されます。APIkit プロジェクトを開始するには、バックエンドフローをメインフローから生成する必要があります。次の手順に従います。 1. Package Explorer で、プロジェクト名を右クリックします。 2. **\[Mule\] > \[Generate Flows From REST API (REST API からフローを生成)\]**​ を選択します。 ![Mule プロジェクトからのバックエンドフローの生成](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-start-apikit-project-3.png) Figure 12. Mule プロジェクトからのバックエンドフローの生成。 APIkit スキャフォールディング手法によってバックエンドフローがメインフローの後に生成されます。次に、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ## [](#アプリケーションワークフローのビルド)アプリケーションワークフローのビルド APIkit の基本構造とスキャフォールディング手法を理解したら、次のワークフローを参考にして、APIkit プロジェクトの作成、Mule フローの生成、API へのコールの実行、および実装の最終処理を行って、目的のアプリケーションをビルドします。 - [REST 用の APIKit を使用した REST API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-rest) - [SOAP 用の APIKit を使用した SOAP API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-soap) さらに次のことができます。 - [既存の Mule プロジェクトの APIkit プロジェクトへの変換](https://docs.mulesoft.com/jp/apikit/latest/apikit-workflow-convert-existing) 既存の APIkit バックエンドファーストの設計への API 仕様の追加、API 定義ファイルの定義、メインフローの作成、バックエンド REST API フローの生成、アクションへの RAML リソースのマップを行います。 - [APIkit 4.x タスクの実行](https://docs.mulesoft.com/jp/apikit/latest/key-configurations) APIkit プロジェクトの変更、API コンソールのカスタマイズ、ヘッダーの設定、RAML ファイルの取得、機能以外の要件の実行、ロードバランサーの設定を行います。 - [APIkit OData 拡張を使用した OData 対応 API の作成](https://docs.mulesoft.com/jp/apikit/latest/creating-an-odatav4-api-with-apikit) OData 要求を処理する Mule フローを生成します。 - [Maven を使用した APIkit プロジェクトの作成](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-scaffolding-reference) 既存の Apache Maven プロジェクトに APIkit コンポーネントを追加します。 ## [](#api-からのデータのコンシューム)API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。ガイドラインについては、​[「API からのデータのコンシューム」のドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.6/consume-data-from-an-api)​を参照してください。 ## [](#関連情報)関連情報 - [APIkit](https://docs.mulesoft.com/jp/apikit/latest/) - [APIKit エラー処理](https://docs.mulesoft.com/jp/apikit/latest/apikit-error-handling-reference) # API 仕様からのアプリケーションのビルド アプリケーション開発ライフサイクル中に APIkit を使用して API 仕様から Mule REST API または SOAP API をビルドできます。 次のモデリング言語に基づいて API を開発します。 - RAML (RESTful API Modeling Language) - WSDL (Web Service Description Language) - OData (APIkit OData 拡張を使用した OData 対応 API) - OAS (Open API 仕様) Anypoint Studio で APIkit を使用し、RAML または WSDL 仕様ファイルのインポートに基づいて Mule フローの作成を自動化することで、API の設計と実装を簡略化できます。API を生成したら、API をテストするコールを実行した後、実装を最終処理できます。 また、APIkit は、Apache Maven を使用してアプリケーションをビルドするのに役立つほか、既存のアプリケーション用のフローを生成するための CLI ツールも提供します。ただし、このいずれかのタスクを実行する前に、APIkit の基本構造を学習し、APIkit プロジェクトを開始するときに Mule フローを生成するスキャフォールディング手法を理解する必要があります。 ## [](#apikit-の構造)APIkit の構造 APIkit を使用する REST または SOAP Studio プロジェクトには、次の部分があります。 - REST または SOAP インターフェース - メインフロー - バックエンドフロー ![APIkit Router や API Console などのコンポーネントが表示されている REST Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-rest-studio-project.png) Figure 1. REST Studio プロジェクト。 ![SOAP Router や Transform Message などのコンポーネントが表示されている SOAP Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-soap-studio-project.png) Figure 2. SOAP Studio プロジェクト。 ### [](#rest-インターフェース)REST インターフェース REST リソースとアクション間のリレーションは、​_リソースとアクション_​のペアリングと呼ばれます。このインターフェースは、REST サービスにより要求された内部データアセットを公開します。また、このインターフェースは API を定義し (データを含むまたはデータにアクセスするリソースを指定します)、外部データに対するアクション (GET、PUT など) を指定します。 ### [](#soap-インターフェース)SOAP インターフェース WSDL ファイルで定義されたインターフェースでは、多くのサービスが公開されます。各サービスには一連の操作が含まれます。基盤となるデータ種別は、WSDL ファイル内のスキーマまたはインポートされた XSD ファイルで定義された XML です。 ### [](#メインフロー)メインフロー API のメインフローでは、次の機能が管理されます。 - HTTP 用 Anypoint Connector (HTTP Connector) を使用して API を公開する。 - HTTP 要求に基づいてインターフェースとバックエンドフロー間で要求を転送する。 - 要求を受け入れて、応答を送信し、インターフェースと API プロセス間の通信を促進する。 メインフローは HTTP Listener コンポーネントと APIkit (REST または SOAP) Router コンポーネントで構成されます。APIkit Router は、提供された定義に対して要求を検証し、メッセージを強化し (メッセージにデフォルト値を追加するなど)、要求をフローに転送する主要なメッセージプロセッサーです。また、ユーザー要求の転送中、検証中、または処理中にエラーが発生した場合、ルーターはエラーメッセージを出力します。 ![Listener や APIkit Router などのコンポーネントが含まれる REST API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-rest-main-flow.png) Figure 3. REST API メインフロー。 ![Listener や SOAP Router などのコンポーネントが含まれる SOAP API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-soap-main-flow.png) Figure 4. SOAP API メインフロー。 ### [](#バックエンドフロー)バックエンドフロー REST 用の APIkit は、RAML ファイル内のリソースとアクションのペアリングごとにバックエンドフローを生成します。 SOAP 用の APIkit は、WSDL 内の操作ごとにバックエンドフローを生成します。 次の例では、RAML インターフェースは GET 要求のユーザーを受け取ります。バックエンドフローはデータベースにアクセスし、ID でユーザーを参照します。 ![REST API バックエンドフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-rest-backend-flows.png) Figure 5. REST API バックエンドフロー。 ### [](#コールの実行)コールの実行 REST API の場合、API Console を使用して API へのコールを実行します。 SOAP API の場合、SoapUI などの SOAP テストツールを使用して、API へのコールを実行します。 ## [](#apikit-プロジェクトを開始して-mule-フローを作成)APIkit プロジェクトを開始して Mule フローを作成 Studio で新しい APIkit プロジェクトを開始するときに、API 定義ファイルをインポートするオプションがあります。ファイルをインポートすると、APIkit スキャフォールディングメカニズムによって API のさまざまなフローが生成されます。Anypoint Studio で APIkit プロジェクトを開始する方法は 3 つあります。 ### [](#api-定義ファイルを使用して新しい-apikit-プロジェクトを開始)API 定義ファイルを使用して新しい APIkit プロジェクトを開始 既存の RAML または WSDL ファイルをインポートするか、ファイルの URL を参照してプロジェクトを開始する場合、次の方法を使用します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択します。 5. **\[Location (場所)\]**​ で、次のいずれかを実行します。 - Design Center で ​`api.raml`​ ファイルを作成している場合は、​**\[Design Center\]**​ を選択します。必要に応じて Anypoint Platform にログインし、​`api.raml`​ を選択します。 - Design Center で RAML ファイルを作成していない場合は、​**\[Browse Files (ファイルを参照)\]**​ を選択し、テキストエディターで作成した RAML または WSDL ファイルを選択します。WSDL ファイルの場合、ドロップダウンメニューからサービスとポートを選択するか、デフォルトを受け入れます。 1. \[Location (場所)\] のデフォルトオプションを受け入れて、​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様が選択された新しい Mule プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-start-apikit-project-1.png) Figure 6. API 仕様を選択している \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディング手法によって以下が生成されます。 - 基本設定ファイルおよび Mule XML 設定ファイルを含むアーキタイプ - API の実装 RAML ベースの API の場合、RAML ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - HTTP Listener を含むメインフロー - APIkit Router コンポーネント - エラーハンドラー - RAML の連動関係 (Studio などの特定の場所から Design Center などの別の場所に変更をプッシュまたはプルします) - REST のリソースとアクションのマッピングを含むバックエンドフロー WSDL ベースの API の場合、WSDL ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - SOAP Router - SOAP エラー応答テンプレート - SOAP メッセージテンプレートを含むバックエンドフロー 次の図は APIkit スキャフォールディングを示しています。 ![Listener、APIkit Router、Error handling コンポーネントが含まれる RAML スキャフォールディングの XML 設定。](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-raml-scaffolding.png) Figure 7. RAML スキャフォールディング。 ![Listener、SOAP Router、Error handling コンポーネントが含まれる WSDL スキャフォールディングの XML 設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-wsdl-scaffolding.png) Figure 8. WSDL スキャフォールディング。 Studio では、REST API APIkit プロジェクトは次のようになります。 ![REST API 要求を処理するファイルおよび設定が含まれる APIkit プロジェクト。](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-rest-api-studio-apikit.png) Figure 9. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の REST API。 この図で示されている 5 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`api.raml`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. APIkit Router を含むメインフロー。 3. APIkit Console 4. エラー処理 5. リソースメソッドごとに生成されたフロー。 生成された最小限のフローは、REST 契約で要求されるコミュニケーション操作を満たします。 Studio では、SOAP API APIkit プロジェクトは次のようになります。 ![Anypoint Studio の Package Explorer とキャンバスが表示されている REST API APIkit プロジェクトセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-soap-api-studio-apikit.png) Figure 10. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の SOAP API。 この図で示されている 4 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`example.wsdl`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. SOAP Router を含むメインフロー。 3. SOAP エラー応答テンプレート 4. SOAP メッセージテンプレートを含む、生成されたバックエンドフロー。 APIkit プロジェクトを作成したら、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#新しい-apikit-プロジェクトを開始)新しい APIkit プロジェクトを開始 API 仕様ファイルなしで APIkit プロジェクトを開始し、後で API 仕様ファイルをプロジェクトに追加できる場合、この方法を使用します。APIkit は骨格 RAML ファイルと XML 設定ファイルを生成します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE。ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択​_しない_​でください。 これにより、バックエンドファーストの APIkit 設計が作成されます。 5. その他のデフォルトのオプションを受け入れて ​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様のない新しい Mule プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-start-apikit-project-2.png) Figure 11. \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディングによって、次のコンポーネントを含む骨格 RAML ファイルおよび XML 設定ファイルが生成されます。 - メインフロー ​`` - メインフローの HTTP Listener 設定 - APIkit Router コンポーネント - エラーハンドラー 後で API 仕様をバックエンドファーストの APIkit 設計に追加し、バックエンドフローを生成して、アプリケーションのビルドを続行できます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#バックエンドフローを生成して新規-apikit-プロジェクトを開始)バックエンドフローを生成して新規 APIkit プロジェクトを開始 このタスクを実行するには、次の前提条件を満たしている必要があります。 - Studio (RAML エディター) で RAML ファイルを作成した - HTTP Listener および APIkit Router コンポーネントを含むメインフローを作成した Studio で RAML ファイルを作成するときに、バックエンドフローの生成は省略可能です。RAML ベースの API ではエラー処理が自動的に生成されます。APIkit プロジェクトを開始するには、バックエンドフローをメインフローから生成する必要があります。次の手順に従います。 1. Package Explorer で、プロジェクト名を右クリックします。 2. **\[Mule\] > \[Generate Flows From REST API (REST API からフローを生成)\]**​ を選択します。 ![Mule プロジェクトからバックエンドフローを生成するオプションが表示されている \[Package Explorer\] ビュー](_images/mruntime-start-apikit-project-3.png) Figure 12. Mule プロジェクトからのバックエンドフローの生成。 APIkit スキャフォールディング手法によってバックエンドフローがメインフローの後に生成されます。次に、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ## [](#アプリケーションワークフローのビルド)アプリケーションワークフローのビルド APIkit の基本構造とスキャフォールディング手法を理解したら、次のワークフローを参考にして、APIkit プロジェクトの作成、Mule フローの生成、API へのコールの実行、および実装の最終処理を行って、目的のアプリケーションをビルドします。 - [REST 用の APIKit を使用した REST API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-rest) - [SOAP 用の APIKit を使用した SOAP API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-soap) さらに次のことができます。 - [既存の Mule プロジェクトの APIkit プロジェクトへの変換](https://docs.mulesoft.com/jp/apikit/latest/apikit-workflow-convert-existing) 既存の APIkit バックエンドファーストの設計への API 仕様の追加、API 定義ファイルの定義、メインフローの作成、バックエンド REST API フローの生成、アクションへの RAML リソースのマップを行います。 - [APIkit 4.x タスクの実行](https://docs.mulesoft.com/jp/apikit/latest/key-configurations) APIkit プロジェクトの変更、API Console のカスタマイズ、ヘッダーの設定、RAML ファイルの取得、機能以外の要件の実行、ロードバランサーの設定を行います。 - [APIkit OData 拡張を使用した OData 対応 API の作成](https://docs.mulesoft.com/jp/apikit/latest/creating-an-odatav4-api-with-apikit) OData 要求を処理する Mule フローを生成します。 - [Maven を使用した APIkit プロジェクトの作成](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-scaffolding-reference) 既存の Apache Maven プロジェクトに APIkit コンポーネントを追加します。 ## [](#api-からのデータのコンシューム)API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。ガイドラインについては、​[「API からのデータのコンシューム」のドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.7/consume-data-from-an-api)​を参照してください。 ## [](#関連情報)関連情報 - [APIkit](https://docs.mulesoft.com/jp/apikit/latest/) - [APIKit エラー処理](https://docs.mulesoft.com/jp/apikit/latest/apikit-error-handling-reference) # API 仕様からのアプリケーションのビルド アプリケーション開発ライフサイクル中に APIkit を使用して API 仕様から Mule REST API または SOAP API をビルドできます。 次のモデリング言語に基づいて API を開発します。 - RAML (RESTful API Modeling Language) - WSDL (Web Service Description Language) - OData (APIkit OData 拡張を使用した OData 対応 API) - OAS (Open API 仕様) Anypoint Studio で APIkit を使用し、RAML または WSDL 仕様ファイルのインポートに基づいて Mule フローの作成を自動化することで、API の設計と実装を簡略化できます。API を生成したら、API をテストするコールを実行した後、実装を最終処理できます。 また、APIkit は、Apache Maven を使用してアプリケーションをビルドするのに役立つほか、既存のアプリケーション用のフローを生成するための CLI ツールも提供します。ただし、このいずれかのタスクを実行する前に、APIkit の基本構造を学習し、APIkit プロジェクトを開始するときに Mule フローを生成するスキャフォールディング手法を理解する必要があります。 ## [](#apikit-の構造)APIkit の構造 APIkit を使用する REST または SOAP Studio プロジェクトには、次の部分があります。 - REST または SOAP インターフェース - メインフロー - バックエンドフロー ![APIkit Router や API Console などのコンポーネントが表示されている REST Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-studio-project.png) Figure 1. REST Studio プロジェクト。 ![SOAP Router や Transform Message などのコンポーネントが表示されている SOAP Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-soap-studio-project.png) Figure 2. SOAP Studio プロジェクト。 ### [](#rest-インターフェース)REST インターフェース REST リソースとアクション間のリレーションは、​_リソースとアクション_​のペアリングと呼ばれます。このインターフェースは、REST サービスにより要求された内部データアセットを公開します。また、このインターフェースは API を定義し (データを含むまたはデータにアクセスするリソースを指定します)、外部データに対するアクション (GET、PUT など) を指定します。 ### [](#soap-インターフェース)SOAP インターフェース WSDL ファイルで定義されたインターフェースでは、多くのサービスが公開されます。各サービスには一連の操作が含まれます。基盤となるデータ種別は、WSDL ファイル内のスキーマまたはインポートされた XSD ファイルで定義された XML です。 ### [](#メインフロー)メインフロー API のメインフローでは、次の機能が管理されます。 - HTTP 用 Anypoint Connector (HTTP Connector) を使用して API を公開する。 - HTTP 要求に基づいてインターフェースとバックエンドフロー間で要求を転送する。 - 要求を受け入れて、応答を送信し、インターフェースと API プロセス間の通信を促進する。 メインフローは HTTP Listener コンポーネントと APIkit (REST または SOAP) Router コンポーネントで構成されます。APIkit Router は、提供された定義に対して要求を検証し、メッセージを強化し (メッセージにデフォルト値を追加するなど)、要求をフローに転送する主要なメッセージプロセッサーです。また、ユーザー要求の転送中、検証中、または処理中にエラーが発生した場合、ルーターはエラーメッセージを出力します。 ![Listener や APIkit Router などのコンポーネントが含まれる REST API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-main-flow.png) Figure 3. REST API メインフロー。 ![Listener や SOAP Router などのコンポーネントが含まれる SOAP API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-soap-main-flow.png) Figure 4. SOAP API メインフロー。 ### [](#バックエンドフロー)バックエンドフロー REST 用の APIkit は、RAML ファイル内のリソースとアクションのペアリングごとにバックエンドフローを生成します。 SOAP 用の APIkit は、WSDL 内の操作ごとにバックエンドフローを生成します。 次の例では、RAML インターフェースは GET 要求のユーザーを受け取ります。バックエンドフローはデータベースにアクセスし、ID でユーザーを参照します。 ![REST API バックエンドフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-backend-flows.png) Figure 5. REST API バックエンドフロー。 ### [](#コールの実行)コールの実行 REST API の場合、API Console を使用して API へのコールを実行します。 SOAP API の場合、SoapUI などの SOAP テストツールを使用して、API へのコールを実行します。 ## [](#apikit-プロジェクトを開始して-mule-フローを作成)APIkit プロジェクトを開始して Mule フローを作成 Studio で新しい APIkit プロジェクトを開始するときに、API 定義ファイルをインポートするオプションがあります。ファイルをインポートすると、APIkit スキャフォールディングメカニズムによって API のさまざまなフローが生成されます。Anypoint Studio で APIkit プロジェクトを開始する方法は 3 つあります。 ### [](#api-定義ファイルを使用して新しい-apikit-プロジェクトを開始)API 定義ファイルを使用して新しい APIkit プロジェクトを開始 既存の RAML または WSDL ファイルをインポートするか、ファイルの URL を参照してプロジェクトを開始する場合、次の方法を使用します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択します。 5. **\[Location (場所)\]**​ で、次のいずれかを実行します。 - Design Center で ​`api.raml`​ ファイルを作成している場合は、​**\[Design Center\]**​ を選択します。必要に応じて Anypoint Platform にログインし、​`api.raml`​ を選択します。 - Design Center で RAML ファイルを作成していない場合は、​**\[Browse Files (ファイルを参照)\]**​ を選択し、テキストエディターで作成した RAML または WSDL ファイルを選択します。WSDL ファイルの場合、ドロップダウンメニューからサービスとポートを選択するか、デフォルトを受け入れます。 1. \[Location (場所)\] のデフォルトオプションを受け入れて、​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様が選択された新しい Mule プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-start-apikit-project-1.png) Figure 6. API 仕様を選択している \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディング手法によって以下が生成されます。 - 基本設定ファイルおよび Mule XML 設定ファイルを含むアーキタイプ - API の実装 RAML ベースの API の場合、RAML ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - HTTP Listener を含むメインフロー - APIkit Router コンポーネント - エラーハンドラー - RAML の連動関係 (Studio などの特定の場所から Design Center などの別の場所に変更をプッシュまたはプルします) - REST のリソースとアクションのマッピングを含むバックエンドフロー WSDL ベースの API の場合、WSDL ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - SOAP Router - SOAP エラー応答テンプレート - SOAP メッセージテンプレートを含むバックエンドフロー 次の図は APIkit スキャフォールディングを示しています。 ![Listener、APIkit Router、Error handling コンポーネントが含まれる RAML スキャフォールディングの XML 設定。](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-raml-scaffolding.png) Figure 7. RAML スキャフォールディング。 ![Listener、SOAP Router、Error handling コンポーネントが含まれる WSDL スキャフォールディングの XML 設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-wsdl-scaffolding.png) Figure 8. WSDL スキャフォールディング。 Studio では、REST API APIkit プロジェクトは次のようになります。 ![REST API 要求を処理するファイルおよび設定が含まれる APIkit プロジェクト。](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-api-studio-apikit.png) Figure 9. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の REST API。 この図で示されている 5 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`api.raml`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. APIkit Router を含むメインフロー。 3. APIkit Console 4. エラー処理 5. リソースメソッドごとに生成されたフロー。 生成された最小限のフローは、REST 契約で要求されるコミュニケーション操作を満たします。 Studio では、SOAP API APIkit プロジェクトは次のようになります。 ![Anypoint Studio の Package Explorer とキャンバスが表示されている REST API APIkit プロジェクトセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-soap-api-studio-apikit.png) Figure 10. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の SOAP API。 この図で示されている 4 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`example.wsdl`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. SOAP Router を含むメインフロー。 3. SOAP エラー応答テンプレート 4. SOAP メッセージテンプレートを含む、生成されたバックエンドフロー。 APIkit プロジェクトを作成したら、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#新しい-apikit-プロジェクトを開始)新しい APIkit プロジェクトを開始 API 仕様ファイルなしで APIkit プロジェクトを開始し、後で API 仕様ファイルをプロジェクトに追加できる場合、この方法を使用します。APIkit は骨格 RAML ファイルと XML 設定ファイルを生成します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE。ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択​_しない_​でください。 これにより、バックエンドファーストの APIkit 設計が作成されます。 5. その他のデフォルトのオプションを受け入れて ​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様のない新しい Mule プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-start-apikit-project-2.png) Figure 11. \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディングによって、次のコンポーネントを含む骨格 RAML ファイルおよび XML 設定ファイルが生成されます。 - メインフロー ​`` - メインフローの HTTP Listener 設定 - APIkit Router コンポーネント - エラーハンドラー 後で API 仕様をバックエンドファーストの APIkit 設計に追加し、バックエンドフローを生成して、アプリケーションのビルドを続行できます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#バックエンドフローを生成して新規-apikit-プロジェクトを開始)バックエンドフローを生成して新規 APIkit プロジェクトを開始 このタスクを実行するには、次の前提条件を満たしている必要があります。 - Studio (RAML エディター) で RAML ファイルを作成した - HTTP Listener および APIkit Router コンポーネントを含むメインフローを作成した Studio で RAML ファイルを作成するときに、バックエンドフローの生成は省略可能です。RAML ベースの API ではエラー処理が自動的に生成されます。APIkit プロジェクトを開始するには、バックエンドフローをメインフローから生成する必要があります。次の手順に従います。 1. Package Explorer で、プロジェクト名を右クリックします。 2. **\[Mule\] > \[Generate Flows From REST API (REST API からフローを生成)\]**​ を選択します。 ![Mule プロジェクトからバックエンドフローを生成するオプションが表示されている \[Package Explorer\] ビュー](_images/mruntime-start-apikit-project-3.png) Figure 12. Mule プロジェクトからのバックエンドフローの生成。 APIkit スキャフォールディング手法によってバックエンドフローがメインフローの後に生成されます。次に、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ## [](#アプリケーションワークフローのビルド)アプリケーションワークフローのビルド APIkit の基本構造とスキャフォールディング手法を理解したら、次のワークフローを参考にして、APIkit プロジェクトの作成、Mule フローの生成、API へのコールの実行、および実装の最終処理を行って、目的のアプリケーションをビルドします。 - [REST 用の APIKit を使用した REST API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-rest) - [SOAP 用の APIKit を使用した SOAP API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-soap) さらに次のことができます。 - [既存の Mule プロジェクトの APIkit プロジェクトへの変換](https://docs.mulesoft.com/jp/apikit/latest/apikit-workflow-convert-existing) 既存の APIkit バックエンドファーストの設計への API 仕様の追加、API 定義ファイルの定義、メインフローの作成、バックエンド REST API フローの生成、アクションへの RAML リソースのマップを行います。 - [APIkit 4.x タスクの実行](https://docs.mulesoft.com/jp/apikit/latest/key-configurations) APIkit プロジェクトの変更、API Console のカスタマイズ、ヘッダーの設定、RAML ファイルの取得、機能以外の要件の実行、ロードバランサーの設定を行います。 - [APIkit OData 拡張を使用した OData 対応 API の作成](https://docs.mulesoft.com/jp/apikit/latest/creating-an-odatav4-api-with-apikit) OData 要求を処理する Mule フローを生成します。 - [Maven を使用した APIkit プロジェクトの作成](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-scaffolding-reference) 既存の Apache Maven プロジェクトに APIkit コンポーネントを追加します。 ## [](#api-からのデータのコンシューム)API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。ガイドラインについては、​[「API からのデータのコンシューム」のドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.8/consume-data-from-an-api)​を参照してください。 ## [](#関連情報)関連情報 - [APIkit](https://docs.mulesoft.com/jp/apikit/latest/) - [APIKit エラー処理](https://docs.mulesoft.com/jp/apikit/latest/apikit-error-handling-reference) # API 仕様からのアプリケーションのビルド アプリケーション開発ライフサイクル中に APIkit を使用して API 仕様から Mule REST API または SOAP API をビルドできます。 次のモデリング言語に基づいて API を開発します。 - RAML (RESTful API Modeling Language) - WSDL (Web Service Description Language) - OData (APIkit OData 拡張を使用した OData 対応 API) - OAS (Open API 仕様) Anypoint Studio で APIkit を使用し、RAML または WSDL 仕様ファイルのインポートに基づいて Mule フローの作成を自動化することで、API の設計と実装を簡略化できます。API を生成したら、API をテストするコールを実行した後、実装を最終処理できます。 また、APIkit は、Apache Maven を使用してアプリケーションをビルドするのに役立つほか、既存のアプリケーション用のフローを生成するための CLI ツールも提供します。ただし、このいずれかのタスクを実行する前に、APIkit の基本構造を学習し、APIkit プロジェクトを開始するときに Mule フローを生成するスキャフォールディング手法を理解する必要があります。 ## [](#apikit-の構造)APIkit の構造 APIkit を使用する REST または SOAP Studio プロジェクトには、次の部分があります。 - REST または SOAP インターフェース - メインフロー - バックエンドフロー ![APIkit Router や API Console などのコンポーネントが表示されている REST Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-studio-project.png) Figure 1. REST Studio プロジェクト。 ![SOAP Router や Transform Message などのコンポーネントが表示されている SOAP Studio プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-soap-studio-project.png) Figure 2. SOAP Studio プロジェクト。 ### [](#rest-インターフェース)REST インターフェース REST リソースとアクション間のリレーションは、​_リソースとアクション_​のペアリングと呼ばれます。このインターフェースは、REST サービスにより要求された内部データアセットを公開します。また、このインターフェースは API を定義し (データを含むまたはデータにアクセスするリソースを指定します)、外部データに対するアクション (GET、PUT など) を指定します。 ### [](#soap-インターフェース)SOAP インターフェース WSDL ファイルで定義されたインターフェースでは、多くのサービスが公開されます。各サービスには一連の操作が含まれます。基盤となるデータ種別は、WSDL ファイル内のスキーマまたはインポートされた XSD ファイルで定義された XML です。 ### [](#メインフロー)メインフロー API のメインフローでは、次の機能が管理されます。 - HTTP 用 Anypoint Connector (HTTP Connector) を使用して API を公開する。 - HTTP 要求に基づいてインターフェースとバックエンドフロー間で要求を転送する。 - 要求を受け入れて、応答を送信し、インターフェースと API プロセス間の通信を促進する。 メインフローは HTTP Listener コンポーネントと APIkit (REST または SOAP) Router コンポーネントで構成されます。APIkit Router は、提供された定義に対して要求を検証し、メッセージを強化し (メッセージにデフォルト値を追加するなど)、要求をフローに転送する主要なメッセージプロセッサーです。また、ユーザー要求の転送中、検証中、または処理中にエラーが発生した場合、ルーターはエラーメッセージを出力します。 ![Listener や APIkit Router などのコンポーネントが含まれる REST API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-main-flow.png) Figure 3. REST API メインフロー。 ![Listener や SOAP Router などのコンポーネントが含まれる SOAP API メインフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-soap-main-flow.png) Figure 4. SOAP API メインフロー。 ### [](#バックエンドフロー)バックエンドフロー REST 用の APIkit は、RAML ファイル内のリソースとアクションのペアリングごとにバックエンドフローを生成します。 SOAP 用の APIkit は、WSDL 内の操作ごとにバックエンドフローを生成します。 次の例では、RAML インターフェースは GET 要求のユーザーを受け取ります。バックエンドフローはデータベースにアクセスし、ID でユーザーを参照します。 ![REST API バックエンドフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-backend-flows.png) Figure 5. REST API バックエンドフロー。 ### [](#コールの実行)コールの実行 REST API の場合、API Console を使用して API へのコールを実行します。 SOAP API の場合、SoapUI などの SOAP テストツールを使用して、API へのコールを実行します。 ## [](#apikit-プロジェクトを開始して-mule-フローを作成)APIkit プロジェクトを開始して Mule フローを作成 Studio で新しい APIkit プロジェクトを開始するときに、API 定義ファイルをインポートするオプションがあります。ファイルをインポートすると、APIkit スキャフォールディングメカニズムによって API のさまざまなフローが生成されます。Anypoint Studio で APIkit プロジェクトを開始する方法は 3 つあります。 ### [](#api-定義ファイルを使用して新しい-apikit-プロジェクトを開始)API 定義ファイルを使用して新しい APIkit プロジェクトを開始 既存の RAML または WSDL ファイルをインポートするか、ファイルの URL を参照してプロジェクトを開始する場合、次の方法を使用します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択します。 5. **\[Location (場所)\]**​ で、次のいずれかを実行します。 - Design Center で ​`api.raml`​ ファイルを作成している場合は、​**\[Design Center\]**​ を選択します。必要に応じて Anypoint Platform にログインし、​`api.raml`​ を選択します。 - Design Center で RAML ファイルを作成していない場合は、​**\[Browse Files (ファイルを参照)\]**​ を選択し、テキストエディターで作成した RAML または WSDL ファイルを選択します。WSDL ファイルの場合、ドロップダウンメニューからサービスとポートを選択するか、デフォルトを受け入れます。 1. \[Location (場所)\] のデフォルトオプションを受け入れて、​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様が選択された新しい Mule プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-start-apikit-project-1.png) Figure 6. API 仕様を選択している \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディング手法によって以下が生成されます。 - 基本設定ファイルおよび Mule XML 設定ファイルを含むアーキタイプ - API の実装 RAML ベースの API の場合、RAML ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - HTTP Listener を含むメインフロー - APIkit Router コンポーネント - エラーハンドラー - RAML の連動関係 (Studio などの特定の場所から Design Center などの別の場所に変更をプッシュまたはプルします) - REST のリソースとアクションのマッピングを含むバックエンドフロー WSDL ベースの API の場合、WSDL ファイルは ​`src/main/resources/api`​ フォルダーの下に表示されます。API の実装には以下が含まれます。 - SOAP Router - SOAP エラー応答テンプレート - SOAP メッセージテンプレートを含むバックエンドフロー 次の図は APIkit スキャフォールディングを示しています。 ![Listener、APIkit Router、Error handling コンポーネントが含まれる RAML スキャフォールディングの XML 設定。](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-raml-scaffolding.png) Figure 7. RAML スキャフォールディング。 ![Listener、SOAP Router、Error handling コンポーネントが含まれる WSDL スキャフォールディングの XML 設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-wsdl-scaffolding.png) Figure 8. WSDL スキャフォールディング。 Studio では、REST API APIkit プロジェクトは次のようになります。 ![REST API 要求を処理するファイルおよび設定が含まれる APIkit プロジェクト。](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-api-studio-apikit.png) Figure 9. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の REST API。 この図で示されている 5 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`api.raml`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. APIkit Router を含むメインフロー。 3. APIkit Console 4. エラー処理 5. リソースメソッドごとに生成されたフロー。 生成された最小限のフローは、REST 契約で要求されるコミュニケーション操作を満たします。 Studio では、SOAP API APIkit プロジェクトは次のようになります。 ![Anypoint Studio の Package Explorer とキャンバスが表示されている REST API APIkit プロジェクトセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-soap-api-studio-apikit.png) Figure 10. Package Explorer とキャンバスセクションを含む Anypoint Studio UI 内の SOAP API。 この図で示されている 4 つの項目は次を示しています。 1. Studio の Package Explorer に含まれるプロジェクトファイル。​`example.wsdl`​ ファイルは ​`src/main/resources/api`​ フォルダーの下にあります。 2. SOAP Router を含むメインフロー。 3. SOAP エラー応答テンプレート 4. SOAP メッセージテンプレートを含む、生成されたバックエンドフロー。 APIkit プロジェクトを作成したら、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#新しい-apikit-プロジェクトを開始)新しい APIkit プロジェクトを開始 API 仕様ファイルなしで APIkit プロジェクトを開始し、後で API 仕様ファイルをプロジェクトに追加できる場合、この方法を使用します。APIkit は骨格 RAML ファイルと XML 設定ファイルを生成します。 1. **\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ に、プロジェクトの名前 (​**「myproject」**​など) を入力します。 3. デフォルトの EE。ランタイム (​**Mule Server 4.2.0 EE**​ など) を選択するか受け入れます。 4. **\[API Implementation (API 実装)\]**​ で、​**\[Specify API Definition File Location or URL (API 定義ファイルの場所または URL を指定)\]**​ を選択​_しない_​でください。 これにより、バックエンドファーストの APIkit 設計が作成されます。 5. その他のデフォルトのオプションを受け入れて ​**\[Finish (完了)\]**​ をクリックします。 ![API 仕様のない新しい Mule プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-start-apikit-project-2.png) Figure 11. \[New Mule Project (新規 Mule プロジェクト)\] ウィンドウ。 この方法を使用すると、APIkit スキャフォールディングによって、次のコンポーネントを含む骨格 RAML ファイルおよび XML 設定ファイルが生成されます。 - メインフロー ​`` - メインフローの HTTP Listener 設定 - APIkit Router コンポーネント - エラーハンドラー 後で API 仕様をバックエンドファーストの APIkit 設計に追加し、バックエンドフローを生成して、アプリケーションのビルドを続行できます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ### [](#バックエンドフローを生成して新規-apikit-プロジェクトを開始)バックエンドフローを生成して新規 APIkit プロジェクトを開始 このタスクを実行するには、次の前提条件を満たしている必要があります。 - Studio (RAML エディター) で RAML ファイルを作成した - HTTP Listener および APIkit Router コンポーネントを含むメインフローを作成した Studio で RAML ファイルを作成するときに、バックエンドフローの生成は省略可能です。RAML ベースの API ではエラー処理が自動的に生成されます。APIkit プロジェクトを開始するには、バックエンドフローをメインフローから生成する必要があります。次の手順に従います。 1. Package Explorer で、プロジェクト名を右クリックします。 2. **\[Mule\] > \[Generate Flows From REST API (REST API からフローを生成)\]**​ を選択します。 ![Mule プロジェクトからバックエンドフローを生成するオプションが表示されている \[Package Explorer\] ビュー](_images/mruntime-start-apikit-project-3.png) Figure 12. Mule プロジェクトからのバックエンドフローの生成。 APIkit スキャフォールディング手法によってバックエンドフローがメインフローの後に生成されます。次に、API をテストするコールを実行し、実装を最終処理することで、アプリケーションのビルドを続行することができます。詳細は、​[\[Build Applications Workflows\]](<#Build Applications Workflows>)​を参照してください。 ## [](#アプリケーションワークフローのビルド)アプリケーションワークフローのビルド APIkit の基本構造とスキャフォールディング手法を理解したら、次のワークフローを参考にして、APIkit プロジェクトの作成、Mule フローの生成、API へのコールの実行、および実装の最終処理を行って、目的のアプリケーションをビルドします。 - [REST 用の APIKit を使用した REST API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-rest) - [SOAP 用の APIKit を使用した SOAP API のビルド](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-for-soap) さらに次のことができます。 - [既存の Mule プロジェクトの APIkit プロジェクトへの変換](https://docs.mulesoft.com/jp/apikit/latest/apikit-workflow-convert-existing) 既存の APIkit バックエンドファーストの設計への API 仕様の追加、API 定義ファイルの定義、メインフローの作成、バックエンド REST API フローの生成、アクションへの RAML リソースのマップを行います。 - [APIkit 4.x タスクの実行](https://docs.mulesoft.com/jp/apikit/latest/key-configurations) APIkit プロジェクトの変更、API Console のカスタマイズ、ヘッダーの設定、RAML ファイルの取得、機能以外の要件の実行、ロードバランサーの設定を行います。 - [APIkit OData 拡張を使用した OData 対応 API の作成](https://docs.mulesoft.com/jp/apikit/latest/creating-an-odatav4-api-with-apikit) OData 要求を処理する Mule フローを生成します。 - [Maven を使用した APIkit プロジェクトの作成](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-scaffolding-reference) 既存の Apache Maven プロジェクトに APIkit コンポーネントを追加します。 ## [](#api-からのデータのコンシューム)API からのデータのコンシューム アプリケーションをビルドしたら、API からのデータのコンシュームを開始できます。ガイドラインについては、​[「API からのデータのコンシューム」のドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.9/consume-data-from-an-api)​を参照してください。 ## [](#関連情報)関連情報 - [APIkit](https://docs.mulesoft.com/jp/apikit/latest/) - [APIKit エラー処理](https://docs.mulesoft.com/jp/apikit/latest/apikit-error-handling-reference) # APIkit ベースのアプリケーションの移行 この例は、APIkit ベースのアプリケーションを Mule 3 から Mule 4 へ移行するために必要な手順を示しています。次の REST API は、MySQL データベースで CRUD (create、read、update、delete) 操作を実行します。 ![Studio 6 の api-main](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-main.png) ![Studio 6 の api-console](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-console.png) ![Studio 6 の get:/product:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-get-products.png) ![Studio 6 の get:/product/{id}:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-get-product-id.png) ![Studio 6 の post:/product:application/json:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-post-product.png) ![Studio 6 の delete:/product/{id}:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-delete-product.png) ![Studio 6 の put:/product/{id}:application/json:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-put-product.png) ![Studio 6 の api-apiKitGlobalExceptionMapping フロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-globalexceptionmapping.png) ## [](#プロパティプレースホルダーの移行)プロパティプレースホルダーの移行 Mule 4 では、プロパティプレースホルダーは ​`.yaml`​ または ​`.properties`​ 設定ファイルのいずれかとしてサポートされています。 1. `/src/main/resources`​ プロジェクトディレクトリに ​`config`​ という名前のフォルダーを作成します。 2. 新しく作成した config フォルダー内に ​`configuration.yaml`​ という名前の設定ファイルを作成します。 3. プロパティプレースホルダーを ​`.properties`​ 形式から ​`.yaml`​ 形式に移行します。 configuration.properties http.host=0.0.0.0 http.port=8081 mysql.password=pa$$w0rd mysql.port=3306 mysql.user=admin mysql.database=products mysql.host=corp.services.com autodiscovery.api.version=1.0.0:1762946 autodiscovery.api.name=groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database anypoint.platform.client\_id=1f702j71hu9z2x88v9vd19v7h248s589 anypoint.platform.client\_secret=87v8V47668701Dd574B0531255d6287d configuration.yaml http: host: "0.0.0.0" port: "8081" mysql: password: "pa$$w0rd" port: "3306" user: "admin" database: "products" host: "corp.services.com" autodiscovery: api: name: "groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database" version: "1.0.0:1762946" anypoint: platform: client\_id: "1f702j71hu9z2x88v9vd19v7h248s589" client\_secret: "87v8V47668701Dd574B0531255d6287d" 4. 標準の Spring 要素 ​``​ を新しいグローバル要素 ​`configuration-properties`​ に置き換えます。 Studio 6 のプロパティプレースホルダーの設定 XML。 ```xml ``` `file`​ 属性は、​`/src/main/resources/config`​ フォルダーにある YAML 形式の新しい設定ファイルを参照しています。 Studio 7 のプロパティプレースホルダーの設定 XML。 ```xml ``` ## [](#グローバル-http-リスナー設定の移行)グローバル HTTP リスナー設定の移行 Studio 6 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` 最小限の設定では、内側の ​`http:listener-connection`​ 要素で ​`host`​ と ​`port`​ を指定する必要があります。前のステップで定義したプレースホルダーを使用します。 Studio 7 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` ## [](#mysql-グローバル設定の移行)MySQL グローバル設定の移行 Database Connector により、Mule アプリケーションで使用する ​_Derby_​、​_MySQL_​、​_Oracle_​ データベースのセットアップが容易になります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Database Connector`​\] を選択します。 2. \[​`Database Config`​ (データベース設定)\] グローバル設定要素を追加します。 3. \[Database Config (データベース設定)\] > \[Connection (接続)\] で、\[MySQL Connection (MySQL 接続)\] を選択します。 4. \[MySQL JDBC Driver (MySQL JDBC ドライバー)\] で \[Add Dependency (連動関係を追加)\] をクリックし、ドライバーの Maven 情報を設定します。 mysql mysql-connector-java 5.1.6 5. 前に定義したプレースホルダーを使用して、​`host`​、​`port`​、​`user`​、​`password`​、​`database`​ を含む MySQL グローバル設定を完了します。 Studio 6 の MySQL グローバル設定の設定 XML。 ```xml ``` Studio 7 の MySQL グローバル設定の設定 XML。 ```xml ``` ## [](#api-自動検出設定の移行)API 自動検出設定の移行 Anypoint Platform で API を登録するには ​`api-platform-gw`​ グローバル要素が必要です。 Studio 6 の API 自動検出設定の設定 XML。 ```xml ``` Mule Runtime 4.x では、​`apiName`​、​`version`​、​`create`​ 属性が削除されました。必要なのは ​`apiId`​ 属性と ​`flowRef`​ 属性のみです。 API Manager によって ​`apiId`​ が生成され、API インスタンスダッシュボードに表示されます。 Mule Runtime 4.x の API 自動検出設定の場合は、次のようになります。 1. 以下の名前空間をスキーマの ​`global.xml`​ 設定ファイルに追加します。 xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway" http://www.mulesoft.org/schema/mule/api-gateway http://www.mulesoft.org/schema/mule/api-gateway/current/mule-api-gateway.xsd 2. 必要な自動検出連動関係情報をプロジェクトの ​`pom.xml`​ ファイルに追加します。 com.mulesoft.anypoint mule-module-autodiscovery 4.0.0 Studio 7 の API 自動検出設定の設定 XML。 ```xml ``` ## [](#グローバル検証設定の移行)グローバル検証設定の移行 Studio 6 のグローバル検証設定の設定 XML。 ```xml ``` Mule Runtime 3.x とは逆に、設定を行うには、\[Mule Palette (Mule パレット)\] に Validation Module を追加する必要があります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Validation Module`​\] を選択します。 2. \[​`Validation Config`​ (データベース設定)\] グローバル設定要素を追加します。 Studio 7 のグローバル検証設定の設定 XML。 ```xml ``` ## [](#get-products-flow-の移行)_get-products-flow_​ の移行 `get-products-flow`​ は ​`Product Category`​ または ​`Product Name`​ あるいはその両方で絞り込み、データベースから商品を返します。また ​`offset`​ および ​`maxResults`​ パラメーターを使用するページ分割クエリもサポートされています。 ![Studio 6 の get-products-flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-get-products-flow.png) Figure 1. Studio 6 の get-products-flow Studio 6 の get-products-flow の設定 XML。 ```xml ``` 1. `get-products-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources`​ フォルダーに ​`variables`​ という名前のパッケージを作成します。 3. `src/main/resources/variables`​ フォルダーに ​`set-queryCategory-variable.dwl`​ ファイルを作成し、​`queryCategory`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryCategory = attributes.queryParams.category --- if (queryCategory != null) queryCategory else '%%' 4. `src/main/resources/variables`​ フォルダーに ​`set-queryLimit-variable.dwl`​ ファイルを作成し、​`queryLimit`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.maxResults as Number 5. `src/main/resources/variables`​ フォルダーに ​`set-queryName-variable.dwl`​ ファイルを作成し、​`queryName`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryName = attributes.queryParams.name --- if (queryName != null) queryName else '%%' 6. `src/main/resources/variables`​ フォルダーに ​`set-queryOffset-variable.dwl`​ ファイルを作成し、​`queryOffset`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.offset as Number 7. `Transform component`​ を追加し、​`message-properties-transformer`​ の内側のロジックを置き換えて、その DW スクリプトを参照する変数 ​`queryOffset`​、​`queryLimit`​、​`queryName`​、​`queryCategory`​ を設定します。 ```xml ``` 8. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` 9. `src/main/resources`​ フォルダーに ​`mappings`​ という名前のパッケージを作成します。 10. `src/main/resources/mappings`​ フォルダーに ​`get-products-response.dwl`​ ファイルを作成します。 11. `get-products-response.dwl`​ DW 1.0 スクリプトを DW 2.0 に移行します。 DW 1.0 の get-products-response の変換。 %dw 1.0 %output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as :string {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as :string {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as :number, stock: $.stock as :number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } DW 2.0 の get-products-response の変換。 %dw 2.0 output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as String {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as String {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as Number, stock: $.stock as Number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } 12. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-products-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` ![Studio 7 の get-products-flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m4-apikit-based-example-get-products-flow.png) Figure 2. Studio 7 の get-products-flow ## [](#get-product-by-id-flow-の移行)_get-product-by-id-flow_​ の移行 `get-product-by-id-flow`​ は、​`id`​ で絞り込んでデータベースから商品を返します。 必要な ID を持つ商品がない場合は、​`HTTP 404 Not Found`​ エラーが返されます。 ![Studio 6 の get-product-by-id-flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-get-product-by-id-flow.png) Figure 3. Studio 6 の get-product-by-id-flow Studio 6 の get-product-by-id-flow の設定 XML。 ```xml ``` 1. `get-product-by-id-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/variables`​ フォルダーに ​`set-productId-variable.dwl`​ ファイルを作成します。​`uriParams`​ から ​`id`​ を取得する次のロジックを追加します。 %dw 2.0 output application/java --- attributes.uriParams.id 3. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 4. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` 5. `db:select`​ の後に、クエリから結果が返されたかどうかをチェックする ​`validation:is-true`​ 要素を追加します。返されなかった場合は ​`APP:NOT_FOUND`​ エラーをスローします。デフォルトの式言語として ​`MEL`​ が ​`DataWeave`​ に置き換わり、​`[payload.size() > 0]`​ は ​`[sizeOf(payload) > 0]`​ として書き換えられています。 ```xml ``` 6. `src/main/resources/mappings`​ フォルダーに ​`get-product-by-id-response.dwl`​ ファイルを作成し、JSON 応答を構築する DataWeave スクリプトを 1.0 から 2.0 に移行します。 DW 1.0 の get-product-by-id-response の変換。 %dw 1.0 %output application/json %var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as :string {format: "##.##"} as :number, listPrice: (product.list\_price default "0.0") as :string {format: "##.##"} as :number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as :date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as :date {format: "yyyy-MM-dd"} } DW 2.0 の get-product-by-id-response.dwl の変換。 %dw 2.0 output application/json var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as String {format: "##.##"} as Number, listPrice: (product.list\_price default "0.0") as String {format: "##.##"} as Number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as Date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as Date {format: "yyyy-MM-dd"} } 7. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-product-by-id-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` ![Studio 7 の get-product-by-id-flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m4-apikit-based-example-get-product-by-id-flow.png) Figure 4. Studio 7 の get-product-by-id-flow ## [](#post-product-flow-の移行)_post-product-flow_​ の移行 `post-product-flow`​ はデータベースに商品を挿入します。 ![Studio 6 の post-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-post-product-flow.png) Figure 5. Studio 6 の post-product-flow Studio 6 の post-product-flow の設定 XML。 ```xml ``` 1. `post-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. JSON 要求を JAVA マップに変換するために、​`src/main/resources/mappings`​ フォルダーに ​`json-to-java.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- payload 3. `src/main/resources/mappings`​ に ​`json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, (manufactured: 1) when payload.manufactured == true, (manufactured: 0) when payload.manufactured == false, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の json-product-to-java.dwl の変換。 %dw 2.0 output application/java fun getManufacturedCode(value) = if (value == true) 1 else 0 --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: getManufacturedCode(payload.manufactured), name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 4. 前に作成した DataWeave 変換を使用して ​`originalPayload`​ と ​`newPayload`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 5. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 6. `Try scope`​ に ​`db:insert`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。データベースエンジンによって自動生成された ​`ID`​ を持つペイロードを設定する ​`db:auto-generated-keys-column-name`​ タグも含まれています。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` 7. `src/main/resources/mappings`​ に ​`post-product-response.dwl`​ ファイルを作成し、応答変換を DataWeave 1.0 から 2.0 に移行します。式 ​`payload.generatedKeys.GENERATED_KEY`​ を使用してペイロードから生成された ​`id`​ を取得するという違いがあります。 DW 1.0 の post-product-response.dwl の変換。 %dw 1.0 %output application/json --- flowVars.originalPayload ++ id: payload\[0\].GENERATED\_KEY DW 2.0 の post-product-response.dwl の変換。 %dw 2.0 output application/json --- vars.originalPayload ++ id: payload.generatedKeys.GENERATED\_KEY 8. `Transform component`​ を追加し、ペイロードを DataWeave スクリプトで設定します。 ```xml ``` Studio 7 の post-product-flow の設定 XML。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` ![Studio 7 の post-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m4-apikit-based-example-post-product-flow.png) Figure 6. Studio 7 の post-product-flow ## [](#put-product-flow-の移行)_put-product-flow_​ の移行 `put-product-flow`​ は指定された ​`id`​ に基づいてデータベース内の商品を更新します。 ![Studio 6 の put-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-put-product-flow.png) Figure 7. Studio 6 の put-product-flow Studio 6 の put-product-flow の設定 XML。 ```xml ``` 1. `put-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/mappings`​ フォルダーに ​`put-json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の put-json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の put-json-product-to-java.dwl の変換。 %dw 2.0 output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 3. 前に作成した DataWeave 変換を使用する ​`updatePayload`​ と、​`variables/set-productId-variable.dwl`​ スクリプトを使用する ​`id`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 4. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 5. `Try scope`​ に ​`db:update`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` 6. `Transform component`​ を追加し、​`src/main/resources/variables`​ にある ​`set-httpStatus-with-204.dwl`​ ファイルを使用して ​`httpStatus`​ 変数に ​`204`​ を設定します。 ```xml ``` Studio 7 の put-product-flow の設定 XML。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` ![Studio 7 の put-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m4-apikit-based-example-put-product-flow.png) Figure 8. Studio 7 の put-product-flow ## [](#delete-product-flow-の移行)_delete-product-flow_​ の移行 `delete-product-flow`​ は ​`URI parameter`​ として指定された ​`id`​ を持つ商品レコードを MySQL データベースから削除し、HTTP 204 状況コードを返します。 ![Studio 6 の delete-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m3-apikit-based-example-delete-product-flow.png) Figure 9. Studio 6 の delete-product-flow Studio 6 の delete-product-flow の設定 XML。 ```xml ``` 1. `delete-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 3. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 4. `Try scope`​ に ​`db:delete`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。Mule 3.x とは逆に、前に定義した ​`productId`​ フロー変数には、​`flowVars.productId`​ ではなく ​`vars.productId`​ としてアクセスする必要があります。 ```xml delete from product where id=:productId ``` 5. 次のように ​`src/main/resources/variables`​ に ​`set-httpStatus-with-204.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- 204 6. `NO CONTENT`​ 応答コードを定義するために、​`Transform Component`​ を使用して値 ​`204`​ を持つ ​`httpStatus`​ 変数を設定します。 ```xml ``` 特定の HTTP 状況コードを返すには、​`http.status`​ プロパティを設定する代わりに、Mule 4 の APIkit で ​`httpStatus`​ という名前の変数を設定する必要があります。 Studio 7 の delete-product-flow の設定 XML。 ```xml delete from product where id=:productId ``` ![Studio 7 の delete-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/m4-apikit-based-example-delete-product-flow.png) Figure 10. Studio 7 の delete-product-flow ## [](#バックエンドフローの移行)バックエンドフローの移行 バックエンドフローの移行方法 APIkit によって生成された各バックエンドフローの実装に ​`flow-ref`​ を追加します。 \+ .Studio 6 のバックエンドフローの設定 XML。 ```xml ``` + \+ .Studio 7 のバックエンドフローの設定 XML。 ```xml ``` ## [](#デフォルトの-apikit-グローバル例外戦略の拡張)デフォルトの APIkit グローバル例外戦略の拡張 1. `APP:NOT_FOUND`​ 例外種別を ApiKit で生成された 404 マッピングに追加し、​`get-product-by-id-flow`​ の ​`validation:is-true`​ 要素によってスローされた例外を処理します。特定の状況コードにマップするその他のエラーに対してこのプロセスを繰り返すことができます。 Studio 6 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` Studio 7 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` 2. まだ管理されていないすべての例外に、汎用の ApiKit による 500 へのマッピングを追加します。 Studio 6 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` Studio 7 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` # APIkit ベースのアプリケーションの移行 この例は、APIkit ベースのアプリケーションを Mule 3 から Mule 4 へ移行するために必要な手順を示しています。次の REST API は、MySQL データベースで CRUD (create、read、update、delete) 操作を実行します。 ![Studio 6 の api-main](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-main.png) ![Studio 6 の api-console](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-console.png) ![Studio 6 の get:/product:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-get-products.png) ![Studio 6 の get:/product/{id}:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-get-product-id.png) ![Studio 6 の post:/product:application/json:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-post-product.png) ![Studio 6 の delete:/product/{id}:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-delete-product.png) ![Studio 6 の put:/product/{id}:application/json:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-put-product.png) ![Studio 6 の api-apiKitGlobalExceptionMapping フロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-globalexceptionmapping.png) ## [](#プロパティプレースホルダーの移行)プロパティプレースホルダーの移行 Mule 4 では、プロパティプレースホルダーは ​`.yaml`​ または ​`.properties`​ 設定ファイルのいずれかとしてサポートされています。 1. `/src/main/resources`​ プロジェクトディレクトリに ​`config`​ という名前のフォルダーを作成します。 2. 新しく作成した config フォルダー内に ​`configuration.yaml`​ という名前の設定ファイルを作成します。 3. プロパティプレースホルダーを ​`.properties`​ 形式から ​`.yaml`​ 形式に移行します。 configuration.properties http.host=0.0.0.0 http.port=8081 mysql.password=pa$$w0rd mysql.port=3306 mysql.user=admin mysql.database=products mysql.host=corp.services.com autodiscovery.api.version=1.0.0:1762946 autodiscovery.api.name=groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database anypoint.platform.client\_id=1f702j71hu9z2x88v9vd19v7h248s589 anypoint.platform.client\_secret=87v8V47668701Dd574B0531255d6287d configuration.yaml http: host: "0.0.0.0" port: "8081" mysql: password: "pa$$w0rd" port: "3306" user: "admin" database: "products" host: "corp.services.com" autodiscovery: api: name: "groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database" version: "1.0.0:1762946" anypoint: platform: client\_id: "1f702j71hu9z2x88v9vd19v7h248s589" client\_secret: "87v8V47668701Dd574B0531255d6287d" 4. 標準の Spring 要素 ​``​ を新しいグローバル要素 ​`configuration-properties`​ に置き換えます。 Studio 6 のプロパティプレースホルダーの設定 XML。 ```xml ``` `file`​ 属性は、​`/src/main/resources/config`​ フォルダーにある YAML 形式の新しい設定ファイルを参照しています。 Studio 7 のプロパティプレースホルダーの設定 XML。 ```xml ``` ## [](#グローバル-http-リスナー設定の移行)グローバル HTTP リスナー設定の移行 Studio 6 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` 最小限の設定では、内側の ​`http:listener-connection`​ 要素で ​`host`​ と ​`port`​ を指定する必要があります。前のステップで定義したプレースホルダーを使用します。 Studio 7 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` ## [](#mysql-グローバル設定の移行)MySQL グローバル設定の移行 Database Connector により、Mule アプリケーションで使用する ​_Derby_​、​_MySQL_​、​_Oracle_​ データベースのセットアップが容易になります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Database Connector`​\] を選択します。 2. \[​`Database Config`​ (データベース設定)\] グローバル設定要素を追加します。 3. \[Database Config (データベース設定)\] > \[Connection (接続)\] で、\[MySQL Connection (MySQL 接続)\] を選択します。 4. \[MySQL JDBC Driver (MySQL JDBC ドライバー)\] で \[Add Dependency (連動関係を追加)\] をクリックし、ドライバーの Maven 情報を設定します。 mysql mysql-connector-java 5.1.6 5. 前に定義したプレースホルダーを使用して、​`host`​、​`port`​、​`user`​、​`password`​、​`database`​ を含む MySQL グローバル設定を完了します。 Studio 6 の MySQL グローバル設定の設定 XML。 ```xml ``` Studio 7 の MySQL グローバル設定の設定 XML。 ```xml ``` ## [](#api-自動検出設定の移行)API 自動検出設定の移行 Anypoint Platform で API を登録するには ​`api-platform-gw`​ グローバル要素が必要です。 Studio 6 の API 自動検出設定の設定 XML。 ```xml ``` Mule Runtime 4.x では、​`apiName`​、​`version`​、​`create`​ 属性が削除されました。必要なのは ​`apiId`​ 属性と ​`flowRef`​ 属性のみです。 API Manager によって ​`apiId`​ が生成され、API インスタンスダッシュボードに表示されます。 Mule Runtime 4.x の API 自動検出設定の場合は、次のようになります。 1. 以下の名前空間をスキーマの ​`global.xml`​ 設定ファイルに追加します。 xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway" http://www.mulesoft.org/schema/mule/api-gateway http://www.mulesoft.org/schema/mule/api-gateway/current/mule-api-gateway.xsd 2. 必要な自動検出連動関係情報をプロジェクトの ​`pom.xml`​ ファイルに追加します。 com.mulesoft.anypoint mule-module-autodiscovery 4.0.0 Studio 7 の API 自動検出設定の設定 XML。 ```xml ``` ## [](#グローバル検証設定の移行)グローバル検証設定の移行 Studio 6 のグローバル検証設定の設定 XML。 ```xml ``` Mule Runtime 3.x とは逆に、設定を行うには、\[Mule Palette (Mule パレット)\] に Validation Module を追加する必要があります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Validation Module`​\] を選択します。 2. \[​`Validation Config`​ (データベース設定)\] グローバル設定要素を追加します。 Studio 7 のグローバル検証設定の設定 XML。 ```xml ``` ## [](#get-products-flow-の移行)_get-products-flow_​ の移行 `get-products-flow`​ は ​`Product Category`​ または ​`Product Name`​ あるいはその両方で絞り込み、データベースから商品を返します。また ​`offset`​ および ​`maxResults`​ パラメーターを使用するページ分割クエリもサポートされています。 ![Studio 6 の get-products-flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-get-products-flow.png) Figure 1. Studio 6 の get-products-flow Studio 6 の get-products-flow の設定 XML。 ```xml ``` 1. `get-products-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources`​ フォルダーに ​`variables`​ という名前のパッケージを作成します。 3. `src/main/resources/variables`​ フォルダーに ​`set-queryCategory-variable.dwl`​ ファイルを作成し、​`queryCategory`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryCategory = attributes.queryParams.category --- if (queryCategory != null) queryCategory else '%%' 4. `src/main/resources/variables`​ フォルダーに ​`set-queryLimit-variable.dwl`​ ファイルを作成し、​`queryLimit`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.maxResults as Number 5. `src/main/resources/variables`​ フォルダーに ​`set-queryName-variable.dwl`​ ファイルを作成し、​`queryName`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryName = attributes.queryParams.name --- if (queryName != null) queryName else '%%' 6. `src/main/resources/variables`​ フォルダーに ​`set-queryOffset-variable.dwl`​ ファイルを作成し、​`queryOffset`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.offset as Number 7. `Transform component`​ を追加し、​`message-properties-transformer`​ の内側のロジックを置き換えて、その DW スクリプトを参照する変数 ​`queryOffset`​、​`queryLimit`​、​`queryName`​、​`queryCategory`​ を設定します。 ```xml ``` 8. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` 9. `src/main/resources`​ フォルダーに ​`mappings`​ という名前のパッケージを作成します。 10. `src/main/resources/mappings`​ フォルダーに ​`get-products-response.dwl`​ ファイルを作成します。 11. `get-products-response.dwl`​ DW 1.0 スクリプトを DW 2.0 に移行します。 DW 1.0 の get-products-response の変換。 %dw 1.0 %output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as :string {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as :string {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as :number, stock: $.stock as :number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } DW 2.0 の get-products-response の変換。 %dw 2.0 output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as String {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as String {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as Number, stock: $.stock as Number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } 12. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-products-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` ![Studio 7 の get-products-flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m4-apikit-based-example-get-products-flow.png) Figure 2. Studio 7 の get-products-flow ## [](#get-product-by-id-flow-の移行)_get-product-by-id-flow_​ の移行 `get-product-by-id-flow`​ は、​`id`​ で絞り込んでデータベースから商品を返します。 必要な ID を持つ商品がない場合は、​`HTTP 404 Not Found`​ エラーが返されます。 ![Studio 6 の get-product-by-id-flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-get-product-by-id-flow.png) Figure 3. Studio 6 の get-product-by-id-flow Studio 6 の get-product-by-id-flow の設定 XML。 ```xml ``` 1. `get-product-by-id-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/variables`​ フォルダーに ​`set-productId-variable.dwl`​ ファイルを作成します。​`uriParams`​ から ​`id`​ を取得する次のロジックを追加します。 %dw 2.0 output application/java --- attributes.uriParams.id 3. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 4. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` 5. `db:select`​ の後に、クエリから結果が返されたかどうかをチェックする ​`validation:is-true`​ 要素を追加します。返されなかった場合は ​`APP:NOT_FOUND`​ エラーをスローします。デフォルトの式言語として ​`MEL`​ が ​`DataWeave`​ に置き換わり、​`[payload.size() > 0]`​ は ​`[sizeOf(payload) > 0]`​ として書き換えられています。 ```xml ``` 6. `src/main/resources/mappings`​ フォルダーに ​`get-product-by-id-response.dwl`​ ファイルを作成し、JSON 応答を構築する DataWeave スクリプトを 1.0 から 2.0 に移行します。 DW 1.0 の get-product-by-id-response の変換。 %dw 1.0 %output application/json %var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as :string {format: "##.##"} as :number, listPrice: (product.list\_price default "0.0") as :string {format: "##.##"} as :number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as :date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as :date {format: "yyyy-MM-dd"} } DW 2.0 の get-product-by-id-response.dwl の変換。 %dw 2.0 output application/json var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as String {format: "##.##"} as Number, listPrice: (product.list\_price default "0.0") as String {format: "##.##"} as Number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as Date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as Date {format: "yyyy-MM-dd"} } 7. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-product-by-id-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` ![Studio 7 の get-product-by-id-flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m4-apikit-based-example-get-product-by-id-flow.png) Figure 4. Studio 7 の get-product-by-id-flow ## [](#post-product-flow-の移行)_post-product-flow_​ の移行 `post-product-flow`​ はデータベースに商品を挿入します。 ![Studio 6 の post-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-post-product-flow.png) Figure 5. Studio 6 の post-product-flow Studio 6 の post-product-flow の設定 XML。 ```xml ``` 1. `post-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. JSON 要求を JAVA マップに変換するために、​`src/main/resources/mappings`​ フォルダーに ​`json-to-java.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- payload 3. `src/main/resources/mappings`​ に ​`json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, (manufactured: 1) when payload.manufactured == true, (manufactured: 0) when payload.manufactured == false, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の json-product-to-java.dwl の変換。 %dw 2.0 output application/java fun getManufacturedCode(value) = if (value == true) 1 else 0 --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: getManufacturedCode(payload.manufactured), name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 4. 前に作成した DataWeave 変換を使用して ​`originalPayload`​ と ​`newPayload`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 5. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 6. `Try scope`​ に ​`db:insert`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。データベースエンジンによって自動生成された ​`ID`​ を持つペイロードを設定する ​`db:auto-generated-keys-column-name`​ タグも含まれています。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` 7. `src/main/resources/mappings`​ に ​`post-product-response.dwl`​ ファイルを作成し、応答変換を DataWeave 1.0 から 2.0 に移行します。式 ​`payload.generatedKeys.GENERATED_KEY`​ を使用してペイロードから生成された ​`id`​ を取得するという違いがあります。 DW 1.0 の post-product-response.dwl の変換。 %dw 1.0 %output application/json --- flowVars.originalPayload ++ id: payload\[0\].GENERATED\_KEY DW 2.0 の post-product-response.dwl の変換。 %dw 2.0 output application/json --- vars.originalPayload ++ id: payload.generatedKeys.GENERATED\_KEY 8. `Transform component`​ を追加し、ペイロードを DataWeave スクリプトで設定します。 ```xml ``` Studio 7 の post-product-flow の設定 XML。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` ![Studio 7 の post-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m4-apikit-based-example-post-product-flow.png) Figure 6. Studio 7 の post-product-flow ## [](#put-product-flow-の移行)_put-product-flow_​ の移行 `put-product-flow`​ は指定された ​`id`​ に基づいてデータベース内の商品を更新します。 ![Studio 6 の put-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-put-product-flow.png) Figure 7. Studio 6 の put-product-flow Studio 6 の put-product-flow の設定 XML。 ```xml ``` 1. `put-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/mappings`​ フォルダーに ​`put-json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の put-json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の put-json-product-to-java.dwl の変換。 %dw 2.0 output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 3. 前に作成した DataWeave 変換を使用する ​`updatePayload`​ と、​`variables/set-productId-variable.dwl`​ スクリプトを使用する ​`id`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 4. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 5. `Try scope`​ に ​`db:update`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` 6. `Transform component`​ を追加し、​`src/main/resources/variables`​ にある ​`set-httpStatus-with-204.dwl`​ ファイルを使用して ​`httpStatus`​ 変数に ​`204`​ を設定します。 ```xml ``` Studio 7 の put-product-flow の設定 XML。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` ![Studio 7 の put-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m4-apikit-based-example-put-product-flow.png) Figure 8. Studio 7 の put-product-flow ## [](#delete-product-flow-の移行)_delete-product-flow_​ の移行 `delete-product-flow`​ は ​`URI parameter`​ として指定された ​`id`​ を持つ商品レコードを MySQL データベースから削除し、HTTP 204 状況コードを返します。 ![Studio 6 の delete-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m3-apikit-based-example-delete-product-flow.png) Figure 9. Studio 6 の delete-product-flow Studio 6 の delete-product-flow の設定 XML。 ```xml ``` 1. `delete-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 3. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 4. `Try scope`​ に ​`db:delete`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。Mule 3.x とは逆に、前に定義した ​`productId`​ フロー変数には、​`flowVars.productId`​ ではなく ​`vars.productId`​ としてアクセスする必要があります。 ```xml delete from product where id=:productId ``` 5. 次のように ​`src/main/resources/variables`​ に ​`set-httpStatus-with-204.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- 204 6. `NO CONTENT`​ 応答コードを定義するために、​`Transform Component`​ を使用して値 ​`204`​ を持つ ​`httpStatus`​ 変数を設定します。 ```xml ``` 特定の HTTP 状況コードを返すには、​`http.status`​ プロパティを設定する代わりに、Mule 4 の APIkit で ​`httpStatus`​ という名前の変数を設定する必要があります。 Studio 7 の delete-product-flow の設定 XML。 ```xml delete from product where id=:productId ``` ![Studio 7 の delete-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/m4-apikit-based-example-delete-product-flow.png) Figure 10. Studio 7 の delete-product-flow ## [](#バックエンドフローの移行)バックエンドフローの移行 バックエンドフローの移行方法 APIkit によって生成された各バックエンドフローの実装に ​`flow-ref`​ を追加します。 \+ .Studio 6 のバックエンドフローの設定 XML。 ```xml ``` + \+ .Studio 7 のバックエンドフローの設定 XML。 ```xml ``` ## [](#デフォルトの-apikit-グローバル例外戦略の拡張)デフォルトの APIkit グローバル例外戦略の拡張 1. `APP:NOT_FOUND`​ 例外種別を ApiKit で生成された 404 マッピングに追加し、​`get-product-by-id-flow`​ の ​`validation:is-true`​ 要素によってスローされた例外を処理します。特定の状況コードにマップするその他のエラーに対してこのプロセスを繰り返すことができます。 Studio 6 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` Studio 7 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` 2. まだ管理されていないすべての例外に、汎用の ApiKit による 500 へのマッピングを追加します。 Studio 6 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` Studio 7 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` # APIkit ベースのアプリケーションの移行 この例は、APIkit ベースのアプリケーションを Mule 3 から Mule 4 へ移行するために必要な手順を示しています。次の REST API は、MySQL データベースで CRUD (create、read、update、delete) 操作を実行します。 ![Studio 6 の api-main](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-main.png) ![Studio 6 の api-console](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-console.png) ![Studio 6 の get:/product:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-get-products.png) ![Studio 6 の get:/product/{id}:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-get-product-id.png) ![Studio 6 の post:/product:application/json:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-post-product.png) ![Studio 6 の delete:/product/{id}:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-delete-product.png) ![Studio 6 の put:/product/{id}:application/json:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-put-product.png) ![Studio 6 の api-apiKitGlobalExceptionMapping フロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-globalexceptionmapping.png) ## [](#プロパティプレースホルダーの移行)プロパティプレースホルダーの移行 Mule 4 では、プロパティプレースホルダーは ​`.yaml`​ または ​`.properties`​ 設定ファイルのいずれかとしてサポートされています。 1. `/src/main/resources`​ プロジェクトディレクトリに ​`config`​ という名前のフォルダーを作成します。 2. 新しく作成した config フォルダー内に ​`configuration.yaml`​ という名前の設定ファイルを作成します。 3. プロパティプレースホルダーを ​`.properties`​ 形式から ​`.yaml`​ 形式に移行します。 configuration.properties http.host=0.0.0.0 http.port=8081 mysql.password=pa$$w0rd mysql.port=3306 mysql.user=admin mysql.database=products mysql.host=corp.services.com autodiscovery.api.version=1.0.0:1762946 autodiscovery.api.name=groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database anypoint.platform.client\_id=1f702j71hu9z2x88v9vd19v7h248s589 anypoint.platform.client\_secret=87v8V47668701Dd574B0531255d6287d configuration.yaml http: host: "0.0.0.0" port: "8081" mysql: password: "pa$$w0rd" port: "3306" user: "admin" database: "products" host: "corp.services.com" autodiscovery: api: name: "groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database" version: "1.0.0:1762946" anypoint: platform: client\_id: "1f702j71hu9z2x88v9vd19v7h248s589" client\_secret: "87v8V47668701Dd574B0531255d6287d" 4. 標準の Spring 要素 ​``​ を新しいグローバル要素 ​`configuration-properties`​ に置き換えます。 Studio 6 のプロパティプレースホルダーの設定 XML。 ```xml ``` `file`​ 属性は、​`/src/main/resources/config`​ フォルダーにある YAML 形式の新しい設定ファイルを参照しています。 Studio 7 のプロパティプレースホルダーの設定 XML。 ```xml ``` ## [](#グローバル-http-リスナー設定の移行)グローバル HTTP リスナー設定の移行 Studio 6 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` 最小限の設定では、内側の ​`http:listener-connection`​ 要素で ​`host`​ と ​`port`​ を指定する必要があります。前のステップで定義したプレースホルダーを使用します。 Studio 7 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` ## [](#mysql-グローバル設定の移行)MySQL グローバル設定の移行 Database Connector により、Mule アプリケーションで使用する ​_Derby_​、​_MySQL_​、​_Oracle_​ データベースのセットアップが容易になります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Database Connector`​ (データベースコネクタ)\] を選択します。 2. \[​`Database Config`​ (データベース設定)\] グローバル設定要素を追加します。 3. \[Database Config (データベース設定)\] > \[Connection (接続)\] で、\[MySQL Connection (MySQL 接続)\] を選択します。 4. \[MySQL JDBC Driver (MySQL JDBC ドライバー)\] で \[Add Dependency (連動関係を追加)\] をクリックし、ドライバーの Maven 情報を設定します。 mysql mysql-connector-java 5.1.6 5. 前に定義したプレースホルダーを使用して、​`host`​、​`port`​、​`user`​、​`password`​、​`database`​ を含む MySQL グローバル設定を完了します。 Studio 6 の MySQL グローバル設定の設定 XML。 ```xml ``` Studio 7 の MySQL グローバル設定の設定 XML。 ```xml ``` ## [](#api-自動検出設定の移行)API 自動検出設定の移行 Anypoint Platform で API を登録するには ​`api-platform-gw`​ グローバル要素が必要です。 Studio 6 の API 自動検出設定の設定 XML。 ```xml ``` Mule Runtime 4.x では、​`apiName`​、​`version`​、​`create`​ 属性が削除されました。必要なのは ​`apiId`​ 属性と ​`flowRef`​ 属性のみです。 API Manager によって ​`apiId`​ が生成され、API インスタンスダッシュボードに表示されます。 Mule Runtime 4.x の API 自動検出設定の場合は、次のようになります。 1. 以下の名前空間をスキーマの ​`global.xml`​ 設定ファイルに追加します。 xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway" http://www.mulesoft.org/schema/mule/api-gateway http://www.mulesoft.org/schema/mule/api-gateway/current/mule-api-gateway.xsd 2. 必要な自動検出連動関係情報をプロジェクトの ​`pom.xml`​ ファイルに追加します。 com.mulesoft.anypoint mule-module-autodiscovery 4.0.0 Studio 7 の API 自動検出設定の設定 XML。 ```xml ``` ## [](#グローバル検証設定の移行)グローバル検証設定の移行 Studio 6 のグローバル検証設定の設定 XML。 ```xml ``` Mule Runtime 3.x とは逆に、設定を行うには、\[Mule Palette (Mule パレット)\] に Validation Module を追加する必要があります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Validation Module`​ (データベースコネクタ)\] を選択します。 2. \[​`Validation Config`​ (データベース設定)\] グローバル設定要素を追加します。 Studio 7 のグローバル検証設定の設定 XML。 ```xml ``` ## [](#get-products-flow-の移行)_get-products-flow_​ の移行 `get-products-flow`​ は ​`Product Category`​ または ​`Product Name`​ あるいはその両方で絞り込み、データベースから商品を返します。また ​`offset`​ および ​`maxResults`​ パラメーターを使用するページ分割クエリもサポートされています。 ![Studio 6 の get-products-flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-get-products-flow.png) Figure 1. Studio 6 の get-products-flow Studio 6 の get-products-flow の設定 XML。 ```xml ``` 1. `get-products-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources`​ フォルダーに ​`variables`​ という名前のパッケージを作成します。 3. `src/main/resources/variables`​ フォルダーに ​`set-queryCategory-variable.dwl`​ ファイルを作成し、​`queryCategory`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryCategory = attributes.queryParams.category --- if (queryCategory != null) queryCategory else '%%' 4. `src/main/resources/variables`​ フォルダーに ​`set-queryLimit-variable.dwl`​ ファイルを作成し、​`queryLimit`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.maxResults as Number 5. `src/main/resources/variables`​ フォルダーに ​`set-queryName-variable.dwl`​ ファイルを作成し、​`queryName`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryName = attributes.queryParams.name --- if (queryName != null) queryName else '%%' 6. `src/main/resources/variables`​ フォルダーに ​`set-queryOffset-variable.dwl`​ ファイルを作成し、​`queryOffset`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.offset as Number 7. `Transform component`​ を追加し、​`message-properties-transformer`​ の内側のロジックを置き換えて、その DW スクリプトを参照する変数 ​`queryOffset`​、​`queryLimit`​、​`queryName`​、​`queryCategory`​ を設定します。 ```xml ``` 8. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` 9. `src/main/resources`​ フォルダーに ​`mappings`​ という名前のパッケージを作成します。 10. `src/main/resources/mappings`​ フォルダーに ​`get-products-response.dwl`​ ファイルを作成します。 11. `get-products-response.dwl`​ DW 1.0 スクリプトを DW 2.0 に移行します。 DW 1.0 の get-products-response の変換。 %dw 1.0 %output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as :string {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as :string {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as :number, stock: $.stock as :number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } DW 2.0 の get-products-response の変換。 %dw 2.0 output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as String {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as String {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as Number, stock: $.stock as Number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } 12. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-products-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` ![Studio 7 の get-products-flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m4-apikit-based-example-get-products-flow.png) Figure 2. Studio 7 の get-products-flow ## [](#get-product-by-id-flow-の移行)_get-product-by-id-flow_​ の移行 `get-product-by-id-flow`​ は、​`id`​ で絞り込んでデータベースから商品を返します。 必要な ID を持つ商品がない場合は、​`HTTP 404 Not Found`​ エラーが返されます。 ![Studio 6 の get-product-by-id-flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-get-product-by-id-flow.png) Figure 3. Studio 6 の get-product-by-id-flow Studio 6 の get-product-by-id-flow の設定 XML。 ```xml ``` 1. `get-product-by-id-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/variables`​ フォルダーに ​`set-productId-variable.dwl`​ ファイルを作成します。​`uriParams`​ から ​`id`​ を取得する次のロジックを追加します。 %dw 2.0 output application/java --- attributes.uriParams.id 3. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 4. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` 5. `db:select`​ の後に、クエリから結果が返されたかどうかをチェックする ​`validation:is-true`​ 要素を追加します。返されなかった場合は ​`APP:NOT_FOUND`​ エラーをスローします。デフォルトの式言語として ​`MEL`​ が ​`DataWeave`​ に置き換わり、​`[payload.size() > 0]`​ は ​`[sizeOf(payload) > 0]`​ として書き換えられています。 ```xml ``` 6. `src/main/resources/mappings`​ フォルダーに ​`get-product-by-id-response.dwl`​ ファイルを作成し、JSON 応答を構築する DataWeave スクリプトを 1.0 から 2.0 に移行します。 DW 1.0 の get-product-by-id-response の変換。 %dw 1.0 %output application/json %var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as :string {format: "##.##"} as :number, listPrice: (product.list\_price default "0.0") as :string {format: "##.##"} as :number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as :date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as :date {format: "yyyy-MM-dd"} } DW 2.0 の get-product-by-id-response.dwl の変換。 %dw 2.0 output application/json var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as String {format: "##.##"} as Number, listPrice: (product.list\_price default "0.0") as String {format: "##.##"} as Number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as Date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as Date {format: "yyyy-MM-dd"} } 7. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-product-by-id-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` ![Studio 7 の get-product-by-id-flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m4-apikit-based-example-get-product-by-id-flow.png) Figure 4. Studio 7 の get-product-by-id-flow ## [](#post-product-flow-の移行)_post-product-flow_​ の移行 `post-product-flow`​ はデータベースに商品を挿入します。 ![Studio 6 の post-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-post-product-flow.png) Figure 5. Studio 6 の post-product-flow Studio 6 の post-product-flow の設定 XML。 ```xml ``` 1. `post-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. JSON 要求を JAVA マップに変換するために、​`src/main/resources/mappings`​ フォルダーに ​`json-to-java.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- payload 3. `src/main/resources/mappings`​ に ​`json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, (manufactured: 1) when payload.manufactured == true, (manufactured: 0) when payload.manufactured == false, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の json-product-to-java.dwl の変換。 %dw 2.0 output application/java fun getManufacturedCode(value) = if (value == true) 1 else 0 --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: getManufacturedCode(payload.manufactured), name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 4. 前に作成した DataWeave 変換を使用して ​`originalPayload`​ と ​`newPayload`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 5. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 6. `Try scope`​ に ​`db:insert`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。データベースエンジンによって自動生成された ​`ID`​ を持つペイロードを設定する ​`db:auto-generated-keys-column-name`​ タグも含まれています。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` 7. `src/main/resources/mappings`​ に ​`post-product-response.dwl`​ ファイルを作成し、応答変換を DataWeave 1.0 から 2.0 に移行します。式 ​`payload.generatedKeys.GENERATED_KEY`​ を使用してペイロードから生成された ​`id`​ を取得するという違いがあります。 DW 1.0 の post-product-response.dwl の変換。 %dw 1.0 %output application/json --- flowVars.originalPayload ++ id: payload\[0\].GENERATED\_KEY DW 2.0 の post-product-response.dwl の変換。 %dw 2.0 output application/json --- vars.originalPayload ++ id: payload.generatedKeys.GENERATED\_KEY 8. `Transform component`​ を追加し、ペイロードを DataWeave スクリプトで設定します。 ```xml ``` Studio 7 の post-product-flow の設定 XML。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` ![Studio 7 の post-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m4-apikit-based-example-post-product-flow.png) Figure 6. Studio 7 の post-product-flow ## [](#put-product-flow-の移行)_put-product-flow_​ の移行 `put-product-flow`​ は指定された ​`id`​ に基づいてデータベース内の商品を更新します。 ![Studio 6 の put-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-put-product-flow.png) Figure 7. Studio 6 の put-product-flow Studio 6 の put-product-flow の設定 XML。 ```xml ``` 1. `put-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/mappings`​ フォルダーに ​`put-json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の put-json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の put-json-product-to-java.dwl の変換。 %dw 2.0 output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 3. 前に作成した DataWeave 変換を使用する ​`updatePayload`​ と、​`variables/set-productId-variable.dwl`​ スクリプトを使用する ​`id`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 4. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 5. `Try scope`​ に ​`db:update`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` 6. `Transform component`​ を追加し、​`src/main/resources/variables`​ にある ​`set-httpStatus-with-204.dwl`​ ファイルを使用して ​`httpStatus`​ 変数に ​`204`​ を設定します。 ```xml ``` Studio 7 の put-product-flow の設定 XML。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` ![Studio 7 の put-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m4-apikit-based-example-put-product-flow.png) Figure 8. Studio 7 の put-product-flow ## [](#delete-product-flow-の移行)_delete-product-flow_​ の移行 `delete-product-flow`​ は ​`URI parameter`​ として指定された ​`id`​ を持つ商品レコードを MySQL データベースから削除し、HTTP 204 状況コードを返します。 ![Studio 6 の delete-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m3-apikit-based-example-delete-product-flow.png) Figure 9. Studio 6 の delete-product-flow Studio 6 の delete-product-flow の設定 XML。 ```xml ``` 1. `delete-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 3. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 4. `Try scope`​ に ​`db:delete`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。Mule 3.x とは逆に、前に定義した ​`productId`​ フロー変数には、​`flowVars.productId`​ ではなく ​`vars.productId`​ としてアクセスする必要があります。 ```xml delete from product where id=:productId ``` 5. 次のように ​`src/main/resources/variables`​ に ​`set-httpStatus-with-204.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- 204 6. `NO CONTENT`​ 応答コードを定義するために、​`Transform Component`​ を使用して値 ​`204`​ を持つ ​`httpStatus`​ 変数を設定します。 ```xml ``` 特定の HTTP 状況コードを返すには、​`http.status`​ プロパティを設定する代わりに、Mule 4 の APIkit で ​`httpStatus`​ という名前の変数を設定する必要があります。 Studio 7 の delete-product-flow の設定 XML。 ```xml delete from product where id=:productId ``` ![Studio 7 の delete-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/m4-apikit-based-example-delete-product-flow.png) Figure 10. Studio 7 の delete-product-flow ## [](#バックエンドフローの移行)バックエンドフローの移行 バックエンドフローの移行方法 APIkit によって生成された各バックエンドフローの実装に ​`flow-ref`​ を追加します。 \+ .Studio 6 のバックエンドフローの設定 XML。 ```xml ``` + \+ .Studio 7 のバックエンドフローの設定 XML。 ```xml ``` ## [](#デフォルトの-apikit-グローバル例外戦略の拡張)デフォルトの APIkit グローバル例外戦略の拡張 1. `APP:NOT_FOUND`​ 例外種別を ApiKit で生成された 404 マッピングに追加し、​`get-product-by-id-flow`​ の ​`validation:is-true`​ 要素によってスローされた例外を処理します。特定の状況コードにマップするその他のエラーに対してこのプロセスを繰り返すことができます。 Studio 6 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` Studio 7 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` 2. まだ管理されていないすべての例外に、汎用の ApiKit による 500 へのマッピングを追加します。 Studio 6 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` Studio 7 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` # APIkit ベースのアプリケーションの移行 この例は、APIkit ベースのアプリケーションを Mule 3 から Mule 4 へ移行するために必要な手順を示しています。次の REST API は、MySQL データベースで CRUD (create、read、update、delete) 操作を実行します。 ![Studio 6 の api-main](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-main.png) ![Studio 6 の api-console](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-console.png) ![Studio 6 の get:/product:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-get-products.png) ![Studio 6 の get:/product/{id}:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-get-product-id.png) ![Studio 6 の post:/product:application/json:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-post-product.png) ![Studio 6 の delete:/product/{id}:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-delete-product.png) ![Studio 6 の put:/product/{id}:application/json:api-config フロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-put-product.png) ![Studio 6 の api-apiKitGlobalExceptionMapping フロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-globalexceptionmapping.png) ## [](#プロパティプレースホルダーの移行)プロパティプレースホルダーの移行 Mule 4 では、プロパティプレースホルダーは ​`.yaml`​ または ​`.properties`​ 設定ファイルのいずれかとしてサポートされています。 1. `/src/main/resources`​ プロジェクトディレクトリに ​`config`​ という名前のフォルダーを作成します。 2. 新しく作成した config フォルダー内に ​`configuration.yaml`​ という名前の設定ファイルを作成します。 3. プロパティプレースホルダーを ​`.properties`​ 形式から ​`.yaml`​ 形式に移行します。 configuration.properties http.host=0.0.0.0 http.port=8081 mysql.password=pa$$w0rd mysql.port=3306 mysql.user=admin mysql.database=products mysql.host=corp.services.com autodiscovery.api.version=1.0.0:1762946 autodiscovery.api.name=groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database anypoint.platform.client\_id=1f702j71hu9z2x88v9vd19v7h248s589 anypoint.platform.client\_secret=87v8V47668701Dd574B0531255d6287d configuration.yaml http: host: "0.0.0.0" port: "8081" mysql: password: "pa$$w0rd" port: "3306" user: "admin" database: "products" host: "corp.services.com" autodiscovery: api: name: "groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database" version: "1.0.0:1762946" anypoint: platform: client\_id: "1f702j71hu9z2x88v9vd19v7h248s589" client\_secret: "87v8V47668701Dd574B0531255d6287d" 4. 標準の Spring 要素 ​``​ を新しいグローバル要素 ​`configuration-properties`​ に置き換えます。 Studio 6 のプロパティプレースホルダーの設定 XML。 ```xml ``` `file`​ 属性は、​`/src/main/resources/config`​ フォルダーにある YAML 形式の新しい設定ファイルを参照しています。 Studio 7 のプロパティプレースホルダーの設定 XML。 ```xml ``` ## [](#グローバル-http-リスナー設定の移行)グローバル HTTP リスナー設定の移行 Studio 6 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` 最小限の設定では、内側の ​`http:listener-connection`​ 要素で ​`host`​ と ​`port`​ を指定する必要があります。前のステップで定義したプレースホルダーを使用します。 Studio 7 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` ## [](#mysql-グローバル設定の移行)MySQL グローバル設定の移行 Database Connector により、Mule アプリケーションで使用する ​_Derby_​、​_MySQL_​、​_Oracle_​ データベースのセットアップが容易になります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Database Connector`​\] を選択します。 2. \[​`Database Config`​ (データベース設定)\] グローバル設定要素を追加します。 3. \[Database Config (データベース設定)\] > \[Connection (接続)\] で、\[MySQL Connection (MySQL 接続)\] を選択します。 4. \[MySQL JDBC Driver (MySQL JDBC ドライバー)\] で \[Add Dependency (連動関係を追加)\] をクリックし、ドライバーの Maven 情報を設定します。 mysql mysql-connector-java 5.1.6 5. 前に定義したプレースホルダーを使用して、​`host`​、​`port`​、​`user`​、​`password`​、​`database`​ を含む MySQL グローバル設定を完了します。 Studio 6 の MySQL グローバル設定の設定 XML。 ```xml ``` Studio 7 の MySQL グローバル設定の設定 XML。 ```xml ``` ## [](#api-自動検出設定の移行)API 自動検出設定の移行 Anypoint Platform で API を登録するには ​`api-platform-gw`​ グローバル要素が必要です。 Studio 6 の API 自動検出設定の設定 XML。 ```xml ``` Mule Runtime 4.x では、​`apiName`​、​`version`​、​`create`​ 属性が削除されました。必要なのは ​`apiId`​ 属性と ​`flowRef`​ 属性のみです。 API Manager によって ​`apiId`​ が生成され、API インスタンスダッシュボードに表示されます。 Mule Runtime 4.x の API 自動検出設定の場合は、次のようになります。 1. 以下の名前空間をスキーマの ​`global.xml`​ 設定ファイルに追加します。 xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway" http://www.mulesoft.org/schema/mule/api-gateway http://www.mulesoft.org/schema/mule/api-gateway/current/mule-api-gateway.xsd 2. 必要な自動検出連動関係情報をプロジェクトの ​`pom.xml`​ ファイルに追加します。 com.mulesoft.anypoint mule-module-autodiscovery 4.0.0 Studio 7 の API 自動検出設定の設定 XML。 ```xml ``` ## [](#グローバル検証設定の移行)グローバル検証設定の移行 Studio 6 のグローバル検証設定の設定 XML。 ```xml ``` Mule Runtime 3.x とは逆に、設定を行うには、\[Mule Palette (Mule パレット)\] に Validation Module を追加する必要があります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Validation Module`​\] を選択します。 2. \[​`Validation Config`​ (データベース設定)\] グローバル設定要素を追加します。 Studio 7 のグローバル検証設定の設定 XML。 ```xml ``` ## [](#get-products-flow-の移行)_get-products-flow_​ の移行 `get-products-flow`​ は ​`Product Category`​ または ​`Product Name`​ あるいはその両方で絞り込み、データベースから商品を返します。また ​`offset`​ および ​`maxResults`​ パラメーターを使用するページ分割クエリもサポートされています。 ![Studio 6 の get-products-flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-get-products-flow.png) Figure 1. Studio 6 の get-products-flow Studio 6 の get-products-flow の設定 XML。 ```xml ``` 1. `get-products-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources`​ フォルダーに ​`variables`​ という名前のパッケージを作成します。 3. `src/main/resources/variables`​ フォルダーに ​`set-queryCategory-variable.dwl`​ ファイルを作成し、​`queryCategory`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryCategory = attributes.queryParams.category --- if (queryCategory != null) queryCategory else '%%' 4. `src/main/resources/variables`​ フォルダーに ​`set-queryLimit-variable.dwl`​ ファイルを作成し、​`queryLimit`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.maxResults as Number 5. `src/main/resources/variables`​ フォルダーに ​`set-queryName-variable.dwl`​ ファイルを作成し、​`queryName`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryName = attributes.queryParams.name --- if (queryName != null) queryName else '%%' 6. `src/main/resources/variables`​ フォルダーに ​`set-queryOffset-variable.dwl`​ ファイルを作成し、​`queryOffset`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.offset as Number 7. `Transform component`​ を追加し、​`message-properties-transformer`​ の内側のロジックを置き換えて、その DW スクリプトを参照する変数 ​`queryOffset`​、​`queryLimit`​、​`queryName`​、​`queryCategory`​ を設定します。 ```xml ``` 8. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` 9. `src/main/resources`​ フォルダーに ​`mappings`​ という名前のパッケージを作成します。 10. `src/main/resources/mappings`​ フォルダーに ​`get-products-response.dwl`​ ファイルを作成します。 11. `get-products-response.dwl`​ DW 1.0 スクリプトを DW 2.0 に移行します。 DW 1.0 の get-products-response の変換。 %dw 1.0 %output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as :string {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as :string {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as :number, stock: $.stock as :number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } DW 2.0 の get-products-response の変換。 %dw 2.0 output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as String {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as String {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as Number, stock: $.stock as Number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } 12. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-products-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` ![Studio 7 の get-products-flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m4-apikit-based-example-get-products-flow.png) Figure 2. Studio 7 の get-products-flow ## [](#get-product-by-id-flow-の移行)_get-product-by-id-flow_​ の移行 `get-product-by-id-flow`​ は、​`id`​ で絞り込んでデータベースから商品を返します。 必要な ID を持つ商品がない場合は、​`HTTP 404 Not Found`​ エラーが返されます。 ![Studio 6 の get-product-by-id-flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-get-product-by-id-flow.png) Figure 3. Studio 6 の get-product-by-id-flow Studio 6 の get-product-by-id-flow の設定 XML。 ```xml ``` 1. `get-product-by-id-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/variables`​ フォルダーに ​`set-productId-variable.dwl`​ ファイルを作成します。​`uriParams`​ から ​`id`​ を取得する次のロジックを追加します。 %dw 2.0 output application/java --- attributes.uriParams.id 3. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 4. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` 5. `db:select`​ の後に、クエリから結果が返されたかどうかをチェックする ​`validation:is-true`​ 要素を追加します。返されなかった場合は ​`APP:NOT_FOUND`​ エラーをスローします。デフォルトの式言語として ​`MEL`​ が ​`DataWeave`​ に置き換わり、​`[payload.size() > 0]`​ は ​`[sizeOf(payload) > 0]`​ として書き換えられています。 ```xml ``` 6. `src/main/resources/mappings`​ フォルダーに ​`get-product-by-id-response.dwl`​ ファイルを作成し、JSON 応答を構築する DataWeave スクリプトを 1.0 から 2.0 に移行します。 DW 1.0 の get-product-by-id-response の変換。 %dw 1.0 %output application/json %var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as :string {format: "##.##"} as :number, listPrice: (product.list\_price default "0.0") as :string {format: "##.##"} as :number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as :date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as :date {format: "yyyy-MM-dd"} } DW 2.0 の get-product-by-id-response.dwl の変換。 %dw 2.0 output application/json var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as String {format: "##.##"} as Number, listPrice: (product.list\_price default "0.0") as String {format: "##.##"} as Number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as Date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as Date {format: "yyyy-MM-dd"} } 7. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-product-by-id-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` ![Studio 7 の get-product-by-id-flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m4-apikit-based-example-get-product-by-id-flow.png) Figure 4. Studio 7 の get-product-by-id-flow ## [](#post-product-flow-の移行)_post-product-flow_​ の移行 `post-product-flow`​ はデータベースに商品を挿入します。 ![Studio 6 の post-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-post-product-flow.png) Figure 5. Studio 6 の post-product-flow Studio 6 の post-product-flow の設定 XML。 ```xml ``` 1. `post-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. JSON 要求を JAVA マップに変換するために、​`src/main/resources/mappings`​ フォルダーに ​`json-to-java.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- payload 3. `src/main/resources/mappings`​ に ​`json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, (manufactured: 1) when payload.manufactured == true, (manufactured: 0) when payload.manufactured == false, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の json-product-to-java.dwl の変換。 %dw 2.0 output application/java fun getManufacturedCode(value) = if (value == true) 1 else 0 --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: getManufacturedCode(payload.manufactured), name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 4. 前に作成した DataWeave 変換を使用して ​`originalPayload`​ と ​`newPayload`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 5. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 6. `Try scope`​ に ​`db:insert`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。データベースエンジンによって自動生成された ​`ID`​ を持つペイロードを設定する ​`db:auto-generated-keys-column-name`​ タグも含まれています。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` 7. `src/main/resources/mappings`​ に ​`post-product-response.dwl`​ ファイルを作成し、応答変換を DataWeave 1.0 から 2.0 に移行します。式 ​`payload.generatedKeys.GENERATED_KEY`​ を使用してペイロードから生成された ​`id`​ を取得するという違いがあります。 DW 1.0 の post-product-response.dwl の変換。 %dw 1.0 %output application/json --- flowVars.originalPayload ++ id: payload\[0\].GENERATED\_KEY DW 2.0 の post-product-response.dwl の変換。 %dw 2.0 output application/json --- vars.originalPayload ++ id: payload.generatedKeys.GENERATED\_KEY 8. `Transform component`​ を追加し、ペイロードを DataWeave スクリプトで設定します。 ```xml ``` Studio 7 の post-product-flow の設定 XML。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` ![Studio 7 の post-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m4-apikit-based-example-post-product-flow.png) Figure 6. Studio 7 の post-product-flow ## [](#put-product-flow-の移行)_put-product-flow_​ の移行 `put-product-flow`​ は指定された ​`id`​ に基づいてデータベース内の商品を更新します。 ![Studio 6 の put-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-put-product-flow.png) Figure 7. Studio 6 の put-product-flow Studio 6 の put-product-flow の設定 XML。 ```xml ``` 1. `put-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/mappings`​ フォルダーに ​`put-json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の put-json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の put-json-product-to-java.dwl の変換。 %dw 2.0 output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 3. 前に作成した DataWeave 変換を使用する ​`updatePayload`​ と、​`variables/set-productId-variable.dwl`​ スクリプトを使用する ​`id`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 4. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 5. `Try scope`​ に ​`db:update`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` 6. `Transform component`​ を追加し、​`src/main/resources/variables`​ にある ​`set-httpStatus-with-204.dwl`​ ファイルを使用して ​`httpStatus`​ 変数に ​`204`​ を設定します。 ```xml ``` Studio 7 の put-product-flow の設定 XML。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` ![Studio 7 の put-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m4-apikit-based-example-put-product-flow.png) Figure 8. Studio 7 の put-product-flow ## [](#delete-product-flow-の移行)_delete-product-flow_​ の移行 `delete-product-flow`​ は ​`URI parameter`​ として指定された ​`id`​ を持つ商品レコードを MySQL データベースから削除し、HTTP 204 状況コードを返します。 ![Studio 6 の delete-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m3-apikit-based-example-delete-product-flow.png) Figure 9. Studio 6 の delete-product-flow Studio 6 の delete-product-flow の設定 XML。 ```xml ``` 1. `delete-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 3. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 4. `Try scope`​ に ​`db:delete`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。Mule 3.x とは逆に、前に定義した ​`productId`​ フロー変数には、​`flowVars.productId`​ ではなく ​`vars.productId`​ としてアクセスする必要があります。 ```xml delete from product where id=:productId ``` 5. 次のように ​`src/main/resources/variables`​ に ​`set-httpStatus-with-204.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- 204 6. `NO CONTENT`​ 応答コードを定義するために、​`Transform Component`​ を使用して値 ​`204`​ を持つ ​`httpStatus`​ 変数を設定します。 ```xml ``` 特定の HTTP 状況コードを返すには、​`http.status`​ プロパティを設定する代わりに、Mule 4 の APIkit で ​`httpStatus`​ という名前の変数を設定する必要があります。 Studio 7 の delete-product-flow の設定 XML。 ```xml delete from product where id=:productId ``` ![Studio 7 の delete-product-flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/m4-apikit-based-example-delete-product-flow.png) Figure 10. Studio 7 の delete-product-flow ## [](#バックエンドフローの移行)バックエンドフローの移行 バックエンドフローの移行方法 APIkit によって生成された各バックエンドフローの実装に ​`flow-ref`​ を追加します。 \+ .Studio 6 のバックエンドフローの設定 XML。 ```xml ``` + \+ .Studio 7 のバックエンドフローの設定 XML。 ```xml ``` ## [](#デフォルトの-apikit-グローバル例外戦略の拡張)デフォルトの APIkit グローバル例外戦略の拡張 1. `APP:NOT_FOUND`​ 例外種別を ApiKit で生成された 404 マッピングに追加し、​`get-product-by-id-flow`​ の ​`validation:is-true`​ 要素によってスローされた例外を処理します。特定の状況コードにマップするその他のエラーに対してこのプロセスを繰り返すことができます。 Studio 6 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` Studio 7 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` 2. まだ管理されていないすべての例外に、汎用の ApiKit による 500 へのマッピングを追加します。 Studio 6 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` Studio 7 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` # APIkit ベースのアプリケーションの移行 この例は、APIkit ベースのアプリケーションを Mule 3 から Mule 4 へ移行するために必要な手順を示しています。次の REST API は、MySQL データベースで CRUD (create、read、update、delete) 操作を実行します。 ![HTTP、APIkit Router、Error handling などのコンポーネントが含まれるメイン API フローが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-main.png) ![HTTP、APIkit Console、Error handling が含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-console.png) ![api-config を使用して商品を取得する GET 要求が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-get-products.png) ![API 設定とエラー処理を使用して ID で商品を取得するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-get-product-id.png) ![エラー処理ステップが含まれる、新しい商品を投稿するフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-post-product.png) ![エラー処理が含まれる、ID で商品を削除するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-delete-product.png) ![api-config を使用して JSON 形式で商品を更新する PUT 要求の API 設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-put-product.png) ![HTTP 状況コードやペイロードを設定するコンポーネントが含まれる、API グローバル例外処理が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-globalexceptionmapping.png) ## [](#プロパティプレースホルダーの移行)プロパティプレースホルダーの移行 Mule 4 では、プロパティプレースホルダーは ​`.yaml`​ または ​`.properties`​ 設定ファイルのいずれかとしてサポートされています。 1. `/src/main/resources`​ プロジェクトディレクトリに ​`config`​ という名前のフォルダーを作成します。 2. 新しく作成した config フォルダー内に ​`configuration.yaml`​ という名前の設定ファイルを作成します。 3. プロパティプレースホルダーを ​`.properties`​ 形式から ​`.yaml`​ 形式に移行します。 configuration.properties http.host=0.0.0.0 http.port=8081 mysql.password=pa$$w0rd mysql.port=3306 mysql.user=admin mysql.database=products mysql.host=corp.services.com autodiscovery.api.version=1.0.0:1762946 autodiscovery.api.name=groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database anypoint.platform.client\_id=1f702j71hu9z2x88v9vd19v7h248s589 anypoint.platform.client\_secret=87v8V47668701Dd574B0531255d6287d configuration.yaml http: host: "0.0.0.0" port: "8081" mysql: password: "pa$$w0rd" port: "3306" user: "admin" database: "products" host: "corp.services.com" autodiscovery: api: name: "groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database" version: "1.0.0:1762946" anypoint: platform: client\_id: "1f702j71hu9z2x88v9vd19v7h248s589" client\_secret: "87v8V47668701Dd574B0531255d6287d" 4. 標準の Spring 要素 ​``​ を新しいグローバル要素 ​`configuration-properties`​ に置き換えます。 Studio 6 のプロパティプレースホルダーの設定 XML。 ```xml ``` `file`​ 属性は、​`/src/main/resources/config`​ フォルダーにある YAML 形式の新しい設定ファイルを参照しています。 Studio 7 のプロパティプレースホルダーの設定 XML。 ```xml ``` ## [](#グローバル-http-リスナー設定の移行)グローバル HTTP リスナー設定の移行 Studio 6 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` 最小限の設定では、内側の ​`http:listener-connection`​ 要素で ​`host`​ と ​`port`​ を指定する必要があります。前のステップで定義したプレースホルダーを使用します。 Studio 7 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` ## [](#mysql-グローバル設定の移行)MySQL グローバル設定の移行 Database Connector により、Mule アプリケーションで使用する ​_Derby_​、​_MySQL_​、​_Oracle_​ データベースのセットアップが容易になります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Database Connector`​\] を選択します。 2. \[​`Database Config`​ (データベース設定)\] グローバル設定要素を追加します。 3. \[Database Config (データベース設定)\] > \[Connection (接続)\] で、\[MySQL Connection (MySQL 接続)\] を選択します。 4. \[MySQL JDBC Driver (MySQL JDBC ドライバー)\] で \[Add Dependency (連動関係を追加)\] をクリックし、ドライバーの Maven 情報を設定します。 mysql mysql-connector-java 5.1.6 5. 前に定義したプレースホルダーを使用して、​`host`​、​`port`​、​`user`​、​`password`​、​`database`​ を含む MySQL グローバル設定を完了します。 Studio 6 の MySQL グローバル設定の設定 XML。 ```xml ``` Studio 7 の MySQL グローバル設定の設定 XML。 ```xml ``` ## [](#api-自動検出設定の移行)API 自動検出設定の移行 Anypoint Platform で API を登録するには ​`api-platform-gw`​ グローバル要素が必要です。 Studio 6 の API 自動検出設定の設定 XML。 ```xml ``` Mule Runtime 4.x では、​`apiName`​、​`version`​、​`create`​ 属性が削除されました。必要なのは ​`apiId`​ 属性と ​`flowRef`​ 属性のみです。 API Manager によって ​`apiId`​ が生成され、API インスタンスダッシュボードに表示されます。 Mule Runtime 4.x の API 自動検出設定の場合は、次のようになります。 1. 以下の名前空間をスキーマの ​`global.xml`​ 設定ファイルに追加します。 xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway" http://www.mulesoft.org/schema/mule/api-gateway http://www.mulesoft.org/schema/mule/api-gateway/current/mule-api-gateway.xsd 2. 必要な自動検出連動関係情報をプロジェクトの ​`pom.xml`​ ファイルに追加します。 com.mulesoft.anypoint mule-module-autodiscovery 4.0.0 Studio 7 の API 自動検出設定の設定 XML。 ```xml ``` ## [](#グローバル検証設定の移行)グローバル検証設定の移行 Studio 6 のグローバル検証設定の設定 XML。 ```xml ``` Mule Runtime 3.x とは逆に、設定を行うには、\[Mule Palette (Mule パレット)\] に Validation Module を追加する必要があります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Validation Module`​\] を選択します。 2. \[​`Validation Config`​ (データベース設定)\] グローバル設定要素を追加します。 Studio 7 のグローバル検証設定の設定 XML。 ```xml ``` ## [](#get-products-flow-の移行)_get-products-flow_​ の移行 `get-products-flow`​ は ​`Product Category`​ または ​`Product Name`​ あるいはその両方で絞り込み、データベースから商品を返します。また ​`offset`​ および ​`maxResults`​ パラメーターを使用するページ分割クエリもサポートされています。 ![Source、Transform Message、Error handling などのコンポーネントが含まれる、商品を取得する GET 要求が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-get-products-flow.png) Figure 1. Studio 6 の get-products-flow Studio 6 の get-products-flow の設定 XML。 ```xml ``` 1. `get-products-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources`​ フォルダーに ​`variables`​ という名前のパッケージを作成します。 3. `src/main/resources/variables`​ フォルダーに ​`set-queryCategory-variable.dwl`​ ファイルを作成し、​`queryCategory`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryCategory = attributes.queryParams.category --- if (queryCategory != null) queryCategory else '%%' 4. `src/main/resources/variables`​ フォルダーに ​`set-queryLimit-variable.dwl`​ ファイルを作成し、​`queryLimit`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.maxResults as Number 5. `src/main/resources/variables`​ フォルダーに ​`set-queryName-variable.dwl`​ ファイルを作成し、​`queryName`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryName = attributes.queryParams.name --- if (queryName != null) queryName else '%%' 6. `src/main/resources/variables`​ フォルダーに ​`set-queryOffset-variable.dwl`​ ファイルを作成し、​`queryOffset`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.offset as Number 7. `Transform component`​ を追加し、​`message-properties-transformer`​ の内側のロジックを置き換えて、その DW スクリプトを参照する変数 ​`queryOffset`​、​`queryLimit`​、​`queryName`​、​`queryCategory`​ を設定します。 ```xml ``` 8. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` 9. `src/main/resources`​ フォルダーに ​`mappings`​ という名前のパッケージを作成します。 10. `src/main/resources/mappings`​ フォルダーに ​`get-products-response.dwl`​ ファイルを作成します。 11. `get-products-response.dwl`​ DW 1.0 スクリプトを DW 2.0 に移行します。 DW 1.0 の get-products-response の変換。 %dw 1.0 %output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as :string {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as :string {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as :number, stock: $.stock as :number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } DW 2.0 の get-products-response の変換。 %dw 2.0 output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as String {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as String {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as Number, stock: $.stock as Number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } 12. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-products-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` ![Source、Transform Message、Error handling などのコンポーネントが含まれる、商品を取得するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m4-apikit-based-example-get-products-flow.png) Figure 2. Studio 7 の get-products-flow ## [](#get-product-by-id-flow-の移行)_get-product-by-id-flow_​ の移行 `get-product-by-id-flow`​ は、​`id`​ で絞り込んでデータベースから商品を返します。 必要な ID を持つ商品がない場合は、​`HTTP 404 Not Found`​ エラーが返されます。 ![検証や JSON 変換が含まれる、ID で商品を取得するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-get-product-by-id-flow.png) Figure 3. Studio 6 の get-product-by-id-flow Studio 6 の get-product-by-id-flow の設定 XML。 ```xml ``` 1. `get-product-by-id-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/variables`​ フォルダーに ​`set-productId-variable.dwl`​ ファイルを作成します。​`uriParams`​ から ​`id`​ を取得する次のロジックを追加します。 %dw 2.0 output application/java --- attributes.uriParams.id 3. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 4. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` 5. `db:select`​ の後に、クエリから結果が返されたかどうかをチェックする ​`validation:is-true`​ 要素を追加します。返されなかった場合は ​`APP:NOT_FOUND`​ エラーをスローします。デフォルトの式言語として ​`MEL`​ が ​`DataWeave`​ に置き換わり、​`[payload.size() > 0]`​ は ​`[sizeOf(payload) > 0]`​ として書き換えられています。 ```xml ``` 6. `src/main/resources/mappings`​ フォルダーに ​`get-product-by-id-response.dwl`​ ファイルを作成し、JSON 応答を構築する DataWeave スクリプトを 1.0 から 2.0 に移行します。 DW 1.0 の get-product-by-id-response の変換。 %dw 1.0 %output application/json %var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as :string {format: "##.##"} as :number, listPrice: (product.list\_price default "0.0") as :string {format: "##.##"} as :number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as :date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as :date {format: "yyyy-MM-dd"} } DW 2.0 の get-product-by-id-response.dwl の変換。 %dw 2.0 output application/json var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as String {format: "##.##"} as Number, listPrice: (product.list\_price default "0.0") as String {format: "##.##"} as Number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as Date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as Date {format: "yyyy-MM-dd"} } 7. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-product-by-id-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` ![Source、Transform Message、Error handling などのコンポーネントが含まれる、ID による GET 要求が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m4-apikit-based-example-get-product-by-id-flow.png) Figure 4. Studio 7 の get-product-by-id-flow ## [](#post-product-flow-の移行)_post-product-flow_​ の移行 `post-product-flow`​ はデータベースに商品を挿入します。 ![Source、Transactional、Error handling などのコンポーネントが含まれる、商品を投稿するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-post-product-flow.png) Figure 5. Studio 6 の post-product-flow Studio 6 の post-product-flow の設定 XML。 ```xml ``` 1. `post-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. JSON 要求を JAVA マップに変換するために、​`src/main/resources/mappings`​ フォルダーに ​`json-to-java.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- payload 3. `src/main/resources/mappings`​ に ​`json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, (manufactured: 1) when payload.manufactured == true, (manufactured: 0) when payload.manufactured == false, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の json-product-to-java.dwl の変換。 %dw 2.0 output application/java fun getManufacturedCode(value) = if (value == true) 1 else 0 --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: getManufacturedCode(payload.manufactured), name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 4. 前に作成した DataWeave 変換を使用して ​`originalPayload`​ と ​`newPayload`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 5. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 6. `Try scope`​ に ​`db:insert`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。データベースエンジンによって自動生成された ​`ID`​ を持つペイロードを設定する ​`db:auto-generated-keys-column-name`​ タグも含まれています。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` 7. `src/main/resources/mappings`​ に ​`post-product-response.dwl`​ ファイルを作成し、応答変換を DataWeave 1.0 から 2.0 に移行します。式 ​`payload.generatedKeys.GENERATED_KEY`​ を使用してペイロードから生成された ​`id`​ を取得するという違いがあります。 DW 1.0 の post-product-response.dwl の変換。 %dw 1.0 %output application/json --- flowVars.originalPayload ++ id: payload\[0\].GENERATED\_KEY DW 2.0 の post-product-response.dwl の変換。 %dw 2.0 output application/json --- vars.originalPayload ++ id: payload.generatedKeys.GENERATED\_KEY 8. `Transform component`​ を追加し、ペイロードを DataWeave スクリプトで設定します。 ```xml ``` Studio 7 の post-product-flow の設定 XML。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` ![JSON 変換やデータベース操作が含まれる、新しい商品を投稿するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m4-apikit-based-example-post-product-flow.png) Figure 6. Studio 7 の post-product-flow ## [](#put-product-flow-の移行)_put-product-flow_​ の移行 `put-product-flow`​ は指定された ​`id`​ に基づいてデータベース内の商品を更新します。 ![トランザクションエラー処理や状況の更新が含まれる、商品を更新するフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-put-product-flow.png) Figure 7. Studio 6 の put-product-flow Studio 6 の put-product-flow の設定 XML。 ```xml ``` 1. `put-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/mappings`​ フォルダーに ​`put-json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の put-json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の put-json-product-to-java.dwl の変換。 %dw 2.0 output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 3. 前に作成した DataWeave 変換を使用する ​`updatePayload`​ と、​`variables/set-productId-variable.dwl`​ スクリプトを使用する ​`id`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 4. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 5. `Try scope`​ に ​`db:update`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` 6. `Transform component`​ を追加し、​`src/main/resources/variables`​ にある ​`set-httpStatus-with-204.dwl`​ ファイルを使用して ​`httpStatus`​ 変数に ​`204`​ を設定します。 ```xml ``` Studio 7 の put-product-flow の設定 XML。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` ![JSON 変換や状況の設定が含まれる、商品を更新するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m4-apikit-based-example-put-product-flow.png) Figure 8. Studio 7 の put-product-flow ## [](#delete-product-flow-の移行)_delete-product-flow_​ の移行 `delete-product-flow`​ は ​`URI parameter`​ として指定された ​`id`​ を持つ商品レコードを MySQL データベースから削除し、HTTP 204 状況コードを返します。 ![Source、Transactional、Error handling などのコンポーネントが含まれる、商品を削除するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m3-apikit-based-example-delete-product-flow.png) Figure 9. Studio 6 の delete-product-flow Studio 6 の delete-product-flow の設定 XML。 ```xml ``` 1. `delete-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 3. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 4. `Try scope`​ に ​`db:delete`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。Mule 3.x とは逆に、前に定義した ​`productId`​ フロー変数には、​`flowVars.productId`​ ではなく ​`vars.productId`​ としてアクセスする必要があります。 ```xml delete from product where id=:productId ``` 5. 次のように ​`src/main/resources/variables`​ に ​`set-httpStatus-with-204.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- 204 6. `NO CONTENT`​ 応答コードを定義するために、​`Transform Component`​ を使用して値 ​`204`​ を持つ ​`httpStatus`​ 変数を設定します。 ```xml ``` 特定の HTTP 状況コードを返すには、​`http.status`​ プロパティを設定する代わりに、Mule 4 の APIkit で ​`httpStatus`​ という名前の変数を設定する必要があります。 Studio 7 の delete-product-flow の設定 XML。 ```xml delete from product where id=:productId ``` ![エラー処理や HTTP 状況の設定が含まれる、商品を削除するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/m4-apikit-based-example-delete-product-flow.png) Figure 10. Studio 7 の delete-product-flow ## [](#バックエンドフローの移行)バックエンドフローの移行 バックエンドフローの移行方法 APIkit によって生成された各バックエンドフローの実装に ​`flow-ref`​ を追加します。 \+ .Studio 6 のバックエンドフローの設定 XML。 ```xml ``` + \+ .Studio 7 のバックエンドフローの設定 XML。 ```xml ``` ## [](#デフォルトの-apikit-グローバル例外戦略の拡張)デフォルトの APIkit グローバル例外戦略の拡張 1. `APP:NOT_FOUND`​ 例外種別を ApiKit で生成された 404 マッピングに追加し、​`get-product-by-id-flow`​ の ​`validation:is-true`​ 要素によってスローされた例外を処理します。特定の状況コードにマップするその他のエラーに対してこのプロセスを繰り返すことができます。 Studio 6 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` Studio 7 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` 2. まだ管理されていないすべての例外に、汎用の ApiKit による 500 へのマッピングを追加します。 Studio 6 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` Studio 7 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` # APIkit ベースのアプリケーションの移行 この例は、APIkit ベースのアプリケーションを Mule 3 から Mule 4 へ移行するために必要な手順を示しています。次の REST API は、MySQL データベースで CRUD (create、read、update、delete) 操作を実行します。 ![HTTP、APIkit Router、Error handling などのコンポーネントが含まれるメイン API フローが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-main.png) ![HTTP、APIkit Console、Error handling が含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-console.png) ![api-config を使用して商品を取得する GET 要求が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-get-products.png) ![API 設定とエラー処理を使用して ID で商品を取得するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-get-product-id.png) ![エラー処理ステップが含まれる、新しい商品を投稿するフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-post-product.png) ![エラー処理が含まれる、ID で商品を削除するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-delete-product.png) ![api-config を使用して JSON 形式で商品を更新する PUT 要求の API 設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-put-product.png) ![HTTP 状況コードやペイロードを設定するコンポーネントが含まれる、API グローバル例外処理が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-globalexceptionmapping.png) ## [](#プロパティプレースホルダーの移行)プロパティプレースホルダーの移行 Mule 4 では、プロパティプレースホルダーは ​`.yaml`​ または ​`.properties`​ 設定ファイルのいずれかとしてサポートされています。 1. `/src/main/resources`​ プロジェクトディレクトリに ​`config`​ という名前のフォルダーを作成します。 2. 新しく作成した config フォルダー内に ​`configuration.yaml`​ という名前の設定ファイルを作成します。 3. プロパティプレースホルダーを ​`.properties`​ 形式から ​`.yaml`​ 形式に移行します。 configuration.properties http.host=0.0.0.0 http.port=8081 mysql.password=pa$$w0rd mysql.port=3306 mysql.user=admin mysql.database=products mysql.host=corp.services.com autodiscovery.api.version=1.0.0:1762946 autodiscovery.api.name=groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database anypoint.platform.client\_id=1f702j71hu9z2x88v9vd19v7h248s589 anypoint.platform.client\_secret=87v8V47668701Dd574B0531255d6287d configuration.yaml http: host: "0.0.0.0" port: "8081" mysql: password: "pa$$w0rd" port: "3306" user: "admin" database: "products" host: "corp.services.com" autodiscovery: api: name: "groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database" version: "1.0.0:1762946" anypoint: platform: client\_id: "1f702j71hu9z2x88v9vd19v7h248s589" client\_secret: "87v8V47668701Dd574B0531255d6287d" 4. 標準の Spring 要素 ​``​ を新しいグローバル要素 ​`configuration-properties`​ に置き換えます。 Studio 6 のプロパティプレースホルダーの設定 XML。 ```xml ``` `file`​ 属性は、​`/src/main/resources/config`​ フォルダーにある YAML 形式の新しい設定ファイルを参照しています。 Studio 7 のプロパティプレースホルダーの設定 XML。 ```xml ``` ## [](#グローバル-http-リスナー設定の移行)グローバル HTTP リスナー設定の移行 Studio 6 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` 最小限の設定では、内側の ​`http:listener-connection`​ 要素で ​`host`​ と ​`port`​ を指定する必要があります。前のステップで定義したプレースホルダーを使用します。 Studio 7 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` ## [](#mysql-グローバル設定の移行)MySQL グローバル設定の移行 Database Connector により、Mule アプリケーションで使用する ​_Derby_​、​_MySQL_​、​_Oracle_​ データベースのセットアップが容易になります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Database Connector`​\] を選択します。 2. \[​`Database Config`​ (データベース設定)\] グローバル設定要素を追加します。 3. \[Database Config (データベース設定)\] > \[Connection (接続)\] で、\[MySQL Connection (MySQL 接続)\] を選択します。 4. \[MySQL JDBC Driver (MySQL JDBC ドライバー)\] で \[Add Dependency (連動関係を追加)\] をクリックし、ドライバーの Maven 情報を設定します。 mysql mysql-connector-java 5.1.6 5. 前に定義したプレースホルダーを使用して、​`host`​、​`port`​、​`user`​、​`password`​、​`database`​ を含む MySQL グローバル設定を完了します。 Studio 6 の MySQL グローバル設定の設定 XML。 ```xml ``` Studio 7 の MySQL グローバル設定の設定 XML。 ```xml ``` ## [](#api-自動検出設定の移行)API 自動検出設定の移行 Anypoint Platform で API を登録するには ​`api-platform-gw`​ グローバル要素が必要です。 Studio 6 の API 自動検出設定の設定 XML。 ```xml ``` Mule Runtime 4.x では、​`apiName`​、​`version`​、​`create`​ 属性が削除されました。必要なのは ​`apiId`​ 属性と ​`flowRef`​ 属性のみです。 API Manager によって ​`apiId`​ が生成され、API インスタンスダッシュボードに表示されます。 Mule Runtime 4.x の API 自動検出設定の場合は、次のようになります。 1. 以下の名前空間をスキーマの ​`global.xml`​ 設定ファイルに追加します。 xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway" http://www.mulesoft.org/schema/mule/api-gateway http://www.mulesoft.org/schema/mule/api-gateway/current/mule-api-gateway.xsd 2. 必要な自動検出連動関係情報をプロジェクトの ​`pom.xml`​ ファイルに追加します。 com.mulesoft.anypoint mule-module-autodiscovery 4.0.0 Studio 7 の API 自動検出設定の設定 XML。 ```xml ``` ## [](#グローバル検証設定の移行)グローバル検証設定の移行 Studio 6 のグローバル検証設定の設定 XML。 ```xml ``` Mule Runtime 3.x とは逆に、設定を行うには、\[Mule Palette (Mule パレット)\] に Validation Module を追加する必要があります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Validation Module`​\] を選択します。 2. \[​`Validation Config`​ (データベース設定)\] グローバル設定要素を追加します。 Studio 7 のグローバル検証設定の設定 XML。 ```xml ``` ## [](#get-products-flow-の移行)_get-products-flow_​ の移行 `get-products-flow`​ は ​`Product Category`​ または ​`Product Name`​ あるいはその両方で絞り込み、データベースから商品を返します。また ​`offset`​ および ​`maxResults`​ パラメーターを使用するページ分割クエリもサポートされています。 ![Source、Transform Message、Error handling などのコンポーネントが含まれる、商品を取得する GET 要求が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-get-products-flow.png) Figure 1. Studio 6 の get-products-flow Studio 6 の get-products-flow の設定 XML。 ```xml ``` 1. `get-products-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources`​ フォルダーに ​`variables`​ という名前のパッケージを作成します。 3. `src/main/resources/variables`​ フォルダーに ​`set-queryCategory-variable.dwl`​ ファイルを作成し、​`queryCategory`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryCategory = attributes.queryParams.category --- if (queryCategory != null) queryCategory else '%%' 4. `src/main/resources/variables`​ フォルダーに ​`set-queryLimit-variable.dwl`​ ファイルを作成し、​`queryLimit`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.maxResults as Number 5. `src/main/resources/variables`​ フォルダーに ​`set-queryName-variable.dwl`​ ファイルを作成し、​`queryName`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryName = attributes.queryParams.name --- if (queryName != null) queryName else '%%' 6. `src/main/resources/variables`​ フォルダーに ​`set-queryOffset-variable.dwl`​ ファイルを作成し、​`queryOffset`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.offset as Number 7. `Transform component`​ を追加し、​`message-properties-transformer`​ の内側のロジックを置き換えて、その DW スクリプトを参照する変数 ​`queryOffset`​、​`queryLimit`​、​`queryName`​、​`queryCategory`​ を設定します。 ```xml ``` 8. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` 9. `src/main/resources`​ フォルダーに ​`mappings`​ という名前のパッケージを作成します。 10. `src/main/resources/mappings`​ フォルダーに ​`get-products-response.dwl`​ ファイルを作成します。 11. `get-products-response.dwl`​ DW 1.0 スクリプトを DW 2.0 に移行します。 DW 1.0 の get-products-response の変換。 %dw 1.0 %output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as :string {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as :string {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as :number, stock: $.stock as :number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } DW 2.0 の get-products-response の変換。 %dw 2.0 output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as String {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as String {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as Number, stock: $.stock as Number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } 12. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-products-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` ![Source、Transform Message、Error handling などのコンポーネントが含まれる、商品を取得するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m4-apikit-based-example-get-products-flow.png) Figure 2. Studio 7 の get-products-flow ## [](#get-product-by-id-flow-の移行)_get-product-by-id-flow_​ の移行 `get-product-by-id-flow`​ は、​`id`​ で絞り込んでデータベースから商品を返します。 必要な ID を持つ商品がない場合は、​`HTTP 404 Not Found`​ エラーが返されます。 ![検証や JSON 変換が含まれる、ID で商品を取得するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-get-product-by-id-flow.png) Figure 3. Studio 6 の get-product-by-id-flow Studio 6 の get-product-by-id-flow の設定 XML。 ```xml ``` 1. `get-product-by-id-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/variables`​ フォルダーに ​`set-productId-variable.dwl`​ ファイルを作成します。​`uriParams`​ から ​`id`​ を取得する次のロジックを追加します。 %dw 2.0 output application/java --- attributes.uriParams.id 3. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 4. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` 5. `db:select`​ の後に、クエリから結果が返されたかどうかをチェックする ​`validation:is-true`​ 要素を追加します。返されなかった場合は ​`APP:NOT_FOUND`​ エラーをスローします。デフォルトの式言語として ​`MEL`​ が ​`DataWeave`​ に置き換わり、​`[payload.size() > 0]`​ は ​`[sizeOf(payload) > 0]`​ として書き換えられています。 ```xml ``` 6. `src/main/resources/mappings`​ フォルダーに ​`get-product-by-id-response.dwl`​ ファイルを作成し、JSON 応答を構築する DataWeave スクリプトを 1.0 から 2.0 に移行します。 DW 1.0 の get-product-by-id-response の変換。 %dw 1.0 %output application/json %var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as :string {format: "##.##"} as :number, listPrice: (product.list\_price default "0.0") as :string {format: "##.##"} as :number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as :date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as :date {format: "yyyy-MM-dd"} } DW 2.0 の get-product-by-id-response.dwl の変換。 %dw 2.0 output application/json var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as String {format: "##.##"} as Number, listPrice: (product.list\_price default "0.0") as String {format: "##.##"} as Number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as Date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as Date {format: "yyyy-MM-dd"} } 7. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-product-by-id-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` ![Source、Transform Message、Error handling などのコンポーネントが含まれる、ID による GET 要求が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m4-apikit-based-example-get-product-by-id-flow.png) Figure 4. Studio 7 の get-product-by-id-flow ## [](#post-product-flow-の移行)_post-product-flow_​ の移行 `post-product-flow`​ はデータベースに商品を挿入します。 ![Source、Transactional、Error handling などのコンポーネントが含まれる、商品を投稿するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-post-product-flow.png) Figure 5. Studio 6 の post-product-flow Studio 6 の post-product-flow の設定 XML。 ```xml ``` 1. `post-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. JSON 要求を JAVA マップに変換するために、​`src/main/resources/mappings`​ フォルダーに ​`json-to-java.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- payload 3. `src/main/resources/mappings`​ に ​`json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, (manufactured: 1) when payload.manufactured == true, (manufactured: 0) when payload.manufactured == false, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の json-product-to-java.dwl の変換。 %dw 2.0 output application/java fun getManufacturedCode(value) = if (value == true) 1 else 0 --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: getManufacturedCode(payload.manufactured), name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 4. 前に作成した DataWeave 変換を使用して ​`originalPayload`​ と ​`newPayload`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 5. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 6. `Try scope`​ に ​`db:insert`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。データベースエンジンによって自動生成された ​`ID`​ を持つペイロードを設定する ​`db:auto-generated-keys-column-name`​ タグも含まれています。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` 7. `src/main/resources/mappings`​ に ​`post-product-response.dwl`​ ファイルを作成し、応答変換を DataWeave 1.0 から 2.0 に移行します。式 ​`payload.generatedKeys.GENERATED_KEY`​ を使用してペイロードから生成された ​`id`​ を取得するという違いがあります。 DW 1.0 の post-product-response.dwl の変換。 %dw 1.0 %output application/json --- flowVars.originalPayload ++ id: payload\[0\].GENERATED\_KEY DW 2.0 の post-product-response.dwl の変換。 %dw 2.0 output application/json --- vars.originalPayload ++ id: payload.generatedKeys.GENERATED\_KEY 8. `Transform component`​ を追加し、ペイロードを DataWeave スクリプトで設定します。 ```xml ``` Studio 7 の post-product-flow の設定 XML。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` ![JSON 変換やデータベース操作が含まれる、新しい商品を投稿するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m4-apikit-based-example-post-product-flow.png) Figure 6. Studio 7 の post-product-flow ## [](#put-product-flow-の移行)_put-product-flow_​ の移行 `put-product-flow`​ は指定された ​`id`​ に基づいてデータベース内の商品を更新します。 ![トランザクションエラー処理や状況の更新が含まれる、商品を更新するフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-put-product-flow.png) Figure 7. Studio 6 の put-product-flow Studio 6 の put-product-flow の設定 XML。 ```xml ``` 1. `put-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/mappings`​ フォルダーに ​`put-json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の put-json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の put-json-product-to-java.dwl の変換。 %dw 2.0 output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 3. 前に作成した DataWeave 変換を使用する ​`updatePayload`​ と、​`variables/set-productId-variable.dwl`​ スクリプトを使用する ​`id`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 4. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 5. `Try scope`​ に ​`db:update`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` 6. `Transform component`​ を追加し、​`src/main/resources/variables`​ にある ​`set-httpStatus-with-204.dwl`​ ファイルを使用して ​`httpStatus`​ 変数に ​`204`​ を設定します。 ```xml ``` Studio 7 の put-product-flow の設定 XML。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` ![JSON 変換や状況の設定が含まれる、商品を更新するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m4-apikit-based-example-put-product-flow.png) Figure 8. Studio 7 の put-product-flow ## [](#delete-product-flow-の移行)_delete-product-flow_​ の移行 `delete-product-flow`​ は ​`URI parameter`​ として指定された ​`id`​ を持つ商品レコードを MySQL データベースから削除し、HTTP 204 状況コードを返します。 ![Source、Transactional、Error handling などのコンポーネントが含まれる、商品を削除するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m3-apikit-based-example-delete-product-flow.png) Figure 9. Studio 6 の delete-product-flow Studio 6 の delete-product-flow の設定 XML。 ```xml ``` 1. `delete-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 3. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 4. `Try scope`​ に ​`db:delete`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。Mule 3.x とは逆に、前に定義した ​`productId`​ フロー変数には、​`flowVars.productId`​ ではなく ​`vars.productId`​ としてアクセスする必要があります。 ```xml delete from product where id=:productId ``` 5. 次のように ​`src/main/resources/variables`​ に ​`set-httpStatus-with-204.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- 204 6. `NO CONTENT`​ 応答コードを定義するために、​`Transform Component`​ を使用して値 ​`204`​ を持つ ​`httpStatus`​ 変数を設定します。 ```xml ``` 特定の HTTP 状況コードを返すには、​`http.status`​ プロパティを設定する代わりに、Mule 4 の APIkit で ​`httpStatus`​ という名前の変数を設定する必要があります。 Studio 7 の delete-product-flow の設定 XML。 ```xml delete from product where id=:productId ``` ![エラー処理や HTTP 状況の設定が含まれる、商品を削除するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/m4-apikit-based-example-delete-product-flow.png) Figure 10. Studio 7 の delete-product-flow ## [](#バックエンドフローの移行)バックエンドフローの移行 バックエンドフローの移行方法 APIkit によって生成された各バックエンドフローの実装に ​`flow-ref`​ を追加します。 \+ .Studio 6 のバックエンドフローの設定 XML。 ```xml ``` + \+ .Studio 7 のバックエンドフローの設定 XML。 ```xml ``` ## [](#デフォルトの-apikit-グローバル例外戦略の拡張)デフォルトの APIkit グローバル例外戦略の拡張 1. `APP:NOT_FOUND`​ 例外種別を ApiKit で生成された 404 マッピングに追加し、​`get-product-by-id-flow`​ の ​`validation:is-true`​ 要素によってスローされた例外を処理します。特定の状況コードにマップするその他のエラーに対してこのプロセスを繰り返すことができます。 Studio 6 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` Studio 7 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` 2. まだ管理されていないすべての例外に、汎用の ApiKit による 500 へのマッピングを追加します。 Studio 6 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` Studio 7 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` # APIkit ベースのアプリケーションの移行 この例は、APIkit ベースのアプリケーションを Mule 3 から Mule 4 へ移行するために必要な手順を示しています。次の REST API は、MySQL データベースで CRUD (create、read、update、delete) 操作を実行します。 ![HTTP、APIkit Router、Error handling などのコンポーネントが含まれるメイン API フローが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-main.png) ![HTTP、APIkit Console、Error handling が含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-console.png) ![api-config を使用して商品を取得する GET 要求が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-get-products.png) ![API 設定とエラー処理を使用して ID で商品を取得するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-get-product-id.png) ![エラー処理ステップが含まれる、新しい商品を投稿するフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-post-product.png) ![エラー処理が含まれる、ID で商品を削除するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-delete-product.png) ![api-config を使用して JSON 形式で商品を更新する PUT 要求の API 設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-put-product.png) ![HTTP 状況コードやペイロードを設定するコンポーネントが含まれる、API グローバル例外処理が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-globalexceptionmapping.png) ## [](#プロパティプレースホルダーの移行)プロパティプレースホルダーの移行 Mule 4 では、プロパティプレースホルダーは ​`.yaml`​ または ​`.properties`​ 設定ファイルのいずれかとしてサポートされています。 1. `/src/main/resources`​ プロジェクトディレクトリに ​`config`​ という名前のフォルダーを作成します。 2. 新しく作成した config フォルダー内に ​`configuration.yaml`​ という名前の設定ファイルを作成します。 3. プロパティプレースホルダーを ​`.properties`​ 形式から ​`.yaml`​ 形式に移行します。 configuration.properties http.host=0.0.0.0 http.port=8081 mysql.password=pa$$w0rd mysql.port=3306 mysql.user=admin mysql.database=products mysql.host=corp.services.com autodiscovery.api.version=1.0.0:1762946 autodiscovery.api.name=groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database anypoint.platform.client\_id=1f702j71hu9z2x88v9vd19v7h248s589 anypoint.platform.client\_secret=87v8V47668701Dd574B0531255d6287d configuration.yaml http: host: "0.0.0.0" port: "8081" mysql: password: "pa$$w0rd" port: "3306" user: "admin" database: "products" host: "corp.services.com" autodiscovery: api: name: "groupId:com.mulesoft.retailer.manufacturingit.apis:assetId:product-api-database" version: "1.0.0:1762946" anypoint: platform: client\_id: "1f702j71hu9z2x88v9vd19v7h248s589" client\_secret: "87v8V47668701Dd574B0531255d6287d" 4. 標準の Spring 要素 ​``​ を新しいグローバル要素 ​`configuration-properties`​ に置き換えます。 Studio 6 のプロパティプレースホルダーの設定 XML。 ```xml ``` `file`​ 属性は、​`/src/main/resources/config`​ フォルダーにある YAML 形式の新しい設定ファイルを参照しています。 Studio 7 のプロパティプレースホルダーの設定 XML。 ```xml ``` ## [](#グローバル-http-リスナー設定の移行)グローバル HTTP リスナー設定の移行 Studio 6 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` 最小限の設定では、内側の ​`http:listener-connection`​ 要素で ​`host`​ と ​`port`​ を指定する必要があります。前のステップで定義したプレースホルダーを使用します。 Studio 7 のグローバル HTTP リスナー設定の設定 XML。 ```xml ``` ## [](#mysql-グローバル設定の移行)MySQL グローバル設定の移行 Database Connector により、Mule アプリケーションで使用する ​_Derby_​、​_MySQL_​、​_Oracle_​ データベースのセットアップが容易になります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Database Connector`​\] を選択します。 2. \[​`Database Config`​ (データベース設定)\] グローバル設定要素を追加します。 3. \[Database Config (データベース設定)\] > \[Connection (接続)\] で、\[MySQL Connection (MySQL 接続)\] を選択します。 4. \[MySQL JDBC Driver (MySQL JDBC ドライバー)\] で \[Add Dependency (連動関係を追加)\] をクリックし、ドライバーの Maven 情報を設定します。 mysql mysql-connector-java 5.1.6 5. 前に定義したプレースホルダーを使用して、​`host`​、​`port`​、​`user`​、​`password`​、​`database`​ を含む MySQL グローバル設定を完了します。 Studio 6 の MySQL グローバル設定の設定 XML。 ```xml ``` Studio 7 の MySQL グローバル設定の設定 XML。 ```xml ``` ## [](#api-自動検出設定の移行)API 自動検出設定の移行 Anypoint Platform で API を登録するには ​`api-platform-gw`​ グローバル要素が必要です。 Studio 6 の API 自動検出設定の設定 XML。 ```xml ``` Mule Runtime 4.x では、​`apiName`​、​`version`​、​`create`​ 属性が削除されました。必要なのは ​`apiId`​ 属性と ​`flowRef`​ 属性のみです。 API Manager によって ​`apiId`​ が生成され、API インスタンスダッシュボードに表示されます。 Mule Runtime 4.x の API 自動検出設定の場合は、次のようになります。 1. 以下の名前空間をスキーマの ​`global.xml`​ 設定ファイルに追加します。 xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway" http://www.mulesoft.org/schema/mule/api-gateway http://www.mulesoft.org/schema/mule/api-gateway/current/mule-api-gateway.xsd 2. 必要な自動検出連動関係情報をプロジェクトの ​`pom.xml`​ ファイルに追加します。 com.mulesoft.anypoint mule-module-autodiscovery 4.0.0 Studio 7 の API 自動検出設定の設定 XML。 ```xml ``` ## [](#グローバル検証設定の移行)グローバル検証設定の移行 Studio 6 のグローバル検証設定の設定 XML。 ```xml ``` Mule Runtime 3.x とは逆に、設定を行うには、\[Mule Palette (Mule パレット)\] に Validation Module を追加する必要があります。 1. \[Mule Palette (Mule パレット)\] で \[​`Add Module`​ (モジュールの追加)\] をクリックし、使用可能なモジュールから \[​`Validation Module`​\] を選択します。 2. \[​`Validation Config`​ (データベース設定)\] グローバル設定要素を追加します。 Studio 7 のグローバル検証設定の設定 XML。 ```xml ``` ## [](#get-products-flow-の移行)_get-products-flow_​ の移行 `get-products-flow`​ は ​`Product Category`​ または ​`Product Name`​ あるいはその両方で絞り込み、データベースから商品を返します。また ​`offset`​ および ​`maxResults`​ パラメーターを使用するページ分割クエリもサポートされています。 ![Source、Transform Message、Error handling などのコンポーネントが含まれる、商品を取得する GET 要求が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-get-products-flow.png) Figure 1. Studio 6 の get-products-flow Studio 6 の get-products-flow の設定 XML。 ```xml ``` 1. `get-products-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources`​ フォルダーに ​`variables`​ という名前のパッケージを作成します。 3. `src/main/resources/variables`​ フォルダーに ​`set-queryCategory-variable.dwl`​ ファイルを作成し、​`queryCategory`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryCategory = attributes.queryParams.category --- if (queryCategory != null) queryCategory else '%%' 4. `src/main/resources/variables`​ フォルダーに ​`set-queryLimit-variable.dwl`​ ファイルを作成し、​`queryLimit`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.maxResults as Number 5. `src/main/resources/variables`​ フォルダーに ​`set-queryName-variable.dwl`​ ファイルを作成し、​`queryName`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java var queryName = attributes.queryParams.name --- if (queryName != null) queryName else '%%' 6. `src/main/resources/variables`​ フォルダーに ​`set-queryOffset-variable.dwl`​ ファイルを作成し、​`queryOffset`​ フロー変数を設定する DW スクリプトを記述します。 %dw 2.0 output application/java --- attributes.queryParams.offset as Number 7. `Transform component`​ を追加し、​`message-properties-transformer`​ の内側のロジックを置き換えて、その DW スクリプトを参照する変数 ​`queryOffset`​、​`queryLimit`​、​`queryName`​、​`queryCategory`​ を設定します。 ```xml ``` 8. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` 9. `src/main/resources`​ フォルダーに ​`mappings`​ という名前のパッケージを作成します。 10. `src/main/resources/mappings`​ フォルダーに ​`get-products-response.dwl`​ ファイルを作成します。 11. `get-products-response.dwl`​ DW 1.0 スクリプトを DW 2.0 に移行します。 DW 1.0 の get-products-response の変換。 %dw 1.0 %output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as :string {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as :string {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as :number, stock: $.stock as :number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } DW 2.0 の get-products-response の変換。 %dw 2.0 output application/json --- payload map { id: $.id, categories: ($.categories default "") splitBy ",", colors: ($.colors default "") splitBy ",", images: ($.images default "") splitBy ",", createdDate: $.created\_date as String {format: "yyyy-MM-dd"}, modifiedDate: $.modified\_date as String {format: "yyyy-MM-dd"}, safetyStockLevel: $.safety\_stock\_level as Number, stock: $.stock as Number, daysToManufacture: $.days\_to\_manufacture, name: $.name, description: $.description, listPrice: $.list\_price, manufactured: $.manufactured, productNumber: $.product\_number, size: $.size, sizeUnitMeasureCode: $.size\_unit\_measure\_code, standardCost: $.standard\_cost, weightUnitMeasureCode: $.weight\_unit\_measure\_code, weight: $.weight } 12. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-products-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p WHERE LOWER(p.name) like :name AND LOWER(p.categories) like :category LIMIT :limit OFFSET :offset ``` ![Source、Transform Message、Error handling などのコンポーネントが含まれる、商品を取得するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m4-apikit-based-example-get-products-flow.png) Figure 2. Studio 7 の get-products-flow ## [](#get-product-by-id-flow-の移行)_get-product-by-id-flow_​ の移行 `get-product-by-id-flow`​ は、​`id`​ で絞り込んでデータベースから商品を返します。 必要な ID を持つ商品がない場合は、​`HTTP 404 Not Found`​ エラーが返されます。 ![検証や JSON 変換が含まれる、ID で商品を取得するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-get-product-by-id-flow.png) Figure 3. Studio 6 の get-product-by-id-flow Studio 6 の get-product-by-id-flow の設定 XML。 ```xml ``` 1. `get-product-by-id-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/variables`​ フォルダーに ​`set-productId-variable.dwl`​ ファイルを作成します。​`uriParams`​ から ​`id`​ を取得する次のロジックを追加します。 %dw 2.0 output application/java --- attributes.uriParams.id 3. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 4. `db:select`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーター化クエリにはコロン (:) 構文を使用します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` 5. `db:select`​ の後に、クエリから結果が返されたかどうかをチェックする ​`validation:is-true`​ 要素を追加します。返されなかった場合は ​`APP:NOT_FOUND`​ エラーをスローします。デフォルトの式言語として ​`MEL`​ が ​`DataWeave`​ に置き換わり、​`[payload.size() > 0]`​ は ​`[sizeOf(payload) > 0]`​ として書き換えられています。 ```xml ``` 6. `src/main/resources/mappings`​ フォルダーに ​`get-product-by-id-response.dwl`​ ファイルを作成し、JSON 応答を構築する DataWeave スクリプトを 1.0 から 2.0 に移行します。 DW 1.0 の get-product-by-id-response の変換。 %dw 1.0 %output application/json %var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as :string {format: "##.##"} as :number, listPrice: (product.list\_price default "0.0") as :string {format: "##.##"} as :number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as :date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as :date {format: "yyyy-MM-dd"} } DW 2.0 の get-product-by-id-response.dwl の変換。 %dw 2.0 output application/json var product = payload\[0\] --- { id: product.id, name: product.name, description: product.description, manufactured: product.manufactured, productNumber: product.product\_number, colors: (product.colors default "") splitBy "," , categories:(product.categories default "") splitBy "," , safetyStockLevel: product.safety\_socket\_level, standardCost: (product.standard\_cost default "0.0") as String {format: "##.##"} as Number, listPrice: (product.list\_price default "0.0") as String {format: "##.##"} as Number, stock: product.stock, safetyStockLevel: product.safety\_stock\_level, daysToManufacture: product.days\_to\_manufacture, size: product.size, sizeUnitMeasureCode: product.size\_unit\_measure\_code, weight: product.weight, weightUnitMeasureCode: product.weight\_unit\_measure\_code, daysToManufacture: product.days\_to\_manufacture, images: (product.images splitBy "," default null), modifiedDate: (product.modified\_date default "") as Date {format: "yyyy-MM-dd"}, createdDate: (product.created\_date default "") as Date {format: "yyyy-MM-dd"} } 7. 最後に、DW 2.0 変換を使用して、ペイロードを設定する ​`Transform component`​ を追加します。 ```xml ``` Studio 7 の get-product-by-id-flow の設定 XML。 ```xml SELECT p.id, p.name, p.description, p.product_number, p.manufactured, p.colors, p.categories, p.stock, p.safety_stock_level, p.standard_cost, p.list_price, p.size, p.size_unit_measure_code, p.weight, p.weight_unit_measure_code, p.days_to_manufacture, p.images, p.modified_date, p.created_date FROM product p where p.id = :id ``` ![Source、Transform Message、Error handling などのコンポーネントが含まれる、ID による GET 要求が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m4-apikit-based-example-get-product-by-id-flow.png) Figure 4. Studio 7 の get-product-by-id-flow ## [](#post-product-flow-の移行)_post-product-flow_​ の移行 `post-product-flow`​ はデータベースに商品を挿入します。 ![Source、Transactional、Error handling などのコンポーネントが含まれる、商品を投稿するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-post-product-flow.png) Figure 5. Studio 6 の post-product-flow Studio 6 の post-product-flow の設定 XML。 ```xml ``` 1. `post-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. JSON 要求を JAVA マップに変換するために、​`src/main/resources/mappings`​ フォルダーに ​`json-to-java.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- payload 3. `src/main/resources/mappings`​ に ​`json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, (manufactured: 1) when payload.manufactured == true, (manufactured: 0) when payload.manufactured == false, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の json-product-to-java.dwl の変換。 %dw 2.0 output application/java fun getManufacturedCode(value) = if (value == true) 1 else 0 --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: getManufacturedCode(payload.manufactured), name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 4. 前に作成した DataWeave 変換を使用して ​`originalPayload`​ と ​`newPayload`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 5. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 6. `Try scope`​ に ​`db:insert`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。データベースエンジンによって自動生成された ​`ID`​ を持つペイロードを設定する ​`db:auto-generated-keys-column-name`​ タグも含まれています。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` 7. `src/main/resources/mappings`​ に ​`post-product-response.dwl`​ ファイルを作成し、応答変換を DataWeave 1.0 から 2.0 に移行します。式 ​`payload.generatedKeys.GENERATED_KEY`​ を使用してペイロードから生成された ​`id`​ を取得するという違いがあります。 DW 1.0 の post-product-response.dwl の変換。 %dw 1.0 %output application/json --- flowVars.originalPayload ++ id: payload\[0\].GENERATED\_KEY DW 2.0 の post-product-response.dwl の変換。 %dw 2.0 output application/json --- vars.originalPayload ++ id: payload.generatedKeys.GENERATED\_KEY 8. `Transform component`​ を追加し、ペイロードを DataWeave スクリプトで設定します。 ```xml ``` Studio 7 の post-product-flow の設定 XML。 ```xml insert into product(name, description, product_number, manufactured, colors, categories, stock, safety_stock_level, standard_cost, list_price, size, size_unit_measure_code, weight, weight_unit_measure_code, days_to_manufacture, images, modified_date, created_date) values(:name, :description, :product_number, :manufactured, :colors, :categories, :stock, :safety_stock_level, :standard_cost, :list_price, :size, :size_unit_measure_code, :weight, :weight_unit_measure_code, :days_to_manufacture, :images, CURDATE(), CURDATE()); ``` ![JSON 変換やデータベース操作が含まれる、新しい商品を投稿するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m4-apikit-based-example-post-product-flow.png) Figure 6. Studio 7 の post-product-flow ## [](#put-product-flow-の移行)_put-product-flow_​ の移行 `put-product-flow`​ は指定された ​`id`​ に基づいてデータベース内の商品を更新します。 ![トランザクションエラー処理や状況の更新が含まれる、商品を更新するフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-put-product-flow.png) Figure 7. Studio 6 の put-product-flow Studio 6 の put-product-flow の設定 XML。 ```xml ``` 1. `put-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `src/main/resources/mappings`​ フォルダーに ​`put-json-product-to-java.dwl`​ ファイルを作成し、元のスクリプトを DW 1.0 から 2.0 に移行します。 DW 1.0 の put-json-product-to-java.dwl の変換。 %dw 1.0 %output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } DW 2.0 の put-json-product-to-java.dwl の変換。 %dw 2.0 output application/java --- { categories: payload.categories joinBy ",", colors: payload.colors joinBy ",", daysToManufacture: payload.daysToManufacture, description: payload.description, images: payload.images joinBy ",", listPrice: payload.listPrice, manufactured: payload.manufactured, name: payload.name, productNumber: payload.productNumber, safetyStockLevel: payload.safetyStockLevel, size: payload.size, sizeUnitMeasureCode: payload.sizeUnitMeasureCode, standardCost: payload.standardCost, stock: payload.stock, weight: payload.weight, weightUnitMeasureCode: payload.weightUnitMeasureCode } 3. 前に作成した DataWeave 変換を使用する ​`updatePayload`​ と、​`variables/set-productId-variable.dwl`​ スクリプトを使用する ​`id`​ を設定する ​`Transform component`​ を追加します。 ```xml ``` 4. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 5. `Try scope`​ に ​`db:update`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` 6. `Transform component`​ を追加し、​`src/main/resources/variables`​ にある ​`set-httpStatus-with-204.dwl`​ ファイルを使用して ​`httpStatus`​ 変数に ​`204`​ を設定します。 ```xml ``` Studio 7 の put-product-flow の設定 XML。 ```xml update product set name = :name, description = :description, product_number = :product_number, manufactured = :manufactured, colors = :colors, categories= :categories, stock = :stock, safety_stock_level = :safety_stock_level, standard_cost = :standard_cost, list_price = :list_price, size = :size, size_unit_measure_code = :size_unit_measure_code, weight = :weight, weight_unit_measure_code = :weight_unit_measure_code, days_to_manufacture = :days_to_manufacture, images = :images, modified_date = CURDATE() where id = :id ``` ![JSON 変換や状況の設定が含まれる、商品を更新するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m4-apikit-based-example-put-product-flow.png) Figure 8. Studio 7 の put-product-flow ## [](#delete-product-flow-の移行)_delete-product-flow_​ の移行 `delete-product-flow`​ は ​`URI parameter`​ として指定された ​`id`​ を持つ商品レコードを MySQL データベースから削除し、HTTP 204 状況コードを返します。 ![Source、Transactional、Error handling などのコンポーネントが含まれる、商品を削除するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m3-apikit-based-example-delete-product-flow.png) Figure 9. Studio 6 の delete-product-flow Studio 6 の delete-product-flow の設定 XML。 ```xml ``` 1. `delete-product-flow`​ の定義に関する変更はありません。 ```xml ``` 2. `productId`​ 値を ​`URI parameter`​ として受け取る変数を設定する DW スクリプトを参照する ​`Transform component`​ を追加します。 ```xml ``` 3. トランザクションの詳細を設定するために、Mule 3.x の ​`transactional`​ スコープを新しい ​`try`​ スコープに置き換え、​`transactionalAction`​ 属性を ​`ALWAYS_BEGIN`​ に設定します。 ```xml ``` 4. `Try scope`​ に ​`db:delete`​ 要素を追加し、MySQL グローバル設定を参照します。パラメーターは、​`db:input-parameters`​ 要素内のキー - 値ペアとして指定する必要があります。Mule 3.x とは逆に、前に定義した ​`productId`​ フロー変数には、​`flowVars.productId`​ ではなく ​`vars.productId`​ としてアクセスする必要があります。 ```xml delete from product where id=:productId ``` 5. 次のように ​`src/main/resources/variables`​ に ​`set-httpStatus-with-204.dwl`​ ファイルを作成します。 %dw 2.0 output application/java --- 204 6. `NO CONTENT`​ 応答コードを定義するために、​`Transform Component`​ を使用して値 ​`204`​ を持つ ​`httpStatus`​ 変数を設定します。 ```xml ``` 特定の HTTP 状況コードを返すには、​`http.status`​ プロパティを設定する代わりに、Mule 4 の APIkit で ​`httpStatus`​ という名前の変数を設定する必要があります。 Studio 7 の delete-product-flow の設定 XML。 ```xml delete from product where id=:productId ``` ![エラー処理や HTTP 状況の設定が含まれる、商品を削除するプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/m4-apikit-based-example-delete-product-flow.png) Figure 10. Studio 7 の delete-product-flow ## [](#バックエンドフローの移行)バックエンドフローの移行 バックエンドフローの移行方法 APIkit によって生成された各バックエンドフローの実装に ​`flow-ref`​ を追加します。 \+ .Studio 6 のバックエンドフローの設定 XML。 ```xml ``` + \+ .Studio 7 のバックエンドフローの設定 XML。 ```xml ``` ## [](#デフォルトの-apikit-グローバル例外戦略の拡張)デフォルトの APIkit グローバル例外戦略の拡張 1. `APP:NOT_FOUND`​ 例外種別を ApiKit で生成された 404 マッピングに追加し、​`get-product-by-id-flow`​ の ​`validation:is-true`​ 要素によってスローされた例外を処理します。特定の状況コードにマップするその他のエラーに対してこのプロセスを繰り返すことができます。 Studio 6 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` Studio 7 の ApiKit による 404 へのマッピングの設定 XML。 ```xml ``` 2. まだ管理されていないすべての例外に、汎用の ApiKit による 500 へのマッピングを追加します。 Studio 6 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` Studio 7 の汎用の ApiKit による 500 へのマッピングの設定 XML。 ```xml ``` # Async スコープ Async スコープは、メインフローと同時に実行される分岐処理ブロックです。メインフローは、Async スコープの開始中や処理中に実行され続けます。非同期フローに埋め込まれた最後のメッセージプロセッサーがタスクを完了するまで、フローは一時停止する必要はありません。 Async は、応答を開始フローに返信する必要がない、時間のかかる操作 (ファイルの印刷やメールサーバーへの接続など) を実行する場合に役立ちます。 同時分岐処理を容易にするため、Async スコープは受信したメッセージの 1 つのコピーを独自の処理ブロック内にある最初の埋め込みメッセージプロセッサーに送信します。同時に、メインフロー内の次のメッセージプロセッサーにメッセージの別のコピーを送信します。 ![Async + スコープ + 概略図](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/async-scope-schematic.png) Async スコープは「ファイヤアンドフォゲット」方式で実行されるため、スコープ内の処理の結果はメインフローでは使用できません。 ## [](#async-の設定)Async の設定 Async スコープは設定できます。
項目 説明

Display Name (表示名) (​name​)

Async スコープの名前。

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。スコープが処理できる同時メッセージの最大数を設定します。デフォルトでは、メッセージの処理時にパフォーマンスを最適化するために使用される最大スレッド数は、コンテナスレッドプールによって異なります。スコープが最大数の同時メッセージを処理している間は追加要求を受信できません。

スコープが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャーの管理​」を参照してください。
## [](#async-スコープとサブフローの比較)Async スコープとサブフローの比較 Async スコープは、次の点でサブフローと異なります。 - メインフローの例外戦略を継承しない。 Async スコープでエラーを処理するには、Try スコープを使用する。 - メッセージを非同期的に処理する。 - データをメインフローに渡さない。 - メインフロースレッドの範囲内に存在する。 - Flow Reference コンポーネントからはコールされない。 - 再利用できない。 Async スコープが Mule メッセージのコピーを受信しても、ペイロードはコピーされません。同じペイロードオブジェクトが両方の Mule メッセージによって参照されます。そのメッセージの 1 つは元のフローに沿って進み続け、もう 1 つは Async スコープによって処理されます。 つまり、メッセージのペイロードが可変オブジェクト (異なる項目が含まれる Bean など) であり、Async スコープ内のメッセージプロセッサーがいずれかの項目の値を変更した場合、Async スコープ外部のメッセージプロセッサーが変更された値を参照できます。 ## [](#async-スコープの設定例)Async スコープの設定例 次の XML フラグメントは、アプリケーションフローでの Async スコープの設定例を示しています。Async スコープにある ​`file:read`​ 操作は、トリガーされると非同期に実行され、アプリケーションはフローの次の操作である ​`http:request`​ の処理に移ります。 ```xml ... ... ``` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management#tx_scopes_routers) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-backpressure-maxconcurrency) # Async スコープ Async スコープは、メインフローと同時に実行される分岐処理ブロックです。メインフローは、Async スコープの開始中や処理中に実行され続けます。非同期フローに埋め込まれた最後のメッセージプロセッサーがタスクを完了するまで、フローは一時停止する必要はありません。 Async は、応答を開始フローに返信する必要がない、時間のかかる操作 (ファイルの印刷やメールサーバーへの接続など) を実行する場合に役立ちます。 同時分岐処理を容易にするため、Async スコープは受信したメッセージの 1 つのコピーを独自の処理ブロック内にある最初の埋め込みメッセージプロセッサーに送信します。同時に、メインフロー内の次のメッセージプロセッサーにメッセージの別のコピーを送信します。 ![Async + スコープ + 概略図](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/async-scope-schematic.png) Async スコープは「ファイヤアンドフォゲット」方式で実行されるため、スコープ内の処理の結果はメインフローでは使用できません。 ## [](#async-の設定)Async の設定 Async スコープは設定できます。
項目 説明

Display Name (表示名) (​name​)

Async スコープの名前。

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。スコープが処理できる同時メッセージの最大数を設定します。デフォルトでは、メッセージの処理時にパフォーマンスを最適化するために使用される最大スレッド数は、コンテナスレッドプールによって異なります。スコープが最大数の同時メッセージを処理している間は追加要求を受信できません。

スコープが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャーの管理​」を参照してください。
## [](#async-スコープとサブフローの比較)Async スコープとサブフローの比較 Async スコープは、次の点でサブフローと異なります。 - メインフローの例外戦略を継承しない。 Async スコープでエラーを処理するには、Try スコープを使用する。 - メッセージを非同期的に処理する。 - データをメインフローに渡さない。 - メインフロースレッドの範囲内に存在する。 - Flow Reference コンポーネントからはコールされない。 - 再利用できない。 Async スコープが Mule メッセージのコピーを受信しても、ペイロードはコピーされません。同じペイロードオブジェクトが両方の Mule メッセージによって参照されます。そのメッセージの 1 つは元のフローに沿って進み続け、もう 1 つは Async スコープによって処理されます。 つまり、メッセージのペイロードが可変オブジェクト (異なる項目が含まれる Bean など) であり、Async スコープ内のメッセージプロセッサーがいずれかの項目の値を変更した場合、Async スコープ外部のメッセージプロセッサーが変更された値を参照できます。 ## [](#async-スコープの設定例)Async スコープの設定例 次の XML フラグメントは、アプリケーションフローでの Async スコープの設定例を示しています。Async スコープにある ​`file:read`​ 操作は、トリガーされると非同期に実行され、アプリケーションはフローの次の操作である ​`http:request`​ の処理に移ります。 ```xml ... ... ``` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management#tx_scopes_routers) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-backpressure-maxconcurrency) # Async スコープ Async スコープは、メインフローと同時に実行される分岐処理ブロックです。メインフローは、Async スコープの開始中や処理中に実行され続けます。非同期フローに埋め込まれた最後のメッセージプロセッサーがタスクを完了するまで、フローは一時停止する必要はありません。 Async は、応答を開始フローに返信する必要がない、時間のかかる操作 (ファイルの印刷やメールサーバーへの接続など) を実行する場合に役立ちます。 同時分岐処理を容易にするため、Async スコープは受信したメッセージの 1 つのコピーを独自の処理ブロック内にある最初の埋め込みメッセージプロセッサーに送信します。同時に、メインフロー内の次のメッセージプロセッサーにメッセージの別のコピーを送信します。 ![Async + スコープ + 概略図](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/async-scope-schematic.png) Async スコープは「ファイヤアンドフォゲット」方式で実行されるため、スコープ内の処理の結果はメインフローでは使用できません。 ## [](#async-の設定)Async の設定 Async スコープは設定できます。
項目 説明

Display Name (表示名) (​name​)

Async スコープの名前。

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。スコープが処理できる同時メッセージの最大数を設定します。デフォルトでは、メッセージの処理時にパフォーマンスを最適化するために使用される最大スレッド数は、コンテナスレッドプールによって異なります。スコープが最大数の同時メッセージを処理している間は追加要求を受信できません。

スコープが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャーの管理​」を参照してください。
## [](#async-スコープとサブフローの比較)Async スコープとサブフローの比較 Async スコープは、次の点でサブフローと異なります。 - メインフローの例外戦略を継承しない。 Async スコープでエラーを処理するには、Try スコープを使用する。 - メッセージを非同期的に処理する。 - データをメインフローに渡さない。 - メインフロースレッドの範囲内に存在する。 - Flow Reference コンポーネントからはコールされない。 - 再利用できない。 Async スコープが Mule メッセージのコピーを受信しても、ペイロードはコピーされません。同じペイロードオブジェクトが両方の Mule メッセージによって参照されます。そのメッセージの 1 つは元のフローに沿って進み続け、もう 1 つは Async スコープによって処理されます。 つまり、メッセージのペイロードが可変オブジェクト (異なる項目が含まれる Bean など) であり、Async スコープ内のメッセージプロセッサーがいずれかの項目の値を変更した場合、Async スコープ外部のメッセージプロセッサーが変更された値を参照できます。 ## [](#async-スコープの設定例)Async スコープの設定例 次の XML フラグメントは、アプリケーションフローでの Async スコープの設定例を示しています。Async スコープにある ​`file:read`​ 操作は、トリガーされると非同期に実行され、アプリケーションはフローの次の操作である ​`http:request`​ の処理に移ります。 ```xml ... ... ``` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management#tx_scopes_routers) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-backpressure-maxconcurrency) # Async スコープ Async スコープは、メインフローと同時に実行される分岐処理ブロックです。メインフローは、Async スコープの開始中や処理中に実行され続けます。非同期フローに埋め込まれた最後のメッセージプロセッサーがタスクを完了するまで、フローは一時停止する必要はありません。 Async は、応答を開始フローに返信する必要がない、時間のかかる操作 (ファイルの印刷やメールサーバーへの接続など) を実行する場合に役立ちます。 同時分岐処理を容易にするため、Async スコープは受信したメッセージの 1 つのコピーを独自の処理ブロック内にある最初の埋め込みメッセージプロセッサーに送信します。同時に、メインフロー内の次のメッセージプロセッサーにメッセージの別のコピーを送信します。 ![Async + スコープ + 概略図](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/async-scope-schematic.png) Async スコープは「ファイヤアンドフォゲット」方式で実行されるため、スコープ内の処理の結果はメインフローでは使用できません。 ## [](#async-の設定)Async の設定 Async スコープは設定できます。
項目 説明

Display Name (表示名) (​name​)

Async スコープの名前。

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。スコープが処理できる同時メッセージの最大数を設定します。デフォルトでは、メッセージの処理時にパフォーマンスを最適化するために使用される最大スレッド数は、コンテナスレッドプールによって異なります。スコープが最大数の同時メッセージを処理している間は追加要求を受信できません。

スコープが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャーの管理​」を参照してください。
## [](#async-スコープとサブフローの比較)Async スコープとサブフローの比較 Async スコープは、次の点でサブフローと異なります。 - メインフローの例外戦略を継承しない。 Async スコープでエラーを処理するには、Try スコープを使用する。 - メッセージを非同期的に処理する。 - データをメインフローに渡さない。 - メインフロースレッドの範囲内に存在する。 - Flow Reference コンポーネントからはコールされない。 - 再利用できない。 Async スコープが Mule メッセージのコピーを受信しても、ペイロードはコピーされません。同じペイロードオブジェクトが両方の Mule メッセージによって参照されます。そのメッセージの 1 つは元のフローに沿って進み続け、もう 1 つは Async スコープによって処理されます。 つまり、メッセージのペイロードが可変オブジェクト (異なる項目が含まれる Bean など) であり、Async スコープ内のメッセージプロセッサーがいずれかの項目の値を変更した場合、Async スコープ外部のメッセージプロセッサーが変更された値を参照できます。 ## [](#async-スコープの設定例)Async スコープの設定例 次の XML フラグメントは、アプリケーションフローでの Async スコープの設定例を示しています。Async スコープにある ​`file:read`​ 操作は、トリガーされると非同期に実行され、アプリケーションはフローの次の操作である ​`http:request`​ の処理に移ります。 ```xml ... ... ``` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management#tx_scopes_routers) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-backpressure-maxconcurrency) # Async スコープ Async スコープは、メインフローと同時に実行される分岐処理ブロックです。メインフローは、Async スコープの開始中や処理中に実行され続けます。非同期フローに埋め込まれた最後のメッセージプロセッサーがタスクを完了するまで、フローは一時停止する必要はありません。 Async は、応答を開始フローに返信する必要がない、時間のかかる操作 (ファイルの印刷やメールサーバーへの接続など) を実行する場合に役立ちます。 同時分岐処理を容易にするため、Async スコープは受信したメッセージの 1 つのコピーを独自の処理ブロック内にある最初の埋め込みメッセージプロセッサーに送信します。同時に、メインフロー内の次のメッセージプロセッサーにメッセージの別のコピーを送信します。 ![スコープ内の組み込み非同期処理ブロック](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/async-scope-schematic.png) Async スコープは「ファイヤアンドフォゲット」方式で実行されるため、スコープ内の処理の結果はメインフローでは使用できません。 ## [](#async-の設定)Async の設定 Async スコープは設定できます。
項目 説明

Display Name (表示名) (​name​)

Async スコープの名前。

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。スコープが処理できる同時メッセージの最大数を設定します。デフォルトでは、メッセージの処理時にパフォーマンスを最適化するために使用される最大スレッド数は、コンテナスレッドプールによって異なります。スコープが最大数の同時メッセージを処理している間は追加要求を受信できません。

スコープが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャーの管理​」を参照してください。
## [](#async-スコープとサブフローの比較)Async スコープとサブフローの比較 Async スコープは、次の点でサブフローと異なります。 - メインフローの例外戦略を継承しない。 Async スコープでエラーを処理するには、Try スコープを使用する。 - メッセージを非同期的に処理する。 - データをメインフローに渡さない。 - メインフロースレッドの範囲内に存在する。 - Flow Reference コンポーネントからはコールされない。 - 再利用できない。 Async スコープが Mule メッセージのコピーを受信しても、ペイロードはコピーされません。同じペイロードオブジェクトが両方の Mule メッセージによって参照されます。そのメッセージの 1 つは元のフローに沿って進み続け、もう 1 つは Async スコープによって処理されます。 つまり、メッセージのペイロードが可変オブジェクト (異なる項目が含まれる Bean など) であり、Async スコープ内のメッセージプロセッサーがいずれかの項目の値を変更した場合、Async スコープ外部のメッセージプロセッサーが変更された値を参照できます。 ## [](#async-スコープの設定例)Async スコープの設定例 次の XML フラグメントは、アプリケーションフローでの Async スコープの設定例を示しています。Async スコープにある ​`file:read`​ 操作は、トリガーされると非同期に実行され、アプリケーションはフローの次の操作である ​`http:request`​ の処理に移ります。 ```xml ... ... ``` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management#tx_scopes_routers) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-backpressure-maxconcurrency) # Async スコープ Async スコープは、メインフローと同時に実行される分岐処理ブロックです。メインフローは、Async スコープの開始中や処理中に実行され続けます。非同期フローに埋め込まれた最後のメッセージプロセッサーがタスクを完了するまで、フローは一時停止する必要はありません。 Async は、応答を開始フローに返信する必要がない、時間のかかる操作 (ファイルの印刷やメールサーバーへの接続など) を実行する場合に役立ちます。 同時分岐処理を容易にするため、Async スコープは受信したメッセージの 1 つのコピーを独自の処理ブロック内にある最初の埋め込みメッセージプロセッサーに送信します。同時に、メインフロー内の次のメッセージプロセッサーにメッセージの別のコピーを送信します。 ![スコープ内の組み込み非同期処理ブロック](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/async-scope-schematic.png) Async スコープは「ファイヤアンドフォゲット」方式で実行されるため、スコープ内の処理の結果はメインフローでは使用できません。 ## [](#async-の設定)Async の設定 Async スコープは設定できます。
項目 説明

Display Name (表示名) (​name​)

Async スコープの名前。

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。スコープが処理できる同時メッセージの最大数を設定します。デフォルトでは、メッセージの処理時にパフォーマンスを最適化するために使用される最大スレッド数は、コンテナスレッドプールによって異なります。スコープが最大数の同時メッセージを処理している間は追加要求を受信できません。

スコープが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャーの管理​」を参照してください。
## [](#async-スコープとサブフローの比較)Async スコープとサブフローの比較 Async スコープは、次の点でサブフローと異なります。 - メインフローの例外戦略を継承しない。 Async スコープでエラーを処理するには、Try スコープを使用する。 - メッセージを非同期的に処理する。 - データをメインフローに渡さない。 - メインフロースレッドの範囲内に存在する。 - Flow Reference コンポーネントからはコールされない。 - 再利用できない。 Async スコープが Mule メッセージのコピーを受信しても、ペイロードはコピーされません。同じペイロードオブジェクトが両方の Mule メッセージによって参照されます。そのメッセージの 1 つは元のフローに沿って進み続け、もう 1 つは Async スコープによって処理されます。 つまり、メッセージのペイロードが可変オブジェクト (異なる項目が含まれる Bean など) であり、Async スコープ内のメッセージプロセッサーがいずれかの項目の値を変更した場合、Async スコープ外部のメッセージプロセッサーが変更された値を参照できます。 ## [](#async-スコープの設定例)Async スコープの設定例 次の XML フラグメントは、アプリケーションフローでの Async スコープの設定例を示しています。Async スコープにある ​`file:read`​ 操作は、トリガーされると非同期に実行され、アプリケーションはフローの次の操作である ​`http:request`​ の処理に移ります。 ```xml ... ... ``` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management#tx_scopes_routers) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-backpressure-maxconcurrency) # Async スコープ Async スコープは、メインフローと同時に実行される分岐処理ブロックです。メインフローは、Async スコープの開始中や処理中に実行され続けます。非同期フローに埋め込まれた最後のメッセージプロセッサーがタスクを完了するまで、フローは一時停止する必要はありません。 Async は、応答を開始フローに返信する必要がない、時間のかかる操作 (ファイルの印刷やメールサーバーへの接続など) を実行する場合に役立ちます。 同時分岐処理を容易にするため、Async スコープは受信したメッセージの 1 つのコピーを独自の処理ブロック内にある最初の埋め込みメッセージプロセッサーに送信します。同時に、メインフロー内の次のメッセージプロセッサーにメッセージの別のコピーを送信します。 ![スコープ内の組み込み非同期処理ブロック](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/async-scope-schematic.png) Async スコープは「ファイヤアンドフォゲット」方式で実行されるため、スコープ内の処理の結果はメインフローでは使用できません。 ## [](#async-の設定)Async の設定 Async スコープは設定できます。
項目 説明

Display Name (表示名) (​name​)

Async スコープの名前。

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。スコープが処理できる同時メッセージの最大数を設定します。デフォルトでは、メッセージの処理時にパフォーマンスを最適化するために使用される最大スレッド数は、コンテナスレッドプールによって異なります。スコープが最大数の同時メッセージを処理している間は追加要求を受信できません。

スコープが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャーの管理​」を参照してください。
## [](#async-スコープとサブフローの比較)Async スコープとサブフローの比較 Async スコープは、次の点でサブフローと異なります。 - メインフローの例外戦略を継承しない。 Async スコープでエラーを処理するには、Try スコープを使用する。 - メッセージを非同期的に処理する。 - データをメインフローに渡さない。 - メインフロースレッドの範囲内に存在する。 - Flow Reference コンポーネントからはコールされない。 - 再利用できない。 Async スコープが Mule メッセージのコピーを受信しても、ペイロードはコピーされません。同じペイロードオブジェクトが両方の Mule メッセージによって参照されます。そのメッセージの 1 つは元のフローに沿って進み続け、もう 1 つは Async スコープによって処理されます。 つまり、メッセージのペイロードが可変オブジェクト (異なる項目が含まれる Bean など) であり、Async スコープ内のメッセージプロセッサーがいずれかの項目の値を変更した場合、Async スコープ外部のメッセージプロセッサーが変更された値を参照できます。 ## [](#async-スコープの設定例)Async スコープの設定例 次の XML フラグメントは、アプリケーションフローでの Async スコープの設定例を示しています。Async スコープにある ​`file:read`​ 操作は、トリガーされると非同期に実行され、アプリケーションはフローの次の操作である ​`http:request`​ の処理に移ります。 ```xml ... ... ``` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management#tx_scopes_routers) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-backpressure-maxconcurrency) # back-pressure と maxConcurrency 負荷が大きい場合、Mule Runtime Engine (Mule) が特定のイベントを処理するために使用可能なリソースがないことがあります。この問題は、すべてのスレッドが使用中で現在のフローの同時実行数を超えている場合に発生します。この場合、Mule は次のメッセージをログに記録します。 ​`Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。 このメッセージはバックプレッシャーと呼ばれます。Mule のバックプレッシャーアクションは、各コネクタの取得元に固有です。 コンシューマーコンポーネントが情報を処理できるレートより、プロデューサーコンポーネントが情報を出力するレートの方が高い場合は、​`maxConcurrency`​ パラメーターを使用して、コンポーネントが内部または外部であるか、フローまたはソースであるか、などに応じて、フローが同時に処理できるメッセージの最大数を設定します。 Mule ではバックプレッシャーを独自に適用していますが、​`maxConcurrency`​ パラメーターを使用することで、特に同時実行数が増える原因がバックエンドサーバーにある場合に、フローのパフォーマンスを制御できます。次の例にパラメーターの設定方法を示します。 ```xml ``` 同様に、​`maxConcurrency`​ パラメーターを次のように使用することで、バッチジョブで処理できるレコード数を制限できます。 ```xml ``` デフォルトでは、Flow スコープと Async スコープでは ​`maxConcurrency`​ の制限は設定されていませんが、Batch Job コンポーネントでは使用できるコア数の 2 倍に同時実行数が制限されています。同時実行数は、システムのキャパシティによっても制限されます。 ## [](#max-concurrency-最大同時実行-設定があるコンポーネント)Max Concurrency (最大同時実行) 設定があるコンポーネント 次の​[コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-components)​には最大同時実行の設定があります。 - Flow スコープ - Scatter-Gather ルーター - Async スコープ - Batch Job スコープ - Parallel For Each スコープ ## [](#推奨事項)推奨事項 同時実行を減らしてバックプレッシャーイベントを人為的にトリガーする必要がある場合を除き、デフォルト設定を使用してください。また、最大同時実行値を変更しないでください。 ## [](#関連情報)関連情報 - [実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-engine) # back-pressure と maxConcurrency 負荷が大きい場合、Mule Runtime Engine (Mule) が特定のイベントを処理するために使用可能なリソースがないことがあります。この問題は、すべてのスレッドが使用中で現在のフローの同時実行数を超えている場合に発生します。この場合、Mule は次のメッセージをログに記録します。 ​`Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。 このメッセージはバックプレッシャーと呼ばれます。Mule のバックプレッシャーアクションは、各コネクタの取得元に固有です。 コンシューマーコンポーネントが情報を処理できるレートより、プロデューサーコンポーネントが情報を出力するレートの方が高い場合は、​`maxConcurrency`​ パラメーターを使用して、コンポーネントが内部または外部であるか、フローまたはソースであるか、などに応じて、フローが同時に処理できるメッセージの最大数を設定します。 Mule ではバックプレッシャーを独自に適用していますが、​`maxConcurrency`​ パラメーターにを使用することで、特に同時実行数が増える原因がバックエンドサーバーにある場合に、フローのパフォーマンスを制御できます。次の例にパラメーターの設定方法を示します。 ```xml ``` 同様に、​`maxConcurrency`​ パラメーターを次のように使用することで、バッチジョブで処理できるレコード数を制限できます。 ```xml ``` デフォルトでは、Flow スコープと Async スコープでは ​`maxConcurrency`​ の制限は設定されていませんが、Batch Job コンポーネントでは使用できるコア数の 2 倍に同時実行数が制限されています。同時実行数は、システムのキャパシティによっても制限されます。 ## [](#max-concurrency-最大同時実行-設定があるコンポーネント)Max Concurrency (最大同時実行) 設定があるコンポーネント 次の​[コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-components)​には最大同時実行の設定があります。 - Flow スコープ - Scatter-Gather ルーター - Async スコープ - Batch Job スコープ - Parallel For Each スコープ ## [](#推奨事項)推奨事項 同時実行を減らしてバックプレッシャーイベントを人為的にトリガーする必要がある場合を除き、デフォルト設定を使用してください。また、最大同時実行値を変更しないでください。 ## [](#関連情報)関連情報 - [実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-engine) # back-pressure と maxConcurrency 負荷が大きい場合、Mule Runtime Engine (Mule) が特定のイベントを処理するために使用可能なリソースがないことがあります。この問題は、すべてのスレッドが使用中で現在のフローの同時実行数を超えている場合に発生します。この場合、Mule は次のメッセージをログに記録します。 ​`Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。 このメッセージはバックプレッシャーと呼ばれます。Mule のバックプレッシャーアクションは、各コネクタの取得元に固有です。 コンシューマーコンポーネントが情報を処理できるレートより、プロデューサーコンポーネントが情報を出力するレートの方が高い場合は、​`maxConcurrency`​ パラメーターを使用して、コンポーネントが内部または外部であるか、フローまたはソースであるか、などに応じて、フローが同時に処理できるメッセージの最大数を設定します。 Mule ではバックプレッシャーを独自に適用していますが、​`maxConcurrency`​ パラメーターを使用することで、特に同時実行数が増える原因がバックエンドサーバーにある場合に、フローのパフォーマンスを制御できます。次の例にパラメーターの設定方法を示します。 ```xml ``` 同様に、​`maxConcurrency`​ パラメーターを次のように使用することで、バッチジョブで処理できるレコード数を制限できます。 ```xml ``` デフォルトでは、Flow スコープと Async スコープでは ​`maxConcurrency`​ の制限は設定されていませんが、Batch Job コンポーネントでは使用できるコア数の 2 倍に同時実行数が制限されています。同時実行数は、システムのキャパシティによっても制限されます。 ## [](#max-concurrency-最大同時実行-設定があるコンポーネント)Max Concurrency (最大同時実行) 設定があるコンポーネント 次の​[コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-components)​には最大同時実行の設定があります。 - Flow スコープ - Scatter-Gather ルーター - Async スコープ - Batch Job スコープ - Parallel For Each スコープ ## [](#推奨事項)推奨事項 同時実行を減らしてバックプレッシャーイベントを人為的にトリガーする必要がある場合を除き、デフォルト設定を使用してください。また、最大同時実行値を変更しないでください。 ## [](#関連情報)関連情報 - [実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-engine) # back-pressure と maxConcurrency 負荷が大きい場合、Mule Runtime Engine (Mule) が特定のイベントを処理するために使用可能なリソースがないことがあります。この問題は、すべてのスレッドが使用中で現在のフローの同時実行数を超えている場合に発生します。この場合、Mule は次のメッセージをログに記録します。 ​`Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。 このメッセージはバックプレッシャーと呼ばれます。Mule のバックプレッシャーアクションは、各コネクタの取得元に固有です。 コンシューマーコンポーネントが情報を処理できるレートより、プロデューサーコンポーネントが情報を出力するレートの方が高い場合は、​`maxConcurrency`​ パラメーターを使用して、コンポーネントが内部または外部であるか、フローまたはソースであるか、などに応じて、フローが同時に処理できるメッセージの最大数を設定します。 Mule ではバックプレッシャーを独自に適用していますが、​`maxConcurrency`​ パラメーターを使用することで、特に同時実行数が増える原因がバックエンドサーバーにある場合に、フローのパフォーマンスを制御できます。次の例にパラメーターの設定方法を示します。 ```xml ``` 同様に、​`maxConcurrency`​ パラメーターを次のように使用することで、バッチジョブで処理できるレコード数を制限できます。 ```xml ``` デフォルトでは、Flow スコープと Async スコープでは ​`maxConcurrency`​ の制限は設定されていませんが、Batch Job コンポーネントでは使用できるコア数の 2 倍に同時実行数が制限されています。同時実行数は、システムのキャパシティによっても制限されます。 ## [](#max-concurrency-最大同時実行-設定があるコンポーネント)Max Concurrency (最大同時実行) 設定があるコンポーネント 次の​[コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-components)​には最大同時実行の設定があります。 - Flow スコープ - Scatter-Gather ルーター - Async スコープ - Batch Job スコープ - Parallel For Each スコープ ## [](#推奨事項)推奨事項 同時実行を減らしてバックプレッシャーイベントを人為的にトリガーする必要がある場合を除き、デフォルト設定を使用してください。また、最大同時実行値を変更しないでください。 ## [](#関連情報)関連情報 - [実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-engine) # back-pressure と maxConcurrency 負荷が大きい場合、Mule Runtime Engine (Mule) が特定のイベントを処理するために使用可能なリソースがないことがあります。この問題は、すべてのスレッドが使用中で現在のフローの同時実行数を超えている場合に発生します。この場合、Mule は次のメッセージをログに記録します。 ​`Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。 このメッセージはバックプレッシャーと呼ばれます。Mule のバックプレッシャーアクションは、各コネクタの取得元に固有です。 コンシューマーコンポーネントが情報を処理できるレートより、プロデューサーコンポーネントが情報を出力するレートの方が高い場合は、​`maxConcurrency`​ パラメーターを使用して、コンポーネントが内部または外部であるか、フローまたはソースであるか、などに応じて、フローが同時に処理できるメッセージの最大数を設定します。 Mule ではバックプレッシャーを独自に適用していますが、​`maxConcurrency`​ パラメーターを使用することで、特に同時実行数が増える原因がバックエンドサーバーにある場合に、フローのパフォーマンスを制御できます。次の例にパラメーターの設定方法を示します。 ```xml ``` 同様に、​`maxConcurrency`​ パラメーターを次のように使用することで、バッチジョブで処理できるレコード数を制限できます。 ```xml ``` デフォルトでは、Flow スコープと Async スコープでは ​`maxConcurrency`​ の制限は設定されていませんが、Batch Job コンポーネントでは使用できるコア数の 2 倍に同時実行数が制限されています。同時実行数は、システムのキャパシティによっても制限されます。 ## [](#max-concurrency-最大同時実行-設定があるコンポーネント)Max Concurrency (最大同時実行) 設定があるコンポーネント 次の​[コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-components)​には最大同時実行の設定があります。 - Flow スコープ - Scatter-Gather ルーター - Async スコープ - Batch Job スコープ - Parallel For Each スコープ ## [](#推奨事項)推奨事項 同時実行を減らしてバックプレッシャーイベントを人為的にトリガーする必要がある場合を除き、デフォルト設定を使用してください。また、最大同時実行値を変更しないでください。 ## [](#関連情報)関連情報 - [実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-engine) # back-pressure と maxConcurrency 負荷が大きい場合、Mule Runtime Engine (Mule) が特定のイベントを処理するために使用可能なリソースがないことがあります。この問題は、すべてのスレッドが使用中で現在のフローの同時実行数を超えている場合に発生します。この場合、Mule は次のメッセージをログに記録します。 ​`Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。 このメッセージはバックプレッシャーと呼ばれます。Mule のバックプレッシャーアクションは、各コネクタの取得元に固有です。 コンシューマーコンポーネントが情報を処理できるレートより、プロデューサーコンポーネントが情報を出力するレートの方が高い場合は、​`maxConcurrency`​ パラメーターを使用して、コンポーネントが内部または外部であるか、フローまたはソースであるか、などに応じて、フローが同時に処理できるメッセージの最大数を設定します。 Mule ではバックプレッシャーを独自に適用していますが、​`maxConcurrency`​ パラメーターを使用することで、特に同時実行数が増える原因がバックエンドサーバーにある場合に、フローのパフォーマンスを制御できます。次の例にパラメーターの設定方法を示します。 ```xml ``` 同様に、​`maxConcurrency`​ パラメーターを次のように使用することで、バッチジョブで処理できるレコード数を制限できます。 ```xml ``` デフォルトでは、Flow スコープと Async スコープでは ​`maxConcurrency`​ の制限は設定されていませんが、Batch Job コンポーネントでは使用できるコア数の 2 倍に同時実行数が制限されています。同時実行数は、システムのキャパシティによっても制限されます。 ## [](#max-concurrency-最大同時実行-設定があるコンポーネント)Max Concurrency (最大同時実行) 設定があるコンポーネント 次の​[コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-components)​には最大同時実行の設定があります。 - Flow スコープ - Scatter-Gather ルーター - Async スコープ - Batch Job スコープ - Parallel For Each スコープ ## [](#推奨事項)推奨事項 同時実行を減らしてバックプレッシャーイベントを人為的にトリガーする必要がある場合を除き、デフォルト設定を使用してください。また、最大同時実行値を変更しないでください。 ## [](#関連情報)関連情報 - [実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-engine) # back-pressure と maxConcurrency 負荷が大きい場合、Mule Runtime Engine (Mule) が特定のイベントを処理するために使用可能なリソースがないことがあります。この問題は、すべてのスレッドが使用中で現在のフローの同時実行数を超えている場合に発生します。この場合、Mule は次のメッセージをログに記録します。 ​`Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。 このメッセージはバックプレッシャーと呼ばれます。Mule のバックプレッシャーアクションは、各コネクタの取得元に固有です。 コンシューマーコンポーネントが情報を処理できるレートより、プロデューサーコンポーネントが情報を出力するレートの方が高い場合は、​`maxConcurrency`​ パラメーターを使用して、コンポーネントが内部または外部であるか、フローまたはソースであるか、などに応じて、フローが同時に処理できるメッセージの最大数を設定します。 Mule ではバックプレッシャーを独自に適用していますが、​`maxConcurrency`​ パラメーターを使用することで、特に同時実行数が増える原因がバックエンドサーバーにある場合に、フローのパフォーマンスを制御できます。次の例にパラメーターの設定方法を示します。 ```xml ``` 同様に、​`maxConcurrency`​ パラメーターを次のように使用することで、バッチジョブで処理できるレコード数を制限できます。 ```xml ``` デフォルトでは、Flow スコープと Async スコープでは ​`maxConcurrency`​ の制限は設定されていませんが、Batch Job コンポーネントでは使用できるコア数の 2 倍に同時実行数が制限されています。同時実行数は、システムのキャパシティによっても制限されます。 ## [](#max-concurrency-最大同時実行-設定があるコンポーネント)Max Concurrency (最大同時実行) 設定があるコンポーネント 次の​[コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-components)​には最大同時実行の設定があります。 - Flow スコープ - Scatter-Gather ルーター - Async スコープ - Batch Job スコープ - Parallel For Each スコープ ## [](#推奨事項)推奨事項 同時実行を減らしてバックプレッシャーイベントを人為的にトリガーする必要がある場合を除き、デフォルト設定を使用してください。また、最大同時実行値を変更しないでください。 ## [](#関連情報)関連情報 - [実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-engine) # Batch Job インスタンス ID バッチ処理のユーザーは多くの場合、Batch Job の実行フェーズ中に Batch Job のインスタンス ID を判断できる必要があります。 Batch Job インスタンス ID は次の場合に役立ちます。 - データを参照および管理するためにローカルジョブインスタンス ID を外部システムに渡す - ジョブのカスタムログを改善する - 重要なイベントに関するメールまたは SMS 通知を送信する ## [](#例)例 Mule は、キー ​`batchJobInstanceId`​ のフロー変数を使用して Batch Job インスタンス ID を公開します。そのフロー変数は、入力フェーズの最初に使用できます。フロー変数はすべてのステップおよび on-complete フェーズでも使用可能です。 ![batch job instance id c4362](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/batch-job-instance-id-c4362.png) ログ出力は次のようになります。 ```text com.mulesoft.mule.runtime.module.batch.internal.engine.DefaultBatchEngine: Created instance '7dc5cad0-ab09-11e8-a790-9801a7b055d3' for batch job 'CreateLeadsBatch' ``` ## [](#カスタム-batch-job-インスタンス-id)カスタム Batch Job インスタンス ID DataWeave 式を使用して、DW 式を取得する ​**JobInstanceId**​ 属性を渡して、各 Batch Job の一意の識別子を指定します。 定数値は Batch Job には使用できないため、DW 式が以前に参照された値を返した場合、Mule は例外をスローしてジョブインスタンスを作成しません。 ジョブインスタンス ID を設定しない場合、Mule によってインスタンスに割り当てる UUID が自動生成されます。 上記のジョブインスタンスで生成された UUID は ​`ba01e1a0-f5c7-11e4-9414-10ddb1daeb6d`​ です。このように、実際の実行と関連付けることが困難な人間が判読できない識別子となっているため、同時に複数のジョブを実行している可能性があることを考慮すると、この ID はまったく意味不明です。 ユニーク性を保証するため、次の DataWeave 式を使用してサーバーの現在の日付としてジョブ ID を定義できます。 `#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]`​。 これは、実行インスタンスに ​`Job From 15/01/16 05:23:12`​ という名前を付けます。 ```text com.mulesoft.module.batch.engine.DefaultBatchEngine: Created instance Job From 15/01/16 05:23:12 for batch job contacts-to-SFDCBatch com.mulesoft.module.batch.engine.DefaultBatchEngine: Starting input phase com.mulesoft.module.batch.engine.DefaultBatchEngine: Input phase completed com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Starting loading phase for instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Finished loading phase for instance Job From 15/01/16 05:23:12 of job contacts-to-SFDCBatch. 3 records were loaded com.mulesoft.module.batch.engine.DefaultBatchEngine: Started execution of instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' ``` 適切に識別されたインスタンスのログは読みやすくなります。 ```xml ... ... ... ``` ## [](#関連情報)関連情報 - [Batch Step 処理の絞り込み](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-filters-and-batch-aggregator) # Batch Job インスタンス ID バッチ処理のユーザーは多くの場合、Batch Job の実行フェーズ中に Batch Job のインスタンス ID を判断できる必要があります。 Batch Job インスタンス ID は次の場合に役立ちます。 - データを参照および管理するためにローカルジョブインスタンス ID を外部システムに渡す - ジョブのカスタムログを改善する - 重要なイベントに関するメールまたは SMS 通知を送信する ## [](#例)例 Mule は、キー ​`batchJobInstanceId`​ のフロー変数を使用して Batch Job インスタンス ID を公開します。そのフロー変数は、入力フェーズの最初に使用できます。フロー変数はすべてのステップおよび on-complete フェーズでも使用可能です。 ![batch job instance id c4362](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/batch-job-instance-id-c4362.png) ログ出力は次のようになります。 ```text com.mulesoft.mule.runtime.module.batch.internal.engine.DefaultBatchEngine: Created instance '7dc5cad0-ab09-11e8-a790-9801a7b055d3' for batch job 'CreateLeadsBatch' ``` ## [](#カスタム-batch-job-インスタンス-id)カスタム Batch Job インスタンス ID DataWeave 式を使用して、DW 式を取得する ​**JobInstanceId**​ 属性を渡して、各 Batch Job の一意の識別子を指定します。 定数値は Batch Job には使用できないため、DW 式が以前に参照された値を返した場合、Mule は例外をスローしてジョブインスタンスを作成しません。 ジョブインスタンス ID を設定しない場合、Mule によってインスタンスに割り当てる UUID が自動生成されます。 上記のジョブインスタンスで生成された UUID は ​`ba01e1a0-f5c7-11e4-9414-10ddb1daeb6d`​ です。このように、実際の実行と関連付けることが困難な人間が判読できない識別子となっているため、同時に複数のジョブを実行している可能性があることを考慮すると、この ID はまったく意味不明です。 ユニーク性を保証するため、次の DataWeave 式を使用してサーバーの現在の日付としてジョブ ID を定義できます。 `#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]`​。 これは、実行インスタンスに ​`Job From 15/01/16 05:23:12`​ という名前を付けます。 ```text com.mulesoft.module.batch.engine.DefaultBatchEngine: Created instance Job From 15/01/16 05:23:12 for batch job contacts-to-SFDCBatch com.mulesoft.module.batch.engine.DefaultBatchEngine: Starting input phase com.mulesoft.module.batch.engine.DefaultBatchEngine: Input phase completed com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Starting loading phase for instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Finished loading phase for instance Job From 15/01/16 05:23:12 of job contacts-to-SFDCBatch. 3 records were loaded com.mulesoft.module.batch.engine.DefaultBatchEngine: Started execution of instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' ``` 適切に識別されたインスタンスのログは読みやすくなります。 ```xml ... ... ... ``` ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-filters-and-batch-aggregator) # Batch Job インスタンス ID バッチ処理のユーザーは多くの場合、Batch Job の実行フェーズ中に Batch Job のインスタンス ID を判断できる必要があります。 Batch Job インスタンス ID は次の場合に役立ちます。 - データを参照および管理するためにローカルジョブインスタンス ID を外部システムに渡す - ジョブのカスタムログを改善する - 重要なイベントに関するメールまたは SMS 通知を送信する ## [](#例)例 Mule は、キー ​`batchJobInstanceId`​ のフロー変数を使用して Batch Job インスタンス ID を公開します。そのフロー変数は、入力フェーズの最初に使用できます。フロー変数はすべてのステップおよび on-complete フェーズでも使用可能です。 ![batch job instance id c4362](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/batch-job-instance-id-c4362.png) ログ出力は次のようになります。 ```text com.mulesoft.mule.runtime.module.batch.internal.engine.DefaultBatchEngine: Created instance '7dc5cad0-ab09-11e8-a790-9801a7b055d3' for batch job 'CreateLeadsBatch' ``` ## [](#カスタム-batch-job-インスタンス-id)カスタム Batch Job インスタンス ID DataWeave 式を使用して、DW 式を取得する ​**JobInstanceId**​ 属性を渡して、各 Batch Job の一意の識別子を指定します。 定数値は Batch Job には使用できないため、DW 式が以前に参照された値を返した場合、Mule は例外をスローしてジョブインスタンスを作成しません。 ジョブインスタンス ID を設定しない場合、Mule によってインスタンスに割り当てる UUID が自動生成されます。 上記のジョブインスタンスで生成された UUID は ​`ba01e1a0-f5c7-11e4-9414-10ddb1daeb6d`​ です。このように、実際の実行と関連付けることが困難な人間が判読できない識別子となっているため、同時に複数のジョブを実行している可能性があることを考慮すると、この ID はまったく意味不明です。 ユニーク性を保証するため、次の DataWeave 式を使用してサーバーの現在の日付としてジョブ ID を定義できます。 `#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]`​。 これは、実行インスタンスに ​`Job From 15/01/16 05:23:12`​ という名前を付けます。 ```text com.mulesoft.module.batch.engine.DefaultBatchEngine: Created instance Job From 15/01/16 05:23:12 for batch job contacts-to-SFDCBatch com.mulesoft.module.batch.engine.DefaultBatchEngine: Starting input phase com.mulesoft.module.batch.engine.DefaultBatchEngine: Input phase completed com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Starting loading phase for instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Finished loading phase for instance Job From 15/01/16 05:23:12 of job contacts-to-SFDCBatch. 3 records were loaded com.mulesoft.module.batch.engine.DefaultBatchEngine: Started execution of instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' ``` 適切に識別されたインスタンスのログは読みやすくなります。 ```xml ... ... ... ``` ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-filters-and-batch-aggregator) # Batch Job インスタンス ID バッチ処理のユーザーは多くの場合、Batch Job の実行フェーズ中に Batch Job のインスタンス ID を判断できる必要があります。 Batch Job インスタンス ID は次の場合に役立ちます。 - データを参照および管理するためにローカルジョブインスタンス ID を外部システムに渡す - ジョブのカスタムログを改善する - 重要なイベントに関するメールまたは SMS 通知を送信する ## [](#例)例 Mule は、キー ​`batchJobInstanceId`​ のフロー変数を使用して Batch Job インスタンス ID を公開します。そのフロー変数は、入力フェーズの最初に使用できます。フロー変数はすべてのステップおよび on-complete フェーズでも使用可能です。 ![batch job instance id c4362](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/batch-job-instance-id-c4362.png) ログ出力は次のようになります。 ```text com.mulesoft.mule.runtime.module.batch.internal.engine.DefaultBatchEngine: Created instance '7dc5cad0-ab09-11e8-a790-9801a7b055d3' for batch job 'CreateLeadsBatch' ``` ## [](#カスタム-batch-job-インスタンス-id)カスタム Batch Job インスタンス ID DataWeave 式を使用して、DW 式を取得する ​**JobInstanceId**​ 属性を渡して、各 Batch Job の一意の識別子を指定します。 定数値は Batch Job には使用できないため、DW 式が以前に参照された値を返した場合、Mule は例外をスローしてジョブインスタンスを作成しません。 ジョブインスタンス ID を設定しない場合、Mule によってインスタンスに割り当てる UUID が自動生成されます。 上記のジョブインスタンスで生成された UUID は ​`ba01e1a0-f5c7-11e4-9414-10ddb1daeb6d`​ です。このように、実際の実行と関連付けることが困難な人間が判読できない識別子となっているため、同時に複数のジョブを実行している可能性があることを考慮すると、この ID はまったく意味不明です。 ユニーク性を保証するため、次の DataWeave 式を使用してサーバーの現在の日付としてジョブ ID を定義できます。 `#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]`​。 これは、実行インスタンスに ​`Job From 15/01/16 05:23:12`​ という名前を付けます。 ```text com.mulesoft.module.batch.engine.DefaultBatchEngine: Created instance Job From 15/01/16 05:23:12 for batch job contacts-to-SFDCBatch com.mulesoft.module.batch.engine.DefaultBatchEngine: Starting input phase com.mulesoft.module.batch.engine.DefaultBatchEngine: Input phase completed com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Starting loading phase for instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Finished loading phase for instance Job From 15/01/16 05:23:12 of job contacts-to-SFDCBatch. 3 records were loaded com.mulesoft.module.batch.engine.DefaultBatchEngine: Started execution of instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' ``` 適切に識別されたインスタンスのログは読みやすくなります。 ```xml ... ... ... ``` ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-filters-and-batch-aggregator) # Batch Job インスタンス ID バッチ処理のユーザーは多くの場合、Batch Job の実行フェーズ中に Batch Job のインスタンス ID を判断できる必要があります。 Batch Job インスタンス ID は次の場合に役立ちます。 - データを参照および管理するためにローカルジョブインスタンス ID を外部システムに渡す - ジョブのカスタムログを改善する - 重要なイベントに関するメールまたは SMS 通知を送信する ## [](#例)例 Mule は、キー ​`batchJobInstanceId`​ のフロー変数を使用して Batch Job インスタンス ID を公開します。そのフロー変数は、入力フェーズの最初に使用できます。フロー変数はすべてのステップおよび on-complete フェーズでも使用可能です。 ![Anypoint Studio のジョブインスタンス ID が表示されているバッチ処理コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/batch-job-instance-id-c4362.png) ログ出力は次のようになります。 ```text com.mulesoft.mule.runtime.module.batch.internal.engine.DefaultBatchEngine: Created instance '7dc5cad0-ab09-11e8-a790-9801a7b055d3' for batch job 'CreateLeadsBatch' ``` ## [](#カスタム-batch-job-インスタンス-id)カスタム Batch Job インスタンス ID DataWeave 式を使用して、DW 式を取得する ​**JobInstanceId**​ 属性を渡して、各 Batch Job の一意の識別子を指定します。 定数値は Batch Job には使用できないため、DW 式が以前に参照された値を返した場合、Mule は例外をスローしてジョブインスタンスを作成しません。 ジョブインスタンス ID を設定しない場合、Mule によってインスタンスに割り当てる UUID が自動生成されます。 上記のジョブインスタンスで生成された UUID は ​`ba01e1a0-f5c7-11e4-9414-10ddb1daeb6d`​ です。このように、実際の実行と関連付けることが困難な人間が判読できない識別子となっているため、同時に複数のジョブを実行している可能性があることを考慮すると、この ID はまったく意味不明です。 ユニーク性を保証するため、次の DataWeave 式を使用してサーバーの現在の日付としてジョブ ID を定義できます。 `#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]`​。 これは、実行インスタンスに ​`Job From 15/01/16 05:23:12`​ という名前を付けます。 ```text com.mulesoft.module.batch.engine.DefaultBatchEngine: Created instance Job From 15/01/16 05:23:12 for batch job contacts-to-SFDCBatch com.mulesoft.module.batch.engine.DefaultBatchEngine: Starting input phase com.mulesoft.module.batch.engine.DefaultBatchEngine: Input phase completed com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Starting loading phase for instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Finished loading phase for instance Job From 15/01/16 05:23:12 of job contacts-to-SFDCBatch. 3 records were loaded com.mulesoft.module.batch.engine.DefaultBatchEngine: Started execution of instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' ``` 適切に識別されたインスタンスのログは読みやすくなります。 ```xml ... ... ... ``` ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-filters-and-batch-aggregator) # Batch Job インスタンス ID バッチ処理のユーザーは多くの場合、Batch Job の実行フェーズ中に Batch Job のインスタンス ID を判断できる必要があります。 Batch Job インスタンス ID は次の場合に役立ちます。 - データを参照および管理するためにローカルジョブインスタンス ID を外部システムに渡す - ジョブのカスタムログを改善する - 重要なイベントに関するメールまたは SMS 通知を送信する ## [](#例)例 Mule は、キー ​`batchJobInstanceId`​ のフロー変数を使用して Batch Job インスタンス ID を公開します。そのフロー変数は、入力フェーズの最初に使用できます。フロー変数はすべてのステップおよび on-complete フェーズでも使用可能です。 ![Anypoint Studio のジョブインスタンス ID が表示されているバッチ処理コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/batch-job-instance-id-c4362.png) ログ出力は次のようになります。 ```text com.mulesoft.mule.runtime.module.batch.internal.engine.DefaultBatchEngine: Created instance '7dc5cad0-ab09-11e8-a790-9801a7b055d3' for batch job 'CreateLeadsBatch' ``` ## [](#カスタム-batch-job-インスタンス-id)カスタム Batch Job インスタンス ID DataWeave 式を使用して、DW 式を取得する ​**JobInstanceId**​ 属性を渡して、各 Batch Job の一意の識別子を指定します。 定数値は Batch Job には使用できないため、DW 式が以前に参照された値を返した場合、Mule は例外をスローしてジョブインスタンスを作成しません。 ジョブインスタンス ID を設定しない場合、Mule によってインスタンスに割り当てる UUID が自動生成されます。 上記のジョブインスタンスで生成された UUID は ​`ba01e1a0-f5c7-11e4-9414-10ddb1daeb6d`​ です。このように、実際の実行と関連付けることが困難な人間が判読できない識別子となっているため、同時に複数のジョブを実行している可能性があることを考慮すると、この ID はまったく意味不明です。 ユニーク性を保証するため、次の DataWeave 式を使用してサーバーの現在の日付としてジョブ ID を定義できます。 `#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]`​。 これは、実行インスタンスに ​`Job From 15/01/16 05:23:12`​ という名前を付けます。 ```text com.mulesoft.module.batch.engine.DefaultBatchEngine: Created instance Job From 15/01/16 05:23:12 for batch job contacts-to-SFDCBatch com.mulesoft.module.batch.engine.DefaultBatchEngine: Starting input phase com.mulesoft.module.batch.engine.DefaultBatchEngine: Input phase completed com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Starting loading phase for instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Finished loading phase for instance Job From 15/01/16 05:23:12 of job contacts-to-SFDCBatch. 3 records were loaded com.mulesoft.module.batch.engine.DefaultBatchEngine: Started execution of instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' ``` 適切に識別されたインスタンスのログは読みやすくなります。 ```xml ... ... ... ``` ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-filters-and-batch-aggregator) # Batch Job インスタンス ID バッチ処理のユーザーは多くの場合、Batch Job の実行フェーズ中に Batch Job のインスタンス ID を判断できる必要があります。 Batch Job インスタンス ID は次の場合に役立ちます。 - データを参照および管理するためにローカルジョブインスタンス ID を外部システムに渡す - ジョブのカスタムログを改善する - 重要なイベントに関するメールまたは SMS 通知を送信する ## [](#例)例 Mule は、キー ​`batchJobInstanceId`​ のフロー変数を使用して Batch Job インスタンス ID を公開します。そのフロー変数は、入力フェーズの最初に使用できます。フロー変数はすべてのステップおよび on-complete フェーズでも使用可能です。 ![Anypoint Studio のジョブインスタンス ID が表示されているバッチ処理コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/batch-job-instance-id-c4362.png) ログ出力は次のようになります。 ```text com.mulesoft.mule.runtime.module.batch.internal.engine.DefaultBatchEngine: Created instance '7dc5cad0-ab09-11e8-a790-9801a7b055d3' for batch job 'CreateLeadsBatch' ``` ## [](#カスタム-batch-job-インスタンス-id)カスタム Batch Job インスタンス ID DataWeave 式を使用して、DW 式を取得する ​**JobInstanceId**​ 属性を渡して、各 Batch Job の一意の識別子を指定します。 定数値は Batch Job には使用できないため、DW 式が以前に参照された値を返した場合、Mule は例外をスローしてジョブインスタンスを作成しません。 ジョブインスタンス ID を設定しない場合、Mule によってインスタンスに割り当てる UUID が自動生成されます。 上記のジョブインスタンスで生成された UUID は ​`ba01e1a0-f5c7-11e4-9414-10ddb1daeb6d`​ です。このように、実際の実行と関連付けることが困難な人間が判読できない識別子となっているため、同時に複数のジョブを実行している可能性があることを考慮すると、この ID はまったく意味不明です。 ユニーク性を保証するため、次の DataWeave 式を使用してサーバーの現在の日付としてジョブ ID を定義できます。 `#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]`​。 これは、実行インスタンスに ​`Job From 15/01/16 05:23:12`​ という名前を付けます。 ```text com.mulesoft.module.batch.engine.DefaultBatchEngine: Created instance Job From 15/01/16 05:23:12 for batch job contacts-to-SFDCBatch com.mulesoft.module.batch.engine.DefaultBatchEngine: Starting input phase com.mulesoft.module.batch.engine.DefaultBatchEngine: Input phase completed com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Starting loading phase for instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Finished loading phase for instance Job From 15/01/16 05:23:12 of job contacts-to-SFDCBatch. 3 records were loaded com.mulesoft.module.batch.engine.DefaultBatchEngine: Started execution of instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch' ``` 適切に識別されたインスタンスのログは読みやすくなります。 ```xml ... ... ... ``` ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-filters-and-batch-aggregator) # Batch Job のフェーズ Batch Job コンポーネントが実行されるたびに、次のフェーズが行われます。 1. [Load and Dispatch フェーズ](#phase_load_dispatch)​: Batch Job コンポーネントにより​[有効な入力](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-processing-concept#valid_input)​がレコードに分割され、レコードを処理する準備が整えられます。このフェーズは Batch Job コンポーネント内で行われます。 2. [Process フェーズ](#phase_process)​: Batch Job の 1 つ以上の Batch Step コンポーネント内の Mule コンポーネントおよびコネクタの操作により、特定の Batch Job インスタンス内のレコードが処理されます。Batch Aggregator コンポーネント内での処理も Process フェーズで行われます。 3. [On Complete フェーズ](#phase_on_complete)​: Batch Job コンポーネントにより、Batch Job インスタンスの処理の結果が含まれるレポートオブジェクトが発行されます。 例については、​[バッチフェーズの XML](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-processing-concept#batch_phases_xml)​ を参照してください。 ## [](#phase_load_dispatch)Load and Dispatch フェーズ フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Load and Dispatch フェーズが開始されます。このフェーズでは、以下が行われます。 1. Mule によって、Batch Job の各フェーズで保持される新しい Batch Job インスタンスが作成されます。 Batch Job コンポーネントのスコープ内で、​`batchJobInstanceId`​ 変数を使用して現在処理中の Batch Job インスタンス ID が Mule によって公開されます。​`vars.batchJobInstanceId`​ を使用して、任意のバッチ処理フェーズで現在のインスタンスの識別子にアクセスできます。自動生成される識別子は UUID ですが、別の値に変更できます。詳細は、[Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-job-instance-id) を参照してください。 2. Batch Job コンポーネントにより、受信されたメッセージペイロードが自動的にレコードに分割され、ステッピングキューにレコードが格納されます。 Batch Job コンポーネントによって入力のすべての項目のレコードが正常に生成され、キューに追加されるか、​`MULE:EXPRESSION`​ メッセージなどのエラータイプと ​`"Expecting Array or Object but got String." evaluating expression: "payload"`​ などのエラーメッセージでイベント全体が失敗します。 Anypoint Runtime Manager では、たとえば次のようにキュー名に ​`BSQ`​ というプレフィックスが付けられます。 ![Batch Step キュートランザクションログ](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-batch-bsq.png) 3. Batch Job コンポーネントにより、読み込まれたレコードを処理する Batch Job インスタンスの実行が開始されます。 ## [](#phase_process)Process フェーズ Process フェーズは、Load and Dispatch でキューへのレコードの読み込みを完了し、Batch Job インスタンスの処理を開始した後に開始されます。このフェーズでは、Batch Step コンポーネントによって設定済みのサイズのレコードブロックがキューから抽出され、処理されます。(デフォルトのバッチブロックサイズは 100 です)。 Batch Step コンポーネント内での処理はブロックレベルで並列に行われますが、各ブロック内のレコードはデフォルトで順次処理されます。Mule では、自動調整機能によって、使用するスレッド数と適用する並列性レベルが決定されます (​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.4/execution-engine)​を参照)。 このフェーズ中、コンポーネント内のプロセッサーは ​`payload`​ および ​`vars`​ Mule 変数を使用してレコードにアクセスし、変更を行います。Batch Job ではすべてのレコードの処理が完了した後でレコードがコンシュームされます。そのため、​_処理済み_​レコードを外部サーバーまたはサービスに転送する場合は、Batch Step または Batch Aggregator コンポーネント​_内_​で転送する必要があります。Mule 変数の伝播ルールについては、​[「変数の伝播」](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-processing-concept#variable_propagation)​を参照してください。 Batch Step ではブロック内のレコードを処理した後に、レコードをステッピングキューに送信します。ステッピングキューでは、レコードは次の Batch Step を待機します。すべてのレコードが同じ Batch Job コンポーネント内のすべての Batch Step を通過するまで、このプロセスが続行されます。このフェーズの最後の時点で、すべてのレコードがコンシュームされます。Mule フローのダウンストリームプロセッサーによる追加の処理には使用できません。 Batch Aggregator コンポーネント内で行われるレコードに対する変更は Batch Aggregator コンポーネント外に​_伝播されない_​ため、変更内容はフローの後続の Batch Step コンポーネントでは表示されませんのでご注意ください。 ![Batch Step のレコードのステッピングキュー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-batch-step-process.png) 処理が行われるときに、各レコードはすべての Batch Step コンポーネントでの処理を監視します。 デフォルトでは、Batch Job インスタンスは、キューに追加されたすべてのレコードが 1 つの Batch Step コンポーネントでの処理を終了するのを待たずに、レコードを次の Batch Step で処理できるようにします。Batch Aggregator コンポーネントを設定するとこの動作が変更されます。 - Batch Aggregator コンポーネントが固定サイズを設定するときの動作: Batch Aggregator 内のプロセッサーは入力としてレコードの配列を受け取れる必要があります。 ![固定サイズのアグリゲーターを使用する Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-batch-job-process-aggregator-fixed.png)
1Batch Job コンポーネント内の各 Batch Step によって 1 つ以上のレコードブロックが受け取られ、並列での処理が開始されます。
2Batch Step コンポーネントはレコードを処理した後で、さらに処理するためにレコードを Batch Aggregator コンポーネントに送信します。
3固定サイズ (​size​) を処理するよう設定した場合、Aggregator コンポーネントによってレコードが指定した数のレコードが含まれる 1 つ以上のブロックに配置されます。レコードが設定したサイズより少ない場合、最後のレコードのブロックが小さくなります。
4特定の配列でレコードを処理した後で、Batch Aggregator コンポーネントではすべてのレコードブロックがステッピングキューに送信されます。
- Batch Aggregator コンポーネントがレコードをストリーミングするよう設定されているときの動作: ストリーミング時には、Batch Aggregator コンポーネントではレコードをレコードブロックに配置するのではなく、受け取った直後にレコードを処理します。アグリゲーターのすべてのレコードで​_現在_​の Batch Step のすべてのレコードが処理されるまで、レコードは​_次_​の Batch Step コンポーネントに公開されません。 コンポーネント内のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。 ![ストリーミング用にアグリゲーターが設定されている場合の Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-batch-job-process-aggregator-streaming.png)
1各 Batch Step コンポーネントで 1 つ以上のレコードブロックを受け取り、レコードブロックの並列処理を開始します。
2Batch Step でレコードを処理したら、レコードを Batch Aggregator に送信してさらに処理を行います。
3Batch Aggregator コンポーネントでは、現在の Batch Step による処理を待機している、ステッピングキュー内のレコードがなくなるまでレコードの処理を継続します。
4Batch Aggregator コンポーネントでは集約したすべてのレコードがステッピングキューに送信されます。
Mule では、各 Batch Step での処理に成功または失敗したすべてのレコードのリストを保持しています。Batch Step のイベントプロセッサーでレコードの処理に失敗した場合、Mule はバッチの処理を続行し、後続の各 Batch Step では ​`acceptPolicy`​ に基づいて失敗したレコードをスキップします。Batch Job コンポーネントには、Batch Job が停止する前に失敗できるレコードの数を設定するための ​`maxFailedRecords`​ プロパティが用意されています。​[「Batch Job のプロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-reference#ref_batch_job_general_fields)​を参照してください。 ## [](#phase_on_complete)On Complete フェーズ このフェーズ中、特定の Batch Job インスタンスで処理したレコードのレポートまたは概要を作成するように Mule Runtime を設定できます。このフェーズでは、システム管理者および開発者に、どのレコードが処理に失敗し、どのレコードが正常に処理されたかに関するインサイトが提供されますが、各レコードの処理が行われたり各レコードへのアクセスが提供されたりすることはなく、処理されたレコードがフローのダウンストリームプロセッサーに渡されたりすることもありません。 このフェーズの終了時に Batch Job インスタンスは完了し、消滅します。 ベストプラクティスとしては、失敗または成功したレコードについて報告するための何らかのメカニズムを設定し、必要な場合は追加アクションの実行を促してください。On Complete フェーズ中に、次のいずれかのタスクを実行できます。 - Mule アプリケーションの他の場所にある Batch Job の結果オブジェクトを参照し、特定の Batch Job インスタンスで処理に失敗したレコード数などの Batch Job メタデータを取得および使用する。 - 各 Batch Job インスタンスの結果オブジェクトを記録する。 ```xml ``` ロガーから ​`payload as Object`​ に設定すると、レポートは次のようになります。 INFO 2022-07-06 11:39:02,921 \[\[MuleRuntime\].uber.06: \[w-batch-take6\].batch-management-work-manager @56978b97\] \[processor: w-batch-take6Flow/processors/3/route/1/processors/0; event: e835b2c0-fd5a-11ec-84a5-147ddaaf4f97\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: {onCompletePhaseException=null, loadingPhaseException=null, totalRecords=1000, elapsedTimeInMillis=117, failedOnCompletePhase=false, failedRecords=0, loadedRecords=1000, failedOnInputPhase=false, successfulRecords=1000, inputPhaseException=null, processedRecords=10, failedOnLoadingPhase=false, batchJobInstanceId=e84b5da0-fd5a-11ec-84a5-147ddaaf4f97} インスタンス内で失敗したレコードの数を返す ​`payload.failedRecords`​ のように、Batch Job レポートオブジェクトの項目は DataWeave セレクターを使用するときのキーとしてアクセスできます。 On Complete フェーズを空のままにすると、Batch Job インスタンスは警告なしに完了し、たとえば次のように、インスタンスに関する処理情報がログで提供されます。 Finished execution for instance 'e84b5da0-fd5a-11ec-84a5-147ddaaf4f97' of job 'w-batch-take6Batch\_Job'. Total Records processed: 1000. Successful records: 1000. Failed Records: 0 # Batch Job のフェーズ Batch Job コンポーネントが実行されるたびに、次のフェーズが行われます。 1. [Load and Dispatch フェーズ](#phase_load_dispatch)​: Batch Job コンポーネントにより​[有効な入力](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-processing-concept#valid_input)​がレコードに分割され、レコードを処理する準備が整えられます。このフェーズは Batch Job コンポーネント内で行われます。 2. [Process フェーズ](#phase_process)​: Batch Job の 1 つ以上の Batch Step コンポーネント内の Mule コンポーネントおよびコネクタの操作により、特定の Batch Job インスタンス内のレコードが処理されます。Batch Aggregator コンポーネント内での処理も Process フェーズで行われます。 3. [On Complete フェーズ](#phase_on_complete)​: Batch Job コンポーネントにより、Batch Job インスタンスの処理の結果が含まれるレポートオブジェクトが発行されます。 例については、​[バッチフェーズの XML](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-processing-concept#batch_phases_xml)​ を参照してください。 ## [](#phase_load_dispatch)Load and Dispatch フェーズ フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Load and Dispatch フェーズが開始されます。このフェーズでは、以下が行われます。 1. Mule によって、Batch Job の各フェーズで保持される新しい Batch Job インスタンスが作成されます。 Batch Job コンポーネントのスコープ内で、​`batchJobInstanceId`​ 変数を使用して現在処理中の Batch Job インスタンス ID が Mule によって公開されます。​`vars.batchJobInstanceId`​ を使用して、任意のバッチ処理フェーズで現在のインスタンスの識別子にアクセスできます。自動生成される識別子は UUID ですが、別の値に変更できます。詳細は、[Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-job-instance-id)を参照してください。 2. Batch Job コンポーネントにより、受信されたメッセージペイロードが自動的にレコードに分割され、ステッピングキューにレコードが格納されます。 Batch Job コンポーネントによって入力のすべての項目のレコードが正常に生成され、キューに追加されるか、​`MULE:EXPRESSION`​ メッセージなどのエラータイプと ​`"Expecting Array or Object but got String." evaluating expression: "payload"`​ などのエラーメッセージでイベント全体が失敗します。 Anypoint Runtime Manager では、たとえば次のようにキュー名に ​`BSQ`​ というプレフィックスが付けられます。 ![Batch Step キュートランザクションログ](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-batch-bsq.png) 3. Batch Job コンポーネントにより、読み込まれたレコードを処理する Batch Job インスタンスの実行が開始されます。 ## [](#phase_process)Process フェーズ Process フェーズは、Load and Dispatch でキューへのレコードの読み込みを完了し、Batch Job インスタンスの処理を開始した後に開始されます。このフェーズでは、Batch Step コンポーネントによって設定済みのサイズのレコードブロックがキューから抽出され、処理されます。(デフォルトのバッチブロックサイズは 100 です)。 Batch Step コンポーネント内での処理はブロックレベルで並列に行われますが、各ブロック内のレコードはデフォルトで順次処理されます。Mule では、自動調整機能によって、使用するスレッド数と適用する並列性レベルが決定されます (​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.5/execution-engine)​を参照)。 このフェーズ中、コンポーネント内のプロセッサーは ​`payload`​ および ​`vars`​ Mule 変数を使用してレコードにアクセスし、変更を行います。Batch Job ではすべてのレコードの処理が完了した後でレコードがコンシュームされます。そのため、​_処理済み_​レコードを外部サーバーまたはサービスに転送する場合は、Batch Step または Batch Aggregator コンポーネント​_内_​で転送する必要があります。Mule 変数の伝播ルールについては、​[「変数の伝播」](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-processing-concept#variable_propagation)​を参照してください。 Batch Step ではブロック内のレコードを処理した後に、レコードをステッピングキューに送信します。ステッピングキューでは、レコードは次の Batch Step を待機します。すべてのレコードが同じ Batch Job コンポーネント内のすべての Batch Step を通過するまで、このプロセスが続行されます。このフェーズの最後の時点で、すべてのレコードがコンシュームされます。Mule フローのダウンストリームプロセッサーによる追加の処理には使用できません。 Batch Aggregator コンポーネント内で行われるレコードに対する変更は Batch Aggregator コンポーネント外に​_伝播されない_​ため、変更内容はフローの後続の Batch Step コンポーネントでは表示されませんのでご注意ください。 ![Batch Step のレコードのステッピングキュー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-batch-step-process.png) 処理が行われるときに、各レコードはすべての Batch Step コンポーネントでの処理を監視します。 デフォルトでは、Batch Job インスタンスは、キューに追加されたすべてのレコードが 1 つの Batch Step コンポーネントでの処理を終了するのを待たずに、レコードを次の Batch Step で処理できるようにします。Batch Aggregator コンポーネントを設定するとこの動作が変更されます。 - Batch Aggregator コンポーネントが固定サイズを設定するときの動作: Batch Aggregator 内のプロセッサーは入力としてレコードの配列を受け取れる必要があります。 ![固定サイズのアグリゲーターを使用する Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-batch-job-process-aggregator-fixed.png)
1Batch Job コンポーネント内の各 Batch Step によって 1 つ以上のレコードブロックが受け取られ、並列での処理が開始されます。
2Batch Step コンポーネントはレコードを処理した後で、さらに処理するためにレコードを Batch Aggregator コンポーネントに送信します。
3固定サイズ (​size​) を処理するよう設定した場合、Aggregator コンポーネントによってレコードが指定した数のレコードが含まれる 1 つ以上のブロックに配置されます。レコードが設定したサイズより少ない場合、最後のレコードのブロックが小さくなります。
4特定の配列でレコードを処理した後で、Batch Aggregator コンポーネントではすべてのレコードブロックがステッピングキューに送信されます。
- Batch Aggregator コンポーネントがレコードをストリーミングするよう設定されているときの動作: ストリーミング時には、Batch Aggregator コンポーネントではレコードをレコードブロックに配置するのではなく、受け取った直後にレコードを処理します。アグリゲーターのすべてのレコードで​_現在_​の Batch Step のすべてのレコードが処理されるまで、レコードは​_次_​の Batch Step コンポーネントに公開されません。 コンポーネント内のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。 ![ストリーミング用にアグリゲーターが設定されている場合の Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-batch-job-process-aggregator-streaming.png)
1各 Batch Step コンポーネントで 1 つ以上のレコードブロックを受け取り、レコードブロックの並列処理を開始します。
2Batch Step でレコードを処理したら、レコードを Batch Aggregator に送信してさらに処理を行います。
3Batch Aggregator コンポーネントでは、現在の Batch Step による処理を待機している、ステッピングキュー内のレコードがなくなるまでレコードの処理を継続します。
4Batch Aggregator コンポーネントでは集約したすべてのレコードがステッピングキューに送信されます。
Mule では、各 Batch Step での処理に成功または失敗したすべてのレコードのリストを保持しています。Batch Step のイベントプロセッサーでレコードの処理に失敗した場合、Mule はバッチの処理を続行し、後続の各 Batch Step では ​`acceptPolicy`​ に基づいて失敗したレコードをスキップします。Batch Job コンポーネントには、Batch Job が停止する前に失敗できるレコードの数を設定するための ​`maxFailedRecords`​ プロパティが用意されています。​[「Batch Job のプロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-reference#ref_batch_job_general_fields)​を参照してください。 ## [](#phase_on_complete)On Complete フェーズ このフェーズ中、特定の Batch Job インスタンスで処理したレコードのレポートまたは概要を作成するように Mule Runtime を設定できます。このフェーズでは、システム管理者および開発者に、どのレコードが処理に失敗し、どのレコードが正常に処理されたかに関するインサイトが提供されますが、各レコードの処理が行われたり各レコードへのアクセスが提供されたりすることはなく、処理されたレコードがフローのダウンストリームプロセッサーに渡されたりすることもありません。 このフェーズの終了時に Batch Job インスタンスは完了し、消滅します。 ベストプラクティスとしては、失敗または成功したレコードについて報告するための何らかのメカニズムを設定し、必要な場合は追加アクションの実行を促してください。On Complete フェーズ中に、次のいずれかのタスクを実行できます。 - Mule アプリケーションの他の場所にある Batch Job の結果オブジェクトを参照し、特定の Batch Job インスタンスで処理に失敗したレコード数などの Batch Job メタデータを取得および使用する。 - 各 Batch Job インスタンスの結果オブジェクトを記録する。 ```xml ``` ロガーから ​`payload as Object`​ に設定すると、レポートは次のようになります。 INFO 2022-07-06 11:39:02,921 \[\[MuleRuntime\].uber.06: \[w-batch-take6\].batch-management-work-manager @56978b97\] \[processor: w-batch-take6Flow/processors/3/route/1/processors/0; event: e835b2c0-fd5a-11ec-84a5-147ddaaf4f97\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: {onCompletePhaseException=null, loadingPhaseException=null, totalRecords=1000, elapsedTimeInMillis=117, failedOnCompletePhase=false, failedRecords=0, loadedRecords=1000, failedOnInputPhase=false, successfulRecords=1000, inputPhaseException=null, processedRecords=10, failedOnLoadingPhase=false, batchJobInstanceId=e84b5da0-fd5a-11ec-84a5-147ddaaf4f97} インスタンス内で失敗したレコードの数を返す ​`payload.failedRecords`​ のように、Batch Job レポートオブジェクトの項目は DataWeave セレクターを使用するときのキーとしてアクセスできます。 On Complete フェーズを空のままにすると、Batch Job インスタンスは警告なしに完了し、たとえば次のように、インスタンスに関する処理情報がログで提供されます。 Finished execution for instance 'e84b5da0-fd5a-11ec-84a5-147ddaaf4f97' of job 'w-batch-take6Batch\_Job'. Total Records processed: 1000. Successful records: 1000. Failed Records: 0 # Batch Job のフェーズ Batch Job コンポーネントが実行されるたびに、次のフェーズが行われます。 1. [Load and Dispatch フェーズ](#phase_load_dispatch)​: Batch Job コンポーネントにより​[有効な入力](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-processing-concept#valid_input)​がレコードに分割され、レコードを処理する準備が整えられます。このフェーズは Batch Job コンポーネント内で行われます。 2. [Process フェーズ](#phase_process)​: Batch Job の 1 つ以上の Batch Step コンポーネント内の Mule コンポーネントおよびコネクタの操作により、特定の Batch Job インスタンス内のレコードが処理されます。Batch Aggregator コンポーネント内での処理も Process フェーズで行われます。 3. [On Complete フェーズ](#phase_on_complete)​: Batch Job コンポーネントにより、Batch Job インスタンスの処理の結果が含まれるレポートオブジェクトが発行されます。 例については、​[バッチフェーズの XML](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-processing-concept#batch_phases_xml)​ を参照してください。 ## [](#phase_load_dispatch)Load and Dispatch フェーズ フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Load and Dispatch フェーズが開始されます。このフェーズでは、以下が行われます。 1. Mule によって、Batch Job の各フェーズで保持される新しい Batch Job インスタンスが作成されます。 Batch Job コンポーネントのスコープ内で、​`batchJobInstanceId`​ 変数を使用して現在処理中の Batch Job インスタンス ID が Mule によって公開されます。​`vars.batchJobInstanceId`​ を使用して、任意のバッチ処理フェーズで現在のインスタンスの識別子にアクセスできます。自動生成される識別子は UUID ですが、別の値に変更できます。詳細は、[Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-job-instance-id)を参照してください。 2. Batch Job コンポーネントにより、受信されたメッセージペイロードが自動的にレコードに分割され、ステッピングキューにレコードが格納されます。 Batch Job コンポーネントによって入力のすべての項目のレコードが正常に生成され、キューに追加されるか、​`MULE:EXPRESSION`​ メッセージなどのエラータイプと ​`"Expecting Array or Object but got String." evaluating expression: "payload"`​ などのエラーメッセージでイベント全体が失敗します。 Anypoint Runtime Manager では、たとえば次のようにキュー名に ​`BSQ`​ というプレフィックスが付けられます。 ![Batch Step キュートランザクションログ](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-batch-bsq.png) 3. Batch Job コンポーネントにより、読み込まれたレコードを処理する Batch Job インスタンスの実行が開始されます。 ## [](#phase_process)Process フェーズ Process フェーズは、Load and Dispatch でキューへのレコードの読み込みを完了し、Batch Job インスタンスの処理を開始した後に開始されます。このフェーズでは、Batch Step コンポーネントによって設定済みのサイズのレコードブロックがキューから抽出され、処理されます。(デフォルトのバッチブロックサイズは 100 です)。 Batch Step コンポーネント内での処理はブロックレベルで並列に行われますが、各ブロック内のレコードはデフォルトで順次処理されます。Mule では、自動調整機能によって、使用するスレッド数と適用する並列性レベルが決定されます (​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.6/execution-engine)​を参照)。 このフェーズ中、コンポーネント内のプロセッサーは ​`payload`​ および ​`vars`​ Mule 変数を使用してレコードにアクセスし、変更を行います。Batch Job ではすべてのレコードの処理が完了した後でレコードがコンシュームされます。そのため、​_処理済み_​レコードを外部サーバーまたはサービスに転送する場合は、Batch Step または Batch Aggregator コンポーネント​_内_​で転送する必要があります。Mule 変数の伝播ルールについては、​[「変数の伝播」](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-processing-concept#variable_propagation)​を参照してください。 Batch Step ではブロック内のレコードを処理した後に、レコードをステッピングキューに送信します。ステッピングキューでは、レコードは次の Batch Step を待機します。すべてのレコードが同じ Batch Job コンポーネント内のすべての Batch Step を通過するまで、このプロセスが続行されます。このフェーズの最後の時点で、すべてのレコードがコンシュームされます。Mule フローのダウンストリームプロセッサーによる追加の処理には使用できません。 Batch Aggregator コンポーネント内で行われるレコードに対する変更は Batch Aggregator コンポーネント外に​_伝播されない_​ため、変更内容はフローの後続の Batch Step コンポーネントでは表示されませんのでご注意ください。 ![Batch Step のレコードのステッピングキュー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-batch-step-process.png) 処理が行われるときに、各レコードはすべての Batch Step コンポーネントでの処理を監視します。 デフォルトでは、Batch Job インスタンスは、キューに追加されたすべてのレコードが 1 つの Batch Step コンポーネントでの処理を終了するのを待たずに、レコードを次の Batch Step で処理できるようにします。Batch Aggregator コンポーネントを設定するとこの動作が変更されます。 - Batch Aggregator コンポーネントが固定サイズを設定するときの動作: Batch Aggregator 内のプロセッサーは入力としてレコードの配列を受け取れる必要があります。 ![固定サイズのアグリゲーターを使用する Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-batch-job-process-aggregator-fixed.png)
1Batch Job コンポーネント内の各 Batch Step によって 1 つ以上のレコードブロックが受け取られ、並列での処理が開始されます。
2Batch Step コンポーネントはレコードを処理した後で、さらに処理するためにレコードを Batch Aggregator コンポーネントに送信します。
3固定サイズ (​size​) を処理するよう設定した場合、Aggregator コンポーネントによってレコードが指定した数のレコードが含まれる 1 つ以上のブロックに配置されます。レコードが設定したサイズより少ない場合、最後のレコードのブロックが小さくなります。
4特定の配列でレコードを処理した後で、Batch Aggregator コンポーネントではすべてのレコードブロックがステッピングキューに送信されます。
- Batch Aggregator コンポーネントがレコードをストリーミングするよう設定されているときの動作: ストリーミング時には、Batch Aggregator コンポーネントではレコードをレコードブロックに配置するのではなく、受け取った直後にレコードを処理します。アグリゲーターのすべてのレコードで​_現在_​の Batch Step のすべてのレコードが処理されるまで、レコードは​_次_​の Batch Step コンポーネントに公開されません。 コンポーネント内のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。 ![ストリーミング用にアグリゲーターが設定されている場合の Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-batch-job-process-aggregator-streaming.png)
1各 Batch Step コンポーネントで 1 つ以上のレコードブロックを受け取り、レコードブロックの並列処理を開始します。
2Batch Step でレコードを処理したら、レコードを Batch Aggregator に送信してさらに処理を行います。
3Batch Aggregator コンポーネントでは、現在の Batch Step による処理を待機している、ステッピングキュー内のレコードがなくなるまでレコードの処理を継続します。
4Batch Aggregator コンポーネントでは集約したすべてのレコードがステッピングキューに送信されます。
Mule では、各 Batch Step での処理に成功または失敗したすべてのレコードのリストを保持しています。Batch Step のイベントプロセッサーでレコードの処理に失敗した場合、Mule はバッチの処理を続行し、後続の各 Batch Step では ​`acceptPolicy`​ に基づいて失敗したレコードをスキップします。Batch Job コンポーネントには、Batch Job が停止する前に失敗できるレコードの数を設定するための ​`maxFailedRecords`​ プロパティが用意されています。​[「Batch Job のプロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-reference#ref_batch_job_general_fields)​を参照してください。 ## [](#phase_on_complete)On Complete フェーズ このフェーズ中、特定の Batch Job インスタンスで処理したレコードのレポートまたは概要を作成するように Mule Runtime を設定できます。このフェーズでは、システム管理者および開発者に、どのレコードが処理に失敗し、どのレコードが正常に処理されたかに関するインサイトが提供されますが、各レコードの処理が行われたり各レコードへのアクセスが提供されたりすることはなく、処理されたレコードがフローのダウンストリームプロセッサーに渡されたりすることもありません。 このフェーズの終了時に Batch Job インスタンスは完了し、消滅します。 ベストプラクティスとしては、失敗または成功したレコードについて報告するための何らかのメカニズムを設定し、必要な場合は追加アクションの実行を促してください。On Complete フェーズ中に、次のいずれかのタスクを実行できます。 - Mule アプリケーションの他の場所にある Batch Job の結果オブジェクトを参照し、特定の Batch Job インスタンスで処理に失敗したレコード数などの Batch Job メタデータを取得および使用する。 - 各 Batch Job インスタンスの結果オブジェクトを記録する。 ```xml ``` ロガーから ​`payload as Object`​ に設定すると、レポートは次のようになります。 INFO 2022-07-06 11:39:02,921 \[\[MuleRuntime\].uber.06: \[w-batch-take6\].batch-management-work-manager @56978b97\] \[processor: w-batch-take6Flow/processors/3/route/1/processors/0; event: e835b2c0-fd5a-11ec-84a5-147ddaaf4f97\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: {onCompletePhaseException=null, loadingPhaseException=null, totalRecords=1000, elapsedTimeInMillis=117, failedOnCompletePhase=false, failedRecords=0, loadedRecords=1000, failedOnInputPhase=false, successfulRecords=1000, inputPhaseException=null, processedRecords=10, failedOnLoadingPhase=false, batchJobInstanceId=e84b5da0-fd5a-11ec-84a5-147ddaaf4f97} インスタンス内で失敗したレコードの数を返す ​`payload.failedRecords`​ のように、Batch Job レポートオブジェクトの項目は DataWeave セレクターを使用するときのキーとしてアクセスできます。 On Complete フェーズを空のままにすると、Batch Job インスタンスは警告なしに完了し、たとえば次のように、インスタンスに関する処理情報がログで提供されます。 Finished execution for instance 'e84b5da0-fd5a-11ec-84a5-147ddaaf4f97' of job 'w-batch-take6Batch\_Job'. Total Records processed: 1000. Successful records: 1000. Failed Records: 0 # Batch Job のフェーズ Batch Job コンポーネントが実行されるたびに、次のフェーズが行われます。 1. [Load and Dispatch フェーズ](#phase_load_dispatch)​: Batch Job コンポーネントにより​[有効な入力](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-processing-concept#valid_input)​がレコードに分割され、レコードを処理する準備が整えられます。このフェーズは Batch Job コンポーネント内で行われます。 2. [Process フェーズ](#phase_process)​: Batch Job の 1 つ以上の Batch Step コンポーネント内の Mule コンポーネントおよびコネクタの操作により、特定の Batch Job インスタンス内のレコードが処理されます。Batch Aggregator コンポーネント内での処理も Process フェーズで行われます。 3. [On Complete フェーズ](#phase_on_complete)​: Batch Job コンポーネントにより、Batch Job インスタンスの処理の結果が含まれるレポートオブジェクトが発行されます。 例については、​[バッチフェーズの XML](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-processing-concept#batch_phases_xml)​ を参照してください。 ## [](#phase_load_dispatch)Load and Dispatch フェーズ フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Load and Dispatch フェーズが開始されます。このフェーズでは、以下が行われます。 1. Mule によって、Batch Job の各フェーズで保持される新しい Batch Job インスタンスが作成されます。 Batch Job コンポーネントのスコープ内で、​`batchJobInstanceId`​ 変数を使用して現在処理中の Batch Job インスタンス ID が Mule によって公開されます。​`vars.batchJobInstanceId`​ を使用して、任意のバッチ処理フェーズで現在のインスタンスの識別子にアクセスできます。自動生成される識別子は UUID ですが、別の値に変更できます。詳細は、[Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-job-instance-id)を参照してください。 2. Batch Job コンポーネントにより、受信されたメッセージペイロードが自動的にレコードに分割され、ステッピングキューにレコードが格納されます。 Batch Job コンポーネントによって入力のすべての項目のレコードが正常に生成され、キューに追加されるか、​`MULE:EXPRESSION`​ メッセージなどのエラータイプと ​`"Expecting Array or Object but got String." evaluating expression: "payload"`​ などのエラーメッセージでイベント全体が失敗します。 Anypoint Runtime Manager では、たとえば次のようにキュー名に ​`BSQ`​ というプレフィックスが付けられます。 ![Anypoint Runtime Manager の Batch Step キュートランザクションログ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-batch-bsq.png) 3. Batch Job コンポーネントにより、読み込まれたレコードを処理する Batch Job インスタンスの実行が開始されます。 ## [](#phase_process)Process フェーズ Process フェーズは、Load and Dispatch でキューへのレコードの読み込みを完了し、Batch Job インスタンスの処理を開始した後に開始されます。このフェーズでは、Batch Step コンポーネントによって設定済みのサイズのレコードブロックがキューから抽出され、処理されます。(デフォルトのバッチブロックサイズは 100 です)。 Batch Step コンポーネント内での処理はブロックレベルで並列に行われますが、各ブロック内のレコードはデフォルトで順次処理されます。Mule では、自動調整機能によって、使用するスレッド数と適用する並列性レベルが決定されます (​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.7/execution-engine)​を参照)。 このフェーズ中、コンポーネント内のプロセッサーは ​`payload`​ および ​`vars`​ Mule 変数を使用してレコードにアクセスし、変更を行います。Batch Job ではすべてのレコードの処理が完了した後でレコードがコンシュームされます。そのため、​_処理済み_​レコードを外部サーバーまたはサービスに転送する場合は、Batch Step または Batch Aggregator コンポーネント​_内_​で転送する必要があります。Mule 変数の伝播ルールについては、​[「変数の伝播」](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-processing-concept#variable_propagation)​を参照してください。 Batch Step ではブロック内のレコードを処理した後に、レコードをステッピングキューに送信します。ステッピングキューでは、レコードは次の Batch Step を待機します。すべてのレコードが同じ Batch Job コンポーネント内のすべての Batch Step を通過するまで、このプロセスが続行されます。このフェーズの最後の時点で、すべてのレコードがコンシュームされます。Mule フローのダウンストリームプロセッサーによる追加の処理には使用できません。 Batch Aggregator コンポーネント内で行われるレコードに対する変更は Batch Aggregator コンポーネント外に​_伝播されない_​ため、変更内容はフローの後続の Batch Step コンポーネントでは表示されませんのでご注意ください。 ![複数の Batch Step のレコードのステッピングキューが含まれる Batch Job インスタンス](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-batch-step-process.png) 処理が行われるときに、各レコードはすべての Batch Step コンポーネントでの処理を監視します。 デフォルトでは、Batch Job インスタンスは、キューに追加されたすべてのレコードが 1 つの Batch Step コンポーネントでの処理を終了するのを待たずに、レコードを次の Batch Step で処理できるようにします。Batch Aggregator コンポーネントを設定するとこの動作が変更されます。 - Batch Aggregator コンポーネントが固定サイズを設定するときの動作: Batch Aggregator 内のプロセッサーは入力としてレコードの配列を受け取れる必要があります。 ![固定サイズのアグリゲーターが含まれる Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-batch-job-process-aggregator-fixed.png)
1Batch Job コンポーネント内の各 Batch Step によって 1 つ以上のレコードブロックが受け取られ、並列での処理が開始されます。
2Batch Step コンポーネントはレコードを処理した後で、さらに処理するためにレコードを Batch Aggregator コンポーネントに送信します。
3固定サイズ (​size​) を処理するよう設定した場合、Aggregator コンポーネントによってレコードが指定した数のレコードが含まれる 1 つ以上のブロックに配置されます。レコードが設定したサイズより少ない場合、最後のレコードのブロックが小さくなります。
4特定の配列でレコードを処理した後で、Batch Aggregator コンポーネントではすべてのレコードブロックがステッピングキューに送信されます。
- Batch Aggregator コンポーネントがレコードをストリーミングするよう設定されているときの動作: ストリーミング時には、Batch Aggregator コンポーネントではレコードをレコードブロックに配置するのではなく、受け取った直後にレコードを処理します。アグリゲーターのすべてのレコードで​_現在_​の Batch Step のすべてのレコードが処理されるまで、レコードは​_次_​の Batch Step コンポーネントに公開されません。 コンポーネント内のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。 ![ストリーミングアグリゲーターが含まれる Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-batch-job-process-aggregator-streaming.png)
1各 Batch Step コンポーネントで 1 つ以上のレコードブロックを受け取り、レコードブロックの並列処理を開始します。
2Batch Step でレコードを処理したら、レコードを Batch Aggregator に送信してさらに処理を行います。
3Batch Aggregator コンポーネントでは、現在の Batch Step による処理を待機している、ステッピングキュー内のレコードがなくなるまでレコードの処理を継続します。
4Batch Aggregator コンポーネントでは集約したすべてのレコードがステッピングキューに送信されます。
Mule では、各 Batch Step での処理に成功または失敗したすべてのレコードのリストを保持しています。Batch Step のイベントプロセッサーでレコードの処理に失敗した場合、Mule はバッチの処理を続行し、後続の各 Batch Step では ​`acceptPolicy`​ に基づいて失敗したレコードをスキップします。Batch Job コンポーネントには、Batch Job が停止する前に失敗できるレコードの数を設定するための ​`maxFailedRecords`​ プロパティが用意されています。​[「Batch Job のプロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-reference#ref_batch_job_general_fields)​を参照してください。 ## [](#phase_on_complete)On Complete フェーズ このフェーズ中、特定の Batch Job インスタンスで処理したレコードのレポートまたは概要を作成するように Mule Runtime を設定できます。このフェーズでは、システム管理者および開発者に、どのレコードが処理に失敗し、どのレコードが正常に処理されたかに関するインサイトが提供されますが、各レコードの処理が行われたり各レコードへのアクセスが提供されたりすることはなく、処理されたレコードがフローのダウンストリームプロセッサーに渡されたりすることもありません。 このフェーズの終了時に Batch Job インスタンスは完了し、消滅します。 ベストプラクティスとしては、失敗または成功したレコードについて報告するための何らかのメカニズムを設定し、必要な場合は追加アクションの実行を促してください。On Complete フェーズ中に、次のいずれかのタスクを実行できます。 - Mule アプリケーションの他の場所にある Batch Job の結果オブジェクトを参照し、特定の Batch Job インスタンスで処理に失敗したレコード数などの Batch Job メタデータを取得および使用する。 - 各 Batch Job インスタンスの結果オブジェクトを記録する。 ```xml ``` ロガーから ​`payload as Object`​ に設定すると、レポートは次のようになります。 INFO 2022-07-06 11:39:02,921 \[\[MuleRuntime\].uber.06: \[w-batch-take6\].batch-management-work-manager @56978b97\] \[processor: w-batch-take6Flow/processors/3/route/1/processors/0; event: e835b2c0-fd5a-11ec-84a5-147ddaaf4f97\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: {onCompletePhaseException=null, loadingPhaseException=null, totalRecords=1000, elapsedTimeInMillis=117, failedOnCompletePhase=false, failedRecords=0, loadedRecords=1000, failedOnInputPhase=false, successfulRecords=1000, inputPhaseException=null, processedRecords=10, failedOnLoadingPhase=false, batchJobInstanceId=e84b5da0-fd5a-11ec-84a5-147ddaaf4f97} インスタンス内で失敗したレコードの数を返す ​`payload.failedRecords`​ のように、Batch Job レポートオブジェクトの項目は DataWeave セレクターを使用するときのキーとしてアクセスできます。 On Complete フェーズを空のままにすると、Batch Job インスタンスは警告なしに完了し、たとえば次のように、インスタンスに関する処理情報がログで提供されます。 Finished execution for instance 'e84b5da0-fd5a-11ec-84a5-147ddaaf4f97' of job 'w-batch-take6Batch\_Job'. Total Records processed: 1000. Successful records: 1000. Failed Records: 0 # Batch Job のフェーズ Batch Job コンポーネントが実行されるたびに、次のフェーズが行われます。 1. [Load and Dispatch フェーズ](#phase_load_dispatch)​: Batch Job コンポーネントにより​[有効な入力](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-processing-concept#valid_input)​がレコードに分割され、レコードを処理する準備が整えられます。このフェーズは Batch Job コンポーネント内で行われます。 2. [Process フェーズ](#phase_process)​: Batch Job の 1 つ以上の Batch Step コンポーネント内の Mule コンポーネントおよびコネクタの操作により、特定の Batch Job インスタンス内のレコードが処理されます。Batch Aggregator コンポーネント内での処理も Process フェーズで行われます。 3. [On Complete フェーズ](#phase_on_complete)​: Batch Job コンポーネントにより、Batch Job インスタンスの処理の結果が含まれるレポートオブジェクトが発行されます。 例については、​[バッチフェーズの XML](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-processing-concept#batch_phases_xml)​ を参照してください。 ## [](#phase_load_dispatch)Load and Dispatch フェーズ フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Load and Dispatch フェーズが開始されます。このフェーズでは、以下が行われます。 1. Mule によって、Batch Job の各フェーズで保持される新しい Batch Job インスタンスが作成されます。 Batch Job コンポーネントのスコープ内で、​`batchJobInstanceId`​ 変数を使用して現在処理中の Batch Job インスタンス ID が Mule によって公開されます。​`vars.batchJobInstanceId`​ を使用して、任意のバッチ処理フェーズで現在のインスタンスの識別子にアクセスできます。自動生成される識別子は UUID ですが、別の値に変更できます。詳細は、[Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-job-instance-id)を参照してください。 2. Batch Job コンポーネントにより、受信されたメッセージペイロードが自動的にレコードに分割され、ステッピングキューにレコードが格納されます。 Batch Job コンポーネントによって入力のすべての項目のレコードが正常に生成され、キューに追加されるか、​`MULE:EXPRESSION`​ メッセージなどのエラータイプと ​`"Expecting Array or Object but got String." evaluating expression: "payload"`​ などのエラーメッセージでイベント全体が失敗します。 Anypoint Runtime Manager では、たとえば次のようにキュー名に ​`BSQ`​ というプレフィックスが付けられます。 ![Anypoint Runtime Manager の Batch Step キュートランザクションログ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-batch-bsq.png) 3. Batch Job コンポーネントにより、読み込まれたレコードを処理する Batch Job インスタンスの実行が開始されます。 ## [](#phase_process)Process フェーズ Process フェーズは、Load and Dispatch でキューへのレコードの読み込みを完了し、Batch Job インスタンスの処理を開始した後に開始されます。このフェーズでは、Batch Step コンポーネントによって設定済みのサイズのレコードブロックがキューから抽出され、処理されます。(デフォルトのバッチブロックサイズは 100 です)。 Batch Step コンポーネント内での処理はブロックレベルで並列に行われますが、各ブロック内のレコードはデフォルトで順次処理されます。Mule では、自動調整機能によって、使用するスレッド数と適用する並列性レベルが決定されます (​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.8/execution-engine)​を参照)。 このフェーズ中、コンポーネント内のプロセッサーは ​`payload`​ および ​`vars`​ Mule 変数を使用してレコードにアクセスし、変更を行います。Batch Job ではすべてのレコードの処理が完了した後でレコードがコンシュームされます。そのため、​_処理済み_​レコードを外部サーバーまたはサービスに転送する場合は、Batch Step または Batch Aggregator コンポーネント​_内_​で転送する必要があります。Mule 変数の伝播ルールについては、​[「変数の伝播」](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-processing-concept#variable_propagation)​を参照してください。 Batch Step ではブロック内のレコードを処理した後に、レコードをステッピングキューに送信します。ステッピングキューでは、レコードは次の Batch Step を待機します。すべてのレコードが同じ Batch Job コンポーネント内のすべての Batch Step を通過するまで、このプロセスが続行されます。このフェーズの最後の時点で、すべてのレコードがコンシュームされます。Mule フローのダウンストリームプロセッサーによる追加の処理には使用できません。 Batch Aggregator コンポーネント内で行われるレコードに対する変更は Batch Aggregator コンポーネント外に​_伝播されない_​ため、変更内容はフローの後続の Batch Step コンポーネントでは表示されませんのでご注意ください。 ![複数の Batch Step のレコードのステッピングキューが含まれる Batch Job インスタンス](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-batch-step-process.png) 処理が行われるときに、各レコードはすべての Batch Step コンポーネントでの処理を監視します。 デフォルトでは、Batch Job インスタンスは、キューに追加されたすべてのレコードが 1 つの Batch Step コンポーネントでの処理を終了するのを待たずに、レコードを次の Batch Step で処理できるようにします。Batch Aggregator コンポーネントを設定するとこの動作が変更されます。 - Batch Aggregator コンポーネントが固定サイズを設定するときの動作: Batch Aggregator 内のプロセッサーは入力としてレコードの配列を受け取れる必要があります。 ![固定サイズのアグリゲーターが含まれる Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-batch-job-process-aggregator-fixed.png)
1Batch Job コンポーネント内の各 Batch Step によって 1 つ以上のレコードブロックが受け取られ、並列での処理が開始されます。
2Batch Step コンポーネントはレコードを処理した後で、さらに処理するためにレコードを Batch Aggregator コンポーネントに送信します。
3固定サイズ (​size​) を処理するよう設定した場合、Aggregator コンポーネントによってレコードが指定した数のレコードが含まれる 1 つ以上のブロックに配置されます。レコードが設定したサイズより少ない場合、最後のレコードのブロックが小さくなります。
4特定の配列でレコードを処理した後で、Batch Aggregator コンポーネントではすべてのレコードブロックがステッピングキューに送信されます。
- Batch Aggregator コンポーネントがレコードをストリーミングするよう設定されているときの動作: ストリーミング時には、Batch Aggregator コンポーネントではレコードをレコードブロックに配置するのではなく、受け取った直後にレコードを処理します。アグリゲーターのすべてのレコードで​_現在_​の Batch Step のすべてのレコードが処理されるまで、レコードは​_次_​の Batch Step コンポーネントに公開されません。 コンポーネント内のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。 ![ストリーミングアグリゲーターが含まれる Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-batch-job-process-aggregator-streaming.png)
1各 Batch Step コンポーネントで 1 つ以上のレコードブロックを受け取り、レコードブロックの並列処理を開始します。
2Batch Step でレコードを処理したら、レコードを Batch Aggregator に送信してさらに処理を行います。
3Batch Aggregator コンポーネントでは、現在の Batch Step による処理を待機している、ステッピングキュー内のレコードがなくなるまでレコードの処理を継続します。
4Batch Aggregator コンポーネントでは集約したすべてのレコードがステッピングキューに送信されます。
Mule では、各 Batch Step での処理に成功または失敗したすべてのレコードのリストを保持しています。Batch Step のイベントプロセッサーでレコードの処理に失敗した場合、Mule はバッチの処理を続行し、後続の各 Batch Step では ​`acceptPolicy`​ に基づいて失敗したレコードをスキップします。Batch Job コンポーネントには、Batch Job が停止する前に失敗できるレコードの数を設定するための ​`maxFailedRecords`​ プロパティが用意されています。​[「Batch Job のプロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-reference#ref_batch_job_general_fields)​を参照してください。 ## [](#phase_on_complete)On Complete フェーズ このフェーズ中、特定の Batch Job インスタンスで処理したレコードのレポートまたは概要を作成するように Mule Runtime を設定できます。このフェーズでは、システム管理者および開発者に、どのレコードが処理に失敗し、どのレコードが正常に処理されたかに関するインサイトが提供されますが、各レコードの処理が行われたり各レコードへのアクセスが提供されたりすることはなく、処理されたレコードがフローのダウンストリームプロセッサーに渡されたりすることもありません。 このフェーズの終了時に Batch Job インスタンスは完了し、消滅します。 ベストプラクティスとしては、失敗または成功したレコードについて報告するための何らかのメカニズムを設定し、必要な場合は追加アクションの実行を促してください。On Complete フェーズ中に、次のいずれかのタスクを実行できます。 - Mule アプリケーションの他の場所にある Batch Job の結果オブジェクトを参照し、特定の Batch Job インスタンスで処理に失敗したレコード数などの Batch Job メタデータを取得および使用する。 - 各 Batch Job インスタンスの結果オブジェクトを記録する。 ```xml ``` ロガーから ​`payload as Object`​ に設定すると、レポートは次のようになります。 INFO 2022-07-06 11:39:02,921 \[\[MuleRuntime\].uber.06: \[w-batch-take6\].batch-management-work-manager @56978b97\] \[processor: w-batch-take6Flow/processors/3/route/1/processors/0; event: e835b2c0-fd5a-11ec-84a5-147ddaaf4f97\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: {onCompletePhaseException=null, loadingPhaseException=null, totalRecords=1000, elapsedTimeInMillis=117, failedOnCompletePhase=false, failedRecords=0, loadedRecords=1000, failedOnInputPhase=false, successfulRecords=1000, inputPhaseException=null, processedRecords=10, failedOnLoadingPhase=false, batchJobInstanceId=e84b5da0-fd5a-11ec-84a5-147ddaaf4f97} インスタンス内で失敗したレコードの数を返す ​`payload.failedRecords`​ のように、Batch Job レポートオブジェクトの項目は DataWeave セレクターを使用するときのキーとしてアクセスできます。 On Complete フェーズを空のままにすると、Batch Job インスタンスは警告なしに完了し、たとえば次のように、インスタンスに関する処理情報がログで提供されます。 Finished execution for instance 'e84b5da0-fd5a-11ec-84a5-147ddaaf4f97' of job 'w-batch-take6Batch\_Job'. Total Records processed: 1000. Successful records: 1000. Failed Records: 0 # Batch Job のフェーズ Batch Job コンポーネントが実行されるたびに、次のフェーズが行われます。 1. [Load and Dispatch フェーズ](#phase_load_dispatch)​: Batch Job コンポーネントにより​[有効な入力](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-processing-concept#valid_input)​がレコードに分割され、レコードを処理する準備が整えられます。このフェーズは Batch Job コンポーネント内で行われます。 2. [Process フェーズ](#phase_process)​: Batch Job の 1 つ以上の Batch Step コンポーネント内の Mule コンポーネントおよびコネクタの操作により、特定の Batch Job インスタンス内のレコードが処理されます。Batch Aggregator コンポーネント内での処理も Process フェーズで行われます。 3. [On Complete フェーズ](#phase_on_complete)​: Batch Job コンポーネントにより、Batch Job インスタンスの処理の結果が含まれるレポートオブジェクトが発行されます。 例については、​[バッチフェーズの XML](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-processing-concept#batch_phases_xml)​ を参照してください。 ## [](#phase_load_dispatch)Load and Dispatch フェーズ フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Load and Dispatch フェーズが開始されます。このフェーズでは、以下が行われます。 1. Mule によって、Batch Job の各フェーズで保持される新しい Batch Job インスタンスが作成されます。 Batch Job コンポーネントのスコープ内で、​`batchJobInstanceId`​ 変数を使用して現在処理中の Batch Job インスタンス ID が Mule によって公開されます。​`vars.batchJobInstanceId`​ を使用して、任意のバッチ処理フェーズで現在のインスタンスの識別子にアクセスできます。自動生成される識別子は UUID ですが、別の値に変更できます。詳細は、[Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-job-instance-id)を参照してください。 2. Batch Job コンポーネントにより、受信されたメッセージペイロードが自動的にレコードに分割され、ステッピングキューにレコードが格納されます。 Batch Job コンポーネントによって入力のすべての項目のレコードが正常に生成され、キューに追加されるか、​`MULE:EXPRESSION`​ メッセージなどのエラータイプと ​`"Expecting Array or Object but got String." evaluating expression: "payload"`​ などのエラーメッセージでイベント全体が失敗します。 Anypoint Runtime Manager では、たとえば次のようにキュー名に ​`BSQ`​ というプレフィックスが付けられます。 ![Anypoint Runtime Manager の Batch Step キュートランザクションログ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-batch-bsq.png) 3. Batch Job コンポーネントにより、読み込まれたレコードを処理する Batch Job インスタンスの実行が開始されます。 ## [](#phase_process)Process フェーズ Process フェーズは、Load and Dispatch でキューへのレコードの読み込みを完了し、Batch Job インスタンスの処理を開始した後に開始されます。このフェーズでは、Batch Step コンポーネントによって設定済みのサイズのレコードブロックがキューから抽出され、処理されます。(デフォルトのバッチブロックサイズは 100 です)。 Batch Step コンポーネント内での処理はブロックレベルで並列に行われますが、各ブロック内のレコードはデフォルトで順次処理されます。Mule では、自動調整機能によって、使用するスレッド数と適用する並列性レベルが決定されます (​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.9/execution-engine)​を参照)。 このフェーズ中、コンポーネント内のプロセッサーは ​`payload`​ および ​`vars`​ Mule 変数を使用してレコードにアクセスし、変更を行います。Batch Job ではすべてのレコードの処理が完了した後でレコードがコンシュームされます。そのため、​_処理済み_​レコードを外部サーバーまたはサービスに転送する場合は、Batch Step または Batch Aggregator コンポーネント​_内_​で転送する必要があります。Mule 変数の伝播ルールについては、​[「変数の伝播」](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-processing-concept#variable_propagation)​を参照してください。 Batch Step ではブロック内のレコードを処理した後に、レコードをステッピングキューに送信します。ステッピングキューでは、レコードは次の Batch Step を待機します。すべてのレコードが同じ Batch Job コンポーネント内のすべての Batch Step を通過するまで、このプロセスが続行されます。このフェーズの最後の時点で、すべてのレコードがコンシュームされます。Mule フローのダウンストリームプロセッサーによる追加の処理には使用できません。 Batch Aggregator コンポーネント内で行われるレコードに対する変更は Batch Aggregator コンポーネント外に​_伝播されない_​ため、変更内容はフローの後続の Batch Step コンポーネントでは表示されませんのでご注意ください。 ![複数の Batch Step のレコードのステッピングキューが含まれる Batch Job インスタンス](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-batch-step-process.png) 処理が行われるときに、各レコードはすべての Batch Step コンポーネントでの処理を監視します。 デフォルトでは、Batch Job インスタンスは、キューに追加されたすべてのレコードが 1 つの Batch Step コンポーネントでの処理を終了するのを待たずに、レコードを次の Batch Step で処理できるようにします。Batch Aggregator コンポーネントを設定するとこの動作が変更されます。 - Batch Aggregator コンポーネントが固定サイズを設定するときの動作: Batch Aggregator 内のプロセッサーは入力としてレコードの配列を受け取れる必要があります。 ![固定サイズのアグリゲーターが含まれる Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-batch-job-process-aggregator-fixed.png)
1Batch Job コンポーネント内の各 Batch Step によって 1 つ以上のレコードブロックが受け取られ、並列での処理が開始されます。
2Batch Step コンポーネントはレコードを処理した後で、さらに処理するためにレコードを Batch Aggregator コンポーネントに送信します。
3固定サイズ (​size​) を処理するよう設定した場合、Aggregator コンポーネントによってレコードが指定した数のレコードが含まれる 1 つ以上のブロックに配置されます。レコードが設定したサイズより少ない場合、最後のレコードのブロックが小さくなります。
4特定の配列でレコードを処理した後で、Batch Aggregator コンポーネントではすべてのレコードブロックがステッピングキューに送信されます。
- Batch Aggregator コンポーネントがレコードをストリーミングするよう設定されているときの動作: ストリーミング時には、Batch Aggregator コンポーネントではレコードをレコードブロックに配置するのではなく、受け取った直後にレコードを処理します。アグリゲーターのすべてのレコードで​_現在_​の Batch Step のすべてのレコードが処理されるまで、レコードは​_次_​の Batch Step コンポーネントに公開されません。 コンポーネント内のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。 ![ストリーミングアグリゲーターが含まれる Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-batch-job-process-aggregator-streaming.png)
1各 Batch Step コンポーネントで 1 つ以上のレコードブロックを受け取り、レコードブロックの並列処理を開始します。
2Batch Step でレコードを処理したら、レコードを Batch Aggregator に送信してさらに処理を行います。
3Batch Aggregator コンポーネントでは、現在の Batch Step による処理を待機している、ステッピングキュー内のレコードがなくなるまでレコードの処理を継続します。
4Batch Aggregator コンポーネントでは集約したすべてのレコードがステッピングキューに送信されます。
Mule では、各 Batch Step での処理に成功または失敗したすべてのレコードのリストを保持しています。Batch Step のイベントプロセッサーでレコードの処理に失敗した場合、Mule はバッチの処理を続行し、後続の各 Batch Step では ​`acceptPolicy`​ に基づいて失敗したレコードをスキップします。Batch Job コンポーネントには、Batch Job が停止する前に失敗できるレコードの数を設定するための ​`maxFailedRecords`​ プロパティが用意されています。​[「Batch Job のプロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-reference#ref_batch_job_general_fields)​を参照してください。 ## [](#phase_on_complete)On Complete フェーズ このフェーズ中、特定の Batch Job インスタンスで処理したレコードのレポートまたは概要を作成するように Mule Runtime を設定できます。このフェーズでは、システム管理者および開発者に、どのレコードが処理に失敗し、どのレコードが正常に処理されたかに関するインサイトが提供されますが、各レコードの処理が行われたり各レコードへのアクセスが提供されたりすることはなく、処理されたレコードがフローのダウンストリームプロセッサーに渡されたりすることもありません。 このフェーズの終了時に Batch Job インスタンスは完了し、消滅します。 ベストプラクティスとしては、失敗または成功したレコードについて報告するための何らかのメカニズムを設定し、必要な場合は追加アクションの実行を促してください。On Complete フェーズ中に、次のいずれかのタスクを実行できます。 - Mule アプリケーションの他の場所にある Batch Job の結果オブジェクトを参照し、特定の Batch Job インスタンスで処理に失敗したレコード数などの Batch Job メタデータを取得および使用する。 - 各 Batch Job インスタンスの結果オブジェクトを記録する。 ```xml ``` ロガーから ​`payload as Object`​ に設定すると、レポートは次のようになります。 INFO 2022-07-06 11:39:02,921 \[\[MuleRuntime\].uber.06: \[w-batch-take6\].batch-management-work-manager @56978b97\] \[processor: w-batch-take6Flow/processors/3/route/1/processors/0; event: e835b2c0-fd5a-11ec-84a5-147ddaaf4f97\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: {onCompletePhaseException=null, loadingPhaseException=null, totalRecords=1000, elapsedTimeInMillis=117, failedOnCompletePhase=false, failedRecords=0, loadedRecords=1000, failedOnInputPhase=false, successfulRecords=1000, inputPhaseException=null, processedRecords=10, failedOnLoadingPhase=false, batchJobInstanceId=e84b5da0-fd5a-11ec-84a5-147ddaaf4f97} インスタンス内で失敗したレコードの数を返す ​`payload.failedRecords`​ のように、Batch Job レポートオブジェクトの項目は DataWeave セレクターを使用するときのキーとしてアクセスできます。 On Complete フェーズを空のままにすると、Batch Job インスタンスは警告なしに完了し、たとえば次のように、インスタンスに関する処理情報がログで提供されます。 Finished execution for instance 'e84b5da0-fd5a-11ec-84a5-147ddaaf4f97' of job 'w-batch-take6Batch\_Job'. Total Records processed: 1000. Successful records: 1000. Failed Records: 0 # Batch Job 中のエラー処理 Mule バッチ処理は、非常に大規模なデータセットを処理して、ほぼリアルタイムのデータインテグレーションを実行できるように設計されており、クラッシュから復旧して、ジョブの処理を障害が発生した時点から続行できます。ただし、大規模なデータセットでは、発生する問題の​_冗長_​ログが膨大なサイズとなり、パフォーマンスが大きく低下する原因になることがあります。 この影響を抑えるため、Mule では​[Batch Step 内の失敗したレコードのログ](#default_logging)​で説明するように INFO レベルのログをデフォルトで使用します。より冗長なログメッセージが必要な場合は、モードを DEBUG に変更してください。このモードはデバッグに便利であり、小規模のデータセットを使用するケースで使用できます。 ログモードは次のプロパティで設定します。 ```text log4j.logger.com.mulesoft.module.batch=DEBUG ``` 本番環境で大規模なデータセットを処理する場合は、DEBUG モードは使用しないでください。 ## [](#default_logging)Batch Step 内の失敗したレコードのログ Batch Step インスタンスを処理するときに、たとえばレコードデータが破損していたり不完全であったりすることなどが原因で、Batch Step 内のプロセッサーが失敗したりエラーを発生させたりすることがあります。問題が発生した場合、デフォルトでは、Mule は INFO ログレベルを使用して、次のロジックに従ってスタックトレースをログに記録します。 1. Mule が例外の完全なスタック追跡を取得します。 2. Mule がログ内のエラーメッセージからスタックトレースを削除します。 すべてのレコードで同じエラーが発生したとしても、処理中のメッセージにはおそらくそれらのレコードに関連する特定の情報が含まれています。たとえば、リードを Salesforce アカウントに転送していて、特定のリードはすでにアップロード済みであるため 1 つのレコードがエラーになった場合、別の繰り返されるリードのレコード情報は異なりますが、同じエラーになります。 3. Mule はスタック追跡がすでに現在のステップに記録されているかどうかを検証します。 ランタイムでこのエラーに初めて遭遇すると、Mule はエラーをログに記録して、次のようなメッセージを生成します。 ```text com.mulesoft.mule.runtime.module.batch.internal.DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'Batch Job Example' of job 'CreateLeadsBatch'. This is the first record to show this exception on this step for this job instance. Subsequent records with the same failures will not be logged for performance and log readability reasons: ``` Mule は「ステップごと」にログを記録します。別のステップでも同じエラーが発生した場合、ランタイムはそのステップに対してもログを記録します。 4. Batch Job が On Complete (完了時) フェーズに達すると、Mule にはエラー概要とすべてのエラーの種別、および各 Batch Step での発生回数が表示されます。 `batch.exception`​ 種別が発生した 2 つの Batch Step が含まれる Batch Job のエラー概要を次に示します。 ```text ************************************************************************************************************************ * - - + Exception Type + - - * - - + Step + - - * - - + Count + - - * ************************************************************************************************************************ * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep1 * 10 * * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep2 * 9 * ************************************************************************************************************************ ``` ここでは、最初のステップが 10 回失敗し、2 番目のステップが 9 回失敗しています。 ## [](#エラー処理用の-dataweave-関数)エラー処理用の DataWeave 関数 Mule 4.x には、Batch Step のコンテキストで使用できる DataWeave 関数のセットが含まれています。
DataWeave 関数 説明

#[Batch::isSuccessfulRecord()]

現在のレコードが前のステップで例外をスローしなかった場合に true を返すブール関数。

#[Batch::isFailedRecord()]

現在のレコードが前のステップで例外をスローした場合に true を返すブール関数。

#[Batch::failureExceptionForStep(String)]

ステップの名前を文字列引数として受け取ります。現在のレコードがそのステップで例外をスローした場合、実際の例外オブジェクトを返します。それ以外の場合は null を返します。

#[Batch::getStepExceptions()]

Java ​Map<String, Exception>​ を返します。キーは現在のレコードが失敗した Batch Step の名前で、値は例外自体です。
レコードがどのステップでも失敗しなかった場合、この Map は空になりますが null になることはありません。また、Map にはレコードが失敗しなかったステップのエントリは含まれません。

#[Batch::getFirstException()]

現在のレコードが失敗した最初のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。

#[Batch::getLastException()]

現在のレコードが失敗した最後のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。
### [](#例)例 連絡先情報を含むファイルをポーリングする Batch Job があるとします。 最初のステップでは、Batch Job は連絡先情報を集約し、Transform Message コンポーネントを使用してそれらを変換してから Salesforce に転送します。 2 番目のステップでは、ジョブはその同じ連絡先を別のサードパーティ連絡先アプリケーション (Google コンタクトなど) のデータ構造と一致するように再度変換し、HTTP 要求を使用してこのサービスに転送します。 次に、3 番目のステップとして、失敗したレコードごとに JMS デッドレターキューに書き込むことができる必要があるとします。簡略化するため、例外自体をメッセージにするとします。この要件には注意が必要です。各レコードが両方のステップで失敗し、同じレコードが 2 つの JMS メッセージに変換される可能性があります。 このアプリケーションは次のようになります。 ![batch error handling faq f34d5](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/batch-error-handling-faq-f34d5.png) 目標は失敗を収集することであるため、ONLY\_FAILURES 検索条件を使用して ​`Failures`​ ステップを設定することが理にかなっています (バッチ検索条件についての詳細は​[「Batch Step 処理の絞り込み」](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-filters-and-batch-aggregator)​参照)。 このステップの set-payload プロセッサーは、​`Batch::getStepExceptions()`​ 関数を使用するように設定できます。 ![batch error handling faq 6269e](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/batch-error-handling-faq-6269e.png) 上述のように、この関数はすべてのステップで見つかったすべてのエラーを含むマップを返します。ここでの目標は JMS を介して例外を送信することであり、ステップを気にする必要はないため、foreach スコープを使用してマップの値 (エラー) を反復処理し、JMS アウトバウンドエンドポイントを介して送信できます。 ![batch error handling faq b822e](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/batch-error-handling-faq-b822e.png) ## [](#エラー処理用のバッチ処理戦略)エラー処理用のバッチ処理戦略 Mule には、レコードレベルのエラーを処理するための 3 つのオプションがあります。 1. **処理を終了**​。現在のジョブインスタンスの実行を停止します。現在インフライト状態のレコードの実行を終了しますが、キューからそれ以上レコードを取得せずにジョブインスタンスを ​`FAILURE`​ 状態に設定します。On Complete (完了時) フェーズが呼び出されます。 2. 失敗したレコード数に関係なく​**処理を続行**​。​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Step に指示します。 3. Batch Job が​**失敗したレコードの最大数**​に達するまで、失敗したレコード数に関係なく​**処理を続行**​ (​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Job に指示します)。最大数に達した時点で、オプション 1 と同様に実行を停止します。 デフォルトでは、Mule の Batch Job はバッチインスタンスの実行を停止する最初のエラー処理戦略に従います。上記の動作は、​`maxFailedRecords`​ 属性を使用して制御されます。
失敗したレコードの処理オプション Batch Job 属性 値

失敗したレコードが見つかったときに処理を停止

maxFailedRecords

0​

失敗したレコード数に関係なく、無期限に処理を続行

maxFailedRecords

-1​

失敗したレコードの最大数に達するまで処理を続行

maxFailedRecords

integer
```xml ``` ### [](#最大失敗しきい値の超過)最大失敗しきい値の超過 Batch Job で ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数が蓄積されると、Mule は残りの Batch Job の処理を中止し、On Complete (完了時) フェーズに直接移動します。 たとえば、​`maxFailedRecords`​ の値を「10」に設定し、Batch Job が 3 つの Batch Step 最初のステップで失敗したレコードを 10 件蓄積した場合、Mule は残り 2 つの Batch Step ではバッチを処理しません。代わりに、それ以降の処理を中止し、On Complete (完了時) に直接移動して Batch Job の失敗を報告します。 Batch Job が ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数を蓄積​_しない_​場合、​_すべての_​レコード (成功と失敗) が引き続き Batch Step 間を移動します。各 Batch Step で処理するレコードを制御するには、検索条件を使用します。 ## [](#関連情報)関連情報 - [Batch Step 処理の絞り込み](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-filters-and-batch-aggregator) # Batch Job 中のエラー処理 Mule バッチ処理は、非常に大規模なデータセットを処理して、ほぼリアルタイムのデータインテグレーションを実行できるように設計されており、クラッシュから復旧して、ジョブの処理を障害が発生した時点から続行できます。ただし、大規模なデータセットでは、発生する問題の​_冗長_​ログが膨大なサイズとなり、パフォーマンスが大きく低下する原因になることがあります。 この影響を抑えるため、Mule では​[Batch Step 内の失敗したレコードのログ](#default_logging)​で説明するように INFO レベルのログをデフォルトで使用します。より冗長なログメッセージが必要な場合は、モードを DEBUG に変更してください。このモードはデバッグに便利であり、小規模のデータセットを使用するケースで使用できます。 ログモードは次のプロパティで設定します。 ```xml ``` CloudHub または Runtime Manager を使用している場合は、次のパッケージを \[Logs (ログ)\] タブの DEBUG レベルに追加できます。 ```logs com.mulesoft.mule.runtime.module.batch ``` 本番環境で大規模なデータセットを処理する場合は、DEBUG モードは使用しないでください。 ## [](#default_logging)Batch Step 内の失敗したレコードのログ Batch Step インスタンスを処理するときに、たとえばレコードデータが破損していたり不完全であったりすることなどが原因で、Batch Step 内のプロセッサーが失敗したりエラーを発生させたりすることがあります。問題が発生した場合、デフォルトでは、Mule は INFO ログレベルを使用して、次のロジックに従ってスタックトレースをログに記録します。 1. Mule が例外の完全なスタック追跡を取得します。 2. Mule がログ内のエラーメッセージからスタックトレースを削除します。 すべてのレコードで同じエラーが発生したとしても、処理中のメッセージにはおそらくそれらのレコードに関連する特定の情報が含まれています。たとえば、リードを Salesforce アカウントに転送していて、特定のリードはすでにアップロード済みであるため 1 つのレコードがエラーになった場合、別の繰り返されるリードのレコード情報は異なりますが、同じエラーになります。 3. Mule はスタック追跡がすでに現在のステップに記録されているかどうかを検証します。 ランタイムでこのエラーに初めて遭遇すると、Mule はエラーをログに記録して、次のようなメッセージを生成します。 ```logs com.mulesoft.mule.runtime.module.batch.internal.DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'Batch Job Example' of job 'CreateLeadsBatch'. This is the first record to show this exception on this step for this job instance. Subsequent records with the same failures will not be logged for performance and log readability reasons: ``` Mule は「ステップごと」にログを記録します。別のステップでも同じエラーが発生した場合、ランタイムはそのステップに対してもログを記録します。 4. Batch Job が On Complete (完了時) フェーズに達すると、Mule にはエラー概要とすべてのエラーの種別、および各 Batch Step での発生回数が表示されます。 `batch.exception`​ 種別が発生した 2 つの Batch Step が含まれる Batch Job のエラー概要を次に示します。 ```logs ******************************************************************************* * - - + Exception Type + - - * - - + Step + - - * - - + Count + - - * ******************************************************************************* * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep1 * 10 * * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep2 * 9 * ******************************************************************************* ``` ここでは、最初のステップが 10 回失敗し、2 番目のステップが 9 回失敗しています。 Mule のデフォルト設定ではこの動作を使用してバッチエラーをログに記録します。これは INFO レベルのメッセージのみをログに記録し、大量なデータをログに記録する場合の効率性のトレードオフとのバランスを取ります。 ただし、バッチ処理を使用する動機は、大規模なデータセットを処理できることではなく、クラッシュから回復し、「ほぼリアルタイム」のデータインテグレーションを実行したときに、中断された場所から Batch Job を処理し続けることかもしれません。または、デバッグ用にさらに詳細なログレベルが必要かもしれません。 ## [](#エラー処理用の-dataweave-関数)エラー処理用の DataWeave 関数 Mule 4.x には、Batch Step のコンテキストで使用できる DataWeave 関数のセットが含まれています。
DataWeave 関数 説明

#[Batch::isSuccessfulRecord()]

現在のレコードが前のステップで例外をスローしなかった場合に true を返すブール関数。

#[Batch::isFailedRecord()]

現在のレコードが前のステップで例外をスローした場合に true を返すブール関数。

#[Batch::failureExceptionForStep(String)]

ステップの名前を文字列引数として受け取ります。現在のレコードがそのステップで例外をスローした場合、実際の例外オブジェクトを返します。それ以外の場合は null を返します。

#[Batch::getStepExceptions()]

Java ​Map<String, Exception>​ を返します。キーは現在のレコードが失敗した Batch Step の名前で、値は例外自体です。
レコードがどのステップでも失敗しなかった場合、この Map は空になりますが null になることはありません。また、Map にはレコードが失敗しなかったステップのエントリは含まれません。

#[Batch::getFirstException()]

現在のレコードが失敗した最初のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。

#[Batch::getLastException()]

現在のレコードが失敗した最後のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。
### [](#例)例 連絡先情報を含むファイルをポーリングする Batch Job があるとします。 最初のステップでは、Batch Job は連絡先情報を集約し、Transform Message コンポーネントを使用してそれらを変換してから Salesforce に転送します。 2 番目のステップでは、ジョブはその同じ連絡先を別のサードパーティ連絡先アプリケーション (Google コンタクトなど) のデータ構造と一致するように再度変換し、HTTP 要求を使用してこのサービスに転送します。 次に、3 番目のステップとして、失敗したレコードごとに JMS デッドレターキューに書き込むことができる必要があるとします。簡略化するため、例外自体をメッセージにするとします。この要件には注意が必要です。各レコードが両方のステップで失敗し、同じレコードが 2 つの JMS メッセージに変換される可能性があります。 このアプリケーションは次のようになります。 ![batch error handling faq f34d5](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/batch-error-handling-faq-f34d5.png) 目標は失敗を収集することであるため、ONLY\_FAILURES 検索条件を使用して ​`Failures`​ ステップを設定することが理にかなっています (バッチ検索条件についての詳細は「[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-filters-and-batch-aggregator)」を参照)。 このステップの set-payload プロセッサーは、​`Batch::getStepExceptions()`​ 関数を使用するように設定できます。 ![batch error handling faq 6269e](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/batch-error-handling-faq-6269e.png) 上述のように、この関数はすべてのステップで見つかったすべてのエラーを含むマップを返します。ここでの目標は JMS を介して例外を送信することであり、ステップを気にする必要はないため、foreach スコープを使用してマップの値 (エラー) を反復処理し、JMS アウトバウンドエンドポイントを介して送信できます。 ![batch error handling faq b822e](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/batch-error-handling-faq-b822e.png) ## [](#エラー処理用のバッチ処理戦略)エラー処理用のバッチ処理戦略 Mule には、レコードレベルのエラーを処理するための 3 つのオプションがあります。 1. **処理を終了**​。現在のジョブインスタンスの実行を停止します。現在インフライト状態のレコードの実行を終了しますが、キューからそれ以上レコードを取得せずにジョブインスタンスを ​`FAILURE`​ 状態に設定します。On Complete (完了時) フェーズが呼び出されます。 2. 失敗したレコード数に関係なく​**処理を続行**​。​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Step に指示します。 3. Batch Job が​**失敗したレコードの最大数**​に達するまで、失敗したレコード数に関係なく​**処理を続行**​ (​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Job に指示します)。最大数に達した時点で、オプション 1 と同様に実行を停止します。 デフォルトでは、Mule の Batch Job はバッチインスタンスの実行を停止する最初のエラー処理戦略に従います。上記の動作は、​`maxFailedRecords`​ 属性を使用して制御されます。
失敗したレコードの処理オプション Batch Job 属性 値

失敗したレコードが見つかったときに処理を停止

maxFailedRecords

0​

失敗したレコード数に関係なく、無期限に処理を続行

maxFailedRecords

-1​

失敗したレコードの最大数に達するまで処理を続行

maxFailedRecords

integer
```xml ``` ### [](#最大失敗しきい値の超過)最大失敗しきい値の超過 Batch Job で ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数が蓄積されると、Mule は残りの Batch Job の処理を中止し、On Complete (完了時) フェーズに直接移動します。 たとえば、​`maxFailedRecords`​ の値を「10」に設定し、Batch Job が 3 つの Batch Step 最初のステップで失敗したレコードを 10 件蓄積した場合、Mule は残り 2 つの Batch Step ではバッチを処理しません。代わりに、それ以降の処理を中止し、On Complete (完了時) に直接移動して Batch Job の失敗を報告します。 Batch Job が ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数を蓄積​_しない_​場合、​_すべての_​レコード (成功と失敗) が引き続き Batch Step 間を移動します。各 Batch Step で処理するレコードを制御するには、検索条件を使用します。 ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-filters-and-batch-aggregator) # Batch Job 中のエラー処理 Mule バッチ処理は、非常に大規模なデータセットを処理して、ほぼリアルタイムのデータインテグレーションを実行できるように設計されており、クラッシュから復旧して、ジョブの処理を障害が発生した時点から続行できます。ただし、大規模なデータセットでは、発生する問題の​_冗長_​ログが膨大なサイズとなり、パフォーマンスが大きく低下する原因になることがあります。 この影響を抑えるため、Mule では​[Batch Step 内の失敗したレコードのログ](#default_logging)​で説明するように INFO レベルのログをデフォルトで使用します。より冗長なログメッセージが必要な場合は、モードを DEBUG に変更してください。このモードはデバッグに便利であり、小規模のデータセットを使用するケースで使用できます。 ログモードは次のプロパティで設定します。 ```xml ``` CloudHub または Runtime Manager を使用している場合は、次のパッケージを \[Logs (ログ)\] タブの DEBUG レベルに追加できます。 ```logs com.mulesoft.mule.runtime.module.batch ``` 本番環境で大規模なデータセットを処理する場合は、DEBUG モードは使用しないでください。 ## [](#default_logging)Batch Step 内の失敗したレコードのログ Batch Step インスタンスを処理するときに、たとえばレコードデータが破損していたり不完全であったりすることなどが原因で、Batch Step 内のプロセッサーが失敗したりエラーを発生させたりすることがあります。問題が発生した場合、デフォルトでは、Mule は INFO ログレベルを使用して、次のロジックに従ってスタックトレースをログに記録します。 1. Mule が例外の完全なスタック追跡を取得します。 2. Mule がログ内のエラーメッセージからスタックトレースを削除します。 すべてのレコードで同じエラーが発生したとしても、処理中のメッセージにはおそらくそれらのレコードに関連する特定の情報が含まれています。たとえば、リードを Salesforce アカウントに転送していて、特定のリードはすでにアップロード済みであるため 1 つのレコードがエラーになった場合、別の繰り返されるリードのレコード情報は異なりますが、同じエラーになります。 3. Mule はスタック追跡がすでに現在のステップに記録されているかどうかを検証します。 ランタイムでこのエラーに初めて遭遇すると、Mule はエラーをログに記録して、次のようなメッセージを生成します。 ```logs com.mulesoft.mule.runtime.module.batch.internal.DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'Batch Job Example' of job 'CreateLeadsBatch'. This is the first record to show this exception on this step for this job instance. Subsequent records with the same failures will not be logged for performance and log readability reasons: ``` Mule は「ステップごと」にログを記録します。別のステップでも同じエラーが発生した場合、ランタイムはそのステップに対してもログを記録します。 4. Batch Job が On Complete (完了時) フェーズに達すると、Mule にはエラー概要とすべてのエラーの種別、および各 Batch Step での発生回数が表示されます。 `batch.exception`​ 種別が発生した 2 つの Batch Step が含まれる Batch Job のエラー概要を次に示します。 ```logs ******************************************************************************* * - - + Exception Type + - - * - - + Step + - - * - - + Count + - - * ******************************************************************************* * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep1 * 10 * * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep2 * 9 * ******************************************************************************* ``` ここでは、最初のステップが 10 回失敗し、2 番目のステップが 9 回失敗しています。 Mule のデフォルト設定ではこの動作を使用してバッチエラーをログに記録します。これは INFO レベルのメッセージのみをログに記録し、大量なデータをログに記録する場合の効率性のトレードオフとのバランスを取ります。 ただし、バッチ処理を使用する動機は、大規模なデータセットを処理できることではなく、クラッシュから回復し、「ほぼリアルタイム」のデータインテグレーションを実行したときに、中断された場所から Batch Job を処理し続けることかもしれません。または、デバッグ用にさらに詳細なログレベルが必要かもしれません。 ## [](#エラー処理用の-dataweave-関数)エラー処理用の DataWeave 関数 Mule 4.x には、Batch Step のコンテキストで使用できる DataWeave 関数のセットが含まれています。
DataWeave 関数 説明

#[Batch::isSuccessfulRecord()]

現在のレコードが前のステップで例外をスローしなかった場合に true を返すブール関数。

#[Batch::isFailedRecord()]

現在のレコードが前のステップで例外をスローした場合に true を返すブール関数。

#[Batch::failureExceptionForStep(String)]

ステップの名前を文字列引数として受け取ります。現在のレコードがそのステップで例外をスローした場合、実際の例外オブジェクトを返します。それ以外の場合は null を返します。

#[Batch::getStepExceptions()]

Java ​Map<String, Exception>​ を返します。キーは現在のレコードが失敗した Batch Step の名前で、値は例外自体です。
レコードがどのステップでも失敗しなかった場合、この Map は空になりますが null になることはありません。また、Map にはレコードが失敗しなかったステップのエントリは含まれません。

#[Batch::getFirstException()]

現在のレコードが失敗した最初のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。

#[Batch::getLastException()]

現在のレコードが失敗した最後のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。
### [](#例)例 連絡先情報を含むファイルをポーリングする Batch Job があるとします。 最初のステップでは、Batch Job は連絡先情報を集約し、Transform Message コンポーネントを使用してそれらを変換してから Salesforce に転送します。 2 番目のステップでは、ジョブはその同じ連絡先を別のサードパーティ連絡先アプリケーション (Google コンタクトなど) のデータ構造と一致するように再度変換し、HTTP 要求を使用してこのサービスに転送します。 次に、3 番目のステップとして、失敗したレコードごとに JMS デッドレターキューに書き込むことができる必要があるとします。簡略化するため、例外自体をメッセージにするとします。この要件には注意が必要です。各レコードが両方のステップで失敗し、同じレコードが 2 つの JMS メッセージに変換される可能性があります。 このアプリケーションは次のようになります。 ![batch error handling faq f34d5](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/batch-error-handling-faq-f34d5.png) 目標は失敗を収集することであるため、ONLY\_FAILURES 検索条件を使用して ​`Failures`​ ステップを設定することが理にかなっています (バッチ検索条件についての詳細は「[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-filters-and-batch-aggregator)」を参照)。 このステップの set-payload プロセッサーは、​`Batch::getStepExceptions()`​ 関数を使用するように設定できます。 ![batch error handling faq 6269e](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/batch-error-handling-faq-6269e.png) 上述のように、この関数はすべてのステップで見つかったすべてのエラーを含むマップを返します。ここでの目標は JMS を介して例外を送信することであり、ステップを気にする必要はないため、foreach スコープを使用してマップの値 (エラー) を反復処理し、JMS アウトバウンドエンドポイントを介して送信できます。 ![batch error handling faq b822e](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/batch-error-handling-faq-b822e.png) ## [](#エラー処理用のバッチ処理戦略)エラー処理用のバッチ処理戦略 Mule には、レコードレベルのエラーを処理するための 3 つのオプションがあります。 1. **処理を終了**​。現在のジョブインスタンスの実行を停止します。現在インフライト状態のレコードの実行を終了しますが、キューからそれ以上レコードを取得せずにジョブインスタンスを ​`FAILURE`​ 状態に設定します。On Complete (完了時) フェーズが呼び出されます。 2. 失敗したレコード数に関係なく​**処理を続行**​。​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Step に指示します。 3. Batch Job が​**失敗したレコードの最大数**​に達するまで、失敗したレコード数に関係なく​**処理を続行**​ (​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Job に指示します)。最大数に達した時点で、オプション 1 と同様に実行を停止します。 デフォルトでは、Mule の Batch Job はバッチインスタンスの実行を停止する最初のエラー処理戦略に従います。上記の動作は、​`maxFailedRecords`​ 属性を使用して制御されます。
失敗したレコードの処理オプション Batch Job 属性 値

失敗したレコードが見つかったときに処理を停止

maxFailedRecords

0​

失敗したレコード数に関係なく、無期限に処理を続行

maxFailedRecords

-1​

失敗したレコードの最大数に達するまで処理を続行

maxFailedRecords

integer
```xml ``` ### [](#最大失敗しきい値の超過)最大失敗しきい値の超過 Batch Job で ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数が蓄積されると、Mule は残りの Batch Job の処理を中止し、On Complete (完了時) フェーズに直接移動します。 たとえば、​`maxFailedRecords`​ の値を「10」に設定し、Batch Job が 3 つの Batch Step 最初のステップで失敗したレコードを 10 件蓄積した場合、Mule は残り 2 つの Batch Step ではバッチを処理しません。代わりに、それ以降の処理を中止し、On Complete (完了時) に直接移動して Batch Job の失敗を報告します。 Batch Job が ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数を蓄積​_しない_​場合、​_すべての_​レコード (成功と失敗) が引き続き Batch Step 間を移動します。各 Batch Step で処理するレコードを制御するには、検索条件を使用します。 ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-filters-and-batch-aggregator) # Batch Job 中のエラー処理 Mule バッチ処理は、非常に大規模なデータセットを処理して、ほぼリアルタイムのデータインテグレーションを実行できるように設計されており、クラッシュから復旧して、ジョブの処理を障害が発生した時点から続行できます。ただし、大規模なデータセットでは、発生する問題の​_冗長_​ログが膨大なサイズとなり、パフォーマンスが大きく低下する原因になることがあります。 この影響を抑えるため、Mule では​[Batch Step 内の失敗したレコードのログ](#default_logging)​で説明するように INFO レベルのログをデフォルトで使用します。より冗長なログメッセージが必要な場合は、モードを DEBUG に変更してください。このモードはデバッグに便利であり、小規模のデータセットを使用するケースで使用できます。 ログモードは次のプロパティで設定します。 ```xml ``` CloudHub または Runtime Manager を使用している場合は、次のパッケージを \[Logs (ログ)\] タブの DEBUG レベルに追加できます。 ```logs com.mulesoft.mule.runtime.module.batch ``` 本番環境で大規模なデータセットを処理する場合は、DEBUG モードは使用しないでください。 ## [](#default_logging)Batch Step 内の失敗したレコードのログ Batch Step インスタンスを処理するときに、たとえばレコードデータが破損していたり不完全であったりすることなどが原因で、Batch Step 内のプロセッサーが失敗したりエラーを発生させたりすることがあります。問題が発生した場合、デフォルトでは、Mule は INFO ログレベルを使用して、次のロジックに従ってスタックトレースをログに記録します。 1. Mule が例外の完全なスタック追跡を取得します。 2. Mule がログ内のエラーメッセージからスタックトレースを削除します。 すべてのレコードで同じエラーが発生したとしても、処理中のメッセージにはおそらくそれらのレコードに関連する特定の情報が含まれています。たとえば、リードを Salesforce アカウントに転送していて、特定のリードはすでにアップロード済みであるため 1 つのレコードがエラーになった場合、別の繰り返されるリードのレコード情報は異なりますが、同じエラーになります。 3. Mule はスタック追跡がすでに現在のステップに記録されているかどうかを検証します。 ランタイムでこのエラーに初めて遭遇すると、Mule はエラーをログに記録して、次のようなメッセージを生成します。 ```logs com.mulesoft.mule.runtime.module.batch.internal.DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'Batch Job Example' of job 'CreateLeadsBatch'. This is the first record to show this exception on this step for this job instance. Subsequent records with the same failures will not be logged for performance and log readability reasons: ``` Mule は「ステップごと」にログを記録します。別のステップでも同じエラーが発生した場合、ランタイムはそのステップに対してもログを記録します。 4. Batch Job が On Complete (完了時) フェーズに達すると、Mule にはエラー概要とすべてのエラーの種別、および各 Batch Step での発生回数が表示されます。 `batch.exception`​ 種別が発生した 2 つの Batch Step が含まれる Batch Job のエラー概要を次に示します。 ```logs ******************************************************************************* * - - + Exception Type + - - * - - + Step + - - * - - + Count + - - * ******************************************************************************* * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep1 * 10 * * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep2 * 9 * ******************************************************************************* ``` ここでは、最初のステップが 10 回失敗し、2 番目のステップが 9 回失敗しています。 Mule のデフォルト設定ではこの動作を使用してバッチエラーをログに記録します。これは INFO レベルのメッセージのみをログに記録し、大量なデータをログに記録する場合の効率性のトレードオフとのバランスを取ります。 ただし、バッチ処理を使用する動機は、大規模なデータセットを処理できることではなく、クラッシュから回復し、「ほぼリアルタイム」のデータインテグレーションを実行したときに、中断された場所から Batch Job を処理し続けることかもしれません。または、デバッグ用にさらに詳細なログレベルが必要かもしれません。 ## [](#エラー処理用の-dataweave-関数)エラー処理用の DataWeave 関数 Mule 4.x には、Batch Step のコンテキストで使用できる DataWeave 関数のセットが含まれています。
DataWeave 関数 説明

#[Batch::isSuccessfulRecord()]

現在のレコードが前のステップで例外をスローしなかった場合に true を返すブール関数。

#[Batch::isFailedRecord()]

現在のレコードが前のステップで例外をスローした場合に true を返すブール関数。

#[Batch::failureExceptionForStep(String)]

ステップの名前を文字列引数として受け取ります。現在のレコードがそのステップで例外をスローした場合、実際の例外オブジェクトを返します。それ以外の場合は null を返します。

#[Batch::getStepExceptions()]

Java ​Map<String, Exception>​ を返します。キーは現在のレコードが失敗した Batch Step の名前で、値は例外自体です。
レコードがどのステップでも失敗しなかった場合、この Map は空になりますが null になることはありません。また、Map にはレコードが失敗しなかったステップのエントリは含まれません。

#[Batch::getFirstException()]

現在のレコードが失敗した最初のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。

#[Batch::getLastException()]

現在のレコードが失敗した最後のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。
### [](#例)例 連絡先情報を含むファイルをポーリングする Batch Job があるとします。 最初のステップでは、Batch Job は連絡先情報を集約し、Transform Message コンポーネントを使用してそれらを変換してから Salesforce に転送します。 2 番目のステップでは、ジョブはその同じ連絡先を別のサードパーティ連絡先アプリケーション (Google コンタクトなど) のデータ構造と一致するように再度変換し、HTTP 要求を使用してこのサービスに転送します。 次に、3 番目のステップとして、失敗したレコードごとに JMS デッドレターキューに書き込むことができる必要があるとします。簡略化するため、例外自体をメッセージにするとします。この要件には注意が必要です。各レコードが両方のステップで失敗し、同じレコードが 2 つの JMS メッセージに変換される可能性があります。 このアプリケーションは次のようになります。 ![batch error handling faq f34d5](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/batch-error-handling-faq-f34d5.png) 目標は失敗を収集することであるため、ONLY\_FAILURES 検索条件を使用して ​`Failures`​ ステップを設定することが理にかなっています (バッチ検索条件についての詳細は「[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-filters-and-batch-aggregator)」を参照)。 このステップの set-payload プロセッサーは、​`Batch::getStepExceptions()`​ 関数を使用するように設定できます。 ![batch error handling faq 6269e](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/batch-error-handling-faq-6269e.png) 上述のように、この関数はすべてのステップで見つかったすべてのエラーを含むマップを返します。ここでの目標は JMS を介して例外を送信することであり、ステップを気にする必要はないため、foreach スコープを使用してマップの値 (エラー) を反復処理し、JMS アウトバウンドエンドポイントを介して送信できます。 ![batch error handling faq b822e](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/batch-error-handling-faq-b822e.png) ## [](#エラー処理用のバッチ処理戦略)エラー処理用のバッチ処理戦略 Mule には、レコードレベルのエラーを処理するための 3 つのオプションがあります。 1. **処理を終了**​。現在のジョブインスタンスの実行を停止します。現在インフライト状態のレコードの実行を終了しますが、キューからそれ以上レコードを取得せずにジョブインスタンスを ​`FAILURE`​ 状態に設定します。On Complete (完了時) フェーズが呼び出されます。 2. 失敗したレコード数に関係なく​**処理を続行**​。​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Step に指示します。 3. Batch Job が​**失敗したレコードの最大数**​に達するまで、失敗したレコード数に関係なく​**処理を続行**​ (​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Job に指示します)。最大数に達した時点で、オプション 1 と同様に実行を停止します。 デフォルトでは、Mule の Batch Job はバッチインスタンスの実行を停止する最初のエラー処理戦略に従います。上記の動作は、​`maxFailedRecords`​ 属性を使用して制御されます。
失敗したレコードの処理オプション Batch Job 属性 値

失敗したレコードが見つかったときに処理を停止

maxFailedRecords

0​

失敗したレコード数に関係なく、無期限に処理を続行

maxFailedRecords

-1​

失敗したレコードの最大数に達するまで処理を続行

maxFailedRecords

integer
```xml ``` ### [](#最大失敗しきい値の超過)最大失敗しきい値の超過 Batch Job で ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数が蓄積されると、Mule は残りの Batch Job の処理を中止し、On Complete (完了時) フェーズに直接移動します。 たとえば、​`maxFailedRecords`​ の値を「10」に設定し、Batch Job が 3 つの Batch Step 最初のステップで失敗したレコードを 10 件蓄積した場合、Mule は残り 2 つの Batch Step ではバッチを処理しません。代わりに、それ以降の処理を中止し、On Complete (完了時) に直接移動して Batch Job の失敗を報告します。 Batch Job が ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数を蓄積​_しない_​場合、​_すべての_​レコード (成功と失敗) が引き続き Batch Step 間を移動します。各 Batch Step で処理するレコードを制御するには、検索条件を使用します。 ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-filters-and-batch-aggregator) # Batch Job 中のエラー処理 Mule バッチ処理は、非常に大規模なデータセットを処理して、ほぼリアルタイムのデータインテグレーションを実行できるように設計されており、クラッシュから復旧して、ジョブの処理を障害が発生した時点から続行できます。ただし、大規模なデータセットでは、発生する問題の​_冗長_​ログが膨大なサイズとなり、パフォーマンスが大きく低下する原因になることがあります。 この影響を抑えるため、Mule では​[Batch Step 内の失敗したレコードのログ](#default_logging)​で説明するように INFO レベルのログをデフォルトで使用します。より冗長なログメッセージが必要な場合は、モードを DEBUG に変更してください。このモードはデバッグに便利であり、小規模のデータセットを使用するケースで使用できます。 ログモードは次のプロパティで設定します。 ```xml ``` CloudHub または Runtime Manager を使用している場合は、次のパッケージを \[Logs (ログ)\] タブの DEBUG レベルに追加できます。 ```logs com.mulesoft.mule.runtime.module.batch ``` 本番環境で大規模なデータセットを処理する場合は、DEBUG モードは使用しないでください。 ## [](#default_logging)Batch Step 内の失敗したレコードのログ Batch Step インスタンスを処理するときに、たとえばレコードデータが破損していたり不完全であったりすることなどが原因で、Batch Step 内のプロセッサーが失敗したりエラーを発生させたりすることがあります。問題が発生した場合、デフォルトでは、Mule は INFO ログレベルを使用して、次のロジックに従ってスタックトレースをログに記録します。 1. Mule が例外の完全なスタック追跡を取得します。 2. Mule がログ内のエラーメッセージからスタックトレースを削除します。 すべてのレコードで同じエラーが発生したとしても、処理中のメッセージにはおそらくそれらのレコードに関連する特定の情報が含まれています。たとえば、リードを Salesforce アカウントに転送していて、特定のリードはすでにアップロード済みであるため 1 つのレコードがエラーになった場合、別の繰り返されるリードのレコード情報は異なりますが、同じエラーになります。 3. Mule はスタック追跡がすでに現在のステップに記録されているかどうかを検証します。 ランタイムでこのエラーに初めて遭遇すると、Mule はエラーをログに記録して、次のようなメッセージを生成します。 ```logs com.mulesoft.mule.runtime.module.batch.internal.DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'Batch Job Example' of job 'CreateLeadsBatch'. This is the first record to show this exception on this step for this job instance. Subsequent records with the same failures will not be logged for performance and log readability reasons: ``` Mule は「ステップごと」にログを記録します。別のステップでも同じエラーが発生した場合、ランタイムはそのステップに対してもログを記録します。 4. Batch Job が On Complete (完了時) フェーズに達すると、Mule にはエラー概要とすべてのエラーの種別、および各 Batch Step での発生回数が表示されます。 `batch.exception`​ 種別が発生した 2 つの Batch Step が含まれる Batch Job のエラー概要を次に示します。 ```logs ******************************************************************************* * - - + Exception Type + - - * - - + Step + - - * - - + Count + - - * ******************************************************************************* * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep1 * 10 * * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep2 * 9 * ******************************************************************************* ``` ここでは、最初のステップが 10 回失敗し、2 番目のステップが 9 回失敗しています。 Mule のデフォルト設定ではこの動作を使用してバッチエラーをログに記録します。これは INFO レベルのメッセージのみをログに記録し、大量なデータをログに記録する場合の効率性のトレードオフとのバランスを取ります。 ただし、バッチ処理を使用する動機は、大規模なデータセットを処理できることではなく、クラッシュから回復し、「ほぼリアルタイム」のデータインテグレーションを実行したときに、中断された場所から Batch Job を処理し続けることかもしれません。または、デバッグ用にさらに詳細なログレベルが必要かもしれません。 ## [](#エラー処理用の-dataweave-関数)エラー処理用の DataWeave 関数 Mule 4.x には、Batch Step のコンテキストで使用できる DataWeave 関数のセットが含まれています。
DataWeave 関数 説明

#[Batch::isSuccessfulRecord()]

現在のレコードが前のステップで例外をスローしなかった場合に true を返すブール関数。

#[Batch::isFailedRecord()]

現在のレコードが前のステップで例外をスローした場合に true を返すブール関数。

#[Batch::failureExceptionForStep(String)]

ステップの名前を文字列引数として受け取ります。現在のレコードがそのステップで例外をスローした場合、実際の例外オブジェクトを返します。それ以外の場合は null を返します。

#[Batch::getStepExceptions()]

Java ​Map<String, Exception>​ を返します。キーは現在のレコードが失敗した Batch Step の名前で、値は例外自体です。
レコードがどのステップでも失敗しなかった場合、この Map は空になりますが null になることはありません。また、Map にはレコードが失敗しなかったステップのエントリは含まれません。

#[Batch::getFirstException()]

現在のレコードが失敗した最初のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。

#[Batch::getLastException()]

現在のレコードが失敗した最後のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。
### [](#例)例 連絡先情報を含むファイルをポーリングする Batch Job があるとします。 最初のステップでは、Batch Job は連絡先情報を集約し、Transform Message コンポーネントを使用してそれらを変換してから Salesforce に転送します。 2 番目のステップでは、ジョブはその同じ連絡先を別のサードパーティ連絡先アプリケーション (Google コンタクトなど) のデータ構造と一致するように再度変換し、HTTP 要求を使用してこのサービスに転送します。 次に、3 番目のステップとして、失敗したレコードごとに JMS デッドレターキューに書き込むことができる必要があるとします。簡略化するため、例外自体をメッセージにするとします。この要件には注意が必要です。各レコードが両方のステップで失敗し、同じレコードが 2 つの JMS メッセージに変換される可能性があります。 このアプリケーションは次のようになります。 ![Anypoint Studio の詳細なステップとエラー処理が含まれるリード管理のバッチプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/batch-error-handling-faq-f34d5.png) 目標は失敗を収集することであるため、ONLY\_FAILURES 検索条件を使用して ​`Failures`​ ステップを設定することが理にかなっています (バッチ検索条件についての詳細は[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-filters-and-batch-aggregator)を参照)。 このステップの set-payload プロセッサーは、​`Batch::getStepExceptions()`​ 関数を使用するように設定できます。 ![Anypoint Studio のバッチ例外に関連する値の式が含まれる Set Payload コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/batch-error-handling-faq-6269e.png) 上述のように、この関数はすべてのステップで見つかったすべてのエラーを含むマップを返します。ここでの目標は JMS を介して例外を送信することであり、ステップを気にする必要はないため、foreach スコープを使用してマップの値 (エラー) を反復処理し、JMS アウトバウンドエンドポイントを介して送信できます。 ![Anypoint Studio のエラーを処理する For Each コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/batch-error-handling-faq-b822e.png) ## [](#エラー処理用のバッチ処理戦略)エラー処理用のバッチ処理戦略 Mule には、レコードレベルのエラーを処理するための 3 つのオプションがあります。 1. **処理を終了**​。現在のジョブインスタンスの実行を停止します。現在インフライト状態のレコードの実行を終了しますが、キューからそれ以上レコードを取得せずにジョブインスタンスを ​`FAILURE`​ 状態に設定します。On Complete (完了時) フェーズが呼び出されます。 2. 失敗したレコード数に関係なく​**処理を続行**​。​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Step に指示します。 3. Batch Job が​**失敗したレコードの最大数**​に達するまで、失敗したレコード数に関係なく​**処理を続行**​ (​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Job に指示します)。最大数に達した時点で、オプション 1 と同様に実行を停止します。 デフォルトでは、Mule の Batch Job はバッチインスタンスの実行を停止する最初のエラー処理戦略に従います。上記の動作は、​`maxFailedRecords`​ 属性を使用して制御されます。
失敗したレコードの処理オプション Batch Job 属性 値

失敗したレコードが見つかったときに処理を停止

maxFailedRecords

0​

失敗したレコード数に関係なく、無期限に処理を続行

maxFailedRecords

-1​

失敗したレコードの最大数に達するまで処理を続行

maxFailedRecords

integer
```xml ``` ### [](#最大失敗しきい値の超過)最大失敗しきい値の超過 Batch Job で ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数が蓄積されると、Mule は残りの Batch Job の処理を中止し、On Complete (完了時) フェーズに直接移動します。 たとえば、​`maxFailedRecords`​ の値を「10」に設定し、Batch Job が 3 つの Batch Step 最初のステップで失敗したレコードを 10 件蓄積した場合、Mule は残り 2 つの Batch Step ではバッチを処理しません。代わりに、それ以降の処理を中止し、On Complete (完了時) に直接移動して Batch Job の失敗を報告します。 Batch Job が ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数を蓄積​_しない_​場合、​_すべての_​レコード (成功と失敗) が引き続き Batch Step 間を移動します。各 Batch Step で処理するレコードを制御するには、検索条件を使用します。 ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-filters-and-batch-aggregator) # Batch Job 中のエラー処理 Mule バッチ処理は、非常に大規模なデータセットを処理して、ほぼリアルタイムのデータインテグレーションを実行できるように設計されており、クラッシュから復旧して、ジョブの処理を障害が発生した時点から続行できます。ただし、大規模なデータセットでは、発生する問題の​_冗長_​ログが膨大なサイズとなり、パフォーマンスが大きく低下する原因になることがあります。 この影響を抑えるため、Mule では​[Batch Step 内の失敗したレコードのログ](#default_logging)​で説明するように INFO レベルのログをデフォルトで使用します。より冗長なログメッセージが必要な場合は、モードを DEBUG に変更してください。このモードはデバッグに便利であり、小規模のデータセットを使用するケースで使用できます。 ログモードは次のプロパティで設定します。 ```xml ``` CloudHub または Runtime Manager を使用している場合は、次のパッケージを \[Logs (ログ)\] タブの DEBUG レベルに追加できます。 ```logs com.mulesoft.mule.runtime.module.batch ``` 本番環境で大規模なデータセットを処理する場合は、DEBUG モードは使用しないでください。 ## [](#default_logging)Batch Step 内の失敗したレコードのログ Batch Step インスタンスを処理するときに、たとえばレコードデータが破損していたり不完全であったりすることなどが原因で、Batch Step 内のプロセッサーが失敗したりエラーを発生させたりすることがあります。問題が発生した場合、デフォルトでは、Mule は INFO ログレベルを使用して、次のロジックに従ってスタックトレースをログに記録します。 1. Mule が例外の完全なスタック追跡を取得します。 2. Mule がログ内のエラーメッセージからスタックトレースを削除します。 すべてのレコードで同じエラーが発生したとしても、処理中のメッセージにはおそらくそれらのレコードに関連する特定の情報が含まれています。たとえば、リードを Salesforce アカウントに転送していて、特定のリードはすでにアップロード済みであるため 1 つのレコードがエラーになった場合、別の繰り返されるリードのレコード情報は異なりますが、同じエラーになります。 3. Mule はスタック追跡がすでに現在のステップに記録されているかどうかを検証します。 ランタイムでこのエラーに初めて遭遇すると、Mule はエラーをログに記録して、次のようなメッセージを生成します。 ```logs com.mulesoft.mule.runtime.module.batch.internal.DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'Batch Job Example' of job 'CreateLeadsBatch'. This is the first record to show this exception on this step for this job instance. Subsequent records with the same failures will not be logged for performance and log readability reasons: ``` Mule は「ステップごと」にログを記録します。別のステップでも同じエラーが発生した場合、ランタイムはそのステップに対してもログを記録します。 4. Batch Job が On Complete (完了時) フェーズに達すると、Mule にはエラー概要とすべてのエラーの種別、および各 Batch Step での発生回数が表示されます。 `batch.exception`​ 種別が発生した 2 つの Batch Step が含まれる Batch Job のエラー概要を次に示します。 ```logs ******************************************************************************* * - - + Exception Type + - - * - - + Step + - - * - - + Count + - - * ******************************************************************************* * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep1 * 10 * * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep2 * 9 * ******************************************************************************* ``` ここでは、最初のステップが 10 回失敗し、2 番目のステップが 9 回失敗しています。 Mule のデフォルト設定ではこの動作を使用してバッチエラーをログに記録します。これは INFO レベルのメッセージのみをログに記録し、大量なデータをログに記録する場合の効率性のトレードオフとのバランスを取ります。 ただし、バッチ処理を使用する動機は、大規模なデータセットを処理できることではなく、クラッシュから回復し、「ほぼリアルタイム」のデータインテグレーションを実行したときに、中断された場所から Batch Job を処理し続けることかもしれません。または、デバッグ用にさらに詳細なログレベルが必要かもしれません。 ## [](#エラー処理用の-dataweave-関数)エラー処理用の DataWeave 関数 Mule 4.x には、Batch Step のコンテキストで使用できる DataWeave 関数のセットが含まれています。
DataWeave 関数 説明

#[Batch::isSuccessfulRecord()]

現在のレコードが前のステップで例外をスローしなかった場合に true を返すブール関数。

#[Batch::isFailedRecord()]

現在のレコードが前のステップで例外をスローした場合に true を返すブール関数。

#[Batch::failureExceptionForStep(String)]

ステップの名前を文字列引数として受け取ります。現在のレコードがそのステップで例外をスローした場合、実際の例外オブジェクトを返します。それ以外の場合は null を返します。

#[Batch::getStepExceptions()]

Java ​Map<String, Exception>​ を返します。キーは現在のレコードが失敗した Batch Step の名前で、値は例外自体です。
レコードがどのステップでも失敗しなかった場合、この Map は空になりますが null になることはありません。また、Map にはレコードが失敗しなかったステップのエントリは含まれません。

#[Batch::getFirstException()]

現在のレコードが失敗した最初のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。

#[Batch::getLastException()]

現在のレコードが失敗した最後のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。
### [](#例)例 連絡先情報を含むファイルをポーリングする Batch Job があるとします。 最初のステップでは、Batch Job は連絡先情報を集約し、Transform Message コンポーネントを使用してそれらを変換してから Salesforce に転送します。 2 番目のステップでは、ジョブはその同じ連絡先を別のサードパーティ連絡先アプリケーション (Google コンタクトなど) のデータ構造と一致するように再度変換し、HTTP 要求を使用してこのサービスに転送します。 次に、3 番目のステップとして、失敗したレコードごとに JMS デッドレターキューに書き込むことができる必要があるとします。簡略化するため、例外自体をメッセージにするとします。この要件には注意が必要です。各レコードが両方のステップで失敗し、同じレコードが 2 つの JMS メッセージに変換される可能性があります。 このアプリケーションは次のようになります。 ![Anypoint Studio の詳細なステップとエラー処理が含まれるリード管理のバッチプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/batch-error-handling-faq-f34d5.png) 目標は失敗を収集することであるため、ONLY\_FAILURES 検索条件を使用して ​`Failures`​ ステップを設定することが理にかなっています (バッチ検索条件についての詳細は[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-filters-and-batch-aggregator)を参照)。 このステップの set-payload プロセッサーは、​`Batch::getStepExceptions()`​ 関数を使用するように設定できます。 ![Anypoint Studio のバッチ例外に関連する値の式が含まれる Set Payload コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/batch-error-handling-faq-6269e.png) 上述のように、この関数はすべてのステップで見つかったすべてのエラーを含むマップを返します。ここでの目標は JMS を介して例外を送信することであり、ステップを気にする必要はないため、foreach スコープを使用してマップの値 (エラー) を反復処理し、JMS アウトバウンドエンドポイントを介して送信できます。 ![Anypoint Studio のエラーを処理する For Each コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/batch-error-handling-faq-b822e.png) ## [](#エラー処理用のバッチ処理戦略)エラー処理用のバッチ処理戦略 Mule には、レコードレベルのエラーを処理するための 3 つのオプションがあります。 1. **処理を終了**​。現在のジョブインスタンスの実行を停止します。現在インフライト状態のレコードの実行を終了しますが、キューからそれ以上レコードを取得せずにジョブインスタンスを ​`FAILURE`​ 状態に設定します。On Complete (完了時) フェーズが呼び出されます。 2. 失敗したレコード数に関係なく​**処理を続行**​。​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Step に指示します。 3. Batch Job が​**失敗したレコードの最大数**​に達するまで、失敗したレコード数に関係なく​**処理を続行**​ (​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Job に指示します)。最大数に達した時点で、オプション 1 と同様に実行を停止します。 デフォルトでは、Mule の Batch Job はバッチインスタンスの実行を停止する最初のエラー処理戦略に従います。上記の動作は、​`maxFailedRecords`​ 属性を使用して制御されます。
失敗したレコードの処理オプション Batch Job 属性 値

失敗したレコードが見つかったときに処理を停止

maxFailedRecords

0​

失敗したレコード数に関係なく、無期限に処理を続行

maxFailedRecords

-1​

失敗したレコードの最大数に達するまで処理を続行

maxFailedRecords

integer
```xml ``` ### [](#最大失敗しきい値の超過)最大失敗しきい値の超過 Batch Job で ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数が蓄積されると、Mule は残りの Batch Job の処理を中止し、On Complete (完了時) フェーズに直接移動します。 たとえば、​`maxFailedRecords`​ の値を「10」に設定し、Batch Job が 3 つの Batch Step 最初のステップで失敗したレコードを 10 件蓄積した場合、Mule は残り 2 つの Batch Step ではバッチを処理しません。代わりに、それ以降の処理を中止し、On Complete (完了時) に直接移動して Batch Job の失敗を報告します。 Batch Job が ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数を蓄積​_しない_​場合、​_すべての_​レコード (成功と失敗) が引き続き Batch Step 間を移動します。各 Batch Step で処理するレコードを制御するには、検索条件を使用します。 ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-filters-and-batch-aggregator) # Batch Job 中のエラー処理 Mule バッチ処理は、非常に大規模なデータセットを処理して、ほぼリアルタイムのデータインテグレーションを実行できるように設計されており、クラッシュから復旧して、ジョブの処理を障害が発生した時点から続行できます。ただし、大規模なデータセットでは、発生する問題の​_冗長_​ログが膨大なサイズとなり、パフォーマンスが大きく低下する原因になることがあります。 この影響を抑えるため、Mule では​[Batch Step 内の失敗したレコードのログ](#default_logging)​で説明するように INFO レベルのログをデフォルトで使用します。より冗長なログメッセージが必要な場合は、モードを DEBUG に変更してください。このモードはデバッグに便利であり、小規模のデータセットを使用するケースで使用できます。 ログモードは次のプロパティで設定します。 ```xml ``` CloudHub または Runtime Manager を使用している場合は、次のパッケージを \[Logs (ログ)\] タブの DEBUG レベルに追加できます。 ```logs com.mulesoft.mule.runtime.module.batch ``` 本番環境で大規模なデータセットを処理する場合は、DEBUG モードは使用しないでください。 ## [](#default_logging)Batch Step 内の失敗したレコードのログ Batch Step インスタンスを処理するときに、たとえばレコードデータが破損していたり不完全であったりすることなどが原因で、Batch Step 内のプロセッサーが失敗したりエラーを発生させたりすることがあります。問題が発生した場合、デフォルトでは、Mule は INFO ログレベルを使用して、次のロジックに従ってスタックトレースをログに記録します。 1. Mule が例外の完全なスタック追跡を取得します。 2. Mule がログ内のエラーメッセージからスタックトレースを削除します。 すべてのレコードで同じエラーが発生したとしても、処理中のメッセージにはおそらくそれらのレコードに関連する特定の情報が含まれています。たとえば、リードを Salesforce アカウントに転送していて、特定のリードはすでにアップロード済みであるため 1 つのレコードがエラーになった場合、別の繰り返されるリードのレコード情報は異なりますが、同じエラーになります。 3. Mule はスタック追跡がすでに現在のステップに記録されているかどうかを検証します。 ランタイムでこのエラーに初めて遭遇すると、Mule はエラーをログに記録して、次のようなメッセージを生成します。 ```logs com.mulesoft.mule.runtime.module.batch.internal.DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'Batch Job Example' of job 'CreateLeadsBatch'. This is the first record to show this exception on this step for this job instance. Subsequent records with the same failures will not be logged for performance and log readability reasons: ``` Mule は「ステップごと」にログを記録します。別のステップでも同じエラーが発生した場合、ランタイムはそのステップに対してもログを記録します。 4. Batch Job が On Complete (完了時) フェーズに達すると、Mule にはエラー概要とすべてのエラーの種別、および各 Batch Step での発生回数が表示されます。 `batch.exception`​ 種別が発生した 2 つの Batch Step が含まれる Batch Job のエラー概要を次に示します。 ```logs ******************************************************************************* * - - + Exception Type + - - * - - + Step + - - * - - + Count + - - * ******************************************************************************* * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep1 * 10 * * com.mulesoft.mule.runtime.module.batch.exception.B * batchStep2 * 9 * ******************************************************************************* ``` ここでは、最初のステップが 10 回失敗し、2 番目のステップが 9 回失敗しています。 Mule のデフォルト設定ではこの動作を使用してバッチエラーをログに記録します。これは INFO レベルのメッセージのみをログに記録し、大量なデータをログに記録する場合の効率性のトレードオフとのバランスを取ります。 ただし、バッチ処理を使用する動機は、大規模なデータセットを処理できることではなく、クラッシュから回復し、「ほぼリアルタイム」のデータインテグレーションを実行したときに、中断された場所から Batch Job を処理し続けることかもしれません。または、デバッグ用にさらに詳細なログレベルが必要かもしれません。 ## [](#エラー処理用の-dataweave-関数)エラー処理用の DataWeave 関数 Mule 4.x には、Batch Step のコンテキストで使用できる DataWeave 関数のセットが含まれています。
DataWeave 関数 説明

#[Batch::isSuccessfulRecord()]

現在のレコードが前のステップで例外をスローしなかった場合に true を返すブール関数。

#[Batch::isFailedRecord()]

現在のレコードが前のステップで例外をスローした場合に true を返すブール関数。

#[Batch::failureExceptionForStep(String)]

ステップの名前を文字列引数として受け取ります。現在のレコードがそのステップで例外をスローした場合、実際の例外オブジェクトを返します。それ以外の場合は null を返します。

#[Batch::getStepExceptions()]

Java ​Map<String, Exception>​ を返します。キーは現在のレコードが失敗した Batch Step の名前で、値は例外自体です。
レコードがどのステップでも失敗しなかった場合、この Map は空になりますが null になることはありません。また、Map にはレコードが失敗しなかったステップのエントリは含まれません。

#[Batch::getFirstException()]

現在のレコードが失敗した最初のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。

#[Batch::getLastException()]

現在のレコードが失敗した最後のステップの例外を返します。レコードがどのステップでも失敗しなかった場合、null を返します。
### [](#例)例 連絡先情報を含むファイルをポーリングする Batch Job があるとします。 最初のステップでは、Batch Job は連絡先情報を集約し、Transform Message コンポーネントを使用してそれらを変換してから Salesforce に転送します。 2 番目のステップでは、ジョブはその同じ連絡先を別のサードパーティ連絡先アプリケーション (Google コンタクトなど) のデータ構造と一致するように再度変換し、HTTP 要求を使用してこのサービスに転送します。 次に、3 番目のステップとして、失敗したレコードごとに JMS デッドレターキューに書き込むことができる必要があるとします。簡略化するため、例外自体をメッセージにするとします。この要件には注意が必要です。各レコードが両方のステップで失敗し、同じレコードが 2 つの JMS メッセージに変換される可能性があります。 このアプリケーションは次のようになります。 ![Anypoint Studio の詳細なステップとエラー処理が含まれるリード管理のバッチプロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/batch-error-handling-faq-f34d5.png) 目標は失敗を収集することであるため、ONLY\_FAILURES 検索条件を使用して ​`Failures`​ ステップを設定することが理にかなっています (バッチ検索条件についての詳細は[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-filters-and-batch-aggregator)を参照)。 このステップの set-payload プロセッサーは、​`Batch::getStepExceptions()`​ 関数を使用するように設定できます。 ![Anypoint Studio のバッチ例外に関連する値の式が含まれる Set Payload コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/batch-error-handling-faq-6269e.png) 上述のように、この関数はすべてのステップで見つかったすべてのエラーを含むマップを返します。ここでの目標は JMS を介して例外を送信することであり、ステップを気にする必要はないため、foreach スコープを使用してマップの値 (エラー) を反復処理し、JMS アウトバウンドエンドポイントを介して送信できます。 ![Anypoint Studio のエラーを処理する For Each コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/batch-error-handling-faq-b822e.png) ## [](#エラー処理用のバッチ処理戦略)エラー処理用のバッチ処理戦略 Mule には、レコードレベルのエラーを処理するための 3 つのオプションがあります。 1. **処理を終了**​。現在のジョブインスタンスの実行を停止します。現在インフライト状態のレコードの実行を終了しますが、キューからそれ以上レコードを取得せずにジョブインスタンスを ​`FAILURE`​ 状態に設定します。On Complete (完了時) フェーズが呼び出されます。 2. 失敗したレコード数に関係なく​**処理を続行**​。​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Step に指示します。 3. Batch Job が​**失敗したレコードの最大数**​に達するまで、失敗したレコード数に関係なく​**処理を続行**​ (​`acceptExpression`​ および ​`acceptPolicy`​ 属性を使用して、失敗したレコードの処理方法を後続の Batch Job に指示します)。最大数に達した時点で、オプション 1 と同様に実行を停止します。 デフォルトでは、Mule の Batch Job はバッチインスタンスの実行を停止する最初のエラー処理戦略に従います。上記の動作は、​`maxFailedRecords`​ 属性を使用して制御されます。
失敗したレコードの処理オプション Batch Job 属性 値

失敗したレコードが見つかったときに処理を停止

maxFailedRecords

0​

失敗したレコード数に関係なく、無期限に処理を続行

maxFailedRecords

-1​

失敗したレコードの最大数に達するまで処理を続行

maxFailedRecords

integer
```xml ``` ### [](#最大失敗しきい値の超過)最大失敗しきい値の超過 Batch Job で ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数が蓄積されると、Mule は残りの Batch Job の処理を中止し、On Complete (完了時) フェーズに直接移動します。 たとえば、​`maxFailedRecords`​ の値を「10」に設定し、Batch Job が 3 つの Batch Step 最初のステップで失敗したレコードを 10 件蓄積した場合、Mule は残り 2 つの Batch Step ではバッチを処理しません。代わりに、それ以降の処理を中止し、On Complete (完了時) に直接移動して Batch Job の失敗を報告します。 Batch Job が ​`maxFailedRecords`​ しきい値を超えるのに十分な失敗したレコード数を蓄積​_しない_​場合、​_すべての_​レコード (成功と失敗) が引き続き Batch Step 間を移動します。各 Batch Step で処理するレコードを制御するには、検索条件を使用します。 ## [](#関連情報)関連情報 - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-filters-and-batch-aggregator) # Batch Step 処理の絞り込み Batch Step が処理するレコードに対して実行する作業を絞り込むことができます。 - 一部のレコードの処理のみを受け入れるように、Batch Step に​**検索条件**​を設定できます。 - レコードをグループに​**集約**​し、それらを一括更新として外部ソースまたはサービスに送信できます。 このドキュメントでは、バッチ検索条件とバッチコミットの使用方法およびそのタイミングについて説明します。 ## [](#バッチ検索条件)バッチ検索条件 1 つ以上の検索条件を属性として任意の数の Batch Step に適用できます。 レコードに Salesforce 取引先責任者が存在するかどうかを最初の Batch Step で確認するバッチジョブと、既存の各 Salesforce 取引先責任者を新しい情報で更新する 2 番目の Batch Step があるとします。2 番目の Batch Step に検索条件を適用し、最初の Batch Step で失敗しなかったレコードのみを処理するように設定できます。 Batch Step で一部のレコードのみを受け入れて処理するように、Batch Job を合理化することで、Mule Runtime Engine は特定の Batch Step で関連データのみに集中できます。 Batch Step は、レコードの絞り込みに次の 2 つの属性を使用します。 - acceptExpression - acceptPolicy 各 Batch Step では、レコードの絞り込みに 1 つの acceptExpression 属性と 1 つの acceptPolicy 属性を使用できます。 acceptExpression 属性を使用して、true と評価されたレコードのみを処理します。レコードが false と評価された場合、Batch Step はそのレコードをスキップして次のレコードでこの属性を使用します。つまり、受け入れ式で false に解決されるレコードは、Mule では​_除外_​されます。 次の例は、年齢が 21 歳未満のすべてのレコードを除外し、Batch Step はそれらのレコードを処理しません。 ```xml ... ``` Batch Step の acceptPolicy 属性を使用して、受け入れポリシー属性の値に対して true と評価されたレコードのみを処理します。受け入れポリシーに使用できる値のリストについては、次の表を参照してください。
Accept Policy (受け入れポリシー) TRUE と評価された場合

NO_FAILURES

デフォルト​
Batch Step は、先行するすべてのステップで処理に​成功​したレコードのみを処理します。

ONLY_FAILURES

Batch Step は、先行する Batch Step で処理に​失敗​したレコードのみを処理します。

ALL (すべて)

Batch Step は、先行する Batch Step で処理に失敗したかどうかに関係なく、すべてのレコードを処理します。
Batch Step に検索条件を適用しない場合、バッチは先行するすべてのステップで処理に​_成功_​したレコードのみを処理します。つまり、すべての Batch Step に適用されるデフォルトの Accept Policy (受け入れポリシー) は ​NO\_FAILURES​ です。 次の例は、先行するステップで処理に失敗したレコードのみを処理する Batch Job の 2 番目の Batch Step を示しています。最初の Batch Step では、ランタイムは各レコードに既存の Salesforce 取引先責任者があるかどうかを確認し、各レコードの取引先責任者を作成する 2 番目の Batch Step は、失敗したレコード (既存の取引先責任者がなかったレコード) のみを処理します。 ```xml ... ... ``` 各 Batch Job には、Batch Job で受け入れる失敗したレコード数を制御する ​`maxFailedRecords`​ 属性があります。 Batch Job インスタンスが ​`maxFailedRecords`​ 値を超えると、Batch Step で設定された検索条件に関係なく、ステップはレコードを処理せず、失敗した Batch Job インスタンスを On Complete (完了時) フェーズに転送します。 詳細は、​[「Batch Job 中のエラー処理」](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-error-handling-faq)​を参照してください。 ### [](#検索条件の特性)検索条件の特性 - バッチ検索条件は Batch Step にのみ適用され、Batch Job のバッチ処理フェーズ内でのみ使用可能。Input (入力) または On Complete (完了時) フェーズで検索条件を適用することはできません。 - Batch Step に検索条件を適用しない場合、バッチは先行するすべてのステップで処理に​_成功_​したレコードのみを処理します。つまり、すべての Batch Step に適用されるデフォルトの Accept Policy (受け入れポリシー) は ​NO\_FAILURES​ です。 - Batch Job インスタンスが ​`max-failed-records`​ 値を超えると、Batch Step で設定された検索条件に関係なく、ステップはレコードを処理せず、失敗した Batch Job インスタンスを On Complete (完了時) フェーズに転送します。 - 両方の種別の検索条件を適用する場合、Mule はそれらを次の順序で評価します。 1. Accept Policy (受け入れポリシー) 2. Accept Expression (受け入れ式) ## [](#batch-aggregator)Batch Aggregator Batch Aggregator スコープを使用して、Batch Step からレコードのサブセットを蓄積し、それらを外部ソースまたはサービスに一括更新/挿入できます。 たとえば、各リード (レコード) を Salesforce にバッチで更新/挿入する代わりに、200 件のレコードを蓄積するように Batch Commit を設定して、そのすべてを 1 つのチャンクで Salesforce に更新/挿入できます。 ```xml ``` レコードをストリーミングするように Batch Aggregator スコープを設定することもできます。 ```xml ``` 固定量のレコードの処理、およびすべてのレコードのストリーミングは相互に排他的な設定です。詳細は、以下のそれぞれのセクションを参照してください。 Batch Aggregator は可変です。つまり、Batch Aggregator でグループ化されたレコードのペイロードと変数にアクセスできます。 固定量のレコードを集約するときは、各レコードに順番にアクセスすることも、変更するランダムレコードを指定することもできます。 ただし、コンテンツをストリーミングするように Batch Aggregator を設定した場合、それらのレコードには順番にアクセスすることしかできません。 Aggregator を使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java Map を使用してシリアル化の問題を回避します。 ### [](#固定サイズを使用したレコードの集約)固定サイズを使用したレコードの集約 Batch Aggregator スコープ内のレコードの固定サイズグループを処理するように、Batch Aggregator スコープを設定できます。 たとえば、一度に 100 件のレコードを更新/挿入するように Batch Aggregator スコープを設定できます。 ```xml ... ``` 固定サイズのアグリゲーターを使用する場合、各レコードのペイロードと変数データの置換、変更、または保存を実行できます。 上述のように Batch Aggregator は可変であるため、foreach スコープを追加することで固定サイズのアグリゲーターブロックを反復処理し、各レコードのデータを順番に調べて各レコードのペイロードと変数を永続的に保存できます。Batch Aggregator 内でレコードにアクセスするこの方式は、順次アクセスと呼ばれます。 たとえば、Groovy Scripting Module を使用してペイロードを変更し、収集したレコードごとに変数を作成できます。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` 順次アクセス方式は、次の条件を前提としています。 1. アグリゲーターのサイズが集約されたレコードの量と一致する。 2. 集約されたレコードとリスト内の項目の間に直接の相関関係がある。 foreach の反復回数を指定することで、ランダムレコードにアクセスすることもできます。これにより、すべてのレコードを反復処理する必要がなくなります。 この foreach スコープは ​`records`​ 変数を公開します。この変数は、反復を追跡するために foreach によって使用される不変リストであり、Batch Aggregator 全体でアクセス可能なランダムアクセスリストを提供します。 各レコードに順番にアクセスする代わりに、レコードリストで任意のインデックス番号を指定することで、上記の例と同じ結果を得ることができます。たとえば、次に示すように変数を作成して最初のレコードのペイロードを変更できます。 ```xml records[0].vars['marco'] = 'polo' records[0].vars['record'].payload = 'foo' ``` ランダムアクセスを使用すると、コミットブロック内の特定のインデックス位置でレコードのペイロードを変更できます。 #### [](#ブロックサイズを定義する場合の考慮事項)ブロックサイズを定義する場合の考慮事項 従来のオンライン処理モデルでは、各要求は通常、ワーカースレッドにマップされます。処理種別 (同期、非同期、一方向、要求 - 応答、または要求が処理前に一時的にバッファされる場合) に関係なく、サーバーは通常、要求と実行中のスレッドの間で 1 対 1 の関係になります。 Batch Job の場合、Process (処理) フェーズが始まる前にすべてのレコードが最初に永続的なキューに保存されるため、従来のスレッドモデルは適用されません。 パフォーマンスを向上させるため、ランタイムはバッチレコードをスレッドごとに最大 100 件のレコードのブロックでキューに追加し、スケジュールします。この動作により I/O 要求数が削減され、操作の負荷が改善されます。Batch Job は Mule Runtime Engine のスレッドプールを使用するため、ジョブのデフォルトはありません。各スレッドはそのブロックを反復処理して各レコードを処理し、その後各ブロックはキューに戻され、プロセスが続行されます。 3 ステップの Batch Job では、キューに 100 万件のレコードを追加することを検討してください。Mule Runtime Engine がジョブのフェーズ間を移動するときに各レコードの取得と要求を行うと、少なくとも 300 万回の I/O 操作が発生します。 パフォーマンスには、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 Batch Job の 1 スレッドあたり最大 100 件のレコードの標準モデルは、ほとんどのユースケースで機能しますが、ブロックサイズの増減が必要な次の 3 つのユースケースを考慮してください。 - Batch Job で処理するレコードが 200 件あるとします。デフォルトの 100 件のレコードのブロックサイズでは、Mule が同時に並行処理できるレコード数は 2 件のみです。Batch Job で処理するレコードが 101 件未満の場合、順次処理になります。負荷の高いペイロードを処理する必要がある場合、100 件のレコードをキューに追加するには大量の作業メモリが必要です。 - 画像を処理する必要がある Batch Job があり、平均画像サイズは 3 MB だとします。この場合、Mule は、各スレッドで 3 MB のペイロードを持つ 100 件のレコードのブロックを処理します。したがって、デフォルトの threading-profile 設定では、ブロックをキューで保持するためだけに大量の作業メモリが必要になります。この場合、より低いブロックサイズを設定して、より多くのジョブを介して各ペイロードを分散し、使用可能メモリの負荷を減らします。 - 500 万件のレコードがあり、ペイロードが非常に小さいためにメモリ内に 500 件のレコードのブロックを問題なく入れることができるとします。より大きなブロックサイズを設定すると、作業メモリの負荷を犠牲にすることなく Batch Job の時間を短縮できます。 この機能を最大限に活用するには、ブロックサイズが Batch Job に与える影響を理解する必要があります。異なる値とテストパフォーマンスを使用して比較テストを実行すると、この変更を本番に移行する前に最適なブロックサイズを見つけるために役立ちます。 バッチブロックサイズの変更は省略可能です。変更を適用しない場合、デフォルト値はブロックあたり 100 件のレコードです。 Batch Aggregator コンポーネントを使用してサイズを設定します。次に例を示します。 ```xml ... ``` ### [](#batch-aggregator-でのレコードのストリーミング)Batch Aggregator でのレコードのストリーミング コンテンツをストリーミングするように Batch Aggregator スコープを設定できます。 レコードをストリーミングするように Batch Aggregator を設定すると、レコードの数や大きさに関係なく、ジョブインスタンス内のすべてのレコードを集約できます。 固定サイズの Batch Aggregator で受信する要素のリストの代わりに、ストリーミング機能を使用して、メモリ不足になることなくジョブインスタンス内のすべてのレコードを受信できます。 たとえば、CSV ファイルに数百万件のレコードを書き込む必要がある場合、レコードをストリーミング Batch Aggregator として処理できます。 ```xml ``` この Batch Aggregator はストリーミングであるため、そのコンテンツへの順次アクセスのみが可能です。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` メモリの制限により、ストリーミングアグリゲーターではランダムアクセスはサポートされていません。 ランダムアクセス用のレコードペイロードは ​`immutable List`​ として公開され、ストリーミングアグリゲーターは、固定コミットサイズなしにレコードセット全体にアクセスできることを意味するため、ランタイムはすべてのレコードがメモリ内に入ることを保証できません。 #### [](#ヒント)ヒント - **SaaS プロバイダーからのストリーミング:**​ 通常、SaaS プロバイダーにはストリーミング入力の受け入れに対する制限があるため、Anypoint Connector を介して Salesforce などの SaaS プロバイダーにデータを送信する場合、バッチストリーミングは使用しません。CSV、JSON、XML などのファイルに書き込む場合は、ストリーミングバッチ処理を使用します。 - **バッチストリーミングおよびパフォーマンス:**​ ストリーミングデータのバッチ処理はアプリケーションのパフォーマンスに影響し、トランザクションの処理速度が遅くなります。パフォーマンスは低下しますが、ストリーミングデータをバッチ処理できるようにするトレードオフにより、実装でこの使用が必要になる可能性があります。 - **バッチストリーミングおよび項目へのアクセス:**​ バッチストリーミングを使用する最大の欠点は、出力の項目へのアクセスが制限されることです。つまり、​_固定サイズのコミット_​では、変更できないリストが作成されるため、その項目にアクセスして反復処理できます。​_ストリーミングコミット_​では、1 つずつの読み取りで前方移動のみのイテレーターを使用することになります。 ### [](#batch-aggregator-の特性)Batch Aggregator の特性 - Batch Aggregator スコープは Batch Step にのみ適用され、Batch Job のバッチ処理フェーズ内でのみ使用可能。Batch Job の On Complete (完了時) フェーズでは Batch Aggregator を使用できません。 - アグリゲーターは、その Batch Step 内で最後の要素のみをラップ可能。 - いくつかの ​**Anypoint Connector**​ は、バッチ集約全体 (更新/挿入) を失敗させることなくレコードレベルのエラーを処理可能。 実行時に、これらのコネクタは対象リソースによって正常に受け入れられたレコード、および更新/挿入できなかったレコードを追跡します。したがって、レコードのグループ全体を失敗させる代わりに、できるだけ多くのレコードを更新/挿入し、通知用に失敗を追跡します。これらのコネクタの一部を次に示します。 - Salesforce - NetSuite 使用しているコネクタがレコードレベルのエラーをサポートすることを確認するには、コネクタのドキュメントを参照してください。 - Batch Aggregator スコープは、ジョブインスタンス全体のトランザクションをサポートしない。各レコードを個別のトランザクションで処理する Batch Step 内にトランザクションを定義できます。これはステップ内のステップと考えてください。 このようなトランザクションは、ステップの境界内で開始および終了する必要があります。 - Batch Step とそのステップ内に存在する Batch Aggregator の間でトランザクションは共有できない。Batch Step が開始するトランザクションは、Batch Aggregator が処理を開始する前に終了します。つまり、トランザクションは Batch Step とそれに含まれる Batch Aggregator スコープの間の境界を越えることはできません。 ## [](#集約されたレコードの-mime-タイプの保持)集約されたレコードの MIME タイプの保持 _Mule 4.3 でサポート_ 集約されたレコードは、各レコードのペイロードが含まれる配列としてアグリゲーターに渡されます。ただし、デフォルトではそれらのペイロードに関連付けられている MIME タイプは保持されません。Batch Aggregator の ​`preserveMimeTypes`​ 属性を指定して、レコードの MIME タイプを保持できます。 たとえば、次の JSON ドキュメントについて考えます。 ```json [ { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" }, { "name": "Steve Rodgers", "alias": "Captain America", "status": "RETIRED" }, { "name": "Peter Parker", "alias": "SpiderMan", "status": "FUGITIVE" } ] ``` このドキュメントを次のジョブに取り込むとします。 ```xml ``` バッチエンジンは入力 JSON 配列を個々のレコードに分割します。つまり、アグリゲーターブロックで 3 つの要素が含まれる配列を受信します。1 つ目は次のようになります。 ```json { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" } ``` ただし、logger 要素で ​`#[payload.alias]`​ 式を評価しようとすると、次のようなエラーが発生します。 ```text ******************************************************************************** Message : "You called the function 'Value Selector' with these arguments: 1: Binary ("ewogICJmaXJzdE5hbWUiOiAiUmFtIiwKICAibGFzdE5hbWUiOiAiUmFtMSIsCiAgImFkZHJlc3Mi...) 2: Name ("alias") But it expects one of these combinations: (Array, Name) (Array, String) (Date, Name) (DateTime, Name) (LocalDateTime, Name) (LocalTime, Name) (Object, Name) (Object, String) (Period, Name) (Time, Name) 5| name: payload.alias, ^^^^^^^^^^^^^ ``` 前のエラーは、デフォルトでは MIME タイプが保持されず、Mule でこのレコードが実際に JSON であるかどうかを把握できないことが原因で発生します。これを修正するには、Batch Aggregator の ​`preserveMimeTypes`​ 属性を指定します。 ```xml ``` この属性を設定すると、Mule で自動的に各レコードのメディア種別が保持され、ペイロードが実際に JSON ドキュメントを表していることを把握できます。 ## [](#最大同時実行の制限)最大同時実行の制限 Max Concurrency (最大同時実行) (​`maxConcurrency`​) プロパティでは、バッチジョブが同時に処理できるブロックの数が制限されます。ブロック内のレコードは順番に処理されます。 `maxConcurrency`​ プロパティを次の例のように設定できます。 ```xml ... ``` デフォルトでは、Batch Job コンポーネントの最大同時実行は使用可能なコアの数の 2 倍に制限されます。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-processing-concept) - [Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-job-instance-id) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-backpressure-maxconcurrency) # Batch コンポーネントの設定 Mule バッチ処理コンポーネントをセットアップおよび設定して、一般的なバッチ処理のユースケースを実行したり、デフォルトを調整する必要がある場合にバッチジョブのパフォーマンスを改善したりできます。 ## [](#batch_filters)Batch Step コンポーネント内で処理するレコードの絞り込み 1 つ以上のレコード検索条件を属性として任意の数の Batch Step コンポーネントに適用できます。たとえば、特定の Batch Job コンポーネント内の最初の Batch Step コンポーネントで各レコードの Salesforce 取引先責任者をチェックして、2 番目の Batch Step コンポーネントでそれらのレコードの取引先責任者情報を更新します。2 番目の Batch Step で最初のステップで成功したレコードのみを処理するようにするには、2 番目の Batch Step で検索条件を設定します。検索条件によって処理が合理化されるため、Mule は特定のステップの関連するデータにのみ集中できます。 レコードを絞り込むために、Batch Step コンポーネントでは、1 つの ​`acceptExpression`​ と 1 つの ​`acceptPolicy`​ がサポートされています。どちらも省略可能で、他の Mule コンポーネントではこれらの検索条件を使用できません。同じコンポーネントで両方の検索条件を使用する場合、Mule は検索条件を次の順序で評価します。 1. 受け入れポリシー: [acceptExpression](#accept_expression) 2. 受け入れ式: [acceptPolicy](#accept_policy) `acceptExpression`​ 属性を使用する Batch Step コンポーネントは、このコンポーネントに到達する各レコードに DataWeave 式を適用し、式が ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。レコードが ​`false`​ に評価される場合、Batch Step コンポーネントはレコードをスキップし、そのレコードは Batch Job コンポーネント内の次の Batch Step コンポーネント (存在する場合) で使用できるようになります。 以下の例では、​`age`​ の値が ​`21`​ 以下のすべてのレコードを除外します。 ```xml ... ``` Batch Step コンポーネントは、​`acceptPolicy`​ 属性を使用して、以前の Batch Step コンポーネントで処理されたレコードにポリシーを適用します。Batch Step は、ポリシーが ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。デフォルトのポリシーは ​`NO_FAILURES`​ です。他のポリシーは ​`ONLY_FAILURES`​ と ​`ALL`​ です。これらのポリシーの詳細は、​[「Batch Step コンポーネント ()」](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-reference#ref_batch_step_component)​を参照してください。 次の例では、2 番目の Batch Step コンポーネント (​`batchStep2`​) で、先行するステップ (​`batchStep1`​) で正常に処理できなかったレコードのみを受け入れます。たとえば、​`batchStep1`​ 内のプロセッサーで Salesforce 取引先責任者の各レコードをチェックするとします。チェックで取引先責任者が見つからなかった場合、​`batchStep2`​ は、取引先責任者のないレコードのみを受け入れて、取引先責任者のあるレコードはスキップします。​`batchStep2`​ 内のメッセージプロセッサーは取引先責任者をそれらのレコードに追加することができます。 ```xml ... ... ``` 次の例では、デモ目的で Raise Error コンポーネント (​``​) を使用して、最初の Batch Step (​`batchStep1`​) で失敗が発生するようにします。2 番目の Batch Step (​`batchStep2`​) は、失敗したレコード (​`ONLY_FAILURES`​) のみを受け入れ、それらのレコードのペイロードを記録します。3 番目は、デフォルトの ​`acceptPolicy`​ を使用して ​`NO_FAILURES`​ を受け入れます。 ```xml ``` - Set Payload コンポーネント (​``​) は、配列 ​`[1,2,3,4,5]`​ を Batch Job コンポーネントに送信します。 - Batch Job コンポーネント (​``​) は、最初の Batch Step コンポーネント内で失敗したレコードによって Batch Job インスタンスの処理が停止しないように ​`maxFailedRecords`​ を ​`-1`​ に設定します。 - 最初の Batch Step (​`batchStep1`​) は、​`acceptExpression="#[payload < 3]"`​ を設定して、ペイロードが ​`3`​ 未満のレコードのみを受け入れ、そのコンポーネント内の Raise Error コンポーネントにより、それらのレコードでエラーをスローします。 ```logs INFO ...DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'f9bb6d60-5ef2-11ed-81e7-147ddaaf4f97' of job 'batch-example-policiesBatch_Job'. ``` - 2 番目の Batch Step (​`batchStep2`​) は、次のように失敗したレコードのペイロードを出力します。 ```logs INFO ... LOGGER IN SECOND BATCH STEP: 1 INFO ... LOGGER IN SECOND BATCH STEP: 2 ``` - 3 番目の Batch Step (​`batchStep3`​) は、次のように成功したレコードのペイロードを出力します。 ```logs INFO ... LOGS IN THIRD BATCH STEP: 3 INFO ...LOGS IN THIRD BATCH STEP: 4 INFO ...LOGS IN THIRD BATCH STEP: 5 ``` - Batch Job インスタンスの完了後、​`3`​ つのレコードが正常に処理されて、​`2`​ つのレコードが失敗したことがログに示されます。 ```logs INFO ...engine.DefaultBatchEngine: Finished execution for instance ... Total Records processed: 5. Successful records: 3. Failed Records: 2 ``` 詳細は、「[Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-error-handling-faq)」を参照してください。 ## [](#aggregator_bulk_update)Batch Aggregator コンポーネントからの一括操作の実行 集約は、配列内の複数のレコードを外部サーバーに送信する場合に便利です。Batch Aggregator コンポーネント内で操作 (一括更新、挿入、更新など) を追加することで、レコードごとに個別に操作を実行する代わりに、操作の 1 つの実行で複数のレコードをサーバーに読み込むことができます。 固定サイズの個別の配列でレコードを処理することも、Batch Job インスタンスから 1 つのレコード配列をストリーミングすることもできます。たとえば、200 件の処理済みレコードを更新/挿入するように、Salesforce 用 Anypoint Connector (Salesforce Connector) で Upsert 操作を設定できます。または、インスタンス内のすべてのレコードをサーバーにストリーミングすることもできます。 次の例では、更新/挿入あたり 200 件のレコードの個別の配列でレコードを一括更新/挿入します。 ```xml ``` 次の例では、データベースに更新/挿入をストリーミングします。 ```xml salesforce:upsert doc:name="Upsert" ... /> ``` エラー処理: [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#Upsert)​ などの一部のコネクタは、バッチ集約プロセス全体を失敗させることなくレコードレベルのエラーを処理します。実行時に、これらのコネクタは対象リソースによって正常に受け入れられたレコード、および失敗したレコードを追跡します。レコードのグループ全体を失敗させる代わりに、できるだけ多くのレコードを更新/挿入し、通知目的で失敗を追跡します。 Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-processing-concept#phase_process)​を参照してください。 ## [](#aggregator_modify_records)Batch Aggregator 内でのレコードの変更 Batch Step コンポーネントのプロセッサーを使用して変更する場合と同様に、Batch Aggregator 内でレコードを変更できます。変更の実行は、順次または特定のレコードへのランダムアクセスで行うことができます。 ### [](#batch-aggregator-内の順次処理)Batch Aggregator 内の順次処理 次の例では、レコードへの順次アクセスを実行します。この例では、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ 内の Groovy を使用して、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.4/for-each-scope-concept)​ コンポーネントの反復から各レコードのペイロードを変更し、収集したレコードごとに変数を作成できます。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'hello' ``` ### [](#batch-aggregator-内でのレコードへのランダムアクセス)Batch Aggregator 内でのレコードへのランダムアクセス 反復回数でレコードにランダムにアクセスする場合、For Each スコープを使用することもできます。For Each は、​`records`​ 変数 (反復を追跡するために使用する不変リスト) を公開します。この変数を使用して、Batch Aggregator コンポーネントからリストのレコードにランダムにアクセスできます。 次の例では、固定サイズの集約を使用するときのランダムなアクセスを示すために、レコードの For Each リストでレコードのインデックスを指定します。各レコードに順次アクセスする代わりに、レコードのインデックスが含まれる ​`records`​ 変数を使用して、リストから 1 つのレコードを選択します。この例では、Scripting Module を使用して、選択したレコードのペイロードを変更し、そのレコードの変数を作成します。 ```xml records[0].vars['marco'] = 'polo' records[0].vars['record'].payload = 'hello' ``` コンテンツをストリーミングするように Batch Aggregator コンポーネントを設定できます。レコードをストリーミングするようにこのコンポーネントを設定すると (​`streaming="true"`​)、レコードの数や大きさに関係なく、メモリ不足にならずに Batch Job インスタンス内のすべてのレコードの配列を処理できます。たとえば、CSV ファイルに数百万件のレコードを書き込む必要がある場合、Batch Aggregator コンポーネントを使用してレコードをストリーミングできます。 ```xml ``` 次の例に示すように、Batch Aggregator コンポーネント内でストリーミングする場合は、レコードへの順次アクセスのみが可能です。ストリーミングでは、レコードセット全体にアクセスする必要があるため、ランダムアクセスはサポートされません。Mule では、固定サイズが指定されていない場合、すべてのレコードがメモリ内に収まることが保証されないため、この制限は必須です。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-processing-concept#phase_process)​を参照してください。 NOTE Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java Map を使用してシリアル化の問題を回避します。 ## [](#集約されたレコードの-mime-タイプの保持)集約されたレコードの MIME タイプの保持 _Mule 4.3 での導入_ 集約されたレコードは、各レコードのペイロードが含まれる配列コンポーネントとして Batch Aggregator コンポーネントに渡されます。ただし、デフォルトではそれらのペイロードに関連付けられている MIME タイプは保持されません。レコードの MIME タイプを保持するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を指定します。 次の JSON 配列を考えてみます。 ```json [ { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" }, { "name": "Steve Rodgers", "alias": "Captain America", "status": "RETIRED" }, { "name": "Peter Parker", "alias": "SpiderMan", "status": "FUGITIVE" } ] ``` [JSON 配列](#json_array)​が次の Batch Job コンポーネントの入力だとします。 ```xml ``` バッチエンジンは入力 JSON 配列を個々のレコードに分割します。つまり、アグリゲーターブロックで 3 つの要素が含まれる配列を受信します。1 つ目は次のようになります。 ```json { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" } ``` ただし、Logger コンポーネントで ​`#[payload.alias]`​ 式を評価しようとすると、次の結果のようなエラーが発生します。 ```text ******************************************************************************** Message : "You called the function 'Value Selector' with these arguments: 1: Binary ("ewogICJmaXJzdE5hbWUiOiAiUmFtIiwKICAibGFzdE5hbWUiOiAiUmFtMSIsCiAgImFkZHJlc3Mi...) 2: Name ("alias") But it expects one of these combinations: (Array, Name) (Array, String) (Date, Name) (DateTime, Name) (LocalDateTime, Name) (LocalTime, Name) (Object, Name) (Object, String) (Period, Name) (Time, Name) 5| name: payload.alias, ^^^^^^^^^^^^^ ``` このエラーは、MIME タイプが保持されないことが原因で発生します。これにより、Mule で JSON として読み取らなくなります。この問題を解決するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を ​`true`​ に設定します。次に例を示します。 ```xml ``` この設定により、Mule で各レコードのメディア種別が保持され、ペイロードが JSON ドキュメントとして処理されます。 ## [](#レコードブロックサイズの変更)レコードブロックサイズの変更 従来のオンライン処理モデルでは、各要求は通常、ワーカースレッドにマップされます。処理種別に関係なく、通常、要求と実行中のスレッドの間には 1 対 1 のリレーションがあります。このリレーションは、同期、非同期、一方向、要求-応答の処理種別や、処理前に要求が一時的にバッファされる場合に保持されます。 ただし、Batch Job の場合、Process (処理) フェーズが始まる前にレコードが最初に永続的なキューに保存されるため、従来のスレッドモデルは適用されません。 パフォーマンスを向上させるため、Mule Runtime はバッチレコードをスレッドごとに最大 100 件のレコードのブロックでキューに追加し、スケジュールします。この動作により I/O 要求数が削減され、操作の負荷が改善されます。Batch Job は Mule のスレッドプールを使用するため、ジョブのデフォルトはありません。各スレッドはそのブロックを反復処理して各レコードを処理し、その後各ブロックはキューに戻され、プロセスが続行されます。 3 ステップの Batch Job では、キューに 100 万件のレコードを追加することを検討してください。Mule Runtime Engine がジョブのフェーズ間を移動するときに各レコードの取得と要求を行うと、少なくとも 300 万回の I/O 操作が発生します。 パフォーマンスには、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 Batch Job の 1 スレッドあたり最大 100 件のレコードの標準モデルは、ほとんどのユースケースで機能しますが、ブロックサイズの増減が必要な次の 3 つのユースケースを考慮してください。 - Batch Job で処理するレコードが 200 件あるとします。デフォルトの 100 件のレコードのブロックサイズでは、Mule が同時に並行処理できるレコード数は 2 件のみです。Batch Job で処理するレコードが 101 件未満の場合、順次処理になります。負荷の高いペイロードを処理する必要がある場合、100 件のレコードをキューに追加するには大量の作業メモリが必要です。 - 画像を処理する必要がある Batch Job があり、平均画像サイズは 3 MB だとします。この場合、Mule は、各スレッドで 3 MB のペイロードを持つ 100 件のレコードのブロックを処理します。したがって、デフォルトの threading-profile 設定では、ブロックをキューで保持するためだけに大量の作業メモリが必要になります。この場合、より低いブロックサイズを設定して、より多くのジョブを介して各ペイロードを分散し、使用可能メモリの負荷を減らします。 - 500 万件のレコードがあり、ペイロードが非常に小さいためにメモリ内に 500 件のレコードのブロックを問題なく入れることができるとします。より大きなブロックサイズを設定すると、作業メモリの負荷を犠牲にすることなく Batch Job の時間を短縮できます。 この機能を最大限に活用するには、ブロックサイズが Batch Job に与える影響を理解する必要があります。異なる値とテストパフォーマンスを使用して比較テストを実行すると、この変更を本番に移行する前に最適なブロックサイズを見つけるために役立ちます。 バッチブロックサイズの変更は省略可能です。変更を適用しない場合、デフォルト値はブロックあたり 100 件のレコードです。 Batch Job コンポーネントを使用してサイズを設定します。次に例を示します。 ```xml ... ``` ## [](#batch-job-インスタンスの最大同時実行の制限の設定)Batch Job インスタンスの最大同時実行の制限の設定 Max Concurrency (最大同時実行) (​`maxConcurrency`​) プロパティでは、同時に処理するレコードブロックの数が制限されます。 `maxConcurrency`​ プロパティを次の例のように設定できます。 ```xml ... ``` デフォルトでは、Batch Job コンポーネントの最大同時実行は使用可能なコアの数の 2 倍に制限されます。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-processing-concept) - [Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-job-instance-id) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-backpressure-maxconcurrency) # Batch コンポーネントの設定 Mule バッチ処理コンポーネントをセットアップおよび設定して、一般的なバッチ処理のユースケースを実行したり、デフォルトを調整する必要がある場合にバッチジョブのパフォーマンスを改善したりできます。 ## [](#batch_filters)Batch Step コンポーネント内で処理するレコードの絞り込み 1 つ以上のレコード検索条件を属性として任意の数の Batch Step コンポーネントに適用できます。たとえば、特定の Batch Job コンポーネント内の最初の Batch Step コンポーネントで各レコードの Salesforce 取引先責任者をチェックして、2 番目の Batch Step コンポーネントでそれらのレコードの取引先責任者情報を更新します。2 番目の Batch Step で最初のステップで成功したレコードのみを処理するようにするには、2 番目の Batch Step で検索条件を設定します。検索条件によって処理が合理化されるため、Mule は特定のステップの関連するデータにのみ集中できます。 レコードを絞り込むために、Batch Step コンポーネントでは、1 つの ​`acceptExpression`​ と 1 つの ​`acceptPolicy`​ がサポートされています。どちらも省略可能で、他の Mule コンポーネントではこれらの検索条件を使用できません。同じコンポーネントで両方の検索条件を使用する場合、Mule は検索条件を次の順序で評価します。 1. 受け入れポリシー: [acceptExpression](#accept_expression) 2. 受け入れ式: [acceptPolicy](#accept_policy) `acceptExpression`​ 属性を使用する Batch Step コンポーネントは、このコンポーネントに到達する各レコードに DataWeave 式を適用し、式が ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。レコードが ​`false`​ に評価される場合、Batch Step コンポーネントはレコードをスキップし、そのレコードは Batch Job コンポーネント内の次の Batch Step コンポーネント (存在する場合) で使用できるようになります。 以下の例では、​`age`​ の値が ​`21`​ 以下のすべてのレコードを除外します。 ```xml ... ``` Batch Step コンポーネントは、​`acceptPolicy`​ 属性を使用して、以前の Batch Step コンポーネントで処理されたレコードにポリシーを適用します。Batch Step は、ポリシーが ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。デフォルトのポリシーは ​`NO_FAILURES`​ です。他のポリシーは ​`ONLY_FAILURES`​ と ​`ALL`​ です。これらのポリシーの詳細は、​[「Batch Step コンポーネント ()」](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-reference#ref_batch_step_component)​を参照してください。 次の例では、2 番目の Batch Step コンポーネント (​`batchStep2`​) で、先行するステップ (​`batchStep1`​) で正常に処理できなかったレコードのみを受け入れます。たとえば、​`batchStep1`​ 内のプロセッサーで Salesforce 取引先責任者の各レコードをチェックするとします。チェックで取引先責任者が見つからなかった場合、​`batchStep2`​ は、取引先責任者のないレコードのみを受け入れて、取引先責任者のあるレコードはスキップします。​`batchStep2`​ 内のメッセージプロセッサーは取引先責任者をそれらのレコードに追加することができます。 ```xml ... ... ``` 次の例では、デモ目的で Raise Error コンポーネント (​``​) を使用して、最初の Batch Step (​`batchStep1`​) で失敗が発生するようにします。2 番目の Batch Step (​`batchStep2`​) は、失敗したレコード (​`ONLY_FAILURES`​) のみを受け入れ、それらのレコードのペイロードを記録します。3 番目は、デフォルトの ​`acceptPolicy`​ を使用して ​`NO_FAILURES`​ を受け入れます。 ```xml ``` - Set Payload コンポーネント (​``​) は、配列 ​`[1,2,3,4,5]`​ を Batch Job コンポーネントに送信します。 - Batch Job コンポーネント (​``​) は、最初の Batch Step コンポーネント内で失敗したレコードによって Batch Job インスタンスの処理が停止しないように ​`maxFailedRecords`​ を ​`-1`​ に設定します。 - 最初の Batch Step (​`batchStep1`​) は、​`acceptExpression="#[payload < 3]"`​ を設定して、ペイロードが ​`3`​ 未満のレコードのみを受け入れ、そのコンポーネント内の Raise Error コンポーネントにより、それらのレコードでエラーをスローします。 ```logs INFO ...DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'f9bb6d60-5ef2-11ed-81e7-147ddaaf4f97' of job 'batch-example-policiesBatch_Job'. ``` - 2 番目の Batch Step (​`batchStep2`​) は、次のように失敗したレコードのペイロードを出力します。 ```logs INFO ... LOGGER IN SECOND BATCH STEP: 1 INFO ... LOGGER IN SECOND BATCH STEP: 2 ``` - 3 番目の Batch Step (​`batchStep3`​) は、次のように成功したレコードのペイロードを出力します。 ```logs INFO ... LOGS IN THIRD BATCH STEP: 3 INFO ...LOGS IN THIRD BATCH STEP: 4 INFO ...LOGS IN THIRD BATCH STEP: 5 ``` - Batch Job インスタンスの完了後、​`3`​ つのレコードが正常に処理されて、​`2`​ つのレコードが失敗したことがログに示されます。 ```logs INFO ...engine.DefaultBatchEngine: Finished execution for instance ... Total Records processed: 5. Successful records: 3. Failed Records: 2 ``` 詳細は、「[Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-error-handling-faq)」を参照してください。 ## [](#aggregator_bulk_update)Batch Aggregator コンポーネントからの一括操作の実行 集約は、配列内の複数のレコードを外部サーバーに送信する場合に便利です。Batch Aggregator コンポーネント内で操作 (一括更新、挿入、更新など) を追加することで、レコードごとに個別に操作を実行する代わりに、操作の 1 つの実行で複数のレコードをサーバーに読み込むことができます。 固定サイズの個別の配列でレコードを処理することも、Batch Job インスタンスから 1 つのレコード配列をストリーミングすることもできます。たとえば、200 件の処理済みレコードを更新/挿入するように、Salesforce 用 Anypoint Connector (Salesforce Connector) で Upsert 操作を設定できます。または、インスタンス内のすべてのレコードをサーバーにストリーミングすることもできます。 次の例では、更新/挿入あたり 200 件のレコードの個別の配列でレコードを一括更新/挿入します。 ```xml ``` 次の例では、データベースに更新/挿入をストリーミングします。 ```xml salesforce:upsert doc:name="Upsert" ... /> ``` エラー処理: [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#Upsert)​ などの一部のコネクタは、バッチ集約プロセス全体を失敗させることなくレコードレベルのエラーを処理します。実行時に、これらのコネクタは対象リソースによって正常に受け入れられたレコード、および失敗したレコードを追跡します。レコードのグループ全体を失敗させる代わりに、できるだけ多くのレコードを更新/挿入し、通知目的で失敗を追跡します。 Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-processing-concept#phase_process)​を参照してください。 ## [](#aggregator_modify_records)Batch Aggregator 内でのレコードの変更 Batch Step コンポーネントのプロセッサーを使用して変更する場合と同様に、Batch Aggregator 内でレコードを変更できます。変更の実行は、順次または特定のレコードへのランダムアクセスで行うことができます。 ### [](#batch-aggregator-内の順次処理)Batch Aggregator 内の順次処理 次の例では、レコードへの順次アクセスを実行します。この例では、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ 内の Groovy を使用して、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.5/for-each-scope-concept)​ コンポーネントの反復から各レコードのペイロードを変更し、収集したレコードごとに変数を作成できます。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'hello' ``` ### [](#batch-aggregator-内でのレコードへのランダムアクセス)Batch Aggregator 内でのレコードへのランダムアクセス 反復回数でレコードにランダムにアクセスする場合、For Each スコープを使用することもできます。For Each は、​`records`​ 変数 (反復を追跡するために使用する不変リスト) を公開します。この変数を使用して、Batch Aggregator コンポーネントからリストのレコードにランダムにアクセスできます。 次の例では、固定サイズの集約を使用するときのランダムなアクセスを示すために、レコードの For Each リストでレコードのインデックスを指定します。各レコードに順次アクセスする代わりに、レコードのインデックスが含まれる ​`records`​ 変数を使用して、リストから 1 つのレコードを選択します。この例では、Scripting Module を使用して、選択したレコードのペイロードを変更し、そのレコードの変数を作成します。 ```xml records[0].vars['marco'] = 'polo' records[0].vars['record'].payload = 'hello' ``` コンテンツをストリーミングするように Batch Aggregator コンポーネントを設定できます。レコードをストリーミングするようにこのコンポーネントを設定すると (​`streaming="true"`​)、レコードの数や大きさに関係なく、メモリ不足にならずに Batch Job インスタンス内のすべてのレコードの配列を処理できます。たとえば、CSV ファイルに数百万件のレコードを書き込む必要がある場合、Batch Aggregator コンポーネントを使用してレコードをストリーミングできます。 ```xml ``` 次の例に示すように、Batch Aggregator コンポーネント内でストリーミングする場合は、レコードへの順次アクセスのみが可能です。ストリーミングでは、レコードセット全体にアクセスする必要があるため、ランダムアクセスはサポートされません。Mule では、固定サイズが指定されていない場合、すべてのレコードがメモリ内に収まることが保証されないため、この制限は必須です。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-processing-concept#phase_process)​を参照してください。 NOTE Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java Map を使用してシリアル化の問題を回避します。 ## [](#集約されたレコードの-mime-タイプの保持)集約されたレコードの MIME タイプの保持 _Mule 4.3 での導入_ 集約されたレコードは、各レコードのペイロードが含まれる配列コンポーネントとして Batch Aggregator コンポーネントに渡されます。ただし、デフォルトではそれらのペイロードに関連付けられている MIME タイプは保持されません。レコードの MIME タイプを保持するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を指定します。 次の JSON 配列を考えてみます。 ```json [ { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" }, { "name": "Steve Rodgers", "alias": "Captain America", "status": "RETIRED" }, { "name": "Peter Parker", "alias": "SpiderMan", "status": "FUGITIVE" } ] ``` [JSON 配列](#json_array)​が次の Batch Job コンポーネントの入力だとします。 ```xml ``` バッチエンジンは入力 JSON 配列を個々のレコードに分割します。つまり、アグリゲーターブロックで 3 つの要素が含まれる配列を受信します。1 つ目は次のようになります。 ```json { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" } ``` ただし、Logger コンポーネントで ​`#[payload.alias]`​ 式を評価しようとすると、次の結果のようなエラーが発生します。 ```text ******************************************************************************** Message : "You called the function 'Value Selector' with these arguments: 1: Binary ("ewogICJmaXJzdE5hbWUiOiAiUmFtIiwKICAibGFzdE5hbWUiOiAiUmFtMSIsCiAgImFkZHJlc3Mi...) 2: Name ("alias") But it expects one of these combinations: (Array, Name) (Array, String) (Date, Name) (DateTime, Name) (LocalDateTime, Name) (LocalTime, Name) (Object, Name) (Object, String) (Period, Name) (Time, Name) 5| name: payload.alias, ^^^^^^^^^^^^^ ``` このエラーは、MIME タイプが保持されないことが原因で発生します。これにより、Mule で JSON として読み取らなくなります。この問題を解決するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を ​`true`​ に設定します。次に例を示します。 ```xml ``` この設定により、Mule で各レコードのメディア種別が保持され、ペイロードが JSON ドキュメントとして処理されます。 ## [](#レコードブロックサイズの変更)レコードブロックサイズの変更 従来のオンライン処理モデルでは、各要求は通常、ワーカースレッドにマップされます。処理種別に関係なく、通常、要求と実行中のスレッドの間には 1 対 1 のリレーションがあります。このリレーションは、同期、非同期、一方向、要求-応答の処理種別や、処理前に要求が一時的にバッファされる場合に保持されます。 ただし、Batch Job の場合、Process (処理) フェーズが始まる前にレコードが最初に永続的なキューに保存されるため、従来のスレッドモデルは適用されません。 パフォーマンスを向上させるため、Mule Runtime はバッチレコードをスレッドごとに最大 100 件のレコードのブロックでキューに追加し、スケジュールします。この動作により I/O 要求数が削減され、操作の負荷が改善されます。Batch Job は Mule のスレッドプールを使用するため、ジョブのデフォルトはありません。各スレッドはそのブロックを反復処理して各レコードを処理し、その後各ブロックはキューに戻され、プロセスが続行されます。 3 ステップの Batch Job では、キューに 100 万件のレコードを追加することを検討してください。Mule Runtime Engine がジョブのフェーズ間を移動するときに各レコードの取得と要求を行うと、少なくとも 300 万回の I/O 操作が発生します。 パフォーマンスには、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 Batch Job の 1 スレッドあたり最大 100 件のレコードの標準モデルは、ほとんどのユースケースで機能しますが、ブロックサイズの増減が必要な次の 3 つのユースケースを考慮してください。 - Batch Job で処理するレコードが 200 件あるとします。デフォルトの 100 件のレコードのブロックサイズでは、Mule が同時に並行処理できるレコード数は 2 件のみです。Batch Job で処理するレコードが 101 件未満の場合、順次処理になります。負荷の高いペイロードを処理する必要がある場合、100 件のレコードをキューに追加するには大量の作業メモリが必要です。 - 画像を処理する必要がある Batch Job があり、平均画像サイズは 3 MB だとします。この場合、Mule は、各スレッドで 3 MB のペイロードを持つ 100 件のレコードのブロックを処理します。したがって、デフォルトの threading-profile 設定では、ブロックをキューで保持するためだけに大量の作業メモリが必要になります。この場合、より低いブロックサイズを設定して、より多くのジョブを介して各ペイロードを分散し、使用可能メモリの負荷を減らします。 - 500 万件のレコードがあり、ペイロードが非常に小さいためにメモリ内に 500 件のレコードのブロックを問題なく入れることができるとします。より大きなブロックサイズを設定すると、作業メモリの負荷を犠牲にすることなく Batch Job の時間を短縮できます。 この機能を最大限に活用するには、ブロックサイズが Batch Job に与える影響を理解する必要があります。異なる値とテストパフォーマンスを使用して比較テストを実行すると、この変更を本番に移行する前に最適なブロックサイズを見つけるために役立ちます。 バッチブロックサイズの変更は省略可能です。変更を適用しない場合、デフォルト値はブロックあたり 100 件のレコードです。 Batch Job コンポーネントを使用してサイズを設定します。次に例を示します。 ```xml ... ``` ## [](#batch-job-インスタンスの最大同時実行の制限の設定)Batch Job インスタンスの最大同時実行の制限の設定 Max Concurrency (最大同時実行) (​`maxConcurrency`​) プロパティでは、同時に処理するレコードブロックの数が制限されます。 `maxConcurrency`​ プロパティを次の例のように設定できます。 ```xml ... ``` デフォルトでは、Batch Job コンポーネントの最大同時実行は使用可能なコアの数の 2 倍に制限されます。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-processing-concept) - [Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-job-instance-id) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-backpressure-maxconcurrency) # Batch コンポーネントの設定 Mule バッチ処理コンポーネントをセットアップおよび設定して、一般的なバッチ処理のユースケースを実行したり、デフォルトを調整する必要がある場合にバッチジョブのパフォーマンスを改善したりできます。 ## [](#batch_filters)Batch Step コンポーネント内で処理するレコードの絞り込み 1 つ以上のレコード検索条件を属性として任意の数の Batch Step コンポーネントに適用できます。たとえば、特定の Batch Job コンポーネント内の最初の Batch Step コンポーネントで各レコードの Salesforce 取引先責任者をチェックして、2 番目の Batch Step コンポーネントでそれらのレコードの取引先責任者情報を更新します。2 番目の Batch Step で最初のステップで成功したレコードのみを処理するようにするには、2 番目の Batch Step で検索条件を設定します。検索条件によって処理が合理化されるため、Mule は特定のステップの関連するデータにのみ集中できます。 レコードを絞り込むために、Batch Step コンポーネントでは、1 つの ​`acceptExpression`​ と 1 つの ​`acceptPolicy`​ がサポートされています。どちらも省略可能で、他の Mule コンポーネントではこれらの検索条件を使用できません。同じコンポーネントで両方の検索条件を使用する場合、Mule は検索条件を次の順序で評価します。 1. 受け入れポリシー: [acceptExpression](#accept_expression) 2. 受け入れ式: [acceptPolicy](#accept_policy) `acceptExpression`​ 属性を使用する Batch Step コンポーネントは、このコンポーネントに到達する各レコードに DataWeave 式を適用し、式が ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。レコードが ​`false`​ に評価される場合、Batch Step コンポーネントはレコードをスキップし、そのレコードは Batch Job コンポーネント内の次の Batch Step コンポーネント (存在する場合) で使用できるようになります。 以下の例では、​`age`​ の値が ​`21`​ 以下のすべてのレコードを除外します。 ```xml ... ``` Batch Step コンポーネントは、​`acceptPolicy`​ 属性を使用して、以前の Batch Step コンポーネントで処理されたレコードにポリシーを適用します。Batch Step は、ポリシーが ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。デフォルトのポリシーは ​`NO_FAILURES`​ です。他のポリシーは ​`ONLY_FAILURES`​ と ​`ALL`​ です。これらのポリシーの詳細は、​[「Batch Step コンポーネント ()」](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-reference#ref_batch_step_component)​を参照してください。 次の例では、2 番目の Batch Step コンポーネント (​`batchStep2`​) で、先行するステップ (​`batchStep1`​) で正常に処理できなかったレコードのみを受け入れます。たとえば、​`batchStep1`​ 内のプロセッサーで Salesforce 取引先責任者の各レコードをチェックするとします。チェックで取引先責任者が見つからなかった場合、​`batchStep2`​ は、取引先責任者のないレコードのみを受け入れて、取引先責任者のあるレコードはスキップします。​`batchStep2`​ 内のメッセージプロセッサーは取引先責任者をそれらのレコードに追加することができます。 ```xml ... ... ``` 次の例では、デモ目的で Raise Error コンポーネント (​``​) を使用して、最初の Batch Step (​`batchStep1`​) で失敗が発生するようにします。2 番目の Batch Step (​`batchStep2`​) は、失敗したレコード (​`ONLY_FAILURES`​) のみを受け入れ、それらのレコードのペイロードを記録します。3 番目は、デフォルトの ​`acceptPolicy`​ を使用して ​`NO_FAILURES`​ を受け入れます。 ```xml ``` - Set Payload コンポーネント (​``​) は、配列 ​`[1,2,3,4,5]`​ を Batch Job コンポーネントに送信します。 - Batch Job コンポーネント (​``​) は、最初の Batch Step コンポーネント内で失敗したレコードによって Batch Job インスタンスの処理が停止しないように ​`maxFailedRecords`​ を ​`-1`​ に設定します。 - 最初の Batch Step (​`batchStep1`​) は、​`acceptExpression="#[payload < 3]"`​ を設定して、ペイロードが ​`3`​ 未満のレコードのみを受け入れ、そのコンポーネント内の Raise Error コンポーネントにより、それらのレコードでエラーをスローします。 ```logs INFO ...DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'f9bb6d60-5ef2-11ed-81e7-147ddaaf4f97' of job 'batch-example-policiesBatch_Job'. ``` - 2 番目の Batch Step (​`batchStep2`​) は、次のように失敗したレコードのペイロードを出力します。 ```logs INFO ... LOGGER IN SECOND BATCH STEP: 1 INFO ... LOGGER IN SECOND BATCH STEP: 2 ``` - 3 番目の Batch Step (​`batchStep3`​) は、次のように成功したレコードのペイロードを出力します。 ```logs INFO ... LOGS IN THIRD BATCH STEP: 3 INFO ...LOGS IN THIRD BATCH STEP: 4 INFO ...LOGS IN THIRD BATCH STEP: 5 ``` - Batch Job インスタンスの完了後、​`3`​ つのレコードが正常に処理されて、​`2`​ つのレコードが失敗したことがログに示されます。 ```logs INFO ...engine.DefaultBatchEngine: Finished execution for instance ... Total Records processed: 5. Successful records: 3. Failed Records: 2 ``` 詳細は、「[Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-error-handling-faq)」を参照してください。 ## [](#aggregator_bulk_update)Batch Aggregator コンポーネントからの一括操作の実行 集約は、配列内の複数のレコードを外部サーバーに送信する場合に便利です。Batch Aggregator コンポーネント内で操作 (一括更新、挿入、更新など) を追加することで、レコードごとに個別に操作を実行する代わりに、操作の 1 つの実行で複数のレコードをサーバーに読み込むことができます。 固定サイズの個別の配列でレコードを処理することも、Batch Job インスタンスから 1 つのレコード配列をストリーミングすることもできます。たとえば、200 件の処理済みレコードを更新/挿入するように、Salesforce 用 Anypoint Connector (Salesforce Connector) で Upsert 操作を設定できます。または、インスタンス内のすべてのレコードをサーバーにストリーミングすることもできます。 次の例では、更新/挿入あたり 200 件のレコードの個別の配列でレコードを一括更新/挿入します。 ```xml ``` 次の例では、データベースに更新/挿入をストリーミングします。 ```xml salesforce:upsert doc:name="Upsert" ... /> ``` エラー処理: [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#Upsert)​ などの一部のコネクタは、バッチ集約プロセス全体を失敗させることなくレコードレベルのエラーを処理します。実行時に、これらのコネクタは対象リソースによって正常に受け入れられたレコード、および失敗したレコードを追跡します。レコードのグループ全体を失敗させる代わりに、できるだけ多くのレコードを更新/挿入し、通知目的で失敗を追跡します。 Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-processing-concept#phase_process)​を参照してください。 ## [](#aggregator_modify_records)Batch Aggregator 内でのレコードの変更 Batch Step コンポーネントのプロセッサーを使用して変更する場合と同様に、Batch Aggregator 内でレコードを変更できます。変更の実行は、順次または特定のレコードへのランダムアクセスで行うことができます。 ### [](#batch-aggregator-内の順次処理)Batch Aggregator 内の順次処理 次の例では、レコードへの順次アクセスを実行します。この例では、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ 内の Groovy を使用して、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.6/for-each-scope-concept)​ コンポーネントの反復から各レコードのペイロードを変更し、収集したレコードごとに変数を作成できます。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'hello' ``` ### [](#batch-aggregator-内でのレコードへのランダムアクセス)Batch Aggregator 内でのレコードへのランダムアクセス 反復回数でレコードにランダムにアクセスする場合、For Each スコープを使用することもできます。For Each は、​`records`​ 変数 (反復を追跡するために使用する不変リスト) を公開します。この変数を使用して、Batch Aggregator コンポーネントからリストのレコードにランダムにアクセスできます。 次の例では、固定サイズの集約を使用するときのランダムなアクセスを示すために、レコードの For Each リストでレコードのインデックスを指定します。各レコードに順次アクセスする代わりに、レコードのインデックスが含まれる ​`records`​ 変数を使用して、リストから 1 つのレコードを選択します。この例では、Scripting Module を使用して、選択したレコードのペイロードを変更し、そのレコードの変数を作成します。 ```xml records[0].vars['marco'] = 'polo' records[0].vars['record'].payload = 'hello' ``` コンテンツをストリーミングするように Batch Aggregator コンポーネントを設定できます。レコードをストリーミングするようにこのコンポーネントを設定すると (​`streaming="true"`​)、レコードの数や大きさに関係なく、メモリ不足にならずに Batch Job インスタンス内のすべてのレコードの配列を処理できます。たとえば、CSV ファイルに数百万件のレコードを書き込む必要がある場合、Batch Aggregator コンポーネントを使用してレコードをストリーミングできます。 ```xml ``` 次の例に示すように、Batch Aggregator コンポーネント内でストリーミングする場合は、レコードへの順次アクセスのみが可能です。ストリーミングでは、レコードセット全体にアクセスする必要があるため、ランダムアクセスはサポートされません。Mule では、固定サイズが指定されていない場合、すべてのレコードがメモリ内に収まることが保証されないため、この制限は必須です。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-processing-concept#phase_process)​を参照してください。 NOTE Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java Map を使用してシリアル化の問題を回避します。 ## [](#集約されたレコードの-mime-タイプの保持)集約されたレコードの MIME タイプの保持 _Mule 4.3 での導入_ 集約されたレコードは、各レコードのペイロードが含まれる配列コンポーネントとして Batch Aggregator コンポーネントに渡されます。ただし、デフォルトではそれらのペイロードに関連付けられている MIME タイプは保持されません。レコードの MIME タイプを保持するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を指定します。 次の JSON 配列を考えてみます。 ```json [ { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" }, { "name": "Steve Rodgers", "alias": "Captain America", "status": "RETIRED" }, { "name": "Peter Parker", "alias": "SpiderMan", "status": "FUGITIVE" } ] ``` [JSON 配列](#json_array)​が次の Batch Job コンポーネントの入力だとします。 ```xml ``` バッチエンジンは入力 JSON 配列を個々のレコードに分割します。つまり、アグリゲーターブロックで 3 つの要素が含まれる配列を受信します。1 つ目は次のようになります。 ```json { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" } ``` ただし、Logger コンポーネントで ​`#[payload.alias]`​ 式を評価しようとすると、次の結果のようなエラーが発生します。 ```text ******************************************************************************** Message : "You called the function 'Value Selector' with these arguments: 1: Binary ("ewogICJmaXJzdE5hbWUiOiAiUmFtIiwKICAibGFzdE5hbWUiOiAiUmFtMSIsCiAgImFkZHJlc3Mi...) 2: Name ("alias") But it expects one of these combinations: (Array, Name) (Array, String) (Date, Name) (DateTime, Name) (LocalDateTime, Name) (LocalTime, Name) (Object, Name) (Object, String) (Period, Name) (Time, Name) 5| name: payload.alias, ^^^^^^^^^^^^^ ``` このエラーは、MIME タイプが保持されないことが原因で発生します。これにより、Mule で JSON として読み取らなくなります。この問題を解決するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を ​`true`​ に設定します。次に例を示します。 ```xml ``` この設定により、Mule で各レコードのメディア種別が保持され、ペイロードが JSON ドキュメントとして処理されます。 ## [](#レコードブロックサイズの変更)レコードブロックサイズの変更 従来のオンライン処理モデルでは、各要求は通常、ワーカースレッドにマップされます。処理種別に関係なく、通常、要求と実行中のスレッドの間には 1 対 1 のリレーションがあります。このリレーションは、同期、非同期、一方向、要求-応答の処理種別や、処理前に要求が一時的にバッファされる場合に保持されます。 ただし、Batch Job の場合、Process (処理) フェーズが始まる前にレコードが最初に永続的なキューに保存されるため、従来のスレッドモデルは適用されません。 パフォーマンスを向上させるため、Mule Runtime はバッチレコードをスレッドごとに最大 100 件のレコードのブロックでキューに追加し、スケジュールします。この動作により I/O 要求数が削減され、操作の負荷が改善されます。Batch Job は Mule のスレッドプールを使用するため、ジョブのデフォルトはありません。各スレッドはそのブロックを反復処理して各レコードを処理し、その後各ブロックはキューに戻され、プロセスが続行されます。 3 ステップの Batch Job では、キューに 100 万件のレコードを追加することを検討してください。Mule Runtime Engine がジョブのフェーズ間を移動するときに各レコードの取得と要求を行うと、少なくとも 300 万回の I/O 操作が発生します。 パフォーマンスには、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 Batch Job の 1 スレッドあたり最大 100 件のレコードの標準モデルは、ほとんどのユースケースで機能しますが、ブロックサイズの増減が必要な次の 3 つのユースケースを考慮してください。 - Batch Job で処理するレコードが 200 件あるとします。デフォルトの 100 件のレコードのブロックサイズでは、Mule が同時に並行処理できるレコード数は 2 件のみです。Batch Job で処理するレコードが 101 件未満の場合、順次処理になります。負荷の高いペイロードを処理する必要がある場合、100 件のレコードをキューに追加するには大量の作業メモリが必要です。 - 画像を処理する必要がある Batch Job があり、平均画像サイズは 3 MB だとします。この場合、Mule は、各スレッドで 3 MB のペイロードを持つ 100 件のレコードのブロックを処理します。したがって、デフォルトの threading-profile 設定では、ブロックをキューで保持するためだけに大量の作業メモリが必要になります。この場合、より低いブロックサイズを設定して、より多くのジョブを介して各ペイロードを分散し、使用可能メモリの負荷を減らします。 - 500 万件のレコードがあり、ペイロードが非常に小さいためにメモリ内に 500 件のレコードのブロックを問題なく入れることができるとします。より大きなブロックサイズを設定すると、作業メモリの負荷を犠牲にすることなく Batch Job の時間を短縮できます。 この機能を最大限に活用するには、ブロックサイズが Batch Job に与える影響を理解する必要があります。異なる値とテストパフォーマンスを使用して比較テストを実行すると、この変更を本番に移行する前に最適なブロックサイズを見つけるために役立ちます。 バッチブロックサイズの変更は省略可能です。変更を適用しない場合、デフォルト値はブロックあたり 100 件のレコードです。 Batch Job コンポーネントを使用してサイズを設定します。次に例を示します。 ```xml ... ``` ## [](#batch-job-インスタンスの最大同時実行の制限の設定)Batch Job インスタンスの最大同時実行の制限の設定 Max Concurrency (最大同時実行) (​`maxConcurrency`​) プロパティでは、同時に処理するレコードブロックの数が制限されます。 `maxConcurrency`​ プロパティを次の例のように設定できます。 ```xml ... ``` デフォルトでは、Batch Job コンポーネントの最大同時実行は使用可能なコアの数の 2 倍に制限されます。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-processing-concept) - [Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-job-instance-id) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-backpressure-maxconcurrency) # Batch コンポーネントの設定 Mule バッチ処理コンポーネントをセットアップおよび設定して、一般的なバッチ処理のユースケースを実行したり、デフォルトを調整する必要がある場合にバッチジョブのパフォーマンスを改善したりできます。 ## [](#batch_filters)Batch Step コンポーネント内で処理するレコードの絞り込み 1 つ以上のレコード検索条件を属性として任意の数の Batch Step コンポーネントに適用できます。たとえば、特定の Batch Job コンポーネント内の最初の Batch Step コンポーネントで各レコードの Salesforce 取引先責任者をチェックして、2 番目の Batch Step コンポーネントでそれらのレコードの取引先責任者情報を更新します。2 番目の Batch Step で最初のステップで成功したレコードのみを処理するようにするには、2 番目の Batch Step で検索条件を設定します。検索条件によって処理が合理化されるため、Mule は特定のステップの関連するデータにのみ集中できます。 レコードを絞り込むために、Batch Step コンポーネントでは、1 つの ​`acceptExpression`​ と 1 つの ​`acceptPolicy`​ がサポートされています。どちらも省略可能で、他の Mule コンポーネントではこれらの検索条件を使用できません。同じコンポーネントで両方の検索条件を使用する場合、Mule は検索条件を次の順序で評価します。 1. 受け入れポリシー: [acceptExpression](#accept_expression) 2. 受け入れ式: [acceptPolicy](#accept_policy) `acceptExpression`​ 属性を使用する Batch Step コンポーネントは、このコンポーネントに到達する各レコードに DataWeave 式を適用し、式が ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。レコードが ​`false`​ に評価される場合、Batch Step コンポーネントはレコードをスキップし、そのレコードは Batch Job コンポーネント内の次の Batch Step コンポーネント (存在する場合) で使用できるようになります。 以下の例では、​`age`​ の値が ​`21`​ 以下のすべてのレコードを除外します。 ```xml ... ``` Batch Step コンポーネントは、​`acceptPolicy`​ 属性を使用して、以前の Batch Step コンポーネントで処理されたレコードにポリシーを適用します。Batch Step は、ポリシーが ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。デフォルトのポリシーは ​`NO_FAILURES`​ です。他のポリシーは ​`ONLY_FAILURES`​ と ​`ALL`​ です。これらのポリシーの詳細は、​[「Batch Step コンポーネント ()」](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-reference#ref_batch_step_component)​を参照してください。 次の例では、2 番目の Batch Step コンポーネント (​`batchStep2`​) で、先行するステップ (​`batchStep1`​) で正常に処理できなかったレコードのみを受け入れます。たとえば、​`batchStep1`​ 内のプロセッサーで Salesforce 取引先責任者の各レコードをチェックするとします。チェックで取引先責任者が見つからなかった場合、​`batchStep2`​ は、取引先責任者のないレコードのみを受け入れて、取引先責任者のあるレコードはスキップします。​`batchStep2`​ 内のメッセージプロセッサーは取引先責任者をそれらのレコードに追加することができます。 ```xml ... ... ``` 次の例では、デモ目的で Raise Error コンポーネント (​``​) を使用して、最初の Batch Step (​`batchStep1`​) で失敗が発生するようにします。2 番目の Batch Step (​`batchStep2`​) は、失敗したレコード (​`ONLY_FAILURES`​) のみを受け入れ、それらのレコードのペイロードを記録します。3 番目は、デフォルトの ​`acceptPolicy`​ を使用して ​`NO_FAILURES`​ を受け入れます。 ```xml ``` - Set Payload コンポーネント (​``​) は、配列 ​`[1,2,3,4,5]`​ を Batch Job コンポーネントに送信します。 - Batch Job コンポーネント (​``​) は、最初の Batch Step コンポーネント内で失敗したレコードによって Batch Job インスタンスの処理が停止しないように ​`maxFailedRecords`​ を ​`-1`​ に設定します。 - 最初の Batch Step (​`batchStep1`​) は、​`acceptExpression="#[payload < 3]"`​ を設定して、ペイロードが ​`3`​ 未満のレコードのみを受け入れ、そのコンポーネント内の Raise Error コンポーネントにより、それらのレコードでエラーをスローします。 ```logs INFO ...DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'f9bb6d60-5ef2-11ed-81e7-147ddaaf4f97' of job 'batch-example-policiesBatch_Job'. ``` - 2 番目の Batch Step (​`batchStep2`​) は、次のように失敗したレコードのペイロードを出力します。 ```logs INFO ... LOGGER IN SECOND BATCH STEP: 1 INFO ... LOGGER IN SECOND BATCH STEP: 2 ``` - 3 番目の Batch Step (​`batchStep3`​) は、次のように成功したレコードのペイロードを出力します。 ```logs INFO ... LOGS IN THIRD BATCH STEP: 3 INFO ...LOGS IN THIRD BATCH STEP: 4 INFO ...LOGS IN THIRD BATCH STEP: 5 ``` - Batch Job インスタンスの完了後、​`3`​ つのレコードが正常に処理されて、​`2`​ つのレコードが失敗したことがログに示されます。 ```logs INFO ...engine.DefaultBatchEngine: Finished execution for instance ... Total Records processed: 5. Successful records: 3. Failed Records: 2 ``` 詳細は、「[Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-error-handling-faq)」を参照してください。 ## [](#aggregator_bulk_update)Batch Aggregator コンポーネントからの一括操作の実行 集約は、配列内の複数のレコードを外部サーバーに送信する場合に便利です。Batch Aggregator コンポーネント内で操作 (一括更新、挿入、更新など) を追加することで、レコードごとに個別に操作を実行する代わりに、操作の 1 つの実行で複数のレコードをサーバーに読み込むことができます。 固定サイズの個別の配列でレコードを処理することも、Batch Job インスタンスから 1 つのレコード配列をストリーミングすることもできます。たとえば、200 件の処理済みレコードを更新/挿入するように、Salesforce 用 Anypoint Connector (Salesforce Connector) で Upsert 操作を設定できます。または、インスタンス内のすべてのレコードをサーバーにストリーミングすることもできます。 次の例では、更新/挿入あたり 200 件のレコードの個別の配列でレコードを一括更新/挿入します。 ```xml ``` 次の例では、データベースに更新/挿入をストリーミングします。 ```xml salesforce:upsert doc:name="Upsert" ... /> ``` エラー処理: [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#Upsert)​ などの一部のコネクタは、バッチ集約プロセス全体を失敗させることなくレコードレベルのエラーを処理します。実行時に、これらのコネクタは対象リソースによって正常に受け入れられたレコード、および失敗したレコードを追跡します。レコードのグループ全体を失敗させる代わりに、できるだけ多くのレコードを更新/挿入し、通知目的で失敗を追跡します。 Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-processing-concept#phase_process)​を参照してください。 ## [](#aggregator_modify_records)Batch Aggregator 内でのレコードの変更 Batch Step コンポーネントのプロセッサーを使用して変更する場合と同様に、Batch Aggregator 内でレコードを変更できます。変更の実行は、順次または特定のレコードへのランダムアクセスで行うことができます。 ### [](#batch-aggregator-内の順次処理)Batch Aggregator 内の順次処理 次の例では、レコードへの順次アクセスを実行します。この例では、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ 内の Groovy を使用して、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.7/for-each-scope-concept)​ コンポーネントの反復から各レコードのペイロードを変更し、収集したレコードごとに変数を作成できます。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'hello' ``` ### [](#batch-aggregator-内でのレコードへのランダムアクセス)Batch Aggregator 内でのレコードへのランダムアクセス 反復回数でレコードにランダムにアクセスする場合、For Each スコープを使用することもできます。For Each は、​`records`​ 変数 (反復を追跡するために使用する不変リスト) を公開します。この変数を使用して、Batch Aggregator コンポーネントからリストのレコードにランダムにアクセスできます。 次の例では、固定サイズの集約を使用するときのランダムなアクセスを示すために、レコードの For Each リストでレコードのインデックスを指定します。各レコードに順次アクセスする代わりに、レコードのインデックスが含まれる ​`records`​ 変数を使用して、リストから 1 つのレコードを選択します。この例では、Scripting Module を使用して、選択したレコードのペイロードを変更し、そのレコードの変数を作成します。 ```xml records[0].vars['marco'] = 'polo' records[0].vars['record'].payload = 'hello' ``` コンテンツをストリーミングするように Batch Aggregator コンポーネントを設定できます。レコードをストリーミングするようにこのコンポーネントを設定すると (​`streaming="true"`​)、レコードの数や大きさに関係なく、メモリ不足にならずに Batch Job インスタンス内のすべてのレコードの配列を処理できます。たとえば、CSV ファイルに数百万件のレコードを書き込む必要がある場合、Batch Aggregator コンポーネントを使用してレコードをストリーミングできます。 ```xml ``` 次の例に示すように、Batch Aggregator コンポーネント内でストリーミングする場合は、レコードへの順次アクセスのみが可能です。ストリーミングでは、レコードセット全体にアクセスする必要があるため、ランダムアクセスはサポートされません。Mule では、固定サイズが指定されていない場合、すべてのレコードがメモリ内に収まることが保証されないため、この制限は必須です。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-processing-concept#phase_process)​を参照してください。 NOTE Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java Map を使用してシリアル化の問題を回避します。 ## [](#集約されたレコードの-mime-タイプの保持)集約されたレコードの MIME タイプの保持 _Mule 4.3 での導入_ 集約されたレコードは、各レコードのペイロードが含まれる配列コンポーネントとして Batch Aggregator コンポーネントに渡されます。ただし、デフォルトではそれらのペイロードに関連付けられている MIME タイプは保持されません。レコードの MIME タイプを保持するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を指定します。 次の JSON 配列を考えてみます。 ```json [ { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" }, { "name": "Steve Rodgers", "alias": "Captain America", "status": "RETIRED" }, { "name": "Peter Parker", "alias": "SpiderMan", "status": "FUGITIVE" } ] ``` [JSON 配列](#json_array)​が次の Batch Job コンポーネントの入力だとします。 ```xml ``` バッチエンジンは入力 JSON 配列を個々のレコードに分割します。つまり、アグリゲーターブロックで 3 つの要素が含まれる配列を受信します。1 つ目は次のようになります。 ```json { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" } ``` ただし、Logger コンポーネントで ​`#[payload.alias]`​ 式を評価しようとすると、次の結果のようなエラーが発生します。 ```text ******************************************************************************** Message : "You called the function 'Value Selector' with these arguments: 1: Binary ("ewogICJmaXJzdE5hbWUiOiAiUmFtIiwKICAibGFzdE5hbWUiOiAiUmFtMSIsCiAgImFkZHJlc3Mi...) 2: Name ("alias") But it expects one of these combinations: (Array, Name) (Array, String) (Date, Name) (DateTime, Name) (LocalDateTime, Name) (LocalTime, Name) (Object, Name) (Object, String) (Period, Name) (Time, Name) 5| name: payload.alias, ^^^^^^^^^^^^^ ``` このエラーは、MIME タイプが保持されないことが原因で発生します。これにより、Mule で JSON として読み取らなくなります。この問題を解決するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を ​`true`​ に設定します。次に例を示します。 ```xml ``` この設定により、Mule で各レコードのメディア種別が保持され、ペイロードが JSON ドキュメントとして処理されます。 ## [](#レコードブロックサイズの変更)レコードブロックサイズの変更 従来のオンライン処理モデルでは、各要求は通常、ワーカースレッドにマップされます。処理種別に関係なく、通常、要求と実行中のスレッドの間には 1 対 1 のリレーションがあります。このリレーションは、同期、非同期、一方向、要求-応答の処理種別や、処理前に要求が一時的にバッファされる場合に保持されます。 ただし、Batch Job の場合、Process (処理) フェーズが始まる前にレコードが最初に永続的なキューに保存されるため、従来のスレッドモデルは適用されません。 パフォーマンスを向上させるため、Mule Runtime はバッチレコードをスレッドごとに最大 100 件のレコードのブロックでキューに追加し、スケジュールします。この動作により I/O 要求数が削減され、操作の負荷が改善されます。Batch Job は Mule のスレッドプールを使用するため、ジョブのデフォルトはありません。各スレッドはそのブロックを反復処理して各レコードを処理し、その後各ブロックはキューに戻され、プロセスが続行されます。 3 ステップの Batch Job では、キューに 100 万件のレコードを追加することを検討してください。Mule Runtime Engine がジョブのフェーズ間を移動するときに各レコードの取得と要求を行うと、少なくとも 300 万回の I/O 操作が発生します。 パフォーマンスには、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 Batch Job の 1 スレッドあたり最大 100 件のレコードの標準モデルは、ほとんどのユースケースで機能しますが、ブロックサイズの増減が必要な次の 3 つのユースケースを考慮してください。 - Batch Job で処理するレコードが 200 件あるとします。デフォルトの 100 件のレコードのブロックサイズでは、Mule が同時に並行処理できるレコード数は 2 件のみです。Batch Job で処理するレコードが 101 件未満の場合、順次処理になります。負荷の高いペイロードを処理する必要がある場合、100 件のレコードをキューに追加するには大量の作業メモリが必要です。 - 画像を処理する必要がある Batch Job があり、平均画像サイズは 3 MB だとします。この場合、Mule は、各スレッドで 3 MB のペイロードを持つ 100 件のレコードのブロックを処理します。したがって、デフォルトの threading-profile 設定では、ブロックをキューで保持するためだけに大量の作業メモリが必要になります。この場合、より低いブロックサイズを設定して、より多くのジョブを介して各ペイロードを分散し、使用可能メモリの負荷を減らします。 - 500 万件のレコードがあり、ペイロードが非常に小さいためにメモリ内に 500 件のレコードのブロックを問題なく入れることができるとします。より大きなブロックサイズを設定すると、作業メモリの負荷を犠牲にすることなく Batch Job の時間を短縮できます。 この機能を最大限に活用するには、ブロックサイズが Batch Job に与える影響を理解する必要があります。異なる値とテストパフォーマンスを使用して比較テストを実行すると、この変更を本番に移行する前に最適なブロックサイズを見つけるために役立ちます。 バッチブロックサイズの変更は省略可能です。変更を適用しない場合、デフォルト値はブロックあたり 100 件のレコードです。 Batch Job コンポーネントを使用してサイズを設定します。次に例を示します。 ```xml ... ``` ## [](#batch-job-インスタンスの最大同時実行の制限の設定)Batch Job インスタンスの最大同時実行の制限の設定 Max Concurrency (最大同時実行) (​`maxConcurrency`​) プロパティでは、同時に処理するレコードブロックの数が制限されます。 `maxConcurrency`​ プロパティを次の例のように設定できます。 ```xml ... ``` デフォルトでは、Batch Job コンポーネントの最大同時実行は使用可能なコアの数の 2 倍に制限されます。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-processing-concept) - [Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-job-instance-id) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-backpressure-maxconcurrency) # Batch コンポーネントの設定 Mule バッチ処理コンポーネントをセットアップおよび設定して、一般的なバッチ処理のユースケースを実行したり、デフォルトを調整する必要がある場合にバッチジョブのパフォーマンスを改善したりできます。 ## [](#batch_filters)Batch Step コンポーネント内で処理するレコードの絞り込み 1 つ以上のレコード検索条件を属性として任意の数の Batch Step コンポーネントに適用できます。たとえば、特定の Batch Job コンポーネント内の最初の Batch Step コンポーネントで各レコードの Salesforce 取引先責任者をチェックして、2 番目の Batch Step コンポーネントでそれらのレコードの取引先責任者情報を更新します。2 番目の Batch Step で最初のステップで成功したレコードのみを処理するようにするには、2 番目の Batch Step で検索条件を設定します。検索条件によって処理が合理化されるため、Mule は特定のステップの関連するデータにのみ集中できます。 レコードを絞り込むために、Batch Step コンポーネントでは、1 つの ​`acceptExpression`​ と 1 つの ​`acceptPolicy`​ がサポートされています。どちらも省略可能で、他の Mule コンポーネントではこれらの検索条件を使用できません。同じコンポーネントで両方の検索条件を使用する場合、Mule は検索条件を次の順序で評価します。 1. 受け入れポリシー: [acceptExpression](#accept_expression) 2. 受け入れ式: [acceptPolicy](#accept_policy) `acceptExpression`​ 属性を使用する Batch Step コンポーネントは、このコンポーネントに到達する各レコードに DataWeave 式を適用し、式が ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。レコードが ​`false`​ に評価される場合、Batch Step コンポーネントはレコードをスキップし、そのレコードは Batch Job コンポーネント内の次の Batch Step コンポーネント (存在する場合) で使用できるようになります。 以下の例では、​`age`​ の値が ​`21`​ 以下のすべてのレコードを除外します。 ```xml ... ``` Batch Step コンポーネントは、​`acceptPolicy`​ 属性を使用して、以前の Batch Step コンポーネントで処理されたレコードにポリシーを適用します。Batch Step は、ポリシーが ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。デフォルトのポリシーは ​`NO_FAILURES`​ です。他のポリシーは ​`ONLY_FAILURES`​ と ​`ALL`​ です。これらのポリシーの詳細は、​[「Batch Step コンポーネント ()」](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-reference#ref_batch_step_component)​を参照してください。 次の例では、2 番目の Batch Step コンポーネント (​`batchStep2`​) で、先行するステップ (​`batchStep1`​) で正常に処理できなかったレコードのみを受け入れます。たとえば、​`batchStep1`​ 内のプロセッサーで Salesforce 取引先責任者の各レコードをチェックするとします。チェックで取引先責任者が見つからなかった場合、​`batchStep2`​ は、取引先責任者のないレコードのみを受け入れて、取引先責任者のあるレコードはスキップします。​`batchStep2`​ 内のメッセージプロセッサーは取引先責任者をそれらのレコードに追加することができます。 ```xml ... ... ``` 次の例では、デモ目的で Raise Error コンポーネント (​``​) を使用して、最初の Batch Step (​`batchStep1`​) で失敗が発生するようにします。2 番目の Batch Step (​`batchStep2`​) は、失敗したレコード (​`ONLY_FAILURES`​) のみを受け入れ、それらのレコードのペイロードを記録します。3 番目は、デフォルトの ​`acceptPolicy`​ を使用して ​`NO_FAILURES`​ を受け入れます。 ```xml ``` - Set Payload コンポーネント (​``​) は、配列 ​`[1,2,3,4,5]`​ を Batch Job コンポーネントに送信します。 - Batch Job コンポーネント (​``​) は、最初の Batch Step コンポーネント内で失敗したレコードによって Batch Job インスタンスの処理が停止しないように ​`maxFailedRecords`​ を ​`-1`​ に設定します。 - 最初の Batch Step (​`batchStep1`​) は、​`acceptExpression="#[payload < 3]"`​ を設定して、ペイロードが ​`3`​ 未満のレコードのみを受け入れ、そのコンポーネント内の Raise Error コンポーネントにより、それらのレコードでエラーをスローします。 ```logs INFO ...DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'f9bb6d60-5ef2-11ed-81e7-147ddaaf4f97' of job 'batch-example-policiesBatch_Job'. ``` - 2 番目の Batch Step (​`batchStep2`​) は、次のように失敗したレコードのペイロードを出力します。 ```logs INFO ... LOGGER IN SECOND BATCH STEP: 1 INFO ... LOGGER IN SECOND BATCH STEP: 2 ``` - 3 番目の Batch Step (​`batchStep3`​) は、次のように成功したレコードのペイロードを出力します。 ```logs INFO ... LOGS IN THIRD BATCH STEP: 3 INFO ...LOGS IN THIRD BATCH STEP: 4 INFO ...LOGS IN THIRD BATCH STEP: 5 ``` - Batch Job インスタンスの完了後、​`3`​ つのレコードが正常に処理されて、​`2`​ つのレコードが失敗したことがログに示されます。 ```logs INFO ...engine.DefaultBatchEngine: Finished execution for instance ... Total Records processed: 5. Successful records: 3. Failed Records: 2 ``` 詳細は、[Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-error-handling-faq)を参照してください。 ## [](#aggregator_bulk_update)Batch Aggregator コンポーネントからの一括操作の実行 集約は、配列内の複数のレコードを外部サーバーに送信する場合に便利です。Batch Aggregator コンポーネント内で操作 (一括更新、挿入、更新など) を追加することで、レコードごとに個別に操作を実行する代わりに、操作の 1 つの実行で複数のレコードをサーバーに読み込むことができます。 固定サイズの個別の配列でレコードを処理することも、Batch Job インスタンスから 1 つのレコード配列をストリーミングすることもできます。たとえば、200 件の処理済みレコードを更新/挿入するように、Salesforce 用 Anypoint Connector (Salesforce Connector) で Upsert 操作を設定できます。または、インスタンス内のすべてのレコードをサーバーにストリーミングすることもできます。 次の例では、更新/挿入あたり 200 件のレコードの個別の配列でレコードを一括更新/挿入します。 ```xml ``` 次の例では、データベースに更新/挿入をストリーミングします。 ```xml salesforce:upsert doc:name="Upsert" ... /> ``` エラー処理: [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#Upsert)​ などの一部のコネクタは、バッチ集約プロセス全体を失敗させることなくレコードレベルのエラーを処理します。実行時に、これらのコネクタは対象リソースによって正常に受け入れられたレコード、および失敗したレコードを追跡します。レコードのグループ全体を失敗させる代わりに、できるだけ多くのレコードを更新/挿入し、通知目的で失敗を追跡します。 Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-processing-concept#phase_process)​を参照してください。 ## [](#aggregator_modify_records)Batch Aggregator 内でのレコードの変更 Batch Step コンポーネントのプロセッサーを使用して変更する場合と同様に、Batch Aggregator 内でレコードを変更できます。変更の実行は、順次または特定のレコードへのランダムアクセスで行うことができます。 ### [](#batch-aggregator-内の順次処理)Batch Aggregator 内の順次処理 次の例では、レコードへの順次アクセスを実行します。この例では、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ 内の Groovy を使用して、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.8/for-each-scope-concept)​ コンポーネントの反復から各レコードのペイロードを変更し、収集したレコードごとに変数を作成できます。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'hello' ``` ### [](#batch-aggregator-内でのレコードへのランダムアクセス)Batch Aggregator 内でのレコードへのランダムアクセス 反復回数でレコードにランダムにアクセスする場合、For Each スコープを使用することもできます。For Each は、​`records`​ 変数 (反復を追跡するために使用する不変リスト) を公開します。この変数を使用して、Batch Aggregator コンポーネントからリストのレコードにランダムにアクセスできます。 次の例では、固定サイズの集約を使用するときのランダムなアクセスを示すために、レコードの For Each リストでレコードのインデックスを指定します。各レコードに順次アクセスする代わりに、レコードのインデックスが含まれる ​`records`​ 変数を使用して、リストから 1 つのレコードを選択します。この例では、Scripting Module を使用して、選択したレコードのペイロードを変更し、そのレコードの変数を作成します。 ```xml records[0].vars['marco'] = 'polo' records[0].vars['record'].payload = 'hello' ``` コンテンツをストリーミングするように Batch Aggregator コンポーネントを設定できます。レコードをストリーミングするようにこのコンポーネントを設定すると (​`streaming="true"`​)、レコードの数や大きさに関係なく、メモリ不足にならずに Batch Job インスタンス内のすべてのレコードの配列を処理できます。たとえば、CSV ファイルに数百万件のレコードを書き込む必要がある場合、Batch Aggregator コンポーネントを使用してレコードをストリーミングできます。 ```xml ``` 次の例に示すように、Batch Aggregator コンポーネント内でストリーミングする場合は、レコードへの順次アクセスのみが可能です。ストリーミングでは、レコードセット全体にアクセスする必要があるため、ランダムアクセスはサポートされません。Mule では、固定サイズが指定されていない場合、すべてのレコードがメモリ内に収まることが保証されないため、この制限は必須です。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-processing-concept#phase_process)​を参照してください。 NOTE Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java Map を使用してシリアル化の問題を回避します。 ## [](#集約されたレコードの-mime-タイプの保持)集約されたレコードの MIME タイプの保持 _Mule 4.3 での導入_ 集約されたレコードは、各レコードのペイロードが含まれる配列コンポーネントとして Batch Aggregator コンポーネントに渡されます。ただし、デフォルトではそれらのペイロードに関連付けられている MIME タイプは保持されません。レコードの MIME タイプを保持するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を指定します。 次の JSON 配列を考えてみます。 ```json [ { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" }, { "name": "Steve Rodgers", "alias": "Captain America", "status": "RETIRED" }, { "name": "Peter Parker", "alias": "SpiderMan", "status": "FUGITIVE" } ] ``` [JSON 配列](#json_array)​が次の Batch Job コンポーネントの入力だとします。 ```xml ``` バッチエンジンは入力 JSON 配列を個々のレコードに分割します。つまり、アグリゲーターブロックで 3 つの要素が含まれる配列を受信します。1 つ目は次のようになります。 ```json { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" } ``` ただし、Logger コンポーネントで ​`#[payload.alias]`​ 式を評価しようとすると、次の結果のようなエラーが発生します。 ```text ******************************************************************************** Message : "You called the function 'Value Selector' with these arguments: 1: Binary ("ewogICJmaXJzdE5hbWUiOiAiUmFtIiwKICAibGFzdE5hbWUiOiAiUmFtMSIsCiAgImFkZHJlc3Mi...) 2: Name ("alias") But it expects one of these combinations: (Array, Name) (Array, String) (Date, Name) (DateTime, Name) (LocalDateTime, Name) (LocalTime, Name) (Object, Name) (Object, String) (Period, Name) (Time, Name) 5| name: payload.alias, ^^^^^^^^^^^^^ ``` このエラーは、MIME タイプが保持されないことが原因で発生します。これにより、Mule で JSON として読み取らなくなります。この問題を解決するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を ​`true`​ に設定します。次に例を示します。 ```xml ``` この設定により、Mule で各レコードのメディア種別が保持され、ペイロードが JSON ドキュメントとして処理されます。 ## [](#レコードブロックサイズの変更)レコードブロックサイズの変更 従来のオンライン処理モデルでは、各要求は通常、ワーカースレッドにマップされます。処理種別に関係なく、通常、要求と実行中のスレッドの間には 1 対 1 のリレーションがあります。このリレーションは、同期、非同期、一方向、要求-応答の処理種別や、処理前に要求が一時的にバッファされる場合に保持されます。 ただし、Batch Job の場合、Process (処理) フェーズが始まる前にレコードが最初に永続的なキューに保存されるため、従来のスレッドモデルは適用されません。 パフォーマンスを向上させるため、Mule Runtime はバッチレコードをスレッドごとに最大 100 件のレコードのブロックでキューに追加し、スケジュールします。この動作により I/O 要求数が削減され、操作の負荷が改善されます。Batch Job は Mule のスレッドプールを使用するため、ジョブのデフォルトはありません。各スレッドはそのブロックを反復処理して各レコードを処理し、その後各ブロックはキューに戻され、プロセスが続行されます。 3 ステップの Batch Job では、キューに 100 万件のレコードを追加することを検討してください。Mule Runtime Engine がジョブのフェーズ間を移動するときに各レコードの取得と要求を行うと、少なくとも 300 万回の I/O 操作が発生します。 パフォーマンスには、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 Batch Job の 1 スレッドあたり最大 100 件のレコードの標準モデルは、ほとんどのユースケースで機能しますが、ブロックサイズの増減が必要な次の 3 つのユースケースを考慮してください。 - Batch Job で処理するレコードが 200 件あるとします。デフォルトの 100 件のレコードのブロックサイズでは、Mule が同時に並行処理できるレコード数は 2 件のみです。Batch Job で処理するレコードが 101 件未満の場合、順次処理になります。負荷の高いペイロードを処理する必要がある場合、100 件のレコードをキューに追加するには大量の作業メモリが必要です。 - 画像を処理する必要がある Batch Job があり、平均画像サイズは 3 MB だとします。この場合、Mule は、各スレッドで 3 MB のペイロードを持つ 100 件のレコードのブロックを処理します。したがって、デフォルトの threading-profile 設定では、ブロックをキューで保持するためだけに大量の作業メモリが必要になります。この場合、より低いブロックサイズを設定して、より多くのジョブを介して各ペイロードを分散し、使用可能メモリの負荷を減らします。 - 500 万件のレコードがあり、ペイロードが非常に小さいためにメモリ内に 500 件のレコードのブロックを問題なく入れることができるとします。より大きなブロックサイズを設定すると、作業メモリの負荷を犠牲にすることなく Batch Job の時間を短縮できます。 この機能を最大限に活用するには、ブロックサイズが Batch Job に与える影響を理解する必要があります。異なる値とテストパフォーマンスを使用して比較テストを実行すると、この変更を本番に移行する前に最適なブロックサイズを見つけるために役立ちます。 バッチブロックサイズの変更は省略可能です。変更を適用しない場合、デフォルト値はブロックあたり 100 件のレコードです。 Batch Job コンポーネントを使用してサイズを設定します。次に例を示します。 ```xml ... ``` ## [](#batch-job-インスタンスの最大同時実行の制限の設定)Batch Job インスタンスの最大同時実行の制限の設定 Max Concurrency (最大同時実行) (​`maxConcurrency`​) プロパティでは、同時に処理するレコードブロックの数が制限されます。 `maxConcurrency`​ プロパティを次の例のように設定できます。 ```xml ... ``` デフォルトでは、Batch Job コンポーネントの最大同時実行は使用可能なコアの数の 2 倍に制限されます。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-processing-concept) - [Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-job-instance-id) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-backpressure-maxconcurrency) # Batch コンポーネントの設定 Mule バッチ処理コンポーネントをセットアップおよび設定して、一般的なバッチ処理のユースケースを実行したり、デフォルトを調整する必要がある場合にバッチジョブのパフォーマンスを改善したりできます。 ## [](#batch_filters)Batch Step コンポーネント内で処理するレコードの絞り込み 1 つ以上のレコード検索条件を属性として任意の数の Batch Step コンポーネントに適用できます。たとえば、特定の Batch Job コンポーネント内の最初の Batch Step コンポーネントで各レコードの Salesforce 取引先責任者をチェックして、2 番目の Batch Step コンポーネントでそれらのレコードの取引先責任者情報を更新します。2 番目の Batch Step で最初のステップで成功したレコードのみを処理するようにするには、2 番目の Batch Step で検索条件を設定します。検索条件によって処理が合理化されるため、Mule は特定のステップの関連するデータにのみ集中できます。 レコードを絞り込むために、Batch Step コンポーネントでは、1 つの ​`acceptExpression`​ と 1 つの ​`acceptPolicy`​ がサポートされています。どちらも省略可能で、他の Mule コンポーネントではこれらの検索条件を使用できません。同じコンポーネントで両方の検索条件を使用する場合、Mule は検索条件を次の順序で評価します。 1. 受け入れポリシー: [acceptExpression](#accept_expression) 2. 受け入れ式: [acceptPolicy](#accept_policy) `acceptExpression`​ 属性を使用する Batch Step コンポーネントは、このコンポーネントに到達する各レコードに DataWeave 式を適用し、式が ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。レコードが ​`false`​ に評価される場合、Batch Step コンポーネントはレコードをスキップし、そのレコードは Batch Job コンポーネント内の次の Batch Step コンポーネント (存在する場合) で使用できるようになります。 以下の例では、​`age`​ の値が ​`21`​ 以下のすべてのレコードを除外します。 ```xml ... ``` Batch Step コンポーネントは、​`acceptPolicy`​ 属性を使用して、以前の Batch Step コンポーネントで処理されたレコードにポリシーを適用します。Batch Step は、ポリシーが ​`true`​ に評価されたレコードのみを受け入れて、コンポーネント内で処理します。デフォルトのポリシーは ​`NO_FAILURES`​ です。他のポリシーは ​`ONLY_FAILURES`​ と ​`ALL`​ です。これらのポリシーの詳細は、​[「Batch Step コンポーネント ()」](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-reference#ref_batch_step_component)​を参照してください。 次の例では、2 番目の Batch Step コンポーネント (​`batchStep2`​) で、先行するステップ (​`batchStep1`​) で正常に処理できなかったレコードのみを受け入れます。たとえば、​`batchStep1`​ 内のプロセッサーで Salesforce 取引先責任者の各レコードをチェックするとします。チェックで取引先責任者が見つからなかった場合、​`batchStep2`​ は、取引先責任者のないレコードのみを受け入れて、取引先責任者のあるレコードはスキップします。​`batchStep2`​ 内のメッセージプロセッサーは取引先責任者をそれらのレコードに追加することができます。 ```xml ... ... ``` 次の例では、デモ目的で Raise Error コンポーネント (​``​) を使用して、最初の Batch Step (​`batchStep1`​) で失敗が発生するようにします。2 番目の Batch Step (​`batchStep2`​) は、失敗したレコード (​`ONLY_FAILURES`​) のみを受け入れ、それらのレコードのペイロードを記録します。3 番目は、デフォルトの ​`acceptPolicy`​ を使用して ​`NO_FAILURES`​ を受け入れます。 ```xml ``` - Set Payload コンポーネント (​``​) は、配列 ​`[1,2,3,4,5]`​ を Batch Job コンポーネントに送信します。 - Batch Job コンポーネント (​``​) は、最初の Batch Step コンポーネント内で失敗したレコードによって Batch Job インスタンスの処理が停止しないように ​`maxFailedRecords`​ を ​`-1`​ に設定します。 - 最初の Batch Step (​`batchStep1`​) は、​`acceptExpression="#[payload < 3]"`​ を設定して、ペイロードが ​`3`​ 未満のレコードのみを受け入れ、そのコンポーネント内の Raise Error コンポーネントにより、それらのレコードでエラーをスローします。 ```logs INFO ...DefaultBatchStep: Found exception processing record on step 'batchStep1' for job instance 'f9bb6d60-5ef2-11ed-81e7-147ddaaf4f97' of job 'batch-example-policiesBatch_Job'. ``` - 2 番目の Batch Step (​`batchStep2`​) は、次のように失敗したレコードのペイロードを出力します。 ```logs INFO ... LOGGER IN SECOND BATCH STEP: 1 INFO ... LOGGER IN SECOND BATCH STEP: 2 ``` - 3 番目の Batch Step (​`batchStep3`​) は、次のように成功したレコードのペイロードを出力します。 ```logs INFO ... LOGS IN THIRD BATCH STEP: 3 INFO ...LOGS IN THIRD BATCH STEP: 4 INFO ...LOGS IN THIRD BATCH STEP: 5 ``` - Batch Job インスタンスの完了後、​`3`​ つのレコードが正常に処理されて、​`2`​ つのレコードが失敗したことがログに示されます。 ```logs INFO ...engine.DefaultBatchEngine: Finished execution for instance ... Total Records processed: 5. Successful records: 3. Failed Records: 2 ``` 詳細は、[Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-error-handling-faq)を参照してください。 ## [](#aggregator_bulk_update)Batch Aggregator コンポーネントからの一括操作の実行 集約は、配列内の複数のレコードを外部サーバーに送信する場合に便利です。Batch Aggregator コンポーネント内で操作 (一括更新、挿入、更新など) を追加することで、レコードごとに個別に操作を実行する代わりに、操作の 1 つの実行で複数のレコードをサーバーに読み込むことができます。 固定サイズの個別の配列でレコードを処理することも、Batch Job インスタンスから 1 つのレコード配列をストリーミングすることもできます。たとえば、200 件の処理済みレコードを更新/挿入するように、Salesforce 用 Anypoint Connector (Salesforce Connector) で Upsert 操作を設定できます。または、インスタンス内のすべてのレコードをサーバーにストリーミングすることもできます。 次の例では、更新/挿入あたり 200 件のレコードの個別の配列でレコードを一括更新/挿入します。 ```xml ``` 次の例では、データベースに更新/挿入をストリーミングします。 ```xml salesforce:upsert doc:name="Upsert" ... /> ``` エラー処理: [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#Upsert)​ などの一部のコネクタは、バッチ集約プロセス全体を失敗させることなくレコードレベルのエラーを処理します。実行時に、これらのコネクタは対象リソースによって正常に受け入れられたレコード、および失敗したレコードを追跡します。レコードのグループ全体を失敗させる代わりに、できるだけ多くのレコードを更新/挿入し、通知目的で失敗を追跡します。 Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-processing-concept#phase_process)​を参照してください。 ## [](#aggregator_modify_records)Batch Aggregator 内でのレコードの変更 Batch Step コンポーネントのプロセッサーを使用して変更する場合と同様に、Batch Aggregator 内でレコードを変更できます。変更の実行は、順次または特定のレコードへのランダムアクセスで行うことができます。 ### [](#batch-aggregator-内の順次処理)Batch Aggregator 内の順次処理 次の例では、レコードへの順次アクセスを実行します。この例では、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ 内の Groovy を使用して、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.9/for-each-scope-concept)​ コンポーネントの反復から各レコードのペイロードを変更し、収集したレコードごとに変数を作成できます。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'hello' ``` ### [](#batch-aggregator-内でのレコードへのランダムアクセス)Batch Aggregator 内でのレコードへのランダムアクセス 反復回数でレコードにランダムにアクセスする場合、For Each スコープを使用することもできます。For Each は、​`records`​ 変数 (反復を追跡するために使用する不変リスト) を公開します。この変数を使用して、Batch Aggregator コンポーネントからリストのレコードにランダムにアクセスできます。 次の例では、固定サイズの集約を使用するときのランダムなアクセスを示すために、レコードの For Each リストでレコードのインデックスを指定します。各レコードに順次アクセスする代わりに、レコードのインデックスが含まれる ​`records`​ 変数を使用して、リストから 1 つのレコードを選択します。この例では、Scripting Module を使用して、選択したレコードのペイロードを変更し、そのレコードの変数を作成します。 ```xml records[0].vars['marco'] = 'polo' records[0].vars['record'].payload = 'hello' ``` コンテンツをストリーミングするように Batch Aggregator コンポーネントを設定できます。レコードをストリーミングするようにこのコンポーネントを設定すると (​`streaming="true"`​)、レコードの数や大きさに関係なく、メモリ不足にならずに Batch Job インスタンス内のすべてのレコードの配列を処理できます。たとえば、CSV ファイルに数百万件のレコードを書き込む必要がある場合、Batch Aggregator コンポーネントを使用してレコードをストリーミングできます。 ```xml ``` 次の例に示すように、Batch Aggregator コンポーネント内でストリーミングする場合は、レコードへの順次アクセスのみが可能です。ストリーミングでは、レコードセット全体にアクセスする必要があるため、ランダムアクセスはサポートされません。Mule では、固定サイズが指定されていない場合、すべてのレコードがメモリ内に収まることが保証されないため、この制限は必須です。 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` Batch Aggregator コンポーネント内の処理や、Batch Step コンポーネント内の処理との集約の違いについての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-processing-concept#phase_process)​を参照してください。 NOTE Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java Map を使用してシリアル化の問題を回避します。 ## [](#集約されたレコードの-mime-タイプの保持)集約されたレコードの MIME タイプの保持 _Mule 4.3 での導入_ 集約されたレコードは、各レコードのペイロードが含まれる配列コンポーネントとして Batch Aggregator コンポーネントに渡されます。ただし、デフォルトではそれらのペイロードに関連付けられている MIME タイプは保持されません。レコードの MIME タイプを保持するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を指定します。 次の JSON 配列を考えてみます。 ```json [ { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" }, { "name": "Steve Rodgers", "alias": "Captain America", "status": "RETIRED" }, { "name": "Peter Parker", "alias": "SpiderMan", "status": "FUGITIVE" } ] ``` [JSON 配列](#json_array)​が次の Batch Job コンポーネントの入力だとします。 ```xml ``` バッチエンジンは入力 JSON 配列を個々のレコードに分割します。つまり、アグリゲーターブロックで 3 つの要素が含まれる配列を受信します。1 つ目は次のようになります。 ```json { "name": "Tony Stark", "alias": "Iron Man", "status": "DEAD" } ``` ただし、Logger コンポーネントで ​`#[payload.alias]`​ 式を評価しようとすると、次の結果のようなエラーが発生します。 ```text ******************************************************************************** Message : "You called the function 'Value Selector' with these arguments: 1: Binary ("ewogICJmaXJzdE5hbWUiOiAiUmFtIiwKICAibGFzdE5hbWUiOiAiUmFtMSIsCiAgImFkZHJlc3Mi...) 2: Name ("alias") But it expects one of these combinations: (Array, Name) (Array, String) (Date, Name) (DateTime, Name) (LocalDateTime, Name) (LocalTime, Name) (Object, Name) (Object, String) (Period, Name) (Time, Name) 5| name: payload.alias, ^^^^^^^^^^^^^ ``` このエラーは、MIME タイプが保持されないことが原因で発生します。これにより、Mule で JSON として読み取らなくなります。この問題を解決するには、Batch Aggregator コンポーネントの ​`preserveMimeTypes`​ 属性を ​`true`​ に設定します。次に例を示します。 ```xml ``` この設定により、Mule で各レコードのメディア種別が保持され、ペイロードが JSON ドキュメントとして処理されます。 ## [](#レコードブロックサイズの変更)レコードブロックサイズの変更 従来のオンライン処理モデルでは、各要求は通常、ワーカースレッドにマップされます。処理種別に関係なく、通常、要求と実行中のスレッドの間には 1 対 1 のリレーションがあります。このリレーションは、同期、非同期、一方向、要求-応答の処理種別や、処理前に要求が一時的にバッファされる場合に保持されます。 ただし、Batch Job の場合、Process (処理) フェーズが始まる前にレコードが最初に永続的なキューに保存されるため、従来のスレッドモデルは適用されません。 パフォーマンスを向上させるため、Mule Runtime はバッチレコードをスレッドごとに最大 100 件のレコードのブロックでキューに追加し、スケジュールします。この動作により I/O 要求数が削減され、操作の負荷が改善されます。Batch Job は Mule のスレッドプールを使用するため、ジョブのデフォルトはありません。各スレッドはそのブロックを反復処理して各レコードを処理し、その後各ブロックはキューに戻され、プロセスが続行されます。 3 ステップの Batch Job では、キューに 100 万件のレコードを追加することを検討してください。Mule Runtime Engine がジョブのフェーズ間を移動するときに各レコードの取得と要求を行うと、少なくとも 300 万回の I/O 操作が発生します。 パフォーマンスには、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 Batch Job の 1 スレッドあたり最大 100 件のレコードの標準モデルは、ほとんどのユースケースで機能しますが、ブロックサイズの増減が必要な次の 3 つのユースケースを考慮してください。 - Batch Job で処理するレコードが 200 件あるとします。デフォルトの 100 件のレコードのブロックサイズでは、Mule が同時に並行処理できるレコード数は 2 件のみです。Batch Job で処理するレコードが 101 件未満の場合、順次処理になります。負荷の高いペイロードを処理する必要がある場合、100 件のレコードをキューに追加するには大量の作業メモリが必要です。 - 画像を処理する必要がある Batch Job があり、平均画像サイズは 3 MB だとします。この場合、Mule は、各スレッドで 3 MB のペイロードを持つ 100 件のレコードのブロックを処理します。したがって、デフォルトの threading-profile 設定では、ブロックをキューで保持するためだけに大量の作業メモリが必要になります。この場合、より低いブロックサイズを設定して、より多くのジョブを介して各ペイロードを分散し、使用可能メモリの負荷を減らします。 - 500 万件のレコードがあり、ペイロードが非常に小さいためにメモリ内に 500 件のレコードのブロックを問題なく入れることができるとします。より大きなブロックサイズを設定すると、作業メモリの負荷を犠牲にすることなく Batch Job の時間を短縮できます。 この機能を最大限に活用するには、ブロックサイズが Batch Job に与える影響を理解する必要があります。異なる値とテストパフォーマンスを使用して比較テストを実行すると、この変更を本番に移行する前に最適なブロックサイズを見つけるために役立ちます。 バッチブロックサイズの変更は省略可能です。変更を適用しない場合、デフォルト値はブロックあたり 100 件のレコードです。 Batch Job コンポーネントを使用してサイズを設定します。次に例を示します。 ```xml ... ``` ## [](#batch-job-インスタンスの最大同時実行の制限の設定)Batch Job インスタンスの最大同時実行の制限の設定 Max Concurrency (最大同時実行) (​`maxConcurrency`​) プロパティでは、同時に処理するレコードブロックの数が制限されます。 `maxConcurrency`​ プロパティを次の例のように設定できます。 ```xml ... ``` デフォルトでは、Batch Job コンポーネントの最大同時実行は使用可能なコアの数の 2 倍に制限されます。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-processing-concept) - [Batch Job インスタンス ID](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-job-instance-id) - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-backpressure-maxconcurrency) # Bitronix を使用したトランザクションの管理 Bitronix トランザクションマネージャーにより、中断されていたトランザクションを Mule の再起動時に自動的に復元できます。 Mule インスタンスがクラッシュするか、リソースマネージャー (JMS ブローカーやデータベースなど) との接続が失われると、2 フェーズコミットプロトコル (2PC) の準備フェーズとコミットフェーズの間にあるトランザクションは失敗します。この場合、トランザクションマネージャーは、復元プロセスを実行して、障害の発生時に実行途中だったトランザクションを完了させる必要があります。このような障害はあまり発生しませんが、発生した場合のデータの一貫性を維持するためのメカニズムが必要です。 ## [](#単一アプリケーションでの-bitronix-の使用)単一アプリケーションでの Bitronix の使用 Bitronix を使用するようにアプリケーションを設定するには、次のようにフローの外部でトランザクションマネージャーを宣言します。 ```xml ... ``` ## [](#mule-ドメインのすべてのアプリケーションでの-bitronix-の使用)Mule ドメインのすべてのアプリケーションでの Bitronix の使用 Mule ドメインに関連付けられているすべてのドメインで Bitronix を使用するには、次のようにドメイン設定ファイルで Bitronix をトランザクションマネージャーとして定義します。このように設定すると、ドメインに関連付けられているすべてのアプリケーションが Bitronix を使用するため、個別のアプリケーションでトランザクションマネージャーを宣言する必要はありません。 ```xml ``` ドメインの詳細については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.3/shared-resources)​を参照してください。 ## [](#anypoint-studio-からの-bitronix-の追加)Anypoint Studio からの Bitronix の追加 Studio からアプリケーションやドメインに Bitronix を追加する手順は次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブに移動します。 2. **\[Create (作成)\]**​ ボタンをクリックします。 3. `Bitronix Transaction Manager`​ を検索します。 ![bitronix-studio](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/bitronix-studio.png) ## [](#bitronix-トランザクションマネージャーの設定)Bitronix トランザクションマネージャーの設定 Bitronix のデフォルト設定値は、ほとんどのユースケースに適していますが、システムプロパティまたは ​`$MULE_HOME/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルを使用してトランザクションマネージャーをカスタマイズすることもできます。 Bitronix の設定属性を下表に示します。
設定属性 説明 デフォルト値

mule.bitronix.transactiontimeout

XA トランザクションのタイムアウト (秒)。

60

mule.bitronix.recoveryinterval

XA トランザクションの復元実行間隔 (秒)。

60

mule.bitronix.serverId

XA トランザクションログに登録するためのトランザクションマネージャーの一意の ID。この値は、Mule インスタンスごとに一意である必要があります。

ホスト IP と、HA で動作している場合はクラスターノード ID との組み合わせ。
### [](#データベースのプーリングデータソースの設定)データベースのプーリングデータソースの設定 Bitronix とのインテグレーションにより、Database Connector でリソースプーリングを実装するときには必ず使用する Database Connector 用のデータソース接続プールが提供されます。 すべての接続用の共有プーリングデータソースを設定できます。これにより、アプリケーションによってこれらのデータソースが集中して使用されていない場合の接続使用状況が改善されます。 ```xml ``` プーリングデータソースの設定属性を下表に示します。
属性 説明 必須 デフォルト値

name

コネクタが参照できるようにプールを識別します。

はい

datasource-ref

JDBC データソースオブジェクトへの参照。​XADataSource​ オブジェクトを用意する必要があります。

はい

minPoolSize

プールに格納する最小の接続数を定義します。

いいえ

4

maxPoolSize

プールに格納できる最大の接続数を定義します。

いいえ

16

maxIdleTime

プール内のアイドル接続を閉じるまでの秒数。

いいえ

60

acquireIncrement

プールが枯渇したときに一度に取得を試みる接続数を決定します。

いいえ

1

acquireTimeoutSeconds

プールが枯渇したときに ​getConnection()​ を呼び出しているクライアントが接続のチェックインまたは取得を待つ秒数。0 を指定すると無限に待ちます。

いいえ

30

preparedStatementCacheSize

プールされた接続ごとにキャッシュされるステートメント数を決定します。0 を指定するとキャッシュは無効になります。

いいえ

5
## [](#トランザクションの復元)トランザクションの復元 Mule には自動的に実行される復元手順があり、設定は不要です。システムクラッシュ後に Mule が再起動すると、XA トランザクションに関与していたすべてのリソースに接続してトランザクション復元プロセスを開始し、すべてのシステムを一貫した状態に保ちます。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.3/shared-resources) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management) - [XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.3/xa-transactions) # Bitronix を使用したトランザクションの管理 Bitronix トランザクションマネージャーにより、中断されていたトランザクションを Mule の再起動時に自動的に復元できます。 Mule インスタンスがクラッシュするか、リソースマネージャー (JMS ブローカーやデータベースなど) との接続が失われると、2 フェーズコミットプロトコル (2PC) の準備フェーズとコミットフェーズの間にあるトランザクションは失敗します。この場合、トランザクションマネージャーは、復元プロセスを実行して、障害の発生時に実行途中だったトランザクションを完了させる必要があります。このような障害はあまり発生しませんが、発生した場合のデータの一貫性を維持するためのメカニズムが必要です。 ## [](#単一アプリケーションでの-bitronix-の使用)単一アプリケーションでの Bitronix の使用 Bitronix を使用するようにアプリケーションを設定するには、次のようにフローの外部でトランザクションマネージャーを宣言します。 ```xml ... ``` ## [](#mule-ドメインのすべてのアプリケーションでの-bitronix-の使用)Mule ドメインのすべてのアプリケーションでの Bitronix の使用 Mule ドメインに関連付けられているすべてのドメインで Bitronix を使用するには、次のようにドメイン設定ファイルで Bitronix をトランザクションマネージャーとして定義します。このように設定すると、ドメインに関連付けられているすべてのアプリケーションが Bitronix を使用するため、個別のアプリケーションでトランザクションマネージャーを宣言する必要はありません。 ```xml ``` ドメインの詳細については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.4/shared-resources)​を参照してください。 ## [](#anypoint-studio-からの-bitronix-の追加)Anypoint Studio からの Bitronix の追加 Studio からアプリケーションやドメインに Bitronix を追加する手順は次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブに移動します。 2. **\[Create (作成)\]**​ ボタンをクリックします。 3. `Bitronix Transaction Manager`​ を検索します。 ![bitronix-studio](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/bitronix-studio.png) ## [](#bitronix-トランザクションマネージャーの設定)Bitronix トランザクションマネージャーの設定 Bitronix のデフォルト設定値は、ほとんどのユースケースに適しています。ただし、システムプロパティまたは ​`$MULE_HOME/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルを使用してトランザクションマネージャーをカスタマイズすることもできます。 Bitronix の設定属性を下表に示します。
設定属性 説明 デフォルト値

mule.bitronix.transactiontimeout

XA トランザクションのタイムアウト (秒)。

60

mule.bitronix.recoveryinterval

XA トランザクションの復元実行間隔 (秒)。

60

mule.bitronix.serverId

XA トランザクションログに登録するためのトランザクションマネージャーの一意の ID。この値は、Mule インスタンスごとに一意である必要があります。

ホスト IP と、HA で動作している場合はクラスターノード ID との組み合わせ。
### [](#データベースのプーリングデータソースの設定)データベースのプーリングデータソースの設定 Bitronix とのインテグレーションにより、Database Connector でリソースプーリングを実装するときには必ず使用する Database Connector 用のデータソース接続プールが提供されます。 すべての接続用の共有プーリングデータソースを設定できます。これにより、アプリケーションによってこれらのデータソースが集中して使用されていない場合の接続使用状況が改善されます。 ```xml ``` プーリングデータソースの設定属性を下表に示します。
属性 説明 必須 デフォルト値

name

コネクタが参照できるようにプールを識別します。

はい

datasource-ref

JDBC データソースオブジェクトへの参照。​XADataSource​ オブジェクトを用意する必要があります。

はい

minPoolSize

プールに格納する最小の接続数を定義します。

いいえ

4

maxPoolSize

プールに格納できる最大の接続数を定義します。

いいえ

16

maxIdleTime

プール内のアイドル接続を閉じるまでの秒数。

いいえ

60

acquireIncrement

プールが枯渇したときに一度に取得を試みる接続数を決定します。

いいえ

1

acquireTimeoutSeconds

プールが枯渇したときに ​getConnection()​ を呼び出しているクライアントが接続のチェックインまたは取得を待つ秒数。0 を指定すると無限に待ちます。

いいえ

30

preparedStatementCacheSize

プールされた接続ごとにキャッシュされるステートメント数を決定します。0 を指定するとキャッシュは無効になります。

いいえ

5
## [](#トランザクションの復元)トランザクションの復元 Mule には自動的に実行される復元手順があり、設定は不要です。システムクラッシュ後に Mule が再起動すると、XA トランザクションに関与していたすべてのリソースに接続してトランザクション復元プロセスを開始し、すべてのシステムを一貫した状態に保ちます。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.4/shared-resources) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management) - [XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.4/xa-transactions) # Bitronix を使用したトランザクションの管理 Bitronix トランザクションマネージャーにより、中断されていたトランザクションを Mule の再起動時に自動的に復元できます。 Mule インスタンスがクラッシュするか、リソースマネージャー (JMS ブローカーやデータベースなど) との接続が失われると、2 フェーズコミットプロトコル (2PC) の準備フェーズとコミットフェーズの間にあるトランザクションは失敗します。この場合、トランザクションマネージャーは、復元プロセスを実行して、障害の発生時に実行途中だったトランザクションを完了させる必要があります。このような障害はあまり発生しませんが、発生した場合のデータの一貫性を維持するためのメカニズムが必要です。 ## [](#単一アプリケーションでの-bitronix-の使用)単一アプリケーションでの Bitronix の使用 Bitronix を使用するようにアプリケーションを設定するには、次のようにフローの外部でトランザクションマネージャーを宣言します。 ```xml ... ``` ## [](#mule-ドメインのすべてのアプリケーションでの-bitronix-の使用)Mule ドメインのすべてのアプリケーションでの Bitronix の使用 Mule ドメインに関連付けられているすべてのドメインで Bitronix を使用するには、次のようにドメイン設定ファイルで Bitronix をトランザクションマネージャーとして定義します。このように設定すると、ドメインに関連付けられているすべてのアプリケーションが Bitronix を使用するため、個別のアプリケーションでトランザクションマネージャーを宣言する必要はありません。 ```xml ``` ドメインの詳細については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.5/shared-resources)​を参照してください。 ## [](#anypoint-studio-からの-bitronix-の追加)Anypoint Studio からの Bitronix の追加 Studio からアプリケーションやドメインに Bitronix を追加する手順は次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブに移動します。 2. **\[Create (作成)\]**​ ボタンをクリックします。 3. `Bitronix Transaction Manager`​ を検索します。 ![bitronix-studio](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/bitronix-studio.png) ## [](#bitronix-トランザクションマネージャーの設定)Bitronix トランザクションマネージャーの設定 Bitronix のデフォルト設定値は、ほとんどのユースケースに適しています。ただし、システムプロパティまたは ​`$MULE_HOME/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルを使用してトランザクションマネージャーをカスタマイズすることもできます。 Bitronix の設定属性を下表に示します。
設定属性 説明 デフォルト値

mule.bitronix.transactiontimeout

XA トランザクションのタイムアウト (秒)。

60

mule.bitronix.recoveryinterval

XA トランザクションの復元実行間隔 (秒)。

60

mule.bitronix.serverId

XA トランザクションログに登録するためのトランザクションマネージャーの一意の ID。この値は、Mule インスタンスごとに一意である必要があります。

ホスト IP と、HA で動作している場合はクラスターノード ID との組み合わせ。
### [](#データベースのプーリングデータソースの設定)データベースのプーリングデータソースの設定 Bitronix とのインテグレーションにより、Database Connector でリソースプーリングを実装するときには必ず使用する Database Connector 用のデータソース接続プールが提供されます。 すべての接続用の共有プーリングデータソースを設定できます。これにより、アプリケーションによってこれらのデータソースが集中して使用されていない場合の接続使用状況が改善されます。 ```xml ``` プーリングデータソースの設定属性を下表に示します。
属性 説明 必須 デフォルト値

name

コネクタが参照できるようにプールを識別します。

はい

datasource-ref

JDBC データソースオブジェクトへの参照。​XADataSource​ オブジェクトを用意する必要があります。

はい

minPoolSize

プールに格納する最小の接続数を定義します。

いいえ

4

maxPoolSize

プールに格納できる最大の接続数を定義します。

いいえ

16

maxIdleTime

プール内のアイドル接続を閉じるまでの秒数。

いいえ

60

acquireIncrement

プールが枯渇したときに一度に取得を試みる接続数を決定します。

いいえ

1

acquireTimeoutSeconds

プールが枯渇したときに ​getConnection()​ を呼び出しているクライアントが接続のチェックインまたは取得を待つ秒数。0 を指定すると無限に待ちます。

いいえ

30

preparedStatementCacheSize

プールされた接続ごとにキャッシュされるステートメント数を決定します。0 を指定するとキャッシュは無効になります。

いいえ

5
## [](#トランザクションの復元)トランザクションの復元 Mule には自動的に実行される復元手順があり、設定は不要です。システムクラッシュ後に Mule が再起動すると、XA トランザクションに関与していたすべてのリソースに接続してトランザクション復元プロセスを開始し、すべてのシステムを一貫した状態に保ちます。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.5/shared-resources) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management) - [XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.5/xa-transactions) # Bitronix を使用したトランザクションの管理 Bitronix トランザクションマネージャーにより、中断されていたトランザクションを Mule の再起動時に自動的に復元できます。 Mule インスタンスがクラッシュするか、リソースマネージャー (JMS ブローカーやデータベースなど) との接続が失われると、2 フェーズコミットプロトコル (2PC) の準備フェーズとコミットフェーズの間にあるトランザクションは失敗します。この場合、トランザクションマネージャーは、復元プロセスを実行して、障害の発生時に実行途中だったトランザクションを完了させる必要があります。このような障害はあまり発生しませんが、発生した場合のデータの一貫性を維持するためのメカニズムが必要です。 ## [](#単一アプリケーションでの-bitronix-の使用)単一アプリケーションでの Bitronix の使用 Bitronix を使用するようにアプリケーションを設定するには、次のようにフローの外部でトランザクションマネージャーを宣言します。 ```xml ... ``` ## [](#mule-ドメインのすべてのアプリケーションでの-bitronix-の使用)Mule ドメインのすべてのアプリケーションでの Bitronix の使用 Mule ドメインに関連付けられているすべてのドメインで Bitronix を使用するには、次のようにドメイン設定ファイルで Bitronix をトランザクションマネージャーとして定義します。このように設定すると、ドメインに関連付けられているすべてのアプリケーションが Bitronix を使用するため、個別のアプリケーションでトランザクションマネージャーを宣言する必要はありません。 ```xml ``` ドメインの詳細については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.6/shared-resources)​を参照してください。 ## [](#anypoint-studio-からの-bitronix-の追加)Anypoint Studio からの Bitronix の追加 Studio からアプリケーションやドメインに Bitronix を追加する手順は次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブに移動します。 2. **\[Create (作成)\]**​ ボタンをクリックします。 3. `Bitronix Transaction Manager`​ を検索します。 ![bitronix-studio](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/bitronix-studio.png) ## [](#bitronix-トランザクションマネージャーの設定)Bitronix トランザクションマネージャーの設定 Bitronix のデフォルト設定値は、ほとんどのユースケースに適していますが、システムプロパティまたは ​`$MULE_HOME/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルを使用してトランザクションマネージャーをカスタマイズすることもできます。 Bitronix の設定属性を下表に示します。
設定属性 説明 デフォルト値

mule.bitronix.transactiontimeout

XA トランザクションのタイムアウト (秒)。

60

mule.bitronix.recoveryinterval

XA トランザクションの復元実行間隔 (秒)。

60

mule.bitronix.serverId

XA トランザクションログに登録するためのトランザクションマネージャーの一意の ID。この値は、Mule インスタンスごとに一意である必要があります。

ホスト IP と、HA で動作している場合はクラスターノード ID との組み合わせ。
### [](#データベースのプーリングデータソースの設定)データベースのプーリングデータソースの設定 Bitronix とのインテグレーションにより、Database Connector でリソースプーリングを実装するときには必ず使用する Database Connector 用のデータソース接続プールが提供されます。 すべての接続用の共有プーリングデータソースを設定できます。これにより、アプリケーションによってこれらのデータソースが集中して使用されていない場合の接続使用状況が改善されます。 ```xml ``` プーリングデータソースの設定属性を下表に示します。
属性 説明 必須 デフォルト値

name

コネクタが参照できるようにプールを識別します。

はい

datasource-ref

JDBC データソースオブジェクトへの参照。​XADataSource​ オブジェクトを用意する必要があります。

はい

minPoolSize

プールに格納する最小の接続数を定義します。

いいえ

4

maxPoolSize

プールに格納できる最大の接続数を定義します。

いいえ

16

maxIdleTime

プール内のアイドル接続を閉じるまでの秒数。

いいえ

60

acquireIncrement

プールが枯渇したときに一度に取得を試みる接続数を決定します。

いいえ

1

acquireTimeoutSeconds

プールが枯渇したときに ​getConnection()​ を呼び出しているクライアントが接続のチェックインまたは取得を待つ秒数。0 を指定すると無限に待ちます。

いいえ

30

preparedStatementCacheSize

プールされた接続ごとにキャッシュされるステートメント数を決定します。0 を指定するとキャッシュは無効になります。

いいえ

5
## [](#トランザクションの復元)トランザクションの復元 Mule には自動的に実行される復元手順があり、設定は不要です。システムクラッシュ後に Mule が再起動すると、XA トランザクションに関与していたすべてのリソースに接続してトランザクション復元プロセスを開始し、すべてのシステムを一貫した状態に保ちます。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.6/shared-resources) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management) - [XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.6/xa-transactions) # Bitronix を使用したトランザクションの管理 Bitronix トランザクションマネージャーにより、中断されていたトランザクションを Mule の再起動時に自動的に復元できます。 Mule インスタンスがクラッシュするか、リソースマネージャー (JMS ブローカーやデータベースなど) との接続が失われると、2 フェーズコミットプロトコル (2PC) の準備フェーズとコミットフェーズの間にあるトランザクションは失敗します。この場合、トランザクションマネージャーは、復元プロセスを実行して、障害の発生時に実行途中だったトランザクションを完了させる必要があります。このような障害はあまり発生しませんが、発生した場合のデータの一貫性を維持するためのメカニズムが必要です。 ## [](#単一アプリケーションでの-bitronix-の使用)単一アプリケーションでの Bitronix の使用 Bitronix を使用するようにアプリケーションを設定するには、次のようにフローの外部でトランザクションマネージャーを宣言します。 ```xml ... ``` ## [](#mule-ドメインのすべてのアプリケーションでの-bitronix-の使用)Mule ドメインのすべてのアプリケーションでの Bitronix の使用 Mule ドメインに関連付けられているすべてのドメインで Bitronix を使用するには、次のようにドメイン設定ファイルで Bitronix をトランザクションマネージャーとして定義します。このように設定すると、ドメインに関連付けられているすべてのアプリケーションが Bitronix を使用するため、個別のアプリケーションでトランザクションマネージャーを宣言する必要はありません。 ```xml ``` ドメインの詳細については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.7/shared-resources)​を参照してください。 ## [](#anypoint-studio-からの-bitronix-の追加)Anypoint Studio からの Bitronix の追加 Studio からアプリケーションやドメインに Bitronix を追加する手順は次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブに移動します。 2. **\[Create (作成)\]**​ ボタンをクリックします。 3. `Bitronix Transaction Manager`​ を検索します。 ![Anypoint Studio の \[Bitronix Transaction Manager (Bitronix トランザクションマネージャー)\] が含まれるオプションでグローバル要素種別を選択する設定タブ](_images/bitronix-studio.png) ## [](#bitronix-トランザクションマネージャーの設定)Bitronix トランザクションマネージャーの設定 Bitronix のデフォルト設定値は、ほとんどのユースケースに適していますが、システムプロパティまたは ​`$MULE_HOME/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルを使用してトランザクションマネージャーをカスタマイズすることもできます。 Bitronix の設定属性を下表に示します。
設定属性 説明 デフォルト値

mule.bitronix.transactiontimeout

XA トランザクションのタイムアウト (秒)。

60

mule.bitronix.recoveryinterval

XA トランザクションの復元実行間隔 (秒)。

60

mule.bitronix.serverId

XA トランザクションログに登録するためのトランザクションマネージャーの一意の ID。この値は、Mule インスタンスごとに一意である必要があります。

ホスト IP と、HA で動作している場合はクラスターノード ID との組み合わせ。
### [](#データベースのプーリングデータソースの設定)データベースのプーリングデータソースの設定 Bitronix とのインテグレーションにより、Database Connector でリソースプーリングを実装するときには必ず使用する Database Connector 用のデータソース接続プールが提供されます。 すべての接続用の共有プーリングデータソースを設定できます。これにより、アプリケーションによってこれらのデータソースが集中して使用されていない場合の接続使用状況が改善されます。 ```xml ``` プーリングデータソースの設定属性を下表に示します。
属性 説明 必須 デフォルト値

name

コネクタが参照できるようにプールを識別します。

はい

datasource-ref

JDBC データソースオブジェクトへの参照。​XADataSource​ オブジェクトを用意する必要があります。

はい

minPoolSize

プールに格納する最小の接続数を定義します。

いいえ

4

maxPoolSize

プールに格納できる最大の接続数を定義します。

いいえ

16

maxIdleTime

プール内のアイドル接続を閉じるまでの秒数。

いいえ

60

acquireIncrement

プールが枯渇したときに一度に取得を試みる接続数を決定します。

いいえ

1

acquireTimeoutSeconds

プールが枯渇したときに ​getConnection()​ を呼び出しているクライアントが接続のチェックインまたは取得を待つ秒数。0 を指定すると無限に待ちます。

いいえ

30

preparedStatementCacheSize

プールされた接続ごとにキャッシュされるステートメント数を決定します。0 を指定するとキャッシュは無効になります。

いいえ

5
## [](#トランザクションの復元)トランザクションの復元 Mule には自動的に実行される復元手順があり、設定は不要です。システムクラッシュ後に Mule が再起動すると、XA トランザクションに関与していたすべてのリソースに接続してトランザクション復元プロセスを開始し、すべてのシステムを一貫した状態に保ちます。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.7/shared-resources) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management) - [XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.7/xa-transactions) # Bitronix を使用したトランザクションの管理 Bitronix トランザクションマネージャーにより、中断されていたトランザクションを Mule の再起動時に自動的に復元できます。 Mule インスタンスがクラッシュするか、リソースマネージャー (JMS ブローカーやデータベースなど) との接続が失われると、2 フェーズコミットプロトコル (2PC) の準備フェーズとコミットフェーズの間にあるトランザクションは失敗します。この場合、トランザクションマネージャーは、復元プロセスを実行して、障害の発生時に実行途中だったトランザクションを完了させる必要があります。このような障害はあまり発生しませんが、発生した場合のデータの一貫性を維持するためのメカニズムが必要です。 ## [](#単一アプリケーションでの-bitronix-の使用)単一アプリケーションでの Bitronix の使用 Bitronix を使用するようにアプリケーションを設定するには、次のようにフローの外部でトランザクションマネージャーを宣言します。 ```xml ... ``` ## [](#mule-ドメインのすべてのアプリケーションでの-bitronix-の使用)Mule ドメインのすべてのアプリケーションでの Bitronix の使用 Mule ドメインに関連付けられているすべてのドメインで Bitronix を使用するには、次のようにドメイン設定ファイルで Bitronix をトランザクションマネージャーとして定義します。このように設定すると、ドメインに関連付けられているすべてのアプリケーションが Bitronix を使用するため、個別のアプリケーションでトランザクションマネージャーを宣言する必要はありません。 ```xml ``` ドメインの詳細については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.8/shared-resources)​を参照してください。 ## [](#anypoint-studio-からの-bitronix-の追加)Anypoint Studio からの Bitronix の追加 Studio からアプリケーションやドメインに Bitronix を追加する手順は次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブに移動します。 2. **\[Create (作成)\]**​ ボタンをクリックします。 3. `Bitronix Transaction Manager`​ を検索します。 ![Anypoint Studio の \[Bitronix Transaction Manager (Bitronix トランザクションマネージャー)\] が含まれるオプションでグローバル要素種別を選択する設定タブ](_images/bitronix-studio.png) ## [](#bitronix-トランザクションマネージャーの設定)Bitronix トランザクションマネージャーの設定 Bitronix のデフォルト設定値は、ほとんどのユースケースに適していますが、システムプロパティまたは ​`$MULE_HOME/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルを使用してトランザクションマネージャーをカスタマイズすることもできます。 Bitronix の設定属性を下表に示します。
設定属性 説明 デフォルト値

mule.bitronix.transactiontimeout

XA トランザクションのタイムアウト (秒)。

60

mule.bitronix.recoveryinterval

XA トランザクションの復元実行間隔 (秒)。

60

mule.bitronix.serverId

XA トランザクションログに登録するためのトランザクションマネージャーの一意の ID。この値は、Mule インスタンスごとに一意である必要があります。

ホスト IP と、HA で動作している場合はクラスターノード ID との組み合わせ。
### [](#データベースのプーリングデータソースの設定)データベースのプーリングデータソースの設定 Bitronix とのインテグレーションにより、Database Connector でリソースプーリングを実装するときには必ず使用する Database Connector 用のデータソース接続プールが提供されます。 すべての接続用の共有プーリングデータソースを設定できます。これにより、アプリケーションによってこれらのデータソースが集中して使用されていない場合の接続使用状況が改善されます。 ```xml ``` プーリングデータソースの設定属性を下表に示します。
属性 説明 必須 デフォルト値

name

コネクタが参照できるようにプールを識別します。

はい

datasource-ref

JDBC データソースオブジェクトへの参照。​XADataSource​ オブジェクトを用意する必要があります。

はい

minPoolSize

プールに格納する最小の接続数を定義します。

いいえ

4

maxPoolSize

プールに格納できる最大の接続数を定義します。

いいえ

16

maxIdleTime

プール内のアイドル接続を閉じるまでの秒数。

いいえ

60

acquireIncrement

プールが枯渇したときに一度に取得を試みる接続数を決定します。

いいえ

1

acquireTimeoutSeconds

プールが枯渇したときに ​getConnection()​ を呼び出しているクライアントが接続のチェックインまたは取得を待つ秒数。0 を指定すると無限に待ちます。

いいえ

30

preparedStatementCacheSize

プールされた接続ごとにキャッシュされるステートメント数を決定します。0 を指定するとキャッシュは無効になります。

いいえ

5
## [](#トランザクションの復元)トランザクションの復元 Mule には自動的に実行される復元手順があり、設定は不要です。システムクラッシュ後に Mule が再起動すると、XA トランザクションに関与していたすべてのリソースに接続してトランザクション復元プロセスを開始し、すべてのシステムを一貫した状態に保ちます。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.8/shared-resources) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management) - [XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.8/xa-transactions) # Bitronix を使用したトランザクションの管理 Bitronix トランザクションマネージャーにより、中断されていたトランザクションを Mule の再起動時に自動的に復元できます。 Mule インスタンスがクラッシュするか、リソースマネージャー (JMS ブローカーやデータベースなど) との接続が失われると、2 フェーズコミットプロトコル (2PC) の準備フェーズとコミットフェーズの間にあるトランザクションは失敗します。この場合、トランザクションマネージャーは、復元プロセスを実行して、障害の発生時に実行途中だったトランザクションを完了させる必要があります。このような障害はあまり発生しませんが、発生した場合のデータの一貫性を維持するためのメカニズムが必要です。 ## [](#単一アプリケーションでの-bitronix-の使用)単一アプリケーションでの Bitronix の使用 Bitronix を使用するようにアプリケーションを設定するには、次のようにフローの外部でトランザクションマネージャーを宣言します。 ```xml ... ``` ## [](#mule-ドメインのすべてのアプリケーションでの-bitronix-の使用)Mule ドメインのすべてのアプリケーションでの Bitronix の使用 Mule ドメインに関連付けられているすべてのドメインで Bitronix を使用するには、次のようにドメイン設定ファイルで Bitronix をトランザクションマネージャーとして定義します。このように設定すると、ドメインに関連付けられているすべてのアプリケーションが Bitronix を使用するため、個別のアプリケーションでトランザクションマネージャーを宣言する必要はありません。 ```xml ``` ドメインの詳細については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.9/shared-resources)​を参照してください。 ## [](#anypoint-studio-からの-bitronix-の追加)Anypoint Studio からの Bitronix の追加 Studio からアプリケーションやドメインに Bitronix を追加する手順は次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブに移動します。 2. **\[Create (作成)\]**​ ボタンをクリックします。 3. `Bitronix Transaction Manager`​ を検索します。 ![Anypoint Studio の \[Bitronix Transaction Manager (Bitronix トランザクションマネージャー)\] が含まれるオプションでグローバル要素種別を選択する設定タブ](_images/bitronix-studio.png) ## [](#bitronix-トランザクションマネージャーの設定)Bitronix トランザクションマネージャーの設定 Bitronix のデフォルト設定値は、ほとんどのユースケースに適していますが、システムプロパティまたは ​`$MULE_HOME/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルを使用してトランザクションマネージャーをカスタマイズすることもできます。 Bitronix の設定属性を下表に示します。
設定属性 説明 デフォルト値

mule.bitronix.transactiontimeout

XA トランザクションのタイムアウト (秒)。

60

mule.bitronix.recoveryinterval

XA トランザクションの復元実行間隔 (秒)。

60

mule.bitronix.serverId

XA トランザクションログに登録するためのトランザクションマネージャーの一意の ID。この値は、Mule インスタンスごとに一意である必要があります。

ホスト IP と、HA で動作している場合はクラスターノード ID との組み合わせ。
### [](#データベースのプーリングデータソースの設定)データベースのプーリングデータソースの設定 Bitronix とのインテグレーションにより、Database Connector でリソースプーリングを実装するときには必ず使用する Database Connector 用のデータソース接続プールが提供されます。 すべての接続用の共有プーリングデータソースを設定できます。これにより、アプリケーションによってこれらのデータソースが集中して使用されていない場合の接続使用状況が改善されます。 ```xml ``` プーリングデータソースの設定属性を下表に示します。
属性 説明 必須 デフォルト値

name

コネクタが参照できるようにプールを識別します。

はい

datasource-ref

JDBC データソースオブジェクトへの参照。​XADataSource​ オブジェクトを用意する必要があります。

はい

minPoolSize

プールに格納する最小の接続数を定義します。

いいえ

4

maxPoolSize

プールに格納できる最大の接続数を定義します。

いいえ

16

maxIdleTime

プール内のアイドル接続を閉じるまでの秒数。

いいえ

60

acquireIncrement

プールが枯渇したときに一度に取得を試みる接続数を決定します。

いいえ

1

acquireTimeoutSeconds

プールが枯渇したときに ​getConnection()​ を呼び出しているクライアントが接続のチェックインまたは取得を待つ秒数。0 を指定すると無限に待ちます。

いいえ

30

preparedStatementCacheSize

プールされた接続ごとにキャッシュされるステートメント数を決定します。0 を指定するとキャッシュは無効になります。

いいえ

5
## [](#トランザクションの復元)トランザクションの復元 Mule には自動的に実行される復元手順があり、設定は不要です。システムクラッシュ後に Mule が再起動すると、XA トランザクションに関与していたすべてのリソースに接続してトランザクション復元プロセスを開始し、すべてのシステムを一貫した状態に保ちます。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.9/shared-resources) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management) - [XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.9/xa-transactions) # Cache スコープ Cache スコープは、頻繁にコールされるデータを保存および再利用するために使用されます。Cache スコープを使用して、Mule インスタンスの処理負荷を減らし、フロー内のメッセージ処理速度を上げることができます。次のタスクでは、特に効果的です。 - 同じ情報を繰り返し求める要求の処理。 - 大容量の反復可能なストリームに関連する情報を求める要求の処理。 Mule アプリケーションのメッセージプロセッサーが Cache スコープにメッセージを送信すると、親フローは出力を要求します。Cache スコープは、メッセージペイロードを処理して、出力を親フローに配信し、出力を保存 (応答をキャッシュ) します。Cache スコープは、次に同じ種類のメッセージペイロードを受信したときに、時間がかかる可能性のあるプロセスを再度呼び出す代わりにキャッシュされた応答を提供できます。 たとえば、Cache スコープを使用して、フライト情報を求める顧客の要求を管理できます。多くの顧客がサンフランシスコからブエノスアイレスへのフライトに関する同じ価格設定情報を要求する場合があります。多くの処理能力を使用して顧客のクエリごとに個別の要求を複数の航空データベースに送信する代わりに、Cache スコープを使用してデータベースへの要求の送信回数が少なくなるように調整し (10 分に 1 回など)、キャッシュされたフライト価格設定情報をユーザーに提供できます。データの適時性が重要でない場合、Cache スコープで時間と処理能力を節約できます。 任意の数のメッセージプロセッサー (コネクタやコンポーネントなど) を Cache スコープに配置し、スコープ内で発生した処理で生成される応答 (応答メッセージのペイロードが含まれる) を保存するようにキャッシュ戦略を設定できます。 キャッシュ戦略で設定されているオブジェクトストアはクラスター内のすべてのノードで共有されるため、Cache スコープはクラスター化された環境でも機能します。 ## [](#キャッシュプロセス)キャッシュプロセス Cache スコープは反復可能なストリームをキャッシュします。失われる前に 1 回だけ読み取ることができる反復不可能なストリームはキャッシュしません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 一般的なキャッシュプロセスシーケンスは、次のとおりです。 1. メッセージが Cache スコープに入ります。 2. Cache スコープは、メッセージペイロードが反復可能かどうかを判断します。 3. Cache スコープは、メッセージのペイロードを識別するキーを生成します。 デフォルトでは、Mule は SHA256KeyGenerator および SHA256 ダイジェストを使用して、メッセージペイロードの一意のキーを生成します。ただし、カスタムキャッシュ戦略で独自のキーをセットアップできます。 4. Cache スコープは、新しく生成されたキーと、以前に処理されてキャッシュされた応答を比較し、セットアップした ObjectStore (推奨) またはデフォルトの ​`InMemoryObjectStore`​ に保存します。 - キャッシュされた応答イベントがない場合 (​_キャッシュミス_​)、Cache スコープは新しいメッセージを処理し、応答を生成します。 また、結果の応答をオブジェクトストアに保存します (反復可能な応答の場合)。 - キャッシュされた応答イベントがある場合 (​_キャッシュヒット_​)、キャッシュ戦略は、新しい要求とキャッシュされた応答の両方のデータを結合する応答を生成します。 生成された応答が反復不可能なストリームである場合は、応答をキャッシュしません。 5. Cache スコープは、処理を続行するために応答を親フローにプッシュします。 ## [](#キャッシュ戦略)キャッシュ戦略 キャッシュ戦略は、メッセージがサブフローに入ってきたときに Cache スコープが実行するアクションを定義します。デフォルトでは、Cache スコープは、メモリ内のオブジェクトストアにデータを保存するキャッシュ戦略を使用します。既存のオブジェクトストアを参照するカスタムキャッシュ戦略を作成するか、またはこのキャッシュ戦略で使用する新しいカスタムオブジェクトストアを作成することができます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。キャッシュへのアクセスを同期するようにキャッシュ戦略を設定して、異なるメッセージプロセッサーが同時にキャッシュを使用できないようにすることもできます。 キャッシュ戦略は、次のカスタマイズも参照できます。 - ObjectStore のイベントキー (ペイロードを ObjectStore に保存するためのキーの作成に使用される DataWeave 式または Java オブジェクト)。 - 戦略の応答ジェネレーター (キャッシュ戦略から返される応答の作成に使用される Java オブジェクトへの参照)。 - 変更可能または変更不可能なデータのイベントコピー戦略。 ## [](#絞り込み)絞り込み Cache スコープは、受信するすべてのメッセージペイロードを処理する代わりに、DataWeave 式に基づいて Cache スコープフローから特定のペイロードを除外できます。 ## [](#例)例 Anypoint Studio では、Anypoint Exchange からサンプルプロジェクト ​_Cache Scope with Salesforce Contacts_​ (Cache スコープと Salesforce 取引先責任者) をダウンロードして開き、Cache スコープの使用方法について学習できます。このサンプルでは、Salesforce からフェッチされたデータをキャッシュします。クエリが発行されてデータが再度要求されると、キャッシュから結果が返され、Salesforce への新しいコールは実行されません。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.3/cache-scope-strategy) - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.3/streaming-about) # Cache スコープ Cache スコープは、頻繁にコールされるデータを保存および再利用するために使用されます。Cache スコープを使用して、Mule インスタンスの処理負荷を減らし、フロー内のメッセージ処理速度を上げることができます。次のタスクでは、特に効果的です。 - 同じ情報を繰り返し求める要求の処理。 - 大容量の反復可能なストリームに関連する情報を求める要求の処理。 Mule アプリケーションのメッセージプロセッサーが Cache スコープにメッセージを送信すると、親フローは出力を要求します。Cache スコープは、メッセージペイロードを処理して、出力を親フローに配信し、出力を保存 (応答をキャッシュ) します。Cache スコープは、次に同じ種類のメッセージペイロードを受信したときに、時間がかかる可能性のあるプロセスを再度呼び出す代わりにキャッシュされた応答を提供できます。 たとえば、Cache スコープを使用して、フライト情報を求める顧客の要求を管理できます。多くの顧客がサンフランシスコからブエノスアイレスへのフライトに関する同じ価格設定情報を要求する場合があります。多くの処理能力を使用して顧客のクエリごとに個別の要求を複数の航空データベースに送信する代わりに、Cache スコープを使用してデータベースへの要求の送信回数が少なくなるように調整し (10 分に 1 回など)、キャッシュされたフライト価格設定情報をユーザーに提供できます。データの適時性が重要でない場合、Cache スコープで時間と処理能力を節約できます。 任意の数のメッセージプロセッサー (コネクタやコンポーネントなど) を Cache スコープに配置し、スコープ内で発生した処理で生成される応答 (応答メッセージのペイロードが含まれる) を保存するようにキャッシュ戦略を設定できます。 キャッシュ戦略で設定されているオブジェクトストアはクラスター内のすべてのノードで共有されるため、Cache スコープはクラスター化された環境でも機能します。 ## [](#キャッシュプロセス)キャッシュプロセス Cache スコープは反復可能なストリームをキャッシュします。失われる前に 1 回だけ読み取ることができる反復不可能なストリームはキャッシュしません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 一般的なキャッシュプロセスシーケンスは、次のとおりです。 1. メッセージが Cache スコープに入ります。 2. Cache スコープは、メッセージペイロードが反復可能かどうかを判断します。 3. Cache スコープは、メッセージのペイロードを識別するキーを生成します。 デフォルトでは、Mule は SHA256KeyGenerator および SHA256 ダイジェストを使用して、メッセージペイロードの一意のキーを生成します。ただし、カスタムキャッシュ戦略で独自のキーをセットアップできます。 4. Cache スコープは、新しく生成されたキーと、以前に処理されてキャッシュされた応答を比較し、セットアップした ObjectStore (推奨) またはデフォルトの ​`InMemoryObjectStore`​ に保存します。 - キャッシュされた応答イベントがない場合 (​_キャッシュミス_​)、Cache スコープは新しいメッセージを処理し、応答を生成します。 また、結果の応答をオブジェクトストアに保存します (反復可能な応答の場合)。 - キャッシュされた応答イベントがある場合 (​_キャッシュヒット_​)、キャッシュ戦略は、新しい要求とキャッシュされた応答の両方のデータを結合する応答を生成します。 生成された応答が反復不可能なストリームである場合は、応答をキャッシュしません。 5. Cache スコープは、処理を続行するために応答を親フローにプッシュします。 ## [](#キャッシュ戦略)キャッシュ戦略 キャッシュ戦略は、メッセージがサブフローに入ってきたときに Cache スコープが実行するアクションを定義します。デフォルトでは、Cache スコープは、メモリ内のオブジェクトストアにデータを保存するキャッシュ戦略を使用します。既存のオブジェクトストアを参照するカスタムキャッシュ戦略を作成するか、またはこのキャッシュ戦略で使用する新しいカスタムオブジェクトストアを作成することができます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。キャッシュへのアクセスを同期するようにキャッシュ戦略を設定して、異なるメッセージプロセッサーが同時にキャッシュを使用できないようにすることもできます。 キャッシュ戦略は、次のカスタマイズも参照できます。 - ObjectStore のイベントキー (ペイロードを ObjectStore に保存するためのキーの作成に使用される DataWeave 式または Java オブジェクト)。 - 戦略の応答ジェネレーター (キャッシュ戦略から返される応答の作成に使用される Java オブジェクトへの参照)。 - 変更可能または変更不可能なデータのイベントコピー戦略。 ## [](#絞り込み)絞り込み Cache スコープは、受信するすべてのメッセージペイロードを処理する代わりに、DataWeave 式に基づいて Cache スコープフローから特定のペイロードを除外できます。 ## [](#例)例 Anypoint Studio では、Anypoint Exchange からサンプルプロジェクト ​_Cache Scope with Salesforce Contacts_​ (Cache スコープと Salesforce 取引先責任者) をダウンロードして開き、Cache スコープの使用方法について学習できます。このサンプルでは、Salesforce からフェッチされたデータをキャッシュします。クエリが発行されてデータが再度要求されると、キャッシュから結果が返され、Salesforce への新しいコールは実行されません。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.4/cache-scope-strategy) - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.4/streaming-about) # Cache スコープ Cache スコープは、頻繁にコールされるデータを保存および再利用するために使用されます。Cache スコープを使用して、Mule インスタンスの処理負荷を減らし、フロー内のメッセージ処理速度を上げることができます。次のタスクでは、特に効果的です。 - 同じ情報を繰り返し求める要求の処理。 - 大容量の反復可能なストリームに関連する情報を求める要求の処理。 Mule アプリケーションのメッセージプロセッサーが Cache スコープにメッセージを送信すると、親フローは出力を要求します。Cache スコープは、メッセージペイロードを処理して、出力を親フローに配信し、出力を保存 (応答をキャッシュ) します。Cache スコープは、次に同じ種類のメッセージペイロードを受信したときに、時間がかかる可能性のあるプロセスを再度呼び出す代わりにキャッシュされた応答を提供できます。 たとえば、Cache スコープを使用して、フライト情報を求める顧客の要求を管理できます。多くの顧客がサンフランシスコからブエノスアイレスへのフライトに関する同じ価格設定情報を要求する場合があります。多くの処理能力を使用して顧客のクエリごとに個別の要求を複数の航空データベースに送信する代わりに、Cache スコープを使用してデータベースへの要求の送信回数が少なくなるように調整し (10 分に 1 回など)、キャッシュされたフライト価格設定情報をユーザーに提供できます。データの適時性が重要でない場合、Cache スコープで時間と処理能力を節約できます。 任意の数のメッセージプロセッサー (コネクタやコンポーネントなど) を Cache スコープに配置し、スコープ内で発生した処理で生成される応答 (応答メッセージのペイロードが含まれる) を保存するようにキャッシュ戦略を設定できます。 キャッシュ戦略で設定されているオブジェクトストアはクラスター内のすべてのノードで共有されるため、Cache スコープはクラスター化された環境でも機能します。 ## [](#キャッシュプロセス)キャッシュプロセス Cache スコープは反復可能なストリームをキャッシュします。失われる前に 1 回だけ読み取ることができる反復不可能なストリームはキャッシュしません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 一般的なキャッシュプロセスシーケンスは、次のとおりです。 1. メッセージが Cache スコープに入ります。 2. Cache スコープは、メッセージペイロードが反復可能かどうかを判断します。 3. Cache スコープは、メッセージのペイロードを識別するキーを生成します。 デフォルトでは、Mule は SHA256KeyGenerator および SHA256 ダイジェストを使用して、メッセージペイロードの一意のキーを生成します。ただし、カスタムキャッシュ戦略で独自のキーをセットアップできます。 4. Cache スコープは、新しく生成されたキーと、以前に処理されてキャッシュされた応答を比較し、セットアップした ObjectStore (推奨) またはデフォルトの ​`InMemoryObjectStore`​ に保存します。 - キャッシュされた応答イベントがない場合 (​_キャッシュミス_​)、Cache スコープは新しいメッセージを処理し、応答を生成します。 また、結果の応答をオブジェクトストアに保存します (反復可能な応答の場合)。 - キャッシュされた応答イベントがある場合 (​_キャッシュヒット_​)、キャッシュ戦略は、新しい要求とキャッシュされた応答の両方のデータを結合する応答を生成します。 生成された応答が反復不可能なストリームである場合は、応答をキャッシュしません。 5. Cache スコープは、処理を続行するために応答を親フローにプッシュします。 ## [](#キャッシュ戦略)キャッシュ戦略 キャッシュ戦略は、メッセージがサブフローに入ってきたときに Cache スコープが実行するアクションを定義します。デフォルトでは、Cache スコープは、メモリ内のオブジェクトストアにデータを保存するキャッシュ戦略を使用します。既存のオブジェクトストアを参照するカスタムキャッシュ戦略を作成するか、またはこのキャッシュ戦略で使用する新しいカスタムオブジェクトストアを作成することができます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。キャッシュへのアクセスを同期するようにキャッシュ戦略を設定して、異なるメッセージプロセッサーが同時にキャッシュを使用できないようにすることもできます。 キャッシュ戦略は、次のカスタマイズも参照できます。 - ObjectStore のイベントキー (ペイロードを ObjectStore に保存するためのキーの作成に使用される DataWeave 式または Java オブジェクト)。 - 戦略の応答ジェネレーター (キャッシュ戦略から返される応答の作成に使用される Java オブジェクトへの参照)。 - 変更可能または変更不可能なデータのイベントコピー戦略。 ## [](#絞り込み)絞り込み Cache スコープは、受信するすべてのメッセージペイロードを処理する代わりに、DataWeave 式に基づいて Cache スコープフローから特定のペイロードを除外できます。 ## [](#例)例 Anypoint Studio では、Anypoint Exchange からサンプルプロジェクト ​_Cache Scope with Salesforce Contacts_​ (Cache スコープと Salesforce 取引先責任者) をダウンロードして開き、Cache スコープの使用方法について学習できます。このサンプルでは、Salesforce からフェッチされたデータをキャッシュします。クエリが発行されてデータが再度要求されると、キャッシュから結果が返され、Salesforce への新しいコールは実行されません。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.5/cache-scope-strategy) - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.5/streaming-about) # Cache スコープ Cache スコープは、頻繁にコールされるデータを保存および再利用するために使用されます。Cache スコープを使用して、Mule インスタンスの処理負荷を減らし、フロー内のメッセージ処理速度を上げることができます。次のタスクでは、特に効果的です。 - 同じ情報を繰り返し求める要求の処理。 - 大容量の反復可能なストリームに関連する情報を求める要求の処理。 Mule アプリケーションのメッセージプロセッサーが Cache スコープにメッセージを送信すると、親フローは出力を要求します。Cache スコープは、メッセージペイロードを処理して、出力を親フローに配信し、出力を保存 (応答をキャッシュ) します。Cache スコープは、次に同じ種類のメッセージペイロードを受信したときに、時間がかかる可能性のあるプロセスを再度呼び出す代わりにキャッシュされた応答を提供できます。 たとえば、Cache スコープを使用して、フライト情報を求める顧客の要求を管理できます。多くの顧客がサンフランシスコからブエノスアイレスへのフライトに関する同じ価格設定情報を要求する場合があります。多くの処理能力を使用して顧客のクエリごとに個別の要求を複数の航空データベースに送信する代わりに、Cache スコープを使用してデータベースへの要求の送信回数が少なくなるように調整し (10 分に 1 回など)、キャッシュされたフライト価格設定情報をユーザーに提供できます。データの適時性が重要でない場合、Cache スコープで時間と処理能力を節約できます。 任意の数のメッセージプロセッサー (コネクタやコンポーネントなど) を Cache スコープに配置し、スコープ内で発生した処理で生成される応答 (応答メッセージのペイロードが含まれる) を保存するようにキャッシュ戦略を設定できます。 キャッシュ戦略で設定されているオブジェクトストアはクラスター内のすべてのノードで共有されるため、Cache スコープはクラスター化された環境でも機能します。 ## [](#キャッシュプロセス)キャッシュプロセス Cache スコープは反復可能なストリームをキャッシュします。失われる前に 1 回だけ読み取ることができる反復不可能なストリームはキャッシュしません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 一般的なキャッシュプロセスシーケンスは、次のとおりです。 1. メッセージが Cache スコープに入ります。 2. Cache スコープは、メッセージペイロードが反復可能かどうかを判断します。 3. Cache スコープは、メッセージのペイロードを識別するキーを生成します。 デフォルトでは、Mule は SHA256KeyGenerator および SHA256 ダイジェストを使用して、メッセージペイロードの一意のキーを生成します。ただし、カスタムキャッシュ戦略で独自のキーをセットアップできます。 4. Cache スコープは、新しく生成されたキーと、以前に処理されてキャッシュされた応答を比較し、セットアップした ObjectStore (推奨) またはデフォルトの ​`InMemoryObjectStore`​ に保存します。 - キャッシュされた応答イベントがない場合 (​_キャッシュミス_​)、Cache スコープは新しいメッセージを処理し、応答を生成します。 また、結果の応答をオブジェクトストアに保存します (反復可能な応答の場合)。 - キャッシュされた応答イベントがある場合 (​_キャッシュヒット_​)、キャッシュ戦略は、新しい要求とキャッシュされた応答の両方のデータを結合する応答を生成します。 生成された応答が反復不可能なストリームである場合は、応答をキャッシュしません。 5. Cache スコープは、処理を続行するために応答を親フローにプッシュします。 ## [](#キャッシュ戦略)キャッシュ戦略 キャッシュ戦略は、メッセージがサブフローに入ってきたときに Cache スコープが実行するアクションを定義します。デフォルトでは、Cache スコープは、メモリ内のオブジェクトストアにデータを保存するキャッシュ戦略を使用します。既存のオブジェクトストアを参照するカスタムキャッシュ戦略を作成するか、またはこのキャッシュ戦略で使用する新しいカスタムオブジェクトストアを作成することができます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。キャッシュへのアクセスを同期するようにキャッシュ戦略を設定して、異なるメッセージプロセッサーが同時にキャッシュを使用できないようにすることもできます。 キャッシュ戦略は、次のカスタマイズも参照できます。 - ObjectStore のイベントキー (ペイロードを ObjectStore に保存するためのキーの作成に使用される DataWeave 式または Java オブジェクト)。 - 戦略の応答ジェネレーター (キャッシュ戦略から返される応答の作成に使用される Java オブジェクトへの参照)。 - 変更可能または変更不可能なデータのイベントコピー戦略。 ## [](#絞り込み)絞り込み Cache スコープは、受信するすべてのメッセージペイロードを処理する代わりに、DataWeave 式に基づいて Cache スコープフローから特定のペイロードを除外できます。 ## [](#例)例 Anypoint Studio では、Anypoint Exchange からサンプルプロジェクト ​_Cache Scope with Salesforce Contacts_​ (Cache スコープと Salesforce 取引先責任者) をダウンロードして開き、Cache スコープの使用方法について学習できます。このサンプルでは、Salesforce からフェッチされたデータをキャッシュします。クエリが発行されてデータが再度要求されると、キャッシュから結果が返され、Salesforce への新しいコールは実行されません。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.6/cache-scope-strategy) - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.6/streaming-about) # Cache スコープ Cache スコープは、頻繁にコールされるデータを保存および再利用するために使用されます。Cache スコープを使用して、Mule インスタンスの処理負荷を減らし、フロー内のメッセージ処理速度を上げることができます。次のタスクでは、特に効果的です。 - 同じ情報を繰り返し求める要求の処理。 - 大容量の反復可能なストリームに関連する情報を求める要求の処理。 Mule アプリケーションのメッセージプロセッサーが Cache スコープにメッセージを送信すると、親フローは出力を要求します。Cache スコープは、メッセージペイロードを処理して、出力を親フローに配信し、出力を保存 (応答をキャッシュ) します。Cache スコープは、次に同じ種類のメッセージペイロードを受信したときに、時間がかかる可能性のあるプロセスを再度呼び出す代わりにキャッシュされた応答を提供できます。 たとえば、Cache スコープを使用して、フライト情報を求める顧客の要求を管理できます。多くの顧客がサンフランシスコからブエノスアイレスへのフライトに関する同じ価格設定情報を要求する場合があります。多くの処理能力を使用して顧客のクエリごとに個別の要求を複数の航空データベースに送信する代わりに、Cache スコープを使用してデータベースへの要求の送信回数が少なくなるように調整し (10 分に 1 回など)、キャッシュされたフライト価格設定情報をユーザーに提供できます。データの適時性が重要でない場合、Cache スコープで時間と処理能力を節約できます。 任意の数のメッセージプロセッサー (コネクタやコンポーネントなど) を Cache スコープに配置し、スコープ内で発生した処理で生成される応答 (応答メッセージのペイロードが含まれる) を保存するようにキャッシュ戦略を設定できます。 キャッシュ戦略で設定されているオブジェクトストアはクラスター内のすべてのノードで共有されるため、Cache スコープはクラスター化された環境でも機能します。 ## [](#キャッシュプロセス)キャッシュプロセス Cache スコープは反復可能なストリームをキャッシュします。失われる前に 1 回だけ読み取ることができる反復不可能なストリームはキャッシュしません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 一般的なキャッシュプロセスシーケンスは、次のとおりです。 1. メッセージが Cache スコープに入ります。 2. Cache スコープは、メッセージペイロードが反復可能かどうかを判断します。 3. Cache スコープは、メッセージのペイロードを識別するキーを生成します。 デフォルトでは、Mule は SHA256KeyGenerator および SHA256 ダイジェストを使用して、メッセージペイロードの一意のキーを生成します。ただし、カスタムキャッシュ戦略で独自のキーをセットアップできます。 4. Cache スコープは、新しく生成されたキーと、以前に処理されてキャッシュされた応答を比較し、セットアップした ObjectStore (推奨) またはデフォルトの ​`InMemoryObjectStore`​ に保存します。 - キャッシュされた応答イベントがない場合 (​_キャッシュミス_​)、Cache スコープは新しいメッセージを処理し、応答を生成します。 また、結果の応答をオブジェクトストアに保存します (反復可能な応答の場合)。 - キャッシュされた応答イベントがある場合 (​_キャッシュヒット_​)、キャッシュ戦略は、新しい要求とキャッシュされた応答の両方のデータを結合する応答を生成します。 生成された応答が反復不可能なストリームである場合は、応答をキャッシュしません。 5. Cache スコープは、処理を続行するために応答を親フローにプッシュします。 ## [](#キャッシュ戦略)キャッシュ戦略 キャッシュ戦略は、メッセージがサブフローに入ってきたときに Cache スコープが実行するアクションを定義します。デフォルトでは、Cache スコープは、メモリ内のオブジェクトストアにデータを保存するキャッシュ戦略を使用します。既存のオブジェクトストアを参照するカスタムキャッシュ戦略を作成するか、またはこのキャッシュ戦略で使用する新しいカスタムオブジェクトストアを作成することができます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。キャッシュへのアクセスを同期するようにキャッシュ戦略を設定して、異なるメッセージプロセッサーが同時にキャッシュを使用できないようにすることもできます。 キャッシュ戦略は、次のカスタマイズも参照できます。 - ObjectStore のイベントキー (ペイロードを ObjectStore に保存するためのキーの作成に使用される DataWeave 式または Java オブジェクト)。 - 戦略の応答ジェネレーター (キャッシュ戦略から返される応答の作成に使用される Java オブジェクトへの参照)。 - 変更可能または変更不可能なデータのイベントコピー戦略。 ## [](#絞り込み)絞り込み Cache スコープは、受信するすべてのメッセージペイロードを処理する代わりに、DataWeave 式に基づいて Cache スコープフローから特定のペイロードを除外できます。 ## [](#例)例 Anypoint Studio では、Anypoint Exchange からサンプルプロジェクト ​_Cache Scope with Salesforce Contacts_​ (Cache スコープと Salesforce 取引先責任者) をダウンロードして開き、Cache スコープの使用方法について学習できます。このサンプルでは、Salesforce からフェッチされたデータをキャッシュします。クエリが発行されてデータが再度要求されると、キャッシュから結果が返され、Salesforce への新しいコールは実行されません。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.7/cache-scope-strategy) - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.7/streaming-about) # Cache スコープ Cache スコープは、頻繁にコールされるデータを保存および再利用するために使用されます。Cache スコープを使用して、Mule インスタンスの処理負荷を減らし、フロー内のメッセージ処理速度を上げることができます。次のタスクでは、特に効果的です。 - 同じ情報を繰り返し求める要求の処理。 - 大容量の反復可能なストリームに関連する情報を求める要求の処理。 Mule アプリケーションのメッセージプロセッサーが Cache スコープにメッセージを送信すると、親フローは出力を要求します。Cache スコープは、メッセージペイロードを処理して、出力を親フローに配信し、出力を保存 (応答をキャッシュ) します。Cache スコープは、次に同じ種類のメッセージペイロードを受信したときに、時間がかかる可能性のあるプロセスを再度呼び出す代わりにキャッシュされた応答を提供できます。 たとえば、Cache スコープを使用して、フライト情報を求める顧客の要求を管理できます。多くの顧客がサンフランシスコからブエノスアイレスへのフライトに関する同じ価格設定情報を要求する場合があります。多くの処理能力を使用して顧客のクエリごとに個別の要求を複数の航空データベースに送信する代わりに、Cache スコープを使用してデータベースへの要求の送信回数が少なくなるように調整し (10 分に 1 回など)、キャッシュされたフライト価格設定情報をユーザーに提供できます。データの適時性が重要でない場合、Cache スコープで時間と処理能力を節約できます。 任意の数のメッセージプロセッサー (コネクタやコンポーネントなど) を Cache スコープに配置し、スコープ内で発生した処理で生成される応答 (応答メッセージのペイロードが含まれる) を保存するようにキャッシュ戦略を設定できます。 キャッシュ戦略で設定されているオブジェクトストアはクラスター内のすべてのノードで共有されるため、Cache スコープはクラスタリングされた環境でも機能します。 ## [](#キャッシュプロセス)キャッシュプロセス Cache スコープは反復可能なストリームをキャッシュします。失われる前に 1 回だけ読み取ることができる反復不可能なストリームはキャッシュしません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 一般的なキャッシュプロセスシーケンスは、次のとおりです。 1. メッセージが Cache スコープに入ります。 2. Cache スコープは、メッセージペイロードが反復可能かどうかを判断します。 3. Cache スコープは、メッセージのペイロードを識別するキーを生成します。 デフォルトでは、Mule は SHA256KeyGenerator および SHA256 ダイジェストを使用して、メッセージペイロードの一意のキーを生成します。ただし、カスタムキャッシュ戦略で独自のキーをセットアップできます。 4. Cache スコープは、新しく生成されたキーと、以前に処理されてキャッシュされた応答を比較し、セットアップした ObjectStore (推奨) またはデフォルトの ​`InMemoryObjectStore`​ に保存します。 - キャッシュされた応答イベントがない場合 (​_キャッシュミス_​)、Cache スコープは新しいメッセージを処理し、応答を生成します。 また、結果の応答をオブジェクトストアに保存します (反復可能な応答の場合)。 - キャッシュされた応答イベントがある場合 (​_キャッシュヒット_​)、キャッシュ戦略は、新しい要求とキャッシュされた応答の両方のデータを結合する応答を生成します。 生成された応答が反復不可能なストリームである場合は、応答をキャッシュしません。 5. Cache スコープは、処理を続行するために応答を親フローにプッシュします。 ## [](#キャッシュ戦略)キャッシュ戦略 キャッシュ戦略は、メッセージがサブフローに入ってきたときに Cache スコープが実行するアクションを定義します。デフォルトでは、Cache スコープは、メモリ内のオブジェクトストアにデータを保存するキャッシュ戦略を使用します。既存のオブジェクトストアを参照するカスタムキャッシュ戦略を作成するか、またはこのキャッシュ戦略で使用する新しいカスタムオブジェクトストアを作成することができます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。キャッシュへのアクセスを同期するようにキャッシュ戦略を設定して、異なるメッセージプロセッサーが同時にキャッシュを使用できないようにすることもできます。 キャッシュ戦略は、次のカスタマイズも参照できます。 - ObjectStore のイベントキー (ペイロードを ObjectStore に保存するためのキーの作成に使用される DataWeave 式または Java オブジェクト)。 - 戦略の応答ジェネレーター (キャッシュ戦略から返される応答の作成に使用される Java オブジェクトへの参照)。 - 変更可能または変更不可能なデータのイベントコピー戦略。 ## [](#絞り込み)絞り込み Cache スコープは、受信するすべてのメッセージペイロードを処理する代わりに、DataWeave 式に基づいて Cache スコープフローから特定のペイロードを除外できます。 ## [](#例)例 Anypoint Studio では、Anypoint Exchange からサンプルプロジェクト ​_Cache Scope with Salesforce Contacts_​ (Cache スコープと Salesforce 取引先責任者) をダウンロードして開き、Cache スコープの使用方法について学習できます。このサンプルでは、Salesforce からフェッチされたデータをキャッシュします。クエリが発行されてデータが再度要求されると、キャッシュから結果が返され、Salesforce への新しいコールは実行されません。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.8/cache-scope-strategy) - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.8/streaming-about) # Cache スコープ Cache スコープは、頻繁にコールされるデータを保存および再利用するために使用されます。Cache スコープを使用して、Mule インスタンスの処理負荷を減らし、フロー内のメッセージ処理速度を上げることができます。次のタスクでは、特に効果的です。 - 同じ情報を繰り返し求める要求の処理。 - 大容量の反復可能なストリームに関連する情報を求める要求の処理。 Mule アプリケーションのメッセージプロセッサーが Cache スコープにメッセージを送信すると、親フローは出力を要求します。Cache スコープは、メッセージペイロードを処理して、出力を親フローに配信し、出力を保存 (応答をキャッシュ) します。Cache スコープは、次に同じ種類のメッセージペイロードを受信したときに、時間がかかる可能性のあるプロセスを再度呼び出す代わりにキャッシュされた応答を提供できます。 たとえば、Cache スコープを使用して、フライト情報を求める顧客の要求を管理できます。多くの顧客がサンフランシスコからブエノスアイレスへのフライトに関する同じ価格設定情報を要求する場合があります。多くの処理能力を使用して顧客のクエリごとに個別の要求を複数の航空データベースに送信する代わりに、Cache スコープを使用してデータベースへの要求の送信回数が少なくなるように調整し (10 分に 1 回など)、キャッシュされたフライト価格設定情報をユーザーに提供できます。データの適時性が重要でない場合、Cache スコープで時間と処理能力を節約できます。 任意の数のメッセージプロセッサー (コネクタやコンポーネントなど) を Cache スコープに配置し、スコープ内で発生した処理で生成される応答 (応答メッセージのペイロードが含まれる) を保存するようにキャッシュ戦略を設定できます。 キャッシュ戦略で設定されているオブジェクトストアはクラスター内のすべてのノードで共有されるため、Cache スコープはクラスタリングされた環境でも機能します。 ## [](#キャッシュプロセス)キャッシュプロセス Cache スコープは反復可能なストリームをキャッシュします。失われる前に 1 回だけ読み取ることができる反復不可能なストリームはキャッシュしません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 一般的なキャッシュプロセスシーケンスは、次のとおりです。 1. メッセージが Cache スコープに入ります。 2. Cache スコープは、メッセージペイロードが反復可能かどうかを判断します。 3. Cache スコープは、メッセージのペイロードを識別するキーを生成します。 デフォルトでは、Mule は SHA256KeyGenerator および SHA256 ダイジェストを使用して、メッセージペイロードの一意のキーを生成します。ただし、カスタムキャッシュ戦略で独自のキーをセットアップできます。 4. Cache スコープは、新しく生成されたキーと、以前に処理されてキャッシュされた応答を比較し、セットアップした ObjectStore (推奨) またはデフォルトの ​`InMemoryObjectStore`​ に保存します。 - キャッシュされた応答イベントがない場合 (​_キャッシュミス_​)、Cache スコープは新しいメッセージを処理し、応答を生成します。 また、結果の応答をオブジェクトストアに保存します (反復可能な応答の場合)。 - キャッシュされた応答イベントがある場合 (​_キャッシュヒット_​)、キャッシュ戦略は、新しい要求とキャッシュされた応答の両方のデータを結合する応答を生成します。 生成された応答が反復不可能なストリームである場合は、応答をキャッシュしません。 5. Cache スコープは、処理を続行するために応答を親フローにプッシュします。 ## [](#キャッシュ戦略)キャッシュ戦略 キャッシュ戦略は、メッセージがサブフローに入ってきたときに Cache スコープが実行するアクションを定義します。デフォルトでは、Cache スコープは、メモリ内のオブジェクトストアにデータを保存するキャッシュ戦略を使用します。既存のオブジェクトストアを参照するカスタムキャッシュ戦略を作成するか、またはこのキャッシュ戦略で使用する新しいカスタムオブジェクトストアを作成することができます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。キャッシュへのアクセスを同期するようにキャッシュ戦略を設定して、異なるメッセージプロセッサーが同時にキャッシュを使用できないようにすることもできます。 キャッシュ戦略は、次のカスタマイズも参照できます。 - ObjectStore のイベントキー (ペイロードを ObjectStore に保存するためのキーの作成に使用される DataWeave 式または Java オブジェクト)。 - 戦略の応答ジェネレーター (キャッシュ戦略から返される応答の作成に使用される Java オブジェクトへの参照)。 - 変更可能または変更不可能なデータのイベントコピー戦略。 ## [](#絞り込み)絞り込み Cache スコープは、受信するすべてのメッセージペイロードを処理する代わりに、DataWeave 式に基づいて Cache スコープフローから特定のペイロードを除外できます。 ## [](#例)例 Anypoint Studio では、Anypoint Exchange からサンプルプロジェクト ​_Cache Scope with Salesforce Contacts_​ (Cache スコープと Salesforce 取引先責任者) をダウンロードして開き、Cache スコープの使用方法について学習できます。このサンプルでは、Salesforce からフェッチされたデータをキャッシュします。クエリが発行されてデータが再度要求されると、キャッシュから結果が返され、Salesforce への新しいコールは実行されません。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.9/cache-scope-strategy) - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.9/streaming-about) # Cache スコープの設定 1. Mule アプリケーションで、Cache スコープをフローに追加します。 2. クリックして Cache スコープの \[General (一般)\] タブを開きます。 3. Cache スコープを設定します。 - 表示名を入力する。 - キャッシュ戦略を選択する。 例: - UI: `My_Caching_Strategy` - Studio XML: `cachingStrategy-ref="My_Caching_Strategy"` 本番環境では、デフォルトを使用する代わりに ObjectStore を使用するキャッシュ戦略を参照することをお勧めします。 キャッシュ戦略を作成する必要がある場合、​[\[See Also\]](<#See Also>)​の手順を参照してください。 4. 必要に応じて、特定のペイロードの検索条件をセットアップします。 DataWeave 式を使用する例: `filterExpression="#[user.isPremium()]"` メッセージが式に一致する場合、Mule はキャッシュ戦略を実行します。 メッセージが式に一致しない場合、Mule は Cache スコープ内のすべてのメッセージプロセッサーでメッセージを処理しますが、キャッシュされた応答は保存および生成しません。 ## [](#cache-スコープの設定例)Cache スコープの設定例 キャッシュ戦略の設定例を次に示します。このキャッシュ戦略は、Database Select 操作と Transform コンポーネントを含む Cache スコープによって参照されます。 ```xml ``` ## [](#関連情報)関連情報 [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.3/cache-scope-strategy) [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/cache-scope) # Cache スコープの設定 1. Mule アプリケーションで、Cache スコープをフローに追加します。 2. クリックして Cache スコープの \[General (一般)\] タブを開きます。 3. Cache スコープを設定します。 - 表示名を入力する。 - キャッシュ戦略を選択する。 例: - UI: `My_Caching_Strategy` - Studio XML: `cachingStrategy-ref="My_Caching_Strategy"` 本番環境では、デフォルトを使用する代わりに ObjectStore を使用するキャッシュ戦略を参照することをお勧めします。 キャッシュ戦略を作成する必要がある場合、​[\[See Also\]](<#See Also>)​の手順を参照してください。 4. 必要に応じて、特定のペイロードの検索条件をセットアップします。 DataWeave 式を使用する例: `filterExpression="#[user.isPremium()]"` メッセージが式に一致する場合、Mule はキャッシュ戦略を実行します。 メッセージが式に一致しない場合、Mule は Cache スコープ内のすべてのメッセージプロセッサーでメッセージを処理しますが、キャッシュされた応答は保存および生成しません。 ## [](#cache-スコープの設定例)Cache スコープの設定例 キャッシュ戦略の設定例を次に示します。このキャッシュ戦略は、Database Select 操作と Transform コンポーネントを含む Cache スコープによって参照されます。 ```xml ``` ## [](#関連情報)関連情報 [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.4/cache-scope-strategy) [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/cache-scope) # Cache スコープの設定 1. Mule アプリケーションで、Cache スコープをフローに追加します。 2. クリックして Cache スコープの \[General (一般)\] タブを開きます。 3. Cache スコープを設定します。 - 表示名を入力する。 - キャッシュ戦略を選択する。 例: - UI: `My_Caching_Strategy` - Studio XML: `cachingStrategy-ref="My_Caching_Strategy"` 本番環境では、デフォルトを使用する代わりに ObjectStore を使用するキャッシュ戦略を参照することをお勧めします。 キャッシュ戦略を作成する必要がある場合、「​[関連情報](#関連情報)​」の手順を参照してください。 4. 必要に応じて、特定のペイロードの検索条件をセットアップします。 DataWeave 式を使用する例: `filterExpression="#[user.isPremium()]"` メッセージが式に一致する場合、Mule はキャッシュ戦略を実行します。 メッセージが式に一致しない場合、Mule は Cache スコープ内のすべてのメッセージプロセッサーでメッセージを処理しますが、キャッシュされた応答は保存および生成しません。 ## [](#cache-スコープの設定例)Cache スコープの設定例 キャッシュ戦略の設定例を次に示します。このキャッシュ戦略は、Database Select 操作と Transform コンポーネントを含む Cache スコープによって参照されます。 ```xml ``` ## [](#関連情報)関連情報 [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.5/cache-scope-strategy) [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/cache-scope) # Cache スコープの設定 1. Mule アプリケーションで、Cache スコープをフローに追加します。 2. クリックして Cache スコープの \[General (一般)\] タブを開きます。 3. Cache スコープを設定します。 - 表示名を入力する。 - キャッシュ戦略を選択する。 例: - UI: `My_Caching_Strategy` - Studio XML: `cachingStrategy-ref="My_Caching_Strategy"` 本番環境では、デフォルトを使用する代わりに ObjectStore を使用するキャッシュ戦略を参照することをお勧めします。 キャッシュ戦略を作成する必要がある場合、​[\[See Also\]](<#See Also>)​の手順を参照してください。 4. 必要に応じて、特定のペイロードの検索条件をセットアップします。 DataWeave 式を使用する例: `filterExpression="#[user.isPremium()]"` メッセージが式に一致する場合、Mule はキャッシュ戦略を実行します。 メッセージが式に一致しない場合、Mule は Cache スコープ内のすべてのメッセージプロセッサーでメッセージを処理しますが、キャッシュされた応答は保存および生成しません。 ## [](#cache-スコープの設定例)Cache スコープの設定例 キャッシュ戦略の設定例を次に示します。このキャッシュ戦略は、Database Select 操作と Transform コンポーネントを含む Cache スコープによって参照されます。 ```xml ``` ## [](#関連情報)関連情報 [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.6/cache-scope-strategy) [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/cache-scope) # Cache スコープの設定 1. Mule アプリケーションで、Cache スコープをフローに追加します。 2. クリックして Cache スコープの \[General (一般)\] タブを開きます。 3. Cache スコープを設定します。 - 表示名を入力する。 - キャッシュ戦略を選択する。 例: - UI: `My_Caching_Strategy` - Studio XML: `cachingStrategy-ref="My_Caching_Strategy"` 本番環境では、デフォルトを使用する代わりに ObjectStore を使用するキャッシュ戦略を参照することをお勧めします。 キャッシュ戦略を作成する必要がある場合、​[\[See Also\]](<#See Also>)​の手順を参照してください。 4. 必要に応じて、特定のペイロードの検索条件をセットアップします。 DataWeave 式を使用する例: `filterExpression="#[user.isPremium()]"` メッセージが式に一致する場合、Mule はキャッシュ戦略を実行します。 メッセージが式に一致しない場合、Mule は Cache スコープ内のすべてのメッセージプロセッサーでメッセージを処理しますが、キャッシュされた応答は保存および生成しません。 ## [](#cache-スコープの設定例)Cache スコープの設定例 キャッシュ戦略の設定例を次に示します。このキャッシュ戦略は、Database Select 操作と Transform コンポーネントを含む Cache スコープによって参照されます。 ```xml ``` ## [](#関連情報)関連情報 [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.7/cache-scope-strategy) [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/cache-scope) # Cache スコープの設定 1. Mule アプリケーションで、Cache スコープをフローに追加します。 2. クリックして Cache スコープの \[General (一般)\] タブを開きます。 3. Cache スコープを設定します。 - 表示名を入力する。 - キャッシュ戦略を選択する。 例: - UI: `My_Caching_Strategy` - Studio XML: `cachingStrategy-ref="My_Caching_Strategy"` 本番環境では、デフォルトを使用する代わりに ObjectStore を使用するキャッシュ戦略を参照することをお勧めします。 キャッシュ戦略を作成する必要がある場合、​[\[See Also\]](<#See Also>)​の手順を参照してください。 4. 必要に応じて、特定のペイロードの検索条件をセットアップします。 DataWeave 式を使用する例: `filterExpression="#[user.isPremium()]"` メッセージが式に一致する場合、Mule はキャッシュ戦略を実行します。 メッセージが式に一致しない場合、Mule は Cache スコープ内のすべてのメッセージプロセッサーでメッセージを処理しますが、キャッシュされた応答は保存および生成しません。 ## [](#cache-スコープの設定例)Cache スコープの設定例 キャッシュ戦略の設定例を次に示します。このキャッシュ戦略は、Database Select 操作と Transform コンポーネントを含む Cache スコープによって参照されます。 ```xml ``` ## [](#関連情報)関連情報 [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.8/cache-scope-strategy) [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/cache-scope) # Cache スコープの設定 1. Mule アプリケーションで、Cache スコープをフローに追加します。 2. クリックして Cache スコープの \[General (一般)\] タブを開きます。 3. Cache スコープを設定します。 - 表示名を入力する。 - キャッシュ戦略を選択する。 例: - UI: `My_Caching_Strategy` - Studio XML: `cachingStrategy-ref="My_Caching_Strategy"` 本番環境では、デフォルトを使用する代わりに ObjectStore を使用するキャッシュ戦略を参照することをお勧めします。 キャッシュ戦略を作成する必要がある場合、​[\[See Also\]](<#See Also>)​の手順を参照してください。 4. 必要に応じて、特定のペイロードの検索条件をセットアップします。 DataWeave 式を使用する例: `filterExpression="#[user.isPremium()]"` メッセージが式に一致する場合、Mule はキャッシュ戦略を実行します。 メッセージが式に一致しない場合、Mule は Cache スコープ内のすべてのメッセージプロセッサーでメッセージを処理しますが、キャッシュされた応答は保存および生成しません。 ## [](#cache-スコープの設定例)Cache スコープの設定例 キャッシュ戦略の設定例を次に示します。このキャッシュ戦略は、Database Select 操作と Transform コンポーネントを含む Cache スコープによって参照されます。 ```xml ``` ## [](#関連情報)関連情報 [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.9/cache-scope-strategy) [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/cache-scope) # Choice ルーター Choice ルーターは、メッセージコンテンツを評価する一連の DataWeave 式に従ってフローで動的にメッセージをルーティングします。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 Choice ルーターが実行するルートは 1 つのみです。つまり、最初に ​`true`​ と評価された式がルートの実行をトリガーし、他のルートはチェックされません。どの式も ​`true`​ でない場合は、デフォルトルートが実行されます。 ![Choice ルーターの系統図](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/component-choice-schematic.png) Figure 1. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターの系統図 ## [](#設定)設定 Choice ルーターを設定するには、1 つ以上の評価する条件と、いずれかの条件が ​`true`​ と評価された場合に実行されるメッセージプロセッサーを指定します。さらに、定義された条件がいずれも ​`true`​ でない場合に実行されるデフォルトルートを設定します。 ### [](#anypoint-studio-設定)Anypoint Studio 設定 Studio で Choice ルートを設定するには、次の手順に従います。 ![Studio の Choice 設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-choice-configuration-studio.png) 1. **Choice**​ コンポーネントをフローの任意の位置にドラッグします。 2. Choice ルーター内の ​**\[When (条件)\]**​ をクリックし、プロパティウィンドウで ​**\[Expression (式)\]**​ の値を設定して、評価する条件を指定します。 3. **\[When (条件)\]**​ 内にメッセージプロセッサーをドラッグして、条件を満たした場合に実行されるプロセッサーを指定します。 4. **\[Default (デフォルト)\]**​ 内にメッセージプロセッサーをドラッグして、定義された条件をいずれも満たさなかった場合に実行されるプロセッサーを指定します。 ### [](#xml-設定)XML 設定 Choice ルーターの基本的な XML 構造を次に示します。 ```xml (1) (2) (3) ```
1expression​ 属性には、評価する条件が含まれています。
2expression​ が ​true​ と評価された場合に実行される任意の数のメッセージプロセッサーを追加します。
3条件がいずれも ​true​ と評価されなかった場合に実行される任意の数のメッセージプロセッサーを追加します。
## [](#choice-ルーターへのルートの追加)Choice ルーターへのルートの追加 デフォルトでは、Choice ルーターは設定された DataWeave 式が ​`true`​ に評価されると実行される 1 つのルートオプションと、既存ルートのどの式も ​`true`​ に評価されなかったときに実行されるデフォルトルートを持ちます。複数の条件を評価して、成立した条件に応じて異なる操作を実行する必要がある場合は、ルートを追加してください。 ### [](#studio-でコンポーネントをドラッグしてルートを追加する)Studio でコンポーネントをドラッグしてルートを追加する Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ で任意のコンポーネントをクリックして、Choice ルーターまでドラッグします (黒い垂直線が表示されます)。 ![add+route+option](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-choice-add-route.png) ### [](#xml-を編集してルートを追加する)XML を編集してルートを追加する XML 設定ファイルを編集して Choice ルーターにルートオプションを追加することもできます。 1. Studio で Choice ルーターを右クリックして ​**\[Go to XML…​ (XML へ移動…​)\]**​ を選択します。 2. ``​ 要素内に ​``​ 要素を追加します。 ```xml ``` 新しい ​``​ 要素を追加すると、新しいルートオプションが \[Message Flow (メッセージフロー)\] ビューに表示されます。 ![new-route-option](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-choice-new-route.png) ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Studio を使用して、Anypoint Exchange からサンプルプロジェクト ​_Content-Based Routing_​ (コンテンツベースのルーティング) をダウンロードできます。このプロジェクトでは、Choice ルーターを使用するフローの稼働サンプルが提供されます。 ![choice-router-example](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-choice-example.png) Figure 2. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターを含むフロー このサンプルプロジェクトをダウンロードして開く手順は、次のとおりです。 1. Anypoint Studio で \[Exchange\] アイコン (​![3%](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-exchange-icon.png)​) をクリックします。 2. 左側のパネルで ​**\[All assets (すべてのアセット)\]**​ をクリックします。 3. 開いたウィンドウで、Anypoint Exchange にログインし、サンプルプロジェクトの Content-Based Routing (コンテンツベースのルーティング) を検索します。 4. \[Open (開く)\] アイコン (​![6%](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-open-exchange-icon.png)​) をクリックします。 ### [](#サンプルプロジェクトの動作)サンプルプロジェクトの動作 プロジェクトを Mule アプリケーションとして実行すると、アプリケーションは次のアクションを実行します。 1. メッセージをリスンします。 2. メッセージを変数設定コンポーネントに渡します。このコンポーネントは、パラメーター ​`language`​ でメッセージに渡される言語を変数 ​`language`​ に設定します。 3. Choice ルーターを使用して、各メッセージに ​`language`​ 属性が含まれているかどうかを確認します。この属性の存在や値によって、Choice ルーターによるメッセージのルーティング方法が決まります。 - 値が ​`French`​ の場合、ルーターはメッセージを​_「Reply in French (フランス語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Bonjour!`​ をリクエスターに返します。 - 値が ​`Spanish`​ の場合、ルーターはメッセージを​_「Reply in Spanish (スペイン語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Hola!`​ をリクエスターに返します。 - メッセージに ​`language`​ 属性が含まれていない場合、ルーターはメッセージをデフォルトパスにルーティングします。デフォルトパスは、次の作業を行うサブフローです。 4. メッセージ「No language specified. Using English as a default. (言語が指定されていません。デフォルトとして英語が使用されます。)」をコンソールに記録する。 5. `language`​ の値を ​`English`​ に設定する。 6. メッセージ ​`Hello!`​ を返す。 このサンプルプロジェクトは、フローで Choice ルーターを使用してメッセージをルーティングするときに 4 つの側面を考慮する必要があることを示しています。 - メッセージのルーティング方法を決定するために Choice ルーターが評価するコンテンツ - ルーターの数 - デフォルトルーティングオプション - ルーティングオプションごとにフローで実行する処理 ## [](#サンプル-xml)サンプル XML サンプル Choice ルーターの XML コードを次に示します。 ```xml ``` ## [](#choice-ルーター-xml-リファレンス)Choice ルーター XML リファレンス Choice フロー制御コンポーネントには次の要素が含まれます。 - 1 つのルート要素 ​`` - 各ルーティングオプションの ​``​ 子要素 (それぞれに照合する式がある) - ``​ 要素のどの式も ​`true`​ に評価されないすべてのケースを処理する Choice の ​``​ 子要素 (省略可能) - 各 Choice に基づいて条件付きで実行されるコンポーネント (​`when`​ および ​`otherwise`​ 要素の子要素として定義される) ### [](#choice-のプロパティ) のプロパティ
プロパティ 説明

ビジネスイベント

ビジネスイベント機能をアクティブ化する場合に使用します。

<choice doc:name="Choice" tracking:enable-default-events="true" >
### [](#when-のプロパティ) のプロパティ
プロパティ 説明

式 (​expression​)

入力を評価する DataWeave 言語の式。
式が ​true​ に評価されると、このルーティングオプションが使用されます。

<when expression="#[vars.language == 'Spanish']" >
## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-flows) - [データの抽出](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-cookbook-extract-data) - [DataWeave スクリプト](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-language-introduction) - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events) # Choice ルーター Choice ルーターは、メッセージコンテンツを評価する一連の DataWeave 式に従ってフローで動的にメッセージをルーティングします。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 Choice ルーターが実行するルートは 1 つのみです。つまり、最初に ​`true`​ と評価された式がルートの実行をトリガーし、他のルートはチェックされません。どの式も ​`true`​ でない場合は、デフォルトルートが実行されます。 ![Choice ルーターの系統図](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/component-choice-schematic.png) Figure 1. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターの系統図 ## [](#設定)設定 Choice ルーターを設定するには、1 つ以上の評価する条件と、いずれかの条件が ​`true`​ と評価された場合に実行されるメッセージプロセッサーを指定します。さらに、定義された条件がいずれも ​`true`​ でない場合に実行されるデフォルトルートを設定します。 ### [](#anypoint-studio-設定)Anypoint Studio 設定 Studio で Choice ルートを設定するには、次の手順に従います。 ![Studio の Choice 設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-choice-configuration-studio.png) 1. **Choice**​ コンポーネントをフローの任意の位置にドラッグします。 2. Choice ルーター内の ​**\[When (条件)\]**​ をクリックし、プロパティウィンドウで ​**\[Expression (式)\]**​ の値を設定して、評価する条件を指定します。 3. **\[When (条件)\]**​ 内にメッセージプロセッサーをドラッグして、条件を満たした場合に実行されるプロセッサーを指定します。 4. **\[Default (デフォルト)\]**​ 内にメッセージプロセッサーをドラッグして、定義された条件をいずれも満たさなかった場合に実行されるプロセッサーを指定します。 ### [](#xml-設定)XML 設定 Choice ルーターの基本的な XML 構造を次に示します。 ```xml (1) (2) (3) ```
1expression​ 属性には、評価する条件が含まれています。
2expression​ が ​true​ と評価された場合に実行される任意の数のメッセージプロセッサーを追加します。
3条件がいずれも ​true​ と評価されなかった場合に実行される任意の数のメッセージプロセッサーを追加します。
## [](#choice-ルーターへのルートの追加)Choice ルーターへのルートの追加 デフォルトでは、Choice ルーターは設定された DataWeave 式が ​`true`​ に評価されると実行される 1 つのルートオプションと、既存ルートのどの式も ​`true`​ に評価されなかったときに実行されるデフォルトルートを持ちます。複数の条件を評価して、成立した条件に応じて異なる操作を実行する必要がある場合は、ルートを追加してください。 ### [](#studio-でコンポーネントをドラッグしてルートを追加する)Studio でコンポーネントをドラッグしてルートを追加する Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ で任意のコンポーネントをクリックして、Choice ルーターまでドラッグします (黒い垂直線が表示されます)。 ![add+route+option](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-choice-add-route.png) ### [](#xml-を編集してルートを追加する)XML を編集してルートを追加する XML 設定ファイルを編集して Choice ルーターにルートオプションを追加することもできます。 1. Studio で Choice ルーターを右クリックして ​**\[Go to XML…​ (XML へ移動…​)\]**​ を選択します。 2. ``​ 要素内に ​``​ 要素を追加します。 ```xml ``` 新しい ​``​ 要素を追加すると、新しいルートオプションが \[Message Flow (メッセージフロー)\] ビューに表示されます。 ![new-route-option](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-choice-new-route.png) ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Studio を使用して、Anypoint Exchange からサンプルプロジェクト ​_Content-Based Routing_​ (コンテンツベースのルーティング) をダウンロードできます。このプロジェクトでは、Choice ルーターを使用するフローの稼働サンプルが提供されます。 ![choice-router-example](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-choice-example.png) Figure 2. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターを含むフロー このサンプルプロジェクトをダウンロードして開く手順は、次のとおりです。 1. Anypoint Studio で \[Exchange\] アイコン (​![3%](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-exchange-icon.png)​) をクリックします。 2. 左側のパネルで ​**\[All assets (すべてのアセット)\]**​ をクリックします。 3. 開いたウィンドウで、Anypoint Exchange にログインし、サンプルプロジェクトの Content-Based Routing (コンテンツベースのルーティング) を検索します。 4. \[Open (開く)\] アイコン (​![6%](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-open-exchange-icon.png)​) をクリックします。 ### [](#サンプルプロジェクトの動作)サンプルプロジェクトの動作 プロジェクトを Mule アプリケーションとして実行すると、アプリケーションは次のアクションを実行します。 1. メッセージをリスンします。 2. メッセージを変数設定コンポーネントに渡します。このコンポーネントは、パラメーター ​`language`​ でメッセージに渡される言語を変数 ​`language`​ に設定します。 3. Choice ルーターを使用して、各メッセージに ​`language`​ 属性が含まれているかどうかを確認します。この属性の存在や値によって、Choice ルーターによるメッセージのルーティング方法が決まります。 - 値が ​`French`​ の場合、ルーターはメッセージを​_「Reply in French (フランス語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Bonjour!`​ をリクエスターに返します。 - 値が ​`Spanish`​ の場合、ルーターはメッセージを​_「Reply in Spanish (スペイン語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Hola!`​ をリクエスターに返します。 - メッセージに ​`language`​ 属性が含まれていない場合、ルーターはメッセージをデフォルトパスにルーティングします。デフォルトパスは、次の作業を行うサブフローです。 4. メッセージ「No language specified. Using English as a default. (言語が指定されていません。デフォルトとして英語が使用されます。)」をコンソールに記録する。 5. `language`​ の値を ​`English`​ に設定する。 6. メッセージ ​`Hello!`​ を返す。 このサンプルプロジェクトは、フローで Choice ルーターを使用してメッセージをルーティングするときに 4 つの側面を考慮する必要があることを示しています。 - メッセージのルーティング方法を決定するために Choice ルーターが評価するコンテンツ - ルーターの数 - デフォルトルーティングオプション - ルーティングオプションごとにフローで実行する処理 ## [](#サンプル-xml)サンプル XML サンプル Choice ルーターの XML コードを次に示します。 ```xml ``` ## [](#choice-ルーター-xml-リファレンス)Choice ルーター XML リファレンス Choice フロー制御コンポーネントには次の要素が含まれます。 - 1 つのルート要素 ​`` - 各ルーティングオプションの ​``​ 子要素 (それぞれに照合する式がある) - ``​ 要素のどの式も ​`true`​ に評価されないすべてのケースを処理する Choice の ​``​ 子要素 (省略可能) - 各 Choice に基づいて条件付きで実行されるコンポーネント (​`when`​ および ​`otherwise`​ 要素の子要素として定義される) ### [](#choice-のプロパティ) のプロパティ
プロパティ 説明

ビジネスイベント

ビジネスイベント機能をアクティブ化する場合に使用します。

<choice doc:name="Choice" tracking:enable-default-events="true" >
### [](#when-のプロパティ) のプロパティ
プロパティ 説明

式 (​expression​)

入力を評価する DataWeave 言語の式。
式が ​true​ に評価されると、このルーティングオプションが使用されます。

<when expression="#[vars.language == 'Spanish']" >
## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-flows) - [データの抽出](https://docs.mulesoft.com/dataweave/latest/dataweave-cookbook-extract-data) - [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events) # Choice ルーター Choice ルーターは、メッセージコンテンツを評価する一連の DataWeave 式に従ってフローで動的にメッセージをルーティングします。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 Choice ルーターが実行するルートは 1 つのみです。つまり、最初に ​`true`​ と評価された式がルートの実行をトリガーし、他のルートはチェックされません。どの式も ​`true`​ でない場合は、デフォルトルートが実行されます。 ![Choice ルーターの系統図](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/component-choice-schematic.png) Figure 1. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターの系統図 ## [](#設定)設定 Choice ルーターを設定するには、1 つ以上の評価する条件と、いずれかの条件が ​`true`​ と評価された場合に実行されるメッセージプロセッサーを指定します。さらに、定義された条件がいずれも ​`true`​ でない場合に実行されるデフォルトルートを設定します。 ### [](#anypoint-studio-設定)Anypoint Studio 設定 Studio で Choice ルートを設定するには、次の手順に従います。 ![Studio の Choice 設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-choice-configuration-studio.png) 1. **Choice**​ コンポーネントをフローの任意の位置にドラッグします。 2. Choice ルーター内の ​**\[When (条件)\]**​ をクリックし、プロパティウィンドウで ​**\[Expression (式)\]**​ の値を設定して、評価する条件を指定します。 3. **\[When (条件)\]**​ 内にメッセージプロセッサーをドラッグして、条件を満たした場合に実行されるプロセッサーを指定します。 4. **\[Default (デフォルト)\]**​ 内にメッセージプロセッサーをドラッグして、定義された条件をいずれも満たさなかった場合に実行されるプロセッサーを指定します。 ### [](#xml-設定)XML 設定 Choice ルーターの基本的な XML 構造を次に示します。 ```xml (1) (2) (3) ```
1expression​ 属性には、評価する条件が含まれています。
2expression​ が ​true​ と評価された場合に実行される任意の数のメッセージプロセッサーを追加します。
3条件がいずれも ​true​ と評価されなかった場合に実行される任意の数のメッセージプロセッサーを追加します。
## [](#choice-ルーターへのルートの追加)Choice ルーターへのルートの追加 デフォルトでは、Choice ルーターは設定された DataWeave 式が ​`true`​ に評価されると実行される 1 つのルートオプションと、既存ルートのどの式も ​`true`​ に評価されなかったときに実行されるデフォルトルートを持ちます。複数の条件を評価して、成立した条件に応じて異なる操作を実行する必要がある場合は、ルートを追加してください。 ### [](#studio-でコンポーネントをドラッグしてルートを追加する)Studio でコンポーネントをドラッグしてルートを追加する Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ で任意のコンポーネントをクリックして、Choice ルーターまでドラッグします (黒い垂直線が表示されます)。 ![add+route+option](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-choice-add-route.png) ### [](#xml-を編集してルートを追加する)XML を編集してルートを追加する XML 設定ファイルを編集して Choice ルーターにルートオプションを追加することもできます。 1. Studio で Choice ルーターを右クリックして ​**\[Go to XML…​ (XML へ移動…​)\]**​ を選択します。 2. ``​ 要素内に ​``​ 要素を追加します。 ```xml ``` 新しい ​``​ 要素を追加すると、新しいルートオプションが \[Message Flow (メッセージフロー)\] ビューに表示されます。 ![new-route-option](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-choice-new-route.png) ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Studio を使用して、Anypoint Exchange からサンプルプロジェクト ​_Content-Based Routing_​ (コンテンツベースのルーティング) をダウンロードできます。このプロジェクトでは、Choice ルーターを使用するフローの稼働サンプルが提供されます。 ![choice-router-example](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-choice-example.png) Figure 2. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターを含むフロー このサンプルプロジェクトをダウンロードして開く手順は、次のとおりです。 1. Anypoint Studio で \[Exchange\] アイコン (​![3%](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-exchange-icon.png)​) をクリックします。 2. 左側のパネルで ​**\[All assets (すべてのアセット)\]**​ をクリックします。 3. 開いたウィンドウで、Anypoint Exchange にログインし、サンプルプロジェクトの Content-Based Routing (コンテンツベースのルーティング) を検索します。 4. \[Open (開く)\] アイコン (​![6%](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-open-exchange-icon.png)​) をクリックします。 ### [](#サンプルプロジェクトの動作)サンプルプロジェクトの動作 プロジェクトを Mule アプリケーションとして実行すると、アプリケーションは次のアクションを実行します。 1. メッセージをリスンします。 2. メッセージを変数設定コンポーネントに渡します。このコンポーネントは、パラメーター ​`language`​ でメッセージに渡される言語を変数 ​`language`​ に設定します。 3. Choice ルーターを使用して、各メッセージに ​`language`​ 属性が含まれているかどうかを確認します。この属性の存在や値によって、Choice ルーターによるメッセージのルーティング方法が決まります。 - 値が ​`French`​ の場合、ルーターはメッセージを​_「Reply in French (フランス語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Bonjour!`​ をリクエスターに返します。 - 値が ​`Spanish`​ の場合、ルーターはメッセージを​_「Reply in Spanish (スペイン語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Hola!`​ をリクエスターに返します。 - メッセージに ​`language`​ 属性が含まれていない場合、ルーターはメッセージをデフォルトパスにルーティングします。デフォルトパスは、次の作業を行うサブフローです。 4. メッセージ「No language specified. Using English as a default. (言語が指定されていません。デフォルトとして英語が使用されます。)」をコンソールに記録する。 5. `language`​ の値を ​`English`​ に設定する。 6. メッセージ ​`Hello!`​ を返す。 このサンプルプロジェクトは、フローで Choice ルーターを使用してメッセージをルーティングするときに 4 つの側面を考慮する必要があることを示しています。 - メッセージのルーティング方法を決定するために Choice ルーターが評価するコンテンツ - ルーターの数 - デフォルトルーティングオプション - ルーティングオプションごとにフローで実行する処理 ## [](#サンプル-xml)サンプル XML サンプル Choice ルーターの XML コードを次に示します。 ```xml ``` ## [](#choice-ルーター-xml-リファレンス)Choice ルーター XML リファレンス Choice フロー制御コンポーネントには次の要素が含まれます。 - 1 つのルート要素 ​`` - 各ルーティングオプションの ​``​ 子要素 (それぞれに照合する式がある) - ``​ 要素のどの式も ​`true`​ に評価されないすべてのケースを処理する Choice の ​``​ 子要素 (省略可能) - 各 Choice に基づいて条件付きで実行されるコンポーネント (​`when`​ および ​`otherwise`​ 要素の子要素として定義される) ### [](#choice-のプロパティ) のプロパティ
プロパティ 説明

ビジネスイベント

ビジネスイベント機能をアクティブ化する場合に使用します。

<choice doc:name="Choice" tracking:enable-default-events="true" >
### [](#when-のプロパティ) のプロパティ
プロパティ 説明

式 (​expression​)

入力を評価する DataWeave 言語の式。
式が ​true​ に評価されると、このルーティングオプションが使用されます。

<when expression="#[vars.language == 'Spanish']" >
## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-flows) - [データの抽出](https://docs.mulesoft.com/dataweave/latest/dataweave-cookbook-extract-data) - [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events) # Choice ルーター Choice ルーターは、メッセージコンテンツを評価する一連の DataWeave 式に従ってフローで動的にメッセージをルーティングします。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 Choice ルーターが実行するルートは 1 つのみです。つまり、最初に ​`true`​ と評価された式がルートの実行をトリガーし、他のルートはチェックされません。どの式も ​`true`​ でない場合は、デフォルトルートが実行されます。 ![Choice ルーターの系統図](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/component-choice-schematic.png) Figure 1. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターの系統図 ## [](#設定)設定 Choice ルーターを設定するには、1 つ以上の評価する条件と、いずれかの条件が ​`true`​ と評価された場合に実行されるメッセージプロセッサーを指定します。さらに、定義された条件がいずれも ​`true`​ でない場合に実行されるデフォルトルートを設定します。 ### [](#anypoint-studio-設定)Anypoint Studio 設定 Studio で Choice ルートを設定するには、次の手順に従います。 ![Studio の Choice 設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-choice-configuration-studio.png) 1. **Choice**​ コンポーネントをフローの任意の位置にドラッグします。 2. Choice ルーター内の ​**\[When (条件)\]**​ をクリックし、プロパティウィンドウで ​**\[Expression (式)\]**​ の値を設定して、評価する条件を指定します。 3. **\[When (条件)\]**​ 内にメッセージプロセッサーをドラッグして、条件を満たした場合に実行されるプロセッサーを指定します。 4. **\[Default (デフォルト)\]**​ 内にメッセージプロセッサーをドラッグして、定義された条件をいずれも満たさなかった場合に実行されるプロセッサーを指定します。 ### [](#xml-設定)XML 設定 Choice ルーターの基本的な XML 構造を次に示します。 ```xml (1) (2) (3) ```
1expression​ 属性には、評価する条件が含まれています。
2expression​ が ​true​ と評価された場合に実行される任意の数のメッセージプロセッサーを追加します。
3条件がいずれも ​true​ と評価されなかった場合に実行される任意の数のメッセージプロセッサーを追加します。
## [](#choice-ルーターへのルートの追加)Choice ルーターへのルートの追加 デフォルトでは、Choice ルーターは設定された DataWeave 式が ​`true`​ に評価されると実行される 1 つのルートオプションと、既存ルートのどの式も ​`true`​ に評価されなかったときに実行されるデフォルトルートを持ちます。複数の条件を評価して、成立した条件に応じて異なる操作を実行する必要がある場合は、ルートを追加してください。 ### [](#studio-でコンポーネントをドラッグしてルートを追加する)Studio でコンポーネントをドラッグしてルートを追加する Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ で任意のコンポーネントをクリックして、Choice ルーターまでドラッグします (黒い垂直線が表示されます)。 ![add+route+option](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-choice-add-route.png) ### [](#xml-を編集してルートを追加する)XML を編集してルートを追加する XML 設定ファイルを編集して Choice ルーターにルートオプションを追加することもできます。 1. Studio で Choice ルーターを右クリックして ​**\[Go to XML…​ (XML へ移動…​)\]**​ を選択します。 2. ``​ 要素内に ​``​ 要素を追加します。 ```xml ``` 新しい ​``​ 要素を追加すると、新しいルートオプションが \[Message Flow (メッセージフロー)\] ビューに表示されます。 ![new-route-option](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-choice-new-route.png) ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Studio を使用して、Anypoint Exchange からサンプルプロジェクト ​_Content-Based Routing_​ (コンテンツベースのルーティング) をダウンロードできます。このプロジェクトでは、Choice ルーターを使用するフローの稼働サンプルが提供されます。 ![choice-router-example](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-choice-example.png) Figure 2. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターを含むフロー このサンプルプロジェクトをダウンロードして開く手順は、次のとおりです。 1. Anypoint Studio で \[Exchange\] アイコン (​![3%](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-exchange-icon.png)​) をクリックします。 2. 左側のパネルで ​**\[All assets (すべてのアセット)\]**​ をクリックします。 3. 開いたウィンドウで、Anypoint Exchange にログインし、サンプルプロジェクトの Content-Based Routing (コンテンツベースのルーティング) を検索します。 4. \[Open (開く)\] アイコン (​![6%](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-open-exchange-icon.png)​) をクリックします。 ### [](#サンプルプロジェクトの動作)サンプルプロジェクトの動作 プロジェクトを Mule アプリケーションとして実行すると、アプリケーションは次のアクションを実行します。 1. メッセージをリスンします。 2. メッセージを変数設定コンポーネントに渡します。このコンポーネントは、パラメーター ​`language`​ でメッセージに渡される言語を変数 ​`language`​ に設定します。 3. Choice ルーターを使用して、各メッセージに ​`language`​ 属性が含まれているかどうかを確認します。この属性の存在や値によって、Choice ルーターによるメッセージのルーティング方法が決まります。 - 値が ​`French`​ の場合、ルーターはメッセージを​_「Reply in French (フランス語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Bonjour!`​ をリクエスターに返します。 - 値が ​`Spanish`​ の場合、ルーターはメッセージを​_「Reply in Spanish (スペイン語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Hola!`​ をリクエスターに返します。 - メッセージに ​`language`​ 属性が含まれていない場合、ルーターはメッセージをデフォルトパスにルーティングします。デフォルトパスは、次の作業を行うサブフローです。 4. メッセージ「No language specified. Using English as a default. (言語が指定されていません。デフォルトとして英語が使用されます。)」をコンソールに記録する。 5. `language`​ の値を ​`English`​ に設定する。 6. メッセージ ​`Hello!`​ を返す。 このサンプルプロジェクトは、フローで Choice ルーターを使用してメッセージをルーティングするときに 4 つの側面を考慮する必要があることを示しています。 - メッセージのルーティング方法を決定するために Choice ルーターが評価するコンテンツ - ルーターの数 - デフォルトルーティングオプション - ルーティングオプションごとにフローで実行する処理 ## [](#サンプル-xml)サンプル XML サンプル Choice ルーターの XML コードを次に示します。 ```xml ``` ## [](#choice-ルーター-xml-リファレンス)Choice ルーター XML リファレンス Choice フロー制御コンポーネントには次の要素が含まれます。 - 1 つのルート要素 ​`` - 各ルーティングオプションの ​``​ 子要素 (それぞれに照合する式がある) - ``​ 要素のどの式も ​`true`​ に評価されないすべてのケースを処理する Choice の ​``​ 子要素 (省略可能) - 各 Choice に基づいて条件付きで実行されるコンポーネント (​`when`​ および ​`otherwise`​ 要素の子要素として定義される) ### [](#choice-のプロパティ) のプロパティ
プロパティ 説明

ビジネスイベント

ビジネスイベント機能をアクティブ化する場合に使用します。

<choice doc:name="Choice" tracking:enable-default-events="true" >
### [](#when-のプロパティ) のプロパティ
プロパティ 説明

式 (​expression​)

入力を評価する DataWeave 言語の式。
式が ​true​ に評価されると、このルーティングオプションが使用されます。

<when expression="#[vars.language == 'Spanish']" >
## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-flows) - [データの抽出](https://docs.mulesoft.com/dataweave/latest/dataweave-cookbook-extract-data) - [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events) # Choice ルーター Choice ルーターは、メッセージコンテンツを評価する一連の DataWeave 式に従ってフローで動的にメッセージをルーティングします。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 Choice ルーターが実行するルートは 1 つのみです。つまり、最初に ​`true`​ と評価された式がルートの実行をトリガーし、他のルートはチェックされません。どの式も ​`true`​ でない場合は、デフォルトルートが実行されます。 ![複数のオプション (1 つはデフォルト) が表示されている Choice ルーターの系統図](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/component-choice-schematic.png) Figure 1. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターの系統図 ## [](#設定)設定 Choice ルーターを設定するには、1 つ以上の評価する条件と、いずれかの条件が ​`true`​ と評価された場合に実行されるメッセージプロセッサーを指定します。さらに、定義された条件がいずれも ​`true`​ でない場合に実行されるデフォルトルートを設定します。 ### [](#anypoint-studio-設定)Anypoint Studio 設定 Studio で Choice ルートを設定するには、次の手順に従います。 ![Studio の Choice 設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-choice-configuration-studio.png) 1. **Choice**​ コンポーネントをフローの任意の位置にドラッグします。 2. Choice ルーター内の ​**\[When (条件)\]**​ をクリックし、プロパティウィンドウで ​**\[Expression (式)\]**​ の値を設定して、評価する条件を指定します。 3. **\[When (条件)\]**​ 内にメッセージプロセッサーをドラッグして、条件を満たした場合に実行されるプロセッサーを指定します。 4. **\[Default (デフォルト)\]**​ 内にメッセージプロセッサーをドラッグして、定義された条件をいずれも満たさなかった場合に実行されるプロセッサーを指定します。 ### [](#xml-設定)XML 設定 Choice ルーターの基本的な XML 構造を次に示します。 ```xml (1) (2) (3) ```
1expression​ 属性には、評価する条件が含まれています。
2expression​ が ​true​ と評価された場合に実行される任意の数のメッセージプロセッサーを追加します。
3条件がいずれも ​true​ と評価されなかった場合に実行される任意の数のメッセージプロセッサーを追加します。
## [](#choice-ルーターへのルートの追加)Choice ルーターへのルートの追加 デフォルトでは、Choice ルーターは設定された DataWeave 式が ​`true`​ に評価されると実行される 1 つのルートオプションと、既存ルートのどの式も ​`true`​ に評価されなかったときに実行されるデフォルトルートを持ちます。複数の条件を評価して、成立した条件に応じて異なる操作を実行する必要がある場合は、ルートを追加してください。 ### [](#studio-でコンポーネントをドラッグしてルートを追加する)Studio でコンポーネントをドラッグしてルートを追加する Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ で任意のコンポーネントをクリックして、Choice ルーターまでドラッグします (黒い垂直線が表示されます)。 ![add+route+option](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-choice-add-route.png) ### [](#xml-を編集してルートを追加する)XML を編集してルートを追加する XML 設定ファイルを編集して Choice ルーターにルートオプションを追加することもできます。 1. Studio で Choice ルーターを右クリックして ​**\[Go to XML…​ (XML へ移動…​)\]**​ を選択します。 2. ``​ 要素内に ​``​ 要素を追加します。 ```xml ``` 新しい ​``​ 要素を追加すると、新しいルートオプションが \[Message Flow (メッセージフロー)\] ビューに表示されます。 ![new-route-option](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-choice-new-route.png) ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Studio を使用して、Anypoint Exchange からサンプルプロジェクト ​_Content-Based Routing_​ (コンテンツベースのルーティング) をダウンロードできます。このプロジェクトでは、Choice ルーターを使用するフローの稼働サンプルが提供されます。 ![choice-router-example](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-choice-example.png) Figure 2. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターを含むフロー このサンプルプロジェクトをダウンロードして開く手順は、次のとおりです。 1. Anypoint Studio で Exchange アイコン (​![](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-exchange-icon.png)​) をクリックします。 2. 左側のパネルで ​**\[All assets (すべてのアセット)\]**​ をクリックします。 3. 開いたウィンドウで、Anypoint Exchange にログインし、サンプルプロジェクトの Content-Based Routing (コンテンツベースのルーティング) を検索します。 4. \[Open (開く)\] アイコン (​![](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-open-exchange-icon.png)​) をクリックします。 ### [](#サンプルプロジェクトの動作)サンプルプロジェクトの動作 プロジェクトを Mule アプリケーションとして実行すると、アプリケーションは次のアクションを実行します。 1. メッセージをリスンします。 2. メッセージを変数設定コンポーネントに渡します。このコンポーネントは、パラメーター ​`language`​ でメッセージに渡される言語を変数 ​`language`​ に設定します。 3. Choice ルーターを使用して、各メッセージに ​`language`​ 属性が含まれているかどうかを確認します。この属性の存在や値によって、Choice ルーターによるメッセージのルーティング方法が決まります。 - 値が ​`French`​ の場合、ルーターはメッセージを​_「Reply in French (フランス語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Bonjour!`​ をリクエスターに返します。 - 値が ​`Spanish`​ の場合、ルーターはメッセージを​_「Reply in Spanish (スペイン語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Hola!`​ をリクエスターに返します。 - メッセージに ​`language`​ 属性が含まれていない場合、ルーターはメッセージをデフォルトパスにルーティングします。デフォルトパスは、次の作業を行うサブフローです。 4. メッセージ「No language specified. Using English as a default. (言語が指定されていません。デフォルトとして英語が使用されます。)」をコンソールに記録する。 5. `language`​ の値を ​`English`​ に設定する。 6. メッセージ ​`Hello!`​ を返す。 このサンプルプロジェクトは、フローで Choice ルーターを使用してメッセージをルーティングするときに 4 つの側面を考慮する必要があることを示しています。 - メッセージのルーティング方法を決定するために Choice ルーターが評価するコンテンツ - ルーターの数 - デフォルトルーティングオプション - ルーティングオプションごとにフローで実行する処理 ## [](#サンプル-xml)サンプル XML サンプル Choice ルーターの XML コードを次に示します。 ```xml ``` ## [](#choice-ルーター-xml-リファレンス)Choice ルーター XML リファレンス Choice フロー制御コンポーネントには次の要素が含まれます。 - 1 つのルート要素 ​`` - 各ルーティングオプションの ​``​ 子要素 (それぞれに照合する式がある) - ``​ 要素のどの式も ​`true`​ に評価されないすべてのケースを処理する Choice の ​``​ 子要素 (省略可能) - 各 Choice に基づいて条件付きで実行されるコンポーネント (​`when`​ および ​`otherwise`​ 要素の子要素として定義される) ### [](#choice-のプロパティ) のプロパティ
プロパティ 説明

ビジネスイベント

ビジネスイベント機能をアクティブ化する場合に使用します。

<choice doc:name="Choice" tracking:enable-default-events="true" >
### [](#when-のプロパティ) のプロパティ
プロパティ 説明

式 (​expression​)

入力を評価する DataWeave 言語の式。
式が ​true​ に評価されると、このルーティングオプションが使用されます。

<when expression="#[vars.language == 'Spanish']" >
## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-flows) - [データの抽出](https://docs.mulesoft.com/dataweave/latest/dataweave-cookbook-extract-data) - [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events) # Choice ルーター Choice ルーターは、メッセージコンテンツを評価する一連の DataWeave 式に従ってフローで動的にメッセージをルーティングします。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 Choice ルーターが実行するルートは 1 つのみです。つまり、最初に ​`true`​ と評価された式がルートの実行をトリガーし、他のルートはチェックされません。どの式も ​`true`​ でない場合は、デフォルトルートが実行されます。 ![複数のオプション (1 つはデフォルト) が表示されている Choice ルーターの系統図](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/component-choice-schematic.png) Figure 1. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターの系統図 ## [](#設定)設定 Choice ルーターを設定するには、1 つ以上の評価する条件と、いずれかの条件が ​`true`​ と評価された場合に実行されるメッセージプロセッサーを指定します。さらに、定義された条件がいずれも ​`true`​ でない場合に実行されるデフォルトルートを設定します。 ### [](#anypoint-studio-設定)Anypoint Studio 設定 Studio で Choice ルートを設定するには、次の手順に従います。 ![Studio の Choice コンポーネントの設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-choice-configuration-studio.png) 1. **Choice**​ コンポーネントをフローの任意の位置にドラッグします。 2. Choice ルーター内の ​**\[When (条件)\]**​ をクリックし、プロパティウィンドウで ​**\[Expression (式)\]**​ の値を設定して、評価する条件を指定します。 3. **\[When (条件)\]**​ 内にメッセージプロセッサーをドラッグして、条件を満たした場合に実行されるプロセッサーを指定します。 4. **\[Default (デフォルト)\]**​ 内にメッセージプロセッサーをドラッグして、定義された条件をいずれも満たさなかった場合に実行されるプロセッサーを指定します。 ### [](#xml-設定)XML 設定 Choice ルーターの基本的な XML 構造を次に示します。 ```xml (1) (2) (3) ```
1expression​ 属性には、評価する条件が含まれています。
2expression​ が ​true​ と評価された場合に実行される任意の数のメッセージプロセッサーを追加します。
3条件がいずれも ​true​ と評価されなかった場合に実行される任意の数のメッセージプロセッサーを追加します。
## [](#choice-ルーターへのルートの追加)Choice ルーターへのルートの追加 デフォルトでは、Choice ルーターは設定された DataWeave 式が ​`true`​ に評価されると実行される 1 つのルートオプションと、既存ルートのどの式も ​`true`​ に評価されなかったときに実行されるデフォルトルートを持ちます。複数の条件を評価して、成立した条件に応じて異なる操作を実行する必要がある場合は、ルートを追加してください。 ### [](#studio-でコンポーネントをドラッグしてルートを追加する)Studio でコンポーネントをドラッグしてルートを追加する Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ で任意のコンポーネントをクリックして、Choice ルーターまでドラッグします (黒い垂直線が表示されます)。 ![コンテンツベースのルーティング設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-choice-add-route.png) ### [](#xml-を編集してルートを追加する)XML を編集してルートを追加する XML 設定ファイルを編集して Choice ルーターにルートオプションを追加することもできます。 1. Studio で Choice ルーターを右クリックして ​**\[Go to XML…​ (XML へ移動…​)\]**​ を選択します。 2. ``​ 要素内に ​``​ 要素を追加します。 ```xml ``` 新しい ​``​ 要素を追加すると、新しいルートオプションが \[Message Flow (メッセージフロー)\] ビューに表示されます。 ![新しいコンテンツベースのルーティングパスのフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-choice-new-route.png) ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Studio を使用して、Anypoint Exchange からサンプルプロジェクト ​_Content-Based Routing_​ (コンテンツベースのルーティング) をダウンロードできます。このプロジェクトでは、Choice ルーターを使用するフローの稼働サンプルが提供されます。 ![ペイロード設定とエラー処理が含まれるコンテンツベースのルーティングのフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-choice-example.png) Figure 2. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターを含むフロー このサンプルプロジェクトをダウンロードして開く手順は、次のとおりです。 1. Anypoint Studio で Exchange アイコン (​![](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-exchange-icon.png)​) をクリックします。 2. 左側のパネルで ​**\[All assets (すべてのアセット)\]**​ をクリックします。 3. 開いたウィンドウで、Anypoint Exchange にログインし、サンプルプロジェクトの Content-Based Routing (コンテンツベースのルーティング) を検索します。 4. \[Open (開く)\] アイコン (​![](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-open-exchange-icon.png)​) をクリックします。 ### [](#サンプルプロジェクトの動作)サンプルプロジェクトの動作 プロジェクトを Mule アプリケーションとして実行すると、アプリケーションは次のアクションを実行します。 1. メッセージをリスンします。 2. メッセージを変数設定コンポーネントに渡します。このコンポーネントは、パラメーター ​`language`​ でメッセージに渡される言語を変数 ​`language`​ に設定します。 3. Choice ルーターを使用して、各メッセージに ​`language`​ 属性が含まれているかどうかを確認します。この属性の存在や値によって、Choice ルーターによるメッセージのルーティング方法が決まります。 - 値が ​`French`​ の場合、ルーターはメッセージを​_「Reply in French (フランス語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Bonjour!`​ をリクエスターに返します。 - 値が ​`Spanish`​ の場合、ルーターはメッセージを​_「Reply in Spanish (スペイン語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Hola!`​ をリクエスターに返します。 - メッセージに ​`language`​ 属性が含まれていない場合、ルーターはメッセージをデフォルトパスにルーティングします。デフォルトパスは、次の作業を行うサブフローです。 4. メッセージ「No language specified. Using English as a default. (言語が指定されていません。デフォルトとして英語が使用されます。)」をコンソールに記録する。 5. `language`​ の値を ​`English`​ に設定する。 6. メッセージ ​`Hello!`​ を返す。 このサンプルプロジェクトは、フローで Choice ルーターを使用してメッセージをルーティングするときに 4 つの側面を考慮する必要があることを示しています。 - メッセージのルーティング方法を決定するために Choice ルーターが評価するコンテンツ - ルーターの数 - デフォルトルーティングオプション - ルーティングオプションごとにフローで実行する処理 ## [](#サンプル-xml)サンプル XML サンプル Choice ルーターの XML コードを次に示します。 ```xml ``` ## [](#choice-ルーター-xml-リファレンス)Choice ルーター XML リファレンス Choice フロー制御コンポーネントには次の要素が含まれます。 - 1 つのルート要素 ​`` - 各ルーティングオプションの ​``​ 子要素 (それぞれに照合する式がある) - ``​ 要素のどの式も ​`true`​ に評価されないすべてのケースを処理する Choice の ​``​ 子要素 (省略可能) - 各 Choice に基づいて条件付きで実行されるコンポーネント (​`when`​ および ​`otherwise`​ 要素の子要素として定義される) ### [](#choice-のプロパティ) のプロパティ
プロパティ 説明

ビジネスイベント

ビジネスイベント機能をアクティブ化する場合に使用します。

<choice doc:name="Choice" tracking:enable-default-events="true" >
### [](#when-のプロパティ) のプロパティ
プロパティ 説明

式 (​expression​)

入力を評価する DataWeave 言語の式。
式が ​true​ に評価されると、このルーティングオプションが使用されます。

<when expression="#[vars.language == 'Spanish']" >
## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-flows) - [データの抽出](https://docs.mulesoft.com/dataweave/latest/dataweave-cookbook-extract-data) - [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events) # Choice ルーター Choice ルーターは、メッセージコンテンツを評価する一連の DataWeave 式に従ってフローで動的にメッセージをルーティングします。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 Choice ルーターが実行するルートは 1 つのみです。つまり、最初に ​`true`​ と評価された式がルートの実行をトリガーし、他のルートはチェックされません。どの式も ​`true`​ でない場合は、デフォルトルートが実行されます。 ![複数のオプション (1 つはデフォルト) が表示されている Choice ルーターの系統図](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/component-choice-schematic.png) Figure 1. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターの系統図 ## [](#設定)設定 Choice ルーターを設定するには、1 つ以上の評価する条件と、いずれかの条件が ​`true`​ と評価された場合に実行されるメッセージプロセッサーを指定します。さらに、定義された条件がいずれも ​`true`​ でない場合に実行されるデフォルトルートを設定します。 ### [](#anypoint-studio-設定)Anypoint Studio 設定 Studio で Choice ルートを設定するには、次の手順に従います。 ![Studio の Choice コンポーネントの設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-choice-configuration-studio.png) 1. **Choice**​ コンポーネントをフローの任意の位置にドラッグします。 2. Choice ルーター内の ​**\[When (条件)\]**​ をクリックし、プロパティウィンドウで ​**\[Expression (式)\]**​ の値を設定して、評価する条件を指定します。 3. **\[When (条件)\]**​ 内にメッセージプロセッサーをドラッグして、条件を満たした場合に実行されるプロセッサーを指定します。 4. **\[Default (デフォルト)\]**​ 内にメッセージプロセッサーをドラッグして、定義された条件をいずれも満たさなかった場合に実行されるプロセッサーを指定します。 ### [](#xml-設定)XML 設定 Choice ルーターの基本的な XML 構造を次に示します。 ```xml (1) (2) (3) ```
1expression​ 属性には、評価する条件が含まれています。
2expression​ が ​true​ と評価された場合に実行される任意の数のメッセージプロセッサーを追加します。
3条件がいずれも ​true​ と評価されなかった場合に実行される任意の数のメッセージプロセッサーを追加します。
## [](#choice-ルーターへのルートの追加)Choice ルーターへのルートの追加 デフォルトでは、Choice ルーターは設定された DataWeave 式が ​`true`​ に評価されると実行される 1 つのルートオプションと、既存ルートのどの式も ​`true`​ に評価されなかったときに実行されるデフォルトルートを持ちます。複数の条件を評価して、成立した条件に応じて異なる操作を実行する必要がある場合は、ルートを追加してください。 ### [](#studio-でコンポーネントをドラッグしてルートを追加する)Studio でコンポーネントをドラッグしてルートを追加する Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ で任意のコンポーネントをクリックして、Choice ルーターまでドラッグします (黒い垂直線が表示されます)。 ![コンテンツベースのルーティング設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-choice-add-route.png) ### [](#xml-を編集してルートを追加する)XML を編集してルートを追加する XML 設定ファイルを編集して Choice ルーターにルートオプションを追加することもできます。 1. Studio で Choice ルーターを右クリックして ​**\[Go to XML…​ (XML へ移動…​)\]**​ を選択します。 2. ``​ 要素内に ​``​ 要素を追加します。 ```xml ``` 新しい ​``​ 要素を追加すると、新しいルートオプションが \[Message Flow (メッセージフロー)\] ビューに表示されます。 ![新しいコンテンツベースのルーティングパスのフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-choice-new-route.png) ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Studio を使用して、Anypoint Exchange からサンプルプロジェクト ​_Content-Based Routing_​ (コンテンツベースのルーティング) をダウンロードできます。このプロジェクトでは、Choice ルーターを使用するフローの稼働サンプルが提供されます。 ![ペイロード設定とエラー処理が含まれるコンテンツベースのルーティングのフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-choice-example.png) Figure 2. 3 つのオプション (1 つはデフォルトオプション) がある Choice ルーターを含むフロー このサンプルプロジェクトをダウンロードして開く手順は、次のとおりです。 1. Anypoint Studio で Exchange アイコン (​![](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-exchange-icon.png)​) をクリックします。 2. 左側のパネルで ​**\[All assets (すべてのアセット)\]**​ をクリックします。 3. 開いたウィンドウで、Anypoint Exchange にログインし、サンプルプロジェクトの Content-Based Routing (コンテンツベースのルーティング) を検索します。 4. \[Open (開く)\] アイコン (​![](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-open-exchange-icon.png)​) をクリックします。 ### [](#サンプルプロジェクトの動作)サンプルプロジェクトの動作 プロジェクトを Mule アプリケーションとして実行すると、アプリケーションは次のアクションを実行します。 1. メッセージをリスンします。 2. メッセージを変数設定コンポーネントに渡します。このコンポーネントは、パラメーター ​`language`​ でメッセージに渡される言語を変数 ​`language`​ に設定します。 3. Choice ルーターを使用して、各メッセージに ​`language`​ 属性が含まれているかどうかを確認します。この属性の存在や値によって、Choice ルーターによるメッセージのルーティング方法が決まります。 - 値が ​`French`​ の場合、ルーターはメッセージを​_「Reply in French (フランス語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Bonjour!`​ をリクエスターに返します。 - 値が ​`Spanish`​ の場合、ルーターはメッセージを​_「Reply in Spanish (スペイン語で返信)」_​という名前の Set Payload コンポーネントにルーティングします。後者のコンポーネントは、メッセージ ​`Hola!`​ をリクエスターに返します。 - メッセージに ​`language`​ 属性が含まれていない場合、ルーターはメッセージをデフォルトパスにルーティングします。デフォルトパスは、次の作業を行うサブフローです。 4. メッセージ「No language specified. Using English as a default. (言語が指定されていません。デフォルトとして英語が使用されます。)」をコンソールに記録する。 5. `language`​ の値を ​`English`​ に設定する。 6. メッセージ ​`Hello!`​ を返す。 このサンプルプロジェクトは、フローで Choice ルーターを使用してメッセージをルーティングするときに 4 つの側面を考慮する必要があることを示しています。 - メッセージのルーティング方法を決定するために Choice ルーターが評価するコンテンツ - ルーターの数 - デフォルトルーティングオプション - ルーティングオプションごとにフローで実行する処理 ## [](#サンプル-xml)サンプル XML サンプル Choice ルーターの XML コードを次に示します。 ```xml ``` ## [](#choice-ルーター-xml-リファレンス)Choice ルーター XML リファレンス Choice フロー制御コンポーネントには次の要素が含まれます。 - 1 つのルート要素 ​`` - 各ルーティングオプションの ​``​ 子要素 (それぞれに照合する式がある) - ``​ 要素のどの式も ​`true`​ に評価されないすべてのケースを処理する Choice の ​``​ 子要素 (省略可能) - 各 Choice に基づいて条件付きで実行されるコンポーネント (​`when`​ および ​`otherwise`​ 要素の子要素として定義される) ### [](#choice-のプロパティ) のプロパティ
プロパティ 説明

ビジネスイベント

ビジネスイベント機能をアクティブ化する場合に使用します。

<choice doc:name="Choice" tracking:enable-default-events="true" >
### [](#when-のプロパティ) のプロパティ
プロパティ 説明

式 (​expression​)

入力を評価する DataWeave 言語の式。
式が ​true​ に評価されると、このルーティングオプションが使用されます。

<when expression="#[vars.language == 'Spanish']" >
## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-flows) - [データの抽出](https://docs.mulesoft.com/dataweave/latest/dataweave-cookbook-extract-data) - [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events) # Choice ルーターの移行 次を除き、Mule 3 と Mule 4 の Choice ルーターはほとんど変更されていません。 - DataWeave が式言語となり、when ステートメントで MEL の代わりに実際に使用されます。 - ``​ ブロックは省略可能になりました。 ## [](#when-ブロックの式言語)when ブロックの式言語 when 式は MEL から DataWeave に変更する必要があります。これは、あらゆる形式を解釈する DataWeave の機能を利用し、必要のない変換を回避できることを意味します。たとえば、ユーザーを表す JSON ドキュメントが HTTP 経由で投稿されるフローがあり、そのユーザーが未成年かどうかを確認する必要があるとします。 Mule 3 の例: MEL ```xml ``` Mule 4 では、形式が JSON か Java かを気にする必要はなく、ただ次を実行します。 Mule 4 の例: DataWeave 2 ```xml ``` ## [](#省略可能な-otherwise)省略可能な otherwise Mule 3 では ​``​ ブロックは必須でした。代替ロジックが不要だった場合、​``​ ブロックに含まれるのは重要ではないロガーになることが多々ありました。Mule 4 では ​``​ ブロックは省略可能で、必要ない場合は指定する必要がありません。 ## [](#関連情報)関連情報 [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-error-handlers) [MEL から DataWeave への移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-mel) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-dataweave) # Choice ルーターの移行 次を除き、Mule 3 と Mule 4 の Choice ルーターはほとんど変更されていません。 - DataWeave が式言語となり、when ステートメントで MEL の代わりに実際に使用されます。 - ``​ ブロックは省略可能になりました。 ## [](#when-ブロックの式言語)when ブロックの式言語 when 式は MEL から DataWeave に変更する必要があります。これは、あらゆる形式を解釈する DataWeave の機能を利用し、必要のない変換を回避できることを意味します。たとえば、ユーザーを表す JSON ドキュメントが HTTP 経由で投稿されるフローがあり、そのユーザーが未成年かどうかを確認する必要があるとします。 Mule 3 の例: MEL ```xml ``` Mule 4 では、形式が JSON か Java かを気にする必要はなく、ただ次を実行します。 Mule 4 の例: DataWeave 2 ```xml ``` ## [](#省略可能な-otherwise)省略可能な otherwise Mule 3 では ​``​ ブロックは必須でした。代替ロジックが不要だった場合、​``​ ブロックに含まれるのは重要ではないロガーになることが多々ありました。Mule 4 では ​``​ ブロックは省略可能で、必要ない場合は指定する必要がありません。 ## [](#関連情報)関連情報 [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-error-handlers) [MEL から DataWeave への移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-mel) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-dataweave) # Choice ルーターの移行 次を除き、Mule 3 と Mule 4 の Choice ルーターはほとんど変更されていません。 - DataWeave が式言語となり、when ステートメントで MEL の代わりに実際に使用されます。 - ``​ ブロックは省略可能になりました。 ## [](#when-ブロックの式言語)when ブロックの式言語 when 式は MEL から DataWeave に変更する必要があります。これは、あらゆる形式を解釈する DataWeave の機能を利用し、必要のない変換を回避できることを意味します。たとえば、ユーザーを表す JSON ドキュメントが HTTP 経由で投稿されるフローがあり、そのユーザーが未成年かどうかを確認する必要があるとします。 Mule 3 の例: MEL ```xml ``` Mule 4 では、形式が JSON か Java かを気にする必要はなく、ただ次を実行します。 Mule 4 の例: DataWeave 2 ```xml ``` ## [](#省略可能な-otherwise)省略可能な otherwise Mule 3 では ​``​ ブロックは必須でした。代替ロジックが不要だった場合、​``​ ブロックに含まれるのは重要ではないロガーになることが多々ありました。Mule 4 では ​``​ ブロックは省略可能で、必要ない場合は指定する必要がありません。 ## [](#関連情報)関連情報 [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-error-handlers) [MEL から DataWeave への移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-mel) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-dataweave) # Choice ルーターの移行 次を除き、Mule 3 と Mule 4 の Choice ルーターはほとんど変更されていません。 - DataWeave が式言語となり、when ステートメントで MEL の代わりに実際に使用されます。 - ``​ ブロックは省略可能になりました。 ## [](#when-ブロックの式言語)when ブロックの式言語 when 式は MEL から DataWeave に変更する必要があります。これは、あらゆる形式を解釈する DataWeave の機能を利用し、必要のない変換を回避できることを意味します。たとえば、ユーザーを表す JSON ドキュメントが HTTP 経由で投稿されるフローがあり、そのユーザーが未成年かどうかを確認する必要があるとします。 Mule 3 の例: MEL ```xml ``` Mule 4 では、形式が JSON か Java かを気にする必要はなく、ただ次を実行します。 Mule 4 の例: DataWeave 2 ```xml ``` ## [](#省略可能な-otherwise)省略可能な otherwise Mule 3 では ​``​ ブロックは必須でした。代替ロジックが不要だった場合、​``​ ブロックに含まれるのは重要ではないロガーになることが多々ありました。Mule 4 では ​``​ ブロックは省略可能で、必要ない場合は指定する必要がありません。 ## [](#関連情報)関連情報 [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-error-handlers) [MEL から DataWeave への移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-mel) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-dataweave) # Choice ルーターの移行 次を除き、Mule 3 と Mule 4 の Choice ルーターはほとんど変更されていません。 - DataWeave が式言語となり、when ステートメントで MEL の代わりに実際に使用されます。 - ``​ ブロックは省略可能になりました。 ## [](#when-ブロックの式言語)when ブロックの式言語 when 式は MEL から DataWeave に変更する必要があります。これは、あらゆる形式を解釈する DataWeave の機能を利用し、必要のない変換を回避できることを意味します。たとえば、ユーザーを表す JSON ドキュメントが HTTP 経由で投稿されるフローがあり、そのユーザーが未成年かどうかを確認する必要があるとします。 Mule 3 の例: MEL ```xml ``` Mule 4 では、形式が JSON か Java かを気にする必要はなく、ただ次を実行します。 Mule 4 の例: DataWeave 2 ```xml ``` ## [](#省略可能な-otherwise)省略可能な otherwise Mule 3 では ​``​ ブロックは必須でした。代替ロジックが不要だった場合、​``​ ブロックに含まれるのは重要ではないロガーになることが多々ありました。Mule 4 では ​``​ ブロックは省略可能で、必要ない場合は指定する必要がありません。 ## [](#関連情報)関連情報 [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-error-handlers) [MEL から DataWeave への移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-mel) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-dataweave) # Choice ルーターの移行 次を除き、Mule 3 と Mule 4 の Choice ルーターはほとんど変更されていません。 - DataWeave が式言語となり、when ステートメントで MEL の代わりに実際に使用されます。 - ``​ ブロックは省略可能になりました。 ## [](#when-ブロックの式言語)when ブロックの式言語 when 式は MEL から DataWeave に変更する必要があります。これは、あらゆる形式を解釈する DataWeave の機能を利用し、必要のない変換を回避できることを意味します。たとえば、ユーザーを表す JSON ドキュメントが HTTP 経由で投稿されるフローがあり、そのユーザーが未成年かどうかを確認する必要があるとします。 Mule 3 の例: MEL ```xml ``` Mule 4 では、形式が JSON か Java かを気にする必要はなく、ただ次を実行します。 Mule 4 の例: DataWeave 2 ```xml ``` ## [](#省略可能な-otherwise)省略可能な otherwise Mule 3 では ​``​ ブロックは必須でした。代替ロジックが不要だった場合、​``​ ブロックに含まれるのは重要ではないロガーになることが多々ありました。Mule 4 では ​``​ ブロックは省略可能で、必要ない場合は指定する必要がありません。 ## [](#関連情報)関連情報 [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-error-handlers) [MEL から DataWeave への移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-mel) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-dataweave) # Choice ルーターの移行 次を除き、Mule 3 と Mule 4 の Choice ルーターはほとんど変更されていません。 - DataWeave が式言語となり、when ステートメントで MEL の代わりに実際に使用されます。 - ``​ ブロックは省略可能になりました。 ## [](#when-ブロックの式言語)when ブロックの式言語 when 式は MEL から DataWeave に変更する必要があります。これは、あらゆる形式を解釈する DataWeave の機能を利用し、必要のない変換を回避できることを意味します。たとえば、ユーザーを表す JSON ドキュメントが HTTP 経由で投稿されるフローがあり、そのユーザーが未成年かどうかを確認する必要があるとします。 Mule 3 の例: MEL ```xml ``` Mule 4 では、形式が JSON か Java かを気にする必要はなく、ただ次を実行します。 Mule 4 の例: DataWeave 2 ```xml ``` ## [](#省略可能な-otherwise)省略可能な otherwise Mule 3 では ​``​ ブロックは必須でした。代替ロジックが不要だった場合、​``​ ブロックに含まれるのは重要ではないロガーになることが多々ありました。Mule 4 では ​``​ ブロックは省略可能で、必要ない場合は指定する必要がありません。 ## [](#関連情報)関連情報 [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-error-handlers) [MEL から DataWeave への移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-mel) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-dataweave) # Correlation ID (相関 ID) Mule で新しいイベントが作成されると、イベントがフローの次のプロセッサーに送信される前に​**相関 ID**​ と呼ばれる一意の識別子文字列が生成されます。この ID を使用すると、異なるログエントリを特定の実行と相関することができます。 相関 ID を使用して、問題や未処理のエラーの原因となったイベントのすべての履歴を把握することができます (すべてのエラーに、エラーをトリガーしたイベントの相関 ID が含まれます)。また、相関 ID を知ることで、ヒープダンプのメモリ分析を用意に行うことができます。 相関 ID を取得するため、Mule ではまずソースメッセージ (X-CORRELATION-ID ヘッダーを持つ JMS メッセージや HTTP リスナー) に相関 ID があるかどうかが確認されます。ソースで相関 ID が設定されていない場合、Mule で相関 ID ジェネレーターを使用して相関 ID が生成されます。 ## [](#相関-id-ジェネレーターの変更)相関 ID ジェネレーターの変更 相関 ID ジェネレーターに変更を加えることはお勧めしませんが、次のような場合、イベントの相関 ID を書式設定することが必要になることがあります。 - 会社に相関 ID に関する独自の標準または形式がある。 - 外部システムの相関 ID の長さが Mule の相関 ID とは異なるため、それらの互換性がなく、トレースできない。 Mule での相関 ID の生成方法を変更する手順は、次のとおりです。 1. ``​ コンポーネントをアプリケーション XML に追加します。 2. `correlationIdGeneratorExpression`​ 属性を設定し、相関 ID を生成する式を指定します。 ```xml ```
使用しているアルゴリズムでは 2 つの異なるイベントに対して同じ相関 ID を生成できないことを確認してください。
### [](#相関-id-ジェネレーターの設定例)相関 ID ジェネレーターの設定例 次の例では、Mule は Java ​`uuid()`​ メソッドをコールし、ダッシュ (​`-`​) をドット (​`.`​) に置き換えることで、相関 ID を生成します。 ```xml ``` フローの実行後、ロガーに次のように表示されます。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.06: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: b5a95a63.f190.4c91.880a.5b54512fa6b1\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`b5a95a63.f190.4c91.880a.5b54512fa6b1`​ が相関 ID です。 ## [](#フロー実行中の相関-id-の変更)フロー実行中の相関 ID の変更 次のような場合は、特定のスコープまたは一連の操作でイベントの相関 ID を変更することが必要になることがあります。 - `foreach`​ スコープ内でデータベースクエリの結果を処理しており、イベントを、処理中のレジスターと相関する必要がある。 - JMS メッセージキューをコンシュームしており、トレーサビリティの目的で JMS 相関 ID を使用して続行する必要がある。 これらのシナリオでは、Mule Tracing Module をインストールすることで、​`with-correlation-id`​ スコープを使用して、そのスコープの実行中に相関 ID を変更することができます。 ### [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール アプリケーションに Mule Tracing Module をインストールする手順は、次のとおりです。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ### [](#設定例)設定例 次の Mule アプリケーションを考えてみます。 ![相関 ID スコープの設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-with-correlation-id-scope.png) アプリケーション XML 設定: ```xml ``` この場合、アプリケーションでフローを実行すると、出力ログは次のようになります。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,271 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,274 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#debug-ログレベルを使用した追加の相関-id-ログの表示)DEBUG ログレベルを使用した追加の相関 ID ログの表示 相関 ID に関連する追加のログを表示する必要がある場合は、次のコードをアプリケーション XML に追加して、ログレベルを ​`DEBUG`​ に設定します。 次のように、更新されたログが表示されます。 WARN 2021-03-30 16:58:29,545 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,548 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Changing event correlationId from '4c355b30-9192-11eb-b79f-36548d51aeee' to '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' in location example/processors/2 WARN 2021-03-30 16:58:29,555 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,566 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Event with correlationId '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' going back to '4c355b30-9192-11eb-b79f-36548d51aeee' (successful execution) in location example/processors/2 WARN 2021-03-30 16:58:29,568 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#エラー処理)エラー処理 エラーが発生した場合に、エラーハンドラーで、エラーハンドラーが含まれるフローまたは Try スコープに対応する相関 ID が記録されます。次に例を示します。 ```xml ``` このシナリオでは、実行の開始時に設定された相関 ID が Mule によって記録されます。エラーにより相関 ID スコープの実行が停止するため、新しい相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) が設定されることはありません。 ただし、次の例を考えてみます。 ```xml ``` このシナリオでは、エラーハンドラーは相関 ID スコープ内で実行されるため、フローの実行後に記録された相関 ID は相関 ID スコープ内で設定された相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) になります。 ## [](#ログ内で相関-id-を識別する例)ログ内で相関 ID を識別する例 次のフローを考えてみます。 ```xml ``` 要求を受信した後、フローで次のログが生成されます。 WARN 2021-03-30 14:19:52,862 \[\[MuleRuntime\].uber.04: \[test-project-app\].example.CPU\_LITE @7a3620f2\] \[processor: example/processors/1; event: 23d22940-917c-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`23d22940-917c-11eb-9209-3c22fb13cde7`​ が相関 ID です。この ID は対応するイベントの一意の ID です。そのため、この相関 ID を含む他のログは同じイベントを参照しています。 ## [](#異なる操作から同じ相関-id-を記録する例)異なる操作から同じ相関 ID を記録する例 次のフローを考えてみます。これは前の例のフローと同じですが、​`raise-error`​ コンポーネントが含まれます。 ```xml ``` このフローの実行後に、フローで次のログが生成されます。 WARN 2021-03-30 14:27:36,045 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/1; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ERROR 2021-03-30 14:27:36,052 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/2; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Message : An error occurred. Element : example/processors/2 @ test-project-app:test-project-app.xml:16 Element DSL : Error type : APP:SOME FlowStack : at example(example/processors/2 @ test-project-app:test-project-app.xml:16) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Logger および Raise Error コンポーネントが実行されると、両方のコンポーネントで相関 ID ​`37f0f591-917d-11eb-9209-3c22fb13cde7`​ が記録されます。この相関 ID は、前の例で記録された相関 ID とは異なります。 ## [](#データベースクエリの相関-id-を設定する例)データベースクエリの相関 ID を設定する例 次の例は、データベースクエリの結果を処理している間に相関 ID を変更できるシナリオを示しています。 ![相関 ID データベースクエリの例](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-correlation-id-db-example.png) アプリケーション XML 設定: ```xml ``` この場合、データベースから取得した各レコードは ​`foreach`​ スコープ内で処理され、各反復処理の相関 ID はそのレコードの ​`orderId`​ に対応します。このシナリオでは、HTTP 要求操作中に問題が発生した場合、相関 ID を使用して、エラーの原因となったレコードを追跡することができます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-event) # Correlation ID (相関 ID) Mule で新しいイベントが作成されると、イベントがフローの次のプロセッサーに送信される前に​**相関 ID**​ と呼ばれる一意の識別子文字列が生成されます。この ID を使用すると、異なるログエントリを特定の実行と相関することができます。 相関 ID を使用して、問題や未処理のエラーの原因となったイベントのすべての履歴を把握することができます (すべてのエラーに、エラーをトリガーしたイベントの相関 ID が含まれます)。また、相関 ID を知ることで、ヒープダンプのメモリ分析を用意に行うことができます。 相関 ID を取得するため、Mule ではまずソースメッセージ (X-CORRELATION-ID ヘッダーを持つ JMS メッセージや HTTP リスナー) に相関 ID があるかどうかが確認されます。ソースで相関 ID が設定されていない場合、Mule で相関 ID ジェネレーターを使用して相関 ID が生成されます。 ## [](#相関-id-ジェネレーターの変更)相関 ID ジェネレーターの変更 相関 ID ジェネレーターに変更を加えることはお勧めしませんが、次のような場合、イベントの相関 ID を書式設定することが必要になることがあります。 - 会社に相関 ID に関する独自の標準または形式がある。 - 外部システムの相関 ID の長さが Mule の相関 ID とは異なるため、それらの互換性がなく、トレースできない。 Mule での相関 ID の生成方法を変更する手順は、次のとおりです。 1. ``​ コンポーネントをアプリケーション XML に追加します。 2. `correlationIdGeneratorExpression`​ 属性を設定し、相関 ID を生成する式を指定します。 ```xml ```
使用しているアルゴリズムでは 2 つの異なるイベントに対して同じ相関 ID を生成できないことを確認してください。
### [](#相関-id-ジェネレーターの設定例)相関 ID ジェネレーターの設定例 次の例では、Mule は Java ​`uuid()`​ メソッドをコールし、ダッシュ (​`-`​) をドット (​`.`​) に置き換えることで、相関 ID を生成します。 ```xml ``` フローの実行後、ロガーに次のように表示されます。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.06: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: b5a95a63.f190.4c91.880a.5b54512fa6b1\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`b5a95a63.f190.4c91.880a.5b54512fa6b1`​ が相関 ID です。 ## [](#フロー実行中の相関-id-の変更)フロー実行中の相関 ID の変更 次のような場合は、特定のスコープまたは一連の操作でイベントの相関 ID を変更することが必要になることがあります。 - `foreach`​ スコープ内でデータベースクエリの結果を処理しており、イベントを、処理中のレジスターと相関する必要がある。 - JMS メッセージキューをコンシュームしており、トレーサビリティの目的で JMS 相関 ID を使用して続行する必要がある。 これらのシナリオでは、Mule Tracing Module をインストールすることで、​`with-correlation-id`​ スコープを使用して、そのスコープの実行中に相関 ID を変更することができます。 ### [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール アプリケーションに Mule Tracing Module をインストールする手順は、次のとおりです。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ### [](#設定例)設定例 次の Mule アプリケーションを考えてみます。 ![相関 ID スコープの設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-with-correlation-id-scope.png) アプリケーション XML 設定: ```xml ``` この場合、アプリケーションでフローを実行すると、出力ログは次のようになります。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,271 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,274 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#debug-ログレベルを使用した追加の相関-id-ログの表示)DEBUG ログレベルを使用した追加の相関 ID ログの表示 相関 ID に関連する追加のログを表示する必要がある場合は、次のコードをアプリケーション XML に追加して、ログレベルを ​`DEBUG`​ に設定します。 次のように、更新されたログが表示されます。 WARN 2021-03-30 16:58:29,545 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,548 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Changing event correlationId from '4c355b30-9192-11eb-b79f-36548d51aeee' to '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' in location example/processors/2 WARN 2021-03-30 16:58:29,555 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,566 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Event with correlationId '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' going back to '4c355b30-9192-11eb-b79f-36548d51aeee' (successful execution) in location example/processors/2 WARN 2021-03-30 16:58:29,568 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#エラー処理)エラー処理 エラーが発生した場合に、エラーハンドラーで、エラーハンドラーが含まれるフローまたは Try スコープに対応する相関 ID が記録されます。次に例を示します。 ```xml ``` このシナリオでは、実行の開始時に設定された相関 ID が Mule によって記録されます。エラーにより相関 ID スコープの実行が停止するため、新しい相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) が設定されることはありません。 ただし、次の例を考えてみます。 ```xml ``` このシナリオでは、エラーハンドラーは相関 ID スコープ内で実行されるため、フローの実行後に記録された相関 ID は相関 ID スコープ内で設定された相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) になります。 ## [](#ログ内で相関-id-を識別する例)ログ内で相関 ID を識別する例 次のフローを考えてみます。 ```xml ``` 要求を受信した後、フローで次のログが生成されます。 WARN 2021-03-30 14:19:52,862 \[\[MuleRuntime\].uber.04: \[test-project-app\].example.CPU\_LITE @7a3620f2\] \[processor: example/processors/1; event: 23d22940-917c-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`23d22940-917c-11eb-9209-3c22fb13cde7`​ が相関 ID です。この ID は対応するイベントの一意の ID です。そのため、この相関 ID を含む他のログは同じイベントを参照しています。 ## [](#異なる操作から同じ相関-id-を記録する例)異なる操作から同じ相関 ID を記録する例 次のフローを考えてみます。これは前の例のフローと同じですが、​`raise-error`​ コンポーネントが含まれます。 ```xml ``` このフローの実行後に、フローで次のログが生成されます。 WARN 2021-03-30 14:27:36,045 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/1; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ERROR 2021-03-30 14:27:36,052 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/2; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Message : An error occurred. Element : example/processors/2 @ test-project-app:test-project-app.xml:16 Element DSL : Error type : APP:SOME FlowStack : at example(example/processors/2 @ test-project-app:test-project-app.xml:16) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Logger および Raise Error コンポーネントが実行されると、両方のコンポーネントで相関 ID ​`37f0f591-917d-11eb-9209-3c22fb13cde7`​ が記録されます。この相関 ID は、前の例で記録された相関 ID とは異なります。 ## [](#データベースクエリの相関-id-を設定する例)データベースクエリの相関 ID を設定する例 次の例は、データベースクエリの結果を処理している間に相関 ID を変更できるシナリオを示しています。 ![相関 ID データベースクエリの例](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-correlation-id-db-example.png) アプリケーション XML 設定: ```xml ``` この場合、データベースから取得した各レコードは ​`foreach`​ スコープ内で処理され、各反復処理の相関 ID はそのレコードの ​`orderId`​ に対応します。このシナリオでは、HTTP 要求操作中に問題が発生した場合、相関 ID を使用して、エラーの原因となったレコードを追跡することができます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-event) # Correlation ID (相関 ID) Mule で新しいイベントが作成されると、イベントがフローの次のプロセッサーに送信される前に​**相関 ID**​ と呼ばれる一意の識別子文字列が生成されます。この ID を使用すると、異なるログエントリを特定の実行と相関することができます。 相関 ID を使用して、問題や未処理のエラーの原因となったイベントのすべての履歴を把握することができます (すべてのエラーに、エラーをトリガーしたイベントの相関 ID が含まれます)。また、相関 ID を知ることで、ヒープダンプのメモリ分析を用意に行うことができます。 相関 ID を取得するため、Mule ではまずソースメッセージ (X-CORRELATION-ID ヘッダーを持つ JMS メッセージや HTTP リスナー) に相関 ID があるかどうかが確認されます。ソースで相関 ID が設定されていない場合、Mule で相関 ID ジェネレーターを使用して相関 ID が生成されます。 ## [](#相関-id-ジェネレーターの変更)相関 ID ジェネレーターの変更 相関 ID ジェネレーターに変更を加えることはお勧めしませんが、次のような場合、イベントの相関 ID を書式設定することが必要になることがあります。 - 会社に相関 ID に関する独自の標準または形式がある。 - 外部システムの相関 ID の長さが Mule の相関 ID とは異なるため、それらの互換性がなく、トレースできない。
CloudHub 2.0 では、相関 ID ジェネレーターを有効にしていても、非公開スペースで設定された correlation-id が相関 ID ジェネレーターを上書きします。
Mule での相関 ID の生成方法を変更する手順は、次のとおりです。 1. ``​ コンポーネントをアプリケーション XML に追加します。 2. `correlationIdGeneratorExpression`​ 属性を設定し、相関 ID を生成する式を指定します。 ```xml ```
使用しているアルゴリズムでは 2 つの異なるイベントに対して同じ相関 ID を生成できないことを確認してください。
### [](#相関-id-ジェネレーターの設定例)相関 ID ジェネレーターの設定例 次の例では、Mule は Java ​`uuid()`​ メソッドをコールし、ダッシュ (​`-`​) をドット (​`.`​) に置き換えることで、相関 ID を生成します。 ```xml ``` フローの実行後、ロガーに次のように表示されます。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.06: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: b5a95a63.f190.4c91.880a.5b54512fa6b1\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`b5a95a63.f190.4c91.880a.5b54512fa6b1`​ が相関 ID です。 ## [](#フロー実行中の相関-id-の変更)フロー実行中の相関 ID の変更 次のような場合は、特定のスコープまたは一連の操作でイベントの相関 ID を変更することが必要になることがあります。 - `foreach`​ スコープ内でデータベースクエリの結果を処理しており、イベントを、処理中のレジスターと相関する必要がある。 - JMS メッセージキューをコンシュームしており、トレーサビリティの目的で JMS 相関 ID を使用して続行する必要がある。 これらのシナリオでは、Mule Tracing Module をインストールすることで、​`with-correlation-id`​ スコープを使用して、そのスコープの実行中に相関 ID を変更することができます。 ### [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール アプリケーションに Mule Tracing Module をインストールする手順は、次のとおりです。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ### [](#設定例)設定例 次の Mule アプリケーションを考えてみます。 ![相関 ID スコープの設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-with-correlation-id-scope.png) アプリケーション XML 設定: ```xml ``` この場合、アプリケーションでフローを実行すると、出力ログは次のようになります。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,271 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,274 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#debug-ログレベルを使用した追加の相関-id-ログの表示)DEBUG ログレベルを使用した追加の相関 ID ログの表示 相関 ID に関連する追加のログを表示する必要がある場合は、次のコードをアプリケーション XML に追加して、ログレベルを ​`DEBUG`​ に設定します。 次のように、更新されたログが表示されます。 WARN 2021-03-30 16:58:29,545 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,548 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Changing event correlationId from '4c355b30-9192-11eb-b79f-36548d51aeee' to '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' in location example/processors/2 WARN 2021-03-30 16:58:29,555 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,566 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Event with correlationId '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' going back to '4c355b30-9192-11eb-b79f-36548d51aeee' (successful execution) in location example/processors/2 WARN 2021-03-30 16:58:29,568 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#エラー処理)エラー処理 エラーが発生した場合に、エラーハンドラーで、エラーハンドラーが含まれるフローまたは Try スコープに対応する相関 ID が記録されます。次に例を示します。 ```xml ``` このシナリオでは、実行の開始時に設定された相関 ID が Mule によって記録されます。エラーにより相関 ID スコープの実行が停止するため、新しい相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) が設定されることはありません。 ただし、次の例を考えてみます。 ```xml ``` このシナリオでは、エラーハンドラーは相関 ID スコープ内で実行されるため、フローの実行後に記録された相関 ID は相関 ID スコープ内で設定された相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) になります。 ## [](#ログ内で相関-id-を識別する例)ログ内で相関 ID を識別する例 次のフローを考えてみます。 ```xml ``` 要求を受信した後、フローで次のログが生成されます。 WARN 2021-03-30 14:19:52,862 \[\[MuleRuntime\].uber.04: \[test-project-app\].example.CPU\_LITE @7a3620f2\] \[processor: example/processors/1; event: 23d22940-917c-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`23d22940-917c-11eb-9209-3c22fb13cde7`​ が相関 ID です。この ID は対応するイベントの一意の ID です。そのため、この相関 ID を含む他のログは同じイベントを参照しています。 ## [](#異なる操作から同じ相関-id-を記録する例)異なる操作から同じ相関 ID を記録する例 次のフローを考えてみます。これは前の例のフローと同じですが、​`raise-error`​ コンポーネントが含まれます。 ```xml ``` このフローの実行後に、フローで次のログが生成されます。 WARN 2021-03-30 14:27:36,045 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/1; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ERROR 2021-03-30 14:27:36,052 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/2; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Message : An error occurred. Element : example/processors/2 @ test-project-app:test-project-app.xml:16 Element DSL : Error type : APP:SOME FlowStack : at example(example/processors/2 @ test-project-app:test-project-app.xml:16) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Logger および Raise Error コンポーネントが実行されると、両方のコンポーネントで相関 ID ​`37f0f591-917d-11eb-9209-3c22fb13cde7`​ が記録されます。この相関 ID は、前の例で記録された相関 ID とは異なります。 ## [](#データベースクエリの相関-id-を設定する例)データベースクエリの相関 ID を設定する例 次の例は、データベースクエリの結果を処理している間に相関 ID を変更できるシナリオを示しています。 ![相関 ID データベースクエリの例](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-correlation-id-db-example.png) アプリケーション XML 設定: ```xml ``` この場合、データベースから取得した各レコードは ​`foreach`​ スコープ内で処理され、各反復処理の相関 ID はそのレコードの ​`orderId`​ に対応します。このシナリオでは、HTTP 要求操作中に問題が発生した場合、相関 ID を使用して、エラーの原因となったレコードを追跡することができます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-event) # Correlation ID (相関 ID) Mule で新しいイベントが作成されると、イベントがフローの次のプロセッサーに送信される前に​**相関 ID**​ と呼ばれる一意の識別子文字列が生成されます。この ID を使用すると、異なるログエントリを特定の実行と相関することができます。 相関 ID を使用して、問題や未処理のエラーの原因となったイベントのすべての履歴を把握することができます (すべてのエラーに、エラーをトリガーしたイベントの相関 ID が含まれます)。また、相関 ID を知ることで、ヒープダンプのメモリ分析を用意に行うことができます。 相関 ID を取得するため、Mule ではまずソースメッセージ (X-CORRELATION-ID ヘッダーを持つ JMS メッセージや HTTP リスナー) に相関 ID があるかどうかが確認されます。ソースで相関 ID が設定されていない場合、Mule で相関 ID ジェネレーターを使用して相関 ID が生成されます。 ## [](#相関-id-ジェネレーターの変更)相関 ID ジェネレーターの変更 相関 ID ジェネレーターに変更を加えることはお勧めしませんが、次のような場合、イベントの相関 ID を書式設定することが必要になることがあります。 - 会社に相関 ID に関する独自の標準または形式がある。 - 外部システムの相関 ID の長さが Mule の相関 ID とは異なるため、それらの互換性がなく、トレースできない。
CloudHub 2.0 では、相関 ID ジェネレーターを有効にしていても、非公開スペースで設定された correlation-id が相関 ID ジェネレーターを上書きします。
Mule での相関 ID の生成方法を変更する手順は、次のとおりです。 1. ``​ コンポーネントをアプリケーション XML に追加します。 2. `correlationIdGeneratorExpression`​ 属性を設定し、相関 ID を生成する式を指定します。 ```xml ```
使用しているアルゴリズムでは 2 つの異なるイベントに対して同じ相関 ID を生成できないことを確認してください。
### [](#相関-id-ジェネレーターの設定例)相関 ID ジェネレーターの設定例 次の例では、Mule は Java ​`uuid()`​ メソッドをコールし、ダッシュ (​`-`​) をドット (​`.`​) に置き換えることで、相関 ID を生成します。 ```xml ``` フローの実行後、ロガーに次のように表示されます。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.06: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: b5a95a63.f190.4c91.880a.5b54512fa6b1\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`b5a95a63.f190.4c91.880a.5b54512fa6b1`​ が相関 ID です。 ## [](#フロー実行中の相関-id-の変更)フロー実行中の相関 ID の変更 次のような場合は、特定のスコープまたは一連の操作でイベントの相関 ID を変更することが必要になることがあります。 - `foreach`​ スコープ内でデータベースクエリの結果を処理しており、イベントを、処理中のレジスターと相関する必要がある。 - JMS メッセージキューをコンシュームしており、トレーサビリティの目的で JMS 相関 ID を使用して続行する必要がある。 これらのシナリオでは、Mule Tracing Module をインストールすることで、​`with-correlation-id`​ スコープを使用して、そのスコープの実行中に相関 ID を変更することができます。 ### [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール アプリケーションに Mule Tracing Module をインストールする手順は、次のとおりです。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ### [](#設定例)設定例 次の Mule アプリケーションを考えてみます。 ![相関 ID スコープの設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-with-correlation-id-scope.png) アプリケーション XML 設定: ```xml ``` この場合、アプリケーションでフローを実行すると、出力ログは次のようになります。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,271 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,274 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#debug-ログレベルを使用した追加の相関-id-ログの表示)DEBUG ログレベルを使用した追加の相関 ID ログの表示 相関 ID に関連する追加のログを表示する必要がある場合は、次のコードをアプリケーション XML に追加して、ログレベルを ​`DEBUG`​ に設定します。 次のように、更新されたログが表示されます。 WARN 2021-03-30 16:58:29,545 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,548 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Changing event correlationId from '4c355b30-9192-11eb-b79f-36548d51aeee' to '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' in location example/processors/2 WARN 2021-03-30 16:58:29,555 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,566 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Event with correlationId '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' going back to '4c355b30-9192-11eb-b79f-36548d51aeee' (successful execution) in location example/processors/2 WARN 2021-03-30 16:58:29,568 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#エラー処理)エラー処理 エラーが発生した場合に、エラーハンドラーで、エラーハンドラーが含まれるフローまたは Try スコープに対応する相関 ID が記録されます。次に例を示します。 ```xml ``` このシナリオでは、実行の開始時に設定された相関 ID が Mule によって記録されます。エラーにより相関 ID スコープの実行が停止するため、新しい相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) が設定されることはありません。 ただし、次の例を考えてみます。 ```xml ``` このシナリオでは、エラーハンドラーは相関 ID スコープ内で実行されるため、フローの実行後に記録された相関 ID は相関 ID スコープ内で設定された相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) になります。 ## [](#ログ内で相関-id-を識別する例)ログ内で相関 ID を識別する例 次のフローを考えてみます。 ```xml ``` 要求を受信した後、フローで次のログが生成されます。 WARN 2021-03-30 14:19:52,862 \[\[MuleRuntime\].uber.04: \[test-project-app\].example.CPU\_LITE @7a3620f2\] \[processor: example/processors/1; event: 23d22940-917c-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`23d22940-917c-11eb-9209-3c22fb13cde7`​ が相関 ID です。この ID は対応するイベントの一意の ID です。そのため、この相関 ID を含む他のログは同じイベントを参照しています。 ## [](#異なる操作から同じ相関-id-を記録する例)異なる操作から同じ相関 ID を記録する例 次のフローを考えてみます。これは前の例のフローと同じですが、​`raise-error`​ コンポーネントが含まれます。 ```xml ``` このフローの実行後に、フローで次のログが生成されます。 WARN 2021-03-30 14:27:36,045 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/1; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ERROR 2021-03-30 14:27:36,052 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/2; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Message : An error occurred. Element : example/processors/2 @ test-project-app:test-project-app.xml:16 Element DSL : Error type : APP:SOME FlowStack : at example(example/processors/2 @ test-project-app:test-project-app.xml:16) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Logger および Raise Error コンポーネントが実行されると、両方のコンポーネントで相関 ID ​`37f0f591-917d-11eb-9209-3c22fb13cde7`​ が記録されます。この相関 ID は、前の例で記録された相関 ID とは異なります。 ## [](#データベースクエリの相関-id-を設定する例)データベースクエリの相関 ID を設定する例 次の例は、データベースクエリの結果を処理している間に相関 ID を変更できるシナリオを示しています。 ![相関 ID データベースクエリの例](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-correlation-id-db-example.png) アプリケーション XML 設定: ```xml ``` この場合、データベースから取得した各レコードは ​`foreach`​ スコープ内で処理され、各反復処理の相関 ID はそのレコードの ​`orderId`​ に対応します。このシナリオでは、HTTP 要求操作中に問題が発生した場合、相関 ID を使用して、エラーの原因となったレコードを追跡することができます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-event) # Correlation ID (相関 ID) Mule で新しいイベントが作成されると、イベントがフローの次のプロセッサーに送信される前に​**相関 ID**​ と呼ばれる一意の識別子文字列が生成されます。この ID を使用すると、異なるログエントリを特定の実行と相関することができます。 相関 ID を使用して、問題や未処理のエラーの原因となったイベントのすべての履歴を把握することができます (すべてのエラーに、エラーをトリガーしたイベントの相関 ID が含まれます)。また、相関 ID を知ることで、ヒープダンプのメモリ分析を用意に行うことができます。 相関 ID を取得するため、Mule ではまずソースメッセージ (X-CORRELATION-ID ヘッダーを持つ JMS メッセージや HTTP リスナー) に相関 ID があるかどうかが確認されます。ソースで相関 ID が設定されていない場合、Mule で相関 ID ジェネレーターを使用して相関 ID が生成されます。 ## [](#相関-id-ジェネレーターの変更)相関 ID ジェネレーターの変更 相関 ID ジェネレーターに変更を加えることはお勧めしませんが、次のような場合、イベントの相関 ID を書式設定することが必要になることがあります。 - 会社に相関 ID に関する独自の標準または形式がある。 - 外部システムの相関 ID の長さが Mule の相関 ID とは異なるため、それらの互換性がなく、トレースできない。
CloudHub 2.0 では、相関 ID ジェネレーターを有効にしていても、非公開スペースで設定された correlation-id が相関 ID ジェネレーターを上書きします。
Mule での相関 ID の生成方法を変更する手順は、次のとおりです。 1. ``​ コンポーネントをアプリケーション XML に追加します。 2. `correlationIdGeneratorExpression`​ 属性を設定し、相関 ID を生成する式を指定します。 ```xml ```
使用しているアルゴリズムでは 2 つの異なるイベントに対して同じ相関 ID を生成できないことを確認してください。
### [](#相関-id-ジェネレーターの設定例)相関 ID ジェネレーターの設定例 次の例では、Mule は Java ​`uuid()`​ メソッドをコールし、ダッシュ (​`-`​) をドット (​`.`​) に置き換えることで、相関 ID を生成します。 ```xml ``` フローの実行後、ロガーに次のように表示されます。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.06: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: b5a95a63.f190.4c91.880a.5b54512fa6b1\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`b5a95a63.f190.4c91.880a.5b54512fa6b1`​ が相関 ID です。 ## [](#フロー実行中の相関-id-の変更)フロー実行中の相関 ID の変更 次のような場合は、特定のスコープまたは一連の操作でイベントの相関 ID を変更することが必要になることがあります。 - `foreach`​ スコープ内でデータベースクエリの結果を処理しており、イベントを、処理中のレジスターと相関する必要がある。 - JMS メッセージキューをコンシュームしており、トレーサビリティの目的で JMS 相関 ID を使用して続行する必要がある。 これらのシナリオでは、Mule Tracing Module をインストールすることで、​`with-correlation-id`​ スコープを使用して、そのスコープの実行中に相関 ID を変更することができます。 ### [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール アプリケーションに Mule Tracing Module をインストールする手順は、次のとおりです。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ### [](#設定例)設定例 次の Mule アプリケーションを考えてみます。 ![相関 ID スコープ設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-with-correlation-id-scope.png) アプリケーション XML 設定: ```xml ``` この場合、アプリケーションでフローを実行すると、出力ログは次のようになります。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,271 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,274 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#debug-ログレベルを使用した追加の相関-id-ログの表示)DEBUG ログレベルを使用した追加の相関 ID ログの表示 相関 ID に関連する追加のログを表示する必要がある場合は、次のコードをアプリケーション XML に追加して、ログレベルを ​`DEBUG`​ に設定します。 次のように、更新されたログが表示されます。 WARN 2021-03-30 16:58:29,545 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,548 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Changing event correlationId from '4c355b30-9192-11eb-b79f-36548d51aeee' to '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' in location example/processors/2 WARN 2021-03-30 16:58:29,555 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,566 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Event with correlationId '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' going back to '4c355b30-9192-11eb-b79f-36548d51aeee' (successful execution) in location example/processors/2 WARN 2021-03-30 16:58:29,568 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#エラー処理)エラー処理 エラーが発生した場合に、エラーハンドラーで、エラーハンドラーが含まれるフローまたは Try スコープに対応する相関 ID が記録されます。次に例を示します。 ```xml ``` このシナリオでは、実行の開始時に設定された相関 ID が Mule によって記録されます。エラーにより相関 ID スコープの実行が停止するため、新しい相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) が設定されることはありません。 ただし、次の例を考えてみます。 ```xml ``` このシナリオでは、エラーハンドラーは相関 ID スコープ内で実行されるため、フローの実行後に記録された相関 ID は相関 ID スコープ内で設定された相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) になります。 ## [](#ログ内で相関-id-を識別する例)ログ内で相関 ID を識別する例 次のフローを考えてみます。 ```xml ``` 要求を受信した後、フローで次のログが生成されます。 WARN 2021-03-30 14:19:52,862 \[\[MuleRuntime\].uber.04: \[test-project-app\].example.CPU\_LITE @7a3620f2\] \[processor: example/processors/1; event: 23d22940-917c-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`23d22940-917c-11eb-9209-3c22fb13cde7`​ が相関 ID です。この ID は対応するイベントの一意の ID です。そのため、この相関 ID を含む他のログは同じイベントを参照しています。 ## [](#異なる操作から同じ相関-id-を記録する例)異なる操作から同じ相関 ID を記録する例 次のフローを考えてみます。これは前の例のフローと同じですが、​`raise-error`​ コンポーネントが含まれます。 ```xml ``` このフローの実行後に、フローで次のログが生成されます。 WARN 2021-03-30 14:27:36,045 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/1; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ERROR 2021-03-30 14:27:36,052 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/2; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Message : An error occurred. Element : example/processors/2 @ test-project-app:test-project-app.xml:16 Element DSL : Error type : APP:SOME FlowStack : at example(example/processors/2 @ test-project-app:test-project-app.xml:16) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Logger および Raise Error コンポーネントが実行されると、両方のコンポーネントで相関 ID ​`37f0f591-917d-11eb-9209-3c22fb13cde7`​ が記録されます。この相関 ID は、前の例で記録された相関 ID とは異なります。 ## [](#データベースクエリの相関-id-を設定する例)データベースクエリの相関 ID を設定する例 次の例は、データベースクエリの結果を処理している間に相関 ID を変更できるシナリオを示しています。 ![Select、For Each、Logger などのコンポーネントが含まれる、相関 ID データベースクエリが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-correlation-id-db-example.png) アプリケーション XML 設定: ```xml ``` この場合、データベースから取得した各レコードは ​`foreach`​ スコープ内で処理され、各反復処理の相関 ID はそのレコードの ​`orderId`​ に対応します。このシナリオでは、HTTP 要求操作中に問題が発生した場合、相関 ID を使用して、エラーの原因となったレコードを追跡することができます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-event) # Correlation ID (相関 ID) Mule で新しいイベントが作成されると、イベントがフローの次のプロセッサーに送信される前に​**相関 ID**​ と呼ばれる一意の識別子文字列が生成されます。この ID を使用すると、異なるログエントリを特定の実行と相関することができます。 相関 ID を使用して、問題や未処理のエラーの原因となったイベントのすべての履歴を把握することができます (すべてのエラーに、エラーをトリガーしたイベントの相関 ID が含まれます)。また、相関 ID を知ることで、ヒープダンプのメモリ分析を用意に行うことができます。 相関 ID を取得するため、Mule ではまずソースメッセージ (X-CORRELATION-ID ヘッダーを持つ JMS メッセージや HTTP リスナー) に相関 ID があるかどうかが確認されます。ソースで相関 ID が設定されていない場合、Mule で相関 ID ジェネレーターを使用して相関 ID が生成されます。 ## [](#相関-id-ジェネレーターの変更)相関 ID ジェネレーターの変更 相関 ID ジェネレーターに変更を加えることはお勧めしませんが、次のような場合、イベントの相関 ID を書式設定することが必要になることがあります。 - 会社に相関 ID に関する独自の標準または形式がある。 - 外部システムの相関 ID の長さが Mule の相関 ID とは異なるため、それらの互換性がなく、トレースできない。
CloudHub 2.0 では、相関 ID ジェネレーターを有効にしていても、非公開スペースで設定された correlation-id が相関 ID ジェネレーターを上書きします。
Mule での相関 ID の生成方法を変更する手順は、次のとおりです。 1. ``​ コンポーネントをアプリケーション XML に追加します。 2. `correlationIdGeneratorExpression`​ 属性を設定し、相関 ID を生成する式を指定します。 ```xml ```
使用しているアルゴリズムでは 2 つの異なるイベントに対して同じ相関 ID を生成できないことを確認してください。
### [](#相関-id-ジェネレーターの設定例)相関 ID ジェネレーターの設定例 次の例では、Mule は Java ​`uuid()`​ メソッドをコールし、ダッシュ (​`-`​) をドット (​`.`​) に置き換えることで、相関 ID を生成します。 ```xml ``` フローの実行後、ロガーに次のように表示されます。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.06: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: b5a95a63.f190.4c91.880a.5b54512fa6b1\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`b5a95a63.f190.4c91.880a.5b54512fa6b1`​ が相関 ID です。 ## [](#フロー実行中の相関-id-の変更)フロー実行中の相関 ID の変更 次のような場合は、特定のスコープまたは一連の操作でイベントの相関 ID を変更することが必要になることがあります。 - `foreach`​ スコープ内でデータベースクエリの結果を処理しており、イベントを、処理中のレジスターと相関する必要がある。 - JMS メッセージキューをコンシュームしており、トレーサビリティの目的で JMS 相関 ID を使用して続行する必要がある。 これらのシナリオでは、Mule Tracing Module をインストールすることで、​`with-correlation-id`​ スコープを使用して、そのスコープの実行中に相関 ID を変更することができます。 ### [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール アプリケーションに Mule Tracing Module をインストールする手順は、次のとおりです。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ### [](#設定例)設定例 次の Mule アプリケーションを考えてみます。 ![相関 ID スコープ設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-with-correlation-id-scope.png) アプリケーション XML 設定: ```xml ``` この場合、アプリケーションでフローを実行すると、出力ログは次のようになります。 WARN 2021-03-30 16:46:11,269 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,271 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some WARN 2021-03-30 16:46:11,274 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#debug-ログレベルを使用した追加の相関-id-ログの表示)DEBUG ログレベルを使用した追加の相関 ID ログの表示 相関 ID に関連する追加のログを表示する必要がある場合は、次のコードをアプリケーション XML に追加して、ログレベルを ​`DEBUG`​ に設定します。 次のように、更新されたログが表示されます。 WARN 2021-03-30 16:58:29,545 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/1; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,548 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Changing event correlationId from '4c355b30-9192-11eb-b79f-36548d51aeee' to '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' in location example/processors/2 WARN 2021-03-30 16:58:29,555 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/2/processors/0; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee-EXAMPLE\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some DEBUG 2021-03-30 16:58:29,566 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] org.mule.runtime.module.extension.internal.runtime.operation.ImmutableProcessorChildContextChainExecutor: Event with correlationId '4c355b30-9192-11eb-b79f-36548d51aeee-EXAMPLE' going back to '4c355b30-9192-11eb-b79f-36548d51aeee' (successful execution) in location example/processors/2 WARN 2021-03-30 16:58:29,568 \[\[MuleRuntime\].uber.05: \[test-project-app\].example.CPU\_LITE @6d3b5ad\] \[processor: example/processors/3; event: bad0e5b0-9191-11eb-a0b3-36548d51aeee\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ## [](#エラー処理)エラー処理 エラーが発生した場合に、エラーハンドラーで、エラーハンドラーが含まれるフローまたは Try スコープに対応する相関 ID が記録されます。次に例を示します。 ```xml ``` このシナリオでは、実行の開始時に設定された相関 ID が Mule によって記録されます。エラーにより相関 ID スコープの実行が停止するため、新しい相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) が設定されることはありません。 ただし、次の例を考えてみます。 ```xml ``` このシナリオでは、エラーハンドラーは相関 ID スコープ内で実行されるため、フローの実行後に記録された相関 ID は相関 ID スコープ内で設定された相関 ID (​`#[correlationId ++ '-EXAMPLE']`​) になります。 ## [](#ログ内で相関-id-を識別する例)ログ内で相関 ID を識別する例 次のフローを考えてみます。 ```xml ``` 要求を受信した後、フローで次のログが生成されます。 WARN 2021-03-30 14:19:52,862 \[\[MuleRuntime\].uber.04: \[test-project-app\].example.CPU\_LITE @7a3620f2\] \[processor: example/processors/1; event: 23d22940-917c-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some この場合、値 ​`23d22940-917c-11eb-9209-3c22fb13cde7`​ が相関 ID です。この ID は対応するイベントの一意の ID です。そのため、この相関 ID を含む他のログは同じイベントを参照しています。 ## [](#異なる操作から同じ相関-id-を記録する例)異なる操作から同じ相関 ID を記録する例 次のフローを考えてみます。これは前の例のフローと同じですが、​`raise-error`​ コンポーネントが含まれます。 ```xml ``` このフローの実行後に、フローで次のログが生成されます。 WARN 2021-03-30 14:27:36,045 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/1; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: some ERROR 2021-03-30 14:27:36,052 \[\[MuleRuntime\].uber.08: \[test-project-app\].example.CPU\_LITE @19afa17\] \[processor: example/processors/2; event: 37f0f591-917d-11eb-9209-3c22fb13cde7\] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Message : An error occurred. Element : example/processors/2 @ test-project-app:test-project-app.xml:16 Element DSL : Error type : APP:SOME FlowStack : at example(example/processors/2 @ test-project-app:test-project-app.xml:16) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Logger および Raise Error コンポーネントが実行されると、両方のコンポーネントで相関 ID ​`37f0f591-917d-11eb-9209-3c22fb13cde7`​ が記録されます。この相関 ID は、前の例で記録された相関 ID とは異なります。 ## [](#データベースクエリの相関-id-を設定する例)データベースクエリの相関 ID を設定する例 次の例は、データベースクエリの結果を処理している間に相関 ID を変更できるシナリオを示しています。 ![Select、For Each、Logger などのコンポーネントが含まれる、相関 ID データベースクエリが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-correlation-id-db-example.png) アプリケーション XML 設定: ```xml ``` この場合、データベースから取得した各レコードは ​`foreach`​ スコープ内で処理され、各反復処理の相関 ID はそのレコードの ​`orderId`​ に対応します。このシナリオでは、HTTP 要求操作中に問題が発生した場合、相関 ID を使用して、エラーの原因となったレコードを追跡することができます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-event) # Custom Business Event コンポーネント Custom Business Event コンポーネント (XML ビューの ​`tracking:custom-event`​ 要素) を使用して、メタデータおよび重要業績評価指標 (KPI) をフローに追加します。次の手順に従って、コンポーネントを設定します。 1. Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ タブをクリックします。 2. **\[Custom Business Event\]**​ をフローの任意の位置にドラッグします。 3. コンポーネントのプロパティビューを開き、​**\[Display Name (表示名)\]**​ と ​**\[Event Name (イベント名)\]**​ の値を指定します。 ![custom-business-event](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-custom-business-event.png) 重要業績評価指標 (KPI) を設定して、メッセージペイロードから情報を取得することもできます。 - UI では、次の手順を実行します。 1. **\[Key Performance Indicators (重要業績指標)\]**​ 内のプラスボタン (​![2%](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/green-plus-icon.png)​) をクリックします。 2. **\[Name (名前)\]**​ と ​**\[Expression / Value (式 / 値)\]**​ を設定します。 ![business-events-kpi](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-business-events-kpi.png) - XML では、次の手順を実行します。 1. 子要素 ​`tracking:meta-data`​ を ​`tracking:custom-event`​ に追加します。 2. `tracking:meta-data`​ 内の ​`key`​ 属性と ​`value`​ 属性を設定します。 次に例を示します。 ```xml ``` KPI については、Anypoint Runtime Manager インターフェースで容易に検索できる名前を使用し、代表値を使用します (任意の Mule 式を使用できます)。
Name (名前) Expression / Value (式 / 値)

employee-id

#[payload['ID']]

employee-email

#[payload['Email']]

employee-git-id

#[payload['GITHUB_ID']]

price

700

price-after-discount

#[vars.price]

order-id

#[payload.order.header.orderID]
## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events) # Custom Business Event コンポーネント Custom Business Event コンポーネント (XML ビューの ​`tracking:custom-event`​ 要素) を使用して、メタデータおよび重要業績評価指標 (KPI) をフローに追加します。次の手順に従って、コンポーネントを設定します。 1. Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ タブをクリックします。 2. **\[Custom Business Event\]**​ をフローの任意の位置にドラッグします。 3. コンポーネントのプロパティビューを開き、​**\[Display Name (表示名)\]**​ と ​**\[Event Name (イベント名)\]**​ の値を指定します。 ![custom-business-event](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-custom-business-event.png) 重要業績評価指標 (KPI) を設定して、メッセージペイロードから情報を取得することもできます。 - UI では、次の手順を実行します。 1. **\[Key Performance Indicators (重要業績指標)\]**​ 内のプラスボタン (​![2%](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/green-plus-icon.png)​) をクリックします。 2. **\[Name (名前)\]**​ と ​**\[Expression / Value (式 / 値)\]**​ を設定します。 ![business-events-kpi](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-business-events-kpi.png) - XML では、次の手順を実行します。 1. 子要素 ​`tracking:meta-data`​ を ​`tracking:custom-event`​ に追加します。 2. `tracking:meta-data`​ 内の ​`key`​ 属性と ​`value`​ 属性を設定します。 次に例を示します。 ```xml ``` KPI については、Anypoint Runtime Manager インターフェースで容易に検索できる名前を使用し、代表値を使用します (任意の Mule 式を使用できます)。
Name (名前) Expression / Value (式 / 値)

employee-id

#[payload['ID']]

employee-email

#[payload['Email']]

employee-git-id

#[payload['GITHUB_ID']]

price

700

price-after-discount

#[vars.price]

order-id

#[payload.order.header.orderID]
## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events) # Custom Business Event コンポーネント Custom Business Event コンポーネント (XML ビューの ​`tracking:custom-event`​ 要素) を使用して、メタデータおよび重要業績評価指標 (KPI) をフローに追加します。次の手順に従って、コンポーネントを設定します。 1. Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ タブをクリックします。 2. **\[Custom Business Event\]**​ をフローの任意の位置にドラッグします。 3. コンポーネントのプロパティビューを開き、​**\[Display Name (表示名)\]**​ と ​**\[Event Name (イベント名)\]**​ の値を指定します。 ![custom-business-event](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-custom-business-event.png) 重要業績評価指標 (KPI) を設定して、メッセージペイロードから情報をキャプチャすることもできます。 - UI では、次の手順を実行します。 1. **\[Key Performance Indicators (重要業績指標)\]**​ 内のプラスボタン (​![2%](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/green-plus-icon.png)​) をクリックします。 2. **\[Name (名前)\]**​ と ​**\[Expression / Value (式 / 値)\]**​ を設定します。 ![business-events-kpi](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-business-events-kpi.png) - XML では、次の手順を実行します。 1. 子要素 ​`tracking:meta-data`​ を ​`tracking:custom-event`​ に追加します。 2. `tracking:meta-data`​ 内の ​`key`​ 属性と ​`value`​ 属性を設定します。 次に例を示します。 ```xml ``` KPI については、Anypoint Runtime Manager インターフェースで容易に検索できる名前を使用し、代表値を使用します (任意の Mule 式を使用できます)。
名前 Expression / Value (式 / 値)

employee-id

#[payload['ID']]

employee-email

#[payload['Email']]

employee-git-id

#[payload['GITHUB_ID']]

price

700

price-after-discount

#[vars.price]

order-id

#[payload.order.header.orderID]
## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events) # Custom Business Event コンポーネント Custom Business Event コンポーネント (XML ビューの ​`tracking:custom-event`​ 要素) を使用して、メタデータおよび重要業績評価指標 (KPI) をフローに追加します。次の手順に従って、コンポーネントを設定します。 1. Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ タブをクリックします。 2. **\[Custom Business Event\]**​ をフローの任意の位置にドラッグします。 3. コンポーネントのプロパティビューを開き、​**\[Display Name (表示名)\]**​ と ​**\[Event Name (イベント名)\]**​ の値を指定します。 ![custom-business-event](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-custom-business-event.png) 重要業績評価指標 (KPI) を設定して、メッセージペイロードから情報を取得することもできます。 - UI では、次の手順を実行します。 1. **\[Key Performance Indicators (重要業績指標)\]**​ 内のプラスボタン (​![2%](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/green-plus-icon.png)​) をクリックします。 2. **\[Name (名前)\]**​ と ​**\[Expression / Value (式 / 値)\]**​ を設定します。 ![business-events-kpi](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-business-events-kpi.png) - XML では、次の手順を実行します。 1. 子要素 ​`tracking:meta-data`​ を ​`tracking:custom-event`​ に追加します。 2. `tracking:meta-data`​ 内の ​`key`​ 属性と ​`value`​ 属性を設定します。 次に例を示します。 ```xml ``` KPI については、Anypoint Runtime Manager インターフェースで容易に検索できる名前を使用し、代表値を使用します (任意の Mule 式を使用できます)。
名前 Expression / Value (式 / 値)

employee-id

#[payload['ID']]

employee-email

#[payload['Email']]

employee-git-id

#[payload['GITHUB_ID']]

price

700

price-after-discount

#[vars.price]

order-id

#[payload.order.header.orderID]
## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events) # Custom Business Event コンポーネント Custom Business Event コンポーネント (XML ビューの ​`tracking:custom-event`​ 要素) を使用して、メタデータおよび重要業績評価指標 (KPI) をフローに追加します。次の手順に従って、コンポーネントを設定します。 1. Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ タブをクリックします。 2. **\[Custom Business Event\]**​ をフローの任意の位置にドラッグします。 3. コンポーネントのプロパティビューを開き、​**\[Display Name (表示名)\]**​ と ​**\[Event Name (イベント名)\]**​ の値を指定します。 ![custom-business-event](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-custom-business-event.png) 重要業績評価指標 (KPI) を設定して、メッセージペイロードから情報を取得することもできます。 - UI では、次の手順を実行します。 1. **\[Key Performance Indicators (重要業績指標)\]**​ 内のプラスボタン (​![追加アイコン](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/green-plus-icon.png)​\]) をクリックします。 2. **\[Name (名前)\]**​ と ​**\[Expression / Value (式 / 値)\]**​ を設定します。 ![business-events-kpi](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-business-events-kpi.png) - XML では、次の手順を実行します。 1. 子要素 ​`tracking:meta-data`​ を ​`tracking:custom-event`​ に追加します。 2. `tracking:meta-data`​ 内の ​`key`​ 属性と ​`value`​ 属性を設定します。 次に例を示します。 ```xml ``` KPI については、Anypoint Runtime Manager インターフェースで容易に検索できる名前を使用し、代表値を使用します (任意の Mule 式を使用できます)。
名前 Expression / Value (式 / 値)

employee-id

#[payload['ID']]

employee-email

#[payload['Email']]

employee-git-id

#[payload['GITHUB_ID']]

price

700

price-after-discount

#[vars.price]

order-id

#[payload.order.header.orderID]
## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events) # Custom Business Event コンポーネント Custom Business Event コンポーネント (XML ビューの ​`tracking:custom-event`​ 要素) を使用して、メタデータおよび重要業績評価指標 (KPI) をフローに追加します。次の手順に従って、コンポーネントを設定します。 1. Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ タブをクリックします。 2. **\[Custom Business Event\]**​ をフローの任意の位置にドラッグします。 3. コンポーネントのプロパティビューを開き、​**\[Display Name (表示名)\]**​ と ​**\[Event Name (イベント名)\]**​ の値を指定します。 ![カスタムビジネスイベントのセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-custom-business-event.png) 重要業績評価指標 (KPI) を設定して、メッセージペイロードから情報を取得することもできます。 - UI では、次の手順を実行します。 1. **\[Key Performance Indicators (重要業績指標)\]**​ 内のプラスボタン (​![追加アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/green-plus-icon.png)​\]) をクリックします。 2. **\[Name (名前)\]**​ と ​**\[Expression / Value (式 / 値)\]**​ を設定します。 ![重要業績評価指標の設定が表示されている設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-business-events-kpi.png) - XML では、次の手順を実行します。 1. 子要素 ​`tracking:meta-data`​ を ​`tracking:custom-event`​ に追加します。 2. `tracking:meta-data`​ 内の ​`key`​ 属性と ​`value`​ 属性を設定します。 次に例を示します。 ```xml ``` KPI については、Anypoint Runtime Manager インターフェースで容易に検索できる名前を使用し、代表値を使用します (任意の Mule 式を使用できます)。
名前 Expression / Value (式 / 値)

employee-id

#[payload['ID']]

employee-email

#[payload['Email']]

employee-git-id

#[payload['GITHUB_ID']]

price

700

price-after-discount

#[vars.price]

order-id

#[payload.order.header.orderID]
## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events) # Custom Business Event コンポーネント Custom Business Event コンポーネント (XML ビューの ​`tracking:custom-event`​ 要素) を使用して、メタデータおよび重要業績評価指標 (KPI) をフローに追加します。次の手順に従って、コンポーネントを設定します。 1. Anypoint Studio の ​**\[Mule Palette (Mule パレット)\]**​ タブをクリックします。 2. **\[Custom Business Event\]**​ をフローの任意の位置にドラッグします。 3. コンポーネントのプロパティビューを開き、​**\[Display Name (表示名)\]**​ と ​**\[Event Name (イベント名)\]**​ の値を指定します。 ![カスタムビジネスイベントのセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-custom-business-event.png) 重要業績評価指標 (KPI) を設定して、メッセージペイロードから情報を取得することもできます。 - UI では、次の手順を実行します。 1. **\[Key Performance Indicators (重要業績指標)\]**​ 内のプラスボタン (​![追加アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/green-plus-icon.png)​\]) をクリックします。 2. **\[Name (名前)\]**​ と ​**\[Expression / Value (式 / 値)\]**​ を設定します。 ![重要業績評価指標の設定が表示されている設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-business-events-kpi.png) - XML では、次の手順を実行します。 1. 子要素 ​`tracking:meta-data`​ を ​`tracking:custom-event`​ に追加します。 2. `tracking:meta-data`​ 内の ​`key`​ 属性と ​`value`​ 属性を設定します。 次に例を示します。 ```xml ``` KPI については、Anypoint Runtime Manager インターフェースで容易に検索できる名前を使用し、代表値を使用します (任意の Mule 式を使用できます)。
名前 Expression / Value (式 / 値)

employee-id

#[payload['ID']]

employee-email

#[payload['Email']]

employee-git-id

#[payload['GITHUB_ID']]

price

700

price-after-discount

#[vars.price]

order-id

#[payload.order.header.orderID]
## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events) # Database Connector の移行 Database Connector を Mule 3 から Mule 4 に移行する場合の主な変更点は次のとおりです。 - すべてのデータベース操作 (Select、Insert、Update、Delete など) が別の操作にリファクタリングされています。Mule 4 にはまた、新しい専用の一括操作もあります。 - DataWeave の使用: データベース操作 (Insert、Update など) は DataWeave バージョン 2 の変換をサポートしています。データベースを挿入または更新するデータセットを構築できます。メッセージの副次的影響はなく、メッセージエンリッチャーも不要になりました。 - 動的クエリと静的クエリを同様の方法で実行できます。 - 各自の操作に応じて Mule ストリーミングフレームワークが自動的に設定されます。Select ステートメントを実行し、接続の漏えいを心配することなく、結果を非同期で処理できます。 ## [](#whats_covered_here)このトピックの内容 - [データベース接続の設定](#database_configuration) - [データソース参照](#data_source_ref) - [例: コネクタの詳細設定](#connector_config_detail) - [動的クエリの移行](#database_dynamic_queries) - [大量の結果のストリーミング](#database_streaming) - [一括操作の移行](#database_operation_bulk) - [一括実行操作の移行](#database_bulk_execute) - [トランザクションのアクション](#tx_actions) - [出力対象](#output_target) ## [](#database_configuration)データベース接続の設定 Mule 3 と Mule 4 の Database Connector は、Derby、MySQL、Oracle、汎用データベースの設定をサポートしています。Mule 4 では、Microsoft SQL Server とデータソース参照接続もサポートされています。 これらの接続設定の XML が Mule 4 で変更されています。 - Mule 3: データベース要素 (​``​ など) が最上位要素です。 - Mule 4: ``​ がすべてのデータベース接続設定の最上位要素で、特定のデータベース設定が個別の ​``​ 要素にネストされます。 - Derby: `` - Microsoft SQL Server: `` - MySQL: `` - Oracle: `` - 汎用: `` - データソース参照接続: `` Mule 3 の例: Derby 接続設定 ```xml ``` 上記の Mule 3 の例の ​``​ が、下記の Mule 4 の例では ​``​ に変更され、データベースへの URL の属性が Mule 4 では ​`url`​ から ​`database`​ に変更されています。Mule 4 で、新たに ​``​ 子要素が追加されました。 Mule 4 の例: Derby 接続設定 ```xml ``` さらに、Mule 4 では、新たな ​``​ 設定 (XML 属性) を使用できます。 - `create="true|false"`​: データベースが存在しない場合に作成するかどうか。 - `subsubProtocol="directory"`​: Derby が使用する SubsubProtocol の種別。選択可能なオプションは ​`directory`​、​`memory`​、​`classpath`​、​`jar`​ です。 次のセクションでは、他のデータベースの接続設定について説明します。 ### [](#data_source_ref)データソース参照 以下のトピックで、その他のデータベース接続の Mule 4 の XML の例と、コネクタに固有の設定を示します。 - [Mule 4 の例: データソース参照](#example_data_source_db) - [Mule 4 の例: 汎用](#example_generic_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [Mule 4 の例: MySQL](#example_mysql_db) - [Mule 4 の例: Oracle JDBC データベース](#example_oracle_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [例: Microsoft SQL Server ドライバーの Maven 連動関係設定。](#example_driver) 前セクションの Derby の Mule 3 の例に、Mule 3 と Mule 4 のデータベース接続設定 (My SQL、Oracle など) の主な相違点の大半が示されています。また、データベース接続の Mule 3 から Mule 4 への主な移行パターンもわかります。 - Derby: [データベース接続の設定](#database_configuration) #### [](#example_data_source_db)Mule 4 の例: データソース参照 データソース参照を使用するには、次の手順を実行する必要があります。 1 - XML Spring Bean ファイルを作成して、​`DataSource`​ を表す Spring Bean を作成します。 datasource-spring-beans.xml ```xml ```
DataSource 実装を含む Maven 連動関係を設定する必要があります。 この例では、​org.enhydra.jdbc.standard.StandardDataSource​ に次の連動関係が必要です。

<dependency>
​<groupId>com.experlog</groupId>
​<artifactId>xapool</artifactId>
​<version>1.5.0</version>
</dependency>
2 - データソース接続を作成します。
1Mule Spring Module​ [Spring Module へのリンク] を使用して ​datasource-spring-beans.xml​ ファイルをインポートします。
2DataSource 接続を使用して DB 設定を作成し、​datasource-spring-beans.xml​ で作成された DataSource Bean の Spring Bean ID を ​dataSourceRef​ として追加します。
```xml (1) (2) ``` 以下はデータソース参照に固有の設定です。 - `dataSourceRef="my_ref_here"`​: JDBC DataSource オブジェクトへの参照。このオブジェクトは通常、Spring を使用して作成されます。XA トランザクションを使用する場合は、XADataSource オブジェクトを指定する必要があります。 #### [](#example_generic_db)Mule 4 の例: 汎用 ```xml ``` 以下は、汎用データベースに固有の設定です。 - `url="url_here"`​: データベースへの接続に使用する JDBC URL。 - `driverClassName="driver_class_name_here"`​: データベースドライバークラスの完全修飾名。
driverClassName​ パラメーターで参照されるクラスを含む Maven 連動関係は、Mule アプリケーションで設定する必要があります。
また、Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。
[データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mssql_db)Mule 4 の例: Microsoft SQL Server ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mysql_db)Mule 4 の例: MySQL ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_oracle_db)Mule 4 の例: Oracle JDBC データベース ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_driver)例: Microsoft SQL Server ドライバーの Maven 連動関係設定。 Microsoft SQL Server、MySQL、Derby、Oracle の設定にはドライバーが必要です。 ```xml com.microsoft.sqlserver mssql-jdbc 6.2.2.jre8 ```
Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。Studio を使用して自動的に設定されます。
### [](#connector_config_detail)例: コネクタの詳細設定 Mule 4 では、次の設定の子要素をデータベース接続設定 (​``​ など) で追加できます。 - [データベースのトランザクション](#db_transactions) - [トランザクションのアクション](#tx_actions) - [トランザクション分離](#tx_isolation) - [XA トランザクション](#xa_tx) - [Connection Properties (接続プロパティ)](#connection_properties) - [列の型](#column_types) - [プーリングプロファイル](#pooling_profile) - [再接続戦略](#reconnection_strategies) #### [](#db_transactions)データベースのトランザクション ##### [](#tx_isolation)トランザクション分離 トランザクションには、データベースの接続時にドライバーに設定するトランザクション分離レベルがあります。 - **NOT\_CONFIGURED**​ (デフォルト) - **READ\_COMMITTED**​ (​`transactionIsolation="READ_COMMITTED"`​) - **READ\_UNCOMMITTED**​ (​`transactionIsolation="READ_UNCOMMITTED"`​) - **REPEATABLE\_READ**​ (​`transactionIsolation="REPEATABLE_READ"`​) - **SERIALIZABLE**​ (​`transactionIsolation="SERIALIZABLE"`​) Mule 3 の例: トランザクション分離 ```xml ``` Mule 4 の例: トランザクション分離 ```xml ``` ##### [](#xa_tx)XA トランザクション **Mule 3**​ と ​**Mule 4**​ のどちらも、XA トランザクションで機能する接続を ​`useXaTransactions="true"`​ 接続設定で定義できます。 Mule 3 の例: XA トランザクション ```xml ``` Mule 4 の例: XA トランザクション ```xml ``` #### [](#connection_properties)Connection Properties (接続プロパティ) **MySQL**​ と ​**Microsoft SQL Server**​ のデータベース設定で接続プロパティ設定を指定します。これらのプロパティは JDBC 接続に、追加のプロパティとして挿入されます。 Mule 3 の例: 接続プロパティ ```xml ``` Mule 4 の例: 接続プロパティ ```xml ``` #### [](#column_types)列の型 - 列の型 (​``​): 標準以外の列の型。 #### [](#pooling_profile)プーリングプロファイル - プーリングプロファイル (​``​): 接続プーリング接続が可能な JDBC データソース。Mule 3 の接続プーリングとほぼ同じです。 #### [](#reconnection_strategies)再接続戦略 Mule 3 と Mule 4 の再接続戦略設定はよく似ています。ただし、Mule 4 ではカスタム再接続戦略を使用できません。 以下の例は、これらの設定の XML への変更点を示しています。 - **None (なし)**​: デフォルト。Mule 3 の \[Do Not Use A Reconnection Strategy (再接続戦略を使用しない)\] と同じです。 - **Standard (標準)**​: Mule 3 の \[Standard Reconnection (標準再接続)\] と同じです。どちらもオプションは、\[Frequency (ms) (頻度 (ミリ秒))\] と \[Reconnection Attempts (再接続試行回数)\] です。 - **Forever (無期限)**​: Mule 3 の \[Reconnect Forever (繰り返し再接続)\] と同じです。 Mule 3 の例: 再接続設定 ```xml ` ` ``` Mule 4 の例: 再接続設定 ```xml ``` ## [](#database_operations_overview)Database Connector の操作 - SQL クエリのテキストや入力パラメーターのクエリ - ストリーミング戦略設定 (​[大量の結果のストリーミング](#database_streaming)​を参照) - [トランザクションのアクション](#tx_actions) - クエリ設定 - エラー (DB:BAD\_SQL\_SYNTAX​、DB:QUERY\_EXECUTION​ など) のエラーマッピング - Mule 4 の属性、ペイロード、変数の入力および出力メタデータ ### [](#database_parameterized_queries)パラメーター化クエリの移行 **Mule 3**​ と ​**Mule 4**​ のどちらも、入力パラメーターはキー - 値のペアとして指定します。 このキーにセミコロン文字 (:) を付けて、名前でパラメーター値を参照します。つまり、​**Mule 3**​ で記述された SQL のパラメーター化クエリを、​**Mule 4**​ で使用するために変更する必要はありません。 SQL インジェクション攻撃を阻止するためにこのアプローチが推奨され、Mule アプリケーションの全般的なパフォーマンスを向上させる最適化をコネクタが実行できます。 #### [](#入力パラメーター)入力パラメーター - **Mule 3**​ では、各入力パラメーターが ​``​ 操作内で ​``​ 要素として定義され、この要素にパラメーター名の ​`name`​ 属性と、そのパラメーター値を保持する ​`value`​ 属性がありました。 - **Mule 4**​ では、各入力パラメーターがマップの ​``​ として定義され、キーはパラメーター名で、値はパラメーター値です。このマップは DataWeave を使用してのみ作成できます。 Mule 3 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name ``` Mule 4 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name #[ { last_name : vars.lastName } ] ``` ### [](#database_dynamic_queries)動的クエリの移行 場合によっては、WHERE 句をパラメーター化するだけでなく、クエリ自体の各部をパラメーター化しなければならないことがあります。このユースケースの例として、条件に応じてオンライン/履歴テーブルにアクセスする必要のあるクエリや、プロジェクト列を変更する必要のある複雑なクエリなどが挙げられます。 Mule 3 では、選択の概念がパラメーター化クエリと動的クエリに分割されており、この両方を同時に使用することができませんでした。動的クエリを使用するか、パラメーターを使用する利点 (SQL インジェクションの防御、PreparedStatement の最適化など) をとるかのどちらかを選択する必要がありました。また、それぞれ構文が異なるため、同じことを行うのに 2 つのやり方を学ぶ必要がありました。 他方 Mule 4 では、この新しい Database Connector のクエリ内で式を用いて、この両方の方法を同時に使用できるようになりました。 Mule 3 の例: 動的 SELECT クエリ ```xml SELECT * FROM #[flowVars.table] WHERE name = #[flowVars.name] ``` Mule 4 の例: 動的 SELECT クエリ ```xml #['SELECT * FROM $(vars.table) WHERE name = $(vars.name)'] ``` 注意点: Mule 3 の例のほうがパフォーマンスに劣り、SQL インジェクション攻撃に対して脆弱です。PreparedStatements を使用せず、クエリ全体が文字列として処理されるためです。 ## [](#database_streaming)大量の結果のストリーミング ストリーミングでは、大規模なデータベーステーブルに対するクエリ結果を処理できます。特にインテグレーションのユースケースなどでは、何万件ものレコードが返されることがあります。この解決策として優れているのがストリーミングです。 ### [](#ストリーミングの有効化)ストリーミングの有効化 **Mule 3**​ では、ストリーミングがデフォルトで無効になっているため、使用する場合は有効にする必要があります。 **Mule 4**​ では、ストリーミングが常にオンですが、ランタイムで反復可能なストリーミングを実行する戦略を設定できます。この点についての詳細は、​[ストリーミングのドキュメントページ](https://docs.mulesoft.com/jp/mule-runtime/4.3/streaming-about)​を参照してください。 TIP: 反復可能なストリーミングを無効にすると、並列処理を含め、DataWeave や他のコンポーネントでストリームを何度も処理できなくなります。 ### [](#database_operation_bulk)一括操作の移行 #### [](#一括モードの有効化)一括モードの有効化 **Mule 3**​ では、​**Insert、Update、Delete**​ 操作の ​`bulkMode="true"`​ 設定で一括機能を設定します。 **Mule 4**​ では代わりに、データベースに対する一括操作専用の Bulk Insert (​``​)、Bulk Update (​``​)、Bulk Delete (​``​) を使用します。受信したペイロードに応じて、操作が動作を変更することがなくなりました。 #### [](#一括データのコンシューム)一括データのコンシューム **Mule 3**​ の一括クエリでは、コネクタが ​``​ コンポーネントと同じように機能していました。つまり、現在のペイロード値 (通常は項目のコレクション) を取り、コレクションの値ごとに ​``​ 式を実行していました。 **Mule 4**​ では若干異なり、ペイロードをコンシュームしてコレクションの要素ごとに式を実行するのではなく、エントリのコレクションを挿入する必要があります。 ##### [](#例)例: Mule 3 の例: パラメーター化クエリを使用した選択 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) ``` Mule 4 の例: 一括操作を使用した各値の取得 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) #[[{ id: 2, name: 'George', lastName: 'Costanza' }, { id: 3, name: 'Cosmo', lastName: 'Kramer' }]] ``` ### [](#database_bulk_execute)一括実行操作の移行 Mule 3 Connector の ​``​ 操作が ​``​ 操作に置換されました。 ここで注意すべき重要な点は、Mule 3 バージョンでは ​`bulk`​ という用語を使うものの、上記の例のように、実際には一括操作ではないことです。同じ接続を使用して個別のステートメントが多数実行されますが、ステートメントがまとめて作成されるわけではありません。そのため、Mule 4 では、この操作の実態を的確に説明するために ​`execute-script`​ と呼ばれています。 Mule 4 の例: `execute-script`​ 操作の使用 ```xml update PLANET set NAME='Mercury' where POSITION=0; update PLANET set NAME='Mercury' where POSITION=4 ``` ステートメントも外部ファイルに抽出できます。 Mule 4 の例: 外部ファイルを設定した ​`execute-script`​ 操作の使用 ```xml ``` ### [](#tx_actions)トランザクションのアクション データベース操作は、トランザクション内で実行されるときに、そのトランザクションとどのようにやり取りするかを決定できます。 トランザクションの選択可能なアクションは次のとおりです。 - **ALWAYS\_JOIN** - **JOIN\_IF\_POSSIBLE** - **NOT\_SUPPORTED** Mule 3 の例: トランザクションのアクション ```xml SELECT * FROM people ``` Mule 4 の例: トランザクションのアクション ```xml SELECT * FROM people ``` ### [](#output_target)出力対象 **Mule 3**​ では、DB Connector が実行した出力を任意の対象変数に保存することができました。​**Mule 4**​ でも同様に処理できますが、若干異なります。 **Mule 3**​ で出力とされていたものは単なる実行結果であり、たとえば ​`target="#[flowVars.targetVar]"`​ と設定すると、クエリの実行が ​`targetVar`​ フロー変数に保存されていました。 **Mule 4**​ でもほぼ同じで、対象のフロー変数の名前である ​`target`​ パラメーターがありますが、これを式にすることはできません。​**Mule 4**​ の新しいパラメーターは ​`targetValue`​ で、これは操作結果に対して評価される式です。たとえば、ペイロード全体を保存する場合は ​`#[payload]`​ に、SELECT クエリの 1 行目だけを保存する場合は ​`#[payload[0]]`​ になります。 Mule 3 の例: 出力対象 ```xml SELECT * FROM People ``` Mule 4 の例: 出力対象 ```xml SELECT * from People ``` Database Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-db-connector 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Database Connector の概要](https://docs.mulesoft.com/db-connector/latest/) - [Mule 4.0 でのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.3/streaming-about)​。 # Database Connector の移行 Database Connector を Mule 3 から Mule 4 に移行する場合の主な変更点は次のとおりです。 - すべてのデータベース操作 (Select、Insert、Update、Delete など) が別の操作にリファクタリングされています。Mule 4 にはまた、新しい専用の一括操作もあります。 - DataWeave の使用: データベース操作 (Insert、Update など) は DataWeave バージョン 2 の変換をサポートしています。データベースを挿入または更新するデータセットを構築できます。メッセージの副次的影響はなく、メッセージエンリッチャーも不要になりました。 - 動的クエリと静的クエリを同様の方法で実行できます。 - 各自の操作に応じて Mule ストリーミングフレームワークが自動的に設定されます。Select ステートメントを実行し、接続の漏えいを心配することなく、結果を非同期で処理できます。 ## [](#whats_covered_here)このトピックの内容 - [データベース接続の設定](#database_configuration) - [データソース参照](#data_source_ref) - [例: Connector の詳細設定](#connector_config_detail) - [動的クエリの移行](#database_dynamic_queries) - [大量の結果のストリーミング](#database_streaming) - [一括操作の移行](#database_operation_bulk) - [一括実行操作の移行](#database_bulk_execute) - [トランザクションのアクション](#tx_actions) - [出力対象](#output_target) ## [](#database_configuration)データベース接続の設定 Mule 3 と Mule 4 の Database Connector は、Derby、MySQL、Oracle、汎用データベースの設定をサポートしています。Mule 4 では、Microsoft SQL Server とデータソース参照接続もサポートされています。 これらの接続設定の XML が Mule 4 で変更されています。 - Mule 3: データベース要素 (​``​ など) が最上位要素です。 - Mule 4: ``​ がすべてのデータベース接続設定の最上位要素で、特定のデータベース設定が個別の ​``​ 要素にネストされます。 - Derby: `` - Microsoft SQL Server: `` - MySQL: `` - Oracle: `` - 汎用: `` - データソース参照接続: `` Mule 3 の例: Derby 接続設定 ```xml ``` 上記の Mule 3 の例の ​``​ が、下記の Mule 4 の例では ​``​ に変更され、データベースへの URL の属性が Mule 4 では ​`url`​ から ​`database`​ に変更されています。Mule 4 で、新たに ​``​ 子要素が追加されました。 Mule 4 の例: Derby 接続設定 ```xml ``` さらに、Mule 4 では、新たな ​``​ 設定 (XML 属性) を使用できます。 - `create="true|false"`​: データベースが存在しない場合に作成するかどうか。 - `subsubProtocol="directory"`​: Derby が使用する SubsubProtocol の種別。選択可能なオプションは ​`directory`​、​`memory`​、​`classpath`​、​`jar`​ です。 次のセクションでは、他のデータベースの接続設定について説明します。 ### [](#data_source_ref)データソース参照 以下のトピックで、その他のデータベース接続の Mule 4 の XML の例と、コネクタに固有の設定を示します。 - [Mule 4 の例: データソース参照](#example_data_source_db) - [Mule 4 の例: 汎用](#example_generic_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [Mule 4 の例: MySQL](#example_mysql_db) - [Mule 4 の例: Oracle JDBC データベース](#example_oracle_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [例: Microsoft SQL Server ドライバーの Maven 連動関係設定。](#example_driver) 前セクションの Derby の Mule 3 の例に、Mule 3 と Mule 4 のデータベース接続設定 (My SQL、Oracle など) の主な相違点の大半が示されています。また、データベース接続の Mule 3 から Mule 4 への主な移行パターンもわかります。 - Derby: [データベース接続の設定](#database_configuration) #### [](#example_data_source_db)Mule 4 の例: データソース参照 データソース参照を使用するには、次の手順を実行する必要があります。 1 - XML Spring Bean ファイルを作成して、​`DataSource`​ を表す Spring Bean を作成します。 datasource-spring-beans.xml ```xml ```
DataSource 実装を含む Maven 連動関係を設定する必要があります。 この例では、​org.enhydra.jdbc.standard.StandardDataSource​ に次の連動関係が必要です。

<dependency>
​<groupId>com.experlog</groupId>
​<artifactId>xapool</artifactId>
​<version>1.5.0</version>
</dependency>
2 - データソース接続を作成します。
1Mule Spring Module​ [Spring Module へのリンク] を使用して ​datasource-spring-beans.xml​ ファイルをインポートします。
2DataSource 接続を使用して DB 設定を作成し、​datasource-spring-beans.xml​ で作成された DataSource Bean の Spring Bean ID を ​dataSourceRef​ として追加します。
```xml (1) (2) ``` 以下はデータソース参照に固有の設定です。 - `dataSourceRef="my_ref_here"`​: JDBC DataSource オブジェクトへの参照。このオブジェクトは通常、Spring を使用して作成されます。XA トランザクションを使用する場合は、XADataSource オブジェクトを指定する必要があります。 #### [](#example_generic_db)Mule 4 の例: 汎用 ```xml ``` 以下は、汎用データベースに固有の設定です。 - `url="url_here"`​: データベースへの接続に使用する JDBC URL。 - `driverClassName="driver_class_name_here"`​: データベースドライバークラスの完全修飾名。
driverClassName​ パラメーターで参照されるクラスを含む Maven 連動関係は、Mule アプリケーションで設定する必要があります。
また、Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。
[データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mssql_db)Mule 4 の例: Microsoft SQL Server ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mysql_db)Mule 4 の例: MySQL ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_oracle_db)Mule 4 の例: Oracle JDBC データベース ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_driver)例: Microsoft SQL Server ドライバーの Maven 連動関係設定。 Microsoft SQL Server、MySQL、Derby、Oracle の設定にはドライバーが必要です。 ```xml com.microsoft.sqlserver mssql-jdbc 6.2.2.jre8 ```
Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。Studio を使用して自動的に設定されます。
### [](#connector_config_detail)例: Connector の詳細設定 Mule 4 では、次の設定の子要素をデータベース接続設定 (​``​ など) で追加できます。 - [データベースのトランザクション](#db_transactions) - [トランザクションのアクション](#tx_actions) - [トランザクション分離](#tx_isolation) - [XA トランザクション](#xa_tx) - [Connection Properties (接続プロパティ)](#connection_properties) - [列の型](#column_types) - [Pooling Profile (プーリングプロファイル)](#pooling_profile) - [再接続戦略](#reconnection_strategies) #### [](#db_transactions)データベースのトランザクション ##### [](#tx_isolation)トランザクション分離 トランザクションには、データベースの接続時にドライバーに設定するトランザクション分離レベルがあります。 - **NOT\_CONFIGURED**​ (デフォルト) - **READ\_COMMITTED**​ (​`transactionIsolation="READ_COMMITTED"`​) - **READ\_UNCOMMITTED**​ (​`transactionIsolation="READ_UNCOMMITTED"`​) - **REPEATABLE\_READ**​ (​`transactionIsolation="REPEATABLE_READ"`​) - **SERIALIZABLE**​ (​`transactionIsolation="SERIALIZABLE"`​) Mule 3 の例: トランザクション分離 ```xml ``` Mule 4 の例: トランザクション分離 ```xml ``` ##### [](#xa_tx)XA トランザクション **Mule 3**​ と ​**Mule 4**​ のどちらも、XA トランザクションで機能する接続を ​`useXaTransactions="true"`​ 接続設定で定義できます。 Mule 3 の例: XA トランザクション ```xml ``` Mule 4 の例: XA トランザクション ```xml ``` #### [](#connection_properties)Connection Properties (接続プロパティ) **MySQL**​ と ​**Microsoft SQL Server**​ のデータベース設定で接続プロパティ設定を指定します。これらのプロパティは JDBC 接続に、追加のプロパティとして挿入されます。 Mule 3 の例: 接続プロパティ ```xml ``` Mule 4 の例: 接続プロパティ ```xml ``` #### [](#column_types)列の型 - 列の型 (​``​): 標準以外の列の型。 #### [](#pooling_profile)Pooling Profile (プーリングプロファイル) - プーリングプロファイル (​``​): 接続プーリング接続が可能な JDBC データソース。Mule 3 の接続プーリングとほぼ同じです。 #### [](#reconnection_strategies)再接続戦略 Mule 3 と Mule 4 の再接続戦略設定はよく似ています。ただし、Mule 4 ではカスタム再接続戦略を使用できません。 以下の例は、これらの設定の XML への変更点を示しています。 - **None (なし)**​: デフォルト。Mule 3 の \[Do Not Use A Reconnection Strategy (再接続戦略を使用しない)\] と同じです。 - **Standard (標準)**​: Mule 3 の \[Standard Reconnection (標準再接続)\] と同じです。どちらもオプションは、\[Frequency (ms) (頻度 (ミリ秒))\] と \[Reconnection Attempts (再接続試行回数)\] です。 - **Forever (無期限)**​: Mule 3 の \[Reconnect Forever (繰り返し再接続)\] と同じです。 Mule 3 の例: 再接続設定 ```xml ` ` ``` Mule 4 の例: 再接続設定 ```xml ``` ## [](#database_operations_overview)Database Connector の操作 - SQL クエリのテキストや入力パラメーターのクエリ - ストリーミング戦略設定 (​[大量の結果のストリーミング](#database_streaming)​を参照) - [トランザクションのアクション](#tx_actions) - クエリ設定 - エラー (DB:BAD\_SQL\_SYNTAX​、DB:QUERY\_EXECUTION​ など) のエラーマッピング - Mule 4 の属性、ペイロード、変数の入力および出力メタデータ ### [](#database_parameterized_queries)パラメーター化クエリの移行 **Mule 3**​ と ​**Mule 4**​ のどちらも、入力パラメーターはキー - 値のペアとして指定します。 このキーにセミコロン文字 (:) を付けて、名前でパラメーター値を参照します。つまり、​**Mule 3**​ で記述された SQL のパラメーター化クエリを、​**Mule 4**​ で使用するために変更する必要はありません。 SQL インジェクション攻撃を阻止するためにこのアプローチが推奨され、Mule アプリケーションの全般的なパフォーマンスを向上させる最適化をコネクタが実行できます。 #### [](#入力パラメーター)入力パラメーター - **Mule 3**​ では、各入力パラメーターが ​``​ 操作内で ​``​ 要素として定義され、この要素にパラメーター名の ​`name`​ 属性と、そのパラメーター値を保持する ​`value`​ 属性がありました。 - **Mule 4**​ では、各入力パラメーターがマップの ​``​ として定義され、キーはパラメーター名で、値はパラメーター値です。このマップは DataWeave を使用してのみ作成できます。 Mule 3 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name ``` Mule 4 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name #[ { last_name : vars.lastName } ] ``` ### [](#database_dynamic_queries)動的クエリの移行 場合によっては、WHERE 句をパラメーター化するだけでなく、クエリ自体の各部をパラメーター化しなければならないことがあります。このユースケースの例として、条件に応じてオンライン/履歴テーブルにアクセスする必要のあるクエリや、プロジェクト列を変更する必要のある複雑なクエリなどが挙げられます。 Mule 3 では、選択の概念がパラメーター化クエリと動的クエリに分割されており、この両方を同時に使用することができませんでした。動的クエリを使用するか、パラメーターを使用する利点 (SQL インジェクションの防御、PreparedStatement の最適化など) をとるかのどちらかを選択する必要がありました。また、それぞれ構文が異なるため、同じことを行うのに 2 つのやり方を学ぶ必要がありました。 他方 Mule 4 では、この新しい Database Connector のクエリ内で式を用いて、この両方の方法を同時に使用できるようになりました。 Mule 3 の例: 動的 SELECT クエリ ```xml SELECT * FROM #[flowVars.table] WHERE name = #[flowVars.name] ``` Mule 4 の例: 動的 SELECT クエリ ```xml #['SELECT * FROM $(vars.table) WHERE name = $(vars.name)'] ``` 注意点: Mule 3 の例のほうがパフォーマンスに劣り、SQL インジェクション攻撃に対して脆弱です。PreparedStatements を使用せず、クエリ全体が文字列として処理されるためです。 ## [](#database_streaming)大量の結果のストリーミング ストリーミングでは、大規模なデータベーステーブルに対するクエリ結果を処理できます。特にインテグレーションのユースケースなどでは、何万件ものレコードが返されることがあります。この解決策として優れているのがストリーミングです。 ### [](#ストリーミングの有効化)ストリーミングの有効化 **Mule 3**​ では、ストリーミングがデフォルトで無効になっているため、使用する場合は有効にする必要があります。 **Mule 4**​ では、ストリーミングが常にオンですが、ランタイムで反復可能なストリーミングを実行する戦略を設定できます。この点についての詳細は、​[ストリーミングのドキュメントページ](https://docs.mulesoft.com/jp/mule-runtime/4.4/streaming-about)​を参照してください。 TIP: 反復可能なストリーミングを無効にすると、並列処理を含め、DataWeave や他のコンポーネントでストリームを何度も処理できなくなります。 ### [](#database_operation_bulk)一括操作の移行 #### [](#一括モードの有効化)一括モードの有効化 **Mule 3**​ では、​**Insert、Update、Delete**​ 操作の ​`bulkMode="true"`​ 設定で一括機能を設定します。 **Mule 4**​ では代わりに、データベースに対する一括操作専用の Bulk Insert (​``​)、Bulk Update (​``​)、Bulk Delete (​``​) を使用します。受信したペイロードに応じて、操作が動作を変更することがなくなりました。 #### [](#一括データのコンシューム)一括データのコンシューム **Mule 3**​ の一括クエリでは、コネクタが ​``​ コンポーネントと同じように機能していました。つまり、現在のペイロード値 (通常は項目のコレクション) を取り、コレクションの値ごとに ​``​ 式を実行していました。 **Mule 4**​ では若干異なり、ペイロードをコンシュームしてコレクションの要素ごとに式を実行するのではなく、エントリのコレクションを挿入する必要があります。 ##### [](#例)例: Mule 3 の例: パラメーター化クエリを使用した選択 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) ``` Mule 4 の例: 一括操作を使用した各値の取得 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) #[[{ id: 2, name: 'George', lastName: 'Costanza' }, { id: 3, name: 'Cosmo', lastName: 'Kramer' }]] ``` ### [](#database_bulk_execute)一括実行操作の移行 Mule 3 Connector の ​``​ 操作が ​``​ 操作に置換されました。 ここで注意すべき重要な点は、Mule 3 バージョンでは ​`bulk`​ という用語を使うものの、上記の例のように、実際には一括操作ではないことです。同じ接続を使用して個別のステートメントが多数実行されますが、ステートメントがまとめて作成されるわけではありません。そのため、Mule 4 では、この操作の実態を的確に説明するために ​`execute-script`​ と呼ばれています。 Mule 4 の例: `execute-script`​ 操作の使用 ```xml update PLANET set NAME='Mercury' where POSITION=0; update PLANET set NAME='Mercury' where POSITION=4 ``` ステートメントも外部ファイルに抽出できます。 Mule 4 の例: 外部ファイルを設定した ​`execute-script`​ 操作の使用 ```xml ``` ### [](#tx_actions)トランザクションのアクション データベース操作は、トランザクション内で実行されるときに、そのトランザクションとどのようにやり取りするかを決定できます。 トランザクションの選択可能なアクションは次のとおりです。 - **ALWAYS\_JOIN** - **JOIN\_IF\_POSSIBLE** - **NOT\_SUPPORTED** Mule 3 の例: トランザクションのアクション ```xml SELECT * FROM people ``` Mule 4 の例: トランザクションのアクション ```xml SELECT * FROM people ``` ### [](#output_target)出力対象 **Mule 3**​ では、DB Connector が実行した出力を任意の対象変数に保存することができました。​**Mule 4**​ でも同様に処理できますが、若干異なります。 **Mule 3**​ で出力とされていたものは単なる実行結果であり、たとえば ​`target="#[flowVars.targetVar]"`​ と設定すると、クエリの実行が ​`targetVar`​ フロー変数に保存されていました。 **Mule 4**​ でもほぼ同じで、対象のフロー変数の名前である ​`target`​ パラメーターがありますが、これを式にすることはできません。​**Mule 4**​ の新しいパラメーターは ​`targetValue`​ で、これは操作結果に対して評価される式です。たとえば、ペイロード全体を保存する場合は ​`#[payload]`​ に、SELECT クエリの 1 行目だけを保存する場合は ​`#[payload[0]]`​ になります。 Mule 3 の例: 出力対象 ```xml SELECT * FROM People ``` Mule 4 の例: 出力対象 ```xml SELECT * from People ``` Database Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-db-connector 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Database Connector の概要](https://docs.mulesoft.com/db-connector/latest/) - [Mule 4.0 でのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.4/streaming-about)​。 # Database Connector の移行 Database Connector を Mule 3 から Mule 4 に移行する場合の主な変更点は次のとおりです。 - すべてのデータベース操作 (Select、Insert、Update、Delete など) が別の操作にリファクタリングされています。Mule 4 にはまた、新しい専用の一括操作もあります。 - DataWeave の使用: データベース操作 (Insert、Update など) は DataWeave バージョン 2 の変換をサポートしています。データベースを挿入または更新するデータセットを構築できます。メッセージの副次的影響はなく、メッセージエンリッチャーも不要になりました。 - 動的クエリと静的クエリを同様の方法で実行できます。 - 各自の操作に応じて Mule ストリーミングフレームワークが自動的に設定されます。Select ステートメントを実行し、接続の漏えいを心配することなく、結果を非同期で処理できます。 ## [](#whats_covered_here)このトピックの内容 - [データベース接続の設定](#database_configuration) - [データソース参照](#data_source_ref) - [例: コネクタの詳細設定](#connector_config_detail) - [動的クエリの移行](#database_dynamic_queries) - [大量の結果のストリーミング](#database_streaming) - [一括操作の移行](#database_operation_bulk) - [一括実行操作の移行](#database_bulk_execute) - [トランザクションのアクション](#tx_actions) - [出力対象](#output_target) ## [](#database_configuration)データベース接続の設定 Mule 3 と Mule 4 の Database Connector は、Derby、MySQL、Oracle、汎用データベースの設定をサポートしています。Mule 4 では、Microsoft SQL Server とデータソース参照接続もサポートされています。 これらの接続設定の XML が Mule 4 で変更されています。 - Mule 3: データベース要素 (​``​ など) が最上位要素です。 - Mule 4: ``​ がすべてのデータベース接続設定の最上位要素で、特定のデータベース設定が個別の ​``​ 要素にネストされます。 - Derby: `` - Microsoft SQL Server: `` - MySQL: `` - Oracle: `` - 汎用: `` - データソース参照接続: `` Mule 3 の例: Derby 接続設定 ```xml ``` 上記の Mule 3 の例の ​``​ が、下記の Mule 4 の例では ​``​ に変更され、データベースへの URL の属性が Mule 4 では ​`url`​ から ​`database`​ に変更されています。Mule 4 で、新たに ​``​ 子要素が追加されました。 Mule 4 の例: Derby 接続設定 ```xml ``` さらに、Mule 4 では、新たな ​``​ 設定 (XML 属性) を使用できます。 - `create="true|false"`​: データベースが存在しない場合に作成するかどうか。 - `subsubProtocol="directory"`​: Derby が使用する SubsubProtocol の種別。選択可能なオプションは ​`directory`​、​`memory`​、​`classpath`​、​`jar`​ です。 次のセクションでは、他のデータベースの接続設定について説明します。 ### [](#data_source_ref)データソース参照 以下のトピックで、その他のデータベース接続の Mule 4 の XML の例と、コネクタに固有の設定を示します。 - [Mule 4 の例: データソース参照](#example_data_source_db) - [Mule 4 の例: 汎用](#example_generic_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [Mule 4 の例: MySQL](#example_mysql_db) - [Mule 4 の例: Oracle JDBC データベース](#example_oracle_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [例: Microsoft SQL Server ドライバーの Maven 連動関係設定。](#example_driver) 前セクションの Derby の Mule 3 の例に、Mule 3 と Mule 4 のデータベース接続設定 (My SQL、Oracle など) の主な相違点の大半が示されています。また、データベース接続の Mule 3 から Mule 4 への主な移行パターンもわかります。 - Derby: [データベース接続の設定](#database_configuration) #### [](#example_data_source_db)Mule 4 の例: データソース参照 データソース参照を使用するには、次の手順を実行する必要があります。 1 - XML Spring Bean ファイルを作成して、​`DataSource`​ を表す Spring Bean を作成します。 datasource-spring-beans.xml ```xml ```
DataSource 実装を含む Maven 連動関係を設定する必要があります。 この例では、​org.enhydra.jdbc.standard.StandardDataSource​ に次の連動関係が必要です。

<dependency>
​<groupId>com.experlog</groupId>
​<artifactId>xapool</artifactId>
​<version>1.5.0</version>
</dependency>
2 - データソース接続を作成します。
1Mule Spring Module​ [Spring Module へのリンク] を使用して ​datasource-spring-beans.xml​ ファイルをインポートします。
2DataSource 接続を使用して DB 設定を作成し、​datasource-spring-beans.xml​ で作成された DataSource Bean の Spring Bean ID を ​dataSourceRef​ として追加します。
```xml (1) (2) ``` 以下はデータソース参照に固有の設定です。 - `dataSourceRef="my_ref_here"`​: JDBC DataSource オブジェクトへの参照。このオブジェクトは通常、Spring を使用して作成されます。XA トランザクションを使用する場合は、XADataSource オブジェクトを指定する必要があります。 #### [](#example_generic_db)Mule 4 の例: 汎用 ```xml ``` 以下は、汎用データベースに固有の設定です。 - `url="url_here"`​: データベースへの接続に使用する JDBC URL。 - `driverClassName="driver_class_name_here"`​: データベースドライバークラスの完全修飾名。
driverClassName​ パラメーターで参照されるクラスを含む Maven 連動関係は、Mule アプリケーションで設定する必要があります。
また、Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。
[データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mssql_db)Mule 4 の例: Microsoft SQL Server ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mysql_db)Mule 4 の例: MySQL ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_oracle_db)Mule 4 の例: Oracle JDBC データベース ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_driver)例: Microsoft SQL Server ドライバーの Maven 連動関係設定。 Microsoft SQL Server、MySQL、Derby、Oracle の設定にはドライバーが必要です。 ```xml com.microsoft.sqlserver mssql-jdbc 6.2.2.jre8 ```
Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。Studio を使用して自動的に設定されます。
### [](#connector_config_detail)例: コネクタの詳細設定 Mule 4 では、次の設定の子要素をデータベース接続設定 (​``​ など) で追加できます。 - [データベースのトランザクション](#db_transactions) - [トランザクションのアクション](#tx_actions) - [トランザクション分離](#tx_isolation) - [XA トランザクション](#xa_tx) - [Connection Properties (接続プロパティ)](#connection_properties) - [列の型](#column_types) - [Pooling Profile (プーリングプロファイル)](#pooling_profile) - [再接続戦略](#reconnection_strategies) #### [](#db_transactions)データベースのトランザクション ##### [](#tx_isolation)トランザクション分離 トランザクションには、データベースの接続時にドライバーに設定するトランザクション分離レベルがあります。 - **NOT\_CONFIGURED**​ (デフォルト) - **READ\_COMMITTED**​ (​`transactionIsolation="READ_COMMITTED"`​) - **READ\_UNCOMMITTED**​ (​`transactionIsolation="READ_UNCOMMITTED"`​) - **REPEATABLE\_READ**​ (​`transactionIsolation="REPEATABLE_READ"`​) - **SERIALIZABLE**​ (​`transactionIsolation="SERIALIZABLE"`​) Mule 3 の例: トランザクション分離 ```xml ``` Mule 4 の例: トランザクション分離 ```xml ``` ##### [](#xa_tx)XA トランザクション **Mule 3**​ と ​**Mule 4**​ のどちらも、XA トランザクションで機能する接続を ​`useXaTransactions="true"`​ 接続設定で定義できます。 Mule 3 の例: XA トランザクション ```xml ``` Mule 4 の例: XA トランザクション ```xml ``` #### [](#connection_properties)Connection Properties (接続プロパティ) **MySQL**​ と ​**Microsoft SQL Server**​ のデータベース設定で接続プロパティ設定を指定します。これらのプロパティは JDBC 接続に、追加のプロパティとして挿入されます。 Mule 3 の例: 接続プロパティ ```xml ``` Mule 4 の例: 接続プロパティ ```xml ``` #### [](#column_types)列の型 - 列の型 (​``​): 標準以外の列の型。 #### [](#pooling_profile)Pooling Profile (プーリングプロファイル) - プーリングプロファイル (​``​): 接続プーリング接続が可能な JDBC データソース。Mule 3 の接続プーリングとほぼ同じです。 #### [](#reconnection_strategies)再接続戦略 Mule 3 と Mule 4 の再接続戦略設定はよく似ています。ただし、Mule 4 ではカスタム再接続戦略を使用できません。 以下の例は、これらの設定の XML への変更点を示しています。 - **None (なし)**​: デフォルト。Mule 3 の \[Do Not Use A Reconnection Strategy (再接続戦略を使用しない)\] と同じです。 - **Standard (標準)**​: Mule 3 の \[Standard Reconnection (標準再接続)\] と同じです。どちらもオプションは、\[Frequency (ms) (頻度 (ミリ秒))\] と \[Reconnection Attempts (再接続試行回数)\] です。 - **Forever (無期限)**​: Mule 3 の \[Reconnect Forever (繰り返し再接続)\] と同じです。 Mule 3 の例: 再接続設定 ```xml ` ` ``` Mule 4 の例: 再接続設定 ```xml ``` ## [](#database_operations_overview)Database Connector の操作 - SQL クエリのテキストや入力パラメーターのクエリ - ストリーミング戦略設定 (​[大量の結果のストリーミング](#database_streaming)​を参照) - [トランザクションのアクション](#tx_actions) - クエリ設定 - エラー (DB:BAD\_SQL\_SYNTAX​、DB:QUERY\_EXECUTION​ など) のエラーマッピング - Mule 4 の属性、ペイロード、変数の入力および出力メタデータ ### [](#database_parameterized_queries)パラメーター化クエリの移行 **Mule 3**​ と ​**Mule 4**​ のどちらも、入力パラメーターはキー - 値のペアとして指定します。 このキーにセミコロン文字 (:) を付けて、名前でパラメーター値を参照します。つまり、​**Mule 3**​ で記述された SQL のパラメーター化クエリを、​**Mule 4**​ で使用するために変更する必要はありません。 SQL インジェクション攻撃を阻止するためにこのアプローチが推奨され、Mule アプリケーションの全般的なパフォーマンスを向上させる最適化をコネクタが実行できます。 #### [](#入力パラメーター)入力パラメーター - **Mule 3**​ では、各入力パラメーターが ​``​ 操作内で ​``​ 要素として定義され、この要素にパラメーター名の ​`name`​ 属性と、そのパラメーター値を保持する ​`value`​ 属性がありました。 - **Mule 4**​ では、各入力パラメーターがマップの ​``​ として定義され、キーはパラメーター名で、値はパラメーター値です。このマップは DataWeave を使用してのみ作成できます。 Mule 3 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name ``` Mule 4 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name #[ { last_name : vars.lastName } ] ``` ### [](#database_dynamic_queries)動的クエリの移行 場合によっては、WHERE 句をパラメーター化するだけでなく、クエリ自体の各部をパラメーター化しなければならないことがあります。このユースケースの例として、条件に応じてオンライン/履歴テーブルにアクセスする必要のあるクエリや、プロジェクト列を変更する必要のある複雑なクエリなどが挙げられます。 Mule 3 では、選択の概念がパラメーター化クエリと動的クエリに分割されており、この両方を同時に使用することができませんでした。動的クエリを使用するか、パラメーターを使用する利点 (SQL インジェクションの防御、PreparedStatement の最適化など) をとるかのどちらかを選択する必要がありました。また、それぞれ構文が異なるため、同じことを行うのに 2 つのやり方を学ぶ必要がありました。 他方 Mule 4 では、この新しい Database Connector のクエリ内で式を用いて、この両方の方法を同時に使用できるようになりました。 Mule 3 の例: 動的 SELECT クエリ ```xml SELECT * FROM #[flowVars.table] WHERE name = #[flowVars.name] ``` Mule 4 の例: 動的 SELECT クエリ ```xml #['SELECT * FROM $(vars.table) WHERE name = $(vars.name)'] ``` 注意点: Mule 3 の例のほうがパフォーマンスに劣り、SQL インジェクション攻撃に対して脆弱です。PreparedStatements を使用せず、クエリ全体が文字列として処理されるためです。 ## [](#database_streaming)大量の結果のストリーミング ストリーミングでは、大規模なデータベーステーブルに対するクエリ結果を処理できます。特にインテグレーションのユースケースなどでは、何万件ものレコードが返されることがあります。この解決策として優れているのがストリーミングです。 ### [](#ストリーミングの有効化)ストリーミングの有効化 **Mule 3**​ では、ストリーミングがデフォルトで無効になっているため、使用する場合は有効にする必要があります。 **Mule 4**​ では、ストリーミングが常にオンですが、ランタイムで反復可能なストリーミングを実行する戦略を設定できます。この点についての詳細は、​[ストリーミングのドキュメントページ](https://docs.mulesoft.com/jp/mule-runtime/4.5/streaming-about)​を参照してください。 TIP: 反復可能なストリーミングを無効にすると、並列処理を含め、DataWeave や他のコンポーネントでストリームを何度も処理できなくなります。 ### [](#database_operation_bulk)一括操作の移行 #### [](#一括モードの有効化)一括モードの有効化 **Mule 3**​ では、​**Insert、Update、Delete**​ 操作の ​`bulkMode="true"`​ 設定で一括機能を設定します。 **Mule 4**​ では代わりに、データベースに対する一括操作専用の Bulk Insert (​``​)、Bulk Update (​``​)、Bulk Delete (​``​) を使用します。受信したペイロードに応じて、操作が動作を変更することがなくなりました。 #### [](#一括データのコンシューム)一括データのコンシューム **Mule 3**​ の一括クエリでは、コネクタが ​``​ コンポーネントと同じように機能していました。つまり、現在のペイロード値 (通常は項目のコレクション) を取り、コレクションの値ごとに ​``​ 式を実行していました。 **Mule 4**​ では若干異なり、ペイロードをコンシュームしてコレクションの要素ごとに式を実行するのではなく、エントリのコレクションを挿入する必要があります。 ##### [](#例)例: Mule 3 の例: パラメーター化クエリを使用した選択 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) ``` Mule 4 の例: 一括操作を使用した各値の取得 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) #[[{ id: 2, name: 'George', lastName: 'Costanza' }, { id: 3, name: 'Cosmo', lastName: 'Kramer' }]] ``` ### [](#database_bulk_execute)一括実行操作の移行 Mule 3 Connector の ​``​ 操作が ​``​ 操作に置換されました。 ここで注意すべき重要な点は、Mule 3 バージョンでは ​`bulk`​ という用語を使うものの、上記の例のように、実際には一括操作ではないことです。同じ接続を使用して個別のステートメントが多数実行されますが、ステートメントがまとめて作成されるわけではありません。そのため、Mule 4 では、この操作の実態を的確に説明するために ​`execute-script`​ と呼ばれています。 Mule 4 の例: `execute-script`​ 操作の使用 ```xml update PLANET set NAME='Mercury' where POSITION=0; update PLANET set NAME='Mercury' where POSITION=4 ``` ステートメントも外部ファイルに抽出できます。 Mule 4 の例: 外部ファイルを設定した ​`execute-script`​ 操作の使用 ```xml ``` ### [](#tx_actions)トランザクションのアクション データベース操作は、トランザクション内で実行されるときに、そのトランザクションとどのようにやり取りするかを決定できます。 トランザクションの選択可能なアクションは次のとおりです。 - **ALWAYS\_JOIN** - **JOIN\_IF\_POSSIBLE** - **NOT\_SUPPORTED** Mule 3 の例: トランザクションのアクション ```xml SELECT * FROM people ``` Mule 4 の例: トランザクションのアクション ```xml SELECT * FROM people ``` ### [](#output_target)出力対象 **Mule 3**​ では、DB Connector が実行した出力を任意の対象変数に保存することができました。​**Mule 4**​ でも同様に処理できますが、若干異なります。 **Mule 3**​ で出力とされていたものは単なる実行結果であり、たとえば ​`target="#[flowVars.targetVar]"`​ と設定すると、クエリの実行が ​`targetVar`​ フロー変数に保存されていました。 **Mule 4**​ でもほぼ同じで、対象のフロー変数の名前である ​`target`​ パラメーターがありますが、これを式にすることはできません。​**Mule 4**​ の新しいパラメーターは ​`targetValue`​ で、これは操作結果に対して評価される式です。たとえば、ペイロード全体を保存する場合は ​`#[payload]`​ に、SELECT クエリの 1 行目だけを保存する場合は ​`#[payload[0]]`​ になります。 Mule 3 の例: 出力対象 ```xml SELECT * FROM People ``` Mule 4 の例: 出力対象 ```xml SELECT * from People ``` Database Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-db-connector 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Database Connector の概要](https://docs.mulesoft.com/db-connector/latest/) - [Mule 4.0 でのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.5/streaming-about)​。 # Database Connector の移行 Database Connector を Mule 3 から Mule 4 に移行する場合の主な変更点は次のとおりです。 - すべてのデータベース操作 (Select、Insert、Update、Delete など) が別の操作にリファクタリングされています。Mule 4 にはまた、新しい専用の一括操作もあります。 - DataWeave の使用: データベース操作 (Insert、Update など) は DataWeave バージョン 2 の変換をサポートしています。データベースを挿入または更新するデータセットを構築できます。メッセージの副次的影響はなく、メッセージエンリッチャーも不要になりました。 - 動的クエリと静的クエリを同様の方法で実行できます。 - 各自の操作に応じて Mule ストリーミングフレームワークが自動的に設定されます。Select ステートメントを実行し、接続の漏えいを心配することなく、結果を非同期で処理できます。 ## [](#whats_covered_here)このトピックの内容 - [データベース接続の設定](#database_configuration) - [データソース参照](#data_source_ref) - [例: コネクタの詳細設定](#connector_config_detail) - [動的クエリの移行](#database_dynamic_queries) - [大量の結果のストリーミング](#database_streaming) - [一括操作の移行](#database_operation_bulk) - [一括実行操作の移行](#database_bulk_execute) - [トランザクションのアクション](#tx_actions) - [出力対象](#output_target) ## [](#database_configuration)データベース接続の設定 Mule 3 と Mule 4 の Database Connector は、Derby、MySQL、Oracle、汎用データベースの設定をサポートしています。Mule 4 では、Microsoft SQL Server とデータソース参照接続もサポートされています。 これらの接続設定の XML が Mule 4 で変更されています。 - Mule 3: データベース要素 (​``​ など) が最上位要素です。 - Mule 4: ``​ がすべてのデータベース接続設定の最上位要素で、特定のデータベース設定が個別の ​``​ 要素にネストされます。 - Derby: `` - Microsoft SQL Server: `` - MySQL: `` - Oracle: `` - 汎用: `` - データソース参照接続: `` Mule 3 の例: Derby 接続設定 ```xml ``` 上記の Mule 3 の例の ​``​ が、下記の Mule 4 の例では ​``​ に変更され、データベースへの URL の属性が Mule 4 では ​`url`​ から ​`database`​ に変更されています。Mule 4 で、新たに ​``​ 子要素が追加されました。 Mule 4 の例: Derby 接続設定 ```xml ``` さらに、Mule 4 では、新たな ​``​ 設定 (XML 属性) を使用できます。 - `create="true|false"`​: データベースが存在しない場合に作成するかどうか。 - `subsubProtocol="directory"`​: Derby が使用する SubsubProtocol の種別。選択可能なオプションは ​`directory`​、​`memory`​、​`classpath`​、​`jar`​ です。 次のセクションでは、他のデータベースの接続設定について説明します。 ### [](#data_source_ref)データソース参照 以下のトピックで、その他のデータベース接続の Mule 4 の XML の例と、コネクタに固有の設定を示します。 - [Mule 4 の例: データソース参照](#example_data_source_db) - [Mule 4 の例: 汎用](#example_generic_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [Mule 4 の例: MySQL](#example_mysql_db) - [Mule 4 の例: Oracle JDBC データベース](#example_oracle_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [例: Microsoft SQL Server ドライバーの Maven 連動関係設定。](#example_driver) 前セクションの Derby の Mule 3 の例に、Mule 3 と Mule 4 のデータベース接続設定 (My SQL、Oracle など) の主な相違点の大半が示されています。また、データベース接続の Mule 3 から Mule 4 への主な移行パターンもわかります。 - Derby: [データベース接続の設定](#database_configuration) #### [](#example_data_source_db)Mule 4 の例: データソース参照 データソース参照を使用するには、次の手順を実行する必要があります。 1 - XML Spring Bean ファイルを作成して、​`DataSource`​ を表す Spring Bean を作成します。 datasource-spring-beans.xml ```xml ```
DataSource 実装を含む Maven 連動関係を設定する必要があります。 この例では、​org.enhydra.jdbc.standard.StandardDataSource​ に次の連動関係が必要です。

<dependency>
​<groupId>com.experlog</groupId>
​<artifactId>xapool</artifactId>
​<version>1.5.0</version>
</dependency>
2 - データソース接続を作成します。
1Mule Spring Module​ [Spring Module へのリンク] を使用して ​datasource-spring-beans.xml​ ファイルをインポートします。
2DataSource 接続を使用して DB 設定を作成し、​datasource-spring-beans.xml​ で作成された DataSource Bean の Spring Bean ID を ​dataSourceRef​ として追加します。
```xml (1) (2) ``` 以下はデータソース参照に固有の設定です。 - `dataSourceRef="my_ref_here"`​: JDBC DataSource オブジェクトへの参照。このオブジェクトは通常、Spring を使用して作成されます。XA トランザクションを使用する場合は、XADataSource オブジェクトを指定する必要があります。 #### [](#example_generic_db)Mule 4 の例: 汎用 ```xml ``` 以下は、汎用データベースに固有の設定です。 - `url="url_here"`​: データベースへの接続に使用する JDBC URL。 - `driverClassName="driver_class_name_here"`​: データベースドライバークラスの完全修飾名。
driverClassName​ パラメーターで参照されるクラスを含む Maven 連動関係は、Mule アプリケーションで設定する必要があります。
また、Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。
[データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mssql_db)Mule 4 の例: Microsoft SQL Server ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mysql_db)Mule 4 の例: MySQL ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_oracle_db)Mule 4 の例: Oracle JDBC データベース ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_driver)例: Microsoft SQL Server ドライバーの Maven 連動関係設定。 Microsoft SQL Server、MySQL、Derby、Oracle の設定にはドライバーが必要です。 ```xml com.microsoft.sqlserver mssql-jdbc 6.2.2.jre8 ```
Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。Studio を使用して自動的に設定されます。
### [](#connector_config_detail)例: コネクタの詳細設定 Mule 4 では、次の設定の子要素をデータベース接続設定 (​``​ など) で追加できます。 - [データベースのトランザクション](#db_transactions) - [トランザクションのアクション](#tx_actions) - [トランザクション分離](#tx_isolation) - [XA トランザクション](#xa_tx) - [Connection Properties (接続プロパティ)](#connection_properties) - [列の型](#column_types) - [Pooling Profile (プーリングプロファイル)](#pooling_profile) - [再接続戦略](#reconnection_strategies) #### [](#db_transactions)データベースのトランザクション ##### [](#tx_isolation)トランザクション分離 トランザクションには、データベースの接続時にドライバーに設定するトランザクション分離レベルがあります。 - **NOT\_CONFIGURED**​ (デフォルト) - **READ\_COMMITTED**​ (​`transactionIsolation="READ_COMMITTED"`​) - **READ\_UNCOMMITTED**​ (​`transactionIsolation="READ_UNCOMMITTED"`​) - **REPEATABLE\_READ**​ (​`transactionIsolation="REPEATABLE_READ"`​) - **SERIALIZABLE**​ (​`transactionIsolation="SERIALIZABLE"`​) Mule 3 の例: トランザクション分離 ```xml ``` Mule 4 の例: トランザクション分離 ```xml ``` ##### [](#xa_tx)XA トランザクション **Mule 3**​ と ​**Mule 4**​ のどちらも、XA トランザクションで機能する接続を ​`useXaTransactions="true"`​ 接続設定で定義できます。 Mule 3 の例: XA トランザクション ```xml ``` Mule 4 の例: XA トランザクション ```xml ``` #### [](#connection_properties)Connection Properties (接続プロパティ) **MySQL**​ と ​**Microsoft SQL Server**​ のデータベース設定で接続プロパティ設定を指定します。これらのプロパティは JDBC 接続に、追加のプロパティとして挿入されます。 Mule 3 の例: 接続プロパティ ```xml ``` Mule 4 の例: 接続プロパティ ```xml ``` #### [](#column_types)列の型 - 列の型 (​``​): 標準以外の列の型。 #### [](#pooling_profile)Pooling Profile (プーリングプロファイル) - プーリングプロファイル (​``​): 接続プーリング接続が可能な JDBC データソース。Mule 3 の接続プーリングとほぼ同じです。 #### [](#reconnection_strategies)再接続戦略 Mule 3 と Mule 4 の再接続戦略設定はよく似ています。ただし、Mule 4 ではカスタム再接続戦略を使用できません。 以下の例は、これらの設定の XML への変更点を示しています。 - **None (なし)**​: デフォルト。Mule 3 の \[Do Not Use A Reconnection Strategy (再接続戦略を使用しない)\] と同じです。 - **Standard (標準)**​: Mule 3 の \[Standard Reconnection (標準再接続)\] と同じです。どちらもオプションは、\[Frequency (ms) (頻度 (ミリ秒))\] と \[Reconnection Attempts (再接続試行回数)\] です。 - **Forever (無期限)**​: Mule 3 の \[Reconnect Forever (繰り返し再接続)\] と同じです。 Mule 3 の例: 再接続設定 ```xml ` ` ``` Mule 4 の例: 再接続設定 ```xml ``` ## [](#database_operations_overview)Database Connector の操作 - SQL クエリのテキストや入力パラメーターのクエリ - ストリーミング戦略設定 (​[大量の結果のストリーミング](#database_streaming)​を参照) - [トランザクションのアクション](#tx_actions) - クエリ設定 - エラー (DB:BAD\_SQL\_SYNTAX​、DB:QUERY\_EXECUTION​ など) のエラーマッピング - Mule 4 の属性、ペイロード、変数の入力および出力メタデータ ### [](#database_parameterized_queries)パラメーター化クエリの移行 **Mule 3**​ と ​**Mule 4**​ のどちらも、入力パラメーターはキー - 値のペアとして指定します。 このキーにセミコロン文字 (:) を付けて、名前でパラメーター値を参照します。つまり、​**Mule 3**​ で記述された SQL のパラメーター化クエリを、​**Mule 4**​ で使用するために変更する必要はありません。 SQL インジェクション攻撃を阻止するためにこのアプローチが推奨され、Mule アプリケーションの全般的なパフォーマンスを向上させる最適化をコネクタが実行できます。 #### [](#入力パラメーター)入力パラメーター - **Mule 3**​ では、各入力パラメーターが ​``​ 操作内で ​``​ 要素として定義され、この要素にパラメーター名の ​`name`​ 属性と、そのパラメーター値を保持する ​`value`​ 属性がありました。 - **Mule 4**​ では、各入力パラメーターがマップの ​``​ として定義され、キーはパラメーター名で、値はパラメーター値です。このマップは DataWeave を使用してのみ作成できます。 Mule 3 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name ``` Mule 4 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name #[ { last_name : vars.lastName } ] ``` ### [](#database_dynamic_queries)動的クエリの移行 場合によっては、WHERE 句をパラメーター化するだけでなく、クエリ自体の各部をパラメーター化しなければならないことがあります。このユースケースの例として、条件に応じてオンライン/履歴テーブルにアクセスする必要のあるクエリや、プロジェクト列を変更する必要のある複雑なクエリなどが挙げられます。 Mule 3 では、選択の概念がパラメーター化クエリと動的クエリに分割されており、この両方を同時に使用することができませんでした。動的クエリを使用するか、パラメーターを使用する利点 (SQL インジェクションの防御、PreparedStatement の最適化など) をとるかのどちらかを選択する必要がありました。また、それぞれ構文が異なるため、同じことを行うのに 2 つのやり方を学ぶ必要がありました。 他方 Mule 4 では、この新しい Database Connector のクエリ内で式を用いて、この両方の方法を同時に使用できるようになりました。 Mule 3 の例: 動的 SELECT クエリ ```xml SELECT * FROM #[flowVars.table] WHERE name = #[flowVars.name] ``` Mule 4 の例: 動的 SELECT クエリ ```xml #['SELECT * FROM $(vars.table) WHERE name = $(vars.name)'] ``` 注意点: Mule 3 の例のほうがパフォーマンスに劣り、SQL インジェクション攻撃に対して脆弱です。PreparedStatements を使用せず、クエリ全体が文字列として処理されるためです。 ## [](#database_streaming)大量の結果のストリーミング ストリーミングでは、大規模なデータベーステーブルに対するクエリ結果を処理できます。特にインテグレーションのユースケースなどでは、何万件ものレコードが返されることがあります。この解決策として優れているのがストリーミングです。 ### [](#ストリーミングの有効化)ストリーミングの有効化 **Mule 3**​ では、ストリーミングがデフォルトで無効になっているため、使用する場合は有効にする必要があります。 **Mule 4**​ では、ストリーミングが常にオンですが、ランタイムで反復可能なストリーミングを実行する戦略を設定できます。この点についての詳細は、​[ストリーミングのドキュメントページ](https://docs.mulesoft.com/jp/mule-runtime/4.6/streaming-about)​を参照してください。 TIP: 反復可能なストリーミングを無効にすると、並列処理を含め、DataWeave や他のコンポーネントでストリームを何度も処理できなくなります。 ### [](#database_operation_bulk)一括操作の移行 #### [](#一括モードの有効化)一括モードの有効化 **Mule 3**​ では、​**Insert、Update、Delete**​ 操作の ​`bulkMode="true"`​ 設定で一括機能を設定します。 **Mule 4**​ では代わりに、データベースに対する一括操作専用の Bulk Insert (​``​)、Bulk Update (​``​)、Bulk Delete (​``​) を使用します。受信したペイロードに応じて、操作が動作を変更することがなくなりました。 #### [](#一括データのコンシューム)一括データのコンシューム **Mule 3**​ の一括クエリでは、コネクタが ​``​ コンポーネントと同じように機能していました。つまり、現在のペイロード値 (通常は項目のコレクション) を取り、コレクションの値ごとに ​``​ 式を実行していました。 **Mule 4**​ では若干異なり、ペイロードをコンシュームしてコレクションの要素ごとに式を実行するのではなく、エントリのコレクションを挿入する必要があります。 ##### [](#例)例: Mule 3 の例: パラメーター化クエリを使用した選択 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) ``` Mule 4 の例: 一括操作を使用した各値の取得 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) #[[{ id: 2, name: 'George', lastName: 'Costanza' }, { id: 3, name: 'Cosmo', lastName: 'Kramer' }]] ``` ### [](#database_bulk_execute)一括実行操作の移行 Mule 3 Connector の ​``​ 操作が ​``​ 操作に置換されました。 ここで注意すべき重要な点は、Mule 3 バージョンでは ​`bulk`​ という用語を使うものの、上記の例のように、実際には一括操作ではないことです。同じ接続を使用して個別のステートメントが多数実行されますが、ステートメントがまとめて作成されるわけではありません。そのため、Mule 4 では、この操作の実態を的確に説明するために ​`execute-script`​ と呼ばれています。 Mule 4 の例: `execute-script`​ 操作の使用 ```xml update PLANET set NAME='Mercury' where POSITION=0; update PLANET set NAME='Mercury' where POSITION=4 ``` ステートメントも外部ファイルに抽出できます。 Mule 4 の例: 外部ファイルを設定した ​`execute-script`​ 操作の使用 ```xml ``` ### [](#tx_actions)トランザクションのアクション データベース操作は、トランザクション内で実行されるときに、そのトランザクションとどのようにやり取りするかを決定できます。 トランザクションの選択可能なアクションは次のとおりです。 - **ALWAYS\_JOIN** - **JOIN\_IF\_POSSIBLE** - **NOT\_SUPPORTED** Mule 3 の例: トランザクションのアクション ```xml SELECT * FROM people ``` Mule 4 の例: トランザクションのアクション ```xml SELECT * FROM people ``` ### [](#output_target)出力対象 **Mule 3**​ では、DB Connector が実行した出力を任意の対象変数に保存することができました。​**Mule 4**​ でも同様に処理できますが、若干異なります。 **Mule 3**​ で出力とされていたものは単なる実行結果であり、たとえば ​`target="#[flowVars.targetVar]"`​ と設定すると、クエリの実行が ​`targetVar`​ フロー変数に保存されていました。 **Mule 4**​ でもほぼ同じで、対象のフロー変数の名前である ​`target`​ パラメーターがありますが、これを式にすることはできません。​**Mule 4**​ の新しいパラメーターは ​`targetValue`​ で、これは操作結果に対して評価される式です。たとえば、ペイロード全体を保存する場合は ​`#[payload]`​ に、SELECT クエリの 1 行目だけを保存する場合は ​`#[payload[0]]`​ になります。 Mule 3 の例: 出力対象 ```xml SELECT * FROM People ``` Mule 4 の例: 出力対象 ```xml SELECT * from People ``` Database Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-db-connector 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Database Connector の概要](https://docs.mulesoft.com/db-connector/latest/) - [Mule 4.0 でのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.6/streaming-about)​。 # Database Connector の移行 Database Connector を Mule 3 から Mule 4 に移行する場合の主な変更点は次のとおりです。 - すべてのデータベース操作 (Select、Insert、Update、Delete など) が別の操作にリファクタリングされています。Mule 4 にはまた、新しい専用の一括操作もあります。 - DataWeave の使用: データベース操作 (Insert、Update など) は DataWeave バージョン 2 の変換をサポートしています。データベースを挿入または更新するデータセットを構築できます。メッセージの副次的影響はなく、メッセージエンリッチャーも不要になりました。 - 動的クエリと静的クエリを同様の方法で実行できます。 - 各自の操作に応じて Mule ストリーミングフレームワークが自動的に設定されます。Select ステートメントを実行し、接続の漏えいを心配することなく、結果を非同期で処理できます。 ## [](#whats_covered_here)このトピックの内容 - [データベース接続の設定](#database_configuration) - [データソース参照](#data_source_ref) - [例: コネクタの詳細設定](#connector_config_detail) - [動的クエリの移行](#database_dynamic_queries) - [大量の結果のストリーミング](#database_streaming) - [一括操作の移行](#database_operation_bulk) - [一括実行操作の移行](#database_bulk_execute) - [トランザクションのアクション](#tx_actions) - [出力対象](#output_target) ## [](#database_configuration)データベース接続の設定 Mule 3 と Mule 4 の Database Connector は、Derby、MySQL、Oracle、汎用データベースの設定をサポートしています。Mule 4 では、Microsoft SQL Server とデータソース参照接続もサポートされています。 これらの接続設定の XML が Mule 4 で変更されています。 - Mule 3: データベース要素 (​``​ など) が最上位要素です。 - Mule 4: ``​ がすべてのデータベース接続設定の最上位要素で、特定のデータベース設定が個別の ​``​ 要素にネストされます。 - Derby: `` - Microsoft SQL Server: `` - MySQL: `` - Oracle: `` - 汎用: `` - データソース参照接続: `` Mule 3 の例: Derby 接続設定 ```xml ``` 上記の Mule 3 の例の ​``​ が、下記の Mule 4 の例では ​``​ に変更され、データベースへの URL の属性が Mule 4 では ​`url`​ から ​`database`​ に変更されています。Mule 4 で、新たに ​``​ 子要素が追加されました。 Mule 4 の例: Derby 接続設定 ```xml ``` さらに、Mule 4 では、新たな ​``​ 設定 (XML 属性) を使用できます。 - `create="true|false"`​: データベースが存在しない場合に作成するかどうか。 - `subsubProtocol="directory"`​: Derby が使用する SubsubProtocol の種別。選択可能なオプションは ​`directory`​、​`memory`​、​`classpath`​、​`jar`​ です。 次のセクションでは、他のデータベースの接続設定について説明します。 ### [](#data_source_ref)データソース参照 以下のトピックで、その他のデータベース接続の Mule 4 の XML の例と、コネクタに固有の設定を示します。 - [Mule 4 の例: データソース参照](#example_data_source_db) - [Mule 4 の例: 汎用](#example_generic_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [Mule 4 の例: MySQL](#example_mysql_db) - [Mule 4 の例: Oracle JDBC データベース](#example_oracle_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [例: Microsoft SQL Server ドライバーの Maven 連動関係設定。](#example_driver) 前セクションの Derby の Mule 3 の例に、Mule 3 と Mule 4 のデータベース接続設定 (My SQL、Oracle など) の主な相違点の大半が示されています。また、データベース接続の Mule 3 から Mule 4 への主な移行パターンもわかります。 - Derby: [データベース接続の設定](#database_configuration) #### [](#example_data_source_db)Mule 4 の例: データソース参照 データソース参照を使用するには、次の手順を実行する必要があります。 1 - XML Spring Bean ファイルを作成して、​`DataSource`​ を表す Spring Bean を作成します。 datasource-spring-beans.xml ```xml ```
DataSource 実装を含む Maven 連動関係を設定する必要があります。 この例では、​org.enhydra.jdbc.standard.StandardDataSource​ に次の連動関係が必要です。

<dependency>
​<groupId>com.experlog</groupId>
​<artifactId>xapool</artifactId>
​<version>1.5.0</version>
</dependency>
2 - データソース接続を作成します。
1Mule Spring Module​ [Spring Module へのリンク] を使用して ​datasource-spring-beans.xml​ ファイルをインポートします。
2DataSource 接続を使用して DB 設定を作成し、​datasource-spring-beans.xml​ で作成された DataSource Bean の Spring Bean ID を ​dataSourceRef​ として追加します。
```xml (1) (2) ``` 以下はデータソース参照に固有の設定です。 - `dataSourceRef="my_ref_here"`​: JDBC DataSource オブジェクトへの参照。このオブジェクトは通常、Spring を使用して作成されます。XA トランザクションを使用する場合は、XADataSource オブジェクトを指定する必要があります。 #### [](#example_generic_db)Mule 4 の例: 汎用 ```xml ``` 以下は、汎用データベースに固有の設定です。 - `url="url_here"`​: データベースへの接続に使用する JDBC URL。 - `driverClassName="driver_class_name_here"`​: データベースドライバークラスの完全修飾名。
driverClassName​ パラメーターで参照されるクラスを含む Maven 連動関係は、Mule アプリケーションで設定する必要があります。
また、Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。
[データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mssql_db)Mule 4 の例: Microsoft SQL Server ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mysql_db)Mule 4 の例: MySQL ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_oracle_db)Mule 4 の例: Oracle JDBC データベース ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_driver)例: Microsoft SQL Server ドライバーの Maven 連動関係設定。 Microsoft SQL Server、MySQL、Derby、Oracle の設定にはドライバーが必要です。 ```xml com.microsoft.sqlserver mssql-jdbc 6.2.2.jre8 ```
Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。Studio を使用して自動的に設定されます。
### [](#connector_config_detail)例: コネクタの詳細設定 Mule 4 では、次の設定の子要素をデータベース接続設定 (​``​ など) で追加できます。 - [データベースのトランザクション](#db_transactions) - [トランザクションのアクション](#tx_actions) - [トランザクション分離](#tx_isolation) - [XA トランザクション](#xa_tx) - [Connection Properties (接続プロパティ)](#connection_properties) - [列の型](#column_types) - [プーリングプロファイル](#pooling_profile) - [再接続戦略](#reconnection_strategies) #### [](#db_transactions)データベースのトランザクション ##### [](#tx_isolation)トランザクション分離 トランザクションには、データベースの接続時にドライバーに設定するトランザクション分離レベルがあります。 - **NOT\_CONFIGURED**​ (デフォルト) - **READ\_COMMITTED**​ (​`transactionIsolation="READ_COMMITTED"`​) - **READ\_UNCOMMITTED**​ (​`transactionIsolation="READ_UNCOMMITTED"`​) - **REPEATABLE\_READ**​ (​`transactionIsolation="REPEATABLE_READ"`​) - **SERIALIZABLE**​ (​`transactionIsolation="SERIALIZABLE"`​) Mule 3 の例: トランザクション分離 ```xml ``` Mule 4 の例: トランザクション分離 ```xml ``` ##### [](#xa_tx)XA トランザクション **Mule 3**​ と ​**Mule 4**​ のどちらも、XA トランザクションで機能する接続を ​`useXaTransactions="true"`​ 接続設定で定義できます。 Mule 3 の例: XA トランザクション ```xml ``` Mule 4 の例: XA トランザクション ```xml ``` #### [](#connection_properties)Connection Properties (接続プロパティ) **MySQL**​ と ​**Microsoft SQL Server**​ のデータベース設定で接続プロパティ設定を指定します。これらのプロパティは JDBC 接続に、追加のプロパティとして挿入されます。 Mule 3 の例: 接続プロパティ ```xml ``` Mule 4 の例: 接続プロパティ ```xml ``` #### [](#column_types)列の型 - 列の型 (​``​): 標準以外の列の型。 #### [](#pooling_profile)プーリングプロファイル - プーリングプロファイル (​``​): 接続プーリング接続が可能な JDBC データソース。Mule 3 の接続プーリングとほぼ同じです。 #### [](#reconnection_strategies)再接続戦略 Mule 3 と Mule 4 の再接続戦略設定はよく似ています。ただし、Mule 4 ではカスタム再接続戦略を使用できません。 以下の例は、これらの設定の XML への変更点を示しています。 - **None (なし)**​: デフォルト。Mule 3 の \[Do Not Use A Reconnection Strategy (再接続戦略を使用しない)\] と同じです。 - **Standard (標準)**​: Mule 3 の \[Standard Reconnection (標準再接続)\] と同じです。どちらもオプションは、\[Frequency (ms) (頻度 (ミリ秒))\] と \[Reconnection Attempts (再接続試行回数)\] です。 - **Forever (無期限)**​: Mule 3 の \[Reconnect Forever (繰り返し再接続)\] と同じです。 Mule 3 の例: 再接続設定 ```xml ` ` ``` Mule 4 の例: 再接続設定 ```xml ``` ## [](#database_operations_overview)Database Connector の操作 - SQL クエリのテキストや入力パラメーターのクエリ - ストリーミング戦略設定 (​[大量の結果のストリーミング](#database_streaming)​を参照) - [トランザクションのアクション](#tx_actions) - クエリ設定 - エラー (DB:BAD\_SQL\_SYNTAX​、DB:QUERY\_EXECUTION​ など) のエラーマッピング - Mule 4 の属性、ペイロード、変数の入力および出力メタデータ ### [](#database_parameterized_queries)パラメーター化クエリの移行 **Mule 3**​ と ​**Mule 4**​ のどちらも、入力パラメーターはキー - 値のペアとして指定します。 このキーにセミコロン文字 (:) を付けて、名前でパラメーター値を参照します。つまり、​**Mule 3**​ で記述された SQL のパラメーター化クエリを、​**Mule 4**​ で使用するために変更する必要はありません。 SQL インジェクション攻撃を阻止するためにこのアプローチが推奨され、Mule アプリケーションの全般的なパフォーマンスを向上させる最適化をコネクタが実行できます。 #### [](#入力パラメーター)入力パラメーター - **Mule 3**​ では、各入力パラメーターが ​``​ 操作内で ​``​ 要素として定義され、この要素にパラメーター名の ​`name`​ 属性と、そのパラメーター値を保持する ​`value`​ 属性がありました。 - **Mule 4**​ では、各入力パラメーターがマップの ​``​ として定義され、キーはパラメーター名で、値はパラメーター値です。このマップは DataWeave を使用してのみ作成できます。 Mule 3 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name ``` Mule 4 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name #[ { last_name : vars.lastName } ] ``` ### [](#database_dynamic_queries)動的クエリの移行 場合によっては、WHERE 句をパラメーター化するだけでなく、クエリ自体の各部をパラメーター化しなければならないことがあります。このユースケースの例として、条件に応じてオンライン/履歴テーブルにアクセスする必要のあるクエリや、プロジェクト列を変更する必要のある複雑なクエリなどが挙げられます。 Mule 3 では、選択の概念がパラメーター化クエリと動的クエリに分割されており、この両方を同時に使用することができませんでした。動的クエリを使用するか、パラメーターを使用する利点 (SQL インジェクションの防御、PreparedStatement の最適化など) をとるかのどちらかを選択する必要がありました。また、それぞれ構文が異なるため、同じことを行うのに 2 つのやり方を学ぶ必要がありました。 他方 Mule 4 では、この新しい Database Connector のクエリ内で式を用いて、この両方の方法を同時に使用できるようになりました。 Mule 3 の例: 動的 SELECT クエリ ```xml SELECT * FROM #[flowVars.table] WHERE name = #[flowVars.name] ``` Mule 4 の例: 動的 SELECT クエリ ```xml #['SELECT * FROM $(vars.table) WHERE name = $(vars.name)'] ``` 注意点: Mule 3 の例のほうがパフォーマンスに劣り、SQL インジェクション攻撃に対して脆弱です。PreparedStatements を使用せず、クエリ全体が文字列として処理されるためです。 ## [](#database_streaming)大量の結果のストリーミング ストリーミングでは、大規模なデータベーステーブルに対するクエリ結果を処理できます。特にインテグレーションのユースケースなどでは、何万件ものレコードが返されることがあります。この解決策として優れているのがストリーミングです。 ### [](#ストリーミングの有効化)ストリーミングの有効化 **Mule 3**​ では、ストリーミングがデフォルトで無効になっているため、使用する場合は有効にする必要があります。 **Mule 4**​ では、ストリーミングが常にオンですが、ランタイムで反復可能なストリーミングを実行する戦略を設定できます。この点についての詳細は、​[ストリーミングのドキュメントページ](https://docs.mulesoft.com/jp/mule-runtime/4.7/streaming-about)​を参照してください。 TIP: 反復可能なストリーミングを無効にすると、並列処理を含め、DataWeave や他のコンポーネントでストリームを何度も処理できなくなります。 ### [](#database_operation_bulk)一括操作の移行 #### [](#一括モードの有効化)一括モードの有効化 **Mule 3**​ では、​**Insert、Update、Delete**​ 操作の ​`bulkMode="true"`​ 設定で一括機能を設定します。 **Mule 4**​ では代わりに、データベースに対する一括操作専用の Bulk Insert (​``​)、Bulk Update (​``​)、Bulk Delete (​``​) を使用します。受信したペイロードに応じて、操作が動作を変更することがなくなりました。 #### [](#一括データのコンシューム)一括データのコンシューム **Mule 3**​ の一括クエリでは、コネクタが ​``​ コンポーネントと同じように機能していました。つまり、現在のペイロード値 (通常は項目のコレクション) を取り、コレクションの値ごとに ​``​ 式を実行していました。 **Mule 4**​ では若干異なり、ペイロードをコンシュームしてコレクションの要素ごとに式を実行するのではなく、エントリのコレクションを挿入する必要があります。 ##### [](#例)例: Mule 3 の例: パラメーター化クエリを使用した選択 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) ``` Mule 4 の例: 一括操作を使用した各値の取得 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) #[[{ id: 2, name: 'George', lastName: 'Costanza' }, { id: 3, name: 'Cosmo', lastName: 'Kramer' }]] ``` ### [](#database_bulk_execute)一括実行操作の移行 Mule 3 Connector の ​``​ 操作が ​``​ 操作に置換されました。 ここで注意すべき重要な点は、Mule 3 バージョンでは ​`bulk`​ という用語を使うものの、上記の例のように、実際には一括操作ではないことです。同じ接続を使用して個別のステートメントが多数実行されますが、ステートメントがまとめて作成されるわけではありません。そのため、Mule 4 では、この操作の実態を的確に説明するために ​`execute-script`​ と呼ばれています。 Mule 4 の例: `execute-script`​ 操作の使用 ```xml update PLANET set NAME='Mercury' where POSITION=0; update PLANET set NAME='Mercury' where POSITION=4 ``` ステートメントも外部ファイルに抽出できます。 Mule 4 の例: 外部ファイルを設定した ​`execute-script`​ 操作の使用 ```xml ``` ### [](#tx_actions)トランザクションのアクション データベース操作は、トランザクション内で実行されるときに、そのトランザクションとどのようにやり取りするかを決定できます。 トランザクションの選択可能なアクションは次のとおりです。 - **ALWAYS\_JOIN** - **JOIN\_IF\_POSSIBLE** - **NOT\_SUPPORTED** Mule 3 の例: トランザクションのアクション ```xml SELECT * FROM people ``` Mule 4 の例: トランザクションのアクション ```xml SELECT * FROM people ``` ### [](#output_target)出力対象 **Mule 3**​ では、DB Connector が実行した出力を任意の対象変数に保存することができました。​**Mule 4**​ でも同様に処理できますが、若干異なります。 **Mule 3**​ で出力とされていたものは単なる実行結果であり、たとえば ​`target="#[flowVars.targetVar]"`​ と設定すると、クエリの実行が ​`targetVar`​ フロー変数に保存されていました。 **Mule 4**​ でもほぼ同じで、対象のフロー変数の名前である ​`target`​ パラメーターがありますが、これを式にすることはできません。​**Mule 4**​ の新しいパラメーターは ​`targetValue`​ で、これは操作結果に対して評価される式です。たとえば、ペイロード全体を保存する場合は ​`#[payload]`​ に、SELECT クエリの 1 行目だけを保存する場合は ​`#[payload[0]]`​ になります。 Mule 3 の例: 出力対象 ```xml SELECT * FROM People ``` Mule 4 の例: 出力対象 ```xml SELECT * from People ``` Database Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-db-connector 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Database Connector の概要](https://docs.mulesoft.com/db-connector/latest/) - [Mule 4.0 でのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.7/streaming-about)​。 # Database Connector の移行 Database Connector を Mule 3 から Mule 4 に移行する場合の主な変更点は次のとおりです。 - すべてのデータベース操作 (Select、Insert、Update、Delete など) が別の操作にリファクタリングされています。Mule 4 にはまた、新しい専用の一括操作もあります。 - DataWeave の使用: データベース操作 (Insert、Update など) は DataWeave バージョン 2 の変換をサポートしています。データベースを挿入または更新するデータセットを構築できます。メッセージの副次的影響はなく、メッセージエンリッチャーも不要になりました。 - 動的クエリと静的クエリを同様の方法で実行できます。 - 各自の操作に応じて Mule ストリーミングフレームワークが自動的に設定されます。Select ステートメントを実行し、接続の漏えいを心配することなく、結果を非同期で処理できます。 ## [](#whats_covered_here)このトピックの内容 - [データベース接続の設定](#database_configuration) - [データソース参照](#data_source_ref) - [例: コネクタの詳細設定](#connector_config_detail) - [動的クエリの移行](#database_dynamic_queries) - [大量の結果のストリーミング](#database_streaming) - [一括操作の移行](#database_operation_bulk) - [一括実行操作の移行](#database_bulk_execute) - [トランザクションのアクション](#tx_actions) - [出力対象](#output_target) ## [](#database_configuration)データベース接続の設定 Mule 3 と Mule 4 の Database Connector は、Derby、MySQL、Oracle、汎用データベースの設定をサポートしています。Mule 4 では、Microsoft SQL Server とデータソース参照接続もサポートされています。 これらの接続設定の XML が Mule 4 で変更されています。 - Mule 3: データベース要素 (​``​ など) が最上位要素です。 - Mule 4: ``​ がすべてのデータベース接続設定の最上位要素で、特定のデータベース設定が個別の ​``​ 要素にネストされます。 - Derby: `` - Microsoft SQL Server: `` - MySQL: `` - Oracle: `` - 汎用: `` - データソース参照接続: `` Mule 3 の例: Derby 接続設定 ```xml ``` 上記の Mule 3 の例の ​``​ が、下記の Mule 4 の例では ​``​ に変更され、データベースへの URL の属性が Mule 4 では ​`url`​ から ​`database`​ に変更されています。Mule 4 で、新たに ​``​ 子要素が追加されました。 Mule 4 の例: Derby 接続設定 ```xml ``` さらに、Mule 4 では、新たな ​``​ 設定 (XML 属性) を使用できます。 - `create="true|false"`​: データベースが存在しない場合に作成するかどうか。 - `subsubProtocol="directory"`​: Derby が使用する SubsubProtocol の種別。選択可能なオプションは ​`directory`​、​`memory`​、​`classpath`​、​`jar`​ です。 次のセクションでは、他のデータベースの接続設定について説明します。 ### [](#data_source_ref)データソース参照 以下のトピックで、その他のデータベース接続の Mule 4 の XML の例と、コネクタに固有の設定を示します。 - [Mule 4 の例: データソース参照](#example_data_source_db) - [Mule 4 の例: 汎用](#example_generic_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [Mule 4 の例: MySQL](#example_mysql_db) - [Mule 4 の例: Oracle JDBC データベース](#example_oracle_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [例: Microsoft SQL Server ドライバーの Maven 連動関係設定。](#example_driver) 前セクションの Derby の Mule 3 の例に、Mule 3 と Mule 4 のデータベース接続設定 (My SQL、Oracle など) の主な相違点の大半が示されています。また、データベース接続の Mule 3 から Mule 4 への主な移行パターンもわかります。 - Derby: [データベース接続の設定](#database_configuration) #### [](#example_data_source_db)Mule 4 の例: データソース参照 データソース参照を使用するには、次の手順を実行する必要があります。 1 - XML Spring Bean ファイルを作成して、​`DataSource`​ を表す Spring Bean を作成します。 datasource-spring-beans.xml ```xml ```
DataSource 実装を含む Maven 連動関係を設定する必要があります。 この例では、​org.enhydra.jdbc.standard.StandardDataSource​ に次の連動関係が必要です。

<dependency>
​<groupId>com.experlog</groupId>
​<artifactId>xapool</artifactId>
​<version>1.5.0</version>
</dependency>
2 - データソース接続を作成します。
1Mule Spring Module​ [Spring Module へのリンク] を使用して ​datasource-spring-beans.xml​ ファイルをインポートします。
2DataSource 接続を使用して DB 設定を作成し、​datasource-spring-beans.xml​ で作成された DataSource Bean の Spring Bean ID を ​dataSourceRef​ として追加します。
```xml (1) (2) ``` 以下はデータソース参照に固有の設定です。 - `dataSourceRef="my_ref_here"`​: JDBC DataSource オブジェクトへの参照。このオブジェクトは通常、Spring を使用して作成されます。XA トランザクションを使用する場合は、XADataSource オブジェクトを指定する必要があります。 #### [](#example_generic_db)Mule 4 の例: 汎用 ```xml ``` 以下は、汎用データベースに固有の設定です。 - `url="url_here"`​: データベースへの接続に使用する JDBC URL。 - `driverClassName="driver_class_name_here"`​: データベースドライバークラスの完全修飾名。
driverClassName​ パラメーターで参照されるクラスを含む Maven 連動関係は、Mule アプリケーションで設定する必要があります。
また、Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。
[データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mssql_db)Mule 4 の例: Microsoft SQL Server ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mysql_db)Mule 4 の例: MySQL ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_oracle_db)Mule 4 の例: Oracle JDBC データベース ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_driver)例: Microsoft SQL Server ドライバーの Maven 連動関係設定。 Microsoft SQL Server、MySQL、Derby、Oracle の設定にはドライバーが必要です。 ```xml com.microsoft.sqlserver mssql-jdbc 6.2.2.jre8 ```
Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。Studio を使用して自動的に設定されます。
### [](#connector_config_detail)例: コネクタの詳細設定 Mule 4 では、次の設定の子要素をデータベース接続設定 (​``​ など) で追加できます。 - [データベースのトランザクション](#db_transactions) - [トランザクションのアクション](#tx_actions) - [トランザクション分離](#tx_isolation) - [XA トランザクション](#xa_tx) - [Connection Properties (接続プロパティ)](#connection_properties) - [列の型](#column_types) - [プーリングプロファイル](#pooling_profile) - [再接続戦略](#reconnection_strategies) #### [](#db_transactions)データベースのトランザクション ##### [](#tx_isolation)トランザクション分離 トランザクションには、データベースの接続時にドライバーに設定するトランザクション分離レベルがあります。 - **NOT\_CONFIGURED**​ (デフォルト) - **READ\_COMMITTED**​ (​`transactionIsolation="READ_COMMITTED"`​) - **READ\_UNCOMMITTED**​ (​`transactionIsolation="READ_UNCOMMITTED"`​) - **REPEATABLE\_READ**​ (​`transactionIsolation="REPEATABLE_READ"`​) - **SERIALIZABLE**​ (​`transactionIsolation="SERIALIZABLE"`​) Mule 3 の例: トランザクション分離 ```xml ``` Mule 4 の例: トランザクション分離 ```xml ``` ##### [](#xa_tx)XA トランザクション **Mule 3**​ と ​**Mule 4**​ のどちらも、XA トランザクションで機能する接続を ​`useXaTransactions="true"`​ 接続設定で定義できます。 Mule 3 の例: XA トランザクション ```xml ``` Mule 4 の例: XA トランザクション ```xml ``` #### [](#connection_properties)Connection Properties (接続プロパティ) **MySQL**​ と ​**Microsoft SQL Server**​ のデータベース設定で接続プロパティ設定を指定します。これらのプロパティは JDBC 接続に、追加のプロパティとして挿入されます。 Mule 3 の例: 接続プロパティ ```xml ``` Mule 4 の例: 接続プロパティ ```xml ``` #### [](#column_types)列の型 - 列の型 (​``​): 標準以外の列の型。 #### [](#pooling_profile)プーリングプロファイル - プーリングプロファイル (​``​): 接続プーリング接続が可能な JDBC データソース。Mule 3 の接続プーリングとほぼ同じです。 #### [](#reconnection_strategies)再接続戦略 Mule 3 と Mule 4 の再接続戦略設定はよく似ています。ただし、Mule 4 ではカスタム再接続戦略を使用できません。 以下の例は、これらの設定の XML への変更点を示しています。 - **None (なし)**​: デフォルト。Mule 3 の \[Do Not Use A Reconnection Strategy (再接続戦略を使用しない)\] と同じです。 - **Standard (標準)**​: Mule 3 の \[Standard Reconnection (標準再接続)\] と同じです。どちらもオプションは、\[Frequency (ms) (頻度 (ミリ秒))\] と \[Reconnection Attempts (再接続試行回数)\] です。 - **Forever (無期限)**​: Mule 3 の \[Reconnect Forever (繰り返し再接続)\] と同じです。 Mule 3 の例: 再接続設定 ```xml ` ` ``` Mule 4 の例: 再接続設定 ```xml ``` ## [](#database_operations_overview)Database Connector の操作 - SQL クエリのテキストや入力パラメーターのクエリ - ストリーミング戦略設定 (​[大量の結果のストリーミング](#database_streaming)​を参照) - [トランザクションのアクション](#tx_actions) - クエリ設定 - エラー (DB:BAD\_SQL\_SYNTAX​、DB:QUERY\_EXECUTION​ など) のエラーマッピング - Mule 4 の属性、ペイロード、変数の入力および出力メタデータ ### [](#database_parameterized_queries)パラメーター化クエリの移行 **Mule 3**​ と ​**Mule 4**​ のどちらも、入力パラメーターはキー - 値のペアとして指定します。 このキーにセミコロン文字 (:) を付けて、名前でパラメーター値を参照します。つまり、​**Mule 3**​ で記述された SQL のパラメーター化クエリを、​**Mule 4**​ で使用するために変更する必要はありません。 SQL インジェクション攻撃を阻止するためにこのアプローチが推奨され、Mule アプリケーションの全般的なパフォーマンスを向上させる最適化をコネクタが実行できます。 #### [](#入力パラメーター)入力パラメーター - **Mule 3**​ では、各入力パラメーターが ​``​ 操作内で ​``​ 要素として定義され、この要素にパラメーター名の ​`name`​ 属性と、そのパラメーター値を保持する ​`value`​ 属性がありました。 - **Mule 4**​ では、各入力パラメーターがマップの ​``​ として定義され、キーはパラメーター名で、値はパラメーター値です。このマップは DataWeave を使用してのみ作成できます。 Mule 3 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name ``` Mule 4 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name #[ { last_name : vars.lastName } ] ``` ### [](#database_dynamic_queries)動的クエリの移行 場合によっては、WHERE 句をパラメーター化するだけでなく、クエリ自体の各部をパラメーター化しなければならないことがあります。このユースケースの例として、条件に応じてオンライン/履歴テーブルにアクセスする必要のあるクエリや、プロジェクト列を変更する必要のある複雑なクエリなどが挙げられます。 Mule 3 では、選択の概念がパラメーター化クエリと動的クエリに分割されており、この両方を同時に使用することができませんでした。動的クエリを使用するか、パラメーターを使用する利点 (SQL インジェクションの防御、PreparedStatement の最適化など) をとるかのどちらかを選択する必要がありました。また、それぞれ構文が異なるため、同じことを行うのに 2 つのやり方を学ぶ必要がありました。 他方 Mule 4 では、この新しい Database Connector のクエリ内で式を用いて、この両方の方法を同時に使用できるようになりました。 Mule 3 の例: 動的 SELECT クエリ ```xml SELECT * FROM #[flowVars.table] WHERE name = #[flowVars.name] ``` Mule 4 の例: 動的 SELECT クエリ ```xml #['SELECT * FROM $(vars.table) WHERE name = $(vars.name)'] ``` 注意点: Mule 3 の例のほうがパフォーマンスに劣り、SQL インジェクション攻撃に対して脆弱です。PreparedStatements を使用せず、クエリ全体が文字列として処理されるためです。 ## [](#database_streaming)大量の結果のストリーミング ストリーミングでは、大規模なデータベーステーブルに対するクエリ結果を処理できます。特にインテグレーションのユースケースなどでは、何万件ものレコードが返されることがあります。この解決策として優れているのがストリーミングです。 ### [](#ストリーミングの有効化)ストリーミングの有効化 **Mule 3**​ では、ストリーミングがデフォルトで無効になっているため、使用する場合は有効にする必要があります。 **Mule 4**​ では、ストリーミングが常にオンですが、ランタイムで反復可能なストリーミングを実行する戦略を設定できます。この点についての詳細は、​[ストリーミングのドキュメントページ](https://docs.mulesoft.com/jp/mule-runtime/4.8/streaming-about)​を参照してください。 TIP: 反復可能なストリーミングを無効にすると、並列処理を含め、DataWeave や他のコンポーネントでストリームを何度も処理できなくなります。 ### [](#database_operation_bulk)一括操作の移行 #### [](#一括モードの有効化)一括モードの有効化 **Mule 3**​ では、​**Insert、Update、Delete**​ 操作の ​`bulkMode="true"`​ 設定で一括機能を設定します。 **Mule 4**​ では代わりに、データベースに対する一括操作専用の Bulk Insert (​``​)、Bulk Update (​``​)、Bulk Delete (​``​) を使用します。受信したペイロードに応じて、操作が動作を変更することがなくなりました。 #### [](#一括データのコンシューム)一括データのコンシューム **Mule 3**​ の一括クエリでは、コネクタが ​``​ コンポーネントと同じように機能していました。つまり、現在のペイロード値 (通常は項目のコレクション) を取り、コレクションの値ごとに ​``​ 式を実行していました。 **Mule 4**​ では若干異なり、ペイロードをコンシュームしてコレクションの要素ごとに式を実行するのではなく、エントリのコレクションを挿入する必要があります。 ##### [](#例)例: Mule 3 の例: パラメーター化クエリを使用した選択 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) ``` Mule 4 の例: 一括操作を使用した各値の取得 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) #[[{ id: 2, name: 'George', lastName: 'Costanza' }, { id: 3, name: 'Cosmo', lastName: 'Kramer' }]] ``` ### [](#database_bulk_execute)一括実行操作の移行 Mule 3 Connector の ​``​ 操作が ​``​ 操作に置換されました。 ここで注意すべき重要な点は、Mule 3 バージョンでは ​`bulk`​ という用語を使うものの、上記の例のように、実際には一括操作ではないことです。同じ接続を使用して個別のステートメントが多数実行されますが、ステートメントがまとめて作成されるわけではありません。そのため、Mule 4 では、この操作の実態を的確に説明するために ​`execute-script`​ と呼ばれています。 Mule 4 の例: `execute-script`​ 操作の使用 ```xml update PLANET set NAME='Mercury' where POSITION=0; update PLANET set NAME='Mercury' where POSITION=4 ``` ステートメントも外部ファイルに抽出できます。 Mule 4 の例: 外部ファイルを設定した ​`execute-script`​ 操作の使用 ```xml ``` ### [](#tx_actions)トランザクションのアクション データベース操作は、トランザクション内で実行されるときに、そのトランザクションとどのようにやり取りするかを決定できます。 トランザクションの選択可能なアクションは次のとおりです。 - **ALWAYS\_JOIN** - **JOIN\_IF\_POSSIBLE** - **NOT\_SUPPORTED** Mule 3 の例: トランザクションのアクション ```xml SELECT * FROM people ``` Mule 4 の例: トランザクションのアクション ```xml SELECT * FROM people ``` ### [](#output_target)出力対象 **Mule 3**​ では、DB Connector が実行した出力を任意の対象変数に保存することができました。​**Mule 4**​ でも同様に処理できますが、若干異なります。 **Mule 3**​ で出力とされていたものは単なる実行結果であり、たとえば ​`target="#[flowVars.targetVar]"`​ と設定すると、クエリの実行が ​`targetVar`​ フロー変数に保存されていました。 **Mule 4**​ でもほぼ同じで、対象のフロー変数の名前である ​`target`​ パラメーターがありますが、これを式にすることはできません。​**Mule 4**​ の新しいパラメーターは ​`targetValue`​ で、これは操作結果に対して評価される式です。たとえば、ペイロード全体を保存する場合は ​`#[payload]`​ に、SELECT クエリの 1 行目だけを保存する場合は ​`#[payload[0]]`​ になります。 Mule 3 の例: 出力対象 ```xml SELECT * FROM People ``` Mule 4 の例: 出力対象 ```xml SELECT * from People ``` Database Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-db-connector 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Database Connector の概要](https://docs.mulesoft.com/db-connector/latest/) - [Mule 4.0 でのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.8/streaming-about)​。 # Database Connector の移行 Database Connector を Mule 3 から Mule 4 に移行する場合の主な変更点は次のとおりです。 - すべてのデータベース操作 (Select、Insert、Update、Delete など) が別の操作にリファクタリングされています。Mule 4 にはまた、新しい専用の一括操作もあります。 - DataWeave の使用: データベース操作 (Insert、Update など) は DataWeave バージョン 2 の変換をサポートしています。データベースを挿入または更新するデータセットを構築できます。メッセージの副次的影響はなく、メッセージエンリッチャーも不要になりました。 - 動的クエリと静的クエリを同様の方法で実行できます。 - 各自の操作に応じて Mule ストリーミングフレームワークが自動的に設定されます。Select ステートメントを実行し、接続の漏えいを心配することなく、結果を非同期で処理できます。 ## [](#whats_covered_here)このトピックの内容 - [データベース接続の設定](#database_configuration) - [データソース参照](#data_source_ref) - [例: コネクタの詳細設定](#connector_config_detail) - [動的クエリの移行](#database_dynamic_queries) - [大量の結果のストリーミング](#database_streaming) - [一括操作の移行](#database_operation_bulk) - [一括実行操作の移行](#database_bulk_execute) - [トランザクションのアクション](#tx_actions) - [出力対象](#output_target) ## [](#database_configuration)データベース接続の設定 Mule 3 と Mule 4 の Database Connector は、Derby、MySQL、Oracle、汎用データベースの設定をサポートしています。Mule 4 では、Microsoft SQL Server とデータソース参照接続もサポートされています。 これらの接続設定の XML が Mule 4 で変更されています。 - Mule 3: データベース要素 (​``​ など) が最上位要素です。 - Mule 4: ``​ がすべてのデータベース接続設定の最上位要素で、特定のデータベース設定が個別の ​``​ 要素にネストされます。 - Derby: `` - Microsoft SQL Server: `` - MySQL: `` - Oracle: `` - 汎用: `` - データソース参照接続: `` Mule 3 の例: Derby 接続設定 ```xml ``` 上記の Mule 3 の例の ​``​ が、下記の Mule 4 の例では ​``​ に変更され、データベースへの URL の属性が Mule 4 では ​`url`​ から ​`database`​ に変更されています。Mule 4 で、新たに ​``​ 子要素が追加されました。 Mule 4 の例: Derby 接続設定 ```xml ``` さらに、Mule 4 では、新たな ​``​ 設定 (XML 属性) を使用できます。 - `create="true|false"`​: データベースが存在しない場合に作成するかどうか。 - `subsubProtocol="directory"`​: Derby が使用する SubsubProtocol の種別。選択可能なオプションは ​`directory`​、​`memory`​、​`classpath`​、​`jar`​ です。 次のセクションでは、他のデータベースの接続設定について説明します。 ### [](#data_source_ref)データソース参照 以下のトピックで、その他のデータベース接続の Mule 4 の XML の例と、コネクタに固有の設定を示します。 - [Mule 4 の例: データソース参照](#example_data_source_db) - [Mule 4 の例: 汎用](#example_generic_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [Mule 4 の例: MySQL](#example_mysql_db) - [Mule 4 の例: Oracle JDBC データベース](#example_oracle_db) - [Mule 4 の例: Microsoft SQL Server](#example_mssql_db) - [例: Microsoft SQL Server ドライバーの Maven 連動関係設定。](#example_driver) 前セクションの Derby の Mule 3 の例に、Mule 3 と Mule 4 のデータベース接続設定 (My SQL、Oracle など) の主な相違点の大半が示されています。また、データベース接続の Mule 3 から Mule 4 への主な移行パターンもわかります。 - Derby: [データベース接続の設定](#database_configuration) #### [](#example_data_source_db)Mule 4 の例: データソース参照 データソース参照を使用するには、次の手順を実行する必要があります。 1 - XML Spring Bean ファイルを作成して、​`DataSource`​ を表す Spring Bean を作成します。 datasource-spring-beans.xml ```xml ```
DataSource 実装を含む Maven 連動関係を設定する必要があります。 この例では、​org.enhydra.jdbc.standard.StandardDataSource​ に次の連動関係が必要です。

<dependency>
​<groupId>com.experlog</groupId>
​<artifactId>xapool</artifactId>
​<version>1.5.0</version>
</dependency>
2 - データソース接続を作成します。
1Mule Spring Module​ [Spring Module へのリンク] を使用して ​datasource-spring-beans.xml​ ファイルをインポートします。
2DataSource 接続を使用して DB 設定を作成し、​datasource-spring-beans.xml​ で作成された DataSource Bean の Spring Bean ID を ​dataSourceRef​ として追加します。
```xml (1) (2) ``` 以下はデータソース参照に固有の設定です。 - `dataSourceRef="my_ref_here"`​: JDBC DataSource オブジェクトへの参照。このオブジェクトは通常、Spring を使用して作成されます。XA トランザクションを使用する場合は、XADataSource オブジェクトを指定する必要があります。 #### [](#example_generic_db)Mule 4 の例: 汎用 ```xml ``` 以下は、汎用データベースに固有の設定です。 - `url="url_here"`​: データベースへの接続に使用する JDBC URL。 - `driverClassName="driver_class_name_here"`​: データベースドライバークラスの完全修飾名。
driverClassName​ パラメーターで参照されるクラスを含む Maven 連動関係は、Mule アプリケーションで設定する必要があります。
また、Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。
[データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mssql_db)Mule 4 の例: Microsoft SQL Server ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_mysql_db)Mule 4 の例: MySQL ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_oracle_db)Mule 4 の例: Oracle JDBC データベース ```xml ``` [データベースのトランザクション](#db_transactions)​も参照してください。 #### [](#example_driver)例: Microsoft SQL Server ドライバーの Maven 連動関係設定。 Microsoft SQL Server、MySQL、Derby、Oracle の設定にはドライバーが必要です。 ```xml com.microsoft.sqlserver mssql-jdbc 6.2.2.jre8 ```
Mule 4 の新しい ClassLoading メカニズムにより、この連動関係は DB Connector にエクスポートする共有ライブラリとして宣言する必要があります。Studio を使用して自動的に設定されます。
### [](#connector_config_detail)例: コネクタの詳細設定 Mule 4 では、次の設定の子要素をデータベース接続設定 (​``​ など) で追加できます。 - [データベースのトランザクション](#db_transactions) - [トランザクションのアクション](#tx_actions) - [トランザクション分離](#tx_isolation) - [XA トランザクション](#xa_tx) - [Connection Properties (接続プロパティ)](#connection_properties) - [列の型](#column_types) - [プーリングプロファイル](#pooling_profile) - [再接続戦略](#reconnection_strategies) #### [](#db_transactions)データベースのトランザクション ##### [](#tx_isolation)トランザクション分離 トランザクションには、データベースの接続時にドライバーに設定するトランザクション分離レベルがあります。 - **NOT\_CONFIGURED**​ (デフォルト) - **READ\_COMMITTED**​ (​`transactionIsolation="READ_COMMITTED"`​) - **READ\_UNCOMMITTED**​ (​`transactionIsolation="READ_UNCOMMITTED"`​) - **REPEATABLE\_READ**​ (​`transactionIsolation="REPEATABLE_READ"`​) - **SERIALIZABLE**​ (​`transactionIsolation="SERIALIZABLE"`​) Mule 3 の例: トランザクション分離 ```xml ``` Mule 4 の例: トランザクション分離 ```xml ``` ##### [](#xa_tx)XA トランザクション **Mule 3**​ と ​**Mule 4**​ のどちらも、XA トランザクションで機能する接続を ​`useXaTransactions="true"`​ 接続設定で定義できます。 Mule 3 の例: XA トランザクション ```xml ``` Mule 4 の例: XA トランザクション ```xml ``` #### [](#connection_properties)Connection Properties (接続プロパティ) **MySQL**​ と ​**Microsoft SQL Server**​ のデータベース設定で接続プロパティ設定を指定します。これらのプロパティは JDBC 接続に、追加のプロパティとして挿入されます。 Mule 3 の例: 接続プロパティ ```xml ``` Mule 4 の例: 接続プロパティ ```xml ``` #### [](#column_types)列の型 - 列の型 (​``​): 標準以外の列の型。 #### [](#pooling_profile)プーリングプロファイル - プーリングプロファイル (​``​): 接続プーリング接続が可能な JDBC データソース。Mule 3 の接続プーリングとほぼ同じです。 #### [](#reconnection_strategies)再接続戦略 Mule 3 と Mule 4 の再接続戦略設定はよく似ています。ただし、Mule 4 ではカスタム再接続戦略を使用できません。 以下の例は、これらの設定の XML への変更点を示しています。 - **None (なし)**​: デフォルト。Mule 3 の \[Do Not Use A Reconnection Strategy (再接続戦略を使用しない)\] と同じです。 - **Standard (標準)**​: Mule 3 の \[Standard Reconnection (標準再接続)\] と同じです。どちらもオプションは、\[Frequency (ms) (頻度 (ミリ秒))\] と \[Reconnection Attempts (再接続試行回数)\] です。 - **Forever (無期限)**​: Mule 3 の \[Reconnect Forever (繰り返し再接続)\] と同じです。 Mule 3 の例: 再接続設定 ```xml ` ` ``` Mule 4 の例: 再接続設定 ```xml ``` ## [](#database_operations_overview)Database Connector の操作 - SQL クエリのテキストや入力パラメーターのクエリ - ストリーミング戦略設定 (​[大量の結果のストリーミング](#database_streaming)​を参照) - [トランザクションのアクション](#tx_actions) - クエリ設定 - エラー (DB:BAD\_SQL\_SYNTAX​、DB:QUERY\_EXECUTION​ など) のエラーマッピング - Mule 4 の属性、ペイロード、変数の入力および出力メタデータ ### [](#database_parameterized_queries)パラメーター化クエリの移行 **Mule 3**​ と ​**Mule 4**​ のどちらも、入力パラメーターはキー - 値のペアとして指定します。 このキーにセミコロン文字 (:) を付けて、名前でパラメーター値を参照します。つまり、​**Mule 3**​ で記述された SQL のパラメーター化クエリを、​**Mule 4**​ で使用するために変更する必要はありません。 SQL インジェクション攻撃を阻止するためにこのアプローチが推奨され、Mule アプリケーションの全般的なパフォーマンスを向上させる最適化をコネクタが実行できます。 #### [](#入力パラメーター)入力パラメーター - **Mule 3**​ では、各入力パラメーターが ​``​ 操作内で ​``​ 要素として定義され、この要素にパラメーター名の ​`name`​ 属性と、そのパラメーター値を保持する ​`value`​ 属性がありました。 - **Mule 4**​ では、各入力パラメーターがマップの ​``​ として定義され、キーはパラメーター名で、値はパラメーター値です。このマップは DataWeave を使用してのみ作成できます。 Mule 3 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name ``` Mule 4 の例: パラメーター化された SELECT クエリ ```xml SELECT * FROM employees WHERE last_name = :last_name #[ { last_name : vars.lastName } ] ``` ### [](#database_dynamic_queries)動的クエリの移行 場合によっては、WHERE 句をパラメーター化するだけでなく、クエリ自体の各部をパラメーター化しなければならないことがあります。このユースケースの例として、条件に応じてオンライン/履歴テーブルにアクセスする必要のあるクエリや、プロジェクト列を変更する必要のある複雑なクエリなどが挙げられます。 Mule 3 では、選択の概念がパラメーター化クエリと動的クエリに分割されており、この両方を同時に使用することができませんでした。動的クエリを使用するか、パラメーターを使用する利点 (SQL インジェクションの防御、PreparedStatement の最適化など) をとるかのどちらかを選択する必要がありました。また、それぞれ構文が異なるため、同じことを行うのに 2 つのやり方を学ぶ必要がありました。 他方 Mule 4 では、この新しい Database Connector のクエリ内で式を用いて、この両方の方法を同時に使用できるようになりました。 Mule 3 の例: 動的 SELECT クエリ ```xml SELECT * FROM #[flowVars.table] WHERE name = #[flowVars.name] ``` Mule 4 の例: 動的 SELECT クエリ ```xml #['SELECT * FROM $(vars.table) WHERE name = $(vars.name)'] ``` 注意点: Mule 3 の例のほうがパフォーマンスに劣り、SQL インジェクション攻撃に対して脆弱です。PreparedStatements を使用せず、クエリ全体が文字列として処理されるためです。 ## [](#database_streaming)大量の結果のストリーミング ストリーミングでは、大規模なデータベーステーブルに対するクエリ結果を処理できます。特にインテグレーションのユースケースなどでは、何万件ものレコードが返されることがあります。この解決策として優れているのがストリーミングです。 ### [](#ストリーミングの有効化)ストリーミングの有効化 **Mule 3**​ では、ストリーミングがデフォルトで無効になっているため、使用する場合は有効にする必要があります。 **Mule 4**​ では、ストリーミングが常にオンですが、ランタイムで反復可能なストリーミングを実行する戦略を設定できます。この点についての詳細は、​[ストリーミングのドキュメントページ](https://docs.mulesoft.com/jp/mule-runtime/4.9/streaming-about)​を参照してください。 TIP: 反復可能なストリーミングを無効にすると、並列処理を含め、DataWeave や他のコンポーネントでストリームを何度も処理できなくなります。 ### [](#database_operation_bulk)一括操作の移行 #### [](#一括モードの有効化)一括モードの有効化 **Mule 3**​ では、​**Insert、Update、Delete**​ 操作の ​`bulkMode="true"`​ 設定で一括機能を設定します。 **Mule 4**​ では代わりに、データベースに対する一括操作専用の Bulk Insert (​``​)、Bulk Update (​``​)、Bulk Delete (​``​) を使用します。受信したペイロードに応じて、操作が動作を変更することがなくなりました。 #### [](#一括データのコンシューム)一括データのコンシューム **Mule 3**​ の一括クエリでは、コネクタが ​``​ コンポーネントと同じように機能していました。つまり、現在のペイロード値 (通常は項目のコレクション) を取り、コレクションの値ごとに ​``​ 式を実行していました。 **Mule 4**​ では若干異なり、ペイロードをコンシュームしてコレクションの要素ごとに式を実行するのではなく、エントリのコレクションを挿入する必要があります。 ##### [](#例)例: Mule 3 の例: パラメーター化クエリを使用した選択 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) ``` Mule 4 の例: 一括操作を使用した各値の取得 ```xml INSERT INTO customers (id, name, lastName) VALUES (:id, :name, :lastName) #[[{ id: 2, name: 'George', lastName: 'Costanza' }, { id: 3, name: 'Cosmo', lastName: 'Kramer' }]] ``` ### [](#database_bulk_execute)一括実行操作の移行 Mule 3 Connector の ​``​ 操作が ​``​ 操作に置換されました。 ここで注意すべき重要な点は、Mule 3 バージョンでは ​`bulk`​ という用語を使うものの、上記の例のように、実際には一括操作ではないことです。同じ接続を使用して個別のステートメントが多数実行されますが、ステートメントがまとめて作成されるわけではありません。そのため、Mule 4 では、この操作の実態を的確に説明するために ​`execute-script`​ と呼ばれています。 Mule 4 の例: `execute-script`​ 操作の使用 ```xml update PLANET set NAME='Mercury' where POSITION=0; update PLANET set NAME='Mercury' where POSITION=4 ``` ステートメントも外部ファイルに抽出できます。 Mule 4 の例: 外部ファイルを設定した ​`execute-script`​ 操作の使用 ```xml ``` ### [](#tx_actions)トランザクションのアクション データベース操作は、トランザクション内で実行されるときに、そのトランザクションとどのようにやり取りするかを決定できます。 トランザクションの選択可能なアクションは次のとおりです。 - **ALWAYS\_JOIN** - **JOIN\_IF\_POSSIBLE** - **NOT\_SUPPORTED** Mule 3 の例: トランザクションのアクション ```xml SELECT * FROM people ``` Mule 4 の例: トランザクションのアクション ```xml SELECT * FROM people ``` ### [](#output_target)出力対象 **Mule 3**​ では、DB Connector が実行した出力を任意の対象変数に保存することができました。​**Mule 4**​ でも同様に処理できますが、若干異なります。 **Mule 3**​ で出力とされていたものは単なる実行結果であり、たとえば ​`target="#[flowVars.targetVar]"`​ と設定すると、クエリの実行が ​`targetVar`​ フロー変数に保存されていました。 **Mule 4**​ でもほぼ同じで、対象のフロー変数の名前である ​`target`​ パラメーターがありますが、これを式にすることはできません。​**Mule 4**​ の新しいパラメーターは ​`targetValue`​ で、これは操作結果に対して評価される式です。たとえば、ペイロード全体を保存する場合は ​`#[payload]`​ に、SELECT クエリの 1 行目だけを保存する場合は ​`#[payload[0]]`​ になります。 Mule 3 の例: 出力対象 ```xml SELECT * FROM People ``` Mule 4 の例: 出力対象 ```xml SELECT * from People ``` Database Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-db-connector 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Database Connector の概要](https://docs.mulesoft.com/db-connector/latest/) - [Mule 4.0 でのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.9/streaming-about)​。 # DataWeave の概要 DataWeave は、Mule アプリケーションを通過したデータにアクセスし、変換するための MuleSoft 式言語です。DataWeave は、Mule アプリケーション内でスクリプトと式を実行する Mule Runtime Engine と緊密に統合します。 DataWeave スクリプトは、Mule イベントのデータに対して動作します。一般には、これを使用してメッセージペイロード内のデータにアクセスし、データを変換します。たとえば、アプリケーション内のコンポーネントで 1 つのシステムからデータを取得した後、DataWeave を使用して、そのデータ内の選択した項目を新しいデータ形式に変更して出力します。次に、アプリケーション内の別のコンポーネントを使用してそのデータを別のシステムに渡すことができます。 - DataWeave 2.3.0 for Mule Runtime Engine (Mule) バージョン 4.3 以降の使用を開始するには、​[クイックスタート](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-quickstart)​を参照してください。 - DataWeave についての詳細は、​[言語ガイド](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-language-guide)​を参照してください。 - DataWeave 2.3.0 の操作および関数についてのリファレンス情報は、​[リファレンスガイド](https://docs.mulesoft.com/jp/dataweave/2.3/dw-functions)​を参照してください。 ## [](#互換性)互換性 This table specifies which version of DataWeave is bundled with each Mule runtime engine release:
Mule Version DataWeave Version

4.13

2.13

4.12

2.12

4.11

2.11

4.10

2.10

4.9

2.9

4.8

2.8

4.7

2.7

4.6

2.6

4.5

2.5

4.4

2.4

4.3

2.3

4.2

2.2

4.1

2.1

3.9

1.2

3.8

1.1

3.7

1.0
## [](#関連情報)関連情報 - [Dataweave](https://docs.mulesoft.com/dataweave/latest/) # DataWeave の概要 DataWeave は、Mule アプリケーションを通過するデータへのアクセスとデータの変換を行うための言語で、MuleSoft により設計されました。Mule Runtime Engine では、Transform や Set Payload など、いくつかのコアコンポーネントに DataWeave が組み込まれているため、Mule アプリケーションで DataWeave スクリプトや式を実行できます。 DataWeave スクリプトは、Mule イベントのデータに対して動作します。一般には、これを使用してメッセージペイロード内のデータにアクセスし、データを変換します。たとえば、Mule アプリケーション内のコンポーネントで 1 つのシステムからデータを取得した後、DataWeave を使用して、そのデータ内の選択した項目を新しいデータ形式に変更して出力します。次に、アプリケーション内の別のコンポーネントを使用してそのデータを別のシステムに渡すことができます。 - DataWeave 2.4.0 for Mule Runtime Engine (Mule) バージョン 4.4 以降の使用を開始するには、​[クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照してください。 - DataWeave についての詳細は、​[言語ガイド](https://docs.mulesoft.com/dataweave/latest/dataweave-language-guide)​を参照してください。 - DataWeave 2.4.0 の操作および関数についてのリファレンス情報は、​[リファレンスガイド](https://docs.mulesoft.com/dataweave/latest/dw-functions)​を参照してください。 ## [](#互換性)互換性 This table specifies which version of DataWeave is bundled with each Mule runtime engine release:
Mule Version DataWeave Version

4.13

2.13

4.12

2.12

4.11

2.11

4.10

2.10

4.9

2.9

4.8

2.8

4.7

2.7

4.6

2.6

4.5

2.5

4.4

2.4

4.3

2.3

4.2

2.2

4.1

2.1

3.9

1.2

3.8

1.1

3.7

1.0
## [](#関連情報)関連情報 - [Dataweave](https://docs.mulesoft.com/dataweave/latest/) # DataWeave の概要 DataWeave は、Mule アプリケーションを通過するデータへのアクセスとデータの変換を行うための言語で、MuleSoft により設計されました。Mule Runtime Engine では、Transform や Set Payload など、いくつかのコアコンポーネントに DataWeave が組み込まれているため、Mule アプリケーションで DataWeave スクリプトや式を実行できます。 DataWeave スクリプトは、Mule イベントのデータに対して動作します。一般には、これを使用してメッセージペイロード内のデータにアクセスし、データを変換します。たとえば、Mule アプリケーション内のコンポーネントで 1 つのシステムからデータを取得した後、DataWeave を使用して、そのデータ内の選択した項目を新しいデータ形式に変更して出力します。次に、アプリケーション内の別のコンポーネントを使用してそのデータを別のシステムに渡すことができます。 - DataWeave 2.4.0 for Mule Runtime Engine (Mule) バージョン 4.4 以降の使用を開始するには、​[クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照してください。 - DataWeave についての詳細は、​[言語ガイド](https://docs.mulesoft.com/dataweave/latest/dataweave-language-guide)​を参照してください。 - DataWeave 2.4.0 の操作および関数についてのリファレンス情報は、​[リファレンスガイド](https://docs.mulesoft.com/dataweave/latest/dw-functions)​を参照してください。 ## [](#互換性)互換性 This table specifies which version of DataWeave is bundled with each Mule runtime engine release:
Mule Version DataWeave Version

4.13

2.13

4.12

2.12

4.11

2.11

4.10

2.10

4.9

2.9

4.8

2.8

4.7

2.7

4.6

2.6

4.5

2.5

4.4

2.4

4.3

2.3

4.2

2.2

4.1

2.1

3.9

1.2

3.8

1.1

3.7

1.0
## [](#関連情報)関連情報 - [Dataweave](https://docs.mulesoft.com/dataweave/latest/) # DataWeave の概要 DataWeave は、Mule アプリケーションを通過するデータへのアクセスとデータの変換を行うための言語で、MuleSoft により設計されました。Mule Runtime Engine では、Transform や Set Payload など、いくつかのコアコンポーネントに DataWeave が組み込まれているため、Mule アプリケーションで DataWeave スクリプトや式を実行できます。 DataWeave スクリプトは、Mule イベントのデータに対して動作します。一般には、これを使用してメッセージペイロード内のデータにアクセスし、データを変換します。たとえば、Mule アプリケーション内のコンポーネントで 1 つのシステムからデータを取得した後、DataWeave を使用して、そのデータ内の選択した項目を新しいデータ形式に変更して出力します。次に、アプリケーション内の別のコンポーネントを使用してそのデータを別のシステムに渡すことができます。 - DataWeave 2.4.0 for Mule Runtime Engine (Mule) バージョン 4.4 以降の使用を開始するには、​[クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照してください。 - DataWeave についての詳細は、​[言語ガイド](https://docs.mulesoft.com/dataweave/latest/dataweave-language-guide)​を参照してください。 - DataWeave 2.4.0 の操作および関数についてのリファレンス情報は、​[リファレンスガイド](https://docs.mulesoft.com/dataweave/latest/dw-functions)​を参照してください。 ## [](#互換性)互換性 This table specifies which version of DataWeave is bundled with each Mule runtime engine release:
Mule Version DataWeave Version

4.13

2.13

4.12

2.12

4.11

2.11

4.10

2.10

4.9

2.9

4.8

2.8

4.7

2.7

4.6

2.6

4.5

2.5

4.4

2.4

4.3

2.3

4.2

2.2

4.1

2.1

3.9

1.2

3.8

1.1

3.7

1.0
## [](#関連情報)関連情報 - [Dataweave](https://docs.mulesoft.com/dataweave/latest/) # DataWeave の概要 DataWeave は、Mule アプリケーションを通過するデータへのアクセスとデータの変換を行うための言語で、MuleSoft により設計されました。Mule Runtime Engine では、Transform や Set Payload など、いくつかのコアコンポーネントに DataWeave が組み込まれているため、Mule アプリケーションで DataWeave スクリプトや式を実行できます。 DataWeave スクリプトは、Mule イベントのデータに対して動作します。一般には、これを使用してメッセージペイロード内のデータにアクセスし、データを変換します。たとえば、Mule アプリケーション内のコンポーネントで 1 つのシステムからデータを取得した後、DataWeave を使用して、そのデータ内の選択した項目を新しいデータ形式に変更して出力します。次に、アプリケーション内の別のコンポーネントを使用してそのデータを別のシステムに渡すことができます。 - DataWeave 2.4.0 for Mule Runtime Engine (Mule) バージョン 4.4 以降の使用を開始するには、​[クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照してください。 - DataWeave についての詳細は、​[言語ガイド](https://docs.mulesoft.com/dataweave/latest/dataweave-language-guide)​を参照してください。 - DataWeave 2.4.0 の操作および関数についてのリファレンス情報は、​[リファレンスガイド](https://docs.mulesoft.com/dataweave/latest/dw-functions)​を参照してください。 ## [](#互換性)互換性 This table specifies which version of DataWeave is bundled with each Mule runtime engine release:
Mule Version DataWeave Version

4.13

2.13

4.12

2.12

4.11

2.11

4.10

2.10

4.9

2.9

4.8

2.8

4.7

2.7

4.6

2.6

4.5

2.5

4.4

2.4

4.3

2.3

4.2

2.2

4.1

2.1

3.9

1.2

3.8

1.1

3.7

1.0
## [](#関連情報)関連情報 - [Dataweave](https://docs.mulesoft.com/dataweave/latest/) # DataWeave の概要 DataWeave は、Mule アプリケーションを通過するデータへのアクセスとデータの変換を行うための言語で、MuleSoft により設計されました。Mule Runtime Engine では、Transform や Set Payload など、いくつかのコアコンポーネントに DataWeave が組み込まれているため、Mule アプリケーションで DataWeave スクリプトや式を実行できます。 DataWeave スクリプトは、Mule イベントのデータに対して動作します。一般には、これを使用してメッセージペイロード内のデータにアクセスし、データを変換します。たとえば、Mule アプリケーション内のコンポーネントで 1 つのシステムからデータを取得した後、DataWeave を使用して、そのデータ内の選択した項目を新しいデータ形式に変更して出力します。次に、アプリケーション内の別のコンポーネントを使用してそのデータを別のシステムに渡すことができます。 - DataWeave 2.4.0 for Mule Runtime Engine (Mule) バージョン 4.4 以降の使用を開始するには、​[クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照してください。 - DataWeave についての詳細は、​[言語ガイド](https://docs.mulesoft.com/dataweave/latest/dataweave-language-guide)​を参照してください。 - DataWeave 2.4.0 の操作および関数についてのリファレンス情報は、​[リファレンスガイド](https://docs.mulesoft.com/dataweave/latest/dw-functions)​を参照してください。 ## [](#互換性)互換性 This table specifies which version of DataWeave is bundled with each Mule runtime engine release:
Mule Version DataWeave Version

4.13

2.13

4.12

2.12

4.11

2.11

4.10

2.10

4.9

2.9

4.8

2.8

4.7

2.7

4.6

2.6

4.5

2.5

4.4

2.4

4.3

2.3

4.2

2.2

4.1

2.1

3.9

1.2

3.8

1.1

3.7

1.0
## [](#関連情報)関連情報 - [Dataweave](https://docs.mulesoft.com/dataweave/latest/) # DataWeave の概要 DataWeave は、Mule アプリケーションを通過するデータへのアクセスとデータの変換を行うための言語で、MuleSoft により設計されました。Mule Runtime Engine では、Transform や Set Payload など、いくつかのコアコンポーネントに DataWeave が組み込まれているため、Mule アプリケーションで DataWeave スクリプトや式を実行できます。 DataWeave スクリプトは、Mule イベントのデータに対して動作します。一般には、これを使用してメッセージペイロード内のデータにアクセスし、データを変換します。たとえば、Mule アプリケーション内のコンポーネントで 1 つのシステムからデータを取得した後、DataWeave を使用して、そのデータ内の選択した項目を新しいデータ形式に変更して出力します。次に、アプリケーション内の別のコンポーネントを使用してそのデータを別のシステムに渡すことができます。 - DataWeave 2.4.0 for Mule Runtime Engine (Mule) バージョン 4.4 以降の使用を開始するには、​[クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照してください。 - DataWeave についての詳細は、​[言語ガイド](https://docs.mulesoft.com/dataweave/latest/dataweave-language-guide)​を参照してください。 - DataWeave 2.4.0 の操作および関数についてのリファレンス情報は、​[リファレンスガイド](https://docs.mulesoft.com/dataweave/latest/dw-functions)​を参照してください。 ## [](#互換性)互換性 This table specifies which version of DataWeave is bundled with each Mule runtime engine release:
Mule Version DataWeave Version

4.13

2.13

4.12

2.12

4.11

2.11

4.10

2.10

4.9

2.9

4.8

2.8

4.7

2.7

4.6

2.6

4.5

2.5

4.4

2.4

4.3

2.3

4.2

2.2

4.1

2.1

3.9

1.2

3.8

1.1

3.7

1.0
## [](#関連情報)関連情報 - [Dataweave](https://docs.mulesoft.com/dataweave/latest/) # DataWeave バージョン 1 から 2 への移行 - [DataWeave ヘッダーのコンテンツ](#dw_header) - [フローコントロール](#dw_flow_control) - [型の参照](#dw_type_references) - [オブジェクトの強制型変換](#dw_object_coercion) - [条件付きキー - 値の括弧](#dw_cond_key_value_parens) ## [](#dw_header)DataWeave ヘッダーのコンテンツ DataWeave ではヘッダーのほとんどのディレクティブが変更されました。​`%dw`​ ディレクティブは例外です。ほとんどの場合 ​`%`​ が削除され、一部はキーワードが短縮されています。
DataWeave 1.0 DataWeave 2.0 コメント

%dw 1.0​

%dw 2.0

%input​

input

Mule アプリケーションフローでは、DataWeave 2.0 は先行するコンポーネントで指定された MIME タイプ (​outputMimeType​) とパラメーターに基づいて、入力 MIME タイプとそのリーダープロパティを認識します。入力 MIME タイプは、ヘッダーの ​input​ ディレクティブを使用して定義されなくなりました。 ただし、​input​ ディレクティブは、​ストリーミングされたデータのスクリプトの検証​などの特定のケースで引き続き使用されます。

%output​

output

%var​

var​

%function

fun​

%namespace

ns​
## [](#dw_flow_control)フローコントロール DataWeave 2 ではフローコントロールが若干変更されました。 ### [](#dw_flow_control_when_otherwise)When Otherwise `when otherwise`​ ステートメントは ​`if else`​ に置き換わります。次に例を示します。 Mule 3 の例: DataWeave 1 ```dataweave { orderStatus: "complete" when flowVars.purchaseOrderStatus == "C" otherwise "incomplete" } ``` Mule 4 の例: DataWeave 2 ```dataweave { orderStatus: if(vars.purchaseOrderStatus == "C") "complete" else "incomplete" } ``` ### [](#dw_flow_control_pattern_matcher)パターンマッチャー DataWeave 2 ではパターン一致が変更されました。キーワード ​`case`​ と (​`default`​ ではなく) ​`else`​ が追加されます。また、​`case`​ キーワードで明示的に区切られるので、ケースをカンマ (​`,`​) で区切らなくなりました。 Mule 3 の例: DataWeave 1 ```dataweave 'world' match { :string -> true, default -> false } ``` Mule 4 の例: DataWeave 2 ```dataweave 'world' match { case is String -> true else -> false } ``` 型のパターンマッチャーの場合は、​`is`​ キーワードを設定する必要があります。 ## [](#dw_type_references)型の参照 型の参照から ​`:`​ が削除され、すべてがキャメルケースになりました。したがって、​`:string`​ は ​`String`​ になりました。 ## [](#dw_object_coercion)オブジェクトの強制型変換 DataWeave 1.0 では、オブジェクトからキー - 値ペアを選択するには、以下を実行する必要がありました。 Mule 3 の例: DataWeave 1 ```dataweave %var payload = {a: 1, b:2} --- payload.a as :object ``` 上記の DataWeave 1.0 の式は、​`{a:1}`​ を返します。これは強制型変換なので、自動強制型変換メカニズムにも含まれており、望ましくない、または予期しない結果が生じます。 DataWeave 2.0 では強制型変換が削除され、キー - 値ペアの括弧を選択する新しいセレクター (​`&`​) が導入されています。 Mule 3 の例: DataWeave 2 ```dataweave var payload = {a: 1, b:2} --- payload.&a ``` この式も ​`{a:1}`​ を返します。 ## [](#dw_cond_key_value_parens)条件付きキー - 値の括弧 DataWeave 1.0 では、条件付きキー - 値ペアは ​`when`​ キーワードで宣言されます。 Mule 3 の例: DataWeave 1 ```dataweave { (a: 1) when payload.product == "Mule" } ``` DataWeave 2.0 では、​`if`​ キーワードを使用します。 Mule 4 の例: DataWeave 2 ```dataweave { (a: 1) if payload.product == "Mule" } ``` ## [](#関連情報)関連情報 [Mule 4 の概要: DataWeave 2.0](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-dataweave2) # DataWeave バージョン 1 から 2 への移行 - [DataWeave ヘッダーのコンテンツ](#dw_header) - [フローコントロール](#dw_flow_control) - [型の参照](#dw_type_references) - [オブジェクトの強制型変換](#dw_object_coercion) - [条件付きキー - 値の括弧](#dw_cond_key_value_parens) ## [](#dw_header)DataWeave ヘッダーのコンテンツ DataWeave ではヘッダーのほとんどのディレクティブが変更されました。​`%dw`​ ディレクティブは例外です。ほとんどの場合 ​`%`​ が削除され、一部はキーワードが短縮されています。
DataWeave 1.0 DataWeave 2.0 コメント

%dw 1.0​

%dw 2.0

%input​

input

Mule アプリケーションフローでは、DataWeave 2.0 は先行するコンポーネントで指定された MIME タイプ (​outputMimeType​) とパラメーターに基づいて、入力 MIME タイプとそのリーダープロパティを認識します。入力 MIME タイプは、ヘッダーの ​input​ ディレクティブを使用して定義されなくなりました。 ただし、​input​ ディレクティブは、​ストリーミングされたデータのスクリプトの検証​などの特定のケースで引き続き使用されます。

%output​

output

%var​

var​

%function

fun​

%namespace

ns​
## [](#dw_flow_control)フローコントロール DataWeave 2 ではフローコントロールが若干変更されました。 ### [](#dw_flow_control_when_otherwise)When Otherwise `when otherwise`​ ステートメントは ​`if else`​ に置き換わります。次に例を示します。 Mule 3 の例: DataWeave 1 ```dataweave { orderStatus: "complete" when flowVars.purchaseOrderStatus == "C" otherwise "incomplete" } ``` Mule 4 の例: DataWeave 2 ```dataweave { orderStatus: if(vars.purchaseOrderStatus == "C") "complete" else "incomplete" } ``` ### [](#dw_flow_control_pattern_matcher)パターンマッチャー DataWeave 2 ではパターン一致が変更されました。キーワード ​`case`​ と (​`default`​ ではなく) ​`else`​ が追加されます。また、​`case`​ キーワードで明示的に区切られるので、ケースをカンマ (​`,`​) で区切らなくなりました。 Mule 3 の例: DataWeave 1 ```dataweave 'world' match { :string -> true, default -> false } ``` Mule 4 の例: DataWeave 2 ```dataweave 'world' match { case is String -> true else -> false } ``` 型のパターンマッチャーの場合は、​`is`​ キーワードを設定する必要があります。 ## [](#dw_type_references)型の参照 型の参照から ​`:`​ が削除され、すべてがキャメルケースになりました。したがって、​`:string`​ は ​`String`​ になりました。 ## [](#dw_object_coercion)オブジェクトの強制型変換 DataWeave 1.0 では、オブジェクトからキー - 値ペアを選択するには、以下を実行する必要がありました。 Mule 3 の例: DataWeave 1 ```dataweave %var payload = {a: 1, b:2} --- payload.a as :object ``` 上記の DataWeave 1.0 の式は、​`{a:1}`​ を返します。これは強制型変換なので、自動強制型変換メカニズムにも含まれており、望ましくない、または予期しない結果が生じます。 DataWeave 2.0 では強制型変換が削除され、キー - 値ペアの括弧を選択する新しいセレクター (​`&`​) が導入されています。 Mule 3 の例: DataWeave 2 ```dataweave var payload = {a: 1, b:2} --- payload.&a ``` この式も ​`{a:1}`​ を返します。 ## [](#dw_cond_key_value_parens)条件付きキー - 値の括弧 DataWeave 1.0 では、条件付きキー - 値ペアは ​`when`​ キーワードで宣言されます。 Mule 3 の例: DataWeave 1 ```dataweave { (a: 1) when payload.product == "Mule" } ``` DataWeave 2.0 では、​`if`​ キーワードを使用します。 Mule 4 の例: DataWeave 2 ```dataweave { (a: 1) if payload.product == "Mule" } ``` ## [](#関連情報)関連情報 [Mule 4 の概要: DataWeave 2.0](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-dataweave2) # DataWeave バージョン 1 から 2 への移行 - [DataWeave ヘッダーのコンテンツ](#dw_header) - [フローコントロール](#dw_flow_control) - [型の参照](#dw_type_references) - [オブジェクトの強制型変換](#dw_object_coercion) - [条件付きキー - 値の括弧](#dw_cond_key_value_parens) ## [](#dw_header)DataWeave ヘッダーのコンテンツ DataWeave ではヘッダーのほとんどのディレクティブが変更されました。​`%dw`​ ディレクティブは例外です。ほとんどの場合 ​`%`​ が削除され、一部はキーワードが短縮されています。
DataWeave 1.0 DataWeave 2.0 コメント

%dw 1.0​

%dw 2.0

%input​

input

Mule アプリケーションフローでは、DataWeave 2.0 は先行するコンポーネントで指定された MIME タイプ (​outputMimeType​) とパラメーターに基づいて、入力 MIME タイプとそのリーダープロパティを認識します。入力 MIME タイプは、ヘッダーの ​input​ ディレクティブを使用して定義されなくなりました。 ただし、​input​ ディレクティブは、​ストリーミングされたデータのスクリプトの検証​などの特定のケースで引き続き使用されます。

%output​

output

%var​

var​

%function

fun​

%namespace

ns​
## [](#dw_flow_control)フローコントロール DataWeave 2 ではフローコントロールが若干変更されました。 ### [](#dw_flow_control_when_otherwise)When Otherwise `when otherwise`​ ステートメントは ​`if else`​ に置き換わります。次に例を示します。 Mule 3 の例: DataWeave 1 ```dataweave { orderStatus: "complete" when flowVars.purchaseOrderStatus == "C" otherwise "incomplete" } ``` Mule 4 の例: DataWeave 2 ```dataweave { orderStatus: if(vars.purchaseOrderStatus == "C") "complete" else "incomplete" } ``` ### [](#dw_flow_control_pattern_matcher)パターンマッチャー DataWeave 2 ではパターン一致が変更されました。キーワード ​`case`​ と (​`default`​ ではなく) ​`else`​ が追加されます。また、​`case`​ キーワードで明示的に区切られるので、ケースをカンマ (​`,`​) で区切らなくなりました。 Mule 3 の例: DataWeave 1 ```dataweave 'world' match { :string -> true, default -> false } ``` Mule 4 の例: DataWeave 2 ```dataweave 'world' match { case is String -> true else -> false } ``` 型のパターンマッチャーの場合は、​`is`​ キーワードを設定する必要があります。 ## [](#dw_type_references)型の参照 型の参照から ​`:`​ が削除され、すべてがキャメルケースになりました。したがって、​`:string`​ は ​`String`​ になりました。 ## [](#dw_object_coercion)オブジェクトの強制型変換 DataWeave 1.0 では、オブジェクトからキー - 値ペアを選択するには、以下を実行する必要がありました。 Mule 3 の例: DataWeave 1 ```dataweave %var payload = {a: 1, b:2} --- payload.a as :object ``` 上記の DataWeave 1.0 の式は、​`{a:1}`​ を返します。これは強制型変換なので、自動強制型変換メカニズムにも含まれており、望ましくない、または予期しない結果が生じます。 DataWeave 2.0 では強制型変換が削除され、キー - 値ペアの括弧を選択する新しいセレクター (​`&`​) が導入されています。 Mule 3 の例: DataWeave 2 ```dataweave var payload = {a: 1, b:2} --- payload.&a ``` この式も ​`{a:1}`​ を返します。 ## [](#dw_cond_key_value_parens)条件付きキー - 値の括弧 DataWeave 1.0 では、条件付きキー - 値ペアは ​`when`​ キーワードで宣言されます。 Mule 3 の例: DataWeave 1 ```dataweave { (a: 1) when payload.product == "Mule" } ``` DataWeave 2.0 では、​`if`​ キーワードを使用します。 Mule 4 の例: DataWeave 2 ```dataweave { (a: 1) if payload.product == "Mule" } ``` ## [](#関連情報)関連情報 [Mule 4 の概要: DataWeave 2.0](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-dataweave2) # DataWeave バージョン 1 から 2 への移行 - [DataWeave ヘッダーのコンテンツ](#dw_header) - [フローコントロール](#dw_flow_control) - [型の参照](#dw_type_references) - [オブジェクトの強制型変換](#dw_object_coercion) - [条件付きキー - 値の括弧](#dw_cond_key_value_parens) ## [](#dw_header)DataWeave ヘッダーのコンテンツ DataWeave ではヘッダーのほとんどのディレクティブが変更されました。​`%dw`​ ディレクティブは例外です。ほとんどの場合 ​`%`​ が削除され、一部はキーワードが短縮されています。
DataWeave 1.0 DataWeave 2.0 コメント

%dw 1.0​

%dw 2.0

%input​

input

Mule アプリケーションフローでは、DataWeave 2.0 は先行するコンポーネントで指定された MIME タイプ (​outputMimeType​) とパラメーターに基づいて、入力 MIME タイプとそのリーダープロパティを認識します。入力 MIME タイプは、ヘッダーの ​input​ ディレクティブを使用して定義されなくなりました。 ただし、​input​ ディレクティブは、​ストリーミングされたデータのスクリプトの検証​などの特定のケースで引き続き使用されます。

%output​

output

%var​

var​

%function

fun​

%namespace

ns​
## [](#dw_flow_control)フローコントロール DataWeave 2 ではフローコントロールが若干変更されました。 ### [](#dw_flow_control_when_otherwise)When Otherwise `when otherwise`​ ステートメントは ​`if else`​ に置き換わります。次に例を示します。 Mule 3 の例: DataWeave 1 ```dataweave { orderStatus: "complete" when flowVars.purchaseOrderStatus == "C" otherwise "incomplete" } ``` Mule 4 の例: DataWeave 2 ```dataweave { orderStatus: if(vars.purchaseOrderStatus == "C") "complete" else "incomplete" } ``` ### [](#dw_flow_control_pattern_matcher)パターンマッチャー DataWeave 2 ではパターン一致が変更されました。キーワード ​`case`​ と (​`default`​ ではなく) ​`else`​ が追加されます。また、​`case`​ キーワードで明示的に区切られるので、ケースをカンマ (​`,`​) で区切らなくなりました。 Mule 3 の例: DataWeave 1 ```dataweave 'world' match { :string -> true, default -> false } ``` Mule 4 の例: DataWeave 2 ```dataweave 'world' match { case is String -> true else -> false } ``` 型のパターンマッチャーの場合は、​`is`​ キーワードを設定する必要があります。 ## [](#dw_type_references)型の参照 型の参照から ​`:`​ が削除され、すべてがキャメルケースになりました。したがって、​`:string`​ は ​`String`​ になりました。 ## [](#dw_object_coercion)オブジェクトの強制型変換 DataWeave 1.0 では、オブジェクトからキー - 値ペアを選択するには、以下を実行する必要がありました。 Mule 3 の例: DataWeave 1 ```dataweave %var payload = {a: 1, b:2} --- payload.a as :object ``` 上記の DataWeave 1.0 の式は、​`{a:1}`​ を返します。これは強制型変換なので、自動強制型変換メカニズムにも含まれており、望ましくない、または予期しない結果が生じます。 DataWeave 2.0 では強制型変換が削除され、キー - 値ペアの括弧を選択する新しいセレクター (​`&`​) が導入されています。 Mule 3 の例: DataWeave 2 ```dataweave var payload = {a: 1, b:2} --- payload.&a ``` この式も ​`{a:1}`​ を返します。 ## [](#dw_cond_key_value_parens)条件付きキー - 値の括弧 DataWeave 1.0 では、条件付きキー - 値ペアは ​`when`​ キーワードで宣言されます。 Mule 3 の例: DataWeave 1 ```dataweave { (a: 1) when payload.product == "Mule" } ``` DataWeave 2.0 では、​`if`​ キーワードを使用します。 Mule 4 の例: DataWeave 2 ```dataweave { (a: 1) if payload.product == "Mule" } ``` ## [](#関連情報)関連情報 [Mule 4 の概要: DataWeave 2.0](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-dataweave2) # DataWeave バージョン 1 から 2 への移行 - [DataWeave ヘッダーのコンテンツ](#dw_header) - [フローコントロール](#dw_flow_control) - [型の参照](#dw_type_references) - [オブジェクトの強制型変換](#dw_object_coercion) - [条件付きキー - 値の括弧](#dw_cond_key_value_parens) ## [](#dw_header)DataWeave ヘッダーのコンテンツ DataWeave ではヘッダーのほとんどのディレクティブが変更されました。​`%dw`​ ディレクティブは例外です。ほとんどの場合 ​`%`​ が削除され、一部はキーワードが短縮されています。
DataWeave 1.0 DataWeave 2.0 コメント

%dw 1.0​

%dw 2.0

%input​

input

Mule アプリケーションフローでは、DataWeave 2.0 は先行するコンポーネントで指定された MIME タイプ (​outputMimeType​) とパラメーターに基づいて、入力 MIME タイプとそのリーダープロパティを認識します。入力 MIME タイプは、ヘッダーの ​input​ ディレクティブを使用して定義されなくなりました。 ただし、​input​ ディレクティブは、​ストリーミングされたデータのスクリプトの検証​などの特定のケースで引き続き使用されます。

%output​

output

%var​

var​

%function

fun​

%namespace

ns​
## [](#dw_flow_control)フローコントロール DataWeave 2 ではフローコントロールが若干変更されました。 ### [](#dw_flow_control_when_otherwise)When Otherwise `when otherwise`​ ステートメントは ​`if else`​ に置き換わります。次に例を示します。 Mule 3 の例: DataWeave 1 ```dataweave { orderStatus: "complete" when flowVars.purchaseOrderStatus == "C" otherwise "incomplete" } ``` Mule 4 の例: DataWeave 2 ```dataweave { orderStatus: if(vars.purchaseOrderStatus == "C") "complete" else "incomplete" } ``` ### [](#dw_flow_control_pattern_matcher)パターンマッチャー DataWeave 2 ではパターン一致が変更されました。キーワード ​`case`​ と (​`default`​ ではなく) ​`else`​ が追加されます。また、​`case`​ キーワードで明示的に区切られるので、ケースをカンマ (​`,`​) で区切らなくなりました。 Mule 3 の例: DataWeave 1 ```dataweave 'world' match { :string -> true, default -> false } ``` Mule 4 の例: DataWeave 2 ```dataweave 'world' match { case is String -> true else -> false } ``` 型のパターンマッチャーの場合は、​`is`​ キーワードを設定する必要があります。 ## [](#dw_type_references)型の参照 型の参照から ​`:`​ が削除され、すべてがキャメルケースになりました。したがって、​`:string`​ は ​`String`​ になりました。 ## [](#dw_object_coercion)オブジェクトの強制型変換 DataWeave 1.0 では、オブジェクトからキー - 値ペアを選択するには、以下を実行する必要がありました。 Mule 3 の例: DataWeave 1 ```dataweave %var payload = {a: 1, b:2} --- payload.a as :object ``` 上記の DataWeave 1.0 の式は、​`{a:1}`​ を返します。これは強制型変換なので、自動強制型変換メカニズムにも含まれており、望ましくない、または予期しない結果が生じます。 DataWeave 2.0 では強制型変換が削除され、キー - 値ペアの括弧を選択する新しいセレクター (​`&`​) が導入されています。 Mule 3 の例: DataWeave 2 ```dataweave var payload = {a: 1, b:2} --- payload.&a ``` この式も ​`{a:1}`​ を返します。 ## [](#dw_cond_key_value_parens)条件付きキー - 値の括弧 DataWeave 1.0 では、条件付きキー - 値ペアは ​`when`​ キーワードで宣言されます。 Mule 3 の例: DataWeave 1 ```dataweave { (a: 1) when payload.product == "Mule" } ``` DataWeave 2.0 では、​`if`​ キーワードを使用します。 Mule 4 の例: DataWeave 2 ```dataweave { (a: 1) if payload.product == "Mule" } ``` ## [](#関連情報)関連情報 [Mule 4 の概要: DataWeave 2.0](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-dataweave2) # DataWeave バージョン 1 から 2 への移行 - [DataWeave ヘッダーのコンテンツ](#dw_header) - [フローコントロール](#dw_flow_control) - [型の参照](#dw_type_references) - [オブジェクトの強制型変換](#dw_object_coercion) - [条件付きキー - 値の括弧](#dw_cond_key_value_parens) ## [](#dw_header)DataWeave ヘッダーのコンテンツ DataWeave ではヘッダーのほとんどのディレクティブが変更されました。​`%dw`​ ディレクティブは例外です。ほとんどの場合 ​`%`​ が削除され、一部はキーワードが短縮されています。
DataWeave 1.0 DataWeave 2.0 コメント

%dw 1.0​

%dw 2.0

%input​

input

Mule アプリケーションフローでは、DataWeave 2.0 は先行するコンポーネントで指定された MIME タイプ (​outputMimeType​) とパラメーターに基づいて、入力 MIME タイプとそのリーダープロパティを認識します。入力 MIME タイプは、ヘッダーの ​input​ ディレクティブを使用して定義されなくなりました。 ただし、​input​ ディレクティブは、​ストリーミングされたデータのスクリプトの検証​などの特定のケースで引き続き使用されます。

%output​

output

%var​

var​

%function

fun​

%namespace

ns​
## [](#dw_flow_control)フローコントロール DataWeave 2 ではフローコントロールが若干変更されました。 ### [](#dw_flow_control_when_otherwise)When Otherwise `when otherwise`​ ステートメントは ​`if else`​ に置き換わります。次に例を示します。 Mule 3 の例: DataWeave 1 ```dataweave { orderStatus: "complete" when flowVars.purchaseOrderStatus == "C" otherwise "incomplete" } ``` Mule 4 の例: DataWeave 2 ```dataweave { orderStatus: if(vars.purchaseOrderStatus == "C") "complete" else "incomplete" } ``` ### [](#dw_flow_control_pattern_matcher)パターンマッチャー DataWeave 2 ではパターン一致が変更されました。キーワード ​`case`​ と (​`default`​ ではなく) ​`else`​ が追加されます。また、​`case`​ キーワードで明示的に区切られるので、ケースをカンマ (​`,`​) で区切らなくなりました。 Mule 3 の例: DataWeave 1 ```dataweave 'world' match { :string -> true, default -> false } ``` Mule 4 の例: DataWeave 2 ```dataweave 'world' match { case is String -> true else -> false } ``` 型のパターンマッチャーの場合は、​`is`​ キーワードを設定する必要があります。 ## [](#dw_type_references)型の参照 型の参照から ​`:`​ が削除され、すべてがキャメルケースになりました。したがって、​`:string`​ は ​`String`​ になりました。 ## [](#dw_object_coercion)オブジェクトの強制型変換 DataWeave 1.0 では、オブジェクトからキー - 値ペアを選択するには、以下を実行する必要がありました。 Mule 3 の例: DataWeave 1 ```dataweave %var payload = {a: 1, b:2} --- payload.a as :object ``` 上記の DataWeave 1.0 の式は、​`{a:1}`​ を返します。これは強制型変換なので、自動強制型変換メカニズムにも含まれており、望ましくない、または予期しない結果が生じます。 DataWeave 2.0 では強制型変換が削除され、キー - 値ペアの括弧を選択する新しいセレクター (​`&`​) が導入されています。 Mule 3 の例: DataWeave 2 ```dataweave var payload = {a: 1, b:2} --- payload.&a ``` この式も ​`{a:1}`​ を返します。 ## [](#dw_cond_key_value_parens)条件付きキー - 値の括弧 DataWeave 1.0 では、条件付きキー - 値ペアは ​`when`​ キーワードで宣言されます。 Mule 3 の例: DataWeave 1 ```dataweave { (a: 1) when payload.product == "Mule" } ``` DataWeave 2.0 では、​`if`​ キーワードを使用します。 Mule 4 の例: DataWeave 2 ```dataweave { (a: 1) if payload.product == "Mule" } ``` ## [](#関連情報)関連情報 [Mule 4 の概要: DataWeave 2.0](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-dataweave2) # DataWeave バージョン 1 から 2 への移行 - [DataWeave ヘッダーのコンテンツ](#dw_header) - [フローコントロール](#dw_flow_control) - [型の参照](#dw_type_references) - [オブジェクトの強制型変換](#dw_object_coercion) - [条件付きキー - 値の括弧](#dw_cond_key_value_parens) ## [](#dw_header)DataWeave ヘッダーのコンテンツ DataWeave ではヘッダーのほとんどのディレクティブが変更されました。​`%dw`​ ディレクティブは例外です。ほとんどの場合 ​`%`​ が削除され、一部はキーワードが短縮されています。
DataWeave 1.0 DataWeave 2.0 コメント

%dw 1.0​

%dw 2.0

%input​

input

Mule アプリケーションフローでは、DataWeave 2.0 は先行するコンポーネントで指定された MIME タイプ (​outputMimeType​) とパラメーターに基づいて、入力 MIME タイプとそのリーダープロパティを認識します。入力 MIME タイプは、ヘッダーの ​input​ ディレクティブを使用して定義されなくなりました。 ただし、​input​ ディレクティブは、​ストリーミングされたデータのスクリプトの検証​などの特定のケースで引き続き使用されます。

%output​

output

%var​

var​

%function

fun​

%namespace

ns​
## [](#dw_flow_control)フローコントロール DataWeave 2 ではフローコントロールが若干変更されました。 ### [](#dw_flow_control_when_otherwise)When Otherwise `when otherwise`​ ステートメントは ​`if else`​ に置き換わります。次に例を示します。 Mule 3 の例: DataWeave 1 ```dataweave { orderStatus: "complete" when flowVars.purchaseOrderStatus == "C" otherwise "incomplete" } ``` Mule 4 の例: DataWeave 2 ```dataweave { orderStatus: if(vars.purchaseOrderStatus == "C") "complete" else "incomplete" } ``` ### [](#dw_flow_control_pattern_matcher)パターンマッチャー DataWeave 2 ではパターン一致が変更されました。キーワード ​`case`​ と (​`default`​ ではなく) ​`else`​ が追加されます。また、​`case`​ キーワードで明示的に区切られるので、ケースをカンマ (​`,`​) で区切らなくなりました。 Mule 3 の例: DataWeave 1 ```dataweave 'world' match { :string -> true, default -> false } ``` Mule 4 の例: DataWeave 2 ```dataweave 'world' match { case is String -> true else -> false } ``` 型のパターンマッチャーの場合は、​`is`​ キーワードを設定する必要があります。 ## [](#dw_type_references)型の参照 型の参照から ​`:`​ が削除され、すべてがキャメルケースになりました。したがって、​`:string`​ は ​`String`​ になりました。 ## [](#dw_object_coercion)オブジェクトの強制型変換 DataWeave 1.0 では、オブジェクトからキー - 値ペアを選択するには、以下を実行する必要がありました。 Mule 3 の例: DataWeave 1 ```dataweave %var payload = {a: 1, b:2} --- payload.a as :object ``` 上記の DataWeave 1.0 の式は、​`{a:1}`​ を返します。これは強制型変換なので、自動強制型変換メカニズムにも含まれており、望ましくない、または予期しない結果が生じます。 DataWeave 2.0 では強制型変換が削除され、キー - 値ペアの括弧を選択する新しいセレクター (​`&`​) が導入されています。 Mule 3 の例: DataWeave 2 ```dataweave var payload = {a: 1, b:2} --- payload.&a ``` この式も ​`{a:1}`​ を返します。 ## [](#dw_cond_key_value_parens)条件付きキー - 値の括弧 DataWeave 1.0 では、条件付きキー - 値ペアは ​`when`​ キーワードで宣言されます。 Mule 3 の例: DataWeave 1 ```dataweave { (a: 1) when payload.product == "Mule" } ``` DataWeave 2.0 では、​`if`​ キーワードを使用します。 Mule 4 の例: DataWeave 2 ```dataweave { (a: 1) if payload.product == "Mule" } ``` ## [](#関連情報)関連情報 [Mule 4 の概要: DataWeave 2.0](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-dataweave2) # Dynamic Evaluate コンポーネント Dynamic Evaluate コンポーネントは、式を評価して DataWeave スクリプトを選択し、新しいスクリプトを実行して結果を生成します。この動作により、​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about)​でハードコード化する代わりに、動的にスクリプトを選択できます。 スクリプトには、​`message`​、​`payload`​、​`vars`​、​`attributes`​ などの通常の​[コンテキスト変数](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-variables-context)​を使用できますが、キー - 値ペアのセットを指定することによってカスタム変数を追加することもできます。 ## [](#動的評価の設定)動的評価の設定
項目 値 説明 例

式

DataWeave 式

Mule が実行する DataWeave スクリプトを選択する式を指定します。

expression="#[vars.generateOrderScript]"

パラメーター

DataWeave 式

DataWeave スクリプトが評価するパラメーターとして設定されるキー-値ペアを指定します。

#[{joiner: ' and ', id: payload.user.id}]​
## [](#ファイルシステムから-dataweave-スクリプトを評価する例)ファイルシステムから DataWeave スクリプトを評価する例 次の例は、Dynamic Evaluate コンポーネントで、ファイルシステムのローカルに保存されている DataWeave スクリプトを選択して実行する方法を示しています。アプリケーションのフロー動作は次のようになります。 1. HTTP Listener ソースで、​`locale`​ クエリパラメーターとペイロードを含む POST URL 要求をリスンします。 2. File Read 操作で、HTTP 要求で受信した ​`locale`​ クエリパラメーターを使用して、パラメーター名に一致する DataWeave スクリプトをローカルで検索します。 3. File Read 操作で、スクリプトのコンテンツを新しい変数に保存します。 4. Dynamic Evaluate コンポーネントで、変数に保存された DataWeave 式を実行します。 5. Logger コンポーネントで、変換のペイロード結果をログに記録します。 ローカルに保存された DataWeave スクリプトは、ローカルではなくデータベースに保存することができ、ファイルシステムではなくデータベースからファイルを選択するようにアプリケーションを変更できます。これにより、アプリケーションのデプロイおよび実行中に任意の ​`.dwl`​ ファイルを置き換えることができ、アプリケーションを変更または再デプロイすることなく、実行する DataWeave スクリプトを変更できます。 この例では、2 つの DataWeave スクリプトを作成してローカルに保存し、Mule アプリケーションを作成して、アプリケーションを実行およびテストします。 ![Anypoint Studio での Dynamic Evaluate フローの例](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/dynamic-evaluate-flow-1.png) Figure 1. Anypoint Studio での Dynamic Evaluate フローの例 ### [](#dataweave-スクリプトの作成と保存)DataWeave スクリプトの作成と保存 ファイルシステムから DataWeave スクリプトを評価する最初のステップは、スクリプトを作成してローカルに保存することです。 1. Studio で新しい Mule プロジェクトを作成します。 2. **Package Explorer**​ ウィンドウの Mule プロジェクト名の下で、​**src/main/resources**​ フォルダーをクリックし、​**\[New (新規)\] > \[File (ファイル)\]**​ を選択します。 3. **\[File name (ファイル名)\]**​ 項目で、名前 ​`dw_en-US.dwl`​ を追加して、新しい DataWeave スクリプトファイルを作成します。 4. **\[Finish (完了)\]**​ をクリックします。 5. **dw\_en-US.dwl**​ ウィンドウで、次の DataWeave 式を貼り付けます。 ```dataweave %dw 2.0 output application/json --- { "First Name": payload.name, "Last Name": payload.last, "Country": payload.loc } ``` 6. 前の手順を繰り返して、次の DataWeave 式を含む ​`dw_es-AR.dwl`​ という名前の新しいファイルを作成します。 ```dataweave %dw 2.0 output application/json --- { "Nombre": payload.name, "Apellido": payload.last, "País": payload.loc } ``` 7. 変更を保存します。 ### [](#mule-アプリケーションの作成)Mule アプリケーションの作成 サンプルスクリプトを作成してローカルに保存したら、Studio で Mule アプリケーションを作成します。 1. **Package Explorer**​ ウィンドウの ​**src/main/mule (フロー)**​ フォルダーで、フローの ​`.xml`​ ファイルに移動します。 2. **\[Mule Palette (Mule パレット)\]**​ ビューで、​**HTTP Listener**​ ソースを選択してキャンバスにドラッグします。 ソースが受信 HTTP 要求をリスンすることでフローが開始します。 3. **\[Path (パス)\]**​ 項目を ​`/test`​ に設定します。 4. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の HTTP リスナーのすべてのインスタンスで使用できるグローバル要素を設定します。 5. **\[General (一般)\]**​ タブで、次の項目を設定します。 - **Host (ホスト)**​: `All Interfaces [0.0.0.0] (default)` - **Port (ポート)**​: `8081` 6. **\[OK\]**​ をクリックします。 7. **\[File Read\]**​ 操作を ​**\[HTTP Listener\]**​ の右にドラッグします。 8. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の File Read 操作のすべてのインスタンスで使用できるグローバル要素を設定します。 9. **\[General (一般)\]**​ タブで、​**\[Working Directory (作業ディレクトリ)\]**​ 項目を Studio プロジェクトと以前の DataWeave スクリプトを含むメインリソースフォルダーに設定します。 `/Users/username/AnypointStudio/studio-workspace/dynamicevaluate/src/main/resources` 10. **\[OK\]**​ をクリックします。 11. **\[File path (ファイルパス)\]**​ 項目で、パス ​`#["dw_" ++ attributes.queryParams.locale ++ ".dwl"]`​ を設定します。 コネクタは、​`dw_`​ で始まり、HTTP 要求で受信した ​`locale`​ クエリパラメーター (​`attributes.queryParams.locale`​) を含む、ローカルに保存された DataWeave スクリプトファイル名を読み取ります。 12. **\[Advanced (詳細)\]**​ タブで、​**\[Target Variable (対象変数)\]**​ 項目を ​`dwScript`​ に設定します。 この変数には、ファイル検索に一致した DataWeave スクリプトが保存されます。 13. **\[Dynamic Evaluate\]**​ コンポーネントを ​**\[File Read\]**​ の右にドラッグします。 14. **\[Expression (式)\]**​ 項目を ​`#[vars."dwScript"]`​ に設定して、変数 ​`dwScript`​ に保存された一致する DataWeave スクリプトを実行します。 15. **\[Target value (対象値)\]**​ 項目を ​`payload`​ に設定します。 16. **\[Logger\]**​ コンポーネントを ​**\[Dynamic Evaluate\]**​ の右にドラッグします。 17. **\[Message (メッセージ)\]**​ 項目を ​`#[payload]`​ に設定します。 18. Mule アプリケーションを保存します。 ### [](#mule-アプリケーションの実行とテスト)Mule アプリケーションの実行とテスト Mule アプリケーションを作成したら、実行してテストします。 1. **Package Explorer**​ でプロジェクト名をクリックし、​**\[Run (実行)\] > \[Run As (別のユーザーとして実行)\] > \[Mule Application (Mule アプリケーション)\]**​ をクリックします。 2. 次のクエリパラメーター ​`locale=en-US`​ または ​`locale=es-AR`​ のいずれかを URL に追加して、POST 要求を ​`http://localhost:8081/test`​ に送信します。次に例を示します。 `http://localhost:8081/test?locale=en-US` さらに、POST 要求で次のペイロードを送信します。 ```JSON { "name": "Max", "last": "The Mule", "loc": "Argentina" } ``` 3. Studio コンソールで、ログをスクロールして結果のメッセージを確認します。 ```console INFO 2021-01-19 11:18:25,559 [[MuleRuntime].uber.12: [dynamicevaluate].dynamicevaluateFlow.CPU_INTENSIVE @2588f400] [processor: dynamicevaluateFlow/processors/2; event: 319aacc0-5a61-11eb-bbb8-f01898ad2638] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "First Name": "Max", "Last Name": "The Mule", "Country": "Argentina" } ``` ### [](#ファイルシステムから-dataweave-スクリプトを評価するための-xml)ファイルシステムから DataWeave スクリプトを評価するための XML この例のフローをすばやく Mule アプリケーションに読み込むには、次のコードを Studio XML エディターに貼り付けます。 ```xml ``` ## [](#データベースから-dataweave-スクリプトを評価する例)データベースから DataWeave スクリプトを評価する例 次の例では、​`userId`​ クエリパラメーターを使用してデータベースからスクリプトを選択し、そのスクリプトを ​`userScript`​ 変数に保存します。​`dynamic-evaluate`​ コンポーネントは、​`userScript`​ 変数にアクセスし、指令された (​`attributes.queryParams.userName`​ の値を含む) パラメーター ​`name`​ を使用してスクリプトを呼び出します。 ```xml #["SELECT script FROM SCRIPTS WHERE ID = $(attributes.queryParams.userId)"] #[{name: attributes.queryParams.userName}] ``` 次のスクリプトが例のデータベースのエントリ ​`lsalander`​ と ​`mblomkvist`​ にそれぞれ保存されているとします。 例: lsalander スクリプト output application/json --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } 例: mblomkvist スクリプト output application/x-www-form-urlencoded --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } ### [](#アプリケーション動作の例)アプリケーション動作の例 このサンプル Mule アプリケーションが要求で ​`lsalander`​ を ​`queryParams.userId`​ として受け取ると、Mule は対応するスクリプトを実行して JSON 応答を返します。アプリケーションが ​`mblomkvist`​ を ​`queryParams.userId`​ 値として受け取った場合、Mule は別のスクリプトを実行して ​`x-www-form-urlencoded`​ 応答を返します。 この例は、ユーザーに基づいて応答種別をパラメーター化でき、さらに各ユーザーのニーズに合わせて応答全体をパラメーター化できることを示しています。 # Dynamic Evaluate コンポーネント Dynamic Evaluate コンポーネントは、式を評価して DataWeave スクリプトを選択し、新しいスクリプトを実行して結果を生成します。この動作により、​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about)​でハードコード化する代わりに、動的にスクリプトを選択できます。 スクリプトには、​`message`​、​`payload`​、​`vars`​、​`attributes`​ などの通常の​[コンテキスト変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​を使用できますが、キー - 値ペアのセットを指定することによってカスタム変数を追加することもできます。 ## [](#動的評価の設定)動的評価の設定
項目 値 説明 例

式

DataWeave 式

Mule が実行する DataWeave スクリプトを選択する式を指定します。

expression="#[vars.generateOrderScript]"

パラメーター

DataWeave 式

DataWeave スクリプトが評価するパラメーターとして設定されるキー-値ペアを指定します。

#[{joiner: ' and ', id: payload.user.id}]​
## [](#ファイルシステムから-dataweave-スクリプトを評価する例)ファイルシステムから DataWeave スクリプトを評価する例 次の例は、Dynamic Evaluate コンポーネントで、ファイルシステムのローカルに保存されている DataWeave スクリプトを選択して実行する方法を示しています。アプリケーションのフロー動作は次のようになります。 1. HTTP Listener ソースで、​`locale`​ クエリパラメーターとペイロードを含む POST URL 要求をリスンします。 2. File Read 操作で、HTTP 要求で受信した ​`locale`​ クエリパラメーターを使用して、パラメーター名に一致する DataWeave スクリプトをローカルで検索します。 3. File Read 操作で、スクリプトのコンテンツを新しい変数に保存します。 4. Dynamic Evaluate コンポーネントで、変数に保存された DataWeave 式を実行します。 5. Logger コンポーネントで、変換のペイロード結果をログに記録します。 ローカルに保存された DataWeave スクリプトは、ローカルではなくデータベースに保存することができ、ファイルシステムではなくデータベースからファイルを選択するようにアプリケーションを変更できます。これにより、アプリケーションのデプロイおよび実行中に任意の ​`.dwl`​ ファイルを置き換えることができ、アプリケーションを変更または再デプロイすることなく、実行する DataWeave スクリプトを変更できます。 この例では、2 つの DataWeave スクリプトを作成してローカルに保存し、Mule アプリケーションを作成して、アプリケーションを実行およびテストします。 ![Anypoint Studio での Dynamic Evaluate フローの例](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/dynamic-evaluate-flow-1.png) Figure 1. Anypoint Studio での Dynamic Evaluate フローの例 ### [](#dataweave-スクリプトの作成と保存)DataWeave スクリプトの作成と保存 ファイルシステムから DataWeave スクリプトを評価する最初のステップは、スクリプトを作成してローカルに保存することです。 1. Studio で新しい Mule プロジェクトを作成します。 2. **Package Explorer**​ ウィンドウの Mule プロジェクト名の下で、​**src/main/resources**​ フォルダーをクリックし、​**\[New (新規)\] > \[File (ファイル)\]**​ を選択します。 3. **\[File name (ファイル名)\]**​ 項目で、名前 ​`dw_en-US.dwl`​ を追加して、新しい DataWeave スクリプトファイルを作成します。 4. **\[Finish (完了)\]**​ をクリックします。 5. **dw\_en-US.dwl**​ ウィンドウで、次の DataWeave 式を貼り付けます。 ```dataweave %dw 2.0 output application/json --- { "First Name": payload.name, "Last Name": payload.last, "Country": payload.loc } ``` 6. 前の手順を繰り返して、次の DataWeave 式を含む ​`dw_es-AR.dwl`​ という名前の新しいファイルを作成します。 ```dataweave %dw 2.0 output application/json --- { "Nombre": payload.name, "Apellido": payload.last, "País": payload.loc } ``` 7. 変更を保存します。 ### [](#mule-アプリケーションの作成)Mule アプリケーションの作成 サンプルスクリプトを作成してローカルに保存したら、Studio で Mule アプリケーションを作成します。 1. **Package Explorer**​ ウィンドウの ​**src/main/mule (フロー)**​ フォルダーで、フローの ​`.xml`​ ファイルに移動します。 2. **\[Mule Palette (Mule パレット)\]**​ ビューで、​**HTTP Listener**​ ソースを選択してキャンバスにドラッグします。 ソースが受信 HTTP 要求をリスンすることでフローが開始します。 3. **\[Path (パス)\]**​ 項目を ​`/test`​ に設定します。 4. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の HTTP リスナーのすべてのインスタンスで使用できるグローバル要素を設定します。 5. **\[General (一般)\]**​ タブで、次の項目を設定します。 - **Host (ホスト)**​: `All Interfaces [0.0.0.0] (default)` - **Port (ポート)**​: `8081` 6. **\[OK\]**​ をクリックします。 7. **\[File Read\]**​ 操作を ​**\[HTTP Listener\]**​ の右にドラッグします。 8. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の File Read 操作のすべてのインスタンスで使用できるグローバル要素を設定します。 9. **\[General (一般)\]**​ タブで、​**\[Working Directory (作業ディレクトリ)\]**​ 項目を Studio プロジェクトと以前の DataWeave スクリプトを含むメインリソースフォルダーに設定します。 `/Users/username/AnypointStudio/studio-workspace/dynamicevaluate/src/main/resources` 10. **\[OK\]**​ をクリックします。 11. **\[File path (ファイルパス)\]**​ 項目で、パス ​`#["dw_" ++ attributes.queryParams.locale ++ ".dwl"]`​ を設定します。 コネクタは、​`dw_`​ で始まり、HTTP 要求で受信した ​`locale`​ クエリパラメーター (​`attributes.queryParams.locale`​) を含む、ローカルに保存された DataWeave スクリプトファイル名を読み取ります。 12. **\[Advanced (詳細)\]**​ タブで、​**\[Target Variable (対象変数)\]**​ 項目を ​`dwScript`​ に設定します。 この変数には、ファイル検索に一致した DataWeave スクリプトが保存されます。 13. **\[Dynamic Evaluate\]**​ コンポーネントを ​**\[File Read\]**​ の右にドラッグします。 14. **\[Expression (式)\]**​ 項目を ​`#[vars."dwScript"]`​ に設定して、変数 ​`dwScript`​ に保存された一致する DataWeave スクリプトを実行します。 15. **\[Target value (対象値)\]**​ 項目を ​`payload`​ に設定します。 16. **\[Logger\]**​ コンポーネントを ​**\[Dynamic Evaluate\]**​ の右にドラッグします。 17. **\[Message (メッセージ)\]**​ 項目を ​`#[payload]`​ に設定します。 18. Mule アプリケーションを保存します。 ### [](#mule-アプリケーションの実行とテスト)Mule アプリケーションの実行とテスト Mule アプリケーションを作成したら、実行してテストします。 1. **Package Explorer**​ でプロジェクト名をクリックし、​**\[Run (実行)\] > \[Run As (別のユーザーとして実行)\] > \[Mule Application (Mule アプリケーション)\]**​ をクリックします。 2. 次のクエリパラメーター ​`locale=en-US`​ または ​`locale=es-AR`​ のいずれかを URL に追加して、POST 要求を ​`http://localhost:8081/test`​ に送信します。次に例を示します。 `http://localhost:8081/test?locale=en-US` さらに、POST 要求で次のペイロードを送信します。 ```JSON { "name": "Max", "last": "The Mule", "loc": "Argentina" } ``` 3. Studio コンソールで、ログをスクロールして結果のメッセージを確認します。 ```console INFO 2021-01-19 11:18:25,559 [[MuleRuntime].uber.12: [dynamicevaluate].dynamicevaluateFlow.CPU_INTENSIVE @2588f400] [processor: dynamicevaluateFlow/processors/2; event: 319aacc0-5a61-11eb-bbb8-f01898ad2638] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "First Name": "Max", "Last Name": "The Mule", "Country": "Argentina" } ``` ### [](#ファイルシステムから-dataweave-スクリプトを評価するための-xml)ファイルシステムから DataWeave スクリプトを評価するための XML この例のフローをすばやく Mule アプリケーションに読み込むには、次のコードを Studio XML エディターに貼り付けます。 ```xml ``` ## [](#データベースから-dataweave-スクリプトを評価する例)データベースから DataWeave スクリプトを評価する例 次の例では、​`userId`​ クエリパラメーターを使用してデータベースからスクリプトを選択し、そのスクリプトを ​`userScript`​ 変数に保存します。​`dynamic-evaluate`​ コンポーネントは、​`userScript`​ 変数にアクセスし、指令された (​`attributes.queryParams.userName`​ の値を含む) パラメーター ​`name`​ を使用してスクリプトを呼び出します。 ```xml #["SELECT script FROM SCRIPTS WHERE ID = $(attributes.queryParams.userId)"] #[{name: attributes.queryParams.userName}] ``` 次のスクリプトが例のデータベースのエントリ ​`lsalander`​ と ​`mblomkvist`​ にそれぞれ保存されているとします。 例: lsalander スクリプト output application/json --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } 例: mblomkvist スクリプト output application/x-www-form-urlencoded --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } ### [](#アプリケーション動作の例)アプリケーション動作の例 このサンプル Mule アプリケーションが要求で ​`lsalander`​ を ​`queryParams.userId`​ として受け取ると、Mule は対応するスクリプトを実行して JSON 応答を返します。アプリケーションが ​`mblomkvist`​ を ​`queryParams.userId`​ 値として受け取った場合、Mule は別のスクリプトを実行して ​`x-www-form-urlencoded`​ 応答を返します。 この例は、ユーザーに基づいて応答種別をパラメーター化でき、さらに各ユーザーのニーズに合わせて応答全体をパラメーター化できることを示しています。 # Dynamic Evaluate コンポーネント Dynamic Evaluate コンポーネントは、式を評価して DataWeave スクリプトを選択し、新しいスクリプトを実行して結果を生成します。この動作により、​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about)​でハードコード化する代わりに、動的にスクリプトを選択できます。 スクリプトには、​`message`​、​`payload`​、​`vars`​、​`attributes`​ などの通常の​[コンテキスト変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​を使用できますが、キー - 値ペアのセットを指定することによってカスタム変数を追加することもできます。 ## [](#動的評価の設定)動的評価の設定
項目 値 説明 例

式

DataWeave 式

Mule が実行する DataWeave スクリプトを選択する式を指定します。

expression="#[vars.generateOrderScript]"

パラメーター

DataWeave 式

DataWeave スクリプトが評価するパラメーターとして設定されるキー-値ペアを指定します。

#[{joiner: ' and ', id: payload.user.id}]​
## [](#ファイルシステムから-dataweave-スクリプトを評価する例)ファイルシステムから DataWeave スクリプトを評価する例 次の例は、Dynamic Evaluate コンポーネントで、ファイルシステムのローカルに保存されている DataWeave スクリプトを選択して実行する方法を示しています。アプリケーションのフロー動作は次のようになります。 1. HTTP Listener ソースで、​`locale`​ クエリパラメーターとペイロードを含む POST URL 要求をリスンします。 2. File Read 操作で、HTTP 要求で受信した ​`locale`​ クエリパラメーターを使用して、パラメーター名に一致する DataWeave スクリプトをローカルで検索します。 3. File Read 操作で、スクリプトのコンテンツを新しい変数に保存します。 4. Dynamic Evaluate コンポーネントで、変数に保存された DataWeave 式を実行します。 5. Logger コンポーネントで、変換のペイロード結果をログに記録します。 ローカルに保存された DataWeave スクリプトは、ローカルではなくデータベースに保存することができ、ファイルシステムではなくデータベースからファイルを選択するようにアプリケーションを変更できます。これにより、アプリケーションのデプロイおよび実行中に任意の ​`.dwl`​ ファイルを置き換えることができ、アプリケーションを変更または再デプロイすることなく、実行する DataWeave スクリプトを変更できます。 この例では、2 つの DataWeave スクリプトを作成してローカルに保存し、Mule アプリケーションを作成して、アプリケーションを実行およびテストします。 ![Anypoint Studio での Dynamic Evaluate フローの例](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/dynamic-evaluate-flow-1.png) Figure 1. Anypoint Studio での Dynamic Evaluate フローの例 ### [](#dataweave-スクリプトの作成と保存)DataWeave スクリプトの作成と保存 ファイルシステムから DataWeave スクリプトを評価する最初のステップは、スクリプトを作成してローカルに保存することです。 1. Studio で新しい Mule プロジェクトを作成します。 2. **Package Explorer**​ ウィンドウの Mule プロジェクト名の下で、​**src/main/resources**​ フォルダーをクリックし、​**\[New (新規)\] > \[File (ファイル)\]**​ を選択します。 3. **\[File name (ファイル名)\]**​ 項目で、名前 ​`dw_en-US.dwl`​ を追加して、新しい DataWeave スクリプトファイルを作成します。 4. **\[Finish (完了)\]**​ をクリックします。 5. **dw\_en-US.dwl**​ ウィンドウで、次の DataWeave 式を貼り付けます。 ```dataweave %dw 2.0 output application/json --- { "First Name": payload.name, "Last Name": payload.last, "Country": payload.loc } ``` 6. 前の手順を繰り返して、次の DataWeave 式を含む ​`dw_es-AR.dwl`​ という名前の新しいファイルを作成します。 ```dataweave %dw 2.0 output application/json --- { "Nombre": payload.name, "Apellido": payload.last, "País": payload.loc } ``` 7. 変更を保存します。 ### [](#mule-アプリケーションの作成)Mule アプリケーションの作成 サンプルスクリプトを作成してローカルに保存したら、Studio で Mule アプリケーションを作成します。 1. **Package Explorer**​ ウィンドウの ​**src/main/mule (フロー)**​ フォルダーで、フローの ​`.xml`​ ファイルに移動します。 2. **\[Mule Palette (Mule パレット)\]**​ ビューで、​**HTTP Listener**​ ソースを選択してキャンバスにドラッグします。 ソースが受信 HTTP 要求をリスンすることでフローが開始します。 3. **\[Path (パス)\]**​ 項目を ​`/test`​ に設定します。 4. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の HTTP リスナーのすべてのインスタンスで使用できるグローバル要素を設定します。 5. **\[General (一般)\]**​ タブで、次の項目を設定します。 - **Host (ホスト)**​: `All Interfaces [0.0.0.0] (default)` - **Port (ポート)**​: `8081` 6. **\[OK\]**​ をクリックします。 7. **\[File Read\]**​ 操作を ​**\[HTTP Listener\]**​ の右にドラッグします。 8. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の File Read 操作のすべてのインスタンスで使用できるグローバル要素を設定します。 9. **\[General (一般)\]**​ タブで、​**\[Working Directory (作業ディレクトリ)\]**​ 項目を Studio プロジェクトと以前の DataWeave スクリプトを含むメインリソースフォルダーに設定します。 `/Users/username/AnypointStudio/studio-workspace/dynamicevaluate/src/main/resources` 10. **\[OK\]**​ をクリックします。 11. **\[File path (ファイルパス)\]**​ 項目で、パス ​`#["dw_" ++ attributes.queryParams.locale ++ ".dwl"]`​ を設定します。 コネクタは、​`dw_`​ で始まり、HTTP 要求で受信した ​`locale`​ クエリパラメーター (​`attributes.queryParams.locale`​) を含む、ローカルに保存された DataWeave スクリプトファイル名を読み取ります。 12. **\[Advanced (詳細)\]**​ タブで、​**\[Target Variable (対象変数)\]**​ 項目を ​`dwScript`​ に設定します。 この変数には、ファイル検索に一致した DataWeave スクリプトが保存されます。 13. **\[Dynamic Evaluate\]**​ コンポーネントを ​**\[File Read\]**​ の右にドラッグします。 14. **\[Expression (式)\]**​ 項目を ​`#[vars."dwScript"]`​ に設定して、変数 ​`dwScript`​ に保存された一致する DataWeave スクリプトを実行します。 15. **\[Target value (対象値)\]**​ 項目を ​`payload`​ に設定します。 16. **\[Logger\]**​ コンポーネントを ​**\[Dynamic Evaluate\]**​ の右にドラッグします。 17. **\[Message (メッセージ)\]**​ 項目を ​`#[payload]`​ に設定します。 18. Mule アプリケーションを保存します。 ### [](#mule-アプリケーションの実行とテスト)Mule アプリケーションの実行とテスト Mule アプリケーションを作成したら、実行してテストします。 1. **Package Explorer**​ でプロジェクト名をクリックし、​**\[Run (実行)\] > \[Run As (別のユーザーとして実行)\] > \[Mule Application (Mule アプリケーション)\]**​ をクリックします。 2. 次のクエリパラメーター ​`locale=en-US`​ または ​`locale=es-AR`​ のいずれかを URL に追加して、POST 要求を ​`http://localhost:8081/test`​ に送信します。次に例を示します。 `http://localhost:8081/test?locale=en-US` さらに、POST 要求で次のペイロードを送信します。 ```JSON { "name": "Max", "last": "The Mule", "loc": "Argentina" } ``` 3. Studio コンソールで、ログをスクロールして結果のメッセージを確認します。 ```console INFO 2021-01-19 11:18:25,559 [[MuleRuntime].uber.12: [dynamicevaluate].dynamicevaluateFlow.CPU_INTENSIVE @2588f400] [processor: dynamicevaluateFlow/processors/2; event: 319aacc0-5a61-11eb-bbb8-f01898ad2638] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "First Name": "Max", "Last Name": "The Mule", "Country": "Argentina" } ``` ### [](#ファイルシステムから-dataweave-スクリプトを評価するための-xml)ファイルシステムから DataWeave スクリプトを評価するための XML この例のフローをすばやく Mule アプリケーションに読み込むには、次のコードを Studio XML エディターに貼り付けます。 ```xml ``` ## [](#データベースから-dataweave-スクリプトを評価する例)データベースから DataWeave スクリプトを評価する例 次の例では、​`userId`​ クエリパラメーターを使用してデータベースからスクリプトを選択し、そのスクリプトを ​`userScript`​ 変数に保存します。​`dynamic-evaluate`​ コンポーネントは、​`userScript`​ 変数にアクセスし、指令された (​`attributes.queryParams.userName`​ の値を含む) パラメーター ​`name`​ を使用してスクリプトを呼び出します。 ```xml #["SELECT script FROM SCRIPTS WHERE ID = $(attributes.queryParams.userId)"] #[{name: attributes.queryParams.userName}] ``` 次のスクリプトが例のデータベースのエントリ ​`lsalander`​ と ​`mblomkvist`​ にそれぞれ保存されているとします。 例: lsalander スクリプト output application/json --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } 例: mblomkvist スクリプト output application/x-www-form-urlencoded --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } ### [](#アプリケーション動作の例)アプリケーション動作の例 このサンプル Mule アプリケーションが要求で ​`lsalander`​ を ​`queryParams.userId`​ として受け取ると、Mule は対応するスクリプトを実行して JSON 応答を返します。アプリケーションが ​`mblomkvist`​ を ​`queryParams.userId`​ 値として受け取った場合、Mule は別のスクリプトを実行して ​`x-www-form-urlencoded`​ 応答を返します。 この例は、ユーザーに基づいて応答種別をパラメーター化でき、さらに各ユーザーのニーズに合わせて応答全体をパラメーター化できることを示しています。 # Dynamic Evaluate コンポーネント Dynamic Evaluate コンポーネントは、式を評価して DataWeave スクリプトを選択し、新しいスクリプトを実行して結果を生成します。この動作により、​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about)​でハードコード化する代わりに、動的にスクリプトを選択できます。 スクリプトには、​`message`​、​`payload`​、​`vars`​、​`attributes`​ などの通常の​[コンテキスト変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​を使用できますが、キー - 値ペアのセットを指定することによってカスタム変数を追加することもできます。 ## [](#動的評価の設定)動的評価の設定
項目 値 説明 例

式

DataWeave 式

Mule が実行する DataWeave スクリプトを選択する式を指定します。

expression="#[vars.generateOrderScript]"

パラメーター

DataWeave 式

DataWeave スクリプトが評価するパラメーターとして設定されるキー-値ペアを指定します。

#[{joiner: ' and ', id: payload.user.id}]​
## [](#ファイルシステムから-dataweave-スクリプトを評価する例)ファイルシステムから DataWeave スクリプトを評価する例 次の例は、Dynamic Evaluate コンポーネントで、ファイルシステムのローカルに保存されている DataWeave スクリプトを選択して実行する方法を示しています。アプリケーションのフロー動作は次のようになります。 1. HTTP Listener ソースで、​`locale`​ クエリパラメーターとペイロードを含む POST URL 要求をリスンします。 2. File Read 操作で、HTTP 要求で受信した ​`locale`​ クエリパラメーターを使用して、パラメーター名に一致する DataWeave スクリプトをローカルで検索します。 3. File Read 操作で、スクリプトのコンテンツを新しい変数に保存します。 4. Dynamic Evaluate コンポーネントで、変数に保存された DataWeave 式を実行します。 5. Logger コンポーネントで、変換のペイロード結果をログに記録します。 ローカルに保存された DataWeave スクリプトは、ローカルではなくデータベースに保存することができ、ファイルシステムではなくデータベースからファイルを選択するようにアプリケーションを変更できます。これにより、アプリケーションのデプロイおよび実行中に任意の ​`.dwl`​ ファイルを置き換えることができ、アプリケーションを変更または再デプロイすることなく、実行する DataWeave スクリプトを変更できます。 この例では、2 つの DataWeave スクリプトを作成してローカルに保存し、Mule アプリケーションを作成して、アプリケーションを実行およびテストします。 ![Anypoint Studio での Dynamic Evaluate フローの例](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/dynamic-evaluate-flow-1.png) Figure 1. Anypoint Studio での Dynamic Evaluate フローの例 ### [](#dataweave-スクリプトの作成と保存)DataWeave スクリプトの作成と保存 ファイルシステムから DataWeave スクリプトを評価する最初のステップは、スクリプトを作成してローカルに保存することです。 1. Studio で新しい Mule プロジェクトを作成します。 2. **Package Explorer**​ ウィンドウの Mule プロジェクト名の下で、​**src/main/resources**​ フォルダーをクリックし、​**\[New (新規)\] > \[File (ファイル)\]**​ を選択します。 3. **\[File name (ファイル名)\]**​ 項目で、名前 ​`dw_en-US.dwl`​ を追加して、新しい DataWeave スクリプトファイルを作成します。 4. **\[Finish (完了)\]**​ をクリックします。 5. **dw\_en-US.dwl**​ ウィンドウで、次の DataWeave 式を貼り付けます。 ```dataweave %dw 2.0 output application/json --- { "First Name": payload.name, "Last Name": payload.last, "Country": payload.loc } ``` 6. 前の手順を繰り返して、次の DataWeave 式を含む ​`dw_es-AR.dwl`​ という名前の新しいファイルを作成します。 ```dataweave %dw 2.0 output application/json --- { "Nombre": payload.name, "Apellido": payload.last, "País": payload.loc } ``` 7. 変更を保存します。 ### [](#mule-アプリケーションの作成)Mule アプリケーションの作成 サンプルスクリプトを作成してローカルに保存したら、Studio で Mule アプリケーションを作成します。 1. **Package Explorer**​ ウィンドウの ​**src/main/mule (フロー)**​ フォルダーで、フローの ​`.xml`​ ファイルに移動します。 2. **\[Mule Palette (Mule パレット)\]**​ ビューで、​**HTTP Listener**​ ソースを選択してキャンバスにドラッグします。 ソースが受信 HTTP 要求をリスンすることでフローが開始します。 3. **\[Path (パス)\]**​ 項目を ​`/test`​ に設定します。 4. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の HTTP リスナーのすべてのインスタンスで使用できるグローバル要素を設定します。 5. **\[General (一般)\]**​ タブで、次の項目を設定します。 - **Host (ホスト)**​: `All Interfaces [0.0.0.0] (default)` - **Port (ポート)**​: `8081` 6. **\[OK\]**​ をクリックします。 7. **\[File Read\]**​ 操作を ​**\[HTTP Listener\]**​ の右にドラッグします。 8. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の File Read 操作のすべてのインスタンスで使用できるグローバル要素を設定します。 9. **\[General (一般)\]**​ タブで、​**\[Working Directory (作業ディレクトリ)\]**​ 項目を Studio プロジェクトと以前の DataWeave スクリプトを含むメインリソースフォルダーに設定します。 `/Users/username/AnypointStudio/studio-workspace/dynamicevaluate/src/main/resources` 10. **\[OK\]**​ をクリックします。 11. **\[File path (ファイルパス)\]**​ 項目で、パス ​`#["dw_" ++ attributes.queryParams.locale ++ ".dwl"]`​ を設定します。 コネクタは、​`dw_`​ で始まり、HTTP 要求で受信した ​`locale`​ クエリパラメーター (​`attributes.queryParams.locale`​) を含む、ローカルに保存された DataWeave スクリプトファイル名を読み取ります。 12. **\[Advanced (詳細)\]**​ タブで、​**\[Target Variable (対象変数)\]**​ 項目を ​`dwScript`​ に設定します。 この変数には、ファイル検索に一致した DataWeave スクリプトが保存されます。 13. **\[Dynamic Evaluate\]**​ コンポーネントを ​**\[File Read\]**​ の右にドラッグします。 14. **\[Expression (式)\]**​ 項目を ​`#[vars."dwScript"]`​ に設定して、変数 ​`dwScript`​ に保存された一致する DataWeave スクリプトを実行します。 15. **\[Target value (対象値)\]**​ 項目を ​`payload`​ に設定します。 16. **\[Logger\]**​ コンポーネントを ​**\[Dynamic Evaluate\]**​ の右にドラッグします。 17. **\[Message (メッセージ)\]**​ 項目を ​`#[payload]`​ に設定します。 18. Mule アプリケーションを保存します。 ### [](#mule-アプリケーションの実行とテスト)Mule アプリケーションの実行とテスト Mule アプリケーションを作成したら、実行してテストします。 1. **Package Explorer**​ でプロジェクト名をクリックし、​**\[Run (実行)\] > \[Run As (別のユーザーとして実行)\] > \[Mule Application (Mule アプリケーション)\]**​ をクリックします。 2. 次のクエリパラメーター ​`locale=en-US`​ または ​`locale=es-AR`​ のいずれかを URL に追加して、POST 要求を ​`http://localhost:8081/test`​ に送信します。次に例を示します。 `http://localhost:8081/test?locale=en-US` さらに、POST 要求で次のペイロードを送信します。 ```JSON { "name": "Max", "last": "The Mule", "loc": "Argentina" } ``` 3. Studio コンソールで、ログをスクロールして結果のメッセージを確認します。 ```console INFO 2021-01-19 11:18:25,559 [[MuleRuntime].uber.12: [dynamicevaluate].dynamicevaluateFlow.CPU_INTENSIVE @2588f400] [processor: dynamicevaluateFlow/processors/2; event: 319aacc0-5a61-11eb-bbb8-f01898ad2638] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "First Name": "Max", "Last Name": "The Mule", "Country": "Argentina" } ``` ### [](#ファイルシステムから-dataweave-スクリプトを評価するための-xml)ファイルシステムから DataWeave スクリプトを評価するための XML この例のフローをすばやく Mule アプリケーションに読み込むには、次のコードを Studio XML エディターに貼り付けます。 ```xml ``` ## [](#データベースから-dataweave-スクリプトを評価する例)データベースから DataWeave スクリプトを評価する例 次の例では、​`userId`​ クエリパラメーターを使用してデータベースからスクリプトを選択し、そのスクリプトを ​`userScript`​ 変数に保存します。​`dynamic-evaluate`​ コンポーネントは、​`userScript`​ 変数にアクセスし、指令された (​`attributes.queryParams.userName`​ の値を含む) パラメーター ​`name`​ を使用してスクリプトを呼び出します。 ```xml #["SELECT script FROM SCRIPTS WHERE ID = $(attributes.queryParams.userId)"] #[{name: attributes.queryParams.userName}] ``` 次のスクリプトが例のデータベースのエントリ ​`lsalander`​ と ​`mblomkvist`​ にそれぞれ保存されているとします。 例: lsalander スクリプト output application/json --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } 例: mblomkvist スクリプト output application/x-www-form-urlencoded --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } ### [](#アプリケーション動作の例)アプリケーション動作の例 このサンプル Mule アプリケーションが要求で ​`lsalander`​ を ​`queryParams.userId`​ として受け取ると、Mule は対応するスクリプトを実行して JSON 応答を返します。アプリケーションが ​`mblomkvist`​ を ​`queryParams.userId`​ 値として受け取った場合、Mule は別のスクリプトを実行して ​`x-www-form-urlencoded`​ 応答を返します。 この例は、ユーザーに基づいて応答種別をパラメーター化でき、さらに各ユーザーのニーズに合わせて応答全体をパラメーター化できることを示しています。 # Dynamic Evaluate コンポーネント Dynamic Evaluate コンポーネントは、式を評価して DataWeave スクリプトを選択し、新しいスクリプトを実行して結果を生成します。この動作により、​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about)​でハードコード化する代わりに、動的にスクリプトを選択できます。 スクリプトには、​`message`​、​`payload`​、​`vars`​、​`attributes`​ などの通常の​[コンテキスト変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​を使用できますが、キー - 値ペアのセットを指定することによってカスタム変数を追加することもできます。 ## [](#動的評価の設定)動的評価の設定
項目 値 説明 例

式

DataWeave 式

Mule が実行する DataWeave スクリプトを選択する式を指定します。

expression="#[vars.generateOrderScript]"

パラメーター

DataWeave 式

DataWeave スクリプトが評価するパラメーターとして設定されるキー-値ペアを指定します。

#[{joiner: ' and ', id: payload.user.id}]​
## [](#ファイルシステムから-dataweave-スクリプトを評価する例)ファイルシステムから DataWeave スクリプトを評価する例 次の例は、Dynamic Evaluate コンポーネントで、ファイルシステムのローカルに保存されている DataWeave スクリプトを選択して実行する方法を示しています。アプリケーションのフロー動作は次のようになります。 1. HTTP Listener ソースで、​`locale`​ クエリパラメーターとペイロードを含む POST URL 要求をリスンします。 2. File Read 操作で、HTTP 要求で受信した ​`locale`​ クエリパラメーターを使用して、パラメーター名に一致する DataWeave スクリプトをローカルで検索します。 3. File Read 操作で、スクリプトのコンテンツを新しい変数に保存します。 4. Dynamic Evaluate コンポーネントで、変数に保存された DataWeave 式を実行します。 5. Logger コンポーネントで、変換のペイロード結果をログに記録します。 ローカルに保存された DataWeave スクリプトは、ローカルではなくデータベースに保存することができ、ファイルシステムではなくデータベースからファイルを選択するようにアプリケーションを変更できます。これにより、アプリケーションのデプロイおよび実行中に任意の ​`.dwl`​ ファイルを置き換えることができ、アプリケーションを変更または再デプロイすることなく、実行する DataWeave スクリプトを変更できます。 この例では、2 つの DataWeave スクリプトを作成してローカルに保存し、Mule アプリケーションを作成して、アプリケーションを実行およびテストします。 ![Anypoint Studio の Dynamic Evaluate コンポーネントが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/dynamic-evaluate-flow-1.png) Figure 1. Anypoint Studio での Dynamic Evaluate フローの例 ### [](#dataweave-スクリプトの作成と保存)DataWeave スクリプトの作成と保存 ファイルシステムから DataWeave スクリプトを評価する最初のステップは、スクリプトを作成してローカルに保存することです。 1. Studio で新しい Mule プロジェクトを作成します。 2. **Package Explorer**​ ウィンドウの Mule プロジェクト名の下で、​**src/main/resources**​ フォルダーをクリックし、​**\[New (新規)\] > \[File (ファイル)\]**​ を選択します。 3. **\[File name (ファイル名)\]**​ 項目で、名前 ​`dw_en-US.dwl`​ を追加して、新しい DataWeave スクリプトファイルを作成します。 4. **\[Finish (完了)\]**​ をクリックします。 5. **dw\_en-US.dwl**​ ウィンドウで、次の DataWeave 式を貼り付けます。 ```dataweave %dw 2.0 output application/json --- { "First Name": payload.name, "Last Name": payload.last, "Country": payload.loc } ``` 6. 前の手順を繰り返して、次の DataWeave 式を含む ​`dw_es-AR.dwl`​ という名前の新しいファイルを作成します。 ```dataweave %dw 2.0 output application/json --- { "Nombre": payload.name, "Apellido": payload.last, "País": payload.loc } ``` 7. 変更を保存します。 ### [](#mule-アプリケーションの作成)Mule アプリケーションの作成 サンプルスクリプトを作成してローカルに保存したら、Studio で Mule アプリケーションを作成します。 1. **Package Explorer**​ ウィンドウの ​**src/main/mule (フロー)**​ フォルダーで、フローの ​`.xml`​ ファイルに移動します。 2. **\[Mule Palette (Mule パレット)\]**​ ビューで、​**HTTP Listener**​ ソースを選択してキャンバスにドラッグします。 ソースが受信 HTTP 要求をリスンすることでフローが開始します。 3. **\[Path (パス)\]**​ 項目を ​`/test`​ に設定します。 4. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の HTTP リスナーのすべてのインスタンスで使用できるグローバル要素を設定します。 5. **\[General (一般)\]**​ タブで、次の項目を設定します。 - **Host (ホスト)**​: `All Interfaces [0.0.0.0] (default)` - **Port (ポート)**​: `8081` 6. **\[OK\]**​ をクリックします。 7. **\[File Read\]**​ 操作を ​**\[HTTP Listener\]**​ の右にドラッグします。 8. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の File Read 操作のすべてのインスタンスで使用できるグローバル要素を設定します。 9. **\[General (一般)\]**​ タブで、​**\[Working Directory (作業ディレクトリ)\]**​ 項目を Studio プロジェクトと以前の DataWeave スクリプトを含むメインリソースフォルダーに設定します。 `/Users/username/AnypointStudio/studio-workspace/dynamicevaluate/src/main/resources` 10. **\[OK\]**​ をクリックします。 11. **\[File path (ファイルパス)\]**​ 項目で、パス ​`#["dw_" ++ attributes.queryParams.locale ++ ".dwl"]`​ を設定します。 コネクタは、​`dw_`​ で始まり、HTTP 要求で受信した ​`locale`​ クエリパラメーター (​`attributes.queryParams.locale`​) を含む、ローカルに保存された DataWeave スクリプトファイル名を読み取ります。 12. **\[Advanced (詳細)\]**​ タブで、​**\[Target Variable (対象変数)\]**​ 項目を ​`dwScript`​ に設定します。 この変数には、ファイル検索に一致した DataWeave スクリプトが保存されます。 13. **\[Dynamic Evaluate\]**​ コンポーネントを ​**\[File Read\]**​ の右にドラッグします。 14. **\[Expression (式)\]**​ 項目を ​`#[vars."dwScript"]`​ に設定して、変数 ​`dwScript`​ に保存された一致する DataWeave スクリプトを実行します。 15. **\[Target value (対象値)\]**​ 項目を ​`payload`​ に設定します。 16. **\[Logger\]**​ コンポーネントを ​**\[Dynamic Evaluate\]**​ の右にドラッグします。 17. **\[Message (メッセージ)\]**​ 項目を ​`#[payload]`​ に設定します。 18. Mule アプリケーションを保存します。 ### [](#mule-アプリケーションの実行とテスト)Mule アプリケーションの実行とテスト Mule アプリケーションを作成したら、実行してテストします。 1. **Package Explorer**​ でプロジェクト名をクリックし、​**\[Run (実行)\] > \[Run As (別のユーザーとして実行)\] > \[Mule Application (Mule アプリケーション)\]**​ をクリックします。 2. 次のクエリパラメーター ​`locale=en-US`​ または ​`locale=es-AR`​ のいずれかを URL に追加して、POST 要求を ​`http://localhost:8081/test`​ に送信します。次に例を示します。 `http://localhost:8081/test?locale=en-US` さらに、POST 要求で次のペイロードを送信します。 ```JSON { "name": "Max", "last": "The Mule", "loc": "Argentina" } ``` 3. Studio コンソールで、ログをスクロールして結果のメッセージを確認します。 ```console INFO 2021-01-19 11:18:25,559 [[MuleRuntime].uber.12: [dynamicevaluate].dynamicevaluateFlow.CPU_INTENSIVE @2588f400] [processor: dynamicevaluateFlow/processors/2; event: 319aacc0-5a61-11eb-bbb8-f01898ad2638] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "First Name": "Max", "Last Name": "The Mule", "Country": "Argentina" } ``` ### [](#ファイルシステムから-dataweave-スクリプトを評価するための-xml)ファイルシステムから DataWeave スクリプトを評価するための XML この例のフローをすばやく Mule アプリケーションに読み込むには、次のコードを Studio XML エディターに貼り付けます。 ```xml ``` ## [](#データベースから-dataweave-スクリプトを評価する例)データベースから DataWeave スクリプトを評価する例 次の例では、​`userId`​ クエリパラメーターを使用してデータベースからスクリプトを選択し、そのスクリプトを ​`userScript`​ 変数に保存します。​`dynamic-evaluate`​ コンポーネントは、​`userScript`​ 変数にアクセスし、指令された (​`attributes.queryParams.userName`​ の値を含む) パラメーター ​`name`​ を使用してスクリプトを呼び出します。 ```xml #["SELECT script FROM SCRIPTS WHERE ID = $(attributes.queryParams.userId)"] #[{name: attributes.queryParams.userName}] ``` 次のスクリプトが例のデータベースのエントリ ​`lsalander`​ と ​`mblomkvist`​ にそれぞれ保存されているとします。 例: lsalander スクリプト output application/json --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } 例: mblomkvist スクリプト output application/x-www-form-urlencoded --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } ### [](#アプリケーション動作の例)アプリケーション動作の例 このサンプル Mule アプリケーションが要求で ​`lsalander`​ を ​`queryParams.userId`​ として受け取ると、Mule は対応するスクリプトを実行して JSON 応答を返します。アプリケーションが ​`mblomkvist`​ を ​`queryParams.userId`​ 値として受け取った場合、Mule は別のスクリプトを実行して ​`x-www-form-urlencoded`​ 応答を返します。 この例は、ユーザーに基づいて応答種別をパラメーター化でき、さらに各ユーザーのニーズに合わせて応答全体をパラメーター化できることを示しています。 # Dynamic Evaluate コンポーネント Dynamic Evaluate コンポーネントは、式を評価して DataWeave スクリプトを選択し、新しいスクリプトを実行して結果を生成します。この動作により、​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about)​でハードコード化する代わりに、動的にスクリプトを選択できます。 スクリプトには、​`message`​、​`payload`​、​`vars`​、​`attributes`​ などの通常の​[コンテキスト変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​を使用できますが、キー - 値ペアのセットを指定することによってカスタム変数を追加することもできます。 ## [](#動的評価の設定)動的評価の設定
項目 値 説明 例

式

DataWeave 式

Mule が実行する DataWeave スクリプトを選択する式を指定します。

expression="#[vars.generateOrderScript]"

パラメーター

DataWeave 式

DataWeave スクリプトが評価するパラメーターとして設定されるキー-値ペアを指定します。

#[{joiner: ' and ', id: payload.user.id}]​
## [](#ファイルシステムから-dataweave-スクリプトを評価する例)ファイルシステムから DataWeave スクリプトを評価する例 次の例は、Dynamic Evaluate コンポーネントで、ファイルシステムのローカルに保存されている DataWeave スクリプトを選択して実行する方法を示しています。アプリケーションのフロー動作は次のようになります。 1. HTTP Listener ソースで、​`locale`​ クエリパラメーターとペイロードを含む POST URL 要求をリスンします。 2. File Read 操作で、HTTP 要求で受信した ​`locale`​ クエリパラメーターを使用して、パラメーター名に一致する DataWeave スクリプトをローカルで検索します。 3. File Read 操作で、スクリプトのコンテンツを新しい変数に保存します。 4. Dynamic Evaluate コンポーネントで、変数に保存された DataWeave 式を実行します。 5. Logger コンポーネントで、変換のペイロード結果をログに記録します。 ローカルに保存された DataWeave スクリプトは、ローカルではなくデータベースに保存することができ、ファイルシステムではなくデータベースからファイルを選択するようにアプリケーションを変更できます。これにより、アプリケーションのデプロイおよび実行中に任意の ​`.dwl`​ ファイルを置き換えることができ、アプリケーションを変更または再デプロイすることなく、実行する DataWeave スクリプトを変更できます。 この例では、2 つの DataWeave スクリプトを作成してローカルに保存し、Mule アプリケーションを作成して、アプリケーションを実行およびテストします。 ![Anypoint Studio の Dynamic Evaluate コンポーネントが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/dynamic-evaluate-flow-1.png) Figure 1. Anypoint Studio での Dynamic Evaluate フローの例 ### [](#dataweave-スクリプトの作成と保存)DataWeave スクリプトの作成と保存 ファイルシステムから DataWeave スクリプトを評価する最初のステップは、スクリプトを作成してローカルに保存することです。 1. Studio で新しい Mule プロジェクトを作成します。 2. **Package Explorer**​ ウィンドウの Mule プロジェクト名の下で、​**src/main/resources**​ フォルダーをクリックし、​**\[New (新規)\] > \[File (ファイル)\]**​ を選択します。 3. **\[File name (ファイル名)\]**​ 項目で、名前 ​`dw_en-US.dwl`​ を追加して、新しい DataWeave スクリプトファイルを作成します。 4. **\[Finish (完了)\]**​ をクリックします。 5. **dw\_en-US.dwl**​ ウィンドウで、次の DataWeave 式を貼り付けます。 ```dataweave %dw 2.0 output application/json --- { "First Name": payload.name, "Last Name": payload.last, "Country": payload.loc } ``` 6. 前の手順を繰り返して、次の DataWeave 式を含む ​`dw_es-AR.dwl`​ という名前の新しいファイルを作成します。 ```dataweave %dw 2.0 output application/json --- { "Nombre": payload.name, "Apellido": payload.last, "País": payload.loc } ``` 7. 変更を保存します。 ### [](#mule-アプリケーションの作成)Mule アプリケーションの作成 サンプルスクリプトを作成してローカルに保存したら、Studio で Mule アプリケーションを作成します。 1. **Package Explorer**​ ウィンドウの ​**src/main/mule (フロー)**​ フォルダーで、フローの ​`.xml`​ ファイルに移動します。 2. **\[Mule Palette (Mule パレット)\]**​ ビューで、​**HTTP Listener**​ ソースを選択してキャンバスにドラッグします。 ソースが受信 HTTP 要求をリスンすることでフローが開始します。 3. **\[Path (パス)\]**​ 項目を ​`/test`​ に設定します。 4. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の HTTP リスナーのすべてのインスタンスで使用できるグローバル要素を設定します。 5. **\[General (一般)\]**​ タブで、次の項目を設定します。 - **Host (ホスト)**​: `All Interfaces [0.0.0.0] (default)` - **Port (ポート)**​: `8081` 6. **\[OK\]**​ をクリックします。 7. **\[File Read\]**​ 操作を ​**\[HTTP Listener\]**​ の右にドラッグします。 8. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の File Read 操作のすべてのインスタンスで使用できるグローバル要素を設定します。 9. **\[General (一般)\]**​ タブで、​**\[Working Directory (作業ディレクトリ)\]**​ 項目を Studio プロジェクトと以前の DataWeave スクリプトを含むメインリソースフォルダーに設定します。 `/Users/username/AnypointStudio/studio-workspace/dynamicevaluate/src/main/resources` 10. **\[OK\]**​ をクリックします。 11. **\[File path (ファイルパス)\]**​ 項目で、パス ​`#["dw_" ++ attributes.queryParams.locale ++ ".dwl"]`​ を設定します。 コネクタは、​`dw_`​ で始まり、HTTP 要求で受信した ​`locale`​ クエリパラメーター (​`attributes.queryParams.locale`​) を含む、ローカルに保存された DataWeave スクリプトファイル名を読み取ります。 12. **\[Advanced (詳細)\]**​ タブで、​**\[Target Variable (対象変数)\]**​ 項目を ​`dwScript`​ に設定します。 この変数には、ファイル検索に一致した DataWeave スクリプトが保存されます。 13. **\[Dynamic Evaluate\]**​ コンポーネントを ​**\[File Read\]**​ の右にドラッグします。 14. **\[Expression (式)\]**​ 項目を ​`#[vars."dwScript"]`​ に設定して、変数 ​`dwScript`​ に保存された一致する DataWeave スクリプトを実行します。 15. **\[Target value (対象値)\]**​ 項目を ​`payload`​ に設定します。 16. **\[Logger\]**​ コンポーネントを ​**\[Dynamic Evaluate\]**​ の右にドラッグします。 17. **\[Message (メッセージ)\]**​ 項目を ​`#[payload]`​ に設定します。 18. Mule アプリケーションを保存します。 ### [](#mule-アプリケーションの実行とテスト)Mule アプリケーションの実行とテスト Mule アプリケーションを作成したら、実行してテストします。 1. **Package Explorer**​ でプロジェクト名をクリックし、​**\[Run (実行)\] > \[Run As (別のユーザーとして実行)\] > \[Mule Application (Mule アプリケーション)\]**​ をクリックします。 2. 次のクエリパラメーター ​`locale=en-US`​ または ​`locale=es-AR`​ のいずれかを URL に追加して、POST 要求を ​`http://localhost:8081/test`​ に送信します。次に例を示します。 `http://localhost:8081/test?locale=en-US` さらに、POST 要求で次のペイロードを送信します。 ```JSON { "name": "Max", "last": "The Mule", "loc": "Argentina" } ``` 3. Studio コンソールで、ログをスクロールして結果のメッセージを確認します。 ```console INFO 2021-01-19 11:18:25,559 [[MuleRuntime].uber.12: [dynamicevaluate].dynamicevaluateFlow.CPU_INTENSIVE @2588f400] [processor: dynamicevaluateFlow/processors/2; event: 319aacc0-5a61-11eb-bbb8-f01898ad2638] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "First Name": "Max", "Last Name": "The Mule", "Country": "Argentina" } ``` ### [](#ファイルシステムから-dataweave-スクリプトを評価するための-xml)ファイルシステムから DataWeave スクリプトを評価するための XML この例のフローをすばやく Mule アプリケーションに読み込むには、次のコードを Studio XML エディターに貼り付けます。 ```xml ``` ## [](#データベースから-dataweave-スクリプトを評価する例)データベースから DataWeave スクリプトを評価する例 次の例では、​`userId`​ クエリパラメーターを使用してデータベースからスクリプトを選択し、そのスクリプトを ​`userScript`​ 変数に保存します。​`dynamic-evaluate`​ コンポーネントは、​`userScript`​ 変数にアクセスし、指令された (​`attributes.queryParams.userName`​ の値を含む) パラメーター ​`name`​ を使用してスクリプトを呼び出します。 ```xml #["SELECT script FROM SCRIPTS WHERE ID = $(attributes.queryParams.userId)"] #[{name: attributes.queryParams.userName}] ``` 次のスクリプトが例のデータベースのエントリ ​`lsalander`​ と ​`mblomkvist`​ にそれぞれ保存されているとします。 例: lsalander スクリプト output application/json --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } 例: mblomkvist スクリプト output application/x-www-form-urlencoded --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } ### [](#アプリケーション動作の例)アプリケーション動作の例 このサンプル Mule アプリケーションが要求で ​`lsalander`​ を ​`queryParams.userId`​ として受け取ると、Mule は対応するスクリプトを実行して JSON 応答を返します。アプリケーションが ​`mblomkvist`​ を ​`queryParams.userId`​ 値として受け取った場合、Mule は別のスクリプトを実行して ​`x-www-form-urlencoded`​ 応答を返します。 この例は、ユーザーに基づいて応答種別をパラメーター化でき、さらに各ユーザーのニーズに合わせて応答全体をパラメーター化できることを示しています。 # Dynamic Evaluate コンポーネント Dynamic Evaluate コンポーネントは、式を評価して DataWeave スクリプトを選択し、新しいスクリプトを実行して結果を生成します。この動作により、​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about)​でハードコード化する代わりに、動的にスクリプトを選択できます。 スクリプトには、​`message`​、​`payload`​、​`vars`​、​`attributes`​ などの通常の​[コンテキスト変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​を使用できますが、キー - 値ペアのセットを指定することによってカスタム変数を追加することもできます。 ## [](#動的評価の設定)動的評価の設定
項目 値 説明 例

式

DataWeave 式

Mule が実行する DataWeave スクリプトを選択する式を指定します。

expression="#[vars.generateOrderScript]"

パラメーター

DataWeave 式

DataWeave スクリプトが評価するパラメーターとして設定されるキー-値ペアを指定します。

#[{joiner: ' and ', id: payload.user.id}]​
## [](#ファイルシステムから-dataweave-スクリプトを評価する例)ファイルシステムから DataWeave スクリプトを評価する例 次の例は、Dynamic Evaluate コンポーネントで、ファイルシステムのローカルに保存されている DataWeave スクリプトを選択して実行する方法を示しています。アプリケーションのフロー動作は次のようになります。 1. HTTP Listener ソースで、​`locale`​ クエリパラメーターとペイロードを含む POST URL 要求をリスンします。 2. File Read 操作で、HTTP 要求で受信した ​`locale`​ クエリパラメーターを使用して、パラメーター名に一致する DataWeave スクリプトをローカルで検索します。 3. File Read 操作で、スクリプトのコンテンツを新しい変数に保存します。 4. Dynamic Evaluate コンポーネントで、変数に保存された DataWeave 式を実行します。 5. Logger コンポーネントで、変換のペイロード結果をログに記録します。 ローカルに保存された DataWeave スクリプトは、ローカルではなくデータベースに保存することができ、ファイルシステムではなくデータベースからファイルを選択するようにアプリケーションを変更できます。これにより、アプリケーションのデプロイおよび実行中に任意の ​`.dwl`​ ファイルを置き換えることができ、アプリケーションを変更または再デプロイすることなく、実行する DataWeave スクリプトを変更できます。 この例では、2 つの DataWeave スクリプトを作成してローカルに保存し、Mule アプリケーションを作成して、アプリケーションを実行およびテストします。 ![Anypoint Studio の Dynamic Evaluate コンポーネントが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/dynamic-evaluate-flow-1.png) Figure 1. Anypoint Studio での Dynamic Evaluate フローの例 ### [](#dataweave-スクリプトの作成と保存)DataWeave スクリプトの作成と保存 ファイルシステムから DataWeave スクリプトを評価する最初のステップは、スクリプトを作成してローカルに保存することです。 1. Studio で新しい Mule プロジェクトを作成します。 2. **Package Explorer**​ ウィンドウの Mule プロジェクト名の下で、​**src/main/resources**​ フォルダーをクリックし、​**\[New (新規)\] > \[File (ファイル)\]**​ を選択します。 3. **\[File name (ファイル名)\]**​ 項目で、名前 ​`dw_en-US.dwl`​ を追加して、新しい DataWeave スクリプトファイルを作成します。 4. **\[Finish (完了)\]**​ をクリックします。 5. **dw\_en-US.dwl**​ ウィンドウで、次の DataWeave 式を貼り付けます。 ```dataweave %dw 2.0 output application/json --- { "First Name": payload.name, "Last Name": payload.last, "Country": payload.loc } ``` 6. 前の手順を繰り返して、次の DataWeave 式を含む ​`dw_es-AR.dwl`​ という名前の新しいファイルを作成します。 ```dataweave %dw 2.0 output application/json --- { "Nombre": payload.name, "Apellido": payload.last, "País": payload.loc } ``` 7. 変更を保存します。 ### [](#mule-アプリケーションの作成)Mule アプリケーションの作成 サンプルスクリプトを作成してローカルに保存したら、Studio で Mule アプリケーションを作成します。 1. **Package Explorer**​ ウィンドウの ​**src/main/mule (フロー)**​ フォルダーで、フローの ​`.xml`​ ファイルに移動します。 2. **\[Mule Palette (Mule パレット)\]**​ ビューで、​**HTTP Listener**​ ソースを選択してキャンバスにドラッグします。 ソースが受信 HTTP 要求をリスンすることでフローが開始します。 3. **\[Path (パス)\]**​ 項目を ​`/test`​ に設定します。 4. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の HTTP リスナーのすべてのインスタンスで使用できるグローバル要素を設定します。 5. **\[General (一般)\]**​ タブで、次の項目を設定します。 - **Host (ホスト)**​: `All Interfaces [0.0.0.0] (default)` - **Port (ポート)**​: `8081` 6. **\[OK\]**​ をクリックします。 7. **\[File Read\]**​ 操作を ​**\[HTTP Listener\]**​ の右にドラッグします。 8. **\[Connector configuration (コネクタ設定)\]**​ 項目の横にあるプラス記号 (​**+**​) をクリックして、アプリケーション内の File Read 操作のすべてのインスタンスで使用できるグローバル要素を設定します。 9. **\[General (一般)\]**​ タブで、​**\[Working Directory (作業ディレクトリ)\]**​ 項目を Studio プロジェクトと以前の DataWeave スクリプトを含むメインリソースフォルダーに設定します。 `/Users/username/AnypointStudio/studio-workspace/dynamicevaluate/src/main/resources` 10. **\[OK\]**​ をクリックします。 11. **\[File path (ファイルパス)\]**​ 項目で、パス ​`#["dw_" ++ attributes.queryParams.locale ++ ".dwl"]`​ を設定します。 コネクタは、​`dw_`​ で始まり、HTTP 要求で受信した ​`locale`​ クエリパラメーター (​`attributes.queryParams.locale`​) を含む、ローカルに保存された DataWeave スクリプトファイル名を読み取ります。 12. **\[Advanced (詳細)\]**​ タブで、​**\[Target Variable (対象変数)\]**​ 項目を ​`dwScript`​ に設定します。 この変数には、ファイル検索に一致した DataWeave スクリプトが保存されます。 13. **\[Dynamic Evaluate\]**​ コンポーネントを ​**\[File Read\]**​ の右にドラッグします。 14. **\[Expression (式)\]**​ 項目を ​`#[vars."dwScript"]`​ に設定して、変数 ​`dwScript`​ に保存された一致する DataWeave スクリプトを実行します。 15. **\[Target value (対象値)\]**​ 項目を ​`payload`​ に設定します。 16. **\[Logger\]**​ コンポーネントを ​**\[Dynamic Evaluate\]**​ の右にドラッグします。 17. **\[Message (メッセージ)\]**​ 項目を ​`#[payload]`​ に設定します。 18. Mule アプリケーションを保存します。 ### [](#mule-アプリケーションの実行とテスト)Mule アプリケーションの実行とテスト Mule アプリケーションを作成したら、実行してテストします。 1. **Package Explorer**​ でプロジェクト名をクリックし、​**\[Run (実行)\] > \[Run As (別のユーザーとして実行)\] > \[Mule Application (Mule アプリケーション)\]**​ をクリックします。 2. 次のクエリパラメーター ​`locale=en-US`​ または ​`locale=es-AR`​ のいずれかを URL に追加して、POST 要求を ​`http://localhost:8081/test`​ に送信します。次に例を示します。 `http://localhost:8081/test?locale=en-US` さらに、POST 要求で次のペイロードを送信します。 ```JSON { "name": "Max", "last": "The Mule", "loc": "Argentina" } ``` 3. Studio コンソールで、ログをスクロールして結果のメッセージを確認します。 ```console INFO 2021-01-19 11:18:25,559 [[MuleRuntime].uber.12: [dynamicevaluate].dynamicevaluateFlow.CPU_INTENSIVE @2588f400] [processor: dynamicevaluateFlow/processors/2; event: 319aacc0-5a61-11eb-bbb8-f01898ad2638] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "First Name": "Max", "Last Name": "The Mule", "Country": "Argentina" } ``` ### [](#ファイルシステムから-dataweave-スクリプトを評価するための-xml)ファイルシステムから DataWeave スクリプトを評価するための XML この例のフローをすばやく Mule アプリケーションに読み込むには、次のコードを Studio XML エディターに貼り付けます。 ```xml ``` ## [](#データベースから-dataweave-スクリプトを評価する例)データベースから DataWeave スクリプトを評価する例 次の例では、​`userId`​ クエリパラメーターを使用してデータベースからスクリプトを選択し、そのスクリプトを ​`userScript`​ 変数に保存します。​`dynamic-evaluate`​ コンポーネントは、​`userScript`​ 変数にアクセスし、指令された (​`attributes.queryParams.userName`​ の値を含む) パラメーター ​`name`​ を使用してスクリプトを呼び出します。 ```xml #["SELECT script FROM SCRIPTS WHERE ID = $(attributes.queryParams.userId)"] #[{name: attributes.queryParams.userName}] ``` 次のスクリプトが例のデータベースのエントリ ​`lsalander`​ と ​`mblomkvist`​ にそれぞれ保存されているとします。 例: lsalander スクリプト output application/json --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } 例: mblomkvist スクリプト output application/x-www-form-urlencoded --- { message: "Order " ++ attributes.queryParams.orderId ++ " has been received from " ++ name, items: payload.items } ### [](#アプリケーション動作の例)アプリケーション動作の例 このサンプル Mule アプリケーションが要求で ​`lsalander`​ を ​`queryParams.userId`​ として受け取ると、Mule は対応するスクリプトを実行して JSON 応答を返します。アプリケーションが ​`mblomkvist`​ を ​`queryParams.userId`​ 値として受け取った場合、Mule は別のスクリプトを実行して ​`x-www-form-urlencoded`​ 応答を返します。 この例は、ユーザーに基づいて応答種別をパラメーター化でき、さらに各ユーザーのニーズに合わせて応答全体をパラメーター化できることを示しています。 # Email Connector への移行 POP3、IMAP、SMTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、1 つの操作ベースのコネクタに進化しています。 この変更により、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来の IMAP や POP3 トランスポートとは異なり、オンデマンドでメールのコンテンツをリストできる。 - メールの送信操作が簡便になる。 - 受信メールのデータ取得操作が簡便になる。 - Mule の全コネクタの一貫性が確保される。 - メールマッチング機能が向上する。 こうした機能が統合され、送信も受信も同様の操作に統一されています。 ## [](#imappop3smtp-サーバー設定の移行)IMAP、POP3、SMTP サーバー設定の移行 ここでは、Mule 3 の各メールトランスポートの設定を Mule 4 の新しい Email Connector に移行する方法を例示します。 以下の Mule 4 の設定例では、ご覧のとおり、​`inbound-endpoint`​ や ​`outbound-endpoint`​ で宣言されていたパラメーターの大半が (​`user`​、​`password`​、​`host`​、​`port`​ など) ​`connection`​ 要素に移されています。 ### [](#pop3-インバウンドエンドポイントの移行)POP3 インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う POP3 インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-pop3 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#imap-インバウンドエンドポイントの移行)IMAP インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う IMAP インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-imap 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#受信メールの添付ファイル)受信メールの添付ファイル Mule 3 では、受信メールの添付ファイルがメッセージの ​`inboundAttachments`​ 項目で設定されていました。Mule 4 の Email Connector では、添付ファイルがメッセージペイロードの項目で、マップとしてモデル化され、DataWeave を使用してアクセスできます。たとえば、​`photo_png`​ という添付ファイルを参照する式は ​`#[payload.attachments['photo_png']]`​ です。 ### [](#smtp-アウトバウンドエンドポイントの移行)SMTP アウトバウンドエンドポイントの移行 Mule 3 の例: SMTP アウトバウンド設定。 ```xml ... ``` Mule 4 の例: SMTP 設定 ```xml #[payload] ``` Mule 3 のトランスポートでは、アウトバウンド SMTP エンドポイントを実行する前に、送信メールのプロパティ (件名、アドレスなど) をイベントで設定されたアウトバウンドプロパティから設定できました。この場合、アウトバウンドプロパティが、エンドポイントまたはコネクタ自体に設定された値より優先されました。 Mule 3 とは異なり、メールと一緒に送信される添付ファイルは、メッセージの ​`outboundAttachments`​ 項目から取得するのではなく、​`email:send`​ 操作で明示的に設定する必要があります。添付ファイルを送信する推奨パターンは、フローに変数として設定してから、これらの添付ファイルを送信する ​`email:send`​ 操作でその変数を参照することです。 ### [](#セキュアな接続-ssltls-の移行)セキュアな接続 (SSL/TLS) の移行 Mule 3 では、各トランスポート/コネクタに独自の TLS 要素がありました。Mule 4 では、TLS コンテキストが、TLS を設定するための全モジュール共有の要素です。 次の例では、Mule 3 の例と、そのコードを Mule 4 に移行する方法を示しています。
この例では SMTP 設定を使用していますが、IMAP や POP3 設定でも同じです。
Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#mule-4-connector-のプロジェクトへの追加)Mule 4 Connector のプロジェクトへの追加 トランスポートは Mule にバインドされていないため、使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加する必要があります。 ```xml org.mule.connectors mule-email-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Email Connector](https://docs.mulesoft.com/email-connector/latest/) - [Email Connector を使用した Mule 4 での Gmail への接続](https://docs.mulesoft.com/email-connector/latest/email-gmail) # Email Connector への移行 POP3、IMAP、SMTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、1 つの操作ベースのコネクタに進化しています。 この変更により、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来の IMAP や POP3 トランスポートとは異なり、オンデマンドでメールのコンテンツをリストできる。 - メールの送信操作が簡便になる。 - 受信メールのデータ取得操作が簡便になる。 - Mule の全コネクタの一貫性が確保される。 - メールマッチング機能が向上する。 こうした機能が統合され、送信も受信も同様の操作に統一されています。 ## [](#imappop3smtp-サーバー設定の移行)IMAP、POP3、SMTP サーバー設定の移行 ここでは、Mule 3 の各メールトランスポートの設定を Mule 4 の新しい Email Connector に移行する方法を例示します。 以下の Mule 4 の設定例では、ご覧のとおり、​`inbound-endpoint`​ や ​`outbound-endpoint`​ で宣言されていたパラメーターの大半が (​`user`​、​`password`​、​`host`​、​`port`​ など) ​`connection`​ 要素に移されています。 ### [](#pop3-インバウンドエンドポイントの移行)POP3 インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う POP3 インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-pop3 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#imap-インバウンドエンドポイントの移行)IMAP インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う IMAP インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-imap 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#受信メールの添付ファイル)受信メールの添付ファイル Mule 3 では、受信メールの添付ファイルがメッセージの ​`inboundAttachments`​ 項目で設定されていました。Mule 4 の Email Connector では、添付ファイルがメッセージペイロードの項目で、マップとしてモデル化され、DataWeave を使用してアクセスできます。たとえば、​`photo_png`​ という添付ファイルを参照する式は ​`#[payload.attachments['photo_png']]`​ です。 ### [](#smtp-アウトバウンドエンドポイントの移行)SMTP アウトバウンドエンドポイントの移行 Mule 3 の例: SMTP アウトバウンド設定。 ```xml ... ``` Mule 4 の例: SMTP 設定 ```xml #[payload] ``` Mule 3 のトランスポートでは、アウトバウンド SMTP エンドポイントを実行する前に、送信メールのプロパティ (件名、アドレスなど) をイベントで設定されたアウトバウンドプロパティから設定できました。この場合、アウトバウンドプロパティが、エンドポイントまたはコネクタ自体に設定された値より優先されました。 Mule 3 とは異なり、メールと一緒に送信される添付ファイルは、メッセージの ​`outboundAttachments`​ 項目から取得するのではなく、​`email:send`​ 操作で明示的に設定する必要があります。添付ファイルを送信する推奨パターンは、フローに変数として設定してから、これらの添付ファイルを送信する ​`email:send`​ 操作でその変数を参照することです。 ### [](#セキュアな接続-ssltls-の移行)セキュアな接続 (SSL/TLS) の移行 Mule 3 では、各トランスポート/コネクタに独自の TLS 要素がありました。Mule 4 では、TLS コンテキストが、TLS を設定するための全モジュール共有の要素です。 次の例では、Mule 3 の例と、そのコードを Mule 4 に移行する方法を示しています。
この例では SMTP 設定を使用していますが、IMAP や POP3 設定でも同じです。
Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#mule-4-connector-のプロジェクトへの追加)Mule 4 Connector のプロジェクトへの追加 トランスポートは Mule にバインドされていないため、使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加する必要があります。 ```xml org.mule.connectors mule-email-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Email Connector](https://docs.mulesoft.com/email-connector/latest/) - [Email Connector を使用した Mule 4 での Gmail への接続](https://docs.mulesoft.com/email-connector/latest/email-gmail) # Email Connector への移行 POP3、IMAP、SMTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、1 つの操作ベースのコネクタに進化しています。 この変更により、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来の IMAP や POP3 トランスポートとは異なり、オンデマンドでメールのコンテンツをリストできる。 - メールの送信操作が簡便になる。 - 受信メールのデータ取得操作が簡便になる。 - Mule の全コネクタの一貫性が確保される。 - メールマッチング機能が向上する。 こうした機能が統合され、送信も受信も同様の操作に統一されています。 ## [](#imappop3smtp-サーバー設定の移行)IMAP、POP3、SMTP サーバー設定の移行 ここでは、Mule 3 の各メールトランスポートの設定を Mule 4 の新しい Email Connector に移行する方法を例示します。 以下の Mule 4 の設定例では、ご覧のとおり、​`inbound-endpoint`​ や ​`outbound-endpoint`​ で宣言されていたパラメーターの大半が (​`user`​、​`password`​、​`host`​、​`port`​ など) ​`connection`​ 要素に移されています。 ### [](#pop3-インバウンドエンドポイントの移行)POP3 インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う POP3 インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-pop3 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#imap-インバウンドエンドポイントの移行)IMAP インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う IMAP インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-imap 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#受信メールの添付ファイル)受信メールの添付ファイル Mule 3 では、受信メールの添付ファイルがメッセージの ​`inboundAttachments`​ 項目で設定されていました。Mule 4 の Email Connector では、添付ファイルがメッセージペイロードの項目で、マップとしてモデル化され、DataWeave を使用してアクセスできます。たとえば、​`photo_png`​ という添付ファイルを参照する式は ​`#[payload.attachments['photo_png']]`​ です。 ### [](#smtp-アウトバウンドエンドポイントの移行)SMTP アウトバウンドエンドポイントの移行 Mule 3 の例: SMTP アウトバウンド設定。 ```xml ... ``` Mule 4 の例: SMTP 設定 ```xml #[payload] ``` Mule 3 のトランスポートでは、アウトバウンド SMTP エンドポイントを実行する前に、送信メールのプロパティ (件名、アドレスなど) をイベントで設定されたアウトバウンドプロパティから設定できました。この場合、アウトバウンドプロパティが、エンドポイントまたはコネクタ自体に設定された値より優先されました。 Mule 3 とは異なり、メールと一緒に送信される添付ファイルは、メッセージの ​`outboundAttachments`​ 項目から取得するのではなく、​`email:send`​ 操作で明示的に設定する必要があります。添付ファイルを送信する推奨パターンは、フローに変数として設定してから、これらの添付ファイルを送信する ​`email:send`​ 操作でその変数を参照することです。 ### [](#セキュアな接続-ssltls-の移行)セキュアな接続 (SSL/TLS) の移行 Mule 3 では、各トランスポート/コネクタに独自の TLS 要素がありました。Mule 4 では、TLS コンテキストが、TLS を設定するための全モジュール共有の要素です。 次の例では、Mule 3 の例と、そのコードを Mule 4 に移行する方法を示しています。
この例では SMTP 設定を使用していますが、IMAP や POP3 設定でも同じです。
Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#mule-4-connector-のプロジェクトへの追加)Mule 4 Connector のプロジェクトへの追加 トランスポートは Mule にバインドされていないため、使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加する必要があります。 ```xml org.mule.connectors mule-email-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Email Connector](https://docs.mulesoft.com/email-connector/latest/) - [Email Connector を使用した Mule 4 での Gmail への接続](https://docs.mulesoft.com/email-connector/latest/email-gmail) # Email Connector への移行 POP3、IMAP、SMTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、1 つの操作ベースのコネクタに進化しています。 この変更により、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来の IMAP や POP3 トランスポートとは異なり、オンデマンドでメールのコンテンツをリストできる。 - メールの送信操作が簡便になる。 - 受信メールのデータ取得操作が簡便になる。 - Mule の全コネクタの一貫性が確保される。 - メールマッチング機能が向上する。 こうした機能が統合され、送信も受信も同様の操作に統一されています。 ## [](#imappop3smtp-サーバー設定の移行)IMAP、POP3、SMTP サーバー設定の移行 ここでは、Mule 3 の各メールトランスポートの設定を Mule 4 の新しい Email Connector に移行する方法を例示します。 以下の Mule 4 の設定例では、ご覧のとおり、​`inbound-endpoint`​ や ​`outbound-endpoint`​ で宣言されていたパラメーターの大半が (​`user`​、​`password`​、​`host`​、​`port`​ など) ​`connection`​ 要素に移されています。 ### [](#pop3-インバウンドエンドポイントの移行)POP3 インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う POP3 インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-pop3 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#imap-インバウンドエンドポイントの移行)IMAP インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う IMAP インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-imap 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#受信メールの添付ファイル)受信メールの添付ファイル Mule 3 では、受信メールの添付ファイルがメッセージの ​`inboundAttachments`​ 項目で設定されていました。Mule 4 の Email Connector では、添付ファイルがメッセージペイロードの項目で、マップとしてモデル化され、DataWeave を使用してアクセスできます。たとえば、​`photo_png`​ という添付ファイルを参照する式は ​`#[payload.attachments['photo_png']]`​ です。 ### [](#smtp-アウトバウンドエンドポイントの移行)SMTP アウトバウンドエンドポイントの移行 Mule 3 の例: SMTP アウトバウンド設定。 ```xml ... ``` Mule 4 の例: SMTP 設定 ```xml #[payload] ``` Mule 3 のトランスポートでは、アウトバウンド SMTP エンドポイントを実行する前に、送信メールのプロパティ (件名、アドレスなど) をイベントで設定されたアウトバウンドプロパティから設定できました。この場合、アウトバウンドプロパティが、エンドポイントまたはコネクタ自体に設定された値より優先されました。 Mule 3 とは異なり、メールと一緒に送信される添付ファイルは、メッセージの ​`outboundAttachments`​ 項目から取得するのではなく、​`email:send`​ 操作で明示的に設定する必要があります。添付ファイルを送信する推奨パターンは、フローに変数として設定してから、これらの添付ファイルを送信する ​`email:send`​ 操作でその変数を参照することです。 ### [](#セキュアな接続-ssltls-の移行)セキュアな接続 (SSL/TLS) の移行 Mule 3 では、各トランスポート/コネクタに独自の TLS 要素がありました。Mule 4 では、TLS コンテキストが、TLS を設定するための全モジュール共有の要素です。 次の例では、Mule 3 の例と、そのコードを Mule 4 に移行する方法を示しています。
この例では SMTP 設定を使用していますが、IMAP や POP3 設定でも同じです。
Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#mule-4-connector-のプロジェクトへの追加)Mule 4 Connector のプロジェクトへの追加 トランスポートは Mule にバインドされていないため、使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加する必要があります。 ```xml org.mule.connectors mule-email-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Email Connector](https://docs.mulesoft.com/email-connector/latest/) - [Email Connector を使用した Mule 4 での Gmail への接続](https://docs.mulesoft.com/email-connector/latest/email-gmail) # Email Connector への移行 POP3、IMAP、SMTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、1 つの操作ベースのコネクタに進化しています。 この変更により、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来の IMAP や POP3 トランスポートとは異なり、オンデマンドでメールのコンテンツをリストできる。 - メールの送信操作が簡便になる。 - 受信メールのデータ取得操作が簡便になる。 - Mule の全コネクタの一貫性が確保される。 - メールマッチング機能が向上する。 こうした機能が統合され、送信も受信も同様の操作に統一されています。 ## [](#imappop3smtp-サーバー設定の移行)IMAP、POP3、SMTP サーバー設定の移行 ここでは、Mule 3 の各メールトランスポートの設定を Mule 4 の新しい Email Connector に移行する方法を例示します。 以下の Mule 4 の設定例では、ご覧のとおり、​`inbound-endpoint`​ や ​`outbound-endpoint`​ で宣言されていたパラメーターの大半が (​`user`​、​`password`​、​`host`​、​`port`​ など) ​`connection`​ 要素に移されています。 ### [](#pop3-インバウンドエンドポイントの移行)POP3 インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う POP3 インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-pop3 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#imap-インバウンドエンドポイントの移行)IMAP インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う IMAP インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-imap 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#受信メールの添付ファイル)受信メールの添付ファイル Mule 3 では、受信メールの添付ファイルがメッセージの ​`inboundAttachments`​ 項目で設定されていました。Mule 4 の Email Connector では、添付ファイルがメッセージペイロードの項目で、マップとしてモデル化され、DataWeave を使用してアクセスできます。たとえば、​`photo_png`​ という添付ファイルを参照する式は ​`#[payload.attachments['photo_png']]`​ です。 ### [](#smtp-アウトバウンドエンドポイントの移行)SMTP アウトバウンドエンドポイントの移行 Mule 3 の例: SMTP アウトバウンド設定。 ```xml ... ``` Mule 4 の例: SMTP 設定 ```xml #[payload] ``` Mule 3 のトランスポートでは、アウトバウンド SMTP エンドポイントを実行する前に、送信メールのプロパティ (件名、アドレスなど) をイベントで設定されたアウトバウンドプロパティから設定できました。この場合、アウトバウンドプロパティが、エンドポイントまたはコネクタ自体に設定された値より優先されました。 Mule 3 とは異なり、メールと一緒に送信される添付ファイルは、メッセージの ​`outboundAttachments`​ 項目から取得するのではなく、​`email:send`​ 操作で明示的に設定する必要があります。添付ファイルを送信する推奨パターンは、フローに変数として設定してから、これらの添付ファイルを送信する ​`email:send`​ 操作でその変数を参照することです。 ### [](#セキュアな接続-ssltls-の移行)セキュアな接続 (SSL/TLS) の移行 Mule 3 では、各トランスポート/コネクタに独自の TLS 要素がありました。Mule 4 では、TLS コンテキストが、TLS を設定するための全モジュール共有の要素です。 次の例では、Mule 3 の例と、そのコードを Mule 4 に移行する方法を示しています。
この例では SMTP 設定を使用していますが、IMAP や POP3 設定でも同じです。
Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#mule-4-connector-のプロジェクトへの追加)Mule 4 Connector のプロジェクトへの追加 トランスポートは Mule にバインドされていないため、使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加する必要があります。 ```xml org.mule.connectors mule-email-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Email Connector](https://docs.mulesoft.com/email-connector/latest/) - [Email Connector を使用した Mule 4 での Gmail への接続](https://docs.mulesoft.com/email-connector/latest/email-gmail) # Email Connector への移行 POP3、IMAP、SMTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、1 つの操作ベースのコネクタに進化しています。 この変更により、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来の IMAP や POP3 トランスポートとは異なり、オンデマンドでメールのコンテンツをリストできる。 - メールの送信操作が簡便になる。 - 受信メールのデータ取得操作が簡便になる。 - Mule の全コネクタの一貫性が確保される。 - メールマッチング機能が向上する。 こうした機能が統合され、送信も受信も同様の操作に統一されています。 ## [](#imappop3smtp-サーバー設定の移行)IMAP、POP3、SMTP サーバー設定の移行 ここでは、Mule 3 の各メールトランスポートの設定を Mule 4 の新しい Email Connector に移行する方法を例示します。 以下の Mule 4 の設定例では、ご覧のとおり、​`inbound-endpoint`​ や ​`outbound-endpoint`​ で宣言されていたパラメーターの大半が (​`user`​、​`password`​、​`host`​、​`port`​ など) ​`connection`​ 要素に移されています。 ### [](#pop3-インバウンドエンドポイントの移行)POP3 インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う POP3 インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-pop3 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#imap-インバウンドエンドポイントの移行)IMAP インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う IMAP インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-imap 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#受信メールの添付ファイル)受信メールの添付ファイル Mule 3 では、受信メールの添付ファイルがメッセージの ​`inboundAttachments`​ 項目で設定されていました。Mule 4 の Email Connector では、添付ファイルがメッセージペイロードの項目で、マップとしてモデル化され、DataWeave を使用してアクセスできます。たとえば、​`photo_png`​ という添付ファイルを参照する式は ​`#[payload.attachments['photo_png']]`​ です。 ### [](#smtp-アウトバウンドエンドポイントの移行)SMTP アウトバウンドエンドポイントの移行 Mule 3 の例: SMTP アウトバウンド設定。 ```xml ... ``` Mule 4 の例: SMTP 設定 ```xml #[payload] ``` Mule 3 のトランスポートでは、アウトバウンド SMTP エンドポイントを実行する前に、送信メールのプロパティ (件名、アドレスなど) をイベントで設定されたアウトバウンドプロパティから設定できました。この場合、アウトバウンドプロパティが、エンドポイントまたはコネクタ自体に設定された値より優先されました。 Mule 3 とは異なり、メールと一緒に送信される添付ファイルは、メッセージの ​`outboundAttachments`​ 項目から取得するのではなく、​`email:send`​ 操作で明示的に設定する必要があります。添付ファイルを送信する推奨パターンは、フローに変数として設定してから、これらの添付ファイルを送信する ​`email:send`​ 操作でその変数を参照することです。 ### [](#セキュアな接続-ssltls-の移行)セキュアな接続 (SSL/TLS) の移行 Mule 3 では、各トランスポート/コネクタに独自の TLS 要素がありました。Mule 4 では、TLS コンテキストが、TLS を設定するための全モジュール共有の要素です。 次の例では、Mule 3 の例と、そのコードを Mule 4 に移行する方法を示しています。
この例では SMTP 設定を使用していますが、IMAP や POP3 設定でも同じです。
Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#mule-4-connector-のプロジェクトへの追加)Mule 4 Connector のプロジェクトへの追加 トランスポートは Mule にバインドされていないため、使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加する必要があります。 ```xml org.mule.connectors mule-email-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Email Connector](https://docs.mulesoft.com/email-connector/latest/) - [Email Connector を使用した Mule 4 での Gmail への接続](https://docs.mulesoft.com/email-connector/latest/email-gmail) # Email Connector への移行 POP3、IMAP、SMTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、1 つの操作ベースのコネクタに進化しています。 この変更により、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来の IMAP や POP3 トランスポートとは異なり、オンデマンドでメールのコンテンツをリストできる。 - メールの送信操作が簡便になる。 - 受信メールのデータ取得操作が簡便になる。 - Mule の全コネクタの一貫性が確保される。 - メールマッチング機能が向上する。 こうした機能が統合され、送信も受信も同様の操作に統一されています。 ## [](#imappop3smtp-サーバー設定の移行)IMAP、POP3、SMTP サーバー設定の移行 ここでは、Mule 3 の各メールトランスポートの設定を Mule 4 の新しい Email Connector に移行する方法を例示します。 以下の Mule 4 の設定例では、ご覧のとおり、​`inbound-endpoint`​ や ​`outbound-endpoint`​ で宣言されていたパラメーターの大半が (​`user`​、​`password`​、​`host`​、​`port`​ など) ​`connection`​ 要素に移されています。 ### [](#pop3-インバウンドエンドポイントの移行)POP3 インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う POP3 インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-pop3 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#imap-インバウンドエンドポイントの移行)IMAP インバウンドエンドポイントの移行 Mule 3 の例: ポーリングを行う IMAP インバウンド設定 ```xml ... ``` Mule 4 の例: POP3 設定 ```xml ... ```
list-imap 操作はポーリングを行わず、スケジューラーがフローのトリガーを実施します。
### [](#受信メールの添付ファイル)受信メールの添付ファイル Mule 3 では、受信メールの添付ファイルがメッセージの ​`inboundAttachments`​ 項目で設定されていました。Mule 4 の Email Connector では、添付ファイルがメッセージペイロードの項目で、マップとしてモデル化され、DataWeave を使用してアクセスできます。たとえば、​`photo_png`​ という添付ファイルを参照する式は ​`#[payload.attachments['photo_png']]`​ です。 ### [](#smtp-アウトバウンドエンドポイントの移行)SMTP アウトバウンドエンドポイントの移行 Mule 3 の例: SMTP アウトバウンド設定。 ```xml ... ``` Mule 4 の例: SMTP 設定 ```xml #[payload] ``` Mule 3 のトランスポートでは、アウトバウンド SMTP エンドポイントを実行する前に、送信メールのプロパティ (件名、アドレスなど) をイベントで設定されたアウトバウンドプロパティから設定できました。この場合、アウトバウンドプロパティが、エンドポイントまたはコネクタ自体に設定された値より優先されました。 Mule 3 とは異なり、メールと一緒に送信される添付ファイルは、メッセージの ​`outboundAttachments`​ 項目から取得するのではなく、​`email:send`​ 操作で明示的に設定する必要があります。添付ファイルを送信する推奨パターンは、フローに変数として設定してから、これらの添付ファイルを送信する ​`email:send`​ 操作でその変数を参照することです。 ### [](#セキュアな接続-ssltls-の移行)セキュアな接続 (SSL/TLS) の移行 Mule 3 では、各トランスポート/コネクタに独自の TLS 要素がありました。Mule 4 では、TLS コンテキストが、TLS を設定するための全モジュール共有の要素です。 次の例では、Mule 3 の例と、そのコードを Mule 4 に移行する方法を示しています。
この例では SMTP 設定を使用していますが、IMAP や POP3 設定でも同じです。
Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#mule-4-connector-のプロジェクトへの追加)Mule 4 Connector のプロジェクトへの追加 トランスポートは Mule にバインドされていないため、使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加する必要があります。 ```xml org.mule.connectors mule-email-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Email Connector](https://docs.mulesoft.com/email-connector/latest/) - [Email Connector を使用した Mule 4 での Gmail への接続](https://docs.mulesoft.com/email-connector/latest/email-gmail) # Enterprise ライセンスのインストール Mule Runtime Engine (Mule) Enterprise Edition (EE) のトライアルバージョンは、評価目的で提供されています。Enterprise のトライアルライセンスは、Mule と Anypoint Studio について知るには最適ですが、Mule の使用に制限があり、本番ユーザーには適していません。 Mule Runtime を本番環境で使用する前に、次の手順を実行してトライアルでない ​**Enterprise ライセンス**​を取得してインストールしてください。 1. MuleSoft アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise ライセンス**​を取得します。 2. インストールする前に、以前のライセンスを ​`$MULE_HOME`​ ディレクトリから削除することをお勧めします。 1. `$MULE_HOME/conf/`​ に移動します。 2. 既存の ​`muleLicenseKey.lic`​ ファイルを削除します。 3. 複数のプラットフォームにライセンスをインストールする場合は、続行する前に新しい ​`license.lic`​ ファイルを別の場所にバックアップします。 4. Mule サーバーが​**停止済み (実行していない)**​ であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 5. `mule -installLicense`​ コマンドを実行する前に ​`JAVA_HOME`​ 環境変数を設定します。 1. **Mac/Unix/Linux**​ で ​`JAVA_HOME`​ が自動検出されない場合、問題を回避するためにそれを設定します。 2. **Windows**​ で ​`JAVA_HOME`​ が設定されていない場合、ライセンスインストールに失敗します。 6. ライセンスインストールコマンドを実行します。 1. **Mac/Unix/Linux**​ では、​`$MULE_HOME/bin`​ ディレクトリから ​`mule -installLicense ~/license.lic`​ を実行します。 2. **Windows**​ では、​`license.lic`​ ファイルを ​`\bin`​ フォルダーにコピーしてから、コマンドラインで ​`mule.bat -installLicense license.lic`​ を実行します。 7. `$MULE_HOME/conf`​ ディレクトリに ​`muleLicenseKey.lic`​ という新しいファイルが保存されます。これによって、ライセンスがインストールされたことが示されます。 8. もう一度、通常の方法で Mule サーバーを​**起動**​します。 ## [](#enterprise-edition-ライセンスの確認または削除)Enterprise Edition ライセンスの確認または削除 Mule サーバーが​**停止済み**​であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 Enterprise ライセンスが正常にインストールされたことを確認するには、次のコマンドを実行します。 `mule -verifyLicense` 以前にインストールしたライセンスをアンインストールするには、次のコマンドを実行します。 `mule -unInstallLicense` ライセンスのインストールが失敗し、手動で ​`$MULE_HOME/conf/muleLicenseKey.lic`​ を削除する必要があることがあります。 ## [](#ライセンスキーファイルのダウンロード)ライセンスキーファイルのダウンロード 1. 自分のログイン情報を使用して [サポートポータル](https://help.mulesoft.com)​にログインします。ログイン情報を持っていない場合は、カスタマーサクセスマネージャーにお問い合わせください。 2. MuleSoft ヘルプセンターホームページのナビゲーションメニューにある ​**\[Support (サポート)\]**​ タブをクリックします。 3. ページの中ほどにある ​**\[Subscriptions (サブスクリプション)\]**​ タブをクリックします。 4. ライセンスキーの対象となるサブスクリプションの ​**\[Subscription Name (サブスクリプション名)\]**​ をクリックします。\[Subscription Name (サブスクリプション名)\] (右から 2 番目の列) をクリックする必要があることに注意してください。そうしないと、適切なページに移動できません。 5. ページの一番下の右側にある ​**\[License ID (ライセンス ID)\]**​ をクリックします。 6. ページ先頭の右側にある \[Notes & Attachments (メモ & 添付ファイル)\] で ​**License Key**​ ファイルをクリックします。 ## [](#埋め込まれた-mule-への-enterprise-ライセンスのインストール)埋め込まれた Mule への Enterprise ライセンスのインストール 本番環境にはお勧めしませんが、Studio にバンドルされている Mule に Enterprise ライセンスをインストールすることもできます。 1. Mule Enterprise Edition をダウンロードしてインストールします。 2. アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise Edition ライセンス**​を取得します。 3. 上記の手順を最初のステップから実行して、Mule Enterprise Edition に新しいライセンスをインストールします。 4. `$MULE_HOME/conf`​ ディレクトリから、保存された新しいライセンスファイル ​`muleLicenseKey.lic`​ をコピーします。 5. `muleLicenseKey.lic`​ ファイルを Studio にバンドルされた Mule の埋め込みアプリケーションのクラスパスに貼り付けます。 ## [](#製品ライセンスのインストール)製品ライセンスのインストール SAP Connector またはその他の Premium Connector を使用するには、製品ライセンスを取得してインストールする必要があります。アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、上記のいずれかの製品のライセンスを取得します。
MuleSoft Enterprise Maven カスタマーリポジトリ​では、トライアルバージョンやコミュニティバージョンに含まれていない Mule Enterprise のモジュール、コネクタ、その他のコンポーネントにアクセスできます。詳細は、​「Mule Maven プラグイン」​を参照してください。
## [](#関連情報)関連情報 - [Mule のコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-components) # Enterprise ライセンスのインストール Mule Runtime Engine (Mule) Enterprise Edition (EE) のトライアルバージョンは、評価目的で提供されています。Enterprise のトライアルライセンスは、Mule と Anypoint Studio について知るには最適ですが、Mule の使用に制限があり、本番ユーザーには適していません。 Mule Runtime を本番環境で使用する前に、次の手順を実行してトライアルでない ​**Enterprise ライセンス**​を取得してインストールしてください。 1. MuleSoft アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise ライセンス**​を取得します。 2. インストールする前に、以前のライセンスを ​`$MULE_HOME`​ ディレクトリから削除することをお勧めします。 1. `$MULE_HOME/conf/`​ に移動します。 2. 既存の ​`muleLicenseKey.lic`​ ファイルを削除します。 3. 複数のプラットフォームにライセンスをインストールする場合は、続行する前に新しい ​`license.lic`​ ファイルを別の場所にバックアップします。 4. Mule サーバーが​**停止済み (実行していない)**​ であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 5. `mule -installLicense`​ コマンドを実行する前に ​`JAVA_HOME`​ 環境変数を設定します。 1. **Mac/Unix/Linux**​ で ​`JAVA_HOME`​ が自動検出されない場合、問題を回避するためにそれを設定します。 2. **Windows**​ で ​`JAVA_HOME`​ が設定されていない場合、ライセンスインストールに失敗します。 6. ライセンスインストールコマンドを実行します。 1. **Mac/Unix/Linux**​ では、​`$MULE_HOME/bin`​ ディレクトリから ​`mule -installLicense ~/license.lic`​ を実行します。 2. **Windows**​ では、​`license.lic`​ ファイルを ​`\bin`​ フォルダーにコピーしてから、コマンドラインで ​`mule.bat -installLicense license.lic`​ を実行します。 7. `$MULE_HOME/conf`​ ディレクトリに ​`muleLicenseKey.lic`​ という新しいファイルが保存されます。これによって、ライセンスがインストールされたことが示されます。 8. もう一度、通常の方法で Mule サーバーを​**起動**​します。 ## [](#enterprise-edition-ライセンスの確認または削除)Enterprise Edition ライセンスの確認または削除 Mule サーバーが​**停止済み**​であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 - Enterprise ライセンスが正常にインストールされたことを確認するには、次のコマンドを実行します。 `mule -verifyLicense` コマンドの出力: ```xml License information Evaluation = false, Expiration Date = Tue May 19 00:00:00 UTC 2025, Contact Name = John Doe, Contact Email Address = john.doe@company.com, Contact Telephone = 00000000, Contact Company = Local Global Ltd, Contact Country = US, Entitlements = clustering,api-gateway ``` - 以前にインストールしたライセンスをアンインストールするには、次のコマンドを実行します。 `mule -unInstallLicense` ライセンスのインストールが失敗し、手動で ​`$MULE_HOME/conf/muleLicenseKey.lic`​ を削除する必要があることがあります。 - インストール前にライセンスを検証するには、次のコマンドを実行します。 `mule -verifyLicenseDetails [path_to_license]` このコマンドでは、​`mule -verifyLicense`​ と同じ情報が出力されます。 ## [](#ライセンスキーファイルのダウンロード)ライセンスキーファイルのダウンロード 1. 自分のログイン情報を使用して [サポートポータル](https://help.mulesoft.com)​にログインします。ログイン情報を持っていない場合は、カスタマーサクセスマネージャーにお問い合わせください。 2. MuleSoft ヘルプセンターホームページのナビゲーションメニューにある ​**\[Support (サポート)\]**​ タブをクリックします。 3. ページの中ほどにある ​**\[Subscriptions (サブスクリプション)\]**​ タブをクリックします。 4. ライセンスキーの対象となるサブスクリプションの ​**\[Subscription Name (サブスクリプション名)\]**​ をクリックします。\[Subscription Name (サブスクリプション名)\] (右から 2 番目の列) をクリックする必要があることに注意してください。そうしないと、適切なページに移動できません。 5. ページの一番下の右側にある ​**\[License ID (ライセンス ID)\]**​ をクリックします。 6. ページ先頭の右側にある \[Notes & Attachments (メモ & 添付ファイル)\] で ​**License Key**​ ファイルをクリックします。 ## [](#埋め込まれた-mule-への-enterprise-ライセンスのインストール)埋め込まれた Mule への Enterprise ライセンスのインストール 本番環境にはお勧めしませんが、Studio にバンドルされている Mule に Enterprise ライセンスをインストールすることもできます。 1. Mule Enterprise Edition をダウンロードしてインストールします。 2. アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise Edition ライセンス**​を取得します。 3. 上記の手順を最初のステップから実行して、Mule Enterprise Edition に新しいライセンスをインストールします。 4. `$MULE_HOME/conf`​ ディレクトリから、保存された新しいライセンスファイル ​`muleLicenseKey.lic`​ をコピーします。 5. `muleLicenseKey.lic`​ ファイルを Studio にバンドルされた Mule の埋め込みアプリケーションのクラスパスに貼り付けます。 ## [](#製品ライセンスのインストール)製品ライセンスのインストール SAP Connector またはその他の Premium Connector を使用するには、製品ライセンスを取得してインストールする必要があります。アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、上記のいずれかの製品のライセンスを取得します。
MuleSoft Enterprise Maven カスタマーリポジトリ​では、トライアルバージョンやコミュニティバージョンに含まれていない Mule Enterprise のモジュール、コネクタ、その他のコンポーネントにアクセスできます。詳細は、​「Mule Maven プラグイン」​を参照してください。
## [](#関連情報)関連情報 - [Mule のコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-components) # Enterprise ライセンスのインストール Mule Runtime Engine (Mule) Enterprise Edition (EE) のトライアルバージョンは、評価目的で提供されています。Enterprise のトライアルライセンスは、Mule と Anypoint Studio について知るには最適ですが、Mule の使用に制限があり、本番ユーザーには適していません。 Mule Runtime を本番環境で使用する前に、次の手順を実行してトライアルでない ​**Enterprise ライセンス**​を取得してインストールしてください。 1. MuleSoft アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise ライセンス**​を取得します。 2. インストールする前に、以前のライセンスを ​`$MULE_HOME`​ ディレクトリから削除することをお勧めします。 1. `$MULE_HOME/conf/`​ に移動します。 2. 既存の ​`muleLicenseKey.lic`​ ファイルを削除します。 3. 複数のプラットフォームにライセンスをインストールする場合は、続行する前に新しい ​`license.lic`​ ファイルを別の場所にバックアップします。 4. Mule サーバーが​**停止済み (実行していない)**​ であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 5. `mule -installLicense`​ コマンドを実行する前に ​`JAVA_HOME`​ 環境変数を設定します。 1. **Mac/Unix/Linux**​ で ​`JAVA_HOME`​ が自動検出されない場合、問題を回避するためにそれを設定します。 2. **Windows**​ で ​`JAVA_HOME`​ が設定されていない場合、ライセンスインストールに失敗します。 6. ライセンスインストールコマンドを実行します。 1. **Mac/Unix/Linux**​ では、​`$MULE_HOME/bin`​ ディレクトリから ​`mule -installLicense ~/license.lic`​ を実行します。 2. **Windows**​ では、​`license.lic`​ ファイルを ​`\bin`​ フォルダーにコピーしてから、コマンドラインで ​`mule.bat -installLicense license.lic`​ を実行します。 7. `$MULE_HOME/conf`​ ディレクトリに ​`muleLicenseKey.lic`​ という新しいファイルが保存されます。これによって、ライセンスがインストールされたことが示されます。 8. もう一度、通常の方法で Mule サーバーを​**起動**​します。 ## [](#enterprise-edition-ライセンスの確認または削除)Enterprise Edition ライセンスの確認または削除 Mule サーバーが​**停止済み**​であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 Enterprise ライセンスが正常にインストールされたことを確認するには、次のコマンドを実行します。 `mule -verifyLicense` 以前にインストールしたライセンスをアンインストールするには、次のコマンドを実行します。 `mule -unInstallLicense` ライセンスのインストールが失敗し、手動で ​`$MULE_HOME/conf/muleLicenseKey.lic`​ を削除する必要があることがあります。 ## [](#ライセンスキーファイルのダウンロード)ライセンスキーファイルのダウンロード 1. 自分のログイン情報を使用して [サポートポータル](https://help.mulesoft.com)​にログインします。ログイン情報を持っていない場合は、カスタマーサクセスマネージャーにお問い合わせください。 2. MuleSoft ヘルプセンターホームページのナビゲーションメニューにある ​**\[Support (サポート)\]**​ タブをクリックします。 3. ページの中ほどにある ​**\[Subscriptions (サブスクリプション)\]**​ タブをクリックします。 4. ライセンスキーの対象となるサブスクリプションの ​**\[Subscription Name (サブスクリプション名)\]**​ をクリックします。\[Subscription Name (サブスクリプション名)\] (右から 2 番目の列) をクリックする必要があることに注意してください。そうしないと、適切なページに移動できません。 5. ページの一番下の右側にある ​**\[License ID (ライセンス ID)\]**​ をクリックします。 6. ページ先頭の右側にある \[Notes & Attachments (メモ & 添付ファイル)\] で ​**License Key**​ ファイルをクリックします。 ## [](#埋め込まれた-mule-への-enterprise-ライセンスのインストール)埋め込まれた Mule への Enterprise ライセンスのインストール 本番環境にはお勧めしませんが、Studio にバンドルされている Mule に Enterprise ライセンスをインストールすることもできます。 1. Mule Enterprise Edition をダウンロードしてインストールします。 2. アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise Edition ライセンス**​を取得します。 3. 上記の手順を最初のステップから実行して、Mule Enterprise Edition に新しいライセンスをインストールします。 4. `$MULE_HOME/conf`​ ディレクトリから、保存された新しいライセンスファイル ​`muleLicenseKey.lic`​ をコピーします。 5. `muleLicenseKey.lic`​ ファイルを Studio にバンドルされた Mule の埋め込みアプリケーションのクラスパスに貼り付けます。 ## [](#製品ライセンスのインストール)製品ライセンスのインストール SAP Connector またはその他の Premium Connector を使用するには、製品ライセンスを取得してインストールする必要があります。アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、上記のいずれかの製品のライセンスを取得します。
MuleSoft Enterprise Maven カスタマーリポジトリ​では、トライアルバージョンやコミュニティバージョンに含まれていない Mule Enterprise のモジュール、コネクタ、その他のコンポーネントにアクセスできます。詳細は、​「Mule Maven プラグイン」​を参照してください。
## [](#関連情報)関連情報 - [Mule のコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-components) # Enterprise ライセンスのインストール Mule Runtime Engine (Mule) Enterprise Edition (EE) のトライアルバージョンは、評価目的で提供されています。Enterprise のトライアルライセンスは、Mule と Anypoint Studio について知るには最適ですが、Mule の使用に制限があり、本番ユーザーには適していません。 Mule Runtime を本番環境で使用する前に、次の手順を実行してトライアルでない ​**Enterprise ライセンス**​を取得してインストールしてください。 1. MuleSoft アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise ライセンス**​を取得します。 2. インストールする前に、以前のライセンスを ​`$MULE_HOME`​ ディレクトリから削除することをお勧めします。 1. `$MULE_HOME/conf/`​ に移動します。 2. 既存の ​`muleLicenseKey.lic`​ ファイルを削除します。 3. 複数のプラットフォームにライセンスをインストールする場合は、続行する前に新しい ​`license.lic`​ ファイルを別の場所にバックアップします。 4. Mule サーバーが​**停止済み (実行していない)**​ であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 5. `mule -installLicense`​ コマンドを実行する前に ​`JAVA_HOME`​ 環境変数を設定します。 1. **Mac/Unix/Linux**​ で ​`JAVA_HOME`​ が自動検出されない場合、問題を回避するためにそれを設定します。 2. **Windows**​ で ​`JAVA_HOME`​ が設定されていない場合、ライセンスインストールに失敗します。 6. ライセンスインストールコマンドを実行します。 1. **Mac/Unix/Linux**​ では、​`$MULE_HOME/bin`​ ディレクトリから ​`mule -installLicense ~/license.lic`​ を実行します。 2. **Windows**​ では、​`license.lic`​ ファイルを ​`\bin`​ フォルダーにコピーしてから、コマンドラインで ​`mule.bat -installLicense license.lic`​ を実行します。 7. `$MULE_HOME/conf`​ ディレクトリに ​`muleLicenseKey.lic`​ という新しいファイルが保存されます。これによって、ライセンスがインストールされたことが示されます。 8. もう一度、通常の方法で Mule サーバーを​**起動**​します。 ## [](#enterprise-edition-ライセンスの確認または削除)Enterprise Edition ライセンスの確認または削除 Mule サーバーが​**停止済み**​であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 - Enterprise ライセンスが正常にインストールされたことを確認するには、次のコマンドを実行します。 `mule -verifyLicense` コマンドの出力: ```xml License information Evaluation = false, Expiration Date = Tue May 19 00:00:00 UTC 2025, Contact Name = John Doe, Contact Email Address = john.doe@company.com, Contact Telephone = 00000000, Contact Company = Local Global Ltd, Contact Country = US, Entitlements = clustering,api-gateway ``` - 以前にインストールしたライセンスをアンインストールするには、次のコマンドを実行します。 `mule -unInstallLicense` ライセンスのインストールが失敗し、手動で ​`$MULE_HOME/conf/muleLicenseKey.lic`​ を削除する必要があることがあります。 - インストール前にライセンスを検証するには、次のコマンドを実行します。 `mule -verifyLicenseDetails [path_to_license]` このコマンドでは、​`mule -verifyLicense`​ と同じ情報が出力されます。 ## [](#ライセンスキーファイルのダウンロード)ライセンスキーファイルのダウンロード 1. 自分のログイン情報を使用して [サポートポータル](https://help.mulesoft.com)​にログインします。ログイン情報を持っていない場合は、カスタマーサクセスマネージャーにお問い合わせください。 2. MuleSoft ヘルプセンターホームページのナビゲーションメニューにある ​**\[Support (サポート)\]**​ タブをクリックします。 3. ページの中ほどにある ​**\[Subscriptions (サブスクリプション)\]**​ タブをクリックします。 4. ライセンスキーの対象となるサブスクリプションの ​**\[Subscription Name (サブスクリプション名)\]**​ をクリックします。\[Subscription Name (サブスクリプション名)\] (右から 2 番目の列) をクリックする必要があることに注意してください。そうしないと、適切なページに移動できません。 5. ページの一番下の右側にある ​**\[License ID (ライセンス ID)\]**​ をクリックします。 6. ページ先頭の右側にある \[Notes & Attachments (メモ & 添付ファイル)\] で ​**License Key**​ ファイルをクリックします。 ## [](#埋め込まれた-mule-への-enterprise-ライセンスのインストール)埋め込まれた Mule への Enterprise ライセンスのインストール 本番環境にはお勧めしませんが、Studio にバンドルされている Mule に Enterprise ライセンスをインストールすることもできます。 1. Mule Enterprise Edition をダウンロードしてインストールします。 2. アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise Edition ライセンス**​を取得します。 3. 上記の手順を最初のステップから実行して、Mule Enterprise Edition に新しいライセンスをインストールします。 4. `$MULE_HOME/conf`​ ディレクトリから、保存された新しいライセンスファイル ​`muleLicenseKey.lic`​ をコピーします。 5. `muleLicenseKey.lic`​ ファイルを Studio にバンドルされた Mule の埋め込みアプリケーションのクラスパスに貼り付けます。 ## [](#製品ライセンスのインストール)製品ライセンスのインストール SAP Connector またはその他の Premium Connector を使用するには、製品ライセンスを取得してインストールする必要があります。アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、上記のいずれかの製品のライセンスを取得します。
MuleSoft Enterprise Maven カスタマーリポジトリ​では、トライアルバージョンやコミュニティバージョンに含まれていない Mule Enterprise のモジュール、コネクタ、その他のコンポーネントにアクセスできます。詳細は、​「Mule Maven プラグイン」​を参照してください。
## [](#関連情報)関連情報 - [Mule のコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-components) # Enterprise ライセンスのインストール Mule Runtime Engine (Mule) Enterprise Edition (EE) のトライアルバージョンは、評価目的で提供されています。Enterprise のトライアルライセンスは、Mule と Anypoint Studio について知るには最適ですが、Mule の使用に制限があり、本番ユーザーには適していません。 Mule Runtime を本番環境で使用する前に、次の手順を実行してトライアルでない ​**Enterprise ライセンス**​を取得してインストールしてください。 1. MuleSoft アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise ライセンス**​を取得します。 2. インストールする前に、以前のライセンスを ​`$MULE_HOME`​ ディレクトリから削除することをお勧めします。 1. `$MULE_HOME/conf/`​ に移動します。 2. 既存の ​`muleLicenseKey.lic`​ ファイルを削除します。 3. 複数のプラットフォームにライセンスをインストールする場合は、続行する前に新しい ​`license.lic`​ ファイルを別の場所にバックアップします。 4. Mule サーバーが​**停止済み (実行していない)**​ であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 5. `mule -installLicense`​ コマンドを実行する前に ​`JAVA_HOME`​ 環境変数を設定します。 1. **Mac/Unix/Linux**​ で ​`JAVA_HOME`​ が自動検出されない場合、問題を回避するためにそれを設定します。 2. **Windows**​ で ​`JAVA_HOME`​ が設定されていない場合、ライセンスインストールに失敗します。 6. ライセンスインストールコマンドを実行します。 1. **Mac/Unix/Linux**​ では、​`$MULE_HOME/bin`​ ディレクトリから ​`mule -installLicense ~/license.lic`​ を実行します。 2. **Windows**​ では、​`license.lic`​ ファイルを ​`\bin`​ フォルダーにコピーしてから、コマンドラインで ​`mule.bat -installLicense license.lic`​ を実行します。 7. `$MULE_HOME/conf`​ ディレクトリに ​`muleLicenseKey.lic`​ という新しいファイルが保存されます。これによって、ライセンスがインストールされたことが示されます。 8. もう一度、通常の方法で Mule サーバーを​**起動します**​。 ## [](#enterprise-edition-ライセンスの確認または削除)Enterprise Edition ライセンスの確認または削除 Mule サーバーが​**停止済み**​であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 Enterprise ライセンスが正常にインストールされたことを確認するには、次のコマンドを実行します。 `mule -verifyLicense` 以前にインストールしたライセンスをアンインストールするには、次のコマンドを実行します。 `mule -unInstallLicense` ライセンスのインストールが失敗し、手動で ​`$MULE_HOME/conf/muleLicenseKey.lic`​ を削除する必要があることがあります。 ## [](#ライセンスキーファイルのダウンロード)ライセンスキーファイルのダウンロード 1. ログイン情報を使用して、​[https://help.mulesoft.com](https://help.mulesoft.com) にある MuleSoft サポートポータルにログインします。ログイン情報を持っていない場合は、カスタマーサクセスマネージャーにお問い合わせください。 2. MuleSoft ヘルプセンターホームページのナビゲーションメニューにある ​**\[Support (サポート)\]**​ タブをクリックします。 3. ページの中ほどにある ​**\[Subscriptions (サブスクリプション)\]**​ タブをクリックします。 4. ライセンスキーの対象となるサブスクリプションの ​**\[Subscription Name (サブスクリプション名)\]**​ をクリックします。\[Subscription Name (サブスクリプション名)\] (右から 2 番目の列) をクリックする必要があることに注意してください。そうしないと、適切なページに移動できません。 5. ページの一番下の右側にある ​**\[License ID (ライセンス ID)\]**​ をクリックします。 6. ページ先頭の右側にある \[Notes & Attachments (メモ & 添付ファイル)\] で ​**License Key**​ ファイルをクリックします。 ## [](#埋め込まれた-mule-への-enterprise-ライセンスのインストール)埋め込まれた Mule への Enterprise ライセンスのインストール 本番環境にはお勧めしませんが、Studio にバンドルされている Mule に Enterprise ライセンスをインストールすることもできます。 1. Mule Enterprise Edition をダウンロードしてインストールします。 2. アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise Edition ライセンス**​を取得します。 3. 上記の手順を最初のステップから実行して、Mule Enterprise Edition に新しいライセンスをインストールします。 4. `$MULE_HOME/conf`​ ディレクトリから、保存された新しいライセンスファイル ​`muleLicenseKey.lic`​ をコピーします。 5. `muleLicenseKey.lic`​ ファイルを Studio にバンドルされた Mule の埋め込みアプリケーションのクラスパスに貼り付けます。 ## [](#製品ライセンスのインストール)製品ライセンスのインストール SAP Connector またはその他の Premium Connector を使用するには、製品ライセンスを取得してインストールする必要があります。アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、上記のいずれかの製品のライセンスを取得します。
MuleSoft Enterprise Maven カスタマーリポジトリ​では、トライアルバージョンやコミュニティバージョンに含まれていない Mule Enterprise のモジュール、コネクタ、その他のコンポーネントにアクセスできます。詳細は、​「Mule Maven プラグイン」​を参照してください。
## [](#関連情報)関連情報 - [Mule のコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-components) # Enterprise ライセンスのインストール Mule Runtime Engine (Mule) Enterprise Edition (EE) のトライアルバージョンは、評価目的で提供されています。Enterprise のトライアルライセンスは、Mule と Anypoint Studio について知るには最適ですが、Mule の使用に制限があり、本番ユーザーには適していません。 Mule Runtime を本番環境で使用する前に、次の手順を実行してトライアルでない ​**Enterprise ライセンス**​を取得してインストールしてください。 1. MuleSoft アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise ライセンス**​を取得します。 2. インストールする前に、以前のライセンスを ​`$MULE_HOME`​ ディレクトリから削除することをお勧めします。 1. `$MULE_HOME/conf/`​ に移動します。 2. 既存の ​`muleLicenseKey.lic`​ ファイルを削除します。 3. 複数のプラットフォームにライセンスをインストールする場合は、続行する前に新しい ​`license.lic`​ ファイルを別の場所にバックアップします。 4. Mule サーバーが​**停止済み (実行していない)**​ であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 5. `mule -installLicense`​ コマンドを実行する前に ​`JAVA_HOME`​ 環境変数を設定します。 1. **Mac/Unix/Linux**​ で ​`JAVA_HOME`​ が自動検出されない場合、問題を回避するためにそれを設定します。 2. **Windows**​ で ​`JAVA_HOME`​ が設定されていない場合、ライセンスインストールに失敗します。 6. ライセンスインストールコマンドを実行します。 1. **Mac/Unix/Linux**​ では、​`$MULE_HOME/bin`​ ディレクトリから ​`mule -installLicense ~/license.lic`​ を実行します。 2. **Windows**​ では、​`license.lic`​ ファイルを ​`\bin`​ フォルダーにコピーしてから、コマンドラインで ​`mule.bat -installLicense license.lic`​ を実行します。 7. `$MULE_HOME/conf`​ ディレクトリに ​`muleLicenseKey.lic`​ という新しいファイルが保存されます。これによって、ライセンスがインストールされたことが示されます。 8. もう一度、通常の方法で Mule サーバーを​**起動します**​。 ## [](#enterprise-edition-ライセンスの確認または削除)Enterprise Edition ライセンスの確認または削除 Mule サーバーが​**停止済み**​であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 Enterprise ライセンスが正常にインストールされたことを確認するには、次のコマンドを実行します。 `mule -verifyLicense` 以前にインストールしたライセンスをアンインストールするには、次のコマンドを実行します。 `mule -unInstallLicense` ライセンスのインストールが失敗し、手動で ​`$MULE_HOME/conf/muleLicenseKey.lic`​ を削除する必要があることがあります。 ## [](#ライセンスキーファイルのダウンロード)ライセンスキーファイルのダウンロード 1. ログイン情報を使用して、​[https://help.mulesoft.com](https://help.mulesoft.com) にある MuleSoft サポートポータルにログインします。ログイン情報を持っていない場合は、カスタマーサクセスマネージャーにお問い合わせください。 2. MuleSoft ヘルプセンターホームページのナビゲーションメニューにある ​**\[Support (サポート)\]**​ タブをクリックします。 3. ページの中ほどにある ​**\[Subscriptions (サブスクリプション)\]**​ タブをクリックします。 4. ライセンスキーの対象となるサブスクリプションの ​**\[Subscription Name (サブスクリプション名)\]**​ をクリックします。\[Subscription Name (サブスクリプション名)\] (右から 2 番目の列) をクリックする必要があることに注意してください。そうしないと、適切なページに移動できません。 5. ページの一番下の右側にある ​**\[License ID (ライセンス ID)\]**​ をクリックします。 6. ページ先頭の右側にある \[Notes & Attachments (メモ & 添付ファイル)\] で ​**License Key**​ ファイルをクリックします。 ## [](#埋め込まれた-mule-への-enterprise-ライセンスのインストール)埋め込まれた Mule への Enterprise ライセンスのインストール 本番環境にはお勧めしませんが、Studio にバンドルされている Mule に Enterprise ライセンスをインストールすることもできます。 1. Mule Enterprise Edition をダウンロードしてインストールします。 2. アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise Edition ライセンス**​を取得します。 3. 上記の手順を最初のステップから実行して、Mule Enterprise Edition に新しいライセンスをインストールします。 4. `$MULE_HOME/conf`​ ディレクトリから、保存された新しいライセンスファイル ​`muleLicenseKey.lic`​ をコピーします。 5. `muleLicenseKey.lic`​ ファイルを Studio にバンドルされた Mule の埋め込みアプリケーションのクラスパスに貼り付けます。 ## [](#製品ライセンスのインストール)製品ライセンスのインストール SAP Connector またはその他の Premium Connector を使用するには、製品ライセンスを取得してインストールする必要があります。アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、上記のいずれかの製品のライセンスを取得します。
MuleSoft Enterprise Maven カスタマーリポジトリ​では、トライアルバージョンやコミュニティバージョンに含まれていない Mule Enterprise のモジュール、コネクタ、その他のコンポーネントにアクセスできます。詳細は、​「Mule Maven プラグイン」​を参照してください。
## [](#関連情報)関連情報 - [Mule のコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-components) # Enterprise ライセンスのインストール Mule Runtime Engine (Mule) Enterprise Edition (EE) のトライアルバージョンは、評価目的で提供されています。Enterprise のトライアルライセンスは、Mule と Anypoint Studio について知るには最適ですが、Mule の使用に制限があり、本番ユーザーには適していません。 Mule Runtime を本番環境で使用する前に、次の手順を実行してトライアルでない ​**Enterprise ライセンス**​を取得してインストールしてください。 1. MuleSoft アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise ライセンス**​を取得します。 2. インストールする前に、以前のライセンスを ​`$MULE_HOME`​ ディレクトリから削除することをお勧めします。 1. `$MULE_HOME/conf/`​ に移動します。 2. 既存の ​`muleLicenseKey.lic`​ ファイルを削除します。 3. 複数のプラットフォームにライセンスをインストールする場合は、続行する前に新しい ​`license.lic`​ ファイルを別の場所にバックアップします。 4. Mule サーバーが​**停止済み (実行していない)**​ であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 5. `mule -installLicense`​ コマンドを実行する前に ​`JAVA_HOME`​ 環境変数を設定します。 1. **Mac/Unix/Linux**​ で ​`JAVA_HOME`​ が自動検出されない場合、問題を回避するためにそれを設定します。 2. **Windows**​ で ​`JAVA_HOME`​ が設定されていない場合、ライセンスインストールに失敗します。 6. ライセンスインストールコマンドを実行します。 1. **Mac/Unix/Linux**​ では、​`$MULE_HOME/bin`​ ディレクトリから ​`mule -installLicense ~/license.lic`​ を実行します。 2. **Windows**​ では、​`license.lic`​ ファイルを ​`\bin`​ フォルダーにコピーしてから、コマンドラインで ​`mule.bat -installLicense license.lic`​ を実行します。 7. `$MULE_HOME/conf`​ ディレクトリに ​`muleLicenseKey.lic`​ という新しいファイルが保存されます。これによって、ライセンスがインストールされたことが示されます。 8. もう一度、通常の方法で Mule サーバーを​**起動します**​。 ## [](#enterprise-edition-ライセンスの確認または削除)Enterprise Edition ライセンスの確認または削除 Mule サーバーが​**停止済み**​であることを確認してから、システムのターミナルまたはコマンドラインを開きます。 - Enterprise ライセンスが正常にインストールされたことを確認するには、次のコマンドを実行します。 `mule -verifyLicense` コマンドの出力: ```xml License information Evaluation = false, Expiration Date = Tue May 19 00:00:00 UTC 2025, Contact Name = John Doe, Contact Email Address = john.doe@company.com, Contact Telephone = 00000000, Contact Company = Local Global Ltd, Contact Country = US, Entitlements = clustering,api-gateway ``` - 以前にインストールしたライセンスをアンインストールするには、次のコマンドを実行します。 `mule -unInstallLicense` ライセンスのインストールが失敗し、手動で ​`$MULE_HOME/conf/muleLicenseKey.lic`​ を削除する必要があることがあります。 - インストール前にライセンスを検証するには、次のコマンドを実行します。 `mule -verifyLicenseDetails [path_to_license]` このコマンドでは、​`mule -verifyLicense`​ と同じ情報が出力されます。 ## [](#ライセンスキーファイルのダウンロード)ライセンスキーファイルのダウンロード 1. ログイン情報を使用して、​[https://help.mulesoft.com](https://help.mulesoft.com) にある MuleSoft サポートポータルにログインします。ログイン情報を持っていない場合は、カスタマーサクセスマネージャーにお問い合わせください。 2. MuleSoft ヘルプセンターホームページのナビゲーションメニューにある ​**\[Support (サポート)\]**​ タブをクリックします。 3. ページの中ほどにある ​**\[Subscriptions (サブスクリプション)\]**​ タブをクリックします。 4. ライセンスキーの対象となるサブスクリプションの ​**\[Subscription Name (サブスクリプション名)\]**​ をクリックします。\[Subscription Name (サブスクリプション名)\] (右から 2 番目の列) をクリックする必要があることに注意してください。そうしないと、適切なページに移動できません。 5. ページの一番下の右側にある ​**\[License ID (ライセンス ID)\]**​ をクリックします。 6. ページ先頭の右側にある \[Notes & Attachments (メモ & 添付ファイル)\] で ​**License Key**​ ファイルをクリックします。 ## [](#埋め込まれた-mule-への-enterprise-ライセンスのインストール)埋め込まれた Mule への Enterprise ライセンスのインストール 本番環境にはお勧めしませんが、Studio にバンドルされている Mule に Enterprise ライセンスをインストールすることもできます。 1. Mule Enterprise Edition をダウンロードしてインストールします。 2. アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、​`license.lic`​ ファイルの形式で ​**Enterprise Edition ライセンス**​を取得します。 3. 上記の手順を最初のステップから実行して、Mule Enterprise Edition に新しいライセンスをインストールします。 4. `$MULE_HOME/conf`​ ディレクトリから、保存された新しいライセンスファイル ​`muleLicenseKey.lic`​ をコピーします。 5. `muleLicenseKey.lic`​ ファイルを Studio にバンドルされた Mule の埋め込みアプリケーションのクラスパスに貼り付けます。 ## [](#製品ライセンスのインストール)製品ライセンスのインストール SAP Connector またはその他の Premium Connector を使用するには、製品ライセンスを取得してインストールする必要があります。アカウント担当者または [MuleSoft 営業チーム](http://www.mulesoft.com/contact)​に連絡して、上記のいずれかの製品のライセンスを取得します。
MuleSoft Enterprise Maven カスタマーリポジトリ​では、トライアルバージョンやコミュニティバージョンに含まれていない Mule Enterprise のモジュール、コネクタ、その他のコンポーネントにアクセスできます。詳細は、​「Mule Maven プラグイン」​を参照してください。
## [](#関連情報)関連情報 - [Mule のコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-components) # File Connector の移行 ファイルトランスポートは一新されています。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 ## [](#whats_covered_here)このトピックの内容 - [File Connector 設定の移行](#file_configs) - [ファイル接続設定の参照](#file_config_refs) - [インバウンドエンドポイントの移行](#file_listener) - [アウトバウンドエンドポイントの移行](#file_write) ## [](#file_configs)File Connector 設定の移行 Mule 3 では、すべてのトランスポート設定が ​``​ という最上位要素で行われますが、File Connector では自動削除、ストリーミング、接続の検証をデフォルトで ​`true`​ に設定します。 Mule 3 の例: デフォルトのファイル設定 ```xml ``` コネクタ設定にはまた、ファイルの読み取り、書き込み、移動など多数の設定があります。次の例は、File Connector で実行可能な Mule 3 の設定の大半を示しています。 Mule 3 の例: 実行可能なファイル接続設定 ```xml ``` Mule 4 では、​``​ がファイル接続設定の最上位要素で、​``​ は接続に関連する設定の子要素です。 Mule 4 の例 ```xml ``` - `workingDir`​ には、他のすべてのパスに使用するディレクトリへの相対パスを指定できます。指定されていない場合は、ユーザーのホームディレクトリが使用されます。Mule 3 に ​`workDirectory`​ とよく似た名前の属性がありますが、​`workDirectory`​ は入力ファイルを処理する前に移動する場合に使用するものです。 - `defaultWriteEncoding`​ は、書き込みで使用する文字エンコーディングを特定します。このグローバル設定は、Write などのファイル操作で上書きできます。 Mule 3 の他の設定パラメーターはすべて不要になりました。新しいコネクタの操作のパラメーターと置換されたか、新しいコネクタモデルでは表示する必要がないためです。 ## [](#file_config_refs)ファイル接続設定の参照 Mule 3 ではすべての操作が、​`connector-ref`​ を使用して File Connector の主要な設定をポイントする、インバウンドまたはアウトバウンドエンドポイントとして設定されます。 Mule 3 の例: インバウンドエンドポイントとしてのファイル接続 ```xml ``` Mule 3 の例: アウトバウンドエンドポイントとしてのファイル接続 ```xml ``` ## [](#file_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用してディレクトリをポーリングしてファイルを見つけていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ コンポーネント (Studio パレットでは ​`On New File`​ という) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - アプリケーションを起動する前にリスン ​`directory`​ を作成するか、再接続戦略を設定する必要があります。Mule 3.x では、アプリケーションの起動時にこのディレクトリが存在しなければ作成されていました。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - 3.x では、エラーが発生してトランザクションがロールバックされても、入力ファイルが削除または移動されることはありませんでしたが、トランザクションがない場合はこうした操作が実行されていました。Mule 4 では、トランザクションの有無に関係なく、エラーが生じると、削除または移動操作が行われません。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じて作成または変更タイムスタンプに基づいて自動的に絞り込むことができます。 - Mule 3 では読み込みファイルの正規パスを使用して、そのメタデータをメッセージのインバウンドプロパティに追加していました。Mule 4 では絶対パスを使用します。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#file_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 のコネクタは、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ コンポーネントは非同期です。つまり、実際の書き込みがバックグラウンドで行われると同時に、フローで次のメッセージプロセッサーが実行されていました。他方、​``​ 操作は同期で、この操作が終了するまで次のメッセージプロセッサーは実行されません。操作を非同期にする場合は、​``​ 操作を ​``​ ブロックでラップします。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作にはモードパラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` File Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-file-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector ドキュメント](https://docs.mulesoft.com/jp/file-connector/latest/) # File Connector の移行 ファイルトランスポートは一新されています。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 ## [](#whats_covered_here)このトピックの内容 - [File Connector 設定の移行](#file_configs) - [ファイル接続設定の参照](#file_config_refs) - [インバウンドエンドポイントの移行](#file_listener) - [アウトバウンドエンドポイントの移行](#file_write) ## [](#file_configs)File Connector 設定の移行 Mule 3 では、すべてのトランスポート設定が ​``​ という最上位要素で行われますが、File Connector では自動削除、ストリーミング、接続の検証をデフォルトで ​`true`​ に設定します。 Mule 3 の例: デフォルトのファイル設定 ```xml ``` コネクタ設定にはまた、ファイルの読み取り、書き込み、移動など多数の設定があります。次の例は、File Connector で実行可能な Mule 3 の設定の大半を示しています。 Mule 3 の例: 実行可能なファイル接続設定 ```xml ``` Mule 4 では、​``​ がファイル接続設定の最上位要素で、​``​ は接続に関連する設定の子要素です。 Mule 4 の例 ```xml ``` - `workingDir`​ には、他のすべてのパスに使用するディレクトリへの相対パスを指定できます。指定されていない場合は、ユーザーのホームディレクトリが使用されます。Mule 3 に ​`workDirectory`​ とよく似た名前の属性がありますが、​`workDirectory`​ は入力ファイルを処理する前に移動する場合に使用するものです。 - `defaultWriteEncoding`​ は、書き込みで使用する文字エンコーディングを特定します。このグローバル設定は、Write などのファイル操作で上書きできます。 Mule 3 の他の設定パラメーターはすべて不要になりました。新しいコネクタの操作のパラメーターと置換されたか、新しいコネクタモデルでは表示する必要がないためです。 ## [](#file_config_refs)ファイル接続設定の参照 Mule 3 ではすべての操作が、​`connector-ref`​ を使用して File Connector の主要な設定をポイントする、インバウンドまたはアウトバウンドエンドポイントとして設定されます。 Mule 3 の例: インバウンドエンドポイントとしてのファイル接続 ```xml ``` Mule 3 の例: アウトバウンドエンドポイントとしてのファイル接続 ```xml ``` ## [](#file_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用してディレクトリをポーリングしてファイルを見つけていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ コンポーネント (Studio パレットでは ​`On New File`​ という) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - アプリケーションを起動する前にリスン ​`directory`​ を作成するか、再接続戦略を設定する必要があります。Mule 3.x では、アプリケーションの起動時にこのディレクトリが存在しなければ作成されていました。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - 3.x では、エラーが発生してトランザクションがロールバックされても、入力ファイルが削除または移動されることはありませんでしたが、トランザクションがない場合はこうした操作が実行されていました。Mule 4 では、トランザクションの有無に関係なく、エラーが生じると、削除または移動操作が行われません。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じて作成または変更タイムスタンプに基づいて自動的に絞り込むことができます。 - Mule 3 では読み込みファイルの正規パスを使用して、そのメタデータをメッセージのインバウンドプロパティに追加していました。Mule 4 では絶対パスを使用します。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#file_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 のコネクタは、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ コンポーネントは非同期です。つまり、実際の書き込みがバックグラウンドで行われると同時に、フローで次のメッセージプロセッサーが実行されていました。他方、​``​ 操作は同期で、この操作が終了するまで次のメッセージプロセッサーは実行されません。操作を非同期にする場合は、​``​ 操作を ​``​ ブロックでラップします。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作にはモードパラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` File Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-file-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector ドキュメント](https://docs.mulesoft.com/jp/file-connector/latest/) # File Connector の移行 ファイルトランスポートは一新されています。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 ## [](#whats_covered_here)このトピックの内容 - [File Connector 設定の移行](#file_configs) - [ファイル接続設定の参照](#file_config_refs) - [インバウンドエンドポイントの移行](#file_listener) - [アウトバウンドエンドポイントの移行](#file_write) ## [](#file_configs)File Connector 設定の移行 Mule 3 では、すべてのトランスポート設定が ​``​ という最上位要素で行われますが、File Connector では自動削除、ストリーミング、接続の検証をデフォルトで ​`true`​ に設定します。 Mule 3 の例: デフォルトのファイル設定 ```xml ``` コネクタ設定にはまた、ファイルの読み取り、書き込み、移動など多数の設定があります。次の例は、File Connector で実行可能な Mule 3 の設定の大半を示しています。 Mule 3 の例: 実行可能なファイル接続設定 ```xml ``` Mule 4 では、​``​ がファイル接続設定の最上位要素で、​``​ は接続に関連する設定の子要素です。 Mule 4 の例 ```xml ``` - `workingDir`​ には、他のすべてのパスに使用するディレクトリへの相対パスを指定できます。指定されていない場合は、ユーザーのホームディレクトリが使用されます。Mule 3 に ​`workDirectory`​ とよく似た名前の属性がありますが、​`workDirectory`​ は入力ファイルを処理する前に移動する場合に使用するものです。 - `defaultWriteEncoding`​ は、書き込みで使用する文字エンコーディングを特定します。このグローバル設定は、Write などのファイル操作で上書きできます。 Mule 3 の他の設定パラメーターはすべて不要になりました。新しいコネクタの操作のパラメーターと置換されたか、新しいコネクタモデルでは表示する必要がないためです。 ## [](#file_config_refs)ファイル接続設定の参照 Mule 3 ではすべての操作が、​`connector-ref`​ を使用して File Connector の主要な設定をポイントする、インバウンドまたはアウトバウンドエンドポイントとして設定されます。 Mule 3 の例: インバウンドエンドポイントとしてのファイル接続 ```xml ``` Mule 3 の例: アウトバウンドエンドポイントとしてのファイル接続 ```xml ``` ## [](#file_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用してディレクトリをポーリングしてファイルを見つけていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ コンポーネント (Studio パレットでは ​`On New File`​ という) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - アプリケーションを起動する前にリスン ​`directory`​ を作成するか、再接続戦略を設定する必要があります。Mule 3.x では、アプリケーションの起動時にこのディレクトリが存在しなければ作成されていました。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - 3.x では、エラーが発生してトランザクションがロールバックされても、入力ファイルが削除または移動されることはありませんでしたが、トランザクションがない場合はこうした操作が実行されていました。Mule 4 では、トランザクションの有無に関係なく、エラーが生じると、削除または移動操作が行われません。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じて作成または変更タイムスタンプに基づいて自動的に絞り込むことができます。 - Mule 3 では読み込みファイルの正規パスを使用して、そのメタデータをメッセージのインバウンドプロパティに追加していました。Mule 4 では絶対パスを使用します。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#file_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 のコネクタは、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ コンポーネントは非同期です。つまり、実際の書き込みがバックグラウンドで行われると同時に、フローで次のメッセージプロセッサーが実行されていました。他方、​``​ 操作は同期で、この操作が終了するまで次のメッセージプロセッサーは実行されません。操作を非同期にする場合は、​``​ 操作を ​``​ ブロックでラップします。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作にはモードパラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` File Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-file-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector ドキュメント](https://docs.mulesoft.com/jp/file-connector/latest/) # File Connector の移行 ファイルトランスポートは一新されています。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 ## [](#whats_covered_here)このトピックの内容 - [File Connector 設定の移行](#file_configs) - [ファイル接続設定の参照](#file_config_refs) - [インバウンドエンドポイントの移行](#file_listener) - [アウトバウンドエンドポイントの移行](#file_write) ## [](#file_configs)File Connector 設定の移行 Mule 3 では、すべてのトランスポート設定が ​``​ という最上位要素で行われますが、File Connector では自動削除、ストリーミング、接続の検証をデフォルトで ​`true`​ に設定します。 Mule 3 の例: デフォルトのファイル設定 ```xml ``` コネクタ設定にはまた、ファイルの読み取り、書き込み、移動など多数の設定があります。次の例は、File Connector で実行可能な Mule 3 の設定の大半を示しています。 Mule 3 の例: 実行可能なファイル接続設定 ```xml ``` Mule 4 では、​``​ がファイル接続設定の最上位要素で、​``​ は接続に関連する設定の子要素です。 Mule 4 の例 ```xml ``` - `workingDir`​ には、他のすべてのパスに使用するディレクトリへの相対パスを指定できます。指定されていない場合は、ユーザーのホームディレクトリが使用されます。Mule 3 に ​`workDirectory`​ とよく似た名前の属性がありますが、​`workDirectory`​ は入力ファイルを処理する前に移動する場合に使用するものです。 - `defaultWriteEncoding`​ は、書き込みで使用する文字エンコーディングを特定します。このグローバル設定は、Write などのファイル操作で上書きできます。 Mule 3 の他の設定パラメーターはすべて不要になりました。新しいコネクタの操作のパラメーターと置換されたか、新しいコネクタモデルでは表示する必要がないためです。 ## [](#file_config_refs)ファイル接続設定の参照 Mule 3 ではすべての操作が、​`connector-ref`​ を使用して File Connector の主要な設定をポイントする、インバウンドまたはアウトバウンドエンドポイントとして設定されます。 Mule 3 の例: インバウンドエンドポイントとしてのファイル接続 ```xml ``` Mule 3 の例: アウトバウンドエンドポイントとしてのファイル接続 ```xml ``` ## [](#file_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用してディレクトリをポーリングしてファイルを見つけていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ コンポーネント (Studio パレットでは ​`On New File`​ という) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - アプリケーションを起動する前にリスン ​`directory`​ を作成するか、再接続戦略を設定する必要があります。Mule 3.x では、アプリケーションの起動時にこのディレクトリが存在しなければ作成されていました。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - 3.x では、エラーが発生してトランザクションがロールバックされても、入力ファイルが削除または移動されることはありませんでしたが、トランザクションがない場合はこうした操作が実行されていました。Mule 4 では、トランザクションの有無に関係なく、エラーが生じると、削除または移動操作が行われません。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じて作成または変更タイムスタンプに基づいて自動的に絞り込むことができます。 - Mule 3 では読み込みファイルの正規パスを使用して、そのメタデータをメッセージのインバウンドプロパティに追加していました。Mule 4 では絶対パスを使用します。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#file_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 Connector は、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ コンポーネントは非同期です。つまり、実際の書き込みがバックグラウンドで行われると同時に、フローで次のメッセージプロセッサーが実行されていました。他方、​``​ 操作は同期で、この操作が終了するまで次のメッセージプロセッサーは実行されません。操作を非同期にする場合は、​``​ 操作を ​``​ ブロックでラップします。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作にはモードパラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` File Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-file-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector ドキュメント](https://docs.mulesoft.com/jp/file-connector/latest/) # File Connector の移行 ファイルトランスポートは一新されています。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 ## [](#whats_covered_here)このトピックの内容 - [File Connector 設定の移行](#file_configs) - [ファイル接続設定の参照](#file_config_refs) - [インバウンドエンドポイントの移行](#file_listener) - [アウトバウンドエンドポイントの移行](#file_write) ## [](#file_configs)File Connector 設定の移行 Mule 3 では、すべてのトランスポート設定が ​``​ という最上位要素で行われますが、File Connector では自動削除、ストリーミング、接続の検証をデフォルトで ​`true`​ に設定します。 Mule 3 の例: デフォルトのファイル設定 ```xml ``` コネクタ設定にはまた、ファイルの読み取り、書き込み、移動など多数の設定があります。次の例は、File Connector で実行可能な Mule 3 の設定の大半を示しています。 Mule 3 の例: 実行可能なファイル接続設定 ```xml ``` Mule 4 では、​``​ がファイル接続設定の最上位要素で、​``​ は接続に関連する設定の子要素です。 Mule 4 の例 ```xml ``` - `workingDir`​ には、他のすべてのパスに使用するディレクトリへの相対パスを指定できます。指定されていない場合は、ユーザーのホームディレクトリが使用されます。Mule 3 に ​`workDirectory`​ とよく似た名前の属性がありますが、​`workDirectory`​ は入力ファイルを処理する前に移動する場合に使用するものです。 - `defaultWriteEncoding`​ は、書き込みで使用する文字エンコーディングを特定します。このグローバル設定は、Write などのファイル操作で上書きできます。 Mule 3 の他の設定パラメーターはすべて不要になりました。新しいコネクタの操作のパラメーターと置換されたか、新しいコネクタモデルでは表示する必要がないためです。 ## [](#file_config_refs)ファイル接続設定の参照 Mule 3 ではすべての操作が、​`connector-ref`​ を使用して File Connector の主要な設定をポイントする、インバウンドまたはアウトバウンドエンドポイントとして設定されます。 Mule 3 の例: インバウンドエンドポイントとしてのファイル接続 ```xml ``` Mule 3 の例: アウトバウンドエンドポイントとしてのファイル接続 ```xml ``` ## [](#file_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用してディレクトリをポーリングしてファイルを見つけていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ コンポーネント (Studio パレットでは ​`On New File`​ という) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - アプリケーションを起動する前にリスン ​`directory`​ を作成するか、再接続戦略を設定する必要があります。Mule 3.x では、アプリケーションの起動時にこのディレクトリが存在しなければ作成されていました。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - 3.x では、エラーが発生してトランザクションがロールバックされても、入力ファイルが削除または移動されることはありませんでしたが、トランザクションがない場合はこうした操作が実行されていました。Mule 4 では、トランザクションの有無に関係なく、エラーが生じると、削除または移動操作が行われません。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じて作成または変更タイムスタンプに基づいて自動的に絞り込むことができます。 - Mule 3 では読み込みファイルの正規パスを使用して、そのメタデータをメッセージのインバウンドプロパティに追加していました。Mule 4 では絶対パスを使用します。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#file_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 Connector は、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ コンポーネントは非同期です。つまり、実際の書き込みがバックグラウンドで行われると同時に、フローで次のメッセージプロセッサーが実行されていました。他方、​``​ 操作は同期で、この操作が終了するまで次のメッセージプロセッサーは実行されません。操作を非同期にする場合は、​``​ 操作を ​``​ ブロックでラップします。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作にはモードパラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` File Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-file-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector ドキュメント](https://docs.mulesoft.com/jp/file-connector/latest/) # File Connector の移行 ファイルトランスポートは一新されています。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 ## [](#whats_covered_here)このトピックの内容 - [File Connector 設定の移行](#file_configs) - [ファイル接続設定の参照](#file_config_refs) - [インバウンドエンドポイントの移行](#file_listener) - [アウトバウンドエンドポイントの移行](#file_write) ## [](#file_configs)File Connector 設定の移行 Mule 3 では、すべてのトランスポート設定が ​``​ という最上位要素で行われますが、File Connector では自動削除、ストリーミング、接続の検証をデフォルトで ​`true`​ に設定します。 Mule 3 の例: デフォルトのファイル設定 ```xml ``` コネクタ設定にはまた、ファイルの読み取り、書き込み、移動など多数の設定があります。次の例は、File Connector で実行可能な Mule 3 の設定の大半を示しています。 Mule 3 の例: 実行可能なファイル接続設定 ```xml ``` Mule 4 では、​``​ がファイル接続設定の最上位要素で、​``​ は接続に関連する設定の子要素です。 Mule 4 の例 ```xml ``` - `workingDir`​ には、他のすべてのパスに使用するディレクトリへの相対パスを指定できます。指定されていない場合は、ユーザーのホームディレクトリが使用されます。Mule 3 に ​`workDirectory`​ とよく似た名前の属性がありますが、​`workDirectory`​ は入力ファイルを処理する前に移動する場合に使用するものです。 - `defaultWriteEncoding`​ は、書き込みで使用する文字エンコーディングを特定します。このグローバル設定は、Write などのファイル操作で上書きできます。 Mule 3 の他の設定パラメーターはすべて不要になりました。新しいコネクタの操作のパラメーターと置換されたか、新しいコネクタモデルでは表示する必要がないためです。 ## [](#file_config_refs)ファイル接続設定の参照 Mule 3 ではすべての操作が、​`connector-ref`​ を使用して File Connector の主要な設定をポイントする、インバウンドまたはアウトバウンドエンドポイントとして設定されます。 Mule 3 の例: インバウンドエンドポイントとしてのファイル接続 ```xml ``` Mule 3 の例: アウトバウンドエンドポイントとしてのファイル接続 ```xml ``` ## [](#file_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用してディレクトリをポーリングしてファイルを見つけていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ コンポーネント (Studio パレットでは ​`On New File`​ という) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - アプリケーションを起動する前にリスン ​`directory`​ を作成するか、再接続戦略を設定する必要があります。Mule 3.x では、アプリケーションの起動時にこのディレクトリが存在しなければ作成されていました。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - 3.x では、エラーが発生してトランザクションがロールバックされても、入力ファイルが削除または移動されることはありませんでしたが、トランザクションがない場合はこうした操作が実行されていました。Mule 4 では、トランザクションの有無に関係なく、エラーが生じると、削除または移動操作が行われません。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じて作成または変更タイムスタンプに基づいて自動的に絞り込むことができます。 - Mule 3 では読み込みファイルの正規パスを使用して、そのメタデータをメッセージのインバウンドプロパティに追加していました。Mule 4 では絶対パスを使用します。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#file_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 Connector は、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ コンポーネントは非同期です。つまり、実際の書き込みがバックグラウンドで行われると同時に、フローで次のメッセージプロセッサーが実行されていました。他方、​``​ 操作は同期で、この操作が終了するまで次のメッセージプロセッサーは実行されません。操作を非同期にする場合は、​``​ 操作を ​``​ ブロックでラップします。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作にはモードパラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` File Connector を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-file-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector ドキュメント](https://docs.mulesoft.com/jp/file-connector/latest/) # FIPS 140-2 コンプライアンスサポート Mule 4 Runtime は、FIPS 140-2 認証済み環境で実行するように設定できます。これには、HTTP Connector などのすべての Runtime Connector を含みます。Mule は、デフォルトでは FIPS セキュリティモードで実行されません。2 つの要件があります。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule Runtime の設定が FIPS セキュリティモードで実行されるように調整されている。

Government Cloud はデフォルトで FIPS 140-2 向けに設定されています。そのため、Government Cloud を使用している場合は、次の手順を実行する必要はありません。

Runtime Fabric を使用している場合は、これらの手順を実行せずに​「Enabling FIPS 140-2 Compliance Mode for Runtime Fabric (Runtime Fabric での FIPS 140-2 コンプライアンスモードの有効化)」​を参照してください。
## [](#前提条件)前提条件 このドキュメントは、読者が [FIPS 140-2](http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。このドキュメントは、読者が [認証済みセキュリティプロバイダー](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​を選択、取得済みであることも前提としています。 ## [](#set_up_environment)FIPS 140-2 Java 環境のセットアップ Mule は、FIPS に準拠するセキュリティモジュールの提供を Java ランタイムに依存しています。そのため、最初の要件は、FIPS 140-2 Java 環境が適切にセットアップされていることです。FIPS に準拠するシステムを初めてセットアップしていて、認証済みセキュリティプロバイダーをまだ設定していない場合は、まず [認証済みセキュリティプロバイダーを選択して取得](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​してから、選択したプロバイダーに固有の手順に従って Java 環境をセットアップする必要があります。 このプロセスの詳細は、選択したセキュリティプロバイダーによって異なります。セキュリティプロバイダーのドキュメントを参照して手順を実行してください。 ### [](#例-bouncy-castle-セキュリティプロバイダーを使用したセットアップ手順)例: Bouncy Castle セキュリティプロバイダーを使用したセットアップ手順 次の例は、Bouncy Castle セキュリティプロバイダーをインストールして設定する方法を示しています。 1. [BouncyCastle の Web ページ](https://www.bouncycastle.org/fips-java/)​からプロバイダーファイルをダウンロードします。 2. 必要な JAR ファイルを ​`$JAVA_HOME/lib/ext`​ フォルダーにインストールします。 ![FIPS-install-jars](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/fips-install-jars.png) 3. セキュリティプロバイダーを、​`$JAVA_HOME/lib/security`​ フォルダーのセキュリティプロパティファイルに登録します。 1. `java.security`​ ファイルを開き、プロバイダーのクラス (​`org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider`​ など) をプロバイダーリストの最初の項目として追加します。 2. SSL プロバイダーの行を Bouncy Castle プロバイダーを使用するように変更します (​`security.provider.4=com.sun.net.ssl.internal.ssl.Provider BCFIPS`​)。 ![FIPS-register-jar](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/fips-register-jar.png) 4. 他のセキュリティプロバイダーの番号を調整して、番号が連続するようにします。 ![FIPS-register-jar-renumber](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/fips-register-jar-renumber.png) 5. 変更を保存します。 ## [](#fips-セキュリティモードでの-mule-の実行)FIPS セキュリティモードでの Mule の実行 [FIPS 140-2 Java 環境のセットアップ](#set_up_environment)​の手順に従った後に、Mule インスタンスが FIPS 140-2 準拠環境で動作するようにセットアップするために、Mule アプリケーションサーバーを起動するラッパーの設定を更新します。 1. `wrapper.conf`​ ファイルを開きます (​`$MULE_HOME/conf`​ フォルダー内)。 2. Mule が FIPS セキュリティモードで動作するように設定する行のコメントを解除します (図を参照)。​``​ を ​`wrapper.conf`​ ファイル内の連続する次の番号に置き換えます。 ![FIPS-wrapper-conf-edit](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/fips-wrapper-conf-edit.png) 3. 変更を保存します。 Mule がもう一度起動すると、起動時の表示に FIPS セキュリティモードが有効になっていることが示されます。 ![FIPS-startup](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/fips-startup.png) FIPS セキュリティモードが有効になると、Mule では自動的にプロトコルネゴシエーションが制限され、承認された暗号化スイートのサブセットのみが使用されます。すべての HTTPS Connector と TLS セキュリティレイヤーを使用するその他のコネクタは、自動的にこの制限の影響を受けます。 ### [](#fips-モードのクラスター環境)FIPS モードのクラスター環境 クラスター化された環境で Mule Runtime を使用して FIPS モードで実行している場合、クラスターの暗号化キーを定義する必要があります。詳細は、​[クラスターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-high-availability-ha-clusters#cluster_fips)​を参照してください。 ## [](#fips-140-2-準拠の暗号化スイート)FIPS 140-2 準拠の暗号化スイート 次のリストには、サポートされる FIPS 140-2 準拠の暗号化スイートが記載されています。 オンプレミス Mule インストールで使用される暗号化スイートを設定するには、​[SSL Connector の微調整](#fine-tuning-ssl-connectors)​を参照してください。 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_DHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA ## [](#ssl-connector-の微調整)SSL Connector の微調整 Mule conf フォルダーには、SSL Connector の設定を微調整するための 2 つのファイルがあります。これらのファイルでは、Mule が使用できる暗号化スイートと許可される SSL プロトコルを手動で設定できます。 - `tls-default.conf`​ (Mule が FIPS セキュリティモードで実行するように設定されていない場合に微調整できます) - `tls-fips140-2.conf`​ (Mule が FIPS セキュリティモードで実行されている場合に微調整できます) 該当するファイルを開き、リストの項目をコメントアウトまたはコメント解除して、使用できる暗号化スイートと SSL プロトコルを手動で設定します。これらのファイルを変更しない場合、Mule では、設定されたセキュリティマネージャーが暗号化スイートとプロトコルを選択することが許可されます。 ## [](#ヒントと制限事項)ヒントと制限事項 - Mule Runtime の配布にバンドルされている Bouncy Castle セキュリティプロバイダーは、FIPS 認証済みではありません。Mule が FIPS セキュリティモードを開始すると、Bouncy Castle プロバイダーは登録されず、使用されません。 - [Mule Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.3/securing#cryptography-module)​ と ​[Mule セキュアプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.3/secure-configuration-properties)​の設定オプションに含まれる一部の暗号化スキームと署名は FIPS に準拠していません。アプリケーションで FIPS 認証済みでないアルゴリズムを使用している場合は、実行時に次のようなエラーが表示されます。 Could not find encryption algorithm ''. (暗号化アルゴリズム「」が見つかりません。) You are running in FIPS mode, so please verify that the algorithm is compliant with FIPS. (FIPS モードで実行中です。アルゴリズムが FIPS に準拠していることを確認してください。) - 環境によってセキュリティ設定が異なり、暗号化スキームやアルゴリズムの選択も異なる可能性があることに注意してください。そのため、セットアップ方法に応じて、一部の環境でこのエラーが表示され、他の環境では表示されないことがあります。 ## [](#関連情報)関連情報 [Validated FIPS-2 Cryptographic Modules (検証済み FIPS-2 Cryptography Module)](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules) [Approved Cryptographic Algorithms (承認済み暗号化アルゴリズム)](http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf) # FIPS 140-2 コンプライアンスサポート Mule 4 Runtime は、FIPS 140-2 認証済み環境で実行するように設定できます。これには、HTTP Connector などのすべての Runtime Connector を含みます。Mule は、デフォルトでは FIPS セキュリティモードで実行されません。2 つの要件があります。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule Runtime の設定が FIPS セキュリティモードで実行されるように調整されている。

Government Cloud はデフォルトで FIPS 140-2 向けに設定されています。そのため、Government Cloud を使用している場合は、次の手順を実行する必要はありません。

Runtime Fabric を使用している場合は、これらの手順を実行せずに​「Enabling FIPS 140-2 Compliance Mode for Runtime Fabric (Runtime Fabric での FIPS 140-2 コンプライアンスモードの有効化)」​を参照してください。
## [](#前提条件)前提条件 このドキュメントは、読者が [FIPS 140-2](http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。このドキュメントは、読者が [認証済みセキュリティプロバイダー](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​を選択、取得済みであることも前提としています。 ## [](#set_up_environment)FIPS 140-2 Java 環境のセットアップ Mule は、FIPS に準拠するセキュリティモジュールの提供を Java ランタイムに依存しています。そのため、最初の要件は、FIPS 140-2 Java 環境が適切にセットアップされていることです。FIPS に準拠するシステムを初めてセットアップしていて、認証済みセキュリティプロバイダーをまだ設定していない場合は、まず [認証済みセキュリティプロバイダーを選択して取得](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​してから、選択したプロバイダーに固有の手順に従って Java 環境をセットアップする必要があります。 このプロセスの詳細は、選択したセキュリティプロバイダーによって異なります。セキュリティプロバイダーのドキュメントを参照して手順を実行してください。 ### [](#例-bouncy-castle-セキュリティプロバイダーを使用したセットアップ手順)例: Bouncy Castle セキュリティプロバイダーを使用したセットアップ手順 次の例は、Bouncy Castle セキュリティプロバイダーをインストールして設定する方法を示しています。 1. [BouncyCastle の Web ページ](https://www.bouncycastle.org/fips-java/)​からプロバイダーファイルをダウンロードします。 2. 必要な JAR ファイルを ​`$JAVA_HOME/lib/ext`​ フォルダーにインストールします。 ![FIPS-install-jars](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/fips-install-jars.png) 3. セキュリティプロバイダーを、​`$JAVA_HOME/lib/security`​ フォルダーのセキュリティプロパティファイルに登録します。 1. `java.security`​ ファイルを開き、プロバイダーのクラス (​`org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider`​ など) をプロバイダーリストの最初の項目として追加します。 2. SSL プロバイダーの行を Bouncy Castle プロバイダーを使用するように変更します (​`security.provider.4=com.sun.net.ssl.internal.ssl.Provider BCFIPS`​)。 ![FIPS-register-jar](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/fips-register-jar.png) 4. 他のセキュリティプロバイダーの番号を調整して、番号が連続するようにします。 ![FIPS-register-jar-renumber](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/fips-register-jar-renumber.png) 5. 変更を保存します。 ## [](#fips-セキュリティモードでの-mule-の実行)FIPS セキュリティモードでの Mule の実行 [FIPS 140-2 Java 環境のセットアップ](#set_up_environment)​の手順に従った後に、Mule インスタンスが FIPS 140-2 準拠環境で動作するようにセットアップするために、Mule アプリケーションサーバーを起動するラッパーの設定を更新します。 1. `wrapper.conf`​ ファイルを開きます (​`$MULE_HOME/conf`​ フォルダー内)。 2. Mule が FIPS セキュリティモードで動作するように設定する行のコメントを解除します (図を参照)。​``​ を ​`wrapper.conf`​ ファイル内の連続する次の番号に置き換えます。 ![FIPS-wrapper-conf-edit](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/fips-wrapper-conf-edit.png) 3. 変更を保存します。 Mule がもう一度起動すると、起動時の表示に FIPS セキュリティモードが有効になっていることが示されます。 ![FIPS-startup](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/fips-startup.png) FIPS セキュリティモードが有効になると、Mule では自動的にプロトコルネゴシエーションが制限され、承認された暗号化スイートのサブセットのみが使用されます。すべての HTTPS Connector と TLS セキュリティレイヤーを使用するその他のコネクタは、自動的にこの制限の影響を受けます。 ### [](#fips-モードのクラスター環境)FIPS モードのクラスター環境 クラスター化された環境で Mule Runtime を使用して FIPS モードで実行している場合、クラスターの暗号化キーを定義する必要があります。詳細は、​[クラスターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-high-availability-ha-clusters#cluster_fips)​を参照してください。 ## [](#fips-140-2-準拠の暗号化スイート)FIPS 140-2 準拠の暗号化スイート 次のリストには、サポートされる FIPS 140-2 準拠の暗号化スイートが記載されています。 オンプレミス Mule インストールで使用される暗号化スイートを設定するには、​[SSL Connector の微調整](#fine-tuning-ssl-connectors)​を参照してください。 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_DHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA ## [](#fips-140-2-準拠のキーストア形式)FIPS 140-2 準拠のキーストア形式 Mule アプリケーションのキーストアまたはトラストストアは、通常 ​`PKCS12`​ または ​`JKS`​ 形式になります。 これらの形式は FIPS に準拠していません。準拠するように、これらを ​`BCFKS`​ 形式に変換します。 `JKS`​ キーストアを ​`BCFKS`​ 形式に変換するには、以下を行っていることを確認します。 1. Java 8 以降を使用し、​`JAVA_HOME`​ が設定されていることを確認する。 2. [Bouncy Castle Web サイト](https://www.bouncycastle.org/download/bouncy-castle-java-fips/)​から ​`bc-fips.jar`​ ファイルをダウンロードする。 3. 次のサンプルコマンドを使用して、キーストアを ​`BCFKS`​ 形式に変換する。 BC\_FIPS\_JAR=${BC\_PATH}/bc-fips-\*.jar # Replace with a correct path OLD\_KEYSTORE="keystore.jks" # Replace with the keystore to convert OLD\_PASSWD="changeit" # Replace with the keystore password NEW\_KEYSTORE="keystore.bcfks" # Replace with the new keystore NEW\_PASSWD="changeit" # Replace with the new keystore password keytool -importkeystore \\ -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \\ -providerpath ${BC\_FIPS\_JAR} \\ -srckeystore ${OLD\_KEYSTORE} -srcstoretype JKS -srcstorepass ${OLD\_PASSWD} \\ -destkeystore ${NEW\_KEYSTORE} -deststoretype BCFKS -deststorepass ${NEW\_PASSWD}
Java 17 以降を使用している場合、​-J—​add-exports=java.base/sun.security.provider=ALL-UNNAMED​ パラメーターを keytool コマンドの ​-importkeystore​ パラメーターの前に追加します。
1. 新しいキーストアまたはトラストストアを使用するには、Mule 設定ファイルで ​[TLS 設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/tls-configuration)​を更新します。
ソースキーストアが ​PKCS12​ の場合、​keytool​ コマンドでパラメーター ​-srcstoretype​ を ​PKCS12​ に設定します。
## [](#ssl-connector-の微調整)SSL Connector の微調整 Mule conf フォルダーには、SSL Connector の設定を微調整するための 2 つのファイルがあります。これらのファイルでは、Mule が使用できる暗号化スイートと許可される SSL プロトコルを手動で設定できます。 - `tls-default.conf`​ (Mule が FIPS セキュリティモードで実行するように設定されていない場合に微調整できます) - `tls-fips140-2.conf`​ (Mule が FIPS セキュリティモードで実行されている場合に微調整できます) 該当するファイルを開き、リストの項目をコメントアウトまたはコメント解除して、使用できる暗号化スイートと SSL プロトコルを手動で設定します。これらのファイルを変更しない場合、Mule では、設定されたセキュリティマネージャーが暗号化スイートとプロトコルを選択することが許可されます。 ## [](#ヒントと制限事項)ヒントと制限事項 - Mule Runtime ディストリビューションにバンドルされている Bouncy Castle セキュリティプロバイダーは、FIPS 認証済みではありません。Mule が FIPS セキュリティモードを開始すると、Bouncy Castle プロバイダーは登録されず、使用されません。 - [Mule Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.4/securing#cryptography-module)​ と ​[Mule セキュアプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.4/secure-configuration-properties)​の設定オプションに含まれる一部の暗号化スキームと署名は FIPS に準拠していません。アプリケーションで FIPS 認証済みでないアルゴリズムを使用している場合は、実行時に次のようなエラーが表示されます。 Could not find encryption algorithm ''. (暗号化アルゴリズム「」が見つかりません。) You are running in FIPS mode, so please verify that the algorithm is compliant with FIPS. (FIPS モードで実行中です。アルゴリズムが FIPS に準拠していることを確認してください。) - 環境によってセキュリティ設定が異なり、暗号化スキームやアルゴリズムの選択も異なる可能性があることに注意してください。そのため、セットアップ方法に応じて、一部の環境でこのエラーが表示され、他の環境では表示されないことがあります。 - 同様に、Red Hat などの OS レベルで FIPS を有効にすると、ライセンス検証時に暗号化スイートエラーが発生するため、この操作はサポートされていません。 ## [](#関連情報)関連情報 - [Validated FIPS-2 Cryptographic Modules (検証済み FIPS-2 Cryptography Module)](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules) - [Approved Cryptographic Algorithms (承認済み暗号化アルゴリズム)](http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf) # FIPS 140-2 コンプライアンスサポート Mule 4 Runtime は、FIPS 140-2 認証済み環境で実行するように設定できます。これには、HTTP Connector などのすべての Runtime Connector を含みます。Mule は、デフォルトでは FIPS セキュリティモードで実行されません。2 つの要件があります。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule Runtime の設定が FIPS セキュリティモードで実行されるように調整されている。

Government Cloud はデフォルトで FIPS 140-2 向けに設定されています。そのため、Government Cloud を使用している場合は、次の手順を実行する必要はありません。

Runtime Fabric を使用している場合は、これらの手順を実行せずに​「Enabling FIPS 140-2 Compliance Mode for Runtime Fabric (Runtime Fabric での FIPS 140-2 コンプライアンスモードの有効化)」​を参照してください。
## [](#前提条件)前提条件 このドキュメントは、読者が [FIPS 140-2](http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。このドキュメントは、読者が [認証済みセキュリティプロバイダー](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​を選択、取得済みであることも前提としています。 ## [](#set_up_environment)FIPS 140-2 Java 環境のセットアップ Mule は、FIPS に準拠するセキュリティモジュールの提供を Java ランタイムに依存しています。そのため、最初の要件は、FIPS 140-2 Java 環境が適切にセットアップされていることです。FIPS に準拠するシステムを初めてセットアップしていて、認証済みセキュリティプロバイダーをまだ設定していない場合は、まず [認証済みセキュリティプロバイダーを選択して取得](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​してから、選択したプロバイダーに固有の手順に従って Java 環境をセットアップする必要があります。 このプロセスの詳細は、選択したセキュリティプロバイダーによって異なります。セキュリティプロバイダーのドキュメントを参照して手順を実行してください。 ### [](#例-bouncy-castle-セキュリティプロバイダーを使用したセットアップ手順)例: Bouncy Castle セキュリティプロバイダーを使用したセットアップ手順 次の例は、Bouncy Castle セキュリティプロバイダーをインストールして設定する方法を示しています。 1. [BouncyCastle の Web ページ](https://www.bouncycastle.org/fips-java/)​からプロバイダーファイルをダウンロードします。 2. 必要な JAR ファイルを ​`$JAVA_HOME/lib/ext`​ フォルダーにインストールします。 ![FIPS-install-jars](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/fips-install-jars.png) 3. セキュリティプロバイダーを、​`$JAVA_HOME/lib/security`​ フォルダーのセキュリティプロパティファイルに登録します。 1. `java.security`​ ファイルを開き、プロバイダーのクラス (​`org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider`​ など) をプロバイダーリストの最初の項目として追加します。 2. SSL プロバイダーの行を Bouncy Castle プロバイダーを使用するように変更します (​`security.provider.4=com.sun.net.ssl.internal.ssl.Provider BCFIPS`​)。 ![FIPS-register-jar](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/fips-register-jar.png) 4. 他のセキュリティプロバイダーの番号を調整して、番号が連続するようにします。 ![FIPS-register-jar-renumber](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/fips-register-jar-renumber.png) 5. 変更を保存します。 ## [](#fips-セキュリティモードでの-mule-の実行)FIPS セキュリティモードでの Mule の実行 [FIPS 140-2 Java 環境のセットアップ](#set_up_environment)​の手順に従った後に、Mule インスタンスが FIPS 140-2 準拠環境で動作するようにセットアップするために、Mule アプリケーションサーバーを起動するラッパーの設定を更新します。 1. `wrapper.conf`​ ファイルを開きます (​`$MULE_HOME/conf`​ フォルダー内)。 2. Mule が FIPS セキュリティモードで動作するように設定する行のコメントを解除します (図を参照)。​``​ を ​`wrapper.conf`​ ファイル内の連続する次の番号に置き換えます。 ![FIPS-wrapper-conf-edit](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/fips-wrapper-conf-edit.png) 3. 変更を保存します。 Mule がもう一度起動すると、起動時の表示に FIPS セキュリティモードが有効になっていることが示されます。 ![FIPS-startup](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/fips-startup.png) FIPS セキュリティモードが有効になると、Mule では自動的にプロトコルネゴシエーションが制限され、承認された暗号化スイートのサブセットのみが使用されます。すべての HTTPS Connector と TLS セキュリティレイヤーを使用するその他のコネクタは、自動的にこの制限の影響を受けます。 ### [](#fips-モードのクラスター環境)FIPS モードのクラスター環境 クラスター化された環境で Mule Runtime を使用して FIPS モードで実行している場合、クラスターの暗号化キーを定義する必要があります。詳細は、​[クラスターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-high-availability-ha-clusters#cluster_fips)​を参照してください。 ## [](#fips-140-2-準拠の暗号化スイート)FIPS 140-2 準拠の暗号化スイート 次のリストには、サポートされる FIPS 140-2 準拠の暗号化スイートが記載されています。 オンプレミス Mule インストールで使用される暗号化スイートを設定するには、​[SSL Connector の微調整](#fine-tuning-ssl-connectors)​を参照してください。 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_DHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA ## [](#ssl-connector-の微調整)SSL Connector の微調整 Mule conf フォルダーには、SSL Connector の設定を微調整するための 2 つのファイルがあります。これらのファイルでは、Mule が使用できる暗号化スイートと許可される SSL プロトコルを手動で設定できます。 - `tls-default.conf`​ (Mule が FIPS セキュリティモードで実行するように設定されていない場合に微調整できます) - `tls-fips140-2.conf`​ (Mule が FIPS セキュリティモードで実行されている場合に微調整できます) 該当するファイルを開き、リストの項目をコメントアウトまたはコメント解除して、使用できる暗号化スイートと SSL プロトコルを手動で設定します。これらのファイルを変更しない場合、Mule では、設定されたセキュリティマネージャーが暗号化スイートとプロトコルを選択することが許可されます。 ## [](#ヒントと制限事項)ヒントと制限事項 - Mule Runtime ディストリビューションにバンドルされている Bouncy Castle セキュリティプロバイダーは、FIPS 認証済みではありません。Mule が FIPS セキュリティモードを開始すると、Bouncy Castle プロバイダーは登録されず、使用されません。 - [Mule Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.5/securing#cryptography-module)​ と ​[Mule セキュアプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.5/secure-configuration-properties)​の設定オプションに含まれる一部の暗号化スキームと署名は FIPS に準拠していません。アプリケーションで FIPS 認証済みでないアルゴリズムを使用している場合は、実行時に次のようなエラーが表示されます。 Could not find encryption algorithm ''. (暗号化アルゴリズム「」が見つかりません。) You are running in FIPS mode, so please verify that the algorithm is compliant with FIPS. (FIPS モードで実行中です。アルゴリズムが FIPS に準拠していることを確認してください。) - 環境によってセキュリティ設定が異なり、暗号化スキームやアルゴリズムの選択も異なる可能性があることに注意してください。そのため、セットアップ方法に応じて、一部の環境でこのエラーが表示され、他の環境では表示されないことがあります。 - 同様に、Red Hat などの OS レベルで FIPS を有効にすると、ライセンス検証時に暗号化スイートエラーが発生するため、この操作はサポートされていません。 ## [](#関連情報)関連情報 - [Validated FIPS-2 Cryptographic Modules (検証済み FIPS-2 Cryptography Module)](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules) - [Approved Cryptographic Algorithms (承認済み暗号化アルゴリズム)](http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf) # FIPS 140-2 コンプライアンスサポート Mule 4 Runtime は、Federal Information Processing Standard (FIPS) 140-2 認証済み環境で実行するように設定できます。これには、HTTP Connector などのすべての Runtime Connector を含みます。Mule は、デフォルトでは FIPS セキュリティモードで実行されません。2 つの要件があります。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule Runtime の設定が FIPS セキュリティモードで実行されるように調整されている。

Government Cloud はデフォルトで FIPS 140-2 向けに設定されています。そのため、Government Cloud を使用している場合は、次の手順を実行する必要はありません。

Runtime Fabric を使用している場合は、これらの手順を実行せずに​「Enabling FIPS 140-2 Compliance Mode for Runtime Fabric (Runtime Fabric での FIPS 140-2 コンプライアンスモードの有効化)」​を参照してください。
## [](#前提条件)前提条件 このドキュメントは、読者が [FIPS 140-2](http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。このドキュメントは、読者が [認証済みセキュリティプロバイダー](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​を選択、取得済みであることも前提としています。 ## [](#set_up_environment)FIPS 140-2 Java 環境のセットアップ Mule は、FIPS に準拠するセキュリティモジュールの提供を Java ランタイムに依存しています。そのため、最初の要件は、FIPS 140-2 Java 環境が適切にセットアップされていることです。FIPS に準拠するシステムを初めてセットアップしていて、認証済みセキュリティプロバイダーをまだ設定していない場合は、まず [認証済みセキュリティプロバイダーを選択して取得](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​してから、選択したプロバイダーに固有の手順に従って Java 環境をセットアップする必要があります。 このプロセスの詳細は、選択したセキュリティプロバイダーによって異なります。セキュリティプロバイダーのドキュメントを参照して手順を実行してください。 ### [](#bouncy-castle-セキュリティプロバイダーを使用したセットアップ手順)Bouncy Castle セキュリティプロバイダーを使用したセットアップ手順 次の手順は、FIPS 140-2 Java 環境をセットアップする方法を示しています。 - [Java 8 でのセットアップ手順](#setupjava8) - [Java 11 以降でのセットアップ手順](#setupjava11) #### [](#setupjava8)Java 8 でのセットアップ手順 Java 8 で Bouncy Castle セキュリティプロバイダーをインストールして設定する手順は次のとおりです。 1. [BouncyCastle の Web ページ](https://www.bouncycastle.org/fips-java/)​からプロバイダーファイルをダウンロードします。 2. 必要な JAR ファイルを ​`$JAVA_HOME/lib/ext`​ フォルダーにインストールします。 ![FIPS-install-jars](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/fips-install-jars.png) 3. セキュリティプロバイダーを、​`$JAVA_HOME/lib/security`​ フォルダーのセキュリティプロパティファイルに登録します。 1. `java.security`​ ファイルを開き、プロバイダーのクラス (​`org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider`​ など) をプロバイダーリストの最初の項目として追加します。 2. SSL プロバイダーの行を Bouncy Castle プロバイダーを使用するように変更します (​`security.provider.4=com.sun.net.ssl.internal.ssl.Provider BCFIPS`​)。 ![FIPS-register-jar](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/fips-register-jar.png) 4. 他のセキュリティプロバイダーの番号を調整して、番号が連続するようにします。 ![FIPS-register-jar-renumber](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/fips-register-jar-renumber.png) 5. 変更を保存します。 #### [](#setupjava11)Java 11 以降でのセットアップ手順 Java 11 以降で Bouncy Castle セキュリティプロバイダーをインストールして設定する手順は次のとおりです。 1. Java 11 以降を使用していて、​`JAVA_HOME`​ が設定されていることを確認します。 2. [BouncyCastle の Web ページ](https://www.bouncycastle.org/fips-java/)​からプロバイダーファイルをダウンロードします。 Provider:bc-fips-1.0.2.4 TLS: bctls-fips-1.0.17.jar PKIX: bcpkix-fips-1.0.7.jar 3. ダウンロードした 3 つのファイルを Mule Runtime の ​`/lib/boot`​ フォルダー (Mule Runtime 用に必要) と ​`/mule-agent-plugin/lib`​ フォルダー (Mule エージェント用に必要) にコピーします。 4. `amc_setup`​ を実行し、Mule Runtime を登録します。たとえば、​**\[Add Server (サーバーを追加)\]**​ には登録トークン ​`/amc_setup -H d32c4bde-7184-444a-bd87-7a274623e14f---704247 node10 --fips`​ が表示されます。ここで ​`d32c4bde-7184-444a-bd87-7a274623e14f---704247`​ は Anypoint Runtime Manager からのキーです。 5. FIPS を有効にするには、​`$MULE_HOME/conf/wrapper.conf`​ を更新します。プロパティ ​`wrapper.java.additional.=-Dmule.security.model=fips140-2`​ と ​`wrapper.java.additional.=-Dmule.cluster.network.encryption.key={someKey}`​ を追加します。ここで、​`someKey`​ はクラスターからのキーで、クラスター環境を使用する場合には定義する必要があります。 6. 最新の Mule Runtime ディストリビューション ​`4.5.x`​ を取得すると、プロバイダー ​`BouncyCastleFipsProvider`​ と ​`BouncyCastleJsseProvider`​ が有効になります。次に、アルゴリズムを PKIX に設定します。 7. Mule Runtime を起動します。 ## [](#fips-セキュリティモードでの-mule-の実行)FIPS セキュリティモードでの Mule の実行 [FIPS 140-2 Java 環境のセットアップ](#set_up_environment)​の手順に従った後に、Mule インスタンスが FIPS 140-2 準拠環境で動作するようにセットアップするために、Mule アプリケーションサーバーを起動するラッパーの設定を更新します。 1. `wrapper.conf`​ ファイルを開きます (​`$MULE_HOME/conf`​ フォルダー内)。 2. Mule が FIPS セキュリティモードで動作するように設定する行のコメントを解除します (図を参照)。​``​ を ​`wrapper.conf`​ ファイル内の連続する次の番号に置き換えます。 ![FIPS-wrapper-conf-edit](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/fips-wrapper-conf-edit.png) 3. 変更を保存します。 Mule がもう一度起動すると、起動時の表示に FIPS セキュリティモードが有効になっていることが示されます。 ![FIPS-startup](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/fips-startup.png) FIPS セキュリティモードが有効になると、Mule では自動的にプロトコルネゴシエーションが制限され、承認された暗号化スイートのサブセットのみが使用されます。すべての HTTPS Connector と TLS セキュリティレイヤーを使用するその他のコネクタは、自動的にこの制限の影響を受けます。 ### [](#fips-モードのクラスター環境)FIPS モードのクラスター環境 クラスター化された環境で Mule Runtime を使用して FIPS モードで実行している場合、クラスターの暗号化キーを定義する必要があります。詳細は、​[クラスターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-high-availability-ha-clusters#cluster_fips)​を参照してください。 ## [](#fips-140-2-準拠の暗号化スイート)FIPS 140-2 準拠の暗号化スイート 次のリストには、サポートされる FIPS 140-2 準拠の暗号化スイートが記載されています。 オンプレミス Mule インストールで使用される暗号化スイートを設定するには、​[SSL Connector の微調整](#fine-tuning-ssl-connectors)​を参照してください。 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_DHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA ## [](#fips-140-2-準拠のキーストア形式)FIPS 140-2 準拠のキーストア形式 Mule アプリケーションのキーストアまたはトラストストアは、通常 ​`PKCS12`​ または ​`JKS`​ 形式になります。 これらの形式は FIPS に準拠していません。準拠するように、これらを ​`BCFKS`​ 形式に変換します。 `JKS`​ キーストアを ​`BCFKS`​ 形式に変換するには、以下を行っていることを確認します。 1. Java 8 以降を使用し、​`JAVA_HOME`​ が設定されていることを確認する。 2. [Bouncy Castle Web サイト](https://www.bouncycastle.org/download/bouncy-castle-java-fips/)​から ​`bc-fips.jar`​ ファイルをダウンロードする。 3. 次のサンプルコマンドを使用して、キーストアを ​`BCFKS`​ 形式に変換する。 BC\_FIPS\_JAR=${BC\_PATH}/bc-fips-\*.jar # Replace with a correct path OLD\_KEYSTORE="keystore.jks" # Replace with the keystore to convert OLD\_PASSWD="changeit" # Replace with the keystore password NEW\_KEYSTORE="keystore.bcfks" # Replace with the new keystore NEW\_PASSWD="changeit" # Replace with the new keystore password keytool -importkeystore \\ -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \\ -providerpath ${BC\_FIPS\_JAR} \\ -srckeystore ${OLD\_KEYSTORE} -srcstoretype JKS -srcstorepass ${OLD\_PASSWD} \\ -destkeystore ${NEW\_KEYSTORE} -deststoretype BCFKS -deststorepass ${NEW\_PASSWD}
Java 17 以降を使用している場合、​-J—​add-exports=java.base/sun.security.provider=ALL-UNNAMED​ パラメーターを keytool コマンドの ​-importkeystore​ パラメーターの前に追加します。
1. 新しいキーストアまたはトラストストアを使用するには、Mule 設定ファイルで ​[TLS 設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/tls-configuration)​を更新します。
ソースキーストアが ​PKCS12​ の場合、​keytool​ コマンドでパラメーター ​-srcstoretype​ を ​PKCS12​ に設定します。
## [](#ssl-connector-の微調整)SSL Connector の微調整 Mule conf フォルダーには、SSL Connector の設定を微調整するための 2 つのファイルがあります。これらのファイルでは、Mule が使用できる暗号化スイートと許可される SSL プロトコルを手動で設定できます。 - `tls-default.conf`​ (Mule が FIPS セキュリティモードで実行するように設定されていない場合に微調整できます) - `tls-fips140-2.conf`​ (Mule が FIPS セキュリティモードで実行されている場合に微調整できます) 該当するファイルを開き、リストの項目をコメントアウトまたはコメント解除して、使用できる暗号化スイートと SSL プロトコルを手動で設定します。これらのファイルを変更しない場合、Mule では、設定されたセキュリティマネージャーが暗号化スイートとプロトコルを選択することが許可されます。 ## [](#ヒントと制限事項)ヒントと制限事項 - Mule Runtime ディストリビューションにバンドルされている Bouncy Castle セキュリティプロバイダーは、FIPS 認証済みではありません。Mule が FIPS セキュリティモードを開始すると、Bouncy Castle プロバイダーは登録されず、使用されません。 - [Mule Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.6/securing#cryptography-module)​ と ​[Mule セキュアプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.6/secure-configuration-properties)​の設定オプションに含まれる一部の暗号化スキームと署名は FIPS に準拠していません。アプリケーションで FIPS 認証済みでないアルゴリズムを使用している場合は、実行時に次のようなエラーが表示されます。 Could not find encryption algorithm ''. (暗号化アルゴリズム「」が見つかりません。) You are running in FIPS mode, so please verify that the algorithm is compliant with FIPS. (FIPS モードで実行中です。アルゴリズムが FIPS に準拠していることを確認してください。) - 環境によってセキュリティ設定が異なり、暗号化スキームやアルゴリズムの選択も異なる可能性があることに注意してください。そのため、セットアップ方法に応じて、一部の環境でこのエラーが表示され、他の環境では表示されないことがあります。 - 同様に、Red Hat などの OS レベルで FIPS を有効にすると、ライセンス検証時に暗号化スイートエラーが発生するため、この操作はサポートされていません。 ## [](#関連情報)関連情報 - [Validated FIPS-2 Cryptographic Modules (検証済み FIPS-2 Cryptography Module)](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules) - [Approved Cryptographic Algorithms (承認済み暗号化アルゴリズム)](http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf) # FIPS 140-2 コンプライアンスサポート Mule 4 Runtime は、Federal Information Processing Standard (FIPS) 140-2 認証済み環境で実行するように設定できます。これには、HTTP Connector などのすべての Runtime Connector を含みます。Mule は、デフォルトでは FIPS セキュリティモードで実行されません。2 つの要件があります。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule Runtime の設定が FIPS セキュリティモードで実行されるように調整されている。

Government Cloud はデフォルトで FIPS 140-2 向けに設定されています。そのため、Government Cloud を使用している場合は、次の手順を実行する必要はありません。

Runtime Fabric を使用している場合は、これらの手順を実行せずに​「Enabling FIPS 140-2 Compliance Mode for Runtime Fabric (Runtime Fabric での FIPS 140-2 コンプライアンスモードの有効化)」​を参照してください。
## [](#前提条件)前提条件 このドキュメントは、読者が [FIPS 140-2](http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。このドキュメントは、読者が [認証済みセキュリティプロバイダー](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​を選択、取得済みであることも前提としています。 ## [](#set_up_environment)FIPS 140-2 Java 環境のセットアップ Mule は、FIPS に準拠するセキュリティモジュールの提供を Java ランタイムに依存しています。そのため、最初の要件は、FIPS 140-2 Java 環境が適切にセットアップされていることです。FIPS に準拠するシステムを初めてセットアップしていて、認証済みセキュリティプロバイダーをまだ設定していない場合は、まず [認証済みセキュリティプロバイダーを選択して取得](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​してから、選択したプロバイダーに固有の手順に従って Java 環境をセットアップする必要があります。 このプロセスの詳細は、選択したセキュリティプロバイダーによって異なります。セキュリティプロバイダーのドキュメントを参照して手順を実行してください。 ### [](#bouncy-castle-セキュリティプロバイダーを使用したセットアップ手順)Bouncy Castle セキュリティプロバイダーを使用したセットアップ手順 次の手順は、FIPS 140-2 Java 環境をセットアップする方法を示しています。 - [Java 8 でのセットアップ手順](#setupjava8) - [Java 11 以降でのセットアップ手順](#setupjava11) #### [](#setupjava8)Java 8 でのセットアップ手順 Java 8 で Bouncy Castle セキュリティプロバイダーをインストールして設定する手順は次のとおりです。 1. [BouncyCastle の Web ページ](https://www.bouncycastle.org/fips-java/)​からプロバイダーファイルをダウンロードします。 2. 必要な JAR ファイルを ​`$JAVA_HOME/lib/ext`​ フォルダーにインストールします。 ![FIPS JAR ファイルを Java ホームディレクトリにインストールするコマンドライン](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/fips-install-jars.png) 3. セキュリティプロバイダーを、​`$JAVA_HOME/lib/security`​ フォルダーのセキュリティプロパティファイルに登録します。 1. `java.security`​ ファイルを開き、プロバイダーのクラス (​`org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider`​ など) をプロバイダーリストの最初の項目として追加します。 2. SSL プロバイダーの行を Bouncy Castle プロバイダーを使用するように変更します (​`security.provider.4=com.sun.net.ssl.internal.ssl.Provider BCFIPS`​)。 ![プロバイダーを変更するセキュリティプロバイダーのリスト](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/fips-register-jar.png) 4. 他のセキュリティプロバイダーの番号を調整して、番号が連続するようにします。 ![セキュリティプロバイダーが順番に表示されているリスト](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/fips-register-jar-renumber.png) 5. 変更を保存します。 #### [](#setupjava11)Java 11 以降でのセットアップ手順 Java 11 以降で Bouncy Castle セキュリティプロバイダーをインストールして設定する手順は次のとおりです。 1. Java 11 以降を使用していて、​`JAVA_HOME`​ が設定されていることを確認します。 2. [BouncyCastle の Web ページ](https://www.bouncycastle.org/fips-java/)​からプロバイダーファイルをダウンロードします。 Provider:bc-fips-1.0.2.4 TLS: bctls-fips-1.0.17.jar PKIX: bcpkix-fips-1.0.7.jar 3. ダウンロードした 3 つのファイルを Mule Runtime の ​`/lib/boot`​ フォルダー (Mule Runtime 用に必要) と ​`/mule-agent-plugin/lib`​ フォルダー (Mule エージェント用に必要) にコピーします。 4. `amc_setup`​ を実行し、Mule Runtime を登録します。たとえば、​**\[Add Server (サーバーを追加)\]**​ には登録トークン ​`/amc_setup -H d32c4bde-7184-444a-bd87-7a274623e14f---704247 node10 --fips`​ が表示されます。ここで ​`d32c4bde-7184-444a-bd87-7a274623e14f---704247`​ は Anypoint Runtime Manager からのキーです。 5. FIPS を有効にするには、​`$MULE_HOME/conf/wrapper.conf`​ を更新します。プロパティ ​`wrapper.java.additional.=-Dmule.security.model=fips140-2`​ と ​`wrapper.java.additional.=-Dmule.cluster.network.encryption.key={someKey}`​ を追加します。ここで、​`someKey`​ はクラスターからのキーで、クラスター環境を使用する場合には定義する必要があります。 6. 最新の Mule Runtime ディストリビューション ​`4.5.x`​ を取得すると、プロバイダー ​`BouncyCastleFipsProvider`​ と ​`BouncyCastleJsseProvider`​ が有効になります。次に、アルゴリズムを PKIX に設定します。 7. Mule Runtime を起動します。 ## [](#fips-セキュリティモードでの-mule-の実行)FIPS セキュリティモードでの Mule の実行 [FIPS 140-2 Java 環境のセットアップ](#set_up_environment)​の手順に従った後に、Mule インスタンスが FIPS 140-2 準拠環境で動作するようにセットアップするために、Mule アプリケーションサーバーを起動するラッパーの設定を更新します。 1. `wrapper.conf`​ ファイルを開きます (​`$MULE_HOME/conf`​ フォルダー内)。 2. Mule が FIPS セキュリティモードで動作するように設定する行のコメントを解除します (図を参照)。​``​ を ​`wrapper.conf`​ ファイル内の連続する次の番号に置き換えます。 ![FIPS 140-2 モードを有効にする設定が含まれるファイル](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/fips-wrapper-conf-edit.png) 3. 変更を保存します。 Mule がもう一度起動すると、起動時の表示に FIPS セキュリティモードが有効になっていることが示されます。 ![FIPS 140-2 セキュリティモデルが有効になっている Mule サーバーの起動ログが表示されているコンソール出力](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/fips-startup.png) FIPS セキュリティモードが有効になると、Mule では自動的にプロトコルネゴシエーションが制限され、承認された暗号化スイートのサブセットのみが使用されます。すべての HTTPS Connector と TLS セキュリティレイヤーを使用するその他のコネクタは、自動的にこの制限の影響を受けます。 ### [](#fips-モードのクラスター環境)FIPS モードのクラスター環境 クラスタリングされた環境で Mule Runtime を使用して FIPS モードで実行している場合、クラスターの暗号化キーを定義する必要があります。詳細は、​[クラスターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-high-availability-ha-clusters#cluster_fips)​を参照してください。 ## [](#fips-140-2-準拠の暗号化スイート)FIPS 140-2 準拠の暗号化スイート 次のリストには、サポートされる FIPS 140-2 準拠の暗号化スイートが記載されています。 オンプレミス Mule インストールで使用される暗号化スイートを設定するには、​[SSL Connector の微調整](#fine-tuning-ssl-connectors)​を参照してください。 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_DHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA ## [](#ssl-connector-の微調整)SSL Connector の微調整 Mule conf フォルダーには、SSL Connector の設定を微調整するための 2 つのファイルがあります。これらのファイルでは、Mule が使用できる暗号化スイートと許可される SSL プロトコルを手動で設定できます。 - `tls-default.conf`​ (Mule が FIPS セキュリティモードで実行するように設定されていない場合に微調整できます) - `tls-fips140-2.conf`​ (Mule が FIPS セキュリティモードで実行されている場合に微調整できます) 該当するファイルを開き、リストの項目をコメントアウトまたはコメント解除して、使用できる暗号化スイートと SSL プロトコルを手動で設定します。これらのファイルを変更しない場合、Mule では、設定されたセキュリティマネージャーが暗号化スイートとプロトコルを選択することが許可されます。 ## [](#ヒントと制限事項)ヒントと制限事項 - Mule Runtime ディストリビューションにバンドルされている Bouncy Castle セキュリティプロバイダーは、FIPS 認証済みではありません。Mule が FIPS セキュリティモードを開始すると、Bouncy Castle プロバイダーは登録されず、使用されません。 - [Mule Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.7/securing#cryptography-module)​ と ​[Mule セキュアプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.7/secure-configuration-properties)​の設定オプションに含まれる一部の暗号化スキームと署名は FIPS に準拠していません。アプリケーションで FIPS 認証済みでないアルゴリズムを使用している場合は、実行時に次のようなエラーが表示されます。 Could not find encryption algorithm ''. (暗号化アルゴリズム「」が見つかりません。) You are running in FIPS mode, so please verify that the algorithm is compliant with FIPS. (FIPS モードで実行中です。アルゴリズムが FIPS に準拠していることを確認してください。) - 環境によってセキュリティ設定が異なり、暗号化スキームやアルゴリズムの選択も異なる可能性があることに注意してください。そのため、セットアップ方法に応じて、一部の環境でこのエラーが表示され、他の環境では表示されないことがあります。 - 同様に、Red Hat などの OS レベルで FIPS を有効にすると、ライセンス検証時に暗号化スイートエラーが発生するため、この操作はサポートされていません。 ## [](#関連情報)関連情報 - [Validated FIPS-2 Cryptographic Modules (検証済み FIPS-2 Cryptography Module)](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules) - [Approved Cryptographic Algorithms (承認済み暗号化アルゴリズム)](http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf) # FIPS 140-2 コンプライアンスサポート Mule 4 Runtime は、Federal Information Processing Standard (FIPS) 140-2 認証済み環境で実行するように設定できます。これには、HTTP Connector などのすべての Runtime Connector を含みます。Mule は、デフォルトでは FIPS セキュリティモードで実行されません。2 つの要件があります。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule Runtime の設定が FIPS セキュリティモードで実行されるように調整されている。

Government Cloud はデフォルトで FIPS 140-2 向けに設定されています。そのため、Government Cloud を使用している場合は、次の手順を実行する必要はありません。

Runtime Fabric を使用している場合は、これらの手順を実行せずに​「Enabling FIPS 140-2 Compliance Mode for Runtime Fabric (Runtime Fabric での FIPS 140-2 コンプライアンスモードの有効化)」​を参照してください。
## [](#前提条件)前提条件 このドキュメントは、読者が [FIPS 140-2](http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。このドキュメントは、読者が [認証済みセキュリティプロバイダー](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​を選択、取得済みであることも前提としています。 ## [](#set_up_environment)FIPS 140-2 Java 環境のセットアップ Mule は、FIPS に準拠するセキュリティモジュールの提供を Java ランタイムに依存しています。そのため、最初の要件は、FIPS 140-2 Java 環境が適切にセットアップされていることです。FIPS に準拠するシステムを初めてセットアップしていて、認証済みセキュリティプロバイダーをまだ設定していない場合は、まず [認証済みセキュリティプロバイダーを選択して取得](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​してから、選択したプロバイダーに固有の手順に従って Java 環境をセットアップする必要があります。 このプロセスの詳細は、選択したセキュリティプロバイダーによって異なります。セキュリティプロバイダーのドキュメントを参照して手順を実行してください。 ### [](#bouncy-castle-セキュリティプロバイダーを使用したセットアップ手順)Bouncy Castle セキュリティプロバイダーを使用したセットアップ手順 次の手順は、FIPS 140-2 Java 環境をセットアップする方法を示しています。 - [Java 8 でのセットアップ手順](#setupjava8) - [Java 11 以降でのセットアップ手順](#setupjava11) #### [](#setupjava8)Java 8 でのセットアップ手順 Java 8 で Bouncy Castle セキュリティプロバイダーをインストールして設定する手順は次のとおりです。 1. [BouncyCastle の Web ページ](https://www.bouncycastle.org/fips-java/)​からプロバイダーファイルをダウンロードします。 2. 必要な JAR ファイルを ​`$JAVA_HOME/lib/ext`​ フォルダーにインストールします。 ![FIPS JAR ファイルを Java ホームディレクトリにインストールするコマンドライン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/fips-install-jars.png) 3. セキュリティプロバイダーを、​`$JAVA_HOME/lib/security`​ フォルダーのセキュリティプロパティファイルに登録します。 1. `java.security`​ ファイルを開き、プロバイダーのクラス (​`org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider`​ など) をプロバイダーリストの最初の項目として追加します。 2. SSL プロバイダーの行を Bouncy Castle プロバイダーを使用するように変更します (​`security.provider.4=com.sun.net.ssl.internal.ssl.Provider BCFIPS`​)。 ![プロバイダーを変更するセキュリティプロバイダーのリスト](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/fips-register-jar.png) 4. 他のセキュリティプロバイダーの番号を調整して、番号が連続するようにします。 ![セキュリティプロバイダーが順番に表示されているリスト](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/fips-register-jar-renumber.png) 5. 変更を保存します。 #### [](#setupjava11)Java 11 以降でのセットアップ手順 Java 11 以降で Bouncy Castle セキュリティプロバイダーをインストールして設定する手順は次のとおりです。 1. Java 11 以降を使用していて、​`JAVA_HOME`​ が設定されていることを確認します。 2. [BouncyCastle の Web ページ](https://www.bouncycastle.org/fips-java/)​からプロバイダーファイルをダウンロードします。 Provider:bc-fips-1.0.2.4 TLS: bctls-fips-1.0.17.jar PKIX: bcpkix-fips-1.0.7.jar 3. ダウンロードした 3 つのファイルを Mule Runtime の ​`/lib/boot`​ フォルダー (Mule Runtime 用に必要) と ​`/mule-agent-plugin/lib`​ フォルダー (Mule エージェント用に必要) にコピーします。 4. `amc_setup`​ を実行し、Mule Runtime を登録します。たとえば、​**\[Add Server (サーバーを追加)\]**​ には登録トークン ​`/amc_setup -H d32c4bde-7184-444a-bd87-7a274623e14f---704247 node10 --fips`​ が表示されます。ここで ​`d32c4bde-7184-444a-bd87-7a274623e14f---704247`​ は Anypoint Runtime Manager からのキーです。 5. FIPS を有効にするには、​`$MULE_HOME/conf/wrapper.conf`​ を更新します。プロパティ ​`wrapper.java.additional.=-Dmule.security.model=fips140-2`​ と ​`wrapper.java.additional.=-Dmule.cluster.network.encryption.key={someKey}`​ を追加します。ここで、​`someKey`​ はクラスターからのキーで、クラスター環境を使用する場合には定義する必要があります。 6. 最新の Mule Runtime ディストリビューション ​`4.5.x`​ を取得すると、プロバイダー ​`BouncyCastleFipsProvider`​ と ​`BouncyCastleJsseProvider`​ が有効になります。次に、アルゴリズムを PKIX に設定します。 7. Mule Runtime を起動します。 ## [](#fips-セキュリティモードでの-mule-の実行)FIPS セキュリティモードでの Mule の実行 [FIPS 140-2 Java 環境のセットアップ](#set_up_environment)​の手順に従った後に、Mule インスタンスが FIPS 140-2 準拠環境で動作するようにセットアップするために、Mule アプリケーションサーバーを起動するラッパーの設定を更新します。 1. `wrapper.conf`​ ファイルを開きます (​`$MULE_HOME/conf`​ フォルダー内)。 2. Mule が FIPS セキュリティモードで動作するように設定する行のコメントを解除します (図を参照)。​``​ を ​`wrapper.conf`​ ファイル内の連続する次の番号に置き換えます。 ![FIPS 140-2 モードを有効にする設定が含まれるファイル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/fips-wrapper-conf-edit.png) 3. 変更を保存します。 Mule がもう一度起動すると、起動時の表示に FIPS セキュリティモードが有効になっていることが示されます。 ![FIPS 140-2 セキュリティモデルが有効になっている Mule サーバーの起動ログが表示されているコンソール出力](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/fips-startup.png) FIPS セキュリティモードが有効になると、Mule では自動的にプロトコルネゴシエーションが制限され、承認された暗号化スイートのサブセットのみが使用されます。すべての HTTPS Connector と TLS セキュリティレイヤーを使用するその他のコネクタは、自動的にこの制限の影響を受けます。 ### [](#fips-モードのクラスター環境)FIPS モードのクラスター環境 クラスタリングされた環境で Mule Runtime を使用して FIPS モードで実行している場合、クラスターの暗号化キーを定義する必要があります。詳細は、​[クラスターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-high-availability-ha-clusters#cluster_fips)​を参照してください。 ## [](#fips-140-2-準拠の暗号化スイート)FIPS 140-2 準拠の暗号化スイート 次のリストには、サポートされる FIPS 140-2 準拠の暗号化スイートが記載されています。 オンプレミス Mule インストールで使用される暗号化スイートを設定するには、​[SSL Connector の微調整](#fine-tuning-ssl-connectors)​を参照してください。 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_DHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA ## [](#ssl-connector-の微調整)SSL Connector の微調整 Mule conf フォルダーには、SSL Connector の設定を微調整するための 2 つのファイルがあります。これらのファイルでは、Mule が使用できる暗号化スイートと許可される SSL プロトコルを手動で設定できます。 - `tls-default.conf`​ (Mule が FIPS セキュリティモードで実行するように設定されていない場合に微調整できます) - `tls-fips140-2.conf`​ (Mule が FIPS セキュリティモードで実行されている場合に微調整できます) 該当するファイルを開き、リストの項目をコメントアウトまたはコメント解除して、使用できる暗号化スイートと SSL プロトコルを手動で設定します。これらのファイルを変更しない場合、Mule では、設定されたセキュリティマネージャーが暗号化スイートとプロトコルを選択することが許可されます。 ## [](#ヒントと制限事項)ヒントと制限事項 - Mule Runtime ディストリビューションにバンドルされている Bouncy Castle セキュリティプロバイダーは、FIPS 認証済みではありません。Mule が FIPS セキュリティモードを開始すると、Bouncy Castle プロバイダーは登録されず、使用されません。 - [Mule Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.8/securing#cryptography-module)​ と ​[Mule セキュアプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.8/secure-configuration-properties)​の設定オプションに含まれる一部の暗号化スキームと署名は FIPS に準拠していません。アプリケーションで FIPS 認証済みでないアルゴリズムを使用している場合は、実行時に次のようなエラーが表示されます。 Could not find encryption algorithm ''. (暗号化アルゴリズム「」が見つかりません。) You are running in FIPS mode, so please verify that the algorithm is compliant with FIPS. (FIPS モードで実行中です。アルゴリズムが FIPS に準拠していることを確認してください。) - 環境によってセキュリティ設定が異なり、暗号化スキームやアルゴリズムの選択も異なる可能性があることに注意してください。そのため、セットアップ方法に応じて、一部の環境でこのエラーが表示され、他の環境では表示されないことがあります。 - 同様に、Red Hat などの OS レベルで FIPS を有効にすると、ライセンス検証時に暗号化スイートエラーが発生するため、この操作はサポートされていません。 ## [](#関連情報)関連情報 - [Validated FIPS-2 Cryptographic Modules (検証済み FIPS-2 Cryptography Module)](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules) - [Approved Cryptographic Algorithms (承認済み暗号化アルゴリズム)](http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf) # FIPS 140-2 コンプライアンスサポート Mule 4 Runtime は、Federal Information Processing Standard (FIPS) 140-2 認証済み環境で実行するように設定できます。これには、HTTP Connector などのすべての Runtime Connector を含みます。Mule は、デフォルトでは FIPS セキュリティモードで実行されません。2 つの要件があります。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule Runtime の設定が FIPS セキュリティモードで実行されるように調整されている。

Government Cloud はデフォルトで FIPS 140-2 向けに設定されています。そのため、Government Cloud を使用している場合は、次の手順を実行する必要はありません。

Runtime Fabric を使用している場合は、これらの手順を実行せずに​「Enabling FIPS 140-2 Compliance Mode for Runtime Fabric (Runtime Fabric での FIPS 140-2 コンプライアンスモードの有効化)」​を参照してください。
## [](#前提条件)前提条件 このドキュメントは、読者が [FIPS 140-2](http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。このドキュメントは、読者が [認証済みセキュリティプロバイダー](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​を選択、取得済みであることも前提としています。 ## [](#set_up_environment)FIPS 140-2 Java 環境のセットアップ Mule は、FIPS に準拠するセキュリティモジュールの提供を Java ランタイムに依存しています。そのため、最初の要件は、FIPS 140-2 Java 環境が適切にセットアップされていることです。FIPS に準拠するシステムを初めてセットアップしていて、認証済みセキュリティプロバイダーをまだ設定していない場合は、まず [認証済みセキュリティプロバイダーを選択して取得](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules)​してから、選択したプロバイダーに固有の手順に従って Java 環境をセットアップする必要があります。 このプロセスの詳細は、選択したセキュリティプロバイダーによって異なります。セキュリティプロバイダーのドキュメントを参照して手順を実行してください。 ### [](#bouncy-castle-セキュリティプロバイダーを使用したセットアップ手順)Bouncy Castle セキュリティプロバイダーを使用したセットアップ手順 次の手順は、FIPS 140-2 Java 環境をセットアップする方法を示しています。 - [Java 8 でのセットアップ手順](#setupjava8) - [Java 11 以降でのセットアップ手順](#setupjava11) #### [](#setupjava8)Java 8 でのセットアップ手順 Java 8 で Bouncy Castle セキュリティプロバイダーをインストールして設定する手順は次のとおりです。 1. [BouncyCastle の Web ページ](https://www.bouncycastle.org/fips-java/)​からプロバイダーファイルをダウンロードします。 2. 必要な JAR ファイルを ​`$JAVA_HOME/lib/ext`​ フォルダーにインストールします。 ![FIPS JAR ファイルを Java ホームディレクトリにインストールするコマンドライン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/fips-install-jars.png) 3. セキュリティプロバイダーを、​`$JAVA_HOME/lib/security`​ フォルダーのセキュリティプロパティファイルに登録します。 1. `java.security`​ ファイルを開き、プロバイダーのクラス (​`org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider`​ など) をプロバイダーリストの最初の項目として追加します。 2. SSL プロバイダーの行を Bouncy Castle プロバイダーを使用するように変更します (​`security.provider.4=com.sun.net.ssl.internal.ssl.Provider BCFIPS`​)。 ![プロバイダーを変更するセキュリティプロバイダーのリスト](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/fips-register-jar.png) 4. 他のセキュリティプロバイダーの番号を調整して、番号が連続するようにします。 ![セキュリティプロバイダーが順番に表示されているリスト](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/fips-register-jar-renumber.png) 5. 変更を保存します。 #### [](#setupjava11)Java 11 以降でのセットアップ手順 Java 11 以降で Bouncy Castle セキュリティプロバイダーをインストールして設定する手順は次のとおりです。 1. Java 11 以降を使用していて、​`JAVA_HOME`​ が設定されていることを確認します。 2. [BouncyCastle の Web ページ](https://www.bouncycastle.org/fips-java/)​からプロバイダーファイルをダウンロードします。 Provider:bc-fips-1.0.2.4 TLS: bctls-fips-1.0.17.jar PKIX: bcpkix-fips-1.0.7.jar 3. ダウンロードした 3 つのファイルを Mule Runtime の ​`/lib/boot`​ フォルダー (Mule Runtime 用に必要) と ​`/mule-agent-plugin/lib`​ フォルダー (Mule エージェント用に必要) にコピーします。 4. `amc_setup`​ を実行し、Mule Runtime を登録します。たとえば、​**\[Add Server (サーバーを追加)\]**​ には登録トークン ​`/amc_setup -H d32c4bde-7184-444a-bd87-7a274623e14f---704247 node10 --fips`​ が表示されます。ここで ​`d32c4bde-7184-444a-bd87-7a274623e14f---704247`​ は Anypoint Runtime Manager からのキーです。 5. FIPS を有効にするには、​`$MULE_HOME/conf/wrapper.conf`​ を更新します。プロパティ ​`wrapper.java.additional.=-Dmule.security.model=fips140-2`​ と ​`wrapper.java.additional.=-Dmule.cluster.network.encryption.key={someKey}`​ を追加します。ここで、​`someKey`​ はクラスターからのキーで、クラスター環境を使用する場合には定義する必要があります。 6. 最新の Mule Runtime ディストリビューション ​`4.5.x`​ を取得すると、プロバイダー ​`BouncyCastleFipsProvider`​ と ​`BouncyCastleJsseProvider`​ が有効になります。次に、アルゴリズムを PKIX に設定します。 7. Mule Runtime を起動します。 ## [](#fips-セキュリティモードでの-mule-の実行)FIPS セキュリティモードでの Mule の実行 [FIPS 140-2 Java 環境のセットアップ](#set_up_environment)​の手順に従った後に、Mule インスタンスが FIPS 140-2 準拠環境で動作するようにセットアップするために、Mule アプリケーションサーバーを起動するラッパーの設定を更新します。 1. `wrapper.conf`​ ファイルを開きます (​`$MULE_HOME/conf`​ フォルダー内)。 2. Mule が FIPS セキュリティモードで動作するように設定する行のコメントを解除します (図を参照)。​``​ を ​`wrapper.conf`​ ファイル内の連続する次の番号に置き換えます。 ![FIPS 140-2 モードを有効にする設定が含まれるファイル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/fips-wrapper-conf-edit.png) 3. 変更を保存します。 Mule がもう一度起動すると、起動時の表示に FIPS セキュリティモードが有効になっていることが示されます。 ![FIPS 140-2 セキュリティモデルが有効になっている Mule サーバーの起動ログが表示されているコンソール出力](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/fips-startup.png) FIPS セキュリティモードが有効になると、Mule では自動的にプロトコルネゴシエーションが制限され、承認された暗号化スイートのサブセットのみが使用されます。すべての HTTPS Connector と TLS セキュリティレイヤーを使用するその他のコネクタは、自動的にこの制限の影響を受けます。 ### [](#fips-モードのクラスター環境)FIPS モードのクラスター環境 クラスタリングされた環境で Mule Runtime を使用して FIPS モードで実行している場合、クラスターの暗号化キーを定義する必要があります。詳細は、​[クラスターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-high-availability-ha-clusters#cluster_fips)​を参照してください。 ## [](#fips-140-2-準拠の暗号化スイート)FIPS 140-2 準拠の暗号化スイート 次のリストには、サポートされる FIPS 140-2 準拠の暗号化スイートが記載されています。 オンプレミス Mule インストールで使用される暗号化スイートを設定するには、​[SSL Connector の微調整](#fine-tuning-ssl-connectors)​を参照してください。 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_DHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA ## [](#fips-140-2-準拠のキーストア形式)FIPS 140-2 準拠のキーストア形式 Mule アプリケーションのキーストアまたはトラストストアは、通常 ​`PKCS12`​ または ​`JKS`​ 形式になります。 これらの形式は FIPS に準拠していません。準拠するように、これらを ​`BCFKS`​ 形式に変換します。 `JKS`​ キーストアを ​`BCFKS`​ 形式に変換するには、以下を行っていることを確認します。 1. Java 8 以降を使用し、​`JAVA_HOME`​ が設定されていることを確認する。 2. [Bouncy Castle Web サイト](https://www.bouncycastle.org/download/bouncy-castle-java-fips/)​から ​`bc-fips.jar`​ ファイルをダウンロードする。 3. 次のサンプルコマンドを使用して、キーストアを ​`BCFKS`​ 形式に変換する。 BC\_FIPS\_JAR=${BC\_PATH}/bc-fips-\*.jar # Replace with a correct path OLD\_KEYSTORE="keystore.jks" # Replace with the keystore to convert OLD\_PASSWD="changeit" # Replace with the keystore password NEW\_KEYSTORE="keystore.bcfks" # Replace with the new keystore NEW\_PASSWD="changeit" # Replace with the new keystore password keytool -importkeystore \\ -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \\ -providerpath ${BC\_FIPS\_JAR} \\ -srckeystore ${OLD\_KEYSTORE} -srcstoretype JKS -srcstorepass ${OLD\_PASSWD} \\ -destkeystore ${NEW\_KEYSTORE} -deststoretype BCFKS -deststorepass ${NEW\_PASSWD}
Java 17 以降を使用している場合、​-J—​add-exports=java.base/sun.security.provider=ALL-UNNAMED​ パラメーターを keytool コマンドの ​-importkeystore​ パラメーターの前に追加します。
1. 新しいキーストアまたはトラストストアを使用するには、Mule 設定ファイルで ​[TLS 設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/tls-configuration)​を更新します。
ソースキーストアが ​PKCS12​ の場合、​keytool​ コマンドでパラメーター ​-srcstoretype​ を ​PKCS12​ に設定します。
## [](#ssl-connector-の微調整)SSL Connector の微調整 Mule conf フォルダーには、SSL Connector の設定を微調整するための 2 つのファイルがあります。これらのファイルでは、Mule が使用できる暗号化スイートと許可される SSL プロトコルを手動で設定できます。 - `tls-default.conf`​ (Mule が FIPS セキュリティモードで実行するように設定されていない場合に微調整できます) - `tls-fips140-2.conf`​ (Mule が FIPS セキュリティモードで実行されている場合に微調整できます) 該当するファイルを開き、リストの項目をコメントアウトまたはコメント解除して、使用できる暗号化スイートと SSL プロトコルを手動で設定します。これらのファイルを変更しない場合、Mule では、設定されたセキュリティマネージャーが暗号化スイートとプロトコルを選択することが許可されます。 ## [](#ヒントと制限事項)ヒントと制限事項 - Mule Runtime ディストリビューションにバンドルされている Bouncy Castle セキュリティプロバイダーは、FIPS 認証済みではありません。Mule が FIPS セキュリティモードを開始すると、Bouncy Castle プロバイダーは登録されず、使用されません。 - [Mule Cryptography Module](https://docs.mulesoft.com/jp/mule-runtime/4.9/securing#cryptography-module)​ と ​[Mule セキュアプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.9/secure-configuration-properties)​の設定オプションに含まれる一部の暗号化スキームと署名は FIPS に準拠していません。アプリケーションで FIPS 認証済みでないアルゴリズムを使用している場合は、実行時に次のようなエラーが表示されます。 Could not find encryption algorithm ''. (暗号化アルゴリズム「」が見つかりません。) You are running in FIPS mode, so please verify that the algorithm is compliant with FIPS. (FIPS モードで実行中です。アルゴリズムが FIPS に準拠していることを確認してください。) - 環境によってセキュリティ設定が異なり、暗号化スキームやアルゴリズムの選択も異なる可能性があることに注意してください。そのため、セットアップ方法に応じて、一部の環境でこのエラーが表示され、他の環境では表示されないことがあります。 - 同様に、Red Hat などの OS レベルで FIPS を有効にすると、ライセンス検証時に暗号化スイートエラーが発生するため、この操作はサポートされていません。 ## [](#関連情報)関連情報 - [Validated FIPS-2 Cryptographic Modules (検証済み FIPS-2 Cryptography Module)](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules) - [Approved Cryptographic Algorithms (承認済み暗号化アルゴリズム)](http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf) # First Successful ルーター First Successful ルーターは、いずれかのルートが正常に実行されるまで、設定されている処理ルートのリストのルートを反復処理します。1 つの処理ルートが実行に失敗すると (エラーをスローします)、ルーターは次に設定されているルートを実行します。 設定されているルートがいずれも正常に実行されないと、First Successful ルーターはエラーをスローします。 ## [](#first-successful-ルーターの設定例)First Successful ルーターの設定例 4 つの処理ルートが設定されている First Successful ルーターの例を示します。 ```xml ``` 上の例は次のように実行されます。 1. 最初のルートが実行され、存在しないファイルを読み取ろうとしたため失敗します。 2. 2 つ目のルートは、存在しない変数にアクセスしようとしたため失敗します。 3. 3 つ目のルートは正常に実行され、​`successfulRoute`​ 変数に ​`3`​ を設定します。 4. First Successful ルーターは、いずれかのルートが正常に完了した時点で実行を終了するため、4 つ目のルートは実行されません。 ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-error-concept) - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling) # First Successful ルーター First Successful ルーターは、いずれかのルートが正常に実行されるまで、設定されている処理ルートのリストのルートを反復処理します。1 つの処理ルートが実行に失敗すると (エラーをスローします)、ルーターは次に設定されているルートを実行します。 設定されているルートがいずれも正常に実行されないと、First Successful ルーターはエラーをスローします。 ## [](#first-successful-ルーターの設定例)First Successful ルーターの設定例 4 つの処理ルートが設定されている First Successful ルーターの例を示します。 ```xml ``` 上の例は次のように実行されます。 1. 最初のルートが実行され、存在しないファイルを読み取ろうとしたため失敗します。 2. 2 つ目のルートは、存在しない変数にアクセスしようとしたため失敗します。 3. 3 つ目のルートは正常に実行され、​`successfulRoute`​ 変数に ​`3`​ を設定します。 4. First Successful ルーターは、いずれかのルートが正常に完了した時点で実行を終了するため、4 つ目のルートは実行されません。 ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-error-concept) - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling) # First Successful ルーター First Successful ルーターは、いずれかのルートが正常に実行されるまで、設定されている処理ルートのリストのルートを反復処理します。1 つの処理ルートが実行に失敗すると (エラーをスローします)、ルーターは次に設定されているルートを実行します。 設定されているルートがいずれも正常に実行されないと、First Successful ルーターはエラーをスローします。 ## [](#first-successful-ルーターの設定例)First Successful ルーターの設定例 4 つの処理ルートが設定されている First Successful ルーターの例を示します。 ```xml ``` 上の例は次のように実行されます。 1. 最初のルートが実行され、存在しないファイルを読み取ろうとしたため失敗します。 2. 2 つ目のルートは、存在しない変数にアクセスしようとしたため失敗します。 3. 3 つ目のルートは正常に実行され、​`successfulRoute`​ 変数に ​`3`​ を設定します。 4. First Successful ルーターは、いずれかのルートが正常に完了した時点で実行を終了するため、4 つ目のルートは実行されません。 ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-error-concept) - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling) # First Successful ルーター First Successful ルーターは、いずれかのルートが正常に実行されるまで、設定されている処理ルートのリストのルートを反復処理します。1 つの処理ルートが実行に失敗すると (エラーをスローします)、ルーターは次に設定されているルートを実行します。 設定されているルートがいずれも正常に実行されないと、First Successful ルーターはエラーをスローします。 ## [](#first-successful-ルーターの設定例)First Successful ルーターの設定例 4 つの処理ルートが設定されている First Successful ルーターの例を示します。 ```xml ``` 上の例は次のように実行されます。 1. 最初のルートが実行され、存在しないファイルを読み取ろうとしたため失敗します。 2. 2 つ目のルートは、存在しない変数にアクセスしようとしたため失敗します。 3. 3 つ目のルートは正常に実行され、​`successfulRoute`​ 変数に ​`3`​ を設定します。 4. First Successful ルーターは、いずれかのルートが正常に完了した時点で実行を終了するため、4 つ目のルートは実行されません。 ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-error-concept) - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling) # First Successful ルーター First Successful ルーターは、いずれかのルートが正常に実行されるまで、設定されている処理ルートのリストのルートを反復処理します。1 つの処理ルートが実行に失敗すると (エラーをスローします)、ルーターは次に設定されているルートを実行します。 設定されているルートがいずれも正常に実行されないと、First Successful ルーターはエラーをスローします。 ## [](#first-successful-ルーターの設定例)First Successful ルーターの設定例 4 つの処理ルートが設定されている First Successful ルーターの例を示します。 ```xml ``` 上の例は次のように実行されます。 1. 最初のルートが実行され、存在しないファイルを読み取ろうとしたため失敗します。 2. 2 つ目のルートは、存在しない変数にアクセスしようとしたため失敗します。 3. 3 つ目のルートは正常に実行され、​`successfulRoute`​ 変数に ​`3`​ を設定します。 4. First Successful ルーターは、いずれかのルートが正常に完了した時点で実行を終了するため、4 つ目のルートは実行されません。 ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-error-concept) - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling) # First Successful ルーター First Successful ルーターは、いずれかのルートが正常に実行されるまで、設定されている処理ルートのリストのルートを反復処理します。1 つの処理ルートが実行に失敗すると (エラーをスローします)、ルーターは次に設定されているルートを実行します。 設定されているルートがいずれも正常に実行されないと、First Successful ルーターはエラーをスローします。 ## [](#first-successful-ルーターの設定例)First Successful ルーターの設定例 4 つの処理ルートが設定されている First Successful ルーターの例を示します。 ```xml ``` 上の例は次のように実行されます。 1. 最初のルートが実行され、存在しないファイルを読み取ろうとしたため失敗します。 2. 2 つ目のルートは、存在しない変数にアクセスしようとしたため失敗します。 3. 3 つ目のルートは正常に実行され、​`successfulRoute`​ 変数に ​`3`​ を設定します。 4. First Successful ルーターは、いずれかのルートが正常に完了した時点で実行を終了するため、4 つ目のルートは実行されません。 ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-error-concept) - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling) # First Successful ルーター First Successful ルーターは、いずれかのルートが正常に実行されるまで、設定されている処理ルートのリストのルートを反復処理します。1 つの処理ルートが実行に失敗すると (エラーをスローします)、ルーターは次に設定されているルートを実行します。 設定されているルートがいずれも正常に実行されないと、First Successful ルーターはエラーをスローします。 ## [](#first-successful-ルーターの設定例)First Successful ルーターの設定例 4 つの処理ルートが設定されている First Successful ルーターの例を示します。 ```xml ``` 上の例は次のように実行されます。 1. 最初のルートが実行され、存在しないファイルを読み取ろうとしたため失敗します。 2. 2 つ目のルートは、存在しない変数にアクセスしようとしたため失敗します。 3. 3 つ目のルートは正常に実行され、​`successfulRoute`​ 変数に ​`3`​ を設定します。 4. First Successful ルーターは、いずれかのルートが正常に完了した時点で実行を終了するため、4 つ目のルートは実行されません。 ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-error-concept) - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling) # Flow Reference コンポーネント Flow Reference は、Mule イベントを同じ Mule アプリケーション内で別のフローやサブフローにルーティングし、参照先のフローですべてのプロセッサーを実行してから、イベントを元のフローにルーティングします。次の図は、1 つのフローが別のフローを参照したときの処理の順序を示しています。 ![flowref about 8b5d1](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/flowref-about-8b5d1.png) メインのフローがトリガーされると、Mule イベントは Flow Reference に到達するまでそのフローを実行します。次に、イベントは参照先のフローを最初から最後まで実行し、メインフローに戻ります。 このプロセスにより、参照先のフロー全体を現在のフロー内の 1 つのコンポーネントのように扱うことができます。 このプロセスにより、参照先のフロー全体を現在のフロー内の 1 つのコンポーネントのように扱うことができます。たとえば、ファイルをリストすることが多いフローは、List 操作の出力を処理する別のフローを参照できます。ファイルをリストするフローにすべての処理ステップを追加する代わりに、処理フローを参照する Flow Reference を追加できます。 ## [](#configure-flow-ref)Flow Reference の設定 Flow Reference コンポーネントを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Mule Palette (Mule パレット)\]**​ から、参照先フローへのコールを作成するフロー内のポイントまで Flow Reference コンポーネントをドラッグします。 ![flow-ref-create](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-flow-ref-create.png) 2. Flow Reference のプロパティを開いて、参照するフローの名前を ​**\[Flow name (フロー名)\]**​ に指定します。 ![flow-ref-config](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-flow-ref-config.png)
実際のフロー名を使用して ​[Flow name (フロー名)]​ (​name​) 属性を定義してください。動的値 (DataWeave 式、変数) を使用して参照先フローを指定すると、パフォーマンスが低下します。また、MUnit テストおよびアプリケーション分析ツールは動的参照では正常に機能しない可能性があります。
## [](#flow-reference-対象変数を使用したコンテンツの強化)Flow Reference 対象変数を使用したコンテンツの強化 現在のペイロードと変数を使用したフローを実行しつつ、プロセスの完了後も Mule メッセージが変更されないようにしたい場合があります。この場合は、対象変数を使用することで、元のメッセージを変更せずに、参照先フローの処理結果を格納できます。 Flow Reference のプロパティで以下の項目を設定することで、Flow Reference コールの結果を対象変数に格納できます。 - **Target (対象)**​: Flow Reference がメッセージの処理結果を格納するために作成する変数の名前。 - **Target Value (対象値)**​: 操作の出力に対して評価される式。この評価の結果は、定義された対象変数に保存されます。 ### [](#対象変数を使用する場合の考慮事項)対象変数を使用する場合の考慮事項 Flow Reference コンポーネントで ​`target`​ 変数を設定すると、元のメッセージは変更されません。つまり、参照先のフローでペイロードや変数が変更されても、参照先のフローでプロセッサーの実行が完了した後は、ペイロードや変数は元の値に戻ります。 一方、​`target`​ 変数を設定しないと、参照先のフローでペイロードや変数に対して行われた変更は、参照先のフローの実行が完了した後も保持され、ペイロードや変数の元の値が変更されます。 ### [](#flow-reference-の-xml-例)Flow Reference の XML 例 次の XML コードは、​[Flow Reference の設定](#configure-flow-ref)​で作成したプロジェクトを表しており、Flow Reference コンポーネントがコールした 2 つ目のフローの結果を格納するための対象変数 ​`flowReferenceVar,`​ が追加されています。この変数は、​`vars.flowReferenceVar`​ のログを記録することで、メインフローでも使用されます。 ```xml ``` 次のログは、アプリケーション例の実行後の出力を表しています。 INFO LoggerMessageProcessor: Payload = Original payload INFO LoggerMessageProcessor: myVar = 1 INFO LoggerMessageProcessor: flowReferenceVar = Modified payload Flow Reference コンポーネントから ​`target="flowReferenceVar"`​ を削除すると、アプリケーションは次の出力を返します。 INFO LoggerMessageProcessor: Payload = Modified payload INFO LoggerMessageProcessor: myVar = 2 INFO LoggerMessageProcessor: flowReferenceVar = null ログは、読みやすいように省略されています。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-event) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.3/target-variables) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management#tx_scopes_routers) # Flow Reference コンポーネント Flow Reference は、Mule イベントを同じ Mule アプリケーション内で別のフローやサブフローにルーティングし、参照先のフローですべてのプロセッサーを実行してから、イベントを元のフローにルーティングします。次の図は、1 つのフローが別のフローを参照したときの処理の順序を示しています。 ![flowref about 8b5d1](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/flowref-about-8b5d1.png) メインのフローがトリガーされると、Mule イベントは Flow Reference に到達するまでそのフローを実行します。次に、イベントは参照先のフローを最初から最後まで実行し、メインフローに戻ります。 このプロセスにより、参照先のフロー全体を現在のフロー内の 1 つのコンポーネントのように扱うことができます。 このプロセスにより、参照先のフロー全体を現在のフロー内の 1 つのコンポーネントのように扱うことができます。たとえば、ファイルをリストすることが多いフローは、List 操作の出力を処理する別のフローを参照できます。ファイルをリストするフローにすべての処理ステップを追加する代わりに、処理フローを参照する Flow Reference を追加できます。 ## [](#configure-flow-ref)Flow Reference の設定 Flow Reference コンポーネントを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Mule Palette (Mule パレット)\]**​ から、参照先フローへのコールを作成するフロー内のポイントまで Flow Reference コンポーネントをドラッグします。 ![flow-ref-create](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-flow-ref-create.png) 2. Flow Reference のプロパティを開いて、参照するフローの名前を ​**\[Flow name (フロー名)\]**​ に指定します。 ![flow-ref-config](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-flow-ref-config.png)
実際のフロー名を使用して ​[Flow name (フロー名)]​ (​name​) 属性を定義してください。動的値 (DataWeave 式、変数) を使用して参照先フローを指定すると、パフォーマンスが低下します。また、MUnit テストおよびアプリケーション分析ツールは動的参照では正常に機能しない可能性があります。
## [](#flow-reference-対象変数を使用したコンテンツの強化)Flow Reference 対象変数を使用したコンテンツの強化 現在のペイロードと変数を使用したフローを実行しつつ、プロセスの完了後も Mule メッセージが変更されないようにしたい場合があります。この場合は、対象変数を使用することで、元のメッセージを変更せずに、参照先フローの処理結果を格納できます。 Flow Reference のプロパティで以下の項目を設定することで、Flow Reference コールの結果を対象変数に格納できます。 - **Target (対象)**​: Flow Reference がメッセージの処理結果を格納するために作成する変数の名前。 - **Target Value (対象値)**​: 操作の出力に対して評価される式。この評価の結果は、定義された対象変数に保存されます。 ### [](#対象変数を使用する場合の考慮事項)対象変数を使用する場合の考慮事項 Flow Reference コンポーネントで ​`target`​ 変数を設定すると、元のメッセージは変更されません。つまり、参照先のフローでペイロードや変数が変更されても、参照先のフローでプロセッサーの実行が完了した後は、ペイロードや変数は元の値に戻ります。 一方、​`target`​ 変数を設定しないと、参照先のフローでペイロードや変数に対して行われた変更は、参照先のフローの実行が完了した後も保持され、ペイロードや変数の元の値が変更されます。 ## [](#参照先フローでのエラー処理動作)参照先フローでのエラー処理動作 Flow Reference コンポーネントによって参照されているフロー内でエラーが発生すると、参照先フローの実行が停止し、参照先フローのエラーハンドラーに処理が渡されます。参照先フローでエラーハンドラーが設定されていない場合は、Flow Reference コールを含むフローまでエラーが伝播され、このフローで設定されている Error Handler コンポーネントでエラーが処理されます。 エラーが発生した場合は、フローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#flow-reference-の-xml-例)Flow Reference の XML 例 次の XML コードは、​[Flow Reference の設定](#configure-flow-ref)​で作成したプロジェクトを表しており、Flow Reference コンポーネントがコールした 2 つ目のフローの結果を格納するための対象変数 ​`flowReferenceVar,`​ が追加されています。この変数は、​`vars.flowReferenceVar`​ のログを記録することで、メインフローでも使用されます。 ```xml ``` 次のログは、アプリケーション例の実行後の出力を表しています。 INFO LoggerMessageProcessor: Payload = Original payload INFO LoggerMessageProcessor: myVar = 1 INFO LoggerMessageProcessor: flowReferenceVar = Modified payload Flow Reference コンポーネントから ​`target="flowReferenceVar"`​ を削除すると、アプリケーションは次の出力を返します。 INFO LoggerMessageProcessor: Payload = Modified payload INFO LoggerMessageProcessor: myVar = 2 INFO LoggerMessageProcessor: flowReferenceVar = null ログは、読みやすいように省略されています。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-event) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.4/target-variables) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management#tx_scopes_routers) # Flow Reference コンポーネント Flow Reference は、Mule イベントを同じ Mule アプリケーション内で別のフローやサブフローにルーティングし、参照先のフローですべてのプロセッサーを実行してから、イベントを元のフローにルーティングします。次の図は、1 つのフローが別のフローを参照したときの処理の順序を示しています。 ![flowref about 8b5d1](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/flowref-about-8b5d1.png) メインのフローがトリガーされると、Mule イベントは Flow Reference に到達するまでそのフローを実行します。次に、イベントは参照先のフローを最初から最後まで実行し、メインフローに戻ります。 このプロセスにより、参照先のフロー全体を現在のフロー内の 1 つのコンポーネントのように扱うことができます。 Flow Reference によって、Mule アプリケーションを個々の再利用可能な単位に分割できます。たとえば、ファイルをリストすることが多いフローは、List 操作の出力を処理する別のフローを参照できます。ファイルをリストするフローにすべての処理ステップを追加する代わりに、処理フローを参照する Flow Reference を追加できます。 ## [](#configure-flow-ref)Flow Reference の設定 Flow Reference コンポーネントを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Mule Palette (Mule パレット)\]**​ から、参照先フローへのコールを作成するフロー内のポイントまで Flow Reference コンポーネントをドラッグします。 ![flow-ref-create](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-flow-ref-create.png) 2. Flow Reference のプロパティを開いて、参照するフローの名前を ​**\[Flow name (フロー名)\]**​ に指定します。 ![flow-ref-config](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-flow-ref-config.png)
実際のフロー名を使用して ​[Flow name (フロー名)]​ (​name​) 属性を定義してください。動的値 (DataWeave 式、変数) を使用して参照先フローを指定すると、パフォーマンスが低下します。また、MUnit テストおよびアプリケーション分析ツールは動的参照では正常に機能しない可能性があります。
## [](#flow-reference-対象変数を使用したコンテンツの強化)Flow Reference 対象変数を使用したコンテンツの強化 現在のペイロードと変数を使用したフローを実行しつつ、プロセスの完了後も Mule メッセージが変更されないようにしたい場合があります。この場合は、対象変数を使用することで、元のメッセージを変更せずに、参照先フローの処理結果を格納できます。 Flow Reference のプロパティで以下の項目を設定することで、Flow Reference コールの結果を対象変数に格納できます。 - **Target (対象)**​: Flow Reference がメッセージの処理結果を格納するために作成する変数の名前。 - **Target Value (対象値)**​: 操作の出力に対して評価される式。この評価の結果は、定義された対象変数に保存されます。 ### [](#対象変数を使用する場合の考慮事項)対象変数を使用する場合の考慮事項 Flow Reference コンポーネントで ​`target`​ 変数を設定すると、元のメッセージは変更されません。つまり、参照先のフローでペイロードや変数が変更されても、参照先のフローでプロセッサーの実行が完了した後は、ペイロードや変数は元の値に戻ります。 一方、​`target`​ 変数を設定しないと、参照先のフローでペイロードや変数に対して行われた変更は、参照先のフローの実行が完了した後も保持され、ペイロードや変数の元の値が変更されます。 ## [](#参照先フローでのエラー処理動作)参照先フローでのエラー処理動作 Flow Reference コンポーネントによって参照されているフロー内でエラーが発生すると、参照先フローの実行が停止し、参照先フローのエラーハンドラーに処理が渡されます。参照先フローでエラーハンドラーが設定されていない場合は、Flow Reference コールを含むフローまでエラーが伝播され、このフローで設定されている Error Handler コンポーネントでエラーが処理されます。 エラーが発生した場合は、フローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#flow-reference-の-xml-例)Flow Reference の XML 例 次の XML コードは、​[「Flow Reference の設定」](#configure-flow-ref)​で作成したプロジェクトを表しており、Flow Reference コンポーネントがコールした 2 つ目のフローの結果を格納するための対象変数 ​`flowReferenceVar,`​ が追加されています。この変数は、​`vars.flowReferenceVar`​ のログを記録することで、メインフローでも使用されます。 ```xml ``` 次のログは、アプリケーション例の実行後の出力を表しています。 INFO LoggerMessageProcessor: Payload = Original payload INFO LoggerMessageProcessor: myVar = 1 INFO LoggerMessageProcessor: flowReferenceVar = Modified payload Flow Reference コンポーネントから ​`target="flowReferenceVar"`​ を削除すると、アプリケーションは次の出力を返します。 INFO LoggerMessageProcessor: Payload = Modified payload INFO LoggerMessageProcessor: myVar = 2 INFO LoggerMessageProcessor: flowReferenceVar = null ログは、読みやすいように省略されています。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-event) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.5/target-variables) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management#tx_scopes_routers) # Flow Reference コンポーネント Flow Reference は、Mule イベントを同じ Mule アプリケーション内で別のフローやサブフローにルーティングし、参照先のフローですべてのプロセッサーを実行してから、イベントを元のフローにルーティングします。次の図は、1 つのフローが別のフローを参照したときの処理の順序を示しています。 ![flowref about 8b5d1](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/flowref-about-8b5d1.png) メインのフローがトリガーされると、Mule イベントは Flow Reference に到達するまでそのフローを実行します。次に、イベントは参照先のフローを最初から最後まで実行し、メインフローに戻ります。 このプロセスにより、参照先のフロー全体を現在のフロー内の 1 つのコンポーネントのように扱うことができます。 このプロセスにより、参照先のフロー全体を現在のフロー内の 1 つのコンポーネントのように扱うことができます。たとえば、ファイルをリストすることが多いフローは、List 操作の出力を処理する別のフローを参照できます。ファイルをリストするフローにすべての処理ステップを追加する代わりに、処理フローを参照する Flow Reference を追加できます。 ## [](#configure-flow-ref)Flow Reference の設定 Flow Reference コンポーネントを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Mule Palette (Mule パレット)\]**​ から、参照先フローへのコールを作成するフロー内のポイントまで Flow Reference コンポーネントをドラッグします。 ![flow-ref-create](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-flow-ref-create.png) 2. Flow Reference のプロパティを開いて、参照するフローの名前を ​**\[Flow name (フロー名)\]**​ に指定します。 ![flow-ref-config](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-flow-ref-config.png)
実際のフロー名を使用して ​[Flow name (フロー名)]​ (​name​) 属性を定義してください。動的値 (DataWeave 式、変数) を使用して参照先フローを指定すると、パフォーマンスが低下します。また、MUnit テストおよびアプリケーション分析ツールは動的参照では正常に機能しない可能性があります。
## [](#flow-reference-対象変数を使用したコンテンツの強化)Flow Reference 対象変数を使用したコンテンツの強化 現在のペイロードと変数を使用したフローを実行しつつ、プロセスの完了後も Mule メッセージが変更されないようにしたい場合があります。この場合は、対象変数を使用することで、元のメッセージを変更せずに、参照先フローの処理結果を格納できます。 Flow Reference のプロパティで以下の項目を設定することで、Flow Reference コールの結果を対象変数に格納できます。 - **Target (対象)**​: Flow Reference がメッセージの処理結果を格納するために作成する変数の名前。 - **Target Value (対象値)**​: 操作の出力に対して評価される式。この評価の結果は、定義された対象変数に保存されます。 ### [](#対象変数を使用する場合の考慮事項)対象変数を使用する場合の考慮事項 Flow Reference コンポーネントで ​`target`​ 変数を設定すると、元のメッセージは変更されません。つまり、参照先のフローでペイロードや変数が変更されても、参照先のフローでプロセッサーの実行が完了した後は、ペイロードや変数は元の値に戻ります。 一方、​`target`​ 変数を設定しないと、参照先のフローでペイロードや変数に対して行われた変更は、参照先のフローの実行が完了した後も保持され、ペイロードや変数の元の値が変更されます。 ## [](#参照先フローでのエラー処理動作)参照先フローでのエラー処理動作 Flow Reference コンポーネントによって参照されているフロー内でエラーが発生すると、参照先フローの実行が停止し、参照先フローのエラーハンドラーに処理が渡されます。参照先フローでエラーハンドラーが設定されていない場合は、Flow Reference コールを含むフローまでエラーが伝播され、このフローで設定されている Error Handler コンポーネントでエラーが処理されます。 エラーが発生した場合は、フローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#flow-reference-の-xml-例)Flow Reference の XML 例 次の XML コードは、​[Flow Reference の設定](#configure-flow-ref)​で作成したプロジェクトを表しており、Flow Reference コンポーネントがコールした 2 つ目のフローの結果を格納するための対象変数 ​`flowReferenceVar,`​ が追加されています。この変数は、​`vars.flowReferenceVar`​ のログを記録することで、メインフローでも使用されます。 ```xml ``` 次のログは、アプリケーション例の実行後の出力を表しています。 INFO LoggerMessageProcessor: Payload = Original payload INFO LoggerMessageProcessor: myVar = 1 INFO LoggerMessageProcessor: flowReferenceVar = Modified payload Flow Reference コンポーネントから ​`target="flowReferenceVar"`​ を削除すると、アプリケーションは次の出力を返します。 INFO LoggerMessageProcessor: Payload = Modified payload INFO LoggerMessageProcessor: myVar = 2 INFO LoggerMessageProcessor: flowReferenceVar = null ログは、読みやすいように省略されています。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-event) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.6/target-variables) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management#tx_scopes_routers) # Flow Reference コンポーネント Flow Reference は、Mule イベントを同じ Mule アプリケーション内で別のフローやサブフローにルーティングし、参照先のフローですべてのプロセッサーを実行してから、イベントを元のフローにルーティングします。次の図は、1 つのフローが別のフローを参照したときの処理の順序を示しています。 ![複数のステップがあるメインフローとメインフローで参照されるサブフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/flowref-about-8b5d1.png) メインのフローがトリガーされると、Mule イベントは Flow Reference に到達するまでそのフローを実行します。次に、イベントは参照先のフローを最初から最後まで実行し、メインフローに戻ります。 このプロセスにより、参照先のフロー全体を現在のフロー内の 1 つのコンポーネントのように扱うことができます。 Flow Reference によって、Mule アプリケーションを個々の再利用可能な単位に分割できます。たとえば、ファイルをリストすることが多いフローは、List 操作の出力を処理する別のフローを参照できます。ファイルをリストするフローにすべての処理ステップを追加する代わりに、処理フローを参照する Flow Reference を追加できます。 ## [](#configure-flow-ref)Flow Reference の設定 Flow Reference コンポーネントを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Mule Palette (Mule パレット)\]**​ から、参照先フローへのコールを作成するフロー内のポイントまで Flow Reference コンポーネントをドラッグします。 ![flow-ref-create](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-flow-ref-create.png) 2. Flow Reference のプロパティを開いて、参照するフローの名前を ​**\[Flow name (フロー名)\]**​ に指定します。 ![flow-ref-config](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-flow-ref-config.png)
実際のフロー名を使用して ​[Flow name (フロー名)]​ (​name​) 属性を定義してください。動的値 (DataWeave 式、変数) を使用して参照先フローを指定すると、パフォーマンスが低下します。また、MUnit テストおよびアプリケーション分析ツールは動的参照では正常に機能しない可能性があります。
## [](#flow-reference-対象変数を使用したコンテンツの強化)Flow Reference 対象変数を使用したコンテンツの強化 現在のペイロードと変数を使用したフローを実行しつつ、プロセスの完了後も Mule メッセージが変更されないようにしたい場合があります。この場合は、対象変数を使用することで、元のメッセージを変更せずに、参照先フローの処理結果を格納できます。 Flow Reference のプロパティで以下の項目を設定することで、Flow Reference コールの結果を対象変数に格納できます。 - **Target (対象)**​: Flow Reference がメッセージの処理結果を格納するために作成する変数の名前。 - **Target Value (対象値)**​: 操作の出力に対して評価される式。この評価の結果は、定義された対象変数に保存されます。 ### [](#対象変数を使用する場合の考慮事項)対象変数を使用する場合の考慮事項 Flow Reference コンポーネントで ​`target`​ 変数を設定すると、元のメッセージは変更されません。つまり、参照先のフローでペイロードや変数が変更されても、参照先のフローでプロセッサーの実行が完了した後は、ペイロードや変数は元の値に戻ります。 一方、​`target`​ 変数を設定しないと、参照先のフローでペイロードや変数に対して行われた変更は、参照先のフローの実行が完了した後も保持され、ペイロードや変数の元の値が変更されます。 ## [](#参照先フローでのエラー処理動作)参照先フローでのエラー処理動作 Flow Reference コンポーネントによって参照されているフロー内でエラーが発生すると、参照先フローの実行が停止し、参照先フローのエラーハンドラーに処理が渡されます。参照先フローでエラーハンドラーが設定されていない場合は、Flow Reference コールを含むフローまでエラーが伝播され、このフローで設定されている Error Handler コンポーネントでエラーが処理されます。 エラーが発生した場合は、フローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#flow-reference-の-xml-例)Flow Reference の XML 例 次の XML コードは、​[Flow Reference の設定](#configure-flow-ref)​で作成したプロジェクトを表しており、Flow Reference コンポーネントがコールした 2 つ目のフローの結果を格納するための対象変数 ​`flowReferenceVar,`​ が追加されています。この変数は、​`vars.flowReferenceVar`​ のログを記録することで、メインフローでも使用されます。 ```xml ``` 次のログは、アプリケーション例の実行後の出力を表しています。 INFO LoggerMessageProcessor: Payload = Original payload INFO LoggerMessageProcessor: myVar = 1 INFO LoggerMessageProcessor: flowReferenceVar = Modified payload Flow Reference コンポーネントから ​`target="flowReferenceVar"`​ を削除すると、アプリケーションは次の出力を返します。 INFO LoggerMessageProcessor: Payload = Modified payload INFO LoggerMessageProcessor: myVar = 2 INFO LoggerMessageProcessor: flowReferenceVar = null ログは、読みやすいように省略されています。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-event) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.7/target-variables) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management#tx_scopes_routers) # Flow Reference コンポーネント Flow Reference は、Mule イベントを同じ Mule アプリケーション内で別のフローやサブフローにルーティングし、参照先のフローですべてのプロセッサーを実行してから、イベントを元のフローにルーティングします。次の図は、1 つのフローが別のフローを参照したときの処理の順序を示しています。 ![複数のステップがあるメインフローとメインフローで参照されるサブフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/flowref-about-8b5d1.png) メインのフローがトリガーされると、Mule イベントは Flow Reference に到達するまでそのフローを実行します。次に、イベントは参照先のフローを最初から最後まで実行し、メインフローに戻ります。 このプロセスにより、参照先のフロー全体を現在のフロー内の 1 つのコンポーネントのように扱うことができます。 Flow Reference によって、Mule アプリケーションを個々の再利用可能な単位に分割できます。たとえば、ファイルをリストすることが多いフローは、List 操作の出力を処理する別のフローを参照できます。ファイルをリストするフローにすべての処理ステップを追加する代わりに、処理フローを参照する Flow Reference を追加できます。 ## [](#configure-flow-ref)Flow Reference の設定 Flow Reference コンポーネントを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Mule Palette (Mule パレット)\]**​ から、参照先フローへのコールを作成するフロー内のポイントまで Flow Reference コンポーネントをドラッグします。 ![変数およびペイロード設定が含まれるメインフローが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-flow-ref-create.png) 2. Flow Reference のプロパティを開いて、参照するフローの名前を ​**\[Flow name (フロー名)\]**​ に指定します。 ![フロー名および対象の設定が表示されている 2 つ目のフローの設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-flow-ref-config.png)
実際のフロー名を使用して ​[Flow name (フロー名)]​ (​name​) 属性を定義してください。動的値 (DataWeave 式、変数) を使用して参照先フローを指定すると、パフォーマンスが低下します。また、MUnit テストおよびアプリケーション分析ツールは動的参照では正常に機能しない可能性があります。
## [](#flow-reference-対象変数を使用したコンテンツの強化)Flow Reference 対象変数を使用したコンテンツの強化 現在のペイロードと変数を使用したフローを実行しつつ、プロセスの完了後も Mule メッセージが変更されないようにしたい場合があります。この場合は、対象変数を使用することで、元のメッセージを変更せずに、参照先フローの処理結果を格納できます。 Flow Reference のプロパティで以下の項目を設定することで、Flow Reference コールの結果を対象変数に格納できます。 - **Target (対象)**​: Flow Reference がメッセージの処理結果を格納するために作成する変数の名前。 - **Target Value (対象値)**​: 操作の出力に対して評価される式。この評価の結果は、定義された対象変数に保存されます。 ### [](#対象変数を使用する場合の考慮事項)対象変数を使用する場合の考慮事項 Flow Reference コンポーネントで ​`target`​ 変数を設定すると、元のメッセージは変更されません。つまり、参照先のフローでペイロードや変数が変更されても、参照先のフローでプロセッサーの実行が完了した後は、ペイロードや変数は元の値に戻ります。 一方、​`target`​ 変数を設定しないと、参照先のフローでペイロードや変数に対して行われた変更は、参照先のフローの実行が完了した後も保持され、ペイロードや変数の元の値が変更されます。 ## [](#参照先フローでのエラー処理動作)参照先フローでのエラー処理動作 Flow Reference コンポーネントによって参照されているフロー内でエラーが発生すると、参照先フローの実行が停止し、参照先フローのエラーハンドラーに処理が渡されます。参照先フローでエラーハンドラーが設定されていない場合は、Flow Reference コールを含むフローまでエラーが伝播され、このフローで設定されている Error Handler コンポーネントでエラーが処理されます。 エラーが発生した場合は、フローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#flow-reference-の-xml-例)Flow Reference の XML 例 次の XML コードは、​[Flow Reference の設定](#configure-flow-ref)​で作成したプロジェクトを表しており、Flow Reference コンポーネントがコールした 2 つ目のフローの結果を格納するための対象変数 ​`flowReferenceVar,`​ が追加されています。この変数は、​`vars.flowReferenceVar`​ のログを記録することで、メインフローでも使用されます。 ```xml ``` 次のログは、アプリケーション例の実行後の出力を表しています。 INFO LoggerMessageProcessor: Payload = Original payload INFO LoggerMessageProcessor: myVar = 1 INFO LoggerMessageProcessor: flowReferenceVar = Modified payload Flow Reference コンポーネントから ​`target="flowReferenceVar"`​ を削除すると、アプリケーションは次の出力を返します。 INFO LoggerMessageProcessor: Payload = Modified payload INFO LoggerMessageProcessor: myVar = 2 INFO LoggerMessageProcessor: flowReferenceVar = null ログは、読みやすいように省略されています。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-event) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.8/target-variables) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management#tx_scopes_routers) # Flow Reference コンポーネント Flow Reference は、Mule イベントを同じ Mule アプリケーション内で別のフローやサブフローにルーティングし、参照先のフローですべてのプロセッサーを実行してから、イベントを元のフローにルーティングします。次の図は、1 つのフローが別のフローを参照したときの処理の順序を示しています。 ![複数のステップがあるメインフローとメインフローで参照されるサブフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/flowref-about-8b5d1.png) メインのフローがトリガーされると、Mule イベントは Flow Reference に到達するまでそのフローを実行します。次に、イベントは参照先のフローを最初から最後まで実行し、メインフローに戻ります。 このプロセスにより、参照先のフロー全体を現在のフロー内の 1 つのコンポーネントのように扱うことができます。 Flow Reference によって、Mule アプリケーションを個々の再利用可能な単位に分割できます。たとえば、ファイルをリストすることが多いフローは、List 操作の出力を処理する別のフローを参照できます。ファイルをリストするフローにすべての処理ステップを追加する代わりに、処理フローを参照する Flow Reference を追加できます。 ## [](#configure-flow-ref)Flow Reference の設定 Flow Reference コンポーネントを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Mule Palette (Mule パレット)\]**​ から、参照先フローへのコールを作成するフロー内のポイントまで Flow Reference コンポーネントをドラッグします。 ![変数およびペイロード設定が含まれるメインフローが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-flow-ref-create.png) 2. Flow Reference のプロパティを開いて、参照するフローの名前を ​**\[Flow name (フロー名)\]**​ に指定します。 ![フロー名および対象の設定が表示されている 2 つ目のフローの設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-flow-ref-config.png)
実際のフロー名を使用して ​[Flow name (フロー名)]​ (​name​) 属性を定義してください。動的値 (DataWeave 式、変数) を使用して参照先フローを指定すると、パフォーマンスが低下します。また、MUnit テストおよびアプリケーション分析ツールは動的参照では正常に機能しない可能性があります。
## [](#flow-reference-対象変数を使用したコンテンツの強化)Flow Reference 対象変数を使用したコンテンツの強化 現在のペイロードと変数を使用したフローを実行しつつ、プロセスの完了後も Mule メッセージが変更されないようにしたい場合があります。この場合は、対象変数を使用することで、元のメッセージを変更せずに、参照先フローの処理結果を格納できます。 Flow Reference のプロパティで以下の項目を設定することで、Flow Reference コールの結果を対象変数に格納できます。 - **Target (対象)**​: Flow Reference がメッセージの処理結果を格納するために作成する変数の名前。 - **Target Value (対象値)**​: 操作の出力に対して評価される式。この評価の結果は、定義された対象変数に保存されます。 ### [](#対象変数を使用する場合の考慮事項)対象変数を使用する場合の考慮事項 Flow Reference コンポーネントで ​`target`​ 変数を設定すると、元のメッセージは変更されません。つまり、参照先のフローでペイロードや変数が変更されても、参照先のフローでプロセッサーの実行が完了した後は、ペイロードや変数は元の値に戻ります。 一方、​`target`​ 変数を設定しないと、参照先のフローでペイロードや変数に対して行われた変更は、参照先のフローの実行が完了した後も保持され、ペイロードや変数の元の値が変更されます。 ## [](#参照先フローでのエラー処理動作)参照先フローでのエラー処理動作 Flow Reference コンポーネントによって参照されているフロー内でエラーが発生すると、参照先フローの実行が停止し、参照先フローのエラーハンドラーに処理が渡されます。参照先フローでエラーハンドラーが設定されていない場合は、Flow Reference コールを含むフローまでエラーが伝播され、このフローで設定されている Error Handler コンポーネントでエラーが処理されます。 エラーが発生した場合は、フローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#flow-reference-の-xml-例)Flow Reference の XML 例 次の XML コードは、​[Flow Reference の設定](#configure-flow-ref)​で作成したプロジェクトを表しており、Flow Reference コンポーネントがコールした 2 つ目のフローの結果を格納するための対象変数 ​`flowReferenceVar,`​ が追加されています。この変数は、​`vars.flowReferenceVar`​ のログを記録することで、メインフローでも使用されます。 ```xml ``` 次のログは、アプリケーション例の実行後の出力を表しています。 INFO LoggerMessageProcessor: Payload = Original payload INFO LoggerMessageProcessor: myVar = 1 INFO LoggerMessageProcessor: flowReferenceVar = Modified payload Flow Reference コンポーネントから ​`target="flowReferenceVar"`​ を削除すると、アプリケーションは次の出力を返します。 INFO LoggerMessageProcessor: Payload = Modified payload INFO LoggerMessageProcessor: myVar = 2 INFO LoggerMessageProcessor: flowReferenceVar = null ログは、読みやすいように省略されています。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-event) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.9/target-variables) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management#tx_scopes_routers) # Flow および Subflow スコープ Flow スコープと Subflow スコープは、他の一連のコアコンポーネントと操作 (コネクタとモジュールによって提供される) をグループ化するコンポーネントで、インテグレーションプロセスの自動化に役立ちます。Flow コンポーネントは、Mule アプリケーションの基盤です。すべての Mule アプリケーションには少なくとも 1 つのフローを含める必要があるため、Anypoint Studio ではアプリケーション内に最初の Flow コンポーネントが自動的に提供されます。 Mule アプリケーションには、追加のフローとサブフローを含めることができます。次に例を示します。 ![フローとサブフローの例](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/component-flow-subflow.png) Figure 1. 例: フローとサブフロー フローとサブフローの仕様、機能、制限についての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-flows)​を参照してください。 フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期パターンを実現する必要がある場合は、​[Async スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/async-scope-reference)​ (​``​) を使用できます。 ## [](#フローの設定)フローの設定 フローは設定可能です。たとえば、Mule アプリケーションの起動時に開始するか停止したままにするかを設定したり、同時に実行できる数を制限したり、ビジネスイベントをセットアップしたりできます。また、コンポーネントのエラー処理をセットアップすることもできます (​[エラー処理](#error_handling)​参照)。
項目 説明

Name (名前) (​name​)

フローの名前。フローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

Initial State (初期状態) (​initialState​)

値: Started (開始済み)、Stopped (停止済み)。これらは、フローの Mule Runtime 設定です。デフォルトの Started (開始済み) (​initialState="started"​、Studio では [Empty (空)] とも呼ばれる) は、アプリケーションの起動時にフローがアクティブであることを示します。そのため、フロー内の内部または外部イベント取得元 (HTTP リスナーやスケジューラーなど)、別のフローやサブフローからのフロー参照、または ​lookup​ 関数のコールによってトリガーできます。

初期状態を Stopped (停止済み) (​initialState="stopped"​) に設定した場合は、フローをアクティブ化するには ​Runtime Manager​ を使用する必要があります。または、単にフロー設定を ​Started​ にリセットすることもできます。この状態のコンソール出力は次のようになります: Flow flow_component_ex has not been started (initial state = 'stopped')

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。フローが処理できる同時メッセージの最大数を設定します。設定しない場合、フローがメッセージの処理時にパフォーマンスを最適化するために使用できる最大スレッド数は、コンテナスレッドプールによって異なります。フローが最大数の同時メッセージを処理している間は追加要求を受信できません。

フローが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャー​」を参照してください。

ビジネスイベント

省略可能。デフォルトは ​false​ です。Mule アプリケーションを CloudHub にデプロイする場合は、ビジネスイベントを有効にし (XML の例: tracking:enable-default-event="true"​)、トランザクション ID を追加できます (XML の例: <tracking:transaction id=12345​/>)。​「ビジネスイベント」​を参照してください。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータを設定できます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#サブフローの設定)サブフローの設定 Subflow スコープでは、サブフローの名前を編集し、メタデータを追加できます。フローとは異なり、サブフローにはエラー処理をセットアップするメカニズムは組み込まれていません。ただし、エラー処理を実行する必要がある場合は、サブフロー内の ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept)​によって提供されるエラー処理を使用できます。
項目 説明

Name (名前) (​name​)

サブフローの名前。サブフローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータをセットアップできます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#フローとサブフローの-xml)フローとサブフローの XML 次の例は、シンプルなフロー (​``​) の XML です。このフローは、10 秒ごとにフローの実行をトリガーするスケジューラーを取得元として使用し、Flow Ref (​``​) コンポーネントを介してサブフロー (​``​) に接続します。そのサブフローも、Flow Ref コンポーネントを使用して別のサブフローに接続します。Studio の UI を使用してコンポーネントを設定すると、Mule アプリケーションの設定 XML に自動的に XML が追加されます。 例: フローとサブフローの XML ```xml 9.99 53 398.99 ', 'application/xml') output application/xml --- myXml ]]> { (key) : { dollars: value, localCurrency: value * conversionRate, index_plus_1: index + 1, timer : currentMilliseconds() } }]]> ``` この例の出力は次のようになります。 出力 ```json { "priceList": { "basic": { "dollars": "9.99", "localCurrency": 129.87, "index_plus_1": 1, "timer": 1533024312658 }, "premium": { "dollars": "53", "localCurrency": 689, "index_plus_1": 2, "timer": 1533024312659 }, "vip": { "dollars": "398.99", "localCurrency": 5186.87, "index_plus_1": 3, "timer": 1533024312659 } } } ``` ## [](#error_handling)エラー処理 Flow コンポーネントに​[エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling)​を追加できます (サブフローには追加できません)。 Studio では、Flow コンポーネントの下部にある \[Error handling (エラー処理)\] 領域を展開し、エラーコンポーネントをフローにドラッグするだけです。このプロセスにより、Error Handler コンポーネントにコンポーネントが自動的に配置されるため、最初に Error Handler コンポーネントを追加する必要はありません。 この XML 例の末尾付近で、フローの On Error Continue (エラー時継続) 設定 (​``​) があります 例: On Error Continue (エラー時継続) 設定が含まれるフローの XML ```xml ', 'application/xml') output application/xml --- myXml ]]> ``` 前の例では、エラーが発生します。次の点を確認してください。 1. ``​ の変数 ​`var myXml`​ は、ペイロードとして空の ​``​ タグを設定します。 2. ``​ コンポーネントの横にある Logger は、空のタグの値を記録するように設定されているため、​`null`​ を返します。 3. DataWeave 条件 ​`isEmpty(payload.prices)`​ が ​`true`​ を返すため、​``​ コンポーネントはエラーを返します。 4. ``​ 内の Logger (​``​) では、エラーが発生したときにコンソールに出力するエラーメッセージを設定します。結果のエラーメッセージは次のようになります。 ```text ERROR 2018-07-30 23:58:45,293 [[MuleRuntime].cpuLight.06: [flow_subflow].flow_subflowFlow.CPU_LITE @1b1529b2] [event: 0-2aba3280-948f-11e8-82d0-f45c898f2549] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: "An Error Occurred" ``` これらのコンポーネントについての詳細は、​[「On-Error エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.3/on-error-scope-concept)​を参照してください。 ## [](#関連情報)関連情報 - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-backpressure-maxconcurrency) # Flow および Subflow スコープ Flow スコープと Subflow スコープは、他の一連のコアコンポーネントと操作 (コネクタとモジュールによって提供される) をグループ化するコンポーネントで、インテグレーションプロセスの自動化に役立ちます。Flow コンポーネントは、Mule アプリケーションの基盤です。すべての Mule アプリケーションには少なくとも 1 つのフローを含める必要があるため、Anypoint Studio ではアプリケーション内に最初の Flow コンポーネントが自動的に提供されます。 Mule アプリケーションには、追加のフローとサブフローを含めることができます。次に例を示します。 ![フローとサブフローの例](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/component-flow-subflow.png) Figure 1. 例: フローとサブフロー フローとサブフローの仕様、機能、制限についての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-flows)​を参照してください。 フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期パターンを実現する必要がある場合は、​[Async スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/async-scope-reference)​ (​``​) を使用できます。 ## [](#フローの設定)フローの設定 フローは設定可能です。たとえば、Mule アプリケーションの起動時に開始するか停止したままにするかを設定したり、同時に実行できる数を制限したり、ビジネスイベントをセットアップしたりできます。また、コンポーネントのエラー処理をセットアップすることもできます (​[エラー処理](#error_handling)​参照)。
項目 説明

Name (名前) (​name​)

フローの名前。フローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

Initial State (初期状態) (​initialState​)

値: Started (開始済み)、Stopped (停止済み)。これらは、フローの Mule Runtime 設定です。デフォルトの Started (開始済み) (​initialState="started"​、Studio では [Empty (空)] とも呼ばれる) は、アプリケーションの起動時にフローがアクティブであることを示します。そのため、フロー内の内部または外部 Mule イベントソース (HTTP リスナーや Scheduler など)、別のフローやサブフローからのフロー参照、または ​lookup​ 関数のコールによってトリガーできます。

初期状態を Stopped (停止済み) (​initialState="stopped"​) に設定した場合は、フローをアクティブ化するには ​Runtime Manager​ を使用する必要があります。または、単にフロー設定を ​Started​ にリセットすることもできます。この状態のコンソール出力は次のようになります: Flow flow_component_ex has not been started (initial state = 'stopped')

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。フローが処理できる同時メッセージの最大数を設定します。設定しない場合、フローがメッセージの処理時にパフォーマンスを最適化するために使用できる最大スレッド数は、コンテナスレッドプールによって異なります。フローが最大数の同時メッセージを処理している間は追加要求を受信できません。

フローが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャー​」を参照してください。

ビジネスイベント

省略可能。デフォルトは ​false​ です。Mule アプリケーションを CloudHub にデプロイする場合は、ビジネスイベントを有効にし (XML の例: tracking:enable-default-event="true"​)、トランザクション ID を追加できます (XML の例: <tracking:transaction id=12345​/>)。​「ビジネスイベント」​を参照してください。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータを設定できます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#サブフローの設定)サブフローの設定 Subflow スコープでは、サブフローの名前を編集し、メタデータを追加できます。フローとは異なり、サブフローにはエラー処理をセットアップするメカニズムは組み込まれていません。ただし、エラー処理を実行する必要がある場合は、サブフロー内の ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept)​によって提供されるエラー処理を使用できます。
項目 説明

Name (名前) (​name​)

サブフローの名前。サブフローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータをセットアップできます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#フローとサブフローの-xml)フローとサブフローの XML 次の例は、シンプルなフロー (​``​) の XML です。このフローは、10 秒ごとにフローの実行をトリガーするスケジューラーを取得元として使用し、Flow Ref (​``​) コンポーネントを介してサブフロー (​``​) に接続します。そのサブフローも、Flow Ref コンポーネントを使用して別のサブフローに接続します。Studio の UI を使用してコンポーネントを設定すると、Mule アプリケーションの設定 XML に自動的に XML が追加されます。 例: フローとサブフローの XML ```xml 9.99 53 398.99 ', 'application/xml') output application/xml --- myXml ]]> { (key) : { dollars: value, localCurrency: value * conversionRate, index_plus_1: index + 1, timer : currentMilliseconds() } }]]> ``` この例の出力は次のようになります。 出力 ```json { "priceList": { "basic": { "dollars": "9.99", "localCurrency": 129.87, "index_plus_1": 1, "timer": 1533024312658 }, "premium": { "dollars": "53", "localCurrency": 689, "index_plus_1": 2, "timer": 1533024312659 }, "vip": { "dollars": "398.99", "localCurrency": 5186.87, "index_plus_1": 3, "timer": 1533024312659 } } } ``` ## [](#error_handling)エラー処理 Flow コンポーネントに​[エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling)​を追加できます (サブフローには追加できません)。 Studio では、Flow コンポーネントの下部にある \[Error handling (エラー処理)\] 領域を展開し、エラーコンポーネントをフローにドラッグするだけです。このプロセスにより、Error Handler コンポーネントにコンポーネントが自動的に配置されるため、最初に Error Handler コンポーネントを追加する必要はありません。 この XML 例の末尾付近で、フローの On Error Continue (エラー時継続) 設定 (​``​) があります 例: On Error Continue (エラー時継続) 設定が含まれるフローの XML ```xml ', 'application/xml') output application/xml --- myXml ]]> ``` 前の例では、エラーが発生します。次の点を確認してください。 1. ``​ の変数 ​`var myXml`​ は、ペイロードとして空の ​``​ タグを設定します。 2. ``​ コンポーネントの横にある Logger は、空のタグの値を記録するように設定されているため、​`null`​ を返します。 3. DataWeave 条件 ​`isEmpty(payload.prices)`​ が ​`true`​ を返すため、​``​ コンポーネントはエラーを返します。 4. ``​ 内の Logger (​``​) では、エラーが発生したときにコンソールに出力するエラーメッセージを設定します。結果のエラーメッセージは次のようになります。 ```text ERROR 2018-07-30 23:58:45,293 [[MuleRuntime].cpuLight.06: [flow_subflow].flow_subflowFlow.CPU_LITE @1b1529b2] [event: 0-2aba3280-948f-11e8-82d0-f45c898f2549] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: "An Error Occurred" ``` これらのコンポーネントについての詳細は、​[「On-Error エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.4/on-error-scope-concept)​を参照してください。 ## [](#関連情報)関連情報 - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-backpressure-maxconcurrency) # Flow および Subflow スコープ Flow スコープと Subflow スコープは、他の一連のコアコンポーネントと操作 (コネクタとモジュールによって提供される) をグループ化するコンポーネントで、インテグレーションプロセスの自動化に役立ちます。Flow コンポーネントは、Mule アプリケーションの基盤です。すべての Mule アプリケーションには少なくとも 1 つのフローを含める必要があるため、Anypoint Studio ではアプリケーション内に最初の Flow コンポーネントが自動的に提供されます。 Mule アプリケーションには、追加のフローとサブフローを含めることができます。次に例を示します。 ![フローとサブフローの例](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/component-flow-subflow.png) Figure 1. 例: フローとサブフロー フローとサブフローの仕様、機能、制限についての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-flows)​を参照してください。 フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期パターンを実現する必要がある場合は、​[Async スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/async-scope-reference)​ (​``​) を使用できます。 ## [](#フローの設定)フローの設定 フローは設定可能です。たとえば、Mule アプリケーションの起動時に開始するか停止したままにするかを設定したり、同時に実行できる数を制限したり、ビジネスイベントをセットアップしたりできます。また、コンポーネントのエラー処理をセットアップすることもできます (​[エラー処理](#error_handling)​参照)。
項目 説明

Name (名前) (​name​)

フローの名前。フローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

Initial State (初期状態) (​initialState​)

値: Started (開始済み)、Stopped (停止済み)。これらは、フローの Mule Runtime 設定です。デフォルトの Started (開始済み) (​initialState="started"​、Studio では [Empty (空)] とも呼ばれる) は、アプリケーションの起動時にフローがアクティブであることを示します。そのため、フロー内の内部または外部 Mule イベントソース (HTTP リスナーや Scheduler など)、別のフローやサブフローからのフロー参照、または ​lookup​ 関数のコールによってトリガーできます。

初期状態を Stopped (停止済み) (​initialState="stopped"​) に設定した場合は、フローをアクティブ化するには ​Runtime Manager​ を使用する必要があります。または、単にフロー設定を ​Started​ にリセットすることもできます。この状態のコンソール出力は次のようになります: Flow flow_component_ex has not been started (initial state = 'stopped')

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。フローが処理できる同時メッセージの最大数を設定します。設定しない場合、フローがメッセージの処理時にパフォーマンスを最適化するために使用できる最大スレッド数は、コンテナスレッドプールによって異なります。フローが最大数の同時メッセージを処理している間は追加要求を受信できません。

フローが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャー​」を参照してください。

ビジネスイベント

省略可能。デフォルトは ​false​ です。Mule アプリケーションを CloudHub にデプロイする場合は、ビジネスイベントを有効にし (XML の例: tracking:enable-default-event="true"​)、トランザクション ID を追加できます (XML の例: <tracking:transaction id=12345​/>)。​「ビジネスイベント」​を参照してください。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータを設定できます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#サブフローの設定)サブフローの設定 Subflow スコープでは、サブフローの名前を編集し、メタデータを追加できます。フローとは異なり、サブフローにはエラー処理をセットアップするメカニズムは組み込まれていません。ただし、エラー処理を実行する必要がある場合は、サブフロー内の ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept)​によって提供されるエラー処理を使用できます。
項目 説明

Name (名前) (​name​)

サブフローの名前。サブフローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータをセットアップできます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#フローとサブフローの-xml)フローとサブフローの XML 次の例は、シンプルなフロー (​``​) の XML です。このフローは、10 秒ごとにフローの実行をトリガーするスケジューラーを取得元として使用し、Flow Ref (​``​) コンポーネントを介してサブフロー (​``​) に接続します。そのサブフローも、Flow Ref コンポーネントを使用して別のサブフローに接続します。Studio の UI を使用してコンポーネントを設定すると、Mule アプリケーションの設定 XML に自動的に XML が追加されます。 例: フローとサブフローの XML ```xml 9.99 53 398.99 ', 'application/xml') output application/xml --- myXml ]]> { (key) : { dollars: value, localCurrency: value * conversionRate, index_plus_1: index + 1, timer : currentMilliseconds() } }]]> ``` この例の出力は次のようになります。 出力 ```json { "priceList": { "basic": { "dollars": "9.99", "localCurrency": 129.87, "index_plus_1": 1, "timer": 1533024312658 }, "premium": { "dollars": "53", "localCurrency": 689, "index_plus_1": 2, "timer": 1533024312659 }, "vip": { "dollars": "398.99", "localCurrency": 5186.87, "index_plus_1": 3, "timer": 1533024312659 } } } ``` ## [](#error_handling)エラー処理 Flow コンポーネントに​[エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling)​を追加できます (サブフローには追加できません)。 Studio では、Flow コンポーネントの下部にある \[Error handling (エラー処理)\] 領域を展開し、エラーコンポーネントをフローにドラッグするだけです。このプロセスにより、Error Handler コンポーネントにコンポーネントが自動的に配置されるため、最初に Error Handler コンポーネントを追加する必要はありません。 この XML 例の末尾付近で、フローの On Error Continue (エラー時継続) 設定 (​``​) があります 例: On Error Continue (エラー時継続) 設定が含まれるフローの XML ```xml ', 'application/xml') output application/xml --- myXml ]]> ``` 前の例では、エラーが発生します。次の点を確認してください。 1. ``​ の変数 ​`var myXml`​ は、ペイロードとして空の ​``​ タグを設定します。 2. ``​ コンポーネントの横にある Logger は、空のタグの値を記録するように設定されているため、​`null`​ を返します。 3. DataWeave 条件 ​`isEmpty(payload.prices)`​ が ​`true`​ を返すため、​``​ コンポーネントはエラーを返します。 4. ``​ 内の Logger (​``​) では、エラーが発生したときにコンソールに出力するエラーメッセージを設定します。結果のエラーメッセージは次のようになります。 ```text ERROR 2018-07-30 23:58:45,293 [[MuleRuntime].cpuLight.06: [flow_subflow].flow_subflowFlow.CPU_LITE @1b1529b2] [event: 0-2aba3280-948f-11e8-82d0-f45c898f2549] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: "An Error Occurred" ``` これらのコンポーネントについての詳細は、​[「On-Error エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.5/on-error-scope-concept)​を参照してください。 ## [](#関連情報)関連情報 - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-backpressure-maxconcurrency) # Flow および Subflow スコープ Flow スコープと Subflow スコープは、他の一連のコアコンポーネントと操作 (コネクタとモジュールによって提供される) をグループ化するコンポーネントで、インテグレーションプロセスの自動化に役立ちます。Flow コンポーネントは、Mule アプリケーションの基盤です。すべての Mule アプリケーションには少なくとも 1 つのフローを含める必要があるため、Anypoint Studio ではアプリケーション内に最初の Flow コンポーネントが自動的に提供されます。 Mule アプリケーションには、追加のフローとサブフローを含めることができます。次に例を示します。 ![フローとサブフローの例](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/component-flow-subflow.png) Figure 1. 例: フローとサブフロー フローとサブフローの仕様、機能、制限についての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-flows)​を参照してください。 フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期パターンを実現する必要がある場合は、​[Async スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/async-scope-reference)​ (​``​) を使用できます。 ## [](#フローの設定)フローの設定 フローは設定可能です。たとえば、Mule アプリケーションの起動時に開始するか停止したままにするかを設定したり、同時に実行できる数を制限したり、ビジネスイベントをセットアップしたりできます。また、コンポーネントのエラー処理をセットアップすることもできます (​[エラー処理](#error_handling)​参照)。
項目 説明

Name (名前) (​name​)

フローの名前。フローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

Initial State (初期状態) (​initialState​)

値: Started (開始済み)、Stopped (停止済み)。これらは、フローの Mule Runtime 設定です。デフォルトの Started (開始済み) (​initialState="started"​、Studio では [Empty (空)] とも呼ばれる) は、アプリケーションの起動時にフローがアクティブであることを示します。そのため、フロー内の内部または外部 Mule イベントソース (HTTP リスナーや Scheduler など)、別のフローやサブフローからのフロー参照、または ​lookup​ 関数のコールによってトリガーできます。

初期状態を Stopped (停止済み) (​initialState="stopped"​) に設定した場合は、フローをアクティブ化するには ​Runtime Manager​ を使用する必要があります。または、単にフロー設定を ​Started​ にリセットすることもできます。この状態のコンソール出力は次のようになります: Flow flow_component_ex has not been started (initial state = 'stopped')

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。フローが処理できる同時メッセージの最大数を設定します。設定しない場合、フローがメッセージの処理時にパフォーマンスを最適化するために使用できる最大スレッド数は、コンテナスレッドプールによって異なります。フローが最大数の同時メッセージを処理している間は追加要求を受信できません。

フローが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、「​バックプレッシャー​」を参照してください。

ビジネスイベント

省略可能。デフォルトは ​false​ です。Mule アプリケーションを CloudHub にデプロイする場合は、ビジネスイベントを有効にし (XML の例: tracking:enable-default-event="true"​)、トランザクション ID を追加できます (XML の例: <tracking:transaction id=12345​/>)。​「ビジネスイベント」​を参照してください。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータを設定できます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#サブフローの設定)サブフローの設定 Subflow スコープでは、サブフローの名前を編集し、メタデータを追加できます。フローとは異なり、サブフローにはエラー処理をセットアップするメカニズムは組み込まれていません。ただし、エラー処理を実行する必要がある場合は、サブフロー内の ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept)​によって提供されるエラー処理を使用できます。
項目 説明

Name (名前) (​name​)

サブフローの名前。サブフローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータをセットアップできます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#フローとサブフローの-xml)フローとサブフローの XML 次の例は、シンプルなフロー (​``​) の XML です。このフローは、10 秒ごとにフローの実行をトリガーするスケジューラーを取得元として使用し、Flow Ref (​``​) コンポーネントを介してサブフロー (​``​) に接続します。そのサブフローも、Flow Ref コンポーネントを使用して別のサブフローに接続します。Studio の UI を使用してコンポーネントを設定すると、Mule アプリケーションの設定 XML に自動的に XML が追加されます。 例: フローとサブフローの XML ```xml 9.99 53 398.99 ', 'application/xml') output application/xml --- myXml ]]> { (key) : { dollars: value, localCurrency: value * conversionRate, index_plus_1: index + 1, timer : currentMilliseconds() } }]]> ``` この例の出力は次のようになります。 出力 ```json { "priceList": { "basic": { "dollars": "9.99", "localCurrency": 129.87, "index_plus_1": 1, "timer": 1533024312658 }, "premium": { "dollars": "53", "localCurrency": 689, "index_plus_1": 2, "timer": 1533024312659 }, "vip": { "dollars": "398.99", "localCurrency": 5186.87, "index_plus_1": 3, "timer": 1533024312659 } } } ``` ## [](#error_handling)エラー処理 Flow コンポーネントに​[エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling)​を追加できます (サブフローには追加できません)。 Studio では、Flow コンポーネントの下部にある \[Error handling (エラー処理)\] 領域を展開し、エラーコンポーネントをフローにドラッグするだけです。このプロセスにより、Error Handler コンポーネントにコンポーネントが自動的に配置されるため、最初に Error Handler コンポーネントを追加する必要はありません。 この XML 例の末尾付近で、フローの On Error Continue (エラー時継続) 設定 (​``​) があります 例: On Error Continue (エラー時継続) 設定が含まれるフローの XML ```xml ', 'application/xml') output application/xml --- myXml ]]> ``` 前の例では、エラーが発生します。次の点を確認してください。 1. ``​ の変数 ​`var myXml`​ は、ペイロードとして空の ​``​ タグを設定します。 2. ``​ コンポーネントの横にある Logger は、空のタグの値を記録するように設定されているため、​`null`​ を返します。 3. DataWeave 条件 ​`isEmpty(payload.prices)`​ が ​`true`​ を返すため、​``​ コンポーネントはエラーを返します。 4. ``​ 内の Logger (​``​) では、エラーが発生したときにコンソールに出力するエラーメッセージを設定します。結果のエラーメッセージは次のようになります。 ```text ERROR 2018-07-30 23:58:45,293 [[MuleRuntime].cpuLight.06: [flow_subflow].flow_subflowFlow.CPU_LITE @1b1529b2] [event: 0-2aba3280-948f-11e8-82d0-f45c898f2549] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: "An Error Occurred" ``` これらのコンポーネントについての詳細は、​[「On-Error エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.6/on-error-scope-concept)​を参照してください。 ## [](#関連情報)関連情報 - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-backpressure-maxconcurrency) # Flow および Subflow スコープ Flow スコープと Subflow スコープは、他の一連のコアコンポーネントと操作 (コネクタとモジュールによって提供される) をグループ化するコンポーネントで、インテグレーションプロセスの自動化に役立ちます。Flow コンポーネントは、Mule アプリケーションの基盤です。すべての Mule アプリケーションには少なくとも 1 つのフローを含める必要があるため、Anypoint Studio ではアプリケーション内に最初の Flow コンポーネントが自動的に提供されます。 Mule アプリケーションには、追加のフローとサブフローを含めることができます。次に例を示します。 ![Anypoint Studio の Scheduler、Error handling、および複数のサブフロー参照が含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/component-flow-subflow.png) Figure 1. 例: フローとサブフロー フローとサブフローの仕様、機能、制限についての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-flows)​を参照してください。 フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期パターンを実現する必要がある場合は、​[Async スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/async-scope-reference)​ (​``​) を使用できます。 ## [](#フローの設定)フローの設定 フローは設定可能です。たとえば、Mule アプリケーションの起動時に開始するか停止したままにするかを設定したり、同時に実行できる数を制限したり、ビジネスイベントをセットアップしたりできます。また、コンポーネントのエラー処理をセットアップすることもできます (​[エラー処理](#error_handling)​参照)。
項目 説明

Name (名前) (​name​)

フローの名前。フローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

Initial State (初期状態) (​initialState​)

値: Started (開始済み)、Stopped (停止済み)。これらは、フローの Mule Runtime 設定です。デフォルトの Started (開始済み) (​initialState="started"​、Studio では [Empty (空)] とも呼ばれる) は、アプリケーションの起動時にフローがアクティブであることを示します。そのため、フロー内の内部または外部 Mule イベントソース (HTTP リスナーや Scheduler など)、別のフローやサブフローからのフロー参照、または ​lookup​ 関数のコールによってトリガーできます。

初期状態を Stopped (停止済み) (​initialState="stopped"​) に設定した場合は、フローをアクティブ化するには ​Runtime Manager​ を使用する必要があります。または、単にフロー設定を ​Started​ にリセットすることもできます。この状態のコンソール出力は次のようになります: Flow flow_component_ex has not been started (initial state = 'stopped')

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。フローが処理できる同時メッセージの最大数を設定します。設定しない場合、フローがメッセージの処理時にパフォーマンスを最適化するために使用できる最大スレッド数は、コンテナスレッドプールによって異なります。フローが最大数の同時メッセージを処理している間は追加要求を受信できません。

フローが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、​「バックプレッシャー」​を参照してください。

ビジネスイベント

省略可能。デフォルトは ​false​ です。Mule アプリケーションを CloudHub にデプロイする場合は、ビジネスイベントを有効にし (XML の例: tracking:enable-default-event="true"​)、トランザクション ID を追加できます (XML の例: <tracking:transaction id=12345​/>)。​「ビジネスイベント」​を参照してください。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータを設定できます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#サブフローの設定)サブフローの設定 Subflow スコープでは、サブフローの名前を編集し、メタデータを追加できます。フローとは異なり、サブフローにはエラー処理をセットアップするメカニズムは組み込まれていません。ただし、エラー処理を実行する必要がある場合は、サブフロー内の ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept)​によって提供されるエラー処理を使用できます。
項目 説明

Name (名前) (​name​)

サブフローの名前。サブフローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータをセットアップできます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#フローとサブフローの-xml)フローとサブフローの XML 次の例は、シンプルなフロー (​``​) の XML です。このフローは、10 秒ごとにフローの実行をトリガーするスケジューラーを取得元として使用し、Flow Ref (​``​) コンポーネントを介してサブフロー (​``​) に接続します。そのサブフローも、Flow Ref コンポーネントを使用して別のサブフローに接続します。Studio の UI を使用してコンポーネントを設定すると、Mule アプリケーションの設定 XML に自動的に XML が追加されます。 例: フローとサブフローの XML ```xml 9.99 53 398.99 ', 'application/xml') output application/xml --- myXml ]]> { (key) : { dollars: value, localCurrency: value * conversionRate, index_plus_1: index + 1, timer : currentMilliseconds() } }]]> ``` この例の出力は次のようになります。 出力 ```json { "priceList": { "basic": { "dollars": "9.99", "localCurrency": 129.87, "index_plus_1": 1, "timer": 1533024312658 }, "premium": { "dollars": "53", "localCurrency": 689, "index_plus_1": 2, "timer": 1533024312659 }, "vip": { "dollars": "398.99", "localCurrency": 5186.87, "index_plus_1": 3, "timer": 1533024312659 } } } ``` ## [](#error_handling)エラー処理 Flow コンポーネントに​[エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling)​を追加できます (サブフローには追加できません)。 Studio では、Flow コンポーネントの下部にある \[Error handling (エラー処理)\] 領域を展開し、エラーコンポーネントをフローにドラッグするだけです。このプロセスにより、Error Handler コンポーネントにコンポーネントが自動的に配置されるため、最初に Error Handler コンポーネントを追加する必要はありません。 この XML 例の末尾付近で、フローの On Error Continue (エラー時継続) 設定 (​``​) があります 例: On Error Continue (エラー時継続) 設定が含まれるフローの XML ```xml ', 'application/xml') output application/xml --- myXml ]]> ``` 前の例では、エラーが発生します。次の点を確認してください。 1. ``​ の変数 ​`var myXml`​ は、ペイロードとして空の ​``​ タグを設定します。 2. ``​ コンポーネントの横にある Logger は、空のタグの値を記録するように設定されているため、​`null`​ を返します。 3. DataWeave 条件 ​`isEmpty(payload.prices)`​ が ​`true`​ を返すため、​``​ コンポーネントはエラーを返します。 4. ``​ 内の Logger (​``​) では、エラーが発生したときにコンソールに出力するエラーメッセージを設定します。結果のエラーメッセージは次のようになります。 ```text ERROR 2018-07-30 23:58:45,293 [[MuleRuntime].cpuLight.06: [flow_subflow].flow_subflowFlow.CPU_LITE @1b1529b2] [event: 0-2aba3280-948f-11e8-82d0-f45c898f2549] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: "An Error Occurred" ``` これらのコンポーネントについての詳細は、​[「On-Error エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.7/on-error-scope-concept)​を参照してください。 ## [](#関連情報)関連情報 - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-backpressure-maxconcurrency) # Flow および Subflow スコープ Flow スコープと Subflow スコープは、他の一連のコアコンポーネントと操作 (コネクタとモジュールによって提供される) をグループ化するコンポーネントで、インテグレーションプロセスの自動化に役立ちます。Flow コンポーネントは、Mule アプリケーションの基盤です。すべての Mule アプリケーションには少なくとも 1 つのフローを含める必要があるため、Anypoint Studio ではアプリケーション内に最初の Flow コンポーネントが自動的に提供されます。 Mule アプリケーションには、追加のフローとサブフローを含めることができます。次に例を示します。 ![Anypoint Studio の Scheduler、Error handling、および複数のサブフロー参照が含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/component-flow-subflow.png) Figure 1. 例: フローとサブフロー フローとサブフローの仕様、機能、制限についての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-flows)​を参照してください。 フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期パターンを実現する必要がある場合は、​[Async スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/async-scope-reference)​ (​``​) を使用できます。 ## [](#フローの設定)フローの設定 フローは設定可能です。たとえば、Mule アプリケーションの起動時に開始するか停止したままにするかを設定したり、同時に実行できる数を制限したり、ビジネスイベントをセットアップしたりできます。また、コンポーネントのエラー処理をセットアップすることもできます (​[エラー処理](#error_handling)​参照)。
項目 説明

Name (名前) (​name​)

フローの名前。フローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

Initial State (初期状態) (​initialState​)

値: Started (開始済み)、Stopped (停止済み)。これらは、フローの Mule Runtime 設定です。デフォルトの Started (開始済み) (​initialState="started"​、Studio では [Empty (空)] とも呼ばれる) は、アプリケーションの起動時にフローがアクティブであることを示します。そのため、フロー内の内部または外部 Mule イベントソース (HTTP リスナーや Scheduler など)、別のフローやサブフローからのフロー参照、または ​lookup​ 関数のコールによってトリガーできます。

初期状態を Stopped (停止済み) (​initialState="stopped"​) に設定した場合は、フローをアクティブ化するには ​Runtime Manager​ を使用する必要があります。または、単にフロー設定を ​Started​ にリセットすることもできます。この状態のコンソール出力は次のようになります: Flow flow_component_ex has not been started (initial state = 'stopped')

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。フローが処理できる同時メッセージの最大数を設定します。設定しない場合、フローがメッセージの処理時にパフォーマンスを最適化するために使用できる最大スレッド数は、コンテナスレッドプールによって異なります。フローが最大数の同時メッセージを処理している間は追加要求を受信できません。

フローが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、​「バックプレッシャー」​を参照してください。

ビジネスイベント

省略可能。デフォルトは ​false​ です。Mule アプリケーションを CloudHub にデプロイする場合は、ビジネスイベントを有効にし (XML の例: tracking:enable-default-event="true"​)、トランザクション ID を追加できます (XML の例: <tracking:transaction id=12345​/>)。​「ビジネスイベント」​を参照してください。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータを設定できます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#サブフローの設定)サブフローの設定 Subflow スコープでは、サブフローの名前を編集し、メタデータを追加できます。フローとは異なり、サブフローにはエラー処理をセットアップするメカニズムは組み込まれていません。ただし、エラー処理を実行する必要がある場合は、サブフロー内の ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept)​によって提供されるエラー処理を使用できます。
項目 説明

Name (名前) (​name​)

サブフローの名前。サブフローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータをセットアップできます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#フローとサブフローの-xml)フローとサブフローの XML 次の例は、シンプルなフロー (​``​) の XML です。このフローは、10 秒ごとにフローの実行をトリガーするスケジューラーを取得元として使用し、Flow Ref (​``​) コンポーネントを介してサブフロー (​``​) に接続します。そのサブフローも、Flow Ref コンポーネントを使用して別のサブフローに接続します。Studio の UI を使用してコンポーネントを設定すると、Mule アプリケーションの設定 XML に自動的に XML が追加されます。 例: フローとサブフローの XML ```xml 9.99 53 398.99 ', 'application/xml') output application/xml --- myXml ]]> { (key) : { dollars: value, localCurrency: value * conversionRate, index_plus_1: index + 1, timer : currentMilliseconds() } }]]> ``` この例の出力は次のようになります。 出力 ```json { "priceList": { "basic": { "dollars": "9.99", "localCurrency": 129.87, "index_plus_1": 1, "timer": 1533024312658 }, "premium": { "dollars": "53", "localCurrency": 689, "index_plus_1": 2, "timer": 1533024312659 }, "vip": { "dollars": "398.99", "localCurrency": 5186.87, "index_plus_1": 3, "timer": 1533024312659 } } } ``` ## [](#error_handling)エラー処理 Flow コンポーネントに​[エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling)​を追加できます (サブフローには追加できません)。 Studio では、Flow コンポーネントの下部にある \[Error handling (エラー処理)\] 領域を展開し、エラーコンポーネントをフローにドラッグするだけです。このプロセスにより、Error Handler コンポーネントにコンポーネントが自動的に配置されるため、最初に Error Handler コンポーネントを追加する必要はありません。 この XML 例の末尾付近で、フローの On Error Continue (エラー時継続) 設定 (​``​) があります 例: On Error Continue (エラー時継続) 設定が含まれるフローの XML ```xml ', 'application/xml') output application/xml --- myXml ]]> ``` 前の例では、エラーが発生します。次の点を確認してください。 1. ``​ の変数 ​`var myXml`​ は、ペイロードとして空の ​``​ タグを設定します。 2. ``​ コンポーネントの横にある Logger は、空のタグの値を記録するように設定されているため、​`null`​ を返します。 3. DataWeave 条件 ​`isEmpty(payload.prices)`​ が ​`true`​ を返すため、​``​ コンポーネントはエラーを返します。 4. ``​ 内の Logger (​``​) では、エラーが発生したときにコンソールに出力するエラーメッセージを設定します。結果のエラーメッセージは次のようになります。 ```text ERROR 2018-07-30 23:58:45,293 [[MuleRuntime].cpuLight.06: [flow_subflow].flow_subflowFlow.CPU_LITE @1b1529b2] [event: 0-2aba3280-948f-11e8-82d0-f45c898f2549] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: "An Error Occurred" ``` これらのコンポーネントについての詳細は、​[「On-Error エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.8/on-error-scope-concept)​を参照してください。 ## [](#関連情報)関連情報 - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-backpressure-maxconcurrency) # Flow および Subflow スコープ Flow スコープと Subflow スコープは、他の一連のコアコンポーネントと操作 (コネクタとモジュールによって提供される) をグループ化するコンポーネントで、インテグレーションプロセスの自動化に役立ちます。Flow コンポーネントは、Mule アプリケーションの基盤です。すべての Mule アプリケーションには少なくとも 1 つのフローを含める必要があるため、Anypoint Studio ではアプリケーション内に最初の Flow コンポーネントが自動的に提供されます。 Mule アプリケーションには、追加のフローとサブフローを含めることができます。次に例を示します。 ![Anypoint Studio の Scheduler、Error handling、および複数のサブフロー参照が含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/component-flow-subflow.png) Figure 1. 例: フローとサブフロー フローとサブフローの仕様、機能、制限についての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-flows)​を参照してください。 フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期パターンを実現する必要がある場合は、​[Async スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/async-scope-reference)​ (​``​) を使用できます。 ## [](#フローの設定)フローの設定 フローは設定可能です。たとえば、Mule アプリケーションの起動時に開始するか停止したままにするかを設定したり、同時に実行できる数を制限したり、ビジネスイベントをセットアップしたりできます。また、コンポーネントのエラー処理をセットアップすることもできます (​[エラー処理](#error_handling)​参照)。
項目 説明

Name (名前) (​name​)

フローの名前。フローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

Initial State (初期状態) (​initialState​)

値: Started (開始済み)、Stopped (停止済み)。これらは、フローの Mule Runtime 設定です。デフォルトの Started (開始済み) (​initialState="started"​、Studio では [Empty (空)] とも呼ばれる) は、アプリケーションの起動時にフローがアクティブであることを示します。そのため、フロー内の内部または外部 Mule イベントソース (HTTP リスナーや Scheduler など)、別のフローやサブフローからのフロー参照、または ​lookup​ 関数のコールによってトリガーできます。

初期状態を Stopped (停止済み) (​initialState="stopped"​) に設定した場合は、フローをアクティブ化するには ​Runtime Manager​ を使用する必要があります。または、単にフロー設定を ​Started​ にリセットすることもできます。この状態のコンソール出力は次のようになります: Flow flow_component_ex has not been started (initial state = 'stopped')

Max Concurrency (最大同時実行) (​maxConcurrency​)

省略可能。フローが処理できる同時メッセージの最大数を設定します。設定しない場合、フローがメッセージの処理時にパフォーマンスを最適化するために使用できる最大スレッド数は、コンテナスレッドプールによって異なります。フローが最大数の同時メッセージを処理している間は追加要求を受信できません。

フローが要求を 1 つずつ処理するようにするには、​maxConcurrency​ を ​1​ に設定します。

最大同時実行値に達した後の Mule の動作についての詳細は、​「バックプレッシャー」​を参照してください。

ビジネスイベント

省略可能。デフォルトは ​false​ です。Mule アプリケーションを CloudHub にデプロイする場合は、ビジネスイベントを有効にし (XML の例: tracking:enable-default-event="true"​)、トランザクション ID を追加できます (XML の例: <tracking:transaction id=12345​/>)。​「ビジネスイベント」​を参照してください。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータを設定できます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#サブフローの設定)サブフローの設定 Subflow スコープでは、サブフローの名前を編集し、メタデータを追加できます。フローとは異なり、サブフローにはエラー処理をセットアップするメカニズムは組み込まれていません。ただし、エラー処理を実行する必要がある場合は、サブフロー内の ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept)​によって提供されるエラー処理を使用できます。
項目 説明

Name (名前) (​name​)

サブフローの名前。サブフローには、プロジェクト名と同じ (または部分的に同じ) 編集可能な名前が自動的につけられます。

メタデータ

他の多くのコンポーネントと同様に、このコンポーネントのメタデータをセットアップできます。このトピックについての詳細は、​「Metadata Editor (メタデータエディター)」​を参照してください。
## [](#フローとサブフローの-xml)フローとサブフローの XML 次の例は、シンプルなフロー (​``​) の XML です。このフローは、10 秒ごとにフローの実行をトリガーするスケジューラーを取得元として使用し、Flow Ref (​``​) コンポーネントを介してサブフロー (​``​) に接続します。そのサブフローも、Flow Ref コンポーネントを使用して別のサブフローに接続します。Studio の UI を使用してコンポーネントを設定すると、Mule アプリケーションの設定 XML に自動的に XML が追加されます。 例: フローとサブフローの XML ```xml 9.99 53 398.99 ', 'application/xml') output application/xml --- myXml ]]> { (key) : { dollars: value, localCurrency: value * conversionRate, index_plus_1: index + 1, timer : currentMilliseconds() } }]]> ``` この例の出力は次のようになります。 出力 ```json { "priceList": { "basic": { "dollars": "9.99", "localCurrency": 129.87, "index_plus_1": 1, "timer": 1533024312658 }, "premium": { "dollars": "53", "localCurrency": 689, "index_plus_1": 2, "timer": 1533024312659 }, "vip": { "dollars": "398.99", "localCurrency": 5186.87, "index_plus_1": 3, "timer": 1533024312659 } } } ``` ## [](#error_handling)エラー処理 Flow コンポーネントに​[エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling)​を追加できます (サブフローには追加できません)。 Studio では、Flow コンポーネントの下部にある \[Error handling (エラー処理)\] 領域を展開し、エラーコンポーネントをフローにドラッグするだけです。このプロセスにより、Error Handler コンポーネントにコンポーネントが自動的に配置されるため、最初に Error Handler コンポーネントを追加する必要はありません。 この XML 例の末尾付近で、フローの On Error Continue (エラー時継続) 設定 (​``​) があります 例: On Error Continue (エラー時継続) 設定が含まれるフローの XML ```xml ', 'application/xml') output application/xml --- myXml ]]> ``` 前の例では、エラーが発生します。次の点を確認してください。 1. ``​ の変数 ​`var myXml`​ は、ペイロードとして空の ​``​ タグを設定します。 2. ``​ コンポーネントの横にある Logger は、空のタグの値を記録するように設定されているため、​`null`​ を返します。 3. DataWeave 条件 ​`isEmpty(payload.prices)`​ が ​`true`​ を返すため、​``​ コンポーネントはエラーを返します。 4. ``​ 内の Logger (​``​) では、エラーが発生したときにコンソールに出力するエラーメッセージを設定します。結果のエラーメッセージは次のようになります。 ```text ERROR 2018-07-30 23:58:45,293 [[MuleRuntime].cpuLight.06: [flow_subflow].flow_subflowFlow.CPU_LITE @1b1529b2] [event: 0-2aba3280-948f-11e8-82d0-f45c898f2549] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: "An Error Occurred" ``` これらのコンポーネントについての詳細は、​[「On-Error エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.9/on-error-scope-concept)​を参照してください。 ## [](#関連情報)関連情報 - [back-pressure と maxConcurrency](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-backpressure-maxconcurrency) # For Each スコープ For Each スコープは、ペイロードを要素に分割し、それらを 1 つずつ、スコープ内に配置したコンポーネントで処理します。 これは、ほとんどのプログラミング言語の ​`for-each`​/​`for`​ loop コードブロックに似ており、リストや配列を含め、あらゆるコレクションを処理できます。 コレクションには、サポートされている任意のコンテンツ種別 (​`application/json`​、​`application/java`​、​`application/xml`​ など) を使用できます。 For Each スコープに関する一般的な考慮事項: - デフォルトでは、For Each はペイロードを分割しようとします。ペイロードが単純な Java コレクションであれば、For Each スコープは設定なしでペイロードを分割できます。For Each スコープ内のペイロードは、分割された各要素です。元のメッセージ内の属性は、メッセージ全体に関連するため無視されます。 - For Each によって、現在のペイロードは変更されません。出力ペイロードは入力と同じです。 - XML や JSON など、Java 以外のコレクションの場合は、DataWeave 式を使用してデータを分割します。それには ​**\[Collection (コレクション)\]**​ 項目を使用します。 次の例では、For Each の ​**\[Collection (コレクション)\]**​ 項目は、​`payload.topics`​ に保存された配列に対して反復処理を行うように設定されています。 ![For Each コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/component-foreach-example.png) For Each スコープでは、各反復中にコレクションの各項目が ​`payload`​ に保存されます。 配列をバッチに分割することで、処理時間を短縮することもできます。各バッチは、個別の Mule メッセージとして処理されます。たとえば、コレクションに 200 個の要素があり、​**\[Batch Size (バッチサイズ)\]**​ を ​`50`​ に設定すると、For Each スコープは 50 個の要素から成る 4 つのバッチをそれぞれ個別の Mule メッセージとして反復処理します。 ## [](#サンプル-xml)サンプル XML これは、上述の For Each スコープ設定に基づくサンプル XML です。 ```xml ... ... ``` ## [](#変数の伝播)変数の伝播 For Each スコープの各実行は、ブロックの前回の実行からの変数と値を使用して開始されます。1 つの要素の処理時に作成された新しい変数や既存の変数に加えられた変更は、別の要素の処理中に参照できます。変数へのこれらの変更は、引き続き For Each スコープの外部で使用できます。 ```xml ``` 集約後、変数は次のようになります。 ```json {var1: "var1", var2: "newValue", var3: "otherVal", var4: "val4"} ``` ## [](#エラー処理)エラー処理 コレクション内のいずれかの要素で例外がスローされると、For Each スコープはそのコレクションの処理を停止し、エラーハンドラーを呼び出します。 ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Exchange にはいくつかのサンプルプロジェクトがあり、Anypoint Studio でそれらを開いて For Each スコープの使用方法について詳しく学ぶことができます。 - _Authenticating Salesforce using OAuth2 (OAuth2 を使用した Salesforce の認証)_ - _Import contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Importing a CSV file into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Importing Email Attachments using the POP3 Connector (POP3 Connector を使用したメールの添付ファイルのインポート)_ - _Querying a Database and Attaching Results to an Email (データベースへのクエリ実行とメールへの結果の添付)_ Anypoint Studio でサンプルプロジェクトをダウンロードして開くには、左上隅にある Exchange アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#xml-リファレンス)XML リファレンス For Each スコープの開始と終了には ​``​ タグを使用します。このスコープの影響を受けるコンポーネントは、​``​ タグの子要素として定義されます。 ### [](#設定可能な変数)設定可能な変数
変数 デフォルト 説明

collection

payload

Java コレクション、オブジェクト配列、マップ、または DOM ノードを返す式。

counterVariableName

counter

反復処理を行うメッセージ数を保存する変数の名前。

batchSize

1

コレクションを指定されたサイズのサブコレクションに分割します。たとえば、コレクションに 200 個の要素があり、バッチサイズを 50 に設定すると、50 個の要素から成る 4 つのバッチを処理します。

rootMessageVariableName

rootMessage

親メッセージを保存する変数の名前。親は、分割されていない完全なメッセージです。
## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 [「並列 For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/parallel-foreach-scope)​を参照してください。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-event) - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-message) # For Each スコープ For Each スコープは、ペイロードを要素に分割し、それらを 1 つずつ、スコープ内に配置したコンポーネントで処理します。 これは、ほとんどのプログラミング言語の ​`for-each`​/​`for`​ loop コードブロックに似ており、リストや配列を含め、あらゆるコレクションを処理できます。 コレクションには、サポートされている任意のコンテンツ種別 (​`application/json`​、​`application/java`​、​`application/xml`​ など) を使用できます。 For Each スコープに関する一般的な考慮事項: - デフォルトでは、For Each はペイロードを分割しようとします。ペイロードが単純な Java コレクションであれば、For Each スコープは設定なしでペイロードを分割できます。For Each スコープ内のペイロードは、分割された各要素です。元のメッセージ内の属性は、メッセージ全体に関連するため無視されます。 - For Each によって、現在のペイロードは変更されません。出力ペイロードは入力と同じです。 - XML や JSON など、Java 以外のコレクションの場合は、DataWeave 式を使用してデータを分割します。それには ​**\[Collection (コレクション)\]**​ 項目を使用します。 次の例では、For Each の ​**\[Collection (コレクション)\]**​ 項目は、​`payload.topics`​ に保存された配列に対して反復処理を行うように設定されています。 ![For Each コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/component-foreach-example.png) For Each スコープでは、各反復中にコレクションの各項目が ​`payload`​ に保存されます。 配列をバッチに分割することで、処理時間を短縮することもできます。各バッチは、個別の Mule メッセージとして処理されます。たとえば、コレクションに 200 個の要素があり、​**\[Batch Size (バッチサイズ)\]**​ を ​`50`​ に設定すると、For Each スコープは 50 個の要素から成る 4 つのバッチをそれぞれ個別の Mule メッセージとして反復処理します。 ## [](#サンプル-xml)サンプル XML これは、上述の For Each スコープ設定に基づくサンプル XML です。 ```xml ... ... ``` ## [](#変数の伝播)変数の伝播 For Each スコープの各実行は、ブロックの前回の実行からの変数と値を使用して開始されます。1 つの要素の処理時に作成された新しい変数や既存の変数に加えられた変更は、別の要素の処理中に参照できます。変数へのこれらの変更は、引き続き For Each スコープの外部で使用できます。 ```xml ``` 集約後、変数は次のようになります。 ```json {var1: "var1", var2: "newValue", var3: "otherVal", var4: "val4"} ``` ## [](#エラー処理)エラー処理 コレクション内のいずれかの要素で例外がスローされると、For Each スコープはそのコレクションの処理を停止し、エラーハンドラーを呼び出します。 ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Exchange にはいくつかのサンプルプロジェクトがあり、Anypoint Studio でそれらを開いて For Each スコープの使用方法について詳しく学ぶことができます。 - _Authenticating Salesforce using OAuth2 (OAuth2 を使用した Salesforce の認証)_ - _Import contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Importing a CSV file into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Importing Email Attachments using the POP3 Connector (POP3 Connector を使用したメールの添付ファイルのインポート)_ - _Querying a Database and Attaching Results to an Email (データベースへのクエリ実行とメールへの結果の添付)_ Anypoint Studio でサンプルプロジェクトをダウンロードして開くには、左上隅にある Exchange アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#xml-リファレンス)XML リファレンス For Each スコープの開始と終了には ​``​ タグを使用します。このスコープの影響を受けるコンポーネントは、​``​ タグの子要素として定義されます。 ### [](#設定可能な変数)設定可能な変数
変数 Default (デフォルト) 説明

collection

payload

Java コレクション、オブジェクト配列、マップ、または DOM ノードを返す式。

counterVariableName

counter

反復処理を行うメッセージ数を保存する変数の名前。

batchSize

1

コレクションを指定されたサイズのサブコレクションに分割します。たとえば、コレクションに 200 個の要素があり、バッチサイズを 50 に設定すると、50 個の要素から成る 4 つのバッチを処理します。

rootMessageVariableName

rootMessage

親メッセージを保存する変数の名前。親は、分割されていない完全なメッセージです。
## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 [「並列 For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/parallel-foreach-scope)​を参照してください。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-event) - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-message) # For Each スコープ For Each スコープは、ペイロードを要素に分割し、それらを 1 つずつ、スコープ内に配置したコンポーネントで処理します。 これは、ほとんどのプログラミング言語の ​`for-each`​/​`for`​ loop コードブロックに似ており、リストや配列を含め、あらゆるコレクションを処理できます。 コレクションには、サポートされている任意のコンテンツ種別 (​`application/json`​、​`application/java`​、​`application/xml`​ など) を使用できます。 For Each スコープに関する一般的な考慮事項: - デフォルトでは、For Each はペイロードを分割しようとします。ペイロードが単純な Java コレクションであれば、For Each スコープは設定なしでペイロードを分割できます。For Each スコープ内のペイロードは、分割された各要素です。元のメッセージ内の属性は、メッセージ全体に関連するため無視されます。 - For Each によって、現在のペイロードは変更されません。出力ペイロードは入力と同じです。 - XML や JSON など、Java 以外のコレクションの場合は、DataWeave 式を使用してデータを分割します。それには ​**\[Collection (コレクション)\]**​ 項目を使用します。 次の例では、For Each の ​**\[Collection (コレクション)\]**​ 項目は、​`payload.topics`​ に保存された配列に対して反復処理を行うように設定されています。 ![For Each コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/component-foreach-example.png) For Each スコープでは、各反復中にコレクションの各項目が ​`payload`​ に保存されます。 配列をバッチに分割することで、処理時間を短縮することもできます。各バッチは、個別の Mule メッセージとして処理されます。たとえば、コレクションに 200 個の要素があり、​**\[Batch Size (バッチサイズ)\]**​ を ​`50`​ に設定すると、For Each スコープは 50 個の要素から成る 4 つのバッチをそれぞれ個別の Mule メッセージとして反復処理します。 ## [](#サンプル-xml)サンプル XML これは、上述の For Each スコープ設定に基づくサンプル XML です。 ```xml ... ... ``` ## [](#変数の伝播)変数の伝播 For Each スコープの各実行は、ブロックの前回の実行からの変数と値を使用して開始されます。1 つの要素の処理時に作成された新しい変数や既存の変数に加えられた変更は、別の要素の処理中に参照できます。変数へのこれらの変更は、引き続き For Each スコープの外部で使用できます。 ```xml ``` 集約後、変数は次のようになります。 ```json {var1: "var1", var2: "newValue", var3: "otherVal", var4: "val4"} ``` ## [](#エラー処理)エラー処理 コレクション内のいずれかの要素で例外がスローされると、For Each スコープはそのコレクションの処理を停止し、エラーハンドラーを呼び出します。 ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Exchange にはいくつかのサンプルプロジェクトがあり、Anypoint Studio でそれらを開いて For Each スコープの使用方法について詳しく学ぶことができます。 - _Authenticating Salesforce using OAuth2 (OAuth2 を使用した Salesforce の認証)_ - _Import contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Importing a CSV file into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Importing Email Attachments using the POP3 Connector (POP3 Connector を使用したメールの添付ファイルのインポート)_ - _Querying a Database and Attaching Results to an Email (データベースへのクエリ実行とメールへの結果の添付)_ Anypoint Studio でサンプルプロジェクトをダウンロードして開くには、左上隅にある Exchange アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#xml-リファレンス)XML リファレンス For Each スコープの開始と終了には ​``​ タグを使用します。このスコープの影響を受けるコンポーネントは、​``​ タグの子要素として定義されます。 ### [](#設定可能な変数)設定可能な変数
変数 Default (デフォルト) 説明

collection

payload

Java コレクション、オブジェクト配列、マップ、または DOM ノードを返す式。

counterVariableName

counter

反復処理を行うメッセージ数を保存する変数の名前。

batchSize

1

コレクションを指定されたサイズのサブコレクションに分割します。たとえば、コレクションに 200 個の要素があり、バッチサイズを 50 に設定すると、50 個の要素から成る 4 つのバッチを処理します。

rootMessageVariableName

rootMessage

親メッセージを保存する変数の名前。親は、分割されていない完全なメッセージです。
## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 [「並列 For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/parallel-foreach-scope)​を参照してください。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-event) - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-message) # For Each スコープ For Each スコープは、ペイロードを要素に分割し、それらを 1 つずつ、スコープ内に配置したコンポーネントで処理します。 これは、ほとんどのプログラミング言語の ​`for-each`​/​`for`​ loop コードブロックに似ており、リストや配列を含め、あらゆるコレクションを処理できます。 コレクションには、サポートされている任意のコンテンツ種別 (​`application/json`​、​`application/java`​、​`application/xml`​ など) を使用できます。 For Each スコープに関する一般的な考慮事項: - デフォルトでは、For Each はペイロードを分割しようとします。ペイロードが単純な Java コレクションであれば、For Each スコープは設定なしでペイロードを分割できます。For Each スコープ内のペイロードは、分割された各要素です。元のメッセージ内の属性は、メッセージ全体に関連するため無視されます。 - For Each によって、現在のペイロードは変更されません。出力ペイロードは入力と同じです。 - XML や JSON など、Java 以外のコレクションの場合は、DataWeave 式を使用してデータを分割します。それには ​**\[Collection (コレクション)\]**​ 項目を使用します。 次の例では、For Each の ​**\[Collection (コレクション)\]**​ 項目は、​`payload.topics`​ に保存された配列に対して反復処理を行うように設定されています。 ![For Each コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/component-foreach-example.png) For Each スコープでは、各反復中にコレクションの各項目が ​`payload`​ に保存されます。 配列をバッチに分割することで、処理時間を短縮することもできます。各バッチは、個別の Mule メッセージとして処理されます。たとえば、コレクションに 200 個の要素があり、​**\[Batch Size (バッチサイズ)\]**​ を ​`50`​ に設定すると、For Each スコープは 50 個の要素から成る 4 つのバッチをそれぞれ個別の Mule メッセージとして反復処理します。 ## [](#サンプル-xml)サンプル XML これは、上述の For Each スコープ設定に基づくサンプル XML です。 ```xml ... ... ``` ## [](#変数の伝播)変数の伝播 For Each スコープの各実行は、ブロックの前回の実行からの変数と値を使用して開始されます。1 つの要素の処理時に作成された新しい変数や既存の変数に加えられた変更は、別の要素の処理中に参照できます。変数へのこれらの変更は、引き続き For Each スコープの外部で使用できます。 ```xml ``` 集約後、変数は次のようになります。 ```json {var1: "var1", var2: "newValue", var3: "otherVal", var4: "val4"} ``` ## [](#エラー処理)エラー処理 コレクション内のいずれかの要素で例外がスローされると、For Each スコープはそのコレクションの処理を停止し、エラーハンドラーを呼び出します。 ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Exchange にはいくつかのサンプルプロジェクトがあり、Anypoint Studio でそれらを開いて For Each スコープの使用方法について詳しく学ぶことができます。 - _Authenticating Salesforce using OAuth2 (OAuth2 を使用した Salesforce の認証)_ - _Import contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Importing a CSV file into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Importing Email Attachments using the POP3 Connector (POP3 Connector を使用したメールの添付ファイルのインポート)_ - _Querying a Database and Attaching Results to an Email (データベースへのクエリ実行とメールへの結果の添付)_ Anypoint Studio でサンプルプロジェクトをダウンロードして開くには、左上隅にある Exchange アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#xml-リファレンス)XML リファレンス For Each スコープの開始と終了には ​``​ タグを使用します。このスコープの影響を受けるコンポーネントは、​``​ タグの子要素として定義されます。 ### [](#設定可能な変数)設定可能な変数
変数 Default (デフォルト) 説明

collection

payload

Java コレクション、オブジェクト配列、マップ、または DOM ノードを返す式。

counterVariableName

counter

反復処理を行うメッセージ数を保存する変数の名前。

batchSize

1

コレクションを指定されたサイズのサブコレクションに分割します。たとえば、コレクションに 200 個の要素があり、バッチサイズを 50 に設定すると、50 個の要素から成る 4 つのバッチを処理します。

rootMessageVariableName

rootMessage

親メッセージを保存する変数の名前。親は、分割されていない完全なメッセージです。
## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 [「並列 For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/parallel-foreach-scope)​を参照してください。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-event) - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-message) # For Each スコープ For Each スコープは、ペイロードを要素に分割し、それらを 1 つずつ、スコープ内に配置したコンポーネントで処理します。 これは、ほとんどのプログラミング言語の ​`for-each`​/​`for`​ loop コードブロックに似ており、リストや配列を含め、あらゆるコレクションを処理できます。 コレクションには、サポートされている任意のコンテンツ種別 (​`application/json`​、​`application/java`​、​`application/xml`​ など) を使用できます。 For Each スコープに関する一般的な考慮事項: - デフォルトでは、For Each はペイロードを分割しようとします。ペイロードが単純な Java コレクションであれば、For Each スコープは設定なしでペイロードを分割できます。For Each スコープ内のペイロードは、分割された各要素です。元のメッセージ内の属性は、メッセージ全体に関連するため無視されます。 - For Each によって、現在のペイロードは変更されません。出力ペイロードは入力と同じです。 - XML や JSON など、Java 以外のコレクションの場合は、DataWeave 式を使用してデータを分割します。それには ​**\[Collection (コレクション)\]**​ 項目を使用します。 次の例では、For Each の ​**\[Collection (コレクション)\]**​ 項目は、​`payload.topics`​ に保存された配列に対して反復処理を行うように設定されています。 ![\[Settings (設定)\] が含まれるフローが表示されている For Each コンポーネント](_images/component-foreach-example.png) For Each スコープでは、各反復中にコレクションの各項目が ​`payload`​ に保存されます。 配列をバッチに分割することで、処理時間を短縮することもできます。各バッチは、個別の Mule メッセージとして処理されます。たとえば、コレクションに 200 個の要素があり、​**\[Batch Size (バッチサイズ)\]**​ を ​`50`​ に設定すると、For Each スコープは 50 個の要素から成る 4 つのバッチをそれぞれ個別の Mule メッセージとして反復処理します。 ## [](#サンプル-xml)サンプル XML これは、上述の For Each スコープ設定に基づくサンプル XML です。 ```xml ... ... ``` ## [](#変数の伝播)変数の伝播 For Each スコープの各実行は、ブロックの前回の実行からの変数と値を使用して開始されます。1 つの要素の処理時に作成された新しい変数や既存の変数に加えられた変更は、別の要素の処理中に参照できます。変数へのこれらの変更は、引き続き For Each スコープの外部で使用できます。 ```xml ``` 集約後、変数は次のようになります。 ```json {var1: "var1", var2: "newValue", var3: "otherVal", var4: "val4"} ``` ## [](#エラー処理)エラー処理 コレクション内のいずれかの要素で例外がスローされると、For Each スコープはそのコレクションの処理を停止し、エラーハンドラーを呼び出します。 ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Exchange にはいくつかのサンプルプロジェクトがあり、Anypoint Studio でそれらを開いて For Each スコープの使用方法について詳しく学ぶことができます。 - _Authenticating Salesforce using OAuth2 (OAuth2 を使用した Salesforce の認証)_ - _Import contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Importing a CSV file into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Importing Email Attachments using the POP3 Connector (POP3 Connector を使用したメールの添付ファイルのインポート)_ - _Querying a Database and Attaching Results to an Email (データベースへのクエリ実行とメールへの結果の添付)_ Anypoint Studio でサンプルプロジェクトをダウンロードして開くには、左上隅にある Exchange アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#xml-リファレンス)XML リファレンス For Each スコープの開始と終了には ​``​ タグを使用します。このスコープの影響を受けるコンポーネントは、​``​ タグの子要素として定義されます。 ### [](#設定可能な変数)設定可能な変数
変数 デフォルト 説明

collection

payload

Java コレクション、オブジェクト配列、マップ、または DOM ノードを返す式。

counterVariableName

counter

反復処理を行うメッセージ数を保存する変数の名前。

batchSize

1

コレクションを指定されたサイズのサブコレクションに分割します。たとえば、コレクションに 200 個の要素があり、バッチサイズを 50 に設定すると、50 個の要素から成る 4 つのバッチを処理します。

rootMessageVariableName

rootMessage

親メッセージを保存する変数の名前。親は、分割されていない完全なメッセージです。
## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 [「並列 For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/parallel-foreach-scope)​を参照してください。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-event) - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-message) # For Each スコープ For Each スコープは、ペイロードを要素に分割し、それらを 1 つずつ、スコープ内に配置したコンポーネントで処理します。 これは、ほとんどのプログラミング言語の ​`for-each`​/​`for`​ loop コードブロックに似ており、リストや配列を含め、あらゆるコレクションを処理できます。 コレクションには、サポートされている任意のコンテンツ種別 (​`application/json`​、​`application/java`​、​`application/xml`​ など) を使用できます。 For Each スコープに関する一般的な考慮事項: - デフォルトでは、For Each はペイロードを分割しようとします。ペイロードが単純な Java コレクションであれば、For Each スコープは設定なしでペイロードを分割できます。For Each スコープ内のペイロードは、分割された各要素です。元のメッセージ内の属性は、メッセージ全体に関連するため無視されます。 - For Each によって、現在のペイロードは変更されません。出力ペイロードは入力と同じです。 - XML や JSON など、Java 以外のコレクションの場合は、DataWeave 式を使用してデータを分割します。それには ​**\[Collection (コレクション)\]**​ 項目を使用します。 次の例では、For Each の ​**\[Collection (コレクション)\]**​ 項目は、​`payload.topics`​ に保存された配列に対して反復処理を行うように設定されています。 ![\[Settings (設定)\] が含まれるフローが表示されている For Each コンポーネント](_images/component-foreach-example.png) For Each スコープでは、各反復中にコレクションの各項目が ​`payload`​ に保存されます。 配列をバッチに分割することで、処理時間を短縮することもできます。各バッチは、個別の Mule メッセージとして処理されます。たとえば、コレクションに 200 個の要素があり、​**\[Batch Size (バッチサイズ)\]**​ を ​`50`​ に設定すると、For Each スコープは 50 個の要素から成る 4 つのバッチをそれぞれ個別の Mule メッセージとして反復処理します。 ## [](#サンプル-xml)サンプル XML これは、上述の For Each スコープ設定に基づくサンプル XML です。 ```xml ... ... ``` ## [](#変数の伝播)変数の伝播 For Each スコープの各実行は、ブロックの前回の実行からの変数と値を使用して開始されます。1 つの要素の処理時に作成された新しい変数や既存の変数に加えられた変更は、別の要素の処理中に参照できます。変数へのこれらの変更は、引き続き For Each スコープの外部で使用できます。 ```xml ``` 集約後、変数は次のようになります。 ```json {var1: "var1", var2: "newValue", var3: "otherVal", var4: "val4"} ``` ## [](#エラー処理)エラー処理 コレクション内のいずれかの要素で例外がスローされると、For Each スコープはそのコレクションの処理を停止し、エラーハンドラーを呼び出します。 ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Exchange にはいくつかのサンプルプロジェクトがあり、Anypoint Studio でそれらを開いて For Each スコープの使用方法について詳しく学ぶことができます。 - _Authenticating Salesforce using OAuth2 (OAuth2 を使用した Salesforce の認証)_ - _Import contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Importing a CSV file into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Importing Email Attachments using the POP3 Connector (POP3 Connector を使用したメールの添付ファイルのインポート)_ - _Querying a Database and Attaching Results to an Email (データベースへのクエリ実行とメールへの結果の添付)_ Anypoint Studio でサンプルプロジェクトをダウンロードして開くには、左上隅にある Exchange アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#xml-リファレンス)XML リファレンス For Each スコープの開始と終了には ​``​ タグを使用します。このスコープの影響を受けるコンポーネントは、​``​ タグの子要素として定義されます。 ### [](#設定可能な変数)設定可能な変数
変数 デフォルト 説明

collection

payload

Java コレクション、オブジェクト配列、マップ、または DOM ノードを返す式。

counterVariableName

counter

反復処理を行うメッセージ数を保存する変数の名前。

batchSize

1

コレクションを指定されたサイズのサブコレクションに分割します。たとえば、コレクションに 200 個の要素があり、バッチサイズを 50 に設定すると、50 個の要素から成る 4 つのバッチを処理します。

rootMessageVariableName

rootMessage

親メッセージを保存する変数の名前。親は、分割されていない完全なメッセージです。
## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 [「並列 For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/parallel-foreach-scope)​を参照してください。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-event) - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-message) # For Each スコープ For Each スコープは、ペイロードを要素に分割し、それらを 1 つずつ、スコープ内に配置したコンポーネントで処理します。 これは、ほとんどのプログラミング言語の ​`for-each`​/​`for`​ loop コードブロックに似ており、リストや配列を含め、あらゆるコレクションを処理できます。 コレクションには、サポートされている任意のコンテンツ種別 (​`application/json`​、​`application/java`​、​`application/xml`​ など) を使用できます。 For Each スコープに関する一般的な考慮事項: - デフォルトでは、For Each はペイロードを分割しようとします。ペイロードが単純な Java コレクションであれば、For Each スコープは設定なしでペイロードを分割できます。For Each スコープ内のペイロードは、分割された各要素です。元のメッセージ内の属性は、メッセージ全体に関連するため無視されます。 - For Each によって、現在のペイロードは変更されません。出力ペイロードは入力と同じです。 - XML や JSON など、Java 以外のコレクションの場合は、DataWeave 式を使用してデータを分割します。それには ​**\[Collection (コレクション)\]**​ 項目を使用します。 次の例では、For Each の ​**\[Collection (コレクション)\]**​ 項目は、​`payload.topics`​ に保存された配列に対して反復処理を行うように設定されています。 ![\[Settings (設定)\] が含まれるフローが表示されている For Each コンポーネント](_images/component-foreach-example.png) For Each スコープでは、各反復中にコレクションの各項目が ​`payload`​ に保存されます。 配列をバッチに分割することで、処理時間を短縮することもできます。各バッチは、個別の Mule メッセージとして処理されます。たとえば、コレクションに 200 個の要素があり、​**\[Batch Size (バッチサイズ)\]**​ を ​`50`​ に設定すると、For Each スコープは 50 個の要素から成る 4 つのバッチをそれぞれ個別の Mule メッセージとして反復処理します。 ## [](#サンプル-xml)サンプル XML これは、上述の For Each スコープ設定に基づくサンプル XML です。 ```xml ... ... ``` ## [](#変数の伝播)変数の伝播 For Each スコープの各実行は、ブロックの前回の実行からの変数と値を使用して開始されます。1 つの要素の処理時に作成された新しい変数や既存の変数に加えられた変更は、別の要素の処理中に参照できます。変数へのこれらの変更は、引き続き For Each スコープの外部で使用できます。 ```xml ``` 集約後、変数は次のようになります。 ```json {var1: "var1", var2: "newValue", var3: "otherVal", var4: "val4"} ``` ## [](#エラー処理)エラー処理 コレクション内のいずれかの要素で例外がスローされると、For Each スコープはそのコレクションの処理を停止し、エラーハンドラーを呼び出します。 ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Exchange にはいくつかのサンプルプロジェクトがあり、Anypoint Studio でそれらを開いて For Each スコープの使用方法について詳しく学ぶことができます。 - _Authenticating Salesforce using OAuth2 (OAuth2 を使用した Salesforce の認証)_ - _Import contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Importing a CSV file into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Importing Email Attachments using the POP3 Connector (POP3 Connector を使用したメールの添付ファイルのインポート)_ - _Querying a Database and Attaching Results to an Email (データベースへのクエリ実行とメールへの結果の添付)_ Anypoint Studio でサンプルプロジェクトをダウンロードして開くには、左上隅にある Exchange アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#xml-リファレンス)XML リファレンス For Each スコープの開始と終了には ​``​ タグを使用します。このスコープの影響を受けるコンポーネントは、​``​ タグの子要素として定義されます。 ### [](#設定可能な変数)設定可能な変数
変数 デフォルト 説明

collection

payload

Java コレクション、オブジェクト配列、マップ、または DOM ノードを返す式。

counterVariableName

counter

反復処理を行うメッセージ数を保存する変数の名前。

batchSize

1

コレクションを指定されたサイズのサブコレクションに分割します。たとえば、コレクションに 200 個の要素があり、バッチサイズを 50 に設定すると、50 個の要素から成る 4 つのバッチを処理します。

rootMessageVariableName

rootMessage

親メッセージを保存する変数の名前。親は、分割されていない完全なメッセージです。
## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 [「並列 For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/parallel-foreach-scope)​を参照してください。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-event) - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-message) # For Each スコープの移行 DataWeave 2 を式言語として使用すること以外に、Mule 3 と Mule 4 の For Each スコープはほとんど変更されていません。ただし、この小さな変更は、コンポーネントの使いやすさに大きく影響します。 Mule 3 の場合、foreach では入力コレクションが Java イテラブル、Java イテレーター、または Java 配列であることが必要でした。常に入力が Java 形式であることを確認する必要がありました (したがって、Java に精通せざるを得ませんでした)。 Mule 4 では、形式に関係なく、配列状の構造での反復処理がサポートされます。たとえば、HTTP 要求によって次の JSON が投稿されるとします。 ```json { persons: [ { name: 'John Doe', age: 34 }, { name: 'Jane Doe', age: 32 } ] } ``` Mule 3 では、JSON を最初に Java に変換する必要があります。 Mule 3 の例 ```xml ``` Mule 4 では、次のように JSON 形式の persons 配列に直接アクセスできます。 Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 - [例外戦略の移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-core-exception-strategies) - [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-dataweave) # For Each スコープの移行 DataWeave 2 を式言語として使用すること以外に、Mule 3 と Mule 4 の For Each スコープはほとんど変更されていません。ただし、この小さな変更は、コンポーネントの使いやすさに大きく影響します。 Mule 3 の場合、foreach では入力コレクションが Java イテラブル、Java イテレーター、または Java 配列であることが必要でした。常に入力が Java 形式であることを確認する必要がありました (したがって、Java に精通せざるを得ませんでした)。 Mule 4 では、形式に関係なく、配列状の構造での反復処理がサポートされます。たとえば、HTTP 要求によって次の JSON が投稿されるとします。 ```json { persons: [ { name: 'John Doe', age: 34 }, { name: 'Jane Doe', age: 32 } ] } ``` Mule 3 では、JSON を最初に Java に変換する必要があります。 Mule 3 の例 ```xml ``` Mule 4 では、次のように JSON 形式の persons 配列に直接アクセスできます。 Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 - [例外戦略の移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-core-exception-strategies) - [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-dataweave) # For Each スコープの移行 DataWeave 2 を式言語として使用すること以外に、Mule 3 と Mule 4 の For Each スコープはほとんど変更されていません。ただし、この小さな変更は、コンポーネントの使いやすさに大きく影響します。 Mule 3 の場合、foreach では入力コレクションが Java イテラブル、Java イテレーター、または Java 配列であることが必要でした。常に入力が Java 形式であることを確認する必要がありました (したがって、Java に精通せざるを得ませんでした)。 Mule 4 では、形式に関係なく、配列状の構造での反復処理がサポートされます。たとえば、HTTP 要求によって次の JSON が投稿されるとします。 ```json { persons: [ { name: 'John Doe', age: 34 }, { name: 'Jane Doe', age: 32 } ] } ``` Mule 3 では、JSON を最初に Java に変換する必要があります。 Mule 3 の例 ```xml ``` Mule 4 では、次のように JSON 形式の persons 配列に直接アクセスできます。 Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 - [例外戦略の移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-core-exception-strategies) - [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-dataweave) # For Each スコープの移行 DataWeave 2 を式言語として使用すること以外に、Mule 3 と Mule 4 の For Each スコープはほとんど変更されていません。ただし、この小さな変更は、コンポーネントの使いやすさに大きく影響します。 Mule 3 の場合、foreach では入力コレクションが Java イテラブル、Java イテレーター、または Java 配列であることが必要でした。常に入力が Java 形式であることを確認する必要がありました (したがって、Java に精通せざるを得ませんでした)。 Mule 4 では、形式に関係なく、配列状の構造での反復処理がサポートされます。たとえば、HTTP 要求によって次の JSON が投稿されるとします。 ```json { persons: [ { name: 'John Doe', age: 34 }, { name: 'Jane Doe', age: 32 } ] } ``` Mule 3 では、JSON を最初に Java に変換する必要があります。 Mule 3 の例 ```xml ``` Mule 4 では、次のように JSON 形式の persons 配列に直接アクセスできます。 Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 - [例外戦略の移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-core-exception-strategies) - [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-dataweave) # For Each スコープの移行 DataWeave 2 を式言語として使用すること以外に、Mule 3 と Mule 4 の For Each スコープはほとんど変更されていません。ただし、この小さな変更は、コンポーネントの使いやすさに大きく影響します。 Mule 3 の場合、foreach では入力コレクションが Java イテラブル、Java イテレーター、または Java 配列であることが必要でした。常に入力が Java 形式であることを確認する必要がありました (したがって、Java に精通せざるを得ませんでした)。 Mule 4 では、形式に関係なく、配列状の構造での反復処理がサポートされます。たとえば、HTTP 要求によって次の JSON が投稿されるとします。 ```json { persons: [ { name: 'John Doe', age: 34 }, { name: 'Jane Doe', age: 32 } ] } ``` Mule 3 では、JSON を最初に Java に変換する必要があります。 Mule 3 の例 ```xml ``` Mule 4 では、次のように JSON 形式の persons 配列に直接アクセスできます。 Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 - [例外戦略の移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-core-exception-strategies) - [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-dataweave) # For Each スコープの移行 DataWeave 2 を式言語として使用すること以外に、Mule 3 と Mule 4 の For Each スコープはほとんど変更されていません。ただし、この小さな変更は、コンポーネントの使いやすさに大きく影響します。 Mule 3 の場合、foreach では入力コレクションが Java イテラブル、Java イテレーター、または Java 配列であることが必要でした。常に入力が Java 形式であることを確認する必要がありました (したがって、Java に精通せざるを得ませんでした)。 Mule 4 では、形式に関係なく、配列状の構造での反復処理がサポートされます。たとえば、HTTP 要求によって次の JSON が投稿されるとします。 ```json { persons: [ { name: 'John Doe', age: 34 }, { name: 'Jane Doe', age: 32 } ] } ``` Mule 3 では、JSON を最初に Java に変換する必要があります。 Mule 3 の例 ```xml ``` Mule 4 では、次のように JSON 形式の persons 配列に直接アクセスできます。 Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 - [例外戦略の移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-core-exception-strategies) - [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-dataweave) # For Each スコープの移行 DataWeave 2 を式言語として使用すること以外に、Mule 3 と Mule 4 の For Each スコープはほとんど変更されていません。ただし、この小さな変更は、コンポーネントの使いやすさに大きく影響します。 Mule 3 の場合、foreach では入力コレクションが Java イテラブル、Java イテレーター、または Java 配列であることが必要でした。常に入力が Java 形式であることを確認する必要がありました (したがって、Java に精通せざるを得ませんでした)。 Mule 4 では、形式に関係なく、配列状の構造での反復処理がサポートされます。たとえば、HTTP 要求によって次の JSON が投稿されるとします。 ```json { persons: [ { name: 'John Doe', age: 34 }, { name: 'Jane Doe', age: 32 } ] } ``` Mule 3 では、JSON を最初に Java に変換する必要があります。 Mule 3 の例 ```xml ``` Mule 4 では、次のように JSON 形式の persons 配列に直接アクセスできます。 Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 - [例外戦略の移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-core-exception-strategies) - [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-dataweave) # FTP および SFTP Connector への移行 SFTP および SFTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 さらに、これらは完全対称になるよう設計されています。つまり、接続設定を除き、デザインや動作が同様で、まったく同じ機能セットを備えています。また、File Connector の機能や動作にも適合します。 ## [](#config_ftp_sftp)FTP または SFTP サーバーへの接続 ### [](#ftp-接続の移行)FTP 接続の移行 Mule 3 の例: ポーリングを行う FTP インバウンド接続 ```xml ``` 次の例は、Mule 4 のシンプルな FTP 設定を示しています。 Mule 4 の例: FTP 接続 ```xml ``` ### [](#sftp-接続の移行)SFTP 接続の移行 Mule 3 の例: SFTP インバウンドエンドポイント ```xml ``` Mule 4 の例: SFTP 接続設定 ```xml ``` SFTP 接続はプロキシ経由の接続もサポートしています。 Mule 4 の例: プロキシ経由の SFTP 接続 ```xml ``` ## [](#ftp_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ と ​``​ メッセージソースを使用してファイルのディレクトリをポーリングしていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ と ​``​ コンポーネント (Studio パレットでは ​`On New File`​ と表示) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ と ​``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じてファイルのタイムスタンプに基づいて自動的に絞り込むことができます。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#ftp_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 のコネクタは、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作には ​`mode`​ パラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` SFTP Connector で FTP を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-ftp-connector 1.1.0 mule-plugin org.mule.connectors mule-sftp-connector 1.1.0 mule-plugin ``` ### [](#sftp-addSeqNo)SFTP アウトバウンドの 'addSeqNo' の重複処理 Mule 3 で ​`duplicateHandling="addSeqNo"`​ を使用すると、未使用のインデックスが見つかるまでファイル名に反復処理が行われます。 Mule 4 では、オブジェクトストアや UUID などを使用して、このコードを独自のインデックスに置換する必要があります。 Mule 3 の例: アウトバウンド SFTP エンドポイント ​`addSeqNo` ```xml ``` Mule 4 の例: `path`​ に ​`uuid()`​ が設定された ​`sftp:write` ```xml ``` ## [](#sftp-temp-dir)SFTP の tempDir の移行 Mule 3 の SFTP トランスポートでは、ファイルの読み取りまたは書き込み時に使用する一時的なディレクトリを設定できます。この設定で指定するプロパティは次のとおりです。 - `sftp:connector`​: - `tempDirInbound` - `tempDirOutbound` - `useTempFileTimestampSuffix` - `sftp:inbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` - `sftp:outbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` Mule 4 の SFTP Connector ではこれらの設定を使用できません。ただし、このコネクタには、この種の設定の代わりとなる ​`sftp:move`​ 操作があります。 Mule 3 の例: インバウンド SFTP エンドポイント ​`tempDir` ```xml ... ``` Mule 4 の例: 一時的なディレクトリへの ​`sftp:move` ```xml ... ``` ## [](#ローカルドライブへのファイルのアーカイブ)ローカルドライブへのファイルのアーカイブ Mule 4 で、SFTP Connector のリスナーの ​`moveToDirectory`​ 属性では、ローカルディレクトリではなく SFTP サーバーの別のディレクトリにのみアーカイブします。 File Connector で Write 操作 (​`file:write`​) を使用すれば、ファイルをローカルドライブにアーカイブできます。 Mule 4 の例: ローカルディレクトリへの ​`file:write`​ ```xml ``` ## [](#関連情報)関連情報 - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) # FTP および SFTP Connector への移行 SFTP および SFTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 さらに、これらは完全対称になるよう設計されています。つまり、接続設定を除き、デザインや動作が同様で、まったく同じ機能セットを備えています。また、File Connector の機能や動作にも適合します。 ## [](#config_ftp_sftp)FTP または SFTP サーバーへの接続 ### [](#ftp-接続の移行)FTP 接続の移行 Mule 3 の例: ポーリングを行う FTP インバウンド接続 ```xml ``` 次の例は、Mule 4 のシンプルな FTP 設定を示しています。 Mule 4 の例: FTP 接続 ```xml ``` ### [](#sftp-接続の移行)SFTP 接続の移行 Mule 3 の例: SFTP インバウンドエンドポイント ```xml ``` Mule 4 の例: SFTP 接続設定 ```xml ``` SFTP 接続はプロキシ経由の接続もサポートしています。 Mule 4 の例: プロキシ経由の SFTP 接続 ```xml ``` ## [](#ftp_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ と ​``​ メッセージソースを使用してファイルのディレクトリをポーリングしていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ と ​``​ コンポーネント (Studio パレットでは ​`On New File`​ と表示) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ と ​``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じてファイルのタイムスタンプに基づいて自動的に絞り込むことができます。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#ftp_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 のコネクタは、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作には ​`mode`​ パラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` SFTP Connector で FTP を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-ftp-connector 1.1.0 mule-plugin org.mule.connectors mule-sftp-connector 1.1.0 mule-plugin ``` ### [](#sftp-addSeqNo)SFTP アウトバウンドの「addSeqNo」の重複処理 Mule 3 で ​`duplicateHandling="addSeqNo"`​ を使用すると、未使用のインデックスが見つかるまでファイル名に反復処理が行われます。 Mule 4 では、オブジェクトストアや UUID などを使用して、このコードを独自のインデックスに置換する必要があります。 Mule 3 の例: アウトバウンド SFTP エンドポイント ​`addSeqNo` ```xml ``` Mule 4 の例: `path`​ に ​`uuid()`​ が設定された ​`sftp:write` ```xml ``` ## [](#sftp-temp-dir)SFTP の tempDir の移行 Mule 3 の SFTP トランスポートでは、ファイルの読み取りまたは書き込み時に使用する一時的なディレクトリを設定できます。この設定で指定するプロパティは次のとおりです。 - `sftp:connector`​: - `tempDirInbound` - `tempDirOutbound` - `useTempFileTimestampSuffix` - `sftp:inbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` - `sftp:outbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` Mule 4 の SFTP Connector ではこれらの設定を使用できません。ただし、このコネクタには、この種の設定の代わりとなる ​`sftp:move`​ 操作があります。 Mule 3 の例: インバウンド SFTP エンドポイント ​`tempDir` ```xml ... ``` Mule 4 の例: 一時的なディレクトリへの ​`sftp:move` ```xml ... ``` ## [](#ローカルドライブへのファイルのアーカイブ)ローカルドライブへのファイルのアーカイブ Mule 4 で、SFTP Connector のリスナーの ​`moveToDirectory`​ 属性では、ローカルディレクトリではなく SFTP サーバーの別のディレクトリにのみアーカイブします。 File Connector で Write 操作 (​`file:write`​) を使用すれば、ファイルをローカルドライブにアーカイブできます。 Mule 4 の例: ローカルディレクトリへの ​`file:write`​ ```xml ``` ## [](#関連情報)関連情報 - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) # FTP および SFTP Connector への移行 SFTP および SFTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 さらに、これらは完全対称になるよう設計されています。つまり、接続設定を除き、デザインや動作が同様で、まったく同じ機能セットを備えています。また、File Connector の機能や動作にも適合します。 ## [](#config_ftp_sftp)FTP または SFTP サーバーへの接続 ### [](#ftp-接続の移行)FTP 接続の移行 Mule 3 の例: ポーリングを行う FTP インバウンド接続 ```xml ``` 次の例は、Mule 4 のシンプルな FTP 設定を示しています。 Mule 4 の例: FTP 接続 ```xml ``` ### [](#sftp-接続の移行)SFTP 接続の移行 Mule 3 の例: SFTP インバウンドエンドポイント ```xml ``` Mule 4 の例: SFTP 接続設定 ```xml ``` SFTP 接続はプロキシ経由の接続もサポートしています。 Mule 4 の例: プロキシ経由の SFTP 接続 ```xml ``` ## [](#ftp_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ と ​``​ メッセージソースを使用してファイルのディレクトリをポーリングしていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ と ​``​ コンポーネント (Studio パレットでは ​`On New File`​ と表示) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ と ​``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じてファイルのタイムスタンプに基づいて自動的に絞り込むことができます。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#ftp_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 のコネクタは、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作には ​`mode`​ パラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` SFTP Connector で FTP を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-ftp-connector 1.1.0 mule-plugin org.mule.connectors mule-sftp-connector 1.1.0 mule-plugin ``` ### [](#sftp-addSeqNo)SFTP アウトバウンドの 'addSeqNo' の重複処理 Mule 3 で ​`duplicateHandling="addSeqNo"`​ を使用すると、未使用のインデックスが見つかるまでファイル名に反復処理が行われます。 Mule 4 では、オブジェクトストアや UUID などを使用して、このコードを独自のインデックスに置換する必要があります。 Mule 3 の例: アウトバウンド SFTP エンドポイント ​`addSeqNo` ```xml ``` Mule 4 の例: `path`​ に ​`uuid()`​ が設定された ​`sftp:write` ```xml ``` ## [](#sftp-temp-dir)SFTP の tempDir の移行 Mule 3 の SFTP トランスポートでは、ファイルの読み取りまたは書き込み時に使用する一時的なディレクトリを設定できます。この設定で指定するプロパティは次のとおりです。 - `sftp:connector`​: - `tempDirInbound` - `tempDirOutbound` - `useTempFileTimestampSuffix` - `sftp:inbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` - `sftp:outbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` Mule 4 の SFTP Connector ではこれらの設定を使用できません。ただし、このコネクタには、この種の設定の代わりとなる ​`sftp:move`​ 操作があります。 Mule 3 の例: インバウンド SFTP エンドポイント ​`tempDir` ```xml ... ``` Mule 4 の例: 一時的なディレクトリへの ​`sftp:move` ```xml ... ``` ## [](#ローカルドライブへのファイルのアーカイブ)ローカルドライブへのファイルのアーカイブ Mule 4 で、SFTP Connector のリスナーの ​`moveToDirectory`​ 属性では、ローカルディレクトリではなく SFTP サーバーの別のディレクトリにのみアーカイブします。 File Connector で Write 操作 (​`file:write`​) を使用すれば、ファイルをローカルドライブにアーカイブできます。 Mule 4 の例: ローカルディレクトリへの ​`file:write`​ ```xml ``` ## [](#関連情報)関連情報 - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) # FTP および SFTP Connector への移行 SFTP および SFTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 さらに、これらは完全対称になるよう設計されています。つまり、接続設定を除き、デザインや動作が同様で、まったく同じ機能セットを備えています。また、File Connector の機能や動作にも適合します。 ## [](#config_ftp_sftp)FTP または SFTP サーバーへの接続 ### [](#ftp-接続の移行)FTP 接続の移行 Mule 3 の例: ポーリングを行う FTP インバウンド接続 ```xml ``` 次の例は、Mule 4 のシンプルな FTP 設定を示しています。 Mule 4 の例: FTP 接続 ```xml ``` ### [](#sftp-接続の移行)SFTP 接続の移行 Mule 3 の例: SFTP インバウンドエンドポイント ```xml ``` Mule 4 の例: SFTP 接続設定 ```xml ``` SFTP 接続はプロキシ経由の接続もサポートしています。 Mule 4 の例: プロキシ経由の SFTP 接続 ```xml ``` ## [](#ftp_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ と ​``​ メッセージソースを使用してファイルのディレクトリをポーリングしていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ と ​``​ コンポーネント (Studio パレットでは ​`On New File`​ と表示) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ と ​``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じてファイルのタイムスタンプに基づいて自動的に絞り込むことができます。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#ftp_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 のコネクタは、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作には ​`mode`​ パラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` SFTP Connector で FTP を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-ftp-connector 1.1.0 mule-plugin org.mule.connectors mule-sftp-connector 1.1.0 mule-plugin ``` ### [](#sftp-addSeqNo)SFTP アウトバウンドの「addSeqNo」の重複処理 Mule 3 で ​`duplicateHandling="addSeqNo"`​ を使用すると、未使用のインデックスが見つかるまでファイル名に反復処理が行われます。 Mule 4 では、オブジェクトストアや UUID などを使用して、このコードを独自のインデックスに置換する必要があります。 Mule 3 の例: アウトバウンド SFTP エンドポイント ​`addSeqNo` ```xml ``` Mule 4 の例: `path`​ に ​`uuid()`​ が設定された ​`sftp:write` ```xml ``` ## [](#sftp-temp-dir)SFTP の tempDir の移行 Mule 3 の SFTP トランスポートでは、ファイルの読み取りまたは書き込み時に使用する一時的なディレクトリを設定できます。この設定で指定するプロパティは次のとおりです。 - `sftp:connector`​: - `tempDirInbound` - `tempDirOutbound` - `useTempFileTimestampSuffix` - `sftp:inbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` - `sftp:outbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` Mule 4 の SFTP Connector ではこれらの設定を使用できません。ただし、このコネクタには、この種の設定の代わりとなる ​`sftp:move`​ 操作があります。 Mule 3 の例: インバウンド SFTP エンドポイント ​`tempDir` ```xml ... ``` Mule 4 の例: 一時的なディレクトリへの ​`sftp:move` ```xml ... ``` ## [](#ローカルドライブへのファイルのアーカイブ)ローカルドライブへのファイルのアーカイブ Mule 4 で、SFTP Connector のリスナーの ​`moveToDirectory`​ 属性では、ローカルディレクトリではなく SFTP サーバーの別のディレクトリにのみアーカイブします。 File Connector で Write 操作 (​`file:write`​) を使用すれば、ファイルをローカルドライブにアーカイブできます。 Mule 4 の例: ローカルディレクトリへの ​`file:write`​ ```xml ``` ## [](#関連情報)関連情報 - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) # FTP および SFTP Connector への移行 SFTP および SFTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 さらに、これらは完全対称になるよう設計されています。つまり、接続設定を除き、デザインや動作が同様で、まったく同じ機能セットを備えています。また、File Connector の機能や動作にも適合します。 ## [](#config_ftp_sftp)FTP または SFTP サーバーへの接続 ### [](#ftp-接続の移行)FTP 接続の移行 Mule 3 の例: ポーリングを行う FTP インバウンド接続 ```xml ``` 次の例は、Mule 4 のシンプルな FTP 設定を示しています。 Mule 4 の例: FTP 接続 ```xml ``` ### [](#sftp-接続の移行)SFTP 接続の移行 Mule 3 の例: SFTP インバウンドエンドポイント ```xml ``` Mule 4 の例: SFTP 接続設定 ```xml ``` SFTP 接続はプロキシ経由の接続もサポートしています。 Mule 4 の例: プロキシ経由の SFTP 接続 ```xml ``` ## [](#ftp_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ と ​``​ メッセージソースを使用してファイルのディレクトリをポーリングしていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ と ​``​ コンポーネント (Studio パレットでは ​`On New File`​ と表示) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ と ​``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じてファイルのタイムスタンプに基づいて自動的に絞り込むことができます。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#ftp_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 のコネクタは、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作には ​`mode`​ パラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` SFTP Connector で FTP を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-ftp-connector 1.1.0 mule-plugin org.mule.connectors mule-sftp-connector 1.1.0 mule-plugin ``` ### [](#sftp-addSeqNo)SFTP アウトバウンドの「addSeqNo」の重複処理 Mule 3 で ​`duplicateHandling="addSeqNo"`​ を使用すると、未使用のインデックスが見つかるまでファイル名に反復処理が行われます。 Mule 4 では、オブジェクトストアや UUID などを使用して、このコードを独自のインデックスに置換する必要があります。 Mule 3 の例: アウトバウンド SFTP エンドポイント ​`addSeqNo` ```xml ``` Mule 4 の例: `path`​ に ​`uuid()`​ が設定された ​`sftp:write` ```xml ``` ## [](#sftp-temp-dir)SFTP の tempDir の移行 Mule 3 の SFTP トランスポートでは、ファイルの読み取りまたは書き込み時に使用する一時的なディレクトリを設定できます。この設定で指定するプロパティは次のとおりです。 - `sftp:connector`​: - `tempDirInbound` - `tempDirOutbound` - `useTempFileTimestampSuffix` - `sftp:inbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` - `sftp:outbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` Mule 4 の SFTP Connector ではこれらの設定を使用できません。ただし、このコネクタには、この種の設定の代わりとなる ​`sftp:move`​ 操作があります。 Mule 3 の例: インバウンド SFTP エンドポイント ​`tempDir` ```xml ... ``` Mule 4 の例: 一時的なディレクトリへの ​`sftp:move` ```xml ... ``` ## [](#ローカルドライブへのファイルのアーカイブ)ローカルドライブへのファイルのアーカイブ Mule 4 で、SFTP Connector のリスナーの ​`moveToDirectory`​ 属性では、ローカルディレクトリではなく SFTP サーバーの別のディレクトリにのみアーカイブします。 File Connector で Write 操作 (​`file:write`​) を使用すれば、ファイルをローカルドライブにアーカイブできます。 Mule 4 の例: ローカルディレクトリへの ​`file:write`​ ```xml ``` ## [](#関連情報)関連情報 - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) # FTP および SFTP Connector への移行 SFTP および SFTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 さらに、これらは完全対称になるよう設計されています。つまり、接続設定を除き、デザインや動作が同様で、まったく同じ機能セットを備えています。また、File Connector の機能や動作にも適合します。 ## [](#config_ftp_sftp)FTP または SFTP サーバーへの接続 ### [](#ftp-接続の移行)FTP 接続の移行 Mule 3 の例: ポーリングを行う FTP インバウンド接続 ```xml ``` 次の例は、Mule 4 のシンプルな FTP 設定を示しています。 Mule 4 の例: FTP 接続 ```xml ``` ### [](#sftp-接続の移行)SFTP 接続の移行 Mule 3 の例: SFTP インバウンドエンドポイント ```xml ``` Mule 4 の例: SFTP 接続設定 ```xml ``` SFTP 接続はプロキシ経由の接続もサポートしています。 Mule 4 の例: プロキシ経由の SFTP 接続 ```xml ``` ## [](#ftp_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ と ​``​ メッセージソースを使用してファイルのディレクトリをポーリングしていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ と ​``​ コンポーネント (Studio パレットでは ​`On New File`​ と表示) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ と ​``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じてファイルのタイムスタンプに基づいて自動的に絞り込むことができます。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#ftp_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 Connector は、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作には ​`mode`​ パラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` SFTP Connector で FTP を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-ftp-connector 1.1.0 mule-plugin org.mule.connectors mule-sftp-connector 1.1.0 mule-plugin ``` ### [](#sftp-addSeqNo)SFTP アウトバウンドの「addSeqNo」の重複処理 Mule 3 で ​`duplicateHandling="addSeqNo"`​ を使用すると、未使用のインデックスが見つかるまでファイル名に反復処理が行われます。 Mule 4 では、オブジェクトストアや UUID などを使用して、このコードを独自のインデックスに置換する必要があります。 Mule 3 の例: アウトバウンド SFTP エンドポイント ​`addSeqNo` ```xml ``` Mule 4 の例: `path`​ に ​`uuid()`​ が設定された ​`sftp:write` ```xml ``` ## [](#sftp-temp-dir)SFTP の tempDir の移行 Mule 3 の SFTP トランスポートでは、ファイルの読み取りまたは書き込み時に使用する一時的なディレクトリを設定できます。この設定で指定するプロパティは次のとおりです。 - `sftp:connector`​: - `tempDirInbound` - `tempDirOutbound` - `useTempFileTimestampSuffix` - `sftp:inbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` - `sftp:outbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` Mule 4 の SFTP Connector ではこれらの設定を使用できません。ただし、このコネクタには、この種の設定の代わりとなる ​`sftp:move`​ 操作があります。 Mule 3 の例: インバウンド SFTP エンドポイント ​`tempDir` ```xml ... ``` Mule 4 の例: 一時的なディレクトリへの ​`sftp:move` ```xml ... ``` ## [](#ローカルドライブへのファイルのアーカイブ)ローカルドライブへのファイルのアーカイブ Mule 4 で、SFTP Connector のリスナーの ​`moveToDirectory`​ 属性では、ローカルディレクトリではなく SFTP サーバーの別のディレクトリにのみアーカイブします。 File Connector で Write 操作 (​`file:write`​) を使用すれば、ファイルをローカルドライブにアーカイブできます。 Mule 4 の例: ローカルディレクトリへの ​`file:write`​ ```xml ``` ## [](#関連情報)関連情報 - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) # FTP および SFTP Connector への移行 SFTP および SFTP トランスポートは一新されました。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 さらに、これらは完全対称になるよう設計されています。つまり、接続設定を除き、デザインや動作が同様で、まったく同じ機能セットを備えています。また、File Connector の機能や動作にも適合します。 ## [](#config_ftp_sftp)FTP または SFTP サーバーへの接続 ### [](#ftp-接続の移行)FTP 接続の移行 Mule 3 の例: ポーリングを行う FTP インバウンド接続 ```xml ``` 次の例は、Mule 4 のシンプルな FTP 設定を示しています。 Mule 4 の例: FTP 接続 ```xml ``` ### [](#sftp-接続の移行)SFTP 接続の移行 Mule 3 の例: SFTP インバウンドエンドポイント ```xml ``` Mule 4 の例: SFTP 接続設定 ```xml ``` SFTP 接続はプロキシ経由の接続もサポートしています。 Mule 4 の例: プロキシ経由の SFTP 接続 ```xml ``` ## [](#ftp_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ と ​``​ メッセージソースを使用してファイルのディレクトリをポーリングしていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルのコンテンツが保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ と ​``​ コンポーネント (Studio パレットでは ​`On New File`​ と表示) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ と ​``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じてファイルのタイムスタンプに基づいて自動的に絞り込むことができます。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#ftp_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 Connector は、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作には ​`mode`​ パラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` SFTP Connector で FTP を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-ftp-connector 1.1.0 mule-plugin org.mule.connectors mule-sftp-connector 1.1.0 mule-plugin ``` ### [](#sftp-addSeqNo)SFTP アウトバウンドの「addSeqNo」の重複処理 Mule 3 で ​`duplicateHandling="addSeqNo"`​ を使用すると、未使用のインデックスが見つかるまでファイル名に反復処理が行われます。 Mule 4 では、オブジェクトストアや UUID などを使用して、このコードを独自のインデックスに置換する必要があります。 Mule 3 の例: アウトバウンド SFTP エンドポイント ​`addSeqNo` ```xml ``` Mule 4 の例: `path`​ に ​`uuid()`​ が設定された ​`sftp:write` ```xml ``` ## [](#sftp-temp-dir)SFTP の tempDir の移行 Mule 3 の SFTP トランスポートでは、ファイルの読み取りまたは書き込み時に使用する一時的なディレクトリを設定できます。この設定で指定するプロパティは次のとおりです。 - `sftp:connector`​: - `tempDirInbound` - `tempDirOutbound` - `useTempFileTimestampSuffix` - `sftp:inbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` - `sftp:outbound-endpoint`​: - `tempDir` - `useTempFileTimestampSuffix` Mule 4 の SFTP Connector ではこれらの設定を使用できません。ただし、このコネクタには、この種の設定の代わりとなる ​`sftp:move`​ 操作があります。 Mule 3 の例: インバウンド SFTP エンドポイント ​`tempDir` ```xml ... ``` Mule 4 の例: 一時的なディレクトリへの ​`sftp:move` ```xml ... ``` ## [](#ローカルドライブへのファイルのアーカイブ)ローカルドライブへのファイルのアーカイブ Mule 4 で、SFTP Connector のリスナーの ​`moveToDirectory`​ 属性では、ローカルディレクトリではなく SFTP サーバーの別のディレクトリにのみアーカイブします。 File Connector で Write 操作 (​`file:write`​) を使用すれば、ファイルをローカルドライブにアーカイブできます。 Mule 4 の例: ローカルディレクトリへの ​`file:write`​ ```xml ``` ## [](#関連情報)関連情報 - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) # Global Element (グローバル要素) グローバル要素は、フロー内の要素 (数に制限なし) が共有できるパラメーターを含む再利用可能なオブジェクトです。グローバル要素は、Mule アプリケーション内の Anypoint Connector またはコンポーネントから参照します。 グローバル要素を使用することで、設定の詳細をフロー内の複数のローカル要素に適用できます。パラメーターと設定の詳細を定義したグローバル要素を 1 つだけ作成しておき、同じ設定を使用する任意のフロー要素からグローバル要素を参照します。このようにして、フロー要素間の一貫性を保つことができます。 一部のコンポーネントでは、プロパティをグローバル要素に格納する必要があります。 ## [](#advantages)利点 グローバル要素は、Mule アプリケーション開発者に再利用性、効率性、柔軟性という利点をもたらします。 - 再利用性 グローバル要素を 1 回だけ設定すれば、同じタイプのプロセッサー間で設定を共有できます。特に、SaaS アプリケーションやデータベースなどの外部ソースへの接続の詳細とログイン情報を定義する場合は、グローバル要素を設定すると便利です。 - 効率性 フロー内のプロセッサーにグローバル要素を共有させることで、同じ設定を何度も繰り返して変更する手間を省けます。たとえば、ログイン情報を使用して同じサービスに接続するコネクタが複数ある場合は、グローバル要素の設定を変更するだけで、そのグローバル要素を参照しているすべてのフロー要素に変更が適用されます。 - 柔軟性 フロー内の要素は、グローバル要素の設定を定義通りに適用することも、グローバル設定プロパティに変更を加えて使用することもできます。 ## [](#始める前に)始める前に [Anypoint Studio ビジュアルエディター](https://docs.mulesoft.com/studio/)​の機能を確認して、Anypoint Studio のグラフィカルユーザーインターフェースを使用した Mule アプリケーションの開発について学習し、グローバル要素を使用するコンテキストについて理解を深めてください。 ## [](#グローバル要素の作成)グローバル要素の作成 グローバル要素は 2 通りの方法で作成できます。 - Anypoint Studio キャンバスの ​**\[Global Elements (グローバル要素)\]**​ タブから - グローバル要素をサポートするコネクタまたはモジュールのプロパティパネルから ### [](#anypoint-studio-キャンバスから)Anypoint Studio キャンバスから 1. Anypoint Studio ビジュアルエディターで、​**\[Global Elements (グローバル要素)\]**​ タブをクリックして、アプリケーション内のすべてのグローバル要素のリストにアクセスします。 ![new-global-element](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-new-global-element.png) 2. **\[Create (作成)\]**​ をクリックして、新しいグローバル要素を追加します。 3. **\[Choose Global Type (グローバル種別の選択)\]**​ ウィザードで、ディレクトリ間を移動するか、または検索条件を使用して、作成するグローバル要素の種別を選択し、​**\[OK\]**​ をクリックします。 4. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 5. **\[OK\]**​ をクリックして保存します。 ### [](#コネクタまたはモジュールのプロパティパネルから)コネクタまたはモジュールのプロパティパネルから フロー内に配置したローカルコンポーネント内から新しいグローバル要素を作成する手順は次のとおりです。 1. グローバル要素を作成するコンポーネントをクリックします。 ![select-component-global-element](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-global-element-component.png) 2. プロパティパネルで、​**\[Connector Configuration (コネクタ設定)\]**​ の横にある追加アイコンをクリックします。 ![create-config-global-element](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-global-element-create.png) 3. 作成するグローバル要素種別で必要な項目をすべて設定します。 ## [](#関連情報)関連情報 - [グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/global-settings-configuration) # Global Element (グローバル要素) グローバル要素は、フロー内の要素 (数に制限なし) が共有できるパラメーターを含む再利用可能なオブジェクトです。グローバル要素は、Mule アプリケーション内の Anypoint Connector またはコンポーネントから参照します。 グローバル要素を使用することで、設定の詳細をフロー内の複数のローカル要素に適用できます。パラメーターと設定の詳細を定義したグローバル要素を 1 つだけ作成しておき、同じ設定を使用する任意のフロー要素からグローバル要素を参照します。このようにして、フロー要素間の一貫性を保つことができます。 一部のコンポーネントでは、プロパティをグローバル要素に格納する必要があります。 ## [](#advantages)利点 グローバル要素は、Mule アプリケーション開発者に再利用性、効率性、柔軟性という利点をもたらします。 - 再利用性 グローバル要素を 1 回だけ設定すれば、同じタイプのプロセッサー間で設定を共有できます。特に、SaaS アプリケーションやデータベースなどの外部ソースへの接続の詳細とログイン情報を定義する場合は、グローバル要素を設定すると便利です。 - 効率性 フロー内のプロセッサーにグローバル要素を共有させることで、同じ設定を何度も繰り返して変更する手間を省けます。たとえば、ログイン情報を使用して同じサービスに接続するコネクタが複数ある場合は、グローバル要素の設定を変更するだけで、そのグローバル要素を参照しているすべてのフロー要素に変更が適用されます。 - 柔軟性 フロー内の要素は、グローバル要素の設定を定義通りに適用することも、グローバル設定プロパティに変更を加えて使用することもできます。 ## [](#始める前に)始める前に [Anypoint Studio ビジュアルエディター](https://docs.mulesoft.com/studio/)​の機能を確認して、Anypoint Studio のグラフィカルユーザーインターフェースを使用した Mule アプリケーションの開発について学習し、グローバル要素を使用するコンテキストについて理解を深めてください。 ## [](#グローバル要素の作成)グローバル要素の作成 グローバル要素は 2 通りの方法で作成できます。 - Anypoint Studio キャンバスの ​**\[Global Elements (グローバル要素)\]**​ タブから - グローバル要素をサポートするコネクタまたはモジュールのプロパティパネルから ### [](#anypoint-studio-キャンバスから)Anypoint Studio キャンバスから 1. Anypoint Studio ビジュアルエディターで、​**\[Global Elements (グローバル要素)\]**​ タブをクリックして、アプリケーション内のすべてのグローバル要素のリストにアクセスします。 ![new-global-element](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-new-global-element.png) 2. **\[Create (作成)\]**​ をクリックして、新しいグローバル要素を追加します。 3. **\[Choose Global Type (グローバル種別の選択)\]**​ ウィザードで、ディレクトリ間を移動するか、または検索条件を使用して、作成するグローバル要素の種別を選択し、​**\[OK\]**​ をクリックします。 4. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 5. **\[OK\]**​ をクリックして保存します。 ### [](#コネクタまたはモジュールのプロパティパネルから)コネクタまたはモジュールのプロパティパネルから フロー内に配置したローカルコンポーネント内から新しいグローバル要素を作成する手順は次のとおりです。 1. グローバル要素を作成するコンポーネントをクリックします。 ![select-component-global-element](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-global-element-component.png) 2. プロパティパネルで、​**\[Connector Configuration (コネクタ設定)\]**​ の横にある追加アイコンをクリックします。 ![create-config-global-element](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-global-element-create.png) 3. 作成するグローバル要素種別で必要な項目をすべて設定します。 ## [](#関連情報)関連情報 - [グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/global-settings-configuration) # Global Element (グローバル要素) グローバル要素は、フロー内の要素 (数に制限なし) が共有できるパラメーターを含む再利用可能なオブジェクトです。グローバル要素は、Mule アプリケーション内の Anypoint Connector またはコンポーネントから参照します。 グローバル要素を使用することで、設定の詳細をフロー内の複数のローカル要素に適用できます。パラメーターと設定の詳細を定義したグローバル要素を 1 つだけ作成しておき、同じ設定を使用する任意のフロー要素からグローバル要素を参照します。このようにして、フロー要素間の一貫性を保つことができます。 一部のコンポーネントでは、プロパティをグローバル要素に格納する必要があります。 ## [](#advantages)利点 グローバル要素は、Mule アプリケーション開発者に再利用性、効率性、柔軟性という利点をもたらします。 - 再利用性 グローバル要素を 1 回だけ設定すれば、同じタイプのプロセッサー間で設定を共有できます。特に、SaaS アプリケーションやデータベースなどの外部ソースへの接続の詳細とログイン情報を定義する場合は、グローバル要素を設定すると便利です。 - 効率性 フロー内のプロセッサーにグローバル要素を共有させることで、同じ設定を何度も繰り返して変更する手間を省けます。たとえば、ログイン情報を使用して同じサービスに接続するコネクタが複数ある場合は、グローバル要素の設定を変更するだけで、そのグローバル要素を参照しているすべてのフロー要素に変更が適用されます。 - 柔軟性 フロー内の要素は、グローバル要素の設定を定義通りに適用することも、グローバル設定プロパティに変更を加えて使用することもできます。 ## [](#始める前に)始める前に [Anypoint Studio ビジュアルエディター](https://docs.mulesoft.com/studio/)​の機能を確認して、Anypoint Studio のグラフィカルユーザーインターフェースを使用した Mule アプリケーションの開発について学習し、グローバル要素を使用するコンテキストについて理解を深めてください。 ## [](#グローバル要素の作成)グローバル要素の作成 グローバル要素は 2 通りの方法で作成できます。 - Anypoint Studio キャンバスの ​**\[Global Elements (グローバル要素)\]**​ タブから - グローバル要素をサポートするコネクタまたはモジュールのプロパティパネルから ### [](#anypoint-studio-キャンバスから)Anypoint Studio キャンバスから 1. Anypoint Studio ビジュアルエディターで、​**\[Global Elements (グローバル要素)\]**​ タブをクリックして、アプリケーション内のすべてのグローバル要素のリストにアクセスします。 ![new-global-element](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-new-global-element.png) 2. **\[Create (作成)\]**​ をクリックして、新しいグローバル要素を追加します。 3. **\[Choose Global Type (グローバル種別の選択)\]**​ ウィザードで、ディレクトリ間を移動するか、または検索条件を使用して、作成するグローバル要素の種別を選択し、​**\[OK\]**​ をクリックします。 4. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 5. **\[OK\]**​ をクリックして保存します。 ### [](#コネクタまたはモジュールのプロパティパネルから)コネクタまたはモジュールのプロパティパネルから フロー内に配置したローカルコンポーネント内から新しいグローバル要素を作成する手順は次のとおりです。 1. グローバル要素を作成するコンポーネントをクリックします。 ![select-component-global-element](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-global-element-component.png) 2. プロパティパネルで、​**\[Connector Configuration (コネクタ設定)\]**​ の横にある追加アイコンをクリックします。 ![create-config-global-element](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-global-element-create.png) 3. 作成するグローバル要素種別で必要な項目をすべて設定します。 ## [](#関連情報)関連情報 - [グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/global-settings-configuration) # Global Element (グローバル要素) グローバル要素は、フロー内の要素 (数に制限なし) が共有できるパラメーターを含む再利用可能なオブジェクトです。グローバル要素は、Mule アプリケーション内の Anypoint Connector またはコンポーネントから参照します。 グローバル要素を使用することで、設定の詳細をフロー内の複数のローカル要素に適用できます。パラメーターと設定の詳細を定義したグローバル要素を 1 つだけ作成しておき、同じ設定を使用する任意のフロー要素からグローバル要素を参照します。このようにして、フロー要素間の一貫性を保つことができます。 一部のコンポーネントでは、プロパティをグローバル要素に格納する必要があります。 ## [](#advantages)利点 グローバル要素は、Mule アプリケーション開発者に再利用性、効率性、柔軟性という利点をもたらします。 - 再利用性 グローバル要素を 1 回だけ設定すれば、同じタイプのプロセッサー間で設定を共有できます。特に、SaaS アプリケーションやデータベースなどの外部ソースへの接続の詳細とログイン情報を定義する場合は、グローバル要素を設定すると便利です。 - 効率性 フロー内のプロセッサーにグローバル要素を共有させることで、同じ設定を何度も繰り返して変更する手間を省けます。たとえば、ログイン情報を使用して同じサービスに接続するコネクタが複数ある場合は、グローバル要素の設定を変更するだけで、そのグローバル要素を参照しているすべてのフロー要素に変更が適用されます。 - 柔軟性 フロー内の要素は、グローバル要素の設定を定義通りに適用することも、グローバル設定プロパティに変更を加えて使用することもできます。 ## [](#始める前に)始める前に [Anypoint Studio ビジュアルエディター](https://docs.mulesoft.com/studio/)​の機能を確認して、Anypoint Studio のグラフィカルユーザーインターフェースを使用した Mule アプリケーションの開発について学習し、グローバル要素を使用するコンテキストについて理解を深めてください。 ## [](#グローバル要素の作成)グローバル要素の作成 グローバル要素は 2 通りの方法で作成できます。 - Anypoint Studio キャンバスの ​**\[Global Elements (グローバル要素)\]**​ タブから - グローバル要素をサポートするコネクタまたはモジュールのプロパティパネルから ### [](#anypoint-studio-キャンバスから)Anypoint Studio キャンバスから 1. Anypoint Studio ビジュアルエディターで、​**\[Global Elements (グローバル要素)\]**​ タブをクリックして、アプリケーション内のすべてのグローバル要素のリストにアクセスします。 ![new-global-element](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-new-global-element.png) 2. **\[Create (作成)\]**​ をクリックして、新しいグローバル要素を追加します。 3. **\[Choose Global Type (グローバル種別の選択)\]**​ ウィザードで、ディレクトリ間を移動するか、または検索条件を使用して、作成するグローバル要素の種別を選択し、​**\[OK\]**​ をクリックします。 4. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 5. **\[OK\]**​ をクリックして保存します。 ### [](#コネクタまたはモジュールのプロパティパネルから)コネクタまたはモジュールのプロパティパネルから フロー内に配置したローカルコンポーネント内から新しいグローバル要素を作成する手順は次のとおりです。 1. グローバル要素を作成するコンポーネントをクリックします。 ![select-component-global-element](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-global-element-component.png) 2. プロパティパネルで、​**\[Connector Configuration (コネクタ設定)\]**​ の横にある追加アイコンをクリックします。 ![create-config-global-element](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-global-element-create.png) 3. 作成するグローバル要素種別で必要な項目をすべて設定します。 ## [](#関連情報)関連情報 - [グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/global-settings-configuration) # Global Element (グローバル要素) グローバル要素は、フロー内の要素 (数に制限なし) が共有できるパラメーターを含む再利用可能なオブジェクトです。グローバル要素は、Mule アプリケーション内の Anypoint Connector またはコンポーネントから参照します。 グローバル要素を使用することで、設定の詳細をフロー内の複数のローカル要素に適用できます。パラメーターと設定の詳細を定義したグローバル要素を 1 つだけ作成しておき、同じ設定を使用する任意のフロー要素からグローバル要素を参照します。このようにして、フロー要素間の一貫性を保つことができます。 一部のコンポーネントでは、プロパティをグローバル要素に格納する必要があります。 ## [](#advantages)利点 グローバル要素は、Mule アプリケーション開発者に再利用性、効率性、柔軟性という利点をもたらします。 - 再利用性 グローバル要素を 1 回だけ設定すれば、同じタイプのプロセッサー間で設定を共有できます。特に、SaaS アプリケーションやデータベースなどの外部ソースへの接続の詳細とログイン情報を定義する場合は、グローバル要素を設定すると便利です。 - 効率性 フロー内のプロセッサーにグローバル要素を共有させることで、同じ設定を何度も繰り返して変更する手間を省けます。たとえば、ログイン情報を使用して同じサービスに接続するコネクタが複数ある場合は、グローバル要素の設定を変更するだけで、そのグローバル要素を参照しているすべてのフロー要素に変更が適用されます。 - 柔軟性 フロー内の要素は、グローバル要素の設定を定義通りに適用することも、グローバル設定プロパティに変更を加えて使用することもできます。 ## [](#始める前に)始める前に [Anypoint Studio ビジュアルエディター](https://docs.mulesoft.com/studio/)​の機能を確認して、Anypoint Studio のグラフィカルユーザーインターフェースを使用した Mule アプリケーションの開発について学習し、グローバル要素を使用するコンテキストについて理解を深めてください。 ## [](#グローバル要素の作成)グローバル要素の作成 グローバル要素は 2 通りの方法で作成できます。 - Anypoint Studio キャンバスの ​**\[Global Elements (グローバル要素)\]**​ タブから - グローバル要素をサポートするコネクタまたはモジュールのプロパティパネルから ### [](#anypoint-studio-キャンバスから)Anypoint Studio キャンバスから 1. Anypoint Studio ビジュアルエディターで、​**\[Global Elements (グローバル要素)\]**​ タブをクリックして、アプリケーション内のすべてのグローバル要素のリストにアクセスします。 ![new-global-element](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-new-global-element.png) 2. **\[Create (作成)\]**​ をクリックして、新しいグローバル要素を追加します。 3. **\[Choose Global Type (グローバル種別の選択)\]**​ ウィザードで、ディレクトリ間を移動するか、または検索条件を使用して、作成するグローバル要素の種別を選択し、​**\[OK\]**​ をクリックします。 4. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 5. **\[OK\]**​ をクリックして保存します。 ### [](#コネクタまたはモジュールのプロパティパネルから)コネクタまたはモジュールのプロパティパネルから フロー内に配置したローカルコンポーネント内から新しいグローバル要素を作成する手順は次のとおりです。 1. グローバル要素を作成するコンポーネントをクリックします。 ![select-component-global-element](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-global-element-component.png) 2. プロパティパネルで、​**\[Connector Configuration (コネクタ設定)\]**​ の横にある追加アイコンをクリックします。 ![create-config-global-element](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-global-element-create.png) 3. 作成するグローバル要素種別で必要な項目をすべて設定します。 ## [](#関連情報)関連情報 - [グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/global-settings-configuration) # Global Element (グローバル要素) グローバル要素は、フロー内の要素 (数に制限なし) が共有できるパラメーターを含む再利用可能なオブジェクトです。グローバル要素は、Mule アプリケーション内の Anypoint Connector またはコンポーネントから参照します。 グローバル要素を使用することで、設定の詳細をフロー内の複数のローカル要素に適用できます。パラメーターと設定の詳細を定義したグローバル要素を 1 つだけ作成しておき、同じ設定を使用する任意のフロー要素からグローバル要素を参照します。このようにして、フロー要素間の一貫性を保つことができます。 一部のコンポーネントでは、プロパティをグローバル要素に格納する必要があります。 ## [](#advantages)利点 グローバル要素は、Mule アプリケーション開発者に再利用性、効率性、柔軟性という利点をもたらします。 - 再利用性 グローバル要素を 1 回だけ設定すれば、同じタイプのプロセッサー間で設定を共有できます。特に、SaaS アプリケーションやデータベースなどの外部ソースへの接続の詳細とログイン情報を定義する場合は、グローバル要素を設定すると便利です。 - 効率性 フロー内のプロセッサーにグローバル要素を共有させることで、同じ設定を何度も繰り返して変更する手間を省けます。たとえば、ログイン情報を使用して同じサービスに接続するコネクタが複数ある場合は、グローバル要素の設定を変更するだけで、そのグローバル要素を参照しているすべてのフロー要素に変更が適用されます。 - 柔軟性 フロー内の要素は、グローバル要素の設定を定義通りに適用することも、グローバル設定プロパティに変更を加えて使用することもできます。 ## [](#始める前に)始める前に [Anypoint Studio ビジュアルエディター](https://docs.mulesoft.com/studio/)​の機能を確認して、Anypoint Studio のグラフィカルユーザーインターフェースを使用した Mule アプリケーションの開発について学習し、グローバル要素を使用するコンテキストについて理解を深めてください。 ## [](#グローバル要素の作成)グローバル要素の作成 グローバル要素は 2 通りの方法で作成できます。 - Anypoint Studio キャンバスの ​**\[Global Elements (グローバル要素)\]**​ タブから - グローバル要素をサポートするコネクタまたはモジュールのプロパティパネルから ### [](#anypoint-studio-キャンバスから)Anypoint Studio キャンバスから 1. Anypoint Studio ビジュアルエディターで、​**\[Global Elements (グローバル要素)\]**​ タブをクリックして、アプリケーション内のすべてのグローバル要素のリストにアクセスします。 ![Mule のグローバル設定要素を作成および管理するメニュー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-new-global-element.png) 2. **\[Create (作成)\]**​ をクリックして、新しいグローバル要素を追加します。 3. **\[Choose Global Type (グローバル種別の選択)\]**​ ウィザードで、ディレクトリ間を移動するか、または検索条件を使用して、作成するグローバル要素の種別を選択し、​**\[OK\]**​ をクリックします。 4. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 5. **\[OK\]**​ をクリックして保存します。 ### [](#コネクタまたはモジュールのプロパティパネルから)コネクタまたはモジュールのプロパティパネルから フロー内に配置したローカルコンポーネント内から新しいグローバル要素を作成する手順は次のとおりです。 1. グローバル要素を作成するコンポーネントをクリックします。 ![エラー処理が含まれるフローコンポーネントの基本的なセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-global-element-component.png) 2. プロパティパネルで、​**\[Connector Configuration (コネクタ設定)\]**​ の横にある追加アイコンをクリックします。 ![Mule の新しいグローバル要素を作成するインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-global-element-create.png) 3. 作成するグローバル要素種別で必要な項目をすべて設定します。 ## [](#関連情報)関連情報 - [グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/global-settings-configuration) # Global Element (グローバル要素) グローバル要素は、フロー内の要素 (数に制限なし) が共有できるパラメーターを含む再利用可能なオブジェクトです。グローバル要素は、Mule アプリケーション内の Anypoint Connector またはコンポーネントから参照します。 グローバル要素を使用することで、設定の詳細をフロー内の複数のローカル要素に適用できます。パラメーターと設定の詳細を定義したグローバル要素を 1 つだけ作成しておき、同じ設定を使用する任意のフロー要素からグローバル要素を参照します。このようにして、フロー要素間の一貫性を保つことができます。 一部のコンポーネントでは、プロパティをグローバル要素に格納する必要があります。 ## [](#advantages)利点 グローバル要素は、Mule アプリケーション開発者に再利用性、効率性、柔軟性という利点をもたらします。 - 再利用性 グローバル要素を 1 回だけ設定すれば、同じタイプのプロセッサー間で設定を共有できます。特に、SaaS アプリケーションやデータベースなどの外部ソースへの接続の詳細とログイン情報を定義する場合は、グローバル要素を設定すると便利です。 - 効率性 フロー内のプロセッサーにグローバル要素を共有させることで、同じ設定を何度も繰り返して変更する手間を省けます。たとえば、ログイン情報を使用して同じサービスに接続するコネクタが複数ある場合は、グローバル要素の設定を変更するだけで、そのグローバル要素を参照しているすべてのフロー要素に変更が適用されます。 - 柔軟性 フロー内の要素は、グローバル要素の設定を定義通りに適用することも、グローバル設定プロパティに変更を加えて使用することもできます。 ## [](#始める前に)始める前に [Anypoint Studio ビジュアルエディター](https://docs.mulesoft.com/studio/)​の機能を確認して、Anypoint Studio のグラフィカルユーザーインターフェースを使用した Mule アプリケーションの開発について学習し、グローバル要素を使用するコンテキストについて理解を深めてください。 ## [](#グローバル要素の作成)グローバル要素の作成 グローバル要素は 2 通りの方法で作成できます。 - Anypoint Studio キャンバスの ​**\[Global Elements (グローバル要素)\]**​ タブから - グローバル要素をサポートするコネクタまたはモジュールのプロパティパネルから ### [](#anypoint-studio-キャンバスから)Anypoint Studio キャンバスから 1. Anypoint Studio ビジュアルエディターで、​**\[Global Elements (グローバル要素)\]**​ タブをクリックして、アプリケーション内のすべてのグローバル要素のリストにアクセスします。 ![Mule のグローバル設定要素を作成および管理するメニュー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-new-global-element.png) 2. **\[Create (作成)\]**​ をクリックして、新しいグローバル要素を追加します。 3. **\[Choose Global Type (グローバル種別の選択)\]**​ ウィザードで、ディレクトリ間を移動するか、または検索条件を使用して、作成するグローバル要素の種別を選択し、​**\[OK\]**​ をクリックします。 4. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 5. **\[OK\]**​ をクリックして保存します。 ### [](#コネクタまたはモジュールのプロパティパネルから)コネクタまたはモジュールのプロパティパネルから フロー内に配置したローカルコンポーネント内から新しいグローバル要素を作成する手順は次のとおりです。 1. グローバル要素を作成するコンポーネントをクリックします。 ![エラー処理が含まれるフローコンポーネントの基本的なセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-global-element-component.png) 2. プロパティパネルで、​**\[Connector Configuration (コネクタ設定)\]**​ の横にある追加アイコンをクリックします。 ![Mule の新しいグローバル要素を作成するインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-global-element-create.png) 3. 作成するグローバル要素種別で必要な項目をすべて設定します。 ## [](#関連情報)関連情報 - [グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/global-settings-configuration) # HTTP Connector の使用の移行 HTTP Connector のほとんどの部分は、Mule 4 モデルに適合されています。 - 設定プロパティは接続コンポーネントに移行されています (可能な場合)。 - メッセージプロセッサーは、適切な操作にリファクタリングされています。 - アウトバウンドプロパティ (​`http.status`​ など) は排除され、明示的なプロパティになりました。 - インバウンドプロパティ (​`http.queryParams`​ など) も排除され、HTTP 固有のメッセージ属性になりました。 - スレッドがすべて Mule Runtime レベルで処理されるようになったため、スレッド設定も排除されています。 - `application/x-www-form-urlencoded`​ と ​`multipart/*`​ のメディア種別の特別処理が排除され、DataWeave になりました。 - RAML メタデータのサポートが HTTP 要求操作から排除され、REST になりました。 ## [](#このトピックの内容)このトピックの内容 - [HTTP リスナー](#http_listener) - [HTTP 要求](#http-request) - [HTTP 静的リソースハンドラー](#http-static-resource) - [HTTP 基本セキュリティ検索条件](#http-basic-authentication) - [HTTP MIME タイプ解析](#http-mime-types) ## [](#http_listener)HTTP リスナー HTTP リスナーは、応答ビルダーの設定と、設定プロパティの特定の接続コンポーネントへのカプセル化にのみ大きな変更が行われています。 ### [](#configuration-設定)Configuration (設定) 次のプロパティやコンポーネントは、内部の ​`http:listener-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `connectionIdleTimeout` - TLS Context Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#リスナー)リスナー HTTP リスナーのプロパティは、​`http:response-builder`​ と ​`http:error-response-builder`​ を除いて同じままです。これらは名前が ​`http:response`​ と ​`http:error-response`​ に変更されたほか、アウトバウンドプロパティの暗黙的な処理へのサポートが排除され、ヘッダーを 1 つの式で定義することになりました。さらに、発信 HTTP メッセージ本文を 1 つの式で定義できる、新しい ​`http:body`​ コンポーネントをサポートします。 Mule 3 の例 次の例では、暗黙的なアウトバウンドプロパティ (​`Mule 3.6.0`​)、1 つのヘッダー参照 (​`Mule 3.7.0`​)、式参照 (​`Mule 3.8.0`​、​`Mule 3.9.0`​) を使用してセットアップされた応答で多数の ​`User-Agent`​ ヘッダーが送信されます。他方、エラー応答は ​`Date`​ ヘッダーと、​`User-Agent`​ のアウトバウンドプロパティを特長とします。 ```xml ... ``` Mule 4 の例 ​`statusCode`​ と ​`reasonPhrase`​ プロパティは同じままですが、すべてのヘッダーが DataWeave 式を使用して明示的に追加されるようになりました。注意すべき重要な点は、アウトバウンドプロパティの ​`http.status`​ と ​`http.reason`​ を使用する代わりに、明示的な ​`statusCode`​ と​`reasonPhrase`​ も指定する必要があることです。 ```xml #[{ 'User-Agent' : 'Mule 3.6.0', 'User-Agent' : 'Mule 3.7.0', 'User-Agent' : 'Mule 3.8.0', 'User-Agent' : 'Mule 3.9.0' }] #[{ 'User-Agent': 'Mule 3.6.0', 'Date': now() }] ... ``` #### [](#属性)属性 HTTP リスナーは、Mule の新しいメッセージ構造に従って、すべての要求メタデータを特定の HTTP 要求属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

メソッド

#[inboundProperties.'http.method']

#[attributes.method]

パス

#[inboundProperties.'http.listener.path']

#[attributes.listenerPath]

相対パス

#[inboundProperties.'http.relative.path']

#[attributes.relativePath]

要求 URI

#[inboundProperties.'http.request.uri']

#[attributes.requestUri]

クエリ文字列

#[inboundProperties.'http.query.string']

#[attributes.queryString]

クエリパラメーター

#[inboundProperties.'http.query.params']

#[attributes.queryParams]

URI パラメーター

#[inboundProperties.'http.uri.params']

#[attributes.uriParams]

バージョン

#[inboundProperties.'http.version']

#[attributes.version]

スキーマ

#[inboundProperties.'http.scheme']

#[attributes.scheme]

ヘッダー

#[inboundProperties]

#[attributes.headers]

リモートアドレス

#[inboundProperties.'http.remote.address']

#[attributes.remoteAddress]

クライアント証明書

#[inboundProperties.'http.client.cert']

#[attributes.clientCertificate]
HTTP ヘッダーはインバウンドプロパティに直接マップされていましたが、専用オブジェクトが導入されました。以下は、ヘッダーを取得する方法の例を示しています。 - Mule 3: `#[inboundProperties.'host']` - Mule 4: `#[attributes.headers.'host']` #### [](#http-要求の文字のエンコード)HTTP 要求の文字のエンコード Mule 4 で HTTP リスナーへの HTTP 要求を実行するときに URI が無効にならないように、 [​RFC](https://tools.ietf.org/html/rfc1738#page-3)​ の推奨事項に従って、HTTP 要求で設定する ​`{`​ や ​`}`​ などの文字をエンコードしてください。 Studio で HTTP リスナーの ​**\[Path (パス)\]**​ 項目に要求 URL を設定する場合と、curl 要求コマンドを送信する場合の両方で、これらの文字をエンコードします。次の例では、URL ​`path=/profiles/{profileid}/credit`​ の文字 ​`{`​ を ​`%7B`​ にエンコードし、​`}`​ を ​`%7D`​ にエンコードします。 1. Studio で、フローから \[HTTP\] の ​**\[Listener\]**​ の提供元を選択します。 2. **\[Path (パス)\]**​ 項目で、エンコードした文字を使用して相対パス URL を設定します。例: `/profiles/%7Bprofileid%7D/credit` 3. Studio でアプリケーションのすべての変更を保存します。 4. curl コマンド ​`http://localhost:8084/test?path=/profiles/%7Bprofileid%7D/credit`​ を実行します。 ## [](#http-request)HTTP 要求 HTTP リスナーと同様、HTTP 要求操作の変更の大半は、設定プロパティの接続コンポーネント内へのカプセル化と、要求作成プロセスに関連しています。 ### [](#configuration-設定-2)Configuration (設定) 次のプロパティやコンポーネントは、内部の ​`http:request-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `maxConnections` - `connectionIdleTimeout` - `streamResponse` - `responseBufferSize` - HTTP Authentication - HTTP Proxy - TLS Context - TCP クライアントソケットのプロパティ Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` RAML メタデータのサポートは排除されました。REST Connect で、指定した RAML の特定の再利用可能なコネクタを生成できるようになったためです。 #### [](#http-authentication)HTTP Authentication HTTP 認証設定が ​`http:request-connection`​ コンポーネントの一部になったほか、​`http:authentication`​ コンポーネント内にも配置する必要があります。 この変更は、サポートされている全種類の認証 (基本、ダイジェスト、NTLM、OAuth2) に適用されます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#http-proxy)HTTP Proxy HTTP Authentication コンポーネントと同様に、HTTP プロキシを設定する場合、あらゆる種類のプロキシにラッピング ​`http:proxy-config`​ コンポーネントが必要になりました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#tcp-クライアントソケットのプロパティ)TCP クライアントソケットのプロパティ Mule 3 では、TCP クライアントソケットのプロパティが TCP トランスポートに基づいて定義されていました。Mule 4 ではこのトランスポートが Sockets Connector になったため、プロパティを設定する必要があります。また、これらのプロパティは ​`http:client-socket-properties`​ コンポーネントでラップする必要があります。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#要求)要求 HTTP 要求のプロパティは、​`source`​ (式と変換をサポートする ​`http:body`​ コンポーネントに置き換え) と ​`http:request-builder`​ (削除済み) を除いて同じままです。ヘッダー、クエリ、URI のパラメーターは DataWeave 式で明示的に定義するようになりました。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... #[vars.customSource] #[{ 'Host': 'www.example.com' 'Transfer-Encoding' : 'chunked' }] #[{ 'id' : vars.songId }] #[vars.params] ... ``` #### [](#属性-2)属性 HTTP 要求も HTTP リスナーと同様に、すべての応答メタデータを特定の HTTP 応答属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

状況コード

#[inboundProperties.'http.status']

#[attributes.statusCode]

理由を示す語句

#[inboundProperties.'http.reason']

#[attributes.reasonPhrase]

ヘッダー

#[inboundProperties]

#[attributes.headers]
ヘッダーが HTTP リスナーの場合と同じように処理されています。 ## [](#http-static-resource)HTTP 静的リソースハンドラー HTTP 静的リソースハンドラーが、Mule 4 の操作モデルに適合され、​`http:load-static-resource`​ という名前に変更されました。​`resourceBase`​ プロパティも ​`resourceBasePath`​ という名前に変更されています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` この操作は HTTP リスナー取得元と併用することのみを意図していますが、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティも導入されています。 ## [](#http-basic-authentication)HTTP 基本セキュリティ検索条件 HTTP 基本セキュリティ検索条件は、DataWeave を ​`securityProviders`​ プロパティの取得元としてサポートすることと、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティを導入したこと以外は変更されていません (HTTP load static resource 操作と同じです)。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` 完全な設定例については、​[「Spring セキュリティの LDAP プロバイダーの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.3/setting-up-ldap-provider-for-spring-security)​を参照してください。 ## [](#http-mime-types)HTTP MIME タイプ解析 Mule 3 の HTTP Connector の特長は、​`application/x-www-form-urlencoded`​ や ​`multipart/form-data`​ タイプ (および他のサブタイプ) の本文を受信したときに、要求や応答を解析するオプションがあることでした。アウトバウンド要求や応答に解析対象のオブジェクトがあると、一貫性を維持する目的でこうしたタイプの本文に戻されていました。 他方、DataWeave 2.0 でこれらの MIME タイプが処理されるようになったため、Mule 4 では HTTP 解析が排除され、HTTP コンポーネントは常にバイナリデータストリームを提供し、また必要とするようになっています。 解析対象であったタイプの使用を移行する方法については、以下を参照してください。 ### [](#applicationx-www-form-urlencoded)application/x-www-form-urlencoded Mule 3 では、​`Map`​ ペイロードを ​`application/x-www-form-urlencoded`​ コンテンツと同様に使用できました。アウトバウンドトラフィックの場合、​`Map`​ ペイロードが存在すれば、各キー - 値ペアを使用して ​`application/x-www-form-urlencoded`​ 本文が生成されることを意味しました。インバウンドトラフィックの場合は、その本文の各キー - 値ペアが ​`Map`​ に配置されることを意味しました。 現在は、DataWeave で ​`application/x-www-form-urlencoded`​ の読み取りや書き取りができることから、HTTP のさまざまな MIME タイプを簡単かつ一貫した方法で処理できるようになりました。 Mule 3 の例 この例では、​`song=Snow+Poems&artist=TQP`​ のペイロードが送信され、保存されていた ID を記した応答 (​`song=Snow+Poems&artist=TQP&id=49`​) が返されます。 ```xml ``` Mule 4 の例 コンテンツを読み取るための構文は同じままですが、実際にデータを変換しているため、出力種別を指定しなければならなくなった点のみが異なります。 ```xml ... #[ %dw 2.0 output application/x-www-form-urlencoded --- { song: "Snow Poems", artist: "TQP" }] ... ``` キーにはいくつかの値を追加できます。このデータにアクセスするには、スターセレクターを使用して、関連するすべての値のコレクションを取得する必要があります。たとえば、​`#[payload.*artist]`​ は ​`Under Pressure`​ という歌で ​`David Bowie`​ と ​`Queen`​ を記載したリストを返します。 ### [](#http_multipart)multipart/\* Mule 3 では、Mule メッセージの添付ファイルを、マルチパートコンテンツと同様に使用していました。 アウトバウンドトラフィックの場合、添付ファイルが存在すれば、それらが ​`multipart/form-data`​ 本文の一部として使用されることを意味しました。インバウンドトラフィックの場合は、その本文の各部が Mule メッセージの添付ファイルにマッピングされることを意味しました。 Mule 4 では、Mule メッセージにファイルが添付されることがなくなりました。代わりに、JSON または XML コンテンツと同様に、DataWeave を使用してマルチパートコンテンツの読み取りや書き込みを行うことができます。 Mule 3 の例 この例では、2 つの主要な JSON 部分がある ​`multipart/form-data`​ 本文を受け取ります。1 つは注文で、もう 1 つは注文を生成したパートナーです。パートナー名をログに記録すると、注文 ID が保存され、注文を受けたことを伝える簡単なメッセージと、その注文用に生成された領収書 PDF について記載した ​`multipart/form-data`​ 応答が生成されます。 ```xml ``` Mule 4 の例 今後は添付ファイルの処理に伴う煩わしさから開放され、​`content`​ キーワードを使用して名前で各部にアクセスするだけです。マルチパート応答は、DataWeave を使用して HTTP レスポンスボディに生成されます (このボディ内で簡単にカスタマイズできます)。 ```xml ``` ここで注意すべき重要な点は、​`http:body`​ 機能を活用していますが、最終的な変換コンポーネントを使用してもおそらく同じ結果が得られることです。 境界が自動生成されるため、正しいコンテンツタイプのヘッダーが生成されます。詳細は、​[「Multipart Format (Form-Data) (マルチパート形式 (フォームデータ))」](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats-multipart)​を参照してください。 == 関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-core) [REST Connect](https://docs.mulesoft.com/jp/exchange/to-deploy-using-rest-connect) # HTTP Connector の使用の移行 HTTP Connector のほとんどの部分は、Mule 4 モデルに適合されています。 - 設定プロパティは接続コンポーネントに移行されています (可能な場合)。 - メッセージプロセッサーは、適切な操作にリファクタリングされています。 - アウトバウンドプロパティ (​`http.status`​ など) は排除され、明示的なプロパティになりました。 - インバウンドプロパティ (​`http.queryParams`​ など) も排除され、HTTP 固有のメッセージ属性になりました。 - スレッドがすべて Mule Runtime レベルで処理されるようになったため、スレッド設定も排除されています。 - `application/x-www-form-urlencoded`​ と ​`multipart/*`​ のメディア種別の特別処理が排除され、DataWeave になりました。 - RAML メタデータのサポートが HTTP 要求操作から排除され、REST になりました。 ## [](#このトピックの内容)このトピックの内容 - [HTTP リスナー](#http_listener) - [HTTP 要求](#http-request) - [HTTP 静的リソースハンドラー](#http-static-resource) - [HTTP 基本セキュリティ検索条件](#http-basic-authentication) - [HTTP MIME タイプ解析](#http-mime-types) ## [](#http_listener)HTTP リスナー HTTP リスナーは、応答ビルダーの設定と、設定プロパティの特定の接続コンポーネントへのカプセル化にのみ大きな変更が行われています。 ### [](#configuration-設定)Configuration (設定) 次のプロパティやコンポーネントは、内部の ​`http:listener-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `connectionIdleTimeout` - TLS Context Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#リスナー)リスナー HTTP リスナーのプロパティは、​`http:response-builder`​ と ​`http:error-response-builder`​ を除いて同じままです。これらは名前が ​`http:response`​ と ​`http:error-response`​ に変更されたほか、アウトバウンドプロパティの暗黙的な処理へのサポートが排除され、ヘッダーを 1 つの式で定義することになりました。さらに、発信 HTTP メッセージ本文を 1 つの式で定義できる、新しい ​`http:body`​ コンポーネントをサポートします。 Mule 3 の例 次の例では、暗黙的なアウトバウンドプロパティ (​`Mule 3.6.0`​)、1 つのヘッダー参照 (​`Mule 3.7.0`​)、式参照 (​`Mule 3.8.0`​、​`Mule 3.9.0`​) を使用してセットアップされた応答で多数の ​`User-Agent`​ ヘッダーが送信されます。他方、エラー応答は ​`Date`​ ヘッダーと、​`User-Agent`​ のアウトバウンドプロパティを特長とします。 ```xml ... ``` Mule 4 の例 ​`statusCode`​ と ​`reasonPhrase`​ プロパティは同じままですが、すべてのヘッダーが DataWeave 式を使用して明示的に追加されるようになりました。注意すべき重要な点は、アウトバウンドプロパティの ​`http.status`​ と ​`http.reason`​ を使用する代わりに、明示的な ​`statusCode`​ と​`reasonPhrase`​ も指定する必要があることです。 ```xml #[{ 'User-Agent' : 'Mule 3.6.0', 'User-Agent' : 'Mule 3.7.0', 'User-Agent' : 'Mule 3.8.0', 'User-Agent' : 'Mule 3.9.0' }] #[{ 'User-Agent': 'Mule 3.6.0', 'Date': now() }] ... ``` #### [](#属性)属性 HTTP リスナーは、Mule の新しいメッセージ構造に従って、すべての要求メタデータを特定の HTTP 要求属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

メソッド

#[inboundProperties.'http.method']

#[attributes.method]

パス

#[inboundProperties.'http.listener.path']

#[attributes.listenerPath]

相対パス

#[inboundProperties.'http.relative.path']

#[attributes.relativePath]

要求 URI

#[inboundProperties.'http.request.uri']

#[attributes.requestUri]

クエリ文字列

#[inboundProperties.'http.query.string']

#[attributes.queryString]

クエリパラメーター

#[inboundProperties.'http.query.params']

#[attributes.queryParams]

URI パラメーター

#[inboundProperties.'http.uri.params']

#[attributes.uriParams]

バージョン

#[inboundProperties.'http.version']

#[attributes.version]

スキーマ

#[inboundProperties.'http.scheme']

#[attributes.scheme]

ヘッダー

#[inboundProperties]

#[attributes.headers]

リモートアドレス

#[inboundProperties.'http.remote.address']

#[attributes.remoteAddress]

クライアント証明書

#[inboundProperties.'http.client.cert']

#[attributes.clientCertificate]
HTTP ヘッダーはインバウンドプロパティに直接マップされていましたが、専用オブジェクトが導入されました。以下は、ヘッダーを取得する方法の例を示しています。 - Mule 3: `#[inboundProperties.'host']` - Mule 4: `#[attributes.headers.'host']` #### [](#http-要求の文字のエンコード)HTTP 要求の文字のエンコード Mule 4 で HTTP リスナーへの HTTP 要求を実行するときに URI が無効にならないように、 [​RFC](https://tools.ietf.org/html/rfc1738#page-3)​ の推奨事項に従って、HTTP 要求で設定する ​`{`​ や ​`}`​ などの文字をエンコードしてください。 Studio で HTTP リスナーの ​**\[Path (パス)\]**​ 項目に要求 URL を設定する場合と、curl 要求コマンドを送信する場合の両方で、これらの文字をエンコードします。次の例では、URL ​`path=/profiles/{profileid}/credit`​ の文字 ​`{`​ を ​`%7B`​ にエンコードし、​`}`​ を ​`%7D`​ にエンコードします。 1. Studio で、フローから \[HTTP\] の ​**\[Listener\]**​ の提供元を選択します。 2. **\[Path (パス)\]**​ 項目で、エンコードした文字を使用して相対パス URL を設定します。例: `/profiles/%7Bprofileid%7D/credit` 3. Studio でアプリケーションのすべての変更を保存します。 4. curl コマンド ​`http://localhost:8084/test?path=/profiles/%7Bprofileid%7D/credit`​ を実行します。 ## [](#http-request)HTTP 要求 HTTP リスナーと同様、HTTP 要求操作の変更の大半は、設定プロパティの接続コンポーネント内へのカプセル化と、要求作成プロセスに関連しています。 ### [](#configuration-設定-2)Configuration (設定) 次のプロパティやコンポーネントは、内部の ​`http:request-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `maxConnections` - `connectionIdleTimeout` - `streamResponse` - `responseBufferSize` - HTTP Authentication - HTTP Proxy - TLS Context - TCP クライアントソケットのプロパティ Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` RAML メタデータのサポートは排除されました。REST Connect で、指定した RAML の特定の再利用可能なコネクタを生成できるようになったためです。 #### [](#http-authentication)HTTP Authentication HTTP 認証設定が ​`http:request-connection`​ コンポーネントの一部になったほか、​`http:authentication`​ コンポーネント内にも配置する必要があります。 この変更は、サポートされている全種類の認証 (基本、ダイジェスト、NTLM、OAuth2) に適用されます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#http-proxy)HTTP Proxy HTTP Authentication コンポーネントと同様に、HTTP プロキシを設定する場合、あらゆる種類のプロキシにラッピング ​`http:proxy-config`​ コンポーネントが必要になりました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#tcp-クライアントソケットのプロパティ)TCP クライアントソケットのプロパティ Mule 3 では、TCP クライアントソケットのプロパティが TCP トランスポートに基づいて定義されていました。Mule 4 ではこのトランスポートが Sockets Connector になったため、プロパティを設定する必要があります。また、これらのプロパティは ​`http:client-socket-properties`​ コンポーネントでラップする必要があります。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#要求)要求 HTTP 要求のプロパティは、​`source`​ (式と変換をサポートする ​`http:body`​ コンポーネントに置き換え) と ​`http:request-builder`​ (削除済み) を除いて同じままです。ヘッダー、クエリ、URI のパラメーターは DataWeave 式で明示的に定義するようになりました。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... #[vars.customSource] #[{ 'Host': 'www.example.com' 'Transfer-Encoding' : 'chunked' }] #[{ 'id' : vars.songId }] #[vars.params] ... ``` #### [](#属性-2)属性 HTTP 要求も HTTP リスナーと同様に、すべての応答メタデータを特定の HTTP 応答属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

状況コード

#[inboundProperties.'http.status']

#[attributes.statusCode]

理由を示す語句

#[inboundProperties.'http.reason']

#[attributes.reasonPhrase]

ヘッダー

#[inboundProperties]

#[attributes.headers]
ヘッダーが HTTP リスナーの場合と同じように処理されています。 ## [](#http-static-resource)HTTP 静的リソースハンドラー HTTP 静的リソースハンドラーが、Mule 4 の操作モデルに適合され、​`http:load-static-resource`​ という名前に変更されました。​`resourceBase`​ プロパティも ​`resourceBasePath`​ という名前に変更されています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` この操作は HTTP リスナー取得元と併用することのみを意図していますが、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティも導入されています。 ## [](#http-basic-authentication)HTTP 基本セキュリティ検索条件 HTTP 基本セキュリティ検索条件は、DataWeave を ​`securityProviders`​ プロパティの取得元としてサポートすることと、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティを導入したこと以外は変更されていません (HTTP load static resource 操作と同じです)。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` 完全な設定例については、​[「Spring セキュリティの LDAP プロバイダーの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.4/setting-up-ldap-provider-for-spring-security)​を参照してください。 ## [](#http-mime-types)HTTP MIME タイプ解析 Mule 3 の HTTP Connector の特長は、​`application/x-www-form-urlencoded`​ や ​`multipart/form-data`​ タイプ (および他のサブタイプ) の本文を受信したときに、要求や応答を解析するオプションがあることでした。アウトバウンド要求や応答に解析対象のオブジェクトがあると、一貫性を維持する目的でこうしたタイプの本文に戻されていました。 他方、DataWeave 2.0 でこれらの MIME タイプが処理されるようになったため、Mule 4 では HTTP 解析が排除され、HTTP コンポーネントは常にバイナリデータストリームを提供し、また必要とするようになっています。 解析対象であったタイプの使用を移行する方法については、以下を参照してください。 ### [](#applicationx-www-form-urlencoded)application/x-www-form-urlencoded Mule 3 では、​`Map`​ ペイロードを ​`application/x-www-form-urlencoded`​ コンテンツと同様に使用できました。アウトバウンドトラフィックの場合、​`Map`​ ペイロードが存在すれば、各キー - 値ペアを使用して ​`application/x-www-form-urlencoded`​ 本文が生成されることを意味しました。インバウンドトラフィックの場合は、その本文の各キー - 値ペアが ​`Map`​ に配置されることを意味しました。 現在は、DataWeave で ​`application/x-www-form-urlencoded`​ の読み取りや書き取りができることから、HTTP のさまざまな MIME タイプを簡単かつ一貫した方法で処理できるようになりました。 Mule 3 の例 この例では、​`song=Snow+Poems&artist=TQP`​ のペイロードが送信され、保存されていた ID を記した応答 (​`song=Snow+Poems&artist=TQP&id=49`​) が返されます。 ```xml ``` Mule 4 の例 コンテンツを読み取るための構文は同じままですが、実際にデータを変換しているため、出力種別を指定しなければならなくなった点のみが異なります。 ```xml ... #[ %dw 2.0 output application/x-www-form-urlencoded --- { song: "Snow Poems", artist: "TQP" }] ... ``` キーにはいくつかの値を追加できます。このデータにアクセスするには、スターセレクターを使用して、関連するすべての値のコレクションを取得する必要があります。たとえば、​`#[payload.*artist]`​ は ​`Under Pressure`​ という歌で ​`David Bowie`​ と ​`Queen`​ を記載したリストを返します。 ### [](#http_multipart)multipart/\* Mule 3 では、Mule メッセージの添付ファイルを、マルチパートコンテンツと同様に使用していました。 アウトバウンドトラフィックの場合、添付ファイルが存在すれば、それらが ​`multipart/form-data`​ 本文の一部として使用されることを意味しました。インバウンドトラフィックの場合は、その本文の各部が Mule メッセージの添付ファイルにマッピングされることを意味しました。 Mule 4 では、Mule メッセージにファイルが添付されることがなくなりました。代わりに、JSON または XML コンテンツと同様に、DataWeave を使用してマルチパートコンテンツの読み取りや書き込みを行うことができます。 Mule 3 の例 この例では、2 つの主要な JSON 部分がある ​`multipart/form-data`​ 本文を受け取ります。1 つは注文で、もう 1 つは注文を生成したパートナーです。パートナー名をログに記録すると、注文 ID が保存され、注文を受けたことを伝える簡単なメッセージと、その注文用に生成された領収書 PDF について記載した ​`multipart/form-data`​ 応答が生成されます。 ```xml ``` Mule 4 の例 今後は添付ファイルの処理に伴う煩わしさから開放され、​`content`​ キーワードを使用して名前で各部にアクセスするだけです。マルチパート応答は、DataWeave を使用して HTTP レスポンスボディに生成されます (このボディ内で簡単にカスタマイズできます)。 ```xml ``` ここで注意すべき重要な点は、​`http:body`​ 機能を活用していますが、最終的な変換コンポーネントを使用してもおそらく同じ結果が得られることです。 境界が自動生成されるため、正しいコンテンツタイプのヘッダーが生成されます。詳細は、​[「Multipart Format (Form-Data) (マルチパート形式 (フォームデータ))」](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-multipart)​を参照してください。 == 関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-core) [REST Connect](https://docs.mulesoft.com/jp/exchange/to-deploy-using-rest-connect) # HTTP Connector の使用の移行 HTTP Connector のほとんどの部分は、Mule 4 モデルに適合されています。 - 設定プロパティは接続コンポーネントに移行されています (可能な場合)。 - メッセージプロセッサーは、適切な操作にリファクタリングされています。 - アウトバウンドプロパティ (​`http.status`​ など) は排除され、明示的なプロパティになりました。 - インバウンドプロパティ (​`http.queryParams`​ など) も排除され、HTTP 固有のメッセージ属性になりました。 - スレッドがすべて Mule Runtime レベルで処理されるようになったため、スレッド設定も排除されています。 - `application/x-www-form-urlencoded`​ と ​`multipart/*`​ のメディア種別の特別処理が排除され、DataWeave になりました。 - RAML メタデータのサポートが HTTP 要求操作から排除され、REST になりました。 ## [](#このトピックの内容)このトピックの内容 - [HTTP Listener (HTTP リスナー)](#http_listener) - [HTTP 要求](#http-request) - [HTTP 静的リソースハンドラー](#http-static-resource) - [HTTP 基本セキュリティ検索条件](#http-basic-authentication) - [HTTP MIME タイプ解析](#http-mime-types) ## [](#http_listener)HTTP Listener (HTTP リスナー) HTTP リスナーは、応答ビルダーの設定と、設定プロパティの特定の接続コンポーネントへのカプセル化にのみ大きな変更が行われています。 ### [](#設定)設定 次のプロパティやコンポーネントは、内部の ​`http:listener-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `connectionIdleTimeout` - TLS Context Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#リスナー)リスナー HTTP リスナーのプロパティは、​`http:response-builder`​ と ​`http:error-response-builder`​ を除いて同じままです。これらは名前が ​`http:response`​ と ​`http:error-response`​ に変更されたほか、アウトバウンドプロパティの暗黙的な処理へのサポートが排除され、ヘッダーを 1 つの式で定義することになりました。さらに、発信 HTTP メッセージ本文を 1 つの式で定義できる、新しい ​`http:body`​ コンポーネントをサポートします。 Mule 3 の例 次の例では、暗黙的なアウトバウンドプロパティ (​`Mule 3.6.0`​)、1 つのヘッダー参照 (​`Mule 3.7.0`​)、式参照 (​`Mule 3.8.0`​、​`Mule 3.9.0`​) を使用してセットアップされた応答で多数の ​`User-Agent`​ ヘッダーが送信されます。他方、エラー応答は ​`Date`​ ヘッダーと、​`User-Agent`​ のアウトバウンドプロパティを特長とします。 ```xml ... ``` Mule 4 の例 ​`statusCode`​ と ​`reasonPhrase`​ プロパティは同じままですが、すべてのヘッダーが DataWeave 式を使用して明示的に追加されるようになりました。注意すべき重要な点は、アウトバウンドプロパティの ​`http.status`​ と ​`http.reason`​ を使用する代わりに、明示的な ​`statusCode`​ と​`reasonPhrase`​ も指定する必要があることです。 ```xml #[{ 'User-Agent' : 'Mule 3.6.0', 'User-Agent' : 'Mule 3.7.0', 'User-Agent' : 'Mule 3.8.0', 'User-Agent' : 'Mule 3.9.0' }] #[{ 'User-Agent': 'Mule 3.6.0', 'Date': now() }] ... ``` #### [](#属性)属性 HTTP リスナーは、Mule の新しいメッセージ構造に従って、すべての要求メタデータを特定の HTTP 要求属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

メソッド

#[inboundProperties.'http.method']

#[attributes.method]

パス

#[inboundProperties.'http.listener.path']

#[attributes.listenerPath]

相対パス

#[inboundProperties.'http.relative.path']

#[attributes.relativePath]

要求 URI

#[inboundProperties.'http.request.uri']

#[attributes.requestUri]

クエリ文字列

#[inboundProperties.'http.query.string']

#[attributes.queryString]

クエリパラメーター

#[inboundProperties.'http.query.params']

#[attributes.queryParams]

URI パラメーター

#[inboundProperties.'http.uri.params']

#[attributes.uriParams]

バージョン

#[inboundProperties.'http.version']

#[attributes.version]

スキーマ

#[inboundProperties.'http.scheme']

#[attributes.scheme]

ヘッダー

#[inboundProperties]

#[attributes.headers]

リモートアドレス

#[inboundProperties.'http.remote.address']

#[attributes.remoteAddress]

クライアント証明書

#[inboundProperties.'http.client.cert']

#[attributes.clientCertificate]
HTTP ヘッダーはインバウンドプロパティに直接マップされていましたが、専用オブジェクトが導入されました。以下は、ヘッダーを取得する方法の例を示しています。 - Mule 3: `#[inboundProperties.'host']` - Mule 4: `#[attributes.headers.'host']` #### [](#http-要求の文字のエンコード)HTTP 要求の文字のエンコード Mule 4 で HTTP リスナーへの HTTP 要求を実行するときに URI が無効にならないように、 [​RFC](https://tools.ietf.org/html/rfc1738#page-3)​ の推奨事項に従って、HTTP 要求で設定する ​`{`​ や ​`}`​ などの文字をエンコードしてください。 Studio で HTTP リスナーの ​**\[Path (パス)\]**​ 項目に要求 URL を設定する場合と、curl 要求コマンドを送信する場合の両方で、これらの文字をエンコードします。次の例では、URL ​`path=/profiles/{profileid}/credit`​ の文字 ​`{`​ を ​`%7B`​ にエンコードし、​`}`​ を ​`%7D`​ にエンコードします。 1. Studio で、フローから \[HTTP\] の ​**\[Listener\]**​ の提供元を選択します。 2. **\[Path (パス)\]**​ 項目で、エンコードした文字を使用して相対パス URL を設定します。例: `/profiles/%7Bprofileid%7D/credit` 3. Studio でアプリケーションのすべての変更を保存します。 4. curl コマンド ​`http://localhost:8084/test?path=/profiles/%7Bprofileid%7D/credit`​ を実行します。 ## [](#http-request)HTTP 要求 HTTP リスナーと同様、HTTP 要求操作の変更の大半は、設定プロパティの接続コンポーネント内へのカプセル化と、要求作成プロセスに関連しています。 ### [](#設定-2)設定 次のプロパティやコンポーネントは、内部の ​`http:request-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `maxConnections` - `connectionIdleTimeout` - `streamResponse` - `responseBufferSize` - HTTP Authentication - HTTP Proxy - TLS Context - TCP クライアントソケットのプロパティ Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` RAML メタデータのサポートは排除されました。REST Connect で、指定した RAML の特定の再利用可能なコネクタを生成できるようになったためです。 #### [](#http-authentication)HTTP Authentication HTTP 認証設定が ​`http:request-connection`​ コンポーネントの一部になったほか、​`http:authentication`​ コンポーネント内にも配置する必要があります。 この変更は、サポートされている全種類の認証 (基本、ダイジェスト、NTLM、OAuth2) に適用されます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#http-proxy)HTTP Proxy HTTP Authentication コンポーネントと同様に、HTTP プロキシを設定する場合、あらゆる種類のプロキシにラッピング ​`http:proxy-config`​ コンポーネントが必要になりました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#tcp-クライアントソケットのプロパティ)TCP クライアントソケットのプロパティ Mule 3 では、TCP クライアントソケットのプロパティが TCP トランスポートに基づいて定義されていました。Mule 4 ではこのトランスポートがソケットコネクタになったため、プロパティを設定する必要があります。また、これらのプロパティは ​`http:client-socket-properties`​ コンポーネントでラップする必要があります。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#要求)要求 HTTP 要求のプロパティは、​`source`​ (式と変換をサポートする ​`http:body`​ コンポーネントに置き換え) と ​`http:request-builder`​ (削除済み) を除いて同じままです。ヘッダー、クエリ、URI のパラメーターは DataWeave 式で明示的に定義するようになりました。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... #[vars.customSource] #[{ 'Host': 'www.example.com' 'Transfer-Encoding' : 'chunked' }] #[{ 'id' : vars.songId }] #[vars.params] ... ``` #### [](#属性-2)属性 HTTP 要求も HTTP リスナーと同様に、すべての応答メタデータを特定の HTTP 応答属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

状況コード

#[inboundProperties.'http.status']

#[attributes.statusCode]

理由を示す語句

#[inboundProperties.'http.reason']

#[attributes.reasonPhrase]

ヘッダー

#[inboundProperties]

#[attributes.headers]
ヘッダーが HTTP リスナーの場合と同じように処理されています。 ## [](#http-static-resource)HTTP 静的リソースハンドラー HTTP 静的リソースハンドラーが、Mule 4 の操作モデルに適合され、​`http:load-static-resource`​ という名前に変更されました。​`resourceBase`​ プロパティも ​`resourceBasePath`​ という名前に変更されています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` この操作は HTTP リスナー取得元と併用することのみを意図していますが、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティも導入されています。 ## [](#http-basic-authentication)HTTP 基本セキュリティ検索条件 HTTP 基本セキュリティ検索条件は、DataWeave を ​`securityProviders`​ プロパティの取得元としてサポートすることと、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティを導入したこと以外は変更されていません (HTTP load static resource 操作と同じです)。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` 完全な設定例については、​[「Spring セキュリティの LDAP プロバイダーの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.5/setting-up-ldap-provider-for-spring-security)​を参照してください。 ## [](#http-mime-types)HTTP MIME タイプ解析 Mule 3 の HTTP Connector の特長は、​`application/x-www-form-urlencoded`​ や ​`multipart/form-data`​ タイプ (および他のサブタイプ) の本文を受信したときに、要求や応答を解析するオプションがあることでした。アウトバウンド要求や応答に解析対象のオブジェクトがあると、一貫性を維持する目的でこうしたタイプの本文に戻されていました。 他方、DataWeave 2.0 でこれらの MIME タイプが処理されるようになったため、Mule 4 では HTTP 解析が排除され、HTTP コンポーネントは常にバイナリデータストリームを提供し、また必要とするようになっています。 解析対象であったタイプの使用を移行する方法については、以下を参照してください。 ### [](#applicationx-www-form-urlencoded)application/x-www-form-urlencoded Mule 3 では、​`Map`​ ペイロードを ​`application/x-www-form-urlencoded`​ コンテンツと同様に使用できました。アウトバウンドトラフィックの場合、​`Map`​ ペイロードが存在すれば、各キー - 値ペアを使用して ​`application/x-www-form-urlencoded`​ 本文が生成されることを意味しました。インバウンドトラフィックの場合は、その本文の各キー - 値ペアが ​`Map`​ に配置されることを意味しました。 現在は、DataWeave で ​`application/x-www-form-urlencoded`​ の読み取りや書き取りができることから、HTTP のさまざまな MIME タイプを簡単かつ一貫した方法で処理できるようになりました。 Mule 3 の例 この例では、​`song=Snow+Poems&artist=TQP`​ のペイロードが送信され、保存されていた ID を記した応答 (​`song=Snow+Poems&artist=TQP&id=49`​) が返されます。 ```xml ``` Mule 4 の例 コンテンツを読み取るための構文は同じままですが、実際にデータを変換しているため、出力種別を指定しなければならなくなった点のみが異なります。 ```xml ... #[ %dw 2.0 output application/x-www-form-urlencoded --- { song: "Snow Poems", artist: "TQP" }] ... ``` キーにはいくつかの値を追加できます。このデータにアクセスするには、スターセレクターを使用して、関連するすべての値のコレクションを取得する必要があります。たとえば、​`#[payload.*artist]`​ は ​`Under Pressure`​ という歌で ​`David Bowie`​ と ​`Queen`​ を記載したリストを返します。 ### [](#http_multipart)multipart/\* Mule 3 では、Mule メッセージの添付ファイルを、マルチパートコンテンツと同様に使用していました。 アウトバウンドトラフィックの場合、添付ファイルが存在すれば、それらが ​`multipart/form-data`​ 本文の一部として使用されることを意味しました。インバウンドトラフィックの場合は、その本文の各部が Mule メッセージの添付ファイルにマッピングされることを意味しました。 Mule 4 では、Mule メッセージにファイルが添付されることがなくなりました。代わりに、JSON または XML コンテンツと同様に、DataWeave を使用してマルチパートコンテンツの読み取りや書き込みを行うことができます。 Mule 3 の例 この例では、2 つの主要な JSON 部分がある ​`multipart/form-data`​ 本文を受け取ります。1 つは注文で、もう 1 つは注文を生成したパートナーです。パートナー名をログに記録すると、注文 ID が保存され、注文を受けたことを伝える簡単なメッセージと、その注文用に生成された領収書 PDF について記載した ​`multipart/form-data`​ 応答が生成されます。 ```xml ``` Mule 4 の例 今後は添付ファイルの処理に伴う煩わしさから開放され、​`content`​ キーワードを使用して名前で各部にアクセスするだけです。マルチパート応答は、DataWeave を使用して HTTP レスポンスボディに生成されます (このボディ内で簡単にカスタマイズできます)。 ```xml ``` ここで注意すべき重要な点は、​`http:body`​ 機能を活用していますが、最終的な変換コンポーネントを使用してもおそらく同じ結果が得られることです。 境界が自動生成されるため、正しいコンテンツタイプのヘッダーが生成されます。詳細は、​[「Multipart Format (Form-Data) (マルチパート形式 (フォームデータ))」](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-multipart)​を参照してください。 == 関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-core) [REST Connect](https://docs.mulesoft.com/jp/exchange/to-deploy-using-rest-connect) # HTTP Connector の使用の移行 HTTP Connector のほとんどの部分は、Mule 4 モデルに適合されています。 - 設定プロパティは接続コンポーネントに移行されています (可能な場合)。 - メッセージプロセッサーは、適切な操作にリファクタリングされています。 - アウトバウンドプロパティ (​`http.status`​ など) は排除され、明示的なプロパティになりました。 - インバウンドプロパティ (​`http.queryParams`​ など) も排除され、HTTP 固有のメッセージ属性になりました。 - スレッドがすべて Mule Runtime レベルで処理されるようになったため、スレッド設定も排除されています。 - `application/x-www-form-urlencoded`​ と ​`multipart/*`​ のメディア種別の特別処理が排除され、DataWeave になりました。 - RAML メタデータのサポートが HTTP 要求操作から排除され、REST になりました。 ## [](#このトピックの内容)このトピックの内容 - [HTTP リスナー](#http_listener) - [HTTP 要求](#http-request) - [HTTP 静的リソースハンドラー](#http-static-resource) - [HTTP 基本セキュリティ検索条件](#http-basic-authentication) - [HTTP MIME タイプ解析](#http-mime-types) ## [](#http_listener)HTTP リスナー HTTP リスナーは、応答ビルダーの設定と、設定プロパティの特定の接続コンポーネントへのカプセル化にのみ大きな変更が行われています。 ### [](#設定)設定 次のプロパティやコンポーネントは、内部の ​`http:listener-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `connectionIdleTimeout` - TLS Context Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#リスナー)リスナー HTTP リスナーのプロパティは、​`http:response-builder`​ と ​`http:error-response-builder`​ を除いて同じままです。これらは名前が ​`http:response`​ と ​`http:error-response`​ に変更されたほか、アウトバウンドプロパティの暗黙的な処理へのサポートが排除され、ヘッダーを 1 つの式で定義することになりました。さらに、発信 HTTP メッセージ本文を 1 つの式で定義できる、新しい ​`http:body`​ コンポーネントをサポートします。 Mule 3 の例 次の例では、暗黙的なアウトバウンドプロパティ (​`Mule 3.6.0`​)、1 つのヘッダー参照 (​`Mule 3.7.0`​)、式参照 (​`Mule 3.8.0`​、​`Mule 3.9.0`​) を使用してセットアップされた応答で多数の ​`User-Agent`​ ヘッダーが送信されます。他方、エラー応答は ​`Date`​ ヘッダーと、​`User-Agent`​ のアウトバウンドプロパティを特長とします。 ```xml ... ``` Mule 4 の例 ​`statusCode`​ と ​`reasonPhrase`​ プロパティは同じままですが、すべてのヘッダーが DataWeave 式を使用して明示的に追加されるようになりました。注意すべき重要な点は、アウトバウンドプロパティの ​`http.status`​ と ​`http.reason`​ を使用する代わりに、明示的な ​`statusCode`​ と​`reasonPhrase`​ も指定する必要があることです。 ```xml #[{ 'User-Agent' : 'Mule 3.6.0', 'User-Agent' : 'Mule 3.7.0', 'User-Agent' : 'Mule 3.8.0', 'User-Agent' : 'Mule 3.9.0' }] #[{ 'User-Agent': 'Mule 3.6.0', 'Date': now() }] ... ``` #### [](#属性)属性 HTTP リスナーは、Mule の新しいメッセージ構造に従って、すべての要求メタデータを特定の HTTP 要求属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

メソッド

#[inboundProperties.'http.method']

#[attributes.method]

パス

#[inboundProperties.'http.listener.path']

#[attributes.listenerPath]

相対パス

#[inboundProperties.'http.relative.path']

#[attributes.relativePath]

要求 URI

#[inboundProperties.'http.request.uri']

#[attributes.requestUri]

クエリ文字列

#[inboundProperties.'http.query.string']

#[attributes.queryString]

クエリパラメーター

#[inboundProperties.'http.query.params']

#[attributes.queryParams]

URI パラメーター

#[inboundProperties.'http.uri.params']

#[attributes.uriParams]

バージョン

#[inboundProperties.'http.version']

#[attributes.version]

スキーマ

#[inboundProperties.'http.scheme']

#[attributes.scheme]

ヘッダー

#[inboundProperties]

#[attributes.headers]

リモートアドレス

#[inboundProperties.'http.remote.address']

#[attributes.remoteAddress]

クライアント証明書

#[inboundProperties.'http.client.cert']

#[attributes.clientCertificate]
HTTP ヘッダーはインバウンドプロパティに直接マップされていましたが、専用オブジェクトが導入されました。以下は、ヘッダーを取得する方法の例を示しています。 - Mule 3: `#[inboundProperties.'host']` - Mule 4: `#[attributes.headers.'host']` #### [](#http-要求の文字のエンコード)HTTP 要求の文字のエンコード Mule 4 で HTTP リスナーへの HTTP 要求を実行するときに URI が無効にならないように、 [​RFC](https://tools.ietf.org/html/rfc1738#page-3)​ の推奨事項に従って、HTTP 要求で設定する ​`{`​ や ​`}`​ などの文字をエンコードしてください。 Studio で HTTP リスナーの ​**\[Path (パス)\]**​ 項目に要求 URL を設定する場合と、curl 要求コマンドを送信する場合の両方で、これらの文字をエンコードします。次の例では、URL ​`path=/profiles/{profileid}/credit`​ の文字 ​`{`​ を ​`%7B`​ にエンコードし、​`}`​ を ​`%7D`​ にエンコードします。 1. Studio で、フローから \[HTTP\] の ​**\[Listener\]**​ の提供元を選択します。 2. **\[Path (パス)\]**​ 項目で、エンコードした文字を使用して相対パス URL を設定します。例: `/profiles/%7Bprofileid%7D/credit` 3. Studio でアプリケーションのすべての変更を保存します。 4. curl コマンド ​`http://localhost:8084/test?path=/profiles/%7Bprofileid%7D/credit`​ を実行します。 ## [](#http-request)HTTP 要求 HTTP リスナーと同様、HTTP 要求操作の変更の大半は、設定プロパティの接続コンポーネント内へのカプセル化と、要求作成プロセスに関連しています。 ### [](#設定-2)設定 次のプロパティやコンポーネントは、内部の ​`http:request-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `maxConnections` - `connectionIdleTimeout` - `streamResponse` - `responseBufferSize` - HTTP Authentication - HTTP Proxy - TLS Context - TCP クライアントソケットのプロパティ Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` RAML メタデータのサポートは排除されました。REST Connect で、指定した RAML の特定の再利用可能なコネクタを生成できるようになったためです。 #### [](#http-authentication)HTTP Authentication HTTP 認証設定が ​`http:request-connection`​ コンポーネントの一部になったほか、​`http:authentication`​ コンポーネント内にも配置する必要があります。 この変更は、サポートされている全種類の認証 (基本、ダイジェスト、NTLM、OAuth2) に適用されます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#http-proxy)HTTP Proxy HTTP Authentication コンポーネントと同様に、HTTP プロキシを設定する場合、あらゆる種類のプロキシにラッピング ​`http:proxy-config`​ コンポーネントが必要になりました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#tcp-クライアントソケットのプロパティ)TCP クライアントソケットのプロパティ Mule 3 では、TCP クライアントソケットのプロパティが TCP トランスポートに基づいて定義されていました。Mule 4 ではこのトランスポートが Sockets Connector になったため、プロパティを設定する必要があります。また、これらのプロパティは ​`http:client-socket-properties`​ コンポーネントでラップする必要があります。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#要求)要求 HTTP 要求のプロパティは、​`source`​ (式と変換をサポートする ​`http:body`​ コンポーネントに置き換え) と ​`http:request-builder`​ (削除済み) を除いて同じままです。ヘッダー、クエリ、URI のパラメーターは DataWeave 式で明示的に定義するようになりました。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... #[vars.customSource] #[{ 'Host': 'www.example.com' 'Transfer-Encoding' : 'chunked' }] #[{ 'id' : vars.songId }] #[vars.params] ... ``` #### [](#属性-2)属性 HTTP 要求も HTTP リスナーと同様に、すべての応答メタデータを特定の HTTP 応答属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

状況コード

#[inboundProperties.'http.status']

#[attributes.statusCode]

理由を示す語句

#[inboundProperties.'http.reason']

#[attributes.reasonPhrase]

ヘッダー

#[inboundProperties]

#[attributes.headers]
ヘッダーが HTTP リスナーの場合と同じように処理されています。 ## [](#http-static-resource)HTTP 静的リソースハンドラー HTTP 静的リソースハンドラーが、Mule 4 の操作モデルに適合され、​`http:load-static-resource`​ という名前に変更されました。​`resourceBase`​ プロパティも ​`resourceBasePath`​ という名前に変更されています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` この操作は HTTP リスナー取得元と併用することのみを意図していますが、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティも導入されています。 ## [](#http-basic-authentication)HTTP 基本セキュリティ検索条件 HTTP 基本セキュリティ検索条件は、DataWeave を ​`securityProviders`​ プロパティの取得元としてサポートすることと、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティを導入したこと以外は変更されていません (HTTP load static resource 操作と同じです)。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` 完全な設定例については、​[「Spring セキュリティの LDAP プロバイダーの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.6/setting-up-ldap-provider-for-spring-security)​を参照してください。 ## [](#http-mime-types)HTTP MIME タイプ解析 Mule 3 の HTTP Connector の特長は、​`application/x-www-form-urlencoded`​ や ​`multipart/form-data`​ タイプ (および他のサブタイプ) の本文を受信したときに、要求や応答を解析するオプションがあることでした。アウトバウンド要求や応答に解析対象のオブジェクトがあると、一貫性を維持する目的でこうしたタイプの本文に戻されていました。 他方、DataWeave 2.0 でこれらの MIME タイプが処理されるようになったため、Mule 4 では HTTP 解析が排除され、HTTP コンポーネントは常にバイナリデータストリームを提供し、また必要とするようになっています。 解析対象であったタイプの使用を移行する方法については、以下を参照してください。 ### [](#applicationx-www-form-urlencoded)application/x-www-form-urlencoded Mule 3 では、​`Map`​ ペイロードを ​`application/x-www-form-urlencoded`​ コンテンツと同様に使用できました。アウトバウンドトラフィックの場合、​`Map`​ ペイロードが存在すれば、各キー - 値ペアを使用して ​`application/x-www-form-urlencoded`​ 本文が生成されることを意味しました。インバウンドトラフィックの場合は、その本文の各キー - 値ペアが ​`Map`​ に配置されることを意味しました。 現在は、DataWeave で ​`application/x-www-form-urlencoded`​ の読み取りや書き取りができることから、HTTP のさまざまな MIME タイプを簡単かつ一貫した方法で処理できるようになりました。 Mule 3 の例 この例では、​`song=Snow+Poems&artist=TQP`​ のペイロードが送信され、保存されていた ID を記した応答 (​`song=Snow+Poems&artist=TQP&id=49`​) が返されます。 ```xml ``` Mule 4 の例 コンテンツを読み取るための構文は同じままですが、実際にデータを変換しているため、出力種別を指定しなければならなくなった点のみが異なります。 ```xml ... #[ %dw 2.0 output application/x-www-form-urlencoded --- { song: "Snow Poems", artist: "TQP" }] ... ``` キーにはいくつかの値を追加できます。このデータにアクセスするには、スターセレクターを使用して、関連するすべての値のコレクションを取得する必要があります。たとえば、​`#[payload.*artist]`​ は ​`Under Pressure`​ という歌で ​`David Bowie`​ と ​`Queen`​ を記載したリストを返します。 ### [](#http_multipart)multipart/\* Mule 3 では、Mule メッセージの添付ファイルを、マルチパートコンテンツと同様に使用していました。 アウトバウンドトラフィックの場合、添付ファイルが存在すれば、それらが ​`multipart/form-data`​ 本文の一部として使用されることを意味しました。インバウンドトラフィックの場合は、その本文の各部が Mule メッセージの添付ファイルにマッピングされることを意味しました。 Mule 4 では、Mule メッセージにファイルが添付されることがなくなりました。代わりに、JSON または XML コンテンツと同様に、DataWeave を使用してマルチパートコンテンツの読み取りや書き込みを行うことができます。 Mule 3 の例 この例では、2 つの主要な JSON 部分がある ​`multipart/form-data`​ 本文を受け取ります。1 つは注文で、もう 1 つは注文を生成したパートナーです。パートナー名をログに記録すると、注文 ID が保存され、注文を受けたことを伝える簡単なメッセージと、その注文用に生成された領収書 PDF について記載した ​`multipart/form-data`​ 応答が生成されます。 ```xml ``` Mule 4 の例 今後は添付ファイルの処理に伴う煩わしさから開放され、​`content`​ キーワードを使用して名前で各部にアクセスするだけです。マルチパート応答は、DataWeave を使用して HTTP レスポンスボディに生成されます (このボディ内で簡単にカスタマイズできます)。 ```xml ``` ここで注意すべき重要な点は、​`http:body`​ 機能を活用していますが、最終的な変換コンポーネントを使用してもおそらく同じ結果が得られることです。 境界が自動生成されるため、正しいコンテンツタイプのヘッダーが生成されます。詳細は、​[「Multipart Format (Form-Data) (マルチパート形式 (フォームデータ))」](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-multipart)​を参照してください。 == 関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-core) [REST Connect](https://docs.mulesoft.com/jp/exchange/to-deploy-using-rest-connect) # HTTP Connector の使用の移行 HTTP Connector のほとんどの部分は、Mule 4 モデルに適合されています。 - 設定プロパティは接続コンポーネントに移行されています (可能な場合)。 - メッセージプロセッサーは、適切な操作にリファクタリングされています。 - アウトバウンドプロパティ (​`http.status`​ など) は排除され、明示的なプロパティになりました。 - インバウンドプロパティ (​`http.queryParams`​ など) も排除され、HTTP 固有のメッセージ属性になりました。 - スレッドがすべて Mule Runtime レベルで処理されるようになったため、スレッド設定も排除されています。 - `application/x-www-form-urlencoded`​ と ​`multipart/*`​ のメディア種別の特別処理が排除され、DataWeave になりました。 - RAML メタデータのサポートが HTTP 要求操作から排除され、REST になりました。 ## [](#このトピックの内容)このトピックの内容 - [HTTP リスナー](#http_listener) - [HTTP 要求](#http-request) - [HTTP 静的リソースハンドラー](#http-static-resource) - [HTTP 基本セキュリティ検索条件](#http-basic-authentication) - [HTTP MIME タイプ解析](#http-mime-types) ## [](#http_listener)HTTP リスナー HTTP リスナーは、応答ビルダーの設定と、設定プロパティの特定の接続コンポーネントへのカプセル化にのみ大きな変更が行われています。 ### [](#設定)設定 次のプロパティやコンポーネントは、内部の ​`http:listener-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `connectionIdleTimeout` - TLS Context Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#リスナー)リスナー HTTP リスナーのプロパティは、​`http:response-builder`​ と ​`http:error-response-builder`​ を除いて同じままです。これらは名前が ​`http:response`​ と ​`http:error-response`​ に変更されたほか、アウトバウンドプロパティの暗黙的な処理へのサポートが排除され、ヘッダーを 1 つの式で定義することになりました。さらに、発信 HTTP メッセージ本文を 1 つの式で定義できる、新しい ​`http:body`​ コンポーネントをサポートします。 Mule 3 の例 次の例では、暗黙的なアウトバウンドプロパティ (​`Mule 3.6.0`​)、1 つのヘッダー参照 (​`Mule 3.7.0`​)、式参照 (​`Mule 3.8.0`​、​`Mule 3.9.0`​) を使用してセットアップされた応答で多数の ​`User-Agent`​ ヘッダーが送信されます。他方、エラー応答は ​`Date`​ ヘッダーと、​`User-Agent`​ のアウトバウンドプロパティを特長とします。 ```xml ... ``` Mule 4 の例 ​`statusCode`​ と ​`reasonPhrase`​ プロパティは同じままですが、すべてのヘッダーが DataWeave 式を使用して明示的に追加されるようになりました。注意すべき重要な点は、アウトバウンドプロパティの ​`http.status`​ と ​`http.reason`​ を使用する代わりに、明示的な ​`statusCode`​ と​`reasonPhrase`​ も指定する必要があることです。 ```xml #[{ 'User-Agent' : 'Mule 3.6.0', 'User-Agent' : 'Mule 3.7.0', 'User-Agent' : 'Mule 3.8.0', 'User-Agent' : 'Mule 3.9.0' }] #[{ 'User-Agent': 'Mule 3.6.0', 'Date': now() }] ... ``` #### [](#属性)属性 HTTP リスナーは、Mule の新しいメッセージ構造に従って、すべての要求メタデータを特定の HTTP 要求属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

メソッド

#[inboundProperties.'http.method']

#[attributes.method]

パス

#[inboundProperties.'http.listener.path']

#[attributes.listenerPath]

相対パス

#[inboundProperties.'http.relative.path']

#[attributes.relativePath]

要求 URI

#[inboundProperties.'http.request.uri']

#[attributes.requestUri]

クエリ文字列

#[inboundProperties.'http.query.string']

#[attributes.queryString]

クエリパラメーター

#[inboundProperties.'http.query.params']

#[attributes.queryParams]

URI パラメーター

#[inboundProperties.'http.uri.params']

#[attributes.uriParams]

バージョン

#[inboundProperties.'http.version']

#[attributes.version]

スキーマ

#[inboundProperties.'http.scheme']

#[attributes.scheme]

ヘッダー

#[inboundProperties]

#[attributes.headers]

リモートアドレス

#[inboundProperties.'http.remote.address']

#[attributes.remoteAddress]

クライアント証明書

#[inboundProperties.'http.client.cert']

#[attributes.clientCertificate]
HTTP ヘッダーはインバウンドプロパティに直接マップされていましたが、専用オブジェクトが導入されました。以下は、ヘッダーを取得する方法の例を示しています。 - Mule 3: `#[inboundProperties.'host']` - Mule 4: `#[attributes.headers.'host']` #### [](#http-要求の文字のエンコード)HTTP 要求の文字のエンコード Mule 4 で HTTP リスナーへの HTTP 要求を実行するときに URI が無効にならないように、 [​RFC](https://tools.ietf.org/html/rfc1738#page-3)​ の推奨事項に従って、HTTP 要求で設定する ​`{`​ や ​`}`​ などの文字をエンコードしてください。 Studio で HTTP リスナーの ​**\[Path (パス)\]**​ 項目に要求 URL を設定する場合と、curl 要求コマンドを送信する場合の両方で、これらの文字をエンコードします。次の例では、URL ​`path=/profiles/{profileid}/credit`​ の文字 ​`{`​ を ​`%7B`​ にエンコードし、​`}`​ を ​`%7D`​ にエンコードします。 1. Studio で、フローから \[HTTP\] の ​**\[Listener\]**​ の提供元を選択します。 2. **\[Path (パス)\]**​ 項目で、エンコードした文字を使用して相対パス URL を設定します。例: `/profiles/%7Bprofileid%7D/credit` 3. Studio でアプリケーションのすべての変更を保存します。 4. curl コマンド ​`http://localhost:8084/test?path=/profiles/%7Bprofileid%7D/credit`​ を実行します。 ## [](#http-request)HTTP 要求 HTTP リスナーと同様、HTTP 要求操作の変更の大半は、設定プロパティの接続コンポーネント内へのカプセル化と、要求作成プロセスに関連しています。 ### [](#設定-2)設定 次のプロパティやコンポーネントは、内部の ​`http:request-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `maxConnections` - `connectionIdleTimeout` - `streamResponse` - `responseBufferSize` - HTTP Authentication - HTTP Proxy - TLS Context - TCP クライアントソケットのプロパティ Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` RAML メタデータのサポートは排除されました。REST Connect で、指定した RAML の特定の再利用可能なコネクタを生成できるようになったためです。 #### [](#http-authentication)HTTP Authentication HTTP 認証設定が ​`http:request-connection`​ コンポーネントの一部になったほか、​`http:authentication`​ コンポーネント内にも配置する必要があります。 この変更は、サポートされている全種類の認証 (基本、ダイジェスト、NTLM、OAuth2) に適用されます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#http-proxy)HTTP Proxy HTTP Authentication コンポーネントと同様に、HTTP プロキシを設定する場合、あらゆる種類のプロキシにラッピング ​`http:proxy-config`​ コンポーネントが必要になりました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#tcp-クライアントソケットのプロパティ)TCP クライアントソケットのプロパティ Mule 3 では、TCP クライアントソケットのプロパティが TCP トランスポートに基づいて定義されていました。Mule 4 ではこのトランスポートが Sockets Connector になったため、プロパティを設定する必要があります。また、これらのプロパティは ​`http:client-socket-properties`​ コンポーネントでラップする必要があります。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#要求)要求 HTTP 要求のプロパティは、​`source`​ (式と変換をサポートする ​`http:body`​ コンポーネントに置き換え) と ​`http:request-builder`​ (削除済み) を除いて同じままです。ヘッダー、クエリ、URI のパラメーターは DataWeave 式で明示的に定義するようになりました。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... #[vars.customSource] #[{ 'Host': 'www.example.com' 'Transfer-Encoding' : 'chunked' }] #[{ 'id' : vars.songId }] #[vars.params] ... ``` #### [](#属性-2)属性 HTTP 要求も HTTP リスナーと同様に、すべての応答メタデータを特定の HTTP 応答属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

状況コード

#[inboundProperties.'http.status']

#[attributes.statusCode]

理由を示す語句

#[inboundProperties.'http.reason']

#[attributes.reasonPhrase]

ヘッダー

#[inboundProperties]

#[attributes.headers]
ヘッダーが HTTP リスナーの場合と同じように処理されています。 ## [](#http-static-resource)HTTP 静的リソースハンドラー HTTP 静的リソースハンドラーが、Mule 4 の操作モデルに適合され、​`http:load-static-resource`​ という名前に変更されました。​`resourceBase`​ プロパティも ​`resourceBasePath`​ という名前に変更されています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` この操作は HTTP リスナー取得元と併用することのみを意図していますが、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティも導入されています。 ## [](#http-basic-authentication)HTTP 基本セキュリティ検索条件 HTTP 基本セキュリティ検索条件は、DataWeave を ​`securityProviders`​ プロパティの取得元としてサポートすることと、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティを導入したこと以外は変更されていません (HTTP load static resource 操作と同じです)。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` 完全な設定例については、​[「Spring セキュリティの LDAP プロバイダーの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.7/setting-up-ldap-provider-for-spring-security)​を参照してください。 ## [](#http-mime-types)HTTP MIME タイプ解析 Mule 3 の HTTP Connector の特長は、​`application/x-www-form-urlencoded`​ や ​`multipart/form-data`​ タイプ (および他のサブタイプ) の本文を受信したときに、要求や応答を解析するオプションがあることでした。アウトバウンド要求や応答に解析対象のオブジェクトがあると、一貫性を維持する目的でこうしたタイプの本文に戻されていました。 他方、DataWeave 2.0 でこれらの MIME タイプが処理されるようになったため、Mule 4 では HTTP 解析が排除され、HTTP コンポーネントは常にバイナリデータストリームを提供し、また必要とするようになっています。 解析対象であったタイプの使用を移行する方法については、以下を参照してください。 ### [](#applicationx-www-form-urlencoded)application/x-www-form-urlencoded Mule 3 では、​`Map`​ ペイロードを ​`application/x-www-form-urlencoded`​ コンテンツと同様に使用できました。アウトバウンドトラフィックの場合、​`Map`​ ペイロードが存在すれば、各キー - 値ペアを使用して ​`application/x-www-form-urlencoded`​ 本文が生成されることを意味しました。インバウンドトラフィックの場合は、その本文の各キー - 値ペアが ​`Map`​ に配置されることを意味しました。 現在は、DataWeave で ​`application/x-www-form-urlencoded`​ の読み取りや書き取りができることから、HTTP のさまざまな MIME タイプを簡単かつ一貫した方法で処理できるようになりました。 Mule 3 の例 この例では、​`song=Snow+Poems&artist=TQP`​ のペイロードが送信され、保存されていた ID を記した応答 (​`song=Snow+Poems&artist=TQP&id=49`​) が返されます。 ```xml ``` Mule 4 の例 コンテンツを読み取るための構文は同じままですが、実際にデータを変換しているため、出力種別を指定しなければならなくなった点のみが異なります。 ```xml ... #[ %dw 2.0 output application/x-www-form-urlencoded --- { song: "Snow Poems", artist: "TQP" }] ... ``` キーにはいくつかの値を追加できます。このデータにアクセスするには、スターセレクターを使用して、関連するすべての値のコレクションを取得する必要があります。たとえば、​`#[payload.*artist]`​ は ​`Under Pressure`​ という歌で ​`David Bowie`​ と ​`Queen`​ を記載したリストを返します。 ### [](#http_multipart)multipart/\* Mule 3 では、Mule メッセージの添付ファイルを、マルチパートコンテンツと同様に使用していました。 アウトバウンドトラフィックの場合、添付ファイルが存在すれば、それらが ​`multipart/form-data`​ 本文の一部として使用されることを意味しました。インバウンドトラフィックの場合は、その本文の各部が Mule メッセージの添付ファイルにマッピングされることを意味しました。 Mule 4 では、Mule メッセージにファイルが添付されることがなくなりました。代わりに、JSON または XML コンテンツと同様に、DataWeave を使用してマルチパートコンテンツの読み取りや書き込みを行うことができます。 Mule 3 の例 この例では、2 つの主要な JSON 部分がある ​`multipart/form-data`​ 本文を受け取ります。1 つは注文で、もう 1 つは注文を生成したパートナーです。パートナー名をログに記録すると、注文 ID が保存され、注文を受けたことを伝える簡単なメッセージと、その注文用に生成された領収書 PDF について記載した ​`multipart/form-data`​ 応答が生成されます。 ```xml ``` Mule 4 の例 今後は添付ファイルの処理に伴う煩わしさから開放され、​`content`​ キーワードを使用して名前で各部にアクセスするだけです。マルチパート応答は、DataWeave を使用して HTTP レスポンスボディに生成されます (このボディ内で簡単にカスタマイズできます)。 ```xml ``` ここで注意すべき重要な点は、​`http:body`​ 機能を活用していますが、最終的な変換コンポーネントを使用してもおそらく同じ結果が得られることです。 境界が自動生成されるため、正しいコンテンツタイプのヘッダーが生成されます。詳細は、​[「Multipart Format (Form-Data) (マルチパート形式 (フォームデータ))」](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-multipart)​を参照してください。 == 関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-core) [REST Connect](https://docs.mulesoft.com/jp/exchange/to-deploy-using-rest-connect) # HTTP Connector の使用の移行 HTTP Connector のほとんどの部分は、Mule 4 モデルに適合されています。 - 設定プロパティは接続コンポーネントに移行されています (可能な場合)。 - メッセージプロセッサーは、適切な操作にリファクタリングされています。 - アウトバウンドプロパティ (​`http.status`​ など) は排除され、明示的なプロパティになりました。 - インバウンドプロパティ (​`http.queryParams`​ など) も排除され、HTTP 固有のメッセージ属性になりました。 - スレッドがすべて Mule Runtime レベルで処理されるようになったため、スレッド設定も排除されています。 - `application/x-www-form-urlencoded`​ と ​`multipart/*`​ のメディア種別の特別処理が排除され、DataWeave になりました。 - RAML メタデータのサポートが HTTP 要求操作から排除され、REST になりました。 ## [](#このトピックの内容)このトピックの内容 - [HTTP リスナー](#http_listener) - [HTTP 要求](#http-request) - [HTTP 静的リソースハンドラー](#http-static-resource) - [HTTP 基本セキュリティ検索条件](#http-basic-authentication) - [HTTP MIME タイプ解析](#http-mime-types) ## [](#http_listener)HTTP リスナー HTTP リスナーは、応答ビルダーの設定と、設定プロパティの特定の接続コンポーネントへのカプセル化にのみ大きな変更が行われています。 ### [](#configuration-設定)Configuration (設定) 次のプロパティやコンポーネントは、内部の ​`http:listener-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `connectionIdleTimeout` - TLS Context Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#リスナー)リスナー HTTP リスナーのプロパティは、​`http:response-builder`​ と ​`http:error-response-builder`​ を除いて同じままです。これらは名前が ​`http:response`​ と ​`http:error-response`​ に変更されたほか、アウトバウンドプロパティの暗黙的な処理へのサポートが排除され、ヘッダーを 1 つの式で定義することになりました。さらに、発信 HTTP メッセージ本文を 1 つの式で定義できる、新しい ​`http:body`​ コンポーネントをサポートします。 Mule 3 の例 次の例では、暗黙的なアウトバウンドプロパティ (​`Mule 3.6.0`​)、1 つのヘッダー参照 (​`Mule 3.7.0`​)、式参照 (​`Mule 3.8.0`​、​`Mule 3.9.0`​) を使用してセットアップされた応答で多数の ​`User-Agent`​ ヘッダーが送信されます。他方、エラー応答は ​`Date`​ ヘッダーと、​`User-Agent`​ のアウトバウンドプロパティを特長とします。 ```xml ... ``` Mule 4 の例 ​`statusCode`​ と ​`reasonPhrase`​ プロパティは同じままですが、すべてのヘッダーが DataWeave 式を使用して明示的に追加されるようになりました。注意すべき重要な点は、アウトバウンドプロパティの ​`http.status`​ と ​`http.reason`​ を使用する代わりに、明示的な ​`statusCode`​ と ​`reasonPhrase`​ も指定する必要があることです。 ```xml #[{ 'User-Agent' : 'Mule 3.6.0', 'User-Agent' : 'Mule 3.7.0', 'User-Agent' : 'Mule 3.8.0', 'User-Agent' : 'Mule 3.9.0' }] #[{ 'User-Agent': 'Mule 3.6.0', 'Date': now() }] ... ``` #### [](#属性)属性 HTTP リスナーは、Mule の新しいメッセージ構造に従って、すべての要求メタデータを特定の HTTP 要求属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

メソッド

#[inboundProperties.'http.method']

#[attributes.method]

パス

#[inboundProperties.'http.listener.path']

#[attributes.listenerPath]

相対パス

#[inboundProperties.'http.relative.path']

#[attributes.relativePath]

要求 URI

#[inboundProperties.'http.request.uri']

#[attributes.requestUri]

クエリ文字列

#[inboundProperties.'http.query.string']

#[attributes.queryString]

クエリパラメーター

#[inboundProperties.'http.query.params']

#[attributes.queryParams]

URI パラメーター

#[inboundProperties.'http.uri.params']

#[attributes.uriParams]

バージョン

#[inboundProperties.'http.version']

#[attributes.version]

スキーマ

#[inboundProperties.'http.scheme']

#[attributes.scheme]

ヘッダー

#[inboundProperties]

#[attributes.headers]

リモートアドレス

#[inboundProperties.'http.remote.address']

#[attributes.remoteAddress]

クライアント証明書

#[inboundProperties.'http.client.cert']

#[attributes.clientCertificate]
HTTP ヘッダーはインバウンドプロパティに直接マップされていましたが、専用オブジェクトが導入されました。以下は、ヘッダーを取得する方法の例を示しています。 - Mule 3: `#[inboundProperties.'host']` - Mule 4: `#[attributes.headers.'host']` #### [](#http-要求の文字のエンコード)HTTP 要求の文字のエンコード Mule 4 で HTTP リスナーへの HTTP 要求を実行するときに URI が無効にならないように、 [​RFC](https://tools.ietf.org/html/rfc1738#page-3)​ の推奨事項に従って、HTTP 要求で設定する ​`{`​ や ​`}`​ などの文字をエンコードしてください。 Studio で HTTP リスナーの ​**\[Path (パス)\]**​ 項目に要求 URL を設定する場合と、curl 要求コマンドを送信する場合の両方で、これらの文字をエンコードします。次の例では、URL ​`path=/profiles/{profileid}/credit`​ の文字 ​`{`​ を ​`%7B`​ にエンコードし、​`}`​ を ​`%7D`​ にエンコードします。 1. Studio で、フローから \[HTTP\] の ​**\[Listener\]**​ の提供元を選択します。 2. **\[Path (パス)\]**​ 項目で、エンコードした文字を使用して相対パス URL を設定します。例: `/profiles/%7Bprofileid%7D/credit` 3. Studio でアプリケーションのすべての変更を保存します。 4. curl コマンド ​`http://localhost:8084/test?path=/profiles/%7Bprofileid%7D/credit`​ を実行します。 ## [](#http-request)HTTP 要求 HTTP リスナーと同様、HTTP 要求操作の変更の大半は、設定プロパティの接続コンポーネント内へのカプセル化と、要求作成プロセスに関連しています。 ### [](#configuration-設定-2)Configuration (設定) 次のプロパティやコンポーネントは、内部の ​`http:request-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `maxConnections` - `connectionIdleTimeout` - `streamResponse` - `responseBufferSize` - HTTP Authentication - HTTP Proxy - TLS Context - TCP クライアントソケットのプロパティ Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` RAML メタデータのサポートは排除されました。REST Connect で、指定した RAML の特定の再利用可能なコネクタを生成できるようになったためです。 #### [](#http-authentication)HTTP Authentication HTTP 認証設定が ​`http:request-connection`​ コンポーネントの一部になったほか、​`http:authentication`​ コンポーネント内にも配置する必要があります。 この変更は、サポートされている全種類の認証 (基本、ダイジェスト、NTLM、OAuth2) に適用されます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#http-proxy)HTTP Proxy HTTP Authentication コンポーネントと同様に、HTTP プロキシを設定する場合、あらゆる種類のプロキシにラッピング ​`http:proxy-config`​ コンポーネントが必要になりました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#tcp-クライアントソケットのプロパティ)TCP クライアントソケットのプロパティ Mule 3 では、TCP クライアントソケットのプロパティが TCP トランスポートに基づいて定義されていました。Mule 4 ではこのトランスポートが Sockets Connector になったため、プロパティを設定する必要があります。また、これらのプロパティは ​`http:client-socket-properties`​ コンポーネントでラップする必要があります。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#要求)要求 HTTP 要求のプロパティは、​`source`​ (式と変換をサポートする ​`http:body`​ コンポーネントに置き換え) と ​`http:request-builder`​ (削除済み) を除いて同じままです。ヘッダー、クエリ、URI のパラメーターは DataWeave 式で明示的に定義するようになりました。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... #[vars.customSource] #[{ 'Host': 'www.example.com' 'Transfer-Encoding' : 'chunked' }] #[{ 'id' : vars.songId }] #[vars.params] ... ``` #### [](#属性-2)属性 HTTP 要求も HTTP リスナーと同様に、すべての応答メタデータを特定の HTTP 応答属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

状況コード

#[inboundProperties.'http.status']

#[attributes.statusCode]

理由を示す語句

#[inboundProperties.'http.reason']

#[attributes.reasonPhrase]

ヘッダー

#[inboundProperties]

#[attributes.headers]
ヘッダーが HTTP リスナーの場合と同じように処理されています。 ## [](#http-static-resource)HTTP 静的リソースハンドラー HTTP 静的リソースハンドラーが、Mule 4 の操作モデルに適合され、​`http:load-static-resource`​ という名前に変更されました。​`resourceBase`​ プロパティも ​`resourceBasePath`​ という名前に変更されています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` この操作は HTTP リスナー取得元と併用することのみを意図していますが、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティも導入されています。 ## [](#http-basic-authentication)HTTP 基本セキュリティ検索条件 HTTP 基本セキュリティ検索条件は、DataWeave を ​`securityProviders`​ プロパティの取得元としてサポートすることと、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティを導入したこと以外は変更されていません (HTTP load static resource 操作と同じです)。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` 完全な設定例については、​[「Spring セキュリティの LDAP プロバイダーの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.8/setting-up-ldap-provider-for-spring-security)​を参照してください。 ## [](#http-mime-types)HTTP MIME タイプ解析 Mule 3 の HTTP Connector の特長は、​`application/x-www-form-urlencoded`​ や ​`multipart/form-data`​ タイプ (および他のサブタイプ) の本文を受信したときに、要求や応答を解析するオプションがあることでした。アウトバウンド要求や応答に解析対象のオブジェクトがあると、一貫性を維持する目的でこうしたタイプの本文に戻されていました。 他方、DataWeave 2.0 でこれらの MIME タイプが処理されるようになったため、Mule 4 では HTTP 解析が排除され、HTTP コンポーネントは常にバイナリデータストリームを提供し、また必要とするようになっています。 解析対象であったタイプの使用を移行する方法については、以下を参照してください。 ### [](#applicationx-www-form-urlencoded)application/x-www-form-urlencoded Mule 3 では、​`Map`​ ペイロードを ​`application/x-www-form-urlencoded`​ コンテンツと同様に使用できました。アウトバウンドトラフィックの場合、​`Map`​ ペイロードが存在すれば、各キー - 値ペアを使用して ​`application/x-www-form-urlencoded`​ 本文が生成されることを意味しました。インバウンドトラフィックの場合は、その本文の各キー - 値ペアが ​`Map`​ に配置されることを意味しました。 現在は、DataWeave で ​`application/x-www-form-urlencoded`​ の読み取りや書き取りができることから、HTTP のさまざまな MIME タイプを簡単かつ一貫した方法で処理できるようになりました。 Mule 3 の例 この例では、​`song=Snow+Poems&artist=TQP`​ のペイロードが送信され、保存されていた ID を記した応答 (​`song=Snow+Poems&artist=TQP&id=49`​) が返されます。 ```xml ``` Mule 4 の例 コンテンツを読み取るための構文は同じままですが、実際にデータを変換しているため、出力種別を指定しなければならなくなった点のみが異なります。 ```xml ... #[ %dw 2.0 output application/x-www-form-urlencoded --- { song: "Snow Poems", artist: "TQP" }] ... ``` キーにはいくつかの値を追加できます。このデータにアクセスするには、スターセレクターを使用して、関連するすべての値のコレクションを取得する必要があります。たとえば、​`#[payload.*artist]`​ は ​`Under Pressure`​ という歌で ​`David Bowie`​ と ​`Queen`​ を記載したリストを返します。 ### [](#http_multipart)multipart/\* Mule 3 では、Mule メッセージの添付ファイルを、マルチパートコンテンツと同様に使用していました。 アウトバウンドトラフィックの場合、添付ファイルが存在すれば、それらが ​`multipart/form-data`​ 本文の一部として使用されることを意味しました。インバウンドトラフィックの場合は、その本文の各部が Mule メッセージの添付ファイルにマッピングされることを意味しました。 Mule 4 では、Mule メッセージにファイルが添付されることがなくなりました。代わりに、JSON または XML コンテンツと同様に、DataWeave を使用してマルチパートコンテンツの読み取りや書き込みを行うことができます。 Mule 3 の例 この例では、2 つの主要な JSON 部分がある ​`multipart/form-data`​ 本文を受け取ります。1 つは注文で、もう 1 つは注文を生成したパートナーです。パートナー名をログに記録すると、注文 ID が保存され、注文を受けたことを伝える簡単なメッセージと、その注文用に生成された領収書 PDF について記載した ​`multipart/form-data`​ 応答が生成されます。 ```xml ``` Mule 4 の例 今後は添付ファイルの処理に伴う煩わしさから開放され、​`content`​ キーワードを使用して名前で各部にアクセスするだけです。マルチパート応答は、DataWeave を使用して HTTP レスポンスボディに生成されます (このボディ内で簡単にカスタマイズできます)。 ```xml ``` ここで注意すべき重要な点は、​`http:body`​ 機能を活用していますが、最終的な変換コンポーネントを使用してもおそらく同じ結果が得られることです。 境界が自動生成されるため、正しいコンテンツタイプのヘッダーが生成されます。詳細は、​[「Multipart Format (Form-Data) (マルチパート形式 (フォームデータ))」](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-multipart)​を参照してください。 == 関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-core) [REST Connect](https://docs.mulesoft.com/jp/exchange/to-deploy-using-rest-connect) # HTTP Connector の使用の移行 HTTP Connector のほとんどの部分は、Mule 4 モデルに適合されています。 - 設定プロパティは接続コンポーネントに移行されています (可能な場合)。 - メッセージプロセッサーは、適切な操作にリファクタリングされています。 - アウトバウンドプロパティ (​`http.status`​ など) は排除され、明示的なプロパティになりました。 - インバウンドプロパティ (​`http.queryParams`​ など) も排除され、HTTP 固有のメッセージ属性になりました。 - スレッドがすべて Mule Runtime レベルで処理されるようになったため、スレッド設定も排除されています。 - `application/x-www-form-urlencoded`​ と ​`multipart/*`​ のメディア種別の特別処理が排除され、DataWeave になりました。 - RAML メタデータのサポートが HTTP 要求操作から排除され、REST になりました。 ## [](#このトピックの内容)このトピックの内容 - [HTTP リスナー](#http_listener) - [HTTP 要求](#http-request) - [HTTP 静的リソースハンドラー](#http-static-resource) - [HTTP 基本セキュリティ検索条件](#http-basic-authentication) - [HTTP MIME タイプ解析](#http-mime-types) ## [](#http_listener)HTTP リスナー HTTP リスナーは、応答ビルダーの設定と、設定プロパティの特定の接続コンポーネントへのカプセル化にのみ大きな変更が行われています。 ### [](#configuration-設定)Configuration (設定) 次のプロパティやコンポーネントは、内部の ​`http:listener-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `connectionIdleTimeout` - TLS Context Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#リスナー)リスナー HTTP リスナーのプロパティは、​`http:response-builder`​ と ​`http:error-response-builder`​ を除いて同じままです。これらは名前が ​`http:response`​ と ​`http:error-response`​ に変更されたほか、アウトバウンドプロパティの暗黙的な処理へのサポートが排除され、ヘッダーを 1 つの式で定義することになりました。さらに、発信 HTTP メッセージ本文を 1 つの式で定義できる、新しい ​`http:body`​ コンポーネントをサポートします。 Mule 3 の例 次の例では、暗黙的なアウトバウンドプロパティ (​`Mule 3.6.0`​)、1 つのヘッダー参照 (​`Mule 3.7.0`​)、式参照 (​`Mule 3.8.0`​、​`Mule 3.9.0`​) を使用してセットアップされた応答で多数の ​`User-Agent`​ ヘッダーが送信されます。他方、エラー応答は ​`Date`​ ヘッダーと、​`User-Agent`​ のアウトバウンドプロパティを特長とします。 ```xml ... ``` Mule 4 の例 ​`statusCode`​ と ​`reasonPhrase`​ プロパティは同じままですが、すべてのヘッダーが DataWeave 式を使用して明示的に追加されるようになりました。注意すべき重要な点は、アウトバウンドプロパティの ​`http.status`​ と ​`http.reason`​ を使用する代わりに、明示的な ​`statusCode`​ と ​`reasonPhrase`​ も指定する必要があることです。 ```xml #[{ 'User-Agent' : 'Mule 3.6.0', 'User-Agent' : 'Mule 3.7.0', 'User-Agent' : 'Mule 3.8.0', 'User-Agent' : 'Mule 3.9.0' }] #[{ 'User-Agent': 'Mule 3.6.0', 'Date': now() }] ... ``` #### [](#属性)属性 HTTP リスナーは、Mule の新しいメッセージ構造に従って、すべての要求メタデータを特定の HTTP 要求属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

メソッド

#[inboundProperties.'http.method']

#[attributes.method]

パス

#[inboundProperties.'http.listener.path']

#[attributes.listenerPath]

相対パス

#[inboundProperties.'http.relative.path']

#[attributes.relativePath]

要求 URI

#[inboundProperties.'http.request.uri']

#[attributes.requestUri]

クエリ文字列

#[inboundProperties.'http.query.string']

#[attributes.queryString]

クエリパラメーター

#[inboundProperties.'http.query.params']

#[attributes.queryParams]

URI パラメーター

#[inboundProperties.'http.uri.params']

#[attributes.uriParams]

バージョン

#[inboundProperties.'http.version']

#[attributes.version]

スキーマ

#[inboundProperties.'http.scheme']

#[attributes.scheme]

ヘッダー

#[inboundProperties]

#[attributes.headers]

リモートアドレス

#[inboundProperties.'http.remote.address']

#[attributes.remoteAddress]

クライアント証明書

#[inboundProperties.'http.client.cert']

#[attributes.clientCertificate]
HTTP ヘッダーはインバウンドプロパティに直接マップされていましたが、専用オブジェクトが導入されました。以下は、ヘッダーを取得する方法の例を示しています。 - Mule 3: `#[inboundProperties.'host']` - Mule 4: `#[attributes.headers.'host']` #### [](#http-要求の文字のエンコード)HTTP 要求の文字のエンコード Mule 4 で HTTP リスナーへの HTTP 要求を実行するときに URI が無効にならないように、 [​RFC](https://tools.ietf.org/html/rfc1738#page-3)​ の推奨事項に従って、HTTP 要求で設定する ​`{`​ や ​`}`​ などの文字をエンコードしてください。 Studio で HTTP リスナーの ​**\[Path (パス)\]**​ 項目に要求 URL を設定する場合と、curl 要求コマンドを送信する場合の両方で、これらの文字をエンコードします。次の例では、URL ​`path=/profiles/{profileid}/credit`​ の文字 ​`{`​ を ​`%7B`​ にエンコードし、​`}`​ を ​`%7D`​ にエンコードします。 1. Studio で、フローから \[HTTP\] の ​**\[Listener\]**​ の提供元を選択します。 2. **\[Path (パス)\]**​ 項目で、エンコードした文字を使用して相対パス URL を設定します。例: `/profiles/%7Bprofileid%7D/credit` 3. Studio でアプリケーションのすべての変更を保存します。 4. curl コマンド ​`http://localhost:8084/test?path=/profiles/%7Bprofileid%7D/credit`​ を実行します。 ## [](#http-request)HTTP 要求 HTTP リスナーと同様、HTTP 要求操作の変更の大半は、設定プロパティの接続コンポーネント内へのカプセル化と、要求作成プロセスに関連しています。 ### [](#configuration-設定-2)Configuration (設定) 次のプロパティやコンポーネントは、内部の ​`http:request-connection`​ コンポーネントで定義することになりました。 - `host` - `port` - `protocol` - `usePersistentConnections` - `maxConnections` - `connectionIdleTimeout` - `streamResponse` - `responseBufferSize` - HTTP Authentication - HTTP Proxy - TLS Context - TCP クライアントソケットのプロパティ Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` RAML メタデータのサポートは排除されました。REST Connect で、指定した RAML の特定の再利用可能なコネクタを生成できるようになったためです。 #### [](#http-authentication)HTTP Authentication HTTP 認証設定が ​`http:request-connection`​ コンポーネントの一部になったほか、​`http:authentication`​ コンポーネント内にも配置する必要があります。 この変更は、サポートされている全種類の認証 (基本、ダイジェスト、NTLM、OAuth2) に適用されます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#http-proxy)HTTP Proxy HTTP Authentication コンポーネントと同様に、HTTP プロキシを設定する場合、あらゆる種類のプロキシにラッピング ​`http:proxy-config`​ コンポーネントが必要になりました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` #### [](#tcp-クライアントソケットのプロパティ)TCP クライアントソケットのプロパティ Mule 3 では、TCP クライアントソケットのプロパティが TCP トランスポートに基づいて定義されていました。Mule 4 ではこのトランスポートが Sockets Connector になったため、プロパティを設定する必要があります。また、これらのプロパティは ​`http:client-socket-properties`​ コンポーネントでラップする必要があります。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#要求)要求 HTTP 要求のプロパティは、​`source`​ (式と変換をサポートする ​`http:body`​ コンポーネントに置き換え) と ​`http:request-builder`​ (削除済み) を除いて同じままです。ヘッダー、クエリ、URI のパラメーターは DataWeave 式で明示的に定義するようになりました。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... #[vars.customSource] #[{ 'Host': 'www.example.com' 'Transfer-Encoding' : 'chunked' }] #[{ 'id' : vars.songId }] #[vars.params] ... ``` #### [](#属性-2)属性 HTTP 要求も HTTP リスナーと同様に、すべての応答メタデータを特定の HTTP 応答属性を介して提供するようになりました。以下は、Mule 3 とは異なるやり方で、メタデータにアクセスする新しい方法を示しています。
メタデータ Mule 3 Mule 4

状況コード

#[inboundProperties.'http.status']

#[attributes.statusCode]

理由を示す語句

#[inboundProperties.'http.reason']

#[attributes.reasonPhrase]

ヘッダー

#[inboundProperties]

#[attributes.headers]
ヘッダーが HTTP リスナーの場合と同じように処理されています。 ## [](#http-static-resource)HTTP 静的リソースハンドラー HTTP 静的リソースハンドラーが、Mule 4 の操作モデルに適合され、​`http:load-static-resource`​ という名前に変更されました。​`resourceBase`​ プロパティも ​`resourceBasePath`​ という名前に変更されています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` この操作は HTTP リスナー取得元と併用することのみを意図していますが、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティも導入されています。 ## [](#http-basic-authentication)HTTP 基本セキュリティ検索条件 HTTP 基本セキュリティ検索条件は、DataWeave を ​`securityProviders`​ プロパティの取得元としてサポートすることと、リスナーの HTTP 要求属性を参照して、この操作をフローのどの時点でも使用できるようにする ​`attributes`​ プロパティを導入したこと以外は変更されていません (HTTP load static resource 操作と同じです)。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` 完全な設定例については、​[「Spring セキュリティの LDAP プロバイダーの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.9/setting-up-ldap-provider-for-spring-security)​を参照してください。 ## [](#http-mime-types)HTTP MIME タイプ解析 Mule 3 の HTTP Connector の特長は、​`application/x-www-form-urlencoded`​ や ​`multipart/form-data`​ タイプ (および他のサブタイプ) の本文を受信したときに、要求や応答を解析するオプションがあることでした。アウトバウンド要求や応答に解析対象のオブジェクトがあると、一貫性を維持する目的でこうしたタイプの本文に戻されていました。 他方、DataWeave 2.0 でこれらの MIME タイプが処理されるようになったため、Mule 4 では HTTP 解析が排除され、HTTP コンポーネントは常にバイナリデータストリームを提供し、また必要とするようになっています。 解析対象であったタイプの使用を移行する方法については、以下を参照してください。 ### [](#applicationx-www-form-urlencoded)application/x-www-form-urlencoded Mule 3 では、​`Map`​ ペイロードを ​`application/x-www-form-urlencoded`​ コンテンツと同様に使用できました。アウトバウンドトラフィックの場合、​`Map`​ ペイロードが存在すれば、各キー - 値ペアを使用して ​`application/x-www-form-urlencoded`​ 本文が生成されることを意味しました。インバウンドトラフィックの場合は、その本文の各キー - 値ペアが ​`Map`​ に配置されることを意味しました。 現在は、DataWeave で ​`application/x-www-form-urlencoded`​ の読み取りや書き取りができることから、HTTP のさまざまな MIME タイプを簡単かつ一貫した方法で処理できるようになりました。 Mule 3 の例 この例では、​`song=Snow+Poems&artist=TQP`​ のペイロードが送信され、保存されていた ID を記した応答 (​`song=Snow+Poems&artist=TQP&id=49`​) が返されます。 ```xml ``` Mule 4 の例 コンテンツを読み取るための構文は同じままですが、実際にデータを変換しているため、出力種別を指定しなければならなくなった点のみが異なります。 ```xml ... #[ %dw 2.0 output application/x-www-form-urlencoded --- { song: "Snow Poems", artist: "TQP" }] ... ``` キーにはいくつかの値を追加できます。このデータにアクセスするには、スターセレクターを使用して、関連するすべての値のコレクションを取得する必要があります。たとえば、​`#[payload.*artist]`​ は ​`Under Pressure`​ という歌で ​`David Bowie`​ と ​`Queen`​ を記載したリストを返します。 ### [](#http_multipart)multipart/\* Mule 3 では、Mule メッセージの添付ファイルを、マルチパートコンテンツと同様に使用していました。 アウトバウンドトラフィックの場合、添付ファイルが存在すれば、それらが ​`multipart/form-data`​ 本文の一部として使用されることを意味しました。インバウンドトラフィックの場合は、その本文の各部が Mule メッセージの添付ファイルにマッピングされることを意味しました。 Mule 4 では、Mule メッセージにファイルが添付されることがなくなりました。代わりに、JSON または XML コンテンツと同様に、DataWeave を使用してマルチパートコンテンツの読み取りや書き込みを行うことができます。 Mule 3 の例 この例では、2 つの主要な JSON 部分がある ​`multipart/form-data`​ 本文を受け取ります。1 つは注文で、もう 1 つは注文を生成したパートナーです。パートナー名をログに記録すると、注文 ID が保存され、注文を受けたことを伝える簡単なメッセージと、その注文用に生成された領収書 PDF について記載した ​`multipart/form-data`​ 応答が生成されます。 ```xml ``` Mule 4 の例 今後は添付ファイルの処理に伴う煩わしさから開放され、​`content`​ キーワードを使用して名前で各部にアクセスするだけです。マルチパート応答は、DataWeave を使用して HTTP レスポンスボディに生成されます (このボディ内で簡単にカスタマイズできます)。 ```xml ``` ここで注意すべき重要な点は、​`http:body`​ 機能を活用していますが、最終的な変換コンポーネントを使用してもおそらく同じ結果が得られることです。 境界が自動生成されるため、正しいコンテンツタイプのヘッダーが生成されます。詳細は、​[「Multipart Format (Form-Data) (マルチパート形式 (フォームデータ))」](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-multipart)​を参照してください。 == 関連情報 [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-core) [REST Connect](https://docs.mulesoft.com/jp/exchange/to-deploy-using-rest-connect) # HTTPS サービスの構築 データの機密性を確保するために、HTTPS ベースのサービスを使用して Mule アプリケーションをデプロイできます。次のものを構築する方法を学習します。 - アプリケーションを CloudHub にデプロイする HTTPS サービス - API Manager プロキシを使用する HTTPS サービス さらに、HTTP リクエストおよびレスポンスヘッダーの設定方法を学習します。 アプリケーションをローカルにデプロイする場合は、​[「TLS 設定」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tls-configuration)​を参照してください。 ## [](#前提条件)前提条件 始める前に、サービス (シンプルな「Hello World」サービスなど) を構築してデプロイします。 [「API ビルドの最初から最後まで」](https://docs.mulesoft.com/jp/general/api-led-overview)​チュートリアルを使用して、API を設計し、開発する方法を学習します。 ## [](#https-サービスの構築)HTTPS サービスの構築 HTTPS を使用してアプリケーションを CloudHub にデプロイするようにサービスを変更します。 1. コマンドラインで JDK ​`keytool`​ ユーティリティを使用して ​`keystore.jks`​ ファイルを作成します。自己署名証明書を生成するには、コマンドラインでホスト名も指定する必要があります。 たとえば、次のコマンドは、ホスト名に ​`SAN=DNS:localhost,IP:127.0.0.1`​ を指定して ​`keystore.jks`​ ファイルを作成します。 ```text keytool -genkeypair -keystore keystore.jks -dname "CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass password -storepass password -keyalg RSA -sigalg SHA1withRSA -keysize 2048 -alias mule -ext SAN=DNS:localhost,IP:127.0.0.1 -validity 9999 ``` 2. 生成された ​`keystore.jks`​ ファイルを Anypoint Studio Mule アプリケーションフォルダーの ​`src/main/resources`​ に追加します。 3. Mule アプリケーションの HTTP リスナーを HTTPS に設定し、次のものを指定します。 - `host`​ の値に HTTPS スキームで使用するホスト IP アドレス。 - `port`​ の値の ${https.port} 変数の値。 ```xml ... ... ``` 1. HTTPS グローバルリスナー設定への ​`config-ref`​ 参照を含めます。 ```xml ``` 1. 外部アドレスへの HTTPS 要求を有効にするために必要な TLS 設定を使用して HTTP リクエスターを設定します。 ```xml ... ... ``` 1. HTTPS グローバル要求設定への ​`config-ref`​ 参照を含めます。 ```xml ``` これで、アプリケーションを CloudHub にデプロイする準備が整いました。HTTPS アドレス (​`https://yourdomain.cloudhub.io`​ など) を使用してエンドポイントにアクセスできます。 ## [](#api-manager-プロキシに基づくサービスの設定)API Manager プロキシに基づくサービスの設定 API Manager からプロキシをダウンロードするように求められており、HTTPS 用に設定する必要がある場合、Anypoint Connector で HTTP 用に HTTP リクエスターを設定したのと同じ手順に従います。この HTTP リスナー設定はテンプレートとして提供されています。 設定を完了する手順は、次のとおりです。 1. プロキシプロジェクトを Anypoint Studio にインポートします。 2. プロキシフローの ​**\[Configuration XML (設定 XML)\]**​ タブを選択します。 フローがコメントアウトされている HTTPS Connector を参照しているため、パーサーでエラーが検出されます。 3. `http:listener-config`​ ブロックのコメントを解除します。 4. `keystore`​ の値を追加します: `path`​、​`password`​、​`keyPassword`​。 ```xml ``` - 外部プロパティを使用できます。 - `path`​ の値に ​`src/main/resources`​ を含めることはできません。 設定は、次のようになります。 ```xml ... ``` ## [](#http-リクエストおよびレスポンスヘッダーの設定)HTTP リクエストおよびレスポンスヘッダーの設定 `wrapper.conf`​ ファイルで次のシステムプロパティを変更することで、サーバーレスポンスヘッダー、サーバーリクエストヘッダー、クライアントリクエストヘッダーの最大値を変更できます。
名前 プロパティ 説明 デフォルト値

Server Response Headers (サーバーレスポンスヘッダー)

mule.http.MAX_SERVER_RESPONSE_HEADERS

HTTP サーバーから送信される応答で許容されるヘッダーの最大量。

100

Server Request Headers (サーバーリクエストヘッダー)

mule.http.MAX_SERVER_REQUEST_HEADERS

HTTP サーバーから送信される要求で許容されるヘッダーの最大量。

100

Client Request Headers (クライアントリクエストヘッダー)

mule.http.MAX_CLIENT_REQUEST_HEADERS

HTTP クライアントから送信される要求で許容されるヘッダーの最大量。

100
クライアントの HTTP レスポンスヘッダーには最大量の制限がないため、Max Client Response Header のようなシステムプロパティはありません。 ## [](#関連情報)関連情報 - Mule 4 での ​[HTTPS API プロキシの構築](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) - [TLS Configuration (TLS 設定)](https://docs.mulesoft.com/jp/mule-runtime/4.3/tls-configuration) # HTTPS サービスの構築 データの機密性を確保するために、HTTPS ベースのサービスを使用して Mule アプリケーションをデプロイできます。次のものを構築する方法を学習します。 - アプリケーションを CloudHub にデプロイする HTTPS サービス - API Manager プロキシを使用する HTTPS サービス さらに、HTTP リクエストおよびレスポンスヘッダーの設定方法を学習します。 アプリケーションをローカルにデプロイする場合は、​[「TLS 設定」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tls-configuration)​を参照してください。 ## [](#前提条件)前提条件 始める前に、サービス (シンプルな「Hello World」サービスなど) を構築してデプロイします。 [「API ビルドの最初から最後まで」](https://docs.mulesoft.com/jp/general/api-led-overview)​チュートリアルを使用して、API を設計し、開発する方法を学習します。 ## [](#https-サービスの構築)HTTPS サービスの構築 HTTPS を使用してアプリケーションを CloudHub にデプロイするようにサービスを変更します。 1. コマンドラインで JDK ​`keytool`​ ユーティリティを使用して ​`keystore.jks`​ ファイルを作成します。自己署名証明書を生成するには、コマンドラインでホスト名も指定する必要があります。 たとえば、次のコマンドは、ホスト名に ​`SAN=DNS:localhost,IP:127.0.0.1`​ を指定して ​`keystore.jks`​ ファイルを作成します。 ```text keytool -genkeypair -keystore keystore.jks -dname "CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass password -storepass password -keyalg RSA -sigalg SHA1withRSA -keysize 2048 -alias mule -ext SAN=DNS:localhost,IP:127.0.0.1 -validity 9999 ``` 2. 生成された ​`keystore.jks`​ ファイルを Anypoint Studio Mule アプリケーションフォルダーの ​`src/main/resources`​ に追加します。 3. Mule アプリケーションの HTTP リスナーを HTTPS に設定し、次のものを指定します。 - `host`​ の値に HTTPS スキームで使用するホスト IP アドレス。 - `port`​ の値の ${https.port} 変数の値。 ```xml ... ... ``` 1. HTTPS グローバルリスナー設定への ​`config-ref`​ 参照を含めます。 ```xml ``` 1. 外部アドレスへの HTTPS 要求を有効にするために必要な TLS 設定を使用して HTTP リクエスターを設定します。 ```xml ... ... ``` 1. HTTPS グローバル要求設定への ​`config-ref`​ 参照を含めます。 ```xml ``` これで、アプリケーションを CloudHub にデプロイする準備が整いました。HTTPS アドレス (​`https://yourdomain.cloudhub.io`​ など) を使用してエンドポイントにアクセスできます。 ## [](#api-manager-プロキシに基づくサービスの設定)API Manager プロキシに基づくサービスの設定 API Manager からプロキシをダウンロードするように求められており、HTTPS 用に設定する必要がある場合、Anypoint Connector で HTTP 用に HTTP リクエスターを設定したのと同じ手順に従います。この HTTP リスナー設定はテンプレートとして提供されています。 設定を完了する手順は、次のとおりです。 1. プロキシプロジェクトを Anypoint Studio にインポートします。 2. プロキシフローの ​**\[Configuration XML (設定 XML)\]**​ タブを選択します。 フローがコメントアウトされている HTTPS Connector を参照しているため、パーサーでエラーが検出されます。 3. `http:listener-config`​ ブロックのコメントを解除します。 4. `keystore`​ の値を追加します: `path`​、​`password`​、​`keyPassword`​。 ```xml ``` - 外部プロパティを使用できます。 - `path`​ の値に ​`src/main/resources`​ を含めることはできません。 設定は、次のようになります。 ```xml ... ``` ## [](#http-リクエストおよびレスポンスヘッダーの設定)HTTP リクエストおよびレスポンスヘッダーの設定 `wrapper.conf`​ ファイルで次のシステムプロパティを変更することで、サーバーレスポンスヘッダー、サーバーリクエストヘッダー、クライアントリクエストヘッダーの最大値を変更できます。
名前 プロパティ 説明 デフォルト値

Server Response Headers (サーバーレスポンスヘッダー)

mule.http.MAX_SERVER_RESPONSE_HEADERS

HTTP サーバーから送信される応答で許容されるヘッダーの最大量。

100

Server Request Headers (サーバーリクエストヘッダー)

mule.http.MAX_SERVER_REQUEST_HEADERS

HTTP サーバーから送信される要求で許容されるヘッダーの最大量。

100

Client Request Headers (クライアントリクエストヘッダー)

mule.http.MAX_CLIENT_REQUEST_HEADERS

HTTP クライアントから送信される要求で許容されるヘッダーの最大量。

100
クライアントの HTTP レスポンスヘッダーには最大量の制限がないため、Max Client Response Header のようなシステムプロパティはありません。 ## [](#関連情報)関連情報 - Mule 4 での ​[HTTPS API プロキシの構築](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) - [TLS Configuration (TLS 設定)](https://docs.mulesoft.com/jp/mule-runtime/4.4/tls-configuration) # HTTPS サービスの構築 データの機密性を確保するために、HTTPS ベースのサービスを使用して Mule アプリケーションをデプロイできます。次のものを構築する方法を学習します。 - アプリケーションを CloudHub にデプロイする HTTPS サービス - API Manager プロキシを使用する HTTPS サービス さらに、HTTP リクエストおよびレスポンスヘッダーの設定方法を学習します。 アプリケーションをローカルにデプロイする場合は、​[「TLS 設定」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tls-configuration)​を参照してください。 ## [](#前提条件)前提条件 始める前に、サービス (シンプルな「Hello World」サービスなど) を構築してデプロイします。 [「API ビルドの最初から最後まで」](https://docs.mulesoft.com/jp/general/api-led-overview)​チュートリアルを使用して、API を設計し、開発する方法を学習します。 ## [](#https-サービスの構築)HTTPS サービスの構築 HTTPS を使用してアプリケーションを CloudHub にデプロイするようにサービスを変更します。 1. コマンドラインで JDK ​`keytool`​ ユーティリティを使用して ​`keystore.jks`​ ファイルを作成します。自己署名証明書を生成するには、コマンドラインでホスト名も指定する必要があります。 たとえば、次のコマンドは、ホスト名に ​`SAN=DNS:localhost,IP:127.0.0.1`​ を指定して ​`keystore.jks`​ ファイルを作成します。 ```text keytool -genkeypair -keystore keystore.jks -dname "CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass password -storepass password -keyalg RSA -sigalg SHA1withRSA -keysize 2048 -alias mule -ext SAN=DNS:localhost,IP:127.0.0.1 -validity 9999 ``` 2. 生成された ​`keystore.jks`​ ファイルを Anypoint Studio Mule アプリケーションフォルダーの ​`src/main/resources`​ に追加します。 3. Mule アプリケーションの HTTP リスナーを HTTPS に設定し、次のものを指定します。 - `host`​ の値に HTTPS スキームで使用するホスト IP アドレス。 - `port`​ の値の ${https.port} 変数の値。 ```xml ... ... ``` 1. HTTPS グローバルリスナー設定への ​`config-ref`​ 参照を含めます。 ```xml ``` 1. 外部アドレスへの HTTPS 要求を有効にするために必要な TLS 設定を使用して HTTP リクエスターを設定します。 ```xml ... ... ``` 1. HTTPS グローバル要求設定への ​`config-ref`​ 参照を含めます。 ```xml ``` これで、アプリケーションを CloudHub にデプロイする準備が整いました。HTTPS アドレス (​`https://yourdomain.cloudhub.io`​ など) を使用してエンドポイントにアクセスできます。 ## [](#api-manager-プロキシに基づくサービスの設定)API Manager プロキシに基づくサービスの設定 API Manager からプロキシをダウンロードするように求められており、HTTPS 用に設定する必要がある場合、Anypoint Connector で HTTP 用に HTTP リクエスターを設定したのと同じ手順に従います。この HTTP リスナー設定はテンプレートとして提供されています。 設定を完了する手順は、次のとおりです。 1. プロキシプロジェクトを Anypoint Studio にインポートします。 2. プロキシフローの ​**\[Configuration XML (設定 XML)\]**​ タブを選択します。 フローがコメントアウトされている HTTPS Connector を参照しているため、パーサーでエラーが検出されます。 3. `http:listener-config`​ ブロックのコメントを解除します。 4. `keystore`​ の値を追加します: `path`​、​`password`​、​`keyPassword`​。 ```xml ``` - 外部プロパティを使用できます。 - `path`​ の値に ​`src/main/resources`​ を含めることはできません。 設定は、次のようになります。 ```xml ... ``` ## [](#http-リクエストおよびレスポンスヘッダーの設定)HTTP リクエストおよびレスポンスヘッダーの設定 `wrapper.conf`​ ファイルで次のシステムプロパティを変更することで、サーバーレスポンスヘッダー、サーバーリクエストヘッダー、クライアントリクエストヘッダーの最大値を変更できます。
名前 プロパティ 説明 デフォルト値

Server Response Headers (サーバーレスポンスヘッダー)

mule.http.MAX_SERVER_RESPONSE_HEADERS

HTTP サーバーから送信される応答で許容されるヘッダーの最大量。

100

Server Request Headers (サーバーリクエストヘッダー)

mule.http.MAX_SERVER_REQUEST_HEADERS

HTTP サーバーから送信される要求で許容されるヘッダーの最大量。

100

Client Request Headers (クライアントリクエストヘッダー)

mule.http.MAX_CLIENT_REQUEST_HEADERS

HTTP クライアントから送信される要求で許容されるヘッダーの最大量。

100
クライアントの HTTP レスポンスヘッダーには最大量の制限がないため、Max Client Response Header のようなシステムプロパティはありません。 ## [](#関連情報)関連情報 - Mule 4 での ​[HTTPS API プロキシの構築](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) - [TLS Configuration (TLS 設定)](https://docs.mulesoft.com/jp/mule-runtime/4.5/tls-configuration) # HTTPS サービスの構築 データの機密性を確保するために、HTTPS ベースのサービスを使用して Mule アプリケーションをデプロイできます。次のものを構築する方法を学習します。 - アプリケーションを CloudHub にデプロイする HTTPS サービス - API Manager プロキシを使用する HTTPS サービス さらに、HTTP リクエストおよびレスポンスヘッダーの設定方法を学習します。 アプリケーションをローカルにデプロイする場合は、​[「TLS 設定」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tls-configuration)​を参照してください。 ## [](#前提条件)前提条件 始める前に、サービス (シンプルな「Hello World」サービスなど) を構築してデプロイします。 [「API ビルドの最初から最後まで」](https://docs.mulesoft.com/jp/general/api-led-overview)​チュートリアルを使用して、API を設計し、開発する方法を学習します。 ## [](#https-サービスの構築)HTTPS サービスの構築 HTTPS を使用してアプリケーションを CloudHub にデプロイするようにサービスを変更します。 1. コマンドラインで JDK ​`keytool`​ ユーティリティを使用して ​`keystore.jks`​ ファイルを作成します。自己署名証明書を生成するには、コマンドラインでホスト名も指定する必要があります。 たとえば、次のコマンドは、ホスト名に ​`SAN=DNS:localhost,IP:127.0.0.1`​ を指定して ​`keystore.jks`​ ファイルを作成します。 ```text keytool -genkeypair -keystore keystore.jks -dname "CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass password -storepass password -keyalg RSA -sigalg SHA1withRSA -keysize 2048 -alias mule -ext SAN=DNS:localhost,IP:127.0.0.1 -validity 9999 ``` 2. 生成された ​`keystore.jks`​ ファイルを Anypoint Studio Mule アプリケーションフォルダーの ​`src/main/resources`​ に追加します。 3. Mule アプリケーションの HTTP リスナーを HTTPS に設定し、次のものを指定します。 - `host`​ の値に HTTPS スキームで使用するホスト IP アドレス。 - `port`​ の値の ${https.port} 変数の値。 ```xml ... ... ``` 1. HTTPS グローバルリスナー設定への ​`config-ref`​ 参照を含めます。 ```xml ``` 1. 外部アドレスへの HTTPS 要求を有効にするために必要な TLS 設定を使用して HTTP リクエスターを設定します。 ```xml ... ... ``` 1. HTTPS グローバル要求設定への ​`config-ref`​ 参照を含めます。 ```xml ``` これで、アプリケーションを CloudHub にデプロイする準備が整いました。HTTPS アドレス (​`https://yourdomain.cloudhub.io`​ など) を使用してエンドポイントにアクセスできます。 ## [](#api-manager-プロキシに基づくサービスの設定)API Manager プロキシに基づくサービスの設定 API Manager からプロキシをダウンロードするように求められており、HTTPS 用に設定する必要がある場合、Anypoint Connector で HTTP 用に HTTP リクエスターを設定したのと同じ手順に従います。この HTTP リスナー設定はテンプレートとして提供されています。 設定を完了する手順は、次のとおりです。 1. プロキシプロジェクトを Anypoint Studio にインポートします。 2. プロキシフローの ​**\[Configuration XML (設定 XML)\]**​ タブを選択します。 フローがコメントアウトされている HTTPS Connector を参照しているため、パーサーでエラーが検出されます。 3. `http:listener-config`​ ブロックのコメントを解除します。 4. `keystore`​ の値を追加します: `path`​、​`password`​、​`keyPassword`​。 ```xml ``` - 外部プロパティを使用できます。 - `path`​ の値に ​`src/main/resources`​ を含めることはできません。 設定は、次のようになります。 ```xml ... ``` ## [](#http-リクエストおよびレスポンスヘッダーの設定)HTTP リクエストおよびレスポンスヘッダーの設定 `wrapper.conf`​ ファイルで次のシステムプロパティを変更することで、サーバーレスポンスヘッダー、サーバーリクエストヘッダー、クライアントリクエストヘッダーの最大値を変更できます。
名前 プロパティ 説明 デフォルト値

Server Response Headers (サーバーレスポンスヘッダー)

mule.http.MAX_SERVER_RESPONSE_HEADERS

HTTP サーバーから送信される応答で許容されるヘッダーの最大量。

100

Server Request Headers (サーバーリクエストヘッダー)

mule.http.MAX_SERVER_REQUEST_HEADERS

HTTP サーバーから送信される要求で許容されるヘッダーの最大量。

100

Client Request Headers (クライアントリクエストヘッダー)

mule.http.MAX_CLIENT_REQUEST_HEADERS

HTTP クライアントから送信される要求で許容されるヘッダーの最大量。

100
クライアントの HTTP レスポンスヘッダーには最大量の制限がないため、Max Client Response Header のようなシステムプロパティはありません。 ## [](#関連情報)関連情報 - Mule 4 での ​[HTTPS API プロキシの構築](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) - [TLS Configuration (TLS 設定)](https://docs.mulesoft.com/jp/mule-runtime/4.6/tls-configuration) # HTTPS サービスの構築 データの機密性を確保するために、HTTPS ベースのサービスを使用して Mule アプリケーションをデプロイできます。次のものを構築する方法を学習します。 - アプリケーションを CloudHub にデプロイする HTTPS サービス - API Manager プロキシを使用する HTTPS サービス さらに、HTTP リクエストおよびレスポンスヘッダーの設定方法を学習します。 アプリケーションをローカルにデプロイする場合は、​[「TLS 設定」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tls-configuration)​を参照してください。 ## [](#前提条件)前提条件 始める前に、サービス (シンプルな「Hello World」サービスなど) を構築してデプロイします。 [「API ビルドの最初から最後まで」](https://docs.mulesoft.com/jp/general/api-led-overview)​チュートリアルを使用して、API を設計し、開発する方法を学習します。 ## [](#https-サービスの構築)HTTPS サービスの構築 HTTPS を使用してアプリケーションを CloudHub にデプロイするようにサービスを変更します。 1. コマンドラインで JDK ​`keytool`​ ユーティリティを使用して ​`keystore.jks`​ ファイルを作成します。自己署名証明書を生成するには、コマンドラインでホスト名も指定する必要があります。 たとえば、次のコマンドは、ホスト名に ​`SAN=DNS:localhost,IP:127.0.0.1`​ を指定して ​`keystore.jks`​ ファイルを作成します。 ```text keytool -genkeypair -keystore keystore.jks -dname "CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass password -storepass password -keyalg RSA -sigalg SHA1withRSA -keysize 2048 -alias mule -ext SAN=DNS:localhost,IP:127.0.0.1 -validity 9999 ``` 2. 生成された ​`keystore.jks`​ ファイルを Anypoint Studio Mule アプリケーションフォルダーの ​`src/main/resources`​ に追加します。 3. Mule アプリケーションの HTTP リスナーを HTTPS に設定し、次のものを指定します。 - `host`​ の値に HTTPS スキームで使用するホスト IP アドレス。 - `port`​ の値の ${https.port} 変数の値。 ```xml ... ... ``` 1. HTTPS グローバルリスナー設定への ​`config-ref`​ 参照を含めます。 ```xml ``` 1. 外部アドレスへの HTTPS 要求を有効にするために必要な TLS 設定を使用して HTTP リクエスターを設定します。 ```xml ... ... ``` 1. HTTPS グローバル要求設定への ​`config-ref`​ 参照を含めます。 ```xml ``` これで、アプリケーションを CloudHub にデプロイする準備が整いました。HTTPS アドレス (​`https://yourdomain.cloudhub.io`​ など) を使用してエンドポイントにアクセスできます。 ## [](#api-manager-プロキシに基づくサービスの設定)API Manager プロキシに基づくサービスの設定 API Manager からプロキシをダウンロードするように求められており、HTTPS 用に設定する必要がある場合、Anypoint Connector で HTTP 用に HTTP リクエスターを設定したのと同じ手順に従います。この HTTP リスナー設定はテンプレートとして提供されています。 設定を完了する手順は、次のとおりです。 1. プロキシプロジェクトを Anypoint Studio にインポートします。 2. プロキシフローの ​**\[Configuration XML (設定 XML)\]**​ タブを選択します。 フローがコメントアウトされている HTTPS Connector を参照しているため、パーサーでエラーが検出されます。 3. `http:listener-config`​ ブロックのコメントを解除します。 4. `keystore`​ の値を追加します: `path`​、​`password`​、​`keyPassword`​。 ```xml ``` - 外部プロパティを使用できます。 - `path`​ の値に ​`src/main/resources`​ を含めることはできません。 設定は、次のようになります。 ```xml ... ``` ## [](#http-リクエストおよびレスポンスヘッダーの設定)HTTP リクエストおよびレスポンスヘッダーの設定 `wrapper.conf`​ ファイルで次のシステムプロパティを変更することで、サーバーレスポンスヘッダー、サーバーリクエストヘッダー、クライアントリクエストヘッダーの最大値を変更できます。
名前 プロパティ 説明 デフォルト値

Server Response Headers (サーバーレスポンスヘッダー)

mule.http.MAX_SERVER_RESPONSE_HEADERS

HTTP サーバーから送信される応答で許容されるヘッダーの最大量。

100

Server Request Headers (サーバーリクエストヘッダー)

mule.http.MAX_SERVER_REQUEST_HEADERS

HTTP サーバーから送信される要求で許容されるヘッダーの最大量。

100

Client Request Headers (クライアントリクエストヘッダー)

mule.http.MAX_CLIENT_REQUEST_HEADERS

HTTP クライアントから送信される要求で許容されるヘッダーの最大量。

100
クライアントの HTTP レスポンスヘッダーには最大量の制限がないため、Max Client Response Header のようなシステムプロパティはありません。 ## [](#関連情報)関連情報 - Mule 4 での ​[HTTPS API プロキシの構築](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) - [TLS Configuration (TLS 設定)](https://docs.mulesoft.com/jp/mule-runtime/4.7/tls-configuration) # HTTPS サービスの構築 データの機密性を確保するために、HTTPS ベースのサービスを使用して Mule アプリケーションをデプロイできます。次のものを構築する方法を学習します。 - アプリケーションを CloudHub にデプロイする HTTPS サービス - API Manager プロキシを使用する HTTPS サービス さらに、HTTP リクエストおよびレスポンスヘッダーの設定方法を学習します。 アプリケーションをローカルにデプロイする場合は、​[「TLS 設定」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tls-configuration)​を参照してください。 ## [](#前提条件)前提条件 始める前に、サービス (シンプルな「Hello World」サービスなど) を構築してデプロイします。 [「API ビルドの最初から最後まで」](https://docs.mulesoft.com/jp/general/api-led-overview)​チュートリアルを使用して、API を設計し、開発する方法を学習します。 ## [](#https-サービスの構築)HTTPS サービスの構築 HTTPS を使用してアプリケーションを CloudHub にデプロイするようにサービスを変更します。 1. コマンドラインで JDK ​`keytool`​ ユーティリティを使用して ​`keystore.jks`​ ファイルを作成します。自己署名証明書を生成するには、コマンドラインでホスト名も指定する必要があります。 たとえば、次のコマンドは、ホスト名に ​`SAN=DNS:localhost,IP:127.0.0.1`​ を指定して ​`keystore.jks`​ ファイルを作成します。 ```text keytool -genkeypair -keystore keystore.jks -dname "CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass password -storepass password -keyalg RSA -sigalg SHA1withRSA -keysize 2048 -alias mule -ext SAN=DNS:localhost,IP:127.0.0.1 -validity 9999 ``` 2. 生成された ​`keystore.jks`​ ファイルを Anypoint Studio Mule アプリケーションフォルダーの ​`src/main/resources`​ に追加します。 3. Mule アプリケーションの HTTP リスナーを HTTPS に設定し、次のものを指定します。 - `host`​ の値に HTTPS スキームで使用するホスト IP アドレス。 - `port`​ の値の ${https.port} 変数の値。 ```xml ... ... ``` 1. HTTPS グローバルリスナー設定への ​`config-ref`​ 参照を含めます。 ```xml ``` 1. 外部アドレスへの HTTPS 要求を有効にするために必要な TLS 設定を使用して HTTP リクエスターを設定します。 ```xml ... ... ``` 1. HTTPS グローバル要求設定への ​`config-ref`​ 参照を含めます。 ```xml ``` これで、アプリケーションを CloudHub にデプロイする準備が整いました。HTTPS アドレス (​`https://yourdomain.cloudhub.io`​ など) を使用してエンドポイントにアクセスできます。 ## [](#api-manager-プロキシに基づくサービスの設定)API Manager プロキシに基づくサービスの設定 API Manager からプロキシをダウンロードするように求められており、HTTPS 用に設定する必要がある場合、Anypoint Connector で HTTP 用に HTTP リクエスターを設定したのと同じ手順に従います。この HTTP リスナー設定はテンプレートとして提供されています。 設定を完了する手順は、次のとおりです。 1. プロキシプロジェクトを Anypoint Studio にインポートします。 2. プロキシフローの ​**\[Configuration XML (設定 XML)\]**​ タブを選択します。 フローがコメントアウトされている HTTPS Connector を参照しているため、パーサーでエラーが検出されます。 3. `http:listener-config`​ ブロックのコメントを解除します。 4. `keystore`​ の値を追加します: `path`​、​`password`​、​`keyPassword`​。 ```xml ``` - 外部プロパティを使用できます。 - `path`​ の値に ​`src/main/resources`​ を含めることはできません。 設定は、次のようになります。 ```xml ... ``` ## [](#http-リクエストおよびレスポンスヘッダーの設定)HTTP リクエストおよびレスポンスヘッダーの設定 `wrapper.conf`​ ファイルで次のシステムプロパティを変更することで、サーバーレスポンスヘッダー、サーバーリクエストヘッダー、クライアントリクエストヘッダーの最大値を変更できます。
名前 プロパティ 説明 デフォルト値

Server Response Headers (サーバーレスポンスヘッダー)

mule.http.MAX_SERVER_RESPONSE_HEADERS

HTTP サーバーから送信される応答で許容されるヘッダーの最大量。

100

Server Request Headers (サーバーリクエストヘッダー)

mule.http.MAX_SERVER_REQUEST_HEADERS

HTTP サーバーから送信される要求で許容されるヘッダーの最大量。

100

Client Request Headers (クライアントリクエストヘッダー)

mule.http.MAX_CLIENT_REQUEST_HEADERS

HTTP クライアントから送信される要求で許容されるヘッダーの最大量。

100
クライアントの HTTP レスポンスヘッダーには最大量の制限がないため、Max Client Response Header のようなシステムプロパティはありません。 ## [](#関連情報)関連情報 - Mule 4 での ​[HTTPS API プロキシの構築](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) - [TLS Configuration (TLS 設定)](https://docs.mulesoft.com/jp/mule-runtime/4.8/tls-configuration) # HTTPS サービスの構築 データの機密性を確保するために、HTTPS ベースのサービスを使用して Mule アプリケーションをデプロイできます。次のものを構築する方法を学習します。 - アプリケーションを CloudHub にデプロイする HTTPS サービス - API Manager プロキシを使用する HTTPS サービス さらに、HTTP リクエストおよびレスポンスヘッダーの設定方法を学習します。 アプリケーションをローカルにデプロイする場合は、​[「TLS 設定」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tls-configuration)​を参照してください。 ## [](#前提条件)前提条件 始める前に、サービス (シンプルな「Hello World」サービスなど) を構築してデプロイします。 [「API ビルドの最初から最後まで」](https://docs.mulesoft.com/jp/general/api-led-overview)​チュートリアルを使用して、API を設計し、開発する方法を学習します。 ## [](#https-サービスの構築)HTTPS サービスの構築 HTTPS を使用してアプリケーションを CloudHub にデプロイするようにサービスを変更します。 1. コマンドラインで JDK ​`keytool`​ ユーティリティを使用して ​`keystore.jks`​ ファイルを作成します。自己署名証明書を生成するには、コマンドラインでホスト名も指定する必要があります。 たとえば、次のコマンドは、ホスト名に ​`SAN=DNS:localhost,IP:127.0.0.1`​ を指定して ​`keystore.jks`​ ファイルを作成します。 ```text keytool -genkeypair -keystore keystore.jks -dname "CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown" -keypass password -storepass password -keyalg RSA -sigalg SHA1withRSA -keysize 2048 -alias mule -ext SAN=DNS:localhost,IP:127.0.0.1 -validity 9999 ``` 2. 生成された ​`keystore.jks`​ ファイルを Anypoint Studio Mule アプリケーションフォルダーの ​`src/main/resources`​ に追加します。 3. Mule アプリケーションの HTTP リスナーを HTTPS に設定し、次のものを指定します。 - `host`​ の値に HTTPS スキームで使用するホスト IP アドレス。 - `port`​ の値の ${https.port} 変数の値。 ```xml ... ... ``` 1. HTTPS グローバルリスナー設定への ​`config-ref`​ 参照を含めます。 ```xml ``` 1. 外部アドレスへの HTTPS 要求を有効にするために必要な TLS 設定を使用して HTTP リクエスターを設定します。 ```xml ... ... ``` 1. HTTPS グローバル要求設定への ​`config-ref`​ 参照を含めます。 ```xml ``` これで、アプリケーションを CloudHub にデプロイする準備が整いました。HTTPS アドレス (​`https://yourdomain.cloudhub.io`​ など) を使用してエンドポイントにアクセスできます。 ## [](#api-manager-プロキシに基づくサービスの設定)API Manager プロキシに基づくサービスの設定 API Manager からプロキシをダウンロードするように求められており、HTTPS 用に設定する必要がある場合、Anypoint Connector で HTTP 用に HTTP リクエスターを設定したのと同じ手順に従います。この HTTP リスナー設定はテンプレートとして提供されています。 設定を完了する手順は、次のとおりです。 1. プロキシプロジェクトを Anypoint Studio にインポートします。 2. プロキシフローの ​**\[Configuration XML (設定 XML)\]**​ タブを選択します。 フローがコメントアウトされている HTTPS Connector を参照しているため、パーサーでエラーが検出されます。 3. `http:listener-config`​ ブロックのコメントを解除します。 4. `keystore`​ の値を追加します: `path`​、​`password`​、​`keyPassword`​。 ```xml ``` - 外部プロパティを使用できます。 - `path`​ の値に ​`src/main/resources`​ を含めることはできません。 設定は、次のようになります。 ```xml ... ``` ## [](#http-リクエストおよびレスポンスヘッダーの設定)HTTP リクエストおよびレスポンスヘッダーの設定 `wrapper.conf`​ ファイルで次のシステムプロパティを変更することで、サーバーレスポンスヘッダー、サーバーリクエストヘッダー、クライアントリクエストヘッダーの最大値を変更できます。
名前 プロパティ 説明 デフォルト値

Server Response Headers (サーバーレスポンスヘッダー)

mule.http.MAX_SERVER_RESPONSE_HEADERS

HTTP サーバーから送信される応答で許容されるヘッダーの最大量。

100

Server Request Headers (サーバーリクエストヘッダー)

mule.http.MAX_SERVER_REQUEST_HEADERS

HTTP サーバーから送信される要求で許容されるヘッダーの最大量。

100

Client Request Headers (クライアントリクエストヘッダー)

mule.http.MAX_CLIENT_REQUEST_HEADERS

HTTP クライアントから送信される要求で許容されるヘッダーの最大量。

100
クライアントの HTTP レスポンスヘッダーには最大量の制限がないため、Max Client Response Header のようなシステムプロパティはありません。 ## [](#関連情報)関連情報 - Mule 4 での ​[HTTPS API プロキシの構築](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) - [TLS Configuration (TLS 設定)](https://docs.mulesoft.com/jp/mule-runtime/4.9/tls-configuration) # Idempotent Message Validator Idempotent Message Validator (冪等性のあるメッセージ検証機能) は、受信メッセージの一意の ID を確認することによって、一意のメッセージのみがフローの実行を継続するようにします。Mule メッセージの任意の入力属性を ID として使用するか、または DataWeave 式を設定することで ID を計算できます。また、DataWeave ​`Crypto`​ 関数を使用してデータからハッシュ (SHA、MD5) を計算することもできます。 ## [](#メッセージのハッシュ)メッセージのハッシュ DataWeave では、ハッシュ関数を実行するための ​`Crypto`​ ライブラリをインポートできます。ハッシュの計算は、Mule メッセージの一意の ID を計算する場合に便利です。たとえば、ペイロードから MD5 ハッシュを取得してそれを ID として使用する場合は、Anypoint Studio で Idempotent Message Validator のプロパティを開いて、​**\[ID Expression (ID の式)\]**​ (XML では ​`idExpression`​) を次の DataWeave 式に設定します。 #\[ %dw 2.0 output text/plain import dw::Crypto --- Crypto::hashWith(payload,'MD5') \] ## [](#例)例 - 次の例では、HTTP 要求からクエリパラメーター ​`id`​ を抽出して、その値を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` - 次の例では、DataWeave 式を使用してペイロードをハッシュし、その結果を永続的なオブジェクトストアに保存して、処理後のメッセージ ID を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` ## [](#パラメーターリファレンス)パラメーターリファレンス
名前 型 説明 デフォルト値 必須

ID Expression (ID の式)

式

Mule が ID を生成するために使用する式。DataWeave 関数を使用して ID を計算するか、または Mule メッセージの任意の既存の値から ID を抽出することができます。

#[correlationId]

いいえ

Value Expression (値の式)

式

このパラメーターは使用しません。値を設定しても効果はありません。

#[correlationId]

いいえ

Object Store (オブジェクトストア)

Object Store (オブジェクトストア)

コンポーネントが処理されたメッセージ ID を格納するためのグローバルオブジェクトストアを参照する名前または非公開オブジェクトストアの定義。

オブジェクトストアマネージャーによって作成されたオブジェクトストア。永続的ではなく、エントリ TTL は 5 分、有効期限間隔は 6 秒です。

いいえ

Store Prefix (ストアプレフィックス)

String (文字列)

オブジェクトストア名のプレフィックスを定義します。この値は内部で作成されたオブジェクトストアにのみ使用します。

configFileName​.flowName.IdempotentMessageValidator

いいえ
### [](#スロー)スロー - `MULE:DUPLICATE_MESSAGE` ## [](#関連情報)関連情報 - [Crypto (dw::Crypto)](https://docs.mulesoft.com/jp/dataweave/2.3/dw-crypto) # Idempotent Message Validator Idempotent Message Validator (冪等性のあるメッセージ検証機能) は、受信メッセージの一意の ID を確認することによって、一意のメッセージのみがフローの実行を継続するようにします。Mule メッセージの任意の入力属性を ID として使用するか、または DataWeave 式を設定することで ID を計算できます。また、DataWeave ​`Crypto`​ 関数を使用してデータからハッシュ (SHA、MD5) を計算することもできます。 ## [](#メッセージのハッシュ)メッセージのハッシュ DataWeave では、ハッシュ関数を実行するための ​`Crypto`​ ライブラリをインポートできます。ハッシュの計算は、Mule メッセージの一意の ID を計算する場合に便利です。たとえば、ペイロードから MD5 ハッシュを取得してそれを ID として使用する場合は、Anypoint Studio で Idempotent Message Validator のプロパティを開いて、​**\[ID Expression (ID の式)\]**​ (XML では ​`idExpression`​) を次の DataWeave 式に設定します。 #\[ %dw 2.0 output text/plain import dw::Crypto --- Crypto::hashWith(payload,'MD5') \] ## [](#例)例 - 次の例では、HTTP 要求からクエリパラメーター ​`id`​ を抽出して、その値を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` - 次の例では、DataWeave 式を使用してペイロードをハッシュし、その結果を永続的なオブジェクトストアに保存して、処理後のメッセージ ID を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` ## [](#パラメーターリファレンス)パラメーターリファレンス
名前 型 説明 デフォルト値 必須

ID Expression (ID の式)

式

Mule が ID を生成するために使用する式。DataWeave 関数を使用して ID を計算するか、または Mule メッセージの任意の既存の値から ID を抽出することができます。

#[correlationId]

いいえ

Value Expression (値の式)

式

このパラメーターは使用しません。値を設定しても効果はありません。

#[correlationId]

いいえ

Object Store (オブジェクトストア)

Object Store (オブジェクトストア)

コンポーネントが処理されたメッセージ ID を格納するためのグローバルオブジェクトストアを参照する名前または非公開オブジェクトストアの定義。

オブジェクトストアマネージャーによって作成されたオブジェクトストア。永続的ではなく、エントリ TTL は 5 分、有効期限間隔は 6 秒です。

いいえ

Store Prefix (ストアプレフィックス)

String (文字列)

オブジェクトストア名のプレフィックスを定義します。この値は内部で作成されたオブジェクトストアにのみ使用します。

configFileName​.flowName.IdempotentMessageValidator

いいえ
### [](#スロー)スロー - `MULE:DUPLICATE_MESSAGE` ## [](#関連情報)関連情報 - [Crypto (dw::Crypto)](https://docs.mulesoft.com/dataweave/latest/dw-crypto) # Idempotent Message Validator Idempotent Message Validator (冪等性のあるメッセージバリデーター) は、受信メッセージの一意の ID を確認することによって、一意のメッセージのみがフローの実行を継続するようにします。Mule メッセージの任意の入力属性を ID として使用するか、または DataWeave 式を設定することで ID を計算できます。また、DataWeave ​`Crypto`​ 関数を使用してデータからハッシュ (SHA、MD5) を計算することもできます。 ## [](#メッセージのハッシュ)メッセージのハッシュ DataWeave では、ハッシュ関数を実行するための ​`Crypto`​ ライブラリをインポートできます。ハッシュの計算は、Mule メッセージの一意の ID を計算する場合に便利です。たとえば、ペイロードから MD5 ハッシュを取得してそれを ID として使用する場合は、Anypoint Studio で Idempotent Message Validator のプロパティを開いて、​**\[ID Expression (ID の式)\]**​ (XML では ​`idExpression`​) を次の DataWeave 式に設定します。 #\[ %dw 2.0 output text/plain import dw::Crypto --- Crypto::hashWith(payload,'MD5') \] ## [](#例)例 - 次の例では、HTTP 要求からクエリパラメーター ​`id`​ を抽出して、その値を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` - 次の例では、DataWeave 式を使用してペイロードをハッシュし、その結果を永続的なオブジェクトストアに保存して、処理後のメッセージ ID を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` ## [](#パラメーターリファレンス)パラメーターリファレンス
名前 型 説明 デフォルト値 必須

ID Expression (ID の式)

式

Mule が ID を生成するために使用する式。DataWeave 関数を使用して ID を計算するか、または Mule メッセージの任意の既存の値から ID を抽出することができます。

#[correlationId]

いいえ

Value Expression (値の式)

式

このパラメーターは使用しません。値を設定しても効果はありません。

#[correlationId]

いいえ

Object Store (オブジェクトストア)

Object Store (オブジェクトストア)

コンポーネントが処理されたメッセージ ID を格納するためのグローバルオブジェクトストアを参照する名前または非公開オブジェクトストアの定義。

オブジェクトストアマネージャーによって作成されたオブジェクトストア。永続的ではなく、エントリ TTL は 5 分、有効期限間隔は 6 秒です。

いいえ

Store Prefix (ストアプレフィックス)

String (文字列)

オブジェクトストア名のプレフィックスを定義します。この値は内部で作成されたオブジェクトストアにのみ使用します。

configFileName​.flowName.IdempotentMessageValidator

いいえ
### [](#スロー)スロー - `MULE:DUPLICATE_MESSAGE` ## [](#関連情報)関連情報 - [Crypto (dw::Crypto)](https://docs.mulesoft.com/dataweave/latest/dw-crypto) # Idempotent Message Validator Idempotent Message Validator (冪等性のあるメッセージ検証機能) は、受信メッセージの一意の ID を確認することによって、一意のメッセージのみがフローの実行を継続するようにします。Mule メッセージの任意の入力属性を ID として使用するか、または DataWeave 式を設定することで ID を計算できます。また、DataWeave ​`Crypto`​ 関数を使用してデータからハッシュ (SHA、MD5) を計算することもできます。 ## [](#メッセージのハッシュ)メッセージのハッシュ DataWeave では、ハッシュ関数を実行するための ​`Crypto`​ ライブラリをインポートできます。ハッシュの計算は、Mule メッセージの一意の ID を計算する場合に便利です。たとえば、ペイロードから MD5 ハッシュを取得してそれを ID として使用する場合は、Anypoint Studio で Idempotent Message Validator のプロパティを開いて、​**\[ID Expression (ID の式)\]**​ (XML では ​`idExpression`​) を次の DataWeave 式に設定します。 #\[ %dw 2.0 output text/plain import dw::Crypto --- Crypto::hashWith(payload,'MD5') \] ## [](#例)例 - 次の例では、HTTP 要求からクエリパラメーター ​`id`​ を抽出して、その値を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` - 次の例では、DataWeave 式を使用してペイロードをハッシュし、その結果を永続的なオブジェクトストアに保存して、処理後のメッセージ ID を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` ## [](#パラメーターリファレンス)パラメーターリファレンス
名前 型 説明 デフォルト値 必須

ID Expression (ID の式)

式

Mule が ID を生成するために使用する式。DataWeave 関数を使用して ID を計算するか、または Mule メッセージの任意の既存の値から ID を抽出することができます。

#[correlationId]

いいえ

Value Expression (値の式)

式

このパラメーターは使用しません。値を設定しても効果はありません。

#[correlationId]

いいえ

Object Store (オブジェクトストア)

Object Store (オブジェクトストア)

コンポーネントが処理されたメッセージ ID を格納するためのグローバルオブジェクトストアを参照する名前または非公開オブジェクトストアの定義。

オブジェクトストアマネージャーによって作成されたオブジェクトストア。永続的ではなく、エントリ TTL は 5 分、有効期限間隔は 6 秒です。

いいえ

Store Prefix (ストアプレフィックス)

String (文字列)

オブジェクトストア名のプレフィックスを定義します。この値は内部で作成されたオブジェクトストアにのみ使用します。

configFileName​.flowName.IdempotentMessageValidator

いいえ
### [](#スロー)スロー - `MULE:DUPLICATE_MESSAGE` ## [](#関連情報)関連情報 - [Crypto (dw::Crypto)](https://docs.mulesoft.com/dataweave/latest/dw-crypto) # Idempotent Message Validator Idempotent Message Validator (冪等性のあるメッセージバリデーター) は、受信メッセージの一意の ID を確認することによって、一意のメッセージのみがフローの実行を継続するようにします。Mule メッセージの任意の入力属性を ID として使用するか、または DataWeave 式を設定することで ID を計算できます。また、DataWeave ​`Crypto`​ 関数を使用してデータからハッシュ (SHA、MD5) を計算することもできます。 ## [](#メッセージのハッシュ)メッセージのハッシュ DataWeave では、ハッシュ関数を実行するための ​`Crypto`​ ライブラリをインポートできます。ハッシュの計算は、Mule メッセージの一意の ID を計算する場合に便利です。たとえば、ペイロードから MD5 ハッシュを取得してそれを ID として使用する場合は、Anypoint Studio で Idempotent Message Validator のプロパティを開いて、​**\[ID Expression (ID の式)\]**​ (XML では ​`idExpression`​) を次の DataWeave 式に設定します。 #\[ %dw 2.0 output text/plain import dw::Crypto --- Crypto::hashWith(payload,'MD5') \] ## [](#例)例 - 次の例では、HTTP 要求からクエリパラメーター ​`id`​ を抽出して、その値を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` - 次の例では、DataWeave 式を使用してペイロードをハッシュし、その結果を永続的なオブジェクトストアに保存して、処理後のメッセージ ID を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` ## [](#パラメーターリファレンス)パラメーターリファレンス
名前 型 説明 デフォルト値 必須

ID Expression (ID の式)

式

Mule が ID を生成するために使用する式。DataWeave 関数を使用して ID を計算するか、または Mule メッセージの任意の既存の値から ID を抽出することができます。

#[correlationId]

いいえ

Value Expression (値の式)

式

このパラメーターは使用しません。値を設定しても効果はありません。

#[correlationId]

いいえ

Object Store (オブジェクトストア)

Object Store (オブジェクトストア)

コンポーネントが処理されたメッセージ ID を格納するためのグローバルオブジェクトストアを参照する名前または非公開オブジェクトストアの定義。

オブジェクトストアマネージャーによって作成されたオブジェクトストア。永続的ではなく、エントリ TTL は 5 分、有効期限間隔は 6 秒です。

いいえ

Store Prefix (ストアプレフィックス)

String (文字列)

オブジェクトストア名のプレフィックスを定義します。この値は内部で作成されたオブジェクトストアにのみ使用します。

configFileName​.flowName.IdempotentMessageValidator

いいえ
### [](#スロー)スロー - `MULE:DUPLICATE_MESSAGE` ## [](#関連情報)関連情報 - [Crypto (dw::Crypto)](https://docs.mulesoft.com/dataweave/latest/dw-crypto) # Idempotent Message Validator Idempotent Message Validator (冪等性のあるメッセージバリデーター) は、受信メッセージの一意の ID を確認することによって、一意のメッセージのみがフローの実行を継続するようにします。Mule メッセージの任意の入力属性を ID として使用するか、または DataWeave 式を設定することで ID を計算できます。また、DataWeave ​`Crypto`​ 関数を使用してデータからハッシュ (SHA、MD5) を計算することもできます。 ## [](#メッセージのハッシュ)メッセージのハッシュ DataWeave では、ハッシュ関数を実行するための ​`Crypto`​ ライブラリをインポートできます。ハッシュの計算は、Mule メッセージの一意の ID を計算する場合に便利です。たとえば、ペイロードから MD5 ハッシュを取得してそれを ID として使用する場合は、Anypoint Studio で Idempotent Message Validator のプロパティを開いて、​**\[ID Expression (ID の式)\]**​ (XML では ​`idExpression`​) を次の DataWeave 式に設定します。 #\[ %dw 2.0 output text/plain import dw::Crypto --- Crypto::hashWith(payload,'MD5') \] ## [](#例)例 - 次の例では、HTTP 要求からクエリパラメーター ​`id`​ を抽出して、その値を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` - 次の例では、DataWeave 式を使用してペイロードをハッシュし、その結果を永続的なオブジェクトストアに保存して、処理後のメッセージ ID を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` ## [](#パラメーターリファレンス)パラメーターリファレンス
名前 型 説明 デフォルト値 必須

ID Expression (ID の式)

式

Mule が ID を生成するために使用する式。DataWeave 関数を使用して ID を計算するか、または Mule メッセージの任意の既存の値から ID を抽出することができます。

#[correlationId]

いいえ

Value Expression (値の式)

式

このパラメーターは使用しません。値を設定しても効果はありません。

#[correlationId]

いいえ

Object Store (オブジェクトストア)

Object Store (オブジェクトストア)

コンポーネントが処理されたメッセージ ID を格納するためのグローバルオブジェクトストアを参照する名前または非公開オブジェクトストアの定義。

オブジェクトストアマネージャーによって作成されたオブジェクトストア。永続的ではなく、エントリ TTL は 5 分、有効期限間隔は 6 秒です。

いいえ

Store Prefix (ストアプレフィックス)

String (文字列)

オブジェクトストア名のプレフィックスを定義します。この値は内部で作成されたオブジェクトストアにのみ使用します。

configFileName​.flowName.IdempotentMessageValidator

いいえ
### [](#スロー)スロー - `MULE:DUPLICATE_MESSAGE` ## [](#関連情報)関連情報 - [Crypto (dw::Crypto)](https://docs.mulesoft.com/dataweave/latest/dw-crypto) # Idempotent Message Validator Idempotent Message Validator (冪等性のあるメッセージバリデーター) は、受信メッセージの一意の ID を確認することによって、一意のメッセージのみがフローの実行を継続するようにします。Mule メッセージの任意の入力属性を ID として使用するか、または DataWeave 式を設定することで ID を計算できます。また、DataWeave ​`Crypto`​ 関数を使用してデータからハッシュ (SHA、MD5) を計算することもできます。 ## [](#メッセージのハッシュ)メッセージのハッシュ DataWeave では、ハッシュ関数を実行するための ​`Crypto`​ ライブラリをインポートできます。ハッシュの計算は、Mule メッセージの一意の ID を計算する場合に便利です。たとえば、ペイロードから MD5 ハッシュを取得してそれを ID として使用する場合は、Anypoint Studio で Idempotent Message Validator のプロパティを開いて、​**\[ID Expression (ID の式)\]**​ (XML では ​`idExpression`​) を次の DataWeave 式に設定します。 #\[ %dw 2.0 output text/plain import dw::Crypto --- Crypto::hashWith(payload,'MD5') \] ## [](#例)例 - 次の例では、HTTP 要求からクエリパラメーター ​`id`​ を抽出して、その値を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` - 次の例では、DataWeave 式を使用してペイロードをハッシュし、その結果を永続的なオブジェクトストアに保存して、処理後のメッセージ ID を一意の ID として使用してメッセージを絞り込むように Idempotent Message Validator を設定しています。 ```xml ... ... ``` ## [](#パラメーターリファレンス)パラメーターリファレンス
名前 型 説明 デフォルト値 必須

ID Expression (ID の式)

式

Mule が ID を生成するために使用する式。DataWeave 関数を使用して ID を計算するか、または Mule メッセージの任意の既存の値から ID を抽出することができます。

#[correlationId]

いいえ

Value Expression (値の式)

式

このパラメーターは使用しません。値を設定しても効果はありません。

#[correlationId]

いいえ

Object Store (オブジェクトストア)

Object Store (オブジェクトストア)

コンポーネントが処理されたメッセージ ID を格納するためのグローバルオブジェクトストアを参照する名前または非公開オブジェクトストアの定義。

オブジェクトストアマネージャーによって作成されたオブジェクトストア。永続的ではなく、エントリ TTL は 5 分、有効期限間隔は 6 秒です。

いいえ

Store Prefix (ストアプレフィックス)

String (文字列)

オブジェクトストア名のプレフィックスを定義します。この値は内部で作成されたオブジェクトストアにのみ使用します。

configFileName​.flowName.IdempotentMessageValidator

いいえ
### [](#スロー)スロー - `MULE:DUPLICATE_MESSAGE` ## [](#関連情報)関連情報 - [Crypto (dw::Crypto)](https://docs.mulesoft.com/dataweave/latest/dw-crypto) # 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 にパブリッシュします。
# 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 にパブリッシュします。
# 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 にパブリッシュします。
# 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 にパブリッシュします。
# 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 にパブリッシュします。
# 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 にパブリッシュします。
# 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 にパブリッシュします。
# JSON Module の移行 スキーマ検証用に Mule 3 にバンドルされていた JSON Module が、Mule 4 で新しい JSON Module に置き換わります。 JSON を使用する変換を移行するには、DataWeave を使用することをお勧めします。 ## [](#transformers)トランスフォーマーの移行 Mule 3 の場合、多くのコンポーネントでは、項目にアクセスできるようペイロードは POJO である必要がありました。Mule 4 では、JSON ペイロードで直接 DataWeave をクエリ言語として使用し、ペイロードを中間ステップとして POJO に変換する必要性を完全に回避できます。 ### [](#json-to-object-トランスフォーマー)JSON to Object トランスフォーマー `json:json-to-object-transformer`​ に設定されるマッピングルールの場合は、DataWeave でルールを記述できます。 - Mule 3 の場合: 例: マッパー設定で使用される Mixin ```java public abstract class AppleMixin { AppleMixin(@JsonProperty("bitten") boolean wasBitten) { super(); } } ``` 例: マッパーを参照するトランスフォーマー ```xml ``` - Mule 4 の場合: 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 ではマッパーや mixin クラスを定義する必要がありません。マッピングルールは DataWeave コードを使用して定義されます。 ### [](#object-to-json-トランスフォーマー)Object to JSON トランスフォーマー `json:object-to-json-transformer`​ のマッピングルールも DataWeave を使用して表されます。 Mule 3 の場合: - 例: Mixin を使用したトランスフォーマー ```xml ``` Mule 4 の場合: - 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 では変換で出力形式を設定できます。この場合は、変換関数が JSON ペイロードを返すように式で出力を ​`application/json`​ として定義します。 ## [](#xslt)XSLT 操作の移行 Mule 4 の JSON Module は、XSLT マッピングに基づいて JSON を変換するコンポーネントは提供されていません。この場合には、次のような対処法があります。 - XSLT を DataWeave 変換に移行する (推奨)。 - XML Module の XSLT サポートを使用して最初にペイロードを XML に変換する。 Mule 4 の例: XSLT を使用した JSON の変換 ```xml ... #[output application/xml --- payload] (the XSLT transformation) ... ... ``` ## [](#関連情報)関連情報 - [JSON Module](https://docs.mulesoft.com/jp/json-module/latest/) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # JSON Module の移行 スキーマ検証用に Mule 3 にバンドルされていた JSON Module が、Mule 4 で新しい JSON Module に置き換わります。 JSON を使用する変換を移行するには、DataWeave を使用することをお勧めします。 ## [](#transformers)トランスフォーマーの移行 Mule 3 の場合、多くのコンポーネントでは、項目にアクセスできるようペイロードは POJO である必要がありました。Mule 4 では、JSON ペイロードで直接 DataWeave をクエリ言語として使用し、ペイロードを中間ステップとして POJO に変換する必要性を完全に回避できます。 ### [](#json-to-object-トランスフォーマー)JSON to Object トランスフォーマー `json:json-to-object-transformer`​ に設定されるマッピングルールの場合は、DataWeave でルールを記述できます。 - Mule 3 の場合: 例: マッパー設定で使用される Mixin ```java public abstract class AppleMixin { AppleMixin(@JsonProperty("bitten") boolean wasBitten) { super(); } } ``` 例: マッパーを参照するトランスフォーマー ```xml ``` - Mule 4 の場合: 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 ではマッパーや mixin クラスを定義する必要がありません。マッピングルールは DataWeave コードを使用して定義されます。 ### [](#object-to-json-トランスフォーマー)Object to JSON トランスフォーマー `json:object-to-json-transformer`​ のマッピングルールも DataWeave を使用して表されます。 Mule 3 の場合: - 例: Mixin を使用したトランスフォーマー ```xml ``` Mule 4 の場合: - 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 では変換で出力形式を設定できます。この場合は、変換関数が JSON ペイロードを返すように式で出力を ​`application/json`​ として定義します。 ## [](#xslt)XSLT 操作の移行 Mule 4 の JSON Module は、XSLT マッピングに基づいて JSON を変換するコンポーネントは提供されていません。この場合には、次のような対処法があります。 - XSLT を DataWeave 変換に移行する (推奨)。 - XML Module の XSLT サポートを使用して最初にペイロードを XML に変換する。 Mule 4 の例: XSLT を使用した JSON の変換 ```xml ... #[output application/xml --- payload] (the XSLT transformation) ... ... ``` ## [](#関連情報)関連情報 - [JSON Module](https://docs.mulesoft.com/jp/json-module/latest/) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # JSON Module の移行 スキーマ検証用に Mule 3 にバンドルされていた JSON Module が、Mule 4 で新しい JSON Module に置き換わります。 JSON を使用する変換を移行するには、DataWeave を使用することをお勧めします。 ## [](#transformers)トランスフォーマーの移行 Mule 3 の場合、多くのコンポーネントでは、項目にアクセスできるようペイロードは POJO である必要がありました。Mule 4 では、JSON ペイロードで直接 DataWeave をクエリ言語として使用し、ペイロードを中間ステップとして POJO に変換する必要性を完全に回避できます。 ### [](#json-to-object-トランスフォーマー)JSON to Object トランスフォーマー `json:json-to-object-transformer`​ に設定されるマッピングルールの場合は、DataWeave でルールを記述できます。 - Mule 3 の場合: 例: マッパー設定で使用される Mixin ```java public abstract class AppleMixin { AppleMixin(@JsonProperty("bitten") boolean wasBitten) { super(); } } ``` 例: マッパーを参照するトランスフォーマー ```xml ``` - Mule 4 の場合: 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 ではマッパーや mixin クラスを定義する必要がありません。マッピングルールは DataWeave コードを使用して定義されます。 ### [](#object-to-json-トランスフォーマー)Object to JSON トランスフォーマー `json:object-to-json-transformer`​ のマッピングルールも DataWeave を使用して表されます。 Mule 3 の場合: - 例: Mixin を使用したトランスフォーマー ```xml ``` Mule 4 の場合: - 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 では変換で出力形式を設定できます。この場合は、変換関数が JSON ペイロードを返すように式で出力を ​`application/json`​ として定義します。 ## [](#xslt)XSLT 操作の移行 Mule 4 の JSON Module は、XSLT マッピングに基づいて JSON を変換するコンポーネントは提供されていません。この場合には、次のような対処法があります。 - XSLT を DataWeave 変換に移行する (推奨)。 - XML Module の XSLT サポートを使用して最初にペイロードを XML に変換する。 Mule 4 の例: XSLT を使用した JSON の変換 ```xml ... #[output application/xml --- payload] (the XSLT transformation) ... ... ``` ## [](#関連情報)関連情報 - [JSON Module](https://docs.mulesoft.com/jp/json-module/latest/) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # JSON Module の移行 スキーマ検証用に Mule 3 にバンドルされていた JSON Module が、Mule 4 で新しい JSON Module に置き換わります。 JSON を使用する変換を移行するには、DataWeave を使用することをお勧めします。 ## [](#transformers)トランスフォーマーの移行 Mule 3 の場合、多くのコンポーネントでは、項目にアクセスできるようペイロードは POJO である必要がありました。Mule 4 では、JSON ペイロードで直接 DataWeave をクエリ言語として使用し、ペイロードを中間ステップとして POJO に変換する必要性を完全に回避できます。 ### [](#json-to-object-トランスフォーマー)JSON to Object トランスフォーマー `json:json-to-object-transformer`​ に設定されるマッピングルールの場合は、DataWeave でルールを記述できます。 - Mule 3 の場合: 例: マッパー設定で使用される Mixin ```java public abstract class AppleMixin { AppleMixin(@JsonProperty("bitten") boolean wasBitten) { super(); } } ``` 例: マッパーを参照するトランスフォーマー ```xml ``` - Mule 4 の場合: 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 ではマッパーや mixin クラスを定義する必要がありません。マッピングルールは DataWeave コードを使用して定義されます。 ### [](#object-to-json-トランスフォーマー)Object to JSON トランスフォーマー `json:object-to-json-transformer`​ のマッピングルールも DataWeave を使用して表されます。 Mule 3 の場合: - 例: Mixin を使用したトランスフォーマー ```xml ``` Mule 4 の場合: - 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 では変換で出力形式を設定できます。この場合は、変換関数が JSON ペイロードを返すように式で出力を ​`application/json`​ として定義します。 ## [](#xslt)XSLT 操作の移行 Mule 4 の JSON Module は、XSLT マッピングに基づいて JSON を変換するコンポーネントは提供されていません。この場合には、次のような対処法があります。 - XSLT を DataWeave 変換に移行する (推奨)。 - XML Module の XSLT サポートを使用して最初にペイロードを XML に変換する。 Mule 4 の例: XSLT を使用した JSON の変換 ```xml ... #[output application/xml --- payload] (the XSLT transformation) ... ... ``` ## [](#関連情報)関連情報 - [JSON Module](https://docs.mulesoft.com/jp/json-module/latest/) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # JSON Module の移行 スキーマ検証用に Mule 3 にバンドルされていた JSON Module が、Mule 4 で新しい JSON Module に置き換わります。 JSON を使用する変換を移行するには、DataWeave を使用することをお勧めします。 ## [](#transformers)トランスフォーマーの移行 Mule 3 の場合、多くのコンポーネントでは、項目にアクセスできるようペイロードは POJO である必要がありました。Mule 4 では、JSON ペイロードで直接 DataWeave をクエリ言語として使用し、ペイロードを中間ステップとして POJO に変換する必要性を完全に回避できます。 ### [](#json-to-object-トランスフォーマー)JSON to Object トランスフォーマー `json:json-to-object-transformer`​ に設定されるマッピングルールの場合は、DataWeave でルールを記述できます。 - Mule 3 の場合: 例: マッパー設定で使用される Mixin ```java public abstract class AppleMixin { AppleMixin(@JsonProperty("bitten") boolean wasBitten) { super(); } } ``` 例: マッパーを参照するトランスフォーマー ```xml ``` - Mule 4 の場合: 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 ではマッパーや mixin クラスを定義する必要がありません。マッピングルールは DataWeave コードを使用して定義されます。 ### [](#object-to-json-トランスフォーマー)Object to JSON トランスフォーマー `json:object-to-json-transformer`​ のマッピングルールも DataWeave を使用して表されます。 Mule 3 の場合: - 例: Mixin を使用したトランスフォーマー ```xml ``` Mule 4 の場合: - 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 では変換で出力形式を設定できます。この場合は、変換関数が JSON ペイロードを返すように式で出力を ​`application/json`​ として定義します。 ## [](#xslt)XSLT 操作の移行 Mule 4 の JSON Module は、XSLT マッピングに基づいて JSON を変換するコンポーネントは提供されていません。この場合には、次のような対処法があります。 - XSLT を DataWeave 変換に移行する (推奨)。 - XML Module の XSLT サポートを使用して最初にペイロードを XML に変換する。 Mule 4 の例: XSLT を使用した JSON の変換 ```xml ... #[output application/xml --- payload] (the XSLT transformation) ... ... ``` ## [](#関連情報)関連情報 - [JSON Module](https://docs.mulesoft.com/jp/json-module/latest/) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # JSON Module の移行 スキーマ検証用に Mule 3 にバンドルされていた JSON Module が、Mule 4 で新しい JSON Module に置き換わります。 JSON を使用する変換を移行するには、DataWeave を使用することをお勧めします。 ## [](#transformers)トランスフォーマーの移行 Mule 3 の場合、多くのコンポーネントでは、項目にアクセスできるようペイロードは POJO である必要がありました。Mule 4 では、JSON ペイロードで直接 DataWeave をクエリ言語として使用し、ペイロードを中間ステップとして POJO に変換する必要性を完全に回避できます。 ### [](#json-to-object-トランスフォーマー)JSON to Object トランスフォーマー `json:json-to-object-transformer`​ に設定されるマッピングルールの場合は、DataWeave でルールを記述できます。 - Mule 3 の場合: 例: マッパー設定で使用される Mixin ```java public abstract class AppleMixin { AppleMixin(@JsonProperty("bitten") boolean wasBitten) { super(); } } ``` 例: マッパーを参照するトランスフォーマー ```xml ``` - Mule 4 の場合: 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 ではマッパーや mixin クラスを定義する必要がありません。マッピングルールは DataWeave コードを使用して定義されます。 ### [](#object-to-json-トランスフォーマー)Object to JSON トランスフォーマー `json:object-to-json-transformer`​ のマッピングルールも DataWeave を使用して表されます。 Mule 3 の場合: - 例: Mixin を使用したトランスフォーマー ```xml ``` Mule 4 の場合: - 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 では変換で出力形式を設定できます。この場合は、変換関数が JSON ペイロードを返すように式で出力を ​`application/json`​ として定義します。 ## [](#xslt)XSLT 操作の移行 Mule 4 の JSON Module は、XSLT マッピングに基づいて JSON を変換するコンポーネントは提供されていません。この場合には、次のような対処法があります。 - XSLT を DataWeave 変換に移行する (推奨)。 - XML Module の XSLT サポートを使用して最初にペイロードを XML に変換する。 Mule 4 の例: XSLT を使用した JSON の変換 ```xml ... #[output application/xml --- payload] (the XSLT transformation) ... ... ``` ## [](#関連情報)関連情報 - [JSON Module](https://docs.mulesoft.com/jp/json-module/latest/) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # JSON Module の移行 スキーマ検証用に Mule 3 にバンドルされていた JSON Module が、Mule 4 で新しい JSON Module に置き換わります。 JSON を使用する変換を移行するには、DataWeave を使用することをお勧めします。 ## [](#transformers)トランスフォーマーの移行 Mule 3 の場合、多くのコンポーネントでは、項目にアクセスできるようペイロードは POJO である必要がありました。Mule 4 では、JSON ペイロードで直接 DataWeave をクエリ言語として使用し、ペイロードを中間ステップとして POJO に変換する必要性を完全に回避できます。 ### [](#json-to-object-トランスフォーマー)JSON to Object トランスフォーマー `json:json-to-object-transformer`​ に設定されるマッピングルールの場合は、DataWeave でルールを記述できます。 - Mule 3 の場合: 例: マッパー設定で使用される Mixin ```java public abstract class AppleMixin { AppleMixin(@JsonProperty("bitten") boolean wasBitten) { super(); } } ``` 例: マッパーを参照するトランスフォーマー ```xml ``` - Mule 4 の場合: 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 ではマッパーや mixin クラスを定義する必要がありません。マッピングルールは DataWeave コードを使用して定義されます。 ### [](#object-to-json-トランスフォーマー)Object to JSON トランスフォーマー `json:object-to-json-transformer`​ のマッピングルールも DataWeave を使用して表されます。 Mule 3 の場合: - 例: Mixin を使用したトランスフォーマー ```xml ``` Mule 4 の場合: - 例: DataWeave をマッパーとして使用 ```xml ``` Mule 4 では変換で出力形式を設定できます。この場合は、変換関数が JSON ペイロードを返すように式で出力を ​`application/json`​ として定義します。 ## [](#xslt)XSLT 操作の移行 Mule 4 の JSON Module は、XSLT マッピングに基づいて JSON を変換するコンポーネントは提供されていません。この場合には、次のような対処法があります。 - XSLT を DataWeave 変換に移行する (推奨)。 - XML Module の XSLT サポートを使用して最初にペイロードを XML に変換する。 Mule 4 の例: XSLT を使用した JSON の変換 ```xml ... #[output application/xml --- payload] (the XSLT transformation) ... ... ``` ## [](#関連情報)関連情報 - [JSON Module](https://docs.mulesoft.com/jp/json-module/latest/) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # Logger コンポーネント このコアコンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグするのに役立ちます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。

Logger は、値に文字列と式を組み合わせることができる数少ないコンポーネントの 1 つです。1 つの式で DataWeave 文字列を補間または連結する場合は他の場所で行います。
設定したメッセージはアプリケーションのログファイルに記録されます。このログファイルは、​`log4j2.xml`​ ファイルでカスタムログファイルパスを指定していない場合、​`MULE_HOME/logs/.log`​ にあります。 Studio では、ログはコンソールに表示されます。 次の例では、メッセージをブラウザーの \[Set Payload (ペイロードを設定)\] に表示すると同時に、メッセージをログにも記録します。 ![logger flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/logger-flow.png) 例: フローの XML 設定 ```xml ``` ## [](#logger-の設定)Logger の設定 ![logger](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/logger.png)
項目 値 説明 例

Message (メッセージ)

String (文字列) または DataWeave 式

Mule のログメッセージを指定します。デフォルトで、メッセージはアプリケーションのログファイルに記録されます。

message="Current payload is #[payload]"​

レベル

選択可能なオプション:

  • DEBUG​

  • ERROR​

  • INFO​ (デフォルト)

  • TRACE​

  • WARN

ログレベルを指定します。

level="ERROR"

Category (カテゴリ)

String (文字列)

log4j2.xml​ ファイルに追加するカテゴリ名を指定する省略可能な設定です。カテゴリの用途の例として、カテゴリに基づいてログメッセージをルーティングすることや、カテゴリに基づいてログレベルを設定することが考えられます。

category="MyCustomCategory"
## [](#例)例 次の Logger は、文字列と式を組み合わせて、メッセージの処理状態を監視するように設定されています。 ```xml ``` 次の Logger は、1 つの式と DataWeave の文字列連結を使用して、フローの処理時間を記録するように設定されています。 ```xml ``` ## [](#関連情報)関連情報 [DataWeave の文字列型](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-types#dw_type_string) # Logger コンポーネント このコアコンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグするのに役立ちます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。

Logger は、値に文字列と式を組み合わせることができる数少ないコンポーネントの 1 つです。1 つの式で DataWeave 文字列を補間または連結する場合は他の場所で行います。
設定したメッセージはアプリケーションのログファイルに記録されます。このログファイルは、​`log4j2.xml`​ ファイルでカスタムログファイルパスを指定していない場合、​`MULE_HOME/logs/.log`​ にあります。 Studio では、ログはコンソールに表示されます。 次の例では、メッセージをブラウザーの \[Set Payload (ペイロードを設定)\] に表示すると同時に、メッセージをログにも記録します。 ![logger flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/logger-flow.png) 例: フローの XML 設定 ```xml ``` ## [](#logger-の設定)Logger の設定 ![logger](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/logger.png)
項目 値 説明 例

Message (メッセージ)

String (文字列) または DataWeave 式

Mule のログメッセージを指定します。デフォルトで、メッセージはアプリケーションのログファイルに記録されます。

message="Current payload is #[payload]"​

レベル

選択可能なオプション:

  • DEBUG​

  • ERROR​

  • INFO​ (デフォルト)

  • TRACE​

  • WARN

ログレベルを指定します。

level="ERROR"

Category (カテゴリ)

String (文字列)

log4j2.xml​ ファイルに追加するカテゴリ名を指定する省略可能な設定です。カテゴリの用途の例として、カテゴリに基づいてログメッセージをルーティングすることや、カテゴリに基づいてログレベルを設定することが考えられます。

category="MyCustomCategory"
## [](#例)例 次の Logger は、文字列と式を組み合わせて、メッセージの処理状態を監視するように設定されています。 ```xml ``` 次の Logger は、1 つの式と DataWeave の文字列連結を使用して、フローの処理時間を記録するように設定されています。 ```xml ``` ## [](#関連情報)関連情報 [DataWeave の文字列型](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_string) # Logger コンポーネント このコアコンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグするのに役立ちます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。

Logger は、値に文字列と式を組み合わせることができる数少ないコンポーネントの 1 つです。1 つの式で DataWeave 文字列を補間または連結する場合は他の場所で行います。
設定したメッセージはアプリケーションのログファイルに記録されます。このログファイルは、​`log4j2.xml`​ ファイルでカスタムログファイルパスを指定していない場合、​`MULE_HOME/logs/.log`​ にあります。 Studio では、ログはコンソールに表示されます。 次の例では、メッセージをブラウザーの \[Set Payload (ペイロードを設定)\] に表示すると同時に、メッセージをログにも記録します。 ![logger flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/logger-flow.png) 例: フローの XML 設定 ```xml ``` ## [](#logger-の設定)Logger の設定 ![logger](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/logger.png)
項目 値 説明 例

Message (メッセージ)

String (文字列) または DataWeave 式

Mule のログメッセージを指定します。デフォルトで、メッセージはアプリケーションのログファイルに記録されます。

message="Current payload is #[payload]"​

レベル

選択可能なオプション:

  • DEBUG​

  • ERROR​

  • INFO​ (デフォルト)

  • TRACE​

  • WARN

ログレベルを指定します。

level="ERROR"

Category (カテゴリ)

String (文字列)

log4j2.xml​ ファイルに追加するカテゴリ名を指定する省略可能な設定です。カテゴリの用途の例として、カテゴリに基づいてログメッセージをルーティングすることや、カテゴリに基づいてログレベルを設定することが考えられます。

category="MyCustomCategory"
## [](#例)例 次の Logger は、文字列と式を組み合わせて、メッセージの処理状態を監視するように設定されています。 ```xml ``` 次の Logger は、1 つの式と DataWeave の文字列連結を使用して、フローの処理時間を記録するように設定されています。 ```xml ``` ## [](#関連情報)関連情報 [DataWeave の文字列型](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_string) # Logger コンポーネント このコアコンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグするのに役立ちます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。

Logger は、値に文字列と式を組み合わせることができる数少ないコンポーネントの 1 つです。1 つの式で DataWeave 文字列を補間または連結する場合は他の場所で行います。
設定したメッセージはアプリケーションのログファイルに記録されます。このログファイルは、​`log4j2.xml`​ ファイルでカスタムログファイルパスを指定していない場合、​`MULE_HOME/logs/.log`​ にあります。 Studio では、ログはコンソールに表示されます。 次の例では、メッセージをブラウザーの \[Set Payload (ペイロードを設定)\] に表示すると同時に、メッセージをログにも記録します。 ![logger flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/logger-flow.png) 例: フローの XML 設定 ```xml ``` ## [](#logger-の設定)Logger の設定 ![logger](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/logger.png)
項目 値 説明 例

Message (メッセージ)

String (文字列) または DataWeave 式

Mule のログメッセージを指定します。デフォルトで、メッセージはアプリケーションのログファイルに記録されます。

message="Current payload is #[payload]"​

レベル

選択可能なオプション:

  • DEBUG​

  • ERROR​

  • INFO​ (デフォルト)

  • TRACE​

  • WARN

ログレベルを指定します。

level="ERROR"

Category (カテゴリ)

String (文字列)

log4j2.xml​ ファイルに追加するカテゴリ名を指定する省略可能な設定です。カテゴリの用途の例として、カテゴリに基づいてログメッセージをルーティングすることや、カテゴリに基づいてログレベルを設定することが考えられます。

category="MyCustomCategory"
## [](#例)例 次の Logger は、文字列と式を組み合わせて、メッセージの処理状態を監視するように設定されています。 ```xml ``` 次の Logger は、1 つの式と DataWeave の文字列連結を使用して、フローの処理時間を記録するように設定されています。 ```xml ``` ## [](#関連情報)関連情報 [DataWeave の文字列型](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_string) # Logger コンポーネント このコアコンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグするのに役立ちます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。

Logger は、値に文字列と式を組み合わせることができる数少ないコンポーネントの 1 つです。1 つの式で DataWeave 文字列を補間または連結する場合は他の場所で行います。
設定したメッセージはアプリケーションのログファイルに記録されます。このログファイルは、​`log4j2.xml`​ ファイルでカスタムログファイルパスを指定していない場合、​`MULE_HOME/logs/.log`​ にあります。 Studio では、ログはコンソールに表示されます。 次の例では、メッセージをブラウザーの \[Set Payload (ペイロードを設定)\] に表示すると同時に、メッセージをログにも記録します。 ![Anypoint Studio の Error handling が含まれる Mule アプリケーションの Logger コンポーネントプロセスのフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/logger-flow.png) 例: フローの XML 設定 ```xml ``` ## [](#logger-の設定)Logger の設定 ![名前と汎用データが表示されている Logger の \[General (一般)\] 項目](_images/logger.png)
項目 値 説明 例

Message (メッセージ)

String (文字列) または DataWeave 式

Mule のログメッセージを指定します。デフォルトで、メッセージはアプリケーションのログファイルに記録されます。

message="Current payload is #[payload]"​

レベル

選択可能なオプション:

  • DEBUG​

  • ERROR​

  • INFO​ (デフォルト)

  • TRACE​

  • WARN

ログレベルを指定します。

level="ERROR"

Category (カテゴリ)

String (文字列)

log4j2.xml​ ファイルに追加するカテゴリ名を指定する省略可能な設定です。カテゴリの用途の例として、カテゴリに基づいてログメッセージをルーティングすることや、カテゴリに基づいてログレベルを設定することが考えられます。

category="MyCustomCategory"
## [](#例)例 次の Logger は、文字列と式を組み合わせて、メッセージの処理状態を監視するように設定されています。 ```xml ``` 次の Logger は、1 つの式と DataWeave の文字列連結を使用して、フローの処理時間を記録するように設定されています。 ```xml ``` ## [](#関連情報)関連情報 [DataWeave の文字列型](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_string) # Logger コンポーネント このコアコンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグするのに役立ちます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。

Logger は、値に文字列と式を組み合わせることができる数少ないコンポーネントの 1 つです。1 つの式で DataWeave 文字列を補間または連結する場合は他の場所で行います。
設定したメッセージはアプリケーションのログファイルに記録されます。このログファイルは、​`log4j2.xml`​ ファイルでカスタムログファイルパスを指定していない場合、​`MULE_HOME/logs/.log`​ にあります。 Studio では、ログはコンソールに表示されます。 次の例では、メッセージをブラウザーの \[Set Payload (ペイロードを設定)\] に表示すると同時に、メッセージをログにも記録します。 ![Anypoint Studio の Error handling が含まれる Mule アプリケーションの Logger コンポーネントプロセスのフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/logger-flow.png) 例: フローの XML 設定 ```xml ``` ## [](#logger-の設定)Logger の設定 ![名前と汎用データが表示されている Logger の \[General (一般)\] 項目](_images/logger.png)
項目 値 説明 例

Message (メッセージ)

String (文字列) または DataWeave 式

Mule のログメッセージを指定します。デフォルトで、メッセージはアプリケーションのログファイルに記録されます。

message="Current payload is #[payload]"​

レベル

選択可能なオプション:

  • DEBUG​

  • ERROR​

  • INFO​ (デフォルト)

  • TRACE​

  • WARN

ログレベルを指定します。

level="ERROR"

Category (カテゴリ)

String (文字列)

log4j2.xml​ ファイルに追加するカテゴリ名を指定する省略可能な設定です。カテゴリの用途の例として、カテゴリに基づいてログメッセージをルーティングすることや、カテゴリに基づいてログレベルを設定することが考えられます。

category="MyCustomCategory"
## [](#例)例 次の Logger は、文字列と式を組み合わせて、メッセージの処理状態を監視するように設定されています。 ```xml ``` 次の Logger は、1 つの式と DataWeave の文字列連結を使用して、フローの処理時間を記録するように設定されています。 ```xml ``` ## [](#関連情報)関連情報 [DataWeave の文字列型](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_string) # Logger コンポーネント このコアコンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグするのに役立ちます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。

Logger は、値に文字列と式を組み合わせることができる数少ないコンポーネントの 1 つです。1 つの式で DataWeave 文字列を補間または連結する場合は他の場所で行います。
設定したメッセージはアプリケーションのログファイルに記録されます。このログファイルは、​`log4j2.xml`​ ファイルでカスタムログファイルパスを指定していない場合、​`MULE_HOME/logs/.log`​ にあります。 Studio では、ログはコンソールに表示されます。 次の例では、メッセージをブラウザーの \[Set Payload (ペイロードを設定)\] に表示すると同時に、メッセージをログにも記録します。 ![Anypoint Studio の Error handling が含まれる Mule アプリケーションの Logger コンポーネントプロセスのフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/logger-flow.png) 例: フローの XML 設定 ```xml ``` ## [](#logger-の設定)Logger の設定 ![名前と汎用データが表示されている Logger の \[General (一般)\] 項目](_images/logger.png)
項目 値 説明 例

Message (メッセージ)

String (文字列) または DataWeave 式

Mule のログメッセージを指定します。デフォルトで、メッセージはアプリケーションのログファイルに記録されます。

message="Current payload is #[payload]"​

レベル

選択可能なオプション:

  • DEBUG​

  • ERROR​

  • INFO​ (デフォルト)

  • TRACE​

  • WARN

ログレベルを指定します。

level="ERROR"

Category (カテゴリ)

String (文字列)

log4j2.xml​ ファイルに追加するカテゴリ名を指定する省略可能な設定です。カテゴリの用途の例として、カテゴリに基づいてログメッセージをルーティングすることや、カテゴリに基づいてログレベルを設定することが考えられます。

category="MyCustomCategory"
## [](#例)例 次の Logger は、文字列と式を組み合わせて、メッセージの処理状態を監視するように設定されています。 ```xml ``` 次の Logger は、1 つの式と DataWeave の文字列連結を使用して、フローの処理時間を記録するように設定されています。 ```xml ``` ## [](#関連情報)関連情報 [DataWeave の文字列型](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_string) # Maven リファレンス Unresolved include directive in modules/ROOT/pages/maven-reference.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] このページでは、Mule で Maven を使用する場合の作業に役立つ参照情報がまとめられています。概要については、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.3/using-maven-with-mule)​を参照してください。 ## [](#pom-xml-ファイル)pom.xml ファイル ```xml /pom.xml ``` アプリケーションについて記述する Maven プロジェクトの設定を定義するプロジェクトオブジェクトモデルファイル。これには、ビルドプラグインの設定など、アプリケーションをビルドするために必要なすべての設定が含まれます。​`pom.xml`​ はプロジェクトごとに存在し、プロジェクトと共に配布されます。 ## [](#settings-xml-ファイル)settings.xml ファイル ```xml /settings.xml /.m2/settings.xml ``` Maven インストールのグローバル設定が含まれます。プロジェクトの ​`pom.xml`​ とは異なり、これはシステム全体の設定を定義するものであり、認証ログイン情報などの機密情報を含む可能性があるためプロジェクトと共に配布されません。 `settings.xml`​ ファイルは次の 2 つの場所に存在できます。 - システム全体の設定のフォルダー: この場合は、ユーザーに関係なく、システム上のすべての Maven インストールの設定を定義する​_グローバル_​な ​`settings.xml`​ ファイルになります。例: /etc/maven2/settings.xml - ユーザー固有の設定のフォルダー: この場合は、特定のユーザーの Maven インストールのみに関連する​_ユーザー_​の ​`settings.xml`​ ファイルになります。デフォルトの場所はユーザーのホームディレクトリ内の ​`.m2`​ ディレクトリです。 /home/joe/.m2/settings.xml グローバルとユーザーの両方の ​`settings.xml`​ ファイルが含まれるシステムでは、両方のファイルの設定がマージされます。重複する設定がある場合、ユーザーの設定がグローバル設定よりも優先されます。 ## [](#configure-mule-repositories)MuleSoft リポジトリ Anypoint Studio で新しい Mule プロジェクトを作成すると、必要な MuleSoft リポジトリがプロジェクトに自動的に追加されます。Studio 外で Mule プロジェクトを作成する場合は、リポジトリを手動で ​`pom.xml`​ ファイルに追加して、Enterprise リポジトリにアクセスするための Maven のログイン情報を設定する必要があります。 ### [](#mulesoft-の公開リポジトリの設定)MuleSoft の公開リポジトリの設定 MuleSoft の公開リポジトリを設定するには、プロジェクトの ​`pom.xml`​ ファイルに以下を追加します。 ```xml anypoint-exchange Anypoint Exchange https://maven.anypoint.mulesoft.com/api/v3/maven default mulesoft-releases MuleSoft Releases Repository https://repository.mulesoft.org/releases/ default mulesoft-public MuleSoft Public Repository https://repository.mulesoft.org/nexus/content/repositories/public/ default mulesoft-releases MuleSoft Releases Repository default https://repository.mulesoft.org/releases/ false ``` ### [](#mulesoft-enterprise-リポジトリの設定)MuleSoft Enterprise リポジトリの設定 プロジェクトから Enterprise リポジトリにアクセスできるようにするには、Enterprise ライセンスを入手してインストールし、リポジトリへのアクセスを取得して、プロジェクト内でリポジトリを設定する必要があります。 #### [](#enterprise-ライセンスの入手とインストール)Enterprise ライセンスの入手とインストール Enterprise ライセンスの入手とインストールの手順は、​[「Enterprise ライセンスのインストール」](https://docs.mulesoft.com/jp/mule-runtime/4.3/installing-an-enterprise-license)​を参照してください。 #### [](#enterprise-リポジトリへのアクセスの取得)Enterprise リポジトリへのアクセスの取得 MuleSoft ユーザーであり、 [MuleSoft Enterprise リポジトリ](https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/)​にアクセスするためのログイン情報を持っていない場合は、サポートに連絡して、Nexus Enterprise ログイン情報を要求してください。 #### [](#mulesoft-enterprise-リポジトリにアクセスするための-maven-の設定)MuleSoft Enterprise リポジトリにアクセスするための Maven の設定 MuleSoft Enterprise リポジトリにアクセスできるように Maven を設定する手順は次のとおりです。 1. `/.m2/settings.xml`​ に移動します。 2. アクセスが必要なすべてのワークステーションで ​`settings.xml`​ を開きます。​`settings.xml`​ ファイルが存在しない場合は作成してください。 `settings.xml`​ ファイルの詳細は、 [Maven ドキュメント](http://maven.apache.org/settings.html)​を参照してください。 3. 各 ​`settings.xml`​ ファイルの ​`servers`​ セクションに次の構文を追加します。 ```xml ... MuleRepository YOUR_ID YOUR_PASSWORD ... ``` 4. 各 ​`settings.xml`​ ファイルの ​`profile`​ セクションに次の構文を追加します。 ```xml ... Mule true MuleRepository MuleRepository https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/ default true true ... ``` ## [](#便利なコマンド)便利なコマンド 次のコマンドを使用して、Maven インストールに関する情報を取得し、プロジェクト関連のタスクを実行できます。 ### [](#maven-バイナリと他のファイルを見つける-unix)Maven バイナリと他のファイルを見つける (Unix) whereis mvn ### [](#グローバル設定ファイルなどの-maven-ファイルを見つける-unix)グローバル設定ファイルなどの Maven ファイルを見つける (Unix) locate maven ### [](#maven-バージョンを取得する)Maven バージョンを取得する mvn --version Java ホームディレクトリ、ロケール、プロセッサーアーキテクチャなど、他の情報も提供されます。 ### [](#maven-コマンドとオプションのリストを取得する)Maven コマンドとオプションのリストを取得する mvn -h ### [](#maven-のマニュアルページを確認する-unix)Maven のマニュアルページを確認する (Unix) man mvn ### [](#プロジェクトを作成する)プロジェクトを作成する mvn archetype:generate -DgroupId=com.company.app -DartifactId=myapp -DarchetypeArtifactId=myarchetypeid -DinteractiveMode=false ### [](#プロジェクトをビルドする)プロジェクトをビルドする mvn package ### [](#プロジェクトをクリーンアップする)プロジェクトをクリーンアップする mvn clean ### [](#サイトを生成する)サイトを生成する mvn site ### [](#アーティファクトに含まれる-jar-ファイルのリストを取得する)アーティファクトに含まれる JAR ファイルのリストを取得する mvn dependency:build-classpath ### [](#アーティファクトの連動関係ツリーを取得する)アーティファクトの連動関係ツリーを取得する mvn dependency:tree ## [](#maven-中央リポジトリへの-mule-アーティファクトのデプロイ)Maven 中央リポジトリへの Mule アーティファクトのデプロイ 中央リポジトリを使用すると、アプリケーションをビルドするときのユーザーの時間を節約できます。中央リポジトリにデプロイするには、Mule ​`POM`​ ファイルと ​`JAR`​ アーティファクトを目的のリポジトリにデプロイする必要があります。 デプロイプラグインは、主にデプロイフェーズ中に、他の開発者やプロジェクトと共有するアーティファクトをリモートリポジトリに追加するために使用されます。 ### [](#pom-xml-のデプロイ)pom.xml のデプロイ `pom.xml`​ をリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${project.groupId} -DartifactId=${project.artifactId} -Dversion=${version} -Dpackaging=pom -Dfile=${localPom.canonicalPath} -Durl=http:///nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​``​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 ### [](#jar-ファイルのデプロイ)JAR ファイルのデプロイ `JAR`​ ファイルをリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${pomProps.groupId} -DartifactId=${pomProps.artifactId} -Dversion=${pomProps.version} -Dpackaging=jar -Dfile=${f.canonicalPath} -DpomFile=${localPom.canonicalPath} -Durl=http://${your_repository_ip}/nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​`your_repository_ip`​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 `JAR`​ ファイルをローカルにインストールし、そのファイルをリモートにもデプロイする場合、両方の場所を引数定義で保持することができます。 ## [](#外部リソース)外部リソース - [Apache Maven ホームページ](https://maven.apache.org/index.html) - [Maven 使用開始ガイド](https://maven.apache.org/guides/getting-started/index.html) - [Maven デプロイプラグインリファレンス](https://maven.apache.org/plugins/maven-deploy-plugin) - [POM リファレンス](https://maven.apache.org/pom.html) - [設定リファレンス](https://maven.apache.org/settings.html) # Maven リファレンス Unresolved include directive in modules/ROOT/pages/maven-reference.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] このページでは、Mule で Maven を使用する場合の作業に役立つ参照情報がまとめられています。概要については、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.4/using-maven-with-mule)​を参照してください。 ## [](#pom-xml-ファイル)pom.xml ファイル ```xml /pom.xml ``` アプリケーションについて記述する Maven プロジェクトの設定を定義するプロジェクトオブジェクトモデルファイル。これには、ビルドプラグインの設定など、アプリケーションをビルドするために必要なすべての設定が含まれます。​`pom.xml`​ はプロジェクトごとに存在し、プロジェクトと共に配布されます。 ## [](#settings-xml-ファイル)settings.xml ファイル ```xml /settings.xml /.m2/settings.xml ``` Maven インストールのグローバル設定が含まれます。プロジェクトの ​`pom.xml`​ とは異なり、これはシステム全体の設定を定義するものであり、認証ログイン情報などの機密情報を含む可能性があるためプロジェクトと共に配布されません。 `settings.xml`​ ファイルは次の 2 つの場所に存在できます。 - システム全体の設定のフォルダー: この場合は、ユーザーに関係なく、システム上のすべての Maven インストールの設定を定義する​_グローバル_​な ​`settings.xml`​ ファイルになります。例: /etc/maven2/settings.xml - ユーザー固有の設定のフォルダー: この場合は、特定のユーザーの Maven インストールのみに関連する​_ユーザー_​の ​`settings.xml`​ ファイルになります。デフォルトの場所はユーザーのホームディレクトリ内の ​`.m2`​ ディレクトリです。 /home/joe/.m2/settings.xml グローバルとユーザーの両方の ​`settings.xml`​ ファイルが含まれるシステムでは、両方のファイルの設定がマージされます。重複する設定がある場合、ユーザーの設定がグローバル設定よりも優先されます。 ## [](#configure-mule-repositories)MuleSoft リポジトリ Anypoint Studio で新しい Mule プロジェクトを作成すると、必要な MuleSoft リポジトリがプロジェクトに自動的に追加されます。Studio 外で Mule プロジェクトを作成する場合は、リポジトリを手動で ​`pom.xml`​ ファイルに追加して、Enterprise リポジトリにアクセスするための Maven のログイン情報を設定する必要があります。 ### [](#mulesoft-の公開リポジトリの設定)MuleSoft の公開リポジトリの設定 MuleSoft の公開リポジトリを設定するには、プロジェクトの ​`pom.xml`​ ファイルに以下を追加します。 ```xml anypoint-exchange Anypoint Exchange https://maven.anypoint.mulesoft.com/api/v3/maven default mulesoft-releases MuleSoft Releases Repository https://repository.mulesoft.org/releases/ default mulesoft-public MuleSoft Public Repository https://repository.mulesoft.org/nexus/content/repositories/public/ default mulesoft-releases MuleSoft Releases Repository default https://repository.mulesoft.org/releases/ false ``` ### [](#mulesoft-enterprise-リポジトリの設定)MuleSoft Enterprise リポジトリの設定 プロジェクトから Enterprise リポジトリにアクセスできるようにするには、Enterprise ライセンスを入手してインストールし、リポジトリへのアクセスを取得して、プロジェクト内でリポジトリを設定する必要があります。 #### [](#enterprise-ライセンスの入手とインストール)Enterprise ライセンスの入手とインストール Enterprise ライセンスの入手とインストールの手順は、​[「Enterprise ライセンスのインストール」](https://docs.mulesoft.com/jp/mule-runtime/4.4/installing-an-enterprise-license)​を参照してください。 #### [](#enterprise-リポジトリへのアクセスの取得)Enterprise リポジトリへのアクセスの取得 MuleSoft ユーザーであり、 [MuleSoft Enterprise リポジトリ](https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/)​にアクセスするためのログイン情報を持っていない場合は、サポートに連絡して、Nexus Enterprise ログイン情報を要求してください。 #### [](#mulesoft-enterprise-リポジトリにアクセスするための-maven-の設定)MuleSoft Enterprise リポジトリにアクセスするための Maven の設定 MuleSoft Enterprise リポジトリにアクセスできるように Maven を設定する手順は次のとおりです。 1. `/.m2/settings.xml`​ に移動します。 2. アクセスが必要なすべてのワークステーションで ​`settings.xml`​ を開きます。​`settings.xml`​ ファイルが存在しない場合は作成してください。 `settings.xml`​ ファイルの詳細は、 [Maven ドキュメント](http://maven.apache.org/settings.html)​を参照してください。 3. 各 ​`settings.xml`​ ファイルの ​`servers`​ セクションに次の構文を追加します。 ```xml ... MuleRepository YOUR_ID YOUR_PASSWORD ... ``` 4. 各 ​`settings.xml`​ ファイルの ​`profile`​ セクションに次の構文を追加します。 ```xml ... Mule true MuleRepository MuleRepository https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/ default true true ... ``` ## [](#便利なコマンド)便利なコマンド 次のコマンドを使用して、Maven インストールに関する情報を取得し、プロジェクト関連のタスクを実行できます。 ### [](#maven-バイナリと他のファイルを見つける-unix)Maven バイナリと他のファイルを見つける (Unix) whereis mvn ### [](#グローバル設定ファイルなどの-maven-ファイルを見つける-unix)グローバル設定ファイルなどの Maven ファイルを見つける (Unix) locate maven ### [](#maven-バージョンを取得する)Maven バージョンを取得する mvn --version Java ホームディレクトリ、ロケール、プロセッサーアーキテクチャなど、他の情報も提供されます。 ### [](#maven-コマンドとオプションのリストを取得する)Maven コマンドとオプションのリストを取得する mvn -h ### [](#maven-のマニュアルページを確認する-unix)Maven のマニュアルページを確認する (Unix) man mvn ### [](#プロジェクトを作成する)プロジェクトを作成する mvn archetype:generate -DgroupId=com.company.app -DartifactId=myapp -DarchetypeArtifactId=myarchetypeid -DinteractiveMode=false ### [](#プロジェクトをビルドする)プロジェクトをビルドする mvn package ### [](#プロジェクトをクリーンアップする)プロジェクトをクリーンアップする mvn clean ### [](#サイトを生成する)サイトを生成する mvn site ### [](#アーティファクトに含まれる-jar-ファイルのリストを取得する)アーティファクトに含まれる JAR ファイルのリストを取得する mvn dependency:build-classpath ### [](#アーティファクトの連動関係ツリーを取得する)アーティファクトの連動関係ツリーを取得する mvn dependency:tree ## [](#maven-中央リポジトリへの-mule-アーティファクトのデプロイ)Maven 中央リポジトリへの Mule アーティファクトのデプロイ 中央リポジトリを使用すると、アプリケーションをビルドするときのユーザーの時間を節約できます。中央リポジトリにデプロイするには、Mule ​`POM`​ ファイルと ​`JAR`​ アーティファクトを目的のリポジトリにデプロイする必要があります。 デプロイプラグインは、主にデプロイフェーズ中に、他の開発者やプロジェクトと共有するアーティファクトをリモートリポジトリに追加するために使用されます。 ### [](#pom-xml-のデプロイ)pom.xml のデプロイ `pom.xml`​ をリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${project.groupId} -DartifactId=${project.artifactId} -Dversion=${version} -Dpackaging=pom -Dfile=${localPom.canonicalPath} -Durl=http:///nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​``​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 ### [](#jar-ファイルのデプロイ)JAR ファイルのデプロイ `JAR`​ ファイルをリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${pomProps.groupId} -DartifactId=${pomProps.artifactId} -Dversion=${pomProps.version} -Dpackaging=jar -Dfile=${f.canonicalPath} -DpomFile=${localPom.canonicalPath} -Durl=http://${your_repository_ip}/nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​`your_repository_ip`​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 `JAR`​ ファイルをローカルにインストールし、そのファイルをリモートにもデプロイする場合、両方の場所を引数定義で保持することができます。 ## [](#外部リソース)外部リソース - [Apache Maven ホームページ](https://maven.apache.org/index.html) - [Maven 使用開始ガイド](https://maven.apache.org/guides/getting-started/index.html) - [Maven デプロイプラグインリファレンス](https://maven.apache.org/plugins/maven-deploy-plugin) - [POM リファレンス](https://maven.apache.org/pom.html) - [設定リファレンス](https://maven.apache.org/settings.html) # Maven リファレンス Unresolved include directive in modules/ROOT/pages/maven-reference.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] このページでは、Mule で Maven を使用する場合の作業に役立つ参照情報がまとめられています。概要については、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.5/using-maven-with-mule)​を参照してください。 ## [](#pom-xml-ファイル)pom.xml ファイル ```xml /pom.xml ``` アプリケーションについて記述する Maven プロジェクトの設定を定義するプロジェクトオブジェクトモデルファイル。これには、ビルドプラグインの設定など、アプリケーションをビルドするために必要なすべての設定が含まれます。​`pom.xml`​ はプロジェクトごとに存在し、プロジェクトと共に配布されます。 ## [](#settings-xml-ファイル)settings.xml ファイル ```xml /settings.xml /.m2/settings.xml ``` Maven インストールのグローバル設定が含まれます。プロジェクトの ​`pom.xml`​ とは異なり、これはシステム全体の設定を定義するものであり、認証ログイン情報などの機密情報を含む可能性があるためプロジェクトと共に配布されません。 `settings.xml`​ ファイルは次の 2 つの場所に存在できます。 - システム全体の設定のフォルダー: この場合は、ユーザーに関係なく、システム上のすべての Maven インストールの設定を定義する​_グローバル_​な ​`settings.xml`​ ファイルになります。次に例を示します。 /etc/maven2/settings.xml - ユーザー固有の設定のフォルダー: この場合は、特定のユーザーの Maven インストールのみに関連する​_ユーザー_​の ​`settings.xml`​ ファイルになります。デフォルトの場所はユーザーのホームディレクトリ内の ​`.m2`​ ディレクトリです。 /home/joe/.m2/settings.xml グローバルとユーザーの両方の ​`settings.xml`​ ファイルが含まれるシステムでは、両方のファイルの設定がマージされます。重複する設定がある場合、ユーザーの設定がグローバル設定よりも優先されます。 ## [](#configure-mule-repositories)MuleSoft リポジトリ Anypoint Studio で新しい Mule プロジェクトを作成すると、必要な MuleSoft リポジトリがプロジェクトに自動的に追加されます。Studio 外で Mule プロジェクトを作成する場合は、リポジトリを手動で ​`pom.xml`​ ファイルに追加して、Enterprise リポジトリにアクセスするための Maven のログイン情報を設定する必要があります。 ### [](#mulesoft-の公開リポジトリの設定)MuleSoft の公開リポジトリの設定 MuleSoft の公開リポジトリを設定するには、プロジェクトの ​`pom.xml`​ ファイルに以下を追加します。 ```xml anypoint-exchange Anypoint Exchange https://maven.anypoint.mulesoft.com/api/v3/maven default mulesoft-releases MuleSoft Releases Repository https://repository.mulesoft.org/releases/ default mulesoft-public MuleSoft Public Repository https://repository.mulesoft.org/nexus/content/repositories/public/ default mulesoft-releases MuleSoft Releases Repository default https://repository.mulesoft.org/releases/ false ``` ### [](#mulesoft-enterprise-リポジトリの設定)MuleSoft Enterprise リポジトリの設定 プロジェクトから Enterprise リポジトリにアクセスできるようにするには、Enterprise ライセンスを入手してインストールし、リポジトリへのアクセスを取得して、プロジェクト内でリポジトリを設定する必要があります。 #### [](#enterprise-ライセンスの入手とインストール)Enterprise ライセンスの入手とインストール Enterprise ライセンスの入手とインストールの手順は、​[「Enterprise ライセンスのインストール」](https://docs.mulesoft.com/jp/mule-runtime/4.5/installing-an-enterprise-license)​を参照してください。 #### [](#enterprise-リポジトリへのアクセスの取得)Enterprise リポジトリへのアクセスの取得 MuleSoft ユーザーであり、 [MuleSoft Enterprise リポジトリ](https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/)​にアクセスするためのログイン情報を持っていない場合は、サポートに連絡して、Nexus Enterprise ログイン情報を要求してください。 #### [](#mulesoft-enterprise-リポジトリにアクセスするための-maven-の設定)MuleSoft Enterprise リポジトリにアクセスするための Maven の設定 MuleSoft Enterprise リポジトリにアクセスできるように Maven を設定する手順は次のとおりです。 1. `/.m2/settings.xml`​ に移動します。 2. アクセスが必要なすべてのワークステーションで ​`settings.xml`​ を開きます。​`settings.xml`​ ファイルが存在しない場合は作成してください。 `settings.xml`​ ファイルの詳細は、 [Maven ドキュメント](http://maven.apache.org/settings.html)​を参照してください。 3. 各 ​`settings.xml`​ ファイルの ​`servers`​ セクションに次の構文を追加します。 ```xml ... MuleRepository YOUR_ID YOUR_PASSWORD ... ``` 4. 各 ​`settings.xml`​ ファイルの ​`profile`​ セクションに次の構文を追加します。 ```xml ... Mule true MuleRepository MuleRepository https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/ default true true ... ``` ## [](#便利なコマンド)便利なコマンド 次のコマンドを使用して、Maven インストールに関する情報を取得し、プロジェクト関連のタスクを実行できます。 ### [](#maven-バイナリと他のファイルを見つける-unix)Maven バイナリと他のファイルを見つける (Unix) whereis mvn ### [](#グローバル設定ファイルなどの-maven-ファイルを見つける-unix)グローバル設定ファイルなどの Maven ファイルを見つける (Unix) locate maven ### [](#maven-バージョンを取得する)Maven バージョンを取得する mvn --version Java ホームディレクトリ、ロケール、プロセッサーアーキテクチャなど、他の情報も提供されます。 ### [](#maven-コマンドとオプションのリストを取得する)Maven コマンドとオプションのリストを取得する mvn -h ### [](#maven-のマニュアルページを確認する-unix)Maven のマニュアルページを確認する (Unix) man mvn ### [](#プロジェクトを作成する)プロジェクトを作成する mvn archetype:generate -DgroupId=com.company.app -DartifactId=myapp -DarchetypeArtifactId=myarchetypeid -DinteractiveMode=false ### [](#プロジェクトをビルドする)プロジェクトをビルドする mvn package ### [](#プロジェクトをクリーンアップする)プロジェクトをクリーンアップする mvn clean ### [](#サイトを生成する)サイトを生成する mvn site ### [](#アーティファクトに含まれる-jar-ファイルのリストを取得する)アーティファクトに含まれる JAR ファイルのリストを取得する mvn dependency:build-classpath ### [](#アーティファクトの連動関係ツリーを取得する)アーティファクトの連動関係ツリーを取得する mvn dependency:tree ## [](#maven-中央リポジトリへの-mule-アーティファクトのデプロイ)Maven 中央リポジトリへの Mule アーティファクトのデプロイ 中央リポジトリを使用すると、アプリケーションをビルドするときのユーザーの時間を節約できます。中央リポジトリにデプロイするには、Mule ​`POM`​ ファイルと ​`JAR`​ アーティファクトを目的のリポジトリにデプロイする必要があります。 デプロイプラグインは、主にデプロイフェーズ中に、他の開発者やプロジェクトと共有するアーティファクトをリモートリポジトリに追加するために使用されます。 ### [](#pom-xml-のデプロイ)pom.xml のデプロイ `pom.xml`​ をリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${project.groupId} -DartifactId=${project.artifactId} -Dversion=${version} -Dpackaging=pom -Dfile=${localPom.canonicalPath} -Durl=http:///nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​``​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 ### [](#jar-ファイルのデプロイ)JAR ファイルのデプロイ `JAR`​ ファイルをリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${pomProps.groupId} -DartifactId=${pomProps.artifactId} -Dversion=${pomProps.version} -Dpackaging=jar -Dfile=${f.canonicalPath} -DpomFile=${localPom.canonicalPath} -Durl=http://${your_repository_ip}/nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​`your_repository_ip`​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 `JAR`​ ファイルをローカルにインストールし、そのファイルをリモートにもデプロイする場合、両方の場所を引数定義で保持することができます。 ## [](#外部リソース)外部リソース - [Apache Maven ホームページ](https://maven.apache.org/index.html) - [Maven 使用開始ガイド](https://maven.apache.org/guides/getting-started/index.html) - [Maven デプロイプラグインリファレンス](https://maven.apache.org/plugins/maven-deploy-plugin) - [POM リファレンス](https://maven.apache.org/pom.html) - [設定リファレンス](https://maven.apache.org/settings.html) # Maven リファレンス Unresolved include directive in modules/ROOT/pages/maven-reference.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] このページでは、Mule で Maven を使用する場合の作業に役立つ参照情報がまとめられています。概要については、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.6/using-maven-with-mule)​を参照してください。 ## [](#pom-xml-ファイル)pom.xml ファイル ```xml /pom.xml ``` アプリケーションについて記述する Maven プロジェクトの設定を定義するプロジェクトオブジェクトモデルファイル。これには、ビルドプラグインの設定など、アプリケーションをビルドするために必要なすべての設定が含まれます。​`pom.xml`​ はプロジェクトごとに存在し、プロジェクトと共に配布されます。 ## [](#settings-xml-ファイル)settings.xml ファイル ```xml /settings.xml /.m2/settings.xml ``` Maven インストールのグローバル設定が含まれます。プロジェクトの ​`pom.xml`​ とは異なり、これはシステム全体の設定を定義するものであり、認証ログイン情報などの機密情報を含む可能性があるためプロジェクトと共に配布されません。 `settings.xml`​ ファイルは次の 2 つの場所に存在できます。 - システム全体の設定のフォルダー: この場合は、ユーザーに関係なく、システム上のすべての Maven インストールの設定を定義する​_グローバル_​な ​`settings.xml`​ ファイルになります。例: /etc/maven2/settings.xml - ユーザー固有の設定のフォルダー: この場合は、特定のユーザーの Maven インストールのみに関連する​_ユーザー_​の ​`settings.xml`​ ファイルになります。デフォルトの場所はユーザーのホームディレクトリ内の ​`.m2`​ ディレクトリです。 /home/joe/.m2/settings.xml グローバルとユーザーの両方の ​`settings.xml`​ ファイルが含まれるシステムでは、両方のファイルの設定がマージされます。重複する設定がある場合、ユーザーの設定がグローバル設定よりも優先されます。 ## [](#configure-mule-repositories)MuleSoft リポジトリ Anypoint Studio で新しい Mule プロジェクトを作成すると、必要な MuleSoft リポジトリがプロジェクトに自動的に追加されます。Studio 外で Mule プロジェクトを作成する場合は、リポジトリを手動で ​`pom.xml`​ ファイルに追加して、Enterprise リポジトリにアクセスするための Maven のログイン情報を設定する必要があります。 ### [](#mulesoft-の公開リポジトリの設定)MuleSoft の公開リポジトリの設定 MuleSoft の公開リポジトリを設定するには、プロジェクトの ​`pom.xml`​ ファイルに以下を追加します。 ```xml anypoint-exchange Anypoint Exchange https://maven.anypoint.mulesoft.com/api/v3/maven default mulesoft-releases MuleSoft Releases Repository https://repository.mulesoft.org/releases/ default mulesoft-public MuleSoft Public Repository https://repository.mulesoft.org/nexus/content/repositories/public/ default mulesoft-releases MuleSoft Releases Repository default https://repository.mulesoft.org/releases/ false ``` ### [](#mulesoft-enterprise-リポジトリの設定)MuleSoft Enterprise リポジトリの設定 プロジェクトから Enterprise リポジトリにアクセスできるようにするには、Enterprise ライセンスを入手してインストールし、リポジトリへのアクセスを取得して、プロジェクト内でリポジトリを設定する必要があります。 #### [](#enterprise-ライセンスの入手とインストール)Enterprise ライセンスの入手とインストール Enterprise ライセンスの入手とインストールの手順は、​[「Enterprise ライセンスのインストール」](https://docs.mulesoft.com/jp/mule-runtime/4.6/installing-an-enterprise-license)​を参照してください。 #### [](#enterprise-リポジトリへのアクセスの取得)Enterprise リポジトリへのアクセスの取得 MuleSoft ユーザーであり、 [MuleSoft Enterprise リポジトリ](https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/)​にアクセスするためのログイン情報を持っていない場合は、サポートに連絡して、Nexus Enterprise ログイン情報を要求してください。 #### [](#mulesoft-enterprise-リポジトリにアクセスするための-maven-の設定)MuleSoft Enterprise リポジトリにアクセスするための Maven の設定 MuleSoft Enterprise リポジトリにアクセスできるように Maven を設定する手順は次のとおりです。 1. `/.m2/settings.xml`​ に移動します。 2. アクセスが必要なすべてのワークステーションで ​`settings.xml`​ を開きます。​`settings.xml`​ ファイルが存在しない場合は作成してください。 `settings.xml`​ ファイルの詳細は、 [Maven ドキュメント](http://maven.apache.org/settings.html)​を参照してください。 3. 各 ​`settings.xml`​ ファイルの ​`servers`​ セクションに次の構文を追加します。 ```xml ... MuleRepository YOUR_ID YOUR_PASSWORD ... ``` 4. 各 ​`settings.xml`​ ファイルの ​`profile`​ セクションに次の構文を追加します。 ```xml ... Mule true MuleRepository MuleRepository https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/ default true true ... ``` ## [](#便利なコマンド)便利なコマンド 次のコマンドを使用して、Maven インストールに関する情報を取得し、プロジェクト関連のタスクを実行できます。 ### [](#maven-バイナリと他のファイルを見つける-unix)Maven バイナリと他のファイルを見つける (Unix) whereis mvn ### [](#グローバル設定ファイルなどの-maven-ファイルを見つける-unix)グローバル設定ファイルなどの Maven ファイルを見つける (Unix) locate maven ### [](#maven-バージョンを取得する)Maven バージョンを取得する mvn --version Java ホームディレクトリ、ロケール、プロセッサーアーキテクチャなど、他の情報も提供されます。 ### [](#maven-コマンドとオプションのリストを取得する)Maven コマンドとオプションのリストを取得する mvn -h ### [](#maven-のマニュアルページを確認する-unix)Maven のマニュアルページを確認する (Unix) man mvn ### [](#プロジェクトを作成する)プロジェクトを作成する mvn archetype:generate -DgroupId=com.company.app -DartifactId=myapp -DarchetypeArtifactId=myarchetypeid -DinteractiveMode=false ### [](#プロジェクトをビルドする)プロジェクトをビルドする mvn package ### [](#プロジェクトをクリーンアップする)プロジェクトをクリーンアップする mvn clean ### [](#サイトを生成する)サイトを生成する mvn site ### [](#アーティファクトに含まれる-jar-ファイルのリストを取得する)アーティファクトに含まれる JAR ファイルのリストを取得する mvn dependency:build-classpath ### [](#アーティファクトの連動関係ツリーを取得する)アーティファクトの連動関係ツリーを取得する mvn dependency:tree ## [](#maven-中央リポジトリへの-mule-アーティファクトのデプロイ)Maven 中央リポジトリへの Mule アーティファクトのデプロイ 中央リポジトリを使用すると、アプリケーションをビルドするときのユーザーの時間を節約できます。中央リポジトリにデプロイするには、Mule ​`POM`​ ファイルと ​`JAR`​ アーティファクトを目的のリポジトリにデプロイする必要があります。 デプロイプラグインは、主にデプロイフェーズ中に、他の開発者やプロジェクトと共有するアーティファクトをリモートリポジトリに追加するために使用されます。 ### [](#pom-xml-のデプロイ)pom.xml のデプロイ `pom.xml`​ をリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${project.groupId} -DartifactId=${project.artifactId} -Dversion=${version} -Dpackaging=pom -Dfile=${localPom.canonicalPath} -Durl=http:///nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​``​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 ### [](#jar-ファイルのデプロイ)JAR ファイルのデプロイ `JAR`​ ファイルをリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${pomProps.groupId} -DartifactId=${pomProps.artifactId} -Dversion=${pomProps.version} -Dpackaging=jar -Dfile=${f.canonicalPath} -DpomFile=${localPom.canonicalPath} -Durl=http://${your_repository_ip}/nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​`your_repository_ip`​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 `JAR`​ ファイルをローカルにインストールし、そのファイルをリモートにもデプロイする場合、両方の場所を引数定義で保持することができます。 ## [](#外部リソース)外部リソース - [Apache Maven ホームページ](https://maven.apache.org/index.html) - [Maven 使用開始ガイド](https://maven.apache.org/guides/getting-started/index.html) - [Maven デプロイプラグインリファレンス](https://maven.apache.org/plugins/maven-deploy-plugin) - [POM リファレンス](https://maven.apache.org/pom.html) - [設定リファレンス](https://maven.apache.org/settings.html) # Maven リファレンス Unresolved include directive in modules/ROOT/pages/maven-reference.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] このページでは、Mule で Maven を使用する場合の作業に役立つ参照情報がまとめられています。概要については、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.7/using-maven-with-mule)​を参照してください。 ## [](#pom-xml-ファイル)pom.xml ファイル ```xml /pom.xml ``` アプリケーションについて記述する Maven プロジェクトの設定を定義するプロジェクトオブジェクトモデルファイル。これには、ビルドプラグインの設定など、アプリケーションをビルドするために必要なすべての設定が含まれます。​`pom.xml`​ はプロジェクトごとに存在し、プロジェクトと共に配布されます。 ## [](#settings-xml-ファイル)settings.xml ファイル ```xml /settings.xml /.m2/settings.xml ``` Maven インストールのグローバル設定が含まれます。プロジェクトの ​`pom.xml`​ とは異なり、これはシステム全体の設定を定義するものであり、認証ログイン情報などの機密情報を含む可能性があるためプロジェクトと共に配布されません。 `settings.xml`​ ファイルは次の 2 つの場所に存在できます。 - システム全体の設定のフォルダー: この場合は、ユーザーに関係なく、システム上のすべての Maven インストールの設定を定義する​_グローバル_​な ​`settings.xml`​ ファイルになります。例: /etc/maven2/settings.xml - ユーザー固有の設定のフォルダー: この場合は、特定のユーザーの Maven インストールのみに関連する​_ユーザー_​の ​`settings.xml`​ ファイルになります。デフォルトの場所はユーザーのホームディレクトリ内の ​`.m2`​ ディレクトリです。 /home/joe/.m2/settings.xml グローバルとユーザーの両方の ​`settings.xml`​ ファイルが含まれるシステムでは、両方のファイルの設定がマージされます。重複する設定がある場合、ユーザーの設定がグローバル設定よりも優先されます。 ## [](#configure-mule-repositories)MuleSoft リポジトリ Anypoint Studio で新しい Mule プロジェクトを作成すると、必要な MuleSoft リポジトリがプロジェクトに自動的に追加されます。Studio 外で Mule プロジェクトを作成する場合は、リポジトリを手動で ​`pom.xml`​ ファイルに追加して、Enterprise リポジトリにアクセスするための Maven のログイン情報を設定する必要があります。 ### [](#mulesoft-の公開リポジトリの設定)MuleSoft の公開リポジトリの設定 MuleSoft の公開リポジトリを設定するには、プロジェクトの ​`pom.xml`​ ファイルに以下を追加します。 ```xml anypoint-exchange Anypoint Exchange https://maven.anypoint.mulesoft.com/api/v3/maven default mulesoft-releases MuleSoft Releases Repository https://repository.mulesoft.org/releases/ default mulesoft-public MuleSoft Public Repository https://repository.mulesoft.org/nexus/content/repositories/public/ default mulesoft-releases MuleSoft Releases Repository default https://repository.mulesoft.org/releases/ false ``` ### [](#mulesoft-enterprise-リポジトリの設定)MuleSoft Enterprise リポジトリの設定 プロジェクトから Enterprise リポジトリにアクセスできるようにするには、Enterprise ライセンスを入手してインストールし、リポジトリへのアクセスを取得して、プロジェクト内でリポジトリを設定する必要があります。 #### [](#enterprise-ライセンスの入手とインストール)Enterprise ライセンスの入手とインストール Enterprise ライセンスの入手とインストールの手順は、​[「Enterprise ライセンスのインストール」](https://docs.mulesoft.com/jp/mule-runtime/4.7/installing-an-enterprise-license)​を参照してください。 #### [](#enterprise-リポジトリへのアクセスの取得)Enterprise リポジトリへのアクセスの取得 MuleSoft ユーザーであり、 [MuleSoft Enterprise リポジトリ](https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/)​にアクセスするためのログイン情報を持っていない場合は、サポートに連絡して、Nexus Enterprise ログイン情報を要求してください。 #### [](#mulesoft-enterprise-リポジトリにアクセスするための-maven-の設定)MuleSoft Enterprise リポジトリにアクセスするための Maven の設定 MuleSoft Enterprise リポジトリにアクセスできるように Maven を設定する手順は次のとおりです。 1. `/.m2/settings.xml`​ に移動します。 2. アクセスが必要なすべてのワークステーションで ​`settings.xml`​ を開きます。​`settings.xml`​ ファイルが存在しない場合は作成してください。 `settings.xml`​ ファイルの詳細は、 [Maven ドキュメント](http://maven.apache.org/settings.html)​を参照してください。 3. 各 ​`settings.xml`​ ファイルの ​`servers`​ セクションに次の構文を追加します。 ```xml ... MuleRepository YOUR_ID YOUR_PASSWORD ... ``` 4. 各 ​`settings.xml`​ ファイルの ​`profile`​ セクションに次の構文を追加します。 ```xml ... Mule true MuleRepository MuleRepository https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/ default true true ... ``` ## [](#便利なコマンド)便利なコマンド 次のコマンドを使用して、Maven インストールに関する情報を取得し、プロジェクト関連のタスクを実行できます。 ### [](#maven-バイナリと他のファイルを見つける-unix)Maven バイナリと他のファイルを見つける (Unix) whereis mvn ### [](#グローバル設定ファイルなどの-maven-ファイルを見つける-unix)グローバル設定ファイルなどの Maven ファイルを見つける (Unix) locate maven ### [](#maven-バージョンを取得する)Maven バージョンを取得する mvn --version Java ホームディレクトリ、ロケール、プロセッサーアーキテクチャなど、他の情報も提供されます。 ### [](#maven-コマンドとオプションのリストを取得する)Maven コマンドとオプションのリストを取得する mvn -h ### [](#maven-のマニュアルページを確認する-unix)Maven のマニュアルページを確認する (Unix) man mvn ### [](#プロジェクトを作成する)プロジェクトを作成する mvn archetype:generate -DgroupId=com.company.app -DartifactId=myapp -DarchetypeArtifactId=myarchetypeid -DinteractiveMode=false ### [](#プロジェクトをビルドする)プロジェクトをビルドする mvn package ### [](#プロジェクトをクリーンアップする)プロジェクトをクリーンアップする mvn clean ### [](#サイトを生成する)サイトを生成する mvn site ### [](#アーティファクトに含まれる-jar-ファイルのリストを取得する)アーティファクトに含まれる JAR ファイルのリストを取得する mvn dependency:build-classpath ### [](#アーティファクトの連動関係ツリーを取得する)アーティファクトの連動関係ツリーを取得する mvn dependency:tree ## [](#maven-中央リポジトリへの-mule-アーティファクトのデプロイ)Maven 中央リポジトリへの Mule アーティファクトのデプロイ 中央リポジトリを使用すると、アプリケーションをビルドするときのユーザーの時間を節約できます。中央リポジトリにデプロイするには、Mule ​`POM`​ ファイルと ​`JAR`​ アーティファクトを目的のリポジトリにデプロイする必要があります。 デプロイプラグインは、主にデプロイフェーズ中に、他の開発者やプロジェクトと共有するアーティファクトをリモートリポジトリに追加するために使用されます。 ### [](#pom-xml-のデプロイ)pom.xml のデプロイ `pom.xml`​ をリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${project.groupId} -DartifactId=${project.artifactId} -Dversion=${version} -Dpackaging=pom -Dfile=${localPom.canonicalPath} -Durl=http:///nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​``​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 ### [](#jar-ファイルのデプロイ)JAR ファイルのデプロイ `JAR`​ ファイルをリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${pomProps.groupId} -DartifactId=${pomProps.artifactId} -Dversion=${pomProps.version} -Dpackaging=jar -Dfile=${f.canonicalPath} -DpomFile=${localPom.canonicalPath} -Durl=http://${your_repository_ip}/nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​`your_repository_ip`​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 `JAR`​ ファイルをローカルにインストールし、そのファイルをリモートにもデプロイする場合、両方の場所を引数定義で保持することができます。 ## [](#外部リソース)外部リソース - [Apache Maven ホームページ](https://maven.apache.org/index.html) - [Maven 使用開始ガイド](https://maven.apache.org/guides/getting-started/index.html) - [Maven デプロイプラグインリファレンス](https://maven.apache.org/plugins/maven-deploy-plugin) - [POM リファレンス](https://maven.apache.org/pom.html) - [設定リファレンス](https://maven.apache.org/settings.html) # Maven リファレンス Unresolved include directive in modules/ROOT/pages/maven-reference.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] このページでは、Mule で Maven を使用する場合の作業に役立つ参照情報がまとめられています。概要については、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.8/using-maven-with-mule)​を参照してください。 ## [](#pom-xml-ファイル)pom.xml ファイル ```xml /pom.xml ``` アプリケーションについて記述する Maven プロジェクトの設定を定義するプロジェクトオブジェクトモデルファイル。これには、ビルドプラグインの設定など、アプリケーションをビルドするために必要なすべての設定が含まれます。​`pom.xml`​ はプロジェクトごとに存在し、プロジェクトと共に配布されます。 ## [](#settings-xml-ファイル)settings.xml ファイル ```xml /settings.xml /.m2/settings.xml ``` Maven インストールのグローバル設定が含まれます。プロジェクトの ​`pom.xml`​ とは異なり、これはシステム全体の設定を定義するものであり、認証ログイン情報などの機密情報を含む可能性があるためプロジェクトと共に配布されません。 `settings.xml`​ ファイルは次の 2 つの場所に存在できます。 - システム全体の設定のフォルダー: この場合は、ユーザーに関係なく、システム上のすべての Maven インストールの設定を定義する​_グローバル_​な ​`settings.xml`​ ファイルになります。例: /etc/maven2/settings.xml - ユーザー固有の設定のフォルダー: この場合は、特定のユーザーの Maven インストールのみに関連する​_ユーザー_​の ​`settings.xml`​ ファイルになります。デフォルトの場所はユーザーのホームディレクトリ内の ​`.m2`​ ディレクトリです。 /home/joe/.m2/settings.xml グローバルとユーザーの両方の ​`settings.xml`​ ファイルが含まれるシステムでは、両方のファイルの設定がマージされます。重複する設定がある場合、ユーザーの設定がグローバル設定よりも優先されます。 ## [](#configure-mule-repositories)MuleSoft リポジトリ Anypoint Studio で新しい Mule プロジェクトを作成すると、必要な MuleSoft リポジトリがプロジェクトに自動的に追加されます。Studio 外で Mule プロジェクトを作成する場合は、リポジトリを手動で ​`pom.xml`​ ファイルに追加して、Enterprise リポジトリにアクセスするための Maven のログイン情報を設定する必要があります。 ### [](#mulesoft-の公開リポジトリの設定)MuleSoft の公開リポジトリの設定 MuleSoft の公開リポジトリを設定するには、プロジェクトの ​`pom.xml`​ ファイルに以下を追加します。 ```xml anypoint-exchange Anypoint Exchange https://maven.anypoint.mulesoft.com/api/v3/maven default mulesoft-releases MuleSoft Releases Repository https://repository.mulesoft.org/releases/ default mulesoft-public MuleSoft Public Repository https://repository.mulesoft.org/nexus/content/repositories/public/ default mulesoft-releases MuleSoft Releases Repository default https://repository.mulesoft.org/releases/ false ``` ### [](#mulesoft-enterprise-リポジトリの設定)MuleSoft Enterprise リポジトリの設定 プロジェクトから Enterprise リポジトリにアクセスできるようにするには、Enterprise ライセンスを入手してインストールし、リポジトリへのアクセスを取得して、プロジェクト内でリポジトリを設定する必要があります。 #### [](#enterprise-ライセンスの入手とインストール)Enterprise ライセンスの入手とインストール Enterprise ライセンスの入手とインストールの手順は、​[「Enterprise ライセンスのインストール」](https://docs.mulesoft.com/jp/mule-runtime/4.8/installing-an-enterprise-license)​を参照してください。 #### [](#enterprise-リポジトリへのアクセスの取得)Enterprise リポジトリへのアクセスの取得 MuleSoft ユーザーであり、 [MuleSoft Enterprise リポジトリ](https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/)​にアクセスするためのログイン情報を持っていない場合は、サポートに連絡して、Nexus Enterprise ログイン情報を要求してください。 #### [](#mulesoft-enterprise-リポジトリにアクセスするための-maven-の設定)MuleSoft Enterprise リポジトリにアクセスするための Maven の設定 MuleSoft Enterprise リポジトリにアクセスできるように Maven を設定する手順は次のとおりです。 1. `/.m2/settings.xml`​ に移動します。 2. アクセスが必要なすべてのワークステーションで ​`settings.xml`​ を開きます。​`settings.xml`​ ファイルが存在しない場合は作成してください。 `settings.xml`​ ファイルの詳細は、 [Maven ドキュメント](http://maven.apache.org/settings.html)​を参照してください。 3. 各 ​`settings.xml`​ ファイルの ​`servers`​ セクションに次の構文を追加します。 ```xml ... MuleRepository YOUR_ID YOUR_PASSWORD ... ``` 4. 各 ​`settings.xml`​ ファイルの ​`profile`​ セクションに次の構文を追加します。 ```xml ... Mule true MuleRepository MuleRepository https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/ default true true ... ``` ## [](#便利なコマンド)便利なコマンド 次のコマンドを使用して、Maven インストールに関する情報を取得し、プロジェクト関連のタスクを実行できます。 ### [](#maven-バイナリと他のファイルを見つける-unix)Maven バイナリと他のファイルを見つける (Unix) whereis mvn ### [](#グローバル設定ファイルなどの-maven-ファイルを見つける-unix)グローバル設定ファイルなどの Maven ファイルを見つける (Unix) locate maven ### [](#maven-バージョンを取得する)Maven バージョンを取得する mvn --version Java ホームディレクトリ、ロケール、プロセッサーアーキテクチャなど、他の情報も提供されます。 ### [](#maven-コマンドとオプションのリストを取得する)Maven コマンドとオプションのリストを取得する mvn -h ### [](#maven-のマニュアルページを確認する-unix)Maven のマニュアルページを確認する (Unix) man mvn ### [](#プロジェクトを作成する)プロジェクトを作成する mvn archetype:generate -DgroupId=com.company.app -DartifactId=myapp -DarchetypeArtifactId=myarchetypeid -DinteractiveMode=false ### [](#プロジェクトをビルドする)プロジェクトをビルドする mvn package ### [](#プロジェクトをクリーンアップする)プロジェクトをクリーンアップする mvn clean ### [](#サイトを生成する)サイトを生成する mvn site ### [](#アーティファクトに含まれる-jar-ファイルのリストを取得する)アーティファクトに含まれる JAR ファイルのリストを取得する mvn dependency:build-classpath ### [](#アーティファクトの連動関係ツリーを取得する)アーティファクトの連動関係ツリーを取得する mvn dependency:tree ## [](#maven-中央リポジトリへの-mule-アーティファクトのデプロイ)Maven 中央リポジトリへの Mule アーティファクトのデプロイ 中央リポジトリを使用すると、アプリケーションをビルドするときのユーザーの時間を節約できます。中央リポジトリにデプロイするには、Mule ​`POM`​ ファイルと ​`JAR`​ アーティファクトを目的のリポジトリにデプロイする必要があります。 デプロイプラグインは、主にデプロイフェーズ中に、他の開発者やプロジェクトと共有するアーティファクトをリモートリポジトリに追加するために使用されます。 ### [](#pom-xml-のデプロイ)pom.xml のデプロイ `pom.xml`​ をリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${project.groupId} -DartifactId=${project.artifactId} -Dversion=${version} -Dpackaging=pom -Dfile=${localPom.canonicalPath} -Durl=http:///nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​``​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 ### [](#jar-ファイルのデプロイ)JAR ファイルのデプロイ `JAR`​ ファイルをリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${pomProps.groupId} -DartifactId=${pomProps.artifactId} -Dversion=${pomProps.version} -Dpackaging=jar -Dfile=${f.canonicalPath} -DpomFile=${localPom.canonicalPath} -Durl=http://${your_repository_ip}/nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​`your_repository_ip`​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 `JAR`​ ファイルをローカルにインストールし、そのファイルをリモートにもデプロイする場合、両方の場所を引数定義で保持することができます。 ## [](#外部リソース)外部リソース - [Apache Maven ホームページ](https://maven.apache.org/index.html) - [Maven 使用開始ガイド](https://maven.apache.org/guides/getting-started/index.html) - [Maven デプロイプラグインリファレンス](https://maven.apache.org/plugins/maven-deploy-plugin) - [POM リファレンス](https://maven.apache.org/pom.html) - [設定リファレンス](https://maven.apache.org/settings.html) # Maven リファレンス
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
このページでは、Mule で Maven を使用する場合の作業に役立つ参照情報がまとめられています。概要については、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.9/using-maven-with-mule)​を参照してください。 ## [](#pom-xml-ファイル)pom.xml ファイル ```xml /pom.xml ``` アプリケーションについて記述する Maven プロジェクトの設定を定義するプロジェクトオブジェクトモデルファイル。これには、ビルドプラグインの設定など、アプリケーションをビルドするために必要なすべての設定が含まれます。​`pom.xml`​ はプロジェクトごとに存在し、プロジェクトと共に配布されます。 ## [](#settings-xml-ファイル)settings.xml ファイル ```xml /settings.xml /.m2/settings.xml ``` Maven インストールのグローバル設定が含まれます。プロジェクトの ​`pom.xml`​ とは異なり、これはシステム全体の設定を定義するものであり、認証ログイン情報などの機密情報を含む可能性があるためプロジェクトと共に配布されません。 `settings.xml`​ ファイルは次の 2 つの場所に存在できます。 - システム全体の設定のフォルダー: この場合は、ユーザーに関係なく、システム上のすべての Maven インストールの設定を定義する​_グローバル_​な ​`settings.xml`​ ファイルになります。例: /etc/maven2/settings.xml - ユーザー固有の設定のフォルダー: この場合は、特定のユーザーの Maven インストールのみに関連する​_ユーザー_​の ​`settings.xml`​ ファイルになります。デフォルトの場所はユーザーのホームディレクトリ内の ​`.m2`​ ディレクトリです。 /home/joe/.m2/settings.xml グローバルとユーザーの両方の ​`settings.xml`​ ファイルが含まれるシステムでは、両方のファイルの設定がマージされます。重複する設定がある場合、ユーザーの設定がグローバル設定よりも優先されます。 ## [](#configure-mule-repositories)MuleSoft リポジトリ Anypoint Studio で新しい Mule プロジェクトを作成すると、必要な MuleSoft リポジトリがプロジェクトに自動的に追加されます。Studio 外で Mule プロジェクトを作成する場合は、リポジトリを手動で ​`pom.xml`​ ファイルに追加して、Enterprise リポジトリにアクセスするための Maven のログイン情報を設定する必要があります。 ### [](#mulesoft-の公開リポジトリの設定)MuleSoft の公開リポジトリの設定 MuleSoft の公開リポジトリを設定するには、プロジェクトの ​`pom.xml`​ ファイルに以下を追加します。 ```xml anypoint-exchange Anypoint Exchange https://maven.anypoint.mulesoft.com/api/v3/maven default mulesoft-releases MuleSoft Releases Repository https://repository.mulesoft.org/releases/ default mulesoft-public MuleSoft Public Repository https://repository.mulesoft.org/nexus/content/repositories/public/ default mulesoft-releases MuleSoft Releases Repository default https://repository.mulesoft.org/releases/ false ``` ### [](#mulesoft-enterprise-リポジトリの設定)MuleSoft Enterprise リポジトリの設定 プロジェクトから Enterprise リポジトリにアクセスできるようにするには、Enterprise ライセンスを入手してインストールし、リポジトリへのアクセスを取得して、プロジェクト内でリポジトリを設定する必要があります。 #### [](#enterprise-ライセンスの入手とインストール)Enterprise ライセンスの入手とインストール Enterprise ライセンスの入手とインストールの手順は、​[「Enterprise ライセンスのインストール」](https://docs.mulesoft.com/jp/mule-runtime/4.9/installing-an-enterprise-license)​を参照してください。 #### [](#enterprise-リポジトリへのアクセスの取得)Enterprise リポジトリへのアクセスの取得 MuleSoft ユーザーであり、 [MuleSoft Enterprise リポジトリ](https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/)​にアクセスするためのログイン情報を持っていない場合は、サポートに連絡して、Nexus Enterprise ログイン情報を要求してください。 #### [](#mulesoft-enterprise-リポジトリにアクセスするための-maven-の設定)MuleSoft Enterprise リポジトリにアクセスするための Maven の設定 MuleSoft Enterprise リポジトリにアクセスできるように Maven を設定する手順は次のとおりです。 1. `/.m2/settings.xml`​ に移動します。 2. アクセスが必要なすべてのワークステーションで ​`settings.xml`​ を開きます。​`settings.xml`​ ファイルが存在しない場合は作成してください。 `settings.xml`​ ファイルの詳細は、 [Maven ドキュメント](http://maven.apache.org/settings.html)​を参照してください。 3. 各 ​`settings.xml`​ ファイルの ​`servers`​ セクションに次の構文を追加します。 ```xml ... MuleRepository YOUR_ID YOUR_PASSWORD ... ``` 4. 各 ​`settings.xml`​ ファイルの ​`profile`​ セクションに次の構文を追加します。 ```xml ... Mule true MuleRepository MuleRepository https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/ default true true ... ``` ## [](#便利なコマンド)便利なコマンド 次のコマンドを使用して、Maven インストールに関する情報を取得し、プロジェクト関連のタスクを実行できます。 ### [](#maven-バイナリと他のファイルを見つける-unix)Maven バイナリと他のファイルを見つける (Unix) whereis mvn ### [](#グローバル設定ファイルなどの-maven-ファイルを見つける-unix)グローバル設定ファイルなどの Maven ファイルを見つける (Unix) locate maven ### [](#maven-バージョンを取得する)Maven バージョンを取得する mvn --version Java ホームディレクトリ、ロケール、プロセッサーアーキテクチャなど、他の情報も提供されます。 ### [](#maven-コマンドとオプションのリストを取得する)Maven コマンドとオプションのリストを取得する mvn -h ### [](#maven-のマニュアルページを確認する-unix)Maven のマニュアルページを確認する (Unix) man mvn ### [](#プロジェクトを作成する)プロジェクトを作成する mvn archetype:generate -DgroupId=com.company.app -DartifactId=myapp -DarchetypeArtifactId=myarchetypeid -DinteractiveMode=false ### [](#プロジェクトをビルドする)プロジェクトをビルドする mvn package ### [](#プロジェクトをクリーンアップする)プロジェクトをクリーンアップする mvn clean ### [](#サイトを生成する)サイトを生成する mvn site ### [](#アーティファクトに含まれる-jar-ファイルのリストを取得する)アーティファクトに含まれる JAR ファイルのリストを取得する mvn dependency:build-classpath ### [](#アーティファクトの連動関係ツリーを取得する)アーティファクトの連動関係ツリーを取得する mvn dependency:tree ## [](#maven-中央リポジトリへの-mule-アーティファクトのデプロイ)Maven 中央リポジトリへの Mule アーティファクトのデプロイ 中央リポジトリを使用すると、アプリケーションをビルドするときのユーザーの時間を節約できます。中央リポジトリにデプロイするには、Mule ​`POM`​ ファイルと ​`JAR`​ アーティファクトを目的のリポジトリにデプロイする必要があります。 デプロイプラグインは、主にデプロイフェーズ中に、他の開発者やプロジェクトと共有するアーティファクトをリモートリポジトリに追加するために使用されます。 ### [](#pom-xml-のデプロイ)pom.xml のデプロイ `pom.xml`​ をリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${project.groupId} -DartifactId=${project.artifactId} -Dversion=${version} -Dpackaging=pom -Dfile=${localPom.canonicalPath} -Durl=http:///nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​``​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 ### [](#jar-ファイルのデプロイ)JAR ファイルのデプロイ `JAR`​ ファイルをリモートリポジトリにデプロイするには、次のコマンドを使用します。 ```text mvn deploy:deploy-file -DgroupId=${pomProps.groupId} -DartifactId=${pomProps.artifactId} -Dversion=${pomProps.version} -Dpackaging=jar -Dfile=${f.canonicalPath} -DpomFile=${localPom.canonicalPath} -Durl=http://${your_repository_ip}/nexus/content/repositories/releases -DrepositoryId=releases ``` `-Durl`​ パラメーターでは、​`your_repository_ip`​ を正しい IP アドレスに置き換えます。また、​`-DrepositoryId`​ は、​`settings.xml`​ ファイルで定義されたログイン情報に一致する必要があります。 `JAR`​ ファイルをローカルにインストールし、そのファイルをリモートにもデプロイする場合、両方の場所を引数定義で保持することができます。 ## [](#外部リソース)外部リソース - [Apache Maven ホームページ](https://maven.apache.org/index.html) - [Maven 使用開始ガイド](https://maven.apache.org/guides/getting-started/index.html) - [Maven デプロイプラグインリファレンス](https://maven.apache.org/plugins/maven-deploy-plugin) - [POM リファレンス](https://maven.apache.org/pom.html) - [設定リファレンス](https://maven.apache.org/settings.html) # MDC ログ Mapped Diagnostic Context (MDC) では、より多くのコンテキストまたは情報が現在の Mule イベントのログに提供されるため、ログが強化され、追跡が改善されます。 デフォルトでは、Mule では、現在のイベントの場所を表示する ​`processor`​ と、イベントの相関 ID を表示する ​`event`​ の 2 つの MDC エントリが記録されます。 Mule Tracing Module を使用すると、特定の Mule イベントのログコンテキストの変数を追加、削除、クリアすることでログを強化できます。このログコンテキストは、対応するイベントの実行全体にわたって存在します。 ## [](#前提条件)前提条件 MDC ログ操作を使用するには、次のタスクを完了します。 - アプリケーションに Mule Tracing Module をインストールします。 - `log4j2.xml`​ ファイル内のパターンレイアウトを ​`MDC`​ に変更します。
Anypoint Runtime Fabric または CloudHub 2.0 を使用して Mule アプリケーションをデプロイしている場合、MDC ログはサポートされません。
## [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール 次の手順に従って、アプリケーションに Mule Tracing Module をインストールします。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ## [](#log4j2-xml-ファイル内のパターンレイアウトの変更)log4j2.xml ファイル内のパターンレイアウトの変更 この変更では、相関 ID とプロセッサーパスを含む MDC コンテキストを自動的に追加するように Mule に指示します。Mule アプリケーションの ​`log4j2.xml`​ ファイルまたは Mule インスタンスのファイルを変更できます。このファイルは ​`/conf/log4j2.xml`​ にあります。 次の手順に従って、パターンレイアウトを MDC に変更します。 1. `log4j2.xml`​ ファイルを編集目的で開きます。 2. `[processor: %X{processorPath}; event: %X{correlationId}]`​ を ​`[%MDC]`​ に置き換えます。 ### [](#log4j2-xml-ファイルの設定例)log4j2.xml ファイルの設定例 例: MDC ログを含まないデフォルトの log4j2.xml ファイル。 例: MDC ログを含む更新後の log4j2.xml ファイル。 ## [](#使用可能な操作)使用可能な操作
XML 要素 説明 受け入れられる属性

set-logging-variable

ログ変数とその値を設定します。
属性名 説明

variableName​

記録する変数の名前。

value​

変数に割り当てる値。DataWeave 式を受け入れます。

remove-logging-variable

ログ変数を削除します。
属性名 説明

variableName​

削除する変数の名前。

clear-logging-variables

すべてのログ変数を削除します。このオプションでは、プロセッサーパスまたは相関 ID は削除されません。

なし
## [](#アプリケーションでの-mdc-ログの設定)アプリケーションでの MDC ログの設定 MDC ログを設定するには、使用可能ないずれかの操作を Mule アプリケーションフローに追加して、対応する属性を指定します。 たとえば、ログ変数を設定するには、​``​ XML 要素をアプリケーションフローに挿入します。 ... ... フローの実行後、出力ログは次のようになります。 INFO 2021-04-08 16:58:26,882 \[\[MuleRuntime\].uber.15: \[test-project-app\].exampleFlow.CPU\_LITE @18f679\] \[{correlationId=c85e16c0-98a4-11eb-bc34-cac765a2219b, processorPath=exampleFlow/processors/2, testVar=testValue}\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Example このログコンテキストは、Logger コンポーネントのすべての出力と Mule Runtime で生成されるすべての内部ログに影響します。このため、予期しないエラーが発生している場合など、潜在的な問題を見つけ出すための追加の情報が必要な場合に、Mule で処理しているイベントに、より多くのコンテキストを追加できます。 ## [](#例)例 次のアプリケーションを考えてみます。 ![MDC ログの例](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-mdc-example.png) 次の要求を送信します。 curl --location --request GET '0.0.0.0:8081/order' \\ --header 'Content-Type: application/json' \\ --data-raw '{ "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] }' 出力ログは次のようになります。 INFO 2021-04-09 11:14:38,409 \[\[MuleRuntime\].uber.05: \[tracing-module\].tracing-moduleFlow.CPU\_LITE @34a62707\] \[processor: tracing-moduleFlow/processors/2; event: eb2b2461-993d-11eb-8a64-4865ee1fd814\] {correlationId=eb2b2461-993d-11eb-8a64-4865ee1fd814, customerId=ARG-12934, processorPath=tracing-moduleFlow/processors/2, requestPath=GET:/order} org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] } ## [](#関連情報)関連情報 - [ログの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/logging-in-mule) # MDC ログ Mapped Diagnostic Context (MDC) では、より多くのコンテキストまたは情報が現在の Mule イベントのログに提供されるため、ログが強化され、追跡が改善されます。 デフォルトでは、Mule では、現在のイベントの場所を表示する ​`processor`​ と、イベントの相関 ID を表示する ​`event`​ の 2 つの MDC エントリが記録されます。 Mule Tracing Module を使用すると、特定の Mule イベントのログコンテキストの変数を追加、削除、クリアすることでログを強化できます。このログコンテキストは、対応するイベントの実行全体にわたって存在します。 ## [](#前提条件)前提条件 MDC ログ操作を使用するには、次のタスクを完了します。 - アプリケーションに Mule Tracing Module をインストールします。 - `log4j2.xml`​ ファイル内のパターンレイアウトを ​`MDC`​ に変更します。
Anypoint Runtime Fabric または CloudHub 2.0 を使用して Mule アプリケーションをデプロイしている場合、MDC ログはサポートされません。
## [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール 次の手順に従って、アプリケーションに Mule Tracing Module をインストールします。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ## [](#log4j2-xml-ファイル内のパターンレイアウトの変更)log4j2.xml ファイル内のパターンレイアウトの変更 この変更では、相関 ID とプロセッサーパスを含む MDC コンテキストを自動的に追加するように Mule に指示します。Mule アプリケーションの ​`log4j2.xml`​ ファイルまたは Mule インスタンスのファイルを変更できます。このファイルは ​`/conf/log4j2.xml`​ にあります。 次の手順に従って、パターンレイアウトを MDC に変更します。 1. `log4j2.xml`​ ファイルを編集目的で開きます。 2. `[processor: %X{processorPath}; event: %X{correlationId}]`​ を ​`[%MDC]`​ に置き換えます。 ### [](#log4j2-xml-ファイルの設定例)log4j2.xml ファイルの設定例 例: MDC ログを含まないデフォルトの log4j2.xml ファイル。 例: MDC ログを含む更新後の log4j2.xml ファイル。 ## [](#使用可能な操作)使用可能な操作
XML 要素 説明 受け入れられる属性

set-logging-variable

ログ変数とその値を設定します。
属性名 説明

variableName​

記録する変数の名前。

value​

変数に割り当てる値。DataWeave 式を受け入れます。

remove-logging-variable

ログ変数を削除します。
属性名 説明

variableName​

削除する変数の名前。

clear-logging-variables

すべてのログ変数を削除します。このオプションでは、プロセッサーパスまたは相関 ID は削除されません。

なし
## [](#アプリケーションでの-mdc-ログの設定)アプリケーションでの MDC ログの設定 MDC ログを設定するには、使用可能ないずれかの操作を Mule アプリケーションフローに追加して、対応する属性を指定します。 たとえば、ログ変数を設定するには、​``​ XML 要素をアプリケーションフローに挿入します。 ... ... フローの実行後、出力ログは次のようになります。 INFO 2021-04-08 16:58:26,882 \[\[MuleRuntime\].uber.15: \[test-project-app\].exampleFlow.CPU\_LITE @18f679\] \[{correlationId=c85e16c0-98a4-11eb-bc34-cac765a2219b, processorPath=exampleFlow/processors/2, testVar=testValue}\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Example このログコンテキストは、Logger コンポーネントのすべての出力と Mule Runtime で生成されるすべての内部ログに影響します。このため、予期しないエラーが発生している場合など、潜在的な問題を見つけ出すための追加の情報が必要な場合に、Mule で処理しているイベントに、より多くのコンテキストを追加できます。 ## [](#例)例 次のアプリケーションを考えてみます。 ![MDC ログの例](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-mdc-example.png) 次の要求を送信します。 curl --location --request GET '0.0.0.0:8081/order' \\ --header 'Content-Type: application/json' \\ --data-raw '{ "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] }' 出力ログは次のようになります。 INFO 2021-04-09 11:14:38,409 \[\[MuleRuntime\].uber.05: \[tracing-module\].tracing-moduleFlow.CPU\_LITE @34a62707\] \[processor: tracing-moduleFlow/processors/2; event: eb2b2461-993d-11eb-8a64-4865ee1fd814\] {correlationId=eb2b2461-993d-11eb-8a64-4865ee1fd814, customerId=ARG-12934, processorPath=tracing-moduleFlow/processors/2, requestPath=GET:/order} org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] } ## [](#関連情報)関連情報 - [ログの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/logging-in-mule) # MDC ログ Mapped Diagnostic Context (MDC) では、より多くのコンテキストまたは情報が現在の Mule イベントのログに提供されるため、ログが強化され、追跡が改善されます。 デフォルトでは、Mule では、現在のイベントの場所を表示する ​`processor`​ と、イベントの相関 ID を表示する ​`event`​ の 2 つの MDC エントリが記録されます。 Mule Tracing Module を使用すると、特定の Mule イベントのログコンテキストの変数を追加、削除、クリアすることでログを強化できます。このログコンテキストは、対応するイベントの実行全体にわたって存在します。 ## [](#前提条件)前提条件 MDC ログ操作を使用するには、次のタスクを完了します。 - アプリケーションに Mule Tracing Module をインストールします。 - `log4j2.xml`​ ファイル内のパターンレイアウトを ​`MDC`​ に変更します。
Anypoint Runtime Fabric または CloudHub 2.0 を使用して Mule アプリケーションをデプロイしている場合、MDC ログはサポートされません。
## [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール 次の手順に従って、アプリケーションに Mule Tracing Module をインストールします。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ## [](#log4j2-xml-ファイル内のパターンレイアウトの変更)log4j2.xml ファイル内のパターンレイアウトの変更 この変更では、相関 ID とプロセッサーパスを含む MDC コンテキストを自動的に追加するように Mule に指示します。Mule アプリケーションの ​`log4j2.xml`​ ファイルまたは Mule インスタンスのファイルを変更できます。このファイルは ​`/conf/log4j2.xml`​ にあります。 次の手順に従って、パターンレイアウトを MDC に変更します。 1. `log4j2.xml`​ ファイルを編集目的で開きます。 2. `[processor: %X{processorPath}; event: %X{correlationId}]`​ を ​`[%MDC]`​ に置き換えます。 ### [](#log4j2-xml-ファイルの設定例)log4j2.xml ファイルの設定例 例: MDC ログを含まないデフォルトの log4j2.xml ファイル。 例: MDC ログを含む更新後の log4j2.xml ファイル。 ## [](#使用可能な操作)使用可能な操作
XML 要素 説明 受け入れられる属性

set-logging-variable

ログ変数とその値を設定します。
属性名 説明

variableName​

記録する変数の名前。

value​

変数に割り当てる値。DataWeave 式を受け入れます。

remove-logging-variable

ログ変数を削除します。
属性名 説明

variableName​

削除する変数の名前。

clear-logging-variables

すべてのログ変数を削除します。このオプションでは、プロセッサーパスまたは相関 ID は削除されません。

なし
## [](#アプリケーションでの-mdc-ログの設定)アプリケーションでの MDC ログの設定 MDC ログを設定するには、使用可能ないずれかの操作を Mule アプリケーションフローに追加して、対応する属性を指定します。 たとえば、ログ変数を設定するには、​``​ XML 要素をアプリケーションフローに挿入します。 ... ... フローの実行後、出力ログは次のようになります。 INFO 2021-04-08 16:58:26,882 \[\[MuleRuntime\].uber.15: \[test-project-app\].exampleFlow.CPU\_LITE @18f679\] \[{correlationId=c85e16c0-98a4-11eb-bc34-cac765a2219b, processorPath=exampleFlow/processors/2, testVar=testValue}\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Example このログコンテキストは、Logger コンポーネントのすべての出力と Mule Runtime で生成されるすべての内部ログに影響します。このため、予期しないエラーが発生している場合など、潜在的な問題を見つけ出すための追加の情報が必要な場合に、Mule で処理しているイベントに、より多くのコンテキストを追加できます。 ## [](#例)例 次のアプリケーションを考えてみます。 ![MDC ログの例](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-mdc-example.png) 次の要求を送信します。 curl --location --request GET '0.0.0.0:8081/order' \\ --header 'Content-Type: application/json' \\ --data-raw '{ "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] }' 出力ログは次のようになります。 INFO 2021-04-09 11:14:38,409 \[\[MuleRuntime\].uber.05: \[tracing-module\].tracing-moduleFlow.CPU\_LITE @34a62707\] \[processor: tracing-moduleFlow/processors/2; event: eb2b2461-993d-11eb-8a64-4865ee1fd814\] {correlationId=eb2b2461-993d-11eb-8a64-4865ee1fd814, customerId=ARG-12934, processorPath=tracing-moduleFlow/processors/2, requestPath=GET:/order} org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] } ## [](#関連情報)関連情報 - [ログの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/logging-in-mule) # MDC ログ Mapped Diagnostic Context (MDC) では、より多くのコンテキストまたは情報が現在の Mule イベントのログに提供されるため、ログが強化され、追跡が改善されます。 デフォルトでは、Mule では、現在のイベントの場所を表示する ​`processor`​ と、イベントの相関 ID を表示する ​`event`​ の 2 つの MDC エントリが記録されます。 Mule Tracing Module を使用すると、特定の Mule イベントのログコンテキストの変数を追加、削除、クリアすることでログを強化できます。このログコンテキストは、対応するイベントの実行全体にわたって存在します。 ## [](#前提条件)前提条件 MDC ログ操作を使用するには、次のタスクを完了します。 - アプリケーションに Mule Tracing Module をインストールします。 - `log4j2.xml`​ ファイル内のパターンレイアウトを ​`MDC`​ に変更します。
MDC ログは、Anypoint Runtime Fabric または CloudHub 2.0 で用できます。ただし、CloudHub 1.0 を使用して Mule アプリケーションをデプロイしている場合、MDC ログはサポートされません。詳細は、 「CloudHub での MDC Logging Module のサポート」​を参照してください。
## [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール 次の手順に従って、アプリケーションに Mule Tracing Module をインストールします。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ## [](#log4j2-xml-ファイル内のパターンレイアウトの変更)log4j2.xml ファイル内のパターンレイアウトの変更 この変更では、相関 ID とプロセッサーパスを含む MDC コンテキストを自動的に追加するように Mule に指示します。Mule アプリケーションの ​`log4j2.xml`​ ファイルまたは Mule インスタンスのファイルを変更できます。このファイルは ​`/conf/log4j2.xml`​ にあります。 次の手順に従って、パターンレイアウトを MDC に変更します。 1. `log4j2.xml`​ ファイルを編集目的で開きます。 2. `[processor: %X{processorPath}; event: %X{correlationId}]`​ を ​`[%MDC]`​ に置き換えます。 ### [](#log4j2-xml-ファイルの設定例)log4j2.xml ファイルの設定例 例: MDC ログを含まないデフォルトの log4j2.xml ファイル。 例: MDC ログを含む更新後の log4j2.xml ファイル。 ## [](#使用可能な操作)使用可能な操作
XML 要素 説明 受け入れられる属性

set-logging-variable

ログ変数とその値を設定します。
属性名 説明

variableName​

記録する変数の名前。

value​

変数に割り当てる値。DataWeave 式を受け入れます。

remove-logging-variable

ログ変数を削除します。
属性名 説明

variableName​

削除する変数の名前。

clear-logging-variables

すべてのログ変数を削除します。このオプションでは、プロセッサーパスまたは相関 ID は削除されません。

なし
## [](#アプリケーションでの-mdc-ログの設定)アプリケーションでの MDC ログの設定 MDC ログを設定するには、使用可能ないずれかの操作を Mule アプリケーションフローに追加して、対応する属性を指定します。 たとえば、ログ変数を設定するには、​``​ XML 要素をアプリケーションフローに挿入します。 ... ... フローの実行後、出力ログは次のようになります。 INFO 2021-04-08 16:58:26,882 \[\[MuleRuntime\].uber.15: \[test-project-app\].exampleFlow.CPU\_LITE @18f679\] \[{correlationId=c85e16c0-98a4-11eb-bc34-cac765a2219b, processorPath=exampleFlow/processors/2, testVar=testValue}\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Example このログコンテキストは、Logger コンポーネントのすべての出力と Mule Runtime で生成されるすべての内部ログに影響します。このため、予期しないエラーが発生している場合など、潜在的な問題を見つけ出すための追加の情報が必要な場合に、Mule で処理しているイベントに、より多くのコンテキストを追加できます。 ## [](#例)例 次のアプリケーションを考えてみます。 ![MDC ログの例](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-mdc-example.png) 次の要求を送信します。 curl --location --request GET '0.0.0.0:8081/order' \\ --header 'Content-Type: application/json' \\ --data-raw '{ "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] }' 出力ログは次のようになります。 INFO 2021-04-09 11:14:38,409 \[\[MuleRuntime\].uber.05: \[tracing-module\].tracing-moduleFlow.CPU\_LITE @34a62707\] \[processor: tracing-moduleFlow/processors/2; event: eb2b2461-993d-11eb-8a64-4865ee1fd814\] {correlationId=eb2b2461-993d-11eb-8a64-4865ee1fd814, customerId=ARG-12934, processorPath=tracing-moduleFlow/processors/2, requestPath=GET:/order} org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] } ## [](#関連情報)関連情報 - [ログの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/logging-in-mule) # MDC ログ Mapped Diagnostic Context (MDC) では、より多くのコンテキストまたは情報が現在の Mule イベントのログに提供されるため、ログが強化され、追跡が改善されます。 デフォルトでは、Mule では、現在のイベントの場所を表示する ​`processor`​ と、イベントの相関 ID を表示する ​`event`​ の 2 つの MDC エントリが記録されます。 Mule Tracing Module を使用すると、特定の Mule イベントのログコンテキストの変数を追加、削除、クリアすることでログを強化できます。このログコンテキストは、対応するイベントの実行全体にわたって存在します。 ## [](#前提条件)前提条件 MDC ログ操作を使用するには、次のタスクを完了します。 - アプリケーションに Mule Tracing Module をインストールします。 - `log4j2.xml`​ ファイル内のパターンレイアウトを ​`MDC`​ に変更します。
MDC ログは、Anypoint Runtime Fabric または CloudHub 2.0 で用できます。ただし、CloudHub 1.0 を使用して Mule アプリケーションをデプロイしている場合、MDC ログはサポートされません。詳細は、 「CloudHub での MDC Logging Module のサポート」​を参照してください。
## [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール 次の手順に従って、アプリケーションに Mule Tracing Module をインストールします。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ## [](#log4j2-xml-ファイル内のパターンレイアウトの変更)log4j2.xml ファイル内のパターンレイアウトの変更 この変更では、相関 ID とプロセッサーパスを含む MDC コンテキストを自動的に追加するように Mule に指示します。Mule アプリケーションの ​`log4j2.xml`​ ファイルまたは Mule インスタンスのファイルを変更できます。このファイルは ​`/conf/log4j2.xml`​ にあります。 次の手順に従って、パターンレイアウトを MDC に変更します。 1. `log4j2.xml`​ ファイルを編集目的で開きます。 2. `[processor: %X{processorPath}; event: %X{correlationId}]`​ を ​`[%MDC]`​ に置き換えます。 ### [](#log4j2-xml-ファイルの設定例)log4j2.xml ファイルの設定例 例: MDC ログを含まないデフォルトの log4j2.xml ファイル。 例: MDC ログを含む更新後の log4j2.xml ファイル。 ## [](#使用可能な操作)使用可能な操作
XML 要素 説明 受け入れられる属性

set-logging-variable

ログ変数とその値を設定します。
属性名 説明

variableName​

記録する変数の名前。

value​

変数に割り当てる値。DataWeave 式を受け入れます。

remove-logging-variable

ログ変数を削除します。
属性名 説明

variableName​

削除する変数の名前。

clear-logging-variables

すべてのログ変数を削除します。このオプションでは、プロセッサーパスまたは相関 ID は削除されません。

なし
## [](#アプリケーションでの-mdc-ログの設定)アプリケーションでの MDC ログの設定 MDC ログを設定するには、使用可能ないずれかの操作を Mule アプリケーションフローに追加して、対応する属性を指定します。 たとえば、ログ変数を設定するには、​``​ XML 要素をアプリケーションフローに挿入します。 ... ... フローの実行後、出力ログは次のようになります。 INFO 2021-04-08 16:58:26,882 \[\[MuleRuntime\].uber.15: \[test-project-app\].exampleFlow.CPU\_LITE @18f679\] \[{correlationId=c85e16c0-98a4-11eb-bc34-cac765a2219b, processorPath=exampleFlow/processors/2, testVar=testValue}\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Example このログコンテキストは、Logger コンポーネントのすべての出力と Mule Runtime で生成されるすべての内部ログに影響します。このため、予期しないエラーが発生している場合など、潜在的な問題を見つけ出すための追加の情報が必要な場合に、Mule で処理しているイベントに、より多くのコンテキストを追加できます。 ## [](#例)例 次のアプリケーションを考えてみます。 ![Mule エラー処理フローの Logger コンポーネントと変数を設定するコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-mdc-example.png) 次の要求を送信します。 curl --location --request GET '0.0.0.0:8081/order' \\ --header 'Content-Type: application/json' \\ --data-raw '{ "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] }' 出力ログは次のようになります。 INFO 2021-04-09 11:14:38,409 \[\[MuleRuntime\].uber.05: \[tracing-module\].tracing-moduleFlow.CPU\_LITE @34a62707\] \[processor: tracing-moduleFlow/processors/2; event: eb2b2461-993d-11eb-8a64-4865ee1fd814\] {correlationId=eb2b2461-993d-11eb-8a64-4865ee1fd814, customerId=ARG-12934, processorPath=tracing-moduleFlow/processors/2, requestPath=GET:/order} org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] } ## [](#関連情報)関連情報 - [ログの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/logging-in-mule) # MDC ログ Mapped Diagnostic Context (MDC) では、より多くのコンテキストまたは情報が現在の Mule イベントのログに提供されるため、ログが強化され、追跡が改善されます。 デフォルトでは、Mule では、現在のイベントの場所を表示する ​`processor`​ と、イベントの相関 ID を表示する ​`event`​ の 2 つの MDC エントリが記録されます。 Mule Tracing Module を使用すると、特定の Mule イベントのログコンテキストの変数を追加、削除、クリアすることでログを強化できます。このログコンテキストは、対応するイベントの実行全体にわたって存在します。 ## [](#前提条件)前提条件 MDC ログ操作を使用するには、次のタスクを完了します。 - アプリケーションに Mule Tracing Module をインストールします。 - `log4j2.xml`​ ファイル内のパターンレイアウトを ​`MDC`​ に変更します。
MDC ログは、Anypoint Runtime Fabric または CloudHub 2.0 で用できます。ただし、CloudHub 1.0 を使用して Mule アプリケーションをデプロイしている場合、MDC ログはサポートされません。詳細は、 「CloudHub での MDC Logging Module のサポート」​を参照してください。
## [](#mule-tracing-module-のインストール)Mule Tracing Module のインストール 次の手順に従って、アプリケーションに Mule Tracing Module をインストールします。 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] に移動します。 3. **\[Search in Exchange (Exchange で検索)\]**​ を選択して、Mule Tracing Module を検索します。 4. モジュールを選択し、​**\[Add (追加)\]**​ をクリックします。 5. **\[Finish (完了)\]**​ をクリックします。 ## [](#log4j2-xml-ファイル内のパターンレイアウトの変更)log4j2.xml ファイル内のパターンレイアウトの変更 この変更では、相関 ID とプロセッサーパスを含む MDC コンテキストを自動的に追加するように Mule に指示します。Mule アプリケーションの ​`log4j2.xml`​ ファイルまたは Mule インスタンスのファイルを変更できます。このファイルは ​`/conf/log4j2.xml`​ にあります。 次の手順に従って、パターンレイアウトを MDC に変更します。 1. `log4j2.xml`​ ファイルを編集目的で開きます。 2. `[processor: %X{processorPath}; event: %X{correlationId}]`​ を ​`[%MDC]`​ に置き換えます。 ### [](#log4j2-xml-ファイルの設定例)log4j2.xml ファイルの設定例 例: MDC ログを含まないデフォルトの log4j2.xml ファイル。 例: MDC ログを含む更新後の log4j2.xml ファイル。 ## [](#使用可能な操作)使用可能な操作
XML 要素 説明 受け入れられる属性

set-logging-variable

ログ変数とその値を設定します。
属性名 説明

variableName​

記録する変数の名前。

value​

変数に割り当てる値。DataWeave 式を受け入れます。

remove-logging-variable

ログ変数を削除します。
属性名 説明

variableName​

削除する変数の名前。

clear-logging-variables

すべてのログ変数を削除します。このオプションでは、プロセッサーパスまたは相関 ID は削除されません。

なし
## [](#アプリケーションでの-mdc-ログの設定)アプリケーションでの MDC ログの設定 MDC ログを設定するには、使用可能ないずれかの操作を Mule アプリケーションフローに追加して、対応する属性を指定します。 たとえば、ログ変数を設定するには、​``​ XML 要素をアプリケーションフローに挿入します。 ... ... フローの実行後、出力ログは次のようになります。 INFO 2021-04-08 16:58:26,882 \[\[MuleRuntime\].uber.15: \[test-project-app\].exampleFlow.CPU\_LITE @18f679\] \[{correlationId=c85e16c0-98a4-11eb-bc34-cac765a2219b, processorPath=exampleFlow/processors/2, testVar=testValue}\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Example このログコンテキストは、Logger コンポーネントのすべての出力と Mule Runtime で生成されるすべての内部ログに影響します。このため、予期しないエラーが発生している場合など、潜在的な問題を見つけ出すための追加の情報が必要な場合に、Mule で処理しているイベントに、より多くのコンテキストを追加できます。 ## [](#例)例 次のアプリケーションを考えてみます。 ![Mule エラー処理フローの Logger コンポーネントと変数を設定するコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-mdc-example.png) 次の要求を送信します。 curl --location --request GET '0.0.0.0:8081/order' \\ --header 'Content-Type: application/json' \\ --data-raw '{ "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] }' 出力ログは次のようになります。 INFO 2021-04-09 11:14:38,409 \[\[MuleRuntime\].uber.05: \[tracing-module\].tracing-moduleFlow.CPU\_LITE @34a62707\] \[processor: tracing-moduleFlow/processors/2; event: eb2b2461-993d-11eb-8a64-4865ee1fd814\] {correlationId=eb2b2461-993d-11eb-8a64-4865ee1fd814, customerId=ARG-12934, processorPath=tracing-moduleFlow/processors/2, requestPath=GET:/order} org.mule.runtime.core.internal.processor.LoggerMessageProcessor: { "orderId": 548102842, "customerId": "ARG-12934", "items": \[ "CP-123", "CP-452" \] } ## [](#関連情報)関連情報 - [ログの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/logging-in-mule) # MEL から DataWeave への移行 Mule 4 では Mule Expression Language (MEL) が DataWeave 式言語に要素に置き換わりました。 このセクションでは、Mule アプリケーションの MEL 式を DataWeave (2.0 以降) に移行するための指針を提供します。 ## [](#dataweave-の概要)DataWeave の概要 DataWeave は、単に値の参照と条件の評価を行う式言語として、または関数や再帰を含む複雑なデータ変換を作成するスクリプティング言語として使用できる Mule 固有の言語です。 MEL とは違い、JSON、XML、CSV など、さまざまなデータ型が標準でサポートされます。つまり、式を評価する前にデータを変更する必要がなくなりました。 また、関数のマッピングやデータの絞り込みなど、高度なユースケースもサポートされています。 DataWeave のメインデータセレクターは ​`.`​ 演算子であることに留意してください。 ほとんどキーワードは MEL と共有されるので、ほとんどのシナリオの構文は同じになります。たとえば、​`#[message.payload.name]`​ は両言語とも同じです。 MEL と DataWeave の主な違いは、DataWeave 式には副作用がないことです。DataWeave を使用してデータを抽出または生成できますが、データを変更することはできません。 それらのユースケースの対処法については、​[Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-java-integration)​の例を参照してください。 ## [](#mel-の使用法)MEL の使用法 以下のセクションでは、MEL の一部の使用法を Mule 4 に適応させる方法を説明します。 ### [](#コンテキスト変数へのアクセス)コンテキスト変数へのアクセス 次の変更を除き、DataWeave ではコンテキスト変数 (Mule Runtime 変数とも呼ばれる) は同じままです。
MEL DataWeave

フロー変数​

flowVars​

  • 例: #[flowVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

例外​

exception​

Mule エラー​:

error​

インバウンド添付ファイル​

message.inboundAttachments​

マルチパートデータ形式​

情報:

インバウンドプロパティ​

message.inboundProperties​

  • 例:

    #[inboundProperties.'http.query.params']
#[inboundProperties]

Mule メッセージ属性​ (メタデータ)

attributes​

  • 例:

    #[attributes.queryParams]
#[attributes.headers]

インバウンドプロパティが属性に​

アウトバウンド添付ファイル​

message.outboundAttachments​

マルチパートデータ形式​

情報:

アウトバウンドプロパティ​

message.outboundProperties​

削除:​

「アウトバウンドプロパティ」​を参照してください。

message.dataType

dataType​

message.id​、​message.rootId​、​message.replyTo

削除​

レコード変数​

recordVars​

  • 例: #[recordVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

セッション変数​

sessionVars​

  • 例: #[sessionVars.myVar]​

削除:​

トランスポートバリアーは Mule 4 には存在しません。情報:

server.dateTime​

削除:​

DataWeave ​now​ 関数を使用する。
### [](#extract_data)データの抽出 [DataWeave セレクター](#dataweave-selectors.adoc)​を使用して、MEL と同様にデータを照会できます。また、JSON などの型に対応するために、さらに変換を行う必要がありません。 以下の例では、次の JSON ペイロードの ID をログに記録します。 JSON ペイロード ```json { "name" : "Rachel Duncan", "id": "779H41" } ``` Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#値の割り当て)値の割り当て 前述のとおり、DataWeave では、MEL の ​`expression-component`​ で許可されていたようなデータの変更はサポートされていません。そのようなユースケースを実行するには、Scripting Module を使用する必要があります。 Java マップとして記述されている​[前述](#extract_data)​のペイロードを考えてみます。例では、​`name`​ 属性を変更します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml payload.put('name', 'R. Duncan') return payload ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ### [](#java-メソッドの呼び出し)Java メソッドの呼び出し DataWeave を使用して静的メソッドを呼び出すことができます。通常のメソッドの場合は Java Module を使用できます。このモジュールは操作と関数の両方を公開して Java メソッドを呼び出します。 #### [](#静的メソッド)静的メソッド 以下の例では、Java の Locale ​`getDefault`​ 静的メソッドを Mule 3 と Mule 4 で使用しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` DataWeave では、Java 静的メソッドが検索対象であることを示す ​`java!`​ プレフィックスと、完全修飾された (​`.`​ ではなく、​`::`​ 区切りの) クラス名が必要です。 #### [](#インスタンスメソッド)インスタンスメソッド 以下の例は、Mule 3 と Mule 4 での Java の String ​`equalsIgnoreCase`​ メソッドの使用法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` Java Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-java-module 1.0.0 mule-plugin ``` ### [](#対象の定義)対象の定義 `enricher`​ は削除されて、すべての操作でサポートされる対象変数に置き換わりました。以下の例は、Mule 3 と Mule 4 で操作の結果を変数に送信する方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` - 詳細は、​[「対象変数を使用したデータのエンリッチ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/target-variables)​を参照してください。 ### [](#xpath-関数)XPath 関数 DataWeave では、​[セレクター](#dataweave-selectors.adoc)​を使用して XML コンテンツを照会できますが、XML Module を使用することもできます。このモジュールは操作と関数の両方を公開して XPath クエリを実行します。 以下の例は、Mule 3 と 4 で、変数から取得された特定の単語を含む行を取得する方法を示しています。 Mule 3 の例 ```xml xpath3('//LINE[contains(.,$word)]',payload,'NODESET') ``` Mule 4 の例 ```xml ``` XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ### [](#ワイルドカード関数と正規表現関数)ワイルドカード関数と正規表現関数 DataWeave のマッチング関数 ​`match`​ と ​`matches`​ を代わりに使用できます (コア DataWeave 関数を参照してください)。次の例は、DataWeave で正規表現を使用して、​`wildcard`​ MEL 関数の使用を置き換える方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # MEL から DataWeave への移行 Mule 4 では Mule Expression Language (MEL) が DataWeave 式言語に要素に置き換わりました。 このセクションでは、Mule アプリケーションの MEL 式を DataWeave (2.0 以降) に移行するための指針を提供します。 ## [](#dataweave-の概要)DataWeave の概要 DataWeave は、単に値の参照と条件の評価を行う式言語として、または関数や再帰を含む複雑なデータ変換を作成するスクリプティング言語として使用できる Mule 固有の言語です。 MEL とは違い、JSON、XML、CSV など、さまざまなデータ型が標準でサポートされます。つまり、式を評価する前にデータを変更する必要がなくなりました。 また、関数のマッピングやデータの絞り込みなど、高度なユースケースもサポートされています。 DataWeave のメインデータセレクターは ​`.`​ 演算子であることに留意してください。 ほとんどキーワードは MEL と共有されるので、ほとんどのシナリオの構文は同じになります。たとえば、​`#[message.payload.name]`​ は両言語とも同じです。 MEL と DataWeave の主な違いは、DataWeave 式には副作用がないことです。DataWeave を使用してデータを抽出または生成できますが、データを変更することはできません。 それらのユースケースの対処法については、​[Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-java-integration)​の例を参照してください。 ## [](#mel-の使用法)MEL の使用法 以下のセクションでは、MEL の一部の使用法を Mule 4 に適応させる方法を説明します。 ### [](#コンテキスト変数へのアクセス)コンテキスト変数へのアクセス 次の変更を除き、DataWeave ではコンテキスト変数 (Mule Runtime 変数とも呼ばれる) は同じままです。
MEL DataWeave

フロー変数​

flowVars​

  • 例: #[flowVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

例外​

exception​

Mule エラー​:

error​

インバウンド添付ファイル​

message.inboundAttachments​

マルチパートデータ形式​

情報:

インバウンドプロパティ​

message.inboundProperties​

  • 例:

#[inboundProperties.'http.query.params']
#[inboundProperties]

Mule メッセージ属性​ (メタデータ)

attributes​

  • 例:

#[attributes.queryParams]
#[attributes.headers]

インバウンドプロパティが属性に​

アウトバウンド添付ファイル​

message.outboundAttachments​

マルチパートデータ形式​

情報:

アウトバウンドプロパティ​

message.outboundProperties​

削除:​

情報:

message.dataType

dataType​

message.id​、​message.rootId​、​message.replyTo

削除​

レコード変数​

recordVars​

  • 例: #[recordVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

セッション変数​

sessionVars​

  • 例: #[sessionVars.myVar]​

削除:​

トランスポートバリアーは Mule 4 には存在しません。情報:

server.dateTime​

削除:​

DataWeave ​now​ 関数を使用する。
### [](#extract_data)データの抽出 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して、MEL と同様にデータを照会できます。また、JSON などの型に対応するために、さらに変換を行う必要がありません。 以下の例では、次の JSON ペイロードの ID をログに記録します。 JSON ペイロード ```json { "name" : "Rachel Duncan", "id": "779H41" } ``` Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#値の割り当て)値の割り当て 前述のとおり、DataWeave では、MEL の ​`expression-component`​ で許可されていたようなデータの変更はサポートされていません。そのようなユースケースを実行するには、Scripting Module を使用する必要があります。 Java マップとして記述されている​[前述](#extract_data)​のペイロードを考えてみます。例では、​`name`​ 属性を変更します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml payload.put('name', 'R. Duncan') return payload ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ### [](#java-メソッドの呼び出し)Java メソッドの呼び出し DataWeave を使用して静的メソッドを呼び出すことができます。通常のメソッドの場合は Java Module を使用できます。このモジュールは操作と関数の両方を公開して Java メソッドを呼び出します。 #### [](#静的メソッド)静的メソッド 以下の例では、Java の Locale ​`getDefault`​ 静的メソッドを Mule 3 と Mule 4 で使用しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` DataWeave では、Java 静的メソッドが検索対象であることを示す ​`java!`​ プレフィックスと、完全修飾された (​`.`​ ではなく、​`::`​ 区切りの) クラス名が必要です。 #### [](#インスタンスメソッド)インスタンスメソッド 以下の例は、Mule 3 と Mule 4 での Java の String ​`equalsIgnoreCase`​ メソッドの使用法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` Java Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-java-module 1.0.0 mule-plugin ``` ### [](#対象の定義)対象の定義 `enricher`​ は削除されて、すべての操作でサポートされる対象変数に置き換わりました。以下の例は、Mule 3 と Mule 4 で操作の結果を変数に送信する方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` - 詳細は、​[「対象変数を使用したデータのエンリッチ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/target-variables)​を参照してください。 ### [](#xpath-関数)XPath 関数 DataWeave では、​[セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して XML コンテンツを照会できますが、XML Module を使用することもできます。このモジュールは操作と関数の両方を公開して XPath クエリを実行します。 以下の例は、Mule 3 と 4 で、変数から取得された特定の単語を含む行を取得する方法を示しています。 Mule 3 の例 ```xml xpath3('//LINE[contains(.,$word)]',payload,'NODESET') ``` Mule 4 の例 ```xml ``` XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ### [](#ワイルドカード関数と正規表現関数)ワイルドカード関数と正規表現関数 DataWeave のマッチング関数 ​`match`​ と ​`matches`​ を代わりに使用できます (コア DataWeave 関数を参照してください)。次の例は、DataWeave で正規表現を使用して、​`wildcard`​ MEL 関数の使用を置き換える方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # MEL から DataWeave への移行 Mule 4 では Mule Expression Language (MEL) が DataWeave 式言語に要素に置き換わりました。 このセクションでは、Mule アプリケーションの MEL 式を DataWeave (2.0 以降) に移行するための指針を提供します。 ## [](#dataweave-の概要)DataWeave の概要 DataWeave は、単に値の参照と条件の評価を行う式言語として、または関数や再帰を含む複雑なデータ変換を作成するスクリプティング言語として使用できる Mule 固有の言語です。 MEL とは違い、JSON、XML、CSV など、さまざまなデータ型が標準でサポートされます。つまり、式を評価する前にデータを変更する必要がなくなりました。 また、関数のマッピングやデータの絞り込みなど、高度なユースケースもサポートされています。 DataWeave のメインデータセレクターは ​`.`​ 演算子であることに留意してください。 ほとんどキーワードは MEL と共有されるので、ほとんどのシナリオの構文は同じになります。たとえば、​`#[message.payload.name]`​ は両言語とも同じです。 MEL と DataWeave の主な違いは、DataWeave 式には副作用がないことです。DataWeave を使用してデータを抽出または生成できますが、データを変更することはできません。 それらのユースケースの対処法については、​[Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-java-integration)​の例を参照してください。 ## [](#mel-の使用法)MEL の使用法 以下のセクションでは、MEL の一部の使用法を Mule 4 に適応させる方法を説明します。 ### [](#コンテキスト変数へのアクセス)コンテキスト変数へのアクセス 次の変更を除き、DataWeave ではコンテキスト変数 (Mule Runtime 変数とも呼ばれる) は同じままです。
MEL DataWeave

フロー変数​

flowVars​

  • 例: #[flowVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

例外​

exception​

Mule エラー​:

error​

インバウンド添付ファイル​

message.inboundAttachments​

マルチパートデータ形式​

情報:

インバウンドプロパティ​

message.inboundProperties​

  • 例:

#[inboundProperties.'http.query.params']
#[inboundProperties]

Mule メッセージ属性​ (メタデータ)

attributes​

  • 例:

#[attributes.queryParams]
#[attributes.headers]

インバウンドプロパティが属性に​

アウトバウンド添付ファイル​

message.outboundAttachments​

マルチパートデータ形式​

情報:

アウトバウンドプロパティ​

message.outboundProperties​

削除:​

情報:

message.dataType

dataType​

message.id​、​message.rootId​、​message.replyTo

削除​

レコード変数​

recordVars​

  • 例: #[recordVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

セッション変数​

sessionVars​

  • 例: #[sessionVars.myVar]​

削除:​

トランスポートバリアーは Mule 4 には存在しません。情報:

server.dateTime​

削除:​

DataWeave ​now​ 関数を使用する。
### [](#extract_data)データの抽出 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して、MEL と同様にデータを照会できます。また、JSON などの型に対応するために、さらに変換を行う必要がありません。 以下の例では、次の JSON ペイロードの ID をログに記録します。 JSON ペイロード ```json { "name" : "Rachel Duncan", "id": "779H41" } ``` Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#値の割り当て)値の割り当て 前述のとおり、DataWeave では、MEL の ​`expression-component`​ で許可されていたようなデータの変更はサポートされていません。そのようなユースケースを実行するには、Scripting Module を使用する必要があります。 Java マップとして記述されている​[前述](#extract_data)​のペイロードを考えてみます。例では、​`name`​ 属性を変更します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml payload.put('name', 'R. Duncan') return payload ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ### [](#java-メソッドの呼び出し)Java メソッドの呼び出し DataWeave を使用して静的メソッドを呼び出すことができます。通常のメソッドの場合は Java Module を使用できます。このモジュールは操作と関数の両方を公開して Java メソッドを呼び出します。 #### [](#静的メソッド)静的メソッド 以下の例では、Java の Locale ​`getDefault`​ 静的メソッドを Mule 3 と Mule 4 で使用しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` DataWeave では、Java 静的メソッドが検索対象であることを示す ​`java!`​ プレフィックスと、完全修飾された (​`.`​ ではなく、​`::`​ 区切りの) クラス名が必要です。 #### [](#インスタンスメソッド)インスタンスメソッド 以下の例は、Mule 3 と Mule 4 での Java の String ​`equalsIgnoreCase`​ メソッドの使用法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` Java Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-java-module 1.0.0 mule-plugin ``` ### [](#対象の定義)対象の定義 `enricher`​ は削除されて、すべての操作でサポートされる対象変数に置き換わりました。以下の例は、Mule 3 と Mule 4 で操作の結果を変数に送信する方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` - 詳細は、​[「対象変数を使用したデータのエンリッチ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/target-variables)​を参照してください。 ### [](#xpath-関数)XPath 関数 DataWeave では、​[セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して XML コンテンツを照会できますが、XML Module を使用することもできます。このモジュールは操作と関数の両方を公開して XPath クエリを実行します。 以下の例は、Mule 3 と 4 で、変数から取得された特定の単語を含む行を取得する方法を示しています。 Mule 3 の例 ```xml xpath3('//LINE[contains(.,$word)]',payload,'NODESET') ``` Mule 4 の例 ```xml ``` XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ### [](#ワイルドカード関数と正規表現関数)ワイルドカード関数と正規表現関数 DataWeave のマッチング関数 ​`match`​ と ​`matches`​ を代わりに使用できます (コア DataWeave 関数を参照してください)。次の例は、DataWeave で正規表現を使用して、​`wildcard`​ MEL 関数の使用を置き換える方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # MEL から DataWeave への移行 Mule 4 では Mule Expression Language (MEL) が DataWeave 式言語に要素に置き換わりました。 このセクションでは、Mule アプリケーションの MEL 式を DataWeave (2.0 以降) に移行するための指針を提供します。 ## [](#dataweave-の概要)DataWeave の概要 DataWeave は、単に値の参照と条件の評価を行う式言語として、または関数や再帰を含む複雑なデータ変換を作成するスクリプティング言語として使用できる Mule 固有の言語です。 MEL とは違い、JSON、XML、CSV など、さまざまなデータ型が標準でサポートされます。つまり、式を評価する前にデータを変更する必要がなくなりました。 また、関数のマッピングやデータの絞り込みなど、高度なユースケースもサポートされています。 DataWeave のメインデータセレクターは ​`.`​ 演算子であることに留意してください。 ほとんどキーワードは MEL と共有されるので、ほとんどのシナリオの構文は同じになります。たとえば、​`#[message.payload.name]`​ は両言語とも同じです。 MEL と DataWeave の主な違いは、DataWeave 式には副作用がないことです。DataWeave を使用してデータを抽出または生成できますが、データを変更することはできません。 それらのユースケースの対処法については、​[Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-java-integration)​の例を参照してください。 ## [](#mel-の使用法)MEL の使用法 以下のセクションでは、MEL の一部の使用法を Mule 4 に適応させる方法を説明します。 ### [](#コンテキスト変数へのアクセス)コンテキスト変数へのアクセス 次の変更を除き、DataWeave ではコンテキスト変数 (Mule Runtime 変数とも呼ばれる) は同じままです。
MEL DataWeave

フロー変数​

flowVars​

  • 例: #[flowVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

例外​

exception​

Mule エラー​:

error​

インバウンド添付ファイル​

message.inboundAttachments​

マルチパートデータ形式​

情報:

インバウンドプロパティ​

message.inboundProperties​

  • 例:

#[inboundProperties.'http.query.params']
#[inboundProperties]

Mule メッセージ属性​ (メタデータ)

attributes​

  • 例:

#[attributes.queryParams]
#[attributes.headers]

インバウンドプロパティが属性に​

アウトバウンド添付ファイル​

message.outboundAttachments​

マルチパートデータ形式​

情報:

アウトバウンドプロパティ​

message.outboundProperties​

削除:​

情報:

message.dataType

dataType​

message.id​、​message.rootId​、​message.replyTo

削除​

レコード変数​

recordVars​

  • 例: #[recordVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

セッション変数​

sessionVars​

  • 例: #[sessionVars.myVar]​

削除:​

トランスポートバリアーは Mule 4 には存在しません。情報:

server.dateTime​

削除:​

DataWeave ​now​ 関数を使用する。
### [](#extract_data)データの抽出 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して、MEL と同様にデータを照会できます。また、JSON などの型に対応するために、さらに変換を行う必要がありません。 以下の例では、次の JSON ペイロードの ID をログに記録します。 JSON ペイロード ```json { "name" : "Rachel Duncan", "id": "779H41" } ``` Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#値の割り当て)値の割り当て 前述のとおり、DataWeave では、MEL の ​`expression-component`​ で許可されていたようなデータの変更はサポートされていません。そのようなユースケースを実行するには、Scripting Module を使用する必要があります。 Java マップとして記述されている​[前述](#extract_data)​のペイロードを考えてみます。例では、​`name`​ 属性を変更します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml payload.put('name', 'R. Duncan') return payload ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ### [](#java-メソッドの呼び出し)Java メソッドの呼び出し DataWeave を使用して静的メソッドを呼び出すことができます。通常のメソッドの場合は Java Module を使用できます。このモジュールは操作と関数の両方を公開して Java メソッドを呼び出します。 #### [](#静的メソッド)静的メソッド 以下の例では、Java の Locale ​`getDefault`​ 静的メソッドを Mule 3 と Mule 4 で使用しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` DataWeave では、Java 静的メソッドが検索対象であることを示す ​`java!`​ プレフィックスと、完全修飾された (​`.`​ ではなく、​`::`​ 区切りの) クラス名が必要です。 #### [](#インスタンスメソッド)インスタンスメソッド 以下の例は、Mule 3 と Mule 4 での Java の String ​`equalsIgnoreCase`​ メソッドの使用法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` Java Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-java-module 1.0.0 mule-plugin ``` ### [](#対象の定義)対象の定義 `enricher`​ は削除されて、すべての操作でサポートされる対象変数に置き換わりました。以下の例は、Mule 3 と Mule 4 で操作の結果を変数に送信する方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` - 詳細は、​[「対象変数を使用したデータのエンリッチ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/target-variables)​を参照してください。 ### [](#xpath-関数)XPath 関数 DataWeave では、​[セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して XML コンテンツを照会できますが、XML Module を使用することもできます。このモジュールは操作と関数の両方を公開して XPath クエリを実行します。 以下の例は、Mule 3 と 4 で、変数から取得された特定の単語を含む行を取得する方法を示しています。 Mule 3 の例 ```xml xpath3('//LINE[contains(.,$word)]',payload,'NODESET') ``` Mule 4 の例 ```xml ``` XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ### [](#ワイルドカード関数と正規表現関数)ワイルドカード関数と正規表現関数 DataWeave のマッチング関数 ​`match`​ と ​`matches`​ を代わりに使用できます (コア DataWeave 関数を参照してください)。次の例は、DataWeave で正規表現を使用して、​`wildcard`​ MEL 関数の使用を置き換える方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # MEL から DataWeave への移行 Mule 4 では Mule Expression Language (MEL) が DataWeave 式言語に要素に置き換わりました。 このセクションでは、Mule アプリケーションの MEL 式を DataWeave (2.0 以降) に移行するための指針を提供します。 ## [](#dataweave-の概要)DataWeave の概要 DataWeave は、単に値の参照と条件の評価を行う式言語として、または関数や再帰を含む複雑なデータ変換を作成するスクリプティング言語として使用できる Mule 固有の言語です。 MEL とは違い、JSON、XML、CSV など、さまざまなデータ型が標準でサポートされます。つまり、式を評価する前にデータを変更する必要がなくなりました。 また、関数のマッピングやデータの絞り込みなど、高度なユースケースもサポートされています。 DataWeave のメインデータセレクターは ​`.`​ 演算子であることに留意してください。 ほとんどキーワードは MEL と共有されるので、ほとんどのシナリオの構文は同じになります。たとえば、​`#[message.payload.name]`​ は両言語とも同じです。 MEL と DataWeave の主な違いは、DataWeave 式には副作用がないことです。DataWeave を使用してデータを抽出または生成できますが、データを変更することはできません。 それらのユースケースの対処法については、​[Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-java-integration)​の例を参照してください。 ## [](#mel-の使用法)MEL の使用法 以下のセクションでは、MEL の一部の使用法を Mule 4 に適応させる方法を説明します。 ### [](#コンテキスト変数へのアクセス)コンテキスト変数へのアクセス 次の変更を除き、DataWeave ではコンテキスト変数 (Mule Runtime 変数とも呼ばれる) は同じままです。
MEL DataWeave

フロー変数​

flowVars​

  • 例: #[flowVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

例外​

exception​

Mule エラー​:

error​

インバウンド添付ファイル​

message.inboundAttachments​

マルチパートデータ形式​

情報:

インバウンドプロパティ​

message.inboundProperties​

  • 例:

#[inboundProperties.'http.query.params']
#[inboundProperties]

Mule メッセージ属性​ (メタデータ)

attributes​

  • 例:

#[attributes.queryParams]
#[attributes.headers]

インバウンドプロパティが属性に​

アウトバウンド添付ファイル​

message.outboundAttachments​

マルチパートデータ形式​

情報:

アウトバウンドプロパティ​

message.outboundProperties​

削除:​

情報:

message.dataType

dataType​

message.id​、​message.rootId​、​message.replyTo

削除​

レコード変数​

recordVars​

  • 例: #[recordVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

セッション変数​

sessionVars​

  • 例: #[sessionVars.myVar]​

削除:​

トランスポートバリアーは Mule 4 には存在しません。情報:

server.dateTime​

削除:​

DataWeave ​now​ 関数を使用する。
### [](#extract_data)データの抽出 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して、MEL と同様にデータを照会できます。また、JSON などの型に対応するために、さらに変換を行う必要がありません。 以下の例では、次の JSON ペイロードの ID をログに記録します。 JSON ペイロード ```json { "name" : "Rachel Duncan", "id": "779H41" } ``` Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#値の割り当て)値の割り当て 前述のとおり、DataWeave では、MEL の ​`expression-component`​ で許可されていたようなデータの変更はサポートされていません。そのようなユースケースを実行するには、Scripting Module を使用する必要があります。 Java マップとして記述されている​[前述](#extract_data)​のペイロードを考えてみます。例では、​`name`​ 属性を変更します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml payload.put('name', 'R. Duncan') return payload ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ### [](#java-メソッドの呼び出し)Java メソッドの呼び出し DataWeave を使用して静的メソッドを呼び出すことができます。通常のメソッドの場合は Java Module を使用できます。このモジュールは操作と関数の両方を公開して Java メソッドを呼び出します。 #### [](#静的メソッド)静的メソッド 以下の例では、Java の Locale ​`getDefault`​ 静的メソッドを Mule 3 と Mule 4 で使用しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` DataWeave では、Java 静的メソッドが検索対象であることを示す ​`java!`​ プレフィックスと、完全修飾された (​`.`​ ではなく、​`::`​ 区切りの) クラス名が必要です。 #### [](#インスタンスメソッド)インスタンスメソッド 以下の例は、Mule 3 と Mule 4 での Java の String ​`equalsIgnoreCase`​ メソッドの使用法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` Java Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-java-module 1.0.0 mule-plugin ``` ### [](#対象の定義)対象の定義 `enricher`​ は削除されて、すべての操作でサポートされる対象変数に置き換わりました。以下の例は、Mule 3 と Mule 4 で操作の結果を変数に送信する方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` - 詳細は、​[「対象変数を使用したデータのエンリッチ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/target-variables)​を参照してください。 ### [](#xpath-関数)XPath 関数 DataWeave では、​[セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して XML コンテンツを照会できますが、XML Module を使用することもできます。このモジュールは操作と関数の両方を公開して XPath クエリを実行します。 以下の例は、Mule 3 と 4 で、変数から取得された特定の単語を含む行を取得する方法を示しています。 Mule 3 の例 ```xml xpath3('//LINE[contains(.,$word)]',payload,'NODESET') ``` Mule 4 の例 ```xml ``` XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ### [](#ワイルドカード関数と正規表現関数)ワイルドカード関数と正規表現関数 DataWeave のマッチング関数 ​`match`​ と ​`matches`​ を代わりに使用できます (コア DataWeave 関数を参照してください)。次の例は、DataWeave で正規表現を使用して、​`wildcard`​ MEL 関数の使用を置き換える方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # MEL から DataWeave への移行 Mule 4 では Mule Expression Language (MEL) が DataWeave 式言語に要素に置き換わりました。 このセクションでは、Mule アプリケーションの MEL 式を DataWeave (2.0 以降) に移行するための指針を提供します。 ## [](#dataweave-の概要)DataWeave の概要 DataWeave は、単に値の参照と条件の評価を行う式言語として、または関数や再帰を含む複雑なデータ変換を作成するスクリプティング言語として使用できる Mule 固有の言語です。 MEL とは違い、JSON、XML、CSV など、さまざまなデータ型が標準でサポートされます。つまり、式を評価する前にデータを変更する必要がなくなりました。 また、関数のマッピングやデータの絞り込みなど、高度なユースケースもサポートされています。 DataWeave のメインデータセレクターは ​`.`​ 演算子であることに留意してください。 ほとんどキーワードは MEL と共有されるので、ほとんどのシナリオの構文は同じになります。たとえば、​`#[message.payload.name]`​ は両言語とも同じです。 MEL と DataWeave の主な違いは、DataWeave 式には副作用がないことです。DataWeave を使用してデータを抽出または生成できますが、データを変更することはできません。 それらのユースケースの対処法については、​[Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-java-integration)​の例を参照してください。 ## [](#mel-の使用法)MEL の使用法 以下のセクションでは、MEL の一部の使用法を Mule 4 に適応させる方法を説明します。 ### [](#コンテキスト変数へのアクセス)コンテキスト変数へのアクセス 次の変更を除き、DataWeave ではコンテキスト変数 (Mule Runtime 変数とも呼ばれる) は同じままです。
MEL DataWeave

フロー変数​

flowVars​

  • 例: #[flowVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

例外​

exception​

Mule エラー​:

error​

インバウンド添付ファイル​

message.inboundAttachments​

マルチパートデータ形式​

情報:

インバウンドプロパティ​

message.inboundProperties​

  • 例:

#[inboundProperties.'http.query.params']
#[inboundProperties]

Mule メッセージ属性​ (メタデータ)

attributes​

  • 例:

#[attributes.queryParams]
#[attributes.headers]

インバウンドプロパティが属性に​

アウトバウンド添付ファイル​

message.outboundAttachments​

マルチパートデータ形式​

情報:

アウトバウンドプロパティ​

message.outboundProperties​

削除:​

情報:

message.dataType

dataType​

message.id​、​message.rootId​、​message.replyTo

削除​

レコード変数​

recordVars​

  • 例: #[recordVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

セッション変数​

sessionVars​

  • 例: #[sessionVars.myVar]​

削除:​

トランスポートバリアーは Mule 4 には存在しません。情報:

server.dateTime​

削除:​

DataWeave ​now​ 関数を使用する。
### [](#extract_data)データの抽出 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して、MEL と同様にデータを照会できます。また、JSON などの型に対応するために、さらに変換を行う必要がありません。 以下の例では、次の JSON ペイロードの ID をログに記録します。 JSON ペイロード ```json { "name" : "Rachel Duncan", "id": "779H41" } ``` Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#値の割り当て)値の割り当て 前述のとおり、DataWeave では、MEL の ​`expression-component`​ で許可されていたようなデータの変更はサポートされていません。そのようなユースケースを実行するには、Scripting Module を使用する必要があります。 Java マップとして記述されている​[前述](#extract_data)​のペイロードを考えてみます。例では、​`name`​ 属性を変更します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml payload.put('name', 'R. Duncan') return payload ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ### [](#java-メソッドの呼び出し)Java メソッドの呼び出し DataWeave を使用して静的メソッドを呼び出すことができます。通常のメソッドの場合は Java Module を使用できます。このモジュールは操作と関数の両方を公開して Java メソッドを呼び出します。 #### [](#静的メソッド)静的メソッド 以下の例では、Java の Locale ​`getDefault`​ 静的メソッドを Mule 3 と Mule 4 で使用しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` DataWeave では、Java 静的メソッドが検索対象であることを示す ​`java!`​ プレフィックスと、完全修飾された (​`.`​ ではなく、​`::`​ 区切りの) クラス名が必要です。 #### [](#インスタンスメソッド)インスタンスメソッド 以下の例は、Mule 3 と Mule 4 での Java の String ​`equalsIgnoreCase`​ メソッドの使用法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` Java Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-java-module 1.0.0 mule-plugin ``` ### [](#対象の定義)対象の定義 `enricher`​ は削除されて、すべての操作でサポートされる対象変数に置き換わりました。以下の例は、Mule 3 と Mule 4 で操作の結果を変数に送信する方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` - 詳細は、​[「対象変数を使用したデータのエンリッチ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/target-variables)​を参照してください。 ### [](#xpath-関数)XPath 関数 DataWeave では、​[セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して XML コンテンツを照会できますが、XML Module を使用することもできます。このモジュールは操作と関数の両方を公開して XPath クエリを実行します。 以下の例は、Mule 3 と 4 で、変数から取得された特定の単語を含む行を取得する方法を示しています。 Mule 3 の例 ```xml xpath3('//LINE[contains(.,$word)]',payload,'NODESET') ``` Mule 4 の例 ```xml ``` XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ### [](#ワイルドカード関数と正規表現関数)ワイルドカード関数と正規表現関数 DataWeave のマッチング関数 ​`match`​ と ​`matches`​ を代わりに使用できます (コア DataWeave 関数を参照してください)。次の例は、DataWeave で正規表現を使用して、​`wildcard`​ MEL 関数の使用を置き換える方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # MEL から DataWeave への移行 Mule 4 では Mule Expression Language (MEL) が DataWeave 式言語に要素に置き換わりました。 このセクションでは、Mule アプリケーションの MEL 式を DataWeave (2.0 以降) に移行するための指針を提供します。 ## [](#dataweave-の概要)DataWeave の概要 DataWeave は、単に値の参照と条件の評価を行う式言語として、または関数や再帰を含む複雑なデータ変換を作成するスクリプティング言語として使用できる Mule 固有の言語です。 MEL とは違い、JSON、XML、CSV など、さまざまなデータ型が標準でサポートされます。つまり、式を評価する前にデータを変更する必要がなくなりました。 また、関数のマッピングやデータの絞り込みなど、高度なユースケースもサポートされています。 DataWeave のメインデータセレクターは ​`.`​ 演算子であることに留意してください。 ほとんどキーワードは MEL と共有されるので、ほとんどのシナリオの構文は同じになります。たとえば、​`#[message.payload.name]`​ は両言語とも同じです。 MEL と DataWeave の主な違いは、DataWeave 式には副作用がないことです。DataWeave を使用してデータを抽出または生成できますが、データを変更することはできません。 それらのユースケースの対処法については、​[Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-java-integration)​の例を参照してください。 ## [](#mel-の使用法)MEL の使用法 以下のセクションでは、MEL の一部の使用法を Mule 4 に適応させる方法を説明します。 ### [](#コンテキスト変数へのアクセス)コンテキスト変数へのアクセス 次の変更を除き、DataWeave ではコンテキスト変数 (Mule Runtime 変数とも呼ばれる) は同じままです。
MEL DataWeave

フロー変数​

flowVars​

  • 例: #[flowVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

例外​

exception​

Mule エラー​:

error​

インバウンド添付ファイル​

message.inboundAttachments​

マルチパートデータ形式​

情報:

インバウンドプロパティ​

message.inboundProperties​

  • 例:

#[inboundProperties.'http.query.params']
#[inboundProperties]

Mule メッセージ属性​ (メタデータ)

attributes​

  • 例:

#[attributes.queryParams]
#[attributes.headers]

インバウンドプロパティが属性に​

アウトバウンド添付ファイル​

message.outboundAttachments​

マルチパートデータ形式​

情報:

アウトバウンドプロパティ​

message.outboundProperties​

削除:​

情報:

message.dataType

dataType​

message.id​、​message.rootId​、​message.replyTo

削除​

レコード変数​

recordVars​

  • 例: #[recordVars.myVar]​

Mule イベント変数​

vars​

  • 例: #[vars.myVar]​

セッション変数​

sessionVars​

  • 例: #[sessionVars.myVar]​

削除:​

トランスポートバリアーは Mule 4 には存在しません。情報:

server.dateTime​

削除:​

DataWeave ​now​ 関数を使用する。
### [](#extract_data)データの抽出 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して、MEL と同様にデータを照会できます。また、JSON などの型に対応するために、さらに変換を行う必要がありません。 以下の例では、次の JSON ペイロードの ID をログに記録します。 JSON ペイロード ```json { "name" : "Rachel Duncan", "id": "779H41" } ``` Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ### [](#値の割り当て)値の割り当て 前述のとおり、DataWeave では、MEL の ​`expression-component`​ で許可されていたようなデータの変更はサポートされていません。そのようなユースケースを実行するには、Scripting Module を使用する必要があります。 Java マップとして記述されている​[前述](#extract_data)​のペイロードを考えてみます。例では、​`name`​ 属性を変更します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml payload.put('name', 'R. Duncan') return payload ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ### [](#java-メソッドの呼び出し)Java メソッドの呼び出し DataWeave を使用して静的メソッドを呼び出すことができます。通常のメソッドの場合は Java Module を使用できます。このモジュールは操作と関数の両方を公開して Java メソッドを呼び出します。 #### [](#静的メソッド)静的メソッド 以下の例では、Java の Locale ​`getDefault`​ 静的メソッドを Mule 3 と Mule 4 で使用しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` DataWeave では、Java 静的メソッドが検索対象であることを示す ​`java!`​ プレフィックスと、完全修飾された (​`.`​ ではなく、​`::`​ 区切りの) クラス名が必要です。 #### [](#インスタンスメソッド)インスタンスメソッド 以下の例は、Mule 3 と Mule 4 での Java の String ​`equalsIgnoreCase`​ メソッドの使用法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` Java Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-java-module 1.0.0 mule-plugin ``` ### [](#対象の定義)対象の定義 `enricher`​ は削除されて、すべての操作でサポートされる対象変数に置き換わりました。以下の例は、Mule 3 と Mule 4 で操作の結果を変数に送信する方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` - 詳細は、​[「対象変数を使用したデータのエンリッチ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/target-variables)​を参照してください。 ### [](#xpath-関数)XPath 関数 DataWeave では、​[セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)​を使用して XML コンテンツを照会できますが、XML Module を使用することもできます。このモジュールは操作と関数の両方を公開して XPath クエリを実行します。 以下の例は、Mule 3 と 4 で、変数から取得された特定の単語を含む行を取得する方法を示しています。 Mule 3 の例 ```xml xpath3('//LINE[contains(.,$word)]',payload,'NODESET') ``` Mule 4 の例 ```xml ``` XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ### [](#ワイルドカード関数と正規表現関数)ワイルドカード関数と正規表現関数 DataWeave のマッチング関数 ​`match`​ と ​`matches`​ を代わりに使用できます (コア DataWeave 関数を参照してください)。次の例は、DataWeave で正規表現を使用して、​`wildcard`​ MEL 関数の使用を置き換える方法を示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) - MEL 式から DataWeave 2.x (2.1?) へ - 事前プランでは、Mule 3 ドキュメントの例を引用し、それらの 4.0 への移行方法を示します。​[https://docs.mulesoft.com/mule-user-guide/v/3.9/mule-expression-language-mel](https://docs.mulesoft.com/mule-user-guide/v/3.9/mule-expression-language-mel) を参照してください。 - 3 つの主なユースケース (Dan Feist): - メッセージの値の抽出 (ログ記録や単純な変換など)。 例: - `#[payload]`​ はDW と同じです。 - `[message.payload]`​ から DW へ: `[payload]` //**\*** **TODO**: `[message.inboundProperties.'propertyName']` to DW: `[attributes.'propertyName']` - `[]`​ はDW と同じです。 - 条件の評価 (検証やルーティングなどで使用) - `#[payload.age > 21]`​ は DW と同じです。 - 対象を定義: - Dan は、「主に 4.0 でサポートされなくなったエンリッチャーでのみ使用されていました」と述べます。これは​[移行パターン](#migration-patterns.adoc)​でカバーされるようです。 - `#[flowVars.output]`​ は対象変数で処理されるようになりました。以前のリンクを参照してください。 4.0 では代わりに対象変数が使用されます MEL 式 + \+ .DataWeave 式 # Mule 3 から Mule 4 への移行早見表 Mule 3 から Mule 4 に移行しやすくなるように、Mule 3 のごく一般的なユースケースに対応する Mule 4 のユースケースを見つけるためのインデックスを作成しました。 **IMPORTANT:**​ このインデックスは、ごく一般的な移行シナリオの出発点にすることを目的としています。移行の完全ガイドではありません。Mule の​[「Mule 4 for Mule 3 Users (Mule 3 ユーザーのための Mule 4)」](https://docs.mulesoft.com/jp/mule-runtime/4.3/index-migration)​ページに、移行に関するすべての記事が掲載されています。 - [設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties)​: Mule 4 では設定プロパティを新たな方法で処理します。 - [セキュアプロパティの使用](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-secure-properties-placeholder)​: セキュアプレースホルダーが Runtime の機能になり、Security モジュールの一部ではなくなりました。 - [HTTP Connector の使用](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-connectors-http)​: 新しい HTTP Connector は、マルチパート/フォーム要求の処理をはじめ、いくつかの点が Mule 3 と異なります。 - [MEL から DataWeave への切り替え](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-mel)​: DataWeave 2.0 が式言語になりました。ここに MEL 式を DataWeave に適合させる方法が記載されています。 - [DataWeave 1.0 から DataWeave 2.0 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-dataweave)​: Mule 4 では DataWeave の新バージョンを使用できます。 - 明示的なトランスフォーマーはどこにいったのかと思うかもしれませんが、​``​ や ​``​ のようなトランスフォーマーは不要になりました。こうした変換は、Mule がバックグラウンドで自動的に処理します。 - [カスタムオブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os)​: カスタムオブジェクトストアが新しいコネクタを使用して定義されるようになりました。 - [ウォーターマークの使用](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-patterns-watermark)​: ウォーターマークが簡素化されました。手動で実行できるようになったため、複雑なユースケースにも対応できます。 - [Mule メッセージへのアクセス](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-message-properties)​: Mule メッセージの構造が刷新され、アクセス方法が変更されました。ここで概要を確認できます。 - Java の使用: [Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​ を使用して Java と相互運用できるようになりました。必要に応じて、​[Scripting Module](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-module-scripting)​ や ​[Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使ってみることもできます。 - [Spring の使用](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-module-spring)​: Spring bean をアプリケーションで直接定義する代わりに、​[Spring Module](https://docs.mulesoft.com/spring-module/latest/)​ を使用できるようになりました。 - [再接続戦略の使用](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-patterns-reconnection-strategies)​: Mule 4 では、再接続に些細ながら重要な違いがあります。 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-classloading-isolation)​: クラスローディング分離により、リソースやクラスの共有方法が変化します。詳細は、この記事を参照してください。 - [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-core)​: コア言語要素に実施された変更の包括的なリストです。 - [新しいコネクタの使用](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-connectors)​: 主要なコネクタに実施された変更の包括的なリストです。 - [Security (AES) モジュールの使用](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-aes)​: Anypoint Enterprise Security モジュールが、ここに記載の各種のモジュールに分割されました。 - [ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-api-gateways)​: このセクションに、API ゲートウェイに関連する機能の移行について説明されています。 - [APIkit アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-example-complex)​: APIkit ベースのアプリケーションを効率的に移行するために必要な手順を説明します。 - カスタムコンポーネントの移行: [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して再利用可能な独自のコンポーネントを作成できます。 - DevKit ベースのコンポーネントの移行: [DevKit 移行ツール](#mule-sdk::dmt.adoc)​で、Mule 3 の DevKit プロジェクトを Mule SDK プロジェクトに移行できます。 - [トランスポートサービスの上書き](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-transports)​: 汎用的なトランスポートから移行する方法を説明します。 - [mule-high-availability-ha-clusters.adoc#configure-the-performance-profile](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-high-availability-ha-clusters#configure-the-performance-profile): コンテナレベルで、プロパティを ​`mule.clusterPartitioningMode=OPTIMIZE_PERFORMANCE`​ から ​`mule.cluster.storeprofile=performance`​ に変更します。個別のアプリケーションレベルで、特定の Mule アプリケーションのストアプロファイルを設定できます。 # Mule 3 から Mule 4 への移行早見表 Mule 3 から Mule 4 に移行しやすくなるように、Mule 3 のごく一般的なユースケースに対応する Mule 4 のユースケースを見つけるためのインデックスを作成しました。 **IMPORTANT:**​ このインデックスは、ごく一般的な移行シナリオの出発点にすることを目的としています。移行の完全ガイドではありません。Mule の​[「Mule 4 for Mule 3 Users (Mule 3 ユーザーのための Mule 4)」](https://docs.mulesoft.com/jp/mule-runtime/4.4/index-migration)​ページに、移行に関するすべての記事が掲載されています。 - [設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties)​: Mule 4 では設定プロパティを新たな方法で処理します。 - [セキュアプロパティの使用](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-secure-properties-placeholder)​: セキュアプレースホルダーが Runtime の機能になり、Security モジュールの一部ではなくなりました。 - [HTTP Connector の使用](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-connectors-http)​: 新しい HTTP Connector は、マルチパート/フォーム要求の処理をはじめ、いくつかの点が Mule 3 と異なります。 - [MEL から DataWeave への切り替え](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-mel)​: DataWeave 2.0 が式言語になりました。ここに MEL 式を DataWeave に適合させる方法が記載されています。 - [DataWeave 1.0 から DataWeave 2.0 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-dataweave)​: Mule 4 では DataWeave の新バージョンを使用できます。 - 明示的なトランスフォーマーはどこにいったのかと思うかもしれませんが、​``​ や ​``​ のようなトランスフォーマーは不要になりました。こうした変換は、Mule がバックグラウンドで自動的に処理します。 - [カスタムオブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os)​: カスタムオブジェクトストアが新しいコネクタを使用して定義されるようになりました。 - [ウォーターマークの使用](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-patterns-watermark)​: ウォーターマークが簡素化されました。手動で実行できるようになったため、複雑なユースケースにも対応できます。 - [Mule メッセージへのアクセス](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-message-properties)​: Mule メッセージの構造が刷新され、アクセス方法が変更されました。ここで概要を確認できます。 - Java の使用: [Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​ を使用して Java と相互運用できるようになりました。必要に応じて、​[Scripting Module](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-module-scripting)​ や ​[Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使ってみることもできます。 - [Spring の使用](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-module-spring)​: Spring bean をアプリケーションで直接定義する代わりに、​[Spring Module](https://docs.mulesoft.com/spring-module/latest/)​ を使用できるようになりました。 - [再接続戦略の使用](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-patterns-reconnection-strategies)​: Mule 4 では、再接続に些細ながら重要な違いがあります。 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-classloading-isolation)​: クラスローディング分離により、リソースやクラスの共有方法が変化します。詳細は、この記事を参照してください。 - [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-core)​: コア言語要素に実施された変更の包括的なリストです。 - [新しいコネクタの使用](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-connectors)​: 主要なコネクタに実施された変更の包括的なリストです。 - [Security (AES) モジュールの使用](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-aes)​: Anypoint Enterprise Security モジュールが、ここに記載の各種のモジュールに分割されました。 - [ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-api-gateways)​: このセクションに、API ゲートウェイに関連する機能の移行について説明されています。 - [APIkit アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-example-complex)​: APIkit ベースのアプリケーションを効率的に移行するために必要な手順を説明します。 - カスタムコンポーネントの移行: [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して再利用可能な独自のコンポーネントを作成できます。 - DevKit ベースのコンポーネントの移行: [DevKit 移行ツール](#mule-sdk::dmt.adoc)​で、Mule 3 の DevKit プロジェクトを Mule SDK プロジェクトに移行できます。 - [トランスポートサービスの上書き](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-transports)​: 汎用的なトランスポートから移行する方法を説明します。 - [mule-high-availability-ha-clusters.adoc#configure-the-performance-profile](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-high-availability-ha-clusters#configure-the-performance-profile): コンテナレベルで、プロパティを ​`mule.clusterPartitioningMode=OPTIMIZE_PERFORMANCE`​ から ​`mule.cluster.storeprofile=performance`​ に変更します。個別のアプリケーションレベルで、特定の Mule アプリケーションのストアプロファイルを設定できます。 # Mule 3 から Mule 4 への移行早見表 Mule 3 から Mule 4 に移行しやすくなるように、Mule 3 のごく一般的なユースケースに対応する Mule 4 のユースケースを見つけるためのインデックスを作成しました。 **IMPORTANT:**​ このインデックスは、ごく一般的な移行シナリオの出発点にすることを目的としています。移行の完全ガイドではありません。Mule の​[「Mule 4 for Mule 3 Users (Mule 3 ユーザーのための Mule 4)」](https://docs.mulesoft.com/jp/mule-runtime/4.5/index-migration)​ページに、移行に関するすべての記事が掲載されています。 - [設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties)​: Mule 4 では設定プロパティを新たな方法で処理します。 - [セキュアプロパティの使用](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-secure-properties-placeholder)​: セキュアプレースホルダーが Runtime の機能になり、Security モジュールの一部ではなくなりました。 - [HTTP Connector の使用](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-connectors-http)​: 新しい HTTP Connector は、マルチパート/フォーム要求の処理をはじめ、いくつかの点が Mule 3 と異なります。 - [MEL から DataWeave への切り替え](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-mel)​: DataWeave 2.0 が式言語になりました。ここに MEL 式を DataWeave に適合させる方法が記載されています。 - [DataWeave 1.0 から DataWeave 2.0 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-dataweave)​: Mule 4 では DataWeave の新バージョンを使用できます。 - 明示的なトランスフォーマーはどこにいったのかと思うかもしれませんが、​``​ や ​``​ のようなトランスフォーマーは不要になりました。こうした変換は、Mule がバックグラウンドで自動的に処理します。 - [カスタムオブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os)​: カスタムオブジェクトストアが新しいコネクタを使用して定義されるようになりました。 - [ウォーターマークの使用](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-patterns-watermark)​: ウォーターマークが簡素化されました。手動で実行できるようになったため、複雑なユースケースにも対応できます。 - [Mule メッセージへのアクセス](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-message-properties)​: Mule メッセージの構造が刷新され、アクセス方法が変更されました。ここで概要を確認できます。 - Java の使用: [Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​ を使用して Java と相互運用できるようになりました。必要に応じて、​[Scripting Module](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-module-scripting)​ や ​[Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使ってみることもできます。 - [Spring の使用](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-module-spring)​: Spring bean をアプリケーションで直接定義する代わりに、​[Spring Module](https://docs.mulesoft.com/spring-module/latest/)​ を使用できるようになりました。 - [再接続戦略の使用](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-patterns-reconnection-strategies)​: Mule 4 では、再接続に些細ながら重要な違いがあります。 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-classloading-isolation)​: クラスローディング分離により、リソースやクラスの共有方法が変化します。詳細は、この記事を参照してください。 - [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-core)​: コア言語要素に実施された変更の包括的なリストです。 - [新しいコネクタの使用](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-connectors)​: 主要なコネクタに実施された変更の包括的なリストです。 - [Security (AES) モジュールの使用](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-aes)​: Anypoint Enterprise Security モジュールが、ここに記載の各種のモジュールに分割されました。 - [ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-api-gateways)​: このセクションに、API ゲートウェイに関連する機能の移行について説明されています。 - [APIkit アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-example-complex)​: APIkit ベースのアプリケーションを効率的に移行するために必要な手順を説明します。 - カスタムコンポーネントの移行: [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して再利用可能な独自のコンポーネントを作成できます。 - DevKit ベースのコンポーネントの移行: [DevKit 移行ツール](#mule-sdk::dmt.adoc)​で、Mule 3 の DevKit プロジェクトを Mule SDK プロジェクトに移行できます。 - [トランスポートサービスの上書き](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-transports)​: 汎用的なトランスポートから移行する方法を説明します。 - [mule-high-availability-ha-clusters.adoc#configure-the-performance-profile](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-high-availability-ha-clusters#configure-the-performance-profile): コンテナレベルで、プロパティを ​`mule.clusterPartitioningMode=OPTIMIZE_PERFORMANCE`​ から ​`mule.cluster.storeprofile=performance`​ に変更します。個別のアプリケーションレベルで、特定の Mule アプリケーションのストアプロファイルを設定できます。 # Mule 3 から Mule 4 への移行早見表 Mule 3 から Mule 4 に移行しやすくなるように、Mule 3 のごく一般的なユースケースに対応する Mule 4 のユースケースを見つけるためのインデックスを作成しました。 **IMPORTANT:**​ このインデックスは、ごく一般的な移行シナリオの出発点にすることを目的としています。移行の完全ガイドではありません。Mule の​[「Mule 4 for Mule 3 Users (Mule 3 ユーザーのための Mule 4)」](https://docs.mulesoft.com/jp/mule-runtime/4.6/index-migration)​ページに、移行に関するすべての記事が掲載されています。 - [設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties)​: Mule 4 では設定プロパティを新たな方法で処理します。 - [セキュアプロパティの使用](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-secure-properties-placeholder)​: セキュアプレースホルダーが Runtime の機能になり、Security モジュールの一部ではなくなりました。 - [HTTP Connector の使用](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-connectors-http)​: 新しい HTTP Connector は、マルチパート/フォーム要求の処理をはじめ、いくつかの点が Mule 3 と異なります。 - [MEL から DataWeave への切り替え](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-mel)​: DataWeave 2.0 が式言語になりました。ここに MEL 式を DataWeave に適合させる方法が記載されています。 - [DataWeave 1.0 から DataWeave 2.0 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-dataweave)​: Mule 4 では DataWeave の新バージョンを使用できます。 - 明示的なトランスフォーマーはどこにいったのかと思うかもしれませんが、​``​ や ​``​ のようなトランスフォーマーは不要になりました。こうした変換は、Mule がバックグラウンドで自動的に処理します。 - [カスタムオブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os)​: カスタムオブジェクトストアが新しいコネクタを使用して定義されるようになりました。 - [ウォーターマークの使用](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-patterns-watermark)​: ウォーターマークが簡素化されました。手動で実行できるようになったため、複雑なユースケースにも対応できます。 - [Mule メッセージへのアクセス](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-message-properties)​: Mule メッセージの構造が刷新され、アクセス方法が変更されました。ここで概要を確認できます。 - Java の使用: [Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​ を使用して Java と相互運用できるようになりました。必要に応じて、​[Scripting Module](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-module-scripting)​ や ​[Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使ってみることもできます。 - [Spring の使用](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-module-spring)​: Spring bean をアプリケーションで直接定義する代わりに、​[Spring Module](https://docs.mulesoft.com/spring-module/latest/)​ を使用できるようになりました。 - [再接続戦略の使用](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-patterns-reconnection-strategies)​: Mule 4 では、再接続に些細ながら重要な違いがあります。 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-classloading-isolation)​: クラスローディング分離により、リソースやクラスの共有方法が変化します。詳細は、この記事を参照してください。 - [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-core)​: コア言語要素に実施された変更の包括的なリストです。 - [新しいコネクタの使用](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-connectors)​: 主要なコネクタに実施された変更の包括的なリストです。 - [Security (AES) モジュールの使用](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-aes)​: Anypoint Enterprise Security モジュールが、ここに記載の各種のモジュールに分割されました。 - [ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-api-gateways)​: このセクションに、API ゲートウェイに関連する機能の移行について説明されています。 - [APIkit アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-example-complex)​: APIkit ベースのアプリケーションを効率的に移行するために必要な手順を説明します。 - カスタムコンポーネントの移行: [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して再利用可能な独自のコンポーネントを作成できます。 - DevKit ベースのコンポーネントの移行: [DevKit 移行ツール](#mule-sdk::dmt.adoc)​で、Mule 3 の DevKit プロジェクトを Mule SDK プロジェクトに移行できます。 - [トランスポートサービスの上書き](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-transports)​: 汎用的なトランスポートから移行する方法を説明します。 - [mule-high-availability-ha-clusters.adoc#configure-the-performance-profile](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-high-availability-ha-clusters#configure-the-performance-profile): コンテナレベルで、プロパティを ​`mule.clusterPartitioningMode=OPTIMIZE_PERFORMANCE`​ から ​`mule.cluster.storeprofile=performance`​ に変更します。個別のアプリケーションレベルで、特定の Mule アプリケーションのストアプロファイルを設定できます。 # Mule 3 から Mule 4 への移行早見表 Mule 3 から Mule 4 に移行しやすくなるように、Mule 3 のごく一般的なユースケースに対応する Mule 4 のユースケースを見つけるためのインデックスを作成しました。 **IMPORTANT:**​ このインデックスは、ごく一般的な移行シナリオの出発点にすることを目的としています。移行の完全ガイドではありません。Mule の​[「Mule 4 for Mule 3 Users (Mule 3 ユーザーのための Mule 4)」](https://docs.mulesoft.com/jp/mule-runtime/4.7/index-migration)​ページに、移行に関するすべての記事が掲載されています。 - [設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties)​: Mule 4 では設定プロパティを新たな方法で処理します。 - [セキュアプロパティの使用](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-secure-properties-placeholder)​: セキュアプレースホルダーが Runtime の機能になり、Security モジュールの一部ではなくなりました。 - [HTTP Connector の使用](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-connectors-http)​: 新しい HTTP Connector は、マルチパート/フォーム要求の処理をはじめ、いくつかの点が Mule 3 と異なります。 - [MEL から DataWeave への切り替え](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-mel)​: DataWeave 2.0 が式言語になりました。ここに MEL 式を DataWeave に適合させる方法が記載されています。 - [DataWeave 1.0 から DataWeave 2.0 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-dataweave)​: Mule 4 では DataWeave の新バージョンを使用できます。 - 明示的なトランスフォーマーはどこにいったのかと思うかもしれませんが、​``​ や ​``​ のようなトランスフォーマーは不要になりました。こうした変換は、Mule がバックグラウンドで自動的に処理します。 - [カスタムオブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os)​: カスタムオブジェクトストアが新しいコネクタを使用して定義されるようになりました。 - [ウォーターマークの使用](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-patterns-watermark)​: ウォーターマークが簡素化されました。手動で実行できるようになったため、複雑なユースケースにも対応できます。 - [Mule メッセージへのアクセス](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-message-properties)​: Mule メッセージの構造が刷新され、アクセス方法が変更されました。ここで概要を確認できます。 - Java の使用: [Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​ を使用して Java と相互運用できるようになりました。必要に応じて、​[Scripting Module](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-module-scripting)​ や ​[Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使ってみることもできます。 - [Spring の使用](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-module-spring)​: Spring bean をアプリケーションで直接定義する代わりに、​[Spring Module](https://docs.mulesoft.com/spring-module/latest/)​ を使用できるようになりました。 - [再接続戦略の使用](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-patterns-reconnection-strategies)​: Mule 4 では、再接続に些細ながら重要な違いがあります。 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-classloading-isolation)​: クラスローディング分離により、リソースやクラスの共有方法が変化します。詳細は、この記事を参照してください。 - [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-core)​: コア言語要素に実施された変更の包括的なリストです。 - [新しいコネクタの使用](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-connectors)​: 主要なコネクタに実施された変更の包括的なリストです。 - [Security (AES) モジュールの使用](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-aes)​: Anypoint Enterprise Security モジュールが、ここに記載の各種のモジュールに分割されました。 - [ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-api-gateways)​: このセクションに、API ゲートウェイに関連する機能の移行について説明されています。 - [APIkit アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-example-complex)​: APIkit ベースのアプリケーションを効率的に移行するために必要な手順を説明します。 - カスタムコンポーネントの移行: [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して再利用可能な独自のコンポーネントを作成できます。 - DevKit ベースのコンポーネントの移行: [DevKit 移行ツール](#mule-sdk::dmt.adoc)​で、Mule 3 の DevKit プロジェクトを Mule SDK プロジェクトに移行できます。 - [トランスポートサービスの上書き](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-transports)​: 汎用的なトランスポートから移行する方法を説明します。 - [mule-high-availability-ha-clusters.adoc#configure-the-performance-profile](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-high-availability-ha-clusters#configure-the-performance-profile): コンテナレベルで、プロパティを ​`mule.clusterPartitioningMode=OPTIMIZE_PERFORMANCE`​ から ​`mule.cluster.storeprofile=performance`​ に変更します。個別のアプリケーションレベルで、特定の Mule アプリケーションのストアプロファイルを設定できます。 # Mule 3 から Mule 4 への移行早見表 Mule 3 から Mule 4 に移行しやすくなるように、Mule 3 のごく一般的なユースケースに対応する Mule 4 のユースケースを見つけるためのインデックスを作成しました。 **IMPORTANT:**​ このインデックスは、ごく一般的な移行シナリオの出発点にすることを目的としています。移行の完全ガイドではありません。Mule の​[「Mule 4 for Mule 3 Users (Mule 3 ユーザーのための Mule 4)」](https://docs.mulesoft.com/jp/mule-runtime/4.8/index-migration)​ページに、移行に関するすべての記事が掲載されています。 - [設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties)​: Mule 4 では設定プロパティを新たな方法で処理します。 - [セキュアプロパティの使用](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-secure-properties-placeholder)​: セキュアプレースホルダーが Runtime の機能になり、Security モジュールの一部ではなくなりました。 - [HTTP Connector の使用](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-connectors-http)​: 新しい HTTP Connector は、マルチパート/フォーム要求の処理をはじめ、いくつかの点が Mule 3 と異なります。 - [MEL から DataWeave への切り替え](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-mel)​: DataWeave 2.0 が式言語になりました。ここに MEL 式を DataWeave に適合させる方法が記載されています。 - [DataWeave 1.0 から DataWeave 2.0 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-dataweave)​: Mule 4 では DataWeave の新バージョンを使用できます。 - 明示的なトランスフォーマーはどこにいったのかと思うかもしれませんが、​``​ や ​``​ のようなトランスフォーマーは不要になりました。こうした変換は、Mule がバックグラウンドで自動的に処理します。 - [カスタムオブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os)​: カスタムオブジェクトストアが新しいコネクタを使用して定義されるようになりました。 - [ウォーターマークの使用](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-patterns-watermark)​: ウォーターマークが簡素化されました。手動で実行できるようになったため、複雑なユースケースにも対応できます。 - [Mule メッセージへのアクセス](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-message-properties)​: Mule メッセージの構造が刷新され、アクセス方法が変更されました。ここで概要を確認できます。 - Java の使用: [Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​ を使用して Java と相互運用できるようになりました。必要に応じて、​[Scripting Module](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-module-scripting)​ や ​[Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使ってみることもできます。 - [Spring の使用](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-module-spring)​: Spring bean をアプリケーションで直接定義する代わりに、​[Spring Module](https://docs.mulesoft.com/spring-module/latest/)​ を使用できるようになりました。 - [再接続戦略の使用](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-patterns-reconnection-strategies)​: Mule 4 では、再接続に些細ながら重要な違いがあります。 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-classloading-isolation)​: クラスローディング分離により、リソースやクラスの共有方法が変化します。詳細は、この記事を参照してください。 - [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-core)​: コア言語要素に実施された変更の包括的なリストです。 - [新しいコネクタの使用](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-connectors)​: 主要なコネクタに実施された変更の包括的なリストです。 - [Security (AES) モジュールの使用](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-aes)​: Anypoint Enterprise Security モジュールが、ここに記載の各種のモジュールに分割されました。 - [ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-api-gateways)​: このセクションに、API ゲートウェイに関連する機能の移行について説明されています。 - [APIkit アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-example-complex)​: APIkit ベースのアプリケーションを効率的に移行するために必要な手順を説明します。 - カスタムコンポーネントの移行: [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して再利用可能な独自のコンポーネントを作成できます。 - DevKit ベースのコンポーネントの移行: [DevKit 移行ツール](#mule-sdk::dmt.adoc)​で、Mule 3 の DevKit プロジェクトを Mule SDK プロジェクトに移行できます。 - [トランスポートサービスの上書き](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-transports)​: 汎用的なトランスポートから移行する方法を説明します。 - [mule-high-availability-ha-clusters.adoc#configure-the-performance-profile](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-high-availability-ha-clusters#configure-the-performance-profile): コンテナレベルで、プロパティを ​`mule.clusterPartitioningMode=OPTIMIZE_PERFORMANCE`​ から ​`mule.cluster.storeprofile=performance`​ に変更します。個別のアプリケーションレベルで、特定の Mule アプリケーションのストアプロファイルを設定できます。 # Mule 3 から Mule 4 への移行早見表 Mule 3 から Mule 4 に移行しやすくなるように、Mule 3 のごく一般的なユースケースに対応する Mule 4 のユースケースを見つけるためのインデックスを作成しました。 **IMPORTANT:**​ このインデックスは、ごく一般的な移行シナリオの出発点にすることを目的としています。移行の完全ガイドではありません。Mule の​[「Mule 4 for Mule 3 Users (Mule 3 ユーザーのための Mule 4)」](https://docs.mulesoft.com/jp/mule-runtime/4.9/index-migration)​ページに、移行に関するすべての記事が掲載されています。 - [設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties)​: Mule 4 では設定プロパティを新たな方法で処理します。 - [セキュアプロパティの使用](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-secure-properties-placeholder)​: セキュアプレースホルダーが Runtime の機能になり、Security モジュールの一部ではなくなりました。 - [HTTP Connector の使用](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-connectors-http)​: 新しい HTTP Connector は、マルチパート/フォーム要求の処理をはじめ、いくつかの点が Mule 3 と異なります。 - [MEL から DataWeave への切り替え](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-mel)​: DataWeave 2.0 が式言語になりました。ここに MEL 式を DataWeave に適合させる方法が記載されています。 - [DataWeave 1.0 から DataWeave 2.0 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-dataweave)​: Mule 4 では DataWeave の新バージョンを使用できます。 - 明示的なトランスフォーマーはどこにいったのかと思うかもしれませんが、​``​ や ​``​ のようなトランスフォーマーは不要になりました。こうした変換は、Mule がバックグラウンドで自動的に処理します。 - [カスタムオブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os)​: カスタムオブジェクトストアが新しいコネクタを使用して定義されるようになりました。 - [ウォーターマークの使用](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-patterns-watermark)​: ウォーターマークが簡素化されました。手動で実行できるようになったため、複雑なユースケースにも対応できます。 - [Mule メッセージへのアクセス](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-message-properties)​: Mule メッセージの構造が刷新され、アクセス方法が変更されました。ここで概要を確認できます。 - Java の使用: [Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​ を使用して Java と相互運用できるようになりました。必要に応じて、​[Scripting Module](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-module-scripting)​ や ​[Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使ってみることもできます。 - [Spring の使用](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-module-spring)​: Spring bean をアプリケーションで直接定義する代わりに、​[Spring Module](https://docs.mulesoft.com/spring-module/latest/)​ を使用できるようになりました。 - [再接続戦略の使用](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-patterns-reconnection-strategies)​: Mule 4 では、再接続に些細ながら重要な違いがあります。 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-classloading-isolation)​: クラスローディング分離により、リソースやクラスの共有方法が変化します。詳細は、この記事を参照してください。 - [コアコンポーネントの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-core)​: コア言語要素に実施された変更の包括的なリストです。 - [新しいコネクタの使用](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-connectors)​: 主要なコネクタに実施された変更の包括的なリストです。 - [Security (AES) モジュールの使用](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-aes)​: Anypoint Enterprise Security モジュールが、ここに記載の各種のモジュールに分割されました。 - [ゲートウェイの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-api-gateways)​: このセクションに、API ゲートウェイに関連する機能の移行について説明されています。 - [APIkit アプリケーションの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-example-complex)​: APIkit ベースのアプリケーションを効率的に移行するために必要な手順を説明します。 - カスタムコンポーネントの移行: [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して再利用可能な独自のコンポーネントを作成できます。 - DevKit ベースのコンポーネントの移行: [DevKit 移行ツール](#mule-sdk::dmt.adoc)​で、Mule 3 の DevKit プロジェクトを Mule SDK プロジェクトに移行できます。 - [トランスポートサービスの上書き](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-transports)​: 汎用的なトランスポートから移行する方法を説明します。 - [mule-high-availability-ha-clusters.adoc#configure-the-performance-profile](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-high-availability-ha-clusters#configure-the-performance-profile): コンテナレベルで、プロパティを ​`mule.clusterPartitioningMode=OPTIMIZE_PERFORMANCE`​ から ​`mule.cluster.storeprofile=performance`​ に変更します。個別のアプリケーションレベルで、特定の Mule アプリケーションのストアプロファイルを設定できます。 # Mule 3 ユーザー向けの Mule 4 の概要 すでに Mule 3 を使用していて、最近 Mule 4 に移行した場合は、以下の概要を読んで Mule 4 での主な変更点について学習してください。 すでに Mule 4 を使い慣れている場合は、以下は読まずに ​[Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.3/)​ ドキュメントに進んでください。 Mule 4 では式言語が簡便になり、管理の複雑性が軽減したため、Mule 3 よりも迅速に実用化して、アプリケーションの提供を加速することができます。 概念上、Mule 4 は Mule 3 の進化型と考えることができます。アプリケーション、フロー、コネクタ、DataWeave など多くの中核的な概念は同じです。けれども、簡素化されているため、習得する内容や管理する事項が少なくなります。 この概要では、Mule 4 の変更内容を大まかに説明し、基本的な事項をすぐに習得できるようにします。次のトピックについて説明します。 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-mule-message) Mule メッセージの構造が進化し、プロパティを簡単に操作できるようになり、コネクタ全体の一貫性が向上しています。 - [式言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-expressions) Mule の式言語が DataWeave 言語に切り替えられ、データを簡単に操作できるようになり、Mule の知識を習得しやすくなりました。 - [コネクタ](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-connectors) Mule 4 で接続のアプローチが統一されました。Mule 3 のトランスポートが新しい操作指向のコネクタに切り替えられました。コネクタは使いやすく、デフォルトの標準設定が改善され、新しい高度な機能を備えています。 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-error-handlers) 新しい Try スコープでエラーをより簡単かつ強力に処理します。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-dataweave2) DataWeave には、構文を簡潔にし、習得しやすくするための若干の変更が行われています。 - [Studio 7](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-studio) 簡便なパレット、Maven インテグレーションの改善など多くの点で使いやすさが向上しています。 - [Runtime Engine](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-engine) 内部の実行エンジンが、自己調整する非ブロック型のリアクティブエンジンに刷新されました。このため、パフォーマンスと標準の拡張性が向上しています。 # Mule 3 ユーザー向けの Mule 4 の概要 すでに Mule 3 を使用していて、最近 Mule 4 に移行した場合は、以下の概要を読んで Mule 4 での主な変更点について学習してください。 すでに Mule 4 を使い慣れている場合は、以下は読まずに ​[Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.4/)​ ドキュメントに進んでください。 Mule 4 では式言語が簡便になり、管理の複雑性が軽減したため、Mule 3 よりも迅速に実用化して、アプリケーションの提供を加速することができます。 概念上、Mule 4 は Mule 3 の進化型と考えることができます。アプリケーション、フロー、コネクタ、DataWeave など多くの中核的な概念は同じです。けれども、簡素化されているため、習得する内容や管理する事項が少なくなります。 この概要では、Mule 4 の変更内容を大まかに説明し、基本的な事項をすぐに習得できるようにします。次のトピックについて説明します。 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-mule-message) Mule メッセージの構造が進化し、プロパティを簡単に操作できるようになり、コネクタ全体の一貫性が向上しています。 - [式言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-expressions) Mule の式言語が DataWeave 言語に切り替えられ、データを簡単に操作できるようになり、Mule の知識を習得しやすくなりました。 - [コネクタ](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-connectors) Mule 4 で接続のアプローチが統一されました。Mule 3 のトランスポートが新しい操作指向のコネクタに切り替えられました。コネクタは使いやすく、デフォルトの標準設定が改善され、新しい高度な機能を備えています。 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-error-handlers) 新しい Try スコープでエラーをより簡単かつ強力に処理します。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-dataweave2) DataWeave には、構文を簡潔にし、習得しやすくするための若干の変更が行われています。 - [Studio 7](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-studio) 簡便なパレット、Maven インテグレーションの改善など多くの点で使いやすさが向上しています。 - [Runtime Engine](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-engine) 内部の実行エンジンが、自己調整する非ブロック型のリアクティブエンジンに刷新されました。このため、パフォーマンスと標準の拡張性が向上しています。 # Mule 3 ユーザー向けの Mule 4 の概要 すでに Mule 3 を使用していて、最近 Mule 4 に移行した場合は、以下の概要を読んで Mule 4 での主な変更点について学習してください。 すでに Mule 4 を使い慣れている場合は、以下は読まずに ​[Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.5/)​ ドキュメントに進んでください。 Mule 4 では式言語が簡便になり、管理の複雑性が軽減したため、Mule 3 よりも迅速に実用化して、アプリケーションの提供を加速することができます。 概念上、Mule 4 は Mule 3 の進化型と考えることができます。アプリケーション、フロー、コネクタ、DataWeave など多くの中核的な概念は同じです。けれども、簡素化されているため、習得する内容や管理する事項が少なくなります。 この概要では、Mule 4 の変更内容を大まかに説明し、基本的な事項をすぐに習得できるようにします。次のトピックについて説明します。 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-mule-message) Mule メッセージの構造が進化し、プロパティを簡単に操作できるようになり、コネクタ全体の一貫性が向上しています。 - [式言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-expressions) Mule の式言語が DataWeave 言語に切り替えられ、データを簡単に操作できるようになり、Mule の知識を習得しやすくなりました。 - [コネクタ](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-connectors) Mule 4 で接続のアプローチが統一されました。Mule 3 のトランスポートが新しい操作指向のコネクタに切り替えられました。コネクタは使いやすく、デフォルトの標準設定が改善され、新しい高度な機能を備えています。 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-error-handlers) 新しい Try スコープでエラーをより簡単かつ強力に処理します。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-dataweave2) DataWeave には、構文を簡潔にし、習得しやすくするための若干の変更が行われています。 - [Studio 7](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-studio) 簡便なパレット、Maven インテグレーションの改善など多くの点で使いやすさが向上しています。 - [Runtime Engine](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-engine) 内部の実行エンジンが、自己調整する非ブロック型のリアクティブエンジンに刷新されました。このため、パフォーマンスと標準の拡張性が向上しています。 # Mule 3 ユーザー向けの Mule 4 の概要 すでに Mule 3 を使用していて、最近 Mule 4 に移行した場合は、以下の概要を読んで Mule 4 での主な変更点について学習してください。 すでに Mule 4 を使い慣れている場合は、以下は読まずに ​[Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.6/)​ ドキュメントに進んでください。 Mule 4 では式言語が簡便になり、管理の複雑性が軽減したため、Mule 3 よりも迅速に実用化して、アプリケーションの提供を加速することができます。 概念上、Mule 4 は Mule 3 の進化型と考えることができます。アプリケーション、フロー、コネクタ、DataWeave など多くの中核的な概念は同じです。けれども、簡素化されているため、習得する内容や管理する事項が少なくなります。 この概要では、Mule 4 の変更内容を大まかに説明し、基本的な事項をすぐに習得できるようにします。次のトピックについて説明します。 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-mule-message) Mule メッセージの構造が進化し、プロパティを簡単に操作できるようになり、コネクタ全体の一貫性が向上しています。 - [式言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-expressions) Mule の式言語が DataWeave 言語に切り替えられ、データを簡単に操作できるようになり、Mule の知識を習得しやすくなりました。 - [コネクタ](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-connectors) Mule 4 で接続のアプローチが統一されました。Mule 3 のトランスポートが新しい操作指向のコネクタに切り替えられました。コネクタは使いやすく、デフォルトの標準設定が改善され、新しい高度な機能を備えています。 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-error-handlers) 新しい Try スコープでエラーをより簡単かつ強力に処理します。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-dataweave2) DataWeave には、構文を簡潔にし、習得しやすくするための若干の変更が行われています。 - [Studio 7](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-studio) 簡便なパレット、Maven インテグレーションの改善など多くの点で使いやすさが向上しています。 - [Runtime Engine](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-engine) 内部の実行エンジンが、自己調整する非ブロック型のリアクティブエンジンに刷新されました。このため、パフォーマンスと標準の拡張性が向上しています。 # Mule 3 ユーザー向けの Mule 4 の概要 すでに Mule 3 を使用していて、最近 Mule 4 に移行した場合は、以下の概要を読んで Mule 4 での主な変更点について学習してください。 すでに Mule 4 を使い慣れている場合は、以下は読まずに ​[Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.7/)​ ドキュメントに進んでください。 Mule 4 では式言語が簡便になり、管理の複雑性が軽減したため、Mule 3 よりも迅速に実用化して、アプリケーションの提供を加速することができます。 概念上、Mule 4 は Mule 3 の進化型と考えることができます。アプリケーション、フロー、コネクタ、DataWeave など多くの中核的な概念は同じです。けれども、簡素化されているため、習得する内容や管理する事項が少なくなります。 この概要では、Mule 4 の変更内容を大まかに説明し、基本的な事項をすぐに習得できるようにします。次のトピックについて説明します。 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-mule-message) Mule メッセージの構造が進化し、プロパティを簡単に操作できるようになり、コネクタ全体の一貫性が向上しています。 - [式言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-expressions) Mule の式言語が DataWeave 言語に切り替えられ、データを簡単に操作できるようになり、Mule の知識を習得しやすくなりました。 - [コネクタ](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-connectors) Mule 4 で接続のアプローチが統一されました。Mule 3 のトランスポートが新しい操作指向のコネクタに切り替えられました。コネクタは使いやすく、デフォルトの標準設定が改善され、新しい高度な機能を備えています。 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-error-handlers) 新しい Try スコープでエラーをより簡単かつ強力に処理します。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-dataweave2) DataWeave には、構文を簡潔にし、習得しやすくするための若干の変更が行われています。 - [Studio 7](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-studio) 簡便なパレット、Maven インテグレーションの改善など多くの点で使いやすさが向上しています。 - [Runtime Engine](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-engine) 内部の実行エンジンが、自己調整する非ブロック型のリアクティブエンジンに刷新されました。このため、パフォーマンスと標準の拡張性が向上しています。 # Mule 3 ユーザー向けの Mule 4 の概要 すでに Mule 3 を使用していて、最近 Mule 4 に移行した場合は、以下の概要を読んで Mule 4 での主な変更点について学習してください。 すでに Mule 4 を使い慣れている場合は、以下は読まずに ​[Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.8/)​ ドキュメントに進んでください。 Mule 4 では式言語が簡便になり、管理の複雑性が軽減したため、Mule 3 よりも迅速に実用化して、アプリケーションの提供を加速することができます。 概念上、Mule 4 は Mule 3 の進化型と考えることができます。アプリケーション、フロー、コネクタ、DataWeave など多くの中核的な概念は同じです。けれども、簡素化されているため、習得する内容や管理する事項が少なくなります。 この概要では、Mule 4 の変更内容を大まかに説明し、基本的な事項をすぐに習得できるようにします。次のトピックについて説明します。 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-mule-message) Mule メッセージの構造が進化し、プロパティを簡単に操作できるようになり、コネクタ全体の一貫性が向上しています。 - [式言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-expressions) Mule の式言語が DataWeave 言語に切り替えられ、データを簡単に操作できるようになり、Mule の知識を習得しやすくなりました。 - [コネクタ](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-connectors) Mule 4 で接続のアプローチが統一されました。Mule 3 のトランスポートが新しい操作指向のコネクタに切り替えられました。コネクタは使いやすく、デフォルトの標準設定が改善され、新しい高度な機能を備えています。 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-error-handlers) 新しい Try スコープでエラーをより簡単かつ強力に処理します。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-dataweave2) DataWeave には、構文を簡潔にし、習得しやすくするための若干の変更が行われています。 - [Studio 7](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-studio) 簡便なパレット、Maven インテグレーションの改善など多くの点で使いやすさが向上しています。 - [Runtime Engine](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-engine) 内部の実行エンジンが、自己調整する非ブロック型のリアクティブエンジンに刷新されました。このため、パフォーマンスと標準の拡張性が向上しています。 # Mule 3 ユーザー向けの Mule 4 の概要 すでに Mule 3 を使用していて、最近 Mule 4 に移行した場合は、以下の概要を読んで Mule 4 での主な変更点について学習してください。 すでに Mule 4 を使い慣れている場合は、以下は読まずに ​[Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.9/)​ ドキュメントに進んでください。 Mule 4 では式言語が簡便になり、管理の複雑性が軽減したため、Mule 3 よりも迅速に実用化して、アプリケーションの提供を加速することができます。 概念上、Mule 4 は Mule 3 の進化型と考えることができます。アプリケーション、フロー、コネクタ、DataWeave など多くの中核的な概念は同じです。けれども、簡素化されているため、習得する内容や管理する事項が少なくなります。 この概要では、Mule 4 の変更内容を大まかに説明し、基本的な事項をすぐに習得できるようにします。次のトピックについて説明します。 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-mule-message) Mule メッセージの構造が進化し、プロパティを簡単に操作できるようになり、コネクタ全体の一貫性が向上しています。 - [式言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-expressions) Mule の式言語が DataWeave 言語に切り替えられ、データを簡単に操作できるようになり、Mule の知識を習得しやすくなりました。 - [コネクタ](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-connectors) Mule 4 で接続のアプローチが統一されました。Mule 3 のトランスポートが新しい操作指向のコネクタに切り替えられました。コネクタは使いやすく、デフォルトの標準設定が改善され、新しい高度な機能を備えています。 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-error-handlers) 新しい Try スコープでエラーをより簡単かつ強力に処理します。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-dataweave2) DataWeave には、構文を簡潔にし、習得しやすくするための若干の変更が行われています。 - [Studio 7](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-studio) 簡便なパレット、Maven インテグレーションの改善など多くの点で使いやすさが向上しています。 - [Runtime Engine](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-engine) 内部の実行エンジンが、自己調整する非ブロック型のリアクティブエンジンに刷新されました。このため、パフォーマンスと標準の拡張性が向上しています。 # Mule 3 ユーザー向けの Mule 4 情報 Mule 4 の改善により、Mule 3 よりも学習、開発、管理が簡単になりました。 次の利点があります。 - より簡単で迅速なアプリケーション開発 - シームレスなアクセスとデータマッピング - 簡略化された接続 - 自動調整された高性能のランタイム - Mule Runtime Engine とコネクタバージョンのシームレスなアップグレード - Mule 3 よりも学習の手順と概念が最大 50% 少ない 現在 Mule 3 アプリケーションを実行している場合、このドキュメントを読んで Mule 4 の機能の概要を確認し、Mule 3 と Mule 4 の違いを学習して Mule 4 に移行する時期を把握し、アプリケーションを Mule 4 に移行するには何が必要かを理解してください。 Mule 3 から Mule 4 にアプリケーションを移行するためのオプションについては、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-intro)​を参照してください。 # Mule 3 ユーザー向けの Mule 4 情報 Mule 4 の改善により、Mule 3 よりも学習、開発、管理が簡単になりました。 次の利点があります。 - より簡単で迅速なアプリケーション開発 - シームレスなアクセスとデータマッピング - 簡略化された接続 - 自動調整された高性能のランタイム - Mule Runtime Engine とコネクタバージョンのシームレスなアップグレード - Mule 3 よりも学習の手順と概念が最大 50% 少ない 現在 Mule 3 アプリケーションを実行している場合、このドキュメントを読んで Mule 4 の機能の概要を確認し、Mule 3 と Mule 4 の違いを学習して Mule 4 に移行する時期を把握し、アプリケーションを Mule 4 に移行するには何が必要かを理解してください。 Mule 3 から Mule 4 にアプリケーションを移行するためのオプションについては、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-intro)​を参照してください。 # Mule 3 ユーザー向けの Mule 4 情報 Mule 4 の改善により、Mule 3 よりも学習、開発、管理が簡単になりました。 次の利点があります。 - より簡単で迅速なアプリケーション開発 - シームレスなアクセスとデータマッピング - 簡略化された接続 - 自動調整された高性能のランタイム - Mule Runtime Engine とコネクタバージョンのシームレスなアップグレード - Mule 3 よりも学習の手順と概念が最大 50% 少ない 現在 Mule 3 アプリケーションを実行している場合、このドキュメントを読んで Mule 4 の機能の概要を確認し、Mule 3 と Mule 4 の違いを学習して Mule 4 に移行する時期を把握し、アプリケーションを Mule 4 に移行するには何が必要かを理解してください。 Mule 3 から Mule 4 にアプリケーションを移行するためのオプションについては、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-intro)​を参照してください。 # Mule 3 ユーザー向けの Mule 4 情報 Mule 4 の改善により、Mule 3 よりも学習、開発、管理が簡単になりました。 次の利点があります。 - より簡単で迅速なアプリケーション開発 - シームレスなアクセスとデータマッピング - 簡略化された接続 - 自動調整された高性能のランタイム - Mule Runtime Engine とコネクタバージョンのシームレスなアップグレード - Mule 3 よりも学習の手順と概念が最大 50% 少ない 現在 Mule 3 アプリケーションを実行している場合、このドキュメントを読んで Mule 4 の機能の概要を確認し、Mule 3 と Mule 4 の違いを学習して Mule 4 に移行する時期を把握し、アプリケーションを Mule 4 に移行するには何が必要かを理解してください。 Mule 3 から Mule 4 にアプリケーションを移行するためのオプションについては、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-intro)​を参照してください。 # Mule 3 ユーザー向けの Mule 4 情報 Mule 4 の改善により、Mule 3 よりも学習、開発、管理が簡単になりました。 次の利点があります。 - より簡単で迅速なアプリケーション開発 - シームレスなアクセスとデータマッピング - 簡略化された接続 - 自動調整された高性能のランタイム - Mule Runtime Engine とコネクタバージョンのシームレスなアップグレード - Mule 3 よりも学習の手順と概念が最大 50% 少ない 現在 Mule 3 アプリケーションを実行している場合、このドキュメントを読んで Mule 4 の機能の概要を確認し、Mule 3 と Mule 4 の違いを学習して Mule 4 に移行する時期を把握し、アプリケーションを Mule 4 に移行するには何が必要かを理解してください。 Mule 3 から Mule 4 にアプリケーションを移行するためのオプションについては、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-intro)​を参照してください。 # Mule 3 ユーザー向けの Mule 4 情報 Mule 4 の改善により、Mule 3 よりも学習、開発、管理が簡単になりました。 次の利点があります。 - より簡単で迅速なアプリケーション開発 - シームレスなアクセスとデータマッピング - 簡略化された接続 - 自動調整された高性能のランタイム - Mule Runtime Engine とコネクタバージョンのシームレスなアップグレード - Mule 3 よりも学習の手順と概念が最大 50% 少ない 現在 Mule 3 アプリケーションを実行している場合、このドキュメントを読んで Mule 4 の機能の概要を確認し、Mule 3 と Mule 4 の違いを学習して Mule 4 に移行する時期を把握し、アプリケーションを Mule 4 に移行するには何が必要かを理解してください。 Mule 3 から Mule 4 にアプリケーションを移行するためのオプションについては、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-intro)​を参照してください。 # Mule 3 ユーザー向けの Mule 4 情報 Mule 4 の改善により、Mule 3 よりも学習、開発、管理が簡単になりました。 次の利点があります。 - より簡単で迅速なアプリケーション開発 - シームレスなアクセスとデータマッピング - 簡略化された接続 - 自動調整された高性能のランタイム - Mule Runtime Engine とコネクタバージョンのシームレスなアップグレード - Mule 3 よりも学習の手順と概念が最大 50% 少ない 現在 Mule 3 アプリケーションを実行している場合、このドキュメントを読んで Mule 4 の機能の概要を確認し、Mule 3 と Mule 4 の違いを学習して Mule 4 に移行する時期を把握し、アプリケーションを Mule 4 に移行するには何が必要かを理解してください。 Mule 3 から Mule 4 にアプリケーションを移行するためのオプションについては、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-intro)​を参照してください。 # Mule 4 の新機能 Mule 4 では言語が簡略化され、管理が単純になっているため、すぐに勘を取り戻し、短時間でアプリケーションを開発できます。 以前のバージョンのランタイムの概念に精通している場合は、以下のセクションで Mule Runtime v4.0 での変更内容を把握してください。 ## [](#簡略化されたイベントとメッセージモデル)簡略化されたイベントとメッセージモデル Mule 4 には簡略化された Mule イベントとメッセージモデルが含まれています。Mule 4 では、フローはイベントによってトリガーされます。イベントにはメッセージと変数が関連付けられています。メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。変数にはメッセージ、ペイロードデータ、属性などの任意の情報が保持されます。簡略化されたメッセージモデルにより、情報を上書きすることなく、コネクタ間で一貫した方法でデータを操作するのが簡単になります。 ## [](#dataweave-2-0-新しい-mule-式言語)DataWeave 2.0: 新しい Mule 式言語 Mule 3 では、ユーザーは Mule 式言語 (MEL) と DataWeave の両方に習熟する必要がありました。MEL のために、ユーザーはペイロードを XML や JSON ドキュメントなどのペイロードから Java オブジェクトに変換する必要があったため、たとえば特定の場所にルーティングする場合などに、そのデータにアクセスする式を作成する場合もありました。 **Mule 4**​ では、DataWeave がデフォルトの式言語になりました。これにより、ビルトインのストリーミング機能と組み合わせることで、一般的なタスクの多くが簡略化されます。 - イベントは最初に Java オブジェクトに変換しなくても、ペイロードデータに基づいてルーティングできます。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - メモリを超えるデータへのアクセスが透過的に実行されます。 DataWeave 2.0 でも多くの機能強化が実装されています。 - 言語の簡略化。すべてが機能するようになりました。 - 新しいインポート機能およびモジュール機能により、DataWeave スクリプトをパッケージ化して再利用できるようになりました。 - マルチラインコメントのサポート。 - DataWeave からの直接的な静的 Java メソッドのコールのサポート。 詳細については、​[DataWeave ドキュメント](#see_also)​へのリンクを参照してください。 ## [](#ストリーミング管理)ストリーミング管理 Mule 4 は自動的にユーザーのデータストリームを処理します。これにより、実行時のデータの操作が簡略化されます。その理由は次のとおりです。 - DataWeave 式言語を使用してデータを複数回読み取るか無作為にアクセスすることができ、副作用もないため。 - ユーザーが最初にメモリでデータをキャッチしなくても、データを複数の場所に送信できるため。 - ユーザーがメモリを超えるデータに透過的にアクセスできるため。 - ストリーミング戦略を使用してデータをディスクに保存するかどうかをユーザーがカスタマイズできるため。 ## [](#非ブロックで自己調整のランタイム)非ブロックで自己調整のランタイム Mule 4 には、非ブロックランタイムに基づいた新しい実行エンジンが含まれています。これはタスク指向の実行モデルであり、非ブロック IO コールを活用して不正な処理戦略設定によりパフォーマンス上の問題を回避できます。 この新しいエンジンにより、エクスチェンジパターンを設定する必要がなくなりました。代わりに、フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期的な種別のパターンを実現するには、​``​ プロセッサーを使用できます。 各 Mule イベントプロセッサーはランタイムに CPU 集中の操作なのか、CPU 軽量の操作なのか、IO 集中の操作なのかを知らせることができるようになりました。これにより、ランタイムはさまざまなワークロードに合わせて動的に自己調整でき、スレッドプールを手動で管理する必要がなくなります。その結果、Mule 4 では最適なパフォーマンスを達成するための複雑な調整が不要になります。 ## [](#コネクタモジュールからの直接的なイベントのエンリッチ)コネクタ/モジュールからの直接的なイベントのエンリッチ 任意のモジュール操作で対象 (または対象変数) を定義できるようになり、結果が変数に保存されるようになりました。 ```xml ``` これにより、Mule メッセージを ​`myVar`​ 変数に保存して、後からアクセスできるようになります。これによってエンリッチャーを削除せずに済むため、フローが単純になります。 targetValue 属性を使用して変数に保存する内容を制御することもできます。たとえば、HTTP 要求からの応答コードのみを保存する場合は、以下を実行することもできます。 ```xml ``` ## [](#簡略化されたコネクタとモジュール環境)簡略化されたコネクタとモジュール環境 Mule 4 では、モジュールおよびコネクタに関する一貫性が高まっているため、Mule コンポーネントの操作に関して統一された環境が整えられています。 トランスポートは完全に Mule モジュールに置き換えられました。モジュールおよびコネクタは Mule SDK を使用して作成および管理できるため、1 つの方法で Mule を拡張できます。 ## [](#簡略化されたエラー処理および新しい-try-スコープ)簡略化されたエラー処理および新しい Try スコープ Mule 4 ではエラーの管理が簡略化されています。Java 例外に直接対処する代わりに、エラーの概念が直接 Mule に組み込まれました。さらに、Mule モジュールおよびコネクタは操作ごとにどのエラーが発生する可能性があるかを宣言します。これにより、発生する可能性があるエラーをデザインタイムに容易に検出し、キャッチできます。 例外戦略はエラーハンドラーに置き換えられたため、種別と任意の式に基づいてエラーをキャッチできます。 フローが処理を続行できるように、またはフローを再伝播できるように、エラーをキャッチするようにエラーハンドラーを設定できます。 新しい Try スコープもあるため、フローの途中でエラーをキャッチでき、そのエラーをキャッチするための専用のフローを新たに作成する必要はありません。 ## [](#より使いやすくスコープになったバッチ)より使いやすく、スコープになったバッチ Mule 3 では、バッチジョブがフローと同じように最重要でした。しかし、この点が簡略化され、バッチジョブはフロー内で存在できるスコープの 1 つになりました。これにより、バッチジョブを理解し、動的に呼び出して、他の Mule コンポーネントとやり取りするのが簡単になりました。バッチ専用の変数のセット (つまり、recordVars) も不要になりました。フロー変数を直接使用できるようになりました。これによって単純になり、バッチジョブの作成方法を理解しやすくなりました。 ## [](#クラスローダー分離によるアップグレード可能性の向上)クラスローダー分離によるアップグレード可能性の向上 Mule 4 は各モジュールを独自のクラスローダーに読み取り、モジュールを内部 Mule コードから分離します。これにより、ランタイムまたはコネクタによる変更から保護され、ランタイムのアップグレードが大幅にシンプルになりました。 - コネクタがランタイムの外側に分散されるようになったため、以下が可能になりました。 - ランタイムをアップグレードしなくてもコネクタの機能強化および修正を取得できる。 - 他のモジュールとの互換性を犠牲にすることなくランタイムバージョンをアップグレードできる。 - 十分に定義された Mule API があるおかげで、サポートされた API を使用していることを確信できます。 - 内部で行われるライブラリ変更の影響がアプリケーションに及ばないように、アプリケーション、ランタイム、コネクタ間のクラスターローダー分離があります。 ## [](#設定のサポートの強化)設定のサポートの強化 Mule 4 の特徴は、Spring によらない環境固有のプロパティを設定しやすくなったことです。これにより、アプリケーション内の YAML ファイルでアプリケーション固有のプロパティを定義できるようになりました。これらはアプリケーションのデフォルトのプロパティであり、システムプロパティを使用して上書きできます。今後は、このメタデータを使用して Runtime Manager から設定管理 UI を改善することもできるようになります。 ## [](#コネクタとモジュールの更新)コネクタとモジュールの更新 ### [](#database-connector)Database Connector Database Connector では軽微な更新が行われました。 - 受信したペイロードに応じて操作によって動作が変更されないように、Bulk 操作は分離されました。 - 1 つの環境で静的および動的クエリを実行できます。 - メッセージに対して副作用を与えたりエンリッチャーを使用することなく、DB に送信するデータセットを作成できるように、DataWeave 変換を insert/update 操作内に埋め込むことができます。 - コネクタは Mule の新しいストリーミングフレームワークを使用して大きいデータセットを処理します。 ### [](#file-connector-と-ftp-connector)File Connector と FTP Connector File Connector と FTP Connector は、操作ベースにして同じ操作のセットを共有するように、機能強化されました。このため、多数の新しい機能が可能になります。 - 従来のトランスポート (インバウンドエンドポイントポーリングのみ可能) とは異なり、ファイルの読み取りやディレクトリのコンテンツの完全なリストの作成をオンデマンドで実行する機能。 - ディレクトリのコピー、移動、名前変更、削除、作成などの一般的なファイルシステム操作の最上位のサポート。 - ファイルシステムレベルでのファイルのロックのサポート。 - 高度なファイル一致機能。 - FTP、SFTP、FTPS などのローカルファイルのサポート。 ### [](#jms-connector)JMS Connector JMS Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。JMS リスナーおよび送信者に加えて、自分でも JMS コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#scripting-module)Scripting Module Scripting Module は Mule 4 用に更新され、Groovy、Ruby、Python、または JavaScript スクリプトを Mule フロー内に埋め込めるようになりました。新しいパラメーター設定属性を使用して Mule メッセージからコードにデータを挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: "A-OK"}] ``` ### [](#spring-module)Spring Module Mule 4 では Mule 内部が Spring から分類され、ユーザーは Spring を知らなくても Mule を理解でき、Spring ユーザーはどのバージョンの spring を実行するか選択できます。Spring Bean 使用するには、Spring Module をアプリケーションに追加して、Spring Bean ファイルをインポートするだけでよくなりました。 ```xml ``` ### [](#vm-connector)VM Connector VM Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。VM リスナーおよび送信者に加えて、自分でも VM コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#その他のモジュールおよびコネクタ)その他のモジュールおよびコネクタ その他のすべてのモジュールおよびコネクタは、Mule 4 環境全体との一貫性を保つために更新されていますが、リリースノートに明示的な記載がない限り、それ以外の機能面での変更はありません。 ## [](#mule-sdk)Mule SDK Mule SDK は Anypoint Connector Devkit の後継です。開発者はこれを使用して、容易に Mule を拡張したり、Exchange で共有できる Mule モジュールを新規作成したりできます。複数の方法で拡張機能を作成できた Mule 3 とは異なり、Mule 4 SDK では 1 つの方法で Mule を拡張することになるため、コンポーネントの一貫性およびアップグレード可能性が保たれます。この方法は、すべての Mule 4 モジュールおよびコネクタをビルドするために使用されています。 多くの点で DevKit と似ていますが、多くの機能強化も施されています。 - SDK はコードを生成しないため、再リリースしなくても拡張機能で新しいランタイム機能を取得できます。 - トランザクションのサポート。 - Request-Response (要求-応答) メッセージソースのサポート。 - 動的設定。 - ルーターのサポート。 - 非ブロック操作。 - クラスローディング分離。 ## [](#see_also)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-event) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) - [DataWeave バージョン 1 から 2 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-dataweave) - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-components) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept) # Mule 4 の新機能 Mule 4 では言語が簡略化され、管理が単純になっているため、すぐに勘を取り戻し、短時間でアプリケーションを開発できます。 以前のバージョンのランタイムの概念に精通している場合は、以下のセクションで Mule Runtime v4.0 での変更内容を把握してください。 ## [](#簡略化されたイベントとメッセージモデル)簡略化されたイベントとメッセージモデル Mule 4 には簡略化された Mule イベントとメッセージモデルが含まれています。Mule 4 では、フローはイベントによってトリガーされます。イベントにはメッセージと変数が関連付けられています。メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。変数にはメッセージ、ペイロードデータ、属性などの任意の情報が保持されます。簡略化されたメッセージモデルにより、情報を上書きすることなく、コネクタ間で一貫した方法でデータを操作するのが簡単になります。 ## [](#dataweave-2-0-新しい-mule-式言語)DataWeave 2.0: 新しい Mule 式言語 Mule 3 では、ユーザーは Mule 式言語 (MEL) と DataWeave の両方に習熟する必要がありました。MEL のために、ユーザーはペイロードを XML や JSON ドキュメントなどのペイロードから Java オブジェクトに変換する必要があったため、たとえば特定の場所にルーティングする場合などに、そのデータにアクセスする式を作成する場合もありました。 **Mule 4**​ では、DataWeave がデフォルトの式言語になりました。これにより、ビルトインのストリーミング機能と組み合わせることで、一般的なタスクの多くが簡略化されます。 - イベントは最初に Java オブジェクトに変換しなくても、ペイロードデータに基づいてルーティングできます。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - メモリを超えるデータへのアクセスが透過的に実行されます。 DataWeave 2.0 でも多くの機能強化が実装されています。 - 言語の簡略化。すべてが機能するようになりました。 - 新しいインポート機能およびモジュール機能により、DataWeave スクリプトをパッケージ化して再利用できるようになりました。 - マルチラインコメントのサポート。 - DataWeave からの直接的な静的 Java メソッドのコールのサポート。 詳細については、​[DataWeave ドキュメント](#see_also)​へのリンクを参照してください。 ## [](#ストリーミング管理)ストリーミング管理 Mule 4 は自動的にユーザーのデータストリームを処理します。これにより、実行時のデータの操作が簡略化されます。その理由は次のとおりです。 - DataWeave 式言語を使用してデータを複数回読み取るか無作為にアクセスすることができ、副作用もないため。 - ユーザーが最初にメモリでデータをキャッチしなくても、データを複数の場所に送信できるため。 - ユーザーがメモリを超えるデータに透過的にアクセスできるため。 - ストリーミング戦略を使用してデータをディスクに保存するかどうかをユーザーがカスタマイズできるため。 ## [](#非ブロックで自己調整のランタイム)非ブロックで自己調整のランタイム Mule 4 には、非ブロックランタイムに基づいた新しい実行エンジンが含まれています。これはタスク指向の実行モデルであり、非ブロック IO コールを活用して不正な処理戦略設定によりパフォーマンス上の問題を回避できます。 この新しいエンジンにより、エクスチェンジパターンを設定する必要がなくなりました。代わりに、フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期的な種別のパターンを実現するには、​``​ プロセッサーを使用できます。 各 Mule イベントプロセッサーはランタイムに CPU 集中の操作なのか、CPU 軽量の操作なのか、IO 集中の操作なのかを知らせることができるようになりました。これにより、ランタイムはさまざまなワークロードに合わせて動的に自己調整でき、スレッドプールを手動で管理する必要がなくなります。その結果、Mule 4 では最適なパフォーマンスを達成するための複雑な調整が不要になります。 ## [](#コネクタモジュールからの直接的なイベントのエンリッチ)コネクタ/モジュールからの直接的なイベントのエンリッチ 任意のモジュール操作で対象 (または対象変数) を定義できるようになり、結果が変数に保存されるようになりました。 ```xml ``` これにより、Mule メッセージを ​`myVar`​ 変数に保存して、後からアクセスできるようになります。これによってエンリッチャーを削除せずに済むため、フローが単純になります。 targetValue 属性を使用して変数に保存する内容を制御することもできます。たとえば、HTTP 要求からの応答コードのみを保存する場合は、以下を実行することもできます。 ```xml ``` ## [](#簡略化されたコネクタとモジュール環境)簡略化されたコネクタとモジュール環境 Mule 4 では、モジュールおよびコネクタに関する一貫性が高まっているため、Mule コンポーネントの操作に関して統一された環境が整えられています。 トランスポートは完全に Mule モジュールに置き換えられました。モジュールおよびコネクタは Mule SDK を使用して作成および管理できるため、1 つの方法で Mule を拡張できます。 ## [](#簡略化されたエラー処理および新しい-try-スコープ)簡略化されたエラー処理および新しい Try スコープ Mule 4 ではエラーの管理が簡略化されています。Java 例外に直接対処する代わりに、エラーの概念が直接 Mule に組み込まれました。さらに、Mule モジュールおよびコネクタは操作ごとにどのエラーが発生する可能性があるかを宣言します。これにより、発生する可能性があるエラーをデザインタイムに容易に検出し、キャッチできます。 例外戦略はエラーハンドラーに置き換えられたため、種別と任意の式に基づいてエラーをキャッチできます。 フローが処理を続行できるように、またはフローを再伝播できるように、エラーをキャッチするようにエラーハンドラーを設定できます。 新しい Try スコープもあるため、フローの途中でエラーをキャッチでき、そのエラーをキャッチするための専用のフローを新たに作成する必要はありません。 ## [](#より使いやすくスコープになったバッチ)より使いやすく、スコープになったバッチ Mule 3 では、バッチジョブがフローと同じように最重要でした。しかし、この点が簡略化され、バッチジョブはフロー内で存在できるスコープの 1 つになりました。これにより、バッチジョブを理解し、動的に呼び出して、他の Mule コンポーネントとやり取りするのが簡単になりました。バッチ専用の変数のセット (つまり、recordVars) も不要になりました。フロー変数を直接使用できるようになりました。これによって単純になり、バッチジョブの作成方法を理解しやすくなりました。 ## [](#クラスローダー分離によるアップグレード可能性の向上)クラスローダー分離によるアップグレード可能性の向上 Mule 4 は各モジュールを独自のクラスローダーに読み取り、モジュールを内部 Mule コードから分離します。これにより、ランタイムまたはコネクタによる変更から保護され、ランタイムのアップグレードが大幅にシンプルになりました。 - コネクタがランタイムの外側に分散されるようになったため、以下が可能になりました。 - ランタイムをアップグレードしなくてもコネクタの機能強化および修正を取得できる。 - 他のモジュールとの互換性を犠牲にすることなくランタイムバージョンをアップグレードできる。 - 十分に定義された Mule API があるおかげで、サポートされた API を使用していることを確信できます。 - 内部で行われるライブラリ変更の影響がアプリケーションに及ばないように、アプリケーション、ランタイム、コネクタ間のクラスターローダー分離があります。 ## [](#設定のサポートの強化)設定のサポートの強化 Mule 4 の特徴は、Spring によらない環境固有のプロパティを設定しやすくなったことです。これにより、アプリケーション内の YAML ファイルでアプリケーション固有のプロパティを定義できるようになりました。これらはアプリケーションのデフォルトのプロパティであり、システムプロパティを使用して上書きできます。今後は、このメタデータを使用して Runtime Manager から設定管理 UI を改善することもできるようになります。 ## [](#コネクタとモジュールの更新)コネクタとモジュールの更新 ### [](#database-connector)Database Connector Database Connector では軽微な更新が行われました。 - 受信したペイロードに応じて操作によって動作が変更されないように、Bulk 操作は分離されました。 - 1 つの環境で静的および動的クエリを実行できます。 - メッセージに対して副作用を与えたりエンリッチャーを使用することなく、DB に送信するデータセットを作成できるように、DataWeave 変換を insert/update 操作内に埋め込むことができます。 - コネクタは Mule の新しいストリーミングフレームワークを使用して大きいデータセットを処理します。 ### [](#file-connector-と-ftp-connector)File Connector と FTP Connector File Connector と FTP Connector は、操作ベースにして同じ操作のセットを共有するように、機能強化されました。このため、多数の新しい機能が可能になります。 - 従来のトランスポート (インバウンドエンドポイントポーリングのみ可能) とは異なり、ファイルの読み取りやディレクトリのコンテンツの完全なリストの作成をオンデマンドで実行する機能。 - ディレクトリのコピー、移動、名前変更、削除、作成などの一般的なファイルシステム操作の最上位のサポート。 - ファイルシステムレベルでのファイルのロックのサポート。 - 高度なファイル一致機能。 - FTP、SFTP、FTPS などのローカルファイルのサポート。 ### [](#jms-connector)JMS Connector JMS Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。JMS リスナーおよび送信者に加えて、自分でも JMS コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#scripting-module)Scripting Module Scripting Module は Mule 4 用に更新され、Groovy、Ruby、Python、または JavaScript スクリプトを Mule フロー内に埋め込めるようになりました。新しいパラメーター設定属性を使用して Mule メッセージからコードにデータを挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: "A-OK"}] ``` ### [](#spring-module)Spring Module Mule 4 では Mule 内部が Spring から分類され、ユーザーは Spring を知らなくても Mule を理解でき、Spring ユーザーはどのバージョンの spring を実行するか選択できます。Spring Bean 使用するには、Spring Module をアプリケーションに追加して、Spring Bean ファイルをインポートするだけでよくなりました。 ```xml ``` ### [](#vm-connector)VM Connector VM Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。VM リスナーおよび送信者に加えて、自分でも VM コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#その他のモジュールおよびコネクタ)その他のモジュールおよびコネクタ その他のすべてのモジュールおよびコネクタは、Mule 4 環境全体との一貫性を保つために更新されていますが、リリースノートに明示的な記載がない限り、それ以外の機能面での変更はありません。 ## [](#mule-sdk)Mule SDK Mule SDK は Anypoint Connector Devkit の後継です。開発者はこれを使用して、容易に Mule を拡張したり、Exchange で共有できる Mule モジュールを新規作成したりできます。複数の方法で拡張機能を作成できた Mule 3 とは異なり、Mule 4 SDK では 1 つの方法で Mule を拡張することになるため、コンポーネントの一貫性およびアップグレード可能性が保たれます。この方法は、すべての Mule 4 モジュールおよびコネクタをビルドするために使用されています。 多くの点で DevKit と似ていますが、多くの機能強化も施されています。 - SDK はコードを生成しないため、再リリースしなくても拡張機能で新しいランタイム機能を取得できます。 - トランザクションのサポート。 - Request-Response (要求-返信) イベントソースのサポート。 - 動的設定。 - ルーターのサポート。 - 非ブロック操作。 - クラスローディング分離。 ## [](#see_also)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-event) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) - [DataWeave バージョン 1 から 2 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-dataweave) - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-components) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept) # Mule 4 の新機能 Mule 4 では言語が簡略化され、管理が単純になっているため、すぐに勘を取り戻し、短時間でアプリケーションを開発できます。 以前のバージョンのランタイムの概念に精通している場合は、以下のセクションで Mule Runtime v4.0 での変更内容を把握してください。 ## [](#簡略化されたイベントとメッセージモデル)簡略化されたイベントとメッセージモデル Mule 4 には簡略化された Mule イベントとメッセージモデルが含まれています。Mule 4 では、フローはイベントによってトリガーされます。イベントにはメッセージと変数が関連付けられています。メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。変数にはメッセージ、ペイロードデータ、属性などの任意の情報が保持されます。簡略化されたメッセージモデルにより、情報を上書きすることなく、コネクタ間で一貫した方法でデータを操作するのが簡単になります。 ## [](#dataweave-2-0-新しい-mule-式言語)DataWeave 2.0: 新しい Mule 式言語 Mule 3 では、ユーザーは Mule 式言語 (MEL) と DataWeave の両方に習熟する必要がありました。MEL のために、ユーザーはペイロードを XML や JSON ドキュメントなどのペイロードから Java オブジェクトに変換する必要があったため、たとえば特定の場所にルーティングする場合などに、そのデータにアクセスする式を作成する場合もありました。 **Mule 4**​ では、DataWeave がデフォルトの式言語になりました。これにより、ビルトインのストリーミング機能と組み合わせることで、一般的なタスクの多くが簡略化されます。 - イベントは最初に Java オブジェクトに変換しなくても、ペイロードデータに基づいてルーティングできます。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - メモリを超えるデータへのアクセスが透過的に実行されます。 DataWeave 2.0 でも多くの機能強化が実装されています。 - 言語の簡略化。すべてが機能するようになりました。 - 新しいインポート機能およびモジュール機能により、DataWeave スクリプトをパッケージ化して再利用できるようになりました。 - マルチラインコメントのサポート。 - DataWeave からの直接的な静的 Java メソッドのコールのサポート。 詳細については、​[DataWeave ドキュメント](#see_also)​へのリンクを参照してください。 ## [](#ストリーミング管理)ストリーミング管理 Mule 4 は自動的にユーザーのデータストリームを処理します。これにより、実行時のデータの操作が簡略化されます。その理由は次のとおりです。 - DataWeave 式言語を使用してデータを複数回読み取るか無作為にアクセスすることができ、副作用もないため。 - ユーザーが最初にメモリでデータをキャッチしなくても、データを複数の場所に送信できるため。 - ユーザーがメモリを超えるデータに透過的にアクセスできるため。 - ストリーミング戦略を使用してデータをディスクに保存するかどうかをユーザーがカスタマイズできるため。 ## [](#非ブロックで自己調整のランタイム)非ブロックで自己調整のランタイム Mule 4 には、非ブロックランタイムに基づいた新しい実行エンジンが含まれています。これはタスク指向の実行モデルであり、非ブロック IO コールを活用して不正な処理戦略設定によりパフォーマンス上の問題を回避できます。 この新しいエンジンにより、エクスチェンジパターンを設定する必要がなくなりました。代わりに、フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期的な種別のパターンを実現するには、​``​ プロセッサーを使用できます。 各 Mule イベントプロセッサーはランタイムに CPU 集中の操作なのか、CPU 軽量の操作なのか、IO 集中の操作なのかを知らせることができるようになりました。これにより、ランタイムはさまざまなワークロードに合わせて動的に自己調整でき、スレッドプールを手動で管理する必要がなくなります。その結果、Mule 4 では最適なパフォーマンスを達成するための複雑な調整が不要になります。 ## [](#コネクタモジュールからの直接的なイベントのエンリッチ)コネクタ/モジュールからの直接的なイベントのエンリッチ 任意のモジュール操作で対象 (または対象変数) を定義できるようになり、結果が変数に保存されるようになりました。 ```xml ``` これにより、Mule メッセージを ​`myVar`​ 変数に保存して、後からアクセスできるようになります。これによってエンリッチャーを削除せずに済むため、フローが単純になります。 targetValue 属性を使用して変数に保存する内容を制御することもできます。たとえば、HTTP 要求からの応答コードのみを保存する場合は、以下を実行することもできます。 ```xml ``` ## [](#簡略化されたコネクタとモジュール環境)簡略化されたコネクタとモジュール環境 Mule 4 では、モジュールおよびコネクタに関する一貫性が高まっているため、Mule コンポーネントの操作に関して統一された環境が整えられています。 トランスポートは完全に Mule モジュールに置き換えられました。モジュールおよびコネクタは Mule SDK を使用して作成および管理できるため、1 つの方法で Mule を拡張できます。 ## [](#簡略化されたエラー処理および新しい-try-スコープ)簡略化されたエラー処理および新しい Try スコープ Mule 4 ではエラーの管理が簡略化されています。Java 例外に直接対処する代わりに、エラーの概念が直接 Mule に組み込まれました。さらに、Mule モジュールおよびコネクタは操作ごとにどのエラーが発生する可能性があるかを宣言します。これにより、発生する可能性があるエラーをデザインタイムに容易に検出し、キャッチできます。 例外戦略はエラーハンドラーに置き換えられたため、種別と任意の式に基づいてエラーをキャッチできます。 フローが処理を続行できるように、またはフローを再伝播できるように、エラーをキャッチするようにエラーハンドラーを設定できます。 新しい Try スコープもあるため、フローの途中でエラーをキャッチでき、そのエラーをキャッチするための専用のフローを新たに作成する必要はありません。 ## [](#より使いやすくスコープになったバッチ)より使いやすく、スコープになったバッチ Mule 3 では、バッチジョブがフローと同じように最重要でした。しかし、この点が簡略化され、バッチジョブはフロー内で存在できるスコープの 1 つになりました。これにより、バッチジョブを理解し、動的に呼び出して、他の Mule コンポーネントとやり取りするのが簡単になりました。バッチ専用の変数のセット (つまり、recordVars) も不要になりました。フロー変数を直接使用できるようになりました。これによって単純になり、バッチジョブの作成方法を理解しやすくなりました。 ## [](#クラスローダー分離によるアップグレード可能性の向上)クラスローダー分離によるアップグレード可能性の向上 Mule 4 は各モジュールを独自のクラスローダーに読み取り、モジュールを内部 Mule コードから分離します。これにより、ランタイムまたはコネクタによる変更から保護され、ランタイムのアップグレードが大幅にシンプルになりました。 - コネクタがランタイムの外側に分散されるようになったため、以下が可能になりました。 - ランタイムをアップグレードしなくてもコネクタの機能強化および修正を取得できる。 - 他のモジュールとの互換性を犠牲にすることなくランタイムバージョンをアップグレードできる。 - 十分に定義された Mule API があるおかげで、サポートされた API を使用していることを確信できます。 - 内部で行われるライブラリ変更の影響がアプリケーションに及ばないように、アプリケーション、ランタイム、コネクタ間のクラスターローダー分離があります。 ## [](#設定のサポートの強化)設定のサポートの強化 Mule 4 の特徴は、Spring によらない環境固有のプロパティを設定しやすくなったことです。これにより、アプリケーション内の YAML ファイルでアプリケーション固有のプロパティを定義できるようになりました。これらはアプリケーションのデフォルトのプロパティであり、システムプロパティを使用して上書きできます。今後は、このメタデータを使用して Runtime Manager から設定管理 UI を改善することもできるようになります。 ## [](#コネクタとモジュールの更新)コネクタとモジュールの更新 ### [](#database-connector)Database Connector Database Connector では軽微な更新が行われました。 - 受信したペイロードに応じて操作によって動作が変更されないように、Bulk 操作は分離されました。 - 1 つの環境で静的および動的クエリを実行できます。 - メッセージに対して副作用を与えたりエンリッチャーを使用することなく、DB に送信するデータセットを作成できるように、DataWeave 変換を insert/update 操作内に埋め込むことができます。 - コネクタは Mule の新しいストリーミングフレームワークを使用して大きいデータセットを処理します。 ### [](#file-connector-と-ftp-connector)File Connector と FTP Connector File Connector と FTP Connector は、操作ベースにして同じ操作のセットを共有するように、機能強化されました。このため、多数の新しい機能が可能になります。 - 従来のトランスポート (インバウンドエンドポイントポーリングのみ可能) とは異なり、ファイルの読み取りやディレクトリのコンテンツの完全なリストの作成をオンデマンドで実行する機能。 - ディレクトリのコピー、移動、名前変更、削除、作成などの一般的なファイルシステム操作の最上位のサポート。 - ファイルシステムレベルでのファイルのロックのサポート。 - 高度なファイル一致機能。 - FTP、SFTP、FTPS などのローカルファイルのサポート。 ### [](#jms-connector)JMS Connector JMS Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。JMS リスナーおよび送信者に加えて、自分でも JMS コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#scripting-module)Scripting Module Scripting Module は Mule 4 用に更新され、Groovy、Ruby、Python、または JavaScript スクリプトを Mule フロー内に埋め込めるようになりました。新しいパラメーター設定属性を使用して Mule メッセージからコードにデータを挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: "A-OK"}] ``` ### [](#spring-module)Spring Module Mule 4 では Mule 内部が Spring から分類され、ユーザーは Spring を知らなくても Mule を理解でき、Spring ユーザーはどのバージョンの spring を実行するか選択できます。Spring Bean 使用するには、Spring Module をアプリケーションに追加して、Spring Bean ファイルをインポートするだけでよくなりました。 ```xml ``` ### [](#vm-connector)VM Connector VM Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。VM リスナーおよび送信者に加えて、自分でも VM コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#その他のモジュールおよびコネクタ)その他のモジュールおよびコネクタ その他のすべてのモジュールおよびコネクタは、Mule 4 環境全体との一貫性を保つために更新されていますが、リリースノートに明示的な記載がない限り、それ以外の機能面での変更はありません。 ## [](#mule-sdk)Mule SDK Mule SDK は Anypoint Connector Devkit の後継です。開発者はこれを使用して、容易に Mule を拡張したり、Exchange で共有できる Mule モジュールを新規作成したりできます。複数の方法で拡張機能を作成できた Mule 3 とは異なり、Mule 4 SDK では 1 つの方法で Mule を拡張することになるため、コンポーネントの一貫性およびアップグレード可能性が保たれます。この方法は、すべての Mule 4 モジュールおよびコネクタをビルドするために使用されています。 多くの点で DevKit と似ていますが、多くの機能強化も施されています。 - SDK はコードを生成しないため、再リリースしなくても拡張機能で新しいランタイム機能を取得できます。 - トランザクションのサポート。 - Request-Response (要求-返信) イベントソースのサポート。 - 動的設定。 - ルーターのサポート。 - 非ブロック操作。 - クラスローディング分離。 ## [](#see_also)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-event) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) - [DataWeave バージョン 1 から 2 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-dataweave) - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-components) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept) # Mule 4 の新機能 Mule 4 では言語が簡略化され、管理が単純になっているため、すぐに勘を取り戻し、短時間でアプリケーションを開発できます。 以前のバージョンのランタイムの概念に精通している場合は、以下のセクションで Mule Runtime v4.0 での変更内容を把握してください。 ## [](#簡略化されたイベントとメッセージモデル)簡略化されたイベントとメッセージモデル Mule 4 には簡略化された Mule イベントとメッセージモデルが含まれています。Mule 4 では、フローはイベントによってトリガーされます。イベントにはメッセージと変数が関連付けられています。メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。変数にはメッセージ、ペイロードデータ、属性などの任意の情報が保持されます。簡略化されたメッセージモデルにより、情報を上書きすることなく、コネクタ間で一貫した方法でデータを操作するのが簡単になります。 ## [](#dataweave-2-0-新しい-mule-式言語)DataWeave 2.0: 新しい Mule 式言語 Mule 3 では、ユーザーは Mule 式言語 (MEL) と DataWeave の両方に習熟する必要がありました。MEL のために、ユーザーはペイロードを XML や JSON ドキュメントなどのペイロードから Java オブジェクトに変換する必要があったため、たとえば特定の場所にルーティングする場合などに、そのデータにアクセスする式を作成する場合もありました。 **Mule 4**​ では、DataWeave がデフォルトの式言語になりました。これにより、ビルトインのストリーミング機能と組み合わせることで、一般的なタスクの多くが簡略化されます。 - イベントは最初に Java オブジェクトに変換しなくても、ペイロードデータに基づいてルーティングできます。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - メモリを超えるデータへのアクセスが透過的に実行されます。 DataWeave 2.0 でも多くの機能強化が実装されています。 - 言語の簡略化。すべてが機能するようになりました。 - 新しいインポート機能およびモジュール機能により、DataWeave スクリプトをパッケージ化して再利用できるようになりました。 - マルチラインコメントのサポート。 - DataWeave からの直接的な静的 Java メソッドのコールのサポート。 詳細については、​[DataWeave ドキュメント](#see_also)​へのリンクを参照してください。 ## [](#ストリーミング管理)ストリーミング管理 Mule 4 は自動的にユーザーのデータストリームを処理します。これにより、実行時のデータの操作が簡略化されます。その理由は次のとおりです。 - DataWeave 式言語を使用してデータを複数回読み取るか無作為にアクセスすることができ、副作用もないため。 - ユーザーが最初にメモリでデータをキャッチしなくても、データを複数の場所に送信できるため。 - ユーザーがメモリを超えるデータに透過的にアクセスできるため。 - ストリーミング戦略を使用してデータをディスクに保存するかどうかをユーザーがカスタマイズできるため。 ## [](#非ブロックで自己調整のランタイム)非ブロックで自己調整のランタイム Mule 4 には、非ブロックランタイムに基づいた新しい実行エンジンが含まれています。これはタスク指向の実行モデルであり、非ブロック IO コールを活用して不正な処理戦略設定によりパフォーマンス上の問題を回避できます。 この新しいエンジンにより、エクスチェンジパターンを設定する必要がなくなりました。代わりに、フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期的な種別のパターンを実現するには、​``​ プロセッサーを使用できます。 各 Mule イベントプロセッサーはランタイムに CPU 集中の操作なのか、CPU 軽量の操作なのか、IO 集中の操作なのかを知らせることができるようになりました。これにより、ランタイムはさまざまなワークロードに合わせて動的に自己調整でき、スレッドプールを手動で管理する必要がなくなります。その結果、Mule 4 では最適なパフォーマンスを達成するための複雑な調整が不要になります。 ## [](#コネクタモジュールからの直接的なイベントのエンリッチ)コネクタ/モジュールからの直接的なイベントのエンリッチ 任意のモジュール操作で対象 (または対象変数) を定義できるようになり、結果が変数に保存されるようになりました。 ```xml ``` これにより、Mule メッセージを ​`myVar`​ 変数に保存して、後からアクセスできるようになります。これによってエンリッチャーを削除せずに済むため、フローが単純になります。 targetValue 属性を使用して変数に保存する内容を制御することもできます。たとえば、HTTP 要求からの応答コードのみを保存する場合は、以下を実行することもできます。 ```xml ``` ## [](#簡略化されたコネクタとモジュール環境)簡略化されたコネクタとモジュール環境 Mule 4 では、モジュールおよびコネクタに関する一貫性が高まっているため、Mule コンポーネントの操作に関して統一された環境が整えられています。 トランスポートは完全に Mule モジュールに置き換えられました。モジュールおよびコネクタは Mule SDK を使用して作成および管理できるため、1 つの方法で Mule を拡張できます。 ## [](#簡略化されたエラー処理および新しい-try-スコープ)簡略化されたエラー処理および新しい Try スコープ Mule 4 ではエラーの管理が簡略化されています。Java 例外に直接対処する代わりに、エラーの概念が直接 Mule に組み込まれました。さらに、Mule モジュールおよびコネクタは操作ごとにどのエラーが発生する可能性があるかを宣言します。これにより、発生する可能性があるエラーをデザインタイムに容易に検出し、キャッチできます。 例外戦略はエラーハンドラーに置き換えられたため、種別と任意の式に基づいてエラーをキャッチできます。 フローが処理を続行できるように、またはフローを再伝播できるように、エラーをキャッチするようにエラーハンドラーを設定できます。 新しい Try スコープもあるため、フローの途中でエラーをキャッチでき、そのエラーをキャッチするための専用のフローを新たに作成する必要はありません。 ## [](#より使いやすくスコープになったバッチ)より使いやすく、スコープになったバッチ Mule 3 では、バッチジョブがフローと同じように最重要でした。しかし、この点が簡略化され、バッチジョブはフロー内で存在できるスコープの 1 つになりました。これにより、バッチジョブを理解し、動的に呼び出して、他の Mule コンポーネントとやり取りするのが簡単になりました。バッチ専用の変数のセット (つまり、recordVars) も不要になりました。フロー変数を直接使用できるようになりました。これによって単純になり、バッチジョブの作成方法を理解しやすくなりました。 ## [](#クラスローダー分離によるアップグレード可能性の向上)クラスローダー分離によるアップグレード可能性の向上 Mule 4 は各モジュールを独自のクラスローダーに読み取り、モジュールを内部 Mule コードから分離します。これにより、ランタイムまたはコネクタによる変更から保護され、ランタイムのアップグレードが大幅にシンプルになりました。 - コネクタがランタイムの外側に分散されるようになったため、以下が可能になりました。 - ランタイムをアップグレードしなくてもコネクタの機能強化および修正を取得できる。 - 他のモジュールとの互換性を犠牲にすることなくランタイムバージョンをアップグレードできる。 - 十分に定義された Mule API があるおかげで、サポートされた API を使用していることを確信できます。 - 内部で行われるライブラリ変更の影響がアプリケーションに及ばないように、アプリケーション、ランタイム、コネクタ間のクラスターローダー分離があります。 ## [](#設定のサポートの強化)設定のサポートの強化 Mule 4 の特徴は、Spring によらない環境固有のプロパティを設定しやすくなったことです。これにより、アプリケーション内の YAML ファイルでアプリケーション固有のプロパティを定義できるようになりました。これらはアプリケーションのデフォルトのプロパティであり、システムプロパティを使用して上書きできます。今後は、このメタデータを使用して Runtime Manager から設定管理 UI を改善することもできるようになります。 ## [](#コネクタとモジュールの更新)コネクタとモジュールの更新 ### [](#database-connector)Database Connector Database Connector では軽微な更新が行われました。 - 受信したペイロードに応じて操作によって動作が変更されないように、Bulk 操作は分離されました。 - 1 つの環境で静的および動的クエリを実行できます。 - メッセージに対して副作用を与えたりエンリッチャーを使用することなく、DB に送信するデータセットを作成できるように、DataWeave 変換を insert/update 操作内に埋め込むことができます。 - コネクタは Mule の新しいストリーミングフレームワークを使用して大きいデータセットを処理します。 ### [](#file-connector-と-ftp-connector)File Connector と FTP Connector File Connector と FTP Connector は、操作ベースにして同じ操作のセットを共有するように、機能強化されました。このため、多数の新しい機能が可能になります。 - 従来のトランスポート (インバウンドエンドポイントポーリングのみ可能) とは異なり、ファイルの読み取りやディレクトリのコンテンツの完全なリストの作成をオンデマンドで実行する機能。 - ディレクトリのコピー、移動、名前変更、削除、作成などの一般的なファイルシステム操作の最上位のサポート。 - ファイルシステムレベルでのファイルのロックのサポート。 - 高度なファイル一致機能。 - FTP、SFTP、FTPS などのローカルファイルのサポート。 ### [](#jms-connector)JMS Connector JMS Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。JMS リスナーおよび送信者に加えて、自分でも JMS コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#scripting-module)Scripting Module Scripting Module は Mule 4 用に更新され、Groovy、Ruby、Python、または JavaScript スクリプトを Mule フロー内に埋め込めるようになりました。新しいパラメーター設定属性を使用して Mule メッセージからコードにデータを挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: "A-OK"}] ``` ### [](#spring-module)Spring Module Mule 4 では Mule 内部が Spring から分類され、ユーザーは Spring を知らなくても Mule を理解でき、Spring ユーザーはどのバージョンの spring を実行するか選択できます。Spring Bean 使用するには、Spring Module をアプリケーションに追加して、Spring Bean ファイルをインポートするだけでよくなりました。 ```xml ``` ### [](#vm-connector)VM Connector VM Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。VM リスナーおよび送信者に加えて、自分でも VM コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#その他のモジュールおよびコネクタ)その他のモジュールおよびコネクタ その他のすべてのモジュールおよびコネクタは、Mule 4 環境全体との一貫性を保つために更新されていますが、リリースノートに明示的な記載がない限り、それ以外の機能面での変更はありません。 ## [](#mule-sdk)Mule SDK Mule SDK は Anypoint Connector Devkit の後継です。開発者はこれを使用して、容易に Mule を拡張したり、Exchange で共有できる Mule モジュールを新規作成したりできます。複数の方法で拡張機能を作成できた Mule 3 とは異なり、Mule 4 SDK では 1 つの方法で Mule を拡張することになるため、コンポーネントの一貫性およびアップグレード可能性が保たれます。この方法は、すべての Mule 4 モジュールおよびコネクタをビルドするために使用されています。 多くの点で DevKit と似ていますが、多くの機能強化も施されています。 - SDK はコードを生成しないため、再リリースしなくても拡張機能で新しいランタイム機能を取得できます。 - トランザクションのサポート。 - Request-Response (要求-返信) イベントソースのサポート。 - 動的設定。 - ルーターのサポート。 - 非ブロック操作。 - クラスローディング分離。 ## [](#see_also)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-event) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) - [DataWeave バージョン 1 から 2 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-dataweave) - [Core コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-components) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept) # Mule 4 の新機能 Mule 4 では言語が簡略化され、管理が単純になっているため、すぐに勘を取り戻し、短時間でアプリケーションを開発できます。 以前のバージョンのランタイムの概念に精通している場合は、以下のセクションで Mule Runtime v4.0 での変更内容を把握してください。 ## [](#簡略化されたイベントとメッセージモデル)簡略化されたイベントとメッセージモデル Mule 4 には簡略化された Mule イベントとメッセージモデルが含まれています。Mule 4 では、フローはイベントによってトリガーされます。イベントにはメッセージと変数が関連付けられています。メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。変数にはメッセージ、ペイロードデータ、属性などの任意の情報が保持されます。簡略化されたメッセージモデルにより、情報を上書きすることなく、コネクタ間で一貫した方法でデータを操作するのが簡単になります。 ## [](#dataweave-2-0-新しい-mule-式言語)DataWeave 2.0: 新しい Mule 式言語 Mule 3 では、ユーザーは Mule 式言語 (MEL) と DataWeave の両方に習熟する必要がありました。MEL のために、ユーザーはペイロードを XML や JSON ドキュメントなどのペイロードから Java オブジェクトに変換する必要があったため、たとえば特定の場所にルーティングする場合などに、そのデータにアクセスする式を作成する場合もありました。 **Mule 4**​ では、DataWeave がデフォルトの式言語になりました。これにより、ビルトインのストリーミング機能と組み合わせることで、一般的なタスクの多くが簡略化されます。 - イベントは最初に Java オブジェクトに変換しなくても、ペイロードデータに基づいてルーティングできます。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - メモリを超えるデータへのアクセスが透過的に実行されます。 DataWeave 2.0 でも多くの機能強化が実装されています。 - 言語の簡略化。すべてが機能するようになりました。 - 新しいインポート機能およびモジュール機能により、DataWeave スクリプトをパッケージ化して再利用できるようになりました。 - マルチラインコメントのサポート。 - DataWeave からの直接的な静的 Java メソッドのコールのサポート。 詳細については、​[DataWeave ドキュメント](#see_also)​へのリンクを参照してください。 ## [](#ストリーミング管理)ストリーミング管理 Mule 4 は自動的にユーザーのデータストリームを処理します。これにより、実行時のデータの操作が簡略化されます。その理由は次のとおりです。 - DataWeave 式言語を使用してデータを複数回読み取るか無作為にアクセスすることができ、副作用もないため。 - ユーザーが最初にメモリでデータをキャッチしなくても、データを複数の場所に送信できるため。 - ユーザーがメモリを超えるデータに透過的にアクセスできるため。 - ストリーミング戦略を使用してデータをディスクに保存するかどうかをユーザーがカスタマイズできるため。 ## [](#非ブロックで自己調整のランタイム)非ブロックで自己調整のランタイム Mule 4 には、非ブロックランタイムに基づいた新しい実行エンジンが含まれています。これはタスク指向の実行モデルであり、非ブロック IO コールを活用して不正な処理戦略設定によりパフォーマンス上の問題を回避できます。 この新しいエンジンにより、エクスチェンジパターンを設定する必要がなくなりました。代わりに、フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期的な種別のパターンを実現するには、​``​ プロセッサーを使用できます。 各 Mule イベントプロセッサーはランタイムに CPU 集中の操作なのか、CPU 軽量の操作なのか、IO 集中の操作なのかを知らせることができるようになりました。これにより、ランタイムはさまざまなワークロードに合わせて動的に自己調整でき、スレッドプールを手動で管理する必要がなくなります。その結果、Mule 4 では最適なパフォーマンスを達成するための複雑な調整が不要になります。 ## [](#コネクタモジュールからの直接的なイベントのエンリッチ)コネクタ/モジュールからの直接的なイベントのエンリッチ 任意のモジュール操作で対象 (または対象変数) を定義できるようになり、結果が変数に保存されるようになりました。 ```xml ``` これにより、Mule メッセージを ​`myVar`​ 変数に保存して、後からアクセスできるようになります。これによってエンリッチャーを削除せずに済むため、フローが単純になります。 targetValue 属性を使用して変数に保存する内容を制御することもできます。たとえば、HTTP 要求からの応答コードのみを保存する場合は、以下を実行することもできます。 ```xml ``` ## [](#簡略化されたコネクタとモジュール環境)簡略化されたコネクタとモジュール環境 Mule 4 では、モジュールおよびコネクタに関する一貫性が高まっているため、Mule コンポーネントの操作に関して統一された環境が整えられています。 トランスポートは完全に Mule モジュールに置き換えられました。モジュールおよびコネクタは Mule SDK を使用して作成および管理できるため、1 つの方法で Mule を拡張できます。 ## [](#簡略化されたエラー処理および新しい-try-スコープ)簡略化されたエラー処理および新しい Try スコープ Mule 4 ではエラーの管理が簡略化されています。Java 例外に直接対処する代わりに、エラーの概念が直接 Mule に組み込まれました。さらに、Mule モジュールおよびコネクタは操作ごとにどのエラーが発生する可能性があるかを宣言します。これにより、発生する可能性があるエラーをデザインタイムに容易に検出し、キャッチできます。 例外戦略はエラーハンドラーに置き換えられたため、種別と任意の式に基づいてエラーをキャッチできます。 フローが処理を続行できるように、またはフローを再伝播できるように、エラーをキャッチするようにエラーハンドラーを設定できます。 新しい Try スコープもあるため、フローの途中でエラーをキャッチでき、そのエラーをキャッチするための専用のフローを新たに作成する必要はありません。 ## [](#より使いやすくスコープになったバッチ)より使いやすく、スコープになったバッチ Mule 3 では、バッチジョブがフローと同じように最重要でした。しかし、この点が簡略化され、バッチジョブはフロー内で存在できるスコープの 1 つになりました。これにより、バッチジョブを理解し、動的に呼び出して、他の Mule コンポーネントとやり取りするのが簡単になりました。バッチ専用の変数のセット (つまり、recordVars) も不要になりました。フロー変数を直接使用できるようになりました。これによって単純になり、バッチジョブの作成方法を理解しやすくなりました。 ## [](#クラスローダー分離によるアップグレード可能性の向上)クラスローダー分離によるアップグレード可能性の向上 Mule 4 は各モジュールを独自のクラスローダーに読み取り、モジュールを内部 Mule コードから分離します。これにより、ランタイムまたはコネクタによる変更から保護され、ランタイムのアップグレードが大幅にシンプルになりました。 - コネクタがランタイムの外側に分散されるようになったため、以下が可能になりました。 - ランタイムをアップグレードしなくてもコネクタの機能強化および修正を取得できる。 - 他のモジュールとの互換性を犠牲にすることなくランタイムバージョンをアップグレードできる。 - 十分に定義された Mule API があるおかげで、サポートされた API を使用していることを確信できます。 - 内部で行われるライブラリ変更の影響がアプリケーションに及ばないように、アプリケーション、ランタイム、コネクタ間のクラスターローダー分離があります。 ## [](#設定のサポートの強化)設定のサポートの強化 Mule 4 の特徴は、Spring によらない環境固有のプロパティを設定しやすくなったことです。これにより、アプリケーション内の YAML ファイルでアプリケーション固有のプロパティを定義できるようになりました。これらはアプリケーションのデフォルトのプロパティであり、システムプロパティを使用して上書きできます。今後は、このメタデータを使用して Runtime Manager から設定管理 UI を改善することもできるようになります。 ## [](#コネクタとモジュールの更新)コネクタとモジュールの更新 ### [](#database-connector)Database Connector Database Connector では軽微な更新が行われました。 - 受信したペイロードに応じて操作によって動作が変更されないように、Bulk 操作は分離されました。 - 1 つの環境で静的および動的クエリを実行できます。 - メッセージに対して副作用を与えたりエンリッチャーを使用することなく、DB に送信するデータセットを作成できるように、DataWeave 変換を insert/update 操作内に埋め込むことができます。 - コネクタは Mule の新しいストリーミングフレームワークを使用して大きいデータセットを処理します。 ### [](#file-connector-と-ftp-connector)File Connector と FTP Connector File Connector と FTP Connector は、操作ベースにして同じ操作のセットを共有するように、機能強化されました。このため、多数の新しい機能が可能になります。 - 従来のトランスポート (インバウンドエンドポイントポーリングのみ可能) とは異なり、ファイルの読み取りやディレクトリのコンテンツの完全なリストの作成をオンデマンドで実行する機能。 - ディレクトリのコピー、移動、名前変更、削除、作成などの一般的なファイルシステム操作の最上位のサポート。 - ファイルシステムレベルでのファイルのロックのサポート。 - 高度なファイル一致機能。 - FTP、SFTP、FTPS などのローカルファイルのサポート。 ### [](#jms-connector)JMS Connector JMS Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。JMS リスナーおよび送信者に加えて、自分でも JMS コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#scripting-module)Scripting Module Scripting Module は Mule 4 用に更新され、Groovy、Ruby、Python、または JavaScript スクリプトを Mule フロー内に埋め込めるようになりました。新しいパラメーター設定属性を使用して Mule メッセージからコードにデータを挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: "A-OK"}] ``` ### [](#spring-module)Spring Module Mule 4 では Mule 内部が Spring から分類され、ユーザーは Spring を知らなくても Mule を理解でき、Spring ユーザーはどのバージョンの spring を実行するか選択できます。Spring Bean 使用するには、Spring Module をアプリケーションに追加して、Spring Bean ファイルをインポートするだけでよくなりました。 ```xml ``` ### [](#vm-connector)VM Connector VM Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。VM リスナーおよび送信者に加えて、自分でも VM コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#その他のモジュールおよびコネクタ)その他のモジュールおよびコネクタ その他のすべてのモジュールおよびコネクタは、Mule 4 環境全体との一貫性を保つために更新されていますが、リリースノートに明示的な記載がない限り、それ以外の機能面での変更はありません。 ## [](#mule-sdk)Mule SDK Mule SDK は Anypoint Connector Devkit の後継です。開発者はこれを使用して、容易に Mule を拡張したり、Exchange で共有できる Mule モジュールを新規作成したりできます。複数の方法で拡張機能を作成できた Mule 3 とは異なり、Mule 4 SDK では 1 つの方法で Mule を拡張することになるため、コンポーネントの一貫性およびアップグレード可能性が保たれます。この方法は、すべての Mule 4 モジュールおよびコネクタをビルドするために使用されています。 多くの点で DevKit と似ていますが、多くの機能強化も施されています。 - SDK はコードを生成しないため、再リリースしなくても拡張機能で新しいランタイム機能を取得できます。 - トランザクションのサポート。 - Request-Response (要求-返信) イベントソースのサポート。 - 動的設定。 - ルーターのサポート。 - 非ブロック操作。 - クラスローディング分離。 ## [](#see_also)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-event) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) - [DataWeave バージョン 1 から 2 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-dataweave) - [Core コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-components) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept) # Mule 4 の新機能 Mule 4 では言語が簡略化され、管理が単純になっているため、すぐに勘を取り戻し、短時間でアプリケーションを開発できます。 以前のバージョンのランタイムの概念に精通している場合は、以下のセクションで Mule Runtime v4.0 での変更内容を把握してください。 ## [](#簡略化されたイベントとメッセージモデル)簡略化されたイベントとメッセージモデル Mule 4 には簡略化された Mule イベントとメッセージモデルが含まれています。Mule 4 では、フローはイベントによってトリガーされます。イベントにはメッセージと変数が関連付けられています。メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。変数にはメッセージ、ペイロードデータ、属性などの任意の情報が保持されます。簡略化されたメッセージモデルにより、情報を上書きすることなく、コネクタ間で一貫した方法でデータを操作するのが簡単になります。 ## [](#dataweave-2-0-新しい-mule-式言語)DataWeave 2.0: 新しい Mule 式言語 Mule 3 では、ユーザーは Mule 式言語 (MEL) と DataWeave の両方に習熟する必要がありました。MEL のために、ユーザーはペイロードを XML や JSON ドキュメントなどのペイロードから Java オブジェクトに変換する必要があったため、たとえば特定の場所にルーティングする場合などに、そのデータにアクセスする式を作成する場合もありました。 **Mule 4**​ では、DataWeave がデフォルトの式言語になりました。これにより、ビルトインのストリーミング機能と組み合わせることで、一般的なタスクの多くが簡略化されます。 - イベントは最初に Java オブジェクトに変換しなくても、ペイロードデータに基づいてルーティングできます。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - メモリを超えるデータへのアクセスが透過的に実行されます。 DataWeave 2.0 でも多くの機能強化が実装されています。 - 言語の簡略化。すべてが機能するようになりました。 - 新しいインポート機能およびモジュール機能により、DataWeave スクリプトをパッケージ化して再利用できるようになりました。 - マルチラインコメントのサポート。 - DataWeave からの直接的な静的 Java メソッドのコールのサポート。 詳細については、​[DataWeave ドキュメント](#see_also)​へのリンクを参照してください。 ## [](#ストリーミング管理)ストリーミング管理 Mule 4 は自動的にユーザーのデータストリームを処理します。これにより、実行時のデータの操作が簡略化されます。その理由は次のとおりです。 - DataWeave 式言語を使用してデータを複数回読み取るか無作為にアクセスすることができ、副作用もないため。 - ユーザーが最初にメモリでデータをキャッチしなくても、データを複数の場所に送信できるため。 - ユーザーがメモリを超えるデータに透過的にアクセスできるため。 - ストリーミング戦略を使用してデータをディスクに保存するかどうかをユーザーがカスタマイズできるため。 ## [](#非ブロックで自己調整のランタイム)非ブロックで自己調整のランタイム Mule 4 には、非ブロックランタイムに基づいた新しい実行エンジンが含まれています。これはタスク指向の実行モデルであり、非ブロック IO コールを活用して不正な処理戦略設定によりパフォーマンス上の問題を回避できます。 この新しいエンジンにより、エクスチェンジパターンを設定する必要がなくなりました。代わりに、フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期的な種別のパターンを実現するには、​``​ プロセッサーを使用できます。 各 Mule イベントプロセッサーはランタイムに CPU 集中の操作なのか、CPU 軽量の操作なのか、IO 集中の操作なのかを知らせることができるようになりました。これにより、ランタイムはさまざまなワークロードに合わせて動的に自己調整でき、スレッドプールを手動で管理する必要がなくなります。その結果、Mule 4 では最適なパフォーマンスを達成するための複雑な調整が不要になります。 ## [](#コネクタモジュールからの直接的なイベントのエンリッチ)コネクタ/モジュールからの直接的なイベントのエンリッチ 任意のモジュール操作で対象 (または対象変数) を定義できるようになり、結果が変数に保存されるようになりました。 ```xml ``` これにより、Mule メッセージを ​`myVar`​ 変数に保存して、後からアクセスできるようになります。これによってエンリッチャーを削除せずに済むため、フローが単純になります。 targetValue 属性を使用して変数に保存する内容を制御することもできます。たとえば、HTTP 要求からの応答コードのみを保存する場合は、以下を実行することもできます。 ```xml ``` ## [](#簡略化されたコネクタとモジュール環境)簡略化されたコネクタとモジュール環境 Mule 4 では、モジュールおよびコネクタに関する一貫性が高まっているため、Mule コンポーネントの操作に関して統一された環境が整えられています。 トランスポートは完全に Mule モジュールに置き換えられました。モジュールおよびコネクタは Mule SDK を使用して作成および管理できるため、1 つの方法で Mule を拡張できます。 ## [](#簡略化されたエラー処理および新しい-try-スコープ)簡略化されたエラー処理および新しい Try スコープ Mule 4 ではエラーの管理が簡略化されています。Java 例外に直接対処する代わりに、エラーの概念が直接 Mule に組み込まれました。さらに、Mule モジュールおよびコネクタは操作ごとにどのエラーが発生する可能性があるかを宣言します。これにより、発生する可能性があるエラーをデザインタイムに容易に検出し、キャッチできます。 例外戦略はエラーハンドラーに置き換えられたため、種別と任意の式に基づいてエラーをキャッチできます。 フローが処理を続行できるように、またはフローを再伝播できるように、エラーをキャッチするようにエラーハンドラーを設定できます。 新しい Try スコープもあるため、フローの途中でエラーをキャッチでき、そのエラーをキャッチするための専用のフローを新たに作成する必要はありません。 ## [](#より使いやすくスコープになったバッチ)より使いやすく、スコープになったバッチ Mule 3 では、バッチジョブがフローと同じように最重要でした。しかし、この点が簡略化され、バッチジョブはフロー内で存在できるスコープの 1 つになりました。これにより、バッチジョブを理解し、動的に呼び出して、他の Mule コンポーネントとやり取りするのが簡単になりました。バッチ専用の変数のセット (つまり、recordVars) も不要になりました。フロー変数を直接使用できるようになりました。これによって単純になり、バッチジョブの作成方法を理解しやすくなりました。 ## [](#クラスローダー分離によるアップグレード可能性の向上)クラスローダー分離によるアップグレード可能性の向上 Mule 4 は各モジュールを独自のクラスローダーに読み取り、モジュールを内部 Mule コードから分離します。これにより、ランタイムまたはコネクタによる変更から保護され、ランタイムのアップグレードが大幅にシンプルになりました。 - コネクタがランタイムの外側に分散されるようになったため、以下が可能になりました。 - ランタイムをアップグレードしなくてもコネクタの機能強化および修正を取得できる。 - 他のモジュールとの互換性を犠牲にすることなくランタイムバージョンをアップグレードできる。 - 十分に定義された Mule API があるおかげで、サポートされた API を使用していることを確信できます。 - 内部で行われるライブラリ変更の影響がアプリケーションに及ばないように、アプリケーション、ランタイム、コネクタ間のクラスターローダー分離があります。 ## [](#設定のサポートの強化)設定のサポートの強化 Mule 4 の特徴は、Spring によらない環境固有のプロパティを設定しやすくなったことです。これにより、アプリケーション内の YAML ファイルでアプリケーション固有のプロパティを定義できるようになりました。これらはアプリケーションのデフォルトのプロパティであり、システムプロパティを使用して上書きできます。今後は、このメタデータを使用して Runtime Manager から設定管理 UI を改善することもできるようになります。 ## [](#コネクタとモジュールの更新)コネクタとモジュールの更新 ### [](#database-connector)Database Connector Database Connector では軽微な更新が行われました。 - 受信したペイロードに応じて操作によって動作が変更されないように、Bulk 操作は分離されました。 - 1 つの環境で静的および動的クエリを実行できます。 - メッセージに対して副作用を与えたりエンリッチャーを使用することなく、DB に送信するデータセットを作成できるように、DataWeave 変換を insert/update 操作内に埋め込むことができます。 - コネクタは Mule の新しいストリーミングフレームワークを使用して大きいデータセットを処理します。 ### [](#file-connector-と-ftp-connector)File Connector と FTP Connector File Connector と FTP Connector は、操作ベースにして同じ操作のセットを共有するように、機能強化されました。このため、多数の新しい機能が可能になります。 - 従来のトランスポート (インバウンドエンドポイントポーリングのみ可能) とは異なり、ファイルの読み取りやディレクトリのコンテンツの完全なリストの作成をオンデマンドで実行する機能。 - ディレクトリのコピー、移動、名前変更、削除、作成などの一般的なファイルシステム操作の最上位のサポート。 - ファイルシステムレベルでのファイルのロックのサポート。 - 高度なファイル一致機能。 - FTP、SFTP、FTPS などのローカルファイルのサポート。 ### [](#jms-connector)JMS Connector JMS Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。JMS リスナーおよび送信者に加えて、自分でも JMS コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#scripting-module)Scripting Module Scripting Module は Mule 4 用に更新され、Groovy、Ruby、Python、または JavaScript スクリプトを Mule フロー内に埋め込めるようになりました。新しいパラメーター設定属性を使用して Mule メッセージからコードにデータを挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: "A-OK"}] ``` ### [](#spring-module)Spring Module Mule 4 では Mule 内部が Spring から分類され、ユーザーは Spring を知らなくても Mule を理解でき、Spring ユーザーはどのバージョンの spring を実行するか選択できます。Spring Bean 使用するには、Spring Module をアプリケーションに追加して、Spring Bean ファイルをインポートするだけでよくなりました。 ```xml ``` ### [](#vm-connector)VM Connector VM Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。VM リスナーおよび送信者に加えて、自分でも VM コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#その他のモジュールおよびコネクタ)その他のモジュールおよびコネクタ その他のすべてのモジュールおよびコネクタは、Mule 4 環境全体との一貫性を保つために更新されていますが、リリースノートに明示的な記載がない限り、それ以外の機能面での変更はありません。 ## [](#mule-sdk)Mule SDK Mule SDK は Anypoint Connector Devkit の後継です。開発者はこれを使用して、容易に Mule を拡張したり、Exchange で共有できる Mule モジュールを新規作成したりできます。複数の方法で拡張機能を作成できた Mule 3 とは異なり、Mule 4 SDK では 1 つの方法で Mule を拡張することになるため、コンポーネントの一貫性およびアップグレード可能性が保たれます。この方法は、すべての Mule 4 モジュールおよびコネクタをビルドするために使用されています。 多くの点で DevKit と似ていますが、多くの機能強化も施されています。 - SDK はコードを生成しないため、再リリースしなくても拡張機能で新しいランタイム機能を取得できます。 - トランザクションのサポート。 - Request-Response (要求-返信) イベントソースのサポート。 - 動的設定。 - ルーターのサポート。 - 非ブロック操作。 - クラスローディング分離。 ## [](#see_also)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-event) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) - [DataWeave バージョン 1 から 2 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-dataweave) - [Core コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-components) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept) # Mule 4 の新機能 Mule 4 では言語が簡略化され、管理が単純になっているため、すぐに勘を取り戻し、短時間でアプリケーションを開発できます。 以前のバージョンのランタイムの概念に精通している場合は、以下のセクションで Mule Runtime v4.0 での変更内容を把握してください。 ## [](#簡略化されたイベントとメッセージモデル)簡略化されたイベントとメッセージモデル Mule 4 には簡略化された Mule イベントとメッセージモデルが含まれています。Mule 4 では、フローはイベントによってトリガーされます。イベントにはメッセージと変数が関連付けられています。メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。変数にはメッセージ、ペイロードデータ、属性などの任意の情報が保持されます。簡略化されたメッセージモデルにより、情報を上書きすることなく、コネクタ間で一貫した方法でデータを操作するのが簡単になります。 ## [](#dataweave-2-0-新しい-mule-式言語)DataWeave 2.0: 新しい Mule 式言語 Mule 3 では、ユーザーは Mule 式言語 (MEL) と DataWeave の両方に習熟する必要がありました。MEL のために、ユーザーはペイロードを XML や JSON ドキュメントなどのペイロードから Java オブジェクトに変換する必要があったため、たとえば特定の場所にルーティングする場合などに、そのデータにアクセスする式を作成する場合もありました。 **Mule 4**​ では、DataWeave がデフォルトの式言語になりました。これにより、ビルトインのストリーミング機能と組み合わせることで、一般的なタスクの多くが簡略化されます。 - イベントは最初に Java オブジェクトに変換しなくても、ペイロードデータに基づいてルーティングできます。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - メモリを超えるデータへのアクセスが透過的に実行されます。 DataWeave 2.0 でも多くの機能強化が実装されています。 - 言語の簡略化。すべてが機能するようになりました。 - 新しいインポート機能およびモジュール機能により、DataWeave スクリプトをパッケージ化して再利用できるようになりました。 - マルチラインコメントのサポート。 - DataWeave からの直接的な静的 Java メソッドのコールのサポート。 詳細については、​[DataWeave ドキュメント](#see_also)​へのリンクを参照してください。 ## [](#ストリーミング管理)ストリーミング管理 Mule 4 は自動的にユーザーのデータストリームを処理します。これにより、実行時のデータの操作が簡略化されます。その理由は次のとおりです。 - DataWeave 式言語を使用してデータを複数回読み取るか無作為にアクセスすることができ、副作用もないため。 - ユーザーが最初にメモリでデータをキャッチしなくても、データを複数の場所に送信できるため。 - ユーザーがメモリを超えるデータに透過的にアクセスできるため。 - ストリーミング戦略を使用してデータをディスクに保存するかどうかをユーザーがカスタマイズできるため。 ## [](#非ブロックで自己調整のランタイム)非ブロックで自己調整のランタイム Mule 4 には、非ブロックランタイムに基づいた新しい実行エンジンが含まれています。これはタスク指向の実行モデルであり、非ブロック IO コールを活用して不正な処理戦略設定によりパフォーマンス上の問題を回避できます。 この新しいエンジンにより、エクスチェンジパターンを設定する必要がなくなりました。代わりに、フローは常に同期的に機能します。ファイヤアンドフォゲットなどの非同期的な種別のパターンを実現するには、​``​ プロセッサーを使用できます。 各 Mule イベントプロセッサーはランタイムに CPU 集中の操作なのか、CPU 軽量の操作なのか、IO 集中の操作なのかを知らせることができるようになりました。これにより、ランタイムはさまざまなワークロードに合わせて動的に自己調整でき、スレッドプールを手動で管理する必要がなくなります。その結果、Mule 4 では最適なパフォーマンスを達成するための複雑な調整が不要になります。 ## [](#コネクタモジュールからの直接的なイベントのエンリッチ)コネクタ/モジュールからの直接的なイベントのエンリッチ 任意のモジュール操作で対象 (または対象変数) を定義できるようになり、結果が変数に保存されるようになりました。 ```xml ``` これにより、Mule メッセージを ​`myVar`​ 変数に保存して、後からアクセスできるようになります。これによってエンリッチャーを削除せずに済むため、フローが単純になります。 targetValue 属性を使用して変数に保存する内容を制御することもできます。たとえば、HTTP 要求からの応答コードのみを保存する場合は、以下を実行することもできます。 ```xml ``` ## [](#簡略化されたコネクタとモジュール環境)簡略化されたコネクタとモジュール環境 Mule 4 では、モジュールおよびコネクタに関する一貫性が高まっているため、Mule コンポーネントの操作に関して統一された環境が整えられています。 トランスポートは完全に Mule モジュールに置き換えられました。モジュールおよびコネクタは Mule SDK を使用して作成および管理できるため、1 つの方法で Mule を拡張できます。 ## [](#簡略化されたエラー処理および新しい-try-スコープ)簡略化されたエラー処理および新しい Try スコープ Mule 4 ではエラーの管理が簡略化されています。Java 例外に直接対処する代わりに、エラーの概念が直接 Mule に組み込まれました。さらに、Mule モジュールおよびコネクタは操作ごとにどのエラーが発生する可能性があるかを宣言します。これにより、発生する可能性があるエラーをデザインタイムに容易に検出し、キャッチできます。 例外戦略はエラーハンドラーに置き換えられたため、種別と任意の式に基づいてエラーをキャッチできます。 フローが処理を続行できるように、またはフローを再伝播できるように、エラーをキャッチするようにエラーハンドラーを設定できます。 新しい Try スコープもあるため、フローの途中でエラーをキャッチでき、そのエラーをキャッチするための専用のフローを新たに作成する必要はありません。 ## [](#より使いやすくスコープになったバッチ)より使いやすく、スコープになったバッチ Mule 3 では、バッチジョブがフローと同じように最重要でした。しかし、この点が簡略化され、バッチジョブはフロー内で存在できるスコープの 1 つになりました。これにより、バッチジョブを理解し、動的に呼び出して、他の Mule コンポーネントとやり取りするのが簡単になりました。バッチ専用の変数のセット (つまり、recordVars) も不要になりました。フロー変数を直接使用できるようになりました。これによって単純になり、バッチジョブの作成方法を理解しやすくなりました。 ## [](#クラスローダー分離によるアップグレード可能性の向上)クラスローダー分離によるアップグレード可能性の向上 Mule 4 は各モジュールを独自のクラスローダーに読み取り、モジュールを内部 Mule コードから分離します。これにより、ランタイムまたはコネクタによる変更から保護され、ランタイムのアップグレードが大幅にシンプルになりました。 - コネクタがランタイムの外側に分散されるようになったため、以下が可能になりました。 - ランタイムをアップグレードしなくてもコネクタの機能強化および修正を取得できる。 - 他のモジュールとの互換性を犠牲にすることなくランタイムバージョンをアップグレードできる。 - 十分に定義された Mule API があるおかげで、サポートされた API を使用していることを確信できます。 - 内部で行われるライブラリ変更の影響がアプリケーションに及ばないように、アプリケーション、ランタイム、コネクタ間のクラスターローダー分離があります。 ## [](#設定のサポートの強化)設定のサポートの強化 Mule 4 の特徴は、Spring によらない環境固有のプロパティを設定しやすくなったことです。これにより、アプリケーション内の YAML ファイルでアプリケーション固有のプロパティを定義できるようになりました。これらはアプリケーションのデフォルトのプロパティであり、システムプロパティを使用して上書きできます。今後は、このメタデータを使用して Runtime Manager から設定管理 UI を改善することもできるようになります。 ## [](#コネクタとモジュールの更新)コネクタとモジュールの更新 ### [](#database-connector)Database Connector Database Connector では軽微な更新が行われました。 - 受信したペイロードに応じて操作によって動作が変更されないように、Bulk 操作は分離されました。 - 1 つの環境で静的および動的クエリを実行できます。 - メッセージに対して副作用を与えたりエンリッチャーを使用することなく、DB に送信するデータセットを作成できるように、DataWeave 変換を insert/update 操作内に埋め込むことができます。 - コネクタは Mule の新しいストリーミングフレームワークを使用して大きいデータセットを処理します。 ### [](#file-connector-と-ftp-connector)File Connector と FTP Connector File Connector と FTP Connector は、操作ベースにして同じ操作のセットを共有するように、機能強化されました。このため、多数の新しい機能が可能になります。 - 従来のトランスポート (インバウンドエンドポイントポーリングのみ可能) とは異なり、ファイルの読み取りやディレクトリのコンテンツの完全なリストの作成をオンデマンドで実行する機能。 - ディレクトリのコピー、移動、名前変更、削除、作成などの一般的なファイルシステム操作の最上位のサポート。 - ファイルシステムレベルでのファイルのロックのサポート。 - 高度なファイル一致機能。 - FTP、SFTP、FTPS などのローカルファイルのサポート。 ### [](#jms-connector)JMS Connector JMS Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。JMS リスナーおよび送信者に加えて、自分でも JMS コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#scripting-module)Scripting Module Scripting Module は Mule 4 用に更新され、Groovy、Ruby、Python、または JavaScript スクリプトを Mule フロー内に埋め込めるようになりました。新しいパラメーター設定属性を使用して Mule メッセージからコードにデータを挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: "A-OK"}] ``` ### [](#spring-module)Spring Module Mule 4 では Mule 内部が Spring から分類され、ユーザーは Spring を知らなくても Mule を理解でき、Spring ユーザーはどのバージョンの spring を実行するか選択できます。Spring Bean 使用するには、Spring Module をアプリケーションに追加して、Spring Bean ファイルをインポートするだけでよくなりました。 ```xml ``` ### [](#vm-connector)VM Connector VM Connector は新しい簡略化されたコネクタ環境を活用するために更新されました。VM リスナーおよび送信者に加えて、自分でも VM コンシューム操作を使用してフローの途中でメッセージをコンシュームできます。 ### [](#その他のモジュールおよびコネクタ)その他のモジュールおよびコネクタ その他のすべてのモジュールおよびコネクタは、Mule 4 環境全体との一貫性を保つために更新されていますが、リリースノートに明示的な記載がない限り、それ以外の機能面での変更はありません。 ## [](#mule-sdk)Mule SDK Mule SDK は Anypoint Connector Devkit の後継です。開発者はこれを使用して、容易に Mule を拡張したり、Exchange で共有できる Mule モジュールを新規作成したりできます。複数の方法で拡張機能を作成できた Mule 3 とは異なり、Mule 4 SDK では 1 つの方法で Mule を拡張することになるため、コンポーネントの一貫性およびアップグレード可能性が保たれます。この方法は、すべての Mule 4 モジュールおよびコネクタをビルドするために使用されています。 多くの点で DevKit と似ていますが、多くの機能強化も施されています。 - SDK はコードを生成しないため、再リリースしなくても拡張機能で新しいランタイム機能を取得できます。 - トランザクションのサポート。 - Request-Response (要求-返信) イベントソースのサポート。 - 動的設定。 - ルーターのサポート。 - 非ブロック操作。 - クラスローディング分離。 ## [](#see_also)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-event) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) - [DataWeave バージョン 1 から 2 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-dataweave) - [Core コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-components) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept) # Mule 4 の概要: Connector システムに接続する場合、Mule 3 にはトランスポートとコネクタという 2 つの手段がありました。トランスポートは、インバウンドおよびアウトバウンドエンドポイントという概念を用いてデータを送信します。コネクタは、操作という概念を用いてシステムを呼び出します (​``​、​``​ など)。 MuleSoft は、Mule 3 で一部のトランスポートを新しい HTTP Connector や Database Connector に切り替え始めました。Mule 4 でこの変更が完了し、すべての接続性をコネクタとして構築するアプローチが完全に標準化されています。この変更により、コネクタの一貫性と使いやすさが向上し、コネクタの機能が強化されます。 ## [](#コアコネクタやコアモジュールの独立したリリースサイクル)コアコネクタやコアモジュールの独立したリリースサイクル もう一つの大きな違いは、コネクタの配布およびリリース方法です。Mule 3 では、Mule Runtime の配布に多数のコネクタやトランスポート (File、FTP、SFTP、Database、JMS、XML、Validations など) が付属していました。こうしたコネクタの修正や機能拡張は、Mule Runtime の次回のリリースまで待たなければなりませんでした。その一方で、他のコネクタは (Salesforce、Workday、ServiceNow、SAP など、主として SaaS Connector)、独立して配布やリリースされていました。 Mule 4 では、最新のモデルを標準化しています。Mule 4 の配布にはコネクタやモジュールが 1 つも付属していません。代わりに、各アプリケーションに必要なモジュールが含まれています。こうしたアプローチには次のメリットがあります。 - どのコネクタにも独自のリリースサイクルがあるため、コアモジュール/コアコネクタでの迅速なイノベーションが可能になる。Mule Runtime の次のリリースまで待たなくても、新機能やバグ修正が手に入ります。 - 異なるアプリケーションで、同じモジュールの異なるバージョンを使用できる。このため、新しいリリースを簡単に採用でき、アップグレードが不要なアプリケーションを完全退行させる必要がありません。 - 一貫したアプローチが可能になる。 # Mule 4 の概要: DataWeave 2.0 DataWeave 2 はほぼ DataWeave 1 のままです。ただし、習得しやすいようにさまざまな点が改善され、新しい機能が追加されています。 ## [](#演算子は関数)演算子は関数 DataWeave 2 では、演算子がすべて関数になりました。このためコード上の括弧が増えるかもしれませんが、曖昧さが減少し、オートコンプリート機能を使用して習得しやすくなります。パラメーターが 2 つある関数はこれまでどおりの構文で機能するため、上級ユーザーは短い構文を使用できます。

DataWeave 1

sizeOf payload filter $.age > 30

DataWeave 2 - 関数構文

sizeOf(filter(payload, (value) → value.age > 30)))

DataWeave 2 - 簡単な構文

sizeOf(payload filter $.age > 30)
## [](#特性は関数)特性は関数

DataWeave 1

payload is :empty

DataWeave 2

isEmpty(payload)
## [](#型名)型名 DataWeave 2 では型名構文が使用され、型名から ​`:`​ が除去されます。

DataWeave 1

payload.foo as :string

DataWeave 2

payload.foo as String
## [](#xml-形式)XML 形式 DataWeave 2.0 では、​`nullValueOn`​ リーダープロパティのデフォルト値が ​`empty`​ です。 DataWeave 1.0 (Mule 3.x に対応) の場合は、以下の例のとおり、この値が ​`none`​ です。 DataWeave スクリプト ```dataweave %dw 1.0 %output application/xml nullValueOn="none" --- payload ``` 入力 ```xml ``` 出力 ```xml ``` ## [](#新機能)新機能 以下をはじめとする多数の新機能が導入されています。 - 再利用可能な関数の入力 - 複数行のコメント - Java コードのコールアウト機能 - URL エンコードされたマルチパートのテキストリーダーおよびライター - モジュールとインポート - など ## [](#関連情報)関連情報 [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # Mule 4 の概要: DataWeave 2.0 DataWeave 2 はほぼ DataWeave 1 のままです。ただし、習得しやすいようにさまざまな点が改善され、新しい機能が追加されています。 ## [](#演算子は関数)演算子は関数 DataWeave 2 では、演算子がすべて関数になりました。このためコード上の括弧が増えるかもしれませんが、曖昧さが減少し、オートコンプリート機能を使用して習得しやすくなります。パラメーターが 2 つある関数はこれまでどおりの構文で機能するため、上級ユーザーは短い構文を使用できます。

DataWeave 1

sizeOf payload filter $.age > 30

DataWeave 2 - 関数構文

sizeOf(filter(payload, (value) → value.age > 30)))

DataWeave 2 - 簡単な構文

sizeOf(payload filter $.age > 30)
## [](#特性は関数)特性は関数

DataWeave 1

payload is :empty

DataWeave 2

isEmpty(payload)
## [](#型名)型名 DataWeave 2 では型名構文が使用され、型名から ​`:`​ が除去されます。

DataWeave 1

payload.foo as :string

DataWeave 2

payload.foo as String
## [](#xml-形式)XML 形式 DataWeave 2.0 では、​`nullValueOn`​ リーダープロパティのデフォルト値が ​`empty`​ です。 DataWeave 1.0 (Mule 3.x に対応) の場合は、以下の例のとおり、この値が ​`none`​ です。 DataWeave スクリプト ```dataweave %dw 1.0 %output application/xml nullValueOn="none" --- payload ``` 入力 ```xml ``` 出力 ```xml ``` ## [](#新機能)新機能 以下をはじめとする多数の新機能が導入されています。 - 再利用可能な関数の入力 - 複数行のコメント - Java コードのコールアウト機能 - URL エンコードされたマルチパートのテキストリーダーおよびライター - モジュールとインポート - など ## [](#関連情報)関連情報 [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # Mule 4 の概要: DataWeave 2.0 DataWeave 2 はほぼ DataWeave 1 のままです。ただし、習得しやすいようにさまざまな点が改善され、新しい機能が追加されています。 ## [](#演算子は関数)演算子は関数 DataWeave 2 では、演算子がすべて関数になりました。このためコード上の括弧が増えるかもしれませんが、曖昧さが減少し、オートコンプリート機能を使用して習得しやすくなります。パラメーターが 2 つある関数はこれまでどおりの構文で機能するため、上級ユーザーは短い構文を使用できます。

DataWeave 1

sizeOf payload filter $.age > 30

DataWeave 2 - 関数構文

sizeOf(filter(payload, (value) → value.age > 30)))

DataWeave 2 - 簡単な構文

sizeOf(payload filter $.age > 30)
## [](#特性は関数)特性は関数

DataWeave 1

payload is :empty

DataWeave 2

isEmpty(payload)
## [](#型名)型名 DataWeave 2 では型名構文が使用され、型名から ​`:`​ が除去されます。

DataWeave 1

payload.foo as :string

DataWeave 2

payload.foo as String
## [](#xml-形式)XML 形式 DataWeave 2.0 では、​`nullValueOn`​ リーダープロパティのデフォルト値が ​`empty`​ です。 DataWeave 1.0 (Mule 3.x に対応) の場合は、以下の例のとおり、この値が ​`none`​ です。 DataWeave スクリプト ```dataweave %dw 1.0 %output application/xml nullValueOn="none" --- payload ``` 入力 ```xml ``` 出力 ```xml ``` ## [](#新機能)新機能 以下をはじめとする多数の新機能が導入されています。 - 再利用可能な関数の入力 - 複数行のコメント - Java コードのコールアウト機能 - URL エンコードされたマルチパートのテキストリーダーおよびライター - モジュールとインポート - など ## [](#関連情報)関連情報 [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # Mule 4 の概要: DataWeave 2.0 DataWeave 2 はほぼ DataWeave 1 のままです。ただし、習得しやすいようにさまざまな点が改善され、新しい機能が追加されています。 ## [](#演算子は関数)演算子は関数 DataWeave 2 では、演算子がすべて関数になりました。このためコード上の括弧が増えるかもしれませんが、曖昧さが減少し、オートコンプリート機能を使用して習得しやすくなります。パラメーターが 2 つある関数はこれまでどおりの構文で機能するため、上級ユーザーは短い構文を使用できます。

DataWeave 1

sizeOf payload filter $.age > 30

DataWeave 2 - 関数構文

sizeOf(filter(payload, (value) → value.age > 30)))

DataWeave 2 - 簡単な構文

sizeOf(payload filter $.age > 30)
## [](#特性は関数)特性は関数

DataWeave 1

payload is :empty

DataWeave 2

isEmpty(payload)
## [](#型名)型名 DataWeave 2 では型名構文が使用され、型名から ​`:`​ が除去されます。

DataWeave 1

payload.foo as :string

DataWeave 2

payload.foo as String
## [](#xml-形式)XML 形式 DataWeave 2.0 では、​`nullValueOn`​ リーダープロパティのデフォルト値が ​`empty`​ です。 DataWeave 1.0 (Mule 3.x に対応) の場合は、以下の例のとおり、この値が ​`none`​ です。 DataWeave スクリプト ```dataweave %dw 1.0 %output application/xml nullValueOn="none" --- payload ``` 入力 ```xml ``` 出力 ```xml ``` ## [](#新機能)新機能 以下をはじめとする多数の新機能が導入されています。 - 再利用可能な関数の入力 - 複数行のコメント - Java コードのコールアウト機能 - URL エンコードされたマルチパートのテキストリーダーおよびライター - モジュールとインポート - など ## [](#関連情報)関連情報 [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # Mule 4 の概要: DataWeave 2.0 DataWeave 2 はほぼ DataWeave 1 のままです。ただし、習得しやすいようにさまざまな点が改善され、新しい機能が追加されています。 ## [](#演算子は関数)演算子は関数 DataWeave 2 では、演算子がすべて関数になりました。このためコード上の括弧が増えるかもしれませんが、曖昧さが減少し、オートコンプリート機能を使用して習得しやすくなります。パラメーターが 2 つある関数はこれまでどおりの構文で機能するため、上級ユーザーは短い構文を使用できます。

DataWeave 1

sizeOf payload filter $.age > 30

DataWeave 2 - 関数構文

sizeOf(filter(payload, (value) → value.age > 30)))

DataWeave 2 - 簡単な構文

sizeOf(payload filter $.age > 30)
## [](#特性は関数)特性は関数

DataWeave 1

payload is :empty

DataWeave 2

isEmpty(payload)
## [](#型名)型名 DataWeave 2 では型名構文が使用され、型名から ​`:`​ が除去されます。

DataWeave 1

payload.foo as :string

DataWeave 2

payload.foo as String
## [](#xml-形式)XML 形式 DataWeave 2.0 では、​`nullValueOn`​ リーダープロパティのデフォルト値が ​`empty`​ です。 DataWeave 1.0 (Mule 3.x に対応) の場合は、以下の例のとおり、この値が ​`none`​ です。 DataWeave スクリプト ```dataweave %dw 1.0 %output application/xml nullValueOn="none" --- payload ``` 入力 ```xml ``` 出力 ```xml ``` ## [](#新機能)新機能 以下をはじめとする多数の新機能が導入されています。 - 再利用可能な関数の入力 - 複数行のコメント - Java コードのコールアウト機能 - URL エンコードされたマルチパートのテキストリーダーおよびライター - モジュールとインポート - など ## [](#関連情報)関連情報 [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # Mule 4 の概要: DataWeave 2.0 DataWeave 2 はほぼ DataWeave 1 のままです。ただし、習得しやすいようにさまざまな点が改善され、新しい機能が追加されています。 ## [](#演算子は関数)演算子は関数 DataWeave 2 では、演算子がすべて関数になりました。このためコード上の括弧が増えるかもしれませんが、曖昧さが減少し、オートコンプリート機能を使用して習得しやすくなります。パラメーターが 2 つある関数はこれまでどおりの構文で機能するため、上級ユーザーは短い構文を使用できます。

DataWeave 1

sizeOf payload filter $.age > 30

DataWeave 2 - 関数構文

sizeOf(filter(payload, (value) → value.age > 30)))

DataWeave 2 - 簡単な構文

sizeOf(payload filter $.age > 30)
## [](#特性は関数)特性は関数

DataWeave 1

payload is :empty

DataWeave 2

isEmpty(payload)
## [](#型名)型名 DataWeave 2 では型名構文が使用され、型名から ​`:`​ が除去されます。

DataWeave 1

payload.foo as :string

DataWeave 2

payload.foo as String
## [](#xml-形式)XML 形式 DataWeave 2.0 では、​`nullValueOn`​ リーダープロパティのデフォルト値が ​`empty`​ です。 DataWeave 1.0 (Mule 3.x に対応) の場合は、以下の例のとおり、この値が ​`none`​ です。 DataWeave スクリプト ```dataweave %dw 1.0 %output application/xml nullValueOn="none" --- payload ``` 入力 ```xml ``` 出力 ```xml ``` ## [](#新機能)新機能 以下をはじめとする多数の新機能が導入されています。 - 再利用可能な関数の入力 - 複数行のコメント - Java コードのコールアウト機能 - URL エンコードされたマルチパートのテキストリーダーおよびライター - モジュールとインポート - など ## [](#関連情報)関連情報 [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # Mule 4 の概要: DataWeave 2.0 DataWeave 2 はほぼ DataWeave 1 のままです。ただし、習得しやすいようにさまざまな点が改善され、新しい機能が追加されています。 ## [](#演算子は関数)演算子は関数 DataWeave 2 では、演算子がすべて関数になりました。このためコード上の括弧が増えるかもしれませんが、曖昧さが減少し、オートコンプリート機能を使用して習得しやすくなります。パラメーターが 2 つある関数はこれまでどおりの構文で機能するため、上級ユーザーは短い構文を使用できます。

DataWeave 1

sizeOf payload filter $.age > 30

DataWeave 2 - 関数構文

sizeOf(filter(payload, (value) → value.age > 30)))

DataWeave 2 - 簡単な構文

sizeOf(payload filter $.age > 30)
## [](#特性は関数)特性は関数

DataWeave 1

payload is :empty

DataWeave 2

isEmpty(payload)
## [](#型名)型名 DataWeave 2 では型名構文が使用され、型名から ​`:`​ が除去されます。

DataWeave 1

payload.foo as :string

DataWeave 2

payload.foo as String
## [](#xml-形式)XML 形式 DataWeave 2.0 では、​`nullValueOn`​ リーダープロパティのデフォルト値が ​`empty`​ です。 DataWeave 1.0 (Mule 3.x に対応) の場合は、以下の例のとおり、この値が ​`none`​ です。 DataWeave スクリプト ```dataweave %dw 1.0 %output application/xml nullValueOn="none" --- payload ``` 入力 ```xml ``` 出力 ```xml ``` ## [](#新機能)新機能 以下をはじめとする多数の新機能が導入されています。 - 再利用可能な関数の入力 - 複数行のコメント - Java コードのコールアウト機能 - URL エンコードされたマルチパートのテキストリーダーおよびライター - モジュールとインポート - など ## [](#関連情報)関連情報 [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # Mule 4 の概要: DataWeave 式言語 Mule 3 では、Mule 式言語 (MEL) と DataWeave の両方を習得する必要があります。MEL の場合、バイナリデータ (XML や JSON ドキュメント) からのペイロードを Java オブジェクトに変換する必要があり、その結果、たとえばデータを特定の場所にルーティングするときに、そのデータにアクセスする式を記述できるようになります。 Mule 4 のデフォルトの式言語は DataWeave です。この変更を組み込みのストリーミング機能と組み合わせることで、多くの一般的なタスクが簡素化されます。 - ペイロードデータに基づいてイベントをルーティングできる (Java オブジェクトに変換する必要がない)。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - ストリーミングが透過的に行われるようになる。データストリームがメモリ量を上回っていないか、ストリームを二度コンシュームしていないかなどと心配する必要がなくなります。 DataWeave 2.0 にはさまざまな改良が行われており、詳細は​[「DataWeave 2.0」](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-dataweave2)​セクションに記載されています。 基本的に、式はこれまでと同じように機能します。データの抽出、データの記録、データのルーティング先の決定などに式を使用できます。MEL と同様、データのプロパティにアクセスする構文は極めてシンプルです。 ```xml ``` MEL と異なる点は、DataWeave を使用した場合、フロー内の任意の時点にあるデータに簡単にアクセスできることで、データを中間オブジェクトに変換すべきかどうか心配することがありません。Mule 3 では次の例のようになります。 ```xml ``` Mule 4 では、JSON を中間形式に変換する必要がありません。式を使用すると、元の基本的なデータを失うことなくデータに直接アクセスできます。そして、Mule 4 が自動的にデータストリーミングとランダムアクセスをすべて透過的に処理します。 ```xml ``` ## [](#関連情報)関連情報 [変換とストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-transformations) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # Mule 4 の概要: DataWeave 式言語 Mule 3 では、Mule 式言語 (MEL) と DataWeave の両方を習得する必要があります。MEL の場合、バイナリデータ (XML や JSON ドキュメント) からのペイロードを Java オブジェクトに変換する必要があり、その結果、たとえばデータを特定の場所にルーティングするときに、そのデータにアクセスする式を記述できるようになります。 Mule 4 のデフォルトの式言語は DataWeave です。この変更を組み込みのストリーミング機能と組み合わせることで、多くの一般的なタスクが簡素化されます。 - ペイロードデータに基づいてイベントをルーティングできる (Java オブジェクトに変換する必要がない)。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - ストリーミングが透過的に行われるようになる。データストリームがメモリ量を上回っていないか、ストリームを二度コンシュームしていないかなどと心配する必要がなくなります。 DataWeave 2.0 にはさまざまな改良が行われており、詳細は​[「DataWeave 2.0」](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-dataweave2)​セクションに記載されています。 基本的に、式はこれまでと同じように機能します。データの抽出、データの記録、データのルーティング先の決定などに式を使用できます。MEL と同様、データのプロパティにアクセスする構文は極めてシンプルです。 ```xml ``` MEL と異なる点は、DataWeave を使用した場合、フロー内の任意の時点にあるデータに簡単にアクセスできることで、データを中間オブジェクトに変換すべきかどうか心配することがありません。Mule 3 では次の例のようになります。 ```xml ``` Mule 4 では、JSON を中間形式に変換する必要がありません。式を使用すると、元の基本的なデータを失うことなくデータに直接アクセスできます。そして、Mule 4 が自動的にデータストリーミングとランダムアクセスをすべて透過的に処理します。 ```xml ``` ## [](#関連情報)関連情報 [変換とストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-transformations) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # Mule 4 の概要: DataWeave 式言語 Mule 3 では、Mule 式言語 (MEL) と DataWeave の両方を習得する必要があります。MEL の場合、バイナリデータ (XML や JSON ドキュメント) からのペイロードを Java オブジェクトに変換する必要があり、その結果、たとえばデータを特定の場所にルーティングするときに、そのデータにアクセスする式を記述できるようになります。 Mule 4 のデフォルトの式言語は DataWeave です。この変更を組み込みのストリーミング機能と組み合わせることで、多くの一般的なタスクが簡素化されます。 - ペイロードデータに基づいてイベントをルーティングできる (Java オブジェクトに変換する必要がない)。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - ストリーミングが透過的に行われるようになる。データストリームがメモリ量を上回っていないか、ストリームを二度コンシュームしていないかなどと心配する必要がなくなります。 DataWeave 2.0 にはさまざまな改良が行われており、詳細は​[「DataWeave 2.0」](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-dataweave2)​セクションに記載されています。 基本的に、式はこれまでと同じように機能します。データの抽出、データの記録、データのルーティング先の決定などに式を使用できます。MEL と同様、データのプロパティにアクセスする構文は極めてシンプルです。 ```xml ``` MEL と異なる点は、DataWeave を使用した場合、フロー内の任意の時点にあるデータに簡単にアクセスできることで、データを中間オブジェクトに変換すべきかどうか心配することがありません。Mule 3 では次の例のようになります。 ```xml ``` Mule 4 では、JSON を中間形式に変換する必要がありません。式を使用すると、元の基本的なデータを失うことなくデータに直接アクセスできます。そして、Mule 4 が自動的にデータストリーミングとランダムアクセスをすべて透過的に処理します。 ```xml ``` ## [](#関連情報)関連情報 [変換とストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-transformations) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # Mule 4 の概要: DataWeave 式言語 Mule 3 では、Mule 式言語 (MEL) と DataWeave の両方を習得する必要があります。MEL の場合、バイナリデータ (XML や JSON ドキュメント) からのペイロードを Java オブジェクトに変換する必要があり、その結果、たとえばデータを特定の場所にルーティングするときに、そのデータにアクセスする式を記述できるようになります。 Mule 4 のデフォルトの式言語は DataWeave です。この変更を組み込みのストリーミング機能と組み合わせることで、多くの一般的なタスクが簡素化されます。 - ペイロードデータに基づいてイベントをルーティングできる (Java オブジェクトに変換する必要がない)。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - ストリーミングが透過的に行われるようになる。データストリームがメモリ量を上回っていないか、ストリームを二度コンシュームしていないかなどと心配する必要がなくなります。 DataWeave 2.0 にはさまざまな改良が行われており、詳細は​[「DataWeave 2.0」](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-dataweave2)​セクションに記載されています。 基本的に、式はこれまでと同じように機能します。データの抽出、データの記録、データのルーティング先の決定などに式を使用できます。MEL と同様、データのプロパティにアクセスする構文は極めてシンプルです。 ```xml ``` MEL と異なる点は、DataWeave を使用した場合、フロー内の任意の時点にあるデータに簡単にアクセスできることで、データを中間オブジェクトに変換すべきかどうか心配することがありません。Mule 3 では次の例のようになります。 ```xml ``` Mule 4 では、JSON を中間形式に変換する必要がありません。式を使用すると、元の基本的なデータを失うことなくデータに直接アクセスできます。そして、Mule 4 が自動的にデータストリーミングとランダムアクセスをすべて透過的に処理します。 ```xml ``` ## [](#関連情報)関連情報 [変換とストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-transformations) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # Mule 4 の概要: DataWeave 式言語 Mule 3 では、Mule 式言語 (MEL) と DataWeave の両方を習得する必要があります。MEL の場合、バイナリデータ (XML や JSON ドキュメント) からのペイロードを Java オブジェクトに変換する必要があり、その結果、たとえばデータを特定の場所にルーティングするときに、そのデータにアクセスする式を記述できるようになります。 Mule 4 のデフォルトの式言語は DataWeave です。この変更を組み込みのストリーミング機能と組み合わせることで、多くの一般的なタスクが簡素化されます。 - ペイロードデータに基づいてイベントをルーティングできる (Java オブジェクトに変換する必要がない)。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - ストリーミングが透過的に行われるようになる。データストリームがメモリ量を上回っていないか、ストリームを二度コンシュームしていないかなどと心配する必要がなくなります。 DataWeave 2.0 にはさまざまな改良が行われており、詳細は​[「DataWeave 2.0」](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-dataweave2)​セクションに記載されています。 基本的に、式はこれまでと同じように機能します。データの抽出、データの記録、データのルーティング先の決定などに式を使用できます。MEL と同様、データのプロパティにアクセスする構文は極めてシンプルです。 ```xml ``` MEL と異なる点は、DataWeave を使用した場合、フロー内の任意の時点にあるデータに簡単にアクセスできることで、データを中間オブジェクトに変換すべきかどうか心配することがありません。Mule 3 では次の例のようになります。 ```xml ``` Mule 4 では、JSON を中間形式に変換する必要がありません。式を使用すると、元の基本的なデータを失うことなくデータに直接アクセスできます。そして、Mule 4 が自動的にデータストリーミングとランダムアクセスをすべて透過的に処理します。 ```xml ``` ## [](#関連情報)関連情報 [変換とストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-transformations) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # Mule 4 の概要: DataWeave 式言語 Mule 3 では、Mule 式言語 (MEL) と DataWeave の両方を習得する必要があります。MEL の場合、バイナリデータ (XML や JSON ドキュメント) からのペイロードを Java オブジェクトに変換する必要があり、その結果、たとえばデータを特定の場所にルーティングするときに、そのデータにアクセスする式を記述できるようになります。 Mule 4 のデフォルトの式言語は DataWeave です。この変更を組み込みのストリーミング機能と組み合わせることで、多くの一般的なタスクが簡素化されます。 - ペイロードデータに基づいてイベントをルーティングできる (Java オブジェクトに変換する必要がない)。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - ストリーミングが透過的に行われるようになる。データストリームがメモリ量を上回っていないか、ストリームを二度コンシュームしていないかなどと心配する必要がなくなります。 DataWeave 2.0 にはさまざまな改良が行われており、詳細は​[「DataWeave 2.0」](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-dataweave2)​セクションに記載されています。 基本的に、式はこれまでと同じように機能します。データの抽出、データの記録、データのルーティング先の決定などに式を使用できます。MEL と同様、データのプロパティにアクセスする構文は極めてシンプルです。 ```xml ``` MEL と異なる点は、DataWeave を使用した場合、フロー内の任意の時点にあるデータに簡単にアクセスできることで、データを中間オブジェクトに変換すべきかどうか心配することがありません。Mule 3 では次の例のようになります。 ```xml ``` Mule 4 では、JSON を中間形式に変換する必要がありません。式を使用すると、元の基本的なデータを失うことなくデータに直接アクセスできます。そして、Mule 4 が自動的にデータストリーミングとランダムアクセスをすべて透過的に処理します。 ```xml ``` ## [](#関連情報)関連情報 [変換とストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-transformations) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # Mule 4 の概要: DataWeave 式言語 Mule 3 では、Mule 式言語 (MEL) と DataWeave の両方を習得する必要があります。MEL の場合、バイナリデータ (XML や JSON ドキュメント) からのペイロードを Java オブジェクトに変換する必要があり、その結果、たとえばデータを特定の場所にルーティングするときに、そのデータにアクセスする式を記述できるようになります。 Mule 4 のデフォルトの式言語は DataWeave です。この変更を組み込みのストリーミング機能と組み合わせることで、多くの一般的なタスクが簡素化されます。 - ペイロードデータに基づいてイベントをルーティングできる (Java オブジェクトに変換する必要がない)。 - バイナリデータを、フロー内の任意の時点 (ログへの記録時など) の式から簡単に照会できる。 - ストリーミングが透過的に行われるようになる。データストリームがメモリ量を上回っていないか、ストリームを二度コンシュームしていないかなどと心配する必要がなくなります。 DataWeave 2.0 にはさまざまな改良が行われており、詳細は​[「DataWeave 2.0」](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-dataweave2)​セクションに記載されています。 基本的に、式はこれまでと同じように機能します。データの抽出、データの記録、データのルーティング先の決定などに式を使用できます。MEL と同様、データのプロパティにアクセスする構文は極めてシンプルです。 ```xml ``` MEL と異なる点は、DataWeave を使用した場合、フロー内の任意の時点にあるデータに簡単にアクセスできることで、データを中間オブジェクトに変換すべきかどうか心配することがありません。Mule 3 では次の例のようになります。 ```xml ``` Mule 4 では、JSON を中間形式に変換する必要がありません。式を使用すると、元の基本的なデータを失うことなくデータに直接アクセスできます。そして、Mule 4 が自動的にデータストリーミングとランダムアクセスをすべて透過的に処理します。 ```xml ``` ## [](#関連情報)関連情報 [変換とストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-transformations) [DataWeave 1.0 から 2.x への移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-dataweave) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # Mule 4 の概要: Java インテグレーション ## [](#式かコードか)式かコードか 経験豊富な Mule ユーザーであれば、Mule 4 ではアプリケーションの構造化について、式言語を使用すれば実行可能なことが制限されるアプローチを敢えて採用していることに気が付くでしょう。その目的は、フローロジックと、コードから抽出されるビジネスロジックを明確に分けておくことです。 フローのデータを抽出、クエリ、変換、その他の方法で処理する場合に推奨されるツールは、DataWeave の式と変換です。カスタムロジックの作成、Java オブジェクトのインスタンス化、任意のメソッドのコールを行う場合の MuleSoft の推奨方法は、このコードをスクリプトまたはクラスにカプセル化して、挿入やテストを簡単に実行できるようにすることです。 このため MuleSoft では Expression コンポーネントと Expression トランスフォーマーを排除し、代わりにロジックをスクリプトまたは Java クラスに明確に分離することを奨励しています。 ## [](#dataweave-からの静的-java-メソッドのコール)DataWeave からの静的 Java メソッドのコール データをフォーマットまたは解析するために Java ロジックをコールアウトしようとする場合に、DataWeave で静的メソッドをコールアウトできるようになりました。次の Java メソッドについて考えてみます。 ```java package org.acme; public class MyCompanyUtils { public static String reformat(String input) { return …; } } ``` このメソッドは次の DataWeave コードでコールできます。 ```dataweave import java!org::acme::MyCompanyUtils --- { date: MyCompanyUtils::reformat(payload.input) } ``` ## [](#scripting-module)Scripting Module Mule 3 の Scripting コンポーネントが Scripting Module になりました。Mule 4 のこのモジュールでは、Groovy、Ruby、Python、JavaScript などのスクリプトを Mule フロー内に埋め込むことができます。新しい ​`parameters`​ 設定属性を使用して、Mule メッセージのデータをコードに挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: payload.body}] ``` Scripting Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` このモジュールについての詳細は、​[「Scripting Module ドキュメント」](https://docs.mulesoft.com/jp/scripting-module/latest/)​を参照してください。 ## [](#java-module)Java Module Scripting Module は、ランダムな命令セットを実行して Java との連動を可能にする極めて強力なツールですが、単にクラスをインスタンス化したり、1 つのメソッドを実行するだけで事足りることも少なくありません。こうした場合、Mule 3 では通常 MEL を利用しますが、Mule 4 ではこのユースケースのために Java Module が導入されました。Java Module が Scripting Module に勝る他のメリットとして次の点が挙げられます - [DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​ をサポート: メソッドを実行するたびに、出力種別とメソッドの入力引数の DataSense を取得します。 - UI をサポート: 各クラスで使用可能なメソッドやオートコンプリートなどの視覚補助を備えています。 ### [](#新しい-java-インスタンスの作成)新しい Java インスタンスの作成 Mule 3 の場合: ```xml ``` Mule 4 の場合: ```xml #[{name: 'some string arg', apple: vars.apple}] ``` ### [](#インスタンスメソッドの呼び出し)インスタンスメソッドの呼び出し Mule 3 の場合: ```xml flowVars.appleEater.chew(500) ``` Mule 4 の場合: ```xml #[{chewingTime: 500}] ``` `invoke`​ 機能は、DataWeave の関数でも実行できます。 ```xml ``` Java Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.module mule-java-module 1.0.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) - [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # Mule 4 の概要: Java インテグレーション ## [](#式かコードか)式かコードか 経験豊富な Mule ユーザーであれば、Mule 4 ではアプリケーションの構造化について、式言語を使用すれば実行可能なことが制限されるアプローチを敢えて採用していることに気が付くでしょう。その目的は、フローロジックと、コードから抽出されるビジネスロジックを明確に分けておくことです。 フローのデータを抽出、クエリ、変換、その他の方法で処理する場合に推奨されるツールは、DataWeave の式と変換です。カスタムロジックの作成、Java オブジェクトのインスタンス化、任意のメソッドのコールを行う場合の MuleSoft の推奨方法は、このコードをスクリプトまたはクラスにカプセル化して、挿入やテストを簡単に実行できるようにすることです。 このため MuleSoft では Expression コンポーネントと Expression トランスフォーマーを排除し、代わりにロジックをスクリプトまたは Java クラスに明確に分離することを奨励しています。 ## [](#dataweave-からの静的-java-メソッドのコール)DataWeave からの静的 Java メソッドのコール データを書式設定または解析するために Java ロジックをコールアウトしようとする場合に、DataWeave で静的メソッドをコールアウトできるようになりました。次の Java メソッドについて考えてみます。 ```java package org.acme; public class MyCompanyUtils { public static String reformat(String input) { return …; } } ``` このメソッドは次の DataWeave コードでコールできます。 ```dataweave import java!org::acme::MyCompanyUtils --- { date: MyCompanyUtils::reformat(payload.input) } ``` ## [](#scripting-module)Scripting Module Mule 3 の Scripting コンポーネントが Scripting Module になりました。Mule 4 のこのモジュールでは、Groovy、Ruby、Python、JavaScript などのスクリプトを Mule フロー内に埋め込むことができます。新しい ​`parameters`​ 設定属性を使用して、Mule メッセージのデータをコードに挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: payload.body}] ``` Scripting Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` このモジュールについての詳細は、​[「Scripting Module ドキュメント」](https://docs.mulesoft.com/jp/scripting-module/latest/)​を参照してください。 ## [](#java-module)Java Module Scripting Module は、ランダムな命令セットを実行して Java との連動を可能にする極めて強力なツールですが、単にクラスをインスタンス化したり、1 つのメソッドを実行するだけで事足りることも少なくありません。こうした場合、Mule 3 では通常 MEL を利用しますが、Mule 4 ではこのユースケースのために Java Module が導入されました。Java Module が Scripting Module に勝る他のメリットとして次の点が挙げられます - [DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​ をサポート: メソッドを実行するたびに、出力種別とメソッドの入力引数の DataSense を取得します。 - UI をサポート: 各クラスで使用可能なメソッドやオートコンプリートなどの視覚補助を備えています。 ### [](#新しい-java-インスタンスの作成)新しい Java インスタンスの作成 Mule 3 の場合: ```xml ``` Mule 4 の場合: ```xml #[{name: 'some string arg', apple: vars.apple}] ``` ### [](#インスタンスメソッドの呼び出し)インスタンスメソッドの呼び出し Mule 3 の場合: ```xml flowVars.appleEater.chew(500) ``` Mule 4 の場合: ```xml #[{chewingTime: 500}] ``` `invoke`​ 機能は、DataWeave の関数でも実行できます。 ```xml ``` Java Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.module mule-java-module 1.0.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) - [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # Mule 4 の概要: Java インテグレーション ## [](#式かコードか)式かコードか 経験豊富な Mule ユーザーであれば、Mule 4 ではアプリケーションの構造化について、式言語を使用すれば実行可能なことが制限されるアプローチを敢えて採用していることに気が付くでしょう。その目的は、フローロジックと、コードから抽出されるビジネスロジックを明確に分けておくことです。 フローのデータを抽出、クエリ、変換、その他の方法で処理する場合に推奨されるツールは、DataWeave の式と変換です。カスタムロジックの作成、Java オブジェクトのインスタンス化、任意のメソッドのコールを行う場合の MuleSoft の推奨方法は、このコードをスクリプトまたはクラスにカプセル化して、挿入やテストを簡単に実行できるようにすることです。 このため MuleSoft では Expression コンポーネントと Expression トランスフォーマーを排除し、代わりにロジックをスクリプトまたは Java クラスに明確に分離することを奨励しています。 ## [](#dataweave-からの静的-java-メソッドのコール)DataWeave からの静的 Java メソッドのコール データをフォーマットまたは解析するために Java ロジックをコールアウトしようとする場合に、DataWeave で静的メソッドをコールアウトできるようになりました。次の Java メソッドについて考えてみます。 ```java package org.acme; public class MyCompanyUtils { public static String reformat(String input) { return …; } } ``` このメソッドは次の DataWeave コードでコールできます。 ```dataweave import java!org::acme::MyCompanyUtils --- { date: MyCompanyUtils::reformat(payload.input) } ``` ## [](#scripting-module)Scripting Module Mule 3 の Scripting コンポーネントが Scripting Module になりました。Mule 4 のこのモジュールでは、Groovy、Ruby、Python、JavaScript などのスクリプトを Mule フロー内に埋め込むことができます。新しい ​`parameters`​ 設定属性を使用して、Mule メッセージのデータをコードに挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: payload.body}] ``` Scripting Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` このモジュールについての詳細は、​[「Scripting Module ドキュメント」](https://docs.mulesoft.com/jp/scripting-module/latest/)​を参照してください。 ## [](#java-module)Java Module Scripting Module は、ランダムな命令セットを実行して Java との連動を可能にする極めて強力なツールですが、単にクラスをインスタンス化したり、1 つのメソッドを実行するだけで事足りることも少なくありません。こうした場合、Mule 3 では通常 MEL を利用しますが、Mule 4 ではこのユースケースのために Java Module が導入されました。Java Module が Scripting Module に勝る他のメリットとして次の点が挙げられます。 - [DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​ をサポート: メソッドを実行するたびに、出力種別とメソッドの入力引数の DataSense を取得します。 - UI をサポート: 各クラスで使用可能なメソッドやオートコンプリートなどの視覚補助を備えています。 ### [](#新しい-java-インスタンスの作成)新しい Java インスタンスの作成 Mule 3 の場合: ```xml ``` Mule 4 の場合: ```xml #[{name: 'some string arg', apple: vars.apple}] ``` ### [](#インスタンスメソッドの呼び出し)インスタンスメソッドの呼び出し Mule 3 の場合: ```xml flowVars.appleEater.chew(500) ``` Mule 4 の場合: ```xml #[{chewingTime: 500}] ``` `invoke`​ 機能は、DataWeave の関数でも実行できます。 ```xml ``` Java Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.module mule-java-module 1.0.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) - [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # Mule 4 の概要: Java インテグレーション ## [](#式かコードか)式かコードか 経験豊富な Mule ユーザーであれば、Mule 4 ではアプリケーションの構造化について、式言語を使用すれば実行可能なことが制限されるアプローチを敢えて採用していることに気が付くでしょう。その目的は、フローロジックと、コードから抽出されるビジネスロジックを明確に分けておくことです。 フローのデータを抽出、クエリ、変換、その他の方法で処理する場合に推奨されるツールは、DataWeave の式と変換です。カスタムロジックの作成、Java オブジェクトのインスタンス化、任意のメソッドのコールを行う場合の MuleSoft の推奨方法は、このコードをスクリプトまたはクラスにカプセル化して、挿入やテストを簡単に実行できるようにすることです。 このため MuleSoft では Expression コンポーネントと Expression トランスフォーマーを排除し、代わりにロジックをスクリプトまたは Java クラスに明確に分離することを奨励しています。 ## [](#dataweave-からの静的-java-メソッドのコール)DataWeave からの静的 Java メソッドのコール データを書式設定または解析するために Java ロジックをコールアウトしようとする場合に、DataWeave で静的メソッドをコールアウトできるようになりました。次の Java メソッドについて考えてみます。 ```java package org.acme; public class MyCompanyUtils { public static String reformat(String input) { return …; } } ``` このメソッドは次の DataWeave コードでコールできます。 ```dataweave import java!org::acme::MyCompanyUtils --- { date: MyCompanyUtils::reformat(payload.input) } ``` ## [](#scripting-module)Scripting Module Mule 3 の Scripting コンポーネントが Scripting Module になりました。Mule 4 のこのモジュールでは、Groovy、Ruby、Python、JavaScript などのスクリプトを Mule フロー内に埋め込むことができます。新しい ​`parameters`​ 設定属性を使用して、Mule メッセージのデータをコードに挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: payload.body}] ``` Scripting Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` このモジュールについての詳細は、​[「Scripting Module ドキュメント」](https://docs.mulesoft.com/jp/scripting-module/latest/)​を参照してください。 ## [](#java-モジュール)Java モジュール Scripting Module は、ランダムな命令セットを実行して Java との連動を可能にする極めて強力なツールですが、単にクラスをインスタンス化したり、1 つのメソッドを実行するだけで事足りることも少なくありません。こうした場合、Mule 3 では通常 MEL を利用しますが、Mule 4 ではこのユースケースのために Java モジュールが導入されました。Java Module が Scripting Module に勝る他のメリットとして次の点が挙げられます。 - [DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​ をサポート: メソッドを実行するたびに、出力種別とメソッドの入力引数の DataSense を取得します。 - UI をサポート: 各クラスで使用可能なメソッドやオートコンプリートなどの視覚補助を備えています。 ### [](#新しい-java-インスタンスの作成)新しい Java インスタンスの作成 Mule 3 の場合: ```xml ``` Mule 4 の場合: ```xml #[{name: 'some string arg', apple: vars.apple}] ``` ### [](#インスタンスメソッドの呼び出し)インスタンスメソッドの呼び出し Mule 3 の場合: ```xml flowVars.appleEater.chew(500) ``` Mule 4 の場合: ```xml #[{chewingTime: 500}] ``` `invoke`​ 機能は、DataWeave の関数でも実行できます。 ```xml ``` Java モジュールを使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.module mule-java-module 1.0.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) - [Java モジュール](https://docs.mulesoft.com/jp/java-module/latest/) # Mule 4 の概要: Java インテグレーション ## [](#式かコードか)式かコードか 経験豊富な Mule ユーザーであれば、Mule 4 ではアプリケーションの構造化について、式言語を使用すれば実行可能なことが制限されるアプローチを敢えて採用していることに気が付くでしょう。その目的は、フローロジックと、コードから抽出されるビジネスロジックを明確に分けておくことです。 フローのデータを抽出、クエリ、変換、その他の方法で処理する場合に推奨されるツールは、DataWeave の式と変換です。カスタムロジックの作成、Java オブジェクトのインスタンス化、任意のメソッドのコールを行う場合の MuleSoft の推奨方法は、このコードをスクリプトまたはクラスにカプセル化して、挿入やテストを簡単に実行できるようにすることです。 このため MuleSoft では Expression コンポーネントと Expression トランスフォーマーを排除し、代わりにロジックをスクリプトまたは Java クラスに明確に分離することを奨励しています。 ## [](#dataweave-からの静的-java-メソッドのコール)DataWeave からの静的 Java メソッドのコール データを書式設定または解析するために Java ロジックをコールアウトしようとする場合に、DataWeave で静的メソッドをコールアウトできるようになりました。次の Java メソッドについて考えてみます。 ```java package org.acme; public class MyCompanyUtils { public static String reformat(String input) { return …; } } ``` このメソッドは次の DataWeave コードでコールできます。 ```dataweave import java!org::acme::MyCompanyUtils --- { date: MyCompanyUtils::reformat(payload.input) } ``` ## [](#scripting-module)Scripting Module Mule 3 の Scripting コンポーネントが Scripting Module になりました。Mule 4 のこのモジュールでは、Groovy、Ruby、Python、JavaScript などのスクリプトを Mule フロー内に埋め込むことができます。新しい ​`parameters`​ 設定属性を使用して、Mule メッセージのデータをコードに挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: payload.body}] ``` Scripting Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` このモジュールについての詳細は、​[「Scripting Module ドキュメント」](https://docs.mulesoft.com/jp/scripting-module/latest/)​を参照してください。 ## [](#java-module)Java Module Scripting Module は、ランダムな命令セットを実行して Java との連動を可能にする極めて強力なツールですが、単にクラスをインスタンス化したり、1 つのメソッドを実行するだけで事足りることも少なくありません。こうした場合、Mule 3 では通常 MEL を利用しますが、Mule 4 ではこのユースケースのために Java Module が導入されました。Java Module が Scripting Module に勝る他のメリットとして次の点が挙げられます - [DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​ をサポート: メソッドを実行するたびに、出力種別とメソッドの入力引数の DataSense を取得します。 - UI をサポート: 各クラスで使用可能なメソッドやオートコンプリートなどの視覚補助を備えています。 ### [](#新しい-java-インスタンスの作成)新しい Java インスタンスの作成 Mule 3 の場合: ```xml ``` Mule 4 の場合: ```xml #[{name: 'some string arg', apple: vars.apple}] ``` ### [](#インスタンスメソッドの呼び出し)インスタンスメソッドの呼び出し Mule 3 の場合: ```xml flowVars.appleEater.chew(500) ``` Mule 4 の場合: ```xml #[{chewingTime: 500}] ``` `invoke`​ 機能は、DataWeave の関数でも実行できます。 ```xml ``` Java Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.module mule-java-module 1.0.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) - [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # Mule 4 の概要: Java インテグレーション ## [](#式かコードか)式かコードか 経験豊富な Mule ユーザーであれば、Mule 4 ではアプリケーションの構造化について、式言語を使用すれば実行可能なことが制限されるアプローチを敢えて採用していることに気が付くでしょう。その目的は、フローロジックと、コードから抽出されるビジネスロジックを明確に分けておくことです。 フローのデータを抽出、クエリ、変換、その他の方法で処理する場合に推奨されるツールは、DataWeave の式と変換です。カスタムロジックの作成、Java オブジェクトのインスタンス化、任意のメソッドのコールを行う場合の MuleSoft の推奨方法は、このコードをスクリプトまたはクラスにカプセル化して、挿入やテストを簡単に実行できるようにすることです。 このため MuleSoft では Expression コンポーネントと Expression トランスフォーマーを排除し、代わりにロジックをスクリプトまたは Java クラスに明確に分離することを奨励しています。 ## [](#dataweave-からの静的-java-メソッドのコール)DataWeave からの静的 Java メソッドのコール データを書式設定または解析するために Java ロジックをコールアウトしようとする場合に、DataWeave で静的メソッドをコールアウトできるようになりました。次の Java メソッドについて考えてみます。 ```java package org.acme; public class MyCompanyUtils { public static String reformat(String input) { return …; } } ``` このメソッドは次の DataWeave コードでコールできます。 ```dataweave import java!org::acme::MyCompanyUtils --- { date: MyCompanyUtils::reformat(payload.input) } ``` ## [](#scripting-module)Scripting Module Mule 3 の Scripting コンポーネントが Scripting Module になりました。Mule 4 のこのモジュールでは、Groovy、Ruby、Python、JavaScript などのスクリプトを Mule フロー内に埋め込むことができます。新しい ​`parameters`​ 設定属性を使用して、Mule メッセージのデータをコードに挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: payload.body}] ``` Scripting Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` このモジュールについての詳細は、​[「Scripting Module ドキュメント」](https://docs.mulesoft.com/jp/scripting-module/latest/)​を参照してください。 ## [](#java-module)Java Module Scripting Module は、ランダムな命令セットを実行して Java との連動を可能にする極めて強力なツールですが、単にクラスをインスタンス化したり、1 つのメソッドを実行するだけで事足りることも少なくありません。こうした場合、Mule 3 では通常 MEL を利用しますが、Mule 4 ではこのユースケースのために Java Module が導入されました。Java Module が Scripting Module に勝る他のメリットとして次の点が挙げられます - [DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​ をサポート: メソッドを実行するたびに、出力種別とメソッドの入力引数の DataSense を取得します。 - UI をサポート: 各クラスで使用可能なメソッドやオートコンプリートなどの視覚補助を備えています。 ### [](#新しい-java-インスタンスの作成)新しい Java インスタンスの作成 Mule 3 の場合: ```xml ``` Mule 4 の場合: ```xml #[{name: 'some string arg', apple: vars.apple}] ``` ### [](#インスタンスメソッドの呼び出し)インスタンスメソッドの呼び出し Mule 3 の場合: ```xml flowVars.appleEater.chew(500) ``` Mule 4 の場合: ```xml #[{chewingTime: 500}] ``` `invoke`​ 機能は、DataWeave の関数でも実行できます。 ```xml ``` Java Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.module mule-java-module 1.0.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) - [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # Mule 4 の概要: Java インテグレーション ## [](#式かコードか)式かコードか 経験豊富な Mule ユーザーであれば、Mule 4 ではアプリケーションの構造化について、式言語を使用すれば実行可能なことが制限されるアプローチを敢えて採用していることに気が付くでしょう。その目的は、フローロジックと、コードから抽出されるビジネスロジックを明確に分けておくことです。 フローのデータを抽出、クエリ、変換、その他の方法で処理する場合に推奨されるツールは、DataWeave の式と変換です。カスタムロジックの作成、Java オブジェクトのインスタンス化、任意のメソッドのコールを行う場合の MuleSoft の推奨方法は、このコードをスクリプトまたはクラスにカプセル化して、挿入やテストを簡単に実行できるようにすることです。 このため MuleSoft では Expression コンポーネントと Expression トランスフォーマーを排除し、代わりにロジックをスクリプトまたは Java クラスに明確に分離することを奨励しています。 ## [](#dataweave-からの静的-java-メソッドのコール)DataWeave からの静的 Java メソッドのコール データを書式設定または解析するために Java ロジックをコールアウトしようとする場合に、DataWeave で静的メソッドをコールアウトできるようになりました。次の Java メソッドについて考えてみます。 ```java package org.acme; public class MyCompanyUtils { public static String reformat(String input) { return …; } } ``` このメソッドは次の DataWeave コードでコールできます。 ```dataweave import java!org::acme::MyCompanyUtils --- { date: MyCompanyUtils::reformat(payload.input) } ``` ## [](#scripting-module)Scripting Module Mule 3 の Scripting コンポーネントが Scripting Module になりました。Mule 4 のこのモジュールでは、Groovy、Ruby、Python、JavaScript などのスクリプトを Mule フロー内に埋め込むことができます。新しい ​`parameters`​ 設定属性を使用して、Mule メッセージのデータをコードに挿入できます。 ```xml return "$payload $prop1 $prop2" #[{prop1: "Received", prop2: payload.body}] ``` Scripting Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` このモジュールについての詳細は、​[「Scripting Module ドキュメント」](https://docs.mulesoft.com/jp/scripting-module/latest/)​を参照してください。 ## [](#java-module)Java Module Scripting Module は、ランダムな命令セットを実行して Java との連動を可能にする極めて強力なツールですが、単にクラスをインスタンス化したり、1 つのメソッドを実行するだけで事足りることも少なくありません。こうした場合、Mule 3 では通常 MEL を利用しますが、Mule 4 ではこのユースケースのために Java Module が導入されました。Java Module が Scripting Module に勝る他のメリットとして次の点が挙げられます - [DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​ をサポート: メソッドを実行するたびに、出力種別とメソッドの入力引数の DataSense を取得します。 - UI をサポート: 各クラスで使用可能なメソッドやオートコンプリートなどの視覚補助を備えています。 ### [](#新しい-java-インスタンスの作成)新しい Java インスタンスの作成 Mule 3 の場合: ```xml ``` Mule 4 の場合: ```xml #[{name: 'some string arg', apple: vars.apple}] ``` ### [](#インスタンスメソッドの呼び出し)インスタンスメソッドの呼び出し Mule 3 の場合: ```xml flowVars.appleEater.chew(500) ``` Mule 4 の場合: ```xml #[{chewingTime: 500}] ``` `invoke`​ 機能は、DataWeave の関数でも実行できます。 ```xml ``` Java Module を使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.module mule-java-module 1.0.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) - [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # Mule 4 の概要: Mule アプリケーションの設定 Mule 3 では、デプロイした環境に合わせてアプリケーションを動的に設定するために、Spring プロパティがよく使用されていました。Mule 4 にはこのための組み込みメカニズムがあり、デフォルト値を設定できるため、Spring を学習する必要がなくなりました。 次のプロパティが YAML ファイルに保存されます。 ```yaml http: path: service port: "10000" ``` YAML ファイルを Mule アプリケーションに追加するには、設定プロパティと呼ばれるグローバル要素を使用します。この要素の XML は次のようになります。 ```xml ``` アプリケーション内のすべての環境の設定ファイルをパッケージ化しないことを強くお勧めします。その代わりに、このファイルをデフォルトとして、デプロイ時に Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#関連情報)関連情報 [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties) # Mule 4 の概要: Mule アプリケーションの設定 Mule 3 では、デプロイした環境に合わせてアプリケーションを動的に設定するために、Spring プロパティがよく使用されていました。Mule 4 にはこのための組み込みメカニズムがあり、デフォルト値を設定できるため、Spring を学習する必要がなくなりました。 次のプロパティが YAML ファイルに保存されます。 ```yaml http: path: service port: "10000" ``` YAML ファイルを Mule アプリケーションに追加するには、設定プロパティと呼ばれるグローバル要素を使用します。この要素の XML は次のようになります。 ```xml ``` アプリケーション内のすべての環境の設定ファイルをパッケージ化しないことを強くお勧めします。その代わりに、このファイルをデフォルトとして、デプロイ時に Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#関連情報)関連情報 [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties) # Mule 4 の概要: Mule アプリケーションの設定 Mule 3 では、デプロイした環境に合わせてアプリケーションを動的に設定するために、Spring プロパティがよく使用されていました。Mule 4 にはこのための組み込みメカニズムがあり、デフォルト値を設定できるため、Spring を学習する必要がなくなりました。 次のプロパティが YAML ファイルに保存されます。 ```yaml http: path: service port: "10000" ``` YAML ファイルを Mule アプリケーションに追加するには、設定プロパティと呼ばれるグローバル要素を使用します。この要素の XML は次のようになります。 ```xml ``` アプリケーション内のすべての環境の設定ファイルをパッケージ化しないことを強くお勧めします。その代わりに、このファイルをデフォルトとして、デプロイ時に Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#関連情報)関連情報 [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties) # Mule 4 の概要: Mule アプリケーションの設定 Mule 3 では、デプロイした環境に合わせてアプリケーションを動的に設定するために、Spring プロパティがよく使用されていました。Mule 4 にはこのための組み込みメカニズムがあり、デフォルト値を設定できるため、Spring を学習する必要がなくなりました。 次のプロパティが YAML ファイルに保存されます。 ```yaml http: path: service port: "10000" ``` YAML ファイルを Mule アプリケーションに追加するには、設定プロパティと呼ばれるグローバル要素を使用します。この要素の XML は次のようになります。 ```xml ``` アプリケーション内のすべての環境の設定ファイルをパッケージ化しないことを強くお勧めします。その代わりに、このファイルをデフォルトとして、デプロイ時に Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#関連情報)関連情報 [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties) # Mule 4 の概要: Mule アプリケーションの設定 Mule 3 では、デプロイした環境に合わせてアプリケーションを動的に設定するために、Spring プロパティがよく使用されていました。Mule 4 にはこのための組み込みメカニズムがあり、デフォルト値を設定できるため、Spring を学習する必要がなくなりました。 次のプロパティが YAML ファイルに保存されます。 ```yaml http: path: service port: "10000" ``` YAML ファイルを Mule アプリケーションに追加するには、設定プロパティと呼ばれるグローバル要素を使用します。この要素の XML は次のようになります。 ```xml ``` アプリケーション内のすべての環境の設定ファイルをパッケージ化しないことを強くお勧めします。その代わりに、このファイルをデフォルトとして、デプロイ時に Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#関連情報)関連情報 [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties) # Mule 4 の概要: Mule アプリケーションの設定 Mule 3 では、デプロイした環境に合わせてアプリケーションを動的に設定するために、Spring プロパティがよく使用されていました。Mule 4 にはこのための組み込みメカニズムがあり、デフォルト値を設定できるため、Spring を学習する必要がなくなりました。 次のプロパティが YAML ファイルに保存されます。 ```yaml http: path: service port: "10000" ``` YAML ファイルを Mule アプリケーションに追加するには、設定プロパティと呼ばれるグローバル要素を使用します。この要素の XML は次のようになります。 ```xml ``` アプリケーション内のすべての環境の設定ファイルをパッケージ化しないことを強くお勧めします。その代わりに、このファイルをデフォルトとして、デプロイ時に Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#関連情報)関連情報 [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties) # Mule 4 の概要: Mule アプリケーションの設定 Mule 3 では、デプロイした環境に合わせてアプリケーションを動的に設定するために、Spring プロパティがよく使用されていました。Mule 4 にはこのための組み込みメカニズムがあり、デフォルト値を設定できるため、Spring を学習する必要がなくなりました。 次のプロパティが YAML ファイルに保存されます。 ```yaml http: path: service port: "10000" ``` YAML ファイルを Mule アプリケーションに追加するには、設定プロパティと呼ばれるグローバル要素を使用します。この要素の XML は次のようになります。 ```xml ``` アプリケーション内のすべての環境の設定ファイルをパッケージ化しないことを強くお勧めします。その代わりに、このファイルをデフォルトとして、デプロイメント時に Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#関連情報)関連情報 [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties) # Mule 4 の概要: Mule メッセージ Mule 4 には簡素化された Mule メッセージモデルがあり、各 Mule イベントにはメッセージと関連する変数が定義されています。 - Mule メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。 - 操作の結果や補助値など、任意のユーザー情報が保持される変数 (​`vars`​)。一般に、操作では変数が他のコンポーネント (リスナーなど) に自動的に伝播されることはありません。ただし、Flow Reference コンポーネントを使用した場合は、フロー内で変数が伝播されます。 メッセージモデルが簡素化されたことで、どのコネクタでも一貫した方法でデータを簡単に操作できるようになり、情報が上書きされることがありません。 ![Mule イベントとメッセージ](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-message-diagram.png) Figure 1. Mule イベントとメッセージ。 ## [](#インバウンドプロパティが属性に)インバウンドプロパティが属性に Mule 3 ではインバウンドプロパティに、メッセージソースから取得されたペイロードに関する追加情報が保存されていました (HTTP リスナー経由で受け取るクエリパラメーターなど)。 Mule 4 では、インバウンドプロパティが​**属性**​になりました。属性には次の利点があります。 - 強く型付けされるため、どのデータを使用できるかがすぐにわかる。 - 変数に簡単に保存して、フローのどの時点でもアクセスできる。以下は、Mule 4 の典型的な Mule メッセージの HTTP リスナーの一例です。 ![Mule 4 の Mule メッセージの構造](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mule-message.png) Mule 3 のインバウンドプロパティの場合と同様に、属性も式を使用して簡単にアクセスできます。 ```text #[attributes.requestPath] #[attributes.queryParams.searchCriteria] ``` ソースや操作から新しいメッセージが生成されると、​**メッセージの両方の部分 (ペイロードと属性) が新しい値に置換され**​、以前の属性は失われます。操作の呼び出し間で属性からの情報を保持する必要がある場合は、以前の属性を変数に保存するか、​[呼び出された操作で ​`target`​ パラメーターを設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/target-variables)​することができます。 以下は、フローの実行時にメッセージがどのように更新されるかを示す一例です。 ```xml (1) (2) (3) #[output application/xml --- { data: payload, customer: attributes.queryParams.customer_id (4) }] (5) #[output application/json --- { customer: requestAttributes.queryParams.customer_id, (6) invoiceTrackingNumber: attributes.properties.userProperties.invoiceTrackingNumber }] (7) (8) ```
1要求が受信され、​http:listener​ が要求ペイロードと HTTP 属性からなるメッセージを生成します。
2logger​ は void の操作で、何ら出力を生成しないため、実行後もメッセージは同じままです。
3この例では、次の操作で現在のメッセージが置換されるため、現在の HTTP 属性を変数に保存して、その後のフローで利用できるようにします。
4その後も HTTP 属性を使用して ​jms:publish-consume​ 操作の入力を設定できます。
5jms:publish-consume​ が呼び出された場合、この操作の出力は、別のペイロードと JMS 属性からなるメッセージです。
6HTTP 属性が変数に保存されているため、現在の JMS 属性 (​attributes​ として) と以前に保存した HTTP 情報の両方を使用できます。
7jms:publish​ 操作も void です。何ら出力が生成されないため、メッセージはそのままです。
8この時点で、​jms:publish-consume​ 呼び出しの JMS 属性がそのまま存在します。
## [](#アウトバウンドプロパティ)アウトバウンドプロパティ Mule 3 では、ヘッダーなどの追加データを送信する必要のある Mule のコネクタやトランスポートに、アウトバウンドプロパティを明示的に指定する必要があります。たとえば、HTTP リスナーの場合、送信状況コード応答やヘッダーの指定が必要になることがあります。Mule 4 では、各々に DataWeave 式を使用してこれらの情報を個別に設定でき、メインのフローに副次的影響が及ぶことがありません。 ```xml #[{'path':'input/issues-list.json'}] #[{'provider':'memory-provider'}] ``` 上記の例では、HTTP 要求を実行すると個々の DataWeave スクリプトによってヘッダーやクエリパラメーターが生成されますが、メッセージのプロパティを設定する必要はなく、メッセージへの副次的な影響もありません。 応答を生成するメッセージソース (HTTP リスナーなど) にも同じ概念を適用できます。 ```xml #[vars.outboundHeaders default {}] #[payload] #[vars.outboundHeaders default {}] ``` 上の例では、​`vars.httpStatus default 200`​ のような ​`http:headers`​ 設定は、実際の値が ​`null`​ になる場合に変数のデフォルト値を設定します。 ## [](#セッションプロパティ)セッションプロパティ セッションプロパティが不要になり、Mule 4 で排除されています。 代わりに、Target (対象) (​`target`​) パラメーターを使用して対象変数にデータを保存します。 セッションプロパティが不要になった理由は、Mule 4 には Mule 3 のトランスポートや関連するトランスポートバリアーが存在しないためです。Mule 3 のトランスポートバリアーは、Mule 3 のフローを進行する Mule メッセージデータの処理方法を決定します。Mule 4 では、トランスポートが対応する Mule Connector (FTP Connector など) に切り替えられ、これらのコネクタがネットワーキングトランスポートプロトコルを異なる方法で処理します。 例については、​[「対象変数への Enricher の移行」](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-core-enricher)​および​[「対象変数を使用したデータの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.3/target-variables)​を参照してください。 ## [](#attachments-添付ファイル)Attachments (添付ファイル) 受信および送信の添付ファイルが排除されました。現在は関与するコネクタが添付の概念を独自の方法で処理します。 - HTTP Connector は DataWeave のマルチパート形式のサポートを利用します。 - Email Connector と Web Service Consumer Connector は、DataWeave を使用して添付ファイルを明示的に追加できます。 ## [](#メッセージのコレクション)メッセージのコレクション Mule メッセージの新しい構造の利点の 1 つが、コレクションの処理です。Mule 3 で複数のペイロードを返すコンポーネントは、​`MuleMessageCollection`​ という特殊な構造を使用していました。Mule 4 では、コンポーネントで複数のメッセージを処理する必要がある場合、単にメッセージのペイロードを Mule メッセージのリストに設定できます。そして、DataWeave、For Each などのコンポーネントを使用して、これらのメッセージを反復処理できます。 たとえば、​``​ 操作はメッセージのリストを取得します。メッセージごとに各ファイルの属性があるため、ファイルサイズやディレクトリかどうかなどに基づいて簡単に判断することができます。 ## [](#関連情報)関連情報 - [HTTP Connector の使用の移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-connectors-http) - [サポートされるデータ形式](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats) - [DataWeave 変数](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-variables) - [対象変数への Enricher の移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-core-enricher) # Mule 4 の概要: Mule メッセージ Mule 4 には簡素化された Mule メッセージモデルがあり、各 Mule イベントにはメッセージと関連する変数が定義されています。 - Mule メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。 - 操作の結果や補助値など、任意のユーザー情報が保持される変数 (​`vars`​)。一般に、操作では変数が他のコンポーネント (リスナーなど) に自動的に伝播されることはありません。ただし、Flow Reference コンポーネントを使用した場合は、フロー内で変数が伝播されます。 メッセージモデルが簡素化されたことで、どのコネクタでも一貫した方法でデータを簡単に操作できるようになり、情報が上書きされることがありません。 ![Mule イベントとメッセージ](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-message-diagram.png) Figure 1. Mule イベントとメッセージ。 ## [](#インバウンドプロパティが属性に)インバウンドプロパティが属性に Mule 3 ではインバウンドプロパティに、Mule イベントソースから取得されたペイロードに関する追加情報が保存されていました (HTTP リスナー経由で受け取るクエリパラメーターなど)。 Mule 4 では、インバウンドプロパティが​**属性**​になりました。属性には次の利点があります。 - 強く型付けされるため、どのデータを使用できるかがすぐにわかる。 - 変数に簡単に保存して、フローのどの時点でもアクセスできる。以下は、Mule 4 の典型的な Mule メッセージの HTTP リスナーの一例です。 ![Mule 4 の Mule メッセージの構造](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mule-message.png) Mule 3 のインバウンドプロパティの場合と同様に、属性も式を使用して簡単にアクセスできます。 ```text #[attributes.requestPath] #[attributes.queryParams.searchCriteria] ``` ソースや操作から新しいメッセージが生成されると、​**メッセージの両方の部分 (ペイロードと属性) が新しい値に置換され**​、以前の属性は失われます。操作の呼び出し間で属性からの情報を保持する必要がある場合は、以前の属性を変数に保存するか、​[呼び出された操作で ​`target`​ パラメーターを設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/target-variables)​することができます。 以下は、フローの実行時にメッセージがどのように更新されるかを示す一例です。 ```xml (1) (2) (3) #[output application/xml --- { data: payload, customer: attributes.queryParams.customer_id (4) }] (5) #[output application/json --- { customer: requestAttributes.queryParams.customer_id, (6) invoiceTrackingNumber: attributes.properties.userProperties.invoiceTrackingNumber }] (7) (8) ```
1要求が受信され、​http:listener​ が要求ペイロードと HTTP 属性からなるメッセージを生成します。
2logger​ は void の操作で、何ら出力を生成しないため、実行後もメッセージは同じままです。
3この例では、次の操作で現在のメッセージが置換されるため、現在の HTTP 属性を変数に保存して、その後のフローで利用できるようにします。
4その後も HTTP 属性を使用して ​jms:publish-consume​ 操作の入力を設定できます。
5jms:publish-consume​ が呼び出された場合、この操作の出力は、別のペイロードと JMS 属性からなるメッセージです。
6HTTP 属性が変数に保存されているため、現在の JMS 属性 (​attributes​ として) と以前に保存した HTTP 情報の両方を使用できます。
7jms:publish​ 操作も void です。何ら出力が生成されないため、メッセージはそのままです。
8この時点で、​jms:publish-consume​ 呼び出しの JMS 属性がそのまま存在します。
## [](#アウトバウンドプロパティ)アウトバウンドプロパティ Mule 3 では、ヘッダーなどの追加データを送信する必要のある Mule のコネクタやトランスポートに、アウトバウンドプロパティを明示的に指定する必要があります。たとえば、HTTP リスナーの場合、送信状況コード応答やヘッダーの指定が必要になることがあります。Mule 4 では、各々に DataWeave 式を使用してこれらの情報を個別に設定でき、メインのフローに副次的影響が及ぶことがありません。 ```xml #[{'path':'input/issues-list.json'}] #[{'provider':'memory-provider'}] ``` 上記の例では、HTTP 要求を実行すると個々の DataWeave スクリプトによってヘッダーやクエリパラメーターが生成されますが、メッセージのプロパティを設定する必要はなく、メッセージへの副次的な影響もありません。 応答を生成する Mule イベントソース (HTTP リスナーなど) にも同じ概念を適用できます。 ```xml #[vars.outboundHeaders default {}] #[payload] #[vars.outboundHeaders default {}] ``` 上の例では、​`vars.httpStatus default 200`​ のような ​`http:headers`​ 設定は、実際の値が ​`null`​ になる場合に変数のデフォルト値を設定します。 ## [](#セッションプロパティ)セッションプロパティ セッションプロパティが不要になり、Mule 4 で排除されています。 代わりに、Target (対象) (​`target`​) パラメーターを使用して対象変数にデータを保存します。 セッションプロパティが不要になった理由は、Mule 4 には Mule 3 のトランスポートや関連するトランスポートバリアーが存在しないためです。Mule 3 のトランスポートバリアーは、Mule 3 のフローを進行する Mule メッセージデータの処理方法を決定します。Mule 4 では、トランスポートが対応する Mule Connector (FTP Connector など) に切り替えられ、これらのコネクタがネットワーキングトランスポートプロトコルを異なる方法で処理します。 例については、​[「対象変数への Enricher の移行」](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-core-enricher)​および​[「対象変数を使用したデータの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.4/target-variables)​を参照してください。 ## [](#添付ファイル)添付ファイル 受信および送信の添付ファイルが排除されました。現在は関与するコネクタが添付の概念を独自の方法で処理します。 - HTTP Connector は DataWeave のマルチパート形式のサポートを利用します。 - Email Connector と Web Service Consumer Connector は、DataWeave を使用して添付ファイルを明示的に追加できます。 ## [](#メッセージのコレクション)メッセージのコレクション Mule メッセージの新しい構造の利点の 1 つが、コレクションの処理です。Mule 3 で複数のペイロードを返すコンポーネントは、​`MuleMessageCollection`​ という特殊な構造を使用していました。Mule 4 では、コンポーネントで複数のメッセージを処理する必要がある場合、単にメッセージのペイロードを Mule メッセージのリストに設定できます。そして、DataWeave、For Each などのコンポーネントを使用して、これらのメッセージを反復処理できます。 たとえば、​``​ 操作はメッセージのリストを取得します。メッセージごとに各ファイルの属性があるため、ファイルサイズやディレクトリかどうかなどに基づいて簡単に判断することができます。 ## [](#関連情報)関連情報 - [HTTP Connector の使用の移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-connectors-http) - [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) - [DataWeave 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables) - [対象変数への Enricher の移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-core-enricher) # Mule 4 の概要: Mule メッセージ Mule 4 には簡素化された Mule メッセージモデルがあり、各 Mule イベントにはメッセージと関連する変数が定義されています。 - Mule メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。 - 操作の結果や補助値など、任意のユーザー情報が保持される変数 (​`vars`​)。一般に、操作では変数が他のコンポーネント (リスナーなど) に自動的に伝播されることはありません。ただし、Flow Reference コンポーネントを使用した場合は、フロー内で変数が伝播されます。 メッセージモデルが簡素化されたことで、どのコネクタでも一貫した方法でデータを簡単に操作できるようになり、情報が上書きされることがありません。 ![Mule イベントとメッセージ](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-message-diagram.png) Figure 1. Mule イベントとメッセージ。 ## [](#インバウンドプロパティが属性に)インバウンドプロパティが属性に Mule 3 ではインバウンドプロパティに、Mule イベントソースから取得されたペイロードに関する追加情報が保存されていました (HTTP リスナー経由で受け取るクエリパラメーターなど)。 Mule 4 では、インバウンドプロパティが​**属性**​になりました。属性には次の利点があります。 - 強く型付けされるため、どのデータを使用できるかがすぐにわかる。 - 変数に簡単に保存して、フローのどの時点でもアクセスできる。以下は、Mule 4 の典型的な Mule メッセージの HTTP リスナーの一例です。 ![Mule 4 の Mule メッセージの構造](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mule-message.png) Mule 3 のインバウンドプロパティの場合と同様に、属性も式を使用して簡単にアクセスできます。 ```text #[attributes.requestPath] #[attributes.queryParams.searchCriteria] ``` ソースや操作から新しいメッセージが生成されると、​**メッセージの両方の部分 (ペイロードと属性) が新しい値に置換され**​、以前の属性は失われます。操作の呼び出し間で属性からの情報を保持する必要がある場合は、以前の属性を変数に保存するか、​[呼び出された操作で ​`target`​ パラメーターを設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/target-variables)​することができます。 以下は、フローの実行時にメッセージがどのように更新されるかを示す一例です。 ```xml (1) (2) (3) #[output application/xml --- { data: payload, customer: attributes.queryParams.customer_id (4) }] (5) #[output application/json --- { customer: requestAttributes.queryParams.customer_id, (6) invoiceTrackingNumber: attributes.properties.userProperties.invoiceTrackingNumber }] (7) (8) ```
1要求が受信され、​http:listener​ が要求ペイロードと HTTP 属性からなるメッセージを生成します。
2logger​ は void の操作で、何ら出力を生成しないため、実行後もメッセージは同じままです。
3この例では、次の操作で現在のメッセージが置換されるため、現在の HTTP 属性を変数に保存して、その後のフローで利用できるようにします。
4その後も HTTP 属性を使用して ​jms:publish-consume​ 操作の入力を設定できます。
5jms:publish-consume​ が呼び出された場合、この操作の出力は、別のペイロードと JMS 属性からなるメッセージです。
6HTTP 属性が変数に保存されているため、現在の JMS 属性 (​attributes​ として) と以前に保存した HTTP 情報の両方を使用できます。
7jms:publish​ 操作も void です。何ら出力が生成されないため、メッセージはそのままです。
8この時点で、​jms:publish-consume​ 呼び出しの JMS 属性がそのまま存在します。
## [](#アウトバウンドプロパティ)アウトバウンドプロパティ Mule 3 では、ヘッダーなどの追加データを送信する必要のある Mule Connector やトランスポートに、アウトバウンドプロパティを明示的に指定する必要があります。たとえば、HTTP リスナーの場合、送信状況コード応答やヘッダーの指定が必要になることがあります。Mule 4 では、各々に DataWeave 式を使用してこれらの情報を個別に設定でき、メインのフローに副次的影響が及ぶことがありません。 ```xml #[{'path':'input/issues-list.json'}] #[{'provider':'memory-provider'}] ``` 上記の例では、HTTP 要求を実行すると個々の DataWeave スクリプトによってヘッダーやクエリパラメーターが生成されますが、メッセージのプロパティを設定する必要はなく、メッセージへの副次的な影響もありません。 応答を生成する Mule イベントソース (HTTP リスナーなど) にも同じ概念を適用できます。 ```xml #[vars.outboundHeaders default {}] #[payload] #[vars.outboundHeaders default {}] ``` 上の例では、​`vars.httpStatus default 200`​ のような ​`http:headers`​ 設定は、実際の値が ​`null`​ になる場合に変数のデフォルト値を設定します。 ## [](#セッションプロパティ)セッションプロパティ セッションプロパティが不要になり、Mule 4 で排除されています。 代わりに、Target (対象) (​`target`​) パラメーターを使用して対象変数にデータを保存します。 セッションプロパティが不要になった理由は、Mule 4 には Mule 3 のトランスポートや関連するトランスポートバリアーが存在しないためです。Mule 3 のトランスポートバリアーは、Mule 3 のフローを進行する Mule メッセージデータの処理方法を決定します。Mule 4 では、トランスポートが対応する Mule Connector (FTP Connector など) に切り替えられ、これらのコネクタがネットワーキングトランスポートプロトコルを異なる方法で処理します。 例については、​[「対象変数への Enricher の移行」](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-core-enricher)​および​[「対象変数を使用したデータの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.5/target-variables)​を参照してください。 ## [](#attachments-添付ファイル)Attachments (添付ファイル) 受信および送信の添付ファイルが排除されました。現在は関与するコネクタが添付の概念を独自の方法で処理します。 - HTTP Connector は DataWeave のマルチパート形式のサポートを利用します。 - Email Connector と Web サービスコンシューマーコネクタは、DataWeave を使用して添付ファイルを明示的に追加できます。 ## [](#メッセージのコレクション)メッセージのコレクション Mule メッセージの新しい構造の利点の 1 つが、コレクションの処理です。Mule 3 で複数のペイロードを返すコンポーネントは、​`MuleMessageCollection`​ という特殊な構造を使用していました。Mule 4 では、コンポーネントで複数のメッセージを処理する必要がある場合、単にメッセージのペイロードを Mule メッセージのリストに設定できます。そして、DataWeave、For Each などのコンポーネントを使用して、これらのメッセージを反復処理できます。 たとえば、​``​ 操作はメッセージのリストを取得します。メッセージごとに各ファイルの属性があるため、ファイルサイズやディレクトリかどうかなどに基づいて簡単に判断することができます。 ## [](#関連情報)関連情報 - [HTTP Connector の使用の移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-connectors-http) - [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) - [DataWeave 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables) - [対象変数への Enricher の移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-core-enricher) # Mule 4 の概要: Mule メッセージ Mule 4 には簡素化された Mule メッセージモデルがあり、各 Mule イベントにはメッセージと関連する変数が定義されています。 - Mule メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。 - 操作の結果や補助値など、任意のユーザー情報が保持される変数 (​`vars`​)。一般に、操作では変数が他のコンポーネント (リスナーなど) に自動的に伝播されることはありません。ただし、Flow Reference コンポーネントを使用した場合は、フロー内で変数が伝播されます。 メッセージモデルが簡素化されたことで、どのコネクタでも一貫した方法でデータを簡単に操作できるようになり、情報が上書きされることがありません。 ![Mule イベントとメッセージ](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-message-diagram.png) Figure 1. Mule イベントとメッセージ。 ## [](#インバウンドプロパティが属性に)インバウンドプロパティが属性に Mule 3 ではインバウンドプロパティに、Mule イベントソースから取得されたペイロードに関する追加情報が保存されていました (HTTP リスナー経由で受け取るクエリパラメーターなど)。 Mule 4 では、インバウンドプロパティが​**属性**​になりました。属性には次の利点があります。 - 強く型付けされるため、どのデータを使用できるかがすぐにわかる。 - 変数に簡単に保存して、フローのどの時点でもアクセスできる。以下は、Mule 4 の典型的な Mule メッセージの HTTP リスナーの一例です。 ![Mule 4 の Mule メッセージの構造](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mule-message.png) Mule 3 のインバウンドプロパティの場合と同様に、属性も式を使用して簡単にアクセスできます。 ```text #[attributes.requestPath] #[attributes.queryParams.searchCriteria] ``` ソースや操作から新しいメッセージが生成されると、​**メッセージの両方の部分 (ペイロードと属性) が新しい値に置換され**​、以前の属性は失われます。操作の呼び出し間で属性からの情報を保持する必要がある場合は、以前の属性を変数に保存するか、​[呼び出された操作で ​`target`​ パラメーターを設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/target-variables)​することができます。 以下は、フローの実行時にメッセージがどのように更新されるかを示す一例です。 ```xml (1) (2) (3) #[output application/xml --- { data: payload, customer: attributes.queryParams.customer_id (4) }] (5) #[output application/json --- { customer: requestAttributes.queryParams.customer_id, (6) invoiceTrackingNumber: attributes.properties.userProperties.invoiceTrackingNumber }] (7) (8) ```
1要求が受信され、​http:listener​ が要求ペイロードと HTTP 属性からなるメッセージを生成します。
2logger​ は void の操作で、何ら出力を生成しないため、実行後もメッセージは同じままです。
3この例では、次の操作で現在のメッセージが置換されるため、現在の HTTP 属性を変数に保存して、その後のフローで利用できるようにします。
4その後も HTTP 属性を使用して ​jms:publish-consume​ 操作の入力を設定できます。
5jms:publish-consume​ が呼び出された場合、この操作の出力は、別のペイロードと JMS 属性からなるメッセージです。
6HTTP 属性が変数に保存されているため、現在の JMS 属性 (​attributes​ として) と以前に保存した HTTP 情報の両方を使用できます。
7jms:publish​ 操作も void です。何ら出力が生成されないため、メッセージはそのままです。
8この時点で、​jms:publish-consume​ 呼び出しの JMS 属性がそのまま存在します。
## [](#アウトバウンドプロパティ)アウトバウンドプロパティ Mule 3 では、ヘッダーなどの追加データを送信する必要のある Mule のコネクタやトランスポートに、アウトバウンドプロパティを明示的に指定する必要があります。たとえば、HTTP リスナーの場合、送信状況コード応答やヘッダーの指定が必要になることがあります。Mule 4 では、各々に DataWeave 式を使用してこれらの情報を個別に設定でき、メインのフローに副次的影響が及ぶことがありません。 ```xml #[{'path':'input/issues-list.json'}] #[{'provider':'memory-provider'}] ``` 上記の例では、HTTP 要求を実行すると個々の DataWeave スクリプトによってヘッダーやクエリパラメーターが生成されますが、メッセージのプロパティを設定する必要はなく、メッセージへの副次的な影響もありません。 応答を生成する Mule イベントソース (HTTP リスナーなど) にも同じ概念を適用できます。 ```xml #[vars.outboundHeaders default {}] #[payload] #[vars.outboundHeaders default {}] ``` 上の例では、​`vars.httpStatus default 200`​ のような ​`http:headers`​ 設定は、実際の値が ​`null`​ になる場合に変数のデフォルト値を設定します。 ## [](#セッションプロパティ)セッションプロパティ セッションプロパティが不要になり、Mule 4 で排除されています。 代わりに、Target (対象) (​`target`​) パラメーターを使用して対象変数にデータを保存します。 セッションプロパティが不要になった理由は、Mule 4 には Mule 3 のトランスポートや関連するトランスポートバリアーが存在しないためです。Mule 3 のトランスポートバリアーは、Mule 3 のフローを進行する Mule メッセージデータの処理方法を決定します。Mule 4 では、トランスポートが対応する Mule Connector (FTP Connector など) に切り替えられ、これらのコネクタがネットワーキングトランスポートプロトコルを異なる方法で処理します。 例については、​[「対象変数への Enricher の移行」](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-core-enricher)​および​[「対象変数を使用したデータの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.6/target-variables)​を参照してください。 ## [](#attachments-添付ファイル)Attachments (添付ファイル) 受信および送信の添付ファイルが排除されました。現在は関与するコネクタが添付の概念を独自の方法で処理します。 - HTTP Connector は DataWeave のマルチパート形式のサポートを利用します。 - Email Connector と Web Service Consumer Connector は、DataWeave を使用して添付ファイルを明示的に追加できます。 ## [](#メッセージのコレクション)メッセージのコレクション Mule メッセージの新しい構造の利点の 1 つが、コレクションの処理です。Mule 3 で複数のペイロードを返すコンポーネントは、​`MuleMessageCollection`​ という特殊な構造を使用していました。Mule 4 では、コンポーネントで複数のメッセージを処理する必要がある場合、単にメッセージのペイロードを Mule メッセージのリストに設定できます。そして、DataWeave、For Each などのコンポーネントを使用して、これらのメッセージを反復処理できます。 たとえば、​``​ 操作はメッセージのリストを取得します。メッセージごとに各ファイルの属性があるため、ファイルサイズやディレクトリかどうかなどに基づいて簡単に判断することができます。 ## [](#関連情報)関連情報 - [HTTP Connector の使用の移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-connectors-http) - [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) - [DataWeave 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables) - [対象変数への Enricher の移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-core-enricher) # Mule 4 の概要: Mule メッセージ Mule 4 には簡素化された Mule メッセージモデルがあり、各 Mule イベントにはメッセージと関連する変数が定義されています。 - Mule メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。 - 操作の結果や補助値など、任意のユーザー情報が保持される変数 (​`vars`​)。一般に、操作では変数が他のコンポーネント (リスナーなど) に自動的に伝播されることはありません。ただし、Flow Reference コンポーネントを使用した場合は、フロー内で変数が伝播されます。 メッセージモデルが簡素化されたことで、どのコネクタでも一貫した方法でデータを簡単に操作できるようになり、情報が上書きされることがありません。 ![Mule イベントとメッセージ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-message-diagram.png) Figure 1. Mule イベントとメッセージ。 ## [](#インバウンドプロパティが属性に)インバウンドプロパティが属性に Mule 3 ではインバウンドプロパティに、Mule イベントソースから取得されたペイロードに関する追加情報が保存されていました (HTTP リスナー経由で受け取るクエリパラメーターなど)。 Mule 4 では、インバウンドプロパティが​**属性**​になりました。属性には次の利点があります。 - 強く型付けされるため、どのデータを使用できるかがすぐにわかる。 - 変数に簡単に保存して、フローのどの時点でもアクセスできる。以下は、Mule 4 の典型的な Mule メッセージの HTTP リスナーの一例です。 ![Mule 4 の Mule メッセージの構造](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mule-message.png) Mule 3 のインバウンドプロパティの場合と同様に、属性も式を使用して簡単にアクセスできます。 ```text #[attributes.requestPath] #[attributes.queryParams.searchCriteria] ``` ソースや操作から新しいメッセージが生成されると、​**メッセージの両方の部分 (ペイロードと属性) が新しい値に置換され**​、以前の属性は失われます。操作の呼び出し間で属性からの情報を保持する必要がある場合は、以前の属性を変数に保存するか、​[呼び出された操作で ​`target`​ パラメーターを設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/target-variables)​することができます。 以下は、フローの実行時にメッセージがどのように更新されるかを示す一例です。 ```xml (1) (2) (3) #[output application/xml --- { data: payload, customer: attributes.queryParams.customer_id (4) }] (5) #[output application/json --- { customer: requestAttributes.queryParams.customer_id, (6) invoiceTrackingNumber: attributes.properties.userProperties.invoiceTrackingNumber }] (7) (8) ```
1要求が受信され、​http:listener​ が要求ペイロードと HTTP 属性からなるメッセージを生成します。
2logger​ は void の操作で、何ら出力を生成しないため、実行後もメッセージは同じままです。
3この例では、次の操作で現在のメッセージが置換されるため、現在の HTTP 属性を変数に保存して、その後のフローで利用できるようにします。
4その後も HTTP 属性を使用して ​jms:publish-consume​ 操作の入力を設定できます。
5jms:publish-consume​ が呼び出された場合、この操作の出力は、別のペイロードと JMS 属性からなるメッセージです。
6HTTP 属性が変数に保存されているため、現在の JMS 属性 (​attributes​ として) と以前に保存した HTTP 情報の両方を使用できます。
7jms:publish​ 操作も void です。何ら出力が生成されないため、メッセージはそのままです。
8この時点で、​jms:publish-consume​ 呼び出しの JMS 属性がそのまま存在します。
## [](#アウトバウンドプロパティ)アウトバウンドプロパティ Mule 3 では、ヘッダーなどの追加データを送信する必要のある Mule Connector やトランスポートに、アウトバウンドプロパティを明示的に指定する必要があります。たとえば、HTTP リスナーの場合、送信状況コード応答やヘッダーの指定が必要になることがあります。Mule 4 では、各々に DataWeave 式を使用してこれらの情報を個別に設定でき、メインのフローに副次的影響が及ぶことがありません。 ```xml #[{'path':'input/issues-list.json'}] #[{'provider':'memory-provider'}] ``` 上記の例では、HTTP 要求を実行すると個々の DataWeave スクリプトによってヘッダーやクエリパラメーターが生成されますが、メッセージのプロパティを設定する必要はなく、メッセージへの副次的な影響もありません。 応答を生成する Mule イベントソース (HTTP リスナーなど) にも同じ概念を適用できます。 ```xml #[vars.outboundHeaders default {}] #[payload] #[vars.outboundHeaders default {}] ``` 上の例では、​`vars.httpStatus default 200`​ のような ​`http:headers`​ 設定は、実際の値が ​`null`​ になる場合に変数のデフォルト値を設定します。 ## [](#セッションプロパティ)セッションプロパティ セッションプロパティが不要になり、Mule 4 で排除されています。 代わりに、Target (対象) (​`target`​) パラメーターを使用して対象変数にデータを保存します。 セッションプロパティが不要になった理由は、Mule 4 には Mule 3 のトランスポートや関連するトランスポートバリアーが存在しないためです。Mule 3 のトランスポートバリアーは、Mule 3 のフローを進行する Mule メッセージデータの処理方法を決定します。Mule 4 では、トランスポートが対応する Mule Connector (FTP Connector など) に切り替えられ、これらのコネクタがネットワーキングトランスポートプロトコルを異なる方法で処理します。 例については、​[「対象変数への Enricher の移行」](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-core-enricher)​および​[「対象変数を使用したデータの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.7/target-variables)​を参照してください。 ## [](#attachments-添付ファイル)Attachments (添付ファイル) 受信および送信の添付ファイルが排除されました。現在は関与するコネクタが添付の概念を独自の方法で処理します。 - HTTP Connector は DataWeave のマルチパート形式のサポートを利用します。 - Email Connector と Web Service Consumer Connector は、DataWeave を使用して添付ファイルを明示的に追加できます。 ## [](#メッセージのコレクション)メッセージのコレクション Mule メッセージの新しい構造の利点の 1 つが、コレクションの処理です。Mule 3 で複数のペイロードを返すコンポーネントは、​`MuleMessageCollection`​ という特殊な構造を使用していました。Mule 4 では、コンポーネントで複数のメッセージを処理する必要がある場合、単にメッセージのペイロードを Mule メッセージのリストに設定できます。そして、DataWeave、For Each などのコンポーネントを使用して、これらのメッセージを反復処理できます。 たとえば、​``​ 操作はメッセージのリストを取得します。メッセージごとに各ファイルの属性があるため、ファイルサイズやディレクトリかどうかなどに基づいて簡単に判断することができます。 ## [](#関連情報)関連情報 - [HTTP Connector の使用の移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-connectors-http) - [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) - [DataWeave 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables) - [対象変数への Enricher の移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-core-enricher) # Mule 4 の概要: Mule メッセージ Mule 4 には簡素化された Mule メッセージモデルがあり、各 Mule イベントにはメッセージと関連する変数が定義されています。 - Mule メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。 - 操作の結果や補助値など、任意のユーザー情報が保持される変数 (​`vars`​)。一般に、操作では変数が他のコンポーネント (リスナーなど) に自動的に伝播されることはありません。ただし、Flow Reference コンポーネントを使用した場合は、フロー内で変数が伝播されます。 メッセージモデルが簡素化されたことで、どのコネクタでも一貫した方法でデータを簡単に操作できるようになり、情報が上書きされることがありません。 ![属性、ペイロード、変数が含まれる Mule メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-message-diagram.png) Figure 1. Mule イベントとメッセージ。 ## [](#インバウンドプロパティが属性に)インバウンドプロパティが属性に Mule 3 ではインバウンドプロパティに、Mule イベントソースから取得されたペイロードに関する追加情報が保存されていました (HTTP リスナー経由で受け取るクエリパラメーターなど)。 Mule 4 では、インバウンドプロパティが​**属性**​になりました。属性には次の利点があります。 - 強く型付けされるため、どのデータを使用できるかがすぐにわかる。 - 変数に簡単に保存して、フローのどの時点でもアクセスできる。以下は、Mule 4 の典型的な Mule メッセージの HTTP リスナーの一例です。 ![属性とペイロードの型が表示されている Mule メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mule-message.png) Mule 3 のインバウンドプロパティの場合と同様に、属性も式を使用して簡単にアクセスできます。 ```text #[attributes.requestPath] #[attributes.queryParams.searchCriteria] ``` ソースや操作から新しいメッセージが生成されると、​**メッセージの両方の部分 (ペイロードと属性) が新しい値に置換され**​、以前の属性は失われます。操作の呼び出し間で属性からの情報を保持する必要がある場合は、以前の属性を変数に保存するか、​[呼び出された操作で ​`target`​ パラメーターを設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/target-variables)​することができます。 以下は、フローの実行時にメッセージがどのように更新されるかを示す一例です。 ```xml (1) (2) (3) #[output application/xml --- { data: payload, customer: attributes.queryParams.customer_id (4) }] (5) #[output application/json --- { customer: requestAttributes.queryParams.customer_id, (6) invoiceTrackingNumber: attributes.properties.userProperties.invoiceTrackingNumber }] (7) (8) ```
1要求が受信され、​http:listener​ が要求ペイロードと HTTP 属性からなるメッセージを生成します。
2logger​ は void の操作で、何ら出力を生成しないため、実行後もメッセージは同じままです。
3この例では、次の操作で現在のメッセージが置換されるため、現在の HTTP 属性を変数に保存して、その後のフローで利用できるようにします。
4その後も HTTP 属性を使用して ​jms:publish-consume​ 操作の入力を設定できます。
5jms:publish-consume​ が呼び出された場合、この操作の出力は、別のペイロードと JMS 属性からなるメッセージです。
6HTTP 属性が変数に保存されているため、現在の JMS 属性 (​attributes​ として) と以前に保存した HTTP 情報の両方を使用できます。
7jms:publish​ 操作も void です。何ら出力が生成されないため、メッセージはそのままです。
8この時点で、​jms:publish-consume​ 呼び出しの JMS 属性がそのまま存在します。
## [](#アウトバウンドプロパティ)アウトバウンドプロパティ Mule 3 では、ヘッダーなどの追加データを送信する必要のある Mule Connector やトランスポートに、アウトバウンドプロパティを明示的に指定する必要があります。たとえば、HTTP リスナーの場合、送信状況コード応答やヘッダーの指定が必要になることがあります。Mule 4 では、各々に DataWeave 式を使用してこれらの情報を個別に設定でき、メインのフローに副次的影響が及ぶことがありません。 ```xml #[{'path':'input/issues-list.json'}] #[{'provider':'memory-provider'}] ``` 上記の例では、HTTP 要求を実行すると個々の DataWeave スクリプトによってヘッダーやクエリパラメーターが生成されますが、メッセージのプロパティを設定する必要はなく、メッセージへの副次的な影響もありません。 応答を生成する Mule イベントソース (HTTP リスナーなど) にも同じ概念を適用できます。 ```xml #[vars.outboundHeaders default {}] #[payload] #[vars.outboundHeaders default {}] ``` 上の例では、​`vars.httpStatus default 200`​ のような ​`http:headers`​ 設定は、実際の値が ​`null`​ になる場合に変数のデフォルト値を設定します。 ## [](#セッションプロパティ)セッションプロパティ セッションプロパティが不要になり、Mule 4 で排除されています。 代わりに、Target (対象) (​`target`​) パラメーターを使用して対象変数にデータを保存します。 セッションプロパティが不要になった理由は、Mule 4 には Mule 3 のトランスポートや関連するトランスポートバリアーが存在しないためです。Mule 3 のトランスポートバリアーは、Mule 3 のフローを進行する Mule メッセージデータの処理方法を決定します。Mule 4 では、トランスポートが対応する Mule Connector (FTP Connector など) に切り替えられ、これらのコネクタがネットワーキングトランスポートプロトコルを異なる方法で処理します。 例については、​[「対象変数への Enricher の移行」](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-core-enricher)​および​[「対象変数を使用したデータの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.8/target-variables)​を参照してください。 ## [](#attachments-添付ファイル)Attachments (添付ファイル) 受信および送信の添付ファイルが排除されました。現在は関与するコネクタが添付の概念を独自の方法で処理します。 - HTTP Connector は DataWeave のマルチパート形式のサポートを利用します。 - Email Connector と Web Service Consumer Connector は、DataWeave を使用して添付ファイルを明示的に追加できます。 ## [](#メッセージのコレクション)メッセージのコレクション Mule メッセージの新しい構造の利点の 1 つが、コレクションの処理です。Mule 3 で複数のペイロードを返すコンポーネントは、​`MuleMessageCollection`​ という特殊な構造を使用していました。Mule 4 では、コンポーネントで複数のメッセージを処理する必要がある場合、単にメッセージのペイロードを Mule メッセージのリストに設定できます。そして、DataWeave、For Each などのコンポーネントを使用して、これらのメッセージを反復処理できます。 たとえば、​``​ 操作はメッセージのリストを取得します。メッセージごとに各ファイルの属性があるため、ファイルサイズやディレクトリかどうかなどに基づいて簡単に判断することができます。 ## [](#関連情報)関連情報 - [HTTP Connector の使用の移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-connectors-http) - [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) - [DataWeave 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables) - [対象変数への Enricher の移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-core-enricher) # Mule 4 の概要: Mule メッセージ Mule 4 には簡素化された Mule メッセージモデルがあり、各 Mule イベントにはメッセージと関連する変数が定義されています。 - Mule メッセージはペイロードとその属性 (ファイルサイズなどのメタデータ) で構成されます。 - 操作の結果や補助値など、任意のユーザー情報が保持される変数 (​`vars`​)。一般に、操作では変数が他のコンポーネント (リスナーなど) に自動的に伝播されることはありません。ただし、Flow Reference コンポーネントを使用した場合は、フロー内で変数が伝播されます。 メッセージモデルが簡素化されたことで、どのコネクタでも一貫した方法でデータを簡単に操作できるようになり、情報が上書きされることがありません。 ![属性、ペイロード、変数が含まれる Mule メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-message-diagram.png) Figure 1. Mule イベントとメッセージ。 ## [](#インバウンドプロパティが属性に)インバウンドプロパティが属性に Mule 3 ではインバウンドプロパティに、Mule イベントソースから取得されたペイロードに関する追加情報が保存されていました (HTTP リスナー経由で受け取るクエリパラメーターなど)。 Mule 4 では、インバウンドプロパティが​**属性**​になりました。属性には次の利点があります。 - 強く型付けされるため、どのデータを使用できるかがすぐにわかる。 - 変数に簡単に保存して、フローのどの時点でもアクセスできる。以下は、Mule 4 の典型的な Mule メッセージの HTTP リスナーの一例です。 ![属性とペイロードの型が表示されている Mule メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mule-message.png) Mule 3 のインバウンドプロパティの場合と同様に、属性も式を使用して簡単にアクセスできます。 ```text #[attributes.requestPath] #[attributes.queryParams.searchCriteria] ``` ソースや操作から新しいメッセージが生成されると、​**メッセージの両方の部分 (ペイロードと属性) が新しい値に置換され**​、以前の属性は失われます。操作の呼び出し間で属性からの情報を保持する必要がある場合は、以前の属性を変数に保存するか、​[呼び出された操作で ​`target`​ パラメーターを設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/target-variables)​することができます。 以下は、フローの実行時にメッセージがどのように更新されるかを示す一例です。 ```xml (1) (2) (3) #[output application/xml --- { data: payload, customer: attributes.queryParams.customer_id (4) }] (5) #[output application/json --- { customer: requestAttributes.queryParams.customer_id, (6) invoiceTrackingNumber: attributes.properties.userProperties.invoiceTrackingNumber }] (7) (8) ```
1要求が受信され、​http:listener​ が要求ペイロードと HTTP 属性からなるメッセージを生成します。
2logger​ は void の操作で、何ら出力を生成しないため、実行後もメッセージは同じままです。
3この例では、次の操作で現在のメッセージが置換されるため、現在の HTTP 属性を変数に保存して、その後のフローで利用できるようにします。
4その後も HTTP 属性を使用して ​jms:publish-consume​ 操作の入力を設定できます。
5jms:publish-consume​ が呼び出された場合、この操作の出力は、別のペイロードと JMS 属性からなるメッセージです。
6HTTP 属性が変数に保存されているため、現在の JMS 属性 (​attributes​ として) と以前に保存した HTTP 情報の両方を使用できます。
7jms:publish​ 操作も void です。何ら出力が生成されないため、メッセージはそのままです。
8この時点で、​jms:publish-consume​ 呼び出しの JMS 属性がそのまま存在します。
## [](#アウトバウンドプロパティ)アウトバウンドプロパティ Mule 3 では、ヘッダーなどの追加データを送信する必要のある Mule Connector やトランスポートに、アウトバウンドプロパティを明示的に指定する必要があります。たとえば、HTTP リスナーの場合、送信状況コード応答やヘッダーの指定が必要になることがあります。Mule 4 では、各々に DataWeave 式を使用してこれらの情報を個別に設定でき、メインのフローに副次的影響が及ぶことがありません。 ```xml #[{'path':'input/issues-list.json'}] #[{'provider':'memory-provider'}] ``` 上記の例では、HTTP 要求を実行すると個々の DataWeave スクリプトによってヘッダーやクエリパラメーターが生成されますが、メッセージのプロパティを設定する必要はなく、メッセージへの副次的な影響もありません。 応答を生成する Mule イベントソース (HTTP リスナーなど) にも同じ概念を適用できます。 ```xml #[vars.outboundHeaders default {}] #[payload] #[vars.outboundHeaders default {}] ``` 上の例では、​`vars.httpStatus default 200`​ のような ​`http:headers`​ 設定は、実際の値が ​`null`​ になる場合に変数のデフォルト値を設定します。 ## [](#セッションプロパティ)セッションプロパティ セッションプロパティが不要になり、Mule 4 で排除されています。 代わりに、Target (対象) (​`target`​) パラメーターを使用して対象変数にデータを保存します。 セッションプロパティが不要になった理由は、Mule 4 には Mule 3 のトランスポートや関連するトランスポートバリアーが存在しないためです。Mule 3 のトランスポートバリアーは、Mule 3 のフローを進行する Mule メッセージデータの処理方法を決定します。Mule 4 では、トランスポートが対応する Mule Connector (FTP Connector など) に切り替えられ、これらのコネクタがネットワーキングトランスポートプロトコルを異なる方法で処理します。 例については、​[「対象変数への Enricher の移行」](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-core-enricher)​および​[「対象変数を使用したデータの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.9/target-variables)​を参照してください。 ## [](#attachments-添付ファイル)Attachments (添付ファイル) 受信および送信の添付ファイルが排除されました。現在は関与するコネクタが添付の概念を独自の方法で処理します。 - HTTP Connector は DataWeave のマルチパート形式のサポートを利用します。 - Email Connector と Web Service Consumer Connector は、DataWeave を使用して添付ファイルを明示的に追加できます。 ## [](#メッセージのコレクション)メッセージのコレクション Mule メッセージの新しい構造の利点の 1 つが、コレクションの処理です。Mule 3 で複数のペイロードを返すコンポーネントは、​`MuleMessageCollection`​ という特殊な構造を使用していました。Mule 4 では、コンポーネントで複数のメッセージを処理する必要がある場合、単にメッセージのペイロードを Mule メッセージのリストに設定できます。そして、DataWeave、For Each などのコンポーネントを使用して、これらのメッセージを反復処理できます。 たとえば、​``​ 操作はメッセージのリストを取得します。メッセージごとに各ファイルの属性があるため、ファイルサイズやディレクトリかどうかなどに基づいて簡単に判断することができます。 ## [](#関連情報)関連情報 - [HTTP Connector の使用の移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-connectors-http) - [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) - [DataWeave 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables) - [対象変数への Enricher の移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-core-enricher) # Mule 4 の概要: Studio 7 Mule 4 の新機能について学ぶ前に、Studio 7 をインストールして慣れておきます。Studio 7 は Mule 4 アプリケーションの開発環境です。Mule 4 をサポートするほか、生産性を向上させる新機能が多数追加されています。Studio 7 は Mule 3 アプリケーションの起動をサポートしていません。 ## [](#新しい-mule-パレット)新しい Mule パレット Studio 6 パレットでは、適切な操作を探すために、コネクタを見つけてキャンバスにドラッグし、操作を検索するという数段階のプロセスを経る必要がありました。Studio 7 ではこのプロセスを加速するために、アクセス時間、検出性、分類を向上させる 2 層構造のパレットが導入されています。コネクタの操作を直接検索し、実行頻度の高い操作を簡単にお気に入りに追加できます。 コネクタとモジュールの管理も改善されています。Studio 7 では、コネクタの各バージョンをプロジェクトに明示的に追加できるため、プロジェクト特有のパレットを設定することができます。そのため、使用していないコネクタやモジュールを目にすることがありません。 ![Studio パレット](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/studio-palette.png) ## [](#maven-との自動インテグレーションによる連動関係の管理)Maven との自動インテグレーションによる連動関係の管理 Studio の旧バージョンでは、Mule の各モジュールが Eclipse プラグインで、「サイトの更新」メカニズムを使用したインストールが必要でした。今回、各モジュールが単なるプロジェクトの連動関係となり、Maven で管理されるようになりました。つまり、膨大な「サイトの更新」、プラグインのインストール、プラグインのバージョンなどに対処する必要がなくなります。Studio で自動的に Maven 連動関係を「pom.xml」ファイルに追加して追跡します。 Maven について知らなくても心配いりません。Studio が自動的に各プロジェクトにデフォルトの ​`pom.xml`​ ファイルを作成して Maven を管理します。 ## [](#xml-ビューへの移動)XML ビューへの移動 ビジュアルビューから XML にすばやく移動できるようになりました。 - 任意のコンポーネントを右クリックし、\[Go to XML (XML へ移動)\] を選択するだけです。 ## [](#anypoint-platform-アカウントの管理)Anypoint Platform アカウントの管理 Platform に関連するどの操作でも、アカウントやビジネスグループ (該当する場合) を変更できるクイック変更ツールバーが表示されます。このツールバーからアカウントを追加することもできます。 たとえば、新しい Mule プロジェクトを作成する場合 (\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\])、Design Center から API 実装を選択すると、選択ダイアログの上部にツールバーが表示されます。 ![新しい Mule プロジェクトの作成時の Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/studio-credentials.png) 同様に、Mule パレットから \[Search in Exchange (Exchange で検索)\] を選択すると、若干異なるツールバーが表示されます。 ![Mule パレットの Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/studio-credentials-exchange.png) ## [](#メタデータのストレージ)メタデータのストレージ Mule 4 アプリケーションには、データ種別に関するメタデータを保存する ​`application-types.xml`​ ファイルがあります。たとえば、新たに CSV 種別を作成すると、このファイルにそのメタデータが追加されます。この新しいファイルは、簡単に共有やコミット、競合が生じた場合のマージを実行できるため、メタデータ指向の開発に役立ちます。 ## [](#その他の改善点)その他の改善点 - 操作性を向上させる新しい一連のグラフィックアイコン。 - 操作のデフォルトの表示名を変更するときに、常に操作名 (Select、Delete など) を示すウォーターマークテキスト。この変更によって視覚的に確認しやすくなります。 - 折りたたみ可能なフローと対話型プレビュー。 # Mule 4 の概要: Studio 7 Mule 4 の新機能について学ぶ前に、Studio 7 をインストールして慣れておきます。Studio 7 は Mule 4 アプリケーションの開発環境です。Mule 4 をサポートするほか、生産性を向上させる新機能が多数追加されています。Studio 7 は Mule 3 アプリケーションの起動をサポートしていません。 ## [](#新しい-mule-パレット)新しい Mule パレット Studio 6 パレットでは、適切な操作を探すために、コネクタを見つけてキャンバスにドラッグし、操作を検索するという数段階のプロセスを経る必要がありました。Studio 7 ではこのプロセスを加速するために、アクセス時間、検出性、分類を向上させる 2 層構造のパレットが導入されています。コネクタの操作を直接検索し、実行頻度の高い操作を簡単にお気に入りに追加できます。 コネクタとモジュールの管理も改善されています。Studio 7 では、コネクタの各バージョンをプロジェクトに明示的に追加できるため、プロジェクト特有のパレットを設定することができます。そのため、使用していないコネクタやモジュールを目にすることがありません。 ![Studio パレット](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/studio-palette.png) ## [](#maven-との自動インテグレーションによる連動関係の管理)Maven との自動インテグレーションによる連動関係の管理 Studio の旧バージョンでは、Mule の各モジュールが Eclipse プラグインで、「サイトの更新」メカニズムを使用したインストールが必要でした。今回、各モジュールが単なるプロジェクトの連動関係となり、Maven で管理されるようになりました。つまり、膨大な「サイトの更新」、プラグインのインストール、プラグインのバージョンなどに対処する必要がなくなります。Studio で自動的に Maven 連動関係を「pom.xml」ファイルに追加して追跡します。 Maven について知らなくても心配いりません。Studio が自動的に各プロジェクトにデフォルトの ​`pom.xml`​ ファイルを作成して Maven を管理します。 ## [](#xml-ビューへの移動)XML ビューへの移動 ビジュアルビューから XML にすばやく移動できるようになりました。 - 任意のコンポーネントを右クリックし、\[Go to XML (XML へ移動)\] を選択するだけです。 ## [](#anypoint-platform-アカウントの管理)Anypoint Platform アカウントの管理 Platform に関連するどの操作でも、アカウントやビジネスグループ (該当する場合) を変更できるクイック変更ツールバーが表示されます。このツールバーからアカウントを追加することもできます。 たとえば、新しい Mule プロジェクトを作成する場合 (\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\])、Design Center から API 実装を選択すると、選択ダイアログの上部にツールバーが表示されます。 ![新しい Mule プロジェクトの作成時の Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/studio-credentials.png) 同様に、Mule パレットから \[Search in Exchange (Exchange で検索)\] を選択すると、若干異なるツールバーが表示されます。 ![Mule パレットの Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/studio-credentials-exchange.png) ## [](#メタデータのストレージ)メタデータのストレージ Mule 4 アプリケーションには、データ種別に関するメタデータを保存する ​`application-types.xml`​ ファイルがあります。たとえば、新たに CSV 種別を作成すると、このファイルにそのメタデータが追加されます。この新しいファイルは、簡単に共有やコミット、競合が生じた場合のマージを実行できるため、メタデータ指向の開発に役立ちます。 ## [](#その他の改善点)その他の改善点 - 操作性を向上させる新しい一連のグラフィックアイコン。 - 操作のデフォルトの表示名を変更するときに、常に操作名 (Select、Delete など) を示すウォーターマークテキスト。この変更によって視覚的に確認しやすくなります。 - 折りたたみ可能なフローと対話型プレビュー。 # Mule 4 の概要: Studio 7 Mule 4 の新機能について学ぶ前に、Studio 7 をインストールして慣れておきます。Studio 7 は Mule 4 アプリケーションの開発環境です。Mule 4 をサポートするほか、生産性を向上させる新機能が多数追加されています。Studio 7 は Mule 3 アプリケーションの起動をサポートしていません。 ## [](#新しい-mule-パレット)新しい Mule パレット Studio 6 パレットでは、適切な操作を探すために、コネクタを見つけてキャンバスにドラッグし、操作を検索するという数段階のプロセスを経る必要がありました。Studio 7 ではこのプロセスを加速するために、アクセス時間、検出性、分類を向上させる 2 層構造のパレットが導入されています。コネクタの操作を直接検索し、実行頻度の高い操作を簡単にお気に入りに追加できます。 コネクタとモジュールの管理も改善されています。Studio 7 では、コネクタの各バージョンをプロジェクトに明示的に追加できるため、プロジェクト特有のパレットを設定することができます。そのため、使用していないコネクタやモジュールを目にすることがありません。 ![Studio パレット](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/studio-palette.png) ## [](#maven-との自動インテグレーションによる連動関係の管理)Maven との自動インテグレーションによる連動関係の管理 Studio の旧バージョンでは、Mule の各モジュールが Eclipse プラグインで、「サイトの更新」メカニズムを使用したインストールが必要でした。今回、各モジュールが単なるプロジェクトの連動関係となり、Maven で管理されるようになりました。つまり、膨大な「サイトの更新」、プラグインのインストール、プラグインのバージョンなどに対処する必要がなくなります。Studio で自動的に Maven 連動関係を「pom.xml」ファイルに追加して追跡します。 Maven について知らなくても心配いりません。Studio が自動的に各プロジェクトにデフォルトの ​`pom.xml`​ ファイルを作成して Maven を管理します。 ## [](#xml-ビューへの移動)XML ビューへの移動 ビジュアルビューから XML にすばやく移動できるようになりました。 - 任意のコンポーネントを右クリックし、\[Go to XML (XML へ移動)\] を選択するだけです。 ## [](#anypoint-platform-アカウントの管理)Anypoint Platform アカウントの管理 Platform に関連するどの操作でも、アカウントやビジネスグループ (該当する場合) を変更できるクイック変更ツールバーが表示されます。このツールバーからアカウントを追加することもできます。 たとえば、新しい Mule プロジェクトを作成する場合 (\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\])、Design Center から API 実装を選択すると、選択ダイアログの上部にツールバーが表示されます。 ![新しい Mule プロジェクトの作成時の Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/studio-credentials.png) 同様に、Mule パレットから \[Search in Exchange (Exchange で検索)\] を選択すると、若干異なるツールバーが表示されます。 ![Mule パレットの Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/studio-credentials-exchange.png) ## [](#メタデータのストレージ)メタデータのストレージ Mule 4 アプリケーションには、データ種別に関するメタデータを保存する ​`application-types.xml`​ ファイルがあります。たとえば、新たに CSV 種別を作成すると、このファイルにそのメタデータが追加されます。この新しいファイルは、簡単に共有やコミット、競合が生じた場合のマージを実行できるため、メタデータ指向の開発に役立ちます。 ## [](#その他の改善点)その他の改善点 - 操作性を向上させる新しい一連のグラフィックアイコン。 - 操作のデフォルトの表示名を変更するときに、常に操作名 (Select、Delete など) を示すウォーターマークテキスト。この変更によって視覚的に確認しやすくなります。 - 折りたたみ可能なフローと対話型プレビュー。 # Mule 4 の概要: Studio 7 Mule 4 の新機能について学ぶ前に、Studio 7 をインストールして慣れておきます。Studio 7 は Mule 4 アプリケーションの開発環境です。Mule 4 をサポートするほか、生産性を向上させる新機能が多数追加されています。Studio 7 は Mule 3 アプリケーションの起動をサポートしていません。 ## [](#新しい-mule-パレット)新しい Mule パレット Studio 6 パレットでは、適切な操作を探すために、コネクタを見つけてキャンバスにドラッグし、操作を検索するという数段階のプロセスを経る必要がありました。Studio 7 ではこのプロセスを加速するために、アクセス時間、検出性、分類を向上させる 2 層構造のパレットが導入されています。コネクタの操作を直接検索し、実行頻度の高い操作を簡単にお気に入りに追加できます。 コネクタとモジュールの管理も改善されています。Studio 7 では、コネクタの各バージョンをプロジェクトに明示的に追加できるため、プロジェクト特有のパレットを設定することができます。そのため、使用していないコネクタやモジュールを目にすることがありません。 ![Studio パレット](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/studio-palette.png) ## [](#maven-との自動インテグレーションによる連動関係の管理)Maven との自動インテグレーションによる連動関係の管理 Studio の旧バージョンでは、Mule の各モジュールが Eclipse プラグインで、「サイトの更新」メカニズムを使用したインストールが必要でした。今回、各モジュールが単なるプロジェクトの連動関係となり、Maven で管理されるようになりました。つまり、膨大な「サイトの更新」、プラグインのインストール、プラグインのバージョンなどに対処する必要がなくなります。Studio で自動的に Maven 連動関係を「pom.xml」ファイルに追加して追跡します。 Maven について知らなくても心配いりません。Studio が自動的に各プロジェクトにデフォルトの ​`pom.xml`​ ファイルを作成して Maven を管理します。 ## [](#xml-ビューへの移動)XML ビューへの移動 ビジュアルビューから XML にすばやく移動できるようになりました。 - 任意のコンポーネントを右クリックし、\[Go to XML (XML へ移動)\] を選択するだけです。 ## [](#anypoint-platform-アカウントの管理)Anypoint Platform アカウントの管理 Platform に関連するどの操作でも、アカウントやビジネスグループ (該当する場合) を変更できるクイック変更ツールバーが表示されます。このツールバーからアカウントを追加することもできます。 たとえば、新しい Mule プロジェクトを作成する場合 (\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\])、Design Center から API 実装を選択すると、選択ダイアログの上部にツールバーが表示されます。 ![新しい Mule プロジェクトの作成時の Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/studio-credentials.png) 同様に、Mule パレットから \[Search in Exchange (Exchange で検索)\] を選択すると、若干異なるツールバーが表示されます。 ![Mule パレットの Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/studio-credentials-exchange.png) ## [](#メタデータのストレージ)メタデータのストレージ Mule 4 アプリケーションには、データ種別に関するメタデータを保存する ​`application-types.xml`​ ファイルがあります。たとえば、新たに CSV 種別を作成すると、このファイルにそのメタデータが追加されます。この新しいファイルは、簡単に共有やコミット、競合が生じた場合のマージを実行できるため、メタデータ指向の開発に役立ちます。 ## [](#その他の改善点)その他の改善点 - 操作性を向上させる新しい一連のグラフィックアイコン。 - 操作のデフォルトの表示名を変更するときに、常に操作名 (Select、Delete など) を示すウォーターマークテキスト。この変更によって視覚的に確認しやすくなります。 - 折りたたみ可能なフローと対話型プレビュー。 # Mule 4 の概要: Studio 7 Mule 4 の新機能について学ぶ前に、Studio 7 をインストールして慣れておきます。Studio 7 は Mule 4 アプリケーションの開発環境です。Mule 4 をサポートするほか、生産性を向上させる新機能が多数追加されています。Studio 7 は Mule 3 アプリケーションの起動をサポートしていません。 ## [](#新しい-mule-パレット)新しい Mule パレット Studio 6 パレットでは、適切な操作を探すために、コネクタを見つけてキャンバスにドラッグし、操作を検索するという数段階のプロセスを経る必要がありました。Studio 7 ではこのプロセスを加速するために、アクセス時間、検出性、分類を向上させる 2 層構造のパレットが導入されています。コネクタの操作を直接検索し、実行頻度の高い操作を簡単にお気に入りに追加できます。 コネクタとモジュールの管理も改善されています。Studio 7 では、コネクタの各バージョンをプロジェクトに明示的に追加できるため、プロジェクト特有のパレットを設定することができます。そのため、使用していないコネクタやモジュールを目にすることがありません。 ![Studio パレット](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/studio-palette.png) ## [](#maven-との自動インテグレーションによる連動関係の管理)Maven との自動インテグレーションによる連動関係の管理 Studio の旧バージョンでは、Mule の各モジュールが Eclipse プラグインで、「サイトの更新」メカニズムを使用したインストールが必要でした。今回、各モジュールが単なるプロジェクトの連動関係となり、Maven で管理されるようになりました。つまり、膨大な「サイトの更新」、プラグインのインストール、プラグインのバージョンなどに対処する必要がなくなります。Studio で自動的に Maven 連動関係を「pom.xml」ファイルに追加して追跡します。 Maven について知らなくても心配いりません。Studio が自動的に各プロジェクトにデフォルトの ​`pom.xml`​ ファイルを作成して Maven を管理します。 ## [](#xml-ビューへの移動)XML ビューへの移動 ビジュアルビューから XML にすばやく移動できるようになりました。 - 任意のコンポーネントを右クリックし、\[Go to XML (XML へ移動)\] を選択するだけです。 ## [](#anypoint-platform-アカウントの管理)Anypoint Platform アカウントの管理 Platform に関連するどの操作でも、アカウントやビジネスグループ (該当する場合) を変更できるクイック変更ツールバーが表示されます。このツールバーからアカウントを追加することもできます。 たとえば、新しい Mule プロジェクトを作成する場合 (\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\])、Design Center から API 実装を選択すると、選択ダイアログの上部にツールバーが表示されます。 ![新しい Mule プロジェクトの作成時の Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/studio-credentials.png) 同様に、Mule パレットから \[Search in Exchange (Exchange で検索)\] を選択すると、若干異なるツールバーが表示されます。 ![Mule パレットの Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/studio-credentials-exchange.png) ## [](#メタデータのストレージ)メタデータのストレージ Mule 4 アプリケーションには、データ種別に関するメタデータを保存する ​`application-types.xml`​ ファイルがあります。たとえば、新たに CSV 種別を作成すると、このファイルにそのメタデータが追加されます。この新しいファイルは、簡単に共有やコミット、競合が生じた場合のマージを実行できるため、メタデータ指向の開発に役立ちます。 ## [](#その他の改善点)その他の改善点 - 操作性を向上させる新しい一連のグラフィックアイコン。 - 操作のデフォルトの表示名を変更するときに、常に操作名 (Select、Delete など) を示すウォーターマークテキスト。この変更によって視覚的に確認しやすくなります。 - 折りたたみ可能なフローと対話型プレビュー。 # Mule 4 の概要: Studio 7 Mule 4 の新機能について学ぶ前に、Studio 7 をインストールして慣れておきます。Studio 7 は Mule 4 アプリケーションの開発環境です。Mule 4 をサポートするほか、生産性を向上させる新機能が多数追加されています。Studio 7 は Mule 3 アプリケーションの起動をサポートしていません。 ## [](#新しい-mule-パレット)新しい Mule パレット Studio 6 パレットでは、適切な操作を探すために、コネクタを見つけてキャンバスにドラッグし、操作を検索するという数段階のプロセスを経る必要がありました。Studio 7 ではこのプロセスを加速するために、アクセス時間、検出性、分類を向上させる 2 層構造のパレットが導入されています。コネクタの操作を直接検索し、実行頻度の高い操作を簡単にお気に入りに追加できます。 コネクタとモジュールの管理も改善されています。Studio 7 では、コネクタの各バージョンをプロジェクトに明示的に追加できるため、プロジェクト特有のパレットを設定することができます。そのため、使用していないコネクタやモジュールを目にすることがありません。 ![Anypoint Studio のモジュールを追加および管理するオプションが含まれる Mule パレット](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/studio-palette.png) ## [](#maven-との自動インテグレーションによる連動関係の管理)Maven との自動インテグレーションによる連動関係の管理 Studio の旧バージョンでは、Mule の各モジュールが Eclipse プラグインで、「サイトの更新」メカニズムを使用したインストールが必要でした。今回、各モジュールが単なるプロジェクトの連動関係となり、Maven で管理されるようになりました。つまり、膨大な「サイトの更新」、プラグインのインストール、プラグインのバージョンなどに対処する必要がなくなります。Studio で自動的に Maven 連動関係を「pom.xml」ファイルに追加して追跡します。 Maven について知らなくても心配いりません。Studio が自動的に各プロジェクトにデフォルトの ​`pom.xml`​ ファイルを作成して Maven を管理します。 ## [](#xml-ビューへの移動)XML ビューへの移動 ビジュアルビューから XML にすばやく移動できるようになりました。 - 任意のコンポーネントを右クリックし、\[Go to XML (XML へ移動)\] を選択するだけです。 ## [](#anypoint-platform-アカウントの管理)Anypoint Platform アカウントの管理 Platform に関連するどの操作でも、アカウントやビジネスグループ (該当する場合) を変更できるクイック変更ツールバーが表示されます。このツールバーからアカウントを追加することもできます。 たとえば、新しい Mule プロジェクトを作成する場合 (\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\])、Design Center から API 実装を選択すると、選択ダイアログの上部にツールバーが表示されます。 ![新しい Mule プロジェクトの作成時の Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/studio-credentials.png) 同様に、Mule パレットから \[Search in Exchange (Exchange で検索)\] を選択すると、若干異なるツールバーが表示されます。 ![Mule パレットの Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/studio-credentials-exchange.png) ## [](#メタデータのストレージ)メタデータのストレージ Mule 4 アプリケーションには、データ種別に関するメタデータを保存する ​`application-types.xml`​ ファイルがあります。たとえば、新たに CSV 種別を作成すると、このファイルにそのメタデータが追加されます。この新しいファイルは、簡単に共有やコミット、競合が生じた場合のマージを実行できるため、メタデータ指向の開発に役立ちます。 ## [](#その他の改善点)その他の改善点 - 操作性を向上させる新しい一連のグラフィックアイコン。 - 操作のデフォルトの表示名を変更するときに、常に操作名 (Select、Delete など) を示すウォーターマークテキスト。この変更によって視覚的に確認しやすくなります。 - 折りたたみ可能なフローと対話型プレビュー。 # Mule 4 の概要: Studio 7 Mule 4 の新機能について学ぶ前に、Studio 7 をインストールして慣れておきます。Studio 7 は Mule 4 アプリケーションの開発環境です。Mule 4 をサポートするほか、生産性を向上させる新機能が多数追加されています。Studio 7 は Mule 3 アプリケーションの起動をサポートしていません。 ## [](#新しい-mule-パレット)新しい Mule パレット Studio 6 パレットでは、適切な操作を探すために、コネクタを見つけてキャンバスにドラッグし、操作を検索するという数段階のプロセスを経る必要がありました。Studio 7 ではこのプロセスを加速するために、アクセス時間、検出性、分類を向上させる 2 層構造のパレットが導入されています。コネクタの操作を直接検索し、実行頻度の高い操作を簡単にお気に入りに追加できます。 コネクタとモジュールの管理も改善されています。Studio 7 では、コネクタの各バージョンをプロジェクトに明示的に追加できるため、プロジェクト特有のパレットを設定することができます。そのため、使用していないコネクタやモジュールを目にすることがありません。 ![Anypoint Studio のモジュールを追加および管理するオプションが含まれる Mule パレット](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/studio-palette.png) ## [](#maven-との自動インテグレーションによる連動関係の管理)Maven との自動インテグレーションによる連動関係の管理 Studio の旧バージョンでは、Mule の各モジュールが Eclipse プラグインで、「サイトの更新」メカニズムを使用したインストールが必要でした。今回、各モジュールが単なるプロジェクトの連動関係となり、Maven で管理されるようになりました。つまり、膨大な「サイトの更新」、プラグインのインストール、プラグインのバージョンなどに対処する必要がなくなります。Studio で自動的に Maven 連動関係を「pom.xml」ファイルに追加して追跡します。 Maven について知らなくても心配いりません。Studio が自動的に各プロジェクトにデフォルトの ​`pom.xml`​ ファイルを作成して Maven を管理します。 ## [](#xml-ビューへの移動)XML ビューへの移動 ビジュアルビューから XML にすばやく移動できるようになりました。 - 任意のコンポーネントを右クリックし、\[Go to XML (XML へ移動)\] を選択するだけです。 ## [](#anypoint-platform-アカウントの管理)Anypoint Platform アカウントの管理 Platform に関連するどの操作でも、アカウントやビジネスグループ (該当する場合) を変更できるクイック変更ツールバーが表示されます。このツールバーからアカウントを追加することもできます。 たとえば、新しい Mule プロジェクトを作成する場合 (\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\])、Design Center から API 実装を選択すると、選択ダイアログの上部にツールバーが表示されます。 ![新しい Mule プロジェクトの作成時の Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/studio-credentials.png) 同様に、Mule パレットから \[Search in Exchange (Exchange で検索)\] を選択すると、若干異なるツールバーが表示されます。 ![Mule パレットの Studio ログイン情報](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/studio-credentials-exchange.png) ## [](#メタデータのストレージ)メタデータのストレージ Mule 4 アプリケーションには、データ種別に関するメタデータを保存する ​`application-types.xml`​ ファイルがあります。たとえば、新たに CSV 種別を作成すると、このファイルにそのメタデータが追加されます。この新しいファイルは、簡単に共有やコミット、競合が生じた場合のマージを実行できるため、メタデータ指向の開発に役立ちます。 ## [](#その他の改善点)その他の改善点 - 操作性を向上させる新しい一連のグラフィックアイコン。 - 操作のデフォルトの表示名を変更するときに、常に操作名 (Select、Delete など) を示すウォーターマークテキスト。この変更によって視覚的に確認しやすくなります。 - 折りたたみ可能なフローと対話型プレビュー。 # Mule 4 の概要: アプリケーションのパッケージ化 ## [](#アプリケーションの構造)アプリケーションの構造 Mule 4 では、Mule アプリケーションのパッケージ化の方法にいくつかの重要な変更が行われています。Mule アプリケーションは JAR としてパッケージ化されるようになり、構造が異なります。Mule Maven プラグインを使用すると、ソースコードを簡単にこの構造にパッケージ化できます。
場所 説明

META-INF/mule-artifact/mule-artifact.json

Mule アプリケーションの記述子 (​アプリケーション記述子​を参照)。

META-INF/mule-src/yourapp/

ソースコードの場所 (省略可能)。

repository

Maven レイアウトにあるアプリケーションのすべての連動関係のリポジトリ。アプリケーションのすべてのコネクタが含まれます。(例: repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar​)。

yourapp.xml

Mule の XML コード。
## [](#app_descriptor)アプリケーション記述子 Mule 4 のアプリケーションの ​`META-INF/mule-artifact/`​ に ​`mule-artifact.json`​ ファイルがあります。このファイルにアプリケーション、設定、必要な Mule バージョン、クラスローダー設定が説明されています。 ```json { "configs": [ "ch-usage-sync.xml" ], "redeploymentEnabled": true, "name": "ch-usage-sync", "minMuleVersion": "4.0.0", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ``` ### [](#アプリケーション記述子リファレンス)アプリケーション記述子リファレンス
属性 値のデータ型 説明

configs

Array of String (文字列の配列)

Mule の設定ファイルのセット。

redeploymentEnabled

Boolean (ブール)

アプリケーション設定ファイルを変更すると再デプロイメントがトリガーされるかどうか。

name

String (文字列)

アプリケーションのわかりやすい名前。

minMuleVersion

String (文字列)

アプリケーションのデプロイに必要な Mule Runtime の最小バージョン。

requiredProduct

String (文字列)

アプリケーションのデプロイに必要な製品種別。 MULE​ は、アプリケーションを Community Edition (CE) バージョンまたは Enterprise Edition (EE) バージョンにデプロイできることを示します。 MULE_EE​ は、アプリケーションを EE バージョンにのみデプロイできることを示します。

classLoaderModelLoaderDescriptor

Object (オブジェクト)

アプリケーションのクラスローディングモデルの記述子。​id​ 項目は、アプリケーションの連動関係とパッケージ/リソースの使用目的を理解するためにランタイムが使用するメカニズムを特定します。Mule はデフォルトで ​mule​ ID を使用します。つまり、アプリケーションからエクスポートされたパッケージとリソースが ​attributes​ 項目で説明され、連動関係は ​/META-INF/mule-artifact/classloader-model.json​ ファイルで説明されます。

bundleDescriptorLoader

Object (オブジェクト)

アプリケーションのバンドル座標の記述子。​id​ 項目は、アプリケーションのバンドル座標を理解するためにランタイムが使用するメカニズムを特定します。デフォルトは ​mule​ で、POM ファイルからアーティファクトグループ ID、アーティファクト ID、バージョンを読み込みます。

secureProperties

Array of String (文字列の配列)

プラットフォームで安全に管理する必要があるアーティファクトの一連の設定プロパティを宣言します。
## [](#アプリケーションのバージョン管理)アプリケーションのバージョン管理 Mule Runtime はすべてのアーティファクトで、 [セマンティックバージョン管理](https://semver.org/)​に従います。セマンティックバージョン管理に従うと、リリースされるアセットの新バージョンがどのようなものかを API のクライアントが容易に想像できます。たとえば、Mule Connector の場合について考えてみます。パッチバージョンが更新されれば、バグ修正 (つまりバグの修正のみ) であることが予想できます。マイナーバージョンが更新された場合は新機能を期待できます。このどちらの変更も後方互換性があると予想されるため、問題なくアップグレードできます。他方、コネクタのメジャーバージョンが更新される場合は、新しい機能を追加したり、はるかに優れた UX を提供したりするために必然的に後方互換性が失われることになります。 また、Mule アーティファクト (アプリケーション、ドメイン、ポリシー) はセマンティックバージョン管理に従うため、Mule アプリケーションを操作するときに何らかの検証が必要になることがあります。Anypoint Platform がセマンティックバージョン管理に従うことで、新しいアセットが整理され、エクスペリエンスが向上します。たとえば、Mule ドメインに新しいメジャーバージョンがある場合、そのバージョンで定義されている一連のグローバルコンポーネントが前回のメジャーバージョンとは異なることを期待できます。そして、新しいドメインを使用するならば、元のドメインに属する Mule アプリケーションの更新が必要になることが予想されます。 ## [](#mule-maven-プラグイン)Mule Maven プラグイン Mule 4 の Mule Maven プラグインはアプリケーションを規定の形式でパッケージ化し、対象の環境にデプロイできるようにします。このプラグインは Studio 7 によって自動的に ​`pom.xml`​ に追加されます。このプラグインを使用してアプリケーションをデプロイする方法については、Mule Maven プラグインのドキュメントを参照してください。
ドメイン、ポリシー、Mule アーティファクトプラグイン (コネクタ、モジュールなど) はすべて Mule アプリケーションと同じ構造です。アーティファクトの種類ごとに、アーティファクト記述子 (​mule-artifact.json​) のプロパティ数が異なりますが、どれもよく似ており、すべてセマンティックバージョン管理に従う必要があります。
## [](#関連情報)関連情報 - [Mule Maven プラグインを使用した Mule アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept#mule-application-packaging) - [Mule Maven プラグインを使用した Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept#mule-application-deployment) # Mule 4 の概要: アプリケーションのパッケージ化 ## [](#アプリケーションの構造)アプリケーションの構造 Mule 4 では、Mule アプリケーションのパッケージ化の方法にいくつかの重要な変更が行われています。Mule アプリケーションは JAR としてパッケージ化されるようになり、構造が異なります。Mule Maven プラグインを使用すると、ソースコードを簡単にこの構造にパッケージ化できます。
場所 説明

META-INF/mule-artifact/mule-artifact.json

Mule アプリケーションの記述子 (​アプリケーション記述子​を参照)。

META-INF/mule-src/yourapp/

ソースコードの場所 (省略可能)。

repository

Maven レイアウトにあるアプリケーションのすべての連動関係のリポジトリ。アプリケーションのすべてのコネクタが含まれます。(例: repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar​)。

yourapp.xml

Mule の XML コード。
## [](#app_descriptor)アプリケーション記述子 Mule 4 のアプリケーションの ​`META-INF/mule-artifact/`​ に ​`mule-artifact.json`​ ファイルがあります。このファイルにアプリケーション、設定、必要な Mule バージョン、クラスローダー設定が説明されています。 ```json { "configs": [ "ch-usage-sync.xml" ], "redeploymentEnabled": true, "name": "ch-usage-sync", "minMuleVersion": "4.0.0", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ``` ### [](#アプリケーション記述子リファレンス)アプリケーション記述子リファレンス
属性 値のデータ型 説明

configs

Array of String (文字列の配列)

Mule の設定ファイルのセット。

redeploymentEnabled

Boolean (ブール)

アプリケーション設定ファイルを変更すると再デプロイメントがトリガーされるかどうか。

name

String (文字列)

アプリケーションのわかりやすい名前。

minMuleVersion

String (文字列)

アプリケーションのデプロイに必要な Mule Runtime の最小バージョン。

requiredProduct

String (文字列)

アプリケーションのデプロイに必要な製品種別。 MULE​ は、アプリケーションを Community Edition (CE) バージョンまたは Enterprise Edition (EE) バージョンにデプロイできることを示します。 MULE_EE​ は、アプリケーションを EE バージョンにのみデプロイできることを示します。

classLoaderModelLoaderDescriptor

Object (オブジェクト)

アプリケーションのクラスローディングモデルの記述子。​id​ 項目は、アプリケーションの連動関係とパッケージ/リソースの使用目的を理解するためにランタイムが使用するメカニズムを特定します。Mule はデフォルトで ​mule​ ID を使用します。つまり、アプリケーションからエクスポートされたパッケージとリソースが ​attributes​ 項目で説明され、連動関係は ​/META-INF/mule-artifact/classloader-model.json​ ファイルで説明されます。

bundleDescriptorLoader

Object (オブジェクト)

アプリケーションのバンドル座標の記述子。​id​ 項目は、アプリケーションのバンドル座標を理解するためにランタイムが使用するメカニズムを特定します。デフォルトは ​mule​ で、POM ファイルからアーティファクトグループ ID、アーティファクト ID、バージョンを読み込みます。

secureProperties

Array of String (文字列の配列)

プラットフォームで安全に管理する必要があるアーティファクトの一連の設定プロパティを宣言します。
## [](#アプリケーションのバージョン管理)アプリケーションのバージョン管理 Mule Runtime はすべてのアーティファクトで、 [セマンティックバージョン管理](https://semver.org/)​に従います。セマンティックバージョン管理に従うと、リリースされるアセットの新バージョンがどのようなものかを API のクライアントが容易に想像できます。たとえば、Mule Connector の場合について考えてみます。パッチバージョンが更新されれば、バグ修正 (つまりバグの修正のみ) であることが予想できます。マイナーバージョンが更新された場合は新機能を期待できます。このどちらの変更も後方互換性があると予想されるため、問題なくアップグレードできます。他方、コネクタのメジャーバージョンが更新される場合は、新しい機能を追加したり、はるかに優れた UX を提供したりするために必然的に後方互換性が失われることになります。 また、Mule アーティファクト (アプリケーション、ドメイン、ポリシー) はセマンティックバージョン管理に従うため、Mule アプリケーションを操作するときに何らかの検証が必要になることがあります。Anypoint Platform がセマンティックバージョン管理に従うことで、新しいアセットが整理され、エクスペリエンスが向上します。たとえば、Mule ドメインに新しいメジャーバージョンがある場合、そのバージョンで定義されている一連のグローバルコンポーネントが前回のメジャーバージョンとは異なることを期待できます。そして、新しいドメインを使用するならば、元のドメインに属する Mule アプリケーションの更新が必要になることが予想されます。 ## [](#mule-maven-プラグイン)Mule Maven プラグイン Mule 4 の Mule Maven プラグインはアプリケーションを規定の形式でパッケージ化し、対象の環境にデプロイできるようにします。このプラグインは Studio 7 によって自動的に ​`pom.xml`​ に追加されます。このプラグインを使用してアプリケーションをデプロイする方法については、Mule Maven プラグインのドキュメントを参照してください。
ドメイン、ポリシー、Mule アーティファクトプラグイン (コネクタ、モジュールなど) はすべて Mule アプリケーションと同じ構造です。アーティファクトの種類ごとに、アーティファクト記述子 (​mule-artifact.json​) のプロパティ数が異なりますが、どれもよく似ており、すべてセマンティックバージョン管理に従う必要があります。
## [](#関連情報)関連情報 - [Mule Maven プラグインを使用した Mule アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept#mule-application-packaging) - [Mule Maven プラグインを使用した Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept#mule-application-deployment) # Mule 4 の概要: アプリケーションのパッケージ化 ## [](#アプリケーションの構造)アプリケーションの構造 Mule 4 では、Mule アプリケーションのパッケージ化の方法にいくつかの重要な変更が行われています。Mule アプリケーションは JAR としてパッケージ化されるようになり、構造が異なります。Mule Maven プラグインを使用すると、ソースコードを簡単にこの構造にパッケージ化できます。
場所 説明

META-INF/mule-artifact/mule-artifact.json

Mule アプリケーションの記述子 (「​アプリケーション記述子​」を参照)。

META-INF/mule-src/yourapp/

ソースコードの場所 (省略可能)。

repository

Maven レイアウトにあるアプリケーションのすべての連動関係のリポジトリ。アプリケーションのすべてのコネクタが含まれます。(例: repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar​)。

yourapp.xml

Mule の XML コード。
## [](#app_descriptor)アプリケーション記述子 Mule 4 のアプリケーションの ​`meta-INF/mule-artifact/`​ に ​`mule-artifact.json`​ ファイルがあります。このファイルにアプリケーション、設定、必要な Mule バージョン、クラスローダー設定が説明されています。 ```json { "configs": [ "ch-usage-sync.xml" ], "redeploymentEnabled": true, "name": "ch-usage-sync", "minMuleVersion": "4.0.0", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ``` ### [](#アプリケーション記述子リファレンス)アプリケーション記述子リファレンス
属性 値のデータ型 説明

configs

Array of String (文字列の配列)

Mule の設定ファイルのセット。

redeploymentEnabled

Boolean (ブール)

アプリケーション設定ファイルを変更すると再デプロイメントがトリガーされるかどうか。

name

String (文字列)

アプリケーションのわかりやすい名前。

minMuleVersion

String (文字列)

アプリケーションのデプロイに必要な Mule Runtime の最小バージョン。

requiredProduct

String (文字列)

アプリケーションのデプロイに必要な製品種別。 MULE​ は、アプリケーションを Community Edition (CE) バージョンまたは Enterprise Edition (EE) バージョンにデプロイできることを示します。 MULE_EE​ は、アプリケーションを EE バージョンにのみデプロイできることを示します。

classLoaderModelLoaderDescriptor

Object (オブジェクト)

アプリケーションのクラスローディングモデルの記述子。​id​ 項目は、アプリケーションの連動関係とパッケージ/リソースの使用目的を理解するためにランタイムが使用するメカニズムを特定します。Mule はデフォルトで ​mule​ ID を使用します。つまり、アプリケーションからエクスポートされたパッケージとリソースが ​attributes​ 項目で説明され、連動関係は ​/META-INF/mule-artifact/classloader-model.json​ ファイルで説明されます。

bundleDescriptorLoader

Object (オブジェクト)

アプリケーションのバンドル座標の記述子。​id​ 項目は、アプリケーションのバンドル座標を理解するためにランタイムが使用するメカニズムを特定します。デフォルトは ​mule​ で、POM ファイルからアーティファクトグループ ID、アーティファクト ID、バージョンを読み込みます。

secureProperties

Array of String (文字列の配列)

プラットフォームで安全に管理する必要があるアーティファクトの一連の設定プロパティを宣言します。
## [](#アプリケーションのバージョン管理)アプリケーションのバージョン管理 Mule Runtime はすべてのアーティファクトで [セマンティックバージョン管理](https://semver.org/)​に従います。セマンティックバージョン管理に従うと、リリースされるアセットの新バージョンがどのようなものかを API のクライアントが容易に想像できます。たとえば、Mule Connector の場合について考えてみます。パッチバージョンが更新されれば、バグ修正 (つまりバグの修正のみ) であることが予想できます。マイナーバージョンが更新された場合は新機能を期待できます。このどちらの変更も後方互換性があると予想されるため、問題なくアップグレードできます。他方、コネクタのメジャーバージョンが更新される場合は、新しい機能を追加したり、はるかに優れた UX を提供したりするために必然的に後方互換性が失われることになります。 また、Mule アーティファクト (アプリケーション、ドメイン、ポリシー) はセマンティックバージョン管理に従うため、Mule アプリケーションを操作するときに何らかの検証が必要になることがあります。Anypoint Platform がセマンティックバージョン管理に従うことで、新しいアセットが整理され、エクスペリエンスが向上します。たとえば、Mule ドメインに新しいメジャーバージョンがある場合、そのバージョンで定義されている一連のグローバルコンポーネントが前回のメジャーバージョンとは異なることを期待できます。そして、新しいドメインを使用するならば、元のドメインに属する Mule アプリケーションの更新が必要になることが予想されます。 ## [](#mule-maven-プラグイン)Mule Maven プラグイン Mule 4 の Mule Maven プラグインはアプリケーションを規定の形式でパッケージ化し、対象の環境にデプロイできるようにします。このプラグインは Studio 7 によって自動的に ​`pom.xml`​ に追加されます。このプラグインを使用してアプリケーションをデプロイする方法については、Mule Maven プラグインのドキュメントを参照してください。
ドメイン、ポリシー、Mule アーティファクトプラグイン (コネクタ、モジュールなど) はすべて Mule アプリケーションと同じ構造です。アーティファクトの種類ごとに、アーティファクト記述子 (​mule-artifact.json​) のプロパティ数が異なりますが、どれもよく似ており、すべてセマンティックバージョン管理に従う必要があります。
## [](#関連情報)関連情報 - [Mule Maven プラグインを使用した Mule アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept#mule-application-packaging) - [Mule Maven プラグインを使用した Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept#mule-application-deployment) # Mule 4 の概要: アプリケーションのパッケージ化 ## [](#アプリケーションの構造)アプリケーションの構造 Mule 4 では、Mule アプリケーションのパッケージ化の方法にいくつかの重要な変更が行われています。Mule アプリケーションは JAR としてパッケージ化されるようになり、構造が異なります。Mule Maven プラグインを使用すると、ソースコードを簡単にこの構造にパッケージ化できます。
場所 説明

META-INF/mule-artifact/mule-artifact.json

Mule アプリケーションの記述子 (​アプリケーション記述子​を参照)。

META-INF/mule-src/yourapp/

ソースコードの場所 (省略可能)。

repository

Maven レイアウトにあるアプリケーションのすべての連動関係のリポジトリ。アプリケーションのすべてのコネクタが含まれます。(例: repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar​)。

yourapp.xml

Mule の XML コード。
## [](#app_descriptor)アプリケーション記述子 Mule 4 のアプリケーションの ​`META-INF/mule-artifact/`​ に ​`mule-artifact.json`​ ファイルがあります。このファイルにアプリケーション、設定、必要な Mule バージョン、クラスローダー設定が説明されています。 ```json { "configs": [ "ch-usage-sync.xml" ], "redeploymentEnabled": true, "name": "ch-usage-sync", "minMuleVersion": "4.0.0", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ``` ### [](#アプリケーション記述子リファレンス)アプリケーション記述子リファレンス
属性 値のデータ型 説明

configs

Array of String (文字列の配列)

Mule の設定ファイルのセット。

redeploymentEnabled

Boolean (ブール)

アプリケーション設定ファイルを変更すると再デプロイメントがトリガーされるかどうか。

name

String (文字列)

アプリケーションのわかりやすい名前。

minMuleVersion

String (文字列)

アプリケーションのデプロイに必要な Mule Runtime の最小バージョン。

requiredProduct

String (文字列)

アプリケーションのデプロイに必要な製品種別。 MULE​ は、アプリケーションを Community Edition (CE) バージョンまたは Enterprise Edition (EE) バージョンにデプロイできることを示します。 MULE_EE​ は、アプリケーションを EE バージョンにのみデプロイできることを示します。

classLoaderModelLoaderDescriptor

Object (オブジェクト)

アプリケーションのクラスローディングモデルの記述子。​id​ 項目は、アプリケーションの連動関係とパッケージ/リソースの使用目的を理解するためにランタイムが使用するメカニズムを特定します。Mule はデフォルトで ​mule​ ID を使用します。つまり、アプリケーションからエクスポートされたパッケージとリソースが ​attributes​ 項目で説明され、連動関係は ​/META-INF/mule-artifact/classloader-model.json​ ファイルで説明されます。

bundleDescriptorLoader

Object (オブジェクト)

アプリケーションのバンドル座標の記述子。​id​ 項目は、アプリケーションのバンドル座標を理解するためにランタイムが使用するメカニズムを特定します。デフォルトは ​mule​ で、POM ファイルからアーティファクトグループ ID、アーティファクト ID、バージョンを読み込みます。

secureProperties

Array of String (文字列の配列)

プラットフォームで安全に管理する必要があるアーティファクトの一連の設定プロパティを宣言します。
## [](#アプリケーションのバージョン管理)アプリケーションのバージョン管理 Mule Runtime はすべてのアーティファクトで [セマンティックバージョン管理](https://semver.org/)​に従います。セマンティックバージョン管理に従うと、リリースされるアセットの新バージョンがどのようなものかを API のクライアントが容易に想像できます。たとえば、Mule Connector の場合について考えてみます。パッチバージョンが更新されれば、バグ修正 (つまりバグの修正のみ) であることが予想できます。マイナーバージョンが更新された場合は新機能を期待できます。このどちらの変更も後方互換性があると予想されるため、問題なくアップグレードできます。他方、コネクタのメジャーバージョンが更新される場合は、新しい機能を追加したり、はるかに優れた UX を提供したりするために必然的に後方互換性が失われることになります。 また、Mule アーティファクト (アプリケーション、ドメイン、ポリシー) はセマンティックバージョン管理に従うため、Mule アプリケーションを操作するときに何らかの検証が必要になることがあります。Anypoint Platform がセマンティックバージョン管理に従うことで、新しいアセットが整理され、エクスペリエンスが向上します。たとえば、Mule ドメインに新しいメジャーバージョンがある場合、そのバージョンで定義されている一連のグローバルコンポーネントが前回のメジャーバージョンとは異なることを期待できます。そして、新しいドメインを使用するならば、元のドメインに属する Mule アプリケーションの更新が必要になることが予想されます。 ## [](#mule-maven-プラグイン)Mule Maven プラグイン Mule 4 の Mule Maven プラグインはアプリケーションを規定の形式でパッケージ化し、対象の環境にデプロイできるようにします。このプラグインは Studio 7 によって自動的に ​`pom.xml`​ に追加されます。このプラグインを使用してアプリケーションをデプロイする方法については、Mule Maven プラグインのドキュメントを参照してください。
ドメイン、ポリシー、Mule アーティファクトプラグイン (コネクタ、モジュールなど) はすべて Mule アプリケーションと同じ構造です。アーティファクトの種類ごとに、アーティファクト記述子 (​mule-artifact.json​) のプロパティ数が異なりますが、どれもよく似ており、すべてセマンティックバージョン管理に従う必要があります。
## [](#関連情報)関連情報 - [Mule Maven プラグインを使用した Mule アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept#mule-application-packaging) - [Mule Maven プラグインを使用した Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept#mule-application-deployment) # Mule 4 の概要: アプリケーションのパッケージ化 ## [](#アプリケーションの構造)アプリケーションの構造 Mule 4 では、Mule アプリケーションのパッケージ化の方法にいくつかの重要な変更が行われています。Mule アプリケーションは JAR としてパッケージ化されるようになり、構造が異なります。Mule Maven プラグインを使用すると、ソースコードを簡単にこの構造にパッケージ化できます。
場所 説明

META-INF/mule-artifact/mule-artifact.json

Mule アプリケーションの記述子 (​アプリケーション記述子​を参照)。

META-INF/mule-src/yourapp/

ソースコードの場所 (省略可能)。

repository

Maven レイアウトにあるアプリケーションのすべての連動関係のリポジトリ。アプリケーションのすべてのコネクタが含まれます。(例: repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar​)。

yourapp.xml

Mule の XML コード。
## [](#app_descriptor)アプリケーション記述子 Mule 4 のアプリケーションの ​`META-INF/mule-artifact/`​ に ​`mule-artifact.json`​ ファイルがあります。このファイルにアプリケーション、設定、必要な Mule バージョン、クラスローダー設定が説明されています。 ```json { "configs": [ "ch-usage-sync.xml" ], "redeploymentEnabled": true, "name": "ch-usage-sync", "minMuleVersion": "4.0.0", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ``` ### [](#アプリケーション記述子リファレンス)アプリケーション記述子リファレンス
属性 値のデータ型 説明

configs

Array of String (文字列の配列)

Mule の設定ファイルのセット。

redeploymentEnabled

Boolean (ブール)

アプリケーション設定ファイルを変更すると再デプロイメントがトリガーされるかどうか。

name

String (文字列)

アプリケーションのわかりやすい名前。

minMuleVersion

String (文字列)

アプリケーションのデプロイに必要な Mule Runtime の最小バージョン。

requiredProduct

String (文字列)

アプリケーションのデプロイに必要な製品種別。 MULE​ は、アプリケーションを Community Edition (CE) バージョンまたは Enterprise Edition (EE) バージョンにデプロイできることを示します。 MULE_EE​ は、アプリケーションを EE バージョンにのみデプロイできることを示します。

classLoaderModelLoaderDescriptor

Object (オブジェクト)

アプリケーションのクラスローディングモデルの記述子。​id​ 項目は、アプリケーションの連動関係とパッケージ/リソースの使用目的を理解するためにランタイムが使用するメカニズムを特定します。Mule はデフォルトで ​mule​ ID を使用します。つまり、アプリケーションからエクスポートされたパッケージとリソースが ​attributes​ 項目で説明され、連動関係は ​/META-INF/mule-artifact/classloader-model.json​ ファイルで説明されます。

bundleDescriptorLoader

Object (オブジェクト)

アプリケーションのバンドル座標の記述子。​id​ 項目は、アプリケーションのバンドル座標を理解するためにランタイムが使用するメカニズムを特定します。デフォルトは ​mule​ で、POM ファイルからアーティファクトグループ ID、アーティファクト ID、バージョンを読み込みます。

secureProperties

Array of String (文字列の配列)

プラットフォームで安全に管理する必要があるアーティファクトの一連の設定プロパティを宣言します。
## [](#アプリケーションのバージョン管理)アプリケーションのバージョン管理 Mule Runtime はすべてのアーティファクトで [セマンティックバージョン管理](https://semver.org/)​に従います。セマンティックバージョン管理に従うと、リリースされるアセットの新バージョンがどのようなものかを API のクライアントが容易に想像できます。たとえば、Mule Connector の場合について考えてみます。パッチバージョンが更新されれば、バグ修正 (つまりバグの修正のみ) であることが予想できます。マイナーバージョンが更新された場合は新機能を期待できます。このどちらの変更も後方互換性があると予想されるため、問題なくアップグレードできます。他方、コネクタのメジャーバージョンが更新される場合は、新しい機能を追加したり、はるかに優れた UX を提供したりするために必然的に後方互換性が失われることになります。 また、Mule アーティファクト (アプリケーション、ドメイン、ポリシー) はセマンティックバージョン管理に従うため、Mule アプリケーションを操作するときに何らかの検証が必要になることがあります。Anypoint Platform がセマンティックバージョン管理に従うことで、新しいアセットが整理され、エクスペリエンスが向上します。たとえば、Mule ドメインに新しいメジャーバージョンがある場合、そのバージョンで定義されている一連のグローバルコンポーネントが前回のメジャーバージョンとは異なることを期待できます。そして、新しいドメインを使用するならば、元のドメインに属する Mule アプリケーションの更新が必要になることが予想されます。 ## [](#mule-maven-プラグイン)Mule Maven プラグイン Mule 4 の Mule Maven プラグインはアプリケーションを規定の形式でパッケージ化し、対象の環境にデプロイできるようにします。このプラグインは Studio 7 によって自動的に ​`pom.xml`​ に追加されます。このプラグインを使用してアプリケーションをデプロイする方法については、Mule Maven プラグインのドキュメントを参照してください。
ドメイン、ポリシー、Mule アーティファクトプラグイン (コネクタ、モジュールなど) はすべて Mule アプリケーションと同じ構造です。アーティファクトの種類ごとに、アーティファクト記述子 (​mule-artifact.json​) のプロパティ数が異なりますが、どれもよく似ており、すべてセマンティックバージョン管理に従う必要があります。
## [](#関連情報)関連情報 - [Mule Maven プラグインを使用した Mule アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept#mule-application-packaging) - [Mule Maven プラグインを使用した Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept#mule-application-deployment) # Mule 4 の概要: アプリケーションのパッケージ化 ## [](#アプリケーションの構造)アプリケーションの構造 Mule 4 では、Mule アプリケーションのパッケージ化の方法にいくつかの重要な変更が行われています。Mule アプリケーションは JAR としてパッケージ化されるようになり、構造が異なります。Mule Maven プラグインを使用すると、ソースコードを簡単にこの構造にパッケージ化できます。
場所 説明

META-INF/mule-artifact/mule-artifact.json

Mule アプリケーションの記述子 (​アプリケーション記述子​を参照)。

META-INF/mule-src/yourapp/

ソースコードの場所 (省略可能)。

repository

Maven レイアウトにあるアプリケーションのすべての連動関係のリポジトリ。アプリケーションのすべてのコネクタが含まれます。(例: repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar​)。

yourapp.xml

Mule の XML コード。
## [](#app_descriptor)アプリケーション記述子 Mule 4 のアプリケーションの ​`META-INF/mule-artifact/`​ に ​`mule-artifact.json`​ ファイルがあります。このファイルにアプリケーション、設定、必要な Mule バージョン、クラスローダー設定が説明されています。 ```json { "configs": [ "ch-usage-sync.xml" ], "redeploymentEnabled": true, "name": "ch-usage-sync", "minMuleVersion": "4.0.0", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ``` ### [](#アプリケーション記述子リファレンス)アプリケーション記述子リファレンス
属性 値のデータ型 説明

configs

Array of String (文字列の配列)

Mule の設定ファイルのセット。

redeploymentEnabled

Boolean (ブール)

アプリケーション設定ファイルを変更すると再デプロイメントがトリガーされるかどうか。

name

String (文字列)

アプリケーションのわかりやすい名前。

minMuleVersion

String (文字列)

アプリケーションのデプロイに必要な Mule Runtime の最小バージョン。

requiredProduct

String (文字列)

アプリケーションのデプロイに必要な製品種別。 MULE​ は、アプリケーションを Community Edition (CE) バージョンまたは Enterprise Edition (EE) バージョンにデプロイできることを示します。 MULE_EE​ は、アプリケーションを EE バージョンにのみデプロイできることを示します。

classLoaderModelLoaderDescriptor

Object (オブジェクト)

アプリケーションのクラスローディングモデルの記述子。​id​ 項目は、アプリケーションの連動関係とパッケージ/リソースの使用目的を理解するためにランタイムが使用するメカニズムを特定します。Mule はデフォルトで ​mule​ ID を使用します。つまり、アプリケーションからエクスポートされたパッケージとリソースが ​attributes​ 項目で説明され、連動関係は ​/META-INF/mule-artifact/classloader-model.json​ ファイルで説明されます。

bundleDescriptorLoader

Object (オブジェクト)

アプリケーションのバンドル座標の記述子。​id​ 項目は、アプリケーションのバンドル座標を理解するためにランタイムが使用するメカニズムを特定します。デフォルトは ​mule​ で、POM ファイルからアーティファクトグループ ID、アーティファクト ID、バージョンを読み込みます。

secureProperties

Array of String (文字列の配列)

プラットフォームで安全に管理する必要があるアーティファクトの一連の設定プロパティを宣言します。
## [](#アプリケーションのバージョン管理)アプリケーションのバージョン管理 Mule Runtime はすべてのアーティファクトで [セマンティックバージョン管理](https://semver.org/)​に従います。セマンティックバージョン管理に従うと、リリースされるアセットの新バージョンがどのようなものかを API のクライアントが容易に想像できます。たとえば、Mule Connector の場合について考えてみます。パッチバージョンが更新されれば、バグ修正 (つまりバグの修正のみ) であることが予想できます。マイナーバージョンが更新された場合は新機能を期待できます。このどちらの変更も後方互換性があると予想されるため、問題なくアップグレードできます。他方、コネクタのメジャーバージョンが更新される場合は、新しい機能を追加したり、はるかに優れた UX を提供したりするために必然的に後方互換性が失われることになります。 また、Mule アーティファクト (アプリケーション、ドメイン、ポリシー) はセマンティックバージョン管理に従うため、Mule アプリケーションを操作するときに何らかの検証が必要になることがあります。Anypoint Platform がセマンティックバージョン管理に従うことで、新しいアセットが整理され、エクスペリエンスが向上します。たとえば、Mule ドメインに新しいメジャーバージョンがある場合、そのバージョンで定義されている一連のグローバルコンポーネントが前回のメジャーバージョンとは異なることを期待できます。そして、新しいドメインを使用するならば、元のドメインに属する Mule アプリケーションの更新が必要になることが予想されます。 ## [](#mule-maven-プラグイン)Mule Maven プラグイン Mule 4 の Mule Maven プラグインはアプリケーションを規定の形式でパッケージ化し、対象の環境にデプロイできるようにします。このプラグインは Studio 7 によって自動的に ​`pom.xml`​ に追加されます。このプラグインを使用してアプリケーションをデプロイする方法については、Mule Maven プラグインのドキュメントを参照してください。
ドメイン、ポリシー、Mule アーティファクトプラグイン (コネクタ、モジュールなど) はすべて Mule アプリケーションと同じ構造です。アーティファクトの種類ごとに、アーティファクト記述子 (​mule-artifact.json​) のプロパティ数が異なりますが、どれもよく似ており、すべてセマンティックバージョン管理に従う必要があります。
## [](#関連情報)関連情報 - [Mule Maven プラグインを使用した Mule アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept#mule-application-packaging) - [Mule Maven プラグインを使用した Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept#mule-application-deployment) # Mule 4 の概要: アプリケーションのパッケージ化 ## [](#アプリケーションの構造)アプリケーションの構造 Mule 4 では、Mule アプリケーションのパッケージ化の方法にいくつかの重要な変更が行われています。Mule アプリケーションは JAR としてパッケージ化されるようになり、構造が異なります。Mule Maven プラグインを使用すると、ソースコードを簡単にこの構造にパッケージ化できます。
場所 説明

META-INF/mule-artifact/mule-artifact.json

Mule アプリケーションの記述子 (​アプリケーション記述子​を参照)。

META-INF/mule-src/yourapp/

ソースコードの場所 (省略可能)。

repository

Maven レイアウトにあるアプリケーションのすべての連動関係のリポジトリ。アプリケーションのすべてのコネクタが含まれます。(例: repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar​)。

yourapp.xml

Mule の XML コード。
## [](#app_descriptor)アプリケーション記述子 Mule 4 のアプリケーションの ​`META-INF/mule-artifact/`​ に ​`mule-artifact.json`​ ファイルがあります。このファイルにアプリケーション、設定、必要な Mule バージョン、クラスローダー設定が説明されています。 ```json { "configs": [ "ch-usage-sync.xml" ], "redeploymentEnabled": true, "name": "ch-usage-sync", "minMuleVersion": "4.0.0", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ``` ### [](#アプリケーション記述子リファレンス)アプリケーション記述子リファレンス
属性 値のデータ型 説明

configs

Array of String (文字列の配列)

Mule の設定ファイルのセット。

redeploymentEnabled

Boolean (ブール)

アプリケーション設定ファイルを変更すると再デプロイメントがトリガーされるかどうか。

name

String (文字列)

アプリケーションのわかりやすい名前。

minMuleVersion

String (文字列)

アプリケーションのデプロイに必要な Mule Runtime の最小バージョン。

requiredProduct

String (文字列)

アプリケーションのデプロイに必要な製品種別。 MULE​ は、アプリケーションを Community Edition (CE) バージョンまたは Enterprise Edition (EE) バージョンにデプロイできることを示します。 MULE_EE​ は、アプリケーションを EE バージョンにのみデプロイできることを示します。

classLoaderModelLoaderDescriptor

Object (オブジェクト)

アプリケーションのクラスローディングモデルの記述子。​id​ 項目は、アプリケーションの連動関係とパッケージ/リソースの使用目的を理解するためにランタイムが使用するメカニズムを特定します。Mule はデフォルトで ​mule​ ID を使用します。つまり、アプリケーションからエクスポートされたパッケージとリソースが ​attributes​ 項目で説明され、連動関係は ​/META-INF/mule-artifact/classloader-model.json​ ファイルで説明されます。

bundleDescriptorLoader

Object (オブジェクト)

アプリケーションのバンドル座標の記述子。​id​ 項目は、アプリケーションのバンドル座標を理解するためにランタイムが使用するメカニズムを特定します。デフォルトは ​mule​ で、POM ファイルからアーティファクトグループ ID、アーティファクト ID、バージョンを読み込みます。

secureProperties

Array of String (文字列の配列)

プラットフォームで安全に管理する必要があるアーティファクトの一連の設定プロパティを宣言します。
## [](#アプリケーションのバージョン管理)アプリケーションのバージョン管理 Mule Runtime はすべてのアーティファクトで [セマンティックバージョン管理](https://semver.org/)​に従います。セマンティックバージョン管理に従うと、リリースされるアセットの新バージョンがどのようなものかを API のクライアントが容易に想像できます。たとえば、Mule Connector の場合について考えてみます。パッチバージョンが更新されれば、バグ修正 (つまりバグの修正のみ) であることが予想できます。マイナーバージョンが更新された場合は新機能を期待できます。このどちらの変更も後方互換性があると予想されるため、問題なくアップグレードできます。他方、コネクタのメジャーバージョンが更新される場合は、新しい機能を追加したり、はるかに優れた UX を提供したりするために必然的に後方互換性が失われることになります。 また、Mule アーティファクト (アプリケーション、ドメイン、ポリシー) はセマンティックバージョン管理に従うため、Mule アプリケーションを操作するときに何らかの検証が必要になることがあります。Anypoint Platform がセマンティックバージョン管理に従うことで、新しいアセットが整理され、エクスペリエンスが向上します。たとえば、Mule ドメインに新しいメジャーバージョンがある場合、そのバージョンで定義されている一連のグローバルコンポーネントが前回のメジャーバージョンとは異なることを期待できます。そして、新しいドメインを使用するならば、元のドメインに属する Mule アプリケーションの更新が必要になることが予想されます。 ## [](#mule-maven-プラグイン)Mule Maven プラグイン Mule 4 の Mule Maven プラグインはアプリケーションを規定の形式でパッケージ化し、対象の環境にデプロイできるようにします。このプラグインは Studio 7 によって自動的に ​`pom.xml`​ に追加されます。このプラグインを使用してアプリケーションをデプロイする方法については、Mule Maven プラグインのドキュメントを参照してください。
ドメイン、ポリシー、Mule アーティファクトプラグイン (コネクタ、モジュールなど) はすべて Mule アプリケーションと同じ構造です。アーティファクトの種類ごとに、アーティファクト記述子 (​mule-artifact.json​) のプロパティ数が異なりますが、どれもよく似ており、すべてセマンティックバージョン管理に従う必要があります。
## [](#関連情報)関連情報 - [Mule Maven プラグインを使用した Mule アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept#mule-application-packaging) - [Mule Maven プラグインを使用した Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept#mule-application-deployment) # Mule 4 の概要: エラーハンドラー Java の例外処理プロセスでは何が起こったのかを理解するためにソースコードを確認したり、エラーを強制的に発生させたりする必要がありますが、Mule 4 ではこれ以外の方法も使用できるようになりました。Java の ​`Throwable`​ エラーや例外も引き続き使用できますが、Mule 4 では処理しやすいエラーの概念が正式に導入されています。スローされる可能性のあるエラーの種類を各コンポーネントで宣言して、設計の時点で潜在的なエラーを識別できるようになりました。 ## [](#mule-エラー)Mule エラー 実行に失敗すると、Mule に次のコンポーネントを含むエラーが示されます。 - 問題の説明。 - 問題の特性を表す種類。 - 原因 (失敗を引き起こした根本的な Java ​`Throwable`​)。 - エラーメッセージ (省略可能)。問題に関する Mule の適切なメッセージが記載されます。 たとえば、HTTP 要求に失敗して 401 状況コードが表示された場合、Mule エラーに次の情報が示されます。 Description: HTTP GET on resource ‘http://localhost:36682/testPath’ failed: unauthorized (401) Type: HTTP:UNAUTHORIZED Cause: a ResponseValidatorTypedException instance Error Message: { "message" : "Could not authorize the user." } ## [](#エラーの種類)エラーの種類 上記の例では、エラーの種類は単純に ​`UNAUTHORIZED`​ ではなく ​`HTTP:UNAUTHORIZED`​ です。エラーの種類が名前空間と識別子の両方で構成されるため、ドメインからその種類を判別することができます (​`HTTP:NOT_FOUND`​、​`FILE:NOT_FOUND`​ など)。名前空間はそのコネクタによって定義されますが、コアランタイムエラーの名前空間は暗黙的なため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同一とみなされます。 エラーの種類のもう一つの重要な特徴は、親種別のある可能性があることです。たとえば、​`HTTP:UNAUTHORIZED`​ は親として ​`MULE:CLIENT_SECURITY`​ を持ち、さらにその親として ​`MULE:SECURITY`​ があります。このため、エラーの種類がグローバルなエラーの細部であることがわかります。つまり、広範なセキュリティ問題の 1 つにクライアントセキュリティエラーがあり、その 1 つに HTTP 未承認エラーがあるということです。 こうした階層により、大まかなルーティングが可能になります。たとえば、​`MULE:SECURITY`​ のハンドラーが HTTP 未承認エラーと OAuth エラーの両方をキャッチします。以下は、コアランタイムがどのような階層になっているかを示しています。 ![エラー階層](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-hierarchy.png) どのエラーも一般的なエラーと ​`CRITICAL`​ エラーのどちらかに該当しますが、後者は極めて深刻なため処理することができません。一般的な階層の最上位が ​`ANY`​ で、その下位の全種類がこれに該当します。 ここで重要な点は、失敗の明確な理由が見つからない場合に使用される ​`UNKNOWN`​ という種類に注意することです。このエラーは ​`ANY`​ 種類経由でしか処理できないため、今後既存のアプリケーションの動作を変更することなく、不明なエラーを特定できるようになります。 コネクタについては、各コネクタがそのコアランタイムエラーを考慮して各自のエラー種類階層を定義しますが、​`CONNECTIVITY`​ と ​`RETRY_EXHAUSTED`​ の 2 種類はすべてのコネクタに共通するため、常に存在します。 ## [](#error_handlers)エラーハンドラー Mule 4 では、​`error-handler`​ コンポーネントを導入してエラー処理が再設計されています。このコンポーネントには任意の数の内部ハンドラーを含めることができ、最初に一致したハンドラーにエラーをルーティングできます。これらのハンドラーに該当するのが ​`on-error-continue`​ や ​`on-error-propagate`​ で、どちらもエラーの種類 (あるいは数種類のエラー) または式 (高度なユースケースの場合) との照合をサポートしています。こうしたハンドラーは、Mule 3 の選択例外 (​`choice-exception-strategy`​)、キャッチ例外 (​`catch-exception-strategy`​)、ロールバック例外 (​`rollback-exception-strategy`​) 戦略によく似ていますが、はるかにシンプルで一貫しています。 Mule 4 でエラーが生じると、エラーハンドラーが実行され、最初に一致したハンドラーにエラーがルーティングされます。この時点でエラーが検査されるため、使用するコンポーネント (Flow または Try スコープなど) に応じたハンドラーを実行して処理できます。 - `on-error-continue`​ が実行され、実行の結果がそのオーナーの結果として (オーナーが実行を正常に完了したかのように) 使用されます。 また、この時点のすべてのトランザクションがコミットされます。 - `on-error-propagate`​ はすべてのトランザクションをロールバックしてから実行され、その結果が使用されて既存のエラーが再度スローされます。つまり、そのオーナーは「失敗した」とみなされます。 HTTP リスナーが、HTTP 要求を実行する別のフローへの Flow Reference コンポーネントをトリガーする、次のアプリケーションについて考えてみます。メッセージの受信時にすべてうまくいけば (下図の 1)、参照がトリガーされ (2)、要求が実行されて (3)、応答を正常に受信します (HTTP 状況コード 200) (4)。 ![エラー処理の例 1](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-example-1.png) エラーハンドラーの設定が ​`inner-flow`​ であるため HTTP 要求に失敗し、​`HTTP:NOT_FOUND`​ エラーが表示された場合 (下図の 3)、エラーが伝搬され (4)、Flow Reference コンポーネントが失敗します (2)。ただし、​`primary-flow`​ によって ​`on-error-continue`​ を使用してエラーが処理されるため、含まれている Logger が実行され (5)、正常な応答 (HTTP 状況コード 200) が返されます (6)。 ![エラー処理の例 1](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-example-2.png) 要求に失敗し、未承認エラーが表示された場合は (3)、​`on-error-continue`​ により ​`inner-flow`​ が処理を行い、ファイルから静的コンテンツを取得します (4)。そして、Flow Reference コンポーネントも正常に行われ (2)、正常な応答 (HTTP 状況コード 200) が返されます (5)。 ![エラー処理の例 3](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-example-3.png) では、HTTP 要求で別のエラーが生じた場合はどうでしょうか? このフローには ​`NOT_FOUND`​ エラーと ​`UNAUTHORIZED`​ エラーのハンドラーしかありませんが、デフォルトで他のエラーも伝搬します。つまり、スローされたエラーに一致するハンドラーがなければ、エラーが再びスローされます。たとえば、要求に失敗し、「メソッドが許可されていません」というエラーが表示された場合 (3)、このエラーが伝搬され、Flow Reference コンポーネントが失敗し (2)、この伝搬により応答も失敗します (4)。 ![エラー処理の例 4](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-example-4.png) 上記のシナリオを回避するためには、最後のハンドラーを ​`HTTP:UNAUTHORIZED`​ ではなく、​`ANY`​ と照合するようにします。以下は、​`HTTP`​ 要求で生じる可能性のある全エラーがどのように提示されるかを示しています。 ![エラー処理の Any](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-any.png) 式を使用してエラーを照合することもできます。たとえば、エラーの処理時に Mule エラーを使用できるため、このエラーを使用してすべてのエラーを HTTP 名前空間と照合することができます。 ![エラー処理の式](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-expression.png) ## [](#try-スコープ)Try スコープ Mule 3 では概してエラーをフローレベルでしか処理できないため、エラーに対処するためにはフローにロジックを抽出する必要があります。Mule 4 では、フロー内で内部コンポーネントのエラーのみを処理する Try スコープが導入されました。このスコープは旧来の Transactional スコープの後継で、トランザクションもサポートします。 ![Try スコープ](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-try.png) 前の例では、On Error Propagate コンポーネントがデータベース接続エラーを伝播するように設定されているため、​`try`​ が失敗して、フローのエラーハンドラーが実行されます。 On Error Continue コンポーネントは、他のすべてのエラーを処理するように設定されています。この場合、Try スコープの実行は正常に完了し、フローの実行が次のプロセッサーである HTTP Request 操作に引き継がれます。 ## [](#エラーのマッピング)エラーのマッピング Mule 4 では、デフォルトのエラーをカスタムエラーにマップできるようになりました。Try スコープは便利ですが、同一のコンポーネントがいくつかあり、それぞれのエラーを区別したい場合、これらのエラーに Try を使用するとアプリケーションがわかりづらくなることがあります。この場合は代わりに、各コンポーネントにエラーマッピングを追加することが考えられます。つまり、コンポーネントからのすべてまたは一定のエラーストリーミングが任意の別のエラーにマップされるようにします。たとえば、それぞれ HTTP 要求コンポーネントを使用する 2 つの API の結果を集約する場合、デフォルトでは API 1 と API 2 のエラーが同じため、API ごとに区別したいことがあります。 最初の要求からのエラーをカスタムの ​`API_1`​ エラーにマップし、2 つ目の要求のエラーを ​`API_2`​ にマップすれば、これらのエラーを異なるハンドラーにルーティングできます。次の例では、​`HTTP:INTERNAL_SERVER_ERROR`​ がマップされるため、API がダウンしたときにそれぞれ異なる処理ポリシーが適用されます (1 つ目の API はエラーの伝搬、2 つ目の API はエラーの処理)。 ![エラー処理のマッピング](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-mappings.png) ## [](#関連情報)関連情報 - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept) # Mule 4 の概要: エラーハンドラー Java の例外処理プロセスでは何が起こったのかを理解するためにソースコードを確認したり、エラーを強制的に発生させたりする必要がありますが、Mule 4 ではこれ以外の方法も使用できるようになりました。Java の ​`Throwable`​ エラーや例外も引き続き使用できますが、Mule 4 では処理しやすいエラーの概念が正式に導入されています。スローされる可能性のあるエラーの種類を各コンポーネントで宣言して、設計の時点で潜在的なエラーを識別できるようになりました。 ## [](#mule-エラー)Mule エラー 実行に失敗すると、Mule に次のコンポーネントを含むエラーが示されます。 - 問題の説明。 - 問題の特性を表す種類。 - 原因 (失敗を引き起こした根本的な Java ​`Throwable`​)。 - エラーメッセージ (省略可能)。問題に関する Mule の適切なメッセージが記載されます。 たとえば、HTTP 要求に失敗して 401 状況コードが表示された場合、Mule エラーに次の情報が示されます。 Description: HTTP GET on resource ‘http://localhost:36682/testPath’ failed: unauthorized (401) Type: HTTP:UNAUTHORIZED Cause: a ResponseValidatorTypedException instance Error Message: { "message" : "Could not authorize the user." } ## [](#エラーの種類)エラーの種類 上記の例では、エラーの種類は単純に ​`UNAUTHORIZED`​ ではなく ​`HTTP:UNAUTHORIZED`​ です。エラーの種類が名前空間と識別子の両方で構成されるため、ドメインからその種類を判別することができます (​`HTTP:NOT_FOUND`​、​`FILE:NOT_FOUND`​ など)。名前空間はそのコネクタによって定義されますが、コアランタイムエラーの名前空間は暗黙的なため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同一とみなされます。 エラーの種類のもう一つの重要な特徴は、親種別のある可能性があることです。たとえば、​`HTTP:UNAUTHORIZED`​ は親として ​`MULE:CLIENT_SECURITY`​ を持ち、さらにその親として ​`MULE:SECURITY`​ があります。このため、エラーの種類がグローバルなエラーの細部であることがわかります。つまり、広範なセキュリティ問題の 1 つにクライアントセキュリティエラーがあり、その 1 つに HTTP 未承認エラーがあるということです。 こうした階層により、大まかなルーティングが可能になります。たとえば、​`MULE:SECURITY`​ のハンドラーが HTTP 未承認エラーと OAuth エラーの両方をキャッチします。以下は、コアランタイムがどのような階層になっているかを示しています。 ![エラー階層](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-hierarchy.png) どのエラーも一般的なエラーと ​`CRITICAL`​ エラーのどちらかに該当しますが、後者は極めて深刻なため処理することができません。一般的な階層の最上位が ​`ANY`​ で、その下位の全種類がこれに該当します。 ここで重要な点は、失敗の明確な理由が見つからない場合に使用される ​`UNKNOWN`​ という種類に注意することです。このエラーは ​`ANY`​ 種類経由でしか処理できないため、今後既存のアプリケーションの動作を変更することなく、不明なエラーを特定できるようになります。 コネクタについては、各コネクタがそのコアランタイムエラーを考慮して各自のエラー種類階層を定義しますが、​`CONNECTIVITY`​ と ​`RETRY_EXHAUSTED`​ の 2 種類はすべてのコネクタに共通するため、常に存在します。 ## [](#error_handlers)エラーハンドラー Mule 4 では、​`error-handler`​ コンポーネントを導入してエラー処理が再設計されています。このコンポーネントには任意の数の内部ハンドラーを含めることができ、最初に一致したハンドラーにエラーをルーティングできます。これらのハンドラーに該当するのが ​`on-error-continue`​ や ​`on-error-propagate`​ で、どちらもエラーの種類 (あるいは数種類のエラー) または式 (高度なユースケースの場合) との照合をサポートしています。こうしたハンドラーは、Mule 3 の選択例外 (​`choice-exception-strategy`​)、キャッチ例外 (​`catch-exception-strategy`​)、ロールバック例外 (​`rollback-exception-strategy`​) 戦略によく似ていますが、はるかにシンプルで一貫しています。 Mule 4 でエラーが生じると、エラーハンドラーが実行され、最初に一致したハンドラーにエラーがルーティングされます。この時点でエラーが検査されるため、使用するコンポーネント (Flow または Try スコープなど) に応じたハンドラーを実行して処理できます。 - `on-error-continue`​ が実行され、実行の結果がそのオーナーの結果として (オーナーが実行を正常に完了したかのように) 使用されます。 また、この時点のすべてのトランザクションがコミットされます。 - `on-error-propagate`​ はすべてのトランザクションをロールバックしてから実行され、その結果が使用されて既存のエラーが再度スローされます。つまり、そのオーナーは「失敗した」とみなされます。 HTTP リスナーが、HTTP 要求を実行する別のフローへの Flow Reference コンポーネントをトリガーする、次のアプリケーションについて考えてみます。メッセージの受信時にすべてうまくいけば (下図の 1)、参照がトリガーされ (2)、要求が実行されて (3)、応答を正常に受信します (HTTP 状況コード 200) (4)。 ![エラー処理の例 1](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-example-1.png) エラーハンドラーの設定が ​`inner-flow`​ であるため HTTP 要求に失敗し、​`HTTP:NOT_FOUND`​ エラーが表示された場合 (下図の 3)、エラーが伝搬され (4)、Flow Reference コンポーネントが失敗します (2)。ただし、​`primary-flow`​ によって ​`on-error-continue`​ を使用してエラーが処理されるため、含まれている Logger が実行され (5)、正常な応答 (HTTP 状況コード 200) が返されます (6)。 ![エラー処理の例 1](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-example-2.png) 要求に失敗し、未承認エラーが表示された場合は (3)、​`on-error-continue`​ により ​`inner-flow`​ が処理を行い、ファイルから静的コンテンツを取得します (4)。そして、Flow Reference コンポーネントも正常に行われ (2)、正常な応答 (HTTP 状況コード 200) が返されます (5)。 ![エラー処理の例 3](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-example-3.png) では、HTTP 要求で別のエラーが生じた場合はどうでしょうか? このフローには ​`NOT_FOUND`​ エラーと ​`UNAUTHORIZED`​ エラーのハンドラーしかありませんが、デフォルトで他のエラーも伝搬します。つまり、スローされたエラーに一致するハンドラーがなければ、エラーが再びスローされます。たとえば、要求に失敗し、「メソッドが許可されていません」というエラーが表示された場合 (3)、このエラーが伝搬され、Flow Reference コンポーネントが失敗し (2)、この伝搬により応答も失敗します (4)。 ![エラー処理の例 4](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-example-4.png) 上記のシナリオを回避するためには、最後のハンドラーを ​`HTTP:UNAUTHORIZED`​ ではなく、​`ANY`​ と照合するようにします。以下は、​`HTTP`​ 要求で生じる可能性のある全エラーがどのように提示されるかを示しています。 ![エラー処理の Any](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-any.png) 式を使用してエラーを照合することもできます。たとえば、エラーの処理時に Mule エラーを使用できるため、このエラーを使用してすべてのエラーを HTTP 名前空間と照合することができます。 ![エラー処理の式](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-expression.png) ## [](#try-スコープ)Try スコープ Mule 3 では概してエラーをフローレベルでしか処理できないため、エラーに対処するためにはフローにロジックを抽出する必要があります。Mule 4 では、フロー内で内部コンポーネントのエラーのみを処理する Try スコープが導入されました。このスコープは旧来の Transactional スコープの後継で、トランザクションもサポートします。 ![Try スコープ](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-try.png) 前の例では、On Error Propagate コンポーネントがデータベース接続エラーを伝播するように設定されているため、​`try`​ が失敗して、フローのエラーハンドラーが実行されます。 On Error Continue コンポーネントは、他のすべてのエラーを処理するように設定されています。この場合、Try スコープの実行は正常に完了し、フローの実行が次のプロセッサーである HTTP Request 操作に引き継がれます。 ## [](#エラーのマッピング)エラーのマッピング Mule 4 では、デフォルトのエラーをカスタムエラーにマップできるようになりました。Try スコープは便利ですが、同一のコンポーネントがいくつかあり、それぞれのエラーを区別したい場合、これらのエラーに Try を使用するとアプリケーションがわかりづらくなることがあります。この場合は代わりに、各コンポーネントにエラーマッピングを追加することが考えられます。つまり、コンポーネントからのすべてまたは一定のエラーストリーミングが任意の別のエラーにマップされるようにします。たとえば、それぞれ HTTP 要求コンポーネントを使用する 2 つの API の結果を集約する場合、デフォルトでは API 1 と API 2 のエラーが同じため、API ごとに区別したいことがあります。 マッピングにより、エラーを適切なエラーハンドラーにルーティングすることでエラー処理をカスタマイズできます。次の例では、最初の Request 操作からエラーハンドラー ​`APP:API_1`​ にエラーをルーティングし、2 つ目の Request 操作から ​`APP:API_2`​ にエラーをルーティングしています。この例では、API がダウンしたときに異なる処理ポリシーを適用するために ​`HTTP:INTERNAL_SERVER_ERROR`​ を各エラーハンドラーにマッピングしています。片方のマッピングは、最初の API から来たエラーを伝播します。他方のマッピングは、2 つ目の API から来たエラーを処理します。 ![エラー処理のマッピング](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-mappings.png) ## [](#関連情報)関連情報 - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept) # Mule 4 の概要: エラーハンドラー Java の例外処理プロセスでは何が起こったのかを理解するためにソースコードを確認したり、エラーを強制的に発生させたりする必要がありますが、Mule 4 ではこれ以外の方法も使用できるようになりました。Java の ​`Throwable`​ エラーや例外も引き続き使用できますが、Mule 4 では処理しやすいエラーの概念が正式に導入されています。スローされる可能性のあるエラーの種類を各コンポーネントで宣言して、設計の時点で潜在的なエラーを識別できるようになりました。 ## [](#mule-エラー)Mule エラー 実行に失敗すると、Mule に次のコンポーネントを含むエラーが示されます。 - 問題の説明。 - 問題の特性を表す種類。 - 原因 (失敗を引き起こした根本的な Java ​`Throwable`​)。 - エラーメッセージ (省略可能)。問題に関する Mule の適切なメッセージが記載されます。 たとえば、HTTP 要求に失敗して 401 状況コードが表示された場合、Mule エラーに次の情報が示されます。 Description: HTTP GET on resource ‘http://localhost:36682/testPath’ failed: unauthorized (401) Type: HTTP:UNAUTHORIZED Cause: a ResponseValidatorTypedException instance Error Message: { "message" : "Could not authorize the user." } ## [](#エラー種別)エラー種別 上記の例では、エラー種別は単純に ​`UNAUTHORIZED`​ ではなく ​`HTTP:UNAUTHORIZED`​ です。エラーの種類が名前空間と識別子の両方で構成されるため、ドメインからその種類を判別することができます (​`HTTP:NOT_FOUND`​、​`FILE:NOT_FOUND`​ など)。名前空間はそのコネクタによって定義されますが、コアランタイムエラーの名前空間は暗黙的なため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同一とみなされます。 エラーの種類のもう一つの重要な特徴は、親種別のある可能性があることです。たとえば、​`HTTP:UNAUTHORIZED`​ は親として ​`MULE:CLIENT_SECURITY`​ を持ち、さらにその親として ​`MULE:SECURITY`​ があります。このため、エラーの種類がグローバルなエラーの細部であることがわかります。つまり、広範なセキュリティ問題の 1 つにクライアントセキュリティエラーがあり、その 1 つに HTTP 未承認エラーがあるということです。 こうした階層により、大まかなルーティングが可能になります。たとえば、​`MULE:SECURITY`​ のハンドラーが HTTP 未承認エラーと OAuth エラーの両方をキャッチします。以下は、コアランタイムがどのような階層になっているかを示しています。 ![エラー階層](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-hierarchy.png) どのエラーも一般的なエラーと ​`CRITICAL`​ エラーのどちらかに該当しますが、後者は極めて深刻なため処理することができません。一般的な階層の最上位が ​`ANY`​ で、その下位の全種類がこれに該当します。 ここで重要な点は、失敗の明確な理由が見つからない場合に使用される ​`UNKNOWN`​ という種類に注意することです。このエラーは ​`ANY`​ 種類経由でしか処理できないため、今後既存のアプリケーションの動作を変更することなく、不明なエラーを特定できるようになります。 コネクタについては、各コネクタがそのコアランタイムエラーを考慮して各自のエラー種類階層を定義しますが、​`CONNECTIVITY`​ と ​`RETRY_EXHAUSTED`​ の 2 種類はすべてのコネクタに共通するため、常に存在します。 ## [](#error_handlers)エラーハンドラー Mule 4 では、​`error-handler`​ コンポーネントを導入してエラー処理が再設計されています。このコンポーネントには任意の数の内部ハンドラーを含めることができ、最初に一致したハンドラーにエラーをルーティングできます。これらのハンドラーに該当するのが ​`on-error-continue`​ や ​`on-error-propagate`​ で、どちらも エラーの種類 (あるいは数種類のエラー) または式 (高度なユースケースの場合) との照合をサポートしています。こうしたハンドラーは、Mule 3 の選択例外 (​`choice-exception-strategy`​)、キャッチ例外 (​`catch-exception-strategy`​)、ロールバック例外 (​`rollback-exception-strategy`​) 戦略によく似ていますが、はるかにシンプルで一貫しています。 Mule 4 でエラーが生じると、エラーハンドラーが実行され、最初に一致したハンドラーにエラーがルーティングされます。この時点でエラーが検査されるため、使用するコンポーネント (Flow または Try スコープなど) に応じたハンドラーを実行して処理できます。 - `on-error-continue`​ が実行され、実行の結果がそのオーナーの結果として (オーナーが実行を正常に完了したかのように) 使用されます。 また、この時点のすべてのトランザクションがコミットされます。 - `on-error-propagate`​ はすべてのトランザクションをロールバックしてから実行され、その結果が使用されて既存のエラーが再度スローされます。つまり、そのオーナーは「失敗した」とみなされます。 HTTP リスナーが、HTTP 要求を実行する別のフローへの Flow Reference コンポーネントをトリガーする、次のアプリケーションについて考えてみます。メッセージの受信時にすべてうまくいけば (下図の 1)、参照がトリガーされ (2)、要求が実行されて (3)、応答を正常に受信します (HTTP 状況コード 200) (4)。 ![エラー処理の例 1](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-example-1.png) エラーハンドラーの設定が ​`inner-flow`​ であるため HTTP 要求に失敗し、​`HTTP:NOT_FOUND`​ エラーが表示された場合 (下図の 3)、エラーが伝搬され (4)、Flow Reference コンポーネントが失敗します (2)。ただし、​`primary-flow`​ によって ​`on-error-continue`​ を使用してエラーが処理されるため、含まれている Logger が実行され (5)、正常な応答 (HTTP 状況コード 200) が返されます (6)。 ![エラー処理の例 1](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-example-2.png) 要求に失敗し、未承認エラーが表示された場合は (3)、​`on-error-continue`​ により ​`inner-flow`​ が処理を行い、ファイルから静的コンテンツを取得します (4)。そして、Flow Reference コンポーネントも正常に行われ (2)、正常な応答 (HTTP 状況コード 200) が返されます (5)。 ![エラー処理の例 3](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-example-3.png) では、HTTP 要求で別のエラーが生じた場合はどうでしょうか? このフローには ​`NOT_FOUND`​ エラーと ​`UNAUTHORIZED`​ エラーのハンドラーしかありませんが、デフォルトで他のエラーも伝搬します。つまり、スローされたエラーに一致するハンドラーがなければ、エラーが再びスローされます。たとえば、要求に失敗し、「メソッドが許可されていません」というエラーが表示された場合 (3)、このエラーが伝搬され、Flow Reference コンポーネントが失敗し (2)、この伝搬により応答も失敗します (4)。 ![エラー処理の例 4](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-example-4.png) 上記のシナリオを回避するためには、最後のハンドラーを ​`HTTP:UNAUTHORIZED`​ ではなく、​`ANY`​ と照合するようにします。以下は、​`HTTP`​ 要求で生じる可能性のある全エラーがどのように提示されるかを示しています。 ![エラー処理の Any](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-any.png) 式を使用してエラーを照合することもできます。たとえば、エラーの処理時に Mule エラーを使用できるため、このエラーを使用してすべてのエラーを HTTP 名前空間と照合することができます。 ![エラー処理の式](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-expression.png) ## [](#try-スコープ)Try スコープ Mule 3 では概してエラーをフローレベルでしか処理できないため、エラーに対処するためにはフローにロジックを抽出する必要があります。Mule 4 では、フロー内で内部コンポーネントのエラーのみを処理する Try スコープが導入されました。このスコープは旧来の Transactional スコープの後継で、トランザクションもサポートします。 ![Try スコープ](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-try.png) 前の例では、On Error Propagate コンポーネントがデータベース接続エラーを伝播するように設定されているため、​`try`​ が失敗して、フローのエラーハンドラーが実行されます。 On Error Continue コンポーネントは、他のすべてのエラーを処理するように設定されています。この場合、Try スコープの実行は正常に完了し、フローの実行が次のプロセッサーである HTTP Request 操作に引き継がれます。 ## [](#エラーマッピング)エラーマッピング Mule 4 では、デフォルトのエラーをカスタムエラーにマップできるようになりました。Try スコープは便利ですが、同一のコンポーネントがいくつかあり、それぞれのエラーを区別したい場合、これらのエラーに Try を使用するとアプリケーションがわかりづらくなることがあります。この場合は代わりに、各コンポーネントにエラーマッピングを追加することが考えられます。つまり、コンポーネントからのすべてまたは一定のエラーストリーミングが任意の別のエラーにマップされるようにします。たとえば、それぞれ HTTP 要求コンポーネントを使用する 2 つの API の結果を集約する場合、デフォルトでは API 1 と API 2 のエラーが同じため、API ごとに区別したいことがあります。 マッピングにより、エラーを適切なエラーハンドラーにルーティングすることでエラー処理をカスタマイズできます。次の例では、最初の Request 操作からエラーハンドラー ​`APP:API_1`​ にエラーをルーティングし、2 つ目の Request 操作から ​`APP:API_2`​ にエラーをルーティングしています。この例では、API がダウンしたときに異なる処理ポリシーを適用するために ​`HTTP:INTERNAL_SERVER_ERROR`​ を各エラーハンドラーにマッピングしています。片方のマッピングは、最初の API から来たエラーを伝播します。他方のマッピングは、2 つ目の API から来たエラーを処理します。 ![エラー処理のマッピング](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-mappings.png) ## [](#関連情報)関連情報 - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept) # Mule 4 の概要: エラーハンドラー Java の例外処理プロセスでは何が起こったのかを理解するためにソースコードを確認したり、エラーを強制的に発生させたりする必要がありますが、Mule 4 ではこれ以外の方法も使用できるようになりました。Java の ​`Throwable`​ エラーや例外も引き続き使用できますが、Mule 4 では処理しやすいエラーの概念が正式に導入されています。スローされる可能性のあるエラーの種類を各コンポーネントで宣言して、設計の時点で潜在的なエラーを識別できるようになりました。 ## [](#mule-エラー)Mule エラー 実行に失敗すると、Mule に次のコンポーネントを含むエラーが示されます。 - 問題の説明。 - 問題の特性を表す種類。 - 原因 (失敗を引き起こした根本的な Java ​`Throwable`​)。 - エラーメッセージ (省略可能)。問題に関する Mule の適切なメッセージが記載されます。 たとえば、HTTP 要求に失敗して 401 状況コードが表示された場合、Mule エラーに次の情報が示されます。 Description: HTTP GET on resource ‘http://localhost:36682/testPath’ failed: unauthorized (401) Type: HTTP:UNAUTHORIZED Cause: a ResponseValidatorTypedException instance Error Message: { "message" : "Could not authorize the user." } ## [](#エラーの種類)エラーの種類 上記の例では、エラーの種類は単純に ​`UNAUTHORIZED`​ ではなく ​`HTTP:UNAUTHORIZED`​ です。エラーの種類が名前空間と識別子の両方で構成されるため、ドメインからその種類を判別することができます (​`HTTP:NOT_FOUND`​、​`FILE:NOT_FOUND`​ など)。名前空間はそのコネクタによって定義されますが、コアランタイムエラーの名前空間は暗黙的なため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同一とみなされます。 エラーの種類のもう一つの重要な特徴は、親種別のある可能性があることです。たとえば、​`HTTP:UNAUTHORIZED`​ は親として ​`MULE:CLIENT_SECURITY`​ を持ち、さらにその親として ​`MULE:SECURITY`​ があります。このため、エラーの種類がグローバルなエラーの細部であることがわかります。つまり、広範なセキュリティ問題の 1 つにクライアントセキュリティエラーがあり、その 1 つに HTTP 未承認エラーがあるということです。 こうした階層により、大まかなルーティングが可能になります。たとえば、​`MULE:SECURITY`​ のハンドラーが HTTP 未承認エラーと OAuth エラーの両方をキャッチします。以下は、コアランタイムがどのような階層になっているかを示しています。 ![エラー階層](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-hierarchy.png) どのエラーも一般的なエラーと ​`CRITICAL`​ エラーのどちらかに該当しますが、後者は極めて深刻なため処理することができません。一般的な階層の最上位が ​`ANY`​ で、その下位の全種類がこれに該当します。 ここで重要な点は、失敗の明確な理由が見つからない場合に使用される ​`UNKNOWN`​ という種類に注意することです。このエラーは ​`ANY`​ 種類経由でしか処理できないため、今後既存のアプリケーションの動作を変更することなく、不明なエラーを特定できるようになります。 コネクタについては、各コネクタがそのコアランタイムエラーを考慮して各自のエラー種類階層を定義しますが、​`CONNECTIVITY`​ と ​`RETRY_EXHAUSTED`​ の 2 種類はすべてのコネクタに共通するため、常に存在します。 ## [](#error_handlers)エラーハンドラー Mule 4 では、​`error-handler`​ コンポーネントを導入してエラー処理が再設計されています。このコンポーネントには任意の数の内部ハンドラーを含めることができ、最初に一致したハンドラーにエラーをルーティングできます。これらのハンドラーに該当するのが ​`on-error-continue`​ や ​`on-error-propagate`​ で、どちらもエラーの種類 (あるいは数種類のエラー) または式 (高度なユースケースの場合) との照合をサポートしています。こうしたハンドラーは、Mule 3 の選択例外 (​`choice-exception-strategy`​)、キャッチ例外 (​`catch-exception-strategy`​)、ロールバック例外 (​`rollback-exception-strategy`​) 戦略によく似ていますが、はるかにシンプルで一貫しています。 Mule 4 でエラーが生じると、エラーハンドラーが実行され、最初に一致したハンドラーにエラーがルーティングされます。この時点でエラーが検査されるため、使用するコンポーネント (Flow または Try スコープなど) に応じたハンドラーを実行して処理できます。 - `on-error-continue`​ が実行され、実行の結果がそのオーナーの結果として (オーナーが実行を正常に完了したかのように) 使用されます。 また、この時点のすべてのトランザクションがコミットされます。 - `on-error-propagate`​ はすべてのトランザクションをロールバックしてから実行され、その結果が使用されて既存のエラーが再度スローされます。つまり、そのオーナーは「失敗した」とみなされます。 HTTP リスナーが、HTTP 要求を実行する別のフローへの Flow Reference コンポーネントをトリガーする、次のアプリケーションについて考えてみます。メッセージの受信時にすべてうまくいけば (下図の 1)、参照がトリガーされ (2)、要求が実行されて (3)、応答を正常に受信します (HTTP 状況コード 200) (4)。 ![エラー処理の例 1](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-example-1.png) エラーハンドラーの設定が ​`inner-flow`​ であるため HTTP 要求に失敗し、​`HTTP:NOT_FOUND`​ エラーが表示された場合 (下図の 3)、エラーが伝搬され (4)、Flow Reference コンポーネントが失敗します (2)。ただし、​`primary-flow`​ によって ​`on-error-continue`​ を使用してエラーが処理されるため、含まれている Logger が実行され (5)、正常な応答 (HTTP 状況コード 200) が返されます (6)。 ![エラー処理の例 1](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-example-2.png) 要求に失敗し、未承認エラーが表示された場合は (3)、​`on-error-continue`​ により ​`inner-flow`​ が処理を行い、ファイルから静的コンテンツを取得します (4)。そして、Flow Reference コンポーネントも正常に行われ (2)、正常な応答 (HTTP 状況コード 200) が返されます (5)。 ![エラー処理の例 3](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-example-3.png) では、HTTP 要求で別のエラーが生じた場合はどうでしょうか? このフローには ​`NOT_FOUND`​ エラーと ​`UNAUTHORIZED`​ エラーのハンドラーしかありませんが、デフォルトで他のエラーも伝搬します。つまり、スローされたエラーに一致するハンドラーがなければ、エラーが再びスローされます。たとえば、要求に失敗し、「メソッドが許可されていません」というエラーが表示された場合 (3)、このエラーが伝搬され、Flow Reference コンポーネントが失敗し (2)、この伝搬により応答も失敗します (4)。 ![エラー処理の例 4](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-example-4.png) 上記のシナリオを回避するためには、最後のハンドラーを ​`HTTP:UNAUTHORIZED`​ ではなく、​`ANY`​ と照合するようにします。以下は、​`HTTP`​ 要求で生じる可能性のある全エラーがどのように提示されるかを示しています。 ![エラー処理の Any](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-any.png) 式を使用してエラーを照合することもできます。たとえば、エラーの処理時に Mule エラーを使用できるため、このエラーを使用してすべてのエラーを HTTP 名前空間と照合することができます。 ![エラー処理の式](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-expression.png) ## [](#try-スコープ)Try スコープ Mule 3 では概してエラーをフローレベルでしか処理できないため、エラーに対処するためにはフローにロジックを抽出する必要があります。Mule 4 では、フロー内で内部コンポーネントのエラーのみを処理する Try スコープが導入されました。このスコープは旧来の Transactional スコープの後継で、トランザクションもサポートします。 ![Try スコープ](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-try.png) 前の例では、On Error Propagate コンポーネントがデータベース接続エラーを伝播するように設定されているため、​`try`​ が失敗して、フローのエラーハンドラーが実行されます。 On Error Continue コンポーネントは、他のすべてのエラーを処理するように設定されています。この場合、Try スコープの実行は正常に完了し、フローの実行が次のプロセッサーである HTTP Request 操作に引き継がれます。 ## [](#エラーのマッピング)エラーのマッピング Mule 4 では、デフォルトのエラーをカスタムエラーにマップできるようになりました。Try スコープは便利ですが、同一のコンポーネントがいくつかあり、それぞれのエラーを区別したい場合、これらのエラーに Try を使用するとアプリケーションがわかりづらくなることがあります。この場合は代わりに、各コンポーネントにエラーマッピングを追加することが考えられます。つまり、コンポーネントからのすべてまたは一定のエラーストリーミングが任意の別のエラーにマップされるようにします。たとえば、それぞれ HTTP 要求コンポーネントを使用する 2 つの API の結果を集約する場合、デフォルトでは API 1 と API 2 のエラーが同じため、API ごとに区別したいことがあります。 マッピングにより、エラーを適切なエラーハンドラーにルーティングすることでエラー処理をカスタマイズできます。次の例では、最初の Request 操作からエラーハンドラー ​`APP:API_1`​ にエラーをルーティングし、2 つ目の Request 操作から ​`APP:API_2`​ にエラーをルーティングしています。この例では、API がダウンしたときに異なる処理ポリシーを適用するために ​`HTTP:INTERNAL_SERVER_ERROR`​ を各エラーハンドラーにマッピングしています。片方のマッピングは、最初の API から来たエラーを伝播します。他方のマッピングは、2 つ目の API から来たエラーを処理します。 ![エラー処理のマッピング](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-mappings.png) ## [](#関連情報)関連情報 - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept) # Mule 4 の概要: エラーハンドラー Java の例外処理プロセスでは何が起こったのかを理解するためにソースコードを確認したり、エラーを強制的に発生させたりする必要がありますが、Mule 4 ではこれ以外の方法も使用できるようになりました。Java の ​`Throwable`​ エラーや例外も引き続き使用できますが、Mule 4 では処理しやすいエラーの概念が正式に導入されています。スローされる可能性のあるエラーの種類を各コンポーネントで宣言して、設計の時点で潜在的なエラーを識別できるようになりました。 ## [](#mule-エラー)Mule エラー 実行に失敗すると、Mule に次のコンポーネントを含むエラーが示されます。 - 問題の説明。 - 問題の特性を表す種類。 - 原因 (失敗を引き起こした根本的な Java ​`Throwable`​)。 - エラーメッセージ (省略可能)。問題に関する Mule の適切なメッセージが記載されます。 たとえば、HTTP 要求に失敗して 401 状況コードが表示された場合、Mule エラーに次の情報が示されます。 Description: HTTP GET on resource ‘http://localhost:36682/testPath’ failed: unauthorized (401) Type: HTTP:UNAUTHORIZED Cause: a ResponseValidatorTypedException instance Error Message: { "message" : "Could not authorize the user." } ## [](#エラーの種類)エラーの種類 上記の例では、エラーの種類は単純に ​`UNAUTHORIZED`​ ではなく ​`HTTP:UNAUTHORIZED`​ です。エラーの種類が名前空間と識別子の両方で構成されるため、ドメインからその種類を判別することができます (​`HTTP:NOT_FOUND`​、​`FILE:NOT_FOUND`​ など)。名前空間はそのコネクタによって定義されますが、コアランタイムエラーの名前空間は暗黙的なため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同一とみなされます。 エラーの種類のもう一つの重要な特徴は、親種別のある可能性があることです。たとえば、​`HTTP:UNAUTHORIZED`​ は親として ​`MULE:CLIENT_SECURITY`​ を持ち、さらにその親として ​`MULE:SECURITY`​ があります。このため、エラーの種類がグローバルなエラーの細部であることがわかります。つまり、広範なセキュリティ問題の 1 つにクライアントセキュリティエラーがあり、その 1 つに HTTP 未承認エラーがあるということです。 こうした階層により、大まかなルーティングが可能になります。たとえば、​`MULE:SECURITY`​ のハンドラーが HTTP 未承認エラーと OAuth エラーの両方をキャッチします。以下は、コアランタイムがどのような階層になっているかを示しています。 ![ANY や CRITICAL などのカテゴリが表示されているエラー種別の階層](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-hierarchy.png) どのエラーも一般的なエラーと ​`CRITICAL`​ エラーのどちらかに該当しますが、後者は極めて深刻なため処理することができません。一般的な階層の最上位が ​`ANY`​ で、その下位の全種類がこれに該当します。 ここで重要な点は、失敗の明確な理由が見つからない場合に使用される ​`UNKNOWN`​ という種類に注意することです。このエラーは ​`ANY`​ 種類経由でしか処理できないため、今後既存のアプリケーションの動作を変更することなく、不明なエラーを特定できるようになります。 コネクタについては、各コネクタがそのコアランタイムエラーを考慮して各自のエラー種類階層を定義しますが、​`CONNECTIVITY`​ と ​`RETRY_EXHAUSTED`​ の 2 種類はすべてのコネクタに共通するため、常に存在します。 ## [](#error_handlers)エラーハンドラー Mule 4 では、​`error-handler`​ コンポーネントを導入してエラー処理が再設計されています。このコンポーネントには任意の数の内部ハンドラーを含めることができ、最初に一致したハンドラーにエラーをルーティングできます。これらのハンドラーに該当するのが ​`on-error-continue`​ や ​`on-error-propagate`​ で、どちらもエラーの種類 (あるいは数種類のエラー) または式 (高度なユースケースの場合) との照合をサポートしています。こうしたハンドラーは、Mule 3 の選択例外 (​`choice-exception-strategy`​)、キャッチ例外 (​`catch-exception-strategy`​)、ロールバック例外 (​`rollback-exception-strategy`​) 戦略によく似ていますが、はるかにシンプルで一貫しています。 Mule 4 でエラーが生じると、エラーハンドラーが実行され、最初に一致したハンドラーにエラーがルーティングされます。この時点でエラーが検査されるため、使用するコンポーネント (Flow または Try スコープなど) に応じたハンドラーを実行して処理できます。 - `on-error-continue`​ が実行され、実行の結果がそのオーナーの結果として (オーナーが実行を正常に完了したかのように) 使用されます。 また、この時点のすべてのトランザクションがコミットされます。 - `on-error-propagate`​ はすべてのトランザクションをロールバックしてから実行され、その結果が使用されて既存のエラーが再度スローされます。つまり、そのオーナーは「失敗した」とみなされます。 HTTP リスナーが、HTTP 要求を実行する別のフローへの Flow Reference コンポーネントをトリガーする、次のアプリケーションについて考えてみます。メッセージの受信時にすべてうまくいけば (下図の 1)、参照がトリガーされ (2)、要求が実行されて (3)、応答を正常に受信します (HTTP 状況コード 200) (4)。 ![NOT\_FOUND が含まれる HTTP エラーのエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-example-1.png) エラーハンドラーの設定が ​`inner-flow`​ であるため HTTP 要求に失敗し、​`HTTP:NOT_FOUND`​ エラーが表示された場合 (下図の 3)、エラーが伝搬され (4)、Flow Reference コンポーネントが失敗します (2)。ただし、​`primary-flow`​ によって ​`on-error-continue`​ を使用してエラーが処理されるため、含まれている Logger が実行され (5)、正常な応答 (HTTP 状況コード 200) が返されます (6)。 ![NOT\_FOUND が含まれる inner-flow の HTTP エラーのエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-example-2.png) 要求に失敗し、未承認エラーが表示された場合は (3)、​`on-error-continue`​ により ​`inner-flow`​ が処理を行い、ファイルから静的コンテンツを取得します (4)。そして、Flow Reference コンポーネントも正常に行われ (2)、正常な応答 (HTTP 状況コード 200) が返されます (5)。 ![UNAUTHORIZED が含まれる inner-flow の HTTP のエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-example-3.png) では、HTTP 要求で別のエラーが生じた場合はどうでしょうか? このフローには ​`NOT_FOUND`​ エラーと ​`UNAUTHORIZED`​ エラーのハンドラーしかありませんが、デフォルトで他のエラーも伝搬します。つまり、スローされたエラーに一致するハンドラーがなければ、エラーが再びスローされます。たとえば、要求に失敗し、「メソッドが許可されていません」というエラーが表示された場合 (3)、このエラーが伝搬され、Flow Reference コンポーネントが失敗し (2)、この伝搬により応答も失敗します (4)。 ![失敗応答になる HTTP のエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-example-4.png) 上記のシナリオを回避するためには、最後のハンドラーを ​`HTTP:UNAUTHORIZED`​ ではなく、​`ANY`​ と照合するようにします。以下は、​`HTTP`​ 要求で生じる可能性のある全エラーがどのように提示されるかを示しています。 ![On Error Continue の ANY などの種別が含まれる \[General (一般)\] 項目](_images/error-handling-any.png) また、項目の場合は、 式を使用してエラーを照合することもできます。たとえば、エラーの処理時に Mule エラーを使用できるため、このエラーを使用してすべてのエラーを HTTP 名前空間と照合することができます。 ![HTTP エラーを処理する式が表示されている On Error Continue の 「General (一般)」 項目](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-expression.png) ## [](#try-スコープ)Try スコープ Mule 3 では概してエラーをフローレベルでしか処理できないため、エラーに対処するためにはフローにロジックを抽出する必要があります。Mule 4 では、フロー内で内部コンポーネントのエラーのみを処理する Try スコープが導入されました。このスコープは旧来の Transactional スコープの後継で、トランザクションもサポートします。 ![エラーの伝播と設定を行うコンポーネントが含まれる Try スコープが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-try.png) 前の例では、On Error Propagate コンポーネントがデータベース接続エラーを伝播するように設定されているため、​`try`​ が失敗して、フローのエラーハンドラーが実行されます。 On Error Continue コンポーネントは、他のすべてのエラーを処理するように設定されています。この場合、Try スコープの実行は正常に完了し、フローの実行が次のプロセッサーである HTTP Request 操作に引き継がれます。 ## [](#エラーのマッピング)エラーのマッピング Mule 4 では、デフォルトのエラーをカスタムエラーにマップできるようになりました。Try スコープは便利ですが、同一のコンポーネントがいくつかあり、それぞれのエラーを区別したい場合、これらのエラーに Try を使用するとアプリケーションがわかりづらくなることがあります。この場合は代わりに、各コンポーネントにエラーマッピングを追加することが考えられます。つまり、コンポーネントからのすべてまたは一定のエラーストリーミングが任意の別のエラーにマップされるようにします。たとえば、それぞれ HTTP 要求コンポーネントを使用する 2 つの API の結果を集約する場合、デフォルトでは API 1 と API 2 のエラーが同じため、API ごとに区別したいことがあります。 マッピングにより、エラーを適切なエラーハンドラーにルーティングすることでエラー処理をカスタマイズできます。次の例では、最初の Request 操作からエラーハンドラー ​`APP:API_1`​ にエラーをルーティングし、2 つ目の Request 操作から ​`APP:API_2`​ にエラーをルーティングしています。この例では、API がダウンしたときに異なる処理ポリシーを適用するために ​`HTTP:INTERNAL_SERVER_ERROR`​ を各エラーハンドラーにマッピングしています。片方のマッピングは、最初の API から来たエラーを伝播します。他方のマッピングは、2 つ目の API から来たエラーを処理します。 ![HTTP 内部サーバーエラーのエラーマッピング設定が表示されている設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-mappings.png) ## [](#関連情報)関連情報 - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept) # Mule 4 の概要: エラーハンドラー Java の例外処理プロセスでは何が起こったのかを理解するためにソースコードを確認したり、エラーを強制的に発生させたりする必要がありますが、Mule 4 ではこれ以外の方法も使用できるようになりました。Java の ​`Throwable`​ エラーや例外も引き続き使用できますが、Mule 4 では処理しやすいエラーの概念が正式に導入されています。スローされる可能性のあるエラーの種類を各コンポーネントで宣言して、設計の時点で潜在的なエラーを識別できるようになりました。 ## [](#mule-エラー)Mule エラー 実行に失敗すると、Mule に次のコンポーネントを含むエラーが示されます。 - 問題の説明。 - 問題の特性を表す種類。 - 原因 (失敗を引き起こした根本的な Java ​`Throwable`​)。 - エラーメッセージ (省略可能)。問題に関する Mule の適切なメッセージが記載されます。 たとえば、HTTP 要求に失敗して 401 状況コードが表示された場合、Mule エラーに次の情報が示されます。 Description: HTTP GET on resource ‘http://localhost:36682/testPath’ failed: unauthorized (401) Type: HTTP:UNAUTHORIZED Cause: a ResponseValidatorTypedException instance Error Message: { "message" : "Could not authorize the user." } ## [](#エラーの種類)エラーの種類 上記の例では、エラーの種類は単純に ​`UNAUTHORIZED`​ ではなく ​`HTTP:UNAUTHORIZED`​ です。エラーの種類が名前空間と識別子の両方で構成されるため、ドメインからその種類を判別することができます (​`HTTP:NOT_FOUND`​、​`FILE:NOT_FOUND`​ など)。名前空間はそのコネクタによって定義されますが、コアランタイムエラーの名前空間は暗黙的なため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同一とみなされます。 エラーの種類のもう一つの重要な特徴は、親種別のある可能性があることです。たとえば、​`HTTP:UNAUTHORIZED`​ は親として ​`MULE:CLIENT_SECURITY`​ を持ち、さらにその親として ​`MULE:SECURITY`​ があります。このため、エラーの種類がグローバルなエラーの細部であることがわかります。つまり、広範なセキュリティ問題の 1 つにクライアントセキュリティエラーがあり、その 1 つに HTTP 未承認エラーがあるということです。 こうした階層により、大まかなルーティングが可能になります。たとえば、​`MULE:SECURITY`​ のハンドラーが HTTP 未承認エラーと OAuth エラーの両方をキャッチします。以下は、コアランタイムがどのような階層になっているかを示しています。 ![ANY や CRITICAL などのカテゴリが表示されているエラー種別の階層](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-hierarchy.png) どのエラーも一般的なエラーと ​`CRITICAL`​ エラーのどちらかに該当しますが、後者は極めて深刻なため処理することができません。一般的な階層の最上位が ​`ANY`​ で、その下位の全種類がこれに該当します。 ここで重要な点は、失敗の明確な理由が見つからない場合に使用される ​`UNKNOWN`​ という種類に注意することです。このエラーは ​`ANY`​ 種類経由でしか処理できないため、今後既存のアプリケーションの動作を変更することなく、不明なエラーを特定できるようになります。 コネクタについては、各コネクタがそのコアランタイムエラーを考慮して各自のエラー種類階層を定義しますが、​`CONNECTIVITY`​ と ​`RETRY_EXHAUSTED`​ の 2 種類はすべてのコネクタに共通するため、常に存在します。 ## [](#error_handlers)エラーハンドラー Mule 4 では、​`error-handler`​ コンポーネントを導入してエラー処理が再設計されています。このコンポーネントには任意の数の内部ハンドラーを含めることができ、最初に一致したハンドラーにエラーをルーティングできます。これらのハンドラーに該当するのが ​`on-error-continue`​ や ​`on-error-propagate`​ で、どちらもエラーの種類 (あるいは数種類のエラー) または式 (高度なユースケースの場合) との照合をサポートしています。こうしたハンドラーは、Mule 3 の選択例外 (​`choice-exception-strategy`​)、キャッチ例外 (​`catch-exception-strategy`​)、ロールバック例外 (​`rollback-exception-strategy`​) 戦略によく似ていますが、はるかにシンプルで一貫しています。 Mule 4 でエラーが生じると、エラーハンドラーが実行され、最初に一致したハンドラーにエラーがルーティングされます。この時点でエラーが検査されるため、使用するコンポーネント (Flow または Try スコープなど) に応じたハンドラーを実行して処理できます。 - `on-error-continue`​ が実行され、実行の結果がそのオーナーの結果として (オーナーが実行を正常に完了したかのように) 使用されます。 また、この時点のすべてのトランザクションがコミットされます。 - `on-error-propagate`​ はすべてのトランザクションをロールバックしてから実行され、その結果が使用されて既存のエラーが再度スローされます。つまり、そのオーナーは「失敗した」とみなされます。 HTTP リスナーが、HTTP 要求を実行する別のフローへの Flow Reference コンポーネントをトリガーする、次のアプリケーションについて考えてみます。メッセージの受信時にすべてうまくいけば (下図の 1)、参照がトリガーされ (2)、要求が実行されて (3)、応答を正常に受信します (HTTP 状況コード 200) (4)。 ![NOT\_FOUND が含まれる HTTP エラーのエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-handling-example-1.png) エラーハンドラーの設定が ​`inner-flow`​ であるため HTTP 要求に失敗し、​`HTTP:NOT_FOUND`​ エラーが表示された場合 (下図の 3)、エラーが伝搬され (4)、Flow Reference コンポーネントが失敗します (2)。ただし、​`primary-flow`​ によって ​`on-error-continue`​ を使用してエラーが処理されるため、含まれている Logger が実行され (5)、正常な応答 (HTTP 状況コード 200) が返されます (6)。 ![NOT\_FOUND が含まれる inner-flow の HTTP エラーのエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-handling-example-2.png) 要求に失敗し、未承認エラーが表示された場合は (3)、​`on-error-continue`​ により ​`inner-flow`​ が処理を行い、ファイルから静的コンテンツを取得します (4)。そして、Flow Reference コンポーネントも正常に行われ (2)、正常な応答 (HTTP 状況コード 200) が返されます (5)。 ![UNAUTHORIZED が含まれる inner-flow の HTTP のエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-handling-example-3.png) では、HTTP 要求で別のエラーが生じた場合はどうでしょうか? このフローには ​`NOT_FOUND`​ エラーと ​`UNAUTHORIZED`​ エラーのハンドラーしかありませんが、デフォルトで他のエラーも伝搬します。つまり、スローされたエラーに一致するハンドラーがなければ、エラーが再びスローされます。たとえば、要求に失敗し、「メソッドが許可されていません」というエラーが表示された場合 (3)、このエラーが伝搬され、Flow Reference コンポーネントが失敗し (2)、この伝搬により応答も失敗します (4)。 ![失敗応答になる HTTP のエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-handling-example-4.png) 上記のシナリオを回避するためには、最後のハンドラーを ​`HTTP:UNAUTHORIZED`​ ではなく、​`ANY`​ と照合するようにします。以下は、​`HTTP`​ 要求で生じる可能性のある全エラーがどのように提示されるかを示しています。 ![On Error Continue の ANY などの種別が含まれる \[General (一般)\] 項目](_images/error-handling-any.png) また、項目の場合は、 式を使用してエラーを照合することもできます。たとえば、エラーの処理時に Mule エラーを使用できるため、このエラーを使用してすべてのエラーを HTTP 名前空間と照合することができます。 ![HTTP エラーを処理する式が表示されている On Error Continue の 「General (一般)」 項目](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-handling-expression.png) ## [](#try-スコープ)Try スコープ Mule 3 では概してエラーをフローレベルでしか処理できないため、エラーに対処するためにはフローにロジックを抽出する必要があります。Mule 4 では、フロー内で内部コンポーネントのエラーのみを処理する Try スコープが導入されました。このスコープは旧来の Transactional スコープの後継で、トランザクションもサポートします。 ![エラーの伝播と設定を行うコンポーネントが含まれる Try スコープが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-handling-try.png) 前の例では、On Error Propagate コンポーネントがデータベース接続エラーを伝播するように設定されているため、​`try`​ が失敗して、フローのエラーハンドラーが実行されます。 On Error Continue コンポーネントは、他のすべてのエラーを処理するように設定されています。この場合、Try スコープの実行は正常に完了し、フローの実行が次のプロセッサーである HTTP Request 操作に引き継がれます。 ## [](#エラーのマッピング)エラーのマッピング Mule 4 では、デフォルトのエラーをカスタムエラーにマップできるようになりました。Try スコープは便利ですが、同一のコンポーネントがいくつかあり、それぞれのエラーを区別したい場合、これらのエラーに Try を使用するとアプリケーションがわかりづらくなることがあります。この場合は代わりに、各コンポーネントにエラーマッピングを追加することが考えられます。つまり、コンポーネントからのすべてまたは一定のエラーストリーミングが任意の別のエラーにマップされるようにします。たとえば、それぞれ HTTP 要求コンポーネントを使用する 2 つの API の結果を集約する場合、デフォルトでは API 1 と API 2 のエラーが同じため、API ごとに区別したいことがあります。 マッピングにより、エラーを適切なエラーハンドラーにルーティングすることでエラー処理をカスタマイズできます。次の例では、最初の Request 操作からエラーハンドラー ​`APP:API_1`​ にエラーをルーティングし、2 つ目の Request 操作から ​`APP:API_2`​ にエラーをルーティングしています。この例では、API がダウンしたときに異なる処理ポリシーを適用するために ​`HTTP:INTERNAL_SERVER_ERROR`​ を各エラーハンドラーにマッピングしています。片方のマッピングは、最初の API から来たエラーを伝播します。他方のマッピングは、2 つ目の API から来たエラーを処理します。 ![HTTP 内部サーバーエラーのエラーマッピング設定が表示されている設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-handling-mappings.png) ## [](#関連情報)関連情報 - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept) # Mule 4 の概要: エラーハンドラー Java の例外処理プロセスでは何が起こったのかを理解するためにソースコードを確認したり、エラーを強制的に発生させたりする必要がありますが、Mule 4 ではこれ以外の方法も使用できるようになりました。Java の ​`Throwable`​ エラーや例外も引き続き使用できますが、Mule 4 では処理しやすいエラーの概念が正式に導入されています。スローされる可能性のあるエラーの種類を各コンポーネントで宣言して、設計の時点で潜在的なエラーを識別できるようになりました。 ## [](#mule-エラー)Mule エラー 実行に失敗すると、Mule に次のコンポーネントを含むエラーが示されます。 - 問題の説明。 - 問題の特性を表す種類。 - 原因 (失敗を引き起こした根本的な Java ​`Throwable`​)。 - エラーメッセージ (省略可能)。問題に関する Mule の適切なメッセージが記載されます。 たとえば、HTTP 要求に失敗して 401 状況コードが表示された場合、Mule エラーに次の情報が示されます。 Description: HTTP GET on resource ‘http://localhost:36682/testPath’ failed: unauthorized (401) Type: HTTP:UNAUTHORIZED Cause: a ResponseValidatorTypedException instance Error Message: { "message" : "Could not authorize the user." } ## [](#エラーの種類)エラーの種類 上記の例では、エラーの種類は単純に ​`UNAUTHORIZED`​ ではなく ​`HTTP:UNAUTHORIZED`​ です。エラーの種類が名前空間と識別子の両方で構成されるため、ドメインからその種類を判別することができます (​`HTTP:NOT_FOUND`​、​`FILE:NOT_FOUND`​ など)。名前空間はそのコネクタによって定義されますが、コアランタイムエラーの名前空間は暗黙的なため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同一とみなされます。 エラーの種類のもう一つの重要な特徴は、親種別のある可能性があることです。たとえば、​`HTTP:UNAUTHORIZED`​ は親として ​`MULE:CLIENT_SECURITY`​ を持ち、さらにその親として ​`MULE:SECURITY`​ があります。このため、エラーの種類がグローバルなエラーの細部であることがわかります。つまり、広範なセキュリティ問題の 1 つにクライアントセキュリティエラーがあり、その 1 つに HTTP 未承認エラーがあるということです。 こうした階層により、大まかなルーティングが可能になります。たとえば、​`MULE:SECURITY`​ のハンドラーが HTTP 未承認エラーと OAuth エラーの両方をキャッチします。以下は、コアランタイムがどのような階層になっているかを示しています。 ![ANY や CRITICAL などのカテゴリが表示されているエラー種別の階層](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-hierarchy.png) どのエラーも一般的なエラーと ​`CRITICAL`​ エラーのどちらかに該当しますが、後者は極めて深刻なため処理することができません。一般的な階層の最上位が ​`ANY`​ で、その下位の全種類がこれに該当します。 ここで重要な点は、失敗の明確な理由が見つからない場合に使用される ​`UNKNOWN`​ という種類に注意することです。このエラーは ​`ANY`​ 種類経由でしか処理できないため、今後既存のアプリケーションの動作を変更することなく、不明なエラーを特定できるようになります。 コネクタについては、各コネクタがそのコアランタイムエラーを考慮して各自のエラー種類階層を定義しますが、​`CONNECTIVITY`​ と ​`RETRY_EXHAUSTED`​ の 2 種類はすべてのコネクタに共通するため、常に存在します。 ## [](#error_handlers)エラーハンドラー Mule 4 では、​`error-handler`​ コンポーネントを導入してエラー処理が再設計されています。このコンポーネントには任意の数の内部ハンドラーを含めることができ、最初に一致したハンドラーにエラーをルーティングできます。これらのハンドラーに該当するのが ​`on-error-continue`​ や ​`on-error-propagate`​ で、どちらもエラーの種類 (あるいは数種類のエラー) または式 (高度なユースケースの場合) との照合をサポートしています。こうしたハンドラーは、Mule 3 の選択例外 (​`choice-exception-strategy`​)、キャッチ例外 (​`catch-exception-strategy`​)、ロールバック例外 (​`rollback-exception-strategy`​) 戦略によく似ていますが、はるかにシンプルで一貫しています。 Mule 4 でエラーが生じると、エラーハンドラーが実行され、最初に一致したハンドラーにエラーがルーティングされます。この時点でエラーが検査されるため、使用するコンポーネント (Flow または Try スコープなど) に応じたハンドラーを実行して処理できます。 - `on-error-continue`​ が実行され、実行の結果がそのオーナーの結果として (オーナーが実行を正常に完了したかのように) 使用されます。 また、この時点のすべてのトランザクションがコミットされます。 - `on-error-propagate`​ はすべてのトランザクションをロールバックしてから実行され、その結果が使用されて既存のエラーが再度スローされます。つまり、そのオーナーは「失敗した」とみなされます。 HTTP リスナーが、HTTP 要求を実行する別のフローへの Flow Reference コンポーネントをトリガーする、次のアプリケーションについて考えてみます。メッセージの受信時にすべてうまくいけば (下図の 1)、参照がトリガーされ (2)、要求が実行されて (3)、応答を正常に受信します (HTTP 状況コード 200) (4)。 ![NOT\_FOUND が含まれる HTTP エラーのエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handling-example-1.png) エラーハンドラーの設定が ​`inner-flow`​ であるため HTTP 要求に失敗し、​`HTTP:NOT_FOUND`​ エラーが表示された場合 (下図の 3)、エラーが伝搬され (4)、Flow Reference コンポーネントが失敗します (2)。ただし、​`primary-flow`​ によって ​`on-error-continue`​ を使用してエラーが処理されるため、含まれている Logger が実行され (5)、正常な応答 (HTTP 状況コード 200) が返されます (6)。 ![NOT\_FOUND が含まれる inner-flow の HTTP エラーのエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handling-example-2.png) 要求に失敗し、未承認エラーが表示された場合は (3)、​`on-error-continue`​ により ​`inner-flow`​ が処理を行い、ファイルから静的コンテンツを取得します (4)。そして、Flow Reference コンポーネントも正常に行われ (2)、正常な応答 (HTTP 状況コード 200) が返されます (5)。 ![UNAUTHORIZED が含まれる inner-flow の HTTP のエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handling-example-3.png) では、HTTP 要求で別のエラーが生じた場合はどうでしょうか? このフローには ​`NOT_FOUND`​ エラーと ​`UNAUTHORIZED`​ エラーのハンドラーしかありませんが、デフォルトで他のエラーも伝搬します。つまり、スローされたエラーに一致するハンドラーがなければ、エラーが再びスローされます。たとえば、要求に失敗し、「メソッドが許可されていません」というエラーが表示された場合 (3)、このエラーが伝搬され、Flow Reference コンポーネントが失敗し (2)、この伝搬により応答も失敗します (4)。 ![失敗応答になる HTTP のエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handling-example-4.png) 上記のシナリオを回避するためには、最後のハンドラーを ​`HTTP:UNAUTHORIZED`​ ではなく、​`ANY`​ と照合するようにします。以下は、​`HTTP`​ 要求で生じる可能性のある全エラーがどのように提示されるかを示しています。 ![On Error Continue の ANY などの種別が含まれる 「General (一般)」 項目](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handling-any.png) また、項目の場合は、 式を使用してエラーを照合することもできます。たとえば、エラーの処理時に Mule エラーを使用できるため、このエラーを使用してすべてのエラーを HTTP 名前空間と照合することができます。 ![HTTP エラーを処理する式が表示されている On Error Continue の 「General (一般)」 項目](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handling-expression.png) ## [](#try-スコープ)Try スコープ Mule 3 では概してエラーをフローレベルでしか処理できないため、エラーに対処するためにはフローにロジックを抽出する必要があります。Mule 4 では、フロー内で内部コンポーネントのエラーのみを処理する Try スコープが導入されました。このスコープは旧来の Transactional スコープの後継で、トランザクションもサポートします。 ![エラーの伝播と設定を行うコンポーネントが含まれる Try スコープが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handling-try.png) 前の例では、On Error Propagate コンポーネントがデータベース接続エラーを伝播するように設定されているため、​`try`​ が失敗して、フローのエラーハンドラーが実行されます。 On Error Continue コンポーネントは、他のすべてのエラーを処理するように設定されています。この場合、Try スコープの実行は正常に完了し、フローの実行が次のプロセッサーである HTTP Request 操作に引き継がれます。 ## [](#エラーのマッピング)エラーのマッピング Mule 4 では、デフォルトのエラーをカスタムエラーにマップできるようになりました。Try スコープは便利ですが、同一のコンポーネントがいくつかあり、それぞれのエラーを区別したい場合、これらのエラーに Try を使用するとアプリケーションがわかりづらくなることがあります。この場合は代わりに、各コンポーネントにエラーマッピングを追加することが考えられます。つまり、コンポーネントからのすべてまたは一定のエラーストリーミングが任意の別のエラーにマップされるようにします。たとえば、それぞれ HTTP 要求コンポーネントを使用する 2 つの API の結果を集約する場合、デフォルトでは API 1 と API 2 のエラーが同じため、API ごとに区別したいことがあります。 マッピングにより、エラーを適切なエラーハンドラーにルーティングすることでエラー処理をカスタマイズできます。次の例では、最初の Request 操作からエラーハンドラー ​`APP:API_1`​ にエラーをルーティングし、2 つ目の Request 操作から ​`APP:API_2`​ にエラーをルーティングしています。この例では、API がダウンしたときに異なる処理ポリシーを適用するために ​`HTTP:INTERNAL_SERVER_ERROR`​ を各エラーハンドラーにマッピングしています。片方のマッピングは、最初の API から来たエラーを伝播します。他方のマッピングは、2 つ目の API から来たエラーを処理します。 ![HTTP 内部サーバーエラーのエラーマッピング設定が表示されている設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handling-mappings.png) ## [](#関連情報)関連情報 - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept) # Mule 4 の概要: コネクタ システムに接続する場合、Mule 3 にはトランスポートとコネクタという 2 つの手段がありました。トランスポートは、インバウンドおよびアウトバウンドエンドポイントという概念を用いてデータを送信します。コネクタは、操作という概念を用いてシステムを呼び出します (​``​、​``​ など)。 MuleSoft は、Mule 3 で一部のトランスポートを新しい HTTP Connector や Database Connector に切り替え始めました。Mule 4 でこの変更が完了し、すべての接続性をコネクタとして構築するアプローチが完全に標準化されています。この変更により、コネクタの一貫性と使いやすさが向上し、コネクタの機能が強化されます。 ## [](#コアコネクタやコアモジュールの独立したリリースサイクル)コアコネクタやコアモジュールの独立したリリースサイクル もう一つの大きな違いは、コネクタの配布およびリリース方法です。Mule 3 では、Mule Runtime の配布に多数のコネクタやトランスポート (File、FTP、SFTP、Database、JMS、XML、Validations など) が付属していました。こうしたコネクタの修正や機能拡張は、Mule Runtime の次回のリリースまで待たなければなりませんでした。その一方で、他のコネクタは (Salesforce、Workday、ServiceNow、SAP など、主として SaaS Connector)、独立して配布やリリースされていました。 Mule 4 では、最新のモデルを標準化しています。Mule 4 の配布にはコネクタやモジュールが 1 つも付属していません。代わりに、各アプリケーションに必要なモジュールが含まれています。こうしたアプローチには次のメリットがあります。 - どのコネクタにも独自のリリースサイクルがあるため、コアモジュール/コアコネクタでの迅速なイノベーションが可能になる。Mule Runtime の次のリリースまで待たなくても、新機能やバグ修正が手に入ります。 - 異なるアプリケーションで、同じモジュールの異なるバージョンを使用できる。このため、新しいリリースを簡単に採用でき、アップグレードが不要なアプリケーションを完全退行させる必要がありません。 - 一貫したアプローチが可能になる。 # Mule 4 の概要: コネクタ システムに接続する場合、Mule 3 にはトランスポートとコネクタという 2 つの手段がありました。トランスポートは、インバウンドおよびアウトバウンドエンドポイントという概念を用いてデータを送信します。コネクタは、操作という概念を用いてシステムを呼び出します (​``​、​``​ など)。 MuleSoft は、Mule 3 で一部のトランスポートを新しい HTTP Connector や Database Connector に切り替え始めました。Mule 4 でこの変更が完了し、すべての接続性をコネクタとして構築するアプローチが完全に標準化されています。この変更により、コネクタの一貫性と使いやすさが向上し、コネクタの機能が強化されます。 ## [](#コアコネクタやコアモジュールの独立したリリースサイクル)コアコネクタやコアモジュールの独立したリリースサイクル もう一つの大きな違いは、コネクタの配布およびリリース方法です。Mule 3 では、Mule Runtime の配布に多数のコネクタやトランスポート (File、FTP、SFTP、Database、JMS、XML、Validations など) が付属していました。こうしたコネクタの修正や機能拡張は、Mule Runtime の次回のリリースまで待たなければなりませんでした。その一方で、他のコネクタは (Salesforce、Workday、ServiceNow、SAP など、主として SaaS Connector)、独立して配布やリリースされていました。 Mule 4 では、最新のモデルを標準化しています。Mule 4 の配布にはコネクタやモジュールが 1 つも付属していません。代わりに、各アプリケーションに必要なモジュールが含まれています。こうしたアプローチには次のメリットがあります。 - どのコネクタにも独自のリリースサイクルがあるため、コアモジュール/コアコネクタでの迅速なイノベーションが可能になる。Mule Runtime の次のリリースまで待たなくても、新機能やバグ修正が手に入ります。 - 異なるアプリケーションで、同じモジュールの異なるバージョンを使用できる。このため、新しいリリースを簡単に採用でき、アップグレードが不要なアプリケーションを完全退行させる必要がありません。 - 一貫したアプローチが可能になる。 # Mule 4 の概要: コネクタ システムに接続する場合、Mule 3 にはトランスポートとコネクタという 2 つの手段がありました。トランスポートは、インバウンドおよびアウトバウンドエンドポイントという概念を用いてデータを送信します。コネクタは、操作という概念を用いてシステムを呼び出します (​``​、​``​ など)。 MuleSoft は、Mule 3 で一部のトランスポートを新しい HTTP Connector や Database Connector に切り替え始めました。Mule 4 でこの変更が完了し、すべての接続性をコネクタとして構築するアプローチが完全に標準化されています。この変更により、コネクタの一貫性と使いやすさが向上し、コネクタの機能が強化されます。 ## [](#コアコネクタやコアモジュールの独立したリリースサイクル)コアコネクタやコアモジュールの独立したリリースサイクル もう一つの大きな違いは、コネクタの配布およびリリース方法です。Mule 3 では、Mule Runtime の配布に多数のコネクタやトランスポート (File、FTP、SFTP、Database、JMS、XML、Validations など) が付属していました。こうしたコネクタの修正や機能拡張は、Mule Runtime の次回のリリースまで待たなければなりませんでした。その一方で、他のコネクタは (Salesforce、Workday、ServiceNow、SAP など、主として SaaS Connector)、独立して配布やリリースされていました。 Mule 4 では、最新のモデルを標準化しています。Mule 4 の配布にはコネクタやモジュールが 1 つも付属していません。代わりに、各アプリケーションに必要なモジュールが含まれています。こうしたアプローチには次のメリットがあります。 - どのコネクタにも独自のリリースサイクルがあるため、コアモジュール/コアコネクタでの迅速なイノベーションが可能になる。Mule Runtime の次のリリースまで待たなくても、新機能やバグ修正が手に入ります。 - 異なるアプリケーションで、同じモジュールの異なるバージョンを使用できる。このため、新しいリリースを簡単に採用でき、アップグレードが不要なアプリケーションを完全退行させる必要がありません。 - 一貫したアプローチが可能になる。 # Mule 4 の概要: コネクタ システムに接続する場合、Mule 3 にはトランスポートとコネクタという 2 つの手段がありました。トランスポートは、インバウンドおよびアウトバウンドエンドポイントという概念を用いてデータを送信します。コネクタは、操作という概念を用いてシステムを呼び出します (​``​、​``​ など)。 MuleSoft は、Mule 3 で一部のトランスポートを新しい HTTP Connector や Database Connector に切り替え始めました。Mule 4 でこの変更が完了し、すべての接続性をコネクタとして構築するアプローチが完全に標準化されています。この変更により、コネクタの一貫性と使いやすさが向上し、コネクタの機能が強化されます。 ## [](#コアコネクタやコアモジュールの独立したリリースサイクル)コアコネクタやコアモジュールの独立したリリースサイクル もう一つの大きな違いは、コネクタの配布およびリリース方法です。Mule 3 では、Mule Runtime の配布に多数のコネクタやトランスポート (File、FTP、SFTP、Database、JMS、XML、Validations など) が付属していました。こうしたコネクタの修正や機能拡張は、Mule Runtime の次回のリリースまで待たなければなりませんでした。その一方で、他のコネクタは (Salesforce、Workday、ServiceNow、SAP など、主として SaaS Connector)、独立して配布やリリースされていました。 Mule 4 では、最新のモデルを標準化しています。Mule 4 の配布にはコネクタやモジュールが 1 つも付属していません。代わりに、各アプリケーションに必要なモジュールが含まれています。こうしたアプローチには次のメリットがあります。 - どのコネクタにも独自のリリースサイクルがあるため、コアモジュール/コアコネクタでの迅速なイノベーションが可能になる。Mule Runtime の次のリリースまで待たなくても、新機能やバグ修正が手に入ります。 - 異なるアプリケーションで、同じモジュールの異なるバージョンを使用できる。このため、新しいリリースを簡単に採用でき、アップグレードが不要なアプリケーションを完全退行させる必要がありません。 - 一貫したアプローチが可能になる。 # Mule 4 の概要: コネクタ システムに接続する場合、Mule 3 にはトランスポートとコネクタという 2 つの手段がありました。トランスポートは、インバウンドおよびアウトバウンドエンドポイントという概念を用いてデータを送信します。コネクタは、操作という概念を用いてシステムを呼び出します (​``​、​``​ など)。 MuleSoft は、Mule 3 で一部のトランスポートを新しい HTTP Connector や Database Connector に切り替え始めました。Mule 4 でこの変更が完了し、すべての接続性をコネクタとして構築するアプローチが完全に標準化されています。この変更により、コネクタの一貫性と使いやすさが向上し、コネクタの機能が強化されます。 ## [](#コアコネクタやコアモジュールの独立したリリースサイクル)コアコネクタやコアモジュールの独立したリリースサイクル もう一つの大きな違いは、コネクタの配布およびリリース方法です。Mule 3 では、Mule Runtime の配布に多数のコネクタやトランスポート (File、FTP、SFTP、Database、JMS、XML、Validations など) が付属していました。こうしたコネクタの修正や機能拡張は、Mule Runtime の次回のリリースまで待たなければなりませんでした。その一方で、他のコネクタは (Salesforce、Workday、ServiceNow、SAP など、主として SaaS Connector)、独立して配布やリリースされていました。 Mule 4 では、最新のモデルを標準化しています。Mule 4 の配布にはコネクタやモジュールが 1 つも付属していません。代わりに、各アプリケーションに必要なモジュールが含まれています。こうしたアプローチには次のメリットがあります。 - どのコネクタにも独自のリリースサイクルがあるため、コアモジュール/コアコネクタでの迅速なイノベーションが可能になる。Mule Runtime の次のリリースまで待たなくても、新機能やバグ修正が手に入ります。 - 異なるアプリケーションで、同じモジュールの異なるバージョンを使用できる。このため、新しいリリースを簡単に採用でき、アップグレードが不要なアプリケーションを完全退行させる必要がありません。 - 一貫したアプローチが可能になる。 # Mule 4 の概要: コネクタ システムに接続する場合、Mule 3 にはトランスポートとコネクタという 2 つの手段がありました。トランスポートは、インバウンドおよびアウトバウンドエンドポイントという概念を用いてデータを送信します。コネクタは、操作という概念を用いてシステムを呼び出します (​``​、​``​ など)。 MuleSoft は、Mule 3 で一部のトランスポートを新しい HTTP Connector や Database Connector に切り替え始めました。Mule 4 でこの変更が完了し、すべての接続性をコネクタとして構築するアプローチが完全に標準化されています。この変更により、コネクタの一貫性と使いやすさが向上し、コネクタの機能が強化されます。 ## [](#コアコネクタやコアモジュールの独立したリリースサイクル)コアコネクタやコアモジュールの独立したリリースサイクル もう一つの大きな違いは、コネクタの配布およびリリース方法です。Mule 3 では、Mule Runtime の配布に多数のコネクタやトランスポート (File、FTP、SFTP、Database、JMS、XML、Validations など) が付属していました。こうしたコネクタの修正や機能拡張は、Mule Runtime の次回のリリースまで待たなければなりませんでした。その一方で、他のコネクタは (Salesforce、Workday、ServiceNow、SAP など、主として SaaS Connector)、独立して配布やリリースされていました。 Mule 4 では、最新のモデルを標準化しています。Mule 4 の配布にはコネクタやモジュールが 1 つも付属していません。代わりに、各アプリケーションに必要なモジュールが含まれています。こうしたアプローチには次のメリットがあります。 - どのコネクタにも独自のリリースサイクルがあるため、コアモジュール/コアコネクタでの迅速なイノベーションが可能になる。Mule Runtime の次のリリースまで待たなくても、新機能やバグ修正が手に入ります。 - 異なるアプリケーションで、同じモジュールの異なるバージョンを使用できる。このため、新しいリリースを簡単に採用でき、アップグレードが不要なアプリケーションを完全退行させる必要がありません。 - 一貫したアプローチが可能になる。 # Mule 4 の概要: 変換とストリーミング Mule 4 ではデータについての考え方が根本的に Mule 3 とは異なります。Mule 3 では多くの場合、基本的な Java データ型、InputStream の管理方法、ペイロードがメモリ量を上回っていないか、MEL でアクセス可能にするためにデータを Java オブジェクトに変換する方法を認識している必要があります。 Mule 4 では、次のベストプラクティスが推奨されます。 - Java データ型への不要な変換を回避し、データを直接操作する。 - ランタイムにストリーミングを処理させる。 - カスタム Java コードとの直接的なインテグレーションを実行している場合を除き、バイナリデータ型を ​`String`​、​`byte[]`​、​`InputStream`​ に変換しない。 ## [](#透過的なストリーミング)透過的なストリーミング [「Mule 4 の概要: DataWeave 式言語」](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-expressions)​で、DataWeave を使用してデータを直接操作する方法を説明しました。各種のデータ形式にアクセスできるこの機能を Mule 4 のストリーミング機能と組み合わせれば、データを最初に Java オブジェクトに変換する必要がなくなります。この改善によって次のことが可能になるため、ランタイムでのデータの操作が大幅に簡素化されます。 - DataWeave 式言語を使用してデータを数回読み取ったり、ランダムにアクセスすることができ、副次的影響がない。 - データを最初にメモリにキャッシュしなくても、複数の場所に送信できる。 - メモリ量を超えるデータに透過的にアクセスできる。 Mule 4 でのストリーミングのしくみについての詳細は、​[「Mule 4.0 でのストリーミングについて」](https://docs.mulesoft.com/jp/mule-runtime/4.3/streaming-about)​を参照してください。 ## [](#データ型とオブジェクトから-stringbyteinputstream-へのトランスフォーマー)データ型とオブジェクトから String/Byte/InputStream へのトランスフォーマー Mule でデータストリームが自動的に管理されるようになったことため、データに簡単にアクセスできます。そのデータ型の基本的な Java 表現が ​`byte[]`​、​`InputStream`​、​`String`​ なのか、それとも他の形式なのかを気にする必要がありません。 Mule 3 アプリケーションで多くみられたパターンは、データをログに記録したり、いずれかのトランスポート経由で送信したりするために、ユーザーがデータを文字列に変換するというものです。ストリームを 2 回コンシュームすることができなかったためこの処理が必要でした。つまり、トランスフォーマーが必要でした。 ```xml ``` Mule 4 では、基になるデータ型やストリームのコンシューム回数を気にすることなく、データを簡単に記録や送信することができます。ペイロードを ​`InputStream`​ ではなく、単なるバイナリデータと考えます。また、コンテンツタイプがわかっている場合は、そのまま JSON、XML、あるいはそのコンテンツタイプに対応するデータ型と考えることができます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.3/streaming-about) # Mule 4 の概要: 変換とストリーミング Mule 4 ではデータについての考え方が根本的に Mule 3 とは異なります。Mule 3 では多くの場合、基本的な Java データ型、InputStream の管理方法、ペイロードがメモリ量を上回っていないか、MEL でアクセス可能にするためにデータを Java オブジェクトに変換する方法を認識している必要があります。 Mule 4 では、次のベストプラクティスが推奨されます。 - Java データ型への不要な変換を回避し、データを直接操作する。 - ランタイムにストリーミングを処理させる。 - カスタム Java コードとの直接的なインテグレーションを実行している場合を除き、バイナリデータ型を ​`String`​、​`byte[]`​、​`InputStream`​ に変換しない。 ## [](#透過的なストリーミング)透過的なストリーミング [「Mule 4 の概要: DataWeave 式言語」](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-expressions)​で、DataWeave を使用してデータを直接操作する方法を説明しました。各種のデータ形式にアクセスできるこの機能を Mule 4 のストリーミング機能と組み合わせれば、データを最初に Java オブジェクトに変換する必要がなくなります。この改善によって次のことが可能になるため、ランタイムでのデータの操作が大幅に簡素化されます。 - DataWeave 式言語を使用してデータを数回読み取ったり、ランダムにアクセスすることができ、副次的影響がない。 - データを最初にメモリにキャッシュしなくても、複数の場所に送信できる。 - メモリ量を超えるデータに透過的にアクセスできる。 Mule 4 でのストリーミングのしくみについての詳細は、​[「Mule 4.0 でのストリーミングについて」](https://docs.mulesoft.com/jp/mule-runtime/4.4/streaming-about)​を参照してください。 ## [](#データ型とオブジェクトから-stringbyteinputstream-へのトランスフォーマー)データ型とオブジェクトから String/Byte/InputStream へのトランスフォーマー Mule でデータストリームが自動的に管理されるようになったことため、データに簡単にアクセスできます。そのデータ型の基本的な Java 表現が ​`byte[]`​、​`InputStream`​、​`String`​ なのか、それとも他の形式なのかを気にする必要がありません。 Mule 3 アプリケーションで多くみられたパターンは、データをログに記録したり、いずれかのトランスポート経由で送信したりするために、ユーザーがデータを文字列に変換するというものです。ストリームを 2 回コンシュームすることができなかったためこの処理が必要でした。つまり、トランスフォーマーが必要でした。 ```xml ``` Mule 4 では、基になるデータ型やストリームのコンシューム回数を気にすることなく、データを簡単に記録や送信することができます。ペイロードを ​`InputStream`​ ではなく、単なるバイナリデータと考えます。また、コンテンツタイプがわかっている場合は、そのまま JSON、XML、あるいはそのコンテンツタイプに対応するデータ型と考えることができます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.4/streaming-about) # Mule 4 の概要: 変換とストリーミング Mule 4 ではデータについての考え方が根本的に Mule 3 とは異なります。Mule 3 では多くの場合、基本的な Java データ型、InputStream の管理方法、ペイロードがメモリ量を上回っていないか、MEL でアクセス可能にするためにデータを Java オブジェクトに変換する方法を認識している必要があります。 Mule 4 では、次のベストプラクティスが推奨されます。 - Java データ型への不要な変換を回避し、データを直接操作する。 - ランタイムにストリーミングを処理させる。 - カスタム Java コードとの直接的なインテグレーションを実行している場合を除き、バイナリデータ型を ​`String`​、​`byte[]`​、​`InputStream`​ に変換しない。 ## [](#透過的なストリーミング)透過的なストリーミング [「Mule 4 の概要: DataWeave 式言語」](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-expressions)​で、DataWeave を使用してデータを直接操作する方法を説明しました。各種のデータ形式にアクセスできるこの機能を Mule 4 のストリーミング機能と組み合わせれば、データを最初に Java オブジェクトに変換する必要がなくなります。この改善によって次のことが可能になるため、ランタイムでのデータの操作が大幅に簡素化されます。 - DataWeave 式言語を使用してデータを数回読み取ったり、ランダムにアクセスすることができ、副次的影響がない。 - データを最初にメモリにキャッシュしなくても、複数の場所に送信できる。 - メモリ量を超えるデータに透過的にアクセスできる。 Mule 4 でのストリーミングのしくみについての詳細は、​[「Mule 4.0 でのストリーミングについて」](https://docs.mulesoft.com/jp/mule-runtime/4.5/streaming-about)​を参照してください。 ## [](#データ型とオブジェクトから-stringbyteinputstream-へのトランスフォーマー)データ型とオブジェクトから String/Byte/InputStream へのトランスフォーマー Mule でデータストリームが自動的に管理されるようになったことため、データに簡単にアクセスできます。そのデータ型の基本的な Java 表現が ​`byte[]`​、​`InputStream`​、​`String`​ なのか、それとも他の形式なのかを気にする必要がありません。 Mule 3 アプリケーションで多くみられたパターンは、データをログに記録したり、いずれかのトランスポート経由で送信したりするために、ユーザーがデータを文字列に変換するというものです。ストリームを 2 回コンシュームすることができなかったためこの処理が必要でした。つまり、トランスフォーマーが必要でした。 ```xml ``` Mule 4 では、基になるデータ型やストリームのコンシューム回数を気にすることなく、データを簡単に記録や送信することができます。ペイロードを ​`InputStream`​ ではなく、単なるバイナリデータと考えます。また、コンテンツタイプがわかっている場合は、そのまま JSON、XML、あるいはそのコンテンツタイプに対応するデータ型と考えることができます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.5/streaming-about) # Mule 4 の概要: 変換とストリーミング Mule 4 ではデータについての考え方が根本的に Mule 3 とは異なります。Mule 3 では多くの場合、基本的な Java データ型、InputStream の管理方法、ペイロードがメモリ量を上回っていないか、MEL でアクセス可能にするためにデータを Java オブジェクトに変換する方法を認識している必要があります。 Mule 4 では、次のベストプラクティスが推奨されます。 - Java データ型への不要な変換を回避し、データを直接操作する。 - ランタイムにストリーミングを処理させる。 - カスタム Java コードとの直接的なインテグレーションを実行している場合を除き、バイナリデータ型を ​`String`​、​`byte[]`​、​`InputStream`​ に変換しない。 ## [](#透過的なストリーミング)透過的なストリーミング [「Mule 4 の概要: DataWeave 式言語」](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-expressions)​で、DataWeave を使用してデータを直接操作する方法を説明しました。各種のデータ形式にアクセスできるこの機能を Mule 4 のストリーミング機能と組み合わせれば、データを最初に Java オブジェクトに変換する必要がなくなります。この改善によって次のことが可能になるため、ランタイムでのデータの操作が大幅に簡素化されます。 - DataWeave 式言語を使用してデータを数回読み取ったり、ランダムにアクセスすることができ、副次的影響がない。 - データを最初にメモリにキャッシュしなくても、複数の場所に送信できる。 - メモリ量を超えるデータに透過的にアクセスできる。 Mule 4 でのストリーミングのしくみについての詳細は、​[「Mule 4.0 でのストリーミングについて」](https://docs.mulesoft.com/jp/mule-runtime/4.6/streaming-about)​を参照してください。 ## [](#データ型とオブジェクトから-stringbyteinputstream-へのトランスフォーマー)データ型とオブジェクトから String/Byte/InputStream へのトランスフォーマー Mule でデータストリームが自動的に管理されるようになったことため、データに簡単にアクセスできます。そのデータ型の基本的な Java 表現が ​`byte[]`​、​`InputStream`​、​`String`​ なのか、それとも他の形式なのかを気にする必要がありません。 Mule 3 アプリケーションで多くみられたパターンは、データをログに記録したり、いずれかのトランスポート経由で送信したりするために、ユーザーがデータを文字列に変換するというものです。ストリームを 2 回コンシュームすることができなかったためこの処理が必要でした。つまり、トランスフォーマーが必要でした。 ```xml ``` Mule 4 では、基になるデータ型やストリームのコンシューム回数を気にすることなく、データを簡単に記録や送信することができます。ペイロードを ​`InputStream`​ ではなく、単なるバイナリデータと考えます。また、コンテンツタイプがわかっている場合は、そのまま JSON、XML、あるいはそのコンテンツタイプに対応するデータ型と考えることができます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.6/streaming-about) # Mule 4 の概要: 変換とストリーミング Mule 4 ではデータについての考え方が根本的に Mule 3 とは異なります。Mule 3 では多くの場合、基本的な Java データ型、InputStream の管理方法、ペイロードがメモリ量を上回っていないか、MEL でアクセス可能にするためにデータを Java オブジェクトに変換する方法を認識している必要があります。 Mule 4 では、次のベストプラクティスが推奨されます。 - Java データ型への不要な変換を回避し、データを直接操作する。 - ランタイムにストリーミングを処理させる。 - カスタム Java コードとの直接的なインテグレーションを実行している場合を除き、バイナリデータ型を ​`String`​、​`byte[]`​、​`InputStream`​ に変換しない。 ## [](#透過的なストリーミング)透過的なストリーミング [「Mule 4 の概要: DataWeave 式言語」](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-expressions)​で、DataWeave を使用してデータを直接操作する方法を説明しました。各種のデータ形式にアクセスできるこの機能を Mule 4 のストリーミング機能と組み合わせれば、データを最初に Java オブジェクトに変換する必要がなくなります。この改善によって次のことが可能になるため、ランタイムでのデータの操作が大幅に簡素化されます。 - DataWeave 式言語を使用してデータを数回読み取ったり、ランダムにアクセスすることができ、副次的影響がない。 - データを最初にメモリにキャッシュしなくても、複数の場所に送信できる。 - メモリ量を超えるデータに透過的にアクセスできる。 Mule 4 でのストリーミングのしくみについての詳細は、​[「Mule 4.0 でのストリーミングについて」](https://docs.mulesoft.com/jp/mule-runtime/4.7/streaming-about)​を参照してください。 ## [](#データ型とオブジェクトから-stringbyteinputstream-へのトランスフォーマー)データ型とオブジェクトから String/Byte/InputStream へのトランスフォーマー Mule でデータストリームが自動的に管理されるようになったことため、データに簡単にアクセスできます。そのデータ型の基本的な Java 表現が ​`byte[]`​、​`InputStream`​、​`String`​ なのか、それとも他の形式なのかを気にする必要がありません。 Mule 3 アプリケーションで多くみられたパターンは、データをログに記録したり、いずれかのトランスポート経由で送信したりするために、ユーザーがデータを文字列に変換するというものです。ストリームを 2 回コンシュームすることができなかったためこの処理が必要でした。つまり、トランスフォーマーが必要でした。 ```xml ``` Mule 4 では、基になるデータ型やストリームのコンシューム回数を気にすることなく、データを簡単に記録や送信することができます。ペイロードを ​`InputStream`​ ではなく、単なるバイナリデータと考えます。また、コンテンツタイプがわかっている場合は、そのまま JSON、XML、あるいはそのコンテンツタイプに対応するデータ型と考えることができます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.7/streaming-about) # Mule 4 の概要: 変換とストリーミング Mule 4 ではデータについての考え方が根本的に Mule 3 とは異なります。Mule 3 では多くの場合、基本的な Java データ型、InputStream の管理方法、ペイロードがメモリ量を上回っていないか、MEL でアクセス可能にするためにデータを Java オブジェクトに変換する方法を認識している必要があります。 Mule 4 では、次のベストプラクティスが推奨されます。 - Java データ型への不要な変換を回避し、データを直接操作する。 - ランタイムにストリーミングを処理させる。 - カスタム Java コードとの直接的なインテグレーションを実行している場合を除き、バイナリデータ型を ​`String`​、​`byte[]`​、​`InputStream`​ に変換しない。 ## [](#透過的なストリーミング)透過的なストリーミング [「Mule 4 の概要: DataWeave 式言語」](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-expressions)​で、DataWeave を使用してデータを直接操作する方法を説明しました。各種のデータ形式にアクセスできるこの機能を Mule 4 のストリーミング機能と組み合わせれば、データを最初に Java オブジェクトに変換する必要がなくなります。この改善によって次のことが可能になるため、ランタイムでのデータの操作が大幅に簡素化されます。 - DataWeave 式言語を使用してデータを数回読み取ったり、ランダムにアクセスすることができ、副次的影響がない。 - データを最初にメモリにキャッシュしなくても、複数の場所に送信できる。 - メモリ量を超えるデータに透過的にアクセスできる。 Mule 4 でのストリーミングのしくみについての詳細は、​[「Mule 4.0 でのストリーミングについて」](https://docs.mulesoft.com/jp/mule-runtime/4.8/streaming-about)​を参照してください。 ## [](#データ型とオブジェクトから-stringbyteinputstream-へのトランスフォーマー)データ型とオブジェクトから String/Byte/InputStream へのトランスフォーマー Mule でデータストリームが自動的に管理されるようになったことため、データに簡単にアクセスできます。そのデータ型の基本的な Java 表現が ​`byte[]`​、​`InputStream`​、​`String`​ なのか、それとも他の形式なのかを気にする必要がありません。 Mule 3 アプリケーションで多くみられたパターンは、データをログに記録したり、いずれかのトランスポート経由で送信したりするために、ユーザーがデータを文字列に変換するというものです。ストリームを 2 回コンシュームすることができなかったためこの処理が必要でした。つまり、トランスフォーマーが必要でした。 ```xml ``` Mule 4 では、基になるデータ型やストリームのコンシューム回数を気にすることなく、データを簡単に記録や送信することができます。ペイロードを ​`InputStream`​ ではなく、単なるバイナリデータと考えます。また、コンテンツタイプがわかっている場合は、そのまま JSON、XML、あるいはそのコンテンツタイプに対応するデータ型と考えることができます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.8/streaming-about) # Mule 4 の概要: 変換とストリーミング Mule 4 ではデータについての考え方が根本的に Mule 3 とは異なります。Mule 3 では多くの場合、基本的な Java データ型、InputStream の管理方法、ペイロードがメモリ量を上回っていないか、MEL でアクセス可能にするためにデータを Java オブジェクトに変換する方法を認識している必要があります。 Mule 4 では、次のベストプラクティスが推奨されます。 - Java データ型への不要な変換を回避し、データを直接操作する。 - ランタイムにストリーミングを処理させる。 - カスタム Java コードとの直接的なインテグレーションを実行している場合を除き、バイナリデータ型を ​`String`​、​`byte[]`​、​`InputStream`​ に変換しない。 ## [](#透過的なストリーミング)透過的なストリーミング [「Mule 4 の概要: DataWeave 式言語」](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-expressions)​で、DataWeave を使用してデータを直接操作する方法を説明しました。各種のデータ形式にアクセスできるこの機能を Mule 4 のストリーミング機能と組み合わせれば、データを最初に Java オブジェクトに変換する必要がなくなります。この改善によって次のことが可能になるため、ランタイムでのデータの操作が大幅に簡素化されます。 - DataWeave 式言語を使用してデータを数回読み取ったり、ランダムにアクセスすることができ、副次的影響がない。 - データを最初にメモリにキャッシュしなくても、複数の場所に送信できる。 - メモリ量を超えるデータに透過的にアクセスできる。 Mule 4 でのストリーミングのしくみについての詳細は、​[「Mule 4.0 でのストリーミングについて」](https://docs.mulesoft.com/jp/mule-runtime/4.9/streaming-about)​を参照してください。 ## [](#データ型とオブジェクトから-stringbyteinputstream-へのトランスフォーマー)データ型とオブジェクトから String/Byte/InputStream へのトランスフォーマー Mule でデータストリームが自動的に管理されるようになったことため、データに簡単にアクセスできます。そのデータ型の基本的な Java 表現が ​`byte[]`​、​`InputStream`​、​`String`​ なのか、それとも他の形式なのかを気にする必要がありません。 Mule 3 アプリケーションで多くみられたパターンは、データをログに記録したり、いずれかのトランスポート経由で送信したりするために、ユーザーがデータを文字列に変換するというものです。ストリームを 2 回コンシュームすることができなかったためこの処理が必要でした。つまり、トランスフォーマーが必要でした。 ```xml ``` Mule 4 では、基になるデータ型やストリームのコンシューム回数を気にすることなく、データを簡単に記録や送信することができます。ペイロードを ​`InputStream`​ ではなく、単なるバイナリデータと考えます。また、コンテンツタイプがわかっている場合は、そのまま JSON、XML、あるいはそのコンテンツタイプに対応するデータ型と考えることができます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.9/streaming-about) # Mule 4 の概要: 実行エンジンのスレッドと同時実行 Mule 4 では実行エンジンが改良され、Mule アプリケーションを簡単に開発および拡張できるようになりました。根幹的なエンジンは、非ブロック型のリアクティブアーキテクチャに基づきます。このタスク指向の実行モデルでは、非ブロック IO コールを活用して、処理方式の不適切な設定に起因するパフォーマンスの問題を回避できます。 開発面では、いくつかの大きな変更が行われています。 - エクスチェンジパターンが廃止されました。どのコネクタも応答を受信します。メッセージを非同期処理する場合は、非同期コンポーネントを使用します。 - どのフローでも常に非ブロック処理方式が使用されるため、今後は処理方式を設定する必要がありません。 - すべてのフローを対象とする 1 つのグローバルスレッドプールがあります。詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.3/execution-engine)​を参照してください。 ## [](#controlling_concurrency)同時実行の制御 Mule 4 では、スレッド設定が同時実行管理から切り離されています。フロー上、または同時実行をサポートするコンポーネント上の同時実行を制御するには、​`maxConcurrency`​ 属性を使用して、そのコンポーネントが任意の時点で受信できる同時呼び出し数を設定します。 ```xml ``` ## [](#thread_pools_and_tuning)スレッドプールとアプリケーションの調整 Mule 4.3 には、UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、IO Intensive (IO 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 新しいスレッドモデルおよびアップグレード手順についての詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.3/execution-engine)​を参照してください。 ## [](#mule-4-24-1-からのアップグレード)Mule 4.2/4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x にアップグレードする場合は、次のアクションを実行します。 - 適用されるカスタムスレッド設定がない場合 (​`scheduler-pools.conf`​ ファイルを使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - 適用されるカスタムスレッド設定がある場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 # Mule 4 の概要: 実行エンジンのスレッドと同時実行 Mule 4 では実行エンジンが改良され、Mule アプリケーションを簡単に開発および拡張できるようになりました。根幹的なエンジンは、非ブロック型のリアクティブアーキテクチャに基づきます。このタスク指向の実行モデルでは、非ブロック IO コールを活用して、処理方式の不適切な設定に起因するパフォーマンスの問題を回避できます。 開発面では、いくつかの大きな変更が行われています。 - エクスチェンジパターンが廃止されました。どのコネクタも応答を受信します。メッセージを非同期処理する場合は、非同期コンポーネントを使用します。 - どのフローでも常に非ブロック処理方式が使用されるため、今後は処理方式を設定する必要がありません。 - すべてのフローを対象とする 1 つのグローバルスレッドプールがあります。詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.4/execution-engine)​を参照してください。 ## [](#controlling_concurrency)同時実行の制御 Mule 4 では、スレッド設定が同時実行管理から切り離されています。フロー上、または同時実行をサポートするコンポーネント上の同時実行を制御するには、​`maxConcurrency`​ 属性を使用して、そのコンポーネントが任意の時点で受信できる同時呼び出し数を設定します。 ```xml ``` ## [](#thread_pools_and_tuning)スレッドプールとアプリケーションの調整 Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、IO Intensive (IO 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 新しいスレッドモデルおよびアップグレード手順についての詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.4/execution-engine)​を参照してください。 ## [](#mule-4-24-1-からのアップグレード)Mule 4.2/4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - 適用されるカスタムスレッド設定がない場合 (​`scheduler-pools.conf`​ ファイルを使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - 適用されるカスタムスレッド設定がある場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 # Mule 4 の概要: 実行エンジンのスレッドと同時実行 Mule 4 では実行エンジンが改良され、Mule アプリケーションを簡単に開発および拡張できるようになりました。根幹的なエンジンは、非ブロック型のリアクティブアーキテクチャに基づきます。このタスク指向の実行モデルでは、非ブロック IO コールを活用して、処理方式の不適切な設定に起因するパフォーマンスの問題を回避できます。 開発面では、いくつかの大きな変更が行われています。 - エクスチェンジパターンが廃止されました。どのコネクタも応答を受信します。メッセージを非同期処理する場合は、非同期コンポーネントを使用します。 - どのフローでも常に非ブロック処理方式が使用されるため、今後は処理方式を設定する必要がありません。 - すべてのフローを対象とする 1 つのグローバルスレッドプールがあります。詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.5/execution-engine)​を参照してください。 ## [](#controlling_concurrency)同時実行の制御 Mule 4 では、スレッド設定が同時実行管理から切り離されています。フロー上、または同時実行をサポートするコンポーネント上の同時実行を制御するには、​`maxConcurrency`​ 属性を使用して、そのコンポーネントが任意の時点で受信できる同時呼び出し数を設定します。 ```xml ``` ## [](#thread_pools_and_tuning)スレッドプールとアプリケーションの調整 Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、IO Intensive (IO 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 新しいスレッドモデルおよびアップグレード手順についての詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.5/execution-engine)​を参照してください。 ## [](#mule-4-24-1-からのアップグレード)Mule 4.2/4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - 適用されるカスタムスレッド設定がない場合 (​`scheduler-pools.conf`​ ファイルを使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - 適用されるカスタムスレッド設定がある場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 # Mule 4 の概要: 実行エンジンのスレッドと同時実行 Mule 4 では実行エンジンが改良され、Mule アプリケーションを簡単に開発および拡張できるようになりました。根幹的なエンジンは、非ブロック型のリアクティブアーキテクチャに基づきます。このタスク指向の実行モデルでは、非ブロック IO コールを活用して、処理方式の不適切な設定に起因するパフォーマンスの問題を回避できます。 開発面では、いくつかの大きな変更が行われています。 - エクスチェンジパターンが廃止されました。どのコネクタも応答を受信します。メッセージを非同期処理する場合は、非同期コンポーネントを使用します。 - どのフローでも常に非ブロック処理方式が使用されるため、今後は処理方式を設定する必要がありません。 - すべてのフローを対象とする 1 つのグローバルスレッドプールがあります。詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.6/execution-engine)​を参照してください。 ## [](#controlling_concurrency)同時実行の制御 Mule 4 では、スレッド設定が同時実行管理から切り離されています。フロー上、または同時実行をサポートするコンポーネント上の同時実行を制御するには、​`maxConcurrency`​ 属性を使用して、そのコンポーネントが任意の時点で受信できる同時呼び出し数を設定します。 ```xml ``` ## [](#thread_pools_and_tuning)スレッドプールとアプリケーションの調整 Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、IO Intensive (IO 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 新しいスレッドモデルおよびアップグレード手順についての詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.6/execution-engine)​を参照してください。 ## [](#mule-4-24-1-からのアップグレード)Mule 4.2/4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - 適用されるカスタムスレッド設定がない場合 (​`scheduler-pools.conf`​ ファイルを使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - 適用されるカスタムスレッド設定がある場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 # Mule 4 の概要: 実行エンジンのスレッドと同時実行 Mule 4 では実行エンジンが改良され、Mule アプリケーションを簡単に開発および拡張できるようになりました。根幹的なエンジンは、非ブロック型のリアクティブアーキテクチャに基づきます。このタスク指向の実行モデルでは、非ブロック IO コールを活用して、処理方式の不適切な設定に起因するパフォーマンスの問題を回避できます。 開発面では、いくつかの大きな変更が行われています。 - エクスチェンジパターンが廃止されました。どのコネクタも応答を受信します。メッセージを非同期処理する場合は、非同期コンポーネントを使用します。 - どのフローでも常に非ブロック処理方式が使用されるため、今後は処理方式を設定する必要がありません。 - すべてのフローを対象とする 1 つのグローバルスレッドプールがあります。詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.7/execution-engine)​を参照してください。 ## [](#controlling_concurrency)同時実行の制御 Mule 4 では、スレッド設定が同時実行管理から切り離されています。フロー上、または同時実行をサポートするコンポーネント上の同時実行を制御するには、​`maxConcurrency`​ 属性を使用して、そのコンポーネントが任意の時点で受信できる同時呼び出し数を設定します。 ```xml ``` ## [](#thread_pools_and_tuning)スレッドプールとアプリケーションの調整 Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、IO Intensive (IO 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 新しいスレッドモデルおよびアップグレード手順についての詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.7/execution-engine)​を参照してください。 ## [](#mule-4-24-1-からのアップグレード)Mule 4.2/4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - 適用されるカスタムスレッド設定がない場合 (​`scheduler-pools.conf`​ ファイルを使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - 適用されるカスタムスレッド設定がある場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 # Mule 4 の概要: 実行エンジンのスレッドと同時実行 Mule 4 では実行エンジンが改良され、Mule アプリケーションを簡単に開発および拡張できるようになりました。根幹的なエンジンは、非ブロック型のリアクティブアーキテクチャに基づきます。このタスク指向の実行モデルでは、非ブロック IO コールを活用して、処理方式の不適切な設定に起因するパフォーマンスの問題を回避できます。 開発面では、いくつかの大きな変更が行われています。 - エクスチェンジパターンが廃止されました。どのコネクタも応答を受信します。メッセージを非同期処理する場合は、非同期コンポーネントを使用します。 - どのフローでも常に非ブロック処理方式が使用されるため、今後は処理方式を設定する必要がありません。 - すべてのフローを対象とする 1 つのグローバルスレッドプールがあります。詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.8/execution-engine)​を参照してください。 ## [](#controlling_concurrency)同時実行の制御 Mule 4 では、スレッド設定が同時実行管理から切り離されています。フロー上、または同時実行をサポートするコンポーネント上の同時実行を制御するには、​`maxConcurrency`​ 属性を使用して、そのコンポーネントが任意の時点で受信できる同時呼び出し数を設定します。 ```xml ``` ## [](#thread_pools_and_tuning)スレッドプールとアプリケーションの調整 Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、IO Intensive (IO 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 新しいスレッドモデルおよびアップグレード手順についての詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.8/execution-engine)​を参照してください。 ## [](#mule-4-24-1-からのアップグレード)Mule 4.2/4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - 適用されるカスタムスレッド設定がない場合 (​`scheduler-pools.conf`​ ファイルを使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - 適用されるカスタムスレッド設定がある場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 # Mule 4 の概要: 実行エンジンのスレッドと同時実行 Mule 4 では実行エンジンが改良され、Mule アプリケーションを簡単に開発および拡張できるようになりました。根幹的なエンジンは、非ブロック型のリアクティブアーキテクチャに基づきます。このタスク指向の実行モデルでは、非ブロック IO コールを活用して、処理方式の不適切な設定に起因するパフォーマンスの問題を回避できます。 開発面では、いくつかの大きな変更が行われています。 - エクスチェンジパターンが廃止されました。どのコネクタも応答を受信します。メッセージを非同期処理する場合は、非同期コンポーネントを使用します。 - どのフローでも常に非ブロック処理方式が使用されるため、今後は処理方式を設定する必要がありません。 - すべてのフローを対象とする 1 つのグローバルスレッドプールがあります。詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.9/execution-engine)​を参照してください。 ## [](#controlling_concurrency)同時実行の制御 Mule 4 では、スレッド設定が同時実行管理から切り離されています。フロー上、または同時実行をサポートするコンポーネント上の同時実行を制御するには、​`maxConcurrency`​ 属性を使用して、そのコンポーネントが任意の時点で受信できる同時呼び出し数を設定します。 ```xml ``` ## [](#thread_pools_and_tuning)スレッドプールとアプリケーションの調整 Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、IO Intensive (IO 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 新しいスレッドモデルおよびアップグレード手順についての詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.9/execution-engine)​を参照してください。 ## [](#mule-4-24-1-からのアップグレード)Mule 4.2/4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - 適用されるカスタムスレッド設定がない場合 (​`scheduler-pools.conf`​ ファイルを使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - 適用されるカスタムスレッド設定がある場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 # Mule 4 プログラミングモデル 以前のバージョンで使用されていたプログラミングのパラダイムが Mule 4 で変更されています。Mule 3 でフローの主なデータコンポーネントはメッセージです。ランタイムが提供するすべてのトランスポートは、主としてメッセージペイロードのコンテンツに関するものです。たとえば Mule 3 では、​`http:outbound-endpoint`​ がメッセージのペイロードコンテンツとして送信できるのは HTTP 本文のみです。この動作のために、ユーザーがペイロードに適切なコンテンツを設定するだけの目的で、エンドポイントの前に他のコンポーネントを追加していました。 Mule 3 ```xml ``` Mule 4 では、操作 (​`http:request`​) のすべての入力パラメーターをカスタマイズできるようになり、こうしたユースケースが容易になっています。 Mule 4 ```xml ``` 上記の例が示すとおり、​`http:request`​ 操作で本文が送信されるように ​`body`​ パラメーター内で本文を定義できるようになりました。このためフローに追加しなければならないコンポーネント数が減るだけでなく、可読性が向上し、​`http:request`​ 操作にコンテンツが必要であるというだけの理由でデータのコンテキストに影響を及ぼすことがなくなります。 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - 対象 (​`target`​): メッセージデータを保存する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ここで理解しておくべき重要な点は、対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化することです。通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 以下は、Read 操作で ​`readme.txt`​ のペイロードを ​`myVar`​ に保存します。 ```xml ``` デフォルトではペイロードが ​`myVar`​ 対象変数に保存されます。フルペイロード以上のものを保存する場合にすべきことは、対象値 (​`targetValue`​) を指定するだけです。 以下は、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合は ​`myVar`​ 変数にファイルのコンテンツだけでなく、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` 以下は、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{{'description' : payload}}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対する Bulk Insert 操作を使用してレコードを挿入しようと考えますが、この操作は成功メッセージを返して現在のペイロードを置換するため、レコードにアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-variables) # Mule 4 プログラミングモデル 以前のバージョンで使用されていたプログラミングのパラダイムが Mule 4 で変更されています。Mule 3 でフローの主なデータコンポーネントはメッセージです。ランタイムが提供するすべてのトランスポートは、主としてメッセージペイロードのコンテンツに関するものです。たとえば Mule 3 では、​`http:outbound-endpoint`​ がメッセージのペイロードコンテンツとして送信できるのは HTTP 本文のみです。この動作のために、ユーザーがペイロードに適切なコンテンツを設定するだけの目的で、エンドポイントの前に他のコンポーネントを追加していました。 Mule 3 ```xml ``` Mule 4 では、操作 (​`http:request`​) のすべての入力パラメーターをカスタマイズできるようになり、こうしたユースケースが容易になっています。 Mule 4 ```xml ``` 上記の例が示すとおり、​`http:request`​ 操作で本文が送信されるように ​`body`​ パラメーター内で本文を定義できるようになりました。このためフローに追加しなければならないコンポーネント数が減るだけでなく、可読性が向上し、​`http:request`​ 操作にコンテンツが必要であるというだけの理由でデータのコンテキストに影響を及ぼすことがなくなります。 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - 対象 (​`target`​): メッセージデータを保存する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ここで理解しておくべき重要な点は、対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化することです。通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 以下は、Read 操作で ​`readme.txt`​ のペイロードを ​`myVar`​ に保存します。 ```xml ``` デフォルトではペイロードが ​`myVar`​ 対象変数に保存されます。フルペイロード以上のものを保存する場合にすべきことは、対象値 (​`targetValue`​) を指定するだけです。 以下は、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合は ​`myVar`​ 変数にファイルのコンテンツだけでなく、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` 以下は、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{{'description' : payload}}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対する Bulk Insert 操作を使用してレコードを挿入しようと考えますが、この操作は成功メッセージを返して現在のペイロードを置換するため、レコードにアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-variables) # Mule 4 プログラミングモデル 以前のバージョンで使用されていたプログラミングのパラダイムが Mule 4 で変更されています。Mule 3 でフローの主なデータコンポーネントはメッセージです。ランタイムが提供するすべてのトランスポートは、主としてメッセージペイロードのコンテンツに関するものです。たとえば Mule 3 では、​`http:outbound-endpoint`​ がメッセージのペイロードコンテンツとして送信できるのは HTTP 本文のみです。この動作のために、ユーザーがペイロードに適切なコンテンツを設定するだけの目的で、エンドポイントの前に他のコンポーネントを追加していました。 Mule 3 ```xml ``` Mule 4 では、操作 (​`http:request`​) のすべての入力パラメーターをカスタマイズできるようになり、こうしたユースケースが容易になっています。 Mule 4 ```xml ``` 上記の例が示すとおり、​`http:request`​ 操作で本文が送信されるように ​`body`​ パラメーター内で本文を定義できるようになりました。このためフローに追加しなければならないコンポーネント数が減るだけでなく、可読性が向上し、​`http:request`​ 操作にコンテンツが必要であるというだけの理由でデータのコンテキストに影響を及ぼすことがなくなります。 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - 対象 (​`target`​): メッセージデータを保存する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ここで理解しておくべき重要な点は、対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化することです。通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 以下は、Read 操作で ​`readme.txt`​ のペイロードを ​`myVar`​ に保存します。 ```xml ``` デフォルトではペイロードが ​`myVar`​ 対象変数に保存されます。フルペイロード以上のものを保存する場合にすべきことは、対象値 (​`targetValue`​) を指定するだけです。 以下は、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合は ​`myVar`​ 変数にファイルの内容だけでなく、関連するすべてのメタデータも含まれます。 - ファイルの内容にアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` 以下は、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{{'description' : payload}}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]` そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]` そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日をキャプチャする対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]` ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対する Bulk Insert 操作を使用してレコードを挿入しようと考えますが、この操作は成功メッセージを返して現在のペイロードを置換するため、レコードにアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-variables) # Mule 4 プログラミングモデル 以前のバージョンで使用されていたプログラミングのパラダイムが Mule 4 で変更されています。Mule 3 でフローの主なデータコンポーネントはメッセージです。ランタイムが提供するすべてのトランスポートは、主としてメッセージペイロードのコンテンツに関するものです。たとえば Mule 3 では、​`http:outbound-endpoint`​ がメッセージのペイロードコンテンツとして送信できるのは HTTP 本文のみです。この動作のために、ユーザーがペイロードに適切なコンテンツを設定するだけの目的で、エンドポイントの前に他のコンポーネントを追加していました。 Mule 3 ```xml ``` Mule 4 では、操作 (​`http:request`​) のすべての入力パラメーターをカスタマイズできるようになり、こうしたユースケースが容易になっています。 Mule 4 ```xml ``` 上記の例が示すとおり、​`http:request`​ 操作で本文が送信されるように ​`body`​ パラメーター内で本文を定義できるようになりました。このためフローに追加しなければならないコンポーネント数が減るだけでなく、可読性が向上し、​`http:request`​ 操作にコンテンツが必要であるというだけの理由でデータのコンテキストに影響を及ぼすことがなくなります。 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - 対象 (​`target`​): メッセージデータを保存する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ここで理解しておくべき重要な点は、対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化することです。通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 以下は、Read 操作で ​`readme.txt`​ のペイロードを ​`myVar`​ に保存します。 ```xml ``` デフォルトではペイロードが ​`myVar`​ 対象変数に保存されます。フルペイロード以上のものを保存する場合にすべきことは、対象値 (​`targetValue`​) を指定するだけです。 以下は、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合は ​`myVar`​ 変数にファイルのコンテンツだけでなく、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` 以下は、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{{'description' : payload}}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対する Bulk Insert 操作を使用してレコードを挿入しようと考えますが、この操作は成功メッセージを返して現在のペイロードを置換するため、レコードにアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-variables) # Mule 4 プログラミングモデル 以前のバージョンで使用されていたプログラミングのパラダイムが Mule 4 で変更されています。Mule 3 でフローの主なデータコンポーネントはメッセージです。ランタイムが提供するすべてのトランスポートは、主としてメッセージペイロードのコンテンツに関するものです。たとえば Mule 3 では、​`http:outbound-endpoint`​ がメッセージのペイロードコンテンツとして送信できるのは HTTP 本文のみです。この動作のために、ユーザーがペイロードに適切なコンテンツを設定するだけの目的で、エンドポイントの前に他のコンポーネントを追加していました。 Mule 3 ```xml ``` Mule 4 では、操作 (​`http:request`​) のすべての入力パラメーターをカスタマイズできるようになり、こうしたユースケースが容易になっています。 Mule 4 ```xml ``` 上記の例が示すとおり、​`http:request`​ 操作で本文が送信されるように ​`body`​ パラメーター内で本文を定義できるようになりました。このためフローに追加しなければならないコンポーネント数が減るだけでなく、可読性が向上し、​`http:request`​ 操作にコンテンツが必要であるというだけの理由でデータのコンテキストに影響を及ぼすことがなくなります。 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - 対象 (​`target`​): メッセージデータを保存する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ここで理解しておくべき重要な点は、対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化することです。通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 以下は、Read 操作で ​`readme.txt`​ のペイロードを ​`myVar`​ に保存します。 ```xml ``` デフォルトではペイロードが ​`myVar`​ 対象変数に保存されます。フルペイロード以上のものを保存する場合にすべきことは、対象値 (​`targetValue`​) を指定するだけです。 以下は、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合は ​`myVar`​ 変数にファイルのコンテンツだけでなく、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` 以下は、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{{'description' : payload}}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対する Bulk Insert 操作を使用してレコードを挿入しようと考えますが、この操作は成功メッセージを返して現在のペイロードを置換するため、レコードにアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-variables) # Mule 4 プログラミングモデル 以前のバージョンで使用されていたプログラミングのパラダイムが Mule 4 で変更されています。Mule 3 でフローの主なデータコンポーネントはメッセージです。ランタイムが提供するすべてのトランスポートは、主としてメッセージペイロードのコンテンツに関するものです。たとえば Mule 3 では、​`http:outbound-endpoint`​ がメッセージのペイロードコンテンツとして送信できるのは HTTP 本文のみです。この動作のために、ユーザーがペイロードに適切なコンテンツを設定するだけの目的で、エンドポイントの前に他のコンポーネントを追加していました。 Mule 3 ```xml ``` Mule 4 では、操作 (​`http:request`​) のすべての入力パラメーターをカスタマイズできるようになり、こうしたユースケースが容易になっています。 Mule 4 ```xml ``` 上記の例が示すとおり、​`http:request`​ 操作で本文が送信されるように ​`body`​ パラメーター内で本文を定義できるようになりました。このためフローに追加しなければならないコンポーネント数が減るだけでなく、可読性が向上し、​`http:request`​ 操作にコンテンツが必要であるというだけの理由でデータのコンテキストに影響を及ぼすことがなくなります。 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - 対象 (​`target`​): メッセージデータを保存する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ここで理解しておくべき重要な点は、対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化することです。通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 以下は、Read 操作で ​`readme.txt`​ のペイロードを ​`myVar`​ に保存します。 ```xml ``` デフォルトではペイロードが ​`myVar`​ 対象変数に保存されます。フルペイロード以上のものを保存する場合にすべきことは、対象値 (​`targetValue`​) を指定するだけです。 以下は、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合は ​`myVar`​ 変数にファイルのコンテンツだけでなく、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` 以下は、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{{'description' : payload}}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対する Bulk Insert 操作を使用してレコードを挿入しようと考えますが、この操作は成功メッセージを返して現在のペイロードを置換するため、レコードにアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-variables) # Mule 4 プログラミングモデル 以前のバージョンで使用されていたプログラミングのパラダイムが Mule 4 で変更されています。Mule 3 でフローの主なデータコンポーネントはメッセージです。ランタイムが提供するすべてのトランスポートは、主としてメッセージペイロードのコンテンツに関するものです。たとえば Mule 3 では、​`http:outbound-endpoint`​ がメッセージのペイロードコンテンツとして送信できるのは HTTP 本文のみです。この動作のために、ユーザーがペイロードに適切なコンテンツを設定するだけの目的で、エンドポイントの前に他のコンポーネントを追加していました。 Mule 3 ```xml ``` Mule 4 では、操作 (​`http:request`​) のすべての入力パラメーターをカスタマイズできるようになり、こうしたユースケースが容易になっています。 Mule 4 ```xml ``` 上記の例が示すとおり、​`http:request`​ 操作で本文が送信されるように ​`body`​ パラメーター内で本文を定義できるようになりました。このためフローに追加しなければならないコンポーネント数が減るだけでなく、可読性が向上し、​`http:request`​ 操作にコンテンツが必要であるというだけの理由でデータのコンテキストに影響を及ぼすことがなくなります。 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - 対象 (​`target`​): メッセージデータを保存する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ここで理解しておくべき重要な点は、対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化することです。通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 以下は、Read 操作で ​`readme.txt`​ のペイロードを ​`myVar`​ に保存します。 ```xml ``` デフォルトではペイロードが ​`myVar`​ 対象変数に保存されます。フルペイロード以上のものを保存する場合にすべきことは、対象値 (​`targetValue`​) を指定するだけです。 以下は、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合は ​`myVar`​ 変数にファイルのコンテンツだけでなく、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` 以下は、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{{'description' : payload}}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対する Bulk Insert 操作を使用してレコードを挿入しようと考えますが、この操作は成功メッセージを返して現在のペイロードを置換するため、レコードにアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-variables) # Mule 4 への移行 Mule 3 アプリケーションを使用していて Mule 4 を利用できるようにするには、次のいずれかのプロセスで Mule 4 に移行します。 - コネクタ、モジュール、トランスポート、式、API ゲートウェイの Mule 4 への完全な手動移行。 完全な手動移行に関する指針については、​[「移行の準備」](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-prep)​と​[「手動移行プロセス」](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-process)​を参照してください。 - GitHub のオープンソースプロジェクトとして入手可能な Mule Migration Assistant (MMA) を使用した部分的な自動移行。 移行を支援する MMA の使用に関する指針については、 [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#understand-the-mma-migration-process)​ を参照してください。MMA を試してみて、完全な手動移行よりもこちらが適しているかどうか判断することをお勧めします。 [移行チュートリアル (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc)​ の手順に従って、サンプルアプリケーションで MMA を実行できます。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** MMA を使用する利点は、Mule 3 アプリケーションから Mule 4 への移行の一部を自動化できることです。MMA はアプリケーションを完全に移行するわけではありませんが、次の作業に大いに役立ちます。 - プロジェクト構造の移行。 - 記述子ファイル (​`pom.xml`​ や ​`mule-artifact.json`​ など) の自動作成。 - アプリケーションのコード適応の多くを自動実行。 - 自動的に移行できないコンポーネントとパターンを手動で移行する方法に関する指針の提供。 MMA ではこのような作業が支援されますが、完全に機能するアプリケーションは提供されません。いくつかの追加手順が必要です。その手順にはテストが含まれ、次の作業も含まれる可能性があります。 - サポートされていないコンポーネントの手動移行。 - MMA で自動的に変換できない複雑な MEL 式の DataWeave への手動移行。 - MMA で自動的に変換できない複雑な DataWeave 変換の手動移行。 - MMA を実行する前に、DataWeave 移行ツールを使用して DataMapper を事前に移行。 また、MMA では増分移行がサポートされていないことにも注意してください。 # Mule 4 への移行 Mule 3 アプリケーションを使用していて Mule 4 を利用できるようにするには、次のいずれかのプロセスで Mule 4 に移行します。 - コネクタ、モジュール、トランスポート、式、API ゲートウェイの Mule 4 への完全な手動移行。 完全な手動移行に関する指針については、​[「移行の準備」](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-prep)​と​[「手動移行プロセス」](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-process)​を参照してください。 - GitHub のオープンソースプロジェクトとして入手可能な Mule Migration Assistant (MMA) を使用した部分的な自動移行。 移行を支援する MMA の使用に関する指針については、 [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#understand-the-mma-migration-process)​ を参照してください。MMA を試してみて、完全な手動移行よりもこちらが適しているかどうか判断することをお勧めします。 [移行チュートリアル (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc)​ の手順に従って、サンプルアプリケーションで MMA を実行できます。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** MMA を使用する利点は、Mule 3 アプリケーションから Mule 4 への移行の一部を自動化できることです。MMA はアプリケーションを完全に移行するわけではありませんが、次の作業に大いに役立ちます。 - プロジェクト構造の移行。 - 記述子ファイル (​`pom.xml`​ や ​`mule-artifact.json`​ など) の自動作成。 - アプリケーションのコード適応の多くを自動実行。 - 自動的に移行できないコンポーネントとパターンを手動で移行する方法に関する指針の提供。 MMA ではこのような作業が支援されますが、完全に機能するアプリケーションは提供されません。いくつかの追加手順が必要です。その手順にはテストが含まれ、次の作業も含まれる可能性があります。 - サポートされていないコンポーネントの手動移行。 - MMA で自動的に変換できない複雑な MEL 式の DataWeave への手動移行。 - MMA で自動的に変換できない複雑な DataWeave 変換の手動移行。 - MMA を実行する前に、DataWeave 移行ツールを使用して DataMapper を事前に移行。 また、MMA では増分移行がサポートされていないことにも注意してください。 # Mule 4 への移行 Mule 3 アプリケーションを使用していて Mule 4 を利用できるようにするには、次のいずれかのプロセスで Mule 4 に移行します。 - コネクタ、モジュール、トランスポート、式、API ゲートウェイの Mule 4 への完全な手動移行。 完全な手動移行に関するガイダンスについては、​[「移行の準備」](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-prep)​と​[「手動移行プロセス」](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-process)​を参照してください。 - GitHub のオープンソースプロジェクトとして入手可能な Mule Migration Assistant (MMA) を使用した部分的な自動移行。 移行を支援する MMA の使用に関する指針については、 [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#understand-the-mma-migration-process)​ を参照してください。MMA を試してみて、完全な手動移行よりもこちらが適しているかどうか判断することをお勧めします。 [移行チュートリアル (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc)​ の手順に従って、サンプルアプリケーションで MMA を実行できます。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** MMA を使用する利点は、Mule 3 アプリケーションから Mule 4 への移行の一部を自動化できることです。MMA はアプリケーションを完全に移行するわけではありませんが、次の作業に大いに役立ちます。 - プロジェクト構造の移行。 - 記述子ファイル (​`pom.xml`​ や ​`mule-artifact.json`​ など) の自動作成。 - アプリケーションのコード適応の多くを自動実行。 - 自動的に移行できないコンポーネントとパターンを手動で移行する方法に関するガイダンスの提供。 MMA ではこのような作業が支援されますが、完全に機能するアプリケーションは提供されません。いくつかの追加手順が必要です。その手順にはテストが含まれ、次の作業も含まれる可能性があります。 - サポートされていないコンポーネントの手動移行。 - MMA で自動的に変換できない複雑な MEL 式の DataWeave への手動移行。 - MMA で自動的に変換できない複雑な DataWeave 変換の手動移行。 - MMA を実行する前に、DataWeave 移行ツールを使用して DataMapper を事前に移行。 また、MMA では増分移行がサポートされていないことにも注意してください。 # Mule 4 への移行 Mule 3 アプリケーションを使用していて Mule 4 を利用できるようにするには、次のいずれかのプロセスで Mule 4 に移行します。 - コネクタ、モジュール、トランスポート、式、API ゲートウェイの Mule 4 への完全な手動移行。 完全な手動移行に関する指針については、​[「移行の準備」](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-prep)​と​[「手動移行プロセス」](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-process)​を参照してください。 - GitHub のオープンソースプロジェクトとして入手可能な Mule Migration Assistant (MMA) を使用した部分的な自動移行。 移行を支援する MMA の使用に関する指針については、 [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#understand-the-mma-migration-process)​ を参照してください。MMA を試してみて、完全な手動移行よりもこちらが適しているかどうか判断することをお勧めします。 [移行チュートリアル (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc)​ の手順に従って、サンプルアプリケーションで MMA を実行できます。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** MMA を使用する利点は、Mule 3 アプリケーションから Mule 4 への移行の一部を自動化できることです。MMA はアプリケーションを完全に移行するわけではありませんが、次の作業に大いに役立ちます。 - プロジェクト構造の移行。 - 記述子ファイル (​`pom.xml`​ や ​`mule-artifact.json`​ など) の自動作成。 - アプリケーションのコード適応の多くを自動実行。 - 自動的に移行できないコンポーネントとパターンを手動で移行する方法に関する案内の提供。 MMA ではこのような作業が支援されますが、完全に機能するアプリケーションは提供されません。いくつかの追加手順が必要です。その手順にはテストが含まれ、次の作業も含まれる可能性があります。 - サポートされていないコンポーネントの手動移行。 - MMA で自動的に変換できない複雑な MEL 式の DataWeave への手動移行。 - MMA で自動的に変換できない複雑な DataWeave 変換の手動移行。 - MMA を実行する前に、DataWeave 移行ツールを使用して DataMapper を事前に移行。 また、MMA では増分移行がサポートされていないことにも注意してください。 # Mule 4 への移行 Mule 3 アプリケーションを使用していて Mule 4 を利用できるようにするには、次のいずれかのプロセスで Mule 4 に移行します。 - コネクタ、モジュール、トランスポート、式、API ゲートウェイの Mule 4 への完全な手動移行。 完全な手動移行に関する指針については、​[「移行の準備」](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-prep)​と​[「手動移行プロセス」](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-process)​を参照してください。 - GitHub のオープンソースプロジェクトとして入手可能な Mule Migration Assistant (MMA) を使用した部分的な自動移行。 移行を支援する MMA の使用に関する指針については、 [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#understand-the-mma-migration-process)​ を参照してください。MMA を試してみて、完全な手動移行よりもこちらが適しているかどうか判断することをお勧めします。 [移行チュートリアル (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc)​ の手順に従って、サンプルアプリケーションで MMA を実行できます。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** MMA を使用する利点は、Mule 3 アプリケーションから Mule 4 への移行の一部を自動化できることです。MMA はアプリケーションを完全に移行するわけではありませんが、次の作業に大いに役立ちます。 - プロジェクト構造の移行。 - 記述子ファイル (​`pom.xml`​ や ​`mule-artifact.json`​ など) の自動作成。 - アプリケーションのコード適応の多くを自動実行。 - 自動的に移行できないコンポーネントとパターンを手動で移行する方法に関する指針の提供。 MMA ではこのような作業が支援されますが、完全に機能するアプリケーションは提供されません。いくつかの追加手順が必要です。その手順にはテストが含まれ、次の作業も含まれる可能性があります。 - サポートされていないコンポーネントの手動移行。 - MMA で自動的に変換できない複雑な MEL 式の DataWeave への手動移行。 - MMA で自動的に変換できない複雑な DataWeave 変換の手動移行。 - MMA を実行する前に、DataWeave 移行ツールを使用して DataMapper を事前に移行。 また、MMA では増分移行がサポートされていないことにも注意してください。 # Mule 4 への移行 Mule 3 アプリケーションを使用していて Mule 4 を利用できるようにするには、次のいずれかのプロセスで Mule 4 に移行します。 - コネクタ、モジュール、トランスポート、式、API ゲートウェイの Mule 4 への完全な手動移行。 完全な手動移行に関する指針については、​[「移行の準備」](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-prep)​と​[「手動移行プロセス」](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-process)​を参照してください。 - GitHub のオープンソースプロジェクトとして入手可能な Mule Migration Assistant (MMA) を使用した部分的な自動移行。 移行を支援する MMA の使用に関する指針については、 [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#understand-the-mma-migration-process)​ を参照してください。MMA を試してみて、完全な手動移行よりもこちらが適しているかどうか判断することをお勧めします。 [移行チュートリアル (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc)​ の手順に従って、サンプルアプリケーションで MMA を実行できます。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** MMA を使用する利点は、Mule 3 アプリケーションから Mule 4 への移行の一部を自動化できることです。MMA はアプリケーションを完全に移行するわけではありませんが、次の作業に大いに役立ちます。 - プロジェクト構造の移行。 - 記述子ファイル (​`pom.xml`​ や ​`mule-artifact.json`​ など) の自動作成。 - アプリケーションのコード適応の多くを自動実行。 - 自動的に移行できないコンポーネントとパターンを手動で移行する方法に関する指針の提供。 MMA ではこのような作業が支援されますが、完全に機能するアプリケーションは提供されません。いくつかの追加手順が必要です。その手順にはテストが含まれ、次の作業も含まれる可能性があります。 - サポートされていないコンポーネントの手動移行。 - MMA で自動的に変換できない複雑な MEL 式の DataWeave への手動移行。 - MMA で自動的に変換できない複雑な DataWeave 変換の手動移行。 - MMA を実行する前に、DataWeave 移行ツールを使用して DataMapper を事前に移行。 また、MMA では増分移行がサポートされていないことにも注意してください。 # Mule 4 への移行 Mule 3 アプリケーションを使用していて Mule 4 を利用できるようにするには、次のいずれかのプロセスで Mule 4 に移行します。 - コネクタ、モジュール、トランスポート、式、API ゲートウェイの Mule 4 への完全な手動移行。 完全な手動移行に関する指針については、​[「移行の準備」](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-prep)​と​[「手動移行プロセス」](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-process)​を参照してください。 - GitHub のオープンソースプロジェクトとして入手可能な Mule Migration Assistant (MMA) を使用した部分的な自動移行。 移行を支援する MMA の使用に関する指針については、 [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#understand-the-mma-migration-process)​ を参照してください。MMA を試してみて、完全な手動移行よりもこちらが適しているかどうか判断することをお勧めします。 [移行チュートリアル (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/user-docs/migration-tutorial.adoc)​ の手順に従って、サンプルアプリケーションで MMA を実行できます。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** MMA を使用する利点は、Mule 3 アプリケーションから Mule 4 への移行の一部を自動化できることです。MMA はアプリケーションを完全に移行するわけではありませんが、次の作業に大いに役立ちます。 - プロジェクト構造の移行。 - 記述子ファイル (​`pom.xml`​ や ​`mule-artifact.json`​ など) の自動作成。 - アプリケーションのコード適応の多くを自動実行。 - 自動的に移行できないコンポーネントとパターンを手動で移行する方法に関する指針の提供。 MMA ではこのような作業が支援されますが、完全に機能するアプリケーションは提供されません。いくつかの追加手順が必要です。その手順にはテストが含まれ、次の作業も含まれる可能性があります。 - サポートされていないコンポーネントの手動移行。 - MMA で自動的に変換できない複雑な MEL 式の DataWeave への手動移行。 - MMA で自動的に変換できない複雑な DataWeave 変換の手動移行。 - MMA を実行する前に、DataWeave 移行ツールを使用して DataMapper を事前に移行。 また、MMA では増分移行がサポートされていないことにも注意してください。 # Mule 4 への移行の準備 Mule 4 では多くの変更が導入されているため、Mule 3 からの移行を試みる前にその点を考慮に入れて計画を練ってください。 ## [](#when_to_start)Mule 4 の使用を開始するタイミング 以下の場合、​**新しい**​プロジェクトはすべて Mule 4 で開発することをお勧めします。 - 自分を含むチームが、ドキュメントや正式なトレーニングを通じて Mule 4 に対応したスキルを備えている場合。 - [適切なデプロイメント環境](#prepare_dev_environ)​がある場合。 Mule 3 にデプロイされたプロジェクトの場合、Mule Migration Assistant (MMA) を使用して、Mule 4 でのアプリケーションの再作成を回避します。 次のいずれかの条件を満たす場合、アプリケーションを移行します。 - 使用している 3.x バージョンが期限切れになった場合。 - 既存のアプリケーションに対して重大な更新を行う場合。 - 重要な Mule 4 機能を利用したい場合。 - 組織ですべてのアプリケーションを 1 つのバージョンで実行する必要があるため、すべてのアプリケーションを Mule 4 にアップグレードすることを決定した場合 (一部のオンプレミスのシナリオ)。 ## [](#prepare_dev_environ)ローカル開発環境のセットアップ まず、Anypoint Studio 7 をダウンロードおよびインストールします。Anypoint Studio に付属の Mule バージョンがローカルデプロイメントに使用する Mule バージョンと一致しない場合は、必要な 4.x バージョンの Mule Runtime Engine をダウンロードします。 ## [](#prepare_to_deploy)デプロイの準備 次に、デプロイメント環境の準備を整える必要があります。現在の環境に応じて、必要なステップが異なる場合があります。
デプロイメントメカニズム 手順

CloudHub

CloudHub は Mule 4 に対応しています。

ハイブリッドデプロイメント

自分のサーバーに Mule 4 をインストールします。

Anypoint Runtime Fabric

Runtime Fabric は Mule 4 をサポートしています。

Anypoint Platform Private Cloud Edition (PCE)

PCE は Mule 4 をサポートしています。
## [](#write_code)コードの作成 完全な手動移行を実行している場合、Mule 4 アプリケーションの構築およびデプロイを開始できます。 移行プロセスの概要を把握し、Mule 4 で導入された変更を理解するには、​[「Mule 4 の概要」](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-overview)​をご確認ください。 Mule Migration Assistant (MMA) を使用した支援による移行の指針について、 [MMA ドキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#migration_process)​ を確認することが重要です。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** # Mule 4 への移行の準備 Mule 4 では多くの変更が導入されているため、Mule 3 からの移行を試みる前にその点を考慮に入れて計画を練ってください。 ## [](#when_to_start)Mule 4 の使用を開始するタイミング 以下の場合、​**新しい**​プロジェクトはすべて Mule 4 で開発することをお勧めします。 - 自分を含むチームが、ドキュメントや正式なトレーニングを通じて Mule 4 に対応したスキルを備えている場合。 - [適切なデプロイメント環境](#prepare_dev_environ)​がある場合。 Mule 3 にデプロイされたプロジェクトの場合、Mule Migration Assistant (MMA) を使用して、Mule 4 でのアプリケーションの再作成を回避します。 次のいずれかの条件を満たす場合、アプリケーションを移行します。 - 使用している 3.x バージョンが期限切れになった場合。 - 既存のアプリケーションに対して重大な更新を行う場合。 - 重要な Mule 4 機能を利用したい場合。 - 組織ですべてのアプリケーションを 1 つのバージョンで実行する必要があるため、すべてのアプリケーションを Mule 4 にアップグレードすることを決定した場合 (一部のオンプレミスのシナリオ)。 ## [](#prepare_dev_environ)ローカル開発環境のセットアップ まず、Anypoint Studio 7 をダウンロードおよびインストールします。Anypoint Studio に付属の Mule バージョンがローカルデプロイメントに使用する Mule バージョンと一致しない場合は、必要な 4.x バージョンの Mule Runtime Engine をダウンロードします。 ## [](#prepare_to_deploy)デプロイの準備 次に、デプロイメント環境の準備を整える必要があります。現在の環境に応じて、必要なステップが異なる場合があります。
デプロイメントメカニズム 手順

CloudHub

CloudHub は Mule 4 に対応しています。

ハイブリッドデプロイメント

自分のサーバーに Mule 4 をインストールします。

Anypoint Runtime Fabric

Runtime Fabric は Mule 4 をサポートしています。

Anypoint Platform Private Cloud Edition (PCE)

PCE は Mule 4 をサポートしています。
## [](#write_code)コードの作成 完全な手動移行を実行している場合、Mule 4 アプリケーションの構築およびデプロイを開始できます。 移行プロセスの概要を把握し、Mule 4 で導入された変更を理解するには、​[「Mule 4 の概要」](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-overview)​をご確認ください。 Mule Migration Assistant (MMA) を使用した支援による移行の指針について、 [MMA ドキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#migration_process)​ を確認することが重要です。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** # Mule 4 への移行の準備 Mule 4 では多くの変更が導入されているため、Mule 3 からの移行を試みる前にその点を考慮に入れて計画を練ってください。 ## [](#when_to_start)Mule 4 の使用を開始するタイミング 以下の場合、​**新しい**​プロジェクトはすべて Mule 4 で開発することをお勧めします。 - 自分を含むチームが、ドキュメントや正式なトレーニングを通じて Mule 4 に対応したスキルを備えている場合。 - [適切なデプロイメント環境](#prepare_dev_environ)​がある場合。 Mule 3 にデプロイされたプロジェクトの場合、Mule Migration Assistant (MMA) を使用して、Mule 4 でのアプリケーションの再作成を回避します。 次のいずれかの条件を満たす場合、アプリケーションを移行します。 - 使用している 3.x バージョンが期限切れになった場合。 - 既存のアプリケーションに対して重大な更新を行う場合。 - 重要な Mule 4 機能を利用したい場合。 - 組織ですべてのアプリケーションを 1 つのバージョンで実行する必要があるため、すべてのアプリケーションを Mule 4 にアップグレードすることを決定した場合 (一部のオンプレミスのシナリオ)。 ## [](#prepare_dev_environ)ローカル開発環境のセットアップ まず、Anypoint Studio 7 をダウンロードおよびインストールします。Anypoint Studio に付属の Mule バージョンがローカルデプロイメントに使用する Mule バージョンと一致しない場合は、必要な 4.x バージョンの Mule Runtime Engine をダウンロードします。 ## [](#prepare_to_deploy)デプロイの準備 次に、デプロイメント環境の準備を整える必要があります。現在の環境に応じて、必要なステップが異なる場合があります。
デプロイメントメカニズム 手順

CloudHub

CloudHub は Mule 4 に対応しています。

ハイブリッドデプロイメント

自分のサーバーに Mule 4 をインストールします。

Anypoint Runtime Fabric

Runtime Fabric は Mule 4 をサポートしています。

Anypoint Platform Private Cloud Edition (PCE)

PCE は Mule 4 をサポートしています。
## [](#write_code)コードの作成 完全な手動移行を実行している場合、Mule 4 アプリケーションの構築およびデプロイを開始できます。 移行プロセスの概要を把握し、Mule 4 で導入された変更を理解するには、​[「Mule 4 の概要」](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-overview)​をご確認ください。 Mule Migration Assistant (MMA) を使用した支援による移行の指針について、 [MMA ドキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#migration_process)​ を確認することが重要です。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** # Mule 4 への移行の準備 Mule 4 では多くの変更が導入されているため、Mule 3 からの移行を試みる前にその点を考慮に入れて計画を練ってください。 ## [](#when_to_start)Mule 4 の使用を開始するタイミング 以下の場合、​**新しい**​プロジェクトはすべて Mule 4 で開発することをお勧めします。 - 自分を含むチームが、ドキュメントや正式なトレーニングを通じて Mule 4 に対応したスキルを備えている場合。 - [適切なデプロイメント環境](#prepare_dev_environ)​がある場合。 Mule 3 にデプロイされたプロジェクトの場合、Mule Migration Assistant (MMA) を使用して、Mule 4 でのアプリケーションの再作成を回避します。 次のいずれかの条件を満たす場合、アプリケーションを移行します。 - 使用している 3.x バージョンが期限切れになった場合。 - 既存のアプリケーションに対して重大な更新を行う場合。 - 重要な Mule 4 機能を利用したい場合。 - 組織ですべてのアプリケーションを 1 つのバージョンで実行する必要があるため、すべてのアプリケーションを Mule 4 にアップグレードすることを決定した場合 (一部のオンプレミスのシナリオ)。 ## [](#prepare_dev_environ)ローカル開発環境のセットアップ まず、Anypoint Studio 7 をダウンロードおよびインストールします。Anypoint Studio に付属の Mule バージョンがローカルデプロイメントに使用する Mule バージョンと一致しない場合は、必要な 4.x バージョンの Mule Runtime Engine をダウンロードします。 ## [](#prepare_to_deploy)デプロイの準備 次に、デプロイメント環境の準備を整える必要があります。現在の環境に応じて、必要なステップが異なる場合があります。
デプロイメントメカニズム 手順

CloudHub

CloudHub は Mule 4 に対応しています。

ハイブリッドデプロイメント

自分のサーバーに Mule 4 をインストールします。

Anypoint Runtime Fabric

Runtime Fabric は Mule 4 をサポートしています。

Anypoint Platform Private Cloud Edition (PCE)

PCE は Mule 4 をサポートしています。
## [](#write_code)コードの作成 完全な手動移行を実行している場合、Mule 4 アプリケーションの構築およびデプロイを開始できます。 移行プロセスの概要を把握し、Mule 4 で導入された変更を理解するには、​[「Mule 4 の概要」](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-overview)​をご確認ください。 Mule Migration Assistant (MMA) を使用した支援による移行の指針について、 [MMA ドキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#migration_process)​ を確認することが重要です。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** # Mule 4 への移行の準備 Mule 4 では多くの変更が導入されているため、Mule 3 からの移行を試みる前にその点を考慮に入れて計画を練ってください。 ## [](#when_to_start)Mule 4 の使用を開始するタイミング 以下の場合、​**新しい**​プロジェクトはすべて Mule 4 で開発することをお勧めします。 - 自分を含むチームが、ドキュメントや正式なトレーニングを通じて Mule 4 に対応したスキルを備えている場合。 - [適切なデプロイメント環境](#prepare_dev_environ)​がある場合。 Mule 3 にデプロイされたプロジェクトの場合、Mule Migration Assistant (MMA) を使用して、Mule 4 でのアプリケーションの再作成を回避します。 次のいずれかの条件を満たす場合、アプリケーションを移行します。 - 使用している 3.x バージョンが期限切れになった場合。 - 既存のアプリケーションに対して重大な更新を行う場合。 - 重要な Mule 4 機能を利用したい場合。 - 組織ですべてのアプリケーションを 1 つのバージョンで実行する必要があるため、すべてのアプリケーションを Mule 4 にアップグレードすることを決定した場合 (一部のオンプレミスのシナリオ)。 ## [](#prepare_dev_environ)ローカル開発環境のセットアップ まず、Anypoint Studio 7 をダウンロードおよびインストールします。Anypoint Studio に付属の Mule バージョンがローカルデプロイメントに使用する Mule バージョンと一致しない場合は、必要な 4.x バージョンの Mule Runtime Engine をダウンロードします。 ## [](#prepare_to_deploy)デプロイの準備 次に、デプロイメント環境の準備を整える必要があります。現在の環境に応じて、必要なステップが異なる場合があります。
デプロイメントメカニズム 手順

CloudHub

CloudHub は Mule 4 に対応しています。

ハイブリッドデプロイメント

自分のサーバーに Mule 4 をインストールします。

Anypoint Runtime Fabric

Runtime Fabric は Mule 4 をサポートしています。

Anypoint Platform Private Cloud Edition (PCE)

PCE は Mule 4 をサポートしています。
## [](#write_code)コードの作成 完全な手動移行を実行している場合、Mule 4 アプリケーションの構築およびデプロイを開始できます。 移行プロセスの概要を把握し、Mule 4 で導入された変更を理解するには、​[「Mule 4 の概要」](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-overview)​をご確認ください。 Mule Migration Assistant (MMA) を使用した支援による移行の指針について、 [MMA ドキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#migration_process)​ を確認することが重要です。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** # Mule 4 への移行の準備 Mule 4 では多くの変更が導入されているため、Mule 3 からの移行を試みる前にその点を考慮に入れて計画を練ってください。 ## [](#when_to_start)Mule 4 の使用を開始するタイミング 以下の場合、​**新しい**​プロジェクトはすべて Mule 4 で開発することをお勧めします。 - 自分を含むチームが、ドキュメントや正式なトレーニングを通じて Mule 4 に対応したスキルを備えている場合。 - [適切なデプロイメント環境](#prepare_dev_environ)​がある場合。 Mule 3 にデプロイされたプロジェクトの場合、Mule Migration Assistant (MMA) を使用して、Mule 4 でのアプリケーションの再作成を回避します。 次のいずれかの条件を満たす場合、アプリケーションを移行します。 - 使用している 3.x バージョンが期限切れになった場合。 - 既存のアプリケーションに対して重大な更新を行う場合。 - 重要な Mule 4 機能を利用したい場合。 - 組織ですべてのアプリケーションを 1 つのバージョンで実行する必要があるため、すべてのアプリケーションを Mule 4 にアップグレードすることを決定した場合 (一部のオンプレミスのシナリオ)。 ## [](#prepare_dev_environ)ローカル開発環境のセットアップ まず、Anypoint Studio 7 をダウンロードおよびインストールします。Anypoint Studio に付属の Mule バージョンがローカルデプロイメントに使用する Mule バージョンと一致しない場合は、必要な 4.x バージョンの Mule Runtime Engine をダウンロードします。 ## [](#prepare_to_deploy)デプロイの準備 次に、デプロイメント環境の準備を整える必要があります。現在の環境に応じて、必要なステップが異なる場合があります。
デプロイメントメカニズム 手順

CloudHub

CloudHub は Mule 4 に対応しています。

ハイブリッドデプロイメント

自分のサーバーに Mule 4 をインストールします。

Anypoint Runtime Fabric

Runtime Fabric は Mule 4 をサポートしています。

Anypoint Platform Private Cloud Edition (PCE)

PCE は Mule 4 をサポートしています。
## [](#write_code)コードの作成 完全な手動移行を実行している場合、Mule 4 アプリケーションの構築およびデプロイを開始できます。 移行プロセスの概要を把握し、Mule 4 で導入された変更を理解するには、​[「Mule 4 の概要」](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-overview)​をご確認ください。 Mule Migration Assistant (MMA) を使用した支援による移行の指針について、 [MMA ドキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#migration_process)​ を確認することが重要です。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** # Mule 4 への移行の準備 Mule 4 では多くの変更が導入されているため、Mule 3 からの移行を試みる前にその点を考慮に入れて計画を練ってください。 ## [](#when_to_start)Mule 4 の使用を開始するタイミング 以下の場合、​**新しい**​プロジェクトはすべて Mule 4 で開発することをお勧めします。 - 自分を含むチームが、ドキュメントや正式なトレーニングを通じて Mule 4 に対応したスキルを備えている場合。 - [適切なデプロイメント環境](#prepare_dev_environ)​がある場合。 Mule 3 にデプロイされたプロジェクトの場合、Mule Migration Assistant (MMA) を使用して、Mule 4 でのアプリケーションの再作成を回避します。 次のいずれかの条件を満たす場合、アプリケーションを移行します。 - 使用している 3.x バージョンが期限切れになった場合。 - 既存のアプリケーションに対して重大な更新を行う場合。 - 重要な Mule 4 機能を利用したい場合。 - 組織ですべてのアプリケーションを 1 つのバージョンで実行する必要があるため、すべてのアプリケーションを Mule 4 にアップグレードすることを決定した場合 (一部のオンプレミスのシナリオ)。 ## [](#prepare_dev_environ)ローカル開発環境のセットアップ まず、Anypoint Studio 7 をダウンロードおよびインストールします。Anypoint Studio に付属の Mule バージョンがローカルデプロイメントに使用する Mule バージョンと一致しない場合は、必要な 4.x バージョンの Mule Runtime Engine をダウンロードします。 ## [](#prepare_to_deploy)デプロイの準備 次に、デプロイメント環境の準備を整える必要があります。現在の環境に応じて、必要なステップが異なる場合があります。
デプロイメントメカニズム 手順

CloudHub

CloudHub は Mule 4 に対応しています。

ハイブリッドデプロイメント

自分のサーバーに Mule 4 をインストールします。

Anypoint Runtime Fabric

Runtime Fabric は Mule 4 をサポートしています。

Anypoint Platform Private Cloud Edition (PCE)

PCE は Mule 4 をサポートしています。
## [](#write_code)コードの作成 完全な手動移行を実行している場合、Mule 4 アプリケーションの構築およびデプロイを開始できます。 移行プロセスの概要を把握し、Mule 4 で導入された変更を理解するには、​[「Mule 4 の概要」](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-overview)​をご確認ください。 Mule Migration Assistant (MMA) を使用した支援による移行の指針について、 [MMA ドキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc#migration_process)​ を確認することが重要です。 重要 **Mule Migration Assistant (MMA) には、 [Community](https://www.mulesoft.com/legal/versioning-back-support-policy#community)​ Connector について記述されている契約条件が適用されます。また、Mule Migration Assistant は、 [3-Clause BSD License](https://github.com/mulesoft/mule-migration-assistant/blob/master/LICENSE.txt)​ の契約条件に従って配布されるものとします。** # Mule 4.3 の新機能 Mule Runtime Engine のバージョン 4.3 では、アプリケーションのパフォーマンスが大幅に向上するのに加えて、引き続き Anypoint Platform でのアプリケーション開発を効率化でき、組織の活動に不可欠なユースケースで弾力性のあるランタイムを実現できます。 この新バージョンで実現されたすべての機能強化を活用するために、アプリケーションを Mule 4.3 に移行することをお勧めします。 ## [](#threading_model)スレッドモデル Mule 4.3 のスレッド処理は Mule 4.2 や 4.1 とは異なります。 以前のバージョンでは、Mule は 3 つの異なるスレッドプールを所有し、管理していました。これらのスレッドプールはそれぞれ異なる処理種別 (​CPU\_LIGHT​、IO、​CPU\_INTENSIVE​) 専用でした。タスクはプロアクター設計パターンを使用してこれらのプールに送信されていました。 Mule 4.3 以降では、引き続きプロアクターパターンが適用されますが、これらのスレッドプールが 1 つの一意のスレッドプールに結合されました。 新しいスレッドモデルおよびアップグレード手順についての詳細は、​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.3/execution-engine)​を参照してください。 ## [](#dataweave)DataWeave の更新 Mule 4.3.0 リリースには DataWeave 2.3.0 の機能が含まれています。 ### [](#更新の構文)更新の構文 この機能により、機能の再帰について理解することなく、ネストされたデータ構造で 1 つの値を簡単に更新できるようになります。 次のオブジェクトの配列は、DataWeave ソースに対する入力ペイロードになります。 入力: ```json [ { "ID" : 4128506, "name": "Ken", "age": 30 }, { "ID" : 1823940, "name": "Tomo", "age": 70 }, { "ID": 9086582, "name": "Kajika", "age": 10 } ] ``` 次の DataWeave スクリプトでは、​`map`​ 関数を使用してオブジェクトの入力配列の要素で反復処理を行います。新しい ​`update`​ 演算子を使用して各オブジェクトの 2 つのキー - 値ペアを変更します: 値が ​`"Tomo"`​ の場合は ​`"name"`​ キーの値に文字列 ​`" (Christian)"`​ を結合 (​`++`​) し、すべての ​`"age"`​ キーの値を ​`1`​ 増加させます。 取得元: ```weave %dw 2.0 output application/json --- payload map ((user) -> user update { case name at .name if(name == "Tomo") -> name ++ " (Christian)" case age at .age -> age + 1 } ) ``` JSON 出力により、文字列 ​`" (Christian)"`​ が値 ​`"Tomo"`​ に追加され、​`"age"`​ 値が ​`1`​ 増加されていることがわかります。​`"Tomo"`​ に一致しない ​`"name"`​ キー値と同じく、​`"ID"`​ キーの値は同じままです。 出力: ```json [ { "ID": 4128506, "name": "Ken", "age": 31 }, { "ID": 1823940, "name": "Tomo (Christian)", "age": 71 }, { "ID": 9086582, "name": "Kajika", "age": 11 } ] ``` 詳細なドキュメントについては、​[「update 演算子」](https://docs.mulesoft.com/jp/dataweave/2.3/dw-operators#update-operator)​を参照してください。 ### [](#ストリーミング機能および機能強化)ストリーミング機能および機能強化 - XML ストリーミング: XML 形式の DataWeave リーダーでストリーミングがサポートされるようになりました。ストリーミングを有効化するには、​`collectionPath`​ および ​`streaming`​ リーダープロパティを指定する必要があります。 ストリーミングを行う場合、XML パーサーはすべての XML コンテンツがなくてもコンテンツの処理を開始できます。これは、大きなコンテンツを扱うときに特に便利です。 詳細は、​[「XML 形式」](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats-xml)​を参照してください。 - JSON のストリーミングの改善: JSON リーダーで配列のみではなく JSON ドキュメント全体のストリーミングがサポートされるようになりました。 詳細は、​[「JSON 形式」](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats-json)​を参照してください。 ### [](#literal-リテラル-型)Literal (リテラル) 型 この機能により、Literal (リテラル) 型に対する DataWeave のサポートが実現されます。Literal (リテラル) 型は、ちょうど 1 つの値を表すデータ型です。つまり、たとえば、DataWeave はデータ型 ​`hello`​ を使用して ​`String`​ 値 ​`"hello"`​ を表すことができます。この機能により、関数のオーバーロードがきわめて動的になり、​`Union`​ 型と組み合わせた場合に、DataWeave でデータ型としてリテラル値の列挙を表せるようになります。たとえば、次のようになります。 ```weave type Weekdays = "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday" type Days = Weekdays | "Saturday" | "Sunday" fun greeting(day : "Monday") = "Best of luck in this new work week!" fun greeting(day : "Friday") = "YAY, it's Friday! Have an awesome day!" fun greeting(day: Weekdays) = "Have a nice day at work!" fun greeting(day: Days) = "We hope you have a great day!" ``` `greeting`​ 関数によって次のメッセージが表示されます。 - 週末 (土曜日と日曜日のみ) には一般的なメッセージ (​`"We hope you have a great day!"`​)。 - 火曜日から木曜日には仕事固有のメッセージ (​`"Have a nice day at work!"`​)。 - 平日の初日と最終日 (月曜日と金曜日) にはカスタマイズしたメッセージ。 DataWeave は、スクリプトで関数が宣言されている順序に従って、関数コールの引数を受け入れる最初の関数を使用します。 詳細なドキュメントについては、​[「Literal (リテラル) 型」](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-type-system#literal-types)​を参照してください。 ### [](#period-期間-と-datetime-日時-の一貫性)Period (期間) と DateTime (日時) の一貫性 この機能により、期間を簡単に操作し、結果を別の単位に変換して、期間を複数の部分に分解できるようになります。 次の例は、​`Duration`​ 値を分解する方法を示しています。ヘッダーで 1 つの ​`DateTime`​ 値を別の値から減算する ​`period`​ 変数を定義しています。このスクリプトでは、生成された ​`period`​ 値から ​`hours`​ 値、​`minutes`​ 値、​`secs`​ 値を選択して、操作の結果を分解しています。 取得元: ```weave %dw 2.0 output application/json var period = (|2010-12-10T12:10:12| - |2010-12-10T10:02:10|) --- { hours: period.hours, minutes: period.minutes, secs: period.secs, } ``` JSON 出力では、​`period`​ から選択された ​`hours`​ 値、​`minutes`​ 値、​`secs`​ 値の生成された数値が表示されます。 出力: ```json { "hours": 2, "minutes": 8, "secs": 2 } ``` 詳細なドキュメントについては、​[「期間」](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-types#dw_type_dates_period)​を参照してください。 ### [](#カスタム-mime-タイプ)カスタム MIME タイプ この機能により、出力データ形式とは別に出力 MIME タイプを定義できます。また、出力形式と入力形式の定義がよりシンプルになります。 ```json %dw 2.0 output json --- { Hello: “there” } ``` ドキュメントについては、​[「MIME タイプの設定」](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats#set_mime_types)​を参照してください。 ### [](#パフォーマンスの向上)パフォーマンスの向上 DataWeave により、このリリースのメモリ使用、関数 (​`groupBy`​ など)、内部実行エンジンのパフォーマンスが改善されます。 - 共通部分式の除去: 共通部分式除去は、スクリプトを最適化するために含まれています。DataWeave では、反復される部分式を表す内部変数を定義し、これによってその部分式の実行の反復を 1 つの式に置き換えることで、スクリプトが最適化されるようになりました。 ソース ```weave %dw 2.0 output json --- { code: payload.message.code, message : payload.message.value, user : payload.message.users[0].name, contact: payload.message.users[0].email } ``` 内部的には、上記の例のスクリプトは次の例で示しているように処理されます。ここで、変数は反復される各式について定義されるため、1 回しか実行されません。 内部表現 ```weave %dw 2.0 output json var fakeVariable1 = payload.message var fakeVariable2 = fakeVariable1.users[0] --- { code: fakeVariable1.code, message : fakeVariable1.value, user : fakeVariable2.name, contact: fakeVariable2.email } ``` - メモリ管理の改善: メモリ管理が一元化されました。ダイレクトメモリのプールやヒープメモリの排他的な使用など、いくつかのメモリ管理戦略が含まれています。 ### [](#dataweave-モジュール)DataWeave モジュール DataWeave では、データ型イントロスペクションをサポートするためにデータ型 (​`dw::core::Types`​) モジュールが導入されています。この新しいモジュールには多数の関数と新しいデータ方が含まれます。詳細は、​[「データ型 (dw::core::Types)」](https://docs.mulesoft.com/jp/dataweave/2.3/dw-types)​を参照してください。 DataWeave では、既存のモジュールの多数の新しい関数も導入されています。 - [コア](https://docs.mulesoft.com/jp/dataweave/2.3/dw-core)​ (​`dw::Core`​) モジュール: `entriesOf`​、​`keysOf`​、​`namesOf`​、​`valuesOf`​。 - [配列](https://docs.mulesoft.com/jp/dataweave/2.3/dw-arrays)​ (​`dw::core::Arrays`​) モジュール: `firstWith`​。 - [オブジェクト](https://docs.mulesoft.com/jp/dataweave/2.3/dw-objects)​ (​`dw::core::Objects`​) モジュール: `everyEntry`​、​`someEntry`​、​`takeWhile`​。​`dropWhile`​ には、反復処理し、条件が true になるまで配列内の項目を無視する新しい関数も含まれます。 - [文字列](https://docs.mulesoft.com/jp/dataweave/2.3/dw-objects)​ (​`dw::core::Strings`​) モジュール: `withMaxSize`​ により、特定の値の最大サイズを指定できます。サイズの上限を超えた値は切り捨てられます。サイズが制限より大きくない場合、値は同じままになります。 非推奨: オブジェクトモジュールの ​`entrySet`​ 関数、​`keySet`​ 関数、​`nameSet`​ 関数、​`valueSet`​ 関数はこのリリースでは非推奨であり、コアモジュールの ​`entriesOf`​ 関数、​`keysOf`​ 関数、​`namesOf`​ 関数、​`valuesOf`​ 関数に置き換えられています。 ### [](#intersection-交差-型)Intersection (交差) 型 DataWeave では、​`Intersection`​ 型が導入されています。​`Intersection`​ 型は ​`Object`​ 型に追加されます。 Intersection (交差) 型の構文は次のとおりです。 TypeA & TypeB & ... ドキュメントについては、​[「Type System (データ型の体系)」](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-type-system)​を参照してください。 ### [](#エラーメッセージの解析に対する改善)エラーメッセージの解析に対する改善 エラーメッセージの解析で、トークンの欠落、不完全な定義などの一般的な問題がより正確に反映されるようになりました。この問題の解決方法に関するヒントと例も含まれています。 ### [](#新しい-dataweave-リーダーとライターのプロパティ)新しい DataWeave リーダーとライターのプロパティ DataWeave では、サポートされる DataWeave 形式の新規および強化済みのリーダーとライターのプロパティが多数導入されています。 - バイナリ (​`application/octet-stream`​) 形式: `encoding` - DataWeave (​`application/dw`​) 形式: `onlyData`​ ライタープロパティとすべてのリーダープロパティ (​`externalResources`​、​`javaModule`​、​`onlyData`​) - JSON (​`application/json`​) 形式: `writeAttributes` - XML (​`application/xml`​) 形式: `escapeCR`​ ライタープロパティといくつかのリーダープロパティ (​`collectionPath`​、​`maxAttributeSize`​、​`optimizeFor`​、​`supportDtd`​、​`streaming`​) - YAML (​`application/yaml`​) 形式: `maxEntityCount`​ リーダープロパティ 説明については、​[「サポートされるデータ形式」](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats)​のこれらの形式へのリンクを参照してください。 ## [](#core_components)コアコンポーネント 次のコアコンポーネントは機能強化され、新しい機能が追加されています。 - Until Successful コンポーネント: Max Retries (​`maxRetries`​) と Milliseconds Between Retries (​`millisBetweenRetries`​) で、数値または数値に解決される式がサポートされるようになりました。 詳細なドキュメントについては、​[「Until Successful スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/until-successful-scope)​を参照してください。 - Batch Aggregator コンポーネントでは ​`preserveMimeTypes`​ 属性が追加されています。 集約されたレコードは、各レコードのペイロードが含まれる配列としてアグリゲーターに渡されます。ただし、デフォルトではそれらのペイロードに関連付けられている MIME タイプは保持されません。Batch Aggregator の ​`preserveMimeTypes`​ 属性を指定して、レコードの MIME タイプを保持できます。この変更により、JSON や XML など、構造化されたテキスト形式のペイロードからのレコードを処理するのが簡単になりました。 詳細なドキュメントについては、​[「Batch Step 処理の絞り込み」](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-filters-and-batch-aggregator)​を参照してください。 ## [](#api-ゲートウェイ)API ゲートウェイ API ゲートウェイに ​`disablePolicies`​ アノテーションが含まれるようになりました。​`true`​ に設定することで、リクエスターへのポリシーの適用をブロックできます。 また、このリリースではバックオフメカニズムの強化やポリシーデプロイヤーメカニズムの機能強化など、弾力性に関する強化もいくつか導入されています。 ## [](#関連情報)関連情報 - [Mule Runtime 4.3.0 リリースノート](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.3.0-release-notes) # Mule 4.4 の新機能 Mule Runtime Engine 4.4 では、重要な機能強化と修正が提供されます。このバージョンで実現されたすべての機能強化を活用するために、新規および既存のすべてのアプリケーションを Mule 4.4 にデプロイしてください。 ## [](#相関-id-管理)相関 ID 管理 Mule 4.4 を使用すると、Mule イベントに関連付けられた相関 ID を変更できます。各相関 ID を生成するために Mule で使用されるアルゴリズムを変更することもできます。 詳細および設定手順は、​[「相関 ID」](https://docs.mulesoft.com/mule-runtime/latest/correlation-id)​を参照してください。 ## [](#改善されたログ機能)改善されたログ機能 Mule 4.4 には Mapped Diagnostic Context (MDC) が組み込まれています。これによって、より多くのコンテキストまたは情報が Mule イベントのログに提供されるため、ログが強化され、追跡が改善されます。 Mule Tracing Module を使用すると、特定の Mule イベントのログコンテキストの変数を追加、削除、クリアできます。 詳細および設定手順は、​[「MDC ログ」](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc)​を参照してください。 ## [](#dataweave-の更新)DataWeave の更新 Mule 4.4 リリースには DataWeave 2.4.0 の機能が含まれています。 詳細は、​[「DataWeave の新機能」](https://docs.mulesoft.com/jp/dataweave/2.4/whats-new-in-dw)​を参照してください。 ## [](#コアコンポーネント)コアコンポーネント Mule 4.4 では Mule Tracing Module (Studio 7.11 で使用可能) が導入されます。これにより、相関 ID 管理機能が有効になるほか、ログオプションが改善されます。 このモジュールの完全なドキュメントは、​[Tracing Module](https://docs.mulesoft.com/tracing-module/latest/)​ を参照してください。 ## [](#機能フラグ)機能フラグ Mule 4.4 には機能フラグのメカニズムが組み込まれています。これを使用すると、後方互換性に影響する特定の Mule 機能の有効化を制御できます。 詳細および設定手順は、​[機能フラグ](https://docs.mulesoft.com/mule-runtime/latest/feature-flagging)​を参照してください。 ## [](#関連情報)関連情報 - [Mule Runtime 4.4.0 リリースノート](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.4.0-release-notes) # Mule API Javadoc MuleSoft は、Mule Kernel (以前の名称は Mule Community Edition) の Javadoc を提供しています。Mule Kernel では Mule Runtime Engine の一部の機能が提供されず、Mule Kernel を使用した開発は Anypoint Studio ではサポートされていません。 Javadoc には、クラスや項目とそのデータ型の定義、そしてメソッドの使い方、パラメーター、戻り値などの説明が記載されています。 Mule Runtime Engine をニーズに合わせて拡張するための簡単な方法を探している場合は、Mule SDK ドキュメントを参照してください。Javadoc へのリンクは以下にあります。 ## [](#java-クラス)Java クラス - [Mule 4.1.1 API](https://www.mulesoft.org/docs/site/4.1.1/apidocs/) - Mule 4.2.0 は使用できません。 - [Mule 4.3.0 API](https://www.mulesoft.org/docs/site/4.3.0/apidocs/) ## [](#関連情報)関連情報 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) - [Mule のダウンロード](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) - [Mule Kernel のダウンロード](https://developer.mulesoft.com/download-mule-esb-runtime) # Mule API Javadoc MuleSoft は、Mule Kernel (以前の名称は Mule Community Edition) の Javadoc を提供しています。Mule Kernel では Mule Runtime Engine の一部の機能が提供されず、Mule Kernel を使用した開発は Anypoint Studio ではサポートされていません。 Javadoc には、クラスや項目とそのデータ型の定義、そしてメソッドの使い方、パラメーター、戻り値などの説明が記載されています。 Mule Runtime Engine をニーズに合わせて拡張するための簡単な方法を探している場合は、Mule SDK ドキュメントを参照してください。Javadoc へのリンクは以下にあります。 ## [](#java-クラス)Java クラス - [Mule 4.1.1 API](https://www.mulesoft.org/docs/site/4.1.1/apidocs/) - Mule 4.2.0 は使用できません。 - [Mule 4.3.0 API](https://www.mulesoft.org/docs/site/4.3.0/apidocs/) - Mule 4.4.0 は使用できません。 ## [](#関連情報)関連情報 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) - [Mule のダウンロード](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) - [Mule Kernel のダウンロード](https://developer.mulesoft.com/download-mule-esb-runtime) # Mule API Javadoc MuleSoft は、Mule Kernel (以前の名称は Mule Community Edition) の Javadoc を提供しています。Mule Kernel では Mule Runtime Engine の一部の機能が提供されず、Mule Kernel を使用した開発は Anypoint Studio ではサポートされていません。 Javadoc には、クラスや項目とそのデータ型の定義、そしてメソッドの使い方、パラメーター、戻り値などの説明が記載されています。 Mule Runtime Engine をニーズに合わせて拡張するための簡単な方法を探している場合は、Mule SDK ドキュメントを参照してください。Javadoc へのリンクは以下にあります。 ## [](#java-クラス)Java クラス - [Mule 4.1.1 API](https://www.mulesoft.org/docs/site/4.1.1/apidocs/) - Mule 4.2.0 は使用できません。 - [Mule 4.3.0 API](https://www.mulesoft.org/docs/site/4.3.0/apidocs/) - Mule 4.4.0 は使用できません。 ## [](#関連情報)関連情報 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) - [Mule のダウンロード](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) - [Mule Kernel のダウンロード](https://developer.mulesoft.com/download-mule-esb-runtime) # Mule API Javadoc MuleSoft は、Mule Kernel (以前の名称は Mule Community Edition) の Javadoc を提供しています。Mule Kernel では Mule Runtime Engine の一部の機能が提供されず、Mule Kernel を使用した開発は Anypoint Studio ではサポートされていません。 Javadoc には、クラスや項目とそのデータ型の定義、そしてメソッドの使い方、パラメーター、戻り値などの説明が記載されています。 Mule Runtime Engine をニーズに合わせて拡張するための簡単な方法を探している場合は、Mule SDK ドキュメントを参照してください。Javadoc へのリンクは以下にあります。 ## [](#java-クラス)Java クラス - [Mule 4.1.1 API](https://www.mulesoft.org/docs/site/4.1.1/apidocs/) - Mule 4.2.0 は使用できません。 - [Mule 4.3.0 API](https://www.mulesoft.org/docs/site/4.3.0/apidocs/) - Mule 4.4.0 は使用できません。 ## [](#関連情報)関連情報 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) - [Mule のダウンロード](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) - [Mule Kernel のダウンロード](https://developer.mulesoft.com/download-mule-esb-runtime) # Mule API Javadoc MuleSoft は、Mule Kernel (以前の名称は Mule Community Edition) の Javadoc を提供しています。Mule Kernel では Mule Runtime Engine の一部の機能が提供されず、Mule Kernel を使用した開発は Anypoint Studio ではサポートされていません。 Javadoc には、クラスや項目とそのデータ型の定義、そしてメソッドの使い方、パラメーター、戻り値などの説明が記載されています。 Mule Runtime Engine をニーズに合わせて拡張するための簡単な方法を探している場合は、Mule SDK ドキュメントを参照してください。Javadoc へのリンクは以下にあります。 ## [](#java-クラス)Java クラス - [Mule 4.1.1 API](https://www.mulesoft.org/docs/site/4.1.1/apidocs/) - Mule 4.2.0 は使用できません。 - [Mule 4.3.0 API](https://www.mulesoft.org/docs/site/4.3.0/apidocs/) - Mule 4.4.0 は使用できません。 ## [](#関連情報)関連情報 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) - [Mule のダウンロード](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) - [Mule Kernel のダウンロード](https://developer.mulesoft.com/download-mule-esb-runtime) # Mule API Javadoc MuleSoft は、Mule Kernel (以前の名称は Mule Community Edition) の Javadoc を提供しています。Mule Kernel では Mule Runtime Engine の一部の機能が提供されず、Mule Kernel を使用した開発は Anypoint Studio ではサポートされていません。 Javadoc には、クラスや項目とそのデータ型の定義、そしてメソッドの使い方、パラメーター、戻り値などの説明が記載されています。 Mule Runtime Engine をニーズに合わせて拡張するための簡単な方法を探している場合は、Mule SDK ドキュメントを参照してください。Javadoc へのリンクは以下にあります。 ## [](#java-クラス)Java クラス - [Mule 4.1.1 API](https://www.mulesoft.org/docs/site/4.1.1/apidocs/) - Mule 4.2.0 は使用できません。 - [Mule 4.3.0 API](https://www.mulesoft.org/docs/site/4.3.0/apidocs/) - Mule 4.4.0 は使用できません。 ## [](#関連情報)関連情報 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) - [Mule のダウンロード](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) - [Mule Kernel のダウンロード](https://developer.mulesoft.com/download-mule-esb-runtime) # Mule API Javadoc MuleSoft は、Mule Kernel (以前の名称は Mule Community Edition) の Javadoc を提供しています。Mule Kernel では Mule Runtime Engine の一部の機能が提供されず、Mule Kernel を使用した開発は Anypoint Studio ではサポートされていません。 Javadoc には、クラスや項目とそのデータ型の定義、そしてメソッドの使い方、パラメーター、戻り値などの説明が記載されています。 Mule Runtime Engine をニーズに合わせて拡張するための簡単な方法を探している場合は、Mule SDK ドキュメントを参照してください。Javadoc へのリンクは以下にあります。 ## [](#java-クラス)Java クラス - [Mule 4.1.1 API](https://www.mulesoft.org/docs/site/4.1.1/apidocs/) - Mule 4.2.0 は使用できません。 - [Mule 4.3.0 API](https://www.mulesoft.org/docs/site/4.3.0/apidocs/) - Mule 4.4.0 は使用できません。 ## [](#関連情報)関連情報 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) - [Mule のダウンロード](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) - [Mule Kernel のダウンロード](https://developer.mulesoft.com/download-mule-esb-runtime) # Mule Maven プラグイン
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule Maven プラグインでは、Mule アプリケーションのパッケージおよびデプロイメントを Maven ライフサイクルと統合できます。 パッケージ化の手順は、​[「Mule アプリケーションをパッケージする」](https://docs.mulesoft.com/jp/mule-runtime/4.3/package-a-mule-application)​を参照してください。 Mule Maven プラグインは Mule Runtime Engine (Enterprise Edition) および Mule Kernel (Community Edition) と互換性があります。 Mule Maven プラグインを使用すれば、次のデプロイメント戦略のいずれかを使用して、CloudHub へ、Anypoint Runtime Fabric へ、またはオンプレミスでの Mule アプリケーションのデプロイメントを自動化できます。 - CloudHub デプロイメント Mule アプリケーションを CloudHub にデプロイします。 手順は、​[「CloudHub へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-to-cloudhub)​を参照してください。 - Runtime Fabric デプロイメント Anypoint Runtime Fabric に Mule アプリケーションをデプロイします。 手順は、​[「Anypoint Runtime Fabric へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-to-rtf)​を参照してください。 - Runtime Manager REST API デプロイメント Runtime Manager REST API を使用してサーバーまたはサーバークラスターに Mule アプリケーションをデプロイします。 手順は、​[「Runtime Manager REST API を使用して Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-on-premises#mmp-deploy-arm)​を参照してください。 - Runtime Manager エージェントデプロイメント Runtime Manager エージェントを使用して Mule アプリケーションをデプロイします。 このデプロイメント戦略は、すべての Mule インスタンスが 1 つのアドレス空間にある場合のみ機能します。 手順は、​[「Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-on-premises#mmp-deploy-agent)​を参照してください。 - スタンドアロンランタイムデプロイメント マシンで実行中の Mule インスタンスに Mule アプリケーションをデプロイします。 手順は、​[「スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-on-premises#mmp-deploy-standalone)​を参照してください。 ## [](#互換性)互換性 - Mule 4.x - Anypoint Studio 7.x ## [](#mule-maven-プラグインの目標)Mule Maven プラグインの目標 Mule Maven プラグインには 4 つの目標があります。 - `package` プロジェクトの jar ファイルを生成します。 - `deploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) で自動的にアプリケーションをアップロードして起動します。 - `mule:deploy` 指定された場所からアーティファクトをデプロイします。 - `mule:undeploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) から自動的にアプリケーションを削除します。 各目標では、目的のプラグイン動作に固有のパラメーターを受け入れます。 コマンドラインからパラメーターを指定するには、パラメーター名の先頭に ​`-D`​ を追加します。 ### [](#package-goal)目標のパッケージ化 `package`​ 目標では、アプリケーションの JAR ファイルが生成されます。この目標は、デフォルトで Maven ライフサイクルフェーズ: `package`​ にバインドします。 省略可能なパラメーター
名前 型 説明

onlyMuleSources

boolean (ブール)

ソースコードのみが含まれるアプリケーションの JAR ファイルを生成します。このプロパティは共有のみに使用します。

attachMuleSources

boolean (ブール)

生成した JAR ファイル内にソースコードを添付します。

lightweightPackage

boolean (ブール)

JAR ファイル内のすべてのアプリケーションの連動関係が含まれるリポジトリを生成しません。このプロパティは共有のみに使用します。
たとえば、​`package`​ 目標を実行して ​`attachMuleSources`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn package -DattachMuleSources ``` ### [](#目標のデプロイ)目標のデプロイ この目標では、アプリケーションの JAR ファイルを任意のアプリケーションデプロイメント対象にアップロードしてデプロイします。deploy 目標は、デフォルトで Maven ライフサイクルフェーズ: `deploy`​ にバインドします。 省略可能なパラメーター
名前 型 説明

artifact

String (文字列)

アプリケーションの JAR ファイルをデプロイするパス。デフォルトでは、アプリケーションの ​target​ フォルダーに設定されます。

muleDeploy

boolean (ブール)

このプラグインに、プラグイン設定で定義されたデプロイメント戦略を使用してデプロイするよう指示します。​muleDeploy​ パラメーターが設定されていない場合、このプラグインで、アプリケーションの ​pom.xml​ ファイルの ​distributionManagement​ セクションで定義されたリポジトリにアーティファクトがアップロードされます。
たとえば、​`deploy`​ 目標を実行して ​`muleDeploy`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn deploy -DmuleDeploy ``` ### [](#muledeploy-目標)mule:deploy 目標 この目標を使用すると、アーティファクトを作成せずにデプロイできます。アーティファクトの場所を指定するには、​`mule.artifact`​ パラメーターを使用します。 次に例を示します。 ```console mvn mule:deploy -Dmule.artifact=myProject/myArtifact.jar ``` このプロパティは、CloudHub、スタンドアロン、またはオンプレミスデプロイメントで有効です。 ### [](#muleundeploy-目標)mule:undeploy 目標 この目標では、任意のアプリケーションデプロイメント対象からアプリケーションを削除します。プラグイン設定の情報を使用して、アプリケーションを定義されたデプロイメント対象から削除します。 `undeploy`​ 目標を実行するには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy 目標により、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する 操作を実行する前に、Mule Maven プラグインをプロジェクトに追加する必要があります。 Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 3.4.2 true ``` このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。
<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
## [](#プラグイン実行のスキップ)プラグイン実行のスキップ デプロイメント設定内で ​`skip`​ パラメーターを true に設定することで、プラグイン実行をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.4.2 true ${mule.home.test} true ``` ## [](#デプロイメント検証のスキップ)デプロイメント検証のスキップ 任意のプラットフォームデプロイメント (Cloudhub、Runtime Manager、Runtime Fabric) 内で ​`skipDeploymentVerification`​ パラメーターを true に設定することで、状況検証をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.4.2 true ... true ... ``` `skipDeploymentVerification`​ パラメーターが存在しない場合、デフォルト値は false です。 この機能は、プラグインバージョン 3.2.5 以降で使用できます。 ## [](#configure-shared-libraries)共有ライブラリの設定 アプリケーションの連動関係をアプリケーションのコネクタから参照できるようにする必要がある場合は、共有ライブラリを設定します。連動関係を共有ライブラリとして設定するには、プロジェクトの ​`pom.xml`​ ファイル内の Mule Maven プラグイン設定に次の要素を追加します。 ```xml ${dependencyGroupID} ${dependencyArtifactID} ``` 次の例では、プロジェクトのデータベース用 Anypoint Connector (Database Connector) を設定し、さらに MySQL ドライバーを共有ライブラリとして設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} true mysql mysql-connector-java org.mule.connectors mule-db-connector 1.5.0 mule-plugin mysql mysql-connector-java 5.1.33 ``` ## [](#configure-plugin-dependencies)追加プラグイン連動関係の設定 アプリケーションでコネクタの追加プラグイン連動関係を設定できます。 追加プラグイン連動関係を設定するには、プロジェクトの ​`pom.xml`​ ファイル内の Mule Maven プラグイン設定に次の要素を追加します。 ```xml ${connectorGroupID} ${connectorArtifactID} ${dependencyGroupID} ${dependencyArtifactID} ${dependencyVersion} ``` 次の例では、Derby ドライバーを Database Connector の連動関係として設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.mule.connectors mule-db-connector org.apache.derby derby 10.11.1.1 ``` ## [](#mule-maven-プラグインリファレンス)Mule Maven プラグインリファレンス 各デプロイメント戦略のパラメーターリファレンスへのリンクを以下に示します。 - [CloudHub デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-to-cloudhub#cloudhub-deploy-reference) - [Runtime Fabric デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-to-rtf#rtf-deploy-reference) - [スタンドアロンデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-on-premises#standalone-deploy-reference) - [Runtime Manager REST API デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-on-premises#arm-deploy-reference) - [Runtime Manager エージェントデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-on-premises#arm-agent-deploy-reference) ## [](#関連情報)関連情報 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-classloading-isolation) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.3/how-to-export-resources) - [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven) - [Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) - [Runtime Manager REST API](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-api) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) # Mule Maven プラグイン
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule Maven プラグインでは、Mule アプリケーションのパッケージおよびデプロイメントを Maven ライフサイクルと統合できます。 パッケージ化の手順は、​[「Mule アプリケーションをパッケージする」](https://docs.mulesoft.com/jp/mule-runtime/4.4/package-a-mule-application)​を参照してください。 Mule Maven プラグインは Mule Runtime Engine (Enterprise Edition) および Mule Kernel (Community Edition) と互換性があります。 Mule Maven プラグインを使用すれば、次のデプロイメント戦略のいずれかを使用して、CloudHub、CloudHub 2.0、または Anypoint Runtime Fabric への、もしくはオンプレミスでの Mule アプリケーションのデプロイメントを自動化できます。 - CloudHub デプロイメント Mule アプリケーションを CloudHub にデプロイします。 手順は、​[「CloudHub へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-to-cloudhub)​を参照してください。 - CloudHub 2.0 デプロイメント Mule アプリケーションを CloudHub 2.0 にデプロイします。 手順は、​[「CloudHub 2.0 へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-to-cloudhub-2)​を参照してください。 - Runtime Fabric デプロイメント Anypoint Runtime Fabric に Mule アプリケーションをデプロイします。 手順は、​[「Anypoint Runtime Fabric へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-to-rtf)​を参照してください。 - Runtime Manager REST API デプロイメント Runtime Manager REST API を使用してサーバーまたはサーバークラスターに Mule アプリケーションをデプロイします。 手順は、​[「Runtime Manager REST API を使用して Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-on-premises#mmp-deploy-arm)​を参照してください。 - Runtime Manager エージェントデプロイメント Runtime Manager エージェントを使用して Mule アプリケーションをデプロイします。 このデプロイメント戦略は、すべての Mule インスタンスが 1 つのアドレス空間にある場合のみ機能します。 手順は、​[「Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-on-premises#mmp-deploy-agent)​を参照してください。 - スタンドアロンランタイムデプロイメント マシンで実行中の Mule インスタンスに Mule アプリケーションをデプロイします。 手順は、​[「スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-on-premises#mmp-deploy-standalone)​を参照してください。 ## [](#互換性)互換性 - Mule 4.x - Anypoint Studio 7.x ## [](#mule-maven-プラグインの目標)Mule Maven プラグインの目標 Mule Maven プラグインには 4 つの目標があります。 - `package` プロジェクトの jar ファイルを生成します。 - `deploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) で自動的にアプリケーションをアップロードして起動します。 - `mule:deploy` 指定された場所からアーティファクトをデプロイします。 - `mule:undeploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) から自動的にアプリケーションを削除します。 各目標では、目的のプラグイン動作に固有のパラメーターを受け入れます。 コマンドラインからパラメーターを指定するには、パラメーター名の先頭に ​`-D`​ を追加します。 ### [](#package-goal)目標のパッケージ化 `package`​ 目標では、アプリケーションの JAR ファイルが生成されます。この目標は、デフォルトで Maven ライフサイクルフェーズ: `package`​ にバインドします。 省略可能なパラメーター
名前 型 説明

onlyMuleSources

boolean (ブール)

ソースコードのみが含まれるアプリケーションの JAR ファイルを生成します。このプロパティは共有のみに使用します。

attachMuleSources

boolean (ブール)

生成した JAR ファイル内にソースコードを添付します。

lightweightPackage

boolean (ブール)

JAR ファイル内のすべてのアプリケーションの連動関係が含まれるリポジトリを生成しません。このプロパティは共有のみに使用します。
たとえば、​`package`​ 目標を実行して ​`attachMuleSources`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn package -DattachMuleSources ``` ### [](#目標のデプロイ)目標のデプロイ この目標では、アプリケーションの JAR ファイルを任意のアプリケーションデプロイメント対象にアップロードしてデプロイします。deploy 目標は、デフォルトで Maven ライフサイクルフェーズ: `deploy`​ にバインドします。 省略可能なパラメーター
名前 型 説明

artifact

String (文字列)

アプリケーションの JAR ファイルをデプロイするパス。デフォルトでは、アプリケーションの ​target​ フォルダーに設定されます。

muleDeploy

boolean (ブール)

このプラグインに、プラグイン設定で定義されたデプロイメント戦略を使用してデプロイするよう指示します。​muleDeploy​ パラメーターが設定されていない場合、このプラグインで、アプリケーションの ​pom.xml​ ファイルの ​distributionManagement​ セクションで定義されたリポジトリにアーティファクトがアップロードされます。
たとえば、​`deploy`​ 目標を実行して ​`muleDeploy`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn deploy -DmuleDeploy ``` ### [](#muledeploy-目標)mule:deploy 目標 この目標を使用すると、アーティファクトを作成せずにデプロイできます。アーティファクトの場所を指定するには、​`mule.artifact`​ パラメーターを使用します。 次に例を示します。 ```console mvn mule:deploy -Dmule.artifact=myProject/myArtifact.jar ``` このプロパティは、CloudHub、スタンドアロン、またはオンプレミスデプロイメントで有効です。 ### [](#muleundeploy-目標)mule:undeploy 目標 この目標では、任意のアプリケーションデプロイメント対象からアプリケーションを削除します。プラグイン設定の情報を使用して、アプリケーションを定義されたデプロイメント対象から削除します。 `undeploy`​ 目標を実行するには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy 目標により、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する 操作を実行する前に、Mule Maven プラグインをプロジェクトに追加する必要があります。 Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。
<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
## [](#プラグイン実行のスキップ)プラグイン実行のスキップ デプロイメント設定内で ​`skip`​ パラメーターを true に設定することで、プラグイン実行をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} true ``` ## [](#デプロイメント検証のスキップ)デプロイメント検証のスキップ 任意のプラットフォームデプロイメント (Cloudhub、Runtime Manager、Runtime Fabric) 内で ​`skipDeploymentVerification`​ パラメーターを true に設定することで、状況検証をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ... true ... ``` `skipDeploymentVerification`​ パラメーターが存在しない場合、デフォルト値は false です。 この機能は、プラグインバージョン 3.2.5 以降で使用できます。 ## [](#configure-shared-libraries)共有ライブラリの設定 共有ライブラリでは、アプリケーションの連動関係を設定し、この連動関係をアプリケーション内のすべてのコネクタからアクセス可能にできます。 この機能の詳細な説明は、​[「Shared Libraries (共有ライブラリ)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#shared-libraries)​を参照してください。 連動関係を共有ライブラリとして設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${dependencyGroupID} ${dependencyArtifactID} ``` 次の例では、プロジェクトのデータベース用 Anypoint Connector (Database Connector) を設定し、さらに MySQL ドライバーを共有ライブラリとして設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} true mysql mysql-connector-java org.mule.connectors mule-db-connector 1.5.0 mule-plugin mysql mysql-connector-java 5.1.33 ``` ## [](#configure-plugin-dependencies)追加プラグイン連動関係の設定 アプリケーションのコネクタ用に追加プラグイン連動関係を設定すると、それらの連動関係はそのコネクタでのみ使用可能になります。これにより、異なるコネクタに対して、異なる連動関係や同じ連動関係の複数のバージョンさえ設定できます。 この機能の詳細な説明は、​[「Additional Plugin Dependencies (追加プラグイン連動関係)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#additional-plugin-dependencies)​を参照してください。 追加プラグイン連動関係を設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${connectorGroupID} ${connectorArtifactID} ${dependencyGroupID} ${dependencyArtifactID} ${dependencyVersion} ``` 次の例では、Derby ドライバーを Database Connector の連動関係として設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.mule.connectors mule-db-connector org.apache.derby derby 10.11.1.1 ``` ## [](#mule-maven-プラグインリファレンス)Mule Maven プラグインリファレンス 各デプロイメント戦略のパラメーターリファレンスへのリンクを以下に示します。 - [CloudHub デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-to-cloudhub#cloudhub-deploy-reference) - [Runtime Fabric デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-to-rtf#rtf-deploy-reference) - [スタンドアロンデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-on-premises#standalone-deploy-reference) - [Runtime Manager REST API デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-on-premises#arm-deploy-reference) - [Runtime Manager エージェントデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-on-premises#arm-agent-deploy-reference) ## [](#関連情報)関連情報 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-classloading-isolation) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.4/how-to-export-resources) - [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven) - [Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) - [Runtime Manager REST API](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-api) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) # Mule Maven プラグイン
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule Maven プラグインでは、Mule アプリケーションのパッケージおよびデプロイメントを Maven ライフサイクルと統合できます。 パッケージ化の手順は、​[「Mule アプリケーションをパッケージする」](https://docs.mulesoft.com/jp/mule-runtime/4.5/package-a-mule-application)​を参照してください。 Mule Maven プラグインは Mule Runtime Engine (Enterprise Edition) および Mule Kernel (Community Edition) と互換性があります。 Mule Maven プラグインを使用すれば、次のデプロイメント戦略のいずれかを使用して、CloudHub、CloudHub 2.0、または Anypoint Runtime Fabric への、もしくはオンプレミスでの Mule アプリケーションのデプロイメントを自動化できます。 - CloudHub デプロイメント Mule アプリケーションを CloudHub にデプロイします。 手順は、​[「CloudHub へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-to-cloudhub)​を参照してください。 - CloudHub 2.0 デプロイメント Mule アプリケーションを CloudHub 2.0 にデプロイします。 手順は、​[「CloudHub 2.0 へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-to-cloudhub-2)​を参照してください。 - Runtime Fabric デプロイメント Anypoint Runtime Fabric に Mule アプリケーションをデプロイします。 手順は、​[「Anypoint Runtime Fabric へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-to-rtf)​を参照してください。 - Runtime Manager REST API デプロイメント Runtime Manager REST API を使用してサーバーまたはサーバークラスターに Mule アプリケーションをデプロイします。 手順は、​[「Runtime Manager REST API を使用して Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-on-premises#mmp-deploy-arm)​を参照してください。 - Runtime Manager エージェントデプロイメント Runtime Manager エージェントを使用して Mule アプリケーションをデプロイします。 このデプロイメント戦略は、すべての Mule インスタンスが 1 つのアドレス空間にある場合のみ機能します。 手順は、​[「Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-on-premises#mmp-deploy-agent)​を参照してください。 - スタンドアロンランタイムデプロイメント マシンで実行中の Mule インスタンスに Mule アプリケーションをデプロイします。 手順は、​[「スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-on-premises#mmp-deploy-standalone)​を参照してください。 ## [](#互換性)互換性 - Mule 4.x - Anypoint Studio 7.x ## [](#mule-maven-プラグインの目標)Mule Maven プラグインの目標 Mule Maven プラグインには次の目標があります。 - `package` プロジェクトの jar ファイルを生成します。 - `deploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) で自動的にアプリケーションをアップロードして起動します。 - `mule:deploy` 指定された場所からアーティファクトをデプロイします。 - `mule:undeploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) から自動的にアプリケーションを削除します。 各目標では、目的のプラグイン動作に固有のパラメーターを受け入れます。 コマンドラインからパラメーターを指定するには、パラメーター名の先頭に ​`-D`​ を追加します。 ### [](#package-goal)目標のパッケージ化 `package`​ 目標では、アプリケーションの JAR ファイルが生成されます。この目標は、デフォルトで Maven ライフサイクルフェーズ: `package`​ にバインドします。 省略可能なパラメーター
名前 型 説明

onlyMuleSources

boolean (ブール)

ソースコードのみが含まれるアプリケーションの JAR ファイルを生成します。このプロパティは共有のみに使用します。

attachMuleSources

boolean (ブール)

生成した JAR ファイル内にソースコードを添付します。

lightweightPackage

boolean (ブール)

JAR ファイル内のすべてのアプリケーションの連動関係が含まれるリポジトリを生成しません。このプロパティは共有のみに使用します。
たとえば、​`package`​ 目標を実行して ​`attachMuleSources`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn package -DattachMuleSources ``` ### [](#目標のデプロイ)目標のデプロイ この目標では、アプリケーションの JAR ファイルを任意のアプリケーションデプロイメント対象にアップロードしてデプロイします。deploy 目標は、デフォルトで Maven ライフサイクルフェーズ: `deploy`​ にバインドします。 省略可能なパラメーター
名前 型 説明

artifact

String (文字列)

アプリケーションの JAR ファイルをデプロイするパス。デフォルトでは、アプリケーションの ​target​ フォルダーに設定されます。

muleDeploy

boolean (ブール)

このプラグインに、プラグイン設定で定義されたデプロイメント戦略を使用してデプロイするよう指示します。​muleDeploy​ パラメーターが設定されていない場合、このプラグインで、アプリケーションの ​pom.xml​ ファイルの ​distributionManagement​ セクションで定義されたリポジトリにアーティファクトがアップロードされます。
たとえば、​`deploy`​ 目標を実行して ​`muleDeploy`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn deploy -DmuleDeploy ``` ### [](#muledeploy-目標)mule:deploy 目標 この目標を使用すると、アーティファクトを作成せずにデプロイできます。アーティファクトの場所を指定するには、​`mule.artifact`​ パラメーターを使用します。 次に例を示します。 ```console mvn mule:deploy -Dmule.artifact=myProject/myArtifact.jar ``` このプロパティは、CloudHub、スタンドアロン、またはオンプレミスデプロイメントで有効です。 ### [](#muleundeploy-目標)mule:undeploy 目標 この目標では、任意のアプリケーションデプロイメント対象からアプリケーションを削除します。プラグイン設定の情報を使用して、アプリケーションを定義されたデプロイメント対象から削除します。 `undeploy`​ 目標を実行するには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy 目標により、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する 操作を実行する前に、Mule Maven プラグインをプロジェクトに追加する必要があります。 Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。
<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
## [](#プラグイン実行のスキップ)プラグイン実行のスキップ デプロイメント設定内で ​`skip`​ パラメーターを true に設定することで、プラグイン実行をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} true ``` ## [](#デプロイメント検証のスキップ)デプロイメント検証のスキップ 任意のプラットフォームデプロイメント (Cloudhub、Runtime Manager、Runtime Fabric) 内で ​`skipDeploymentVerification`​ パラメーターを true に設定することで、状況検証をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ... true ... ``` `skipDeploymentVerification`​ パラメーターが存在しない場合、デフォルト値は false です。 この機能は、プラグインバージョン 3.2.5 以降で使用できます。 ## [](#configure-shared-libraries)共有ライブラリの設定 共有ライブラリでは、アプリケーションの連動関係を設定し、この連動関係をアプリケーション内のすべてのコネクタからアクセス可能にできます。 この機能の詳細な説明は、​[「Shared Libraries (共有ライブラリ)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#shared-libraries)​を参照してください。 連動関係を共有ライブラリとして設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${dependencyGroupID} ${dependencyArtifactID} ``` 次の例では、プロジェクトのデータベース用 Anypoint Connector (Database Connector) を設定し、さらに MySQL ドライバーを共有ライブラリとして設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} true mysql mysql-connector-java org.mule.connectors mule-db-connector 1.5.0 mule-plugin mysql mysql-connector-java 5.1.33 ``` ## [](#configure-plugin-dependencies)追加プラグイン連動関係の設定 アプリケーションのコネクタ用に追加プラグイン連動関係を設定すると、それらの連動関係はそのコネクタでのみ使用可能になります。これにより、異なるコネクタに対して、異なる連動関係や同じ連動関係の複数のバージョンさえ設定できます。 この機能の詳細な説明は、​[「Additional Plugin Dependencies (追加プラグイン連動関係)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#additional-plugin-dependencies)​を参照してください。 追加プラグイン連動関係を設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${connectorGroupID} ${connectorArtifactID} ${dependencyGroupID} ${dependencyArtifactID} ${dependencyVersion} ``` 次の例では、Derby ドライバーを Database Connector の連動関係として設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.mule.connectors mule-db-connector org.apache.derby derby 10.11.1.1 ``` ## [](#mule-maven-プラグインリファレンス)Mule Maven プラグインリファレンス 各デプロイメント戦略のパラメーターリファレンスへのリンクを以下に示します。 - [CloudHub デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-to-cloudhub#cloudhub-deploy-reference) - [Runtime Fabric デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-to-rtf#rtf-deploy-reference) - [スタンドアロンデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-on-premises#standalone-deploy-reference) - [Runtime Manager REST API デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-on-premises#arm-deploy-reference) - [Runtime Manager エージェントデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-on-premises#arm-agent-deploy-reference) ## [](#関連情報)関連情報 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-classloading-isolation) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.5/how-to-export-resources) - [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven) - [Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) - [Runtime Manager REST API](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-api) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) # Mule Maven プラグイン
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule Maven プラグインでは、Mule アプリケーションのパッケージおよびデプロイメントを Maven ライフサイクルと統合できます。 パッケージ化の手順は、​[「Mule アプリケーションをパッケージする」](https://docs.mulesoft.com/jp/mule-runtime/4.6/package-a-mule-application)​を参照してください。 Mule Maven プラグインは Mule Runtime Engine (Enterprise Edition) および Mule Kernel (Community Edition) と互換性があります。 Mule Maven プラグインを使用すれば、次のデプロイメント戦略のいずれかを使用して、CloudHub、CloudHub 2.0、または Anypoint Runtime Fabric への、もしくはオンプレミスでの Mule アプリケーションのデプロイメントを自動化できます。 - CloudHub デプロイメント Mule アプリケーションを CloudHub にデプロイします。 手順は、​[「CloudHub へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-to-cloudhub)​を参照してください。 - CloudHub 2.0 デプロイメント Mule アプリケーションを CloudHub 2.0 にデプロイします。 手順は、​[「CloudHub 2.0 へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-to-cloudhub-2)​を参照してください。 - Runtime Fabric デプロイメント Anypoint Runtime Fabric に Mule アプリケーションをデプロイします。 手順は、​[「Anypoint Runtime Fabric へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-to-rtf)​を参照してください。 - Runtime Manager REST API デプロイメント Runtime Manager REST API を使用してサーバーまたはサーバークラスターに Mule アプリケーションをデプロイします。 手順は、​[「Runtime Manager REST API を使用して Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-on-premises#mmp-deploy-arm)​を参照してください。 - Runtime Manager エージェントデプロイメント Runtime Manager エージェントを使用して Mule アプリケーションをデプロイします。 このデプロイメント戦略は、すべての Mule インスタンスが 1 つのアドレス空間にある場合のみ機能します。 手順は、​[「Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-on-premises#mmp-deploy-agent)​を参照してください。 - スタンドアロンランタイムデプロイメント マシンで実行中の Mule インスタンスに Mule アプリケーションをデプロイします。 手順は、​[「スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-on-premises#mmp-deploy-standalone)​を参照してください。 ## [](#互換性)互換性 - Mule 4.x - Anypoint Studio 7.x ## [](#mule-maven-プラグインの目標)Mule Maven プラグインの目標 Mule Maven プラグインには次の目標があります。 - `package` プロジェクトの jar ファイルを生成します。 - `deploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) で自動的にアプリケーションをアップロードして起動します。 - `mule:deploy` 指定された場所からアーティファクトをデプロイします。 - `mule:undeploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) から自動的にアプリケーションを削除します。 各目標では、目的のプラグイン動作に固有のパラメーターを受け入れます。 コマンドラインからパラメーターを指定するには、パラメーター名の先頭に ​`-D`​ を追加します。 ### [](#package-goal)目標のパッケージ化 `package`​ 目標では、アプリケーションの JAR ファイルが生成されます。この目標は、デフォルトで Maven ライフサイクルフェーズ: `package`​ にバインドします。 省略可能なパラメーター
名前 型 説明

onlyMuleSources

boolean (ブール)

ソースコードのみが含まれるアプリケーションの JAR ファイルを生成します。このプロパティは共有のみに使用します。

attachMuleSources

boolean (ブール)

生成した JAR ファイル内にソースコードを添付します。

lightweightPackage

boolean (ブール)

JAR ファイル内のすべてのアプリケーションの連動関係が含まれるリポジトリを生成しません。このプロパティは共有のみに使用します。
たとえば、​`package`​ 目標を実行して ​`attachMuleSources`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn package -DattachMuleSources ``` ### [](#目標のデプロイ)目標のデプロイ この目標では、アプリケーションの JAR ファイルを任意のアプリケーションデプロイメント対象にアップロードしてデプロイします。deploy 目標は、デフォルトで Maven ライフサイクルフェーズ: `deploy`​ にバインドします。 省略可能なパラメーター
名前 型 説明

artifact

String (文字列)

アプリケーションの JAR ファイルをデプロイするパス。デフォルトでは、アプリケーションの ​target​ フォルダーに設定されます。

muleDeploy

boolean (ブール)

このプラグインに、プラグイン設定で定義されたデプロイメント戦略を使用してデプロイするよう指示します。​muleDeploy​ パラメーターが設定されていない場合、このプラグインで、アプリケーションの ​pom.xml​ ファイルの ​distributionManagement​ セクションで定義されたリポジトリにアーティファクトがアップロードされます。
たとえば、​`deploy`​ 目標を実行して ​`muleDeploy`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn deploy -DmuleDeploy ``` ### [](#muledeploy-目標)mule:deploy 目標 この目標を使用すると、アーティファクトを作成せずにデプロイできます。アーティファクトの場所を指定するには、​`mule.artifact`​ パラメーターを使用します。 次に例を示します。 ```console mvn mule:deploy -Dmule.artifact=myProject/myArtifact.jar ``` このプロパティは CloudHub、スタンドアロン、オンプレミスのデプロイメントに対して有効です。 ### [](#muleundeploy-目標)mule:undeploy 目標 この目標では、任意のアプリケーションデプロイメント対象からアプリケーションを削除します。プラグイン設定の情報を使用して、アプリケーションを定義されたデプロイメント対象から削除します。 `undeploy`​ 目標を実行するには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy 目標により、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する 操作を実行する前に、Mule Maven プラグインをプロジェクトに追加する必要があります。 Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。
<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
## [](#プラグイン実行のスキップ)プラグイン実行のスキップ デプロイメント設定内で ​`skip`​ パラメーターを true に設定することで、プラグイン実行をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} true ``` ## [](#デプロイメント検証のスキップ)デプロイメント検証のスキップ 任意のプラットフォームデプロイメント (Cloudhub、Runtime Manager、Runtime Fabric) 内で ​`skipDeploymentVerification`​ パラメーターを true に設定することで、状況検証をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ... true ... ``` `skipDeploymentVerification`​ パラメーターが存在しない場合、デフォルト値は false です。 この機能は、プラグインバージョン 3.2.5 以降で使用できます。 ## [](#configure-shared-libraries)共有ライブラリの設定 共有ライブラリでは、アプリケーションの連動関係を設定し、この連動関係をアプリケーション内のすべてのコネクタからアクセス可能にできます。 この機能の詳細な説明は、​[「Shared Libraries (共有ライブラリ)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#shared-libraries)​を参照してください。 連動関係を共有ライブラリとして設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${dependencyGroupID} ${dependencyArtifactID} ``` 次の例では、プロジェクトのデータベース用 Anypoint Connector (Database Connector) を設定し、さらに MySQL ドライバーを共有ライブラリとして設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} true mysql mysql-connector-java org.mule.connectors mule-db-connector 1.5.0 mule-plugin mysql mysql-connector-java 5.1.33 ``` ## [](#configure-plugin-dependencies)追加プラグイン連動関係の設定 アプリケーションのコネクタ用に追加プラグイン連動関係を設定すると、それらの連動関係はそのコネクタでのみ使用可能になります。これにより、異なるコネクタに対して、異なる連動関係や同じ連動関係の複数のバージョンさえ設定できます。 この機能の詳細な説明は、​[「Additional Plugin Dependencies (追加プラグイン連動関係)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#additional-plugin-dependencies)​を参照してください。 追加プラグイン連動関係を設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${connectorGroupID} ${connectorArtifactID} ${dependencyGroupID} ${dependencyArtifactID} ${dependencyVersion} ``` 次の例では、Derby ドライバーを Database Connector の連動関係として設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.mule.connectors mule-db-connector org.apache.derby derby 10.11.1.1 ``` ## [](#mule-maven-プラグインリファレンス)Mule Maven プラグインリファレンス 各デプロイメント戦略のパラメーターリファレンスへのリンクを以下に示します。 - [CloudHub デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-to-cloudhub#cloudhub-deploy-reference) - [Runtime Fabric デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-to-rtf#rtf-deploy-reference) - [スタンドアロンデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-on-premises#standalone-deploy-reference) - [Runtime Manager REST API デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-on-premises#arm-deploy-reference) - [Runtime Manager エージェントデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-on-premises#arm-agent-deploy-reference) ## [](#関連情報)関連情報 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-classloading-isolation) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.6/how-to-export-resources) - [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven) - [Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) - [Runtime Manager REST API](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-api) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) # Mule Maven プラグイン
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule Maven プラグインでは、Mule アプリケーションのパッケージおよびデプロイメントを Maven ライフサイクルと統合できます。 パッケージ化の手順は、​[「Mule アプリケーションをパッケージする」](https://docs.mulesoft.com/jp/mule-runtime/4.7/package-a-mule-application)​を参照してください。 Mule Maven プラグインは Mule Runtime Engine (Enterprise Edition) および Mule Kernel (Community Edition) と互換性があります。 Mule Maven プラグインを使用すれば、次のデプロイメント戦略のいずれかを使用して、CloudHub、CloudHub 2.0、または Anypoint Runtime Fabric への、もしくはオンプレミスでの Mule アプリケーションのデプロイメントを自動化できます。 - CloudHub デプロイメント Mule アプリケーションを CloudHub にデプロイします。 手順は、​[「CloudHub へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-to-cloudhub)​を参照してください。 - CloudHub 2.0 デプロイメント Mule アプリケーションを CloudHub 2.0 にデプロイします。 手順は、​[「CloudHub 2.0 へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-to-cloudhub-2)​を参照してください。 - Runtime Fabric デプロイメント Anypoint Runtime Fabric に Mule アプリケーションをデプロイします。 手順は、​[「Anypoint Runtime Fabric へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-to-rtf)​を参照してください。 - Runtime Manager REST API デプロイメント Runtime Manager REST API を使用してサーバーまたはサーバークラスターに Mule アプリケーションをデプロイします。 手順は、​[「Runtime Manager REST API を使用して Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-on-premises#mmp-deploy-arm)​を参照してください。 - Runtime Manager エージェントデプロイメント Runtime Manager エージェントを使用して Mule アプリケーションをデプロイします。 このデプロイメント戦略は、すべての Mule インスタンスが 1 つのアドレス空間にある場合のみ機能します。 手順は、​[「Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-on-premises#mmp-deploy-agent)​を参照してください。 - スタンドアロンランタイムデプロイメント マシンで実行中の Mule インスタンスに Mule アプリケーションをデプロイします。 手順は、​[「スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-on-premises#mmp-deploy-standalone)​を参照してください。 ## [](#互換性)互換性 - Mule 4.x - Anypoint Studio 7.x ## [](#mule-maven-プラグインの目標)Mule Maven プラグインの目標 Mule Maven プラグインには次の目標があります。 - `package` プロジェクトの jar ファイルを生成します。 - `deploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) で自動的にアプリケーションをアップロードして起動します。 - `mule:deploy` 指定された場所からアーティファクトをデプロイします。 - `mule:undeploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) から自動的にアプリケーションを削除します。 各目標では、目的のプラグイン動作に固有のパラメーターを受け入れます。 コマンドラインからパラメーターを指定するには、パラメーター名の先頭に ​`-D`​ を追加します。 ### [](#package-goal)目標のパッケージ化 `package`​ 目標では、アプリケーションの JAR ファイルが生成されます。この目標は、デフォルトで Maven ライフサイクルフェーズ: `package`​ にバインドします。 省略可能なパラメーター
名前 型 説明

onlyMuleSources

boolean (ブール)

ソースコードのみが含まれるアプリケーションの JAR ファイルを生成します。このプロパティは共有のみに使用します。

attachMuleSources

boolean (ブール)

生成した JAR ファイル内にソースコードを添付します。

lightweightPackage

boolean (ブール)

JAR ファイル内のすべてのアプリケーションの連動関係が含まれるリポジトリを生成しません。このプロパティは共有のみに使用します。
たとえば、​`package`​ 目標を実行して ​`attachMuleSources`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn package -DattachMuleSources ``` ### [](#目標のデプロイ)目標のデプロイ この目標では、アプリケーションの JAR ファイルを任意のアプリケーションデプロイメント対象にアップロードしてデプロイします。deploy 目標は、デフォルトで Maven ライフサイクルフェーズ: `deploy`​ にバインドします。 省略可能なパラメーター
名前 型 説明

artifact

String (文字列)

アプリケーションの JAR ファイルをデプロイするパス。デフォルトでは、アプリケーションの ​target​ フォルダーに設定されます。

muleDeploy

boolean (ブール)

このプラグインに、プラグイン設定で定義されたデプロイメント戦略を使用してデプロイするよう指示します。​muleDeploy​ パラメーターが設定されていない場合、このプラグインで、アプリケーションの ​pom.xml​ ファイルの ​distributionManagement​ セクションで定義されたリポジトリにアーティファクトがアップロードされます。
たとえば、​`deploy`​ 目標を実行して ​`muleDeploy`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn deploy -DmuleDeploy ``` ### [](#muledeploy-目標)mule:deploy 目標 この目標を使用すると、アーティファクトを作成せずにデプロイできます。アーティファクトの場所を指定するには、​`mule.artifact`​ パラメーターを使用します。 次に例を示します。 ```console mvn mule:deploy -Dmule.artifact=myProject/myArtifact.jar ``` このプロパティは CloudHub、スタンドアロン、オンプレミスのデプロイメントに対して有効です。 ### [](#muleundeploy-目標)mule:undeploy 目標 この目標では、任意のアプリケーションデプロイメント対象からアプリケーションを削除します。プラグイン設定の情報を使用して、アプリケーションを定義されたデプロイメント対象から削除します。 `undeploy`​ 目標を実行するには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy 目標により、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する 操作を実行する前に、Mule Maven プラグインをプロジェクトに追加する必要があります。 Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。
<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
## [](#プラグイン実行のスキップ)プラグイン実行のスキップ デプロイメント設定内で ​`skip`​ パラメーターを true に設定することで、プラグイン実行をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} true ``` ## [](#デプロイメント検証のスキップ)デプロイメント検証のスキップ 任意のプラットフォームデプロイメント (Cloudhub、Runtime Manager、Runtime Fabric) 内で ​`skipDeploymentVerification`​ パラメーターを true に設定することで、状況検証をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ... true ... ``` `skipDeploymentVerification`​ パラメーターが存在しない場合、デフォルト値は false です。 この機能は、プラグインバージョン 3.2.5 以降で使用できます。 ## [](#configure-shared-libraries)共有ライブラリの設定 共有ライブラリでは、アプリケーションの連動関係を設定し、この連動関係をアプリケーション内のすべてのコネクタからアクセス可能にできます。 この機能の詳細な説明は、​[「Shared Libraries (共有ライブラリ)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#shared-libraries)​を参照してください。 連動関係を共有ライブラリとして設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${dependencyGroupID} ${dependencyArtifactID} ``` 次の例では、プロジェクトのデータベース用 Anypoint Connector (Database Connector) を設定し、さらに MySQL ドライバーを共有ライブラリとして設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} true mysql mysql-connector-java org.mule.connectors mule-db-connector 1.5.0 mule-plugin mysql mysql-connector-java 5.1.33 ``` ## [](#configure-plugin-dependencies)追加プラグイン連動関係の設定 アプリケーションのコネクタ用に追加プラグイン連動関係を設定すると、それらの連動関係はそのコネクタでのみ使用可能になります。これにより、異なるコネクタに対して、異なる連動関係や同じ連動関係の複数のバージョンさえ設定できます。 この機能の詳細な説明は、​[「Additional Plugin Dependencies (追加プラグイン連動関係)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#additional-plugin-dependencies)​を参照してください。 追加プラグイン連動関係を設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${connectorGroupID} ${connectorArtifactID} ${dependencyGroupID} ${dependencyArtifactID} ${dependencyVersion} ``` 次の例では、Derby ドライバーを Database Connector の連動関係として設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.mule.connectors mule-db-connector org.apache.derby derby 10.11.1.1 ``` ## [](#mule-maven-プラグインリファレンス)Mule Maven プラグインリファレンス 各デプロイメント戦略のパラメーターリファレンスへのリンクを以下に示します。 - [CloudHub デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-to-cloudhub#cloudhub-deploy-reference) - [Runtime Fabric デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-to-rtf#rtf-deploy-reference) - [スタンドアロンデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-on-premises#standalone-deploy-reference) - [Runtime Manager REST API デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-on-premises#arm-deploy-reference) - [Runtime Manager エージェントデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-on-premises#arm-agent-deploy-reference) ## [](#関連情報)関連情報 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-classloading-isolation) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.7/how-to-export-resources) - [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven) - [Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) - [Runtime Manager REST API](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-api) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) # Mule Maven プラグイン
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule Maven プラグインでは、Mule アプリケーションのパッケージおよびデプロイメントを Maven ライフサイクルと統合できます。 パッケージ化の手順は、​[「Mule アプリケーションをパッケージする」](https://docs.mulesoft.com/jp/mule-runtime/4.8/package-a-mule-application)​を参照してください。 Mule Maven プラグインは Mule Runtime Engine (Enterprise Edition) および Mule Kernel (Community Edition) と互換性があります。 Mule Maven プラグインを使用すれば、次のデプロイメント戦略のいずれかを使用して、CloudHub、CloudHub 2.0、または Anypoint Runtime Fabric への、もしくはオンプレミスでの Mule アプリケーションのデプロイメントを自動化できます。 - CloudHub デプロイメント Mule アプリケーションを CloudHub にデプロイします。 手順は、​[「CloudHub へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-to-cloudhub)​を参照してください。 - CloudHub 2.0 デプロイメント Mule アプリケーションを CloudHub 2.0 にデプロイします。 手順は、​[「CloudHub 2.0 へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-to-cloudhub-2)​を参照してください。 - Runtime Fabric デプロイメント Anypoint Runtime Fabric に Mule アプリケーションをデプロイします。 手順は、​[「Anypoint Runtime Fabric へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-to-rtf)​を参照してください。 - Runtime Manager REST API デプロイメント Runtime Manager REST API を使用してサーバーまたはサーバークラスターに Mule アプリケーションをデプロイします。 手順は、​[「Runtime Manager REST API を使用して Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-on-premises#mmp-deploy-arm)​を参照してください。 - Runtime Manager エージェントデプロイメント Runtime Manager エージェントを使用して Mule アプリケーションをデプロイします。 このデプロイメント戦略は、すべての Mule インスタンスが 1 つのアドレス空間にある場合のみ機能します。 手順は、​[「Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-on-premises#mmp-deploy-agent)​を参照してください。 - スタンドアロンランタイムデプロイメント マシンで実行中の Mule インスタンスに Mule アプリケーションをデプロイします。 手順は、​[「スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-on-premises#mmp-deploy-standalone)​を参照してください。 ## [](#互換性)互換性 - Mule 4.x - Anypoint Studio 7.x ## [](#mule-maven-プラグインの目標)Mule Maven プラグインの目標 Mule Maven プラグインには次の目標があります。 - `package` プロジェクトの jar ファイルを生成します。 - `deploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) で自動的にアプリケーションをアップロードして起動します。 - `mule:deploy` 指定された場所からアーティファクトをデプロイします。 - `mule:undeploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) から自動的にアプリケーションを削除します。 各目標では、目的のプラグイン動作に固有のパラメーターを受け入れます。 コマンドラインからパラメーターを指定するには、パラメーター名の先頭に ​`-D`​ を追加します。 ### [](#package-goal)目標のパッケージ化 `package`​ 目標では、アプリケーションの JAR ファイルが生成されます。この目標は、デフォルトで Maven ライフサイクルフェーズ: `package`​ にバインドします。 省略可能なパラメーター
名前 型 説明

onlyMuleSources

boolean (ブール)

ソースコードのみが含まれるアプリケーションの JAR ファイルを生成します。このプロパティは共有のみに使用します。

attachMuleSources

boolean (ブール)

生成した JAR ファイル内にソースコードを添付します。

lightweightPackage

boolean (ブール)

JAR ファイル内のすべてのアプリケーションの連動関係が含まれるリポジトリを生成しません。このプロパティは共有のみに使用します。
たとえば、​`package`​ 目標を実行して ​`attachMuleSources`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn package -DattachMuleSources ``` ### [](#目標のデプロイ)目標のデプロイ この目標では、アプリケーションの JAR ファイルを任意のアプリケーションデプロイメント対象にアップロードしてデプロイします。deploy 目標は、デフォルトで Maven ライフサイクルフェーズ: `deploy`​ にバインドします。 省略可能なパラメーター
名前 型 説明

artifact

String (文字列)

アプリケーションの JAR ファイルをデプロイするパス。デフォルトでは、アプリケーションの ​target​ フォルダーに設定されます。

muleDeploy

boolean (ブール)

このプラグインに、プラグイン設定で定義されたデプロイメント戦略を使用してデプロイするよう指示します。​muleDeploy​ パラメーターが設定されていない場合、このプラグインで、アプリケーションの ​pom.xml​ ファイルの ​distributionManagement​ セクションで定義されたリポジトリにアーティファクトがアップロードされます。
たとえば、​`deploy`​ 目標を実行して ​`muleDeploy`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn deploy -DmuleDeploy ``` ### [](#muledeploy-目標)mule:deploy 目標 この目標を使用すると、アーティファクトを作成せずにデプロイできます。アーティファクトの場所を指定するには、​`mule.artifact`​ パラメーターを使用します。 次に例を示します。 ```console mvn mule:deploy -Dmule.artifact=myProject/myArtifact.jar ``` このプロパティは CloudHub、スタンドアロン、オンプレミスのデプロイメントに対して有効です。 ### [](#muleundeploy-目標)mule:undeploy 目標 この目標では、任意のアプリケーションデプロイメント対象からアプリケーションを削除します。プラグイン設定の情報を使用して、アプリケーションを定義されたデプロイメント対象から削除します。 `undeploy`​ 目標を実行するには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy 目標により、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する 操作を実行する前に、Mule Maven プラグインをプロジェクトに追加する必要があります。 Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。
<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
## [](#プラグイン実行のスキップ)プラグイン実行のスキップ デプロイメント設定内で ​`skip`​ パラメーターを true に設定することで、プラグイン実行をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} true ``` ## [](#デプロイメント検証のスキップ)デプロイメント検証のスキップ 任意のプラットフォームデプロイメント (Cloudhub、Runtime Manager、Runtime Fabric) 内で ​`skipDeploymentVerification`​ パラメーターを true に設定することで、状況検証をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ... true ... ``` `skipDeploymentVerification`​ パラメーターが存在しない場合、デフォルト値は false です。 この機能は、プラグインバージョン 3.2.5 以降で使用できます。 ## [](#configure-shared-libraries)共有ライブラリの設定 共有ライブラリでは、アプリケーションの連動関係を設定し、この連動関係をアプリケーション内のすべてのコネクタからアクセス可能にできます。 この機能の詳細な説明は、​[「Shared Libraries (共有ライブラリ)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#shared-libraries)​を参照してください。 連動関係を共有ライブラリとして設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${dependencyGroupID} ${dependencyArtifactID} ``` 次の例では、プロジェクトのデータベース用 Anypoint Connector (Database Connector) を設定し、さらに MySQL ドライバーを共有ライブラリとして設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} true mysql mysql-connector-java org.mule.connectors mule-db-connector 1.5.0 mule-plugin mysql mysql-connector-java 5.1.33 ``` ## [](#configure-plugin-dependencies)追加プラグイン連動関係の設定 アプリケーションのコネクタ用に追加プラグイン連動関係を設定すると、それらの連動関係はそのコネクタでのみ使用可能になります。これにより、異なるコネクタに対して、異なる連動関係や同じ連動関係の複数のバージョンさえ設定できます。 この機能の詳細な説明は、​[「Additional Plugin Dependencies (追加プラグイン連動関係)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#additional-plugin-dependencies)​を参照してください。 追加プラグイン連動関係を設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${connectorGroupID} ${connectorArtifactID} ${dependencyGroupID} ${dependencyArtifactID} ${dependencyVersion} ``` 次の例では、Derby ドライバーを Database Connector の連動関係として設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.mule.connectors mule-db-connector org.apache.derby derby 10.11.1.1 ``` ## [](#mule-maven-プラグインリファレンス)Mule Maven プラグインリファレンス 各デプロイメント戦略のパラメーターリファレンスへのリンクを以下に示します。 - [CloudHub デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-to-cloudhub#cloudhub-deploy-reference) - [Runtime Fabric デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-to-rtf#rtf-deploy-reference) - [スタンドアロンデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-on-premises#standalone-deploy-reference) - [Runtime Manager REST API デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-on-premises#arm-deploy-reference) - [Runtime Manager エージェントデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-on-premises#arm-agent-deploy-reference) ## [](#関連情報)関連情報 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-classloading-isolation) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.8/how-to-export-resources) - [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven) - [Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) - [Runtime Manager REST API](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-api) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) # Mule Maven プラグイン
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule Maven プラグインでは、Mule アプリケーションのパッケージおよびデプロイメントを Maven ライフサイクルと統合できます。 パッケージ化の手順は、​[「Mule アプリケーションをパッケージする」](https://docs.mulesoft.com/jp/mule-runtime/4.9/package-a-mule-application)​を参照してください。 Mule Maven プラグインは Mule Runtime Engine (Enterprise Edition) および Mule Kernel (Community Edition) と互換性があります。 Mule Maven プラグインを使用すれば、次のデプロイメント戦略のいずれかを使用して、CloudHub、CloudHub 2.0、または Anypoint Runtime Fabric への、もしくはオンプレミスでの Mule アプリケーションのデプロイメントを自動化できます。 - CloudHub デプロイメント Mule アプリケーションを CloudHub にデプロイします。 手順は、​[「CloudHub へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-to-cloudhub)​を参照してください。 - CloudHub 2.0 デプロイメント Mule アプリケーションを CloudHub 2.0 にデプロイします。 手順は、​[「CloudHub 2.0 へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-to-cloudhub-2)​を参照してください。 - Runtime Fabric デプロイメント Anypoint Runtime Fabric に Mule アプリケーションをデプロイします。 手順は、​[「Anypoint Runtime Fabric へのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-to-rtf)​を参照してください。 - Runtime Manager REST API デプロイメント Runtime Manager REST API を使用してサーバーまたはサーバークラスターに Mule アプリケーションをデプロイします。 手順は、​[「Runtime Manager REST API を使用して Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-on-premises#mmp-deploy-arm)​を参照してください。 - Runtime Manager エージェントデプロイメント Runtime Manager エージェントを使用して Mule アプリケーションをデプロイします。 このデプロイメント戦略は、すべての Mule インスタンスが 1 つのアドレス空間にある場合のみ機能します。 手順は、​[「Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-on-premises#mmp-deploy-agent)​を参照してください。 - スタンドアロンランタイムデプロイメント マシンで実行中の Mule インスタンスに Mule アプリケーションをデプロイします。 手順は、​[「スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-on-premises#mmp-deploy-standalone)​を参照してください。 ## [](#互換性)互換性 - Mule 4.x - Anypoint Studio 7.x ## [](#mule-maven-プラグインの目標)Mule Maven プラグインの目標 Mule Maven プラグインには次の目標があります。 - `package` プロジェクトの jar ファイルを生成します。 - `deploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) で自動的にアプリケーションをアップロードして起動します。 - `mule:deploy` 指定された場所からアーティファクトをデプロイします。 - `mule:undeploy` 任意のアプリケーションデプロイメント対象 (CloudHub、Runtime Fabric、またはオンプレミス) から自動的にアプリケーションを削除します。 各目標では、目的のプラグイン動作に固有のパラメーターを受け入れます。 コマンドラインからパラメーターを指定するには、パラメーター名の先頭に ​`-D`​ を追加します。 ### [](#package-goal)目標のパッケージ化 `package`​ 目標では、アプリケーションの JAR ファイルが生成されます。この目標は、デフォルトで Maven ライフサイクルフェーズ: `package`​ にバインドします。 省略可能なパラメーター
名前 型 説明

onlyMuleSources

boolean (ブール)

ソースコードのみが含まれるアプリケーションの JAR ファイルを生成します。このプロパティは共有のみに使用します。

attachMuleSources

boolean (ブール)

生成した JAR ファイル内にソースコードを添付します。

lightweightPackage

boolean (ブール)

JAR ファイル内のすべてのアプリケーションの連動関係が含まれるリポジトリを生成しません。このプロパティは共有のみに使用します。
たとえば、​`package`​ 目標を実行して ​`attachMuleSources`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn package -DattachMuleSources ``` ### [](#目標のデプロイ)目標のデプロイ この目標では、アプリケーションの JAR ファイルを任意のアプリケーションデプロイメント対象にアップロードしてデプロイします。deploy 目標は、デフォルトで Maven ライフサイクルフェーズ: `deploy`​ にバインドします。 省略可能なパラメーター
名前 型 説明

artifact

String (文字列)

アプリケーションの JAR ファイルをデプロイするパス。デフォルトでは、アプリケーションの ​target​ フォルダーに設定されます。

muleDeploy

boolean (ブール)

このプラグインに、プラグイン設定で定義されたデプロイメント戦略を使用してデプロイするよう指示します。​muleDeploy​ パラメーターが設定されていない場合、このプラグインで、アプリケーションの ​pom.xml​ ファイルの ​distributionManagement​ セクションで定義されたリポジトリにアーティファクトがアップロードされます。
たとえば、​`deploy`​ 目標を実行して ​`muleDeploy`​ パラメーターを設定するには、次のコマンドを実行します。 ```console mvn deploy -DmuleDeploy ``` ### [](#muledeploy-目標)mule:deploy 目標 この目標を使用すると、アーティファクトを作成せずにデプロイできます。アーティファクトの場所を指定するには、​`mule.artifact`​ パラメーターを使用します。 次に例を示します。 ```console mvn mule:deploy -Dmule.artifact=myProject/myArtifact.jar ``` このプロパティは CloudHub、スタンドアロン、オンプレミスのデプロイメントに対して有効です。 ### [](#muleundeploy-目標)mule:undeploy 目標 この目標では、任意のアプリケーションデプロイメント対象からアプリケーションを削除します。プラグイン設定の情報を使用して、アプリケーションを定義されたデプロイメント対象から削除します。 `undeploy`​ 目標を実行するには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy 目標により、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する 操作を実行する前に、Mule Maven プラグインをプロジェクトに追加する必要があります。 Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ``` このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。
<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
## [](#プラグイン実行のスキップ)プラグイン実行のスキップ デプロイメント設定内で ​`skip`​ パラメーターを true に設定することで、プラグイン実行をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} true ``` ## [](#デプロイメント検証のスキップ)デプロイメント検証のスキップ 任意のプラットフォームデプロイメント (Cloudhub、Runtime Manager、Runtime Fabric) 内で ​`skipDeploymentVerification`​ パラメーターを true に設定することで、状況検証をスキップできます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ... true ... ``` `skipDeploymentVerification`​ パラメーターが存在しない場合、デフォルト値は false です。 この機能は、プラグインバージョン 3.2.5 以降で使用できます。 ## [](#configure-shared-libraries)共有ライブラリの設定 共有ライブラリでは、アプリケーションの連動関係を設定し、この連動関係をアプリケーション内のすべてのコネクタからアクセス可能にできます。 この機能の詳細な説明は、​[「Shared Libraries (共有ライブラリ)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#shared-libraries)​を参照してください。 連動関係を共有ライブラリとして設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${dependencyGroupID} ${dependencyArtifactID} ``` 次の例では、プロジェクトのデータベース用 Anypoint Connector (Database Connector) を設定し、さらに MySQL ドライバーを共有ライブラリとして設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} true mysql mysql-connector-java org.mule.connectors mule-db-connector 1.5.0 mule-plugin mysql mysql-connector-java 5.1.33 ``` ## [](#configure-plugin-dependencies)追加プラグイン連動関係の設定 アプリケーションのコネクタ用に追加プラグイン連動関係を設定すると、それらの連動関係はそのコネクタでのみ使用可能になります。これにより、異なるコネクタに対して、異なる連動関係や同じ連動関係の複数のバージョンさえ設定できます。 この機能の詳細な説明は、​[「Additional Plugin Dependencies (追加プラグイン連動関係)」](https://docs.mulesoft.com/mule-runtime/latest/about-classloading-isolation#additional-plugin-dependencies)​を参照してください。 追加プラグイン連動関係を設定するには、プロジェクトの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内に次の要素を追加します。 ```xml ${connectorGroupID} ${connectorArtifactID} ${dependencyGroupID} ${dependencyArtifactID} ${dependencyVersion} ``` 次の例では、Derby ドライバーを Database Connector の連動関係として設定しています。 ```xml org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.mule.connectors mule-db-connector org.apache.derby derby 10.11.1.1 ``` ## [](#mule-maven-プラグインリファレンス)Mule Maven プラグインリファレンス 各デプロイメント戦略のパラメーターリファレンスへのリンクを以下に示します。 - [CloudHub デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-to-cloudhub#cloudhub-deploy-reference) - [Runtime Fabric デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-to-rtf#rtf-deploy-reference) - [スタンドアロンデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-on-premises#standalone-deploy-reference) - [Runtime Manager REST API デプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-on-premises#arm-deploy-reference) - [Runtime Manager エージェントデプロイメントのパラメーターリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-on-premises#arm-agent-deploy-reference) ## [](#関連情報)関連情報 - [クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-classloading-isolation) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.9/how-to-export-resources) - [Maven を使用した Exchange アセットのパブリッシュとデプロイ](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven) - [Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed) - [Runtime Manager REST API](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-api) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) # Mule Maven プラグインを使用した CloudHub 2.0 へのアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\]

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを CloudHub2.0 にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub 2.0 デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 ## [](#前提条件)前提条件 - Mule Maven プラグイン (バージョン 3.8.1) がプロジェクトに追加されている 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp)​を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 - Mule Maven Facade API (v3) がプロジェクトの POM ファイルの配布管理セクションにリポジトリとして追加されている。次に例を示します。 ```xml Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION_ID/maven default ``` 詳細は、 [Mule Maven Facade API ドキュメント](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/exchange-maven-facade-api-http/)​を参照してください。 ## [](#deploying-to-rtf)CloudHub 2.0 デプロイメント戦略の設定 `plugin`​ 要素内に CloudHub 2.0 デプロイメント用の設定を追加し、次のプレースホルダーの値を CloudHub 2.0 情報で置き換えます。 ```xml Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::example$mmp-concept-config.xml[] https://anypoint.mulesoft.com MC ${environment} ${targetName} ${muleVersion} ${user} ${pass} ${appName} 1 1 ${publicURL} true true ``` ## [](#cloudhub-2-0-へのデプロイ)CloudHub 2.0 へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean deploy -DmuleDeploy ``` アーティファクトを再ビルドすることなくデプロイするには、次のコマンドを実行します。 ```bash mvn mule:deploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange スナップショットアセットを CloudHub 2.0 にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされると、Mule Maven プラグインを介して ​`SNAPSHOT`​ バージョンのアプリケーションを CloudHub 2.0 に再デプロイすることで、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。 スナップショットアセットはデプロイ後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#cloudhub-2-0-への再デプロイ)CloudHub 2.0 への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 CloudHub 2.0 は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] 設定パラメーターの詳細は、​[CloudHub 2.0 デプロイメントのパラメーターリファレンス](#cloudhub2-deploy-reference)​を参照してください。 ## [](#cloudhub2-deploy-reference)CloudHub 2.0 デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

cloudhub2Deployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

CloudHub 2.0 インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.3.0​、​4.2.2-hf4

はい

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

scopeLoggingConfigurations

scopeLoggingConfiguration​

scope​

使用するログライブラリのパッケージ。

logLevel​

ログレベル。使用可能な値: INFO​、​DEBUG​、​WARN​、​ERROR​、​FATAL​。

設定例:

<scopeLoggingConfigurations>
  <scopeLoggingConfiguration>
    <scope>com.pkg.warning</scope>
    <logLevel>WARN</logLevel>
  </scopeLoggingConfiguration>
  <scopeLoggingConfiguration>
    <scope>com.pkg.debug</scope>
    <logLevel>DEBUG</logLevel>
  </scopeLoggingConfiguration>
</scopeLoggingConfigurations>

いいえ

target

アプリケーションをデプロイする CloudHub 2.0 対象名。
CloudHub 2.0 のデプロイメント対象値で使用できる共有スペースまたは非公開スペースのいずれかを指定します。共有スペースまたは非公開スペースについての詳細は、​「CloudHub 2.0 の機能」​を参照してください。​リージョンのリスト​の対象名値を使用します。例: Cloudhub-US-East-1​。

はい

provider

プロバイダー MC (MuleSoft コントロールプレーン) は、デプロイメントが Anypoint Runtime Manager を介して管理されていることを示します。CloudHub 2.0 では ​MC​ に設定します。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。

はい

vCores

vCores で指定されている各レプリカのサイズ。使用可能な値: 0.1​、​0.2​、​0.5​、​1​、​1.5​、​2​、​2.5​、​3​、​3.5​、​4​。 使用可能な vCore サイズと割り当てられるハードウェアリソースの詳細は、​「CloudHub 2.0 レプリカ」​を参照してください。

はい (​instanceType​ が設定されていない場合のみ) Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター。

いいえ

integrations

services​

objectStoreV2​

enabled​

​true​ の場合、Object Store v2 を使用するようにデプロイメントに指示します。

設定例:

<integrations>
  <services>
    <objectStoreV2>
      <enabled>true</enabled>
    </objectStoreV2>
  </services>
</integrations>

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。
可用性を高めるには、この値を ​true​ に設定します。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。複数のカンマ区切り値を追加できます。

pathRewrite​

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。この値は ​/​ で始まる必要があります。このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。

lastMileSecurity​

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.anypoint.com</publicUrl>
      <pathRewrite>/api</pathRewrite>
      <lastMileSecurity>true</lastMileSecurity>
      <forwardSslSession>true</forwardSslSession>
    </inbound>
  </http>
</deploymentSettings>

generateDefaultPublicUrl

true​ に設定されている場合、CloudHub 2.0 は、デプロイ済みアプリケーションの公開 URL を生成します。
このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。​共有スペース​にデプロイされたアプリケーションでは常に生成された公開 URL が使用されます。
## [](#ログイン情報の暗号化)ログイン情報の暗号化 Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] + ```xml ... ... ... my.anypoint.credentials ... ... ... ``` \+ NOTE: ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。 ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) # Mule Maven プラグインを使用した CloudHub 2.0 へのアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\]

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを CloudHub2.0 にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub 2.0 デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 ## [](#前提条件)前提条件 - Mule Maven プラグイン (バージョン 3.8.1) がプロジェクトに追加されている 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp)​を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 - Mule Maven Facade API (v3) がプロジェクトの POM ファイルの配布管理セクションにリポジトリとして追加されている。次に例を示します。 ```xml Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION_ID/maven default ``` 詳細は、 [Mule Maven Facade API ドキュメント](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/exchange-maven-facade-api-http/)​を参照してください。 ## [](#deploying-to-rtf)CloudHub 2.0 デプロイメント戦略の設定 `plugin`​ 要素内に CloudHub 2.0 デプロイメント用の設定を追加し、次のプレースホルダーの値を CloudHub 2.0 情報で置き換えます。 ```xml Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::example$mmp-concept-config.xml[] https://anypoint.mulesoft.com MC ${environment} ${targetName} ${muleVersion} ${user} ${pass} ${appName} 1 1 ${publicURL} true true ``` ## [](#cloudhub-2-0-へのデプロイ)CloudHub 2.0 へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean deploy -DmuleDeploy ``` アーティファクトを再ビルドすることなくデプロイするには、次のコマンドを実行します。 ```bash mvn mule:deploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange スナップショットアセットを CloudHub 2.0 にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされると、Mule Maven プラグインを介して ​`SNAPSHOT`​ バージョンのアプリケーションを CloudHub 2.0 に再デプロイすることで、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。 スナップショットアセットはデプロイメント後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#cloudhub-2-0-への再デプロイ)CloudHub 2.0 への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 CloudHub 2.0 は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] 設定パラメーターの詳細は、​[CloudHub 2.0 デプロイメントのパラメーターリファレンス](#cloudhub2-deploy-reference)​を参照してください。 ## [](#cloudhub2-deploy-reference)CloudHub 2.0 デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

cloudhub2Deployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

CloudHub 2.0 インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.5.0

はい

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

scopeLoggingConfigurations

scopeLoggingConfiguration​

scope​

使用するログライブラリのパッケージ。

logLevel​

ログレベル。使用可能な値: INFO​、​DEBUG​、​WARN​、​ERROR​、​FATAL​。

設定例:

<scopeLoggingConfigurations>
  <scopeLoggingConfiguration>
    <scope>com.pkg.warning</scope>
    <logLevel>WARN</logLevel>
  </scopeLoggingConfiguration>
  <scopeLoggingConfiguration>
    <scope>com.pkg.debug</scope>
    <logLevel>DEBUG</logLevel>
  </scopeLoggingConfiguration>
</scopeLoggingConfigurations>

いいえ

target

アプリケーションをデプロイする CloudHub 2.0 対象名。
CloudHub 2.0 のデプロイメント対象値で使用できる共有スペースまたは非公開スペースのいずれかを指定します。共有スペースまたは非公開スペースについての詳細は、​「CloudHub 2.0 の機能」​を参照してください。​リージョンのリスト​の対象名値を使用します。例: Cloudhub-US-East-1​。

はい

provider

プロバイダー MC (MuleSoft コントロールプレーン) は、デプロイメントが Anypoint Runtime Manager を介して管理されていることを示します。CloudHub 2.0 では ​MC​ に設定します。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。

はい

vCores

vCores で指定されている各レプリカのサイズ。使用可能な値: 0.1​、​0.2​、​0.5​、​1​、​1.5​、​2​、​2.5​、​3​、​3.5​、​4​。 使用可能な vCore サイズと割り当てられるハードウェアリソースの詳細は、​「CloudHub 2.0 レプリカ」​を参照してください。

はい (​instanceType​ が設定されていない場合のみ) Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター。

いいえ

integrations

services​

objectStoreV2​

enabled​

​true​ の場合、Object Store v2 を使用するようにデプロイメントに指示します。

設定例:

<integrations>
  <services>
    <objectStoreV2>
      <enabled>true</enabled>
    </objectStoreV2>
  </services>
</integrations>

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。
可用性を高めるには、この値を ​true​ に設定します。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。複数のカンマ区切り値を追加できます。

pathRewrite​

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。この値は ​/​ で始まる必要があります。このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。

lastMileSecurity​

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.anypoint.com</publicUrl>
      <pathRewrite>/api</pathRewrite>
      <lastMileSecurity>true</lastMileSecurity>
      <forwardSslSession>true</forwardSslSession>
    </inbound>
  </http>
</deploymentSettings>

generateDefaultPublicUrl

true​ に設定されている場合、CloudHub 2.0 は、デプロイ済みアプリケーションの公開 URL を生成します。
このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。​共有スペース​にデプロイされたアプリケーションでは常に生成された公開 URL が使用されます。

instanceType

アプリケーションデプロイメントのレプリカの容量を指定します。このフラグは、使用量ベースの価格設定 (UBP) パッケージを使用している組織でのみ利用できます。UBP 以外の組織では、代わりに ​vCores​ パラメーターを使用します。Anypoint Platform 価格設定を参照してください。
## [](#ログイン情報の暗号化)ログイン情報の暗号化 Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] + ```xml ... ... ... my.anypoint.credentials ... ... ... ``` \+ NOTE: ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。 ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) # Mule Maven プラグインを使用した CloudHub 2.0 へのアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\]

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを CloudHub2.0 にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub 2.0 デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 ## [](#始める前に)始める前に - Mule Maven プラグインがプロジェクトに追加されていることを確認する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp)​を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 - Mule Maven Facade API (v3) がプロジェクトの POM ファイルの配布管理セクションにリポジトリとして追加されている。次に例を示します。 ```xml Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION_ID/maven default ``` 詳細は、 [Mule Maven Facade API ドキュメント](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/exchange-maven-facade-api-http/)​を参照してください。 ## [](#deploying-to-rtf)CloudHub 2.0 デプロイメント戦略の設定 `plugin`​ 要素内に CloudHub 2.0 デプロイメント用の設定を追加し、次のプレースホルダーの値を CloudHub 2.0 情報で置き換えます。 ```xml Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::example$mmp-concept-config.xml[] https://anypoint.mulesoft.com MC ${environment} ${targetName} ${muleVersion} ${user} ${pass} ${appName} 1 1 ${publicURL} true true ``` ## [](#cloudhub-2-0-へのデプロイ)CloudHub 2.0 へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean deploy -DmuleDeploy ``` アーティファクトを再ビルドすることなくデプロイするには、次のコマンドを実行します。 ```bash mvn mule:deploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange スナップショットアセットを CloudHub 2.0 にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされると、Mule Maven プラグインを介して ​`SNAPSHOT`​ バージョンのアプリケーションを CloudHub 2.0 に再デプロイすることで、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。 スナップショットアセットはデプロイメント後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#cloudhub-2-0-への再デプロイ)CloudHub 2.0 への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 CloudHub 2.0 は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] 設定パラメーターの詳細は、​[CloudHub 2.0 デプロイメントのパラメーターリファレンス](#cloudhub2-deploy-reference)​を参照してください。 ## [](#cloudhub2-deploy-reference)CloudHub 2.0 デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

cloudhub2Deployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

CloudHub 2.0 インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。デフォルトでは、使用可能な最新の Mule バージョンが選択されます。
値の例: 4.6.0​ ではデフォルトで Edge チャネルと Java 8 になる最新のビルドが選択されます。異なる LTS または Edge の選択や Java バージョンを選択する場合は、​4.6.0:1e-java17​ のように完全な Mule バージョン名を指定します。
デプロイメントに Mule Maven プラグインバージョン 3.8.0 および 4.0.0 を使用している場合、​muleVersion​ プロパティで ​releaseChannel​ と ​javaVersion​ を指定できません。これらのプロパティを指定するには、プラグインをバージョン 4.1.1 以降にアップグレードします。
Mule Runtime 4.4 標準サポートは 2024 年 10 月に終了するため、新しい Mule アプリケーションは Mule 4.6 LTS または Mule 4.8 Edge にデプロイできます。お客様が Mule Maven プラグインバージョン 4.1.0 以前を使用している場合、LTS チャネルはサポートされないため、プラグインをバージョン 4.1.1 以降にアップグレードしてください。

いいえ

releaseChannel

Mule イメージを選択するために使用されるリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。デフォルトでは、この値は ​EDGE​ に設定されています。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

デプロイで使用される Java バージョンを設定します。サポートされている値は ​8​ と ​17​ です。デフォルトでは、この値は ​8​ に設定されています。選択された Java バージョンが存在しない場合、エラーが発生します。

いいえ

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

scopeLoggingConfigurations

scopeLoggingConfiguration​

scope​

使用するログライブラリのパッケージ。

logLevel​

ログレベル。使用可能な値: INFO​、​DEBUG​、​WARN​、​ERROR​、​FATAL​。

設定例:

<scopeLoggingConfigurations>
  <scopeLoggingConfiguration>
    <scope>com.pkg.warning</scope>
    <logLevel>WARN</logLevel>
  </scopeLoggingConfiguration>
  <scopeLoggingConfiguration>
    <scope>com.pkg.debug</scope>
    <logLevel>DEBUG</logLevel>
  </scopeLoggingConfiguration>
</scopeLoggingConfigurations>

いいえ

target

アプリケーションをデプロイする CloudHub 2.0 対象名。
CloudHub 2.0 のデプロイメント対象値で使用できる共有スペースまたは非公開スペースのいずれかを指定します。共有スペースまたは非公開スペースについての詳細は、​「CloudHub 2.0 の機能」​を参照してください。​リージョンのリスト​の対象名値を使用します。例: Cloudhub-US-East-1​。

はい

provider

プロバイダー MC (MuleSoft コントロールプレーン) は、デプロイメントが Anypoint Runtime Manager を介して管理されていることを示します。CloudHub 2.0 では ​MC​ に設定します。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。

はい

vCores

vCores で指定されている各レプリカのサイズ。使用可能な値: 0.1​、​0.2​、​0.5​、​1​、​1.5​、​2​、​2.5​、​3​、​3.5​、​4​。 使用可能な vCore サイズと割り当てられるハードウェアリソースの詳細は、​「CloudHub 2.0 レプリカ」​を参照してください。

はい (​instanceType​ が設定されていない場合のみ) Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター。

いいえ

integrations

services​

objectStoreV2​

enabled​

​true​ の場合、Object Store v2 を使用するようにデプロイメントに指示します。

設定例:

<integrations>
  <services>
    <objectStoreV2>
      <enabled>true</enabled>
    </objectStoreV2>
  </services>
</integrations>

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。
可用性を高めるには、この値を ​true​ に設定します。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。複数のカンマ区切り値を追加できます。

pathRewrite​

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。この値は ​/​ で始まる必要があります。このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。

lastMileSecurity​

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.anypoint.com</publicUrl>
      <pathRewrite>/api</pathRewrite>
      <lastMileSecurity>true</lastMileSecurity>
      <forwardSslSession>true</forwardSslSession>
    </inbound>
  </http>
</deploymentSettings>

generateDefaultPublicUrl

true​ に設定されている場合、CloudHub 2.0 は、デプロイ済みアプリケーションの公開 URL を生成します。
このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。​共有スペース​にデプロイされたアプリケーションでは常に生成された公開 URL が使用されます。

instanceType

アプリケーションデプロイメントのレプリカの容量を指定します。このフラグは、使用量ベースの価格設定 (UBP) パッケージを使用している組織でのみ利用できます。UBP 以外の組織では、代わりに ​vCores​ パラメーターを使用します。Anypoint Platform 価格設定を参照してください。
## [](#ログイン情報の暗号化)ログイン情報の暗号化 Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] + ```xml ... ... ... my.anypoint.credentials ... ... ... ``` \+ NOTE: ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。 ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) # Mule Maven プラグインを使用した CloudHub 2.0 へのアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\]

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを CloudHub2.0 にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub 2.0 デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 ## [](#始める前に)始める前に - Mule Maven プラグインがプロジェクトに追加されていることを確認する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp)​を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 - Mule Maven Facade API (v3) がプロジェクトの POM ファイルの配布管理セクションにリポジトリとして追加されている。次に例を示します。 ```xml Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION_ID/maven default ``` 詳細は、 [Mule Maven Facade API ドキュメント](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/exchange-maven-facade-api-http/)​を参照してください。 ## [](#deploying-to-rtf)CloudHub 2.0 デプロイメント戦略の設定 `plugin`​ 要素内に CloudHub 2.0 デプロイメント用の設定を追加し、次のプレースホルダーの値を CloudHub 2.0 情報で置き換えます。 ```xml Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::example$mmp-concept-config.xml[] https://anypoint.mulesoft.com MC ${environment} ${targetName} ${muleVersion} ${user} ${pass} ${appName} 1 1 ${publicURL} true true ``` ## [](#cloudhub-2-0-へのデプロイ)CloudHub 2.0 へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean deploy -DmuleDeploy ``` アーティファクトを再ビルドすることなくデプロイするには、次のコマンドを実行します。 ```bash mvn mule:deploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange スナップショットアセットを CloudHub 2.0 にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされると、Mule Maven プラグインを介して ​`SNAPSHOT`​ バージョンのアプリケーションを CloudHub 2.0 に再デプロイすることで、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。

スナップショットアセットはデプロイメント後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#cloudhub-2-0-への再デプロイ)CloudHub 2.0 への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 CloudHub 2.0 は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] 設定パラメーターの詳細は、​[CloudHub 2.0 デプロイメントのパラメーターリファレンス](#cloudhub2-deploy-reference)​を参照してください。 ## [](#cloudhub2-deploy-reference)CloudHub 2.0 デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

cloudhub2Deployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

CloudHub 2.0 インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。デフォルトでは、使用可能な最新の Mule バージョンが選択されます。
値の例: 4.6.0​ ではデフォルトで Edge チャネルと Java 8 になる最新のビルドが選択されます。異なる LTS または Edge の選択や Java バージョンを選択する場合は、​4.6.0:1e-java17​ のように完全な Mule バージョン名を指定します。
デプロイメントに Mule Maven プラグインバージョン 3.8.0 および 4.0.0 を使用している場合、​muleVersion​ プロパティで ​releaseChannel​ と ​javaVersion​ を指定できません。これらのプロパティを指定するには、プラグインをバージョン 4.1.1 以降にアップグレードします。
Mule Runtime 4.4 標準サポートは 2024 年 10 月に終了するため、新しい Mule アプリケーションは Mule 4.6 LTS または Mule 4.8 Edge にデプロイできます。お客様が Mule Maven プラグインバージョン 4.1.0 以前を使用している場合、LTS チャネルはサポートされないため、プラグインをバージョン 4.1.1 以降にアップグレードしてください。

いいえ

releaseChannel

Mule イメージを選択するために使用されるリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。デフォルトでは、この値は ​EDGE​ に設定されています。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

デプロイで使用される Java バージョンを設定します。サポートされている値は ​8​ と ​17​ です。デフォルトでは、この値は ​8​ に設定されています。選択された Java バージョンが存在しない場合、エラーが発生します。

いいえ

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

scopeLoggingConfigurations

scopeLoggingConfiguration​

scope​

使用するログライブラリのパッケージ。

logLevel​

ログレベル。使用可能な値: INFO​、​DEBUG​、​WARN​、​ERROR​、​FATAL​。

設定例:

<scopeLoggingConfigurations>
  <scopeLoggingConfiguration>
    <scope>com.pkg.warning</scope>
    <logLevel>WARN</logLevel>
  </scopeLoggingConfiguration>
  <scopeLoggingConfiguration>
    <scope>com.pkg.debug</scope>
    <logLevel>DEBUG</logLevel>
  </scopeLoggingConfiguration>
</scopeLoggingConfigurations>

いいえ

target

アプリケーションをデプロイする CloudHub 2.0 対象名。
CloudHub 2.0 のデプロイメント対象値で使用できる共有スペースまたは非公開スペースのいずれかを指定します。共有スペースまたは非公開スペースについての詳細は、​「CloudHub 2.0 の機能」​を参照してください。​リージョンのリスト​の対象名値を使用します。例: Cloudhub-US-East-1​。

はい

provider

プロバイダー MC (MuleSoft コントロールプレーン) は、デプロイメントが Anypoint Runtime Manager を介して管理されていることを示します。CloudHub 2.0 では ​MC​ に設定します。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。

autoscaling​ が ​false​ に設定されている場合のみ。

vCores

vCores で指定されている各レプリカのサイズ。使用可能な値: 0.1​、​0.2​、​0.5​、​1​、​1.5​、​2​、​2.5​、​3​、​3.5​、​4​。 使用可能な vCore サイズと割り当てられるハードウェアリソースの詳細は、​「CloudHub 2.0 レプリカ」​を参照してください。
instanceType​ を設定する場合、このパラメーターは使用できません。

はい (​instanceType​ が設定されていない場合のみ) Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

properties

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

アプリケーションを再デプロイする必要があり、デプロイメントの POM ファイルで設定されたプロパティがない場合、CloudHub 2.0 環境の既存のプロパティが保持されます。POM ファイルでプロパティが定義されている場合、アプリケーションはそれらのプロパティを使用してデプロイされるため、UI で設定されたプロパティは上書きされます。

いいえ Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター。

いいえ

integrations

services​

objectStoreV2​

enabled​

​true​ の場合、Object Store v2 を使用するようにデプロイメントに指示します。

設定例:

<integrations>
  <services>
    <objectStoreV2>
      <enabled>true</enabled>
    </objectStoreV2>
  </services>
</integrations>

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。
可用性を高めるには、この値を ​true​ に設定します。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。複数のカンマ区切り値を追加できます。

pathRewrite​

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。この値は ​/​ で始まる必要があります。このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。

lastMileSecurity​

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.anypoint.com</publicUrl>
      <pathRewrite>/api</pathRewrite>
      <lastMileSecurity>true</lastMileSecurity>
      <forwardSslSession>true</forwardSslSession>
    </inbound>
  </http>
</deploymentSettings>

generateDefaultPublicUrl

true​ に設定されている場合、CloudHub 2.0 は、デプロイ済みアプリケーションの公開 URL を生成します。
このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。​共有スペース​にデプロイされたアプリケーションでは常に生成された公開 URL が使用されます。

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションレベルログの転送を無効にします。デフォルト値は ​false​ です。

tracingEnabled

Mule Runtime の OpenTelemetry 標準のトレース情報をすべての APM ソリューションに公開します。cloudhub-2::ch2-deploy-private-space.adoc#enable-trace-data-collectionを参照してください。

autoscaling

デプロイメントおよび再デプロイメント操作で CPU ベースの水平自動スケーリング設定を指定します。autoscaling が無効になっていて、​minReplicas​ および ​maxReplicas​ 項目が指定されている場合、それらは ​target.replicas​ 項目の値と一致している必要があります。​「トレースデータ収集の有効化」​を参照してください。 設定例:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>

persistentObjectStore

永続的なオブジェクトストアを使用するように Mule アプリケーションを設定します。デフォルトでは、これは ​false​ に設定されます。

instanceType

アプリケーションデプロイメントのレプリカの容量を指定します。このフラグは、使用量ベースの価格設定 (UBP) パッケージを使用している組織でのみ利用できます。UBP 以外の組織では、代わりに ​vCores​ パラメーターを使用します。Anypoint Platform 価格設定を参照してください。
## [](#ログイン情報の暗号化)ログイン情報の暗号化 Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] + ```xml ... ... ... my.anypoint.credentials ... ... ... ``` \+ NOTE: ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。 ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) # Mule Maven プラグインを使用した CloudHub 2.0 へのアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\]

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを CloudHub2.0 にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub 2.0 デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 ## [](#始める前に)始める前に - Mule Maven プラグインがプロジェクトに追加されていることを確認する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp)​を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 - Mule Maven Facade API (v3) がプロジェクトの POM ファイルの配布管理セクションにリポジトリとして追加されている。次に例を示します。 ```xml Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION_ID/maven default ``` 詳細は、 [Mule Maven Facade API ドキュメント](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/exchange-maven-facade-api-http/)​を参照してください。 ## [](#deploying-to-rtf)CloudHub 2.0 デプロイメント戦略の設定 `plugin`​ 要素内に CloudHub 2.0 デプロイメント用の設定を追加し、次のプレースホルダーの値を CloudHub 2.0 情報で置き換えます。 ```xml Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::example$mmp-concept-config.xml[] https://anypoint.mulesoft.com MC ${environment} ${targetName} ${muleVersion} ${user} ${pass} ${appName} 1 1 ${publicURL} true true ``` ## [](#cloudhub-2-0-へのデプロイ)CloudHub 2.0 へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean deploy -DmuleDeploy ``` アーティファクトを再ビルドすることなくデプロイするには、次のコマンドを実行します。 ```bash mvn mule:deploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange スナップショットアセットを CloudHub 2.0 にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされると、Mule Maven プラグインを介して ​`SNAPSHOT`​ バージョンのアプリケーションを CloudHub 2.0 に再デプロイすることで、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。

スナップショットアセットはデプロイメント後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#cloudhub-2-0-への再デプロイ)CloudHub 2.0 への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 CloudHub 2.0 は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] 設定パラメーターの詳細は、​[CloudHub 2.0 デプロイメントのパラメーターリファレンス](#cloudhub2-deploy-reference)​を参照してください。 ## [](#cloudhub2-deploy-reference)CloudHub 2.0 デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

cloudhub2Deployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

CloudHub 2.0 インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。デフォルトでは、使用可能な最新の Mule バージョンが選択されます。
値の例: 4.6.0​ ではデフォルトで Edge チャネルと Java 8 になる最新のビルドが選択されます。異なる LTS または Edge の選択や Java バージョンを選択する場合は、​4.6.0:1e-java17​ のように完全な Mule バージョン名を指定します。
デプロイメントに Mule Maven プラグインバージョン 3.8.0 および 4.0.0 を使用している場合、​muleVersion​ プロパティで ​releaseChannel​ と ​javaVersion​ を指定できません。これらのプロパティを指定するには、プラグインをバージョン 4.1.1 以降にアップグレードします。
Mule Runtime 4.4 標準サポートは 2024 年 10 月に終了するため、新しい Mule アプリケーションは Mule 4.6 LTS または Mule 4.8 Edge にデプロイできます。お客様が Mule Maven プラグインバージョン 4.1.0 以前を使用している場合、LTS チャネルはサポートされないため、プラグインをバージョン 4.1.1 以降にアップグレードしてください。

いいえ

releaseChannel

Mule イメージを選択するために使用されるリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。デフォルトでは、この値は ​EDGE​ に設定されています。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

デプロイで使用される Java バージョンを設定します。サポートされている値は ​8​ と ​17​ です。デフォルトでは、この値は ​8​ に設定されています。選択された Java バージョンが存在しない場合、エラーが発生します。

いいえ

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

scopeLoggingConfigurations

scopeLoggingConfiguration​

scope​

使用するログライブラリのパッケージ。

logLevel​

ログレベル。使用可能な値: INFO​、​DEBUG​、​WARN​、​ERROR​、​FATAL​。

設定例:

<scopeLoggingConfigurations>
  <scopeLoggingConfiguration>
    <scope>com.pkg.warning</scope>
    <logLevel>WARN</logLevel>
  </scopeLoggingConfiguration>
  <scopeLoggingConfiguration>
    <scope>com.pkg.debug</scope>
    <logLevel>DEBUG</logLevel>
  </scopeLoggingConfiguration>
</scopeLoggingConfigurations>

いいえ

target

アプリケーションをデプロイする CloudHub 2.0 対象名。
CloudHub 2.0 のデプロイメント対象値で使用できる共有スペースまたは非公開スペースのいずれかを指定します。共有スペースまたは非公開スペースについての詳細は、​「CloudHub 2.0 の機能」​を参照してください。​リージョンのリスト​の対象名値を使用します。例: Cloudhub-US-East-1​。

はい

provider

プロバイダー MC (MuleSoft コントロールプレーン) は、デプロイメントが Anypoint Runtime Manager を介して管理されていることを示します。CloudHub 2.0 では ​MC​ に設定します。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。

autoscaling​ が ​false​ に設定されている場合のみ。

vCores

vCores で指定されている各レプリカのサイズ。使用可能な値: 0.1​、​0.2​、​0.5​、​1​、​1.5​、​2​、​2.5​、​3​、​3.5​、​4​。 使用可能な vCore サイズと割り当てられるハードウェアリソースの詳細は、​「CloudHub 2.0 レプリカ」​を参照してください。
instanceType​ を設定する場合、このパラメーターは使用できません。

はい (​instanceType​ が設定されていない場合のみ) Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

properties

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

アプリケーションを再デプロイする必要があり、デプロイメントの POM ファイルで設定されたプロパティがない場合、CloudHub 2.0 環境の既存のプロパティが保持されます。POM ファイルでプロパティが定義されている場合、アプリケーションはそれらのプロパティを使用してデプロイされるため、UI で設定されたプロパティは上書きされます。

いいえ Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター。

いいえ

integrations

services​

objectStoreV2​

enabled​

​true​ の場合、Object Store v2 を使用するようにデプロイメントに指示します。

設定例:

<integrations>
  <services>
    <objectStoreV2>
      <enabled>true</enabled>
    </objectStoreV2>
  </services>
</integrations>

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。
可用性を高めるには、この値を ​true​ に設定します。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。複数のカンマ区切り値を追加できます。

pathRewrite​

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。この値は ​/​ で始まる必要があります。このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。

lastMileSecurity​

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.anypoint.com</publicUrl>
      <pathRewrite>/api</pathRewrite>
      <lastMileSecurity>true</lastMileSecurity>
      <forwardSslSession>true</forwardSslSession>
    </inbound>
  </http>
</deploymentSettings>

generateDefaultPublicUrl

true​ に設定されている場合、CloudHub 2.0 は、デプロイ済みアプリケーションの公開 URL を生成します。
このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。​共有スペース​にデプロイされたアプリケーションでは常に生成された公開 URL が使用されます。

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションレベルログの転送を無効にします。デフォルト値は ​false​ です。

tracingEnabled

Mule Runtime の OpenTelemetry 標準のトレース情報をすべての APM ソリューションに公開します。cloudhub-2::ch2-deploy-private-space.adoc#enable-trace-data-collectionを参照してください。

autoscaling

デプロイメントおよび再デプロイメント操作で CPU ベースの水平自動スケーリング設定を指定します。autoscaling が無効になっていて、​minReplicas​ および ​maxReplicas​ 項目が指定されている場合、それらは ​target.replicas​ 項目の値と一致している必要があります。​「トレースデータ収集の有効化」​を参照してください。 設定例:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>

persistentObjectStore

永続的なオブジェクトストアを使用するように Mule アプリケーションを設定します。デフォルトでは、これは ​false​ に設定されます。

instanceType

アプリケーションデプロイメントのレプリカの容量を指定します。このフラグは、使用量ベースの価格設定 (UBP) パッケージを使用している組織でのみ利用できます。UBP 以外の組織では、代わりに ​vCores​ パラメーターを使用します。Anypoint Platform 価格設定を参照してください。
## [](#ログイン情報の暗号化)ログイン情報の暗号化 Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-cloudhub-2.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] + ```xml ... ... ... my.anypoint.credentials ... ... ... ``` \+ NOTE: ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。 ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) # Mule Maven プラグインを使用した CloudHub 2.0 へのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを CloudHub2.0 にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub 2.0 デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 ## [](#始める前に)始める前に - Mule Maven プラグインがプロジェクトに追加されていることを確認する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp)​を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 - Mule Maven Facade API (v3) がプロジェクトの POM ファイルの配布管理セクションにリポジトリとして追加されている。次に例を示します。 ```xml Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION_ID/maven default ``` 詳細は、 [Mule Maven Facade API ドキュメント](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/exchange-maven-facade-api-http/)​を参照してください。 ## [](#deploying-to-rtf)CloudHub 2.0 デプロイメント戦略の設定 `plugin`​ 要素内に CloudHub 2.0 デプロイメント用の設定を追加し、次のプレースホルダーの値を CloudHub 2.0 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com MC ${environment} ${targetName} ${muleVersion} ${user} ${pass} ${appName} 1 1 ${publicURL} true true ``` ## [](#cloudhub-2-0-へのデプロイ)CloudHub 2.0 へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean deploy -DmuleDeploy ``` アーティファクトを再ビルドすることなくデプロイするには、次のコマンドを実行します。 ```bash mvn mule:deploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange スナップショットアセットを CloudHub 2.0 にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされると、Mule Maven プラグインを介して ​`SNAPSHOT`​ バージョンのアプリケーションを CloudHub 2.0 に再デプロイすることで、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。

スナップショットアセットはデプロイメント後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#cloudhub-2-0-への再デプロイ)CloudHub 2.0 への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 CloudHub 2.0 は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

CloudHub 2.0 のユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[CloudHub 2.0 デプロイメントのパラメーターリファレンス](#cloudhub2-deploy-reference)​を参照してください。 ## [](#cloudhub2-deploy-reference)CloudHub 2.0 デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

cloudhub2Deployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

CloudHub 2.0 インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。デフォルトでは、使用可能な最新の Mule バージョンが選択されます。
値の例: 4.6.0​ ではデフォルトで Edge チャネルと Java 8 になる最新のビルドが選択されます。異なる LTS または Edge の選択や Java バージョンを選択する場合は、​4.6.0:1e-java17​ のように完全な Mule バージョン名を指定します。
デプロイメントに Mule Maven プラグインバージョン 3.8.0 および 4.0.0 を使用している場合、​muleVersion​ プロパティで ​releaseChannel​ と ​javaVersion​ を指定できません。これらのプロパティを指定するには、プラグインをバージョン 4.1.1 以降にアップグレードします。
Mule Runtime 4.4 標準サポートは 2024 年 10 月に終了するため、新しい Mule アプリケーションは Mule 4.6 LTS または Mule 4.8 Edge にデプロイできます。お客様が Mule Maven プラグインバージョン 4.1.0 以前を使用している場合、LTS チャネルはサポートされないため、プラグインをバージョン 4.1.1 以降にアップグレードしてください。

いいえ

releaseChannel

Mule イメージを選択するために使用されるリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。デフォルトでは、この値は ​EDGE​ に設定されています。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

デプロイで使用される Java バージョンを設定します。サポートされている値は ​8​ と ​17​ です。デフォルトでは、この値は ​8​ に設定されています。選択された Java バージョンが存在しない場合、エラーが発生します。

いいえ

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

scopeLoggingConfigurations

scopeLoggingConfiguration​

scope​

使用するログライブラリのパッケージ。

logLevel​

ログレベル。使用可能な値: INFO​、​DEBUG​、​WARN​、​ERROR​、​FATAL​。

設定例:

<scopeLoggingConfigurations>
  <scopeLoggingConfiguration>
    <scope>com.pkg.warning</scope>
    <logLevel>WARN</logLevel>
  </scopeLoggingConfiguration>
  <scopeLoggingConfiguration>
    <scope>com.pkg.debug</scope>
    <logLevel>DEBUG</logLevel>
  </scopeLoggingConfiguration>
</scopeLoggingConfigurations>

いいえ

target

アプリケーションをデプロイする CloudHub 2.0 対象名。
CloudHub 2.0 のデプロイメント対象値で使用できる共有スペースまたは非公開スペースのいずれかを指定します。共有スペースまたは非公開スペースについての詳細は、​「CloudHub 2.0 の機能」​を参照してください。​リージョンのリスト​の対象名値を使用します。例: Cloudhub-US-East-1​。

はい

provider

プロバイダー MC (MuleSoft コントロールプレーン) は、デプロイメントが Anypoint Runtime Manager を介して管理されていることを示します。CloudHub 2.0 では ​MC​ に設定します。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。

autoscaling​ が ​false​ に設定されている場合のみ。

vCores

vCores で指定されている各レプリカのサイズ。使用可能な値: 0.1​、​0.2​、​0.5​、​1​、​1.5​、​2​、​2.5​、​3​、​3.5​、​4​。 使用可能な vCore サイズと割り当てられるハードウェアリソースの詳細は、​「CloudHub 2.0 レプリカ」​を参照してください。
instanceType​ を設定する場合、このパラメーターは使用できません。

はい (​instanceType​ が設定されていない場合のみ)

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

properties

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

アプリケーションを再デプロイする必要があり、デプロイメントの POM ファイルで設定されたプロパティがない場合、CloudHub 2.0 環境の既存のプロパティが保持されます。POM ファイルでプロパティが定義されている場合、アプリケーションはそれらのプロパティを使用してデプロイされるため、UI で設定されたプロパティは上書きされます。

いいえ

​secureProperties​

最上位要素
secureProperties​ 最上位要素を使用して Mule アプリケーションのプロパティを設定し、値を保存する前に暗号化するように CloudHub 2.0 に指示します。

<secureProperties>
  <key>value</key>
</secureProperties>

次に例を示します。

<secureProperties>
  <http.port>8081</http.port>
</secureProperties>

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター。

いいえ

integrations

services​

objectStoreV2​

enabled​

​true​ の場合、Object Store v2 を使用するようにデプロイメントに指示します。

設定例:

<integrations>
  <services>
    <objectStoreV2>
      <enabled>true</enabled>
    </objectStoreV2>
  </services>
</integrations>

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。
可用性を高めるには、この値を ​true​ に設定します。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。複数のカンマ区切り値を追加できます。

pathRewrite​

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。この値は ​/​ で始まる必要があります。このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。

lastMileSecurity​

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.anypoint.com</publicUrl>
      <pathRewrite>/api</pathRewrite>
      <lastMileSecurity>true</lastMileSecurity>
      <forwardSslSession>true</forwardSslSession>
    </inbound>
  </http>
</deploymentSettings>

generateDefaultPublicUrl

true​ に設定されている場合、CloudHub 2.0 は、デプロイ済みアプリケーションの公開 URL を生成します。
このパラメーターは、​非公開スペース​にデプロイされたアプリケーションでのみ使用されます。​共有スペース​にデプロイされたアプリケーションでは常に生成された公開 URL が使用されます。

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションレベルログの転送を無効にします。デフォルト値は ​false​ です。

tracingEnabled

Mule Runtime の OpenTelemetry 標準のトレース情報をすべての APM ソリューションに公開します。cloudhub-2::ch2-deploy-private-space.adoc#enable-trace-data-collectionを参照してください。

autoscaling

デプロイメントおよび再デプロイメント操作で CPU ベースの水平自動スケーリング設定を指定します。autoscaling が無効になっていて、​minReplicas​ および ​maxReplicas​ 項目が指定されている場合、それらは ​target.replicas​ 項目の値と一致している必要があります。​「トレースデータ収集の有効化」​を参照してください。 設定例:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>

persistentObjectStore

永続的なオブジェクトストアを使用するように Mule アプリケーションを設定します。デフォルトでは、これは ​false​ に設定されます。

instanceType

アプリケーションデプロイメントのレプリカの容量を指定します。このフラグは、使用量ベースの価格設定 (UBP) パッケージを使用している組織でのみ利用できます。UBP 以外の組織では、代わりに ​vCores​ パラメーターを使用します。Anypoint Platform 価格設定を参照してください。
## [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) # Mule Maven プラグインを使用した CloudHub へのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションを CloudHub にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイ、再デプロイ、アンデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して CloudHub にアプリケーションをデプロイする場合は、以下を参照してください。 - [Anypoint Studio を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/deploy-mule-application-task) - [Anypoint CLI を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/cloudhub-apps#deploy-to-cloudhub) - [Runtime Manager を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub) ## [](#前提条件)前提条件 Mule Maven プラグインを使用して CloudHub にデプロイする前に、次のタスクを完了する必要があります。 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept#add-mmp)​を参照してください。 - HTTP Listener をフローのソースとして使用している場合、そのホストを ​**0.0.0.0**​ に、そのポートを ​**${http.port}**​ に設定する必要があります。 - すべての外部クラスおよびリソースを ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ および ​`exportedResources`​ 項目で宣言する ## [](#cloudhub-デプロイメント戦略の設定)CloudHub デプロイメント戦略の設定 Mule Maven プラグインを使用して Mule アプリケーションをデプロイ、再デプロイ、アンデプロイできるようにプロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定します。 プロジェクトの ​`pom.xml`​ ファイルの ​`plugin`​ 要素内で CloudHub デプロイメントを設定し、プレースホルダーの値を CloudHub 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.4.2 true https://anypoint.mulesoft.com ${app.runtime} ${username} ${password} ${cloudhub.application.name} ${environment} ${region} ${workers} ${workerType} value ``` ## [](#cloudhub-へのデプロイ)CloudHub へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean package deploy -DmuleDeploy ``` ## [](#cloudhub-への再デプロイ)CloudHub への再デプロイ Mule Maven プラグインを使用して Mule アプリケーションを再デプロイするには、以前にアプリケーションをデプロイしたときと同様に ​`mvn clean package deploy -DmuleDeploy`​ を実行します。CloudHub は、デプロイしたアプリケーションを書き込み直します。 ## [](#cloudhub-からのアンデプロイ)CloudHub からのアンデプロイ Mule Maven プラグインを使用して Mule アプリケーションをアンデプロイするには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy コマンドにより、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

CloudHub のユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[CloudHub デプロイメントリファレンス](#cloudhub-deploy-reference)​を参照してください。 ## [](#cloudhub-deploy-reference)CloudHub デプロイメントリファレンス 次の表に、プロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定するための使用可能なパラメーターを示します。
パラメーター 説明 必須

cloudHubDeployment

最上位要素

はい

uri

Anypoint Platform の URI
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

muleVersion

CloudHub インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.3.0​、​4.2.2-hf4

はい

username

CloudHub ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

CloudHub パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

CloudHub 内のアプリケーションの名前
この名前は、デプロイされるアプリケーションのドメインの一部です。たとえば、アプリケーションに application-1 という名前を付けると、アプリケーションの公開ドメインは application-1.cloudhub.io となります。

はい

artifact

デプロイする JAR ファイルの絶対パス
設定しない場合、パスはデフォルトで、パッケージフェーズで生成された JAR ファイルの位置になります。

いいえ

environment

デプロイ先の CloudHub 環境
この値は、CloudHub アカウントで設定されたいずれかの環境に一致する必要があります。

<environment>Sandbox</environment>

はい

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

workers

ワーカーの数
デフォルトでは、この値は 1 です。

いいえ

workerType

各ワーカーのサイズ (次のいずれかの値)

  • MICRO​ (デフォルト、0.1 vCore)

  • SMALL​ (0.2 vCore)

  • MEDIUM​ (1 vCore)

  • LARGE​ (2 vCore)

  • XLARGE​ (4 vCore)

  • XXLARGE​ (8 vCore)

  • 4XLARGE​ (16 vCore)

いいえ

region

ワーカークラウドの地域 (次のいずれかの値)

  • us-east-1​ (デフォルト、米国東部、北バージニア)

  • us-east-2​ (米国東部、オハイオ)

  • us-west-1​ (米国西部、北カリフォルニア)

  • us-west-2​ (米国西部、オレゴン)

  • us-gov-west-1​ (MuleSoft Government Cloud)

  • eu-central-1​ (EU、フランクフルト)

  • eu-west-1​ (EU、アイルランド)

  • eu-west-2​ (EU、ロンドン)

  • ap-southeast-1​ (アジア太平洋、シンガポール)

  • ap-southeast-2​ (アジア太平洋、シドニー)

  • ap-northeast-1​ (アジア太平洋、東京)

  • ca-central-1​ (カナダ、中央部)

  • sa-east-1​ (南米、サンパウロ)

いいえ

objectStoreV2

Object Store V2 を有効にします。
デフォルトでは、この値は OSv2 の Runtime Manager 設定に一致するように ​true​ に設定されています。
このパラメーターは、プラグインバージョン 3.3.3 以降で使用できます。

いいえ

persistentQueues

永続的なキューを有効にします。
デフォルトでは、これは ​false​ に設定されます。

いいえ

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

applyLatestRuntimePatch

true​ に設定すると、プラグインは CloudHub に、デプロイメント設定で指定された Mule Runtime Engine バージョンで使用可能な最新のパッチにワーカーを更新してからアプリケーションをデプロイするように指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ
## [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.3/how-to-export-resources) # Mule Maven プラグインを使用した CloudHub へのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションを CloudHub にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイ、再デプロイ、アンデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して CloudHub にアプリケーションをデプロイする場合は、以下を参照してください。 - [Anypoint Studio を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/deploy-mule-application-task) - [Anypoint CLI を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/cloudhub-apps#deploy-to-cloudhub) - [Runtime Manager を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub) ## [](#前提条件)前提条件 Mule Maven プラグインを使用して CloudHub にデプロイする前に、次のタスクを完了する必要があります。 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept#add-mmp)​を参照してください。 - HTTP Listener をフローのソースとして使用している場合、そのホストを ​**0.0.0.0**​ に、そのポートを ​**${http.port}**​ に設定する必要があります。 - すべての外部クラスおよびリソースを ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ および ​`exportedResources`​ 項目で宣言する ## [](#cloudhub-デプロイメント戦略の設定)CloudHub デプロイメント戦略の設定 Mule Maven プラグインを使用して Mule アプリケーションをデプロイ、再デプロイ、アンデプロイできるようにプロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定します。 プロジェクトの ​`pom.xml`​ ファイルの ​`plugin`​ 要素内で CloudHub デプロイメントを設定し、プレースホルダーの値を CloudHub 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com ${app.runtime} ${username} ${password} ${cloudhub.application.name} ${environment} ${region} ${workers} ${workerType} value ``` ## [](#cloudhub-へのデプロイ)CloudHub へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#cloudhub-への再デプロイ)CloudHub への再デプロイ Mule Maven プラグインを使用して Mule アプリケーションを再デプロイするには、以前にアプリケーションをデプロイしたときと同様に ​`mvn clean deploy -DmuleDeploy`​ を実行します。CloudHub は、デプロイしたアプリケーションを書き込み直します。 ## [](#cloudhub-からのアンデプロイ)CloudHub からのアンデプロイ Mule Maven プラグインを使用して Mule アプリケーションをアンデプロイするには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy コマンドにより、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

CloudHub のユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[CloudHub デプロイメントリファレンス](#cloudhub-deploy-reference)​を参照してください。 ## [](#cloudhub-deploy-reference)CloudHub デプロイメントリファレンス 次の表に、プロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定するための使用可能なパラメーターを示します。
パラメーター 説明 必須

cloudHubDeployment

最上位要素

はい

uri

Anypoint Platform の URI
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

muleVersion

CloudHub インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.3.0

Mule 4.5 以降では、CloudHub へのデプロイメントに最新バージョンの Mule Runtime がデプロイされる Major.Minor バージョンが必要です。 値の例: 4.5

はい

username

CloudHub ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

CloudHub パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

CloudHub 内のアプリケーションの名前
この名前は、デプロイされるアプリケーションのドメインの一部です。たとえば、アプリケーションに application-1 という名前を付けると、アプリケーションの公開ドメインは application-1.cloudhub.io となります。

はい

artifact

デプロイする JAR ファイルの絶対パス
設定しない場合、パスはデフォルトで、パッケージフェーズで生成された JAR ファイルの位置になります。

いいえ

environment

デプロイ先の CloudHub 環境
この値は、CloudHub アカウントで設定されたいずれかの環境に一致する必要があります。

<environment>Sandbox</environment>

はい

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

workers

ワーカーの数
デフォルトでは、この値は 1 です。

いいえ

workerType

各ワーカーのサイズ (次のいずれかの値)

  • MICRO​ (デフォルト、0.1 vCore)

  • SMALL​ (0.2 vCore)

  • MEDIUM​ (1 vCore)

  • LARGE​ (2 vCore)

  • XLARGE​ (4 vCore)

  • XXLARGE​ (8 vCore)

  • 4XLARGE​ (16 vCore)

いいえ

region

ワーカークラウドの地域 (次のいずれかの値)

  • us-east-1​ (デフォルト、米国東部、北バージニア)

  • us-east-2​ (米国東部、オハイオ)

  • us-west-1​ (米国西部、北カリフォルニア)

  • us-west-2​ (米国西部、オレゴン)

  • us-gov-west-1​ (MuleSoft Government Cloud)

  • eu-central-1​ (EU、フランクフルト)

  • eu-west-1​ (EU、アイルランド)

  • eu-west-2​ (EU、ロンドン)

  • ap-southeast-1​ (アジア太平洋、シンガポール)

  • ap-southeast-2​ (アジア太平洋、シドニー)

  • ap-northeast-1​ (アジア太平洋、東京)

  • ca-central-1​ (カナダ、中央部)

  • sa-east-1​ (南米、サンパウロ)

いいえ

objectStoreV2

Object Store V2 を有効にします。
デフォルトでは、この値は OSv2 の Runtime Manager 設定に一致するように ​true​ に設定されています。

いいえ

persistentQueues

永続的なキューを有効にします。
デフォルトでは、これは ​false​ に設定されます。

いいえ

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの状況検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

applyLatestRuntimePatch

true​ に設定すると、プラグインは CloudHub に、デプロイメント設定で指定された Mule Runtime Engine バージョンで使用可能な最新のパッチにワーカーを更新してからアプリケーションをデプロイするように指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ

disableCloudHubLogs

true​ に設定した場合、プラグインは、CloudHub ログを無効化して代わりに ​log4j2.xml​ ファイルで設定されたアプリケーションを使用するように CloudHub に指示します。
デフォルトでは、これは ​false​ に設定されます。
このパラメーターは、プラグインバージョン 3.8.1 以降で使用できます。

いいえ
## [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.4/how-to-export-resources) # Mule Maven プラグインを使用した CloudHub へのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションを CloudHub にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイ、再デプロイ、アンデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して CloudHub にアプリケーションをデプロイする場合は、以下を参照してください。 - [Anypoint Studio を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/deploy-mule-application-task) - [Anypoint CLI を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/cloudhub-apps#deploy-to-cloudhub) - [Runtime Manager を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub) ## [](#前提条件)前提条件 Mule Maven プラグインを使用して CloudHub にデプロイする前に、次のタスクを完了する必要があります。 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept#add-mmp)​を参照してください。 - HTTP Listener をフローのソースとして使用している場合、そのホストを ​**0.0.0.0**​ に、そのポートを ​**${http.port}**​ に設定する必要があります。 - すべての外部クラスおよびリソースを ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ および ​`exportedResources`​ 項目で宣言する ## [](#cloudhub-デプロイメント戦略の設定)CloudHub デプロイメント戦略の設定 Mule Maven プラグインを使用して Mule アプリケーションをデプロイ、再デプロイ、アンデプロイできるようにプロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定します。 プロジェクトの ​`pom.xml`​ ファイルの ​`plugin`​ 要素内で CloudHub デプロイメントを設定し、プレースホルダーの値を CloudHub 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com ${app.runtime} ${username} ${password} ${cloudhub.application.name} ${environment} ${region} ${workers} ${workerType} value ``` ## [](#cloudhub-へのデプロイ)CloudHub へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#cloudhub-への再デプロイ)CloudHub への再デプロイ Mule Maven プラグインを使用して Mule アプリケーションを再デプロイするには、以前にアプリケーションをデプロイしたときと同様に ​`mvn clean deploy -DmuleDeploy`​ を実行します。CloudHub は、デプロイしたアプリケーションを書き込み直します。 ## [](#cloudhub-からのアンデプロイ)CloudHub からのアンデプロイ Mule Maven プラグインを使用して Mule アプリケーションをアンデプロイするには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy コマンドにより、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

CloudHub のユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、「​[CloudHub デプロイメントリファレンス](#cloudhub-deploy-reference)​」を参照してください。 ## [](#cloudhub-deploy-reference)CloudHub デプロイメントリファレンス 次の表に、プロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定するための使用可能なパラメーターを示します。
パラメーター 説明 必須

cloudHubDeployment

最上位要素

はい

uri

Anypoint Platform の URI
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

muleVersion

CloudHub インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.3.0

Mule 4.5 以降では、CloudHub へのデプロイメントに最新バージョンの Mule Runtime がデプロイされる Major.Minor バージョンが必要です。 値の例: 4.5

はい

username

CloudHub ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

CloudHub パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

CloudHub 内のアプリケーションの名前
この名前は、デプロイされるアプリケーションのドメインの一部です。たとえば、アプリケーションに application-1 という名前を付けると、アプリケーションの公開ドメインは application-1.cloudhub.io となります。

はい

artifact

デプロイする JAR ファイルの絶対パス
設定しない場合、パスはデフォルトで、パッケージフェーズで生成された JAR ファイルの位置になります。

いいえ

environment

デプロイ先の CloudHub 環境
この値は、CloudHub アカウントで設定されたいずれかの環境に一致する必要があります。

<environment>Sandbox</environment>

はい

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

workers

ワーカーの数
デフォルトでは、この値は 1 です。

いいえ

workerType

各ワーカーのサイズ (次のいずれかの値)

  • MICRO​ (デフォルト、0.1 vCore)

  • SMALL​ (0.2 vCore)

  • MEDIUM​ (1 vCore)

  • LARGE​ (2 vCore)

  • XLARGE​ (4 vCore)

  • XXLARGE​ (8 vCore)

  • 4XLARGE​ (16 vCore)

いいえ

region

ワーカークラウドの地域 (次のいずれかの値)

  • us-east-1​ (デフォルト、米国東部、北バージニア)

  • us-east-2​ (米国東部、オハイオ)

  • us-west-1​ (米国西部、北カリフォルニア)

  • us-west-2​ (米国西部、オレゴン)

  • us-gov-west-1​ (MuleSoft Government Cloud)

  • eu-central-1​ (EU、フランクフルト)

  • eu-west-1​ (EU、アイルランド)

  • eu-west-2​ (EU、ロンドン)

  • ap-southeast-1​ (アジア太平洋、シンガポール)

  • ap-southeast-2​ (アジア太平洋、シドニー)

  • ap-northeast-1​ (アジア太平洋、東京)

  • ca-central-1​ (カナダ、中央部)

  • sa-east-1​ (南米、サンパウロ)

いいえ

objectStoreV2

Object Store V2 を有効にします。
デフォルトでは、この値は OSv2 の Runtime Manager 設定に一致するように ​true​ に設定されています。

いいえ

persistentQueues

永続的なキューを有効にします。
デフォルトでは、これは ​false​ に設定されます。

いいえ

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

applyLatestRuntimePatch

true​ に設定すると、プラグインは CloudHub に、デプロイメント設定で指定された Mule Runtime Engine バージョンで使用可能な最新のパッチにワーカーを更新してからアプリケーションをデプロイするように指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ

disableCloudHubLogs

true​ に設定した場合、プラグインは、CloudHub ログを無効化して代わりに ​log4j2.xml​ ファイルで設定されたアプリケーションを使用するように CloudHub に指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ
## [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.5/how-to-export-resources) # Mule Maven プラグインを使用した CloudHub へのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションを CloudHub にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイ、再デプロイ、アンデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して CloudHub にアプリケーションをデプロイする場合は、以下を参照してください。 - [Anypoint Studio を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/deploy-mule-application-task) - [Anypoint CLI を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/cloudhub-apps#deploy-to-cloudhub) - [Runtime Manager を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub) ## [](#前提条件)前提条件 Mule Maven プラグインを使用して CloudHub にデプロイする前に、次のタスクを完了する必要があります。 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept#add-mmp)​を参照してください。 - HTTP Listener をフローのソースとして使用している場合、そのホストを ​**0.0.0.0**​ に、そのポートを ​**${http.port}**​ に設定する必要があります。 - すべての外部クラスおよびリソースを ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ および ​`exportedResources`​ 項目で宣言する ## [](#cloudhub-デプロイメント戦略の設定)CloudHub デプロイメント戦略の設定 Mule Maven プラグインを使用して Mule アプリケーションをデプロイ、再デプロイ、アンデプロイできるようにプロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定します。 プロジェクトの ​`pom.xml`​ ファイルの ​`plugin`​ 要素内で CloudHub デプロイメントを設定し、プレースホルダーの値を CloudHub 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com ${app.runtime} ${username} ${password} ${cloudhub.application.name} ${environment} ${region} ${workers} ${workerType} value ``` ## [](#cloudhub-へのデプロイ)CloudHub へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#cloudhub-への再デプロイ)CloudHub への再デプロイ Mule Maven プラグインを使用して Mule アプリケーションを再デプロイするには、以前にアプリケーションをデプロイしたときと同様に ​`mvn clean deploy -DmuleDeploy`​ を実行します。CloudHub は、デプロイしたアプリケーションを書き込み直します。 ## [](#cloudhub-からのアンデプロイ)CloudHub からのアンデプロイ Mule Maven プラグインを使用して Mule アプリケーションをアンデプロイするには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy コマンドにより、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

CloudHub のユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[CloudHub デプロイメントリファレンス](#cloudhub-deploy-reference)​を参照してください。 ## [](#cloudhub-deploy-reference)CloudHub デプロイメントリファレンス 次の表に、プロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定するための使用可能なパラメーターを示します。
パラメーター 説明 必須

cloudHubDeployment

最上位要素

はい

uri

Anypoint Platform の URI
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

muleVersion

CloudHub インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.3.0
Mule 4.5 以降では、CloudHub へのデプロイメントに Mule バージョンの正確な名前または最新バージョンの Mule Runtime がデプロイされるセマンティックバージョン設定を使用できます。
値の例: 4.6​、​4.6-e-java8​ (Edge)、​4.6-e-java17​ (Edge)、​4.6-java8​ (LTS)、​4.6-java17​ (LTS)
デプロイメントに Mule Maven プラグインバージョン 3.8.0 および 4.0.0 を使用している場合、MuleSoft は LTS チャネルのサポートを保証しません。Mule Maven プラグインバージョン 4.1.1 以降を使用することをお勧めします。たとえば、プラグイン 3.8.0 または 4.0.0 で ​<muleVersion>4.6-java17</muleVersion>​ と指定すると、Edge リリースチャネルと Java 8 を選択してアプリケーションがデプロイされます。​releaseChannel​ と ​javaVersion​ を指定するには、プラグインをバージョン 4.1.1 以降にアップグレードします。

はい

releaseChannel

選択した Mule バージョンで使用するリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。Mule バージョンを指定しない場合、選択したリリースチャネルのデフォルトの Mule バージョンが使用されます。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

選択した Mule バージョンで使用する Java バージョン名を設定します。サポートされている値は ​8​ と ​17​ です。Mule バージョンを指定しない場合、選択した Java バージョンのデフォルトの Mule バージョンが使用されます。選択した Java バージョンが指定された Mule バージョンで使用できない場合、エラーが発生します。

いいえ

username

CloudHub ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

CloudHub パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

CloudHub 内のアプリケーションの名前
この名前は、デプロイされるアプリケーションのドメインの一部です。たとえば、アプリケーションに application-1 という名前を付けると、アプリケーションの公開ドメインは application-1.cloudhub.io となります。

はい

artifact

デプロイする JAR ファイルの絶対パス
設定しない場合、パスはデフォルトで、パッケージフェーズで生成された JAR ファイルの位置になります。

いいえ

environment

デプロイ先の CloudHub 環境
この値は、CloudHub アカウントで設定されたいずれかの環境に一致する必要があります。

<environment>Sandbox</environment>

はい

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

workers

ワーカーの数
デフォルトでは、この値は 1 です。

いいえ

workerType

各ワーカーのサイズ (次のいずれかの値)

  • MICRO​ (デフォルト、0.1 vCore)

  • SMALL​ (0.2 vCore)

  • MEDIUM​ (1 vCore)

  • LARGE​ (2 vCore)

  • XLARGE​ (4 vCore)

  • XXLARGE​ (8 vCore)

  • 4XLARGE​ (16 vCore)

いいえ

region

ワーカークラウドの地域 (次のいずれかの値)

  • us-east-1​ (デフォルト、米国東部、北バージニア)

  • us-east-2​ (米国東部、オハイオ)

  • us-west-1​ (米国西部、北カリフォルニア)

  • us-west-2​ (米国西部、オレゴン)

  • us-gov-west-1​ (MuleSoft Government Cloud)

  • eu-central-1​ (EU、フランクフルト)

  • eu-west-1​ (EU、アイルランド)

  • eu-west-2​ (EU、ロンドン)

  • ap-southeast-1​ (アジア太平洋、シンガポール)

  • ap-southeast-2​ (アジア太平洋、シドニー)

  • ap-northeast-1​ (アジア太平洋、東京)

  • ca-central-1​ (カナダ、中央部)

  • sa-east-1​ (南米、サンパウロ)

いいえ

objectStoreV2

Object Store V2 を有効にします。
デフォルトでは、この値は OSv2 の Runtime Manager 設定に一致するように ​true​ に設定されています。

いいえ

persistentQueues

永続的なキューを有効にします。
デフォルトでは、これは ​false​ に設定されます。

いいえ

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの状況検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

applyLatestRuntimePatch

true​ に設定すると、プラグインは CloudHub に、デプロイメント設定で指定された Mule Runtime Engine バージョンで使用可能な最新のパッチにワーカーを更新してからアプリケーションをデプロイするように指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ

disableCloudHubLogs

true​ に設定した場合、プラグインは、CloudHub ログを無効化して代わりに ​log4j2.xml​ ファイルで設定されたアプリケーションを使用するように CloudHub に指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ
## [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.6/how-to-export-resources) # Mule Maven プラグインを使用した CloudHub へのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションを CloudHub にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイ、再デプロイ、アンデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して CloudHub にアプリケーションをデプロイする場合は、以下を参照してください。 - [Anypoint Studio を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/deploy-mule-application-task) - [Anypoint CLI を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/cloudhub-apps#deploy-to-cloudhub) - [Runtime Manager を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub) ## [](#前提条件)前提条件 Mule Maven プラグインを使用して CloudHub にデプロイする前に、次のタスクを完了する必要があります。 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept#add-mmp)​を参照してください。 - HTTP Listener をフローのソースとして使用している場合、そのホストを ​**0.0.0.0**​ に、そのポートを ​**${http.port}**​ に設定する必要があります。 - すべての外部クラスおよびリソースを ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ および ​`exportedResources`​ 項目で宣言する ## [](#cloudhub-デプロイメント戦略の設定)CloudHub デプロイメント戦略の設定 Mule Maven プラグインを使用して Mule アプリケーションをデプロイ、再デプロイ、アンデプロイできるようにプロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定します。 プロジェクトの ​`pom.xml`​ ファイルの ​`plugin`​ 要素内で CloudHub デプロイメントを設定し、プレースホルダーの値を CloudHub 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com ${app.runtime} ${username} ${password} ${cloudhub.application.name} ${environment} ${region} ${workers} ${workerType} value ``` ## [](#cloudhub-へのデプロイ)CloudHub へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#cloudhub-への再デプロイ)CloudHub への再デプロイ Mule Maven プラグインを使用して Mule アプリケーションを再デプロイするには、以前にアプリケーションをデプロイしたときと同様に ​`mvn clean deploy -DmuleDeploy`​ を実行します。CloudHub は、デプロイしたアプリケーションを書き込み直します。 ## [](#cloudhub-からのアンデプロイ)CloudHub からのアンデプロイ Mule Maven プラグインを使用して Mule アプリケーションをアンデプロイするには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy コマンドにより、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

CloudHub のユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[CloudHub デプロイメントリファレンス](#cloudhub-deploy-reference)​を参照してください。 ## [](#cloudhub-deploy-reference)CloudHub デプロイメントリファレンス 次の表に、プロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定するための使用可能なパラメーターを示します。
パラメーター 説明 必須

cloudHubDeployment

最上位要素

はい

uri

Anypoint Platform の URI
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

muleVersion

CloudHub インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.3.0
Mule 4.5 以降では、CloudHub へのデプロイメントに Mule バージョンの正確な名前または最新バージョンの Mule Runtime がデプロイされるセマンティックバージョン設定を使用できます。
値の例: 4.6​、​4.6-e-java8​ (Edge)、​4.6-e-java17​ (Edge)、​4.6-java8​ (LTS)、​4.6-java17​ (LTS)
デプロイメントに Mule Maven プラグインバージョン 3.8.0 および 4.0.0 を使用している場合、MuleSoft は LTS チャネルのサポートを保証しません。Mule Maven プラグインバージョン 4.1.1 以降を使用することをお勧めします。たとえば、プラグイン 3.8.0 または 4.0.0 で ​<muleVersion>4.6-java17</muleVersion>​ と指定すると、Edge リリースチャネルと Java 8 を選択してアプリケーションがデプロイされます。​releaseChannel​ と ​javaVersion​ を指定するには、プラグインをバージョン 4.1.1 以降にアップグレードします。

はい

releaseChannel

選択した Mule バージョンで使用するリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。Mule バージョンを指定しない場合、選択したリリースチャネルのデフォルトの Mule バージョンが使用されます。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

選択した Mule バージョンで使用する Java バージョン名を設定します。サポートされている値は ​8​ と ​17​ です。Mule バージョンを指定しない場合、選択した Java バージョンのデフォルトの Mule バージョンが使用されます。選択した Java バージョンが指定された Mule バージョンで使用できない場合、エラーが発生します。

いいえ

username

CloudHub ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

CloudHub パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

CloudHub 内のアプリケーションの名前
この名前は、デプロイされるアプリケーションのドメインの一部です。たとえば、アプリケーションに application-1 という名前を付けると、アプリケーションの公開ドメインは application-1.cloudhub.io となります。

はい

artifact

デプロイする JAR ファイルの絶対パス
設定しない場合、パスはデフォルトで、パッケージフェーズで生成された JAR ファイルの位置になります。

いいえ

environment

デプロイ先の CloudHub 環境
この値は、CloudHub アカウントで設定されたいずれかの環境に一致する必要があります。

<environment>Sandbox</environment>

はい

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

workers

ワーカーの数
デフォルトでは、この値は 1 です。

いいえ

workerType

各ワーカーのサイズ (次のいずれかの値)

  • MICRO​ (デフォルト、0.1 vCore)

  • SMALL​ (0.2 vCore)

  • MEDIUM​ (1 vCore)

  • LARGE​ (2 vCore)

  • XLARGE​ (4 vCore)

  • XXLARGE​ (8 vCore)

  • 4XLARGE​ (16 vCore)

いいえ

region

ワーカークラウドの地域 (次のいずれかの値)

  • us-east-1​ (デフォルト、米国東部、北バージニア)

  • us-east-2​ (米国東部、オハイオ)

  • us-west-1​ (米国西部、北カリフォルニア)

  • us-west-2​ (米国西部、オレゴン)

  • us-gov-west-1​ (MuleSoft Government Cloud)

  • eu-central-1​ (EU、フランクフルト)

  • eu-west-1​ (EU、アイルランド)

  • eu-west-2​ (EU、ロンドン)

  • ap-southeast-1​ (アジア太平洋、シンガポール)

  • ap-southeast-2​ (アジア太平洋、シドニー)

  • ap-northeast-1​ (アジア太平洋、東京)

  • ca-central-1​ (カナダ、中央部)

  • sa-east-1​ (南米、サンパウロ)

いいえ

objectStoreV2

Object Store V2 を有効にします。
デフォルトでは、この値は OSv2 の Runtime Manager 設定に一致するように ​true​ に設定されています。

いいえ

persistentQueues

永続的なキューを有効にします。
デフォルトでは、これは ​false​ に設定されます。

いいえ

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

applyLatestRuntimePatch

true​ に設定すると、プラグインは CloudHub に、デプロイメント設定で指定された Mule Runtime Engine バージョンで使用可能な最新のパッチにワーカーを更新してからアプリケーションをデプロイするように指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ

disableCloudHubLogs

true​ に設定した場合、プラグインは、CloudHub ログを無効化して代わりに ​log4j2.xml​ ファイルで設定されたアプリケーションを使用するように CloudHub に指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ
## [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.7/how-to-export-resources) # Mule Maven プラグインを使用した CloudHub へのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションを CloudHub にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイ、再デプロイ、アンデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して CloudHub にアプリケーションをデプロイする場合は、以下を参照してください。 - [Anypoint Studio を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/deploy-mule-application-task) - [Anypoint CLI を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/cloudhub-apps#deploy-to-cloudhub) - [Runtime Manager を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub) ## [](#前提条件)前提条件 Mule Maven プラグインを使用して CloudHub にデプロイする前に、次のタスクを完了する必要があります。 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept#add-mmp)​を参照してください。 - HTTP Listener をフローのソースとして使用している場合、そのホストを ​**0.0.0.0**​ に、そのポートを ​**${http.port}**​ に設定する必要があります。 - すべての外部クラスおよびリソースを ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ および ​`exportedResources`​ 項目で宣言する ## [](#cloudhub-デプロイメント戦略の設定)CloudHub デプロイメント戦略の設定 Mule Maven プラグインを使用して Mule アプリケーションをデプロイ、再デプロイ、アンデプロイできるようにプロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定します。 プロジェクトの ​`pom.xml`​ ファイルの ​`plugin`​ 要素内で CloudHub デプロイメントを設定し、プレースホルダーの値を CloudHub 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com ${app.runtime} ${username} ${password} ${cloudhub.application.name} ${environment} ${region} ${workers} ${workerType} value ``` ## [](#cloudhub-へのデプロイ)CloudHub へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#cloudhub-への再デプロイ)CloudHub への再デプロイ Mule Maven プラグインを使用して Mule アプリケーションを再デプロイするには、以前にアプリケーションをデプロイしたときと同様に ​`mvn clean deploy -DmuleDeploy`​ を実行します。CloudHub は、デプロイしたアプリケーションを書き込み直します。 ## [](#cloudhub-からのアンデプロイ)CloudHub からのアンデプロイ Mule Maven プラグインを使用して Mule アプリケーションをアンデプロイするには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy コマンドにより、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

CloudHub のユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[CloudHub デプロイメントリファレンス](#cloudhub-deploy-reference)​を参照してください。 ## [](#cloudhub-deploy-reference)CloudHub デプロイメントリファレンス 次の表に、プロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定するための使用可能なパラメーターを示します。
パラメーター 説明 必須

cloudHubDeployment

最上位要素

はい

uri

Anypoint Platform の URI
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

muleVersion

CloudHub インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.3.0
Mule 4.5 以降では、CloudHub へのデプロイメントに Mule バージョンの正確な名前または最新バージョンの Mule Runtime がデプロイされるセマンティックバージョン設定を使用できます。
値の例: 4.6​、​4.6-e-java8​ (Edge)、​4.6-e-java17​ (Edge)、​4.6-java8​ (LTS)、​4.6-java17​ (LTS)
デプロイメントに Mule Maven プラグインバージョン 3.8.0 および 4.0.0 を使用している場合、MuleSoft は LTS チャネルのサポートを保証しません。Mule Maven プラグインバージョン 4.1.1 以降を使用することをお勧めします。たとえば、プラグイン 3.8.0 または 4.0.0 で ​<muleVersion>4.6-java17</muleVersion>​ と指定すると、Edge リリースチャネルと Java 8 を選択してアプリケーションがデプロイされます。​releaseChannel​ と ​javaVersion​ を指定するには、プラグインをバージョン 4.1.1 以降にアップグレードします。

はい

releaseChannel

選択した Mule バージョンで使用するリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。Mule バージョンを指定しない場合、選択したリリースチャネルのデフォルトの Mule バージョンが使用されます。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

選択した Mule バージョンで使用する Java バージョン名を設定します。サポートされている値は ​8​ と ​17​ です。Mule バージョンを指定しない場合、選択した Java バージョンのデフォルトの Mule バージョンが使用されます。選択した Java バージョンが指定された Mule バージョンで使用できない場合、エラーが発生します。

いいえ

username

CloudHub ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

CloudHub パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

CloudHub 内のアプリケーションの名前
この名前は、デプロイされるアプリケーションのドメインの一部です。たとえば、アプリケーションに application-1 という名前を付けると、アプリケーションの公開ドメインは application-1.cloudhub.io となります。

はい

artifact

デプロイする JAR ファイルの絶対パス
設定しない場合、パスはデフォルトで、パッケージフェーズで生成された JAR ファイルの位置になります。

いいえ

environment

デプロイ先の CloudHub 環境
この値は、CloudHub アカウントで設定されたいずれかの環境に一致する必要があります。

<environment>Sandbox</environment>

はい

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

workers

ワーカーの数
デフォルトでは、この値は 1 です。

いいえ

workerType

各ワーカーのサイズ (次のいずれかの値)

  • MICRO​ (デフォルト、0.1 vCore)

  • SMALL​ (0.2 vCore)

  • MEDIUM​ (1 vCore)

  • LARGE​ (2 vCore)

  • XLARGE​ (4 vCore)

  • XXLARGE​ (8 vCore)

  • 4XLARGE​ (16 vCore)

いいえ

region

ワーカークラウドの地域 (次のいずれかの値)

  • us-east-1​ (デフォルト、米国東部、北バージニア)

  • us-east-2​ (米国東部、オハイオ)

  • us-west-1​ (米国西部、北カリフォルニア)

  • us-west-2​ (米国西部、オレゴン)

  • us-gov-west-1​ (MuleSoft Government Cloud)

  • eu-central-1​ (EU、フランクフルト)

  • eu-west-1​ (EU、アイルランド)

  • eu-west-2​ (EU、ロンドン)

  • ap-southeast-1​ (アジア太平洋、シンガポール)

  • ap-southeast-2​ (アジア太平洋、シドニー)

  • ap-northeast-1​ (アジア太平洋、東京)

  • ca-central-1​ (カナダ、中央部)

  • sa-east-1​ (南米、サンパウロ)

いいえ

objectStoreV2

Object Store V2 を有効にします。
デフォルトでは、この値は OSv2 の Runtime Manager 設定に一致するように ​true​ に設定されています。

いいえ

persistentQueues

永続的なキューを有効にします。
デフォルトでは、これは ​false​ に設定されます。

いいえ

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションの秘密鍵を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

applyLatestRuntimePatch

true​ に設定すると、プラグインは CloudHub に、デプロイメント設定で指定された Mule Runtime Engine バージョンで使用可能な最新のパッチにワーカーを更新してからアプリケーションをデプロイするように指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ

disableCloudHubLogs

true​ に設定した場合、プラグインは、CloudHub ログを無効化して代わりに ​log4j2.xml​ ファイルで設定されたアプリケーションを使用するように CloudHub に指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ
## [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.8/how-to-export-resources) # Mule Maven プラグインを使用した CloudHub へのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションを CloudHub にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイ、再デプロイ、アンデプロイすることもできます。これを行うには、特定の前提条件を満たし、CloudHub デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して CloudHub にアプリケーションをデプロイする場合は、以下を参照してください。 - [Anypoint Studio を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/deploy-mule-application-task) - [Anypoint CLI を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/cloudhub-apps#deploy-to-cloudhub) - [Runtime Manager を使用した CloudHub へのアプリケーションのデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub) ## [](#前提条件)前提条件 Mule Maven プラグインを使用して CloudHub にデプロイする前に、次のタスクを完了する必要があります。 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept#add-mmp)​を参照してください。 - HTTP Listener をフローのソースとして使用している場合、そのホストを ​**0.0.0.0**​ に、そのポートを ​**${http.port}**​ に設定する必要があります。 - すべての外部クラスおよびリソースを ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ および ​`exportedResources`​ 項目で宣言する ## [](#cloudhub-デプロイメント戦略の設定)CloudHub デプロイメント戦略の設定 Mule Maven プラグインを使用して Mule アプリケーションをデプロイ、再デプロイ、アンデプロイできるようにプロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定します。 プロジェクトの ​`pom.xml`​ ファイルの ​`plugin`​ 要素内で CloudHub デプロイメントを設定し、プレースホルダーの値を CloudHub 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com ${app.runtime} ${username} ${password} ${cloudhub.application.name} ${environment} ${region} ${workers} ${workerType} value ``` ## [](#cloudhub-へのデプロイ)CloudHub へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#cloudhub-への再デプロイ)CloudHub への再デプロイ Mule Maven プラグインを使用して Mule アプリケーションを再デプロイするには、以前にアプリケーションをデプロイしたときと同様に ​`mvn clean deploy -DmuleDeploy`​ を実行します。CloudHub は、デプロイしたアプリケーションを書き込み直します。 ## [](#cloudhub-からのアンデプロイ)CloudHub からのアンデプロイ Mule Maven プラグインを使用して Mule アプリケーションをアンデプロイするには、次のコマンドを実行します。 ```console mvn mule:undeploy ``` undeploy コマンドにより、Mule Maven プラグイン 3.3.0 以降のバージョンのアプリケーションも削除されます。 ## [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

CloudHub のユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[CloudHub デプロイメントリファレンス](#cloudhub-deploy-reference)​を参照してください。 ## [](#cloudhub-deploy-reference)CloudHub デプロイメントリファレンス 次の表に、プロジェクトの ​`pom.xml`​ ファイルで CloudHub デプロイメント戦略を設定するための使用可能なパラメーターを示します。
パラメーター 説明 必須

cloudHubDeployment

最上位要素

はい

uri

Anypoint Platform の URI
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

muleVersion

CloudHub インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.3.0
Mule 4.5 以降では、CloudHub へのデプロイメントに Mule バージョンの正確な名前または最新バージョンの Mule Runtime がデプロイされるセマンティックバージョン設定を使用できます。
値の例: 4.6​、​4.6-e-java8​ (Edge)、​4.6-e-java17​ (Edge)、​4.6-java8​ (LTS)、​4.6-java17​ (LTS)
デプロイメントに Mule Maven プラグインバージョン 3.8.0 および 4.0.0 を使用している場合、MuleSoft は LTS チャネルのサポートを保証しません。Mule Maven プラグインバージョン 4.1.1 以降を使用することをお勧めします。たとえば、プラグイン 3.8.0 または 4.0.0 で ​<muleVersion>4.6-java17</muleVersion>​ と指定すると、Edge リリースチャネルと Java 8 を選択してアプリケーションがデプロイされます。​releaseChannel​ と ​javaVersion​ を指定するには、プラグインをバージョン 4.1.1 以降にアップグレードします。

はい

releaseChannel

選択した Mule バージョンで使用するリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。Mule バージョンを指定しない場合、選択したリリースチャネルのデフォルトの Mule バージョンが使用されます。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

選択した Mule バージョンで使用する Java バージョン名を設定します。サポートされている値は ​8​ と ​17​ です。Mule バージョンを指定しない場合、選択した Java バージョンのデフォルトの Mule バージョンが使用されます。選択した Java バージョンが指定された Mule バージョンで使用できない場合、エラーが発生します。

いいえ

username

CloudHub ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

CloudHub パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

CloudHub 内のアプリケーションの名前
この名前は、デプロイされるアプリケーションのドメインの一部です。たとえば、アプリケーションに application-1 という名前を付けると、アプリケーションの公開ドメインは application-1.cloudhub.io となります。

はい

artifact

デプロイする JAR ファイルの絶対パス
設定しない場合、パスはデフォルトで、パッケージフェーズで生成された JAR ファイルの位置になります。

いいえ

environment

デプロイ先の CloudHub 環境
この値は、CloudHub アカウントで設定されたいずれかの環境に一致する必要があります。

<environment>Sandbox</environment>

はい

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

workers

ワーカーの数
デフォルトでは、この値は 1 です。

いいえ

workerType

各ワーカーのサイズ (次のいずれかの値)

  • MICRO​ (デフォルト、0.1 vCore)

  • SMALL​ (0.2 vCore)

  • MEDIUM​ (1 vCore)

  • LARGE​ (2 vCore)

  • XLARGE​ (4 vCore)

  • XXLARGE​ (8 vCore)

  • 4XLARGE​ (16 vCore)

いいえ

region

ワーカークラウドの地域 (次のいずれかの値)

  • us-east-1​ (デフォルト、米国東部、北バージニア)

  • us-east-2​ (米国東部、オハイオ)

  • us-west-1​ (米国西部、北カリフォルニア)

  • us-west-2​ (米国西部、オレゴン)

  • us-gov-west-1​ (MuleSoft Government Cloud)

  • eu-central-1​ (EU、フランクフルト)

  • eu-west-1​ (EU、アイルランド)

  • eu-west-2​ (EU、ロンドン)

  • ap-southeast-1​ (アジア太平洋、シンガポール)

  • ap-southeast-2​ (アジア太平洋、シドニー)

  • ap-northeast-1​ (アジア太平洋、東京)

  • ca-central-1​ (カナダ、中央部)

  • sa-east-1​ (南米、サンパウロ)

いいえ

objectStoreV2

Object Store V2 を有効にします。
デフォルトでは、この値は OSv2 の Runtime Manager 設定に一致するように ​true​ に設定されています。

いいえ

persistentQueues

永続的なキューを有効にします。
デフォルトでは、これは ​false​ に設定されます。

いいえ

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

applyLatestRuntimePatch

true​ に設定すると、プラグインは CloudHub に、デプロイメント設定で指定された Mule Runtime Engine バージョンで使用可能な最新のパッチにワーカーを更新してからアプリケーションをデプロイするように指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ

disableCloudHubLogs

true​ に設定した場合、プラグインは、CloudHub ログを無効化して代わりに ​log4j2.xml​ ファイルで設定されたアプリケーションを使用するように CloudHub に指示します。
デフォルトでは、これは ​false​ に設定されます。

いいえ
## [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept) - [リソースのエクスポート](https://docs.mulesoft.com/jp/mule-runtime/4.9/how-to-export-resources) # Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\]

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを Anypoint Runtime Fabric にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、Runtime Fabric デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して Runtime Fabric にアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用した Runtime Fabric へのアプリケーションのデプロイ](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) ## [](#前提条件)前提条件 - Mule Maven プラグインがプロジェクトに追加されていることを確認する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept#add-mmp)​を参照してください。 - Runtime Fabric へのデプロイに必要なリソースの数を理解し、使用できる 詳細は、[Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed)を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 ## [](#deploying-to-rtf)Runtime Fabric デプロイメント戦略の設定 `plugin`​ 要素内に Runtime Fabric デプロイメント用の設定を追加し、次のプレースホルダーの値を Runtime Fabric 情報で置き換えます。 ```xml Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::example$mmp-concept-config.xml[] https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## [](#runtime-fabric-へのデプロイ)Runtime Fabric へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean package deploy -DmuleDeploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange のスナップショットアセットを Runtime Fabric にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされたら、Mule Maven プラグインを使用して ​`SNAPSHOT`​ バージョンのアプリケーションを Runtime Fabric に再デプロイし、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。 スナップショットアセットはデプロイ後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#runtime-fabric-への再デプロイ)Runtime Fabric への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 Runtime Fabric は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] 設定パラメーターの詳細は、​[Runtime Fabric デプロイメントのパラメーターリファレンス](#rtf-deploy-reference)​を参照してください。 ## [](#rtf-deploy-reference)Runtime Fabric デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

runtimeFabricDeployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

Runtime Fabric インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.3.0​、​4.2.2-hf4

はい

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

target

アプリケーションをデプロイする Runtime Fabric 対象名。

はい

provider

Runtime Fabric では ​MC​ に設定。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。アプリケーションあたりのレプリカの最大数は 8 です。

はい Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

forwardSslSession

セッション中に SSL 転送を有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <forwardSslSession>true</forwardSslSession>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

lastMileSecurity

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。
このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。
設定例:

<deploymentSettings>
    <lastMileSecurity>true</lastMileSecurity>
</deploymentSettings>

resources

cpu​

reserved​

アプリケーションの各レプリカに割り当てるコア数を指定します。デフォルト値は 0.5 vCore です。

limit​

アプリケーションの各レプリカに割り当てる最大コア数を指定します。
​reserved​ 設定が存在する場合、この値がそれ以上であることを確認してください。

memory​

reserved​

アプリケーションの各レプリカに割り当てるメモリ量を指定します。デフォルト値は 700 MB です。

limit​

アプリケーションレプリカごとに割り当てる最大メモリを指定します。​reserved​ 設定が存在する場合、この値がそれ以上であることを確認してください。

設定例:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。

設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>myapp.anypoint.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションレベルログの転送を無効にします。デフォルトでは、これは ​false​ に設定されます。
## [](#ログイン情報の暗号化)ログイン情報の暗号化 Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] + ```xml ... ... ... my.anypoint.credentials ... ... ... ``` \+ NOTE: ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。 ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\]

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを Anypoint Runtime Fabric にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、Runtime Fabric デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して Runtime Fabric にアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用した Runtime Fabric へのアプリケーションのデプロイ](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) ## [](#前提条件)前提条件 - Mule Maven プラグインがプロジェクトに追加されていることを確認する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept#add-mmp)​を参照してください。 - Runtime Fabric へのデプロイに必要なリソースの数を理解し、使用できる 詳細は、[Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed)を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 ## [](#deploying-to-rtf)Runtime Fabric デプロイメント戦略の設定 `plugin`​ 要素内に Runtime Fabric デプロイメント用の設定を追加し、次のプレースホルダーの値を Runtime Fabric 情報で置き換えます。 ```xml Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::example$mmp-concept-config.xml[] https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## [](#runtime-fabric-へのデプロイ)Runtime Fabric へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean deploy -DmuleDeploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange のスナップショットアセットを Runtime Fabric にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされたら、Mule Maven プラグインを使用して ​`SNAPSHOT`​ バージョンのアプリケーションを Runtime Fabric に再デプロイし、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。 スナップショットアセットはデプロイメント後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#runtime-fabric-への再デプロイ)Runtime Fabric への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 Runtime Fabric は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] 設定パラメーターの詳細は、​[Runtime Fabric デプロイメントのパラメーターリファレンス](#rtf-deploy-reference)​を参照してください。 ## [](#rtf-deploy-reference)Runtime Fabric デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

runtimeFabricDeployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

Runtime Fabric インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.3.0​、​4.2.2-hf4

はい

releaseChannel

Mule イメージを選択するために使用されるリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。デフォルトでは、この値は ​EDGE​ に設定されています。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

デプロイで使用される Java バージョンを設定します。サポートされている値は ​8​ と ​17​ です。デフォルトでは、この値は ​8​ に設定されています。選択された Java バージョンが存在しない場合、エラーが発生します。

いいえ

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

target

アプリケーションをデプロイする Runtime Fabric 対象名。

はい

provider

プロバイダー MC (MuleSoft コントロールプレーン) は、デプロイメントが Anypoint Runtime Manager を介して管理されていることを示します。Runtime Fabric では ​MC​ に設定します。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。アプリケーションあたりのレプリカの最大数は 8 です。

はい Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

forwardSslSession

セッション中に SSL 転送を有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <forwardSslSession>true</forwardSslSession>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

lastMileSecurity

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。
このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。
設定例:

<deploymentSettings>
    <lastMileSecurity>true</lastMileSecurity>
</deploymentSettings>

resources

cpu​

reserved​

アプリケーションの各レプリカに割り当てるコア数を指定します。デフォルト値は 0.5 vCore です。

limit​

アプリケーションの各レプリカに割り当てる最大コア数を指定します。
​reserved​ 設定が存在する場合、この値がそれ以上であることを確認してください。

memory​

reserved​

アプリケーションの各レプリカに割り当てるメモリ量を指定します。デフォルト値は 700 MB です。

limit​

アプリケーションレプリカごとに割り当てる最大メモリを指定します。​reserved​ 設定が存在する場合、この値がそれ以上であることを確認してください。

設定例:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。

ワイルドカード URL を使用した設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

単一証明書の単一 URL を使用した設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>wwww.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

永続的なオブジェクトストアを使用するように Mule アプリケーションを設定します。デフォルトでは、これは ​false​ に設定されます。

jvm

args​

アプリケーションのデプロイ時に Runtime Fabric に渡す JVM 引数を指定します。各引数を区切るには空白を使用します。

設定例:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

このパラメーターが true に設定されている場合、Runtime Fabric は、デプロイ済みアプリケーションの公開 URL を生成します。

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションレベルログの転送を無効にします。デフォルトでは、これは ​false​ に設定されます。
## [](#ログイン情報の暗号化)ログイン情報の暗号化 Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] + ```xml ... ... ... my.anypoint.credentials ... ... ... ``` \+ NOTE: ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。 ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\]

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを Anypoint Runtime Fabric にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、Runtime Fabric デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して Runtime Fabric にアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用した Runtime Fabric へのアプリケーションのデプロイ](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) ## [](#前提条件)前提条件 - Mule Maven プラグインがプロジェクトに追加されていることを確認する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept#add-mmp)​を参照してください。 - Runtime Fabric へのデプロイに必要なリソースの数を理解し、使用できる 詳細は、[Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed)を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 ## [](#deploying-to-rtf)Runtime Fabric デプロイメント戦略の設定 `plugin`​ 要素内に Runtime Fabric デプロイメント用の設定を追加し、次のプレースホルダーの値を Runtime Fabric 情報で置き換えます。 ```xml Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::example$mmp-concept-config.xml[] https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## [](#runtime-fabric-へのデプロイ)Runtime Fabric へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean deploy -DmuleDeploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange のスナップショットアセットを Runtime Fabric にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされたら、Mule Maven プラグインを使用して ​`SNAPSHOT`​ バージョンのアプリケーションを Runtime Fabric に再デプロイし、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。 スナップショットアセットはデプロイメント後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#runtime-fabric-への再デプロイ)Runtime Fabric への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 Runtime Fabric は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] 設定パラメーターの詳細は、​[Runtime Fabric デプロイメントのパラメーターリファレンス](#rtf-deploy-reference)​を参照してください。 ## [](#rtf-deploy-reference)Runtime Fabric デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

runtimeFabricDeployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

Runtime Fabric インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。
値の例: 4.5.0

はい

releaseChannel

Mule イメージを選択するために使用されるリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。デフォルトでは、この値は ​EDGE​ に設定されています。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

デプロイで使用される Java バージョンを設定します。サポートされている値は ​8​ と ​17​ です。デフォルトでは、この値は ​8​ に設定されています。選択された Java バージョンが存在しない場合、エラーが発生します。

いいえ

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

target

アプリケーションをデプロイする Runtime Fabric 対象名。

はい

provider

プロバイダー MC (MuleSoft コントロールプレーン) は、デプロイメントが Anypoint Runtime Manager を介して管理されていることを示します。Runtime Fabric では ​MC​ に設定します。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。アプリケーションあたりのレプリカの最大数は 8 です。

autoscaling​ が ​false​ に設定されている場合のみ。 Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

forwardSslSession

セッション中に SSL 転送を有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <forwardSslSession>true</forwardSslSession>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

lastMileSecurity

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。
このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。
設定例:

<deploymentSettings>
    <lastMileSecurity>true</lastMileSecurity>
</deploymentSettings>

resources

cpu​

reserved​

アプリケーションの各レプリカに割り当てるコア数を指定します。デフォルト値は 0.5 vCore です。

limit​

アプリケーションの各レプリカに割り当てる最大コア数を指定します。
​reserved​ 設定が存在する場合、この値がそれ以上であることを確認してください。

memory​

reserved​

アプリケーションの各レプリカに割り当てるメモリ量を指定します。デフォルト値は 700 MB です。

設定例:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。

ワイルドカード URL を使用した設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

単一証明書の単一 URL を使用した設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>wwww.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

永続的なオブジェクトストアを使用するように Mule アプリケーションを設定します。デフォルトでは、これは ​false​ に設定されます。

jvm

args​

アプリケーションのデプロイ時に Runtime Fabric に渡す JVM 引数を指定します。各引数を区切るには空白を使用します。

設定例:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

このパラメーターが true に設定されている場合、Runtime Fabric は、デプロイ済みアプリケーションの公開 URL を生成します。

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションレベルログの転送を無効にします。デフォルトでは、これは ​false​ に設定されます。

autoscaling

デプロイメントおよび再デプロイメント操作で CPU ベースの水平自動スケーリング設定を指定します。autoscaling が無効になっていて、​minReplicas​ および ​maxReplicas​ 項目が指定されている場合、それらは ​target.replicas​ 項目の値と一致している必要があります。​「トレースデータ収集の有効化」​を参照してください。 設定例:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## [](#ログイン情報の暗号化)ログイン情報の暗号化 Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] + ```xml ... ... ... my.anypoint.credentials ... ... ... ``` \+ NOTE: ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。 ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\]

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを Anypoint Runtime Fabric にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、Runtime Fabric デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して Runtime Fabric にアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用した Runtime Fabric へのアプリケーションのデプロイ](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) ## [](#前提条件)前提条件 - Mule Maven プラグインがプロジェクトに追加されていることを確認する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept#add-mmp)​を参照してください。 - Runtime Fabric へのデプロイに必要なリソースの数を理解し、使用できる 詳細は、[Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed)を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 ## [](#deploying-to-rtf)Runtime Fabric デプロイメント戦略の設定 `plugin`​ 要素内に Runtime Fabric デプロイメント用の設定を追加し、次のプレースホルダーの値を Runtime Fabric 情報で置き換えます。 ```xml Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::example$mmp-concept-config.xml[] https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## [](#runtime-fabric-へのデプロイ)Runtime Fabric へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean deploy -DmuleDeploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange のスナップショットアセットを Runtime Fabric にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされたら、Mule Maven プラグインを使用して ​`SNAPSHOT`​ バージョンのアプリケーションを Runtime Fabric に再デプロイし、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。 スナップショットアセットはデプロイメント後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#runtime-fabric-への再デプロイ)Runtime Fabric への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 Runtime Fabric は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] 設定パラメーターの詳細は、​[Runtime Fabric デプロイメントのパラメーターリファレンス](#rtf-deploy-reference)​を参照してください。 ## [](#rtf-deploy-reference)Runtime Fabric デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

runtimeFabricDeployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

Runtime Fabric インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。 デフォルトでは、使用可能な最新の Mule バージョンが選択されます。
値の例: 4.6.0​ ではデフォルトで Edge チャネルと Java 8 になる最新のビルドが選択されます。異なる LTS または Edge の選択や Java バージョンを選択する場合は、​4.6.0:1e-java17​ のように完全な Mule バージョン名を指定します。
デプロイメントに Mule Maven プラグインバージョン 3.8.0 および 4.0.0 を使用している場合、​muleVersion​ プロパティで ​releaseChannel​ と ​javaVersion​ を指定できません。これらのプロパティを指定するには、プラグインをバージョン 4.1.1 以降にアップグレードします。

いいえ

releaseChannel

Mule イメージを選択するために使用されるリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。デフォルトでは、この値は ​EDGE​ に設定されています。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

デプロイで使用される Java バージョンを設定します。サポートされている値は ​8​ と ​17​ です。デフォルトでは、この値は ​8​ に設定されています。選択された Java バージョンが存在しない場合、エラーが発生します。

いいえ

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

target

アプリケーションをデプロイする Runtime Fabric 対象名。

はい

provider

プロバイダー MC (MuleSoft コントロールプレーン) は、デプロイメントが Anypoint Runtime Manager を介して管理されていることを示します。Runtime Fabric では ​MC​ に設定します。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。アプリケーションあたりのレプリカの最大数は 8 です。

autoscaling​ が ​false​ に設定されている場合のみ。 Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

forwardSslSession

セッション中に SSL 転送を有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <forwardSslSession>true</forwardSslSession>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

lastMileSecurity

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。
このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。
設定例:

<deploymentSettings>
    <lastMileSecurity>true</lastMileSecurity>
</deploymentSettings>

resources

cpu​

reserved​

アプリケーションの各レプリカに割り当てるコア数を指定します。デフォルト値は 0.5 vCore です。

limit​

アプリケーションの各レプリカに割り当てる最大コア数を指定します。
​reserved​ 設定が存在する場合、この値がそれ以上であることを確認してください。

memory​

reserved​

アプリケーションの各レプリカに割り当てるメモリ量を指定します。デフォルト値は 700 MB です。

limit​

アプリケーションレプリカごとに割り当てる最大メモリを指定します。​reserved​ 設定が存在する場合、この値がそれ以上であることを確認してください。

設定例:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。

ワイルドカード URL を使用した設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

単一証明書の単一 URL を使用した設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>wwww.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

永続的なオブジェクトストアを使用するように Mule アプリケーションを設定します。デフォルトでは、これは ​false​ に設定されます。

jvm

args​

アプリケーションのデプロイ時に Runtime Fabric に渡す JVM 引数を指定します。各引数を区切るには空白を使用します。

設定例:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

このパラメーターが true に設定されている場合、Runtime Fabric は、デプロイ済みアプリケーションの公開 URL を生成します。

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションレベルログの転送を無効にします。デフォルトでは、これは ​false​ に設定されます。

autoscaling

デプロイメントおよび再デプロイメント操作で CPU ベースの水平自動スケーリング設定を指定します。autoscaling が無効になっていて、​minReplicas​ および ​maxReplicas​ 項目が指定されている場合、それらは ​target.replicas​ 項目の値と一致している必要があります。​「トレースデータ収集の有効化」​を参照してください。 設定例:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## [](#ログイン情報の暗号化)ログイン情報の暗号化 Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] + ```xml ... ... ... my.anypoint.credentials ... ... ... ``` \+ NOTE: ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。 ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\]

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを Anypoint Runtime Fabric にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、Runtime Fabric デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して Runtime Fabric にアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用した Runtime Fabric へのアプリケーションのデプロイ](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) ## [](#前提条件)前提条件 - Mule Maven プラグインがプロジェクトに追加されていることを確認する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept#add-mmp)​を参照してください。 - Runtime Fabric へのデプロイに必要なリソースの数を理解し、使用できる 詳細は、[Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed)を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 ## [](#deploying-to-rtf)Runtime Fabric デプロイメント戦略の設定 `plugin`​ 要素内に Runtime Fabric デプロイメント用の設定を追加し、次のプレースホルダーの値を Runtime Fabric 情報で置き換えます。 ```xml Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::example$mmp-concept-config.xml[] https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## [](#runtime-fabric-へのデプロイ)Runtime Fabric へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean deploy -DmuleDeploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange のスナップショットアセットを Runtime Fabric にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされたら、Mule Maven プラグインを使用して ​`SNAPSHOT`​ バージョンのアプリケーションを Runtime Fabric に再デプロイし、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。

スナップショットアセットはデプロイメント後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#runtime-fabric-への再デプロイ)Runtime Fabric への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 Runtime Fabric は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] 設定パラメーターの詳細は、​[Runtime Fabric デプロイメントのパラメーターリファレンス](#rtf-deploy-reference)​を参照してください。 ## [](#rtf-deploy-reference)Runtime Fabric デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

runtimeFabricDeployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

Runtime Fabric インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。 デフォルトでは、使用可能な最新の Mule バージョンが選択されます。
値の例: 4.6.0​ ではデフォルトで Edge チャネルと Java 8 になる最新のビルドが選択されます。異なる LTS または Edge の選択や Java バージョンを選択する場合は、​4.6.0:1e-java17​ のように完全な Mule バージョン名を指定します。
デプロイメントに Mule Maven プラグインバージョン 3.8.0 および 4.0.0 を使用している場合、​muleVersion​ プロパティで ​releaseChannel​ と ​javaVersion​ を指定できません。これらのプロパティを指定するには、プラグインをバージョン 4.1.1 以降にアップグレードします。

いいえ

releaseChannel

Mule イメージを選択するために使用されるリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。デフォルトでは、この値は ​EDGE​ に設定されています。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

デプロイで使用される Java バージョンを設定します。サポートされている値は ​8​ と ​17​ です。デフォルトでは、この値は ​8​ に設定されています。選択された Java バージョンが存在しない場合、エラーが発生します。

いいえ

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

target

アプリケーションをデプロイする Runtime Fabric 対象名。

はい

provider

プロバイダー MC (MuleSoft コントロールプレーン) は、デプロイメントが Anypoint Runtime Manager を介して管理されていることを示します。Runtime Fabric では ​MC​ に設定します。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。アプリケーションあたりのレプリカの最大数は 16 です。

autoscaling​ が ​false​ に設定されている場合のみ。 Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[] Unresolved include directive in modules/ROOT/pages/_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc[]

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

forwardSslSession

セッション中に SSL 転送を有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <forwardSslSession>true</forwardSslSession>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

lastMileSecurity

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。
このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。
設定例:

<deploymentSettings>
    <lastMileSecurity>true</lastMileSecurity>
</deploymentSettings>

resources

cpu​

reserved​

アプリケーションの各レプリカに割り当てるコア数を指定します。デフォルト値は 0.5 vCore です。

limit​

アプリケーションの各レプリカに割り当てる最大コア数を指定します。
​reserved​ 設定が存在する場合、この値がそれ以上であることを確認してください。

memory​

reserved​

アプリケーションの各レプリカに割り当てるメモリ量を指定します。デフォルト値は 700 MB です。

limit​

アプリケーションレプリカごとに割り当てる最大メモリを指定します。​reserved​ 設定が存在する場合、この値がそれ以上であることを確認してください。

設定例:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。

ワイルドカード URL を使用した設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

単一証明書の単一 URL を使用した設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>wwww.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

永続的なオブジェクトストアを使用するように Mule アプリケーションを設定します。デフォルトでは、これは ​false​ に設定されます。

jvm

args​

アプリケーションのデプロイ時に Runtime Fabric に渡す JVM 引数を指定します。各引数を区切るには空白を使用します。

設定例:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

このパラメーターが true に設定されている場合、Runtime Fabric は、デプロイ済みアプリケーションの公開 URL を生成します。

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションレベルログの転送を無効にします。デフォルトでは、これは ​false​ に設定されます。

autoscaling

デプロイメントおよび再デプロイメント操作で CPU ベースの水平自動スケーリング設定を指定します。autoscaling が無効になっていて、​minReplicas​ および ​maxReplicas​ 項目が指定されている場合、それらは ​target.replicas​ 項目の値と一致している必要があります。​「トレースデータ収集の有効化」​を参照してください。 設定例:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## [](#ログイン情報の暗号化)ログイン情報の暗号化 Unresolved include directive in modules/ROOT/pages/\_partials/mmp-deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] + ```xml ... ... ... my.anypoint.credentials ... ... ... ``` \+ NOTE: ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。 ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-to-rtf.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Runtime Manager を使用してアプリケーションを Anypoint Runtime Fabric にデプロイすることに加えて、Mule Maven プラグインを使用してアプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、Runtime Fabric デプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用して Runtime Fabric にアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用した Runtime Fabric へのアプリケーションのデプロイ](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric) ## [](#前提条件)前提条件 - Mule Maven プラグインがプロジェクトに追加されていることを確認する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept#add-mmp)​を参照してください。 - Runtime Fabric へのデプロイに必要なリソースの数を理解し、使用できる 詳細は、[Allocating Resources for Application Deployment on Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/deploy-resource-allocation-self-managed)を参照してください。 - アプリケーションが Exchange ですでにパブリッシュされている [「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。 ## [](#deploying-to-rtf)Runtime Fabric デプロイメント戦略の設定 `plugin`​ 要素内に Runtime Fabric デプロイメント用の設定を追加し、次のプレースホルダーの値を Runtime Fabric 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com 4.3.0 user pass newapp rtf Sandbox MC 1 value false recreate false false false 20m 1500m 700Mi url ``` ## [](#runtime-fabric-へのデプロイ)Runtime Fabric へのデプロイ プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```bash mvn clean deploy -DmuleDeploy ``` ### [](#exchange-のスナップショットアセット)Exchange のスナップショットアセット Exchange のスナップショットアセットを Runtime Fabric にデプロイすることもできます。 開発フェーズとテストフェーズで Anypoint Exchange の ​`SNAPSHOT`​ バージョンアセットを使用して、些細な変更でアプリケーションのバージョン番号を増分することを回避できます。​`SNAPSHOT`​ バージョンのアプリケーションが Anypoint Exchange で上書きされたら、Mule Maven プラグインを使用して ​`SNAPSHOT`​ バージョンのアプリケーションを Runtime Fabric に再デプロイし、最新の変更をデプロイできます。 スナップショットアセットを Anypoint Exchange にパブリッシュする方法についての詳細は、​[アセットライフサイクル状態](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven#asset-lifecycle-state)​を参照してください。

アプリケーションのスナップショットを更新するたびに、アプリケーションを再デプロイして最新のスナップショットバイナリで更新します。

スナップショットアセットはデプロイメント後に変更される可能性があるため、本番環境にはデプロイしないでください。
## [](#runtime-fabric-への再デプロイ)Runtime Fabric への再デプロイ アプリケーションを再デプロイするには、デプロイしたときと同じコマンドを実行します。 Runtime Fabric は、デプロイしたアプリケーションを書き込み直します。 ## [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

Runtime Fabric のユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[Runtime Fabric デプロイメントのパラメーターリファレンス](#rtf-deploy-reference)​を参照してください。 ## [](#rtf-deploy-reference)Runtime Fabric デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

runtimeFabricDeployment

最上位要素

はい

uri

Anypoint Platform URI。
設定しない場合、デフォルトの https://anypoint.mulesoft.com になります。

いいえ

muleVersion

Runtime Fabric インスタンスで実行する Mule Runtime Engine のバージョン。
この値がアプリケーションで最小限必要な Mule バージョン以上であることを確認します。 デフォルトでは、使用可能な最新の Mule バージョンが選択されます。
値の例: 4.6.0​ ではデフォルトで Edge チャネルと Java 8 になる最新のビルドが選択されます。異なる LTS または Edge の選択や Java バージョンを選択する場合は、​4.6.0:1e-java17​ のように完全な Mule バージョン名を指定します。
デプロイメントに Mule Maven プラグインバージョン 3.8.0 および 4.0.0 を使用している場合、​muleVersion​ プロパティで ​releaseChannel​ と ​javaVersion​ を指定できません。これらのプロパティを指定するには、プラグインをバージョン 4.1.1 以降にアップグレードします。

いいえ

releaseChannel

Mule イメージを選択するために使用されるリリースチャネル名を設定します。サポートされている値は、​NONE​、​EDGE​、​LTS​ です。デフォルトでは、この値は ​EDGE​ に設定されています。選択されたリリースチャネルが存在しない場合、エラーが発生します。

いいえ

javaVersion

デプロイで使用される Java バージョンを設定します。サポートされている値は ​8​ と ​17​ です。デフォルトでは、この値は ​8​ に設定されています。選択された Java バージョンが存在しない場合、エラーが発生します。

いいえ

username

Anypoint Platform ユーザー名

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Anypoint Platform パスワード

Anypoint Platform ログイン情報を使用してログインする場合のみ。

applicationName

アプリケーションのデプロイ後に Runtime Manager に表示されるアプリケーション名。

はい

target

アプリケーションをデプロイする Runtime Fabric 対象名。

はい

provider

プロバイダー MC (MuleSoft コントロールプレーン) は、デプロイメントが Anypoint Runtime Manager を介して管理されていることを示します。Runtime Fabric では ​MC​ に設定します。

はい

environment

対象の Anypoint Platform 環境。
この値は、次のように Anypoint Platform アカウントで設定された環境に一致する必要があります。

<environment>Sandbox</environment>

はい

replicas

デプロイする Mule アプリケーションのレプリカまたはインスタンスの数を指定します。アプリケーションあたりのレプリカの最大数は 16 です。

autoscaling​ が ​false​ に設定されている場合のみ。

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

​secureProperties​

最上位要素
secureProperties​ 最上位要素を使用して Mule アプリケーションのプロパティを設定し、値を保存する前に暗号化するように Runtime Fabric に指示します。

<secureProperties>
  <key>value</key>
</secureProperties>

次に例を示します。

<secureProperties>
  <http.port>8081</http.port>
</secureProperties>

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

deploymentSettings

deploymentSettings リファレンス​で説明されているいずれかのパラメーター

いいえ
### [](#deployment-settings)deploymentSettings パラメーターリファレンス
パラメーター 説明

enforceDeployingReplicasAcrossNodes

異なるノード間でレプリカのデプロイメントを適用します。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy
使用可能な値 説明

rolling​

レプリカを増分的に更新することで、可用性を維持します。成功するには、レプリカに相当する 1 つの追加リソースが必要です。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの総数より 1 つ少なくなります。

recreate​

再デプロイメントの前にレプリカを終了します。再デプロイメントは ​rolling​ よりも迅速で、追加リソースは必要ありません。
enforceDeployingReplicasAcrossNodes​ が有効になっている場合、設定できるレプリカの最大数はノードの数と同じです。

デフォルト値は ​rolling​ です。

設定例:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

forwardSslSession

セッション中に SSL 転送を有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
  <forwardSslSession>true</forwardSslSession>
</deploymentSettings>

clustered

アプリケーションの複数のレプリカでのクラスタリングを有効にします。デフォルト値は ​false​ です。

設定例:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

lastMileSecurity

Last-Mile セキュリティを有効化して、このアプリケーションによって復号化される HTTPS 接続を転送します。
このためには SSL 証明書を Mule アプリケーションに含む必要があり、より多くの CPU リソースも必要です。デフォルト値は ​false​ です。
設定例:

<deploymentSettings>
    <lastMileSecurity>true</lastMileSecurity>
</deploymentSettings>

resources

cpu​

reserved​

アプリケーションの各レプリカに割り当てるコア数を指定します。デフォルト値は 0.5 vCore です。

limit​

アプリケーションの各レプリカに割り当てる最大コア数を指定します。
​reserved​ 設定が存在する場合、この値がそれ以上であることを確認してください。

memory​

reserved​

アプリケーションの各レプリカに割り当てるメモリ量を指定します。デフォルト値は 700 MB です。

limit​

アプリケーションレプリカごとに割り当てる最大メモリを指定します。​reserved​ 設定が存在する場合、この値がそれ以上であることを確認してください。

設定例:

<deploymentSettings>
  <resources>
    <cpu>
      <reserved>20m</reserved>
      <limit>1500m</limit>
    </cpu>
    <memory>
      <reserved>700Mi</reserved>
    </memory>
  </resources>
</deploymentSettings>

http

inbound​

publicURL​

デプロイされるアプリケーションの URL。

ワイルドカード URL を使用した設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>myapp.example.com</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

単一証明書の単一 URL を使用した設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>wwww.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

Runtime Fabric BYOK の設定例:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://www.example.com/myapp</publicUrl>
    </inbound>
  </http>
</deploymentSettings>

persistentObjectStore

永続的なオブジェクトストアを使用するように Mule アプリケーションを設定します。デフォルトでは、これは ​false​ に設定されます。

jvm

args​

アプリケーションのデプロイ時に Runtime Fabric に渡す JVM 引数を指定します。各引数を区切るには空白を使用します。

設定例:

<deploymentSettings>
  <jvm>
    <args>
      -XX:MaxMetaspaceSize=500m -XX:MaxRAMPercentage=60.0
    </args>
  </jvm>
</deploymentSettings>

generateDefaultPublicUrl

このパラメーターが true に設定されている場合、Runtime Fabric は、デプロイ済みアプリケーションの公開 URL を生成します。

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションレベルログの転送を無効にします。デフォルトでは、これは ​false​ に設定されます。

autoscaling

デプロイメントおよび再デプロイメント操作で CPU ベースの水平自動スケーリング設定を指定します。autoscaling が無効になっていて、​minReplicas​ および ​maxReplicas​ 項目が指定されている場合、それらは ​target.replicas​ 項目の値と一致している必要があります。​「トレースデータ収集の有効化」​を参照してください。 設定例:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>
## [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Mule Maven プラグインを使用したオンプレミス Mule インスタンスへのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションをオンプレミスでデプロイすることに加えて、Mule Maven プラグインを使用して Mule アプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、目的のデプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用してオンプレミスにアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) - [Anypoint Platform CLI を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/standalone-apps#runtime-mgr-standalone-application-deploy) - [Anypoint Studio を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) ## [](#オンプレミスデプロイメント戦略)オンプレミスデプロイメント戦略 Mule Maven プラグインを使用してアプリケーションをオンプレミスにデプロイする場合、3 つの異なるデプロイメント方法を選択できます。 - スタンドアロンデプロイメント この方法を使用して、オンプレミス Mule インスタンスに Mule アプリケーションを手動でデプロイします。 - Runtime Manager REST API デプロイメント この方法を使用すると、Runtime Manager REST API を使用してアプリケーションをデプロイできます。これにより、オンプレミス Mule インスタンスが Anypoint Runtime Manager アカウントにリンクされ、デプロイしたアプリケーションをさらに管理および監視できます。 - Runtime Manager エージェントデプロイメント この方法を使用すると、Runtime Manager エージェントを使用してアプリケーションをデプロイできます。これにより、ローカル API が公開され、その API をコールして、デプロイしたアプリケーションを管理および監視できます。 スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合、Mule Maven プラグインはドメインのデプロイもサポートします。 追加の操作により、複数のアプリケーションを並列にデプロイしたり、実行時にアプリケーションを更新したりできます。 ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept#add-mmp)​を参照してください。 ## [](#mmp-deploy-standalone)スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.4.2 true ${mule.home.test} ${app.runtime} ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean package deploy -DmuleDeploy ``` ### [](#standalone-deploy-reference)スタンドアロンデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

standaloneDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

ローカルマシンインスタンスで実行する Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

muleHome

ローカルマシンにおける Mule インスタンスの場所。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#mmp-deploy-arm)Runtime Manager REST API を使用した Mule アプリケーションのデプロイ Mule Maven プラグインを使用すると、Runtime Manager REST API を使用してローカルの Mule インスタンスに Mule アプリケーションをデプロイできます。 ### [](#前提条件-2)前提条件 - Runtime Manager で作成されたサーバー、サーバーグループ、またはクラスターが必要です。 - サーバーを作成するには、​[「サーバーの追加」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 - サーバーグループを作成するには、​[「サーバーグループの作成」](https://docs.mulesoft.com/jp/runtime-manager/server-group-create)​を参照してください。 - クラスターを作成するには、​[「クラスターの作成」](https://docs.mulesoft.com/jp/runtime-manager/cluster-create)​を参照してください。 ### [](#runtime-manager-rest-api-を使用したデプロイ)Runtime Manager REST API を使用したデプロイ `plugin`​ 要素内に Runtime Manager デプロイメント用の設定を追加し、プレースホルダーの値を Runtime Manager 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.4.2 true ${app.runtime} https://anypoint.mulesoft.com ${target} ${target.type} ${username} ${password} ${environment} value ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean package deploy -DmuleDeploy ``` ### [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

Mule インスタンスがインストールされているサーバーのユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[Runtime Manager REST API デプロイメントのパラメーターリファレンス](#arm-deploy-reference)​を参照してください。 ### [](#arm-deploy-reference)Runtime Manager REST API デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

armDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Anypoint Platform URI。Anypoint Platform PCE を使用している場合、Anypoint Platform インストールの URI を使用してこのパラメーターを指定します。
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

target

Mule インスタンスをインストールするサーバーのサーバー名。

はい

targetType

デプロイ先の対象の種別。

有効な値:

  • サーバー

  • serverGroup

  • クラスター

はい

username

Mule インスタンスをインストールするサーバーのユーザー名。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Mule インスタンスをインストールするサーバーのパスワード。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

environment

Mule インスタンスをインストールするサーバーの環境名。この値は、Runtime Manager アカウントで設定されたいずれかの環境に一致する必要があります。
例:

<environment>Sandbox</environment>

はい

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。
### [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
### [](#anypoint-private-cloud-edition-での-tls-エラーのトラブルシューティング)Anypoint Private Cloud Edition での TLS エラーのトラブルシューティング [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/)​ インストールの Runtime Manager のインスタンスに接続しようとすると、プラグインはそのサーバーのログイン情報を検証します。トラストストアにサーバーログイン情報をインストールしていない場合、SSL エラーが発生します。この問題を回避するために、非セキュアモードでプラグインを実行できます。このモードでは、セキュリティ検証がスキップされます。​**armInsecure**​ タグまたは ​**arm.insecure**​ システムプロパティを使用できます。
非セキュア接続を有効にするのは危険です。実行内容を理解し、オンプレミスインストールがローカルネットワークに隔離されている場合を除き、使用しないでください。
下の設定例を参照してください。 ```xml org.mule.tools.maven mule-maven-plugin 3.4.2 true ${target} ${target.type} ${username} ${password} ${environment} true ``` ## [](#mmp-deploy-agent)Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ `plugin`​ 要素内に Runtime Manager エージェントデプロイメント用の設定を追加し、URI の値をリモートサーバー情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.4.2 true http://localhost:9999/ ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean package deploy -DmuleDeploy ``` ### [](#arm-agent-deploy-reference)Runtime Manager エージェントデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

agentDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Mule インスタンスをインストールするサーバーの URI。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#deploy-a-domain)ドメインのデプロイ スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合のみ、Mule Maven プラグインはドメインのデプロイをサポートします。 ドメインをデプロイするには、アプリケーションのデプロイ時に使用するものと同じ設定とデプロイメント手順を使用します。たとえば、スタンドアロンインスタンスにドメインをデプロイするには、次の手順を実行します。 1. `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.4.2 true ${mule.home.test} ${app.runtime} ``` 2. プロジェクトのフォルダーのコマンドラインから、ドメインをパッケージ化してデプロイゴールを実行します。 ```console mvn clean package deploy -DmuleDeploy ``` ## [](#並列でのアプリケーションのデプロイ)並列でのアプリケーションのデプロイ オンプレミス Mule インスタンスに複数のアプリケーションを並列にデプロイできます。多数のアプリケーションをデプロイする場合は、並列にデプロイすると起動時間を短縮できます。起動順序は不特定であるため、デプロイメントが失敗しないように、アプリケーションが相互連動していないことを確認します。 並列処理は 20 で固定されています。 並列デプロイを有効にする手順は次のとおりです。 1. Mule アプリケーションを Mule Runtime Engine インスタンスの ​`/apps`​ ディレクトリにパッケージ (エクスポート) します。 2. `-M-Dmule.deployment.parallel`​ オプションを使用して Mule を起動します。 ```none mule -M-Dmule.deployment.parallel ``` これらの手順を実行すると、Mule は ​`/apps`​ ディレクトリにあるすべてのアプリケーションを並列にデプロイします。 ## [](#実行時のアプリケーションの更新)実行時のアプリケーションの更新 実行時の Mule アプリケーションの更新は、クラスの変更、エンドポイントの変更 (ポートの変更など)、フローの再設定を伴う複雑な変更になる場合があります。アプリケーションの更新では、最初にアプリケーションを適切にシャットダウンしてから、数秒以内にバックグラウンドでアプリケーションを再設定します。このプロセスは、ユーザーに対して透過的に行われます。 アプリケーションは、2 つの方法で更新できます。 - 展開された既存のアプリケーションフォルダーに変更を追加して、メイン設定ファイル (デフォルトではアプリケーションルートディレクトリにある ​`mule-config.xml`​) を操作する。 - 更新されたバージョンのアプリケーションを含む新しい ​`jar`​ を ​`$MULE_HOME/apps`​ ディレクトリに追加する。Mule は、​`jar`​ を既存アプリケーションの更新バージョンとして検出し、アプリケーションのクリーンな再デプロイを実行します。 Mule は、古いアプリケーションフォルダーへの変更を破棄します。新しいアプリケーションフォルダーは、​`jar`​ から展開されたクリーンなアプリケーションフォルダーです。 どちらの方法も、既存のビルドツールと適切に統合されます。 ## [](#関連情報)関連情報 - [Anypoint Studio エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept) # Mule Maven プラグインを使用したオンプレミス Mule インスタンスへのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションをオンプレミスでデプロイすることに加えて、Mule Maven プラグインを使用して Mule アプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、目的のデプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用してオンプレミスにアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) - [Anypoint Platform CLI を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/standalone-apps#runtime-mgr-standalone-application-deploy) - [Anypoint Studio を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) ## [](#オンプレミスデプロイメント戦略)オンプレミスデプロイメント戦略 Mule Maven プラグインを使用してアプリケーションをオンプレミスにデプロイする場合、3 つの異なるデプロイメント方法を選択できます。 - スタンドアロンデプロイメント この方法を使用して、オンプレミス Mule インスタンスに Mule アプリケーションを手動でデプロイします。 - Runtime Manager REST API デプロイメント この方法を使用すると、Runtime Manager REST API を使用してアプリケーションをデプロイできます。これにより、オンプレミス Mule インスタンスが Anypoint Runtime Manager アカウントにリンクされ、デプロイしたアプリケーションをさらに管理および監視できます。 - Runtime Manager エージェントデプロイメント この方法を使用すると、Runtime Manager エージェントを使用してアプリケーションをデプロイできます。これにより、ローカル API が公開され、その API をコールして、デプロイしたアプリケーションを管理および監視できます。 スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合、Mule Maven プラグインはドメインのデプロイもサポートします。 追加の操作により、複数のアプリケーションを並列にデプロイしたり、実行時にアプリケーションを更新したりできます。 ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept#add-mmp)​を参照してください。 ## [](#mmp-deploy-standalone)スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#standalone-deploy-reference)スタンドアロンデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

standaloneDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

ローカルマシンインスタンスで実行する Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

muleHome

ローカルマシンにおける Mule インスタンスの場所。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#mmp-deploy-arm)Runtime Manager REST API を使用した Mule アプリケーションのデプロイ Mule Maven プラグインを使用すると、Runtime Manager REST API を使用してローカルの Mule インスタンスに Mule アプリケーションをデプロイできます。 ### [](#前提条件-2)前提条件 - Runtime Manager で作成されたサーバー、サーバーグループ、またはクラスターが必要です。 - サーバーを作成するには、​[「サーバーの追加」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 - サーバーグループを作成するには、​[「サーバーグループの作成」](https://docs.mulesoft.com/jp/runtime-manager/server-group-create)​を参照してください。 - クラスターを作成するには、​[「クラスターの作成」](https://docs.mulesoft.com/jp/runtime-manager/cluster-create)​を参照してください。 ### [](#runtime-manager-rest-api-を使用したデプロイ)Runtime Manager REST API を使用したデプロイ `plugin`​ 要素内に Runtime Manager デプロイメント用の設定を追加し、プレースホルダーの値を Runtime Manager 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${app.runtime} https://anypoint.mulesoft.com ${target} ${target.type} ${username} ${password} ${environment} value ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

Mule インスタンスがインストールされているサーバーのユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、「​[Runtime Manager REST API デプロイメントのパラメーターリファレンス](#arm-deploy-reference)​」を参照してください。 ### [](#arm-deploy-reference)Runtime Manager REST API デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

armDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Anypoint Platform URI。Anypoint Platform PCE を使用している場合、Anypoint Platform インストールの URI を使用してこのパラメーターを指定します。
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

target

Mule インスタンスをインストールするサーバーのサーバー名。

はい

targetType

デプロイ先の対象の種別。

有効な値:

  • サーバー

  • serverGroup

  • クラスター

はい

username

Mule インスタンスをインストールするサーバーのユーザー名。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Mule インスタンスをインストールするサーバーのパスワード。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

environment

Mule インスタンスをインストールするサーバーの環境名。この値は、Runtime Manager アカウントで設定されたいずれかの環境に一致する必要があります。
例:

<environment>Sandbox</environment>

はい

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの状況検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。
### [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
### [](#anypoint-private-cloud-edition-での-tls-エラーのトラブルシューティング)Anypoint Private Cloud Edition での TLS エラーのトラブルシューティング [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/)​ インストールの Runtime Manager のインスタンスに接続しようとすると、プラグインはそのサーバーのログイン情報を検証します。トラストストアにサーバーログイン情報をインストールしていない場合、SSL エラーが発生します。この問題を回避するために、非セキュアモードでプラグインを実行できます。このモードでは、セキュリティ検証がスキップされます。​**armInsecure**​ タグまたは ​**arm.insecure**​ システムプロパティを使用できます。
非セキュア接続を有効にするのは危険です。実行内容を理解し、オンプレミスインストールがローカルネットワークに隔離されている場合を除き、使用しないでください。
下の設定例を参照してください。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${target} ${target.type} ${username} ${password} ${environment} true ``` ## [](#mmp-deploy-agent)Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ `plugin`​ 要素内に Runtime Manager エージェントデプロイメント用の設定を追加し、URI の値をリモートサーバー情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true http://localhost:9999/ ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#arm-agent-deploy-reference)Runtime Manager エージェントデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

agentDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Mule インスタンスをインストールするサーバーの URI。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#deploy-a-domain)ドメインのデプロイ スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合のみ、Mule Maven プラグインはドメインのデプロイをサポートします。 ドメインをデプロイするには、アプリケーションのデプロイ時に使用するものと同じ設定とデプロイメント手順を使用します。たとえば、スタンドアロンインスタンスにドメインをデプロイするには、次の手順を実行します。 1. `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` 2. プロジェクトのフォルダーのコマンドラインから、ドメインをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#並列でのアプリケーションのデプロイ)並列でのアプリケーションのデプロイ オンプレミス Mule インスタンスに複数のアプリケーションを並列にデプロイできます。多数のアプリケーションをデプロイする場合は、並列にデプロイすると起動時間を短縮できます。起動順序は不特定であるため、デプロイメントが失敗しないように、アプリケーションが相互連動していないことを確認します。 並列処理は 20 で固定されています。 並列デプロイを有効にする手順は次のとおりです。 1. Mule アプリケーションを Mule Runtime Engine インスタンスの ​`/apps`​ ディレクトリにパッケージ (エクスポート) します。 2. `-M-Dmule.deployment.parallel`​ オプションを使用して Mule を起動します。 ```none mule -M-Dmule.deployment.parallel ``` これらの手順を実行すると、Mule は ​`/apps`​ ディレクトリにあるすべてのアプリケーションを並列にデプロイします。 ## [](#アプリケーションのアンデプロイ)アプリケーションのアンデプロイ Mule アプリケーションは、アプリケーションフォルダーを直接削除するのではなく、アプリケーションのアンカーファイルを削除することでアンデプロイできます。 アプリケーションのアンカーファイルのみを削除することで、次のようになります。 - ホットデプロイメントレイヤーからの干渉を防止し、同時の競合アクションの余地をなくします。 - 一部のオペレーションシステムでアプリケーションの JAR ファイルがロックする問題を回避し、クリーンなシャットダウンとアンデプロイメントを可能にします。 たとえば、​`stockTrader`​ アプリケーションが実行されている (アプリケーションフォルダーと ​`$MULE_HOME/apps/stockTrader-anchor.txt`​ ファイルが存在) 場合、アンカーファイルを削除するだけで実行時にアプリケーション Mule インスタンスから削除されます。アプリケーションフォルダーはアプリケーションの終了後に削除されます。
Mule アプリケーションをアンデプロイした後で、​LoggerContext​ が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。 Mule アプリケーションをアンデプロイした後で、LoggerContext が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。
## [](#実行時のアプリケーションの更新)実行時のアプリケーションの更新 実行時の Mule アプリケーションの更新は、クラスの変更、エンドポイントの変更 (ポートの変更など)、フローの再設定を伴う複雑な変更になる場合があります。アプリケーションの更新では、最初にアプリケーションを適切にシャットダウンしてから、数秒以内にバックグラウンドでアプリケーションを再設定します。このプロセスは、ユーザーに対して透過的に行われます。 アプリケーションは、2 つの方法で更新できます。 - 展開された既存のアプリケーションフォルダーに変更を追加して、メイン設定ファイル (デフォルトではアプリケーションルートディレクトリにある ​`mule-config.xml`​) を操作する。 このオプションを有効にするには、システムプロパティ ​`-M-Dmule.deployment.forceParseConfigXmls=true`​ を使用して Runtime を起動します。 - 更新されたバージョンのアプリケーションを含む新しい ​`jar`​ を ​`$MULE_HOME/apps`​ ディレクトリに追加する。Mule は、​`jar`​ を既存アプリケーションの更新バージョンとして検出し、アプリケーションのクリーンな再デプロイを実行します。 Mule は、古いアプリケーションフォルダーへの変更を破棄します。新しいアプリケーションフォルダーは、​`jar`​ から展開されたクリーンなアプリケーションフォルダーです。 どちらの方法も、既存のビルドツールと適切に統合されます。 ## [](#関連情報)関連情報 - [Anypoint Studio エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept) # Mule Maven プラグインを使用したオンプレミス Mule インスタンスへのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションをオンプレミスでデプロイすることに加えて、Mule Maven プラグインを使用して Mule アプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、目的のデプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用してオンプレミスにアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) - [Anypoint Platform CLI を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/standalone-apps#runtime-mgr-standalone-application-deploy) - [Anypoint Studio を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) ## [](#オンプレミスデプロイメント戦略)オンプレミスデプロイメント戦略 Mule Maven プラグインを使用してアプリケーションをオンプレミスにデプロイする場合、3 つの異なるデプロイメント方法を選択できます。 - スタンドアロンデプロイメント この方法を使用して、オンプレミス Mule インスタンスに Mule アプリケーションを手動でデプロイします。 - Runtime Manager REST API デプロイメント この方法を使用すると、Runtime Manager REST API を使用してアプリケーションをデプロイできます。これにより、オンプレミス Mule インスタンスが Anypoint Runtime Manager アカウントにリンクされ、デプロイしたアプリケーションをさらに管理および監視できます。 - Runtime Manager エージェントデプロイメント この方法を使用すると、Runtime Manager エージェントを使用してアプリケーションをデプロイできます。これにより、ローカル API が公開され、その API をコールして、デプロイしたアプリケーションを管理および監視できます。 スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合、Mule Maven プラグインはドメインのデプロイもサポートします。 追加の操作により、複数のアプリケーションを並列にデプロイしたり、実行時にアプリケーションを更新したりできます。 ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept#add-mmp)​を参照してください。 ## [](#mmp-deploy-standalone)スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#standalone-deploy-reference)スタンドアロンデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

standaloneDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

ローカルマシンインスタンスで実行する Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

muleHome

ローカルマシンにおける Mule インスタンスの場所。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#mmp-deploy-arm)Runtime Manager REST API を使用した Mule アプリケーションのデプロイ Mule Maven プラグインを使用すると、Runtime Manager REST API を使用してローカルの Mule インスタンスに Mule アプリケーションをデプロイできます。 ### [](#前提条件-2)前提条件 - Runtime Manager で作成されたサーバー、サーバーグループ、またはクラスターが必要です。 - サーバーを作成するには、​[「サーバーの追加」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 - サーバーグループを作成するには、​[「サーバーグループの作成」](https://docs.mulesoft.com/jp/runtime-manager/server-group-create)​を参照してください。 - クラスターを作成するには、​[「クラスターの作成」](https://docs.mulesoft.com/jp/runtime-manager/cluster-create)​を参照してください。 ### [](#runtime-manager-rest-api-を使用したデプロイ)Runtime Manager REST API を使用したデプロイ `plugin`​ 要素内に Runtime Manager デプロイメント用の設定を追加し、プレースホルダーの値を Runtime Manager 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${app.runtime} https://anypoint.mulesoft.com ${target} ${target.type} ${username} ${password} ${environment} value ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

Mule インスタンスがインストールされているサーバーのユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、「​[Runtime Manager REST API デプロイメントのパラメーターリファレンス](#arm-deploy-reference)​」を参照してください。 ### [](#arm-deploy-reference)Runtime Manager REST API デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

armDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Anypoint Platform URI。Anypoint Platform PCE を使用している場合、Anypoint Platform インストールの URI を使用してこのパラメーターを指定します。
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

target

Mule インスタンスをインストールするサーバーのサーバー名。

はい

targetType

デプロイ先の対象の種別。

有効な値:

  • サーバー

  • serverGroup

  • クラスター

はい

username

Mule インスタンスをインストールするサーバーのユーザー名。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Mule インスタンスをインストールするサーバーのパスワード。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

environment

Mule インスタンスをインストールするサーバーの環境名。この値は、Runtime Manager アカウントで設定されたいずれかの環境に一致する必要があります。
例:

<environment>Sandbox</environment>

はい

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。
### [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
### [](#anypoint-private-cloud-edition-での-tls-エラーのトラブルシューティング)Anypoint Private Cloud Edition での TLS エラーのトラブルシューティング [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/)​ インストールの Runtime Manager のインスタンスに接続しようとすると、プラグインはそのサーバーのログイン情報を検証します。トラストストアにサーバーログイン情報をインストールしていない場合、SSL エラーが発生します。この問題を回避するために、非セキュアモードでプラグインを実行できます。このモードでは、セキュリティ検証がスキップされます。​**armInsecure**​ タグまたは ​**arm.insecure**​ システムプロパティを使用できます。
非セキュア接続を有効にするのは危険です。実行内容を理解し、オンプレミスインストールがローカルネットワークに隔離されている場合を除き、使用しないでください。
下の設定例を参照してください。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${target} ${target.type} ${username} ${password} ${environment} true ``` ## [](#mmp-deploy-agent)Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ `plugin`​ 要素内に Runtime Manager エージェントデプロイメント用の設定を追加し、URI の値をリモートサーバー情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true http://localhost:9999/ ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#arm-agent-deploy-reference)Runtime Manager エージェントデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

agentDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Mule インスタンスをインストールするサーバーの URI。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#deploy-a-domain)ドメインのデプロイ スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合のみ、Mule Maven プラグインはドメインのデプロイをサポートします。 ドメインをデプロイするには、アプリケーションのデプロイ時に使用するものと同じ設定とデプロイメント手順を使用します。たとえば、スタンドアロンインスタンスにドメインをデプロイするには、次の手順を実行します。 1. `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` 2. プロジェクトのフォルダーのコマンドラインから、ドメインをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#並列でのアプリケーションのデプロイ)並列でのアプリケーションのデプロイ オンプレミス Mule インスタンスに複数のアプリケーションを並列にデプロイできます。多数のアプリケーションをデプロイする場合は、並列にデプロイすると起動時間を短縮できます。起動順序は不特定であるため、デプロイメントが失敗しないように、アプリケーションが相互連動していないことを確認します。 並列処理は 20 で固定されています。 並列デプロイを有効にする手順は次のとおりです。 1. Mule アプリケーションを Mule Runtime Engine インスタンスの ​`/apps`​ ディレクトリにパッケージ (エクスポート) します。 2. `-M-Dmule.deployment.parallel`​ オプションを使用して Mule を起動します。 ```none mule -M-Dmule.deployment.parallel ``` これらの手順を実行すると、Mule は ​`/apps`​ ディレクトリにあるすべてのアプリケーションを並列にデプロイします。 ## [](#アプリケーションのアンデプロイ)アプリケーションのアンデプロイ Mule アプリケーションは、アプリケーションフォルダーを直接削除するのではなく、アプリケーションのアンカーファイルを削除することでアンデプロイできます。 アプリケーションのアンカーファイルのみを削除することで、次のようになります。 - ホットデプロイメントレイヤーからの干渉を防止し、同時の競合アクションの余地をなくします。 - 一部のオペレーションシステムでアプリケーションの JAR ファイルがロックする問題を回避し、クリーンなシャットダウンとアンデプロイメントを可能にします。 たとえば、​`stockTrader`​ アプリケーションが実行されている (アプリケーションフォルダーと ​`$MULE_HOME/apps/stockTrader-anchor.txt`​ ファイルが存在) 場合、アンカーファイルを削除するだけで実行時にアプリケーション Mule インスタンスから削除されます。アプリケーションフォルダーはアプリケーションの終了後に削除されます。
Mule アプリケーションをアンデプロイした後で、​LoggerContext​ が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。 Mule アプリケーションをアンデプロイした後で、LoggerContext が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。
## [](#実行時のアプリケーションの更新)実行時のアプリケーションの更新 実行時の Mule アプリケーションの更新は、クラスの変更、エンドポイントの変更 (ポートの変更など)、フローの再設定を伴う複雑な変更になる場合があります。アプリケーションの更新では、最初にアプリケーションを適切にシャットダウンしてから、数秒以内にバックグラウンドでアプリケーションを再設定します。このプロセスは、ユーザーに対して透過的に行われます。 アプリケーションは、2 つの方法で更新できます。 - 展開された既存のアプリケーションフォルダーに変更を追加して、メイン設定ファイル (デフォルトではアプリケーションルートディレクトリにある ​`mule-config.xml`​) を操作する。 このオプションを有効にするには、システムプロパティ ​`-M-Dmule.deployment.forceParseConfigXmls=true`​ を使用して Runtime を起動します。 - 更新されたバージョンのアプリケーションを含む新しい ​`jar`​ を ​`$MULE_HOME/apps`​ ディレクトリに追加する。Mule は、​`jar`​ を既存アプリケーションの更新バージョンとして検出し、アプリケーションのクリーンな再デプロイを実行します。 Mule は、古いアプリケーションフォルダーへの変更を破棄します。新しいアプリケーションフォルダーは、​`jar`​ から展開されたクリーンなアプリケーションフォルダーです。 どちらの方法も、既存のビルドツールと適切に統合されます。 ## [](#関連情報)関連情報 - [Anypoint Studio エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept) # Mule Maven プラグインを使用したオンプレミス Mule インスタンスへのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションをオンプレミスでデプロイすることに加えて、Mule Maven プラグインを使用して Mule アプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、目的のデプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用してオンプレミスにアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) - [Anypoint Platform CLI を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/standalone-apps#runtime-mgr-standalone-application-deploy) - [Anypoint Studio を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) ## [](#オンプレミスデプロイメント戦略)オンプレミスデプロイメント戦略 Mule Maven プラグインを使用してアプリケーションをオンプレミスにデプロイする場合、3 つの異なるデプロイメント方法を選択できます。 - スタンドアロンデプロイメント この方法を使用して、オンプレミス Mule インスタンスに Mule アプリケーションを手動でデプロイします。 - Runtime Manager REST API デプロイメント この方法を使用すると、Runtime Manager REST API を使用してアプリケーションをデプロイできます。これにより、オンプレミス Mule インスタンスが Anypoint Runtime Manager アカウントにリンクされ、デプロイしたアプリケーションをさらに管理および監視できます。 - Runtime Manager エージェントデプロイメント この方法を使用すると、Runtime Manager エージェントを使用してアプリケーションをデプロイできます。これにより、ローカル API が公開され、その API をコールして、デプロイしたアプリケーションを管理および監視できます。 スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合、Mule Maven プラグインはドメインのデプロイもサポートします。 追加の操作により、複数のアプリケーションを並列にデプロイしたり、実行時にアプリケーションを更新したりできます。 ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept#add-mmp)​を参照してください。 ## [](#mmp-deploy-standalone)スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#standalone-deploy-reference)スタンドアロンデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

standaloneDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

ローカルマシンインスタンスで実行する Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

muleHome

ローカルマシンにおける Mule インスタンスの場所。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#mmp-deploy-arm)Runtime Manager REST API を使用した Mule アプリケーションのデプロイ Mule Maven プラグインを使用すると、Runtime Manager REST API を使用してローカルの Mule インスタンスに Mule アプリケーションをデプロイできます。 ### [](#前提条件-2)前提条件 - Runtime Manager で作成されたサーバー、サーバーグループ、またはクラスターが必要です。 - サーバーを作成するには、​[「サーバーの追加」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 - サーバーグループを作成するには、​[「サーバーグループの作成」](https://docs.mulesoft.com/jp/runtime-manager/server-group-create)​を参照してください。 - クラスターを作成するには、​[「クラスターの作成」](https://docs.mulesoft.com/jp/runtime-manager/cluster-create)​を参照してください。 ### [](#runtime-manager-rest-api-を使用したデプロイ)Runtime Manager REST API を使用したデプロイ `plugin`​ 要素内に Runtime Manager デプロイメント用の設定を追加し、プレースホルダーの値を Runtime Manager 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${app.runtime} https://anypoint.mulesoft.com ${target} ${target.type} ${username} ${password} ${environment} value ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

Mule インスタンスがインストールされているサーバーのユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[Runtime Manager REST API デプロイメントのパラメーターリファレンス](#arm-deploy-reference)​を参照してください。 ### [](#arm-deploy-reference)Runtime Manager REST API デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

armDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Anypoint Platform URI。Anypoint Platform PCE を使用している場合、Anypoint Platform インストールの URI を使用してこのパラメーターを指定します。
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

target

Mule インスタンスをインストールするサーバーのサーバー名。

はい

targetType

デプロイ先の対象の種別。

有効な値:

  • サーバー

  • serverGroup

  • クラスター

はい

username

Mule インスタンスをインストールするサーバーのユーザー名。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Mule インスタンスをインストールするサーバーのパスワード。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

environment

Mule インスタンスをインストールするサーバーの環境名。この値は、Runtime Manager アカウントで設定されたいずれかの環境に一致する必要があります。
例:

<environment>Sandbox</environment>

はい

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの状況検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。
### [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
### [](#anypoint-private-cloud-edition-での-tls-エラーのトラブルシューティング)Anypoint Private Cloud Edition での TLS エラーのトラブルシューティング [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/)​ インストールの Runtime Manager のインスタンスに接続しようとすると、プラグインはそのサーバーのログイン情報を検証します。トラストストアにサーバーログイン情報をインストールしていない場合、SSL エラーが発生します。この問題を回避するために、非セキュアモードでプラグインを実行できます。このモードでは、セキュリティ検証がスキップされます。​**armInsecure**​ タグまたは ​**arm.insecure**​ システムプロパティを使用できます。
非セキュア接続を有効にするのは危険です。実行内容を理解し、オンプレミスインストールがローカルネットワークに隔離されている場合を除き、使用しないでください。
下の設定例を参照してください。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${target} ${target.type} ${username} ${password} ${environment} true ``` ## [](#mmp-deploy-agent)Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ `plugin`​ 要素内に Runtime Manager エージェントデプロイメント用の設定を追加し、URI の値をリモートサーバー情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true http://localhost:9999/ ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#arm-agent-deploy-reference)Runtime Manager エージェントデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

agentDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Mule インスタンスをインストールするサーバーの URI。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#deploy-a-domain)ドメインのデプロイ スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合のみ、Mule Maven プラグインはドメインのデプロイをサポートします。 ドメインをデプロイするには、アプリケーションのデプロイ時に使用するものと同じ設定とデプロイメント手順を使用します。たとえば、スタンドアロンインスタンスにドメインをデプロイするには、次の手順を実行します。 1. `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` 2. プロジェクトのフォルダーのコマンドラインから、ドメインをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#並列でのアプリケーションのデプロイ)並列でのアプリケーションのデプロイ オンプレミス Mule インスタンスに複数のアプリケーションを並列にデプロイできます。多数のアプリケーションをデプロイする場合は、並列にデプロイすると起動時間を短縮できます。起動順序は不特定であるため、デプロイメントが失敗しないように、アプリケーションが相互連動していないことを確認します。 並列処理は 20 で固定されています。 並列デプロイを有効にする手順は次のとおりです。 1. Mule アプリケーションを Mule Runtime Engine インスタンスの ​`/apps`​ ディレクトリにパッケージ (エクスポート) します。 2. `-M-Dmule.deployment.parallel`​ オプションを使用して Mule を起動します。 ```none mule -M-Dmule.deployment.parallel ``` これらの手順を実行すると、Mule は ​`/apps`​ ディレクトリにあるすべてのアプリケーションを並列にデプロイします。 ## [](#アプリケーションのアンデプロイ)アプリケーションのアンデプロイ Mule アプリケーションは、アプリケーションフォルダーを直接削除するのではなく、アプリケーションのアンカーファイルを削除することでアンデプロイできます。 アプリケーションのアンカーファイルのみを削除することで、次のようになります。 - ホットデプロイメントレイヤーからの干渉を防止し、同時の競合アクションの余地をなくします。 - 一部のオペレーションシステムでアプリケーションの JAR ファイルがロックする問題を回避し、クリーンなシャットダウンとアンデプロイメントを可能にします。 たとえば、​`stockTrader`​ アプリケーションが実行されている (アプリケーションフォルダーと ​`$MULE_HOME/apps/stockTrader-anchor.txt`​ ファイルが存在) 場合、アンカーファイルを削除するだけで実行時にアプリケーション Mule インスタンスから削除されます。アプリケーションフォルダーはアプリケーションの終了後に削除されます。
Mule アプリケーションをアンデプロイした後で、​LoggerContext​ が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。 Mule アプリケーションをアンデプロイした後で、LoggerContext が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。
## [](#実行時のアプリケーションの更新)実行時のアプリケーションの更新 実行時の Mule アプリケーションの更新は、クラスの変更、エンドポイントの変更 (ポートの変更など)、フローの再設定を伴う複雑な変更になる場合があります。アプリケーションの更新では、最初にアプリケーションを適切にシャットダウンしてから、数秒以内にバックグラウンドでアプリケーションを再設定します。このプロセスは、ユーザーに対して透過的に行われます。 アプリケーションは、2 つの方法で更新できます。 - 展開された既存のアプリケーションフォルダーに変更を追加して、メイン設定ファイル (デフォルトではアプリケーションルートディレクトリにある ​`mule-config.xml`​) を操作する。 このオプションを有効にするには、システムプロパティ ​`-M-Dmule.deployment.forceParseConfigXmls=true`​ を使用して Runtime を起動します。 - 更新されたバージョンのアプリケーションを含む新しい ​`jar`​ を ​`$MULE_HOME/apps`​ ディレクトリに追加する。Mule は、​`jar`​ を既存アプリケーションの更新バージョンとして検出し、アプリケーションのクリーンな再デプロイを実行します。 Mule は、古いアプリケーションフォルダーへの変更を破棄します。新しいアプリケーションフォルダーは、​`jar`​ から展開されたクリーンなアプリケーションフォルダーです。 どちらの方法も、既存のビルドツールと適切に統合されます。 ## [](#関連情報)関連情報 - [Anypoint Studio エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept) # Mule Maven プラグインを使用したオンプレミス Mule インスタンスへのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションをオンプレミスでデプロイすることに加えて、Mule Maven プラグインを使用して Mule アプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、目的のデプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用してオンプレミスにアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) - [Anypoint Platform CLI を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/standalone-apps#runtime-mgr-standalone-application-deploy) - [Anypoint Studio を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) ## [](#オンプレミスデプロイメント戦略)オンプレミスデプロイメント戦略 Mule Maven プラグインを使用してアプリケーションをオンプレミスにデプロイする場合、3 つの異なるデプロイメント方法を選択できます。 - スタンドアロンデプロイメント この方法を使用して、オンプレミス Mule インスタンスに Mule アプリケーションを手動でデプロイします。 - Runtime Manager REST API デプロイメント この方法を使用すると、Runtime Manager REST API を使用してアプリケーションをデプロイできます。これにより、オンプレミス Mule インスタンスが Anypoint Runtime Manager アカウントにリンクされ、デプロイしたアプリケーションをさらに管理および監視できます。 - Runtime Manager エージェントデプロイメント この方法を使用すると、Runtime Manager エージェントを使用してアプリケーションをデプロイできます。これにより、ローカル API が公開され、その API をコールして、デプロイしたアプリケーションを管理および監視できます。 スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合、Mule Maven プラグインはドメインのデプロイもサポートします。 追加の操作により、複数のアプリケーションを並列にデプロイしたり、実行時にアプリケーションを更新したりできます。 ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept#add-mmp)​を参照してください。 ## [](#mmp-deploy-standalone)スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#standalone-deploy-reference)スタンドアロンデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

standaloneDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

ローカルマシンインスタンスで実行する Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

muleHome

ローカルマシンにおける Mule インスタンスの場所。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#mmp-deploy-arm)Runtime Manager REST API を使用した Mule アプリケーションのデプロイ Mule Maven プラグインを使用すると、Runtime Manager REST API を使用してローカルの Mule インスタンスに Mule アプリケーションをデプロイできます。 ### [](#前提条件-2)前提条件 - Runtime Manager で作成されたサーバー、サーバーグループ、またはクラスターが必要です。 - サーバーを作成するには、​[「サーバーの追加」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 - サーバーグループを作成するには、​[「サーバーグループの作成」](https://docs.mulesoft.com/jp/runtime-manager/server-group-create)​を参照してください。 - クラスターを作成するには、​[「クラスターの作成」](https://docs.mulesoft.com/jp/runtime-manager/cluster-create)​を参照してください。 ### [](#runtime-manager-rest-api-を使用したデプロイ)Runtime Manager REST API を使用したデプロイ `plugin`​ 要素内に Runtime Manager デプロイメント用の設定を追加し、プレースホルダーの値を Runtime Manager 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${app.runtime} https://anypoint.mulesoft.com ${target} ${target.type} ${username} ${password} ${environment} value ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

Mule インスタンスがインストールされているサーバーのユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[Runtime Manager REST API デプロイメントのパラメーターリファレンス](#arm-deploy-reference)​を参照してください。 ### [](#arm-deploy-reference)Runtime Manager REST API デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

armDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Anypoint Platform URI。Anypoint Platform PCE を使用している場合、Anypoint Platform インストールの URI を使用してこのパラメーターを指定します。
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

target

Mule インスタンスをインストールするサーバーのサーバー名。

はい

targetType

デプロイ先の対象の種別。

有効な値:

  • サーバー

  • serverGroup

  • クラスター

はい

username

Mule インスタンスをインストールするサーバーのユーザー名。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Mule インスタンスをインストールするサーバーのパスワード。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

environment

Mule インスタンスをインストールするサーバーの環境名。この値は、Runtime Manager アカウントで設定されたいずれかの環境に一致する必要があります。
例:

<environment>Sandbox</environment>

はい

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。
### [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
### [](#anypoint-private-cloud-edition-での-tls-エラーのトラブルシューティング)Anypoint Private Cloud Edition での TLS エラーのトラブルシューティング [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/)​ インストールの Runtime Manager のインスタンスに接続しようとすると、プラグインはそのサーバーのログイン情報を検証します。トラストストアにサーバーログイン情報をインストールしていない場合、SSL エラーが発生します。この問題を回避するために、非セキュアモードでプラグインを実行できます。このモードでは、セキュリティ検証がスキップされます。​**armInsecure**​ タグまたは ​**arm.insecure**​ システムプロパティを使用できます。
非セキュア接続を有効にするのは危険です。実行内容を理解し、オンプレミスインストールがローカルネットワークに隔離されている場合を除き、使用しないでください。
下の設定例を参照してください。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${target} ${target.type} ${username} ${password} ${environment} true ``` ## [](#mmp-deploy-agent)Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ `plugin`​ 要素内に Runtime Manager エージェントデプロイメント用の設定を追加し、URI の値をリモートサーバー情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true http://localhost:9999/ ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#arm-agent-deploy-reference)Runtime Manager エージェントデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

agentDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Mule インスタンスをインストールするサーバーの URI。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#deploy-a-domain)ドメインのデプロイ スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合のみ、Mule Maven プラグインはドメインのデプロイをサポートします。 ドメインをデプロイするには、アプリケーションのデプロイ時に使用するものと同じ設定とデプロイメント手順を使用します。たとえば、スタンドアロンインスタンスにドメインをデプロイするには、次の手順を実行します。 1. `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` 2. プロジェクトのフォルダーのコマンドラインから、ドメインをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#並列でのアプリケーションのデプロイ)並列でのアプリケーションのデプロイ オンプレミス Mule インスタンスに複数のアプリケーションを並列にデプロイできます。多数のアプリケーションをデプロイする場合は、並列にデプロイすると起動時間を短縮できます。起動順序は不特定であるため、デプロイメントが失敗しないように、アプリケーションが相互連動していないことを確認します。 並列処理は 20 で固定されています。 並列デプロイを有効にする手順は次のとおりです。 1. Mule アプリケーションを Mule Runtime Engine インスタンスの ​`/apps`​ ディレクトリにパッケージ (エクスポート) します。 2. `-M-Dmule.deployment.parallel`​ オプションを使用して Mule を起動します。 ```none mule -M-Dmule.deployment.parallel ``` これらの手順を実行すると、Mule は ​`/apps`​ ディレクトリにあるすべてのアプリケーションを並列にデプロイします。 ## [](#アプリケーションのアンデプロイ)アプリケーションのアンデプロイ Mule アプリケーションは、アプリケーションフォルダーを直接削除するのではなく、アプリケーションのアンカーファイルを削除することでアンデプロイできます。 アプリケーションのアンカーファイルのみを削除することで、次のようになります。 - ホットデプロイメントレイヤーからの干渉を防止し、同時の競合アクションの余地をなくします。 - 一部のオペレーションシステムでアプリケーションの JAR ファイルがロックする問題を回避し、クリーンなシャットダウンとアンデプロイメントを可能にします。 たとえば、​`stockTrader`​ アプリケーションが実行されている (アプリケーションフォルダーと ​`$MULE_HOME/apps/stockTrader-anchor.txt`​ ファイルが存在) 場合、アンカーファイルを削除するだけで実行時にアプリケーション Mule インスタンスから削除されます。アプリケーションフォルダーはアプリケーションの終了後に削除されます。
Mule アプリケーションをアンデプロイした後で、​LoggerContext​ が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。 Mule アプリケーションをアンデプロイした後で、LoggerContext が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。
## [](#実行時のアプリケーションの更新)実行時のアプリケーションの更新 実行時の Mule アプリケーションの更新は、クラスの変更、エンドポイントの変更 (ポートの変更など)、フローの再設定を伴う複雑な変更になる場合があります。アプリケーションの更新では、最初にアプリケーションを適切にシャットダウンしてから、数秒以内にバックグラウンドでアプリケーションを再設定します。このプロセスは、ユーザーに対して透過的に行われます。 アプリケーションは、2 つの方法で更新できます。 - 展開された既存のアプリケーションフォルダーに変更を追加して、メイン設定ファイル (デフォルトではアプリケーションルートディレクトリにある ​`mule-config.xml`​) を操作する。 このオプションを有効にするには、システムプロパティ ​`-M-Dmule.deployment.forceParseConfigXmls=true`​ を使用して Runtime を起動します。 - 更新されたバージョンのアプリケーションを含む新しい ​`jar`​ を ​`$MULE_HOME/apps`​ ディレクトリに追加する。Mule は、​`jar`​ を既存アプリケーションの更新バージョンとして検出し、アプリケーションのクリーンな再デプロイを実行します。 Mule は、古いアプリケーションフォルダーへの変更を破棄します。新しいアプリケーションフォルダーは、​`jar`​ から展開されたクリーンなアプリケーションフォルダーです。 どちらの方法も、既存のビルドツールと適切に統合されます。 ## [](#関連情報)関連情報 - [Anypoint Studio エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept) # Mule Maven プラグインを使用したオンプレミス Mule インスタンスへのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションをオンプレミスでデプロイすることに加えて、Mule Maven プラグインを使用して Mule アプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、目的のデプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用してオンプレミスにアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) - [Anypoint Platform CLI を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/standalone-apps#runtime-mgr-standalone-application-deploy) - [Anypoint Studio を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) ## [](#オンプレミスデプロイメント戦略)オンプレミスデプロイメント戦略 Mule Maven プラグインを使用してアプリケーションをオンプレミスにデプロイする場合、3 つの異なるデプロイメント方法を選択できます。 - スタンドアロンデプロイメント この方法を使用して、オンプレミス Mule インスタンスに Mule アプリケーションを手動でデプロイします。 - Runtime Manager REST API デプロイメント この方法を使用すると、Runtime Manager REST API を使用してアプリケーションをデプロイできます。これにより、オンプレミス Mule インスタンスが Anypoint Runtime Manager アカウントにリンクされ、デプロイしたアプリケーションをさらに管理および監視できます。 - Runtime Manager エージェントデプロイメント この方法を使用すると、Runtime Manager エージェントを使用してアプリケーションをデプロイできます。これにより、ローカル API が公開され、その API をコールして、デプロイしたアプリケーションを管理および監視できます。 スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合、Mule Maven プラグインはドメインのデプロイもサポートします。 追加の操作により、複数のアプリケーションを並列にデプロイしたり、実行時にアプリケーションを更新したりできます。 ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept#add-mmp)​を参照してください。 ## [](#mmp-deploy-standalone)スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#standalone-deploy-reference)スタンドアロンデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

standaloneDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

ローカルマシンインスタンスで実行する Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

muleHome

ローカルマシンにおける Mule インスタンスの場所。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#mmp-deploy-arm)Runtime Manager REST API を使用した Mule アプリケーションのデプロイ Mule Maven プラグインを使用すると、Runtime Manager REST API を使用してローカルの Mule インスタンスに Mule アプリケーションをデプロイできます。 ### [](#前提条件-2)前提条件 - Runtime Manager で作成されたサーバー、サーバーグループ、またはクラスターが必要です。 - サーバーを作成するには、​[「サーバーの追加」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 - サーバーグループを作成するには、​[「サーバーグループの作成」](https://docs.mulesoft.com/jp/runtime-manager/server-group-create)​を参照してください。 - クラスターを作成するには、​[「クラスターの作成」](https://docs.mulesoft.com/jp/runtime-manager/cluster-create)​を参照してください。 ### [](#runtime-manager-rest-api-を使用したデプロイ)Runtime Manager REST API を使用したデプロイ `plugin`​ 要素内に Runtime Manager デプロイメント用の設定を追加し、プレースホルダーの値を Runtime Manager 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${app.runtime} https://anypoint.mulesoft.com ${target} ${target.type} ${username} ${password} ${environment} value ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

Mule インスタンスがインストールされているサーバーのユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[Runtime Manager REST API デプロイメントのパラメーターリファレンス](#arm-deploy-reference)​を参照してください。 ### [](#arm-deploy-reference)Runtime Manager REST API デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

armDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Anypoint Platform URI。Anypoint Platform PCE を使用している場合、Anypoint Platform インストールの URI を使用してこのパラメーターを指定します。
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

target

Mule インスタンスをインストールするサーバーのサーバー名。

はい

targetType

デプロイ先の対象の種別。

有効な値:

  • サーバー

  • serverGroup

  • クラスター

はい

username

Mule インスタンスをインストールするサーバーのユーザー名。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Mule インスタンスをインストールするサーバーのパスワード。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

environment

Mule インスタンスをインストールするサーバーの環境名。この値は、Runtime Manager アカウントで設定されたいずれかの環境に一致する必要があります。
例:

<environment>Sandbox</environment>

はい

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションの秘密鍵を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。
### [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
### [](#anypoint-private-cloud-edition-での-tls-エラーのトラブルシューティング)Anypoint Private Cloud Edition での TLS エラーのトラブルシューティング [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/)​ インストールの Runtime Manager のインスタンスに接続しようとすると、プラグインはそのサーバーのログイン情報を検証します。トラストストアにサーバーログイン情報をインストールしていない場合、SSL エラーが発生します。この問題を回避するために、非セキュアモードでプラグインを実行できます。このモードでは、セキュリティ検証がスキップされます。​**armInsecure**​ タグまたは ​**arm.insecure**​ システムプロパティを使用できます。
非セキュア接続を有効にするのは危険です。実行内容を理解し、オンプレミスインストールがローカルネットワークに隔離されている場合を除き、使用しないでください。
下の設定例を参照してください。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${target} ${target.type} ${username} ${password} ${environment} true ``` ## [](#mmp-deploy-agent)Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ `plugin`​ 要素内に Runtime Manager エージェントデプロイメント用の設定を追加し、URI の値をリモートサーバー情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true http://localhost:9999/ ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#arm-agent-deploy-reference)Runtime Manager エージェントデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

agentDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Mule インスタンスをインストールするサーバーの URI。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#deploy-a-domain)ドメインのデプロイ スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合のみ、Mule Maven プラグインはドメインのデプロイをサポートします。 ドメインをデプロイするには、アプリケーションのデプロイ時に使用するものと同じ設定とデプロイメント手順を使用します。たとえば、スタンドアロンインスタンスにドメインをデプロイするには、次の手順を実行します。 1. `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` 2. プロジェクトのフォルダーのコマンドラインから、ドメインをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#並列でのアプリケーションのデプロイ)並列でのアプリケーションのデプロイ オンプレミス Mule インスタンスに複数のアプリケーションを並列にデプロイできます。多数のアプリケーションをデプロイする場合は、並列にデプロイすると起動時間を短縮できます。起動順序は不特定であるため、デプロイメントが失敗しないように、アプリケーションが相互連動していないことを確認します。 並列処理は 20 で固定されています。 並列デプロイを有効にする手順は次のとおりです。 1. Mule アプリケーションを Mule Runtime Engine インスタンスの ​`/apps`​ ディレクトリにパッケージ (エクスポート) します。 2. `-M-Dmule.deployment.parallel`​ オプションを使用して Mule を起動します。 ```none mule -M-Dmule.deployment.parallel ``` これらの手順を実行すると、Mule は ​`/apps`​ ディレクトリにあるすべてのアプリケーションを並列にデプロイします。 ## [](#アプリケーションのアンデプロイ)アプリケーションのアンデプロイ Mule アプリケーションは、アプリケーションフォルダーを直接削除するのではなく、アプリケーションのアンカーファイルを削除することでアンデプロイできます。 アプリケーションのアンカーファイルのみを削除することで、次のようになります。 - ホットデプロイメントレイヤーからの干渉を防止し、同時の競合アクションの余地をなくします。 - 一部のオペレーションシステムでアプリケーションの JAR ファイルがロックする問題を回避し、クリーンなシャットダウンとアンデプロイメントを可能にします。 たとえば、​`stockTrader`​ アプリケーションが実行されている (アプリケーションフォルダーと ​`$MULE_HOME/apps/stockTrader-anchor.txt`​ ファイルが存在) 場合、アンカーファイルを削除するだけで実行時にアプリケーション Mule インスタンスから削除されます。アプリケーションフォルダーはアプリケーションの終了後に削除されます。
Mule アプリケーションをアンデプロイした後で、​LoggerContext​ が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。 Mule アプリケーションをアンデプロイした後で、LoggerContext が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。
## [](#実行時のアプリケーションの更新)実行時のアプリケーションの更新 実行時の Mule アプリケーションの更新は、クラスの変更、エンドポイントの変更 (ポートの変更など)、フローの再設定を伴う複雑な変更になる場合があります。アプリケーションの更新では、最初にアプリケーションを適切にシャットダウンしてから、数秒以内にバックグラウンドでアプリケーションを再設定します。このプロセスは、ユーザーに対して透過的に行われます。 アプリケーションは、2 つの方法で更新できます。 - 展開された既存のアプリケーションフォルダーに変更を追加して、メイン設定ファイル (デフォルトではアプリケーションルートディレクトリにある ​`mule-config.xml`​) を操作する。 このオプションを有効にするには、システムプロパティ ​`-M-Dmule.deployment.forceParseConfigXmls=true`​ を使用して Runtime を起動します。 - 更新されたバージョンのアプリケーションを含む新しい ​`jar`​ を ​`$MULE_HOME/apps`​ ディレクトリに追加する。Mule は、​`jar`​ を既存アプリケーションの更新バージョンとして検出し、アプリケーションのクリーンな再デプロイを実行します。 Mule は、古いアプリケーションフォルダーへの変更を破棄します。新しいアプリケーションフォルダーは、​`jar`​ から展開されたクリーンなアプリケーションフォルダーです。 どちらの方法も、既存のビルドツールと適切に統合されます。 ## [](#関連情報)関連情報 - [Anypoint Studio エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept) # Mule Maven プラグインを使用したオンプレミス Mule インスタンスへのアプリケーションのデプロイ
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Studio、Anypoint Runtime Manager、または Anypoint Platform CLI を使用してアプリケーションをオンプレミスでデプロイすることに加えて、Mule Maven プラグインを使用して Mule アプリケーションをデプロイすることもできます。これを行うには、特定の前提条件を満たし、目的のデプロイメント戦略をプロジェクトの ​`pom.xml`​ ファイルで定義する必要があります。 別の方法を使用してオンプレミスにアプリケーションをデプロイする場合は、以下を参照してください。 - [Runtime Manager を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) - [Anypoint Platform CLI を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/anypoint-cli/latest/standalone-apps#runtime-mgr-standalone-application-deploy) - [Anypoint Studio を使用したオンプレミスでのアプリケーションのデプロイ](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) ## [](#オンプレミスデプロイメント戦略)オンプレミスデプロイメント戦略 Mule Maven プラグインを使用してアプリケーションをオンプレミスにデプロイする場合、3 つの異なるデプロイメント方法を選択できます。 - スタンドアロンデプロイメント この方法を使用して、オンプレミス Mule インスタンスに Mule アプリケーションを手動でデプロイします。 - Runtime Manager REST API デプロイメント この方法を使用すると、Runtime Manager REST API を使用してアプリケーションをデプロイできます。これにより、オンプレミス Mule インスタンスが Anypoint Runtime Manager アカウントにリンクされ、デプロイしたアプリケーションをさらに管理および監視できます。 - Runtime Manager エージェントデプロイメント この方法を使用すると、Runtime Manager エージェントを使用してアプリケーションをデプロイできます。これにより、ローカル API が公開され、その API をコールして、デプロイしたアプリケーションを管理および監視できます。 スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合、Mule Maven プラグインはドメインのデプロイもサポートします。 追加の操作により、複数のアプリケーションを並列にデプロイしたり、実行時にアプリケーションを更新したりできます。 ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept#add-mmp)​を参照してください。 ## [](#mmp-deploy-standalone)スタンドアロン Mule Runtime Engine への Mule アプリケーションのデプロイ `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#standalone-deploy-reference)スタンドアロンデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

standaloneDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

ローカルマシンインスタンスで実行する Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

muleHome

ローカルマシンにおける Mule インスタンスの場所。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#mmp-deploy-arm)Runtime Manager REST API を使用した Mule アプリケーションのデプロイ Mule Maven プラグインを使用すると、Runtime Manager REST API を使用してローカルの Mule インスタンスに Mule アプリケーションをデプロイできます。 ### [](#前提条件-2)前提条件 - Runtime Manager で作成されたサーバー、サーバーグループ、またはクラスターが必要です。 - サーバーを作成するには、​[「サーバーの追加」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 - サーバーグループを作成するには、​[「サーバーグループの作成」](https://docs.mulesoft.com/jp/runtime-manager/server-group-create)​を参照してください。 - クラスターを作成するには、​[「クラスターの作成」](https://docs.mulesoft.com/jp/runtime-manager/cluster-create)​を参照してください。 ### [](#runtime-manager-rest-api-を使用したデプロイ)Runtime Manager REST API を使用したデプロイ `plugin`​ 要素内に Runtime Manager デプロイメント用の設定を追加し、プレースホルダーの値を Runtime Manager 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${app.runtime} https://anypoint.mulesoft.com ${target} ${target.type} ${username} ${password} ${environment} value ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#authentication-のメソッド)Authentication のメソッド Mule Maven プラグインを使用してアプリケーションをデプロイする場合には、デプロイメントプラットフォームに対して認証するためのログイン情報をいくつかの方法で提供できます。使用する認証方法に応じて、デプロイメント設定で指定するパラメーターが異なります。
認証方法 説明 設定パラメーター

ユーザー名とパスワード

Mule インスタンスがインストールされているサーバーのユーザー名とパスワードを使用して認証します。

  • username

  • password

サーバー

Maven サーバーに保存されているログイン情報を使用します。Maven の ​settings.xml​ ファイル内で設定します。

  • server

認証トークン

認証トークンを使用してプラットフォームにアクセスします。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

  • authToken

接続アプリケーション

接続アプリケーションを使用して Anypoint Platform と通信することで、プログラムによって認証を実行します。
接続アプリケーションのログイン情報に ​Design Center Developer​ アクセススコープが設定されている必要があります。
接続アプリケーションを作成する手順は、​「開発者向けの接続アプリケーション」​を参照してください。

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType
設定パラメーターの詳細は、​[Runtime Manager REST API デプロイメントのパラメーターリファレンス](#arm-deploy-reference)​を参照してください。 ### [](#arm-deploy-reference)Runtime Manager REST API デプロイメントのパラメーターリファレンス
パラメーター 説明 必須

armDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Anypoint Platform URI。Anypoint Platform PCE を使用している場合、Anypoint Platform インストールの URI を使用してこのパラメーターを指定します。
設定しない場合、デフォルトでこの値は https://anypoint.mulesoft.com に設定されます。

いいえ

target

Mule インスタンスをインストールするサーバーのサーバー名。

はい

targetType

デプロイ先の対象の種別。

有効な値:

  • サーバー

  • serverGroup

  • クラスター

はい

username

Mule インスタンスをインストールするサーバーのユーザー名。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

password

Mule インスタンスをインストールするサーバーのパスワード。

Anypoint Platform ログイン情報を使用してログインする場合のみ。

environment

Mule インスタンスをインストールするサーバーの環境名。この値は、Runtime Manager アカウントで設定されたいずれかの環境に一致する必要があります。
例:

<environment>Sandbox</environment>

はい

​businessGroup​

デプロイメントのビジネスグループパス
親組織から対象ビジネスグループへの完全な階層パスを指定します。次に例を示します。

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

この値は、​businessGroupId​ が設定されている場合は省略されます。​businessGroup​ と ​businessGroupId​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。

いいえ

​businessGroupId​

デプロイメントのビジネスグループ ID
ビジネスグループパスを指定する代わりにビジネスグループ ID を指定してアプリケーションをデプロイできます。​businessGroupId​ と ​businessGroup​ が設定されていない場合、値はデフォルトでユーザーのメインビジネスグループになります。
特定のビジネスグループへのアクセス権のみがあり、親組織へのアクセス権がない場合は、ビジネスグループ ID は必須パラメーターです。
このパラメーターは、プラグインバージョン 3.2.7 以降で使用できます。

いいえ

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

​server​

Anypoint Platform ログイン情報を持つ Maven サーバー
これは、Maven ​settings.xml​ ファイルに保存されたログイン情報を使用する場合のみ必要です。これは Mule サーバー名ではありません。

いいえ

​properties​

最上位要素
デプロイする Mule アプリケーションのプロパティを設定する必要がある場合、最上位要素 ​<properties>​ を使用できます。

<properties>
  <key>value</key>
</properties>

次に例を示します。

<properties>
  <http.port>8081</http.port>
</properties>

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ

skipDeploymentVerification​

​true​ に設定すると、デプロイされるアプリケーションの検証をスキップします。
デフォルト値は ​false​ です。

いいえ

​authToken​

プラットフォームにアクセスするための認証トークンを指定します。ユーザー名とパスワードを設定する代わりに、この認証方式を使用できます。
サポートされているシングルサインオン (SSO) 種別は​「ID 管理」​を参照してください。

認証トークンを使用してログインする場合のみ。

​connectedAppClientId​

接続アプリケーションの ​clientID​ 値を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppClientSecret​

接続アプリケーションのシークレットキーを指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。

​connectedAppGrantType​

サポートされている唯一の接続種別、​client_credentials​ を指定します。

接続アプリケーションログイン情報を使用してログインする場合のみ。
### [](#ログイン情報の暗号化)ログイン情報の暗号化 デプロイするときに暗号化ログイン情報を使用するには、Maven マスター暗号化パスワードおよび ​`settings-security.xml`​ ファイルをセットアップする必要があります。 1. Maven 設定のマスターパスワードを作成します。 mvn --encrypt-master-password Maven はマスターパスワードを暗号化して返します。 {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. ~/.m2 リポジトリで ​`settings-security.xml`​ ファイルを作成し、暗号化マスターパスワードを追加します。 ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Anypoint Platform パスワードを暗号化します。 mvn --encrypt-password Maven は Anypoint Platform パスワードを暗号化して返します。 {HTWFGH5BG9QmvJ1B=} 4. 暗号化 Anypoint Platform パスワードを ​`settings.xml`​ ファイルの セクションに追加します。 ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. 設定デプロイメントで、​`settings.xml`​ ファイルで設定されたサーバー ID を挿入するログイン情報を参照します。 ```xml ... ... ... my.anypoint.credentials ... ... ... ```
ユーザー名とパスワードがデプロイメント設定で設定されていると、定義されたサーバー ID が上書きされるため、設定されていないことを確認してください。
### [](#anypoint-private-cloud-edition-での-tls-エラーのトラブルシューティング)Anypoint Private Cloud Edition での TLS エラーのトラブルシューティング [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/)​ インストールの Runtime Manager のインスタンスに接続しようとすると、プラグインはそのサーバーのログイン情報を検証します。トラストストアにサーバーログイン情報をインストールしていない場合、SSL エラーが発生します。この問題を回避するために、非セキュアモードでプラグインを実行できます。このモードでは、セキュリティ検証がスキップされます。​**armInsecure**​ タグまたは ​**arm.insecure**​ システムプロパティを使用できます。
非セキュア接続を有効にするのは危険です。実行内容を理解し、オンプレミスインストールがローカルネットワークに隔離されている場合を除き、使用しないでください。
下の設定例を参照してください。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${target} ${target.type} ${username} ${password} ${environment} true ``` ## [](#mmp-deploy-agent)Runtime Manager エージェントを使用した Mule アプリケーションのデプロイ `plugin`​ 要素内に Runtime Manager エージェントデプロイメント用の設定を追加し、URI の値をリモートサーバー情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true http://localhost:9999/ ``` プロジェクトのフォルダーのコマンドラインから、アプリケーションをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ### [](#arm-agent-deploy-reference)Runtime Manager エージェントデプロイメントのパラメーターリファレンス
パラメーター 説明 必須

agentDeployment

最上位要素。

はい

​applicationName​

デプロイ時に使用するアプリケーション名を指定します。

はい

muleVersion

アプリケーションをデプロイメント対象で実行するために必要な Mule バージョン。
この値がデプロイメント対象で実行している Mule バージョンに一致しない場合、プラグインで例外が発生します。

この値が一致しない場合、Mule Maven プラグインは Mule Runtime Engine をダウンロードしません。

はい

uri

Mule インスタンスをインストールするサーバーの URI。

はい

​deploymentTimeout​

デプロイメントプロセスの開始からアーティファクトがデプロイされたことの確認までの許容される経過時間 (ミリ秒)

デフォルト値は ​1000000​ です。

いいえ

skip​

​true​ に設定すると、プラグインデプロイメントゴールをスキップします。
デフォルト値は ​false​ です。

いいえ
## [](#deploy-a-domain)ドメインのデプロイ スタンドアロンデプロイメント戦略または Runtime Manager エージェントデプロイメント戦略を使用する場合のみ、Mule Maven プラグインはドメインのデプロイをサポートします。 ドメインをデプロイするには、アプリケーションのデプロイ時に使用するものと同じ設定とデプロイメント手順を使用します。たとえば、スタンドアロンインスタンスにドメインをデプロイするには、次の手順を実行します。 1. `plugin`​ 要素内にスタンドアロンデプロイメント用の設定を追加し、プレースホルダーの値をローカルの Mule Runtime Engine 情報で置き換えます。 ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true ${mule.home.test} ${app.runtime} ``` 2. プロジェクトのフォルダーのコマンドラインから、ドメインをパッケージ化してデプロイゴールを実行します。 ```console mvn clean deploy -DmuleDeploy ``` ## [](#並列でのアプリケーションのデプロイ)並列でのアプリケーションのデプロイ オンプレミス Mule インスタンスに複数のアプリケーションを並列にデプロイできます。多数のアプリケーションをデプロイする場合は、並列にデプロイすると起動時間を短縮できます。起動順序は不特定であるため、デプロイメントが失敗しないように、アプリケーションが相互連動していないことを確認します。 並列処理は 20 で固定されています。 並列デプロイを有効にする手順は次のとおりです。 1. Mule アプリケーションを Mule Runtime Engine インスタンスの ​`/apps`​ ディレクトリにパッケージ (エクスポート) します。 2. `-M-Dmule.deployment.parallel`​ オプションを使用して Mule を起動します。 ```none mule -M-Dmule.deployment.parallel ``` これらの手順を実行すると、Mule は ​`/apps`​ ディレクトリにあるすべてのアプリケーションを並列にデプロイします。 ## [](#アプリケーションのアンデプロイ)アプリケーションのアンデプロイ Mule アプリケーションは、アプリケーションフォルダーを直接削除するのではなく、アプリケーションのアンカーファイルを削除することでアンデプロイできます。 アプリケーションのアンカーファイルのみを削除することで、次のようになります。 - ホットデプロイメントレイヤーからの干渉を防止し、同時の競合アクションの余地をなくします。 - 一部のオペレーションシステムでアプリケーションの JAR ファイルがロックする問題を回避し、クリーンなシャットダウンとアンデプロイメントを可能にします。 たとえば、​`stockTrader`​ アプリケーションが実行されている (アプリケーションフォルダーと ​`$MULE_HOME/apps/stockTrader-anchor.txt`​ ファイルが存在) 場合、アンカーファイルを削除するだけで実行時にアプリケーション Mule インスタンスから削除されます。アプリケーションフォルダーはアプリケーションの終了後に削除されます。
Mule アプリケーションをアンデプロイした後で、​LoggerContext​ が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。 Mule アプリケーションをアンデプロイした後で、LoggerContext が停止するまで 15 秒のタイムアウトがあります。アプリケーションのログファイルはこのタイムアウトが経過した後にならないとリリースされません。この情報は、他のプロセスで使用されているファイルを削除できない Windows では重要です。
## [](#実行時のアプリケーションの更新)実行時のアプリケーションの更新 実行時の Mule アプリケーションの更新は、クラスの変更、エンドポイントの変更 (ポートの変更など)、フローの再設定を伴う複雑な変更になる場合があります。アプリケーションの更新では、最初にアプリケーションを適切にシャットダウンしてから、数秒以内にバックグラウンドでアプリケーションを再設定します。このプロセスは、ユーザーに対して透過的に行われます。 アプリケーションは、2 つの方法で更新できます。 - 展開された既存のアプリケーションフォルダーに変更を追加して、メイン設定ファイル (デフォルトではアプリケーションルートディレクトリにある ​`mule-config.xml`​) を操作する。 このオプションを有効にするには、システムプロパティ ​`-M-Dmule.deployment.forceParseConfigXmls=true`​ を使用して Runtime を起動します。 - 更新されたバージョンのアプリケーションを含む新しい ​`jar`​ を ​`$MULE_HOME/apps`​ ディレクトリに追加する。Mule は、​`jar`​ を既存アプリケーションの更新バージョンとして検出し、アプリケーションのクリーンな再デプロイを実行します。 Mule は、古いアプリケーションフォルダーへの変更を破棄します。新しいアプリケーションフォルダーは、​`jar`​ から展開されたクリーンなアプリケーションフォルダーです。 どちらの方法も、既存のビルドツールと適切に統合されます。 ## [](#関連情報)関連情報 - [Anypoint Studio エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept) # Mule Runtime Engine の概要 Mule Runtime Engine (Mule) は、Mule アプリケーションを実行する軽量のインテグレーションエンジンであり、ドメインとポリシーをサポートします。Mule アプリケーション、ドメイン、およびポリシーは、XML DSL (ドメイン特有言語) を共有します。 ## [](#mule-アプリケーション)Mule アプリケーション Mule アプリケーションは、ポイントツーポイントのインテグレーションではなく API 主導の接続性を使用してシステム、サービス、API、デバイスに接続します。Mule アプリケーションは、メッセージルーティング、データマッピング、オーケストレーション、信頼性、セキュリティ、スケーラビリティの機能を提供します。 Anypoint Studio は、Mule アプリケーションの開発をサポートします。 ## [](#mule-ドメイン)Mule ドメイン ドメインにより、デフォルトのエラーハンドラー、共有プロパティ、スケジューラープール、コンポーネント設定など、Mule アプリケーションが再利用する必要のあるグローバル設定を共有できます。ドメインをデプロイできるのは、オンプレミスで Mule Runtime Engine を実行している場合のみです。 Anypoint Studio を使用した Mule ドメインの開発と設定については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.3/shared-resources)​を参照してください。 ドメインデプロイメント手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ポリシー)ポリシー HTTP ベース API に基づいたポリシーにより、セキュリティの適用、Mule アプリケーションのトラフィックの規制、ビジネスニーズに合わせた API の活用が可能です。 Mule には、埋め込み API ゲートウェイが含まれています。これにより、コードを記述することなく、セキュリティポリシーを API に適用し、受信メッセージや送信メッセージを強化し、API に機能を追加できます。 詳細は、​[「API ゲートウェイ機能」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4)​を参照してください。 API Manager は、自動ポリシーの設定をサポートします。カスタムポリシー開発と設定もサポートされます。 ## [](#Maven)Maven サポート Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には Maven の機能が組み込まれています。Mule Runtime Engine では、Mule Maven プラグインを使用することで、Mule アプリケーション、ドメイン、カスタムポリシーのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 詳細は、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.3/using-maven-with-mule)​を参照してください。 ## [](#install_deploy_manage)Mule のインストール、デプロイ、管理 Mule アプリケーションを実行するには、Mule Runtime Engine がインストールされている環境に Mule アプリケーションをデプロイする必要があります。 Mule は、​[Studio](https://docs.mulesoft.com/studio/)​ IDE 内で Anypoint Platform 上の ​[Design Center](https://docs.mulesoft.com/design-center/)​ と共にパッケージ化されているため、設計するときに Mule アプリケーションを実行できます。 Mule アプリケーションの本番デプロイや本番準備デプロイには、​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/)​ を使用して Mule アプリケーションを CloudHub 内のランタイムやサポートされているその他のサービスとしてのプラットフォーム (PaaS) にデプロイできます。 - [CloudHub](https://docs.mulesoft.com/cloudhub/)​ は、Anypoint Platform 用の完全に管理されたクラウドベースのサービスとしてのインテグレーションプラットフォーム (iPaaS) で、Mule Runtime やアプリケーションを実行するインフラストラクチャを用意しなくても Mule アプリケーションを実行できます。Runtime Manager を使用して、CloudHub への Mule アプリケーションのデプロイ、Mule バージョンの選択、アプリケーションを実行するのに必要な vCore 数の設定などを行います。 - ハイブリッドデプロイメントモデルでは、自社が管理するデータセンターで Mule アプリケーションとランタイムを実行しながら、クラウドからそれらを管理します。 - リモート Mule Runtime (スタンドアロンまたはネイキッド Mule とも呼ばれる) の場合は、データセンターから Mule Runtime を起動しますが、Mule アプリケーションのデプロイと管理は Runtime Manager を使用してクラウドから実行できます。このデプロイモデルでは、インフラストラクチャと Mule Runtime を自社で用意します (​[「オンプレミスでの Mule Runtime Engine の実行」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-standalone)​を参照)。 - ハイブリッド PaaS デプロイの場合は、自社のデータセンターで PaaS をセットアップして実行し、Runtime Manager を使用して PaaS 内で Mule アプリケーションを管理します。この場合、アプリケーションを実行するインフラストラクチャを自社で用意します。Mule アプリケーションの高可用性を保証するには、Runtime Manager を使用して Mule Runtime を管理します。 MuleSoft には、組み込みの PaaS ソリューション、​[Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/)​ もあります。Runtime Fabric では、「コンテナ化」された環境で Mule Runtime Engine を実行します。 Runtime Manager を使用するのに加えて、デプロイ用のコマンドといくつかの Anypoint Platform ユースケースが含まれる ​[Anypoint CLI 3.x](https://docs.mulesoft.com/jp/anypoint-cli/latest/anypoint-platform-cli-commands)​ を使用して Mule アプリケーションのデプロイと管理を実行することもできます。 ## [](#関連情報)関連情報 - [Mule アプリケーションの開発](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-app-dev) - [ドメイン](https://docs.mulesoft.com/studio/domain-support-concept) - [ポリシー](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) - [Mule 設定 XML](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-configuration) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule のダウンロード、インストール、アップグレード](https://docs.mulesoft.com/jp/mule-runtime/4.3/runtime-installation-task) # Mule Runtime Engine の概要 Mule Runtime Engine (Mule) は、Mule アプリケーションを実行する軽量のインテグレーションエンジンであり、ドメインとポリシーをサポートします。Mule アプリケーション、ドメイン、およびポリシーは、XML DSL (ドメイン特有言語) を共有します。 ## [](#mule-アプリケーション)Mule アプリケーション Mule アプリケーションは、ポイントツーポイントのインテグレーションではなく API 主導の接続性を使用してシステム、サービス、API、デバイスに接続します。Mule アプリケーションは、メッセージルーティング、データマッピング、オーケストレーション、信頼性、セキュリティ、スケーラビリティの機能を提供します。 Anypoint Studio は、Mule アプリケーションの開発をサポートします。 ## [](#mule-ドメイン)Mule ドメイン ドメインにより、デフォルトのエラーハンドラー、共有プロパティ、スケジューラープール、コンポーネント設定など、Mule アプリケーションが再利用する必要のあるグローバル設定を共有できます。ドメインをデプロイできるのは、オンプレミスで Mule Runtime Engine を実行している場合のみです。 Anypoint Studio を使用した Mule ドメインの開発と設定については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.4/shared-resources)​を参照してください。 ドメインデプロイメント手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ポリシー)ポリシー HTTP ベース API に基づいたポリシーにより、セキュリティの適用、Mule アプリケーションのトラフィックの規制、ビジネスニーズに合わせた API の活用が可能です。 Mule には、埋め込み API ゲートウェイが含まれています。これにより、コードを記述することなく、セキュリティポリシーを API に適用し、受信メッセージや送信メッセージを強化し、API に機能を追加できます。 詳細は、​[「API ゲートウェイ機能」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4)​を参照してください。 API Manager は、自動ポリシーの設定をサポートします。カスタムポリシー開発と設定もサポートされます。 ## [](#Maven)Maven サポート Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には Maven の機能が組み込まれています。Mule Runtime Engine では、Mule Maven プラグインを使用することで、Mule アプリケーション、ドメイン、カスタムポリシーのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 詳細は、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.4/using-maven-with-mule)​を参照してください。 ## [](#install_deploy_manage)Mule のインストール、デプロイ、管理 Mule アプリケーションを実行するには、Mule Runtime Engine がインストールされている環境に Mule アプリケーションをデプロイする必要があります。 Mule は、​[Studio](https://docs.mulesoft.com/studio/)​ IDE 内で Anypoint Platform 上の ​[Design Center](https://docs.mulesoft.com/design-center/)​ と共にパッケージ化されているため、設計するときに Mule アプリケーションを実行できます。 Unresolved include directive in modules/ROOT/pages/index.adoc - include::cloudhub-2::partial$index-runtime-plane-hosting-options.adoc\[\] Runtime Manager を使用するのに加えて、デプロイ用のコマンドといくつかの Anypoint Platform ユースケースが含まれる ​[Anypoint CLI 3.x](https://docs.mulesoft.com/jp/anypoint-cli/latest/anypoint-platform-cli-commands)​ を使用して Mule アプリケーションのデプロイと管理を実行することもできます。 ## [](#関連情報)関連情報 - [Mule アプリケーションの開発](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-app-dev) - [ドメイン](https://docs.mulesoft.com/studio/domain-support-concept) - [ポリシー](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) - [Mule 設定 XML](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-configuration) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule のダウンロード、インストール、アップグレード](https://docs.mulesoft.com/jp/mule-runtime/4.4/runtime-installation-task) # Mule Runtime Engine の概要 Mule Runtime Engine (Mule) は、Mule アプリケーションを実行する軽量のインテグレーションエンジンであり、ドメインとポリシーをサポートします。Mule アプリケーション、ドメイン、およびポリシーは、XML DSL (ドメイン特有言語) を共有します。 ## [](#mule-アプリケーション)Mule アプリケーション Mule アプリケーションは、ポイントツーポイントのインテグレーションではなく API 主導の接続性を使用してシステム、サービス、API、デバイスに接続します。Mule アプリケーションは、メッセージルーティング、データマッピング、オーケストレーション、信頼性、セキュリティ、スケーラビリティの機能を提供します。 Anypoint Studio は、Mule アプリケーションの開発をサポートします。 ## [](#mule-ドメイン)Mule ドメイン ドメインにより、デフォルトのエラーハンドラー、共有プロパティ、スケジューラープール、コンポーネント設定など、Mule アプリケーションが再利用する必要のあるグローバル設定を共有できます。ドメインをデプロイできるのは、オンプレミスで Mule Runtime Engine を実行している場合のみです。 Anypoint Studio を使用した Mule ドメインの開発と設定については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.5/shared-resources)​を参照してください。 ドメインデプロイメント手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ポリシー)ポリシー HTTP ベース API に基づいたポリシーにより、セキュリティの適用、Mule アプリケーションのトラフィックの規制、ビジネスニーズに合わせた API の活用が可能です。 Mule には、埋め込み API ゲートウェイが含まれています。これにより、コードを記述することなく、セキュリティポリシーを API に適用し、受信メッセージや送信メッセージを強化し、API に機能を追加できます。 詳細は、​[「API ゲートウェイ機能」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4)​を参照してください。 API Manager は、自動ポリシーの設定をサポートします。カスタムポリシー開発と設定もサポートされます。 ## [](#Maven)Maven サポート Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には Maven の機能が組み込まれています。Mule Runtime Engine では、Mule Maven プラグインを使用することで、Mule アプリケーション、ドメイン、カスタムポリシーのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 詳細は、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.5/using-maven-with-mule)​を参照してください。 ## [](#install_deploy_manage)Mule のインストール、デプロイ、管理 Mule アプリケーションを実行するには、Mule Runtime Engine がインストールされている環境に Mule アプリケーションをデプロイする必要があります。 Mule は、​[Studio](https://docs.mulesoft.com/studio/)​ IDE 内で Anypoint Platform 上の ​[Design Center](https://docs.mulesoft.com/design-center/)​ と共にパッケージ化されているため、設計するときに Mule アプリケーションを実行できます。 Unresolved include directive in modules/ROOT/pages/index.adoc - include::cloudhub-2::partial$index-runtime-plane-hosting-options.adoc\[\] Runtime Manager を使用するのに加えて、デプロイ用のコマンドといくつかの Anypoint Platform ユースケースが含まれる ​[Anypoint CLI 3.x](https://docs.mulesoft.com/jp/anypoint-cli/latest/anypoint-platform-cli-commands)​ を使用して Mule アプリケーションのデプロイと管理を実行することもできます。 ## [](#関連情報)関連情報 - [Mule アプリケーションの開発](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-app-dev) - [ドメイン](https://docs.mulesoft.com/studio/domain-support-concept) - [ポリシー](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) - [Mule 設定 XML](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-configuration) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule のダウンロード、インストール、アップグレード](https://docs.mulesoft.com/jp/mule-runtime/4.5/runtime-installation-task) # Mule Runtime Engine の概要 Mule Runtime Engine (Mule) は、Mule アプリケーションを実行する軽量のインテグレーションエンジンであり、ドメインとポリシーをサポートします。Mule アプリケーション、ドメイン、およびポリシーは、XML DSL (ドメイン特有言語) を共有します。 ## [](#mule-アプリケーション)Mule アプリケーション Mule アプリケーションは、ポイントツーポイントのインテグレーションではなく API 主導の接続性を使用してシステム、サービス、API、デバイスに接続します。Mule アプリケーションは、メッセージルーティング、データマッピング、オーケストレーション、信頼性、セキュリティ、スケーラビリティの機能を提供します。 Anypoint Studio は、Mule アプリケーションの開発をサポートします。 ## [](#mule-ドメイン)Mule ドメイン ドメインにより、デフォルトのエラーハンドラー、共有プロパティ、スケジューラープール、コンポーネント設定など、Mule アプリケーションが再利用する必要のあるグローバル設定を共有できます。ドメインをデプロイできるのは、オンプレミスで Mule Runtime Engine を実行している場合のみです。 Anypoint Studio を使用した Mule ドメインの開発と設定については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.6/shared-resources)​を参照してください。 ドメインデプロイメント手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ポリシー)ポリシー HTTP ベース API に基づいたポリシーにより、セキュリティの適用、Mule アプリケーションのトラフィックの規制、ビジネスニーズに合わせた API の活用が可能です。 Mule には、埋め込み API ゲートウェイが含まれています。これにより、コードを記述することなく、セキュリティポリシーを API に適用し、受信メッセージや送信メッセージを強化し、API に機能を追加できます。 詳細は、​[「API ゲートウェイ機能」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4)​を参照してください。 API Manager は、自動ポリシーの設定をサポートします。カスタムポリシー開発と設定もサポートされます。 ## [](#Maven)Maven サポート Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には Maven の機能が組み込まれています。Mule Runtime Engine では、Mule Maven プラグインを使用することで、Mule アプリケーション、ドメイン、カスタムポリシーのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 詳細は、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.6/using-maven-with-mule)​を参照してください。 ## [](#install_deploy_manage)Mule のインストール、デプロイ、管理 Mule アプリケーションを実行するには、Mule Runtime Engine がインストールされている環境に Mule アプリケーションをデプロイする必要があります。 Mule は、​[Studio](https://docs.mulesoft.com/studio/)​ IDE 内で Anypoint Platform 上の ​[Design Center](https://docs.mulesoft.com/design-center/)​ と共にパッケージ化されているため、設計するときに Mule アプリケーションを実行できます。 Unresolved include directive in modules/ROOT/pages/index.adoc - include::cloudhub-2::partial$index-runtime-plane-hosting-options.adoc\[\] Runtime Manager を使用するのに加えて、デプロイ用のコマンドといくつかの Anypoint Platform ユースケースが含まれる ​[Anypoint CLI 3.x](https://docs.mulesoft.com/jp/anypoint-cli/latest/anypoint-platform-cli-commands)​ を使用して Mule アプリケーションのデプロイと管理を実行することもできます。 ## [](#関連情報)関連情報 - [Mule アプリケーションの開発](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-app-dev) - [ドメイン](https://docs.mulesoft.com/studio/domain-support-concept) - [ポリシー](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) - [Mule 設定 XML](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-configuration) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule のダウンロード、インストール、アップグレード](https://docs.mulesoft.com/jp/mule-runtime/4.6/runtime-installation-task) # Mule Runtime Engine の概要 Mule Runtime Engine (Mule) は、Mule アプリケーションを実行する軽量のインテグレーションエンジンであり、ドメインとポリシーをサポートします。Mule アプリケーション、ドメイン、およびポリシーは、XML DSL (ドメイン特有言語) を共有します。 ## [](#mule-アプリケーション)Mule アプリケーション Mule アプリケーションは、ポイントツーポイントのインテグレーションではなく API 主導の接続性を使用してシステム、サービス、API、デバイスに接続します。Mule アプリケーションは、メッセージルーティング、データマッピング、オーケストレーション、信頼性、セキュリティ、スケーラビリティの機能を提供します。 Anypoint Studio は、Mule アプリケーションの開発をサポートします。 ## [](#mule-ドメイン)Mule ドメイン ドメインにより、デフォルトのエラーハンドラー、共有プロパティ、スケジューラープール、コンポーネント設定など、Mule アプリケーションが再利用する必要のあるグローバル設定を共有できます。ドメインをデプロイできるのは、オンプレミスで Mule Runtime Engine を実行している場合のみです。 Anypoint Studio を使用した Mule ドメインの開発と設定については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.7/shared-resources)​を参照してください。 ドメインデプロイメント手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ポリシー)ポリシー HTTP ベース API に基づいたポリシーにより、セキュリティの適用、Mule アプリケーションのトラフィックの規制、ビジネスニーズに合わせた API の活用が可能です。 Mule には、埋め込み API ゲートウェイが含まれています。これにより、コードを記述することなく、セキュリティポリシーを API に適用し、受信メッセージや送信メッセージを強化し、API に機能を追加できます。 詳細は、​[「API ゲートウェイ機能」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4)​を参照してください。 API Manager は、自動ポリシーの設定をサポートします。カスタムポリシー開発と設定もサポートされます。 ## [](#Maven)Maven サポート Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には Maven の機能が組み込まれています。Mule Runtime Engine では、Mule Maven プラグインを使用することで、Mule アプリケーション、ドメイン、カスタムポリシーのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 詳細は、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.7/using-maven-with-mule)​を参照してください。 ## [](#install_deploy_manage)Mule のインストール、デプロイ、管理 Mule アプリケーションを実行するには、Mule Runtime Engine がインストールされている環境に Mule アプリケーションをデプロイする必要があります。 Mule は、​[Studio](https://docs.mulesoft.com/studio/)​ IDE 内で Anypoint Platform 上の ​[Design Center](https://docs.mulesoft.com/design-center/)​ と共にパッケージ化されているため、設計するときに Mule アプリケーションを実行できます。 Unresolved include directive in modules/ROOT/pages/index.adoc - include::cloudhub-2::partial$index-runtime-plane-hosting-options.adoc\[\] Runtime Manager を使用するのに加えて、デプロイ用のコマンドといくつかの Anypoint Platform ユースケースが含まれる ​[Anypoint CLI 3.x](https://docs.mulesoft.com/jp/anypoint-cli/latest/anypoint-platform-cli-commands)​ を使用して Mule アプリケーションのデプロイと管理を実行することもできます。 ## [](#関連情報)関連情報 - [Mule アプリケーションの開発](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-app-dev) - [ドメイン](https://docs.mulesoft.com/studio/domain-support-concept) - [ポリシー](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) - [Mule 設定 XML](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-configuration) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule のダウンロード、インストール、アップグレード](https://docs.mulesoft.com/jp/mule-runtime/4.7/runtime-installation-task) # Mule Runtime Engine の概要 Mule Runtime Engine (Mule) は、Mule アプリケーションを実行する軽量のインテグレーションエンジンであり、ドメインとポリシーをサポートします。Mule アプリケーション、ドメイン、およびポリシーは、XML DSL (ドメイン特有言語) を共有します。 ## [](#mule-アプリケーション)Mule アプリケーション Mule アプリケーションは、ポイントツーポイントのインテグレーションではなく API 主導の接続性を使用してシステム、サービス、API、デバイスに接続します。Mule アプリケーションは、メッセージルーティング、データマッピング、オーケストレーション、信頼性、セキュリティ、スケーラビリティの機能を提供します。 Anypoint Studio は、Mule アプリケーションの開発をサポートします。 ## [](#mule-ドメイン)Mule ドメイン ドメインにより、デフォルトのエラーハンドラー、共有プロパティ、スケジューラープール、コンポーネント設定など、Mule アプリケーションが再利用する必要のあるグローバル設定を共有できます。ドメインをデプロイできるのは、オンプレミスで Mule Runtime Engine を実行している場合のみです。 Anypoint Studio を使用した Mule ドメインの開発と設定については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.8/shared-resources)​を参照してください。 ドメインデプロイメント手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ポリシー)ポリシー HTTP ベース API に基づいたポリシーにより、セキュリティの適用、Mule アプリケーションのトラフィックの規制、ビジネスニーズに合わせた API の活用が可能です。 Mule には、埋め込み API ゲートウェイが含まれています。これにより、コードを記述することなく、セキュリティポリシーを API に適用し、受信メッセージや送信メッセージを強化し、API に機能を追加できます。 詳細は、​[「API ゲートウェイ機能」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4)​を参照してください。 API Manager は、自動ポリシーの設定をサポートします。カスタムポリシー開発と設定もサポートされます。 ## [](#Maven)Maven サポート Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には Maven の機能が組み込まれています。Mule Runtime Engine では、Mule Maven プラグインを使用することで、Mule アプリケーション、ドメイン、カスタムポリシーのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 詳細は、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.8/using-maven-with-mule)​を参照してください。 ## [](#install_deploy_manage)Mule のインストール、デプロイ、管理 Mule アプリケーションを実行するには、Mule Runtime Engine がインストールされている環境に Mule アプリケーションをデプロイする必要があります。 Mule は、​[Studio](https://docs.mulesoft.com/studio/)​ IDE 内で Anypoint Platform 上の ​[Design Center](https://docs.mulesoft.com/design-center/)​ と共にパッケージ化されているため、設計するときに Mule アプリケーションを実行できます。 Unresolved include directive in modules/ROOT/pages/index.adoc - include::cloudhub-2::partial$index-runtime-plane-hosting-options.adoc\[\] Runtime Manager を使用するのに加えて、デプロイ用のコマンドといくつかの Anypoint Platform ユースケースが含まれる ​[Anypoint CLI 3.x](https://docs.mulesoft.com/jp/anypoint-cli/latest/anypoint-platform-cli-commands)​ を使用して Mule アプリケーションのデプロイと管理を実行することもできます。 ## [](#関連情報)関連情報 - [Mule アプリケーションの開発](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-app-dev) - [ドメイン](https://docs.mulesoft.com/studio/domain-support-concept) - [ポリシー](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) - [Mule 設定 XML](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-configuration) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule のダウンロード、インストール、アップグレード](https://docs.mulesoft.com/jp/mule-runtime/4.8/runtime-installation-task) # Mule Runtime Engine の概要 Mule Runtime Engine (Mule) は、Mule アプリケーションを実行する軽量のインテグレーションエンジンであり、ドメインとポリシーをサポートします。Mule アプリケーション、ドメイン、およびポリシーは、XML DSL (ドメイン特有言語) を共有します。 ## [](#mule-アプリケーション)Mule アプリケーション Mule アプリケーションは、ポイントツーポイントのインテグレーションではなく API 主導の接続性を使用してシステム、サービス、API、デバイスに接続します。Mule アプリケーションは、メッセージルーティング、データマッピング、オーケストレーション、信頼性、セキュリティ、スケーラビリティの機能を提供します。 Anypoint Studio は、Mule アプリケーションの開発をサポートします。 ## [](#mule-ドメイン)Mule ドメイン ドメインにより、デフォルトのエラーハンドラー、共有プロパティ、スケジューラープール、コンポーネント設定など、Mule アプリケーションが再利用する必要のあるグローバル設定を共有できます。ドメインをデプロイできるのは、オンプレミスで Mule Runtime Engine を実行している場合のみです。 Anypoint Studio を使用した Mule ドメインの開発と設定については、​[「共有リソース」](https://docs.mulesoft.com/jp/mule-runtime/4.9/shared-resources)​を参照してください。 ドメインデプロイメント手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ポリシー)ポリシー HTTP ベース API に基づいたポリシーにより、セキュリティの適用、Mule アプリケーションのトラフィックの規制、ビジネスニーズに合わせた API の活用が可能です。 Mule には、埋め込み API ゲートウェイが含まれています。これにより、コードを記述することなく、セキュリティポリシーを API に適用し、受信メッセージや送信メッセージを強化し、API に機能を追加できます。 詳細は、​[「API ゲートウェイ機能」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4)​を参照してください。 API Manager は、自動ポリシーの設定をサポートします。カスタムポリシー開発と設定もサポートされます。 ## [](#Maven)Maven サポート Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には Maven の機能が組み込まれています。Mule Runtime Engine では、Mule Maven プラグインを使用することで、Mule アプリケーション、ドメイン、カスタムポリシーのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 詳細は、​[「Mule での Maven サポート」](https://docs.mulesoft.com/jp/mule-runtime/4.9/using-maven-with-mule)​を参照してください。 ## [](#install_deploy_manage)Mule のインストール、デプロイ、管理 Mule アプリケーションを実行するには、Mule Runtime Engine がインストールされている環境に Mule アプリケーションをデプロイする必要があります。 Mule は、​[Studio](https://docs.mulesoft.com/studio/)​ IDE 内で Anypoint Platform 上の ​[Design Center](https://docs.mulesoft.com/design-center/)​ と共にパッケージ化されているため、設計するときに Mule アプリケーションを実行できます。 Unresolved include directive in modules/ROOT/pages/index.adoc - include::cloudhub-2::partial$index-runtime-plane-hosting-options.adoc\[\] Runtime Manager を使用するのに加えて、デプロイ用のコマンドといくつかの Anypoint Platform ユースケースが含まれる ​[Anypoint CLI 3.x](https://docs.mulesoft.com/jp/anypoint-cli/latest/anypoint-platform-cli-commands)​ を使用して Mule アプリケーションのデプロイと管理を実行することもできます。 ## [](#関連情報)関連情報 - [Mule アプリケーションの開発](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-app-dev) - [ドメイン](https://docs.mulesoft.com/studio/domain-support-concept) - [ポリシー](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) - [Mule 設定 XML](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-configuration) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule のダウンロード、インストール、アップグレード](https://docs.mulesoft.com/jp/mule-runtime/4.9/runtime-installation-task) # Mule Runtime Release Notes Mule follows semantic versioning to denote major, minor, and patch releases. MuleSoft releases enhance the quality, capabilities, and security of Mule runtime engine (Mule). To take advantage of these improvements, it’s important to adopt a strategy for upgrading your Mule version and to regularly update patches of your Mule deployments with the latest bug fixes and security enhancements. To upgrade to a new Mule version, see [Mule Upgrades and Patch Updates](#mule-upgrades). ## [](#mule-4-release-notes)Mule 4 Release Notes - [Mule Runtime 4.13.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.13.0-release-notes) - [Mule Runtime 4.12.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.12.0-release-notes) - [Mule Runtime 4.11.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.11.0-release-notes) - [Mule Runtime 4.9.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.9.0-release-notes) - [Mule Runtime 4.6.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.6.0-release-notes) - [Mule Runtime 4.4.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.4.0-release-notes) (This version of the product has reached [End of Life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).) - [Mule Runtime 4.3.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.3.0-release-notes) (This version of the product has reached [End of Life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).) ## [](#mule-upgrades)Mule Upgrades and Patch Updates For Mule 4 upgrades and patch updates: - [Java Adoption](https://docs.mulesoft.com/jp/release-notes/mule-runtime/java-adoption) - [Edge and LTS Releases for Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence) (for Mule versions 4.6 and later) - [Mule Upgrade Tool](https://docs.mulesoft.com/mule-runtime/latest/mule-upgrade-tool) (for upgrading standalone Mule 4 instances, including minor versions and patch updates) - [Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) (overview) - [Update Patches to Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/patching-mule-versions) - [Upgrading Mule Runtime Engine (Versions 4.x to 4.n)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions) ## [](#mule-troubleshooting-plugin)Mule Troubleshooting Plugin - [Mule Troubleshooting Plugin](https://docs.mulesoft.com/mule-runtime/latest/mule-troubleshooting-plugin) ## [](#mule-services)Mule Services - [HTTP Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-http-release-notes) - [OAuth Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-oauth-release-notes) - [Scheduler Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-scheduler-release-notes) - [Mule SOAP Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-soap-release-notes) ## [](#anypoint-enterprise-security)Anypoint Enterprise Security - [Anypoint Security Release Notes](https://docs.mulesoft.com/jp/release-notes/anypoint-security/anypoint-security-rn-landing-page) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # Mule Runtime Release Notes Mule follows semantic versioning to denote major, minor, and patch releases. MuleSoft releases enhance the quality, capabilities, and security of Mule runtime engine (Mule). To take advantage of these improvements, it’s important to adopt a strategy for upgrading your Mule version and to regularly update patches of your Mule deployments with the latest bug fixes and security enhancements. To upgrade to a new Mule version, see [Mule Upgrades and Patch Updates](#mule-upgrades). ## [](#mule-4-release-notes)Mule 4 Release Notes - [Mule Runtime 4.13.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.13.0-release-notes) - [Mule Runtime 4.12.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.12.0-release-notes) - [Mule Runtime 4.11.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.11.0-release-notes) - [Mule Runtime 4.9.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.9.0-release-notes) - [Mule Runtime 4.6.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.6.0-release-notes) - [Mule Runtime 4.4.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.4.0-release-notes) (This version of the product has reached [End of Life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).) - [Mule Runtime 4.3.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.3.0-release-notes) (This version of the product has reached [End of Life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).) ## [](#mule-upgrades)Mule Upgrades and Patch Updates For Mule 4 upgrades and patch updates: - [Java Adoption](https://docs.mulesoft.com/jp/release-notes/mule-runtime/java-adoption) - [Edge and LTS Releases for Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence) (for Mule versions 4.6 and later) - [Mule Upgrade Tool](https://docs.mulesoft.com/mule-runtime/latest/mule-upgrade-tool) (for upgrading standalone Mule 4 instances, including minor versions and patch updates) - [Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) (overview) - [Update Patches to Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/patching-mule-versions) - [Upgrading Mule Runtime Engine (Versions 4.x to 4.n)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions) ## [](#mule-troubleshooting-plugin)Mule Troubleshooting Plugin - [Mule Troubleshooting Plugin](https://docs.mulesoft.com/mule-runtime/latest/mule-troubleshooting-plugin) ## [](#mule-services)Mule Services - [HTTP Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-http-release-notes) - [OAuth Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-oauth-release-notes) - [Scheduler Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-scheduler-release-notes) - [Mule SOAP Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-soap-release-notes) ## [](#anypoint-enterprise-security)Anypoint Enterprise Security - [Anypoint Security Release Notes](https://docs.mulesoft.com/jp/release-notes/anypoint-security/anypoint-security-rn-landing-page) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # Mule Runtime Release Notes Mule follows semantic versioning to denote major, minor, and patch releases. MuleSoft releases enhance the quality, capabilities, and security of Mule runtime engine (Mule). To take advantage of these improvements, it’s important to adopt a strategy for upgrading your Mule version and to regularly update patches of your Mule deployments with the latest bug fixes and security enhancements. To upgrade to a new Mule version, see [Mule Upgrades and Patch Updates](#mule-upgrades). ## [](#mule-4-release-notes)Mule 4 Release Notes - [Mule Runtime 4.13.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.13.0-release-notes) - [Mule Runtime 4.12.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.12.0-release-notes) - [Mule Runtime 4.11.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.11.0-release-notes) - [Mule Runtime 4.9.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.9.0-release-notes) - [Mule Runtime 4.6.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.6.0-release-notes) - [Mule Runtime 4.4.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.4.0-release-notes) (This version of the product has reached [End of Life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).) - [Mule Runtime 4.3.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.3.0-release-notes) (This version of the product has reached [End of Life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).) ## [](#mule-upgrades)Mule Upgrades and Patch Updates For Mule 4 upgrades and patch updates: - [Java Adoption](https://docs.mulesoft.com/jp/release-notes/mule-runtime/java-adoption) - [Edge and LTS Releases for Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence) (for Mule versions 4.6 and later) - [Mule Upgrade Tool](https://docs.mulesoft.com/mule-runtime/latest/mule-upgrade-tool) (for upgrading standalone Mule 4 instances, including minor versions and patch updates) - [Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) (overview) - [Update Patches to Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/patching-mule-versions) - [Upgrading Mule Runtime Engine (Versions 4.x to 4.n)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions) ## [](#mule-troubleshooting-plugin)Mule Troubleshooting Plugin - [Mule Troubleshooting Plugin](https://docs.mulesoft.com/mule-runtime/latest/mule-troubleshooting-plugin) ## [](#mule-services)Mule Services - [HTTP Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-http-release-notes) - [OAuth Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-oauth-release-notes) - [Scheduler Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-scheduler-release-notes) - [Mule SOAP Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-soap-release-notes) ## [](#anypoint-enterprise-security)Anypoint Enterprise Security - [Anypoint Security Release Notes](https://docs.mulesoft.com/jp/release-notes/anypoint-security/anypoint-security-rn-landing-page) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # Mule Runtime Release Notes Mule follows semantic versioning to denote major, minor, and patch releases. MuleSoft releases enhance the quality, capabilities, and security of Mule runtime engine (Mule). To take advantage of these improvements, it’s important to adopt a strategy for upgrading your Mule version and to regularly update patches of your Mule deployments with the latest bug fixes and security enhancements. To upgrade to a new Mule version, see [Mule Upgrades and Patch Updates](#mule-upgrades). ## [](#mule-4-release-notes)Mule 4 Release Notes - [Mule Runtime 4.13.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.13.0-release-notes) - [Mule Runtime 4.12.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.12.0-release-notes) - [Mule Runtime 4.11.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.11.0-release-notes) - [Mule Runtime 4.9.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.9.0-release-notes) - [Mule Runtime 4.6.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.6.0-release-notes) - [Mule Runtime 4.4.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.4.0-release-notes) (This version of the product has reached [End of Life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).) - [Mule Runtime 4.3.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.3.0-release-notes) (This version of the product has reached [End of Life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).) ## [](#mule-upgrades)Mule Upgrades and Patch Updates For Mule 4 upgrades and patch updates: - [Java Adoption](https://docs.mulesoft.com/jp/release-notes/mule-runtime/java-adoption) - [Edge and LTS Releases for Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence) (for Mule versions 4.6 and later) - [Mule Upgrade Tool](https://docs.mulesoft.com/mule-runtime/latest/mule-upgrade-tool) (for upgrading standalone Mule 4 instances, including minor versions and patch updates) - [Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) (overview) - [Update Patches to Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/patching-mule-versions) - [Upgrading Mule Runtime Engine (Versions 4.x to 4.n)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions) ## [](#mule-troubleshooting-plugin)Mule Troubleshooting Plugin - [Mule Troubleshooting Plugin](https://docs.mulesoft.com/mule-runtime/latest/mule-troubleshooting-plugin) ## [](#mule-services)Mule Services - [HTTP Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-http-release-notes) - [OAuth Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-oauth-release-notes) - [Scheduler Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-scheduler-release-notes) - [Mule SOAP Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-soap-release-notes) ## [](#anypoint-enterprise-security)Anypoint Enterprise Security - [Anypoint Security Release Notes](https://docs.mulesoft.com/jp/release-notes/anypoint-security/anypoint-security-rn-landing-page) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # Mule Runtime Release Notes Mule follows semantic versioning to denote major, minor, and patch releases. MuleSoft releases enhance the quality, capabilities, and security of Mule runtime engine (Mule). To take advantage of these improvements, it’s important to adopt a strategy for upgrading your Mule version and to regularly update patches of your Mule deployments with the latest bug fixes and security enhancements. To upgrade to a new Mule version, see [Mule Upgrades and Patch Updates](#mule-upgrades). ## [](#mule-4-release-notes)Mule 4 Release Notes - [Mule Runtime 4.13.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.13.0-release-notes) - [Mule Runtime 4.12.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.12.0-release-notes) - [Mule Runtime 4.11.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.11.0-release-notes) - [Mule Runtime 4.9.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.9.0-release-notes) - [Mule Runtime 4.6.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.6.0-release-notes) - [Mule Runtime 4.4.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.4.0-release-notes) (This version of the product has reached [End of Life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).) - [Mule Runtime 4.3.0 Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-4.3.0-release-notes) (This version of the product has reached [End of Life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).) ## [](#mule-upgrades)Mule Upgrades and Patch Updates For Mule 4 upgrades and patch updates: - [Java Adoption](https://docs.mulesoft.com/jp/release-notes/mule-runtime/java-adoption) - [Edge and LTS Releases for Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence) (for Mule versions 4.6 and later) - [Mule Upgrade Tool](https://docs.mulesoft.com/mule-runtime/latest/mule-upgrade-tool) (for upgrading standalone Mule 4 instances, including minor versions and patch updates) - [Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) (overview) - [Update Patches to Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/patching-mule-versions) - [Upgrading Mule Runtime Engine (Versions 4.x to 4.n)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions) ## [](#mule-troubleshooting-plugin)Mule Troubleshooting Plugin - [Mule Troubleshooting Plugin](https://docs.mulesoft.com/mule-runtime/latest/mule-troubleshooting-plugin) ## [](#mule-services)Mule Services - [HTTP Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-http-release-notes) - [OAuth Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-oauth-release-notes) - [Scheduler Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-scheduler-release-notes) - [Mule SOAP Service Release Notes - Mule 4](https://docs.mulesoft.com/jp/release-notes/mule-runtime/service-soap-release-notes) ## [](#anypoint-enterprise-security)Anypoint Enterprise Security - [Anypoint Security Release Notes](https://docs.mulesoft.com/jp/release-notes/anypoint-security/anypoint-security-rn-landing-page) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # Mule Runtime シャットダウン時の HTTP 接続処理の理解 Mule Runtime Engine (Mule) は、2 フェーズのグレースフルシャットダウンプロセス (この後に強制終了が発生) を介してシャットダウン時の HTTP 接続を管理します。 このプロセスでは、まず新規接続を拒否し、​`Connection: close`​ シグナルを使用して既存の接続を完了できるようにします。次に、新規要求を完全に拒否し、その間にインフライト処理を終了します。最後にタイムアウト時に残っているすべての接続を強制終了します。 シームレスなスケールダウンのシナリオがサポートされているため、トラフィックを段階的にドレーンしてアプリケーションの安定性と信頼性を維持しつつ、Mule レプリカを削減できます。 ## [](#http-接続処理の図)HTTP 接続処理の図 この図は、Mule シャットダウン時の HTTP 接続の動作を示しています。 ![runtime http connections diagram](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/runtime-http-connections-diagram.png) フェーズ 1: Mule の起動 - Mule の状態: Mule が起動し、通常どおりに実行されます。 - HTTP の動作: すべての受信 HTTP トラフィックが Mule にルーティングされて処理されます。特殊な処理は行われません。 推移: 停止シグナルを Mule に送信 - 停止シグナルを Mule インスタンスに送信することでシャットダウンシーケンスが開始されます。 フェーズ 2: HTTP グレースフルシャットダウン - Mule の停止 - トリガー: 停止シグナルの受信。 - 期間: 設定された HTTP グレースフルタイムアウト (デフォルト: 5 秒)。ただし、このタイムアウト期間が経過する前に既存のすべての HTTP 接続が終了した場合、HTTP グレースフルシャットダウンフェーズは早期に終了し、Mule はタイムアウト期間全体を待機することはありません。 - Mule の状態: Mule のシャットダウンが開始されるか、\[stopped (停止済み)\] に移行します。 - HTTP の動作: - 新規接続なし: HTTP サーバーは新しい受信 TCP 接続の受け入れを停止します (アクセプターソケットが閉じる)。 - 既存の要求とインフライト要求: 進行中の HTTP 要求 (すでに処理中のインフライト要求と、既存の確立された接続の要求) は引き続き通常どおり処理されます。ただし、現在の要求-応答サイクルが完了した後に接続を終了するように HTTP クライアントに通知する ​`Connection: close`​ ヘッダーがすべての応答に含まれます。 - 早期終了: 停止シグナルを受信したときにアクティブな HTTP 接続がない場合、タイムアウト期間が終了する前でも、HTTP グレースフルシャットダウンフェーズは即座に終了します。 - 遅れて到着した要求: HTTP 要求が HTTP グレースフルタイムアウトに達する直前に到着した場合、HTTP グレースフルシャットダウンタイムアウトを経過しても通常どおり処理されます。 推移: HTTP グレースフルシャットダウンタイムアウトが経過 - HTTP グレースフルシャットダウンの設定された期間が終了します。 フェーズ 3: Mule グレースフルシャットダウン - Mule の停止 - トリガー: HTTP グレースフルシャットダウンタイムアウトの終了。 - 期間: 設定された Mule グレースフルシャットダウンタイムアウト (デフォルト: 5 秒)。 - Mule の状態: Mule がグレースフルシャットダウンします。 - HTTP の動作: - 新規要求を拒否 (503): 実行時に到着する新しい HTTP 要求は、「503 Service Unavailable」 (503 サービスを利用できません) エラーで即座に拒否されます。 - 新規要求を拒否 (404): Mule アプリケーションで基盤となる HTTP サーバーの HTTP エンドポイントが登録解除されると、後続の新しい HTTP 要求で「404 Not Found」 (404 見つかりません) エラーが発生します。 - インフライトメッセージを完了: すでに完全に読み取られた処理中の HTTP 要求 (インフライトメッセージ) の実行が通常どおりに完了します。 推移: Mule グレースフルシャットダウンタイムアウトが経過 - Mule 全体のグレースフルシャットダウンの設定された期間が終了します。 フェーズ 4: Mule の停止 - トリガー: Mule グレースフルシャットダウンタイムアウトの終了。 - Mule の状態: Mule が停止します。 - 動作: Mule プロセスが強制シャットダウンに進み、最終的に終了します。その結果、次のようになります。 - 残りの開いているすべての HTTP 接続が突然終了します。 - 終了時のソケットの TCP 状況によって、これらの強制終了された接続に接続されているクライアントで接続リセットエラーやパイプ破損エラーが発生する可能性があります。 ## [](#シャットダウンタイムアウトの設定)シャットダウンタイムアウトの設定 HTTP グレースフルシャットダウンタイムアウトと Mule 全体のグレースフルシャットダウンタイムアウトは、シャットダウンシーケンスで異なる目的を果たしますが、Mule アプリケーションの XML ファイルの ​``​ 要素内の同じ ​`shutdownTimeout`​ パラメーターを使用して設定します。 ミリ秒 (デフォルトでは 5000 ミリ秒) 単位で値を指定します。これにより、両方のグレースフルシャットダウンの最大期間を制御します。次に例を示します。 ```xml ``` 詳細は、​[「グローバル設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.3/global-settings-configuration#global-configurations-reference)​を参照してください。 # Mule Runtime シャットダウン時の HTTP 接続処理の理解 Mule Runtime Engine (Mule) は、2 フェーズのグレースフルシャットダウンプロセス (この後に強制終了が発生) を介してシャットダウン時の HTTP 接続を管理します。 このプロセスでは、まず新規接続を拒否し、​`Connection: close`​ シグナルを使用して既存の接続を完了できるようにします。次に、新規要求を完全に拒否し、その間にインフライト処理を終了します。最後にタイムアウト時に残っているすべての接続を強制終了します。 シームレスなスケールダウンのシナリオがサポートされているため、トラフィックを段階的にドレーンしてアプリケーションの安定性と信頼性を維持しつつ、Mule レプリカを削減できます。 ## [](#http-接続処理の図)HTTP 接続処理の図 この図は、Mule シャットダウン時の HTTP 接続処理の動作を示しています。 ![runtime http connections diagram](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/runtime-http-connections-diagram.png) フェーズ 1: Mule の起動 - Mule の状態: Mule が起動し、通常どおりに実行されます。 - HTTP の動作: すべての受信 HTTP トラフィックが Mule にルーティングされて処理されます。特殊な処理は行われません。 推移: 停止シグナルを Mule に送信 - 停止シグナルを Mule インスタンスに送信することでシャットダウンシーケンスが開始されます。 フェーズ 2: HTTP グレースフルシャットダウン - Mule の停止 - トリガー: 停止シグナルの受信。 - 期間: 設定された HTTP グレースフルタイムアウト (デフォルト: 5 秒)。ただし、このタイムアウト期間が経過する前に既存のすべての HTTP 接続が終了した場合、HTTP グレースフルシャットダウンフェーズは早期に終了し、Mule はタイムアウト期間全体を待機することはありません。 - Mule の状態: Mule のシャットダウンが開始されるか、\[stopped (停止済み)\] に移行します。 - HTTP の動作: - 新規接続なし: HTTP サーバーは新しい受信 TCP 接続の受け入れを停止します (アクセプターソケットが閉じる)。 - 既存の要求とインフライト要求: 進行中の HTTP 要求 (すでに処理中のインフライト要求と、既存の確立された接続の要求) は引き続き通常どおり処理されます。ただし、現在の要求-応答サイクルが完了した後に接続を終了するように HTTP クライアントに通知する ​`Connection: close`​ ヘッダーがすべての応答に含まれます。 - 早期終了: 停止シグナルを受信したときにアクティブな HTTP 接続がない場合、タイムアウト期間が終了する前でも、HTTP グレースフルシャットダウンフェーズは即座に終了します。 - 遅れて到着した要求: HTTP 要求が HTTP グレースフルタイムアウトに達する直前に到着した場合、HTTP グレースフルシャットダウンタイムアウトを経過しても通常どおり処理されます。 推移: HTTP グレースフルシャットダウンタイムアウトが経過 - HTTP グレースフルシャットダウンの設定された期間が終了します。 フェーズ 3: Mule グレースフルシャットダウン - Mule の停止 - トリガー: HTTP グレースフルシャットダウンタイムアウトの終了。 - 期間: 設定された Mule グレースフルシャットダウンタイムアウト (デフォルト: 5 秒)。 - Mule の状態: Mule がグレースフルシャットダウンします。 - HTTP の動作: - 新規要求を拒否 (503): 実行時に到着する新しい HTTP 要求は、「503 Service Unavailable」 (503 サービスを利用できません) エラーで即座に拒否されます。 - 新規要求を拒否 (404): Mule アプリケーションコードで基盤となる HTTP サーバーの HTTP エンドポイントが登録解除されると、後続の新しい HTTP 要求で「404 Not Found」 (404 見つかりません) エラーが発生します。 - インフライトメッセージを完了: すでに完全に読み取られた処理中の HTTP 要求 (インフライトメッセージ) の実行を通常どおりに完了できるようになります。 推移: Mule グレースフルシャットダウンタイムアウトが経過 - Mule 全体のグレースフルシャットダウンの設定された期間が終了します。 フェーズ 4: Mule の停止 - トリガー: Mule グレースフルシャットダウンタイムアウトの終了。 - Mule の状態: Mule が停止します。 - 動作: Mule プロセスが強制シャットダウンに進み、最終的に終了します。その結果、次のようになります。 - 残りの開いているすべての HTTP 接続が突然終了します。 - 終了時のソケットの TCP 状況によって、これらの強制終了された接続に接続されているクライアントで接続リセットエラーやパイプ破損エラーが発生する可能性があります。 ## [](#シャットダウンタイムアウトの設定)シャットダウンタイムアウトの設定 HTTP グレースフルシャットダウンタイムアウトと Mule 全体のグレースフルシャットダウンタイムアウトは、シャットダウンシーケンスで異なる目的を果たしますが、Mule アプリケーションの XML ファイルの ​``​ 要素内の同じ ​`shutdownTimeout`​ パラメーターを使用して設定します。 ミリ秒 (デフォルトでは 5000 ミリ秒) 単位で値を指定します。これにより、両方のグレースフルシャットダウンの最大期間を制御します。次に例を示します。 ```xml ``` 詳細は、​[「グローバル設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.4/global-settings-configuration#global-configurations-reference)​を参照してください。 # Mule Runtime シャットダウン時の HTTP 接続処理の理解 Mule Runtime Engine (Mule) は、2 フェーズのグレースフルシャットダウンプロセス (この後に強制終了が発生) を介してシャットダウン時の HTTP 接続を管理します。 このプロセスでは、まず新規接続を拒否し、​`Connection: close`​ シグナルを使用して既存の接続を完了できるようにします。次に、新規要求を完全に拒否し、その間にインフライト処理を終了します。最後にタイムアウト時に残っているすべての接続を強制終了します。 シームレスなスケールダウンのシナリオがサポートされているため、トラフィックを段階的にドレーンしてアプリケーションの安定性と信頼性を維持しつつ、Mule レプリカを削減できます。 ## [](#http-接続処理の図)HTTP 接続処理の図 この図は、Mule シャットダウン時の HTTP 接続処理の動作を示しています。 ![runtime http connections diagram](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/runtime-http-connections-diagram.png) フェーズ 1: Mule の起動 - Mule の状態: Mule が起動し、通常どおりに実行されます。 - HTTP の動作: すべての受信 HTTP トラフィックが Mule にルーティングされて処理されます。特殊な処理は行われません。 推移: 停止シグナルを Mule に送信 - 停止シグナルを Mule インスタンスに送信することでシャットダウンシーケンスが開始されます。 フェーズ 2: HTTP グレースフルシャットダウン - Mule の停止 - トリガー: 停止シグナルの受信。 - 期間: 設定された HTTP グレースフルタイムアウト (デフォルト: 5 秒)。ただし、このタイムアウト期間が経過する前に既存のすべての HTTP 接続が終了した場合、HTTP グレースフルシャットダウンフェーズは早期に終了し、Mule はタイムアウト期間全体を待機することはありません。 - Mule の状態: Mule のシャットダウンが開始されるか、\[stopped (停止済み)\] に移行します。 - HTTP の動作: - 新規接続なし: HTTP サーバーは新しい受信 TCP 接続の受け入れを停止します (アクセプターソケットが閉じる)。 - 既存の要求とインフライト要求: 進行中の HTTP 要求 (すでに処理中のインフライト要求と、既存の確立された接続の要求) は引き続き通常どおり処理されます。ただし、現在の要求-応答サイクルが完了した後に接続を終了するように HTTP クライアントに通知する ​`Connection: close`​ ヘッダーがすべての応答に含まれます。 - 早期終了: 停止シグナルを受信したときにアクティブな HTTP 接続がない場合、タイムアウト期間が終了する前でも、HTTP グレースフルシャットダウンフェーズは即座に終了します。 - 遅れて到着した要求: HTTP 要求が HTTP グレースフルタイムアウトに達する直前に到着した場合、HTTP グレースフルシャットダウンタイムアウトを経過しても通常どおり処理されます。 推移: HTTP グレースフルシャットダウンタイムアウトが経過 - HTTP グレースフルシャットダウンの設定された期間が終了します。 フェーズ 3: Mule グレースフルシャットダウン - Mule の停止 - トリガー: HTTP グレースフルシャットダウンタイムアウトの終了。 - 期間: 設定された Mule グレースフルシャットダウンタイムアウト (デフォルト: 5 秒)。 - Mule の状態: Mule がグレースフルシャットダウンします。 - HTTP の動作: - 新規要求を拒否 (503): 実行時に到着する新しい HTTP 要求は、「503 Service Unavailable」 (503 サービスを利用できません) エラーで即座に拒否されます。 - 新規要求を拒否 (404): Mule アプリケーションコードで基盤となる HTTP サーバーの HTTP エンドポイントが登録解除されると、後続の新しい HTTP 要求で「404 Not Found」 (404 見つかりません) エラーが発生します。 - インフライトメッセージを完了: すでに完全に読み取られた処理中の HTTP 要求 (インフライトメッセージ) の実行を通常どおりに完了できるようになります。 推移: Mule グレースフルシャットダウンタイムアウトが経過 - Mule 全体のグレースフルシャットダウンの設定された期間が終了します。 フェーズ 4: Mule の停止 - トリガー: Mule グレースフルシャットダウンタイムアウトの終了。 - Mule の状態: Mule が停止します。 - 動作: Mule プロセスが強制シャットダウンに進み、最終的に終了します。その結果、次のようになります。 - 残りの開いているすべての HTTP 接続が突然終了します。 - 終了時のソケットの TCP 状況によって、これらの強制終了された接続に接続されているクライアントで接続リセットエラーやパイプ破損エラーが発生する可能性があります。 ## [](#シャットダウンタイムアウトの設定)シャットダウンタイムアウトの設定 HTTP グレースフルシャットダウンタイムアウトと Mule 全体のグレースフルシャットダウンタイムアウトは、シャットダウンシーケンスで異なる目的を果たしますが、Mule アプリケーションの XML ファイルの ​``​ 要素内の同じ ​`shutdownTimeout`​ パラメーターを使用して設定します。 ミリ秒 (デフォルトでは 5000 ミリ秒) 単位で値を指定します。これにより、両方のグレースフルシャットダウンの最大期間を制御します。次に例を示します。 ```xml ``` 詳細は、​[「グローバル設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.5/global-settings-configuration#global-configurations-reference)​を参照してください。 # Mule Runtime シャットダウン時の HTTP 接続処理の理解 Mule Runtime Engine (Mule) は、2 フェーズのグレースフルシャットダウンプロセス (この後に強制終了が発生) を介してシャットダウン時の HTTP 接続を管理します。 このプロセスでは、まず新規接続を拒否し、​`Connection: close`​ シグナルを使用して既存の接続を完了できるようにします。次に、新規要求を完全に拒否し、その間にインフライト処理を終了します。最後にタイムアウト時に残っているすべての接続を強制終了します。 シームレスなスケールダウンのシナリオがサポートされているため、トラフィックを段階的にドレーンしてアプリケーションの安定性と信頼性を維持しつつ、Mule レプリカを削減できます。 ## [](#http-接続処理の図)HTTP 接続処理の図 この図は、Mule シャットダウン時の HTTP 接続処理の動作を示しています。 ![runtime http connections diagram](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/runtime-http-connections-diagram.png) フェーズ 1: Mule の起動 - Mule の状態: Mule が起動し、通常どおりに実行されます。 - HTTP の動作: すべての受信 HTTP トラフィックが Mule にルーティングされて処理されます。特殊な処理は行われません。 推移: 停止シグナルを Mule に送信 - 停止シグナルを Mule インスタンスに送信することでシャットダウンシーケンスが開始されます。 フェーズ 2: HTTP グレースフルシャットダウン - Mule の停止 - トリガー: 停止シグナルの受信。 - 期間: 設定された HTTP グレースフルタイムアウト (デフォルト: 5 秒)。ただし、このタイムアウト期間が経過する前に既存のすべての HTTP 接続が終了した場合、HTTP グレースフルシャットダウンフェーズは早期に終了し、Mule はタイムアウト期間全体を待機することはありません。 - Mule の状態: Mule のシャットダウンが開始されるか、\[stopped (停止済み)\] に移行します。 - HTTP の動作: - 新規接続なし: HTTP サーバーは新しい受信 TCP 接続の受け入れを停止します (アクセプターソケットが閉じる)。 - 既存の要求とインフライト要求: 進行中の HTTP 要求 (すでに処理中のインフライト要求と、既存の確立された接続の要求) は引き続き通常どおり処理されます。ただし、現在の要求-応答サイクルが完了した後に接続を終了するように HTTP クライアントに通知する ​`Connection: close`​ ヘッダーがすべての応答に含まれます。 - 早期終了: 停止シグナルを受信したときにアクティブな HTTP 接続がない場合、タイムアウト期間が終了する前でも、HTTP グレースフルシャットダウンフェーズは即座に終了します。 - 遅れて到着した要求: HTTP 要求が HTTP グレースフルタイムアウトに達する直前に到着した場合、HTTP グレースフルシャットダウンタイムアウトを経過しても通常どおり処理されます。 推移: HTTP グレースフルシャットダウンタイムアウトが経過 - HTTP グレースフルシャットダウンの設定された期間が終了します。 フェーズ 3: Mule グレースフルシャットダウン - Mule の停止 - トリガー: HTTP グレースフルシャットダウンタイムアウトの終了。 - 期間: 設定された Mule グレースフルシャットダウンタイムアウト (デフォルト: 5 秒)。 - Mule の状態: Mule がグレースフルシャットダウンします。 - HTTP の動作: - 新規要求を拒否 (503): 実行時に到着する新しい HTTP 要求は、「503 Service Unavailable」 (503 サービスを利用できません) エラーで即座に拒否されます。 - 新規要求を拒否 (404): Mule アプリケーションコードで基盤となる HTTP サーバーの HTTP エンドポイントが登録解除されると、後続の新しい HTTP 要求で「404 Not Found」 (404 見つかりません) エラーが発生します。 - インフライトメッセージを完了: すでに完全に読み取られた処理中の HTTP 要求 (インフライトメッセージ) の実行を通常どおりに完了できるようになります。 推移: Mule グレースフルシャットダウンタイムアウトが経過 - Mule 全体のグレースフルシャットダウンの設定された期間が終了します。 フェーズ 4: Mule の停止 - トリガー: Mule グレースフルシャットダウンタイムアウトの終了。 - Mule の状態: Mule が停止します。 - 動作: Mule プロセスが強制シャットダウンに進み、最終的に終了します。その結果、次のようになります。 - 残りの開いているすべての HTTP 接続が突然終了します。 - 終了時のソケットの TCP 状況によって、これらの強制終了された接続に接続されているクライアントで接続リセットエラーやパイプ破損エラーが発生する可能性があります。 ## [](#シャットダウンタイムアウトの設定)シャットダウンタイムアウトの設定 HTTP グレースフルシャットダウンタイムアウトと Mule 全体のグレースフルシャットダウンタイムアウトは、シャットダウンシーケンスで異なる目的を果たしますが、Mule アプリケーションの XML ファイルの ​``​ 要素内の同じ ​`shutdownTimeout`​ パラメーターを使用して設定します。 ミリ秒 (デフォルトでは 5000 ミリ秒) 単位で値を指定します。これにより、両方のグレースフルシャットダウンの最大期間を制御します。次に例を示します。 ```xml ``` 詳細は、​[「グローバル設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.6/global-settings-configuration#global-configurations-reference)​を参照してください。 # Mule Runtime シャットダウン時の HTTP 接続処理の理解 Mule Runtime Engine (Mule) は、2 フェーズのグレースフルシャットダウンプロセス (この後に強制終了が発生) を介してシャットダウン時の HTTP 接続を管理します。 このプロセスでは、まず新規接続を拒否し、​`Connection: close`​ シグナルを使用して既存の接続を完了できるようにします。次に、新規要求を完全に拒否し、その間にインフライト処理を終了します。最後にタイムアウト時に残っているすべての接続を強制終了します。 シームレスなスケールダウンのシナリオがサポートされているため、トラフィックを段階的にドレーンしてアプリケーションの安定性と信頼性を維持しつつ、Mule レプリカを削減できます。 ## [](#http-接続処理の図)HTTP 接続処理の図 この図は、Mule シャットダウン時の HTTP 接続処理の動作を示しています。 ![runtime http connections diagram](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/runtime-http-connections-diagram.png) フェーズ 1: Mule の起動 - Mule の状態: Mule が起動し、通常どおりに実行されます。 - HTTP の動作: すべての受信 HTTP トラフィックが Mule にルーティングされて処理されます。特殊な処理は行われません。 推移: 停止シグナルを Mule に送信 - 停止シグナルを Mule インスタンスに送信することでシャットダウンシーケンスが開始されます。 フェーズ 2: HTTP グレースフルシャットダウン - Mule の停止 - トリガー: 停止シグナルの受信。 - 期間: 設定された HTTP グレースフルタイムアウト (デフォルト: 5 秒)。ただし、このタイムアウト期間が経過する前に既存のすべての HTTP 接続が終了した場合、HTTP グレースフルシャットダウンフェーズは早期に終了し、Mule はタイムアウト期間全体を待機することはありません。 - Mule の状態: Mule のシャットダウンが開始されるか、\[stopped (停止済み)\] に移行します。 - HTTP の動作: - 新規接続なし: HTTP サーバーは新しい受信 TCP 接続の受け入れを停止します (アクセプターソケットが閉じる)。 - 既存の要求とインフライト要求: 進行中の HTTP 要求 (すでに処理中のインフライト要求と、既存の確立された接続の要求) は引き続き通常どおり処理されます。ただし、現在の要求-応答サイクルが完了した後に接続を終了するように HTTP クライアントに通知する ​`Connection: close`​ ヘッダーがすべての応答に含まれます。 - 早期終了: 停止シグナルを受信したときにアクティブな HTTP 接続がない場合、タイムアウト期間が終了する前でも、HTTP グレースフルシャットダウンフェーズは即座に終了します。 - 遅れて到着した要求: HTTP 要求が HTTP グレースフルタイムアウトに達する直前に到着した場合、HTTP グレースフルシャットダウンタイムアウトを経過しても通常どおり処理されます。 推移: HTTP グレースフルシャットダウンタイムアウトが経過 - HTTP グレースフルシャットダウンの設定された期間が終了します。 フェーズ 3: Mule グレースフルシャットダウン - Mule の停止 - トリガー: HTTP グレースフルシャットダウンタイムアウトの終了。 - 期間: 設定された Mule グレースフルシャットダウンタイムアウト (デフォルト: 5 秒)。 - Mule の状態: Mule がグレースフルシャットダウンします。 - HTTP の動作: - 新規要求を拒否 (503): 実行時に到着する新しい HTTP 要求は、「503 Service Unavailable」 (503 サービスを利用できません) エラーで即座に拒否されます。 - 新規要求を拒否 (404): Mule アプリケーションコードで基盤となる HTTP サーバーの HTTP エンドポイントが登録解除されると、後続の新しい HTTP 要求で「404 Not Found」 (404 見つかりません) エラーが発生します。 - インフライトメッセージを完了: すでに完全に読み取られた処理中の HTTP 要求 (インフライトメッセージ) の実行を通常どおりに完了できるようになります。 推移: Mule グレースフルシャットダウンタイムアウトが経過 - Mule 全体のグレースフルシャットダウンの設定された期間が終了します。 フェーズ 4: Mule の停止 - トリガー: Mule グレースフルシャットダウンタイムアウトの終了。 - Mule の状態: Mule が停止します。 - 動作: Mule プロセスが強制シャットダウンに進み、最終的に終了します。その結果、次のようになります。 - 残りの開いているすべての HTTP 接続が突然終了します。 - 終了時のソケットの TCP 状況によって、これらの強制終了された接続に接続されているクライアントで接続リセットエラーやパイプ破損エラーが発生する可能性があります。 ## [](#シャットダウンタイムアウトの設定)シャットダウンタイムアウトの設定 HTTP グレースフルシャットダウンタイムアウトと Mule 全体のグレースフルシャットダウンタイムアウトは、シャットダウンシーケンスで異なる目的を果たしますが、Mule アプリケーションの XML ファイルの ​``​ 要素内の同じ ​`shutdownTimeout`​ パラメーターを使用して設定します。 ミリ秒 (デフォルトでは 5000 ミリ秒) 単位で値を指定します。これにより、両方のグレースフルシャットダウンの最大期間を制御します。次に例を示します。 ```xml ``` 詳細は、​[「グローバル設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.7/global-settings-configuration#global-configurations-reference)​を参照してください。 # Mule Runtime シャットダウン時の HTTP 接続処理の理解 Mule Runtime Engine (Mule) は、2 フェーズのグレースフルシャットダウンプロセス (この後に強制終了が発生) を介してシャットダウン時の HTTP 接続を管理します。 このプロセスでは、まず新規接続を拒否し、​`Connection: close`​ シグナルを使用して既存の接続を完了できるようにします。次に、新規要求を完全に拒否し、その間にインフライト処理を終了します。最後にタイムアウト時に残っているすべての接続を強制終了します。 シームレスなスケールダウンのシナリオがサポートされているため、トラフィックを段階的にドレーンしてアプリケーションの安定性と信頼性を維持しつつ、Mule レプリカを削減できます。 ## [](#http-接続処理の図)HTTP 接続処理の図 この図は、Mule シャットダウン時の HTTP 接続処理の動作を示しています。 ![runtime http connections diagram](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/runtime-http-connections-diagram.png) フェーズ 1: Mule の起動 - Mule の状態: Mule が起動し、通常どおりに実行されます。 - HTTP の動作: すべての受信 HTTP トラフィックが Mule にルーティングされて処理されます。特殊な処理は行われません。 推移: 停止シグナルを Mule に送信 - 停止シグナルを Mule インスタンスに送信することでシャットダウンシーケンスが開始されます。 フェーズ 2: HTTP グレースフルシャットダウン - Mule の停止 - トリガー: 停止シグナルの受信。 - 期間: 設定された HTTP グレースフルタイムアウト (デフォルト: 5 秒)。ただし、このタイムアウト期間が経過する前に既存のすべての HTTP 接続が終了した場合、HTTP グレースフルシャットダウンフェーズは早期に終了し、Mule はタイムアウト期間全体を待機することはありません。 - Mule の状態: Mule のシャットダウンが開始されるか、\[stopped (停止済み)\] に移行します。 - HTTP の動作: - 新規接続なし: HTTP サーバーは新しい受信 TCP 接続の受け入れを停止します (アクセプターソケットが閉じる)。 - 既存の要求とインフライト要求: 進行中の HTTP 要求 (すでに処理中のインフライト要求と、既存の確立された接続の要求) は引き続き通常どおり処理されます。ただし、現在の要求-応答サイクルが完了した後に接続を終了するように HTTP クライアントに通知する ​`Connection: close`​ ヘッダーがすべての応答に含まれます。 - 早期終了: 停止シグナルを受信したときにアクティブな HTTP 接続がない場合、タイムアウト期間が終了する前でも、HTTP グレースフルシャットダウンフェーズは即座に終了します。 - 遅れて到着した要求: HTTP 要求が HTTP グレースフルタイムアウトに達する直前に到着した場合、HTTP グレースフルシャットダウンタイムアウトを経過しても通常どおり処理されます。 推移: HTTP グレースフルシャットダウンタイムアウトが経過 - HTTP グレースフルシャットダウンの設定された期間が終了します。 フェーズ 3: Mule グレースフルシャットダウン - Mule の停止 - トリガー: HTTP グレースフルシャットダウンタイムアウトの終了。 - 期間: 設定された Mule グレースフルシャットダウンタイムアウト (デフォルト: 5 秒)。 - Mule の状態: Mule がグレースフルシャットダウンします。 - HTTP の動作: - 新規要求を拒否 (503): 実行時に到着する新しい HTTP 要求は、「503 Service Unavailable」 (503 サービスを利用できません) エラーで即座に拒否されます。 - 新規要求を拒否 (404): Mule アプリケーションコードで基盤となる HTTP サーバーの HTTP エンドポイントが登録解除されると、後続の新しい HTTP 要求で「404 Not Found」 (404 見つかりません) エラーが発生します。 - インフライトメッセージを完了: すでに完全に読み取られた処理中の HTTP 要求 (インフライトメッセージ) の実行を通常どおりに完了できるようになります。 推移: Mule グレースフルシャットダウンタイムアウトが経過 - Mule 全体のグレースフルシャットダウンの設定された期間が終了します。 フェーズ 4: Mule の停止 - トリガー: Mule グレースフルシャットダウンタイムアウトの終了。 - Mule の状態: Mule が停止します。 - 動作: Mule プロセスが強制シャットダウンに進み、最終的に終了します。その結果、次のようになります。 - 残りの開いているすべての HTTP 接続が突然終了します。 - 終了時のソケットの TCP 状況によって、これらの強制終了された接続に接続されているクライアントで接続リセットエラーやパイプ破損エラーが発生する可能性があります。 ## [](#シャットダウンタイムアウトの設定)シャットダウンタイムアウトの設定 HTTP グレースフルシャットダウンタイムアウトと Mule 全体のグレースフルシャットダウンタイムアウトは、シャットダウンシーケンスで異なる目的を果たしますが、Mule アプリケーションの XML ファイルの ​``​ 要素内の同じ ​`shutdownTimeout`​ パラメーターを使用して設定します。 ミリ秒 (デフォルトでは 5000 ミリ秒) 単位で値を指定します。これにより、両方のグレースフルシャットダウンの最大期間を制御します。次に例を示します。 ```xml ``` 詳細は、​[「グローバル設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.8/global-settings-configuration#global-configurations-reference)​を参照してください。 # Mule Runtime シャットダウン時の HTTP 接続処理の理解 Mule Runtime Engine (Mule) は、2 フェーズのグレースフルシャットダウンプロセス (この後に強制終了が発生) を介してシャットダウン時の HTTP 接続を管理します。 このプロセスでは、まず新規接続を拒否し、​`Connection: close`​ シグナルを使用して既存の接続を完了できるようにします。次に、新規要求を完全に拒否し、その間にインフライト処理を終了します。最後にタイムアウト時に残っているすべての接続を強制終了します。 シームレスなスケールダウンのシナリオがサポートされているため、トラフィックを段階的にドレーンしてアプリケーションの安定性と信頼性を維持しつつ、Mule レプリカを削減できます。 ## [](#http-接続処理の図)HTTP 接続処理の図 この図は、Mule シャットダウン時の HTTP 接続処理の動作を示しています。 ![runtime http connections diagram](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/runtime-http-connections-diagram.png) フェーズ 1: Mule の起動 - Mule の状態: Mule が起動し、通常どおりに実行されます。 - HTTP の動作: すべての受信 HTTP トラフィックが Mule にルーティングされて処理されます。特殊な処理は行われません。 推移: 停止シグナルを Mule に送信 - 停止シグナルを Mule インスタンスに送信することでシャットダウンシーケンスが開始されます。 フェーズ 2: HTTP グレースフルシャットダウン - Mule の停止 - トリガー: 停止シグナルの受信。 - 期間: 設定された HTTP グレースフルタイムアウト (デフォルト: 5 秒)。ただし、このタイムアウト期間が経過する前に既存のすべての HTTP 接続が終了した場合、HTTP グレースフルシャットダウンフェーズは早期に終了し、Mule はタイムアウト期間全体を待機することはありません。 - Mule の状態: Mule のシャットダウンが開始されるか、\[stopped (停止済み)\] に移行します。 - HTTP の動作: - 新規接続なし: HTTP サーバーは新しい受信 TCP 接続の受け入れを停止します (アクセプターソケットが閉じる)。 - 既存の要求とインフライト要求: 進行中の HTTP 要求 (すでに処理中のインフライト要求と、既存の確立された接続の要求) は引き続き通常どおり処理されます。ただし、現在の要求-応答サイクルが完了した後に接続を終了するように HTTP クライアントに通知する ​`Connection: close`​ ヘッダーがすべての応答に含まれます。 - 早期終了: 停止シグナルを受信したときにアクティブな HTTP 接続がない場合、タイムアウト期間が終了する前でも、HTTP グレースフルシャットダウンフェーズは即座に終了します。 - 遅れて到着した要求: HTTP 要求が HTTP グレースフルタイムアウトに達する直前に到着した場合、HTTP グレースフルシャットダウンタイムアウトを経過しても通常どおり処理されます。 推移: HTTP グレースフルシャットダウンタイムアウトが経過 - HTTP グレースフルシャットダウンの設定された期間が終了します。 フェーズ 3: Mule グレースフルシャットダウン - Mule の停止 - トリガー: HTTP グレースフルシャットダウンタイムアウトの終了。 - 期間: 設定された Mule グレースフルシャットダウンタイムアウト (デフォルト: 5 秒)。 - Mule の状態: Mule がグレースフルシャットダウンします。 - HTTP の動作: - 新規要求を拒否 (503): 実行時に到着する新しい HTTP 要求は、「503 Service Unavailable」 (503 サービスを利用できません) エラーで即座に拒否されます。 - 新規要求を拒否 (404): Mule アプリケーションコードで基盤となる HTTP サーバーの HTTP エンドポイントが登録解除されると、後続の新しい HTTP 要求で「404 Not Found」 (404 見つかりません) エラーが発生します。 - インフライトメッセージを完了: すでに完全に読み取られた処理中の HTTP 要求 (インフライトメッセージ) の実行を通常どおりに完了できるようになります。 推移: Mule グレースフルシャットダウンタイムアウトが経過 - Mule 全体のグレースフルシャットダウンの設定された期間が終了します。 フェーズ 4: Mule の停止 - トリガー: Mule グレースフルシャットダウンタイムアウトの終了。 - Mule の状態: Mule が停止します。 - 動作: Mule プロセスが強制シャットダウンに進み、最終的に終了します。その結果、次のようになります。 - 残りの開いているすべての HTTP 接続が突然終了します。 - 終了時のソケットの TCP 状況によって、これらの強制終了された接続に接続されているクライアントで接続リセットエラーやパイプ破損エラーが発生する可能性があります。 ## [](#シャットダウンタイムアウトの設定)シャットダウンタイムアウトの設定 HTTP グレースフルシャットダウンタイムアウトと Mule 全体のグレースフルシャットダウンタイムアウトは、シャットダウンシーケンスで異なる目的を果たしますが、Mule アプリケーションの XML ファイルの ​``​ 要素内の同じ ​`shutdownTimeout`​ パラメーターを使用して設定します。 ミリ秒 (デフォルトでは 5000 ミリ秒) 単位で値を指定します。これにより、両方のグレースフルシャットダウンの最大期間を制御します。次に例を示します。 ```xml ``` 詳細は、​[「グローバル設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.9/global-settings-configuration#global-configurations-reference)​を参照してください。 # Mule Runtime での OpenTelemetry のサポート OpenTelemetry は、仕様、API、SDK で構成されるオブザーバビリティ標準です。テレメトリーデータ (メトリクス、ログ、トレースなど) を計測、生成、収集、エクスポートしてソフトウェアの動作を分析するのに役立ちます。 OpenTelemetry を使用すると、Mule Runtime Engine で Mule アプリケーションの動作に関するオブザーバビリティを提供できます。また、分散トレースを使用すると、Mule でこの標準を活用する Mule アプリケーションと非 Mule コンポーネント間のインタラクションに関するオブザーバビリティを提供できます。 Mule では、OpenTelemetry 分散トレースの生成およびエクスポートがサポートされています。ただし、メトリクスとログはまだ OpenTelemetry でサポートされていません。 ## [](#始める前に)始める前に OpenTelemetry Mule 機能を使用するには、以下に精通している必要があります。 - 分散トレースの概念 (トレースやスパンなど)。 分散トレースや OpenTelemetry を初めて使用する場合、 [「OpenTelemetry とは」](https://opentelemetry.io/docs/concepts/what-is-opentelemetry/)​および [「分散トレースを理解する」](https://opentelemetry.io/docs/concepts/observability-primer/#understanding-distributed-tracing)​から始めることをお勧めします。 - [テレメトリーデータをサードパーティ監視システムにエクスポートする方法](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter)​。 オブザーバビリティ標準で開始するには、以下が必要です。 - Mule Runtime 4.6.0 以降 (フロートレースの場合)。 - HTTP 用 Anypoint Connector (HTTP Connector) 1.8 (分散トレースの場合)。 - 設定済みの Telemetry Exporter。 ## [](#mule-アプリケーションのトレース)Mule アプリケーションのトレース Mule は OpenTelemetry を利用して、以下を提供します。 - アプリケーション実行オブザーバビリティ オブザーバビリティには、アプリケーションの各コンポーネントの動作が含まれます。Mule アプリケーションに関連するメインスパンはフロースパンです。メッセージ処理に関連する各 Mule コンポーネント実行は、対応するフローの子スパンとして表されます。 - 分散トレース トレースにより、Mule アプリケーションのインタラクションを追跡できます。複数のシステムおよびサービスが関連する場合、分散トレースで分散環境に流れるアプリケーション要求を追跡し、アプリケーションの実行の包括的なビューを提供します。 たとえば、HTTP Listener で [W3C トレースコンテキスト](https://www.w3.org/TR/trace-context/)​ヘッダーを受信する場合、Mule のフロースパンでクライアントのリモート親スパン (HTTP コールの発生元のスパン) を取得します。HTTP Requester コンポーネントを使用している場合、Mule は自動的に現在のスパンをサーバーエンドポイントに伝播します。 コンテキストの受信および伝播でサポートされているスパンコンテキスト形式は、 [W3C トレースコンテキスト](https://www.w3.org/TR/trace-context/)​形式です。 ### [](#mule-スパンデータ)Mule スパンデータ トレースは、分散システムの完全な操作を表す一連のスパンです。スパンは、ネストされることがあり、作業または操作の単位を表します。各スパンには、以下が含まれます。
カテゴリ 説明 値の例

Name (名前)

スパンの名前

mule:set-variable

Parent Span ID (親スパン ID)

現在のスパンの親のスパン ID

86838830d494d679

Start and End Timestamps (開始および終了タイムスタンプ)

スパンの最も早いおよび最も遅いタイムスタンプ

2021-10-22 16:04:01.209458162 +0000 UTC

Span Context (スパンコンテキスト)

スパンを一意に識別するデータ: トレース ID、スパン ID、トレースフラグ、トレース状態

Attributes (属性)

メタデータが含まれるキー-値ペア。このメタデータを使用してアノテーションをスパンに付加し、追跡対象の操作に関する情報を伝えます。

{ “location”: “flow/processors/2”, “correlation.id”: “1234abcd” }

Span Events (スパンイベント)

スパンの期間中の意味のある一意の時点を示すために使用される、スパンの構造化されたログメッセージまたはアノテーション。

{ "name": "", "message": "OK", "timestamp": "2021-10-22 16:04:01.209512872 +0000 UTC" }

Span Links (スパンリンク)

あるスパンを 1 つ以上の他のスパンに関連付けるリンク (因果関係を示す)。

Span Status (スパン状況)

スパンに関連付けられた状況。アプリケーションコードで例外などの不明なエラーが発生したときのスパン状況を設定できます。

ERROR​、​OK​、​UNSET

Span Kind (スパンの種類)

トレースの編成方法に関する情報。

CLIENT​、​INTERNAL​、​PRODUCER
### [](#フロートレース機能の例)フロートレース機能の例 フロー実行をトレースする場合、メッセージの処理に関連する各 Mule コンポーネント実行はスパンとして表されます。コンポーネントスパンは、実行の関連する側面を表します。Set Payload などのシンプルなコンポーネントでは 1 つのスパンですが、Batch Job などではより複雑な構造になります。 バッチインスタンス Mule Runtime は Batch Job などの複雑なコンポーネントを追跡します。 ![Listener および Set Payload コンポーネントが含まれるより複雑な構造のバッチフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/otel-batch-instance.png) 生成されるスパン トレースは、Batch Job の最初のステップでどのように各バッチレコードが処理されるのかを表示します。各レコードスパンには、Logger コンポーネントで実行される作業の単位を表す子スパンが含まれます。 次に、For Each コンポーネントおよびその内部のプロセッサー (Transform Message や Logger など) と共に Batch Aggregator スパンを表示します。 その後、他の 2 つのバッチステップとそれぞれのコンポーネントを表示します。 最後に、フローの Batch Job の後に表示される Logger コンポーネントと共に Batch On Complete スパンを表示します。 ### [](#分散トレース機能の例)分散トレース機能の例 次の例では、ある Mule アプリケーションが別の Mule アプリケーションに要求を送信しています。 ![HTTP アプリケーションの Listener、Logger、Request コンポーネントが含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/otel-mule-app1.png) ![非同期アプリケーションのプロセスフローが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/otel-mule-app2.png) Mule および HTTP Connector で OpenTelemetry が計測されるため、分散トレースでは、同じトレースの一部として両方のフローが取得されます。 ### [](#トレースのエラー)トレースのエラー スパンで表される実行作業単位でエラーが発生すると、スパンの状況が ​`[Error (エラー)]`​ に設定されます。MuleSoft は、1 つ以上の​`例外`​イベントをスパンに追加する OpenTelemetry によって定義されるセマンティック規則に準拠します。 - `exception.type`​: Mule エラー種別 - `exception.message`​: Mule エラーメッセージ - `exception.stacktrace`​: Mule フロースタックの文字列表現 次の例では、エラーが発生したときに、Raise error コンポーネントに対応するスパンで Lightstep プラットフォームのエラー状況が表示されます。 ![エラー処理が含まれるテレメトリーフローのフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/otel-errors-in-tracing.png) この状況は、親スパン (フロースパンなど) に伝播します。スパンの詳細ビューにエラー状況と例外イベントが表示されます。 ### [](#http-規則)HTTP 規則 HTTP Listener および HTTP Request 操作により、スパンに属性が追加され、HTTP インタラクションをトレースするためのより多くのコンテキストが提供されます。 HTTP Listener が含まれるフローでは以下のようになります。 - Span name (スパン名): HTTP メソッドとパスの組み合わせ。例: `POST /api`​。 - Span kind (スパンの種類): `SERVER`​。 フロースパンに関連付けられた HTTP Listener の追加属性:
属性 説明

net.host.name

HTTP Listener のホストアドレス

net.host.port

HTTP Listener のポート

http.user_agent

受信した要求のユーザーエージェント

http.route

HTTP Listener のパス

http.method

HTTP メソッド

http.flavor

HTTP バージョン
HTTP Request が含まれるフローでは以下のようになります。 - Span name (スパン名): HTTP メソッド。例: `GET`​。 - Span kind (スパンの種類): `CLIENT`​。 フロースパンに関連付けられた HTTP Request の追加属性:
属性 説明

http.url

対象 URL

net.host.port

HTTP Request のポート

net.peer.name

対象 IP アドレス

http.route

HTTP Request のパス

http.flavor

HTTP バージョン
## [](#関連情報)関連情報 - [サードパーティ監視システムへのテレメトリーデータのエクスポート](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter) # Mule Runtime での OpenTelemetry のサポート OpenTelemetry は、仕様、API、SDK で構成されるオブザーバビリティ標準です。テレメトリーデータ (メトリクス、ログ、トレースなど) を計測、生成、収集、エクスポートしてソフトウェアの動作を分析するのに役立ちます。 OpenTelemetry を使用すると、Mule Runtime Engine で Mule アプリケーションの動作に関するオブザーバビリティを提供できます。また、分散トレースを使用すると、Mule でこの標準を活用する Mule アプリケーションと非 Mule コンポーネント間のインタラクションに関するオブザーバビリティを提供できます。 Mule では、OpenTelemetry 分散トレースの生成およびエクスポートがサポートされています。ただし、メトリクスとログはまだ OpenTelemetry でサポートされていません。 ## [](#始める前に)始める前に OpenTelemetry Mule 機能を使用するには、以下に精通している必要があります。 - 分散トレースの概念 (トレースやスパンなど)。 分散トレースや OpenTelemetry を初めて使用する場合、 [「OpenTelemetry とは」](https://opentelemetry.io/docs/concepts/what-is-opentelemetry/)​および [「分散トレースを理解する」](https://opentelemetry.io/docs/concepts/observability-primer/#understanding-distributed-tracing)​から始めることをお勧めします。 - [テレメトリーデータをサードパーティ監視システムにエクスポートする方法](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter)​。 オブザーバビリティ標準で開始するには、以下が必要です。 - Mule Runtime 4.6.0 以降 (フロートレースの場合)。 - HTTP 用 Anypoint Connector (HTTP Connector) 1.8 (分散トレースの場合)。 - 設定済みの Telemetry Exporter。 ## [](#mule-アプリケーションのトレース)Mule アプリケーションのトレース Mule は OpenTelemetry を利用して、以下を提供します。 - アプリケーション実行オブザーバビリティ オブザーバビリティには、アプリケーションの各コンポーネントの動作が含まれます。Mule アプリケーションに関連するメインスパンはフロースパンです。メッセージ処理に関連する各 Mule コンポーネント実行は、対応するフローの子スパンとして表されます。 - 分散トレース トレースにより、Mule アプリケーションのインタラクションを追跡できます。複数のシステムおよびサービスが関連する場合、分散トレースで分散環境に流れるアプリケーション要求を追跡し、アプリケーションの実行の包括的なビューを提供します。 たとえば、HTTP Listener で [W3C トレースコンテキスト](https://www.w3.org/TR/trace-context/)​ヘッダーを受信する場合、Mule のフロースパンでクライアントのリモート親スパン (HTTP コールの発生元のスパン) を取得します。HTTP Requester コンポーネントを使用している場合、Mule は自動的に現在のスパンをサーバーエンドポイントに伝播します。 コンテキストの受信および伝播でサポートされているスパンコンテキスト形式は、 [W3C トレースコンテキスト](https://www.w3.org/TR/trace-context/)​形式です。 ### [](#mule-スパンデータ)Mule スパンデータ トレースは、分散システムの完全な操作を表す一連のスパンです。スパンは、ネストされることがあり、作業または操作の単位を表します。各スパンには、以下が含まれます。
カテゴリ 説明 値の例

Name (名前)

スパンの名前

mule:set-variable

Parent Span ID (親スパン ID)

現在のスパンの親のスパン ID

86838830d494d679

Start and End Timestamps (開始および終了タイムスタンプ)

スパンの最も早いおよび最も遅いタイムスタンプ

2021-10-22 16:04:01.209458162 +0000 UTC

Span Context (スパンコンテキスト)

スパンを一意に識別するデータ: トレース ID、スパン ID、トレースフラグ、トレース状態

Attributes (属性)

メタデータが含まれるキー-値ペア。このメタデータを使用してアノテーションをスパンに付加し、追跡対象の操作に関する情報を伝えます。

{ “location”: “flow/processors/2”, “correlation.id”: “1234abcd” }

Span Events (スパンイベント)

スパンの期間中の意味のある一意の時点を示すために使用される、スパンの構造化されたログメッセージまたはアノテーション。

{ "name": "", "message": "OK", "timestamp": "2021-10-22 16:04:01.209512872 +0000 UTC" }

Span Links (スパンリンク)

あるスパンを 1 つ以上の他のスパンに関連付けるリンク (因果関係を示す)。

Span Status (スパン状況)

スパンに関連付けられた状況。アプリケーションコードで例外などの不明なエラーが発生したときのスパン状況を設定できます。

ERROR​、​OK​、​UNSET

Span Kind (スパンの種類)

トレースの編成方法に関する情報。

CLIENT​、​INTERNAL​、​PRODUCER
### [](#フロートレース機能の例)フロートレース機能の例 フロー実行をトレースする場合、メッセージの処理に関連する各 Mule コンポーネント実行はスパンとして表されます。コンポーネントスパンは、実行の関連する側面を表します。Set Payload などのシンプルなコンポーネントでは 1 つのスパンですが、Batch Job などではより複雑な構造になります。 バッチインスタンス Mule Runtime は Batch Job などの複雑なコンポーネントを追跡します。 ![Listener および Set Payload コンポーネントが含まれるより複雑な構造のバッチフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/otel-batch-instance.png) 生成されるスパン トレースは、Batch Job の最初のステップでどのように各バッチレコードが処理されるのかを表示します。各レコードスパンには、Logger コンポーネントで実行される作業の単位を表す子スパンが含まれます。 次に、For Each コンポーネントおよびその内部のプロセッサー (Transform Message や Logger など) と共に Batch Aggregator スパンを表示します。 その後、他の 2 つのバッチステップとそれぞれのコンポーネントを表示します。 最後に、フローの Batch Job の後に表示される Logger コンポーネントと共に Batch On Complete スパンを表示します。 ### [](#分散トレース機能の例)分散トレース機能の例 次の例では、ある Mule アプリケーションが別の Mule アプリケーションに要求を送信しています。 ![HTTP アプリケーションの Listener、Logger、Request コンポーネントが含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/otel-mule-app1.png) ![非同期アプリケーションのプロセスフローが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/otel-mule-app2.png) Mule および HTTP Connector で OpenTelemetry が計測されるため、分散トレースでは、同じトレースの一部として両方のフローが取得されます。 ### [](#トレースのエラー)トレースのエラー スパンで表される実行作業単位でエラーが発生すると、スパンの状況が ​`[Error (エラー)]`​ に設定されます。MuleSoft は、1 つ以上の​`例外`​イベントをスパンに追加する OpenTelemetry によって定義されるセマンティック規則に準拠します。 - `exception.type`​: Mule エラー種別 - `exception.message`​: Mule エラーメッセージ - `exception.stacktrace`​: Mule フロースタックの文字列表現 次の例では、エラーが発生したときに、Raise error コンポーネントに対応するスパンで Lightstep プラットフォームのエラー状況が表示されます。 ![エラー処理が含まれるテレメトリーフローのフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/otel-errors-in-tracing.png) この状況は、親スパン (フロースパンなど) に伝播します。スパンの詳細ビューにエラー状況と例外イベントが表示されます。 ### [](#http-規則)HTTP 規則 HTTP Listener および HTTP Request 操作により、スパンに属性が追加され、HTTP インタラクションをトレースするためのより多くのコンテキストが提供されます。 HTTP Listener が含まれるフローでは以下のようになります。 - Span name (スパン名): HTTP メソッドとパスの組み合わせ。例: `POST /api`​。 - Span kind (スパンの種類): `SERVER`​。 フロースパンに関連付けられた HTTP Listener の追加属性:
属性 説明

net.host.name

HTTP Listener のホストアドレス

net.host.port

HTTP Listener のポート

http.user_agent

受信した要求のユーザーエージェント

http.route

HTTP Listener のパス

http.method

HTTP メソッド

http.flavor

HTTP バージョン
HTTP Request が含まれるフローでは以下のようになります。 - Span name (スパン名): HTTP メソッド。例: `GET`​。 - Span kind (スパンの種類): `CLIENT`​。 フロースパンに関連付けられた HTTP Request の追加属性:
属性 説明

http.url

対象 URL

net.host.port

HTTP Request のポート

net.peer.name

対象 IP アドレス

http.route

HTTP Request のパス

http.flavor

HTTP バージョン
## [](#関連情報)関連情報 - [サードパーティ監視システムへのテレメトリーデータのエクスポート](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter) # Mule Runtime での OpenTelemetry のサポート OpenTelemetry は、仕様、API、SDK で構成されるオブザーバビリティ標準です。テレメトリーデータ (メトリクス、ログ、トレースなど) を計測、生成、収集、エクスポートしてソフトウェアの動作を分析するのに役立ちます。 OpenTelemetry を使用すると、Mule Runtime Engine で Mule アプリケーションの動作に関するオブザーバビリティを提供できます。また、分散トレースを使用すると、Mule でこの標準を活用する Mule アプリケーションと非 Mule コンポーネント間のインタラクションに関するオブザーバビリティを提供できます。 Mule では、OpenTelemetry 分散トレースの生成およびエクスポートがサポートされています。ただし、メトリクスとログはまだ OpenTelemetry でサポートされていません。 ## [](#始める前に)始める前に OpenTelemetry Mule 機能を使用するには、以下に精通している必要があります。 - 分散トレースの概念 (トレースやスパンなど)。 分散トレースや OpenTelemetry を初めて使用する場合、 [「OpenTelemetry とは」](https://opentelemetry.io/docs/concepts/what-is-opentelemetry/)​および [「分散トレースを理解する」](https://opentelemetry.io/docs/concepts/observability-primer/#understanding-distributed-tracing)​から始めることをお勧めします。 - [テレメトリーデータをサードパーティ監視システムにエクスポートする方法](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter)​。 オブザーバビリティ標準で開始するには、以下が必要です。 - Mule Runtime 4.6.0 以降 (フロートレースの場合)。 - HTTP 用 Anypoint Connector (HTTP Connector) 1.8 (分散トレースの場合)。 - 設定済みの Telemetry Exporter。 ## [](#mule-アプリケーションのトレース)Mule アプリケーションのトレース Mule は OpenTelemetry を利用して、以下を提供します。 - アプリケーション実行オブザーバビリティ オブザーバビリティには、アプリケーションの各コンポーネントの動作が含まれます。Mule アプリケーションに関連するメインスパンはフロースパンです。メッセージ処理に関連する各 Mule コンポーネント実行は、対応するフローの子スパンとして表されます。 - 分散トレース トレースにより、Mule アプリケーションのインタラクションを追跡できます。複数のシステムおよびサービスが関連する場合、分散トレースで分散環境に流れるアプリケーション要求を追跡し、アプリケーションの実行の包括的なビューを提供します。 たとえば、HTTP Listener で [W3C トレースコンテキスト](https://www.w3.org/TR/trace-context/)​ヘッダーを受信する場合、Mule のフロースパンでクライアントのリモート親スパン (HTTP コールの発生元のスパン) を取得します。HTTP Requester コンポーネントを使用している場合、Mule は自動的に現在のスパンをサーバーエンドポイントに伝播します。 コンテキストの受信および伝播でサポートされているスパンコンテキスト形式は、 [W3C トレースコンテキスト](https://www.w3.org/TR/trace-context/)​形式です。 ### [](#mule-スパンデータ)Mule スパンデータ トレースは、分散システムの完全な操作を表す一連のスパンです。スパンは、ネストされることがあり、作業または操作の単位を表します。各スパンには、以下が含まれます。
カテゴリ 説明 値の例

Name (名前)

スパンの名前

mule:set-variable

Parent Span ID (親スパン ID)

現在のスパンの親のスパン ID

86838830d494d679

Start and End Timestamps (開始および終了タイムスタンプ)

スパンの最も早いおよび最も遅いタイムスタンプ

2021-10-22 16:04:01.209458162 +0000 UTC

Span Context (スパンコンテキスト)

スパンを一意に識別するデータ: トレース ID、スパン ID、トレースフラグ、トレース状態

Attributes (属性)

メタデータが含まれるキー-値ペア。このメタデータを使用してアノテーションをスパンに付加し、追跡対象の操作に関する情報を伝えます。

{ “location”: “flow/processors/2”, “correlation.id”: “1234abcd” }

Span Events (スパンイベント)

スパンの期間中の意味のある一意の時点を示すために使用される、スパンの構造化されたログメッセージまたはアノテーション。

{ "name": "", "message": "OK", "timestamp": "2021-10-22 16:04:01.209512872 +0000 UTC" }

Span Links (スパンリンク)

あるスパンを 1 つ以上の他のスパンに関連付けるリンク (因果関係を示す)。

Span Status (スパン状況)

スパンに関連付けられた状況。アプリケーションコードで例外などの不明なエラーが発生したときのスパン状況を設定できます。

ERROR​、​OK​、​UNSET

Span Kind (スパンの種類)

トレースの編成方法に関する情報。

CLIENT​、​INTERNAL​、​PRODUCER
### [](#フロートレース機能の例)フロートレース機能の例 フロー実行をトレースする場合、メッセージの処理に関連する各 Mule コンポーネント実行はスパンとして表されます。コンポーネントスパンは、実行の関連する側面を表します。Set Payload などのシンプルなコンポーネントでは 1 つのスパンですが、Batch Job などではより複雑な構造になります。 バッチインスタンス Mule Runtime は Batch Job などの複雑なコンポーネントを追跡します。 ![Listener および Set Payload コンポーネントが含まれるより複雑な構造のバッチフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/otel-batch-instance.png) 生成されるスパン トレースは、Batch Job の最初のステップでどのように各バッチレコードが処理されるのかを表示します。各レコードスパンには、Logger コンポーネントで実行される作業の単位を表す子スパンが含まれます。 次に、For Each コンポーネントおよびその内部のプロセッサー (Transform Message や Logger など) と共に Batch Aggregator スパンを表示します。 その後、他の 2 つのバッチステップとそれぞれのコンポーネントを表示します。 最後に、フローの Batch Job の後に表示される Logger コンポーネントと共に Batch On Complete スパンを表示します。 ### [](#分散トレース機能の例)分散トレース機能の例 次の例では、ある Mule アプリケーションが別の Mule アプリケーションに要求を送信しています。 ![HTTP アプリケーションの Listener、Logger、Request コンポーネントが含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/otel-mule-app1.png) ![非同期アプリケーションのプロセスフローが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/otel-mule-app2.png) Mule および HTTP Connector で OpenTelemetry が計測されるため、分散トレースでは、同じトレースの一部として両方のフローが取得されます。 ### [](#トレースのエラー)トレースのエラー スパンで表される実行作業単位でエラーが発生すると、スパンの状況が ​`[Error (エラー)]`​ に設定されます。MuleSoft は、1 つ以上の​`例外`​イベントをスパンに追加する OpenTelemetry によって定義されるセマンティック規則に準拠します。 - `exception.type`​: Mule エラー種別 - `exception.message`​: Mule エラーメッセージ - `exception.stacktrace`​: Mule フロースタックの文字列表現 次の例では、エラーが発生したときに、Raise error コンポーネントに対応するスパンで Lightstep プラットフォームのエラー状況が表示されます。 ![エラー処理が含まれるテレメトリーフローのフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/otel-errors-in-tracing.png) この状況は、親スパン (フロースパンなど) に伝播します。スパンの詳細ビューにエラー状況と例外イベントが表示されます。 ### [](#http-規則)HTTP 規則 HTTP Listener および HTTP Request 操作により、スパンに属性が追加され、HTTP インタラクションをトレースするためのより多くのコンテキストが提供されます。 HTTP Listener が含まれるフローでは以下のようになります。 - Span name (スパン名): HTTP メソッドとパスの組み合わせ。例: `POST /api`​。 - Span kind (スパンの種類): `SERVER`​。 フロースパンに関連付けられた HTTP Listener の追加属性:
属性 説明

net.host.name

HTTP Listener のホストアドレス

net.host.port

HTTP Listener のポート

http.user_agent

受信した要求のユーザーエージェント

http.route

HTTP Listener のパス

http.method

HTTP メソッド

http.flavor

HTTP バージョン
HTTP Request が含まれるフローでは以下のようになります。 - Span name (スパン名): HTTP メソッド。例: `GET`​。 - Span kind (スパンの種類): `CLIENT`​。 フロースパンに関連付けられた HTTP Request の追加属性:
属性 説明

http.url

対象 URL

net.host.port

HTTP Request のポート

net.peer.name

対象 IP アドレス

http.route

HTTP Request のパス

http.flavor

HTTP バージョン
## [](#関連情報)関連情報 - [サードパーティ監視システムへのテレメトリーデータのエクスポート](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter) # Mule Runtime での OpenTelemetry のサポート OpenTelemetry は、仕様、API、SDK で構成されるオブザーバビリティ標準です。テレメトリーデータ (メトリクス、ログ、トレースなど) を計測、生成、収集、エクスポートしてソフトウェアの動作を分析するのに役立ちます。 OpenTelemetry を使用すると、Mule Runtime Engine で Mule アプリケーションの動作に関するオブザーバビリティを提供できます。また、分散トレースを使用すると、Mule でこの標準を活用する Mule アプリケーションと非 Mule コンポーネント間のインタラクションに関するオブザーバビリティを提供できます。 Mule では、OpenTelemetry 分散トレースの生成およびエクスポートがサポートされています。ただし、メトリクスとログはまだ OpenTelemetry でサポートされていません。 ## [](#始める前に)始める前に OpenTelemetry Mule 機能を使用するには、以下に精通している必要があります。 - 分散トレースの概念 (トレースやスパンなど)。 分散トレースや OpenTelemetry を初めて使用する場合、 [「OpenTelemetry とは」](https://opentelemetry.io/docs/concepts/what-is-opentelemetry/)​および [「分散トレースを理解する」](https://opentelemetry.io/docs/concepts/observability-primer/#understanding-distributed-tracing)​から始めることをお勧めします。 - [テレメトリーデータをサードパーティ監視システムにエクスポートする方法](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter)​。 オブザーバビリティ標準で開始するには、以下が必要です。 - Mule Runtime 4.6.0 以降 (フロートレースの場合)。 - HTTP 用 Anypoint Connector (HTTP Connector) 1.8 (分散トレースの場合)。 - 設定済みの Telemetry Exporter。 ## [](#mule-アプリケーションのトレース)Mule アプリケーションのトレース Mule は OpenTelemetry を利用して、以下を提供します。 - アプリケーション実行オブザーバビリティ オブザーバビリティには、アプリケーションの各コンポーネントの動作が含まれます。Mule アプリケーションに関連するメインスパンはフロースパンです。メッセージ処理に関連する各 Mule コンポーネント実行は、対応するフローの子スパンとして表されます。 - 分散トレース トレースにより、Mule アプリケーションのインタラクションを追跡できます。複数のシステムおよびサービスが関連する場合、分散トレースで分散環境に流れるアプリケーション要求を追跡し、アプリケーションの実行の包括的なビューを提供します。 たとえば、HTTP Listener で [W3C トレースコンテキスト](https://www.w3.org/TR/trace-context/)​ヘッダーを受信する場合、Mule のフロースパンでクライアントのリモート親スパン (HTTP コールの発生元のスパン) を取得します。HTTP Requester コンポーネントを使用している場合、Mule は自動的に現在のスパンをサーバーエンドポイントに伝播します。 コンテキストの受信および伝播でサポートされているスパンコンテキスト形式は、 [W3C トレースコンテキスト](https://www.w3.org/TR/trace-context/)​形式です。 ### [](#mule-スパンデータ)Mule スパンデータ トレースは、分散システムの完全な操作を表す一連のスパンです。スパンは、ネストされることがあり、作業または操作の単位を表します。各スパンには、以下が含まれます。
カテゴリ 説明 値の例

Name (名前)

スパンの名前

mule:set-variable

Parent Span ID (親スパン ID)

現在のスパンの親のスパン ID

86838830d494d679

Start and End Timestamps (開始および終了タイムスタンプ)

スパンの最も早いおよび最も遅いタイムスタンプ

2021-10-22 16:04:01.209458162 +0000 UTC

Span Context (スパンコンテキスト)

スパンを一意に識別するデータ: トレース ID、スパン ID、トレースフラグ、トレース状態

Attributes (属性)

メタデータが含まれるキー-値ペア。このメタデータを使用してアノテーションをスパンに付加し、追跡対象の操作に関する情報を伝えます。

{ “location”: “flow/processors/2”, “correlation.id”: “1234abcd” }

Span Events (スパンイベント)

スパンの期間中の意味のある一意の時点を示すために使用される、スパンの構造化されたログメッセージまたはアノテーション。

{ "name": "", "message": "OK", "timestamp": "2021-10-22 16:04:01.209512872 +0000 UTC" }

Span Links (スパンリンク)

あるスパンを 1 つ以上の他のスパンに関連付けるリンク (因果関係を示す)。

Span Status (スパン状況)

スパンに関連付けられた状況。アプリケーションコードで例外などの不明なエラーが発生したときのスパン状況を設定できます。

ERROR​、​OK​、​UNSET

Span Kind (スパンの種類)

トレースの編成方法に関する情報。

CLIENT​、​INTERNAL​、​PRODUCER
### [](#フロートレース機能の例)フロートレース機能の例 フロー実行をトレースする場合、メッセージの処理に関連する各 Mule コンポーネント実行はスパンとして表されます。コンポーネントスパンは、実行の関連する側面を表します。Set Payload などのシンプルなコンポーネントでは 1 つのスパンですが、Batch Job などではより複雑な構造になります。 バッチインスタンス Mule Runtime は Batch Job などの複雑なコンポーネントを追跡します。 ![Listener および Set Payload コンポーネントが含まれるより複雑な構造のバッチフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/otel-batch-instance.png) 生成されるスパン トレースは、Batch Job の最初のステップでどのように各バッチレコードが処理されるのかを表示します。各レコードスパンには、Logger コンポーネントで実行される作業の単位を表す子スパンが含まれます。 次に、For Each コンポーネントおよびその内部のプロセッサー (Transform Message や Logger など) と共に Batch Aggregator スパンを表示します。 その後、他の 2 つのバッチステップとそれぞれのコンポーネントを表示します。 最後に、フローの Batch Job の後に表示される Logger コンポーネントと共に Batch On Complete スパンを表示します。 ### [](#分散トレース機能の例)分散トレース機能の例 次の例では、ある Mule アプリケーションが別の Mule アプリケーションに要求を送信しています。 ![HTTP アプリケーションの Listener、Logger、Request コンポーネントが含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/otel-mule-app1.png) ![非同期アプリケーションのプロセスフローが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/otel-mule-app2.png) Mule および HTTP Connector で OpenTelemetry が計測されるため、分散トレースでは、同じトレースの一部として両方のフローが取得されます。 ### [](#トレースのエラー)トレースのエラー スパンで表される実行作業単位でエラーが発生すると、スパンの状況が ​`[Error (エラー)]`​ に設定されます。MuleSoft は、1 つ以上の​`例外`​イベントをスパンに追加する OpenTelemetry によって定義されるセマンティック規則に準拠します。 - `exception.type`​: Mule エラー種別 - `exception.message`​: Mule エラーメッセージ - `exception.stacktrace`​: Mule フロースタックの文字列表現 次の例では、エラーが発生したときに、Raise error コンポーネントに対応するスパンで Lightstep プラットフォームのエラー状況が表示されます。 ![エラー処理が含まれるテレメトリーフローのフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/otel-errors-in-tracing.png) この状況は、親スパン (フロースパンなど) に伝播します。スパンの詳細ビューにエラー状況と例外イベントが表示されます。 ### [](#http-規則)HTTP 規則 HTTP Listener および HTTP Request 操作により、スパンに属性が追加され、HTTP インタラクションをトレースするためのより多くのコンテキストが提供されます。 HTTP Listener が含まれるフローでは以下のようになります。 - Span name (スパン名): HTTP メソッドとパスの組み合わせ。例: `POST /api`​。 - Span kind (スパンの種類): `SERVER`​。 フロースパンに関連付けられた HTTP Listener の追加属性:
属性 説明

net.host.name

HTTP Listener のホストアドレス

net.host.port

HTTP Listener のポート

http.user_agent

受信した要求のユーザーエージェント

http.route

HTTP Listener のパス

http.method

HTTP メソッド

http.flavor

HTTP バージョン
HTTP Request が含まれるフローでは以下のようになります。 - Span name (スパン名): HTTP メソッド。例: `GET`​。 - Span kind (スパンの種類): `CLIENT`​。 フロースパンに関連付けられた HTTP Request の追加属性:
属性 説明

http.url

対象 URL

net.host.port

HTTP Request のポート

net.peer.name

対象 IP アドレス

http.route

HTTP Request のパス

http.flavor

HTTP バージョン
## [](#関連情報)関連情報 - [サードパーティ監視システムへのテレメトリーデータのエクスポート](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter) # Mule Runtime 高可用性 (HA) クラスターの概要
CloudHub でのクラスタリングに相当するものの場合、アプリケーションを拡大し、高可用性を提供するためにワーカーを共有または二重化する方法の詳細は、​CloudHub 高可用性​を参照してください。
Mule Enterprise Edition は拡張可能なクラスタリングをサポートし、アプリケーションの高可用性 (HA) を実現しています。 クラスターとは、ユニットとして機能する Mule Runtime Engine のセットです。言い換えると、クラスターとは複数のノード (Mule Runtime Engine) で構成された仮想サーバーです。クラスター内のノードは分散された共有メモリグリッドを通じて通信を行い、情報を共有します。つまり、データがさまざまなマシンのメモリ間で複製されます。 ![cluster](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/cluster.png)
この機能の価格については、カスタマーサービス担当者にお問い合わせください。
## [](#クラスタリングの利点)クラスタリングの利点 デフォルトでは、Mule Runtime Engine のクラスタリングにより、システムの高可用性を実現できます。障害や計画的なダウンタイムが原因で Mule Runtime Engine ノードが使用不可になった場合、クラスター内の別のノードがワークロードを引き継ぎ、既存のイベントおよびメッセージの処理を続行できます。次の図は、2 ノードのクラスターによる受信メッセージの処理を示しています。処理負荷がノード間で分散されているのがわかります。ノード 1 がメッセージ 1 を処理するのと同時に、ノード 2 はメッセージ 2 を処理します。 ![FailoverNoFail](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/failovernofail.png) 一方のノードで障害が発生した場合、もう一方の障害の発生していないノードが障害の発生しているノードの作業を引き継ぎます。次の図で示しているように、ノード 2 で障害が発生した場合、ノード 1 はメッセージ 1 とメッセージ 2 の両方を処理します。 ![FailoverNode2Fail](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/failovernode2fail.png) Mule Runtime Engine のクラスターではすべてのノードが同時にメッセージを処理するため、クラスターによってパフォーマンスおよび拡張性も向上します。単一ノードのインスタンスと比較すると、クラスターのほうがサポートできるユーザーも多く、ワークロードを複数のノードで共有するかノードをクラスターに追加することで、アプリケーションのパフォーマンスも向上できます。 次の図では、ワークロードの共有をより詳しく示しています。両方のノードが受注処理に関するメッセージを処理します。ただし、一方のノードの負荷が大きい場合、その処理の 1 つ以上のステップの処理をもう一方のノードに移動できます。ここでは、割引処理ステップの処理がノード 1 に移動され、受注ステップの処理がノード 2 に移動されています。 ![cluster diagram](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/cluster-diagram.png) 自動フェールオーバーによる高可用性、パフォーマンスの向上、拡張性の向上以外に、Mule Runtime Engine のクラスタリングには次のような利点があります。 - ファイル、データベース、FTP ソースなどのリソースへのアクセスの自動調整。 Mule Runtime Engine クラスターは、どのノード (Mule Runtime Engine) がデータソースからの通信を処理するかを自動的に管理します。 - クラスター内の処理の自動負荷分散。 フローを一連のステップに分割してこれらのステップを VM などのコネクタと接続すると、各ステップはキューに入り、クラスターが有効になります。続いて、Mule Runtime Engine のクラスターが任意のノードで各ステップを処理し、ノード間で負荷がより効率的に分散されます。 - アラートの生成。 ノードがダウンした場合やノードが復活したときに表示されるアラートをセットアップできます。
クラスターのすべての Mule Runtime Engine はアクティブにメッセージを処理します。各 Mule ノードは内部でも拡張可能です。単一のノードでも複数のコアを活用することで拡張できます。Mule は複数のコアを使用する場合であっても、クラスターでは単一のノードとして動作します。
### [](#クラスターによって解決される同時実行の問題)クラスターによって解決される同時実行の問題 クラスターとしてバインドされていない複数のサーバーで構成されたサーバーグループがある場合、次のような問題が存在する可能性があります。サーバーをクラスターとしてグループ化すれば、こうした問題に頭を悩ませることはありません。 - ファイルベースのコネクタ。 すべての Mule インスタンスは同じ Mule ファイルフォルダーに同時にアクセスするため、ファイル処理が重複することもあれば、ファイルが Mule アプリケーションによって削除または変更された場合には障害が発生する可能性もあります。 - マルチキャストコネクタ。 すべての Mule インスタンスは同じ TCP 要求を受けてから重複メッセージを処理します。 - JMS トピック。 すべての Mule インスタンスは同じ JMS トピックに接続するため、非クラスタリング Mule インスタンスを水平方向に拡張した場合、メッセージの処理が反復される場合もあります。 - JMS request-reply (要求-返信)/request-response (要求-応答)。 すべての Mule インスタンスは同じ応答キューでメッセージをリスンします。これは、Mule インスタンスが送信した要求に相関していない応答を受け取る可能性があり、結果として不正な応答になったりフローがタイムアウトにより失敗したりする場合があることを意味します。 - 冪等性再配信ポリシー。 同じ要求が異なる Mule インスタンスによって受信された場合、冪等性は機能しません。複製されたメッセージは使用できません。 - Salesforce ストリーミング API。 同じアプリケーションの複数のインスタンスをデプロイした場合、API は単一コンシューマーしかサポートしていないため、失敗します。接続されているインスタンスが停止またはクラッシュした場合のフェールオーバーのサポートはありません。 ## [](#前提条件)前提条件 - クラスターには少なくとも 2 個の Mule Runtime Engine インスタンスが必要であり、それぞれを異なるマシンで実行する必要があります。 - Mule 高可用性 (HA) では、クラスターのノード間の同期を維持するために、サーバー間に信頼性の高いネットワーク接続が必要です。 - Mule クラスター用に設定されたポートを開いたままにします。 - Runtime Manager を使用してクラスターをセットアップし、デフォルトポートを使用する場合、TCP ポート ​`5701`​、​`5702`​、および ​`5703`​ を開いたままにします。 - 代わりにカスタムポートを設定する場合、カスタムポートを開いたままにします。 - ポート ​`5701`​ を介してノード間の通信が開いていることを確認します。 ネットワーク内のファイアウォールルールを検証して、ノード間の双方向通信が有効になっていることを確認します。 クラスターでマルチキャストを有効にする場合、前述の前提条件に加えて次の要件も適用されます。 - UDP ポート ​`54327`​ を開いたままにします。 - マルチキャスト IP アドレス ​`224.2.2.3`​ を有効にします。 ## [](#高可用性)高可用性 高可用性とは、そこで実行されるアプリケーションのダウンタイムを防止するようにコンピューターシステムをデザインする方法です。一部のシステムでは 1 台のサーバーでダウンタイムが発生しても、アプリケーションはアプリケーションのエンドユーザーに対するサービスに提供を中断することなくもう 1 台のサーバーでスムーズに実行し続けることができるように、複数のサーバーを使用しています。 ## [](#クラスターのデザインと管理)クラスターのデザインと管理 Anypoint Runtime Manager は、Mule インスタンスのクラスターをセットアップしてアプリケーションをデプロイしてクラスターで実行できるようにします。クラスターおよび個別のノードの状況に関する情報を監視することもできます。クラスタリングを行うと、複数のサーバーを 1 台として容易に管理できます。
クラスター管理についての詳細は、Runtime Manager の​「Managing Servers (サーバーの管理)」​を参照してください。
Mule クラスターは、2 つ以上の Mule Runtime Engine、またはノードで構成され、グループにまとめられて単一ユニットとして扱われます。初期設定の場合、クラスターの拡張は 8 個の Mule Runtime Engine までにすることをお勧めします。 Anypoint Runtime Manager を使用すれば、クラスター内のすべての Mule Runtime Engine を単一の Mule Runtime Engine であるかのようにデプロイ、監視、および停止することができます。 次に示すように、クラスター内のすべてのノードはメモリを共有します。 ![topology\_4-cluster](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/topology-4-cluster.png)
動作のパフォーマンスを確保するために、Mule は active-active (アクティブ-アクティブ) モデルを使用して Mule Runtime Engine をクラスタリングします。active-passive (アクティブ-パッシブ) モデルに対するこのモデルのメリットは、アプリケーションがすべてのノードで実行され、メッセージ処理をクラスター内の他のノードと分け合うことで、処理を効率化できることです。
### [](#プライマリノードの違い)プライマリノードの違い active-active (アクティブ-アクティブ) モデルでは、プライマリノードはありません。ただし、いずれかのノードがプライマリポーリングノードの役割を果たします。つまり、他のノードがそのソースからのメッセージを読み取らないように、ソースをプライマリポーリングノードのみで使用するように設定できます。 この機能は、ソース種別に応じて異なります。 - スケジューラーソース: プライマリポーリングノードでのみ実行されます。 - 他のソース: `primaryNodeOnly`​ 属性で定義されます。そのコネクタの ​`primaryNodeOnly`​ のデフォルト値を調べるには、各コネクタのドキュメントを確認してください。 JMS の設定例: ```xml ``` ## [](#queues)Queues Mule Runtime Engine (ノード) 間で負荷分散を行うために明示的に VM キューをセットアップできます。そのため、アプリケーションフロー全体に子フローのシーケンスが含まれる場合、クラスターは連続する各子フローをその時点で使用可能な任意の Mule Runtime Engine に割り当てることができます。下で示しているように、クラスターはアプリケーションフローの VM エンドポイントを通過するときに複数のノードで単一メッセージを処理することもできます。 ![load\_balancing](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/load-balancing.png) ## [](#高信頼性アプリケーション)高信頼性アプリケーション 高信頼性アプリケーションと言えるには、以下の要件を満たす必要があります。 1. メッセージの損失の許容がゼロであること 2. インテグレーションエンジン (Mule) が信頼できること 3. 個別の接続の信頼性が高いこと トランザクション性として知られる機能はアプリケーションイベントシーケンスを追跡し、それぞれのメッセージ処理ステップが正常に完了するようにします。そのため、失われたり不正に処理されたりするメッセージはありません。何らかの理由でステップが失敗した場合、トランザクションメカニズムが以前の処理イベントをすべてロールバックし、メッセージ処理シーケンスを再開します。 JMS、VM、JDBC などのコネクタにより、ビルトイントランザクションサポートが提供されるため、メッセージが確実に処理されるようになります。たとえば、トランザクションがコミットされた後でのみメッセージを JMS サーバーから削除するようにインバウンド JMS 接続エンドポイントでトランザクションを設定できます。この方法により、処理フロー中にエラーが発生した場合、元のメッセージは再処理できる状態で保持されます。 トランザクションをサポートする異種コネクタ間でメッセージを移動するには、XA トランザクションを使用する必要があります。これにより、Mule Runtime Engine はすべての異種コネクタの関連付けられたトランザクションを単一ユニットとしてコミットするようになります。 ## [](#コネクタのクラスターサポート)コネクタのクラスターサポート すべての Mule Connector がクラスター内でサポートされます。コネクタごとにインバウンドトラフィックにアクセスする方法が異なるため、このサポートの詳細は異なります。一般に、アウトバウンドトラフィックはクラスター内外で同じように機能します。Mule Runtime は 3 つの基本的な種別のコネクタをサポートしています。 ### [](#ソケットベースのコネクタ)ソケットベースのコネクタ ソケットベースのコネクタは Mule が所有するネットワークソケットに送信された入力を読み取ります。例としては TCP、UDP、HTTP\[S\] などがあります。 ソケットベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - クラスタリングされた各 Mule Runtime は異なるネットワークノードで実行されるため、各インスタンスはそのノードに送信されたソケットベースのトラフィックのみを受信します。受信したソケットベースのトラフィックは、クラスタリングされたインスタンス間で分散するために​[\[Clustering and Load Balancing\]](<#Clustering and Load Balancing>)​を実行する必要があります。 - ソケットベースのコネクタへの出力は特定のホスト/ポートの組み合わせに書き込まれます。ホスト/ポートの組み合わせが外部ホストの場合、特に考慮事項はありません。ローカルホストのポートの場合、クラスター間でより効率的にトラフィックを分散するために、代わりにロードバランサーでそのポートを使用することを検討してください。 ### [](#リスナーベースのコネクタ)リスナーベースのコネクタ リスナーベースのコネクタは同時の複数アクセサーを十分にサポートするプロトコルを使用してデータを読み取ります。例としては、JMS や VM があります。 リスナーベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - リスナーベースのコネクタは複数のリーダーおよびライターを完全にサポートしています。入力にも出力にも特に考慮事項はありません。 - クラスターでは、VM Connector キューが共有のクラスター全体のリソースである点に注意してください。クラスターは VM Connector キューへのアクセスを自動的に同期します。そのため、任意のクラスターノードで VM キューに書き込まれたメッセージを処理できます。これにより、VM はクラスターノード間でワークを共有するのに最適です。 ### [](#リソースベースのコネクタ)リソースベースのコネクタ リソースベースのコネクタは複数の同時アクセサーは使用可能だがリソースの使用をネイティブに調整しないリソースからデータを読み取ります。リソースベースのコネクタの例としては、ファイル、FTP、SFTP、メール、JDBC などがあります。 リソースベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - Mule HA クラスタリングは自動的にクラスター内のノードのみについて各リソースへのアクセスを調整するため、クラスタリングされたインスタンスのうち 1 つだけが一度に各リソースにアクセスするようになります。そのため、通常はリソースベースのコネクタから読み取られたメッセージをすぐに VM キューに書き込むことをお勧めします。これにより、他のクラスターノードがメッセージの処理に参加できます。

クラスター内のノードとして同じリソースにアクセスする他のアプリケーション (クラスター外の Mule アプリケーションまたは Mule 以外のアプリケーション) を実行する場合は、これらのリソースをロックするロジックを実装する必要があります。

たとえば、複数のプログラムがファイルの読み取り、変更、そして削除を行うことで、同じ共有ディレクトリのファイルを処理しているとします。これらのプログラムは明示的なアプリケーションレベルのロッキング戦略を使用して、同じファイルが複数回処理されないようにする必要があります。
- リソースベースのクラスタリングされたコネクタへの書き込みには特に考慮事項はありません。 - ファイルベースのコネクタ (ファイル、FTP、SFTP) に書き込むときに、Mule は一意のファイル名を生成します。 - JDBC に書き込むときに、Mule は一意のキーを生成できます。 - メールの作成は、実質的にはリソースベースではなくリスナーベースです。 ## [](#クラスタリングと信頼性の高いアプリケーション)クラスタリングと信頼性の高いアプリケーション 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。クラスターで十分に信頼できるアプリケーションをビルドするためのツールは​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.3/reliability-patterns)​で見つかります。 アプリケーションで非トランザクションコネクタを使用している場合、信頼性パターンに従ってください。これらのパターンにより、メッセージが受け入れられて正常に処理されるか、「失敗」応答を生成してクライアントが再試行できるようになります。 アプリケーションで JMS、VM、JDBC などのトランザクションコネクタを使用している場合は、トランザクションを使用します。トランザクションコネクタに対する Mule のビルトインサポートにより、こうしたコネクタを使用するアプリケーションで信頼性の高いメッセージングを実現できます。 これらのアクションは、クラスタリングされていないアプリケーションにも適用できます。 ## [](#クラスタリングとネットワーキング)クラスタリングとネットワーキング ### [](#単一のデータセンターのクラスタリング)単一のデータセンターのクラスタリング クラスターノード間で信頼性のある接続を確立するには、クラスターのすべてのノードを同じ LAN に配置する必要があります。VPN を通じて接続された異なるデータセンターなど、地理的に離れた場所にノードが含まれるクラスターを実装することも可能ですが、お勧めはしません。 ネットワークの中断や、メッセージの重複などの意図しない結果を招く可能性を下げるためには、すべてのクラスターノードを同じ LAN に配置するのが最もお勧めです。 ### [](#分散型データセンターのクラスタリング)分散型データセンターのクラスタリング WAN ネットワークを使用してクラスターノードをリンクすると、外部ルーターやファイアウォールなど、障害が発生する可能性のあるポイントが多くなり、クラスターノード間で適切に同期が行われないおそれがあります。これはパフォーマンスに影響を及ぼすだけでなく、アプリケーションにおける副作用の可能性を考慮に入れる必要も生じます。たとえば、2 つのクラスターノードがネットワークリンクの障害による切断後に再接続した場合、次回の同期プロセスでメッセージが 2 回処理される可能性があり、重複が発生して、アプリケーションロジックで処理する必要が生じます。 異なるデータセンターに配置されたクラスターのノードを使用でき、必ずしも同じ LAN に配置されている必要はありませんが、いくつか制限事項がある点に注意してください。 この動作を防ぐには、Quorum プロトコルを有効にする必要があります。このプロトコルは、ノードの 1 つのセットがデータの処理を続行し、他のセットが再接続されるまで共有データに関して何も実行しないようにするために使用されます。基本的に、切断が発生した場合、ノードが最も多い方のみが稼働し続けます。たとえば、2 つのデータセンターがあり、一方は 3 つのノードがあり、もう一方には 2 つのノードがあるとします。2 つのノードがあるデータセンターで接続の問題が発生した場合、ノードが 3 つのデータセンターが機能し続け、もう一方のデータセンターは停止します。ノードが 3 つのデータセンターがオフラインになった場合、どちらのノードも機能しなくなります。こうした機能停止を防ぐには、少なくとも 3 つの同じ数のノードを持つデータセンターでクラスターを作成する必要があります。2 つのデータセンターがクラッシュすることは考えにくいため、1 つのデータセンターがオフラインになっても、クラスターは常に機能し続けることになります。
機能するのに十分なノードがクラスターパーティションにない場合、外部システムコールに対しては引き続き反応しますが、オブジェクトストアを経由したすべての操作は失敗し、データ生成できなくなります。
#### [](#制限事項)制限事項 - Quorum はオブジェクトストア関連の操作でのみサポートされます。 - 分散ロッキングはサポートされず、以下に影響を及ぼします。 - ファイルの並列に関するファイル/FTP Connector ポーリング - 冪等性再配信ポリシーコンポーネント - 冪等性メッセージ検索条件コンポーネント - メモリ内メッセージングはサポートされず、以下に影響を及ぼします。 - VM Connector - Quorum 機能は手動でのみ設定できます。 - Batch job では高可用性機能は使用されません。 ## [](#クラスタリングと負荷分散)クラスタリングと負荷分散 TCP 要求 (この場合、TCP には SSL/TLS、UDP、Multicast、HTTP、HTTPS が含まれる) に対応するために Mule クラスターが使用される場合、クラスタリングされたインスタンス間で要求を分散するためにある程度の負荷分散が必要になります。さまざまなソフトウェアのロードバランサーが使用できますが、そのうちの 2 つを紹介します。 - オープンソースの HTTP サーバーおよびリバースプロキシである Nginx。HTTP(S) の負荷分散に NGINX の ​`HttpUpstreamModule`​ を使用できます。 - Apache Web サーバー。これは HTTP(S) ロードバランサーとしても使用できます。 TCP と HTTP または HTTPS トラフィックの両方をルーティングできるハードウェアのロードバランサーも多数あります。 ## [](#cluster-high-performance)高パフォーマンス用のクラスタリング このセクションは、オンプレミスデプロイメントにのみ適用されます。高パフォーマンスの実装は CloudHub と Pivotal Cloud Foundry で異なります。 これらの各デプロイメントについての詳細は、​[「デプロイメント戦略」](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)​を参照してください。 (信頼性ではなく) 高パフォーマンスが最大目標の場合は、パフォーマンスプロファイルを使用してパフォーマンスが最大になるように Mule クラスターまたは各アプリケーションを設定できます。クラスター内で特定のアプリケーションのパフォーマンスプロファイルを実装することで、デプロイメントの拡張性を最大にすると同時に、パフォーマンスおよび信頼性の要件が異なるアプリケーションを同じクラスターにデプロイすることができます。コンテナレベルで設定したパフォーマンスプロファイルは、そのコンテナ内のすべてのアプリケーションに適用されます。アプリケーションレベルの設定はコンテナレベルの設定より優先されます。 ### [](#パフォーマンスプロファイルの設定に関する考慮事項)パフォーマンスプロファイルの設定に関する考慮事項 パフォーマンスプロファイルの設定には 2 つの効果があります。 - 分散キューが無効になり、代わりにローカルキューを使用して共有データグリッドにおけるデータの逐次化/非逐次化および分散を防止します。 - バックアップなしでオブジェクトストアを実装し、複製を防止します。
1 つのノードがダウンしたら、そのノードに関連付けられているデータが失われます。
パフォーマンスプロファイルを設定しても、メモリ共有には影響しません。クラスターモードでは、オブジェクトストアはノード間で常に分散し、共有されます。 ### [](#パフォーマンスプロファイルの設定)パフォーマンスプロファイルの設定 _コンテナ_​レベルでパフォーマンスプロファイルを設定するには、次のコマンドを ​`mule-cluster.properties`​、システムプロパティ (コマンドラインから)、または ​`wrapper.conf`​ に追加します。 `mule.cluster.storeprofile=performance` _個別のアプリケーション_​レベルでパフォーマンスプロファイルを設定するには、以下で示しているように、設定ラッパー内にプロファイルを追加します。 - パフォーマンスストアプロファイル ```xml ``` アプリケーションレベルの設定はコンテナレベルの設定より優先されます。高パフォーマンス用にコンテナを設定するが、そのコンテナ内の 1 つ以上の個別のアプリケーションでは信頼性を優先するには、こうしたアプリケーションに次のコードを含めます。 - 信頼性ストアプロファイル ```xml ```

負荷分散をサポートしないエンドポイントで負荷が大きい場合、パフォーマンスプロファイルを適用するとパフォーマンスが低下する場合もあります。非同期処理戦略、ロードバランサーがない JMS トピック、マルチキャスト、または HTTP Connector でファイルベースのコネクタを使用している場合、大量のメッセージが単一ノードに入るとボトルネックが発生する可能性があるため、こうしたアプリケーションのパフォーマンスプロファイルを無効にしたほうがパフォーマンスが向上する場合があります。
稼働状態を保つためにクラスターで必要なマシンの最小数を定義することもできます。この設定により、パフォーマンス全体での一貫性が改善されます。 ## [](#クラスターノード間の通信の暗号化)クラスターノード間の通信の暗号化 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルでまたはシステムプロパティとして定義することで、クラスターノード間のトラフィックを暗号化できます。 暗号化キーを定義すると、定義したキーと AES 暗号化アルゴリズムを使用してクラスターノード間のすべての通信が暗号化されます。 ## [](#cluster_fips)FIPS モードでのクラスタリングの有効化 FIPS モードでのクラスタリングを有効化するには、次のタスクを完了します。 - FIPS モードで Mule Runtime Engine を実行します。 設定の手順は、​[「FIPS コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.3/fips-140-2-compliance-support)​を参照してください。 - クラスターノード間の通信を暗号化します。 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルで定義するか、システムプロパティとして定義します。 ### [](#警告)警告 - 暗号化キーを定義しない場合、アプリケーションはデプロイに失敗し、​`Cluster key must be defined in FIPS mode.`​ というメッセージが表示されます。 - クラスタリングされたすべてのノードで同じ暗号化キーを使用しない場合、この機能は動作しません。 - FIPS モードでクラスタリングされた環境を実行すると、ノード間のすべての通信が暗号化 (および復号化) されるため、パフォーマンスが低下します。 ## [](#クラスタリングのベストプラクティス)クラスタリングのベストプラクティス クラスタリングに関しては多くの推奨事項があります。例を挙げます。 - できるだけアプリケーションを一連のステップに整理し、各ステップがメッセージを 1 つのトランザクションストアから別のトランザクションストアに移動するようにします。 - アプリケーションで非トランザクションコネクタからのメッセージを処理する場合、​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.3/reliability-patterns)​を使用して VM や JMS ストアなどのトランザクションストアに移動します。 - トランザクションを使用してトランザクションコネクタからのメッセージを処理します。これにより、エラーが発生した場合、メッセージが再処理されるようになります。 - VM や JMS Connector で使用するような分散ストアを使用します。こうしたストアはクラスター全体に対して使用可能です。これは、ファイル、FTP、JDBC などのコネクタで使用する非分散ストアよりも優れています。こうしたストアは一度に単一のノードによって読み取られます。 - VM Connector を使用して最適なパフォーマンスを得ます。クラスター全体が終了した後にデータを保存する必要があるアプリケーションに JMS Connector を使用します。 - 高信頼性アプリケーションを作成するには信頼性パターンを実装します。 - HA クラスターモードでは、すべてのオブジェクトストアコンテンツ (メモリ内コンテンツと、​`persistent`​ パラメーターで定義される永続的なコンテンツの両方) は、分散メモリグリッドに保存されます。クラスターでクォーラムが保持されている限り、このデータはアプリケーションの再デプロイまたは再起動後も存続します。オブジェクトストアコンテンツを完全にクリアするには、再起動する前にすべてのクラスターノードを停止する必要があります。クラスターの完全シャットダウン後もデータの永続性が必要なシナリオでは、メモリグリッドの代わりに JDBC ベースのストアを使用するようにオブジェクトストアを設定します。​[「オブジェクトストアの永続性」](https://docs.mulesoft.com/jp/mule-runtime/4.3/creating-and-managing-a-cluster-manually#object-store-persistence)​を参照してください。 ## [](#関連情報)関連情報 - [Enterprise ライセンスのインストール](https://docs.mulesoft.com/jp/mule-runtime/4.3/installing-an-enterprise-license) - [サーバーの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-servers#create-a-cluster) - [CloudHub 高可用性および障害回復](https://docs.mulesoft.com/cloudhub/cloudhub-hadr) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/creating-and-managing-a-cluster-manually) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management) - [クォーラム管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/creating-and-managing-a-cluster-manually#quorum-management) # Mule Runtime 高可用性 (HA) クラスターの概要
CloudHub でのクラスタリングに相当するものの場合、アプリケーションを拡大し、高可用性を提供するためにワーカーを共有または二重化する方法の詳細は、​CloudHub 高可用性​を参照してください。
Mule Enterprise Edition は拡張可能なクラスタリングをサポートし、オンプレミスアプリケーションの高可用性 (HA) を実現しています。 クラスターとは、ユニットとして機能する Mule Runtime Engine のセットです。言い換えると、クラスターとは複数のノード (Mule Runtime Engine) で構成された仮想サーバーです。クラスター内のノードは分散された共有メモリグリッドを通じて通信を行い、オブジェクトストアと VM キューのデータを共有します。つまり、データがさまざまなマシンのメモリ間で複製されます。 この複製された状態の共有メモリグリッドは、次のものに適用されます。 - 永続的または非永続的なオブジェクトストア - 永続的または一時的な VM キュー - Mule Runtime LockFactory ![クラスター](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/cluster.png)
この機能の価格については、カスタマーサービス担当者にお問い合わせください。
## [](#クラスタリングの利点)クラスタリングの利点 デフォルトでは、Mule Runtime Engine のクラスタリングにより、システムの高可用性を実現できます。障害や計画的なダウンタイムが原因で Mule Runtime Engine ノードが使用不可になった場合、クラスター内の別のノードがワークロードを引き継ぎ、VM キューからのメッセージの処理やその他の要求のサービスを続行できます。次の図は、2 ノードのクラスターによる受信メッセージの処理を示しています。処理負荷がノード間で分散されているのがわかります。ノード 1 がメッセージ 1 を処理するのと同時に、ノード 2 はメッセージ 2 を処理します。 ![FailoverNoFail](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/failovernofail.png) 一方のノードで障害が発生した場合、もう一方の障害の発生していないノードが障害の発生しているノードの作業を引き継ぎます。外部ロードバランサーが障害の発生しているノードのトラフィックをアクティブなノードにリダイレクトするか、VM キューを通じてアクティブなノードがインフライトメッセージの処理を続行できるようにします。次の図で示しているように、ノード 2 で障害が発生した場合、ノード 1 はメッセージ 1 とメッセージ 2 の両方を処理します。 ![FailoverNode2Fail](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/failovernode2fail.png) Mule Runtime Engine のクラスターではすべてのノードが同時に「アクティブ-アクティブ」になりメッセージを処理できるため、クラスターによってパフォーマンスおよび拡張性も向上します。単一ノードのインスタンスと比較すると、クラスターのほうがサポートできるユーザーも多く、ワークロードを複数のノードで共有するかノードをクラスターに追加することで、アプリケーションのパフォーマンスも向上できます。アプリケーションによっては水平方向にスケーリングまたはクラスタリングを行ってもパフォーマンスが向上しないものもあります。パフォーマンスは追加ノードと共有される作業の性質によって異なります。オブジェクトストアを多用するアプリケーションの中には、共有メモリグリッド内のデータの複製やアクセスの調整に必要な作業のために、パフォーマンスが低下するものもあります。 次の図では、ワークロードの共有をより詳しく示しています。両方のノードが受注処理に関するメッセージを処理します。ただし、一方のノードの負荷が大きい場合、その処理の 1 つ以上のステップの処理をもう一方のノードに移動できます。ここでは、割引処理ステップの処理がノード 1 に移動され、受注ステップの処理がノード 2 に移動されています。 ![クラスター図](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/cluster-diagram.png) 自動フェールオーバーによる高可用性、パフォーマンスの向上、拡張性の向上以外に、Mule Runtime Engine のクラスタリングには次のような利点があります。 - ファイル、データベース、FTP ソースなどのリソースへのアクセスの自動調整。 Mule Runtime Engine クラスターは、どのノード (Mule Runtime Engine) がデータソースからの通信を処理するかを自動的に管理します。 - クラスター内の処理の自動負荷分散。 フローを一連のステップに分割してこれらのステップを VM などのコネクタと接続すると、各ステップはキューに入り、クラスターが有効になります。続いて、Mule Runtime Engine のクラスターが任意のノードで各ステップを処理し、ノード間で負荷がより効率的に分散されます。 - アラートの生成。 ノードがダウンした場合やノードが復活したときに表示されるアラートをセットアップできます。
クラスターのすべての Mule Runtime Engine はアクティブにメッセージを処理します。各 Mule ノードは垂直方向にも拡張可能です。単一のノードでも複数のコアや追加メモリを活用することで拡張できます。Mule は複数のコアを使用する場合であっても、クラスターでは単一のノードとして動作します。
### [](#クラスターによって解決される同時実行の問題)クラスターによって解決される同時実行の問題 クラスターとしてバインドされていない複数のサーバーで構成されたサーバーグループがある場合、次のような問題が存在する可能性があります。サーバーをクラスターとしてグループ化すれば、こうした問題に頭を悩ませることはありません。 - ファイルベースのコネクタ。 すべての Mule インスタンスは同じ Mule ファイルフォルダーに同時にアクセスするため、ファイル処理が重複することもあれば、ファイルが Mule アプリケーションによって削除または変更された場合には障害が発生する可能性もあります。 - マルチキャストコネクタ。 すべての Mule インスタンスは同じ TCP 要求を受けてから重複メッセージを処理します。 - JMS トピック。 すべての Mule インスタンスは同じ JMS トピックに接続するため、非クラスタリング Mule インスタンスを水平方向に拡張した場合、メッセージの処理が反復される場合もあります。JMS ブローカーからは、インスタンスは別々のサブスクライバーのように見え、そのすべてが各メッセージのコピーを取得します。この動作が必要となるのはまれです。このシナリオを避けるために、「共有サブスクライバー」設定を使用できます。この設定によって、JMS ブローカーに、すべてのインスタンスを結合サブスクライバーとして扱い、それぞれ別個のメッセージを与えるように指示できます。 - JMS request-reply (要求-返信)/request-response (要求-応答)。 すべての Mule インスタンスは同じ応答キューでメッセージをリスンします。これは、Mule インスタンスが送信した要求に相関していない応答を受け取る可能性があり、結果として不正な応答になったりフローがタイムアウトにより失敗したりする場合があることを意味します。 - 冪等性再配信ポリシーと冪等性メッセージ検証。 水平スケーリングで同じ要求を異なる Mule インスタンスが受信し、再配信ポリシーまたは Idempotency Message Validator で使用されるオブジェクトストアコンテンツがローカライズされている場合、冪等性が正しく機能しません。このような冪等性機能で使用されるオブジェクトストア値を共有するクラスターの場合、すべてのノードがすでに処理済みの識別子のリストを共有しているため、メッセージの重複は起こり得ません。 - Salesforce ストリーミング API。 同じアプリケーションの複数のインスタンスをデプロイした場合、API は単一コンシューマーしかサポートしていないため、失敗します。接続されているインスタンスが停止またはクラッシュした場合のフェールオーバーのサポートはありません。 ## [](#前提条件)前提条件 - クラスターには少なくとも 2 個の Mule Runtime Engine インスタンスが必要であり、マシン上で障害が 1 か所に集中することを防ぐため、それぞれを異なるマシンで実行する必要があります。 - Mule 高可用性 (HA) では、クラスターのノード間の同期を維持するために、サーバー間に信頼性の高いネットワーク接続が必要です。 - Mule クラスター用に設定されたポートを開いたままにします。 - Runtime Manager を使用してクラスターをセットアップし、デフォルトポートを使用する場合、TCP ポート ​`5701`​、​`5702`​、および ​`5703`​ を開いたままにします。 - 代わりにカスタムポートを設定する場合、カスタムポートを開いたままにします。 - ポート ​`5701`​ を介してノード間の通信が開いていることを確認します。 ネットワーク内のファイアウォールルールを検証して、ノード間の双方向通信が有効になっていることを確認します。 クラスターでマルチキャストを有効にする場合、前述の前提条件に加えて次の要件も適用されます。 - UDP ポート ​`54327`​ を開いたままにします。 - マルチキャスト IP アドレス ​`224.2.2.3`​ を有効にします。 ## [](#高可用性)高可用性 高可用性とは、そこで実行されるアプリケーションのダウンタイムを防止するようにコンピューターシステムをデザインする方法です。一部のシステムでは 1 台のサーバーでダウンタイムが発生しても、アプリケーションはアプリケーションのエンドユーザーに対するサービスに提供を中断することなくもう 1 台のサーバーでスムーズに実行し続けることができるように、複数のサーバーを使用しています。 ## [](#クラスターのデザインと管理)クラスターのデザインと管理 Anypoint Runtime Manager は、Mule インスタンスの顧客がホストするクラスターをセットアップしてアプリケーションをデプロイしてクラスターで実行できるようにします。クラスターおよび個別のノードの状況に関する情報を監視することもできます。クラスタリングを行うと、複数のサーバーを 1 台として容易に管理できます。
クラスター管理についての詳細は、Runtime Manager の​「Managing Servers (サーバーの管理)」​を参照してください。
Anypoint Runtime Fabric では、デプロイメント時に Mule Runtime レプリカをクラスターモードでプロビジョニングするオプションがあります。 Mule クラスターは、2 つ以上の Mule Runtime Engine、またはノードで構成され、グループにまとめられて単一ユニットとして扱われます。初期設定の場合、クラスターの拡張は 8 個の Mule Runtime Engine までにすることをお勧めします。 Anypoint Runtime Manager を使用すれば、クラスター内のすべての Mule Runtime Engine を単一の Mule Runtime Engine であるかのようにデプロイ、監視、および停止することができます。 注意: CloudHub ではプロビジョンされたワーカーにこのクラスタリング設定を使用しませんが、同等の環境を提供する他の高可用性機能があります。たとえば、Anypoint Object Store (OSv2) を介した外部化された状態管理や、永続的なキュー配置機能 (VM キューをワーカーの外部に移すことで、共有可能にして再プロビジョニングの際も存続するようにする) などです。 次に示すように、クラスター内のすべてのノードはメモリを共有します。 ![topology\_4-cluster](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/topology-4-cluster.png)
動作のパフォーマンスを確保するために、Mule は active-active (アクティブ-アクティブ) モデルを使用して Mule Runtime Engine をクラスタリングします。active-passive (アクティブ-パッシブ) モデルに対するこのモデルのメリットは、アプリケーションがすべてのノードで実行され、メッセージ処理をクラスター内の他のノードと分け合うことで、処理を効率化できることです。
### [](#プライマリノードの違い)プライマリノードの違い active-active (アクティブ-アクティブ) モデルでは、すべてのノードが処理を実行できます。ただし、いずれか 1 つのノードがプライマリノードとして機能し、スケジューラーやその他の「プライマリノードのみ」とマークされているイベントソースを実行します。このモデルでは、クラスター内の 1 つのプライマリポーリングノードでソースが実行され、クラスター内の他のノードはそれらのソースからのメッセージを読めないように設定できます。 この機能は、ソース種別に応じて異なります。 - スケジューラーソース: プライマリポーリングノードでのみ実行されます。 - 他のソース: `primaryNodeOnly`​ 属性で定義されます。そのコネクタの ​`primaryNodeOnly`​ のデフォルト値を調べるには、各コネクタのドキュメントを確認してください。 JMS の設定例: ```xml ``` この例は、逐次/一度に 1 つのメッセージの処理が必要な状況でアプリケーションが JMS からメッセージを受信するユースケースのものと考えられます。JMS Connector の On New Message ソースのデフォルト設定では、デフォルトで \[Primary Node Only (プライマリノードのみ)\] が選択されていますが、ほとんどのコネクタソースでは \[Primary Node Only (プライマリノードのみ)\] は選択されていません。デフォルト設定の決定はコネクタの開発者が行います。すべてのノードで処理を実行する必要があるユースケースでは、開発者はすべてのクラスターノードでソースが有効になるように primaryNodeOnly 値の選択を解除します。 ## [](#queues)Queues コードの実行とフロー参照によるフローのコールは、イベントの実行が開始されたのと同じノードで行われます。ただし、クラスタリングされた Mule Runtime で実行を共有または分散するために、VM キューをセットアップして VM キューに明示的にパブリッシュすることでノード間で負荷を分散できます。永続的な VM キューと一時的な VM キューのいずれでもクラスターの共有メモリグリッドが使用され、VM キューを介したあらゆる移行は別のアクティブなノードにジャンプする可能性があります。そのため、アプリケーションフロー全体に VM キューのパブリッシャー/リスナーによってリンクされた子フローのシーケンスが含まれる場合、クラスターは連続する各子フローをその時点で使用可能な任意の Mule Runtime Engine に割り当てることができます。下で示しているように、クラスターはアプリケーションフローの VM キューを通過するときに複数のノードで単一メッセージを処理することもできます。 ![load\_balancing](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/load-balancing.png) ## [](#高信頼性アプリケーション)高信頼性アプリケーション 高信頼性アプリケーションと言えるには、以下の要件を満たす必要があります。 1. メッセージの損失の許容がゼロであること 2. インテグレーションエンジン (Mule) が信頼できること 3. 個別の接続の信頼性が高いこと トランザクション性として知られる機能はアプリケーションイベントシーケンスを追跡し、それぞれのメッセージ処理ステップが正常に完了するようにします。そのため、失われたり不正に処理されたりするメッセージはありません。何らかの理由でステップが失敗した場合、トランザクションメカニズムが以前の処理イベントをすべてロールバックし、メッセージ処理シーケンスを再開します。 JMS、VM、JDBC などのコネクタにより、ビルトイントランザクションサポートが提供されるため、メッセージが確実に処理されるようになります。たとえば、トランザクションがコミットされた後でのみメッセージを JMS サーバーから削除するようにインバウンド JMS 接続エンドポイントでトランザクションを設定できます。この方法により、処理フロー中にエラーが発生した場合、元のメッセージは再処理できる状態で保持されます。 トランザクションをサポートする異種コネクタ間でメッセージを移動するには、XA トランザクションを使用する必要があります。これにより、Mule Runtime Engine はすべての異種コネクタの関連付けられたトランザクションを単一ユニットとしてコミットするようになります。
トランザクションは、コネクタがトランザクションをサポートしないシステムでのインタラクションや操作を対象とすることはできません。そのため、関連する操作の中にトランザクションに含めることができないものがある場合には、 Sagas​ などの代替パターンを代わりに使用します。
## [](#コネクタのクラスターサポート)コネクタのクラスターサポート すべての Mule Connector がクラスター内でサポートされます。コネクタごとにインバウンドトラフィックにアクセスする方法が異なるため、このサポートの詳細は異なります。一般に、アウトバウンドトラフィックはクラスター内外で同じように機能します。Mule Runtime は 3 つの基本的な種別のコネクタをサポートしています。 ### [](#ソケットベースのコネクタ)ソケットベースのコネクタ ソケットベースのコネクタは Mule が所有するネットワークソケットに送信された入力を読み取ります。例としては TCP、UDP、HTTP\[S\] などがあります。 ソケットベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - クラスタリングされた各 Mule Runtime は異なるネットワークノードで実行されるため、各インスタンスはそのノードに送信されたソケットベースのトラフィックのみを受信します。受信したソケットベースのトラフィックは、クラスタリングされたインスタンス間で分散するために​[\[Clustering and Load Balancing\]](<#Clustering and Load Balancing>)​を実行する必要があります。 - ソケットベースのコネクタへの出力は特定のホスト/ポートの組み合わせに書き込まれます。ホスト/ポートの組み合わせが外部ホストの場合、特に考慮事項はありません。ローカルホストのポートの場合、クラスター間でより効率的にトラフィックを分散するために、代わりにロードバランサーでそのポートを使用することを検討してください。 ### [](#リスナーベースのコネクタ)リスナーベースのコネクタ リスナーベースのコネクタは同時の複数アクセサーを十分にサポートするプロトコルを使用してデータを読み取ります。例としては、JMS や VM があります。 リスナーベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - リスナーベースのコネクタは複数のリーダーおよびライターを完全にサポートしています。入力にも出力にも特に考慮事項はありません。 - クラスターでは、VM Connector キュー (永続的と一時的の両方) が共有のクラスター全体のリソースである点に注意してください。クラスターは VM Connector キューへのアクセスを自動的に同期します。そのため、任意のクラスターノードで VM キューに書き込まれたメッセージを処理できます。これにより、VM はクラスターノード間でワークを共有するのに最適です。 ### [](#リソースベースのコネクタ)リソースベースのコネクタ リソースベースのコネクタは複数の同時アクセサーは使用可能だがリソースの使用をネイティブに調整しないリソースからデータを読み取ります。リソースベースのコネクタの例としては、ファイル、FTP、SFTP、メール、JDBC などがあります。 リソースベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - Mule HA クラスタリングは自動的にクラスター内のノードのみについて各リソースへのアクセスを調整するため、クラスタリングされたインスタンスのうち 1 つだけが一度に各リソースにアクセスするようになります。そのため、通常はリソースベースのコネクタから読み取られたメッセージをすぐに VM キューに書き込むことをお勧めします。これにより、他のクラスターノードがメッセージの処理に参加できます。

クラスター内のノードとして同じリソースにアクセスする他のアプリケーション (クラスター外の Mule アプリケーションまたは Mule 以外のアプリケーション) を実行する場合は、これらのリソースをロックするロジックを実装する必要があります。

たとえば、複数のプログラムがファイルの読み取り、変更、そして削除を行うことで、同じ共有ディレクトリのファイルを処理しているとします。これらのプログラムは明示的なアプリケーションレベルのロッキング戦略を使用して、同じファイルが複数回処理されないようにする必要があります。
- リソースベースのクラスタリングされたコネクタへの書き込みには特に考慮事項はありません。 - ファイルベースのコネクタ (ファイル、FTP、SFTP) に書き込むときに、Mule は一意のファイル名を生成します。 - JDBC に書き込むときに、Mule は一意のキーを生成できます。 - メールの作成は、実質的にはリソースベースではなくリスナーベースです。 ## [](#クラスタリングと信頼性の高いアプリケーション)クラスタリングと信頼性の高いアプリケーション 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。クラスターで十分に信頼できるアプリケーションをビルドするためのツールは​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.4/reliability-patterns)​で見つかります。 アプリケーションで非トランザクションコネクタを使用している場合、信頼性パターンに従ってください。これらのパターンにより、メッセージが受け入れられて正常に処理されるか、「失敗」応答を生成してクライアントが再試行できるようになります。 アプリケーションで JMS、VM、JDBC などのトランザクションコネクタを使用している場合は、トランザクションを使用します。トランザクションコネクタに対する Mule のビルトインサポートにより、こうしたコネクタを使用するアプリケーションで信頼性の高いメッセージングを実現できます。 これらのアクションは、クラスタリングされていないアプリケーションにも適用できます。 ## [](#クラスタリングとネットワーキング)クラスタリングとネットワーキング ### [](#単一のデータセンターのクラスタリング)単一のデータセンターのクラスタリング クラスターノード間で信頼性のある接続を確立するには、クラスターのすべてのノードを同じ LAN に配置する必要があります。VPN を通じて接続された異なるデータセンターなど、地理的に離れた場所にノードが含まれるクラスターを実装することも可能ですが、お勧めはしません。 ネットワークの中断や、メッセージの重複などの意図しない結果を招く可能性を下げるためには、すべてのクラスターノードを同じ LAN に配置するのが最もお勧めです。 ### [](#分散型データセンターのクラスタリング)分散型データセンターのクラスタリング WAN ネットワークを使用してクラスターノードをリンクすると、外部ルーターやファイアウォールなど、障害が発生する可能性のあるポイントが多くなり、クラスターノード間で適切に同期が行われないおそれがあります。これはパフォーマンスに影響を及ぼすだけでなく、アプリケーションにおける副作用の可能性を考慮に入れる必要も生じます。たとえば、2 つのクラスターノードがネットワークリンクの障害による切断後に再接続した場合、次回の同期プロセスでメッセージが 2 回処理される可能性があり、重複が発生して、アプリケーションロジックで処理する必要が生じます。また、オブジェクトストアを使用しているアプリケーションが、ノード間の通信機能の障害のために整合性のない状態になる可能性もあります。他に発生する可能性のある問題は、複数のノードが「プライマリ」になることです。これは、別々のノードが自身がクラスター内の唯一のノードであると認識することで発生します。 異なるデータセンターに配置されたクラスターのノードを使用でき、必ずしも同じ LAN に配置されている必要はありませんが、いくつか制限事項がある点に注意してください。 この「スプリットブレーン」処理動作を防ぐには、Quorum プロトコルを有効にする必要があります。このプロトコルは、ノードの 1 つのセットがデータの処理を続行し、他のセットが再接続されるまで共有データに関して何も実行しないようにするために使用されます。基本的に、切断が発生した場合、ノードが最も多い方のみが稼働し続けます。たとえば、2 つのデータセンターがあり、一方は 3 つのノードがあり、もう一方には 2 つのノードがあるとします。2 つのノードがあるデータセンターで接続の問題が発生した場合、ノードが 3 つのデータセンターが機能し続け、もう一方のデータセンターは停止します。ノードが 3 つのデータセンターがオフラインになった場合、どちらのノードも機能しなくなります。こうした機能停止を防ぐには、少なくとも 3 つの同じ数のノードを持つデータセンターでクラスターを作成する必要があります。2 つのデータセンターがクラッシュすることは考えにくいため、1 つのデータセンターがオフラインになったり、ネットワーク障害によって他のデータセンターから分離されたりしても、クラスターは常に機能し続けることになります。
機能するのに十分なノードがクラスターパーティションにない場合、外部システムコールに対しては引き続き反応しますが、オブジェクトストアを経由したすべての操作は失敗し、データ生成できなくなります。
#### [](#制限事項)制限事項 - Quorum はオブジェクトストア関連の操作でのみサポートされます。 - 分散ロッキングはサポートされず、以下に影響を及ぼします。 - ファイルの並列に関するファイル/FTP Connector ポーリング - 冪等性再配信ポリシーコンポーネント - 冪等性メッセージ検索条件コンポーネント - メモリ内メッセージングはサポートされず、以下に影響を及ぼします。 - VM Connector - Quorum 機能は手動でのみ設定できます。 - Batch job では高可用性機能は使用されません。 ## [](#クラスタリングと負荷分散)クラスタリングと負荷分散 TCP 要求 (この場合、TCP には SSL/TLS、UDP、Multicast、HTTP、HTTPS が含まれる) に対応するために Mule クラスターが使用される場合、クラスタリングされたインスタンス間で要求を分散するためにある程度の負荷分散が必要になります。Anypoint Runtime Fabric には基盤となる Docker Kubernetes (K8s) インフラストラクチャの一部としてロードバランサー機能が含まれていますが、お客様がホストし、手動でプロビジョニングされたクラスターでは、サードパーティのロードバランサーを提供するか、クライアント側で負荷分散とフェールオーバーを実行する必要があります。 さまざまなソフトウェアのロードバランサーが使用できますが、そのうちの 2 つを紹介します。 - オープンソースの HTTP サーバーおよびリバースプロキシである Nginx。HTTP(S) の負荷分散に NGINX の ​`HttpUpstreamModule`​ を使用できます。 - Apache Web サーバー。これは HTTP(S) ロードバランサーとしても使用できます。 TCP と HTTP または HTTPS トラフィックの両方をルーティングできるハードウェアのロードバランサーも多数あります。 ## [](#cluster-high-performance)高パフォーマンス用のクラスタリング このセクションは、お客様がホストし、手動でプロビジョニングされたクラスターデプロイメントにのみ適用されます。 その他のデプロイメントオプションについての詳細は、​[「デプロイメント戦略」](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)​を参照してください。 (信頼性ではなく) 高パフォーマンスが最大目標の場合は、パフォーマンスプロファイルを使用してパフォーマンスが最大になるように Mule クラスターまたは各アプリケーションを設定できます。クラスター内で特定のアプリケーションのパフォーマンスプロファイルを実装することで、デプロイメントの拡張性を最大にすると同時に、パフォーマンスおよび信頼性の要件が異なるアプリケーションを同じクラスターにデプロイすることができます。コンテナレベルで設定したパフォーマンスプロファイルは、そのコンテナ内のすべてのアプリケーションに適用されます。アプリケーションレベルの設定はコンテナレベルの設定より優先されます。 ### [](#パフォーマンスプロファイルの設定に関する考慮事項)パフォーマンスプロファイルの設定に関する考慮事項 パフォーマンスプロファイルの設定には 2 つの効果があります。 - 分散キューが無効になり、代わりにローカルキューを使用して共有データグリッドにおけるデータの逐次化/非逐次化および分散を防止します。 - バックアップなしでオブジェクトストアを実装し、複製を防止します。
1 つのノードがダウンしたら、そのノードに関連付けられているデータが失われます。
パフォーマンスプロファイルを設定しても、メモリ共有には影響しません。クラスターモードでは、オブジェクトストアはノード間で常に分散し、共有されます。 ### [](#パフォーマンスプロファイルの設定)パフォーマンスプロファイルの設定 _コンテナ_​レベルでパフォーマンスプロファイルを設定するには、次のコマンドを ​`mule-cluster.properties`​、システムプロパティ (コマンドラインから)、または ​`wrapper.conf`​ に追加します。 `mule.cluster.storeprofile=performance` _個別のアプリケーション_​レベルでパフォーマンスプロファイルを設定するには、以下で示しているように、設定ラッパー内にプロファイルを追加します。 - パフォーマンスストアプロファイル ```xml ``` アプリケーションレベルの設定はコンテナレベルの設定より優先されます。高パフォーマンス用にコンテナを設定するが、そのコンテナ内の 1 つ以上の個別のアプリケーションでは信頼性を優先するには、こうしたアプリケーションに次のコードを含めます。 - 信頼性ストアプロファイル ```xml ```

負荷分散をサポートしないエンドポイントで負荷が大きい場合、パフォーマンスプロファイルを適用するとパフォーマンスが低下する場合もあります。非同期処理戦略、ロードバランサーがない JMS トピック、マルチキャスト、または HTTP Connector でファイルベースのコネクタを使用している場合、大量のメッセージが単一ノードに入るとボトルネックが発生する可能性があるため、こうしたアプリケーションのパフォーマンスプロファイルを無効にしたほうがパフォーマンスが向上する場合があります。
稼働状態を保つためにクラスターで必要なマシンの最小数を定義することもできます。この設定により、パフォーマンス全体での一貫性が改善されます。 ## [](#クラスターノード間の通信の暗号化)クラスターノード間の通信の暗号化 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルでまたはシステムプロパティとして定義することで、クラスターノード間のトラフィックを暗号化できます。 暗号化鍵を定義すると、定義した鍵と AES 暗号化アルゴリズムを使用してクラスターノード間のすべての通信が暗号化されます。 ## [](#cluster_fips)FIPS モードでのクラスタリングの有効化 FIPS モードでのクラスタリングを有効化するには、次のタスクを完了します。 - FIPS モードで Mule Runtime Engine を実行します。 設定の手順は、​[「FIPS コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.4/fips-140-2-compliance-support)​を参照してください。 - クラスターノード間の通信を暗号化します。 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルで定義するか、システムプロパティとして定義します。 ### [](#警告)警告 - 暗号化鍵を定義しない場合、アプリケーションはデプロイに失敗し、​`Cluster key must be defined in FIPS mode.`​ というメッセージが表示されます。 - クラスタリングされたすべてのノードで同じ暗号化鍵を使用しない場合、この機能は動作しません。 - FIPS モードでクラスタリングされた環境を実行すると、ノード間のすべての通信が暗号化 (および復号化) されるため、パフォーマンスが低下します。 ## [](#クラスタリングのベストプラクティス)クラスタリングのベストプラクティス クラスタリングに関しては多くの推奨事項があります。例を挙げます。 - できるだけアプリケーションを一連のステップに整理し、各ステップがメッセージを 1 つのトランザクションストアから別のトランザクションストアに移動するようにします。 - アプリケーションで非トランザクションコネクタからのメッセージを処理する場合、​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.4/reliability-patterns)​を使用して VM や JMS ストアなどのトランザクションストアに移動します。 - トランザクションを使用してトランザクションコネクタからのメッセージを処理します。これにより、エラーが発生した場合、メッセージが再処理されるようになります。 - VM や JMS Connector で使用するような分散ストアを使用します。こうしたストアはクラスター全体に対して使用可能です。これは、ファイル、FTP、JDBC などのコネクタで使用する非分散ストアよりも優れています。こうしたストアは一度に単一のノードによって読み取られます。 - VM Connector を使用して最適なパフォーマンスを得ます。クラスター全体が終了した後にデータを保存する必要があるアプリケーションに JMS Connector を使用します。 - 高信頼性アプリケーションを作成するには信頼性パターンを実装します。 - HA クラスターモードでは、すべてのオブジェクトストアコンテンツ (メモリ内コンテンツと、​`persistent`​ パラメーターで定義される永続的なコンテンツの両方) は、分散メモリグリッドに保存されます。クラスターでクォーラムが保持されている限り、このデータはアプリケーションの再デプロイまたは再起動後も存続します。オブジェクトストアコンテンツを完全にクリアするには、再起動する前にすべてのクラスターノードを停止する必要があります。クラスターの完全シャットダウン後もデータの永続性が必要なシナリオでは、メモリグリッドの代わりに JDBC ベースのストアを使用するようにオブジェクトストアを設定します。​[「オブジェクトストアの永続性」](https://docs.mulesoft.com/jp/mule-runtime/4.4/creating-and-managing-a-cluster-manually#object-store-persistence)​を参照してください。 ## [](#関連情報)関連情報 - [Enterprise ライセンスのインストール](https://docs.mulesoft.com/jp/mule-runtime/4.4/installing-an-enterprise-license) - [サーバーの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-servers#create-a-cluster) - [CloudHub 高可用性および障害回復](https://docs.mulesoft.com/cloudhub/cloudhub-hadr) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/creating-and-managing-a-cluster-manually) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management) - [クォーラム管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/creating-and-managing-a-cluster-manually#quorum-management) # Mule Runtime 高可用性 (HA) クラスターの概要
CloudHub でのクラスタリングに相当するものの場合、アプリケーションを拡大し、高可用性を提供するためにワーカーを共有または二重化する方法の詳細は、​CloudHub 高可用性​を参照してください。
Mule Enterprise Edition は拡張可能なクラスタリングをサポートし、アプリケーションの高可用性 (HA) を実現しています。 クラスターとは、ユニットとして機能する Mule Runtime Engine のセットです。言い換えると、クラスターとは複数のノード (Mule Runtime Engine) で構成された仮想サーバーです。クラスター内のノードは分散された共有メモリグリッドを通じて通信を行い、オブジェクトストアと VM キューのデータを共有します。つまり、データがさまざまなマシンのメモリ間で複製されます。 この複製された状態の共有メモリグリッドは、次のものに適用されます。 - 永続的または非永続的なオブジェクトストア - 永続的または一時的な VM キュー - Mule Runtime LockFactory ![クラスター](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/cluster.png)
この機能の価格については、カスタマーサービス担当者にお問い合わせください。
## [](#クラスタリングの利点)クラスタリングの利点 デフォルトでは、Mule Runtime Engine のクラスタリングにより、システムの高可用性を実現できます。障害や計画的なダウンタイムが原因で Mule Runtime Engine ノードが使用不可になった場合、クラスター内の別のノードがワークロードを引き継ぎ、VM キューからのメッセージの処理やその他の要求のサービスを続行できます。次の図は、2 ノードのクラスターによる受信メッセージの処理を示しています。処理負荷がノード間で分散されているのがわかります。ノード 1 がメッセージ 1 を処理するのと同時に、ノード 2 はメッセージ 2 を処理します。 ![FailoverNoFail](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/failovernofail.png) 一方のノードで障害が発生した場合、もう一方の障害の発生していないノードが障害の発生しているノードの作業を引き継ぎます。外部ロードバランサーが障害の発生しているノードのトラフィックをアクティブなノードにリダイレクトするか、VM キューを通じてアクティブなノードがインフライトメッセージの処理を続行できるようにします。次の図で示しているように、ノード 2 で障害が発生した場合、ノード 1 はメッセージ 1 とメッセージ 2 の両方を処理します。 ![FailoverNode2Fail](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/failovernode2fail.png) Mule Runtime Engine のクラスターではすべてのノードが同時に「アクティブ-アクティブ」になりメッセージを処理できるため、クラスターによってパフォーマンスおよび拡張性も向上します。単一ノードのインスタンスと比較すると、クラスターのほうがサポートできるユーザーも多く、ワークロードを複数のノードで共有するかノードをクラスターに追加することで、アプリケーションのパフォーマンスも向上できます。アプリケーションによっては水平方向にスケーリングまたはクラスタリングを行ってもパフォーマンスが向上しないものもあります。パフォーマンスは追加ノードと共有される作業の性質によって異なります。オブジェクトストアを多用するアプリケーションの中には、共有メモリグリッド内のデータの複製やアクセスの調整に必要な作業のために、パフォーマンスが低下するものもあります。 次の図では、ワークロードの共有をより詳しく示しています。両方のノードが受注処理に関するメッセージを処理します。ただし、一方のノードの負荷が大きい場合、その処理の 1 つ以上のステップの処理をもう一方のノードに移動できます。ここでは、割引処理ステップの処理がノード 1 に移動され、受注ステップの処理がノード 2 に移動されています。 ![クラスター図](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/cluster-diagram.png) 自動フェールオーバーによる高可用性、パフォーマンスの向上、拡張性の向上以外に、Mule Runtime Engine のクラスタリングには次のような利点があります。 - ファイル、データベース、FTP ソースなどのリソースへのアクセスの自動調整。 Mule Runtime Engine クラスターは、どのノード (Mule Runtime Engine) がデータソースからの通信を処理するかを自動的に管理します。 - クラスター内の処理の自動負荷分散。 フローを一連のステップに分割してこれらのステップを VM などのコネクタと接続すると、各ステップはキューに入り、クラスターが有効になります。続いて、Mule Runtime Engine のクラスターが任意のノードで各ステップを処理し、ノード間で負荷がより効率的に分散されます。 - アラートの生成。 ノードがダウンした場合やノードが復活したときに表示されるアラートをセットアップできます。
クラスターのすべての Mule Runtime Engine はアクティブにメッセージを処理します。各 Mule ノードは垂直方向にも拡張可能です。単一のノードでも複数のコアや追加メモリを活用することで拡張できます。Mule は複数のコアを使用する場合であっても、クラスターでは単一のノードとして動作します。
### [](#クラスターによって解決される同時実行の問題)クラスターによって解決される同時実行の問題 クラスターとしてバインドされていない複数のサーバーで構成されたサーバーグループがある場合、次のような問題が存在する可能性があります。サーバーをクラスターとしてグループ化すれば、こうした問題に頭を悩ませることはありません。 - ファイルベースのコネクタ。 すべての Mule インスタンスは同じ Mule ファイルフォルダーに同時にアクセスするため、ファイル処理が重複することもあれば、ファイルが Mule アプリケーションによって削除または変更された場合には障害が発生する可能性もあります。 - マルチキャストコネクタ。 すべての Mule インスタンスは同じ TCP 要求を受けてから重複メッセージを処理します。 - JMS トピック。 すべての Mule インスタンスは同じ JMS トピックに接続するため、非クラスタリング Mule インスタンスを水平方向に拡張した場合、メッセージの処理が反復される場合もあります。JMS ブローカーからは、インスタンスは別々のサブスクライバーのように見え、そのすべてが各メッセージのコピーを取得します。この動作が必要となるのはまれです。このシナリオを避けるために、「共有サブスクライバー」設定を使用できます。この設定によって、JMS ブローカーに、すべてのインスタンスを結合サブスクライバーとして扱い、それぞれ別個のメッセージを与えるように指示できます。 - JMS request-reply (要求-返信)/request-response (要求-応答)。 すべての Mule インスタンスは同じ応答キューでメッセージをリスンします。これは、Mule インスタンスが送信した要求に相関していない応答を受け取る可能性があり、結果として不正な応答になったりフローがタイムアウトにより失敗したりする場合があることを意味します。 - 冪等性再配信ポリシーと冪等性メッセージ検証。 水平スケーリングで同じ要求を異なる Mule インスタンスが受信し、再配信ポリシーまたは Idempotency Message Validator で使用されるオブジェクトストアコンテンツがローカライズされている場合、冪等性が正しく機能しません。このような冪等性機能で使用されるオブジェクトストア値を共有するクラスターの場合、すべてのノードがすでに処理済みの識別子のリストを共有しているため、メッセージの重複は起こり得ません。 - Salesforce ストリーミング API。 同じアプリケーションの複数のインスタンスをデプロイした場合、API は単一コンシューマーしかサポートしていないため、失敗します。接続されているインスタンスが停止またはクラッシュした場合のフェールオーバーのサポートはありません。 ## [](#前提条件)前提条件 - クラスターには少なくとも 2 個の Mule Runtime Engine インスタンスが必要であり、マシン上で障害が 1 か所に集中することを防ぐため、それぞれを異なるマシンで実行する必要があります。 - Mule 高可用性 (HA) では、クラスターのノード間の同期を維持するために、サーバー間に信頼性の高いネットワーク接続が必要です。 - Mule クラスター用に設定されたポートを開いたままにします。 - Runtime Manager を使用してクラスターを設定し、デフォルトポートを使用する場合、TCP ポート ​`5701`​、​`5702`​、および ​`5703`​ を開いたままにします。 - 代わりにカスタムポートを設定する場合、カスタムポートを開いたままにします。 - ポート ​`5701`​ を介してノード間の通信が開いていることを確認します。 ネットワーク内のファイアウォールルールを検証して、ノード間の双方向通信が有効になっていることを確認します。 クラスターでマルチキャストを有効にする場合、前述の前提条件に加えて次の要件も適用されます。 - UDP ポート ​`54327`​ を開いたままにします。 - マルチキャスト IP アドレス ​`224.2.2.3`​ を有効にします。 ## [](#高可用性)高可用性 高可用性とは、そこで実行されるアプリケーションのダウンタイムを防止するようにコンピューターシステムをデザインする方法です。一部のシステムでは 1 台のサーバーでダウンタイムが発生しても、アプリケーションはアプリケーションのエンドユーザーに対するサービスの提供を中断することなく他のサーバーでスムーズに実行し続けることができるように、複数のサーバーを使用しています。 ## [](#クラスターのデザインと管理)クラスターのデザインと管理 Anypoint Runtime Manager は、Mule インスタンスの顧客がホストするクラスターをセットアップしてアプリケーションをデプロイしてクラスターで実行できるようにします。クラスターおよび個別のノードの状況に関する情報を監視することもできます。クラスタリングを行うと、複数のサーバーを 1 台として容易に管理できます。
クラスター管理についての詳細は、Runtime Manager の​「Managing Servers (サーバーの管理)」​を参照してください。
Anypoint Runtime Fabric では、デプロイメント時に Mule Runtime レプリカをクラスターモードでプロビジョニングするオプションがあります。 Mule クラスターは、2 つ以上の Mule Runtime Engine、またはノードで構成され、グループにまとめられて単一ユニットとして扱われます。初期設定の場合、クラスターの拡張は 8 個の Mule Runtime Engine までにすることをお勧めします。 Anypoint Runtime Manager を使用すれば、クラスター内のすべての Mule Runtime Engine を単一の Mule Runtime Engine であるかのようにデプロイ、監視、および停止することができます。 注意: CloudHub ではプロビジョンされたワーカーにこのクラスタリング設定を使用しませんが、同等の環境を提供する他の高可用性機能があります。たとえば、Anypoint Object Store (OSv2) を介した外部化された状態管理や、永続的なキュー配置機能 (VM キューをワーカーの外部に移すことで、共有可能にして再プロビジョニングの際も存続するようにする) などです。 次に示すように、クラスター内のすべてのノードはメモリを共有します。 ![topology\_4-cluster](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/topology-4-cluster.png)
動作のパフォーマンスを確保するために、Mule は active-active (アクティブ-アクティブ) モデルを使用して Mule Runtime Engine をクラスタリングします。active-passive (アクティブ-パッシブ) モデルに対するこのモデルのメリットは、アプリケーションがすべてのノードで実行され、メッセージ処理をクラスター内の他のノードと分け合うことで、処理を効率化できることです。
### [](#プライマリノードの違い)プライマリノードの違い active-active (アクティブ-アクティブ) モデルでは、すべてのノードが処理を実行できます。ただし、いずれか 1 つのノードがプライマリノードとして機能し、スケジューラーやその他の「プライマリノードのみ」とマークされているイベントソースを実行します。このモデルでは、クラスター内の 1 つのプライマリポーリングノードでソースが実行され、クラスター内の他のノードはそれらのソースからのメッセージを読めないように設定できます。 この機能は、ソース種別に応じて異なります。 - スケジューラーソース: プライマリポーリングノードでのみ実行されます。 - 他のソース: `primaryNodeOnly`​ 属性で定義されます。そのコネクタの ​`primaryNodeOnly`​ のデフォルト値を調べるには、各コネクタのドキュメントを確認してください。 JMS の設定例: ```xml ``` この例は、逐次/一度に 1 つのメッセージの処理が必要な状況でアプリケーションが JMS からメッセージを受信するユースケースのものと考えられます。JMS Connector の On New Message ソースのデフォルト設定では、デフォルトで \[Primary Node Only (プライマリノードのみ)\] が選択されていますが、ほとんどのコネクタソースでは \[Primary Node Only (プライマリノードのみ)\] は選択されていません。デフォルト設定の決定はコネクタの開発者が行います。すべてのノードで処理を実行する必要があるユースケースでは、開発者はすべてのクラスターノードでソースが有効になるように primaryNodeOnly 値の選択を解除します。 ## [](#queues)Queues コードの実行とフロー参照によるフローのコールは、イベントの実行が開始されたのと同じノードで行われます。ただし、クラスター化された Mule Runtime で実行を共有または分散するために、VM キューをセットアップして VM キューに明示的にパブリッシュすることでノード間で負荷を分散できます。永続的な VM キューと一時的な VM キューのいずれでもクラスターの共有メモリグリッドが使用され、VM キューを介したあらゆる移行は別のアクティブなノードにジャンプする可能性があります。そのため、アプリケーションフロー全体に VM キューのパブリッシャー/リスナーによってリンクされた子フローのシーケンスが含まれる場合、クラスターは連続する各子フローをその時点で使用可能な任意の Mule Runtime Engine に割り当てることができます。下で示しているように、クラスターはアプリケーションフローの VM キューを通過するときに複数のノードで単一メッセージを処理することもできます。 ![load\_balancing](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/load-balancing.png) ## [](#高信頼性アプリケーション)高信頼性アプリケーション 高信頼性アプリケーションと言えるには、以下の要件を満たす必要があります。 1. メッセージの損失の許容がゼロであること 2. インテグレーションエンジン (Mule) が信頼できること 3. 個別の接続の信頼性が高いこと トランザクション性として知られる機能はアプリケーションイベントシーケンスを追跡し、それぞれのメッセージ処理ステップが正常に完了するようにします。そのため、失われたり不正に処理されたりするメッセージはありません。何らかの理由でステップが失敗した場合、トランザクションメカニズムが以前の処理イベントをすべてロールバックし、メッセージ処理シーケンスを再開します。 JMS、VM、JDBC などのコネクタにより、ビルトイントランザクションサポートが提供されるため、メッセージが確実に処理されるようになります。たとえば、トランザクションがコミットされた後でのみメッセージを JMS サーバーから削除するようにインバウンド JMS 接続エンドポイントでトランザクションを設定できます。この方法により、処理フロー中にエラーが発生した場合、元のメッセージは再処理できる状態で保持されます。 トランザクションをサポートする異種コネクタ間でメッセージを移動するには、XA トランザクションを使用する必要があります。これにより、Mule Runtime Engine はすべての異種コネクタの関連付けられたトランザクションを単一ユニットとしてコミットするようになります。
トランザクションは、コネクタがトランザクションをサポートしないシステムでのインタラクションや操作を対象とすることはできません。そのため、関連する操作の中にトランザクションに含めることができないものがある場合には、 Sagas​ などの代替パターンを代わりに使用します。
## [](#コネクタのクラスターサポート)コネクタのクラスターサポート すべての Mule Connector がクラスター内でサポートされます。コネクタごとにインバウンドトラフィックにアクセスする方法が異なるため、このサポートの詳細は異なります。一般に、アウトバウンドトラフィックはクラスター内外で同じように機能します。Mule Runtime は 3 つの基本的な種別のコネクタをサポートしています。 ### [](#ソケットベースのコネクタ)ソケットベースのコネクタ ソケットベースのコネクタは Mule が所有するネットワークソケットに送信された入力を読み取ります。例としては TCP、UDP、HTTP\[S\] などがあります。 ソケットベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - クラスタリングされた各 Mule Runtime は異なるネットワークノードで実行されるため、各インスタンスはそのノードに送信されたソケットベースのトラフィックのみを受信します。受信したソケットベースのトラフィックは、クラスタリングされたインスタンス間で分散するために​[\[Clustering and Load Balancing\]](<#Clustering and Load Balancing>)​を実行する必要があります。 - ソケットベースのコネクタへの出力は特定のホスト/ポートの組み合わせに書き込まれます。ホスト/ポートの組み合わせが外部ホストの場合、特に考慮事項はありません。ローカルホストのポートの場合、クラスター間でより効率的にトラフィックを分散するために、代わりにロードバランサーでそのポートを使用することを検討してください。 ### [](#リスナーベースのコネクタ)リスナーベースのコネクタ リスナーベースのコネクタは同時の複数アクセサーを十分にサポートするプロトコルを使用してデータを読み取ります。例としては、JMS や VM があります。 リスナーベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - リスナーベースのコネクタは複数のリーダーおよびライターを完全にサポートしています。入力にも出力にも特に考慮事項はありません。 - クラスターでは、VM Connector キュー (永続的と一時的の両方) が共有のクラスター全体のリソースである点に注意してください。クラスターは VM Connector キューへのアクセスを自動的に同期します。そのため、任意のクラスターノードで VM キューに書き込まれたメッセージを処理できます。これにより、VM はクラスターノード間でワークを共有するのに最適です。 ### [](#リソースベースのコネクタ)リソースベースのコネクタ リソースベースのコネクタは複数の同時アクセサーは使用可能だがリソースの使用をネイティブに調整しないリソースからデータを読み取ります。リソースベースのコネクタの例としては、ファイル、FTP、SFTP、メール、JDBC などがあります。 リソースベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - Mule HA クラスタリングは自動的にクラスター内のノードのみについて各リソースへのアクセスを調整するため、クラスタリングされたインスタンスのうち 1 つだけが一度に各リソースにアクセスするようになります。そのため、通常はリソースベースのコネクタから読み取られたメッセージをすぐに VM キューに書き込むことをお勧めします。これにより、他のクラスターノードがメッセージの処理に参加できます。

クラスター内のノードとして同じリソースにアクセスする他のアプリケーション (クラスター外の Mule アプリケーションまたは Mule 以外のアプリケーション) を実行する場合は、これらのリソースをロックするロジックを実装する必要があります。

たとえば、複数のプログラムがファイルの読み取り、変更、そして削除を行うことで、同じ共有ディレクトリのファイルを処理しているとします。これらのプログラムは明示的なアプリケーションレベルのロッキング戦略を使用して、同じファイルが複数回処理されないようにする必要があります。
- リソースベースのクラスタリングされたコネクタへの書き込みには特に考慮事項はありません。 - ファイルベースのコネクタ (ファイル、FTP、SFTP) に書き込むときに、Mule は一意のファイル名を生成します。 - JDBC に書き込むときに、Mule は一意のキーを生成できます。 - メールの作成は、実質的にはリソースベースではなくリスナーベースです。 ## [](#クラスタリングと信頼性の高いアプリケーション)クラスタリングと信頼性の高いアプリケーション 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。クラスターで十分に信頼できるアプリケーションをビルドするためのツールは​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.5/reliability-patterns)​で見つかります。 アプリケーションで非トランザクションコネクタを使用している場合、信頼性パターンに従ってください。これらのパターンにより、メッセージが受け入れられて正常に処理されるか、「失敗」応答を生成してクライアントが再試行できるようになります。 アプリケーションで JMS、VM、JDBC などのトランザクションコネクタを使用している場合は、トランザクションを使用します。トランザクションコネクタに対する Mule のビルトインサポートにより、こうしたコネクタを使用するアプリケーションで信頼性の高いメッセージングを実現できます。 これらのアクションは、クラスタリングされていないアプリケーションにも適用できます。 ## [](#クラスタリングとネットワーキング)クラスタリングとネットワーキング ### [](#単一のデータセンターのクラスタリング)単一のデータセンターのクラスタリング クラスターノード間で信頼性のある接続を確立するには、クラスターのすべてのノードを同じ LAN に配置する必要があります。VPN を通じて接続された異なるデータセンターなど、地理的に離れた場所にノードが含まれるクラスターを実装することも可能ですが、お勧めはしません。 ネットワークの中断や、メッセージの重複などの意図しない結果を招く可能性を下げるためには、すべてのクラスターノードを同じ LAN に配置するのが最もお勧めです。 ### [](#分散型データセンターのクラスタリング)分散型データセンターのクラスタリング WAN ネットワークを使用してクラスターノードをリンクすると、外部ルーターやファイアウォールなど、障害が発生する可能性のあるポイントが多くなり、クラスターノード間で適切に同期が行われないおそれがあります。これはパフォーマンスに影響を及ぼすだけでなく、アプリケーションにおける副作用の可能性を考慮に入れる必要も生じます。たとえば、2 つのクラスターノードがネットワークリンクの障害による切断後に再接続した場合、次回の同期プロセスでメッセージが 2 回処理される可能性があり、重複が発生して、アプリケーションロジックで処理する必要が生じます。また、オブジェクトストアを使用しているアプリケーションが、ノード間の通信機能の障害のために整合性のない状態になる可能性もあります。他に発生する可能性のある問題は、複数のノードが「プライマリ」になることです。これは、別々のノードが自身がクラスター内の唯一のノードであると認識することで発生します。 異なるデータセンターに配置されたクラスターのノードを使用でき、必ずしも同じ LAN に配置されている必要はありませんが、いくつか制限事項がある点に注意してください。 この「スプリットブレーン」処理動作を防ぐには、Quorum プロトコルを有効にする必要があります。このプロトコルは、ノードの 1 つのセットがデータの処理を続行し、他のセットが再接続されるまで共有データに関して何も実行しないようにするために使用されます。基本的に、切断が発生した場合、ノードが最も多い方のみが稼働し続けます。たとえば、2 つのデータセンターがあり、一方は 3 つのノードがあり、もう一方には 2 つのノードがあるとします。2 つのノードがあるデータセンターで接続の問題が発生した場合、ノードが 3 つのデータセンターが機能し続け、もう一方のデータセンターは停止します。ノードが 3 つのデータセンターがオフラインになった場合、どちらのノードも機能しなくなります。こうした機能停止を防ぐには、少なくとも 3 つの同じ数のノードを持つデータセンターでクラスターを作成する必要があります。2 つのデータセンターがクラッシュすることは考えにくいため、1 つのデータセンターがオフラインになったり、ネットワーク障害によって他のデータセンターから分離されたりしても、クラスターは常に機能し続けることになります。
機能するのに十分なノードがクラスターパーティションにない場合、外部システムコールに対しては引き続き反応しますが、オブジェクトストアを経由したすべての操作は失敗し、データ生成できなくなります。
#### [](#制限事項)制限事項 - Quorum はオブジェクトストア関連の操作でのみサポートされます。 - 分散ロッキングはサポートされず、以下に影響を及ぼします。 - ファイルの並列に関するファイル/FTP Connector ポーリング - 冪等性再配信ポリシーコンポーネント - 冪等性メッセージ検索条件コンポーネント - メモリ内メッセージングはサポートされず、以下に影響を及ぼします。 - VM Connector - Quorum 機能は手動でのみ設定できます。 - 一括処理ジョブでは高可用性機能が使用されません。 ## [](#クラスタリングと負荷分散)クラスタリングと負荷分散 TCP 要求 (この場合、TCP には SSL/TLS、UDP、Multicast、HTTP、HTTPS が含まれる) に対応するために Mule クラスターが使用される場合、クラスタリングされたインスタンス間で要求を分散するためにある程度の負荷分散が必要になります。Anypoint Runtime Fabric には基盤となる Docker Kubernetes (K8s) インフラストラクチャの一部としてロードバランサー機能が含まれていますが、お客様がホストし、手動でプロビジョニングされたクラスターでは、サードパーティのロードバランサーを提供するか、クライアント側で負荷分散とフェールオーバーを実行する必要があります。 さまざまなソフトウェアのロードバランサーが使用できますが、そのうちの 2 つを紹介します。 - オープンソースの HTTP サーバーおよびリバースプロキシである Nginx。HTTP(S) の負荷分散に NGINX の ​`HttpUpstreamModule`​ を使用できます。 - Apache Web サーバー。これは HTTP(S) ロードバランサーとしても使用できます。 TCP と HTTP または HTTPS トラフィックの両方をルーティングできるハードウェアのロードバランサーも多数あります。 ## [](#cluster-high-performance)高パフォーマンス用のクラスタリング このセクションは、お客様がホストし、手動でプロビジョニングされたクラスターデプロイメントにのみ適用されます。 その他のデプロイメントオプションについての詳細は、​[「デプロイメント戦略」](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)​を参照してください。 (信頼性ではなく) 高パフォーマンスが最大目標の場合は、パフォーマンスプロファイルを使用してパフォーマンスが最大になるように Mule クラスターまたは各アプリケーションを設定できます。クラスター内で特定のアプリケーションのパフォーマンスプロファイルを実装することで、デプロイメントの拡張性を最大にすると同時に、パフォーマンスおよび信頼性の要件が異なるアプリケーションを同じクラスターにデプロイすることができます。コンテナレベルで設定したパフォーマンスプロファイルは、そのコンテナ内のすべてのアプリケーションに適用されます。アプリケーションレベルの設定はコンテナレベルの設定より優先されます。 ### [](#パフォーマンスプロファイルの設定に関する考慮事項)パフォーマンスプロファイルの設定に関する考慮事項 パフォーマンスプロファイルの設定には 2 つの効果があります。 - 分散キューが無効になり、代わりにローカルキューを使用して共有データグリッドにおけるデータの逐次化/非逐次化および分散を防止します。 - バックアップなしでオブジェクトストアを実装し、複製を防止します。
1 つのノードがダウンしたら、そのノードに関連付けられているデータが失われます。
パフォーマンスプロファイルを設定しても、メモリ共有には影響しません。クラスターモードでは、オブジェクトストアはノード間で常に分散し、共有されます。 ### [](#パフォーマンスプロファイルの設定)パフォーマンスプロファイルの設定 _コンテナ_​レベルでパフォーマンスプロファイルを設定するには、次のコマンドを ​`mule-cluster.properties`​、システムプロパティ (コマンドラインから)、または ​`wrapper.conf`​ に追加します。 `mule.cluster.storeprofile=performance` _個別のアプリケーション_​レベルでパフォーマンスプロファイルを設定するには、以下で示しているように、設定ラッパー内にプロファイルを追加します。 - パフォーマンスストアプロファイル ```xml ``` アプリケーションレベルの設定はコンテナレベルの設定より優先されます。高パフォーマンス用にコンテナを設定するが、そのコンテナ内の 1 つ以上の個別のアプリケーションでは信頼性を優先するには、こうしたアプリケーションに次のコードを含めます。 - 信頼性ストアプロファイル ```xml ```

負荷分散をサポートしないエンドポイントで負荷が大きい場合、パフォーマンスプロファイルを適用するとパフォーマンスが低下する場合もあります。非同期処理戦略、ロードバランサーがない JMS トピック、マルチキャスト、または HTTP Connector でファイルベースのコネクタを使用している場合、大量のメッセージが単一ノードに入るとボトルネックが発生する可能性があるため、こうしたアプリケーションのパフォーマンスプロファイルを無効にしたほうがパフォーマンスが向上する場合があります。
稼働状態を保つためにクラスターで必要なマシンの最小数を定義することもできます。この設定により、パフォーマンス全体での一貫性が改善されます。 ## [](#クラスターノード間の通信の暗号化)クラスターノード間の通信の暗号化 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルでまたはシステムプロパティとして定義することで、クラスターノード間のトラフィックを暗号化できます。 暗号化キーを定義すると、定義したキーと AES 暗号化アルゴリズムを使用してクラスターノード間のすべての通信が暗号化されます。 ## [](#cluster_fips)FIPS モードでのクラスタリングの有効化 FIPS モードでのクラスタリングを有効化するには、次のタスクを完了します。 - FIPS モードで Mule Runtime Engine を実行します。 設定の手順は、​[「FIPS コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.5/fips-140-2-compliance-support)​を参照してください。 - クラスターノード間の通信を暗号化します。 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルで定義するか、システムプロパティとして定義します。 ### [](#警告)警告 - 暗号化キーを定義しない場合、アプリケーションはデプロイに失敗し、​`Cluster key must be defined in FIPS mode.`​ というメッセージが表示されます。 - クラスタリングされたすべてのノードで同じ暗号化キーを使用しない場合、この機能は動作しません。 - FIPS モードでクラスタリングされた環境を実行すると、ノード間のすべての通信が暗号化 (および復号化) されるため、パフォーマンスが低下します。 ## [](#クラスタリングのベストプラクティス)クラスタリングのベストプラクティス クラスタリングに関しては多くの推奨事項があります。例を挙げます。 - できるだけアプリケーションを一連のステップに整理し、各ステップがメッセージを 1 つのトランザクションストアから別のトランザクションストアに移動するようにします。 - アプリケーションで非トランザクションコネクタからのメッセージを処理する場合、​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.5/reliability-patterns)​を使用して VM や JMS ストアなどのトランザクションストアに移動します。 - トランザクションを使用してトランザクションコネクタからのメッセージを処理します。これにより、エラーが発生した場合、メッセージが再処理されるようになります。 - VM や JMS Connector で使用するような分散ストアを使用します。こうしたストアはクラスター全体に対して使用可能です。これは、ファイル、FTP、JDBC などのコネクタで使用する非分散ストアよりも優れています。こうしたストアは一度に単一のノードによって読み取られます。 - VM Connector を使用して最適なパフォーマンスを得ます。クラスター全体が終了した後にデータを保存する必要があるアプリケーションに JMS Connector を使用します。 - 高信頼性アプリケーションを作成するには信頼性パターンを実装します。 - HA クラスターモードでは、すべてのオブジェクトストアコンテンツ (メモリ内コンテンツと、​`persistent`​ パラメーターで定義される永続的なコンテンツの両方) は、分散メモリグリッドに保存されます。クラスターでクォーラムが保持されている限り、このデータはアプリケーションの再デプロイまたは再起動後も存続します。オブジェクトストアコンテンツを完全にクリアするには、再起動する前にすべてのクラスターノードを停止する必要があります。クラスターの完全シャットダウン後もデータの永続性が必要なシナリオでは、メモリグリッドの代わりに JDBC ベースのストアを使用するようにオブジェクトストアを設定します。​[「オブジェクトストアの永続性」](https://docs.mulesoft.com/jp/mule-runtime/4.5/creating-and-managing-a-cluster-manually#object-store-persistence)​を参照してください。 ## [](#関連情報)関連情報 - [Enterprise ライセンスのインストール](https://docs.mulesoft.com/jp/mule-runtime/4.5/installing-an-enterprise-license) - [サーバーの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-servers#create-a-cluster) - [CloudHub 高可用性および障害回復](https://docs.mulesoft.com/cloudhub/cloudhub-hadr) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/creating-and-managing-a-cluster-manually) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management) - [クォーラム管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/creating-and-managing-a-cluster-manually#quorum-management) # Mule Runtime 高可用性 (HA) クラスターの概要
CloudHub でのクラスタリングに相当するもの場合、アプリケーションを拡大し、高可用性を提供するためにワーカーを共有または二重化する方法の詳細は、​CloudHub 高可用性​を参照してください。
Mule Enterprise Edition は拡張可能なクラスタリングをサポートし、オンプレミスアプリケーションの高可用性 (HA) を実現しています。 クラスターとは、ユニットとして機能する Mule Runtime Engine のセットです。言い換えると、クラスターとは複数のノード (Mule Runtime Engine) で構成された仮想サーバーです。クラスター内のノードは分散された共有メモリグリッドを通じて通信を行い、オブジェクトストアと VM キューのデータを共有します。つまり、データがさまざまなマシンのメモリ間で複製されます。 この複製された状態の共有メモリグリッドは、次のものに適用されます。 - 永続的または非永続的なオブジェクトストア - 永続的または一時的な VM キュー - Mule Runtime LockFactory ![クラスター](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/cluster.png)
この機能の価格については、カスタマーサービス担当者にお問い合わせください。
## [](#クラスタリングの利点)クラスタリングの利点 デフォルトでは、Mule Runtime Engine のクラスタリングにより、システムの高可用性を実現できます。障害や計画的なダウンタイムが原因で Mule Runtime Engine ノードが使用不可になった場合、クラスター内の別のノードがワークロードを引き継ぎ、VM キューからのメッセージの処理やその他の要求のサービスを続行できます。次の図は、2 ノードのクラスターによる受信メッセージの処理を示しています。処理負荷がノード間で分散されているのがわかります。ノード 1 がメッセージ 1 を処理するのと同時に、ノード 2 はメッセージ 2 を処理します。 ![FailoverNoFail](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/failovernofail.png) 一方のノードで障害が発生した場合、もう一方の障害の発生していないノードが障害の発生しているノードの作業を引き継ぎます。外部ロードバランサーが障害の発生しているノードのトラフィックをアクティブなノードにリダイレクトするか、VM キューを通じてアクティブなノードがインフライトメッセージの処理を続行できるようにします。次の図で示しているように、ノード 2 で障害が発生した場合、ノード 1 はメッセージ 1 とメッセージ 2 の両方を処理します。 ![FailoverNode2Fail](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/failovernode2fail.png) Mule Runtime Engine のクラスターではすべてのノードが同時に「アクティブ-アクティブ」になりメッセージを処理できるため、クラスターによってパフォーマンスおよび拡張性も向上します。単一ノードのインスタンスと比較すると、クラスターのほうがサポートできるユーザーも多く、ワークロードを複数のノードで共有するかノードをクラスターに追加することで、アプリケーションのパフォーマンスも向上できます。アプリケーションによっては水平方向にスケーリングまたはクラスタリングを行ってもパフォーマンスが向上しないものもあります。パフォーマンスは追加ノードと共有される作業の性質によって異なります。オブジェクトストアを多用するアプリケーションの中には、共有メモリグリッド内のデータの複製やアクセスの調整に必要な作業のために、パフォーマンスが低下するものもあります。 次の図では、ワークロードの共有をより詳しく示しています。両方のノードが受注処理に関するメッセージを処理します。ただし、一方のノードの負荷が大きい場合、その処理の 1 つ以上のステップの処理をもう一方のノードに移動できます。ここでは、割引処理ステップの処理がノード 1 に移動され、受注ステップの処理がノード 2 に移動されています。 ![クラスター図](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/cluster-diagram.png) 自動フェールオーバーによる高可用性、パフォーマンスの向上、拡張性の向上以外に、Mule Runtime Engine のクラスタリングには次のような利点があります。 - ファイル、データベース、FTP ソースなどのリソースへのアクセスの自動調整。 Mule Runtime Engine クラスターは、どのノード (Mule Runtime Engine) がデータソースからの通信を処理するかを自動的に管理します。 - クラスター内の処理の自動負荷分散。 フローを一連のステップに分割してこれらのステップを VM などのコネクタと接続すると、各ステップはキューに入り、クラスターが有効になります。続いて、Mule Runtime Engine のクラスターが任意のノードで各ステップを処理し、ノード間で負荷がより効率的に分散されます。 - アラートの生成。 ノードがダウンした場合やノードが復活したときに表示されるアラートをセットアップできます。
クラスターのすべての Mule Runtime Engine はアクティブにメッセージを処理します。各 Mule ノードは垂直方向にも拡張可能です。単一のノードでも複数のコアや追加メモリを活用することで拡張できます。Mule は複数のコアを使用する場合であっても、クラスターでは単一のノードとして動作します。
### [](#クラスターによって解決される同時実行の問題)クラスターによって解決される同時実行の問題 クラスターとしてバインドされていない複数のサーバーで構成されたサーバーグループがある場合、次のような問題が存在する可能性があります。サーバーをクラスターとしてグループ化すれば、こうした問題に頭を悩ませることはありません。 - ファイルベースのコネクタ。 すべての Mule インスタンスは同じ Mule ファイルフォルダーに同時にアクセスするため、ファイル処理が重複することもあれば、ファイルが Mule アプリケーションによって削除または変更された場合には障害が発生する可能性もあります。 - マルチキャストコネクタ。 すべての Mule インスタンスは同じ TCP 要求を受けてから重複メッセージを処理します。 - JMS トピック。 すべての Mule インスタンスは同じ JMS トピックに接続するため、非クラスタリング Mule インスタンスを水平方向に拡張した場合、メッセージの処理が反復される場合もあります。JMS ブローカーからは、インスタンスは別々のサブスクライバーのように見え、そのすべてが各メッセージのコピーを取得します。この動作が必要となるのはまれです。このシナリオを避けるために、「共有サブスクライバー」設定を使用できます。この設定によって、JMS ブローカーに、すべてのインスタンスを結合サブスクライバーとして扱い、それぞれ別個のメッセージを与えるように指示できます。 - JMS request-reply (要求-返信)/request-response (要求-応答)。 すべての Mule インスタンスは同じ応答キューでメッセージをリスンします。これは、Mule インスタンスが送信した要求に相関していない応答を受け取る可能性があり、結果として不正な応答になったりフローがタイムアウトにより失敗したりする場合があることを意味します。 - 冪等性再配信ポリシーと冪等性メッセージ検証。 水平スケーリングで同じ要求を異なる Mule インスタンスが受信し、再配信ポリシーまたは Idempotency Message Validator で使用されるオブジェクトストアコンテンツがローカライズされている場合、冪等性が正しく機能しません。このような冪等性機能で使用されるオブジェクトストア値を共有するクラスターの場合、すべてのノードがすでに処理済みの識別子のリストを共有しているため、メッセージの重複は起こり得ません。 - Salesforce ストリーミング API。 同じアプリケーションの複数のインスタンスをデプロイした場合、API は単一コンシューマーしかサポートしていないため、失敗します。接続されているインスタンスが停止またはクラッシュした場合のフェールオーバーのサポートはありません。 ## [](#前提条件)前提条件 - クラスターには少なくとも 2 個の Mule Runtime Engine インスタンスが必要であり、マシン上で障害が 1 か所に集中することを防ぐため、それぞれを異なるマシンで実行する必要があります。 - Mule 高可用性 (HA) では、クラスターのノード間の同期を維持するために、サーバー間に信頼性の高いネットワーク接続が必要です。 - Mule クラスター用に設定されたポートを開いたままにします。 - Runtime Manager を使用してクラスターを設定し、デフォルトポートを使用する場合、TCP ポート ​`5701`​、​`5702`​、および ​`5703`​ を開いたままにします。 - 代わりにカスタムポートを設定する場合、カスタムポートを開いたままにします。 - ポート ​`5701`​ を介してノード間の通信が開いていることを確認します。 ネットワーク内のファイアウォールルールを検証して、ノード間の双方向通信が有効になっていることを確認します。 クラスターでマルチキャストを有効にする場合、前述の前提条件に加えて次の要件も適用されます。 - UDP ポート ​`54327`​ を開いたままにします。 - マルチキャスト IP アドレス ​`224.2.2.3`​ を有効にします。 ## [](#高可用性)高可用性 高可用性とは、そこで実行されるアプリケーションのダウンタイムを防止するようにコンピューターシステムをデザインする方法です。一部のシステムでは 1 台のサーバーでダウンタイムが発生しても、アプリケーションはアプリケーションのエンドユーザーに対するサービスの提供を中断することなく他のサーバーでスムーズに実行し続けることができるように、複数のサーバーを使用しています。 ## [](#クラスターのデザインと管理)クラスターのデザインと管理 Anypoint Runtime Manager は、Mule インスタンスの顧客がホストするクラスターをセットアップしてアプリケーションをデプロイしてクラスターで実行できるようにします。クラスターおよび個別のノードの状況に関する情報を監視することもできます。クラスタリングを行うと、複数のサーバーを 1 台として容易に管理できます。
クラスター管理についての詳細は、Runtime Manager の​「Managing Servers (サーバーの管理)」​を参照してください。
Anypoint Runtime Fabric では、デプロイメント時に Mule Runtime レプリカをクラスターモードでプロビジョニングするオプションがあります。 Mule クラスターは、2 つ以上の Mule Runtime Engine、またはノードで構成され、グループにまとめられて単一ユニットとして扱われます。初期設定の場合、クラスターの拡張は 8 個の Mule Runtime Engine までにすることをお勧めします。 Anypoint Runtime Manager を使用すれば、クラスター内のすべての Mule Runtime Engine を単一の Mule Runtime Engine であるかのようにデプロイ、監視、および停止することができます。 注意: CloudHub ではプロビジョンされたワーカーにこのクラスタリング設定を使用しませんが、同等の環境を提供する他の高可用性機能があります。たとえば、Anypoint Object Store (OSv2) を介した外部化された状態管理や、永続的なキュー配置機能 (VM キューをワーカーの外部に移すことで、共有可能にして再プロビジョニングの際も存続するようにする) などです。 次に示すように、クラスター内のすべてのノードはメモリを共有します。 ![topology\_4-cluster](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/topology-4-cluster.png)
動作のパフォーマンスを確保するために、Mule は active-active (アクティブ-アクティブ) モデルを使用して Mule Runtime Engine をクラスタリングします。active-passive (アクティブ-パッシブ) モデルに対するこのモデルのメリットは、アプリケーションがすべてのノードで実行され、メッセージ処理をクラスター内の他のノードと分け合うことで、処理を効率化できることです。
### [](#プライマリノードの違い)プライマリノードの違い active-active (アクティブ-アクティブ) モデルでは、すべてのノードが処理を実行できます。ただし、いずれか 1 つのノードがプライマリノードとして機能し、スケジューラーやその他の「プライマリノードのみ」とマークされているイベントソースを実行します。このモデルでは、クラスター内の 1 つのプライマリポーリングノードでソースが実行され、クラスター内の他のノードはそれらのソースからのメッセージを読めないように設定できます。 この機能は、ソース種別に応じて異なります。 - スケジューラーソース: プライマリポーリングノードでのみ実行されます。 - 他のソース: `primaryNodeOnly`​ 属性で定義されます。そのコネクタの ​`primaryNodeOnly`​ のデフォルト値を調べるには、各コネクタのドキュメントを確認してください。 JMS の設定例: ```xml ``` この例は、逐次/一度に 1 つのメッセージの処理が必要な状況でアプリケーションが JMS からメッセージを受信するユースケースのものと考えられます。JMS Connector の On New Message ソースのデフォルト設定では、デフォルトで \[Primary Node Only (プライマリノードのみ)\] が選択されていますが、ほとんどのコネクタソースでは \[Primary Node Only (プライマリノードのみ)\] は選択されていません。デフォルト設定の決定はコネクタの開発者が行います。すべてのノードで処理を実行する必要があるユースケースでは、開発者はすべてのクラスターノードでソースが有効になるように primaryNodeOnly 値の選択を解除します。 ## [](#queues)Queues コードの実行とフロー参照によるフローのコールは、イベントの実行が開始されたのと同じノードで行われます。ただし、クラスタリングされた Mule Runtime で実行を共有または分散するために、VM キューをセットアップして VM キューに明示的にパブリッシュすることでノード間で負荷を分散できます。永続的な VM キューと一時的な VM キューのいずれでもクラスターの共有メモリグリッドが使用され、VM キューを介したあらゆる移行は別のアクティブなノードにジャンプする可能性があります。そのため、アプリケーションフロー全体に VM キューのパブリッシャー/リスナーによってリンクされた子フローのシーケンスが含まれる場合、クラスターは連続する各子フローをその時点で使用可能な任意の Mule Runtime Engine に割り当てることができます。下で示しているように、クラスターはアプリケーションフローの VM キューを通過するときに複数のノードで単一メッセージを処理することもできます。 ![load\_balancing](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/load-balancing.png) ## [](#高信頼性アプリケーション)高信頼性アプリケーション 高信頼性アプリケーションと言えるには、以下の要件を満たす必要があります。 1. メッセージの損失の許容がゼロであること 2. インテグレーションエンジン (Mule) が信頼できること 3. 個別の接続の信頼性が高いこと トランザクション性として知られる機能はアプリケーションイベントシーケンスを追跡し、それぞれのメッセージ処理ステップが正常に完了するようにします。そのため、失われたり不正に処理されたりするメッセージはありません。何らかの理由でステップが失敗した場合、トランザクションメカニズムが以前の処理イベントをすべてロールバックし、メッセージ処理シーケンスを再開します。 JMS、VM、JDBC などのコネクタにより、ビルトイントランザクションサポートが提供されるため、メッセージが確実に処理されるようになります。たとえば、トランザクションがコミットされた後でのみメッセージを JMS サーバーから削除するようにインバウンド JMS 接続エンドポイントでトランザクションを設定できます。この方法により、処理フロー中にエラーが発生した場合、元のメッセージは再処理できる状態で保持されます。 トランザクションをサポートする異種コネクタ間でメッセージを移動するには、XA トランザクションを使用する必要があります。これにより、Mule Runtime Engine はすべての異種コネクタの関連付けられたトランザクションを単一ユニットとしてコミットするようになります。
トランザクションは、コネクタがトランザクションをサポートしないシステムでのインタラクションや操作を対象とすることはできません。そのため、関連する操作の中にトランザクションに含めることができないものがある場合には、 Sagas​ などの代替パターンを代わりに使用します。
## [](#コネクタのクラスターサポート)コネクタのクラスターサポート すべての Mule Connector がクラスター内でサポートされます。コネクタごとにインバウンドトラフィックにアクセスする方法が異なるため、このサポートの詳細は異なります。一般に、アウトバウンドトラフィックはクラスター内外で同じように機能します。Mule Runtime は 3 つの基本的な種別のコネクタをサポートしています。 ### [](#ソケットベースのコネクタ)ソケットベースのコネクタ ソケットベースのコネクタは Mule が所有するネットワークソケットに送信された入力を読み取ります。例としては TCP、UDP、HTTP\[S\] などがあります。 ソケットベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - クラスタリングされた各 Mule Runtime は異なるネットワークノードで実行されるため、各インスタンスはそのノードに送信されたソケットベースのトラフィックのみを受信します。受信したソケットベースのトラフィックは、クラスタリングされたインスタンス間で分散するために​[\[Clustering and Load Balancing\]](<#Clustering and Load Balancing>)​を実行する必要があります。 - ソケットベースのコネクタへの出力は特定のホスト/ポートの組み合わせに書き込まれます。ホスト/ポートの組み合わせが外部ホストの場合、特に考慮事項はありません。ローカルホストのポートの場合、クラスター間でより効率的にトラフィックを分散するために、代わりにロードバランサーでそのポートを使用することを検討してください。 ### [](#リスナーベースのコネクタ)リスナーベースのコネクタ リスナーベースのコネクタは同時の複数アクセサーを十分にサポートするプロトコルを使用してデータを読み取ります。例としては、JMS や VM があります。 リスナーベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - リスナーベースのコネクタは複数のリーダーおよびライターを完全にサポートしています。入力にも出力にも特に考慮事項はありません。 - クラスターでは、VM Connector キュー (永続的と一時的の両方) が共有のクラスター全体のリソースである点に注意してください。クラスターは VM Connector キューへのアクセスを自動的に同期します。そのため、任意のクラスターノードで VM キューに書き込まれたメッセージを処理できます。これにより、VM はクラスターノード間でワークを共有するのに最適です。 ### [](#リソースベースのコネクタ)リソースベースのコネクタ リソースベースのコネクタは複数の同時アクセサーは使用可能だがリソースの使用をネイティブに調整しないリソースからデータを読み取ります。リソースベースのコネクタの例としては、ファイル、FTP、SFTP、メール、JDBC などがあります。 リソースベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - Mule HA クラスタリングは自動的にクラスター内のノードのみについて各リソースへのアクセスを調整するため、クラスタリングされたインスタンスのうち 1 つだけが一度に各リソースにアクセスするようになります。そのため、通常はリソースベースのコネクタから読み取られたメッセージをすぐに VM キューに書き込むことをお勧めします。これにより、他のクラスターノードがメッセージの処理に参加できます。

クラスター内のノードとして同じリソースにアクセスする他のアプリケーション (クラスター外の Mule アプリケーションまたは Mule 以外のアプリケーション) を実行する場合は、これらのリソースをロックするロジックを実装する必要があります。

たとえば、複数のプログラムがファイルの読み取り、変更、そして削除を行うことで、同じ共有ディレクトリのファイルを処理しているとします。これらのプログラムは明示的なアプリケーションレベルのロッキング戦略を使用して、同じファイルが複数回処理されないようにする必要があります。
- リソースベースのクラスタリングされたコネクタへの書き込みには特に考慮事項はありません。 - ファイルベースのコネクタ (ファイル、FTP、SFTP) に書き込むときに、Mule は一意のファイル名を生成します。 - JDBC に書き込むときに、Mule は一意のキーを生成できます。 - メールの作成は、実質的にはリソースベースではなくリスナーベースです。 ## [](#クラスタリングと信頼性の高いアプリケーション)クラスタリングと信頼性の高いアプリケーション 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。クラスターで十分に信頼できるアプリケーションをビルドするためのツールは​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.6/reliability-patterns)​で見つかります。 アプリケーションで非トランザクションコネクタを使用している場合、信頼性パターンに従ってください。これらのパターンにより、メッセージが受け入れられて正常に処理されるか、「失敗」応答を生成してクライアントが再試行できるようになります。 アプリケーションで JMS、VM、JDBC などのトランザクションコネクタを使用している場合は、トランザクションを使用します。トランザクションコネクタに対する Mule のビルトインサポートにより、こうしたコネクタを使用するアプリケーションで信頼性の高いメッセージングを実現できます。 これらのアクションは、クラスタリングされていないアプリケーションにも適用できます。 ## [](#クラスタリングとネットワーキング)クラスタリングとネットワーキング ### [](#単一のデータセンターのクラスタリング)単一のデータセンターのクラスタリング クラスターノード間で信頼性のある接続を確立するには、クラスターのすべてのノードを同じ LAN に配置する必要があります。VPN を通じて接続された異なるデータセンターなど、地理的に離れた場所にノードが含まれるクラスターを実装することも可能ですが、お勧めはしません。 ネットワークの中断や、メッセージの重複などの意図しない結果を招く可能性を下げるためには、すべてのクラスターノードを同じ LAN に配置するのが最もお勧めです。 ### [](#分散型データセンターのクラスタリング)分散型データセンターのクラスタリング WAN ネットワークを使用してクラスターノードをリンクすると、外部ルーターやファイアウォールなど、障害が発生する可能性のあるポイントが多くなり、クラスターノード間で適切に同期が行われないおそれがあります。これはパフォーマンスに影響を及ぼすだけでなく、アプリケーションにおける副作用の可能性を考慮に入れる必要も生じます。たとえば、2 つのクラスターノードがネットワークリンクの障害による切断後に再接続した場合、次回の同期プロセスでメッセージが 2 回処理される可能性があり、重複が発生して、アプリケーションロジックで処理する必要が生じます。また、オブジェクトストアを使用しているアプリケーションが、ノード間の通信機能の障害のために整合性のない状態になる可能性もあります。他に発生する可能性のある問題は、複数のノードが「プライマリ」になることです。これは、別々のノードが自身がクラスター内の唯一のノードであると認識することで発生します。 異なるデータセンターに配置されたクラスターのノードを使用でき、必ずしも同じ LAN に配置されている必要はありませんが、いくつか制限事項がある点に注意してください。 この「スプリットブレーン」処理動作を防ぐには、Quorum プロトコルを有効にする必要があります。このプロトコルは、ノードの 1 つのセットがデータの処理を続行し、他のセットが再接続されるまで共有データに関して何も実行しないようにするために使用されます。基本的に、切断が発生した場合、ノードが最も多い方のみが稼働し続けます。たとえば、2 つのデータセンターがあり、一方は 3 つのノードがあり、もう一方には 2 つのノードがあるとします。2 つのノードがあるデータセンターで接続の問題が発生した場合、ノードが 3 つのデータセンターが機能し続け、もう一方のデータセンターは停止します。ノードが 3 つのデータセンターがオフラインになった場合、どちらのノードも機能しなくなります。こうした機能停止を防ぐには、少なくとも 3 つの同じ数のノードを持つデータセンターでクラスターを作成する必要があります。2 つのデータセンターがクラッシュすることは考えにくいため、1 つのデータセンターがオフラインになったり、ネットワーク障害によって他のデータセンターから分離されたりしても、クラスターは常に機能し続けることになります。
機能するのに十分なノードがクラスターパーティションにない場合、外部システムコールに対しては引き続き反応しますが、オブジェクトストアを経由したすべての操作は失敗し、データ生成できなくなります。
#### [](#制限事項)制限事項 - Quorum はオブジェクトストア関連の操作でのみサポートされます。 - 分散ロッキングはサポートされず、以下に影響を及ぼします。 - ファイルの並列に関するファイル/FTP Connector ポーリング - 冪等性再配信ポリシーコンポーネント - 冪等性メッセージ検索条件コンポーネント - メモリ内メッセージングはサポートされず、以下に影響を及ぼします。 - VM Connector - Quorum 機能は手動でのみ設定できます。 - Batch job では高可用性機能は使用されません。 ## [](#クラスタリングと負荷分散)クラスタリングと負荷分散 TCP 要求 (この場合、TCP には SSL/TLS、UDP、Multicast、HTTP、HTTPS が含まれる) に対応するために Mule クラスターが使用される場合、クラスタリングされたインスタンス間で要求を分散するためにある程度の負荷分散が必要になります。Anypoint Runtime Fabric には基盤となる Docker Kubernetes (K8s) インフラストラクチャの一部としてロードバランサー機能が含まれていますが、お客様がホストし、手動でプロビジョニングされたクラスターでは、サードパーティのロードバランサーを提供するか、クライアント側で負荷分散とフェールオーバーを実行する必要があります。 さまざまなソフトウェアのロードバランサーが使用できますが、そのうちの 2 つを紹介します。 - オープンソースの HTTP サーバーおよびリバースプロキシである Nginx。HTTP(S) の負荷分散に NGINX の ​`HttpUpstreamModule`​ を使用できます。 - Apache Web サーバー。これは HTTP(S) ロードバランサーとしても使用できます。 TCP と HTTP または HTTPS トラフィックの両方をルーティングできるハードウェアのロードバランサーも多数あります。 ## [](#cluster-high-performance)高パフォーマンス用のクラスタリング このセクションは、お客様がホストし、手動でプロビジョニングされたクラスターデプロイメントにのみ適用されます。 その他のデプロイメントオプションについての詳細は、​[「デプロイメント戦略」](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)​を参照してください。 (信頼性ではなく) 高パフォーマンスが最大目標の場合は、パフォーマンスプロファイルを使用してパフォーマンスが最大になるように Mule クラスターまたは各アプリケーションを設定できます。クラスター内で特定のアプリケーションのパフォーマンスプロファイルを実装することで、デプロイメントの拡張性を最大にすると同時に、パフォーマンスおよび信頼性の要件が異なるアプリケーションを同じクラスターにデプロイすることができます。コンテナレベルで設定したパフォーマンスプロファイルは、そのコンテナ内のすべてのアプリケーションに適用されます。アプリケーションレベルの設定はコンテナレベルの設定より優先されます。 ### [](#パフォーマンスプロファイルの設定に関する考慮事項)パフォーマンスプロファイルの設定に関する考慮事項 パフォーマンスプロファイルの設定には 2 つの効果があります。 - 分散キューが無効になり、代わりにローカルキューを使用して共有データグリッドにおけるデータの逐次化/非逐次化および分散を防止します。 - バックアップなしでオブジェクトストアを実装し、複製を防止します。
1 つのノードがダウンしたら、そのノードに関連付けられているデータが失われます。
パフォーマンスプロファイルを設定しても、メモリ共有には影響しません。クラスターモードでは、オブジェクトストアはノード間で常に分散し、共有されます。 ### [](#パフォーマンスプロファイルの設定)パフォーマンスプロファイルの設定 _コンテナ_​レベルでパフォーマンスプロファイルを設定するには、次のコマンドを ​`mule-cluster.properties`​、システムプロパティ (コマンドラインから)、または ​`wrapper.conf`​ に追加します。 `mule.cluster.storeprofile=performance` _個別のアプリケーション_​レベルでパフォーマンスプロファイルを設定するには、以下で示しているように、設定ラッパー内にプロファイルを追加します。 - パフォーマンスストアプロファイル ```xml ``` アプリケーションレベルの設定はコンテナレベルの設定より優先されます。高パフォーマンス用にコンテナを設定するが、そのコンテナ内の 1 つ以上の個別のアプリケーションでは信頼性を優先するには、こうしたアプリケーションに次のコードを含めます。 - 信頼性ストアプロファイル ```xml ```

負荷分散をサポートしないエンドポイントで負荷が大きい場合、パフォーマンスプロファイルを適用するとパフォーマンスが低下する場合もあります。非同期処理戦略、ロードバランサーがない JMS トピック、マルチキャスト、または HTTP Connector でファイルベースのコネクタを使用している場合、大量のメッセージが単一ノードに入るとボトルネックが発生する可能性があるため、こうしたアプリケーションのパフォーマンスプロファイルを無効にしたほうがパフォーマンスが向上する場合があります。
稼働状態を保つためにクラスターで必要なマシンの最小数を定義することもできます。この設定により、パフォーマンス全体での一貫性が改善されます。 ## [](#クラスターノード間の通信の暗号化)クラスターノード間の通信の暗号化 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルでまたはシステムプロパティとして定義することで、クラスターノード間のトラフィックを暗号化できます。 暗号化鍵を定義すると、定義した鍵と AES 暗号化アルゴリズムを使用してクラスターノード間のすべての通信が暗号化されます。 ## [](#cluster_fips)FIPS モードでのクラスタリングの有効化 FIPS モードでのクラスタリングを有効化するには、次のタスクを完了します。 - FIPS モードで Mule Runtime Engine を実行します。 設定の手順は、​[「FIPS コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.6/fips-140-2-compliance-support)​を参照してください。 - クラスターノード間の通信を暗号化します。 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルで定義するか、システムプロパティとして定義します。 ### [](#警告)警告 - 暗号化鍵を定義しない場合、アプリケーションはデプロイに失敗し、​`Cluster key must be defined in FIPS mode.`​ というメッセージが表示されます。 - クラスタリングされたすべてのノードで同じ暗号化鍵を使用しない場合、この機能は動作しません。 - FIPS モードでクラスタリングされた環境を実行すると、ノード間のすべての通信が暗号化 (および復号化) されるため、パフォーマンスが低下します。 ## [](#クラスタリングのベストプラクティス)クラスタリングのベストプラクティス クラスタリングに関しては多くの推奨事項があります。例を挙げます。 - できるだけアプリケーションを一連のステップに整理し、各ステップがメッセージを 1 つのトランザクションストアから別のトランザクションストアに移動するようにします。 - アプリケーションで非トランザクションコネクタからのメッセージを処理する場合、​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.6/reliability-patterns)​を使用して VM や JMS ストアなどのトランザクションストアに移動します。 - トランザクションを使用してトランザクションコネクタからのメッセージを処理します。これにより、エラーが発生した場合、メッセージが再処理されるようになります。 - VM や JMS Connector で使用するような分散ストアを使用します。こうしたストアはクラスター全体に対して使用可能です。これは、ファイル、FTP、JDBC などのコネクタで使用する非分散ストアよりも優れています。こうしたストアは一度に単一のノードによって読み取られます。 - VM Connector を使用して最適なパフォーマンスを得ます。クラスター全体が終了した後にデータを保存する必要があるアプリケーションに JMS Connector を使用します。 - 高信頼性アプリケーションを作成するには信頼性パターンを実装します。 - HA クラスターモードでは、すべてのオブジェクトストアコンテンツ (メモリ内コンテンツと、​`persistent`​ パラメーターで定義される永続的なコンテンツの両方) は、分散メモリグリッドに保存されます。クラスターでクォーラムが保持されている限り、このデータはアプリケーションの再デプロイまたは再起動後も存続します。オブジェクトストアコンテンツを完全にクリアするには、再起動する前にすべてのクラスターノードを停止する必要があります。クラスターの完全シャットダウン後もデータの永続性が必要なシナリオでは、メモリグリッドの代わりに JDBC ベースのストアを使用するようにオブジェクトストアを設定します。​[「オブジェクトストアの永続性」](https://docs.mulesoft.com/jp/mule-runtime/4.6/creating-and-managing-a-cluster-manually#object-store-persistence)​を参照してください。 ## [](#関連情報)関連情報 - [Enterprise ライセンスのインストール](https://docs.mulesoft.com/jp/mule-runtime/4.6/installing-an-enterprise-license) - [サーバーの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-servers#create-a-cluster) - [CloudHub 高可用性および障害回復](https://docs.mulesoft.com/cloudhub/cloudhub-hadr) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/creating-and-managing-a-cluster-manually) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management) - [クォーラム管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/creating-and-managing-a-cluster-manually#quorum-management) # Mule Runtime 高可用性 (HA) クラスターの概要
CloudHub でのクラスタリングに相当するものの場合、アプリケーションを拡大し、高可用性を提供するためにワーカーを共有または二重化する方法の詳細は、​CloudHub 高可用性​を参照してください。
Mule Enterprise Edition は拡張可能なクラスタリングをサポートし、オンプレミスアプリケーションの高可用性 (HA) を実現しています。 クラスターとは、ユニットとして機能する Mule Runtime Engine のセットです。言い換えると、クラスターとは複数のノード (Mule Runtime Engine) で構成された仮想サーバーです。クラスター内のノードは分散された共有メモリグリッドを通じて通信を行い、オブジェクトストアと VM キューのデータを共有します。つまり、データがさまざまなマシンのメモリ間で複製されます。 この複製された状態の共有メモリグリッドは、次のものに適用されます。 - 永続的または非永続的なオブジェクトストア - 永続的または一時的な VM キュー - Mule Runtime LockFactory ![分散共有メモリが含まれる複数のクラスターノード](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/cluster.png)
この機能の価格については、カスタマーサービス担当者にお問い合わせください。
## [](#クラスタリングの利点)クラスタリングの利点 デフォルトでは、Mule Runtime Engine のクラスタリングにより、システムの高可用性を実現できます。障害や計画的なダウンタイムが原因で Mule Runtime Engine ノードが使用不可になった場合、クラスター内の別のノードがワークロードを引き継ぎ、VM キューからのメッセージの処理やその他の要求のサービスを続行できます。次の図は、2 ノードのクラスターによる受信メッセージの処理を示しています。処理負荷がノード間で分散されているのがわかります。ノード 1 がメッセージ 1 を処理するのと同時に、ノード 2 はメッセージ 2 を処理します。 ![複数のノードと 1 つのクライアントが含まれるフェールオーバープロセス](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/failovernofail.png) 一方のノードで障害が発生した場合、もう一方の障害の発生していないノードが障害の発生しているノードの作業を引き継ぎます。外部ロードバランサーが障害の発生しているノードのトラフィックをアクティブなノードにリダイレクトするか、VM キューを通じてアクティブなノードがインフライトメッセージの処理を続行できるようにします。次の図で示しているように、ノード 2 で障害が発生した場合、ノード 1 はメッセージ 1 とメッセージ 2 の両方を処理します。 ![クラスター内に 2 つのノードと 1 つのクライアントが含まれるフェールオーバープロセス](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/failovernode2fail.png) Mule Runtime Engine のクラスターではすべてのノードが同時に「アクティブ-アクティブ」になりメッセージを処理できるため、クラスターによってパフォーマンスおよび拡張性も向上します。単一ノードのインスタンスと比較すると、クラスターのほうがサポートできるユーザーも多く、ワークロードを複数のノードで共有するかノードをクラスターに追加することで、アプリケーションのパフォーマンスも向上できます。アプリケーションによっては水平方向にスケーリングまたはクラスタリングを行ってもパフォーマンスが向上しないものもあります。パフォーマンスは追加ノードと共有される作業の性質によって異なります。オブジェクトストアを多用するアプリケーションの中には、共有メモリグリッド内のデータの複製やアクセスの調整に必要な作業のために、パフォーマンスが低下するものもあります。 次の図では、ワークロードの共有をより詳しく示しています。両方のノードが受注処理に関するメッセージを処理します。ただし、一方のノードの負荷が大きい場合、その処理の 1 つ以上のステップの処理をもう一方のノードに移動できます。ここでは、割引処理ステップの処理がノード 1 に移動され、受注ステップの処理がノード 2 に移動されています。 ![注文とメッセージを処理するノードが含まれるクラスター](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/cluster-diagram.png) 自動フェールオーバーによる高可用性、パフォーマンスの向上、拡張性の向上以外に、Mule Runtime Engine のクラスタリングには次のような利点があります。 - ファイル、データベース、FTP ソースなどのリソースへのアクセスの自動調整。 Mule Runtime Engine クラスターは、どのノード (Mule Runtime Engine) がデータソースからの通信を処理するかを自動的に管理します。 - クラスター内の処理の自動負荷分散。 フローを一連のステップに分割してこれらのステップを VM などのコネクタと接続すると、各ステップはキューに入り、クラスターが有効になります。続いて、Mule Runtime Engine のクラスターが任意のノードで各ステップを処理し、ノード間で負荷がより効率的に分散されます。 - アラートの生成。 ノードがダウンした場合やノードが復活したときに表示されるアラートをセットアップできます。
クラスターのすべての Mule Runtime Engine はアクティブにメッセージを処理します。各 Mule ノードは垂直方向にも拡張可能です。単一のノードでも複数のコアや追加メモリを活用することで拡張できます。Mule は複数のコアを使用する場合であっても、クラスターでは単一のノードとして動作します。
### [](#クラスターによって解決される同時実行の問題)クラスターによって解決される同時実行の問題 クラスターとしてバインドされていない複数のサーバーで構成されたサーバーグループがある場合、次のような問題が存在する可能性があります。サーバーをクラスターとしてグループ化すれば、こうした問題に頭を悩ませることはありません。 - ファイルベースのコネクタ。 すべての Mule インスタンスは同じ Mule ファイルフォルダーに同時にアクセスするため、ファイル処理が重複することもあれば、ファイルが Mule アプリケーションによって削除または変更された場合には障害が発生する可能性もあります。 - マルチキャストコネクタ。 すべての Mule インスタンスは同じ TCP 要求を受けてから重複メッセージを処理します。 - JMS トピック。 すべての Mule インスタンスは同じ JMS トピックに接続するため、非クラスタリング Mule インスタンスを水平方向に拡張した場合、メッセージの処理が反復される場合もあります。JMS ブローカーからは、インスタンスは別々のサブスクライバーのように見え、そのすべてが各メッセージのコピーを取得します。この動作が必要となるのはまれです。このシナリオを避けるために、「共有サブスクライバー」設定を使用できます。この設定によって、JMS ブローカーに、すべてのインスタンスを結合サブスクライバーとして扱い、それぞれ別個のメッセージを与えるように指示できます。 - JMS request-reply (要求-返信)/request-response (要求-応答)。 すべての Mule インスタンスは同じ応答キューでメッセージをリスンします。これは、Mule インスタンスが送信した要求に相関していない応答を受け取る可能性があり、結果として不正な応答になったりフローがタイムアウトにより失敗したりする場合があることを意味します。 - 冪等性再配信ポリシーと冪等性メッセージ検証。 水平スケーリングで同じ要求を異なる Mule インスタンスが受信し、再配信ポリシーまたは Idempotency Message Validator で使用されるオブジェクトストアコンテンツがローカライズされている場合、冪等性が正しく機能しません。このような冪等性機能で使用されるオブジェクトストア値を共有するクラスターの場合、すべてのノードがすでに処理済みの識別子のリストを共有しているため、メッセージの重複は起こり得ません。 - Salesforce ストリーミング API。 同じアプリケーションの複数のインスタンスをデプロイした場合、API は単一コンシューマーしかサポートしていないため、失敗します。接続されているインスタンスが停止またはクラッシュした場合のフェールオーバーのサポートはありません。 ## [](#前提条件)前提条件 - クラスターには少なくとも 2 個の Mule Runtime Engine インスタンスが必要であり、マシン上で障害が 1 か所に集中することを防ぐため、それぞれを異なるマシンで実行する必要があります。 - Mule 高可用性 (HA) では、クラスターのノード間の同期を維持するために、サーバー間に信頼性の高いネットワーク接続が必要です。 - Mule クラスター用に設定されたポートを開いたままにします。 - Runtime Manager を使用してクラスターをセットアップし、デフォルトポートを使用する場合、TCP ポート ​`5701`​、​`5702`​、および ​`5703`​ を開いたままにします。 - 代わりにカスタムポートを設定する場合、カスタムポートを開いたままにします。 - ポート ​`5701`​ を介してノード間の通信が開いていることを確認します。 ネットワーク内のファイアウォールルールを検証して、ノード間の双方向通信が有効になっていることを確認します。 クラスターでマルチキャストを有効にする場合、前述の前提条件に加えて次の要件も適用されます。 - UDP ポート ​`54327`​ を開いたままにします。 - マルチキャスト IP アドレス ​`224.2.2.3`​ を有効にします。 ## [](#高可用性)高可用性 高可用性とは、そこで実行されるアプリケーションのダウンタイムを防止するようにコンピューターシステムをデザインする方法です。一部のシステムでは 1 台のサーバーでダウンタイムが発生しても、アプリケーションはアプリケーションのエンドユーザーに対するサービスの提供を中断することなく他のサーバーでスムーズに実行し続けることができるように、複数のサーバーを使用しています。 ## [](#クラスターのデザインと管理)クラスターのデザインと管理 Anypoint Runtime Manager は、Mule インスタンスの顧客がホストするクラスターをセットアップしてアプリケーションをデプロイしてクラスターで実行できるようにします。クラスターおよび個別のノードの状況に関する情報を監視することもできます。クラスタリングを行うと、複数のサーバーを 1 台として容易に管理できます。
クラスター管理についての詳細は、Runtime Manager の​「Managing Servers (サーバーの管理)」​を参照してください。
Anypoint Runtime Fabric では、デプロイメント時に Mule Runtime レプリカをクラスターモードでプロビジョニングするオプションがあります。 Mule クラスターは、2 つ以上の Mule Runtime Engine、またはノードで構成され、グループにまとめられて単一ユニットとして扱われます。初期設定の場合、クラスターの拡張は 8 個の Mule Runtime Engine までにすることをお勧めします。 Anypoint Runtime Manager を使用すれば、クラスター内のすべての Mule Runtime Engine を単一の Mule Runtime Engine であるかのようにデプロイ、監視、および停止することができます。 注意: CloudHub ではプロビジョンされたワーカーにこのクラスタリング設定を使用しませんが、同等の環境を提供する他の高可用性機能があります。たとえば、Anypoint Object Store (OSv2) を介した外部化された状態管理や、永続的なキュー配置機能 (VM キューをワーカーの外部に移すことで、共有可能にして再プロビジョニングの際も存続するようにする) などです。 次に示すように、クラスター内のすべてのノードはメモリを共有します。 ![topology\_4-cluster](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/topology-4-cluster.png)
動作のパフォーマンスを確保するために、Mule は active-active (アクティブ-アクティブ) モデルを使用して Mule Runtime Engine をクラスタリングします。active-passive (アクティブ-パッシブ) モデルに対するこのモデルのメリットは、アプリケーションがすべてのノードで実行され、メッセージ処理をクラスター内の他のノードと分け合うことで、処理を効率化できることです。
### [](#プライマリノードの違い)プライマリノードの違い active-active (アクティブ-アクティブ) モデルでは、すべてのノードが処理を実行できます。ただし、いずれか 1 つのノードがプライマリノードとして機能し、スケジューラーやその他の「プライマリノードのみ」とマークされているイベントソースを実行します。このモデルでは、クラスター内の 1 つのプライマリポーリングノードでソースが実行され、クラスター内の他のノードはそれらのソースからのメッセージを読めないように設定できます。 この機能は、ソース種別に応じて異なります。 - スケジューラーソース: プライマリポーリングノードでのみ実行されます。 - 他のソース: `primaryNodeOnly`​ 属性で定義されます。そのコネクタの ​`primaryNodeOnly`​ のデフォルト値を調べるには、各コネクタのドキュメントを確認してください。 JMS の設定例: ```xml ``` この例は、逐次/一度に 1 つのメッセージの処理が必要な状況でアプリケーションが JMS からメッセージを受信するユースケースのものと考えられます。JMS Connector の On New Message ソースのデフォルト設定では、デフォルトで \[Primary Node Only (プライマリノードのみ)\] が選択されていますが、ほとんどのコネクタソースでは \[Primary Node Only (プライマリノードのみ)\] は選択されていません。デフォルト設定の決定はコネクタの開発者が行います。すべてのノードで処理を実行する必要があるユースケースでは、開発者はすべてのクラスターノードでソースが有効になるように primaryNodeOnly 値の選択を解除します。 ## [](#queues)Queues コードの実行とフロー参照によるフローのコールは、イベントの実行が開始されたのと同じノードで行われます。ただし、クラスタリングされた Mule Runtime で実行を共有または分散するために、VM キューをセットアップして VM キューに明示的にパブリッシュすることでノード間で負荷を分散できます。永続的な VM キューと一時的な VM キューのいずれでもクラスターの共有メモリグリッドが使用され、VM キューを介したあらゆる移行は別のアクティブなノードにジャンプする可能性があります。そのため、アプリケーションフロー全体に VM キューのパブリッシャー/リスナーによってリンクされた子フローのシーケンスが含まれる場合、クラスターは連続する各子フローをその時点で使用可能な任意の Mule Runtime Engine に割り当てることができます。下で示しているように、クラスターはアプリケーションフローの VM キューを通過するときに複数のノードで単一メッセージを処理することもできます。 ![さまざまなフロープロセスで負荷分散するように設計された 4 つのノードの Mule クラスター](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/load-balancing.png) ## [](#高信頼性アプリケーション)高信頼性アプリケーション 高信頼性アプリケーションと言えるには、以下の要件を満たす必要があります。 1. メッセージの損失の許容がゼロであること 2. インテグレーションエンジン (Mule) が信頼できること 3. 個別の接続の信頼性が高いこと トランザクション性として知られる機能はアプリケーションイベントシーケンスを追跡し、それぞれのメッセージ処理ステップが正常に完了するようにします。そのため、失われたり不正に処理されたりするメッセージはありません。何らかの理由でステップが失敗した場合、トランザクションメカニズムが以前の処理イベントをすべてロールバックし、メッセージ処理シーケンスを再開します。 JMS、VM、JDBC などのコネクタにより、ビルトイントランザクションサポートが提供されるため、メッセージが確実に処理されるようになります。たとえば、トランザクションがコミットされた後でのみメッセージを JMS サーバーから削除するようにインバウンド JMS 接続エンドポイントでトランザクションを設定できます。この方法により、処理フロー中にエラーが発生した場合、元のメッセージは再処理できる状態で保持されます。 トランザクションをサポートする異種コネクタ間でメッセージを移動するには、XA トランザクションを使用する必要があります。これにより、Mule Runtime Engine はすべての異種コネクタの関連付けられたトランザクションを単一ユニットとしてコミットするようになります。
トランザクションは、コネクタがトランザクションをサポートしないシステムでのインタラクションや操作を対象とすることはできません。そのため、関連する操作の中にトランザクションに含めることができないものがある場合には、 Sagas​ などの代替パターンを代わりに使用します。
## [](#コネクタのクラスターサポート)コネクタのクラスターサポート すべての Mule Connector がクラスター内でサポートされます。コネクタごとにインバウンドトラフィックにアクセスする方法が異なるため、このサポートの詳細は異なります。一般に、アウトバウンドトラフィックはクラスター内外で同じように機能します。Mule Runtime は 3 つの基本的な種別のコネクタをサポートしています。 ### [](#ソケットベースのコネクタ)ソケットベースのコネクタ ソケットベースのコネクタは Mule が所有するネットワークソケットに送信された入力を読み取ります。例としては TCP、UDP、HTTP\[S\] などがあります。 ソケットベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - クラスタリングされた各 Mule Runtime は異なるネットワークノードで実行されるため、各インスタンスはそのノードに送信されたソケットベースのトラフィックのみを受信します。受信したソケットベースのトラフィックは、クラスタリングされたインスタンス間で分散するために​[\[Clustering and Load Balancing\]](<#Clustering and Load Balancing>)​を実行する必要があります。 - ソケットベースのコネクタへの出力は特定のホスト/ポートの組み合わせに書き込まれます。ホスト/ポートの組み合わせが外部ホストの場合、特に考慮事項はありません。ローカルホストのポートの場合、クラスター間でより効率的にトラフィックを分散するために、代わりにロードバランサーでそのポートを使用することを検討してください。 ### [](#リスナーベースのコネクタ)リスナーベースのコネクタ リスナーベースのコネクタは同時の複数アクセサーを十分にサポートするプロトコルを使用してデータを読み取ります。例としては、JMS や VM があります。 リスナーベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - リスナーベースのコネクタは複数のリーダーおよびライターを完全にサポートしています。入力にも出力にも特に考慮事項はありません。 - クラスターでは、VM Connector キュー (永続的と一時的の両方) が共有のクラスター全体のリソースである点に注意してください。クラスターは VM Connector キューへのアクセスを自動的に同期します。そのため、任意のクラスターノードで VM キューに書き込まれたメッセージを処理できます。これにより、VM はクラスターノード間でワークを共有するのに最適です。 ### [](#リソースベースのコネクタ)リソースベースのコネクタ リソースベースのコネクタは複数の同時アクセサーは使用可能だがリソースの使用をネイティブに調整しないリソースからデータを読み取ります。リソースベースのコネクタの例としては、ファイル、FTP、SFTP、メール、JDBC などがあります。 リソースベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - Mule HA クラスタリングは自動的にクラスター内のノードのみについて各リソースへのアクセスを調整するため、クラスタリングされたインスタンスのうち 1 つだけが一度に各リソースにアクセスするようになります。そのため、通常はリソースベースのコネクタから読み取られたメッセージをすぐに VM キューに書き込むことをお勧めします。これにより、他のクラスターノードがメッセージの処理に参加できます。

クラスター内のノードとして同じリソースにアクセスする他のアプリケーション (クラスター外の Mule アプリケーションまたは Mule 以外のアプリケーション) を実行する場合は、これらのリソースをロックするロジックを実装する必要があります。

たとえば、複数のプログラムがファイルの読み取り、変更、そして削除を行うことで、同じ共有ディレクトリのファイルを処理しているとします。これらのプログラムは明示的なアプリケーションレベルのロッキング戦略を使用して、同じファイルが複数回処理されないようにする必要があります。
- リソースベースのクラスタリングされたコネクタへの書き込みには特に考慮事項はありません。 - ファイルベースのコネクタ (ファイル、FTP、SFTP) に書き込むときに、Mule は一意のファイル名を生成します。 - JDBC に書き込むときに、Mule は一意のキーを生成できます。 - メールの作成は、実質的にはリソースベースではなくリスナーベースです。 ## [](#クラスタリングと信頼性の高いアプリケーション)クラスタリングと信頼性の高いアプリケーション 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。クラスターで十分に信頼できるアプリケーションをビルドするためのツールは​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.7/reliability-patterns)​で見つかります。 アプリケーションで非トランザクションコネクタを使用している場合、信頼性パターンに従ってください。これらのパターンにより、メッセージが受け入れられて正常に処理されるか、「失敗」応答を生成してクライアントが再試行できるようになります。 アプリケーションで JMS、VM、JDBC などのトランザクションコネクタを使用している場合は、トランザクションを使用します。トランザクションコネクタに対する Mule のビルトインサポートにより、こうしたコネクタを使用するアプリケーションで信頼性の高いメッセージングを実現できます。 これらのアクションは、クラスタリングされていないアプリケーションにも適用できます。 ## [](#クラスタリングとネットワーキング)クラスタリングとネットワーキング ### [](#単一のデータセンターのクラスタリング)単一のデータセンターのクラスタリング クラスターノード間で信頼性のある接続を確立するには、クラスターのすべてのノードを同じ LAN に配置する必要があります。VPN を通じて接続された異なるデータセンターなど、地理的に離れた場所にノードが含まれるクラスターを実装することも可能ですが、お勧めはしません。 ネットワークの中断や、メッセージの重複などの意図しない結果を招く可能性を下げるためには、すべてのクラスターノードを同じ LAN に配置するのが最もお勧めです。 ### [](#分散型データセンターのクラスタリング)分散型データセンターのクラスタリング WAN ネットワークを使用してクラスターノードをリンクすると、外部ルーターやファイアウォールなど、障害が発生する可能性のあるポイントが多くなり、クラスターノード間で適切に同期が行われないおそれがあります。これはパフォーマンスに影響を及ぼすだけでなく、アプリケーションにおける副作用の可能性を考慮に入れる必要も生じます。たとえば、2 つのクラスターノードがネットワークリンクの障害による切断後に再接続した場合、次回の同期プロセスでメッセージが 2 回処理される可能性があり、重複が発生して、アプリケーションロジックで処理する必要が生じます。また、オブジェクトストアを使用しているアプリケーションが、ノード間の通信機能の障害のために整合性のない状態になる可能性もあります。他に発生する可能性のある問題は、複数のノードが「プライマリ」になることです。これは、別々のノードが自身がクラスター内の唯一のノードであると認識することで発生します。 異なるデータセンターに配置されたクラスターのノードを使用でき、必ずしも同じ LAN に配置されている必要はありませんが、いくつか制限事項がある点に注意してください。 この「スプリットブレーン」処理動作を防ぐには、Quorum プロトコルを有効にする必要があります。このプロトコルは、ノードの 1 つのセットがデータの処理を続行し、他のセットが再接続されるまで共有データに関して何も実行しないようにするために使用されます。基本的に、切断が発生した場合、ノードが最も多い方のみが稼働し続けます。たとえば、2 つのデータセンターがあり、一方は 3 つのノードがあり、もう一方には 2 つのノードがあるとします。2 つのノードがあるデータセンターで接続の問題が発生した場合、ノードが 3 つのデータセンターが機能し続け、もう一方のデータセンターは停止します。ノードが 3 つのデータセンターがオフラインになった場合、どちらのノードも機能しなくなります。こうした機能停止を防ぐには、少なくとも 3 つの同じ数のノードを持つデータセンターでクラスターを作成する必要があります。2 つのデータセンターがクラッシュすることは考えにくいため、1 つのデータセンターがオフラインになったり、ネットワーク障害によって他のデータセンターから分離されたりしても、クラスターは常に機能し続けることになります。
機能するのに十分なノードがクラスターパーティションにない場合、外部システムコールに対しては引き続き反応しますが、オブジェクトストアを経由したすべての操作は失敗し、データ生成できなくなります。
#### [](#制限事項)制限事項 - Quorum はオブジェクトストア関連の操作でのみサポートされます。 - 分散ロッキングはサポートされず、以下に影響を及ぼします。 - ファイルの並列に関するファイル/FTP Connector ポーリング - 冪等性再配信ポリシーコンポーネント - 冪等性メッセージ検索条件コンポーネント - メモリ内メッセージングはサポートされず、以下に影響を及ぼします。 - VM Connector - Quorum 機能は手動でのみ設定できます。 - 一括処理ジョブでは高可用性機能が使用されません。 ## [](#クラスタリングと負荷分散)クラスタリングと負荷分散 TCP 要求 (この場合、TCP には SSL/TLS、UDP、Multicast、HTTP、HTTPS が含まれる) に対応するために Mule クラスターが使用される場合、クラスタリングされたインスタンス間で要求を分散するためにある程度の負荷分散が必要になります。Anypoint Runtime Fabric には基盤となる Docker Kubernetes (K8s) インフラストラクチャの一部としてロードバランサー機能が含まれていますが、お客様がホストし、手動でプロビジョニングされたクラスターでは、サードパーティのロードバランサーを提供するか、クライアント側で負荷分散とフェールオーバーを実行する必要があります。 さまざまなソフトウェアのロードバランサーが使用できますが、そのうちの 2 つを紹介します。 - オープンソースの HTTP サーバーおよびリバースプロキシである Nginx。HTTP(S) の負荷分散に NGINX の ​`HttpUpstreamModule`​ を使用できます。 - Apache Web サーバー。これは HTTP(S) ロードバランサーとしても使用できます。 TCP と HTTP または HTTPS トラフィックの両方をルーティングできるハードウェアのロードバランサーも多数あります。 ## [](#cluster-high-performance)高パフォーマンス用のクラスタリング このセクションは、お客様がホストし、手動でプロビジョニングされたクラスターデプロイメントにのみ適用されます。 その他のデプロイメントオプションについての詳細は、​[「デプロイメント戦略」](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)​を参照してください。 (信頼性ではなく) 高パフォーマンスが最大目標の場合は、パフォーマンスプロファイルを使用してパフォーマンスが最大になるように Mule クラスターまたは各アプリケーションを設定できます。クラスター内で特定のアプリケーションのパフォーマンスプロファイルを実装することで、デプロイメントの拡張性を最大にすると同時に、パフォーマンスおよび信頼性の要件が異なるアプリケーションを同じクラスターにデプロイすることができます。コンテナレベルで設定したパフォーマンスプロファイルは、そのコンテナ内のすべてのアプリケーションに適用されます。アプリケーションレベルの設定はコンテナレベルの設定より優先されます。 ### [](#パフォーマンスプロファイルの設定に関する考慮事項)パフォーマンスプロファイルの設定に関する考慮事項 パフォーマンスプロファイルの設定には 2 つの効果があります。 - 分散キューが無効になり、代わりにローカルキューを使用して共有データグリッドにおけるデータの逐次化/非逐次化および分散を防止します。 - バックアップなしでオブジェクトストアを実装し、複製を防止します。
1 つのノードがダウンしたら、そのノードに関連付けられているデータが失われます。
パフォーマンスプロファイルを設定しても、メモリ共有には影響しません。クラスターモードでは、オブジェクトストアはノード間で常に分散し、共有されます。 ### [](#パフォーマンスプロファイルの設定)パフォーマンスプロファイルの設定 _コンテナ_​レベルでパフォーマンスプロファイルを設定するには、次のコマンドを ​`mule-cluster.properties`​、システムプロパティ (コマンドラインから)、または ​`wrapper.conf`​ に追加します。 `mule.cluster.storeprofile=performance` _個別のアプリケーション_​レベルでパフォーマンスプロファイルを設定するには、以下で示しているように、設定ラッパー内にプロファイルを追加します。 - パフォーマンスストアプロファイル ```xml ``` アプリケーションレベルの設定はコンテナレベルの設定より優先されます。高パフォーマンス用にコンテナを設定するが、そのコンテナ内の 1 つ以上の個別のアプリケーションでは信頼性を優先するには、こうしたアプリケーションに次のコードを含めます。 - 信頼性ストアプロファイル ```xml ```

負荷分散をサポートしないエンドポイントで負荷が大きい場合、パフォーマンスプロファイルを適用するとパフォーマンスが低下する場合もあります。非同期処理戦略、ロードバランサーがない JMS トピック、マルチキャスト、または HTTP Connector でファイルベースのコネクタを使用している場合、大量のメッセージが単一ノードに入るとボトルネックが発生する可能性があるため、こうしたアプリケーションのパフォーマンスプロファイルを無効にしたほうがパフォーマンスが向上する場合があります。
稼働状態を保つためにクラスターで必要なマシンの最小数を定義することもできます。この設定により、パフォーマンス全体での一貫性が改善されます。 ## [](#クラスターノード間の通信の暗号化)クラスターノード間の通信の暗号化 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルでまたはシステムプロパティとして定義することで、クラスターノード間のトラフィックを暗号化できます。 暗号化鍵を定義すると、定義した鍵と AES 暗号化アルゴリズムを使用してクラスターノード間のすべての通信が暗号化されます。 ## [](#cluster_fips)FIPS モードでのクラスタリングの有効化 FIPS モードでのクラスタリングを有効化するには、次のタスクを完了します。 - FIPS モードで Mule Runtime Engine を実行します。 設定の手順は、​[「FIPS コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.7/fips-140-2-compliance-support)​を参照してください。 - クラスターノード間の通信を暗号化します。 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルで定義するか、システムプロパティとして定義します。 ### [](#警告)警告 - 暗号化鍵を定義しない場合、アプリケーションはデプロイに失敗し、​`Cluster key must be defined in FIPS mode.`​ というメッセージが表示されます。 - クラスタリングされたすべてのノードで同じ暗号化鍵を使用しない場合、この機能は動作しません。 - FIPS モードでクラスタリングされた環境を実行すると、ノード間のすべての通信が暗号化 (および復号化) されるため、パフォーマンスが低下します。 ## [](#クラスタリングのベストプラクティス)クラスタリングのベストプラクティス クラスタリングに関しては多くの推奨事項があります。例を挙げます。 - できるだけアプリケーションを一連のステップに整理し、各ステップがメッセージを 1 つのトランザクションストアから別のトランザクションストアに移動するようにします。 - アプリケーションで非トランザクションコネクタからのメッセージを処理する場合、​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.7/reliability-patterns)​を使用して VM や JMS ストアなどのトランザクションストアに移動します。 - トランザクションを使用してトランザクションコネクタからのメッセージを処理します。これにより、エラーが発生した場合、メッセージが再処理されるようになります。 - VM や JMS Connector で使用するような分散ストアを使用します。こうしたストアはクラスター全体に対して使用可能です。これは、ファイル、FTP、JDBC などのコネクタで使用する非分散ストアよりも優れています。こうしたストアは一度に単一のノードによって読み取られます。 - VM Connector を使用して最適なパフォーマンスを得ます。クラスター全体が終了した後にデータを保存する必要があるアプリケーションに JMS Connector を使用します。 - 高信頼性アプリケーションを作成するには信頼性パターンを実装します。 - HA クラスターモードでは、すべてのオブジェクトストアコンテンツ (メモリ内コンテンツと、​`persistent`​ パラメーターで定義される永続的なコンテンツの両方) は、分散メモリグリッドに保存されます。クラスターでクォーラムが保持されている限り、このデータはアプリケーションの再デプロイまたは再起動後も存続します。オブジェクトストアコンテンツを完全にクリアするには、再起動する前にすべてのクラスターノードを停止する必要があります。クラスターの完全シャットダウン後もデータの永続性が必要なシナリオでは、メモリグリッドの代わりに JDBC ベースのストアを使用するようにオブジェクトストアを設定します。​[「オブジェクトストアの永続性」](https://docs.mulesoft.com/jp/mule-runtime/4.7/creating-and-managing-a-cluster-manually#object-store-persistence)​を参照してください。 ## [](#関連情報)関連情報 - [Enterprise ライセンスのインストール](https://docs.mulesoft.com/jp/mule-runtime/4.7/installing-an-enterprise-license) - [サーバーの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-servers#create-a-cluster) - [CloudHub 高可用性および障害回復](https://docs.mulesoft.com/cloudhub/cloudhub-hadr) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/creating-and-managing-a-cluster-manually) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management) - [クォーラム管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/creating-and-managing-a-cluster-manually#quorum-management) # Mule Runtime 高可用性 (HA) クラスターの概要
CloudHub でのクラスタリングに相当するものの場合、アプリケーションを拡大し、高可用性を提供するためにワーカーを共有または二重化する方法の詳細は、​CloudHub 高可用性​を参照してください。
Mule Enterprise Edition は拡張可能なクラスタリングをサポートし、オンプレミスアプリケーションの高可用性 (HA) を実現しています。 クラスターとは、ユニットとして機能する Mule Runtime Engine のセットです。言い換えると、クラスターとは複数のノード (Mule Runtime Engine) で構成された仮想サーバーです。クラスター内のノードは分散された共有メモリグリッドを通じて通信を行い、オブジェクトストアと VM キューのデータを共有します。つまり、データがさまざまなマシンのメモリ間で複製されます。 この複製された状態の共有メモリグリッドは、次のものに適用されます。 - 永続的または非永続的なオブジェクトストア - 永続的または一時的な VM キュー - Mule Runtime LockFactory ![分散共有メモリが含まれる複数のクラスターノード](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/cluster.png)
この機能の価格については、カスタマーサービス担当者にお問い合わせください。
## [](#クラスタリングの利点)クラスタリングの利点 デフォルトでは、Mule Runtime Engine のクラスタリングにより、システムの高可用性を実現できます。障害や計画的なダウンタイムが原因で Mule Runtime Engine ノードが使用不可になった場合、クラスター内の別のノードがワークロードを引き継ぎ、VM キューからのメッセージの処理やその他の要求のサービスを続行できます。次の図は、2 ノードのクラスターによる受信メッセージの処理を示しています。処理負荷がノード間で分散されているのがわかります。ノード 1 がメッセージ 1 を処理するのと同時に、ノード 2 はメッセージ 2 を処理します。 ![複数のノードと 1 つのクライアントが含まれるフェールオーバープロセス](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/failovernofail.png) 一方のノードで障害が発生した場合、もう一方の障害の発生していないノードが障害の発生しているノードの作業を引き継ぎます。外部ロードバランサーが障害の発生しているノードのトラフィックをアクティブなノードにリダイレクトするか、VM キューを通じてアクティブなノードがインフライトメッセージの処理を続行できるようにします。次の図で示しているように、ノード 2 で障害が発生した場合、ノード 1 はメッセージ 1 とメッセージ 2 の両方を処理します。 ![クラスター内に 2 つのノードと 1 つのクライアントが含まれるフェールオーバープロセス](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/failovernode2fail.png) Mule Runtime Engine のクラスターではすべてのノードが同時に「アクティブ-アクティブ」になりメッセージを処理できるため、クラスターによってパフォーマンスおよび拡張性も向上します。単一ノードのインスタンスと比較すると、クラスターのほうがサポートできるユーザーも多く、ワークロードを複数のノードで共有するかノードをクラスターに追加することで、アプリケーションのパフォーマンスも向上できます。アプリケーションによっては水平方向にスケーリングまたはクラスタリングを行ってもパフォーマンスが向上しないものもあります。パフォーマンスは追加ノードと共有される作業の性質によって異なります。オブジェクトストアを多用するアプリケーションの中には、共有メモリグリッド内のデータの複製やアクセスの調整に必要な作業のために、パフォーマンスが低下するものもあります。 次の図では、ワークロードの共有をより詳しく示しています。両方のノードが受注処理に関するメッセージを処理します。ただし、一方のノードの負荷が大きい場合、その処理の 1 つ以上のステップの処理をもう一方のノードに移動できます。ここでは、割引処理ステップの処理がノード 1 に移動され、受注ステップの処理がノード 2 に移動されています。 ![注文とメッセージを処理するノードが含まれるクラスター](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/cluster-diagram.png) 自動フェールオーバーによる高可用性、パフォーマンスの向上、拡張性の向上以外に、Mule Runtime Engine のクラスタリングには次のような利点があります。 - ファイル、データベース、FTP ソースなどのリソースへのアクセスの自動調整。 Mule Runtime Engine クラスターは、どのノード (Mule Runtime Engine) がデータソースからの通信を処理するかを自動的に管理します。 - クラスター内の処理の自動負荷分散。 フローを一連のステップに分割してこれらのステップを VM などのコネクタと接続すると、各ステップはキューに入り、クラスターが有効になります。続いて、Mule Runtime Engine のクラスターが任意のノードで各ステップを処理し、ノード間で負荷がより効率的に分散されます。 - アラートの生成。 ノードがダウンした場合やノードが復活したときに表示されるアラートをセットアップできます。
クラスターのすべての Mule Runtime Engine はアクティブにメッセージを処理します。各 Mule ノードは垂直方向にも拡張可能です。単一のノードでも複数のコアや追加メモリを活用することで拡張できます。Mule は複数のコアを使用する場合であっても、クラスターでは単一のノードとして動作します。
### [](#クラスターによって解決される同時実行の問題)クラスターによって解決される同時実行の問題 クラスターとしてバインドされていない複数のサーバーで構成されたサーバーグループがある場合、次のような問題が存在する可能性があります。サーバーをクラスターとしてグループ化すれば、こうした問題に頭を悩ませることはありません。 - ファイルベースのコネクタ。 すべての Mule インスタンスは同じ Mule ファイルフォルダーに同時にアクセスするため、ファイル処理が重複することもあれば、ファイルが Mule アプリケーションによって削除または変更された場合には障害が発生する可能性もあります。 - マルチキャストコネクタ。 すべての Mule インスタンスは同じ TCP 要求を受けてから重複メッセージを処理します。 - JMS トピック。 すべての Mule インスタンスは同じ JMS トピックに接続するため、非クラスタリング Mule インスタンスを水平方向に拡張した場合、メッセージの処理が反復される場合もあります。JMS ブローカーからは、インスタンスは別々のサブスクライバーのように見え、そのすべてが各メッセージのコピーを取得します。この動作が必要となるのはまれです。このシナリオを避けるために、「共有サブスクライバー」設定を使用できます。この設定によって、JMS ブローカーに、すべてのインスタンスを結合サブスクライバーとして扱い、それぞれ別個のメッセージを与えるように指示できます。 - JMS request-reply (要求-返信)/request-response (要求-応答)。 すべての Mule インスタンスは同じ応答キューでメッセージをリスンします。これは、Mule インスタンスが送信した要求に相関していない応答を受け取る可能性があり、結果として不正な応答になったりフローがタイムアウトにより失敗したりする場合があることを意味します。 - 冪等性再配信ポリシーと冪等性メッセージ検証。 水平スケーリングで同じ要求を異なる Mule インスタンスが受信し、再配信ポリシーまたは Idempotency Message Validator で使用されるオブジェクトストアコンテンツがローカライズされている場合、冪等性が正しく機能しません。このような冪等性機能で使用されるオブジェクトストア値を共有するクラスターの場合、すべてのノードがすでに処理済みの識別子のリストを共有しているため、メッセージの重複は起こり得ません。 - Salesforce ストリーミング API。 同じアプリケーションの複数のインスタンスをデプロイした場合、API は単一コンシューマーしかサポートしていないため、失敗します。接続されているインスタンスが停止またはクラッシュした場合のフェールオーバーのサポートはありません。 ## [](#前提条件)前提条件 - クラスターには少なくとも 2 個の Mule Runtime Engine インスタンスが必要であり、マシン上で障害が 1 か所に集中することを防ぐため、それぞれを異なるマシンで実行する必要があります。 - Mule 高可用性 (HA) では、クラスターのノード間の同期を維持するために、サーバー間に信頼性の高いネットワーク接続が必要です。 - Mule クラスター用に設定されたポートを開いたままにします。 - Runtime Manager を使用してクラスターをセットアップし、デフォルトポートを使用する場合、TCP ポート ​`5701`​、​`5702`​、および ​`5703`​ を開いたままにします。 - 代わりにカスタムポートを設定する場合、カスタムポートを開いたままにします。 - ポート ​`5701`​ を介してノード間の通信が開いていることを確認します。 ネットワーク内のファイアウォールルールを検証して、ノード間の双方向通信が有効になっていることを確認します。 クラスターでマルチキャストを有効にする場合、前述の前提条件に加えて次の要件も適用されます。 - UDP ポート ​`54327`​ を開いたままにします。 - マルチキャスト IP アドレス ​`224.2.2.3`​ を有効にします。 ## [](#高可用性)高可用性 高可用性とは、そこで実行されるアプリケーションのダウンタイムを防止するようにコンピューターシステムをデザインする方法です。一部のシステムでは 1 台のサーバーでダウンタイムが発生しても、アプリケーションはアプリケーションのエンドユーザーに対するサービスの提供を中断することなく他のサーバーでスムーズに実行し続けることができるように、複数のサーバーを使用しています。 ## [](#クラスターのデザインと管理)クラスターのデザインと管理 Anypoint Runtime Manager は、Mule インスタンスの顧客がホストするクラスターをセットアップしてアプリケーションをデプロイしてクラスターで実行できるようにします。クラスターおよび個別のノードの状況に関する情報を監視することもできます。クラスタリングを行うと、複数のサーバーを 1 台として容易に管理できます。
クラスター管理についての詳細は、Runtime Manager の​「Managing Servers (サーバーの管理)」​を参照してください。
Anypoint Runtime Fabric では、デプロイメント時に Mule Runtime レプリカをクラスターモードでプロビジョニングするオプションがあります。 Mule クラスターは、2 つ以上の Mule Runtime Engine、またはノードで構成され、グループにまとめられて単一ユニットとして扱われます。初期設定の場合、クラスターの拡張は 8 個の Mule Runtime Engine までにすることをお勧めします。 Anypoint Runtime Manager を使用すれば、クラスター内のすべての Mule Runtime Engine を単一の Mule Runtime Engine であるかのようにデプロイ、監視、および停止することができます。 注意: CloudHub ではプロビジョンされたワーカーにこのクラスタリング設定を使用しませんが、同等の環境を提供する他の高可用性機能があります。たとえば、Anypoint Object Store (OSv2) を介した外部化された状態管理や、永続的なキュー配置機能 (VM キューをワーカーの外部に移すことで、共有可能にして再プロビジョニングの際も存続するようにする) などです。 次に示すように、クラスター内のすべてのノードはメモリを共有します。 ![ノード間のメッセージのフローを示す矢印が表示されているノードクラスター](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/topology-4-cluster.png)
動作のパフォーマンスを確保するために、Mule は active-active (アクティブ-アクティブ) モデルを使用して Mule Runtime Engine をクラスタリングします。active-passive (アクティブ-パッシブ) モデルに対するこのモデルのメリットは、アプリケーションがすべてのノードで実行され、メッセージ処理をクラスター内の他のノードと分け合うことで、処理を効率化できることです。
### [](#プライマリノードの違い)プライマリノードの違い active-active (アクティブ-アクティブ) モデルでは、すべてのノードが処理を実行できます。ただし、いずれか 1 つのノードがプライマリノードとして機能し、スケジューラーやその他の「プライマリノードのみ」とマークされているイベントソースを実行します。このモデルでは、クラスター内の 1 つのプライマリポーリングノードでソースが実行され、クラスター内の他のノードはそれらのソースからのメッセージを読めないように設定できます。 この機能は、ソース種別に応じて異なります。 - スケジューラーソース: プライマリポーリングノードでのみ実行されます。 - 他のソース: `primaryNodeOnly`​ 属性で定義されます。そのコネクタの ​`primaryNodeOnly`​ のデフォルト値を調べるには、各コネクタのドキュメントを確認してください。 JMS の設定例: ```xml ``` この例は、逐次/一度に 1 つのメッセージの処理が必要な状況でアプリケーションが JMS からメッセージを受信するユースケースのものと考えられます。JMS Connector の On New Message ソースのデフォルト設定では、デフォルトで \[Primary Node Only (プライマリノードのみ)\] が選択されていますが、ほとんどのコネクタソースでは \[Primary Node Only (プライマリノードのみ)\] は選択されていません。デフォルト設定の決定はコネクタの開発者が行います。すべてのノードで処理を実行する必要があるユースケースでは、開発者はすべてのクラスターノードでソースが有効になるように primaryNodeOnly 値の選択を解除します。 ## [](#queues)Queues コードの実行とフロー参照によるフローのコールは、イベントの実行が開始されたのと同じノードで行われます。ただし、クラスタリングされた Mule Runtime で実行を共有または分散するために、VM キューをセットアップして VM キューに明示的にパブリッシュすることでノード間で負荷を分散できます。永続的な VM キューと一時的な VM キューのいずれでもクラスターの共有メモリグリッドが使用され、VM キューを介したあらゆる移行は別のアクティブなノードにジャンプする可能性があります。そのため、アプリケーションフロー全体に VM キューのパブリッシャー/リスナーによってリンクされた子フローのシーケンスが含まれる場合、クラスターは連続する各子フローをその時点で使用可能な任意の Mule Runtime Engine に割り当てることができます。下で示しているように、クラスターはアプリケーションフローの VM キューを通過するときに複数のノードで単一メッセージを処理することもできます。 ![さまざまなフロープロセスで負荷分散するように設計された 4 つのノードの Mule クラスター](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/load-balancing.png) ## [](#高信頼性アプリケーション)高信頼性アプリケーション 高信頼性アプリケーションと言えるには、以下の要件を満たす必要があります。 1. メッセージの損失の許容がゼロであること 2. インテグレーションエンジン (Mule) が信頼できること 3. 個別の接続の信頼性が高いこと トランザクション性として知られる機能はアプリケーションイベントシーケンスを追跡し、それぞれのメッセージ処理ステップが正常に完了するようにします。そのため、失われたり不正に処理されたりするメッセージはありません。何らかの理由でステップが失敗した場合、トランザクションメカニズムが以前の処理イベントをすべてロールバックし、メッセージ処理シーケンスを再開します。 JMS、VM、JDBC などのコネクタにより、ビルトイントランザクションサポートが提供されるため、メッセージが確実に処理されるようになります。たとえば、トランザクションがコミットされた後でのみメッセージを JMS サーバーから削除するようにインバウンド JMS 接続エンドポイントでトランザクションを設定できます。この方法により、処理フロー中にエラーが発生した場合、元のメッセージは再処理できる状態で保持されます。 トランザクションをサポートする異種コネクタ間でメッセージを移動するには、XA トランザクションを使用する必要があります。これにより、Mule Runtime Engine はすべての異種コネクタの関連付けられたトランザクションを単一ユニットとしてコミットするようになります。
トランザクションは、コネクタがトランザクションをサポートしないシステムでのインタラクションや操作を対象とすることはできません。そのため、関連する操作の中にトランザクションに含めることができないものがある場合には、 Sagas​ などの代替パターンを代わりに使用します。
## [](#コネクタのクラスターサポート)コネクタのクラスターサポート すべての Mule Connector がクラスター内でサポートされます。コネクタごとにインバウンドトラフィックにアクセスする方法が異なるため、このサポートの詳細は異なります。一般に、アウトバウンドトラフィックはクラスター内外で同じように機能します。Mule Runtime は 3 つの基本的な種別のコネクタをサポートしています。 ### [](#ソケットベースのコネクタ)ソケットベースのコネクタ ソケットベースのコネクタは Mule が所有するネットワークソケットに送信された入力を読み取ります。例としては TCP、UDP、HTTP\[S\] などがあります。 ソケットベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - クラスタリングされた各 Mule Runtime は異なるネットワークノードで実行されるため、各インスタンスはそのノードに送信されたソケットベースのトラフィックのみを受信します。受信したソケットベースのトラフィックは、クラスタリングされたインスタンス間で分散するために​[\[Clustering and Load Balancing\]](<#Clustering and Load Balancing>)​を実行する必要があります。 - ソケットベースのコネクタへの出力は特定のホスト/ポートの組み合わせに書き込まれます。ホスト/ポートの組み合わせが外部ホストの場合、特に考慮事項はありません。ローカルホストのポートの場合、クラスター間でより効率的にトラフィックを分散するために、代わりにロードバランサーでそのポートを使用することを検討してください。 ### [](#リスナーベースのコネクタ)リスナーベースのコネクタ リスナーベースのコネクタは同時の複数アクセサーを十分にサポートするプロトコルを使用してデータを読み取ります。例としては、JMS や VM があります。 リスナーベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - リスナーベースのコネクタは複数のリーダーおよびライターを完全にサポートしています。入力にも出力にも特に考慮事項はありません。 - クラスターでは、VM Connector キュー (永続的と一時的の両方) が共有のクラスター全体のリソースである点に注意してください。クラスターは VM Connector キューへのアクセスを自動的に同期します。そのため、任意のクラスターノードで VM キューに書き込まれたメッセージを処理できます。これにより、VM はクラスターノード間でワークを共有するのに最適です。 ### [](#リソースベースのコネクタ)リソースベースのコネクタ リソースベースのコネクタは複数の同時アクセサーは使用可能だがリソースの使用をネイティブに調整しないリソースからデータを読み取ります。リソースベースのコネクタの例としては、ファイル、FTP、SFTP、メール、JDBC などがあります。 リソースベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - Mule HA クラスタリングは自動的にクラスター内のノードのみについて各リソースへのアクセスを調整するため、クラスタリングされたインスタンスのうち 1 つだけが一度に各リソースにアクセスするようになります。そのため、通常はリソースベースのコネクタから読み取られたメッセージをすぐに VM キューに書き込むことをお勧めします。これにより、他のクラスターノードがメッセージの処理に参加できます。

クラスター内のノードとして同じリソースにアクセスする他のアプリケーション (クラスター外の Mule アプリケーションまたは Mule 以外のアプリケーション) を実行する場合は、これらのリソースをロックするロジックを実装する必要があります。

たとえば、複数のプログラムがファイルの読み取り、変更、そして削除を行うことで、同じ共有ディレクトリのファイルを処理しているとします。これらのプログラムは明示的なアプリケーションレベルのロッキング戦略を使用して、同じファイルが複数回処理されないようにする必要があります。
- リソースベースのクラスタリングされたコネクタへの書き込みには特に考慮事項はありません。 - ファイルベースのコネクタ (ファイル、FTP、SFTP) に書き込むときに、Mule は一意のファイル名を生成します。 - JDBC に書き込むときに、Mule は一意のキーを生成できます。 - メールの作成は、実質的にはリソースベースではなくリスナーベースです。 ## [](#クラスタリングと信頼性の高いアプリケーション)クラスタリングと信頼性の高いアプリケーション 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。クラスターで十分に信頼できるアプリケーションをビルドするためのツールは​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.8/reliability-patterns)​で見つかります。 アプリケーションで非トランザクションコネクタを使用している場合、信頼性パターンに従ってください。これらのパターンにより、メッセージが受け入れられて正常に処理されるか、「失敗」応答を生成してクライアントが再試行できるようになります。 アプリケーションで JMS、VM、JDBC などのトランザクションコネクタを使用している場合は、トランザクションを使用します。トランザクションコネクタに対する Mule のビルトインサポートにより、こうしたコネクタを使用するアプリケーションで信頼性の高いメッセージングを実現できます。 これらのアクションは、クラスタリングされていないアプリケーションにも適用できます。 ## [](#クラスタリングとネットワーキング)クラスタリングとネットワーキング ### [](#単一のデータセンターのクラスタリング)単一のデータセンターのクラスタリング クラスターノード間で信頼性のある接続を確立するには、クラスターのすべてのノードを同じ LAN に配置する必要があります。VPN を通じて接続された異なるデータセンターなど、地理的に離れた場所にノードが含まれるクラスターを実装することも可能ですが、お勧めはしません。 ネットワークの中断や、メッセージの重複などの意図しない結果を招く可能性を下げるためには、すべてのクラスターノードを同じ LAN に配置するのが最もお勧めです。 ### [](#分散型データセンターのクラスタリング)分散型データセンターのクラスタリング WAN ネットワークを使用してクラスターノードをリンクすると、外部ルーターやファイアウォールなど、障害が発生する可能性のあるポイントが多くなり、クラスターノード間で適切に同期が行われないおそれがあります。これはパフォーマンスに影響を及ぼすだけでなく、アプリケーションにおける副作用の可能性を考慮に入れる必要も生じます。たとえば、2 つのクラスターノードがネットワークリンクの障害による切断後に再接続した場合、次回の同期プロセスでメッセージが 2 回処理される可能性があり、重複が発生して、アプリケーションロジックで処理する必要が生じます。また、オブジェクトストアを使用しているアプリケーションが、ノード間の通信機能の障害のために整合性のない状態になる可能性もあります。他に発生する可能性のある問題は、複数のノードが「プライマリ」になることです。これは、別々のノードが自身がクラスター内の唯一のノードであると認識することで発生します。 異なるデータセンターに配置されたクラスターのノードを使用でき、必ずしも同じ LAN に配置されている必要はありませんが、いくつか制限事項がある点に注意してください。 この「スプリットブレーン」処理動作を防ぐには、Quorum プロトコルを有効にする必要があります。このプロトコルは、ノードの 1 つのセットがデータの処理を続行し、他のセットが再接続されるまで共有データに関して何も実行しないようにするために使用されます。基本的に、切断が発生した場合、ノードが最も多い方のみが稼働し続けます。たとえば、2 つのデータセンターがあり、一方は 3 つのノードがあり、もう一方には 2 つのノードがあるとします。2 つのノードがあるデータセンターで接続の問題が発生した場合、ノードが 3 つのデータセンターが機能し続け、もう一方のデータセンターは停止します。ノードが 3 つのデータセンターがオフラインになった場合、どちらのノードも機能しなくなります。こうした機能停止を防ぐには、少なくとも 3 つの同じ数のノードを持つデータセンターでクラスターを作成する必要があります。2 つのデータセンターがクラッシュすることは考えにくいため、1 つのデータセンターがオフラインになったり、ネットワーク障害によって他のデータセンターから分離されたりしても、クラスターは常に機能し続けることになります。
機能するのに十分なノードがクラスターパーティションにない場合、外部システムコールに対しては引き続き反応しますが、オブジェクトストアを経由したすべての操作は失敗し、データ生成できなくなります。
#### [](#制限事項)制限事項 - Quorum はオブジェクトストア関連の操作でのみサポートされます。 - 分散ロッキングはサポートされず、以下に影響を及ぼします。 - ファイルの並列に関するファイル/FTP Connector ポーリング - 冪等性再配信ポリシーコンポーネント - 冪等性メッセージ検索条件コンポーネント - メモリ内メッセージングはサポートされず、以下に影響を及ぼします。 - VM Connector - Quorum 機能は手動でのみ設定できます。 - 一括処理ジョブでは高可用性機能が使用されません。 ## [](#クラスタリングと負荷分散)クラスタリングと負荷分散 TCP 要求 (この場合、TCP には SSL/TLS、UDP、Multicast、HTTP、HTTPS が含まれる) に対応するために Mule クラスターが使用される場合、クラスタリングされたインスタンス間で要求を分散するためにある程度の負荷分散が必要になります。Anypoint Runtime Fabric には基盤となる Docker Kubernetes (K8s) インフラストラクチャの一部としてロードバランサー機能が含まれていますが、お客様がホストし、手動でプロビジョニングされたクラスターでは、サードパーティのロードバランサーを提供するか、クライアント側で負荷分散とフェールオーバーを実行する必要があります。 さまざまなソフトウェアのロードバランサーが使用できますが、そのうちの 2 つを紹介します。 - オープンソースの HTTP サーバーおよびリバースプロキシである Nginx。HTTP(S) の負荷分散に NGINX の ​`HttpUpstreamModule`​ を使用できます。 - Apache Web サーバー。これは HTTP(S) ロードバランサーとしても使用できます。 TCP と HTTP または HTTPS トラフィックの両方をルーティングできるハードウェアのロードバランサーも多数あります。 ## [](#cluster-high-performance)高パフォーマンス用のクラスタリング このセクションは、お客様がホストし、手動でプロビジョニングされたクラスターデプロイメントにのみ適用されます。 その他のデプロイメントオプションについての詳細は、​[「デプロイメント戦略」](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)​を参照してください。 (信頼性ではなく) 高パフォーマンスが最大目標の場合は、パフォーマンスプロファイルを使用してパフォーマンスが最大になるように Mule クラスターまたは各アプリケーションを設定できます。クラスター内で特定のアプリケーションのパフォーマンスプロファイルを実装することで、デプロイメントの拡張性を最大にすると同時に、パフォーマンスおよび信頼性の要件が異なるアプリケーションを同じクラスターにデプロイすることができます。コンテナレベルで設定したパフォーマンスプロファイルは、そのコンテナ内のすべてのアプリケーションに適用されます。アプリケーションレベルの設定はコンテナレベルの設定より優先されます。 ### [](#パフォーマンスプロファイルの設定に関する考慮事項)パフォーマンスプロファイルの設定に関する考慮事項 パフォーマンスプロファイルの設定には 2 つの効果があります。 - 分散キューが無効になり、代わりにローカルキューを使用して共有データグリッドにおけるデータの逐次化/非逐次化および分散を防止します。 - バックアップなしでオブジェクトストアを実装し、複製を防止します。
1 つのノードがダウンしたら、そのノードに関連付けられているデータが失われます。
パフォーマンスプロファイルを設定しても、メモリ共有には影響しません。クラスターモードでは、オブジェクトストアはノード間で常に分散し、共有されます。 ### [](#パフォーマンスプロファイルの設定)パフォーマンスプロファイルの設定 _コンテナ_​レベルでパフォーマンスプロファイルを設定するには、次のコマンドを ​`mule-cluster.properties`​、システムプロパティ (コマンドラインから)、または ​`wrapper.conf`​ に追加します。 `mule.cluster.storeprofile=performance` _個別のアプリケーション_​レベルでパフォーマンスプロファイルを設定するには、以下で示しているように、設定ラッパー内にプロファイルを追加します。 - パフォーマンスストアプロファイル ```xml

負荷分散をサポートしないエンドポイントで負荷が大きい場合、パフォーマンスプロファイルを適用するとパフォーマンスが低下する場合もあります。非同期処理戦略、ロードバランサーがない JMS トピック、マルチキャスト、または HTTP Connector でファイルベースのコネクタを使用している場合、大量のメッセージが単一ノードに入るとボトルネックが発生する可能性があるため、こうしたアプリケーションのパフォーマンスプロファイルを無効にしたほうがパフォーマンスが向上する場合があります。

稼働状態を保つためにクラスターで必要なマシンの最小数を定義することもできます。この設定により、パフォーマンス全体での一貫性が改善されます。 ## [](#クラスターノード間の通信の暗号化)クラスターノード間の通信の暗号化 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルでまたはシステムプロパティとして定義することで、クラスターノード間のトラフィックを暗号化できます。 暗号化鍵を定義すると、定義した鍵と AES 暗号化アルゴリズムを使用してクラスターノード間のすべての通信が暗号化されます。 ## [](#cluster_fips)FIPS モードでのクラスタリングの有効化 FIPS モードでのクラスタリングを有効化するには、次のタスクを完了します。 - FIPS モードで Mule Runtime Engine を実行します。 設定の手順は、​[「FIPS コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.8/fips-140-2-compliance-support)​を参照してください。 - クラスターノード間の通信を暗号化します。 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルで定義するか、システムプロパティとして定義します。 ### [](#警告)警告 - 暗号化鍵を定義しない場合、アプリケーションはデプロイに失敗し、​`Cluster key must be defined in FIPS mode.`​ というメッセージが表示されます。 - クラスタリングされたすべてのノードで同じ暗号化鍵を使用しない場合、この機能は動作しません。 - FIPS モードでクラスタリングされた環境を実行すると、ノード間のすべての通信が暗号化 (および復号化) されるため、パフォーマンスが低下します。 ## [](#クラスタリングのベストプラクティス)クラスタリングのベストプラクティス クラスタリングに関しては多くの推奨事項があります。例を挙げます。 - できるだけアプリケーションを一連のステップに整理し、各ステップがメッセージを 1 つのトランザクションストアから別のトランザクションストアに移動するようにします。 - アプリケーションで非トランザクションコネクタからのメッセージを処理する場合、​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.8/reliability-patterns)​を使用して VM や JMS ストアなどのトランザクションストアに移動します。 - トランザクションを使用してトランザクションコネクタからのメッセージを処理します。これにより、エラーが発生した場合、メッセージが再処理されるようになります。 - VM や JMS Connector で使用するような分散ストアを使用します。こうしたストアはクラスター全体に対して使用可能です。これは、ファイル、FTP、JDBC などのコネクタで使用する非分散ストアよりも優れています。こうしたストアは一度に単一のノードによって読み取られます。 - VM Connector を使用して最適なパフォーマンスを得ます。クラスター全体が終了した後にデータを保存する必要があるアプリケーションに JMS Connector を使用します。 - 高信頼性アプリケーションを作成するには信頼性パターンを実装します。 - HA クラスターモードでは、すべてのオブジェクトストアコンテンツ (メモリ内コンテンツと、​`persistent`​ パラメーターで定義される永続的なコンテンツの両方) は、分散メモリグリッドに保存されます。クラスターでクォーラムが保持されている限り、このデータはアプリケーションの再デプロイまたは再起動後も存続します。オブジェクトストアコンテンツを完全にクリアするには、再起動する前にすべてのクラスターノードを停止する必要があります。クラスターの完全シャットダウン後もデータの永続性が必要なシナリオでは、メモリグリッドの代わりに JDBC ベースのストアを使用するようにオブジェクトストアを設定します。​[「オブジェクトストアの永続性」](https://docs.mulesoft.com/jp/mule-runtime/4.8/creating-and-managing-a-cluster-manually#object-store-persistence)​を参照してください。 ## [](#関連情報)関連情報 - [Enterprise ライセンスのインストール](https://docs.mulesoft.com/jp/mule-runtime/4.8/installing-an-enterprise-license) - [サーバーの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-servers#create-a-cluster) - [CloudHub 高可用性および障害回復](https://docs.mulesoft.com/cloudhub/cloudhub-hadr) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/creating-and-managing-a-cluster-manually) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management) - [クォーラム管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/creating-and-managing-a-cluster-manually#quorum-management) # Mule Runtime 高可用性 (HA) クラスターの概要
CloudHub でのクラスタリングに相当するものの場合、アプリケーションを拡大し、高可用性を提供するためにワーカーを共有または二重化する方法の詳細は、​CloudHub 高可用性​を参照してください。
Mule Enterprise Edition は拡張可能なクラスタリングをサポートし、オンプレミスアプリケーションの高可用性 (HA) を実現しています。 クラスターとは、ユニットとして機能する Mule Runtime Engine のセットです。言い換えると、クラスターとは複数のノード (Mule Runtime Engine) で構成された仮想サーバーです。クラスター内のノードは分散された共有メモリグリッドを通じて通信を行い、オブジェクトストアと VM キューのデータを共有します。つまり、データがさまざまなマシンのメモリ間で複製されます。 この複製された状態の共有メモリグリッドは、次のものに適用されます。 - 永続的または非永続的なオブジェクトストア - 永続的または一時的な VM キュー - Mule Runtime LockFactory ![分散共有メモリが含まれる複数のクラスターノード](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/cluster.png)
この機能の価格については、カスタマーサービス担当者にお問い合わせください。
## [](#クラスタリングの利点)クラスタリングの利点 デフォルトでは、Mule Runtime Engine のクラスタリングにより、システムの高可用性を実現できます。障害や計画的なダウンタイムが原因で Mule Runtime Engine ノードが使用不可になった場合、クラスター内の別のノードがワークロードを引き継ぎ、VM キューからのメッセージの処理やその他の要求のサービスを続行できます。次の図は、2 ノードのクラスターによる受信メッセージの処理を示しています。処理負荷がノード間で分散されているのがわかります。ノード 1 がメッセージ 1 を処理するのと同時に、ノード 2 はメッセージ 2 を処理します。 ![複数のノードと 1 つのクライアントが含まれるフェールオーバープロセス](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/failovernofail.png) 一方のノードで障害が発生した場合、もう一方の障害の発生していないノードが障害の発生しているノードの作業を引き継ぎます。外部ロードバランサーが障害の発生しているノードのトラフィックをアクティブなノードにリダイレクトするか、VM キューを通じてアクティブなノードがインフライトメッセージの処理を続行できるようにします。次の図で示しているように、ノード 2 で障害が発生した場合、ノード 1 はメッセージ 1 とメッセージ 2 の両方を処理します。 ![クラスター内に 2 つのノードと 1 つのクライアントが含まれるフェールオーバープロセス](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/failovernode2fail.png) Mule Runtime Engine のクラスターではすべてのノードが同時に「アクティブ-アクティブ」になりメッセージを処理できるため、クラスターによってパフォーマンスおよび拡張性も向上します。単一ノードのインスタンスと比較すると、クラスターのほうがサポートできるユーザーも多く、ワークロードを複数のノードで共有するかノードをクラスターに追加することで、アプリケーションのパフォーマンスも向上できます。アプリケーションによっては水平方向にスケーリングまたはクラスタリングを行ってもパフォーマンスが向上しないものもあります。パフォーマンスは追加ノードと共有される作業の性質によって異なります。オブジェクトストアを多用するアプリケーションの中には、共有メモリグリッド内のデータの複製やアクセスの調整に必要な作業のために、パフォーマンスが低下するものもあります。 次の図では、ワークロードの共有をより詳しく示しています。両方のノードが受注処理に関するメッセージを処理します。ただし、一方のノードの負荷が大きい場合、その処理の 1 つ以上のステップの処理をもう一方のノードに移動できます。ここでは、割引処理ステップの処理がノード 1 に移動され、受注ステップの処理がノード 2 に移動されています。 ![注文とメッセージを処理するノードが含まれるクラスター](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/cluster-diagram.png) 自動フェールオーバーによる高可用性、パフォーマンスの向上、拡張性の向上以外に、Mule Runtime Engine のクラスタリングには次のような利点があります。 - ファイル、データベース、FTP ソースなどのリソースへのアクセスの自動調整。 Mule Runtime Engine クラスターは、どのノード (Mule Runtime Engine) がデータソースからの通信を処理するかを自動的に管理します。 - クラスター内の処理の自動負荷分散。 フローを一連のステップに分割してこれらのステップを VM などのコネクタと接続すると、各ステップはキューに入り、クラスターが有効になります。続いて、Mule Runtime Engine のクラスターが任意のノードで各ステップを処理し、ノード間で負荷がより効率的に分散されます。 - アラートの生成。 ノードがダウンした場合やノードが復活したときに表示されるアラートをセットアップできます。
クラスターのすべての Mule Runtime Engine はアクティブにメッセージを処理します。各 Mule ノードは垂直方向にも拡張可能です。単一のノードでも複数のコアや追加メモリを活用することで拡張できます。Mule は複数のコアを使用する場合であっても、クラスターでは単一のノードとして動作します。
### [](#クラスターによって解決される同時実行の問題)クラスターによって解決される同時実行の問題 クラスターとしてバインドされていない複数のサーバーで構成されたサーバーグループがある場合、次のような問題が存在する可能性があります。サーバーをクラスターとしてグループ化すれば、こうした問題に頭を悩ませることはありません。 - ファイルベースのコネクタ。 すべての Mule インスタンスは同じ Mule ファイルフォルダーに同時にアクセスするため、ファイル処理が重複することもあれば、ファイルが Mule アプリケーションによって削除または変更された場合には障害が発生する可能性もあります。 - マルチキャストコネクタ。 すべての Mule インスタンスは同じ TCP 要求を受けてから重複メッセージを処理します。 - JMS トピック。 すべての Mule インスタンスは同じ JMS トピックに接続するため、非クラスタリング Mule インスタンスを水平方向に拡張した場合、メッセージの処理が反復される場合もあります。JMS ブローカーからは、インスタンスは別々のサブスクライバーのように見え、そのすべてが各メッセージのコピーを取得します。この動作が必要となるのはまれです。このシナリオを避けるために、「共有サブスクライバー」設定を使用できます。この設定によって、JMS ブローカーに、すべてのインスタンスを結合サブスクライバーとして扱い、それぞれ別個のメッセージを与えるように指示できます。 - JMS request-reply (要求-返信)/request-response (要求-応答)。 すべての Mule インスタンスは同じ応答キューでメッセージをリスンします。これは、Mule インスタンスが送信した要求に相関していない応答を受け取る可能性があり、結果として不正な応答になったりフローがタイムアウトにより失敗したりする場合があることを意味します。 - 冪等性再配信ポリシーと冪等性メッセージ検証。 水平スケーリングで同じ要求を異なる Mule インスタンスが受信し、再配信ポリシーまたは Idempotency Message Validator で使用されるオブジェクトストアコンテンツがローカライズされている場合、冪等性が正しく機能しません。このような冪等性機能で使用されるオブジェクトストア値を共有するクラスターの場合、すべてのノードがすでに処理済みの識別子のリストを共有しているため、メッセージの重複は起こり得ません。 - Salesforce ストリーミング API。 同じアプリケーションの複数のインスタンスをデプロイした場合、API は単一コンシューマーしかサポートしていないため、失敗します。接続されているインスタンスが停止またはクラッシュした場合のフェールオーバーのサポートはありません。 ## [](#前提条件)前提条件 - クラスターには少なくとも 2 個の Mule Runtime Engine インスタンスが必要であり、マシン上で障害が 1 か所に集中することを防ぐため、それぞれを異なるマシンで実行する必要があります。 - Mule 高可用性 (HA) では、クラスターのノード間の同期を維持するために、サーバー間に信頼性の高いネットワーク接続が必要です。 - Mule クラスター用に設定されたポートを開いたままにします。 - Runtime Manager を使用してクラスターをセットアップし、デフォルトポートを使用する場合、TCP ポート ​`5701`​、​`5702`​、および ​`5703`​ を開いたままにします。 - 代わりにカスタムポートを設定する場合、カスタムポートを開いたままにします。 - ポート ​`5701`​ を介してノード間の通信が開いていることを確認します。 ネットワーク内のファイアウォールルールを検証して、ノード間の双方向通信が有効になっていることを確認します。 クラスターでマルチキャストを有効にする場合、前述の前提条件に加えて次の要件も適用されます。 - UDP ポート ​`54327`​ を開いたままにします。 - マルチキャスト IP アドレス ​`224.2.2.3`​ を有効にします。 ## [](#高可用性)高可用性 高可用性とは、そこで実行されるアプリケーションのダウンタイムを防止するようにコンピューターシステムをデザインする方法です。一部のシステムでは 1 台のサーバーでダウンタイムが発生しても、アプリケーションはアプリケーションのエンドユーザーに対するサービスの提供を中断することなく他のサーバーでスムーズに実行し続けることができるように、複数のサーバーを使用しています。 ## [](#クラスターのデザインと管理)クラスターのデザインと管理 Anypoint Runtime Manager は、Mule インスタンスの顧客がホストするクラスターをセットアップしてアプリケーションをデプロイしてクラスターで実行できるようにします。クラスターおよび個別のノードの状況に関する情報を監視することもできます。クラスタリングを行うと、複数のサーバーを 1 台として容易に管理できます。
クラスター管理についての詳細は、Runtime Manager の​「Managing Servers (サーバーの管理)」​を参照してください。
Anypoint Runtime Fabric では、デプロイメント時に Mule Runtime レプリカをクラスターモードでプロビジョニングするオプションがあります。 Mule クラスターは、2 つ以上の Mule Runtime Engine、またはノードで構成され、グループにまとめられて単一ユニットとして扱われます。初期設定の場合、クラスターの拡張は 8 個の Mule Runtime Engine までにすることをお勧めします。 Anypoint Runtime Manager を使用すれば、クラスター内のすべての Mule Runtime Engine を単一の Mule Runtime Engine であるかのようにデプロイ、監視、および停止することができます。 注意: CloudHub ではプロビジョンされたワーカーにこのクラスタリング設定を使用しませんが、同等の環境を提供する他の高可用性機能があります。たとえば、Anypoint Object Store (OSv2) を介した外部化された状態管理や、永続的なキュー配置機能 (VM キューをワーカーの外部に移すことで、共有可能にして再プロビジョニングの際も存続するようにする) などです。 次に示すように、クラスター内のすべてのノードはメモリを共有します。 ![ノード間のメッセージのフローを示す矢印が表示されているノードクラスター](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/topology-4-cluster.png)
動作のパフォーマンスを確保するために、Mule は active-active (アクティブ-アクティブ) モデルを使用して Mule Runtime Engine をクラスタリングします。active-passive (アクティブ-パッシブ) モデルに対するこのモデルのメリットは、アプリケーションがすべてのノードで実行され、メッセージ処理をクラスター内の他のノードと分け合うことで、処理を効率化できることです。
### [](#プライマリノードの違い)プライマリノードの違い active-active (アクティブ-アクティブ) モデルでは、すべてのノードが処理を実行できます。ただし、いずれか 1 つのノードがプライマリノードとして機能し、スケジューラーやその他の「プライマリノードのみ」とマークされているイベントソースを実行します。このモデルでは、クラスター内の 1 つのプライマリポーリングノードでソースが実行され、クラスター内の他のノードはそれらのソースからのメッセージを読めないように設定できます。 この機能は、ソース種別に応じて異なります。 - スケジューラーソース: プライマリポーリングノードでのみ実行されます。 - 他のソース: `primaryNodeOnly`​ 属性で定義されます。そのコネクタの ​`primaryNodeOnly`​ のデフォルト値を調べるには、各コネクタのドキュメントを確認してください。 JMS の設定例: ```xml ``` この例は、逐次/一度に 1 つのメッセージの処理が必要な状況でアプリケーションが JMS からメッセージを受信するユースケースのものと考えられます。JMS Connector の On New Message ソースのデフォルト設定では、デフォルトで \[Primary Node Only (プライマリノードのみ)\] が選択されていますが、ほとんどのコネクタソースでは \[Primary Node Only (プライマリノードのみ)\] は選択されていません。デフォルト設定の決定はコネクタの開発者が行います。すべてのノードで処理を実行する必要があるユースケースでは、開発者はすべてのクラスターノードでソースが有効になるように primaryNodeOnly 値の選択を解除します。 ## [](#queues)Queues コードの実行とフロー参照によるフローのコールは、イベントの実行が開始されたのと同じノードで行われます。ただし、クラスタリングされた Mule Runtime で実行を共有または分散するために、VM キューをセットアップして VM キューに明示的にパブリッシュすることでノード間で負荷を分散できます。永続的な VM キューと一時的な VM キューのいずれでもクラスターの共有メモリグリッドが使用され、VM キューを介したあらゆる移行は別のアクティブなノードにジャンプする可能性があります。そのため、アプリケーションフロー全体に VM キューのパブリッシャー/リスナーによってリンクされた子フローのシーケンスが含まれる場合、クラスターは連続する各子フローをその時点で使用可能な任意の Mule Runtime Engine に割り当てることができます。下で示しているように、クラスターはアプリケーションフローの VM キューを通過するときに複数のノードで単一メッセージを処理することもできます。 ![さまざまなフロープロセスで負荷分散するように設計された 4 つのノードの Mule クラスター](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/load-balancing.png) ## [](#高信頼性アプリケーション)高信頼性アプリケーション 高信頼性アプリケーションと言えるには、以下の要件を満たす必要があります。 1. メッセージの損失の許容がゼロであること 2. インテグレーションエンジン (Mule) が信頼できること 3. 個別の接続の信頼性が高いこと トランザクション性として知られる機能はアプリケーションイベントシーケンスを追跡し、それぞれのメッセージ処理ステップが正常に完了するようにします。そのため、失われたり不正に処理されたりするメッセージはありません。何らかの理由でステップが失敗した場合、トランザクションメカニズムが以前の処理イベントをすべてロールバックし、メッセージ処理シーケンスを再開します。 JMS、VM、JDBC などのコネクタにより、ビルトイントランザクションサポートが提供されるため、メッセージが確実に処理されるようになります。たとえば、トランザクションがコミットされた後でのみメッセージを JMS サーバーから削除するようにインバウンド JMS 接続エンドポイントでトランザクションを設定できます。この方法により、処理フロー中にエラーが発生した場合、元のメッセージは再処理できる状態で保持されます。 トランザクションをサポートする異種コネクタ間でメッセージを移動するには、XA トランザクションを使用する必要があります。これにより、Mule Runtime Engine はすべての異種コネクタの関連付けられたトランザクションを単一ユニットとしてコミットするようになります。
トランザクションは、コネクタがトランザクションをサポートしないシステムでのインタラクションや操作を対象とすることはできません。そのため、関連する操作の中にトランザクションに含めることができないものがある場合には、 Sagas​ などの代替パターンを代わりに使用します。
## [](#コネクタのクラスターサポート)コネクタのクラスターサポート すべての Mule Connector がクラスター内でサポートされます。コネクタごとにインバウンドトラフィックにアクセスする方法が異なるため、このサポートの詳細は異なります。一般に、アウトバウンドトラフィックはクラスター内外で同じように機能します。Mule Runtime は 3 つの基本的な種別のコネクタをサポートしています。 ### [](#ソケットベースのコネクタ)ソケットベースのコネクタ ソケットベースのコネクタは Mule が所有するネットワークソケットに送信された入力を読み取ります。例としては TCP、UDP、HTTP\[S\] などがあります。 ソケットベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - クラスタリングされた各 Mule Runtime は異なるネットワークノードで実行されるため、各インスタンスはそのノードに送信されたソケットベースのトラフィックのみを受信します。受信したソケットベースのトラフィックは、クラスタリングされたインスタンス間で分散するために​[\[Clustering and Load Balancing\]](<#Clustering and Load Balancing>)​を実行する必要があります。 - ソケットベースのコネクタへの出力は特定のホスト/ポートの組み合わせに書き込まれます。ホスト/ポートの組み合わせが外部ホストの場合、特に考慮事項はありません。ローカルホストのポートの場合、クラスター間でより効率的にトラフィックを分散するために、代わりにロードバランサーでそのポートを使用することを検討してください。 ### [](#リスナーベースのコネクタ)リスナーベースのコネクタ リスナーベースのコネクタは同時の複数アクセサーを十分にサポートするプロトコルを使用してデータを読み取ります。例としては、JMS や VM があります。 リスナーベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - リスナーベースのコネクタは複数のリーダーおよびライターを完全にサポートしています。入力にも出力にも特に考慮事項はありません。 - クラスターでは、VM Connector キュー (永続的と一時的の両方) が共有のクラスター全体のリソースである点に注意してください。クラスターは VM Connector キューへのアクセスを自動的に同期します。そのため、任意のクラスターノードで VM キューに書き込まれたメッセージを処理できます。これにより、VM はクラスターノード間でワークを共有するのに最適です。 ### [](#リソースベースのコネクタ)リソースベースのコネクタ リソースベースのコネクタは複数の同時アクセサーは使用可能だがリソースの使用をネイティブに調整しないリソースからデータを読み取ります。リソースベースのコネクタの例としては、ファイル、FTP、SFTP、メール、JDBC などがあります。 リソースベースのコネクタは以下に示しているようにクラスター内でサポートされます。 - Mule HA クラスタリングは自動的にクラスター内のノードのみについて各リソースへのアクセスを調整するため、クラスタリングされたインスタンスのうち 1 つだけが一度に各リソースにアクセスするようになります。そのため、通常はリソースベースのコネクタから読み取られたメッセージをすぐに VM キューに書き込むことをお勧めします。これにより、他のクラスターノードがメッセージの処理に参加できます。

クラスター内のノードとして同じリソースにアクセスする他のアプリケーション (クラスター外の Mule アプリケーションまたは Mule 以外のアプリケーション) を実行する場合は、これらのリソースをロックするロジックを実装する必要があります。

たとえば、複数のプログラムがファイルの読み取り、変更、そして削除を行うことで、同じ共有ディレクトリのファイルを処理しているとします。これらのプログラムは明示的なアプリケーションレベルのロッキング戦略を使用して、同じファイルが複数回処理されないようにする必要があります。
- リソースベースのクラスタリングされたコネクタへの書き込みには特に考慮事項はありません。 - ファイルベースのコネクタ (ファイル、FTP、SFTP) に書き込むときに、Mule は一意のファイル名を生成します。 - JDBC に書き込むときに、Mule は一意のキーを生成できます。 - メールの作成は、実質的にはリソースベースではなくリスナーベースです。 ## [](#クラスタリングと信頼性の高いアプリケーション)クラスタリングと信頼性の高いアプリケーション 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。クラスターで十分に信頼できるアプリケーションをビルドするためのツールは​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.9/reliability-patterns)​で見つかります。 アプリケーションで非トランザクションコネクタを使用している場合、信頼性パターンに従ってください。これらのパターンにより、メッセージが受け入れられて正常に処理されるか、「失敗」応答を生成してクライアントが再試行できるようになります。 アプリケーションで JMS、VM、JDBC などのトランザクションコネクタを使用している場合は、トランザクションを使用します。トランザクションコネクタに対する Mule のビルトインサポートにより、こうしたコネクタを使用するアプリケーションで信頼性の高いメッセージングを実現できます。 これらのアクションは、クラスタリングされていないアプリケーションにも適用できます。 ## [](#クラスタリングとネットワーキング)クラスタリングとネットワーキング ### [](#単一のデータセンターのクラスタリング)単一のデータセンターのクラスタリング クラスターノード間で信頼性のある接続を確立するには、クラスターのすべてのノードを同じ LAN に配置する必要があります。VPN を通じて接続された異なるデータセンターなど、地理的に離れた場所にノードが含まれるクラスターを実装することも可能ですが、お勧めはしません。 ネットワークの中断や、メッセージの重複などの意図しない結果を招く可能性を下げるためには、すべてのクラスターノードを同じ LAN に配置するのが最もお勧めです。 ### [](#分散型データセンターのクラスタリング)分散型データセンターのクラスタリング WAN ネットワークを使用してクラスターノードをリンクすると、外部ルーターやファイアウォールなど、障害が発生する可能性のあるポイントが多くなり、クラスターノード間で適切に同期が行われないおそれがあります。これはパフォーマンスに影響を及ぼすだけでなく、アプリケーションにおける副作用の可能性を考慮に入れる必要も生じます。たとえば、2 つのクラスターノードがネットワークリンクの障害による切断後に再接続した場合、次回の同期プロセスでメッセージが 2 回処理される可能性があり、重複が発生して、アプリケーションロジックで処理する必要が生じます。また、オブジェクトストアを使用しているアプリケーションが、ノード間の通信機能の障害のために整合性のない状態になる可能性もあります。他に発生する可能性のある問題は、複数のノードが「プライマリ」になることです。これは、別々のノードが自身がクラスター内の唯一のノードであると認識することで発生します。 異なるデータセンターに配置されたクラスターのノードを使用でき、必ずしも同じ LAN に配置されている必要はありませんが、いくつか制限事項がある点に注意してください。 この「スプリットブレーン」処理動作を防ぐには、Quorum プロトコルを有効にする必要があります。このプロトコルは、ノードの 1 つのセットがデータの処理を続行し、他のセットが再接続されるまで共有データに関して何も実行しないようにするために使用されます。基本的に、切断が発生した場合、ノードが最も多い方のみが稼働し続けます。たとえば、2 つのデータセンターがあり、一方は 3 つのノードがあり、もう一方には 2 つのノードがあるとします。2 つのノードがあるデータセンターで接続の問題が発生した場合、ノードが 3 つのデータセンターが機能し続け、もう一方のデータセンターは停止します。ノードが 3 つのデータセンターがオフラインになった場合、どちらのノードも機能しなくなります。こうした機能停止を防ぐには、少なくとも 3 つの同じ数のノードを持つデータセンターでクラスターを作成する必要があります。2 つのデータセンターがクラッシュすることは考えにくいため、1 つのデータセンターがオフラインになったり、ネットワーク障害によって他のデータセンターから分離されたりしても、クラスターは常に機能し続けることになります。
機能するのに十分なノードがクラスターパーティションにない場合、外部システムコールに対しては引き続き反応しますが、オブジェクトストアを経由したすべての操作は失敗し、データ生成できなくなります。
#### [](#制限事項)制限事項 - Quorum はオブジェクトストア関連の操作でのみサポートされます。 - 分散ロッキングはサポートされず、以下に影響を及ぼします。 - ファイルの並列に関するファイル/FTP Connector ポーリング - 冪等性再配信ポリシーコンポーネント - 冪等性メッセージ検索条件コンポーネント - メモリ内メッセージングはサポートされず、以下に影響を及ぼします。 - VM Connector - Quorum 機能は手動でのみ設定できます。 - 一括処理ジョブでは高可用性機能が使用されません。 ## [](#クラスタリングと負荷分散)クラスタリングと負荷分散 TCP 要求 (この場合、TCP には SSL/TLS、UDP、Multicast、HTTP、HTTPS が含まれる) に対応するために Mule クラスターが使用される場合、クラスタリングされたインスタンス間で要求を分散するためにある程度の負荷分散が必要になります。Anypoint Runtime Fabric には基盤となる Docker Kubernetes (K8s) インフラストラクチャの一部としてロードバランサー機能が含まれていますが、お客様がホストし、手動でプロビジョニングされたクラスターでは、サードパーティのロードバランサーを提供するか、クライアント側で負荷分散とフェールオーバーを実行する必要があります。 さまざまなソフトウェアのロードバランサーが使用できますが、そのうちの 2 つを紹介します。 - オープンソースの HTTP サーバーおよびリバースプロキシである Nginx。HTTP(S) の負荷分散に NGINX の ​`HttpUpstreamModule`​ を使用できます。 - Apache Web サーバー。これは HTTP(S) ロードバランサーとしても使用できます。 TCP と HTTP または HTTPS トラフィックの両方をルーティングできるハードウェアのロードバランサーも多数あります。 ## [](#cluster-high-performance)高パフォーマンス用のクラスタリング このセクションは、お客様がホストし、手動でプロビジョニングされたクラスターデプロイメントにのみ適用されます。 その他のデプロイメントオプションについての詳細は、​[「デプロイメント戦略」](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)​を参照してください。 (信頼性ではなく) 高パフォーマンスが最大目標の場合は、パフォーマンスプロファイルを使用してパフォーマンスが最大になるように Mule クラスターまたは各アプリケーションを設定できます。クラスター内で特定のアプリケーションのパフォーマンスプロファイルを実装することで、デプロイメントの拡張性を最大にすると同時に、パフォーマンスおよび信頼性の要件が異なるアプリケーションを同じクラスターにデプロイすることができます。コンテナレベルで設定したパフォーマンスプロファイルは、そのコンテナ内のすべてのアプリケーションに適用されます。アプリケーションレベルの設定はコンテナレベルの設定より優先されます。 ### [](#パフォーマンスプロファイルの設定に関する考慮事項)パフォーマンスプロファイルの設定に関する考慮事項 パフォーマンスプロファイルの設定には 2 つの効果があります。 - 分散キューが無効になり、代わりにローカルキューを使用して共有データグリッドにおけるデータの逐次化/非逐次化および分散を防止します。 - バックアップなしでオブジェクトストアを実装し、複製を防止します。
1 つのノードがダウンしたら、そのノードに関連付けられているデータが失われます。
パフォーマンスプロファイルを設定しても、メモリ共有には影響しません。クラスターモードでは、オブジェクトストアはノード間で常に分散し、共有されます。 ### [](#パフォーマンスプロファイルの設定)パフォーマンスプロファイルの設定 _コンテナ_​レベルでパフォーマンスプロファイルを設定するには、次のコマンドを ​`mule-cluster.properties`​、システムプロパティ (コマンドラインから)、または ​`wrapper.conf`​ に追加します。 `mule.cluster.storeprofile=performance` _個別のアプリケーション_​レベルでパフォーマンスプロファイルを設定するには、以下で示しているように、設定ラッパー内にプロファイルを追加します。 - パフォーマンスストアプロファイル ```xml

負荷分散をサポートしないエンドポイントで負荷が大きい場合、パフォーマンスプロファイルを適用するとパフォーマンスが低下する場合もあります。非同期処理戦略、ロードバランサーがない JMS トピック、マルチキャスト、または HTTP Connector でファイルベースのコネクタを使用している場合、大量のメッセージが単一ノードに入るとボトルネックが発生する可能性があるため、こうしたアプリケーションのパフォーマンスプロファイルを無効にしたほうがパフォーマンスが向上する場合があります。

稼働状態を保つためにクラスターで必要なマシンの最小数を定義することもできます。この設定により、パフォーマンス全体での一貫性が改善されます。 ## [](#クラスターノード間の通信の暗号化)クラスターノード間の通信の暗号化 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルでまたはシステムプロパティとして定義することで、クラスターノード間のトラフィックを暗号化できます。 暗号化鍵を定義すると、定義した鍵と AES 暗号化アルゴリズムを使用してクラスターノード間のすべての通信が暗号化されます。 ## [](#cluster_fips)FIPS モードでのクラスタリングの有効化 FIPS モードでのクラスタリングを有効化するには、次のタスクを完了します。 - FIPS モードで Mule Runtime Engine を実行します。 設定の手順は、​[「FIPS コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.9/fips-140-2-compliance-support)​を参照してください。 - クラスターノード間の通信を暗号化します。 `mule.cluster.network.encryption.key`​ プロパティを ​`wrapper.conf`​ ファイルで定義するか、システムプロパティとして定義します。 ### [](#警告)警告 - 暗号化鍵を定義しない場合、アプリケーションはデプロイに失敗し、​`Cluster key must be defined in FIPS mode.`​ というメッセージが表示されます。 - クラスタリングされたすべてのノードで同じ暗号化鍵を使用しない場合、この機能は動作しません。 - FIPS モードでクラスタリングされた環境を実行すると、ノード間のすべての通信が暗号化 (および復号化) されるため、パフォーマンスが低下します。 ## [](#クラスタリングのベストプラクティス)クラスタリングのベストプラクティス クラスタリングに関しては多くの推奨事項があります。例を挙げます。 - できるだけアプリケーションを一連のステップに整理し、各ステップがメッセージを 1 つのトランザクションストアから別のトランザクションストアに移動するようにします。 - アプリケーションで非トランザクションコネクタからのメッセージを処理する場合、​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.9/reliability-patterns)​を使用して VM や JMS ストアなどのトランザクションストアに移動します。 - トランザクションを使用してトランザクションコネクタからのメッセージを処理します。これにより、エラーが発生した場合、メッセージが再処理されるようになります。 - VM や JMS Connector で使用するような分散ストアを使用します。こうしたストアはクラスター全体に対して使用可能です。これは、ファイル、FTP、JDBC などのコネクタで使用する非分散ストアよりも優れています。こうしたストアは一度に単一のノードによって読み取られます。 - VM Connector を使用して最適なパフォーマンスを得ます。クラスター全体が終了した後にデータを保存する必要があるアプリケーションに JMS Connector を使用します。 - 高信頼性アプリケーションを作成するには信頼性パターンを実装します。 - HA クラスターモードでは、すべてのオブジェクトストアコンテンツ (メモリ内コンテンツと、​`persistent`​ パラメーターで定義される永続的なコンテンツの両方) は、分散メモリグリッドに保存されます。クラスターでクォーラムが保持されている限り、このデータはアプリケーションの再デプロイまたは再起動後も存続します。オブジェクトストアコンテンツを完全にクリアするには、再起動する前にすべてのクラスターノードを停止する必要があります。クラスターの完全シャットダウン後もデータの永続性が必要なシナリオでは、メモリグリッドの代わりに JDBC ベースのストアを使用するようにオブジェクトストアを設定します。​[「オブジェクトストアの永続性」](https://docs.mulesoft.com/jp/mule-runtime/4.9/creating-and-managing-a-cluster-manually#object-store-persistence)​を参照してください。 ## [](#関連情報)関連情報 - [Enterprise ライセンスのインストール](https://docs.mulesoft.com/jp/mule-runtime/4.9/installing-an-enterprise-license) - [サーバーの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-servers#create-a-cluster) - [CloudHub 高可用性および障害回復](https://docs.mulesoft.com/cloudhub/cloudhub-hadr) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/creating-and-managing-a-cluster-manually) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management) - [クォーラム管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/creating-and-managing-a-cluster-manually#quorum-management) # Mule アップグレードツール The Mule upgrade tool is a command line utility for updating and upgrading standalone on-premise instances of Mule 4. Download the tool and integrate it with your existing automated processes and workflows by using scripts and cron jobs. 現在の Mule インスタンスに Runtime Manager エージェントがインストールされている場合、アップグレードツールは、アップグレードプロセスの一環としてエージェントのバージョンも更新します。 Anypoint Monitoring エージェントのアップグレードはサポートされていません。アップグレードを続行するには、まずエージェントをアンインストールし、Mule インスタンスのアップグレードが完了してから再インストールする必要があります。​[「Anypoint Monitoring エージェントの更新」](https://docs.mulesoft.com/jp/monitoring/am-installing#update-the-anypoint-monitoring-agent)​を参照してください。 アップグレードツールでは、アップグレードするランタイムで実行されている Mule アプリケーションは変更されません。 Mule アップグレードツールは、ツールを使用して各ノードを手動でアップグレードすることにより、クラスタリングされた Mule インスタンスのアップグレードをサポートしています。アップグレードを続行する方法についての追加情報は、​[クラスタリングされた Mule アプリケーションのアップグレード](#upgrade_clustered_mule_instances)​を参照してください。このツールの使用を強くお勧めしますが、現在の Mule インスタンスをアップグレードするのに厳格に必要なわけではありません。完全に手動でのアップグレードについては、​[「Upgrading an On-Premises Mule Instance Managed Through Runtime Manager (Runtime Manager で管理されているオンプレミス Mule インスタンスのアップグレード)」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions#mulerunvers)​を参照してください。 ## [](#始める前に)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ## [](#mule-のアップグレードまたは更新)Mule のアップグレードまたは更新 クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。
対象の場所が ​$MULE_HOME​ であるため、アップグレードした Mule Runtime インスタンスによって以前のバージョンが置き換えられます。
## [](#アップグレードまたは更新のロールバック)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` ## [](#ファイルの競合の解決)ファイルの競合の解決 Mule アップグレードツールは、​_現在の_​ Mule ディストリビューションと​_新しい_​ディストリビューションの設定ファイルを比較し、変更された内容を検出して失われないようにします。Mule アップグレードツールが​_新しい_​ Mule ディストリビューションの設定ファイルで変更を検出すると、自動的に競合を解決し、アップグレードを続行しようとします。競合を自動的に解決できない場合、ツールでは次のアクションを実行します。 - `upgrade`​ サブコマンドの実行を失敗させて、エラーメッセージを表示します。 - 競合が検出された Mule 設定ファイルの名前をログ出力に記録します。 - 競合が検出された設定ファイルを、現在の Mule ディストリビューションの ​`${MULE_HOME}/conf`​ ディレクトリから ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ にコピーします。 - 設定ファイルの元のコンテンツを、​_新しい_​ Mule ディストリビューションから ​`${MULE_HOME}/upgrade-tool/mule-configs-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}`​ フォルダーにコピーします。 設定ファイルの競合によってアップグレードプロセスが失敗した場合は、以下の手順に従って競合を解決してから、アップグレードプロセスを続行してください。 ### [](#steps-to-solve-conflicts)Mule 設定ファイルの競合を解決する手順 アップグレード中に競合を解決する手順は、次のとおりです。 1. アップグレード中の現在の Mule ディストリビューションの ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/`​ フォルダーで、競合が検出されたファイルのいずれかを選択します。 2. ファイル比較ツール (​`diff`​ など) を使用して、次のパスのファイルのコンテンツを比較します。 - `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf` - `${MULE_HOME}/upgrade-tool/mule-configs-files/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf` 3. 相違点を確認したら、変更内容をマージするか、または破棄してください。 - 変更内容をマージする場合は、新しい設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf`​ ファイルから目的の変更内容を追加して前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を変更します。次に、マージしたファイルを ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーにコピーします。 - 変更内容を破棄して前の設定を保持する場合は、前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーに移動します。 変更内容を破棄すると、古い設定が新しい Mule ディストリビューションで使用される場合があります。 4. `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ フォルダー内の各設定ファイルに対してステップ 1 ～ 3 を繰り返します。 5. `upgrade`​ サブコマンドの実行を再試行します。 アップグレードが正常に完了すると、ツールは ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts`​ フォルダーを削除し、将来のアップグレードに備えてクリーンな環境に戻します。 ### [](#無人のアップグレードまたは更新)無人のアップグレードまたは更新 対象環境でアップグレードを実行する前に、別の環境で競合を解決しておけば、アップグレードや更新を無人で実行できます。この手順は、別の環境で設定する​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションが、メイン環境の​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションのバージョンと一致する場合にのみ使用できます。 1. ユーザーインタラクションが可能な環境で、​[Mule 設定ファイルの競合を解決する手順](#steps-to-solve-conflicts)​の説明に従ってすべての競合を確認して解決します。 2. 対象環境で、​`${MULE_HOME_WITH_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ から ​`${MULE_HOME_WITHOUT_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ にファイルをコピーします。 3. 対象環境で ​`upgrade`​ サブコマンドを実行します。 ## [](#mule-アップグレードツールのログの設定)Mule アップグレードツールのログの設定 デバッグのログを有効化することで、Mule アップグレードツールの各操作の詳細情報を追加したり、ツールがログを保存するフォルダーを変更したり、カスタマイズされたログ設定ファイルを使用したりできます。 ### [](#カスタム-log4j-ファイルの指定)カスタム Log4j ファイルの指定 デフォルトでは、Mule アップグレードツールは ​`$MULE_HOME/tools/upgrade-tool`​ フォルダーにある ​`log4j2-upgrade-tool.xml`​ ファイルを使用します。 カスタム Log4j ファイルを使用するには、​`-l`​ パラメーターを使用して、使用するカスタム Log4j 設定ファイルのファイル名を指定します。例: ```bash $MULE_HOME/tools/upgrade-tool -l myLog4j2File.xml upgrade ``` ### [](#デバッグレベルログの有効化)デバッグレベルログの有効化 デバッグログを有効化する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. Log4j ファイルの次の行で、​`level`​ プロパティの値を ​`INFO`​ から ​`DEBUG`​ に変更します。 ```xml ``` ### [](#ログ出力のカスタマイズ)ログ出力のカスタマイズ デフォルトでは、Mule アップグレードツールは ​`./mule-Runtime-upgrade-tool-logs`​ ディレクトリにログファイルを保存します。 ファイル名、出力パス、ログパターンを変更する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. `fileName`​ プロパティと ​`filePattern`​ プロパティに希望する値を指定します。 ```xml ``` ## [](#mule-アップグレードツールのサブコマンドとオプション)Mule アップグレードツールのサブコマンドとオプション Mule アップグレードツールの実行時に使用できるサブコマンドとオプションを下表に示します。
サブコマンド 説明

upgrade

ローカル Mule インスタンスを、使用できる最新バージョンにアップグレードします。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-n <newMuleDistributionPath>​

ローカル Mule インスタンスを、ファイルシステムにダウンロードして展開してあるディストリビューションにアップグレードします。​<newMuleDistribution>​ パラメーターを使用して、新しい Mule ディストリビューションのパスを指定できます。例:
​$ ./upgrade-tool upgrade -n /<newMuleDistributionPath>​

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスをアップグレードします。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスをアップグレードできます。例:
​$ ./upgrade-tool upgrade -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、アップグレードプロセスをシミュレーションします。

-f​

バックアップの上書きや適用したパッチの削除といった破壊的な操作に対してユーザーの確認を要求せずにアップグレードを実行します。

-h​

このサブコマンドのヘルプメッセージを表示します。

rollback

Mule インスタンスを以前の状態に戻します。このサブコマンドは、ツールでアップグレードを正常に完了した後でのみ使用できます。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスを復元します。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスを復元できます。例:
​$ ./upgrade-tool rollback -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、ロールバックプロセスをシミュレーションします。

-f​

ユーザーの確認を要求せずに Mule インスタンスを復元します。

-h​

このサブコマンドのヘルプメッセージを表示します。

status

現在の Mule インスタンスに関して、次のような情報を提供します。

  • Mule Runtime Engine バージョン

  • 現在の Mule インスタンスがアップグレードまたはロールバックの条件を満たしていることを確認するメッセージ

  • 既存のバックアップとその場所

  • バックアップが存在する場合はその整合性
## [](#一般的なエラーのトラブルシューティング)一般的なエラーのトラブルシューティング 以下に、アップグレードツールから返される最も一般的なエラーメッセージの一部と、それぞれの説明および解決策を示します。 ### [](#missing-required-subcommand-必要なサブコマンドがありません)Missing Required Subcommand (必要なサブコマンドがありません) ./upgrade-tool Mule Runtime Upgrade Tool ───────────────────────── Missing required subcommand Usage: upgrade-tool \[-hV\] \[COMMAND\] Try 'upgrade-tool --help' for more information. #### [](#原因)原因 このエラーは、未知の、または存在しないサブコマンドが指定されたことを示します。サポートされているサブコマンドは、​`upgrade`​、​`rollback`​、​`status`​ のみです。 #### [](#解決策)解決策 `upgrade-tool`​ コマンドと、サポートされているいずれかのサブコマンド (​`upgrade`​、​`rollback`​、または ​`status`​) を実行していることを確認します。 `-h`​ または ​`--help`​ オプションを使用すると、特定のサブコマンドの詳細情報を見ることができます。例: $ ./upgrade-tool rollback --help ### [](#missing-required-option-必須のオプションがありません)Missing Required Option (必須のオプションがありません) ./upgrade-tool upgrade Mule Runtime Upgrade Tool ───────────────────────── Missing required option: '--new-mule-distro=' Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Try 'upgrade-tool upgrade --help' for more information. #### [](#原因-2)原因 このエラーは、選択したサブコマンドに追加の引数が必要であることを示しています。たとえば、アップグレード時には引数 ​`--new-mule-distro`​ が必要です。 #### [](#解決策-2)解決策 次のコマンドを実行して、特定のサブコマンドで必要な引数に関する情報を確認します。 ./upgrade-tool upgrade --help このコマンドを実行すると、追加情報が次のように表示されます。 Mule Runtime Upgrade Tool ───────────────────────── Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Upgrades a Mule Runtime to a newer version -d, --dry-run Simulate upgrade process without performing any permanent changes to the current Mule Runtime Distribution. -f, --force Perform all the destructive operations like overwriting the backup or removing the applied patches without user confirmation -h, --help Display this help message -n, --new-mule-distro= File path of the newer Mule Runtime distribution used for the upgrade -o, --old-mule-distro= File path of Mule Runtime distribution to upgrade `Usage:`​ 行では、省略可能なオプションと引数が角括弧 (​`[`,`]`​) 内に示されます。角括弧が付いていないオプションと引数は必須です。 ### [](#no-space-left-on-device-デバイスにスペースがありません)No Space Left on Device (デバイスにスペースがありません) $ ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 ERROR: There's not enough disk space for performing the upgrade. ERROR: No space left on device No space left on device #### [](#原因-3)原因 このエラーは、アップグレードを実行するのに必要な空きディスクスペースがないことを示します。 #### [](#解決策-3)解決策 アップグレードツールは、Mule インスタンスが動作しているファイルシステムに 2 GB 以上の空きスペースを必要とします。システムに十分なディスクスペースがあり、他の要件も満足されていることを確認してください。 Linux 環境では、​`df`​ コマンドで空きディスクスペースを確認できます。 $ df -h /opt Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-opt 419G 205G 193G 52% /opt ### [](#version-should-be-newer-新しいバージョンが必要です)Version Should Be Newer (新しいバージョンが必要です) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 #### [](#原因-4)原因 このエラーは、upgrade コマンドで、現在の Mule インスタンスと同じバージョンの新しい Mule ディストリビューションが指定された場合に発生します。 #### [](#解決策-4)解決策 ダウンロードした Mule ディストリビューションが現在の Mule インスタンスよりも新しいバージョンであることを確認してください。アップグレード中にこのエラーメッセージが連続して返される場合は、現在の Mule インスタンスがすでにアップグレード済みであるか、または最新のバージョンが実行中であることを意味します。 ### [](#missing-reading-permissions-参照権限がありません)Missing Reading Permissions (参照権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required reading permissions under Mule distribution \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] java.nio.file.AccessDeniedException: /tmp/mule-enterprise-standalone-4.4.0-20211104/lib/mule/mule-module-cache-ee-4.4.0-20211104.jar \[...\] #### [](#原因-5)原因 新しい Mule ディストリビューションで必要な参照権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルを参照できません。 #### [](#解決策-5)解決策 アップグレードツールによって参照不能として特定されているファイルの参照権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#missing-writing-permissions-書き込み権限がありません)Missing Writing Permissions (書き込み権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required writing permissions under Mule distribution \[/opt/mule-enterprise-standalone-4.4.0-20211026\] java.nio.file.AccessDeniedException: /opt/mule-enterprise-standalone-4.4.0-20211026/lib/boot/libwrapper-linux-ppcle-64.so \[...\] #### [](#原因-6)原因 古い Mule ディストリビューションで必要な書き込み権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルに書き込めません。 #### [](#解決策-6)解決策 アップグレードツールによって特定されたファイルへの書き込み権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#mule-runtime-should-be-stopped-mule-runtime-を停止する必要があります)Mule Runtime Should Be Stopped (Mule Runtime を停止する必要があります) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Mule Runtime should be stopped. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-7)原因 Mule が実行中であることをアップグレードツールが検出しました。 #### [](#解決策-7)解決策 アップグレードプロセスを開始する前に Mule を停止してください。現在の状況を確認するには ​`${MULE_HOME}/bin/mule status`​ コマンドを使用します。 ### [](#mule-version-isnt-supported-for-an-upgrade-アップグレードでサポートされていない-mule-バージョンです)Mule Version Isn’t Supported for an Upgrade (アップグレードでサポートされていない Mule バージョンです) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/tmp/mule-enterprise-standalone-4.1.1-20211222\] with version: \[4.1.1\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211026\] with version \[4.4.0-20211026\] ... ERROR: Your Mule version cannot be upgraded to the new one, you need to upgrade to a version greater than 4.1.5, or for versions between 4.1.1 to 4.1.4, then packages released after January 20, 2022. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-8)原因 Mule アップグレードツールでは、現在の Mule インスタンスと新しい Mule インスタンス (​`/new-${MULE_HOME_NEW_FOLDER_NAME}`​) の両方がバージョン 4.1.5 以降である必要があります。 #### [](#解決策-8)解決策 Mule アップグレードツールを使用してアップグレードを実行する前に、現在の Mule インスタンスと新しい Mule インスタンスの両方をバージョン 4.1.5 以降に手動でアップグレードしてください。 ## [](#upgrade_clustered_mule_instances)クラスタリングされた Mule アプリケーションのアップグレード クラスタリングされた Mule インスタンスをアップグレードするには、Mule アップグレードツールを使用して各ノードを手動でアップグレードすることにより、ローカル Mule インスタンスのアップグレードプロセスを自動化します。 ### [](#始める前に-2)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 新しい Mule Runtime ディストリビューション (対象バージョン) と、アップグレードする各ノードにコピーされた Mule アップグレードツール (ダウンタイムを短縮するため)。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ### [](#mule-のアップグレードまたは更新-2)Mule のアップグレードまたは更新 クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。
対象の場所が ​$MULE_HOME​ であるため、アップグレードした Mule Runtime インスタンスによって以前のバージョンが置き換えられます。
すべてのノードを同じ Mule Runtime バージョンにアップグレードまたは更新しないと正常に動作しませんのでご注意ください。 ### [](#アップグレードまたは更新のロールバック-2)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` すべてのノードを同じ Mule Runtime バージョンにロールバックしないと正常に動作しませんのでご注意ください。 ## [](#関連情報)関連情報 - [Mule Upgrades and Patch Updates (Mule のアップグレードとパッチの更新)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) # Mule アップグレードツール The Mule upgrade tool is a command line utility for updating and upgrading standalone on-premise instances of Mule 4. Download the tool and integrate it with your existing automated processes and workflows by using scripts and cron jobs. 現在の Mule インスタンスに Runtime Manager エージェントがインストールされている場合、アップグレードツールは、アップグレードプロセスの一環としてエージェントのバージョンも更新します。 Anypoint Monitoring エージェントのアップグレードはサポートされていません。アップグレードを続行するには、まずエージェントをアンインストールし、Mule インスタンスのアップグレードが完了してから再インストールする必要があります。​[「Anypoint Monitoring エージェントの更新」](https://docs.mulesoft.com/jp/monitoring/am-installing#update-the-anypoint-monitoring-agent)​を参照してください。 アップグレードツールでは、アップグレードするランタイムで実行されている Mule アプリケーションは変更されません。 Mule アップグレードツールは、ツールを使用して各ノードを手動でアップグレードすることにより、クラスタリングされた Mule インスタンスのアップグレードをサポートしています。アップグレードを続行する方法についての追加情報は、​[クラスタリングされた Mule アプリケーションのアップグレード](#upgrade_clustered_mule_instances)​を参照してください。このツールの使用を強くお勧めしますが、現在の Mule インスタンスをアップグレードするのに厳格に必要なわけではありません。完全に手動でのアップグレードについては、​[「Upgrading an On-Premises Mule Instance Managed Through Runtime Manager (Runtime Manager で管理されているオンプレミス Mule インスタンスのアップグレード)」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions#mulerunvers)​を参照してください。 ## [](#始める前に)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ## [](#mule-のアップグレードまたは更新)Mule のアップグレードまたは更新 クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 ➜ tools ./upgrade-tool upgrade -n /Users/me/mule-download/upgrade/mule-enterprise-standalone-4.5.0/ Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。
対象の場所が ​$MULE_HOME​ であるため、アップグレードした Mule Runtime インスタンスによって以前のバージョンが置き換えられます。
## [](#アップグレードまたは更新のロールバック)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` ## [](#ファイルの競合の解決)ファイルの競合の解決 Mule アップグレードツールは、​_現在の_​ Mule ディストリビューションと​_新しい_​ディストリビューションの設定ファイルを比較し、変更された内容を検出して失われないようにします。Mule アップグレードツールが​_新しい_​ Mule ディストリビューションの設定ファイルで変更を検出すると、自動的に競合を解決し、アップグレードを続行しようとします。競合を自動的に解決できない場合、ツールでは次のアクションを実行します。 - `upgrade`​ サブコマンドの実行を失敗させて、エラーメッセージを表示します。 - 競合が検出された Mule 設定ファイルの名前をログ出力に記録します。 - 競合が検出された設定ファイルを、現在の Mule ディストリビューションの ​`${MULE_HOME}/conf`​ ディレクトリから ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ にコピーします。 - 設定ファイルの元のコンテンツを、​_新しい_​ Mule ディストリビューションから ​`${MULE_HOME}/upgrade-tool/mule-configs-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}`​ フォルダーにコピーします。 設定ファイルの競合によってアップグレードプロセスが失敗した場合は、以下の手順に従って競合を解決してから、アップグレードプロセスを続行してください。 ### [](#steps-to-solve-conflicts)Mule 設定ファイルの競合を解決する手順 アップグレード中に競合を解決する手順は、次のとおりです。 1. アップグレード中の現在の Mule ディストリビューションの ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/`​ フォルダーで、競合が検出されたファイルのいずれかを選択します。 2. ファイル比較ツール (​`diff`​ など) を使用して、次のパスのファイルのコンテンツを比較します。 - `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf` - `${MULE_HOME}/upgrade-tool/mule-configs-files/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf` 3. 相違点を確認したら、変更内容をマージするか、または破棄してください。 - 変更内容をマージする場合は、新しい設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf`​ ファイルから目的の変更内容を追加して前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を変更します。次に、マージしたファイルを ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーにコピーします。 - 変更内容を破棄して前の設定を保持する場合は、前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーに移動します。 変更内容を破棄すると、古い設定が新しい Mule ディストリビューションで使用される場合があります。 4. `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ フォルダー内の各設定ファイルに対してステップ 1 ～ 3 を繰り返します。 5. `upgrade`​ サブコマンドの実行を再試行します。 アップグレードが正常に完了すると、ツールは ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts`​ フォルダーを削除し、将来のアップグレードに備えてクリーンな環境に戻します。 ### [](#無人のアップグレードまたは更新)無人のアップグレードまたは更新 対象環境でアップグレードを実行する前に、別の環境で競合を解決しておけば、アップグレードや更新を無人で実行できます。この手順は、別の環境で設定する​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションが、メイン環境の​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションのバージョンと一致する場合にのみ使用できます。 1. ユーザーインタラクションが可能な環境で、​[Mule 設定ファイルの競合を解決する手順](#steps-to-solve-conflicts)​の説明に従ってすべての競合を確認して解決します。 2. 対象環境で、​`${MULE_HOME_WITH_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ から ​`${MULE_HOME_WITHOUT_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ にファイルをコピーします。 3. 対象環境で ​`upgrade`​ サブコマンドを実行します。 ## [](#mule-アップグレードツールのログの設定)Mule アップグレードツールのログの設定 デバッグのログを有効化することで、Mule アップグレードツールの各操作の詳細情報を追加したり、ツールがログを保存するフォルダーを変更したり、カスタマイズされたログ設定ファイルを使用したりできます。 ### [](#カスタム-log4j-ファイルの指定)カスタム Log4j ファイルの指定 デフォルトでは、Mule アップグレードツールは ​`$MULE_HOME/tools/upgrade-tool`​ フォルダーにある ​`log4j2-upgrade-tool.xml`​ ファイルを使用します。 カスタム Log4j ファイルを使用するには、​`-l`​ パラメーターを使用して、使用するカスタム Log4j 設定ファイルのファイル名を指定します。例: ```bash $MULE_HOME/tools/upgrade-tool -l myLog4j2File.xml upgrade ``` ### [](#デバッグレベルログの有効化)デバッグレベルログの有効化 デバッグログを有効化する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. Log4j ファイルの次の行で、​`level`​ プロパティの値を ​`INFO`​ から ​`DEBUG`​ に変更します。 ```xml ``` ### [](#ログ出力のカスタマイズ)ログ出力のカスタマイズ デフォルトでは、Mule アップグレードツールは ​`./mule-Runtime-upgrade-tool-logs`​ ディレクトリにログファイルを保存します。 ファイル名、出力パス、ログパターンを変更する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. `fileName`​ プロパティと ​`filePattern`​ プロパティに希望する値を指定します。 ```xml ``` ## [](#mule-アップグレードツールのサブコマンドとオプション)Mule アップグレードツールのサブコマンドとオプション Mule アップグレードツールの実行時に使用できるサブコマンドとオプションを下表に示します。
サブコマンド 説明

upgrade

ローカル Mule インスタンスを、使用できる最新バージョンにアップグレードします。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-n <newMuleDistributionPath>​

ローカル Mule インスタンスを、ファイルシステムにダウンロードして展開してあるディストリビューションにアップグレードします。​<newMuleDistribution>​ パラメーターを使用して、新しい Mule ディストリビューションのパスを指定できます。例:
​$ ./upgrade-tool upgrade -n /<newMuleDistributionPath>​

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスをアップグレードします。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスをアップグレードできます。例:
​$ ./upgrade-tool upgrade -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、アップグレードプロセスをシミュレーションします。

-f​

バックアップの上書きや適用したパッチの削除といった破壊的な操作に対してユーザーの確認を要求せずにアップグレードを実行します。

-h​

このサブコマンドのヘルプメッセージを表示します。

rollback

Mule インスタンスを以前の状態に戻します。このサブコマンドは、ツールでアップグレードを正常に完了した後でのみ使用できます。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスを復元します。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスを復元できます。例:
​$ ./upgrade-tool rollback -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、ロールバックプロセスをシミュレーションします。

-f​

ユーザーの確認を要求せずに Mule インスタンスを復元します。

-h​

このサブコマンドのヘルプメッセージを表示します。

status

現在の Mule インスタンスに関して、次のような情報を提供します。

  • Mule Runtime Engine バージョン

  • 現在の Mule インスタンスがアップグレードまたはロールバックの条件を満たしていることを確認するメッセージ

  • 既存のバックアップとその場所

  • バックアップが存在する場合はその整合性
## [](#一般的なエラーのトラブルシューティング)一般的なエラーのトラブルシューティング 以下に、アップグレードツールから返される最も一般的なエラーメッセージの一部と、それぞれの説明および解決策を示します。 ### [](#missing-required-subcommand-必要なサブコマンドがありません)Missing Required Subcommand (必要なサブコマンドがありません) ./upgrade-tool Mule Runtime Upgrade Tool ───────────────────────── Missing required subcommand Usage: upgrade-tool \[-hV\] \[COMMAND\] Try 'upgrade-tool --help' for more information. #### [](#原因)原因 このエラーは、未知の、または存在しないサブコマンドが指定されたことを示します。サポートされているサブコマンドは、​`upgrade`​、​`rollback`​、​`status`​ のみです。 #### [](#解決策)解決策 `upgrade-tool`​ コマンドと、サポートされているいずれかのサブコマンド (​`upgrade`​、​`rollback`​、または ​`status`​) を実行していることを確認します。 `-h`​ または ​`--help`​ オプションを使用すると、特定のサブコマンドの詳細情報を見ることができます。例: $ ./upgrade-tool rollback --help ### [](#missing-required-option-必須のオプションがありません)Missing Required Option (必須のオプションがありません) ./upgrade-tool upgrade Mule Runtime Upgrade Tool ───────────────────────── Missing required option: '--new-mule-distro=' Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Try 'upgrade-tool upgrade --help' for more information. #### [](#原因-2)原因 このエラーは、選択したサブコマンドに追加の引数が必要であることを示しています。たとえば、アップグレード時には引数 ​`--new-mule-distro`​ が必要です。 #### [](#解決策-2)解決策 次のコマンドを実行して、特定のサブコマンドで必要な引数に関する情報を確認します。 ./upgrade-tool upgrade --help このコマンドを実行すると、追加情報が次のように表示されます。 Mule Runtime Upgrade Tool ───────────────────────── Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Upgrades a Mule Runtime to a newer version -d, --dry-run Simulate upgrade process without performing any permanent changes to the current Mule Runtime Distribution. -f, --force Perform all the destructive operations like overwriting the backup or removing the applied patches without user confirmation -h, --help Display this help message -n, --new-mule-distro= File path of the newer Mule Runtime distribution used for the upgrade -o, --old-mule-distro= File path of Mule Runtime distribution to upgrade `Usage:`​ 行では、省略可能なオプションと引数が角括弧 (​`[`,`]`​) 内に示されます。角括弧が付いていないオプションと引数は必須です。 ### [](#no-space-left-on-device-デバイスにスペースがありません)No Space Left on Device (デバイスにスペースがありません) $ ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 ERROR: There's not enough disk space for performing the upgrade. ERROR: No space left on device No space left on device #### [](#原因-3)原因 このエラーは、アップグレードを実行するのに必要な空きディスクスペースがないことを示します。 #### [](#解決策-3)解決策 アップグレードツールは、Mule インスタンスが動作しているファイルシステムに 2 GB 以上の空きスペースを必要とします。システムに十分なディスクスペースがあり、他の要件も満足されていることを確認してください。 Linux 環境では、​`df`​ コマンドで空きディスクスペースを確認できます。 $ df -h /opt Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-opt 419G 205G 193G 52% /opt ### [](#version-should-be-newer-新しいバージョンが必要です)Version Should Be Newer (新しいバージョンが必要です) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 #### [](#原因-4)原因 このエラーは、upgrade コマンドで、現在の Mule インスタンスと同じバージョンの新しい Mule ディストリビューションが指定された場合に発生します。 #### [](#解決策-4)解決策 ダウンロードした Mule ディストリビューションが現在の Mule インスタンスよりも新しいバージョンであることを確認してください。アップグレード中にこのエラーメッセージが連続して返される場合は、現在の Mule インスタンスがすでにアップグレード済みであるか、または最新のバージョンが実行中であることを意味します。 ### [](#missing-reading-permissions-参照権限がありません)Missing Reading Permissions (参照権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required reading permissions under Mule distribution \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] java.nio.file.AccessDeniedException: /tmp/mule-enterprise-standalone-4.4.0-20211104/lib/mule/mule-module-cache-ee-4.4.0-20211104.jar \[...\] #### [](#原因-5)原因 新しい Mule ディストリビューションで必要な参照権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルを参照できません。 #### [](#解決策-5)解決策 アップグレードツールによって参照不能として特定されているファイルの参照権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#missing-writing-permissions-書き込み権限がありません)Missing Writing Permissions (書き込み権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required writing permissions under Mule distribution \[/opt/mule-enterprise-standalone-4.4.0-20211026\] java.nio.file.AccessDeniedException: /opt/mule-enterprise-standalone-4.4.0-20211026/lib/boot/libwrapper-linux-ppcle-64.so \[...\] #### [](#原因-6)原因 古い Mule ディストリビューションで必要な書き込み権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルに書き込めません。 #### [](#解決策-6)解決策 アップグレードツールによって特定されたファイルへの書き込み権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#mule-runtime-should-be-stopped-mule-runtime-を停止する必要があります)Mule Runtime Should Be Stopped (Mule Runtime を停止する必要があります) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Mule Runtime should be stopped. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-7)原因 Mule が実行中であることをアップグレードツールが検出しました。 #### [](#解決策-7)解決策 アップグレードプロセスを開始する前に Mule を停止してください。現在の状況を確認するには ​`${MULE_HOME}/bin/mule status`​ コマンドを使用します。 ### [](#mule-version-isnt-supported-for-an-upgrade-アップグレードでサポートされていない-mule-バージョンです)Mule Version Isn’t Supported for an Upgrade (アップグレードでサポートされていない Mule バージョンです) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/tmp/mule-enterprise-standalone-4.1.1-20211222\] with version: \[4.1.1\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211026\] with version \[4.4.0-20211026\] ... ERROR: Your Mule version cannot be upgraded to the new one, you need to upgrade to a version greater than 4.1.5, or for versions between 4.1.1 to 4.1.4, then packages released after January 20, 2022. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-8)原因 Mule アップグレードツールでは、現在の Mule インスタンスと新しい Mule インスタンス (​`/new-${MULE_HOME_NEW_FOLDER_NAME}`​) の両方がバージョン 4.1.5 以降である必要があります。 #### [](#解決策-8)解決策 Mule アップグレードツールを使用してアップグレードを実行する前に、現在の Mule インスタンスと新しい Mule インスタンスの両方をバージョン 4.1.5 以降に手動でアップグレードしてください。 ## [](#upgrade_clustered_mule_instances)クラスタリングされた Mule アプリケーションのアップグレード クラスタリングされた Mule インスタンスをアップグレードするには、Mule アップグレードツールを使用して各ノードを手動でアップグレードすることにより、ローカル Mule インスタンスのアップグレードプロセスを自動化します。 ### [](#始める前に-2)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 新しい Mule Runtime ディストリビューション (対象バージョン) と、アップグレードする各ノードにコピーされた Mule アップグレードツール (ダウンタイムを短縮するため)。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ### [](#mule-のアップグレードまたは更新-2)Mule のアップグレードまたは更新 クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 ➜ tools ./upgrade-tool upgrade -n /Users/me/mule-download/upgrade/mule-enterprise-standalone-4.5.0/ Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。
対象の場所が ​$MULE_HOME​ であるため、アップグレードした Mule Runtime インスタンスによって以前のバージョンが置き換えられます。
すべてのノードを同じ Mule Runtime バージョンにアップグレードまたは更新しないと正常に動作しませんのでご注意ください。 ### [](#アップグレードまたは更新のロールバック-2)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` すべてのノードを同じ Mule Runtime バージョンにロールバックしないと正常に動作しませんのでご注意ください。 ## [](#関連情報)関連情報 - [Mule Upgrades and Patch Updates (Mule のアップグレードとパッチの更新)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) # Mule アップグレードツール The Mule upgrade tool is a command line utility for updating and upgrading standalone on-premise instances of Mule 4. Download the tool and integrate it with your existing automated processes and workflows by using scripts and cron jobs. 現在の Mule インスタンスに Runtime Manager エージェントがインストールされている場合、アップグレードツールは、アップグレードプロセスの一環としてエージェントのバージョンも更新します。 Anypoint Monitoring エージェントのアップグレードはサポートされていません。アップグレードを続行するには、まずエージェントをアンインストールし、Mule インスタンスのアップグレードが完了してから再インストールする必要があります。​[「Anypoint Monitoring エージェントの更新」](https://docs.mulesoft.com/jp/monitoring/am-installing#update-the-anypoint-monitoring-agent)​を参照してください。 アップグレードツールでは、アップグレードするランタイムで実行されている Mule アプリケーションは変更されません。 Mule アップグレードツールは、ツールを使用して各ノードを手動でアップグレードすることにより、クラスタリングされた Mule インスタンスのアップグレードをサポートしています。アップグレードを続行する方法についての追加情報は、​[クラスタリングされた Mule アプリケーションのアップグレード](#upgrade_clustered_mule_instances)​を参照してください。このツールの使用を強くお勧めしますが、現在の Mule インスタンスをアップグレードするのに厳格に必要なわけではありません。完全に手動でのアップグレードについては、​[「Upgrading an On-Premises Mule Instance Managed Through Runtime Manager (Runtime Manager で管理されているオンプレミス Mule インスタンスのアップグレード)」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions#mulerunvers)​を参照してください。 ## [](#始める前に)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ## [](#mule-のアップグレードまたは更新)Mule のアップグレードまたは更新 クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 ➜ tools ./upgrade-tool upgrade -n /Users/me/mule-download/upgrade/mule-enterprise-standalone-4.5.0/ Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。
対象の場所が ​$MULE_HOME​ であるため、アップグレードした Mule Runtime インスタンスによって以前のバージョンが置き換えられます。
## [](#アップグレードまたは更新のロールバック)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` ## [](#ファイルの競合の解決)ファイルの競合の解決 Mule アップグレードツールは、​_現在の_​ Mule ディストリビューションと​_新しい_​ディストリビューションの設定ファイルを比較し、変更された内容を検出して失われないようにします。Mule アップグレードツールが​_新しい_​ Mule ディストリビューションの設定ファイルで変更を検出すると、自動的に競合を解決し、アップグレードを続行しようとします。競合を自動的に解決できない場合、ツールでは次のアクションを実行します。 - `upgrade`​ サブコマンドの実行を失敗させて、エラーメッセージを表示します。 - 競合が検出された Mule 設定ファイルの名前をログ出力に記録します。 - 競合が検出された設定ファイルを、現在の Mule ディストリビューションの ​`${MULE_HOME}/conf`​ ディレクトリから ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ にコピーします。 - 設定ファイルの元のコンテンツを、​_新しい_​ Mule ディストリビューションから ​`${MULE_HOME}/upgrade-tool/mule-configs-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}`​ フォルダーにコピーします。 設定ファイルの競合によってアップグレードプロセスが失敗した場合は、以下の手順に従って競合を解決してから、アップグレードプロセスを続行してください。 ### [](#steps-to-solve-conflicts)Mule 設定ファイルの競合を解決する手順 アップグレード中に競合を解決する手順は、次のとおりです。 1. アップグレード中の現在の Mule ディストリビューションの ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/`​ フォルダーで、競合が検出されたファイルのいずれかを選択します。 2. ファイル比較ツール (​`diff`​ など) を使用して、次のパスのファイルのコンテンツを比較します。 - `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf` - `${MULE_HOME}/upgrade-tool/mule-configs-files/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf` 3. 相違点を確認したら、変更内容をマージするか、または破棄してください。 - 変更内容をマージする場合は、新しい設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf`​ ファイルから目的の変更内容を追加して前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を変更します。次に、マージしたファイルを ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーにコピーします。 - 変更内容を破棄して前の設定を保持する場合は、前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーに移動します。 変更内容を破棄すると、古い設定が新しい Mule ディストリビューションで使用される場合があります。 4. `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ フォルダー内の各設定ファイルに対してステップ 1 ～ 3 を繰り返します。 5. `upgrade`​ サブコマンドの実行を再試行します。 アップグレードが正常に完了すると、ツールは ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts`​ フォルダーを削除し、将来のアップグレードに備えてクリーンな環境に戻します。 ### [](#無人のアップグレードまたは更新)無人のアップグレードまたは更新 対象環境でアップグレードを実行する前に、別の環境で競合を解決しておけば、アップグレードや更新を無人で実行できます。この手順は、別の環境で設定する​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションが、メイン環境の​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションのバージョンと一致する場合にのみ使用できます。 1. ユーザーインタラクションが可能な環境で、​[Mule 設定ファイルの競合を解決する手順](#steps-to-solve-conflicts)​の説明に従ってすべての競合を確認して解決します。 2. 対象環境で、​`${MULE_HOME_WITH_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ から ​`${MULE_HOME_WITHOUT_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ にファイルをコピーします。 3. 対象環境で ​`upgrade`​ サブコマンドを実行します。 ## [](#mule-アップグレードツールのログの設定)Mule アップグレードツールのログの設定 デバッグのログを有効化することで、Mule アップグレードツールの各操作の詳細情報を追加したり、ツールがログを保存するフォルダーを変更したり、カスタマイズされたログ設定ファイルを使用したりできます。 ### [](#カスタム-log4j-ファイルの指定)カスタム Log4j ファイルの指定 デフォルトでは、Mule アップグレードツールは ​`$MULE_HOME/tools/upgrade-tool`​ フォルダーにある ​`log4j2-upgrade-tool.xml`​ ファイルを使用します。 カスタム Log4j ファイルを使用するには、​`-l`​ パラメーターを使用して、使用するカスタム Log4j 設定ファイルのファイル名を指定します。例: ```bash $MULE_HOME/tools/upgrade-tool -l myLog4j2File.xml upgrade ``` ### [](#デバッグレベルログの有効化)デバッグレベルログの有効化 デバッグログを有効化する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. Log4j ファイルの次の行で、​`level`​ プロパティの値を ​`INFO`​ から ​`DEBUG`​ に変更します。 ```xml ``` ### [](#ログ出力のカスタマイズ)ログ出力のカスタマイズ デフォルトでは、Mule アップグレードツールは ​`./mule-Runtime-upgrade-tool-logs`​ ディレクトリにログファイルを保存します。 ファイル名、出力パス、ログパターンを変更する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. `fileName`​ プロパティと ​`filePattern`​ プロパティに希望する値を指定します。 ```xml ``` ## [](#mule-アップグレードツールのサブコマンドとオプション)Mule アップグレードツールのサブコマンドとオプション Mule アップグレードツールの実行時に使用できるサブコマンドとオプションを下表に示します。
サブコマンド 説明

upgrade

ローカル Mule インスタンスを、使用できる最新バージョンにアップグレードします。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-n <newMuleDistributionPath>​

ローカル Mule インスタンスを、ファイルシステムにダウンロードして展開してあるディストリビューションにアップグレードします。​<newMuleDistribution>​ パラメーターを使用して、新しい Mule ディストリビューションのパスを指定できます。例:
​$ ./upgrade-tool upgrade -n /<newMuleDistributionPath>​

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスをアップグレードします。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスをアップグレードできます。例:
​$ ./upgrade-tool upgrade -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、アップグレードプロセスをシミュレーションします。

-f​

バックアップの上書きや適用したパッチの削除といった破壊的な操作に対してユーザーの確認を要求せずにアップグレードを実行します。

-h​

このサブコマンドのヘルプメッセージを表示します。

rollback

Mule インスタンスを以前の状態に戻します。このサブコマンドは、ツールでアップグレードを正常に完了した後でのみ使用できます。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスを復元します。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスを復元できます。例:
​$ ./upgrade-tool rollback -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、ロールバックプロセスをシミュレーションします。

-f​

ユーザーの確認を要求せずに Mule インスタンスを復元します。

-h​

このサブコマンドのヘルプメッセージを表示します。

status

現在の Mule インスタンスに関して、次のような情報を提供します。

  • Mule Runtime Engine バージョン

  • 現在の Mule インスタンスがアップグレードまたはロールバックの条件を満たしていることを確認するメッセージ

  • 既存のバックアップとその場所

  • バックアップが存在する場合はその整合性
## [](#一般的なエラーのトラブルシューティング)一般的なエラーのトラブルシューティング 以下に、アップグレードツールから返される最も一般的なエラーメッセージの一部と、それぞれの説明および解決策を示します。 ### [](#missing-required-subcommand-必要なサブコマンドがありません)Missing Required Subcommand (必要なサブコマンドがありません) ./upgrade-tool Mule Runtime Upgrade Tool ───────────────────────── Missing required subcommand Usage: upgrade-tool \[-hV\] \[COMMAND\] Try 'upgrade-tool --help' for more information. #### [](#原因)原因 このエラーは、未知の、または存在しないサブコマンドが指定されたことを示します。サポートされているサブコマンドは、​`upgrade`​、​`rollback`​、​`status`​ のみです。 #### [](#解決策)解決策 `upgrade-tool`​ コマンドと、サポートされているいずれかのサブコマンド (​`upgrade`​、​`rollback`​、または ​`status`​) を実行していることを確認します。 `-h`​ または ​`--help`​ オプションを使用すると、特定のサブコマンドの詳細情報を見ることができます。例: $ ./upgrade-tool rollback --help ### [](#missing-required-option-必須のオプションがありません)Missing Required Option (必須のオプションがありません) ./upgrade-tool upgrade Mule Runtime Upgrade Tool ───────────────────────── Missing required option: '--new-mule-distro=' Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Try 'upgrade-tool upgrade --help' for more information. #### [](#原因-2)原因 このエラーは、選択したサブコマンドに追加の引数が必要であることを示しています。たとえば、アップグレード時には引数 ​`--new-mule-distro`​ が必要です。 #### [](#解決策-2)解決策 次のコマンドを実行して、特定のサブコマンドで必要な引数に関する情報を確認します。 ./upgrade-tool upgrade --help このコマンドを実行すると、追加情報が次のように表示されます。 Mule Runtime Upgrade Tool ───────────────────────── Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Upgrades a Mule Runtime to a newer version -d, --dry-run Simulate upgrade process without performing any permanent changes to the current Mule Runtime Distribution. -f, --force Perform all the destructive operations like overwriting the backup or removing the applied patches without user confirmation -h, --help Display this help message -n, --new-mule-distro= File path of the newer Mule Runtime distribution used for the upgrade -o, --old-mule-distro= File path of Mule Runtime distribution to upgrade `Usage:`​ 行では、省略可能なオプションと引数が角括弧 (​`[`,`]`​) 内に示されます。角括弧が付いていないオプションと引数は必須です。 ### [](#no-space-left-on-device-デバイスにスペースがありません)No Space Left on Device (デバイスにスペースがありません) $ ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 ERROR: There's not enough disk space for performing the upgrade. ERROR: No space left on device No space left on device #### [](#原因-3)原因 このエラーは、アップグレードを実行するのに必要な空きディスクスペースがないことを示します。 #### [](#解決策-3)解決策 アップグレードツールは、Mule インスタンスが動作しているファイルシステムに 2 GB 以上の空きスペースを必要とします。システムに十分なディスクスペースがあり、他の要件も満足されていることを確認してください。 Linux 環境では、​`df`​ コマンドで空きディスクスペースを確認できます。 $ df -h /opt Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-opt 419G 205G 193G 52% /opt ### [](#version-should-be-newer-新しいバージョンが必要です)Version Should Be Newer (新しいバージョンが必要です) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 #### [](#原因-4)原因 このエラーは、upgrade コマンドで、現在の Mule インスタンスと同じバージョンの新しい Mule ディストリビューションが指定された場合に発生します。 #### [](#解決策-4)解決策 ダウンロードした Mule ディストリビューションが現在の Mule インスタンスよりも新しいバージョンであることを確認してください。アップグレード中にこのエラーメッセージが連続して返される場合は、現在の Mule インスタンスがすでにアップグレード済みであるか、または最新のバージョンが実行中であることを意味します。 ### [](#missing-reading-permissions-参照権限がありません)Missing Reading Permissions (参照権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required reading permissions under Mule distribution \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] java.nio.file.AccessDeniedException: /tmp/mule-enterprise-standalone-4.4.0-20211104/lib/mule/mule-module-cache-ee-4.4.0-20211104.jar \[...\] #### [](#原因-5)原因 新しい Mule ディストリビューションで必要な参照権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルを参照できません。 #### [](#解決策-5)解決策 アップグレードツールによって参照不能として特定されているファイルの参照権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#missing-writing-permissions-書き込み権限がありません)Missing Writing Permissions (書き込み権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required writing permissions under Mule distribution \[/opt/mule-enterprise-standalone-4.4.0-20211026\] java.nio.file.AccessDeniedException: /opt/mule-enterprise-standalone-4.4.0-20211026/lib/boot/libwrapper-linux-ppcle-64.so \[...\] #### [](#原因-6)原因 古い Mule ディストリビューションで必要な書き込み権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルに書き込めません。 #### [](#解決策-6)解決策 アップグレードツールによって特定されたファイルへの書き込み権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#mule-runtime-should-be-stopped-mule-runtime-を停止する必要があります)Mule Runtime Should Be Stopped (Mule Runtime を停止する必要があります) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Mule Runtime should be stopped. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-7)原因 Mule が実行中であることをアップグレードツールが検出しました。 #### [](#解決策-7)解決策 アップグレードプロセスを開始する前に Mule を停止してください。現在の状況を確認するには ​`${MULE_HOME}/bin/mule status`​ コマンドを使用します。 ### [](#mule-version-isnt-supported-for-an-upgrade-アップグレードでサポートされていない-mule-バージョンです)Mule Version Isn’t Supported for an Upgrade (アップグレードでサポートされていない Mule バージョンです) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/tmp/mule-enterprise-standalone-4.1.1-20211222\] with version: \[4.1.1\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211026\] with version \[4.4.0-20211026\] ... ERROR: Your Mule version cannot be upgraded to the new one, you need to upgrade to a version greater than 4.1.5, or for versions between 4.1.1 to 4.1.4, then packages released after January 20, 2022. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-8)原因 Mule アップグレードツールでは、現在の Mule インスタンスと新しい Mule インスタンス (​`/new-${MULE_HOME_NEW_FOLDER_NAME}`​) の両方がバージョン 4.1.5 以降である必要があります。 #### [](#解決策-8)解決策 Mule アップグレードツールを使用してアップグレードを実行する前に、現在の Mule インスタンスと新しい Mule インスタンスの両方をバージョン 4.1.5 以降に手動でアップグレードしてください。 ## [](#upgrade_clustered_mule_instances)クラスタリングされた Mule アプリケーションのアップグレード クラスタリングされた Mule インスタンスをアップグレードするには、Mule アップグレードツールを使用して各ノードを手動でアップグレードすることにより、ローカル Mule インスタンスのアップグレードプロセスを自動化します。 ### [](#始める前に-2)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 新しい Mule Runtime ディストリビューション (対象バージョン) と、アップグレードする各ノードにコピーされた Mule アップグレードツール (ダウンタイムを短縮するため)。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ### [](#mule-のアップグレードまたは更新-2)Mule のアップグレードまたは更新 クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 ➜ tools ./upgrade-tool upgrade -n /Users/me/mule-download/upgrade/mule-enterprise-standalone-4.5.0/ Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。
対象の場所が ​$MULE_HOME​ であるため、アップグレードした Mule Runtime インスタンスによって以前のバージョンが置き換えられます。
すべてのノードを同じ Mule Runtime バージョンにアップグレードまたは更新しないと正常に動作しませんのでご注意ください。 ### [](#アップグレードまたは更新のロールバック-2)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` すべてのノードを同じ Mule Runtime バージョンにロールバックしないと正常に動作しませんのでご注意ください。 ## [](#関連情報)関連情報 - [Mule Upgrades and Patch Updates (Mule のアップグレードとパッチの更新)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) # Mule アップグレードツール The Mule upgrade tool is a command line utility for updating and upgrading standalone on-premise instances of Mule 4. Download the tool and integrate it with your existing automated processes and workflows by using scripts and cron jobs. 現在の Mule インスタンスに Runtime Manager エージェントがインストールされている場合、アップグレードツールは、アップグレードプロセスの一環としてエージェントのバージョンも更新します。 Anypoint Monitoring エージェントのアップグレードはサポートされていません。アップグレードを続行するには、まずエージェントをアンインストールし、Mule インスタンスのアップグレードが完了してから再インストールする必要があります。​[「Anypoint Monitoring エージェントの更新」](https://docs.mulesoft.com/jp/monitoring/am-installing#update-the-anypoint-monitoring-agent)​を参照してください。 アップグレードツールでは、アップグレードするランタイムで実行されている Mule アプリケーションは変更されません。 Mule アップグレードツールは、ツールを使用して各ノードを手動でアップグレードすることにより、クラスタリングされた Mule インスタンスのアップグレードをサポートしています。アップグレードを続行する方法についての追加情報は、​[クラスタリングされた Mule アプリケーションのアップグレード](#upgrade_clustered_mule_instances)​を参照してください。このツールの使用を強くお勧めしますが、現在の Mule インスタンスをアップグレードするのに厳格に必要なわけではありません。完全に手動でのアップグレードについては、​[「Upgrading an On-Premises Mule Instance Managed Through Runtime Manager (Runtime Manager で管理されているオンプレミス Mule インスタンスのアップグレード)」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions#mulerunvers)​を参照してください。 ## [](#始める前に)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ## [](#mule-のアップグレードまたは更新)Mule のアップグレードまたは更新 クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 ➜ tools ./upgrade-tool upgrade -n /Users/me/mule-download/upgrade/mule-enterprise-standalone-4.5.0/ Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。
対象の場所が ​$MULE_HOME​ であるため、アップグレードした Mule Runtime インスタンスによって以前のバージョンが置き換えられます。
## [](#アップグレードまたは更新のロールバック)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` ## [](#ファイルの競合の解決)ファイルの競合の解決 Mule アップグレードツールは、​_現在の_​ Mule ディストリビューションと​_新しい_​ディストリビューションの設定ファイルを比較し、変更された内容を検出して失われないようにします。Mule アップグレードツールが​_新しい_​ Mule ディストリビューションの設定ファイルで変更を検出すると、自動的に競合を解決し、アップグレードを続行しようとします。競合を自動的に解決できない場合、ツールでは次のアクションを実行します。 - `upgrade`​ サブコマンドの実行を失敗させて、エラーメッセージを表示します。 - 競合が検出された Mule 設定ファイルの名前をログ出力に記録します。 - 競合が検出された設定ファイルを、現在の Mule ディストリビューションの ​`${MULE_HOME}/conf`​ ディレクトリから ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ にコピーします。 - 設定ファイルの元のコンテンツを、​_新しい_​ Mule ディストリビューションから ​`${MULE_HOME}/upgrade-tool/mule-configs-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}`​ フォルダーにコピーします。 設定ファイルの競合によってアップグレードプロセスが失敗した場合は、以下の手順に従って競合を解決してから、アップグレードプロセスを続行してください。 ### [](#steps-to-solve-conflicts)Mule 設定ファイルの競合を解決する手順 アップグレード中に競合を解決する手順は、次のとおりです。 1. アップグレード中の現在の Mule ディストリビューションの ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/`​ フォルダーで、競合が検出されたファイルのいずれかを選択します。 2. ファイル比較ツール (​`diff`​ など) を使用して、次のパスのファイルのコンテンツを比較します。 - `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf` - `${MULE_HOME}/upgrade-tool/mule-configs-files/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf` 3. 相違点を確認したら、変更内容をマージするか、または破棄してください。 - 変更内容をマージする場合は、新しい設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf`​ ファイルから目的の変更内容を追加して前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を変更します。次に、マージしたファイルを ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーにコピーします。 - 変更内容を破棄して前の設定を保持する場合は、前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーに移動します。 変更内容を破棄すると、古い設定が新しい Mule ディストリビューションで使用される場合があります。 4. `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ フォルダー内の各設定ファイルに対してステップ 1 ～ 3 を繰り返します。 5. `upgrade`​ サブコマンドの実行を再試行します。 アップグレードが正常に完了すると、ツールは ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts`​ フォルダーを削除し、将来のアップグレードに備えてクリーンな環境に戻します。 ### [](#無人のアップグレードまたは更新)無人のアップグレードまたは更新 対象環境でアップグレードを実行する前に、別の環境で競合を解決しておけば、アップグレードや更新を無人で実行できます。この手順は、別の環境で設定する​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションが、メイン環境の​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションのバージョンと一致する場合にのみ使用できます。 1. ユーザーインタラクションが可能な環境で、​[Mule 設定ファイルの競合を解決する手順](#steps-to-solve-conflicts)​の説明に従ってすべての競合を確認して解決します。 2. 対象環境で、​`${MULE_HOME_WITH_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ から ​`${MULE_HOME_WITHOUT_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ にファイルをコピーします。 3. 対象環境で ​`upgrade`​ サブコマンドを実行します。 ## [](#mule-アップグレードツールのログの設定)Mule アップグレードツールのログの設定 デバッグのログを有効化することで、Mule アップグレードツールの各操作の詳細情報を追加したり、ツールがログを保存するフォルダーを変更したり、カスタマイズされたログ設定ファイルを使用したりできます。 ### [](#カスタム-log4j-ファイルの指定)カスタム Log4j ファイルの指定 デフォルトでは、Mule アップグレードツールは ​`$MULE_HOME/tools/upgrade-tool`​ フォルダーにある ​`log4j2-upgrade-tool.xml`​ ファイルを使用します。 カスタム Log4j ファイルを使用するには、​`-l`​ パラメーターを使用して、使用するカスタム Log4j 設定ファイルのファイル名を指定します。例: ```bash $MULE_HOME/tools/upgrade-tool -l myLog4j2File.xml upgrade ``` ### [](#デバッグレベルログの有効化)デバッグレベルログの有効化 デバッグログを有効化する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. Log4j ファイルの次の行で、​`level`​ プロパティの値を ​`INFO`​ から ​`DEBUG`​ に変更します。 ```xml ``` ### [](#ログ出力のカスタマイズ)ログ出力のカスタマイズ デフォルトでは、Mule アップグレードツールは ​`./mule-Runtime-upgrade-tool-logs`​ ディレクトリにログファイルを保存します。 ファイル名、出力パス、ログパターンを変更する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. `fileName`​ プロパティと ​`filePattern`​ プロパティに希望する値を指定します。 ```xml ``` ## [](#mule-アップグレードツールのサブコマンドとオプション)Mule アップグレードツールのサブコマンドとオプション Mule アップグレードツールの実行時に使用できるサブコマンドとオプションを下表に示します。
サブコマンド 説明

upgrade

ローカル Mule インスタンスを、使用できる最新バージョンにアップグレードします。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-n <newMuleDistributionPath>​

ローカル Mule インスタンスを、ファイルシステムにダウンロードして展開してあるディストリビューションにアップグレードします。​<newMuleDistribution>​ パラメーターを使用して、新しい Mule ディストリビューションのパスを指定できます。例:
​$ ./upgrade-tool upgrade -n /<newMuleDistributionPath>​

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスをアップグレードします。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスをアップグレードできます。例:
​$ ./upgrade-tool upgrade -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、アップグレードプロセスをシミュレーションします。

-f​

バックアップの上書きや適用したパッチの削除といった破壊的な操作に対してユーザーの確認を要求せずにアップグレードを実行します。

-h​

このサブコマンドのヘルプメッセージを表示します。

rollback

Mule インスタンスを以前の状態に戻します。このサブコマンドは、ツールでアップグレードを正常に完了した後でのみ使用できます。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスを復元します。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスを復元できます。例:
​$ ./upgrade-tool rollback -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、ロールバックプロセスをシミュレーションします。

-f​

ユーザーの確認を要求せずに Mule インスタンスを復元します。

-h​

このサブコマンドのヘルプメッセージを表示します。

status

現在の Mule インスタンスに関して、次のような情報を提供します。

  • Mule Runtime Engine バージョン

  • 現在の Mule インスタンスがアップグレードまたはロールバックの条件を満たしていることを確認するメッセージ

  • 既存のバックアップとその場所

  • バックアップが存在する場合はその整合性
## [](#一般的なエラーのトラブルシューティング)一般的なエラーのトラブルシューティング 以下に、アップグレードツールから返される最も一般的なエラーメッセージの一部と、それぞれの説明および解決策を示します。 ### [](#missing-required-subcommand-必要なサブコマンドがありません)Missing Required Subcommand (必要なサブコマンドがありません) ./upgrade-tool Mule Runtime Upgrade Tool ───────────────────────── Missing required subcommand Usage: upgrade-tool \[-hV\] \[COMMAND\] Try 'upgrade-tool --help' for more information. #### [](#原因)原因 このエラーは、未知の、または存在しないサブコマンドが指定されたことを示します。サポートされているサブコマンドは、​`upgrade`​、​`rollback`​、​`status`​ のみです。 #### [](#解決策)解決策 `upgrade-tool`​ コマンドと、サポートされているいずれかのサブコマンド (​`upgrade`​、​`rollback`​、または ​`status`​) を実行していることを確認します。 `-h`​ または ​`--help`​ オプションを使用すると、特定のサブコマンドの詳細情報を見ることができます。例: $ ./upgrade-tool rollback --help ### [](#missing-required-option-必須のオプションがありません)Missing Required Option (必須のオプションがありません) ./upgrade-tool upgrade Mule Runtime Upgrade Tool ───────────────────────── Missing required option: '--new-mule-distro=' Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Try 'upgrade-tool upgrade --help' for more information. #### [](#原因-2)原因 このエラーは、選択したサブコマンドに追加の引数が必要であることを示しています。たとえば、アップグレード時には引数 ​`--new-mule-distro`​ が必要です。 #### [](#解決策-2)解決策 次のコマンドを実行して、特定のサブコマンドで必要な引数に関する情報を確認します。 ./upgrade-tool upgrade --help このコマンドを実行すると、追加情報が次のように表示されます。 Mule Runtime Upgrade Tool ───────────────────────── Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Upgrades a Mule Runtime to a newer version -d, --dry-run Simulate upgrade process without performing any permanent changes to the current Mule Runtime Distribution. -f, --force Perform all the destructive operations like overwriting the backup or removing the applied patches without user confirmation -h, --help Display this help message -n, --new-mule-distro= File path of the newer Mule Runtime distribution used for the upgrade -o, --old-mule-distro= File path of Mule Runtime distribution to upgrade `Usage:`​ 行では、省略可能なオプションと引数が角括弧 (​`[`,`]`​) 内に示されます。角括弧が付いていないオプションと引数は必須です。 ### [](#no-space-left-on-device-デバイスにスペースがありません)No Space Left on Device (デバイスにスペースがありません) $ ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 ERROR: There's not enough disk space for performing the upgrade. ERROR: No space left on device No space left on device #### [](#原因-3)原因 このエラーは、アップグレードを実行するのに必要な空きディスクスペースがないことを示します。 #### [](#解決策-3)解決策 アップグレードツールは、Mule インスタンスが動作しているファイルシステムに 2 GB 以上の空きスペースを必要とします。システムに十分なディスクスペースがあり、他の要件も満足されていることを確認してください。 Linux 環境では、​`df`​ コマンドで空きディスクスペースを確認できます。 $ df -h /opt Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-opt 419G 205G 193G 52% /opt ### [](#version-should-be-newer-新しいバージョンが必要です)Version Should Be Newer (新しいバージョンが必要です) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 #### [](#原因-4)原因 このエラーは、upgrade コマンドで、現在の Mule インスタンスと同じバージョンの新しい Mule ディストリビューションが指定された場合に発生します。 #### [](#解決策-4)解決策 ダウンロードした Mule ディストリビューションが現在の Mule インスタンスよりも新しいバージョンであることを確認してください。アップグレード中にこのエラーメッセージが連続して返される場合は、現在の Mule インスタンスがすでにアップグレード済みであるか、または最新のバージョンが実行中であることを意味します。 ### [](#missing-reading-permissions-参照権限がありません)Missing Reading Permissions (参照権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required reading permissions under Mule distribution \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] java.nio.file.AccessDeniedException: /tmp/mule-enterprise-standalone-4.4.0-20211104/lib/mule/mule-module-cache-ee-4.4.0-20211104.jar \[...\] #### [](#原因-5)原因 新しい Mule ディストリビューションで必要な参照権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルを参照できません。 #### [](#解決策-5)解決策 アップグレードツールによって参照不能として特定されているファイルの参照権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#missing-writing-permissions-書き込み権限がありません)Missing Writing Permissions (書き込み権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required writing permissions under Mule distribution \[/opt/mule-enterprise-standalone-4.4.0-20211026\] java.nio.file.AccessDeniedException: /opt/mule-enterprise-standalone-4.4.0-20211026/lib/boot/libwrapper-linux-ppcle-64.so \[...\] #### [](#原因-6)原因 古い Mule ディストリビューションで必要な書き込み権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルに書き込めません。 #### [](#解決策-6)解決策 アップグレードツールによって特定されたファイルへの書き込み権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#mule-runtime-should-be-stopped-mule-runtime-を停止する必要があります)Mule Runtime Should Be Stopped (Mule Runtime を停止する必要があります) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Mule Runtime should be stopped. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-7)原因 Mule が実行中であることをアップグレードツールが検出しました。 #### [](#解決策-7)解決策 アップグレードプロセスを開始する前に Mule を停止してください。現在の状況を確認するには ​`${MULE_HOME}/bin/mule status`​ コマンドを使用します。 ### [](#mule-version-isnt-supported-for-an-upgrade-アップグレードでサポートされていない-mule-バージョンです)Mule Version Isn’t Supported for an Upgrade (アップグレードでサポートされていない Mule バージョンです) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/tmp/mule-enterprise-standalone-4.1.1-20211222\] with version: \[4.1.1\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211026\] with version \[4.4.0-20211026\] ... ERROR: Your Mule version cannot be upgraded to the new one, you need to upgrade to a version greater than 4.1.5, or for versions between 4.1.1 to 4.1.4, then packages released after January 20, 2022. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-8)原因 Mule アップグレードツールでは、現在の Mule インスタンスと新しい Mule インスタンス (​`/new-${MULE_HOME_NEW_FOLDER_NAME}`​) の両方がバージョン 4.1.5 以降である必要があります。 #### [](#解決策-8)解決策 Mule アップグレードツールを使用してアップグレードを実行する前に、現在の Mule インスタンスと新しい Mule インスタンスの両方をバージョン 4.1.5 以降に手動でアップグレードしてください。 ## [](#upgrade_clustered_mule_instances)クラスタリングされた Mule アプリケーションのアップグレード クラスタリングされた Mule インスタンスをアップグレードするには、Mule アップグレードツールを使用して各ノードを手動でアップグレードすることにより、ローカル Mule インスタンスのアップグレードプロセスを自動化します。 ### [](#始める前に-2)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 新しい Mule Runtime ディストリビューション (対象バージョン) と、アップグレードする各ノードにコピーされた Mule アップグレードツール (ダウンタイムを短縮するため)。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ### [](#mule-のアップグレードまたは更新-2)Mule のアップグレードまたは更新 クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 ➜ tools ./upgrade-tool upgrade -n /Users/me/mule-download/upgrade/mule-enterprise-standalone-4.5.0/ Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。
対象の場所が ​$MULE_HOME​ であるため、アップグレードした Mule Runtime インスタンスによって以前のバージョンが置き換えられます。
すべてのノードを同じ Mule Runtime バージョンにアップグレードまたは更新しないと正常に動作しませんのでご注意ください。 ### [](#アップグレードまたは更新のロールバック-2)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` すべてのノードを同じ Mule Runtime バージョンにロールバックしないと正常に動作しませんのでご注意ください。 ## [](#関連情報)関連情報 - [Mule Upgrades and Patch Updates (Mule のアップグレードとパッチの更新)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) # Mule アップグレードツール The Mule upgrade tool is a command line utility for updating and upgrading standalone on-premise instances of Mule 4. Download the tool and integrate it with your existing automated processes and workflows by using scripts and cron jobs. 現在の Mule インスタンスに Runtime Manager エージェントがインストールされている場合、アップグレードツールは、アップグレードプロセスの一環としてエージェントのバージョンも更新します。 Anypoint Monitoring エージェントのアップグレードはサポートされていません。アップグレードを続行するには、まずエージェントをアンインストールし、Mule インスタンスのアップグレードが完了してから再インストールする必要があります。​[「Anypoint Monitoring エージェントの更新」](https://docs.mulesoft.com/jp/monitoring/am-installing#update-the-anypoint-monitoring-agent)​を参照してください。 アップグレードツールでは、アップグレードするランタイムで実行されている Mule アプリケーションは変更されません。 Mule アップグレードツールは、ツールを使用して各ノードを手動でアップグレードすることにより、クラスタリングされた Mule インスタンスのアップグレードをサポートしています。アップグレードを続行する方法についての追加情報は、​[クラスタリングされた Mule アプリケーションのアップグレード](#upgrade_clustered_mule_instances)​を参照してください。このツールの使用を強くお勧めしますが、現在の Mule インスタンスをアップグレードするのに厳格に必要なわけではありません。完全に手動でのアップグレードについては、​[「Upgrading an On-Premises Mule Instance Managed Through Runtime Manager (Runtime Manager で管理されているオンプレミス Mule インスタンスのアップグレード)」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions#mulerunvers)​を参照してください。 ## [](#始める前に)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ## [](#mule-のアップグレードまたは更新)Mule のアップグレードまたは更新 クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 ➜ tools ./upgrade-tool upgrade -n /Users/me/mule-download/upgrade/mule-enterprise-standalone-4.5.0/ Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。
対象の場所が ​$MULE_HOME​ であるため、アップグレードした Mule Runtime インスタンスによって以前のバージョンが置き換えられます。
## [](#アップグレードまたは更新のロールバック)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` ## [](#ファイルの競合の解決)ファイルの競合の解決 Mule アップグレードツールは、​_現在の_​ Mule ディストリビューションと​_新しい_​ディストリビューションの設定ファイルを比較し、変更された内容を検出して失われないようにします。Mule アップグレードツールが​_新しい_​ Mule ディストリビューションの設定ファイルで変更を検出すると、自動的に競合を解決し、アップグレードを続行しようとします。競合を自動的に解決できない場合、ツールでは次のアクションを実行します。 - `upgrade`​ サブコマンドの実行を失敗させて、エラーメッセージを表示します。 - 競合が検出された Mule 設定ファイルの名前をログ出力に記録します。 - 競合が検出された設定ファイルを、現在の Mule ディストリビューションの ​`${MULE_HOME}/conf`​ ディレクトリから ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ にコピーします。 - 設定ファイルの元のコンテンツを、​_新しい_​ Mule ディストリビューションから ​`${MULE_HOME}/upgrade-tool/mule-configs-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}`​ フォルダーにコピーします。 設定ファイルの競合によってアップグレードプロセスが失敗した場合は、以下の手順に従って競合を解決してから、アップグレードプロセスを続行してください。 ### [](#steps-to-solve-conflicts)Mule 設定ファイルの競合を解決する手順 アップグレード中に競合を解決する手順は、次のとおりです。 1. アップグレード中の現在の Mule ディストリビューションの ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/`​ フォルダーで、競合が検出されたファイルのいずれかを選択します。 2. ファイル比較ツール (​`diff`​ など) を使用して、次のパスのファイルのコンテンツを比較します。 - `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf` - `${MULE_HOME}/upgrade-tool/mule-configs-files/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf` 3. 相違点を確認したら、変更内容をマージするか、または破棄してください。 - 変更内容をマージする場合は、新しい設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf`​ ファイルから目的の変更内容を追加して前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を変更します。次に、マージしたファイルを ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーにコピーします。 - 変更内容を破棄して前の設定を保持する場合は、前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーに移動します。 変更内容を破棄すると、古い設定が新しい Mule ディストリビューションで使用される場合があります。 4. `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ フォルダー内の各設定ファイルに対してステップ 1 ～ 3 を繰り返します。 5. `upgrade`​ サブコマンドの実行を再試行します。 アップグレードが正常に完了すると、ツールは ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts`​ フォルダーを削除し、将来のアップグレードに備えてクリーンな環境に戻します。 ### [](#無人のアップグレードまたは更新)無人のアップグレードまたは更新 対象環境でアップグレードを実行する前に、別の環境で競合を解決しておけば、アップグレードや更新を無人で実行できます。この手順は、別の環境で設定する​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションが、メイン環境の​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションのバージョンと一致する場合にのみ使用できます。 1. ユーザーインタラクションが可能な環境で、​[Mule 設定ファイルの競合を解決する手順](#steps-to-solve-conflicts)​の説明に従ってすべての競合を確認して解決します。 2. 対象環境で、​`${MULE_HOME_WITH_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ から ​`${MULE_HOME_WITHOUT_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ にファイルをコピーします。 3. 対象環境で ​`upgrade`​ サブコマンドを実行します。 ## [](#mule-アップグレードツールのログの設定)Mule アップグレードツールのログの設定 デバッグのログを有効化することで、Mule アップグレードツールの各操作の詳細情報を追加したり、ツールがログを保存するフォルダーを変更したり、カスタマイズされたログ設定ファイルを使用したりできます。 ### [](#カスタム-log4j-ファイルの指定)カスタム Log4j ファイルの指定 デフォルトでは、Mule アップグレードツールは ​`$MULE_HOME/tools/upgrade-tool`​ フォルダーにある ​`log4j2-upgrade-tool.xml`​ ファイルを使用します。 カスタム Log4j ファイルを使用するには、​`-l`​ パラメーターを使用して、使用するカスタム Log4j 設定ファイルのファイル名を指定します。例: ```bash $MULE_HOME/tools/upgrade-tool -l myLog4j2File.xml upgrade ``` ### [](#デバッグレベルログの有効化)デバッグレベルログの有効化 デバッグログを有効化する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. Log4j ファイルの次の行で、​`level`​ プロパティの値を ​`INFO`​ から ​`DEBUG`​ に変更します。 ```xml ``` ### [](#ログ出力のカスタマイズ)ログ出力のカスタマイズ デフォルトでは、Mule アップグレードツールは ​`./mule-Runtime-upgrade-tool-logs`​ ディレクトリにログファイルを保存します。 ファイル名、出力パス、ログパターンを変更する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. `fileName`​ プロパティと ​`filePattern`​ プロパティに希望する値を指定します。 ```xml ``` ## [](#mule-アップグレードツールのサブコマンドとオプション)Mule アップグレードツールのサブコマンドとオプション Mule アップグレードツールの実行時に使用できるサブコマンドとオプションを下表に示します。
サブコマンド 説明

upgrade

ローカル Mule インスタンスを、使用できる最新バージョンにアップグレードします。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-n <newMuleDistributionPath>​

ローカル Mule インスタンスを、ファイルシステムにダウンロードして展開してあるディストリビューションにアップグレードします。​<newMuleDistribution>​ パラメーターを使用して、新しい Mule ディストリビューションのパスを指定できます。例:
​$ ./upgrade-tool upgrade -n /<newMuleDistributionPath>​

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスをアップグレードします。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスをアップグレードできます。例:
​$ ./upgrade-tool upgrade -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、アップグレードプロセスをシミュレーションします。

-f​

バックアップの上書きや適用したパッチの削除といった破壊的な操作に対してユーザーの確認を要求せずにアップグレードを実行します。

-h​

このサブコマンドのヘルプメッセージを表示します。

rollback

Mule インスタンスを以前の状態に戻します。このサブコマンドは、ツールでアップグレードを正常に完了した後でのみ使用できます。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスを復元します。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスを復元できます。例:
​$ ./upgrade-tool rollback -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、ロールバックプロセスをシミュレーションします。

-f​

ユーザーの確認を要求せずに Mule インスタンスを復元します。

-h​

このサブコマンドのヘルプメッセージを表示します。

status

現在の Mule インスタンスに関して、次のような情報を提供します。

  • Mule Runtime Engine バージョン

  • 現在の Mule インスタンスがアップグレードまたはロールバックの条件を満たしていることを確認するメッセージ

  • 既存のバックアップとその場所

  • バックアップが存在する場合はその整合性
## [](#一般的なエラーのトラブルシューティング)一般的なエラーのトラブルシューティング 以下に、アップグレードツールから返される最も一般的なエラーメッセージの一部と、それぞれの説明および解決策を示します。 ### [](#missing-required-subcommand-必要なサブコマンドがありません)Missing Required Subcommand (必要なサブコマンドがありません) ./upgrade-tool Mule Runtime Upgrade Tool ───────────────────────── Missing required subcommand Usage: upgrade-tool \[-hV\] \[COMMAND\] Try 'upgrade-tool --help' for more information. #### [](#原因)原因 このエラーは、未知の、または存在しないサブコマンドが指定されたことを示します。サポートされているサブコマンドは、​`upgrade`​、​`rollback`​、​`status`​ のみです。 #### [](#解決策)解決策 `upgrade-tool`​ コマンドと、サポートされているいずれかのサブコマンド (​`upgrade`​、​`rollback`​、または ​`status`​) を実行していることを確認します。 `-h`​ または ​`--help`​ オプションを使用すると、特定のサブコマンドの詳細情報を見ることができます。例: $ ./upgrade-tool rollback --help ### [](#missing-required-option-必須のオプションがありません)Missing Required Option (必須のオプションがありません) ./upgrade-tool upgrade Mule Runtime Upgrade Tool ───────────────────────── Missing required option: '--new-mule-distro=' Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Try 'upgrade-tool upgrade --help' for more information. #### [](#原因-2)原因 このエラーは、選択したサブコマンドに追加の引数が必要であることを示しています。たとえば、アップグレード時には引数 ​`--new-mule-distro`​ が必要です。 #### [](#解決策-2)解決策 次のコマンドを実行して、特定のサブコマンドで必要な引数に関する情報を確認します。 ./upgrade-tool upgrade --help このコマンドを実行すると、追加情報が次のように表示されます。 Mule Runtime Upgrade Tool ───────────────────────── Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Upgrades a Mule Runtime to a newer version -d, --dry-run Simulate upgrade process without performing any permanent changes to the current Mule Runtime Distribution. -f, --force Perform all the destructive operations like overwriting the backup or removing the applied patches without user confirmation -h, --help Display this help message -n, --new-mule-distro= File path of the newer Mule Runtime distribution used for the upgrade -o, --old-mule-distro= File path of Mule Runtime distribution to upgrade `Usage:`​ 行では、省略可能なオプションと引数が角括弧 (​`[`,`]`​) 内に示されます。角括弧が付いていないオプションと引数は必須です。 ### [](#no-space-left-on-device-デバイスにスペースがありません)No Space Left on Device (デバイスにスペースがありません) $ ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 ERROR: There's not enough disk space for performing the upgrade. ERROR: No space left on device No space left on device #### [](#原因-3)原因 このエラーは、アップグレードを実行するのに必要な空きディスクスペースがないことを示します。 #### [](#解決策-3)解決策 アップグレードツールは、Mule インスタンスが動作しているファイルシステムに 2 GB 以上の空きスペースを必要とします。システムに十分なディスクスペースがあり、他の要件も満足されていることを確認してください。 Linux 環境では、​`df`​ コマンドで空きディスクスペースを確認できます。 $ df -h /opt Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-opt 419G 205G 193G 52% /opt ### [](#version-should-be-newer-新しいバージョンが必要です)Version Should Be Newer (新しいバージョンが必要です) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 #### [](#原因-4)原因 このエラーは、upgrade コマンドで、現在の Mule インスタンスと同じバージョンの新しい Mule ディストリビューションが指定された場合に発生します。 #### [](#解決策-4)解決策 ダウンロードした Mule ディストリビューションが現在の Mule インスタンスよりも新しいバージョンであることを確認してください。アップグレード中にこのエラーメッセージが連続して返される場合は、現在の Mule インスタンスがすでにアップグレード済みであるか、または最新のバージョンが実行中であることを意味します。 ### [](#missing-reading-permissions-参照権限がありません)Missing Reading Permissions (参照権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required reading permissions under Mule distribution \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] java.nio.file.AccessDeniedException: /tmp/mule-enterprise-standalone-4.4.0-20211104/lib/mule/mule-module-cache-ee-4.4.0-20211104.jar \[...\] #### [](#原因-5)原因 新しい Mule ディストリビューションで必要な参照権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルを参照できません。 #### [](#解決策-5)解決策 アップグレードツールによって参照不能として特定されているファイルの参照権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#missing-writing-permissions-書き込み権限がありません)Missing Writing Permissions (書き込み権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required writing permissions under Mule distribution \[/opt/mule-enterprise-standalone-4.4.0-20211026\] java.nio.file.AccessDeniedException: /opt/mule-enterprise-standalone-4.4.0-20211026/lib/boot/libwrapper-linux-ppcle-64.so \[...\] #### [](#原因-6)原因 古い Mule ディストリビューションで必要な書き込み権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルに書き込めません。 #### [](#解決策-6)解決策 アップグレードツールによって特定されたファイルへの書き込み権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#mule-runtime-should-be-stopped-mule-runtime-を停止する必要があります)Mule Runtime Should Be Stopped (Mule Runtime を停止する必要があります) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Mule Runtime should be stopped. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-7)原因 Mule が実行中であることをアップグレードツールが検出しました。 #### [](#解決策-7)解決策 アップグレードプロセスを開始する前に Mule を停止してください。現在の状況を確認するには ​`${MULE_HOME}/bin/mule status`​ コマンドを使用します。 ### [](#mule-version-isnt-supported-for-an-upgrade-アップグレードでサポートされていない-mule-バージョンです)Mule Version Isn’t Supported for an Upgrade (アップグレードでサポートされていない Mule バージョンです) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/tmp/mule-enterprise-standalone-4.1.1-20211222\] with version: \[4.1.1\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211026\] with version \[4.4.0-20211026\] ... ERROR: Your Mule version cannot be upgraded to the new one, you need to upgrade to a version greater than 4.1.5, or for versions between 4.1.1 to 4.1.4, then packages released after January 20, 2022. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-8)原因 Mule アップグレードツールでは、現在の Mule インスタンスと新しい Mule インスタンス (​`/new-${MULE_HOME_NEW_FOLDER_NAME}`​) の両方がバージョン 4.1.5 以降である必要があります。 #### [](#解決策-8)解決策 Mule アップグレードツールを使用してアップグレードを実行する前に、現在の Mule インスタンスと新しい Mule インスタンスの両方をバージョン 4.1.5 以降に手動でアップグレードしてください。 ## [](#upgrade_clustered_mule_instances)クラスタリングされた Mule アプリケーションのアップグレード クラスタリングされた Mule インスタンスをアップグレードするには、Mule アップグレードツールを使用して各ノードを手動でアップグレードすることにより、ローカル Mule インスタンスのアップグレードプロセスを自動化します。 ### [](#始める前に-2)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 新しい Mule Runtime ディストリビューション (対象バージョン) と、アップグレードする各ノードにコピーされた Mule アップグレードツール (ダウンタイムを短縮するため)。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ### [](#mule-のアップグレードまたは更新-2)Mule のアップグレードまたは更新 クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 ➜ tools ./upgrade-tool upgrade -n /Users/me/mule-download/upgrade/mule-enterprise-standalone-4.5.0/ Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。
対象の場所が ​$MULE_HOME​ であるため、アップグレードした Mule Runtime インスタンスによって以前のバージョンが置き換えられます。
すべてのノードを同じ Mule Runtime バージョンにアップグレードまたは更新しないと正常に動作しませんのでご注意ください。 ### [](#アップグレードまたは更新のロールバック-2)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` すべてのノードを同じ Mule Runtime バージョンにロールバックしないと正常に動作しませんのでご注意ください。 ## [](#関連情報)関連情報 - [Mule Upgrades and Patch Updates (Mule のアップグレードとパッチの更新)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) # Mule アップグレードツール The Mule upgrade tool is a command line utility for updating and upgrading standalone on-premise instances of Mule 4. Download the tool and integrate it with your existing automated processes and workflows by using scripts and cron jobs. 現在の Mule インスタンスに Runtime Manager エージェントがインストールされている場合、アップグレードツールは、アップグレードプロセスの一環としてエージェントのバージョンも更新します。 Anypoint Monitoring エージェントのアップグレードはサポートされていません。アップグレードを続行するには、まずエージェントをアンインストールし、Mule インスタンスのアップグレードが完了してから再インストールする必要があります。​[「Anypoint Monitoring エージェントの更新」](https://docs.mulesoft.com/jp/monitoring/am-installing#update-the-anypoint-monitoring-agent)​を参照してください。 アップグレードツールでは、アップグレードするランタイムで実行されている Mule アプリケーションは変更されません。 Mule アップグレードツールは、ツールを使用して各ノードを手動でアップグレードすることにより、クラスタリングされた Mule インスタンスのアップグレードをサポートしています。アップグレードを続行する方法についての追加情報は、​[クラスタリングされた Mule アプリケーションのアップグレード](#upgrade_clustered_mule_instances)​を参照してください。このツールの使用を強くお勧めしますが、現在の Mule インスタンスをアップグレードするのに厳格に必要なわけではありません。完全に手動でのアップグレードについては、​[「Upgrading an On-Premises Mule Instance Managed Through Runtime Manager (Runtime Manager で管理されているオンプレミス Mule インスタンスのアップグレード)」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions#mulerunvers)​を参照してください。 ## [](#始める前に)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ## [](#mule-のアップグレードまたは更新)Mule のアップグレードまたは更新
パラメーター ​<newMuleDistributionAbsolutePath>​ は、アップグレードプロセスで新しい Mule Runtime ディストリビューションが展開される一時的な場所を参照します。アップグレードが正常に完了すれば、この場所はアップグレードツールで不要になるため、安全に削除できます。
クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 ➜ tools ./upgrade-tool upgrade -n /Users/me/mule-download/upgrade/mule-enterprise-standalone-4.5.0/ Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。 ## [](#アップグレードまたは更新のロールバック)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` ## [](#ファイルの競合の解決)ファイルの競合の解決 Mule アップグレードツールは、​_現在の_​ Mule ディストリビューションと​_新しい_​ディストリビューションの設定ファイルを比較し、変更された内容を検出して失われないようにします。Mule アップグレードツールが​_新しい_​ Mule ディストリビューションの設定ファイルで変更を検出すると、自動的に競合を解決し、アップグレードを続行しようとします。競合を自動的に解決できない場合、ツールでは次のアクションを実行します。 - `upgrade`​ サブコマンドの実行を失敗させて、エラーメッセージを表示します。 - 競合が検出された Mule 設定ファイルの名前をログ出力に記録します。 - 競合が検出された設定ファイルを、現在の Mule ディストリビューションの ​`${MULE_HOME}/conf`​ ディレクトリから ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ にコピーします。 - 設定ファイルの元のコンテンツを、​_新しい_​ Mule ディストリビューションから ​`${MULE_HOME}/upgrade-tool/mule-configs-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}`​ フォルダーにコピーします。 設定ファイルの競合によってアップグレードプロセスが失敗した場合は、以下の手順に従って競合を解決してから、アップグレードプロセスを続行してください。 ### [](#steps-to-solve-conflicts)Mule 設定ファイルの競合を解決する手順 アップグレード中に競合を解決する手順は、次のとおりです。 1. アップグレード中の現在の Mule ディストリビューションの ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/`​ フォルダーで、競合が検出されたファイルのいずれかを選択します。 2. ファイル比較ツール (​`diff`​ など) を使用して、次のパスのファイルのコンテンツを比較します。 - `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf` - `${MULE_HOME}/upgrade-tool/mule-configs-files/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf` 3. 相違点を確認したら、変更内容をマージするか、または破棄してください。 - 変更内容をマージする場合は、新しい設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/new-${MULE_HOME_NEW_FOLDER_NAME}/fileWithConflicts.conf`​ ファイルから目的の変更内容を追加して前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を変更します。次に、マージしたファイルを ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーにコピーします。 - 変更内容を破棄して前の設定を保持する場合は、前の設定ファイル ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review/fileWithConflicts.conf`​ を ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts/ready`​ フォルダーに移動します。 変更内容を破棄すると、古い設定が新しい Mule ディストリビューションで使用される場合があります。 4. `${MULE_HOME}/upgrade-tool/mule-config-conflicts/to_review`​ フォルダー内の各設定ファイルに対してステップ 1 ～ 3 を繰り返します。 5. `upgrade`​ サブコマンドの実行を再試行します。 アップグレードが正常に完了すると、ツールは ​`${MULE_HOME}/upgrade-tool/mule-config-conflicts`​ フォルダーを削除し、将来のアップグレードに備えてクリーンな環境に戻します。 ### [](#無人のアップグレードまたは更新)無人のアップグレードまたは更新 対象環境でアップグレードを実行する前に、別の環境で競合を解決しておけば、アップグレードや更新を無人で実行できます。この手順は、別の環境で設定する​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションが、メイン環境の​_現在の_​ Mule ディストリビューションと​_新しい_​ Mule ディストリビューションのバージョンと一致する場合にのみ使用できます。 1. ユーザーインタラクションが可能な環境で、​[Mule 設定ファイルの競合を解決する手順](#steps-to-solve-conflicts)​の説明に従ってすべての競合を確認して解決します。 2. 対象環境で、​`${MULE_HOME_WITH_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ から ​`${MULE_HOME_WITHOUT_USER_INTERACTION}/upgrade-tool/mule-config-conflicts/ready/`​ にファイルをコピーします。 3. 対象環境で ​`upgrade`​ サブコマンドを実行します。 ## [](#mule-アップグレードツールのログの設定)Mule アップグレードツールのログの設定 デバッグのログを有効化することで、Mule アップグレードツールの各操作の詳細情報を追加したり、ツールがログを保存するフォルダーを変更したり、カスタマイズされたログ設定ファイルを使用したりできます。 ### [](#カスタム-log4j-ファイルの指定)カスタム Log4j ファイルの指定 デフォルトでは、Mule アップグレードツールは ​`$MULE_HOME/tools/upgrade-tool`​ フォルダーにある ​`log4j2-upgrade-tool.xml`​ ファイルを使用します。 カスタム Log4j ファイルを使用するには、​`-l`​ パラメーターを使用して、使用するカスタム Log4j 設定ファイルのファイル名を指定します。例: ```bash $MULE_HOME/tools/upgrade-tool -l myLog4j2File.xml upgrade ``` ### [](#デバッグレベルログの有効化)デバッグレベルログの有効化 デバッグログを有効化する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. Log4j ファイルの次の行で、​`level`​ プロパティの値を ​`INFO`​ から ​`DEBUG`​ に変更します。 ```xml ``` ### [](#ログ出力のカスタマイズ)ログ出力のカスタマイズ デフォルトでは、Mule アップグレードツールは ​`./mule-Runtime-upgrade-tool-logs`​ ディレクトリにログファイルを保存します。 ファイル名、出力パス、ログパターンを変更する手順は、次のとおりです。 1. ツールで使用する Log4j ファイルを開きます。 2. `fileName`​ プロパティと ​`filePattern`​ プロパティに希望する値を指定します。 ```xml ``` ## [](#mule-アップグレードツールのサブコマンドとオプション)Mule アップグレードツールのサブコマンドとオプション Mule アップグレードツールの実行時に使用できるサブコマンドとオプションを下表に示します。
サブコマンド 説明

upgrade

ローカル Mule インスタンスを、使用できる最新バージョンにアップグレードします。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-n <newMuleDistributionPath>​

ローカル Mule インスタンスを、ファイルシステムにダウンロードして展開してあるディストリビューションにアップグレードします。​<newMuleDistribution>​ パラメーターを使用して、新しい Mule ディストリビューションのパスを指定できます。例:
​$ ./upgrade-tool upgrade -n /<newMuleDistributionPath>​

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスをアップグレードします。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスをアップグレードできます。例:
​$ ./upgrade-tool upgrade -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、アップグレードプロセスをシミュレーションします。

-f​

バックアップの上書きや適用したパッチの削除といった破壊的な操作に対してユーザーの確認を要求せずにアップグレードを実行します。

-h​

このサブコマンドのヘルプメッセージを表示します。

rollback

Mule インスタンスを以前の状態に戻します。このサブコマンドは、ツールでアップグレードを正常に完了した後でのみ使用できます。
このサブコマンドでは次のオプションがサポートされています。

オプション 説明

-o <localMuleInstancePath>​

​<localMuleInstancePath>​ にあるローカル Mule インスタンスを復元します。このオプションを使用すると、アップグレードツールと同じ ​$MULE_HOME​ パスにある Mule インスタンスとは異なる Mule インスタンスを復元できます。例:
​$ ./upgrade-tool rollback -o /<localMuleInstancePath>​

-d​

現在の Mule インスタンスに永続的な変更を加えることなく、ロールバックプロセスをシミュレーションします。

-f​

ユーザーの確認を要求せずに Mule インスタンスを復元します。

-h​

このサブコマンドのヘルプメッセージを表示します。

status

現在の Mule インスタンスに関して、次のような情報を提供します。

  • Mule Runtime Engine バージョン

  • 現在の Mule インスタンスがアップグレードまたはロールバックの条件を満たしていることを確認するメッセージ

  • 既存のバックアップとその場所

  • バックアップが存在する場合はその整合性
## [](#一般的なエラーのトラブルシューティング)一般的なエラーのトラブルシューティング 以下に、アップグレードツールから返される最も一般的なエラーメッセージの一部と、それぞれの説明および解決策を示します。 ### [](#missing-required-subcommand-必要なサブコマンドがありません)Missing Required Subcommand (必要なサブコマンドがありません) ./upgrade-tool Mule Runtime Upgrade Tool ───────────────────────── Missing required subcommand Usage: upgrade-tool \[-hV\] \[COMMAND\] Try 'upgrade-tool --help' for more information. #### [](#原因)原因 このエラーは、未知の、または存在しないサブコマンドが指定されたことを示します。サポートされているサブコマンドは、​`upgrade`​、​`rollback`​、​`status`​ のみです。 #### [](#解決策)解決策 `upgrade-tool`​ コマンドと、サポートされているいずれかのサブコマンド (​`upgrade`​、​`rollback`​、または ​`status`​) を実行していることを確認します。 `-h`​ または ​`--help`​ オプションを使用すると、特定のサブコマンドの詳細情報を見ることができます。例: $ ./upgrade-tool rollback --help ### [](#missing-required-option-必須のオプションがありません)Missing Required Option (必須のオプションがありません) ./upgrade-tool upgrade Mule Runtime Upgrade Tool ───────────────────────── Missing required option: '--new-mule-distro=' Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Try 'upgrade-tool upgrade --help' for more information. #### [](#原因-2)原因 このエラーは、選択したサブコマンドに追加の引数が必要であることを示しています。たとえば、アップグレード時には引数 ​`--new-mule-distro`​ が必要です。 #### [](#解決策-2)解決策 次のコマンドを実行して、特定のサブコマンドで必要な引数に関する情報を確認します。 ./upgrade-tool upgrade --help このコマンドを実行すると、追加情報が次のように表示されます。 Mule Runtime Upgrade Tool ───────────────────────── Usage: upgrade-tool upgrade \[-dfh\] -n= \[-o=\] Upgrades a Mule Runtime to a newer version -d, --dry-run Simulate upgrade process without performing any permanent changes to the current Mule Runtime Distribution. -f, --force Perform all the destructive operations like overwriting the backup or removing the applied patches without user confirmation -h, --help Display this help message -n, --new-mule-distro= File path of the newer Mule Runtime distribution used for the upgrade -o, --old-mule-distro= File path of Mule Runtime distribution to upgrade `Usage:`​ 行では、省略可能なオプションと引数が角括弧 (​`[`,`]`​) 内に示されます。角括弧が付いていないオプションと引数は必須です。 ### [](#no-space-left-on-device-デバイスにスペースがありません)No Space Left on Device (デバイスにスペースがありません) $ ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 ERROR: There's not enough disk space for performing the upgrade. ERROR: No space left on device No space left on device #### [](#原因-3)原因 このエラーは、アップグレードを実行するのに必要な空きディスクスペースがないことを示します。 #### [](#解決策-3)解決策 アップグレードツールは、Mule インスタンスが動作しているファイルシステムに 2 GB 以上の空きスペースを必要とします。システムに十分なディスクスペースがあり、他の要件も満足されていることを確認してください。 Linux 環境では、​`df`​ コマンドで空きディスクスペースを確認できます。 $ df -h /opt Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-opt 419G 205G 193G 52% /opt ### [](#version-should-be-newer-新しいバージョンが必要です)Version Should Be Newer (新しいバージョンが必要です) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211104\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Version of new Mule distribution 4.4.0-20211104 should be newer than old Mule distribution: 4.4.0-20211104 #### [](#原因-4)原因 このエラーは、upgrade コマンドで、現在の Mule インスタンスと同じバージョンの新しい Mule ディストリビューションが指定された場合に発生します。 #### [](#解決策-4)解決策 ダウンロードした Mule ディストリビューションが現在の Mule インスタンスよりも新しいバージョンであることを確認してください。アップグレード中にこのエラーメッセージが連続して返される場合は、現在の Mule インスタンスがすでにアップグレード済みであるか、または最新のバージョンが実行中であることを意味します。 ### [](#missing-reading-permissions-参照権限がありません)Missing Reading Permissions (参照権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required reading permissions under Mule distribution \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] java.nio.file.AccessDeniedException: /tmp/mule-enterprise-standalone-4.4.0-20211104/lib/mule/mule-module-cache-ee-4.4.0-20211104.jar \[...\] #### [](#原因-5)原因 新しい Mule ディストリビューションで必要な参照権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルを参照できません。 #### [](#解決策-5)解決策 アップグレードツールによって参照不能として特定されているファイルの参照権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#missing-writing-permissions-書き込み権限がありません)Missing Writing Permissions (書き込み権限がありません) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Error validating required writing permissions under Mule distribution \[/opt/mule-enterprise-standalone-4.4.0-20211026\] java.nio.file.AccessDeniedException: /opt/mule-enterprise-standalone-4.4.0-20211026/lib/boot/libwrapper-linux-ppcle-64.so \[...\] #### [](#原因-6)原因 古い Mule ディストリビューションで必要な書き込み権限がアップグレードを実行しているユーザーに付与されていないため、スタックトレースで参照されているファイルに書き込めません。 #### [](#解決策-6)解決策 アップグレードツールによって特定されたファイルへの書き込み権限を取得してください。必要に応じて、システム管理者にお問い合わせください。 ### [](#mule-runtime-should-be-stopped-mule-runtime-を停止する必要があります)Mule Runtime Should Be Stopped (Mule Runtime を停止する必要があります) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule-enterprise-standalone-4.4.0-20211026\] with version: \[4.4.0-20211026\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211104\] with version \[4.4.0-20211104\] ... ERROR: Mule Runtime should be stopped. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-7)原因 Mule が実行中であることをアップグレードツールが検出しました。 #### [](#解決策-7)解決策 アップグレードプロセスを開始する前に Mule を停止してください。現在の状況を確認するには ​`${MULE_HOME}/bin/mule status`​ コマンドを使用します。 ### [](#mule-version-isnt-supported-for-an-upgrade-アップグレードでサポートされていない-mule-バージョンです)Mule Version Isn’t Supported for an Upgrade (アップグレードでサポートされていない Mule バージョンです) ./upgrade-tool upgrade -n /tmp/mule-enterprise-standalone-4.4.0-20211104 Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/tmp/mule-enterprise-standalone-4.1.1-20211222\] with version: \[4.1.1\] to distribution at path \[/tmp/mule-enterprise-standalone-4.4.0-20211026\] with version \[4.4.0-20211026\] ... ERROR: Your Mule version cannot be upgraded to the new one, you need to upgrade to a version greater than 4.1.5, or for versions between 4.1.1 to 4.1.4, then packages released after January 20, 2022. ERROR: Not all preconditions are met to perform the upgrade. Review the log for details. Not all preconditions are met to perform the upgrade. Review the log for details. #### [](#原因-8)原因 Mule アップグレードツールでは、現在の Mule インスタンスと新しい Mule インスタンス (​`/new-${MULE_HOME_NEW_FOLDER_NAME}`​) の両方がバージョン 4.1.5 以降である必要があります。 #### [](#解決策-8)解決策 Mule アップグレードツールを使用してアップグレードを実行する前に、現在の Mule インスタンスと新しい Mule インスタンスの両方をバージョン 4.1.5 以降に手動でアップグレードしてください。 ## [](#upgrade_clustered_mule_instances)クラスタリングされた Mule アプリケーションのアップグレード クラスタリングされた Mule インスタンスをアップグレードするには、Mule アップグレードツールを使用して各ノードを手動でアップグレードすることにより、ローカル Mule インスタンスのアップグレードプロセスを自動化します。 ### [](#始める前に-2)始める前に アップグレードを始める前に、次の準備が整っていることを確認します。 - 新しい Mule Runtime ディストリビューション (対象バージョン) と、アップグレードする各ノードにコピーされた Mule アップグレードツール (ダウンタイムを短縮するため)。 - 最新の修正とセキュリティ機能強化を備えたツールが実行されるように、​[最新バージョンの Mule アップグレードツール](https://docs.mulesoft.com/jp/release-notes/mule-upgrade-tool/mule-upgrade-tool)​をご使用ください。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule アップグレードツールをダウンロードしてください。 - 現在運用中の Mule 4 インスタンスはアップグレードに備えて​_停止_​状況にあります。 Mule アップグレードツールを使用して Mule バージョン 4.1.1 ～ 4.1.4 のアップグレードを行う場合は、2022 年 1 月 20 日以降にリリースされたパッチ更新からアップグレードを行う必要があります。2022 年 1 月 20 日より​_前_​のバージョン 4.1.1 ～ 4.1.4 のリリースは現在のところツールでサポートされておらず、アップグレードしようとすると、最初にサポートされるバージョンにアップグレードしてからでないと Mule バージョンをアップグレードできない旨のエラーメッセージが表示されます ([Mule Upgrades and Patch Updates](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) を参照)。 - 最新の Mule Runtime Engine ディストリビューションをシステムにダウンロードして展開してある。 Mule アップグレードツールには、Mule Runtime のフルディストリビューションが必要です。必ずファイル名に (​`patch`​ ではなく) ​`distribution`​ という単語が含まれているフル Mule Runtime ディストリビューションをダウンロードしてください。たとえば、Mule 4.4.0 の 20220221 ディストリビューションであれば、ファイル名は ​`mule-ee-distribution-standalone-4.4.0-20220221.zip`​ となります。 [ヘルプセンター](https://help.mulesoft.com/s/)​から Mule Runtime ディストリビューションをダウンロードしてください。 - ファイルシステムに 2 GB 以上の空きディスクスペースと、Mule ディストリビューションをインストールするためのアクセス権限がある。 - (Windows 環境の場合) PowerShell スクリプトの実行ポリシーが ​**\[Unrestricted\]**​ に設定されている。 - Anypoint Monitoring エージェントがインストールされている場合は、アップグレードの前にアンインストールする。 ### [](#mule-のアップグレードまたは更新-2)Mule のアップグレードまたは更新
パラメーター ​<newMuleDistributionAbsolutePath>​ は、アップグレードプロセスで新しい Mule Runtime ディストリビューションが展開される一時的な場所を参照します。アップグレードが正常に完了すれば、この場所はアップグレードツールで不要になるため、安全に削除できます。
クラスタリングされた Mule インスタンスを最新バージョンにアップグレードまたは更新する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. 最新の Mule Runtime ディストリビューションをダウンロードして展開してあるディレクトリの絶対パスを引数として指定し、​`upgrade -n`​ サブコマンドを実行します。例: ```bash $MULE_HOME/tools/upgrade-tool upgrade -n ``` このスクリプトの出力は次のようになります。 ➜ tools ./upgrade-tool upgrade -n /Users/me/mule-download/upgrade/mule-enterprise-standalone-4.5.0/ Mule Runtime Upgrade Tool ───────────────────────── INFO: Initiating upgrade process... INFO: Upgrading distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20221212\] with version: \[4.4.0-20221212\] to distribution at path \[/opt/mule/mule-enterprise-standalone-4.4.0-20230217\] with version \[4.4.0-20230217\] ... Do you want to proceed with the upgrade? To confirm please, enter \[yes, no\] (default: no): yes WARN: Unknown file tools/mule-runtime-upgrade-tool-logs/mule-runtime-upgrade-tool-logs.log was found in the runtime installation, and will be kept. WARN: A version in your MULE\_HOME directory name was detected: /opt/mule/mule-enterprise-standalone-4.4.0-20221212, beware it may not match the current installed version inside the directory. INFO: Upgrade process finished successfully. Verifying Mule Agent ──────────────────── INFO: Mule Agent not installed, skipping setup これで、既存の Mule インスタンスがアップグレードされたため、アップグレードツールで必要でなくなった最近ダウンロードしたバージョン (例では ​``​ として参照) を削除できます。 すべてのノードを同じ Mule Runtime バージョンにアップグレードまたは更新しないと正常に動作しませんのでご注意ください。 ### [](#アップグレードまたは更新のロールバック-2)アップグレードまたは更新のロールバック Mule アップグレードツールは、アップグレードまたは更新プロセスを開始する前にアップグレードまたは更新するクラスタリングされた Mule インスタンスのバックアップを作成するため、クラスタリングされた Mule インスタンスをアップグレードまたは更新した後で、以前の状態に復元できます。バックアップは ​`$MULE_HOME/.upgrade-tool-backup`​ フォルダーに保存されます。 ロールバックを実行する手順は、次のとおりです。 1. Mule アップグレードツールをダウンロードしてある ​`$MULE_HOME/tools`​ ディレクトリに移動します。 2. `rollback`​ サブコマンドを次のように実行します。 ```bash $MULE_HOME/tools/upgrade-tool rollback ``` すべてのノードを同じ Mule Runtime バージョンにロールバックしないと正常に動作しませんのでご注意ください。 ## [](#関連情報)関連情報 - [Mule Upgrades and Patch Updates (Mule のアップグレードとパッチの更新)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/upgrade-update-mule) # Mule アプリケーションでのストリーミング Mule 4 では、データストリームを処理するためのフレームワークが追加されています。Mule 4 での変更点を理解するためには、従来はデータストリームがどのようにコンシュームされていたかを理解することが必要です。 - データストリームは 1 回しかコンシュームできません。 次の例は、ファイルに書き込む本文 (ペイロード) を持つ POST メソッドを受け取る HTTP Listener ソースのフローを示しています。このフローにより、最初のファイルは正しく書き込まれますが、2 つ目のファイルはコンテンツが空になります。これは、ストリームをコンシュームする各コンポーネントが、新しいストリームを受信することを予期しているためです。最初の File Write 操作がストリームをコンシュームすると、2 つ目の File Write 操作は空のストリームを受け取ります。そのため、2 つ目の操作はファイルに書き込むコンテンツを持ちません。 ![mruntime streaming about 1](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-streaming-about-1.png) Figure 1. Mule 3 のストリーミング: ファイルの書き込み 次の例は、DataWeave 変換の後でペイロードをログに記録しようとすると、同じような結果となります。HTTP Listener 操作は、ペイロードストリームを受け取り、ストリームが Transform Message コンポーネントに達した時点ではまだメモリに残っているため、コンポーネントはストリームをコンシュームします。Transform Message コンポーネントでコンテンツをコンシュームした後で、2 つ目の Logger は空のストリームを受信します。 ![mruntime streaming about 2](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-streaming-about-2.png) Figure 2. Mule 3 のストリーミング: ペイロードのログへの記録 - データストリームを同時にコンシュームすることはできません。 次の例は、Scatter-Gather ルーターを使用してデータストリームを分割し、ペイロードのログへの記録とファイルへの書き込みを同時に実行するフローを示しています。異なるプロセッサーチェーンでデータストリームのコンテンツを同時に処理することはできないため、アプリケーションはストリームの一部をファイルで受け取り、残りをログで受け取ります。 ![mruntime streaming about 3](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-streaming-about-3.png) Figure 3. Mule 3 のストリーミング: データストリームのコンシューム ## [](#反復可能ストリーム)反復可能ストリーム Mule 4 では、ストリームを処理するためのデフォルトフレームワークとして反復可能ストリームが追加されています。反復可能ストリームを使用すると、次の操作を実行できます。 - ストリームを複数回読み込むことができます。 - ストリームに同時にアクセスできます。 コンポーネントがストリームをコンシュームすると、Mule はそのコンテンツを一時バッファに格納します。以後、ランタイムはストリームのコンテンツをテンポラリーバッファからコンポーネントに供給することで、すでにストリームが他のコンポーネントによって何度コンシュームされていようとも、各コンポーネントが完全なストリームを受信できるようにします。この処理は自動的に行われるため、ユーザーが特別な設定をする必要はなく、再びアクセスするためにストリームを別の場所に保存するための回避策を考える必要はありません。この設定により、上記の 3 つの Mule アプリケーションの例の問題のうち、2 つが自動的に解決されます。 すべての反復可能ストリームは並列アクセスをサポートしています。つまり、各コンポーネントが異なるスレッドで実行されているときに、2 つのコンポーネントが同じストリームを読み取ろうとしても心配する要はありません。Mule は、コンポーネント ​`A`​ がストリームを読み込んでもコンポーネント ​`B`​ に対して一切の副作用を発生させないことを自動的に保証します。この動作により、​[3 番目の例](#example_3)​で説明しているようなタスクを実行できます。 ## [](#ストリーミング戦略)ストリーミング戦略 ストリーミング戦略を使用して、Mule によるストリームの処理方法を設定できます。 ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルストレージは Mule 4 のデフォルトのストリーミング戦略です。

ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
この戦略では、初期設定として、メモリ内のバッファサイズとして 512 KB を使用します。ストリームが大きくなると、この戦略で一時ファイルがディスクに作成され、メモリをオーバーフローさせることなく、コンテンツを格納します。 大きいまたは小さいファイルを処理する必要がある場合、バッファサイズ (​`inMemorySize`​) を変更してパフォーマンスを最適化できます。 - バッファサイズを大きく設定すると、ランタイムがバッファをディスクに書き込む回数を減らすことができるため、パフォーマンスが向上します。ただし、アプリケーションが同時に処理できる要求の数が制限されます。 - バッファサイズを小さく設定すると、メモリの負荷が減ります。 また、バッファの測定の単位も設定できます (​`bufferUnit`​)。 たとえば、常に約 1 MB のファイルを読み取ることが分かっているのであれば、1 MB のバッファを設定できます。 ```xml ``` あるいは、処理するファイルのサイズが 10 KB を超えることがないということが分かっていれば、メモリを節約できます。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズ設定が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。 ただし、ニーズに合った適切なバッファサイズの設定を見つけるには、テストを実行する必要があります。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内戦略は、Mule Kernel (以前の名称は Mule Runtime Community Edition) のデフォルト設定です。 この戦略のデフォルトのバッファサイズは 512 KB です。大きいストリームでは、設定した最大バッファサイズに達するまで、デフォルトの拡張単位である 512 KB ずつバッファが拡張されます。ストリームが最大バッファサイズを超えると、アプリケーションはエラーとなります。 この動作は、初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、最大バッファサイズ (​`maxInMemorySize`​)、バッファサイズ値の測定単位 (​`bufferUnit`​) を設定することでカスタマイズできます。 たとえば、次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズと 512 KB の拡張単位が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。ただし、テストを実行してニーズに合った適切なバッファサイズとサイズの拡張単位の設定を見つける必要があります。 `InputStream`​ または ​`Streamable`​ コレクションを返す Mule 4 のすべてのコンポーネントで、反復可能ストリームがサポートされています。これらのコンポーネントには以下が含まれています。 - File Connector - FTP Connector - Database Connector - HTTP Connector - Sockets Connector - SalesForce Connector ## [](#オブジェクトのストリーミング)オブジェクトのストリーミング Anypoint Connector が自動ページングを使用するように設定されている場合、Mule 4 によって、反復可能自動ページングフレームワークを使用してページングされたコネクタ出力が自動的に処理されます。コネクタがオブジェクトを受信し、Mule がオブジェクトを保存するために設定可能なメモリ内バッファを設定するため、このフレームワークは反復可能ストリームと似ています。ただし、反復可能ストリームはバッファサイズをバイト単位で測定するのに対して、ランタイムはオブジェクトを処理するときにインスタンス数を使用してバッファサイズを測定します。
オブジェクトをストリーミングすると、メモリ内のバッファサイズはインスタンス数で測定されます。
反復可能自動ページングのメモリ内のバッファサイズを計算する場合は、メモリ不足にならないように、各インスタンスで使用するメモリ量を見積もる必要があります。 反復可能ストリームと同じように、さまざまな戦略を使用して、Mule による反復可能自動ページングの処理方法を設定できます。 ### [](#反復可能ファイルストア-イテラブル)反復可能ファイルストア (イテラブル) この設定は、Mule Enterprise Edition のデフォルトです。この戦略では、デフォルトの設定済みメモリ内バッファとして 500 個のオブジェクトを使用します。このバッファサイズよりも多くの結果がクエリで返されると、Mule はオブジェクトをシリアル化して、ディスクに書き込みます。メモリ内のバッファに格納されるオブジェクト数は設定可能です。メモリ内に保存するオブジェクトの数が多いほど、ディスクへの書き込みが減るため、パフォーマンスが向上します。 たとえば、次のように、SalesForce Connector のクエリに対してメモリ内のバッファサイズを 100 個のオブジェクトに設定できます。 反復可能ファイルストア (イテラブル): ```xml ``` MuleSoft ではシリアル化に Kryo フレームワークを使用します。これは、標準の Java シリアル化では、​`Serializable`​ インターフェースを実装するためにシリアル化されたオブジェクト (およびそのすべての参照されるオブジェクト) が必要になるためです。Kryo シリアライザーにはこの制限がないため、標準の Java のシリアル化ではシリアル化できない一部のオブジェクトをシリアル化できます。ただし、Kryo ですべてをシリアル化できるわけではありません。たとえば、​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl`​ のインスタンスは Kryo を使用してもシリアル化できません。MuleSoft では、オブジェクトを単純にすることをお勧めします。

このオプションは Mule EE でのみ使用できます。
### [](#反復可能メモリ内-イテラブル)反復可能メモリ内 (イテラブル) この設定は Mule Kernel のデフォルトであり、デフォルトのバッファサイズを 500 個のオブジェクトに設定します。クエリ結果がこのサイズを超えると、設定された最大バッファサイズに到達するまで、デフォルトの拡張単位である 100 個ずつバッファが拡張されます。ストリームがこの制限を超えると、アプリケーションは失敗します。 初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、そして最大バッファサイズ (​`maxBufferSize`​) をカスタマイズできます。 たとえば、次の設定ではメモリ内のバッファサイズを 100 個のオブジェクト、拡張単位を 100 個のオブジェクト、最大バッファサイズを 500 個のオブジェクトに設定します。 反復可能メモリ内 (イテラブル): ```xml ``` ## [](#disable_repeatable_streaming)反復可能ストリームの無効化 反復可能ストリームは、​`non-repeatable-stream`​ 戦略と ​`non-repeatable-iterable`​ 戦略で無効化できます。使用する戦略は、ストリームの種別によって決まります。 このオプションは、ストリームを複数回コンシュームする必要がないことが確実であり、パフォーマンスとリソース消費を非常に厳密に最適化する必要がある場合にのみ使用してください。 その場合には、次の点に注意してください。 - 反復可能ストリームを無効化するとパフォーマンスは向上しますが、向上する程度はストリームのサイズに比例します。大きなストリームを使用していない限り、アプリケーションの他の部分を調整した方がパフォーマンスはより大きく向上します。 - 反復可能ストリームを無効化すると、ストリームは 1 回しか読み取ることができなくなります。フローには、明示的にそのように指定していなくても、ストリーム全体をコンシュームする必要のあるコンポーネントが存在する可能性があります。たとえば、Cache コンポーネント (​``​)、Transform Message コンポーネント (​``​) による一部の変換、For Each コンポーネント (​``​) による JSON 配列の反復処理、そしてストリームに直接、または式を通してアクセスする他のコンポーネントなどです。 ## [](#関連情報)関連情報 - [ストリーミング戦略リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/streaming-strategies-reference) # Mule アプリケーションでのストリーミング Mule 4 では、データストリームを処理するためのフレームワークが追加されています。Mule 4 での変更点を理解するためには、従来はデータストリームがどのようにコンシュームされていたかを理解することが必要です。 - データストリームは 1 回しかコンシュームできません。 次の例は、ファイルに書き込む本文 (ペイロード) を持つ POST メソッドを受け取る HTTP Listener ソースのフローを示しています。このフローにより、最初のファイルは正しく書き込まれますが、2 つ目のファイルはコンテンツが空になります。これは、ストリームをコンシュームする各コンポーネントが、新しいストリームを受信することを予期しているためです。最初の File Write 操作がストリームをコンシュームすると、2 つ目の File Write 操作は空のストリームを受け取ります。そのため、2 つ目の操作はファイルに書き込むコンテンツを持ちません。 ![mruntime streaming about 1](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-streaming-about-1.png) Figure 1. Mule 3 のストリーミング: ファイルの書き込み 次の例は、DataWeave 変換の後でペイロードをログに記録しようとすると、同じような結果となります。HTTP Listener 操作は、ペイロードストリームを受け取り、ストリームが Transform Message コンポーネントに達した時点ではまだメモリに残っているため、コンポーネントはストリームをコンシュームします。Transform Message コンポーネントでコンテンツをコンシュームした後で、2 つ目の Logger は空のストリームを受信します。 ![mruntime streaming about 2](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-streaming-about-2.png) Figure 2. Mule 3 のストリーミング: ペイロードのログへの記録 - データストリームを同時にコンシュームすることはできません。 次の例は、Scatter-Gather ルーターを使用してデータストリームを分割し、ペイロードのログへの記録とファイルへの書き込みを同時に実行するフローを示しています。異なるプロセッサーチェーンでデータストリームのコンテンツを同時に処理することはできないため、アプリケーションはストリームの一部をファイルで受け取り、残りをログで受け取ります。 ![mruntime streaming about 3](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-streaming-about-3.png) Figure 3. Mule 3 のストリーミング: データストリームのコンシューム ## [](#反復可能ストリーム)反復可能ストリーム Mule 4 では、ストリームを処理するためのデフォルトフレームワークとして反復可能ストリームが追加されています。反復可能ストリームを使用すると、次の操作を実行できます。 - ストリームを複数回読み込むことができます。 - ストリームに同時にアクセスできます。 コンポーネントがストリームをコンシュームすると、Mule はそのコンテンツを一時バッファに格納します。以後、ランタイムはストリームのコンテンツをテンポラリーバッファからコンポーネントに供給することで、すでにストリームが他のコンポーネントによって何度コンシュームされていようとも、各コンポーネントが完全なストリームを受信できるようにします。この処理は自動的に行われるため、ユーザーが特別な設定をする必要はなく、再びアクセスするためにストリームを別の場所に保存するための回避策を考える必要はありません。この設定により、上記の 3 つの Mule アプリケーションの例の問題のうち、2 つが自動的に解決されます。 すべての反復可能ストリームは並列アクセスをサポートしています。つまり、各コンポーネントが異なるスレッドで実行されているときに、2 つのコンポーネントが同じストリームを読み取ろうとしても心配する要はありません。Mule は、コンポーネント ​`A`​ がストリームを読み込んでもコンポーネント ​`B`​ に対して一切の副作用を発生させないことを自動的に保証します。 この動作により、​[3 番目の例](#example_3)​で説明しているようなタスクを実行できます。 ## [](#ストリーミング戦略)ストリーミング戦略 ストリーミング戦略を使用して、Mule によるストリームの処理方法を設定できます。 ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルストレージは Mule 4 のデフォルトのストリーミング戦略です。

ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
この戦略では、初期設定として、メモリ内のバッファサイズとして 512 KB を使用します。ストリームが大きくなると、この戦略で一時ファイルがディスクに作成され、メモリをオーバーフローさせることなく、コンテンツを格納します。 大きいまたは小さいファイルを処理する必要がある場合、バッファサイズ (​`inMemorySize`​) を変更してパフォーマンスを最適化できます。 - バッファサイズを大きく設定すると、ランタイムがバッファをディスクに書き込む回数を減らすことができるため、パフォーマンスが向上します。ただし、アプリケーションが同時に処理できる要求の数が制限されます。 - バッファサイズを小さく設定すると、メモリの負荷が減ります。 また、バッファの測定の単位も設定できます (​`bufferUnit`​)。 たとえば、常に約 1 MB のファイルを読み取ることが分かっているのであれば、1 MB のバッファを設定できます。 ```xml ``` あるいは、処理するファイルのサイズが 10 KB を超えることがないということが分かっていれば、メモリを節約できます。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズ設定が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。 ただし、ニーズに合った適切なバッファサイズの設定を見つけるには、テストを実行する必要があります。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内戦略は、Mule Kernel (以前の名称は Mule Runtime Community Edition) のデフォルト設定です。 この戦略のデフォルトのバッファサイズは 512 KB です。大きいストリームでは、設定した最大バッファサイズに達するまで、デフォルトの拡張単位である 512 KB ずつバッファが拡張されます。ストリームが最大バッファサイズを超えると、アプリケーションはエラーとなります。 この動作は、初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、最大バッファサイズ (​`maxInMemorySize`​)、バッファサイズ値の測定単位 (​`bufferUnit`​) を設定することでカスタマイズできます。 たとえば、次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズと 512 KB の拡張単位が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。ただし、テストを実行してニーズに合った適切なバッファサイズとサイズの拡張単位の設定を見つける必要があります。 `InputStream`​ または ​`Streamable`​ コレクションを返す Mule 4 のすべてのコンポーネントで、反復可能ストリームがサポートされています。これらのコンポーネントには以下が含まれています。 - File Connector - FTP Connector - Database Connector - HTTP Connector - Sockets Connector - SalesForce Connector ## [](#オブジェクトのストリーミング)オブジェクトのストリーミング Anypoint Connector が自動ページングを使用するように設定されている場合、Mule 4 によって、反復可能自動ページングフレームワークを使用してページングされたコネクタ出力が自動的に処理されます。コネクタがオブジェクトを受信し、Mule がオブジェクトを保存するために設定可能なメモリ内バッファを設定するため、このフレームワークは反復可能ストリームと似ています。ただし、反復可能ストリームはバッファサイズをバイト単位で測定するのに対して、ランタイムはオブジェクトを処理するときにインスタンス数を使用してバッファサイズを測定します。
オブジェクトをストリーミングすると、メモリ内のバッファサイズはインスタンス数で測定されます。
反復可能自動ページングのメモリ内のバッファサイズを計算する場合は、メモリ不足にならないように、各インスタンスで使用するメモリ量を見積もる必要があります。 反復可能ストリームと同じように、さまざまな戦略を使用して、Mule による反復可能自動ページングの処理方法を設定できます。 ### [](#反復可能ファイルストア-イテラブル)反復可能ファイルストア (イテラブル) この設定は、Mule Enterprise Edition のデフォルトです。この戦略では、デフォルトの設定済みメモリ内バッファとして 500 個のオブジェクトを使用します。このバッファサイズよりも多くの結果がクエリで返されると、Mule はオブジェクトをシリアル化して、ディスクに書き込みます。メモリ内のバッファに格納されるオブジェクト数は設定可能です。メモリ内に保存するオブジェクトの数が多いほど、ディスクへの書き込みが減るため、パフォーマンスが向上します。 たとえば、次のように、SalesForce Connector のクエリに対してメモリ内のバッファサイズを 100 個のオブジェクトに設定できます。 反復可能ファイルストア (イテラブル): ```xml ``` MuleSoft ではシリアル化に Kryo フレームワークを使用します。これは、標準の Java シリアル化では、​`Serializable`​ インターフェースを実装するためにシリアル化されたオブジェクト (およびそのすべての参照されるオブジェクト) が必要になるためです。Kryo シリアライザーにはこの制限がないため、標準の Java のシリアル化ではシリアル化できない一部のオブジェクトをシリアル化できます。ただし、Kryo ですべてをシリアル化できるわけではありません。たとえば、​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl`​ のインスタンスは Kryo を使用してもシリアル化できません。MuleSoft では、オブジェクトを単純にすることをお勧めします。

このオプションは Mule EE でのみ使用できます。
### [](#反復可能メモリ内-イテラブル)反復可能メモリ内 (イテラブル) この設定は Mule Kernel のデフォルトであり、デフォルトのバッファサイズを 500 個のオブジェクトに設定します。クエリ結果がこのサイズを超えると、設定された最大バッファサイズに到達するまで、デフォルトの拡張単位である 100 個ずつバッファが拡張されます。ストリームがこの制限を超えると、アプリケーションは失敗します。 初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、そして最大バッファサイズ (​`maxBufferSize`​) をカスタマイズできます。 たとえば、次の設定ではメモリ内のバッファサイズを 100 個のオブジェクト、拡張単位を 100 個のオブジェクト、最大バッファサイズを 500 個のオブジェクトに設定します。 反復可能メモリ内 (イテラブル): ```xml ``` ## [](#disable_repeatable_streaming)反復可能ストリームの無効化 反復可能ストリームは、​`non-repeatable-stream`​ 戦略と ​`non-repeatable-iterable`​ 戦略で無効化できます。使用する戦略は、ストリームの種別によって決まります。 このオプションは、ストリームを複数回コンシュームする必要がないことが確実であり、パフォーマンスとリソース消費を非常に厳密に最適化する必要がある場合にのみ使用してください。 その場合には、次の点に注意してください。 - 反復可能ストリームを無効化するとパフォーマンスは向上しますが、向上する程度はストリームのサイズに比例します。大きなストリームを使用していない限り、アプリケーションの他の部分を調整した方がパフォーマンスはより大きく向上します。 - 反復可能ストリームを無効化すると、ストリームは 1 回しか読み取ることができなくなります。フローには、明示的にそのように指定していなくても、ストリーム全体をコンシュームする必要のあるコンポーネントが存在する可能性があります。たとえば、Cache コンポーネント (​``​)、Transform Message コンポーネント (​``​) による一部の変換、For Each コンポーネント (​``​) による JSON 配列の反復処理、そしてストリームに直接、または式を通してアクセスする他のコンポーネントなどです。 ## [](#関連情報)関連情報 - [ストリーミング戦略リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/streaming-strategies-reference) # Mule アプリケーションでのストリーミング Mule 4 では、データストリームを処理するためのフレームワークが追加されています。Mule 4 での変更点を理解するためには、従来はデータストリームがどのようにコンシュームされていたかを理解することが必要です。 - データストリームは 1 回しかコンシュームできません。 次の例は、ファイルに書き込む本文 (ペイロード) を持つ POST メソッドを受け取る HTTP Listener ソースのフローを示しています。このフローにより、最初のファイルは正しく書き込まれますが、2 つ目のファイルはコンテンツが空になります。これは、ストリームをコンシュームする各コンポーネントが、新しいストリームを受信することを予期しているためです。最初の File Write 操作がストリームをコンシュームすると、2 つ目の File Write 操作は空のストリームを受け取ります。そのため、2 つ目の操作はファイルに書き込むコンテンツを持ちません。 ![mruntime streaming about 1](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-streaming-about-1.png) Figure 1. Mule 3 のストリーミング: ファイルの書き込み 次の例は、DataWeave 変換の後でペイロードをログに記録しようとすると、同じような結果となります。HTTP Listener 操作は、ペイロードストリームを受け取り、ストリームが Transform Message コンポーネントに達した時点ではまだメモリに残っているため、コンポーネントはストリームをコンシュームします。Transform Message コンポーネントでコンテンツをコンシュームした後で、2 つ目の Logger は空のストリームを受信します。 ![mruntime streaming about 2](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-streaming-about-2.png) Figure 2. Mule 3 のストリーミング: ペイロードのログへの記録 - データストリームを同時にコンシュームすることはできません。 次の例は、Scatter-Gather ルーターを使用してデータストリームを分割し、ペイロードのログへの記録とファイルへの書き込みを同時に実行するフローを示しています。異なるプロセッサーチェーンでデータストリームのコンテンツを同時に処理することはできないため、アプリケーションはストリームの一部をファイルで受け取り、残りをログで受け取ります。 ![mruntime streaming about 3](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-streaming-about-3.png) Figure 3. Mule 3 のストリーミング: データストリームのコンシューム ## [](#反復可能ストリーム)反復可能ストリーム Mule 4 では、ストリームを処理するためのデフォルトフレームワークとして反復可能ストリームが追加されています。反復可能ストリームを使用すると、次の操作を実行できます。 - ストリームを複数回読み込むことができます。 - ストリームに同時にアクセスできます。 コンポーネントがストリームをコンシュームすると、Mule はそのコンテンツを一時バッファに格納します。以後、ランタイムはストリームのコンテンツをテンポラリーバッファからコンポーネントに供給することで、すでにストリームが他のコンポーネントによって何度コンシュームされていようとも、各コンポーネントが完全なストリームを受信できるようにします。この処理は自動的に行われるため、ユーザーが特別な設定をする必要はなく、再びアクセスするためにストリームを別の場所に保存するための回避策を考える必要はありません。この設定により、上記の 3 つの Mule アプリケーションの例の問題のうち、2 つが自動的に解決されます。 すべての反復可能ストリームは並列アクセスをサポートしています。つまり、各コンポーネントが異なるスレッドで実行されているときに、2 つのコンポーネントが同じストリームを読み取ろうとしても心配する要はありません。Mule により、コンポーネント ​`A`​ がストリームを読み取ってもコンポーネント ​`B`​ に対して一切の副作用を発生させないことが自動的に確認されます。 この動作により、​[3 番目の例](#example_3)​で説明しているようなタスクを実行できます。 ## [](#ストリーミング戦略)ストリーミング戦略 ストリーミング戦略を使用して、Mule によるストリームの処理方法を設定できます。 ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルストレージは Mule 4 のデフォルトのストリーミング戦略です。

ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
この戦略では、初期設定として、メモリ内のバッファサイズとして 512 KB を使用します。ストリームが大きくなると、この戦略で一時ファイルがディスクに作成され、メモリをオーバーフローさせることなく、コンテンツを格納します。 大きいまたは小さいファイルを処理する必要がある場合、バッファサイズ (​`inMemorySize`​) を変更してパフォーマンスを最適化できます。 - バッファサイズを大きく設定すると、ランタイムがバッファをディスクに書き込む回数を減らすことができるため、パフォーマンスが向上します。ただし、アプリケーションが同時に処理できる要求の数が制限されます。 - バッファサイズを小さく設定すると、メモリの負荷が減ります。 また、バッファの測定の単位も設定できます (​`bufferUnit`​)。 たとえば、常に約 1 MB のファイルを読み取ることが分かっているのであれば、1 MB のバッファを設定できます。 ```xml ``` あるいは、処理するファイルのサイズが 10 KB を超えることがないということが分かっていれば、メモリを節約できます。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズ設定が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。 ただし、ニーズに合った適切なバッファサイズの設定を見つけるには、テストを実行する必要があります。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内戦略は、Mule Kernel (以前の名称は Mule Runtime Community Edition) のデフォルト設定です。 この戦略のデフォルトのバッファサイズは 512 KB です。大きいストリームでは、設定した最大バッファサイズに達するまで、デフォルトの拡張単位である 512 KB ずつバッファが拡張されます。ストリームが最大バッファサイズを超えると、アプリケーションはエラーとなります。 この動作は、初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、最大バッファサイズ (​`maxInMemorySize`​)、バッファサイズ値の測定単位 (​`bufferUnit`​) を設定することでカスタマイズできます。 たとえば、次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズと 512 KB の拡張単位が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。ただし、テストを実行してニーズに合った適切なバッファサイズとサイズの拡張単位の設定を見つける必要があります。 `InputStream`​ または ​`Streamable`​ コレクションを返す Mule 4 のすべてのコンポーネントで、反復可能ストリームがサポートされています。これらのコンポーネントには以下が含まれています。 - File Connector - FTP Connector - Database Connector - HTTP Connector - Sockets Connector - SalesForce Connector ## [](#オブジェクトのストリーミング)オブジェクトのストリーミング Anypoint Connector が自動ページングを使用するように設定されている場合、Mule 4 によって、反復可能自動ページングフレームワークを使用してページングされたコネクタ出力が自動的に処理されます。コネクタがオブジェクトを受信し、Mule がオブジェクトを保存するために設定可能なメモリ内バッファを設定するため、このフレームワークは反復可能ストリームと似ています。ただし、反復可能ストリームはバッファサイズをバイト単位で測定するのに対して、ランタイムはオブジェクトを処理するときにインスタンス数を使用してバッファサイズを測定します。
オブジェクトをストリーミングすると、メモリ内のバッファサイズはインスタンス数で測定されます。
反復可能自動ページングのメモリ内のバッファサイズを計算する場合は、メモリ不足にならないように、各インスタンスで使用するメモリ量を見積もる必要があります。 反復可能ストリームと同じように、さまざまな戦略を使用して、Mule による反復可能自動ページングの処理方法を設定できます。 ### [](#反復可能ファイルストア-イテラブル)反復可能ファイルストア (イテラブル) この設定は、Mule Enterprise Edition のデフォルトです。この戦略では、デフォルトの設定済みメモリ内バッファとして 500 個のオブジェクトを使用します。このバッファサイズよりも多くの結果がクエリで返されると、Mule はオブジェクトをシリアル化して、ディスクに書き込みます。メモリ内のバッファに格納されるオブジェクト数は設定可能です。メモリ内に保存するオブジェクトの数が多いほど、ディスクへの書き込みが減るため、パフォーマンスが向上します。 たとえば、次のように、SalesForce Connector のクエリに対してメモリ内のバッファサイズを 100 個のオブジェクトに設定できます。 反復可能ファイルストア (イテラブル): ```xml ``` MuleSoft ではシリアル化に Kryo フレームワークを使用します。これは、標準の Java シリアル化では、​`Serializable`​ インターフェースを実装するためにシリアル化されたオブジェクト (およびそのすべての参照されるオブジェクト) が必要になるためです。Kryo シリアライザーにはこの制限がないため、標準の Java のシリアル化ではシリアル化できない一部のオブジェクトをシリアル化できます。ただし、Kryo ですべてをシリアル化できるわけではありません。たとえば、​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl`​ のインスタンスは Kryo を使用してもシリアル化できません。MuleSoft では、オブジェクトを単純にすることをお勧めします。

このオプションは Mule EE でのみ使用できます。
### [](#反復可能メモリ内-イテラブル)反復可能メモリ内 (イテラブル) この設定は Mule Kernel のデフォルトであり、デフォルトのバッファサイズを 500 個のオブジェクトに設定します。クエリ結果がこのサイズを超えると、設定された最大バッファサイズに到達するまで、デフォルトの拡張単位である 100 個ずつバッファが拡張されます。ストリームがこの制限を超えると、アプリケーションは失敗します。 初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、そして最大バッファサイズ (​`maxBufferSize`​) をカスタマイズできます。 たとえば、次の設定ではメモリ内のバッファサイズを 100 個のオブジェクト、拡張単位を 100 個のオブジェクト、最大バッファサイズを 500 個のオブジェクトに設定します。 反復可能メモリ内 (イテラブル): ```xml ``` ## [](#disable_repeatable_streaming)反復可能ストリームの無効化 反復可能ストリームは、​`non-repeatable-stream`​ 戦略と ​`non-repeatable-iterable`​ 戦略で無効化できます。使用する戦略は、ストリームの種別によって決まります。 このオプションは、ストリームを複数回コンシュームする必要がないことが確実であり、パフォーマンスとリソース消費を非常に厳密に最適化する必要がある場合にのみ使用してください。 その場合には、次の点に注意してください。 - 反復可能ストリームを無効化するとパフォーマンスは向上しますが、向上する程度はストリームのサイズに比例します。大きなストリームを使用していない限り、アプリケーションの他の部分を調整した方がパフォーマンスはより大きく向上します。 - 反復可能ストリームを無効化すると、ストリームは 1 回しか読み取ることができなくなります。フローには、明示的にそのように指定していなくても、ストリーム全体をコンシュームする必要のあるコンポーネントが存在する可能性があります。たとえば、Cache コンポーネント (​``​)、Transform Message コンポーネント (​``​) による一部の変換、For Each コンポーネント (​``​) による JSON 配列の反復処理、そしてストリームに直接、または式を通してアクセスする他のコンポーネントなどです。 ## [](#関連情報)関連情報 - [ストリーミング戦略リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/streaming-strategies-reference) # Mule アプリケーションでのストリーミング Mule 4 では、データストリームを処理するためのフレームワークが追加されています。Mule 4 での変更点を理解するためには、従来はデータストリームがどのようにコンシュームされていたかを理解することが必要です。 - データストリームは 1 回しかコンシュームできません。 次の例は、ファイルに書き込む本文 (ペイロード) を持つ POST メソッドを受け取る HTTP Listener ソースのフローを示しています。このフローにより、最初のファイルは正しく書き込まれますが、2 つ目のファイルはコンテンツが空になります。これは、ストリームをコンシュームする各コンポーネントが、新しいストリームを受信することを予期しているためです。最初の File Write 操作がストリームをコンシュームすると、2 つ目の File Write 操作は空のストリームを受け取ります。そのため、2 つ目の操作はファイルに書き込むコンテンツを持ちません。 ![mruntime streaming about 1](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-streaming-about-1.png) Figure 1. Mule 3 のストリーミング: ファイルの書き込み 次の例は、DataWeave 変換の後でペイロードをログに記録しようとすると、同じような結果となります。HTTP Listener 操作は、ペイロードストリームを受け取り、ストリームが Transform Message コンポーネントに達した時点ではまだメモリに残っているため、コンポーネントはストリームをコンシュームします。Transform Message コンポーネントでコンテンツをコンシュームした後で、2 つ目の Logger は空のストリームを受信します。 ![mruntime streaming about 2](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-streaming-about-2.png) Figure 2. Mule 3 のストリーミング: ペイロードのログへの記録 - データストリームを同時にコンシュームすることはできません。 次の例は、Scatter-Gather ルーターを使用してデータストリームを分割し、ペイロードのログへの記録とファイルへの書き込みを同時に実行するフローを示しています。異なるプロセッサーチェーンでデータストリームのコンテンツを同時に処理することはできないため、アプリケーションはストリームの一部をファイルで受け取り、残りをログで受け取ります。 ![mruntime streaming about 3](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-streaming-about-3.png) Figure 3. Mule 3 のストリーミング: データストリームのコンシューム ## [](#反復可能ストリーム)反復可能ストリーム Mule 4 では、ストリームを処理するためのデフォルトフレームワークとして反復可能ストリームが追加されています。反復可能ストリームを使用すると、次の操作を実行できます。 - ストリームを複数回読み込むことができます。 - ストリームに同時にアクセスできます。 コンポーネントがストリームをコンシュームすると、Mule はそのコンテンツを一時バッファに格納します。以後、ランタイムはストリームのコンテンツをテンポラリーバッファからコンポーネントに供給することで、すでにストリームが他のコンポーネントによって何度コンシュームされていようとも、各コンポーネントが完全なストリームを受信できるようにします。この処理は自動的に行われるため、ユーザーが特別な設定をする必要はなく、再びアクセスするためにストリームを別の場所に保存するための回避策を考える必要はありません。この設定により、上記の 3 つの Mule アプリケーションの例の問題のうち、2 つが自動的に解決されます。 すべての反復可能ストリームは並列アクセスをサポートしています。つまり、各コンポーネントが異なるスレッドで実行されているときに、2 つのコンポーネントが同じストリームを読み取ろうとしても心配する要はありません。Mule は、コンポーネント ​`A`​ がストリームを読み込んでもコンポーネント ​`B`​ に対して一切の副作用を発生させないことを自動的に保証します。 この動作により、​[3 番目の例](#example_3)​で説明しているようなタスクを実行できます。 ## [](#ストリーミング戦略)ストリーミング戦略 ストリーミング戦略を使用して、Mule によるストリームの処理方法を設定できます。 ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルストレージは Mule 4 のデフォルトのストリーミング戦略です。

ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
この戦略では、初期設定として、メモリ内のバッファサイズとして 512 KB を使用します。ストリームが大きくなると、この戦略で一時ファイルがディスクに作成され、メモリをオーバーフローさせることなく、コンテンツを格納します。 大きいまたは小さいファイルを処理する必要がある場合、バッファサイズ (​`inMemorySize`​) を変更してパフォーマンスを最適化できます。 - バッファサイズを大きく設定すると、ランタイムがバッファをディスクに書き込む回数を減らすことができるため、パフォーマンスが向上します。ただし、アプリケーションが同時に処理できる要求の数が制限されます。 - バッファサイズを小さく設定すると、メモリの負荷が減ります。 また、バッファの測定の単位も設定できます (​`bufferUnit`​)。 たとえば、常に約 1 MB のファイルを読み取ることが分かっているのであれば、1 MB のバッファを設定できます。 ```xml ``` あるいは、処理するファイルのサイズが 10 KB を超えることがないということが分かっていれば、メモリを節約できます。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズ設定が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。 ただし、ニーズに合った適切なバッファサイズの設定を見つけるには、テストを実行する必要があります。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内戦略は、Mule Kernel (以前の名称は Mule Runtime Community Edition) のデフォルト設定です。 この戦略のデフォルトのバッファサイズは 512 KB です。大きいストリームでは、設定した最大バッファサイズに達するまで、デフォルトの拡張単位である 512 KB ずつバッファが拡張されます。ストリームが最大バッファサイズを超えると、アプリケーションはエラーとなります。 この動作は、初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、最大バッファサイズ (​`maxInMemorySize`​)、バッファサイズ値の測定単位 (​`bufferUnit`​) を設定することでカスタマイズできます。 たとえば、次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズと 512 KB の拡張単位が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。ただし、テストを実行してニーズに合った適切なバッファサイズとサイズの拡張単位の設定を見つける必要があります。 `InputStream`​ または ​`Streamable`​ コレクションを返す Mule 4 のすべてのコンポーネントで、反復可能ストリームがサポートされています。これらのコンポーネントには以下が含まれています。 - File Connector - FTP Connector - Database Connector - HTTP Connector - Sockets Connector - SalesForce Connector ## [](#オブジェクトのストリーミング)オブジェクトのストリーミング Anypoint が自動ページングを使用するように設定されている場合、Mule 4 によって、反復可能自動ページングフレームワークを使用してページングされたコネクタ出力が自動的に処理されます。コネクタがオブジェクトを受信し、Mule がオブジェクトを保存するために設定可能なメモリ内バッファを設定するため、このフレームワークは反復可能ストリームと似ています。ただし、反復可能ストリームはバッファサイズをバイト単位で測定するのに対して、ランタイムはオブジェクトを処理するときにインスタンス数を使用してバッファサイズを測定します。
オブジェクトをストリーミングすると、メモリ内のバッファサイズはインスタンス数で測定されます。
反復可能自動ページングのメモリ内のバッファサイズを計算する場合は、メモリ不足にならないように、各インスタンスで使用するメモリ量を見積もる必要があります。 反復可能ストリームと同じように、さまざまな戦略を使用して、Mule による反復可能自動ページングの処理方法を設定できます。 ### [](#反復可能ファイルストア-イテラブル)反復可能ファイルストア (イテラブル) この設定は、Mule Enterprise Edition のデフォルトです。この戦略では、デフォルトの設定済みメモリ内バッファとして 500 個のオブジェクトを使用します。このバッファサイズよりも多くの結果がクエリで返されると、Mule はオブジェクトをシリアル化して、ディスクに書き込みます。メモリ内のバッファに格納されるオブジェクト数は設定可能です。メモリ内に保存するオブジェクトの数が多いほど、ディスクへの書き込みが減るため、パフォーマンスが向上します。 たとえば、次のように、SalesForce Connector のクエリに対してメモリ内のバッファサイズを 100 個のオブジェクトに設定できます。 反復可能ファイルストア (イテラブル): ```xml ``` MuleSoft ではシリアル化に Kryo フレームワークを使用します。これは、標準の Java シリアル化では、​`Serializable`​ インターフェースを実装するためにシリアル化されたオブジェクト (およびそのすべての参照されるオブジェクト) が必要になるためです。Kryo シリアライザーにはこの制限がないため、標準の Java のシリアル化ではシリアル化できない一部のオブジェクトをシリアル化できます。ただし、Kryo ですべてをシリアル化できるわけではありません。たとえば、​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl`​ のインスタンスは Kryo を使用してもシリアル化できません。MuleSoft では、オブジェクトを単純にすることをお勧めします。

このオプションは Mule EE でのみ使用できます。
### [](#反復可能メモリ内-イテラブル)反復可能メモリ内 (イテラブル) この設定は Mule Kernel のデフォルトであり、デフォルトのバッファサイズを 500 個のオブジェクトに設定します。クエリ結果がこのサイズを超えると、設定された最大バッファサイズに到達するまで、デフォルトの拡張単位である 100 個ずつバッファが拡張されます。ストリームがこの制限を超えると、アプリケーションは失敗します。 初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、そして最大バッファサイズ (​`maxBufferSize`​) をカスタマイズできます。 たとえば、次の設定ではメモリ内のバッファサイズを 100 個のオブジェクト、拡張単位を 100 個のオブジェクト、最大バッファサイズを 500 個のオブジェクトに設定します。 反復可能メモリ内 (イテラブル): ```xml ``` ## [](#disable_repeatable_streaming)反復可能ストリームの無効化 反復可能ストリームは、​`non-repeatable-stream`​ 戦略と ​`non-repeatable-iterable`​ 戦略で無効化できます。使用する戦略は、ストリームの種別によって決まります。 このオプションは、ストリームを複数回コンシュームする必要がないことが確実であり、パフォーマンスとリソース消費を非常に厳密に最適化する必要がある場合にのみ使用してください。 その場合には、次の点に注意してください。 - 反復可能ストリームを無効化するとパフォーマンスは向上しますが、向上する程度はストリームのサイズに比例します。大きなストリームを使用していない限り、アプリケーションの他の部分を調整した方がパフォーマンスはより大きく向上します。 - 反復可能ストリームを無効化すると、ストリームは 1 回しか読み取ることができなくなります。フローには、明示的にそのように指定していなくても、ストリーム全体をコンシュームする必要のあるコンポーネントが存在する可能性があります。たとえば、Cache コンポーネント (​``​)、Transform Message コンポーネント (​``​) による一部の変換、For Each コンポーネント (​``​) による JSON 配列の反復処理、そしてストリームに直接、または式を通してアクセスする他のコンポーネントなどです。 ## [](#関連情報)関連情報 - [ストリーミング戦略リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/streaming-strategies-reference) # Mule アプリケーションでのストリーミング Mule 4 では、データストリームを処理するためのフレームワークが追加されています。Mule 4 での変更点を理解するためには、従来はデータストリームがどのようにコンシュームされていたかを理解することが必要です。 - データストリームは 1 回しかコンシュームできません。 次の例は、ファイルに書き込む本文 (ペイロード) を持つ POST メソッドを受け取る HTTP Listener ソースのフローを示しています。このフローにより、最初のファイルは正しく書き込まれますが、2 つ目のファイルはコンテンツが空になります。これは、ストリームをコンシュームする各コンポーネントが、新しいストリームを受信することを予期しているためです。最初の File Write 操作がストリームをコンシュームすると、2 つ目の File Write 操作は空のストリームを受け取ります。そのため、2 つ目の操作はファイルに書き込むコンテンツを持ちません。 ![mruntime streaming about 1](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-streaming-about-1.png) Figure 1. Mule 3 のストリーミング: ファイルの書き込み 次の例は、DataWeave 変換の後でペイロードをログに記録しようとすると、同じような結果となります。HTTP Listener 操作は、ペイロードストリームを受け取り、ストリームが Transform Message コンポーネントに達した時点ではまだメモリに残っているため、コンポーネントはストリームをコンシュームします。Transform Message コンポーネントでコンテンツをコンシュームした後で、2 つ目の Logger は空のストリームを受信します。 ![mruntime streaming about 2](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-streaming-about-2.png) Figure 2. Mule 3 のストリーミング: ペイロードのログへの記録 - データストリームを同時にコンシュームすることはできません。 次の例は、Scatter-Gather ルーターを使用してデータストリームを分割し、ペイロードのログへの記録とファイルへの書き込みを同時に実行するフローを示しています。異なるプロセッサーチェーンでデータストリームのコンテンツを同時に処理することはできないため、アプリケーションはストリームの一部をファイルで受け取り、残りをログで受け取ります。 ![mruntime streaming about 3](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-streaming-about-3.png) Figure 3. Mule 3 のストリーミング: データストリームのコンシューム ## [](#反復可能ストリーム)反復可能ストリーム Mule 4 では、ストリームを処理するためのデフォルトフレームワークとして反復可能ストリームが追加されています。反復可能ストリームを使用すると、次の操作を実行できます。 - ストリームを複数回読み込むことができます。 - ストリームに同時にアクセスできます。 コンポーネントがストリームをコンシュームすると、Mule はそのコンテンツを一時バッファに格納します。以後、ランタイムはストリームのコンテンツをテンポラリーバッファからコンポーネントに供給することで、すでにストリームが他のコンポーネントによって何度コンシュームされていようとも、各コンポーネントが完全なストリームを受信できるようにします。この処理は自動的に行われるため、ユーザーが特別な設定をする必要はなく、再びアクセスするためにストリームを別の場所に保存するための回避策を考える必要はありません。この設定により、上記の 3 つの Mule アプリケーションの例の問題のうち、2 つが自動的に解決されます。 すべての反復可能ストリームは並列アクセスをサポートしています。つまり、各コンポーネントが異なるスレッドで実行されているときに、2 つのコンポーネントが同じストリームを読み取ろうとしても心配する要はありません。Mule は、コンポーネント ​`A`​ がストリームを読み込んでもコンポーネント ​`B`​ に対して一切の副作用を発生させないことを自動的に保証します。 この動作により、​[3 番目の例](#example_3)​で説明しているようなタスクを実行できます。 ## [](#ストリーミング戦略)ストリーミング戦略 ストリーミング戦略を使用して、Mule によるストリームの処理方法を設定できます。 ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルストレージは Mule 4 のデフォルトのストリーミング戦略です。

ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
この戦略では、初期設定として、メモリ内のバッファサイズとして 512 KB を使用します。ストリームが大きくなると、この戦略で一時ファイルがディスクに作成され、メモリをオーバーフローさせることなく、コンテンツを格納します。 大きいまたは小さいファイルを処理する必要がある場合、バッファサイズ (​`inMemorySize`​) を変更してパフォーマンスを最適化できます。 - バッファサイズを大きく設定すると、ランタイムがバッファをディスクに書き込む回数を減らすことができるため、パフォーマンスが向上します。ただし、アプリケーションが同時に処理できる要求の数が制限されます。 - バッファサイズを小さく設定すると、メモリの負荷が減ります。 また、バッファの測定の単位も設定できます (​`bufferUnit`​)。 たとえば、常に約 1 MB のファイルを読み取ることが分かっているのであれば、1 MB のバッファを設定できます。 ```xml ``` あるいは、処理するファイルのサイズが 10 KB を超えることがないということが分かっていれば、メモリを節約できます。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズ設定が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。 ただし、ニーズに合った適切なバッファサイズの設定を見つけるには、テストを実行する必要があります。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内戦略は、Mule Kernel (以前の名称は Mule Runtime Community Edition) のデフォルト設定です。 この戦略のデフォルトのバッファサイズは 512 KB です。大きいストリームでは、設定した最大バッファサイズに達するまで、デフォルトの拡張単位である 512 KB ずつバッファが拡張されます。ストリームが最大バッファサイズを超えると、アプリケーションはエラーとなります。 この動作は、初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、最大バッファサイズ (​`maxInMemorySize`​)、バッファサイズ値の測定単位 (​`bufferUnit`​) を設定することでカスタマイズできます。 たとえば、次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズと 512 KB の拡張単位が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。ただし、テストを実行してニーズに合った適切なバッファサイズとサイズの拡張単位の設定を見つける必要があります。 `InputStream`​ または ​`Streamable`​ コレクションを返す Mule 4 のすべてのコンポーネントで、反復可能ストリームがサポートされています。これらのコンポーネントには以下が含まれています。 - File Connector - FTP Connector - Database Connector - HTTP Connector - Sockets Connector - SalesForce Connector ## [](#オブジェクトのストリーミング)オブジェクトのストリーミング Anypoint が自動ページングを使用するように設定されている場合、Mule 4 によって、反復可能自動ページングフレームワークを使用してページングされたコネクタ出力が自動的に処理されます。コネクタがオブジェクトを受信し、Mule がオブジェクトを保存するために設定可能なメモリ内バッファを設定するため、このフレームワークは反復可能ストリームと似ています。ただし、反復可能ストリームはバッファサイズをバイト単位で測定するのに対して、ランタイムはオブジェクトを処理するときにインスタンス数を使用してバッファサイズを測定します。
オブジェクトをストリーミングすると、メモリ内のバッファサイズはインスタンス数で測定されます。
反復可能自動ページングのメモリ内のバッファサイズを計算する場合は、メモリ不足にならないように、各インスタンスで使用するメモリ量を見積もる必要があります。 反復可能ストリームと同じように、さまざまな戦略を使用して、Mule による反復可能自動ページングの処理方法を設定できます。 ### [](#反復可能ファイルストア-イテラブル)反復可能ファイルストア (イテラブル) この設定は、Mule Enterprise Edition のデフォルトです。この戦略では、デフォルトの設定済みメモリ内バッファとして 500 個のオブジェクトを使用します。このバッファサイズよりも多くの結果がクエリで返されると、Mule はオブジェクトをシリアル化して、ディスクに書き込みます。メモリ内のバッファに格納されるオブジェクト数は設定可能です。メモリ内に保存するオブジェクトの数が多いほど、ディスクへの書き込みが減るため、パフォーマンスが向上します。 たとえば、次のように、SalesForce Connector のクエリに対してメモリ内のバッファサイズを 100 個のオブジェクトに設定できます。 反復可能ファイルストア (イテラブル): ```xml ``` MuleSoft ではシリアル化に Kryo フレームワークを使用します。これは、標準の Java シリアル化では、​`Serializable`​ インターフェースを実装するためにシリアル化されたオブジェクト (およびそのすべての参照されるオブジェクト) が必要になるためです。Kryo シリアライザーにはこの制限がないため、標準の Java のシリアル化ではシリアル化できない一部のオブジェクトをシリアル化できます。ただし、Kryo ですべてをシリアル化できるわけではありません。たとえば、​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl`​ のインスタンスは Kryo を使用してもシリアル化できません。MuleSoft では、オブジェクトを単純にすることをお勧めします。

このオプションは Mule EE でのみ使用できます。
### [](#反復可能メモリ内-イテラブル)反復可能メモリ内 (イテラブル) この設定は Mule Kernel のデフォルトであり、デフォルトのバッファサイズを 500 個のオブジェクトに設定します。クエリ結果がこのサイズを超えると、設定された最大バッファサイズに到達するまで、デフォルトの拡張単位である 100 個ずつバッファが拡張されます。ストリームがこの制限を超えると、アプリケーションは失敗します。 初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、そして最大バッファサイズ (​`maxBufferSize`​) をカスタマイズできます。 たとえば、次の設定ではメモリ内のバッファサイズを 100 個のオブジェクト、拡張単位を 100 個のオブジェクト、最大バッファサイズを 500 個のオブジェクトに設定します。 反復可能メモリ内 (イテラブル): ```xml ``` ## [](#disable_repeatable_streaming)反復可能ストリームの無効化 反復可能ストリームは、​`non-repeatable-stream`​ 戦略と ​`non-repeatable-iterable`​ 戦略で無効化できます。使用する戦略は、ストリームの種別によって決まります。 このオプションは、ストリームを複数回コンシュームする必要がないことが確実であり、パフォーマンスとリソース消費を非常に厳密に最適化する必要がある場合にのみ使用してください。 その場合には、次の点に注意してください。 - 反復可能ストリームを無効化するとパフォーマンスは向上しますが、向上する程度はストリームのサイズに比例します。大きなストリームを使用していない限り、アプリケーションの他の部分を調整した方がパフォーマンスはより大きく向上します。 - 反復可能ストリームを無効化すると、ストリームは 1 回しか読み取ることができなくなります。フローには、明示的にそのように指定していなくても、ストリーム全体をコンシュームする必要のあるコンポーネントが存在する可能性があります。たとえば、Cache コンポーネント (​``​)、Transform Message コンポーネント (​``​) による一部の変換、For Each コンポーネント (​``​) による JSON 配列の反復処理、そしてストリームに直接、または式を通してアクセスする他のコンポーネントなどです。 ## [](#関連情報)関連情報 - [ストリーミング戦略リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/streaming-strategies-reference) # Mule アプリケーションでのストリーミング Mule 4 では、データストリームを処理するためのフレームワークが追加されています。Mule 4 での変更点を理解するためには、従来はデータストリームがどのようにコンシュームされていたかを理解することが必要です。 - データストリームは 1 回しかコンシュームできません。 次の例は、ファイルに書き込む本文 (ペイロード) を持つ POST メソッドを受け取る HTTP Listener ソースのフローを示しています。このフローにより、最初のファイルは正しく書き込まれますが、2 つ目のファイルはコンテンツが空になります。これは、ストリームをコンシュームする各コンポーネントが、新しいストリームを受信することを予期しているためです。最初の File Write 操作がストリームをコンシュームすると、2 つ目の File Write 操作は空のストリームを受け取ります。そのため、2 つ目の操作はファイルに書き込むコンテンツを持ちません。 ![HTTP および File 操作が Error handling と共に表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-streaming-about-1.png) Figure 1. Mule 3 のストリーミング: ファイルの書き込み 次の例は、DataWeave 変換の後でペイロードをログに記録しようとすると、同じような結果となります。HTTP Listener 操作は、ペイロードストリームを受け取り、ストリームが Transform Message コンポーネントに達した時点ではまだメモリに残っているため、コンポーネントはストリームをコンシュームします。Transform Message コンポーネントでコンテンツをコンシュームした後で、2 つ目の Logger は空のストリームを受信します。 ![ストリーミングアプリケーションのコンポーネント (HTTP、Logger、Error handling) が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-streaming-about-2.png) Figure 2. Mule 3 のストリーミング: ペイロードのログへの記録 - データストリームを同時にコンシュームすることはできません。 次の例は、Scatter-Gather ルーターを使用してデータストリームを分割し、ペイロードのログへの記録とファイルへの書き込みを同時に実行するフローを示しています。異なるプロセッサーチェーンでデータストリームのコンテンツを同時に処理することはできないため、アプリケーションはストリームの一部をファイルで受け取り、残りをログで受け取ります。 ![Scatter-Gather と Error handling が含まれる非同期ファイル処理が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-streaming-about-3.png) Figure 3. Mule 3 のストリーミング: データストリームのコンシューム ## [](#反復可能ストリーム)反復可能ストリーム Mule 4 では、ストリームを処理するためのデフォルトフレームワークとして反復可能ストリームが追加されています。反復可能ストリームを使用すると、次の操作を実行できます。 - ストリームを複数回読み込むことができます。 - ストリームに同時にアクセスできます。 コンポーネントがストリームをコンシュームすると、Mule はそのコンテンツを一時バッファに格納します。以後、ランタイムはストリームのコンテンツをテンポラリーバッファからコンポーネントに供給することで、すでにストリームが他のコンポーネントによって何度コンシュームされていようとも、各コンポーネントが完全なストリームを受信できるようにします。この処理は自動的に行われるため、ユーザーが特別な設定をする必要はなく、再びアクセスするためにストリームを別の場所に保存するための回避策を考える必要はありません。この設定により、上記の 3 つの Mule アプリケーションの例の問題のうち、2 つが自動的に解決されます。 すべての反復可能ストリームは並列アクセスをサポートしています。つまり、各コンポーネントが異なるスレッドで実行されているときに、2 つのコンポーネントが同じストリームを読み取ろうとしても心配する要はありません。Mule は、コンポーネント ​`A`​ がストリームを読み込んでもコンポーネント ​`B`​ に対して一切の副作用を発生させないことを自動的に保証します。 この動作により、​[3 番目の例](#example_3)​で説明しているようなタスクを実行できます。 ## [](#ストリーミング戦略)ストリーミング戦略 ストリーミング戦略を使用して、Mule によるストリームの処理方法を設定できます。 ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルストレージは Mule 4 のデフォルトのストリーミング戦略です。

ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
この戦略では、初期設定として、メモリ内のバッファサイズとして 512 KB を使用します。ストリームが大きくなると、この戦略で一時ファイルがディスクに作成され、メモリをオーバーフローさせることなく、コンテンツを格納します。 大きいまたは小さいファイルを処理する必要がある場合、バッファサイズ (​`inMemorySize`​) を変更してパフォーマンスを最適化できます。 - バッファサイズを大きく設定すると、ランタイムがバッファをディスクに書き込む回数を減らすことができるため、パフォーマンスが向上します。ただし、アプリケーションが同時に処理できる要求の数が制限されます。 - バッファサイズを小さく設定すると、メモリの負荷が減ります。 また、バッファの測定の単位も設定できます (​`bufferUnit`​)。 たとえば、常に約 1 MB のファイルを読み取ることが分かっているのであれば、1 MB のバッファを設定できます。 ```xml ``` あるいは、処理するファイルのサイズが 10 KB を超えることがないということが分かっていれば、メモリを節約できます。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズ設定が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。 ただし、ニーズに合った適切なバッファサイズの設定を見つけるには、テストを実行する必要があります。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内戦略は、Mule Kernel (以前の名称は Mule Runtime Community Edition) のデフォルト設定です。 この戦略のデフォルトのバッファサイズは 512 KB です。大きいストリームでは、設定した最大バッファサイズに達するまで、デフォルトの拡張単位である 512 KB ずつバッファが拡張されます。ストリームが最大バッファサイズを超えると、アプリケーションはエラーとなります。 この動作は、初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、最大バッファサイズ (​`maxInMemorySize`​)、バッファサイズ値の測定単位 (​`bufferUnit`​) を設定することでカスタマイズできます。 たとえば、次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズと 512 KB の拡張単位が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。ただし、テストを実行してニーズに合った適切なバッファサイズとサイズの拡張単位の設定を見つける必要があります。 `InputStream`​ または ​`Streamable`​ コレクションを返す Mule 4 のすべてのコンポーネントで、反復可能ストリームがサポートされています。これらのコンポーネントには以下が含まれています。 - File Connector - FTP Connector - Database Connector - HTTP Connector - Sockets Connector - SalesForce Connector ## [](#オブジェクトのストリーミング)オブジェクトのストリーミング Anypoint Connector が自動ページングを使用するように設定されている場合、Mule 4 によって、反復可能自動ページングフレームワークを使用してページングされたコネクタ出力が自動的に処理されます。コネクタがオブジェクトを受信し、Mule がオブジェクトを保存するために設定可能なメモリ内バッファを設定するため、このフレームワークは反復可能ストリームと似ています。ただし、反復可能ストリームはバッファサイズをバイト単位で測定するのに対して、ランタイムはオブジェクトを処理するときにインスタンス数を使用してバッファサイズを測定します。
オブジェクトをストリーミングすると、メモリ内のバッファサイズはインスタンス数で測定されます。
反復可能自動ページングのメモリ内のバッファサイズを計算する場合は、メモリ不足にならないように、各インスタンスで使用するメモリ量を見積もる必要があります。 反復可能ストリームと同じように、さまざまな戦略を使用して、Mule による反復可能自動ページングの処理方法を設定できます。 ### [](#反復可能ファイルストア-イテラブル)反復可能ファイルストア (イテラブル) この設定は、Mule Enterprise Edition のデフォルトです。この戦略では、デフォルトの設定済みメモリ内バッファとして 500 個のオブジェクトを使用します。このバッファサイズよりも多くの結果がクエリで返されると、Mule はオブジェクトをシリアル化して、ディスクに書き込みます。メモリ内のバッファに格納されるオブジェクト数は設定可能です。メモリ内に保存するオブジェクトの数が多いほど、ディスクへの書き込みが減るため、パフォーマンスが向上します。 たとえば、次のように、SalesForce Connector のクエリに対してメモリ内のバッファサイズを 100 個のオブジェクトに設定できます。 反復可能ファイルストア (イテラブル): ```xml ``` MuleSoft ではシリアル化に Kryo フレームワークを使用します。これは、標準の Java シリアル化では、​`Serializable`​ インターフェースを実装するためにシリアル化されたオブジェクト (およびそのすべての参照されるオブジェクト) が必要になるためです。Kryo シリアライザーにはこの制限がないため、標準の Java のシリアル化ではシリアル化できない一部のオブジェクトをシリアル化できます。ただし、Kryo ですべてをシリアル化できるわけではありません。たとえば、​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl`​ のインスタンスは Kryo を使用してもシリアル化できません。MuleSoft では、オブジェクトを単純にすることをお勧めします。

このオプションは Mule EE でのみ使用できます。
### [](#反復可能メモリ内-イテラブル)反復可能メモリ内 (イテラブル) この設定は Mule Kernel のデフォルトであり、デフォルトのバッファサイズを 500 個のオブジェクトに設定します。クエリ結果がこのサイズを超えると、設定された最大バッファサイズに到達するまで、デフォルトの拡張単位である 100 個ずつバッファが拡張されます。ストリームがこの制限を超えると、アプリケーションは失敗します。 初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、そして最大バッファサイズ (​`maxBufferSize`​) をカスタマイズできます。 たとえば、次の設定ではメモリ内のバッファサイズを 100 個のオブジェクト、拡張単位を 100 個のオブジェクト、最大バッファサイズを 500 個のオブジェクトに設定します。 反復可能メモリ内 (イテラブル): ```xml ``` ## [](#disable_repeatable_streaming)反復可能ストリームの無効化 反復可能ストリームは、​`non-repeatable-stream`​ 戦略と ​`non-repeatable-iterable`​ 戦略で無効化できます。使用する戦略は、ストリームの種別によって決まります。 このオプションは、ストリームを複数回コンシュームする必要がないことが確実であり、パフォーマンスとリソース消費を非常に厳密に最適化する必要がある場合にのみ使用してください。 その場合には、次の点に注意してください。 - 反復可能ストリームを無効化するとパフォーマンスは向上しますが、向上する程度はストリームのサイズに比例します。大きなストリームを使用していない限り、アプリケーションの他の部分を調整した方がパフォーマンスはより大きく向上します。 - 反復可能ストリームを無効化すると、ストリームは 1 回しか読み取ることができなくなります。フローには、明示的にそのように指定していなくても、ストリーム全体をコンシュームする必要のあるコンポーネントが存在する可能性があります。たとえば、Cache コンポーネント (​``​)、Transform Message コンポーネント (​``​) による一部の変換、For Each コンポーネント (​``​) による JSON 配列の反復処理、そしてストリームに直接、または式を通してアクセスする他のコンポーネントなどです。 ## [](#関連情報)関連情報 - [ストリーミング戦略リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/streaming-strategies-reference) # Mule アプリケーションでのストリーミング Mule 4 では、データストリームを処理するためのフレームワークが追加されています。Mule 4 での変更点を理解するためには、従来はデータストリームがどのようにコンシュームされていたかを理解することが必要です。 - データストリームは 1 回しかコンシュームできません。 次の例は、ファイルに書き込む本文 (ペイロード) を持つ POST メソッドを受け取る HTTP Listener ソースのフローを示しています。このフローにより、最初のファイルは正しく書き込まれますが、2 つ目のファイルはコンテンツが空になります。これは、ストリームをコンシュームする各コンポーネントが、新しいストリームを受信することを予期しているためです。最初の File Write 操作がストリームをコンシュームすると、2 つ目の File Write 操作は空のストリームを受け取ります。そのため、2 つ目の操作はファイルに書き込むコンテンツを持ちません。 ![HTTP および File 操作が Error handling と共に表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-streaming-about-1.png) Figure 1. Mule 3 のストリーミング: ファイルの書き込み 次の例は、DataWeave 変換の後でペイロードをログに記録しようとすると、同じような結果となります。HTTP Listener 操作は、ペイロードストリームを受け取り、ストリームが Transform Message コンポーネントに達した時点ではまだメモリに残っているため、コンポーネントはストリームをコンシュームします。Transform Message コンポーネントでコンテンツをコンシュームした後で、2 つ目の Logger は空のストリームを受信します。 ![ストリーミングアプリケーションのコンポーネント (HTTP、Logger、Error handling) が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-streaming-about-2.png) Figure 2. Mule 3 のストリーミング: ペイロードのログへの記録 - データストリームを同時にコンシュームすることはできません。 次の例は、Scatter-Gather ルーターを使用してデータストリームを分割し、ペイロードのログへの記録とファイルへの書き込みを同時に実行するフローを示しています。異なるプロセッサーチェーンでデータストリームのコンテンツを同時に処理することはできないため、アプリケーションはストリームの一部をファイルで受け取り、残りをログで受け取ります。 ![Scatter-Gather と Error handling が含まれる非同期ファイル処理が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-streaming-about-3.png) Figure 3. Mule 3 のストリーミング: データストリームのコンシューム ## [](#反復可能ストリーム)反復可能ストリーム Mule 4 では、ストリームを処理するためのデフォルトフレームワークとして反復可能ストリームが追加されています。反復可能ストリームを使用すると、次の操作を実行できます。 - ストリームを複数回読み込むことができます。 - ストリームに同時にアクセスできます。 コンポーネントがストリームをコンシュームすると、Mule はそのコンテンツを一時バッファに格納します。以後、ランタイムはストリームのコンテンツをテンポラリーバッファからコンポーネントに供給することで、すでにストリームが他のコンポーネントによって何度コンシュームされていようとも、各コンポーネントが完全なストリームを受信できるようにします。この処理は自動的に行われるため、ユーザーが特別な設定をする必要はなく、再びアクセスするためにストリームを別の場所に保存するための回避策を考える必要はありません。この設定により、上記の 3 つの Mule アプリケーションの例の問題のうち、2 つが自動的に解決されます。 すべての反復可能ストリームは並列アクセスをサポートしています。つまり、各コンポーネントが異なるスレッドで実行されているときに、2 つのコンポーネントが同じストリームを読み取ろうとしても心配する要はありません。Mule は、コンポーネント ​`A`​ がストリームを読み込んでもコンポーネント ​`B`​ に対して一切の副作用を発生させないことを自動的に保証します。 この動作により、​[3 番目の例](#example_3)​で説明しているようなタスクを実行できます。 ## [](#ストリーミング戦略)ストリーミング戦略 ストリーミング戦略を使用して、Mule によるストリームの処理方法を設定できます。 ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルストレージは Mule 4 のデフォルトのストリーミング戦略です。

ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
この戦略では、初期設定として、メモリ内のバッファサイズとして 512 KB を使用します。ストリームが大きくなると、この戦略で一時ファイルがディスクに作成され、メモリをオーバーフローさせることなく、コンテンツを格納します。 大きいまたは小さいファイルを処理する必要がある場合、バッファサイズ (​`inMemorySize`​) を変更してパフォーマンスを最適化できます。 - バッファサイズを大きく設定すると、ランタイムがバッファをディスクに書き込む回数を減らすことができるため、パフォーマンスが向上します。ただし、アプリケーションが同時に処理できる要求の数が制限されます。 - バッファサイズを小さく設定すると、メモリの負荷が減ります。 また、バッファの測定の単位も設定できます (​`bufferUnit`​)。 たとえば、常に約 1 MB のファイルを読み取ることが分かっているのであれば、1 MB のバッファを設定できます。 ```xml ``` あるいは、処理するファイルのサイズが 10 KB を超えることがないということが分かっていれば、メモリを節約できます。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズ設定が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。 ただし、ニーズに合った適切なバッファサイズの設定を見つけるには、テストを実行する必要があります。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内戦略は、Mule Kernel (以前の名称は Mule Runtime Community Edition) のデフォルト設定です。 この戦略のデフォルトのバッファサイズは 512 KB です。大きいストリームでは、設定した最大バッファサイズに達するまで、デフォルトの拡張単位である 512 KB ずつバッファが拡張されます。ストリームが最大バッファサイズを超えると、アプリケーションはエラーとなります。 この動作は、初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、最大バッファサイズ (​`maxInMemorySize`​)、バッファサイズ値の測定単位 (​`bufferUnit`​) を設定することでカスタマイズできます。 たとえば、次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` パフォーマンステストにより、この戦略のデフォルトである 512 KB のバッファサイズと 512 KB の拡張単位が、ほとんどのシナリオにおいてパフォーマンスに大きな影響を与えないことが分かっています。ただし、テストを実行してニーズに合った適切なバッファサイズとサイズの拡張単位の設定を見つける必要があります。 `InputStream`​ または ​`Streamable`​ コレクションを返す Mule 4 のすべてのコンポーネントで、反復可能ストリームがサポートされています。これらのコンポーネントには以下が含まれています。 - File Connector - FTP Connector - Database Connector - HTTP Connector - Sockets Connector - SalesForce Connector ## [](#オブジェクトのストリーミング)オブジェクトのストリーミング Anypoint Connector が自動ページングを使用するように設定されている場合、Mule 4 によって、反復可能自動ページングフレームワークを使用してページングされたコネクタ出力が自動的に処理されます。コネクタがオブジェクトを受信し、Mule がオブジェクトを保存するために設定可能なメモリ内バッファを設定するため、このフレームワークは反復可能ストリームと似ています。ただし、反復可能ストリームはバッファサイズをバイト単位で測定するのに対して、ランタイムはオブジェクトを処理するときにインスタンス数を使用してバッファサイズを測定します。
オブジェクトをストリーミングすると、メモリ内のバッファサイズはインスタンス数で測定されます。
反復可能自動ページングのメモリ内のバッファサイズを計算する場合は、メモリ不足にならないように、各インスタンスで使用するメモリ量を見積もる必要があります。 反復可能ストリームと同じように、さまざまな戦略を使用して、Mule による反復可能自動ページングの処理方法を設定できます。 ### [](#反復可能ファイルストア-イテラブル)反復可能ファイルストア (イテラブル) この設定は、Mule Enterprise Edition のデフォルトです。この戦略では、デフォルトの設定済みメモリ内バッファとして 500 個のオブジェクトを使用します。このバッファサイズよりも多くの結果がクエリで返されると、Mule はオブジェクトをシリアル化して、ディスクに書き込みます。メモリ内のバッファに格納されるオブジェクト数は設定可能です。メモリ内に保存するオブジェクトの数が多いほど、ディスクへの書き込みが減るため、パフォーマンスが向上します。 たとえば、次のように、SalesForce Connector のクエリに対してメモリ内のバッファサイズを 100 個のオブジェクトに設定できます。 反復可能ファイルストア (イテラブル): ```xml ``` MuleSoft ではシリアル化に Kryo フレームワークを使用します。これは、標準の Java シリアル化では、​`Serializable`​ インターフェースを実装するためにシリアル化されたオブジェクト (およびそのすべての参照されるオブジェクト) が必要になるためです。Kryo シリアライザーにはこの制限がないため、標準の Java のシリアル化ではシリアル化できない一部のオブジェクトをシリアル化できます。ただし、Kryo ですべてをシリアル化できるわけではありません。たとえば、​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl`​ のインスタンスは Kryo を使用してもシリアル化できません。MuleSoft では、オブジェクトを単純にすることをお勧めします。

このオプションは Mule EE でのみ使用できます。
### [](#反復可能メモリ内-イテラブル)反復可能メモリ内 (イテラブル) この設定は Mule Kernel のデフォルトであり、デフォルトのバッファサイズを 500 個のオブジェクトに設定します。クエリ結果がこのサイズを超えると、設定された最大バッファサイズに到達するまで、デフォルトの拡張単位である 100 個ずつバッファが拡張されます。ストリームがこの制限を超えると、アプリケーションは失敗します。 初期バッファサイズ (​`initialBufferSize`​)、バッファの拡張単位 (​`bufferSizeIncrement`​)、そして最大バッファサイズ (​`maxBufferSize`​) をカスタマイズできます。 たとえば、次の設定ではメモリ内のバッファサイズを 100 個のオブジェクト、拡張単位を 100 個のオブジェクト、最大バッファサイズを 500 個のオブジェクトに設定します。 反復可能メモリ内 (イテラブル): ```xml ``` ## [](#disable_repeatable_streaming)反復可能ストリームの無効化 反復可能ストリームは、​`non-repeatable-stream`​ 戦略と ​`non-repeatable-iterable`​ 戦略で無効化できます。使用する戦略は、ストリームの種別によって決まります。 このオプションは、ストリームを複数回コンシュームする必要がないことが確実であり、パフォーマンスとリソース消費を非常に厳密に最適化する必要がある場合にのみ使用してください。 その場合には、次の点に注意してください。 - 反復可能ストリームを無効化するとパフォーマンスは向上しますが、向上する程度はストリームのサイズに比例します。大きなストリームを使用していない限り、アプリケーションの他の部分を調整した方がパフォーマンスはより大きく向上します。 - 反復可能ストリームを無効化すると、ストリームは 1 回しか読み取ることができなくなります。フローには、明示的にそのように指定していなくても、ストリーム全体をコンシュームする必要のあるコンポーネントが存在する可能性があります。たとえば、Cache コンポーネント (​``​)、Transform Message コンポーネント (​``​) による一部の変換、For Each コンポーネント (​``​) による JSON 配列の反復処理、そしてストリームに直接、または式を通してアクセスする他のコンポーネントなどです。 ## [](#関連情報)関連情報 - [ストリーミング戦略リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/streaming-strategies-reference) # Mule アプリケーションのテスト Mule アプリケーション用に自動化されたテストの包括的なスイートを構築すれば、ローカル環境でのテスト中にアプリケーション内の回帰や互換性のない変更を検出できます。MUnit は Mule テストフレームワークであり、​_ユニット_​テスト、​_インテグレーション_​テスト、​_機能_​テストを使用して、Mule アプリケーションのテストを容易に自動化できます。MUnit には、分離環境でコードのユニットをテストできるプロセッサーモックフレームワークなど、一連のツールも用意されています。 詳細は、​[MUnit](https://docs.mulesoft.com/munit/latest/)​ のドキュメントを参照してください。 アプリケーションを作成するときは、コードのモジュール化などのベストプラクティスに従い、コードのテストが容易になるように短いフローを記述します。問題を識別して解決しやすくなるように、わかりやすい名前とエラーメッセージを使用して読みやすく維持しやすいテストを作成します。 Anypoint Studio のテストレコーダー (ベータ) を使用すると、処理フローを記録してから、取得されたイベントに基づいてユニットテストを設定できます。 詳細と例は、​[「Studio のテストレコーダー」](https://docs.mulesoft.com/munit/latest/test-recorder)​を参照してください。 アプリケーションのロジックおよび動作をテストしたら、Mule Runtime Engine (Mule) をプロファイリングして Mule アプリケーションのパフォーマンスをテストできます。このプロセスにより、Mule アプリケーションやカスタム Mule 拡張機能でのメモリやパフォーマンスに関連した問題を識別しやすくなります。Mule をプロファイリングするには、Java プロファイラーをオンプレミス Mule インスタンスに読み込む必要があります。 詳細な手順は、​[「Mule のプロファイリング」](https://docs.mulesoft.com/jp/mule-runtime/4.3/profiling-mule)​を参照してください。 ## [](#ユニットテスト)ユニットテスト ユニットテストの概念はプログラミングのパラダイムに応じて異なりますが、その中核的な概念は常に​_ソースコードの各ユニットの正しさを検証すること_​です。 ユニットテストのコンテキストでは、コードのユニットとはアプリケーションのテスト可能な最小の部分を指します。アプリケーションのテスト可能な最小の部分の実際の構成要素は、アプリケーションに応じて異なります。Mule アプリケーションの場合、テスト可能な最小の部分とは Mule フローまたはサブフローです。 開発者として、テストするコードが他のコードのユニットまたはコンポーネントとやりとりするかどうかを評価し、必ずテスト対象のコードのユニットを分離するようにユニットテストをデザインする必要があります。 分離により、テストに失敗した場合は、その原因が他のコードやコンポーネントではなくテスト対象のコードに関連するようにできます。 対象コードユニットを分離するには、MUnit が提供する ​`mock-when`​ プロセッサーなどのツールを使用します。 `mock-when`​ プロセッサーの使用例については、​[「Foreach プロセッサーの前および内部のメッセージのモック」](https://docs.mulesoft.com/munit/latest/mock-before-after-foreach-cookbook)​を参照してください。 ## [](#インテグレーションテスト)インテグレーションテスト コードのユニットが組み合わさって実際のアプリケーションを構成するため、これらのユニットを正常にテストしたら、インテグレーションテストを使用してアプリケーション全体をテストする準備が整います。 インテグレーションテストの目的は、​_異なるコードのユニットおよびモジュールが意図したとおりに連携して機能することを検証すること_​です。 アプリケーションの性質に応じて、インテグレーションテストに ​_Sandbox_​ テスト環境が必要になる場合もあります。これにより、本番のアプリケーション環境の外部で分離されたテスト評価を行うことができます。意図した結果を得るには、Sandbox のデータの状態がテストに適切であることを確認する必要があります。この検証は、インテグレーションテストを実行する前後に実行します。 ## [](#機能テスト)機能テスト 機能テストでは、Mule アプリケーション全体に想定されるユースケースをテストします。 たとえば、2 つのシステム間の双方向同期を維持するための Mule アプリケーションをテストするために、各システムでエントリを作成し、もう一方での複製を検証するテストケースをデザインできます。または、バッチ処理アプリケーションをテストする場合は、典型的な一連の情報を使用してテストを実行し、バッチの結果を検証できます。最後に、サービスオーケストレーションをテストするには、フローの一端でイベントを生成し、イベントがさまざまなサービスを通過した後に、もう一端で結果をテストすることができます。 インテグレーションテストの場合と同様、機能テストケースはテスト専用の環境プロパティおよびサービスのバージョンを使用して実行します。 ## [](#テスト可能なコードの記述)テスト可能なコードの記述 コードをモジュール化して実行環境を定義すれば、テストがきわめて容易になります (さらに、より設定項目が多く、拡張可能で読みやすいアプリケーションを作成できます)。 - コードをモジュール化する コードを異なるファイルに分割すれば、読みやすさが向上します。そのためには、共通の目標を達成するために連携するフローをグループ化するか、特定の機能的条件に従ってコードをグループ化します。 - 短いフローを記述する 長いフローは理解やコーディング、維持が難しくなる場合があるため、避けるのが得策です。ユニットテストの観点から見ると、長いフローでは 1 つのポイントからトリガーできるシナリオが多すぎるため、1 つのシナリオを検証するために非常に複雑な評価を実行する必要があるということになります。 - 実行環境を定義する プレースホルダーを使用してコードをパラメーター化します。この通常のユースケースには、DB や HTTP などのアウトバウンドエンドポイントのアドレスが含まれます。プレースホルダーを使用することで、テスト (ユニットまたはインテグレーション) 実行時に実際のアドレスを変更でき、環境 (DEV/QA/UAT/PROD) 間でコードを昇格させるのが容易になります。 ## [](#テスト作成のベストプラクティス)テスト作成のベストプラクティス - 読みやすく維持しやすくなるようにテストを作成します。 - テストが失敗したときに確認する内容に従ってテストに名前を付けます。 - テストが失敗したときに誤って記述されたエラーメッセージや曖昧なエラーメッセージが表示されないように、失敗時にテストによってスローされるわかりやすい名前を使用します。 - 長いフローは理解しにくくなるため、使用を避けます。 - カバーされるシナリオと失敗の条件が明示的になるようにテストをコーディングします。 ## [](#関連情報)関連情報 - [MUnit テスト構造の基礎](https://docs.mulesoft.com/munit/latest/munit-test-concept) - [MUnit の例](https://docs.mulesoft.com/munit/latest/munit-cookbook) # Mule アプリケーションのテスト Mule アプリケーション用に自動化されたテストの包括的なスイートを構築すれば、ローカル環境でのテスト中にアプリケーション内の回帰や互換性のない変更を検出できます。MUnit は Mule テストフレームワークであり、​_ユニット_​テスト、​_インテグレーション_​テスト、​_機能_​テストを使用して、Mule アプリケーションのテストを容易に自動化できます。MUnit には、分離環境でコードのユニットをテストできるプロセッサーモックフレームワークなど、一連のツールも用意されています。 詳細は、​[MUnit](https://docs.mulesoft.com/munit/latest/)​ のドキュメントを参照してください。 アプリケーションを作成するときは、コードのモジュール化などのベストプラクティスに従い、コードのテストが容易になるように短いフローを記述します。問題を識別して解決しやすくなるように、わかりやすい名前とエラーメッセージを使用して読みやすく維持しやすいテストを作成します。 Anypoint Studio のテストレコーダー (ベータ) を使用すると、処理フローを記録してから、捕捉されたイベントに基づいてユニットテストを設定できます。 詳細と例は、​[「Studio のテストレコーダー」](https://docs.mulesoft.com/munit/latest/test-recorder)​を参照してください。 アプリケーションのロジックおよび動作をテストしたら、Mule Runtime Engine (Mule) をプロファイリングして Mule アプリケーションのパフォーマンスをテストできます。このプロセスにより、Mule アプリケーションやカスタム Mule 拡張機能でのメモリやパフォーマンスに関連した問題を識別しやすくなります。Mule をプロファイリングするには、Java プロファイラーをオンプレミス Mule インスタンスに読み込む必要があります。 詳細な手順は、​[「Mule のプロファイリング」](https://docs.mulesoft.com/jp/mule-runtime/4.4/profiling-mule)​を参照してください。 ## [](#ユニットテスト)ユニットテスト ユニットテストの概念はプログラミングのパラダイムに応じて異なりますが、その中核的な概念は常に​_ソースコードの各ユニットの正しさを検証すること_​です。 ユニットテストのコンテキストでは、コードのユニットとはアプリケーションのテスト可能な最小の部分を指します。アプリケーションのテスト可能な最小の部分の実際の構成要素は、アプリケーションに応じて異なります。Mule アプリケーションの場合、テスト可能な最小の部分とは Mule フローまたはサブフローです。 開発者として、テストするコードが他のコードのユニットまたはコンポーネントとやりとりするかどうかを評価し、必ずテスト対象のコードのユニットを分離するようにユニットテストをデザインする必要があります。 分離により、テストに失敗した場合は、その原因が他のコードやコンポーネントではなくテスト対象のコードに関連するようにできます。 対象コードユニットを分離するには、MUnit が提供する ​`mock-when`​ プロセッサーなどのツールを使用します。 `mock-when`​ プロセッサーの使用例については、​[「Foreach プロセッサーの前および内部のメッセージのモック」](https://docs.mulesoft.com/munit/latest/mock-before-after-foreach-cookbook)​を参照してください。 ## [](#インテグレーションテスト)インテグレーションテスト コードのユニットが組み合わさって実際のアプリケーションを構成するため、これらのユニットを正常にテストしたら、インテグレーションテストを使用してアプリケーション全体をテストする準備が整います。 インテグレーションテストの目的は、​_異なるコードのユニットおよびモジュールが意図したとおりに連携して機能することを検証すること_​です。 アプリケーションの性質に応じて、インテグレーションテストに ​_Sandbox_​ テスト環境が必要になる場合もあります。これにより、本番のアプリケーション環境の外部で分離されたテスト評価を行うことができます。意図した結果を得るには、Sandbox のデータの状態がテストに適切であることを確認する必要があります。この検証は、インテグレーションテストを実行する前後に実行します。 ## [](#機能テスト)機能テスト 機能テストでは、Mule アプリケーション全体に想定されるユースケースをテストします。 たとえば、2 つのシステム間の双方向同期を維持するための Mule アプリケーションをテストするために、各システムでエントリを作成し、もう一方での複製を検証するテストケースをデザインできます。または、バッチ処理アプリケーションをテストする場合は、典型的な一連の情報を使用してテストを実行し、バッチの結果を検証できます。最後に、サービスオーケストレーションをテストするには、フローの一端でイベントを生成し、イベントがさまざまなサービスを通過した後に、もう一端で結果をテストすることができます。 インテグレーションテストの場合と同様、機能テストケースはテスト専用の環境プロパティおよびサービスのバージョンを使用して実行します。 ## [](#テスト可能なコードの記述)テスト可能なコードの記述 コードをモジュール化して実行環境を定義すれば、テストがきわめて容易になります (さらに、より設定項目が多く、拡張可能で読みやすいアプリケーションを作成できます)。 - コードをモジュール化する コードを異なるファイルに分割すれば、読みやすさが向上します。そのためには、共通の目標を達成するために連携するフローをグループ化するか、特定の機能的条件に従ってコードをグループ化します。 - 短いフローを記述する 長いフローは理解やコーディング、維持が難しくなる場合があるため、避けるのが得策です。ユニットテストの観点から見ると、長いフローでは 1 つのポイントからトリガーできるシナリオが多すぎるため、1 つのシナリオを検証するために非常に複雑な評価を実行する必要があるということになります。 - 実行環境を定義する プレースホルダーを使用してコードをパラメーター化します。この通常のユースケースには、DB や HTTP などのアウトバウンドエンドポイントのアドレスが含まれます。プレースホルダーを使用することで、テスト (ユニットまたはインテグレーション) 実行時に実際のアドレスを変更でき、環境 (DEV/QA/UAT/PROD) 間でコードを昇格させるのが容易になります。 ## [](#テスト作成のベストプラクティス)テスト作成のベストプラクティス - 読みやすく維持しやすくなるようにテストを作成します。 - テストが失敗したときに確認する内容に従ってテストに名前を付けます。 - テストが失敗したときに誤って記述されたエラーメッセージや曖昧なエラーメッセージが表示されないように、失敗時にテストによってスローされるわかりやすい名前を使用します。 - 長いフローは理解しにくくなるため、使用を避けます。 - カバーされるシナリオと失敗の条件が明示的になるようにテストをコーディングします。 ## [](#関連情報)関連情報 - [MUnit テスト構造の基礎](https://docs.mulesoft.com/munit/latest/munit-test-concept) - [MUnit の例](https://docs.mulesoft.com/munit/latest/munit-cookbook) # Mule アプリケーションのテスト Mule アプリケーション用に自動化されたテストの包括的なスイートを構築すれば、ローカル環境でのテスト中にアプリケーション内の回帰や互換性のない変更を検出できます。MUnit は Mule テストフレームワークであり、​_ユニット_​テスト、​_インテグレーション_​テスト、​_機能_​テストを使用して、Mule アプリケーションのテストを容易に自動化できます。MUnit には、分離環境でコードのユニットをテストできるプロセッサーモックフレームワークなど、一連のツールも用意されています。 詳細は、​[MUnit](https://docs.mulesoft.com/munit/latest/)​ のドキュメントを参照してください。 アプリケーションを作成するときは、コードのモジュール化などのベストプラクティスに従い、コードのテストが容易になるように短いフローを記述します。問題を識別して解決しやすくなるように、わかりやすい名前とエラーメッセージを使用して読みやすく維持しやすいテストを作成します。 Anypoint Studio のテストレコーダー (ベータ) を使用すると、処理フローを記録してから、捕捉されたイベントに基づいてユニットテストを設定できます。 詳細と例は、​[「Studio のテストレコーダー」](https://docs.mulesoft.com/munit/latest/test-recorder)​を参照してください。 アプリケーションのロジックおよび動作をテストしたら、Mule Runtime Engine (Mule) をプロファイリングして Mule アプリケーションのパフォーマンスをテストできます。このプロセスにより、Mule アプリケーションやカスタム Mule 拡張機能でのメモリやパフォーマンスに関連した問題を識別しやすくなります。Mule をプロファイリングするには、Java プロファイラをオンプレミス Mule インスタンスに読み込む必要があります。 詳細な手順は、​[「Mule のプロファイリング」](https://docs.mulesoft.com/jp/mule-runtime/4.5/profiling-mule)​を参照してください。 ## [](#ユニットテスト)ユニットテスト ユニットテストの概念はプログラミングのパラダイムに応じて異なりますが、その中核的な概念は常に​_ソースコードの各ユニットの正しさを検証すること_​です。 ユニットテストのコンテキストでは、コードのユニットとはアプリケーションのテスト可能な最小の部分を指します。アプリケーションのテスト可能な最小の部分の実際の構成要素は、アプリケーションに応じて異なります。Mule アプリケーションの場合、テスト可能な最小の部分とは Mule フローまたはサブフローです。 開発者として、テストするコードが他のコードのユニットまたはコンポーネントとやりとりするかどうかを評価し、必ずテスト対象のコードのユニットを分離するようにユニットテストをデザインする必要があります。 分離により、テストに失敗した場合は、その原因が他のコードやコンポーネントではなくテスト対象のコードに関連するようにできます。 対象コードユニットを分離するには、MUnit が提供する ​`mock-when`​ プロセッサーなどのツールを使用します。 `mock-when`​ プロセッサーの使用例については、​[「Foreach プロセッサーの前および内部のメッセージのモック」](https://docs.mulesoft.com/munit/latest/mock-before-after-foreach-cookbook)​を参照してください。 ## [](#インテグレーションテスト)インテグレーションテスト コードのユニットが組み合わさって実際のアプリケーションを構成するため、これらのユニットを正常にテストしたら、インテグレーションテストを使用してアプリケーション全体をテストする準備が整います。 インテグレーションテストの目的は、​_異なるコードのユニットおよびモジュールが意図したとおりに連携して機能することを検証すること_​です。 アプリケーションの性質に応じて、インテグレーションテストに ​_Sandbox_​ テスト環境が必要になる場合もあります。これにより、本番のアプリケーション環境の外部で分離されたテスト評価を行うことができます。意図した結果を得るには、Sandbox のデータの状態がテストに適切であることを確認する必要があります。この検証は、インテグレーションテストを実行する前後に実行します。 ## [](#機能テスト)機能テスト 機能テストでは、Mule アプリケーション全体に想定されるユースケースをテストします。 たとえば、2 つのシステム間の双方向同期を維持するための Mule アプリケーションをテストするために、各システムでエントリを作成し、もう一方での複製を検証するテストケースをデザインできます。または、バッチ処理アプリケーションをテストする場合は、典型的な一連の情報を使用してテストを実行し、バッチの結果を検証できます。最後に、サービスオーケストレーションをテストするには、フローの一端でイベントを生成し、イベントがさまざまなサービスを通過した後に、もう一端で結果をテストすることができます。 インテグレーションテストの場合と同様、機能テストケースはテスト専用の環境プロパティおよびサービスのバージョンを使用して実行します。 ## [](#テスト可能なコードの記述)テスト可能なコードの記述 コードをモジュール化して実行環境を定義すれば、テストがきわめて容易になります (さらに、より設定項目が多く、拡張可能で読みやすいアプリケーションを作成できます)。 - コードをモジュール化する コードを異なるファイルに分割すれば、読みやすさが向上します。そのためには、共通の目標を達成するために連携するフローをグループ化するか、特定の機能的条件に従ってコードをグループ化します。 - 短いフローを記述する 長いフローは理解やコーディング、維持が難しくなる場合があるため、避けるのが得策です。ユニットテストの観点から見ると、長いフローでは 1 つのポイントからトリガーできるシナリオが多すぎるため、1 つのシナリオを検証するために非常に複雑な評価を実行する必要があるということになります。 - 実行環境を定義する プレースホルダーを使用してコードをパラメーター化します。この通常のユースケースには、DB や HTTP などのアウトバウンドエンドポイントのアドレスが含まれます。プレースホルダーを使用することで、テスト (ユニットまたはインテグレーション) 実行時に実際のアドレスを変更でき、環境 (DEV/QA/UAT/PROD) 間でコードを昇格させるのが容易になります。 ## [](#テスト作成のベストプラクティス)テスト作成のベストプラクティス - 読みやすく維持しやすくなるようにテストを作成します。 - テストが失敗したときに確認する内容に従ってテストに名前を付けます。 - テストが失敗したときに誤って記述されたエラーメッセージや曖昧なエラーメッセージが表示されないように、失敗時にテストによってスローされるわかりやすい名前を使用します。 - 長いフローは理解しにくくなるため、使用を避けます。 - カバーされるシナリオと失敗の条件が明示的になるようにテストをコーディングします。 ## [](#関連情報)関連情報 - [MUnit テスト構造の基礎](https://docs.mulesoft.com/munit/latest/munit-test-concept) - [MUnit の例](https://docs.mulesoft.com/munit/latest/munit-cookbook) # Mule アプリケーションのテスト Mule アプリケーション用に自動化されたテストの包括的なスイートを構築すれば、ローカル環境でのテスト中にアプリケーション内の回帰や互換性のない変更を検出できます。MUnit は Mule テストフレームワークであり、​_ユニット_​テスト、​_インテグレーション_​テスト、​_機能_​テストを使用して、Mule アプリケーションのテストを容易に自動化できます。MUnit には、分離環境でコードのユニットをテストできるプロセッサーモックフレームワークなど、一連のツールも用意されています。 詳細は、​[MUnit](https://docs.mulesoft.com/munit/latest/)​ のドキュメントを参照してください。 アプリケーションを作成するときは、コードのモジュール化などのベストプラクティスに従い、コードのテストが容易になるように短いフローを記述します。問題を識別して解決しやすくなるように、わかりやすい名前とエラーメッセージを使用して読みやすく維持しやすいテストを作成します。 Anypoint Studio のテストレコーダー (ベータ) を使用すると、処理フローを記録してから、取得されたイベントに基づいてユニットテストを設定できます。 詳細と例は、​[「Studio のテストレコーダー」](https://docs.mulesoft.com/munit/latest/test-recorder)​を参照してください。 アプリケーションのロジックおよび動作をテストしたら、Mule Runtime Engine (Mule) をプロファイリングして Mule アプリケーションのパフォーマンスをテストできます。このプロセスにより、Mule アプリケーションやカスタム Mule 拡張機能でのメモリやパフォーマンスに関連した問題を識別しやすくなります。Mule をプロファイリングするには、Java プロファイラーをオンプレミス Mule インスタンスに読み込む必要があります。 詳細な手順は、​[「Mule のプロファイリング」](https://docs.mulesoft.com/jp/mule-runtime/4.6/profiling-mule)​を参照してください。 ## [](#ユニットテスト)ユニットテスト ユニットテストの概念はプログラミングのパラダイムに応じて異なりますが、その中核的な概念は常に​_ソースコードの各ユニットの正しさを検証すること_​です。 ユニットテストのコンテキストでは、コードのユニットとはアプリケーションのテスト可能な最小の部分を指します。アプリケーションのテスト可能な最小の部分の実際の構成要素は、アプリケーションに応じて異なります。Mule アプリケーションの場合、テスト可能な最小の部分とは Mule フローまたはサブフローです。 開発者として、テストするコードが他のコードのユニットまたはコンポーネントとやりとりするかどうかを評価し、必ずテスト対象のコードのユニットを分離するようにユニットテストをデザインする必要があります。 分離により、テストに失敗した場合は、その原因が他のコードやコンポーネントではなくテスト対象のコードに関連するようにできます。 対象コードユニットを分離するには、MUnit が提供する ​`mock-when`​ プロセッサーなどのツールを使用します。 `mock-when`​ プロセッサーの使用例については、​[「Foreach プロセッサーの前および内部のメッセージのモック」](https://docs.mulesoft.com/munit/latest/mock-before-after-foreach-cookbook)​を参照してください。 ## [](#インテグレーションテスト)インテグレーションテスト コードのユニットが組み合わさって実際のアプリケーションを構成するため、これらのユニットを正常にテストしたら、インテグレーションテストを使用してアプリケーション全体をテストする準備が整います。 インテグレーションテストの目的は、​_異なるコードのユニットおよびモジュールが意図したとおりに連携して機能することを検証すること_​です。 アプリケーションの性質に応じて、インテグレーションテストに ​_Sandbox_​ テスト環境が必要になる場合もあります。これにより、本番のアプリケーション環境の外部で分離されたテスト評価を行うことができます。意図した結果を得るには、Sandbox のデータの状態がテストに適切であることを確認する必要があります。この検証は、インテグレーションテストを実行する前後に実行します。 ## [](#機能テスト)機能テスト 機能テストでは、Mule アプリケーション全体に想定されるユースケースをテストします。 たとえば、2 つのシステム間の双方向同期を維持するための Mule アプリケーションをテストするために、各システムでエントリを作成し、もう一方での複製を検証するテストケースをデザインできます。または、バッチ処理アプリケーションをテストする場合は、典型的な一連の情報を使用してテストを実行し、バッチの結果を検証できます。最後に、サービスオーケストレーションをテストするには、フローの一端でイベントを生成し、イベントがさまざまなサービスを通過した後に、もう一端で結果をテストすることができます。 インテグレーションテストの場合と同様、機能テストケースはテスト専用の環境プロパティおよびサービスのバージョンを使用して実行します。 ## [](#テスト可能なコードの記述)テスト可能なコードの記述 コードをモジュール化して実行環境を定義すれば、テストがきわめて容易になります (さらに、より設定項目が多く、拡張可能で読みやすいアプリケーションを作成できます)。 - コードをモジュール化する コードを異なるファイルに分割すれば、読みやすさが向上します。そのためには、共通の目標を達成するために連携するフローをグループ化するか、特定の機能的条件に従ってコードをグループ化します。 - 短いフローを記述する 長いフローは理解やコーディング、維持が難しくなる場合があるため、避けるのが得策です。ユニットテストの観点から見ると、長いフローでは 1 つのポイントからトリガーできるシナリオが多すぎるため、1 つのシナリオを検証するために非常に複雑な評価を実行する必要があるということになります。 - 実行環境を定義する プレースホルダーを使用してコードをパラメーター化します。この通常のユースケースには、DB や HTTP などのアウトバウンドエンドポイントのアドレスが含まれます。プレースホルダーを使用することで、テスト (ユニットまたはインテグレーション) 実行時に実際のアドレスを変更でき、環境 (DEV/QA/UAT/PROD) 間でコードを昇格させるのが容易になります。 ## [](#テスト作成のベストプラクティス)テスト作成のベストプラクティス - 読みやすく維持しやすくなるようにテストを作成します。 - テストが失敗したときに確認する内容に従ってテストに名前を付けます。 - テストが失敗したときに誤って記述されたエラーメッセージや曖昧なエラーメッセージが表示されないように、失敗時にテストによってスローされるわかりやすい名前を使用します。 - 長いフローは理解しにくくなるため、使用を避けます。 - カバーされるシナリオと失敗の条件が明示的になるようにテストをコーディングします。 ## [](#関連情報)関連情報 - [MUnit テスト構造の基礎](https://docs.mulesoft.com/munit/latest/munit-test-concept) - [MUnit の例](https://docs.mulesoft.com/munit/latest/munit-cookbook) # Mule アプリケーションのテスト Mule アプリケーション用に自動化されたテストの包括的なスイートを構築すれば、ローカル環境でのテスト中にアプリケーション内の回帰や互換性のない変更を検出できます。MUnit は Mule テストフレームワークであり、​_ユニット_​テスト、​_インテグレーション_​テスト、​_機能_​テストを使用して、Mule アプリケーションのテストを容易に自動化できます。MUnit には、分離環境でコードのユニットをテストできるプロセッサーモックフレームワークなど、一連のツールも用意されています。 詳細は、​[MUnit](https://docs.mulesoft.com/munit/latest/)​ のドキュメントを参照してください。 アプリケーションを作成するときは、コードのモジュール化などのベストプラクティスに従い、コードのテストが容易になるように短いフローを記述します。問題を識別して解決しやすくなるように、わかりやすい名前とエラーメッセージを使用して読みやすく維持しやすいテストを作成します。 Anypoint Studio のテストレコーダー (ベータ) を使用すると、処理フローを記録してから、捕捉されたイベントに基づいてユニットテストを設定できます。 詳細と例は、​[「Studio のテストレコーダー」](https://docs.mulesoft.com/munit/latest/test-recorder)​を参照してください。 アプリケーションのロジックおよび動作をテストしたら、Mule Runtime Engine (Mule) をプロファイリングして Mule アプリケーションのパフォーマンスをテストできます。このプロセスにより、Mule アプリケーションやカスタム Mule 拡張機能でのメモリやパフォーマンスに関連した問題を識別しやすくなります。Mule をプロファイリングするには、Java プロファイラーをオンプレミス Mule インスタンスに読み込む必要があります。 詳細な手順は、​[「Mule のプロファイリング」](https://docs.mulesoft.com/jp/mule-runtime/4.7/profiling-mule)​を参照してください。 ## [](#ユニットテスト)ユニットテスト ユニットテストの概念はプログラミングのパラダイムに応じて異なりますが、その中核的な概念は常に​_ソースコードの各ユニットの正しさを検証すること_​です。 ユニットテストのコンテキストでは、コードのユニットとはアプリケーションのテスト可能な最小の部分を指します。アプリケーションのテスト可能な最小の部分の実際の構成要素は、アプリケーションに応じて異なります。Mule アプリケーションの場合、テスト可能な最小の部分とは Mule フローまたはサブフローです。 開発者として、テストするコードが他のコードのユニットまたはコンポーネントとやりとりするかどうかを評価し、必ずテスト対象のコードのユニットを分離するようにユニットテストをデザインする必要があります。 分離により、テストに失敗した場合は、その原因が他のコードやコンポーネントではなくテスト対象のコードに関連するようにできます。 対象コードユニットを分離するには、MUnit が提供する ​`mock-when`​ プロセッサーなどのツールを使用します。 `mock-when`​ プロセッサーの使用例については、​[「Foreach プロセッサーの前および内部のメッセージのモック」](https://docs.mulesoft.com/munit/latest/mock-before-after-foreach-cookbook)​を参照してください。 ## [](#インテグレーションテスト)インテグレーションテスト コードのユニットが組み合わさって実際のアプリケーションを構成するため、これらのユニットを正常にテストしたら、インテグレーションテストを使用してアプリケーション全体をテストする準備が整います。 インテグレーションテストの目的は、​_異なるコードのユニットおよびモジュールが意図したとおりに連携して機能することを検証すること_​です。 アプリケーションの性質に応じて、インテグレーションテストに ​_Sandbox_​ テスト環境が必要になる場合もあります。これにより、本番のアプリケーション環境の外部で分離されたテスト評価を行うことができます。意図した結果を得るには、Sandbox のデータの状態がテストに適切であることを確認する必要があります。この検証は、インテグレーションテストを実行する前後に実行します。 ## [](#機能テスト)機能テスト 機能テストでは、Mule アプリケーション全体に想定されるユースケースをテストします。 たとえば、2 つのシステム間の双方向同期を維持するための Mule アプリケーションをテストするために、各システムでエントリを作成し、もう一方での複製を検証するテストケースをデザインできます。または、バッチ処理アプリケーションをテストする場合は、典型的な一連の情報を使用してテストを実行し、バッチの結果を検証できます。最後に、サービスオーケストレーションをテストするには、フローの一端でイベントを生成し、イベントがさまざまなサービスを通過した後に、もう一端で結果をテストすることができます。 インテグレーションテストの場合と同様、機能テストケースはテスト専用の環境プロパティおよびサービスのバージョンを使用して実行します。 ## [](#テスト可能なコードの記述)テスト可能なコードの記述 コードをモジュール化して実行環境を定義すれば、テストがきわめて容易になります (さらに、より設定項目が多く、拡張可能で読みやすいアプリケーションを作成できます)。 - コードをモジュール化する コードを異なるファイルに分割すれば、読みやすさが向上します。そのためには、共通の目標を達成するために連携するフローをグループ化するか、特定の機能的条件に従ってコードをグループ化します。 - 短いフローを記述する 長いフローは理解やコーディング、維持が難しくなる場合があるため、避けるのが得策です。ユニットテストの観点から見ると、長いフローでは 1 つのポイントからトリガーできるシナリオが多すぎるため、1 つのシナリオを検証するために非常に複雑な評価を実行する必要があるということになります。 - 実行環境を定義する プレースホルダーを使用してコードをパラメーター化します。この通常のユースケースには、DB や HTTP などのアウトバウンドエンドポイントのアドレスが含まれます。プレースホルダーを使用することで、テスト (ユニットまたはインテグレーション) 実行時に実際のアドレスを変更でき、環境 (DEV/QA/UAT/PROD) 間でコードを昇格させるのが容易になります。 ## [](#テスト作成のベストプラクティス)テスト作成のベストプラクティス - 読みやすく維持しやすくなるようにテストを作成します。 - テストが失敗したときに確認する内容に従ってテストに名前を付けます。 - テストが失敗したときに誤って記述されたエラーメッセージや曖昧なエラーメッセージが表示されないように、失敗時にテストによってスローされるわかりやすい名前を使用します。 - 長いフローは理解しにくくなるため、使用を避けます。 - カバーされるシナリオと失敗の条件が明示的になるようにテストをコーディングします。 ## [](#関連情報)関連情報 - [MUnit テスト構造の基礎](https://docs.mulesoft.com/munit/latest/munit-test-concept) - [MUnit の例](https://docs.mulesoft.com/munit/latest/munit-cookbook) # Mule アプリケーションのテスト Mule アプリケーション用に自動化されたテストの包括的なスイートを構築すれば、ローカル環境でのテスト中にアプリケーション内の回帰や互換性のない変更を検出できます。MUnit は Mule テストフレームワークであり、​_ユニット_​テスト、​_インテグレーション_​テスト、​_機能_​テストを使用して、Mule アプリケーションのテストを容易に自動化できます。MUnit には、分離環境でコードのユニットをテストできるプロセッサーモックフレームワークなど、一連のツールも用意されています。 詳細は、​[MUnit](https://docs.mulesoft.com/munit/latest/)​ のドキュメントを参照してください。 アプリケーションを作成するときは、コードのモジュール化などのベストプラクティスに従い、コードのテストが容易になるように短いフローを記述します。問題を識別して解決しやすくなるように、わかりやすい名前とエラーメッセージを使用して読みやすく維持しやすいテストを作成します。 Anypoint Studio のテストレコーダー (ベータ) を使用すると、処理フローを記録してから、捕捉されたイベントに基づいてユニットテストを設定できます。 詳細と例は、​[「Studio のテストレコーダー」](https://docs.mulesoft.com/munit/latest/test-recorder)​を参照してください。 アプリケーションのロジックおよび動作をテストしたら、Mule Runtime Engine (Mule) をプロファイリングして Mule アプリケーションのパフォーマンスをテストできます。このプロセスにより、Mule アプリケーションやカスタム Mule 拡張機能でのメモリやパフォーマンスに関連した問題を識別しやすくなります。Mule をプロファイリングするには、Java プロファイラーをオンプレミス Mule インスタンスに読み込む必要があります。 詳細な手順は、​[「Mule のプロファイリング」](https://docs.mulesoft.com/jp/mule-runtime/4.8/profiling-mule)​を参照してください。 ## [](#ユニットテスト)ユニットテスト ユニットテストの概念はプログラミングのパラダイムに応じて異なりますが、その中核的な概念は常に​_ソースコードの各ユニットの正しさを検証すること_​です。 ユニットテストのコンテキストでは、コードのユニットとはアプリケーションのテスト可能な最小の部分を指します。アプリケーションのテスト可能な最小の部分の実際の構成要素は、アプリケーションに応じて異なります。Mule アプリケーションの場合、テスト可能な最小の部分とは Mule フローまたはサブフローです。 開発者として、テストするコードが他のコードのユニットまたはコンポーネントとやりとりするかどうかを評価し、必ずテスト対象のコードのユニットを分離するようにユニットテストをデザインする必要があります。 分離により、テストに失敗した場合は、その原因が他のコードやコンポーネントではなくテスト対象のコードに関連するようにできます。 対象コードユニットを分離するには、MUnit が提供する ​`mock-when`​ プロセッサーなどのツールを使用します。 `mock-when`​ プロセッサーの使用例については、​[「Foreach プロセッサーの前および内部のメッセージのモック」](https://docs.mulesoft.com/munit/latest/mock-before-after-foreach-cookbook)​を参照してください。 ## [](#インテグレーションテスト)インテグレーションテスト コードのユニットが組み合わさって実際のアプリケーションを構成するため、これらのユニットを正常にテストしたら、インテグレーションテストを使用してアプリケーション全体をテストする準備が整います。 インテグレーションテストの目的は、​_異なるコードのユニットおよびモジュールが意図したとおりに連携して機能することを検証すること_​です。 アプリケーションの性質に応じて、インテグレーションテストに ​_Sandbox_​ テスト環境が必要になる場合もあります。これにより、本番のアプリケーション環境の外部で分離されたテスト評価を行うことができます。意図した結果を得るには、Sandbox のデータの状態がテストに適切であることを確認する必要があります。この検証は、インテグレーションテストを実行する前後に実行します。 ## [](#機能テスト)機能テスト 機能テストでは、Mule アプリケーション全体に想定されるユースケースをテストします。 たとえば、2 つのシステム間の双方向同期を維持するための Mule アプリケーションをテストするために、各システムでエントリを作成し、もう一方での複製を検証するテストケースをデザインできます。または、バッチ処理アプリケーションをテストする場合は、典型的な一連の情報を使用してテストを実行し、バッチの結果を検証できます。最後に、サービスオーケストレーションをテストするには、フローの一端でイベントを生成し、イベントがさまざまなサービスを通過した後に、もう一端で結果をテストすることができます。 インテグレーションテストの場合と同様、機能テストケースはテスト専用の環境プロパティおよびサービスのバージョンを使用して実行します。 ## [](#テスト可能なコードの記述)テスト可能なコードの記述 コードをモジュール化して実行環境を定義すれば、テストがきわめて容易になります (さらに、より設定項目が多く、拡張可能で読みやすいアプリケーションを作成できます)。 - コードをモジュール化する コードを異なるファイルに分割すれば、読みやすさが向上します。そのためには、共通の目標を達成するために連携するフローをグループ化するか、特定の機能的条件に従ってコードをグループ化します。 - 短いフローを記述する 長いフローは理解やコーディング、維持が難しくなる場合があるため、避けるのが得策です。ユニットテストの観点から見ると、長いフローでは 1 つのポイントからトリガーできるシナリオが多すぎるため、1 つのシナリオを検証するために非常に複雑な評価を実行する必要があるということになります。 - 実行環境を定義する プレースホルダーを使用してコードをパラメーター化します。この通常のユースケースには、DB や HTTP などのアウトバウンドエンドポイントのアドレスが含まれます。プレースホルダーを使用することで、テスト (ユニットまたはインテグレーション) 実行時に実際のアドレスを変更でき、環境 (DEV/QA/UAT/PROD) 間でコードを昇格させるのが容易になります。 ## [](#テスト作成のベストプラクティス)テスト作成のベストプラクティス - 読みやすく維持しやすくなるようにテストを作成します。 - テストが失敗したときに確認する内容に従ってテストに名前を付けます。 - テストが失敗したときに誤って記述されたエラーメッセージや曖昧なエラーメッセージが表示されないように、失敗時にテストによってスローされるわかりやすい名前を使用します。 - 長いフローは理解しにくくなるため、使用を避けます。 - カバーされるシナリオと失敗の条件が明示的になるようにテストをコーディングします。 ## [](#関連情報)関連情報 - [MUnit テスト構造の基礎](https://docs.mulesoft.com/munit/latest/munit-test-concept) - [MUnit の例](https://docs.mulesoft.com/munit/latest/munit-cookbook) # Mule アプリケーションのテスト Mule アプリケーション用に自動化されたテストの包括的なスイートを構築すれば、ローカル環境でのテスト中にアプリケーション内の回帰や互換性のない変更を検出できます。MUnit は Mule テストフレームワークであり、​_ユニット_​テスト、​_インテグレーション_​テスト、​_機能_​テストを使用して、Mule アプリケーションのテストを容易に自動化できます。MUnit には、分離環境でコードのユニットをテストできるプロセッサーモックフレームワークなど、一連のツールも用意されています。 詳細は、​[MUnit](https://docs.mulesoft.com/munit/latest/)​ のドキュメントを参照してください。 アプリケーションを作成するときは、コードのモジュール化などのベストプラクティスに従い、コードのテストが容易になるように短いフローを記述します。問題を識別して解決しやすくなるように、わかりやすい名前とエラーメッセージを使用して読みやすく維持しやすいテストを作成します。 Anypoint Studio のテストレコーダー (ベータ) を使用すると、処理フローを記録してから、捕捉されたイベントに基づいてユニットテストを設定できます。 詳細と例は、​[「Studio のテストレコーダー」](https://docs.mulesoft.com/munit/latest/test-recorder)​を参照してください。 アプリケーションのロジックおよび動作をテストしたら、Mule Runtime Engine (Mule) をプロファイリングして Mule アプリケーションのパフォーマンスをテストできます。このプロセスにより、Mule アプリケーションやカスタム Mule 拡張機能でのメモリやパフォーマンスに関連した問題を識別しやすくなります。Mule をプロファイリングするには、Java プロファイラーをオンプレミス Mule インスタンスに読み込む必要があります。 詳細な手順は、​[「Mule のプロファイリング」](https://docs.mulesoft.com/jp/mule-runtime/4.9/profiling-mule)​を参照してください。 ## [](#ユニットテスト)ユニットテスト ユニットテストの概念はプログラミングのパラダイムに応じて異なりますが、その中核的な概念は常に​_ソースコードの各ユニットの正しさを検証すること_​です。 ユニットテストのコンテキストでは、コードのユニットとはアプリケーションのテスト可能な最小の部分を指します。アプリケーションのテスト可能な最小の部分の実際の構成要素は、アプリケーションに応じて異なります。Mule アプリケーションの場合、テスト可能な最小の部分とは Mule フローまたはサブフローです。 開発者として、テストするコードが他のコードのユニットまたはコンポーネントとやりとりするかどうかを評価し、必ずテスト対象のコードのユニットを分離するようにユニットテストをデザインする必要があります。 分離により、テストに失敗した場合は、その原因が他のコードやコンポーネントではなくテスト対象のコードに関連するようにできます。 対象コードユニットを分離するには、MUnit が提供する ​`mock-when`​ プロセッサーなどのツールを使用します。 `mock-when`​ プロセッサーの使用例については、​[「Foreach プロセッサーの前および内部のメッセージのモック」](https://docs.mulesoft.com/munit/latest/mock-before-after-foreach-cookbook)​を参照してください。 ## [](#インテグレーションテスト)インテグレーションテスト コードのユニットが組み合わさって実際のアプリケーションを構成するため、これらのユニットを正常にテストしたら、インテグレーションテストを使用してアプリケーション全体をテストする準備が整います。 インテグレーションテストの目的は、​_異なるコードのユニットおよびモジュールが意図したとおりに連携して機能することを検証すること_​です。 アプリケーションの性質に応じて、インテグレーションテストに ​_Sandbox_​ テスト環境が必要になる場合もあります。これにより、本番のアプリケーション環境の外部で分離されたテスト評価を行うことができます。意図した結果を得るには、Sandbox のデータの状態がテストに適切であることを確認する必要があります。この検証は、インテグレーションテストを実行する前後に実行します。 ## [](#機能テスト)機能テスト 機能テストでは、Mule アプリケーション全体に想定されるユースケースをテストします。 たとえば、2 つのシステム間の双方向同期を維持するための Mule アプリケーションをテストするために、各システムでエントリを作成し、もう一方での複製を検証するテストケースをデザインできます。または、バッチ処理アプリケーションをテストする場合は、典型的な一連の情報を使用してテストを実行し、バッチの結果を検証できます。最後に、サービスオーケストレーションをテストするには、フローの一端でイベントを生成し、イベントがさまざまなサービスを通過した後に、もう一端で結果をテストすることができます。 インテグレーションテストの場合と同様、機能テストケースはテスト専用の環境プロパティおよびサービスのバージョンを使用して実行します。 ## [](#テスト可能なコードの記述)テスト可能なコードの記述 コードをモジュール化して実行環境を定義すれば、テストがきわめて容易になります (さらに、より設定項目が多く、拡張可能で読みやすいアプリケーションを作成できます)。 - コードをモジュール化する コードを異なるファイルに分割すれば、読みやすさが向上します。そのためには、共通の目標を達成するために連携するフローをグループ化するか、特定の機能的条件に従ってコードをグループ化します。 - 短いフローを記述する 長いフローは理解やコーディング、維持が難しくなる場合があるため、避けるのが得策です。ユニットテストの観点から見ると、長いフローでは 1 つのポイントからトリガーできるシナリオが多すぎるため、1 つのシナリオを検証するために非常に複雑な評価を実行する必要があるということになります。 - 実行環境を定義する プレースホルダーを使用してコードをパラメーター化します。この通常のユースケースには、DB や HTTP などのアウトバウンドエンドポイントのアドレスが含まれます。プレースホルダーを使用することで、テスト (ユニットまたはインテグレーション) 実行時に実際のアドレスを変更でき、環境 (DEV/QA/UAT/PROD) 間でコードを昇格させるのが容易になります。 ## [](#テスト作成のベストプラクティス)テスト作成のベストプラクティス - 読みやすく維持しやすくなるようにテストを作成します。 - テストが失敗したときに確認する内容に従ってテストに名前を付けます。 - テストが失敗したときに誤って記述されたエラーメッセージや曖昧なエラーメッセージが表示されないように、失敗時にテストによってスローされるわかりやすい名前を使用します。 - 長いフローは理解しにくくなるため、使用を避けます。 - カバーされるシナリオと失敗の条件が明示的になるようにテストをコーディングします。 ## [](#関連情報)関連情報 - [MUnit テスト構造の基礎](https://docs.mulesoft.com/munit/latest/munit-test-concept) - [MUnit の例](https://docs.mulesoft.com/munit/latest/munit-cookbook) # Mule アプリケーションのデプロイ すべての Mule アプリケーションは Mule Runtime Engine インスタンスにデプロイされます。MuleSoft は、CloudHub、Anypoint Runtime Fabric、オンプレミス Mule インスタンスの 3 種類のデプロイメント対象をサポートします。 CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが管理します。 オンプレミスにアプリケーションをデプロイする場合は Mule Runtime Engine をインストールする必要があります。 オンプレミスへのデプロイメント特有の詳細については、​[「オンプロミスデプロイモデル」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-deployment-model)​を参照してください。 また、それぞれの対象にアプリケーションをデプロイするために使用できるツールも異なります。
デプロイメント対象 利用可能なデプロイメントツール Mule Runtime Engine のインストール

CloudHub

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub ワーカーがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

Anypoint Runtime Fabric

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Mule Maven プラグイン

  • Anypoint Runtime Fabric がデプロイプロセスの一貫として内部で Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

  • 使用するインフラストラクチャへの Anypoint Runtime Fabric のインストールは必要です。

オンプレミス

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • 使用するインフラストラクチャへの Mule Runtime Engine のインストールは必要です。

  • Mule インスタンスのインストールと設定はユーザーの責任となります。
Mule Runtime 4.3 の延長サポートが終了すると、CloudHub または CloudHub 2.0 環境にデプロイされた Mule アプリケーションが停止します。
## [](#関連情報)関連情報 - [CloudHub](https://docs.mulesoft.com/cloudhub/) - [Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/) - [Anypoint Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.3/shared-resources) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-high-availability-ha-clusters) # Mule アプリケーションのデプロイ すべての Mule アプリケーションは、Mule Runtime Engine インスタンスにデプロイして実行する必要があります。MuleSoft は、CloudHub、Anypoint Runtime Fabric、オンプレミス Mule インスタンスの 3 種類のデプロイメント対象をサポートします。 CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが自動的に管理します。 オンプレミスにアプリケーションをデプロイする場合は Mule Runtime Engine をインストールする必要があります。 オンプレミスへのデプロイメント特有の詳細については、​[「オンプロミスデプロイモデル」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-deployment-model)​を参照してください。 また、各デプロイメント対象にアプリケーションをデプロイするためにさまざまなツールを利用できます。
デプロイメント対象 利用可能なデプロイメントツール Mule Runtime Engine のインストール

CloudHub

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub ワーカーがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

CloudHub 2.0

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub レプリカがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

Anypoint Runtime Fabric

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Mule Maven プラグイン

  • Anypoint Runtime Fabric がデプロイプロセスの一貫として内部で Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

  • 使用するインフラストラクチャへの Anypoint Runtime Fabric のインストールは必要です。

オンプレミス

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • 使用するインフラストラクチャへの Mule Runtime Engine のインストールは必要です。

  • Mule インスタンスのインストールと設定はユーザーの責任となります。
Mule Runtime 4.4 の延長サポートが終了すると、CloudHub または CloudHub 2.0 環境にデプロイされた Mule アプリケーションが停止します。
## [](#関連情報)関連情報 - [CloudHub](https://docs.mulesoft.com/cloudhub/) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) - [Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/) - [Anypoint Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.4/shared-resources) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-high-availability-ha-clusters) # Mule アプリケーションのデプロイ すべての Mule アプリケーションは、Mule Runtime Engine インスタンスにデプロイして実行する必要があります。MuleSoft は、CloudHub、Anypoint Runtime Fabric、オンプレミス Mule インスタンスの 3 種類のデプロイメント対象をサポートします。 CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが自動的に管理します。 オンプレミスにアプリケーションをデプロイする場合は Mule Runtime Engine をインストールする必要があります。 オンプレミスへのデプロイメント特有の詳細については、​[「オンプレミスデプロイモデル」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-deployment-model)​を参照してください。 また、各デプロイメント対象にアプリケーションをデプロイするためにさまざまなツールを利用できます。
デプロイメント対象 利用可能なデプロイメントツール Mule Runtime Engine のインストール

CloudHub

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub ワーカーがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

CloudHub 2.0

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub レプリカがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

Anypoint Runtime Fabric

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Mule Maven プラグイン

  • Anypoint Runtime Fabric がデプロイプロセスの一貫として内部で Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

  • 使用するインフラストラクチャへの Anypoint Runtime Fabric のインストールは必要です。

オンプレミス

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • 使用するインフラストラクチャへの Mule Runtime Engine のインストールは必要です。

  • Mule インスタンスのインストールと設定はユーザーの責任となります。
## [](#関連情報)関連情報 - [CloudHub](https://docs.mulesoft.com/cloudhub/) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) - [Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/) - [Anypoint Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.5/shared-resources) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-high-availability-ha-clusters) # Mule アプリケーションのデプロイ すべての Mule アプリケーションは、Mule Runtime Engine インスタンスにデプロイして実行する必要があります。MuleSoft は、CloudHub、Anypoint Runtime Fabric、オンプレミス Mule インスタンスの 3 種類のデプロイメント対象をサポートします。 CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが自動的に管理します。 オンプレミスにアプリケーションをデプロイする場合は Mule Runtime Engine をインストールする必要があります。 オンプレミスへのデプロイメント特有の詳細については、​[「オンプロミスデプロイモデル」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-deployment-model)​を参照してください。 また、各デプロイメント対象にアプリケーションをデプロイするためにさまざまなツールを利用できます。
デプロイメント対象 利用可能なデプロイメントツール Mule Runtime Engine のインストール

CloudHub

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub ワーカーがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

CloudHub 2.0

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub レプリカがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

Anypoint Runtime Fabric

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Mule Maven プラグイン

  • Anypoint Runtime Fabric がデプロイプロセスの一貫として内部で Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

  • 使用するインフラストラクチャへの Anypoint Runtime Fabric のインストールは必要です。

オンプレミス

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • 使用するインフラストラクチャへの Mule Runtime Engine のインストールは必要です。

  • Mule インスタンスのインストールと設定はユーザーの責任となります。
## [](#関連情報)関連情報 - [CloudHub](https://docs.mulesoft.com/cloudhub/) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) - [Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/) - [Anypoint Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.6/shared-resources) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-high-availability-ha-clusters) # Mule アプリケーションのデプロイ すべての Mule アプリケーションは、Mule Runtime Engine インスタンスにデプロイして実行する必要があります。MuleSoft は、CloudHub、Anypoint Runtime Fabric、オンプレミス Mule インスタンスの 3 種類のデプロイメント対象をサポートします。 CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが自動的に管理します。 オンプレミスにアプリケーションをデプロイする場合は Mule Runtime Engine をインストールする必要があります。 オンプレミスへのデプロイメント特有の詳細については、​[「オンプロミスデプロイモデル」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-deployment-model)​を参照してください。 また、各デプロイメント対象にアプリケーションをデプロイするためにさまざまなツールを利用できます。
デプロイメント対象 利用可能なデプロイメントツール Mule Runtime Engine のインストール

CloudHub

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub ワーカーがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

CloudHub 2.0

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub レプリカがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

Anypoint Runtime Fabric

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Mule Maven プラグイン

  • Anypoint Runtime Fabric がデプロイプロセスの一貫として内部で Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

  • 使用するインフラストラクチャへの Anypoint Runtime Fabric のインストールは必要です。

オンプレミス

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • 使用するインフラストラクチャへの Mule Runtime Engine のインストールは必要です。

  • Mule インスタンスのインストールと設定はユーザーの責任となります。
## [](#関連情報)関連情報 - [CloudHub](https://docs.mulesoft.com/cloudhub/) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) - [Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/) - [Anypoint Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.7/shared-resources) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-high-availability-ha-clusters) # Mule アプリケーションのデプロイ すべての Mule アプリケーションは、Mule Runtime Engine インスタンスにデプロイして実行する必要があります。MuleSoft は、CloudHub、Anypoint Runtime Fabric、オンプレミス Mule インスタンスの 3 種類のデプロイメント対象をサポートします。 CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが自動的に管理します。 オンプレミスにアプリケーションをデプロイする場合は Mule Runtime Engine をインストールする必要があります。 オンプレミスへのデプロイメント特有の詳細については、​[「オンプロミスデプロイモデル」](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-deployment-model)​を参照してください。 また、各デプロイメント対象にアプリケーションをデプロイするためにさまざまなツールを利用できます。
デプロイメント対象 利用可能なデプロイメントツール Mule Runtime Engine のインストール

CloudHub

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub ワーカーがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

CloudHub 2.0

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub レプリカがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

Anypoint Runtime Fabric

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Mule Maven プラグイン

  • Anypoint Runtime Fabric がデプロイプロセスの一貫として内部で Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

  • 使用するインフラストラクチャへの Anypoint Runtime Fabric のインストールは必要です。

オンプレミス

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • 使用するインフラストラクチャへの Mule Runtime Engine のインストールは必要です。

  • Mule インスタンスのインストールと設定はユーザーの責任となります。
## [](#関連情報)関連情報 - [CloudHub](https://docs.mulesoft.com/cloudhub/) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) - [Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/) - [Anypoint Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.8/shared-resources) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-high-availability-ha-clusters) # Mule アプリケーションのデプロイ すべての Mule アプリケーションは、Mule Runtime Engine インスタンスにデプロイして実行する必要があります。MuleSoft は、CloudHub、Anypoint Runtime Fabric、オンプレミス Mule インスタンスの 3 種類のデプロイメント対象をサポートします。 CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが自動的に管理します。 オンプレミスにアプリケーションをデプロイする場合は Mule Runtime Engine をインストールする必要があります。 オンプレミスへのデプロイメント特有の詳細については、​[「オンプロミスデプロイモデル」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-deployment-model)​を参照してください。 また、各デプロイメント対象にアプリケーションをデプロイするためにさまざまなツールを利用できます。
デプロイメント対象 利用可能なデプロイメントツール Mule Runtime Engine のインストール

CloudHub

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub ワーカーがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

CloudHub 2.0

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • CloudHub レプリカがデプロイプロセスの一貫として Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

Anypoint Runtime Fabric

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Mule Maven プラグイン

  • Anypoint Runtime Fabric がデプロイプロセスの一貫として内部で Mule インスタンスを起動するため、Mule Runtime Engine のインストールは不要です。

  • 使用するインフラストラクチャへの Anypoint Runtime Fabric のインストールは必要です。

オンプレミス

  • Anypoint Studio

  • Anypoint Runtime Manager

  • Anypoint Platform Private Cloud Edition での Runtime Manager

  • Anypoint Platform CLI

  • Mule Maven プラグイン

  • 使用するインフラストラクチャへの Mule Runtime Engine のインストールは必要です。

  • Mule インスタンスのインストールと設定はユーザーの責任となります。
## [](#関連情報)関連情報 - [CloudHub](https://docs.mulesoft.com/cloudhub/) - [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/) - [Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/) - [Anypoint Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.9/shared-resources) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-high-availability-ha-clusters) # Mule アプリケーションの変数 変数は、Mule アプリケーションのフロー内で使用する各イベント値の保存に使用されます。保存されたデータは、オブジェクト、数値、文字列など、サポートされている任意のデータ型にすることができます。現在のメッセージ (​`message`​ キーワードを使用)、現在のメッセージペイロード (​`payload`​ キーワードを使用)、または現在のメッセージ属性のみ (​`attributes`​ キーワードを使用) を保存することもできます。値として DataWeave 式を使用することさえもできます。ただし、キーワード ​`vars`​ (​`vars.someOtherVar`​ など) は使用できません。 次の方法で変数を作成または更新できます。 - Set Variable コンポーネントを使用する。 - File Connector に対する Read 操作や Database Connector に対する Store 操作など、操作内から対象変数を使用する。 - DataWeave Transform コンポーネント (EE のみ) を使用する。 - Scripting コンポーネント (Scripting Module 内) を使用する。 削除することもできます。 - Remove Variable コンポーネントを使用する。 変数を作成したら、作成元の Mule フローのスコープ内でその変数にアクセスして使用できます。これには、Flow Ref コンポーネントを使用して結合されたフローも含まれます。 - `vars`​: 変数にアクセスするキーワード。たとえば、Mule コンポーネント (Logger など) の DataWeave 式、または操作の \[Input (入力)\] または \[Output (出力)\] パラメーターからアクセスします。変数の名前が ​`myVar`​ の場合、​`vars.myVar`​ のようにしてアクセスできます。 Mule イベント内の変数は、DataWeave スクリプトで定義された変数 (スクリプトのローカルでありその外部からはアクセスできない変数) とは異なります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-event) - [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.3/variable-transformer-reference) - [Flow Reference コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/flowref-about) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.3/target-variables) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # Mule アプリケーションの変数 変数は、Mule アプリケーションのフロー内で使用する各イベント値の保存に使用されます。保存されたデータは、オブジェクト、数値、文字列など、サポートされている任意のデータ型にすることができます。現在のメッセージ (​`message`​ キーワードを使用)、現在のメッセージペイロード (​`payload`​ キーワードを使用)、または現在のメッセージ属性のみ (​`attributes`​ キーワードを使用) を保存することもできます。値として DataWeave 式を使用することさえもできます。ただし、キーワード ​`vars`​ (​`vars.someOtherVar`​ など) は使用できません。 次の方法で変数を作成または更新できます。 - Set Variable コンポーネントを使用する。 - File Connector に対する Read 操作や Database Connector に対する Store 操作など、操作内から対象変数を使用する。 - DataWeave Transform コンポーネント (EE のみ) を使用する。 - Scripting コンポーネント (Scripting Module 内) を使用する。 削除することもできます。 - Remove Variable コンポーネントを使用する。 変数を作成したら、作成元の Mule フローのスコープ内でその変数にアクセスして使用できます。これには、Flow Ref コンポーネントを使用して結合されたフローも含まれます。 - `vars`​: 変数にアクセスするキーワード。たとえば、Mule コンポーネント (Logger など) の DataWeave 式、または操作の \[Input (入力)\] または \[Output (出力)\] パラメーターからアクセスします。変数の名前が ​`myVar`​ の場合、​`vars.myVar`​ のようにしてアクセスできます。 Mule イベント内の変数は、DataWeave スクリプトで定義された変数 (スクリプトのローカルでありその外部からはアクセスできない変数) とは異なります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-event) - [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.4/variable-transformer-reference) - [Flow Reference コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/flowref-about) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.4/target-variables) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # Mule アプリケーションの変数 変数は、Mule アプリケーションのフロー内で使用する各イベント値の保存に使用されます。保存されたデータは、オブジェクト、数値、文字列など、サポートされている任意のデータ型にすることができます。現在のメッセージ (​`message`​ キーワードを使用)、現在のメッセージペイロード (​`payload`​ キーワードを使用)、または現在のメッセージ属性のみ (​`attributes`​ キーワードを使用) を保存することもできます。値として DataWeave 式を使用することさえもできます。ただし、キーワード ​`vars`​ (​`vars.someOtherVar`​ など) は使用できません。 次の方法で変数を作成または更新できます。 - Set Variable コンポーネントを使用する。 - ファイルコネクタに対する Read 操作や Database Connector に対する Store 操作など、操作内から対象変数を使用する。 - DataWeave Transform コンポーネント (EE のみ) を使用する。 - Scripting コンポーネント (Scripting Module 内) を使用する。 削除することもできます。 - Remove Variable コンポーネントを使用する。 変数を作成したら、作成元の Mule フローのスコープ内でその変数にアクセスして使用できます。これには、Flow Ref コンポーネントを使用して結合されたフローも含まれます。 - `vars`​: 変数にアクセスするキーワード。たとえば、Mule コンポーネント (Logger など) の DataWeave 式、または操作の \[Input (入力)\] または \[Output (出力)\] パラメーターからアクセスします。変数の名前が ​`myVar`​ の場合、​`vars.myVar`​ のようにしてアクセスできます。 Mule イベント内の変数は、DataWeave スクリプトで定義された変数 (スクリプトのローカルでありその外部からはアクセスできない変数) とは異なります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-event) - [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.5/variable-transformer-reference) - [Flow Reference コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/flowref-about) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.5/target-variables) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # Mule アプリケーションの変数 変数は、Mule アプリケーションのフロー内で使用する各イベント値の保存に使用されます。保存されたデータは、オブジェクト、数値、文字列など、サポートされている任意のデータ型にすることができます。現在のメッセージ (​`message`​ キーワードを使用)、現在のメッセージペイロード (​`payload`​ キーワードを使用)、または現在のメッセージ属性のみ (​`attributes`​ キーワードを使用) を保存することもできます。値として DataWeave 式を使用することさえもできます。ただし、キーワード ​`vars`​ (​`vars.someOtherVar`​ など) は使用できません。 次の方法で変数を作成または更新できます。 - Set Variable コンポーネントを使用する。 - File Connector に対する Read 操作や Database Connector に対する Store 操作など、操作内から対象変数を使用する。 - DataWeave Transform コンポーネント (EE のみ) を使用する。 - Scripting コンポーネント (Scripting Module 内) を使用する。 削除することもできます。 - Remove Variable コンポーネントを使用する。 変数を作成したら、作成元の Mule フローのスコープ内でその変数にアクセスして使用できます。これには、Flow Ref コンポーネントを使用して結合されたフローも含まれます。 - `vars`​: 変数にアクセスするキーワード。たとえば、Mule コンポーネント (Logger など) の DataWeave 式、または操作の \[Input (入力)\] または \[Output (出力)\] パラメーターからアクセスします。変数の名前が ​`myVar`​ の場合、​`vars.myVar`​ のようにしてアクセスできます。 Mule イベント内の変数は、DataWeave スクリプトで定義された変数 (スクリプトのローカルでありその外部からはアクセスできない変数) とは異なります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-event) - [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.6/variable-transformer-reference) - [Flow Reference コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/flowref-about) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.6/target-variables) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # Mule アプリケーションの変数 変数は、Mule アプリケーションのフロー内で使用する各イベント値の保存に使用されます。保存されたデータは、オブジェクト、数値、文字列など、サポートされている任意のデータ型にすることができます。現在のメッセージ (​`message`​ キーワードを使用)、現在のメッセージペイロード (​`payload`​ キーワードを使用)、または現在のメッセージ属性のみ (​`attributes`​ キーワードを使用) を保存することもできます。値として DataWeave 式を使用することさえもできます。ただし、キーワード ​`vars`​ (​`vars.someOtherVar`​ など) は使用できません。 次の方法で変数を作成または更新できます。 - Set Variable コンポーネントを使用する。 - File Connector に対する Read 操作や Database Connector に対する Store 操作など、操作内から対象変数を使用する。 - DataWeave Transform コンポーネント (EE のみ) を使用する。 - Scripting コンポーネント (Scripting Module 内) を使用する。 削除することもできます。 - Remove Variable コンポーネントを使用する。 変数を作成したら、作成元の Mule フローのスコープ内でその変数にアクセスして使用できます。これには、Flow Ref コンポーネントを使用して結合されたフローも含まれます。 - `vars`​: 変数にアクセスするキーワード。たとえば、Mule コンポーネント (Logger など) の DataWeave 式、または操作の \[Input (入力)\] または \[Output (出力)\] パラメーターからアクセスします。変数の名前が ​`myVar`​ の場合、​`vars.myVar`​ のようにしてアクセスできます。 Mule イベント内の変数は、DataWeave スクリプトで定義された変数 (スクリプトのローカルでありその外部からはアクセスできない変数) とは異なります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-event) - [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.7/variable-transformer-reference) - [Flow Reference コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/flowref-about) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.7/target-variables) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # Mule アプリケーションの変数 変数は、Mule アプリケーションのフロー内で使用する各イベント値の保存に使用されます。保存されたデータは、オブジェクト、数値、文字列など、サポートされている任意のデータ型にすることができます。現在のメッセージ (​`message`​ キーワードを使用)、現在のメッセージペイロード (​`payload`​ キーワードを使用)、または現在のメッセージ属性のみ (​`attributes`​ キーワードを使用) を保存することもできます。値として DataWeave 式を使用することさえもできます。ただし、キーワード ​`vars`​ (​`vars.someOtherVar`​ など) は使用できません。 次の方法で変数を作成または更新できます。 - Set Variable コンポーネントを使用する。 - File Connector に対する Read 操作や Database Connector に対する Store 操作など、操作内から対象変数を使用する。 - DataWeave Transform コンポーネント (EE のみ) を使用する。 - Scripting コンポーネント (Scripting Module 内) を使用する。 削除することもできます。 - Remove Variable コンポーネントを使用する。 変数を作成したら、作成元の Mule フローのスコープ内でその変数にアクセスして使用できます。これには、Flow Ref コンポーネントを使用して結合されたフローも含まれます。 - `vars`​: 変数にアクセスするキーワード。たとえば、Mule コンポーネント (Logger など) の DataWeave 式、または操作の \[Input (入力)\] または \[Output (出力)\] パラメーターからアクセスします。変数の名前が ​`myVar`​ の場合、​`vars.myVar`​ のようにしてアクセスできます。 Mule イベント内の変数は、DataWeave スクリプトで定義された変数 (スクリプトのローカルでありその外部からはアクセスできない変数) とは異なります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-event) - [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.8/variable-transformer-reference) - [Flow Reference コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/flowref-about) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.8/target-variables) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # Mule アプリケーションの変数 変数は、Mule アプリケーションのフロー内で使用する各イベント値の保存に使用されます。保存されたデータは、オブジェクト、数値、文字列など、サポートされている任意のデータ型にすることができます。現在のメッセージ (​`message`​ キーワードを使用)、現在のメッセージペイロード (​`payload`​ キーワードを使用)、または現在のメッセージ属性のみ (​`attributes`​ キーワードを使用) を保存することもできます。値として DataWeave 式を使用することさえもできます。ただし、キーワード ​`vars`​ (​`vars.someOtherVar`​ など) は使用できません。 次の方法で変数を作成または更新できます。 - Set Variable コンポーネントを使用する。 - File Connector に対する Read 操作や Database Connector に対する Store 操作など、操作内から対象変数を使用する。 - DataWeave Transform コンポーネント (EE のみ) を使用する。 - Scripting コンポーネント (Scripting Module 内) を使用する。 削除することもできます。 - Remove Variable コンポーネントを使用する。 変数を作成したら、作成元の Mule フローのスコープ内でその変数にアクセスして使用できます。これには、Flow Ref コンポーネントを使用して結合されたフローも含まれます。 - `vars`​: 変数にアクセスするキーワード。たとえば、Mule コンポーネント (Logger など) の DataWeave 式、または操作の \[Input (入力)\] または \[Output (出力)\] パラメーターからアクセスします。変数の名前が ​`myVar`​ の場合、​`vars.myVar`​ のようにしてアクセスできます。 Mule イベント内の変数は、DataWeave スクリプトで定義された変数 (スクリプトのローカルでありその外部からはアクセスできない変数) とは異なります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-event) - [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.9/variable-transformer-reference) - [Flow Reference コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/flowref-about) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.9/target-variables) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # Mule アプリケーションの開発 Mule アプリケーションを作成してシステムインテグレーションを実行します。通常、アプリケーションは内部ソースや外部ソースからデータを読み込み、データを処理して必要な形式や構造に変換して、変換後のデータを格納または使用するシステムやサーバーに出力を書き込みます。 Mule アプリケーションは Mule Runtime Engine (Mule) で実行するように設定されています。Mule アプリケーションへの要求により、Mule は要求およびデータを Mule イベントでエンコードし、単一または複数のスレッドに渡します。 ## [](#mule-アプリケーション開発入門)Mule アプリケーション開発入門 Mule アプリケーションの開発を始めるには、以下のチュートリアルの手順に従ってください。 - [「Hello World」Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-app-dev-hellomule) シンプルな HTTP 要求-返信フローでユーザーとやり取りする Mule アプリケーションを作成します。 - [Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-app-tutorial) データベースからデータを取得して新しい構造に変換する Mule アプリケーションを作成します。 ## [](#mule-アプリケーションのビルディングブロック)Mule アプリケーションのビルディングブロック Mule アプリケーションは、コネクタ、モジュール、コンポーネントを使用して、データの読み込み、書き込み、処理を行います。 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) Anypoint Connector は、Mule アプリケーションから外部 API エンドポイントとやり取りしてデータを処理するコンポーネント (リスナーなど) を提供します。検証、Java、Spring、OAuth などのモジュールは、エンドポイントに直接接続せずに Mule アプリケーション内でデータを処理します。 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-components) コアコンポーネントは、フロー制御、エラー処理、ログ、バッチ処理など、アプリケーション内を流れるデータに対するプログラム操作をサポートします。 ## [](#dataweave-言語)DataWeave 言語 DataWeave は、Mule で式を作成するために使用される主言語です。 コネクタ、モジュール、コンポーネントでは、DataWeave を使用してデータ構造や出力形式にアクセスし、処理や変換を行ったり、Mule アプリケーション内で処理するデータを抽出したりできます。 実行時に、Mule はフローを実行するときに DataWeave 式を評価して、次のことを行います。 - 現在のメッセージを処理するために必要なデータの抽出 - メッセージ内の値の設定または操作 ## [](#flows)Mule フロー 基本的なフローアーキテクチャを理解することは、Mule アプリケーションを理解するための鍵です。 基本的に、すべての Mule フローにはメッセージを受信または処理する一連の Mule コンポーネントが含まれています。 ![Design Center での簡単なフロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/flow-example.png) Figure 1. Design Center での簡単なフロー 最もシンプルなレベルでは、フローは一連のプロセッサーです。フローに入ったメッセージは、さまざまなプロセッサーを通過します。一般的なフローでは、Mule アプリケーションはソース (HTTP Listener コンポーネントなど) を使用してメッセージを受信し、そのメッセージを新しい形式に変換し、何らかのビジネスロジックを処理してから、処理されたメッセージを外部システムに向けてそのシステムが読み取れる形式で記述します。 処理を管理しやすい単位に分割するために、通常、Mule アプリケーションには 1 つのフローではなく複数の相互に関係するフローが含まれています。1 つのフローから、他のフローを直接参照としてコールできます。 このトピックについての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-flows)​と​[「Mule コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-components)​を参照してください。 ### [](#ソース)ソース ソースコンポーネント (またはトリガー) は、フローの最初のコンポーネントです。このコンポーネントは、トリガーイベントを受信し、対応する Mule イベントを作成し、そのイベントを処理するためにフローの次のコンポーネントに転送します。 外部クライアントは、Mule フローでの処理をいくつかの通信プロトコルや方法でトリガーできます。たとえば、JMS、HTTP、FTP、JDBC、ファイルなどを使用できます。 Mule は、これらの通信プロトコルや方法を標準メッセージ形式に変換し、それをフローのプロセッサーに渡します。 Mule のソースは、標準プロトコルまたはサードパーティ API を使用して、特定の外部取得元に接続できます。また、Scheduler コンポーネントを設定することも可能です。一部のスケジューラーは、外部リソースの特定の変更 (外部リソースの新規ファイルやテーブル行など) へのポーリングを実行できます。フローをトリガーできるリスナーやコネクタ操作の例として、次のようなものがあります。 - 関連するコネクタでの HTTP、JMS、VM リスナー - Database Connector での On Table Row 操作 - File Connector や FTP Connector での On New or Updated File 操作 - スケジューラー [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のソースを作成することもできます。 ### [](#プロセッサー)プロセッサー ソースコンポーネントによってフローがトリガーされると、データはフロー内を通過し、後続のコンポーネントによって処理されます。デフォルトでは、Mule イベントを受信する各プロセッサーは、新しい Mule メッセージを返します。通常、このメッセージにはプロセッサーが返す属性セットとメッセージペイロードが含まれます。プロセッサーは、新しいメッセージを出力としてフロー内の次のプロセッサーに転送します。 Mule アプリケーションで使用できるプロセッサーには、次のものがあります。 - モジュールやコネクタからのコンポーネント たとえば、外部リソースからの読み込みや外部リソースへの書き込み、Mule アプリケーション内でのデータの検証などの操作があります。 一部の操作は、外部のリソースおよびサービス (Salesforce、Workday、ServiceNow などの多数の外部データベースやシステムを含む) や他の Mule アプリケーションへのクライアント要求を行うことができます。または、カスタムコードの実行、OAuth 設定のサポート、非同期キューを使用した通信の管理を実行できる操作もあります。他にも多くの操作が用意されています。 - コアコンポーネント コアコンポーネントは、データの転送、データ変換の実行、イベント処理中に発生したエラー処理など、Mule アプリケーション内のタスクを実行できます。 トランスフォーマー (Transform Message や Set Variable など) は、ノード間でデータを交換するために重要です。トランスフォーマーを使用することで、Mule は Mule イベント内のメッセージデータを別のアプリケーションやサービスが読み取れる形式に変換できます。 また、Mule ではメッセージのコンテンツ強化 (​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.3/target-variables)​を使用) も有効なため、追加データを取得して、メッセージに添付することができます。 [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のイベントプロセッサーを作成することもできます。 ## [](#セキュリティ)セキュリティ プロパティの暗号化、TLS 上でのセキュア通信の設定、OAuth 2.0 による認証のセットアップ、さらには暗号化や FIPS 準拠などの機能を使用することで、Mule アプリケーションを保護できます。 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.3/securing) ## [](#開発環境)開発環境 Mule アプリケーションは ​[Anypoint Studio](https://docs.mulesoft.com/studio/)​ (Eclipse ベースの IDE) を使用して、または上級者であれば自分の IDE で開発できます。 たとえば、Studio では、1 つ以上の XML ベースファイルを含むプロジェクトで Mule アプリケーションをビルドおよび設計します。Mule プロジェクトは、開発に必要なすべての連動関係をサポートします。Studio の ​[\[Package Explorer](https://docs.mulesoft.com/studio/#package-explorer)\]​ ビューには、Mule プロジェクトを構成するプロジェクトフォルダーとファイルが表示されます。 Studio は、Mule アプリケーションをビルド、実行、テストするための設計環境を提供します。 ## [](#version)Mule のバージョン設定 使用する Mule のバージョンによって、Mule アプリケーション、ドメイン、またはポリシーで実行できる内容と Mule との互換性がある機能や製品が決まります。 たとえば、Mule アプリケーションのフロー内を通過する Mule イベントを処理する​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-components)​は、Mule にバンドルされ、Mule と同じバージョンのコアモジュールの一部です。 [モジュール、コネクタ](https://docs.mulesoft.com/connectors/)​、DataWeave 言語、いくつかの MuleSoft 製品には、固有のバージョン設定システムがありますが、特定のバージョンの Mule と互換性があります。たとえば、DataWeave 2.0 と Studio 7.x は Mule 4.x Runtime Engine と互換性があり、DataWeave 1.0 と Studio 6.x は Mule 3.x Runtime Engine と互換性があります。Mule アプリケーションで使用するコネクタやモジュールが、Mule バージョンと互換性があることを確認する必要があります。 ## [](#関連情報)関連情報 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-message) - [Mule アプリケーションの変数](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-variables) - [Mule の設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-configuration) - [APIKit](https://docs.mulesoft.com/jp/apikit/latest/) # Mule アプリケーションの開発 Mule アプリケーションを作成してシステムインテグレーションを実行します。通常、アプリケーションは内部ソースや外部ソースからデータを読み込み、データを処理して必要な形式や構造に変換して、変換後のデータを格納または使用するシステムやサーバーに出力を書き込みます。 Mule アプリケーションは Mule Runtime Engine (Mule) で実行するように設定されています。Mule アプリケーションへの要求により、Mule は要求およびデータを Mule イベントでエンコードし、単一または複数のスレッドに渡します。 ## [](#mule-アプリケーション開発入門)Mule アプリケーション開発入門 Mule アプリケーションの開発を始めるには、以下のチュートリアルの手順に従ってください。 - [「Hello World」Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-app-dev-hellomule) シンプルな HTTP 要求-返信フローでユーザーとやり取りする Mule アプリケーションを作成します。 - [Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-app-tutorial) データベースからデータを取得して新しい構造に変換する Mule アプリケーションを作成します。 ## [](#mule-アプリケーションのビルディングブロック)Mule アプリケーションのビルディングブロック Mule アプリケーションは、コネクタ、モジュール、コンポーネントを使用して、データの読み込み、書き込み、処理を行います。 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) Anypoint Connector は、Mule アプリケーションから外部 API エンドポイントとやり取りしてデータを処理するコンポーネント (リスナーなど) を提供します。検証、Java、Spring、OAuth などのモジュールは、エンドポイントに直接接続せずに Mule アプリケーション内でデータを処理します。 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-components) コアコンポーネントは、フロー制御、エラー処理、ログ、バッチ処理など、アプリケーション内を流れるデータに対するプログラム操作をサポートします。 ## [](#dataweave-言語)DataWeave 言語 DataWeave は、Mule で式を作成するために使用される主言語です。 コネクタ、モジュール、コンポーネントでは、DataWeave を使用してデータ構造や出力形式にアクセスし、処理や変換を行ったり、Mule アプリケーション内で処理するデータを抽出したりできます。 実行時に、Mule はフローを実行するときに DataWeave 式を評価して、次のことを行います。 - 現在のメッセージを処理するために必要なデータの抽出 - メッセージ内の値の設定または操作 ## [](#flows)Mule フロー 基本的なフローアーキテクチャを理解することは、Mule アプリケーションを理解するための鍵です。 基本的に、すべての Mule フローにはメッセージを受信または処理する一連の Mule コンポーネントが含まれています。 ![Design Center での簡単なフロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/flow-example.png) Figure 1. Design Center での簡単なフロー 最もシンプルなレベルでは、フローは一連のプロセッサーです。フローに入ったメッセージは、さまざまなプロセッサーを通過します。一般的なフローでは、Mule アプリケーションはソース (HTTP Listener コンポーネントなど) を使用してメッセージを受信し、そのメッセージを新しい形式に変換し、何らかのビジネスロジックを処理してから、処理されたメッセージを外部システムに向けてそのシステムが読み取れる形式で記述します。 処理を管理しやすい単位に分割するために、通常、Mule アプリケーションには 1 つのフローではなく複数の相互に関係するフローが含まれています。1 つのフローから、他のフローを直接参照としてコールできます。 このトピックについての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-flows)​と​[「Mule コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-components)​を参照してください。 ### [](#ソース)ソース ソースコンポーネント (またはトリガー) は、フローの最初のコンポーネントです。このコンポーネントは、トリガーイベントを受信し、対応する Mule イベントを作成し、そのイベントを処理するためにフローの次のコンポーネントに転送します。 外部クライアントは、Mule フローでの処理をいくつかの通信プロトコルや方法でトリガーできます。たとえば、JMS、HTTP、FTP、JDBC、ファイルなどを使用できます。 Mule は、これらの通信プロトコルや方法を標準メッセージ形式に変換し、それをフローのプロセッサーに渡します。 Mule のソースは、標準プロトコルまたはサードパーティ API を使用して、特定の外部取得元に接続できます。また、Scheduler コンポーネントを設定することも可能です。一部のスケジューラーは、外部リソースの特定の変更 (外部リソースの新規ファイルやテーブル行など) へのポーリングを実行できます。フローをトリガーできるリスナーやコネクタ操作の例として、次のようなものがあります。 - 関連するコネクタでの HTTP、JMS、VM リスナー - Database Connector での On Table Row 操作 - File Connector や FTP Connector での On New or Updated File 操作 - スケジューラー [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のソースを作成することもできます。 ### [](#プロセッサー)プロセッサー ソースコンポーネントによってフローがトリガーされると、データはフロー内を通過し、後続のコンポーネントによって処理されます。デフォルトでは、Mule イベントを受信する各プロセッサーは、新しい Mule メッセージを返します。通常、このメッセージにはプロセッサーが返す属性セットとメッセージペイロードが含まれます。プロセッサーは、新しいメッセージを出力としてフロー内の次のプロセッサーに転送します。 Mule アプリケーションで使用できるプロセッサーには、次のものがあります。 - モジュールやコネクタからのコンポーネント たとえば、外部リソースからの読み込みや外部リソースへの書き込み、Mule アプリケーション内でのデータの検証などの操作があります。 一部の操作は、外部のリソースおよびサービス (Salesforce、Workday、ServiceNow などの多数の外部データベースやシステムを含む) や他の Mule アプリケーションへのクライアント要求を行うことができます。または、カスタムコードの実行、OAuth 設定のサポート、非同期キューを使用した通信の管理を実行できる操作もあります。他にも多くの操作が用意されています。 - コアコンポーネント コアコンポーネントは、データの転送、データ変換の実行、イベント処理中に発生したエラー処理など、Mule アプリケーション内のタスクを実行できます。 トランスフォーマー (Transform Message や Set Variable など) は、ノード間でデータを交換するために重要です。トランスフォーマーを使用することで、Mule は Mule イベント内のメッセージデータを別のアプリケーションやサービスが読み取れる形式に変換できます。 また、Mule ではメッセージのコンテンツ強化 (​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.4/target-variables)​を使用) も有効なため、追加データを取得して、メッセージに添付することができます。 [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のイベントプロセッサーを作成することもできます。 ## [](#セキュリティ)セキュリティ プロパティの暗号化、TLS 上でのセキュア通信の設定、OAuth 2.0 による認証のセットアップ、さらには暗号化や FIPS 準拠などの機能を使用することで、Mule アプリケーションを保護できます。 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.4/securing) ## [](#開発環境)開発環境 Mule アプリケーションは ​[Anypoint Studio](https://docs.mulesoft.com/studio/)​ (Eclipse ベースの IDE) を使用して、または上級者であれば自分の IDE で開発できます。 たとえば、Studio では、1 つ以上の XML ベースファイルを含むプロジェクトで Mule アプリケーションをビルドおよび設計します。Mule プロジェクトは、開発に必要なすべての連動関係をサポートします。Studio の ​[\[Package Explorer](https://docs.mulesoft.com/studio/#package-explorer)\]​ ビューには、Mule プロジェクトを構成するプロジェクトフォルダーとファイルが表示されます。 Studio は、Mule アプリケーションをビルド、実行、テストするための設計環境を提供します。 ## [](#version)Mule のバージョン設定 使用する Mule のバージョンによって、Mule アプリケーション、ドメイン、またはポリシーで実行できる内容と Mule との互換性がある機能や製品が決まります。 たとえば、Mule アプリケーションのフロー内を通過する Mule イベントを処理する​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-components)​は、Mule にバンドルされ、Mule と同じバージョンのコアモジュールの一部です。 [モジュール、コネクタ](https://docs.mulesoft.com/connectors/)​、DataWeave 言語、いくつかの MuleSoft 製品には、固有のバージョン設定システムがありますが、特定のバージョンの Mule と互換性があります。たとえば、DataWeave 2.0 と Studio 7.x は Mule 4.x Runtime Engine と互換性があり、DataWeave 1.0 と Studio 6.x は Mule 3.x Runtime Engine と互換性があります。Mule アプリケーションで使用するコネクタやモジュールが、Mule バージョンと互換性があることを確認する必要があります。 ## [](#関連情報)関連情報 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-message) - [Mule アプリケーションの変数](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-variables) - [Mule の設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-configuration) - [APIKit](https://docs.mulesoft.com/jp/apikit/latest/) # Mule アプリケーションの開発 Mule アプリケーションを作成してシステムインテグレーションを実行します。通常、アプリケーションは内部ソースや外部ソースからデータを読み込み、データを処理して必要な形式や構造に変換して、変換後のデータを格納または使用するシステムやサーバーに出力を書き込みます。 Mule アプリケーションは Mule Runtime Engine (Mule) で実行するように設定されています。Mule アプリケーションへの要求により、Mule は要求およびデータを Mule イベントでエンコードし、単一または複数のスレッドに渡します。 ## [](#mule-アプリケーション開発入門)Mule アプリケーション開発入門 Mule アプリケーションの開発を始めるには、以下のチュートリアルの手順に従ってください。 - [「Hello World」Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-app-dev-hellomule) シンプルな HTTP 要求-返信フローでユーザーとやり取りする Mule アプリケーションを作成します。 - [Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-app-tutorial) データベースからデータを取得して新しい構造に変換する Mule アプリケーションを作成します。 ## [](#mule-アプリケーションのビルディングブロック)Mule アプリケーションのビルディングブロック Mule アプリケーションは、コネクタ、モジュール、コンポーネントを使用して、データの読み込み、書き込み、処理を行います。 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) Anypoint Connector は、Mule アプリケーションから外部 API エンドポイントとやり取りしてデータを処理するコンポーネント (リスナーなど) を提供します。検証、Java、Spring、OAuth などのモジュールは、エンドポイントに直接接続せずに Mule アプリケーション内でデータを処理します。 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-components) コアコンポーネントは、フロー制御、エラー処理、ログ、バッチ処理など、アプリケーション内を流れるデータに対するプログラム操作をサポートします。 ## [](#dataweave-言語)DataWeave 言語 DataWeave は、Mule で式を作成するために使用される主言語です。 コネクタ、モジュール、コンポーネントでは、DataWeave を使用してデータ構造や出力形式にアクセスし、処理や変換を行ったり、Mule アプリケーション内で処理するデータを抽出したりできます。 実行時に、Mule はフローを実行するときに DataWeave 式を評価して、次のことを行います。 - 現在のメッセージを処理するために必要なデータの抽出 - メッセージ内の値の設定または操作 ## [](#flows)Mule フロー 基本的なフローアーキテクチャを理解することは、Mule アプリケーションを理解するための鍵です。 基本的に、すべての Mule フローにはメッセージを受信または処理する一連の Mule コンポーネントが含まれています。 ![Design Center での簡単なフロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/flow-example.png) Figure 1. Design Center での簡単なフロー 最もシンプルなレベルでは、フローは一連のプロセッサーです。フローに入ったメッセージは、さまざまなプロセッサーを通過します。一般的なフローでは、Mule アプリケーションはソース (HTTP Listener コンポーネントなど) を使用してメッセージを受信し、そのメッセージを新しい形式に変換し、何らかのビジネスロジックを処理してから、処理されたメッセージを外部システムに向けてそのシステムが読み取れる形式で記述します。 処理を管理しやすい単位に分割するために、通常、Mule アプリケーションには 1 つのフローではなく複数の相互に関係するフローが含まれています。1 つのフローから、他のフローを直接参照としてコールできます。 このトピックについての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-flows)​と​[「Mule コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-components)​を参照してください。 ### [](#ソース)ソース ソースコンポーネント (またはトリガー) は、フローの最初のコンポーネントです。このコンポーネントは、トリガーイベントを受信し、対応する Mule イベントを作成し、そのイベントを処理するためにフローの次のコンポーネントに転送します。 外部クライアントは、Mule フローでの処理をいくつかの通信プロトコルや方法でトリガーできます。たとえば、JMS、HTTP、FTP、JDBC、ファイルなどを使用できます。 Mule は、これらの通信プロトコルや方法を標準メッセージ形式に変換し、それをフローのプロセッサーに渡します。 Mule のソースは、標準プロトコルまたはサードパーティ API を使用して、特定の外部取得元に接続できます。また、Scheduler コンポーネントを設定することも可能です。一部のスケジューラーは、外部リソースの特定の変更 (外部リソースの新規ファイルやテーブル行など) へのポーリングを実行できます。フローをトリガーできるリスナーやコネクタ操作の例として、次のようなものがあります。 - 関連するコネクタでの HTTP、JMS、VM リスナー - Database Connector での On Table Row 操作 - File Connector や FTP Connector での On New or Updated File 操作 - スケジューラー [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のソースを作成することもできます。 ### [](#プロセッサー)プロセッサー ソースコンポーネントによってフローがトリガーされると、データはフロー内を通過し、後続のコンポーネントによって処理されます。デフォルトでは、Mule イベントを受信する各プロセッサーは、新しい Mule メッセージを返します。通常、このメッセージにはプロセッサーが返す属性セットとメッセージペイロードが含まれます。プロセッサーは、新しいメッセージを出力としてフロー内の次のプロセッサーに転送します。 Mule アプリケーションで使用できるプロセッサーには、次のものがあります。 - モジュールやコネクタからのコンポーネント たとえば、外部リソースからの読み込みや外部リソースへの書き込み、Mule アプリケーション内でのデータの検証などの操作があります。 一部の操作は、外部のリソースおよびサービス (Salesforce、Workday、ServiceNow などの多数の外部データベースやシステムを含む) や他の Mule アプリケーションへのクライアント要求を行うことができます。または、カスタムコードの実行、OAuth 設定のサポート、非同期キューを使用した通信の管理を実行できる操作もあります。他にも多くの操作が用意されています。 - コアコンポーネント コアコンポーネントは、データの転送、データ変換の実行、イベント処理中に発生したエラー処理など、Mule アプリケーション内のタスクを実行できます。 トランスフォーマー (Transform Message や Set Variable など) は、ノード間でデータを交換するために重要です。トランスフォーマーを使用することで、Mule は Mule イベント内のメッセージデータを別のアプリケーションやサービスが読み取れる形式に変換できます。 また、Mule ではメッセージのコンテンツ強化 (​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.5/target-variables)​を使用) も有効なため、追加データを取得して、メッセージに添付することができます。 [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のイベントプロセッサーを作成することもできます。 ## [](#セキュリティ)セキュリティ プロパティの暗号化、TLS 上でのセキュア通信の設定、OAuth 2.0 による認証のセットアップ、さらには暗号化や FIPS 準拠などの機能を使用することで、Mule アプリケーションを保護できます。 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.5/securing) ## [](#開発環境)開発環境 Mule アプリケーションは ​[Anypoint Studio](https://docs.mulesoft.com/studio/)​ (Eclipse ベースの IDE) を使用して、または上級者であれば自分の IDE で開発できます。 たとえば、Studio では、1 つ以上の XML ベースファイルを含むプロジェクトで Mule アプリケーションをビルドおよび設計します。Mule プロジェクトは、開発に必要なすべての連動関係をサポートします。Studio の ​[\[Package Explorer](https://docs.mulesoft.com/studio/#package-explorer)\]​ ビューには、Mule プロジェクトを構成するプロジェクトフォルダーとファイルが表示されます。 Studio は、Mule アプリケーションをビルド、実行、テストするための設計環境を提供します。 ## [](#version)Mule のバージョン設定 使用する Mule のバージョンによって、Mule アプリケーション、ドメイン、またはポリシーで実行できる内容と Mule との互換性がある機能や製品が決まります。 たとえば、Mule アプリケーションのフロー内を通過する Mule イベントを処理する​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-components)​は、Mule にバンドルされ、Mule と同じバージョンのコアモジュールの一部です。 [モジュール、コネクタ](https://docs.mulesoft.com/connectors/)​、DataWeave 言語、いくつかの MuleSoft 製品には、固有のバージョン設定システムがありますが、特定のバージョンの Mule と互換性があります。たとえば、DataWeave 2.0 と Studio 7.x は Mule 4.x Runtime Engine と互換性があり、DataWeave 1.0 と Studio 6.x は Mule 3.x Runtime Engine と互換性があります。Mule アプリケーションで使用するコネクタやモジュールが、Mule バージョンと互換性があることを確認する必要があります。 ## [](#関連情報)関連情報 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-message) - [Mule アプリケーションの変数](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-variables) - [Mule の設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-configuration) - [APIkit](https://docs.mulesoft.com/jp/apikit/latest/) # Mule アプリケーションの開発 Mule アプリケーションを作成してシステムインテグレーションを実行します。通常、アプリケーションは内部ソースや外部ソースからデータを読み込み、データを処理して必要な形式や構造に変換して、変換後のデータを格納または使用するシステムやサーバーに出力を書き込みます。 Mule アプリケーションは Mule Runtime Engine (Mule) で実行するように設定されています。Mule アプリケーションへの要求により、Mule は要求およびデータを Mule イベントでエンコードし、単一または複数のスレッドに渡します。 ## [](#mule-アプリケーション開発入門)Mule アプリケーション開発入門 Mule アプリケーションの開発を始めるには、以下のチュートリアルの手順に従ってください。 - [「Hello World」Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-app-dev-hellomule) シンプルな HTTP 要求-返信フローでユーザーとやり取りする Mule アプリケーションを作成します。 - [Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-app-tutorial) データベースからデータを取得して新しい構造に変換する Mule アプリケーションを作成します。 ## [](#mule-アプリケーションのビルディングブロック)Mule アプリケーションのビルディングブロック Mule アプリケーションは、コネクタ、モジュール、コンポーネントを使用して、データの読み込み、書き込み、処理を行います。 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) Anypoint Connector は、Mule アプリケーションから外部 API エンドポイントとやり取りしてデータを処理するコンポーネント (リスナーなど) を提供します。検証、Java、Spring、OAuth などのモジュールは、エンドポイントに直接接続せずに Mule アプリケーション内でデータを処理します。 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-components) コアコンポーネントは、フロー制御、エラー処理、ログ、バッチ処理など、アプリケーション内を流れるデータに対するプログラム操作をサポートします。 ## [](#dataweave-言語)DataWeave 言語 DataWeave は、Mule で式を作成するために使用される主言語です。 コネクタ、モジュール、コンポーネントでは、DataWeave を使用してデータ構造や出力形式にアクセスし、処理や変換を行ったり、Mule アプリケーション内で処理するデータを抽出したりできます。 実行時に、Mule はフローを実行するときに DataWeave 式を評価して、次のことを行います。 - 現在のメッセージを処理するために必要なデータの抽出 - メッセージ内の値の設定または操作 ## [](#flows)Mule フロー 基本的なフローアーキテクチャを理解することは、Mule アプリケーションを理解するための鍵です。 基本的に、すべての Mule フローにはメッセージを受信または処理する一連の Mule コンポーネントが含まれています。 ![Design Center での簡単なフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/flow-example.png) Figure 1. Design Center での簡単なフロー 最もシンプルなレベルでは、フローは一連のプロセッサーです。フローに入ったメッセージは、さまざまなプロセッサーを通過します。一般的なフローでは、Mule アプリケーションはソース (HTTP Listener コンポーネントなど) を使用してメッセージを受信し、そのメッセージを新しい形式に変換し、何らかのビジネスロジックを処理してから、処理されたメッセージを外部システムに向けてそのシステムが読み取れる形式で記述します。 処理を管理しやすい単位に分割するために、通常、Mule アプリケーションには 1 つのフローではなく複数の相互に関係するフローが含まれています。1 つのフローから、他のフローを直接参照としてコールできます。 このトピックについての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-flows)​と​[「Mule コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-components)​を参照してください。 ### [](#ソース)ソース ソースコンポーネント (またはトリガー) は、フローの最初のコンポーネントです。このコンポーネントは、トリガーイベントを受信し、対応する Mule イベントを作成し、そのイベントを処理するためにフローの次のコンポーネントに転送します。 外部クライアントは、Mule フローでの処理をいくつかの通信プロトコルや方法でトリガーできます。たとえば、JMS、HTTP、FTP、JDBC、ファイルなどを使用できます。 Mule は、これらの通信プロトコルや方法を標準メッセージ形式に変換し、それをフローのプロセッサーに渡します。 Mule のソースは、標準プロトコルまたはサードパーティ API を使用して、特定の外部取得元に接続できます。また、Scheduler コンポーネントを設定することも可能です。一部のスケジューラーは、外部リソースの特定の変更 (外部リソースの新規ファイルやテーブル行など) へのポーリングを実行できます。フローをトリガーできるリスナーやコネクタ操作の例として、次のようなものがあります。 - 関連するコネクタでの HTTP、JMS、VM リスナー - Database Connector での On Table Row 操作 - File Connector や FTP Connector での On New or Updated File 操作 - スケジューラー [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のソースを作成することもできます。 ### [](#プロセッサー)プロセッサー ソースコンポーネントによってフローがトリガーされると、データはフロー内を通過し、後続のコンポーネントによって処理されます。デフォルトでは、Mule イベントを受信する各プロセッサーは、新しい Mule メッセージを返します。通常、このメッセージにはプロセッサーが返す属性セットとメッセージペイロードが含まれます。プロセッサーは、新しいメッセージを出力としてフロー内の次のプロセッサーに転送します。 Mule アプリケーションで使用できるプロセッサーには、次のものがあります。 - モジュールやコネクタからのコンポーネント たとえば、外部リソースからの読み込みや外部リソースへの書き込み、Mule アプリケーション内でのデータの検証などの操作があります。 一部の操作は、外部のリソースおよびサービス (Salesforce、Workday、ServiceNow などの多数の外部データベースやシステムを含む) や他の Mule アプリケーションへのクライアント要求を行うことができます。または、カスタムコードの実行、OAuth 設定のサポート、非同期キューを使用した通信の管理を実行できる操作もあります。他にも多くの操作が用意されています。 - コアコンポーネント コアコンポーネントは、データの転送、データ変換の実行、イベント処理中に発生したエラー処理など、Mule アプリケーション内のタスクを実行できます。 トランスフォーマー (Transform Message や Set Variable など) は、ノード間でデータを交換するために重要です。トランスフォーマーを使用することで、Mule は Mule イベント内のメッセージデータを別のアプリケーションやサービスが読み取れる形式に変換できます。 また、Mule ではメッセージのコンテンツ強化 (​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.6/target-variables)​を使用) も有効なため、追加データを取得して、メッセージに添付することができます。 [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のイベントプロセッサーを作成することもできます。 ## [](#セキュリティ)セキュリティ プロパティの暗号化、TLS 上でのセキュア通信の設定、OAuth 2.0 による認証のセットアップ、さらには暗号化や FIPS 準拠などの機能を使用することで、Mule アプリケーションを保護できます。 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.6/securing) ## [](#開発環境)開発環境 Mule アプリケーションは ​[Anypoint Studio](https://docs.mulesoft.com/studio/)​ (Eclipse ベースの IDE) を使用して、または上級者であれば自分の IDE で開発できます。 たとえば、Studio では、1 つ以上の XML ベースファイルを含むプロジェクトで Mule アプリケーションをビルドおよび設計します。Mule プロジェクトは、開発に必要なすべての連動関係をサポートします。Studio の ​[\[Package Explorer](https://docs.mulesoft.com/studio/#package-explorer)\]​ ビューには、Mule プロジェクトを構成するプロジェクトフォルダーとファイルが表示されます。 Studio は、Mule アプリケーションをビルド、実行、テストするための設計環境を提供します。 ## [](#version)Mule のバージョン設定 使用する Mule のバージョンによって、Mule アプリケーション、ドメイン、またはポリシーで実行できる内容と Mule との互換性がある機能や製品が決まります。 たとえば、Mule アプリケーションのフロー内を通過する Mule イベントを処理する​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-components)​は、Mule にバンドルされ、Mule と同じバージョンのコアモジュールの一部です。 [モジュール、コネクタ](https://docs.mulesoft.com/connectors/)​、DataWeave 言語、いくつかの MuleSoft 製品には、固有のバージョン設定システムがありますが、特定のバージョンの Mule と互換性があります。たとえば、DataWeave 2.0 と Studio 7.x は Mule 4.x Runtime Engine と互換性があり、DataWeave 1.0 と Studio 6.x は Mule 3.x Runtime Engine と互換性があります。Mule アプリケーションで使用するコネクタやモジュールが、Mule バージョンと互換性があることを確認する必要があります。 ## [](#関連情報)関連情報 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-message) - [Mule アプリケーションの変数](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-variables) - [Mule の設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-configuration) - [APIKit](https://docs.mulesoft.com/jp/apikit/latest/) # Mule アプリケーションの開発 Mule アプリケーションを作成してシステムインテグレーションを実行します。通常、アプリケーションは内部ソースや外部ソースからデータを読み込み、データを処理して必要な形式や構造に変換して、変換後のデータを格納または使用するシステムやサーバーに出力を書き込みます。 Mule アプリケーションは Mule Runtime Engine (Mule) で実行するように設定されています。Mule アプリケーションへの要求により、Mule は要求およびデータを Mule イベントでエンコードし、単一または複数のスレッドに渡します。 ## [](#mule-アプリケーション開発入門)Mule アプリケーション開発入門 Mule アプリケーションの開発を始めるには、以下のチュートリアルの手順に従ってください。 - [「Hello World」Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-app-dev-hellomule) シンプルな HTTP 要求-返信フローでユーザーとやり取りする Mule アプリケーションを作成します。 - [Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-app-tutorial) データベースからデータを取得して新しい構造に変換する Mule アプリケーションを作成します。 ## [](#mule-アプリケーションのビルディングブロック)Mule アプリケーションのビルディングブロック Mule アプリケーションは、コネクタ、モジュール、コンポーネントを使用して、データの読み込み、書き込み、処理を行います。 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) Anypoint Connector は、Mule アプリケーションから外部 API エンドポイントとやり取りしてデータを処理するコンポーネント (リスナーなど) を提供します。検証、Java、Spring、OAuth などのモジュールは、エンドポイントに直接接続せずに Mule アプリケーション内でデータを処理します。 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-components) コアコンポーネントは、フロー制御、エラー処理、ログ、バッチ処理など、アプリケーション内を流れるデータに対するプログラム操作をサポートします。 ## [](#dataweave-言語)DataWeave 言語 DataWeave は、Mule で式を作成するために使用される主言語です。 コネクタ、モジュール、コンポーネントでは、DataWeave を使用してデータ構造や出力形式にアクセスし、処理や変換を行ったり、Mule アプリケーション内で処理するデータを抽出したりできます。 実行時に、Mule はフローを実行するときに DataWeave 式を評価して、次のことを行います。 - 現在のメッセージを処理するために必要なデータの抽出 - メッセージ内の値の設定または操作 ## [](#flows)Mule フロー 基本的なフローアーキテクチャを理解することは、Mule アプリケーションを理解するための鍵です。 基本的に、すべての Mule フローにはメッセージを受信または処理する一連の Mule コンポーネントが含まれています。 ![HTTP リスナー、データ変換、データベース接続、ログプロセスが含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/flow-example.png) Figure 1. Design Center での簡単なフロー 最もシンプルなレベルでは、フローは一連のプロセッサーです。フローに入ったメッセージは、さまざまなプロセッサーを通過します。一般的なフローでは、Mule アプリケーションはソース (HTTP Listener コンポーネントなど) を使用してメッセージを受信し、そのメッセージを新しい形式に変換し、何らかのビジネスロジックを処理してから、処理されたメッセージを外部システムに向けてそのシステムが読み取れる形式で記述します。 処理を管理しやすい単位に分割するために、通常、Mule アプリケーションには 1 つのフローではなく複数の相互に関係するフローが含まれています。1 つのフローから、他のフローを直接参照としてコールできます。 このトピックについての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-flows)​と​[「Mule コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-components)​を参照してください。 ### [](#ソース)ソース ソースコンポーネント (またはトリガー) は、フローの最初のコンポーネントです。このコンポーネントは、トリガーイベントを受信し、対応する Mule イベントを作成し、そのイベントを処理するためにフローの次のコンポーネントに転送します。 外部クライアントは、Mule フローでの処理をいくつかの通信プロトコルや方法でトリガーできます。たとえば、JMS、HTTP、FTP、JDBC、ファイルなどを使用できます。 Mule は、これらの通信プロトコルや方法を標準メッセージ形式に変換し、それをフローのプロセッサーに渡します。 Mule のソースは、標準プロトコルまたはサードパーティ API を使用して、特定の外部取得元に接続できます。また、Scheduler コンポーネントを設定することも可能です。一部のスケジューラーは、外部リソースの特定の変更 (外部リソースの新規ファイルやテーブル行など) へのポーリングを実行できます。フローをトリガーできるリスナーやコネクタ操作の例として、次のようなものがあります。 - 関連するコネクタでの HTTP、JMS、VM リスナー - Database Connector での On Table Row 操作 - File Connector や FTP Connector での On New or Updated File 操作 - スケジューラー [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のソースを作成することもできます。 ### [](#プロセッサー)プロセッサー ソースコンポーネントによってフローがトリガーされると、データはフロー内を通過し、後続のコンポーネントによって処理されます。デフォルトでは、Mule イベントを受信する各プロセッサーは、新しい Mule メッセージを返します。通常、このメッセージにはプロセッサーが返す属性セットとメッセージペイロードが含まれます。プロセッサーは、新しいメッセージを出力としてフロー内の次のプロセッサーに転送します。 Mule アプリケーションで使用できるプロセッサーには、次のものがあります。 - モジュールやコネクタからのコンポーネント たとえば、外部リソースからの読み込みや外部リソースへの書き込み、Mule アプリケーション内でのデータの検証などの操作があります。 一部の操作は、外部のリソースおよびサービス (Salesforce、Workday、ServiceNow などの多数の外部データベースやシステムを含む) や他の Mule アプリケーションへのクライアント要求を行うことができます。または、カスタムコードの実行、OAuth 設定のサポート、非同期キューを使用した通信の管理を実行できる操作もあります。他にも多くの操作が用意されています。 - コアコンポーネント コアコンポーネントは、データの転送、データ変換の実行、イベント処理中に発生したエラー処理など、Mule アプリケーション内のタスクを実行できます。 トランスフォーマー (Transform Message や Set Variable など) は、ノード間でデータを交換するために重要です。トランスフォーマーを使用することで、Mule は Mule イベント内のメッセージデータを別のアプリケーションやサービスが読み取れる形式に変換できます。 また、Mule ではメッセージのコンテンツ強化 (​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.7/target-variables)​を使用) も有効なため、追加データを取得して、メッセージに添付することができます。 [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のイベントプロセッサーを作成することもできます。 ## [](#セキュリティ)セキュリティ プロパティの暗号化、TLS 上でのセキュア通信の設定、OAuth 2.0 による認証のセットアップ、さらには暗号化や FIPS 準拠などの機能を使用することで、Mule アプリケーションを保護できます。 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.7/securing) ## [](#開発環境)開発環境 Mule アプリケーションは ​[Anypoint Studio](https://docs.mulesoft.com/studio/)​ (Eclipse ベースの IDE) を使用して、または上級者であれば自分の IDE で開発できます。 たとえば、Studio では、1 つ以上の XML ベースファイルを含むプロジェクトで Mule アプリケーションをビルドおよび設計します。Mule プロジェクトは、開発に必要なすべての連動関係をサポートします。Studio の ​[\[Package Explorer](https://docs.mulesoft.com/studio/#package-explorer)\]​ ビューには、Mule プロジェクトを構成するプロジェクトフォルダーとファイルが表示されます。 Studio は、Mule アプリケーションをビルド、実行、テストするための設計環境を提供します。 ## [](#version)Mule のバージョン設定 使用する Mule のバージョンによって、Mule アプリケーション、ドメイン、またはポリシーで実行できる内容と Mule との互換性がある機能や製品が決まります。 たとえば、Mule アプリケーションのフロー内を通過する Mule イベントを処理する​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-components)​は、Mule にバンドルされ、Mule と同じバージョンのコアモジュールの一部です。 [モジュール、コネクタ](https://docs.mulesoft.com/connectors/)​、DataWeave 言語、いくつかの MuleSoft 製品には、固有のバージョン設定システムがありますが、特定のバージョンの Mule と互換性があります。たとえば、DataWeave 2.0 と Studio 7.x は Mule 4.x Runtime Engine と互換性があり、DataWeave 1.0 と Studio 6.x は Mule 3.x Runtime Engine と互換性があります。Mule アプリケーションで使用するコネクタやモジュールが、Mule バージョンと互換性があることを確認する必要があります。 ## [](#関連情報)関連情報 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-message) - [Mule アプリケーションの変数](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-variables) - [Mule の設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-configuration) - [APIKit](https://docs.mulesoft.com/jp/apikit/latest/) # Mule アプリケーションの開発 Mule アプリケーションを作成してシステムインテグレーションを実行します。通常、アプリケーションは内部ソースや外部ソースからデータを読み込み、データを処理して必要な形式や構造に変換して、変換後のデータを格納または使用するシステムやサーバーに出力を書き込みます。 Mule アプリケーションは Mule Runtime Engine (Mule) で実行するように設定されています。Mule アプリケーションへの要求により、Mule は要求およびデータを Mule イベントでエンコードし、単一または複数のスレッドに渡します。 ## [](#mule-アプリケーション開発入門)Mule アプリケーション開発入門 Mule アプリケーションの開発を始めるには、以下のチュートリアルの手順に従ってください。 - [「Hello World」Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-app-dev-hellomule) シンプルな HTTP 要求-返信フローでユーザーとやり取りする Mule アプリケーションを作成します。 - [Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-app-tutorial) データベースからデータを取得して新しい構造に変換する Mule アプリケーションを作成します。 ## [](#mule-アプリケーションのビルディングブロック)Mule アプリケーションのビルディングブロック Mule アプリケーションは、コネクタ、モジュール、コンポーネントを使用して、データの読み込み、書き込み、処理を行います。 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) Anypoint Connector は、Mule アプリケーションから外部 API エンドポイントとやり取りしてデータを処理するコンポーネント (リスナーなど) を提供します。検証、Java、Spring、OAuth などのモジュールは、エンドポイントに直接接続せずに Mule アプリケーション内でデータを処理します。 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-components) コアコンポーネントは、フロー制御、エラー処理、ログ、バッチ処理など、アプリケーション内を流れるデータに対するプログラム操作をサポートします。 ## [](#dataweave-言語)DataWeave 言語 DataWeave は、Mule で式を作成するために使用される主言語です。 コネクタ、モジュール、コンポーネントでは、DataWeave を使用してデータ構造や出力形式にアクセスし、処理や変換を行ったり、Mule アプリケーション内で処理するデータを抽出したりできます。 実行時に、Mule はフローを実行するときに DataWeave 式を評価して、次のことを行います。 - 現在のメッセージを処理するために必要なデータの抽出 - メッセージ内の値の設定または操作 ## [](#flows)Mule フロー 基本的なフローアーキテクチャを理解することは、Mule アプリケーションを理解するための鍵です。 基本的に、すべての Mule フローにはメッセージを受信または処理する一連の Mule コンポーネントが含まれています。 ![HTTP リスナー、データ変換、データベース接続、ログプロセスが含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/flow-example.png) Figure 1. Design Center での簡単なフロー 最もシンプルなレベルでは、フローは一連のプロセッサーです。フローに入ったメッセージは、さまざまなプロセッサーを通過します。一般的なフローでは、Mule アプリケーションはソース (HTTP Listener コンポーネントなど) を使用してメッセージを受信し、そのメッセージを新しい形式に変換し、何らかのビジネスロジックを処理してから、処理されたメッセージを外部システムに向けてそのシステムが読み取れる形式で記述します。 処理を管理しやすい単位に分割するために、通常、Mule アプリケーションには 1 つのフローではなく複数の相互に関係するフローが含まれています。1 つのフローから、他のフローを直接参照としてコールできます。 このトピックについての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-flows)​と​[「Mule コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-components)​を参照してください。 ### [](#ソース)ソース ソースコンポーネント (またはトリガー) は、フローの最初のコンポーネントです。このコンポーネントは、トリガーイベントを受信し、対応する Mule イベントを作成し、そのイベントを処理するためにフローの次のコンポーネントに転送します。 外部クライアントは、Mule フローでの処理をいくつかの通信プロトコルや方法でトリガーできます。たとえば、JMS、HTTP、FTP、JDBC、ファイルなどを使用できます。 Mule は、これらの通信プロトコルや方法を標準メッセージ形式に変換し、それをフローのプロセッサーに渡します。 Mule のソースは、標準プロトコルまたはサードパーティ API を使用して、特定の外部取得元に接続できます。また、Scheduler コンポーネントを設定することも可能です。一部のスケジューラーは、外部リソースの特定の変更 (外部リソースの新規ファイルやテーブル行など) へのポーリングを実行できます。フローをトリガーできるリスナーやコネクタ操作の例として、次のようなものがあります。 - 関連するコネクタでの HTTP、JMS、VM リスナー - Database Connector での On Table Row 操作 - File Connector や FTP Connector での On New or Updated File 操作 - スケジューラー [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のソースを作成することもできます。 ### [](#プロセッサー)プロセッサー ソースコンポーネントによってフローがトリガーされると、データはフロー内を通過し、後続のコンポーネントによって処理されます。デフォルトでは、Mule イベントを受信する各プロセッサーは、新しい Mule メッセージを返します。通常、このメッセージにはプロセッサーが返す属性セットとメッセージペイロードが含まれます。プロセッサーは、新しいメッセージを出力としてフロー内の次のプロセッサーに転送します。 Mule アプリケーションで使用できるプロセッサーには、次のものがあります。 - モジュールやコネクタからのコンポーネント たとえば、外部リソースからの読み込みや外部リソースへの書き込み、Mule アプリケーション内でのデータの検証などの操作があります。 一部の操作は、外部のリソースおよびサービス (Salesforce、Workday、ServiceNow などの多数の外部データベースやシステムを含む) や他の Mule アプリケーションへのクライアント要求を行うことができます。または、カスタムコードの実行、OAuth 設定のサポート、非同期キューを使用した通信の管理を実行できる操作もあります。他にも多くの操作が用意されています。 - コアコンポーネント コアコンポーネントは、データの転送、データ変換の実行、イベント処理中に発生したエラー処理など、Mule アプリケーション内のタスクを実行できます。 トランスフォーマー (Transform Message や Set Variable など) は、ノード間でデータを交換するために重要です。トランスフォーマーを使用することで、Mule は Mule イベント内のメッセージデータを別のアプリケーションやサービスが読み取れる形式に変換できます。 また、Mule ではメッセージのコンテンツ強化 (​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.8/target-variables)​を使用) も有効なため、追加データを取得して、メッセージに添付することができます。 [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のイベントプロセッサーを作成することもできます。 ## [](#セキュリティ)セキュリティ プロパティの暗号化、TLS 上でのセキュア通信の設定、OAuth 2.0 による認証のセットアップ、さらには暗号化や FIPS 準拠などの機能を使用することで、Mule アプリケーションを保護できます。 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.8/securing) ## [](#開発環境)開発環境 Mule アプリケーションは ​[Anypoint Studio](https://docs.mulesoft.com/studio/)​ (Eclipse ベースの IDE) を使用して、または上級者であれば自分の IDE で開発できます。 たとえば、Studio では、1 つ以上の XML ベースファイルを含むプロジェクトで Mule アプリケーションをビルドおよび設計します。Mule プロジェクトは、開発に必要なすべての連動関係をサポートします。Studio の ​[\[Package Explorer](https://docs.mulesoft.com/studio/#package-explorer)\]​ ビューには、Mule プロジェクトを構成するプロジェクトフォルダーとファイルが表示されます。 Studio は、Mule アプリケーションをビルド、実行、テストするための設計環境を提供します。 ## [](#version)Mule のバージョン設定 使用する Mule のバージョンによって、Mule アプリケーション、ドメイン、またはポリシーで実行できる内容と Mule との互換性がある機能や製品が決まります。 たとえば、Mule アプリケーションのフロー内を通過する Mule イベントを処理する​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-components)​は、Mule にバンドルされ、Mule と同じバージョンのコアモジュールの一部です。 [モジュール、コネクタ](https://docs.mulesoft.com/connectors/)​、DataWeave 言語、いくつかの MuleSoft 製品には、固有のバージョン設定システムがありますが、特定のバージョンの Mule と互換性があります。たとえば、DataWeave 2.0 と Studio 7.x は Mule 4.x Runtime Engine と互換性があり、DataWeave 1.0 と Studio 6.x は Mule 3.x Runtime Engine と互換性があります。Mule アプリケーションで使用するコネクタやモジュールが、Mule バージョンと互換性があることを確認する必要があります。 ## [](#関連情報)関連情報 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-message) - [Mule アプリケーションの変数](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-variables) - [Mule の設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-configuration) - [APIKit](https://docs.mulesoft.com/jp/apikit/latest/) # Mule アプリケーションの開発 Mule アプリケーションを作成してシステムインテグレーションを実行します。通常、アプリケーションは内部ソースや外部ソースからデータを読み込み、データを処理して必要な形式や構造に変換して、変換後のデータを格納または使用するシステムやサーバーに出力を書き込みます。 Mule アプリケーションは Mule Runtime Engine (Mule) で実行するように設定されています。Mule アプリケーションへの要求により、Mule は要求およびデータを Mule イベントでエンコードし、単一または複数のスレッドに渡します。 ## [](#mule-アプリケーション開発入門)Mule アプリケーション開発入門 Mule アプリケーションの開発を始めるには、以下のチュートリアルの手順に従ってください。 - [「Hello World」Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-app-dev-hellomule) シンプルな HTTP 要求-返信フローでユーザーとやり取りする Mule アプリケーションを作成します。 - [Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-app-tutorial) データベースからデータを取得して新しい構造に変換する Mule アプリケーションを作成します。 ## [](#mule-アプリケーションのビルディングブロック)Mule アプリケーションのビルディングブロック Mule アプリケーションは、コネクタ、モジュール、コンポーネントを使用して、データの読み込み、書き込み、処理を行います。 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) Anypoint Connector は、Mule アプリケーションから外部 API エンドポイントとやり取りしてデータを処理するコンポーネント (リスナーなど) を提供します。検証、Java、Spring、OAuth などのモジュールは、エンドポイントに直接接続せずに Mule アプリケーション内でデータを処理します。 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-components) コアコンポーネントは、フロー制御、エラー処理、ログ、バッチ処理など、アプリケーション内を流れるデータに対するプログラム操作をサポートします。 ## [](#dataweave-言語)DataWeave 言語 DataWeave は、Mule で式を作成するために使用される主言語です。 コネクタ、モジュール、コンポーネントでは、DataWeave を使用してデータ構造や出力形式にアクセスし、処理や変換を行ったり、Mule アプリケーション内で処理するデータを抽出したりできます。 実行時に、Mule はフローを実行するときに DataWeave 式を評価して、次のことを行います。 - 現在のメッセージを処理するために必要なデータの抽出 - メッセージ内の値の設定または操作 ## [](#flows)Mule フロー 基本的なフローアーキテクチャを理解することは、Mule アプリケーションを理解するための鍵です。 基本的に、すべての Mule フローにはメッセージを受信または処理する一連の Mule コンポーネントが含まれています。 ![HTTP リスナー、データ変換、データベース接続、ログプロセスが含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/flow-example.png) Figure 1. Design Center での簡単なフロー 最もシンプルなレベルでは、フローは一連のプロセッサーです。フローに入ったメッセージは、さまざまなプロセッサーを通過します。一般的なフローでは、Mule アプリケーションはソース (HTTP Listener コンポーネントなど) を使用してメッセージを受信し、そのメッセージを新しい形式に変換し、何らかのビジネスロジックを処理してから、処理されたメッセージを外部システムに向けてそのシステムが読み取れる形式で記述します。 処理を管理しやすい単位に分割するために、通常、Mule アプリケーションには 1 つのフローではなく複数の相互に関係するフローが含まれています。1 つのフローから、他のフローを直接参照としてコールできます。 このトピックについての詳細は、​[「フローおよびサブフロー」](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-flows)​と​[「Mule コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-components)​を参照してください。 ### [](#ソース)ソース ソースコンポーネント (またはトリガー) は、フローの最初のコンポーネントです。このコンポーネントは、トリガーイベントを受信し、対応する Mule イベントを作成し、そのイベントを処理するためにフローの次のコンポーネントに転送します。 外部クライアントは、Mule フローでの処理をいくつかの通信プロトコルや方法でトリガーできます。たとえば、JMS、HTTP、FTP、JDBC、ファイルなどを使用できます。 Mule は、これらの通信プロトコルや方法を標準メッセージ形式に変換し、それをフローのプロセッサーに渡します。 Mule のソースは、標準プロトコルまたはサードパーティ API を使用して、特定の外部取得元に接続できます。また、Scheduler コンポーネントを設定することも可能です。一部のスケジューラーは、外部リソースの特定の変更 (外部リソースの新規ファイルやテーブル行など) へのポーリングを実行できます。フローをトリガーできるリスナーやコネクタ操作の例として、次のようなものがあります。 - 関連するコネクタでの HTTP、JMS、VM リスナー - Database Connector での On Table Row 操作 - File Connector や FTP Connector での On New or Updated File 操作 - スケジューラー [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のソースを作成することもできます。 ### [](#プロセッサー)プロセッサー ソースコンポーネントによってフローがトリガーされると、データはフロー内を通過し、後続のコンポーネントによって処理されます。デフォルトでは、Mule イベントを受信する各プロセッサーは、新しい Mule メッセージを返します。通常、このメッセージにはプロセッサーが返す属性セットとメッセージペイロードが含まれます。プロセッサーは、新しいメッセージを出力としてフロー内の次のプロセッサーに転送します。 Mule アプリケーションで使用できるプロセッサーには、次のものがあります。 - モジュールやコネクタからのコンポーネント たとえば、外部リソースからの読み込みや外部リソースへの書き込み、Mule アプリケーション内でのデータの検証などの操作があります。 一部の操作は、外部のリソースおよびサービス (Salesforce、Workday、ServiceNow などの多数の外部データベースやシステムを含む) や他の Mule アプリケーションへのクライアント要求を行うことができます。または、カスタムコードの実行、OAuth 設定のサポート、非同期キューを使用した通信の管理を実行できる操作もあります。他にも多くの操作が用意されています。 - コアコンポーネント コアコンポーネントは、データの転送、データ変換の実行、イベント処理中に発生したエラー処理など、Mule アプリケーション内のタスクを実行できます。 トランスフォーマー (Transform Message や Set Variable など) は、ノード間でデータを交換するために重要です。トランスフォーマーを使用することで、Mule は Mule イベント内のメッセージデータを別のアプリケーションやサービスが読み取れる形式に変換できます。 また、Mule ではメッセージのコンテンツ強化 (​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.9/target-variables)​を使用) も有効なため、追加データを取得して、メッセージに添付することができます。 [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して独自のイベントプロセッサーを作成することもできます。 ## [](#セキュリティ)セキュリティ プロパティの暗号化、TLS 上でのセキュア通信の設定、OAuth 2.0 による認証のセットアップ、さらには暗号化や FIPS 準拠などの機能を使用することで、Mule アプリケーションを保護できます。 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.9/securing) ## [](#開発環境)開発環境 Mule アプリケーションは ​[Anypoint Studio](https://docs.mulesoft.com/studio/)​ (Eclipse ベースの IDE) を使用して、または上級者であれば自分の IDE で開発できます。 たとえば、Studio では、1 つ以上の XML ベースファイルを含むプロジェクトで Mule アプリケーションをビルドおよび設計します。Mule プロジェクトは、開発に必要なすべての連動関係をサポートします。Studio の ​[\[Package Explorer](https://docs.mulesoft.com/studio/#package-explorer)\]​ ビューには、Mule プロジェクトを構成するプロジェクトフォルダーとファイルが表示されます。 Studio は、Mule アプリケーションをビルド、実行、テストするための設計環境を提供します。 ## [](#version)Mule のバージョン設定 使用する Mule のバージョンによって、Mule アプリケーション、ドメイン、またはポリシーで実行できる内容と Mule との互換性がある機能や製品が決まります。 たとえば、Mule アプリケーションのフロー内を通過する Mule イベントを処理する​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-components)​は、Mule にバンドルされ、Mule と同じバージョンのコアモジュールの一部です。 [モジュール、コネクタ](https://docs.mulesoft.com/connectors/)​、DataWeave 言語、いくつかの MuleSoft 製品には、固有のバージョン設定システムがありますが、特定のバージョンの Mule と互換性があります。たとえば、DataWeave 2.0 と Studio 7.x は Mule 4.x Runtime Engine と互換性があり、DataWeave 1.0 と Studio 6.x は Mule 3.x Runtime Engine と互換性があります。Mule アプリケーションで使用するコネクタやモジュールが、Mule バージョンと互換性があることを確認する必要があります。 ## [](#関連情報)関連情報 - [Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-message) - [Mule アプリケーションの変数](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-variables) - [Mule の設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-configuration) - [APIKit](https://docs.mulesoft.com/jp/apikit/latest/) # Mule アプリケーションをパッケージする
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule アプリケーションは Mule Maven プラグイン (コマンドライン) または Anypoint Studio を使用してパッケージできます。この手順についての詳細は、​[「Studio からのプロジェクトのエクスポート」](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio)​を参照してください。 Mule アプリケーションはデプロイ可能な JAR ファイルにパッケージされ、このパッケージを後から実行中の Mule Runtime Engine にデプロイできます。パッケージには、アプリケーションによって必要とされる JAR ファイルであるかそのプラグインによって必要とされる JAR ファイルであるかに関係なく、アプリケーションおよびそのすべての連動関係が含まれます。 すべての Mule アプリケーションには 2 つの記述子があります。これらの記述子により、Mule アプリケーションの連動関係が定義されます。 - `mule-artifact.json`​ ファイル。 このファイルは、アプリケーションがどのように構成されるかを記述します。 - `pom.xml`​ ファイル。 このファイルは、パッケージが正常に機能するために必要なすべての連動関係を記述します。 ## [](#互換性)互換性 Mule 4 アプリケーションは次の Anypoint Studio と Mule Maven プラグインバージョンと互換性があります。 - Anypoint Studio 7.x - Mule Maven プラグイン 3.x ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept#add-mmp)​を参照してください。 ## [](#mule-アプリケーション構造リファレンス)Mule アプリケーション構造リファレンス デザインタイムに、Mule アプリケーションには少なくとも次の 3 つの基本的なコンポーネントが必要です。
コンポーネント 型 説明

src

フォルダー

アプリケーションの本番ソースコードおよびテストのソースディレクトリ。
このフォルダーについては、下記のリファレンスを参照してください。

pom.xml

Descriptor (記述子)

Mule アプリケーションの POM ファイル。
このファイルは、アプリケーションのすべての必須の連動関係を記述します。

mule-artifact.json

Descriptor (記述子)

Mule アプリケーションの mule-artifact ファイル。
このファイルは、Mule アプリケーションがどのように構成されるかを記述します。
これらの 3 つのコンポーネントは必須です。このいずれか 1 つが欠落すると、プロジェクトをデプロイ可能な JAR ファイルにパッケージできません。 さらに、パッケージプロセスでは Mule アプリケーションのルートフォルダーにある他のディレクトリまたはファイルが考慮されません。 ## [](#ソースディレクトリリファレンス)ソースディレクトリリファレンス `src`​ ディレクトリには ​`main`​ と ​`test`​ の 2 つの主要なフォルダーがあります。 プラグインはアプリケーションをパッケージするときに ​`src`​ 内の他のディレクトリを考慮しません。 ### [](#srcmain)src/main src/main はアプリケーションのすべての本番ソースコードのルートフォルダーです。
フォルダー フォルダー種別 説明

src/main/mule

ソース

Mule 設定ファイルのルートフォルダー。
Java パッケージの形式で、ネストされたフォルダーを含むことができます。

このフォルダーは必須です。

src/main/resources

resource (リソース)

XML、JSON、プロパティファイルなどのアプリケーションリソースが含まれます。
ここに配置された Jar ファイルはアプリケーションクラスローダーによって読み込まれますが、プレーンファイルリソースとして読み込まれます。
パッケージプロセスにより、​`src/main/mule`​ および ​`src/main/resources`​ 内のすべてのファイルがバイナリパッケージのルートディレクトリに送信されます。 `src/main/mule`​ 内のネストされたフォルダーは、バイナリパッケージのルートディレクトリ内のディレクトリとして保持されます。 ### [](#srctest)src/test src/test はアプリケーションのすべてのテストソースコードのルートフォルダーです。
フォルダー フォルダー種別 説明

src/test/java

ソース

アプリケーションのカスタム Java コードを検証するために使用されるテストクラスのルートフォルダーです。
通常の Java アプリケーションの規則に従います。

src/test/munit

ソース

MUnit ソースコードが含まれます。
パッケージの形式で、ネストされたフォルダーを含むことができます。

src/test/resources

resource (リソース)

XML、JSON、プロパティファイルなどのリソースが含まれます。
このフォルダーには、​mule-config.xml​ で参照されるメタデータを記述するファイルも含まれます。
## [](#mule-アプリケーションをパッケージする)Mule アプリケーションをパッケージする プロジェクトのフォルダーのコマンドラインから、パッケージゴールを実行します。 ```console mvn clean package ``` このプラグインはアプリケーションをプロジェクトのフォルダー内の対象ディレクトリにパッケージし、デプロイ可能な JAR ファイルを作成します。
pom.xml​ に連動関係バージョンの競合がある場合、最新バージョンが使用されます。
## [](#anypoint-studio-にインポートするアプリケーションパッケージの作成)Anypoint Studio にインポートするアプリケーションパッケージの作成 Anypoint Studio にインポートできる JAR ファイルを生成するには、​`-DattachMuleSources`​ パラメーターを使用してアプリケーションをパッケージ化し、デプロイ可能ファイルをオープン Mule プロジェクトとしてワークスペースに再インポートするために Studio で必要とされるソースファイルおよびメタデータを含める必要があります。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources ``` `-DattachMuleSources`​ パラメーターにより、デザインタイムにアプリケーション構造の正確なコピーを使用して ​`META-INF`​ ディレクトリ内に ​`mule-src`​ フォルダーを追加するようプラグインに指示されます。このオプションにより、Mule Runtime Engine にデプロイできる機能する Mule のデプロイ可能なアーカイブファイルを作成するために必要なプロジェクトモジュールおよび連動関係もパッケージ化されます。 ## [](#軽量パッケージの作成)軽量パッケージの作成 Mule Runtime Engine で Mule アプリケーションを実行するために必要な実際のモジュールおよび外部連動関係のバンドルをスキップして、Anypoint Studio に JAR パッケージをインポートし直すために必要なソースファイルおよびメタデータのみの軽量パッケージを作成できます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DlightweightPackage ``` このパラメーターを指定すると、プラグインによって Mule アプリケーションの ​`pom.xml`​ ファイルで宣言された連動関係を含まない軽量 JAR ファイルが作成されます。この JAR ファイルを Mule Runtime Engine にデプロイすることはできず、Mule アプリケーションのソースファイルのみをアーカイブすることができます。この Maven パラメーターの結果は、Mule アプリケーションを Anypoint Studio からエクスポートするときに ​**\[Include Project Modules and Dependencies (プロジェクトモジュールと連動関係を含める)\]**​ をオフにするのと同じです。 ## [](#複数のパラメーターの指定)複数のパラメーターの指定 パラメーターを結合して、Anypoint Studio にパッケージをインポートし直すためのソースファイルおよびメタデータも含まれる軽量 Mule アプリケーションパッケージを作成することもできます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources -DlightweightPackage ``` ## [](#アプリケーションパッケージからファイルを除外する)アプリケーションパッケージからファイルを除外する アプリケーションをパッケージするときに、特定のファイルまたはディレクトリを除外できます。プロジェクトのルートディレクトリで ​`_muleExclude`​ ファイルを作成し、そのコンテンツを編集して除外ルールを設定します。 `_muleExclude`​ ファイルの各行で、 [glob のパターン](https://docs.oracle.com/javase/tutorial/essential/io/fileOps.html#glob)​に従うルールが指定されます。 たとえば、2 つの除外ルールが含まれる次の ​`_muleExclude`​ ファイルを考えます。 fileToBeExcluded.json \*\*/src/main/resources/local\_directory - 最初の行は、すべてのディレクトリ内の ​`fileToBeExcluded.json`​ という名前のすべてのファイルがアプリケーションパッケージから除外されることを示しています。 - 2 行目は、​`src/main/resources`​ にある ​`local_directory`​ という名前のディレクトリのみがパッケージから除外されることを示しています。 `**/src/main/resources/local_directory`​ が ​`local_directory`​ に置き換えられている場合、プロジェクト内の ​`local_directory`​ という名前のすべてのディレクトリがアプリケーションパッケージから除外されます。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept) # Mule アプリケーションをパッケージする
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule アプリケーションは Mule Maven プラグイン (コマンドライン) または Anypoint Studio を使用してパッケージできます。この手順についての詳細は、​[「Studio からのプロジェクトのエクスポート」](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio)​を参照してください。 Mule アプリケーションはデプロイ可能な JAR ファイルにパッケージされ、このパッケージを後から実行中の Mule Runtime Engine にデプロイできます。パッケージには、アプリケーションによって必要とされる JAR ファイルであるかそのプラグインによって必要とされる JAR ファイルであるかに関係なく、アプリケーションおよびそのすべての連動関係が含まれます。 すべての Mule アプリケーションには 2 つの記述子があります。これらの記述子により、Mule アプリケーションの連動関係が定義されます。 - `mule-artifact.json`​ ファイル。 このファイルは、アプリケーションがどのように構成されるかを記述します。 - `pom.xml`​ ファイル。 このファイルは、パッケージが正常に機能するために必要なすべての連動関係を記述します。 ## [](#互換性)互換性 Mule 4 アプリケーションは次の Anypoint Studio と Mule Maven プラグインバージョンと互換性があります。 - Anypoint Studio 7.x - Mule Maven プラグイン 3.x ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept#add-mmp)​を参照してください。 ## [](#mule-アプリケーション構造リファレンス)Mule アプリケーション構造リファレンス デザインタイムに、Mule アプリケーションには少なくとも次の 3 つの基本的なコンポーネントが必要です。
コンポーネント 型 説明

src

フォルダー

アプリケーションの本番ソースコードおよびテストのソースディレクトリ。
このフォルダーについては、下記のリファレンスを参照してください。

pom.xml

Descriptor (記述子)

Mule アプリケーションの POM ファイル。
このファイルは、アプリケーションのすべての必須の連動関係を記述します。

mule-artifact.json

Descriptor (記述子)

Mule アプリケーションの mule-artifact ファイル。
このファイルは、Mule アプリケーションがどのように構成されるかを記述します。
これらの 3 つのコンポーネントは必須です。このいずれか 1 つが欠落すると、プロジェクトをデプロイ可能な JAR ファイルにパッケージできません。 さらに、パッケージプロセスでは Mule アプリケーションのルートフォルダーにある他のディレクトリまたはファイルが考慮されません。 ## [](#ソースディレクトリリファレンス)ソースディレクトリリファレンス `src`​ ディレクトリには ​`main`​ と ​`test`​ の 2 つの主要なフォルダーがあります。 プラグインはアプリケーションをパッケージするときに ​`src`​ 内の他のディレクトリを考慮しません。 ### [](#srcmain)src/main src/main はアプリケーションのすべての本番ソースコードのルートフォルダーです。
フォルダー フォルダー種別 説明

src/main/mule

ソース

Mule 設定ファイルのルートフォルダー。
Java パッケージの形式で、ネストされたフォルダーを含むことができます。

このフォルダーは必須です。

src/main/resources

resource (リソース)

XML、JSON、プロパティファイルなどのアプリケーションリソースが含まれます。
ここに配置された Jar ファイルはアプリケーションクラスローダーによって読み込まれますが、プレーンファイルリソースとして読み込まれます。
パッケージプロセスにより、​`src/main/mule`​ および ​`src/main/resources`​ 内のすべてのファイルがバイナリパッケージのルートディレクトリに送信されます。 `src/main/mule`​ 内のネストされたフォルダーは、バイナリパッケージのルートディレクトリ内のディレクトリとして保持されます。 ### [](#srctest)src/test src/test はアプリケーションのすべてのテストソースコードのルートフォルダーです。
フォルダー フォルダー種別 説明

src/test/java

ソース

アプリケーションのカスタム Java コードを検証するために使用されるテストクラスのルートフォルダーです。
通常の Java アプリケーションの規則に従います。

src/test/munit

ソース

MUnit ソースコードが含まれます。
パッケージの形式で、ネストされたフォルダーを含むことができます。

src/test/resources

resource (リソース)

XML、JSON、プロパティファイルなどのリソースが含まれます。
このフォルダーには、​mule-config.xml​ で参照されるメタデータを記述するファイルも含まれます。
## [](#mule-アプリケーションをパッケージする)Mule アプリケーションをパッケージする プロジェクトのフォルダーのコマンドラインから、パッケージゴールを実行します。 ```console mvn clean package ``` このプラグインはアプリケーションをプロジェクトのフォルダー内の対象ディレクトリにパッケージし、デプロイ可能な JAR ファイルを作成します。
pom.xml​ に連動関係バージョンの競合がある場合、最新バージョンが使用されます。
## [](#anypoint-studio-にインポートするアプリケーションパッケージの作成)Anypoint Studio にインポートするアプリケーションパッケージの作成 Anypoint Studio にインポートできる JAR ファイルを生成するには、​`-DattachMuleSources`​ パラメーターを使用してアプリケーションをパッケージ化し、デプロイ可能ファイルをオープン Mule プロジェクトとしてワークスペースに再インポートするために Studio で必要とされるソースファイルおよびメタデータを含める必要があります。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources ``` `-DattachMuleSources`​ パラメーターにより、デザインタイムにアプリケーション構造の正確なコピーを使用して ​`META-INF`​ ディレクトリ内に ​`mule-src`​ フォルダーを追加するようプラグインに指示されます。このオプションにより、Mule Runtime Engine にデプロイできる機能する Mule のデプロイ可能なアーカイブファイルを作成するために必要なプロジェクトモジュールおよび連動関係もパッケージ化されます。 ## [](#軽量パッケージの作成)軽量パッケージの作成 Mule Runtime Engine で Mule アプリケーションを実行するために必要な実際のモジュールおよび外部連動関係のバンドルをスキップして、Anypoint Studio に JAR パッケージをインポートし直すために必要なソースファイルおよびメタデータのみの軽量パッケージを作成できます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DlightweightPackage ``` このパラメーターを指定すると、プラグインによって Mule アプリケーションの ​`pom.xml`​ ファイルで宣言された連動関係を含まない軽量 JAR ファイルが作成されます。この JAR ファイルを Mule Runtime Engine にデプロイすることはできず、Mule アプリケーションのソースファイルのみをアーカイブすることができます。この Maven パラメーターの結果は、Mule アプリケーションを Anypoint Studio からエクスポートするときに ​**\[Include Project Modules and Dependencies (プロジェクトモジュールと連動関係を含める)\]**​ をオフにするのと同じです。 ## [](#複数のパラメーターの指定)複数のパラメーターの指定 パラメーターを結合して、Anypoint Studio にパッケージをインポートし直すためのソースファイルおよびメタデータも含まれる軽量 Mule アプリケーションパッケージを作成することもできます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources -DlightweightPackage ``` ## [](#アプリケーションパッケージからファイルを除外する)アプリケーションパッケージからファイルを除外する アプリケーションをパッケージするときに、特定のファイルまたはディレクトリを除外できます。プロジェクトのルートディレクトリで ​`_muleExclude`​ ファイルを作成し、そのコンテンツを編集して除外ルールを設定します。 `_muleExclude`​ ファイルの各行で、 [glob のパターン](https://docs.oracle.com/javase/tutorial/essential/io/fileOps.html#glob)​に従うルールが指定されます。 たとえば、2 つの除外ルールが含まれる次の ​`_muleExclude`​ ファイルを考えます。 fileToBeExcluded.json \*\*/src/main/resources/local\_directory - 最初の行は、すべてのディレクトリ内の ​`fileToBeExcluded.json`​ という名前のすべてのファイルがアプリケーションパッケージから除外されることを示しています。 - 2 行目は、​`src/main/resources`​ にある ​`local_directory`​ という名前のディレクトリのみがパッケージから除外されることを示しています。 `**/src/main/resources/local_directory`​ が ​`local_directory`​ に置き換えられている場合、プロジェクト内の ​`local_directory`​ という名前のすべてのディレクトリがアプリケーションパッケージから除外されます。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept) # Mule アプリケーションをパッケージする
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule アプリケーションは Mule Maven プラグイン (コマンドライン) または Anypoint Studio を使用してパッケージできます。この手順についての詳細は、​[「Studio からのプロジェクトのエクスポート」](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio)​を参照してください。 Mule アプリケーションはデプロイ可能な JAR ファイルにパッケージされ、このパッケージを後から実行中の Mule Runtime Engine にデプロイできます。パッケージには、アプリケーションによって必要とされる JAR ファイルであるかそのプラグインによって必要とされる JAR ファイルであるかに関係なく、アプリケーションおよびそのすべての連動関係が含まれます。 すべての Mule アプリケーションには 2 つの記述子があります。これらの記述子により、Mule アプリケーションの連動関係が定義されます。 - `mule-artifact.json`​ ファイル。 このファイルは、アプリケーションがどのように構成されるかを記述します。 - `pom.xml`​ ファイル。 このファイルは、パッケージが正常に機能するために必要なすべての連動関係を記述します。 ## [](#互換性)互換性 Mule 4 アプリケーションは次の Anypoint Studio と Mule Maven プラグインバージョンと互換性があります。 - Anypoint Studio 7.x - Mule Maven プラグイン 3.x ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept#add-mmp)​を参照してください。 ## [](#mule-アプリケーション構造リファレンス)Mule アプリケーション構造リファレンス デザインタイムに、Mule アプリケーションには少なくとも次の 3 つの基本的なコンポーネントが必要です。
コンポーネント 型 説明

src

フォルダー

アプリケーションの本番ソースコードおよびテストのソースディレクトリ。
このフォルダーについては、下記のリファレンスを参照してください。

pom.xml

Descriptor (記述子)

Mule アプリケーションの POM ファイル。
このファイルは、アプリケーションのすべての必須の連動関係を記述します。

mule-artifact.json

Descriptor (記述子)

Mule アプリケーションの mule-artifact ファイル。
このファイルは、Mule アプリケーションがどのように構成されるかを記述します。
これらの 3 つのコンポーネントは必須です。このいずれか 1 つが欠落すると、プロジェクトをデプロイ可能な JAR ファイルにパッケージできません。 さらに、パッケージプロセスでは Mule アプリケーションのルートフォルダーにある他のディレクトリまたはファイルが考慮されません。 ## [](#ソースディレクトリリファレンス)ソースディレクトリリファレンス `src`​ ディレクトリには ​`main`​ と ​`test`​ の 2 つの主要なフォルダーがあります。 プラグインはアプリケーションをパッケージするときに ​`src`​ 内の他のディレクトリを考慮しません。 ### [](#srcmain)src/main src/main はアプリケーションのすべての本番ソースコードのルートフォルダーです。
フォルダー フォルダー種別 説明

src/main/mule

ソース

Mule 設定ファイルのルートフォルダー。
Java パッケージの形式で、ネストされたフォルダーを含むことができます。

このフォルダーは必須です。

src/main/resources

resource (リソース)

XML、JSON、プロパティファイルなどのアプリケーションリソースが含まれます。
ここに配置された Jar ファイルはアプリケーションクラスローダーによって読み込まれますが、プレーンファイルリソースとして読み込まれます。
パッケージプロセスにより、​`src/main/mule`​ および ​`src/main/resources`​ 内のすべてのファイルがバイナリパッケージのルートディレクトリに送信されます。 `src/main/mule`​ 内のネストされたフォルダーは、バイナリパッケージのルートディレクトリ内のディレクトリとして保持されます。 ### [](#srctest)src/test src/test はアプリケーションのすべてのテストソースコードのルートフォルダーです。
フォルダー フォルダー種別 説明

src/test/java

ソース

アプリケーションのカスタム Java コードを検証するために使用されるテストクラスのルートフォルダーです。
通常の Java アプリケーションの規則に従います。

src/test/munit

ソース

MUnit ソースコードが含まれます。
パッケージの形式で、ネストされたフォルダーを含むことができます。

src/test/resources

resource (リソース)

XML、JSON、プロパティファイルなどのリソースが含まれます。
このフォルダーには、​mule-config.xml​ で参照されるメタデータを記述するファイルも含まれます。
## [](#mule-アプリケーションをパッケージする)Mule アプリケーションをパッケージする プロジェクトのフォルダーのコマンドラインから、パッケージゴールを実行します。 ```console mvn clean package ``` このプラグインはアプリケーションをプロジェクトのフォルダー内の対象ディレクトリにパッケージし、デプロイ可能な JAR ファイルを作成します。
pom.xml​ に連動関係バージョンの競合がある場合、最新バージョンが使用されます。
## [](#anypoint-studio-にインポートするアプリケーションパッケージの作成)Anypoint Studio にインポートするアプリケーションパッケージの作成 Anypoint Studio にインポートできる JAR ファイルを生成するには、​`-DattachMuleSources`​ パラメーターを使用してアプリケーションをパッケージ化し、デプロイ可能ファイルをオープン Mule プロジェクトとしてワークスペースに再インポートするために Studio で必要とされるソースファイルおよびメタデータを含める必要があります。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources ``` `-DattachMuleSources`​ パラメーターにより、デザインタイムにアプリケーション構造の正確なコピーを使用して ​`META-INF`​ ディレクトリ内に ​`mule-src`​ フォルダーを追加するようプラグインに指示されます。このオプションにより、Mule Runtime Engine にデプロイできる機能する Mule のデプロイ可能なアーカイブファイルを作成するために必要なプロジェクトモジュールおよび連動関係もパッケージ化されます。 ## [](#軽量パッケージの作成)軽量パッケージの作成 Mule Runtime Engine で Mule アプリケーションを実行するために必要な実際のモジュールおよび外部連動関係のバンドルをスキップして、Anypoint Studio に JAR パッケージをインポートし直すために必要なソースファイルおよびメタデータのみの軽量パッケージを作成できます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DlightweightPackage ``` このパラメーターを指定すると、プラグインによって Mule アプリケーションの ​`pom.xml`​ ファイルで宣言された連動関係を含まない軽量 JAR ファイルが作成されます。この JAR ファイルを Mule Runtime Engine にデプロイすることはできず、Mule アプリケーションのソースファイルのみをアーカイブすることができます。この Maven パラメーターの結果は、Mule アプリケーションを Anypoint Studio からエクスポートするときに ​**\[Include Project Modules and Dependencies (プロジェクトモジュールと連動関係を含める)\]**​ をオフにするのと同じです。 ## [](#複数のパラメーターの指定)複数のパラメーターの指定 パラメーターを結合して、Anypoint Studio にパッケージをインポートし直すためのソースファイルおよびメタデータも含まれる軽量 Mule アプリケーションパッケージを作成することもできます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources -DlightweightPackage ``` ## [](#アプリケーションパッケージからファイルを除外する)アプリケーションパッケージからファイルを除外する アプリケーションをパッケージするときに、特定のファイルまたはディレクトリを除外できます。プロジェクトのルートディレクトリで ​`_muleExclude`​ ファイルを作成し、そのコンテンツを編集して除外ルールを設定します。 `_muleExclude`​ ファイルの各行で、 [glob のパターン](https://docs.oracle.com/javase/tutorial/essential/io/fileOps.html#glob)​に従うルールが指定されます。 たとえば、2 つの除外ルールが含まれる次の ​`_muleExclude`​ ファイルを考えます。 fileToBeExcluded.json \*\*/src/main/resources/local\_directory - 最初の行は、すべてのディレクトリ内の ​`fileToBeExcluded.json`​ という名前のすべてのファイルがアプリケーションパッケージから除外されることを示しています。 - 2 行目は、​`src/main/resources`​ にある ​`local_directory`​ という名前のディレクトリのみがパッケージから除外されることを示しています。 `**/src/main/resources/local_directory`​ が ​`local_directory`​ に置き換えられている場合、プロジェクト内の ​`local_directory`​ という名前のすべてのディレクトリがアプリケーションパッケージから除外されます。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept) # Mule アプリケーションをパッケージする
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule アプリケーションは Mule Maven プラグイン (コマンドライン) または Anypoint Studio を使用してパッケージできます。この手順についての詳細は、​[「Studio からのプロジェクトのエクスポート」](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio)​を参照してください。 Mule アプリケーションはデプロイ可能な JAR ファイルにパッケージされ、このパッケージを後から実行中の Mule Runtime Engine にデプロイできます。パッケージには、アプリケーションによって必要とされる JAR ファイルであるかそのプラグインによって必要とされる JAR ファイルであるかに関係なく、アプリケーションおよびそのすべての連動関係が含まれます。 すべての Mule アプリケーションには 2 つの記述子があります。これらの記述子により、Mule アプリケーションの連動関係が定義されます。 - `mule-artifact.json`​ ファイル。 このファイルは、アプリケーションがどのように構成されるかを記述します。 - `pom.xml`​ ファイル。 このファイルは、パッケージが正常に機能するために必要なすべての連動関係を記述します。 ## [](#互換性)互換性 Mule 4 アプリケーションは次の Anypoint Studio と Mule Maven プラグインバージョンと互換性があります。 - Anypoint Studio 7.x - Mule Maven プラグイン 3.x ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept#add-mmp)​を参照してください。 ## [](#mule-アプリケーション構造リファレンス)Mule アプリケーション構造リファレンス デザインタイムに、Mule アプリケーションには少なくとも次の 3 つの基本的なコンポーネントが必要です。
コンポーネント 型 説明

src

フォルダー

アプリケーションの本番ソースコードおよびテストのソースディレクトリ。
このフォルダーについては、下記のリファレンスを参照してください。

pom.xml

Descriptor (記述子)

Mule アプリケーションの POM ファイル。
このファイルは、アプリケーションのすべての必須の連動関係を記述します。

mule-artifact.json

Descriptor (記述子)

Mule アプリケーションの mule-artifact ファイル。
このファイルは、Mule アプリケーションがどのように構成されるかを記述します。
これらの 3 つのコンポーネントは必須です。このいずれか 1 つが欠落すると、プロジェクトをデプロイ可能な JAR ファイルにパッケージできません。 さらに、パッケージプロセスでは Mule アプリケーションのルートフォルダーにある他のディレクトリまたはファイルが考慮されません。 ## [](#ソースディレクトリリファレンス)ソースディレクトリリファレンス `src`​ ディレクトリには ​`main`​ と ​`test`​ の 2 つの主要なフォルダーがあります。 プラグインはアプリケーションをパッケージするときに ​`src`​ 内の他のディレクトリを考慮しません。 ### [](#srcmain)src/main src/main はアプリケーションのすべての本番ソースコードのルートフォルダーです。
フォルダー フォルダー種別 説明

src/main/mule

source

Mule 設定ファイルのルートフォルダー。
Java パッケージの形式で、ネストされたフォルダーを含むことができます。

このフォルダーは必須です。

src/main/resources

resource

XML、JSON、プロパティファイルなどのアプリケーションリソースが含まれます。
ここに配置された Jar ファイルはアプリケーションクラスローダーによって読み込まれますが、プレーンファイルリソースとして読み込まれます。
パッケージプロセスにより、​`src/main/mule`​ および ​`src/main/resources`​ 内のすべてのファイルがバイナリパッケージのルートディレクトリに送信されます。 `src/main/mule`​ 内のネストされたフォルダーは、バイナリパッケージのルートディレクトリ内のディレクトリとして保持されます。 ### [](#srctest)src/test src/test はアプリケーションのすべてのテストソースコードのルートフォルダーです。
フォルダー フォルダー種別 説明

src/test/java

source

アプリケーションのカスタム Java コードを検証するために使用されるテストクラスのルートフォルダーです。
通常の Java アプリケーションの規則に従います。

src/test/munit

source

MUnit ソースコードが含まれます。
パッケージの形式で、ネストされたフォルダーを含むことができます。

src/test/resources

resource

XML、JSON、プロパティファイルなどのリソースが含まれます。
このフォルダーには、​mule-config.xml​ で参照されるメタデータを記述するファイルも含まれます。
## [](#mule-アプリケーションをパッケージする)Mule アプリケーションをパッケージする プロジェクトのフォルダーのコマンドラインから、パッケージゴールを実行します。 ```console mvn clean package ``` このプラグインはアプリケーションをプロジェクトのフォルダー内の対象ディレクトリにパッケージし、デプロイ可能な JAR ファイルを作成します。
pom.xml​ に連動関係バージョンの競合がある場合、最新バージョンが使用されます。
## [](#anypoint-studio-にインポートするアプリケーションパッケージの作成)Anypoint Studio にインポートするアプリケーションパッケージの作成 Anypoint Studio にインポートできる JAR ファイルを生成するには、​`-DattachMuleSources`​ パラメーターを使用してアプリケーションをパッケージ化し、デプロイ可能ファイルをオープン Mule プロジェクトとしてワークスペースに再インポートするために Studio で必要とされるソースファイルおよびメタデータを含める必要があります。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources ``` `-DattachMuleSources`​ パラメーターにより、デザインタイムにアプリケーション構造の正確なコピーを使用して ​`META-INF`​ ディレクトリ内に ​`mule-src`​ フォルダーを追加するようプラグインに指示されます。このオプションにより、Mule Runtime Engine にデプロイできる機能する Mule のデプロイ可能なアーカイブファイルを作成するために必要なプロジェクトモジュールおよび連動関係もパッケージ化されます。 ## [](#軽量パッケージの作成)軽量パッケージの作成 Mule Runtime Engine で Mule アプリケーションを実行するために必要な実際のモジュールおよび外部連動関係のバンドルをスキップして、Anypoint Studio に JAR パッケージをインポートし直すために必要なソースファイルおよびメタデータのみの軽量パッケージを作成できます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DlightweightPackage ``` このパラメーターを指定すると、プラグインによって Mule アプリケーションの ​`pom.xml`​ ファイルで宣言された連動関係を含まない軽量 JAR ファイルが作成されます。この JAR ファイルを Mule Runtime Engine にデプロイすることはできず、Mule アプリケーションのソースファイルのみをアーカイブすることができます。この Maven パラメーターの結果は、Mule アプリケーションを Anypoint Studio からエクスポートするときに ​**\[Include Project Modules and Dependencies (プロジェクトモジュールと連動関係を含める)\]**​ をオフにするのと同じです。 ## [](#複数のパラメーターの指定)複数のパラメーターの指定 パラメーターを結合して、Anypoint Studio にパッケージをインポートし直すためのソースファイルおよびメタデータも含まれる軽量 Mule アプリケーションパッケージを作成することもできます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources -DlightweightPackage ``` ## [](#アプリケーションパッケージからファイルを除外する)アプリケーションパッケージからファイルを除外する アプリケーションをパッケージするときに、特定のファイルまたはディレクトリを除外できます。プロジェクトのルートディレクトリで ​`_muleExclude`​ ファイルを作成し、そのコンテンツを編集して除外ルールを設定します。 `_muleExclude`​ ファイルの各行で、 [glob のパターン](https://docs.oracle.com/javase/tutorial/essential/io/fileOps.html#glob)​に従うルールが指定されます。 たとえば、2 つの除外ルールが含まれる次の ​`_muleExclude`​ ファイルを考えます。 fileToBeExcluded.json \*\*/src/main/resources/local\_directory - 最初の行は、すべてのディレクトリ内の ​`fileToBeExcluded.json`​ という名前のすべてのファイルがアプリケーションパッケージから除外されることを示しています。 - 2 行目は、​`src/main/resources`​ にある ​`local_directory`​ という名前のディレクトリのみがパッケージから除外されることを示しています。 `**/src/main/resources/local_directory`​ が ​`local_directory`​ に置き換えられている場合、プロジェクト内の ​`local_directory`​ という名前のすべてのディレクトリがアプリケーションパッケージから除外されます。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept) # Mule アプリケーションをパッケージする
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule アプリケーションは Mule Maven プラグイン (コマンドライン) または Anypoint Studio を使用してパッケージできます。この手順についての詳細は、​[「Studio からのプロジェクトのエクスポート」](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio)​を参照してください。 Mule アプリケーションはデプロイ可能な JAR ファイルにパッケージされ、このパッケージを後から実行中の Mule Runtime Engine にデプロイできます。パッケージには、アプリケーションによって必要とされる JAR ファイルであるかそのプラグインによって必要とされる JAR ファイルであるかに関係なく、アプリケーションおよびそのすべての連動関係が含まれます。 すべての Mule アプリケーションには 2 つの記述子があります。これらの記述子により、Mule アプリケーションの連動関係が定義されます。 - `mule-artifact.json`​ ファイル。 このファイルは、アプリケーションがどのように構成されるかを記述します。 - `pom.xml`​ ファイル。 このファイルは、パッケージが正常に機能するために必要なすべての連動関係を記述します。 ## [](#互換性)互換性 Mule 4 アプリケーションは次の Anypoint Studio と Mule Maven プラグインバージョンと互換性があります。 - Anypoint Studio 7.x - Mule Maven プラグイン 3.x ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept#add-mmp)​を参照してください。 ## [](#mule-アプリケーション構造リファレンス)Mule アプリケーション構造リファレンス デザインタイムに、Mule アプリケーションには少なくとも次の 3 つの基本的なコンポーネントが必要です。
コンポーネント 種別 説明

src

Folder (フォルダー)

アプリケーションの本番ソースコードおよびテストのソースディレクトリ。
このフォルダーについては、下記のリファレンスを参照してください。

pom.xml

Descriptor (記述子)

Mule アプリケーションの POM ファイル。
このファイルは、アプリケーションのすべての必須の連動関係を記述します。

mule-artifact.json

Descriptor (記述子)

Mule アプリケーションの mule-artifact ファイル。
このファイルは、Mule アプリケーションがどのように構成されるかを記述します。
これらの 3 つのコンポーネントは必須です。このいずれか 1 つが欠落すると、プロジェクトをデプロイ可能な JAR ファイルにパッケージできません。 さらに、パッケージプロセスでは Mule アプリケーションのルートフォルダーにある他のディレクトリまたはファイルが考慮されません。 ## [](#ソースディレクトリリファレンス)ソースディレクトリリファレンス `src`​ ディレクトリには ​`main`​ と ​`test`​ の 2 つの主要なフォルダーがあります。 プラグインはアプリケーションをパッケージするときに ​`src`​ 内の他のディレクトリを考慮しません。 ### [](#srcmain)src/main src/main はアプリケーションのすべての本番ソースコードのルートフォルダーです。
Folder (フォルダー) フォルダー種別 説明

src/main/mule

source (ソース)

Mule 設定ファイルのルートフォルダー。
Java パッケージの形式で、ネストされたフォルダーを含むことができます。

このフォルダーは必須です。

src/main/resources

resource (リソース)

XML、JSON、プロパティファイルなどのアプリケーションリソースが含まれます。
ここに配置された Jar ファイルはアプリケーションクラスローダーによって読み込まれますが、プレーンファイルリソースとして読み込まれます。
パッケージプロセスにより、​`src/main/mule`​ および ​`src/main/resources`​ 内のすべてのファイルがバイナリパッケージのルートディレクトリに送信されます。 `src/main/mule`​ 内のネストされたフォルダーは、バイナリパッケージのルートディレクトリ内のディレクトリとして保持されます。 ### [](#srctest)src/test src/test はアプリケーションのすべてのテストソースコードのルートフォルダーです。
Folder (フォルダー) フォルダー種別 説明

src/test/java

source (ソース)

アプリケーションのカスタム Java コードを検証するために使用されるテストクラスのルートフォルダーです。
通常の Java アプリケーションの規則に従います。

src/test/munit

source (ソース)

MUnit ソースコードが含まれます。
パッケージの形式で、ネストされたフォルダーを含むことができます。

src/test/resources

resource (リソース)

XML、JSON、プロパティファイルなどのリソースが含まれます。
このフォルダーには、​mule-config.xml​ で参照されるメタデータを記述するファイルも含まれます。
## [](#mule-アプリケーションをパッケージする)Mule アプリケーションをパッケージする プロジェクトのフォルダーのコマンドラインから、パッケージゴールを実行します。 ```console mvn clean package ``` このプラグインはアプリケーションをプロジェクトのフォルダー内の対象ディレクトリにパッケージし、デプロイ可能な JAR ファイルを作成します。
pom.xml​ に連動関係バージョンの競合がある場合、最新バージョンが使用されます。
## [](#anypoint-studio-にインポートするアプリケーションパッケージの作成)Anypoint Studio にインポートするアプリケーションパッケージの作成 Anypoint Studio にインポートできる JAR ファイルを生成するには、​`-DattachMuleSources`​ パラメーターを使用してアプリケーションをパッケージ化し、デプロイ可能ファイルをオープン Mule プロジェクトとしてワークスペースに再インポートするために Studio で必要とされるソースファイルおよびメタデータを含める必要があります。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources ``` `-DattachMuleSources`​ パラメーターにより、デザインタイムにアプリケーション構造の正確なコピーを使用して ​`META-INF`​ ディレクトリ内に ​`mule-src`​ フォルダーを追加するようプラグインに指示されます。このオプションにより、Mule Runtime Engine にデプロイできる機能する Mule のデプロイ可能なアーカイブファイルを作成するために必要なプロジェクトモジュールおよび連動関係もパッケージ化されます。 ## [](#軽量パッケージの作成)軽量パッケージの作成 Mule Runtime Engine で Mule アプリケーションを実行するために必要な実際のモジュールおよび外部連動関係のバンドルをスキップして、Anypoint Studio に JAR パッケージをインポートし直すために必要なソースファイルおよびメタデータのみの軽量パッケージを作成できます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DlightweightPackage ``` このパラメーターを指定すると、プラグインによって Mule アプリケーションの ​`pom.xml`​ ファイルで宣言された連動関係を含まない軽量 JAR ファイルが作成されます。この JAR ファイルを Mule Runtime Engine にデプロイすることはできず、Mule アプリケーションのソースファイルのみをアーカイブすることができます。この Maven パラメーターの結果は、Mule アプリケーションを Anypoint Studio からエクスポートするときに ​**\[Include Project Modules and Dependencies (プロジェクトモジュールと連動関係を含める)\]**​ をオフにするのと同じです。 ## [](#複数のパラメーターの指定)複数のパラメーターの指定 パラメーターを結合して、Anypoint Studio にパッケージをインポートし直すためのソースファイルおよびメタデータも含まれる軽量 Mule アプリケーションパッケージを作成することもできます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources -DlightweightPackage ``` ## [](#アプリケーションパッケージからファイルを除外する)アプリケーションパッケージからファイルを除外する アプリケーションをパッケージするときに、特定のファイルまたはディレクトリを除外できます。プロジェクトのルートディレクトリで ​`_muleExclude`​ ファイルを作成し、そのコンテンツを編集して除外ルールを設定します。 `_muleExclude`​ ファイルの各行で、 [glob のパターン](https://docs.oracle.com/javase/tutorial/essential/io/fileOps.html#glob)​に従うルールが指定されます。 たとえば、2 つの除外ルールが含まれる次の ​`_muleExclude`​ ファイルを考えます。 fileToBeExcluded.json \*\*/src/main/resources/local\_directory - 最初の行は、すべてのディレクトリ内の ​`fileToBeExcluded.json`​ という名前のすべてのファイルがアプリケーションパッケージから除外されることを示しています。 - 2 行目は、​`src/main/resources`​ にある ​`local_directory`​ という名前のディレクトリのみがパッケージから除外されることを示しています。 `**/src/main/resources/local_directory`​ が ​`local_directory`​ に置き換えられている場合、プロジェクト内の ​`local_directory`​ という名前のすべてのディレクトリがアプリケーションパッケージから除外されます。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept) # Mule アプリケーションをパッケージする
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule アプリケーションは Mule Maven プラグイン (コマンドライン) または Anypoint Studio を使用してパッケージできます。この手順についての詳細は、​[「Studio からのプロジェクトのエクスポート」](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio)​を参照してください。 Mule アプリケーションはデプロイ可能な JAR ファイルにパッケージされ、このパッケージを後から実行中の Mule Runtime Engine にデプロイできます。パッケージには、アプリケーションによって必要とされる JAR ファイルであるかそのプラグインによって必要とされる JAR ファイルであるかに関係なく、アプリケーションおよびそのすべての連動関係が含まれます。 すべての Mule アプリケーションには 2 つの記述子があります。これらの記述子により、Mule アプリケーションの連動関係が定義されます。 - `mule-artifact.json`​ ファイル。 このファイルは、アプリケーションがどのように構成されるかを記述します。 - `pom.xml`​ ファイル。 このファイルは、パッケージが正常に機能するために必要なすべての連動関係を記述します。 ## [](#互換性)互換性 Mule 4 アプリケーションは次の Anypoint Studio と Mule Maven プラグインバージョンと互換性があります。 - Anypoint Studio 7.x - Mule Maven プラグイン 3.x ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept#add-mmp)​を参照してください。 ## [](#mule-アプリケーション構造リファレンス)Mule アプリケーション構造リファレンス デザインタイムに、Mule アプリケーションには少なくとも次の 3 つの基本的なコンポーネントが必要です。
コンポーネント 種別 説明

src

Folder (フォルダー)

アプリケーションの本番ソースコードおよびテストのソースディレクトリ。
このフォルダーについては、下記のリファレンスを参照してください。

pom.xml

Descriptor (記述子)

Mule アプリケーションの POM ファイル。
このファイルは、アプリケーションのすべての必須の連動関係を記述します。

mule-artifact.json

Descriptor (記述子)

Mule アプリケーションの mule-artifact ファイル。
このファイルは、Mule アプリケーションがどのように構成されるかを記述します。
これらの 3 つのコンポーネントは必須です。このいずれか 1 つが欠落すると、プロジェクトをデプロイ可能な JAR ファイルにパッケージできません。 さらに、パッケージプロセスでは Mule アプリケーションのルートフォルダーにある他のディレクトリまたはファイルが考慮されません。 ## [](#ソースディレクトリリファレンス)ソースディレクトリリファレンス `src`​ ディレクトリには ​`main`​ と ​`test`​ の 2 つの主要なフォルダーがあります。 プラグインはアプリケーションをパッケージするときに ​`src`​ 内の他のディレクトリを考慮しません。 ### [](#srcmain)src/main src/main はアプリケーションのすべての本番ソースコードのルートフォルダーです。
Folder (フォルダー) フォルダー種別 説明

src/main/mule

source (ソース)

Mule 設定ファイルのルートフォルダー。
Java パッケージの形式で、ネストされたフォルダーを含むことができます。

このフォルダーは必須です。

src/main/resources

resource (リソース)

XML、JSON、プロパティファイルなどのアプリケーションリソースが含まれます。
ここに配置された Jar ファイルはアプリケーションクラスローダーによって読み込まれますが、プレーンファイルリソースとして読み込まれます。
パッケージプロセスにより、​`src/main/mule`​ および ​`src/main/resources`​ 内のすべてのファイルがバイナリパッケージのルートディレクトリに送信されます。 `src/main/mule`​ 内のネストされたフォルダーは、バイナリパッケージのルートディレクトリ内のディレクトリとして保持されます。 ### [](#srctest)src/test src/test はアプリケーションのすべてのテストソースコードのルートフォルダーです。
Folder (フォルダー) フォルダー種別 説明

src/test/java

source (ソース)

アプリケーションのカスタム Java コードを検証するために使用されるテストクラスのルートフォルダーです。
通常の Java アプリケーションの規則に従います。

src/test/munit

source (ソース)

MUnit ソースコードが含まれます。
パッケージの形式で、ネストされたフォルダーを含むことができます。

src/test/resources

resource (リソース)

XML、JSON、プロパティファイルなどのリソースが含まれます。
このフォルダーには、​mule-config.xml​ で参照されるメタデータを記述するファイルも含まれます。
## [](#mule-アプリケーションをパッケージする)Mule アプリケーションをパッケージする プロジェクトのフォルダーのコマンドラインから、パッケージゴールを実行します。 ```console mvn clean package ``` このプラグインはアプリケーションをプロジェクトのフォルダー内の対象ディレクトリにパッケージし、デプロイ可能な JAR ファイルを作成します。
pom.xml​ に連動関係バージョンの競合がある場合、最新バージョンが使用されます。
## [](#anypoint-studio-にインポートするアプリケーションパッケージの作成)Anypoint Studio にインポートするアプリケーションパッケージの作成 Anypoint Studio にインポートできる JAR ファイルを生成するには、​`-DattachMuleSources`​ パラメーターを使用してアプリケーションをパッケージ化し、デプロイ可能ファイルをオープン Mule プロジェクトとしてワークスペースに再インポートするために Studio で必要とされるソースファイルおよびメタデータを含める必要があります。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources ``` `-DattachMuleSources`​ パラメーターにより、デザインタイムにアプリケーション構造の正確なコピーを使用して ​`META-INF`​ ディレクトリ内に ​`mule-src`​ フォルダーを追加するようプラグインに指示されます。このオプションにより、Mule Runtime Engine にデプロイできる機能する Mule のデプロイ可能なアーカイブファイルを作成するために必要なプロジェクトモジュールおよび連動関係もパッケージ化されます。 ## [](#軽量パッケージの作成)軽量パッケージの作成 Mule Runtime Engine で Mule アプリケーションを実行するために必要な実際のモジュールおよび外部連動関係のバンドルをスキップして、Anypoint Studio に JAR パッケージをインポートし直すために必要なソースファイルおよびメタデータのみの軽量パッケージを作成できます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DlightweightPackage ``` このパラメーターを指定すると、プラグインによって Mule アプリケーションの ​`pom.xml`​ ファイルで宣言された連動関係を含まない軽量 JAR ファイルが作成されます。この JAR ファイルを Mule Runtime Engine にデプロイすることはできず、Mule アプリケーションのソースファイルのみをアーカイブすることができます。この Maven パラメーターの結果は、Mule アプリケーションを Anypoint Studio からエクスポートするときに ​**\[Include Project Modules and Dependencies (プロジェクトモジュールと連動関係を含める)\]**​ をオフにするのと同じです。 ## [](#複数のパラメーターの指定)複数のパラメーターの指定 パラメーターを結合して、Anypoint Studio にパッケージをインポートし直すためのソースファイルおよびメタデータも含まれる軽量 Mule アプリケーションパッケージを作成することもできます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources -DlightweightPackage ``` ## [](#アプリケーションパッケージからファイルを除外する)アプリケーションパッケージからファイルを除外する アプリケーションをパッケージするときに、特定のファイルまたはディレクトリを除外できます。プロジェクトのルートディレクトリで ​`_muleExclude`​ ファイルを作成し、そのコンテンツを編集して除外ルールを設定します。 `_muleExclude`​ ファイルの各行で、 [glob のパターン](https://docs.oracle.com/javase/tutorial/essential/io/fileOps.html#glob)​に従うルールが指定されます。 たとえば、2 つの除外ルールが含まれる次の ​`_muleExclude`​ ファイルを考えます。 fileToBeExcluded.json \*\*/src/main/resources/local\_directory - 最初の行は、すべてのディレクトリ内の ​`fileToBeExcluded.json`​ という名前のすべてのファイルがアプリケーションパッケージから除外されることを示しています。 - 2 行目は、​`src/main/resources`​ にある ​`local_directory`​ という名前のディレクトリのみがパッケージから除外されることを示しています。 `**/src/main/resources/local_directory`​ が ​`local_directory`​ に置き換えられている場合、プロジェクト内の ​`local_directory`​ という名前のすべてのディレクトリがアプリケーションパッケージから除外されます。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept) # Mule アプリケーションをパッケージする
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Mule アプリケーションは Mule Maven プラグイン (コマンドライン) または Anypoint Studio を使用してパッケージできます。この手順についての詳細は、​[「Studio からのプロジェクトのエクスポート」](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio)​を参照してください。 Mule アプリケーションはデプロイ可能な JAR ファイルにパッケージされ、このパッケージを後から実行中の Mule Runtime Engine にデプロイできます。パッケージには、アプリケーションによって必要とされる JAR ファイルであるかそのプラグインによって必要とされる JAR ファイルであるかに関係なく、アプリケーションおよびそのすべての連動関係が含まれます。 すべての Mule アプリケーションには 2 つの記述子があります。これらの記述子により、Mule アプリケーションの連動関係が定義されます。 - `mule-artifact.json`​ ファイル。 このファイルは、アプリケーションがどのように構成されるかを記述します。 - `pom.xml`​ ファイル。 このファイルは、パッケージが正常に機能するために必要なすべての連動関係を記述します。 ## [](#互換性)互換性 Mule 4 アプリケーションは次の Anypoint Studio と Mule Maven プラグインバージョンと互換性があります。 - Anypoint Studio 7.x - Mule Maven プラグイン 3.x ## [](#前提条件)前提条件 - Mule Maven プラグインをプロジェクトに追加する 手順については、​[「Mule Maven プラグインを Mule プロジェクトに追加する」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept#add-mmp)​を参照してください。 ## [](#mule-アプリケーション構造リファレンス)Mule アプリケーション構造リファレンス デザインタイムに、Mule アプリケーションには少なくとも次の 3 つの基本的なコンポーネントが必要です。
コンポーネント 種別 説明

src

Folder (フォルダー)

アプリケーションの本番ソースコードおよびテストのソースディレクトリ。
このフォルダーについては、下記のリファレンスを参照してください。

pom.xml

Descriptor (記述子)

Mule アプリケーションの POM ファイル。
このファイルは、アプリケーションのすべての必須の連動関係を記述します。

mule-artifact.json

Descriptor (記述子)

Mule アプリケーションの mule-artifact ファイル。
このファイルは、Mule アプリケーションがどのように構成されるかを記述します。
これらの 3 つのコンポーネントは必須です。このいずれか 1 つが欠落すると、プロジェクトをデプロイ可能な JAR ファイルにパッケージできません。 さらに、パッケージプロセスでは Mule アプリケーションのルートフォルダーにある他のディレクトリまたはファイルが考慮されません。 ## [](#ソースディレクトリリファレンス)ソースディレクトリリファレンス `src`​ ディレクトリには ​`main`​ と ​`test`​ の 2 つの主要なフォルダーがあります。 プラグインはアプリケーションをパッケージするときに ​`src`​ 内の他のディレクトリを考慮しません。 ### [](#srcmain)src/main src/main はアプリケーションのすべての本番ソースコードのルートフォルダーです。
Folder (フォルダー) フォルダー種別 説明

src/main/mule

source (ソース)

Mule 設定ファイルのルートフォルダー。
Java パッケージの形式で、ネストされたフォルダーを含むことができます。

このフォルダーは必須です。

src/main/resources

resource (リソース)

XML、JSON、プロパティファイルなどのアプリケーションリソースが含まれます。
ここに配置された Jar ファイルはアプリケーションクラスローダーによって読み込まれますが、プレーンファイルリソースとして読み込まれます。
パッケージプロセスにより、​`src/main/mule`​ および ​`src/main/resources`​ 内のすべてのファイルがバイナリパッケージのルートディレクトリに送信されます。 `src/main/mule`​ 内のネストされたフォルダーは、バイナリパッケージのルートディレクトリ内のディレクトリとして保持されます。 ### [](#srctest)src/test src/test はアプリケーションのすべてのテストソースコードのルートフォルダーです。
Folder (フォルダー) フォルダー種別 説明

src/test/java

source (ソース)

アプリケーションのカスタム Java コードを検証するために使用されるテストクラスのルートフォルダーです。
通常の Java アプリケーションの規則に従います。

src/test/munit

source (ソース)

MUnit ソースコードが含まれます。
パッケージの形式で、ネストされたフォルダーを含むことができます。

src/test/resources

resource (リソース)

XML、JSON、プロパティファイルなどのリソースが含まれます。
このフォルダーには、​mule-config.xml​ で参照されるメタデータを記述するファイルも含まれます。
## [](#mule-アプリケーションをパッケージする)Mule アプリケーションをパッケージする プロジェクトのフォルダーのコマンドラインから、パッケージゴールを実行します。 ```console mvn clean package ``` このプラグインはアプリケーションをプロジェクトのフォルダー内の対象ディレクトリにパッケージし、デプロイ可能な JAR ファイルを作成します。
pom.xml​ に連動関係バージョンの競合がある場合、最新バージョンが使用されます。
## [](#anypoint-studio-にインポートするアプリケーションパッケージの作成)Anypoint Studio にインポートするアプリケーションパッケージの作成 Anypoint Studio にインポートできる JAR ファイルを生成するには、​`-DattachMuleSources`​ パラメーターを使用してアプリケーションをパッケージ化し、デプロイ可能ファイルをオープン Mule プロジェクトとしてワークスペースに再インポートするために Studio で必要とされるソースファイルおよびメタデータを含める必要があります。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources ``` `-DattachMuleSources`​ パラメーターにより、デザインタイムにアプリケーション構造の正確なコピーを使用して ​`META-INF`​ ディレクトリ内に ​`mule-src`​ フォルダーを追加するようプラグインに指示されます。このオプションにより、Mule Runtime Engine にデプロイできる機能する Mule のデプロイ可能なアーカイブファイルを作成するために必要なプロジェクトモジュールおよび連動関係もパッケージ化されます。 ## [](#軽量パッケージの作成)軽量パッケージの作成 Mule Runtime Engine で Mule アプリケーションを実行するために必要な実際のモジュールおよび外部連動関係のバンドルをスキップして、Anypoint Studio に JAR パッケージをインポートし直すために必要なソースファイルおよびメタデータのみの軽量パッケージを作成できます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DlightweightPackage ``` このパラメーターを指定すると、プラグインによって Mule アプリケーションの ​`pom.xml`​ ファイルで宣言された連動関係を含まない軽量 JAR ファイルが作成されます。この JAR ファイルを Mule Runtime Engine にデプロイすることはできず、Mule アプリケーションのソースファイルのみをアーカイブすることができます。この Maven パラメーターの結果は、Mule アプリケーションを Anypoint Studio からエクスポートするときに ​**\[Include Project Modules and Dependencies (プロジェクトモジュールと連動関係を含める)\]**​ をオフにするのと同じです。 ## [](#複数のパラメーターの指定)複数のパラメーターの指定 パラメーターを結合して、Anypoint Studio にパッケージをインポートし直すためのソースファイルおよびメタデータも含まれる軽量 Mule アプリケーションパッケージを作成することもできます。 プロジェクトのフォルダーのコマンドラインから、次のコマンドを実行します。 ```console mvn clean package -DattachMuleSources -DlightweightPackage ``` ## [](#アプリケーションパッケージからファイルを除外する)アプリケーションパッケージからファイルを除外する アプリケーションをパッケージするときに、特定のファイルまたはディレクトリを除外できます。プロジェクトのルートディレクトリで ​`_muleExclude`​ ファイルを作成し、そのコンテンツを編集して除外ルールを設定します。 `_muleExclude`​ ファイルの各行で、 [glob のパターン](https://docs.oracle.com/javase/tutorial/essential/io/fileOps.html#glob)​に従うルールが指定されます。 たとえば、2 つの除外ルールが含まれる次の ​`_muleExclude`​ ファイルを考えます。 fileToBeExcluded.json \*\*/src/main/resources/local\_directory - 最初の行は、すべてのディレクトリ内の ​`fileToBeExcluded.json`​ という名前のすべてのファイルがアプリケーションパッケージから除外されることを示しています。 - 2 行目は、​`src/main/resources`​ にある ​`local_directory`​ という名前のディレクトリのみがパッケージから除外されることを示しています。 `**/src/main/resources/local_directory`​ が ​`local_directory`​ に置き換えられている場合、プロジェクト内の ​`local_directory`​ という名前のすべてのディレクトリがアプリケーションパッケージから除外されます。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept) # Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#anypoint-studio-のベストプラクティス)Anypoint Studio のベストプラクティス Anypoint Studio を使用して Mule アプリケーションを作成する場合は、以下のプラクティスを考慮してください。 - Anypoint Studio の最新バージョンに更新する。 - 各 Studio バージョンで推奨される Java バージョン (OpenJDK) を使用する。 - 自動環境では Mule Maven プラグインを導入する (CI/CD プロセスによって実行)。 ### [](#プロジェクト構造の定義)プロジェクト構造の定義 Anypoint Studio で見やすく構造化された読みやすいプロジェクトを維持するためには、以下の推奨事項を考慮してください。 - 設定要素などのグローバル要素に対して個別の XML ファイルを作成する。 - ユースケースやリソース実装ごとに個別の XML ファイルを作成する。 - 共通の構造やロジックに対して個別の XML ファイルを作成する。 - DataWeave、WSDL、例など、リソースごとに異なるパッケージを作成する。 #### [](#インデントと書式の追加)インデントと書式の追加 Anypoint Studio でアプリケーションプロジェクトを作成する場合は、以下の点を考慮してください。 - すべての XML ファイル (Mule XML、​`pom.xml`​、​`log4j2.xml`​ など) をソースコードリポジトリにコミットする前に、インデントと書式設定を追加する。 - Anypoint Studio XML エディターのプリファレンスで線の幅 (例: `140.d`​) を定義する。 - 命名規則を定義する。 #### [](#環境ごとのプロパティ管理)環境ごとのプロパティ管理 各環境で個別の変数セットを作成しなくても済むように、Mule 4 にはデフォルト値を設定できるようにしたメカニズムが組み込まれており、Anypoint Runtime Manager を使用して管理できます。詳細は、​[「個別の XML ファイルを作成する」](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-configuration)​と​[「プロパティの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties)​を参照してください。 ## [](#アプリケーション作成のベストプラクティス)アプリケーション作成のベストプラクティス Mule アプリケーションを作成する場合には、すべての環境の設定ファイルをアプリケーション内にパッケージすることは避けてください。その代わりに、​`.yaml`​ ファイルを使用してデフォルトのプロパティを提供し、デプロイ時に Anypoint Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 ### [](#apikit)APIkit APIkit を使用する場合は、以下のプラクティスを考慮してください。 - APIkit 機能を使用して、自分の API 仕様を使用してフローを自動的に生成する。 - APIkit の例外戦略を使用して、コネクタ関連の例外をキャッチする。 ### [](#dataweave)DataWeave DataWeave を使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 - 開発フェーズではインラインスクリプトを使用する。 - インラインスクリプトを外部ファイルに渡すことで、見やすい XML を再利用可能なスクリプトを実現する。 ### [](#フロー)フロー アプリケーションのフローを作成する場合は、以下のプラクティスを考慮してください。 - ユースケースのステップを示した見やすいフロー図を用意する。 - フローリファレンスを使用して、共通ロジックを分離して再利用する。 ### [](#file-connector)File Connector ファイル用の Anypoint Connector (File Connector) を使用して大量の読み取りや他のファイル操作のパスの一部を共有する場合は、基本パスをファイル設定に抽出して再利用してください。 ```xml ``` ### [](#http-と-https)HTTP と HTTPS オンプレミスデプロイメントの HTTP および HTTPS ポートには、CloudHub デプロイメントで予約されているプロパティプレースホルダーの名前を使用することをお勧めします。 CloudHub の共有ロードバランサーでは、これらのプロパティにデフォルトが使用されます。 - CloudHub では ​`${http.port}`​ が設定 ​`port=8081`​、​`${https.port}`​ が ​`port=8082`​ にマップされます。 - CloudHub デプロイメントの HTTP サービスへの内部ポートの場合、​`${http.private.port}`​ が設定 ​`port=8091`​、​`${https.private.port}`​ が ​`port=8092`​ にマップされます。 CloudHub でのこれらの設定についての詳細は、​[「CloudHub の予約されたプロパティ」](https://docs.mulesoft.com/cloudhub/cloudhub-manage-props#cloudhub-reserved-properties)​および [CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide) を参照してください。 ### [](#apache-kafka-connector)Apache Kafka Connector Apache Kafka 用の Anypoint Connector (Apache Kafka Connector) を使用する場合は、以下のアクションを実行してください。 - `.properties`​ ファイルを使用して、ブートストラップサーバー設定を追加する。 - `.yaml`​ ファイルまたは ​`.properties`​ ファイルにプロパティのプレースホルダーを追加して、設定でこれらのファイルを使用する ```xml config.bootstrapServers={your Kafka Server address} config.consumerPropertiesFile=consumer.properties config.producerPropertiesFile=producer.properties # Consumer specific information consumer.topic=one-replica consumer.topic.partitions=1 ``` - Apache Kafka Connector は、プロデューサーとコンシューマーのプロパティのさまざまな設定を用意しています。独自の設定は、​`src/main/resource`​ にある ​`consumer.properties`​ ファイルと ​`producer.properties`​ ファイルに追加できます。 ```xml ``` ## [](#関連情報)関連情報 - [Apache Kafka Connector](https://docs.mulesoft.com/kafka-connector/latest/) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) # Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#anypoint-studio-のベストプラクティス)Anypoint Studio のベストプラクティス Anypoint Studio を使用して Mule アプリケーションを作成する場合は、以下のプラクティスを考慮してください。 - Anypoint Studio の最新バージョンに更新する。 - 各 Studio バージョンで推奨される Java バージョン (OpenJDK) を使用する。 - 自動環境では Mule Maven プラグインを導入する (CI/CD プロセスによって実行)。 ### [](#プロジェクト構造の定義)プロジェクト構造の定義 Anypoint Studio で見やすく構造化された読みやすいプロジェクトを維持するためには、以下の推奨事項を考慮してください。 - 設定要素などのグローバル要素に対して個別の XML ファイルを作成する。 - ユースケースやリソース実装ごとに個別の XML ファイルを作成する。 - 共通の構造やロジックに対して個別の XML ファイルを作成する。 - DataWeave、WSDL、例など、リソースごとに異なるパッケージを作成する。 #### [](#インデントと書式の追加)インデントと書式の追加 Anypoint Studio でアプリケーションプロジェクトを作成する場合は、以下の点を考慮してください。 - すべての XML ファイル (Mule XML、​`pom.xml`​、​`log4j2.xml`​ など) をソースコードリポジトリにコミットする前に、インデントと書式設定を追加する。 - Anypoint Studio XML エディターのプリファレンスで線の幅 (例: `140.d`​) を定義する。 - 命名規則を定義する。 #### [](#環境ごとのプロパティ管理)環境ごとのプロパティ管理 各環境で個別の変数セットを作成しなくても済むように、Mule 4 にはデフォルト値を設定できるようにしたメカニズムが組み込まれており、Anypoint Runtime Manager を使用して管理できます。詳細は、​[「個別の XML ファイルを作成する」](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-configuration)​と​[「プロパティの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties)​を参照してください。 ## [](#アプリケーション作成のベストプラクティス)アプリケーション作成のベストプラクティス Mule アプリケーションを作成する場合には、すべての環境の設定ファイルをアプリケーション内にパッケージすることは避けてください。その代わりに、​`.yaml`​ ファイルを使用してデフォルトのプロパティを提供し、デプロイ時に Anypoint Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 ### [](#apikit)APIkit APIkit を使用する場合は、以下のプラクティスを考慮してください。 - APIkit 機能を使用して、自分の API 仕様を使用してフローを自動的に生成する。 - APIkit の例外戦略を使用して、コネクタ関連の例外をキャッチする。 ### [](#dataweave)DataWeave DataWeave を使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 - 開発フェーズではインラインスクリプトを使用する。 - インラインスクリプトを外部ファイルに渡すことで、見やすい XML を再利用可能なスクリプトを実現する。 ### [](#フロー)フロー アプリケーションのフローを作成する場合は、以下のプラクティスを考慮してください。 - ユースケースのステップを示した見やすいフロー図を用意する。 - フローリファレンスを使用して、共通ロジックを分離して再利用する。 ### [](#file-connector)File Connector ファイル用の Anypoint Connector (File Connector) を使用して大量の読み取りや他のファイル操作のパスの一部を共有する場合は、基本パスをファイル設定に抽出して再利用してください。 ```xml ``` ### [](#http-と-https)HTTP と HTTPS オンプレミスデプロイメントの HTTP および HTTPS ポートには、CloudHub デプロイメントで予約されているプロパティプレースホルダーの名前を使用することをお勧めします。 CloudHub の共有ロードバランサーでは、これらのプロパティにデフォルトが使用されます。 - CloudHub では ​`${http.port}`​ が設定 ​`port=8081`​、​`${https.port}`​ が ​`port=8082`​ にマップされます。 - CloudHub デプロイメントの HTTP サービスへの内部ポートの場合、​`${http.private.port}`​ が設定 ​`port=8091`​、​`${https.private.port}`​ が ​`port=8092`​ にマップされます。 CloudHub でのこれらの設定についての詳細は、​[「CloudHub の予約されたプロパティ」](https://docs.mulesoft.com/cloudhub/cloudhub-manage-props#cloudhub-reserved-properties)​および [CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide) を参照してください。 ### [](#apache-kafka-connector)Apache Kafka Connector Apache Kafka 用の Anypoint Connector (Apache Kafka Connector) を使用する場合は、以下のアクションを実行してください。 - `.properties`​ ファイルを使用して、ブートストラップサーバー設定を追加する。 - `.yaml`​ ファイルまたは ​`.properties`​ ファイルにプロパティのプレースホルダーを追加して、設定でこれらのファイルを使用する ```xml config.bootstrapServers={your Kafka Server address} config.consumerPropertiesFile=consumer.properties config.producerPropertiesFile=producer.properties # Consumer specific information consumer.topic=one-replica consumer.topic.partitions=1 ``` - Apache Kafka Connector は、プロデューサーとコンシューマーのプロパティのさまざまな設定を用意しています。独自の設定は、​`src/main/resource`​ にある ​`consumer.properties`​ ファイルと ​`producer.properties`​ ファイルに追加できます。 ```xml ``` ## [](#関連情報)関連情報 - [Apache Kafka Connector](https://docs.mulesoft.com/kafka-connector/latest/) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) # Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#anypoint-studio-のベストプラクティス)Anypoint Studio のベストプラクティス Anypoint Studio を使用して Mule アプリケーションを作成する場合は、以下のプラクティスを考慮してください。 - Anypoint Studio の最新バージョンに更新する。 - 各 Studio バージョンで推奨される Java バージョン (OpenJDK) を使用する。 - 自動環境では Mule Maven プラグインを導入する (CI/CD プロセスによって実行)。 ### [](#プロジェクト構造の定義)プロジェクト構造の定義 Anypoint Studio で見やすく構造化された読みやすいプロジェクトを維持するためには、以下の推奨事項を考慮してください。 - 設定要素などのグローバル要素に対して個別の XML ファイルを作成する。 - ユースケースやリソース実装ごとに個別の XML ファイルを作成する。 - 共通の構造やロジックに対して個別の XML ファイルを作成する。 - DataWeave、WSDL、例など、リソースごとに異なるパッケージを作成する。 #### [](#インデントと書式の追加)インデントと書式の追加 Anypoint Studio でアプリケーションプロジェクトを作成する場合は、以下の点を考慮してください。 - すべての XML ファイル (Mule XML、​`pom.xml`​、​`log4j2.xml`​ など) をソースコードリポジトリにコミットする前に、インデントと書式設定を追加する。 - Anypoint Studio XML エディターのプリファレンスで線の幅 (例: `140.d`​) を定義する。 - 命名規則を定義する。 #### [](#環境ごとのプロパティ管理)環境ごとのプロパティ管理 各環境で個別の変数セットを作成しなくても済むように、Mule 4 にはデフォルト値を設定できるようにしたメカニズムが組み込まれており、Anypoint Runtime Manager を使用して管理できます。詳細は、​[「個別の XML ファイルを作成する」](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-configuration)​と​[「プロパティの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties)​を参照してください。 ## [](#アプリケーション作成のベストプラクティス)アプリケーション作成のベストプラクティス Mule アプリケーションを作成する場合には、すべての環境の設定ファイルをアプリケーション内にパッケージすることは避けてください。その代わりに、​`.yaml`​ ファイルを使用してデフォルトのプロパティを提供し、デプロイ時に Anypoint Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 ### [](#apikit)APIkit APIkit を使用する場合は、以下のプラクティスを考慮してください。 - APIkit 機能を使用して、自分の API 仕様を使用してフローを自動的に生成する。 - APIkit の例外戦略を使用して、コネクタ関連の例外をキャッチする。 ### [](#dataweave)DataWeave DataWeave を使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 - 開発フェーズではインラインスクリプトを使用する。 - インラインスクリプトを外部ファイルに渡すことで、見やすい XML を再利用可能なスクリプトを実現する。 ### [](#フロー)フロー アプリケーションのフローを作成する場合は、以下のプラクティスを考慮してください。 - ユースケースのステップを示した見やすいフロー図を用意する。 - フローリファレンスを使用して、共通ロジックを分離して再利用する。 ### [](#file-connector)File Connector ファイル用の Anypoint Connector (File Connector) を使用して大量の読み取りや他のファイル操作のパスの一部を共有する場合は、基本パスをファイル設定に抽出して再利用してください。 ```xml ``` ### [](#http-と-https)HTTP と HTTPS オンプレミスデプロイメントの HTTP および HTTPS ポートには、CloudHub デプロイメントで予約されているプロパティプレースホルダーの名前を使用することをお勧めします。 CloudHub の共有ロードバランサーでは、これらのプロパティにデフォルトが使用されます。 - CloudHub では ​`${http.port}`​ が設定 ​`port=8081`​、​`${https.port}`​ が ​`port=8082`​ にマップされます。 - CloudHub デプロイメントの HTTP サービスへの内部ポートの場合、​`${http.private.port}`​ が設定 ​`port=8091`​、​`${https.private.port}`​ が ​`port=8092`​ にマップされます。 CloudHub でのこれらの設定についての詳細は、​[「CloudHub の予約されたプロパティ」](https://docs.mulesoft.com/cloudhub/cloudhub-manage-props#cloudhub-reserved-properties)​および [CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide)を参照してください。 ### [](#apache-kafka-connector)Apache Kafka Connector Apache Kafka 用の Anypoint Connector (Apache Kafka Connector) を使用する場合は、以下のアクションを実行してください。 - `.properties`​ ファイルを使用して、ブートストラップサーバー設定を追加する。 - `.yaml`​ ファイルまたは ​`.properties`​ ファイルにプロパティのプレースホルダーを追加して、設定でこれらのファイルを使用する ```xml config.bootstrapServers={your Kafka Server address} config.consumerPropertiesFile=consumer.properties config.producerPropertiesFile=producer.properties # Consumer specific information consumer.topic=one-replica consumer.topic.partitions=1 ``` - Apache Kafka Connector は、プロデューサーとコンシューマーのプロパティのさまざまな設定を用意しています。独自の設定は、​`src/main/resource`​ にある ​`consumer.properties`​ ファイルと ​`producer.properties`​ ファイルに追加できます。 ```xml ``` ## [](#関連情報)関連情報 - [Apache Kafka Connector](https://docs.mulesoft.com/kafka-connector/latest/) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) # Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#anypoint-studio-のベストプラクティス)Anypoint Studio のベストプラクティス Anypoint Studio を使用して Mule アプリケーションを作成する場合は、以下のプラクティスを考慮してください。 - Anypoint Studio の最新バージョンに更新する。 - 各 Studio バージョンで推奨される Java バージョン (OpenJDK) を使用する。 - 自動環境では Mule Maven プラグインを導入する (CI/CD プロセスによって実行)。 ### [](#プロジェクト構造の定義)プロジェクト構造の定義 Anypoint Studio で見やすく構造化された読みやすいプロジェクトを維持するためには、以下の推奨事項を考慮してください。 - 設定要素などのグローバル要素に対して個別の XML ファイルを作成する。 - ユースケースやリソース実装ごとに個別の XML ファイルを作成する。 - 共通の構造やロジックに対して個別の XML ファイルを作成する。 - DataWeave、WSDL、例など、リソースごとに異なるパッケージを作成する。 #### [](#インデントと書式の追加)インデントと書式の追加 Anypoint Studio でアプリケーションプロジェクトを作成する場合は、以下の点を考慮してください。 - すべての XML ファイル (Mule XML、​`pom.xml`​、​`log4j2.xml`​ など) をソースコードリポジトリにコミットする前に、インデントと書式設定を追加する。 - Anypoint Studio XML エディターのプリファレンスで線の幅 (例: `140.d`​) を定義する。 - 命名規則を定義する。 #### [](#環境ごとのプロパティ管理)環境ごとのプロパティ管理 各環境で個別の変数セットを作成しなくても済むように、Mule 4 にはデフォルト値を設定できるようにしたメカニズムが組み込まれており、Anypoint Runtime Manager を使用して管理できます。詳細は、​[「個別の XML ファイルを作成する」](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-configuration)​と​[「プロパティの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties)​を参照してください。 ## [](#アプリケーション作成のベストプラクティス)アプリケーション作成のベストプラクティス Mule アプリケーションを作成する場合には、すべての環境の設定ファイルをアプリケーション内にパッケージすることは避けてください。その代わりに、​`.yaml`​ ファイルを使用してデフォルトのプロパティを提供し、デプロイ時に Anypoint Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 ### [](#apikit)APIkit APIkit を使用する場合は、以下のプラクティスを考慮してください。 - APIkit 機能を使用して、自分の API 仕様を使用してフローを自動的に生成する。 - APIkit の例外戦略を使用して、コネクタ関連の例外をキャッチする。 ### [](#dataweave)DataWeave DataWeave を使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 - 開発フェーズではインラインスクリプトを使用する。 - インラインスクリプトを外部ファイルに渡すことで、見やすい XML を再利用可能なスクリプトを実現する。 ### [](#フロー)フロー アプリケーションのフローを作成する場合は、以下のプラクティスを考慮してください。 - ユースケースのステップを示した見やすいフロー図を用意する。 - フローリファレンスを使用して、共通ロジックを分離して再利用する。 ### [](#file-connector)File Connector ファイル用の Anypoint Connector (File Connector) を使用して大量の読み取りや他のファイル操作のパスの一部を共有する場合は、基本パスをファイル設定に抽出して再利用してください。 ```xml ``` ### [](#http-と-https)HTTP と HTTPS オンプレミスデプロイメントの HTTP および HTTPS ポートには、CloudHub デプロイメントで予約されているプロパティプレースホルダーの名前を使用することをお勧めします。 CloudHub の共有ロードバランサーでは、これらのプロパティにデフォルトが使用されます。 - CloudHub では ​`${http.port}`​ が設定 ​`port=8081`​、​`${https.port}`​ が ​`port=8082`​ にマップされます。 - CloudHub デプロイメントの HTTP サービスへの内部ポートの場合、​`${http.private.port}`​ が設定 ​`port=8091`​、​`${https.private.port}`​ が ​`port=8092`​ にマップされます。 CloudHub でのこれらの設定についての詳細は、​[「CloudHub の予約されたプロパティ」](https://docs.mulesoft.com/cloudhub/cloudhub-manage-props#cloudhub-reserved-properties)​および [CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide)を参照してください。 ### [](#apache-kafka-connector)Apache Kafka Connector Apache Kafka 用の Anypoint Connector (Apache Kafka Connector) を使用する場合は、以下のアクションを実行してください。 - `.properties`​ ファイルを使用して、ブートストラップサーバー設定を追加する。 - `.yaml`​ ファイルまたは ​`.properties`​ ファイルにプロパティのプレースホルダーを追加して、設定でこれらのファイルを使用する ```xml config.bootstrapServers={your Kafka Server address} config.consumerPropertiesFile=consumer.properties config.producerPropertiesFile=producer.properties # Consumer specific information consumer.topic=one-replica consumer.topic.partitions=1 ``` - Apache Kafka Connector は、プロデューサーとコンシューマーのプロパティのさまざまな設定を用意しています。独自の設定は、​`src/main/resource`​ にある ​`consumer.properties`​ ファイルと ​`producer.properties`​ ファイルに追加できます。 ```xml ``` ## [](#関連情報)関連情報 - [Apache Kafka Connector](https://docs.mulesoft.com/kafka-connector/latest/) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) # Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#anypoint-studio-のベストプラクティス)Anypoint Studio のベストプラクティス Anypoint Studio を使用して Mule アプリケーションを作成する場合は、以下のプラクティスを考慮してください。 - Anypoint Studio の最新バージョンに更新する。 - 各 Studio バージョンで推奨される Java バージョン (OpenJDK) を使用する。 - 自動環境では Mule Maven プラグインを導入する (CI/CD プロセスによって実行)。 ### [](#プロジェクト構造の定義)プロジェクト構造の定義 Anypoint Studio で見やすく構造化された読みやすいプロジェクトを維持するためには、以下の推奨事項を考慮してください。 - 設定要素などのグローバル要素に対して個別の XML ファイルを作成する。 - ユースケースやリソース実装ごとに個別の XML ファイルを作成する。 - 共通の構造やロジックに対して個別の XML ファイルを作成する。 - DataWeave、WSDL、例など、リソースごとに異なるパッケージを作成する。 #### [](#インデントと書式の追加)インデントと書式の追加 Anypoint Studio でアプリケーションプロジェクトを作成する場合は、以下の点を考慮してください。 - すべての XML ファイル (Mule XML、​`pom.xml`​、​`log4j2.xml`​ など) をソースコードリポジトリにコミットする前に、インデントと書式設定を追加する。 - Anypoint Studio XML エディターのプリファレンスで線の幅 (例: `140.d`​) を定義する。 - 命名規則を定義する。 #### [](#環境ごとのプロパティ管理)環境ごとのプロパティ管理 各環境で個別の変数セットを作成しなくても済むように、Mule 4 にはデフォルト値を設定できるようにしたメカニズムが組み込まれており、Anypoint Runtime Manager を使用して管理できます。詳細は、​[「個別の XML ファイルを作成する」](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-configuration)​と​[「プロパティの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties)​を参照してください。 ## [](#アプリケーション作成のベストプラクティス)アプリケーション作成のベストプラクティス Mule アプリケーションを作成する場合には、すべての環境の設定ファイルをアプリケーション内にパッケージすることは避けてください。その代わりに、​`.yaml`​ ファイルを使用してデフォルトのプロパティを提供し、デプロイ時に Anypoint Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 ### [](#apikit)APIkit APIkit を使用する場合は、以下のプラクティスを考慮してください。 - APIkit 機能を使用して、自分の API 仕様を使用してフローを自動的に生成する。 - APIkit の例外戦略を使用して、コネクタ関連の例外をキャッチする。 ### [](#dataweave)DataWeave DataWeave を使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 - 開発フェーズではインラインスクリプトを使用する。 - インラインスクリプトを外部ファイルに渡すことで、見やすい XML を再利用可能なスクリプトを実現する。 ### [](#フロー)フロー アプリケーションのフローを作成する場合は、以下のプラクティスを考慮してください。 - ユースケースのステップを示した見やすいフロー図を用意する。 - フローリファレンスを使用して、共通ロジックを分離して再利用する。 ### [](#file-connector)File Connector ファイル用の Anypoint Connector (File Connector) を使用して大量の読み取りや他のファイル操作のパスの一部を共有する場合は、基本パスをファイル設定に抽出して再利用してください。 ```xml ``` ### [](#http-と-https)HTTP と HTTPS オンプレミスデプロイメントの HTTP および HTTPS ポートには、CloudHub デプロイメントで予約されているプロパティプレースホルダーの名前を使用することをお勧めします。 CloudHub の共有ロードバランサーでは、これらのプロパティにデフォルトが使用されます。 - CloudHub では ​`${http.port}`​ が設定 ​`port=8081`​、​`${https.port}`​ が ​`port=8082`​ にマップされます。 - CloudHub デプロイメントの HTTP サービスへの内部ポートの場合、​`${http.private.port}`​ が設定 ​`port=8091`​、​`${https.private.port}`​ が ​`port=8092`​ にマップされます。 CloudHub でのこれらの設定についての詳細は、​[「CloudHub の予約されたプロパティ」](https://docs.mulesoft.com/cloudhub/cloudhub-manage-props#cloudhub-reserved-properties)​および [CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide)を参照してください。 ### [](#apache-kafka-connector)Apache Kafka Connector Apache Kafka 用の Anypoint Connector (Apache Kafka Connector) を使用する場合は、以下のアクションを実行してください。 - `.properties`​ ファイルを使用して、ブートストラップサーバー設定を追加する。 - `.yaml`​ ファイルまたは ​`.properties`​ ファイルにプロパティのプレースホルダーを追加して、設定でこれらのファイルを使用する ```xml config.bootstrapServers={your Kafka Server address} config.consumerPropertiesFile=consumer.properties config.producerPropertiesFile=producer.properties # Consumer specific information consumer.topic=one-replica consumer.topic.partitions=1 ``` - Apache Kafka Connector は、プロデューサーとコンシューマーのプロパティのさまざまな設定を用意しています。独自の設定は、​`src/main/resource`​ にある ​`consumer.properties`​ ファイルと ​`producer.properties`​ ファイルに追加できます。 ```xml ``` ## [](#関連情報)関連情報 - [Apache Kafka Connector](https://docs.mulesoft.com/kafka-connector/latest/) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) # Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#anypoint-studio-のベストプラクティス)Anypoint Studio のベストプラクティス Anypoint Studio を使用して Mule アプリケーションを作成する場合は、以下のプラクティスを考慮してください。 - Anypoint Studio の最新バージョンに更新する。 - 各 Studio バージョンで推奨される Java バージョン (OpenJDK) を使用する。 - 自動環境では Mule Maven プラグインを導入する (CI/CD プロセスによって実行)。 ### [](#プロジェクト構造の定義)プロジェクト構造の定義 Anypoint Studio で見やすく構造化された読みやすいプロジェクトを維持するためには、以下の推奨事項を考慮してください。 - 設定要素などのグローバル要素に対して個別の XML ファイルを作成する。 - ユースケースやリソース実装ごとに個別の XML ファイルを作成する。 - 共通の構造やロジックに対して個別の XML ファイルを作成する。 - DataWeave、WSDL、例など、リソースごとに異なるパッケージを作成する。 #### [](#インデントと書式の追加)インデントと書式の追加 Anypoint Studio でアプリケーションプロジェクトを作成する場合は、以下の点を考慮してください。 - すべての XML ファイル (Mule XML、​`pom.xml`​、​`log4j2.xml`​ など) をソースコードリポジトリにコミットする前に、インデントと書式設定を追加する。 - Anypoint Studio XML エディターのプリファレンスで線の幅 (例: `140.d`​) を定義する。 - 命名規則を定義する。 #### [](#環境ごとのプロパティ管理)環境ごとのプロパティ管理 各環境で個別の変数セットを作成しなくても済むように、Mule 4 にはデフォルト値を設定できるようにしたメカニズムが組み込まれており、Anypoint Runtime Manager を使用して管理できます。詳細は、​[「個別の XML ファイルを作成する」](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-configuration)​と​[「プロパティの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties)​を参照してください。 ## [](#アプリケーション作成のベストプラクティス)アプリケーション作成のベストプラクティス Mule アプリケーションを作成する場合には、すべての環境の設定ファイルをアプリケーション内にパッケージすることは避けてください。その代わりに、​`.yaml`​ ファイルを使用してデフォルトのプロパティを提供し、デプロイ時に Anypoint Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 ### [](#apikit)APIkit APIkit を使用する場合は、以下のプラクティスを考慮してください。 - APIkit 機能を使用して、自分の API 仕様を使用してフローを自動的に生成する。 - APIkit の例外戦略を使用して、コネクタ関連の例外をキャッチする。 ### [](#dataweave)DataWeave DataWeave を使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 - 開発フェーズではインラインスクリプトを使用する。 - インラインスクリプトを外部ファイルに渡すことで、見やすい XML を再利用可能なスクリプトを実現する。 ### [](#フロー)フロー アプリケーションのフローを作成する場合は、以下のプラクティスを考慮してください。 - ユースケースのステップを示した見やすいフロー図を用意する。 - フローリファレンスを使用して、共通ロジックを分離して再利用する。 ### [](#file-connector)File Connector ファイル用の Anypoint Connector (File Connector) を使用して大量の読み取りや他のファイル操作のパスの一部を共有する場合は、基本パスをファイル設定に抽出して再利用してください。 ```xml ``` ### [](#http-と-https)HTTP と HTTPS オンプレミスデプロイメントの HTTP および HTTPS ポートには、CloudHub デプロイメントで予約されているプロパティプレースホルダーの名前を使用することをお勧めします。 CloudHub の共有ロードバランサーでは、これらのプロパティにデフォルトが使用されます。 - CloudHub では ​`${http.port}`​ が設定 ​`port=8081`​、​`${https.port}`​ が ​`port=8082`​ にマップされます。 - CloudHub デプロイメントの HTTP サービスへの内部ポートの場合、​`${http.private.port}`​ が設定 ​`port=8091`​、​`${https.private.port}`​ が ​`port=8092`​ にマップされます。 CloudHub でのこれらの設定についての詳細は、​[「CloudHub の予約されたプロパティ」](https://docs.mulesoft.com/cloudhub/cloudhub-manage-props#cloudhub-reserved-properties)​および [CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide)を参照してください。 ### [](#apache-kafka-connector)Apache Kafka Connector Apache Kafka 用の Anypoint Connector (Apache Kafka Connector) を使用する場合は、以下のアクションを実行してください。 - `.properties`​ ファイルを使用して、ブートストラップサーバー設定を追加する。 - `.yaml`​ ファイルまたは ​`.properties`​ ファイルにプロパティのプレースホルダーを追加して、設定でこれらのファイルを使用する ```xml config.bootstrapServers={your Kafka Server address} config.consumerPropertiesFile=consumer.properties config.producerPropertiesFile=producer.properties # Consumer specific information consumer.topic=one-replica consumer.topic.partitions=1 ``` - Apache Kafka Connector は、プロデューサーとコンシューマーのプロパティのさまざまな設定を用意しています。独自の設定は、​`src/main/resource`​ にある ​`consumer.properties`​ ファイルと ​`producer.properties`​ ファイルに追加できます。 ```xml ``` ## [](#関連情報)関連情報 - [Apache Kafka Connector](https://docs.mulesoft.com/kafka-connector/latest/) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) # Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#anypoint-studio-のベストプラクティス)Anypoint Studio のベストプラクティス Anypoint Studio を使用して Mule アプリケーションを作成する場合は、以下のプラクティスを考慮してください。 - Anypoint Studio の最新バージョンに更新する。 - 各 Studio バージョンで推奨される Java バージョン (OpenJDK) を使用する。 - 自動環境では Mule Maven プラグインを導入する (CI/CD プロセスによって実行)。 ### [](#プロジェクト構造の定義)プロジェクト構造の定義 Anypoint Studio で見やすく構造化された読みやすいプロジェクトを維持するためには、以下の推奨事項を考慮してください。 - 設定要素などのグローバル要素に対して個別の XML ファイルを作成する。 - ユースケースやリソース実装ごとに個別の XML ファイルを作成する。 - 共通の構造やロジックに対して個別の XML ファイルを作成する。 - DataWeave、WSDL、例など、リソースごとに異なるパッケージを作成する。 #### [](#インデントと書式の追加)インデントと書式の追加 Anypoint Studio でアプリケーションプロジェクトを作成する場合は、以下の点を考慮してください。 - すべての XML ファイル (Mule XML、​`pom.xml`​、​`log4j2.xml`​ など) をソースコードリポジトリにコミットする前に、インデントと書式設定を追加する。 - Anypoint Studio XML エディターのプリファレンスで線の幅 (例: `140.d`​) を定義する。 - 命名規則を定義する。 #### [](#環境ごとのプロパティ管理)環境ごとのプロパティ管理 各環境で個別の変数セットを作成しなくても済むように、Mule 4 にはデフォルト値を設定できるようにしたメカニズムが組み込まれており、Anypoint Runtime Manager を使用して管理できます。詳細は、​[「個別の XML ファイルを作成する」](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-configuration)​と​[「プロパティの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties)​を参照してください。 ## [](#アプリケーション作成のベストプラクティス)アプリケーション作成のベストプラクティス Mule アプリケーションを作成する場合には、すべての環境の設定ファイルをアプリケーション内にパッケージすることは避けてください。その代わりに、​`.yaml`​ ファイルを使用してデフォルトのプロパティを提供し、デプロイ時に Anypoint Runtime Manager を使用してこれらのプロパティを個別に上書きします。 ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 ### [](#apikit)APIkit APIkit を使用する場合は、以下のプラクティスを考慮してください。 - APIkit 機能を使用して、自分の API 仕様を使用してフローを自動的に生成する。 - APIkit の例外戦略を使用して、コネクタ関連の例外をキャッチする。 ### [](#dataweave)DataWeave DataWeave を使用してアプリケーションを作成する場合は、以下の推奨事項を考慮してください。 - 開発フェーズではインラインスクリプトを使用する。 - インラインスクリプトを外部ファイルに渡すことで、見やすい XML を再利用可能なスクリプトを実現する。 ### [](#フロー)フロー アプリケーションのフローを作成する場合は、以下のプラクティスを考慮してください。 - ユースケースのステップを示した見やすいフロー図を用意する。 - フローリファレンスを使用して、共通ロジックを分離して再利用する。 ### [](#file-connector)File Connector ファイル用の Anypoint Connector (File Connector) を使用して大量の読み取りや他のファイル操作のパスの一部を共有する場合は、基本パスをファイル設定に抽出して再利用してください。 ```xml ``` ### [](#http-と-https)HTTP と HTTPS オンプレミスデプロイメントの HTTP および HTTPS ポートには、CloudHub デプロイメントで予約されているプロパティプレースホルダーの名前を使用することをお勧めします。 CloudHub の共有ロードバランサーでは、これらのプロパティにデフォルトが使用されます。 - CloudHub では ​`${http.port}`​ が設定 ​`port=8081`​、​`${https.port}`​ が ​`port=8082`​ にマップされます。 - CloudHub デプロイメントの HTTP サービスへの内部ポートの場合、​`${http.private.port}`​ が設定 ​`port=8091`​、​`${https.private.port}`​ が ​`port=8092`​ にマップされます。 CloudHub でのこれらの設定についての詳細は、​[「CloudHub の予約されたプロパティ」](https://docs.mulesoft.com/cloudhub/cloudhub-manage-props#cloudhub-reserved-properties)​および [CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide)を参照してください。 ### [](#apache-kafka-connector)Apache Kafka Connector Apache Kafka 用の Anypoint Connector (Apache Kafka Connector) を使用する場合は、以下のアクションを実行してください。 - `.properties`​ ファイルを使用して、ブートストラップサーバー設定を追加する。 - `.yaml`​ ファイルまたは ​`.properties`​ ファイルにプロパティのプレースホルダーを追加して、設定でこれらのファイルを使用する ```xml config.bootstrapServers={your Kafka Server address} config.consumerPropertiesFile=consumer.properties config.producerPropertiesFile=producer.properties # Consumer specific information consumer.topic=one-replica consumer.topic.partitions=1 ``` - Apache Kafka Connector は、プロデューサーとコンシューマーのプロパティのさまざまな設定を用意しています。独自の設定は、​`src/main/resource`​ にある ​`consumer.properties`​ ファイルと ​`producer.properties`​ ファイルに追加できます。 ```xml ``` ## [](#関連情報)関連情報 - [Apache Kafka Connector](https://docs.mulesoft.com/kafka-connector/latest/) - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) # Mule イベント Mule イベントには、ランタイムによって処理されたコア情報が含まれます。イベントは、設定されたアプリケーションロジックに従って Mule アプリケーション内のコンポーネントを通過します。 Mule イベントは不変であるため、Mule イベントのインスタンスを変更するたびに新しいインスタンスが作成されます。 Mule イベントは次のオブジェクトで構成されます。 - Mule メッセージ: メッセージペイロードとその関連属性が含まれる。 - 変数: フローで使用する Mule イベントのメタデータ。 ![mule concepts d46f9](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mule-concepts-d46f9.png) Scheduler、HTTP Listener、または On New や Updated File コンポーネントなどのメッセージソースは、Mule イベントの生成をトリガーし、そのイベントをフローにディスパッチします。 ![about mule event 2724e](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/about-mule-event-2724e.png) 1. トリガーがイベントソースに到達します。 2. イベントソースにより Mule イベントが生成されます。 3. Mule イベントがフローのコンポーネントを順番に通過します。 4. 定義済みの方法で、各コンポーネントが Mule イベントとやりとりします。 場合によっては、メッセージソースで問題が発生したときに、コンポーネントで Mule イベントが生成されないことがあります。たとえば、HTTP リスナー設定のパスが無効または不正な場合、Mule イベントは作成されません。コネクタでは、ERROR、WARN、または INFO メッセージでこのような問題が記録されます。 ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-message) - [定義済み変数](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-variables-context) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-variables) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.3/logging-and-debugging) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-error-concept) # Mule イベント Mule イベントには、ランタイムによって処理されたコア情報が含まれます。イベントは、設定されたアプリケーションロジックに従って Mule アプリケーション内のコンポーネントを通過します。 Mule イベントは不変であるため、Mule イベントのインスタンスを変更するたびに新しいインスタンスが作成されます。 Mule イベントは次のオブジェクトで構成されます。 - Mule メッセージ: メッセージペイロードとその関連属性が含まれる。 - 変数: フローで使用する Mule イベントのメタデータ。 ![mule concepts d46f9](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mule-concepts-d46f9.png) Mule イベントソース (以前は「メッセージソース」と呼ばれていた) は、Mule イベントの生成をトリガーし、そのイベントをフローにディスパッチします。イベントソースの例としては、Scheduler などのトリガーや HTTP Listener などのリスナー、On New コンポーネントや Updated File コンポーネントなどがあります。 ![about mule event 2724e](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/about-mule-event-2724e.png) 1. トリガーがイベントソースに到達します。 2. イベントソースにより Mule イベントが生成されます。 3. Mule イベントがフローのコンポーネントを順番に通過します。 4. 定義済みの方法で、各コンポーネントが Mule イベントとやりとりします。 場合によっては、イベントソースで問題が発生したときに、コンポーネントで Mule イベントが生成されないことがあります。たとえば、HTTP リスナー設定のパスが無効または不正な場合、Mule イベントは作成されません。コネクタでは、ERROR、WARN、または INFO メッセージでこのような問題が記録されます。 ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-message) - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-variables) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.4/logging-and-debugging) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-error-concept) # Mule イベント Mule イベントには、ランタイムによって処理されたコア情報が含まれます。イベントは、設定されたアプリケーションロジックに従って Mule アプリケーション内のコンポーネントを通過します。 Mule イベントは不変であるため、Mule イベントのインスタンスを変更するたびに新しいインスタンスが作成されます。 Mule イベントは次のオブジェクトで構成されます。 - Mule メッセージ: メッセージペイロードとその関連属性が含まれる。 - 変数: フローで使用する Mule イベントのメタデータ。 ![mule concepts d46f9](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mule-concepts-d46f9.png) Mule イベントソース (以前は「メッセージソース」と呼ばれていた) は、Mule イベントの生成をトリガーし、そのイベントをフローにディスパッチします。イベントソースの例としては、Scheduler などのトリガーや HTTP Listener などのリスナー、On New コンポーネントや Updated File コンポーネントなどがあります。 ![about mule event 2724e](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/about-mule-event-2724e.png) 1. トリガーがイベントソースに到達します。 2. イベントソースにより Mule イベントが生成されます。 3. Mule イベントがフローのコンポーネントを順番に通過します。 4. 定義済みの方法で、各コンポーネントが Mule イベントとやりとりします。 場合によっては、イベントソースで問題が発生したときに、コンポーネントで Mule イベントが生成されないことがあります。たとえば、HTTP リスナー設定のパスが無効または不正な場合、Mule イベントは作成されません。コネクタでは、ERROR、WARN、または INFO メッセージでこのような問題が記録されます。 ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-message) - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-variables) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.5/logging-and-debugging) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-error-concept) # Mule イベント Mule イベントには、ランタイムによって処理されたコア情報が含まれます。イベントは、設定されたアプリケーションロジックに従って Mule アプリケーション内のコンポーネントを通過します。 Mule イベントは不変であるため、Mule イベントのインスタンスを変更するたびに新しいインスタンスが作成されます。 Mule イベントは次のオブジェクトで構成されます。 - Mule メッセージ: メッセージペイロードとその関連属性が含まれる。 - 変数: フローで使用する Mule イベントのメタデータ。 ![mule concepts d46f9](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mule-concepts-d46f9.png) Mule イベントソース (以前は「メッセージソース」と呼ばれていた) は、Mule イベントの生成をトリガーし、そのイベントをフローにディスパッチします。イベントソースの例としては、Scheduler などのトリガーや HTTP Listener などのリスナー、On New コンポーネントや Updated File コンポーネントなどがあります。 ![about mule event 2724e](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/about-mule-event-2724e.png) 1. トリガーがイベントソースに到達します。 2. イベントソースにより Mule イベントが生成されます。 3. Mule イベントがフローのコンポーネントを順番に通過します。 4. 定義済みの方法で、各コンポーネントが Mule イベントとやりとりします。 場合によっては、イベントソースで問題が発生したときに、コンポーネントで Mule イベントが生成されないことがあります。たとえば、HTTP リスナー設定のパスが無効または不正な場合、Mule イベントは作成されません。コネクタでは、ERROR、WARN、または INFO メッセージでこのような問題が記録されます。 ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-message) - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-variables) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.6/logging-and-debugging) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-error-concept) # Mule イベント Mule イベントには、ランタイムによって処理されたコア情報が含まれます。イベントは、設定されたアプリケーションロジックに従って Mule アプリケーション内のコンポーネントを通過します。 Mule イベントは不変であるため、Mule イベントのインスタンスを変更するたびに新しいインスタンスが作成されます。 Mule イベントは次のオブジェクトで構成されます。 - Mule メッセージ: メッセージペイロードとその関連属性が含まれる。 - 変数: フローで使用する Mule イベントのメタデータ。 ![メッセージ、属性、ペイロード、変数が含まれる Mule イベント](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mule-concepts-d46f9.png) Mule イベントソース (以前は「メッセージソース」と呼ばれていた) は、Mule イベントの生成をトリガーし、そのイベントをフローにディスパッチします。イベントソースの例としては、Scheduler などのトリガーや HTTP Listener などのリスナー、On New コンポーネントや Updated File コンポーネントなどがあります。 ![Mule イベントソースシーケンス](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/about-mule-event-2724e.png) 1. トリガーがイベントソースに到達します。 2. イベントソースにより Mule イベントが生成されます。 3. Mule イベントがフローのコンポーネントを順番に通過します。 4. 定義済みの方法で、各コンポーネントが Mule イベントとやりとりします。 場合によっては、イベントソースで問題が発生したときに、コンポーネントで Mule イベントが生成されないことがあります。たとえば、HTTP リスナー設定のパスが無効または不正な場合、Mule イベントは作成されません。コネクタでは、ERROR、WARN、または INFO メッセージでこのような問題が記録されます。 ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-message) - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-variables) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.7/logging-and-debugging) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-error-concept) # Mule イベント Mule イベントには、ランタイムによって処理されたコア情報が含まれます。イベントは、設定されたアプリケーションロジックに従って Mule アプリケーション内のコンポーネントを通過します。 Mule イベントは不変であるため、Mule イベントのインスタンスを変更するたびに新しいインスタンスが作成されます。 Mule イベントは次のオブジェクトで構成されます。 - Mule メッセージ: メッセージペイロードとその関連属性が含まれる。 - 変数: フローで使用する Mule イベントのメタデータ。 ![メッセージ、属性、ペイロード、変数が含まれる Mule イベント](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mule-concepts-d46f9.png) Mule イベントソース (以前は「メッセージソース」と呼ばれていた) は、Mule イベントの生成をトリガーし、そのイベントをフローにディスパッチします。イベントソースの例としては、Scheduler などのトリガーや HTTP Listener などのリスナー、On New コンポーネントや Updated File コンポーネントなどがあります。 ![Mule イベントソースシーケンス](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/about-mule-event-2724e.png) 1. トリガーがイベントソースに到達します。 2. イベントソースにより Mule イベントが生成されます。 3. Mule イベントがフローのコンポーネントを順番に通過します。 4. 定義済みの方法で、各コンポーネントが Mule イベントとやりとりします。 場合によっては、イベントソースで問題が発生したときに、コンポーネントで Mule イベントが生成されないことがあります。たとえば、HTTP リスナー設定のパスが無効または不正な場合、Mule イベントは作成されません。コネクタでは、ERROR、WARN、または INFO メッセージでこのような問題が記録されます。 ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-message) - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-variables) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.8/logging-and-debugging) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-error-concept) # Mule イベント Mule イベントには、ランタイムによって処理されたコア情報が含まれます。イベントは、設定されたアプリケーションロジックに従って Mule アプリケーション内のコンポーネントを通過します。 Mule イベントは不変であるため、Mule イベントのインスタンスを変更するたびに新しいインスタンスが作成されます。 Mule イベントは次のオブジェクトで構成されます。 - Mule メッセージ: メッセージペイロードとその関連属性が含まれる。 - 変数: フローで使用する Mule イベントのメタデータ。 ![メッセージ、属性、ペイロード、変数が含まれる Mule イベント](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mule-concepts-d46f9.png) Mule イベントソース (以前は「メッセージソース」と呼ばれていた) は、Mule イベントの生成をトリガーし、そのイベントをフローにディスパッチします。イベントソースの例としては、Scheduler などのトリガーや HTTP Listener などのリスナー、On New コンポーネントや Updated File コンポーネントなどがあります。 ![Mule イベントソースシーケンス](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/about-mule-event-2724e.png) 1. トリガーがイベントソースに到達します。 2. イベントソースにより Mule イベントが生成されます。 3. Mule イベントがフローのコンポーネントを順番に通過します。 4. 定義済みの方法で、各コンポーネントが Mule イベントとやりとりします。 場合によっては、イベントソースで問題が発生したときに、コンポーネントで Mule イベントが生成されないことがあります。たとえば、HTTP リスナー設定のパスが無効または不正な場合、Mule イベントは作成されません。コネクタでは、ERROR、WARN、または INFO メッセージでこのような問題が記録されます。 ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-message) - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-variables) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.9/logging-and-debugging) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-error-concept) # Mule インストールの強化 強化とは、セキュリティとは異なり、アプリケーションを開発から本番に移行するために実行する必要がある手順を意味します。これは、開発サイクルの完了後に、IT 空間に何かをデプロイするために従う必要がある精巧な手順です。 通常、IT 組織は、オープンポートを最小限に維持し、管理アプリケーションへのアクセスを制限し、アプリケーション数を最小限に抑え、品質を確保するための他の対策を講じるなど、制御をすでに実行しています。安全なファイルを使用して Mule を設定するだけでなく、安全な設定ファイルを使用することもお勧めします。 ## [](#強化チェックリスト)強化チェックリスト オンプレミスでホストしている Mule インストールの強化を開始する手順は、次のとおりです。 - Mule を非特権ユーザーとして実行します。 - Mule をサービスとしてインストールします。 - ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。 - 一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。 - 証明書をキーストアファイルで管理します。 - 個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。 Runtime Fabric に固有の手順については、​[「Runtime Fabric での Mule Runtime の強化」](https://docs.mulesoft.com/runtime-fabric/latest/configure-hardening)​を参照してください。 ### [](#mule-を非特権ユーザーとして実行することについて)Mule を非特権ユーザーとして実行することについて Linux および Unix では、次の注意事項を念頭に置いて、Mule を任意のユーザーとして実行できます。 - ログディレクトリへの書き込み権限が必要です - root 権限なしで、1024 未満のポートを使用することはできません Windows では、Mule を実行するには、管理ユーザーのグループに属している必要があります。 ## [](#多層の強化)多層の強化 その性質から、Mule はさまざまな設定下に置くことができます。推奨される強化の方法は、まずオペレーティングシステムから開始し、徐々に積み上げて強化を多層化する方法です。Center for Internet Security (CIS) がパブリッシュしている設定ベンチマークは、システムの強化ガイドとして全体的または部分的に広く使用されています。 商業設定管理ツールおよび整合性管理ツールは、CIS ベンチマークに対する管理を自動化するのに役立つ可能性があります。また、Mule ドキュメントにはセキュリティの設定に関する多くの情報が含まれます。アプリケーションで機密データを取り扱う場合は、SSL トランスポート (HTTPS) を使用して機密データを保護することを考慮してください。 ネットワークセキュリティの面では、セキュリティの専門家は、デフォルト拒否のルールセットを設定し、正当化されたビジネスニーズのみを例外として認める適切なステートフルインスペクションネットワークファイアウォールを使用することを推奨しています。また、インターネット向けのすべてのサーバーを DMZ 内に含めて、デフォルト拒否の強力な送信ルールをファイアウォールに設定し、データの流出を防ぎます。さらに、ネットワーク IDS/IPS を使用して、既知の攻撃を監視し、防ぐことができます。データベースを DMZ ではなく内部ネットワークに配置することで、インストールを強化することもできます。 ソフトウェア開発者が安全な Web アプリケーションのコーディング技法に精通していることを確認してください。少なくとも、ソフトウェア開発者は、OWASP の上位 10 件のプロジェクトにリストされているような、一般的な Web アプリケーションの落とし穴を回避するためのベストプラクティスに精通している必要があります。 ## [](#関連情報)関連情報 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.3/securing) # Mule インストールの強化 強化とは、セキュリティとは異なり、アプリケーションを開発から本番に移行するために実行する必要がある手順を意味します。これは、開発サイクルの完了後に、IT 空間に何かをデプロイするために従う必要がある精巧な手順です。 通常、IT 組織は、オープンポートを最小限に維持し、管理アプリケーションへのアクセスを制限し、アプリケーション数を最小限に抑え、品質を確保するための他の対策を講じるなど、制御をすでに実行しています。安全なファイルを使用して Mule を設定するだけでなく、安全な設定ファイルを使用することもお勧めします。 ## [](#強化チェックリスト)強化チェックリスト オンプレミスでホストしている Mule インストールの強化を開始する手順は、次のとおりです。 - Mule を非特権ユーザーとして実行します。 - Mule をサービスとしてインストールします。 - ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。 - 一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。 - 証明書をキーストアファイルで管理します。 - 個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。 Runtime Fabric に固有の手順については、​[「Runtime Fabric での Mule Runtime の強化」](https://docs.mulesoft.com/runtime-fabric/latest/configure-hardening)​を参照してください。 ### [](#mule-を非特権ユーザーとして実行することについて)Mule を非特権ユーザーとして実行することについて Linux および Unix では、次の注意事項を念頭に置いて、Mule を任意のユーザーとして実行できます。 - ログディレクトリへの書き込み権限が必要です - root 権限なしで、1024 未満のポートを使用することはできません Windows では、Mule を実行するには、管理ユーザーのグループに属している必要があります。 ## [](#多層の強化)多層の強化 その性質から、Mule はさまざまな設定下に置くことができます。推奨される強化の方法は、まずオペレーティングシステムから開始し、徐々に積み上げて強化を多層化する方法です。Center for Internet Security (CIS) がパブリッシュしている設定ベンチマークは、システムの強化ガイドとして全体的または部分的に広く使用されています。 商業設定管理ツールおよび整合性管理ツールは、CIS ベンチマークに対する管理を自動化するのに役立つ可能性があります。また、Mule ドキュメントにはセキュリティの設定に関する多くの情報が含まれます。アプリケーションで機密データを取り扱う場合は、SSL トランスポート (HTTPS) を使用して機密データを保護することを考慮してください。 ネットワークセキュリティの面では、セキュリティの専門家は、デフォルト拒否のルールセットを設定し、正当化されたビジネスニーズのみを例外として認める適切なステートフルインスペクションネットワークファイアウォールを使用することを推奨しています。また、インターネット向けのすべてのサーバーを DMZ 内に含めて、デフォルト拒否の強力な送信ルールをファイアウォールに設定し、データの流出を防ぎます。さらに、ネットワーク IDS/IPS を使用して、既知の攻撃を監視し、防ぐことができます。データベースを DMZ ではなく内部ネットワークに配置することで、インストールを強化することもできます。 ソフトウェア開発者が安全な Web アプリケーションのコーディング技法に精通していることを確認してください。少なくとも、ソフトウェア開発者は、OWASP の上位 10 件のプロジェクトにリストされているような、一般的な Web アプリケーションの落とし穴を回避するためのベストプラクティスに精通している必要があります。 ## [](#関連情報)関連情報 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.4/securing) # Mule インストールの強化 強化とは、セキュリティとは異なり、アプリケーションを開発から本番に移行するために実行する必要がある手順を意味します。これは、開発サイクルの完了後に、IT 空間に何かをデプロイするために従う必要がある精巧な手順です。 通常、IT 組織は、オープンポートを最小限に維持し、管理アプリケーションへのアクセスを制限し、アプリケーション数を最小限に抑え、品質を確保するための他の対策を講じるなど、制御をすでに実行しています。安全なファイルを使用して Mule を設定するだけでなく、安全な設定ファイルを使用することもお勧めします。 ## [](#強化チェックリスト)強化チェックリスト オンプレミスでホストしている Mule インストールの強化を開始する手順は、次のとおりです。 - Mule を非特権ユーザーとして実行します。 - Mule をサービスとしてインストールします。 - ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。 - 一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。 - 証明書をキーストアファイルで管理します。 - 個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。 Runtime Fabric に固有の手順については、​[「Runtime Fabric での Mule Runtime の強化」](https://docs.mulesoft.com/runtime-fabric/latest/configure-hardening)​を参照してください。 ### [](#mule-を非特権ユーザーとして実行することについて)Mule を非特権ユーザーとして実行することについて Linux および Unix では、次の注意事項を念頭に置いて、Mule を任意のユーザーとして実行できます。 - ログディレクトリへの書き込み権限が必要です - root 権限なしで、1024 未満のポートを使用することはできません Windows では、Mule を実行するには、管理ユーザーのグループに属している必要があります。 ## [](#多層の強化)多層の強化 その性質から、Mule はさまざまな設定下に置くことができます。推奨される強化の方法は、まずオペレーティングシステムから開始し、徐々に積み上げて強化を多層化する方法です。Center for Internet Security (CIS) がパブリッシュしている設定ベンチマークは、システムの強化ガイドとして全体的または部分的に広く使用されています。 商業設定管理ツールおよび整合性管理ツールは、CIS ベンチマークに対する管理を自動化するのに役立つ可能性があります。また、Mule ドキュメントにはセキュリティの設定に関する多くの情報が含まれます。アプリケーションで機密データを取り扱う場合は、SSL トランスポート (HTTPS) を使用して機密データを保護することを考慮してください。 ネットワークセキュリティの面では、セキュリティの専門家は、デフォルト拒否のルールセットを設定し、正当化されたビジネスニーズのみを例外として認める適切なステートフルインスペクションネットワークファイアウォールを使用することを推奨しています。また、インターネット向けのすべてのサーバーを DMZ 内に含めて、デフォルト拒否の強力な送信ルールをファイアウォールに設定し、データの流出を防ぎます。さらに、ネットワーク IDS/IPS を使用して、既知の攻撃を監視し、防ぐことができます。データベースを DMZ ではなく内部ネットワークに配置することで、インストールを強化することもできます。 ソフトウェア開発者が安全な Web アプリケーションのコーディング技法に精通していることを確認してください。少なくとも、ソフトウェア開発者は、OWASP の上位 10 件のプロジェクトにリストされているような、一般的な Web アプリケーションの落とし穴を回避するためのベストプラクティスに精通している必要があります。 ## [](#関連情報)関連情報 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.5/securing) # Mule インストールの強化 強化とは、セキュリティとは異なり、アプリケーションを開発から本番に移行するために実行する必要がある手順を意味します。これは、開発サイクルの完了後に、IT 空間に何かをデプロイするために従う必要がある精巧な手順です。 通常、IT 組織は、オープンポートを最小限に維持し、管理アプリケーションへのアクセスを制限し、アプリケーション数を最小限に抑え、品質を確保するための他の対策を講じるなど、制御をすでに実行しています。安全なファイルを使用して Mule を設定するだけでなく、安全な設定ファイルを使用することもお勧めします。 ## [](#強化チェックリスト)強化チェックリスト オンプレミスでホストしている Mule インストールの強化を開始する手順は、次のとおりです。 - Mule を非特権ユーザーとして実行します。 - Mule をサービスとしてインストールします。 - ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。 - 一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。 - 証明書をキーストアファイルで管理します。 - 個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。 Runtime Fabric に固有の手順については、​[「Runtime Fabric での Mule Runtime の強化」](https://docs.mulesoft.com/runtime-fabric/latest/configure-hardening)​を参照してください。 ### [](#mule-を非特権ユーザーとして実行することについて)Mule を非特権ユーザーとして実行することについて Linux および Unix では、次の注意事項を念頭に置いて、Mule を任意のユーザーとして実行できます。 - ログディレクトリへの書き込み権限が必要です - root 権限なしで、1024 未満のポートを使用することはできません Windows では、Mule を実行するには、管理ユーザーのグループに属している必要があります。 ## [](#多層の強化)多層の強化 その性質から、Mule はさまざまな設定下に置くことができます。推奨される強化の方法は、まずオペレーティングシステムから開始し、徐々に積み上げて強化を多層化する方法です。Center for Internet Security (CIS) がパブリッシュしている設定ベンチマークは、システムの強化ガイドとして全体的または部分的に広く使用されています。 商業設定管理ツールおよび整合性管理ツールは、CIS ベンチマークに対する管理を自動化するのに役立つ可能性があります。また、Mule ドキュメントにはセキュリティの設定に関する多くの情報が含まれます。アプリケーションで機密データを取り扱う場合は、SSL トランスポート (HTTPS) を使用して機密データを保護することを考慮してください。 ネットワークセキュリティの面では、セキュリティの専門家は、デフォルト拒否のルールセットを設定し、正当化されたビジネスニーズのみを例外として認める適切なステートフルインスペクションネットワークファイアウォールを使用することを推奨しています。また、インターネット向けのすべてのサーバーを DMZ 内に含めて、デフォルト拒否の強力な送信ルールをファイアウォールに設定し、データの流出を防ぎます。さらに、ネットワーク IDS/IPS を使用して、既知の攻撃を監視し、防ぐことができます。データベースを DMZ ではなく内部ネットワークに配置することで、インストールを強化することもできます。 ソフトウェア開発者が安全な Web アプリケーションのコーディング技法に精通していることを確認してください。少なくとも、ソフトウェア開発者は、OWASP の上位 10 件のプロジェクトにリストされているような、一般的な Web アプリケーションの落とし穴を回避するためのベストプラクティスに精通している必要があります。 ## [](#関連情報)関連情報 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.6/securing) # Mule インストールの強化 強化とは、セキュリティとは異なり、アプリケーションを開発から本番に移行するために実行する必要がある手順を意味します。これは、開発サイクルの完了後に、IT 空間に何かをデプロイするために従う必要がある精巧な手順です。 通常、IT 組織は、オープンポートを最小限に維持し、管理アプリケーションへのアクセスを制限し、アプリケーション数を最小限に抑え、品質を確保するための他の対策を講じるなど、制御をすでに実行しています。安全なファイルを使用して Mule を設定するだけでなく、安全な設定ファイルを使用することもお勧めします。 ## [](#強化チェックリスト)強化チェックリスト オンプレミスでホストしている Mule インストールの強化を開始する手順は、次のとおりです。 - Mule を非特権ユーザーとして実行します。 - Mule をサービスとしてインストールします。 - ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。 - 一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。 - 証明書をキーストアファイルで管理します。 - 個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。 Runtime Fabric に固有の手順については、​[「Runtime Fabric での Mule Runtime の強化」](https://docs.mulesoft.com/runtime-fabric/latest/configure-hardening)​を参照してください。 ### [](#mule-を非特権ユーザーとして実行することについて)Mule を非特権ユーザーとして実行することについて Linux および Unix では、次の注意事項を念頭に置いて、Mule を任意のユーザーとして実行できます。 - ログディレクトリへの書き込み権限が必要です - root 権限なしで、1024 未満のポートを使用することはできません Windows では、Mule を実行するには、管理ユーザーのグループに属している必要があります。 ## [](#多層の強化)多層の強化 その性質から、Mule はさまざまな設定下に置くことができます。推奨される強化の方法は、まずオペレーティングシステムから開始し、徐々に積み上げて強化を多層化する方法です。Center for Internet Security (CIS) がパブリッシュしている設定ベンチマークは、システムの強化ガイドとして全体的または部分的に広く使用されています。 商業設定管理ツールおよび整合性管理ツールは、CIS ベンチマークに対する管理を自動化するのに役立つ可能性があります。また、Mule ドキュメントにはセキュリティの設定に関する多くの情報が含まれます。アプリケーションで機密データを取り扱う場合は、SSL トランスポート (HTTPS) を使用して機密データを保護することを考慮してください。 ネットワークセキュリティの面では、セキュリティの専門家は、デフォルト拒否のルールセットを設定し、正当化されたビジネスニーズのみを例外として認める適切なステートフルインスペクションネットワークファイアウォールを使用することを推奨しています。また、インターネット向けのすべてのサーバーを DMZ 内に含めて、デフォルト拒否の強力な送信ルールをファイアウォールに設定し、データの流出を防ぎます。さらに、ネットワーク IDS/IPS を使用して、既知の攻撃を監視し、防ぐことができます。データベースを DMZ ではなく内部ネットワークに配置することで、インストールを強化することもできます。 ソフトウェア開発者が安全な Web アプリケーションのコーディング技法に精通していることを確認してください。少なくとも、ソフトウェア開発者は、OWASP の上位 10 件のプロジェクトにリストされているような、一般的な Web アプリケーションの落とし穴を回避するためのベストプラクティスに精通している必要があります。 ## [](#関連情報)関連情報 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.7/securing) # Mule インストールの強化 強化とは、セキュリティとは異なり、アプリケーションを開発から本番に移行するために実行する必要がある手順を意味します。これは、開発サイクルの完了後に、IT 空間に何かをデプロイするために従う必要がある精巧な手順です。 通常、IT 組織は、オープンポートを最小限に維持し、管理アプリケーションへのアクセスを制限し、アプリケーション数を最小限に抑え、品質を確保するための他の対策を講じるなど、制御をすでに実行しています。安全なファイルを使用して Mule を設定するだけでなく、安全な設定ファイルを使用することもお勧めします。 ## [](#強化チェックリスト)強化チェックリスト オンプレミスでホストしている Mule インストールの強化を開始する手順は、次のとおりです。 - Mule を非特権ユーザーとして実行します。 - Mule をサービスとしてインストールします。 - ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。 - 一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。 - 証明書をキーストアファイルで管理します。 - 個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。 Runtime Fabric に固有の手順については、​[「Runtime Fabric での Mule Runtime の強化」](https://docs.mulesoft.com/runtime-fabric/latest/configure-hardening)​を参照してください。 ### [](#mule-を非特権ユーザーとして実行することについて)Mule を非特権ユーザーとして実行することについて Linux および Unix では、次の注意事項を念頭に置いて、Mule を任意のユーザーとして実行できます。 - ログディレクトリへの書き込み権限が必要です - root 権限なしで、1024 未満のポートを使用することはできません Windows では、Mule を実行するには、管理ユーザーのグループに属している必要があります。 ## [](#多層の強化)多層の強化 その性質から、Mule はさまざまな設定下に置くことができます。推奨される強化の方法は、まずオペレーティングシステムから開始し、徐々に積み上げて強化を多層化する方法です。Center for Internet Security (CIS) がパブリッシュしている設定ベンチマークは、システムの強化ガイドとして全体的または部分的に広く使用されています。 商業設定管理ツールおよび整合性管理ツールは、CIS ベンチマークに対する管理を自動化するのに役立つ可能性があります。また、Mule ドキュメントにはセキュリティの設定に関する多くの情報が含まれます。アプリケーションで機密データを取り扱う場合は、SSL トランスポート (HTTPS) を使用して機密データを保護することを考慮してください。 ネットワークセキュリティの面では、セキュリティの専門家は、デフォルト拒否のルールセットを設定し、正当化されたビジネスニーズのみを例外として認める適切なステートフルインスペクションネットワークファイアウォールを使用することを推奨しています。また、インターネット向けのすべてのサーバーを DMZ 内に含めて、デフォルト拒否の強力な送信ルールをファイアウォールに設定し、データの流出を防ぎます。さらに、ネットワーク IDS/IPS を使用して、既知の攻撃を監視し、防ぐことができます。データベースを DMZ ではなく内部ネットワークに配置することで、インストールを強化することもできます。 ソフトウェア開発者が安全な Web アプリケーションのコーディング技法に精通していることを確認してください。少なくとも、ソフトウェア開発者は、OWASP の上位 10 件のプロジェクトにリストされているような、一般的な Web アプリケーションの落とし穴を回避するためのベストプラクティスに精通している必要があります。 ## [](#関連情報)関連情報 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.8/securing) # Mule インストールの強化 強化とは、セキュリティとは異なり、アプリケーションを開発から本番に移行するために実行する必要がある手順を意味します。これは、開発サイクルの完了後に、IT 空間に何かをデプロイするために従う必要がある精巧な手順です。 通常、IT 組織は、オープンポートを最小限に維持し、管理アプリケーションへのアクセスを制限し、アプリケーション数を最小限に抑え、品質を確保するための他の対策を講じるなど、制御をすでに実行しています。安全なファイルを使用して Mule を設定するだけでなく、安全な設定ファイルを使用することもお勧めします。 ## [](#強化チェックリスト)強化チェックリスト オンプレミスでホストしている Mule インストールの強化を開始する手順は、次のとおりです。 - Mule を非特権ユーザーとして実行します。 - Mule をサービスとしてインストールします。 - ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。 - 一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。 - 証明書をキーストアファイルで管理します。 - 個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。 Runtime Fabric に固有の手順については、​[「Runtime Fabric での Mule Runtime の強化」](https://docs.mulesoft.com/runtime-fabric/latest/configure-hardening)​を参照してください。 ### [](#mule-を非特権ユーザーとして実行することについて)Mule を非特権ユーザーとして実行することについて Linux および Unix では、次の注意事項を念頭に置いて、Mule を任意のユーザーとして実行できます。 - ログディレクトリへの書き込み権限が必要です - root 権限なしで、1024 未満のポートを使用することはできません Windows では、Mule を実行するには、管理ユーザーのグループに属している必要があります。 ## [](#多層の強化)多層の強化 その性質から、Mule はさまざまな設定下に置くことができます。推奨される強化の方法は、まずオペレーティングシステムから開始し、徐々に積み上げて強化を多層化する方法です。Center for Internet Security (CIS) がパブリッシュしている設定ベンチマークは、システムの強化ガイドとして全体的または部分的に広く使用されています。 商業設定管理ツールおよび整合性管理ツールは、CIS ベンチマークに対する管理を自動化するのに役立つ可能性があります。また、Mule ドキュメントにはセキュリティの設定に関する多くの情報が含まれます。アプリケーションで機密データを取り扱う場合は、SSL トランスポート (HTTPS) を使用して機密データを保護することを考慮してください。 ネットワークセキュリティの面では、セキュリティの専門家は、デフォルト拒否のルールセットを設定し、正当化されたビジネスニーズのみを例外として認める適切なステートフルインスペクションネットワークファイアウォールを使用することを推奨しています。また、インターネット向けのすべてのサーバーを DMZ 内に含めて、デフォルト拒否の強力な送信ルールをファイアウォールに設定し、データの流出を防ぎます。さらに、ネットワーク IDS/IPS を使用して、既知の攻撃を監視し、防ぐことができます。データベースを DMZ ではなく内部ネットワークに配置することで、インストールを強化することもできます。 ソフトウェア開発者が安全な Web アプリケーションのコーディング技法に精通していることを確認してください。少なくとも、ソフトウェア開発者は、OWASP の上位 10 件のプロジェクトにリストされているような、一般的な Web アプリケーションの落とし穴を回避するためのベストプラクティスに精通している必要があります。 ## [](#関連情報)関連情報 - [セキュリティ](https://docs.mulesoft.com/jp/mule-runtime/4.9/securing) # Mule エラー Mule の実行に失敗すると、エラーが発生します。Mule アプリケーションの実行中、Mule Runtime Engine と、アプリケーションで設定されたモジュールおよびコネクタの操作の両方でエラーがスローされる可能性があります。エラーは Mule エラーオブジェクトで表され、Mule イベントに関連付けられています。On-Error コンポーネントを使用してエラーオブジェクトを処理し、それらに関する情報をログで確認できます。 Mule エラーは、階層順に従い、エラーの発生源を識別して選択したレベルでエラーを処理するのに役立つ命名規則を使用する​[エラー種別](#error_types)​にグループ化されます。これらのエラーをマッピングするカスタムエラー種別を作成することもできます。マッピングは、アプリケーションで処理する必要があるエラーをさらに識別してグループ化するのに役立つ場合があります。 エラー処理設定で Mule エラーの値を調べて使用するために、​[セレクター式](#selector_expressions)​を使用することもできます。 Mule エラーには式 (​`EXPRESSION`​) とストリームに関連したエラー (​`STREAM_MAXIMUM_SIZE_EXCEEDED`​) が含まれる一方で、操作によって多数の異なる種別のエラーがスローされる可能性があります。例として、​`HTTP:NOT_FOUND`​ (404 エラー) および HTTP Connector の HTTP リスナーからの ​`HTTP:CONNECTIVITY`​ エラーなどがあります。 `DB:BAD_SYNTAX`​ と ​`DB:QUERY_EXPRESSION`​ は、Database Connector の Select 操作でスローされる可能性があるエラーです。 モジュールおよびコネクタ (たとえば、​[HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/)​ や ​[Database Connector](https://docs.mulesoft.com/db-connector/latest/database-documentation)​ のリファレンス) では、Mule エラーをリストしています。 ## [](#selector_expressions)Mule エラーのセレクター式 Mule エラーは説明や種別など、複数の項目が含まれる複合データ型です。Mule エラーを記録して処理する場合、任意の数のエラー項目から値を選択できます。
項目 説明 セレクター式

説明

問題の説明。

#[error.description]​

Detailed Description (詳細な説明)

問題の説明。説明と同じ場合もあれば、説明よりも広範な内容の場合もあります。

#[error.detailedDescription]​

型

問題の特徴を記述し、エラーハンドラー内のルーティングを可能にするために使用される種別。

#[error.errorType]​

Cause

失敗の原因となった基になる Java ​Throwable​。

#[error.cause]​

Message (メッセージ)

問題に関する省略可能な Mule メッセージ。

#[error.errorMessage]​

Child Errors

Scatter-Gather などの要素が集約されたルートエラーを提供するために使用する内部エラーの省略可能なコレクション。

#[error.childErrors]
多くの場合、​error.cause​ セレクターは、Mule API に含まれる ​Throwable​ インスタンスを返します。このエラーの内部構造にアクセスしてエラー処理ロジックを定義しないでください。エラーを処理するためのすべての必要な情報は他のエラーセレクターによって公開されます。また、​error.cause​ をシリアル化すると、冗長な情報が生成される可能性があります。
### [](#http-request-error)HTTP 要求エラーの例 たとえば、HTTP 要求に失敗して ​`HTTP:NOT_FOUND`​ エラー (404 状況コードの場合) が表示された場合、エラーメッセージの各部の値は次のようになります。 - `#[error.description]`​ が返す内容: ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404). ``` - `#[error.detailedDescription]`​ は ​`HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404).`​ を返します。 - `#[error.errorType]`​ は ​`HTTP:NOT_FOUND`​ を返します。 - `#[error.cause]`​ は ​`org.mule.extension.http.api.request.validator.ResponseValidatorTypedException`​ を返します。​`ResponseValidatorTypedException`​ の戻りインスタンスを出力する場合、Mule は ​`toString`​ の結果を出力します。エラーに関連付けられた既知の HTTP 状況コード (404 など) がある場合、​`ResponseValidatorTypedException`​ インスタンスの文字列表現は人間が読み取り可能なエラーの説明になります。 - `#[error.errorMessage]`​ が返す内容: ```txt org.mule.runtime.core.internal.message.DefaultMessageBuilder$MessageImplementation { payload=org.mule.runtime.core.internal.streaming.bytes.ManagedCursorStreamProvider@223d8f75 mediaType=application/json; charset=UTF-8 attributes=org.mule.extension.http.api.HttpResponseAttributes { Status Code=404 Reason Phrase=Not Found Headers=[ date=Sat, 03 Aug 2019 04:28:29 GMT content-type=application/json; charset=utf-8 content-length=2 connection=keep-alive set-cookie=__cfduid=de19ed0b495b5b58e74fa0ee31a700d651564806509; expires=Sun, 02-Aug-20 04:28:29 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 pragma=no-cache expires=Sat, 03 Aug 2019 08:28:29 GMT x-content-type-options=nosniff etag=W/"2-vyGp6PvFo4RvsFtPoIWeCReyIC8" via=1.1 vegur cf-cache-status=HIT age=96 server=cloudflare cf-ray=50058b8add0a92fe-SJC ] } attributesMediaType=*/* } ``` `errorMessage`​ 要素は、コネクタまたはコンポーネントがエラーとして解釈したメッセージを公開した時点で使用可能になります。たとえば、HTTP 要求で Mule がエラーとして扱うことを示す状況コードが受信された場合、プロセスは失敗し、また、​`errorMessage`​ にエラーに関する情報が入力されます。その後、ペイロードには ​`#[error.errorMessage.payload]`​ を、メタデータには ​`#[error.errorMessage.attributes]`​ を使用して、エラーメッセージ属性 (メタデータ) およびペイロード自体にアクセスできるようになります。HTTP 要求でエラーが返される場合は、​`#[error.errorMessage.attributes.statusCode]`​ を使用して状況コードの値 (​`404`​ など) を選択できます。Studio でメッセージ属性を確認するには、​[「DataSense」](https://docs.mulesoft.com/studio/datasense-concept)​を参照してください。 - `#[error.childErrors]`​ が返す内容: `[]` ## [](#error_types)Mule エラー種別 Mule エラーには名前空間 (​`HTTP:`​ や ​`FILE:`​ など) と識別子 (​`NOT_FOUND`​ など) があり、エラー種別の階層に属します。 命名規則により、ドメインに従ってエラーを区別できます。たとえば、​`NOT_FOUND`​ をスローする代わりに、HTTP Connector は ​`HTTP:NOT_FOUND`​ をスローし、File Connector は ​`FILE:NOT_FOUND`​ エラーをスローする場合があります。 コネクタとは異なり、Mule Runtime エラーには暗黙の ​`MULE`​ 名前空間があるため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同じように解釈されます。 エラー種別には親種別がある場合があります。たとえば、​`HTTP:UNAUTHORIZED`​ の親は ​`MULE:CLIENT_SECURITY`​、​`MULE:CLIENT_SECURITY`​ の親は ​`MULE:SECURITY`​ です。この階層は、よりグローバルなエラー種別が各エラー種別に特定化されていることを示しています。 たとえば、​`HTTP:UNAUTHORIZED`​ エラー種別はクライアントセキュリティエラー (​`MULE:CLIENT_SECURITY`​) の種別の 1 つですが、クライアントセキュリティエラーはより広範なセキュリティ上の問題 (​`MULE:SECURITY`​) の種別の 1 つです。 階層により、一般的な方法、またはより特定の方法でエラーをルーティングできます。たとえば、​`MULE:SECURITY`​ のエラーハンドラーは ​`HTTP:UNAUTHORIZED`​ エラーおよび OAuth エラーをキャッチします。次の図は、コアランタイム階層を示しています。 ![エラー階層](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-hierarchy.png) すべてのエラーは ​`ANY`​ または ​`CRITICAL`​ の 2 つの主な種別に属します。​`ANY`​ の各種別はその親によって照合され、処理できるのに対して、​`CRITICAL`​ のエラー種別はきわめて厳密であるため、処理できず、ログ記録されるのみです。 `CRITICAL`​ エラーには ​`FATAL_JVM_ERROR`​ と ​`OVERLOAD`​ が含まれます。 失敗の明確な理由がない場合、コンポーネントは ​`UNKNOWN`​ 種別を使用できます。このエラーは ​`ANY`​ 種別を介して処理し、アプリケーションの既存の動作を変更せずに、不明確なエラーを定義します。 コネクタの場合、各コネクタがコアランタイム階層を考慮してそのエラー種別階層を定義しますが、​`CONNECTIVITY`​ および ​`RETRY_EXHAUSTED`​ 種別はすべてのコネクタに共通であるため、常に存在します。 エラー種別: - `ANY`​: フローで発生し、処理できるすべてのエラー種別に一致するエラー種別。この種別には、提供元で発生するエラーは含まれません。 - `TRANSFORMATION`​: 値の変換中にエラーが発生したことを示す。これには、Mule Runtime 内部変換が含まれ、DataWeave 変換は含まれません。 - `EXPRESSION`​: DataWeave 式の評価中にエラーが発生したことを示す。 - `VALIDATION`​: 検証エラーが発生したことを示す。 - `DUPLICATE_MESSAGE`​: 2 回処理されたメッセージに関する検証エラーを示す。たとえば、​[冪等性のあるメッセージバリデーター](https://docs.mulesoft.com/jp/mule-runtime/4.3/idempotent-message-validator)​の使用などです。 - `REDELIVERY_EXHAUSTED`​: ソースからのメッセージの再処理の最大試行回数に達したことを示す。 - `CONNECTIVITY`​: 接続の確立で問題が発生したことを示す。これは、たとえば HTTP リクエスターなど、コネクタの使用中に発生する可能性があります。 - `RETRY_EXHAUSTED`​: 特定の実行ブロックの再試行回数がなくなったことを示す。たとえば、特定の操作や、​[Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/until-successful-scope)​の使用などです。 - `ROUTING`​: メッセージのルーティング中にエラーが発生したことを示す。たとえば、​[Round Robin ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.3/round-robin)​の使用などです。 - `COMPOSITE_ROUTING`​: メッセージのルーティング中に 1 つ以上のエラーが発生したことを示す。たとえば、​[Scatter Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.3/scatter-gather-concept)​の使用などです。 - `SECURITY`​: 無効なログイン情報の受信や期限切れのトークンの使用など、セキュリティエラーが発生したことを示す。 - `CLIENT_SECURITY`​: 外部エンティティ (たとえば、外部エンドポイントのコール) によってセキュリティエラーが発生したことを示す。 - `SERVER_SECURITY`​: Mule Runtime によってセキュリティエラーが適用されたことを示す。 - `NOT_PERMITTED`​: 検索条件によってセキュリティ制限が適用されたことを示す。たとえば、​[Mule Spring Module の承認検索条件](https://docs.mulesoft.com/spring-module/latest/#_to_validate_authentication_using_the_spring_authorization_filter)​の使用などです。 - `STREAM_MAXIMUM_SIZE_EXCEEDED`​: ストリームに許可された最大サイズを超えたことを示す。詳細については、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.3/streaming-about)​を参照してください。 - `TIMEOUT`​: メッセージの処理中にタイムアウトが発生したことを示す。 - `UNKNOWN`​: 不明なエラーまたは予期しないエラーが発生したことを示す。このエラーは、将来のランタイムバージョンでエラー種別が追加された場合に備えて後方互換性を確保するため、直接処理することはできず、​`ANY`​ を処理することで処理するしかありません。 - `SOURCE`​: フローの取得元でエラーが発生したことを示す。このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_GENERATE`​: エラー応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_SEND`​: エラー応答の送信中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_RESPONSE`​: 成功した応答の処理中にフローの取得元でエラーが発生したことを示す。取得元がすでに成功したパスを実行しているため、このエラーは伝播のみできます。このエラーは処理できません。 - `SOURCE_RESPONSE_GENERATE`​: 成功した応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。 - `SOURCE_RESPONSE_SEND`​: 成功した応答の送信中にフローの取得元でエラーが発生したことを示す。 - `CRITICAL`​: 重大なエラーが発生したことを示す。このエラーは処理できません。 - `OVERLOAD`​: オーバーロードの問題が発生し、実行が拒否されたことを示す。 - `FLOW_BACK_PRESSURE`​: ソースレベルでオーバーロードの問題が発生したことを示す。たとえば、ソースとしての HTTP リスナーの使用などです。 - `FATAL_JVM_ERROR`​: スタックのオーバーフローなど、重大なエラーが発生したことを示す。 ## [](#カスタムエラー種別)カスタムエラー種別 カスタムエラー種別を使用するには、マッピングするときまたはエラーが​[発生した](https://docs.mulesoft.com/jp/mule-runtime/4.3/raise-error-component-reference)​ときに定義する必要があります。このエラーは、アプリケーション内の既存の種別と区別するために特定のカスタム名前空間が必要です。つまり、HTTP および Database Connector 操作を使用するアプリケーションでは、カスタムエラー種別に HTTP および DB 名前空間を使用できません。 特定の Mule アプリケーション名またはコンテキストに関連した名前空間を定義し、既存のコネクタ名前空間の使用を避ける必要があります。たとえば、顧客集約 API は ​`CUSTOMER`​ 名前空間をそのカスタムエラー種別に使用でき、受注処理 API は ​`ORDER`​ 名前空間を使用できます。 ## [](#エラーのマッピング)エラーのマッピング フローの各操作で、可能性のあるエラー種別を選択したカスタムエラー種別にマップできます。これらのカスタムエラー種別を使用して、フローのどこでエラーが発生したかを識別できます。 たとえば、フローに異なる REST サービスにアクセスする 2 つの HTTP Request 操作がある場合、一方での接続失敗によって同じエラーが発生します。各エラーを異なるカスタムエラー種別にマッピングすることで、各操作失敗のエラー処理を識別でき、Mule アプリケーションログでエラーの発生元をすばやく識別できます。 次の例では、マッピングによって 2 つのカスタムエラー種別 ​`APP:CUSTOMER_API`​ および ​`APP:ORDER_API`​ を定義することで、きめ細かいエラー処理が可能になることがわかります。 マッピングの XML 設定の例 ```xml ``` ## [](#関連情報)関連情報 - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/on-error-scope-concept) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.3/logging-and-debugging) # Mule エラー Mule の実行に失敗すると、エラーが発生します。Mule アプリケーションの実行中、Mule Runtime Engine と、アプリケーションで設定されたモジュールおよびコネクタの操作の両方でエラーがスローされる可能性があります。エラーは Mule エラーオブジェクトで表され、Mule イベントに関連付けられています。On-Error コンポーネントを使用してエラーオブジェクトを処理し、それらに関する情報をログで確認できます。 Mule エラーは、階層順に従い、エラーの発生源を識別して選択したレベルでエラーを処理するのに役立つ命名規則を使用する​[エラー種別](#error_types)​にグループ化されます。これらのエラーをマッピングするカスタムエラー種別を作成することもできます。マッピングは、アプリケーションで処理する必要があるエラーをさらに識別してグループ化するのに役立つ場合があります。 エラー処理設定で Mule エラーの値を調べて使用するために、​[セレクター式](#selector_expressions)​を使用することもできます。 Mule エラーには式 (​`EXPRESSION`​) とストリームに関連したエラー (​`STREAM_MAXIMUM_SIZE_EXCEEDED`​) が含まれる一方で、操作によって多数の異なる種別のエラーがスローされる可能性があります。例として、​`HTTP:NOT_FOUND`​ (404 エラー) および HTTP Connector の HTTP リスナーからの ​`HTTP:CONNECTIVITY`​ エラーなどがあります。 `DB:BAD_SYNTAX`​ と ​`DB:QUERY_EXPRESSION`​ は、Database Connector の Select 操作でスローされる可能性があるエラーです。 モジュールおよびコネクタ (たとえば、​[HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/)​ や ​[Database Connector](https://docs.mulesoft.com/db-connector/latest/database-documentation)​ のリファレンス) では、Mule エラーをリストしています。 ## [](#selector_expressions)Mule エラーのセレクター式 Mule エラーは説明や種別など、複数の項目が含まれる複合データ型です。Mule エラーを記録して処理する場合、任意の数のエラー項目から値を選択できます。
項目 説明 セレクター式

説明

問題の説明。

#[error.description]​

Detailed Description (詳細な説明)

問題の説明。説明と同じ場合もあれば、説明よりも広範な内容の場合もあります。

#[error.detailedDescription]​

型

問題の特徴を記述し、エラーハンドラー内のルーティングを可能にするために使用される種別。

#[error.errorType]​

Cause

失敗の原因となった基になる Java ​Throwable​。

#[error.cause]​

Message (メッセージ)

問題に関する省略可能な Mule メッセージ。

#[error.errorMessage]​

Child Errors

Scatter-Gather などの要素が集約されたルートエラーを提供するために使用する内部エラーの省略可能なコレクション。

#[error.childErrors]
多くの場合、​error.cause​ セレクターは、Mule API に含まれる ​Throwable​ インスタンスを返します。このエラーの内部構造にアクセスしてエラー処理ロジックを定義しないでください。エラーを処理するためのすべての必要な情報は他のエラーセレクターによって公開されます。また、​error.cause​ をシリアル化すると、冗長な情報が生成される可能性があります。
### [](#http-request-error)HTTP 要求エラーの例 たとえば、HTTP 要求に失敗して ​`HTTP:NOT_FOUND`​ エラー (404 状況コードの場合) が表示された場合、エラーメッセージの各部の値は次のようになります。 - `#[error.description]`​ が返す内容: ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404). ``` - `#[error.detailedDescription]`​ は ​`HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404).`​ を返します。 - `#[error.errorType]`​ は ​`HTTP:NOT_FOUND`​ を返します。 - `#[error.cause]`​ は ​`org.mule.extension.http.api.request.validator.ResponseValidatorTypedException`​ を返します。​`ResponseValidatorTypedException`​ の戻りインスタンスを出力する場合、Mule は ​`toString`​ の結果を出力します。エラーに関連付けられた既知の HTTP 状況コード (404 など) がある場合、​`ResponseValidatorTypedException`​ インスタンスの文字列表現は人間が読み取り可能なエラーの説明になります。 - `#[error.errorMessage]`​ が返す内容: ```txt org.mule.runtime.core.internal.message.DefaultMessageBuilder$MessageImplementation { payload=org.mule.runtime.core.internal.streaming.bytes.ManagedCursorStreamProvider@223d8f75 mediaType=application/json; charset=UTF-8 attributes=org.mule.extension.http.api.HttpResponseAttributes { Status Code=404 Reason Phrase=Not Found Headers=[ date=Sat, 03 Aug 2019 04:28:29 GMT content-type=application/json; charset=utf-8 content-length=2 connection=keep-alive set-cookie=__cfduid=de19ed0b495b5b58e74fa0ee31a700d651564806509; expires=Sun, 02-Aug-20 04:28:29 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 pragma=no-cache expires=Sat, 03 Aug 2019 08:28:29 GMT x-content-type-options=nosniff etag=W/"2-vyGp6PvFo4RvsFtPoIWeCReyIC8" via=1.1 vegur cf-cache-status=HIT age=96 server=cloudflare cf-ray=50058b8add0a92fe-SJC ] } attributesMediaType=*/* } ``` `errorMessage`​ 要素は、コネクタまたはコンポーネントがエラーとして解釈したメッセージを公開した時点で使用可能になります。たとえば、HTTP 要求で Mule がエラーとして扱うことを示す状況コードが受信された場合、プロセスは失敗し、また、​`errorMessage`​ にエラーに関する情報が入力されます。その後、ペイロードには ​`#[error.errorMessage.payload]`​ を、メタデータには ​`#[error.errorMessage.attributes]`​ を使用して、エラーメッセージ属性 (メタデータ) およびペイロード自体にアクセスできるようになります。HTTP 要求でエラーが返される場合は、​`#[error.errorMessage.attributes.statusCode]`​ を使用して状況コードの値 (​`404`​ など) を選択できます。Studio でメッセージ属性を確認するには、​[「DataSense」](https://docs.mulesoft.com/studio/datasense-concept)​を参照してください。 - `#[error.childErrors]`​ が返す内容: `[]` ## [](#error_types)Mule エラー種別 Mule エラーには名前空間 (​`HTTP:`​ や ​`FILE:`​ など) と識別子 (​`NOT_FOUND`​ など) があり、エラー種別の階層に属します。 命名規則により、ドメインに従ってエラーを区別できます。たとえば、​`NOT_FOUND`​ をスローする代わりに、HTTP Connector は ​`HTTP:NOT_FOUND`​ をスローし、File Connector は ​`FILE:NOT_FOUND`​ エラーをスローする場合があります。 コネクタとは異なり、Mule ランタイムエラーには暗黙の ​`MULE`​ 名前空間があるため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同じように解釈されます。 エラー種別には親種別がある場合があります。たとえば、​`HTTP:UNAUTHORIZED`​ の親は ​`MULE:CLIENT_SECURITY`​、​`MULE:CLIENT_SECURITY`​ の親は ​`MULE:SECURITY`​ です。この階層は、よりグローバルなエラー種別が各エラー種別に特定化されていることを示しています。 たとえば、​`HTTP:UNAUTHORIZED`​ エラー種別はクライアントセキュリティエラー (​`MULE:CLIENT_SECURITY`​) の種別の 1 つですが、クライアントセキュリティエラーはより広範なセキュリティ上の問題 (​`MULE:SECURITY`​) の種別の 1 つです。 階層により、一般的な方法、またはより特定の方法でエラーをルーティングできます。たとえば、​`MULE:SECURITY`​ のエラーハンドラーは ​`HTTP:UNAUTHORIZED`​ エラーおよび OAuth エラーをキャッチします。次の図は、コアランタイム階層を示しています。 ![エラー階層](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-hierarchy.png) すべてのエラーは ​`ANY`​ または ​`CRITICAL`​ の 2 つの主な種別に属します。​`ANY`​ の各種別はその親によって照合され、処理できるのに対して、​`CRITICAL`​ のエラー種別はきわめて厳密であるため、処理できず、ログ記録されるのみです。 `CRITICAL`​ エラーには ​`FATAL_JVM_ERROR`​ と ​`OVERLOAD`​ が含まれます。 失敗の明確な理由がない場合、コンポーネントは ​`UNKNOWN`​ 種別を使用できます。このエラーは ​`ANY`​ 種別を介して処理し、アプリケーションの既存の動作を変更せずに、不明確なエラーを定義します。 コネクタの場合、各コネクタがコアランタイム階層を考慮してそのエラー種別階層を定義しますが、​`CONNECTIVITY`​ および ​`RETRY_EXHAUSTED`​ 種別はすべてのコネクタに共通であるため、常に存在します。 エラー種別: - `ANY`​: フローで発生し、処理できるすべてのエラー種別に一致するエラー種別。この種別には、提供元で発生するエラーは含まれません。 - `TRANSFORMATION`​: 値の変換中にエラーが発生したことを示す。これには、Mule Runtime 内部変換が含まれ、DataWeave 変換は含まれません。 - `EXPRESSION`​: DataWeave 式の評価中にエラーが発生したことを示す。 - `VALIDATION`​: 検証エラーが発生したことを示す。 - `DUPLICATE_MESSAGE`​: 2 回処理されたメッセージに関する検証エラーを示す。たとえば、​[冪等性のあるメッセージバリデーター](https://docs.mulesoft.com/jp/mule-runtime/4.4/idempotent-message-validator)​の使用などです。 - `REDELIVERY_EXHAUSTED`​: ソースからのメッセージの再処理の最大試行回数に達したことを示す。 - `CONNECTIVITY`​: 接続の確立で問題が発生したことを示す。これは、たとえば HTTP リクエスターなど、コネクタの使用中に発生する可能性があります。 - `RETRY_EXHAUSTED`​: 特定の実行ブロックの再試行回数がなくなったことを示す。たとえば、特定の操作や、​[Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/until-successful-scope)​の使用などです。 - `ROUTING`​: メッセージのルーティング中にエラーが発生したことを示す。たとえば、​[Round Robin ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.4/round-robin)​の使用などです。 - `COMPOSITE_ROUTING`​: メッセージのルーティング中に 1 つ以上のエラーが発生したことを示す。たとえば、​[Scatter Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.4/scatter-gather-concept)​の使用などです。 - `SECURITY`​: 無効なログイン情報の受信や期限切れのトークンの使用など、セキュリティエラーが発生したことを示す。 - `CLIENT_SECURITY`​: 外部エンティティ (たとえば、外部エンドポイントのコール) によってセキュリティエラーが発生したことを示す。 - `SERVER_SECURITY`​: Mule Runtime によってセキュリティエラーが適用されたことを示す。 - `NOT_PERMITTED`​: 検索条件によってセキュリティ制限が適用されたことを示す。たとえば、​[Mule Spring Module の認証検索条件](https://docs.mulesoft.com/spring-module/latest/#_to_validate_authentication_using_the_spring_authorization_filter)​の使用などです。 - `STREAM_MAXIMUM_SIZE_EXCEEDED`​: ストリームに許可された最大サイズを超えたことを示す。詳細については、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.4/streaming-about)​を参照してください。 - `TIMEOUT`​: メッセージの処理中にタイムアウトが発生したことを示す。 - `UNKNOWN`​: 不明なエラーまたは予期しないエラーが発生したことを示す。このエラーは、将来のランタイムバージョンでエラー種別が追加された場合に備えて後方互換性を確保するため、直接処理することはできず、​`ANY`​ を処理することで処理するしかありません。 - `SOURCE`​: フローの取得元でエラーが発生したことを示す。このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_GENERATE`​: エラー応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_SEND`​: エラー応答の送信中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_RESPONSE`​: 成功した応答の処理中にフローの取得元でエラーが発生したことを示す。取得元がすでに成功したパスを実行しているため、このエラーは伝播のみできます。このエラーは処理できません。 - `SOURCE_RESPONSE_GENERATE`​: 成功した応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。 - `SOURCE_RESPONSE_SEND`​: 成功した応答の送信中にフローの取得元でエラーが発生したことを示す。 - `CRITICAL`​: 重大なエラーが発生したことを示す。このエラーは処理できません。 - `OVERLOAD`​: オーバーロードの問題が発生し、実行が拒否されたことを示す。 - `FLOW_BACK_PRESSURE`​: ソースレベルでオーバーロードの問題が発生したことを示す。たとえば、ソースとしての HTTP リスナーの使用などです。 - `FATAL_JVM_ERROR`​: スタックのオーバーフローなど、重大なエラーが発生したことを示す。 ## [](#カスタムエラー種別)カスタムエラー種別 カスタムエラー種別を使用するには、マッピングするときまたはエラーが​[発生した](https://docs.mulesoft.com/jp/mule-runtime/4.4/raise-error-component-reference)​ときに定義する必要があります。このエラーは、アプリケーション内の既存の種別と区別するために特定のカスタム名前空間が必要です。つまり、HTTP および Database Connector 操作を使用するアプリケーションでは、カスタムエラー種別に HTTP および DB 名前空間を使用できません。 特定の Mule アプリケーション名またはコンテキストに関連した名前空間を定義し、既存のコネクタ名前空間の使用を避ける必要があります。たとえば、顧客集約 API は ​`CUSTOMER`​ 名前空間をそのカスタムエラー種別に使用でき、受注処理 API は ​`ORDER`​ 名前空間を使用できます。 ## [](#エラーのマッピング)エラーのマッピング フローの各操作で、可能性のあるエラー種別を選択したカスタムエラー種別にマップできます。これらのカスタムエラー種別を使用して、フローのどこでエラーが発生したかを識別できます。 たとえば、フローに異なる REST サービスにアクセスする 2 つの HTTP Request 操作がある場合、一方での接続失敗によって同じエラーが発生します。各エラーを異なるカスタムエラー種別にマッピングすることで、各操作失敗のエラー処理を識別でき、Mule アプリケーションログでエラーの発生元をすばやく識別できます。 次の例では、マッピングによって 2 つのカスタムエラー種別 ​`APP:CUSTOMER_API`​ および ​`APP:ORDER_API`​ を定義することで、きめ細かいエラー処理が可能になることがわかります。 マッピングの XML 設定の例 ```xml ``` ## [](#関連情報)関連情報 - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/on-error-scope-concept) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.4/logging-and-debugging) # Mule エラー Mule の実行に失敗すると、エラーが発生します。Mule アプリケーションの実行中、Mule Runtime Engine と、アプリケーションで設定されたモジュールおよびコネクタの操作の両方でエラーがスローされる可能性があります。エラーは Mule エラーオブジェクトで表され、Mule イベントに関連付けられています。On-Error コンポーネントを使用してエラーオブジェクトを処理し、それらに関する情報をログで確認できます。 Mule エラーは、階層順に従い、エラーの発生源を識別して選択したレベルでエラーを処理するのに役立つ命名規則を使用する​[エラー種別](#error_types)​にグループ化されます。これらのエラーをマッピングするカスタムエラー種別を作成することもできます。マッピングは、アプリケーションで処理する必要があるエラーをさらに識別してグループ化するのに役立つ場合があります。 エラー処理設定で Mule エラーの値を調べて使用するために、​[セレクター式](#selector_expressions)​を使用することもできます。 Mule エラーには式 (​`EXPRESSION`​) とストリームに関連したエラー (​`STREAM_MAXIMUM_SIZE_EXCEEDED`​) が含まれる一方で、操作によって多数の異なる種別のエラーがスローされる可能性があります。例として、​`HTTP:NOT_FOUND`​ (404 エラー) および HTTP Connector の HTTP リスナーからの ​`HTTP:CONNECTIVITY`​ エラーなどがあります。 `DB:BAD_SYNTAX`​ と ​`DB:QUERY_EXPRESSION`​ は、Database Connector の Select 操作でスローされる可能性があるエラーです。 モジュールおよびコネクタ (たとえば、​[HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/)​ や ​[Database Connector](https://docs.mulesoft.com/db-connector/latest/database-documentation)​ のリファレンス) では、Mule エラーをリストしています。 ## [](#selector_expressions)Mule エラーのセレクター式 Mule エラーは説明や種別など、複数の項目が含まれる複合データ型です。Mule エラーを記録して処理する場合、任意の数のエラー項目から値を選択できます。
項目 説明 セレクター式

説明

問題の説明。

#[error.description]​

Detailed Description (詳細な説明)

問題の説明。説明と同じ場合もあれば、説明よりも広範な内容の場合もあります。

#[error.detailedDescription]​

Type (種別)

問題の特徴を記述し、エラーハンドラー内のルーティングを可能にするために使用される種別。

#[error.errorType]​

Cause

失敗の原因となった基になる Java ​Throwable​。

#[error.cause]​

Message (メッセージ)

問題に関する省略可能な Mule メッセージ。

#[error.errorMessage]​

Child Errors

Scatter-Gather などの要素が集約されたルートエラーを提供するために使用する内部エラーの省略可能なコレクション。

#[error.childErrors]
多くの場合、​error.cause​ セレクターは、Mule API に含まれる ​Throwable​ インスタンスを返します。このエラーの内部構造にアクセスしてエラー処理ロジックを定義しないでください。エラーを処理するためのすべての必要な情報は他のエラーセレクターによって公開されます。また、​error.cause​ をシリアル化すると、冗長な情報が生成される可能性があります。
### [](#http-request-error)HTTP 要求エラーの例 たとえば、HTTP 要求に失敗して ​`HTTP:NOT_FOUND`​ エラー (404 状況コードの場合) が表示された場合、エラーメッセージの各部の値は次のようになります。 - `#[error.description]`​ が返す内容: ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404). ``` - `#[error.detailedDescription]`​ は ​`HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404).`​ を返します。 - `#[error.errorType]`​ は ​`HTTP:NOT_FOUND`​ を返します。 - `#[error.cause]`​ は ​`org.mule.extension.http.api.request.validator.ResponseValidatorTypedException`​ を返します。​`ResponseValidatorTypedException`​ の戻りインスタンスを出力する場合、Mule は ​`toString`​ の結果を出力します。エラーに関連付けられた既知の HTTP 状況コード (404 など) がある場合、​`ResponseValidatorTypedException`​ インスタンスの文字列表現は人間が読み取り可能なエラーの説明になります。 - `#[error.errorMessage]`​ が返す内容: ```txt org.mule.runtime.core.internal.message.DefaultMessageBuilder$MessageImplementation { payload=org.mule.runtime.core.internal.streaming.bytes.ManagedCursorStreamProvider@223d8f75 mediaType=application/json; charset=UTF-8 attributes=org.mule.extension.http.api.HttpResponseAttributes { Status Code=404 Reason Phrase=Not Found Headers=[ date=Sat, 03 Aug 2019 04:28:29 GMT content-type=application/json; charset=utf-8 content-length=2 connection=keep-alive set-cookie=__cfduid=de19ed0b495b5b58e74fa0ee31a700d651564806509; expires=Sun, 02-Aug-20 04:28:29 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 pragma=no-cache expires=Sat, 03 Aug 2019 08:28:29 GMT x-content-type-options=nosniff etag=W/"2-vyGp6PvFo4RvsFtPoIWeCReyIC8" via=1.1 vegur cf-cache-status=HIT age=96 server=cloudflare cf-ray=50058b8add0a92fe-SJC ] } attributesMediaType=*/* } ``` `errorMessage`​ 要素は、コネクタまたはコンポーネントがエラーとして解釈したメッセージを公開した時点で使用可能になります。たとえば、HTTP 要求で Mule がエラーとして扱うことを示す状況コードが受信された場合、プロセスは失敗し、また、​`errorMessage`​ にエラーに関する情報が入力されます。その後、ペイロードには ​`#[error.errorMessage.payload]`​ を、メタデータには ​`#[error.errorMessage.attributes]`​ を使用して、エラーメッセージ属性 (メタデータ) およびペイロード自体にアクセスできるようになります。HTTP 要求でエラーが返される場合は、​`#[error.errorMessage.attributes.statusCode]`​ を使用して状況コードの値 (​`404`​ など) を選択できます。Studio でメッセージ属性を確認するには、​[「DataSense」](https://docs.mulesoft.com/studio/datasense-concept)​を参照してください。 - `#[error.childErrors]`​ が返す内容: `[]` ## [](#error_types)Mule エラー種別 Mule エラーには名前空間 (​`HTTP:`​ や ​`FILE:`​ など) と識別子 (​`NOT_FOUND`​ など) があり、エラー種別の階層に属します。 命名規則により、ドメインに従ってエラーを区別できます。たとえば、​`NOT_FOUND`​ をスローする代わりに、HTTP Connector は ​`HTTP:NOT_FOUND`​ をスローし、File Connector は ​`FILE:NOT_FOUND`​ エラーをスローする場合があります。 コネクタとは異なり、Mule Runtime エラーには暗黙の ​`MULE`​ 名前空間があるため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同じように解釈されます。 エラー種別には親種別がある場合があります。たとえば、​`HTTP:UNAUTHORIZED`​ の親は ​`MULE:CLIENT_SECURITY`​、​`MULE:CLIENT_SECURITY`​ の親は ​`MULE:SECURITY`​ です。この階層は、よりグローバルなエラー種別が各エラー種別に特定化されていることを示しています。 たとえば、​`HTTP:UNAUTHORIZED`​ エラー種別はクライアントセキュリティエラー (​`MULE:CLIENT_SECURITY`​) の種別の 1 つですが、クライアントセキュリティエラーはより広範なセキュリティ上の問題 (​`MULE:SECURITY`​) の種別の 1 つです。 階層により、一般的な方法、またはより特定の方法でエラーをルーティングできます。たとえば、​`MULE:SECURITY`​ のエラーハンドラーは ​`HTTP:UNAUTHORIZED`​ エラーおよび OAuth エラーをキャッチします。次の図は、コアランタイム階層を示しています。 ![エラー階層](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-hierarchy.png) すべてのエラーは ​`ANY`​ または ​`CRITICAL`​ の 2 つの主な種別に属します。​`ANY`​ の各種別はその親によって照合され、処理できるのに対して、​`CRITICAL`​ のエラー種別はきわめて厳密であるため、処理できず、ログ記録されるのみです。 `CRITICAL`​ エラーには ​`FATAL_JVM_ERROR`​ と ​`OVERLOAD`​ が含まれます。 失敗の明確な理由がない場合、コンポーネントは ​`UNKNOWN`​ 種別を使用できます。このエラーは ​`ANY`​ 種別を介して処理し、アプリケーションの既存の動作を変更せずに、不明確なエラーを定義します。 コネクタの場合、各コネクタがコアランタイム階層を考慮してそのエラー種別階層を定義しますが、​`CONNECTIVITY`​ および ​`RETRY_EXHAUSTED`​ 種別はすべてのコネクタに共通であるため、常に存在します。 エラー種別: - `ANY`​: フローで発生し、処理できるすべてのエラー種別に一致するエラー種別。この種別には、提供元で発生するエラーは含まれません。 - `TRANSFORMATION`​: 値の変換中にエラーが発生したことを示す。これには、Mule Runtime 内部変換が含まれ、DataWeave 変換は含まれません。 - `EXPRESSION`​: DataWeave 式の評価中にエラーが発生したことを示す。 - `VALIDATION`​: 検証エラーが発生したことを示す。 - `DUPLICATE_MESSAGE`​: 2 回処理されたメッセージに関する検証エラーを示す。たとえば、​[冪等性のあるメッセージバリデーター](https://docs.mulesoft.com/jp/mule-runtime/4.5/idempotent-message-validator)​の使用などです。 - `REDELIVERY_EXHAUSTED`​: ソースからのメッセージの再処理の最大試行回数に達したことを示す。 - `CONNECTIVITY`​: 接続の確立で問題が発生したことを示す。これは、たとえば HTTP リクエスターなど、コネクタの使用中に発生する可能性があります。 - `RETRY_EXHAUSTED`​: 特定の実行ブロックの再試行回数がなくなったことを示す。たとえば、特定の操作や、​[Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/until-successful-scope)​の使用などです。 - `ROUTING`​: メッセージのルーティング中にエラーが発生したことを示す。たとえば、​[Round Robin ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.5/round-robin)​の使用などです。 - `COMPOSITE_ROUTING`​: メッセージのルーティング中に 1 つ以上のエラーが発生したことを示す。たとえば、​[Scatter Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.5/scatter-gather-concept)​の使用などです。 - `SECURITY`​: 無効なログイン情報の受信や期限切れのトークンの使用など、セキュリティエラーが発生したことを示す。 - `CLIENT_SECURITY`​: 外部エンティティ (たとえば、外部エンドポイントのコール) によってセキュリティエラーが発生したことを示す。 - `SERVER_SECURITY`​: Mule Runtime によってセキュリティエラーが適用されたことを示す。 - `NOT_PERMITTED`​: 検索条件によってセキュリティ制限が適用されたことを示す。たとえば、​[Mule Spring Module の承認検索条件](https://docs.mulesoft.com/spring-module/latest/#_to_validate_authentication_using_the_spring_authorization_filter)​の使用などです。 - `STREAM_MAXIMUM_SIZE_EXCEEDED`​: ストリームに許可された最大サイズを超えたことを示す。詳細については、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.5/streaming-about)​を参照してください。 - `TIMEOUT`​: メッセージの処理中にタイムアウトが発生したことを示す。 - `UNKNOWN`​: 不明なエラーまたは予期しないエラーが発生したことを示す。このエラーは、将来のランタイムバージョンでエラー種別が追加された場合に備えて後方互換性を確保するため、直接処理することはできず、​`ANY`​ を処理することで処理するしかありません。 - `SOURCE`​: フローの取得元でエラーが発生したことを示す。このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_GENERATE`​: エラー応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_SEND`​: エラー応答の送信中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_RESPONSE`​: 成功した応答の処理中にフローの取得元でエラーが発生したことを示す。取得元がすでに成功したパスを実行しているため、このエラーは伝播のみできます。このエラーは処理できません。 - `SOURCE_RESPONSE_GENERATE`​: 成功した応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。 - `SOURCE_RESPONSE_SEND`​: 成功した応答の送信中にフローの取得元でエラーが発生したことを示す。 - `CRITICAL`​: 重大なエラーが発生したことを示す。このエラーは処理できません。 - `OVERLOAD`​: オーバーロードの問題が発生し、実行が拒否されたことを示す。 - `FLOW_BACK_PRESSURE`​: ソースレベルでオーバーロードの問題が発生したことを示す。たとえば、ソースとしての HTTP リスナーの使用などです。 - `FATAL_JVM_ERROR`​: スタックのオーバーフローなど、重大なエラーが発生したことを示す。 ## [](#カスタムエラー種別)カスタムエラー種別 カスタムエラー種別を使用するには、マッピングするときまたはエラーが​[発生した](https://docs.mulesoft.com/jp/mule-runtime/4.5/raise-error-component-reference)​ときに定義する必要があります。このエラーは、アプリケーション内の既存の種別と区別するために特定のカスタム名前空間が必要です。つまり、HTTP および Database Connector 操作を使用するアプリケーションでは、カスタムエラー種別に HTTP および DB 名前空間を使用できません。 特定の Mule アプリケーション名またはコンテキストに関連した名前空間を定義し、既存のコネクタ名前空間の使用を避ける必要があります。たとえば、顧客集約 API は ​`CUSTOMER`​ 名前空間をそのカスタムエラー種別に使用でき、受注処理 API は ​`ORDER`​ 名前空間を使用できます。 ## [](#エラーのマッピング)エラーのマッピング フローの各操作で、可能性のあるエラー種別を選択したカスタムエラー種別にマップできます。これらのカスタムエラー種別を使用して、フローのどこでエラーが発生したかを識別できます。 たとえば、フローに異なる REST サービスにアクセスする 2 つの HTTP Request 操作がある場合、一方での接続失敗によって同じエラーが発生します。各エラーを異なるカスタムエラー種別にマッピングすることで、各操作失敗のエラー処理を識別でき、Mule アプリケーションログでエラーの発生元をすばやく識別できます。 次の例では、マッピングによって 2 つのカスタムエラー種別 ​`APP:CUSTOMER_API`​ および ​`APP:ORDER_API`​ を定義することで、きめ細かいエラー処理が可能になることがわかります。 マッピングの XML 設定の例 ```xml ``` ## [](#関連情報)関連情報 - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/on-error-scope-concept) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.5/logging-and-debugging) # Mule エラー Mule の実行に失敗すると、エラーが発生します。Mule アプリケーションの実行中、Mule Runtime Engine と、アプリケーションで設定されたモジュールおよびコネクタの操作の両方でエラーがスローされる可能性があります。エラーは Mule エラーオブジェクトで表され、Mule イベントに関連付けられています。On-Error コンポーネントを使用してエラーオブジェクトを処理し、それらに関する情報をログで確認できます。 Mule エラーは、階層順に従い、エラーの発生源を識別して選択したレベルでエラーを処理するのに役立つ命名規則を使用する​[エラー種別](#error_types)​にグループ化されます。これらのエラーをマッピングするカスタムエラー種別を作成することもできます。マッピングは、アプリケーションで処理する必要があるエラーをさらに識別してグループ化するのに役立つ場合があります。 エラー処理設定で Mule エラーの値を調べて使用するために、​[セレクター式](#selector_expressions)​を使用することもできます。 Mule エラーには式 (​`EXPRESSION`​) とストリームに関連したエラー (​`STREAM_MAXIMUM_SIZE_EXCEEDED`​) が含まれる一方で、操作によって多数の異なる種別のエラーがスローされる可能性があります。例として、​`HTTP:NOT_FOUND`​ (404 エラー) および HTTP Connector の HTTP リスナーからの ​`HTTP:CONNECTIVITY`​ エラーなどがあります。 `DB:BAD_SYNTAX`​ と ​`DB:QUERY_EXPRESSION`​ は、Database Connector の Select 操作でスローされる可能性があるエラーです。 モジュールおよびコネクタ (たとえば、​[HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/)​ や ​[Database Connector](https://docs.mulesoft.com/db-connector/latest/database-documentation)​ のリファレンス) では、Mule エラーをリストしています。 ## [](#selector_expressions)Mule エラーのセレクター式 Mule エラーは説明や種別など、複数の項目が含まれる複合データ型です。Mule エラーを記録して処理する場合、任意の数のエラー項目から値を選択できます。
項目 説明 セレクター式

説明

問題の説明。

#[error.description]​

Detailed Description (詳細な説明)

問題の説明。説明と同じ場合もあれば、説明よりも広範な内容の場合もあります。

#[error.detailedDescription]​

型

問題の特徴を記述し、エラーハンドラー内のルーティングを可能にするために使用される種別。

#[error.errorType]​

Cause

失敗の原因となった基になる Java ​Throwable​。

#[error.cause]​

Message (メッセージ)

問題に関する省略可能な Mule メッセージ。

#[error.errorMessage]​

Child Errors

Scatter-Gather などの要素が集約されたルートエラーを提供するために使用する内部エラーの省略可能なコレクション。

#[error.childErrors]
多くの場合、​error.cause​ セレクターは、Mule API に含まれる ​Throwable​ インスタンスを返します。このエラーの内部構造にアクセスしてエラー処理ロジックを定義しないでください。エラーを処理するためのすべての必要な情報は他のエラーセレクターによって公開されます。また、​error.cause​ をシリアル化すると、冗長な情報が生成される可能性があります。
### [](#http-request-error)HTTP 要求エラーの例 たとえば、HTTP 要求に失敗して ​`HTTP:NOT_FOUND`​ エラー (404 状況コードの場合) が表示された場合、エラーメッセージの各部の値は次のようになります。 - `#[error.description]`​ が返す内容: ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404). ``` - `#[error.detailedDescription]`​ は ​`HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404).`​ を返します。 - `#[error.errorType]`​ は ​`HTTP:NOT_FOUND`​ を返します。 - `#[error.cause]`​ は ​`org.mule.extension.http.api.request.validator.ResponseValidatorTypedException`​ を返します。​`ResponseValidatorTypedException`​ の戻りインスタンスを出力する場合、Mule は ​`toString`​ の結果を出力します。エラーに関連付けられた既知の HTTP 状況コード (404 など) がある場合、​`ResponseValidatorTypedException`​ インスタンスの文字列表現は人間が読み取り可能なエラーの説明になります。 - `#[error.errorMessage]`​ が返す内容: ```txt org.mule.runtime.core.internal.message.DefaultMessageBuilder$MessageImplementation { payload=org.mule.runtime.core.internal.streaming.bytes.ManagedCursorStreamProvider@223d8f75 mediaType=application/json; charset=UTF-8 attributes=org.mule.extension.http.api.HttpResponseAttributes { Status Code=404 Reason Phrase=Not Found Headers=[ date=Sat, 03 Aug 2019 04:28:29 GMT content-type=application/json; charset=utf-8 content-length=2 connection=keep-alive set-cookie=__cfduid=de19ed0b495b5b58e74fa0ee31a700d651564806509; expires=Sun, 02-Aug-20 04:28:29 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 pragma=no-cache expires=Sat, 03 Aug 2019 08:28:29 GMT x-content-type-options=nosniff etag=W/"2-vyGp6PvFo4RvsFtPoIWeCReyIC8" via=1.1 vegur cf-cache-status=HIT age=96 server=cloudflare cf-ray=50058b8add0a92fe-SJC ] } attributesMediaType=*/* } ``` `errorMessage`​ 要素は、コネクタまたはコンポーネントがエラーとして解釈したメッセージを公開した時点で使用可能になります。たとえば、HTTP 要求で Mule がエラーとして扱うことを示す状況コードが受信された場合、プロセスは失敗し、また、​`errorMessage`​ にエラーに関する情報が入力されます。その後、ペイロードには ​`#[error.errorMessage.payload]`​ を、メタデータには ​`#[error.errorMessage.attributes]`​ を使用して、エラーメッセージ属性 (メタデータ) およびペイロード自体にアクセスできるようになります。HTTP 要求でエラーが返される場合は、​`#[error.errorMessage.attributes.statusCode]`​ を使用して状況コードの値 (​`404`​ など) を選択できます。Studio でメッセージ属性を確認するには、​[「DataSense」](https://docs.mulesoft.com/studio/datasense-concept)​を参照してください。 - `#[error.childErrors]`​ が返す内容: `[]` ## [](#error_types)Mule エラー種別 Mule エラーには名前空間 (​`HTTP:`​ や ​`FILE:`​ など) と識別子 (​`NOT_FOUND`​ など) があり、エラー種別の階層に属します。 命名規則により、ドメインに従ってエラーを区別できます。たとえば、​`NOT_FOUND`​ をスローする代わりに、HTTP Connector は ​`HTTP:NOT_FOUND`​ をスローし、File Connector は ​`FILE:NOT_FOUND`​ エラーをスローする場合があります。 コネクタとは異なり、Mule ランタイムエラーには暗黙の ​`MULE`​ 名前空間があるため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同じように解釈されます。 エラー種別には親種別がある場合があります。たとえば、​`HTTP:UNAUTHORIZED`​ の親は ​`MULE:CLIENT_SECURITY`​、​`MULE:CLIENT_SECURITY`​ の親は ​`MULE:SECURITY`​ です。この階層は、よりグローバルなエラー種別が各エラー種別に特定化されていることを示しています。 たとえば、​`HTTP:UNAUTHORIZED`​ エラー種別はクライアントセキュリティエラー (​`MULE:CLIENT_SECURITY`​) の種別の 1 つですが、クライアントセキュリティエラーはより広範なセキュリティ上の問題 (​`MULE:SECURITY`​) の種別の 1 つです。 階層により、一般的な方法、またはより特定の方法でエラーをルーティングできます。たとえば、​`MULE:SECURITY`​ のエラーハンドラーは ​`HTTP:UNAUTHORIZED`​ エラーおよび OAuth エラーをキャッチします。次の図は、コアランタイム階層を示しています。 ![エラー階層](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-hierarchy.png) すべてのエラーは ​`ANY`​ または ​`CRITICAL`​ の 2 つの主な種別に属します。​`ANY`​ の各種別はその親によって照合され、処理できるのに対して、​`CRITICAL`​ のエラー種別はきわめて厳密であるため、処理できず、ログ記録されるのみです。 `CRITICAL`​ エラーには ​`FATAL_JVM_ERROR`​ と ​`OVERLOAD`​ が含まれます。 失敗の明確な理由がない場合、コンポーネントは ​`UNKNOWN`​ 種別を使用できます。このエラーは ​`ANY`​ 種別を介して処理し、アプリケーションの既存の動作を変更せずに、不明確なエラーを定義します。 コネクタの場合、各コネクタがコアランタイム階層を考慮してそのエラー種別階層を定義しますが、​`CONNECTIVITY`​ および ​`RETRY_EXHAUSTED`​ 種別はすべてのコネクタに共通であるため、常に存在します。 エラー種別: - `ANY`​: フローで発生し、処理できるすべてのエラー種別に一致するエラー種別。この種別には、提供元で発生するエラーは含まれません。 - `TRANSFORMATION`​: 値の変換中にエラーが発生したことを示す。これには、Mule Runtime 内部変換が含まれ、DataWeave 変換は含まれません。 - `EXPRESSION`​: DataWeave 式の評価中にエラーが発生したことを示す。 - `VALIDATION`​: 検証エラーが発生したことを示す。 - `DUPLICATE_MESSAGE`​: 2 回処理されたメッセージに関する検証エラーを示す。たとえば、​[冪等性のあるメッセージバリデーター](https://docs.mulesoft.com/jp/mule-runtime/4.6/idempotent-message-validator)​の使用などです。 - `REDELIVERY_EXHAUSTED`​: ソースからのメッセージの再処理の最大試行回数に達したことを示す。 - `CONNECTIVITY`​: 接続の確立で問題が発生したことを示す。これは、たとえば HTTP リクエスターなど、コネクタの使用中に発生する可能性があります。 - `RETRY_EXHAUSTED`​: 特定の実行ブロックの再試行回数がなくなったことを示す。たとえば、特定の操作や、​[Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/until-successful-scope)​の使用などです。 - `ROUTING`​: メッセージのルーティング中にエラーが発生したことを示す。たとえば、​[Round Robin ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.6/round-robin)​の使用などです。 - `COMPOSITE_ROUTING`​: メッセージのルーティング中に 1 つ以上のエラーが発生したことを示す。たとえば、​[Scatter Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.6/scatter-gather-concept)​の使用などです。 - `SECURITY`​: 無効なログイン情報の受信や期限切れのトークンの使用など、セキュリティエラーが発生したことを示す。 - `CLIENT_SECURITY`​: 外部エンティティ (たとえば、外部エンドポイントのコール) によってセキュリティエラーが発生したことを示す。 - `SERVER_SECURITY`​: Mule Runtime によってセキュリティエラーが適用されたことを示す。 - `NOT_PERMITTED`​: 検索条件によってセキュリティ制限が適用されたことを示す。たとえば、​[Mule Spring Module の認証検索条件](https://docs.mulesoft.com/spring-module/latest/#_to_validate_authentication_using_the_spring_authorization_filter)​の使用などです。 - `STREAM_MAXIMUM_SIZE_EXCEEDED`​: ストリームに許可された最大サイズを超えたことを示す。詳細については、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.6/streaming-about)​を参照してください。 - `TIMEOUT`​: メッセージの処理中にタイムアウトが発生したことを示す。 - `UNKNOWN`​: 不明なエラーまたは予期しないエラーが発生したことを示す。このエラーは、将来のランタイムバージョンでエラー種別が追加された場合に備えて後方互換性を確保するため、直接処理することはできず、​`ANY`​ を処理することで処理するしかありません。 - `SOURCE`​: フローの取得元でエラーが発生したことを示す。このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_GENERATE`​: エラー応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_SEND`​: エラー応答の送信中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_RESPONSE`​: 成功した応答の処理中にフローの取得元でエラーが発生したことを示す。取得元がすでに成功したパスを実行しているため、このエラーは伝播のみできます。このエラーは処理できません。 - `SOURCE_RESPONSE_GENERATE`​: 成功した応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。 - `SOURCE_RESPONSE_SEND`​: 成功した応答の送信中にフローの取得元でエラーが発生したことを示す。 - `CRITICAL`​: 重大なエラーが発生したことを示す。このエラーは処理できません。 - `OVERLOAD`​: オーバーロードの問題が発生し、実行が拒否されたことを示す。 - `FLOW_BACK_PRESSURE`​: ソースレベルでオーバーロードの問題が発生したことを示す。たとえば、ソースとしての HTTP リスナーの使用などです。 - `FATAL_JVM_ERROR`​: スタックのオーバーフローなど、重大なエラーが発生したことを示す。 ## [](#カスタムエラー種別)カスタムエラー種別 カスタムエラー種別を使用するには、マッピングするときまたはエラーが​[発生した](https://docs.mulesoft.com/jp/mule-runtime/4.6/raise-error-component-reference)​ときに定義する必要があります。このエラーは、アプリケーション内の既存の種別と区別するために特定のカスタム名前空間が必要です。つまり、HTTP および Database Connector 操作を使用するアプリケーションでは、カスタムエラー種別に HTTP および DB 名前空間を使用できません。 特定の Mule アプリケーション名またはコンテキストに関連した名前空間を定義し、既存のコネクタ名前空間の使用を避ける必要があります。たとえば、顧客集約 API は ​`CUSTOMER`​ 名前空間をそのカスタムエラー種別に使用でき、受注処理 API は ​`ORDER`​ 名前空間を使用できます。 ## [](#エラーのマッピング)エラーのマッピング フローの各操作で、可能性のあるエラー種別を選択したカスタムエラー種別にマップできます。これらのカスタムエラー種別を使用して、フローのどこでエラーが発生したかを識別できます。 たとえば、フローに異なる REST サービスにアクセスする 2 つの HTTP Request 操作がある場合、一方での接続失敗によって同じエラーが発生します。各エラーを異なるカスタムエラー種別にマッピングすることで、各操作失敗のエラー処理を識別でき、Mule アプリケーションログでエラーの発生元をすばやく識別できます。 次の例では、マッピングによって 2 つのカスタムエラー種別 ​`APP:CUSTOMER_API`​ および ​`APP:ORDER_API`​ を定義することで、きめ細かいエラー処理が可能になることがわかります。 マッピングの XML 設定の例 ```xml ``` ## [](#関連情報)関連情報 - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/on-error-scope-concept) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.6/logging-and-debugging) # Mule エラー Mule の実行に失敗すると、エラーが発生します。Mule アプリケーションの実行中、Mule Runtime Engine と、アプリケーションで設定されたモジュールおよびコネクタの操作の両方でエラーがスローされる可能性があります。エラーは Mule エラーオブジェクトで表され、Mule イベントに関連付けられています。On-Error コンポーネントを使用してエラーオブジェクトを処理し、それらに関する情報をログで確認できます。 Mule エラーは、階層順に従い、エラーの発生源を識別して選択したレベルでエラーを処理するのに役立つ命名規則を使用する​[エラー種別](#error_types)​にグループ化されます。これらのエラーをマッピングするカスタムエラー種別を作成することもできます。マッピングは、アプリケーションで処理する必要があるエラーをさらに識別してグループ化するのに役立つ場合があります。 エラー処理設定で Mule エラーの値を調べて使用するために、​[セレクター式](#selector_expressions)​を使用することもできます。 Mule エラーには式 (​`EXPRESSION`​) とストリームに関連したエラー (​`STREAM_MAXIMUM_SIZE_EXCEEDED`​) が含まれる一方で、操作によって多数の異なる種別のエラーがスローされる可能性があります。例として、​`HTTP:NOT_FOUND`​ (404 エラー) および HTTP Connector の HTTP リスナーからの ​`HTTP:CONNECTIVITY`​ エラーなどがあります。 `DB:BAD_SYNTAX`​ と ​`DB:QUERY_EXPRESSION`​ は、Database Connector の Select 操作でスローされる可能性があるエラーです。 モジュールおよびコネクタ (たとえば、​[HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/)​ や ​[Database Connector](https://docs.mulesoft.com/db-connector/latest/database-documentation)​ のリファレンス) では、Mule エラーをリストしています。 ## [](#selector_expressions)Mule エラーのセレクター式 Mule エラーは説明や種別など、複数の項目が含まれる複合データ型です。Mule エラーを記録して処理する場合、任意の数のエラー項目から値を選択できます。
項目 説明 セレクター式

説明

問題の説明。

#[error.description]​

Detailed Description (詳細な説明)

問題の説明。説明と同じ場合もあれば、説明よりも広範な内容の場合もあります。

#[error.detailedDescription]​

型

問題の特徴を記述し、エラーハンドラー内のルーティングを可能にするために使用される種別。

#[error.errorType]​

Cause

失敗の原因となった基になる Java ​Throwable​。

#[error.cause]​

Message (メッセージ)

問題に関する省略可能な Mule メッセージ。

#[error.errorMessage]​

Child Errors

Scatter-Gather などの要素が集約されたルートエラーを提供するために使用する内部エラーの省略可能なコレクション。

#[error.childErrors]
多くの場合、​error.cause​ セレクターは、Mule API に含まれる ​Throwable​ インスタンスを返します。このエラーの内部構造にアクセスしてエラー処理ロジックを定義しないでください。エラーを処理するためのすべての必要な情報は他のエラーセレクターによって公開されます。また、​error.cause​ をシリアル化すると、冗長な情報が生成される可能性があります。
### [](#http-request-error)HTTP 要求エラーの例 たとえば、HTTP 要求に失敗して ​`HTTP:NOT_FOUND`​ エラー (404 状況コードの場合) が表示された場合、エラーメッセージの各部の値は次のようになります。 - `#[error.description]`​ が返す内容: ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404). ``` - `#[error.detailedDescription]`​ は ​`HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404).`​ を返します。 - `#[error.errorType]`​ は ​`HTTP:NOT_FOUND`​ を返します。 - `#[error.cause]`​ は ​`org.mule.extension.http.api.request.validator.ResponseValidatorTypedException`​ を返します。​`ResponseValidatorTypedException`​ の戻りインスタンスを出力する場合、Mule は ​`toString`​ の結果を出力します。エラーに関連付けられた既知の HTTP 状況コード (404 など) がある場合、​`ResponseValidatorTypedException`​ インスタンスの文字列表現は人間が読み取り可能なエラーの説明になります。 - `#[error.errorMessage]`​ が返す内容: ```txt org.mule.runtime.core.internal.message.DefaultMessageBuilder$MessageImplementation { payload=org.mule.runtime.core.internal.streaming.bytes.ManagedCursorStreamProvider@223d8f75 mediaType=application/json; charset=UTF-8 attributes=org.mule.extension.http.api.HttpResponseAttributes { Status Code=404 Reason Phrase=Not Found Headers=[ date=Sat, 03 Aug 2019 04:28:29 GMT content-type=application/json; charset=utf-8 content-length=2 connection=keep-alive set-cookie=__cfduid=de19ed0b495b5b58e74fa0ee31a700d651564806509; expires=Sun, 02-Aug-20 04:28:29 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 pragma=no-cache expires=Sat, 03 Aug 2019 08:28:29 GMT x-content-type-options=nosniff etag=W/"2-vyGp6PvFo4RvsFtPoIWeCReyIC8" via=1.1 vegur cf-cache-status=HIT age=96 server=cloudflare cf-ray=50058b8add0a92fe-SJC ] } attributesMediaType=*/* } ``` `errorMessage`​ 要素は、コネクタまたはコンポーネントがエラーとして解釈したメッセージを公開した時点で使用可能になります。たとえば、HTTP 要求で Mule がエラーとして扱うことを示す状況コードが受信された場合、プロセスは失敗し、また、​`errorMessage`​ にエラーに関する情報が入力されます。その後、ペイロードには ​`#[error.errorMessage.payload]`​ を、メタデータには ​`#[error.errorMessage.attributes]`​ を使用して、エラーメッセージ属性 (メタデータ) およびペイロード自体にアクセスできるようになります。HTTP 要求でエラーが返される場合は、​`#[error.errorMessage.attributes.statusCode]`​ を使用して状況コードの値 (​`404`​ など) を選択できます。Studio でメッセージ属性を確認するには、​[「DataSense」](https://docs.mulesoft.com/studio/datasense-concept)​を参照してください。 - `#[error.childErrors]`​ が返す内容: `[]` ## [](#error_types)Mule エラー種別 Mule エラーには名前空間 (​`HTTP:`​ や ​`FILE:`​ など) と識別子 (​`NOT_FOUND`​ など) があり、エラー種別の階層に属します。 命名規則により、ドメインに従ってエラーを区別できます。たとえば、​`NOT_FOUND`​ をスローする代わりに、HTTP Connector は ​`HTTP:NOT_FOUND`​ をスローし、File Connector は ​`FILE:NOT_FOUND`​ エラーをスローする場合があります。 コネクタとは異なり、Mule Runtime エラーには暗黙の ​`MULE`​ 名前空間があるため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同じように解釈されます。 エラー種別には親種別がある場合があります。たとえば、​`HTTP:UNAUTHORIZED`​ の親は ​`MULE:CLIENT_SECURITY`​、​`MULE:CLIENT_SECURITY`​ の親は ​`MULE:SECURITY`​ です。この階層は、よりグローバルなエラー種別が各エラー種別に特定化されていることを示しています。 たとえば、​`HTTP:UNAUTHORIZED`​ エラー種別はクライアントセキュリティエラー (​`MULE:CLIENT_SECURITY`​) の種別の 1 つですが、クライアントセキュリティエラーはより広範なセキュリティ上の問題 (​`MULE:SECURITY`​) の種別の 1 つです。 階層により、一般的な方法、またはより特定の方法でエラーをルーティングできます。たとえば、​`MULE:SECURITY`​ のエラーハンドラーは ​`HTTP:UNAUTHORIZED`​ エラーおよび OAuth エラーをキャッチします。次の図は、コアランタイム階層を示しています。 ![ANY や CRITICAL などのカテゴリが表示されているエラー種別の階層](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-hierarchy.png) すべてのエラーは ​`ANY`​ または ​`CRITICAL`​ の 2 つの主な種別に属します。​`ANY`​ の各種別はその親によって照合され、処理できるのに対して、​`CRITICAL`​ のエラー種別はきわめて厳密であるため、処理できず、ログ記録されるのみです。 `CRITICAL`​ エラーには ​`FATAL_JVM_ERROR`​ と ​`OVERLOAD`​ が含まれます。 失敗の明確な理由がない場合、コンポーネントは ​`UNKNOWN`​ 種別を使用できます。このエラーは ​`ANY`​ 種別を介して処理し、アプリケーションの既存の動作を変更せずに、不明確なエラーを定義します。 コネクタの場合、各コネクタがコアランタイム階層を考慮してそのエラー種別階層を定義しますが、​`CONNECTIVITY`​ および ​`RETRY_EXHAUSTED`​ 種別はすべてのコネクタに共通であるため、常に存在します。 エラー種別: - `ANY`​: フローで発生し、処理できるすべてのエラー種別に一致するエラー種別。この種別には、提供元で発生するエラーは含まれません。 - `TRANSFORMATION`​: 値の変換中にエラーが発生したことを示す。これには、Mule Runtime 内部変換が含まれ、DataWeave 変換は含まれません。 - `EXPRESSION`​: DataWeave 式の評価中にエラーが発生したことを示す。 - `VALIDATION`​: 検証エラーが発生したことを示す。 - `DUPLICATE_MESSAGE`​: 2 回処理されたメッセージに関する検証エラーを示す。たとえば、​[冪等性のあるメッセージバリデーター](https://docs.mulesoft.com/jp/mule-runtime/4.7/idempotent-message-validator)​の使用などです。 - `REDELIVERY_EXHAUSTED`​: ソースからのメッセージの再処理の最大試行回数に達したことを示す。 - `CONNECTIVITY`​: 接続の確立で問題が発生したことを示す。これは、たとえば HTTP リクエスターなど、コネクタの使用中に発生する可能性があります。 - `RETRY_EXHAUSTED`​: 特定の実行ブロックの再試行回数がなくなったことを示す。たとえば、特定の操作や、​[Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/until-successful-scope)​の使用などです。 - `ROUTING`​: メッセージのルーティング中にエラーが発生したことを示す。たとえば、​[Round Robin ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.7/round-robin)​の使用などです。 - `COMPOSITE_ROUTING`​: メッセージのルーティング中に 1 つ以上のエラーが発生したことを示す。たとえば、​[Scatter Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.7/scatter-gather-concept)​の使用などです。 - `SECURITY`​: 無効なログイン情報の受信や期限切れのトークンの使用など、セキュリティエラーが発生したことを示す。 - `CLIENT_SECURITY`​: 外部エンティティ (たとえば、外部エンドポイントのコール) によってセキュリティエラーが発生したことを示す。 - `SERVER_SECURITY`​: Mule Runtime によってセキュリティエラーが適用されたことを示す。 - `NOT_PERMITTED`​: 検索条件によってセキュリティ制限が適用されたことを示す。たとえば、​[Mule Spring Module の認証検索条件](https://docs.mulesoft.com/spring-module/latest/#_to_validate_authentication_using_the_spring_authorization_filter)​の使用などです。 - `STREAM_MAXIMUM_SIZE_EXCEEDED`​: ストリームに許可された最大サイズを超えたことを示す。詳細については、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.7/streaming-about)​を参照してください。 - `TIMEOUT`​: メッセージの処理中にタイムアウトが発生したことを示す。 - `UNKNOWN`​: 不明なエラーまたは予期しないエラーが発生したことを示す。このエラーは、将来のランタイムバージョンでエラー種別が追加された場合に備えて後方互換性を確保するため、直接処理することはできず、​`ANY`​ を処理することで処理するしかありません。 - `SOURCE`​: フローの取得元でエラーが発生したことを示す。このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_GENERATE`​: エラー応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_SEND`​: エラー応答の送信中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_RESPONSE`​: 成功した応答の処理中にフローの取得元でエラーが発生したことを示す。取得元がすでに成功したパスを実行しているため、このエラーは伝播のみできます。このエラーは処理できません。 - `SOURCE_RESPONSE_GENERATE`​: 成功した応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。 - `SOURCE_RESPONSE_SEND`​: 成功した応答の送信中にフローの取得元でエラーが発生したことを示す。 - `CRITICAL`​: 重大なエラーが発生したことを示す。このエラーは処理できません。 - `OVERLOAD`​: オーバーロードの問題が発生し、実行が拒否されたことを示す。 - `FLOW_BACK_PRESSURE`​: ソースレベルでオーバーロードの問題が発生したことを示す。たとえば、ソースとしての HTTP リスナーの使用などです。 - `FATAL_JVM_ERROR`​: スタックのオーバーフローなど、重大なエラーが発生したことを示す。 ## [](#カスタムエラー種別)カスタムエラー種別 カスタムエラー種別を使用するには、マッピングするときまたはエラーが​[発生した](https://docs.mulesoft.com/jp/mule-runtime/4.7/raise-error-component-reference)​ときに定義する必要があります。このエラーは、アプリケーション内の既存の種別と区別するために特定のカスタム名前空間が必要です。つまり、HTTP および Database Connector 操作を使用するアプリケーションでは、カスタムエラー種別に HTTP および DB 名前空間を使用できません。 特定の Mule アプリケーション名またはコンテキストに関連した名前空間を定義し、既存のコネクタ名前空間の使用を避ける必要があります。たとえば、顧客集約 API は ​`CUSTOMER`​ 名前空間をそのカスタムエラー種別に使用でき、受注処理 API は ​`ORDER`​ 名前空間を使用できます。 ## [](#エラーのマッピング)エラーのマッピング フローの各操作で、可能性のあるエラー種別を選択したカスタムエラー種別にマップできます。これらのカスタムエラー種別を使用して、フローのどこでエラーが発生したかを識別できます。 たとえば、フローに異なる REST サービスにアクセスする 2 つの HTTP Request 操作がある場合、一方での接続失敗によって同じエラーが発生します。各エラーを異なるカスタムエラー種別にマッピングすることで、各操作失敗のエラー処理を識別でき、Mule アプリケーションログでエラーの発生元をすばやく識別できます。 次の例では、マッピングによって 2 つのカスタムエラー種別 ​`APP:CUSTOMER_API`​ および ​`APP:ORDER_API`​ を定義することで、きめ細かいエラー処理が可能になることがわかります。 マッピングの XML 設定の例 ```xml ``` ## [](#関連情報)関連情報 - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/on-error-scope-concept) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.7/logging-and-debugging) # Mule エラー Mule の実行に失敗すると、エラーが発生します。Mule アプリケーションの実行中、Mule Runtime Engine と、アプリケーションで設定されたモジュールおよびコネクタの操作の両方でエラーがスローされる可能性があります。エラーは Mule エラーオブジェクトで表され、Mule イベントに関連付けられています。On-Error コンポーネントを使用してエラーオブジェクトを処理し、それらに関する情報をログで確認できます。 Mule エラーは、階層順に従い、エラーの発生源を識別して選択したレベルでエラーを処理するのに役立つ命名規則を使用する​[エラー種別](#error_types)​にグループ化されます。これらのエラーをマッピングするカスタムエラー種別を作成することもできます。マッピングは、アプリケーションで処理する必要があるエラーをさらに識別してグループ化するのに役立つ場合があります。 エラー処理設定で Mule エラーの値を調べて使用するために、​[セレクター式](#selector_expressions)​を使用することもできます。 Mule エラーには式 (​`EXPRESSION`​) とストリームに関連したエラー (​`STREAM_MAXIMUM_SIZE_EXCEEDED`​) が含まれる一方で、操作によって多数の異なる種別のエラーがスローされる可能性があります。例として、​`HTTP:NOT_FOUND`​ (404 エラー) および HTTP Connector の HTTP リスナーからの ​`HTTP:CONNECTIVITY`​ エラーなどがあります。 `DB:BAD_SYNTAX`​ と ​`DB:QUERY_EXPRESSION`​ は、Database Connector の Select 操作でスローされる可能性があるエラーです。 モジュールおよびコネクタ (たとえば、​[HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/)​ や ​[Database Connector](https://docs.mulesoft.com/db-connector/latest/database-documentation)​ のリファレンス) では、Mule エラーをリストしています。 ## [](#selector_expressions)Mule エラーのセレクター式 Mule エラーは説明や種別など、複数の項目が含まれる複合データ型です。Mule エラーを記録して処理する場合、任意の数のエラー項目から値を選択できます。
項目 説明 セレクター式

説明

問題の説明。

#[error.description]​

Detailed Description (詳細な説明)

問題の説明。説明と同じ場合もあれば、説明よりも広範な内容の場合もあります。

#[error.detailedDescription]​

型

問題の特徴を記述し、エラーハンドラー内のルーティングを可能にするために使用される種別。

#[error.errorType]​

Cause

失敗の原因となった基になる Java ​Throwable​。

#[error.cause]​

Message (メッセージ)

問題に関する省略可能な Mule メッセージ。

#[error.errorMessage]​

Child Errors

Scatter-Gather などの要素が集約されたルートエラーを提供するために使用する内部エラーの省略可能なコレクション。

#[error.childErrors]
多くの場合、​error.cause​ セレクターは、Mule API に含まれる ​Throwable​ インスタンスを返します。このエラーの内部構造にアクセスしてエラー処理ロジックを定義しないでください。エラーを処理するためのすべての必要な情報は他のエラーセレクターによって公開されます。また、​error.cause​ をシリアル化すると、冗長な情報が生成される可能性があります。
### [](#http-request-error)HTTP 要求エラーの例 たとえば、HTTP 要求に失敗して ​`HTTP:NOT_FOUND`​ エラー (404 状況コードの場合) が表示された場合、エラーメッセージの各部の値は次のようになります。 - `#[error.description]`​ が返す内容: ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404). ``` - `#[error.detailedDescription]`​ は ​`HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404).`​ を返します。 - `#[error.errorType]`​ は ​`HTTP:NOT_FOUND`​ を返します。 - `#[error.cause]`​ は ​`org.mule.extension.http.api.request.validator.ResponseValidatorTypedException`​ を返します。​`ResponseValidatorTypedException`​ の戻りインスタンスを出力する場合、Mule は ​`toString`​ の結果を出力します。エラーに関連付けられた既知の HTTP 状況コード (404 など) がある場合、​`ResponseValidatorTypedException`​ インスタンスの文字列表現は人間が読み取り可能なエラーの説明になります。 - `#[error.errorMessage]`​ が返す内容: ```txt org.mule.runtime.core.internal.message.DefaultMessageBuilder$MessageImplementation { payload=org.mule.runtime.core.internal.streaming.bytes.ManagedCursorStreamProvider@223d8f75 mediaType=application/json; charset=UTF-8 attributes=org.mule.extension.http.api.HttpResponseAttributes { Status Code=404 Reason Phrase=Not Found Headers=[ date=Sat, 03 Aug 2019 04:28:29 GMT content-type=application/json; charset=utf-8 content-length=2 connection=keep-alive set-cookie=__cfduid=de19ed0b495b5b58e74fa0ee31a700d651564806509; expires=Sun, 02-Aug-20 04:28:29 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 pragma=no-cache expires=Sat, 03 Aug 2019 08:28:29 GMT x-content-type-options=nosniff etag=W/"2-vyGp6PvFo4RvsFtPoIWeCReyIC8" via=1.1 vegur cf-cache-status=HIT age=96 server=cloudflare cf-ray=50058b8add0a92fe-SJC ] } attributesMediaType=*/* } ``` `errorMessage`​ 要素は、コネクタまたはコンポーネントがエラーとして解釈したメッセージを公開した時点で使用可能になります。たとえば、HTTP 要求で Mule がエラーとして扱うことを示す状況コードが受信された場合、プロセスは失敗し、また、​`errorMessage`​ にエラーに関する情報が入力されます。その後、ペイロードには ​`#[error.errorMessage.payload]`​ を、メタデータには ​`#[error.errorMessage.attributes]`​ を使用して、エラーメッセージ属性 (メタデータ) およびペイロード自体にアクセスできるようになります。HTTP 要求でエラーが返される場合は、​`#[error.errorMessage.attributes.statusCode]`​ を使用して状況コードの値 (​`404`​ など) を選択できます。Studio でメッセージ属性を確認するには、​[「DataSense」](https://docs.mulesoft.com/studio/datasense-concept)​を参照してください。 - `#[error.childErrors]`​ が返す内容: `[]` ## [](#error_types)Mule エラー種別 Mule エラーには名前空間 (​`HTTP:`​ や ​`FILE:`​ など) と識別子 (​`NOT_FOUND`​ など) があり、エラー種別の階層に属します。 命名規則により、ドメインに従ってエラーを区別できます。たとえば、​`NOT_FOUND`​ をスローする代わりに、HTTP Connector は ​`HTTP:NOT_FOUND`​ をスローし、File Connector は ​`FILE:NOT_FOUND`​ エラーをスローする場合があります。 コネクタとは異なり、Mule Runtime エラーには暗黙の ​`MULE`​ 名前空間があるため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同じように解釈されます。 エラー種別には親種別がある場合があります。たとえば、​`HTTP:UNAUTHORIZED`​ の親は ​`MULE:CLIENT_SECURITY`​、​`MULE:CLIENT_SECURITY`​ の親は ​`MULE:SECURITY`​ です。この階層は、よりグローバルなエラー種別が各エラー種別に特定化されていることを示しています。 たとえば、​`HTTP:UNAUTHORIZED`​ エラー種別はクライアントセキュリティエラー (​`MULE:CLIENT_SECURITY`​) の種別の 1 つですが、クライアントセキュリティエラーはより広範なセキュリティ上の問題 (​`MULE:SECURITY`​) の種別の 1 つです。 階層により、一般的な方法、またはより特定の方法でエラーをルーティングできます。たとえば、​`MULE:SECURITY`​ のエラーハンドラーは ​`HTTP:UNAUTHORIZED`​ エラーおよび OAuth エラーをキャッチします。次の図は、コアランタイム階層を示しています。 ![ANY や CRITICAL などのカテゴリが表示されているエラー種別の階層](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-hierarchy.png) すべてのエラーは ​`ANY`​ または ​`CRITICAL`​ の 2 つの主な種別に属します。​`ANY`​ の各種別はその親によって照合され、処理できるのに対して、​`CRITICAL`​ のエラー種別はきわめて厳密であるため、処理できず、ログ記録されるのみです。 `CRITICAL`​ エラーには ​`FATAL_JVM_ERROR`​ と ​`OVERLOAD`​ が含まれます。 失敗の明確な理由がない場合、コンポーネントは ​`UNKNOWN`​ 種別を使用できます。このエラーは ​`ANY`​ 種別を介して処理し、アプリケーションの既存の動作を変更せずに、不明確なエラーを定義します。 コネクタの場合、各コネクタがコアランタイム階層を考慮してそのエラー種別階層を定義しますが、​`CONNECTIVITY`​ および ​`RETRY_EXHAUSTED`​ 種別はすべてのコネクタに共通であるため、常に存在します。 エラー種別: - `ANY`​: フローで発生し、処理できるすべてのエラー種別に一致するエラー種別。この種別には、提供元で発生するエラーは含まれません。 - `TRANSFORMATION`​: 値の変換中にエラーが発生したことを示す。これには、Mule Runtime 内部変換が含まれ、DataWeave 変換は含まれません。 - `EXPRESSION`​: DataWeave 式の評価中にエラーが発生したことを示す。 - `VALIDATION`​: 検証エラーが発生したことを示す。 - `DUPLICATE_MESSAGE`​: 2 回処理されたメッセージに関する検証エラーを示す。たとえば、​[冪等性のあるメッセージバリデーター](https://docs.mulesoft.com/jp/mule-runtime/4.8/idempotent-message-validator)​の使用などです。 - `REDELIVERY_EXHAUSTED`​: ソースからのメッセージの再処理の最大試行回数に達したことを示す。 - `CONNECTIVITY`​: 接続の確立で問題が発生したことを示す。これは、たとえば HTTP リクエスターなど、コネクタの使用中に発生する可能性があります。 - `RETRY_EXHAUSTED`​: 特定の実行ブロックの再試行回数がなくなったことを示す。たとえば、特定の操作や、​[Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/until-successful-scope)​の使用などです。 - `ROUTING`​: メッセージのルーティング中にエラーが発生したことを示す。たとえば、​[Round Robin ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.8/round-robin)​の使用などです。 - `COMPOSITE_ROUTING`​: メッセージのルーティング中に 1 つ以上のエラーが発生したことを示す。たとえば、​[Scatter Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.8/scatter-gather-concept)​の使用などです。 - `SECURITY`​: 無効なログイン情報の受信や期限切れのトークンの使用など、セキュリティエラーが発生したことを示す。 - `CLIENT_SECURITY`​: 外部エンティティ (たとえば、外部エンドポイントのコール) によってセキュリティエラーが発生したことを示す。 - `SERVER_SECURITY`​: Mule Runtime によってセキュリティエラーが適用されたことを示す。 - `NOT_PERMITTED`​: 検索条件によってセキュリティ制限が適用されたことを示す。たとえば、​[Mule Spring Module の認証検索条件](https://docs.mulesoft.com/spring-module/latest/#_to_validate_authentication_using_the_spring_authorization_filter)​の使用などです。 - `STREAM_MAXIMUM_SIZE_EXCEEDED`​: ストリームに許可された最大サイズを超えたことを示す。詳細については、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.8/streaming-about)​を参照してください。 - `TIMEOUT`​: メッセージの処理中にタイムアウトが発生したことを示す。 - `UNKNOWN`​: 不明なエラーまたは予期しないエラーが発生したことを示す。このエラーは、将来のランタイムバージョンでエラー種別が追加された場合に備えて後方互換性を確保するため、直接処理することはできず、​`ANY`​ を処理することで処理するしかありません。 - `SOURCE`​: フローの取得元でエラーが発生したことを示す。このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_GENERATE`​: エラー応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_SEND`​: エラー応答の送信中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_RESPONSE`​: 成功した応答の処理中にフローの取得元でエラーが発生したことを示す。取得元がすでに成功したパスを実行しているため、このエラーは伝播のみできます。このエラーは処理できません。 - `SOURCE_RESPONSE_GENERATE`​: 成功した応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。 - `SOURCE_RESPONSE_SEND`​: 成功した応答の送信中にフローの取得元でエラーが発生したことを示す。 - `CRITICAL`​: 重大なエラーが発生したことを示す。このエラーは処理できません。 - `OVERLOAD`​: オーバーロードの問題が発生し、実行が拒否されたことを示す。 - `FLOW_BACK_PRESSURE`​: ソースレベルでオーバーロードの問題が発生したことを示す。たとえば、ソースとしての HTTP リスナーの使用などです。 - `FATAL_JVM_ERROR`​: スタックのオーバーフローなど、重大なエラーが発生したことを示す。 ## [](#カスタムエラー種別)カスタムエラー種別 カスタムエラー種別を使用するには、マッピングするときまたはエラーが​[発生した](https://docs.mulesoft.com/jp/mule-runtime/4.8/raise-error-component-reference)​ときに定義する必要があります。このエラーは、アプリケーション内の既存の種別と区別するために特定のカスタム名前空間が必要です。つまり、HTTP および Database Connector 操作を使用するアプリケーションでは、カスタムエラー種別に HTTP および DB 名前空間を使用できません。 特定の Mule アプリケーション名またはコンテキストに関連した名前空間を定義し、既存のコネクタ名前空間の使用を避ける必要があります。たとえば、顧客集約 API は ​`CUSTOMER`​ 名前空間をそのカスタムエラー種別に使用でき、受注処理 API は ​`ORDER`​ 名前空間を使用できます。 ## [](#エラーのマッピング)エラーのマッピング フローの各操作で、可能性のあるエラー種別を選択したカスタムエラー種別にマップできます。これらのカスタムエラー種別を使用して、フローのどこでエラーが発生したかを識別できます。 たとえば、フローに異なる REST サービスにアクセスする 2 つの HTTP Request 操作がある場合、一方での接続失敗によって同じエラーが発生します。各エラーを異なるカスタムエラー種別にマッピングすることで、各操作失敗のエラー処理を識別でき、Mule アプリケーションログでエラーの発生元をすばやく識別できます。 次の例では、マッピングによって 2 つのカスタムエラー種別 ​`APP:CUSTOMER_API`​ および ​`APP:ORDER_API`​ を定義することで、きめ細かいエラー処理が可能になることがわかります。 マッピングの XML 設定の例 ```xml ``` ## [](#関連情報)関連情報 - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/on-error-scope-concept) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.8/logging-and-debugging) # Mule エラー Mule の実行に失敗すると、エラーが発生します。Mule アプリケーションの実行中、Mule Runtime Engine と、アプリケーションで設定されたモジュールおよびコネクタの操作の両方でエラーがスローされる可能性があります。エラーは Mule エラーオブジェクトで表され、Mule イベントに関連付けられています。On-Error コンポーネントを使用してエラーオブジェクトを処理し、それらに関する情報をログで確認できます。 Mule エラーは、階層順に従い、エラーの発生源を識別して選択したレベルでエラーを処理するのに役立つ命名規則を使用する​[エラー種別](#error_types)​にグループ化されます。これらのエラーをマッピングするカスタムエラー種別を作成することもできます。マッピングは、アプリケーションで処理する必要があるエラーをさらに識別してグループ化するのに役立つ場合があります。 エラー処理設定で Mule エラーの値を調べて使用するために、​[セレクター式](#selector_expressions)​を使用することもできます。 Mule エラーには式 (​`EXPRESSION`​) とストリームに関連したエラー (​`STREAM_MAXIMUM_SIZE_EXCEEDED`​) が含まれる一方で、操作によって多数の異なる種別のエラーがスローされる可能性があります。例として、​`HTTP:NOT_FOUND`​ (404 エラー) および HTTP Connector の HTTP リスナーからの ​`HTTP:CONNECTIVITY`​ エラーなどがあります。 `DB:BAD_SYNTAX`​ と ​`DB:QUERY_EXPRESSION`​ は、Database Connector の Select 操作でスローされる可能性があるエラーです。 モジュールおよびコネクタ (たとえば、​[HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/)​ や ​[Database Connector](https://docs.mulesoft.com/db-connector/latest/database-documentation)​ のリファレンス) では、Mule エラーをリストしています。 ## [](#selector_expressions)Mule エラーのセレクター式 Mule エラーは説明や種別など、複数の項目が含まれる複合データ型です。Mule エラーを記録して処理する場合、任意の数のエラー項目から値を選択できます。
項目 説明 セレクター式

説明

問題の説明。

#[error.description]​

Detailed Description (詳細な説明)

問題の説明。説明と同じ場合もあれば、説明よりも広範な内容の場合もあります。

#[error.detailedDescription]​

型

問題の特徴を記述し、エラーハンドラー内のルーティングを可能にするために使用される種別。

#[error.errorType]​

Cause

失敗の原因となった基になる Java ​Throwable​。

#[error.cause]​

Message (メッセージ)

問題に関する省略可能な Mule メッセージ。

#[error.errorMessage]​

Child Errors

Scatter-Gather などの要素が集約されたルートエラーを提供するために使用する内部エラーの省略可能なコレクション。

#[error.childErrors]
多くの場合、​error.cause​ セレクターは、Mule API に含まれる ​Throwable​ インスタンスを返します。このエラーの内部構造にアクセスしてエラー処理ロジックを定義しないでください。エラーを処理するためのすべての必要な情報は他のエラーセレクターによって公開されます。また、​error.cause​ をシリアル化すると、冗長な情報が生成される可能性があります。
### [](#http-request-error)HTTP 要求エラーの例 たとえば、HTTP 要求に失敗して ​`HTTP:NOT_FOUND`​ エラー (404 状況コードの場合) が表示された場合、エラーメッセージの各部の値は次のようになります。 - `#[error.description]`​ が返す内容: ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404). ``` - `#[error.detailedDescription]`​ は ​`HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/mybadrequest' failed: not found (404).`​ を返します。 - `#[error.errorType]`​ は ​`HTTP:NOT_FOUND`​ を返します。 - `#[error.cause]`​ は ​`org.mule.extension.http.api.request.validator.ResponseValidatorTypedException`​ を返します。​`ResponseValidatorTypedException`​ の戻りインスタンスを出力する場合、Mule は ​`toString`​ の結果を出力します。エラーに関連付けられた既知の HTTP 状況コード (404 など) がある場合、​`ResponseValidatorTypedException`​ インスタンスの文字列表現は人間が読み取り可能なエラーの説明になります。 - `#[error.errorMessage]`​ が返す内容: ```txt org.mule.runtime.core.internal.message.DefaultMessageBuilder$MessageImplementation { payload=org.mule.runtime.core.internal.streaming.bytes.ManagedCursorStreamProvider@223d8f75 mediaType=application/json; charset=UTF-8 attributes=org.mule.extension.http.api.HttpResponseAttributes { Status Code=404 Reason Phrase=Not Found Headers=[ date=Sat, 03 Aug 2019 04:28:29 GMT content-type=application/json; charset=utf-8 content-length=2 connection=keep-alive set-cookie=__cfduid=de19ed0b495b5b58e74fa0ee31a700d651564806509; expires=Sun, 02-Aug-20 04:28:29 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 pragma=no-cache expires=Sat, 03 Aug 2019 08:28:29 GMT x-content-type-options=nosniff etag=W/"2-vyGp6PvFo4RvsFtPoIWeCReyIC8" via=1.1 vegur cf-cache-status=HIT age=96 server=cloudflare cf-ray=50058b8add0a92fe-SJC ] } attributesMediaType=*/* } ``` `errorMessage`​ 要素は、コネクタまたはコンポーネントがエラーとして解釈したメッセージを公開した時点で使用可能になります。たとえば、HTTP 要求で Mule がエラーとして扱うことを示す状況コードが受信された場合、プロセスは失敗し、また、​`errorMessage`​ にエラーに関する情報が入力されます。その後、ペイロードには ​`#[error.errorMessage.payload]`​ を、メタデータには ​`#[error.errorMessage.attributes]`​ を使用して、エラーメッセージ属性 (メタデータ) およびペイロード自体にアクセスできるようになります。HTTP 要求でエラーが返される場合は、​`#[error.errorMessage.attributes.statusCode]`​ を使用して状況コードの値 (​`404`​ など) を選択できます。Studio でメッセージ属性を確認するには、​[「DataSense」](https://docs.mulesoft.com/studio/datasense-concept)​を参照してください。 - `#[error.childErrors]`​ が返す内容: `[]` ## [](#error_types)Mule エラー種別 Mule エラーには名前空間 (​`HTTP:`​ や ​`FILE:`​ など) と識別子 (​`NOT_FOUND`​ など) があり、エラー種別の階層に属します。 命名規則により、ドメインに従ってエラーを区別できます。たとえば、​`NOT_FOUND`​ をスローする代わりに、HTTP Connector は ​`HTTP:NOT_FOUND`​ をスローし、File Connector は ​`FILE:NOT_FOUND`​ エラーをスローする場合があります。 コネクタとは異なり、Mule Runtime エラーには暗黙の ​`MULE`​ 名前空間があるため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同じように解釈されます。 エラー種別には親種別がある場合があります。たとえば、​`HTTP:UNAUTHORIZED`​ の親は ​`MULE:CLIENT_SECURITY`​、​`MULE:CLIENT_SECURITY`​ の親は ​`MULE:SECURITY`​ です。この階層は、よりグローバルなエラー種別が各エラー種別に特定化されていることを示しています。 たとえば、​`HTTP:UNAUTHORIZED`​ エラー種別はクライアントセキュリティエラー (​`MULE:CLIENT_SECURITY`​) の種別の 1 つですが、クライアントセキュリティエラーはより広範なセキュリティ上の問題 (​`MULE:SECURITY`​) の種別の 1 つです。 階層により、一般的な方法、またはより特定の方法でエラーをルーティングできます。たとえば、​`MULE:SECURITY`​ のエラーハンドラーは ​`HTTP:UNAUTHORIZED`​ エラーおよび OAuth エラーをキャッチします。次の図は、コアランタイム階層を示しています。 ![ANY や CRITICAL などのカテゴリが表示されているエラー種別の階層](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-hierarchy.png) すべてのエラーは ​`ANY`​ または ​`CRITICAL`​ の 2 つの主な種別に属します。​`ANY`​ の各種別はその親によって照合され、処理できるのに対して、​`CRITICAL`​ のエラー種別はきわめて厳密であるため、処理できず、ログ記録されるのみです。 `CRITICAL`​ エラーには ​`FATAL_JVM_ERROR`​ と ​`OVERLOAD`​ が含まれます。 失敗の明確な理由がない場合、コンポーネントは ​`UNKNOWN`​ 種別を使用できます。このエラーは ​`ANY`​ 種別を介して処理し、アプリケーションの既存の動作を変更せずに、不明確なエラーを定義します。 コネクタの場合、各コネクタがコアランタイム階層を考慮してそのエラー種別階層を定義しますが、​`CONNECTIVITY`​ および ​`RETRY_EXHAUSTED`​ 種別はすべてのコネクタに共通であるため、常に存在します。 エラー種別: - `ANY`​: フローで発生し、処理できるすべてのエラー種別に一致するエラー種別。この種別には、提供元で発生するエラーは含まれません。 - `TRANSFORMATION`​: 値の変換中にエラーが発生したことを示す。これには、Mule Runtime 内部変換が含まれ、DataWeave 変換は含まれません。 - `EXPRESSION`​: DataWeave 式の評価中にエラーが発生したことを示す。 - `VALIDATION`​: 検証エラーが発生したことを示す。 - `DUPLICATE_MESSAGE`​: 2 回処理されたメッセージに関する検証エラーを示す。たとえば、​[冪等性のあるメッセージバリデーター](https://docs.mulesoft.com/jp/mule-runtime/4.9/idempotent-message-validator)​の使用などです。 - `REDELIVERY_EXHAUSTED`​: ソースからのメッセージの再処理の最大試行回数に達したことを示す。 - `CONNECTIVITY`​: 接続の確立で問題が発生したことを示す。これは、たとえば HTTP リクエスターなど、コネクタの使用中に発生する可能性があります。 - `RETRY_EXHAUSTED`​: 特定の実行ブロックの再試行回数がなくなったことを示す。たとえば、特定の操作や、​[Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/until-successful-scope)​の使用などです。 - `ROUTING`​: メッセージのルーティング中にエラーが発生したことを示す。たとえば、​[Round Robin ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.9/round-robin)​の使用などです。 - `COMPOSITE_ROUTING`​: メッセージのルーティング中に 1 つ以上のエラーが発生したことを示す。たとえば、​[Scatter Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.9/scatter-gather-concept)​の使用などです。 - `SECURITY`​: 無効なログイン情報の受信や期限切れのトークンの使用など、セキュリティエラーが発生したことを示す。 - `CLIENT_SECURITY`​: 外部エンティティ (たとえば、外部エンドポイントのコール) によってセキュリティエラーが発生したことを示す。 - `SERVER_SECURITY`​: Mule Runtime によってセキュリティエラーが適用されたことを示す。 - `NOT_PERMITTED`​: 検索条件によってセキュリティ制限が適用されたことを示す。たとえば、​[Mule Spring Module の認証検索条件](https://docs.mulesoft.com/spring-module/latest/#_to_validate_authentication_using_the_spring_authorization_filter)​の使用などです。 - `STREAM_MAXIMUM_SIZE_EXCEEDED`​: ストリームに許可された最大サイズを超えたことを示す。詳細については、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.9/streaming-about)​を参照してください。 - `TIMEOUT`​: メッセージの処理中にタイムアウトが発生したことを示す。 - `UNKNOWN`​: 不明なエラーまたは予期しないエラーが発生したことを示す。このエラーは、将来のランタイムバージョンでエラー種別が追加された場合に備えて後方互換性を確保するため、直接処理することはできず、​`ANY`​ を処理することで処理するしかありません。 - `SOURCE`​: フローの取得元でエラーが発生したことを示す。このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_GENERATE`​: エラー応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_ERROR_RESPONSE_SEND`​: エラー応答の送信中にフローの取得元でエラーが発生したことを示す。取得元がすでに失敗したパスを実行しているため、このエラーは処理できません。 - `SOURCE_RESPONSE`​: 成功した応答の処理中にフローの取得元でエラーが発生したことを示す。取得元がすでに成功したパスを実行しているため、このエラーは伝播のみできます。このエラーは処理できません。 - `SOURCE_RESPONSE_GENERATE`​: 成功した応答のパラメーターの生成中にフローの取得元でエラーが発生したことを示す。 - `SOURCE_RESPONSE_SEND`​: 成功した応答の送信中にフローの取得元でエラーが発生したことを示す。 - `CRITICAL`​: 重大なエラーが発生したことを示す。このエラーは処理できません。 - `OVERLOAD`​: オーバーロードの問題が発生し、実行が拒否されたことを示す。 - `FLOW_BACK_PRESSURE`​: ソースレベルでオーバーロードの問題が発生したことを示す。たとえば、ソースとしての HTTP リスナーの使用などです。 - `FATAL_JVM_ERROR`​: スタックのオーバーフローなど、重大なエラーが発生したことを示す。 ## [](#カスタムエラー種別)カスタムエラー種別 カスタムエラー種別を使用するには、マッピングするときまたはエラーが​[発生した](https://docs.mulesoft.com/jp/mule-runtime/4.9/raise-error-component-reference)​ときに定義する必要があります。このエラーは、アプリケーション内の既存の種別と区別するために特定のカスタム名前空間が必要です。つまり、HTTP および Database Connector 操作を使用するアプリケーションでは、カスタムエラー種別に HTTP および DB 名前空間を使用できません。 特定の Mule アプリケーション名またはコンテキストに関連した名前空間を定義し、既存のコネクタ名前空間の使用を避ける必要があります。たとえば、顧客集約 API は ​`CUSTOMER`​ 名前空間をそのカスタムエラー種別に使用でき、受注処理 API は ​`ORDER`​ 名前空間を使用できます。 ## [](#エラーのマッピング)エラーのマッピング フローの各操作で、可能性のあるエラー種別を選択したカスタムエラー種別にマップできます。これらのカスタムエラー種別を使用して、フローのどこでエラーが発生したかを識別できます。 たとえば、フローに異なる REST サービスにアクセスする 2 つの HTTP Request 操作がある場合、一方での接続失敗によって同じエラーが発生します。各エラーを異なるカスタムエラー種別にマッピングすることで、各操作失敗のエラー処理を識別でき、Mule アプリケーションログでエラーの発生元をすばやく識別できます。 次の例では、マッピングによって 2 つのカスタムエラー種別 ​`APP:CUSTOMER_API`​ および ​`APP:ORDER_API`​ を定義することで、きめ細かいエラー処理が可能になることがわかります。 マッピングの XML 設定の例 ```xml ``` ## [](#関連情報)関連情報 - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/on-error-scope-concept) - [ログおよびデバッグ](https://docs.mulesoft.com/jp/mule-runtime/4.9/logging-and-debugging) # Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行 次の例で、Mule 3 のさまざまな Exception Strategy (例外戦略) の移行について説明し、Mule 4 の新しいエラー処理コンポーネントについて考えます。
これらの例では、​when​ 属性内で使用される式の移行については説明していません。 式の移行については​「DataWeave への MEL の移行」​、Java Module を使用して例外を分析する方法については​「Throwable の使用」​を参照してください。
## [](#catch-exception-strategy-キャッチ例外戦略)Catch Exception Strategy (キャッチ例外戦略) catch exception strategy (キャッチ例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-continue`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#rollback-exception-strategy-ロールバック例外戦略)Rollback Exception Strategy (ロールバック例外戦略) 単純な (再配信のない) rollback exception strategy (ロールバック例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-propagate`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#再配信の指定)再配信の指定 - `idempotent-redelivery-policy`​ は ​`redelivery-policy`​ に名前が変更されます。 - `org.mule.runtime.core.api.exception.MessageRedeliveredException`​ は ​`REDELIVERY_EXHAUSTED`​ エラー種別に置き換わりました。 - `dead-letter-queue`​ は削除されます。DLQ にパブリッシュするために実行されるアウトバウンド操作は、​`REDELIVERY_EXHAUSTED`​ エラーの処理の一部として実行する必要があります。次に例を示します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ... ``` - `rollback-exception-strategy`​ では ​`maxRedelivery`​ がサポートされなくなりました。​`maxRedelivery`​ を指定する ​``​ 要素は、​`message-source`​ 内に作成する必要があります。 ## [](#choice-exception-strategy-選択肢例外戦略)Choice Exception Strategy (選択肢例外戦略) 内部に catch/rollback exception strategy (キャッチ/ロールバック例外戦略) を含む choice exception strategy (選択肢例外戦略) は、前述のとおり、例外戦略の種類に応じて on-error continue または on-error propagate を使用するエラーハンドラーに相当します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#reference-exception-strategy-参照例外戦略)Reference Exception Strategy (参照例外戦略) ガイドラインに従って前述の例外戦略はすでに移行されているので、実際の参照の移行は ​`error-handler`​ 参照を追加するだけです。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling) [ブログ: A Look into Error Handling in Mule 4 Beta (Mule 4 ベータ版のエラー処理の調査)](https://blogs.mulesoft.com/dev/mule-dev/how-to-error-handling-mule-4-beta/) # Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行 次の例で、Mule 3 のさまざまな Exception Strategy (例外戦略) の移行について説明し、Mule 4 の新しいエラー処理コンポーネントについて考えます。
これらの例では、​when​ 属性内で使用される式の移行については説明していません。 式の移行については​「DataWeave への MEL の移行」​、Java Module を使用して例外を分析する方法については​「Throwable の使用」​を参照してください。
## [](#catch-exception-strategy-キャッチ例外戦略)Catch Exception Strategy (キャッチ例外戦略) catch exception strategy (キャッチ例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-continue`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#rollback-exception-strategy-ロールバック例外戦略)Rollback Exception Strategy (ロールバック例外戦略) 単純な (再配信のない) rollback exception strategy (ロールバック例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-propagate`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#再配信の指定)再配信の指定 - `idempotent-redelivery-policy`​ は ​`redelivery-policy`​ に名前が変更されます。 - `org.mule.runtime.core.api.exception.MessageRedeliveredException`​ は ​`REDELIVERY_EXHAUSTED`​ エラー種別に置き換わりました。 - `dead-letter-queue`​ は削除されます。DLQ にパブリッシュするために実行されるアウトバウンド操作は、​`REDELIVERY_EXHAUSTED`​ エラーの処理の一部として実行する必要があります。次に例を示します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ... ``` - `rollback-exception-strategy`​ では ​`maxRedelivery`​ がサポートされなくなりました。​`maxRedelivery`​ を指定する ​``​ 要素は、​`message-source`​ 内に作成する必要があります。 ## [](#choice-exception-strategy-選択肢例外戦略)Choice Exception Strategy (選択肢例外戦略) 内部に catch/rollback exception strategy (キャッチ/ロールバック例外戦略) を含む choice exception strategy (選択肢例外戦略) は、前述のとおり、例外戦略の種類に応じて on-error continue または on-error propagate を使用するエラーハンドラーに相当します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#reference-exception-strategy-参照例外戦略)Reference Exception Strategy (参照例外戦略) ガイドラインに従って前述の例外戦略はすでに移行されているので、実際の参照の移行は ​`error-handler`​ 参照を追加するだけです。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling) [ブログ: A Look into Error Handling in Mule 4 Beta (Mule 4 ベータ版のエラー処理の調査)](https://blogs.mulesoft.com/dev/mule-dev/how-to-error-handling-mule-4-beta/) # Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行 次の例で、Mule 3 のさまざまな Exception Strategy (例外戦略) の移行について説明し、Mule 4 の新しいエラー処理コンポーネントについて考えます。
これらの例では、​when​ 属性内で使用される式の移行については説明していません。 式の移行については​「DataWeave への MEL の移行」​、Java Module を使用して例外を分析する方法については​「Throwable の使用」​を参照してください。
## [](#catch-exception-strategy-キャッチ例外戦略)Catch Exception Strategy (キャッチ例外戦略) catch exception strategy (キャッチ例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-continue`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#rollback-exception-strategy-ロールバック例外戦略)Rollback Exception Strategy (ロールバック例外戦略) 単純な (再配信のない) rollback exception strategy (ロールバック例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-propagate`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#再配信の指定)再配信の指定 - `idempotent-redelivery-policy`​ は ​`redelivery-policy`​ に名前が変更されます。 - `org.mule.runtime.core.api.exception.MessageRedeliveredException`​ は ​`REDELIVERY_EXHAUSTED`​ エラー種別に置き換わりました。 - `dead-letter-queue`​ は削除されます。DLQ にパブリッシュするために実行されるアウトバウンド操作は、​`REDELIVERY_EXHAUSTED`​ エラーの処理の一部として実行する必要があります。次に例を示します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ... ``` - `rollback-exception-strategy`​ では ​`maxRedelivery`​ がサポートされなくなりました。​`maxRedelivery`​ を指定する ​``​ 要素は、​`message-source`​ 内に作成する必要があります。 ## [](#choice-exception-strategy-選択肢例外戦略)Choice Exception Strategy (選択肢例外戦略) 内部に catch/rollback exception strategy (キャッチ/ロールバック例外戦略) を含む choice exception strategy (選択肢例外戦略) は、前述のとおり、例外戦略の種類に応じて on-error continue または on-error propagate を使用するエラーハンドラーに相当します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#reference-exception-strategy-参照例外戦略)Reference Exception Strategy (参照例外戦略) ガイドラインに従って前述の例外戦略はすでに移行されているので、実際の参照の移行は ​`error-handler`​ 参照を追加するだけです。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling) [ブログ: A Look into Error Handling in Mule 4 Beta (Mule 4 ベータ版のエラー処理の調査)](https://blogs.mulesoft.com/dev/mule-dev/how-to-error-handling-mule-4-beta/) # Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行 次の例で、Mule 3 のさまざまな Exception Strategy (例外戦略) の移行について説明し、Mule 4 の新しいエラー処理コンポーネントについて考えます。
これらの例では、​when​ 属性内で使用される式の移行については説明していません。 式の移行については​「DataWeave への MEL の移行」​、Java モジュールを使用して例外を分析する方法については​「Throwable の使用」​を参照してください。
## [](#catch-exception-strategy-キャッチ例外戦略)Catch Exception Strategy (キャッチ例外戦略) catch exception strategy (キャッチ例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-continue`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#rollback-exception-strategy-ロールバック例外戦略)Rollback Exception Strategy (ロールバック例外戦略) 単純な (再配信のない) rollback exception strategy (ロールバック例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-propagate`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#再配信の指定)再配信の指定 - `idempotent-redelivery-policy`​ は ​`redelivery-policy`​ に名前が変更されます。 - `org.mule.runtime.core.api.exception.MessageRedeliveredException`​ は ​`REDELIVERY_EXHAUSTED`​ エラー種別に置き換わりました。 - `dead-letter-queue`​ は削除されます。DLQ にパブリッシュするために実行されるアウトバウンド操作は、​`REDELIVERY_EXHAUSTED`​ エラーの処理の一部として実行する必要があります。次に例を示します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ... ``` - `rollback-exception-strategy`​ では ​`maxRedelivery`​ がサポートされなくなりました。​`maxRedelivery`​ を指定する ​``​ 要素は、​`message-source`​ 内に作成する必要があります。 ## [](#choice-exception-strategy-選択肢例外戦略)Choice Exception Strategy (選択肢例外戦略) 内部に catch/rollback exception strategy (キャッチ/ロールバック例外戦略) を含む choice exception strategy (選択肢例外戦略) は、前述のとおり、例外戦略の種類に応じて on-error continue または on-error propagate を使用するエラーハンドラーに相当します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#reference-exception-strategy-参照例外戦略)Reference Exception Strategy (参照例外戦略) ガイドラインに従って前述の例外戦略はすでに移行されているので、実際の参照の移行は ​`error-handler`​ 参照を追加するだけです。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling) [ブログ: A Look into Error Handling in Mule 4 Beta (Mule 4 ベータ版のエラー処理の調査)](https://blogs.mulesoft.com/dev/mule-dev/how-to-error-handling-mule-4-beta/) # Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行 次の例で、Mule 3 のさまざまな Exception Strategy (例外戦略) の移行について説明し、Mule 4 の新しいエラー処理コンポーネントについて考えます。
これらの例では、​when​ 属性内で使用される式の移行については説明していません。 式の移行については​「DataWeave への MEL の移行」​、Java Module を使用して例外を分析する方法については​「Throwable の使用」​を参照してください。
## [](#catch-exception-strategy-キャッチ例外戦略)Catch Exception Strategy (キャッチ例外戦略) catch exception strategy (キャッチ例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-continue`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#rollback-exception-strategy-ロールバック例外戦略)Rollback Exception Strategy (ロールバック例外戦略) 単純な (再配信のない) rollback exception strategy (ロールバック例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-propagate`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#再配信の指定)再配信の指定 - `idempotent-redelivery-policy`​ は ​`redelivery-policy`​ に名前が変更されます。 - `org.mule.runtime.core.api.exception.MessageRedeliveredException`​ は ​`REDELIVERY_EXHAUSTED`​ エラー種別に置き換わりました。 - `dead-letter-queue`​ は削除されます。DLQ にパブリッシュするために実行されるアウトバウンド操作は、​`REDELIVERY_EXHAUSTED`​ エラーの処理の一部として実行する必要があります。次に例を示します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ... ``` - `rollback-exception-strategy`​ では ​`maxRedelivery`​ がサポートされなくなりました。​`maxRedelivery`​ を指定する ​``​ 要素は、​`message-source`​ 内に作成する必要があります。 ## [](#choice-exception-strategy-選択肢例外戦略)Choice Exception Strategy (選択肢例外戦略) 内部に catch/rollback exception strategy (キャッチ/ロールバック例外戦略) を含む choice exception strategy (選択肢例外戦略) は、前述のとおり、例外戦略の種類に応じて on-error continue または on-error propagate を使用するエラーハンドラーに相当します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#reference-exception-strategy-参照例外戦略)Reference Exception Strategy (参照例外戦略) ガイドラインに従って前述の例外戦略はすでに移行されているので、実際の参照の移行は ​`error-handler`​ 参照を追加するだけです。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling) [ブログ: A Look into Error Handling in Mule 4 Beta (Mule 4 ベータ版のエラー処理の調査)](https://blogs.mulesoft.com/dev/mule-dev/how-to-error-handling-mule-4-beta/) # Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行 次の例で、Mule 3 のさまざまな Exception Strategy (例外戦略) の移行について説明し、Mule 4 の新しいエラー処理コンポーネントについて考えます。
これらの例では、​when​ 属性内で使用される式の移行については説明していません。 式の移行については​「DataWeave への MEL の移行」​、Java Module を使用して例外を分析する方法については​「Throwable の使用」​を参照してください。
## [](#catch-exception-strategy-キャッチ例外戦略)Catch Exception Strategy (キャッチ例外戦略) catch exception strategy (キャッチ例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-continue`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#rollback-exception-strategy-ロールバック例外戦略)Rollback Exception Strategy (ロールバック例外戦略) 単純な (再配信のない) rollback exception strategy (ロールバック例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-propagate`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#再配信の指定)再配信の指定 - `idempotent-redelivery-policy`​ は ​`redelivery-policy`​ に名前が変更されます。 - `org.mule.runtime.core.api.exception.MessageRedeliveredException`​ は ​`REDELIVERY_EXHAUSTED`​ エラー種別に置き換わりました。 - `dead-letter-queue`​ は削除されます。DLQ にパブリッシュするために実行されるアウトバウンド操作は、​`REDELIVERY_EXHAUSTED`​ エラーの処理の一部として実行する必要があります。次に例を示します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ... ``` - `rollback-exception-strategy`​ では ​`maxRedelivery`​ がサポートされなくなりました。​`maxRedelivery`​ を指定する ​``​ 要素は、​`message-source`​ 内に作成する必要があります。 ## [](#choice-exception-strategy-選択肢例外戦略)Choice Exception Strategy (選択肢例外戦略) 内部に catch/rollback exception strategy (キャッチ/ロールバック例外戦略) を含む choice exception strategy (選択肢例外戦略) は、前述のとおり、例外戦略の種類に応じて on-error continue または on-error propagate を使用するエラーハンドラーに相当します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#reference-exception-strategy-参照例外戦略)Reference Exception Strategy (参照例外戦略) ガイドラインに従って前述の例外戦略はすでに移行されているので、実際の参照の移行は ​`error-handler`​ 参照を追加するだけです。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling) [ブログ: A Look into Error Handling in Mule 4 Beta (Mule 4 ベータ版のエラー処理の調査)](https://blogs.mulesoft.com/dev/mule-dev/how-to-error-handling-mule-4-beta/) # Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行 次の例で、Mule 3 のさまざまな Exception Strategy (例外戦略) の移行について説明し、Mule 4 の新しいエラー処理コンポーネントについて考えます。
これらの例では、​when​ 属性内で使用される式の移行については説明していません。 式の移行については​「DataWeave への MEL の移行」​、Java Module を使用して例外を分析する方法については​「Throwable の使用」​を参照してください。
## [](#catch-exception-strategy-キャッチ例外戦略)Catch Exception Strategy (キャッチ例外戦略) catch exception strategy (キャッチ例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-continue`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#rollback-exception-strategy-ロールバック例外戦略)Rollback Exception Strategy (ロールバック例外戦略) 単純な (再配信のない) rollback exception strategy (ロールバック例外戦略) は、すべてのエラーを受け入れる単一の ​`on-error-propagate`​ コンポーネントを使用するエラーハンドラーに相当します。これはデフォルトの設定です。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#再配信の指定)再配信の指定 - `idempotent-redelivery-policy`​ は ​`redelivery-policy`​ に名前が変更されます。 - `org.mule.runtime.core.api.exception.MessageRedeliveredException`​ は ​`REDELIVERY_EXHAUSTED`​ エラー種別に置き換わりました。 - `dead-letter-queue`​ は削除されます。DLQ にパブリッシュするために実行されるアウトバウンド操作は、​`REDELIVERY_EXHAUSTED`​ エラーの処理の一部として実行する必要があります。次に例を示します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ... ``` - `rollback-exception-strategy`​ では ​`maxRedelivery`​ がサポートされなくなりました。​`maxRedelivery`​ を指定する ​``​ 要素は、​`message-source`​ 内に作成する必要があります。 ## [](#choice-exception-strategy-選択肢例外戦略)Choice Exception Strategy (選択肢例外戦略) 内部に catch/rollback exception strategy (キャッチ/ロールバック例外戦略) を含む choice exception strategy (選択肢例外戦略) は、前述のとおり、例外戦略の種類に応じて on-error continue または on-error propagate を使用するエラーハンドラーに相当します。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#reference-exception-strategy-参照例外戦略)Reference Exception Strategy (参照例外戦略) ガイドラインに従って前述の例外戦略はすでに移行されているので、実際の参照の移行は ​`error-handler`​ 参照を追加するだけです。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#関連情報)関連情報 [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling) [ブログ: A Look into Error Handling in Mule 4 Beta (Mule 4 ベータ版のエラー処理の調査)](https://blogs.mulesoft.com/dev/mule-dev/how-to-error-handling-mule-4-beta/) # Mule サーバーの通知 Mule には、フローコンポーネントの追加、認証の要求失敗、Mule の起動など、Mule サーバーで行われた変更を確認するために使用できる内部通知メカニズムがあります。こうした通知に反応するためのエージェントまたはフローコンポーネントをセットアップできます。 ## [](#通知の設定)通知の設定 メッセージ通知は、Mule サーバーとの間で送信されるすべての情報のスナップショットとなります。Mule はメッセージを送受信したときにこうした通知を実行します。こうした追加の通知はパフォーマンスに影響を及ぼすため、デフォルトで無効になっています。メッセージ通知を有効にするには、Mule 設定ファイルで ​``​ 要素を使用して有効にするメッセージの種別を設定します。また、通知リスナーを登録してインターフェースを特定の通知に関連付けます。 たとえば、最初に Spring 設定ファイルで通知リスナーの Bean を作成し、受信する通知の種別のクラスを指定します。 ```xml ``` 続いて、Spring 設定の参照を追加します。 ```xml ``` 次に、​``​ 要素を使用して受信する通知を指定し、​``​ 要素を使用してリスナーを登録します。 ```xml ``` MESSAGE-PROCESSOR 通知を指定すると、通知はメッセージプロセッサーが呼び出される前と後に送信されます。リスナーは受信する通知の種別のインターフェースを実装しているため、リスナーは正しい通知を受信します。 たとえば、​`ProcessorNotificationLogger`​ クラスは ​`org.mule.runtime.api.notification.MessageProcessorNotificationListener`​ を実装します。 ```java public class ProcessorNotificationLogger implements MessageProcessorNotificationListener { @Override public void onNotification(MessageProcessorNotification notification) { // write here the logic to process the notification event } } ```
API クラスをクラスパスで使用できるように、忘れずに ​provided​ をスコープとして POM ファイルで Mule と API の連動関係を追加してください。この連動関係は実行時に Mule によって提供されます。
通知種別のリストについては、​[「通知設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.3/notifications-configuration-reference)​を参照してください。通知リスナーインターフェースのリストについては、下記の​[\[Notification Interfaces\]](<#Notification Interfaces>)​を参照してください。 ### [](#別のインターフェースの指定)別のインターフェースの指定 通知に関連付けられたインターフェースを変更するには、​`interface-class`​ 属性で新しいインターフェースを指定します。 ```xml ``` ### [](#カスタム通知の設定)カスタム通知の設定 カスタム通知を作成する場合、​`event-class`​ 属性も指定します。 ```xml ``` ### [](#通知の無効化)通知の無効化 特定のインターフェースが通知を受信しないようにブロックするには、​``​ 要素で指定します。ブロックする通知種別 (イベント)、イベントクラス、インターフェース、インターフェースクラスを指定できます。 ```xml ``` ### [](#サブスクリプションの使用)サブスクリプションの使用 リスナーを登録するときに、​`subscription`​ 属性を使用して特定のコンポーネントからの通知のみを受信するように指定できます。たとえば、「MyService1」という名前のフローコンポーネントからのみ通知を受信するようにリスナーを指定するには、次のようにリスナーを設定します。 ```xml ``` 名前に「Service」が付くすべてのフローコンポーネントからの通知の受信に登録するには、次のようにワイルドカード文字列を使用します。 詳細は、下記の​[\[Registering Listeners Programmatically\]](<#Registering Listeners Programmatically>)​を参照してください。 ## [](#カスタム通知の実行)カスタム通知の実行 オブジェクトは Mule でカスタム通知を実行し、カスタムリスナーに通知できます。たとえば、検出エージェントはクライアントが接続したときに「Client Found (クライアントが見つかりました)」という通知を実行する場合もあります。 カスタム通知は次のように実行します。 ```text CustomNotification n = new CustomNotification("Hello"); notificationDispatcher.dispatch(n); ``` `CustomNotificationListener`​ を実装するオブジェクトがこの通知を受信します。​`CustomNotification`​ を拡張して、カスタム通知種別のアクションを定義すると良いでしょう。例: ```text DiscoveryNotification n = new DiscoveryNotification(client, DiscoveryNotification.CLIENT_ADDED); notificationDispatcher.dispatch(n); ``` ## [](#通知インターフェース)通知インターフェース 次の表は、​`org.mule.runtime.api.notification`​ パッケージの Mule サーバー通知とインターフェースを示しています。オブジェクトは、これらのインターフェースのいずれかを実装して関連付けられた通知のリスナーになることができます。すべてのリスナーは ​`NotificationListener`​ インターフェースを拡張します。
通知 説明 インターフェース

Connection (接続) 通知

接続が行われるか切断されたときに実行されます。

ConnectionNotificationListener​

Custom (カスタム) 通知

コンポーネントの他、ルーター、トランスフォーマー、エージェントなどのオブジェクトによって相互の状態の変更を通信するために実行される場合があります。

CustomNotificationListener​

Exception (例外) 通知

例外がスローされました。

ExceptionNotificationListener​

Management (管理) 通知

内部キューが容量に達するなど、Mule インスタンスまたはそのリソースの状態が変更されました。

ManagementNotificationListener​

Mule Context (Mule コンテキスト) 通知

Mule コンテキストの開始などのイベントが発生したときに実行できます。

MuleContextNotificationListener​

Routing (ルーティング) 通知

Async-Reply (非同期返信) ルーターは、すでに処理されたイベントグループについてイベントが受信されたときにこの通知を使用します。

RoutingNotificationListener​

Security (セキュリティ) 通知

認証の要求が失敗したときに実行されます。

SecurityNotificationListener​

Transaction (トランザクション) 通知

トランザクションが開始された、コミットされた、ロールバックされた後に実行されます。

TransactionNotificationListener​

Async-Message (非同期メッセージ) 通知

非同期作業がスケジュールされ、指定されたフローについて完了したときに実行できます。

AsyncMessageNotificationListener​

Pipeline-Message (パイプラインメッセージ) 通知

パイプラインの処理の重要なステップで実行されます。

PipelineMessageNotificationListener​

Message-Processor (メッセージプロセッサー) 通知

メッセージプロセッサーが呼び出されました。

MessageProcessorNotificationListener​

Exception Strategy (例外戦略) 通知

例外戦略が呼び出されました。

ExceptionStrategyNotificationListener​

Extension (拡張機能) 通知

カスタムデータを含む拡張機能によって実行できます。

ExtensionNotificationListener​

Connector-Message (コネクタメッセージ) 通知

メッセージが受信されたかコネクタを通じて送信されたときに実行されます。

ConnectorMessageNotificationListener​
リスナーインターフェースにはすべて単一のメソッドがあります。 ```java public void onNotification(T notification); ``` ここで、T は通知クラスです (末尾に「Listener」が付かないリスナークラス)。 実装されているリスナーに応じて、特定の通知のみが受信されます。たとえば、オブジェクトで ​`ManagementNotificationListener`​ が実装されている場合、種別 ​`ManagementNotification`​ の通知のみが受信されます。オブジェクトは複数のリスナーを実装して複数の種別の通知を受信できます。 ## [](#プログラムでのリスナーの登録)プログラムでのリスナーの登録 リスナーは次のように登録できます。 notificationListenerRegistry.registerListener(listener); または notificationListenerRegistry.registerListener(listener, selector); ここで、​`listener`​ は ​`NotificationListener`​ インスタンスであり、​`selector`​ はリスナーをコールする前に実行された通知に適用する検索条件として機能する ​`Predicate`​ です。 ## [](#通知アクションコード)通知アクションコード 各通知には、通知種別を決定するアクションコードがあります。アクションコードを問い合わせて、その種別を決定することができます。例: **MyObject.java** ```java public class MyObject implements ConnectionNotificationListener { (...) public void onNotification(ConnectionNotification notification) { if (valueOf(ConnectionNotification.CONNECTION_FAILED).equals(notification.getAction().getIdentifier())) { // write here the logic to handle the connection failed notification } } } ``` ## [](#通知ペイロード)通知ペイロード すべての通知は ​`java.util.EventObject`​ を拡張し、​`getSource()`​ メソッドを使用してオブジェクトのペイロードにアクセスできます。次の表で、通知の各種別のペイロードについて説明します。
Notification (通知) ペイロード種別 リソース ID 説明

Connection (接続) 通知

String (文字列)

<connector-name>.receiver(<endpoint-uri>)

接続されたメッセージレシーバーまたはメッセージディスパッチャー。

Custom (カスタム) 通知

任意のオブジェクト

任意の String (文字列)

オブジェクト種別は通知を実行したオブジェクトに対してカスタムです。

Exception (例外) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Management (管理) 通知

Object (オブジェクト)

オブジェクト ID

この通知をトリガーした監視対象オブジェクト。

Mule Context (Mule コンテキスト) 通知

MuleContext

Mule コンテキスト ID

Mule コンテキストインスタンス。getMuleContext() のコールと同じ。

Routing (ルーティング) 通知

Message (メッセージ)

メッセージ ID

送信または受信されたメッセージ。

Security (セキュリティ) 通知

SecurityException

例外メッセージ。

発生したセキュリティ例外。

Transaction (トランザクション) 通知

String (文字列)

トランザクション ID

この通知をトリガーしたトランザクション。

Async-Message (非同期メッセージ) 通知

ComponentLocation

コンポーネント名

非同期作業をスケジュールしたコンポーネント。

Pipeline-Message (パイプラインメッセージ) 通知

String (文字列)

Name (名前)

パイプライン名。

Message-Processor (メッセージプロセッサー) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Exception Strategy (例外戦略) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Extension (拡張機能) 通知

Object (オブジェクト)

Extension name (拡張名)

ペイロードは拡張機能ごとに変更できます。

Connector-Message (コネクタメッセージ) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。
# Mule サーバーの通知 Mule には、フローコンポーネントの追加、認証の要求失敗、Mule の起動など、Mule サーバーで行われた変更を確認するために使用できる内部通知メカニズムがあります。こうした通知に反応するためのエージェントまたはフローコンポーネントをセットアップできます。 ## [](#通知の設定)通知の設定 メッセージ通知は、Mule サーバーとの間で送信されるすべての情報のスナップショットとなります。Mule はメッセージを送受信したときにこうした通知を実行します。こうした追加の通知はパフォーマンスに影響を及ぼすため、デフォルトで無効になっています。メッセージ通知を有効にするには、Mule 設定ファイルで ​``​ 要素を使用して有効にするメッセージの種別を設定します。また、通知リスナーを登録してインターフェースを特定の通知に関連付けます。 たとえば、最初に Spring 設定ファイルで通知リスナーの Bean を作成し、受信する通知の種別のクラスを指定します。 ```xml ``` 続いて、Spring 設定の参照を追加します。 ```xml ``` 次に、​``​ 要素を使用して受信する通知を指定し、​``​ 要素を使用してリスナーを登録します。 ```xml ``` MESSAGE-PROCESSOR 通知を指定すると、通知はメッセージプロセッサーが呼び出される前と後に送信されます。リスナーは受信する通知の種別のインターフェースを実装しているため、リスナーは正しい通知を受信します。 たとえば、​`ProcessorNotificationLogger`​ クラスは ​`org.mule.runtime.api.notification.MessageProcessorNotificationListener`​ を実装します。 ```java public class ProcessorNotificationLogger implements MessageProcessorNotificationListener { @Override public void onNotification(MessageProcessorNotification notification) { // write here the logic to process the notification event } } ```
API クラスをクラスパスで使用できるように、忘れずに ​provided​ をスコープとして POM ファイルで Mule と API の連動関係を追加してください。この連動関係は実行時に Mule によって提供されます。
通知種別のリストについては、​[「通知設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.4/notifications-configuration-reference)​を参照してください。通知リスナーインターフェースのリストについては、下記の​[\[Notification Interfaces\]](<#Notification Interfaces>)​を参照してください。 ### [](#別のインターフェースの指定)別のインターフェースの指定 通知に関連付けられたインターフェースを変更するには、​`interface-class`​ 属性で新しいインターフェースを指定します。 ```xml ``` ### [](#カスタム通知の設定)カスタム通知の設定 カスタム通知を作成する場合、​`event-class`​ 属性も指定します。 ```xml ``` ### [](#通知の無効化)通知の無効化 特定のインターフェースが通知を受信しないようにブロックするには、​``​ 要素で指定します。ブロックする通知種別 (イベント)、イベントクラス、インターフェース、インターフェースクラスを指定できます。 ```xml ``` ### [](#サブスクリプションの使用)サブスクリプションの使用 リスナーを登録するときに、​`subscription`​ 属性を使用して特定のコンポーネントからの通知のみを受信するように指定できます。たとえば、「MyService1」という名前のフローコンポーネントからのみ通知を受信するようにリスナーを指定するには、次のようにリスナーを設定します。 ```xml ``` 名前に「Service」が付くすべてのフローコンポーネントからの通知の受信に登録するには、次のようにワイルドカード文字列を使用します。 詳細は、下記の​[\[Registering Listeners Programmatically\]](<#Registering Listeners Programmatically>)​を参照してください。 ## [](#カスタム通知の実行)カスタム通知の実行 オブジェクトは Mule でカスタム通知を実行し、カスタムリスナーに通知できます。たとえば、検出エージェントはクライアントが接続したときに「Client Found (クライアントが見つかりました)」という通知を実行する場合もあります。 カスタム通知は次のように実行します。 ```text CustomNotification n = new CustomNotification("Hello"); notificationDispatcher.dispatch(n); ``` `CustomNotificationListener`​ を実装するオブジェクトがこの通知を受信します。​`CustomNotification`​ を拡張して、カスタム通知種別のアクションを定義すると良いでしょう。例: ```text DiscoveryNotification n = new DiscoveryNotification(client, DiscoveryNotification.CLIENT_ADDED); notificationDispatcher.dispatch(n); ``` ## [](#通知インターフェース)通知インターフェース 次の表は、​`org.mule.runtime.api.notification`​ パッケージの Mule サーバー通知とインターフェースを示しています。オブジェクトは、これらのインターフェースのいずれかを実装して関連付けられた通知のリスナーになることができます。すべてのリスナーは ​`NotificationListener`​ インターフェースを拡張します。
Notification (通知) 説明 インターフェース

Connection (接続) 通知

接続が行われるか切断されたときに実行されます。

ConnectionNotificationListener​

Custom (カスタム) 通知

コンポーネントの他、ルーター、トランスフォーマー、エージェントなどのオブジェクトによって相互の状態の変更を通信するために実行される場合があります。

CustomNotificationListener​

Exception (例外) 通知

例外がスローされました。

ExceptionNotificationListener​

Management (管理) 通知

内部キューが容量に達するなど、Mule インスタンスまたはそのリソースの状態が変更されました。

ManagementNotificationListener​

Mule Context (Mule コンテキスト) 通知

Mule コンテキストの開始などのイベントが発生したときに実行できます。

MuleContextNotificationListener​

Routing (ルーティング) 通知

Async-Reply (非同期返信) ルーターは、すでに処理されたイベントグループについてイベントが受信されたときにこの通知を使用します。

RoutingNotificationListener​

Security (セキュリティ) 通知

認証の要求が失敗したときに実行されます。

SecurityNotificationListener​

Transaction (トランザクション) 通知

トランザクションが開始された、コミットされた、ロールバックされた後に実行されます。

TransactionNotificationListener​

Async-Message (非同期メッセージ) 通知

非同期作業がスケジュールされ、指定されたフローについて完了したときに実行できます。

AsyncMessageNotificationListener​

Pipeline-Message (パイプラインメッセージ) 通知

パイプラインの処理の重要なステップで実行されます。

PipelineMessageNotificationListener​

Message-Processor (メッセージプロセッサー) 通知

メッセージプロセッサーが呼び出されました。

MessageProcessorNotificationListener​

Exception Strategy (例外戦略) 通知

例外戦略が呼び出されました。

ExceptionStrategyNotificationListener​

Extension (拡張機能) 通知

カスタムデータを含む拡張機能によって実行できます。

ExtensionNotificationListener​

Connector-Message (コネクタメッセージ) 通知

メッセージが受信されたかコネクタを通じて送信されたときに実行されます。

ConnectorMessageNotificationListener​
リスナーインターフェースにはすべて単一のメソッドがあります。 ```java public void onNotification(T notification); ``` ここで、T は通知クラスです (末尾に「Listener」が付かないリスナークラス)。 実装されているリスナーに応じて、特定の通知のみが受信されます。たとえば、オブジェクトで ​`ManagementNotificationListener`​ が実装されている場合、種別 ​`ManagementNotification`​ の通知のみが受信されます。オブジェクトは複数のリスナーを実装して複数の種別の通知を受信できます。 ## [](#プログラムでのリスナーの登録)プログラムでのリスナーの登録 リスナーは次のように登録できます。 notificationListenerRegistry.registerListener(listener); または notificationListenerRegistry.registerListener(listener, selector); ここで、​`listener`​ は ​`NotificationListener`​ インスタンスであり、​`selector`​ はリスナーをコールする前に実行された通知に適用する検索条件として機能する ​`Predicate`​ です。 ## [](#通知アクションコード)通知アクションコード 各通知には、通知種別を決定するアクションコードがあります。アクションコードを問い合わせて、その種別を決定することができます。例: **MyObject.java** ```java public class MyObject implements ConnectionNotificationListener { (...) public void onNotification(ConnectionNotification notification) { if (valueOf(ConnectionNotification.CONNECTION_FAILED).equals(notification.getAction().getIdentifier())) { // write here the logic to handle the connection failed notification } } } ``` ## [](#通知ペイロード)通知ペイロード すべての通知は ​`java.util.EventObject`​ を拡張し、​`getSource()`​ メソッドを使用してオブジェクトのペイロードにアクセスできます。次の表で、通知の各種別のペイロードについて説明します。
Notification (通知) ペイロード種別 リソース ID 説明

Connection (接続) 通知

String (文字列)

<connector-name>.receiver(<endpoint-uri>)

接続されたメッセージレシーバーまたはメッセージディスパッチャー。

Custom (カスタム) 通知

任意のオブジェクト

任意の String (文字列)

オブジェクト種別は通知を実行したオブジェクトに対してカスタムです。

Exception (例外) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Management (管理) 通知

Object (オブジェクト)

オブジェクト ID

この通知をトリガーした監視対象オブジェクト。

Mule Context (Mule コンテキスト) 通知

MuleContext

Mule コンテキスト ID

Mule コンテキストインスタンス。getMuleContext() のコールと同じ。

Routing (ルーティング) 通知

Message (メッセージ)

メッセージ ID

送信または受信されたメッセージ。

Security (セキュリティ) 通知

SecurityException

例外メッセージ。

発生したセキュリティ例外。

Transaction (トランザクション) 通知

String (文字列)

トランザクション ID

この通知をトリガーしたトランザクション。

Async-Message (非同期メッセージ) 通知

ComponentLocation

コンポーネント名

非同期作業をスケジュールしたコンポーネント。

Pipeline-Message (パイプラインメッセージ) 通知

String (文字列)

Name (名前)

パイプライン名。

Message-Processor (メッセージプロセッサー) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Exception Strategy (例外戦略) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Extension (拡張機能) 通知

Object (オブジェクト)

Extension name (拡張名)

ペイロードは拡張機能ごとに変更できます。

Connector-Message (コネクタメッセージ) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。
# Mule サーバーの通知 Mule には、フローコンポーネントの追加、認証の要求失敗、Mule の起動など、Mule サーバーで行われた変更を確認するために使用できる内部通知メカニズムがあります。こうした通知に反応するためのエージェントまたはフローコンポーネントをセットアップできます。 ## [](#通知の設定)通知の設定 メッセージ通知は、Mule サーバーとの間で送信されるすべての情報のスナップショットとなります。Mule はメッセージを送受信したときにこうした通知を実行します。こうした追加の通知はパフォーマンスに影響を及ぼすため、デフォルトで無効になっています。メッセージ通知を有効にするには、Mule 設定ファイルで ​``​ 要素を使用して有効にするメッセージの種別を設定します。また、通知リスナーを登録してインターフェースを特定の通知に関連付けます。 たとえば、最初に Spring 設定ファイルで通知リスナーの Bean を作成し、受信する通知の種別のクラスを指定します。 ```xml ``` 続いて、Spring 設定の参照を追加します。 ```xml ``` 次に、​``​ 要素を使用して受信する通知を指定し、​``​ 要素を使用してリスナーを登録します。 ```xml ``` MESSAGE-PROCESSOR 通知を指定すると、通知はメッセージプロセッサーが呼び出される前と後に送信されます。リスナーは受信する通知の種別のインターフェースを実装しているため、リスナーは正しい通知を受信します。 たとえば、​`ProcessorNotificationLogger`​ クラスは ​`org.mule.runtime.api.notification.MessageProcessorNotificationListener`​ を実装します。 ```java public class ProcessorNotificationLogger implements MessageProcessorNotificationListener { @Override public void onNotification(MessageProcessorNotification notification) { // write here the logic to process the notification event } } ```
API クラスをクラスパスで使用できるように、忘れずに ​provided​ をスコープとして POM ファイルで Mule と API の連動関係を追加してください。この連動関係は実行時に Mule によって提供されます。
通知種別のリストについては、​[「通知設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.5/notifications-configuration-reference)​を参照してください。通知リスナーインターフェースのリストについては、下記の​[\[Notification Interfaces\]](<#Notification Interfaces>)​を参照してください。 ### [](#別のインターフェースの指定)別のインターフェースの指定 通知に関連付けられたインターフェースを変更するには、​`interface-class`​ 属性で新しいインターフェースを指定します。 ```xml ``` ### [](#カスタム通知の設定)カスタム通知の設定 カスタム通知を作成する場合、​`event-class`​ 属性も指定します。 ```xml ``` ### [](#通知の無効化)通知の無効化 特定のインターフェースが通知を受信しないようにブロックするには、​``​ 要素で指定します。ブロックする通知種別 (イベント)、イベントクラス、インターフェース、インターフェースクラスを指定できます。 ```xml ``` ### [](#サブスクリプションの使用)サブスクリプションの使用 リスナーを登録するときに、​`subscription`​ 属性を使用して特定のコンポーネントからの通知のみを受信するように指定できます。たとえば、「MyService1」という名前のフローコンポーネントからのみ通知を受信するようにリスナーを指定するには、次のようにリスナーを設定します。 ```xml ``` 名前に「Service」が付くすべてのフローコンポーネントからの通知の受信に登録するには、次のようにワイルドカード文字列を使用します。 詳細は、下記の​[\[Registering Listeners Programmatically\]](<#Registering Listeners Programmatically>)​を参照してください。 ## [](#カスタム通知の実行)カスタム通知の実行 オブジェクトは Mule でカスタム通知を実行し、カスタムリスナーに通知できます。たとえば、検出エージェントはクライアントが接続したときに「Client Found (クライアントが見つかりました)」という通知を実行する場合もあります。 カスタム通知は次のように実行します。 ```text CustomNotification n = new CustomNotification("Hello"); notificationDispatcher.dispatch(n); ``` `CustomNotificationListener`​ を実装するオブジェクトがこの通知を受信します。​`CustomNotification`​ を拡張して、カスタム通知種別のアクションを定義すると良いでしょう。次に例を示します。 ```text DiscoveryNotification n = new DiscoveryNotification(client, DiscoveryNotification.CLIENT_ADDED); notificationDispatcher.dispatch(n); ``` ## [](#通知インターフェース)通知インターフェース 次の表は、​`org.mule.runtime.api.notification`​ パッケージの Mule サーバー通知とインターフェースを示しています。オブジェクトは、これらのインターフェースのいずれかを実装して関連付けられた通知のリスナーになることができます。すべてのリスナーは ​`NotificationListener`​ インターフェースを拡張します。
Notification (通知) 説明 インターフェース

Connection (接続) 通知

接続が行われるか切断されたときに実行されます。

ConnectionNotificationListener​

Custom (カスタム) 通知

コンポーネントの他、ルーター、トランスフォーマー、エージェントなどのオブジェクトによって相互の状態の変更を通信するために実行される場合があります。

CustomNotificationListener​

Exception (例外) 通知

例外がスローされました。

ExceptionNotificationListener​

Management (管理) 通知

内部キューが容量に達するなど、Mule インスタンスまたはそのリソースの状態が変更されました。

ManagementNotificationListener​

Mule Context (Mule コンテキスト) 通知

Mule コンテキストの開始などのイベントが発生したときに実行できます。

MuleContextNotificationListener​

Routing (ルーティング) 通知

Async-Reply (非同期返信) ルーターは、すでに処理されたイベントグループについてイベントが受信されたときにこの通知を使用します。

RoutingNotificationListener​

Security (セキュリティ) 通知

認証の要求が失敗したときに実行されます。

SecurityNotificationListener​

Transaction (トランザクション) 通知

トランザクションが開始された、コミットされた、ロールバックされた後に実行されます。

TransactionNotificationListener​

Async-Message (非同期メッセージ) 通知

非同期作業がスケジュールされ、指定されたフローについて完了したときに実行できます。

AsyncMessageNotificationListener​

Pipeline-Message (パイプラインメッセージ) 通知

パイプラインの処理の重要なステップで実行されます。

PipelineMessageNotificationListener​

Message-Processor (メッセージプロセッサー) 通知

メッセージプロセッサーが呼び出されました。

MessageProcessorNotificationListener​

Exception Strategy (例外戦略) 通知

例外戦略が呼び出されました。

ExceptionStrategyNotificationListener​

Extension (拡張機能) 通知

カスタムデータを含む拡張機能によって実行できます。

ExtensionNotificationListener​

Connector-Message (コネクタメッセージ) 通知

メッセージが受信されたかコネクタを通じて送信されたときに実行されます。

ConnectorMessageNotificationListener​
リスナーインターフェースにはすべて単一のメソッドがあります。 ```java public void onNotification(T notification); ``` ここで、T は通知クラスです (末尾に「Listener」が付かないリスナークラス)。 実装されているリスナーに応じて、特定の通知のみが受信されます。たとえば、オブジェクトで ​`ManagementNotificationListener`​ が実装されている場合、種別 ​`ManagementNotification`​ の通知のみが受信されます。オブジェクトは複数のリスナーを実装して複数の種別の通知を受信できます。 ## [](#プログラムでのリスナーの登録)プログラムでのリスナーの登録 リスナーは次のように登録できます。 notificationListenerRegistry.registerListener(listener); または notificationListenerRegistry.registerListener(listener, selector); ここで、​`listener`​ は ​`NotificationListener`​ インスタンスであり、​`selector`​ はリスナーをコールする前に実行された通知に適用する検索条件として機能する ​`Predicate`​ です。 ## [](#通知アクションコード)通知アクションコード 各通知には、通知種別を決定するアクションコードがあります。アクションコードを問い合わせて、その種別を決定することができます。次に例を示します。 **MyObject.java** ```java public class MyObject implements ConnectionNotificationListener { (...) public void onNotification(ConnectionNotification notification) { if (valueOf(ConnectionNotification.CONNECTION_FAILED).equals(notification.getAction().getIdentifier())) { // write here the logic to handle the connection failed notification } } } ``` ## [](#通知ペイロード)通知ペイロード すべての通知は ​`java.util.EventObject`​ を拡張し、​`getSource()`​ メソッドを使用してオブジェクトのペイロードにアクセスできます。次の表で、通知の各種別のペイロードについて説明します。
Notification (通知) ペイロード種別 リソース ID 説明

Connection (接続) 通知

String (文字列)

<connector-name>.receiver(<endpoint-uri>)

接続されたメッセージレシーバーまたはメッセージディスパッチャー。

Custom (カスタム) 通知

任意のオブジェクト

任意の String (文字列)

オブジェクト種別は通知を実行したオブジェクトに対してカスタムです。

Exception (例外) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Management (管理) 通知

Object (オブジェクト)

オブジェクト ID

この通知をトリガーした監視対象オブジェクト。

Mule Context (Mule コンテキスト) 通知

MuleContext

Mule コンテキスト ID

Mule コンテキストインスタンス。getMuleContext() のコールと同じ。

Routing (ルーティング) 通知

Message (メッセージ)

メッセージ ID

送信または受信されたメッセージ。

Security (セキュリティ) 通知

SecurityException

例外メッセージ。

発生したセキュリティ例外。

Transaction (トランザクション) 通知

String (文字列)

トランザクション ID

この通知をトリガーしたトランザクション。

Async-Message (非同期メッセージ) 通知

ComponentLocation

コンポーネント名

非同期作業をスケジュールしたコンポーネント。

Pipeline-Message (パイプラインメッセージ) 通知

String (文字列)

名前

パイプライン名。

Message-Processor (メッセージプロセッサー) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Exception Strategy (例外戦略) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Extension (拡張機能) 通知

Object (オブジェクト)

Extension name (拡張名)

ペイロードは拡張機能ごとに変更できます。

Connector-Message (コネクタメッセージ) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。
# Mule サーバーの通知 Mule には、フローコンポーネントの追加、認証の要求失敗、Mule の起動など、Mule サーバーで行われた変更を確認するために使用できる内部通知メカニズムがあります。こうした通知に反応するためのエージェントまたはフローコンポーネントをセットアップできます。 ## [](#通知の設定)通知の設定 メッセージ通知は、Mule サーバーとの間で送信されるすべての情報のスナップショットとなります。Mule はメッセージを送受信したときにこうした通知を実行します。こうした追加の通知はパフォーマンスに影響を及ぼすため、デフォルトで無効になっています。メッセージ通知を有効にするには、Mule 設定ファイルで ​``​ 要素を使用して有効にするメッセージの種別を設定します。また、通知リスナーを登録してインターフェースを特定の通知に関連付けます。 たとえば、最初に Spring 設定ファイルで通知リスナーの Bean を作成し、受信する通知の種別のクラスを指定します。 ```xml ``` 続いて、Spring 設定の参照を追加します。 ```xml ``` 次に、​``​ 要素を使用して受信する通知を指定し、​``​ 要素を使用してリスナーを登録します。 ```xml ``` MESSAGE-PROCESSOR 通知を指定すると、通知はメッセージプロセッサーが呼び出される前と後に送信されます。リスナーは受信する通知の種別のインターフェースを実装しているため、リスナーは正しい通知を受信します。 たとえば、​`ProcessorNotificationLogger`​ クラスは ​`org.mule.runtime.api.notification.MessageProcessorNotificationListener`​ を実装します。 ```java public class ProcessorNotificationLogger implements MessageProcessorNotificationListener { @Override public void onNotification(MessageProcessorNotification notification) { // write here the logic to process the notification event } } ```
API クラスをクラスパスで使用できるように、忘れずに ​provided​ をスコープとして POM ファイルで Mule と API の連動関係を追加してください。この連動関係は実行時に Mule によって提供されます。
通知種別のリストについては、​[「通知設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.6/notifications-configuration-reference)​を参照してください。通知リスナーインターフェースのリストについては、下記の​[\[Notification Interfaces\]](<#Notification Interfaces>)​を参照してください。 ### [](#別のインターフェースの指定)別のインターフェースの指定 通知に関連付けられたインターフェースを変更するには、​`interface-class`​ 属性で新しいインターフェースを指定します。 ```xml ``` ### [](#カスタム通知の設定)カスタム通知の設定 カスタム通知を作成する場合、​`event-class`​ 属性も指定します。 ```xml ``` ### [](#通知の無効化)通知の無効化 特定のインターフェースが通知を受信しないようにブロックするには、​``​ 要素で指定します。ブロックする通知種別 (イベント)、イベントクラス、インターフェース、インターフェースクラスを指定できます。 ```xml ``` ### [](#サブスクリプションの使用)サブスクリプションの使用 リスナーを登録するときに、​`subscription`​ 属性を使用して特定のコンポーネントからの通知のみを受信するように指定できます。たとえば、「MyService1」という名前のフローコンポーネントからのみ通知を受信するようにリスナーを指定するには、次のようにリスナーを設定します。 ```xml ``` 名前に「Service」が付くすべてのフローコンポーネントからの通知の受信に登録するには、次のようにワイルドカード文字列を使用します。 詳細は、下記の​[\[Registering Listeners Programmatically\]](<#Registering Listeners Programmatically>)​を参照してください。 ## [](#カスタム通知の実行)カスタム通知の実行 オブジェクトは Mule でカスタム通知を実行し、カスタムリスナーに通知できます。たとえば、検出エージェントはクライアントが接続したときに「Client Found (クライアントが見つかりました)」という通知を実行する場合もあります。 カスタム通知は次のように実行します。 ```text CustomNotification n = new CustomNotification("Hello"); notificationDispatcher.dispatch(n); ``` `CustomNotificationListener`​ を実装するオブジェクトがこの通知を受信します。​`CustomNotification`​ を拡張して、カスタム通知種別のアクションを定義すると良いでしょう。例: ```text DiscoveryNotification n = new DiscoveryNotification(client, DiscoveryNotification.CLIENT_ADDED); notificationDispatcher.dispatch(n); ``` ## [](#通知インターフェース)通知インターフェース 次の表は、​`org.mule.runtime.api.notification`​ パッケージの Mule サーバー通知とインターフェースを示しています。オブジェクトは、これらのインターフェースのいずれかを実装して関連付けられた通知のリスナーになることができます。すべてのリスナーは ​`NotificationListener`​ インターフェースを拡張します。
Notification (通知) 説明 インターフェース

Connection (接続) 通知

接続が行われるか切断されたときに実行されます。

ConnectionNotificationListener​

Custom (カスタム) 通知

コンポーネントの他、ルーター、トランスフォーマー、エージェントなどのオブジェクトによって相互の状態の変更を通信するために実行される場合があります。

CustomNotificationListener​

Exception (例外) 通知

例外がスローされました。

ExceptionNotificationListener​

Management (管理) 通知

内部キューが容量に達するなど、Mule インスタンスまたはそのリソースの状態が変更されました。

ManagementNotificationListener​

Mule Context (Mule コンテキスト) 通知

Mule コンテキストの開始などのイベントが発生したときに実行できます。

MuleContextNotificationListener​

Routing (ルーティング) 通知

Async-Reply (非同期返信) ルーターは、すでに処理されたイベントグループについてイベントが受信されたときにこの通知を使用します。

RoutingNotificationListener​

Security (セキュリティ) 通知

認証の要求が失敗したときに実行されます。

SecurityNotificationListener​

Transaction (トランザクション) 通知

トランザクションが開始された、コミットされた、ロールバックされた後に実行されます。

TransactionNotificationListener​

Async-Message (非同期メッセージ) 通知

非同期作業がスケジュールされ、指定されたフローについて完了したときに実行できます。

AsyncMessageNotificationListener​

Pipeline-Message (パイプラインメッセージ) 通知

パイプラインの処理の重要なステップで実行されます。

PipelineMessageNotificationListener​

Message-Processor (メッセージプロセッサー) 通知

メッセージプロセッサーが呼び出されました。

MessageProcessorNotificationListener​

Exception Strategy (例外戦略) 通知

例外戦略が呼び出されました。

ExceptionStrategyNotificationListener​

Extension (拡張機能) 通知

カスタムデータを含む拡張機能によって実行できます。

ExtensionNotificationListener​

Connector-Message (コネクタメッセージ) 通知

メッセージが受信されたかコネクタを通じて送信されたときに実行されます。

ConnectorMessageNotificationListener​
リスナーインターフェースにはすべて単一のメソッドがあります。 ```java public void onNotification(T notification); ``` ここで、T は通知クラスです (末尾に「Listener」が付かないリスナークラス)。 実装されているリスナーに応じて、特定の通知のみが受信されます。たとえば、オブジェクトで ​`ManagementNotificationListener`​ が実装されている場合、種別 ​`ManagementNotification`​ の通知のみが受信されます。オブジェクトは複数のリスナーを実装して複数の種別の通知を受信できます。 ## [](#プログラムでのリスナーの登録)プログラムでのリスナーの登録 リスナーは次のように登録できます。 notificationListenerRegistry.registerListener(listener); または notificationListenerRegistry.registerListener(listener, selector); ここで、​`listener`​ は ​`NotificationListener`​ インスタンスであり、​`selector`​ はリスナーをコールする前に実行された通知に適用する検索条件として機能する ​`Predicate`​ です。 ## [](#通知アクションコード)通知アクションコード 各通知には、通知種別を決定するアクションコードがあります。アクションコードを問い合わせて、その種別を決定することができます。例: **MyObject.java** ```java public class MyObject implements ConnectionNotificationListener { (...) public void onNotification(ConnectionNotification notification) { if (valueOf(ConnectionNotification.CONNECTION_FAILED).equals(notification.getAction().getIdentifier())) { // write here the logic to handle the connection failed notification } } } ``` ## [](#通知ペイロード)通知ペイロード すべての通知は ​`java.util.EventObject`​ を拡張し、​`getSource()`​ メソッドを使用してオブジェクトのペイロードにアクセスできます。次の表で、通知の各種別のペイロードについて説明します。
Notification (通知) ペイロード種別 リソース ID 説明

Connection (接続) 通知

String (文字列)

<connector-name>.receiver(<endpoint-uri>)

接続されたメッセージレシーバーまたはメッセージディスパッチャー。

Custom (カスタム) 通知

任意のオブジェクト

任意の String (文字列)

オブジェクト種別は通知を実行したオブジェクトに対してカスタムです。

Exception (例外) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Management (管理) 通知

Object (オブジェクト)

オブジェクト ID

この通知をトリガーした監視対象オブジェクト。

Mule Context (Mule コンテキスト) 通知

MuleContext

Mule コンテキスト ID

Mule コンテキストインスタンス。getMuleContext() のコールと同じ。

Routing (ルーティング) 通知

Message (メッセージ)

メッセージ ID

送信または受信されたメッセージ。

Security (セキュリティ) 通知

SecurityException

例外メッセージ。

発生したセキュリティ例外。

Transaction (トランザクション) 通知

String (文字列)

トランザクション ID

この通知をトリガーしたトランザクション。

Async-Message (非同期メッセージ) 通知

ComponentLocation

コンポーネント名

非同期作業をスケジュールしたコンポーネント。

Pipeline-Message (パイプラインメッセージ) 通知

String (文字列)

Name (名前)

パイプライン名。

Message-Processor (メッセージプロセッサー) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Exception Strategy (例外戦略) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Extension (拡張機能) 通知

Object (オブジェクト)

Extension name (拡張名)

ペイロードは拡張機能ごとに変更できます。

Connector-Message (コネクタメッセージ) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。
# Mule サーバーの通知 Mule には、フローコンポーネントの追加、認証の要求失敗、Mule の起動など、Mule サーバーで行われた変更を確認するために使用できる内部通知メカニズムがあります。こうした通知に反応するためのエージェントまたはフローコンポーネントをセットアップできます。 ## [](#通知の設定)通知の設定 メッセージ通知は、Mule サーバーとの間で送信されるすべての情報のスナップショットとなります。Mule はメッセージを送受信したときにこうした通知を実行します。こうした追加の通知はパフォーマンスに影響を及ぼすため、デフォルトで無効になっています。メッセージ通知を有効にするには、Mule 設定ファイルで ​``​ 要素を使用して有効にするメッセージの種別を設定します。また、通知リスナーを登録してインターフェースを特定の通知に関連付けます。 たとえば、最初に Spring 設定ファイルで通知リスナーの Bean を作成し、受信する通知の種別のクラスを指定します。 ```xml ``` 続いて、Spring 設定の参照を追加します。 ```xml ``` 次に、​``​ 要素を使用して受信する通知を指定し、​``​ 要素を使用してリスナーを登録します。 ```xml ``` MESSAGE-PROCESSOR 通知を指定すると、通知はメッセージプロセッサーが呼び出される前と後に送信されます。リスナーは受信する通知の種別のインターフェースを実装しているため、リスナーは正しい通知を受信します。 たとえば、​`ProcessorNotificationLogger`​ クラスは ​`org.mule.runtime.api.notification.MessageProcessorNotificationListener`​ を実装します。 ```java public class ProcessorNotificationLogger implements MessageProcessorNotificationListener { @Override public void onNotification(MessageProcessorNotification notification) { // write here the logic to process the notification event } } ```
API クラスをクラスパスで使用できるように、忘れずに ​provided​ をスコープとして POM ファイルで Mule と API の連動関係を追加してください。この連動関係は実行時に Mule によって提供されます。
通知種別のリストについては、​[「通知設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.7/notifications-configuration-reference)​を参照してください。通知リスナーインターフェースのリストについては、下記の​[\[Notification Interfaces\]](<#Notification Interfaces>)​を参照してください。 ### [](#別のインターフェースの指定)別のインターフェースの指定 通知に関連付けられたインターフェースを変更するには、​`interface-class`​ 属性で新しいインターフェースを指定します。 ```xml ``` ### [](#カスタム通知の設定)カスタム通知の設定 カスタム通知を作成する場合、​`event-class`​ 属性も指定します。 ```xml ``` ### [](#通知の無効化)通知の無効化 特定のインターフェースが通知を受信しないようにブロックするには、​``​ 要素で指定します。ブロックする通知種別 (イベント)、イベントクラス、インターフェース、インターフェースクラスを指定できます。 ```xml ``` ### [](#サブスクリプションの使用)サブスクリプションの使用 リスナーを登録するときに、​`subscription`​ 属性を使用して特定のコンポーネントからの通知のみを受信するように指定できます。たとえば、「MyService1」という名前のフローコンポーネントからのみ通知を受信するようにリスナーを指定するには、次のようにリスナーを設定します。 ```xml ``` 名前に「Service」が付くすべてのフローコンポーネントからの通知の受信に登録するには、次のようにワイルドカード文字列を使用します。 詳細は、下記の​[\[Registering Listeners Programmatically\]](<#Registering Listeners Programmatically>)​を参照してください。 ## [](#カスタム通知の実行)カスタム通知の実行 オブジェクトは Mule でカスタム通知を実行し、カスタムリスナーに通知できます。たとえば、検出エージェントはクライアントが接続したときに「Client Found (クライアントが見つかりました)」という通知を実行する場合もあります。 カスタム通知は次のように実行します。 ```text CustomNotification n = new CustomNotification("Hello"); notificationDispatcher.dispatch(n); ``` `CustomNotificationListener`​ を実装するオブジェクトがこの通知を受信します。​`CustomNotification`​ を拡張して、カスタム通知種別のアクションを定義すると良いでしょう。例: ```text DiscoveryNotification n = new DiscoveryNotification(client, DiscoveryNotification.CLIENT_ADDED); notificationDispatcher.dispatch(n); ``` ## [](#通知インターフェース)通知インターフェース 次の表は、​`org.mule.runtime.api.notification`​ パッケージの Mule サーバー通知とインターフェースを示しています。オブジェクトは、これらのインターフェースのいずれかを実装して関連付けられた通知のリスナーになることができます。すべてのリスナーは ​`NotificationListener`​ インターフェースを拡張します。
Notification (通知) 説明 インターフェース

Connection (接続) 通知

接続が行われるか切断されたときに実行されます。

ConnectionNotificationListener​

Custom (カスタム) 通知

コンポーネントの他、ルーター、トランスフォーマー、エージェントなどのオブジェクトによって相互の状態の変更を通信するために実行される場合があります。

CustomNotificationListener​

Exception (例外) 通知

例外がスローされました。

ExceptionNotificationListener​

Management (管理) 通知

内部キューが容量に達するなど、Mule インスタンスまたはそのリソースの状態が変更されました。

ManagementNotificationListener​

Mule Context (Mule コンテキスト) 通知

Mule コンテキストの開始などのイベントが発生したときに実行できます。

MuleContextNotificationListener​

Routing (ルーティング) 通知

Async-Reply (非同期返信) ルーターは、すでに処理されたイベントグループについてイベントが受信されたときにこの通知を使用します。

RoutingNotificationListener​

Security (セキュリティ) 通知

認証の要求が失敗したときに実行されます。

SecurityNotificationListener​

Transaction (トランザクション) 通知

トランザクションが開始された、コミットされた、ロールバックされた後に実行されます。

TransactionNotificationListener​

Async-Message (非同期メッセージ) 通知

非同期作業がスケジュールされ、指定されたフローについて完了したときに実行できます。

AsyncMessageNotificationListener​

Pipeline-Message (パイプラインメッセージ) 通知

パイプラインの処理の重要なステップで実行されます。

PipelineMessageNotificationListener​

Message-Processor (メッセージプロセッサー) 通知

メッセージプロセッサーが呼び出されました。

MessageProcessorNotificationListener​

Exception Strategy (例外戦略) 通知

例外戦略が呼び出されました。

ExceptionStrategyNotificationListener​

Extension (拡張機能) 通知

カスタムデータを含む拡張機能によって実行できます。

ExtensionNotificationListener​

Connector-Message (コネクタメッセージ) 通知

メッセージが受信されたかコネクタを通じて送信されたときに実行されます。

ConnectorMessageNotificationListener​
リスナーインターフェースにはすべて単一のメソッドがあります。 ```java public void onNotification(T notification); ``` ここで、T は通知クラスです (末尾に「Listener」が付かないリスナークラス)。 実装されているリスナーに応じて、特定の通知のみが受信されます。たとえば、オブジェクトで ​`ManagementNotificationListener`​ が実装されている場合、種別 ​`ManagementNotification`​ の通知のみが受信されます。オブジェクトは複数のリスナーを実装して複数の種別の通知を受信できます。 ## [](#プログラムでのリスナーの登録)プログラムでのリスナーの登録 リスナーは次のように登録できます。 notificationListenerRegistry.registerListener(listener); または notificationListenerRegistry.registerListener(listener, selector); ここで、​`listener`​ は ​`NotificationListener`​ インスタンスであり、​`selector`​ はリスナーをコールする前に実行された通知に適用する検索条件として機能する ​`Predicate`​ です。 ## [](#通知アクションコード)通知アクションコード 各通知には、通知種別を決定するアクションコードがあります。アクションコードを問い合わせて、その種別を決定することができます。例: **MyObject.java** ```java public class MyObject implements ConnectionNotificationListener { (...) public void onNotification(ConnectionNotification notification) { if (valueOf(ConnectionNotification.CONNECTION_FAILED).equals(notification.getAction().getIdentifier())) { // write here the logic to handle the connection failed notification } } } ``` ## [](#通知ペイロード)通知ペイロード すべての通知は ​`java.util.EventObject`​ を拡張し、​`getSource()`​ メソッドを使用してオブジェクトのペイロードにアクセスできます。次の表で、通知の各種別のペイロードについて説明します。
Notification (通知) ペイロード種別 リソース ID 説明

Connection (接続) 通知

String (文字列)

<connector-name>.receiver(<endpoint-uri>)

接続されたメッセージレシーバーまたはメッセージディスパッチャー。

Custom (カスタム) 通知

任意のオブジェクト

任意の String (文字列)

オブジェクト種別は通知を実行したオブジェクトに対してカスタムです。

Exception (例外) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Management (管理) 通知

Object (オブジェクト)

オブジェクト ID

この通知をトリガーした監視対象オブジェクト。

Mule Context (Mule コンテキスト) 通知

MuleContext

Mule コンテキスト ID

Mule コンテキストインスタンス。getMuleContext() のコールと同じ。

Routing (ルーティング) 通知

Message (メッセージ)

メッセージ ID

送信または受信されたメッセージ。

Security (セキュリティ) 通知

SecurityException

例外メッセージ。

発生したセキュリティ例外。

Transaction (トランザクション) 通知

String (文字列)

トランザクション ID

この通知をトリガーしたトランザクション。

Async-Message (非同期メッセージ) 通知

ComponentLocation

コンポーネント名

非同期作業をスケジュールしたコンポーネント。

Pipeline-Message (パイプラインメッセージ) 通知

String (文字列)

Name (名前)

パイプライン名。

Message-Processor (メッセージプロセッサー) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Exception Strategy (例外戦略) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Extension (拡張機能) 通知

Object (オブジェクト)

Extension name (拡張名)

ペイロードは拡張機能ごとに変更できます。

Connector-Message (コネクタメッセージ) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。
# Mule サーバーの通知 Mule には、フローコンポーネントの追加、認証の要求失敗、Mule の起動など、Mule サーバーで行われた変更を確認するために使用できる内部通知メカニズムがあります。こうした通知に反応するためのエージェントまたはフローコンポーネントをセットアップできます。 ## [](#通知の設定)通知の設定 メッセージ通知は、Mule サーバーとの間で送信されるすべての情報のスナップショットとなります。Mule はメッセージを送受信したときにこうした通知を実行します。こうした追加の通知はパフォーマンスに影響を及ぼすため、デフォルトで無効になっています。メッセージ通知を有効にするには、Mule 設定ファイルで ​``​ 要素を使用して有効にするメッセージの種別を設定します。また、通知リスナーを登録してインターフェースを特定の通知に関連付けます。 たとえば、最初に Spring 設定ファイルで通知リスナーの Bean を作成し、受信する通知の種別のクラスを指定します。 ```xml ``` 続いて、Spring 設定の参照を追加します。 ```xml ``` 次に、​``​ 要素を使用して受信する通知を指定し、​``​ 要素を使用してリスナーを登録します。 ```xml ``` MESSAGE-PROCESSOR 通知を指定すると、通知はメッセージプロセッサーが呼び出される前と後に送信されます。リスナーは受信する通知の種別のインターフェースを実装しているため、リスナーは正しい通知を受信します。 たとえば、​`ProcessorNotificationLogger`​ クラスは ​`org.mule.runtime.api.notification.MessageProcessorNotificationListener`​ を実装します。 ```java public class ProcessorNotificationLogger implements MessageProcessorNotificationListener { @Override public void onNotification(MessageProcessorNotification notification) { // write here the logic to process the notification event } } ```
API クラスをクラスパスで使用できるように、忘れずに ​provided​ をスコープとして POM ファイルで Mule と API の連動関係を追加してください。この連動関係は実行時に Mule によって提供されます。
通知種別のリストについては、​[「通知設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.8/notifications-configuration-reference)​を参照してください。通知リスナーインターフェースのリストについては、下記の​[\[Notification Interfaces\]](<#Notification Interfaces>)​を参照してください。 ### [](#別のインターフェースの指定)別のインターフェースの指定 通知に関連付けられたインターフェースを変更するには、​`interface-class`​ 属性で新しいインターフェースを指定します。 ```xml ``` ### [](#カスタム通知の設定)カスタム通知の設定 カスタム通知を作成する場合、​`event-class`​ 属性も指定します。 ```xml ``` ### [](#通知の無効化)通知の無効化 特定のインターフェースが通知を受信しないようにブロックするには、​``​ 要素で指定します。ブロックする通知種別 (イベント)、イベントクラス、インターフェース、インターフェースクラスを指定できます。 ```xml ``` ### [](#サブスクリプションの使用)サブスクリプションの使用 リスナーを登録するときに、​`subscription`​ 属性を使用して特定のコンポーネントからの通知のみを受信するように指定できます。たとえば、「MyService1」という名前のフローコンポーネントからのみ通知を受信するようにリスナーを指定するには、次のようにリスナーを設定します。 ```xml ``` 名前に「Service」が付くすべてのフローコンポーネントからの通知の受信に登録するには、次のようにワイルドカード文字列を使用します。 詳細は、下記の​[\[Registering Listeners Programmatically\]](<#Registering Listeners Programmatically>)​を参照してください。 ## [](#カスタム通知の実行)カスタム通知の実行 オブジェクトは Mule でカスタム通知を実行し、カスタムリスナーに通知できます。たとえば、検出エージェントはクライアントが接続したときに「Client Found (クライアントが見つかりました)」という通知を実行する場合もあります。 カスタム通知は次のように実行します。 ```text CustomNotification n = new CustomNotification("Hello"); notificationDispatcher.dispatch(n); ``` `CustomNotificationListener`​ を実装するオブジェクトがこの通知を受信します。​`CustomNotification`​ を拡張して、カスタム通知種別のアクションを定義すると良いでしょう。例: ```text DiscoveryNotification n = new DiscoveryNotification(client, DiscoveryNotification.CLIENT_ADDED); notificationDispatcher.dispatch(n); ``` ## [](#通知インターフェース)通知インターフェース 次の表は、​`org.mule.runtime.api.notification`​ パッケージの Mule サーバー通知とインターフェースを示しています。オブジェクトは、これらのインターフェースのいずれかを実装して関連付けられた通知のリスナーになることができます。すべてのリスナーは ​`NotificationListener`​ インターフェースを拡張します。
Notification (通知) 説明 インターフェース

Connection (接続) 通知

接続が行われるか切断されたときに実行されます。

ConnectionNotificationListener​

Custom (カスタム) 通知

コンポーネントの他、ルーター、トランスフォーマー、エージェントなどのオブジェクトによって相互の状態の変更を通信するために実行される場合があります。

CustomNotificationListener​

Exception (例外) 通知

例外がスローされました。

ExceptionNotificationListener​

Management (管理) 通知

内部キューが容量に達するなど、Mule インスタンスまたはそのリソースの状態が変更されました。

ManagementNotificationListener​

Mule Context (Mule コンテキスト) 通知

Mule コンテキストの開始などのイベントが発生したときに実行できます。

MuleContextNotificationListener​

Routing (ルーティング) 通知

Async-Reply (非同期返信) ルーターは、すでに処理されたイベントグループについてイベントが受信されたときにこの通知を使用します。

RoutingNotificationListener​

Security (セキュリティ) 通知

認証の要求が失敗したときに実行されます。

SecurityNotificationListener​

Transaction (トランザクション) 通知

トランザクションが開始された、コミットされた、ロールバックされた後に実行されます。

TransactionNotificationListener​

Async-Message (非同期メッセージ) 通知

非同期作業がスケジュールされ、指定されたフローについて完了したときに実行できます。

AsyncMessageNotificationListener​

Pipeline-Message (パイプラインメッセージ) 通知

パイプラインの処理の重要なステップで実行されます。

PipelineMessageNotificationListener​

Message-Processor (メッセージプロセッサー) 通知

メッセージプロセッサーが呼び出されました。

MessageProcessorNotificationListener​

Exception Strategy (例外戦略) 通知

例外戦略が呼び出されました。

ExceptionStrategyNotificationListener​

Extension (拡張機能) 通知

カスタムデータを含む拡張機能によって実行できます。

ExtensionNotificationListener​

Connector-Message (コネクタメッセージ) 通知

メッセージが受信されたかコネクタを通じて送信されたときに実行されます。

ConnectorMessageNotificationListener​
リスナーインターフェースにはすべて単一のメソッドがあります。 ```java public void onNotification(T notification); ``` ここで、T は通知クラスです (末尾に「Listener」が付かないリスナークラス)。 実装されているリスナーに応じて、特定の通知のみが受信されます。たとえば、オブジェクトで ​`ManagementNotificationListener`​ が実装されている場合、種別 ​`ManagementNotification`​ の通知のみが受信されます。オブジェクトは複数のリスナーを実装して複数の種別の通知を受信できます。 ## [](#プログラムでのリスナーの登録)プログラムでのリスナーの登録 リスナーは次のように登録できます。 notificationListenerRegistry.registerListener(listener); または notificationListenerRegistry.registerListener(listener, selector); ここで、​`listener`​ は ​`NotificationListener`​ インスタンスであり、​`selector`​ はリスナーをコールする前に実行された通知に適用する検索条件として機能する ​`Predicate`​ です。 ## [](#通知アクションコード)通知アクションコード 各通知には、通知種別を決定するアクションコードがあります。アクションコードを問い合わせて、その種別を決定することができます。例: **MyObject.java** ```java public class MyObject implements ConnectionNotificationListener { (...) public void onNotification(ConnectionNotification notification) { if (valueOf(ConnectionNotification.CONNECTION_FAILED).equals(notification.getAction().getIdentifier())) { // write here the logic to handle the connection failed notification } } } ``` ## [](#通知ペイロード)通知ペイロード すべての通知は ​`java.util.EventObject`​ を拡張し、​`getSource()`​ メソッドを使用してオブジェクトのペイロードにアクセスできます。次の表で、通知の各種別のペイロードについて説明します。
Notification (通知) ペイロード種別 リソース ID 説明

Connection (接続) 通知

String (文字列)

<connector-name>.receiver(<endpoint-uri>)

接続されたメッセージレシーバーまたはメッセージディスパッチャー。

Custom (カスタム) 通知

任意のオブジェクト

任意の String (文字列)

オブジェクト種別は通知を実行したオブジェクトに対してカスタムです。

Exception (例外) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Management (管理) 通知

Object (オブジェクト)

オブジェクト ID

この通知をトリガーした監視対象オブジェクト。

Mule Context (Mule コンテキスト) 通知

MuleContext

Mule コンテキスト ID

Mule コンテキストインスタンス。getMuleContext() のコールと同じ。

Routing (ルーティング) 通知

Message (メッセージ)

メッセージ ID

送信または受信されたメッセージ。

Security (セキュリティ) 通知

SecurityException

例外メッセージ。

発生したセキュリティ例外。

Transaction (トランザクション) 通知

String (文字列)

トランザクション ID

この通知をトリガーしたトランザクション。

Async-Message (非同期メッセージ) 通知

ComponentLocation

コンポーネント名

非同期作業をスケジュールしたコンポーネント。

Pipeline-Message (パイプラインメッセージ) 通知

String (文字列)

Name (名前)

パイプライン名。

Message-Processor (メッセージプロセッサー) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Exception Strategy (例外戦略) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Extension (拡張機能) 通知

Object (オブジェクト)

Extension name (拡張名)

ペイロードは拡張機能ごとに変更できます。

Connector-Message (コネクタメッセージ) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。
# Mule サーバーの通知 Mule には、フローコンポーネントの追加、認証の要求失敗、Mule の起動など、Mule サーバーで行われた変更を確認するために使用できる内部通知メカニズムがあります。こうした通知に反応するためのエージェントまたはフローコンポーネントをセットアップできます。 ## [](#通知の設定)通知の設定 メッセージ通知は、Mule サーバーとの間で送信されるすべての情報のスナップショットとなります。Mule はメッセージを送受信したときにこうした通知を実行します。こうした追加の通知はパフォーマンスに影響を及ぼすため、デフォルトで無効になっています。メッセージ通知を有効にするには、Mule 設定ファイルで ​``​ 要素を使用して有効にするメッセージの種別を設定します。また、通知リスナーを登録してインターフェースを特定の通知に関連付けます。 たとえば、最初に Spring 設定ファイルで通知リスナーの Bean を作成し、受信する通知の種別のクラスを指定します。 ```xml ``` 続いて、Spring 設定の参照を追加します。 ```xml ``` 次に、​``​ 要素を使用して受信する通知を指定し、​``​ 要素を使用してリスナーを登録します。 ```xml ``` MESSAGE-PROCESSOR 通知を指定すると、通知はメッセージプロセッサーが呼び出される前と後に送信されます。リスナーは受信する通知の種別のインターフェースを実装しているため、リスナーは正しい通知を受信します。 たとえば、​`ProcessorNotificationLogger`​ クラスは ​`org.mule.runtime.api.notification.MessageProcessorNotificationListener`​ を実装します。 ```java public class ProcessorNotificationLogger implements MessageProcessorNotificationListener { @Override public void onNotification(MessageProcessorNotification notification) { // write here the logic to process the notification event } } ```
API クラスをクラスパスで使用できるように、忘れずに ​provided​ をスコープとして POM ファイルで Mule と API の連動関係を追加してください。この連動関係は実行時に Mule によって提供されます。
通知種別のリストについては、​[「通知設定リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.9/notifications-configuration-reference)​を参照してください。通知リスナーインターフェースのリストについては、下記の​[\[Notification Interfaces\]](<#Notification Interfaces>)​を参照してください。 ### [](#別のインターフェースの指定)別のインターフェースの指定 通知に関連付けられたインターフェースを変更するには、​`interface-class`​ 属性で新しいインターフェースを指定します。 ```xml ``` ### [](#カスタム通知の設定)カスタム通知の設定 カスタム通知を作成する場合、​`event-class`​ 属性も指定します。 ```xml ``` ### [](#通知の無効化)通知の無効化 特定のインターフェースが通知を受信しないようにブロックするには、​``​ 要素で指定します。ブロックする通知種別 (イベント)、イベントクラス、インターフェース、インターフェースクラスを指定できます。 ```xml ``` ### [](#サブスクリプションの使用)サブスクリプションの使用 リスナーを登録するときに、​`subscription`​ 属性を使用して特定のコンポーネントからの通知のみを受信するように指定できます。たとえば、「MyService1」という名前のフローコンポーネントからのみ通知を受信するようにリスナーを指定するには、次のようにリスナーを設定します。 ```xml ``` 名前に「Service」が付くすべてのフローコンポーネントからの通知の受信に登録するには、次のようにワイルドカード文字列を使用します。 詳細は、下記の​[\[Registering Listeners Programmatically\]](<#Registering Listeners Programmatically>)​を参照してください。 ## [](#カスタム通知の実行)カスタム通知の実行 オブジェクトは Mule でカスタム通知を実行し、カスタムリスナーに通知できます。たとえば、検出エージェントはクライアントが接続したときに「Client Found (クライアントが見つかりました)」という通知を実行する場合もあります。 カスタム通知は次のように実行します。 ```text CustomNotification n = new CustomNotification("Hello"); notificationDispatcher.dispatch(n); ``` `CustomNotificationListener`​ を実装するオブジェクトがこの通知を受信します。​`CustomNotification`​ を拡張して、カスタム通知種別のアクションを定義すると良いでしょう。例: ```text DiscoveryNotification n = new DiscoveryNotification(client, DiscoveryNotification.CLIENT_ADDED); notificationDispatcher.dispatch(n); ``` ## [](#通知インターフェース)通知インターフェース 次の表は、​`org.mule.runtime.api.notification`​ パッケージの Mule サーバー通知とインターフェースを示しています。オブジェクトは、これらのインターフェースのいずれかを実装して関連付けられた通知のリスナーになることができます。すべてのリスナーは ​`NotificationListener`​ インターフェースを拡張します。
Notification (通知) 説明 インターフェース

Connection (接続) 通知

接続が行われるか切断されたときに実行されます。

ConnectionNotificationListener​

Custom (カスタム) 通知

コンポーネントの他、ルーター、トランスフォーマー、エージェントなどのオブジェクトによって相互の状態の変更を通信するために実行される場合があります。

CustomNotificationListener​

Exception (例外) 通知

例外がスローされました。

ExceptionNotificationListener​

Management (管理) 通知

内部キューが容量に達するなど、Mule インスタンスまたはそのリソースの状態が変更されました。

ManagementNotificationListener​

Mule Context (Mule コンテキスト) 通知

Mule コンテキストの開始などのイベントが発生したときに実行できます。

MuleContextNotificationListener​

Routing (ルーティング) 通知

Async-Reply (非同期返信) ルーターは、すでに処理されたイベントグループについてイベントが受信されたときにこの通知を使用します。

RoutingNotificationListener​

Security (セキュリティ) 通知

認証の要求が失敗したときに実行されます。

SecurityNotificationListener​

Transaction (トランザクション) 通知

トランザクションが開始された、コミットされた、ロールバックされた後に実行されます。

TransactionNotificationListener​

Async-Message (非同期メッセージ) 通知

非同期作業がスケジュールされ、指定されたフローについて完了したときに実行できます。

AsyncMessageNotificationListener​

Pipeline-Message (パイプラインメッセージ) 通知

パイプラインの処理の重要なステップで実行されます。

PipelineMessageNotificationListener​

Message-Processor (メッセージプロセッサー) 通知

メッセージプロセッサーが呼び出されました。

MessageProcessorNotificationListener​

Exception Strategy (例外戦略) 通知

例外戦略が呼び出されました。

ExceptionStrategyNotificationListener​

Extension (拡張機能) 通知

カスタムデータを含む拡張機能によって実行できます。

ExtensionNotificationListener​

Connector-Message (コネクタメッセージ) 通知

メッセージが受信されたかコネクタを通じて送信されたときに実行されます。

ConnectorMessageNotificationListener​
リスナーインターフェースにはすべて単一のメソッドがあります。 ```java public void onNotification(T notification); ``` ここで、T は通知クラスです (末尾に「Listener」が付かないリスナークラス)。 実装されているリスナーに応じて、特定の通知のみが受信されます。たとえば、オブジェクトで ​`ManagementNotificationListener`​ が実装されている場合、種別 ​`ManagementNotification`​ の通知のみが受信されます。オブジェクトは複数のリスナーを実装して複数の種別の通知を受信できます。 ## [](#プログラムでのリスナーの登録)プログラムでのリスナーの登録 リスナーは次のように登録できます。 notificationListenerRegistry.registerListener(listener); または notificationListenerRegistry.registerListener(listener, selector); ここで、​`listener`​ は ​`NotificationListener`​ インスタンスであり、​`selector`​ はリスナーをコールする前に実行された通知に適用する検索条件として機能する ​`Predicate`​ です。 ## [](#通知アクションコード)通知アクションコード 各通知には、通知種別を決定するアクションコードがあります。アクションコードを問い合わせて、その種別を決定することができます。例: **MyObject.java** ```java public class MyObject implements ConnectionNotificationListener { (...) public void onNotification(ConnectionNotification notification) { if (valueOf(ConnectionNotification.CONNECTION_FAILED).equals(notification.getAction().getIdentifier())) { // write here the logic to handle the connection failed notification } } } ``` ## [](#通知ペイロード)通知ペイロード すべての通知は ​`java.util.EventObject`​ を拡張し、​`getSource()`​ メソッドを使用してオブジェクトのペイロードにアクセスできます。次の表で、通知の各種別のペイロードについて説明します。
Notification (通知) ペイロード種別 リソース ID 説明

Connection (接続) 通知

String (文字列)

<connector-name>.receiver(<endpoint-uri>)

接続されたメッセージレシーバーまたはメッセージディスパッチャー。

Custom (カスタム) 通知

任意のオブジェクト

任意の String (文字列)

オブジェクト種別は通知を実行したオブジェクトに対してカスタムです。

Exception (例外) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Management (管理) 通知

Object (オブジェクト)

オブジェクト ID

この通知をトリガーした監視対象オブジェクト。

Mule Context (Mule コンテキスト) 通知

MuleContext

Mule コンテキスト ID

Mule コンテキストインスタンス。getMuleContext() のコールと同じ。

Routing (ルーティング) 通知

Message (メッセージ)

メッセージ ID

送信または受信されたメッセージ。

Security (セキュリティ) 通知

SecurityException

例外メッセージ。

発生したセキュリティ例外。

Transaction (トランザクション) 通知

String (文字列)

トランザクション ID

この通知をトリガーしたトランザクション。

Async-Message (非同期メッセージ) 通知

ComponentLocation

コンポーネント名

非同期作業をスケジュールしたコンポーネント。

Pipeline-Message (パイプラインメッセージ) 通知

String (文字列)

Name (名前)

パイプライン名。

Message-Processor (メッセージプロセッサー) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Exception Strategy (例外戦略) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。

Extension (拡張機能) 通知

Object (オブジェクト)

Extension name (拡張名)

ペイロードは拡張機能ごとに変更できます。

Connector-Message (コネクタメッセージ) 通知

ComponentLocation

コンポーネント名

通知をトリガーしたフローコンポーネント。
# Mule セキュアトークンサービス OAuth 2.0 Mule Runtime Engine は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、OAuth ロールおよび目的に応じて異なります。 - Github OAuth2 サーバーなど、認証が必要なサービスに要求を送信する場合は、クライアント Mule アプリケーションで認証を設定します。OAuth2 設定には ​[OAuth Module](https://docs.mulesoft.com/jp/oauth-module/latest/oauth-module-reference)​ を使用します。 - [Mule OAuth2 プロバイダーコネクタ](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​を使用して、保護されたリソースにアクセスするために必要なトークンを付与して検証する Mule アプリケーションを作成します。 API またはアプリケーションが不正な要求を受信しないように保護するには、​`OAuth 2.0 Access Token Enforcement Using External Provider`​ ポリシーなどの API Manager ポリシーを使用します。OAuth 2.0 セキュリティによって保護される Web サービスを公開するには、​[API Manager のドキュメント](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page)​を参照してください。 ## [](#関連情報)関連情報 - [OAuth 認証許可種別](https://docs.mulesoft.com/jp/mule-runtime/4.3/authorization-grant-types) # Mule セキュアトークンサービス OAuth 2.0 Mule Runtime Engine は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、OAuth ロールおよび目的に応じて異なります。 - Github OAuth2 サーバーなど、認証が必要なサービスに要求を送信する場合は、クライアント Mule アプリケーションで認証を設定します。OAuth2 設定には ​[OAuth Module](https://docs.mulesoft.com/jp/oauth-module/latest/oauth-module-reference)​ を使用します。 - [Mule OAuth2 プロバイダーコネクタ](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​を使用して、保護されたリソースにアクセスするために必要なトークンを付与して検証する Mule アプリケーションを作成します。 API またはアプリケーションが不正な要求を受信しないように保護するには、​`OAuth 2.0 Access Token Enforcement Using External Provider`​ ポリシーなどの API Manager ポリシーを使用します。OAuth 2.0 セキュリティによって保護される Web サービスを公開するには、​[API Manager のドキュメント](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page)​を参照してください。 ## [](#関連情報)関連情報 - [OAuth 認証許可種別](https://docs.mulesoft.com/jp/mule-runtime/4.4/authorization-grant-types) # Mule セキュアトークンサービス OAuth 2.0 Mule Runtime Engine は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、OAuth ロールおよび目的に応じて異なります。 - Github OAuth2 サーバーなど、認証が必要なサービスに要求を送信する場合は、クライアント Mule アプリケーションで認証を設定します。OAuth2 設定には ​[OAuth モジュール](https://docs.mulesoft.com/jp/oauth-module/latest/oauth-module-reference)​を使用します。 - [Mule OAuth2 プロバイダーコネクタ](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​を使用して、保護されたリソースにアクセスするために必要なトークンを付与して検証する Mule アプリケーションを作成します。 API またはアプリケーションが不正な要求を受信しないように保護するには、​`OAuth 2.0 Access Token Enforcement Using External Provider`​ ポリシーなどの API Manager ポリシーを使用します。OAuth 2.0 セキュリティによって保護される Web サービスを公開するには、​[API Manager のドキュメント](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page)​を参照してください。 ## [](#関連情報)関連情報 - [OAuth 認証許可種別](https://docs.mulesoft.com/jp/mule-runtime/4.5/authorization-grant-types) # Mule セキュアトークンサービス OAuth 2.0 Mule Runtime Engine は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、OAuth ロールおよび目的に応じて異なります。 - Github OAuth2 サーバーなど、認証が必要なサービスに要求を送信する場合は、クライアント Mule アプリケーションで認証を設定します。OAuth2 設定には ​[OAuth Module](https://docs.mulesoft.com/jp/oauth-module/latest/oauth-module-reference)​ を使用します。 - [Mule OAuth2 プロバイダーコネクタ](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​を使用して、保護されたリソースにアクセスするために必要なトークンを付与して検証する Mule アプリケーションを作成します。 API またはアプリケーションが不正な要求を受信しないように保護するには、​`OAuth 2.0 Access Token Enforcement Using External Provider`​ ポリシーなどの API Manager ポリシーを使用します。OAuth 2.0 セキュリティによって保護される Web サービスを公開するには、​[API Manager のドキュメント](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page)​を参照してください。 ## [](#関連情報)関連情報 - [OAuth 認証許可種別](https://docs.mulesoft.com/jp/mule-runtime/4.6/authorization-grant-types) # Mule セキュアトークンサービス OAuth 2.0 Mule Runtime Engine は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、OAuth ロールおよび目的に応じて異なります。 - Github OAuth2 サーバーなど、認証が必要なサービスに要求を送信する場合は、クライアント Mule アプリケーションで認証を設定します。OAuth2 設定には ​[OAuth Module](https://docs.mulesoft.com/jp/oauth-module/latest/oauth-module-reference)​ を使用します。 - [Mule OAuth2 プロバイダーコネクタ](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​を使用して、保護されたリソースにアクセスするために必要なトークンを付与して検証する Mule アプリケーションを作成します。 API またはアプリケーションが不正な要求を受信しないように保護するには、​`OAuth 2.0 Access Token Enforcement Using External Provider`​ ポリシーなどの API Manager ポリシーを使用します。OAuth 2.0 セキュリティによって保護される Web サービスを公開するには、​[API Manager のドキュメント](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page)​を参照してください。 ## [](#関連情報)関連情報 - [OAuth 認証許可種別](https://docs.mulesoft.com/jp/mule-runtime/4.7/authorization-grant-types) # Mule セキュアトークンサービス OAuth 2.0 Mule Runtime Engine は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、OAuth ロールおよび目的に応じて異なります。 - Github OAuth2 サーバーなど、認証が必要なサービスに要求を送信する場合は、クライアント Mule アプリケーションで認証を設定します。OAuth2 設定には ​[OAuth Module](https://docs.mulesoft.com/jp/oauth-module/latest/oauth-module-reference)​ を使用します。 - [Mule OAuth2 プロバイダーコネクタ](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​を使用して、保護されたリソースにアクセスするために必要なトークンを付与して検証する Mule アプリケーションを作成します。 API またはアプリケーションが不正な要求を受信しないように保護するには、​`OAuth 2.0 Access Token Enforcement Using External Provider`​ ポリシーなどの API Manager ポリシーを使用します。OAuth 2.0 セキュリティによって保護される Web サービスを公開するには、​[API Manager のドキュメント](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page)​を参照してください。 ## [](#関連情報)関連情報 - [OAuth 認証許可種別](https://docs.mulesoft.com/jp/mule-runtime/4.8/authorization-grant-types) # Mule セキュアトークンサービス OAuth 2.0 Mule Runtime Engine は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、OAuth ロールおよび目的に応じて異なります。 - Github OAuth2 サーバーなど、認証が必要なサービスに要求を送信する場合は、クライアント Mule アプリケーションで認証を設定します。OAuth2 設定には ​[OAuth Module](https://docs.mulesoft.com/jp/oauth-module/latest/oauth-module-reference)​ を使用します。 - [Mule OAuth2 プロバイダーコネクタ](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference)​を使用して、保護されたリソースにアクセスするために必要なトークンを付与して検証する Mule アプリケーションを作成します。 API またはアプリケーションが不正な要求を受信しないように保護するには、​`OAuth 2.0 Access Token Enforcement Using External Provider`​ ポリシーなどの API Manager ポリシーを使用します。OAuth 2.0 セキュリティによって保護される Web サービスを公開するには、​[API Manager のドキュメント](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page)​を参照してください。 ## [](#関連情報)関連情報 - [OAuth 認証許可種別](https://docs.mulesoft.com/jp/mule-runtime/4.9/authorization-grant-types) # Mule データ型 Mule Runtime Engine では、さまざまなコンポーネントのデータアクセスを一元化する ​`TypedValue`​ という型付けされたデータ構造を使用します。このデータ構造は実際のデータとそのデータ型の両方へのアクセスを提供します。データ型は 2 つの値 (MIME タイプとデータのエンコード) で構成されます。 ## [](#入力データ)入力データ Mule は ​`TypedValue`​ データ構造を使用してすべての変数とペイロードを保存します。また、Anypoint Platform File Connector からの ​`List`​ のような操作では、結果が ​`TypedValue`​ インスタンスで返されるため、DataWeave は読み込むさまざまな種別のファイル (JSON、XML、CSV など) をリストできます。 ## [](#出力データ)出力データ DataWeave では常に ​`TypedValue`​ インスタンスが出力されます。また、使用するライターが ​`TypedValue`​ インスタンスのデータ型に基づいて判断されます。ただし、DataWeave スクリプトで ​`output`​ ディレクティブを使用してデータ型を手動で指定できます。 Mule が実行しているスクリプトがメッセージ処理項目に割り当てられている場合、Mule から DataWeave にその項目のメタデータに基づいてどのデータ型を想定すべきかが伝えられます。たとえば、データ型が Plain Old Java Object (Pojo) の場合、DataWeave はインスタンス化するクラスだけでなく、Java ライターを使用して出力を生成する必要があることも把握できます。 ## [](#dataweave-での-mule-データ型の使用方法)DataWeave での Mule データ型の使用方法 DataWeave は ​`TypedValue`​ インスタンスに含まれるデータ型を使用し、MIME タイプに基づいて使用すべきリーダー、MIME タイププロパティに基づいてそのリーダーの設定方法 (エンコード、リーダープロパティ) を決定します。 データ型を決定できない場合、DataWeave は次の手順に従います。 1. スクリプトが使用している入力種別を確認する。 すべての入力が互換か同じデータ型の場合、DataWeave はそのデータ型を使用します。たとえば、スクリプトに ​``​ が含まれていて、その ​`vars.myBar`​ が XML 型で ​`payload`​ が JSON 型の場合、DataWeave はエラーをスローします。場合によっては、特に XML を操作するときには、Set Payload 操作の式は、無効な XML 構造が生成されたために失敗します。 2. 入力が使用されない場合、DataWeave は Java ライターを使用する。 たとえば、DataWeave がスクリプト ​` # Mule データ型 Mule Runtime Engine では、さまざまなコンポーネントのデータアクセスを一元化する ​`TypedValue`​ という型付けされたデータ構造を使用します。このデータ構造は実際のデータとそのデータ型の両方へのアクセスを提供します。データ型は 2 つの値 (MIME タイプとデータのエンコード) で構成されます。 ## [](#入力データ)入力データ Mule は ​`TypedValue`​ データ構造を使用してすべての変数とペイロードを保存します。また、Anypoint Platform File Connector からの ​`List`​ のような操作では、結果が ​`TypedValue`​ インスタンスで返されるため、DataWeave は読み込むさまざまな種別のファイル (JSON、XML、CSV など) をリストできます。 ## [](#出力データ)出力データ DataWeave では常に ​`TypedValue`​ インスタンスが出力されます。また、使用するライターが ​`TypedValue`​ インスタンスのデータ型に基づいて判断されます。ただし、DataWeave スクリプトで ​`output`​ ディレクティブを使用してデータ型を手動で指定できます。 Mule が実行しているスクリプトがメッセージ処理項目に割り当てられている場合、Mule から DataWeave にその項目のメタデータに基づいてどのデータ型を想定すべきかが伝えられます。たとえば、データ型が Plain Old Java Object (Pojo) の場合、DataWeave はインスタンス化するクラスだけでなく、Java ライターを使用して出力を生成する必要があることも把握できます。 ## [](#dataweave-での-mule-データ型の使用方法)DataWeave での Mule データ型の使用方法 DataWeave は ​`TypedValue`​ インスタンスに含まれるデータ型を使用し、MIME タイプに基づいて使用すべきリーダー、MIME タイププロパティに基づいてそのリーダーの設定方法 (エンコード、リーダープロパティ) を決定します。 データ型を決定できない場合、DataWeave は次の手順に従います。 1. スクリプトが使用している入力種別を確認する。 すべての入力が互換か同じデータ型の場合、DataWeave はそのデータ型を使用します。たとえば、スクリプトに ​``​ が含まれていて、その ​`vars.myBar`​ が XML 型で ​`payload`​ が JSON 型の場合、DataWeave はエラーをスローします。場合によっては、特に XML を操作するときには、Set Payload 操作の式は、無効な XML 構造が生成されたために失敗します。 2. 入力が使用されない場合、DataWeave は Java ライターを使用する。 たとえば、DataWeave がスクリプト ​` # Mule データ型 Mule Runtime Engine では、さまざまなコンポーネントのデータアクセスを一元化する ​`TypedValue`​ という型付けされたデータ構造を使用します。このデータ構造は実際のデータとそのデータ型の両方へのアクセスを提供します。データ型は 2 つの値 (MIME タイプとデータのエンコード) で構成されます。 ## [](#入力データ)入力データ Mule は ​`TypedValue`​ データ構造を使用してすべての変数とペイロードを保存します。また、Anypoint Platform File Connector からの ​`List`​ のような操作では、結果が ​`TypedValue`​ インスタンスで返されるため、DataWeave は読み込むさまざまな種別のファイル (JSON、XML、CSV など) をリストできます。 ## [](#出力データ)出力データ DataWeave では常に ​`TypedValue`​ インスタンスが出力されます。また、使用するライターが ​`TypedValue`​ インスタンスのデータ型に基づいて判断されます。ただし、DataWeave スクリプトで ​`output`​ ディレクティブを使用してデータ型を手動で指定できます。 Mule が実行しているスクリプトがメッセージ処理項目に割り当てられている場合、Mule から DataWeave にその項目のメタデータに基づいてどのデータ型を想定すべきかが伝えられます。たとえば、データ型が Plain Old Java Object (Pojo) の場合、DataWeave はインスタンス化するクラスだけでなく、Java ライターを使用して出力を生成する必要があることも把握できます。 ## [](#dataweave-での-mule-データ型の使用方法)DataWeave での Mule データ型の使用方法 DataWeave は ​`TypedValue`​ インスタンスに含まれるデータ型を使用し、MIME タイプに基づいて使用すべきリーダー、MIME タイププロパティに基づいてそのリーダーの設定方法 (エンコード、リーダープロパティ) を決定します。 データ型を決定できない場合、DataWeave は次の手順に従います。 1. スクリプトが使用している入力種別を確認する。 すべての入力が互換か同じデータ型の場合、DataWeave はそのデータ型を使用します。たとえば、スクリプトに ​``​ が含まれていて、その ​`vars.myBar`​ が XML 型で ​`payload`​ が JSON 型の場合、DataWeave はエラーをスローします。場合によっては、特に XML を操作するときには、Set Payload 操作の式は、無効な XML 構造が生成されたために失敗します。 2. 入力が使用されない場合、DataWeave は Java ライターを使用する。 たとえば、DataWeave がスクリプト ​` # Mule データ型 Mule Runtime Engine では、さまざまなコンポーネントのデータアクセスを一元化する ​`TypedValue`​ という型付けされたデータ構造を使用します。このデータ構造は実際のデータとそのデータ型の両方へのアクセスを提供します。データ型は 2 つの値 (MIME タイプとデータのエンコード) で構成されます。 ## [](#入力データ)入力データ Mule は ​`TypedValue`​ データ構造を使用してすべての変数とペイロードを保存します。また、Anypoint Platform File Connector からの ​`List`​ のような操作では、結果が ​`TypedValue`​ インスタンスで返されるため、DataWeave は読み込むさまざまな種別のファイル (JSON、XML、CSV など) をリストできます。 ## [](#出力データ)出力データ DataWeave では常に ​`TypedValue`​ インスタンスが出力されます。また、使用するライターが ​`TypedValue`​ インスタンスのデータ型に基づいて判断されます。ただし、DataWeave スクリプトで ​`output`​ ディレクティブを使用してデータ型を手動で指定できます。 Mule が実行しているスクリプトがメッセージ処理項目に割り当てられている場合、Mule から DataWeave にその項目のメタデータに基づいてどのデータ型を想定すべきかが伝えられます。たとえば、データ型が Plain Old Java Object (Pojo) の場合、DataWeave はインスタンス化するクラスだけでなく、Java ライターを使用して出力を生成する必要があることも把握できます。 ## [](#dataweave-での-mule-データ型の使用方法)DataWeave での Mule データ型の使用方法 DataWeave は ​`TypedValue`​ インスタンスに含まれるデータ型を使用し、MIME タイプに基づいて使用すべきリーダー、MIME タイププロパティに基づいてそのリーダーの設定方法 (エンコード、リーダープロパティ) を決定します。 データ型を決定できない場合、DataWeave は次の手順に従います。 1. スクリプトが使用している入力種別を確認する。 すべての入力が互換か同じデータ型の場合、DataWeave はそのデータ型を使用します。たとえば、スクリプトに ​``​ が含まれていて、その ​`vars.myBar`​ が XML 型で ​`payload`​ が JSON 型の場合、DataWeave はエラーをスローします。場合によっては、特に XML を操作するときには、Set Payload 操作の式は、無効な XML 構造が生成されたために失敗します。 2. 入力が使用されない場合、DataWeave は Java ライターを使用する。 たとえば、DataWeave がスクリプト ​` # Mule データ型 Mule Runtime Engine では、さまざまなコンポーネントのデータアクセスを一元化する ​`TypedValue`​ という型付けされたデータ構造を使用します。このデータ構造は実際のデータとそのデータ型の両方へのアクセスを提供します。データ型は 2 つの値 (MIME タイプとデータのエンコード) で構成されます。 ## [](#入力データ)入力データ Mule は ​`TypedValue`​ データ構造を使用してすべての変数とペイロードを保存します。また、Anypoint Platform File Connector からの ​`List`​ のような操作では、結果が ​`TypedValue`​ インスタンスで返されるため、DataWeave は読み込むさまざまな種別のファイル (JSON、XML、CSV など) をリストできます。 ## [](#出力データ)出力データ DataWeave では常に ​`TypedValue`​ インスタンスが出力されます。また、使用するライターが ​`TypedValue`​ インスタンスのデータ型に基づいて判断されます。ただし、DataWeave スクリプトで ​`output`​ ディレクティブを使用してデータ型を手動で指定できます。 Mule が実行しているスクリプトがメッセージ処理項目に割り当てられている場合、Mule から DataWeave にその項目のメタデータに基づいてどのデータ型を想定すべきかが伝えられます。たとえば、データ型が Plain Old Java Object (Pojo) の場合、DataWeave はインスタンス化するクラスだけでなく、Java ライターを使用して出力を生成する必要があることも把握できます。 ## [](#dataweave-での-mule-データ型の使用方法)DataWeave での Mule データ型の使用方法 DataWeave は ​`TypedValue`​ インスタンスに含まれるデータ型を使用し、MIME タイプに基づいて使用すべきリーダー、MIME タイププロパティに基づいてそのリーダーの設定方法 (エンコード、リーダープロパティ) を決定します。 データ型を決定できない場合、DataWeave は次の手順に従います。 1. スクリプトが使用している入力種別を確認する。 すべての入力が互換か同じデータ型の場合、DataWeave はそのデータ型を使用します。たとえば、スクリプトに ​``​ が含まれていて、その ​`vars.myBar`​ が XML 型で ​`payload`​ が JSON 型の場合、DataWeave はエラーをスローします。場合によっては、特に XML を操作するときには、Set Payload 操作の式は、無効な XML 構造が生成されたために失敗します。 2. 入力が使用されない場合、DataWeave は Java ライターを使用する。 たとえば、DataWeave がスクリプト ​` # Mule データ型 Mule Runtime Engine では、さまざまなコンポーネントのデータアクセスを一元化する ​`TypedValue`​ という型付けされたデータ構造を使用します。このデータ構造は実際のデータとそのデータ型の両方へのアクセスを提供します。データ型は 2 つの値 (MIME タイプとデータのエンコード) で構成されます。 ## [](#入力データ)入力データ Mule は ​`TypedValue`​ データ構造を使用してすべての変数とペイロードを保存します。また、Anypoint Platform File Connector からの ​`List`​ のような操作では、結果が ​`TypedValue`​ インスタンスで返されるため、DataWeave は読み込むさまざまな種別のファイル (JSON、XML、CSV など) をリストできます。 ## [](#出力データ)出力データ DataWeave では常に ​`TypedValue`​ インスタンスが出力されます。また、使用するライターが ​`TypedValue`​ インスタンスのデータ型に基づいて判断されます。ただし、DataWeave スクリプトで ​`output`​ ディレクティブを使用してデータ型を手動で指定できます。 Mule が実行しているスクリプトがメッセージ処理項目に割り当てられている場合、Mule から DataWeave にその項目のメタデータに基づいてどのデータ型を想定すべきかが伝えられます。たとえば、データ型が Plain Old Java Object (Pojo) の場合、DataWeave はインスタンス化するクラスだけでなく、Java ライターを使用して出力を生成する必要があることも把握できます。 ## [](#dataweave-での-mule-データ型の使用方法)DataWeave での Mule データ型の使用方法 DataWeave は ​`TypedValue`​ インスタンスに含まれるデータ型を使用し、MIME タイプに基づいて使用すべきリーダー、MIME タイププロパティに基づいてそのリーダーの設定方法 (エンコード、リーダープロパティ) を決定します。 データ型を決定できない場合、DataWeave は次の手順に従います。 1. スクリプトが使用している入力種別を確認する。 すべての入力が互換か同じデータ型の場合、DataWeave はそのデータ型を使用します。たとえば、スクリプトに ​``​ が含まれていて、その ​`vars.myBar`​ が XML 型で ​`payload`​ が JSON 型の場合、DataWeave はエラーをスローします。場合によっては、特に XML を操作するときには、Set Payload 操作の式は、無効な XML 構造が生成されたために失敗します。 2. 入力が使用されない場合、DataWeave は Java ライターを使用する。 たとえば、DataWeave がスクリプト ​` # Mule での Maven のサポート
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には次のような Maven の機能が組み込まれています。 - Anypoint Exchange - Anypoint Exchange のコネクタは、Maven 連動関係情報を提供します。Anypoint Exchange でコネクタアセットをクリックして ​**\[Dependency Snippets (連動関係スニペット)\]**​ をクリックすると、Maven の ​`pom.xml`​ ファイルの連動関係をリストできます。 - Anypoint Studio - Anypoint Studio 7 以降で作成されたすべての新規プロジェクトは、デフォルトでは Maven で設定されます。コマンドラインから Maven でプロジェクトを実行したり、Anypoint Studio から直接実行したりできます。 - 既存の Maven プロジェクトを Anypoint Studio にインポートして作業を続けることができます。詳細は、​[「プロジェクトのインポートとエクスポート」](https://docs.mulesoft.com/studio/import-export-packages)​を参照してください。 - Mule Runtime Engine - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept)​を使用することで、Mule アプリケーションのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 ## [](#前提条件)前提条件 `pom.xml`​ ファイルの管理や Maven プラグインの操作といった Maven の概念に慣れておく必要があります。 Maven を使い始めたばかりであれば、 [「Maven’s Getting Started tutorial (Maven の使用開始チュートリアル)」](http://maven.apache.org/guides/getting-started/)​を参照してください。 ## [](#利点)利点 Maven は、Anypoint Studio の内部と外部の両方で Mule アプリケーションの管理を容易にし、以下の利点を提供します。 - Anypoint Studio を使用して新規の Mule プロジェクトを作成すると、正しい Mule プロジェクトフォルダー構造と標準連動関係の基本セットを使用することが保証されます。 - Anypoint Studio は、追加の連動関係を必要とする新しい要素がフローに追加されるたびに、POM ファイルを自動的に管理します。 - Maven POM ファイルを使用することで、POM が連動関係を参照するため、すべての連動関係をユーザー自身が見つけてプロジェクト自身に含める必要がなくなり、プロジェクトの共有が容易かつ軽量になります。 - Maven を使用してビルドを管理することにより、最終的なビルドがクリーンで標準化されます。 - Bamboo などの外部フレームワークを使用して自動ビルドをプログラムすることで、継続的なインテグレーションを保証できます。 ## [](#推奨事項)推奨事項 - Anypoint Studio を使用してアプリケーションを設計してください。 Anypoint Studio には Maven のサポートが組み込まれているため、新しい連動関係を追加した場合でも POM ファイルを手動で更新したり、アプリケーションを修正する必要はほとんどありません。 - POM ファイルと ​`settings.xml`​ は必要に応じて更新してください。 POM ファイルを更新するときに、​`…`​ タグは必須です。作成するプロジェクトの種別に応じて、このタグの有効な値は ​`mule-application`​、​`mule-domain`​、​`mule-policy`​、​`mule-domain-bundle`​ です。たとえば、Anypoint Studio を使用して Mule プロジェクトを作成する場合、タグは自動的に ​`mule-application`​ と定義されます。 コマンドラインからアーキタイプを使用して Maven プロジェクトを作成する場合は、POM ファイルを手動で管理する必要があります。また、場合によっては ​`settings.xml`​ を編集して、MuleSoft Enterprise リポジトリを参照して、ログイン情報を供給する必要があります。また、プロジェクトを Anypoint Studio で管理している場合でも、手動での POM ファイルの調整が必要になるケースもあります。 - SNAPSHOT バージョンを使用してください。 SNAPSHOT により、プロジェクトのバージョンを識別できるため、安定した製品をリリースできるようになります。たとえば、プロジェクトのバージョン ​`1.0.0-SNAPSHOT`​ をビルドしたら、機能をテストしたり修正を加えたりしてから、バージョン ​`1.0.0`​ としてリリースできます。その後は、新しいバージョンである ​`1.1.0-SNAPSHOT`​ を使用してビルドを続けられます。 XML の例: ```xml com.mycompany my-application 1.0.0-SNAPSHOT mule-application ``` ## [](#maven-インストールの設定)Maven インストールの設定 Anypoint Studio では、新規プロジェクトの作成時に、Maven が Mule で動作するように自動的に設定されますが、たとえば、次の継続的インストールや継続的デプロイメント (CI/CD) を実行する場合など、シナリオによっては、Maven インストールが Mule で動作するように手動で設定することが必要になることがあります。 Maven インストールを管理する場合、次の点を確認します。 - `settings.xml`​ ファイルが適切に設定されている。 - Maven インストールを参照するように Anypoint Studio で ​[Maven プリファレンス](https://docs.mulesoft.com/studio/maven-preferences-reference)​を設定します。 - [MuleSoft リポジトリ](https://docs.mulesoft.com/jp/mule-runtime/4.3/maven-reference#configure-mule-repositories)​へのアクセスを設定します。 - `pom.xml`​ ファイルが適切に設定されている。 Studio 以外でプロジェクトを更新する場合は、必要な調整を加えて ​`pom.xml`​ ファイルを常に最新の状態に保ちます。 Maven 設定についての詳細は、​[「Maven リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.3/maven-reference)​を参照してください。 ## [](#関連情報)関連情報 - [Apache Maven](http://maven.apache.org/) - [Anypoint Studio での Maven 設定の調整](https://docs.mulesoft.com/studio/maven-preferences-reference) - [Anypoint Studio でのプロジェクトのインポートとエクスポート](https://docs.mulesoft.com/studio/import-export-packages) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept) - [Maven リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/maven-reference) # Mule での Maven のサポート
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には次のような Maven の機能が組み込まれています。 - Anypoint Exchange - Anypoint Exchange のコネクタは、Maven 連動関係情報を提供します。Anypoint Exchange でコネクタアセットをクリックして ​**\[Dependency Snippets (連動関係スニペット)\]**​ をクリックすると、Maven の ​`pom.xml`​ ファイルの連動関係をリストできます。 - Anypoint Studio - Anypoint Studio 7 以降で作成されたすべての新規プロジェクトは、デフォルトでは Maven で設定されます。コマンドラインから Maven でプロジェクトを実行したり、Anypoint Studio から直接実行したりできます。 - 既存の Maven プロジェクトを Anypoint Studio にインポートして作業を続けることができます。詳細は、​[「プロジェクトのインポートとエクスポート」](https://docs.mulesoft.com/studio/import-export-packages)​を参照してください。 - Mule Runtime Engine - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept)​を使用することで、Mule アプリケーションのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 ## [](#前提条件)前提条件 `pom.xml`​ ファイルの管理や Maven プラグインの操作といった Maven の概念に慣れておく必要があります。 Maven を使い始めたばかりであれば、 [「Maven’s Getting Started tutorial (Maven の使用開始チュートリアル)」](http://maven.apache.org/guides/getting-started/)​を参照してください。 ## [](#利点)利点 Maven は、Anypoint Studio の内部と外部の両方で Mule アプリケーションの管理を容易にし、以下の利点を提供します。 - Anypoint Studio を使用して新規の Mule プロジェクトを作成すると、正しい Mule プロジェクトフォルダー構造と標準連動関係の基本セットを使用することが保証されます。 - Anypoint Studio は、追加の連動関係を必要とする新しい要素がフローに追加されるたびに、POM ファイルを自動的に管理します。 - Maven POM ファイルを使用することで、POM が連動関係を参照するため、すべての連動関係をユーザー自身が見つけてプロジェクト自身に含める必要がなくなり、プロジェクトの共有が容易かつ軽量になります。 - Maven を使用してビルドを管理することにより、最終的なビルドがクリーンで標準化されます。 - Bamboo などの外部フレームワークを使用して自動ビルドをプログラムすることで、継続的なインテグレーションを保証できます。 ## [](#推奨事項)推奨事項 - Anypoint Studio を使用してアプリケーションを設計してください。 Anypoint Studio には Maven のサポートが組み込まれているため、新しい連動関係を追加した場合でも POM ファイルを手動で更新したり、アプリケーションを修正する必要はほとんどありません。 - POM ファイルと ​`settings.xml`​ は必要に応じて更新してください。 POM ファイルを更新するときに、​`…`​ タグは必須です。作成するプロジェクトの種別に応じて、このタグの有効な値は ​`mule-application`​、​`mule-domain`​、​`mule-policy`​、​`mule-domain-bundle`​ です。たとえば、Anypoint Studio を使用して Mule プロジェクトを作成する場合、タグは自動的に ​`mule-application`​ と定義されます。 コマンドラインからアーキタイプを使用して Maven プロジェクトを作成する場合は、POM ファイルを手動で管理する必要があります。また、場合によっては ​`settings.xml`​ を編集して、MuleSoft Enterprise リポジトリを参照して、ログイン情報を供給する必要があります。また、プロジェクトを Anypoint Studio で管理している場合でも、手動での POM ファイルの調整が必要になるケースもあります。 - SNAPSHOT バージョンを使用してください。 SNAPSHOT により、プロジェクトのバージョンを識別できるため、安定した製品をリリースできるようになります。たとえば、プロジェクトのバージョン ​`1.0.0-SNAPSHOT`​ をビルドしたら、機能をテストしたり修正を加えたりしてから、バージョン ​`1.0.0`​ としてリリースできます。その後は、新しいバージョンである ​`1.1.0-SNAPSHOT`​ を使用してビルドを続けられます。 XML の例: ```xml com.mycompany my-application 1.0.0-SNAPSHOT mule-application ``` ## [](#maven-インストールの設定)Maven インストールの設定 Anypoint Studio では、新規プロジェクトの作成時に、Maven が Mule で動作するように自動的に設定されますが、たとえば、次の継続的インストールや継続的デプロイメント (CI/CD) を実行する場合など、シナリオによっては、Maven インストールが Mule で動作するように手動で設定することが必要になることがあります。 Maven インストールを管理する場合、次の点を確認します。 - `settings.xml`​ ファイルが適切に設定されている。 - Maven インストールを参照するように Anypoint Studio で ​[Maven プリファレンス](https://docs.mulesoft.com/studio/maven-preferences-reference)​を設定します。 - [MuleSoft リポジトリ](https://docs.mulesoft.com/jp/mule-runtime/4.4/maven-reference#configure-mule-repositories)​へのアクセスを設定します。 - `pom.xml`​ ファイルが適切に設定されている。 Studio 以外でプロジェクトを更新する場合は、必要な調整を加えて ​`pom.xml`​ ファイルを常に最新の状態に保ちます。 Maven 設定についての詳細は、​[「Maven リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.4/maven-reference)​を参照してください。 ## [](#関連情報)関連情報 - [Apache Maven](http://maven.apache.org/) - [Anypoint Studio での Maven 設定の調整](https://docs.mulesoft.com/studio/maven-preferences-reference) - [Anypoint Studio でのプロジェクトのインポートとエクスポート](https://docs.mulesoft.com/studio/import-export-packages) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept) - [Maven リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/maven-reference) # Mule での Maven のサポート
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には次のような Maven の機能が組み込まれています。 - Anypoint Exchange - Anypoint Exchange のコネクタは、Maven 連動関係情報を提供します。Anypoint Exchange でコネクタアセットをクリックして ​**\[Dependency Snippets (連動関係スニペット)\]**​ をクリックすると、Maven の ​`pom.xml`​ ファイルの連動関係をリストできます。 - Anypoint Studio - Anypoint Studio 7 以降で作成されたすべての新規プロジェクトは、デフォルトでは Maven で設定されます。コマンドラインから Maven でプロジェクトを実行したり、Anypoint Studio から直接実行したりできます。 - 既存の Maven プロジェクトを Anypoint Studio にインポートして作業を続けることができます。詳細は、​[「プロジェクトのインポートとエクスポート」](https://docs.mulesoft.com/studio/import-export-packages)​を参照してください。 - Mule Runtime Engine - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept)​を使用することで、Mule アプリケーションのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 ## [](#前提条件)前提条件 `pom.xml`​ ファイルの管理や Maven プラグインの操作といった Maven の概念に慣れておく必要があります。 Maven を使い始めたばかりであれば、 [「Maven’s Getting Started tutorial (Maven の使用開始チュートリアル)」](http://maven.apache.org/guides/getting-started/)​を参照してください。 ## [](#利点)利点 Maven は、Anypoint Studio の内部と外部の両方で Mule アプリケーションの管理を容易にし、以下の利点を提供します。 - Anypoint Studio を使用して新規の Mule プロジェクトを作成すると、正しい Mule プロジェクトフォルダー構造と標準連動関係の基本セットを使用することが保証されます。 - Anypoint Studio は、追加の連動関係を必要とする新しい要素がフローに追加されるたびに、POM ファイルを自動的に管理します。 - Maven POM ファイルを使用することで、POM が連動関係を参照するため、すべての連動関係をユーザー自身が見つけてプロジェクト自身に含める必要がなくなり、プロジェクトの共有が容易かつ軽量になります。 - Maven を使用してビルドを管理することにより、最終的なビルドがクリーンで標準化されます。 - Bamboo などの外部フレームワークを使用して自動ビルドをプログラムすることで、継続的なインテグレーションを保証できます。 ## [](#推奨事項)推奨事項 - Anypoint Studio を使用してアプリケーションを設計してください。 Anypoint Studio には Maven のサポートが組み込まれているため、新しい連動関係を追加した場合でも POM ファイルを手動で更新したり、アプリケーションを修正する必要はほとんどありません。 - POM ファイルと ​`settings.xml`​ は必要に応じて更新してください。 POM ファイルを更新するときに、​`…`​ タグは必須です。作成するプロジェクトの種別に応じて、このタグの有効な値は ​`mule-application`​、​`mule-domain`​、​`mule-policy`​、​`mule-domain-bundle`​ です。たとえば、Anypoint Studio を使用して Mule プロジェクトを作成する場合、タグは自動的に ​`mule-application`​ と定義されます。 コマンドラインからアーキタイプを使用して Maven プロジェクトを作成する場合は、POM ファイルを手動で管理する必要があります。また、場合によっては ​`settings.xml`​ を編集して、MuleSoft Enterprise リポジトリを参照して、ログイン情報を供給する必要があります。また、プロジェクトを Anypoint Studio で管理している場合でも、手動での POM ファイルの調整が必要になるケースもあります。 - SNAPSHOT バージョンを使用してください。 SNAPSHOT により、プロジェクトのバージョンを識別できるため、安定した製品をリリースできるようになります。たとえば、プロジェクトのバージョン ​`1.0.0-SNAPSHOT`​ をビルドしたら、機能をテストしたり修正を加えたりしてから、バージョン ​`1.0.0`​ としてリリースできます。その後は、新しいバージョンである ​`1.1.0-SNAPSHOT`​ を使用してビルドを続けられます。 XML の例: ```xml com.mycompany my-application 1.0.0-SNAPSHOT mule-application ``` ## [](#maven-インストールの設定)Maven インストールの設定 Anypoint Studio では、新規プロジェクトの作成時に、Maven が Mule で動作するように自動的に設定されますが、たとえば、次の継続的インストールや継続的デプロイメント (CI/CD) を実行する場合など、シナリオによっては、Maven インストールが Mule で動作するように手動で設定することが必要になることがあります。 Maven インストールを管理する場合、次の点を確認します。 - `settings.xml`​ ファイルが適切に設定されている。 - Maven インストールを参照するように Anypoint Studio で ​[Maven プリファレンス](https://docs.mulesoft.com/studio/maven-preferences-reference)​を設定します。 - [MuleSoft リポジトリ](https://docs.mulesoft.com/jp/mule-runtime/4.5/maven-reference#configure-mule-repositories)​へのアクセスを設定します。 - `pom.xml`​ ファイルが適切に設定されている。 Studio 以外でプロジェクトを更新する場合は、必要な調整を加えて ​`pom.xml`​ ファイルを常に最新の状態に保ちます。 Maven 設定についての詳細は、​[「Maven リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.5/maven-reference)​を参照してください。 ## [](#関連情報)関連情報 - [Apache Maven](http://maven.apache.org/) - [Anypoint Studio での Maven 設定の調整](https://docs.mulesoft.com/studio/maven-preferences-reference) - [Anypoint Studio でのプロジェクトのインポートとエクスポート](https://docs.mulesoft.com/studio/import-export-packages) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept) - [Maven リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/maven-reference) # Mule での Maven のサポート
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には次のような Maven の機能が組み込まれています。 - Anypoint Exchange - Anypoint Exchange のコネクタは、Maven 連動関係情報を提供します。Anypoint Exchange でコネクタアセットをクリックして ​**\[Dependency Snippets (連動関係スニペット)\]**​ をクリックすると、Maven の ​`pom.xml`​ ファイルの連動関係をリストできます。 - Anypoint Studio - Anypoint Studio 7 以降で作成されたすべての新規プロジェクトは、デフォルトでは Maven で設定されます。コマンドラインから Maven でプロジェクトを実行したり、Anypoint Studio から直接実行したりできます。 - 既存の Maven プロジェクトを Anypoint Studio にインポートして作業を続けることができます。詳細は、​[「プロジェクトのインポートとエクスポート」](https://docs.mulesoft.com/studio/import-export-packages)​を参照してください。 - Mule Runtime Engine - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept)​を使用することで、Mule アプリケーションのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 ## [](#前提条件)前提条件 `pom.xml`​ ファイルの管理や Maven プラグインの操作といった Maven の概念に慣れておく必要があります。 Maven を使い始めたばかりであれば、 [「Maven’s Getting Started tutorial (Maven の使用開始チュートリアル)」](http://maven.apache.org/guides/getting-started/)​を参照してください。 ## [](#利点)利点 Maven は、Anypoint Studio の内部と外部の両方で Mule アプリケーションの管理を容易にし、以下の利点を提供します。 - Anypoint Studio を使用して新規の Mule プロジェクトを作成すると、正しい Mule プロジェクトフォルダー構造と標準連動関係の基本セットを使用することが保証されます。 - Anypoint Studio は、追加の連動関係を必要とする新しい要素がフローに追加されるたびに、POM ファイルを自動的に管理します。 - Maven POM ファイルを使用することで、POM が連動関係を参照するため、すべての連動関係をユーザー自身が見つけてプロジェクト自身に含める必要がなくなり、プロジェクトの共有が容易かつ軽量になります。 - Maven を使用してビルドを管理することにより、最終的なビルドがクリーンで標準化されます。 - Bamboo などの外部フレームワークを使用して自動ビルドをプログラムすることで、継続的なインテグレーションを保証できます。 ## [](#推奨事項)推奨事項 - Anypoint Studio を使用してアプリケーションを設計してください。 Anypoint Studio には Maven のサポートが組み込まれているため、新しい連動関係を追加した場合でも POM ファイルを手動で更新したり、アプリケーションを修正する必要はほとんどありません。 - POM ファイルと ​`settings.xml`​ は必要に応じて更新してください。 POM ファイルを更新するときに、​`…`​ タグは必須です。作成するプロジェクトの種別に応じて、このタグの有効な値は ​`mule-application`​、​`mule-domain`​、​`mule-policy`​、​`mule-domain-bundle`​ です。たとえば、Anypoint Studio を使用して Mule プロジェクトを作成する場合、タグは自動的に ​`mule-application`​ と定義されます。 コマンドラインからアーキタイプを使用して Maven プロジェクトを作成する場合は、POM ファイルを手動で管理する必要があります。また、場合によっては ​`settings.xml`​ を編集して、MuleSoft Enterprise リポジトリを参照して、ログイン情報を供給する必要があります。また、プロジェクトを Anypoint Studio で管理している場合でも、手動での POM ファイルの調整が必要になるケースもあります。 - SNAPSHOT バージョンを使用してください。 SNAPSHOT により、プロジェクトのバージョンを識別できるため、安定した製品をリリースできるようになります。たとえば、プロジェクトのバージョン ​`1.0.0-SNAPSHOT`​ をビルドしたら、機能をテストしたり修正を加えたりしてから、バージョン ​`1.0.0`​ としてリリースできます。その後は、新しいバージョンである ​`1.1.0-SNAPSHOT`​ を使用してビルドを続けられます。 XML の例: ```xml com.mycompany my-application 1.0.0-SNAPSHOT mule-application ```
連動関係の管理に Maven を使用している場合、プロジェクトにサードパーティコンポーネントを含めるときには注意してください。MuleSoft はセキュアなリポジトリを維持していますが、外部ソースからのコンポーネントの安全性は保証できません。悪意のある攻撃者が偽物のコンポーネントを作成し、サードパーティリポジトリで配布する可能性があります。サードパーティコンポーネントをプロジェクトに組み込む前に、すべてのサードパーティコンポーネントについて調査と審査を行ってください。そうすることで、アプリケーションのセキュリティと整合性を保つことができます。
## [](#maven-インストールの設定)Maven インストールの設定 Anypoint Studio では、新規プロジェクトの作成時に、Maven が Mule で動作するように自動的に設定されますが、たとえば、次の継続的インストールや継続的デプロイメント (CI/CD) を実行する場合など、シナリオによっては、Maven インストールが Mule で動作するように手動で設定することが必要になることがあります。 Maven インストールを管理する場合、次の点を確認します。 - `settings.xml`​ ファイルが適切に設定されている。 - Maven インストールを参照するように Anypoint Studio で ​[Maven プリファレンス](https://docs.mulesoft.com/studio/maven-preferences-reference)​を設定します。 - [MuleSoft リポジトリ](https://docs.mulesoft.com/jp/mule-runtime/4.6/maven-reference#configure-mule-repositories)​へのアクセスを設定します。 - `pom.xml`​ ファイルが適切に設定されている。 Studio 以外でプロジェクトを更新する場合は、必要な調整を加えて ​`pom.xml`​ ファイルを常に最新の状態に保ちます。 Maven 設定についての詳細は、​[「Maven リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.6/maven-reference)​を参照してください。 ## [](#関連情報)関連情報 - [Apache Maven](http://maven.apache.org/) - [Anypoint Studio での Maven 設定の調整](https://docs.mulesoft.com/studio/maven-preferences-reference) - [Anypoint Studio でのプロジェクトのインポートとエクスポート](https://docs.mulesoft.com/studio/import-export-packages) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept) - [Maven リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/maven-reference) # Mule での Maven のサポート
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には次のような Maven の機能が組み込まれています。 - Anypoint Exchange - Anypoint Exchange のコネクタは、Maven 連動関係情報を提供します。Anypoint Exchange でコネクタアセットをクリックして ​**\[Dependency Snippets (連動関係スニペット)\]**​ をクリックすると、Maven の ​`pom.xml`​ ファイルの連動関係をリストできます。 - Anypoint Studio - Anypoint Studio 7 以降で作成されたすべての新規プロジェクトは、デフォルトでは Maven で設定されます。コマンドラインから Maven でプロジェクトを実行したり、Anypoint Studio から直接実行したりできます。 - 既存の Maven プロジェクトを Anypoint Studio にインポートして作業を続けることができます。詳細は、​[「プロジェクトのインポートとエクスポート」](https://docs.mulesoft.com/studio/import-export-packages)​を参照してください。 - Mule Runtime Engine - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept)​を使用することで、Mule アプリケーションのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 ## [](#前提条件)前提条件 `pom.xml`​ ファイルの管理や Maven プラグインの操作といった Maven の概念に慣れておく必要があります。 Maven を使い始めたばかりであれば、 [「Maven’s Getting Started tutorial (Maven の使用開始チュートリアル)」](http://maven.apache.org/guides/getting-started/)​を参照してください。 ## [](#利点)利点 Maven は、Anypoint Studio の内部と外部の両方で Mule アプリケーションの管理を容易にし、以下の利点を提供します。 - Anypoint Studio を使用して新規の Mule プロジェクトを作成すると、正しい Mule プロジェクトフォルダー構造と標準連動関係の基本セットを使用することが保証されます。 - Anypoint Studio は、追加の連動関係を必要とする新しい要素がフローに追加されるたびに、POM ファイルを自動的に管理します。 - Maven POM ファイルを使用することで、POM が連動関係を参照するため、すべての連動関係をユーザー自身が見つけてプロジェクト自身に含める必要がなくなり、プロジェクトの共有が容易かつ軽量になります。 - Maven を使用してビルドを管理することにより、最終的なビルドがクリーンで標準化されます。 - Bamboo などの外部フレームワークを使用して自動ビルドをプログラムすることで、継続的なインテグレーションを保証できます。 ## [](#推奨事項)推奨事項 - Anypoint Studio を使用してアプリケーションを設計してください。 Anypoint Studio には Maven のサポートが組み込まれているため、新しい連動関係を追加した場合でも POM ファイルを手動で更新したり、アプリケーションを修正する必要はほとんどありません。 - POM ファイルと ​`settings.xml`​ は必要に応じて更新してください。 POM ファイルを更新するときに、​`…`​ タグは必須です。作成するプロジェクトの種別に応じて、このタグの有効な値は ​`mule-application`​、​`mule-domain`​、​`mule-policy`​、​`mule-domain-bundle`​ です。たとえば、Anypoint Studio を使用して Mule プロジェクトを作成する場合、タグは自動的に ​`mule-application`​ と定義されます。 コマンドラインからアーキタイプを使用して Maven プロジェクトを作成する場合は、POM ファイルを手動で管理する必要があります。また、場合によっては ​`settings.xml`​ を編集して、MuleSoft Enterprise リポジトリを参照して、ログイン情報を供給する必要があります。また、プロジェクトを Anypoint Studio で管理している場合でも、手動での POM ファイルの調整が必要になるケースもあります。 - SNAPSHOT バージョンを使用してください。 SNAPSHOT により、プロジェクトのバージョンを識別できるため、安定した製品をリリースできるようになります。たとえば、プロジェクトのバージョン ​`1.0.0-SNAPSHOT`​ をビルドしたら、機能をテストしたり修正を加えたりしてから、バージョン ​`1.0.0`​ としてリリースできます。その後は、新しいバージョンである ​`1.1.0-SNAPSHOT`​ を使用してビルドを続けられます。 XML の例: ```xml com.mycompany my-application 1.0.0-SNAPSHOT mule-application ```
連動関係の管理に Maven を使用している場合、プロジェクトにサードパーティコンポーネントを含めるときには注意してください。MuleSoft はセキュアなリポジトリを維持していますが、外部ソースからのコンポーネントの安全性は保証できません。悪意のある攻撃者が偽物のコンポーネントを作成し、サードパーティリポジトリで配布する可能性があります。サードパーティコンポーネントをプロジェクトに組み込む前に、すべてのサードパーティコンポーネントについて調査と審査を行ってください。そうすることで、アプリケーションのセキュリティと整合性を保つことができます。
## [](#maven-インストールの設定)Maven インストールの設定 Anypoint Studio では、新規プロジェクトの作成時に、Maven が Mule で動作するように自動的に設定されますが、たとえば、次の継続的インストールや継続的デプロイメント (CI/CD) を実行する場合など、シナリオによっては、Maven インストールが Mule で動作するように手動で設定することが必要になることがあります。 Maven インストールを管理する場合、次の点を確認します。 - `settings.xml`​ ファイルが適切に設定されている。 - Maven インストールを参照するように Anypoint Studio で ​[Maven プリファレンス](https://docs.mulesoft.com/studio/maven-preferences-reference)​を設定します。 - [MuleSoft リポジトリ](https://docs.mulesoft.com/jp/mule-runtime/4.7/maven-reference#configure-mule-repositories)​へのアクセスを設定します。 - `pom.xml`​ ファイルが適切に設定されている。 Studio 以外でプロジェクトを更新する場合は、必要な調整を加えて ​`pom.xml`​ ファイルを常に最新の状態に保ちます。 Maven 設定についての詳細は、​[「Maven リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.7/maven-reference)​を参照してください。 ## [](#関連情報)関連情報 - [Apache Maven](http://maven.apache.org/) - [Anypoint Studio での Maven 設定の調整](https://docs.mulesoft.com/studio/maven-preferences-reference) - [Anypoint Studio でのプロジェクトのインポートとエクスポート](https://docs.mulesoft.com/studio/import-export-packages) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept) - [Maven リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/maven-reference) # Mule での Maven のサポート
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には次のような Maven の機能が組み込まれています。 - Anypoint Exchange - Anypoint Exchange のコネクタは、Maven 連動関係情報を提供します。Anypoint Exchange でコネクタアセットをクリックして ​**\[Dependency Snippets (連動関係スニペット)\]**​ をクリックすると、Maven の ​`pom.xml`​ ファイルの連動関係をリストできます。 - Anypoint Studio - Anypoint Studio 7 以降で作成されたすべての新規プロジェクトは、デフォルトでは Maven で設定されます。コマンドラインから Maven でプロジェクトを実行したり、Anypoint Studio から直接実行したりできます。 - 既存の Maven プロジェクトを Anypoint Studio にインポートして作業を続けることができます。詳細は、​[「プロジェクトのインポートとエクスポート」](https://docs.mulesoft.com/studio/import-export-packages)​を参照してください。 - Mule Runtime Engine - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept)​を使用することで、Mule アプリケーションのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 ## [](#前提条件)前提条件 `pom.xml`​ ファイルの管理や Maven プラグインの操作といった Maven の概念に慣れておく必要があります。 Maven を使い始めたばかりであれば、 [「Maven’s Getting Started tutorial (Maven の使用開始チュートリアル)」](http://maven.apache.org/guides/getting-started/)​を参照してください。 ## [](#利点)利点 Maven は、Anypoint Studio の内部と外部の両方で Mule アプリケーションの管理を容易にし、以下の利点を提供します。 - Anypoint Studio を使用して新規の Mule プロジェクトを作成すると、正しい Mule プロジェクトフォルダー構造と標準連動関係の基本セットを使用することが保証されます。 - Anypoint Studio は、追加の連動関係を必要とする新しい要素がフローに追加されるたびに、POM ファイルを自動的に管理します。 - Maven POM ファイルを使用することで、POM が連動関係を参照するため、すべての連動関係をユーザー自身が見つけてプロジェクト自身に含める必要がなくなり、プロジェクトの共有が容易かつ軽量になります。 - Maven を使用してビルドを管理することにより、最終的なビルドがクリーンで標準化されます。 - Bamboo などの外部フレームワークを使用して自動ビルドをプログラムすることで、継続的なインテグレーションを保証できます。 ## [](#推奨事項)推奨事項 - Anypoint Studio を使用してアプリケーションを設計してください。 Anypoint Studio には Maven のサポートが組み込まれているため、新しい連動関係を追加した場合でも POM ファイルを手動で更新したり、アプリケーションを修正する必要はほとんどありません。 - POM ファイルと ​`settings.xml`​ は必要に応じて更新してください。 POM ファイルを更新するときに、​`…`​ タグは必須です。作成するプロジェクトの種別に応じて、このタグの有効な値は ​`mule-application`​、​`mule-domain`​、​`mule-policy`​、​`mule-domain-bundle`​ です。たとえば、Anypoint Studio を使用して Mule プロジェクトを作成する場合、タグは自動的に ​`mule-application`​ と定義されます。 コマンドラインからアーキタイプを使用して Maven プロジェクトを作成する場合は、POM ファイルを手動で管理する必要があります。また、場合によっては ​`settings.xml`​ を編集して、MuleSoft Enterprise リポジトリを参照して、ログイン情報を供給する必要があります。また、プロジェクトを Anypoint Studio で管理している場合でも、手動での POM ファイルの調整が必要になるケースもあります。 - SNAPSHOT バージョンを使用してください。 SNAPSHOT により、プロジェクトのバージョンを識別できるため、安定した製品をリリースできるようになります。たとえば、プロジェクトのバージョン ​`1.0.0-SNAPSHOT`​ をビルドしたら、機能をテストしたり修正を加えたりしてから、バージョン ​`1.0.0`​ としてリリースできます。その後は、新しいバージョンである ​`1.1.0-SNAPSHOT`​ を使用してビルドを続けられます。 XML の例: ```xml com.mycompany my-application 1.0.0-SNAPSHOT mule-application ```
連動関係の管理に Maven を使用している場合、プロジェクトにサードパーティコンポーネントを含めるときには注意してください。MuleSoft はセキュアなリポジトリを維持していますが、外部ソースからのコンポーネントの安全性は保証できません。悪意のある攻撃者が偽物のコンポーネントを作成し、サードパーティリポジトリで配布する可能性があります。サードパーティコンポーネントをプロジェクトに組み込む前に、すべてのサードパーティコンポーネントについて調査と審査を行ってください。そうすることで、アプリケーションのセキュリティと整合性を保つことができます。
## [](#maven-インストールの設定)Maven インストールの設定 Anypoint Studio では、新規プロジェクトの作成時に、Maven が Mule で動作するように自動的に設定されますが、たとえば、次の継続的インストールや継続的デプロイメント (CI/CD) を実行する場合など、シナリオによっては、Maven インストールが Mule で動作するように手動で設定することが必要になることがあります。 Maven インストールを管理する場合、次の点を確認します。 - `settings.xml`​ ファイルが適切に設定されている。 - Maven インストールを参照するように Anypoint Studio で ​[Maven プリファレンス](https://docs.mulesoft.com/studio/maven-preferences-reference)​を設定します。 - [MuleSoft リポジトリ](https://docs.mulesoft.com/jp/mule-runtime/4.8/maven-reference#configure-mule-repositories)​へのアクセスを設定します。 - `pom.xml`​ ファイルが適切に設定されている。 Studio 以外でプロジェクトを更新する場合は、必要な調整を加えて ​`pom.xml`​ ファイルを常に最新の状態に保ちます。 Maven 設定についての詳細は、​[「Maven リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.8/maven-reference)​を参照してください。 ## [](#関連情報)関連情報 - [Apache Maven](http://maven.apache.org/) - [Anypoint Studio での Maven 設定の調整](https://docs.mulesoft.com/studio/maven-preferences-reference) - [Anypoint Studio でのプロジェクトのインポートとエクスポート](https://docs.mulesoft.com/studio/import-export-packages) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept) - [Maven リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/maven-reference) # Mule での Maven のサポート
Mule Maven プラグインバージョン 3.0.0、3.1.0、3.1.1、3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.1.7、3.8.3 は非推奨です。
Maven は、プロジェクト開発を強化するために Mule が実装しているプロジェクト管理ユーティリティです。Mule には次のような Maven の機能が組み込まれています。 - Anypoint Exchange - Anypoint Exchange のコネクタは、Maven 連動関係情報を提供します。Anypoint Exchange でコネクタアセットをクリックして ​**\[Dependency Snippets (連動関係スニペット)\]**​ をクリックすると、Maven の ​`pom.xml`​ ファイルの連動関係をリストできます。 - Anypoint Studio - Anypoint Studio 7 以降で作成されたすべての新規プロジェクトは、デフォルトでは Maven で設定されます。コマンドラインから Maven でプロジェクトを実行したり、Anypoint Studio から直接実行したりできます。 - 既存の Maven プロジェクトを Anypoint Studio にインポートして作業を続けることができます。詳細は、​[「プロジェクトのインポートとエクスポート」](https://docs.mulesoft.com/studio/import-export-packages)​を参照してください。 - Mule Runtime Engine - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept)​を使用することで、Mule アプリケーションのパッケージ、テスト、デプロイメントを Maven ライフサイクルと統合できます。 ## [](#前提条件)前提条件 `pom.xml`​ ファイルの管理や Maven プラグインの操作といった Maven の概念に慣れておく必要があります。 Maven を使い始めたばかりであれば、 [「Maven’s Getting Started tutorial (Maven の使用開始チュートリアル)」](http://maven.apache.org/guides/getting-started/)​を参照してください。 ## [](#利点)利点 Maven は、Anypoint Studio の内部と外部の両方で Mule アプリケーションの管理を容易にし、以下の利点を提供します。 - Anypoint Studio を使用して新規の Mule プロジェクトを作成すると、正しい Mule プロジェクトフォルダー構造と標準連動関係の基本セットを使用することが保証されます。 - Anypoint Studio は、追加の連動関係を必要とする新しい要素がフローに追加されるたびに、POM ファイルを自動的に管理します。 - Maven POM ファイルを使用することで、POM が連動関係を参照するため、すべての連動関係をユーザー自身が見つけてプロジェクト自身に含める必要がなくなり、プロジェクトの共有が容易かつ軽量になります。 - Maven を使用してビルドを管理することにより、最終的なビルドがクリーンで標準化されます。 - Bamboo などの外部フレームワークを使用して自動ビルドをプログラムすることで、継続的なインテグレーションを保証できます。 ## [](#推奨事項)推奨事項 - Anypoint Studio を使用してアプリケーションを設計してください。 Anypoint Studio には Maven のサポートが組み込まれているため、新しい連動関係を追加した場合でも POM ファイルを手動で更新したり、アプリケーションを修正する必要はほとんどありません。 - POM ファイルと ​`settings.xml`​ は必要に応じて更新してください。 POM ファイルを更新するときに、​`…`​ タグは必須です。作成するプロジェクトの種別に応じて、このタグの有効な値は ​`mule-application`​、​`mule-domain`​、​`mule-policy`​、​`mule-domain-bundle`​ です。たとえば、Anypoint Studio を使用して Mule プロジェクトを作成する場合、タグは自動的に ​`mule-application`​ と定義されます。 コマンドラインからアーキタイプを使用して Maven プロジェクトを作成する場合は、POM ファイルを手動で管理する必要があります。また、場合によっては ​`settings.xml`​ を編集して、MuleSoft Enterprise リポジトリを参照して、ログイン情報を供給する必要があります。また、プロジェクトを Anypoint Studio で管理している場合でも、手動での POM ファイルの調整が必要になるケースもあります。 - SNAPSHOT バージョンを使用してください。 SNAPSHOT により、プロジェクトのバージョンを識別できるため、安定した製品をリリースできるようになります。たとえば、プロジェクトのバージョン ​`1.0.0-SNAPSHOT`​ をビルドしたら、機能をテストしたり修正を加えたりしてから、バージョン ​`1.0.0`​ としてリリースできます。その後は、新しいバージョンである ​`1.1.0-SNAPSHOT`​ を使用してビルドを続けられます。 XML の例: ```xml com.mycompany my-application 1.0.0-SNAPSHOT mule-application ```
連動関係の管理に Maven を使用している場合、プロジェクトにサードパーティコンポーネントを含めるときには注意してください。MuleSoft はセキュアなリポジトリを維持していますが、外部ソースからのコンポーネントの安全性は保証できません。悪意のある攻撃者が偽物のコンポーネントを作成し、サードパーティリポジトリで配布する可能性があります。サードパーティコンポーネントをプロジェクトに組み込む前に、すべてのサードパーティコンポーネントについて調査と審査を行ってください。そうすることで、アプリケーションのセキュリティと整合性を保つことができます。
## [](#maven-インストールの設定)Maven インストールの設定 Anypoint Studio では、新規プロジェクトの作成時に、Maven が Mule で動作するように自動的に設定されますが、たとえば、次の継続的インストールや継続的デプロイメント (CI/CD) を実行する場合など、シナリオによっては、Maven インストールが Mule で動作するように手動で設定することが必要になることがあります。 Maven インストールを管理する場合、次の点を確認します。 - `settings.xml`​ ファイルが適切に設定されている。 - Maven インストールを参照するように Anypoint Studio で ​[Maven プリファレンス](https://docs.mulesoft.com/studio/maven-preferences-reference)​を設定します。 - [MuleSoft リポジトリ](https://docs.mulesoft.com/jp/mule-runtime/4.9/maven-reference#configure-mule-repositories)​へのアクセスを設定します。 - `pom.xml`​ ファイルが適切に設定されている。 Studio 以外でプロジェクトを更新する場合は、必要な調整を加えて ​`pom.xml`​ ファイルを常に最新の状態に保ちます。 Maven 設定についての詳細は、​[「Maven リファレンス」](https://docs.mulesoft.com/jp/mule-runtime/4.9/maven-reference)​を参照してください。 ## [](#関連情報)関連情報 - [Apache Maven](http://maven.apache.org/) - [Anypoint Studio での Maven 設定の調整](https://docs.mulesoft.com/studio/maven-preferences-reference) - [Anypoint Studio でのプロジェクトのインポートとエクスポート](https://docs.mulesoft.com/studio/import-export-packages) - [Mule Maven プラグイン](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept) - [Maven リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/maven-reference) # Mule のコンポーネント Mule アプリケーションの主な構成要素はコンポーネントです。コンポーネントは Mule アプリケーションを経由するメッセージでビジネスロジックを実行します。コンポーネントには、コアコンポーネントと、コネクタやモジュールに属するコンポーネントがあります。 ## [](#コアコンポーネント)コアコンポーネント これは、Mule Runtime の機能のコアを構成する個別のコンポーネントです。次に、コアコンポーネントでアプリケーションに追加できる機能の例を挙げます。 - フローまたはサブフローの一部の非同期処理 - メッセージの一括処理 - サブフローの初期化 - ログ記録 - ペイロードの設定 - DataWeave 言語を使用したメッセージの変換 - エラーをキャッチして対応するためのフローでの Try スコープの作成 たとえば、Choice ルーターはメッセージコンテンツを評価する DataWeave 式のセットに従ってフローを経由するメッセージを動的にルーティングするコンポーネントです。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 ![Anypoint Studio のコアコンポーネントのリスト](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/about-mule-apps-core-components.png) Figure 1. Anypoint Studio のコアコンポーネントのリスト コンポーネントドキュメントについては、​[「コアコンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-components)​を参照してください。 ## [](#コネクタ)コネクタ コネクタは、サードパーティ API や標準インテグレーションプロトコルなどの外部リソースと MuleSoft アプリケーションのインテグレーションを容易にするために作成されたコンポーネントをグループにまとめたものです。コネクタにより、SaaS やオンプレミスアプリケーション、システム、サービスへの接続が可能になります。 たとえば、Salesforce Connector には、Salesforce プラットフォーム API を使用して多数のさまざまな操作を実行できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた Salesforce Connector およびその操作](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/about-mule-apps-salesforce-connector.png) Figure 2. Anypoint Studio でリストされた Salesforce Connector およびその操作 ## [](#モジュール)モジュール モジュールは、値の圧縮データの集約、Java 機能の使用、JSON を処理するための追加機能の使用などを可能にすることで、アプリケーションの柔軟性を高めるために作成されたコンポーネントをグループにまとめたものです。モジュールによって提供される機能は、従来のアプリケーションコーディングのレベルではさらに増えます。 たとえば、XML Module には XML ドキュメントからデータを抽出して処理できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた XML Module およびそのコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/about-mule-apps-xml-module.png) Figure 3. Anypoint Studio でリストされた XML Module およびそのコンポーネント ## [](#関連情報)関連情報 - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # Mule のコンポーネント Mule アプリケーションの主な構成要素はコンポーネントです。コンポーネントは Mule アプリケーションを経由するメッセージでビジネスロジックを実行します。コンポーネントには、コアコンポーネントと、コネクタやモジュールに属するコンポーネントがあります。 ## [](#コアコンポーネント)コアコンポーネント これは、Mule Runtime の機能のコアを構成する個別のコンポーネントです。次に、コアコンポーネントでアプリケーションに追加できる機能の例を挙げます。 - フローまたはサブフローの一部の非同期処理 - メッセージの一括処理 - サブフローの初期化 - ログ記録 - ペイロードの設定 - DataWeave 言語を使用したメッセージの変換 - エラーをキャッチして対応するためのフローでの Try スコープの作成 たとえば、Choice ルーターはメッセージコンテンツを評価する DataWeave 式のセットに従ってフローを経由するメッセージを動的にルーティングするコンポーネントです。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 ![Anypoint Studio のコアコンポーネントのリスト](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/about-mule-apps-core-components.png) Figure 1. Anypoint Studio のコアコンポーネントのリスト コンポーネントドキュメントについては、​[「コアコンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-components)​を参照してください。 ## [](#コネクタ)コネクタ コネクタは、サードパーティ API や標準インテグレーションプロトコルなどの外部リソースと MuleSoft アプリケーションのインテグレーションを容易にするために作成されたコンポーネントをグループにまとめたものです。コネクタにより、SaaS やオンプレミスアプリケーション、システム、サービスへの接続が可能になります。 たとえば、Salesforce Connector には、Salesforce プラットフォーム API を使用して多数のさまざまな操作を実行できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた Salesforce Connector およびその操作](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/about-mule-apps-salesforce-connector.png) Figure 2. Anypoint Studio でリストされた Salesforce Connector およびその操作 ## [](#モジュール)モジュール モジュールは、値の圧縮データの集約、Java 機能の使用、JSON を処理するための追加機能の使用などを可能にすることで、アプリケーションの柔軟性を高めるために作成されたコンポーネントをグループにまとめたものです。モジュールによって提供される機能は、従来のアプリケーションコーディングのレベルではさらに増えます。 たとえば、XML Module には XML ドキュメントからデータを抽出して処理できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた XML Module およびそのコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/about-mule-apps-xml-module.png) Figure 3. Anypoint Studio でリストされた XML Module およびそのコンポーネント ## [](#関連情報)関連情報 - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # Mule のコンポーネント Mule アプリケーションの主な構成要素はコンポーネントです。コンポーネントは Mule アプリケーションを経由するメッセージでビジネスロジックを実行します。コンポーネントには、コアコンポーネントと、コネクタやモジュールに属するコンポーネントがあります。 ## [](#コアコンポーネント)コアコンポーネント これは、Mule Runtime の機能のコアを構成する個別のコンポーネントです。次に、コアコンポーネントでアプリケーションに追加できる機能の例を挙げます。 - フローまたはサブフローの一部の非同期処理 - メッセージの一括処理 - サブフローの初期化 - ログ記録 - ペイロードの設定 - DataWeave 言語を使用したメッセージの変換 - エラーをキャッチして対応するためのフローでの Try スコープの作成 たとえば、Choice ルーターはメッセージコンテンツを評価する DataWeave 式のセットに従ってフローを経由するメッセージを動的にルーティングするコンポーネントです。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 ![Anypoint Studio のコアコンポーネントのリスト](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/about-mule-apps-core-components.png) Figure 1. Anypoint Studio のコアコンポーネントのリスト コンポーネントドキュメントについては、​[「コアコンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-components)​を参照してください。 ## [](#コネクタ)コネクタ コネクタは、サードパーティ API や標準インテグレーションプロトコルなどの外部リソースと MuleSoft アプリケーションのインテグレーションを容易にするために作成されたコンポーネントをグループにまとめたものです。コネクタにより、SaaS やオンプレミスアプリケーション、システム、サービスへの接続が可能になります。 たとえば、Salesforce Connector には、Salesforce プラットフォーム API を使用して多数のさまざまな操作を実行できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた Salesforce Connector およびその操作](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/about-mule-apps-salesforce-connector.png) Figure 2. Anypoint Studio でリストされた Salesforce Connector およびその操作 ## [](#モジュール)モジュール モジュールは、値の圧縮データの集約、Java 機能の使用、JSON を処理するための追加機能の使用などを可能にすることで、アプリケーションの柔軟性を高めるために作成されたコンポーネントをグループにまとめたものです。モジュールによって提供される機能は、従来のアプリケーションコーディングのレベルではさらに増えます。 たとえば、XML Module には XML ドキュメントからデータを抽出して処理できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた XML Module およびそのコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/about-mule-apps-xml-module.png) Figure 3. Anypoint Studio でリストされた XML Module およびそのコンポーネント ## [](#関連情報)関連情報 - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # Mule のコンポーネント Mule アプリケーションの主な構成要素はコンポーネントです。コンポーネントは Mule アプリケーションを経由するメッセージでビジネスロジックを実行します。コンポーネントには、コアコンポーネントと、コネクタやモジュールに属するコンポーネントがあります。 ## [](#コアコンポーネント)コアコンポーネント これは、Mule Runtime の機能のコアを構成する個別のコンポーネントです。次に、コアコンポーネントでアプリケーションに追加できる機能の例を挙げます。 - フローまたはサブフローの一部の非同期処理 - メッセージの一括処理 - サブフローの初期化 - ログ記録 - ペイロードの設定 - DataWeave 言語を使用したメッセージの変換 - エラーをキャッチして対応するためのフローでの Try スコープの作成 たとえば、Choice ルーターはメッセージコンテンツを評価する DataWeave 式のセットに従ってフローを経由するメッセージを動的にルーティングするコンポーネントです。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 ![Anypoint Studio のコアコンポーネントのリスト](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/about-mule-apps-core-components.png) Figure 1. Anypoint Studio のコアコンポーネントのリスト コンポーネントドキュメントについては、​[「コアコンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-components)​を参照してください。 ## [](#コネクタ)コネクタ コネクタは、サードパーティ API や標準インテグレーションプロトコルなどの外部リソースと MuleSoft アプリケーションのインテグレーションを容易にするために作成されたコンポーネントをグループにまとめたものです。コネクタにより、SaaS やオンプレミスアプリケーション、システム、サービスへの接続が可能になります。 たとえば、Salesforce Connector には、Salesforce プラットフォーム API を使用して多数のさまざまな操作を実行できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた Salesforce Connector およびその操作](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/about-mule-apps-salesforce-connector.png) Figure 2. Anypoint Studio でリストされた Salesforce Connector およびその操作 ## [](#モジュール)モジュール モジュールは、値の圧縮データの集約、Java 機能の使用、JSON を処理するための追加機能の使用などを可能にすることで、アプリケーションの柔軟性を高めるために作成されたコンポーネントをグループにまとめたものです。モジュールによって提供される機能は、従来のアプリケーションコーディングのレベルではさらに増えます。 たとえば、XML Module には XML ドキュメントからデータを抽出して処理できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた XML Module およびそのコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/about-mule-apps-xml-module.png) Figure 3. Anypoint Studio でリストされた XML Module およびそのコンポーネント ## [](#関連情報)関連情報 - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # Mule のコンポーネント Mule アプリケーションの主な構成要素はコンポーネントです。コンポーネントは Mule アプリケーションを経由するメッセージでビジネスロジックを実行します。コンポーネントには、コアコンポーネントと、コネクタやモジュールに属するコンポーネントがあります。 ## [](#コアコンポーネント)コアコンポーネント これは、Mule Runtime の機能のコアを構成する個別のコンポーネントです。次に、コアコンポーネントでアプリケーションに追加できる機能の例を挙げます。 - フローまたはサブフローの一部の非同期処理 - メッセージの一括処理 - サブフローの初期化 - ログ記録 - ペイロードの設定 - DataWeave 言語を使用したメッセージの変換 - エラーをキャッチして対応するためのフローでの Try スコープの作成 たとえば、Choice ルーターはメッセージコンテンツを評価する DataWeave 式のセットに従ってフローを経由するメッセージを動的にルーティングするコンポーネントです。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 ![Anypoint Studio でリストされた Mule アプリケーションのコアコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/about-mule-apps-core-components.png) Figure 1. Anypoint Studio のコアコンポーネントのリスト コンポーネントドキュメントについては、​[「コアコンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-components)​を参照してください。 ## [](#コネクタ)コネクタ コネクタは、サードパーティ API や標準インテグレーションプロトコルなどの外部リソースと MuleSoft アプリケーションのインテグレーションを容易にするために作成されたコンポーネントをグループにまとめたものです。コネクタにより、SaaS やオンプレミスアプリケーション、システム、サービスへの接続が可能になります。 たとえば、Salesforce Connector には、Salesforce プラットフォーム API を使用して多数のさまざまな操作を実行できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた Salesforce Connector およびその操作](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/about-mule-apps-salesforce-connector.png) Figure 2. Anypoint Studio でリストされた Salesforce Connector およびその操作 ## [](#モジュール)モジュール モジュールは、値の圧縮データの集約、Java 機能の使用、JSON を処理するための追加機能の使用などを可能にすることで、アプリケーションの柔軟性を高めるために作成されたコンポーネントをグループにまとめたものです。モジュールによって提供される機能は、従来のアプリケーションコーディングのレベルではさらに増えます。 たとえば、XML Module には XML ドキュメントからデータを抽出して処理できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた XML Module およびそのコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/about-mule-apps-xml-module.png) Figure 3. Anypoint Studio でリストされた XML Module およびそのコンポーネント ## [](#関連情報)関連情報 - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # Mule のコンポーネント Mule アプリケーションの主な構成要素はコンポーネントです。コンポーネントは Mule アプリケーションを経由するメッセージでビジネスロジックを実行します。コンポーネントには、コアコンポーネントと、コネクタやモジュールに属するコンポーネントがあります。 ## [](#コアコンポーネント)コアコンポーネント これは、Mule Runtime の機能のコアを構成する個別のコンポーネントです。次に、コアコンポーネントでアプリケーションに追加できる機能の例を挙げます。 - フローまたはサブフローの一部の非同期処理 - メッセージの一括処理 - サブフローの初期化 - ログ記録 - ペイロードの設定 - DataWeave 言語を使用したメッセージの変換 - エラーをキャッチして対応するためのフローでの Try スコープの作成 たとえば、Choice ルーターはメッセージコンテンツを評価する DataWeave 式のセットに従ってフローを経由するメッセージを動的にルーティングするコンポーネントです。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 ![Anypoint Studio でリストされた Mule アプリケーションのコアコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/about-mule-apps-core-components.png) Figure 1. Anypoint Studio のコアコンポーネントのリスト コンポーネントドキュメントについては、​[「コアコンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-components)​を参照してください。 ## [](#コネクタ)コネクタ コネクタは、サードパーティ API や標準インテグレーションプロトコルなどの外部リソースと MuleSoft アプリケーションのインテグレーションを容易にするために作成されたコンポーネントをグループにまとめたものです。コネクタにより、SaaS やオンプレミスアプリケーション、システム、サービスへの接続が可能になります。 たとえば、Salesforce Connector には、Salesforce プラットフォーム API を使用して多数のさまざまな操作を実行できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた Salesforce Connector およびその操作](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/about-mule-apps-salesforce-connector.png) Figure 2. Anypoint Studio でリストされた Salesforce Connector およびその操作 ## [](#モジュール)モジュール モジュールは、値の圧縮データの集約、Java 機能の使用、JSON を処理するための追加機能の使用などを可能にすることで、アプリケーションの柔軟性を高めるために作成されたコンポーネントをグループにまとめたものです。モジュールによって提供される機能は、従来のアプリケーションコーディングのレベルではさらに増えます。 たとえば、XML Module には XML ドキュメントからデータを抽出して処理できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた XML Module およびそのコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/about-mule-apps-xml-module.png) Figure 3. Anypoint Studio でリストされた XML Module およびそのコンポーネント ## [](#関連情報)関連情報 - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # Mule のコンポーネント Mule アプリケーションの主な構成要素はコンポーネントです。コンポーネントは Mule アプリケーションを経由するメッセージでビジネスロジックを実行します。コンポーネントには、コアコンポーネントと、コネクタやモジュールに属するコンポーネントがあります。 ## [](#コアコンポーネント)コアコンポーネント これは、Mule Runtime の機能のコアを構成する個別のコンポーネントです。次に、コアコンポーネントでアプリケーションに追加できる機能の例を挙げます。 - フローまたはサブフローの一部の非同期処理 - メッセージの一括処理 - サブフローの初期化 - ログ記録 - ペイロードの設定 - DataWeave 言語を使用したメッセージの変換 - エラーをキャッチして対応するためのフローでの Try スコープの作成 たとえば、Choice ルーターはメッセージコンテンツを評価する DataWeave 式のセットに従ってフローを経由するメッセージを動的にルーティングするコンポーネントです。各式は、異なるルーティングオプションに関連付けられます。これにより、大部分のプログラミング言語の ​`if`​/​`then`​/​`else`​ コードブロックのような条件付き処理がフローに追加されます。 ![Anypoint Studio でリストされた Mule アプリケーションのコアコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/about-mule-apps-core-components.png) Figure 1. Anypoint Studio のコアコンポーネントのリスト コンポーネントドキュメントについては、​[「コアコンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-components)​を参照してください。 ## [](#コネクタ)コネクタ コネクタは、サードパーティ API や標準インテグレーションプロトコルなどの外部リソースと MuleSoft アプリケーションのインテグレーションを容易にするために作成されたコンポーネントをグループにまとめたものです。コネクタにより、SaaS やオンプレミスアプリケーション、システム、サービスへの接続が可能になります。 たとえば、Salesforce Connector には、Salesforce プラットフォーム API を使用して多数のさまざまな操作を実行できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた Salesforce Connector およびその操作](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/about-mule-apps-salesforce-connector.png) Figure 2. Anypoint Studio でリストされた Salesforce Connector およびその操作 ## [](#モジュール)モジュール モジュールは、値の圧縮データの集約、Java 機能の使用、JSON を処理するための追加機能の使用などを可能にすることで、アプリケーションの柔軟性を高めるために作成されたコンポーネントをグループにまとめたものです。モジュールによって提供される機能は、従来のアプリケーションコーディングのレベルではさらに増えます。 たとえば、XML Module には XML ドキュメントからデータを抽出して処理できるコンポーネントが用意されています。 ![Anypoint Studio でリストされた XML Module およびそのコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/about-mule-apps-xml-module.png) Figure 3. Anypoint Studio でリストされた XML Module およびそのコンポーネント ## [](#関連情報)関連情報 - [コネクタとモジュール (Mule 4 用)](https://docs.mulesoft.com/connectors/) # Mule のサードパーティソフトウェア Mule Runtime Engine は、含まれるサードパーティソフトウェアのライブラリのサブセットに内部で連動しています。Mule アプリケーションには、サードパーティソフトウェアリストに含まれていない追加のサードパーティ連動関係 (Apache Maven から管理) が含まれている可能性もあります。 ## [](#サードパーティソフトウェアリスト)サードパーティソフトウェアリスト 次の表では、Mule のサードパーティソフトウェアをソフトウェアコンポーネント別に示しています。
ライセンス コンポーネント

MPL-1.1

com.googlecode.juniversalchardet : juniversalchardet : 1.0.3

CDDL-1.1

javax.annotation : javax.annotation-api : 1.2

CDDL-1.1

javax.json : javax.json-api : 1.0

EPL-2.0

javax.json : jakarta.mail : 1.6.3

CDDL-1.1

javax.transaction : javax.transaction-api : 1.3

Apache-2.0

javax.ws.rs : javax.ws.rs-api : 2.0

CDDL-1.0

javax.xml.stream : stax-api : 1.0-2

CDDL-1.1

org.glassfish : javax.json : 1.0.4

CDDL-1.1

org.glassfish.grizzly : connection-pool : 2.4.0-beta3

CDDL-1.1

org.glassfish.grizzly : grizzly-framework : 2.4.0-beta2

Apache-2.0

org.glassfish.grizzly : grizzly-http : 2.3.34

Apache-2.0

org.glassfish.grizzly : grizzly-http-server : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-websockets : 2.4.0-beta4

CDDL-1.1

org.glassfish.hk2 : hk2-api : 2.3.0-b05

CDDL-1.1

org.glassfish.hk2 : hk2-locator : 2.3.0-b05

CDDL-1.1

org.glassfish.hk2 : hk2-utils : 2.3.0-b05

CDDL-1.1

org.glassfish.hk2 : osgi-resource-locator : 1.0.1

Apache-2.0

org.glassfish.jersey.bundles.repackaged : jersey-guava : 2.11

CDDL-1.1

org.glassfish.jersey.core : jersey-common : 2.11

CDDL-1.1

org.jvnet.mimepull : mimepull : 1.9.7

Apache-1.1

org.dom4j : dom4j : 2.1.1

CDDL-1.1

javax.xml.bind : jaxb-api : 2.3.1

CDDL-1.1

javax.xml.bind : jaxb-api : 2.3.0

Apache-2.0

org.apache.cxf : cxf-rt-ws-policy : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-ws-rm : 3.3.5

BSD-2-Clause

org.codehaus.woodstox : stax2-api : 4.2

Apache-2.0

com.fasterxml.woodstox : woodstox-core : 5.3.0

BSD-2-Clause

org.reflections : reflections : 0.9.10

BSD-3-Clause

org.ow2.asm : asm : 7.1

BSD-3-Clause

com.esotericsoftware : minlog : 1.3.0

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.10.3

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.10.0

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.9.0

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.10.3

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.10.0

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.9.7

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.10.3

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.10.0

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.9.7

Apache-2.0

com.github.fge : btf : 1.2

Apache-2.0

com.github.java-json-tools : jackson-coreutils : 1.9

Apache-2.0

com.github.fge : msg-simple : 1.1

Apache-2.0

com.github.java-json-tools : json-schema-core : 1.2.10

Apache-2.0

com.github.java-json-tools : json-schema-validator : 2.2.10

Apache-2.0

opensymphony : oscore : 2.2.6

Apache-2.0

opensymphony : propertyset : 1.3

Apache-2.0

org.apache.poi : poi-ooxml-schemas : 4.1.1

Apache-2.0

org.apache.poi : poi-ooxml : 4.1.1

Apache-2.0

org.apache.poi : poi : 4.1.1

MIT

org.bouncycastle : bcpkix-jdk15on : 1.61

BSD-3-Clause

org.scala-lang : scala-reflect : 2.12.1

BSD-3-Clause

org.scala-lang : scala-reflect : 2.12.0

BSD-3-Clause

org.scala-lang.modules : scala-parser-combinators_2.12 : 1.1.1

MIT

org.typelevel : spire-macros_2.12 : 0.14.1

MIT

org.typelevel : spire_2.12 : 0.14.1

MIT

org.typelevel : machinist_2.12 : 0.6.1

CPL-1.0

wsdl4j : wsdl4j : 1.6.3

Apache-2.0

com.github.fge : uri-template : 0.9

EPL-1.0

com.mchange : c3p0 : 0.9.5.4

EPL-1.0

com.mchange : mchange-commons-java : 0.2.15

MPL-2.0

net.sf.saxon : Saxon-HE : 9.9.1-1

EPL-1.0

org.aspectj : aspectjrt : 1.9.2

EPL-1.0

org.aspectj : aspectjweaver : 1.9.2

EPL-1.0

org.eclipse.sisu : org.eclipse.sisu.plexus : 0.3.2

Apache-2.0

jboss : javassist : 3.7.ga

Apache-2.0

cglib : cglib-nodep : 3.2.10

Apache-2.0

com.chuusai : shapeless_2.12 : 2.3.3

BSD-3-Clause

com.esotericsoftware : kryo-shaded : 4.0.1

Apache-2.0

de.javakaffee : kryo-serializers : 0.45

Apache-2.0

com.fasterxml.jackson.module : jackson-module-jsonSchema : 2.10.0

MIT

org.mule.com.github.stephenc.eaio-uuid : uuid : 3.4.2-MULE-001

Apache-2.0

com.google.guava : guava : 25.1-jre

Apache-2.0

com.googlecode.libphonenumber : libphonenumber : 8.0.0

Apache-2.0

com.hazelcast : hazelcast : 3.12

Apache-2.0

com.hazelcast : hazelcast-client : 3.12

Apache-2.0

commons-beanutils : commons-beanutils : 1.9.4

Apache-2.0

commons-cli : commons-cli : 1.2

Apache-2.0

commons-codec : commons-codec : 1.13

Apache-2.0

commons-collections : commons-collections : 3.2.2

Apache-2.0

commons-dbutils : commons-dbutils : 1.7

Apache-2.0

commons-io : commons-io : 2.6

Apache-2.0

commons-lang : commons-lang : 2.6

Apache-2.0

commons-lang : commons-lang : 2.4

Apache-2.0

commons-logging : commons-logging : 1.1.3

Apache-2.0

commons-pool : commons-pool : 1.6

Apache-2.0

joda-time : joda-time : 2.9

Apache-2.0

joda-time : joda-time : 2.9.1

BSD-3-Clause

net.java.dev.stax-utils : stax-utils : 20070216

Apache-2.0

net.sf.ehcache : ehcache-core : 2.5.1

MIT

net.sf.jopt-simple : jopt-simple : 5.0.3

BSD-3-Clause

org.antlr : antlr-runtime : 3.5

BSD-3-Clause

org.antlr : stringtemplate : 3.2.1

Apache-2.0

org.apache.ant : ant : 1.10.5

Apache-2.0

org.apache.ant : ant-launcher : 1.10.5

Apache-2.0

org.apache.commons : commons-collections4 : 4.4

Apache-2.0

org.apache.commons : commons-lang3 : 3.4

Apache-2.0

org.apache.commons : commons-lang3 : 3.8.1

Apache-2.0

org.apache.cxf : cxf-rt-bindings-soap : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-databinding-jaxb : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-frontend-simple : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-management : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-ws-addr : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-ws-security : 3.3.5

Apache-2.0

org.apache.geronimo.specs : geronimo-j2ee-connector_1.5_spec : 2.0.0

Apache-2.0

org.apache.geronimo.specs : geronimo-servlet_3.0_spec : 1.0

Apache-2.0

org.apache.httpcomponents : httpclient : 4.5.3

Apache-2.0

org.apache.httpcomponents : httpcore : 4.4.6

Apache-2.0

org.apache.logging.log4j : log4j-1.2-api : 2.13.1

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.13.1

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.11.0

Apache-2.0

org.apache.logging.log4j : log4j-core : 2.13.1

Apache-2.0

org.apache.logging.log4j : log4j-core : 2.11.0

Apache-2.0

org.apache.logging.log4j : log4j-slf4j-impl : 2.13.1

Apache-2.0

org.apache.maven : maven-artifact : 3.3.9

Apache-2.0

org.apache.neethi : neethi : 3.1.1

Apache-2.0

org.apache.santuario : xmlsec : 2.1.4

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.2.5

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.2.1

Apache-2.0

org.apache.xmlbeans : xmlbeans : 3.1.0

Apache-2.0

org.codehaus.groovy : groovy-all : jar : indy : 2.4.15

Apache-2.0

org.codehaus.plexus : plexus-utils : 3.0.24

Apache-2.0

org.glassfish.grizzly : grizzly-http-client : 1.14

Apache-2.0

org.mapdb : mapdb : 1.0.6

Apache-2.0

org.objenesis : objenesis : 2.5.1

Apache-2.0

org.parboiled : parboiled_2.12 : 2.1.5

Apache-2.0

org.quartz-scheduler : quartz : 2.3.2

MIT

org.slf4j : jcl-over-slf4j : 1.7.30

MIT

org.slf4j : slf4j-api : 1.7.30

MIT

org.slf4j : slf4j-api : 1.7.25

Apache-2.0

org.springframework : spring-aop : 5.1.6.RELEASE

Apache-2.0

org.springframework : spring-beans : 5.1.6.RELEASE

Apache-2.0

org.springframework : spring-context : 5.1.6.RELEASE

Apache-2.0

org.springframework : spring-context-support : 5.1.6.RELEASE

Apache-2.0

org.springframework : spring-core : 5.1.6.RELEASE

Apache-2.0

org.springframework : spring-expression : 5.1.6.RELEASE

Apache-2.0

org.typelevel : macro-compat_2.12 : 1.1.1

Apache-2.0

om.beust : jcommander : 1.69

Apache-2.0

com.conversantmedia : disruptor : 1.2.10

Apache-2.0

com.fasterxml : aalto-xml : 1.0.0

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-yaml : 2.10.3

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-yaml : 2.10.0

Apache-2.0

com.github.ben-manes.caffeine : caffeine : 2.8.0

Apache-2.0

com.github.jknack : handlebars : 4.0.6

Apache-2.0

com.github.jknack : handlebars-proto : 2.0.0

BSD-3-Clause

com.github.virtuald : curvesapi : 1.06

LGPL-3.0

com.google.code.findbugs : annotations : 3.0.0

Apache-2.0

com.google.code.findbugs : jsr305 : 3.0.2

Apache-2.0

com.google.code.gson : gson : 2.8.5

Apache-2.0

com.google.code.gson : gson : 2.3.1

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.3.3

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.1.3

Apache-2.0

com.google.j2objc : j2objc-annotations : 1.1

Apache-2.0

com.lmax : disruptor : 3.3.7

Apache-2.0

com.monitorjbl : xlsx-streamer : 2.1.0

Apache-2.0

com.rackspace.apache : xerces2-xsd11 : 2.11.2

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.1

CDDL-1.1

com.sun.activation : javax.activation : 1.2.0

EDL-1.0

com.sun.istack : istack-commons-runtime : 3.0.10

EDL-1.0

com.sun.istack : istack-commons-runtime : 3.0.8

CDDL-1.1

com.sun.istack : istack-commons-runtime : 3.0.7

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.4

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.3

EDL-1.0

com.sun.mail : mailapi : 1.6.4

CDDL-1.1

com.sun.xml.bind : jaxb-core : 2.3.0.1

CDDL-1.1

com.sun.xml.bind : jaxb-impl : 2.3.1

Apache-2.0

com.sun.xml.fastinfoset : FastInfoset : 1.2.16

Apache-2.0

com.sun.xml.fastinfoset : FastInfoset : 1.2.15

CDDL-1.1

com.sun.xml.messaging.saaj : saaj-impl : 1.3.28

Apache-2.0

com.typesafe : config : 1.3.1

MIT

com.vdurmont : semver4j : 3.1.0

Apache-2.0

com.zaxxer : HikariCP-java7 : 2.4.13

MIT

: handlebars : 4.0.5

Apache-2.0

io.dropwizard.metrics : metrics-core : 3.1.2

Apache-2.0

io.projectreactor : reactor-core : 3.2.12.RELEASE

Apache-2.0

io.projectreactor.addons : reactor-extra : 3.2.3.RELEASE

Apache-2.0

it.unimi.dsi : fastutil : 8.1.1

EDL-1.0

jakarta.activation : jakarta.activation-api : 1.2.1

EDL-1.0

jakarta.xml.bind : jakarta.xml.bind-api : 2.3.2

CDDL-1.1

javax.activation : activation : 1.1

CDDL-1.1

javax.activation : javax.activation-api : 1.2.0

Apache-2.0

javax.inject : javax.inject : 1

CDDL-1.1

javax.jms : javax.jms-api : 2.0.1

CDDL-1.1

javax.jws : javax.jws-api : 1.1

Apache-2.0

javax.validation : validation-api : 1.1.0.Final

CDDL-1.1

javax.xml.soap : javax.xml.soap-api : 1.4.0

CDDL-1.1

javax.xml.ws : jaxws-api : 2.3.1

CDDL-1.1

javax.xml.ws : jaxws-api : 2.3.0

Apache-2.0

net.bytebuddy : byte-buddy : 1.10.7

Apache-2.0

net.jodah : failsafe : 2.1.1

Apache-2.0

net.sf.ehcache : sizeof-agent : 1.0.1

Apache-2.0

net.shibboleth.utilities : java-support : 7.3.0

BSD-3-Clause

org.antlr : antlr4-runtime : 4.5.1-1

Apache-2.0

org.apache.avro : avro : 1.10.0

Apache-2.0

org.apache.commons : commons-compress : 1.19

Apache-2.0

org.apache.commons : commons-math3 : 3.6.1

Apache-2.0

org.apache.commons : commons-pool2 : 2.4.2

Apache-2.0

org.apache.commons : commons-pool2 : 2.6.2

Apache-2.0

org.apache.commons : commons-text : 1.3

Apache-2.0

org.apache.cxf : cxf-core : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-security : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-security-saml : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-wsdl : 3.3.5

Apache-2.0

org.apache.geronimo.javamail : geronimo-javamail_1.4_mail : 1.8.4

Apache-2.0

org.apache.httpcomponents : fluent-hc : 4.3.5

Apache-2.0

org.apache.logging.log4j : log4j-api-scala_2.12 : 11.0

Apache-2.0

org.apache.maven : maven-aether-provider : 3.3.9

Apache-2.0

org.apache.maven : maven-builder-support : 3.3.9

Apache-2.0

org.apache.maven : maven-model : 3.3.9

Apache-2.0

org.apache.maven : maven-model-builder : 3.3.9

Apache-2.0

org.apache.maven : maven-repository-metadata : 3.3.9

Apache-2.0

org.apache.maven : maven-settings : 3.3.9

Apache-2.0

org.apache.maven : maven-settings-builder : 3.3.9

Apache-2.0

org.apache.velocity : velocity : 1.7

Apache-2.0

org.apache.wss4j : wss4j-bindings : 2.2.4

Apache-2.0

org.apache.wss4j : wss4j-policy : 2.2.4

Apache-2.0

org.apache.wss4j : wss4j-ws-security-common : 2.2.4

Apache-2.0

org.apache.wss4j : wss4j-ws-security-dom : 2.2.4

Apache-2.0

org.apache.wss4j : wss4j-ws-security-policy-stax : 2.2.4

Apache-2.0

org.apache.wss4j : wss4j-ws-security-stax : 2.2.4

Apache-2.0

org.bouncycastle : bcpg-jdk15on : 1.61

MIT

org.bouncycastle : bcprov-ext-jdk15on : 1.61

MIT

org.bouncycastle : bcprov-jdk15on : 1.64

MIT

org.bouncycastle : bcprov-jdk15on : 1.61

MIT

org.checkerframework : checker-qual : 2.10.0

MIT

org.checkerframework : checker-qual : 2.0.0

MIT

org.codehaus.mojo : animal-sniffer-annotations : 1.14

Apache-2.0

org.codehaus.plexus : plexus-component-annotations : 1.6

Apache-2.0

org.codehaus.plexus : plexus-interpolation : 1.21

Apache-2.0

org.cryptacular : cryptacular : 1.2.4

EPL-1.0

org.eclipse.aether : aether-api : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-connector-basic : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-impl : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-spi : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-transport-file : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-transport-http : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-util : 1.0.2.v20150114

Apache-2.0

org.everit.json : org.everit.json.schema : 1.5.1

Apache-2.0

org.glassfish.grizzly : grizzly-http-servlet : 2.3.34

CDDL-1.1

org.glassfish.jaxb : jaxb-runtime : 2.3.1

EDL-1.0

org.glassfish.jaxb : jaxb-runtime : 2.3.2

CDDL-1.1

org.glassfish.jaxb : txw2 : 2.3.1

EDL-1.0

org.glassfish.jaxb : txw2 : 2.3.2

Apache-2.0

org.jasypt : jasypt : 1.9.3

Apache-2.0

org.jetbrains : annotations : 13.0

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib : 1.1.3-2

EPL-2.0

org.jgrapht : jgrapht-core : 1.3.1

Apache-2.0

org.jheaps : jheaps : 0.10

JSON

org.json : json : 20160810

MIT

org.jsoup : jsoup : 1.11.3

CDDL-1.1

org.jvnet.staxex : stax-ex : 1.7.8

CDDL-1.1

org.jvnet.staxex : stax-ex : 1.8

BSD-3-Clause

org.mozilla : rhino : 1.7.12

Apache-2.0

org.opensaml : opensaml-core : 3.3.0

Apache-2.0

org.opensaml : opensaml-profile-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-saml-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-saml-impl : 3.3.0

Apache-2.0

org.opensaml : opensaml-security-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-security-impl : 3.3.0

Apache-2.0

org.opensaml : opensaml-soap-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-xacml-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-xacml-impl : 3.3.0

Apache-2.0

org.opensaml : opensaml-xacml-saml-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-xacml-saml-impl : 3.3.0

Apache-2.0

org.opensaml : opensaml-xmlsec-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-xmlsec-impl : 3.3.0

Apache-2.0

org.raml : raml-parser-2 : 1.0.48

Apache-2.0

org.raml : yagi : 1.0.48

CC0-1.0

org.reactivestreams : reactive-streams : 1.0.2

Apache-2.0

org.scala-lang : scala-library : 2.12.10

MIT

org.slf4j : jul-to-slf4j : 1.7.30

MIT

org.slf4j : slf4j-ext : 1.7.30

Apache-2.0

org.sonatype.plexus : plexus-cipher : 1.4

Apache-2.0

org.sonatype.plexus : plexus-sec-dispatcher : 1.3

Apache-2.0

org.springframework : spring-jcl : 5.1.6.RELEASE

MIT

org.typelevel : algebra_2.12 : 0.7.0

MIT

org.typelevel : cats-kernel_2.12 : 0.9.0

Apache-2.0

org.vibur : vibur-object-pool : 23.0

Apache-2.0

org.yaml : snakeyaml : 1.26
## [](#ライセンス情報)ライセンス情報 各ライセンス種別に関する情報は次の場所にあります。 - `http://aopalliance.sourceforge.net/`​ (AOP) - `https://opensource.org/licenses/APACHE-2.0`​ (Apache-2.0) - `https://en.wikipedia.org/wiki/BSD_licenses`​ (BSD) - `https://opensource.org/licenses/BSD-2-Clause`​ (BSD-2-Clause) - `https://opensource.org/licenses/BSD-3-Clause`​ (BSD-3-Clause) - `https://creativecommons.org/licenses/by-sa/3.0/us/`​ (CC-BY-SA-3.0) - `https://opensource.org/licenses/CDDL-1.0`​ (CDDL-1.0) - `https://spdx.org/licenses/CDDL-1.1.html`​ (CDDL-1.1) - `https://opensource.org/licenses/CPAL-1.0`​ (CPAL-1.0) - `https://opensource.org/licenses/CPL-1.0`​ (CPL-1.0) - `https://opensource.org/licenses/EPL-2.0`​ (EPL-2.0) - `http://source.icu-project.org/repos/icu/icu/trunk/LICENSE`​ (ICU) - `https://github.com/stleary/JSON-java/blob/master/LICENSE`​ (JSON) - `https://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html`​ (LGPL-2.0) - `https://opensource.org/licenses/LGPL-2.1`​ (LGPL-2.1) - `https://opensource.org/licenses/LGPL-3.0`​ (LGPL-3.0) - `https://opensource.org/licenses/MIT`​ (MIT) - `https://opensource.org/licenses/MPL-1.1`​ (MPL-1.1) - `https://opensource.org/licenses/MPL-2.0`​ (MPL-2.0) - `https://www.oasis-open.org/resources/open-repositories/licenses`​ (OASIS) - `http://www.jython.org/license.html`​ (SMLNJ (Jython)) - `https://opensource.org/licenses/SPL-1.0`​ (Sun-IP (SPL-1.0)) - `https://opensource.org/licenses/W3C`​ (W3C) - `http://www.randelshofer.ch/`​ (WernerRandelshofer) - `https://www.w3.org/Submission/ws-addressing/`​ (WS-Addressing-2004/03 および /08) - `https://opensource.org/licenses/Zlib`​ (zlib) # Mule のサードパーティソフトウェア Mule Runtime Engine は、含まれるサードパーティソフトウェアのライブラリのサブセットに内部で連動しています。Mule アプリケーションには、サードパーティソフトウェアリストに含まれていない追加のサードパーティ連動関係 (Apache Maven から管理) が含まれている可能性もあります。 ## [](#サードパーティソフトウェアリスト)サードパーティソフトウェアリスト 次の表では、Mule のサードパーティソフトウェアをソフトウェアコンポーネント別に示しています。
ライセンス コンポーネント

MPL-1.1

com.googlecode.juniversalchardet : juniversalchardet : 1.0.3

CDDL-1.1

javax.annotation : javax.annotation-api : 1.2

CDDL-1.1

javax.json : javax.json-api : 1.0

EPL-2.0

javax.json : jakarta.mail : 1.6.3

CDDL-1.1

javax.transaction : javax.transaction-api : 1.3

Apache-2.0

javax.ws.rs : javax.ws.rs-api : 2.0

CDDL-1.0

javax.xml.stream : stax-api : 1.0-2

CDDL-1.1

org.glassfish : javax.json : 1.0.4

CDDL-1.1

org.glassfish.grizzly : connection-pool : 2.4.0-beta3

CDDL-1.1

org.glassfish.grizzly : grizzly-framework : 2.4.0-beta2

Apache-2.0

org.glassfish.grizzly : grizzly-http : 2.3.34

Apache-2.0

org.glassfish.grizzly : grizzly-http-server : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-websockets : 2.4.0-beta4

CDDL-1.1

org.glassfish.hk2 : hk2-api : 2.3.0-b05

CDDL-1.1

org.glassfish.hk2 : hk2-locator : 2.3.0-b05

CDDL-1.1

org.glassfish.hk2 : hk2-utils : 2.3.0-b05

CDDL-1.1

org.glassfish.hk2 : osgi-resource-locator : 1.0.1

Apache-2.0

org.glassfish.jersey.bundles.repackaged : jersey-guava : 2.11

CDDL-1.1

org.glassfish.jersey.core : jersey-common : 2.11

CDDL-1.1

org.jvnet.mimepull : mimepull : 1.9.7

Apache-1.1

org.dom4j : dom4j : 2.1.1

CDDL-1.1

javax.xml.bind : jaxb-api : 2.3.1

CDDL-1.1

javax.xml.bind : jaxb-api : 2.3.0

Apache-2.0

org.apache.cxf : cxf-rt-ws-policy : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-ws-rm : 3.3.5

BSD-2-Clause

org.codehaus.woodstox : stax2-api : 4.2

Apache-2.0

com.fasterxml.woodstox : woodstox-core : 5.3.0

BSD-2-Clause

org.reflections : reflections : 0.9.10

BSD-3-Clause

org.ow2.asm : asm : 7.1

BSD-3-Clause

com.esotericsoftware : minlog : 1.3.0

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.10.3

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.10.0

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.9.0

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.10.3

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.10.0

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.9.7

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.10.3

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.10.0

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.9.7

Apache-2.0

com.github.fge : btf : 1.2

Apache-2.0

com.github.java-json-tools : jackson-coreutils : 1.9

Apache-2.0

com.github.fge : msg-simple : 1.1

Apache-2.0

com.github.java-json-tools : json-schema-core : 1.2.10

Apache-2.0

com.github.java-json-tools : json-schema-validator : 2.2.10

Apache-2.0

opensymphony : oscore : 2.2.6

Apache-2.0

opensymphony : propertyset : 1.3

Apache-2.0

org.apache.poi : poi-ooxml-schemas : 4.1.1

Apache-2.0

org.apache.poi : poi-ooxml : 4.1.1

Apache-2.0

org.apache.poi : poi : 4.1.1

MIT

org.bouncycastle : bcpkix-jdk15on : 1.61

BSD-3-Clause

org.scala-lang : scala-reflect : 2.12.1

BSD-3-Clause

org.scala-lang : scala-reflect : 2.12.0

BSD-3-Clause

org.scala-lang.modules : scala-parser-combinators_2.12 : 1.1.1

MIT

org.typelevel : spire-macros_2.12 : 0.14.1

MIT

org.typelevel : spire_2.12 : 0.14.1

MIT

org.typelevel : machinist_2.12 : 0.6.1

CPL-1.0

wsdl4j : wsdl4j : 1.6.3

Apache-2.0

com.github.fge : uri-template : 0.9

EPL-1.0

com.mchange : c3p0 : 0.9.5.4

EPL-1.0

com.mchange : mchange-commons-java : 0.2.15

MPL-2.0

net.sf.saxon : Saxon-HE : 9.9.1-1

EPL-1.0

org.aspectj : aspectjrt : 1.9.2

EPL-1.0

org.aspectj : aspectjweaver : 1.9.2

EPL-1.0

org.eclipse.sisu : org.eclipse.sisu.plexus : 0.3.2

Apache-2.0

jboss : javassist : 3.7.ga

Apache-2.0

cglib : cglib-nodep : 3.2.10

Apache-2.0

com.chuusai : shapeless_2.12 : 2.3.3

BSD-3-Clause

com.esotericsoftware : kryo-shaded : 4.0.1

Apache-2.0

de.javakaffee : kryo-serializers : 0.45

Apache-2.0

com.fasterxml.jackson.module : jackson-module-jsonSchema : 2.10.0

MIT

org.mule.com.github.stephenc.eaio-uuid : uuid : 3.4.2-MULE-001

Apache-2.0

com.google.guava : guava : 25.1-jre

Apache-2.0

com.googlecode.libphonenumber : libphonenumber : 8.0.0

Apache-2.0

com.hazelcast : hazelcast : 3.12

Apache-2.0

com.hazelcast : hazelcast-client : 3.12

Apache-2.0

commons-beanutils : commons-beanutils : 1.9.4

Apache-2.0

commons-cli : commons-cli : 1.2

Apache-2.0

commons-codec : commons-codec : 1.13

Apache-2.0

commons-collections : commons-collections : 3.2.2

Apache-2.0

commons-dbutils : commons-dbutils : 1.7

Apache-2.0

commons-io : commons-io : 2.6

Apache-2.0

commons-lang : commons-lang : 2.6

Apache-2.0

commons-lang : commons-lang : 2.4

Apache-2.0

commons-logging : commons-logging : 1.1.3

Apache-2.0

commons-pool : commons-pool : 1.6

Apache-2.0

joda-time : joda-time : 2.9

Apache-2.0

joda-time : joda-time : 2.9.1

BSD-3-Clause

net.java.dev.stax-utils : stax-utils : 20070216

Apache-2.0

net.sf.ehcache : ehcache-core : 2.5.1

MIT

net.sf.jopt-simple : jopt-simple : 5.0.3

BSD-3-Clause

org.antlr : antlr-runtime : 3.5

BSD-3-Clause

org.antlr : stringtemplate : 3.2.1

Apache-2.0

org.apache.ant : ant : 1.10.5

Apache-2.0

org.apache.ant : ant-launcher : 1.10.5

Apache-2.0

org.apache.commons : commons-collections4 : 4.4

Apache-2.0

org.apache.commons : commons-lang3 : 3.4

Apache-2.0

org.apache.commons : commons-lang3 : 3.8.1

Apache-2.0

org.apache.cxf : cxf-rt-bindings-soap : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-databinding-jaxb : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-frontend-simple : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-management : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-ws-addr : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-ws-security : 3.3.5

Apache-2.0

org.apache.geronimo.specs : geronimo-j2ee-connector_1.5_spec : 2.0.0

Apache-2.0

org.apache.geronimo.specs : geronimo-servlet_3.0_spec : 1.0

Apache-2.0

org.apache.httpcomponents : httpclient : 4.5.3

Apache-2.0

org.apache.httpcomponents : httpcore : 4.4.6

Apache-2.0

org.apache.logging.log4j : log4j-1.2-api : 2.13.1

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.13.1

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.11.0

Apache-2.0

org.apache.logging.log4j : log4j-core : 2.13.1

Apache-2.0

org.apache.logging.log4j : log4j-core : 2.11.0

Apache-2.0

org.apache.logging.log4j : log4j-slf4j-impl : 2.13.1

Apache-2.0

org.apache.maven : maven-artifact : 3.3.9

Apache-2.0

org.apache.neethi : neethi : 3.1.1

Apache-2.0

org.apache.santuario : xmlsec : 2.1.4

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.2.5

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.2.1

Apache-2.0

org.apache.xmlbeans : xmlbeans : 3.1.0

Apache-2.0

org.codehaus.groovy : groovy-all : jar : indy : 2.4.15

Apache-2.0

org.codehaus.plexus : plexus-utils : 3.0.24

Apache-2.0

org.glassfish.grizzly : grizzly-http-client : 1.14

Apache-2.0

org.mapdb : mapdb : 1.0.6

Apache-2.0

org.objenesis : objenesis : 2.5.1

Apache-2.0

org.parboiled : parboiled_2.12 : 2.1.5

Apache-2.0

org.quartz-scheduler : quartz : 2.3.2

MIT

org.slf4j : jcl-over-slf4j : 1.7.30

MIT

org.slf4j : slf4j-api : 1.7.30

MIT

org.slf4j : slf4j-api : 1.7.25

Apache-2.0

org.springframework : spring-aop : 5.1.6.RELEASE

Apache-2.0

org.springframework : spring-beans : 5.1.6.RELEASE

Apache-2.0

org.springframework : spring-context : 5.1.6.RELEASE

Apache-2.0

org.springframework : spring-context-support : 5.1.6.RELEASE

Apache-2.0

org.springframework : spring-core : 5.1.6.RELEASE

Apache-2.0

org.springframework : spring-expression : 5.1.6.RELEASE

Apache-2.0

org.typelevel : macro-compat_2.12 : 1.1.1

Apache-2.0

om.beust : jcommander : 1.69

Apache-2.0

com.conversantmedia : disruptor : 1.2.10

Apache-2.0

com.fasterxml : aalto-xml : 1.0.0

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-yaml : 2.10.3

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-yaml : 2.10.0

Apache-2.0

com.github.ben-manes.caffeine : caffeine : 2.8.0

Apache-2.0

com.github.jknack : handlebars : 4.0.6

Apache-2.0

com.github.jknack : handlebars-proto : 2.0.0

BSD-3-Clause

com.github.virtuald : curvesapi : 1.06

LGPL-3.0

com.google.code.findbugs : annotations : 3.0.0

Apache-2.0

com.google.code.findbugs : jsr305 : 3.0.2

Apache-2.0

com.google.code.gson : gson : 2.8.5

Apache-2.0

com.google.code.gson : gson : 2.3.1

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.3.3

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.1.3

Apache-2.0

com.google.j2objc : j2objc-annotations : 1.1

Apache-2.0

com.lmax : disruptor : 3.3.7

Apache-2.0

com.monitorjbl : xlsx-streamer : 2.1.0

Apache-2.0

com.rackspace.apache : xerces2-xsd11 : 2.11.2

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.1

CDDL-1.1

com.sun.activation : javax.activation : 1.2.0

EDL-1.0

com.sun.istack : istack-commons-runtime : 3.0.10

EDL-1.0

com.sun.istack : istack-commons-runtime : 3.0.8

CDDL-1.1

com.sun.istack : istack-commons-runtime : 3.0.7

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.4

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.3

EDL-1.0

com.sun.mail : mailapi : 1.6.4

CDDL-1.1

com.sun.xml.bind : jaxb-core : 2.3.0.1

CDDL-1.1

com.sun.xml.bind : jaxb-impl : 2.3.1

Apache-2.0

com.sun.xml.fastinfoset : FastInfoset : 1.2.16

Apache-2.0

com.sun.xml.fastinfoset : FastInfoset : 1.2.15

CDDL-1.1

com.sun.xml.messaging.saaj : saaj-impl : 1.3.28

Apache-2.0

com.typesafe : config : 1.3.1

MIT

com.vdurmont : semver4j : 3.1.0

Apache-2.0

com.zaxxer : HikariCP-java7 : 2.4.13

MIT

: handlebars : 4.0.5

Apache-2.0

io.dropwizard.metrics : metrics-core : 3.1.2

Apache-2.0

io.projectreactor : reactor-core : 3.2.12.RELEASE

Apache-2.0

io.projectreactor.addons : reactor-extra : 3.2.3.RELEASE

Apache-2.0

it.unimi.dsi : fastutil : 8.1.1

EDL-1.0

jakarta.activation : jakarta.activation-api : 1.2.1

EDL-1.0

jakarta.xml.bind : jakarta.xml.bind-api : 2.3.2

CDDL-1.1

javax.activation : activation : 1.1

CDDL-1.1

javax.activation : javax.activation-api : 1.2.0

Apache-2.0

javax.inject : javax.inject : 1

CDDL-1.1

javax.jms : javax.jms-api : 2.0.1

CDDL-1.1

javax.jws : javax.jws-api : 1.1

Apache-2.0

javax.validation : validation-api : 1.1.0.Final

CDDL-1.1

javax.xml.soap : javax.xml.soap-api : 1.4.0

CDDL-1.1

javax.xml.ws : jaxws-api : 2.3.1

CDDL-1.1

javax.xml.ws : jaxws-api : 2.3.0

Apache-2.0

net.bytebuddy : byte-buddy : 1.10.7

Apache-2.0

net.jodah : failsafe : 2.1.1

Apache-2.0

net.sf.ehcache : sizeof-agent : 1.0.1

Apache-2.0

net.shibboleth.utilities : java-support : 7.3.0

BSD-3-Clause

org.antlr : antlr4-runtime : 4.5.1-1

Apache-2.0

org.apache.avro : avro : 1.10.0

Apache-2.0

org.apache.commons : commons-compress : 1.19

Apache-2.0

org.apache.commons : commons-math3 : 3.6.1

Apache-2.0

org.apache.commons : commons-pool2 : 2.4.2

Apache-2.0

org.apache.commons : commons-pool2 : 2.6.2

Apache-2.0

org.apache.commons : commons-text : 1.3

Apache-2.0

org.apache.cxf : cxf-core : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-security : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-security-saml : 3.3.5

Apache-2.0

org.apache.cxf : cxf-rt-wsdl : 3.3.5

Apache-2.0

org.apache.geronimo.javamail : geronimo-javamail_1.4_mail : 1.8.4

Apache-2.0

org.apache.httpcomponents : fluent-hc : 4.3.5

Apache-2.0

org.apache.logging.log4j : log4j-api-scala_2.12 : 11.0

Apache-2.0

org.apache.maven : maven-aether-provider : 3.3.9

Apache-2.0

org.apache.maven : maven-builder-support : 3.3.9

Apache-2.0

org.apache.maven : maven-model : 3.3.9

Apache-2.0

org.apache.maven : maven-model-builder : 3.3.9

Apache-2.0

org.apache.maven : maven-repository-metadata : 3.3.9

Apache-2.0

org.apache.maven : maven-settings : 3.3.9

Apache-2.0

org.apache.maven : maven-settings-builder : 3.3.9

Apache-2.0

org.apache.velocity : velocity : 1.7

Apache-2.0

org.apache.wss4j : wss4j-bindings : 2.2.4

Apache-2.0

org.apache.wss4j : wss4j-policy : 2.2.4

Apache-2.0

org.apache.wss4j : wss4j-ws-security-common : 2.2.4

Apache-2.0

org.apache.wss4j : wss4j-ws-security-dom : 2.2.4

Apache-2.0

org.apache.wss4j : wss4j-ws-security-policy-stax : 2.2.4

Apache-2.0

org.apache.wss4j : wss4j-ws-security-stax : 2.2.4

Apache-2.0

org.bouncycastle : bcpg-jdk15on : 1.61

MIT

org.bouncycastle : bcprov-ext-jdk15on : 1.61

MIT

org.bouncycastle : bcprov-jdk15on : 1.64

MIT

org.bouncycastle : bcprov-jdk15on : 1.61

MIT

org.checkerframework : checker-qual : 2.10.0

MIT

org.checkerframework : checker-qual : 2.0.0

MIT

org.codehaus.mojo : animal-sniffer-annotations : 1.14

Apache-2.0

org.codehaus.plexus : plexus-component-annotations : 1.6

Apache-2.0

org.codehaus.plexus : plexus-interpolation : 1.21

Apache-2.0

org.cryptacular : cryptacular : 1.2.4

EPL-1.0

org.eclipse.aether : aether-api : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-connector-basic : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-impl : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-spi : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-transport-file : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-transport-http : 1.0.2.v20150114

EPL-1.0

org.eclipse.aether : aether-util : 1.0.2.v20150114

Apache-2.0

org.everit.json : org.everit.json.schema : 1.5.1

Apache-2.0

org.glassfish.grizzly : grizzly-http-servlet : 2.3.34

CDDL-1.1

org.glassfish.jaxb : jaxb-runtime : 2.3.1

EDL-1.0

org.glassfish.jaxb : jaxb-runtime : 2.3.2

CDDL-1.1

org.glassfish.jaxb : txw2 : 2.3.1

EDL-1.0

org.glassfish.jaxb : txw2 : 2.3.2

Apache-2.0

org.jasypt : jasypt : 1.9.3

Apache-2.0

org.jetbrains : annotations : 13.0

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib : 1.1.3-2

EPL-2.0

org.jgrapht : jgrapht-core : 1.3.1

Apache-2.0

org.jheaps : jheaps : 0.10

JSON

org.json : json : 20160810

MIT

org.jsoup : jsoup : 1.11.3

CDDL-1.1

org.jvnet.staxex : stax-ex : 1.7.8

CDDL-1.1

org.jvnet.staxex : stax-ex : 1.8

BSD-3-Clause

org.mozilla : rhino : 1.7.12

Apache-2.0

org.opensaml : opensaml-core : 3.3.0

Apache-2.0

org.opensaml : opensaml-profile-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-saml-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-saml-impl : 3.3.0

Apache-2.0

org.opensaml : opensaml-security-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-security-impl : 3.3.0

Apache-2.0

org.opensaml : opensaml-soap-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-xacml-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-xacml-impl : 3.3.0

Apache-2.0

org.opensaml : opensaml-xacml-saml-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-xacml-saml-impl : 3.3.0

Apache-2.0

org.opensaml : opensaml-xmlsec-api : 3.3.0

Apache-2.0

org.opensaml : opensaml-xmlsec-impl : 3.3.0

Apache-2.0

org.raml : raml-parser-2 : 1.0.48

Apache-2.0

org.raml : yagi : 1.0.48

CC0-1.0

org.reactivestreams : reactive-streams : 1.0.2

Apache-2.0

org.scala-lang : scala-library : 2.12.10

MIT

org.slf4j : jul-to-slf4j : 1.7.30

MIT

org.slf4j : slf4j-ext : 1.7.30

Apache-2.0

org.sonatype.plexus : plexus-cipher : 1.4

Apache-2.0

org.sonatype.plexus : plexus-sec-dispatcher : 1.3

Apache-2.0

org.springframework : spring-jcl : 5.1.6.RELEASE

MIT

org.typelevel : algebra_2.12 : 0.7.0

MIT

org.typelevel : cats-kernel_2.12 : 0.9.0

Apache-2.0

org.vibur : vibur-object-pool : 23.0

Apache-2.0

org.yaml : snakeyaml : 1.26
## [](#ライセンス情報)ライセンス情報 各ライセンス種別に関する情報は次の場所にあります。 - `http://aopalliance.sourceforge.net/`​ (AOP) - `https://opensource.org/licenses/APACHE-2.0`​ (Apache-2.0) - `https://en.wikipedia.org/wiki/BSD_licenses`​ (BSD) - `https://opensource.org/licenses/BSD-2-Clause`​ (BSD-2-Clause) - `https://opensource.org/licenses/BSD-3-Clause`​ (BSD-3-Clause) - `https://creativecommons.org/licenses/by-sa/3.0/us/`​ (CC-BY-SA-3.0) - `https://opensource.org/licenses/CDDL-1.0`​ (CDDL-1.0) - `https://spdx.org/licenses/CDDL-1.1.html`​ (CDDL-1.1) - `https://opensource.org/licenses/CPAL-1.0`​ (CPAL-1.0) - `https://opensource.org/licenses/CPL-1.0`​ (CPL-1.0) - `https://opensource.org/licenses/EPL-2.0`​ (EPL-2.0) - `http://source.icu-project.org/repos/icu/icu/trunk/LICENSE`​ (ICU) - `https://github.com/stleary/JSON-java/blob/master/LICENSE`​ (JSON) - `https://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html`​ (LGPL-2.0) - `https://opensource.org/licenses/LGPL-2.1`​ (LGPL-2.1) - `https://opensource.org/licenses/LGPL-3.0`​ (LGPL-3.0) - `https://opensource.org/licenses/MIT`​ (MIT) - `https://opensource.org/licenses/MPL-1.1`​ (MPL-1.1) - `https://opensource.org/licenses/MPL-2.0`​ (MPL-2.0) - `https://www.oasis-open.org/resources/open-repositories/licenses`​ (OASIS) - `http://www.jython.org/license.html`​ (SMLNJ (Jython)) - `https://opensource.org/licenses/SPL-1.0`​ (Sun-IP (SPL-1.0)) - `https://opensource.org/licenses/W3C`​ (W3C) - `http://www.randelshofer.ch/`​ (WernerRandelshofer) - `https://www.w3.org/Submission/ws-addressing/`​ (WS-Addressing-2004/03 および /08) - `https://opensource.org/licenses/Zlib`​ (zlib) # Mule のサードパーティソフトウェア Mule Runtime Engine は、含まれるサードパーティソフトウェアのライブラリのサブセットに内部で連動しています。Mule アプリケーションには、サードパーティソフトウェアリストに含まれていない追加のサードパーティ連動関係 (Apache Maven から管理) が含まれている可能性もあります。 ## [](#サードパーティソフトウェアリスト)サードパーティソフトウェアリスト 次の表では、Mule のサードパーティソフトウェアをソフトウェアコンポーネント別に示しています。
ライセンス コンポーネント

Apache-2.0

com.beust : jcommander : 1.78

Apache-2.0

com.chuusai : shapeless_2.12 : 2.3.3

Apache-2.0

com.conversantmedia : disruptor : 1.2.10

Apache-2.0

com.damnhandy : handy-uri-templates : 2.1.8

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.15.0

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.15.0

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-yaml : 2.15.0

Apache-2.0

com.fasterxml.jackson.module : jackson-module-jsonSchema : 2.15.0

Apache-2.0

com.google.code.gson : gson : 2.8.9

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.3.3

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.5.1

Apache-2.0

com.google.guava : failureaccess : 1.0.1

Apache-2.0

com.google.j2objc : j2objc-annotations : 2.8

Apache-2.0

com.googlecode.libphonenumber : libphonenumber : 8.0.0

Apache-2.0

com.lmax : disruptor : 3.4.3

Apache-2.0

com.squareup.okhttp3 : okhttp : 4.11.0

Apache-2.0

com.squareup.okio : okio : 3.2.0

Apache-2.0

com.squareup.okio : okio-jvm : 3.2.0

Apache-2.0

com.zaxxer : HikariCP-java7 : 2.4.13

Apache-2.0

commons-beanutils : commons-beanutils : 1.9.4

Apache-2.0

commons-cli : commons-cli : 1.2

Apache-2.0

commons-collections : commons-collections : 3.2.2

Apache-2.0

commons-digester : commons-digester : 2.1

Apache-2.0

commons-io : commons-io : 2.13.0

Apache-2.0

commons-io : commons-io : 2.7

Apache-2.0

commons-lang : commons-lang : 2.6

Apache-2.0

commons-logging : commons-logging : 1.2

Apache-2.0

commons-net : commons-net : 3.9.0

Apache-2.0

commons-validator : commons-validator : 1.7

Apache-2.0

io.helidon.grpc : io.grpc : 2.6.1

Apache-2.0

io.opentelemetry : opentelemetry-api : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-api-events : 1.27.0-alpha

Apache-2.0

io.opentelemetry : opentelemetry-context : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-logging : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-otlp : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-otlp-common : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-extension-incubator : 1.27.0-alpha

Apache-2.0

io.opentelemetry : opentelemetry-sdk : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-common : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-extension-autoconfigure-spi : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-logs : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-metrics : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-testing : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-trace : 1.27.0

Apache-2.0

io.opentelemetry : opentelemetry-semconv : 1.27.0-alpha

Apache-2.0

io.perfmark : perfmark-api : 0.25.0

Apache-2.0

io.projectreactor : reactor-core : 3.4.22

Apache-2.0

io.projectreactor.addons : reactor-extra : 3.4.8

Apache-2.0

io.qameta.allure : allure-java-commons : 2.22.2

Apache-2.0

io.qameta.allure : allure-junit4 : 2.22.2

Apache-2.0

io.qameta.allure : allure-model : 2.22.2

Apache-2.0

it.unimi.dsi : fastutil : 8.5.11

Apache-2.0

javax.inject : javax.inject : 1

Apache-2.0

javax.validation : validation-api : 1.1.0.Final

Apache-2.0

joda-time : joda-time : 2.10.2

Apache-2.0

joda-time : joda-time : 2.9.1

Apache-2.0

net.jodah : failsafe : 2.1.1

Apache-2.0

net.lingala.zip4j : zip4j : 2.11.3

Apache-2.0

org.apache.avro : avro : 1.11.3

Apache-2.0

org.apache.commons : commons-collections4 : 4.4

Apache-2.0

org.apache.commons : commons-compress : 1.21

Apache-2.0

org.apache.commons : commons-compress : 1.22

Apache-2.0

org.apache.commons : commons-exec : 1.3

Apache-2.0

org.apache.commons : commons-lang3 : 3.12.0

Apache-2.0

org.apache.commons : commons-pool2 : 2.11.1

Apache-2.0

org.apache.commons : commons-text : 1.3

Apache-2.0

org.apache.cxf : cxf-rt-bindings-soap : 3.5.5

Apache-2.0

org.apache.cxf : cxf-rt-databinding-jaxb : 3.5.5

Apache-2.0

org.apache.cxf : cxf-rt-frontend-simple : 3.5.5

Apache-2.0

org.apache.cxf : cxf-rt-management : 3.5.5

Apache-2.0

org.apache.cxf : cxf-rt-security : 3.5.5

Apache-2.0

org.apache.cxf : cxf-rt-security-saml : 3.5.5

Apache-2.0

org.apache.cxf : cxf-rt-ws-addr : 3.5.5

Apache-2.0

org.apache.cxf : cxf-rt-ws-security : 3.5.5

Apache-2.0

org.apache.cxf : cxf-rt-wsdl : 3.5.5

Apache-2.0

org.apache.ftpserver : ftplet-api : 1.2.0

Apache-2.0

org.apache.ftpserver : ftpserver-core : 1.2.0

Apache-2.0

org.apache.httpcomponents : httpclient : 4.5.13

Apache-2.0

org.apache.httpcomponents : httpcore : 4.4.16

Apache-2.0

org.apache.httpcomponents : httpcore-nio : 4.4.4

Apache-2.0

org.apache.logging.log4j : log4j-1.2-api : 2.20.0

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.20.0

Apache-2.0

org.apache.logging.log4j : log4j-core : 2.20.0

Apache-2.0

org.apache.logging.log4j : log4j-slf4j-impl : 2.20.0

Apache-2.0

org.apache.logging.log4j : log4j-slf4j2-impl : 2.20.0

Apache-2.0

org.apache.maven : maven-builder-support : 3.9.4

Apache-2.0

org.apache.maven : maven-resolver-provider : 3.9.4

Apache-2.0

org.apache.maven : maven-settings : 3.9.4

Apache-2.0

org.apache.maven : maven-settings-builder : 3.9.4

Apache-2.0

org.apache.maven.resolver : maven-resolver-api : 1.9.15

Apache-2.0

org.apache.maven.resolver : maven-resolver-connector-basic : 1.9.15

Apache-2.0

org.apache.maven.resolver : maven-resolver-impl : 1.9.15

Apache-2.0

org.apache.maven.resolver : maven-resolver-named-locks : 1.9.15

Apache-2.0

org.apache.maven.resolver : maven-resolver-spi : 1.9.15

Apache-2.0

org.apache.maven.resolver : maven-resolver-supplier : 1.9.15

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-file : 1.9.15

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-http : 1.9.15

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-wagon : 1.9.15

Apache-2.0

org.apache.maven.resolver : maven-resolver-util : 1.9.15

Apache-2.0

org.apache.maven.shared : maven-invoker : 3.2.0

Apache-2.0

org.apache.maven.shared : maven-shared-utils : 3.3.4

Apache-2.0

org.apache.maven.wagon : wagon-http : 3.4.2

Apache-2.0

org.apache.maven.wagon : wagon-http-shared : 3.4.2

Apache-2.0

org.apache.maven.wagon : wagon-provider-api : 3.4.2

Apache-2.0

org.apache.mina : mina-core : 2.1.6

Apache-2.0

org.apache.neethi : neethi : 3.2.0

Apache-2.0

org.apache.sshd : sshd-core : 2.10.0

Apache-2.0

org.apache.sshd : sshd-sftp : 2.10.0

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.2.1

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.3.0

Apache-2.0

org.apache.wss4j : wss4j-bindings : 2.4.1

Apache-2.0

org.apache.wss4j : wss4j-policy : 2.4.1

Apache-2.0

org.apache.wss4j : wss4j-ws-security-common : 2.4.1

Apache-2.0

org.apache.wss4j : wss4j-ws-security-dom : 2.4.1

Apache-2.0

org.codehaus.plexus : plexus-cipher : 2.0

Apache-2.0

org.codehaus.plexus : plexus-component-annotations : 1.5.5

Apache-2.0

org.codehaus.plexus : plexus-sec-dispatcher : 2.0

Apache-2.0

org.ehcache : ehcache : 3.9.3

Apache-2.0

org.everit.json : org.everit.json.schema : 1.5.1

Apache-2.0

org.glassfish.grizzly : grizzly-http-client : 1.14

Apache-2.0

org.jasypt : jasypt : 1.9.3

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib : 1.6.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib : 1.7.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-common : 1.6.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-common : 1.7.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk7 : 1.6.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk8 : 1.6.20

Apache-2.0

org.jheaps : jheaps : 0.10

Apache-2.0

org.objenesis : objenesis : 2.5.1

Apache-2.0

org.objenesis : objenesis : 3.3

Apache-2.0

org.opensaml : opensaml-core : 3.4.6

Apache-2.0

org.opensaml : opensaml-profile-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-saml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-saml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-security-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-security-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-saml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-saml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-xmlsec-impl : 3.4.6

Apache-2.0

org.parboiled : parboiled_2.12 : 2.1.8

Apache-2.0

org.quartz-scheduler : quartz : 2.3.2

Apache-2.0

org.raml : raml-parser-2 : 1.0.41

Apache-2.0

org.raml : yagi : 1.0.47

Apache-2.0

org.slf4j : jcl-over-slf4j : 2.0.7

Apache-2.0

org.typelevel : macro-compat_2.12 : 1.1.1

Apache-2.0

org.vibur : vibur-object-pool : 23.0

Apache-2.0

org.yaml : snakeyaml : 2.0

Apache-2.0

org.apache.xmlbeans : xmlbeans : 3.1.0

Apache-2.0

org.codehaus.plexus : plexus-utils : 3.3.0

Apache-2.0

org.codehaus.plexus : plexus-interpolation : 1.26

Apache-2.0

net.shibboleth.utilities : java-support : 7.5.2

Apache-2.0

org.apache.cxf : cxf-rt-ws-policy : 3.5.5

Apache-2.0

commons-codec : commons-codec : 1.15

Apache-2.0

io.opentelemetry : opentelemetry-exporter-common : 1.27.0

Apache-2.0

org.apache.sshd : sshd-scp : 2.10.0

Apache-2.0

org.mule.mvel : mule-mvel2 : 2.1.9-MULE-019

Apache-2.0

org.springframework : spring-aop : 5.3.27

Apache-2.0

org.springframework : spring-beans : 5.3.27

Apache-2.0

org.springframework : spring-context : 5.3.27

Apache-2.0

org.springframework : spring-core : 5.3.27

Apache-2.0

org.springframework : spring-expression : 5.3.27

Apache-2.0

org.apache.httpcomponents : httpcore : 4.4.4

Apache-2.0

com.github.ben-manes.caffeine : caffeine : 2.8.0

Apache-2.0

com.github.ben-manes.caffeine : caffeine : 2.9.0

Apache-2.0

com.google.guava : guava : 32.1.1-jre

Apache-2.0

io.dropwizard.metrics : metrics-core : 3.1.5

Apache-2.0

org.scala-lang : scala-library : 2.12.15

Apache-2.0

net.bytebuddy : byte-buddy-agent : 1.14.0

Apache-2.0

org.apache.derby : derby : 10.14.2.0

Apache-2.0

org.jetbrains : annotations : 13.0

Apache-2.0

net.bytebuddy : byte-buddy : 1.14.0

Apache-2.0

org.apache.sshd : sshd-common : 2.10.0

Apache-2.0

com.github.erosb : everit-json-schema : 1.14.2

Apache-2.0

com.github.fge : btf : 1.2

Apache-2.0

com.github.fge : msg-simple : 1.1

Apache-2.0

com.github.fge : uri-template : 0.9

Apache-2.0

com.github.java-json-tools : jackson-coreutils : 1.9

Apache-2.0

com.github.java-json-tools : json-schema-core : 1.2.10

Apache-2.0

com.github.java-json-tools : json-schema-validator : 2.2.10

Apache-2.0

org.cryptacular : cryptacular : 1.2.4

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.15.0

Apache-2.0

com.google.guava : listenablefuture : 9999.0-empty-to-avoid-conflict-with-guava

Apache-2.0

com.typesafe : config : 1.3.1

Apache-2.0

org.apache.wss4j : wss4j-ws-security-stax : 2.4.1

Apache-2.0

org.opensaml : opensaml-soap-api : 3.4.6

Apache-2.0

org.apache.wss4j : wss4j-ws-security-policy-stax : 2.4.1

Apache-2.0

org.apache.groovy : groovy : 4.0.11

Apache-2.0

org.togglz : togglz-core : 3.0.0

Apache-2.0

xml-apis : xml-apis : 1.4.01

Apache-2.0

com.fasterxml : aalto-xml : 1.3.2

Apache-2.0

com.fasterxml.woodstox : woodstox-core : 6.4.0

Apache-2.0

org.apache.httpcomponents : httpasyncclient : 4.1.1

Apache-2.0

org.awaitility : awaitility : 3.0.0

Apache-2.0

org.apache.santuario : xmlsec : 2.3.0

Apache-2.0

org.opensaml : opensaml-xmlsec-api : 3.4.6

Apache-2.0

org.apache.cxf : cxf-core : 3.5.5

Apache-2.0

org.apache.cxf : cxf-rt-ws-rm : 3.5.5

BSD

org.codehaus.woodstox : stax2-api : 4.2.1

BSD

net.java.dev.stax-utils : stax-utils : 20070216

BSD

org.antlr : antlr-runtime : 3.5.2

BSD-2-Clause

org.reflections : reflections : 0.9.10

BSD-3-Clause

org.ow2.asm : asm : 9.4

BSD-3-Clause

org.dom4j : dom4j : 2.1.3

BSD-3-Clause

org.hamcrest : hamcrest : 2.2

BSD-3-Clause

com.google.re2j : re2j : 1.6

Bouncycastle-license

org.bouncycastle : bcprov-jdk15on : 1.70

CDDL-1.1

org.glassfish.grizzly : grizzly-http : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-framework : 2.4.0-beta2

CDDL-1.1

org.glassfish.grizzly : grizzly-http-servlet : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-http-server : 2.3.34

CDDL-1.1

org.glassfish.grizzly : connection-pool : 2.4.0-beta3

CDDL-1.1

org.glassfish.grizzly : grizzly-websockets : 2.4.0-beta4

CPAL-1.0

org.mule.runtime : mule-extensions-api-dsql : 1.0.0-rc

CPAL-1.0

org.mule.runtime : mule-extensions-soap-api : 1.1.1

CPAL-1.0

org.mule.runtime : mule-metadata-model-api : 1.1.1

CPAL-1.0

org.mule.runtime : mule-metadata-model-raml : 1.1.1

CPAL-1.0

org.mule.runtime : mule-module-license-api : 4.1.1

CPAL-1.0

org.mule.runtime : mule-service-soap-api : 4.1.1

CPAL-1.0

org.mule.tests : mule-tests-model : 4.1.1

CPL-1.0

wsdl4j : wsdl4j : 1.6.3

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.1

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.2

EDL-1.0

com.sun.istack : istack-commons-runtime : 3.0.12

EDL-1.0

com.sun.xml.messaging.saaj : saaj-impl : 1.5.3

EDL-1.0

jakarta.xml.bind : jakarta.xml.bind-api : 2.3.3

EDL-1.0

jakarta.xml.soap : jakarta.xml.soap-api : 1.4.2

EDL-1.0

jakarta.xml.ws : jakarta.xml.ws-api : 2.3.3

EDL-1.0

org.jvnet.staxex : stax-ex : 1.8.3

EDL-1.0

jakarta.jws : jakarta.jws-api : 1.1.1

EDL-1.0

com.sun.xml.bind : jaxb-impl : 2.3.8

EDL-1.0

org.glassfish.jaxb : jaxb-runtime : 2.3.5

EDL-1.0

org.glassfish.jaxb : txw2 : 2.3.5

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.7

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.3

EDL-1.0

com.sun.mail : mailapi : 1.6.5

EPL-1.0

org.eclipse.sisu : org.eclipse.sisu.plexus : 0.3.5

EPL-1.0

org.aspectj : aspectjweaver : 1.9.2

EPL-1.0

org.eclipse.sisu : org.eclipse.sisu.inject : 0.3.5

EPL-1.0

com.mchange : c3p0 : 0.9.5.5

EPL-1.0

com.mchange : mchange-commons-java : 0.2.15

EPL-1.0

junit : junit : 4.12

EPL-2.0

jakarta.annotation : jakarta.annotation-api : 1.3.5

EPL-2.0

jakarta.jms : jakarta.jms-api : 2.0.3

EPL-2.0

jakarta.resource : jakarta.resource-api : 1.7.4

EPL-2.0

jakarta.transaction : jakarta.transaction-api : 1.3.3

EPL-2.0

org.glassfish : jakarta.json : 1.1.6

EPL-2.0

org.jgrapht : jgrapht-core : 1.3.1

ICU または Unicode

com.ibm.icu : icu4j : 67.1

LGPL-2.1

com.github.spotbugs : spotbugs-annotations : 4.7.3

MIT

net.sf.jopt-simple : jopt-simple : 5.0.3

MIT

org.checkerframework : checker-qual : 3.10.0

MIT

org.checkerframework : checker-qual : 3.33.0

MIT

org.jsoup : jsoup : 1.15.3

MIT

org.slf4j : jul-to-slf4j : 2.0.7

MIT

org.slf4j : slf4j-api : 1.7.36

MIT

org.slf4j : slf4j-api : 2.0.7

MIT

org.mockito : mockito-core : 4.11.0

MIT

com.mashape.unirest : unirest-java : 1.4.9

MIT

ch.randelshofer : fastdoubleparser : 0.8.0

MIT

com.vdurmont : semver4j : 3.1.0

MIT

org.checkerframework : checker-qual : 2.10.0

MIT

tanukisoft : wrapper : 3.2.3

MIT

org.graalvm.js : js : 21.0.0.2

MIT

org.graalvm.js js 1.0.0-rc15

MIT-0

org.reactivestreams : reactive-streams : 1.0.4

MPL-1.1

com.googlecode.juniversalchardet : juniversalchardet : 1.0.3

MPL-2.0

net.sf.saxon : Saxon-HE : 9.9.1-8

MPL-2.0

org.mozilla : rhino : 1.7.12

Public Domain

org.json : json : 20230227

UPL-1.0

org.graalvm.js : js-scriptengine : 21.0.0.2

UPL-1.0

org.graalvm.regex : regex : 21.0.0.2

UPL-1.0

org.graalvm.sdk : graal-sdk : 21.0.0.2

UPL-1.0

org.graalvm.truffle : truffle-api : 21.0.0.2
## [](#ライセンス情報)ライセンス情報 各ライセンス種別に関する情報は次の場所にあります。 - `http://aopalliance.sourceforge.net/`​ (AOP) - `https://opensource.org/licenses/APACHE-2.0`​ (Apache-2.0) - `https://en.wikipedia.org/wiki/BSD_licenses`​ (BSD) - `https://opensource.org/licenses/BSD-2-Clause`​ (BSD-2-Clause) - `https://opensource.org/licenses/BSD-3-Clause`​ (BSD-3-Clause) - `https://spdx.org/licenses/CDDL-1.1.html`​ (CDDL-1.1) - `https://opensource.org/licenses/CPAL-1.0`​ (CPAL-1.0) - `https://opensource.org/licenses/CPL-1.0`​ (CPL-1.0) - `https://opensource.org/licenses/EPL-2.0`​ (EPL-2.0) - `http://source.icu-project.org/repos/icu/icu/trunk/LICENSE`​ (ICU) - `https://github.com/stleary/JSON-java/blob/master/LICENSE`​ (JSON) - `https://opensource.org/licenses/LGPL-2.1`​ (LGPL-2.1) - `https://opensource.org/licenses/MIT`​ (MIT) - `https://opensource.org/licenses/MPL-1.1`​ (MPL-1.1) - `https://opensource.org/licenses/MPL-2.0`​ (MPL-2.0) # Mule のサードパーティソフトウェア Mule Runtime Engine は、含まれるサードパーティソフトウェアのライブラリのサブセットに内部で連動しています。Mule アプリケーションには、サードパーティソフトウェアリストに含まれていない追加のサードパーティ連動関係 (Apache Maven から管理) が含まれている可能性もあります。 ## [](#サードパーティソフトウェアリスト)サードパーティソフトウェアリスト 次の表では、Mule のサードパーティソフトウェアをソフトウェアコンポーネント別に示しています。
ライセンス コンポーネント

Apache-2.0

com.beust : jcommander : 1.78

Apache-2.0

com.conversantmedia : disruptor : 1.2.10

Apache-2.0

com.damnhandy : handy-uri-templates : 2.1.8

Apache-2.0

com.fasterxml : aalto-xml : 1.3.2

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.12.4

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.15.4

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.16.1

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.15.4

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.16.1

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.15.4

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.16.1

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-yaml : 2.12.4

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-yaml : 2.15.4

Apache-2.0

com.fasterxml.jackson.datatype : jackson-datatype-jsr310 : 2.12.4

Apache-2.0

com.fasterxml.jackson.module : jackson-module-jsonschema : 2.15.4

Apache-2.0

com.fasterxml.woodstox : woodstox-core : 6.4.0

Apache-2.0

com.github.ben-manes.caffeine : caffeine : 2.8.0

Apache-2.0

com.github.ben-manes.caffeine : caffeine : 2.9.0

Apache-2.0

com.github.erosb : everit-json-schema : 1.14.3

Apache-2.0

com.github.fge : btf : 1.2

Apache-2.0

com.github.fge : msg-simple : 1.1

Apache-2.0

com.github.fge : uri-template : 0.9

Apache-2.0

com.github.java-json-tools : jackson-coreutils : 1.9

Apache-2.0

com.github.java-json-tools : json-schema-core : 1.2.10

Apache-2.0

com.github.java-json-tools : json-schema-validator : 2.2.10

Apache-2.0

com.github.jknack : handlebars : 4.3.1

Apache-2.0

com.github.jknack handlebars-proto 4.1.0

Apache-2.0

com.github.pjfanning : excel-streaming-reader : 4.1.2

Apache-2.0

com.github.pjfanning : poi-shared-strings : 2.6.1

Apache-2.0

com.google.code.gson : gson : 2.8.9

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.3.3

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.5.1

Apache-2.0

com.google.guava : failureaccess : 1.0.1

Apache-2.0

com.google.guava : guava : 32.1.3-jre

Apache-2.0

com.google.guava : listenablefuture : 9999.0-empty-to-avoid-conflict-with-guava

Apache-2.0

com.google.j2objc : j2objc-annotations : 2.8

Apache-2.0

com.googlecode.libphonenumber : libphonenumber : 8.0.0

Apache-2.0

com.hazelcast : hazelcast : 5.2.5

Apache-2.0

com.lmax : disruptor : 3.4.3

Apache-2.0

com.squareup.okhttp3 : okhttp : 4.11.0

Apache-2.0

com.squareup.okio : okio-jvm : 3.6.0

Apache-2.0

com.typesafe : config : 1.3.1

Apache-2.0

com.zaxxer : hikaricp-java7 : 2.4.13

Apache-2.0

com.zaxxer : sparsebitset : 1.3

Apache-2.0

commons-beanutils : commons-beanutils : 1.9.4

Apache-2.0

commons-cli : commons-cli : 1.2

Apache-2.0

commons-cli : commons-cli : 1.4

Apache-2.0

commons-codec : commons-codec : 1.15

Apache-2.0

commons-codec : commons-codec : 1.16.0

Apache-2.0

commons-collections : commons-collections : 3.2.2

Apache-2.0

commons-dbutils : commons-dbutils : 1.7

Apache-2.0

commons-digester : commons-digester : 2.1

Apache-2.0

commons-io : commons-io : 2.13.0

Apache-2.0

commons-io : commons-io : 2.15.1

Apache-2.0

commons-lang : commons-lang : 2.6

Apache-2.0

commons-validator : commons-validator : 1.7

Apache-2.0

de.javakaffee : kryo-serializers : 0.45

Apache-2.0

io.dropwizard.metrics : metrics-core : 3.1.5

Apache-2.0

io.helidon.grpc : io.grpc : 2.6.1

Apache-2.0

io.opentelemetry : opentelemetry-api : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-api-events : 1.31.0-alpha

Apache-2.0

io.opentelemetry : opentelemetry-context : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-common : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-logging : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-otlp : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-otlp-common : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-sender-okhttp : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-extension-incubator : 1.31.0-alpha

Apache-2.0

io.opentelemetry : opentelemetry-sdk : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-common : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-extension-autoconfigure-spi : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-logs : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-metrics : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-testing : 1.31.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-trace : 1.31.0

Apache-2.0

io.perfmark : perfmark-api : 0.25.0

Apache-2.0

io.projectreactor : reactor-core : 3.4.22

Apache-2.0

io.projectreactor.addons : reactor-extra : 3.4.8

Apache-2.0

it.unimi.dsi : fastutil : 8.5.11

Apache-2.0

jakarta.inject : jakarta.inject-api : 1.0.5

Apache-2.0

javax.validation : validation-api : 1.1.0.final

Apache-2.0

joda-time : joda-time : 2.10.2

Apache-2.0

joda-time : joda-time : 2.12.7

Apache-2.0

net.bytebuddy : byte-buddy : 1.14.0

Apache-2.0

net.jodah : failsafe : 2.1.1

Apache-2.0

net.lingala.zip4j : zip4j : 2.11.3

Apache-2.0

net.shibboleth.utilities : java-support : 7.5.2

Apache-2.0

org.apache.avro : avro : 1.11.3

Apache-2.0

org.apache.commons : commons-collections4 : 4.4

Apache-2.0

org.apache.commons : commons-compress : 1.21

Apache-2.0

org.apache.commons : commons-compress : 1.21

Apache-2.0

org.apache.commons : commons-compress : 1.26.0

Apache-2.0

org.apache.commons : commons-lang3 : 3.12.0

Apache-2.0

org.apache.commons : commons-lang3 : 3.14.0

Apache-2.0

org.apache.commons : commons-math3 : 3.6.1

Apache-2.0

org.apache.commons : commons-pool2 : 2.11.1

Apache-2.0

org.apache.commons : commons-text : 1.10.0

Apache-2.0

org.apache.commons : commons-text : 1.3

Apache-2.0

org.apache.cxf : cxf-core : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-bindings-soap : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-databinding-jaxb : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-frontend-simple : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-management : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-security : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-security-saml : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-ws-addr : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-ws-policy : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-ws-rm : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-ws-security : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-wsdl : 3.5.8

Apache-2.0

org.apache.httpcomponents : fluent-hc : 4.5.13

Apache-2.0

org.apache.httpcomponents : httpclient : 4.5.13

Apache-2.0

org.apache.httpcomponents : httpcore : 4.4.13

Apache-2.0

org.apache.httpcomponents : httpcore : 4.4.16

Apache-2.0

org.apache.logging.log4j : log4j-1.2-api : 2.20.0

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.20.0

Apache-2.0

org.apache.logging.log4j : log4j-core : 2.20.0

Apache-2.0

org.apache.logging.log4j : log4j-slf4j2-impl : 2.20.0

Apache-2.0

org.apache.maven : maven-builder-support : 3.9.6

Apache-2.0

org.apache.maven : maven-resolver-provider : 3.9.4

Apache-2.0

org.apache.maven : maven-settings : 3.9.6

Apache-2.0

org.apache.maven : maven-settings-builder : 3.9.6

Apache-2.0

org.apache.maven.resolver : maven-resolver-api : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-connector-basic : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-impl : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-named-locks : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-spi : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-supplier : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-file : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-http : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-wagon : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-util : 1.9.18

Apache-2.0

org.apache.maven.wagon : wagon-http : 3.4.2

Apache-2.0

org.apache.maven.wagon : wagon-http-shared : 3.4.2

Apache-2.0

org.apache.maven.wagon : wagon-provider-api : 3.4.2

Apache-2.0

org.apache.neethi : neethi : 3.2.0

Apache-2.0

org.apache.poi : poi : 5.2.4

Apache-2.0

org.apache.poi : poi-ooxml : 5.2.4

Apache-2.0

org.apache.poi : poi-ooxml-lite : 5.2.4

Apache-2.0

org.apache.santuario : xmlsec : 2.3.4

Apache-2.0

org.apache.velocity : velocity-engine-core : 2.3

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.1.0

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.2.1

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.3.1

Apache-2.0

org.apache.wss4j : wss4j-bindings : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-policy : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-common : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-dom : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-policy-stax : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-stax : 2.4.3

Apache-2.0

org.apache.xmlbeans : xmlbeans : 3.1.0

Apache-2.0

org.apache.xmlbeans : xmlbeans : 5.1.1

Apache-2.0

org.codehaus.plexus : plexus-cipher : 2.0

Apache-2.0

org.codehaus.plexus : plexus-component-annotations : 1.5.5

Apache-2.0

org.codehaus.plexus : plexus-interpolation : 1.26

Apache-2.0

org.codehaus.plexus : plexus-sec-dispatcher : 2.0

Apache-2.0

org.codehaus.plexus : plexus-utils : 4.0.0

Apache-2.0

org.codehaus.plexus : plexus-xml : 3.0.0

Apache-2.0

org.cryptacular : cryptacular : 1.2.4

Apache-2.0

org.ehcache : ehcache : 3.9.3

Apache-2.0

org.everit.json : org.everit.json.schema : 1.5.1

Apache-2.0

org.fusesource.jansi : jansi : 1.18

Apache-2.0

org.jasypt : jasypt : 1.9.3

Apache-2.0

org.jetbrains : annotations : 13.0

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib : 1.7.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib : 1.9.10

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-common : 1.7.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-common : 1.9.10

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk7 : 1.9.10

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk8 : 1.9.10

Apache-2.0

org.jheaps : jheaps : 0.10

Apache-2.0

org.mapdb : mapdb : 1.0.6

Apache-2.0

org.objenesis : objenesis : 2.5.1

Apache-2.0

org.opensaml : opensaml-core : 3.4.6

Apache-2.0

org.opensaml : opensaml-profile-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-saml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-saml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-security-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-security-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-soap-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-saml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-saml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-xmlsec-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xmlsec-impl : 3.4.6

Apache-2.0

org.parboiled : parboiled_2.12 : 2.5.1

Apache-2.0

org.quartz-scheduler : quartz : 2.3.2

Apache-2.0

org.raml : raml-parser-2 : 1.0.44-12

Apache-2.0

org.raml : yagi : 1.0.44-12

Apache-2.0

org.scala-lang : scala-library : 2.12.15

Apache-2.0

org.scala-lang.modules : scala-parser-combinators_2.12 : 2.1.1

Apache-2.0

org.slf4j : jcl-over-slf4j : 2.0.7

Apache-2.0

org.springframework : spring-aop : 5.3.33

Apache-2.0

org.springframework : spring-beans : 5.3.27

Apache-2.0

org.springframework : spring-beans : 5.3.33

Apache-2.0

org.springframework : spring-context : 5.3.27

Apache-2.0

org.springframework : spring-context : 5.3.33

Apache-2.0

org.springframework : spring-context-support : 5.3.32

Apache-2.0

org.springframework : spring-core : 5.3.33

Apache-2.0

org.springframework : spring-expression : 5.3.27

Apache-2.0

org.springframework : spring-expression : 5.3.33

Apache-2.0

org.togglz : togglz-core : 3.0.0

Apache-2.0

org.vibur : vibur-object-pool : 23.0

Apache-2.0

org.yaml : snakeyaml : 2.0

Apache-2.0

xml-apis : xml-apis : 1.4.01

BSD

com.github.virtuald : curvesapi : 1.08

BSD

net.java.dev.stax-utils : stax-utils : 20080702

BSD

org.antlr : antlr-runtime : 3.5.2

BSD

org.codehaus.woodstox : stax2-api : 4.2.1

BSD

org.jline : jline : 3.19.0

BSD-2-Clause

com.esotericsoftware : minlog : 1.3.0

BSD-2-Clause

org.reflections : reflections : 0.9.10

BSD-3-Clause

com.esotericsoftware : kryo-shaded : 4.0.3

BSD-3-Clause

com.esotericsoftware : kryo-shaded : 4.0.3

BSD-3-Clause

com.google.protobuf : protobuf-java : 3.21.9

BSD-3-Clause

com.google.re2j : re2j : 1.6

BSD-3-Clause

com.ibm.icu : icu4j : 71.1

BSD-3-Clause

org.dom4j : dom4j : 2.1.3

BSD-3-Clause

org.ow2.asm : asm : 9.6

CDDL-1.1

javax.ws.rs : javax.ws.rs-api : 2.0

CDDL-1.1

org.glassfish.grizzly : connection-pool : 2.4.0-beta3

CDDL-1.1

org.glassfish.grizzly : grizzly-framework : 2.4.0-beta2

CDDL-1.1

org.glassfish.grizzly : grizzly-http : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-http-server : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-http-servlet : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-websockets : 2.4.0-beta4

CPL-1.0

wsdl4j : wsdl4j : 1.6.3

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.1

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.2

EDL-1.0

com.sun.istack : istack-commons-runtime : 3.0.12

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.3

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.7

EDL-1.0

com.sun.mail : mailapi : 1.6.5

EDL-1.0

com.sun.xml.bind : jaxb-impl : 2.3.8

EDL-1.0

com.sun.xml.messaging.saaj : saaj-impl : 1.5.3

EDL-1.0

jakarta.jws : jakarta.jws-api : 1.1.1

EDL-1.0

jakarta.xml.bind : jakarta.xml.bind-api : 2.3.3

EDL-1.0

jakarta.xml.soap : jakarta.xml.soap-api : 1.4.2

EDL-1.0

jakarta.xml.ws : jakarta.xml.ws-api : 2.3.3

EDL-1.0

org.glassfish.jaxb : jaxb-runtime : 2.3.5

EDL-1.0

org.glassfish.jaxb : txw2 : 2.3.5

EDL-1.0

org.jvnet.staxex : stax-ex : 1.8.3

EPL-1.0

com.mchange : c3p0 : 0.9.5.4

EPL-1.0

com.mchange : c3p0 : 0.9.5.5

EPL-1.0

com.mchange : mchange-commons-java : 0.2.15

EPL-1.0

org.eclipse.sisu : org.eclipse.sisu.inject : 0.3.5

EPL-1.0

org.eclipse.sisu : org.eclipse.sisu.plexus : 0.3.5

EPL-2.0

jakarta.annotation : jakarta.annotation-api : 1.3.5

EPL-2.0

jakarta.jms : jakarta.jms-api : 2.0.3

EPL-2.0

jakarta.resource : jakarta.resource-api : 1.7.4

EPL-2.0

jakarta.servlet : jakarta.servlet-api : 4.0.4

EPL-2.0

jakarta.transaction : jakarta.transaction-api : 1.3.3

EPL-2.0

org.glassfish : jakarta.json : 1.1.6

EPL-2.0

org.jgrapht : jgrapht-core : 1.3.1

LGPL-2.1

com.github.spotbugs : spotbugs-annotations : 4.7.3

MIT

com.vdurmont : semver4j : 3.1.0

MIT

handlebars 4.7.7

MIT

me.tongfei : progressbar : 0.9.1

MIT

net.sf.jopt-simple : jopt-simple : 5.0.3

MIT

org.checkerframework : checker-qual : 2.10.0

MIT

org.checkerframework : checker-qual : 3.33.0

MIT

org.graalvm.js : js : 22.3.5

MIT

org.graalvm.js js 1.0.0-rc15

MIT

org.jsoup : jsoup : 1.15.3

MIT

org.slf4j : jul-to-slf4j : 2.0.7

MIT

org.slf4j : slf4j-api : 2.0.7

MIT-0

org.reactivestreams : reactive-streams : 1.0.4

MPL-1.1

com.googlecode.juniversalchardet : juniversalchardet : 1.0.3

MPL-2.0

net.sf.saxon : saxon-he : 9.9.1-8

MPL-2.0

org.mozilla : rhino : 1.7.12

Public Domain

org.json : json : 20231013

UPL-1.0

org.graalvm.js : js-scriptengine : 22.3.5

UPL-1.0

org.graalvm.regex : regex : 22.3.5

UPL-1.0

org.graalvm.sdk : graal-sdk : 22.3.5

UPL-1.0

org.graalvm.truffle : truffle-api : 22.3.5
## [](#ライセンス情報)ライセンス情報 各ライセンス種別に関する情報は次の場所にあります。 - `http://aopalliance.sourceforge.net/`​ (AOP) - `https://opensource.org/licenses/APACHE-2.0`​ (Apache-2.0) - `https://en.wikipedia.org/wiki/BSD_licenses`​ (BSD) - `https://opensource.org/licenses/BSD-2-Clause`​ (BSD-2-Clause) - `https://opensource.org/licenses/BSD-3-Clause`​ (BSD-3-Clause) - `https://spdx.org/licenses/CDDL-1.1.html`​ (CDDL-1.1) - `https://opensource.org/licenses/CPAL-1.0`​ (CPAL-1.0) - `https://opensource.org/licenses/CPL-1.0`​ (CPL-1.0) - `https://opensource.org/licenses/EPL-2.0`​ (EPL-2.0) - `http://source.icu-project.org/repos/icu/icu/trunk/LICENSE`​ (ICU) - `https://github.com/stleary/JSON-java/blob/master/LICENSE`​ (JSON) - `https://opensource.org/licenses/LGPL-2.1`​ (LGPL-2.1) - `https://opensource.org/licenses/MIT`​ (MIT) - `https://opensource.org/licenses/MPL-1.1`​ (MPL-1.1) - `https://opensource.org/licenses/MPL-2.0`​ (MPL-2.0) # Mule のサードパーティソフトウェア Mule Runtime Engine は、含まれるサードパーティソフトウェアのライブラリのサブセットに内部で連動しています。Mule アプリケーションには、サードパーティソフトウェアリストに含まれていない追加のサードパーティ連動関係 (Apache Maven から管理) が含まれている可能性もあります。 ## [](#サードパーティソフトウェアリスト)サードパーティソフトウェアリスト 次の表では、Mule のサードパーティソフトウェアをソフトウェアコンポーネント別に示しています。
ライセンス コンポーネント

Apache-1.0

org.javassist : javassist : 3.28.0-ga

Apache-2.0

com.beust : jcommander : 1.78

Apache-2.0

com.conversantmedia : disruptor : 1.2.10

Apache-2.0

com.damnhandy : handy-uri-templates : 2.1.8

Apache-2.0

com.fasterxml : aalto-xml : 1.3.2

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.15.2

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.16.1

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.17.0

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.15.2

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.16.1

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.17.0

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.15.2

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.16.1

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.17.0

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-cbor : 2.12.6

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-yaml : 2.17.0

Apache-2.0

com.fasterxml.jackson.datatype : jackson-datatype-jsr310 : 2.17.0

Apache-2.0

com.fasterxml.jackson.module : jackson-module-jaxb-annotations : 2.14.1

Apache-2.0

com.fasterxml.jackson.module : jackson-module-jsonschema : 2.17.0

Apache-2.0

com.fasterxml.uuid : java-uuid-generator : 3.1.3

Apache-2.0

com.fasterxml.woodstox : woodstox-core : 6.6.1

Apache-2.0

com.fasterxml.woodstox : woodstox-core : 6.6.2

Apache-2.0

com.github.ben-manes.caffeine : caffeine : 2.9.3

Apache-2.0

com.github.erosb : everit-json-schema : 1.14.3

Apache-2.0

com.github.fge : btf : 1.2

Apache-2.0

com.github.fge : msg-simple : 1.1

Apache-2.0

com.github.fge : uri-template : 0.9

Apache-2.0

com.github.java-json-tools : jackson-coreutils : 1.9

Apache-2.0

com.github.java-json-tools : json-schema-core : 1.2.10

Apache-2.0

com.github.java-json-tools : json-schema-validator : 2.2.10

Apache-2.0

com.github.jknack : handlebars : 4.3.1

Apache-2.0

com.github.jknack handlebars-proto 4.1.0

Apache-2.0

com.github.jsendnsca : jsendnsca : 2.1.1

Apache-2.0

com.github.pjfanning : excel-streaming-reader : 4.1.2

Apache-2.0

com.github.pjfanning : poi-shared-strings : 2.6.1

Apache-2.0

com.google.code.findbugs : jsr305 : 3.0.2

Apache-2.0

com.google.code.gson : gson : 2.10.1

Apache-2.0

com.google.code.gson : gson : 2.8.9

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.10.0

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.18.0

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.26.1

Apache-2.0

com.google.guava : failureaccess : 1.0.1

Apache-2.0

com.google.guava : failureaccess : 1.0.2

Apache-2.0

com.google.guava : guava : 32.0.1-jre

Apache-2.0

com.google.guava : guava : 33.1.0-jre

Apache-2.0

com.google.guava : listenablefuture : 9999.0-empty-to-avoid-conflict-with-guava

Apache-2.0

com.google.inject : guice : 5.0.1

Apache-2.0

com.google.j2objc : j2objc-annotations : 2.8

Apache-2.0

com.google.j2objc : j2objc-annotations : 3.0.0

Apache-2.0

com.googlecode.libphonenumber : libphonenumber : 8.0.0

Apache-2.0

com.hazelcast : hazelcast : 5.2.5

Apache-2.0

com.lmax : disruptor : 3.4.4

Apache-2.0

com.netflix.servo : servo-core : 0.12.22

Apache-2.0

com.netflix.spectator : spectator-api : 0.67.0

Apache-2.0

com.splunk : splunk : 1.6.4.0

Apache-2.0

com.squareup : tape : 1.2.2

Apache-2.0

com.squareup.okhttp3 : logging-interceptor : 4.11.0

Apache-2.0

com.squareup.okhttp3 : okhttp : 4.11.0

Apache-2.0

com.squareup.okhttp3 : okhttp : 4.12.0

Apache-2.0

com.squareup.okio : okio : 3.4.0

Apache-2.0

com.squareup.okio : okio-jvm : 3.4.0

Apache-2.0

com.squareup.okio : okio-jvm : 3.9.0

Apache-2.0

com.typesafe : config : 1.4.3

Apache-2.0

com.typesafe.netty : netty-reactive-streams : 2.0.4

Apache-2.0

com.zaxxer : hikaricp-java7 : 2.4.13

Apache-2.0

com.zaxxer : sparsebitset : 1.3

Apache-2.0

commons-beanutils : commons-beanutils : 1.9.4

Apache-2.0

commons-cli : commons-cli : 1.4

Apache-2.0

commons-cli : commons-cli : 1.6.0

Apache-2.0

commons-codec : commons-codec : 1.14

Apache-2.0

commons-codec : commons-codec : 1.16.0

Apache-2.0

commons-codec : commons-codec : 1.16.1

Apache-2.0

commons-collections : commons-collections : 3.2.2

Apache-2.0

commons-dbutils : commons-dbutils : 1.8.0

Apache-2.0

commons-digester : commons-digester : 2.1

Apache-2.0

commons-io : commons-io : 2.15.1

Apache-2.0

commons-io : commons-io : 2.16.0

Apache-2.0

commons-io : commons-io : 2.8.0

Apache-2.0

commons-lang : commons-lang : 2.4

Apache-2.0

commons-lang : commons-lang : 2.6

Apache-2.0

commons-logging : commons-logging : 1.2

Apache-2.0

commons-validator : commons-validator : 1.7

Apache-2.0

de.javakaffee : kryo-serializers : 0.45

Apache-2.0

io.dropwizard.metrics : metrics-core : 3.1.5

Apache-2.0

io.grpc : grpc-api : 1.63.0

Apache-2.0

io.grpc : grpc-context : 1.63.0

Apache-2.0

io.grpc : grpc-core : 1.63.0

Apache-2.0

io.jsonwebtoken : jjwt-api : 0.11.5

Apache-2.0

io.jsonwebtoken : jjwt-gson : 0.11.5

Apache-2.0

io.jsonwebtoken : jjwt-impl : 0.11.5

Apache-2.0

io.netty : netty-buffer : 4.1.104.final

Apache-2.0

io.netty : netty-codec : 4.1.104.final

Apache-2.0

io.netty : netty-codec-http : 4.1.104.final

Apache-2.0

io.netty : netty-codec-socks : 4.1.104.final

Apache-2.0

io.netty : netty-common : 4.1.104.final

Apache-2.0

io.netty : netty-handler : 4.1.104.final

Apache-2.0

io.netty : netty-handler-proxy : 4.1.104.final

Apache-2.0

io.netty : netty-resolver : 4.1.104.final

Apache-2.0

io.netty : netty-transport : 4.1.104.final

Apache-2.0

io.netty : netty-transport-classes-epoll : 4.1.104.final

Apache-2.0

io.netty : netty-transport-native-epoll : jar : linux-x​86_64​ : 4.1.104.final

Apache-2.0

io.netty : netty-transport-native-unix-common : 4.1.104.final

Apache-2.0

io.opentelemetry : opentelemetry-api : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-api-events : 1.36.0-alpha

Apache-2.0

io.opentelemetry : opentelemetry-context : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-common : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-logging : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-otlp : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-otlp-common : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-sender-okhttp : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-extension-incubator : 1.36.0-alpha

Apache-2.0

io.opentelemetry : opentelemetry-sdk : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-common : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-extension-autoconfigure-spi : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-logs : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-metrics : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-testing : 1.36.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-trace : 1.36.0

Apache-2.0

io.perfmark : perfmark-api : 0.27.0

Apache-2.0

io.projectreactor : reactor-core : 3.6.4

Apache-2.0

io.projectreactor.addons : reactor-extra : 3.5.1

Apache-2.0

it.unimi.dsi : fastutil : 8.5.13

Apache-2.0

jakarta.inject : jakarta.inject-api : 1.0.5

Apache-2.0

jakarta.validation : jakarta.validation-api : 2.0.2

Apache-2.0

javax.inject : javax.inject : 1

Apache-2.0

javax.validation : validation-api : 1.0.0.ga

Apache-2.0

javax.validation : validation-api : 1.1.0.final

Apache-2.0

joda-time : joda-time : 2.10.2

Apache-2.0

joda-time : joda-time : 2.12.7

Apache-2.0

joda-time : joda-time : 2.9.1

Apache-2.0

net.bytebuddy : byte-buddy : 1.14.13

Apache-2.0

net.jodah : failsafe : 2.4.4

Apache-2.0

net.lingala.zip4j : zip4j : 2.11.3

Apache-2.0

net.shibboleth.utilities : java-support : 7.5.2

Apache-2.0

org.apache.avro : avro : 1.11.3

Apache-2.0

org.apache.commons : commons-collections4 : 4.4

Apache-2.0

org.apache.commons : commons-compress : 1.26.0

Apache-2.0

org.apache.commons : commons-compress : 1.26.1

Apache-2.0

org.apache.commons : commons-lang3 : 3.14.0

Apache-2.0

org.apache.commons : commons-lang3 : 3.4

Apache-2.0

org.apache.commons : commons-math3 : 3.6.1

Apache-2.0

org.apache.commons : commons-pool2 : 2.12.0

Apache-2.0

org.apache.commons : commons-text : 1.10.0

Apache-2.0

org.apache.commons : commons-text : 1.11.0

Apache-2.0

org.apache.cxf : cxf-core : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-bindings-soap : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-databinding-jaxb : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-frontend-simple : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-management : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-security : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-security-saml : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-ws-addr : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-ws-policy : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-ws-rm : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-ws-security : 3.5.8

Apache-2.0

org.apache.cxf : cxf-rt-wsdl : 3.5.8

Apache-2.0

org.apache.httpcomponents : fluent-hc : 4.5.14

Apache-2.0

org.apache.httpcomponents : httpclient : 4.5.13

Apache-2.0

org.apache.httpcomponents : httpclient : 4.5.14

Apache-2.0

org.apache.httpcomponents : httpcore : 4.4.16

Apache-2.0

org.apache.httpcomponents : httpcore : 4.4.5

Apache-2.0

org.apache.httpcomponents.client5 : httpclient5 : 5.1.3

Apache-2.0

org.apache.httpcomponents.core5 : httpcore5 : 5.1.3

Apache-2.0

org.apache.httpcomponents.core5 : httpcore5-h2 : 5.1.3

Apache-2.0

org.apache.logging.log4j : log4j-1.2-api : 2.22.1

Apache-2.0

org.apache.logging.log4j : log4j-1.2-api : 2.23.1

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.20.0

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.22.1

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.23.1

Apache-2.0

org.apache.logging.log4j : log4j-core : 2.22.1

Apache-2.0

org.apache.logging.log4j : log4j-core : 2.23.1

Apache-2.0

org.apache.logging.log4j : log4j-slf4j-impl : 2.22.1

Apache-2.0

org.apache.logging.log4j : log4j-slf4j2-impl : 2.23.1

Apache-2.0

org.apache.maven : maven-artifact : 3.8.5

Apache-2.0

org.apache.maven : maven-builder-support : 3.9.6

Apache-2.0

org.apache.maven : maven-resolver-provider : 3.9.4

Apache-2.0

org.apache.maven : maven-settings : 3.9.6

Apache-2.0

org.apache.maven : maven-settings-builder : 3.9.6

Apache-2.0

org.apache.maven.resolver : maven-resolver-api : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-connector-basic : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-impl : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-named-locks : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-spi : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-supplier : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-file : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-http : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-wagon : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-util : 1.9.18

Apache-2.0

org.apache.maven.wagon : wagon-http : 3.4.2

Apache-2.0

org.apache.maven.wagon : wagon-http-shared : 3.4.2

Apache-2.0

org.apache.maven.wagon : wagon-provider-api : 3.4.2

Apache-2.0

org.apache.neethi : neethi : 3.2.0

Apache-2.0

org.apache.poi : poi : 5.2.4

Apache-2.0

org.apache.poi : poi-ooxml : 5.2.4

Apache-2.0

org.apache.poi : poi-ooxml-lite : 5.2.4

Apache-2.0

org.apache.santuario : xmlsec : 2.3.4

Apache-2.0

org.apache.velocity : velocity-engine-core : 2.3

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.2.1

Apache-2.0

org.apache.wss4j : wss4j-bindings : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-policy : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-common : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-dom : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-policy-stax : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-stax : 2.4.3

Apache-2.0

org.apache.xmlbeans : xmlbeans : 3.1.0

Apache-2.0

org.apache.xmlbeans : xmlbeans : 5.1.1

Apache-2.0

org.asynchttpclient : async-http-client : 2.12.3

Apache-2.0

org.asynchttpclient : async-http-client-netty-utils : 2.12.3

Apache-2.0

org.codehaus.plexus : plexus-cipher : 2.0

Apache-2.0

org.codehaus.plexus : plexus-component-annotations : 1.5.5

Apache-2.0

org.codehaus.plexus : plexus-component-annotations : 2.2.0

Apache-2.0

org.codehaus.plexus : plexus-interpolation : 1.26

Apache-2.0

org.codehaus.plexus : plexus-sec-dispatcher : 2.0

Apache-2.0

org.codehaus.plexus : plexus-utils : 3.3.0

Apache-2.0

org.codehaus.plexus : plexus-utils : 4.0.0

Apache-2.0

org.codehaus.plexus : plexus-xml : 3.0.0

Apache-2.0

org.cryptacular : cryptacular : 1.2.6

Apache-2.0

org.eclipse.jetty : jetty-client : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-http : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-io : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-security : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-server : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-servlet : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-util : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-util-ajax : 9.4.53.v20231009

Apache-2.0

org.ehcache : ehcache : 3.9.3

Apache-2.0

org.fusesource.jansi : jansi : 1.18

Apache-2.0

org.glassfish.jersey.containers : jersey-container-servlet : 2.39.1

Apache-2.0

org.glassfish.jersey.containers : jersey-container-servlet-core : 2.39.1

Apache-2.0

org.glassfish.jersey.core : jersey-client : 2.39.1

Apache-2.0

org.glassfish.jersey.core : jersey-common : 2.39.1

Apache-2.0

org.glassfish.jersey.core : jersey-server : 2.39.1

Apache-2.0

org.glassfish.jersey.ext : jersey-entity-filtering : 2.39.1

Apache-2.0

org.glassfish.jersey.inject : jersey-hk2 : 2.39.1

Apache-2.0

org.glassfish.jersey.media : jersey-media-json-jackson : 2.39.1

Apache-2.0

org.glassfish.jersey.media : jersey-media-multipart : 2.39.1

Apache-2.0

org.jasypt : jasypt : 1.9.2

Apache-2.0

org.jasypt : jasypt : 1.9.3

Apache-2.0

org.jetbrains : annotations : 13.0

Apache-2.0

org.jetbrains : annotations : 24.1.0

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib : 1.6.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib : 1.9.23

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-common : 1.6.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk7 : 1.6.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk7 : 1.9.23

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk8 : 1.6.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk8 : 1.9.23

Apache-2.0

org.jheaps : jheaps : 0.14

Apache-2.0

org.mapdb : mapdb : 1.0.6

Apache-2.0

org.objenesis : objenesis : 3.3

Apache-2.0

org.opensaml : opensaml-core : 3.4.6

Apache-2.0

org.opensaml : opensaml-profile-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-saml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-saml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-security-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-security-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-soap-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-saml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-saml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-xmlsec-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xmlsec-impl : 3.4.6

Apache-2.0

org.parboiled : parboiled_2.12 : 2.5.1

Apache-2.0

org.quartz-scheduler : quartz : 2.3.2

Apache-2.0

org.raml : raml-parser-2 : 1.0.44-15

Apache-2.0

org.raml : yagi : 1.0.44-15

Apache-2.0

org.reflections : reflections : 0.10.2

Apache-2.0

org.scala-lang : scala-library : 2.12.15

Apache-2.0

org.scala-lang.modules : scala-parser-combinators_2.12 : 2.1.1

Apache-2.0

org.slf4j : jcl-over-slf4j : 2.0.12

Apache-2.0

org.springframework : spring-aop : 5.3.33

Apache-2.0

org.springframework : spring-beans : 5.3.33

Apache-2.0

org.springframework : spring-context : 5.3.33

Apache-2.0

org.springframework : spring-context-support : 5.3.33

Apache-2.0

org.springframework : spring-core : 5.3.29

Apache-2.0

org.springframework : spring-core : 5.3.33

Apache-2.0

org.springframework : spring-expression : 5.3.33

Apache-2.0

org.springframework : spring-jcl : 5.3.29

Apache-2.0

org.togglz : togglz-core : 3.2.1

Apache-2.0

org.vibur : vibur-object-pool : 25.0

Apache-2.0

org.xmlresolver : xmlresolver : 5.2.2

Apache-2.0

org.xmlresolver : xmlresolver : jar : data : 5.2.2

Apache-2.0

org.yaml : snakeyaml : 2.0

Apache-2.0

org.yaml : snakeyaml : 2.2

Apache-2.0

software.amazon.ion : ion-java : 1.0.2

Apache-2.0

xml-apis : xml-apis : 1.4.01

Bouncycastle-license

org.bouncycastle : bcprov-jdk18on : 1.76

BSD

com.github.virtuald : curvesapi : 1.08

BSD

net.java.dev.stax-utils : stax-utils : 20080702

BSD

org.antlr : antlr-runtime : 3.5.3

BSD

org.jline : jline : 3.19.0

BSD-2-Clause

org.codehaus.woodstox : stax2-api : 4.2.2

BSD-3-Clause

com.esotericsoftware : kryo : 5.5.0

BSD-3-Clause

com.esotericsoftware : kryo-shaded : 4.0.3

BSD-3-Clause

com.esotericsoftware : kryo-shaded : 4.0.3

BSD-3-Clause

com.esotericsoftware : minlog : 1.3.1

BSD-3-Clause

com.esotericsoftware : reflectasm : 1.11.9

BSD-3-Clause

com.google.protobuf : protobuf-java : 3.21.9

BSD-3-Clause

com.google.re2j : re2j : 1.6

BSD-3-Clause

com.google.re2j : re2j : 1.7

BSD-3-Clause

org.ow2.asm : asm : 9.6

CC0-1.0

org.reactivestreams : reactive-streams : 1.0.3

CDDL-1.1

javax.servlet : javax.servlet-api : 3.1.0

CDDL-1.1

javax.ws.rs : javax.ws.rs-api : 2.0

CDDL-1.1

org.glassfish.grizzly : connection-pool : 2.4.0-beta3

CDDL-1.1

org.glassfish.grizzly : grizzly-framework : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-framework : 2.4.0-beta2

CDDL-1.1

org.glassfish.grizzly : grizzly-http : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-http-server : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-http-servlet : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-websockets : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-websockets : 2.4.0-beta4

CPAL-1.0

org.mule.tools.maven : mule-classloader-model : 4.1.1

CPL-1.0

wsdl4j : wsdl4j : 1.6.3

DOM4j-License

org.dom4j : dom4j : 2.1.4

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.1

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.2

EDL-1.0

com.sun.istack : istack-commons-runtime : 3.0.12

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.3

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.7

EDL-1.0

com.sun.mail : mailapi : 1.6.7

EDL-1.0

com.sun.xml.bind : jaxb-impl : 2.3.8

EDL-1.0

com.sun.xml.messaging.saaj : saaj-impl : 1.5.3

EDL-1.0

jakarta.jws : jakarta.jws-api : 1.1.1

EDL-1.0

jakarta.xml.bind : jakarta.xml.bind-api : 2.3.3

EDL-1.0

jakarta.xml.soap : jakarta.xml.soap-api : 1.4.2

EDL-1.0

jakarta.xml.ws : jakarta.xml.ws-api : 2.3.3

EDL-1.0

org.glassfish.jaxb : jaxb-runtime : 2.3.5

EDL-1.0

org.glassfish.jaxb : txw2 : 2.3.5

EDL-1.0

org.jvnet.mimepull : mimepull : 1.9.15

EDL-1.0

org.jvnet.staxex : stax-ex : 1.8.3

EPL-1.0

com.mchange : c3p0 : 0.10.0

EPL-1.0

com.mchange : mchange-commons-java : 0.3.0

EPL-1.0

org.eclipse.sisu : org.eclipse.sisu.inject : 0.3.5

EPL-1.0

org.eclipse.sisu : org.eclipse.sisu.plexus : 0.3.5

EPL-2.0

jakarta.annotation : jakarta.annotation-api : 1.3.5

EPL-2.0

jakarta.jms : jakarta.jms-api : 2.0.3

EPL-2.0

jakarta.resource : jakarta.resource-api : 1.7.4

EPL-2.0

jakarta.servlet : jakarta.servlet-api : 4.0.4

EPL-2.0

jakarta.transaction : jakarta.transaction-api : 1.3.3

EPL-2.0

jakarta.ws.rs : jakarta.ws.rs-api : 2.1.6

EPL-2.0

org.glassfish : jakarta.json : 1.1.6

EPL-2.0

org.glassfish.hk2 : hk2-api : 2.6.1

EPL-2.0

org.glassfish.hk2 : hk2-locator : 2.6.1

EPL-2.0

org.glassfish.hk2 : hk2-utils : 2.6.1

EPL-2.0

org.glassfish.hk2 : osgi-resource-locator : 1.0.3

EPL-2.0

org.glassfish.hk2.external : aopalliance-repackaged : 2.6.1

EPL-2.0

org.glassfish.hk2.external : jakarta.inject : 2.6.1

EPL-2.0

org.jgrapht : jgrapht-core : 1.3.1

ICU または Unicode

com.ibm.icu : icu4j : 71.1

LGPL-2.1

com.github.spotbugs : spotbugs-annotations : 4.7.3

LGPL-3.0

org.mule.btm : mule-btm : 2.1.20

MIT

com.vdurmont : semver4j : 3.1.0

MIT

handlebars 4.7.7

MIT

me.tongfei : progressbar : 0.9.1

MIT

net.sf.jopt-simple : jopt-simple : 5.0.3

MIT

org.bouncycastle : bcutil-jdk15to18 : 1.74

MIT

org.checkerframework : checker-qual : 3.19.0

MIT

org.checkerframework : checker-qual : 3.33.0

MIT

org.checkerframework : checker-qual : 3.42.0

MIT

org.graalvm.js : js : 22.3.5

MIT

org.graalvm.js js 1.0.0-rc15

MIT

org.jsoup : jsoup : 1.17.2

MIT

org.mule.com.github.stephenc.eaio-uuid : uuid : 3.4.2-mule-001

MIT

org.slf4j : jul-to-slf4j : 2.0.12

MIT

org.slf4j : slf4j-api : 1.7.30

MIT

org.slf4j : slf4j-api : 2.0.12

MIT-0

org.reactivestreams : reactive-streams : 1.0.4

MPL-1.1

com.googlecode.juniversalchardet : juniversalchardet : 1.0.3

MPL-2.0

net.sf.saxon : saxon-he : 12.4

MPL-2.0

org.mozilla : rhino : 1.7.14

Non-Standard

de.schlichtherle : truelicense : 1.29

Non-Standard

de.schlichtherle : truexml : 1.29

Non-Standard

org.mule.apache : xerces2-xsd11 : 2.11.3-mule-002

Non-Standard

org.mule.common : scala-common_2.12 : 2.0.99

Non-Standard

org.mule.syaml : syaml_2.12 : 2.0.334

Public Domain

org.json : json : 20231013

Public Domain

org.json : json : 20240303

UPL-1.0

org.graalvm.js : js-scriptengine : 22.3.5

UPL-1.0

org.graalvm.regex : regex : 22.3.5

UPL-1.0

org.graalvm.sdk : graal-sdk : 22.3.5

UPL-1.0

org.graalvm.truffle : truffle-api : 22.3.5
## [](#ライセンス情報)ライセンス情報 各ライセンス種別に関する情報は次の場所にあります。 - `http://aopalliance.sourceforge.net/`​ (AOP) - `https://opensource.org/licenses/APACHE-2.0`​ (Apache-2.0) - `https://en.wikipedia.org/wiki/BSD_licenses`​ (BSD) - `https://opensource.org/licenses/BSD-2-Clause`​ (BSD-2-Clause) - `https://opensource.org/licenses/BSD-3-Clause`​ (BSD-3-Clause) - `https://spdx.org/licenses/CDDL-1.1.html`​ (CDDL-1.1) - `https://opensource.org/licenses/CPAL-1.0`​ (CPAL-1.0) - `https://opensource.org/licenses/CPL-1.0`​ (CPL-1.0) - `https://opensource.org/licenses/EPL-2.0`​ (EPL-2.0) - `http://source.icu-project.org/repos/icu/icu/trunk/LICENSE`​ (ICU) - `https://github.com/stleary/JSON-java/blob/master/LICENSE`​ (JSON) - `https://opensource.org/licenses/LGPL-2.1`​ (LGPL-2.1) - `https://opensource.org/licenses/MIT`​ (MIT) - `https://opensource.org/licenses/MPL-1.1`​ (MPL-1.1) - `https://opensource.org/licenses/MPL-2.0`​ (MPL-2.0) # Mule のサードパーティソフトウェア Mule Runtime Engine は、含まれるサードパーティソフトウェアのライブラリのサブセットに内部で連動しています。Mule アプリケーションには、サードパーティソフトウェアリストに含まれていない追加のサードパーティ連動関係 (Apache Maven から管理) が含まれている可能性もあります。 ## [](#サードパーティソフトウェアリスト)サードパーティソフトウェアリスト 次の表では、Mule のサードパーティソフトウェアをソフトウェアコンポーネント別に示しています。
ライセンス コンポーネント

Apache-1.0

org.javassist : javassist : 3.28.0-ga

Apache-2.0

com.amazonaws : aws-java-sdk-cloudwatch : 1.12.674

Apache-2.0

com.amazonaws : aws-java-sdk-core : 1.12.674

Apache-2.0

com.amazonaws : aws-java-sdk-pinpoint : 1.12.674

Apache-2.0

com.amazonaws : jmespath-java : 1.12.674

Apache-2.0

com.beust : jcommander : 1.82

Apache-2.0

com.conversantmedia : disruptor : 1.2.10

Apache-2.0

com.damnhandy : handy-uri-templates : 2.1.8

Apache-2.0

com.fasterxml : aalto-xml : 1.3.2

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.16.0

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.16.1

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.17.2

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.16.0

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.16.1

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.17.2

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.16.0

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.16.1

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.17.2

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-cbor : 2.12.6

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-yaml : 2.17.2

Apache-2.0

com.fasterxml.jackson.datatype : jackson-datatype-jsr310 : 2.17.2

Apache-2.0

com.fasterxml.jackson.module : jackson-module-jaxb-annotations : 2.14.1

Apache-2.0

com.fasterxml.jackson.module : jackson-module-jsonschema : 2.17.2

Apache-2.0

com.fasterxml.uuid : java-uuid-generator : 3.1.3

Apache-2.0

com.fasterxml.woodstox : woodstox-core : 6.6.1

Apache-2.0

com.fasterxml.woodstox : woodstox-core : 6.6.2

Apache-2.0

com.github.ben-manes.caffeine : caffeine : 2.9.3

Apache-2.0

com.github.erosb : everit-json-schema : 1.14.3

Apache-2.0

com.github.fge : btf : 1.2

Apache-2.0

com.github.fge : msg-simple : 1.1

Apache-2.0

com.github.fge : uri-template : 0.9

Apache-2.0

com.github.java-json-tools : jackson-coreutils : 1.9

Apache-2.0

com.github.java-json-tools : json-schema-core : 1.2.10

Apache-2.0

com.github.java-json-tools : json-schema-validator : 2.2.10

Apache-2.0

com.github.jknack : handlebars : 4.3.1

Apache-2.0

com.github.jknack handlebars-proto 4.1.0

Apache-2.0

com.github.jsendnsca : jsendnsca : 2.1.1

Apache-2.0

com.github.pjfanning : excel-streaming-reader : 4.1.2

Apache-2.0

com.github.pjfanning : poi-shared-strings : 2.6.1

Apache-2.0

com.google.code.findbugs : jsr305 : 3.0.2

Apache-2.0

com.google.code.gson : gson : 2.11.0

Apache-2.0

com.google.code.gson : gson : 2.8.9

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.10.0

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.18.0

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.29.2

Apache-2.0

com.google.guava : failureaccess : 1.0.1

Apache-2.0

com.google.guava : failureaccess : 1.0.2

Apache-2.0

com.google.guava : guava : 32.0.1-jre

Apache-2.0

com.google.guava : guava : 33.2.1-jre

Apache-2.0

com.google.guava : listenablefuture : 9999.0-empty-to-avoid-conflict-with-guava

Apache-2.0

com.google.inject : guice : 5.0.1

Apache-2.0

com.google.j2objc : j2objc-annotations : 2.8

Apache-2.0

com.google.j2objc : j2objc-annotations : 3.0.0

Apache-2.0

com.googlecode.libphonenumber : libphonenumber : 8.0.0

Apache-2.0

com.hazelcast : hazelcast : 5.2.5

Apache-2.0

com.lmax : disruptor : 3.4.3

Apache-2.0

com.lmax : disruptor : 3.4.4

Apache-2.0

com.netflix.servo : servo-core : 0.12.22

Apache-2.0

com.netflix.spectator : spectator-api : 0.67.0

Apache-2.0

com.splunk : splunk : 1.6.4.0

Apache-2.0

com.squareup : tape : 1.2.2

Apache-2.0

com.squareup.okhttp3 : logging-interceptor : 4.11.0

Apache-2.0

com.squareup.okhttp3 : okhttp : 4.11.0

Apache-2.0

com.squareup.okhttp3 : okhttp : 4.12.0

Apache-2.0

com.squareup.okio : okio : 3.4.0

Apache-2.0

com.squareup.okio : okio-jvm : 3.4.0

Apache-2.0

com.squareup.okio : okio-jvm : 3.9.0

Apache-2.0

com.typesafe : config : 1.4.3

Apache-2.0

com.typesafe.netty : netty-reactive-streams : 2.0.4

Apache-2.0

com.zaxxer : hikaricp-java7 : 2.4.13

Apache-2.0

com.zaxxer : sparsebitset : 1.3

Apache-2.0

commons-beanutils : commons-beanutils : 1.9.4

Apache-2.0

commons-cli : commons-cli : 1.4

Apache-2.0

commons-cli : commons-cli : 1.8.0

Apache-2.0

commons-codec : commons-codec : 1.14

Apache-2.0

commons-codec : commons-codec : 1.16.0

Apache-2.0

commons-codec : commons-codec : 1.17.1

Apache-2.0

commons-collections : commons-collections : 3.2.2

Apache-2.0

commons-dbutils : commons-dbutils : 1.8.1

Apache-2.0

commons-digester : commons-digester : 2.1

Apache-2.0

commons-io : commons-io : 2.15.1

Apache-2.0

commons-io : commons-io : 2.16.1

Apache-2.0

commons-io : commons-io : 2.8.0

Apache-2.0

commons-lang : commons-lang : 2.4

Apache-2.0

commons-lang : commons-lang : 2.6

Apache-2.0

commons-logging : commons-logging : 1.2

Apache-2.0

commons-validator : commons-validator : 1.7

Apache-2.0

de.javakaffee : kryo-serializers : 0.45

Apache-2.0

io.dropwizard.metrics : metrics-core : 3.1.5

Apache-2.0

io.grpc : grpc-api : 1.66.0

Apache-2.0

io.grpc : grpc-context : 1.66.0

Apache-2.0

io.grpc : grpc-core : 1.66.0

Apache-2.0

io.jsonwebtoken : jjwt-api : 0.11.5

Apache-2.0

io.jsonwebtoken : jjwt-gson : 0.11.5

Apache-2.0

io.jsonwebtoken : jjwt-impl : 0.11.5

Apache-2.0

io.netty : netty-buffer : 4.1.104.final

Apache-2.0

io.netty : netty-buffer : 4.1.113.final

Apache-2.0

io.netty : netty-codec : 4.1.104.final

Apache-2.0

io.netty : netty-codec : 4.1.113.final

Apache-2.0

io.netty : netty-codec-dns : 4.1.112.final

Apache-2.0

io.netty : netty-codec-http : 4.1.104.final

Apache-2.0

io.netty : netty-codec-http : 4.1.113.final

Apache-2.0

io.netty : netty-codec-http2 : 4.1.113.final

Apache-2.0

io.netty : netty-codec-socks : 4.1.104.final

Apache-2.0

io.netty : netty-codec-socks : 4.1.113.final

Apache-2.0

io.netty : netty-common : 4.1.104.final

Apache-2.0

io.netty : netty-common : 4.1.113.final

Apache-2.0

io.netty : netty-handler : 4.1.104.final

Apache-2.0

io.netty : netty-handler : 4.1.113.final

Apache-2.0

io.netty : netty-handler-proxy : 4.1.104.final

Apache-2.0

io.netty : netty-handler-proxy : 4.1.113.final

Apache-2.0

io.netty : netty-resolver : 4.1.104.final

Apache-2.0

io.netty : netty-resolver : 4.1.113.final

Apache-2.0

io.netty : netty-resolver-dns : 4.1.112.final

Apache-2.0

io.netty : netty-transport : 4.1.104.final

Apache-2.0

io.netty : netty-transport : 4.1.113.final

Apache-2.0

io.netty : netty-transport-classes-epoll : 4.1.104.final

Apache-2.0

io.netty : netty-transport-classes-epoll : 4.1.112.final

Apache-2.0

io.netty : netty-transport-native-epoll : jar : linux-x​86_64​ : 4.1.104.final

Apache-2.0

io.netty : netty-transport-native-epoll : jar : linux-x​86_64​ : 4.1.112.final

Apache-2.0

io.netty : netty-transport-native-unix-common : 4.1.104.final

Apache-2.0

io.netty : netty-transport-native-unix-common : 4.1.113.final

Apache-2.0

io.opentelemetry : opentelemetry-api : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-api-incubator : 1.40.0-alpha

Apache-2.0

io.opentelemetry : opentelemetry-context : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-common : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-logging : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-otlp : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-otlp-common : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-exporter-sender-okhttp : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-common : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-extension-autoconfigure-spi : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-logs : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-metrics : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-testing : 1.40.0

Apache-2.0

io.opentelemetry : opentelemetry-sdk-trace : 1.40.0

Apache-2.0

io.perfmark : perfmark-api : 0.27.0

Apache-2.0

io.projectreactor : reactor-core : 3.6.8

Apache-2.0

io.projectreactor.addons : reactor-extra : 3.5.1

Apache-2.0

io.projectreactor.netty : reactor-netty-core : 1.1.22

Apache-2.0

io.projectreactor.netty : reactor-netty-http : 1.1.22

Apache-2.0

io.qameta.allure : allure-java-commons : 2.28.1

Apache-2.0

io.qameta.allure : allure-junit4 : 2.28.1

Apache-2.0

io.qameta.allure : allure-model : 2.28.1

Apache-2.0

io.qameta.allure : allure-test-filter : 2.28.1

Apache-2.0

it.unimi.dsi : fastutil : 8.5.14

Apache-2.0

jakarta.inject : jakarta.inject-api : 1.0.5

Apache-2.0

jakarta.validation : jakarta.validation-api : 2.0.2

Apache-2.0

javax.inject : javax.inject : 1

Apache-2.0

javax.validation : validation-api : 1.0.0.ga

Apache-2.0

javax.validation : validation-api : 1.1.0.final

Apache-2.0

joda-time : joda-time : 2.10.2

Apache-2.0

joda-time : joda-time : 2.12.7

Apache-2.0

joda-time : joda-time : 2.9.1

Apache-2.0

net.bytebuddy : byte-buddy : 1.14.18

Apache-2.0

net.jodah : failsafe : 2.4.4

Apache-2.0

net.shibboleth.utilities : java-support : 7.5.2

Apache-2.0

org.apache.avro : avro : 1.11.3

Apache-2.0

org.apache.commons : commons-collections4 : 4.4

Apache-2.0

org.apache.commons : commons-compress : 1.26.0

Apache-2.0

org.apache.commons : commons-compress : 1.26.2

Apache-2.0

org.apache.commons : commons-lang3 : 3.14.0

Apache-2.0

org.apache.commons : commons-lang3 : 3.16.0

Apache-2.0

org.apache.commons : commons-lang3 : 3.4

Apache-2.0

org.apache.commons : commons-math3 : 3.6.1

Apache-2.0

org.apache.commons : commons-pool2 : 2.12.0

Apache-2.0

org.apache.commons : commons-text : 1.10.0

Apache-2.0

org.apache.commons : commons-text : 1.12.0

Apache-2.0

org.apache.cxf : cxf-core : 3.5.9

Apache-2.0

org.apache.cxf : cxf-rt-bindings-soap : 3.5.9

Apache-2.0

org.apache.cxf : cxf-rt-databinding-jaxb : 3.5.9

Apache-2.0

org.apache.cxf : cxf-rt-frontend-simple : 3.5.9

Apache-2.0

org.apache.cxf : cxf-rt-management : 3.5.9

Apache-2.0

org.apache.cxf : cxf-rt-security : 3.5.9

Apache-2.0

org.apache.cxf : cxf-rt-security-saml : 3.5.9

Apache-2.0

org.apache.cxf : cxf-rt-ws-addr : 3.5.9

Apache-2.0

org.apache.cxf : cxf-rt-ws-policy : 3.5.9

Apache-2.0

org.apache.cxf : cxf-rt-ws-rm : 3.5.9

Apache-2.0

org.apache.cxf : cxf-rt-ws-security : 3.5.9

Apache-2.0

org.apache.cxf : cxf-rt-wsdl : 3.5.9

Apache-2.0

org.apache.httpcomponents : fluent-hc : 4.5.14

Apache-2.0

org.apache.httpcomponents : httpclient : 4.5.13

Apache-2.0

org.apache.httpcomponents : httpclient : 4.5.14

Apache-2.0

org.apache.httpcomponents : httpcore : 4.4.16

Apache-2.0

org.apache.httpcomponents : httpcore : 4.4.5

Apache-2.0

org.apache.httpcomponents.client5 : httpclient5 : 5.1.3

Apache-2.0

org.apache.httpcomponents.core5 : httpcore5 : 5.1.3

Apache-2.0

org.apache.httpcomponents.core5 : httpcore5-h2 : 5.1.3

Apache-2.0

org.apache.logging.log4j : log4j-1.2-api : 2.22.1

Apache-2.0

org.apache.logging.log4j : log4j-1.2-api : 2.23.1

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.20.0

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.22.1

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.23.1

Apache-2.0

org.apache.logging.log4j : log4j-core : 2.22.1

Apache-2.0

org.apache.logging.log4j : log4j-core : 2.23.1

Apache-2.0

org.apache.logging.log4j : log4j-slf4j2-impl : 2.20.0

Apache-2.0

org.apache.logging.log4j : log4j-slf4j2-impl : 2.23.1

Apache-2.0

org.apache.maven : maven-artifact : 3.8.5

Apache-2.0

org.apache.maven : maven-builder-support : 3.9.8

Apache-2.0

org.apache.maven : maven-model-builder : 3.9.8

Apache-2.0

org.apache.maven : maven-resolver-provider : 3.9.8

Apache-2.0

org.apache.maven : maven-settings : 3.9.8

Apache-2.0

org.apache.maven : maven-settings-builder : 3.9.8

Apache-2.0

org.apache.maven.resolver : maven-resolver-api : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-connector-basic : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-impl : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-named-locks : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-spi : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-supplier : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-file : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-http : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-wagon : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-util : 1.9.18

Apache-2.0

org.apache.maven.wagon : wagon-http : 3.5.3

Apache-2.0

org.apache.maven.wagon : wagon-http-shared : 3.5.3

Apache-2.0

org.apache.maven.wagon : wagon-provider-api : 3.5.3

Apache-2.0

org.apache.neethi : neethi : 3.2.0

Apache-2.0

org.apache.poi : poi : 5.2.4

Apache-2.0

org.apache.poi : poi-ooxml : 5.2.4

Apache-2.0

org.apache.poi : poi-ooxml-lite : 5.2.4

Apache-2.0

org.apache.santuario : xmlsec : 2.3.4

Apache-2.0

org.apache.velocity : velocity-engine-core : 2.3

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.2.1

Apache-2.0

org.apache.wss4j : wss4j-bindings : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-policy : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-common : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-dom : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-policy-stax : 2.4.3

Apache-2.0

org.apache.wss4j : wss4j-ws-security-stax : 2.4.3

Apache-2.0

org.apache.xmlbeans : xmlbeans : 3.1.0

Apache-2.0

org.apache.xmlbeans : xmlbeans : 5.1.1

Apache-2.0

org.asynchttpclient : async-http-client : 2.12.3

Apache-2.0

org.asynchttpclient : async-http-client-netty-utils : 2.12.3

Apache-2.0

org.codehaus.plexus : plexus-cipher : 2.0

Apache-2.0

org.codehaus.plexus : plexus-component-annotations : 1.5.5

Apache-2.0

org.codehaus.plexus : plexus-component-annotations : 2.2.0

Apache-2.0

org.codehaus.plexus : plexus-interpolation : 1.27

Apache-2.0

org.codehaus.plexus : plexus-sec-dispatcher : 2.0

Apache-2.0

org.codehaus.plexus : plexus-utils : 3.3.0

Apache-2.0

org.codehaus.plexus : plexus-utils : 4.0.1

Apache-2.0

org.codehaus.plexus : plexus-xml : 3.0.1

Apache-2.0

org.cryptacular : cryptacular : 1.2.6

Apache-2.0

org.eclipse.jetty : jetty-client : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-http : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-io : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-security : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-server : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-servlet : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-util : 9.4.53.v20231009

Apache-2.0

org.eclipse.jetty : jetty-util-ajax : 9.4.53.v20231009

Apache-2.0

org.ehcache : ehcache : 3.9.3

Apache-2.0

org.fusesource.jansi : jansi : 1.18

Apache-2.0

org.glassfish.jersey.containers : jersey-container-servlet : 2.39.1

Apache-2.0

org.glassfish.jersey.containers : jersey-container-servlet-core : 2.39.1

Apache-2.0

org.glassfish.jersey.core : jersey-client : 2.39.1

Apache-2.0

org.glassfish.jersey.core : jersey-common : 2.39.1

Apache-2.0

org.glassfish.jersey.core : jersey-server : 2.39.1

Apache-2.0

org.glassfish.jersey.ext : jersey-entity-filtering : 2.39.1

Apache-2.0

org.glassfish.jersey.inject : jersey-hk2 : 2.39.1

Apache-2.0

org.glassfish.jersey.media : jersey-media-json-jackson : 2.39.1

Apache-2.0

org.glassfish.jersey.media : jersey-media-multipart : 2.39.1

Apache-2.0

org.jasypt : jasypt : 1.9.2

Apache-2.0

org.jasypt : jasypt : 1.9.3

Apache-2.0

org.jetbrains : annotations : 13.0

Apache-2.0

org.jetbrains : annotations : 24.1.0

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib : 1.6.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib : 1.9.25

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-common : 1.6.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk7 : 1.6.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk7 : 1.9.25

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk8 : 1.6.20

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk8 : 1.9.25

Apache-2.0

org.jheaps : jheaps : 0.14

Apache-2.0

org.mapdb : mapdb : 1.0.6

Apache-2.0

org.objenesis : objenesis : 3.4

Apache-2.0

org.opensaml : opensaml-core : 3.4.6

Apache-2.0

org.opensaml : opensaml-profile-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-saml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-saml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-security-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-security-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-soap-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-saml-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xacml-saml-impl : 3.4.6

Apache-2.0

org.opensaml : opensaml-xmlsec-api : 3.4.6

Apache-2.0

org.opensaml : opensaml-xmlsec-impl : 3.4.6

Apache-2.0

org.parboiled : parboiled_2.12 : 2.5.1

Apache-2.0

org.quartz-scheduler : quartz : 2.3.2

Apache-2.0

org.raml : raml-parser-2 : 1.0.44-15

Apache-2.0

org.raml : yagi : 1.0.44-15

Apache-2.0

org.reflections : reflections : 0.10.2

Apache-2.0

org.scala-lang : scala-library : 2.12.15

Apache-2.0

org.scala-lang.modules : scala-parser-combinators_2.12 : 2.1.1

Apache-2.0

org.slf4j : jcl-over-slf4j : 2.0.14

Apache-2.0

org.slf4j : jcl-over-slf4j : 2.0.7

Apache-2.0

org.springframework : spring-aop : 5.3.39

Apache-2.0

org.springframework : spring-beans : 5.3.39

Apache-2.0

org.springframework : spring-context : 5.3.39

Apache-2.0

org.springframework : spring-context-support : 5.3.39

Apache-2.0

org.springframework : spring-core : 5.3.33

Apache-2.0

org.springframework : spring-core : 5.3.39

Apache-2.0

org.springframework : spring-expression : 5.3.39

Apache-2.0

org.springframework : spring-jcl : 5.3.33

Apache-2.0

org.togglz : togglz-core : 3.2.1

Apache-2.0

org.vibur : vibur-object-pool : 25.0

Apache-2.0

org.xmlresolver : xmlresolver : 5.2.2

Apache-2.0

org.xmlresolver : xmlresolver : jar : data : 5.2.2

Apache-2.0

org.yaml : snakeyaml : 2.0

Apache-2.0

org.yaml : snakeyaml : 2.2

Apache-2.0

xml-apis : xml-apis : 1.4.01

Bouncycastle-license

org.bouncycastle : bcprov-jdk18on : 1.76

BSD

net.java.dev.stax-utils : stax-utils : 20080702

BSD-2-Clause

org.codehaus.woodstox : stax2-api : 4.2.2

BSD-3-Clause

com.esotericsoftware : kryo : 5.5.0

BSD-3-Clause

com.esotericsoftware : kryo-shaded : 4.0.3

BSD-3-Clause

com.esotericsoftware : minlog : 1.3.1

BSD-3-Clause

com.esotericsoftware : reflectasm : 1.11.9

BSD-3-Clause

com.github.virtuald : curvesapi : 1.08

BSD-3-Clause

com.google.protobuf : protobuf-java : 3.21.9

BSD-3-Clause

com.google.re2j : re2j : 1.6

BSD-3-Clause

com.google.re2j : re2j : 1.7

BSD-3-Clause

org.antlr : antlr-runtime : 3.5.3

BSD-3-Clause

org.jline : jline : 3.19.0

BSD-3-Clause

org.ow2.asm : asm : 9.7

CC0-1.0

org.reactivestreams : reactive-streams : 1.0.3

CDDL-1.1

javax.servlet : javax.servlet-api : 3.1.0

CDDL-1.1

javax.ws.rs : javax.ws.rs-api : 2.0

CDDL-1.1

org.glassfish.grizzly : grizzly-framework : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-http : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-websockets : 2.3.34

DOM4j-License

org.dom4j : dom4j : 2.1.4

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.1

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.2

EDL-1.0

com.sun.istack : istack-commons-runtime : 3.0.12

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.3

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.7

EDL-1.0

com.sun.xml.bind : jaxb-impl : 2.3.8

EDL-1.0

com.sun.xml.messaging.saaj : saaj-impl : 1.5.3

EDL-1.0

jakarta.jws : jakarta.jws-api : 1.1.1

EDL-1.0

jakarta.xml.bind : jakarta.xml.bind-api : 2.3.3

EDL-1.0

jakarta.xml.soap : jakarta.xml.soap-api : 1.4.2

EDL-1.0

jakarta.xml.ws : jakarta.xml.ws-api : 2.3.3

EDL-1.0

org.glassfish.jaxb : jaxb-runtime : 2.3.5

EDL-1.0

org.glassfish.jaxb : txw2 : 2.3.5

EDL-1.0

org.jvnet.mimepull : mimepull : 1.9.15

EDL-1.0

org.jvnet.staxex : stax-ex : 1.8.3

EDL-1.0

com.mchange : c3p0 : 0.10.1

EDL-1.0

com.mchange : mchange-commons-java : 0.3.1

EDL-1.0

junit : junit : 4.13.2

EDL-1.0

org.eclipse.sisu : org.eclipse.sisu.inject : 0.3.5

EDL-1.0

org.eclipse.sisu : org.eclipse.sisu.plexus : 0.3.5

EPL-2.0

jakarta.annotation : jakarta.annotation-api : 1.3.5

EPL-2.0

jakarta.jms : jakarta.jms-api : 2.0.3

EPL-2.0

jakarta.resource : jakarta.resource-api : 1.7.4

EPL-2.0

jakarta.servlet : jakarta.servlet-api : 4.0.4

EPL-2.0

jakarta.transaction : jakarta.transaction-api : 1.3.3

EPL-2.0

jakarta.ws.rs : jakarta.ws.rs-api : 2.1.6

EPL-2.0

org.glassfish : jakarta.json : 1.1.6

EPL-2.0

org.glassfish.hk2 : hk2-api : 2.6.1

EPL-2.0

org.glassfish.hk2 : hk2-locator : 2.6.1

EPL-2.0

org.glassfish.hk2 : hk2-utils : 2.6.1

EPL-2.0

org.glassfish.hk2 : osgi-resource-locator : 1.0.3

EPL-2.0

org.glassfish.hk2.external : aopalliance-repackaged : 2.6.1

EPL-2.0

org.glassfish.hk2.external : jakarta.inject : 2.6.1

EPL-2.0

org.jgrapht : jgrapht-core : 1.3.1

ICU または Unicode

com.ibm.icu : icu4j : 71.1

LGPL-2.1

com.github.spotbugs : spotbugs-annotations : 4.7.3

LGPL-3.0

eu.agno3.jcifs : jcifs-ng : 2.1.10

MIT

com.vdurmont : semver4j : 3.1.0

MIT

handlebars 4.7.7

MIT

me.tongfei : progressbar : 0.9.1

MIT

me.tongfei : progressbar : 0.9.1

MIT

org.bouncycastle : bcprov-jdk15to18 : 1.74

MIT

org.bouncycastle : bcutil-jdk15to18 : 1.74

MIT

org.checkerframework : checker-qual : 3.19.0

MIT

org.checkerframework : checker-qual : 3.33.0

MIT

org.checkerframework : checker-qual : 3.46.0

MIT

org.graalvm.js : js : 22.3.5

MIT

org.graalvm.js js 1.0.0-rc15

MIT

org.jsoup : jsoup : 1.18.1

MIT

org.slf4j : jul-to-slf4j : 2.0.14

MIT

org.slf4j : jul-to-slf4j : 2.0.7

MIT

org.slf4j : slf4j-api : 1.7.30

MIT

org.slf4j : slf4j-api : 2.0.14

MIT-0

org.reactivestreams : reactive-streams : 1.0.4

MPL-1.1

com.googlecode.juniversalchardet : juniversalchardet : 1.0.3

MPL-2.0

net.sf.saxon : saxon-he : 12.5

MPL-2.0

org.mozilla : rhino : 1.7.15

Public Domain

org.json : json : 20231013

Public Domain

org.json : json : 20240303

UPL-1.0

org.graalvm.js : js-scriptengine : 22.3.5

UPL-1.0

org.graalvm.regex : regex : 22.3.5

UPL-1.0

org.graalvm.sdk : graal-sdk : 22.3.5

UPL-1.0

org.graalvm.truffle : truffle-api : 22.3.5
## [](#ライセンス情報)ライセンス情報 各ライセンス種別に関する情報は次の場所にあります。 - `http://aopalliance.sourceforge.net/`​ (AOP) - `https://opensource.org/licenses/APACHE-2.0`​ (Apache-2.0) - `https://en.wikipedia.org/wiki/BSD_licenses`​ (BSD) - `https://opensource.org/licenses/BSD-2-Clause`​ (BSD-2-Clause) - `https://opensource.org/licenses/BSD-3-Clause`​ (BSD-3-Clause) - `https://spdx.org/licenses/CDDL-1.1.html`​ (CDDL-1.1) - `https://opensource.org/licenses/CPAL-1.0`​ (CPAL-1.0) - `https://opensource.org/licenses/CPL-1.0`​ (CPL-1.0) - `https://opensource.org/licenses/EPL-2.0`​ (EPL-2.0) - `http://source.icu-project.org/repos/icu/icu/trunk/LICENSE`​ (ICU) - `https://github.com/stleary/JSON-java/blob/master/LICENSE`​ (JSON) - `https://opensource.org/licenses/LGPL-2.1`​ (LGPL-2.1) - `https://opensource.org/licenses/MIT`​ (MIT) - `https://opensource.org/licenses/MPL-1.1`​ (MPL-1.1) - `https://opensource.org/licenses/MPL-2.0`​ (MPL-2.0) # Mule のサードパーティソフトウェア Mule Runtime Engine は、含まれるサードパーティソフトウェアのライブラリのサブセットに内部で連動しています。Mule アプリケーションには、サードパーティソフトウェアリストに含まれていない追加のサードパーティ連動関係 (Apache Maven から管理) が含まれている可能性もあります。 ## [](#サードパーティソフトウェアリスト)サードパーティソフトウェアリスト 次の表では、Mule のサードパーティソフトウェアをソフトウェアコンポーネント別に示しています。
ライセンス コンポーネント

Apache-2.0

com.beust : jcommander : 1.82

Apache-2.0

com.conversantmedia : disruptor : 1.2.21

Apache-2.0

com.damnhandy : handy-uri-templates : 2.1.8

Apache-2.0

com.fasterxml : aalto-xml : 1.3.2

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.16.1

Apache-2.0

com.fasterxml.jackson.core : jackson-annotations : 2.18.2

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.16.1

Apache-2.0

com.fasterxml.jackson.core : jackson-core : 2.18.2

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.16.1

Apache-2.0

com.fasterxml.jackson.core : jackson-databind : 2.18.2

Apache-2.0

com.fasterxml.jackson.dataformat : jackson-dataformat-yaml : 2.18.2

Apache-2.0

com.fasterxml.jackson.module : jackson-module-jsonschema : 2.18.2

Apache-2.0

com.fasterxml.woodstox : woodstox-core : 6.6.1

Apache-2.0

com.github.ben-manes.caffeine : caffeine : 2.9.3

Apache-2.0

com.github.ben-manes.caffeine : caffeine : 3.1.8

Apache-2.0

com.github.erosb : everit-json-schema : 1.14.3

Apache-2.0

com.github.fge : btf : 1.2

Apache-2.0

com.github.fge : msg-simple : 1.1

Apache-2.0

com.github.fge : uri-template : 0.9

Apache-2.0

com.github.java-json-tools : jackson-coreutils : 1.9

Apache-2.0

com.github.java-json-tools : json-schema-core : 1.2.10

Apache-2.0

com.github.java-json-tools : json-schema-validator : 2.2.10

Apache-2.0

com.google.code.gson : gson : 2.11.0

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.10.0

Apache-2.0

com.google.errorprone : error_prone_annotations : 2.36.0

Apache-2.0

com.google.guava : failureaccess : 1.0.2

Apache-2.0

com.google.guava : guava : 33.3.1-jre

Apache-2.0

com.google.guava : listenablefuture : 9999.0-empty-to-avoid-conflict-with-guava

Apache-2.0

com.google.j2objc : j2objc-annotations : 3.0.0

Apache-2.0

com.googlecode.libphonenumber : libphonenumber : 8.0.0

Apache-2.0

com.lmax : disruptor : 4.0.0

Apache-2.0

com.squareup.okhttp3 : okhttp : 4.12.0

Apache-2.0

com.squareup.okio : okio-jvm : 3.9.1

Apache-2.0

com.typesafe : config : 1.4.3

Apache-2.0

com.zaxxer : hikaricp-java7 : 2.4.13

Apache-2.0

commons-beanutils : commons-beanutils : 1.9.4

Apache-2.0

commons-cli : commons-cli : 1.9.0

Apache-2.0

commons-codec : commons-codec : 1.17.0

Apache-2.0

commons-codec : commons-codec : 1.17.1

Apache-2.0

commons-collections : commons-collections : 3.2.2

Apache-2.0

commons-digester : commons-digester : 2.1

Apache-2.0

commons-io : commons-io : 2.16.1

Apache-2.0

commons-io : commons-io : 2.18.0

Apache-2.0

commons-lang : commons-lang : 2.6

Apache-2.0

commons-net : commons-net : 3.11.1

Apache-2.0

commons-validator : commons-validator : 1.7

Apache-2.0

io.grpc : grpc-api : 1.68.2

Apache-2.0

io.grpc : grpc-context : 1.68.2

Apache-2.0

io.grpc : grpc-core : 1.68.2

Apache-2.0

io.micrometer : micrometer-commons : 1.14.1

Apache-2.0

io.micrometer : micrometer-observation : 1.14.1

Apache-2.0

io.netty : netty-buffer : 4.1.115.final

Apache-2.0

io.netty : netty-codec : 4.1.115.final

Apache-2.0

io.netty : netty-codec-dns : 4.1.115.final

Apache-2.0

io.netty : netty-codec-http : 4.1.115.final

Apache-2.0

io.netty : netty-codec-http2 : 4.1.115.final

Apache-2.0

io.netty : netty-codec-socks : 4.1.115.final

Apache-2.0

io.netty : netty-common : 4.1.115.final

Apache-2.0

io.netty : netty-handler : 4.1.115.final

Apache-2.0

io.netty : netty-handler-proxy : 4.1.115.final

Apache-2.0

io.netty : netty-resolver : 4.1.115.final

Apache-2.0

io.netty : netty-resolver-dns : 4.1.115.final

Apache-2.0

io.netty : netty-transport : 4.1.115.final

Apache-2.0

io.netty : netty-transport-classes-epoll : 4.1.115.final

Apache-2.0

io.netty : netty-transport-native-epoll : jar : linux-x​86_64​ : 4.1.115.final

Apache-2.0

io.netty : netty-transport-native-unix-common : 4.1.115.final

Apache-2.0

io.opentelemetry : opentelemetry-api : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-api-incubator : 1.44.1-alpha

Apache-2.0

io.opentelemetry : opentelemetry-context : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-exporter-common : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-exporter-logging : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-exporter-otlp : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-exporter-otlp-common : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-exporter-sender-okhttp : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-sdk : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-sdk-common : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-sdk-extension-autoconfigure-spi : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-sdk-logs : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-sdk-metrics : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-sdk-testing : 1.44.1

Apache-2.0

io.opentelemetry : opentelemetry-sdk-trace : 1.44.1

Apache-2.0

io.perfmark : perfmark-api : 0.27.0

Apache-2.0

io.projectreactor : reactor-core : 3.7.0

Apache-2.0

io.projectreactor.addons : reactor-extra : 3.5.2

Apache-2.0

io.projectreactor.netty : reactor-netty-core : 1.2.0

Apache-2.0

io.projectreactor.netty : reactor-netty-http : 1.2.0

Apache-2.0

io.qameta.allure : allure-java-commons : 2.29.1

Apache-2.0

io.qameta.allure : allure-junit4 : 2.29.1

Apache-2.0

io.qameta.allure : allure-model : 2.29.1

Apache-2.0

io.qameta.allure : allure-test-filter : 2.29.1

Apache-2.0

it.unimi.dsi : fastutil : 8.5.15

Apache-2.0

jakarta.inject : jakarta.inject-api : 1.0.5

Apache-2.0

javax.validation : validation-api : 1.1.0.final

Apache-2.0

joda-time : joda-time : 2.10.2

Apache-2.0

joda-time : joda-time : 2.13.0

Apache-2.0

net.bytebuddy : byte-buddy : 1.15.10

Apache-2.0

net.bytebuddy : byte-buddy-agent : 1.15.10

Apache-2.0

net.jodah : failsafe : 2.4.4

Apache-2.0

net.lingala.zip4j : zip4j : 2.11.3

Apache-2.0

org.apache.avro : avro : 1.11.4

Apache-2.0

org.apache.commons : commons-collections4 : 4.4

Apache-2.0

org.apache.commons : commons-compress : 1.26.2

Apache-2.0

org.apache.commons : commons-exec : 1.4.0

Apache-2.0

org.apache.commons : commons-lang3 : 3.14.0

Apache-2.0

org.apache.commons : commons-lang3 : 3.17.0

Apache-2.0

org.apache.commons : commons-pool2 : 2.12.0

Apache-2.0

org.apache.commons : commons-text : 1.12.0

Apache-2.0

org.apache.derby : derby : 10.16.1.1

Apache-2.0

org.apache.ftpserver : ftplet-api : 1.2.0

Apache-2.0

org.apache.ftpserver : ftpserver-core : 1.2.0

Apache-2.0

org.apache.groovy : groovy : 4.0.24

Apache-2.0

org.apache.httpcomponents : httpclient : 4.5.14

Apache-2.0

org.apache.httpcomponents : httpcore : 4.4.16

Apache-2.0

org.apache.logging.log4j : log4j-1.2-api : 2.24.2

Apache-2.0

org.apache.logging.log4j : log4j-api : 2.24.2

Apache-2.0

org.apache.logging.log4j : log4j-core : 2.24.2

Apache-2.0

org.apache.logging.log4j : log4j-slf4j2-impl : 2.24.2

Apache-2.0

org.apache.maven : maven-builder-support : 3.9.9

Apache-2.0

org.apache.maven : maven-model-builder : 3.9.9

Apache-2.0

org.apache.maven : maven-resolver-provider : 3.9.9

Apache-2.0

org.apache.maven : maven-settings : 3.9.9

Apache-2.0

org.apache.maven : maven-settings-builder : 3.9.9

Apache-2.0

org.apache.maven.resolver : maven-resolver-api : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-connector-basic : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-impl : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-named-locks : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-spi : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-supplier : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-file : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-http : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-transport-wagon : 1.9.18

Apache-2.0

org.apache.maven.resolver : maven-resolver-util : 1.9.18

Apache-2.0

org.apache.maven.shared : maven-invoker : 3.3.0

Apache-2.0

org.apache.maven.shared : maven-shared-utils : 3.4.2

Apache-2.0

org.apache.maven.wagon : wagon-http : 3.5.3

Apache-2.0

org.apache.maven.wagon : wagon-http-shared : 3.5.3

Apache-2.0

org.apache.maven.wagon : wagon-provider-api : 3.5.3

Apache-2.0

org.apache.mina : mina-core : 2.1.6

Apache-2.0

org.apache.sshd : sshd-osgi : 2.14.0

Apache-2.0

org.apache.sshd : sshd-scp : 2.14.0

Apache-2.0

org.apache.sshd : sshd-sftp : 2.14.0

Apache-2.0

org.apache.ws.xmlschema : xmlschema-core : 2.2.1

Apache-2.0

org.apache.xmlbeans : xmlbeans : 3.1.0

Apache-2.0

org.apache.xmlbeans : xmlbeans : 5.2.2

Apache-2.0

org.awaitility : awaitility : 4.2.2

Apache-2.0

org.codehaus.plexus : plexus-cipher : 2.0

Apache-2.0

org.codehaus.plexus : plexus-component-annotations : 2.2.0

Apache-2.0

org.codehaus.plexus : plexus-interpolation : 1.27

Apache-2.0

org.codehaus.plexus : plexus-sec-dispatcher : 2.0

Apache-2.0

org.codehaus.plexus : plexus-utils : 4.0.2

Apache-2.0

org.codehaus.plexus : plexus-xml : 3.0.1

Apache-2.0

org.jetbrains : annotations : 26.0.1

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib : 2.1.0

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk7 : 2.1.0

Apache-2.0

org.jetbrains.kotlin : kotlin-stdlib-jdk8 : 2.1.0

Apache-2.0

org.jheaps : jheaps : 0.14

Apache-2.0

org.objenesis : objenesis : 3.3

Apache-2.0

org.parboiled : parboiled_2.12 : 2.5.1

Apache-2.0

org.quartz-scheduler : quartz : 2.3.2

Apache-2.0

org.raml : raml-parser-2 : 1.0.44-15

Apache-2.0

org.raml : yagi : 1.0.44-15

Apache-2.0

org.reflections : reflections : 0.10.2

Apache-2.0

org.scala-lang : scala-library : 2.12.18

Apache-2.0

org.slf4j : jcl-over-slf4j : 2.0.16

Apache-2.0

org.springframework : spring-aop : 6.2.0

Apache-2.0

org.springframework : spring-beans : 6.2.0

Apache-2.0

org.springframework : spring-context : 6.2.0

Apache-2.0

org.springframework : spring-core : 6.2.0

Apache-2.0

org.springframework : spring-expression : 6.2.0

Apache-2.0

org.togglz : togglz-core : 4.4.0

Apache-2.0

org.vibur : vibur-object-pool : 25.0

Apache-2.0

org.yaml : snakeyaml : 2.3

BSD-2-Clause

org.codehaus.woodstox : stax2-api : 4.2.2

BSD-3-Clause

com.google.re2j : re2j : 1.6

BSD-3-Clause

com.google.re2j : re2j : 1.7

BSD-3-Clause

org.antlr : antlr-runtime : 3.5.3

BSD-3-Clause

org.hamcrest : hamcrest : 3.0

CDDL-1.1

org.glassfish.grizzly : grizzly-http : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-http-server : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-http-servlet : 2.3.34

CDDL-1.1

org.glassfish.grizzly : grizzly-websockets : 2.4.0-beta4

DOM4j-License

org.dom4j : dom4j : 2.1.4

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.1

EDL-1.0

com.sun.activation : jakarta.activation : 1.2.2

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.3

EDL-1.0

com.sun.mail : jakarta.mail : 1.6.7

EDL-1.0

com.sun.xml.bind : jaxb-impl : 2.3.9

EDL-1.0

jakarta.xml.bind : jakarta.xml.bind-api : 2.3.3

EPL-1.0

com.mchange : c3p0 : 0.10.1

EPL-1.0

com.mchange : mchange-commons-java : 0.3.1

EPL-1.0

junit : junit : 4.13.2

EPL-1.0

org.eclipse.sisu : org.eclipse.sisu.inject : 0.3.5

EPL-1.0

org.eclipse.sisu : org.eclipse.sisu.plexus : 0.3.5

EPL-2.0

jakarta.annotation : jakarta.annotation-api : 1.3.5

EPL-2.0

jakarta.jms : jakarta.jms-api : 2.0.3

EPL-2.0

jakarta.transaction : jakarta.transaction-api : 1.3.3

EPL-2.0

org.aspectj : aspectjweaver : 1.9.22.1

EPL-2.0

org.glassfish : jakarta.json : 1.1.6

EPL-2.0

org.jgrapht : jgrapht-core : 1.5.2

ICU または Unicode

org.graalvm.shadowed : icu4j : 24.1.1

LGPL-2.1

com.github.spotbugs : spotbugs-annotations : 4.7.3

MIT

com.vdurmont : semver4j : 3.1.0

MIT

net.sf.jopt-simple : jopt-simple : 5.0.3

MIT

org.apfloat : apfloat : 1.14.0

MIT

org.apfloat : apfloat : 1.14.0

MIT

org.checkerframework : checker-qual : 3.19.0

MIT

org.checkerframework : checker-qual : 3.48.3

MIT

org.graalvm.js : js : 23.0.6

MIT

org.graalvm.js js 1.0.0-rc15

MIT

org.jsoup : jsoup : 1.18.3

MIT

org.mockito : mockito-core : 4.11.0

MIT

org.slf4j : jul-to-slf4j : 2.0.16

MIT

org.slf4j : slf4j-api : 2.0.16

MIT

superstartup-closure-compiler 0.1.1

MIT

tanukisoft : wrapper : 3.2.3

MIT-0

org.reactivestreams : reactive-streams : 1.0.4

MPL-1.1

com.googlecode.juniversalchardet : juniversalchardet : 1.0.3

MPL-2.0

org.mozilla : rhino : 1.7.15

Public Domain

org.json : json : 20231013

Public Domain

org.json : json : 20240303

Unicode-3.0

com.ibm.icu : icu4j : 76.1

UPL-1.0

org.graalvm.js : js-scriptengine : 24.1.1

UPL-1.0

org.graalvm.polyglot : polyglot : 24.1.1

UPL-1.0

org.graalvm.regex : regex : 24.1.1

UPL-1.0

org.graalvm.sdk : collections : 24.1.1

UPL-1.0

org.graalvm.sdk : graal-sdk : 24.1.1

UPL-1.0

org.graalvm.sdk : graal-sdk : 24.1.1

UPL-1.0

org.graalvm.sdk : graal-sdk : 24.1.1

UPL-1.0

org.graalvm.sdk : nativeimage : 24.1.1

UPL-1.0

org.graalvm.sdk : word : 24.1.1

UPL-1.0

org.graalvm.truffle : truffle-api : 24.1.1
## [](#ライセンス情報)ライセンス情報 各ライセンス種別に関する情報は次の場所にあります。 - `http://aopalliance.sourceforge.net/`​ (AOP) - `https://opensource.org/licenses/APACHE-2.0`​ (Apache-2.0) - `https://en.wikipedia.org/wiki/BSD_licenses`​ (BSD) - `https://opensource.org/licenses/BSD-2-Clause`​ (BSD-2-Clause) - `https://opensource.org/licenses/BSD-3-Clause`​ (BSD-3-Clause) - `https://spdx.org/licenses/CDDL-1.1.html`​ (CDDL-1.1) - `https://opensource.org/licenses/CPAL-1.0`​ (CPAL-1.0) - `https://opensource.org/licenses/CPL-1.0`​ (CPL-1.0) - `https://opensource.org/licenses/EPL-2.0`​ (EPL-2.0) - `http://source.icu-project.org/repos/icu/icu/trunk/LICENSE`​ (ICU) - `https://github.com/stleary/JSON-java/blob/master/LICENSE`​ (JSON) - `https://opensource.org/licenses/LGPL-2.1`​ (LGPL-2.1) - `https://opensource.org/licenses/MIT`​ (MIT) - `https://opensource.org/licenses/MPL-1.1`​ (MPL-1.1) - `https://opensource.org/licenses/MPL-2.0`​ (MPL-2.0) # Mule のダウンロード、インストール、アップグレード Mule をダウンロードしてインストールする前に、サポートされている JDK がインストールされていることを確認してください。 この例では、Mule 4.3 に推奨の AdoptOpenJDK 8 を使用しています。 ```console $ java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b03) OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b03, mixed mode) ``` ## [](#mule-のダウンロード)Mule のダウンロード 1. Mule 4 のバイナリファイルを次のリンクからダウンロードして展開します。 [https://www.mulesoft.com/lp/dl/mule-esb-enterprise](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) 2. 環境変数の ​`MULE_HOME`​ を、ファイルを展開したフォルダー内の ​`mule`​ ディレクトリに設定します。 バージョン 4.3.0 を ​`Downloads`​ ディレクトリに展開した場合の例を示します。 - Windows 環境: ```console $ env:MULE_HOME="C:\Downloads\mule-enterprise-standalone-4.3.0" ``` - Linux/Unix 環境: ```console $ export MULE_HOME=~/Downloads/mule-enterprise-standalone-4.3.0 ``` `MULE_HOME`​ 設定を永続化するための手順はオペレーティングシステムによって異なります。 ## [](#mule-の実行)Mule の実行 次のコマンドを実行することで、お使いの環境で Mule がエラーなく動作するかどうかを確認できます。 - Windows 環境: ```powershell %MULE_HOME%\bin\mule.bat ``` - Linux/Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#mule-バージョンの更新アップグレード移行)Mule バージョンの更新、アップグレード、移行 MuleSoft では Mule の新しいメジャーリリース、マイナーリリース、パッチリリースバージョンだけでなく、Mule のパッチリリースへの月 1 回の更新がリリースされます。この更新には、最新のバグ修正とセキュリティの機能強化が含まれています。 - Mule のパッチバージョンを更新するには、​[「Update Patches to Mule Runtime Engine (Mule Runtime Engine のパッチの更新)」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/patching-mule-versions)​を参照してください。 - Mule 4 の新しいバージョンにアップグレードするには、​[「Upgrading Mule Runtime Engine (Versions 4.x to 4.n) (Mule Runtime Engine のアップグレード (バージョン 4.x から 4.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions)​を参照してください。 - Mule 3 の新しいバージョンにアップグレードするには、​[「Upgrading Mule Runtime Engine (Versions 3.x to 3.n) (Mule Runtime Engine のアップグレード (バージョン 3.x から 3.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-versions)​を参照してください。 - Mule 3 から Mule 4 に移行するには、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-intro)​を参照してください。 ## [](#関連情報)関連情報 - [Mule の開始と停止](https://docs.mulesoft.com/jp/mule-runtime/4.3/starting-and-stopping-mule-esb) - [Anypoint Studio 7.0 のインストール](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [Mule 4 の新機能](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-runtime-updates) # Mule のダウンロード、インストール、設定、アップグレード Mule をダウンロードしてインストールする前に、サポートされている JDK がインストールされていることを確認してください。 この例では、Mule 4.4 に推奨の [Eclipse Temurin 8](https://adoptium.net/temurin/releases/?version=8)​ を使用しています。 ```console $ java -version openjdk version "1.8.0_352" OpenJDK Runtime Environment (Temurin)(build 1.8.0_352-b08) OpenJDK 64-Bit Server VM (Temurin)(build 25.352-b08, mixed mode) ``` AdoptOpenJDK は Eclipse Foundation に移行され、その名前が Eclipse Adoptium プロジェクトに変更されました。JDK の名前は Temurin に変更されました。 ## [](#mule-のダウンロード)Mule のダウンロード 1. Mule 4 のバイナリファイルを次のリンクからダウンロードして展開します。 [https://www.mulesoft.com/lp/dl/mule-esb-enterprise](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) 2. 環境変数の ​`MULE_HOME`​ を、ファイルを展開したフォルダー内の ​`mule`​ ディレクトリに設定します。 バージョン 4.4.0 を ​`Downloads`​ ディレクトリに展開した場合の例を示します。 - Windows 環境: ```console $ env:MULE_HOME="C:\Downloads\mule-enterprise-standalone-4.4.0" ``` - Linux または Unix 環境: ```console $ export MULE_HOME=~/Downloads/mule-enterprise-standalone-4.4.0 ``` `MULE_HOME`​ 設定を永続化するための手順はオペレーティングシステムによって異なります。 ### [](#mule-アプリケーションのテスト)Mule アプリケーションのテスト Mule をダウンロードしたら、次のコマンドを実行してシステムでエラーなく動作することをテストして確認します。 - Windows 環境: ```powershell %MULE_HOME%\bin\mule.bat ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#mule-のインストール)Mule のインストール 対応するコマンドを実行して、Mule を Windows サービスか、Linux または Unix デーモンとしてインストールできます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat install ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule install ``` ## [](#wrapper-conf-ファイルのプロパティの設定)wrapper.conf ファイルのプロパティの設定 Mule を Windows サービスとしてインストールしたら、​`wrapper.additional.conf`​ ファイルで新しいプロパティを宣言することで ​`wrapper.conf`​ ファイルに定義されているプロパティを上書きできます。 使用している Mule エディションによって設定手順が異なります。 - Mule Community Edition 1. 新しいプロパティを追加したら、Windows サービスを再インストールまたは再起動します。 2. プロパティを追加し、そのプロパティを上書きできないようにそのインデックスが ​`wrapper-additional.conf`​ ファイルの最大のインデックスよりも大きいことを確認します。 たとえば、​`wrapper-additional.conf`​ に次のプロパティがあるとします。 `wrapper.java.additional.n=-Dproperty=value` `n`​ が最大のインデックスである場合、プロパティを ​`wrapper.conf`​ ファイルに追加し、インデックスを次のように増やします。 `wrapper.java.additional.n+1=-DyourProperty=valueOfYourProperty` - Mule Enterprise Edition Mule をサービスとしてインストールしたら、次のコマンドライン引数を使用して最大 20 個の追加プロパティを設定します。 `-additionalJavaProperties=numberOfExtraProperties` ## [](#cpu-アフィニティの設定)CPU アフィニティの設定 多くのオペレーティングシステムで、プロセスを 1 つ以上の中央処理装置 (CPU) にバインドしてプロセスが割り当てられた CPU でのみ実行されるようにするメカニズムが提供されています。使用する環境に CPU アフィニティを設定して Mule を非仮想マルチコアサーバーで実行し、サブスクリプションに含まれるコア数に準拠することができます。 ### [](#cpu-アフィニティ使用時の考慮事項)CPU アフィニティ使用時の考慮事項 - CPU にはコアのグループがあり、キャッシュを共有してスレッド通信と移行のパフォーマンスを改善しています。こうしたパフォーマンスの問題を回避するには、この機能をセットアップする前にどのコアがこのキャッシュを共有しているかインフラストラクチャチームに確認します。 - CPU アフィニティ設定を妨げる可能性がある既存のリソース割り当てポリシーがないことをインフラストラクチャチームに確認します。 - CPU アフィニティで設定する予定のコア数が MuleSoft サブスクリプションプランに含まれるコア数を超えていないことを確認します。 ## [](#mule-サービスまたはデーモンの削除)Mule サービスまたはデーモンの削除 対応するコマンドを実行して、Mule を Windows サービスまたは Unix デーモンとして削除できます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat remove ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule remove MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Detected Mac OSX: Mule Enterprise Edition is not running. Removing Mule Enterprise Edition daemon... ``` ## [](#anypoint-monitoring-のインストール)Anypoint Monitoring のインストール オンプレミスランタイムインスタンスのクラウド管理対応バージョン用の ​[Anypoint Monitoring をインストール](https://docs.mulesoft.com/jp/monitoring/am-installing)​して、そのサーバー上で動作するアプリケーションを監視できます。 ## [](#mule-バージョンの更新アップグレード移行)Mule バージョンの更新、アップグレード、移行 MuleSoft では Mule の新しいメジャーリリース、マイナーリリース、パッチリリースバージョンだけでなく、Mule のパッチリリースへの月 1 回の更新がリリースされます。この更新には、最新のバグ修正とセキュリティの機能強化が含まれています。 - Mule のパッチバージョンを更新するには、​[「Update Patches to Mule Runtime Engine (Mule Runtime Engine のパッチの更新)」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/patching-mule-versions)​を参照してください。 - Mule 4 の新しいバージョンにアップグレードするには、​[「Upgrading Mule Runtime Engine (Versions 4.x to 4.n) (Mule Runtime Engine のアップグレード (バージョン 4.x から 4.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions)​を参照してください。 - Mule 3 の新しいバージョンにアップグレードするには、​[「Upgrading Mule Runtime Engine (Versions 3.x to 3.n) (Mule Runtime Engine のアップグレード (バージョン 3.x から 3.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-versions)​を参照してください。 - Mule 3 から Mule 4 に移行するには、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-intro)​を参照してください。 ## [](#関連情報)関連情報 - [Mule の開始と停止](https://docs.mulesoft.com/jp/mule-runtime/4.4/starting-and-stopping-mule-esb) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Studio 7.0 のインストール](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [Mule 4 の新機能](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-runtime-updates) # Mule のダウンロード、インストール、設定、アップグレード Mule をダウンロードしてインストールする前に、サポートされている JDK がインストールされていることを確認してください。 この例では、Mule 4.4 に推奨の [Eclipse Temurin 8](https://adoptium.net/temurin/releases/?version=8)​ を使用しています。 ```console $ java -version openjdk version "1.8.0_352" OpenJDK Runtime Environment (Temurin)(build 1.8.0_352-b08) OpenJDK 64-Bit Server VM (Temurin)(build 25.352-b08, mixed mode) ``` AdoptOpenJDK は Eclipse Foundation に移行され、その名前が Eclipse Adoptium プロジェクトに変更されました。JDK の名前は Temurin に変更されました。 ## [](#mule-のダウンロード)Mule のダウンロード 1. Mule 4 のバイナリファイルを次のリンクからダウンロードして展開します。 [https://www.mulesoft.com/lp/dl/mule-esb-enterprise](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) 2. 環境変数の ​`MULE_HOME`​ を、ファイルを展開したフォルダー内の ​`mule`​ ディレクトリに設定します。 バージョン 4.4.0 を ​`Downloads`​ ディレクトリに展開した場合の例を示します。 - Windows 環境: ```console $ env:MULE_HOME="C:\Downloads\mule-enterprise-standalone-4.4.0" ``` - Linux または Unix 環境: ```console $ export MULE_HOME=~/Downloads/mule-enterprise-standalone-4.4.0 ``` `MULE_HOME`​ 設定を永続化するための手順はオペレーティングシステムによって異なります。 ### [](#mule-アプリケーションのテスト)Mule アプリケーションのテスト Mule をダウンロードしたら、次のコマンドを実行してシステムでエラーなく動作することをテストして確認します。 - Windows 環境: ```powershell %MULE_HOME%\bin\mule.bat ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#mule-のインストール)Mule のインストール 対応するコマンドを実行して、Mule を Windows サービスか、Linux または Unix デーモンとしてインストールできます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat install ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule install ``` ## [](#wrapper-conf-ファイルのプロパティの設定)wrapper.conf ファイルのプロパティの設定 Mule を Windows サービスとしてインストールしたら、​`wrapper.additional.conf`​ ファイルで新しいプロパティを宣言することで ​`wrapper.conf`​ ファイルに定義されているプロパティを上書きできます。 使用している Mule エディションによって設定手順が異なります。 - Mule Community Edition 1. 新しいプロパティを追加したら、Windows サービスを再インストールまたは再起動します。 2. プロパティを追加し、そのプロパティを上書きできないようにそのインデックスが ​`wrapper-additional.conf`​ ファイルの最大のインデックスよりも大きいことを確認します。 たとえば、​`wrapper-additional.conf`​ に次のプロパティがあるとします。 `wrapper.java.additional.n=-Dproperty=value` `n`​ が最大のインデックスである場合、プロパティを ​`wrapper.conf`​ ファイルに追加し、インデックスを次のように増やします。 `wrapper.java.additional.n+1=-DyourProperty=valueOfYourProperty` - Mule Enterprise Edition Mule をサービスとしてインストールしたら、次のコマンドライン引数を使用して最大 20 個の追加プロパティを設定します。 `-additionalJavaProperties=numberOfExtraProperties` ## [](#cpu-アフィニティの設定)CPU アフィニティの設定 多くのオペレーティングシステムで、プロセスを 1 つ以上の中央処理装置 (CPU) にバインドしてプロセスが割り当てられた CPU でのみ実行されるようにするメカニズムが提供されています。使用する環境に CPU アフィニティを設定して Mule を非仮想マルチコアサーバーで実行し、サブスクリプションに含まれるコア数に準拠することができます。 ### [](#cpu-アフィニティ使用時の考慮事項)CPU アフィニティ使用時の考慮事項 - CPU にはコアのグループがあり、キャッシュを共有してスレッド通信と移行のパフォーマンスを改善しています。こうしたパフォーマンスの問題を回避するには、この機能をセットアップする前にどのコアがこのキャッシュを共有しているかインフラストラクチャチームに確認します。 - CPU アフィニティ設定を妨げる可能性がある既存のリソース割り当てポリシーがないことをインフラストラクチャチームに確認します。 - CPU アフィニティで設定する予定のコア数が MuleSoft サブスクリプションプランに含まれるコア数を超えていないことを確認します。 ## [](#mule-サービスまたはデーモンの削除)Mule サービスまたはデーモンの削除 対応するコマンドを実行して、Mule を Windows サービスまたは Unix デーモンとして削除できます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat remove ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule remove MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Detected Mac OSX: Mule Enterprise Edition is not running. Removing Mule Enterprise Edition daemon... ``` ## [](#anypoint-monitoring-のインストール)Anypoint Monitoring のインストール オンプレミスランタイムインスタンスのクラウド管理対応バージョン用の ​[Anypoint Monitoring をインストール](https://docs.mulesoft.com/jp/monitoring/am-installing)​して、そのサーバー上で動作するアプリケーションを監視できます。 ## [](#mule-バージョンの更新アップグレード移行)Mule バージョンの更新、アップグレード、移行 MuleSoft では Mule の新しいメジャーリリース、マイナーリリース、パッチリリースバージョンだけでなく、Mule のパッチリリースへの月 1 回の更新がリリースされます。この更新には、最新のバグ修正とセキュリティの機能強化が含まれています。 - Mule のパッチバージョンを更新するには、​[「Update Patches to Mule Runtime Engine (Mule Runtime Engine のパッチの更新)」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/patching-mule-versions)​を参照してください。 - Mule 4 の新しいバージョンにアップグレードするには、​[「Upgrading Mule Runtime Engine (Versions 4.x to 4.n) (Mule Runtime Engine のアップグレード (バージョン 4.x から 4.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions)​を参照してください。 - Mule 3 の新しいバージョンにアップグレードするには、​[「Upgrading Mule Runtime Engine (Versions 3.x to 3.n) (Mule Runtime Engine のアップグレード (バージョン 3.x から 3.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-versions)​を参照してください。 - Mule 3 から Mule 4 に移行するには、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-intro)​を参照してください。 ## [](#関連情報)関連情報 - [Mule の開始と停止](https://docs.mulesoft.com/jp/mule-runtime/4.5/starting-and-stopping-mule-esb) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Studio 7.0 のインストール](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [Mule 4 の新機能](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-runtime-updates) # Mule のダウンロード、インストール、設定、アップグレード Mule をダウンロードしてインストールする前に、サポートされている JDK がインストールされていることを確認してください。 この例では、Mule 4.4 に推奨の [Eclipse Temurin 8](https://adoptium.net/temurin/releases/?version=8)​ を使用しています。 ```console $ java -version openjdk version "1.8.0_352" OpenJDK Runtime Environment (Temurin)(build 1.8.0_352-b08) OpenJDK 64-Bit Server VM (Temurin)(build 25.352-b08, mixed mode) ``` AdoptOpenJDK は Eclipse Foundation に移行され、その名前が Eclipse Adoptium プロジェクトに変更されました。JDK の名前は Temurin に変更されました。 ## [](#mule-のダウンロード)Mule のダウンロード 1. Mule 4 のバイナリファイルを次のリンクからダウンロードして展開します。 [https://www.mulesoft.com/lp/dl/mule-esb-enterprise](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) 2. 環境変数の ​`MULE_HOME`​ を、ファイルを展開したフォルダー内の ​`mule`​ ディレクトリに設定します。 バージョン 4.4.0 を ​`Downloads`​ ディレクトリに展開した場合の例を示します。 - Windows 環境: ```console $ env:MULE_HOME="C:\Downloads\mule-enterprise-standalone-4.4.0" ``` - Linux または Unix 環境: ```console $ export MULE_HOME=~/Downloads/mule-enterprise-standalone-4.4.0 ``` `MULE_HOME`​ 設定を永続化するための手順はオペレーティングシステムによって異なります。 ### [](#mule-アプリケーションのテスト)Mule アプリケーションのテスト Mule をダウンロードしたら、次のコマンドを実行してシステムでエラーなく動作することをテストして確認します。 - Windows 環境: ```powershell %MULE_HOME%\bin\mule.bat ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#mule-のインストール)Mule のインストール 対応するコマンドを実行して、Mule を Windows サービスか、Linux または Unix デーモンとしてインストールできます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat install ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule install ``` ## [](#wrapper-conf-ファイルのプロパティの設定)wrapper.conf ファイルのプロパティの設定 Mule をサービスまたはデーモンとしてインストールしたら、​`wrapper.conf`​ ファイルで定義されたプロパティを変更できます。 設定ファイルで実行できる内容についての詳細は、 [「Configuration Property Overview (設定プロパティの概要)」](https://wrapper.tanukisoftware.com/doc/english/properties.html)​を参照してください。 `wrapper.conf`​ ファイルを変更したら、Mule インスタンスを再起動して、変更を有効にします。

新しいプロパティを追加するときは、他のプロパティで同じ連番がまだ使用されていないことを確認します。 wrapper-additional.conf​ ファイルは、Mule によって自動的に生成されるため変更しないでください。 wrapper-additional.conf​ のプロパティシーケンスと追加したプロパティシーケンスが競合しないようにするには、Mule を再起動するのではなく停止してから開始します。これにより、​wrapper-additional.conf​ が再生成され、新しいプロパティが取り込まれます。または、​-additionalJavaProperties=numberOfExtraProperties​ を使用して、​wrapper.conf​ の最後のシーケンスと ​wrapper-additional.conf​ の最初のシーケンス間にギャップを作ることもできます (Mule Enterprise Edition のみ)。
## [](#cpu-アフィニティの設定)CPU アフィニティの設定 多くのオペレーティングシステムで、プロセスを 1 つ以上の中央処理装置 (CPU) にバインドしてプロセスが割り当てられた CPU でのみ実行されるようにするメカニズムが提供されています。使用する環境に CPU アフィニティを設定して Mule を非仮想マルチコアサーバーで実行し、サブスクリプションに含まれるコア数に準拠することができます。 ### [](#cpu-アフィニティ使用時の考慮事項)CPU アフィニティ使用時の考慮事項 - CPU にはコアのグループがあり、キャッシュを共有してスレッド通信と移行のパフォーマンスを改善しています。こうしたパフォーマンスの問題を回避するには、この機能をセットアップする前にどのコアがこのキャッシュを共有しているかインフラストラクチャチームに確認します。 - CPU アフィニティ設定を妨げる可能性がある既存のリソース割り当てポリシーがないことをインフラストラクチャチームに確認します。 - CPU アフィニティで設定する予定のコア数が MuleSoft サブスクリプションプランに含まれるコア数を超えていないことを確認します。 ## [](#mule-サービスまたはデーモンの削除)Mule サービスまたはデーモンの削除 対応するコマンドを実行して、Mule を Windows サービスまたは Unix デーモンとして削除できます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat remove ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule remove MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Detected Mac OSX: Mule Enterprise Edition is not running. Removing Mule Enterprise Edition daemon... ``` ## [](#anypoint-monitoring-のインストール)Anypoint Monitoring のインストール オンプレミスランタイムインスタンスのクラウド管理対応バージョン用の ​[Anypoint Monitoring をインストール](https://docs.mulesoft.com/jp/monitoring/am-installing)​して、そのサーバー上で動作するアプリケーションを監視できます。 ## [](#mule-バージョンの更新アップグレード移行)Mule バージョンの更新、アップグレード、移行 Unresolved include directive in modules/ROOT/pages/runtime-installation-task.adoc - include::mule-runtime::partial$upgrade-update-migrate-mule.adoc\[\] ## [](#関連情報)関連情報 - [Mule の開始と停止](https://docs.mulesoft.com/jp/mule-runtime/4.6/starting-and-stopping-mule-esb) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Studio 7.0 のインストール](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [Mule 4 の新機能](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-runtime-updates) # Mule のダウンロード、インストール、設定、アップグレード Mule をダウンロードしてインストールする前に、サポートされている JDK がインストールされていることを確認してください。 この例では、Mule 4.4 に推奨の [Eclipse Temurin 8](https://adoptium.net/temurin/releases/?version=8)​ を使用しています。 ```console $ java -version openjdk version "1.8.0_352" OpenJDK Runtime Environment (Temurin)(build 1.8.0_352-b08) OpenJDK 64-Bit Server VM (Temurin)(build 25.352-b08, mixed mode) ``` AdoptOpenJDK は Eclipse Foundation に移行され、その名前が Eclipse Adoptium プロジェクトに変更されました。JDK の名前は Temurin に変更されました。 ## [](#mule-のダウンロード)Mule のダウンロード 1. Mule 4 のバイナリファイルを次のリンクからダウンロードして展開します。 [https://www.mulesoft.com/lp/dl/mule-esb-enterprise](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) 2. 環境変数の ​`MULE_HOME`​ を、ファイルを展開したフォルダー内の ​`mule`​ ディレクトリに設定します。 バージョン 4.4.0 を ​`Downloads`​ ディレクトリに展開した場合の例を示します。 - Windows 環境: ```console $ env:MULE_HOME="C:\Downloads\mule-enterprise-standalone-4.4.0" ``` - Linux または Unix 環境: ```console $ export MULE_HOME=~/Downloads/mule-enterprise-standalone-4.4.0 ``` `MULE_HOME`​ 設定を永続化するための手順はオペレーティングシステムによって異なります。 ### [](#mule-アプリケーションのテスト)Mule アプリケーションのテスト Mule をダウンロードしたら、次のコマンドを実行してシステムでエラーなく動作することをテストして確認します。 - Windows 環境: ```powershell %MULE_HOME%\bin\mule.bat ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#mule-のインストール)Mule のインストール 対応するコマンドを実行して、Mule を Windows サービスか、Linux または Unix デーモンとしてインストールできます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat install ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule install ``` ## [](#wrapper-conf-ファイルのプロパティの設定)wrapper.conf ファイルのプロパティの設定 Mule をサービスまたはデーモンとしてインストールしたら、​`wrapper.conf`​ ファイルで定義されたプロパティを変更できます。 設定ファイルで実行できる内容についての詳細は、 [「Configuration Property Overview (設定プロパティの概要)」](https://wrapper.tanukisoftware.com/doc/english/properties.html)​を参照してください。 `wrapper.conf`​ ファイルを変更したら、Mule インスタンスを再起動して、変更を有効にします。

新しいプロパティを追加するときは、他のプロパティで同じ連番がまだ使用されていないことを確認します。

wrapper-additional.conf​ ファイルは、Mule によって自動的に生成されるため変更しないでください。

wrapper-additional.conf​ のプロパティシーケンスと追加したプロパティシーケンスが競合しないようにするには、Mule を再起動するのではなく停止してから開始します。これにより、​wrapper-additional.conf​ が再生成され、新しいプロパティが取り込まれます。または、​-additionalJavaProperties=numberOfExtraProperties​ を使用して、​wrapper.conf​ の最後のシーケンスと ​wrapper-additional.conf​ の最初のシーケンス間にギャップを作ることもできます (Mule Enterprise Edition のみ)。
## [](#cpu-アフィニティの設定)CPU アフィニティの設定 多くのオペレーティングシステムで、プロセスを 1 つ以上の中央処理装置 (CPU) にバインドしてプロセスが割り当てられた CPU でのみ実行されるようにするメカニズムが提供されています。使用する環境に CPU アフィニティを設定して Mule を非仮想マルチコアサーバーで実行し、サブスクリプションに含まれるコア数に準拠することができます。 ### [](#cpu-アフィニティ使用時の考慮事項)CPU アフィニティ使用時の考慮事項 - CPU にはコアのグループがあり、キャッシュを共有してスレッド通信と移行のパフォーマンスを改善しています。こうしたパフォーマンスの問題を回避するには、この機能をセットアップする前にどのコアがこのキャッシュを共有しているかインフラストラクチャチームに確認します。 - CPU アフィニティ設定を妨げる可能性がある既存のリソース割り当てポリシーがないことをインフラストラクチャチームに確認します。 - CPU アフィニティで設定する予定のコア数が MuleSoft サブスクリプションプランに含まれるコア数を超えていないことを確認します。 ## [](#mule-サービスまたはデーモンの削除)Mule サービスまたはデーモンの削除 対応するコマンドを実行して、Mule を Windows サービスまたは Unix デーモンとして削除できます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat remove ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule remove MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Detected Mac OSX: Mule Enterprise Edition is not running. Removing Mule Enterprise Edition daemon... ``` ## [](#anypoint-monitoring-のインストール)Anypoint Monitoring のインストール オンプレミスランタイムインスタンスのクラウド管理対応バージョン用の ​[Anypoint Monitoring をインストール](https://docs.mulesoft.com/jp/monitoring/am-installing)​して、そのサーバー上で動作するアプリケーションを監視できます。 ## [](#mule-バージョンの更新アップグレード移行)Mule バージョンの更新、アップグレード、移行 Unresolved include directive in modules/ROOT/pages/runtime-installation-task.adoc - include::mule-runtime::partial$upgrade-update-migrate-mule.adoc\[\] ## [](#関連情報)関連情報 - [Mule の開始と停止](https://docs.mulesoft.com/jp/mule-runtime/4.7/starting-and-stopping-mule-esb) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Studio 7.0 のインストール](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [Mule 4 の新機能](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-runtime-updates) # Mule のダウンロード、インストール、設定、アップグレード Mule をダウンロードしてインストールする前に、サポートされている JDK がインストールされていることを確認してください。 この例では、Mule 4.4 に推奨の [Eclipse Temurin 8](https://adoptium.net/temurin/releases/?version=8)​ を使用しています。 ```console $ java -version openjdk version "1.8.0_352" OpenJDK Runtime Environment (Temurin)(build 1.8.0_352-b08) OpenJDK 64-Bit Server VM (Temurin)(build 25.352-b08, mixed mode) ``` AdoptOpenJDK は Eclipse Foundation に移行され、その名前が Eclipse Adoptium プロジェクトに変更されました。JDK の名前は Temurin に変更されました。 ## [](#mule-のダウンロード)Mule のダウンロード 1. Mule 4 のバイナリファイルを次のリンクからダウンロードして展開します。 [https://www.mulesoft.com/lp/dl/mule-esb-enterprise](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) 2. 環境変数の ​`MULE_HOME`​ を、ファイルを展開したフォルダー内の ​`mule`​ ディレクトリに設定します。 バージョン 4.4.0 を ​`Downloads`​ ディレクトリに展開した場合の例を示します。 - Windows 環境: ```console $ env:MULE_HOME="C:\Downloads\mule-enterprise-standalone-4.4.0" ``` - Linux または Unix 環境: ```console $ export MULE_HOME=~/Downloads/mule-enterprise-standalone-4.4.0 ``` `MULE_HOME`​ 設定を永続化するための手順はオペレーティングシステムによって異なります。 ### [](#mule-アプリケーションのテスト)Mule アプリケーションのテスト Mule をダウンロードしたら、次のコマンドを実行してシステムでエラーなく動作することをテストして確認します。 - Windows 環境: ```powershell %MULE_HOME%\bin\mule.bat ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#mule-のインストール)Mule のインストール 対応するコマンドを実行して、Mule を Windows サービスか、Linux または Unix デーモンとしてインストールできます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat install ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule install ``` ## [](#wrapper-conf-ファイルのプロパティの設定)wrapper.conf ファイルのプロパティの設定 Mule をサービスまたはデーモンとしてインストールしたら、​`wrapper.conf`​ ファイルで定義されたプロパティを変更できます。 設定ファイルで実行できる内容についての詳細は、 [「Configuration Property Overview (設定プロパティの概要)」](https://wrapper.tanukisoftware.com/doc/english/properties.html)​を参照してください。 `wrapper.conf`​ ファイルを変更したら、Mule インスタンスを再起動して、変更を有効にします。

新しいプロパティを追加するときは、他のプロパティで同じ連番がまだ使用されていないことを確認します。 wrapper-additional.conf​ ファイルは、Mule によって自動的に生成されるため変更しないでください。 wrapper-additional.conf​ のプロパティシーケンスと追加したプロパティシーケンスが競合しないようにするには、Mule を再起動するのではなく停止してから開始します。これにより、​wrapper-additional.conf​ が再生成され、新しいプロパティが取り込まれます。または、​-additionalJavaProperties=numberOfExtraProperties​ を使用して、​wrapper.conf​ の最後のシーケンスと ​wrapper-additional.conf​ の最初のシーケンス間にギャップを作ることもできます (Mule Enterprise Edition のみ)。
## [](#cpu-アフィニティの設定)CPU アフィニティの設定 多くのオペレーティングシステムで、プロセスを 1 つ以上の中央処理装置 (CPU) にバインドしてプロセスが割り当てられた CPU でのみ実行されるようにするメカニズムが提供されています。使用する環境に CPU アフィニティを設定して Mule を非仮想マルチコアサーバーで実行し、サブスクリプションに含まれるコア数に準拠することができます。 ### [](#cpu-アフィニティ使用時の考慮事項)CPU アフィニティ使用時の考慮事項 - CPU にはコアのグループがあり、キャッシュを共有してスレッド通信と移行のパフォーマンスを改善しています。こうしたパフォーマンスの問題を回避するには、この機能をセットアップする前にどのコアがこのキャッシュを共有しているかインフラストラクチャチームに確認します。 - CPU アフィニティ設定を妨げる可能性がある既存のリソース割り当てポリシーがないことをインフラストラクチャチームに確認します。 - CPU アフィニティで設定する予定のコア数が MuleSoft サブスクリプションプランに含まれるコア数を超えていないことを確認します。 ## [](#mule-サービスまたはデーモンの削除)Mule サービスまたはデーモンの削除 対応するコマンドを実行して、Mule を Windows サービスまたは Unix デーモンとして削除できます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat remove ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule remove MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Detected Mac OSX: Mule Enterprise Edition is not running. Removing Mule Enterprise Edition daemon... ``` ## [](#anypoint-monitoring-のインストール)Anypoint Monitoring のインストール オンプレミスランタイムインスタンスのクラウド管理対応バージョン用の ​[Anypoint Monitoring をインストール](https://docs.mulesoft.com/jp/monitoring/am-installing)​して、そのサーバー上で動作するアプリケーションを監視できます。 ## [](#mule-バージョンの更新アップグレード移行)Mule バージョンの更新、アップグレード、移行 MuleSoft では Mule の新しいメジャーリリース、マイナーリリース、パッチリリースバージョンだけでなく、Mule のパッチリリースへの月 1 回の更新がリリースされます。この更新には、最新のバグ修正とセキュリティの機能強化が含まれています。 - Mule のパッチバージョンを更新するには、​[「Update Patches to Mule Runtime Engine (Mule Runtime Engine のパッチの更新)」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/patching-mule-versions)​を参照してください。 - Mule 4 の新しいバージョンにアップグレードするには、​[「Upgrading Mule Runtime Engine (Versions 4.x to 4.n) (Mule Runtime Engine のアップグレード (バージョン 4.x から 4.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions)​を参照してください。 - Mule 3 の新しいバージョンにアップグレードするには、​[「Upgrading Mule Runtime Engine (Versions 3.x to 3.n) (Mule Runtime Engine のアップグレード (バージョン 3.x から 3.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-versions)​を参照してください。 - Mule 3 から Mule 4 に移行するには、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-intro)​を参照してください。 ## [](#関連情報)関連情報 - [Mule の開始と停止](https://docs.mulesoft.com/jp/mule-runtime/4.8/starting-and-stopping-mule-esb) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Studio 7.0 のインストール](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [Mule 4 の新機能](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-runtime-updates) # Mule のダウンロード、インストール、設定、アップグレード Mule をダウンロードしてインストールする前に、​[サポートされている JDK](https://docs.mulesoft.com/jp/general/java-support#mule-runtime-java-support)​ がインストールされていることを確認してください。 この例では、Mule 4.9 に推奨の [Eclipse Temurin 17](https://adoptium.net/temurin/releases/?version=17)​ を使用しています。 ```console $ java -version openjdk version "17.0.13" 2024-10-15 OpenJDK Runtime Environment Temurin-17.0.13+11 (build 17.0.13+11) OpenJDK 64-Bit Server VM Temurin-17.0.13+11 (build 17.0.13+11, mixed mode, sharing) ``` AdoptOpenJDK は Eclipse Foundation に移行され、その名前が Eclipse Adoptium プロジェクトに変更されました。JDK の名前は Temurin に変更されました。 ## [](#mule-のダウンロード)Mule のダウンロード 1. Mule 4 のバイナリファイルを次のリンクからダウンロードして展開します。 [https://www.mulesoft.com/lp/dl/mule-esb-enterprise](https://www.mulesoft.com/lp/dl/mule-esb-enterprise) 2. 環境変数の ​`MULE_HOME`​ を、ファイルを展開したフォルダー内の ​`mule`​ ディレクトリに設定します。 バージョン 4.9.0 を ​`Downloads`​ ディレクトリに展開した場合の例を示します。 - Windows 環境: ```console $ env:MULE_HOME="C:\Downloads\mule-enterprise-standalone-4.9.0" ``` - Linux または Unix 環境: ```console $ export MULE_HOME=~/Downloads/mule-enterprise-standalone-4.9.0 ``` `MULE_HOME`​ 設定を永続化するための手順はオペレーティングシステムによって異なります。 ### [](#mule-アプリケーションのテスト)Mule アプリケーションのテスト Mule をダウンロードしたら、次のコマンドを実行してシステムでエラーなく動作することをテストして確認します。 - Windows 環境: ```powershell %MULE_HOME%\bin\mule.bat ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#mule-のインストール)Mule のインストール 対応するコマンドを実行して、Mule を Windows サービスか、Linux または Unix デーモンとしてインストールできます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat install ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule install ``` ## [](#wrapper-conf-ファイルのプロパティの設定)wrapper.conf ファイルのプロパティの設定 Mule をサービスまたはデーモンとしてインストールしたら、​`wrapper.conf`​ ファイルで定義されたプロパティを変更できます。 設定ファイルで実行できる内容についての詳細は、 [「Configuration Property Overview (設定プロパティの概要)」](https://wrapper.tanukisoftware.com/doc/english/properties.html)​を参照してください。 `wrapper.conf`​ ファイルを変更したら、Mule インスタンスを再起動して、変更を有効にします。

新しいプロパティを追加するときは、ほかのプロパティで同じ連番がまだ使用されていないことを確認します (​wrapper-additional.conf​ のプロパティについては、Mule によって再起動時に調整されるので心配はいりません)。

wrapper-additional.conf​ ファイルは、Mule によって自動的に生成されるため変更しないでください。
## [](#cpu-アフィニティの設定)CPU アフィニティの設定 多くのオペレーティングシステムで、プロセスを 1 つ以上の中央処理装置 (CPU) にバインドしてプロセスが割り当てられた CPU でのみ実行されるようにするメカニズムが提供されています。使用する環境に CPU アフィニティを設定して Mule を非仮想マルチコアサーバーで実行し、サブスクリプションに含まれるコア数に準拠することができます。 ### [](#cpu-アフィニティ使用時の考慮事項)CPU アフィニティ使用時の考慮事項 - CPU にはコアのグループがあり、キャッシュを共有してスレッド通信と移行のパフォーマンスを改善しています。こうしたパフォーマンスの問題を回避するには、この機能をセットアップする前にどのコアがこのキャッシュを共有しているかインフラストラクチャチームに確認します。 - CPU アフィニティ設定を妨げる可能性がある既存のリソース割り当てポリシーがないことをインフラストラクチャチームに確認します。 - CPU アフィニティで設定する予定のコア数が MuleSoft サブスクリプションプランに含まれるコア数を超えていないことを確認します。 ## [](#mule-サービスまたはデーモンの削除)Mule サービスまたはデーモンの削除 対応するコマンドを実行して、Mule を Windows サービスまたは Unix デーモンとして削除できます。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat remove ``` - Linux または Unix 環境: ```console $ $MULE_HOME/bin/mule remove MULE_HOME is set to /Applications/mule-enterprise-standalone-4.9.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.9.0 Detected Mac OSX: Mule Enterprise Edition is not running. Removing Mule Enterprise Edition daemon... ``` ## [](#anypoint-monitoring-のインストール)Anypoint Monitoring のインストール オンプレミスランタイムインスタンスのクラウド管理対応バージョン用の ​[Anypoint Monitoring をインストール](https://docs.mulesoft.com/jp/monitoring/am-installing)​して、そのサーバー上で動作するアプリケーションを監視できます。 ## [](#mule-バージョンの更新アップグレード移行)Mule バージョンの更新、アップグレード、移行 MuleSoft では Mule の新しいメジャーリリース、マイナーリリース、パッチリリースバージョンだけでなく、Mule のパッチリリースへの月 1 回の更新がリリースされます。この更新には、最新のバグ修正とセキュリティの機能強化が含まれています。 - Mule のパッチバージョンを更新するには、​[「Update Patches to Mule Runtime Engine (Mule Runtime Engine のパッチの更新)」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/patching-mule-versions)​を参照してください。 - Mule 4 の新しいバージョンにアップグレードするには、​[「Upgrading Mule Runtime Engine (Versions 4.x to 4.n) (Mule Runtime Engine のアップグレード (バージョン 4.x から 4.n))」](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions)​を参照してください。 - Mule 3 から Mule 4 に移行するには、​[「Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-intro)​を参照してください。 ## [](#関連情報)関連情報 - [Mule の開始と停止](https://docs.mulesoft.com/jp/mule-runtime/4.9/starting-and-stopping-mule-esb) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Studio 7.0 のインストール](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [Mule 4 の新機能](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-runtime-updates) # Mule のプロファイリング Mule Runtime Engine (Mule) をプロファイリングすると、カスタム Mule 拡張機能でのメモリリークを識別しやすくなる可能性があります。 Mule をプロファイリングするには、Java プロファイラーを Mule インスタンスに読み込む必要があります。 複数の Java プロファイラーオプションを使用できますが、MuleSoft では、JVM のパフォーマンスを分析するためによく使用されている Java プロファイルである [YourKit](https://www.yourkit.com/)​ を使用することをお勧めします。 YourKit を使用していない場合、各プロファイルのドキュメントを参照して、Mule-Java プロセスの接続方法をご確認ください。 Mule インスタンスをプロファイリングする方法は 2 つあります。 ## [](#yourkit-エージェントを参照するように-mule-を設定する)YourKit エージェントを参照するように Mule を設定する この方法では、YourKit プロファイラーをダウンロードして ​`wrapper.conf`​ ファイルで設定し、Mule インスタンスを再起動します。プロセスを完了するには、YourKit UI をローカルまたはリモートの Mule インスタンスに接続します。 YourKit ドキュメントを参照してオペレーティングシステムに基づいてエージェントを適切に起動する方法の詳細を確認し、起動パラメーターの完全なリストを確認してください。 独自の YourKit プロファイラーエージェントを使用するには、次の操作を実行する必要があります。 1. YourKit ビルドを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。以前のプロファイラーダウンロードリリースページから古いビルドバージョンをダウンロードすることができます。 2. YourKit パッケージコンテンツを展開し、​`/bin/`​ フォルダー内でエージェントを見つけます。 3. 次の行を ​`$MULE_HOME/conf`​ パスにある ​`wrapper.conf`​ ファイルに追加して、YourKit エージェントが Mule インスタンスとやりとりできるようにします。 wrapper.java.additional.=-agentpath:=delay=10000 次の項目の値は次のとおりです。 - ``​ 値は、マシンの設定およびオペレーティングシステムに応じて異なります。 - ``​ Java サービスラッパーのこのコンポーネントは ​`wrapper.conf`​ ファイルの残りの ​`wrapper.java.additional`​ コンポーネントと連続している必要があります。 - ``​ は省略可能なポート仕様です。デフォルトでは、YourKit エージェントによってインターネットに接続しているポートがスキャンされます。 たとえば、Linux 用の ​`yjp-2013-build-13062`​ をダウンロードしたとすると、​`wrapper.conf`​ で追加するエントリは次のようになります。 wrapper.java.additional.=-agentpath:/yjp-2013-build-13062/bin/linux-x86-64/libyjpagent.so=delay=10000,port= 1. Mule を再起動します。 2. Mule が再起動したら、ローカルまたはリモートの Mule インスタンスに接続するように YourKit プロファイラー UI を設定します。 ### [](#yourkit-ui-をローカル-mule-インスタンスに接続する)YourKit UI をローカル Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Local Applications (ローカルアプリケーションを監視)\] で ​`MuleContainerBootstrap`​ プロセスをダブルクリックします。 ![profiling mule 286a5](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/profiling-mule-286a5.png) 3. YourKit が Mule インスタンスに接続されていることを確認します。 ![yourkit hooked up](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/yourkit-hooked-up.png) ### [](#yourkit-ui-をリモート-mule-インスタンスに接続する)YourKit UI をリモート Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Remote Applications (リモートアプリケーションを監視)\] で ​**\[Connect to remote application (リモートアプリケーションに接続)\]**​ をクリックします。 ![monitor remote apps](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/monitor-remote-apps.png) 3. サーバーのユーザー名とパスワードをセットアップします。 4. SSH 認証を設定します: ![yourkit auth](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/yourkit-auth.png) 5. **\[OK\]**​ をクリックします。 6. 使用可能なアプリケーションをスキャンした後で、YourKit は Mule インスタンスに接続されます。 ![yourkit hooked up](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/yourkit-hooked-up.png) ## [](#アタッチモードでのプロファイラーエージェントの実行)アタッチモードでのプロファイラーエージェントの実行 この方法では、YourKit プロファイラーをダウンロードしてアタッチモードで実行されるようにそのエージェントを設定します。プロセスを完了するには、プロファイラーを実行します。アタッチモードで実行すると、実行中の Mule インスタンスを再起動せずにプロファイリングできます。 このタスクのステップは、環境に応じて異なります。ここで紹介している例が当てはまらない場合、YourKit ドキュメントを参照してください。 1. プロファイラーを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。 2. プロファイラーのパッケージを展開します。 3. `jps`​ を実行して Mule の PID を判断します。 ```console jps ``` 4. `MuleContainerBootstrap`​ の PID を取得します。 2838 MuleContainerBootstrap 21311 Jps 5. YourKit パッケージ内で、​`bin`​ ディレクトリを開きます。 ```console cd yjp-2015-build-15086/bin ``` 6. `MuleContainerBootstrap`​ の PID を含む ​`-attach`​ フラグを含めて、​`yph.sh`​ を実行します。 ```console ./yph.sh -attach 2838 ``` 7. エージェントがアタッチされていることを確認します。 ```console Attaching to process 2838 using default options The profiler agent has attached. Waiting while it initializes... The agent is loaded and is listening on port 10001. You can connect to it from the profiler UI. ``` ## [](#関連情報)関連情報 [YourKit](https://www.yourkit.com/) # Mule のプロファイリング Mule Runtime Engine (Mule) をプロファイリングすると、カスタム Mule 拡張機能でのメモリリークを識別しやすくなる可能性があります。 Mule をプロファイリングするには、Java プロファイラーを Mule インスタンスに読み込む必要があります。 複数の Java プロファイラーオプションを使用できますが、MuleSoft では、JVM のパフォーマンスを分析するためによく使用されている Java プロファイルである [YourKit](https://www.yourkit.com/)​ を使用することをお勧めします。 YourKit を使用していない場合、各プロファイルのドキュメントを参照して、Mule-Java プロセスの接続方法をご確認ください。 Mule インスタンスをプロファイリングする方法は 2 つあります。 ## [](#yourkit-エージェントを参照するように-mule-を設定する)YourKit エージェントを参照するように Mule を設定する この方法では、YourKit プロファイラーをダウンロードして ​`wrapper.conf`​ ファイルで設定し、Mule インスタンスを再起動します。プロセスを完了するには、YourKit UI をローカルまたはリモートの Mule インスタンスに接続します。 YourKit ドキュメントを参照してオペレーティングシステムに基づいてエージェントを適切に起動する方法の詳細を確認し、起動パラメーターの完全なリストを確認してください。 独自の YourKit プロファイラーエージェントを使用するには、次の操作を実行する必要があります。 1. YourKit ビルドを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。以前のプロファイラーダウンロードリリースページから古いビルドバージョンをダウンロードすることができます。 2. YourKit パッケージコンテンツを展開し、​`/bin/`​ フォルダー内でエージェントを見つけます。 3. 次の行を ​`$MULE_HOME/conf`​ パスにある ​`wrapper.conf`​ ファイルに追加して、YourKit エージェントが Mule インスタンスとやりとりできるようにします。 wrapper.java.additional.=-agentpath:=delay=10000 次の項目の値は次のとおりです。 - ``​ 値は、マシンの設定およびオペレーティングシステムに応じて異なります。 - ``​ Java サービスラッパーのこのコンポーネントは ​`wrapper.conf`​ ファイルの残りの ​`wrapper.java.additional`​ コンポーネントと連続している必要があります。 - ``​ は省略可能なポート仕様です。デフォルトでは、YourKit エージェントによってインターネットに接続しているポートがスキャンされます。 たとえば、Linux 用の ​`yjp-2013-build-13062`​ をダウンロードしたとすると、​`wrapper.conf`​ で追加するエントリは次のようになります。 wrapper.java.additional.=-agentpath:/yjp-2013-build-13062/bin/linux-x86-64/libyjpagent.so=delay=10000,port= 1. Mule を再起動します。 2. Mule が再起動したら、ローカルまたはリモートの Mule インスタンスに接続するように YourKit プロファイラー UI を設定します。 ### [](#yourkit-ui-をローカル-mule-インスタンスに接続する)YourKit UI をローカル Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Local Applications (ローカルアプリケーションを監視)\] で ​`MuleContainerBootstrap`​ プロセスをダブルクリックします。 ![profiling mule 286a5](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/profiling-mule-286a5.png) 3. YourKit が Mule インスタンスに接続されていることを確認します。 ![yourkit hooked up](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/yourkit-hooked-up.png) ### [](#yourkit-ui-をリモート-mule-インスタンスに接続する)YourKit UI をリモート Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Remote Applications (リモートアプリケーションを監視)\] で ​**\[Connect to remote application (リモートアプリケーションに接続)\]**​ をクリックします。 ![monitor remote apps](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/monitor-remote-apps.png) 3. サーバーのユーザー名とパスワードをセットアップします。 4. SSH 認証を設定します: ![yourkit auth](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/yourkit-auth.png) 5. **\[OK\]**​ をクリックします。 6. 使用可能なアプリケーションをスキャンした後で、YourKit は Mule インスタンスに接続されます。 ![yourkit hooked up](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/yourkit-hooked-up.png) ## [](#アタッチモードでのプロファイラーエージェントの実行)アタッチモードでのプロファイラーエージェントの実行 この方法では、YourKit プロファイラーをダウンロードしてアタッチモードで実行されるようにそのエージェントを設定します。プロセスを完了するには、プロファイラーを実行します。アタッチモードで実行すると、実行中の Mule インスタンスを再起動せずにプロファイリングできます。 このタスクのステップは、環境に応じて異なります。ここで紹介している例が当てはまらない場合、YourKit ドキュメントを参照してください。 1. プロファイラーを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。 2. プロファイラーのパッケージを展開します。 3. `jps`​ を実行して Mule の PID を判断します。 ```console jps ``` 4. `MuleContainerBootstrap`​ の PID を取得します。 2838 MuleContainerBootstrap 21311 Jps 5. YourKit パッケージ内で、​`bin`​ ディレクトリを開きます。 ```console cd yjp-2015-build-15086/bin ``` 6. `MuleContainerBootstrap`​ の PID を含む ​`-attach`​ フラグを含めて、​`yph.sh`​ を実行します。 ```console ./yph.sh -attach 2838 ``` 7. エージェントがアタッチされていることを確認します。 ```console Attaching to process 2838 using default options The profiler agent has attached. Waiting while it initializes... The agent is loaded and is listening on port 10001. You can connect to it from the profiler UI. ``` ## [](#関連情報)関連情報 [YourKit](https://www.yourkit.com/) # Mule のプロファイリング Mule Runtime Engine (Mule) をプロファイリングすると、カスタム Mule 拡張機能でのメモリリークを識別しやすくなる可能性があります。 Mule をプロファイリングするには、Java プロファイラーを Mule インスタンスに読み込む必要があります。 複数の Java プロファイラーオプションを使用できますが、MuleSoft では、JVM のパフォーマンスを分析するためによく使用されている Java プロファイルである [YourKit](https://www.yourkit.com/)​ を使用することをお勧めします。 YourKit を使用していない場合、各プロファイルのドキュメントを参照して、Mule-Java プロセスの接続方法をご確認ください。 Mule インスタンスをプロファイリングする方法は 2 つあります。 ## [](#yourkit-エージェントを参照するように-mule-を設定する)YourKit エージェントを参照するように Mule を設定する この方法では、YourKit プロファイラーをダウンロードして ​`wrapper.conf`​ ファイルで設定し、Mule インスタンスを再起動します。プロセスを完了するには、YourKit UI をローカルまたはリモートの Mule インスタンスに接続します。 YourKit ドキュメントを参照してオペレーティングシステムに基づいてエージェントを適切に起動する方法の詳細を確認し、起動パラメーターの完全なリストを確認してください。 独自の YourKit プロファイラーエージェントを使用するには、次の操作を実行する必要があります。 1. YourKit ビルドを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。以前のプロファイラーダウンロードリリースページから古いビルドバージョンをダウンロードすることができます。 2. YourKit パッケージコンテンツを展開し、​`/bin/`​ フォルダー内でエージェントを見つけます。 3. 次の行を ​`$MULE_HOME/conf`​ パスにある ​`wrapper.conf`​ ファイルに追加して、YourKit エージェントが Mule インスタンスとやりとりできるようにします。 wrapper.java.additional.=-agentpath:=delay=10000 次の項目の値は次のとおりです。 - ``​ 値は、マシンの設定およびオペレーティングシステムに応じて異なります。 - ``​ Java サービスラッパーのこのコンポーネントは ​`wrapper.conf`​ ファイルの残りの ​`wrapper.java.additional`​ コンポーネントと連続している必要があります。 - ``​ は省略可能なポート仕様です。デフォルトでは、YourKit エージェントによってインターネットに接続しているポートがスキャンされます。 たとえば、Linux 用の ​`yjp-2013-build-13062`​ をダウンロードしたとすると、​`wrapper.conf`​ で追加するエントリは次のようになります。 wrapper.java.additional.=-agentpath:/yjp-2013-build-13062/bin/linux-x86-64/libyjpagent.so=delay=10000,port= 1. Mule を再起動します。 2. Mule が再起動したら、ローカルまたはリモートの Mule インスタンスに接続するように YourKit プロファイラー UI を設定します。 ### [](#yourkit-ui-をローカル-mule-インスタンスに接続する)YourKit UI をローカル Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Local Applications (ローカルアプリケーションを監視)\] で ​`MuleContainerBootstrap`​ プロセスをダブルクリックします。 ![profiling mule 286a5](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/profiling-mule-286a5.png) 3. YourKit が Mule インスタンスに接続されていることを確認します。 ![yourkit hooked up](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/yourkit-hooked-up.png) ### [](#yourkit-ui-をリモート-mule-インスタンスに接続する)YourKit UI をリモート Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Remote Applications (リモートアプリケーションを監視)\] で ​**\[Connect to remote application (リモートアプリケーションに接続)\]**​ をクリックします。 ![monitor remote apps](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/monitor-remote-apps.png) 3. サーバーのユーザー名とパスワードをセットアップします。 4. SSH 認証を設定します: ![yourkit auth](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/yourkit-auth.png) 5. **\[OK\]**​ をクリックします。 6. 使用可能なアプリケーションをスキャンした後で、YourKit は Mule インスタンスに接続されます。 ![yourkit hooked up](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/yourkit-hooked-up.png) ## [](#アタッチモードでのプロファイラーエージェントの実行)アタッチモードでのプロファイラーエージェントの実行 この方法では、YourKit プロファイラーをダウンロードしてアタッチモードで実行されるようにそのエージェントを設定します。プロセスを完了するには、プロファイラーを実行します。アタッチモードで実行すると、実行中の Mule インスタンスを再起動せずにプロファイリングできます。 このタスクのステップは、環境に応じて異なります。ここで紹介している例が当てはまらない場合、YourKit ドキュメントを参照してください。 1. プロファイラーを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。 2. プロファイラーのパッケージを展開します。 3. `jps`​ を実行して Mule の PID を判断します。 ```console jps ``` 4. `MuleContainerBootstrap`​ の PID を取得します。 2838 MuleContainerBootstrap 21311 Jps 5. YourKit パッケージ内で、​`bin`​ ディレクトリを開きます。 ```console cd yjp-2015-build-15086/bin ``` 6. `MuleContainerBootstrap`​ の PID を含む ​`-attach`​ フラグを含めて、​`yph.sh`​ を実行します。 ```console ./yph.sh -attach 2838 ``` 7. エージェントがアタッチされていることを確認します。 ```console Attaching to process 2838 using default options The profiler agent has attached. Waiting while it initializes... The agent is loaded and is listening on port 10001. You can connect to it from the profiler UI. ``` ## [](#関連情報)関連情報 [YourKit](https://www.yourkit.com/) # Mule のプロファイリング Mule Runtime Engine (Mule) をプロファイリングすると、カスタム Mule 拡張機能でのメモリリークを識別しやすくなる可能性があります。 Mule をプロファイリングするには、Java プロファイラーを Mule インスタンスに読み込む必要があります。 複数の Java プロファイラーオプションを使用できますが、MuleSoft では、JVM のパフォーマンスを分析するためによく使用されている Java プロファイルである [YourKit](https://www.yourkit.com/)​ を使用することをお勧めします。 YourKit を使用していない場合、各プロファイルのドキュメントを参照して、Mule-Java プロセスの接続方法をご確認ください。 Mule インスタンスをプロファイリングする方法は 2 つあります。 ## [](#yourkit-エージェントを参照するように-mule-を設定する)YourKit エージェントを参照するように Mule を設定する この方法では、YourKit プロファイラーをダウンロードして ​`wrapper.conf`​ ファイルで設定し、Mule インスタンスを再起動します。プロセスを完了するには、YourKit UI をローカルまたはリモートの Mule インスタンスに接続します。 YourKit ドキュメントを参照してオペレーティングシステムに基づいてエージェントを適切に起動する方法の詳細を確認し、起動パラメーターの完全なリストを確認してください。 独自の YourKit プロファイラーエージェントを使用するには、次の操作を実行する必要があります。 1. YourKit ビルドを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。以前のプロファイラーダウンロードリリースページから古いビルドバージョンをダウンロードすることができます。 2. YourKit パッケージコンテンツを展開し、​`/bin/`​ フォルダー内でエージェントを見つけます。 3. 次の行を ​`$MULE_HOME/conf`​ パスにある ​`wrapper.conf`​ ファイルに追加して、YourKit エージェントが Mule インスタンスとやりとりできるようにします。 wrapper.java.additional.=-agentpath:=delay=10000 次の項目の値は次のとおりです。 - ``​ 値は、マシンの設定およびオペレーティングシステムに応じて異なります。 - ``​ Java サービスラッパーのこのコンポーネントは ​`wrapper.conf`​ ファイルの残りの ​`wrapper.java.additional`​ コンポーネントと連続している必要があります。 - ``​ は省略可能なポート仕様です。デフォルトでは、YourKit エージェントによってインターネットに接続しているポートがスキャンされます。 たとえば、Linux 用の ​`yjp-2013-build-13062`​ をダウンロードしたとすると、​`wrapper.conf`​ で追加するエントリは次のようになります。 wrapper.java.additional.=-agentpath:/yjp-2013-build-13062/bin/linux-x86-64/libyjpagent.so=delay=10000,port= 1. Mule を再起動します。 2. Mule が再起動したら、ローカルまたはリモートの Mule インスタンスに接続するように YourKit プロファイラー UI を設定します。 ### [](#yourkit-ui-をローカル-mule-インスタンスに接続する)YourKit UI をローカル Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Local Applications (ローカルアプリケーションを監視)\] で ​`MuleContainerBootstrap`​ プロセスをダブルクリックします。 ![profiling mule 286a5](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/profiling-mule-286a5.png) 3. YourKit が Mule インスタンスに接続されていることを確認します。 ![yourkit hooked up](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/yourkit-hooked-up.png) ### [](#yourkit-ui-をリモート-mule-インスタンスに接続する)YourKit UI をリモート Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Remote Applications (リモートアプリケーションを監視)\] で ​**\[Connect to remote application (リモートアプリケーションに接続)\]**​ をクリックします。 ![monitor remote apps](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/monitor-remote-apps.png) 3. サーバーのユーザー名とパスワードをセットアップします。 4. SSH 認証を設定します: ![yourkit auth](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/yourkit-auth.png) 5. **\[OK\]**​ をクリックします。 6. 使用可能なアプリケーションをスキャンした後で、YourKit は Mule インスタンスに接続されます。 ![yourkit hooked up](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/yourkit-hooked-up.png) ## [](#アタッチモードでのプロファイラーエージェントの実行)アタッチモードでのプロファイラーエージェントの実行 この方法では、YourKit プロファイラーをダウンロードしてアタッチモードで実行されるようにそのエージェントを設定します。プロセスを完了するには、プロファイラーを実行します。アタッチモードで実行すると、実行中の Mule インスタンスを再起動せずにプロファイリングできます。 このタスクのステップは、環境に応じて異なります。ここで紹介している例が当てはまらない場合、YourKit ドキュメントを参照してください。 1. プロファイラーを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。 2. プロファイラーのパッケージを展開します。 3. `jps`​ を実行して Mule の PID を判断します。 ```console jps ``` 4. `MuleContainerBootstrap`​ の PID を取得します。 2838 MuleContainerBootstrap 21311 Jps 5. YourKit パッケージ内で、​`bin`​ ディレクトリを開きます。 ```console cd yjp-2015-build-15086/bin ``` 6. `MuleContainerBootstrap`​ の PID を含む ​`-attach`​ フラグを含めて、​`yph.sh`​ を実行します。 ```console ./yph.sh -attach 2838 ``` 7. エージェントがアタッチされていることを確認します。 ```console Attaching to process 2838 using default options The profiler agent has attached. Waiting while it initializes... The agent is loaded and is listening on port 10001. You can connect to it from the profiler UI. ``` ## [](#関連情報)関連情報 [YourKit](https://www.yourkit.com/) # Mule のプロファイリング Mule Runtime Engine (Mule) をプロファイリングすると、カスタム Mule 拡張機能でのメモリリークを識別しやすくなる可能性があります。 Mule をプロファイリングするには、Java プロファイラーを Mule インスタンスに読み込む必要があります。 複数の Java プロファイラーオプションを使用できますが、MuleSoft では、JVM のパフォーマンスを分析するためによく使用されている Java プロファイルである [YourKit](https://www.yourkit.com/)​ を使用することをお勧めします。 YourKit を使用していない場合、各プロファイルのドキュメントを参照して、Mule-Java プロセスの接続方法をご確認ください。 Mule インスタンスをプロファイリングする方法は 2 つあります。 ## [](#yourkit-エージェントを参照するように-mule-を設定する)YourKit エージェントを参照するように Mule を設定する この方法では、YourKit プロファイラーをダウンロードして ​`wrapper.conf`​ ファイルで設定し、Mule インスタンスを再起動します。プロセスを完了するには、YourKit UI をローカルまたはリモートの Mule インスタンスに接続します。 YourKit ドキュメントを参照してオペレーティングシステムに基づいてエージェントを適切に起動する方法の詳細を確認し、起動パラメーターの完全なリストを確認してください。 独自の YourKit プロファイラーエージェントを使用するには、次の操作を実行する必要があります。 1. YourKit ビルドを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。以前のプロファイラーダウンロードリリースページから古いビルドバージョンをダウンロードすることができます。 2. YourKit パッケージコンテンツを展開し、​`/bin/`​ フォルダー内でエージェントを見つけます。 3. 次の行を ​`$MULE_HOME/conf`​ パスにある ​`wrapper.conf`​ ファイルに追加して、YourKit エージェントが Mule インスタンスとやりとりできるようにします。 wrapper.java.additional.=-agentpath:=delay=10000 次の項目の値は次のとおりです。 - ``​ 値は、マシンの設定およびオペレーティングシステムに応じて異なります。 - ``​ Java サービスラッパーのこのコンポーネントは ​`wrapper.conf`​ ファイルの残りの ​`wrapper.java.additional`​ コンポーネントと連続している必要があります。 - ``​ は省略可能なポート仕様です。デフォルトでは、YourKit エージェントによってインターネットに接続しているポートがスキャンされます。 たとえば、Linux 用の ​`yjp-2013-build-13062`​ をダウンロードしたとすると、​`wrapper.conf`​ で追加するエントリは次のようになります。 wrapper.java.additional.=-agentpath:/yjp-2013-build-13062/bin/linux-x86-64/libyjpagent.so=delay=10000,port= 1. Mule を再起動します。 2. Mule が再起動したら、ローカルまたはリモートの Mule インスタンスに接続するように YourKit プロファイラー UI を設定します。 ### [](#yourkit-ui-をローカル-mule-インスタンスに接続する)YourKit UI をローカル Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Local Applications (ローカルアプリケーションを監視)\] で ​`MuleContainerBootstrap`​ プロセスをダブルクリックします。 ![profiling mule 286a5](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/profiling-mule-286a5.png) 3. YourKit が Mule インスタンスに接続されていることを確認します。 ![yourkit hooked up](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/yourkit-hooked-up.png) ### [](#yourkit-ui-をリモート-mule-インスタンスに接続する)YourKit UI をリモート Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Remote Applications (リモートアプリケーションを監視)\] で ​**\[Connect to remote application (リモートアプリケーションに接続)\]**​ をクリックします。 ![最新の接続の詳細を使用してリモートアプリケーションに接続するオプション](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/monitor-remote-apps.png) 3. サーバーのユーザー名とパスワードをセットアップします。 4. SSH 認証を設定します: ![yourkit auth](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/yourkit-auth.png) 5. **\[OK\]**​ をクリックします。 6. 使用可能なアプリケーションをスキャンした後で、YourKit は Mule インスタンスに接続されます。 ![yourkit hooked up](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/yourkit-hooked-up.png) ## [](#アタッチモードでのプロファイラーエージェントの実行)アタッチモードでのプロファイラーエージェントの実行 この方法では、YourKit プロファイラーをダウンロードしてアタッチモードで実行されるようにそのエージェントを設定します。プロセスを完了するには、プロファイラーを実行します。アタッチモードで実行すると、実行中の Mule インスタンスを再起動せずにプロファイリングできます。 このタスクのステップは、環境に応じて異なります。ここで紹介している例が当てはまらない場合、YourKit ドキュメントを参照してください。 1. プロファイラーを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。 2. プロファイラーのパッケージを展開します。 3. `jps`​ を実行して Mule の PID を判断します。 ```console jps ``` 4. `MuleContainerBootstrap`​ の PID を取得します。 2838 MuleContainerBootstrap 21311 Jps 5. YourKit パッケージ内で、​`bin`​ ディレクトリを開きます。 ```console cd yjp-2015-build-15086/bin ``` 6. `MuleContainerBootstrap`​ の PID を含む ​`-attach`​ フラグを含めて、​`yph.sh`​ を実行します。 ```console ./yph.sh -attach 2838 ``` 7. エージェントがアタッチされていることを確認します。 ```console Attaching to process 2838 using default options The profiler agent has attached. Waiting while it initializes... The agent is loaded and is listening on port 10001. You can connect to it from the profiler UI. ``` ## [](#関連情報)関連情報 [YourKit](https://www.yourkit.com/) # Mule のプロファイリング Mule Runtime Engine (Mule) をプロファイリングすると、カスタム Mule 拡張機能でのメモリリークを識別しやすくなる可能性があります。 Mule をプロファイリングするには、Java プロファイラーを Mule インスタンスに読み込む必要があります。 複数の Java プロファイラーオプションを使用できますが、MuleSoft では、JVM のパフォーマンスを分析するためによく使用されている Java プロファイルである [YourKit](https://www.yourkit.com/)​ を使用することをお勧めします。 YourKit を使用していない場合、各プロファイルのドキュメントを参照して、Mule-Java プロセスの接続方法をご確認ください。 Mule インスタンスをプロファイリングする方法は 2 つあります。 ## [](#yourkit-エージェントを参照するように-mule-を設定する)YourKit エージェントを参照するように Mule を設定する この方法では、YourKit プロファイラーをダウンロードして ​`wrapper.conf`​ ファイルで設定し、Mule インスタンスを再起動します。プロセスを完了するには、YourKit UI をローカルまたはリモートの Mule インスタンスに接続します。 YourKit ドキュメントを参照してオペレーティングシステムに基づいてエージェントを適切に起動する方法の詳細を確認し、起動パラメーターの完全なリストを確認してください。 独自の YourKit プロファイラーエージェントを使用するには、次の操作を実行する必要があります。 1. YourKit ビルドを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。以前のプロファイラーダウンロードリリースページから古いビルドバージョンをダウンロードすることができます。 2. YourKit パッケージコンテンツを展開し、​`/bin/`​ フォルダー内でエージェントを見つけます。 3. 次の行を ​`$MULE_HOME/conf`​ パスにある ​`wrapper.conf`​ ファイルに追加して、YourKit エージェントが Mule インスタンスとやりとりできるようにします。 wrapper.java.additional.=-agentpath:=delay=10000 次の項目の値は次のとおりです。 - ``​ 値は、マシンの設定およびオペレーティングシステムに応じて異なります。 - ``​ Java サービスラッパーのこのコンポーネントは ​`wrapper.conf`​ ファイルの残りの ​`wrapper.java.additional`​ コンポーネントと連続している必要があります。 - ``​ は省略可能なポート仕様です。デフォルトでは、YourKit エージェントによってインターネットに接続しているポートがスキャンされます。 たとえば、Linux 用の ​`yjp-2013-build-13062`​ をダウンロードしたとすると、​`wrapper.conf`​ で追加するエントリは次のようになります。 wrapper.java.additional.=-agentpath:/yjp-2013-build-13062/bin/linux-x86-64/libyjpagent.so=delay=10000,port= 1. Mule を再起動します。 2. Mule が再起動したら、ローカルまたはリモートの Mule インスタンスに接続するように YourKit プロファイラー UI を設定します。 ### [](#yourkit-ui-をローカル-mule-インスタンスに接続する)YourKit UI をローカル Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Local Applications (ローカルアプリケーションを監視)\] で ​`MuleContainerBootstrap`​ プロセスをダブルクリックします。 ![アプリケーションが PID とプロファイラー状況と共にリストされているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/profiling-mule-286a5.png) 3. YourKit が Mule インスタンスに接続されていることを確認します。 ![メソッドのパフォーマンスが表示されている YourKit Java プロファイラーの詳細な CPU プロファイリングインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/yourkit-hooked-up.png) ### [](#yourkit-ui-をリモート-mule-インスタンスに接続する)YourKit UI をリモート Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Remote Applications (リモートアプリケーションを監視)\] で ​**\[Connect to remote application (リモートアプリケーションに接続)\]**​ をクリックします。 ![最新の接続の詳細を使用してリモートアプリケーションに接続するオプション](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/monitor-remote-apps.png) 3. サーバーのユーザー名とパスワードをセットアップします。 4. SSH 認証を設定します: ![YourKit の SSH 認証ダイアログ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/yourkit-auth.png) 5. **\[OK\]**​ をクリックします。 6. 使用可能なアプリケーションをスキャンした後で、YourKit は Mule インスタンスに接続されます。 ![メソッドのパフォーマンスが表示されている YourKit Java プロファイラーの詳細な CPU プロファイリングインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/yourkit-hooked-up.png) ## [](#アタッチモードでのプロファイラーエージェントの実行)アタッチモードでのプロファイラーエージェントの実行 この方法では、YourKit プロファイラーをダウンロードしてアタッチモードで実行されるようにそのエージェントを設定します。プロセスを完了するには、プロファイラーを実行します。アタッチモードで実行すると、実行中の Mule インスタンスを再起動せずにプロファイリングできます。 このタスクのステップは、環境に応じて異なります。ここで紹介している例が当てはまらない場合、YourKit ドキュメントを参照してください。 1. プロファイラーを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。 2. プロファイラーのパッケージを展開します。 3. `jps`​ を実行して Mule の PID を判断します。 ```console jps ``` 4. `MuleContainerBootstrap`​ の PID を取得します。 2838 MuleContainerBootstrap 21311 Jps 5. YourKit パッケージ内で、​`bin`​ ディレクトリを開きます。 ```console cd yjp-2015-build-15086/bin ``` 6. `MuleContainerBootstrap`​ の PID を含む ​`-attach`​ フラグを含めて、​`yph.sh`​ を実行します。 ```console ./yph.sh -attach 2838 ``` 7. エージェントがアタッチされていることを確認します。 ```console Attaching to process 2838 using default options The profiler agent has attached. Waiting while it initializes... The agent is loaded and is listening on port 10001. You can connect to it from the profiler UI. ``` ## [](#関連情報)関連情報 [YourKit](https://www.yourkit.com/) # Mule のプロファイリング Mule Runtime Engine (Mule) をプロファイリングすると、カスタム Mule 拡張機能でのメモリリークを識別しやすくなる可能性があります。 Mule をプロファイリングするには、Java プロファイラーを Mule インスタンスに読み込む必要があります。 複数の Java プロファイラーオプションを使用できますが、MuleSoft では、JVM のパフォーマンスを分析するためによく使用されている Java プロファイルである [YourKit](https://www.yourkit.com/)​ を使用することをお勧めします。 YourKit を使用していない場合、各プロファイルのドキュメントを参照して、Mule-Java プロセスの接続方法をご確認ください。 Mule インスタンスをプロファイリングする方法は 2 つあります。 ## [](#yourkit-エージェントを参照するように-mule-を設定する)YourKit エージェントを参照するように Mule を設定する この方法では、YourKit プロファイラーをダウンロードして ​`wrapper.conf`​ ファイルで設定し、Mule インスタンスを再起動します。プロセスを完了するには、YourKit UI をローカルまたはリモートの Mule インスタンスに接続します。 YourKit ドキュメントを参照してオペレーティングシステムに基づいてエージェントを適切に起動する方法の詳細を確認し、起動パラメーターの完全なリストを確認してください。 独自の YourKit プロファイラーエージェントを使用するには、次の操作を実行する必要があります。 1. YourKit ビルドを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。以前のプロファイラーダウンロードリリースページから古いビルドバージョンをダウンロードすることができます。 2. YourKit パッケージコンテンツを展開し、​`/bin/`​ フォルダー内でエージェントを見つけます。 3. 次の行を ​`$MULE_HOME/conf`​ パスにある ​`wrapper.conf`​ ファイルに追加して、YourKit エージェントが Mule インスタンスとやりとりできるようにします。 wrapper.java.additional.=-agentpath:=delay=10000 次の項目の値は次のとおりです。 - ``​ 値は、マシンの設定およびオペレーティングシステムに応じて異なります。 - ``​ Java サービスラッパーのこのコンポーネントは ​`wrapper.conf`​ ファイルの残りの ​`wrapper.java.additional`​ コンポーネントと連続している必要があります。 - ``​ は省略可能なポート仕様です。デフォルトでは、YourKit エージェントによってインターネットに接続しているポートがスキャンされます。 たとえば、Linux 用の ​`yjp-2013-build-13062`​ をダウンロードしたとすると、​`wrapper.conf`​ で追加するエントリは次のようになります。 wrapper.java.additional.=-agentpath:/yjp-2013-build-13062/bin/linux-x86-64/libyjpagent.so=delay=10000,port= 1. Mule を再起動します。 2. Mule が再起動したら、ローカルまたはリモートの Mule インスタンスに接続するように YourKit プロファイラー UI を設定します。 ### [](#yourkit-ui-をローカル-mule-インスタンスに接続する)YourKit UI をローカル Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Local Applications (ローカルアプリケーションを監視)\] で ​`MuleContainerBootstrap`​ プロセスをダブルクリックします。 ![アプリケーションが PID とプロファイラー状況と共にリストされているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/profiling-mule-286a5.png) 3. YourKit が Mule インスタンスに接続されていることを確認します。 ![メソッドのパフォーマンスが表示されている YourKit Java プロファイラーの詳細な CPU プロファイリングインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/yourkit-hooked-up.png) ### [](#yourkit-ui-をリモート-mule-インスタンスに接続する)YourKit UI をリモート Mule インスタンスに接続する 1. ローカルマシンで YourKit を起動します。 2. \[Monitor Remote Applications (リモートアプリケーションを監視)\] で ​**\[Connect to remote application (リモートアプリケーションに接続)\]**​ をクリックします。 ![最新の接続の詳細を使用してリモートアプリケーションに接続するオプション](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/monitor-remote-apps.png) 3. サーバーのユーザー名とパスワードをセットアップします。 4. SSH 認証を設定します: ![YourKit の SSH 認証ダイアログ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/yourkit-auth.png) 5. **\[OK\]**​ をクリックします。 6. 使用可能なアプリケーションをスキャンした後で、YourKit は Mule インスタンスに接続されます。 ![メソッドのパフォーマンスが表示されている YourKit Java プロファイラーの詳細な CPU プロファイリングインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/yourkit-hooked-up.png) ## [](#アタッチモードでのプロファイラーエージェントの実行)アタッチモードでのプロファイラーエージェントの実行 この方法では、YourKit プロファイラーをダウンロードしてアタッチモードで実行されるようにそのエージェントを設定します。プロセスを完了するには、プロファイラーを実行します。アタッチモードで実行すると、実行中の Mule インスタンスを再起動せずにプロファイリングできます。 このタスクのステップは、環境に応じて異なります。ここで紹介している例が当てはまらない場合、YourKit ドキュメントを参照してください。 1. プロファイラーを Mule インスタンスに [ダウンロード](https://www.yourkit.com/java/profiler/download/)​します。 2. プロファイラーのパッケージを展開します。 3. `jps`​ を実行して Mule の PID を判断します。 ```console jps ``` 4. `MuleContainerBootstrap`​ の PID を取得します。 2838 MuleContainerBootstrap 21311 Jps 5. YourKit パッケージ内で、​`bin`​ ディレクトリを開きます。 ```console cd yjp-2015-build-15086/bin ``` 6. `MuleContainerBootstrap`​ の PID を含む ​`-attach`​ フラグを含めて、​`yph.sh`​ を実行します。 ```console ./yph.sh -attach 2838 ``` 7. エージェントがアタッチされていることを確認します。 ```console Attaching to process 2838 using default options The profiler agent has attached. Waiting while it initializes... The agent is loaded and is listening on port 10001. You can connect to it from the profiler UI. ``` ## [](#関連情報)関連情報 [YourKit](https://www.yourkit.com/) # Mule の起動と停止 Mule Runtime Engine を起動および停止して Mule アプリケーションをデプロイする方法を説明します。管理機能および監視機能を最大限に活用するために、Anypoint Runtime Manager を使用して同じ Mule インスタンスにデプロイできます。 Mule は Java サービスラッパーを使用してネイティブ OS から Java 仮想マシン (JVM) を制御します。ラッパーには Mule を Unix デーモンとして実行する機能や Mule を Windows サービスとしてインストールまたは削除する機能を含めて、多くのオプションと機能があります。ラッパーはシステムシグナルを処理してパラメーターを開始するため、全体的に JVM と基礎となる OS 間のインタラクションが大幅に向上します。 ## [](#スクリプトの起動とシャットダウン)スクリプトの起動とシャットダウン ラッパーは ​`$MULE_HOME/bin`​ のスクリプトによってコールされます。 次の表に、スクリプトが受け入れるすべてのパラメーターを示します。
パラメーター 説明

start

ターミナルのバックグラウンドで Mule を起動します。

stop

Mule を停止します。インバウンドエンドポイントは Mule がシャットダウンする前にインフライトメッセージを処理します。ただし、タイムアウト期間後に、完了していないインフライトメッセージが破棄され、Mule がシャットダウンします。

restart

Mule を再起動します。

status

(Linux/Unix のみ)​。Mule サーバー (​running​ または ​not running​) および実行している場合はプロセスの PID の状況を表示します。

dump

(Linux/Unix のみ)​。Mule ラッパーのコアを ​$MULE_HOME/log/mule_ee.log​ にダンプします。

console

ターミナルのフォアグラウンドで Mule を起動します (コンソールモード)。パラメーターを指定せずに ​mule​ を実行するのと同じです。

install

Mule を Windows サービスまたは Linux/Unix デーモンとしてインストールします。

remove

Mule を Windows サービスまたは Linux/Unix デーモンから削除します。
## [](#mule-の起動)Mule の起動 Mule ソフトウェア配布物を展開した場所にディレクトリを変更してから bin ディレクトリに変更して、コマンドラインから Mule を起動します。次のコマンドを実行します。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat ``` - Linux/Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#windows-サービスとしての-mule-の起動)Windows サービスとしての Mule の起動 Windows サービスとして Mule を実行するには、まず次のように実行して Mule をインストールします。 ```powershell $ $MULE_HOME\bin\mule.bat install ``` インストール後、Mule をサービスとして実行することができます。 ```powershell $ $MULE_HOME\bin\mule.bat start ```

Windows が再起動すると、​mule stop​ コマンドを使用した場合と同じように Mule サービスが停止します。 唯一異なる状況は、Windows がタイムアウトによってプロセスをキルした場合です。
### [](#インストール後のプロパティの-wrapper-conf-ファイルへの追加)インストール後のプロパティの wrapper.conf ファイルへの追加 Mule を Windows サービスとしてインストールした後で、​`wrapper.additional.conf`​ ファイルで新しいプロパティを宣言することで ​`wrapper.conf`​ ファイルのプロパティを上書きできます。 使用している Mule エディションによって動作が異なります。 - Mule Community Edition 1. 新しいプロパティを追加したら、Windows サービスを再インストールまたは再起動します。 2. プロパティを追加し、そのインデックスが ​`wrapper-additional.conf`​ ファイルの最大インデックスより大きいことを確認します。そうでなければ、プロパティは上書きされません。 たとえば、​`wrapper-additional.conf`​ に次のプロパティがあるとします。 `wrapper.java.additional.n=-Dproperty=value` `n`​ が最大のインデックスであれば、​`wrapper.conf`​ ファイルにはインデックスを増やしてプロパティを追加する必要があります。 `wrapper.java.additional.n+1=-DyourProperty=valueOfYourProperty` - Mule Enterprise Edition 1. デフォルトでは、Mule をサービスとしてインストールした後で 20 個のプロパティを追加できます。 2. サービスをインストールする際に、次のコマンドライン引数を使用して、必要な追加プロパティを設定します。 `-additionalJavaProperties=numberOfExtraProperties` ## [](#linuxunix-デーモンとしての-mule-の起動)Linux/Unix デーモンとしての Mule の起動 Mule を Linux/Unix デーモンとして実行するには、まず次のように実行して Mule をインストールします。 ```console $ $MULE_HOME/bin/mule install ``` インストール後、Mule をデーモンとして実行することができます。 ```console $ $MULE_HOME/bin/mule start ```

また、インストールせずに Mule を実行することもできます。この場合は、現在のユーザーセッションのバックグラウンドとして Mule が起動します。
次の例では、Mule を Unix コンソールから起動しています。 ```console $ $MULE_HOME/bin/mule start MULE_HOME is set to ~/Downloads/mule-enterprise-standalone-4.3.0 MULE_BASE is set to ~/Downloads/mule-enterprise-standalone-4.3.0 Starting Mule Enterprise Edition... Waiting for Mule Enterprise Edition................. running: PID:87318 ``` ## [](#スクリプトからの-mule-の起動)スクリプトからの Mule の起動 Java サービスラッパーを使用せずに Mule をスクリプトまたは IDE から起動するために、​`org.mule.MuleServer`​ クラスを使用できます。このクラスはいくつかのパラメーターを受け入れます。 org.mule.MuleServer -config mule-config.xml または org.mule.MuleServer -builder -config appContext.xml - **\-config**​ は使用する 1 つ以上の設定ファイルを指定します。この引数を省略した場合、​`mule-config.xml`​ が存在する場合はこれを探して使用します。 - **\-builder**​ は使用する設定ビルダーの完全修飾されたクラス名です。この引数を設定しなかった場合、デフォルトの ​`org.mule.config.builders.AutoConfigurationBuilder`​ が使用され、使用可能なビルダーに基づいて設定ファイルの自動検出を試みます。最も一般的なシナリオでは、これは ​`org.mule.config.spring.SpringXmlConfigurationBuilder`​ に解決されます。 クラスパスを設定する最も簡単な方法は、配布の ​`./lib/mule`​ ディレクトリと ​`./lib/opt`​ ディレクトリにすべての JAR を含めることです。サーバーと各モジュールの連動関係レポートを確認して、どの JAR が特定のモジュールに必要かを正確に把握できます。 ## [](#mule-アプリケーションのデプロイ)Mule アプリケーションのデプロイ 1. Mule を起動します。 2. Mule が起動したら、パッケージ化された JAR ファイルを ​`$MULE_HOME`​ の下にある ​`apps`​ ディレクトリに移動することで、Mule アプリケーションをデプロイできます。 ## [](#mule-の停止)Mule の停止 Mule を停止するには ​`stop`​ コマンドを実行します。 次の例では、Mule を Unix コンソールから停止しています。 ```console $ $MULE_HOME/bin/mule stop MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Stopping Mule Enterprise Edition... Stopped Mule Enterprise Edition. ``` ## [](#mule-サービスまたはデーモンの削除)Mule サービスまたはデーモンの削除 システムからサービスまたはデーモンを削除するには、​`remove`​ コマンドを実行します。 次の例では、Mule デーモンを Unix コンソールから削除しています。 ```console $ $MULE_HOME/bin/mule remove MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Detected Mac OSX: Mule Enterprise Edition is not running. Removing Mule Enterprise Edition daemon... ``` ## [](#anypoint-monitoring-の有効化)Anypoint Monitoring の有効化 必要に応じて、オンプレミスランタイムのクラウド管理対応バージョン用の ​[Anypoint Monitoring をインストール](https://docs.mulesoft.com/jp/monitoring/am-installing)​して、サーバー上で動作するアプリケーションを監視できます。 ## [](#関連情報)関連情報 - [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/am-installing) - [Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule を開始するときにシステムプロパティを設定する](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-app-properties-system#set-properties) # Mule の起動と停止 Mule Runtime Engine を起動および停止して Mule アプリケーションをデプロイする方法を説明します。管理機能および監視機能を最大限に活用するために、Anypoint Runtime Manager を使用して同じ Mule インスタンスにデプロイできます。 Mule は Java サービスラッパーを使用してネイティブ OS から Java 仮想マシン (JVM) を制御します。ラッパーには Mule を Unix デーモンとして実行する機能や Mule を Windows サービスとしてインストールまたは削除する機能を含めて、多くのオプションと機能があります。ラッパーはシステムシグナルを処理してパラメーターを開始するため、全体的に JVM と基礎となる OS 間のインタラクションが大幅に向上します。 ## [](#スクリプトの起動とシャットダウン)スクリプトの起動とシャットダウン ラッパーは ​`$MULE_HOME/bin`​ のスクリプトによってコールされます。 次の表に、スクリプトが受け入れるすべてのパラメーターを示します。
パラメーター 説明

start

ターミナルのバックグラウンドで Mule を起動します。

stop

Mule を停止します。インバウンドエンドポイントは Mule がシャットダウンする前にインフライトメッセージを処理します。ただし、タイムアウト期間後に、完了していないインフライトメッセージが破棄され、Mule がシャットダウンします。

restart

Mule を再起動します。

status

(Linux/Unix のみ)​。Mule サーバー (​running​ または ​not running​) および実行している場合はプロセスの PID の状況を表示します。

dump

(Linux/Unix のみ)​。Mule ラッパーのコアを ​$MULE_HOME/log/mule_ee.log​ にダンプします。

console

ターミナルのフォアグラウンドで Mule を起動します (コンソールモード)。パラメーターを指定せずに ​mule​ を実行するのと同じです。

install

Mule を Windows サービスまたは Linux/Unix デーモンとしてインストールします。

remove

Mule を Windows サービスまたは Linux/Unix デーモンから削除します。
## [](#mule-の起動)Mule の起動 Mule ソフトウェア配布物を展開した場所にディレクトリを変更してから bin ディレクトリに変更して、コマンドラインから Mule を起動します。次のコマンドを実行します。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat ``` - Linux/Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#windows-サービスとしての-mule-の起動)Windows サービスとしての Mule の起動 Windows サービスとして Mule を実行するには、まず次のように実行して Mule をインストールします。 ```powershell $ $MULE_HOME\bin\mule.bat install ``` インストール後、Mule をサービスとして実行することができます。 ```powershell $ $MULE_HOME\bin\mule.bat start ```

Windows が再起動すると、​mule stop​ コマンドを使用した場合と同じように Mule サービスが停止します。 唯一異なる状況は、Windows がタイムアウトによってプロセスをキルした場合です。
## [](#linuxunix-デーモンとしての-mule-の起動)Linux/Unix デーモンとしての Mule の起動 Mule を Linux/Unix デーモンとして実行するには、まず次のように実行して Mule をインストールします。 ```console $ $MULE_HOME/bin/mule install ``` インストール後、Mule をデーモンとして実行することができます。 ```console $ $MULE_HOME/bin/mule start ```

現在のユーザーセッションのバックグラウンドで Mule を起動するこのインストールステップを実行せずに Mule を起動することもできます。
次の例では、Mule を Unix コンソールから起動しています。 ```console $ $MULE_HOME/bin/mule start MULE_HOME is set to ~/Downloads/mule-enterprise-standalone-4.3.0 MULE_BASE is set to ~/Downloads/mule-enterprise-standalone-4.3.0 Starting Mule Enterprise Edition... Waiting for Mule Enterprise Edition................. running: PID:87318 ``` ## [](#スクリプトからの-mule-の起動)スクリプトからの Mule の起動 Java サービスラッパーを使用せずに Mule をスクリプトまたは IDE から起動するために、​`org.mule.MuleServer`​ クラスを使用できます。このクラスはいくつかのパラメーターを受け入れます。 org.mule.MuleServer -config mule-config.xml または org.mule.MuleServer -builder -config appContext.xml - **\-config**​ は使用する 1 つ以上の設定ファイルを指定します。この引数を省略した場合、​`mule-config.xml`​ が存在する場合はこれを探して使用します。 - **\-builder**​ は使用する設定ビルダーの完全修飾されたクラス名です。この引数を設定しなかった場合、デフォルトの ​`org.mule.config.builders.AutoConfigurationBuilder`​ が使用され、使用可能なビルダーに基づいて設定ファイルの自動検出を試みます。最も一般的なシナリオでは、これは ​`org.mule.config.spring.SpringXmlConfigurationBuilder`​ に解決されます。 クラスパスを設定する最も簡単な方法は、配布の ​`./lib/mule`​ ディレクトリと ​`./lib/opt`​ ディレクトリにすべての JAR を含めることです。サーバーと各モジュールの連動関係レポートを確認して、どの JAR が特定のモジュールに必要かを正確に把握できます。 ## [](#mule-の停止)Mule の停止 Mule を停止するには ​`stop`​ コマンドを実行します。 次の例では、Mule を Unix コンソールから停止しています。 ```console $ $MULE_HOME/bin/mule stop MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Stopping Mule Enterprise Edition... Stopped Mule Enterprise Edition. ``` ## [](#関連情報)関連情報 - [Mule のダウンロード、インストール、設定、アップグレード](https://docs.mulesoft.com/on-premises/latest/runtime-installation-task) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/am-installing) - [Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule を開始するときにシステムプロパティを設定する](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-app-properties-system#set-properties) # Mule の起動と停止 Mule Runtime Engine を起動および停止して Mule アプリケーションをデプロイする方法を説明します。管理機能および監視機能を最大限に活用するために、Anypoint Runtime Manager を使用して同じ Mule インスタンスにデプロイできます。 Mule は Java サービスラッパーを使用してネイティブ OS から Java 仮想マシン (JVM) を制御します。ラッパーには Mule を Unix デーモンとして実行する機能や Mule を Windows サービスとしてインストールまたは削除する機能を含めて、多くのオプションと機能があります。ラッパーはシステムシグナルを処理してパラメーターを開始するため、全体的に JVM と基礎となる OS 間のインタラクションが大幅に向上します。 ## [](#スクリプトの起動とシャットダウン)スクリプトの起動とシャットダウン ラッパーは ​`$MULE_HOME/bin`​ のスクリプトによってコールされます。 次の表に、スクリプトが受け入れるすべてのパラメーターを示します。
パラメーター 説明

start

ターミナルのバックグラウンドで Mule を起動します。

stop

Mule を停止します。インバウンドエンドポイントは Mule がシャットダウンする前にインフライトメッセージを処理します。ただし、タイムアウト期間後に、完了していないインフライトメッセージが破棄され、Mule がシャットダウンします。

restart

Mule を再起動します。

status

(Linux/Unix のみ)​。Mule サーバー (​running​ または ​not running​) および実行している場合はプロセスの PID の状況を表示します。

dump

(Linux/Unix のみ)​。Mule ラッパーのコアを ​$MULE_HOME/log/mule_ee.log​ にダンプします。

console

ターミナルのフォアグラウンドで Mule を起動します (コンソールモード)。パラメーターを指定せずに ​mule​ を実行するのと同じです。

install

Mule を Windows サービスまたは Linux/Unix デーモンとしてインストールします。

remove

Mule を Windows サービスまたは Linux/Unix デーモンから削除します。
## [](#mule-の起動)Mule の起動 Mule ソフトウェア配布物を展開した場所にディレクトリを変更してから bin ディレクトリに変更して、コマンドラインから Mule を起動します。次のコマンドを実行します。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat ``` - Linux/Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#windows-サービスとしての-mule-の起動)Windows サービスとしての Mule の起動 Windows サービスとして Mule を実行するには、まず次のように実行して Mule をインストールします。 ```powershell $ $MULE_HOME\bin\mule.bat install ``` インストール後、Mule をサービスとして実行することができます。 ```powershell $ $MULE_HOME\bin\mule.bat start ```

Windows が再起動すると、​mule stop​ コマンドを使用した場合と同じように Mule サービスが停止します。 唯一異なる状況は、Windows がタイムアウトによってプロセスをキルした場合です。
## [](#linuxunix-デーモンとしての-mule-の起動)Linux/Unix デーモンとしての Mule の起動 Mule を Linux/Unix デーモンとして実行するには、まず次のように実行して Mule をインストールします。 ```console $ $MULE_HOME/bin/mule install ``` インストール後、Mule をデーモンとして実行することができます。 ```console $ $MULE_HOME/bin/mule start ```

現在のユーザーセッションのバックグラウンドで Mule を起動するこのインストールステップを実行せずに Mule を起動することもできます。
次の例では、Mule を Unix コンソールから起動しています。 ```console $ $MULE_HOME/bin/mule start MULE_HOME is set to ~/Downloads/mule-enterprise-standalone-4.3.0 MULE_BASE is set to ~/Downloads/mule-enterprise-standalone-4.3.0 Starting Mule Enterprise Edition... Waiting for Mule Enterprise Edition................. running: PID:87318 ``` ## [](#スクリプトからの-mule-の起動)スクリプトからの Mule の起動 Java サービスラッパーを使用せずに Mule をスクリプトまたは IDE から起動するために、​`org.mule.MuleServer`​ クラスを使用できます。このクラスはいくつかのパラメーターを受け入れます。 org.mule.MuleServer -config mule-config.xml または org.mule.MuleServer -builder -config appContext.xml - **\-config**​ は使用する 1 つ以上の設定ファイルを指定します。この引数を省略した場合、​`mule-config.xml`​ が存在する場合はこれを探して使用します。 - **\-builder**​ は使用する設定ビルダーの完全修飾されたクラス名です。この引数を設定しなかった場合、デフォルトの ​`org.mule.config.builders.AutoConfigurationBuilder`​ が使用され、使用可能なビルダーに基づいて設定ファイルの自動検出を試みます。最も一般的なシナリオでは、これは ​`org.mule.config.spring.SpringXmlConfigurationBuilder`​ に解決されます。 クラスパスを設定する最も簡単な方法は、配布の ​`./lib/mule`​ ディレクトリと ​`./lib/opt`​ ディレクトリにすべての JAR を含めることです。サーバーと各モジュールの連動関係レポートを確認して、どの JAR が特定のモジュールに必要かを正確に把握できます。 ## [](#mule-の停止)Mule の停止 Mule を停止するには ​`stop`​ コマンドを実行します。 次の例では、Mule を Unix コンソールから停止しています。 ```console $ $MULE_HOME/bin/mule stop MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Stopping Mule Enterprise Edition... Stopped Mule Enterprise Edition. ``` ## [](#関連情報)関連情報 - [Mule のダウンロード、インストール、設定、アップグレード](https://docs.mulesoft.com/on-premises/latest/runtime-installation-task) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/am-installing) - [Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule を開始するときにシステムプロパティを設定する](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-app-properties-system#set-properties) # Mule の起動と停止 Mule Runtime Engine を起動および停止して Mule アプリケーションをデプロイする方法を説明します。管理機能および監視機能を最大限に活用するために、Anypoint Runtime Manager を使用して同じ Mule インスタンスにデプロイできます。 Mule は Java サービスラッパーを使用してネイティブ OS から Java 仮想マシン (JVM) を制御します。ラッパーには Mule を Unix デーモンとして実行する機能や Mule を Windows サービスとしてインストールまたは削除する機能を含めて、多くのオプションと機能があります。ラッパーはシステムシグナルを処理してパラメーターを開始するため、全体的に JVM と基礎となる OS 間のインタラクションが大幅に向上します。 ## [](#スクリプトの起動とシャットダウン)スクリプトの起動とシャットダウン ラッパーは ​`$MULE_HOME/bin`​ のスクリプトによってコールされます。 次の表に、スクリプトが受け入れるすべてのパラメーターを示します。
パラメーター 説明

start

ターミナルのバックグラウンドで Mule を起動します。

stop

Mule を停止します。インバウンドエンドポイントは Mule がシャットダウンする前にインフライトメッセージを処理します。ただし、タイムアウト期間後に、完了していないインフライトメッセージが破棄され、Mule がシャットダウンします。

restart

Mule を再起動します。

status

(Linux/Unix のみ)​。Mule サーバー (​running​ または ​not running​) および実行している場合はプロセスの PID の状況を表示します。

dump

(Linux/Unix のみ)​。Mule ラッパーのコアを ​$MULE_HOME/log/mule_ee.log​ にダンプします。

console

ターミナルのフォアグラウンドで Mule を起動します (コンソールモード)。パラメーターを指定せずに ​mule​ を実行するのと同じです。

install

Mule を Windows サービスまたは Linux/Unix デーモンとしてインストールします。

remove

Mule を Windows サービスまたは Linux/Unix デーモンから削除します。
## [](#mule-の起動)Mule の起動 Mule ソフトウェア配布物を展開した場所にディレクトリを変更してから bin ディレクトリに変更して、コマンドラインから Mule を起動します。次のコマンドを実行します。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat ``` - Linux/Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#windows-サービスとしての-mule-の起動)Windows サービスとしての Mule の起動 Windows サービスとして Mule を実行するには、まず次のように実行して Mule をインストールします。 ```powershell $ $MULE_HOME\bin\mule.bat install ``` インストール後、Mule をサービスとして実行することができます。 ```powershell $ $MULE_HOME\bin\mule.bat start ```

Windows が再起動すると、​mule stop​ コマンドを使用した場合と同じように Mule サービスが停止します。 唯一異なる状況は、Windows がタイムアウトによってプロセスをキルした場合です。
## [](#linuxunix-デーモンとしての-mule-の起動)Linux/Unix デーモンとしての Mule の起動 Mule を Linux/Unix デーモンとして実行するには、まず次のように実行して Mule をインストールします。 ```console $ $MULE_HOME/bin/mule install ``` インストール後、Mule をデーモンとして実行することができます。 ```console $ $MULE_HOME/bin/mule start ```

現在のユーザーセッションのバックグラウンドで Mule を起動するこのインストールステップを実行せずに Mule を起動することもできます。
次の例では、Mule を Unix コンソールから起動しています。 ```console $ $MULE_HOME/bin/mule start MULE_HOME is set to ~/Downloads/mule-enterprise-standalone-4.3.0 MULE_BASE is set to ~/Downloads/mule-enterprise-standalone-4.3.0 Starting Mule Enterprise Edition... Waiting for Mule Enterprise Edition................. running: PID:87318 ``` ## [](#スクリプトからの-mule-の起動)スクリプトからの Mule の起動 Java サービスラッパーを使用せずに Mule をスクリプトまたは IDE から起動するために、​`org.mule.MuleServer`​ クラスを使用できます。このクラスはいくつかのパラメーターを受け入れます。 org.mule.MuleServer -config mule-config.xml または org.mule.MuleServer -builder -config appContext.xml - **\-config**​ は使用する 1 つ以上の設定ファイルを指定します。この引数を省略した場合、​`mule-config.xml`​ が存在する場合はこれを探して使用します。 - **\-builder**​ は使用する設定ビルダーの完全修飾されたクラス名です。この引数を設定しなかった場合、デフォルトの ​`org.mule.config.builders.AutoConfigurationBuilder`​ が使用され、使用可能なビルダーに基づいて設定ファイルの自動検出を試みます。最も一般的なシナリオでは、これは ​`org.mule.config.spring.SpringXmlConfigurationBuilder`​ に解決されます。 クラスパスを設定する最も簡単な方法は、配布の ​`./lib/mule`​ ディレクトリと ​`./lib/opt`​ ディレクトリにすべての JAR を含めることです。サーバーと各モジュールの連動関係レポートを確認して、どの JAR が特定のモジュールに必要かを正確に把握できます。 ## [](#mule-の停止)Mule の停止 Mule を停止するには ​`stop`​ コマンドを実行します。 次の例では、Mule を Unix コンソールから停止しています。 ```console $ $MULE_HOME/bin/mule stop MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Stopping Mule Enterprise Edition... Stopped Mule Enterprise Edition. ``` ## [](#関連情報)関連情報 - [Mule のダウンロード、インストール、設定、アップグレード](https://docs.mulesoft.com/on-premises/latest/runtime-installation-task) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/am-installing) - [Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule を開始するときにシステムプロパティを設定する](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-app-properties-system#set-properties) # Mule の起動と停止 Mule Runtime Engine を起動および停止して Mule アプリケーションをデプロイする方法を説明します。管理機能および監視機能を最大限に活用するために、Anypoint Runtime Manager を使用して同じ Mule インスタンスにデプロイできます。 Mule は Java サービスラッパーを使用してネイティブ OS から Java 仮想マシン (JVM) を制御します。ラッパーには Mule を Unix デーモンとして実行する機能や Mule を Windows サービスとしてインストールまたは削除する機能を含めて、多くのオプションと機能があります。ラッパーはシステムシグナルを処理してパラメーターを開始するため、全体的に JVM と基礎となる OS 間のインタラクションが大幅に向上します。 ## [](#スクリプトの起動とシャットダウン)スクリプトの起動とシャットダウン ラッパーは ​`$MULE_HOME/bin`​ のスクリプトによってコールされます。 次の表に、スクリプトが受け入れるすべてのパラメーターを示します。
パラメーター 説明

start

ターミナルのバックグラウンドで Mule を起動します。

stop

Mule を停止します。インバウンドエンドポイントは Mule がシャットダウンする前にインフライトメッセージを処理します。ただし、タイムアウト期間後に、完了していないインフライトメッセージが破棄され、Mule がシャットダウンします。

restart

Mule を再起動します。

status

(Linux/Unix のみ)​。Mule サーバー (​running​ または ​not running​) および実行している場合はプロセスの PID の状況を表示します。

dump

(Linux/Unix のみ)​。Mule ラッパーのコアを ​$MULE_HOME/log/mule_ee.log​ にダンプします。

console

ターミナルのフォアグラウンドで Mule を起動します (コンソールモード)。パラメーターを指定せずに ​mule​ を実行するのと同じです。

install

Mule を Windows サービスまたは Linux/Unix デーモンとしてインストールします。

remove

Mule を Windows サービスまたは Linux/Unix デーモンから削除します。
## [](#mule-の起動)Mule の起動 Mule ソフトウェア配布物を展開した場所にディレクトリを変更してから bin ディレクトリに変更して、コマンドラインから Mule を起動します。次のコマンドを実行します。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat ``` - Linux/Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#windows-サービスとしての-mule-の起動)Windows サービスとしての Mule の起動 Windows サービスとして Mule を実行するには、まず次のように実行して Mule をインストールします。 ```powershell $ $MULE_HOME\bin\mule.bat install ``` インストール後、Mule をサービスとして実行することができます。 ```powershell $ $MULE_HOME\bin\mule.bat start ```

Windows が再起動すると、​mule stop​ コマンドを使用した場合と同じように Mule サービスが停止します。 唯一異なる状況は、Windows がタイムアウトによってプロセスをキルした場合です。
## [](#linuxunix-デーモンとしての-mule-の起動)Linux/Unix デーモンとしての Mule の起動 Mule を Linux/Unix デーモンとして実行するには、まず次のように実行して Mule をインストールします。 ```console $ $MULE_HOME/bin/mule install ``` インストール後、Mule をデーモンとして実行することができます。 ```console $ $MULE_HOME/bin/mule start ```

現在のユーザーセッションのバックグラウンドで Mule を起動するこのインストールステップを実行せずに Mule を起動することもできます。
次の例では、Mule を Unix コンソールから起動しています。 ```console $ $MULE_HOME/bin/mule start MULE_HOME is set to ~/Downloads/mule-enterprise-standalone-4.3.0 MULE_BASE is set to ~/Downloads/mule-enterprise-standalone-4.3.0 Starting Mule Enterprise Edition... Waiting for Mule Enterprise Edition................. running: PID:87318 ``` ## [](#スクリプトからの-mule-の起動)スクリプトからの Mule の起動 Java サービスラッパーを使用せずに Mule をスクリプトまたは IDE から起動するために、​`org.mule.MuleServer`​ クラスを使用できます。このクラスはいくつかのパラメーターを受け入れます。 org.mule.MuleServer -config mule-config.xml または org.mule.MuleServer -builder -config appContext.xml - **\-config**​ は使用する 1 つ以上の設定ファイルを指定します。この引数を省略した場合、​`mule-config.xml`​ が存在する場合はこれを探して使用します。 - **\-builder**​ は使用する設定ビルダーの完全修飾されたクラス名です。この引数を設定しなかった場合、デフォルトの ​`org.mule.config.builders.AutoConfigurationBuilder`​ が使用され、使用可能なビルダーに基づいて設定ファイルの自動検出を試みます。最も一般的なシナリオでは、これは ​`org.mule.config.spring.SpringXmlConfigurationBuilder`​ に解決されます。 クラスパスを設定する最も簡単な方法は、配布の ​`./lib/mule`​ ディレクトリと ​`./lib/opt`​ ディレクトリにすべての JAR を含めることです。サーバーと各モジュールの連動関係レポートを確認して、どの JAR が特定のモジュールに必要かを正確に把握できます。 ## [](#mule-の停止)Mule の停止 Mule を停止するには ​`stop`​ コマンドを実行します。 次の例では、Mule を Unix コンソールから停止しています。 ```console $ $MULE_HOME/bin/mule stop MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Stopping Mule Enterprise Edition... Stopped Mule Enterprise Edition. ``` ## [](#関連情報)関連情報 - [Mule のダウンロード、インストール、設定、アップグレード](https://docs.mulesoft.com/on-premises/latest/runtime-installation-task) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/am-installing) - [Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule を開始するときにシステムプロパティを設定する](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-app-properties-system#set-properties) # Mule の起動と停止 Mule Runtime Engine を起動および停止して Mule アプリケーションをデプロイする方法を説明します。管理機能および監視機能を最大限に活用するために、Anypoint Runtime Manager を使用して同じ Mule インスタンスにデプロイできます。 Mule は Java サービスラッパーを使用してネイティブ OS から Java 仮想マシン (JVM) を制御します。ラッパーには Mule を Unix デーモンとして実行する機能や Mule を Windows サービスとしてインストールまたは削除する機能を含めて、多くのオプションと機能があります。ラッパーはシステムシグナルを処理してパラメーターを開始するため、全体的に JVM と基礎となる OS 間のインタラクションが大幅に向上します。 ## [](#スクリプトの起動とシャットダウン)スクリプトの起動とシャットダウン ラッパーは ​`$MULE_HOME/bin`​ のスクリプトによってコールされます。 次の表に、スクリプトが受け入れるすべてのパラメーターを示します。
パラメーター 説明

start

ターミナルのバックグラウンドで Mule を起動します。

stop

Mule を停止します。インバウンドエンドポイントは Mule がシャットダウンする前にインフライトメッセージを処理します。ただし、タイムアウト期間後に、完了していないインフライトメッセージが破棄され、Mule がシャットダウンします。

restart

Mule を再起動します。

status

(Linux/Unix のみ)​。Mule サーバー (​running​ または ​not running​) および実行している場合はプロセスの PID の状況を表示します。

dump

(Linux/Unix のみ)​。Mule ラッパーのコアを ​$MULE_HOME/log/mule_ee.log​ にダンプします。

console

ターミナルのフォアグラウンドで Mule を起動します (コンソールモード)。パラメーターを指定せずに ​mule​ を実行するのと同じです。

install

Mule を Windows サービスまたは Linux/Unix デーモンとしてインストールします。

remove

Mule を Windows サービスまたは Linux/Unix デーモンから削除します。
## [](#mule-の起動)Mule の起動 Mule ソフトウェア配布物を展開した場所にディレクトリを変更してから bin ディレクトリに変更して、コマンドラインから Mule を起動します。次のコマンドを実行します。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat ``` - Linux/Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#windows-サービスとしての-mule-の起動)Windows サービスとしての Mule の起動 Windows サービスとして Mule を実行するには、まず次のように実行して Mule をインストールします。 ```powershell $ $MULE_HOME\bin\mule.bat install ``` インストール後、Mule をサービスとして実行することができます。 ```powershell $ $MULE_HOME\bin\mule.bat start ```

Windows が再起動すると、​mule stop​ コマンドを使用した場合と同じように Mule サービスが停止します。 唯一異なる状況は、Windows がタイムアウトによってプロセスをキルした場合です。
## [](#linuxunix-デーモンとしての-mule-の起動)Linux/Unix デーモンとしての Mule の起動 Mule を Linux/Unix デーモンとして実行するには、まず次のように実行して Mule をインストールします。 ```console $ $MULE_HOME/bin/mule install ``` インストール後、Mule をデーモンとして実行することができます。 ```console $ $MULE_HOME/bin/mule start ```

現在のユーザーセッションのバックグラウンドで Mule を起動するこのインストールステップを実行せずに Mule を起動することもできます。
次の例では、Mule を Unix コンソールから起動しています。 ```console $ $MULE_HOME/bin/mule start MULE_HOME is set to ~/Downloads/mule-enterprise-standalone-4.3.0 MULE_BASE is set to ~/Downloads/mule-enterprise-standalone-4.3.0 Starting Mule Enterprise Edition... Waiting for Mule Enterprise Edition................. running: PID:87318 ``` ## [](#スクリプトからの-mule-の起動)スクリプトからの Mule の起動 Java サービスラッパーを使用せずに Mule をスクリプトまたは IDE から起動するために、​`org.mule.MuleServer`​ クラスを使用できます。このクラスはいくつかのパラメーターを受け入れます。 org.mule.MuleServer -config mule-config.xml または org.mule.MuleServer -builder -config appContext.xml - **\-config**​ は使用する 1 つ以上の設定ファイルを指定します。この引数を省略した場合、​`mule-config.xml`​ が存在する場合はこれを探して使用します。 - **\-builder**​ は使用する設定ビルダーの完全修飾されたクラス名です。この引数を設定しなかった場合、デフォルトの ​`org.mule.config.builders.AutoConfigurationBuilder`​ が使用され、使用可能なビルダーに基づいて設定ファイルの自動検出を試みます。最も一般的なシナリオでは、これは ​`org.mule.config.spring.SpringXmlConfigurationBuilder`​ に解決されます。 クラスパスを設定する最も簡単な方法は、配布の ​`./lib/mule`​ ディレクトリと ​`./lib/opt`​ ディレクトリにすべての JAR を含めることです。サーバーと各モジュールの連動関係レポートを確認して、どの JAR が特定のモジュールに必要かを正確に把握できます。 ## [](#mule-の停止)Mule の停止 Mule を停止するには ​`stop`​ コマンドを実行します。 次の例では、Mule を Unix コンソールから停止しています。 ```console $ $MULE_HOME/bin/mule stop MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Stopping Mule Enterprise Edition... Stopped Mule Enterprise Edition. ``` ## [](#関連情報)関連情報 - [Mule のダウンロード、インストール、設定、アップグレード](https://docs.mulesoft.com/on-premises/latest/runtime-installation-task) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/am-installing) - [Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule を開始するときにシステムプロパティを設定する](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-app-properties-system#set-properties) # Mule の起動と停止 Mule Runtime Engine を起動および停止して Mule アプリケーションをデプロイする方法を説明します。管理機能および監視機能を最大限に活用するために、Anypoint Runtime Manager を使用して同じ Mule インスタンスにデプロイできます。 Mule は Java サービスラッパーを使用してネイティブ OS から Java 仮想マシン (JVM) を制御します。ラッパーには Mule を Unix デーモンとして実行する機能や Mule を Windows サービスとしてインストールまたは削除する機能を含めて、多くのオプションと機能があります。ラッパーはシステムシグナルを処理してパラメーターを開始するため、全体的に JVM と基礎となる OS 間のインタラクションが大幅に向上します。 ## [](#スクリプトの起動とシャットダウン)スクリプトの起動とシャットダウン ラッパーは ​`$MULE_HOME/bin`​ のスクリプトによってコールされます。 次の表に、スクリプトが受け入れるすべてのパラメーターを示します。
パラメーター 説明

start

ターミナルのバックグラウンドで Mule を起動します。

stop

Mule を停止します。インバウンドエンドポイントは Mule がシャットダウンする前にインフライトメッセージを処理します。ただし、タイムアウト期間後に、完了していないインフライトメッセージが破棄され、Mule がシャットダウンします。

restart

Mule を再起動します。

status

(Linux/Unix のみ)​。Mule サーバー (​running​ または ​not running​) および実行している場合はプロセスの PID の状況を表示します。

dump

(Linux/Unix のみ)​。Mule ラッパーのコアを ​$MULE_HOME/log/mule_ee.log​ にダンプします。

console

ターミナルのフォアグラウンドで Mule を起動します (コンソールモード)。パラメーターを指定せずに ​mule​ を実行するのと同じです。

install

Mule を Windows サービスまたは Linux/Unix デーモンとしてインストールします。

remove

Mule を Windows サービスまたは Linux/Unix デーモンから削除します。
## [](#mule-の起動)Mule の起動 Mule ソフトウェア配布物を展開した場所にディレクトリを変更してから bin ディレクトリに変更して、コマンドラインから Mule を起動します。次のコマンドを実行します。 - Windows 環境: ```powershell $ $MULE_HOME\bin\mule.bat ``` - Linux/Unix 環境: ```console $ $MULE_HOME/bin/mule ``` これらのコマンドは、Mule をフォアグラウンドで実行し、起動スクリプトによってターミナルの標準出力に情報が表示されます。Mule の動作中は、他のコマンドを実行することはできません。 Mule を停止するには、スクリプトが動作しているターミナルで ​`CTRL-C`​ を押します。 ## [](#windows-サービスとしての-mule-の起動)Windows サービスとしての Mule の起動 Windows サービスとして Mule を実行するには、まず次のように実行して Mule をインストールします。 ```powershell $ $MULE_HOME\bin\mule.bat install ``` インストール後、Mule をサービスとして実行することができます。 ```powershell $ $MULE_HOME\bin\mule.bat start ```

Windows が再起動すると、​mule stop​ コマンドを使用した場合と同じように Mule サービスが停止します。 唯一異なる状況は、Windows がタイムアウトによってプロセスをキルした場合です。
## [](#linuxunix-デーモンとしての-mule-の起動)Linux/Unix デーモンとしての Mule の起動 Mule を Linux/Unix デーモンとして実行するには、まず次のように実行して Mule をインストールします。 ```console $ $MULE_HOME/bin/mule install ``` インストール後、Mule をデーモンとして実行することができます。 ```console $ $MULE_HOME/bin/mule start ```

現在のユーザーセッションのバックグラウンドで Mule を起動するこのインストールステップを実行せずに Mule を起動することもできます。
次の例では、Mule を Unix コンソールから起動しています。 ```console $ $MULE_HOME/bin/mule start MULE_HOME is set to ~/Downloads/mule-enterprise-standalone-4.3.0 MULE_BASE is set to ~/Downloads/mule-enterprise-standalone-4.3.0 Starting Mule Enterprise Edition... Waiting for Mule Enterprise Edition................. running: PID:87318 ``` ## [](#スクリプトからの-mule-の起動)スクリプトからの Mule の起動 Java サービスラッパーを使用せずに Mule をスクリプトまたは IDE から起動するために、​`org.mule.MuleServer`​ クラスを使用できます。このクラスはいくつかのパラメーターを受け入れます。 org.mule.MuleServer -config mule-config.xml または org.mule.MuleServer -builder -config appContext.xml - **\-config**​ は使用する 1 つ以上の設定ファイルを指定します。この引数を省略した場合、​`mule-config.xml`​ が存在する場合はこれを探して使用します。 - **\-builder**​ は使用する設定ビルダーの完全修飾されたクラス名です。この引数を設定しなかった場合、デフォルトの ​`org.mule.config.builders.AutoConfigurationBuilder`​ が使用され、使用可能なビルダーに基づいて設定ファイルの自動検出を試みます。最も一般的なシナリオでは、これは ​`org.mule.config.spring.SpringXmlConfigurationBuilder`​ に解決されます。 クラスパスを設定する最も簡単な方法は、配布の ​`./lib/mule`​ ディレクトリと ​`./lib/opt`​ ディレクトリにすべての JAR を含めることです。サーバーと各モジュールの連動関係レポートを確認して、どの JAR が特定のモジュールに必要かを正確に把握できます。 ## [](#mule-の停止)Mule の停止 Mule を停止するには ​`stop`​ コマンドを実行します。 次の例では、Mule を Unix コンソールから停止しています。 ```console $ $MULE_HOME/bin/mule stop MULE_HOME is set to /Applications/mule-enterprise-standalone-4.3.0 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.3.0 Stopping Mule Enterprise Edition... Stopped Mule Enterprise Edition. ``` ## [](#関連情報)関連情報 - [Mule のダウンロード、インストール、設定、アップグレード](https://docs.mulesoft.com/on-premises/latest/runtime-installation-task) - [Mule アプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying) - [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/am-installing) - [Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) - [デプロイメント戦略](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [Mule を開始するときにシステムプロパティを設定する](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-app-properties-system#set-properties) # Mule の高度な概念 Mule アプリケーションの開発と Mule Runtime Engine (Mule) の概念の基礎を理解したら、実行エンジン、クラスローディング分離メカニズム、分散ファイルのポーリングなど、より高度な機能に焦点を当てることができます。 Mule Runtime Engine が Mule アプリケーションフロー内で操作を処理する方法や、必要に応じてスレッドプールを変更する方法を理解するには、​[実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.3/execution-engine)​について学習します。Mule Runtime Engine は、フロー内の操作によって提供された実行メタデータを使用して、自動調整を実行します。 Mule 4 に実装されている​[クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-classloading-isolation)​メカニズムでは、コンポーネントがその内部リソースを公開できなくなるため、アップグレードが容易になります。すべてのコンポーネントは、その定義済みの API を介して相互にやり取りするため、他のコンポーネントがアクセスできるのは公開されたリソースのみになります。クラスローディング分離を使用すると、コンポーネントの内部コンテンツが確実に保護されるほか、他のコンポーネントに影響を与えずにいつでもコンポーネントの内部コンテンツを変更できます。 Mule 4 は​[分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.3/distributed-file-polling)​をサポートします。これにより、コネクタはファイルの作成時に特定のディレクトリからファイルを読み取ることができます。また、分散ファイルのポーリングでは、すべてのクラスターノードのファイルをポーリングできます。 Mule 4 は​[分散ロッキング](https://docs.mulesoft.com/jp/mule-runtime/4.3/distributed-locking)​もサポートします。これにより、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。 クラス、項目、データ型の定義を学習するには、Mule Kernel (Mule Runtime Engine の Community Edition) の ​[Javadoc](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-4-api-javadoc)​ を参照してください。 内部の連動関係として Mule Runtime Engine の一部として含まれている​[サードパーティソフトウェア](https://docs.mulesoft.com/jp/mule-runtime/4.3/third-party-software-in-mule)​のリストを参照してください。 # Mule の高度な概念 Mule アプリケーションの開発と Mule Runtime Engine (Mule) の概念の基礎を理解したら、実行エンジン、クラスローディング分離メカニズム、分散ファイルのポーリングなど、より高度な機能に焦点を当てることができます。 Mule Runtime Engine が Mule アプリケーションフロー内で操作を処理する方法や、必要に応じてスレッドプールを変更する方法を理解するには、​[実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.4/execution-engine)​について学習します。Mule Runtime Engine は、フロー内の操作によって提供された実行メタデータを使用して、自動調整を実行します。 Mule 4 に実装されている​[クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-classloading-isolation)​メカニズムでは、コンポーネントがその内部リソースを公開できなくなるため、アップグレードが容易になります。すべてのコンポーネントは、その定義済みの API を介して相互にやり取りするため、他のコンポーネントがアクセスできるのは公開されたリソースのみになります。クラスローディング分離を使用すると、コンポーネントの内部コンテンツが確実に保護されるほか、他のコンポーネントに影響を与えずにいつでもコンポーネントの内部コンテンツを変更できます。 Mule 4 は​[分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.4/distributed-file-polling)​をサポートします。これにより、コネクタはファイルの作成時に特定のディレクトリからファイルを読み取ることができます。また、分散ファイルのポーリングでは、すべてのクラスターノードのファイルをポーリングできます。 Mule 4 は​[分散ロッキング](https://docs.mulesoft.com/jp/mule-runtime/4.4/distributed-locking)​もサポートします。これにより、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。 Mule がさまざまなコンポーネントのデータアクセスを一元化する方法に加え、DataWeave がこの情報を使用して使用するリーダーやライターを決定する方法を理解するには、​[「Mule データ型」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-data-types)​を参照してください。 クラス、項目、データ型の定義を学習するには、Mule Kernel (Mule Runtime Engine の Community Edition) の ​[Javadoc](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-4-api-javadoc)​ を参照してください。 内部の連動関係として Mule Runtime Engine の一部として含まれている​[サードパーティソフトウェア](https://docs.mulesoft.com/jp/mule-runtime/4.4/third-party-software-in-mule)​のリストを参照してください。 # Mule の高度な概念 Mule アプリケーションの開発と Mule Runtime Engine (Mule) の概念の基礎を理解したら、実行エンジン、クラスローディング分離メカニズム、分散ファイルのポーリングなど、より高度な機能に焦点を当てることができます。 Mule Runtime Engine が Mule アプリケーションフロー内で操作を処理する方法や、必要に応じてスレッドプールを変更する方法を理解するには、​[実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.5/execution-engine)​について学習します。Mule Runtime Engine は、フロー内の操作によって提供された実行メタデータを使用して、自動調整を実行します。 Mule 4 に実装されている​[クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-classloading-isolation)​メカニズムでは、コンポーネントがその内部リソースを公開できなくなるため、アップグレードが容易になります。すべてのコンポーネントは、その定義済みの API を介して相互にやり取りするため、他のコンポーネントがアクセスできるのは公開されたリソースのみになります。クラスローディング分離を使用すると、コンポーネントの内部コンテンツが確実に保護されるほか、他のコンポーネントに影響を与えずにいつでもコンポーネントの内部コンテンツを変更できます。 Mule 4 は​[分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.5/distributed-file-polling)​をサポートします。これにより、コネクタはファイルの作成時に特定のディレクトリからファイルを読み取ることができます。また、分散ファイルのポーリングでは、すべてのクラスターノードのファイルをポーリングできます。 Mule 4 は​[分散ロッキング](https://docs.mulesoft.com/jp/mule-runtime/4.5/distributed-locking)​もサポートします。これにより、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。 Mule がさまざまなコンポーネントのデータアクセスを一元化する方法に加え、DataWeave がこの情報を使用して使用するリーダーやライターを決定する方法を理解するには、​[「Mule データ型」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-data-types)​を参照してください。 クラス、項目、データ型の定義を学習するには、Mule Kernel (Mule Runtime Engine の Community Edition) の ​[Javadoc](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-4-api-javadoc)​ を参照してください。 内部の連動関係として Mule Runtime Engine の一部として含まれている​[サードパーティソフトウェア](https://docs.mulesoft.com/jp/mule-runtime/4.5/third-party-software-in-mule)​のリストを参照してください。 # Mule の高度な概念 Mule アプリケーションの開発と Mule Runtime Engine (Mule) の概念の基礎を理解したら、実行エンジン、クラスローディング分離メカニズム、分散ファイルのポーリングなど、より高度な機能に焦点を当てることができます。 Mule Runtime Engine が Mule アプリケーションフロー内で操作を処理する方法や、必要に応じてスレッドプールを変更する方法を理解するには、​[実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.6/execution-engine)​について学習します。Mule Runtime Engine は、フロー内の操作によって提供された実行メタデータを使用して、自動調整を実行します。 Mule 4 に実装されている​[クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-classloading-isolation)​メカニズムでは、コンポーネントがその内部リソースを公開できなくなるため、アップグレードが容易になります。すべてのコンポーネントは、その定義済みの API を介して相互にやり取りするため、他のコンポーネントがアクセスできるのは公開されたリソースのみになります。クラスローディング分離を使用すると、コンポーネントの内部コンテンツが確実に保護されるほか、他のコンポーネントに影響を与えずにいつでもコンポーネントの内部コンテンツを変更できます。 Mule 4 は​[分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.6/distributed-file-polling)​をサポートします。これにより、コネクタはファイルの作成時に特定のディレクトリからファイルを読み取ることができます。また、分散ファイルのポーリングでは、すべてのクラスターノードのファイルをポーリングできます。 Mule 4 は​[分散ロッキング](https://docs.mulesoft.com/jp/mule-runtime/4.6/distributed-locking)​もサポートします。これにより、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。 Mule がさまざまなコンポーネントのデータアクセスを一元化する方法に加え、DataWeave がこの情報を使用して使用するリーダーやライターを決定する方法を理解するには、​[「Mule データ型」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-data-types)​を参照してください。 クラス、項目、データ型の定義を学習するには、Mule Kernel (Mule Runtime Engine の Community Edition) の ​[Javadoc](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-4-api-javadoc)​ を参照してください。 内部の連動関係として Mule Runtime Engine の一部として含まれている​[サードパーティソフトウェア](https://docs.mulesoft.com/jp/mule-runtime/4.6/third-party-software-in-mule)​のリストを参照してください。 # Mule の高度な概念 Mule アプリケーションの開発と Mule Runtime Engine (Mule) の概念の基礎を理解したら、実行エンジン、クラスローディング分離メカニズム、分散ファイルのポーリングなど、より高度な機能に焦点を当てることができます。 Mule Runtime Engine が Mule アプリケーションフロー内で操作を処理する方法や、必要に応じてスレッドプールを変更する方法を理解するには、​[実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.7/execution-engine)​について学習します。Mule Runtime Engine は、フロー内の操作によって提供された実行メタデータを使用して、自動調整を実行します。 Mule 4 に実装されている​[クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-classloading-isolation)​メカニズムでは、コンポーネントがその内部リソースを公開できなくなるため、アップグレードが容易になります。すべてのコンポーネントは、その定義済みの API を介して相互にやり取りするため、他のコンポーネントがアクセスできるのは公開されたリソースのみになります。クラスローディング分離を使用すると、コンポーネントの内部コンテンツが確実に保護されるほか、他のコンポーネントに影響を与えずにいつでもコンポーネントの内部コンテンツを変更できます。 Mule 4 は​[分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.7/distributed-file-polling)​をサポートします。これにより、コネクタはファイルの作成時に特定のディレクトリからファイルを読み取ることができます。また、分散ファイルのポーリングでは、すべてのクラスターノードのファイルをポーリングできます。 Mule 4 は​[分散ロッキング](https://docs.mulesoft.com/jp/mule-runtime/4.7/distributed-locking)​もサポートします。これにより、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。 Mule がさまざまなコンポーネントのデータアクセスを一元化する方法に加え、DataWeave がこの情報を使用して使用するリーダーやライターを決定する方法を理解するには、​[「Mule データ型」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-data-types)​を参照してください。 クラス、項目、データ型の定義を学習するには、Mule Kernel (Mule Runtime Engine の Community Edition) の ​[Javadoc](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-4-api-javadoc)​ を参照してください。 内部の連動関係として Mule Runtime Engine の一部として含まれている​[サードパーティソフトウェア](https://docs.mulesoft.com/jp/mule-runtime/4.7/third-party-software-in-mule)​のリストを参照してください。 # Mule の高度な概念 Mule アプリケーションの開発と Mule Runtime Engine (Mule) の概念の基礎を理解したら、実行エンジン、クラスローディング分離メカニズム、分散ファイルのポーリングなど、より高度な機能に焦点を当てることができます。 Mule Runtime Engine が Mule アプリケーションフロー内で操作を処理する方法や、必要に応じてスレッドプールを変更する方法を理解するには、​[実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.8/execution-engine)​について学習します。Mule Runtime Engine は、フロー内の操作によって提供された実行メタデータを使用して、自動調整を実行します。 Mule 4 に実装されている​[クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-classloading-isolation)​メカニズムでは、コンポーネントがその内部リソースを公開できなくなるため、アップグレードが容易になります。すべてのコンポーネントは、その定義済みの API を介して相互にやり取りするため、他のコンポーネントがアクセスできるのは公開されたリソースのみになります。クラスローディング分離を使用すると、コンポーネントの内部コンテンツが確実に保護されるほか、他のコンポーネントに影響を与えずにいつでもコンポーネントの内部コンテンツを変更できます。 Mule 4 は​[分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.8/distributed-file-polling)​をサポートします。これにより、コネクタはファイルの作成時に特定のディレクトリからファイルを読み取ることができます。また、分散ファイルのポーリングでは、すべてのクラスターノードのファイルをポーリングできます。 Mule 4 は​[分散ロッキング](https://docs.mulesoft.com/jp/mule-runtime/4.8/distributed-locking)​もサポートします。これにより、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。 Mule がさまざまなコンポーネントのデータアクセスを一元化する方法に加え、DataWeave がこの情報を使用して使用するリーダーやライターを決定する方法を理解するには、​[「Mule データ型」](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-data-types)​を参照してください。 クラス、項目、データ型の定義を学習するには、Mule Kernel (Mule Runtime Engine の Community Edition) の ​[Javadoc](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-4-api-javadoc)​ を参照してください。 内部の連動関係として Mule Runtime Engine の一部として含まれている​[サードパーティソフトウェア](https://docs.mulesoft.com/jp/mule-runtime/4.8/third-party-software-in-mule)​のリストを参照してください。 # Mule の高度な概念 Mule アプリケーションの開発と Mule Runtime Engine (Mule) の概念の基礎を理解したら、実行エンジン、クラスローディング分離メカニズム、分散ファイルのポーリングなど、より高度な機能に焦点を当てることができます。 Mule Runtime Engine が Mule アプリケーションフロー内で操作を処理する方法や、必要に応じてスレッドプールを変更する方法を理解するには、​[実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.9/execution-engine)​について学習します。Mule Runtime Engine は、フロー内の操作によって提供された実行メタデータを使用して、自動調整を実行します。 Mule 4 に実装されている​[クラスローディング分離](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-classloading-isolation)​メカニズムでは、コンポーネントがその内部リソースを公開できなくなるため、アップグレードが容易になります。すべてのコンポーネントは、その定義済みの API を介して相互にやり取りするため、他のコンポーネントがアクセスできるのは公開されたリソースのみになります。クラスローディング分離を使用すると、コンポーネントの内部コンテンツが確実に保護されるほか、他のコンポーネントに影響を与えずにいつでもコンポーネントの内部コンテンツを変更できます。 Mule 4 は​[分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.9/distributed-file-polling)​をサポートします。これにより、コネクタはファイルの作成時に特定のディレクトリからファイルを読み取ることができます。また、分散ファイルのポーリングでは、すべてのクラスターノードのファイルをポーリングできます。 Mule 4 は​[分散ロッキング](https://docs.mulesoft.com/jp/mule-runtime/4.9/distributed-locking)​もサポートします。これにより、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。 Mule がさまざまなコンポーネントのデータアクセスを一元化する方法に加え、DataWeave がこの情報を使用して使用するリーダーやライターを決定する方法を理解するには、​[「Mule データ型」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-data-types)​を参照してください。 クラス、項目、データ型の定義を学習するには、Mule Kernel (Mule Runtime Engine の Community Edition) の ​[Javadoc](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-4-api-javadoc)​ を参照してください。 内部の連動関係として Mule Runtime Engine の一部として含まれている​[サードパーティソフトウェア](https://docs.mulesoft.com/jp/mule-runtime/4.9/third-party-software-in-mule)​のリストを参照してください。 # Mule メッセージ構造 Mule メッセージは、Mule アプリケーションのフロー内で処理されるときに、通常は外部ソースのメッセージコンテンツとメタデータのコンテナとして機能する、Mule イベントの一部です。 Mule イベントは不変であるため、Mule メッセージを変更するたびに新しいインスタンスが作成されます。メッセージを受信するフロー内の各プロセッサーは、次の要素で構成される新しい Mule メッセージを返します。 - メッセージ​`payload`​。メッセージの本文が含まれます。たとえば、ファイルの内容、データベースのレコード、REST または Web サービス要求への応答が含まれます。 - メッセージ​`attributes`​。ペイロードに関連付けられたメタデータ。 ![mule message structure 82af1](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mule-message-structure-82af1.png) Mule メッセージは、HTTP リスナーが応答を受信したときや Scheduler コンポーネントがフローの実行をトリガーしたときと同様に、Mule フロー内のメッセージソースがフローの開始をトリガーしたときに ​[Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-event)​の一部として作成されます。 たとえば、Mule アプリケーションの HTTP リスナーは応答を受信したときに、応答のコンテンツをそのペイロードとして含み、そのコンテンツに関連付けられたメタデータも含む Mule メッセージを使用して Mule イベントを作成します。フロー内のメッセージプロセッサー (コアコンポーネント、File Read 操作、HTTP Request 操作など) は、その設定に従って、Mule イベントに存在する Mule メッセージデータを取得、設定、処理できます。 Anypoint Studio では、​[DataSense Explorer](https://docs.mulesoft.com/studio/datasense-explorer)​ にフローの特定ポイントでの Mule メッセージの構造が表示されます。 ## [](#メッセージペイロード)メッセージペイロード メッセージペイロードには、メッセージのコンテンツまたは本文が含まれます。たとえは、ペイロードには HTTP 要求の結果、Database Connector の Select 操作で取得したレコードの内容、またはファイルコネクタや FTP Connector への Read 操作で取得したファイルの内容が含まれる可能性があります。 ペイロードのコンテンツは、フロー内を移動するにつれ、Mule フロー内のメッセージプロセッサーによって設定、強化、新しい形式への変換、情報の抽出、または Mule イベント変数への保存と新規ペイロードの生成が行われたときに変更されます。 Mule メッセージのペイロードは、​[Mule Runtime 変数](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-variables-context)​ ​`payload`​ を使用する DataWeave 式で選択できます。 たとえば、​`https://jsonplaceholder.typicode.com/users`​ の JSON コンテンツに対する HTTP 要求への応答の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力されます。 例: HTTP 応答ペイロード ```txt [ { "id": 1, "name": "Leanne Graham", "username": "Bret", "email": "Sincere@april.biz", "address": { "street": "Kulas Light", "city": "Gwenborough", "zipcode": "92998-3874", "geo": { "lat": "-37.3159", "lng": "81.1496" } } }, { "id": 2, "name": "Ervin Howell", "username": "Antonette", "email": "Shanna@melissa.tv", "address": { "street": "Victor Plains", "city": "Wisokyburgh", "zipcode": "90566-7771", "geo": { "lat": "-43.9509", "lng": "-34.4618" } } } ] ``` 単純な JSON ファイルに対する File Read 操作の出力の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力される可能性があります。 例: ファイルペイロード ```txt { "hello" : "world" } ``` フロー内の次のメッセージプロセッサーは、このペイロードに対して、​`payload.'hello'`​ を含むペイロード内の JSON オブジェクトの値を選択し、先行する JSON ペイロードを文字列 ​`"world"`​ で置き換えるアクションなどを実行できます。 ## [](#attributes)属性 属性には、メッセージの本文 (またはペイロード) に関連付けられたメタデータが含まれます。メッセージの特定の属性は、そのメッセージに関連付けられたコネクタ (HTTP、FTP、ファイルなど) によって異なります。メタデータはコネクタによって受信または返されたヘッダーとプロパティ、およびコネクタまたはコアコンポーネント (Transform Message など) によって入力された他のメタデータで構成されます。 Mule メッセージの属性は、​[Mule Runtime 変数](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-variables-context)​ ​`attributes`​ を使用する DataWeave 式で選択できます。 たとえば、Logger コンポーネントを介して HTTP 応答メタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のような HTTP 応答属性が Studio コンソールに出力されます。 例: HTTP 応答の属性 ```txt { Status Code=200 Reason Phrase=OK Headers=[ date=Sun, 20 Jan 2019 19:13:51 GMT content-type=text/html; charset=UTF-8 transfer-encoding=chunked connection=keep-alive set-cookie=__cfduid=d03462713a0b2c57c8d2ad3bf311287041548011631; expires=Mon, 20-Jan-20 19:13:51 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 last-modified=Tue, 15 Jan 2019 18:17:15 GMT via=1.1 vegur cf-cache-status=HIT expires=Sun, 20 Jan 2019 23:13:51 GMT expect-ct=max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" server=cloudflare cf-ray=49c3dc570c2f281c-SJC ] } ``` この例は、Web ページ ​`https://jsonplaceholder.typicode.com/users`​ に対する HTTP Request 操作からの応答です。 各属性は、等号 (​`=`​) で区切られたキー-値のペアになっています。フローでコネクタまたはコンポーネント (Logger など) を使用する場合、​`attribute`​ 変数を特定の属性やその内部属性と共に使用して、必要な属性値 (状況コードやコンテンツタイプなど) を選択できます。たとえば、次の構文を使用して HTTP 応答で属性の値を選択できます。 - `attributes.statusCode`​: `200`​ などの HTTP 状況コードを選択。 - `attributes.headers.date`​: HTTP 応答のヘッダーから ​`Sun, 20 Jan 2019 18:54:54 GMT`​ を選択。 - `attributes.headers.'content-type'`​: HTTP コンテンツタイプ ​`application/json`​ を選択。 `content-type`​ などの内部属性を選択するには、名前 ​`content-type`​ を引用符で囲む必要があります。DataWeave では ​[属性名の有効な識別子](#valid_identifiers)​ で記述されたルールが内部値に適用されるため、​`date`​ などの値を引用符で囲む必要はありません。状況コード値を選択するセレクターで ​`'Status Code'`​ または ​`"Status Code"`​ ではなく ​`statusCode`​ を使用する理由については、該当のセクションの​[「注意」](#note_top_level_selectors)​を参照してください。 ファイルメタデータの場合、属性は異なります。たとえば、Logger コンポーネントを介してファイルメタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のようなコンテンツが Studio コンソールに表示されます。 例: ファイルの属性 ```txt LocalFileAttributes[ lastModifiedTime=2019-01-20T08:17:55, lastAccessTime=2019-01-20T10:54:55, creationTime=2019-01-20T08:17:55, size=22, regularFile=true, directory=false, symbolicLink=false, path=/Users/me/Desktop/myJson.json, fileName=myJson.json ``` 各属性は、キー-値のペア (​`fileName=myJson.json`​ など) になっています。属性の値を選択するには、次のようにそのキーを参照します。 - `attributes.'fileName'`​: ファイルの名前 (​`myJson.json`​) を返す。 - `attributes.size`​: ファイルのサイズ (​`22`​) を返す。 ### [](#valid_identifiers)属性名の有効な識別子 [「有効な識別子を宣言するためのルール」](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-language-introduction#valid-identifiers)​で説明されているルールに従う属性名については、引用符を使用せずにアクセスおよび宣言できます。 有効な識別子ではない属性を使用するには、次のいずれかの文字で属性名を囲みます。 - 単一引用符 (​`'`​) - 二重引用符 (​`"`​) - バッククォート (`` ` ``) たとえば、次の DataWeave 変数宣言について考えてみます。 ```java var myVar = { id : "1234", "123 abc !@#" : "some_value" } ``` 属性名 ​`123 abc !@#`​ は有効な識別子ではないため、引用符またはバッククォートを使用して宣言する必要があります。 属性 ​`123 abc !@#`​ の値 (​`"some_value"`​) にアクセスするには、引用符またはバッククォートを使用します。 ```none myVar.'123 abc !@#' ``` 属性名が有効な識別子の場合も、引用符またはバッククォートを使用して属性を宣言したり、属性の値を選択したりできます。 前述の変数宣言の例では、属性 ​`id`​ は引用符を使用せずに宣言されています。​`id`​ に保存された値にアクセスするには、次のいずれかの方法を使用できます。 - `myVar.id` - `myVar.'id'` - `myVar."id"` - `myVar.`​id\`\` 注意: コンソール出力に表示される、人間が解読できる最上位属性の名前 (​`Status Code`​ など) は、属性の選択で使用する名前 (​`statusCode`​) とは異なる可能性があります。人間が解読できる名前 ​`Status Code`​ を引用符で囲むと、その最上位属性が選択可能になるのではなく ​`null`​ が返されます。最上位属性名 (​`Status Code`​、​`Reason Phrase`​、​`Headers`​ など) の選択に使用する構文は、​[Studio のオートコンプリート](https://docs.mulesoft.com/studio/datasense-concept#using-datasense-for-autocomplete)​を使用して確認できるほか、コネクタのドキュメント (​[「HTTP 要求」など](#connectors::http/http-connector-xml-reference.adoc#http-request)​) で確認できます。 ## [](#関連情報)関連情報 - [定義済み変数](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-variables-context) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-event) - [DataWeave セレクター](#dataweave-selectors.adoc) - [Set Payload トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.3/set-payload-transformer-reference) # Mule メッセージ構造 Mule メッセージは、Mule アプリケーションのフロー内で処理されるときに、通常は外部ソースのメッセージコンテンツとメタデータのコンテナとして機能する、Mule イベントの一部です。 Mule イベントは不変であるため、Mule メッセージを変更するたびに新しいインスタンスが作成されます。メッセージを受信するフロー内の各プロセッサーは、次の要素で構成される新しい Mule メッセージを返します。 - メッセージ​`payload`​。メッセージの本文が含まれます。たとえば、ファイルのコンテンツ、HTTP 本文、データベースのレコード、REST または Web サービス要求への応答が含まれます。 - メッセージ ​`attributes`​。HTTP ヘッダーやクエリパラメーターなどのペイロードに関連付けられたメタデータ。 ![mule message structure 82af1](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mule-message-structure-82af1.png) Mule イベントソースは、Mule メッセージを使用して Mule イベントを作成してイベントソースが含まれる Mule フローを実行するプロセスをトリガーします。たとえば、このプロセスは ​[HTTP Listener](https://docs.mulesoft.com/jp/http-connector/1.10/http-listener-ref)​ ソースが要求を受信するか ​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.4/scheduler-concept)​ が実行されるたびに開始されます。 フローが実行を開始した後で、ダウンストリームプロセッサー (コアコンポーネント、File Read 操作、HTTP Request 操作など) は、その設定に従って、Mule イベントに存在する Mule メッセージデータ (ペイロードと属性) を取得、設定、処理できます。 Anypoint Studio では、​[DataSense Explorer](https://docs.mulesoft.com/studio/datasense-explorer)​ にフローの特定ポイントでの Mule メッセージの構造が表示されます。 ## [](#メッセージペイロード)メッセージペイロード メッセージペイロードには、メッセージのコンテンツまたは本文が含まれます。たとえは、ペイロードには HTTP 要求の結果、Database Connector の Select 操作で取得したレコードのコンテンツ、または File Connector や FTP Connector への Read 操作で取得したファイルのコンテンツが含まれる可能性があります。 ペイロードのコンテンツは、フロー内を移動するにつれ、Mule フロー内のメッセージプロセッサーによって設定、強化、新しい形式への変換、情報の抽出、または Mule イベント変数への保存と新規ペイロードの生成が行われたときに変更されます。 Mule メッセージのペイロードは、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`payload`​ を使用する DataWeave 式で選択できます。 たとえば、​`https://jsonplaceholder.typicode.com/users`​ の JSON コンテンツに対する HTTP 要求への応答の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力されます。 例: HTTP 応答ペイロード ```txt [ { "id": 1, "name": "Leanne Graham", "username": "Bret", "email": "Sincere@april.biz", "address": { "street": "Kulas Light", "city": "Gwenborough", "zipcode": "92998-3874", "geo": { "lat": "-37.3159", "lng": "81.1496" } } }, { "id": 2, "name": "Ervin Howell", "username": "Antonette", "email": "Shanna@melissa.tv", "address": { "street": "Victor Plains", "city": "Wisokyburgh", "zipcode": "90566-7771", "geo": { "lat": "-43.9509", "lng": "-34.4618" } } } ] ``` 単純な JSON ファイルに対する File Read 操作の出力の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力される可能性があります。 例: ファイルペイロード ```txt { "hello" : "world" } ``` フロー内の次のメッセージプロセッサーは、このペイロードに対して、​`payload.'hello'`​ を含むペイロード内の JSON オブジェクトの値を選択し、先行する JSON ペイロードを文字列 ​`"world"`​ で置き換えるアクションなどを実行できます。 ## [](#attributes)属性 属性には、メッセージの本文 (またはペイロード) に関連付けられたメタデータが含まれます。メッセージの特定の属性は、そのメッセージに関連付けられたコネクタ (HTTP、FTP、ファイルなど) によって異なります。メタデータはコネクタによって受信または返されたヘッダーとプロパティ、およびコネクタまたはコアコンポーネント (Transform Message など) によって入力された他のメタデータで構成されます。 Mule メッセージの属性は、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`attributes`​ を使用する DataWeave 式で選択できます。 たとえば、Logger コンポーネントを介して HTTP 応答メタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のような HTTP 応答属性が Studio コンソールに出力されます。 例: HTTP 応答の属性 ```txt { Status Code=200 Reason Phrase=OK Headers=[ date=Sun, 20 Jan 2019 19:13:51 GMT content-type=text/html; charset=UTF-8 transfer-encoding=chunked connection=keep-alive set-cookie=__cfduid=d03462713a0b2c57c8d2ad3bf311287041548011631; expires=Mon, 20-Jan-20 19:13:51 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 last-modified=Tue, 15 Jan 2019 18:17:15 GMT via=1.1 vegur cf-cache-status=HIT expires=Sun, 20 Jan 2019 23:13:51 GMT expect-ct=max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" server=cloudflare cf-ray=49c3dc570c2f281c-SJC ] } ``` この例は、Web ページ ​`https://jsonplaceholder.typicode.com/users`​ に対する HTTP Request 操作からの応答です。 各属性は、等号 (​`=`​) で区切られたキー-値のペアになっています。フローでコネクタまたはコンポーネント (Logger など) を使用する場合、​`attribute`​ 変数を特定の属性やその内部属性と共に使用して、必要な属性値 (状況コードやコンテンツタイプなど) を選択できます。たとえば、次の構文を使用して HTTP 応答で属性の値を選択できます。 - `attributes.statusCode`​: `200`​ などの HTTP 状況コードを選択。 - `attributes.headers.date`​: HTTP 応答のヘッダーから ​`Sun, 20 Jan 2019 18:54:54 GMT`​ を選択。 - `attributes.headers.'content-type'`​: HTTP コンテンツタイプ ​`application/json`​ を選択。 `content-type`​ などの内部属性を選択するには、名前 ​`content-type`​ を引用符で囲む必要があります。DataWeave では ​[属性名の有効な識別子](#valid_identifiers)​ で記述されたルールが内部値に適用されるため、​`date`​ のように値を引用符で囲む必要はありません。状況コード値を選択するセレクターで ​`'Status Code'`​ または ​`"Status Code"`​ ではなく ​`statusCode`​ を使用する理由については、該当のセクションの​[注意](#note_top_level_selectors)​を参照してください。 ファイルメタデータの場合、属性は異なります。たとえば、Logger コンポーネントを介してファイルメタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のようなコンテンツが Studio コンソールに表示されます。 例: ファイルの属性 ```txt LocalFileAttributes[ lastModifiedTime=2019-01-20T08:17:55, lastAccessTime=2019-01-20T10:54:55, creationTime=2019-01-20T08:17:55, size=22, regularFile=true, directory=false, symbolicLink=false, path=/Users/me/Desktop/myJson.json, fileName=myJson.json ``` 各属性は、キー-値のペア (​`fileName=myJson.json`​ など) になっています。属性の値を選択するには、次のようにそのキーを参照します。 - `attributes.'fileName'`​: ファイルの名前 (​`myJson.json`​) を返す。 - `attributes.size`​: ファイルのサイズ (​`22`​) を返す。 ### [](#valid_identifiers)属性名の有効な識別子 [「有効な識別子を宣言するためのルール」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#valid-identifiers)​で説明されているルールに従う属性名については、引用符を使用せずにアクセスおよび宣言できます。 有効な識別子ではない属性を使用するには、次のいずれかの文字で属性名を囲みます。 - 単一引用符 (​`'`​) - 二重引用符 (​`"`​) - バッククォート (`` ` ``) たとえば、次の DataWeave 変数宣言について考えてみます。 ```java var myVar = { id : "1234", "123 abc !@#" : "some_value" } ``` 属性名 ​`123 abc !@#`​ は有効な識別子ではないため、引用符またはバッククォートを使用して宣言する必要があります。 属性 ​`123 abc !@#`​ の値 (​`"some_value"`​) にアクセスするには、引用符またはバッククォートを使用します。 ```none myVar.'123 abc !@#' ``` 属性名が有効な識別子の場合も、引用符またはバッククォートを使用して属性を宣言したり、属性の値を選択したりできます。 前述の変数宣言の例では、属性 ​`id`​ は引用符を使用せずに宣言されています。​`id`​ に保存された値にアクセスするには、次のいずれかの方法を使用できます。 - `myVar.id` - `myVar.'id'` - `myVar."id"` - `myVar.`​id\`\` 注意: コンソール出力に表示される、人間が解読できる最上位属性の名前 (​`Status Code`​ など) は、属性の選択で使用する名前 (​`statusCode`​) とは異なる可能性があります。人間が解読できる名前 ​`Status Code`​ を引用符で囲むと、その最上位属性が選択可能になるのではなく ​`null`​ が返されます。最上位属性名 (​`Status Code`​、​`Reason Phrase`​、​`Headers`​ など) の選択に使用する構文は、​[Studio のオートコンプリート](https://docs.mulesoft.com/studio/datasense-concept#using-datasense-for-autocomplete)​を使用して確認できるほか、コネクタのドキュメント (​[「HTTP 要求」など](#connectors::http/http-connector-xml-reference.adoc#http-request)​) で確認できます。 ## [](#関連情報)関連情報 - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-event) - [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) - [Set Payload トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.4/set-payload-transformer-reference) # Mule メッセージ構造 Mule メッセージは、Mule アプリケーションのフロー内で処理されるときに、通常は外部ソースのメッセージコンテンツとメタデータのコンテナとして機能する、Mule イベントの一部です。 Mule イベントは不変であるため、Mule メッセージを変更するたびに新しいインスタンスが作成されます。メッセージを受信するフロー内の各プロセッサーは、次の要素で構成される新しい Mule メッセージを返します。 - メッセージ​`payload`​。メッセージの本文が含まれます。たとえば、ファイルのコンテンツ、HTTP 本文、データベースのレコード、REST または Web サービス要求への応答が含まれます。 - メッセージ ​`attributes`​。HTTP ヘッダーやクエリパラメーターなどのペイロードに関連付けられたメタデータ。 ![mule message structure 82af1](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mule-message-structure-82af1.png) Mule イベントソースは、Mule メッセージを使用して Mule イベントを作成してイベントソースが含まれる Mule フローを実行するプロセスをトリガーします。たとえば、このプロセスは ​[HTTP Listener](https://docs.mulesoft.com/jp/http-connector/1.10/http-listener-ref)​ ソースが要求を受信するか ​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.5/scheduler-concept)​ が実行されるたびに開始されます。 フローが実行を開始した後で、ダウンストリームプロセッサー (コアコンポーネント、File Read 操作、HTTP Request 操作など) は、その設定に従って、Mule イベントに存在する Mule メッセージデータ (ペイロードと属性) を取得、設定、処理できます。 Anypoint Studio では、​[DataSense Explorer](https://docs.mulesoft.com/studio/datasense-explorer)​ にフローの特定ポイントでの Mule メッセージの構造が表示されます。 ## [](#メッセージペイロード)メッセージペイロード メッセージペイロードには、メッセージのコンテンツまたは本文が含まれます。たとえは、ペイロードには HTTP 要求の結果、Database Connector の Select 操作で取得したレコードのコンテンツ、または File Connector や FTP Connector への Read 操作で取得したファイルのコンテンツが含まれる可能性があります。 ペイロードのコンテンツは、フロー内を移動するにつれ、Mule フロー内のメッセージプロセッサーによって設定、強化、新しい形式への変換、情報の抽出、または Mule イベント変数への保存と新規ペイロードの生成が行われたときに変更されます。 Mule メッセージのペイロードは、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`payload`​ を使用する DataWeave 式で選択できます。 たとえば、​`https://jsonplaceholder.typicode.com/users`​ の JSON コンテンツに対する HTTP 要求への応答の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力されます。 例: HTTP 応答ペイロード ```txt [ { "id": 1, "name": "Leanne Graham", "username": "Bret", "email": "Sincere@april.biz", "address": { "street": "Kulas Light", "city": "Gwenborough", "zipcode": "92998-3874", "geo": { "lat": "-37.3159", "lng": "81.1496" } } }, { "id": 2, "name": "Ervin Howell", "username": "Antonette", "email": "Shanna@melissa.tv", "address": { "street": "Victor Plains", "city": "Wisokyburgh", "zipcode": "90566-7771", "geo": { "lat": "-43.9509", "lng": "-34.4618" } } } ] ``` 単純な JSON ファイルに対する File Read 操作の出力の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力される可能性があります。 例: ファイルペイロード ```txt { "hello" : "world" } ``` フロー内の次のメッセージプロセッサーは、このペイロードに対して、​`payload.'hello'`​ を含むペイロード内の JSON オブジェクトの値を選択し、先行する JSON ペイロードを文字列 ​`"world"`​ で置き換えるアクションなどを実行できます。 ## [](#attributes)属性 属性には、メッセージの本文 (またはペイロード) に関連付けられたメタデータが含まれます。メッセージの特定の属性は、そのメッセージに関連付けられたコネクタ (HTTP、FTP、ファイルなど) によって異なります。メタデータはコネクタによって受信または返されたヘッダーとプロパティ、およびコネクタまたはコアコンポーネント (Transform Message など) によって入力された他のメタデータで構成されます。 Mule メッセージの属性は、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`attributes`​ を使用する DataWeave 式で選択できます。 たとえば、Logger コンポーネントを介して HTTP 応答メタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のような HTTP 応答属性が Studio コンソールに出力されます。 例: HTTP 応答の属性 ```txt { Status Code=200 Reason Phrase=OK Headers=[ date=Sun, 20 Jan 2019 19:13:51 GMT content-type=text/html; charset=UTF-8 transfer-encoding=chunked connection=keep-alive set-cookie=__cfduid=d03462713a0b2c57c8d2ad3bf311287041548011631; expires=Mon, 20-Jan-20 19:13:51 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 last-modified=Tue, 15 Jan 2019 18:17:15 GMT via=1.1 vegur cf-cache-status=HIT expires=Sun, 20 Jan 2019 23:13:51 GMT expect-ct=max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" server=cloudflare cf-ray=49c3dc570c2f281c-SJC ] } ``` この例は、Web ページ ​`https://jsonplaceholder.typicode.com/users`​ に対する HTTP Request 操作からの応答です。 各属性は、等号 (​`=`​) で区切られたキー-値のペアになっています。フローでコネクタまたはコンポーネント (Logger など) を使用する場合、​`attribute`​ 変数を特定の属性やその内部属性と共に使用して、必要な属性値 (状況コードやコンテンツタイプなど) を選択できます。たとえば、次の構文を使用して HTTP 応答で属性の値を選択できます。 - `attributes.statusCode`​: `200`​ などの HTTP 状況コードを選択。 - `attributes.headers.date`​: HTTP 応答のヘッダーから ​`Sun, 20 Jan 2019 18:54:54 GMT`​ を選択。 - `attributes.headers.'content-type'`​: HTTP コンテンツタイプ ​`application/json`​ を選択。 `content-type`​ などの内部属性を選択するには、名前 ​`content-type`​ を引用符で囲む必要があります。DataWeave では ​[属性名の有効な識別子](#valid_identifiers)​ で記述されたルールが内部値に適用されるため、​`date`​ などの値を引用符で囲む必要はありません。状況コード値を選択するセレクターで ​`'Status Code'`​ または ​`"Status Code"`​ ではなく ​`statusCode`​ を使用する理由については、該当のセクションの​[「注意」](#note_top_level_selectors)​を参照してください。 ファイルメタデータの場合、属性は異なります。たとえば、Logger コンポーネントを介してファイルメタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のようなコンテンツが Studio コンソールに表示されます。 例: ファイルの属性 ```txt LocalFileAttributes[ lastModifiedTime=2019-01-20T08:17:55, lastAccessTime=2019-01-20T10:54:55, creationTime=2019-01-20T08:17:55, size=22, regularFile=true, directory=false, symbolicLink=false, path=/Users/me/Desktop/myJson.json, fileName=myJson.json ``` 各属性は、キー-値のペア (​`fileName=myJson.json`​ など) になっています。属性の値を選択するには、次のようにそのキーを参照します。 - `attributes.'fileName'`​: ファイルの名前 (​`myJson.json`​) を返す。 - `attributes.size`​: ファイルのサイズ (​`22`​) を返す。 ### [](#valid_identifiers)属性名の有効な識別子 [「有効な識別子を宣言するためのルール」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#valid-identifiers)​で説明されているルールに従う属性名については、引用符を使用せずにアクセスおよび宣言できます。 有効な識別子ではない属性を使用するには、次のいずれかの文字で属性名を囲みます。 - 単一引用符 (​`'`​) - 二重引用符 (​`"`​) - バッククォート (`` ` ``) たとえば、次の DataWeave 変数宣言について考えてみます。 ```java var myVar = { id : "1234", "123 abc !@#" : "some_value" } ``` 属性名 ​`123 abc !@#`​ は有効な識別子ではないため、引用符またはバッククォートを使用して宣言する必要があります。 属性 ​`123 abc !@#`​ の値 (​`"some_value"`​) にアクセスするには、引用符またはバッククォートを使用します。 ```none myVar.'123 abc !@#' ``` 属性名が有効な識別子の場合も、引用符またはバッククォートを使用して属性を宣言したり、属性の値を選択したりできます。 前述の変数宣言の例では、属性 ​`id`​ は引用符を使用せずに宣言されています。​`id`​ に保存された値にアクセスするには、次のいずれかの方法を使用できます。 - `myVar.id` - `myVar.'id'` - `myVar."id"` - `myVar.`​id\`\` 注意: コンソール出力に表示される、人間が解読できる最上位属性の名前 (​`Status Code`​ など) は、属性の選択で使用する名前 (​`statusCode`​) とは異なる可能性があります。人間が解読できる名前 ​`Status Code`​ を引用符で囲むと、その最上位属性が選択可能になるのではなく ​`null`​ が返されます。最上位属性名 (​`Status Code`​、​`Reason Phrase`​、​`Headers`​ など) の選択に使用する構文は、​[Studio のオートコンプリート](https://docs.mulesoft.com/studio/datasense-concept#using-datasense-for-autocomplete)​を使用して確認できるほか、コネクタのドキュメント (​[「HTTP 要求」など](#connectors::http/http-connector-xml-reference.adoc#http-request)​) で確認できます。 ## [](#関連情報)関連情報 - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-event) - [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) - [Set Payload トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.5/set-payload-transformer-reference) # Mule メッセージ構造 Mule メッセージは、Mule アプリケーションのフロー内で処理されるときに、通常は外部ソースのメッセージコンテンツとメタデータのコンテナとして機能する、Mule イベントの一部です。 Mule イベントは不変であるため、Mule メッセージを変更するたびに新しいインスタンスが作成されます。メッセージを受信するフロー内の各プロセッサーは、次の要素で構成される新しい Mule メッセージを返します。 - メッセージ​`payload`​。メッセージの本文が含まれます。たとえば、ファイルのコンテンツ、HTTP 本文、データベースのレコード、REST または Web サービス要求への応答が含まれます。 - メッセージ ​`attributes`​。HTTP ヘッダーやクエリパラメーターなどのペイロードに関連付けられたメタデータ。 ![mule message structure 82af1](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mule-message-structure-82af1.png) Mule イベントソースは、Mule メッセージを使用して Mule イベントを作成してイベントソースが含まれる Mule フローを実行するプロセスをトリガーします。たとえば、このプロセスは ​[HTTP Listener](https://docs.mulesoft.com/jp/http-connector/1.10/http-listener-ref)​ ソースが要求を受信するか ​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.6/scheduler-concept)​ が実行されるたびに開始されます。 フローが実行を開始した後で、ダウンストリームプロセッサー (コアコンポーネント、File Read 操作、HTTP Request 操作など) は、その設定に従って、Mule イベントに存在する Mule メッセージデータ (ペイロードと属性) を取得、設定、処理できます。 Anypoint Studio では、​[DataSense Explorer](https://docs.mulesoft.com/studio/datasense-explorer)​ にフローの特定ポイントでの Mule メッセージの構造が表示されます。 ## [](#メッセージペイロード)メッセージペイロード メッセージペイロードには、メッセージのコンテンツまたは本文が含まれます。たとえは、ペイロードには HTTP 要求の結果、Database Connector の Select 操作で取得したレコードのコンテンツ、または File Connector や FTP Connector への Read 操作で取得したファイルのコンテンツが含まれる可能性があります。 ペイロードのコンテンツは、フロー内を移動するにつれ、Mule フロー内のメッセージプロセッサーによって設定、強化、新しい形式への変換、情報の抽出、または Mule イベント変数への保存と新規ペイロードの生成が行われたときに変更されます。 Mule メッセージのペイロードは、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`payload`​ を使用する DataWeave 式で選択できます。 たとえば、​`https://jsonplaceholder.typicode.com/users`​ の JSON コンテンツに対する HTTP 要求への応答の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力されます。 例: HTTP 応答ペイロード ```txt [ { "id": 1, "name": "Leanne Graham", "username": "Bret", "email": "Sincere@april.biz", "address": { "street": "Kulas Light", "city": "Gwenborough", "zipcode": "92998-3874", "geo": { "lat": "-37.3159", "lng": "81.1496" } } }, { "id": 2, "name": "Ervin Howell", "username": "Antonette", "email": "Shanna@melissa.tv", "address": { "street": "Victor Plains", "city": "Wisokyburgh", "zipcode": "90566-7771", "geo": { "lat": "-43.9509", "lng": "-34.4618" } } } ] ``` 単純な JSON ファイルに対する File Read 操作の出力の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力される可能性があります。 例: ファイルペイロード ```txt { "hello" : "world" } ``` フロー内の次のメッセージプロセッサーは、このペイロードに対して、​`payload.'hello'`​ を含むペイロード内の JSON オブジェクトの値を選択し、先行する JSON ペイロードを文字列 ​`"world"`​ で置き換えるアクションなどを実行できます。 ## [](#attributes)属性 属性には、メッセージの本文 (またはペイロード) に関連付けられたメタデータが含まれます。メッセージの特定の属性は、そのメッセージに関連付けられたコネクタ (HTTP、FTP、ファイルなど) によって異なります。メタデータはコネクタによって受信または返されたヘッダーとプロパティ、およびコネクタまたはコアコンポーネント (Transform Message など) によって入力された他のメタデータで構成されます。 Mule メッセージの属性は、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`attributes`​ を使用する DataWeave 式で選択できます。 たとえば、Logger コンポーネントを介して HTTP 応答メタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のような HTTP 応答属性が Studio コンソールに出力されます。 例: HTTP 応答の属性 ```txt { Status Code=200 Reason Phrase=OK Headers=[ date=Sun, 20 Jan 2019 19:13:51 GMT content-type=text/html; charset=UTF-8 transfer-encoding=chunked connection=keep-alive set-cookie=__cfduid=d03462713a0b2c57c8d2ad3bf311287041548011631; expires=Mon, 20-Jan-20 19:13:51 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 last-modified=Tue, 15 Jan 2019 18:17:15 GMT via=1.1 vegur cf-cache-status=HIT expires=Sun, 20 Jan 2019 23:13:51 GMT expect-ct=max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" server=cloudflare cf-ray=49c3dc570c2f281c-SJC ] } ``` この例は、Web ページ ​`https://jsonplaceholder.typicode.com/users`​ に対する HTTP Request 操作からの応答です。 各属性は、等号 (​`=`​) で区切られたキー-値のペアになっています。フローでコネクタまたはコンポーネント (Logger など) を使用する場合、​`attribute`​ 変数を特定の属性やその内部属性と共に使用して、必要な属性値 (状況コードやコンテンツタイプなど) を選択できます。たとえば、次の構文を使用して HTTP 応答で属性の値を選択できます。 - `attributes.statusCode`​: `200`​ などの HTTP 状況コードを選択。 - `attributes.headers.date`​: HTTP 応答のヘッダーから ​`Sun, 20 Jan 2019 18:54:54 GMT`​ を選択。 - `attributes.headers.'content-type'`​: HTTP コンテンツタイプ ​`application/json`​ を選択。 `content-type`​ などの内部属性を選択するには、名前 ​`content-type`​ を引用符で囲む必要があります。DataWeave では ​[属性名の有効な識別子](#valid_identifiers)​ で記述されたルールが内部値に適用されるため、​`date`​ のように値を引用符で囲む必要はありません。状況コード値を選択するセレクターで ​`'Status Code'`​ または ​`"Status Code"`​ ではなく ​`statusCode`​ を使用する理由については、該当のセクションの​[注意](#note_top_level_selectors)​を参照してください。 ファイルメタデータの場合、属性は異なります。たとえば、Logger コンポーネントを介してファイルメタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のようなコンテンツが Studio コンソールに表示されます。 例: ファイルの属性 ```txt LocalFileAttributes[ lastModifiedTime=2019-01-20T08:17:55, lastAccessTime=2019-01-20T10:54:55, creationTime=2019-01-20T08:17:55, size=22, regularFile=true, directory=false, symbolicLink=false, path=/Users/me/Desktop/myJson.json, fileName=myJson.json ``` 各属性は、キー-値のペア (​`fileName=myJson.json`​ など) になっています。属性の値を選択するには、次のようにそのキーを参照します。 - `attributes.'fileName'`​: ファイルの名前 (​`myJson.json`​) を返す。 - `attributes.size`​: ファイルのサイズ (​`22`​) を返す。 ### [](#valid_identifiers)属性名の有効な識別子 [「有効な識別子を宣言するためのルール」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#valid-identifiers)​で説明されているルールに従う属性名については、引用符を使用せずにアクセスおよび宣言できます。 有効な識別子ではない属性を使用するには、次のいずれかの文字で属性名を囲みます。 - 単一引用符 (​`'`​) - 二重引用符 (​`"`​) - バッククォート (`` ` ``) たとえば、次の DataWeave 変数宣言について考えてみます。 ```java var myVar = { id : "1234", "123 abc !@#" : "some_value" } ``` 属性名 ​`123 abc !@#`​ は有効な識別子ではないため、引用符またはバッククォートを使用して宣言する必要があります。 属性 ​`123 abc !@#`​ の値 (​`"some_value"`​) にアクセスするには、引用符またはバッククォートを使用します。 ```none myVar.'123 abc !@#' ``` 属性名が有効な識別子の場合も、引用符またはバッククォートを使用して属性を宣言したり、属性の値を選択したりできます。 前述の変数宣言の例では、属性 ​`id`​ は引用符を使用せずに宣言されています。​`id`​ に保存された値にアクセスするには、次のいずれかの方法を使用できます。 - `myVar.id` - `myVar.'id'` - `myVar."id"` - `myVar.`​id\`\` 注意: コンソール出力に表示される、人間が解読できる最上位属性の名前 (​`Status Code`​ など) は、属性の選択で使用する名前 (​`statusCode`​) とは異なる可能性があります。人間が解読できる名前 ​`Status Code`​ を引用符で囲むと、その最上位属性が選択可能になるのではなく ​`null`​ が返されます。最上位属性名 (​`Status Code`​、​`Reason Phrase`​、​`Headers`​ など) の選択に使用する構文は、​[Studio のオートコンプリート](https://docs.mulesoft.com/studio/datasense-concept#using-datasense-for-autocomplete)​を使用して確認できるほか、コネクタのドキュメント (​[「HTTP 要求」など](#connectors::http/http-connector-xml-reference.adoc#http-request)​) で確認できます。 ## [](#関連情報)関連情報 - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-event) - [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) - [Set Payload トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.6/set-payload-transformer-reference) # Mule メッセージ構造 Mule メッセージは、Mule アプリケーションのフロー内で処理されるときに、通常は外部ソースのメッセージコンテンツとメタデータのコンテナとして機能する、Mule イベントの一部です。 Mule イベントは不変であるため、Mule メッセージを変更するたびに新しいインスタンスが作成されます。メッセージを受信するフロー内の各プロセッサーは、次の要素で構成される新しい Mule メッセージを返します。 - メッセージ ​`payload`​。メッセージの本文が含まれます。たとえば、ファイルのコンテンツ、HTTP 本文、データベースのレコード、REST または Web サービス要求への応答が含まれます。 - メッセージ ​`attributes`​。HTTP ヘッダーやクエリパラメーターなどのペイロードに関連付けられたメタデータ。 ![属性とペイロードが含まれる Mule メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mule-message-structure-82af1.png) Mule イベントソースは、Mule メッセージを使用して Mule イベントを作成してイベントソースが含まれる Mule フローを実行するプロセスをトリガーします。たとえば、このプロセスは ​[HTTP Listener](https://docs.mulesoft.com/jp/http-connector/1.10/http-listener-ref)​ ソースが要求を受信するか ​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.7/scheduler-concept)​ が実行されるたびに開始されます。 フローが実行を開始した後で、ダウンストリームプロセッサー (コアコンポーネント、File Read 操作、HTTP Request 操作など) は、その設定に従って、Mule イベントに存在する Mule メッセージデータ (ペイロードと属性) を取得、設定、処理できます。 Anypoint Studio では、​[DataSense Explorer](https://docs.mulesoft.com/studio/datasense-explorer)​ にフローの特定ポイントでの Mule メッセージの構造が表示されます。 ## [](#メッセージペイロード)メッセージペイロード メッセージペイロードには、メッセージのコンテンツまたは本文が含まれます。たとえは、ペイロードには HTTP 要求の結果、Database Connector の Select 操作で取得したレコードのコンテンツ、または File Connector や FTP Connector への Read 操作で取得したファイルのコンテンツが含まれる可能性があります。 ペイロードのコンテンツは、フロー内を移動するにつれ、Mule フロー内のメッセージプロセッサーによって設定、強化、新しい形式への変換、情報の抽出、または Mule イベント変数への保存と新規ペイロードの生成が行われたときに変更されます。 Mule メッセージのペイロードは、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`payload`​ を使用する DataWeave 式で選択できます。 たとえば、​`https://jsonplaceholder.typicode.com/users`​ の JSON コンテンツに対する HTTP 要求への応答の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力されます。 例: HTTP 応答ペイロード ```txt [ { "id": 1, "name": "Leanne Graham", "username": "Bret", "email": "Sincere@april.biz", "address": { "street": "Kulas Light", "city": "Gwenborough", "zipcode": "92998-3874", "geo": { "lat": "-37.3159", "lng": "81.1496" } } }, { "id": 2, "name": "Ervin Howell", "username": "Antonette", "email": "Shanna@melissa.tv", "address": { "street": "Victor Plains", "city": "Wisokyburgh", "zipcode": "90566-7771", "geo": { "lat": "-43.9509", "lng": "-34.4618" } } } ] ``` 単純な JSON ファイルに対する File Read 操作の出力の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力される可能性があります。 例: ファイルペイロード ```txt { "hello" : "world" } ``` フロー内の次のメッセージプロセッサーは、このペイロードに対して、​`payload.'hello'`​ を含むペイロード内の JSON オブジェクトの値を選択し、先行する JSON ペイロードを文字列 ​`"world"`​ で置き換えるアクションなどを実行できます。 ## [](#attributes)属性 属性には、メッセージの本文 (またはペイロード) に関連付けられたメタデータが含まれます。メッセージの特定の属性は、そのメッセージに関連付けられたコネクタ (HTTP、FTP、ファイルなど) によって異なります。メタデータはコネクタによって受信または返されたヘッダーとプロパティ、およびコネクタまたはコアコンポーネント (Transform Message など) によって入力された他のメタデータで構成されます。 Mule メッセージの属性は、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`attributes`​ を使用する DataWeave 式で選択できます。 たとえば、Logger コンポーネントを介して HTTP 応答メタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のような HTTP 応答属性が Studio コンソールに出力されます。 例: HTTP 応答の属性 ```txt { Status Code=200 Reason Phrase=OK Headers=[ date=Sun, 20 Jan 2019 19:13:51 GMT content-type=text/html; charset=UTF-8 transfer-encoding=chunked connection=keep-alive set-cookie=__cfduid=d03462713a0b2c57c8d2ad3bf311287041548011631; expires=Mon, 20-Jan-20 19:13:51 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 last-modified=Tue, 15 Jan 2019 18:17:15 GMT via=1.1 vegur cf-cache-status=HIT expires=Sun, 20 Jan 2019 23:13:51 GMT expect-ct=max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" server=cloudflare cf-ray=49c3dc570c2f281c-SJC ] } ``` この例は、Web ページ ​`https://jsonplaceholder.typicode.com/users`​ に対する HTTP Request 操作からの応答です。 各属性は、等号 (​`=`​) で区切られたキー-値のペアになっています。フローでコネクタまたはコンポーネント (Logger など) を使用する場合、​`attribute`​ 変数を特定の属性やその内部属性と共に使用して、必要な属性値 (状況コードやコンテンツタイプなど) を選択できます。たとえば、次の構文を使用して HTTP 応答で属性の値を選択できます。 - `attributes.statusCode`​: `200`​ などの HTTP 状況コードを選択。 - `attributes.headers.date`​: HTTP 応答のヘッダーから ​`Sun, 20 Jan 2019 18:54:54 GMT`​ を選択。 - `attributes.headers.'content-type'`​: HTTP コンテンツタイプ ​`application/json`​ を選択。 `content-type`​ などの内部属性を選択するには、名前 ​`content-type`​ を引用符で囲む必要があります。DataWeave では ​[属性名の有効な識別子](#valid_identifiers)​ で記述されたルールが内部値に適用されるため、​`date`​ のように値を引用符で囲む必要はありません。状況コード値を選択するセレクターで ​`'Status Code'`​ または ​`"Status Code"`​ ではなく ​`statusCode`​ を使用する理由については、該当のセクションの​[注意](#note_top_level_selectors)​を参照してください。 ファイルメタデータの場合、属性は異なります。たとえば、Logger コンポーネントを介してファイルメタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のようなコンテンツが Studio コンソールに表示されます。 例: ファイルの属性 ```txt LocalFileAttributes[ lastModifiedTime=2019-01-20T08:17:55, lastAccessTime=2019-01-20T10:54:55, creationTime=2019-01-20T08:17:55, size=22, regularFile=true, directory=false, symbolicLink=false, path=/Users/me/Desktop/myJson.json, fileName=myJson.json ``` 各属性は、キー-値のペア (​`fileName=myJson.json`​ など) になっています。属性の値を選択するには、次のようにそのキーを参照します。 - `attributes.'fileName'`​: ファイルの名前 (​`myJson.json`​) を返す。 - `attributes.size`​: ファイルのサイズ (​`22`​) を返す。 ### [](#valid_identifiers)属性名の有効な識別子 [「有効な識別子を宣言するためのルール」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#valid-identifiers)​で説明されているルールに従う属性名については、引用符を使用せずにアクセスおよび宣言できます。 有効な識別子ではない属性を使用するには、次のいずれかの文字で属性名を囲みます。 - 単一引用符 (​`'`​) - 二重引用符 (​`"`​) - バッククォート (`` ` ``) たとえば、次の DataWeave 変数宣言について考えてみます。 ```java var myVar = { id : "1234", "123 abc !@#" : "some_value" } ``` 属性名 ​`123 abc !@#`​ は有効な識別子ではないため、引用符またはバッククォートを使用して宣言する必要があります。 属性 ​`123 abc !@#`​ の値 (​`"some_value"`​) にアクセスするには、引用符またはバッククォートを使用します。 ```none myVar.'123 abc !@#' ``` 属性名が有効な識別子の場合も、引用符またはバッククォートを使用して属性を宣言したり、属性の値を選択したりできます。 前述の変数宣言の例では、属性 ​`id`​ は引用符を使用せずに宣言されています。​`id`​ に保存された値にアクセスするには、次のいずれかの方法を使用できます。 - `myVar.id` - `myVar.'id'` - `myVar."id"` - `myVar.`​id\`\` 注意: コンソール出力に表示される、人間が解読できる最上位属性の名前 (​`Status Code`​ など) は、属性の選択で使用する名前 (​`statusCode`​) とは異なる可能性があります。人間が解読できる名前 ​`Status Code`​ を引用符で囲むと、その最上位属性が選択可能になるのではなく ​`null`​ が返されます。最上位属性名 (​`Status Code`​、​`Reason Phrase`​、​`Headers`​ など) の選択に使用する構文は、​[Studio のオートコンプリート](https://docs.mulesoft.com/studio/datasense-concept#using-datasense-for-autocomplete)​を使用して確認できるほか、コネクタのドキュメント (​[「HTTP 要求」など](#connectors::http/http-connector-xml-reference.adoc#http-request)​) で確認できます。 ## [](#関連情報)関連情報 - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-event) - [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) - [Set Payload トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.7/set-payload-transformer-reference) # Mule メッセージ構造 Mule メッセージは、Mule アプリケーションのフロー内で処理されるときに、通常は外部ソースのメッセージコンテンツとメタデータのコンテナとして機能する、Mule イベントの一部です。 Mule イベントは不変であるため、Mule メッセージを変更するたびに新しいインスタンスが作成されます。メッセージを受信するフロー内の各プロセッサーは、次の要素で構成される新しい Mule メッセージを返します。 - メッセージ ​`payload`​。メッセージの本文が含まれます。たとえば、ファイルのコンテンツ、HTTP 本文、データベースのレコード、REST または Web サービス要求への応答が含まれます。 - メッセージ ​`attributes`​。HTTP ヘッダーやクエリパラメーターなどのペイロードに関連付けられたメタデータ。 ![属性とペイロードが含まれる Mule メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mule-message-structure-82af1.png) Mule イベントソースは、Mule メッセージを使用して Mule イベントを作成してイベントソースが含まれる Mule フローを実行するプロセスをトリガーします。たとえば、このプロセスは ​[HTTP Listener](https://docs.mulesoft.com/jp/http-connector/1.10/http-listener-ref)​ ソースが要求を受信するか ​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.8/scheduler-concept)​ が実行されるたびに開始されます。 フローが実行を開始した後で、ダウンストリームプロセッサー (コアコンポーネント、File Read 操作、HTTP Request 操作など) は、その設定に従って、Mule イベントに存在する Mule メッセージデータ (ペイロードと属性) を取得、設定、処理できます。 Anypoint Studio では、​[DataSense Explorer](https://docs.mulesoft.com/studio/datasense-explorer)​ にフローの特定ポイントでの Mule メッセージの構造が表示されます。 ## [](#メッセージペイロード)メッセージペイロード メッセージペイロードには、メッセージのコンテンツまたは本文が含まれます。たとえは、ペイロードには HTTP 要求の結果、Database Connector の Select 操作で取得したレコードのコンテンツ、または File Connector や FTP Connector への Read 操作で取得したファイルのコンテンツが含まれる可能性があります。 ペイロードのコンテンツは、フロー内を移動するにつれ、Mule フロー内のメッセージプロセッサーによって設定、強化、新しい形式への変換、情報の抽出、または Mule イベント変数への保存と新規ペイロードの生成が行われたときに変更されます。 Mule メッセージのペイロードは、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`payload`​ を使用する DataWeave 式で選択できます。 たとえば、​`https://jsonplaceholder.typicode.com/users`​ の JSON コンテンツに対する HTTP 要求への応答の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力されます。 例: HTTP 応答ペイロード ```txt [ { "id": 1, "name": "Leanne Graham", "username": "Bret", "email": "Sincere@april.biz", "address": { "street": "Kulas Light", "city": "Gwenborough", "zipcode": "92998-3874", "geo": { "lat": "-37.3159", "lng": "81.1496" } } }, { "id": 2, "name": "Ervin Howell", "username": "Antonette", "email": "Shanna@melissa.tv", "address": { "street": "Victor Plains", "city": "Wisokyburgh", "zipcode": "90566-7771", "geo": { "lat": "-43.9509", "lng": "-34.4618" } } } ] ``` 単純な JSON ファイルに対する File Read 操作の出力の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力される可能性があります。 例: ファイルペイロード ```txt { "hello" : "world" } ``` フロー内の次のメッセージプロセッサーは、このペイロードに対して、​`payload.'hello'`​ を含むペイロード内の JSON オブジェクトの値を選択し、先行する JSON ペイロードを文字列 ​`"world"`​ で置き換えるアクションなどを実行できます。 ## [](#attributes)属性 属性には、メッセージの本文 (またはペイロード) に関連付けられたメタデータが含まれます。メッセージの特定の属性は、そのメッセージに関連付けられたコネクタ (HTTP、FTP、ファイルなど) によって異なります。メタデータはコネクタによって受信または返されたヘッダーとプロパティ、およびコネクタまたはコアコンポーネント (Transform Message など) によって入力された他のメタデータで構成されます。 Mule メッセージの属性は、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`attributes`​ を使用する DataWeave 式で選択できます。 たとえば、Logger コンポーネントを介して HTTP 応答メタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のような HTTP 応答属性が Studio コンソールに出力されます。 例: HTTP 応答の属性 ```txt { Status Code=200 Reason Phrase=OK Headers=[ date=Sun, 20 Jan 2019 19:13:51 GMT content-type=text/html; charset=UTF-8 transfer-encoding=chunked connection=keep-alive set-cookie=__cfduid=d03462713a0b2c57c8d2ad3bf311287041548011631; expires=Mon, 20-Jan-20 19:13:51 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 last-modified=Tue, 15 Jan 2019 18:17:15 GMT via=1.1 vegur cf-cache-status=HIT expires=Sun, 20 Jan 2019 23:13:51 GMT expect-ct=max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" server=cloudflare cf-ray=49c3dc570c2f281c-SJC ] } ``` この例は、Web ページ ​`https://jsonplaceholder.typicode.com/users`​ に対する HTTP Request 操作からの応答です。 各属性は、等号 (​`=`​) で区切られたキー-値のペアになっています。フローでコネクタまたはコンポーネント (Logger など) を使用する場合、​`attribute`​ 変数を特定の属性やその内部属性と共に使用して、必要な属性値 (状況コードやコンテンツタイプなど) を選択できます。たとえば、次の構文を使用して HTTP 応答で属性の値を選択できます。 - `attributes.statusCode`​: `200`​ などの HTTP 状況コードを選択。 - `attributes.headers.date`​: HTTP 応答のヘッダーから ​`Sun, 20 Jan 2019 18:54:54 GMT`​ を選択。 - `attributes.headers.'content-type'`​: HTTP コンテンツタイプ ​`application/json`​ を選択。 `content-type`​ などの内部属性を選択するには、名前 ​`content-type`​ を引用符で囲む必要があります。DataWeave では ​[属性名の有効な識別子](#valid_identifiers)​ で記述されたルールが内部値に適用されるため、​`date`​ のように値を引用符で囲む必要はありません。状況コード値を選択するセレクターで ​`'Status Code'`​ または ​`"Status Code"`​ ではなく ​`statusCode`​ を使用する理由については、該当のセクションの​[注意](#note_top_level_selectors)​を参照してください。 ファイルメタデータの場合、属性は異なります。たとえば、Logger コンポーネントを介してファイルメタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のようなコンテンツが Studio コンソールに表示されます。 例: ファイルの属性 ```txt LocalFileAttributes[ lastModifiedTime=2019-01-20T08:17:55, lastAccessTime=2019-01-20T10:54:55, creationTime=2019-01-20T08:17:55, size=22, regularFile=true, directory=false, symbolicLink=false, path=/Users/me/Desktop/myJson.json, fileName=myJson.json ``` 各属性は、キー-値のペア (​`fileName=myJson.json`​ など) になっています。属性の値を選択するには、次のようにそのキーを参照します。 - `attributes.'fileName'`​: ファイルの名前 (​`myJson.json`​) を返す。 - `attributes.size`​: ファイルのサイズ (​`22`​) を返す。 ### [](#valid_identifiers)属性名の有効な識別子 [「有効な識別子を宣言するためのルール」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#valid-identifiers)​で説明されているルールに従う属性名については、引用符を使用せずにアクセスおよび宣言できます。 有効な識別子ではない属性を使用するには、次のいずれかの文字で属性名を囲みます。 - 単一引用符 (​`'`​) - 二重引用符 (​`"`​) - バッククォート (`` ` ``) たとえば、次の DataWeave 変数宣言について考えてみます。 ```java var myVar = { id : "1234", "123 abc !@#" : "some_value" } ``` 属性名 ​`123 abc !@#`​ は有効な識別子ではないため、引用符またはバッククォートを使用して宣言する必要があります。 属性 ​`123 abc !@#`​ の値 (​`"some_value"`​) にアクセスするには、引用符またはバッククォートを使用します。 ```none myVar.'123 abc !@#' ``` 属性名が有効な識別子の場合も、引用符またはバッククォートを使用して属性を宣言したり、属性の値を選択したりできます。 前述の変数宣言の例では、属性 ​`id`​ は引用符を使用せずに宣言されています。​`id`​ に保存された値にアクセスするには、次のいずれかの方法を使用できます。 - `myVar.id` - `myVar.'id'` - `myVar."id"` - `myVar.`​id\`\` 注意: コンソール出力に表示される、人間が解読できる最上位属性の名前 (​`Status Code`​ など) は、属性の選択で使用する名前 (​`statusCode`​) とは異なる可能性があります。人間が解読できる名前 ​`Status Code`​ を引用符で囲むと、その最上位属性が選択可能になるのではなく ​`null`​ が返されます。最上位属性名 (​`Status Code`​、​`Reason Phrase`​、​`Headers`​ など) の選択に使用する構文は、​[Studio のオートコンプリート](https://docs.mulesoft.com/studio/datasense-concept#using-datasense-for-autocomplete)​を使用して確認できるほか、コネクタのドキュメント (​[「HTTP 要求」など](#connectors::http/http-connector-xml-reference.adoc#http-request)​) で確認できます。 ## [](#関連情報)関連情報 - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-event) - [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) - [Set Payload トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.8/set-payload-transformer-reference) # Mule メッセージ構造 Mule メッセージは、Mule アプリケーションのフロー内で処理されるときに、通常は外部ソースのメッセージコンテンツとメタデータのコンテナとして機能する、Mule イベントの一部です。 Mule イベントは不変であるため、Mule メッセージを変更するたびに新しいインスタンスが作成されます。メッセージを受信するフロー内の各プロセッサーは、次の要素で構成される新しい Mule メッセージを返します。 - メッセージ ​`payload`​。メッセージの本文が含まれます。たとえば、ファイルのコンテンツ、HTTP 本文、データベースのレコード、REST または Web サービス要求への応答が含まれます。 - メッセージ ​`attributes`​。HTTP ヘッダーやクエリパラメーターなどのペイロードに関連付けられたメタデータ。 ![属性とペイロードが含まれる Mule メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mule-message-structure-82af1.png) Mule イベントソースは、Mule メッセージを使用して Mule イベントを作成してイベントソースが含まれる Mule フローを実行するプロセスをトリガーします。たとえば、このプロセスは ​[HTTP Listener](https://docs.mulesoft.com/jp/http-connector/1.10/http-listener-ref)​ ソースが要求を受信するか ​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.9/scheduler-concept)​ が実行されるたびに開始されます。 フローが実行を開始した後で、ダウンストリームプロセッサー (コアコンポーネント、File Read 操作、HTTP Request 操作など) は、その設定に従って、Mule イベントに存在する Mule メッセージデータ (ペイロードと属性) を取得、設定、処理できます。 Anypoint Studio では、​[DataSense Explorer](https://docs.mulesoft.com/studio/datasense-explorer)​ にフローの特定ポイントでの Mule メッセージの構造が表示されます。 ## [](#メッセージペイロード)メッセージペイロード メッセージペイロードには、メッセージのコンテンツまたは本文が含まれます。たとえは、ペイロードには HTTP 要求の結果、Database Connector の Select 操作で取得したレコードのコンテンツ、または File Connector や FTP Connector への Read 操作で取得したファイルのコンテンツが含まれる可能性があります。 ペイロードのコンテンツは、フロー内を移動するにつれ、Mule フロー内のメッセージプロセッサーによって設定、強化、新しい形式への変換、情報の抽出、または Mule イベント変数への保存と新規ペイロードの生成が行われたときに変更されます。 Mule メッセージのペイロードは、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`payload`​ を使用する DataWeave 式で選択できます。 たとえば、​`https://jsonplaceholder.typicode.com/users`​ の JSON コンテンツに対する HTTP 要求への応答の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力されます。 例: HTTP 応答ペイロード ```txt [ { "id": 1, "name": "Leanne Graham", "username": "Bret", "email": "Sincere@april.biz", "address": { "street": "Kulas Light", "city": "Gwenborough", "zipcode": "92998-3874", "geo": { "lat": "-37.3159", "lng": "81.1496" } } }, { "id": 2, "name": "Ervin Howell", "username": "Antonette", "email": "Shanna@melissa.tv", "address": { "street": "Victor Plains", "city": "Wisokyburgh", "zipcode": "90566-7771", "geo": { "lat": "-43.9509", "lng": "-34.4618" } } } ] ``` 単純な JSON ファイルに対する File Read 操作の出力の ​`payload`​ を表示するように設定された Logger コンポーネントでは、次の例のような JSON コンテンツが Studio コンソールに出力される可能性があります。 例: ファイルペイロード ```txt { "hello" : "world" } ``` フロー内の次のメッセージプロセッサーは、このペイロードに対して、​`payload.'hello'`​ を含むペイロード内の JSON オブジェクトの値を選択し、先行する JSON ペイロードを文字列 ​`"world"`​ で置き換えるアクションなどを実行できます。 ## [](#attributes)属性 属性には、メッセージの本文 (またはペイロード) に関連付けられたメタデータが含まれます。メッセージの特定の属性は、そのメッセージに関連付けられたコネクタ (HTTP、FTP、ファイルなど) によって異なります。メタデータはコネクタによって受信または返されたヘッダーとプロパティ、およびコネクタまたはコアコンポーネント (Transform Message など) によって入力された他のメタデータで構成されます。 Mule メッセージの属性は、​[Mule Runtime 変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ ​`attributes`​ を使用する DataWeave 式で選択できます。 たとえば、Logger コンポーネントを介して HTTP 応答メタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のような HTTP 応答属性が Studio コンソールに出力されます。 例: HTTP 応答の属性 ```txt { Status Code=200 Reason Phrase=OK Headers=[ date=Sun, 20 Jan 2019 19:13:51 GMT content-type=text/html; charset=UTF-8 transfer-encoding=chunked connection=keep-alive set-cookie=__cfduid=d03462713a0b2c57c8d2ad3bf311287041548011631; expires=Mon, 20-Jan-20 19:13:51 GMT; path=/; domain=.typicode.com; HttpOnly x-powered-by=Express vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=public, max-age=14400 last-modified=Tue, 15 Jan 2019 18:17:15 GMT via=1.1 vegur cf-cache-status=HIT expires=Sun, 20 Jan 2019 23:13:51 GMT expect-ct=max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" server=cloudflare cf-ray=49c3dc570c2f281c-SJC ] } ``` この例は、Web ページ ​`https://jsonplaceholder.typicode.com/users`​ に対する HTTP Request 操作からの応答です。 各属性は、等号 (​`=`​) で区切られたキー-値のペアになっています。フローでコネクタまたはコンポーネント (Logger など) を使用する場合、​`attribute`​ 変数を特定の属性やその内部属性と共に使用して、必要な属性値 (状況コードやコンテンツタイプなど) を選択できます。たとえば、次の構文を使用して HTTP 応答で属性の値を選択できます。 - `attributes.statusCode`​: `200`​ などの HTTP 状況コードを選択。 - `attributes.headers.date`​: HTTP レスポンスヘッダーから ​`Sun, 20 Jan 2019 18:54:54 GMT`​ を選択。 - `attributes.headers.'content-type'`​: HTTP コンテンツタイプ ​`application/json`​ を選択。 `content-type`​ などの内部属性を選択するには、名前 ​`content-type`​ を引用符で囲む必要があります。DataWeave では ​[属性名の有効な識別子](#valid_identifiers)​ で記述されたルールが内部値に適用されるため、​`date`​ のように値を引用符で囲む必要はありません。状況コード値を選択するセレクターで ​`'Status Code'`​ または ​`"Status Code"`​ ではなく ​`statusCode`​ を使用する理由については、該当のセクションの​[注意](#note_top_level_selectors)​を参照してください。 ファイルメタデータの場合、属性は異なります。たとえば、Logger コンポーネントを介してファイルメタデータを表示する ​`attributes`​ 変数を使用している場合、次の例のようなコンテンツが Studio コンソールに表示されます。 例: ファイルの属性 ```txt LocalFileAttributes[ lastModifiedTime=2019-01-20T08:17:55, lastAccessTime=2019-01-20T10:54:55, creationTime=2019-01-20T08:17:55, size=22, regularFile=true, directory=false, symbolicLink=false, path=/Users/me/Desktop/myJson.json, fileName=myJson.json ``` 各属性は、キー-値のペア (​`fileName=myJson.json`​ など) になっています。属性の値を選択するには、次のようにそのキーを参照します。 - `attributes.'fileName'`​: ファイルの名前 (​`myJson.json`​) を返す。 - `attributes.size`​: ファイルのサイズ (​`22`​) を返す。 ### [](#valid_identifiers)属性名の有効な識別子 [「有効な識別子を宣言するためのルール」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#valid-identifiers)​で説明されているルールに従う属性名については、引用符を使用せずにアクセスおよび宣言できます。 有効な識別子ではない属性を使用するには、次のいずれかの文字で属性名を囲みます。 - 単一引用符 (​`'`​) - 二重引用符 (​`"`​) - バッククォート (`` ` ``) たとえば、次の DataWeave 変数宣言について考えてみます。 ```java var myVar = { id : "1234", "123 abc !@#" : "some_value" } ``` 属性名 ​`123 abc !@#`​ は有効な識別子ではないため、引用符またはバッククォートを使用して宣言する必要があります。 属性 ​`123 abc !@#`​ の値 (​`"some_value"`​) にアクセスするには、引用符またはバッククォートを使用します。 ```none myVar.'123 abc !@#' ``` 属性名が有効な識別子の場合も、引用符またはバッククォートを使用して属性を宣言したり、属性の値を選択したりできます。 前述の変数宣言の例では、属性 ​`id`​ は引用符を使用せずに宣言されています。​`id`​ に保存された値にアクセスするには、次のいずれかの方法を使用できます。 - `myVar.id` - `myVar.'id'` - `myVar."id"` - `myVar.`​id\`\` 注意: コンソール出力に表示される、人間が解読できる最上位属性の名前 (​`Status Code`​ など) は、属性の選択で使用する名前 (​`statusCode`​) とは異なる可能性があります。人間が解読できる名前 ​`Status Code`​ を引用符で囲むと、その最上位属性が選択可能になるのではなく ​`null`​ が返されます。最上位属性名 (​`Status Code`​、​`Reason Phrase`​、​`Headers`​ など) の選択に使用する構文は、​[Studio のオートコンプリート](https://docs.mulesoft.com/studio/datasense-concept#using-datasense-for-autocomplete)​を使用して確認できるほか、コネクタのドキュメント (​[「HTTP 要求」など](#connectors::http/http-connector-xml-reference.adoc#http-request)​) で確認できます。 ## [](#関連情報)関連情報 - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-event) - [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) - [Set Payload トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.9/set-payload-transformer-reference) # Mule を使用したエンタープライズインテグレーションパターン エンタープライズインテグレーションパターンとは、特定のコンテキストで繰り返し発生する問題に対して効果が認められているソリューションです。このパターンは、メッセージングシステムやインテグレーションシステムの設計とビルドのフレームワークと、ソリューションのアーキテクト設計時のチームの共通言語を提供します。 Mule では、Gregor Hohpe と Bobby Woolf が執筆した『Enterprise Integration Patterns (エンタープライズインテグレーションパターン)』に示されているパターンのほとんどをサポートします。 Mule では、ソリューションを設計するために使用するパターンを実装することで、インテグレーションの構築に必要な労力を軽減しています。その後、単に Mule でこれらの同じパターンを設定して使用することができます。 ## [](#エンタープライズインテグレーションパターンと-mule-オブジェクトとのマッピング)エンタープライズインテグレーションパターンと Mule オブジェクトとのマッピング Mule オブジェクトに直接マッピングできるエンタープライズインテグレーションパターンを下表に示します。 ### [](#インテグレーションスタイル)インテグレーションスタイル
パターン Mule オブジェクトへのマッピング

ファイル転送

File Connector

共有データベース

Database Connector

リモートプロシージャー呼び出し

Mule API はこのプロシージャーのように機能するか、外部 API に要求を行うこともできます。

メッセージング

Mule はメッセージングを完全にサポートします。
### [](#メッセージングシステム)メッセージングシステム
パターン Mule オブジェクトへのマッピング

メッセージチャネル

Mule は、フロー内のメッセージプロセッサーを接続するメッセージチャネルを提供しています。

パイプと検索条件

フローでは、パイプおよび検索条件アーキテクチャを実装しています。

メッセージルーター

メッセージルーター​。

メッセージトランスレーター

メッセージトランスフォーマー​。

メッセージエンドポイント

メッセージソース​と​操作​。
### [](#メッセージングチャネル)メッセージングチャネル
パターン Mule オブジェクトへのマッピング

ポイントツーポイントチャネル

フロー内のデフォルトチャネル。

メッセージバス

Mule はメッセージバスです。

保証された配信

信頼性パターン​を使用。
### [](#メッセージ構築)メッセージ構築
パターン Mule オブジェクトへのマッピング

イベントメッセージ

Mule は、他のアプリケーションやプロセッサーからのイベントを送信します。

要求応答

Mule では、要求-応答の操作を容易にするコネクタ、または​信頼性パターン​を使用します。
### [](#メッセージルーティング)メッセージルーティング
パターン Mule オブジェクトへのマッピング

クライアントベースルーター

Choice ルーター​。

メッセージ検索条件

Validation Module​。

動的ルーティング

メッセージルーター​。

Scatter Gather

Scatter-Gather ルーター​。

スプリッター

foreach スコープ​、​parape​、および​バッチ​。

集約

アグリゲーターモジュール​。
### [](#メッセージトランスフォーメーション)メッセージトランスフォーメーション
パターン Mule オブジェクトへのマッピング

コンテンツエンリッチャー

対象変数​。
### [](#メッセージングエンドポイント)メッセージングエンドポイント
パターン Mule オブジェクトへのマッピング

ポーリングコンシューマー

メッセージソース​。

トランザクションクライアント

トランザクションの管理​。

羃等性レシーバー

再配信ポリシー​。
# Mule を使用したエンタープライズインテグレーションパターン エンタープライズインテグレーションパターンとは、特定のコンテキストで繰り返し発生する問題に対して効果が認められているソリューションです。このパターンは、メッセージングシステムやインテグレーションシステムの設計とビルドのフレームワークと、ソリューションのアーキテクト設計時のチームの共通言語を提供します。 Mule では、Gregor Hohpe と Bobby Woolf が執筆した『Enterprise Integration Patterns (エンタープライズインテグレーションパターン)』に示されているパターンのほとんどをサポートします。 Mule では、ソリューションを設計するために使用するパターンを実装することで、インテグレーションの構築に必要な労力を軽減しています。その後、単に Mule でこれらの同じパターンを設定して使用することができます。 ## [](#エンタープライズインテグレーションパターンと-mule-オブジェクトとのマッピング)エンタープライズインテグレーションパターンと Mule オブジェクトとのマッピング Mule オブジェクトに直接マッピングできるエンタープライズインテグレーションパターンを下表に示します。 ### [](#インテグレーションスタイル)インテグレーションスタイル
パターン Mule オブジェクトへのマッピング

ファイル転送

File Connector

共有データベース

Database Connector

リモートプロシージャー呼び出し

Mule API はこのプロシージャーのように機能するか、外部 API に要求を行うこともできます。

メッセージング

Mule はメッセージングを完全にサポートします。
### [](#メッセージングシステム)メッセージングシステム
パターン Mule オブジェクトへのマッピング

メッセージチャネル

Mule は、フロー内のメッセージプロセッサーを接続するメッセージチャネルを提供しています。

パイプと検索条件

フローでは、パイプおよび検索条件アーキテクチャを実装しています。

メッセージルーター

メッセージルーター​。

メッセージトランスレーター

メッセージトランスフォーマー​。

メッセージエンドポイント

Creating Message Sources with the Mule SDK and Operations​。
### [](#メッセージングチャネル)メッセージングチャネル
パターン Mule オブジェクトへのマッピング

ポイントツーポイントチャネル

フロー内のデフォルトチャネル。

メッセージバス

Mule はメッセージバスです。

保証された配信

信頼性パターン​を使用。
### [](#メッセージ構築)メッセージ構築
パターン Mule オブジェクトへのマッピング

イベントメッセージ

Mule は、他のアプリケーションやプロセッサーからのイベントを送信します。

要求応答

Mule では、要求-応答の操作を容易にするコネクタ、または​信頼性パターン​を使用します。
### [](#メッセージルーティング)メッセージルーティング
パターン Mule オブジェクトへのマッピング

クライアントベースルーター

Choice ルーター​。

メッセージ検索条件

Validation Module​。

動的ルーティング

メッセージルーター​。

Scatter Gather

Scatter-Gather ルーター​。

スプリッター

foreach スコープ​、​parape​、および​バッチ​。

集約

アグリゲーターモジュール​。
### [](#メッセージトランスフォーメーション)メッセージトランスフォーメーション
パターン Mule オブジェクトへのマッピング

コンテンツエンリッチャー

対象変数​。
### [](#メッセージングエンドポイント)メッセージングエンドポイント
パターン Mule オブジェクトへのマッピング

ポーリングコンシューマー

Creating Message Sources with the Mule SDK。

トランザクションクライアント

トランザクションの管理​。

羃等性レシーバー

再配信ポリシー​。
# Mule を使用したエンタープライズインテグレーションパターン エンタープライズインテグレーションパターンとは、特定のコンテキストで繰り返し発生する問題に対して効果が認められているソリューションです。このパターンは、メッセージングシステムやインテグレーションシステムの設計とビルドのフレームワークと、ソリューションのアーキテクト設計時のチームの共通言語を提供します。 Mule では、Gregor Hohpe と Bobby Woolf が執筆した『Enterprise Integration Patterns (エンタープライズインテグレーションパターン)』に示されているパターンのほとんどをサポートします。 Mule では、ソリューションを設計するために使用するパターンを実装することで、インテグレーションの構築に必要な労力を軽減しています。その後、単に Mule でこれらの同じパターンを設定して使用することができます。 ## [](#エンタープライズインテグレーションパターンと-mule-オブジェクトとのマッピング)エンタープライズインテグレーションパターンと Mule オブジェクトとのマッピング Mule オブジェクトに直接マッピングできるエンタープライズインテグレーションパターンを下表に示します。 ### [](#インテグレーションスタイル)インテグレーションスタイル
パターン Mule オブジェクトへのマッピング

ファイル転送

File Connector

共有データベース

DataBase Connector

リモートプロシージャー呼び出し

Mule API はこのプロシージャーのように機能するか、外部 API に要求を行うこともできます。

メッセージング

Mule はメッセージングを完全にサポートします。
### [](#メッセージングシステム)メッセージングシステム
パターン Mule オブジェクトへのマッピング

メッセージチャネル

Mule は、フロー内のメッセージプロセッサーを接続するメッセージチャネルを提供しています。

パイプとフィルター

フローでは、パイプおよびフィルターアーキテクチャを実装しています。

メッセージルーター

メッセージルーター​。

メッセージトランスレーター

メッセージトランスフォーマー​。

メッセージエンドポイント

Creating Message Sources with the Mule SDK and Operations​.
### [](#メッセージングチャネル)メッセージングチャネル
パターン Mule オブジェクトへのマッピング

ポイントツーポイントチャネル

フロー内のデフォルトチャネル。

メッセージバス

Mule はメッセージバスです。

保証された配信

信頼性パターン​を使用。
### [](#メッセージ構築)メッセージ構築
パターン Mule オブジェクトへのマッピング

イベントメッセージ

Mule は、他のアプリケーションやプロセッサーからのイベントを送信します。

要求応答

Mule では、要求-返信の操作を容易にするコネクタ、または​信頼性パターン​を使用します。
### [](#メッセージルーティング)メッセージルーティング
パターン Mule オブジェクトへのマッピング

クライアントベースルーター

Choice ルーター​。

メッセージ検索条件

Validation Module​。

動的ルーティング

メッセージルーター​。

Scatter Gather

Scatter-Gather ルーター​。

スプリッター

foreach スコープ​、​parape​、および​バッチ​。

集約

アグリゲーターモジュール​。
### [](#メッセージトランスフォーメーション)メッセージトランスフォーメーション
パターン Mule オブジェクトへのマッピング

コンテンツエンリッチャー

対象変数​。
### [](#メッセージングエンドポイント)メッセージングエンドポイント
パターン Mule オブジェクトへのマッピング

ポーリングコンシューマー

Creating Message Sources with the Mule SDK。

トランザクションクライアント

トランザクションの管理​。

羃等性レシーバー

再配信ポリシー​。
# Mule を使用したエンタープライズインテグレーションパターン エンタープライズインテグレーションパターンとは、特定のコンテキストで繰り返し発生する問題に対して効果が認められているソリューションです。このパターンは、メッセージングシステムやインテグレーションシステムの設計とビルドのフレームワークと、ソリューションのアーキテクト設計時のチームの共通言語を提供します。 Mule では、Gregor Hohpe と Bobby Woolf が執筆した『Enterprise Integration Patterns (エンタープライズインテグレーションパターン)』に示されているパターンのほとんどをサポートします。 Mule では、ソリューションを設計するために使用するパターンを実装することで、インテグレーションの構築に必要な労力を軽減しています。その後、単に Mule でこれらの同じパターンを設定して使用することができます。 ## [](#エンタープライズインテグレーションパターンと-mule-オブジェクトとのマッピング)エンタープライズインテグレーションパターンと Mule オブジェクトとのマッピング Mule オブジェクトに直接マッピングできるエンタープライズインテグレーションパターンを下表に示します。 ### [](#インテグレーションスタイル)インテグレーションスタイル
パターン Mule オブジェクトへのマッピング

ファイル転送

File Connector

共有データベース

Database Connector

リモートプロシージャー呼び出し

Mule API はこのプロシージャーのように機能するか、外部 API に要求を行うこともできます。

メッセージング

Mule はメッセージングを完全にサポートします。
### [](#メッセージングシステム)メッセージングシステム
パターン Mule オブジェクトへのマッピング

メッセージチャネル

Mule は、フロー内のメッセージプロセッサーを接続するメッセージチャネルを提供しています。

パイプと検索条件

フローでは、パイプおよび検索条件アーキテクチャを実装しています。

メッセージルーター

メッセージルーター​。

メッセージトランスレーター

メッセージトランスフォーマー​。

メッセージエンドポイント

Creating Message Sources with the Mule SDK and Operations​。
### [](#メッセージングチャネル)メッセージングチャネル
パターン Mule オブジェクトへのマッピング

ポイントツーポイントチャネル

フロー内のデフォルトチャネル。

メッセージバス

Mule はメッセージバスです。

保証された配信

信頼性パターン​を使用。
### [](#メッセージ構築)メッセージ構築
パターン Mule オブジェクトへのマッピング

イベントメッセージ

Mule は、他のアプリケーションやプロセッサーからのイベントを送信します。

要求応答

Mule では、要求-応答の操作を容易にするコネクタ、または​信頼性パターン​を使用します。
### [](#メッセージルーティング)メッセージルーティング
パターン Mule オブジェクトへのマッピング

クライアントベースルーター

Choice ルーター​。

メッセージ検索条件

Validation Module​。

動的ルーティング

メッセージルーター​。

Scatter Gather

Scatter-Gather ルーター​。

スプリッター

foreach スコープ​、​parape​、および​バッチ​。

集約

アグリゲーターモジュール​。
### [](#メッセージトランスフォーメーション)メッセージトランスフォーメーション
パターン Mule オブジェクトへのマッピング

コンテンツエンリッチャー

対象変数​。
### [](#メッセージングエンドポイント)メッセージングエンドポイント
パターン Mule オブジェクトへのマッピング

ポーリングコンシューマー

Creating Message Sources with the Mule SDK。

トランザクションクライアント

トランザクションの管理​。

羃等性レシーバー

再配信ポリシー​。
# Mule を使用したエンタープライズインテグレーションパターン エンタープライズインテグレーションパターンとは、特定のコンテキストで繰り返し発生する問題に対して効果が認められているソリューションです。このパターンは、メッセージングシステムやインテグレーションシステムの設計とビルドのフレームワークと、ソリューションのアーキテクト設計時のチームの共通言語を提供します。 Mule では、Gregor Hohpe と Bobby Woolf が執筆した『Enterprise Integration Patterns (エンタープライズインテグレーションパターン)』に示されているパターンのほとんどをサポートします。 Mule では、ソリューションを設計するために使用するパターンを実装することで、インテグレーションの構築に必要な労力を軽減しています。その後、単に Mule でこれらの同じパターンを設定して使用することができます。 ## [](#エンタープライズインテグレーションパターンと-mule-オブジェクトとのマッピング)エンタープライズインテグレーションパターンと Mule オブジェクトとのマッピング Mule オブジェクトに直接マッピングできるエンタープライズインテグレーションパターンを下表に示します。 ### [](#インテグレーションスタイル)インテグレーションスタイル
パターン Mule オブジェクトへのマッピング

ファイル転送

File Connector

共有データベース

DataBase Connector

リモートプロシージャー呼び出し

Mule API はこのプロシージャーのように機能するか、外部 API に要求を行うこともできます。

メッセージング

Mule はメッセージングを完全にサポートします。
### [](#メッセージングシステム)メッセージングシステム
パターン Mule オブジェクトへのマッピング

メッセージチャネル

Mule は、フロー内のメッセージプロセッサーを接続するメッセージチャネルを提供しています。

パイプと検索条件

フローでは、パイプおよび検索条件アーキテクチャを実装しています。

メッセージルーター

メッセージルーター​。

メッセージトランスレーター

メッセージトランスフォーマー​。

メッセージエンドポイント

Creating Message Sources with the Mule SDK and Operations​。
### [](#メッセージングチャネル)メッセージングチャネル
パターン Mule オブジェクトへのマッピング

ポイントツーポイントチャネル

フロー内のデフォルトチャネル。

メッセージバス

Mule はメッセージバスです。

保証された配信

信頼性パターン​を使用。
### [](#メッセージ構築)メッセージ構築
パターン Mule オブジェクトへのマッピング

イベントメッセージ

Mule は、他のアプリケーションやプロセッサーからのイベントを送信します。

要求応答

Mule では、要求-返信の操作を容易にするコネクタ、または​信頼性パターン​を使用します。
### [](#メッセージルーティング)メッセージルーティング
パターン Mule オブジェクトへのマッピング

クライアントベースルーター

Choice ルーター​。

メッセージ検索条件

Validation Module​。

動的ルーティング

メッセージルーター​。

Scatter Gather

Scatter-Gather ルーター​。

スプリッター

foreach スコープ​、​parape​、および​バッチ​。

集約

アグリゲーターモジュール​。
### [](#メッセージトランスフォーメーション)メッセージトランスフォーメーション
パターン Mule オブジェクトへのマッピング

コンテンツエンリッチャー

対象変数​。
### [](#メッセージングエンドポイント)メッセージングエンドポイント
パターン Mule オブジェクトへのマッピング

ポーリングコンシューマー

Creating Message Sources with the Mule SDK。

トランザクションクライアント

トランザクションの管理​。

羃等性レシーバー

再配信ポリシー​。
# Mule を使用したエンタープライズインテグレーションパターン エンタープライズインテグレーションパターンとは、特定のコンテキストで繰り返し発生する問題に対して効果が認められているソリューションです。このパターンは、メッセージングシステムやインテグレーションシステムの設計とビルドのフレームワークと、ソリューションのアーキテクト設計時のチームの共通言語を提供します。 Mule では、Gregor Hohpe と Bobby Woolf が執筆した『Enterprise Integration Patterns (エンタープライズインテグレーションパターン)』に示されているパターンのほとんどをサポートします。 Mule では、ソリューションを設計するために使用するパターンを実装することで、インテグレーションの構築に必要な労力を軽減しています。その後、単に Mule でこれらの同じパターンを設定して使用することができます。 ## [](#エンタープライズインテグレーションパターンと-mule-オブジェクトとのマッピング)エンタープライズインテグレーションパターンと Mule オブジェクトとのマッピング Mule オブジェクトに直接マッピングできるエンタープライズインテグレーションパターンを下表に示します。 ### [](#インテグレーションスタイル)インテグレーションスタイル
パターン Mule オブジェクトへのマッピング

ファイル転送

File Connector

共有データベース

DataBase Connector

リモートプロシージャー呼び出し

Mule API はこのプロシージャーのように機能するか、外部 API に要求を行うこともできます。

メッセージング

Mule はメッセージングを完全にサポートします。
### [](#メッセージングシステム)メッセージングシステム
パターン Mule オブジェクトへのマッピング

メッセージチャネル

Mule は、フロー内のメッセージプロセッサーを接続するメッセージチャネルを提供しています。

パイプと検索条件

フローでは、パイプおよび検索条件アーキテクチャを実装しています。

メッセージルーター

メッセージルーター​。

メッセージトランスレーター

メッセージトランスフォーマー​。

メッセージエンドポイント

Creating Message Sources with the Mule SDK and Operations​。
### [](#メッセージングチャネル)メッセージングチャネル
パターン Mule オブジェクトへのマッピング

ポイントツーポイントチャネル

フロー内のデフォルトチャネル。

メッセージバス

Mule はメッセージバスです。

保証された配信

信頼性パターン​を使用。
### [](#メッセージ構築)メッセージ構築
パターン Mule オブジェクトへのマッピング

イベントメッセージ

Mule は、他のアプリケーションやプロセッサーからのイベントを送信します。

要求応答

Mule では、要求-返信の操作を容易にするコネクタ、または​信頼性パターン​を使用します。
### [](#メッセージルーティング)メッセージルーティング
パターン Mule オブジェクトへのマッピング

クライアントベースルーター

Choice ルーター​。

メッセージ検索条件

Validation Module​。

動的ルーティング

メッセージルーター​。

Scatter Gather

Scatter-Gather ルーター​。

スプリッター

foreach スコープ​、​parape​、および​バッチ​。

集約

アグリゲーターモジュール​。
### [](#メッセージトランスフォーメーション)メッセージトランスフォーメーション
パターン Mule オブジェクトへのマッピング

コンテンツエンリッチャー

対象変数​。
### [](#メッセージングエンドポイント)メッセージングエンドポイント
パターン Mule オブジェクトへのマッピング

ポーリングコンシューマー

Creating Message Sources with the Mule SDK。

トランザクションクライアント

トランザクションの管理​。

羃等性レシーバー

再配信ポリシー​。
# Mule を使用したエンタープライズインテグレーションパターン エンタープライズインテグレーションパターンとは、特定のコンテキストで繰り返し発生する問題に対して効果が認められているソリューションです。このパターンは、メッセージングシステムやインテグレーションシステムの設計とビルドのフレームワークと、ソリューションのアーキテクト設計時のチームの共通言語を提供します。 Mule では、Gregor Hohpe と Bobby Woolf が執筆した『Enterprise Integration Patterns (エンタープライズインテグレーションパターン)』に示されているパターンのほとんどをサポートします。 Mule では、ソリューションを設計するために使用するパターンを実装することで、インテグレーションの構築に必要な労力を軽減しています。その後、単に Mule でこれらの同じパターンを設定して使用することができます。 ## [](#エンタープライズインテグレーションパターンと-mule-オブジェクトとのマッピング)エンタープライズインテグレーションパターンと Mule オブジェクトとのマッピング Mule オブジェクトに直接マッピングできるエンタープライズインテグレーションパターンを下表に示します。 ### [](#インテグレーションスタイル)インテグレーションスタイル
パターン Mule オブジェクトへのマッピング

ファイル転送

File Connector

共有データベース

DataBase Connector

リモートプロシージャー呼び出し

Mule API はこのプロシージャーのように機能するか、外部 API に要求を行うこともできます。

メッセージング

Mule はメッセージングを完全にサポートします。
### [](#メッセージングシステム)メッセージングシステム
パターン Mule オブジェクトへのマッピング

メッセージチャネル

Mule は、フロー内のメッセージプロセッサーを接続するメッセージチャネルを提供しています。

パイプと検索条件

フローでは、パイプおよび検索条件アーキテクチャを実装しています。

メッセージルーター

メッセージルーター​。

メッセージトランスレーター

メッセージトランスフォーマー​。

メッセージエンドポイント

Creating Message Sources with the Mule SDK and Operations​。
### [](#メッセージングチャネル)メッセージングチャネル
パターン Mule オブジェクトへのマッピング

ポイントツーポイントチャネル

フロー内のデフォルトチャネル。

メッセージバス

Mule はメッセージバスです。

保証された配信

信頼性パターン​を使用。
### [](#メッセージ構築)メッセージ構築
パターン Mule オブジェクトへのマッピング

イベントメッセージ

Mule は、他のアプリケーションやプロセッサーからのイベントを送信します。

要求応答

Mule では、要求-返信の操作を容易にするコネクタ、または​信頼性パターン​を使用します。
### [](#メッセージルーティング)メッセージルーティング
パターン Mule オブジェクトへのマッピング

クライアントベースルーター

Choice ルーター​。

メッセージ検索条件

Validation Module​。

動的ルーティング

メッセージルーター​。

Scatter Gather

Scatter-Gather ルーター​。

スプリッター

foreach スコープ​、​parape​、および​バッチ​。

集約

アグリゲーターモジュール​。
### [](#メッセージトランスフォーメーション)メッセージトランスフォーメーション
パターン Mule オブジェクトへのマッピング

コンテンツエンリッチャー

対象変数​。
### [](#メッセージングエンドポイント)メッセージングエンドポイント
パターン Mule オブジェクトへのマッピング

ポーリングコンシューマー

Creating Message Sources with the Mule SDK。

トランザクションクライアント

トランザクションの管理​。

羃等性レシーバー

再配信ポリシー​。
# Mule を使用したオーケストレーション オーケストレーションとは、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にする手段です。オーケストレーションは、サービス呼び出しを組み合わせて、より抽象的で便利な複合サービスを作成する処理と考えることができ、いろいろなアプリケーションや情報システムに渡ってビジネス特有のサービスを組み合わせたビジネスレベルのプロセスを実装することを意味します。 ## [](#オーケストレーションとフロー)オーケストレーションとフロー オーケストレーションでは、ポイントツーポイントのインテグレーションを分離して、システムニーズやビジネスニーズの変化に合わせて再利用したり変更したりできる操作のチェーンを使用します。具体的には、パターンには縛られずにサービスベースのフレームワークへの移動を行い、複数のコンポーネントをソースでラップすることで、プロトコルやルーティング要件から分離します。これにより、実装要件で必要であれば、複数のサービスを 1 つにまとめて機能させることができます。フローがサービスのオーケストレーションをよく行う一般的なユースケースを挙げます。 - シンプルなインテグレーション - データ処理のスケジューリング - クラウドアプリケーションとオンプレミスアプリケーションの接続 - 複数のサービスを構成して同時に動作させる必要があるイベント処理 ## [](#フローによるオーケストレーション実装の実現)フローによるオーケストレーション実装の実現 フローは、サービス仲介の新しいオーケストレーション方法を提供しています。たとえば、任意の数のソース、ルーター、およびコンポーネントを一緒に機能するように組み合わせることで、実装の要件を達成することができます。また、フロー特有のルーターに基づいた新しい形態のデータ移動のオーケストレーションも可能です。オーケストレーションによって、フローとコンポーネントチェーンを作成して再利用したり、複数のコンポーネントを 1 つのフローに連結したり、フローの任意の場所でソースやコネクタを統合したりできます。 ## [](#オーケストレーションを使用する状況)オーケストレーションを使用する状況 オーケストレーションは、既存のサービスを組み合わせることによってビジネス要件を満足させる必要がある場合に使用します。たとえば、給与システムと HR システムの両方に入力する必要のある新しい従業員を追加する場合などには、オーケストレーションを使用すると便利です。注文処理にもオーケストレーションを利用できます。この場合は、オーケストレーションを使用して注文を受け付け、注文が在庫システムに登録されていることを確認し、クレジットチェックシステムを使用して顧客のクレジットの信頼性を確認して、注文を請求システムと発送システムに入力します。 ## [](#オーケストレーションの例)オーケストレーションの例 このオーケストレーションの例では、フローを使用して以下の処理を行います。 1. ファイルのコンテンツを、1 つまたは複数の特定の注文を含む標準形式に変換します。 2. 注文を別々の処理用に分割し、書籍以外の注文を除外します。 3. 2 つのサービスを呼び出します。1 つは注文された書籍の在庫があるかどうかを確認し、もう 1 つは顧客の注文を作成します。 4. 注文情報を顧客にメールで送信し、データベースに保存します。 このプロセスのいずれかのステップが失敗した場合、メッセージは失敗した注文の JMS キューに登録されます。影響を受ける注文を表示、修正してから、再び送信できます。 ```xml INSERT INTO ORDERS(CUSTOMER, AMOUNT) VALUES (:id, :amount) ``` ## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-flows) # Mule を使用したオーケストレーション オーケストレーションとは、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にする手段です。オーケストレーションは、サービス呼び出しを組み合わせて、より抽象的で便利な複合サービスを作成する処理と考えることができ、いろいろなアプリケーションや情報システムに渡ってビジネス特有のサービスを組み合わせたビジネスレベルのプロセスを実装することを意味します。 ## [](#オーケストレーションとフロー)オーケストレーションとフロー オーケストレーションでは、ポイントツーポイントのインテグレーションを分離して、システムニーズやビジネスニーズの変化に合わせて再利用したり変更したりできる操作のチェーンを使用します。具体的には、パターンには縛られずにサービスベースのフレームワークへの移動を行い、複数のコンポーネントをソースでラップすることで、プロトコルやルーティング要件から分離します。これにより、実装要件で必要であれば、複数のサービスを 1 つにまとめて機能させることができます。フローがサービスのオーケストレーションをよく行う一般的なユースケースを挙げます。 - シンプルなインテグレーション - データ処理のスケジューリング - クラウドアプリケーションとオンプレミスアプリケーションの接続 - 複数のサービスを構成して同時に動作させる必要があるイベント処理 ## [](#フローによるオーケストレーション実装の実現)フローによるオーケストレーション実装の実現 フローは、サービス仲介の新しいオーケストレーション方法を提供しています。たとえば、任意の数のソース、ルーター、およびコンポーネントを一緒に機能するように組み合わせることで、実装の要件を達成することができます。また、フロー特有のルーターに基づいた新しい形態のデータ移動のオーケストレーションも可能です。オーケストレーションによって、フローとコンポーネントチェーンを作成して再利用したり、複数のコンポーネントを 1 つのフローに連結したり、フローの任意の場所でソースやコネクタを統合したりできます。 ## [](#オーケストレーションを使用する状況)オーケストレーションを使用する状況 オーケストレーションは、既存のサービスを組み合わせることによってビジネス要件を満足させる必要がある場合に使用します。たとえば、給与システムと HR システムの両方に入力する必要のある新しい従業員を追加する場合などには、オーケストレーションを使用すると便利です。注文処理にもオーケストレーションを利用できます。この場合は、オーケストレーションを使用して注文を受け付け、注文が在庫システムに登録されていることを確認し、クレジットチェックシステムを使用して顧客のクレジットの信頼性を確認して、注文を請求システムと発送システムに入力します。 ## [](#オーケストレーションの例)オーケストレーションの例 このオーケストレーションの例では、フローを使用して以下の処理を行います。 1. ファイルのコンテンツを、1 つまたは複数の特定の注文を含む標準形式に変換します。 2. 注文を別々の処理用に分割し、書籍以外の注文を除外します。 3. 2 つのサービスを呼び出します。1 つは注文された書籍の在庫があるかどうかを確認し、もう 1 つは顧客の注文を作成します。 4. 注文情報を顧客にメールで送信し、データベースに保存します。 このプロセスのいずれかのステップが失敗した場合、メッセージは失敗した注文の JMS キューに登録されます。影響を受ける注文を表示、修正してから、再び送信できます。 ```xml INSERT INTO ORDERS(CUSTOMER, AMOUNT) VALUES (:id, :amount) ``` ## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-flows) # Mule を使用したオーケストレーション オーケストレーションとは、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にする手段です。オーケストレーションは、サービス呼び出しを組み合わせて、より抽象的で便利な複合サービスを作成する処理と考えることができ、いろいろなアプリケーションや情報システムに渡ってビジネス特有のサービスを組み合わせたビジネスレベルのプロセスを実装することを意味します。 ## [](#オーケストレーションとフロー)オーケストレーションとフロー オーケストレーションでは、ポイントツーポイントのインテグレーションを分離して、システムニーズやビジネスニーズの変化に合わせて再利用したり変更したりできる操作のチェーンを使用します。具体的には、パターンには縛られずにサービスベースのフレームワークへの移動を行い、複数のコンポーネントをソースでラップすることで、プロトコルやルーティング要件から分離します。これにより、実装要件で必要であれば、複数のサービスを 1 つにまとめて機能させることができます。フローがサービスのオーケストレーションをよく行う一般的なユースケースを挙げます。 - シンプルなインテグレーション - データ処理のスケジューリング - クラウドアプリケーションとオンプレミスアプリケーションの接続 - 複数のサービスを構成して同時に動作させる必要があるイベント処理 ## [](#フローによるオーケストレーション実装の実現)フローによるオーケストレーション実装の実現 フローは、サービス仲介の新しいオーケストレーション方法を提供しています。たとえば、任意の数の接続元、ルーター、およびコンポーネントを一緒に機能するように組み合わせることで、実装の要件を達成することができます。また、フロー特有のルーターに基づいた新しい形態のデータ移動のオーケストレーションも可能です。オーケストレーションによって、フローとコンポーネントチェーンを作成して再利用したり、複数のコンポーネントを 1 つのフローに連結したり、フローの任意の場所で接続元やコネクタを統合したりできます。 ## [](#オーケストレーションを使用する状況)オーケストレーションを使用する状況 オーケストレーションは、既存のサービスを組み合わせることによってビジネス要件を満足させる必要がある場合に使用します。たとえば、給与システムと HR システムの両方に入力する必要のある新しい従業員を追加する場合などには、オーケストレーションを使用すると便利です。注文処理にもオーケストレーションを利用できます。この場合は、オーケストレーションを使用して注文を受け付け、注文が在庫システムに登録されていることを確認し、クレジットチェックシステムを使用して顧客のクレジットの信頼性を確認して、注文を請求システムと発送システムに入力します。 ## [](#オーケストレーションの例)オーケストレーションの例 このオーケストレーションの例では、フローを使用して以下の処理を行います。 1. ファイルの内容を、1 つまたは複数の特定の注文を含む標準形式に変換します。 2. 注文を別々の処理用に分割し、書籍以外の注文を除外します。 3. 2 つのサービスを呼び出します。1 つは注文された書籍の在庫があるかどうかを確認し、もう 1 つは顧客の注文を作成します。 4. 注文情報を顧客にメールで送信し、データベースに保存します。 このプロセスのいずれかのステップが失敗した場合、メッセージは失敗した注文の JMS キューに登録されます。影響を受ける注文を表示、修正してから、再び送信できます。 ```xml INSERT INTO ORDERS(CUSTOMER, AMOUNT) VALUES (:id, :amount) ``` ## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-flows) # Mule を使用したオーケストレーション オーケストレーションとは、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にする手段です。オーケストレーションは、サービス呼び出しを組み合わせて、より抽象的で便利な複合サービスを作成する処理と考えることができ、いろいろなアプリケーションや情報システムに渡ってビジネス特有のサービスを組み合わせたビジネスレベルのプロセスを実装することを意味します。 ## [](#オーケストレーションとフロー)オーケストレーションとフロー オーケストレーションでは、ポイントツーポイントのインテグレーションを分離して、システムニーズやビジネスニーズの変化に合わせて再利用したり変更したりできる操作のチェーンを使用します。具体的には、パターンには縛られずにサービスベースのフレームワークへの移動を行い、複数のコンポーネントをソースでラップすることで、プロトコルやルーティング要件から分離します。これにより、実装要件で必要であれば、複数のサービスを 1 つにまとめて機能させることができます。フローがサービスのオーケストレーションをよく行う一般的なユースケースを挙げます。 - シンプルなインテグレーション - データ処理のスケジューリング - クラウドアプリケーションとオンプレミスアプリケーションの接続 - 複数のサービスを構成して同時に動作させる必要があるイベント処理 ## [](#フローによるオーケストレーション実装の実現)フローによるオーケストレーション実装の実現 フローは、サービス仲介の新しいオーケストレーション方法を提供しています。たとえば、任意の数の接続元、ルーター、およびコンポーネントを一緒に機能するように組み合わせることで、実装の要件を達成することができます。また、フロー特有のルーターに基づいた新しい形態のデータ移動のオーケストレーションも可能です。オーケストレーションによって、フローとコンポーネントチェーンを作成して再利用したり、複数のコンポーネントを 1 つのフローに連結したり、フローの任意の場所で接続元やコネクタを統合したりできます。 ## [](#オーケストレーションを使用する状況)オーケストレーションを使用する状況 オーケストレーションは、既存のサービスを組み合わせることによってビジネス要件を満足させる必要がある場合に使用します。たとえば、給与システムと HR システムの両方に入力する必要のある新しい従業員を追加する場合などには、オーケストレーションを使用すると便利です。注文処理にもオーケストレーションを利用できます。この場合は、オーケストレーションを使用して注文を受け付け、注文が在庫システムに登録されていることを確認し、クレジットチェックシステムを使用して顧客のクレジットの信頼性を確認して、注文を請求システムと発送システムに入力します。 ## [](#オーケストレーションの例)オーケストレーションの例 このオーケストレーションの例では、フローを使用して以下の処理を行います。 1. ファイルのコンテンツを、1 つまたは複数の特定の注文を含む標準形式に変換します。 2. 注文を別々の処理用に分割し、書籍以外の注文を除外します。 3. 2 つのサービスを呼び出します。1 つは注文された書籍の在庫があるかどうかを確認し、もう 1 つは顧客の注文を作成します。 4. 注文情報を顧客にメールで送信し、データベースに保存します。 このプロセスのいずれかのステップが失敗した場合、メッセージは失敗した注文の JMS キューに登録されます。影響を受ける注文を表示、修正してから、再び送信できます。 ```xml INSERT INTO ORDERS(CUSTOMER, AMOUNT) VALUES (:id, :amount) ``` ## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-flows) # Mule を使用したオーケストレーション オーケストレーションとは、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にする手段です。オーケストレーションは、サービス呼び出しを組み合わせて、より抽象的で便利な複合サービスを作成する処理と考えることができ、いろいろなアプリケーションや情報システムに渡ってビジネス特有のサービスを組み合わせたビジネスレベルのプロセスを実装することを意味します。 ## [](#オーケストレーションとフロー)オーケストレーションとフロー オーケストレーションでは、ポイントツーポイントのインテグレーションを分離して、システムニーズやビジネスニーズの変化に合わせて再利用したり変更したりできる操作のチェーンを使用します。具体的には、パターンには縛られずにサービスベースのフレームワークへの移動を行い、複数のコンポーネントをソースでラップすることで、プロトコルやルーティング要件から分離します。これにより、実装要件で必要であれば、複数のサービスを 1 つにまとめて機能させることができます。フローがサービスのオーケストレーションをよく行う一般的なユースケースを挙げます。 - シンプルなインテグレーション - データ処理のスケジューリング - クラウドアプリケーションとオンプレミスアプリケーションの接続 - 複数のサービスを構成して同時に動作させる必要があるイベント処理 ## [](#フローによるオーケストレーション実装の実現)フローによるオーケストレーション実装の実現 フローは、サービス仲介の新しいオーケストレーション方法を提供しています。たとえば、任意の数の接続元、ルーター、およびコンポーネントを一緒に機能するように組み合わせることで、実装の要件を達成することができます。また、フロー特有のルーターに基づいた新しい形態のデータ移動のオーケストレーションも可能です。オーケストレーションによって、フローとコンポーネントチェーンを作成して再利用したり、複数のコンポーネントを 1 つのフローに連結したり、フローの任意の場所で接続元やコネクタを統合したりできます。 ## [](#オーケストレーションを使用する状況)オーケストレーションを使用する状況 オーケストレーションは、既存のサービスを組み合わせることによってビジネス要件を満足させる必要がある場合に使用します。たとえば、給与システムと HR システムの両方に入力する必要のある新しい従業員を追加する場合などには、オーケストレーションを使用すると便利です。注文処理にもオーケストレーションを利用できます。この場合は、オーケストレーションを使用して注文を受け付け、注文が在庫システムに登録されていることを確認し、クレジットチェックシステムを使用して顧客のクレジットの信頼性を確認して、注文を請求システムと発送システムに入力します。 ## [](#オーケストレーションの例)オーケストレーションの例 このオーケストレーションの例では、フローを使用して以下の処理を行います。 1. ファイルのコンテンツを、1 つまたは複数の特定の注文を含む標準形式に変換します。 2. 注文を別々の処理用に分割し、書籍以外の注文を除外します。 3. 2 つのサービスを呼び出します。1 つは注文された書籍の在庫があるかどうかを確認し、もう 1 つは顧客の注文を作成します。 4. 注文情報を顧客にメールで送信し、データベースに保存します。 このプロセスのいずれかのステップが失敗した場合、メッセージは失敗した注文の JMS キューに登録されます。影響を受ける注文を表示、修正してから、再び送信できます。 ```xml INSERT INTO ORDERS(CUSTOMER, AMOUNT) VALUES (:id, :amount) ``` ## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-flows) # Mule を使用したオーケストレーション オーケストレーションとは、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にする手段です。オーケストレーションは、サービス呼び出しを組み合わせて、より抽象的で便利な複合サービスを作成する処理と考えることができ、いろいろなアプリケーションや情報システムに渡ってビジネス特有のサービスを組み合わせたビジネスレベルのプロセスを実装することを意味します。 ## [](#オーケストレーションとフロー)オーケストレーションとフロー オーケストレーションでは、ポイントツーポイントのインテグレーションを分離して、システムニーズやビジネスニーズの変化に合わせて再利用したり変更したりできる操作のチェーンを使用します。具体的には、パターンには縛られずにサービスベースのフレームワークへの移動を行い、複数のコンポーネントをソースでラップすることで、プロトコルやルーティング要件から分離します。これにより、実装要件で必要であれば、複数のサービスを 1 つにまとめて機能させることができます。フローがサービスのオーケストレーションをよく行う一般的なユースケースを挙げます。 - シンプルなインテグレーション - データ処理のスケジューリング - クラウドアプリケーションとオンプレミスアプリケーションの接続 - 複数のサービスを構成して同時に動作させる必要があるイベント処理 ## [](#フローによるオーケストレーション実装の実現)フローによるオーケストレーション実装の実現 フローは、サービス仲介の新しいオーケストレーション方法を提供しています。たとえば、任意の数の接続元、ルーター、およびコンポーネントを一緒に機能するように組み合わせることで、実装の要件を達成することができます。また、フロー特有のルーターに基づいた新しい形態のデータ移動のオーケストレーションも可能です。オーケストレーションによって、フローとコンポーネントチェーンを作成して再利用したり、複数のコンポーネントを 1 つのフローに連結したり、フローの任意の場所で接続元やコネクタを統合したりできます。 ## [](#オーケストレーションを使用する状況)オーケストレーションを使用する状況 オーケストレーションは、既存のサービスを組み合わせることによってビジネス要件を満足させる必要がある場合に使用します。たとえば、給与システムと HR システムの両方に入力する必要のある新しい従業員を追加する場合などには、オーケストレーションを使用すると便利です。注文処理にもオーケストレーションを利用できます。この場合は、オーケストレーションを使用して注文を受け付け、注文が在庫システムに登録されていることを確認し、クレジットチェックシステムを使用して顧客のクレジットの信頼性を確認して、注文を請求システムと発送システムに入力します。 ## [](#オーケストレーションの例)オーケストレーションの例 このオーケストレーションの例では、フローを使用して以下の処理を行います。 1. ファイルのコンテンツを、1 つまたは複数の特定の注文を含む標準形式に変換します。 2. 注文を別々の処理用に分割し、書籍以外の注文を除外します。 3. 2 つのサービスを呼び出します。1 つは注文された書籍の在庫があるかどうかを確認し、もう 1 つは顧客の注文を作成します。 4. 注文情報を顧客にメールで送信し、データベースに保存します。 このプロセスのいずれかのステップが失敗した場合、メッセージは失敗した注文の JMS キューに登録されます。影響を受ける注文を表示、修正してから、再び送信できます。 ```xml INSERT INTO ORDERS(CUSTOMER, AMOUNT) VALUES (:id, :amount) ``` ## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-flows) # Mule を使用したオーケストレーション オーケストレーションとは、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にする手段です。オーケストレーションは、サービス呼び出しを組み合わせて、より抽象的で便利な複合サービスを作成する処理と考えることができ、いろいろなアプリケーションや情報システムに渡ってビジネス特有のサービスを組み合わせたビジネスレベルのプロセスを実装することを意味します。 ## [](#オーケストレーションとフロー)オーケストレーションとフロー オーケストレーションでは、ポイントツーポイントのインテグレーションを分離して、システムニーズやビジネスニーズの変化に合わせて再利用したり変更したりできる操作のチェーンを使用します。具体的には、パターンには縛られずにサービスベースのフレームワークへの移動を行い、複数のコンポーネントをソースでラップすることで、プロトコルやルーティング要件から分離します。これにより、実装要件で必要であれば、複数のサービスを 1 つにまとめて機能させることができます。フローがサービスのオーケストレーションをよく行う一般的なユースケースを挙げます。 - シンプルなインテグレーション - データ処理のスケジューリング - クラウドアプリケーションとオンプレミスアプリケーションの接続 - 複数のサービスを構成して同時に動作させる必要があるイベント処理 ## [](#フローによるオーケストレーション実装の実現)フローによるオーケストレーション実装の実現 フローは、サービス仲介の新しいオーケストレーション方法を提供しています。たとえば、任意の数の接続元、ルーター、およびコンポーネントを一緒に機能するように組み合わせることで、実装の要件を達成することができます。また、フロー特有のルーターに基づいた新しい形態のデータ移動のオーケストレーションも可能です。オーケストレーションによって、フローとコンポーネントチェーンを作成して再利用したり、複数のコンポーネントを 1 つのフローに連結したり、フローの任意の場所で接続元やコネクタを統合したりできます。 ## [](#オーケストレーションを使用する状況)オーケストレーションを使用する状況 オーケストレーションは、既存のサービスを組み合わせることによってビジネス要件を満足させる必要がある場合に使用します。たとえば、給与システムと HR システムの両方に入力する必要のある新しい従業員を追加する場合などには、オーケストレーションを使用すると便利です。注文処理にもオーケストレーションを利用できます。この場合は、オーケストレーションを使用して注文を受け付け、注文が在庫システムに登録されていることを確認し、クレジットチェックシステムを使用して顧客のクレジットの信頼性を確認して、注文を請求システムと発送システムに入力します。 ## [](#オーケストレーションの例)オーケストレーションの例 このオーケストレーションの例では、フローを使用して以下の処理を行います。 1. ファイルのコンテンツを、1 つまたは複数の特定の注文を含む標準形式に変換します。 2. 注文を別々の処理用に分割し、書籍以外の注文を除外します。 3. 2 つのサービスを呼び出します。1 つは注文された書籍の在庫があるかどうかを確認し、もう 1 つは顧客の注文を作成します。 4. 注文情報を顧客にメールで送信し、データベースに保存します。 このプロセスのいずれかのステップが失敗した場合、メッセージは失敗した注文の JMS キューに登録されます。影響を受ける注文を表示、修正してから、再び送信できます。 ```xml INSERT INTO ORDERS(CUSTOMER, AMOUNT) VALUES (:id, :amount) ``` ## [](#関連情報)関連情報 - [フローおよびサブフロー](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-flows) # Mule 設定ファイル すべての Mule アプリケーション、ドメイン、およびポリシーは、XML のドメイン固有言語 (DSL) を介して設定されます。 この XML ファイルは、Mule アプリケーションを実行するのに必要な連動関係など、アーティファクトを構成するリソースを指定します。 XML ファイルを手動で作成することもできますが、Anypoint Design Center または Anypoint Studio のグラフィカルユーザーインターフェースを使用して Mule アプリケーションの動作を構造化して定義する方が一般的です。これらの GUI のいずれかを使用したとしても、基になる XML は提供されます。 Studio では、XML を表示したり編集したりすることもできます。 ## [](#概要)概要 Mule 設定ファイルはツリー形式です。 各要素により、Mule 内に次のような設定オブジェクトがセットアップされます。 - [Mule グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/global-settings-configuration) デフォルトのトランザクションタイムアウトなどのグローバル設定。Mule 設定全体に適用されます。 - [プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties) 設定プロパティ、メッセージプロパティ、およびシステムプロパティ。 - [フロー](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-flows) メッセージフローを定義するコンポーネントの組み合わせ。 - [ソース (エンドポイント)](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-components#_endpoints) フローのトリガー。ソースは Studio ではトリガーとも呼ばれます。 - [コネクタおよびモジュール設定](https://docs.mulesoft.com/connectors/) 使用されるすべてのコネクタおよびモジュールコンポーネントの設定の宣言。 - [ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-components#_flow_control_routers) フロー実行の制御。 - [操作](https://docs.mulesoft.com/mule-sdk/latest/operations) フロー内の特定のアクションの適用。 ## [](#xml-スキーマ)XML スキーマ [スキーマ](https://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation)​は、XML 設定ファイルで参照されるこれらのリソースの設定可能な属性を定義します。この方法を使用して、Mule アーティファクトはその機能コンポーネントと設定の検証と定義を行います。 XML スキーマは、Mule アーティファクトの機能コンポーネントを検証するために使用されます。これらはヘッダーで指定します。 ```xml ```
Mule ドメインでは ​mule​ の代わりに ​mule-domain​ タグを使用します。
必要なスキーマファイルをすべて指定してください。手動で設定ファイルをセットアップする場合は時間がかかる可能性がありますが、スキーマファイルをインポートすることで、次の利点を得て時間を節約できます。 - Anypoint Studio のオートコンプリートおよびコンテキスト固有のヘルプ - 設計時の設定検証 - 型付けされたプロパティ Mule 4 のスキーマは、アーティファクトの連動関係に従って動的に自動生成されます。たとえば HTTP スキーマは、HTTP Connector がアーティファクト連動関係の一部である場合にのみ使用できます。したがって、スキーマを指定するには、適切な連動関係を宣言する必要もあります。JMS およびファイルスキーマを必要とする上記の例では、アーティファクトの ​`pom.xml`​ ファイル内に次のような連動関係が必要になります。 ```xml ... org.mule.connectors mule-jms-connector 1.3.2 mule-plugin org.mule.connectors mule-file-connector 1.2.1 mule-plugin ... ```
Anypoint Studio は、コンポーネントが導入されたときに必要なスキーマと連動関係を追加します。
## [](#名前空間)名前空間 各 Mule モジュールまたはコネクタには、コミュニティおよび Enterprise バージョン用の Mule コアを含む XML スキーマがあります。インポートしたスキーマにはその名前空間が含まれます。 標準の Mule 要素を使用するには、Mule Kernel (CE) および Mule Runtime Engine (EE) の名前空間をインポートします。 - `http://www.mulesoft.org/schema/mule/core` ​`http://www.mulesoft.org/schema/mule/core/current/mule.xsd` - `http://www.mulesoft.org/schema/mule/ee/core` ​`http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd` ### [](#デフォルトの名前空間)デフォルトの名前空間 通常、Mule コアスキーマを設定ファイルのデフォルトの名前空間として設定します。そのため、プレフィックスのない XML 要素は Mule コアスキーマから取得されることを意味します。デフォルトの名前空間を設定するには、前の例で設定したコロンと名前空間プレフィックスは使用せずに (例: `xmlns:jms`​ ではなく ​`xmlns`​)、​`xmlns`​ を Mule スキーマの URL の直前に指定します。 ```xml ...config... ``` ## [](#設定ファイルのマージ)設定ファイルのマージ 複数の設定ファイルがある場合、それらを 1 つの設定ファイルにインポートできるため、1 つの設定を指定するだけで済みます。 これは、コネクタ設定やその他のグローバル要素を抽出するために役立ちます。例: ```xml ... ``` これらのインポートは、プロパティと組み合わせて動的にすることもできます。 ```xml (1) ... ```
1この例の ​env​ プロパティは、グローバルプロパティでは設定できません。​env​ 値を定義するには、システムプロパティまたは環境プロパティのいずれかを設定できます。
Mule Runtime Engine は階層でプロパティを読み込むため、インポートをアプリケーションやグローバル設定プロパティに連動させることはできません。詳細は、​[プロパティの階層](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties#properties-hierarchy)​ページを参照してください。 ## [](#複数の設定の宣言)複数の設定の宣言 ファイルをアプリケーション設定の一部として宣言している限り、ファイルを 別々にしておくこともできます。これは、各設定ファイル間の関連性が低い場合に役立ちます。設定は、 アプリケーション記述子ファイル ​`mule-artifact.json`​ の ​`configs`​ セクション内で宣言されます。たとえば、ここでは 4 つの設定ファイルが宣言されています。 ```json { "configs": [ "http-api.xml", "jms-messaging-api.xml", "monitoring-tools.xml", "core-functionality.xml" ], "redeploymentEnabled": true, "name": "retail-api", "minMuleVersion": "4.1.1", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ```
Anypoint Studio は自動的にアプリケーション記述子を処理します。
## [](#完全なアプリケーションの例)完全なアプリケーションの例 アプリケーションの単純な Mule 設定ファイルの例を次に示します。 ```xml #[payload] ``` ## [](#完全なポリシーの例)完全なポリシーの例 ```xml ``` ## [](#完全なドメインの例)完全なドメインの例 ```xml ``` ## [](#関連情報)関連情報 - [Mule ドメイン](https://docs.mulesoft.com/jp/mule-runtime/4.3/shared-resources) - [Mule カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties) - [アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-packaging) # Mule 設定ファイル すべての Mule アプリケーション、ドメイン、およびポリシーは、XML のドメイン固有言語 (DSL) を介して設定されます。 この XML ファイルは、Mule アプリケーションを実行するのに必要な連動関係など、アーティファクトを構成するリソースを指定します。 XML ファイルを手動で作成することもできますが、Design Center または Anypoint Studio のグラフィカルユーザーインターフェースを使用して Mule アプリケーションの動作を構造化して定義する方が一般的です。これらの GUI のいずれかを使用したとしても、基になる XML は提供されます。 Studio では、XML を表示したり編集したりすることもできます。 ## [](#概要)概要 Mule 設定ファイルはツリー形式です。 各要素により、Mule 内に次のような設定オブジェクトがセットアップされます。 - [Mule グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/global-settings-configuration) デフォルトのトランザクションタイムアウトなどのグローバル設定。Mule 設定全体に適用されます。 - [プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties) 設定プロパティ、メッセージプロパティ、およびシステムプロパティ。 - [フロー](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-flows) メッセージフローを定義するコンポーネントの組み合わせ。 - [ソース (エンドポイント)](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-components#_endpoints) フローのトリガー。ソースは Studio ではトリガーとも呼ばれます。 - [コネクタおよびモジュール設定](https://docs.mulesoft.com/connectors/) 使用されるすべてのコネクタおよびモジュールコンポーネントの設定の宣言。 - [ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-components#_flow_control_routers) フロー実行の制御。 - [操作](https://docs.mulesoft.com/mule-sdk/latest/operations) フロー内の特定のアクションの適用。 ## [](#xml-スキーマ)XML スキーマ [スキーマ](https://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation)​は、XML 設定ファイルで参照されるこれらのリソースの設定可能な属性を定義します。この方法を使用して、Mule アーティファクトはその機能コンポーネントと設定の検証と定義を行います。 XML スキーマは、Mule アーティファクトの機能コンポーネントを検証するために使用されます。これらはヘッダーで指定します。 ```xml ```
Mule ドメインでは ​mule​ の代わりに ​mule-domain​ タグを使用します。
必要なスキーマファイルをすべて指定してください。手動で設定ファイルをセットアップする場合は時間がかかる可能性がありますが、スキーマファイルをインポートすることで、次の利点を得て時間を節約できます。 - Anypoint Studio のオートコンプリートおよびコンテキスト固有のヘルプ - 設計時の設定検証 - 型付けされたプロパティ Mule 4 のスキーマは、アーティファクトの連動関係に従って動的に自動生成されます。たとえば HTTP スキーマは、HTTP Connector がアーティファクト連動関係の一部である場合にのみ使用できます。したがって、スキーマを指定するには、適切な連動関係を宣言する必要もあります。JMS およびファイルスキーマを必要とする上記の例では、アーティファクトの ​`pom.xml`​ ファイル内に次のような連動関係が必要になります。 ```xml ... org.mule.connectors mule-jms-connector 1.3.2 mule-plugin org.mule.connectors mule-file-connector 1.2.1 mule-plugin ... ```
Anypoint Studio は、コンポーネントが導入されたときに必要なスキーマと連動関係を追加します。
## [](#名前空間)名前空間 各 Mule モジュールまたはコネクタには、コミュニティおよび Enterprise バージョン用の Mule コアを含む XML スキーマがあります。インポートしたスキーマにはその名前空間が含まれます。 標準の Mule 要素を使用するには、Mule Kernel (CE) および Mule Runtime Engine (EE) の名前空間をインポートします。 - `http://www.mulesoft.org/schema/mule/core` ​`http://www.mulesoft.org/schema/mule/core/current/mule.xsd` - `http://www.mulesoft.org/schema/mule/ee/core` ​`http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd` ### [](#デフォルトの名前空間)デフォルトの名前空間 通常、Mule コアスキーマを設定ファイルのデフォルトの名前空間として設定します。そのため、プレフィックスのない XML 要素は Mule コアスキーマから取得されることを意味します。デフォルトの名前空間を設定するには、前の例で設定したコロンと名前空間プレフィックスは使用せずに (例: `xmlns:jms`​ ではなく ​`xmlns`​)、​`xmlns`​ を Mule スキーマの URL の直前に指定します。 ```xml ...config... ``` ## [](#設定ファイルのマージ)設定ファイルのマージ 複数の設定ファイルがある場合、それらを 1 つの設定ファイルにインポートできるため、1 つの設定を指定するだけで済みます。 これは、コネクタ設定やその他のグローバル要素を抽出するために役立ちます。例: ```xml ... ``` これらのインポートは、プロパティと組み合わせて動的にすることもできます。 ```xml (1) ... ```
1この例の ​env​ プロパティは、グローバルプロパティでは設定できません。​env​ 値を定義するには、システムプロパティまたは環境プロパティのいずれかを設定できます。
Mule Runtime Engine は階層でプロパティを読み込むため、インポートをアプリケーションやグローバル設定プロパティに連動させることはできません。詳細は、​[プロパティの階層](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties#properties-hierarchy)​ページを参照してください。 ## [](#複数の設定の宣言)複数の設定の宣言 ファイルをアプリケーション設定の一部として宣言している限り、ファイルを 別々にしておくこともできます。これは、各設定ファイル間の関連性が低い場合に役立ちます。設定は、 アプリケーション記述子ファイル ​`mule-artifact.json`​ の ​`configs`​ セクション内で宣言されます。たとえば、ここでは 4 つの設定ファイルが宣言されています。 ```json { "configs": [ "http-api.xml", "jms-messaging-api.xml", "monitoring-tools.xml", "core-functionality.xml" ], "redeploymentEnabled": true, "name": "retail-api", "minMuleVersion": "4.1.1", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ```
Anypoint Studio は自動的にアプリケーション記述子を処理します。
## [](#完全なアプリケーションの例)完全なアプリケーションの例 アプリケーションの単純な Mule 設定ファイルの例を次に示します。 ```xml #[payload] ``` ## [](#完全なポリシーの例)完全なポリシーの例 ```xml ``` ## [](#完全なドメインの例)完全なドメインの例 ```xml ``` ## [](#関連情報)関連情報 - [Mule ドメイン](https://docs.mulesoft.com/jp/mule-runtime/4.4/shared-resources) - [Mule カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties) - [アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-packaging) # Mule 設定ファイル すべての Mule アプリケーション、ドメイン、およびポリシーは、XML のドメイン固有言語 (DSL) を介して設定されます。 この XML ファイルは、Mule アプリケーションを実行するのに必要な連動関係など、アーティファクトを構成するリソースを指定します。 XML ファイルを手動で作成することもできますが、Design Center または Anypoint Studio のグラフィカルユーザーインターフェースを使用して Mule アプリケーションの動作を構造化して定義する方が一般的です。これらの GUI のいずれかを使用したとしても、基になる XML は提供されます。 Studio では、XML を表示したり編集したりすることもできます。 ## [](#概要)概要 Mule 設定ファイルはツリー形式です。 各要素により、Mule 内に次のような設定オブジェクトがセットアップされます。 - [Mule グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/global-settings-configuration) デフォルトのトランザクションタイムアウトなどのグローバル設定。Mule 設定全体に適用されます。 - [プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties) 設定プロパティ、メッセージプロパティ、およびシステムプロパティ。 - [フロー](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-flows) メッセージフローを定義するコンポーネントの組み合わせ。 - [ソース (エンドポイント)](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-components#_endpoints) フローのトリガー。ソースは Studio ではトリガーとも呼ばれます。 - [コネクタおよびモジュール設定](https://docs.mulesoft.com/connectors/) 使用されるすべてのコネクタおよびモジュールコンポーネントの設定の宣言。 - [ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-components#_flow_control_routers) フロー実行の制御。 - [操作](https://docs.mulesoft.com/mule-sdk/latest/operations) フロー内の特定のアクションの適用。 ## [](#xml-スキーマ)XML スキーマ [スキーマ](https://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation)​は、XML 設定ファイルで参照されるこれらのリソースの設定可能な属性を定義します。この方法を使用して、Mule アーティファクトはその機能コンポーネントと設定の検証と定義を行います。 XML スキーマは、Mule アーティファクトの機能コンポーネントを検証するために使用されます。これらはヘッダーで指定します。 ```xml ```
Mule ドメインでは ​mule​ の代わりに ​mule-domain​ タグを使用します。
必要なスキーマファイルをすべて指定してください。手動で設定ファイルをセットアップする場合は時間がかかる可能性がありますが、スキーマファイルをインポートすることで、次の利点を得て時間を節約できます。 - Anypoint Studio のオートコンプリートおよびコンテキスト固有のヘルプ - 設計時の設定検証 - 型付けされたプロパティ Mule 4 のスキーマは、アーティファクトの連動関係に従って動的に自動生成されます。たとえば HTTP スキーマは、HTTP Connector がアーティファクト連動関係の一部である場合にのみ使用できます。したがって、スキーマを指定するには、適切な連動関係を宣言する必要もあります。JMS およびファイルスキーマを必要とする上記の例では、アーティファクトの ​`pom.xml`​ ファイル内に次のような連動関係が必要になります。 ```xml ... org.mule.connectors mule-jms-connector 1.3.2 mule-plugin org.mule.connectors mule-file-connector 1.2.1 mule-plugin ... ```
Anypoint Studio は、コンポーネントが導入されたときに必要なスキーマと連動関係を追加します。
## [](#名前空間)名前空間 各 Mule モジュールまたはコネクタには、コミュニティおよび Enterprise バージョン用の Mule コアを含む XML スキーマがあります。インポートしたスキーマにはその名前空間が含まれます。 標準の Mule 要素を使用するには、Mule Kernel (CE) および Mule Runtime Engine (EE) の名前空間をインポートします。 - `http://www.mulesoft.org/schema/mule/core` ​`http://www.mulesoft.org/schema/mule/core/current/mule.xsd` - `http://www.mulesoft.org/schema/mule/ee/core` ​`http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd` ### [](#デフォルトの名前空間)デフォルトの名前空間 通常、Mule コアスキーマを設定ファイルのデフォルトの名前空間として設定します。そのため、プレフィックスのない XML 要素は Mule コアスキーマから取得されることを意味します。デフォルトの名前空間を設定するには、前の例で設定したコロンと名前空間プレフィックスは使用せずに (例: `xmlns:jms`​ ではなく ​`xmlns`​)、​`xmlns`​ を Mule スキーマの URL の直前に指定します。 ```xml ...config... ``` ## [](#設定ファイルのマージ)設定ファイルのマージ 複数の設定ファイルがある場合、それらを 1 つの設定ファイルにインポートできるため、1 つの設定を指定するだけで済みます。 これは、コネクタ設定やその他のグローバル要素を抽出するために役立ちます。例: ```xml ... ``` これらのインポートは、プロパティと組み合わせて動的にすることもできます。 ```xml (1) ... ```
1この例の ​env​ プロパティは、グローバルプロパティでは設定できません。​env​ 値を定義するには、システムプロパティまたは環境プロパティのいずれかを設定できます。
Mule Runtime Engine は階層でプロパティを読み込むため、インポートをアプリケーションやグローバル設定プロパティに連動させることはできません。詳細は、​[プロパティの階層](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties#properties-hierarchy)​ページを参照してください。 ## [](#複数の設定の宣言)複数の設定の宣言 ファイルをアプリケーション設定の一部として宣言している限り、ファイルを 別々にしておくこともできます。これは、各設定ファイル間の関連性が低い場合に役立ちます。設定は、 アプリケーション記述子ファイル ​`mule-artifact.json`​ の ​`configs`​ セクション内で宣言されます。たとえば、ここでは 4 つの設定ファイルが宣言されています。 ```json { "configs": [ "http-api.xml", "jms-messaging-api.xml", "monitoring-tools.xml", "core-functionality.xml" ], "redeploymentEnabled": true, "name": "retail-api", "minMuleVersion": "4.1.1", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ```
Anypoint Studio は自動的にアプリケーション記述子を処理します。
## [](#完全なアプリケーションの例)完全なアプリケーションの例 アプリケーションの単純な Mule 設定ファイルの例を次に示します。 ```xml #[payload] ``` ## [](#完全なポリシーの例)完全なポリシーの例 ```xml ``` ## [](#完全なドメインの例)完全なドメインの例 ```xml ``` ## [](#関連情報)関連情報 - [Mule ドメイン](https://docs.mulesoft.com/jp/mule-runtime/4.5/shared-resources) - [Mule カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties) - [アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-packaging) # Mule 設定ファイル すべての Mule アプリケーション、ドメイン、およびポリシーは、XML のドメイン固有言語 (DSL) を介して設定されます。 この XML ファイルは、Mule アプリケーションを実行するのに必要な連動関係など、アーティファクトを構成するリソースを指定します。 XML ファイルを手動で作成することもできますが、Design Center または Anypoint Studio のグラフィカルユーザーインターフェースを使用して Mule アプリケーションの動作を構造化して定義する方が一般的です。これらの GUI のいずれかを使用したとしても、基になる XML は提供されます。 Studio では、XML を表示したり編集したりすることもできます。 ## [](#概要)概要 Mule 設定ファイルはツリー形式です。 各要素により、Mule 内に次のような設定オブジェクトがセットアップされます。 - [Mule グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/global-settings-configuration) デフォルトのトランザクションタイムアウトなどのグローバル設定。Mule 設定全体に適用されます。 - [プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties) 設定プロパティ、メッセージプロパティ、およびシステムプロパティ。 - [フロー](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-flows) メッセージフローを定義するコンポーネントの組み合わせ。 - [ソース (エンドポイント)](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-components#_endpoints) フローのトリガー。ソースは Studio ではトリガーとも呼ばれます。 - [コネクタおよびモジュール設定](https://docs.mulesoft.com/connectors/) 使用されるすべてのコネクタおよびモジュールコンポーネントの設定の宣言。 - [ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-components#_flow_control_routers) フロー実行の制御。 - [操作](https://docs.mulesoft.com/mule-sdk/latest/operations) フロー内の特定のアクションの適用。 ## [](#xml-スキーマ)XML スキーマ [スキーマ](https://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation)​は、XML 設定ファイルで参照されるこれらのリソースの設定可能な属性を定義します。この方法を使用して、Mule アーティファクトはその機能コンポーネントと設定の検証と定義を行います。 XML スキーマは、Mule アーティファクトの機能コンポーネントを検証するために使用されます。これらはヘッダーで指定します。 ```xml ```
Mule ドメインでは ​mule​ の代わりに ​mule-domain​ タグを使用します。
必要なスキーマファイルをすべて指定してください。手動で設定ファイルをセットアップする場合は時間がかかる可能性がありますが、スキーマファイルをインポートすることで、次の利点を得て時間を節約できます。 - Anypoint Studio のオートコンプリートおよびコンテキスト固有のヘルプ - 設計時の設定検証 - 型付けされたプロパティ Mule 4 のスキーマは、アーティファクトの連動関係に従って動的に自動生成されます。たとえば HTTP スキーマは、HTTP Connector がアーティファクト連動関係の一部である場合にのみ使用できます。したがって、スキーマを指定するには、適切な連動関係を宣言する必要もあります。JMS およびファイルスキーマを必要とする上記の例では、アーティファクトの ​`pom.xml`​ ファイル内に次のような連動関係が必要になります。 ```xml ... org.mule.connectors mule-jms-connector 1.3.2 mule-plugin org.mule.connectors mule-file-connector 1.2.1 mule-plugin ... ```
Anypoint Studio は、コンポーネントが導入されたときに必要なスキーマと連動関係を追加します。
## [](#名前空間)名前空間 各 Mule モジュールまたはコネクタには、コミュニティおよび Enterprise バージョン用の Mule コアを含む XML スキーマがあります。インポートしたスキーマにはその名前空間が含まれます。 標準の Mule 要素を使用するには、Mule Kernel (CE) および Mule Runtime Engine (EE) の名前空間をインポートします。 - `http://www.mulesoft.org/schema/mule/core` ​`http://www.mulesoft.org/schema/mule/core/current/mule.xsd` - `http://www.mulesoft.org/schema/mule/ee/core` ​`http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd` ### [](#デフォルトの名前空間)デフォルトの名前空間 通常、Mule コアスキーマを設定ファイルのデフォルトの名前空間として設定します。そのため、プレフィックスのない XML 要素は Mule コアスキーマから取得されることを意味します。デフォルトの名前空間を設定するには、前の例で設定したコロンと名前空間プレフィックスは使用せずに (例: `xmlns:jms`​ ではなく ​`xmlns`​)、​`xmlns`​ を Mule スキーマの URL の直前に指定します。 ```xml ...config... ``` ## [](#設定ファイルのマージ)設定ファイルのマージ 複数の設定ファイルがある場合、それらを 1 つの設定ファイルにインポートできるため、1 つの設定を指定するだけで済みます。 これは、コネクタ設定やその他のグローバル要素を抽出するために役立ちます。例: ```xml ... ``` これらのインポートは、プロパティと組み合わせて動的にすることもできます。 ```xml (1) ... ```
1この例の ​env​ プロパティは、グローバルプロパティでは設定できません。​env​ 値を定義するには、システムプロパティまたは環境プロパティのいずれかを設定できます。
Mule Runtime Engine は階層でプロパティを読み込むため、インポートをアプリケーションやグローバル設定プロパティに連動させることはできません。詳細は、​[プロパティの階層](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties#properties-hierarchy)​ページを参照してください。 ## [](#複数の設定の宣言)複数の設定の宣言 ファイルをアプリケーション設定の一部として宣言している限り、ファイルを 別々にしておくこともできます。これは、各設定ファイル間の関連性が低い場合に役立ちます。設定は、 アプリケーション記述子ファイル ​`mule-artifact.json`​ の ​`configs`​ セクション内で宣言されます。たとえば、ここでは 4 つの設定ファイルが宣言されています。 ```json { "configs": [ "http-api.xml", "jms-messaging-api.xml", "monitoring-tools.xml", "core-functionality.xml" ], "redeploymentEnabled": true, "name": "retail-api", "minMuleVersion": "4.1.1", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ```
Anypoint Studio は自動的にアプリケーション記述子を処理します。
## [](#完全なアプリケーションの例)完全なアプリケーションの例 アプリケーションの単純な Mule 設定ファイルの例を次に示します。 ```xml #[payload] ``` ## [](#完全なポリシーの例)完全なポリシーの例 ```xml ``` ## [](#完全なドメインの例)完全なドメインの例 ```xml ``` ## [](#関連情報)関連情報 - [Mule ドメイン](https://docs.mulesoft.com/jp/mule-runtime/4.6/shared-resources) - [Mule カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties) - [アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-packaging) # Mule 設定ファイル すべての Mule アプリケーション、ドメイン、およびポリシーは、XML のドメイン固有言語 (DSL) を介して設定されます。 この XML ファイルは、Mule アプリケーションを実行するのに必要な連動関係など、アーティファクトを構成するリソースを指定します。 XML ファイルを手動で作成することもできますが、Anypoint Design Center または Anypoint Studio のグラフィカルユーザーインターフェースを使用して Mule アプリケーションの動作を構造化して定義する方が一般的です。これらの GUI のいずれかを使用したとしても、基になる XML は提供されます。 Studio では、XML を表示したり編集したりすることもできます。 ## [](#概要)概要 Mule 設定ファイルはツリー形式です。 各要素により、Mule 内に次のような設定オブジェクトがセットアップされます。 - [Mule グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/global-settings-configuration) デフォルトのトランザクションタイムアウトなどのグローバル設定。Mule 設定全体に適用されます。 - [プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties) 設定プロパティ、メッセージプロパティ、およびシステムプロパティ。 - [フロー](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-flows) メッセージフローを定義するコンポーネントの組み合わせ。 - [ソース (エンドポイント)](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-components#_endpoints) フローのトリガー。ソースは Studio ではトリガーとも呼ばれます。 - [コネクタおよびモジュール設定](https://docs.mulesoft.com/connectors/) 使用されるすべてのコネクタおよびモジュールコンポーネントの設定の宣言。 - [ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-components#_flow_control_routers) フロー実行の制御。 - [操作](https://docs.mulesoft.com/mule-sdk/latest/operations) フロー内の特定のアクションの適用。 ## [](#xml-スキーマ)XML スキーマ [スキーマ](https://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation)​は、XML 設定ファイルで参照されるこれらのリソースの設定可能な属性を定義します。この方法を使用して、Mule アーティファクトはその機能コンポーネントと設定の検証と定義を行います。 XML スキーマは、Mule アーティファクトの機能コンポーネントを検証するために使用されます。これらはヘッダーで指定します。 ```xml ```
Mule ドメインでは ​mule​ の代わりに ​mule-domain​ タグを使用します。
必要なスキーマファイルをすべて指定してください。手動で設定ファイルをセットアップする場合は時間がかかる可能性がありますが、スキーマファイルをインポートすることで、次の利点を得て時間を節約できます。 - Anypoint Studio のオートコンプリートおよびコンテキスト固有のヘルプ - 設計時の設定検証 - 型付けされたプロパティ Mule 4 のスキーマは、アーティファクトの連動関係に従って動的に自動生成されます。たとえば HTTP スキーマは、HTTP Connector がアーティファクト連動関係の一部である場合にのみ使用できます。したがって、スキーマを指定するには、適切な連動関係を宣言する必要もあります。JMS およびファイルスキーマを必要とする上記の例では、アーティファクトの ​`pom.xml`​ ファイル内に次のような連動関係が必要になります。 ```xml ... org.mule.connectors mule-jms-connector 1.3.2 mule-plugin org.mule.connectors mule-file-connector 1.2.1 mule-plugin ... ```
Anypoint Studio は、コンポーネントが導入されたときに必要なスキーマと連動関係を追加します。
## [](#名前空間)名前空間 各 Mule モジュールまたはコネクタには、コミュニティおよび Enterprise バージョン用の Mule コアを含む XML スキーマがあります。インポートしたスキーマにはその名前空間が含まれます。 標準の Mule 要素を使用するには、Mule Kernel (CE) および Mule Runtime Engine (EE) の名前空間をインポートします。 - `http://www.mulesoft.org/schema/mule/core` ​`http://www.mulesoft.org/schema/mule/core/current/mule.xsd` - `http://www.mulesoft.org/schema/mule/ee/core` ​`http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd` ### [](#デフォルトの名前空間)デフォルトの名前空間 通常、Mule コアスキーマを設定ファイルのデフォルトの名前空間として設定します。そのため、プレフィックスのない XML 要素は Mule コアスキーマから取得されることを意味します。デフォルトの名前空間を設定するには、前の例で設定したコロンと名前空間プレフィックスは使用せずに (例: `xmlns:jms`​ ではなく ​`xmlns`​)、​`xmlns`​ を Mule スキーマの URL の直前に指定します。 ```xml ...config... ``` ## [](#設定ファイルのマージ)設定ファイルのマージ 複数の設定ファイルがある場合、それらを 1 つの設定ファイルにインポートできるため、1 つの設定を指定するだけで済みます。 これは、コネクタ設定やその他のグローバル要素を抽出するために役立ちます。次に例を示します。 ```xml ... ``` これらのインポートは、プロパティと組み合わせて動的にすることもできます。 ```xml (1) ... ```
1この例の ​env​ プロパティは、グローバルプロパティでは設定できません。​env​ 値を定義するには、システムプロパティまたは環境プロパティのいずれかを設定できます。
Mule Runtime Engine は階層でプロパティを読み込むため、インポートをアプリケーションやグローバル設定プロパティに連動させることはできません。詳細は、​[プロパティの階層](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties#properties-hierarchy)​ページを参照してください。 ## [](#複数の設定の宣言)複数の設定の宣言 ファイルをアプリケーション設定の一部として宣言している限り、ファイルを 別々にしておくこともできます。これは、各設定ファイル間の関連性が低い場合に役立ちます。設定は、 アプリケーション記述子ファイル ​`mule-artifact.json`​ の ​`configs`​ セクション内で宣言されます。たとえば、ここでは 4 つの設定ファイルが宣言されています。 ```json { "configs": [ "http-api.xml", "jms-messaging-api.xml", "monitoring-tools.xml", "core-functionality.xml" ], "redeploymentEnabled": true, "name": "retail-api", "minMuleVersion": "4.1.1", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ```
Anypoint Studio は自動的にアプリケーション記述子を処理します。
## [](#完全なアプリケーションの例)完全なアプリケーションの例 アプリケーションの単純な Mule 設定ファイルの例を次に示します。 ```xml #[payload] ``` ## [](#完全なポリシーの例)完全なポリシーの例 ```xml ``` ## [](#完全なドメインの例)完全なドメインの例 ```xml ``` ## [](#関連情報)関連情報 - [Mule ドメイン](https://docs.mulesoft.com/jp/mule-runtime/4.7/shared-resources) - [Mule カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties) - [アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-packaging) # Mule 設定ファイル すべての Mule アプリケーション、ドメイン、およびポリシーは、XML のドメイン固有言語 (DSL) を介して設定されます。 この XML ファイルは、Mule アプリケーションを実行するのに必要な連動関係など、アーティファクトを構成するリソースを指定します。 XML ファイルを手動で作成することもできますが、Anypoint Design Center または Anypoint Studio のグラフィカルユーザーインターフェースを使用して Mule アプリケーションの動作を構造化して定義する方が一般的です。これらの GUI のいずれかを使用したとしても、基になる XML は提供されます。 Studio では、XML を表示したり編集したりすることもできます。 ## [](#概要)概要 Mule 設定ファイルはツリー形式です。 各要素により、Mule 内に次のような設定オブジェクトがセットアップされます。 - [Mule グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/global-settings-configuration) デフォルトのトランザクションタイムアウトなどのグローバル設定。Mule 設定全体に適用されます。 - [プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties) 設定プロパティ、メッセージプロパティ、およびシステムプロパティ。 - [フロー](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-flows) メッセージフローを定義するコンポーネントの組み合わせ。 - [ソース (エンドポイント)](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-components#_endpoints) フローのトリガー。ソースは Studio ではトリガーとも呼ばれます。 - [コネクタおよびモジュール設定](https://docs.mulesoft.com/connectors/) 使用されるすべてのコネクタおよびモジュールコンポーネントの設定の宣言。 - [ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-components#_flow_control_routers) フロー実行の制御。 - [操作](https://docs.mulesoft.com/mule-sdk/latest/operations) フロー内の特定のアクションの適用。 ## [](#xml-スキーマ)XML スキーマ [スキーマ](https://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation)​は、XML 設定ファイルで参照されるこれらのリソースの設定可能な属性を定義します。この方法を使用して、Mule アーティファクトはその機能コンポーネントと設定の検証と定義を行います。 XML スキーマは、Mule アーティファクトの機能コンポーネントを検証するために使用されます。これらはヘッダーで指定します。 ```xml ```
Mule ドメインでは ​mule​ の代わりに ​mule-domain​ タグを使用します。
必要なスキーマファイルをすべて指定してください。手動で設定ファイルをセットアップする場合は時間がかかる可能性がありますが、スキーマファイルをインポートすることで、次の利点を得て時間を節約できます。 - Anypoint Studio のオートコンプリートおよびコンテキスト固有のヘルプ - 設計時の設定検証 - 型付けされたプロパティ Mule 4 のスキーマは、アーティファクトの連動関係に従って動的に自動生成されます。たとえば HTTP スキーマは、HTTP Connector がアーティファクト連動関係の一部である場合にのみ使用できます。したがって、スキーマを指定するには、適切な連動関係を宣言する必要もあります。JMS およびファイルスキーマを必要とする上記の例では、アーティファクトの ​`pom.xml`​ ファイル内に次のような連動関係が必要になります。 ```xml ... org.mule.connectors mule-jms-connector 1.3.2 mule-plugin org.mule.connectors mule-file-connector 1.2.1 mule-plugin ... ```
Anypoint Studio は、コンポーネントが導入されたときに必要なスキーマと連動関係を追加します。
## [](#名前空間)名前空間 各 Mule モジュールまたはコネクタには、コミュニティおよび Enterprise バージョン用の Mule コアを含む XML スキーマがあります。インポートしたスキーマにはその名前空間が含まれます。 標準の Mule 要素を使用するには、Mule Kernel (CE) および Mule Runtime Engine (EE) の名前空間をインポートします。 - `http://www.mulesoft.org/schema/mule/core` ​`http://www.mulesoft.org/schema/mule/core/current/mule.xsd` - `http://www.mulesoft.org/schema/mule/ee/core` ​`http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd` ### [](#デフォルトの名前空間)デフォルトの名前空間 通常、Mule コアスキーマを設定ファイルのデフォルトの名前空間として設定します。そのため、プレフィックスのない XML 要素は Mule コアスキーマから取得されることを意味します。デフォルトの名前空間を設定するには、前の例で設定したコロンと名前空間プレフィックスは使用せずに (例: `xmlns:jms`​ ではなく ​`xmlns`​)、​`xmlns`​ を Mule スキーマの URL の直前に指定します。 ```xml ...config... ``` ## [](#設定ファイルのマージ)設定ファイルのマージ 複数の設定ファイルがある場合、それらを 1 つの設定ファイルにインポートできるため、1 つの設定を指定するだけで済みます。 これは、コネクタ設定やその他のグローバル要素を抽出するために役立ちます。次に例を示します。 ```xml ... ``` これらのインポートは、プロパティと組み合わせて動的にすることもできます。 ```xml (1) ... ```
1この例の ​env​ プロパティは、グローバルプロパティでは設定できません。​env​ 値を定義するには、システムプロパティまたは環境プロパティのいずれかを設定できます。
Mule Runtime Engine は階層でプロパティを読み込むため、インポートをアプリケーションやグローバル設定プロパティに連動させることはできません。詳細は、​[プロパティの階層](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties#properties-hierarchy)​ページを参照してください。 ## [](#複数の設定の宣言)複数の設定の宣言 ファイルをアプリケーション設定の一部として宣言している限り、ファイルを 別々にしておくこともできます。これは、各設定ファイル間の関連性が低い場合に役立ちます。設定は、 アプリケーション記述子ファイル ​`mule-artifact.json`​ の ​`configs`​ セクション内で宣言されます。たとえば、ここでは 4 つの設定ファイルが宣言されています。 ```json { "configs": [ "http-api.xml", "jms-messaging-api.xml", "monitoring-tools.xml", "core-functionality.xml" ], "redeploymentEnabled": true, "name": "retail-api", "minMuleVersion": "4.1.1", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ```
Anypoint Studio は自動的にアプリケーション記述子を処理します。
## [](#完全なアプリケーションの例)完全なアプリケーションの例 アプリケーションの単純な Mule 設定ファイルの例を次に示します。 ```xml #[payload] ``` ## [](#完全なポリシーの例)完全なポリシーの例 ```xml ``` ## [](#完全なドメインの例)完全なドメインの例 ```xml ``` ## [](#関連情報)関連情報 - [Mule ドメイン](https://docs.mulesoft.com/jp/mule-runtime/4.8/shared-resources) - [Mule カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties) - [アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-packaging) # Mule 設定ファイル すべての Mule アプリケーション、ドメイン、およびポリシーは、XML のドメイン固有言語 (DSL) を介して設定されます。 この XML ファイルは、Mule アプリケーションを実行するのに必要な連動関係など、アーティファクトを構成するリソースを指定します。 XML ファイルを手動で作成することもできますが、Anypoint Design Center または Anypoint Studio のグラフィカルユーザーインターフェースを使用して Mule アプリケーションの動作を構造化して定義する方が一般的です。これらの GUI のいずれかを使用したとしても、基になる XML は提供されます。 Studio では、XML を表示したり編集したりすることもできます。 ## [](#概要)概要 Mule 設定ファイルはツリー形式です。 各要素により、Mule 内に次のような設定オブジェクトがセットアップされます。 - [Mule グローバル設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/global-settings-configuration) デフォルトのトランザクションタイムアウトなどのグローバル設定。Mule 設定全体に適用されます。 - [プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties) 設定プロパティ、メッセージプロパティ、およびシステムプロパティ。 - [フロー](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-flows) メッセージフローを定義するコンポーネントの組み合わせ。 - [ソース (エンドポイント)](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-components#_endpoints) フローのトリガー。ソースは Studio ではトリガーとも呼ばれます。 - [コネクタおよびモジュール設定](https://docs.mulesoft.com/connectors/) 使用されるすべてのコネクタおよびモジュールコンポーネントの設定の宣言。 - [ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-components#_flow_control_routers) フロー実行の制御。 - [操作](https://docs.mulesoft.com/mule-sdk/latest/operations) フロー内の特定のアクションの適用。 ## [](#xml-スキーマ)XML スキーマ [スキーマ](https://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation)​は、XML 設定ファイルで参照されるこれらのリソースの設定可能な属性を定義します。この方法を使用して、Mule アーティファクトはその機能コンポーネントと設定の検証と定義を行います。 XML スキーマは、Mule アーティファクトの機能コンポーネントを検証するために使用されます。これらはヘッダーで指定します。 ```xml ```
Mule ドメインでは ​mule​ の代わりに ​mule-domain​ タグを使用します。
必要なスキーマファイルをすべて指定してください。手動で設定ファイルをセットアップする場合は時間がかかる可能性がありますが、スキーマファイルをインポートすることで、次の利点を得て時間を節約できます。 - Anypoint Studio のオートコンプリートおよびコンテキスト固有のヘルプ - 設計時の設定検証 - 型付けされたプロパティ Mule 4 のスキーマは、アーティファクトの連動関係に従って動的に自動生成されます。たとえば HTTP スキーマは、HTTP Connector がアーティファクト連動関係の一部である場合にのみ使用できます。したがって、スキーマを指定するには、適切な連動関係を宣言する必要もあります。JMS およびファイルスキーマを必要とする上記の例では、アーティファクトの ​`pom.xml`​ ファイル内に次のような連動関係が必要になります。 ```xml ... org.mule.connectors mule-jms-connector 1.3.2 mule-plugin org.mule.connectors mule-file-connector 1.2.1 mule-plugin ... ```
Anypoint Studio は、コンポーネントが導入されたときに必要なスキーマと連動関係を追加します。
## [](#名前空間)名前空間 各 Mule モジュールまたはコネクタには、コミュニティおよび Enterprise バージョン用の Mule コアを含む XML スキーマがあります。インポートしたスキーマにはその名前空間が含まれます。 標準の Mule 要素を使用するには、Mule Kernel (CE) および Mule Runtime Engine (EE) の名前空間をインポートします。 - `http://www.mulesoft.org/schema/mule/core` ​`http://www.mulesoft.org/schema/mule/core/current/mule.xsd` - `http://www.mulesoft.org/schema/mule/ee/core` ​`http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd` ### [](#デフォルトの名前空間)デフォルトの名前空間 通常、Mule コアスキーマを設定ファイルのデフォルトの名前空間として設定します。そのため、プレフィックスのない XML 要素は Mule コアスキーマから取得されることを意味します。デフォルトの名前空間を設定するには、前の例で設定したコロンと名前空間プレフィックスは使用せずに (例: `xmlns:jms`​ ではなく ​`xmlns`​)、​`xmlns`​ を Mule スキーマの URL の直前に指定します。 ```xml ...config... ``` ## [](#設定ファイルのマージ)設定ファイルのマージ 複数の設定ファイルがある場合、それらを 1 つの設定ファイルにインポートできるため、1 つの設定を指定するだけで済みます。 これは、コネクタ設定やその他のグローバル要素を抽出するために役立ちます。次に例を示します。 ```xml ... ``` これらのインポートは、プロパティと組み合わせて動的にすることもできます。 ```xml (1) ... ```
1この例の ​env​ プロパティは、グローバルプロパティでは設定できません。​env​ 値を定義するには、システムプロパティまたは環境プロパティのいずれかを設定できます。
Mule Runtime Engine は階層でプロパティを読み込むため、インポートをアプリケーションやグローバル設定プロパティに連動させることはできません。詳細は、​[プロパティの階層](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties#properties-hierarchy)​ページを参照してください。 ## [](#複数の設定の宣言)複数の設定の宣言 ファイルをアプリケーション設定の一部として宣言している限り、ファイルを 別々にしておくこともできます。これは、各設定ファイル間の関連性が低い場合に役立ちます。設定は、 アプリケーション記述子ファイル ​`mule-artifact.json`​ の ​`configs`​ セクション内で宣言されます。たとえば、ここでは 4 つの設定ファイルが宣言されています。 ```json { "configs": [ "http-api.xml", "jms-messaging-api.xml", "monitoring-tools.xml", "core-functionality.xml" ], "redeploymentEnabled": true, "name": "retail-api", "minMuleVersion": "4.1.1", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ```
Anypoint Studio は自動的にアプリケーション記述子を処理します。
## [](#完全なアプリケーションの例)完全なアプリケーションの例 アプリケーションの単純な Mule 設定ファイルの例を次に示します。 ```xml #[payload] ``` ## [](#完全なポリシーの例)完全なポリシーの例 ```xml ``` ## [](#完全なドメインの例)完全なドメインの例 ```xml ``` ## [](#関連情報)関連情報 - [Mule ドメイン](https://docs.mulesoft.com/jp/mule-runtime/4.9/shared-resources) - [Mule カスタムポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-getting-started) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties) - [アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-packaging) # OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するために使用できる 4 つの認証許可種別があります。 - [認証コード](#authorization-code) - [暗黙的](#implicit) - [リソースオーナーパスワードログイン情報](#resource-owner-password-credentials) - [クライアントログイン情報](#client-credentials) OAuth 認証フレームワークについては、RFC 6749 の「OAuth 2.0 認証フレームワーク」を参照してください。 ## [](#authorization-code)認証コード 認証コード許可種別では、認証サーバー (保護されたリソースにアクセスするための権限を確認して付与する) とリソースサーバー (保護されたリソースへのアクセスを提供する) を使用します。独立したサーバーとして記述されていますが、認証サーバーとリソースサーバーは同じ Mule サーバーに存在します。認証コード許可種別を使用する場合、クライアントアプリケーションは、保護されたリソースへのアクセス権を付与するトークンを要求する前に、サービスプロバイダーに認証コードを要求する必要があります。 認証コード許可種別は、認証されていないパーティ (リソースオーナーを含む) に公開することなくクライアントを認証してアクセストークンを転送するため、特に安全です。 認証コード許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションはサービスプロバイダーによって制御されている、保護されたリソースを使用するために、リソースへのアクセス要求を開始します。 2. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 3. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、サービスプロバイダーの認証を受けます。 4. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーは認証コードを返します。 5. クライアントアプリケーションは、認証サーバーをもう一度コールし、認証コード、クライアント ID (再度)、クライアントシークレットを提供します。 6. サービスプロバイダーは、アクセストークンを返します。 7. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 8. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#implicit)暗黙的 認証コード許可種別と同様に、暗黙的許可種別には認証サーバーとリソースサーバーが関与します。ただし、認証コードとクライアントシークレットを使用してクライアントアプリケーションを認証するための追加手順を実行する代わりに、サービスプロバイダーは次の作業を行います。 - クライアント ID に基づいてクライアントを認証する。 - 保護されたリソースにアクセスするためのアクセストークンを提供する。 暗黙的許可種別は、Javascript などのスクリプト言語を使用するブラウザークライアントのパフォーマンスを最適化します。ただし、この許可種別では、アクセストークンをリソースオーナーまたはリソースオーナーのユーザーエージェントに公開できます。 暗黙的許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、リソースオーナーがサービスプロバイダーに対してクライアントアプリケーションを認証するように要求します。 3. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーはアクセストークンを返します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#resource-owner-password-credentials)リソースオーナーパスワードログイン情報 リソースオーナーパスワードログイン情報許可種別を使用する場合、クライアントアプリケーションは、リソースオーナーがサービスプロバイダーのログイン情報を共有するように要求します。次に、クライアントアプリケーションは、それらのログイン情報を使用して、サービスプロバイダーにアクセスし、リソースオーナーのアカウントにアクセスします。サービスプロバイダーは、有効なログイン情報を受け入れて、リソースオーナーのアカウントへのフルアクセス権をクライアントアプリケーションに付与します。 この認証種別は、安全なアクセスログイン情報の共有を犠牲にしてパフォーマンスを最適化します。リソースオーナーは、クライアントアプリケーションが非公開データへのアクセス権を共有しないことを信頼する必要があります。 リソースオーナーパスワードログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. リソースオーナーは、アクセスログイン情報をクライアントアプリケーションに提供します。 2. クライアントアプリケーションは、サービスプロバイダーをコールしてアクセストークンを要求します。クライアントは、コール時にサービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。保護されたリソースのアクセスログイン情報も提供します。 3. サービスプロバイダーは、クライアントアプリケーションを認証し、アクセスログイン情報を検証します。次に、アクセストークンを発行します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースへのアクセスを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#client-credentials)クライアントログイン情報 クライアントログイン情報許可種別を使用する場合、クライアントアプリケーションは、特定のリソースオーナーに関連付けられていないデータへのアクセスを要求します。この許可種別では、サービスプロバイダーはクライアントが有効であるかどうかのみを検証する必要があります。この種別の OAuth インタラクションは、2 つの役割 (サービスプロバイダーとクライアントアプリケーション) のみが関与するため「2 本足の OAuth」と呼ばれることがあります。 他の 3 つの認証種別は、3 番目の役割 (リソースオーナー) が関与します。そのため、「3 本足の OAuth」と呼ばれることがあります。 通常、クライアントログイン情報許可種別は、クライアントがリソースオーナーでもある場合に適用されます。 クライアントログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認しら、サービスプロバイダーはアクセストークンを返します。 3. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 4. クライアントアプリケーションは、保護されたリソースを取得します。 ## [](#関連情報)関連情報 - [Mule セキュアトークンサービス](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-secure-token-service) # OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するために使用できる 4 つの認証許可種別があります。 - [認証コード](#authorization-code) - [暗黙的](#implicit) - [リソースオーナーパスワードログイン情報](#resource-owner-password-credentials) - [クライアントログイン情報](#client-credentials) OAuth 認証フレームワークについては、RFC 6749 の「OAuth 2.0 認証フレームワーク」を参照してください。 ## [](#authorization-code)認証コード 認証コード許可種別では、認証サーバー (保護されたリソースにアクセスするための権限を確認して付与する) とリソースサーバー (保護されたリソースへのアクセスを提供する) を使用します。独立したサーバーとして記述されていますが、認証サーバーとリソースサーバーは同じ Mule サーバーに存在します。認証コード許可種別を使用する場合、クライアントアプリケーションは、保護されたリソースへのアクセス権を付与するトークンを要求する前に、サービスプロバイダーに認証コードを要求する必要があります。 認証コード許可種別は、認証されていないパーティ (リソースオーナーを含む) に公開することなくクライアントを認証してアクセストークンを転送するため、特に安全です。 認証コード許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションはサービスプロバイダーによって制御されている、保護されたリソースを使用するために、リソースへのアクセス要求を開始します。 2. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 3. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、サービスプロバイダーの認証を受けます。 4. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーは認証コードを返します。 5. クライアントアプリケーションは、認証サーバーをもう一度コールし、認証コード、クライアント ID (再度)、クライアントシークレットを提供します。 6. サービスプロバイダーは、アクセストークンを返します。 7. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 8. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#implicit)暗黙的 認証コード許可種別と同様に、暗黙的許可種別には認証サーバーとリソースサーバーが関与します。ただし、認証コードとクライアントシークレットを使用してクライアントアプリケーションを認証するための追加手順を実行する代わりに、サービスプロバイダーは次の作業を行います。 - クライアント ID に基づいてクライアントを認証する。 - 保護されたリソースにアクセスするためのアクセストークンを提供する。 暗黙的許可種別は、Javascript などのスクリプト言語を使用するブラウザークライアントのパフォーマンスを最適化します。ただし、この許可種別では、アクセストークンをリソースオーナーまたはリソースオーナーのユーザーエージェントに公開できます。 暗黙的許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、リソースオーナーがサービスプロバイダーに対してクライアントアプリケーションを認証するように要求します。 3. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーはアクセストークンを返します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#resource-owner-password-credentials)リソースオーナーパスワードログイン情報 リソースオーナーパスワードログイン情報許可種別を使用する場合、クライアントアプリケーションは、リソースオーナーがサービスプロバイダーのログイン情報を共有するように要求します。次に、クライアントアプリケーションは、それらのログイン情報を使用して、サービスプロバイダーにアクセスし、リソースオーナーのアカウントにアクセスします。サービスプロバイダーは、有効なログイン情報を受け入れて、リソースオーナーのアカウントへのフルアクセス権をクライアントアプリケーションに付与します。 この認証種別は、安全なアクセスログイン情報の共有を犠牲にしてパフォーマンスを最適化します。リソースオーナーは、クライアントアプリケーションが非公開データへのアクセス権を共有しないことを信頼する必要があります。 リソースオーナーパスワードログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. リソースオーナーは、アクセスログイン情報をクライアントアプリケーションに提供します。 2. クライアントアプリケーションは、サービスプロバイダーをコールしてアクセストークンを要求します。クライアントは、コール時にサービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。保護されたリソースのアクセスログイン情報も提供します。 3. サービスプロバイダーは、クライアントアプリケーションを認証し、アクセスログイン情報を検証します。次に、アクセストークンを発行します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースへのアクセスを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#client-credentials)クライアントログイン情報 クライアントログイン情報許可種別を使用する場合、クライアントアプリケーションは、特定のリソースオーナーに関連付けられていないデータへのアクセスを要求します。この許可種別では、サービスプロバイダーはクライアントが有効であるかどうかのみを検証する必要があります。この種別の OAuth インタラクションは、2 つの役割 (サービスプロバイダーとクライアントアプリケーション) のみが関与するため「2 本足の OAuth」と呼ばれることがあります。 他の 3 つの認証種別は、3 番目の役割 (リソースオーナー) が関与します。そのため、「3 本足の OAuth」と呼ばれることがあります。 通常、クライアントログイン情報許可種別は、クライアントがリソースオーナーでもある場合に適用されます。 クライアントログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認しら、サービスプロバイダーはアクセストークンを返します。 3. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 4. クライアントアプリケーションは、保護されたリソースを取得します。 ## [](#関連情報)関連情報 - [Mule セキュアトークンサービス](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-secure-token-service) # OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するために使用できる 4 つの認証許可種別があります。 - [認証コード](#authorization-code) - [暗黙的](#implicit) - [リソースオーナーパスワードログイン情報](#resource-owner-password-credentials) - [クライアントログイン情報](#client-credentials) OAuth 認証フレームワークについては、RFC 6749 の「OAuth 2.0 認証フレームワーク」を参照してください。 ## [](#authorization-code)認証コード 認証コード許可種別では、認証サーバー (保護されたリソースにアクセスするための権限を確認して付与する) とリソースサーバー (保護されたリソースへのアクセスを提供する) を使用します。独立したサーバーとして記述されていますが、認証サーバーとリソースサーバーは同じ Mule サーバーに存在します。認証コード許可種別を使用する場合、クライアントアプリケーションは、保護されたリソースへのアクセス権を付与するトークンを要求する前に、サービスプロバイダーに認証コードを要求する必要があります。 認証コード許可種別は、認証されていないパーティ (リソースオーナーを含む) に公開することなくクライアントを認証してアクセストークンを転送するため、特に安全です。 認証コード許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションはサービスプロバイダーによって制御されている、保護されたリソースを使用するために、リソースへのアクセス要求を開始します。 2. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 3. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、サービスプロバイダーの認証を受けます。 4. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーは認証コードを返します。 5. クライアントアプリケーションは、認証サーバーをもう一度コールし、認証コード、クライアント ID (再度)、クライアントシークレットを提供します。 6. サービスプロバイダーは、アクセストークンを返します。 7. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 8. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#implicit)暗黙的 認証コード許可種別と同様に、暗黙的許可種別には認証サーバーとリソースサーバーが関与します。ただし、認証コードとクライアントシークレットを使用してクライアントアプリケーションを認証するための追加手順を実行する代わりに、サービスプロバイダーは次の作業を行います。 - クライアント ID に基づいてクライアントを認証する。 - 保護されたリソースにアクセスするためのアクセストークンを提供する。 暗黙的許可種別は、Javascript などのスクリプト言語を使用するブラウザークライアントのパフォーマンスを最適化します。ただし、この許可種別では、アクセストークンをリソースオーナーまたはリソースオーナーのユーザーエージェントに公開できます。 暗黙的許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、リソースオーナーがサービスプロバイダーに対してクライアントアプリケーションを認証するように要求します。 3. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーはアクセストークンを返します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#resource-owner-password-credentials)リソースオーナーパスワードログイン情報 リソースオーナーパスワードログイン情報許可種別を使用する場合、クライアントアプリケーションは、リソースオーナーがサービスプロバイダーのログイン情報を共有するように要求します。次に、クライアントアプリケーションは、それらのログイン情報を使用して、サービスプロバイダーにアクセスし、リソースオーナーのアカウントにアクセスします。サービスプロバイダーは、有効なログイン情報を受け入れて、リソースオーナーのアカウントへのフルアクセス権をクライアントアプリケーションに付与します。 この認証種別は、安全なアクセスログイン情報の共有を犠牲にしてパフォーマンスを最適化します。リソースオーナーは、クライアントアプリケーションが非公開データへのアクセス権を共有しないことを信頼する必要があります。 リソースオーナーパスワードログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. リソースオーナーは、アクセスログイン情報をクライアントアプリケーションに提供します。 2. クライアントアプリケーションは、サービスプロバイダーをコールしてアクセストークンを要求します。クライアントは、コール時にサービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。保護されたリソースのアクセスログイン情報も提供します。 3. サービスプロバイダーは、クライアントアプリケーションを認証し、アクセスログイン情報を検証します。次に、アクセストークンを発行します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースへのアクセスを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#client-credentials)クライアントログイン情報 クライアントログイン情報許可種別を使用する場合、クライアントアプリケーションは、特定のリソースオーナーに関連付けられていないデータへのアクセスを要求します。この許可種別では、サービスプロバイダーはクライアントが有効であるかどうかのみを検証する必要があります。この種別の OAuth インタラクションは、2 つの役割 (サービスプロバイダーとクライアントアプリケーション) のみが関与するため「2 本足の OAuth」と呼ばれることがあります。 他の 3 つの認証種別は、3 番目の役割 (リソースオーナー) が関与します。そのため、「3 本足の OAuth」と呼ばれることがあります。 通常、クライアントログイン情報許可種別は、クライアントがリソースオーナーでもある場合に適用されます。 クライアントログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認しら、サービスプロバイダーはアクセストークンを返します。 3. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 4. クライアントアプリケーションは、保護されたリソースを取得します。 ## [](#関連情報)関連情報 - [Mule セキュアトークンサービス](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-secure-token-service) # OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するために使用できる 4 つの認証許可種別があります。 - [認証コード](#authorization-code) - [暗黙的](#implicit) - [リソースオーナーパスワードログイン情報](#resource-owner-password-credentials) - [クライアントログイン情報](#client-credentials) OAuth 認証フレームワークについては、RFC 6749 の「OAuth 2.0 認証フレームワーク」を参照してください。 ## [](#authorization-code)認証コード 認証コード許可種別では、認証サーバー (保護されたリソースにアクセスするための権限を確認して付与する) とリソースサーバー (保護されたリソースへのアクセスを提供する) を使用します。独立したサーバーとして記述されていますが、認証サーバーとリソースサーバーは同じ Mule サーバーに存在します。認証コード許可種別を使用する場合、クライアントアプリケーションは、保護されたリソースへのアクセス権を付与するトークンを要求する前に、サービスプロバイダーに認証コードを要求する必要があります。 認証コード許可種別は、認証されていないパーティ (リソースオーナーを含む) に公開することなくクライアントを認証してアクセストークンを転送するため、特に安全です。 認証コード許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションはサービスプロバイダーによって制御されている、保護されたリソースを使用するために、リソースへのアクセス要求を開始します。 2. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 3. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、サービスプロバイダーの認証を受けます。 4. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーは認証コードを返します。 5. クライアントアプリケーションは、認証サーバーをもう一度コールし、認証コード、クライアント ID (再度)、クライアントシークレットを提供します。 6. サービスプロバイダーは、アクセストークンを返します。 7. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 8. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#implicit)暗黙的 認証コード許可種別と同様に、暗黙的許可種別には認証サーバーとリソースサーバーが関与します。ただし、認証コードとクライアントシークレットを使用してクライアントアプリケーションを認証するための追加手順を実行する代わりに、サービスプロバイダーは次の作業を行います。 - クライアント ID に基づいてクライアントを認証する。 - 保護されたリソースにアクセスするためのアクセストークンを提供する。 暗黙的許可種別は、Javascript などのスクリプト言語を使用するブラウザークライアントのパフォーマンスを最適化します。ただし、この許可種別では、アクセストークンをリソースオーナーまたはリソースオーナーのユーザーエージェントに公開できます。 暗黙的許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、リソースオーナーがサービスプロバイダーに対してクライアントアプリケーションを認証するように要求します。 3. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーはアクセストークンを返します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#resource-owner-password-credentials)リソースオーナーパスワードログイン情報 リソースオーナーパスワードログイン情報許可種別を使用する場合、クライアントアプリケーションは、リソースオーナーがサービスプロバイダーのログイン情報を共有するように要求します。次に、クライアントアプリケーションは、それらのログイン情報を使用して、サービスプロバイダーにアクセスし、リソースオーナーのアカウントにアクセスします。サービスプロバイダーは、有効なログイン情報を受け入れて、リソースオーナーのアカウントへのフルアクセス権をクライアントアプリケーションに付与します。 この認証種別は、安全なアクセスログイン情報の共有を犠牲にしてパフォーマンスを最適化します。リソースオーナーは、クライアントアプリケーションが非公開データへのアクセス権を共有しないことを信頼する必要があります。 リソースオーナーパスワードログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. リソースオーナーは、アクセスログイン情報をクライアントアプリケーションに提供します。 2. クライアントアプリケーションは、サービスプロバイダーをコールしてアクセストークンを要求します。クライアントは、コール時にサービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。保護されたリソースのアクセスログイン情報も提供します。 3. サービスプロバイダーは、クライアントアプリケーションを認証し、アクセスログイン情報を検証します。次に、アクセストークンを発行します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースへのアクセスを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#client-credentials)クライアントログイン情報 クライアントログイン情報許可種別を使用する場合、クライアントアプリケーションは、特定のリソースオーナーに関連付けられていないデータへのアクセスを要求します。この許可種別では、サービスプロバイダーはクライアントが有効であるかどうかのみを検証する必要があります。この種別の OAuth インタラクションは、2 つの役割 (サービスプロバイダーとクライアントアプリケーション) のみが関与するため「2 本足の OAuth」と呼ばれることがあります。 他の 3 つの認証種別は、3 番目の役割 (リソースオーナー) が関与します。そのため、「3 本足の OAuth」と呼ばれることがあります。 通常、クライアントログイン情報許可種別は、クライアントがリソースオーナーでもある場合に適用されます。 クライアントログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認しら、サービスプロバイダーはアクセストークンを返します。 3. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 4. クライアントアプリケーションは、保護されたリソースを取得します。 ## [](#関連情報)関連情報 - [Mule セキュアトークンサービス](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-secure-token-service) # OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するために使用できる 4 つの認証許可種別があります。 - [認証コード](#authorization-code) - [暗黙的](#implicit) - [リソースオーナーパスワードログイン情報](#resource-owner-password-credentials) - [クライアントログイン情報](#client-credentials) OAuth 認証フレームワークについては、RFC 6749 の「OAuth 2.0 認証フレームワーク」を参照してください。 ## [](#authorization-code)認証コード 認証コード許可種別では、認証サーバー (保護されたリソースにアクセスするための権限を確認して付与する) とリソースサーバー (保護されたリソースへのアクセスを提供する) を使用します。独立したサーバーとして記述されていますが、認証サーバーとリソースサーバーは同じ Mule サーバーに存在します。認証コード許可種別を使用する場合、クライアントアプリケーションは、保護されたリソースへのアクセス権を付与するトークンを要求する前に、サービスプロバイダーに認証コードを要求する必要があります。 認証コード許可種別は、認証されていないパーティ (リソースオーナーを含む) に公開することなくクライアントを認証してアクセストークンを転送するため、特に安全です。 認証コード許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションはサービスプロバイダーによって制御されている、保護されたリソースを使用するために、リソースへのアクセス要求を開始します。 2. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 3. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、サービスプロバイダーの認証を受けます。 4. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーは認証コードを返します。 5. クライアントアプリケーションは、認証サーバーをもう一度コールし、認証コード、クライアント ID (再度)、クライアントシークレットを提供します。 6. サービスプロバイダーは、アクセストークンを返します。 7. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 8. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#implicit)暗黙的 認証コード許可種別と同様に、暗黙的許可種別には認証サーバーとリソースサーバーが関与します。ただし、認証コードとクライアントシークレットを使用してクライアントアプリケーションを認証するための追加手順を実行する代わりに、サービスプロバイダーは次の作業を行います。 - クライアント ID に基づいてクライアントを認証する。 - 保護されたリソースにアクセスするためのアクセストークンを提供する。 暗黙的許可種別は、Javascript などのスクリプト言語を使用するブラウザークライアントのパフォーマンスを最適化します。ただし、この許可種別では、アクセストークンをリソースオーナーまたはリソースオーナーのユーザーエージェントに公開できます。 暗黙的許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、リソースオーナーがサービスプロバイダーに対してクライアントアプリケーションを認証するように要求します。 3. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーはアクセストークンを返します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#resource-owner-password-credentials)リソースオーナーパスワードログイン情報 リソースオーナーパスワードログイン情報許可種別を使用する場合、クライアントアプリケーションは、リソースオーナーがサービスプロバイダーのログイン情報を共有するように要求します。次に、クライアントアプリケーションは、それらのログイン情報を使用して、サービスプロバイダーにアクセスし、リソースオーナーのアカウントにアクセスします。サービスプロバイダーは、有効なログイン情報を受け入れて、リソースオーナーのアカウントへのフルアクセス権をクライアントアプリケーションに付与します。 この認証種別は、安全なアクセスログイン情報の共有を犠牲にしてパフォーマンスを最適化します。リソースオーナーは、クライアントアプリケーションが非公開データへのアクセス権を共有しないことを信頼する必要があります。 リソースオーナーパスワードログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. リソースオーナーは、アクセスログイン情報をクライアントアプリケーションに提供します。 2. クライアントアプリケーションは、サービスプロバイダーをコールしてアクセストークンを要求します。クライアントは、コール時にサービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。保護されたリソースのアクセスログイン情報も提供します。 3. サービスプロバイダーは、クライアントアプリケーションを認証し、アクセスログイン情報を検証します。次に、アクセストークンを発行します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースへのアクセスを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#client-credentials)クライアントログイン情報 クライアントログイン情報許可種別を使用する場合、クライアントアプリケーションは、特定のリソースオーナーに関連付けられていないデータへのアクセスを要求します。この許可種別では、サービスプロバイダーはクライアントが有効であるかどうかのみを検証する必要があります。この種別の OAuth インタラクションは、2 つの役割 (サービスプロバイダーとクライアントアプリケーション) のみが関与するため「2 本足の OAuth」と呼ばれることがあります。 他の 3 つの認証種別は、3 番目の役割 (リソースオーナー) が関与します。そのため、「3 本足の OAuth」と呼ばれることがあります。 通常、クライアントログイン情報許可種別は、クライアントがリソースオーナーでもある場合に適用されます。 クライアントログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認しら、サービスプロバイダーはアクセストークンを返します。 3. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 4. クライアントアプリケーションは、保護されたリソースを取得します。 ## [](#関連情報)関連情報 - [Mule セキュアトークンサービス](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-secure-token-service) # OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するために使用できる 4 つの認証許可種別があります。 - [認証コード](#authorization-code) - [暗黙的](#implicit) - [リソースオーナーパスワードログイン情報](#resource-owner-password-credentials) - [クライアントログイン情報](#client-credentials) OAuth 認証フレームワークについては、RFC 6749 の「OAuth 2.0 認証フレームワーク」を参照してください。 ## [](#authorization-code)認証コード 認証コード許可種別では、認証サーバー (保護されたリソースにアクセスするための権限を確認して付与する) とリソースサーバー (保護されたリソースへのアクセスを提供する) を使用します。独立したサーバーとして記述されていますが、認証サーバーとリソースサーバーは同じ Mule サーバーに存在します。認証コード許可種別を使用する場合、クライアントアプリケーションは、保護されたリソースへのアクセス権を付与するトークンを要求する前に、サービスプロバイダーに認証コードを要求する必要があります。 認証コード許可種別は、認証されていないパーティ (リソースオーナーを含む) に公開することなくクライアントを認証してアクセストークンを転送するため、特に安全です。 認証コード許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションはサービスプロバイダーによって制御されている、保護されたリソースを使用するために、リソースへのアクセス要求を開始します。 2. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 3. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、サービスプロバイダーの認証を受けます。 4. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーは認証コードを返します。 5. クライアントアプリケーションは、認証サーバーをもう一度コールし、認証コード、クライアント ID (再度)、クライアントシークレットを提供します。 6. サービスプロバイダーは、アクセストークンを返します。 7. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 8. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#implicit)暗黙的 認証コード許可種別と同様に、暗黙的許可種別には認証サーバーとリソースサーバーが関与します。ただし、認証コードとクライアントシークレットを使用してクライアントアプリケーションを認証するための追加手順を実行する代わりに、サービスプロバイダーは次の作業を行います。 - クライアント ID に基づいてクライアントを認証する。 - 保護されたリソースにアクセスするためのアクセストークンを提供する。 暗黙的許可種別は、Javascript などのスクリプト言語を使用するブラウザークライアントのパフォーマンスを最適化します。ただし、この許可種別では、アクセストークンをリソースオーナーまたはリソースオーナーのユーザーエージェントに公開できます。 暗黙的許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、リソースオーナーがサービスプロバイダーに対してクライアントアプリケーションを認証するように要求します。 3. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーはアクセストークンを返します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#resource-owner-password-credentials)リソースオーナーパスワードログイン情報 リソースオーナーパスワードログイン情報許可種別を使用する場合、クライアントアプリケーションは、リソースオーナーがサービスプロバイダーのログイン情報を共有するように要求します。次に、クライアントアプリケーションは、それらのログイン情報を使用して、サービスプロバイダーにアクセスし、リソースオーナーのアカウントにアクセスします。サービスプロバイダーは、有効なログイン情報を受け入れて、リソースオーナーのアカウントへのフルアクセス権をクライアントアプリケーションに付与します。 この認証種別は、安全なアクセスログイン情報の共有を犠牲にしてパフォーマンスを最適化します。リソースオーナーは、クライアントアプリケーションが非公開データへのアクセス権を共有しないことを信頼する必要があります。 リソースオーナーパスワードログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. リソースオーナーは、アクセスログイン情報をクライアントアプリケーションに提供します。 2. クライアントアプリケーションは、サービスプロバイダーをコールしてアクセストークンを要求します。クライアントは、コール時にサービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。保護されたリソースのアクセスログイン情報も提供します。 3. サービスプロバイダーは、クライアントアプリケーションを認証し、アクセスログイン情報を検証します。次に、アクセストークンを発行します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースへのアクセスを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#client-credentials)クライアントログイン情報 クライアントログイン情報許可種別を使用する場合、クライアントアプリケーションは、特定のリソースオーナーに関連付けられていないデータへのアクセスを要求します。この許可種別では、サービスプロバイダーはクライアントが有効であるかどうかのみを検証する必要があります。この種別の OAuth インタラクションは、2 つの役割 (サービスプロバイダーとクライアントアプリケーション) のみが関与するため「2 本足の OAuth」と呼ばれることがあります。 他の 3 つの認証種別は、3 番目の役割 (リソースオーナー) が関与します。そのため、「3 本足の OAuth」と呼ばれることがあります。 通常、クライアントログイン情報許可種別は、クライアントがリソースオーナーでもある場合に適用されます。 クライアントログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認しら、サービスプロバイダーはアクセストークンを返します。 3. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 4. クライアントアプリケーションは、保護されたリソースを取得します。 ## [](#関連情報)関連情報 - [Mule セキュアトークンサービス](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-secure-token-service) # OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するために使用できる 4 つの認証許可種別があります。 - [認証コード](#authorization-code) - [暗黙的](#implicit) - [リソースオーナーパスワードログイン情報](#resource-owner-password-credentials) - [クライアントログイン情報](#client-credentials) OAuth 認証フレームワークについては、RFC 6749 の「OAuth 2.0 認証フレームワーク」を参照してください。 ## [](#authorization-code)認証コード 認証コード許可種別では、認証サーバー (保護されたリソースにアクセスするための権限を確認して付与する) とリソースサーバー (保護されたリソースへのアクセスを提供する) を使用します。独立したサーバーとして記述されていますが、認証サーバーとリソースサーバーは同じ Mule サーバーに存在します。認証コード許可種別を使用する場合、クライアントアプリケーションは、保護されたリソースへのアクセス権を付与するトークンを要求する前に、サービスプロバイダーに認証コードを要求する必要があります。 認証コード許可種別は、認証されていないパーティ (リソースオーナーを含む) に公開することなくクライアントを認証してアクセストークンを転送するため、特に安全です。 認証コード許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションはサービスプロバイダーによって制御されている、保護されたリソースを使用するために、リソースへのアクセス要求を開始します。 2. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 3. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、サービスプロバイダーの認証を受けます。 4. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーは認証コードを返します。 5. クライアントアプリケーションは、認証サーバーをもう一度コールし、認証コード、クライアント ID (再度)、クライアントシークレットを提供します。 6. サービスプロバイダーは、アクセストークンを返します。 7. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 8. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#implicit)暗黙的 認証コード許可種別と同様に、暗黙的許可種別には認証サーバーとリソースサーバーが関与します。ただし、認証コードとクライアントシークレットを使用してクライアントアプリケーションを認証するための追加手順を実行する代わりに、サービスプロバイダーは次の作業を行います。 - クライアント ID に基づいてクライアントを認証する。 - 保護されたリソースにアクセスするためのアクセストークンを提供する。 暗黙的許可種別は、Javascript などのスクリプト言語を使用するブラウザークライアントのパフォーマンスを最適化します。ただし、この許可種別では、アクセストークンをリソースオーナーまたはリソースオーナーのユーザーエージェントに公開できます。 暗黙的許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、リソースオーナーがサービスプロバイダーに対してクライアントアプリケーションを認証するように要求します。 3. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーはアクセストークンを返します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#resource-owner-password-credentials)リソースオーナーパスワードログイン情報 リソースオーナーパスワードログイン情報許可種別を使用する場合、クライアントアプリケーションは、リソースオーナーがサービスプロバイダーのログイン情報を共有するように要求します。次に、クライアントアプリケーションは、それらのログイン情報を使用して、サービスプロバイダーにアクセスし、リソースオーナーのアカウントにアクセスします。サービスプロバイダーは、有効なログイン情報を受け入れて、リソースオーナーのアカウントへのフルアクセス権をクライアントアプリケーションに付与します。 この認証種別は、安全なアクセスログイン情報の共有を犠牲にしてパフォーマンスを最適化します。リソースオーナーは、クライアントアプリケーションが非公開データへのアクセス権を共有しないことを信頼する必要があります。 リソースオーナーパスワードログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. リソースオーナーは、アクセスログイン情報をクライアントアプリケーションに提供します。 2. クライアントアプリケーションは、サービスプロバイダーをコールしてアクセストークンを要求します。クライアントは、コール時にサービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。保護されたリソースのアクセスログイン情報も提供します。 3. サービスプロバイダーは、クライアントアプリケーションを認証し、アクセスログイン情報を検証します。次に、アクセストークンを発行します。 4. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースへのアクセスを要求するためのアクセストークンを提供します。 5. サービスプロバイダーは、保護されたリソースを提供します。 ## [](#client-credentials)クライアントログイン情報 クライアントログイン情報許可種別を使用する場合、クライアントアプリケーションは、特定のリソースオーナーに関連付けられていないデータへのアクセスを要求します。この許可種別では、サービスプロバイダーはクライアントが有効であるかどうかのみを検証する必要があります。この種別の OAuth インタラクションは、2 つの役割 (サービスプロバイダーとクライアントアプリケーション) のみが関与するため「2 本足の OAuth」と呼ばれることがあります。 他の 3 つの認証種別は、3 番目の役割 (リソースオーナー) が関与します。そのため、「3 本足の OAuth」と呼ばれることがあります。 通常、クライアントログイン情報許可種別は、クライアントがリソースオーナーでもある場合に適用されます。 クライアントログイン情報許可種別を使用する OAuth ダンスは次のように機能します。 1. クライアントアプリケーションは、認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。 2. クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認しら、サービスプロバイダーはアクセストークンを返します。 3. クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。 4. クライアントアプリケーションは、保護されたリソースを取得します。 ## [](#関連情報)関連情報 - [Mule セキュアトークンサービス](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-secure-token-service) # OAuth2 プロバイダーの移行 Anypoint Enterprise Security の以前のプロバイダーは、Mule 4 の新しい OAuth2 Provider Module に置き換えられます。 ただし、アプリケーションを移行するときに考慮する必要がある設定変更がいくつかあります。 ## [](#グローバル設定の移行)グローバル設定の移行 プロバイダーのグローバル設定で行われた変更とバージョン間の違いを以下に示します。 ### [](#変更された属性)変更された属性 属性の状況は次のとおりです。 - 維持: 同じ名前、型、場所を使用します。 - 移動: 属性の名前と型は同じですが、設定を行う場所が変更されました。 - 変更: 型または名前が変更されましたが、場所は同じです。 - 削除: 属性は存在しません。
Mule 3 の属性 状況 Mule 4 の設定

Name (名前)

維持

Name (名前)

Provider Name (プロバイダー名)

維持

Provider Name (プロバイダー名)

Host (ホスト)

削除

ホストは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Port (ポート)

削除

ポートは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Client Store Ref (クライアントストア参照)

変更

属性はオブジェクトストアになりました。参照または非公開オブジェクトストアの定義である必要があります。

Authorization Code Store Ref (認証コードストア参照)

移動、変更

認証コードストアは、​Authorization Config (認証設定)​ の属性として設定し、オブジェクトストアである必要があります。

Token Generator Strategy (トークンジェネレーター戦略)

維持

Token Generator Strategy (トークンジェネレーター戦略)

Token Store Ref (トークンストア参照)

移動、変更

トークンストアは、​Token Config (トークン設定)​ の属性として設定し、オブジェクトストアである必要があります。

Login Page (ログインページ)

移動

ログインページは ​Authorization Config (認証設定)​ の属性として設定します。

スコープ

維持

カンマ区切りにする必要があります。

Default Scopes (デフォルトスコープ)

維持

カンマ区切りにする必要があります。

Supported Grant Types (サポートされる付与種別)

維持

カンマ区切りにする必要があります。

Authorization Endpoint Path (認証エンドポイントパス)

変更、移動

Authorization Config (認証設定)​ の属性 ​path​ で設定できます。

Access Token Endpoint Path (アクセストークンエンドポイントパス)

変更、移動

Token Config (トークン設定)​ の属性 ​path​ で設定できます。

Authorization Ttl Seconds (認証 Ttl 秒)

削除

認証コード Ttl は、​Authorization Code Store (認証コードストア)​ オブジェクトストアで設定された entry Ttl (入力 Ttl) から取得されます。

Token Ttl Seconds (トークン Ttl 秒)

移動、変更

トークン Ttl は ​Token Store (トークンストア)​ オブジェクトストアから取得されます。コード上の制限により、この項目を ​TokenConfig​ の属性 ​tokenTtl​ と ​tokenTtlTimeUnit​ でも設定する必要があります。​Token Store (トークンストア)​ の ​entryTtl​ と ​Token Config (トークン設定)​ の ​tokenTtl​ (および ​tokenTtlTimeUnit​) は同じにする必要があります。

Refresh Token Ttl Seconds (更新トークン Ttl 秒)

削除

更新トークン Ttl は、​Refresh Token Strategy (更新トークン戦略)​ で設定されたオブジェクトストアの entry Ttl (入力 Ttl) から取得されます (ある場合)。

Connector (コネクタ)

削除

トランスポートが Mule 4 から削除されたので、この項目には意味がなくなりました。

HttpListenerConfig

変更

Listener Config (リスナー設定)​ と呼ばれるようになりました。必須です。

Resource Owner Security Provider Ref (リソースオーナーセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Client Security Provider Ref (クライアントセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Enable Refresh Token (更新トークンの有効化)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Issue New Refresh Token (更新トークンの新規発行)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Rate Limiter (レートリミッター)

変更

Spring bean からカスタム実装を追加する必要がなくなりました。Period Rate Limiter (期間レートリミッター) のみが実装されるようになりました。

Clients (クライアント)

維持

各クライアント定義が変更されました。

Pre Flow (プリフロー)

削除

プリフロー機能は、このバージョンではサポートされません。
## [](#ストア)ストア Authentication Code (認証コード)、Token (トークン)、または Refresh token (更新トークン) ストアはなくなりました。これらのカスタム実装を参照できる属性はありません。 ストレージ設定は、オブジェクトストアで行われるようになりました。 カスタム動作が必要な場合は、オブジェクトストアのカスタム実装を使用してそれらの属性を設定します。 ## [](#セキュリティプロバイダー)セキュリティプロバイダー Mule 4 では、アプリケーション設定を Spring から完全に分離したので、Spirng bean を参照して設定された一部の属性の設定方法が変更されました。 Spring セキュリティプロバイダーは引き続き使用できますが、その場合、アプリケーションが機能するには Spring Module が必要です。 ## [](#更新トークン属性)更新トークン属性 Mule 3 には、更新トークンの動作を設定できる 2 つの属性がありました。さまざまな更新トークン戦略が使用されるようになったので、次のように設定する必要があります。

Enable Refresh Token (更新トークンの有効化)

Issue New Refresh Token (更新トークンの新規発行)

Refresh Token Strategy (更新トークン戦略)

False

-

更新トークン戦略なし

True

False

1 つの更新トークン戦略

True

True

複数の更新トークン戦略
## [](#clients-クライアント)Clients (クライアント) どちらの Mule バージョンでも、認証サーバーに要求を実行できるクライアントのリストを定義する可能性があります。 クライアントを追加する方法は、一部の属性名以外は変わりありません。新しいバージョンの制限により、子要素の名前は、​_clients_​ および ​_client_​ プレフィックスを追加して変更する必要がありました。 - Redirect Uri(s) → Client Redirect Uris(s) - Authorized Grant Type(s) → Client Authorized Grant Type(s) - Scope(s) → Client Scope(s) ## [](#操作)操作 Mule 3 のモジュールで使用可能な操作と Mule 4 で行われた変更を以下に示します ### [](#validate-client)Validate Client この操作は Mule 4 から削除されました。 ### [](#validate)Validate この操作は、​**Validate Token**​ と呼ばれるようになりました。 Oauth2 プロバイダーの操作は HTTP にリンクされなくなったので、検証するトークンを解決する式が必要です。 Mule 3 では、トークン検証後、関連するリソースオーナー認証がある場合、そのリソースオーナー認証で新しいセキュリティコンテキストが作成されました。さらに、トークン情報を持つトークン保有者が _mule.oauth2.access\_token\_store\_holder_ というフロー変数に保存されました。 Mule 4 では、その同じ情報が若干異なる方法で保存されます。トークン検証後、​`#[authentication]`​ によってアクセス可能なトークン認証を使用してセキュリティコンテキストが作成されます。変数内のトークン所有者は、そのトークン認証の属性 ​`#[authentication.tokenHolder]`​ として保存されます。同時に、関連するリソースオーナーがある場合、その情報には ​`#[authentication.tokenHolder.resourceOwnerAuthentication]`​ を評価して到達できます。 ### [](#create-client)Create Client この操作は、​**Fail If Present (存在する場合は失敗)**​ という新しい属性が追加された以外は変わりありません。 **Fail If Present (存在する場合は失敗)**​ では、追加されるクライアントと同じ ID を持つクライアントが既存する場合にどうするかを指定できます。 - true の場合、操作は失敗します。 - false の場合、クライアント情報が更新されます。 ### [](#delete-client)Delete Client この操作は変わりありません。 ### [](#revoke-token)Revoke Token この操作は変わりありません。 ## [](#例)例 Mule 3 と Mule 4 で同じアプリケーションを設定した例を次に示します。 アプリケーションには、トークンを付与する Oauth2 プロバイダーと HTTP 要求をリスンするフローがあり、あるロジックを処理する前にトークン検証があります。 Mule 4 設定では Spring Module と Object Store Connector が使用されている点に留意してください。 どちらの場合も、アプリケーションは複数のファイルに分割されています。 Mule 3 の場合は、共通設定と実際の OAuth2 プロバイダー設定に 1 つずつ、2 つのファイルがあります。 Mule 4 の場合は、bean 定義、共通設定、実際の OAuth2 プロバイダー設定に 1 つずつ、3 つのファイルがあります。 ### [](#mule-3)Mule 3 #### [](#共通設定)共通設定 ```xml ``` #### [](#アプリケーション設定)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ### [](#mule-4)Mule 4 #### [](#bean-設定)Bean 設定 ```xml ``` #### [](#共通設定-2)共通設定 ```xml ``` #### [](#アプリケーション設定-2)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ## [](#関連情報)関連情報 - [OAuth2 プロバイダードキュメントリファレンス](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference) # OAuth2 プロバイダーの移行 Anypoint Enterprise Security の以前のプロバイダーは、Mule 4 の新しい OAuth2 プロバイダーモジュールに置き換えられます。 ただし、アプリケーションを移行するときに考慮する必要がある設定変更がいくつかあります。 ## [](#グローバル設定の移行)グローバル設定の移行 プロバイダーのグローバル設定で行われた変更とバージョン間の違いを以下に示します。 ### [](#変更された属性)変更された属性 属性の状況は次のとおりです。 - 維持: 同じ名前、型、場所を使用します。 - 移動: 属性の名前と型は同じですが、設定を行う場所が変更されました。 - 変更: 型または名前が変更されましたが、場所は同じです。 - 削除: 属性は存在しません。
Mule 3 の属性 状況 Mule 4 の設定

Name (名前)

維持

Name (名前)

Provider Name (プロバイダー名)

維持

Provider Name (プロバイダー名)

Host (ホスト)

削除

ホストは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Port (ポート)

削除

ポートは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Client Store Ref (クライアントストア参照)

変更

属性はオブジェクトストアになりました。参照または非公開オブジェクトストアの定義である必要があります。

Authorization Code Store Ref (認証コードストア参照)

移動、変更

認証コードストアは、​Authorization Config (認証設定)​ の属性として設定し、オブジェクトストアである必要があります。

Token Generator Strategy (トークンジェネレーター戦略)

維持

Token Generator Strategy (トークンジェネレーター戦略)

Token Store Ref (トークンストア参照)

移動、変更

トークンストアは、​Token Config (トークン設定)​ の属性として設定し、オブジェクトストアである必要があります。

Login Page (ログインページ)

移動

ログインページは ​Authorization Config (認証設定)​ の属性として設定します。

スコープ

維持

カンマ区切りにする必要があります。

Default Scopes (デフォルトスコープ)

維持

カンマ区切りにする必要があります。

Supported Grant Types (サポートされる付与種別)

維持

カンマ区切りにする必要があります。

Authorization Endpoint Path (認証エンドポイントパス)

変更、移動

Authorization Config (認証設定)​ の属性 ​path​ で設定できます。

Access Token Endpoint Path (アクセストークンエンドポイントパス)

変更、移動

Token Config (トークン設定)​ の属性 ​path​ で設定できます。

Authorization Ttl Seconds (認証 Ttl 秒)

削除

認証コード Ttl は、​Authorization Code Store (認証コードストア)​ オブジェクトストアで設定された entry Ttl (入力 Ttl) から取得されます。

Token Ttl Seconds (トークン Ttl 秒)

移動、変更

トークン Ttl は ​Token Store (トークンストア)​ オブジェクトストアから取得されます。コード上の制限により、この項目を ​TokenConfig​ の属性 ​tokenTtl​ と ​tokenTtlTimeUnit​ でも設定する必要があります。​Token Store (トークンストア)​ の ​entryTtl​ と ​Token Config (トークン設定)​ の ​tokenTtl​ (および ​tokenTtlTimeUnit​) は同じにする必要があります。

Refresh Token Ttl Seconds (更新トークン Ttl 秒)

削除

更新トークン Ttl は、​Refresh Token Strategy (更新トークン戦略)​ で設定されたオブジェクトストアの entry Ttl (入力 Ttl) から取得されます (ある場合)。

Connector (コネクタ)

削除

トランスポートが Mule 4 から削除されたので、この項目には意味がなくなりました。

HttpListenerConfig

変更

Listener Config (リスナー設定)​ と呼ばれるようになりました。必須です。

Resource Owner Security Provider Ref (リソースオーナーセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Client Security Provider Ref (クライアントセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Enable Refresh Token (更新トークンの有効化)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Issue New Refresh Token (更新トークンの新規発行)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Rate Limiter (レートリミッター)

変更

Spring bean からカスタム実装を追加する必要がなくなりました。Period Rate Limiter (期間レートリミッター) のみが実装されるようになりました。

Clients (クライアント)

維持

各クライアント定義が変更されました。

Pre Flow (プリフロー)

削除

プリフロー機能は、このバージョンではサポートされません。
## [](#ストア)ストア Authentication Code (認証コード)、Token (トークン)、または Refresh token (更新トークン) ストアはなくなりました。これらのカスタム実装を参照できる属性はありません。 ストレージ設定は、オブジェクトストアで行われるようになりました。 カスタム動作が必要な場合は、オブジェクトストアのカスタム実装を使用してそれらの属性を設定します。 ## [](#セキュリティプロバイダー)セキュリティプロバイダー Mule 4 では、アプリケーション設定を Spring から完全に分離したので、Spirng bean を参照して設定された一部の属性の設定方法が変更されました。 Spring セキュリティプロバイダーは引き続き使用できますが、その場合、アプリケーションが機能するには Spring Module が必要です。 ## [](#更新トークン属性)更新トークン属性 Mule 3 には、更新トークンの動作を設定できる 2 つの属性がありました。さまざまな更新トークン戦略が使用されるようになったので、次のように設定する必要があります。

Enable Refresh Token (更新トークンの有効化)

Issue New Refresh Token (更新トークンの新規発行)

Refresh Token Strategy (更新トークン戦略)

False

-

更新トークン戦略なし

True

False

1 つの更新トークン戦略

True

True

複数の更新トークン戦略
## [](#clients-クライアント)Clients (クライアント) どちらの Mule バージョンでも、認証サーバーに要求を実行できるクライアントのリストを定義する可能性があります。 クライアントを追加する方法は、一部の属性名以外は変わりありません。新しいバージョンの制限により、子要素の名前は、​_clients_​ および ​_client_​ プレフィックスを追加して変更する必要がありました。 - Redirect Uri(s) → Client Redirect Uris(s) - Authorized Grant Type(s) → Client Authorized Grant Type(s) - Scope(s) → Client Scope(s) ## [](#操作)操作 Mule 3 のモジュールで使用可能な操作と Mule 4 で行われた変更を以下に示します ### [](#validate-client)Validate Client この操作は Mule 4 から削除されました。 ### [](#validate)Validate この操作は、​**Validate Token**​ と呼ばれるようになりました。 Oauth2 プロバイダーの操作は HTTP にリンクされなくなったので、検証するトークンを解決する式が必要です。 Mule 3 では、トークン検証後、関連するリソースオーナー認証がある場合、そのリソースオーナー認証で新しいセキュリティコンテキストが作成されました。さらに、トークン情報を持つトークン保有者が _mule.oauth2.access\_token\_store\_holder_ というフロー変数に保存されました。 Mule 4 では、その同じ情報が若干異なる方法で保存されます。トークン検証後、​`#[authentication]`​ によってアクセス可能なトークン認証を使用してセキュリティコンテキストが作成されます。変数内のトークン所有者は、そのトークン認証の属性 ​`#[authentication.tokenHolder]`​ として保存されます。同時に、関連するリソースオーナーがある場合、その情報には ​`#[authentication.tokenHolder.resourceOwnerAuthentication]`​ を評価して到達できます。 ### [](#create-client)Create Client この操作は、​**Fail If Present (存在する場合は失敗)**​ という新しい属性が追加された以外は変わりありません。 **Fail If Present (存在する場合は失敗)**​ では、追加されるクライアントと同じ ID を持つクライアントが既存する場合にどうするかを指定できます。 - true の場合、操作は失敗します。 - false の場合、クライアント情報が更新されます。 ### [](#delete-client)Delete Client この操作は変わりありません。 ### [](#revoke-token)Revoke Token この操作は変わりありません。 ## [](#例)例 Mule 3 と Mule 4 で同じアプリケーションを設定した例を次に示します。 アプリケーションには、トークンを付与する Oauth2 プロバイダーと HTTP 要求をリスンするフローがあり、あるロジックを処理する前にトークン検証があります。 Mule 4 設定では Spring Module と Object Store Connector が使用されている点に留意してください。 どちらの場合も、アプリケーションは複数のファイルに分割されています。 Mule 3 の場合は、共通設定と実際の OAuth2 プロバイダー設定に 1 つずつ、2 つのファイルがあります。 Mule 4 の場合は、bean 定義、共通設定、実際の OAuth2 プロバイダー設定に 1 つずつ、3 つのファイルがあります。 ### [](#mule-3)Mule 3 #### [](#共通設定)共通設定 ```xml ``` #### [](#アプリケーション設定)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ### [](#mule-4)Mule 4 #### [](#bean-設定)Bean 設定 ```xml ``` #### [](#共通設定-2)共通設定 ```xml ``` #### [](#アプリケーション設定-2)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ## [](#関連情報)関連情報 - [OAuth2 プロバイダードキュメントリファレンス](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference) # OAuth2 プロバイダーの移行 Anypoint Enterprise Security の以前のプロバイダーは、Mule 4 の新しい OAuth2 Provider Module に置き換えられます。 ただし、アプリケーションを移行するときに考慮する必要がある設定変更がいくつかあります。 ## [](#グローバル設定の移行)グローバル設定の移行 プロバイダーのグローバル設定で行われた変更とバージョン間の違いを以下に示します。 ### [](#変更された属性)変更された属性 属性の状況は次のとおりです。 - 維持: 同じ名前、型、場所を使用します。 - 移動: 属性の名前と型は同じですが、設定を行う場所が変更されました。 - 変更: 型または名前が変更されましたが、場所は同じです。 - 削除: 属性は存在しません。
Mule 3 の属性 状況 Mule 4 の設定

Name (名前)

維持

Name (名前)

Provider Name (プロバイダー名)

維持

Provider Name (プロバイダー名)

Host (ホスト)

削除

ホストは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Port (ポート)

削除

ポートは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Client Store Ref (クライアントストア参照)

変更

属性はオブジェクトストアになりました。参照または非公開オブジェクトストアの定義である必要があります。

Authorization Code Store Ref (認証コードストア参照)

移動、変更

認証コードストアは、​Authorization Config (認証設定)​ の属性として設定し、オブジェクトストアである必要があります。

Token Generator Strategy (トークンジェネレーター戦略)

維持

Token Generator Strategy (トークンジェネレーター戦略)

Token Store Ref (トークンストア参照)

移動、変更

トークンストアは、​Token Config (トークン設定)​ の属性として設定し、オブジェクトストアである必要があります。

Login Page (ログインページ)

移動

ログインページは ​Authorization Config (認証設定)​ の属性として設定します。

Scopes (スコープ)

維持

カンマ区切りにする必要があります。

Default Scopes (デフォルトスコープ)

維持

カンマ区切りにする必要があります。

Supported Grant Types (サポートされる付与種別)

維持

カンマ区切りにする必要があります。

Authorization Endpoint Path (認証エンドポイントパス)

変更、移動

Authorization Config (認証設定)​ の属性 ​path​ で設定できます。

Access Token Endpoint Path (アクセストークンエンドポイントパス)

変更、移動

Token Config (トークン設定)​ の属性 ​path​ で設定できます。

Authorization Ttl Seconds (認証 Ttl 秒)

削除

認証コード Ttl は、​Authorization Code Store (認証コードストア)​ オブジェクトストアで設定された entry Ttl (入力 Ttl) から取得されます。

Token Ttl Seconds (トークン Ttl 秒)

移動、変更

トークン Ttl は ​Token Store (トークンストア)​ オブジェクトストアから取得されます。コード上の制限により、この項目を ​TokenConfig​ の属性 ​tokenTtl​ と ​tokenTtlTimeUnit​ でも設定する必要があります。​Token Store (トークンストア)​ の ​entryTtl​ と ​Token Config (トークン設定)​ の ​tokenTtl​ (および ​tokenTtlTimeUnit​) は同じにする必要があります。

Refresh Token Ttl Seconds (更新トークン Ttl 秒)

削除

更新トークン Ttl は、​Refresh Token Strategy (更新トークン戦略)​ で設定されたオブジェクトストアの entry Ttl (入力 Ttl) から取得されます (ある場合)。

Connector (コネクタ)

削除

トランスポートが Mule 4 から削除されたので、この項目には意味がなくなりました。

HttpListenerConfig

変更

Listener Config (リスナー設定)​ と呼ばれるようになりました。必須です。

Resource Owner Security Provider Ref (リソースオーナーセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Client Security Provider Ref (クライアントセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Enable Refresh Token (更新トークンの有効化)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Issue New Refresh Token (更新トークンの新規発行)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Rate Limiter (レートリミッター)

変更

Spring bean からカスタム実装を追加する必要がなくなりました。Period Rate Limiter (期間レートリミッター) のみが実装されるようになりました。

Clients (クライアント)

維持

各クライアント定義が変更されました。

Pre Flow (プリフロー)

削除

プリフロー機能は、このバージョンではサポートされません。
## [](#ストア)ストア Authentication Code (認証コード)、Token (トークン)、または Refresh token (更新トークン) ストアはなくなりました。これらのカスタム実装を参照できる属性はありません。 ストレージ設定は、オブジェクトストアで行われるようになりました。 カスタム動作が必要な場合は、オブジェクトストアのカスタム実装を使用してそれらの属性を設定します。 ## [](#セキュリティプロバイダー)セキュリティプロバイダー Mule 4 では、アプリケーション設定を Spring から完全に分離したので、Spirng bean を参照して設定された一部の属性の設定方法が変更されました。 Spring セキュリティプロバイダーは引き続き使用できますが、その場合、アプリケーションが機能するには Spring Module が必要です。 ## [](#更新トークン属性)更新トークン属性 Mule 3 には、更新トークンの動作を設定できる 2 つの属性がありました。さまざまな更新トークン戦略が使用されるようになったので、次のように設定する必要があります。

Enable Refresh Token (更新トークンの有効化)

Issue New Refresh Token (更新トークンの新規発行)

Refresh Token Strategy (更新トークン戦略)

False

-

更新トークン戦略なし

True

False

1 つの更新トークン戦略

True

True

複数の更新トークン戦略
## [](#clients-クライアント)Clients (クライアント) どちらの Mule バージョンでも、認証サーバーに要求を実行できるクライアントのリストを定義する可能性があります。 クライアントを追加する方法は、一部の属性名以外は変わりありません。新しいバージョンの制限により、子要素の名前は、​_clients_​ および ​_client_​ プレフィックスを追加して変更する必要がありました。 - Redirect Uri(s) → Client Redirect Uris(s) - Authorized Grant Type(s) → Client Authorized Grant Type(s) - Scope(s) → Client Scope(s) ## [](#操作)操作 Mule 3 のモジュールで使用可能な操作と Mule 4 で行われた変更を以下に示します ### [](#validate-client)Validate Client この操作は Mule 4 から削除されました。 ### [](#validate)Validate この操作は、​**Validate Token**​ と呼ばれるようになりました。 Oauth2 プロバイダーの操作は HTTP にリンクされなくなったので、検証するトークンを解決する式が必要です。 Mule 3 では、トークン検証後、関連するリソースオーナー認証がある場合、そのリソースオーナー認証で新しいセキュリティコンテキストが作成されました。さらに、トークン情報を持つトークン保有者が _mule.oauth2.access\_token\_store\_holder_ というフロー変数に保存されました。 Mule 4 では、その同じ情報が若干異なる方法で保存されます。トークン検証後、​`#[authentication]`​ によってアクセス可能なトークン認証を使用してセキュリティコンテキストが作成されます。変数内のトークン所有者は、そのトークン認証の属性 ​`#[authentication.tokenHolder]`​ として保存されます。同時に、関連するリソースオーナーがある場合、その情報には ​`#[authentication.tokenHolder.resourceOwnerAuthentication]`​ を評価して到達できます。 ### [](#create-client)Create Client この操作は、​**Fail If Present (存在する場合は失敗)**​ という新しい属性が追加された以外は変わりありません。 **Fail If Present (存在する場合は失敗)**​ では、追加されるクライアントと同じ ID を持つクライアントが既存する場合にどうするかを指定できます。 - true の場合、操作は失敗します。 - false の場合、クライアント情報が更新されます。 ### [](#delete-client)Delete Client この操作は変わりありません。 ### [](#revoke-token)Revoke Token この操作は変わりありません。 ## [](#例)例 Mule 3 と Mule 4 で同じアプリケーションを設定した例を次に示します。 アプリケーションには、トークンを付与する Oauth2 プロバイダーと HTTP 要求をリスンするフローがあり、あるロジックを処理する前にトークン検証があります。 Mule 4 設定では Spring Module と Object Store Connector が使用されている点に留意してください。 どちらの場合も、アプリケーションは複数のファイルに分割されています。 Mule 3 の場合は、共通設定と実際の OAuth2 プロバイダー設定に 1 つずつ、2 つのファイルがあります。 Mule 4 の場合は、bean 定義、共通設定、実際の OAuth2 プロバイダー設定に 1 つずつ、3 つのファイルがあります。 ### [](#mule-3)Mule 3 #### [](#共通設定)共通設定 ```xml ``` #### [](#アプリケーション設定)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ### [](#mule-4)Mule 4 #### [](#bean-設定)Bean 設定 ```xml ``` #### [](#共通設定-2)共通設定 ```xml ``` #### [](#アプリケーション設定-2)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ## [](#関連情報)関連情報 - [OAuth2 プロバイダードキュメントリファレンス](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference) # OAuth2 プロバイダーの移行 Anypoint Enterprise Security の以前のプロバイダーは、Mule 4 の新しい OAuth2 Provider Module に置き換えられます。 ただし、アプリケーションを移行するときに考慮する必要がある設定変更がいくつかあります。 ## [](#グローバル設定の移行)グローバル設定の移行 プロバイダーのグローバル設定で行われた変更とバージョン間の違いを以下に示します。 ### [](#変更された属性)変更された属性 属性の状況は次のとおりです。 - 維持: 同じ名前、型、場所を使用します。 - 移動: 属性の名前と型は同じですが、設定を行う場所が変更されました。 - 変更: 型または名前が変更されましたが、場所は同じです。 - 削除: 属性は存在しません。
Mule 3 の属性 状況 Mule 4 の設定

Name (名前)

維持

Name (名前)

Provider Name (プロバイダー名)

維持

Provider Name (プロバイダー名)

Host (ホスト)

削除

ホストは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Port (ポート)

削除

ポートは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Client Store Ref (クライアントストア参照)

変更

属性はオブジェクトストアになりました。参照または非公開オブジェクトストアの定義である必要があります。

Authorization Code Store Ref (認証コードストア参照)

移動、変更

認証コードストアは、​Authorization Config (認証設定)​ の属性として設定し、オブジェクトストアである必要があります。

Token Generator Strategy (トークンジェネレーター戦略)

維持

Token Generator Strategy (トークンジェネレーター戦略)

Token Store Ref (トークンストア参照)

移動、変更

トークンストアは、​Token Config (トークン設定)​ の属性として設定し、オブジェクトストアである必要があります。

Login Page (ログインページ)

移動

ログインページは ​Authorization Config (認証設定)​ の属性として設定します。

スコープ

維持

カンマ区切りにする必要があります。

Default Scopes (デフォルトスコープ)

維持

カンマ区切りにする必要があります。

Supported Grant Types (サポートされる付与種別)

維持

カンマ区切りにする必要があります。

Authorization Endpoint Path (認証エンドポイントパス)

変更、移動

Authorization Config (認証設定)​ の属性 ​path​ で設定できます。

Access Token Endpoint Path (アクセストークンエンドポイントパス)

変更、移動

Token Config (トークン設定)​ の属性 ​path​ で設定できます。

Authorization Ttl Seconds (認証 Ttl 秒)

削除

認証コード Ttl は、​Authorization Code Store (認証コードストア)​ オブジェクトストアで設定された entry Ttl (入力 Ttl) から取得されます。

Token Ttl Seconds (トークン Ttl 秒)

移動、変更

トークン Ttl は ​Token Store (トークンストア)​ オブジェクトストアから取得されます。コード上の制限により、この項目を ​TokenConfig​ の属性 ​tokenTtl​ と ​tokenTtlTimeUnit​ でも設定する必要があります。​Token Store (トークンストア)​ の ​entryTtl​ と ​Token Config (トークン設定)​ の ​tokenTtl​ (および ​tokenTtlTimeUnit​) は同じにする必要があります。

Refresh Token Ttl Seconds (更新トークン Ttl 秒)

削除

更新トークン Ttl は、​Refresh Token Strategy (更新トークン戦略)​ で設定されたオブジェクトストアの entry Ttl (入力 Ttl) から取得されます (ある場合)。

Connector (コネクタ)

削除

トランスポートが Mule 4 から削除されたので、この項目には意味がなくなりました。

HttpListenerConfig

変更

Listener Config (リスナー設定)​ と呼ばれるようになりました。必須です。

Resource Owner Security Provider Ref (リソースオーナーセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Client Security Provider Ref (クライアントセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Enable Refresh Token (更新トークンの有効化)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Issue New Refresh Token (更新トークンの新規発行)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Rate Limiter (レートリミッター)

変更

Spring bean からカスタム実装を追加する必要がなくなりました。Period Rate Limiter (期間レートリミッター) のみが実装されるようになりました。

Clients (クライアント)

維持

各クライアント定義が変更されました。

Pre Flow (プリフロー)

削除

プリフロー機能は、このバージョンではサポートされません。
## [](#ストア)ストア Authentication Code (認証コード)、Token (トークン)、または Refresh token (更新トークン) ストアはなくなりました。これらのカスタム実装を参照できる属性はありません。 ストレージ設定は、オブジェクトストアで行われるようになりました。 カスタム動作が必要な場合は、オブジェクトストアのカスタム実装を使用してそれらの属性を設定します。 ## [](#セキュリティプロバイダー)セキュリティプロバイダー Mule 4 では、アプリケーション設定を Spring から完全に分離したので、Spirng bean を参照して設定された一部の属性の設定方法が変更されました。 Spring セキュリティプロバイダーは引き続き使用できますが、その場合、アプリケーションが機能するには Spring Module が必要です。 ## [](#更新トークン属性)更新トークン属性 Mule 3 には、更新トークンの動作を設定できる 2 つの属性がありました。さまざまな更新トークン戦略が使用されるようになったので、次のように設定する必要があります。

Enable Refresh Token (更新トークンの有効化)

Issue New Refresh Token (更新トークンの新規発行)

Refresh Token Strategy (更新トークン戦略)

False

-

更新トークン戦略なし

True

False

1 つの更新トークン戦略

True

True

複数の更新トークン戦略
## [](#clients-クライアント)Clients (クライアント) どちらの Mule バージョンでも、認証サーバーに要求を実行できるクライアントのリストを定義する可能性があります。 クライアントを追加する方法は、一部の属性名以外は変わりありません。新しいバージョンの制限により、子要素の名前は、​_clients_​ および ​_client_​ プレフィックスを追加して変更する必要がありました。 - Redirect Uri(s) → Client Redirect Uris(s) - Authorized Grant Type(s) → Client Authorized Grant Type(s) - Scope(s) → Client Scope(s) ## [](#操作)操作 Mule 3 のモジュールで使用可能な操作と Mule 4 で行われた変更を以下に示します ### [](#validate-client)Validate Client この操作は Mule 4 から削除されました。 ### [](#validate)Validate この操作は、​**Validate Token**​ と呼ばれるようになりました。 Oauth2 プロバイダーの操作は HTTP にリンクされなくなったので、検証するトークンを解決する式が必要です。 Mule 3 では、トークン検証後、関連するリソースオーナー認証がある場合、そのリソースオーナー認証で新しいセキュリティコンテキストが作成されました。さらに、トークン情報を持つトークン保有者が _mule.oauth2.access\_token\_store\_holder_ というフロー変数に保存されました。 Mule 4 では、その同じ情報が若干異なる方法で保存されます。トークン検証後、​`#[authentication]`​ によってアクセス可能なトークン認証を使用してセキュリティコンテキストが作成されます。変数内のトークン所有者は、そのトークン認証の属性 ​`#[authentication.tokenHolder]`​ として保存されます。同時に、関連するリソースオーナーがある場合、その情報には ​`#[authentication.tokenHolder.resourceOwnerAuthentication]`​ を評価して到達できます。 ### [](#create-client)Create Client この操作は、​**Fail If Present (存在する場合は失敗)**​ という新しい属性が追加された以外は変わりありません。 **Fail If Present (存在する場合は失敗)**​ では、追加されるクライアントと同じ ID を持つクライアントが既存する場合にどうするかを指定できます。 - true の場合、操作は失敗します。 - false の場合、クライアント情報が更新されます。 ### [](#delete-client)Delete Client この操作は変わりありません。 ### [](#revoke-token)Revoke Token この操作は変わりありません。 ## [](#例)例 Mule 3 と Mule 4 で同じアプリケーションを設定した例を次に示します。 アプリケーションには、トークンを付与する Oauth2 プロバイダーと HTTP 要求をリスンするフローがあり、あるロジックを処理する前にトークン検証があります。 Mule 4 設定では Spring Module と Object Store Connector が使用されている点に留意してください。 どちらの場合も、アプリケーションは複数のファイルに分割されています。 Mule 3 の場合は、共通設定と実際の OAuth2 プロバイダー設定に 1 つずつ、2 つのファイルがあります。 Mule 4 の場合は、bean 定義、共通設定、実際の OAuth2 プロバイダー設定に 1 つずつ、3 つのファイルがあります。 ### [](#mule-3)Mule 3 #### [](#共通設定)共通設定 ```xml ``` #### [](#アプリケーション設定)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ### [](#mule-4)Mule 4 #### [](#bean-設定)Bean 設定 ```xml ``` #### [](#共通設定-2)共通設定 ```xml ``` #### [](#アプリケーション設定-2)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ## [](#関連情報)関連情報 - [OAuth2 プロバイダードキュメントリファレンス](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference) # OAuth2 プロバイダーの移行 Anypoint Enterprise Security の以前のプロバイダーは、Mule 4 の新しい OAuth2 Provider Module に置き換えられます。 ただし、アプリケーションを移行するときに考慮する必要がある設定変更がいくつかあります。 ## [](#グローバル設定の移行)グローバル設定の移行 プロバイダーのグローバル設定で行われた変更とバージョン間の違いを以下に示します。 ### [](#変更された属性)変更された属性 属性の状況は次のとおりです。 - 維持: 同じ名前、型、場所を使用します。 - 移動: 属性の名前と型は同じですが、設定を行う場所が変更されました。 - 変更: 型または名前が変更されましたが、場所は同じです。 - 削除: 属性は存在しません。
Mule 3 の属性 状況 Mule 4 の設定

Name (名前)

維持

Name (名前)

Provider Name (プロバイダー名)

維持

Provider Name (プロバイダー名)

Host (ホスト)

削除

ホストは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Port (ポート)

削除

ポートは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Client Store Ref (クライアントストア参照)

変更

属性はオブジェクトストアになりました。参照または非公開オブジェクトストアの定義である必要があります。

Authorization Code Store Ref (認証コードストア参照)

移動、変更

認証コードストアは、​Authorization Config (認証設定)​ の属性として設定し、オブジェクトストアである必要があります。

Token Generator Strategy (トークンジェネレーター戦略)

維持

Token Generator Strategy (トークンジェネレーター戦略)

Token Store Ref (トークンストア参照)

移動、変更

トークンストアは、​Token Config (トークン設定)​ の属性として設定し、オブジェクトストアである必要があります。

Login Page (ログインページ)

移動

ログインページは ​Authorization Config (認証設定)​ の属性として設定します。

スコープ

維持

カンマ区切りにする必要があります。

Default Scopes (デフォルトスコープ)

維持

カンマ区切りにする必要があります。

Supported Grant Types (サポートされる付与種別)

維持

カンマ区切りにする必要があります。

Authorization Endpoint Path (認証エンドポイントパス)

変更、移動

Authorization Config (認証設定)​ の属性 ​path​ で設定できます。

Access Token Endpoint Path (アクセストークンエンドポイントパス)

変更、移動

Token Config (トークン設定)​ の属性 ​path​ で設定できます。

Authorization Ttl Seconds (認証 Ttl 秒)

削除

認証コード Ttl は、​Authorization Code Store (認証コードストア)​ オブジェクトストアで設定された entry Ttl (入力 Ttl) から取得されます。

Token Ttl Seconds (トークン Ttl 秒)

移動、変更

トークン Ttl は ​Token Store (トークンストア)​ オブジェクトストアから取得されます。コード上の制限により、この項目を ​TokenConfig​ の属性 ​tokenTtl​ と ​tokenTtlTimeUnit​ でも設定する必要があります。​Token Store (トークンストア)​ の ​entryTtl​ と ​Token Config (トークン設定)​ の ​tokenTtl​ (および ​tokenTtlTimeUnit​) は同じにする必要があります。

Refresh Token Ttl Seconds (更新トークン Ttl 秒)

削除

更新トークン Ttl は、​Refresh Token Strategy (更新トークン戦略)​ で設定されたオブジェクトストアの entry Ttl (入力 Ttl) から取得されます (ある場合)。

Connector (コネクタ)

削除

トランスポートが Mule 4 から削除されたので、この項目には意味がなくなりました。

HttpListenerConfig

変更

Listener Config (リスナー設定)​ と呼ばれるようになりました。必須です。

Resource Owner Security Provider Ref (リソースオーナーセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Client Security Provider Ref (クライアントセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Enable Refresh Token (更新トークンの有効化)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Issue New Refresh Token (更新トークンの新規発行)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Rate Limiter (レートリミッター)

変更

Spring bean からカスタム実装を追加する必要がなくなりました。Period Rate Limiter (期間レートリミッター) のみが実装されるようになりました。

Clients (クライアント)

維持

各クライアント定義が変更されました。

Pre Flow (プリフロー)

削除

プリフロー機能は、このバージョンではサポートされません。
## [](#ストア)ストア Authentication Code (認証コード)、Token (トークン)、または Refresh token (更新トークン) ストアはなくなりました。これらのカスタム実装を参照できる属性はありません。 ストレージ設定は、オブジェクトストアで行われるようになりました。 カスタム動作が必要な場合は、オブジェクトストアのカスタム実装を使用してそれらの属性を設定します。 ## [](#セキュリティプロバイダー)セキュリティプロバイダー Mule 4 では、アプリケーション設定を Spring から完全に分離したので、Spirng bean を参照して設定された一部の属性の設定方法が変更されました。 Spring セキュリティプロバイダーは引き続き使用できますが、その場合、アプリケーションが機能するには Spring Module が必要です。 ## [](#更新トークン属性)更新トークン属性 Mule 3 には、更新トークンの動作を設定できる 2 つの属性がありました。さまざまな更新トークン戦略が使用されるようになったので、次のように設定する必要があります。

Enable Refresh Token (更新トークンの有効化)

Issue New Refresh Token (更新トークンの新規発行)

Refresh Token Strategy (更新トークン戦略)

False

-

更新トークン戦略なし

True

False

1 つの更新トークン戦略

True

True

複数の更新トークン戦略
## [](#clients-クライアント)Clients (クライアント) どちらの Mule バージョンでも、認証サーバーに要求を実行できるクライアントのリストを定義する可能性があります。 クライアントを追加する方法は、一部の属性名以外は変わりありません。新しいバージョンの制限により、子要素の名前は、​_clients_​ および ​_client_​ プレフィックスを追加して変更する必要がありました。 - Redirect Uri(s) → Client Redirect Uris(s) - Authorized Grant Type(s) → Client Authorized Grant Type(s) - Scope(s) → Client Scope(s) ## [](#操作)操作 Mule 3 のモジュールで使用可能な操作と Mule 4 で行われた変更を以下に示します ### [](#validate-client)Validate Client この操作は Mule 4 から削除されました。 ### [](#validate)Validate この操作は、​**Validate Token**​ と呼ばれるようになりました。 Oauth2 プロバイダーの操作は HTTP にリンクされなくなったので、検証するトークンを解決する式が必要です。 Mule 3 では、トークン検証後、関連するリソースオーナー認証がある場合、そのリソースオーナー認証で新しいセキュリティコンテキストが作成されました。さらに、トークン情報を持つトークン保有者が _mule.oauth2.access\_token\_store\_holder_ というフロー変数に保存されました。 Mule 4 では、その同じ情報が若干異なる方法で保存されます。トークン検証後、​`#[authentication]`​ によってアクセス可能なトークン認証を使用してセキュリティコンテキストが作成されます。変数内のトークン所有者は、そのトークン認証の属性 ​`#[authentication.tokenHolder]`​ として保存されます。同時に、関連するリソースオーナーがある場合、その情報には ​`#[authentication.tokenHolder.resourceOwnerAuthentication]`​ を評価して到達できます。 ### [](#create-client)Create Client この操作は、​**Fail If Present (存在する場合は失敗)**​ という新しい属性が追加された以外は変わりありません。 **Fail If Present (存在する場合は失敗)**​ では、追加されるクライアントと同じ ID を持つクライアントが既存する場合にどうするかを指定できます。 - true の場合、操作は失敗します。 - false の場合、クライアント情報が更新されます。 ### [](#delete-client)Delete Client この操作は変わりありません。 ### [](#revoke-token)Revoke Token この操作は変わりありません。 ## [](#例)例 Mule 3 と Mule 4 で同じアプリケーションを設定した例を次に示します。 アプリケーションには、トークンを付与する Oauth2 プロバイダーと HTTP 要求をリスンするフローがあり、あるロジックを処理する前にトークン検証があります。 Mule 4 設定では Spring Module と Object Store Connector が使用されている点に留意してください。 どちらの場合も、アプリケーションは複数のファイルに分割されています。 Mule 3 の場合は、共通設定と実際の OAuth2 プロバイダー設定に 1 つずつ、2 つのファイルがあります。 Mule 4 の場合は、bean 定義、共通設定、実際の OAuth2 プロバイダー設定に 1 つずつ、3 つのファイルがあります。 ### [](#mule-3)Mule 3 #### [](#共通設定)共通設定 ```xml ``` #### [](#アプリケーション設定)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ### [](#mule-4)Mule 4 #### [](#bean-設定)Bean 設定 ```xml ``` #### [](#共通設定-2)共通設定 ```xml ``` #### [](#アプリケーション設定-2)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ## [](#関連情報)関連情報 - [OAuth2 プロバイダードキュメントリファレンス](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference) # OAuth2 プロバイダーの移行 Anypoint Enterprise Security の以前のプロバイダーは、Mule 4 の新しい OAuth2 Provider Module に置き換えられます。 ただし、アプリケーションを移行するときに考慮する必要がある設定変更がいくつかあります。 ## [](#グローバル設定の移行)グローバル設定の移行 プロバイダーのグローバル設定で行われた変更とバージョン間の違いを以下に示します。 ### [](#変更された属性)変更された属性 属性の状況は次のとおりです。 - 維持: 同じ名前、型、場所を使用します。 - 移動: 属性の名前と型は同じですが、設定を行う場所が変更されました。 - 変更: 型または名前が変更されましたが、場所は同じです。 - 削除: 属性は存在しません。
Mule 3 の属性 状況 Mule 4 の設定

Name (名前)

維持

Name (名前)

Provider Name (プロバイダー名)

維持

Provider Name (プロバイダー名)

Host (ホスト)

削除

ホストは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Port (ポート)

削除

ポートは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Client Store Ref (クライアントストア参照)

変更

属性はオブジェクトストアになりました。参照または非公開オブジェクトストアの定義である必要があります。

Authorization Code Store Ref (認証コードストア参照)

移動、変更

認証コードストアは、​Authorization Config (認証設定)​ の属性として設定し、オブジェクトストアである必要があります。

Token Generator Strategy (トークンジェネレーター戦略)

維持

Token Generator Strategy (トークンジェネレーター戦略)

Token Store Ref (トークンストア参照)

移動、変更

トークンストアは、​Token Config (トークン設定)​ の属性として設定し、オブジェクトストアである必要があります。

Login Page (ログインページ)

移動

ログインページは ​Authorization Config (認証設定)​ の属性として設定します。

スコープ

維持

カンマ区切りにする必要があります。

Default Scopes (デフォルトスコープ)

維持

カンマ区切りにする必要があります。

Supported Grant Types (サポートされる付与種別)

維持

カンマ区切りにする必要があります。

Authorization Endpoint Path (認証エンドポイントパス)

変更、移動

Authorization Config (認証設定)​ の属性 ​path​ で設定できます。

Access Token Endpoint Path (アクセストークンエンドポイントパス)

変更、移動

Token Config (トークン設定)​ の属性 ​path​ で設定できます。

Authorization Ttl Seconds (認証 Ttl 秒)

削除

認証コード Ttl は、​Authorization Code Store (認証コードストア)​ オブジェクトストアで設定された entry Ttl (入力 Ttl) から取得されます。

Token Ttl Seconds (トークン Ttl 秒)

移動、変更

トークン Ttl は ​Token Store (トークンストア)​ オブジェクトストアから取得されます。コード上の制限により、この項目を ​TokenConfig​ の属性 ​tokenTtl​ と ​tokenTtlTimeUnit​ でも設定する必要があります。​Token Store (トークンストア)​ の ​entryTtl​ と ​Token Config (トークン設定)​ の ​tokenTtl​ (および ​tokenTtlTimeUnit​) は同じにする必要があります。

Refresh Token Ttl Seconds (更新トークン Ttl 秒)

削除

更新トークン Ttl は、​Refresh Token Strategy (更新トークン戦略)​ で設定されたオブジェクトストアの entry Ttl (入力 Ttl) から取得されます (ある場合)。

Connector (コネクタ)

削除

トランスポートが Mule 4 から削除されたので、この項目には意味がなくなりました。

HttpListenerConfig

変更

Listener Config (リスナー設定)​ と呼ばれるようになりました。必須です。

Resource Owner Security Provider Ref (リソースオーナーセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Client Security Provider Ref (クライアントセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Enable Refresh Token (更新トークンの有効化)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Issue New Refresh Token (更新トークンの新規発行)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Rate Limiter (レートリミッター)

変更

Spring bean からカスタム実装を追加する必要がなくなりました。Period Rate Limiter (期間レートリミッター) のみが実装されるようになりました。

Clients (クライアント)

維持

各クライアント定義が変更されました。

Pre Flow (プリフロー)

削除

プリフロー機能は、このバージョンではサポートされません。
## [](#ストア)ストア Authentication Code (認証コード)、Token (トークン)、または Refresh token (更新トークン) ストアはなくなりました。これらのカスタム実装を参照できる属性はありません。 ストレージ設定は、オブジェクトストアで行われるようになりました。 カスタム動作が必要な場合は、オブジェクトストアのカスタム実装を使用してそれらの属性を設定します。 ## [](#セキュリティプロバイダー)セキュリティプロバイダー Mule 4 では、アプリケーション設定を Spring から完全に分離したので、Spirng bean を参照して設定された一部の属性の設定方法が変更されました。 Spring セキュリティプロバイダーは引き続き使用できますが、その場合、アプリケーションが機能するには Spring Module が必要です。 ## [](#更新トークン属性)更新トークン属性 Mule 3 には、更新トークンの動作を設定できる 2 つの属性がありました。さまざまな更新トークン戦略が使用されるようになったので、次のように設定する必要があります。

Enable Refresh Token (更新トークンの有効化)

Issue New Refresh Token (更新トークンの新規発行)

Refresh Token Strategy (更新トークン戦略)

False

-

更新トークン戦略なし

True

False

1 つの更新トークン戦略

True

True

複数の更新トークン戦略
## [](#clients-クライアント)Clients (クライアント) どちらの Mule バージョンでも、認証サーバーに要求を実行できるクライアントのリストを定義する可能性があります。 クライアントを追加する方法は、一部の属性名以外は変わりありません。新しいバージョンの制限により、子要素の名前は、​_clients_​ および ​_client_​ プレフィックスを追加して変更する必要がありました。 - Redirect Uri(s) → Client Redirect Uris(s) - Authorized Grant Type(s) → Client Authorized Grant Type(s) - Scope(s) → Client Scope(s) ## [](#操作)操作 Mule 3 のモジュールで使用可能な操作と Mule 4 で行われた変更を以下に示します ### [](#validate-client)Validate Client この操作は Mule 4 から削除されました。 ### [](#validate)Validate この操作は、​**Validate Token**​ と呼ばれるようになりました。 Oauth2 プロバイダーの操作は HTTP にリンクされなくなったので、検証するトークンを解決する式が必要です。 Mule 3 では、トークン検証後、関連するリソースオーナー認証がある場合、そのリソースオーナー認証で新しいセキュリティコンテキストが作成されました。さらに、トークン情報を持つトークン保有者が _mule.oauth2.access\_token\_store\_holder_ というフロー変数に保存されました。 Mule 4 では、その同じ情報が若干異なる方法で保存されます。トークン検証後、​`#[authentication]`​ によってアクセス可能なトークン認証を使用してセキュリティコンテキストが作成されます。変数内のトークン所有者は、そのトークン認証の属性 ​`#[authentication.tokenHolder]`​ として保存されます。同時に、関連するリソースオーナーがある場合、その情報には ​`#[authentication.tokenHolder.resourceOwnerAuthentication]`​ を評価して到達できます。 ### [](#create-client)Create Client この操作は、​**Fail If Present (存在する場合は失敗)**​ という新しい属性が追加された以外は変わりありません。 **Fail If Present (存在する場合は失敗)**​ では、追加されるクライアントと同じ ID を持つクライアントが既存する場合にどうするかを指定できます。 - true の場合、操作は失敗します。 - false の場合、クライアント情報が更新されます。 ### [](#delete-client)Delete Client この操作は変わりありません。 ### [](#revoke-token)Revoke Token この操作は変わりありません。 ## [](#例)例 Mule 3 と Mule 4 で同じアプリケーションを設定した例を次に示します。 アプリケーションには、トークンを付与する Oauth2 プロバイダーと HTTP 要求をリスンするフローがあり、あるロジックを処理する前にトークン検証があります。 Mule 4 設定では Spring Module と Object Store Connector が使用されている点に留意してください。 どちらの場合も、アプリケーションは複数のファイルに分割されています。 Mule 3 の場合は、共通設定と実際の OAuth2 プロバイダー設定に 1 つずつ、2 つのファイルがあります。 Mule 4 の場合は、bean 定義、共通設定、実際の OAuth2 プロバイダー設定に 1 つずつ、3 つのファイルがあります。 ### [](#mule-3)Mule 3 #### [](#共通設定)共通設定 ```xml ``` #### [](#アプリケーション設定)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ### [](#mule-4)Mule 4 #### [](#bean-設定)Bean 設定 ```xml ``` #### [](#共通設定-2)共通設定 ```xml ``` #### [](#アプリケーション設定-2)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ## [](#関連情報)関連情報 - [OAuth2 プロバイダードキュメントリファレンス](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference) # OAuth2 プロバイダーの移行 Anypoint Enterprise Security の以前のプロバイダーは、Mule 4 の新しい OAuth2 Provider Module に置き換えられます。 ただし、アプリケーションを移行するときに考慮する必要がある設定変更がいくつかあります。 ## [](#グローバル設定の移行)グローバル設定の移行 プロバイダーのグローバル設定で行われた変更とバージョン間の違いを以下に示します。 ### [](#変更された属性)変更された属性 属性の状況は次のとおりです。 - 維持: 同じ名前、型、場所を使用します。 - 移動: 属性の名前と型は同じですが、設定を行う場所が変更されました。 - 変更: 型または名前が変更されましたが、場所は同じです。 - 削除: 属性は存在しません。
Mule 3 の属性 状況 Mule 4 の設定

Name (名前)

維持

Name (名前)

Provider Name (プロバイダー名)

維持

Provider Name (プロバイダー名)

Host (ホスト)

削除

ホストは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Port (ポート)

削除

ポートは ​Listener Config (リスナー設定)​ の Http Configuration (Http 設定) から取得されます。

Client Store Ref (クライアントストア参照)

変更

属性はオブジェクトストアになりました。参照または非公開オブジェクトストアの定義である必要があります。

Authorization Code Store Ref (認証コードストア参照)

移動、変更

認証コードストアは、​Authorization Config (認証設定)​ の属性として設定し、オブジェクトストアである必要があります。

Token Generator Strategy (トークンジェネレーター戦略)

維持

Token Generator Strategy (トークンジェネレーター戦略)

Token Store Ref (トークンストア参照)

移動、変更

トークンストアは、​Token Config (トークン設定)​ の属性として設定し、オブジェクトストアである必要があります。

Login Page (ログインページ)

移動

ログインページは ​Authorization Config (認証設定)​ の属性として設定します。

スコープ

維持

カンマ区切りにする必要があります。

Default Scopes (デフォルトスコープ)

維持

カンマ区切りにする必要があります。

Supported Grant Types (サポートされる付与種別)

維持

カンマ区切りにする必要があります。

Authorization Endpoint Path (認証エンドポイントパス)

変更、移動

Authorization Config (認証設定)​ の属性 ​path​ で設定できます。

Access Token Endpoint Path (アクセストークンエンドポイントパス)

変更、移動

Token Config (トークン設定)​ の属性 ​path​ で設定できます。

Authorization Ttl Seconds (認証 Ttl 秒)

削除

認証コード Ttl は、​Authorization Code Store (認証コードストア)​ オブジェクトストアで設定された entry Ttl (入力 Ttl) から取得されます。

Token Ttl Seconds (トークン Ttl 秒)

移動、変更

トークン Ttl は ​Token Store (トークンストア)​ オブジェクトストアから取得されます。コード上の制限により、この項目を ​TokenConfig​ の属性 ​tokenTtl​ と ​tokenTtlTimeUnit​ でも設定する必要があります。​Token Store (トークンストア)​ の ​entryTtl​ と ​Token Config (トークン設定)​ の ​tokenTtl​ (および ​tokenTtlTimeUnit​) は同じにする必要があります。

Refresh Token Ttl Seconds (更新トークン Ttl 秒)

削除

更新トークン Ttl は、​Refresh Token Strategy (更新トークン戦略)​ で設定されたオブジェクトストアの entry Ttl (入力 Ttl) から取得されます (ある場合)。

Connector (コネクタ)

削除

トランスポートが Mule 4 から削除されたので、この項目には意味がなくなりました。

HttpListenerConfig

変更

Listener Config (リスナー設定)​ と呼ばれるようになりました。必須です。

Resource Owner Security Provider Ref (リソースオーナーセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Client Security Provider Ref (クライアントセキュリティプロバイダー参照)

変更

Ref​ が属性の名前から削除されました。Spring Security Provider (Spring セキュリティプロバイダー) が設定されている場合は、Spring Module を使用します。

Enable Refresh Token (更新トークンの有効化)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Issue New Refresh Token (更新トークンの新規発行)

削除

別の ​Refresh Token Strategy (更新トークン戦略)​ に設定できます。

Rate Limiter (レートリミッター)

変更

Spring bean からカスタム実装を追加する必要がなくなりました。Period Rate Limiter (期間レートリミッター) のみが実装されるようになりました。

Clients (クライアント)

維持

各クライアント定義が変更されました。

Pre Flow (プリフロー)

削除

プリフロー機能は、このバージョンではサポートされません。
## [](#ストア)ストア Authentication Code (認証コード)、Token (トークン)、または Refresh token (更新トークン) ストアはなくなりました。これらのカスタム実装を参照できる属性はありません。 ストレージ設定は、オブジェクトストアで行われるようになりました。 カスタム動作が必要な場合は、オブジェクトストアのカスタム実装を使用してそれらの属性を設定します。 ## [](#セキュリティプロバイダー)セキュリティプロバイダー Mule 4 では、アプリケーション設定を Spring から完全に分離したので、Spirng bean を参照して設定された一部の属性の設定方法が変更されました。 Spring セキュリティプロバイダーは引き続き使用できますが、その場合、アプリケーションが機能するには Spring Module が必要です。 ## [](#更新トークン属性)更新トークン属性 Mule 3 には、更新トークンの動作を設定できる 2 つの属性がありました。さまざまな更新トークン戦略が使用されるようになったので、次のように設定する必要があります。

Enable Refresh Token (更新トークンの有効化)

Issue New Refresh Token (更新トークンの新規発行)

Refresh Token Strategy (更新トークン戦略)

False

-

更新トークン戦略なし

True

False

1 つの更新トークン戦略

True

True

複数の更新トークン戦略
## [](#clients-クライアント)Clients (クライアント) どちらの Mule バージョンでも、認証サーバーに要求を実行できるクライアントのリストを定義する可能性があります。 クライアントを追加する方法は、一部の属性名以外は変わりありません。新しいバージョンの制限により、子要素の名前は、​_clients_​ および ​_client_​ プレフィックスを追加して変更する必要がありました。 - Redirect Uri(s) → Client Redirect Uris(s) - Authorized Grant Type(s) → Client Authorized Grant Type(s) - Scope(s) → Client Scope(s) ## [](#操作)操作 Mule 3 のモジュールで使用可能な操作と Mule 4 で行われた変更を以下に示します ### [](#validate-client)Validate Client この操作は Mule 4 から削除されました。 ### [](#validate)Validate この操作は、​**Validate Token**​ と呼ばれるようになりました。 Oauth2 プロバイダーの操作は HTTP にリンクされなくなったので、検証するトークンを解決する式が必要です。 Mule 3 では、トークン検証後、関連するリソースオーナー認証がある場合、そのリソースオーナー認証で新しいセキュリティコンテキストが作成されました。さらに、トークン情報を持つトークン保有者が _mule.oauth2.access\_token\_store\_holder_ というフロー変数に保存されました。 Mule 4 では、その同じ情報が若干異なる方法で保存されます。トークン検証後、​`#[authentication]`​ によってアクセス可能なトークン認証を使用してセキュリティコンテキストが作成されます。変数内のトークン所有者は、そのトークン認証の属性 ​`#[authentication.tokenHolder]`​ として保存されます。同時に、関連するリソースオーナーがある場合、その情報には ​`#[authentication.tokenHolder.resourceOwnerAuthentication]`​ を評価して到達できます。 ### [](#create-client)Create Client この操作は、​**Fail If Present (存在する場合は失敗)**​ という新しい属性が追加された以外は変わりありません。 **Fail If Present (存在する場合は失敗)**​ では、追加されるクライアントと同じ ID を持つクライアントが既存する場合にどうするかを指定できます。 - true の場合、操作は失敗します。 - false の場合、クライアント情報が更新されます。 ### [](#delete-client)Delete Client この操作は変わりありません。 ### [](#revoke-token)Revoke Token この操作は変わりありません。 ## [](#例)例 Mule 3 と Mule 4 で同じアプリケーションを設定した例を次に示します。 アプリケーションには、トークンを付与する Oauth2 プロバイダーと HTTP 要求をリスンするフローがあり、あるロジックを処理する前にトークン検証があります。 Mule 4 設定では Spring Module と Object Store Connector が使用されている点に留意してください。 どちらの場合も、アプリケーションは複数のファイルに分割されています。 Mule 3 の場合は、共通設定と実際の OAuth2 プロバイダー設定に 1 つずつ、2 つのファイルがあります。 Mule 4 の場合は、bean 定義、共通設定、実際の OAuth2 プロバイダー設定に 1 つずつ、3 つのファイルがあります。 ### [](#mule-3)Mule 3 #### [](#共通設定)共通設定 ```xml ``` #### [](#アプリケーション設定)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ### [](#mule-4)Mule 4 #### [](#bean-設定)Bean 設定 ```xml ``` #### [](#共通設定-2)共通設定 ```xml ``` #### [](#アプリケーション設定-2)アプリケーション設定 ```xml http://fake/redirect AUTHORIZATION_CODE ``` ## [](#関連情報)関連情報 - [OAuth2 プロバイダードキュメントリファレンス](https://docs.mulesoft.com/jp/oauth2-provider-module/latest/oauth2-provider-module-reference) # Object Store Connector の移行 Mule 4 の Object Store Connector は、Mule 3 の Object Store Connector と非常に似ています。これらのメジャーバージョンの主な違いは次のとおりです。 - カスタムオブジェクトストアの作成方法。Mule 4 でのカスタムオブジェクトストアの作成では、Spring の使用や、特定の Java クラスの存在を知っている必要がありません。 - キーは必ず文字列であること。以前の Object Store Connector では ​`Serializable`​ をキーとして使用できました。 Mule 4 では、すべてのキーは ​`String`​ 型である必要があります。 ## [](#このセクションの内容)このセクションの内容 - [名前空間の変更](#namespace) - [最上位レベルオブジェクトの使用](#configs-object-stores) - [カスタムオブジェクトストアの作成](#custom-object-store) - [キーの変更](#change-on-keys) - [値の保存](#storing-values) - [Persistent (永続) 属性のデフォルト値](#persistent-default-value) - [オブジェクトストアのクリーンアップ](#dispose-clear) - [Dual Store 操作の削除](#dual-store) - [Remove 操作の動作](#remove-behavior) ## [](#namespace)名前空間の変更 Mule 3 の Object Store Connector で使用されていた名前空間は ​`objectstore`​ でした。Mule 4 の新しいコネクタでは、この名前空間が ​`os`​ に変更されました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#configs-object-stores)最上位レベルオブジェクトの使用 前述の例では、​`config-ref`​ パラメーターが削除され、代わりに ​`objectStore`​ パラメーターが使用されていました。これは、Mule 3 ではほとんどのコネクタ操作に​_コネクタ設定の参照_​が必要であるのに対し、Mule 4 のほとんどの操作では代わりに ​_Object Store の最上位レベルの要素_​の参照を受け取るからです。 ## [](#custom-object-store)カスタムオブジェクトストアの作成 カスタムオブジェクトストアは、操作で使用するために名前で参照できる OS のグローバル定義で、オブジェクトストアの動作をニーズに応じて調整し、設定することができます。 Mule 3 では、新しい ObjectStore を作成するには、Spring bean を作成し、ObjectStore に使用する特定の Java クラスを知っている必要がありました。Mule 4 では、これがかなり容易になり、​`os:object-store`​ コンポーネントを使用して ObjectStore を宣言するグローバル要素を作成するだけですみます。 次の例は、永続的なカスタムオブジェクトストアを使用して HTTP エンドポイント経由で ​`store`​ と ​`retrieve`​ が公開される簡単なケースを、Mule 3 で行われていた方法と Mule 4 で行う方法を示しています。 Mule 3 の例 ```xml (1) (2) (4) 1Spring bean と Java クラスへの参照を使用してカスタムオブジェクトストアを作成します。2設定でカスタムオブジェクトストアを参照します。3store 操作を使用する前に DataWeave 変換を使用して、ペイロードに何が保存されるのかを設定します。4ペイロードはオブジェクトストアに保存されます。 Mule 4 で同じアプリケーションを実装すると次のようになります。 Mule 4 の例 ```xml (1) (2) #[{ id: attributes.queryParams.id, book: attributes.queryParams.book, author: attributes.queryParams.author }] ``` 主な違いは次のとおりです。
1新しいオブジェクトは Spring bean と Java クラスを知らずに作成されます。ここで定義されているのは、設定ではなく、オブジェクトストアの最上位レベルの要素です。
2変数またはペイロードに値を保存する必要がなく、インライン記述でオブジェクトストアに何が保存されるのかが定義されます。
Mule 3 では、オブジェクトストアのパーティションを指定する必要がありました。Mule 4 では、パーティションを指定する必要がなくなり、代わりに別のオブジェクトストアを使用します。 また、エントリの存続時間と、エントリの有効期限またはエントリ最大数を超えたどうかをチェックする頻度の両方に、時間単位を指定することができます。 ## [](#change-on-keys)キーの変更 Mule 3 では、オブジェクトストアの値を参照するために使用するキーに任意の ​`Serializable`​ を使用できました。Mule 4 では、この目的に使用できるのは ​`String`​ オブジェクトのみです。 `String`​ ではなく ​`Serializable`​ をキーとして使用している場合は、​`String`​ 値に変換してください。 ## [](#storing-values)値の保存 Mule 4 では、値のパラメーターがコンテンツのパラメーターとして取得されるようになりました。つまり、インラインで定義する必要があります。これは、Mule 3 では属性として設定されていました。 また、オブジェクトストアの値を更新する方法が若干変更されました。Mule 3 には、デフォルトで false になる ​`overwrite`​ というフラグがありました。Mule 4 には、デフォルトで false になる ​`failIfPresent`​ というフラグがあります。つまり、すでに使用されているキーを指定した store 操作を使用する場合、デフォルトの動作はその値の上書きです。
Mule 4 では、キーがすでに存在し、フラグ ​failIfPresent​ が true に設定されると、OS:KEY_ALREADY_EXISTS エラーがスローされます。
移行するときには、デフォルトの動作が異なるため、フラグがどのように設定されているかに注意してください。 Mule 3 の例 ```xml (1) ```
1Mule 3 では DataWeave 式をインラインで挿入できないので、コンテンツを変数に保存するか、ペイロードを変更するかのいずれかになります。この例では、クライアント変数に割り当てられました。
Mule 4 の例 ```xml #[{ (1) id: payload.id, name: payload.name, lname: payload.lname, age: payload.age }] ```
1Mule 4 では、保存するコンテンツをインラインで挿入できます。この操作の後、ペイロードは変更されないままです。
## [](#persistent-default-value)Persistent (永続) 属性のデフォルト値 Mule 4 のオブジェクトストアはデフォルトで永続的なのに対し、Mule 3 Connector ではデフォルトでオンメモリに保存されます。このため、実装を移行するときには注意が必要です。オブジェクトストアの永続性を明示的に指定しないと、違うことを意味するようになります。 この例は、移行後に persistent (永続) 属性をどのように明示的に追加する必要があるかを示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#dispose-clear)オブジェクトストアのクリーンアップ オブジェクトストアの特定のパーティションをクリアするには、Mule 3 では dispose 操作が使用されていました。 Mule 4 には、オブジェクトストア全体をクリアする clear 操作があります。パーティションという概念は使用されなくなりした。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ```
Mule 4 の clear 操作は、オブジェクトストア全体をクリアします。
## [](#dual-store)Dual Store 操作の削除 Mule 3 の Object Store Connector には、キーを使用して値を保存し、また値を保存して同じキーを保存する ​`dual-store`​ 操作がありました。Mule 4 ではキーは ​`String`​ に限定されるため、この操作は意味がないので削除されました。 ## [](#remove-behavior)Remove 操作の動作 Mule 3 の ​`remove`​ 操作には、デフォルトで false に設定される ​`ignoreNotExists`​ というフラグがありました。これは、削除されるキーが存在しなかった場合に操作が失敗するかどうかを示します。Mule 4 では、キーが存在しない場合、​`OS:KEY_NOT_FOUND`​ エラーがスローされ、エラー処理で必要に応じて処理することができます。 # Object Store Connector の移行 Mule 4 の Object Store Connector は、Mule 3 の Object Store Connector と非常に似ています。これらのメジャーバージョンの主な違いは次のとおりです。 - カスタムオブジェクトストアの作成方法。Mule 4 でのカスタムオブジェクトストアの作成では、Spring の使用や、特定の Java クラスの存在を知っている必要がありません。 - キーは必ず文字列であること。以前の Object Store Connector では ​`Serializable`​ をキーとして使用できました。 Mule 4 では、すべてのキーは ​`String`​ 型である必要があります。 ## [](#このセクションの内容)このセクションの内容 - [名前空間の変更](#namespace) - [最上位レベルオブジェクトの使用](#configs-object-stores) - [カスタムオブジェクトストアの作成](#custom-object-store) - [キーの変更](#change-on-keys) - [値の保存](#storing-values) - [Persistent (永続) 属性のデフォルト値](#persistent-default-value) - [オブジェクトストアのクリーンアップ](#dispose-clear) - [Dual Store 操作の削除](#dual-store) - [Remove 操作の動作](#remove-behavior) ## [](#namespace)名前空間の変更 Mule 3 の Object Store Connector で使用されていた名前空間は ​`objectstore`​ でした。Mule 4 の新しいコネクタでは、この名前空間が ​`os`​ に変更されました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#configs-object-stores)最上位レベルオブジェクトの使用 前述の例では、​`config-ref`​ パラメーターが削除され、代わりに ​`objectStore`​ パラメーターが使用されていました。これは、Mule 3 ではほとんどのコネクタ操作に​_コネクタ設定の参照_​が必要であるのに対し、Mule 4 のほとんどの操作では代わりに ​_Object Store の最上位レベルの要素_​の参照を受け取るからです。 ## [](#custom-object-store)カスタムオブジェクトストアの作成 カスタムオブジェクトストアは、操作で使用するために名前で参照できる OS のグローバル定義で、オブジェクトストアの動作をニーズに応じて調整し、設定することができます。 Mule 3 では、新しい ObjectStore を作成するには、Spring bean を作成し、ObjectStore に使用する特定の Java クラスを知っている必要がありました。Mule 4 では、これがかなり容易になり、​`os:object-store`​ コンポーネントを使用して ObjectStore を宣言するグローバル要素を作成するだけですみます。 次の例は、永続的なカスタムオブジェクトストアを使用して HTTP エンドポイント経由で ​`store`​ と ​`retrieve`​ が公開される簡単なケースを、Mule 3 で行われていた方法と Mule 4 で行う方法を示しています。 Mule 3 の例 ```xml (1) (2) (4) ``` このスニペットでは、次の点に注目します。
1Spring bean と Java クラスへの参照を使用してカスタムオブジェクトストアを作成します。
2設定でカスタムオブジェクトストアを参照します。
3store 操作を使用する前に DataWeave 変換を使用して、ペイロードに何が保存されるのかを設定します。
4ペイロードはオブジェクトストアに保存されます。
Mule 4 で同じアプリケーションを実装すると次のようになります。 Mule 4 の例 ```xml (1) (2) #[{ id: attributes.queryParams.id, book: attributes.queryParams.book, author: attributes.queryParams.author }] ``` 主な違いは次のとおりです。
1新しいオブジェクトは Spring bean と Java クラスを知らずに作成されます。ここで定義されているのは、設定ではなく、オブジェクトストアの最上位レベルの要素です。
2変数またはペイロードに値を保存する必要がなく、インライン記述でオブジェクトストアに何が保存されるのかが定義されます。
Mule 3 では、オブジェクトストアのパーティションを指定する必要がありました。Mule 4 では、パーティションを指定する必要がなくなり、代わりに別のオブジェクトストアを使用します。 また、エントリの存続時間と、エントリの有効期限またはエントリ最大数を超えたどうかをチェックする頻度の両方に、時間単位を指定することができます。 ## [](#change-on-keys)キーの変更 Mule 3 では、オブジェクトストアの値を参照するために使用するキーに任意の ​`Serializable`​ を使用できました。Mule 4 では、この目的に使用できるのは ​`String`​ オブジェクトのみです。 `String`​ ではなく ​`Serializable`​ をキーとして使用している場合は、​`String`​ 値に変換してください。 ## [](#storing-values)値の保存 Mule 4 では、値のパラメーターがコンテンツのパラメーターとして取得されるようになりました。つまり、インラインで定義する必要があります。これは、Mule 3 では属性として設定されていました。 また、オブジェクトストアの値を更新する方法が若干変更されました。Mule 3 には、デフォルトで false になる ​`overwrite`​ というフラグがありました。Mule 4 には、デフォルトで false になる ​`failIfPresent`​ というフラグがあります。つまり、すでに使用されているキーを指定した store 操作を使用する場合、デフォルトの動作はその値の上書きです。
Mule 4 では、キーがすでに存在し、フラグ ​failIfPresent​ が true に設定されると、OS:KEY_ALREADY_EXISTS エラーがスローされます。
移行するときには、デフォルトの動作が異なるため、フラグがどのように設定されているかに注意してください。 Mule 3 の例 ```xml (1) ```
1Mule 3 では DataWeave 式をインラインで挿入できないので、コンテンツを変数に保存するか、ペイロードを変更するかのいずれかになります。この例では、クライアント変数に割り当てられました。
Mule 4 の例 ```xml #[{ (1) id: payload.id, name: payload.name, lname: payload.lname, age: payload.age }] ```
1Mule 4 では、保存するコンテンツをインラインで挿入できます。この操作の後、ペイロードは変更されないままです。
## [](#persistent-default-value)Persistent (永続) 属性のデフォルト値 Mule 4 のオブジェクトストアはデフォルトで永続的なのに対し、Mule 3 Connector ではデフォルトでオンメモリに保存されます。このため、実装を移行するときには注意が必要です。オブジェクトストアの永続性を明示的に指定しないと、違うことを意味するようになります。 この例は、移行後に persistent (永続) 属性をどのように明示的に追加する必要があるかを示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#dispose-clear)オブジェクトストアのクリーンアップ オブジェクトストアの特定のパーティションをクリアするには、Mule 3 では dispose 操作が使用されていました。 Mule 4 には、オブジェクトストア全体をクリアする clear 操作があります。パーティションという概念は使用されなくなりした。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ```
Mule 4 の clear 操作は、オブジェクトストア全体をクリアします。
## [](#dual-store)Dual Store 操作の削除 Mule 3 の Object Store Connector には、キーを使用して値を保存し、また値を保存して同じキーを保存する ​`dual-store`​ 操作がありました。Mule 4 ではキーは ​`String`​ に限定されるため、この操作は意味がないので削除されました。 ## [](#remove-behavior)Remove 操作の動作 Mule 3 の ​`remove`​ 操作には、デフォルトで false に設定される ​`ignoreNotExists`​ というフラグがありました。これは、削除されるキーが存在しなかった場合に操作が失敗するかどうかを示します。Mule 4 では、キーが存在しない場合、​`OS:KEY_NOT_FOUND`​ エラーがスローされ、エラー処理で必要に応じて処理することができます。 # Object Store Connector の移行 Mule 4 の Object Store Connector は、Mule 3 の Object Store Connector と非常に似ています。これらのメジャーバージョンの主な違いは次のとおりです。 - カスタムオブジェクトストアの作成方法。Mule 4 でのカスタムオブジェクトストアの作成では、Spring の使用や、特定の Java クラスの存在を知っている必要がありません。 - キーは必ず文字列であること。以前の Object Store Connector では ​`Serializable`​ をキーとして使用できました。 Mule 4 では、すべてのキーは ​`String`​ 型である必要があります。 ## [](#このセクションの内容)このセクションの内容 - [名前空間の変更](#namespace) - [最上位レベルオブジェクトの使用](#configs-object-stores) - [カスタムオブジェクトストアの作成](#custom-object-store) - [キーの変更](#change-on-keys) - [値の保存](#storing-values) - [Persistent (永続) 属性のデフォルト値](#persistent-default-value) - [オブジェクトストアのクリーンアップ](#dispose-clear) - [Dual Store 操作の削除](#dual-store) - [Remove 操作の動作](#remove-behavior) ## [](#namespace)名前空間の変更 Mule 3 の Object Store Connector で使用されていた名前空間は ​`objectstore`​ でした。Mule 4 の新しいコネクタでは、この名前空間が ​`os`​ に変更されました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#configs-object-stores)最上位レベルオブジェクトの使用 前述の例では、​`config-ref`​ パラメーターが削除され、代わりに ​`objectStore`​ パラメーターが使用されていました。これは、Mule 3 ではほとんどのコネクタ操作に​_コネクタ設定の参照_​が必要であるのに対し、Mule 4 のほとんどの操作では代わりに ​_Object Store の最上位レベルの要素_​の参照を受け取るからです。 ## [](#custom-object-store)カスタムオブジェクトストアの作成 カスタムオブジェクトストアは、操作で使用するために名前で参照できる OS のグローバル定義で、オブジェクトストアの動作をニーズに応じて調整し、設定することができます。 Mule 3 では、新しい ObjectStore を作成するには、Spring bean を作成し、ObjectStore に使用する特定の Java クラスを知っている必要がありました。Mule 4 では、これがかなり容易になり、​`os:object-store`​ コンポーネントを使用して ObjectStore を宣言するグローバル要素を作成するだけですみます。 次の例は、永続的なカスタムオブジェクトストアを使用して HTTP エンドポイント経由で ​`store`​ と ​`retrieve`​ が公開される簡単なケースを、Mule 3 で行われていた方法と Mule 4 で行う方法を示しています。 Mule 3 の例 ```xml (1) (2) (4) ``` このスニペットでは、次の点に注目します。
1Spring bean と Java クラスへの参照を使用してカスタムオブジェクトストアを作成します。
2設定でカスタムオブジェクトストアを参照します。
3store 操作を使用する前に DataWeave 変換を使用して、ペイロードに何が保存されるのかを設定します。
4ペイロードはオブジェクトストアに保存されます。
Mule 4 で同じアプリケーションを実装すると次のようになります。 Mule 4 の例 ```xml (1) (2) #[{ id: attributes.queryParams.id, book: attributes.queryParams.book, author: attributes.queryParams.author }] ``` 主な違いは次のとおりです。
1新しいオブジェクトは Spring bean と Java クラスを知らずに作成されます。ここで定義されているのは、設定ではなく、オブジェクトストアの最上位レベルの要素です。
2変数またはペイロードに値を保存する必要がなく、インライン記述でオブジェクトストアに何が保存されるのかが定義されます。
Mule 3 では、オブジェクトストアのパーティションを指定する必要がありました。Mule 4 では、パーティションを指定する必要がなくなり、代わりに別のオブジェクトストアを使用します。 また、エントリの存続時間と、エントリの有効期限またはエントリ最大数を超えたどうかをチェックする頻度の両方に、時間単位を指定することができます。 ## [](#change-on-keys)キーの変更 Mule 3 では、オブジェクトストアの値を参照するために使用するキーに任意の ​`Serializable`​ を使用できました。Mule 4 では、この目的に使用できるのは ​`String`​ オブジェクトのみです。 `String`​ ではなく ​`Serializable`​ をキーとして使用している場合は、​`String`​ 値に変換してください。 ## [](#storing-values)値の保存 Mule 4 では、値のパラメーターがコンテンツのパラメーターとして取得されるようになりました。つまり、インラインで定義する必要があります。これは、Mule 3 では属性として設定されていました。 また、オブジェクトストアの値を更新する方法が若干変更されました。Mule 3 には、デフォルトで false になる ​`overwrite`​ というフラグがありました。Mule 4 には、デフォルトで false になる ​`failIfPresent`​ というフラグがあります。つまり、すでに使用されているキーを指定した store 操作を使用する場合、デフォルトの動作はその値の上書きです。
Mule 4 では、キーがすでに存在し、フラグ ​failIfPresent​ が true に設定されると、OS:KEY_ALREADY_EXISTS エラーがスローされます。
移行するときには、デフォルトの動作が異なるため、フラグがどのように設定されているかに注意してください。 Mule 3 の例 ```xml (1) ```
1Mule 3 では DataWeave 式をインラインで挿入できないので、コンテンツを変数に保存するか、ペイロードを変更するかのいずれかになります。この例では、クライアント変数に割り当てられました。
Mule 4 の例 ```xml #[{ (1) id: payload.id, name: payload.name, lname: payload.lname, age: payload.age }] ```
1Mule 4 では、保存するコンテンツをインラインで挿入できます。この操作の後、ペイロードは変更されないままです。
## [](#persistent-default-value)Persistent (永続) 属性のデフォルト値 Mule 4 のオブジェクトストアはデフォルトで永続的なのに対し、Mule 3 Connector ではデフォルトでオンメモリに保存されます。このため、実装を移行するときには注意が必要です。オブジェクトストアの永続性を明示的に指定しないと、違うことを意味するようになります。 この例は、移行後に persistent (永続) 属性をどのように明示的に追加する必要があるかを示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#dispose-clear)オブジェクトストアのクリーンアップ オブジェクトストアの特定のパーティションをクリアするには、Mule 3 では dispose 操作が使用されていました。 Mule 4 には、オブジェクトストア全体をクリアする clear 操作があります。パーティションという概念は使用されなくなりした。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ```
Mule 4 の clear 操作は、オブジェクトストア全体をクリアします。
## [](#dual-store)Dual Store 操作の削除 Mule 3 の Object Store Connector には、キーを使用して値を保存し、また値を保存して同じキーを保存する ​`dual-store`​ 操作がありました。Mule 4 ではキーは ​`String`​ に限定されるため、この操作は意味がないので削除されました。 ## [](#remove-behavior)Remove 操作の動作 Mule 3 の ​`remove`​ 操作には、デフォルトで false に設定される ​`ignoreNotExists`​ というフラグがありました。これは、削除されるキーが存在しなかった場合に操作が失敗するかどうかを示します。Mule 4 では、キーが存在しない場合、​`OS:KEY_NOT_FOUND`​ エラーがスローされ、エラー処理で必要に応じて処理することができます。 # Object Store Connector の移行 Mule 4 の Object Store Connector は、Mule 3 の Object Store Connector と非常に似ています。これらのメジャーバージョンの主な違いは次のとおりです。 - カスタムオブジェクトストアの作成方法。Mule 4 でのカスタムオブジェクトストアの作成では、Spring の使用や、特定の Java クラスの存在を知っている必要がありません。 - キーは必ず文字列であること。以前の Object Store Connector では ​`Serializable`​ をキーとして使用できました。 Mule 4 では、すべてのキーは ​`String`​ 型である必要があります。 ## [](#このセクションの内容)このセクションの内容 - [名前空間の変更](#namespace) - [最上位レベルオブジェクトの使用](#configs-object-stores) - [カスタムオブジェクトストアの作成](#custom-object-store) - [キーの変更](#change-on-keys) - [値の保存](#storing-values) - [Persistent (永続) 属性のデフォルト値](#persistent-default-value) - [オブジェクトストアのクリーンアップ](#dispose-clear) - [Dual Store 操作の削除](#dual-store) - [Remove 操作の動作](#remove-behavior) ## [](#namespace)名前空間の変更 Mule 3 の Object Store Connector で使用されていた名前空間は ​`objectstore`​ でした。Mule 4 の新しいコネクタでは、この名前空間が ​`os`​ に変更されました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#configs-object-stores)最上位レベルオブジェクトの使用 前述の例では、​`config-ref`​ パラメーターが削除され、代わりに ​`objectStore`​ パラメーターが使用されていました。これは、Mule 3 ではほとんどのコネクタ操作に​_コネクタ設定の参照_​が必要であるのに対し、Mule 4 のほとんどの操作では代わりに ​_Object Store の最上位レベルの要素_​の参照を受け取るからです。 ## [](#custom-object-store)カスタムオブジェクトストアの作成 カスタムオブジェクトストアは、操作で使用するために名前で参照できる OS のグローバル定義で、オブジェクトストアの動作をニーズに応じて調整し、設定することができます。 Mule 3 では、新しい ObjectStore を作成するには、Spring bean を作成し、ObjectStore に使用する特定の Java クラスを知っている必要がありました。Mule 4 では、これがかなり容易になり、​`os:object-store`​ コンポーネントを使用して ObjectStore を宣言するグローバル要素を作成するだけですみます。 次の例は、永続的なカスタムオブジェクトストアを使用して HTTP エンドポイント経由で ​`store`​ と ​`retrieve`​ が公開される簡単なケースを、Mule 3 で行われていた方法と Mule 4 で行う方法を示しています。 Mule 3 の例 ```xml (1) (2) (4) ``` このスニペットでは、次の点に注目します。
1Spring bean と Java クラスへの参照を使用してカスタムオブジェクトストアを作成します。
2設定でカスタムオブジェクトストアを参照します。
3store 操作を使用する前に DataWeave 変換を使用して、ペイロードに何が保存されるのかを設定します。
4ペイロードはオブジェクトストアに保存されます。
Mule 4 で同じアプリケーションを実装すると次のようになります。 Mule 4 の例 ```xml (1) (2) #[{ id: attributes.queryParams.id, book: attributes.queryParams.book, author: attributes.queryParams.author }] ``` 主な違いは次のとおりです。
1新しいオブジェクトは Spring bean と Java クラスを知らずに作成されます。ここで定義されているのは、設定ではなく、オブジェクトストアの最上位レベルの要素です。
2変数またはペイロードに値を保存する必要がなく、インライン記述でオブジェクトストアに何が保存されるのかが定義されます。
Mule 3 では、オブジェクトストアのパーティションを指定する必要がありました。Mule 4 では、パーティションを指定する必要がなくなり、代わりに別のオブジェクトストアを使用します。 また、エントリの存続時間と、エントリの有効期限またはエントリ最大数を超えたどうかをチェックする頻度の両方に、時間単位を指定することができます。 ## [](#change-on-keys)キーの変更 Mule 3 では、オブジェクトストアの値を参照するために使用するキーに任意の ​`Serializable`​ を使用できました。Mule 4 では、この目的に使用できるのは ​`String`​ オブジェクトのみです。 `String`​ ではなく ​`Serializable`​ をキーとして使用している場合は、​`String`​ 値に変換してください。 ## [](#storing-values)値の保存 Mule 4 では、値のパラメーターがコンテンツのパラメーターとして取得されるようになりました。つまり、インラインで定義する必要があります。これは、Mule 3 では属性として設定されていました。 また、オブジェクトストアの値を更新する方法が若干変更されました。Mule 3 には、デフォルトで false になる ​`overwrite`​ というフラグがありました。Mule 4 には、デフォルトで false になる ​`failIfPresent`​ というフラグがあります。つまり、すでに使用されているキーを指定した store 操作を使用する場合、デフォルトの動作はその値の上書きです。
Mule 4 では、キーがすでに存在し、フラグ ​failIfPresent​ が true に設定されると、OS:KEY_ALREADY_EXISTS エラーがスローされます。
移行するときには、デフォルトの動作が異なるため、フラグがどのように設定されているかに注意してください。 Mule 3 の例 ```xml (1) ```
1Mule 3 では DataWeave 式をインラインで挿入できないので、コンテンツを変数に保存するか、ペイロードを変更するかのいずれかになります。この例では、クライアント変数に割り当てられました。
Mule 4 の例 ```xml #[{ (1) id: payload.id, name: payload.name, lname: payload.lname, age: payload.age }] ```
1Mule 4 では、保存するコンテンツをインラインで挿入できます。この操作の後、ペイロードは変更されないままです。
## [](#persistent-default-value)Persistent (永続) 属性のデフォルト値 Mule 4 のオブジェクトストアはデフォルトで永続的なのに対し、Mule 3 Connector ではデフォルトでオンメモリに保存されます。このため、実装を移行するときには注意が必要です。オブジェクトストアの永続性を明示的に指定しないと、違うことを意味するようになります。 この例は、移行後に persistent (永続) 属性をどのように明示的に追加する必要があるかを示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#dispose-clear)オブジェクトストアのクリーンアップ オブジェクトストアの特定のパーティションをクリアするには、Mule 3 では dispose 操作が使用されていました。 Mule 4 には、オブジェクトストア全体をクリアする clear 操作があります。パーティションという概念は使用されなくなりした。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ```
Mule 4 の clear 操作は、オブジェクトストア全体をクリアします。
## [](#dual-store)Dual Store 操作の削除 Mule 3 の Object Store Connector には、キーを使用して値を保存し、また値を保存して同じキーを保存する ​`dual-store`​ 操作がありました。Mule 4 ではキーは ​`String`​ に限定されるため、この操作は意味がないので削除されました。 ## [](#remove-behavior)Remove 操作の動作 Mule 3 の ​`remove`​ 操作には、デフォルトで false に設定される ​`ignoreNotExists`​ というフラグがありました。これは、削除されるキーが存在しなかった場合に操作が失敗するかどうかを示します。Mule 4 では、キーが存在しない場合、​`OS:KEY_NOT_FOUND`​ エラーがスローされ、エラー処理で必要に応じて処理することができます。 # Object Store Connector の移行 Mule 4 の Object Store Connector は、Mule 3 の Object Store Connector と非常に似ています。これらのメジャーバージョンの主な違いは次のとおりです。 - カスタムオブジェクトストアの作成方法。Mule 4 でのカスタムオブジェクトストアの作成では、Spring の使用や、特定の Java クラスの存在を知っている必要がありません。 - キーは必ず文字列であること。以前の Object Store Connector では ​`Serializable`​ をキーとして使用できました。 Mule 4 では、すべてのキーは ​`String`​ 型である必要があります。 ## [](#このセクションの内容)このセクションの内容 - [名前空間の変更](#namespace) - [最上位レベルオブジェクトの使用](#configs-object-stores) - [カスタムオブジェクトストアの作成](#custom-object-store) - [キーの変更](#change-on-keys) - [値の保存](#storing-values) - [Persistent (永続) 属性のデフォルト値](#persistent-default-value) - [オブジェクトストアのクリーンアップ](#dispose-clear) - [Dual Store 操作の削除](#dual-store) - [Remove 操作の動作](#remove-behavior) ## [](#namespace)名前空間の変更 Mule 3 の Object Store Connector で使用されていた名前空間は ​`objectstore`​ でした。Mule 4 の新しいコネクタでは、この名前空間が ​`os`​ に変更されました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#configs-object-stores)最上位レベルオブジェクトの使用 前述の例では、​`config-ref`​ パラメーターが削除され、代わりに ​`objectStore`​ パラメーターが使用されていました。これは、Mule 3 ではほとんどのコネクタ操作に​_コネクタ設定の参照_​が必要であるのに対し、Mule 4 のほとんどの操作では代わりに ​_Object Store の最上位レベルの要素_​の参照を受け取るからです。 ## [](#custom-object-store)カスタムオブジェクトストアの作成 カスタムオブジェクトストアは、操作で使用するために名前で参照できる OS のグローバル定義で、オブジェクトストアの動作をニーズに応じて調整し、設定することができます。 Mule 3 では、新しい ObjectStore を作成するには、Spring bean を作成し、ObjectStore に使用する特定の Java クラスを知っている必要がありました。Mule 4 では、これがかなり容易になり、​`os:object-store`​ コンポーネントを使用して ObjectStore を宣言するグローバル要素を作成するだけですみます。 次の例は、永続的なカスタムオブジェクトストアを使用して HTTP エンドポイント経由で ​`store`​ と ​`retrieve`​ が公開される簡単なケースを、Mule 3 で行われていた方法と Mule 4 で行う方法を示しています。 Mule 3 の例 ```xml (1) (2) (4) ``` このスニペットでは、次の点に注目します。
1Spring bean と Java クラスへの参照を使用してカスタムオブジェクトストアを作成します。
2設定でカスタムオブジェクトストアを参照します。
3store 操作を使用する前に DataWeave 変換を使用して、ペイロードに何が保存されるのかを設定します。
4ペイロードはオブジェクトストアに保存されます。
Mule 4 で同じアプリケーションを実装すると次のようになります。 Mule 4 の例 ```xml (1) (2) #[{ id: attributes.queryParams.id, book: attributes.queryParams.book, author: attributes.queryParams.author }] ``` 主な違いは次のとおりです。
1新しいオブジェクトは Spring bean と Java クラスを知らずに作成されます。ここで定義されているのは、設定ではなく、オブジェクトストアの最上位レベルの要素です。
2変数またはペイロードに値を保存する必要がなく、インライン記述でオブジェクトストアに何が保存されるのかが定義されます。
Mule 3 では、オブジェクトストアのパーティションを指定する必要がありました。Mule 4 では、パーティションを指定する必要がなくなり、代わりに別のオブジェクトストアを使用します。 また、エントリの存続時間と、エントリの有効期限またはエントリ最大数を超えたどうかをチェックする頻度の両方に、時間単位を指定することができます。 ## [](#change-on-keys)キーの変更 Mule 3 では、オブジェクトストアの値を参照するために使用するキーに任意の ​`Serializable`​ を使用できました。Mule 4 では、この目的に使用できるのは ​`String`​ オブジェクトのみです。 `String`​ ではなく ​`Serializable`​ をキーとして使用している場合は、​`String`​ 値に変換してください。 ## [](#storing-values)値の保存 Mule 4 では、値のパラメーターがコンテンツのパラメーターとして取得されるようになりました。つまり、インラインで定義する必要があります。これは、Mule 3 では属性として設定されていました。 また、オブジェクトストアの値を更新する方法が若干変更されました。Mule 3 には、デフォルトで false になる ​`overwrite`​ というフラグがありました。Mule 4 には、デフォルトで false になる ​`failIfPresent`​ というフラグがあります。つまり、すでに使用されているキーを指定した store 操作を使用する場合、デフォルトの動作はその値の上書きです。
Mule 4 では、キーがすでに存在し、フラグ ​failIfPresent​ が true に設定されると、OS:KEY_ALREADY_EXISTS エラーがスローされます。
移行するときには、デフォルトの動作が異なるため、フラグがどのように設定されているかに注意してください。 Mule 3 の例 ```xml (1) ```
1Mule 3 では DataWeave 式をインラインで挿入できないので、コンテンツを変数に保存するか、ペイロードを変更するかのいずれかになります。この例では、クライアント変数に割り当てられました。
Mule 4 の例 ```xml #[{ (1) id: payload.id, name: payload.name, lname: payload.lname, age: payload.age }] ```
1Mule 4 では、保存するコンテンツをインラインで挿入できます。この操作の後、ペイロードは変更されないままです。
## [](#persistent-default-value)Persistent (永続) 属性のデフォルト値 Mule 4 のオブジェクトストアはデフォルトで永続的なのに対し、Mule 3 Connector ではデフォルトでオンメモリに保存されます。このため、実装を移行するときには注意が必要です。オブジェクトストアの永続性を明示的に指定しないと、違うことを意味するようになります。 この例は、移行後に persistent (永続) 属性をどのように明示的に追加する必要があるかを示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#dispose-clear)オブジェクトストアのクリーンアップ オブジェクトストアの特定のパーティションをクリアするには、Mule 3 では dispose 操作が使用されていました。 Mule 4 には、オブジェクトストア全体をクリアする clear 操作があります。パーティションという概念は使用されなくなりした。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ```
Mule 4 の clear 操作は、オブジェクトストア全体をクリアします。
## [](#dual-store)Dual Store 操作の削除 Mule 3 の Object Store Connector には、キーを使用して値を保存し、また値を保存して同じキーを保存する ​`dual-store`​ 操作がありました。Mule 4 ではキーは ​`String`​ に限定されるため、この操作は意味がないので削除されました。 ## [](#remove-behavior)Remove 操作の動作 Mule 3 の ​`remove`​ 操作には、デフォルトで false に設定される ​`ignoreNotExists`​ というフラグがありました。これは、削除されるキーが存在しなかった場合に操作が失敗するかどうかを示します。Mule 4 では、キーが存在しない場合、​`OS:KEY_NOT_FOUND`​ エラーがスローされ、エラー処理で必要に応じて処理することができます。 # Object Store Connector の移行 Mule 4 の Object Store Connector は、Mule 3 の Object Store Connector と非常に似ています。これらのメジャーバージョンの主な違いは次のとおりです。 - カスタムオブジェクトストアの作成方法。Mule 4 でのカスタムオブジェクトストアの作成では、Spring の使用や、特定の Java クラスの存在を知っている必要がありません。 - キーは必ず文字列であること。以前の Object Store Connector では ​`Serializable`​ をキーとして使用できました。 Mule 4 では、すべてのキーは ​`String`​ 型である必要があります。 ## [](#このセクションの内容)このセクションの内容 - [名前空間の変更](#namespace) - [最上位レベルオブジェクトの使用](#configs-object-stores) - [カスタムオブジェクトストアの作成](#custom-object-store) - [キーの変更](#change-on-keys) - [値の保存](#storing-values) - [Persistent (永続) 属性のデフォルト値](#persistent-default-value) - [オブジェクトストアのクリーンアップ](#dispose-clear) - [Dual Store 操作の削除](#dual-store) - [Remove 操作の動作](#remove-behavior) ## [](#namespace)名前空間の変更 Mule 3 の Object Store Connector で使用されていた名前空間は ​`objectstore`​ でした。新しい Mule 4 Connector では、この名前空間が ​`os`​ に変更されました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#configs-object-stores)最上位レベルオブジェクトの使用 前述の例では、​`config-ref`​ パラメーターが削除され、代わりに ​`objectStore`​ パラメーターが使用されていました。これは、Mule 3 ではほとんどのコネクタ操作に​_コネクタ設定の参照_​が必要であるのに対し、Mule 4 のほとんどの操作では代わりに ​_Object Store の最上位レベルの要素_​の参照を受け取るからです。 ## [](#custom-object-store)カスタムオブジェクトストアの作成 カスタムオブジェクトストアは、操作で使用するために名前で参照できる OS のグローバル定義で、オブジェクトストアの動作をニーズに応じて調整し、設定することができます。 Mule 3 では、新しい ObjectStore を作成するには、Spring bean を作成し、ObjectStore に使用する特定の Java クラスを知っている必要がありました。Mule 4 では、これがかなり容易になり、​`os:object-store`​ コンポーネントを使用して ObjectStore を宣言するグローバル要素を作成するだけですみます。 次の例は、永続的なカスタムオブジェクトストアを使用して HTTP エンドポイント経由で ​`store`​ と ​`retrieve`​ が公開される簡単なケースを、Mule 3 で行われていた方法と Mule 4 で行う方法を示しています。 Mule 3 の例 ```xml (1) (2) (4) ``` このスニペットでは、次の点に注目します。
1Spring bean と Java クラスへの参照を使用してカスタムオブジェクトストアを作成します。
2設定でカスタムオブジェクトストアを参照します。
3store 操作を使用する前に DataWeave 変換を使用して、ペイロードに何が保存されるのかを設定します。
4ペイロードはオブジェクトストアに保存されます。
Mule 4 で同じアプリケーションを実装すると次のようになります。 Mule 4 の例 ```xml (1) (2) #[{ id: attributes.queryParams.id, book: attributes.queryParams.book, author: attributes.queryParams.author }] ``` 主な違いは次のとおりです。
1新しいオブジェクトは Spring bean と Java クラスを知らずに作成されます。ここで定義されているのは、設定ではなく、オブジェクトストアの最上位レベルの要素です。
2変数またはペイロードに値を保存する必要がなく、インライン記述でオブジェクトストアに何が保存されるのかが定義されます。
Mule 3 では、オブジェクトストアのパーティションを指定する必要がありました。Mule 4 では、パーティションを指定する必要がなくなり、代わりに別のオブジェクトストアを使用します。 また、エントリの存続時間と、エントリの有効期限またはエントリ最大数を超えたどうかをチェックする頻度の両方に、時間単位を指定することができます。 ## [](#change-on-keys)キーの変更 Mule 3 では、オブジェクトストアの値を参照するために使用するキーに任意の ​`Serializable`​ を使用できました。Mule 4 では、この目的に使用できるのは ​`String`​ オブジェクトのみです。 `String`​ ではなく ​`Serializable`​ をキーとして使用している場合は、​`String`​ 値に変換してください。 ## [](#storing-values)値の保存 Mule 4 では、値のパラメーターがコンテンツのパラメーターとして取得されるようになりました。つまり、インラインで定義する必要があります。これは、Mule 3 では属性として設定されていました。 また、オブジェクトストアの値を更新する方法が若干変更されました。Mule 3 には、デフォルトで false になる ​`overwrite`​ というフラグがありました。Mule 4 には、デフォルトで false になる ​`failIfPresent`​ というフラグがあります。つまり、すでに使用されているキーを指定した store 操作を使用する場合、デフォルトの動作はその値の上書きです。
Mule 4 では、キーがすでに存在し、フラグ ​failIfPresent​ が true に設定されると、OS:KEY_ALREADY_EXISTS エラーがスローされます。
移行するときには、デフォルトの動作が異なるため、フラグがどのように設定されているかに注意してください。 Mule 3 の例 ```xml (1) ```
1Mule 3 では DataWeave 式をインラインで挿入できないので、コンテンツを変数に保存するか、ペイロードを変更するかのいずれかになります。この例では、クライアント変数に割り当てられました。
Mule 4 の例 ```xml #[{ (1) id: payload.id, name: payload.name, lname: payload.lname, age: payload.age }] ```
1Mule 4 では、保存するコンテンツをインラインで挿入できます。この操作の後、ペイロードは変更されないままです。
## [](#persistent-default-value)Persistent (永続) 属性のデフォルト値 Mule 4 のオブジェクトストアはデフォルトで永続的なのに対し、Mule 3 Connector ではデフォルトでオンメモリに保存されます。このため、実装を移行するときには注意が必要です。オブジェクトストアの永続性を明示的に指定しないと、違うことを意味するようになります。 この例は、移行後に persistent (永続) 属性をどのように明示的に追加する必要があるかを示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#dispose-clear)オブジェクトストアのクリーンアップ オブジェクトストアの特定のパーティションをクリアするには、Mule 3 では dispose 操作が使用されていました。 Mule 4 には、オブジェクトストア全体をクリアする clear 操作があります。パーティションという概念は使用されなくなりした。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ```
Mule 4 の clear 操作は、オブジェクトストア全体をクリアします。
## [](#dual-store)Dual Store 操作の削除 Mule 3 の Object Store Connector には、キーを使用して値を保存し、また値を保存して同じキーを保存する ​`dual-store`​ 操作がありました。Mule 4 ではキーは ​`String`​ に限定されるため、この操作は意味がないので削除されました。 ## [](#remove-behavior)Remove 操作の動作 Mule 3 の ​`remove`​ 操作には、デフォルトで false に設定される ​`ignoreNotExists`​ というフラグがありました。これは、削除されるキーが存在しなかった場合に操作が失敗するかどうかを示します。Mule 4 では、キーが存在しない場合、​`OS:KEY_NOT_FOUND`​ エラーがスローされ、エラー処理で必要に応じて処理することができます。 # Object Store Connector の移行 Mule 4 の Object Store Connector は、Mule 3 の Object Store Connector と非常に似ています。これらのメジャーバージョンの主な違いは次のとおりです。 - カスタムオブジェクトストアの作成方法。Mule 4 でのカスタムオブジェクトストアの作成では、Spring の使用や、特定の Java クラスの存在を知っている必要がありません。 - キーは必ず文字列であること。以前の Object Store Connector では ​`Serializable`​ をキーとして使用できました。 Mule 4 では、すべてのキーは ​`String`​ 型である必要があります。 ## [](#このセクションの内容)このセクションの内容 - [名前空間の変更](#namespace) - [最上位レベルオブジェクトの使用](#configs-object-stores) - [カスタムオブジェクトストアの作成](#custom-object-store) - [キーの変更](#change-on-keys) - [値の保存](#storing-values) - [Persistent (永続) 属性のデフォルト値](#persistent-default-value) - [オブジェクトストアのクリーンアップ](#dispose-clear) - [Dual Store 操作の削除](#dual-store) - [Remove 操作の動作](#remove-behavior) ## [](#namespace)名前空間の変更 Mule 3 の Object Store Connector で使用されていた名前空間は ​`objectstore`​ でした。新しい Mule 4 Connector では、この名前空間が ​`os`​ に変更されました。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#configs-object-stores)最上位レベルオブジェクトの使用 前述の例では、​`config-ref`​ パラメーターが削除され、代わりに ​`objectStore`​ パラメーターが使用されていました。これは、Mule 3 ではほとんどのコネクタ操作に​_コネクタ設定の参照_​が必要であるのに対し、Mule 4 のほとんどの操作では代わりに ​_Object Store の最上位レベルの要素_​の参照を受け取るからです。 ## [](#custom-object-store)カスタムオブジェクトストアの作成 カスタムオブジェクトストアは、操作で使用するために名前で参照できる OS のグローバル定義で、オブジェクトストアの動作をニーズに応じて調整し、設定することができます。 Mule 3 では、新しい ObjectStore を作成するには、Spring bean を作成し、ObjectStore に使用する特定の Java クラスを知っている必要がありました。Mule 4 では、これがかなり容易になり、​`os:object-store`​ コンポーネントを使用して ObjectStore を宣言するグローバル要素を作成するだけですみます。 次の例は、永続的なカスタムオブジェクトストアを使用して HTTP エンドポイント経由で ​`store`​ と ​`retrieve`​ が公開される簡単なケースを、Mule 3 で行われていた方法と Mule 4 で行う方法を示しています。 Mule 3 の例 ```xml (1) (2) (4) ``` このスニペットでは、次の点に注目します。
1Spring bean と Java クラスへの参照を使用してカスタムオブジェクトストアを作成します。
2設定でカスタムオブジェクトストアを参照します。
3store 操作を使用する前に DataWeave 変換を使用して、ペイロードに何が保存されるのかを設定します。
4ペイロードはオブジェクトストアに保存されます。
Mule 4 で同じアプリケーションを実装すると次のようになります。 Mule 4 の例 ```xml (1) (2) #[{ id: attributes.queryParams.id, book: attributes.queryParams.book, author: attributes.queryParams.author }] ``` 主な違いは次のとおりです。
1新しいオブジェクトは Spring bean と Java クラスを知らずに作成されます。ここで定義されているのは、設定ではなく、オブジェクトストアの最上位レベルの要素です。
2変数またはペイロードに値を保存する必要がなく、インライン記述でオブジェクトストアに何が保存されるのかが定義されます。
Mule 3 では、オブジェクトストアのパーティションを指定する必要がありました。Mule 4 では、パーティションを指定する必要がなくなり、代わりに別のオブジェクトストアを使用します。 また、エントリの存続時間と、エントリの有効期限またはエントリ最大数を超えたどうかをチェックする頻度の両方に、時間単位を指定することができます。 ## [](#change-on-keys)キーの変更 Mule 3 では、オブジェクトストアの値を参照するために使用するキーに任意の ​`Serializable`​ を使用できました。Mule 4 では、この目的に使用できるのは ​`String`​ オブジェクトのみです。 `String`​ ではなく ​`Serializable`​ をキーとして使用している場合は、​`String`​ 値に変換してください。 ## [](#storing-values)値の保存 Mule 4 では、値のパラメーターがコンテンツのパラメーターとして取得されるようになりました。つまり、インラインで定義する必要があります。これは、Mule 3 では属性として設定されていました。 また、オブジェクトストアの値を更新する方法が若干変更されました。Mule 3 には、デフォルトで false になる ​`overwrite`​ というフラグがありました。Mule 4 には、デフォルトで false になる ​`failIfPresent`​ というフラグがあります。つまり、すでに使用されているキーを指定した store 操作を使用する場合、デフォルトの動作はその値の上書きです。
Mule 4 では、キーがすでに存在し、フラグ ​failIfPresent​ が true に設定されると、OS:KEY_ALREADY_EXISTS エラーがスローされます。
移行するときには、デフォルトの動作が異なるため、フラグがどのように設定されているかに注意してください。 Mule 3 の例 ```xml (1) ```
1Mule 3 では DataWeave 式をインラインで挿入できないので、コンテンツを変数に保存するか、ペイロードを変更するかのいずれかになります。この例では、クライアント変数に割り当てられました。
Mule 4 の例 ```xml #[{ (1) id: payload.id, name: payload.name, lname: payload.lname, age: payload.age }] ```
1Mule 4 では、保存するコンテンツをインラインで挿入できます。この操作の後、ペイロードは変更されないままです。
## [](#persistent-default-value)Persistent (永続) 属性のデフォルト値 Mule 4 のオブジェクトストアはデフォルトで永続的なのに対し、Mule 3 Connector ではデフォルトでオンメモリに保存されます。このため、実装を移行するときには注意が必要です。オブジェクトストアの永続性を明示的に指定しないと、違うことを意味するようになります。 この例は、移行後に persistent (永続) 属性をどのように明示的に追加する必要があるかを示しています。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#dispose-clear)オブジェクトストアのクリーンアップ オブジェクトストアの特定のパーティションをクリアするには、Mule 3 では dispose 操作が使用されていました。 Mule 4 には、オブジェクトストア全体をクリアする clear 操作があります。パーティションという概念は使用されなくなりした。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ```
Mule 4 の clear 操作は、オブジェクトストア全体をクリアします。
## [](#dual-store)Dual Store 操作の削除 Mule 3 の Object Store Connector には、キーを使用して値を保存し、また値を保存して同じキーを保存する ​`dual-store`​ 操作がありました。Mule 4 ではキーは ​`String`​ に限定されるため、この操作は意味がないので削除されました。 ## [](#remove-behavior)Remove 操作の動作 Mule 3 の ​`remove`​ 操作には、デフォルトで false に設定される ​`ignoreNotExists`​ というフラグがありました。これは、削除されるキーが存在しなかった場合に操作が失敗するかどうかを示します。Mule 4 では、キーが存在しない場合、​`OS:KEY_NOT_FOUND`​ エラーがスローされ、エラー処理で必要に応じて処理することができます。 # On-Error コンポーネント Mule アプリケーションでエラーが発生すると、Error Handler コンポーネントでエラーが ​`HTTP:NOT_FOUND`​、​`DB:CONNECTIVITY`​、​`ANY`​ (すべての Mule エラーのデフォルト) など、Mule エラーに一致した最初の On-Error コンポーネント (On Error Continue または On Error Propagate) 設定にルーティングされます。エラーについてエラー処理が設定されていない場合、アプリケーションは​[デフォルトのエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling#default_error_handling)​プロセスに従います。 ![mruntime error handler](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-error-handler.png) Figure 1. Studio のエラー処理コンポーネント ## [](#on-error-コンポーネントの動作)On-Error コンポーネントの動作 On-Error コンポーネントでは、​_オーナー_​に与える影響で違いがあります。つまり、定義されている Flow または Try スコープです。また、On-Error コンポーネントはグローバルエラーハンドラー内で定義することができ、Mule アプリケーション全体に影響します。 ### [](#on-error-propagate)On Error Propagate 実行しますが、含む側のスコープ (たとえば、エラーが発生した Try スコープが含まれるフロー) またはエラーが発生したフローに対するフロー参照が含まれる外部フローなど、上のレベルにエラーを伝播します。 エラーによってオーナーの実行が中断され、その上のレベルに伝播するため、そのレベルで失敗となります。さらに、オーナーが処理するトランザクションがロールバックされます。ただし、別のコンポーネント (On Error Propagate を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはロールバックされません。 ![mruntime on error propagate](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-on-error-propagate.png) ### [](#on-error-continue)On Error Continue 実行し、オーナーが実行を正常に完了したかのように、実行の結果をそのオーナーの結果として使用します。オーナーが処理するトランザクションはコミットされます。ただし、別のコンポーネント (On Error Continue を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはコミットされません。 ## [](#エラーの照合)エラーの照合 Mule アプリケーションのデザイン中にエラーの可能性を識別して処理できるように、On-Error コンポーネントではアプリケーションで設定される Runtime Engine および操作によってスローされる可能性があるエラーをリストしています。処理するエラーを選択できます。 - エラー種別に基づく照合: On-Error コンポーネントでは、選択した​[エラー種別](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-error-concept#error_types)​に基づいて照合を実行できます。選択可能なエラー種別のリストは、On-Error コンポーネントが適用されるフローまたはスコープ内のモジュールおよびコネクタ操作に応じて異なります。また、ランタイムでスローされる可能性がある ​`EXPRESSION`​ エラーと ​`STREAM_MAXIMUM_SIZE_EXCEEDED`​ エラーもリストしています。 ![mruntime on error type selection](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-on-error-type-selection.png) - 条件に基づく照合 (より高度なユースケース向け): On-Error コンポーネントの ​**When**​ 項目で定義した ​`when`​ 条件に基づいてエラー照合を実行できます。たとえば、コンポーネントを「fatal (致命的)」という語が含まれるエラーメッセージがある致命的なエラーにマップすることができます。 ```xml ``` この例では、​`when`​ 式に一致するすべてのエラーが ​`on-error-continue`​ によって処理されます。エラーハンドラーによって指定された種別および条件に一致するエラーのみが処理されるように、​`type="HTTP:CONNECTIVITY"`​ などの制限種別を追加することもできます。 照合条件は、On-Error コンポーネントがエラーハンドラーに存在する順番で連続的に評価されます。たとえば ​`VALIDATION:NOT_NULL`​ をある方法で処理し、その他のすべてのエラーを別の方法で処理する場合は、残りのエラーを捕捉するコンポーネント (2 つ目の On-Error コンポーネントで ​`ANY`​ として識別) の前に、そのエラーの On-Error コンポーネント設定を指定します。明示的に照合しないエラーまたは ANY を使用して捕捉するエラーでは、デフォルトのエラー処理が実行されます。 ## [](#設定と使用)設定と使用 ほとんどの場合、On Error コンポーネントはスコープに似た Error Handler コンポーネント内で設定します。各フローには組み込みの Error Handler が 1 つだけ含まれますが、Error Handler には必要に応じて任意の数の On-Error コンポーネントを含めることができ、各 On-Error コンポーネントには Logger など、On-Error コンポーネントによって捕捉されたエラーを処理するコンポーネントを任意の数含めることができます。 Error Handler コンポーネントは Flow コンポーネントおよび Try コンポーネントに組み込まれているため、On-Error コンポーネントをフローのスコープ内または Try コンポーネント内で発生したエラーに使用できます。例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling#on_error_continue)​を参照してください。 On-Error コンポーネントは、Flow コンポーネントまたは Try スコープから参照される個別の Error Handler 設定で使用することもできます (​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling#global_error_handler)​を参照)。 デフォルトでは、On-Error コンポーネントによって一致するエラーも記録され、エラーが発生した場合のエラーの通知も有効になります。これらの設定を無効にするには、Studio でコンポーネントのプロパティを変更するか、設定 XML を編集します。 Mule アプリケーションで通知リスナーを設定して、通知イベントに反応できるようにすることもできます。 ### [](#flow_error_config)フロー内のエラー処理 フロー内の組み込み Error Handler コンポーネント内部で、エラー種別と式を照合する On -Error コンポーネントを 1 つ以上セットアップできます。次の例は、任意のフロー内で発生したエラーを処理する一般的な構造を示しています。1 つのフローでは、Error Handler コンポーネントの On Error Continue (​`on-error-continue`​) を使用します。もう 1 つのフローでは On Error Propagate (​`on-error-propagate`​) を使用します。 ```xml ``` 例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling#on_error_continue)​を参照してください。 ### [](#on-error-スコープの再利用)On Error スコープの再利用 グローバルに公開してフローおよび Try スコープで参照することでエラーハンドラーを共有できるのと同じように、On-Error コンポーネントを再利用することもできます。On-Error コンポーネントをグローバルに定義して名前を付けてから、Error Handler コンポーネントから参照できます。 例: 参照される On-Error の XML 設定 ```xml ``` 他の再利用の例は、​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling#global_error_handler)​を参照してください。 ## [](#エラー処理の例)エラー処理の例 次のエラーハンドラーは、​`VALIDATION:NOT_NULL`​ エラーに対して ​`{ "messageANY" : "Some other error" }`​ ではなく ​`{ "MyError": "value was expected to be null" }`​ を生成するように設定されています。文字列 ​`value was expected to be null`​ は ​`VALIDATION:NOT_NULL`​ エラーの説明です。Is Null コンポーネントがこのエラーをスローできます。 Is Null は Validation Module に属しています。 ```xml ``` ## [](#on-error-コンポーネントリファレンス)On-Error コンポーネントリファレンス
項目 値 説明

Type (種別) (​type​)

Mule エラー種別

この On-Error 戦略によって処理されるエラーを定義する、Mule エラー種別のカンマ区切りのリスト。

When (次の場合) (​when​)

DataWeave 式

この On-Error 戦略の実行をトリガーする条件を定義する一致式。式はブール値 (​true​ または ​false​) に評価される必要があります。

Enable Notifications (通知を有効化) (​enableNotifications​)

Boolean (ブール)

エラーが発生したときに、この戦略で ​ExceptionNotification​ 種別の通知が起動されるかどうかを指定します。デフォルト値は ​true​ です。

Log Exception (例外を記録) (​logException​)

ブール。

この戦略でエラーが処理される前に、そのエラーをレベル ​ERROR​ でログに記録するかどうかを指定します。デフォルト値は ​true​ です。
## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-error-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept) - [Mule Runtime Engine 通知](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-server-notifications) # On-Error コンポーネント Mule アプリケーションでエラーが発生すると、Error Handler コンポーネントでエラーが ​`HTTP:NOT_FOUND`​、​`DB:CONNECTIVITY`​、​`ANY`​ (すべての Mule エラーのデフォルト) など、Mule エラーに一致した最初の On-Error コンポーネント (On Error Continue または On Error Propagate) 設定にルーティングされます。エラーについてエラー処理が設定されていない場合、アプリケーションは​[デフォルトのエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling#default_error_handling)​プロセスに従います。 ![mruntime error handler](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-error-handler.png) Figure 1. Studio のエラー処理コンポーネント ## [](#on-error-コンポーネントの動作)On-Error コンポーネントの動作 On-Error コンポーネントでは、​_オーナー_​に与える影響で違いがあります。つまり、定義されている Flow または Try スコープです。また、On-Error コンポーネントはグローバルエラーハンドラー内で定義することができ、Mule アプリケーション全体に影響します。 ### [](#on-error-propagate)On Error Propagate 実行しますが、含む側のスコープ (たとえば、エラーが発生した Try スコープが含まれるフロー) またはエラーが発生したフローに対するフロー参照が含まれる外部フローなど、上のレベルにエラーを伝播します。 エラーによってオーナーの実行が中断され、その上のレベルに伝播するため、そのレベルで失敗となります。さらに、オーナーが処理するトランザクションがロールバックされます。ただし、別のコンポーネント (On Error Propagate を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはロールバックされません。 ![mruntime on error propagate](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-on-error-propagate.png) ### [](#on-error-continue)On Error Continue 実行し、オーナーが実行を正常に完了したかのように、実行の結果をそのオーナーの結果として使用します。オーナーが処理するトランザクションはコミットされます。ただし、別のコンポーネント (On Error Continue を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはコミットされません。 ## [](#エラーの照合)エラーの照合 Mule アプリケーションのデザイン中にエラーの可能性を識別して処理できるように、On-Error コンポーネントではアプリケーションで設定される Runtime Engine および操作によってスローされる可能性があるエラーをリストしています。処理するエラーを選択できます。 - エラー種別に基づく照合: On-Error コンポーネントでは、選択した​[エラー種別](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-error-concept#error_types)​に基づいて照合を実行できます。選択可能なエラー種別のリストは、On-Error コンポーネントが適用されるフローまたはスコープ内のモジュールおよびコネクタ操作に応じて異なります。また、ランタイムでスローされる可能性がある ​`EXPRESSION`​ エラーと ​`STREAM_MAXIMUM_SIZE_EXCEEDED`​ エラーもリストしています。 ![mruntime on error type selection](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-on-error-type-selection.png) - 条件に基づく照合 (より高度なユースケース向け): On-Error コンポーネントの ​**When**​ 項目で定義した ​`when`​ 条件に基づいてエラー照合を実行できます。たとえば、コンポーネントを「fatal (致命的)」という語が含まれるエラーメッセージがある致命的なエラーにマップすることができます。 ```xml ``` この例では、​`when`​ 式に一致するすべてのエラーが ​`on-error-continue`​ によって処理されます。エラーハンドラーによって指定された種別および条件に一致するエラーのみが処理されるように、​`type="HTTP:CONNECTIVITY"`​ などの制限種別を追加することもできます。 照合条件は、On-Error コンポーネントがエラーハンドラーに存在する順番で連続的に評価されます。たとえば ​`VALIDATION:NOT_NULL`​ をある方法で処理し、その他のすべてのエラーを別の方法で処理する場合は、残りのエラーを捕捉するコンポーネント (2 つ目の On-Error コンポーネントで ​`ANY`​ として識別) の前に、そのエラーの On-Error コンポーネント設定を指定します。明示的に照合しないエラーまたは ANY を使用して捕捉するエラーでは、デフォルトのエラー処理が実行されます。 ## [](#設定と使用)設定と使用 ほとんどの場合、On Error コンポーネントはスコープに似た Error Handler コンポーネント内で設定します。各フローには組み込みの Error Handler が 1 つだけ含まれますが、Error Handler には必要に応じて任意の数の On-Error コンポーネントを含めることができ、各 On-Error コンポーネントには Logger など、On-Error コンポーネントによって捕捉されたエラーを処理するコンポーネントを任意の数含めることができます。 Error Handler コンポーネントは Flow コンポーネントおよび Try コンポーネントに組み込まれているため、On-Error コンポーネントをフローのスコープ内または Try コンポーネント内で発生したエラーに使用できます。例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling#on_error_continue)​を参照してください。 On-Error コンポーネントは、Flow コンポーネントまたは Try スコープから参照される個別の Error Handler 設定で使用することもできます (​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling#global_error_handler)​を参照)。 デフォルトでは、On-Error コンポーネントによって一致するエラーも記録され、エラーが発生した場合のエラーの通知も有効になります。これらの設定を無効にするには、Studio でコンポーネントのプロパティを変更するか、設定 XML を編集します。 Mule アプリケーションで通知リスナーを設定して、通知イベントに反応できるようにすることもできます。 ### [](#flow_error_config)フロー内のエラー処理 フロー内の組み込み Error Handler コンポーネント内部で、エラー種別と式を照合する On -Error コンポーネントを 1 つ以上セットアップできます。次の例は、任意のフロー内で発生したエラーを処理する一般的な構造を示しています。1 つのフローでは、Error Handler コンポーネントの On Error Continue (​`on-error-continue`​) を使用します。もう 1 つのフローでは On Error Propagate (​`on-error-propagate`​) を使用します。 ```xml ``` 例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling#on_error_continue)​を参照してください。 ### [](#on-error-スコープの再利用)On Error スコープの再利用 グローバルに公開してフローおよび Try スコープで参照することでエラーハンドラーを共有できるのと同じように、On-Error コンポーネントを再利用することもできます。On-Error コンポーネントをグローバルに定義して名前を付けてから、Error Handler コンポーネントから参照できます。 例: 参照される On-Error の XML 設定 ```xml ``` 他の再利用の例は、​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling#global_error_handler)​を参照してください。 ## [](#エラー処理の例)エラー処理の例 次のエラーハンドラーは、​`VALIDATION:NOT_NULL`​ エラーに対して ​`{ "messageANY" : "Some other error" }`​ ではなく ​`{ "MyError": "value was expected to be null" }`​ を生成するように設定されています。文字列 ​`value was expected to be null`​ は ​`VALIDATION:NOT_NULL`​ エラーの説明です。Is Null コンポーネントがこのエラーをスローできます。 Is Null は Validation Module に属しています。 ```xml ``` ## [](#on-error-コンポーネントリファレンス)On-Error コンポーネントリファレンス
項目 値 説明

Type (種別) (​type​)

Mule エラー種別

この On-Error 戦略によって処理されるエラーを定義する、Mule エラー種別のカンマ区切りのリスト。

When (次の場合) (​when​)

DataWeave 式

この On-Error 戦略の実行をトリガーする条件を定義する一致式。式はブール値 (​true​ または ​false​) に評価される必要があります。

Enable Notifications (通知を有効化) (​enableNotifications​)

Boolean (ブール)

エラーが発生したときに、この戦略で ​ExceptionNotification​ 種別の通知が起動されるかどうかを指定します。デフォルト値は ​true​ です。

Log Exception (例外を記録) (​logException​)

ブール。

この戦略でエラーが処理される前に、そのエラーをレベル ​ERROR​ でログに記録するかどうかを指定します。デフォルト値は ​true​ です。
## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-error-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept) - [Mule Runtime Engine 通知](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-server-notifications) # On-Error コンポーネント Mule アプリケーションでエラーが発生すると、Error Handler コンポーネントでエラーが ​`HTTP:NOT_FOUND`​、​`DB:CONNECTIVITY`​、​`ANY`​ (すべての Mule エラーのデフォルト) など、Mule エラーに一致した最初の On-Error コンポーネント (On Error Continue または On Error Propagate) 設定にルーティングされます。エラーについてエラー処理が設定されていない場合、アプリケーションは​[デフォルトのエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling#default_error_handling)​プロセスに従います。 ![mruntime error handler](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-error-handler.png) Figure 1. Studio のエラー処理コンポーネント ## [](#on-error-コンポーネントの動作)On-Error コンポーネントの動作 On-Error コンポーネントでは、​_オーナー_​に与える影響で違いがあります。つまり、定義されている Flow または Try スコープです。また、On-Error コンポーネントはグローバルエラーハンドラー内で定義することができ、Mule アプリケーション全体に影響します。 ### [](#on-error-propagate)On Error Propagate 実行しますが、含む側のスコープ (たとえば、エラーが発生した Try スコープが含まれるフロー) またはエラーが発生したフローに対するフロー参照が含まれる外部フローなど、上のレベルにエラーを伝播します。 エラーによってオーナーの実行が中断され、その上のレベルに伝播するため、そのレベルで失敗となります。さらに、オーナーが処理するトランザクションがロールバックされます。ただし、別のコンポーネント (On Error Propagate を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはロールバックされません。 ![mruntime on error propagate](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-on-error-propagate.png) ### [](#on-error-continue)On Error Continue 実行し、オーナーが実行を正常に完了したかのように、実行の結果をそのオーナーの結果として使用します。オーナーが処理するトランザクションはコミットされます。ただし、別のコンポーネント (On Error Continue を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはコミットされません。 ## [](#エラーの照合)エラーの照合 Mule アプリケーションのデザイン中にエラーの可能性を識別して処理できるように、On-Error コンポーネントではアプリケーションで設定される Runtime Engine および操作によってスローされる可能性があるエラーをリストしています。処理するエラーを選択できます。 - エラー種別に基づく照合: On-Error コンポーネントでは、選択した​[エラー種別](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-error-concept#error_types)​に基づいて照合を実行できます。選択可能なエラー種別のリストは、On-Error コンポーネントが適用されるフローまたはスコープ内のモジュールおよびコネクタ操作に応じて異なります。また、ランタイムでスローされる可能性がある ​`EXPRESSION`​ エラーと ​`STREAM_MAXIMUM_SIZE_EXCEEDED`​ エラーもリストしています。 ![mruntime on error type selection](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-on-error-type-selection.png) - 条件に基づく照合 (より高度なユースケース向け): On-Error コンポーネントの ​**When**​ 項目で定義した ​`when`​ 条件に基づいてエラー照合を実行できます。たとえば、コンポーネントを「fatal (致命的)」という語が含まれるエラーメッセージがある致命的なエラーにマップすることができます。 ```xml ``` この例では、​`when`​ 式に一致するすべてのエラーが ​`on-error-continue`​ によって処理されます。エラーハンドラーによって指定された種別および条件に一致するエラーのみが処理されるように、​`type="HTTP:CONNECTIVITY"`​ などの制限種別を追加することもできます。 照合条件は、On-Error コンポーネントがエラーハンドラーに存在する順番で連続的に評価されます。たとえば ​`VALIDATION:NOT_NULL`​ をある方法で処理し、その他のすべてのエラーを別の方法で処理する場合は、残りのエラーを捕捉するコンポーネント (2 つ目の On-Error コンポーネントで ​`ANY`​ として識別) の前に、そのエラーの On-Error コンポーネント設定を指定します。明示的に照合しないエラーまたは ANY を使用して捕捉するエラーでは、デフォルトのエラー処理が実行されます。 ## [](#設定と使用)設定と使用 ほとんどの場合、On Error コンポーネントはスコープに似た Error Handler コンポーネント内で設定します。各フローには組み込みの Error Handler が 1 つだけ含まれますが、Error Handler には必要に応じて任意の数の On-Error コンポーネントを含めることができ、各 On-Error コンポーネントには Logger など、On-Error コンポーネントによって捕捉されたエラーを処理するコンポーネントを任意の数含めることができます。 Error Handler コンポーネントは Flow コンポーネントおよび Try コンポーネントに組み込まれているため、On-Error コンポーネントをフローのスコープ内または Try コンポーネント内で発生したエラーに使用できます。例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling#on_error_continue)​を参照してください。 On-Error コンポーネントは、Flow コンポーネントまたは Try スコープから参照される個別の Error Handler 設定で使用することもできます (​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling#global_error_handler)​を参照)。 デフォルトでは、On-Error コンポーネントによって一致するエラーも記録され、エラーが発生した場合のエラーの通知も有効になります。これらの設定を無効にするには、Studio でコンポーネントのプロパティを変更するか、設定 XML を編集します。 Mule アプリケーションで通知リスナーを設定して、通知イベントに反応できるようにすることもできます。 ### [](#flow_error_config)フロー内のエラー処理 フロー内の組み込み Error Handler コンポーネント内部で、エラー種別と式を照合する On -Error コンポーネントを 1 つ以上セットアップできます。次の例は、任意のフロー内で発生したエラーを処理する一般的な構造を示しています。1 つのフローでは、Error Handler コンポーネントの On Error Continue (​`on-error-continue`​) を使用します。もう 1 つのフローでは On Error Propagate (​`on-error-propagate`​) を使用します。 ```xml ``` 例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling#on_error_continue)​を参照してください。 ### [](#on-error-スコープの再利用)On Error スコープの再利用 グローバルに公開してフローおよび Try スコープで参照することでエラーハンドラーを共有できるのと同じように、On-Error コンポーネントを再利用することもできます。On-Error コンポーネントをグローバルに定義して名前を付けてから、Error Handler コンポーネントから参照できます。 例: 参照される On-Error の XML 設定 ```xml ``` 他の再利用の例は、​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling#global_error_handler)​を参照してください。 ## [](#エラー処理の例)エラー処理の例 次のエラーハンドラーは、​`VALIDATION:NOT_NULL`​ エラーに対して ​`{ "messageANY" : "Some other error" }`​ ではなく ​`{ "MyError": "value was expected to be null" }`​ を生成するように設定されています。文字列 ​`value was expected to be null`​ は ​`VALIDATION:NOT_NULL`​ エラーの説明です。Is Null コンポーネントがこのエラーをスローできます。 Is Null は Validation Module に属しています。 ```xml ``` ## [](#on-error-コンポーネントリファレンス)On-Error コンポーネントリファレンス
項目 値 説明

Type (種別) (​type​)

Mule エラー種別

この On-Error 戦略によって処理されるエラーを定義する、Mule エラー種別のカンマ区切りのリスト。

When (次の場合) (​when​)

DataWeave 式

この On-Error 戦略の実行をトリガーする条件を定義する一致式。式はブール値 (​true​ または ​false​) に評価される必要があります。

Enable Notifications (通知を有効化) (​enableNotifications​)

Boolean (ブール)

エラーが発生したときに、この戦略で ​ExceptionNotification​ 種別の通知が起動されるかどうかを指定します。デフォルト値は ​true​ です。

Log Exception (例外を記録) (​logException​)

ブール。

この戦略でエラーが処理される前に、そのエラーをレベル ​ERROR​ でログに記録するかどうかを指定します。デフォルト値は ​true​ です。
## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-error-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept) - [Mule Runtime Engine 通知](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-server-notifications) # On-Error コンポーネント Mule アプリケーションでエラーが発生すると、Error Handler コンポーネントでエラーが ​`HTTP:NOT_FOUND`​、​`DB:CONNECTIVITY`​、​`ANY`​ (すべての Mule エラーのデフォルト) など、Mule エラーに一致した最初の On-Error コンポーネント (On Error Continue または On Error Propagate) 設定にルーティングされます。エラーについてエラー処理が設定されていない場合、アプリケーションは​[デフォルトのエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling#default_error_handling)​プロセスに従います。 ![mruntime error handler](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-error-handler.png) Figure 1. Studio のエラー処理コンポーネント ## [](#on-error-コンポーネントの動作)On-Error コンポーネントの動作 On-Error コンポーネントでは、​_オーナー_​に与える影響で違いがあります。つまり、定義されている Flow または Try スコープです。また、On-Error コンポーネントはグローバルエラーハンドラー内で定義することができ、Mule アプリケーション全体に影響します。 ### [](#on-error-propagate)On Error Propagate 実行しますが、含む側のスコープ (たとえば、エラーが発生した Try スコープが含まれるフロー) またはエラーが発生したフローに対するフロー参照が含まれる外部フローなど、上のレベルにエラーを伝播します。 エラーによってオーナーの実行が中断され、その上のレベルに伝播するため、そのレベルで失敗となります。さらに、オーナーが処理するトランザクションがロールバックされます。ただし、別のコンポーネント (On Error Propagate を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはロールバックされません。 ![mruntime on error propagate](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-on-error-propagate.png) ### [](#on-error-continue)On Error Continue 実行し、オーナーが実行を正常に完了したかのように、実行の結果をそのオーナーの結果として使用します。オーナーが処理するトランザクションはコミットされます。ただし、別のコンポーネント (On Error Continue を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはコミットされません。 ## [](#エラーの照合)エラーの照合 Mule アプリケーションのデザイン中にエラーの可能性を識別して処理できるように、On-Error コンポーネントではアプリケーションで設定される Runtime Engine および操作によってスローされる可能性があるエラーをリストしています。処理するエラーを選択できます。 - エラー種別に基づく照合: On-Error コンポーネントでは、選択した​[エラー種別](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-error-concept#error_types)​に基づいて照合を実行できます。選択可能なエラー種別のリストは、On-Error コンポーネントが適用されるフローまたはスコープ内のモジュールおよびコネクタ操作に応じて異なります。また、ランタイムでスローされる可能性がある ​`EXPRESSION`​ エラーと ​`STREAM_MAXIMUM_SIZE_EXCEEDED`​ エラーもリストしています。 ![mruntime on error type selection](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-on-error-type-selection.png) - 条件に基づく照合 (より高度なユースケース向け): On-Error コンポーネントの ​**When**​ 項目で定義した ​`when`​ 条件に基づいてエラー照合を実行できます。たとえば、コンポーネントを「fatal (致命的)」という語が含まれるエラーメッセージがある致命的なエラーにマップすることができます。 ```xml ``` この例では、​`when`​ 式に一致するすべてのエラーが ​`on-error-continue`​ によって処理されます。エラーハンドラーによって指定された種別および条件に一致するエラーのみが処理されるように、​`type="HTTP:CONNECTIVITY"`​ などの制限種別を追加することもできます。 照合条件は、On-Error コンポーネントがエラーハンドラーに存在する順番で連続的に評価されます。たとえば ​`VALIDATION:NOT_NULL`​ をある方法で処理し、その他のすべてのエラーを別の方法で処理する場合は、残りのエラーを捕捉するコンポーネント (2 つ目の On-Error コンポーネントで ​`ANY`​ として識別) の前に、そのエラーの On-Error コンポーネント設定を指定します。明示的に照合しないエラーまたは ANY を使用して捕捉するエラーでは、デフォルトのエラー処理が実行されます。 ## [](#設定と使用)設定と使用 ほとんどの場合、On Error コンポーネントはスコープに似た Error Handler コンポーネント内で設定します。各フローには組み込みの Error Handler が 1 つだけ含まれますが、Error Handler には必要に応じて任意の数の On-Error コンポーネントを含めることができ、各 On-Error コンポーネントには Logger など、On-Error コンポーネントによって捕捉されたエラーを処理するコンポーネントを任意の数含めることができます。 Error Handler コンポーネントは Flow コンポーネントおよび Try コンポーネントに組み込まれているため、On-Error コンポーネントをフローのスコープ内または Try コンポーネント内で発生したエラーに使用できます。例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling#on_error_continue)​を参照してください。 On-Error コンポーネントは、Flow コンポーネントまたは Try スコープから参照される個別の Error Handler 設定で使用することもできます (​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling#global_error_handler)​を参照)。 デフォルトでは、On-Error コンポーネントによって一致するエラーも記録され、エラーが発生した場合のエラーの通知も有効になります。これらの設定を無効にするには、Studio でコンポーネントのプロパティを変更するか、設定 XML を編集します。 Mule アプリケーションで通知リスナーを設定して、通知イベントに反応できるようにすることもできます。 ### [](#flow_error_config)フロー内のエラー処理 フロー内の組み込み Error Handler コンポーネント内部で、エラー種別と式を照合する On -Error コンポーネントを 1 つ以上セットアップできます。次の例は、任意のフロー内で発生したエラーを処理する一般的な構造を示しています。1 つのフローでは、Error Handler コンポーネントの On Error Continue (​`on-error-continue`​) を使用します。もう 1 つのフローでは On Error Propagate (​`on-error-propagate`​) を使用します。 ```xml ``` 例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling#on_error_continue)​を参照してください。 ### [](#on-error-スコープの再利用)On Error スコープの再利用 グローバルに公開してフローおよび Try スコープで参照することでエラーハンドラーを共有できるのと同じように、On-Error コンポーネントを再利用することもできます。On-Error コンポーネントをグローバルに定義して名前を付けてから、Error Handler コンポーネントから参照できます。 例: 参照される On-Error の XML 設定 ```xml ``` 他の再利用の例は、​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling#global_error_handler)​を参照してください。 ## [](#エラー処理の例)エラー処理の例 次のエラーハンドラーは、​`VALIDATION:NOT_NULL`​ エラーに対して ​`{ "messageANY" : "Some other error" }`​ ではなく ​`{ "MyError": "value was expected to be null" }`​ を生成するように設定されています。文字列 ​`value was expected to be null`​ は ​`VALIDATION:NOT_NULL`​ エラーの説明です。Is Null コンポーネントがこのエラーをスローできます。 Is Null は Validation Module に属しています。 ```xml ``` ## [](#on-error-コンポーネントリファレンス)On-Error コンポーネントリファレンス
項目 値 説明

Type (種別) (​type​)

Mule エラー種別

この On-Error 戦略によって処理されるエラーを定義する、Mule エラー種別のカンマ区切りのリスト。

When (次の場合) (​when​)

DataWeave 式

この On-Error 戦略の実行をトリガーする条件を定義する一致式。式はブール値 (​true​ または ​false​) に評価される必要があります。

Enable Notifications (通知を有効化) (​enableNotifications​)

Boolean (ブール)

エラーが発生したときに、この戦略で ​ExceptionNotification​ 種別の通知が起動されるかどうかを指定します。デフォルト値は ​true​ です。

Log Exception (例外を記録) (​logException​)

ブール。

この戦略でエラーが処理される前に、そのエラーをレベル ​ERROR​ でログに記録するかどうかを指定します。デフォルト値は ​true​ です。
## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-error-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept) - [Mule Runtime Engine 通知](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-server-notifications) # On-Error コンポーネント Mule アプリケーションでエラーが発生すると、Error Handler コンポーネントでエラーが ​`HTTP:NOT_FOUND`​、​`DB:CONNECTIVITY`​、​`ANY`​ (すべての Mule エラーのデフォルト) など、Mule エラーに一致した最初の On-Error コンポーネント (On Error Continue または On Error Propagate) 設定にルーティングされます。エラーについてエラー処理が設定されていない場合、アプリケーションは​[デフォルトのエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling#default_error_handling)​プロセスに従います。 ![mruntime error handler](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-error-handler.png) Figure 1. Studio のエラー処理コンポーネント ## [](#on-error-コンポーネントの動作)On-Error コンポーネントの動作 On-Error コンポーネントでは、​_オーナー_​に与える影響で違いがあります。つまり、定義されている Flow または Try スコープです。また、On-Error コンポーネントはグローバルエラーハンドラー内で定義することができ、Mule アプリケーション全体に影響します。 ### [](#on-error-propagate)On Error Propagate 実行しますが、含む側のスコープ (たとえば、エラーが発生した Try スコープが含まれるフロー) またはエラーが発生したフローに対するフロー参照が含まれる外部フローなど、上のレベルにエラーを伝播します。 エラーによってオーナーの実行が中断され、その上のレベルに伝播するため、そのレベルで失敗となります。さらに、オーナーが処理するトランザクションがロールバックされます。ただし、別のコンポーネント (On Error Propagate を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはロールバックされません。 ![mruntime on error propagate](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-on-error-propagate.png) ### [](#on-error-continue)On Error Continue 実行し、オーナーが実行を正常に完了したかのように、実行の結果をそのオーナーの結果として使用します。オーナーが処理するトランザクションはコミットされます。ただし、別のコンポーネント (On Error Continue を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはコミットされません。 ## [](#エラーの照合)エラーの照合 Mule アプリケーションのデザイン中にエラーの可能性を識別して処理できるように、On-Error コンポーネントではアプリケーションで設定される Runtime Engine および操作によってスローされる可能性があるエラーをリストしています。処理するエラーを選択できます。 - エラー種別に基づく照合: On-Error コンポーネントでは、選択した​[エラー種別](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-error-concept#error_types)​に基づいて照合を実行できます。選択可能なエラー種別のリストは、On-Error コンポーネントが適用されるフローまたはスコープ内のモジュールおよびコネクタ操作に応じて異なります。また、ランタイムでスローされる可能性がある ​`EXPRESSION`​ エラーと ​`STREAM_MAXIMUM_SIZE_EXCEEDED`​ エラーもリストしています。 ![mruntime on error type selection](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-on-error-type-selection.png) - 条件に基づく照合 (より高度なユースケース向け): On-Error コンポーネントの ​**When**​ 項目で定義した ​`when`​ 条件に基づいてエラー照合を実行できます。たとえば、コンポーネントを「fatal (致命的)」という語が含まれるエラーメッセージがある致命的なエラーにマップすることができます。 ```xml ``` この例では、​`when`​ 式に一致するすべてのエラーが ​`on-error-continue`​ によって処理されます。エラーハンドラーによって指定された種別および条件に一致するエラーのみが処理されるように、​`type="HTTP:CONNECTIVITY"`​ などの制限種別を追加することもできます。 照合条件は、On-Error コンポーネントがエラーハンドラーに存在する順番で連続的に評価されます。たとえば ​`VALIDATION:NOT_NULL`​ をある方法で処理し、その他のすべてのエラーを別の方法で処理する場合は、残りのエラーを捕捉するコンポーネント (2 つ目の On-Error コンポーネントで ​`ANY`​ として識別) の前に、そのエラーの On-Error コンポーネント設定を指定します。明示的に照合しないエラーまたは ANY を使用して捕捉するエラーでは、デフォルトのエラー処理が実行されます。 ## [](#設定と使用)設定と使用 ほとんどの場合、On Error コンポーネントはスコープに似た Error Handler コンポーネント内で設定します。各フローには組み込みの Error Handler が 1 つだけ含まれますが、Error Handler には必要に応じて任意の数の On-Error コンポーネントを含めることができ、各 On-Error コンポーネントには Logger など、On-Error コンポーネントによって捕捉されたエラーを処理するコンポーネントを任意の数含めることができます。 Error Handler コンポーネントは Flow コンポーネントおよび Try コンポーネントに組み込まれているため、On-Error コンポーネントをフローのスコープ内または Try コンポーネント内で発生したエラーに使用できます。例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling#on_error_continue)​を参照してください。 On-Error コンポーネントは、Flow コンポーネントまたは Try スコープから参照される個別の Error Handler 設定で使用することもできます (​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling#global_error_handler)​を参照)。 デフォルトでは、On-Error コンポーネントによって一致するエラーも記録され、エラーが発生した場合のエラーの通知も有効になります。これらの設定を無効にするには、Studio でコンポーネントのプロパティを変更するか、設定 XML を編集します。 Mule アプリケーションで通知リスナーを設定して、通知イベントに反応できるようにすることもできます。 ### [](#flow_error_config)フロー内のエラー処理 フロー内の組み込み Error Handler コンポーネント内部で、エラー種別と式を照合する On -Error コンポーネントを 1 つ以上セットアップできます。次の例は、任意のフロー内で発生したエラーを処理する一般的な構造を示しています。1 つのフローでは、Error Handler コンポーネントの On Error Continue (​`on-error-continue`​) を使用します。もう 1 つのフローでは On Error Propagate (​`on-error-propagate`​) を使用します。 ```xml ``` 例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling#on_error_continue)​を参照してください。 ### [](#on-error-スコープの再利用)On Error スコープの再利用 グローバルに公開してフローおよび Try スコープで参照することでエラーハンドラーを共有できるのと同じように、On-Error コンポーネントを再利用することもできます。On-Error コンポーネントをグローバルに定義して名前を付けてから、Error Handler コンポーネントから参照できます。 例: 参照される On-Error の XML 設定 ```xml ``` 他の再利用の例は、​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling#global_error_handler)​を参照してください。 ## [](#エラー処理の例)エラー処理の例 次のエラーハンドラーは、​`VALIDATION:NOT_NULL`​ エラーに対して ​`{ "messageANY" : "Some other error" }`​ ではなく ​`{ "MyError": "value was expected to be null" }`​ を生成するように設定されています。文字列 ​`value was expected to be null`​ は ​`VALIDATION:NOT_NULL`​ エラーの説明です。Is Null コンポーネントがこのエラーをスローできます。 Is Null は Validation Module に属しています。 ```xml ``` ## [](#on-error-コンポーネントリファレンス)On-Error コンポーネントリファレンス
項目 値 説明

Type (種別) (​type​)

Mule エラー種別

この On-Error 戦略によって処理されるエラーを定義する、Mule エラー種別のカンマ区切りのリスト。

When (次の場合) (​when​)

DataWeave 式

この On-Error 戦略の実行をトリガーする条件を定義する一致式。式はブール値 (​true​ または ​false​) に評価される必要があります。

Enable Notifications (通知を有効化) (​enableNotifications​)

Boolean (ブール)

エラーが発生したときに、この戦略で ​ExceptionNotification​ 種別の通知が起動されるかどうかを指定します。デフォルト値は ​true​ です。

Log Exception (例外を記録) (​logException​)

ブール。

この戦略でエラーが処理される前に、そのエラーをレベル ​ERROR​ でログに記録するかどうかを指定します。デフォルト値は ​true​ です。
## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-error-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept) - [Mule Runtime Engine 通知](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-server-notifications) # On-Error コンポーネント Mule アプリケーションでエラーが発生すると、Error Handler コンポーネントでエラーが ​`HTTP:NOT_FOUND`​、​`DB:CONNECTIVITY`​、​`ANY`​ (すべての Mule エラーのデフォルト) など、Mule エラーに一致した最初の On-Error コンポーネント (On Error Continue または On Error Propagate) 設定にルーティングされます。エラーについてエラー処理が設定されていない場合、アプリケーションは​[デフォルトのエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling#default_error_handling)​プロセスに従います。 ![Mule アプリケーションのエラー処理戦略を選択するパレットメニュー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-error-handler.png) Figure 1. Studio のエラー処理コンポーネント ## [](#on-error-コンポーネントの動作)On-Error コンポーネントの動作 On-Error コンポーネントでは、​_オーナー_​に与える影響で違いがあります。つまり、定義されている Flow または Try スコープです。また、On-Error コンポーネントはグローバルエラーハンドラー内で定義することができ、Mule アプリケーション全体に影響します。 ### [](#on-error-propagate)On Error Propagate 実行しますが、含む側のスコープ (たとえば、エラーが発生した Try スコープが含まれるフロー) またはエラーが発生したフローに対するフロー参照が含まれる外部フローなど、上のレベルにエラーを伝播します。 エラーによってオーナーの実行が中断され、その上のレベルに伝播するため、そのレベルで失敗となります。さらに、オーナーが処理するトランザクションがロールバックされます。ただし、別のコンポーネント (On Error Propagate を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはロールバックされません。 ![Mule フローの「On Error Propagate」を使用したエラー処理設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-on-error-propagate.png) ### [](#on-error-continue)On Error Continue 実行し、オーナーが実行を正常に完了したかのように、実行の結果をそのオーナーの結果として使用します。オーナーが処理するトランザクションはコミットされます。ただし、別のコンポーネント (On Error Continue を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはコミットされません。 ## [](#エラーの照合)エラーの照合 Mule アプリケーションのデザイン中にエラーの可能性を識別して処理できるように、On-Error コンポーネントではアプリケーションで設定される Runtime Engine および操作によってスローされる可能性があるエラーをリストしています。処理するエラーを選択できます。 - エラー種別に基づく照合: On-Error コンポーネントでは、選択した​[エラー種別](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-error-concept#error_types)​に基づいて照合を実行できます。選択可能なエラー種別のリストは、On-Error コンポーネントが適用されるフローまたはスコープ内のモジュールおよびコネクタ操作に応じて異なります。また、ランタイムでスローされる可能性がある ​`EXPRESSION`​ エラーと ​`STREAM_MAXIMUM_SIZE_EXCEEDED`​ エラーもリストしています。 ![Mule アプリケーションのエラー処理設定のエラー種別選択メニュー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-on-error-type-selection.png) - 条件に基づく照合 (より高度なユースケース向け): On-Error コンポーネントの ​**When**​ 項目で定義した ​`when`​ 条件に基づいてエラー照合を実行できます。たとえば、コンポーネントを「fatal (致命的)」という語が含まれるエラーメッセージがある致命的なエラーにマップすることができます。 ```xml ``` この例では、​`when`​ 式に一致するすべてのエラーが ​`on-error-continue`​ によって処理されます。エラーハンドラーによって指定された種別および条件に一致するエラーのみが処理されるように、​`type="HTTP:CONNECTIVITY"`​ などの制限種別を追加することもできます。 照合条件は、On-Error コンポーネントがエラーハンドラーに存在する順番で連続的に評価されます。たとえば ​`VALIDATION:NOT_NULL`​ をある方法で処理し、その他のすべてのエラーを別の方法で処理する場合は、残りのエラーを捕捉するコンポーネント (2 つ目の On-Error コンポーネントで ​`ANY`​ として識別) の前に、そのエラーの On-Error コンポーネント設定を指定します。明示的に照合しないエラーまたは ANY を使用して捕捉するエラーでは、デフォルトのエラー処理が実行されます。 ## [](#設定と使用)設定と使用 ほとんどの場合、On Error コンポーネントはスコープに似た Error Handler コンポーネント内で設定します。各フローには組み込みの Error Handler が 1 つだけ含まれますが、Error Handler には必要に応じて任意の数の On-Error コンポーネントを含めることができ、各 On-Error コンポーネントには Logger など、On-Error コンポーネントによって捕捉されたエラーを処理するコンポーネントを任意の数含めることができます。 Error Handler コンポーネントは Flow コンポーネントおよび Try コンポーネントに組み込まれているため、On-Error コンポーネントをフローのスコープ内または Try コンポーネント内で発生したエラーに使用できます。例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling#on_error_continue)​を参照してください。 On-Error コンポーネントは、Flow コンポーネントまたは Try スコープから参照される個別の Error Handler 設定で使用することもできます (​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling#global_error_handler)​を参照)。 デフォルトでは、On-Error コンポーネントによって一致するエラーも記録され、エラーが発生した場合のエラーの通知も有効になります。これらの設定を無効にするには、Studio でコンポーネントのプロパティを変更するか、設定 XML を編集します。 Mule アプリケーションで通知リスナーを設定して、通知イベントに反応できるようにすることもできます。 ### [](#flow_error_config)フロー内のエラー処理 フロー内の組み込み Error Handler コンポーネント内部で、エラー種別と式を照合する On -Error コンポーネントを 1 つ以上セットアップできます。次の例は、任意のフロー内で発生したエラーを処理する一般的な構造を示しています。1 つのフローでは、Error Handler コンポーネントの On Error Continue (​`on-error-continue`​) を使用します。もう 1 つのフローでは On Error Propagate (​`on-error-propagate`​) を使用します。 ```xml ``` 例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling#on_error_continue)​を参照してください。 ### [](#on-error-スコープの再利用)On Error スコープの再利用 グローバルに公開してフローおよび Try スコープで参照することでエラーハンドラーを共有できるのと同じように、On-Error コンポーネントを再利用することもできます。On-Error コンポーネントをグローバルに定義して名前を付けてから、Error Handler コンポーネントから参照できます。 例: 参照される On-Error の XML 設定 ```xml ``` 他の再利用の例は、​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling#global_error_handler)​を参照してください。 ## [](#エラー処理の例)エラー処理の例 次のエラーハンドラーは、​`VALIDATION:NOT_NULL`​ エラーに対して ​`{ "messageANY" : "Some other error" }`​ ではなく ​`{ "MyError": "value was expected to be null" }`​ を生成するように設定されています。文字列 ​`value was expected to be null`​ は ​`VALIDATION:NOT_NULL`​ エラーの説明です。Is Null コンポーネントがこのエラーをスローできます。 Is Null は Validation Module に属しています。 ```xml ``` ## [](#on-error-コンポーネントリファレンス)On-Error コンポーネントリファレンス
項目 値 説明

Type (種別) (​type​)

Mule エラー種別

この On-Error 戦略によって処理されるエラーを定義する、Mule エラー種別のカンマ区切りのリスト。

When (次の場合) (​when​)

DataWeave 式

この On-Error 戦略の実行をトリガーする条件を定義する一致式。式はブール値 (​true​ または ​false​) に評価される必要があります。

Enable Notifications (通知を有効化) (​enableNotifications​)

Boolean (ブール)

エラーが発生したときに、この戦略で ​ExceptionNotification​ 種別の通知が起動されるかどうかを指定します。デフォルト値は ​true​ です。

Log Exception (例外を記録) (​logException​)

ブール。

この戦略でエラーが処理される前に、そのエラーをレベル ​ERROR​ でログに記録するかどうかを指定します。デフォルト値は ​true​ です。
## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-error-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept) - [Mule Runtime Engine 通知](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-server-notifications) # On-Error コンポーネント Mule アプリケーションでエラーが発生すると、Error Handler コンポーネントでエラーが ​`HTTP:NOT_FOUND`​、​`DB:CONNECTIVITY`​、​`ANY`​ (すべての Mule エラーのデフォルト) など、Mule エラーに一致した最初の On-Error コンポーネント (On Error Continue または On Error Propagate) 設定にルーティングされます。エラーについてエラー処理が設定されていない場合、アプリケーションは​[デフォルトのエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling#default_error_handling)​プロセスに従います。 ![Mule アプリケーションのエラー処理戦略を選択するパレットメニュー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-error-handler.png) Figure 1. Studio のエラー処理コンポーネント ## [](#on-error-コンポーネントの動作)On-Error コンポーネントの動作 On-Error コンポーネントでは、​_オーナー_​に与える影響で違いがあります。つまり、定義されている Flow または Try スコープです。また、On-Error コンポーネントはグローバルエラーハンドラー内で定義することができ、Mule アプリケーション全体に影響します。 ### [](#on-error-propagate)On Error Propagate 実行しますが、含む側のスコープ (たとえば、エラーが発生した Try スコープが含まれるフロー) またはエラーが発生したフローに対するフロー参照が含まれる外部フローなど、上のレベルにエラーを伝播します。 エラーによってオーナーの実行が中断され、その上のレベルに伝播するため、そのレベルで失敗となります。さらに、オーナーが処理するトランザクションがロールバックされます。ただし、別のコンポーネント (On Error Propagate を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはロールバックされません。 ![Mule フローの「On Error Propagate」を使用したエラー処理設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-on-error-propagate.png) ### [](#on-error-continue)On Error Continue 実行し、オーナーが実行を正常に完了したかのように、実行の結果をそのオーナーの結果として使用します。オーナーが処理するトランザクションはコミットされます。ただし、別のコンポーネント (On Error Continue を所有しないコンポーネント) でトランザクションが作成された場合は、トランザクションはコミットされません。 ## [](#エラーの照合)エラーの照合 Mule アプリケーションのデザイン中にエラーの可能性を識別して処理できるように、On-Error コンポーネントではアプリケーションで設定される Runtime Engine および操作によってスローされる可能性があるエラーをリストしています。処理するエラーを選択できます。 - エラー種別に基づく照合: On-Error コンポーネントでは、選択した​[エラー種別](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-error-concept#error_types)​に基づいて照合を実行できます。選択可能なエラー種別のリストは、On-Error コンポーネントが適用されるフローまたはスコープ内のモジュールおよびコネクタ操作に応じて異なります。また、ランタイムでスローされる可能性がある ​`EXPRESSION`​ エラーと ​`STREAM_MAXIMUM_SIZE_EXCEEDED`​ エラーもリストしています。 ![Mule アプリケーションのエラー処理設定のエラー種別選択メニュー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-on-error-type-selection.png) - 条件に基づく照合 (より高度なユースケース向け): On-Error コンポーネントの ​**When**​ 項目で定義した ​`when`​ 条件に基づいてエラー照合を実行できます。たとえば、コンポーネントを「fatal (致命的)」という語が含まれるエラーメッセージがある致命的なエラーにマップすることができます。 ```xml ``` この例では、​`when`​ 式に一致するすべてのエラーが ​`on-error-continue`​ によって処理されます。エラーハンドラーによって指定された種別および条件に一致するエラーのみが処理されるように、​`type="HTTP:CONNECTIVITY"`​ などの制限種別を追加することもできます。 照合条件は、On-Error コンポーネントがエラーハンドラーに存在する順番で連続的に評価されます。たとえば ​`VALIDATION:NOT_NULL`​ をある方法で処理し、その他のすべてのエラーを別の方法で処理する場合は、残りのエラーを捕捉するコンポーネント (2 つ目の On-Error コンポーネントで ​`ANY`​ として識別) の前に、そのエラーの On-Error コンポーネント設定を指定します。明示的に照合しないエラーまたは ANY を使用して捕捉するエラーでは、デフォルトのエラー処理が実行されます。 ## [](#設定と使用)設定と使用 ほとんどの場合、On Error コンポーネントはスコープに似た Error Handler コンポーネント内で設定します。各フローには組み込みの Error Handler が 1 つだけ含まれますが、Error Handler には必要に応じて任意の数の On-Error コンポーネントを含めることができ、各 On-Error コンポーネントには Logger など、On-Error コンポーネントによって捕捉されたエラーを処理するコンポーネントを任意の数含めることができます。 Error Handler コンポーネントは Flow コンポーネントおよび Try コンポーネントに組み込まれているため、On-Error コンポーネントをフローのスコープ内または Try コンポーネント内で発生したエラーに使用できます。例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling#on_error_continue)​を参照してください。 On-Error コンポーネントは、Flow コンポーネントまたは Try スコープから参照される個別の Error Handler 設定で使用することもできます (​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling#global_error_handler)​を参照)。 デフォルトでは、On-Error コンポーネントによって一致するエラーも記録され、エラーが発生した場合のエラーの通知も有効になります。これらの設定を無効にするには、Studio でコンポーネントのプロパティを変更するか、設定 XML を編集します。 Mule アプリケーションで通知リスナーを設定して、通知イベントに反応できるようにすることもできます。 ### [](#flow_error_config)フロー内のエラー処理 フロー内の組み込み Error Handler コンポーネント内部で、エラー種別と式を照合する On -Error コンポーネントを 1 つ以上セットアップできます。次の例は、任意のフロー内で発生したエラーを処理する一般的な構造を示しています。1 つのフローでは、Error Handler コンポーネントの On Error Continue (​`on-error-continue`​) を使用します。もう 1 つのフローでは On Error Propagate (​`on-error-propagate`​) を使用します。 ```xml ``` 例は、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling#on_error_continue)​を参照してください。 ### [](#on-error-スコープの再利用)On Error スコープの再利用 グローバルに公開してフローおよび Try スコープで参照することでエラーハンドラーを共有できるのと同じように、On-Error コンポーネントを再利用することもできます。On-Error コンポーネントをグローバルに定義して名前を付けてから、Error Handler コンポーネントから参照できます。 例: 参照される On-Error の XML 設定 ```xml ``` 他の再利用の例は、​[「グローバルエラーハンドラーの参照」](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling#global_error_handler)​を参照してください。 ## [](#エラー処理の例)エラー処理の例 次のエラーハンドラーは、​`VALIDATION:NOT_NULL`​ エラーに対して ​`{ "messageANY" : "Some other error" }`​ ではなく ​`{ "MyError": "value was expected to be null" }`​ を生成するように設定されています。文字列 ​`value was expected to be null`​ は ​`VALIDATION:NOT_NULL`​ エラーの説明です。Is Null コンポーネントがこのエラーをスローできます。 Is Null は Validation Module に属しています。 ```xml ``` ## [](#on-error-コンポーネントリファレンス)On-Error コンポーネントリファレンス
項目 値 説明

Type (種別) (​type​)

Mule エラー種別

この On-Error 戦略によって処理されるエラーを定義する、Mule エラー種別のカンマ区切りのリスト。

When (次の場合) (​when​)

DataWeave 式

この On-Error 戦略の実行をトリガーする条件を定義する一致式。式はブール値 (​true​ または ​false​) に評価される必要があります。

Enable Notifications (通知を有効化) (​enableNotifications​)

Boolean (ブール)

エラーが発生したときに、この戦略で ​ExceptionNotification​ 種別の通知が起動されるかどうかを指定します。デフォルト値は ​true​ です。

Log Exception (例外を記録) (​logException​)

ブール。

この戦略でエラーが処理される前に、そのエラーをレベル ​ERROR​ でログに記録するかどうかを指定します。デフォルト値は ​true​ です。
## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-error-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept) - [Mule Runtime Engine 通知](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-server-notifications) # Parallel For Each スコープ Parallel For Each スコープにより、コレクションを同時処理に設定された制限のスコープ内で個別のルートで同時に処理される部分に分割することで、メッセージのコレクションを処理できます。すべてのメッセージが処理された後で、結果は分割前と同じ順序で集約され、その後もフローは続行されます。 ## [](#考慮事項)考慮事項 - Parallel For Each では、すべての処理ルートの結果がリストにバッファされ、スコープの処理が終了した後にそのリストが返されます。これにより、大量のエントリを処理するときにメモリ不足エラーが発生する可能性があります。大きなペイロードを処理するには、代わりに​[バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-processing-concept)​を使用します。 - 7.6 より前の Anypoint Studio バージョンでは、この機能は \[Mule Palette (Mule パレット)\] ビューでは提供されません。これらのバージョンで Parallel for Each を使用するには、XML で Parallel For Each スコープを手動で設定する必要があります。 ## [](#configuration-設定)Configuration (設定) Parallel For Each スコープは次の項目から設定できます。
子要素 説明

Collection (コレクション) (​collection​)

並列で処理する部分のコレクションを定義する式を指定します。デフォルトでは、受信ペイロードを使用します。
属性 説明

Collection Expression (コレクション式) (​collection​)

コレクションを返す式。デフォルトでは、ペイロードは分割するコレクションとして扱われます。

Timeout (タイムアウト) (​timeout​)

各並列ルートのタイムアウトをミリ秒単位で指定します。デフォルトでは、タイムアウトはありません。

Max Concurrency (最大同時実行) (​maxConcurrency​)

ルーターが使用する並列性の最大レベルを指定します。デフォルトでは、すべてのルートが並列実行されます。

Target Variable (対象変数) (​target​)

処理されたペイロードを保存するために使用する変数を指定します。デフォルトでは、出力はフローのペイロードに保存されます。

Target Value (対象値) (​targetValue​)

操作の出力値に対して評価する式を指定します。この式の結果は対象変数に保存されます。デフォルトでは、これは操作の出力値と同じです。
## [](#例)例 この XML の例では、コレクションのすべての要素に文字列 ​`"-result"`​ を追加します。 ```xml ``` Parallel For Each スコープのすべての実行は、ブロックの実行前と同じ変数および値で開始されます。 1 つの要素の処理中に新しい変数を追加したり既存の変数を修正したりしても、別の要素の処理中は表示されません。これらのすべての変数の変更は Parallel For Each スコープ外で使用できないため、Parallel For Each スコープの実行後、一連の変数 (およびその値) は実行前と同じままになります。 次の例を考えてみましょう。 ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "var2"}` 変数の新規作成を含めて、Parallel For Each スコープ内で実行された変更は一切登録されません。 ## [](#エラー処理)エラー処理 すべてのルートは並列処理されるため、1 つのルートでエラーがスローされた場合、すべての処理が完了するまで、他のすべてのルートでは処理が続行されます。その後、ここで示しているように、すべての結果 (およびエラー) が集約されてから、​[Error Handler](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-error-handlers)​ によって処理されます。 ```xml ``` ### [](#スロー)スロー - `MULE:COMPOSITE_ROUTING` ## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 ## [](#関連情報)関連情報 - [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/for-each-scope-concept)​。 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management#tx_scopes_routers) # Parallel For Each スコープ Parallel For Each スコープにより、コレクションを同時処理に設定された制限のスコープ内で個別のルートで同時に処理される部分に分割することで、メッセージのコレクションを処理できます。すべてのメッセージが処理された後で、結果は分割前と同じ順序で集約され、その後もフローは続行されます。 ## [](#考慮事項)考慮事項 - Parallel For Each では、すべての処理ルートの結果がリストにバッファされ、スコープの処理が終了した後にそのリストが返されます。これにより、大量のエントリを処理するときにメモリ不足エラーが発生する可能性があります。大きなペイロードを処理するには、代わりに​[バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-processing-concept)​を使用します。 - 7.6 より前の Anypoint Studio バージョンでは、この機能は \[Mule Palette (Mule パレット)\] ビューでは提供されません。これらのバージョンで Parallel for Each を使用するには、XML で Parallel For Each スコープを手動で設定する必要があります。 ## [](#configuration-設定)Configuration (設定) Parallel For Each スコープは次の項目から設定できます。
子要素 説明

Collection (コレクション) (​collection​)

並列で処理する部分のコレクションを定義する式を指定します。デフォルトでは、受信ペイロードを使用します。
属性 説明

Collection Expression (コレクション式) (​collection​)

コレクションを返す式。デフォルトでは、ペイロードは分割するコレクションとして扱われます。

Timeout (タイムアウト) (​timeout​)

各並列ルートのタイムアウトをミリ秒単位で指定します。デフォルトでは、タイムアウトはありません。

Max Concurrency (最大同時実行) (​maxConcurrency​)

ルーターが使用する並列性の最大レベルを指定します。デフォルトでは、すべてのルートが並列実行されます。

Target Variable (対象変数) (​target​)

処理されたペイロードを保存するために使用する変数を指定します。デフォルトでは、出力はフローのペイロードに保存されます。

Target Value (対象値) (​targetValue​)

操作の出力値に対して評価する式を指定します。この式の結果は対象変数に保存されます。デフォルトでは、これは操作の出力値と同じです。
## [](#例)例 この XML の例では、コレクションのすべての要素に文字列 ​`"-result"`​ を追加します。 ```xml ``` Parallel For Each スコープのすべての実行は、ブロックの実行前と同じ変数および値で開始されます。 1 つの要素の処理中に新しい変数を追加したり既存の変数を修正したりしても、別の要素の処理中は表示されません。これらのすべての変数の変更は Parallel For Each スコープ外で使用できないため、Parallel For Each スコープの実行後、一連の変数 (およびその値) は実行前と同じままになります。 次の例を考えてみましょう。 ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "var2"}` 変数の新規作成を含めて、Parallel For Each スコープ内で実行された変更は一切登録されません。 ## [](#エラー処理)エラー処理 すべてのルートは並列処理されるため、1 つのルートでエラーがスローされた場合、すべての処理が完了するまで、他のすべてのルートでは処理が続行されます。その後、ここで示しているように、すべての結果 (およびエラー) が集約されてから、​[Error Handler](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-error-handlers)​ によって処理されます。 ```xml ``` ### [](#スロー)スロー - `MULE:COMPOSITE_ROUTING` ## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 ## [](#関連情報)関連情報 - [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/for-each-scope-concept)​。 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management#tx_scopes_routers) # Parallel For Each スコープ Parallel For Each スコープにより、コレクションを同時処理に設定された制限のスコープ内で個別のルートで同時に処理される部分に分割することで、メッセージのコレクションを処理できます。すべてのメッセージが処理された後で、結果は分割前と同じ順序で集約され、その後もフローは続行されます。 ## [](#考慮事項)考慮事項 - Parallel For Each では、すべての処理ルートの結果がリストにバッファされ、スコープの処理が終了した後にそのリストが返されます。これにより、大量のエントリを処理するときにメモリ不足エラーが発生する可能性があります。大きなペイロードを処理するには、代わりに​[バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-processing-concept)​を使用します。 - 7.6 より前の Anypoint Studio バージョンでは、この機能は \[Mule Palette (Mule パレット)\] ビューでは提供されません。これらのバージョンで Parallel for Each を使用するには、XML で Parallel For Each スコープを手動で設定する必要があります。 ## [](#configuration-設定)Configuration (設定) Parallel For Each スコープは次の項目から設定できます。
子要素 説明

Collection (コレクション) (​collection​)

並列で処理する部分のコレクションを定義する式を指定します。デフォルトでは、受信ペイロードを使用します。
属性 説明

Collection Expression (コレクション式) (​collection​)

コレクションを返す式。デフォルトでは、ペイロードは分割するコレクションとして扱われます。

Timeout (タイムアウト) (​timeout​)

各並列ルートのタイムアウトをミリ秒単位で指定します。デフォルトでは、タイムアウトはありません。

Max Concurrency (最大同時実行) (​maxConcurrency​)

ルーターが使用する並列性の最大レベルを指定します。デフォルトでは、すべてのルートが並列実行されます。

Target Variable (対象変数) (​target​)

処理されたペイロードを保存するために使用する変数を指定します。デフォルトでは、出力はフローのペイロードに保存されます。

Target Value (対象値) (​targetValue​)

操作の出力値に対して評価する式を指定します。この式の結果は対象変数に保存されます。デフォルトでは、これは操作の出力値と同じです。
## [](#例)例 この XML の例では、コレクションのすべての要素に文字列 ​`"-result"`​ を追加します。 ```xml ``` Parallel For Each スコープのすべての実行は、ブロックの実行前と同じ変数および値で開始されます。 1 つの要素の処理中に新しい変数を追加したり既存の変数を修正したりしても、別の要素の処理中は表示されません。これらのすべての変数の変更は Parallel For Each スコープ外で使用できないため、Parallel For Each スコープの実行後、一連の変数 (およびその値) は実行前と同じままになります。 次の例を考えてみましょう。 ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "var2"}` 変数の新規作成を含めて、Parallel For Each スコープ内で実行された変更は一切登録されません。 ## [](#エラー処理)エラー処理 すべてのルートは並列処理されるため、1 つのルートでエラーがスローされた場合、すべての処理が完了するまで、他のすべてのルートでは処理が続行されます。その後、ここで示しているように、すべての結果 (およびエラー) が集約されてから、​[Error Handler](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-error-handlers)​ によって処理されます。 ```xml ``` ### [](#スロー)スロー - `MULE:COMPOSITE_ROUTING` ## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 ## [](#関連情報)関連情報 - [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/for-each-scope-concept)​。 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management#tx_scopes_routers) # Parallel For Each スコープ Parallel For Each スコープにより、コレクションを同時処理に設定された制限のスコープ内で個別のルートで同時に処理される部分に分割することで、メッセージのコレクションを処理できます。すべてのメッセージが処理された後で、結果は分割前と同じ順序で集約され、その後もフローは続行されます。 ## [](#考慮事項)考慮事項 - Parallel For Each では、すべての処理ルートの結果がリストにバッファされ、スコープの処理が終了した後にそのリストが返されます。これにより、大量のエントリを処理するときにメモリ不足エラーが発生する可能性があります。大きなペイロードを処理するには、代わりに​[バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-processing-concept)​を使用します。 - 7.6 より前の Anypoint Studio バージョンでは、この機能は \[Mule Palette (Mule パレット)\] ビューでは提供されません。これらのバージョンで Parallel for Each を使用するには、XML で Parallel For Each スコープを手動で設定する必要があります。 ## [](#configuration-設定)Configuration (設定) Parallel For Each スコープは次の項目から設定できます。
子要素 説明

Collection (コレクション) (​collection​)

並列で処理する部分のコレクションを定義する式を指定します。デフォルトでは、受信ペイロードを使用します。
属性 説明

Collection Expression (コレクション式) (​collection​)

コレクションを返す式。デフォルトでは、ペイロードは分割するコレクションとして扱われます。

Timeout (タイムアウト) (​timeout​)

各並列ルートのタイムアウトをミリ秒単位で指定します。デフォルトでは、タイムアウトはありません。

Max Concurrency (最大同時実行) (​maxConcurrency​)

ルーターが使用する並列性の最大レベルを指定します。デフォルトでは、すべてのルートが並列実行されます。

Target Variable (対象変数) (​target​)

処理されたペイロードを保存するために使用する変数を指定します。デフォルトでは、出力はフローのペイロードに保存されます。

Target Value (対象値) (​targetValue​)

操作の出力値に対して評価する式を指定します。この式の結果は対象変数に保存されます。デフォルトでは、これは操作の出力値と同じです。
## [](#例)例 この XML の例では、コレクションのすべての要素に文字列 ​`"-result"`​ を追加します。 ```xml ``` Parallel For Each スコープのすべての実行は、ブロックの実行前と同じ変数および値で開始されます。 1 つの要素の処理中に新しい変数を追加したり既存の変数を修正したりしても、別の要素の処理中は表示されません。これらのすべての変数の変更は Parallel For Each スコープ外で使用できないため、Parallel For Each スコープの実行後、一連の変数 (およびその値) は実行前と同じままになります。 次の例を考えてみましょう。 ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "var2"}` 変数の新規作成を含めて、Parallel For Each スコープ内で実行された変更は一切登録されません。 ## [](#エラー処理)エラー処理 すべてのルートは並列処理されるため、1 つのルートでエラーがスローされた場合、すべての処理が完了するまで、他のすべてのルートでは処理が続行されます。その後、ここで示しているように、すべての結果 (およびエラー) が集約されてから、​[Error Handler](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-error-handlers)​ によって処理されます。 ```xml ``` ### [](#スロー)スロー - `MULE:COMPOSITE_ROUTING` ## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 ## [](#関連情報)関連情報 - [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/for-each-scope-concept)​。 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management#tx_scopes_routers) # Parallel For Each スコープ Parallel For Each スコープにより、コレクションを同時処理に設定された制限のスコープ内で個別のルートで同時に処理される部分に分割することで、メッセージのコレクションを処理できます。すべてのメッセージが処理された後で、結果は分割前と同じ順序で集約され、その後もフローは続行されます。 ## [](#考慮事項)考慮事項 - Parallel For Each では、すべての処理ルートの結果がリストにバッファされ、スコープの処理が終了した後にそのリストが返されます。これにより、大量のエントリを処理するときにメモリ不足エラーが発生する可能性があります。大きなペイロードを処理するには、代わりに​[バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-processing-concept)​を使用します。 - 7.6 より前の Anypoint Studio バージョンでは、この機能は \[Mule Palette (Mule パレット)\] ビューでは提供されません。これらのバージョンで Parallel for Each を使用するには、XML で Parallel For Each スコープを手動で設定する必要があります。 ## [](#configuration-設定)Configuration (設定) Parallel For Each スコープは次の項目から設定できます。
子要素 説明

Collection (コレクション) (​collection​)

並列で処理する部分のコレクションを定義する式を指定します。デフォルトでは、受信ペイロードを使用します。
属性 説明

Collection Expression (コレクション式) (​collection​)

コレクションを返す式。デフォルトでは、ペイロードは分割するコレクションとして扱われます。

Timeout (タイムアウト) (​timeout​)

各並列ルートのタイムアウトをミリ秒単位で指定します。デフォルトでは、タイムアウトはありません。

Max Concurrency (最大同時実行) (​maxConcurrency​)

ルーターが使用する並列性の最大レベルを指定します。デフォルトでは、すべてのルートが並列実行されます。

Target Variable (対象変数) (​target​)

処理されたペイロードを保存するために使用する変数を指定します。デフォルトでは、出力はフローのペイロードに保存されます。

Target Value (対象値) (​targetValue​)

操作の出力値に対して評価する式を指定します。この式の結果は対象変数に保存されます。デフォルトでは、これは操作の出力値と同じです。
## [](#例)例 この XML の例では、コレクションのすべての要素に文字列 ​`"-result"`​ を追加します。 ```xml ``` Parallel For Each スコープのすべての実行は、ブロックの実行前と同じ変数および値で開始されます。 1 つの要素の処理中に新しい変数を追加したり既存の変数を修正したりしても、別の要素の処理中は表示されません。これらのすべての変数の変更は Parallel For Each スコープ外で使用できないため、Parallel For Each スコープの実行後、一連の変数 (およびその値) は実行前と同じままになります。 次の例を考えてみましょう。 ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "var2"}` 変数の新規作成を含めて、Parallel For Each スコープ内で実行された変更は一切登録されません。 ## [](#エラー処理)エラー処理 すべてのルートは並列処理されるため、1 つのルートでエラーがスローされた場合、すべての処理が完了するまで、他のすべてのルートでは処理が続行されます。その後、ここで示しているように、すべての結果 (およびエラー) が集約されてから、​[Error Handler](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-error-handlers)​ によって処理されます。 ```xml ``` ### [](#スロー)スロー - `MULE:COMPOSITE_ROUTING` ## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 ## [](#関連情報)関連情報 - [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/for-each-scope-concept)​。 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management#tx_scopes_routers) # Parallel For Each スコープ Parallel For Each スコープにより、コレクションを同時処理に設定された制限のスコープ内で個別のルートで同時に処理される部分に分割することで、メッセージのコレクションを処理できます。すべてのメッセージが処理された後で、結果は分割前と同じ順序で集約され、その後もフローは続行されます。 ## [](#考慮事項)考慮事項 - Parallel For Each では、すべての処理ルートの結果がリストにバッファされ、スコープの処理が終了した後にそのリストが返されます。これにより、大量のエントリを処理するときにメモリ不足エラーが発生する可能性があります。大きなペイロードを処理するには、代わりに​[バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-processing-concept)​を使用します。 - 7.6 より前の Anypoint Studio バージョンでは、この機能は \[Mule Palette (Mule パレット)\] ビューでは提供されません。これらのバージョンで Parallel for Each を使用するには、XML で Parallel For Each スコープを手動で設定する必要があります。 ## [](#configuration-設定)Configuration (設定) Parallel For Each スコープは次の項目から設定できます。
子要素 説明

Collection (コレクション) (​collection​)

並列で処理する部分のコレクションを定義する式を指定します。デフォルトでは、受信ペイロードを使用します。
属性 説明

Collection Expression (コレクション式) (​collection​)

コレクションを返す式。デフォルトでは、ペイロードは分割するコレクションとして扱われます。

Timeout (タイムアウト) (​timeout​)

各並列ルートのタイムアウトをミリ秒単位で指定します。デフォルトでは、タイムアウトはありません。

Max Concurrency (最大同時実行) (​maxConcurrency​)

ルーターが使用する並列性の最大レベルを指定します。デフォルトでは、すべてのルートが並列実行されます。

Target Variable (対象変数) (​target​)

処理されたペイロードを保存するために使用する変数を指定します。デフォルトでは、出力はフローのペイロードに保存されます。

Target Value (対象値) (​targetValue​)

操作の出力値に対して評価する式を指定します。この式の結果は対象変数に保存されます。デフォルトでは、これは操作の出力値と同じです。
## [](#例)例 この XML の例では、コレクションのすべての要素に文字列 ​`"-result"`​ を追加します。 ```xml ``` Parallel For Each スコープのすべての実行は、ブロックの実行前と同じ変数および値で開始されます。 1 つの要素の処理中に新しい変数を追加したり既存の変数を修正したりしても、別の要素の処理中は表示されません。これらのすべての変数の変更は Parallel For Each スコープ外で使用できないため、Parallel For Each スコープの実行後、一連の変数 (およびその値) は実行前と同じままになります。 次の例を考えてみましょう。 ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "var2"}` 変数の新規作成を含めて、Parallel For Each スコープ内で実行された変更は一切登録されません。 ## [](#エラー処理)エラー処理 すべてのルートは並列処理されるため、1 つのルートでエラーがスローされた場合、すべての処理が完了するまで、他のすべてのルートでは処理が続行されます。その後、ここで示しているように、すべての結果 (およびエラー) が集約されてから、​[Error Handler](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-error-handlers)​ によって処理されます。 ```xml ``` ### [](#スロー)スロー - `MULE:COMPOSITE_ROUTING` ## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 ## [](#関連情報)関連情報 - [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/for-each-scope-concept)​。 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management#tx_scopes_routers) # Parallel For Each スコープ Parallel For Each スコープにより、コレクションを同時処理に設定された制限のスコープ内で個別のルートで同時に処理される部分に分割することで、メッセージのコレクションを処理できます。すべてのメッセージが処理された後で、結果は分割前と同じ順序で集約され、その後もフローは続行されます。 ## [](#考慮事項)考慮事項 - Parallel For Each では、すべての処理ルートの結果がリストにバッファされ、スコープの処理が終了した後にそのリストが返されます。これにより、大量のエントリを処理するときにメモリ不足エラーが発生する可能性があります。大きなペイロードを処理するには、代わりに​[バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-processing-concept)​を使用します。 - 7.6 より前の Anypoint Studio バージョンでは、この機能は \[Mule Palette (Mule パレット)\] ビューでは提供されません。これらのバージョンで Parallel for Each を使用するには、XML で Parallel For Each スコープを手動で設定する必要があります。 ## [](#configuration-設定)Configuration (設定) Parallel For Each スコープは次の項目から設定できます。
子要素 説明

Collection (コレクション) (​collection​)

並列で処理する部分のコレクションを定義する式を指定します。デフォルトでは、受信ペイロードを使用します。
属性 説明

Collection Expression (コレクション式) (​collection​)

コレクションを返す式。デフォルトでは、ペイロードは分割するコレクションとして扱われます。

Timeout (タイムアウト) (​timeout​)

各並列ルートのタイムアウトをミリ秒単位で指定します。デフォルトでは、タイムアウトはありません。

Max Concurrency (最大同時実行) (​maxConcurrency​)

ルーターが使用する並列性の最大レベルを指定します。デフォルトでは、すべてのルートが並列実行されます。

Target Variable (対象変数) (​target​)

処理されたペイロードを保存するために使用する変数を指定します。デフォルトでは、出力はフローのペイロードに保存されます。

Target Value (対象値) (​targetValue​)

操作の出力値に対して評価する式を指定します。この式の結果は対象変数に保存されます。デフォルトでは、これは操作の出力値と同じです。
## [](#例)例 この XML の例では、コレクションのすべての要素に文字列 ​`"-result"`​ を追加します。 ```xml ``` Parallel For Each スコープのすべての実行は、ブロックの実行前と同じ変数および値で開始されます。 1 つの要素の処理中に新しい変数を追加したり既存の変数を修正したりしても、別の要素の処理中は表示されません。これらのすべての変数の変更は Parallel For Each スコープ外で使用できないため、Parallel For Each スコープの実行後、一連の変数 (およびその値) は実行前と同じままになります。 次の例を考えてみましょう。 ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "var2"}` 変数の新規作成を含めて、Parallel For Each スコープ内で実行された変更は一切登録されません。 ## [](#エラー処理)エラー処理 すべてのルートは並列処理されるため、1 つのルートでエラーがスローされた場合、すべての処理が完了するまで、他のすべてのルートでは処理が続行されます。その後、ここで示しているように、すべての結果 (およびエラー) が集約されてから、​[Error Handler](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-error-handlers)​ によって処理されます。 ```xml ``` ### [](#スロー)スロー - `MULE:COMPOSITE_ROUTING` ## [](#for-each-スコープと-parallel-for-each-スコープの違い)For Each スコープと Parallel For Each スコープの違い For Each と Parallel For Each のどちらも定義済みコレクションを分割し、スコープ内のコンポーネントがコレクションの各要素を処理します。どちらの場合も、同じ初期コンテキストで各ルートが実行されます。これらの 2 つのスコープの違いは、次のとおりです。 - For Each は順次処理で、Parallel For Each は並列処理です。 この違いは​_エラー処理_​に影響します。 処理の違いのため、For Each の実行はエラーの発生時に中断されてエラーハンドラーが呼び出されますが、Parallel For Each は ​`MULE:COMPOSITE_ROUTE`​ エラー種別でエラーハンドラーを呼び出す前にすべてのルートを処理します。 - For Each はペイロードを変更しませんが、Parallel For Each は各反復の出力メッセージのコレクションを出力します。 ## [](#関連情報)関連情報 - [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/for-each-scope-concept)​。 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management#tx_scopes_routers) # Parse Template リファレンス Parse Template はテンプレートを処理して結果を得るために使用する Mule コンポーネントです。テンプレートはテキストとして定義され、埋め込まれた Mule 式は評価され、結果に置き換えられます。 外部ファイル参照を使用してテンプレートを設定することも、コンポーネント定義自体に埋め込むこともできます。 [例](#code_example) ## [](#parse-template-の設定)Parse Template の設定 1. Studio で、Parse Template メッセージプロセッサーをパレットからキャンバスまでドラッグします。 2. この表で説明している項目を設定します。 ![parse](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/parse.png)
項目 値 説明

Content (コンテンツ)

テンプレート文字列

テンプレートとして使用する文字列。外部ファイルでテンプレートを定義する代わりに、この項目を使用してインラインで記述できます。評価され、結果に置き換えられる式を埋め込むことができます。

Display Name (表示名)

Parse Template

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。

Location (場所)

ファイルパス

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義します。

Target Variable (対象変数)

変数名

[Target Value (対象値)] で定義された式を評価した結果を保存する変数の名前。

Target Value (対象値)

式

Parse Template の実行後に評価される Mule 式。この式の結果は、[Target Variable (対象変数)] 項目で定義された名前の変数に保存されます。
Studio または Standalone Mule インスタンスで XML エディターを使用している場合: - `parse-template`​ 要素をフローに追加してから、下の表に従って設定します。 ```xml ``` `parse-template`​ 要素の属性:
要素属性 値

content​

使用するテンプレートを表す文字列であり、このテンプレートでは埋め込まれた式が評価され、その結果に置き換えられます。

location​

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義するファイルパス。

doc:name​

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。(注意: Mule スタンドアロンでは不要)。

target​

Parse Template が実行された後に ​targetValue​ で定義された式の結果が保存される変数の名前。

targetValue

Parse Template が実行された後に評価され、結果が ​target​ 属性で定義された名前の変数に保存される Mule 式。
## [](#code_example)例 この例では、Parse Template を使用してデータを HTML に動的に読み込みます。 - [データベースクエリの結果の動的処理](#ex_1) - [HTML 行でのデータの動的な生成](#ex_2) ### [](#ex_1)データベースクエリの結果の動的処理 この例では、データベースから従業員データを HTML テンプレートに読み込む Mule アプリケーションで Parse Template を使用します。フローは、テンプレートで構築された出力をコール元に返します。 ![parse template flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/parse-template-flow.png) #### [](#parse-template-への入力)Parse Template への入力 `http://localhost:8081/getEmployee?id=1234`​ など、従業員の ID を識別するクエリパラメーターを含む URI でフローを開始し、Select 操作で次の入力を Parse Template に返すとします。 ```html { "first_name": "Melba", "last_name": "Roy Mouton", "department": "Computers", "job_title": "Assistant Chief of Research Programs", "start_date": "01/01/2021", "employee_type": "mathematician" } ``` #### [](#template)テンプレートコンテンツ テンプレートでは、名前、部門、役職、開始日、および従業員種別の各値を含む項目を入力ペイロードから選択します。 ```html
First Name Last Name Department Job Title Start Date Employee Type
#[payload['first_name']] #[payload['last_name']] #[payload['department']] #[payload['job_title']] #[payload['start_date']] #[payload['employee_type']]
``` #### [](#configuration-xml-設定-xml)Configuration XML (設定 XML) この例の Mule 設定 XML では、Parse Template で設定 ​`location="src/main/resources/responseHtml.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml SELECT * FROM Employees WHERE id=#[attributes.queryParams['id']] ``` #### [](#テンプレートの出力)テンプレートの出力 この​[例](#template)​では、テンプレートで構築された出力が返されます。出力は、選択された従業員データを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
"Melba" "Roy Mouton" "Computers" "Assistant Chief of Research Programs" "01/01/2021" "mathematician"
``` ### [](#ex_2)HTML 行でのデータの動的な生成 この例では、オブジェクトの配列として表される従業員レコードで Parse Template を使用します。 ![parse template flow2](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/parse-template-flow2.png) #### [](#parse-template-への入力-2)Parse Template への入力 Parse Template コンポーネントは Set Payload から次のペイロードを受け取るとします。 ```html { Employee: [ { "first_name" : "Melba", "last_name" : "Roy Mouton", "department" : "Computers", "job_title" : "Assistant Chief of Research Programs", "start_date" : "01/01/2021", "employee_type" : "mathematician" }, { "first_name" : "Annie", "last_name" : "Easley", "department" : "Software Development", "job_title" : "Technical Lead", "start_date" : "06/02/2020", "employee_type" : "Rocket Scientist" } ] } ``` #### [](#template2)テンプレートコンテンツ 次のテンプレートでは、DataWeave スクリプトを使用して入力配列を反復処理し、配列内のオブジェクトごとに HTML 行を作成します。 ```html #[%dw 2.0 output application/java --- payload.*Employee[0] map ((item) -> "") joinBy ""]
First Name Last Name Department Job Title Start Date Employee Type
" ++ (item.first_name default "") ++ "" ++ (item.last_name default "") ++ "" ++ (item.department default "") ++ "" ++ (item.job_title default "") ++ "" ++ (item.start_date default "") ++ "" ++ (item.employee_type default "") ++ "
``` #### [](#configuration-xml-設定-xml-2)Configuration XML (設定 XML) Mule 設定 XML では、Parse Template で設定 ​`location="/path/to/my.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml ``` #### [](#テンプレートの出力-2)テンプレートの出力 この​[例](#template2)​では、テンプレートで構築された出力が返されます。出力は、動的に作成された行と、配列内のオブジェクトのデータを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
Melba Roy Mouton Computers Assistant Chief of Research Programs 01/01/2021 mathematician
Annie Easley Software Development Technical Lead 06/02/2020 Rocket Scientist
``` ## [](#特殊文字)特殊文字 Parse Template は、テンプレート内での式の使用や、これらの式でのリテラルの使用をサポートします。テンプレートは、​`\#[`​ といったシーケンスや引用符など、一部の特殊文字を認識します。これらの文字をエスケープすることで通常の文字として扱うことができます。 - `#[an-expression]`​: テンプレート内では ​`#[]`​ を使用して式を指定します。たとえば、テンプレートの HTML 要素内で ​`#[upper("mulesoft")]`​ という式を指定すると ​`MULESOFT`​ に解決されます。空白の式 (​`#[]`​) はエラーとなりますが、​`#['']`​ や ​`#[""]`​ などの空白文字列は有効な式です。 - サブ式: 引用符で囲まれたサブ式を解決するには、サブ式を別の ​`#[]`​ で囲みます。たとえば、次のテンプレートスニペットでは、4 つの要素で同じサブ式 (​`upper("world")`​) が引用符の内部または外部に指定されています。最初の 2 つは同じ結果を返します。最後の 2 つは、サブ式が引用符内に指定されていますが、別の ​`#[]`​ で囲まれていないため、​`upper("world")`​ を処理せずにそのまま返します。 Parse Template スニペット: ```XML #['hello #[upper("world")]'] #['hello ' ++ upper("world")] #['hello upper("world")'] #['hello ++ upper("world")'] ``` 出力される値: ```XML hello WORLD hello WORLD hello upper("world") hello ++ upper("world") ``` - エスケープ文字 (​`\`​): Parse Template は、文字シーケンスの ​`#[`​ で式の開始を示します。この文字シーケンスを式として解釈せずにリテラル文字として扱うには、​`\`​ でエスケープします。たとえば、​`#[`​ は ​`#[`​ を返します。 また、式の文字列に含まれる特殊文字を通常の文字として扱いたい場合があります。式に含まれる文字列内の特殊文字をエスケープするには、特殊文字の前に ​`\`​ を付けます。特殊文字の例としては、​`#[`​ のシーケンス、引用符 (​`'`​ または ​`"`​)、アポストロフィ (​`'`​)、​`$`​ などがあります。​`\#`​ や ​`[`​ は、文字列内でこれらの 2 文字が (​`\#`​ が ​`[`​ の前に来て) 連続していない限り、エスケープする必要はありません。 Parse Template スニペット: ```XML \#[ #['abcd\#[-1234' ++ now() as String ++ '.log'] 'abc'def' #['abc\'def'] "xyz"xyz" #["xyz\"xyz"] #["abc\$DEF\#ghi\[JKL]"] ``` 出力される値: ```XML #[ abcd#[-12342020-07-06T17:20:10.683-07:00.log 'abc'def' abc'def "xyz"xyz" xyz"xyz abc$DEF#ghi[JKL] ``` 詳細は、​[「特殊文字のエスケープ」](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-language-introduction#escape-special-characters)​を参照してください。 ## [](#関連情報)関連情報 [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.3/variable-transformer-reference) # Parse Template リファレンス Parse Template はテンプレートを処理して結果を得るために使用する Mule コンポーネントです。テンプレートはテキストとして定義され、埋め込まれた Mule 式は評価され、結果に置き換えられます。 外部ファイル参照を使用してテンプレートを設定することも、コンポーネント定義自体に埋め込むこともできます。 [例](#code_example) ## [](#parse-template-の設定)Parse Template の設定 1. Studio で、Parse Template メッセージプロセッサーをパレットからキャンバスまでドラッグします。 2. この表で説明している項目を設定します。 ![parse](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/parse.png)
項目 値 説明

Content (コンテンツ)

テンプレート文字列

テンプレートとして使用する文字列。外部ファイルでテンプレートを定義する代わりに、この項目を使用してインラインで記述できます。評価され、結果に置き換えられる式を埋め込むことができます。

Display Name (表示名)

Parse Template

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。

Location (場所)

ファイルパス

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義します。

Target Variable (対象変数)

変数名

[Target Value (対象値)] で定義された式を評価した結果を保存する変数の名前。

Target Value (対象値)

式

Parse Template の実行後に評価される Mule 式。この式の結果は、[Target Variable (対象変数)] 項目で定義された名前の変数に保存されます。
Studio または Standalone Mule インスタンスで XML エディターを使用している場合: - `parse-template`​ 要素をフローに追加してから、下の表に従って設定します。 ```xml ``` `parse-template`​ 要素の属性:
要素属性 値

content​

使用するテンプレートを表す文字列であり、このテンプレートでは埋め込まれた式が評価され、その結果に置き換えられます。

location​

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義するファイルパス。

doc:name​

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。(注意: Mule スタンドアロンでは不要)。

target​

Parse Template が実行された後に ​targetValue​ で定義された式の結果が保存される変数の名前。

targetValue

Parse Template が実行された後に評価され、結果が ​target​ 属性で定義された名前の変数に保存される Mule 式。
## [](#code_example)例 この例では、Parse Template を使用してデータを HTML に動的に読み込みます。 - [データベースクエリの結果の動的処理](#ex_1) - [HTML 行でのデータの動的な生成](#ex_2) ### [](#ex_1)データベースクエリの結果の動的処理 この例では、データベースから従業員データを HTML テンプレートに読み込む Mule アプリケーションで Parse Template を使用します。フローは、テンプレートで構築された出力をコール元に返します。 ![parse template flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/parse-template-flow.png) #### [](#parse-template-への入力)Parse Template への入力 `http://localhost:8081/getEmployee?id=1234`​ など、従業員の ID を識別するクエリパラメーターを含む URI でフローを開始し、Select 操作で次の入力を Parse Template に返すとします。 ```html { "first_name": "Melba", "last_name": "Roy Mouton", "department": "Computers", "job_title": "Assistant Chief of Research Programs", "start_date": "01/01/2021", "employee_type": "mathematician" } ``` #### [](#template)テンプレートコンテンツ テンプレートでは、名前、部門、役職、開始日、および従業員種別の各値を含む項目を入力ペイロードから選択します。 ```html
First Name Last Name Department Job Title Start Date Employee Type
#[payload['first_name']] #[payload['last_name']] #[payload['department']] #[payload['job_title']] #[payload['start_date']] #[payload['employee_type']]
``` #### [](#configuration-xml-設定-xml)Configuration XML (設定 XML) この例の Mule 設定 XML では、Parse Template で設定 ​`location="src/main/resources/responseHtml.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml SELECT * FROM Employees WHERE id=#[attributes.queryParams['id']] ``` #### [](#テンプレートの出力)テンプレートの出力 この​[例](#template)​では、テンプレートで構築された出力が返されます。出力は、選択された従業員データを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
"Melba" "Roy Mouton" "Computers" "Assistant Chief of Research Programs" "01/01/2021" "mathematician"
``` ### [](#ex_2)HTML 行でのデータの動的な生成 この例では、オブジェクトの配列として表される従業員レコードで Parse Template を使用します。 ![parse template flow2](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/parse-template-flow2.png) #### [](#parse-template-への入力-2)Parse Template への入力 Parse Template コンポーネントは Set Payload から次のペイロードを受け取るとします。 ```html { Employee: [ { "first_name" : "Melba", "last_name" : "Roy Mouton", "department" : "Computers", "job_title" : "Assistant Chief of Research Programs", "start_date" : "01/01/2021", "employee_type" : "mathematician" }, { "first_name" : "Annie", "last_name" : "Easley", "department" : "Software Development", "job_title" : "Technical Lead", "start_date" : "06/02/2020", "employee_type" : "Rocket Scientist" } ] } ``` #### [](#template2)テンプレートコンテンツ 次のテンプレートでは、DataWeave スクリプトを使用して入力配列を反復処理し、配列内のオブジェクトごとに HTML 行を作成します。 ```html #[%dw 2.0 output application/java --- payload.*Employee[0] map ((item) -> "") joinBy ""]
First Name Last Name Department Job Title Start Date Employee Type
" ++ (item.first_name default "") ++ "" ++ (item.last_name default "") ++ "" ++ (item.department default "") ++ "" ++ (item.job_title default "") ++ "" ++ (item.start_date default "") ++ "" ++ (item.employee_type default "") ++ "
``` #### [](#configuration-xml-設定-xml-2)Configuration XML (設定 XML) Mule 設定 XML では、Parse Template で設定 ​`location="/path/to/my.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml ``` #### [](#テンプレートの出力-2)テンプレートの出力 この​[例](#template2)​では、テンプレートで構築された出力が返されます。出力は、動的に作成された行と、配列内のオブジェクトのデータを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
Melba Roy Mouton Computers Assistant Chief of Research Programs 01/01/2021 mathematician
Annie Easley Software Development Technical Lead 06/02/2020 Rocket Scientist
``` ## [](#特殊文字)特殊文字 Parse Template は、テンプレート内での式の使用や、これらの式でのリテラルの使用をサポートします。テンプレートは、​`\#[`​ といったシーケンスや引用符など、一部の特殊文字を認識します。これらの文字をエスケープすることで通常の文字として扱うことができます。 - `#[an-expression]`​: テンプレート内では ​`#[]`​ を使用して式を指定します。たとえば、テンプレートの HTML 要素内で ​`#[upper("mulesoft")]`​ という式を指定すると ​`MULESOFT`​ に解決されます。空白の式 (​`#[]`​) はエラーとなりますが、​`#['']`​ や ​`#[""]`​ などの空白文字列は有効な式です。 - サブ式: 引用符で囲まれたサブ式を解決するには、サブ式を別の ​`#[]`​ で囲みます。たとえば、次のテンプレートスニペットでは、4 つの要素で同じサブ式 (​`upper("world")`​) が引用符の内部または外部に指定されています。最初の 2 つは同じ結果を返します。最後の 2 つは、サブ式が引用符内に指定されていますが、別の ​`#[]`​ で囲まれていないため、​`upper("world")`​ を処理せずにそのまま返します。 Parse Template スニペット: ```XML #['hello #[upper("world")]'] #['hello ' ++ upper("world")] #['hello upper("world")'] #['hello ++ upper("world")'] ``` 出力される値: ```XML hello WORLD hello WORLD hello upper("world") hello ++ upper("world") ``` - エスケープ文字 (​`\`​): Parse Template は、文字シーケンスの ​`#[`​ で式の開始を示します。この文字シーケンスを式として解釈せずにリテラル文字として扱うには、​`\`​ でエスケープします。たとえば、​`#[`​ は ​`#[`​ を返します。 また、式の文字列に含まれる特殊文字を通常の文字として扱いたい場合があります。式に含まれる文字列内の特殊文字をエスケープするには、特殊文字の前に ​`\`​ を付けます。特殊文字の例としては、​`#[`​ のシーケンス、引用符 (​`'`​ または ​`"`​)、アポストロフィ (​`'`​)、​`$`​ などがあります。​`\#`​ や ​`[`​ は、文字列内でこれらの 2 文字が (​`\#`​ が ​`[`​ の前に来て) 連続していない限り、エスケープする必要はありません。 Parse Template スニペット: ```XML \#[ #['abcd\#[-1234' ++ now() as String ++ '.log'] 'abc'def' #['abc\'def'] "xyz"xyz" #["xyz\"xyz"] #["abc\$DEF\#ghi\[JKL]"] ``` 出力される値: ```XML #[ abcd#[-12342020-07-06T17:20:10.683-07:00.log 'abc'def' abc'def "xyz"xyz" xyz"xyz abc$DEF#ghi[JKL] ``` 詳細は、​[「特殊文字のエスケープ」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#escape-special-characters)​を参照してください。 ## [](#関連情報)関連情報 [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.4/variable-transformer-reference) # Parse Template リファレンス Parse Template はテンプレートを処理して結果を得るために使用する Mule コンポーネントです。テンプレートはテキストとして定義され、埋め込まれた Mule 式は評価され、結果に置き換えられます。 外部ファイル参照を使用してテンプレートを設定することも、コンポーネント定義自体に埋め込むこともできます。 [例](#code_example) ## [](#parse-template-の設定)Parse Template の設定 1. Studio で、Parse Template メッセージプロセッサーをパレットからキャンバスまでドラッグします。 2. この表で説明している項目を設定します。 ![parse](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/parse.png)
項目 値 説明

Content (コンテンツ)

テンプレート文字列

テンプレートとして使用する文字列。外部ファイルでテンプレートを定義する代わりに、この項目を使用してインラインで記述できます。評価され、結果に置き換えられる式を埋め込むことができます。

Display Name (表示名)

Parse Template

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。

Location (場所)

ファイルパス

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義します。

Target Variable (対象変数)

変数名

[Target Value (対象値)] で定義された式を評価した結果を保存する変数の名前。

Target Value (対象値)

式

Parse Template の実行後に評価される Mule 式。この式の結果は、[Target Variable (対象変数)] 項目で定義された名前の変数に保存されます。
Studio または Standalone Mule インスタンスで XML エディターを使用している場合: - `parse-template`​ 要素をフローに追加してから、下の表に従って設定します。 ```xml ``` `parse-template`​ 要素の属性:
要素属性 値

content​

使用するテンプレートを表す文字列であり、このテンプレートでは埋め込まれた式が評価され、その結果に置き換えられます。

location​

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義するファイルパス。

doc:name​

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。(注意: Mule スタンドアロンでは不要)。

target​

Parse Template が実行された後に ​targetValue​ で定義された式の結果が保存される変数の名前。

targetValue

Parse Template が実行された後に評価され、結果が ​target​ 属性で定義された名前の変数に保存される Mule 式。
## [](#code_example)例 この例では、Parse Template を使用してデータを HTML に動的に読み込みます。 - [データベースクエリの結果の動的処理](#ex_1) - [HTML 行でのデータの動的な生成](#ex_2) ### [](#ex_1)データベースクエリの結果の動的処理 この例では、データベースから従業員データを HTML テンプレートに読み込む Mule アプリケーションで Parse Template を使用します。フローは、テンプレートで構築された出力をコール元に返します。 ![parse template flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/parse-template-flow.png) #### [](#parse-template-への入力)Parse Template への入力 `http://localhost:8081/getEmployee?id=1234`​ など、従業員の ID を識別するクエリパラメーターを含む URI でフローを開始し、Select 操作で次の入力を Parse Template に返すとします。 ```html { "first_name": "Melba", "last_name": "Roy Mouton", "department": "Computers", "job_title": "Assistant Chief of Research Programs", "start_date": "01/01/2021", "employee_type": "mathematician" } ``` #### [](#template)テンプレートコンテンツ テンプレートでは、名前、部門、役職、開始日、および従業員種別の各値を含む項目を入力ペイロードから選択します。 ```html
First Name Last Name Department Job Title Start Date Employee Type
#[payload['first_name']] #[payload['last_name']] #[payload['department']] #[payload['job_title']] #[payload['start_date']] #[payload['employee_type']]
``` #### [](#configuration-xml-設定-xml)Configuration XML (設定 XML) この例の Mule 設定 XML では、Parse Template で設定 ​`location="src/main/resources/responseHtml.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml SELECT * FROM Employees WHERE id=#[attributes.queryParams['id']] ``` #### [](#テンプレートの出力)テンプレートの出力 この​[例](#template)​では、テンプレートで構築された出力が返されます。出力は、選択された従業員データを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
"Melba" "Roy Mouton" "Computers" "Assistant Chief of Research Programs" "01/01/2021" "mathematician"
``` ### [](#ex_2)HTML 行でのデータの動的な生成 この例では、オブジェクトの配列として表される従業員レコードで Parse Template を使用します。 ![parse template flow2](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/parse-template-flow2.png) #### [](#parse-template-への入力-2)Parse Template への入力 Parse Template コンポーネントは Set Payload から次のペイロードを受け取るとします。 ```html { Employee: [ { "first_name" : "Melba", "last_name" : "Roy Mouton", "department" : "Computers", "job_title" : "Assistant Chief of Research Programs", "start_date" : "01/01/2021", "employee_type" : "mathematician" }, { "first_name" : "Annie", "last_name" : "Easley", "department" : "Software Development", "job_title" : "Technical Lead", "start_date" : "06/02/2020", "employee_type" : "Rocket Scientist" } ] } ``` #### [](#template2)テンプレートコンテンツ 次のテンプレートでは、DataWeave スクリプトを使用して入力配列を反復処理し、配列内のオブジェクトごとに HTML 行を作成します。 ```html #[%dw 2.0 output application/java --- payload.*Employee[0] map ((item) -> "") joinBy ""]
First Name Last Name Department Job Title Start Date Employee Type
" ++ (item.first_name default "") ++ "" ++ (item.last_name default "") ++ "" ++ (item.department default "") ++ "" ++ (item.job_title default "") ++ "" ++ (item.start_date default "") ++ "" ++ (item.employee_type default "") ++ "
``` #### [](#configuration-xml-設定-xml-2)Configuration XML (設定 XML) Mule 設定 XML では、Parse Template で設定 ​`location="/path/to/my.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml ``` #### [](#テンプレートの出力-2)テンプレートの出力 この​[例](#template2)​では、テンプレートで構築された出力が返されます。出力は、動的に作成された行と、配列内のオブジェクトのデータを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
Melba Roy Mouton Computers Assistant Chief of Research Programs 01/01/2021 mathematician
Annie Easley Software Development Technical Lead 06/02/2020 Rocket Scientist
``` ## [](#特殊文字)特殊文字 Parse Template は、テンプレート内での式の使用や、これらの式でのリテラルの使用をサポートします。テンプレートは、​`\#[`​ といったシーケンスや引用符など、一部の特殊文字を認識します。これらの文字をエスケープすることで通常の文字として扱うことができます。 - `#[an-expression]`​: テンプレート内では ​`#[]`​ を使用して式を指定します。たとえば、テンプレートの HTML 要素内で ​`#[upper("mulesoft")]`​ という式を指定すると ​`MULESOFT`​ に解決されます。空白の式 (​`#[]`​) はエラーとなりますが、​`#['']`​ や ​`#[""]`​ などの空白文字列は有効な式です。 - サブ式: 引用符で囲まれたサブ式を解決するには、サブ式を別の ​`#[]`​ で囲みます。たとえば、次のテンプレートスニペットでは、4 つの要素で同じサブ式 (​`upper("world")`​) が引用符の内部または外部に指定されています。最初の 2 つは同じ結果を返します。最後の 2 つは、サブ式が引用符内に指定されていますが、別の ​`#[]`​ で囲まれていないため、​`upper("world")`​ を処理せずにそのまま返します。 Parse Template スニペット: ```XML #['hello #[upper("world")]'] #['hello ' ++ upper("world")] #['hello upper("world")'] #['hello ++ upper("world")'] ``` 出力される値: ```XML hello WORLD hello WORLD hello upper("world") hello ++ upper("world") ``` - エスケープ文字 (​`\`​): Parse Template は、文字シーケンスの ​`#[`​ で式の開始を示します。この文字シーケンスを式として解釈せずにリテラル文字として扱うには、​`\`​ でエスケープします。たとえば、​`#[`​ は ​`#[`​ を返します。 また、式の文字列に含まれる特殊文字を通常の文字として扱いたい場合があります。式に含まれる文字列内の特殊文字をエスケープするには、特殊文字の前に ​`\`​ を付けます。特殊文字の例としては、​`#[`​ のシーケンス、引用符 (​`'`​ または ​`"`​)、アポストロフィ (​`'`​)、​`$`​ などがあります。​`\#`​ や ​`[`​ は、文字列内でこれらの 2 文字が (​`\#`​ が ​`[`​ の前に来て) 連続していない限り、エスケープする必要はありません。 Parse Template スニペット: ```XML \#[ #['abcd\#[-1234' ++ now() as String ++ '.log'] 'abc'def' #['abc\'def'] "xyz"xyz" #["xyz\"xyz"] #["abc\$DEF\#ghi\[JKL]"] ``` 出力される値: ```XML #[ abcd#[-12342020-07-06T17:20:10.683-07:00.log 'abc'def' abc'def "xyz"xyz" xyz"xyz abc$DEF#ghi[JKL] ``` 詳細は、​[「特殊文字のエスケープ」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#escape-special-characters)​を参照してください。 ## [](#関連情報)関連情報 [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.5/variable-transformer-reference) # Parse Template リファレンス Parse Template はテンプレートを処理して結果を得るために使用する Mule コンポーネントです。テンプレートはテキストとして定義され、埋め込まれた Mule 式は評価され、結果に置き換えられます。 外部ファイル参照を使用してテンプレートを設定することも、コンポーネント定義自体に埋め込むこともできます。 [例](#code_example) ## [](#parse-template-の設定)Parse Template の設定 1. Studio で、Parse Template メッセージプロセッサーをパレットからキャンバスまでドラッグします。 2. この表で説明している項目を設定します。 ![parse](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/parse.png)
項目 値 説明

Content (コンテンツ)

テンプレート文字列

テンプレートとして使用する文字列。外部ファイルでテンプレートを定義する代わりに、この項目を使用してインラインで記述できます。評価され、結果に置き換えられる式を埋め込むことができます。

Display Name (表示名)

Parse Template

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。

Location (場所)

ファイルパス

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義します。

Target Variable (対象変数)

変数名

[Target Value (対象値)] で定義された式を評価した結果を保存する変数の名前。

Target Value (対象値)

式

Parse Template の実行後に評価される Mule 式。この式の結果は、[Target Variable (対象変数)] 項目で定義された名前の変数に保存されます。
Studio または Standalone Mule インスタンスで XML エディターを使用している場合: - `parse-template`​ 要素をフローに追加してから、下の表に従って設定します。 ```xml ``` `parse-template`​ 要素の属性:
要素属性 値

content​

使用するテンプレートを表す文字列であり、このテンプレートでは埋め込まれた式が評価され、その結果に置き換えられます。

location​

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義するファイルパス。

doc:name​

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。(注意: Mule スタンドアロンでは不要)。

target​

Parse Template が実行された後に ​targetValue​ で定義された式の結果が保存される変数の名前。

targetValue

Parse Template が実行された後に評価され、結果が ​target​ 属性で定義された名前の変数に保存される Mule 式。
## [](#code_example)例 この例では、Parse Template を使用してデータを HTML に動的に読み込みます。 - [データベースクエリの結果の動的処理](#ex_1) - [HTML 行でのデータの動的な生成](#ex_2) ### [](#ex_1)データベースクエリの結果の動的処理 この例では、データベースから従業員データを HTML テンプレートに読み込む Mule アプリケーションで Parse Template を使用します。フローは、テンプレートで構築された出力をコール元に返します。 ![parse template flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/parse-template-flow.png) #### [](#parse-template-への入力)Parse Template への入力 `http://localhost:8081/getEmployee?id=1234`​ など、従業員の ID を識別するクエリパラメーターを含む URI でフローを開始し、Select 操作で次の入力を Parse Template に返すとします。 ```html { "first_name": "Melba", "last_name": "Roy Mouton", "department": "Computers", "job_title": "Assistant Chief of Research Programs", "start_date": "01/01/2021", "employee_type": "mathematician" } ``` #### [](#template)テンプレートコンテンツ テンプレートでは、名前、部門、役職、開始日、および従業員種別の各値を含む項目を入力ペイロードから選択します。 ```html
First Name Last Name Department Job Title Start Date Employee Type
#[payload['first_name']] #[payload['last_name']] #[payload['department']] #[payload['job_title']] #[payload['start_date']] #[payload['employee_type']]
``` #### [](#configuration-xml-設定-xml)Configuration XML (設定 XML) この例の Mule 設定 XML では、Parse Template で設定 ​`location="src/main/resources/responseHtml.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml SELECT * FROM Employees WHERE id=#[attributes.queryParams['id']] ``` #### [](#テンプレートの出力)テンプレートの出力 この​[例](#template)​では、テンプレートで構築された出力が返されます。出力は、選択された従業員データを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
"Melba" "Roy Mouton" "Computers" "Assistant Chief of Research Programs" "01/01/2021" "mathematician"
``` ### [](#ex_2)HTML 行でのデータの動的な生成 この例では、オブジェクトの配列として表される従業員レコードで Parse Template を使用します。 ![parse template flow2](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/parse-template-flow2.png) #### [](#parse-template-への入力-2)Parse Template への入力 Parse Template コンポーネントは Set Payload から次のペイロードを受け取るとします。 ```html { Employee: [ { "first_name" : "Melba", "last_name" : "Roy Mouton", "department" : "Computers", "job_title" : "Assistant Chief of Research Programs", "start_date" : "01/01/2021", "employee_type" : "mathematician" }, { "first_name" : "Annie", "last_name" : "Easley", "department" : "Software Development", "job_title" : "Technical Lead", "start_date" : "06/02/2020", "employee_type" : "Rocket Scientist" } ] } ``` #### [](#template2)テンプレートコンテンツ 次のテンプレートでは、DataWeave スクリプトを使用して入力配列を反復処理し、配列内のオブジェクトごとに HTML 行を作成します。 ```html #[%dw 2.0 output application/java --- payload.*Employee[0] map ((item) -> "") joinBy ""]
First Name Last Name Department Job Title Start Date Employee Type
" ++ (item.first_name default "") ++ "" ++ (item.last_name default "") ++ "" ++ (item.department default "") ++ "" ++ (item.job_title default "") ++ "" ++ (item.start_date default "") ++ "" ++ (item.employee_type default "") ++ "
``` #### [](#configuration-xml-設定-xml-2)Configuration XML (設定 XML) Mule 設定 XML では、Parse Template で設定 ​`location="/path/to/my.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml ``` #### [](#テンプレートの出力-2)テンプレートの出力 この​[例](#template2)​では、テンプレートで構築された出力が返されます。出力は、動的に作成された行と、配列内のオブジェクトのデータを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
Melba Roy Mouton Computers Assistant Chief of Research Programs 01/01/2021 mathematician
Annie Easley Software Development Technical Lead 06/02/2020 Rocket Scientist
``` ## [](#特殊文字)特殊文字 Parse Template は、テンプレート内での式の使用や、これらの式でのリテラルの使用をサポートします。テンプレートは、​`\#[`​ といったシーケンスや引用符など、一部の特殊文字を認識します。これらの文字をエスケープすることで通常の文字として扱うことができます。 - `#[an-expression]`​: テンプレート内では ​`#[]`​ を使用して式を指定します。たとえば、テンプレートの HTML 要素内で ​`#[upper("mulesoft")]`​ という式を指定すると ​`MULESOFT`​ に解決されます。空白の式 (​`#[]`​) はエラーとなりますが、​`#['']`​ や ​`#[""]`​ などの空白文字列は有効な式です。 - サブ式: 引用符で囲まれたサブ式を解決するには、サブ式を別の ​`#[]`​ で囲みます。たとえば、次のテンプレートスニペットでは、4 つの要素で同じサブ式 (​`upper("world")`​) が引用符の内部または外部に指定されています。最初の 2 つは同じ結果を返します。最後の 2 つは、サブ式が引用符内に指定されていますが、別の ​`#[]`​ で囲まれていないため、​`upper("world")`​ を処理せずにそのまま返します。 Parse Template スニペット: ```XML #['hello #[upper("world")]'] #['hello ' ++ upper("world")] #['hello upper("world")'] #['hello ++ upper("world")'] ``` 出力される値: ```XML hello WORLD hello WORLD hello upper("world") hello ++ upper("world") ``` - エスケープ文字 (​`\`​): Parse Template は、文字シーケンスの ​`#[`​ で式の開始を示します。この文字シーケンスを式として解釈せずにリテラル文字として扱うには、​`\`​ でエスケープします。たとえば、​`#[`​ は ​`#[`​ を返します。 また、式の文字列に含まれる特殊文字を通常の文字として扱いたい場合があります。式に含まれる文字列内の特殊文字をエスケープするには、特殊文字の前に ​`\`​ を付けます。特殊文字の例としては、​`#[`​ のシーケンス、引用符 (​`'`​ または ​`"`​)、アポストロフィ (​`'`​)、​`$`​ などがあります。​`\#`​ や ​`[`​ は、文字列内でこれらの 2 文字が (​`\#`​ が ​`[`​ の前に来て) 連続していない限り、エスケープする必要はありません。 Parse Template スニペット: ```XML \#[ #['abcd\#[-1234' ++ now() as String ++ '.log'] 'abc'def' #['abc\'def'] "xyz"xyz" #["xyz\"xyz"] #["abc\$DEF\#ghi\[JKL]"] ``` 出力される値: ```XML #[ abcd#[-12342020-07-06T17:20:10.683-07:00.log 'abc'def' abc'def "xyz"xyz" xyz"xyz abc$DEF#ghi[JKL] ``` 詳細は、​[「特殊文字のエスケープ」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#escape-special-characters)​を参照してください。 ## [](#関連情報)関連情報 [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.6/variable-transformer-reference) # Parse Template リファレンス Parse Template はテンプレートを処理して結果を得るために使用する Mule コンポーネントです。テンプレートはテキストとして定義され、埋め込まれた Mule 式は評価され、結果に置き換えられます。 外部ファイル参照を使用してテンプレートを設定することも、コンポーネント定義自体に埋め込むこともできます。 [例](#code_example) ## [](#parse-template-の設定)Parse Template の設定 1. Studio で、Parse Template メッセージプロセッサーをパレットからキャンバスまでドラッグします。 2. この表で説明している項目を設定します。 ![parse](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/parse.png)
項目 値 説明

Content (コンテンツ)

テンプレート文字列

テンプレートとして使用する文字列。外部ファイルでテンプレートを定義する代わりに、この項目を使用してインラインで記述できます。評価され、結果に置き換えられる式を埋め込むことができます。

Display Name (表示名)

Parse Template

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。

Location (場所)

ファイルパス

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義します。

Target Variable (対象変数)

変数名

[Target Value (対象値)] で定義された式を評価した結果を保存する変数の名前。

Target Value (対象値)

式

Parse Template の実行後に評価される Mule 式。この式の結果は、[Target Variable (対象変数)] 項目で定義された名前の変数に保存されます。
Studio または Standalone Mule インスタンスで XML エディターを使用している場合: - `parse-template`​ 要素をフローに追加してから、下の表に従って設定します。 ```xml ``` `parse-template`​ 要素の属性:
要素属性 値

content​

使用するテンプレートを表す文字列であり、このテンプレートでは埋め込まれた式が評価され、その結果に置き換えられます。

location​

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義するファイルパス。

doc:name​

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。(注意: Mule スタンドアロンでは不要)。

target​

Parse Template が実行された後に ​targetValue​ で定義された式の結果が保存される変数の名前。

targetValue

Parse Template が実行された後に評価され、結果が ​target​ 属性で定義された名前の変数に保存される Mule 式。
## [](#code_example)例 この例では、Parse Template を使用してデータを HTML に動的に読み込みます。 - [データベースクエリの結果の動的処理](#ex_1) - [HTML 行でのデータの動的な生成](#ex_2) ### [](#ex_1)データベースクエリの結果の動的処理 この例では、データベースから従業員データを HTML テンプレートに読み込む Mule アプリケーションで Parse Template を使用します。フローは、テンプレートで構築された出力をコール元に返します。 ![parse template flow](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/parse-template-flow.png) #### [](#parse-template-への入力)Parse Template への入力 `http://localhost:8081/getEmployee?id=1234`​ など、従業員の ID を識別するクエリパラメーターを含む URI でフローを開始し、Select 操作で次の入力を Parse Template に返すとします。 ```html { "first_name": "Melba", "last_name": "Roy Mouton", "department": "Computers", "job_title": "Assistant Chief of Research Programs", "start_date": "01/01/2021", "employee_type": "mathematician" } ``` #### [](#template)テンプレートコンテンツ テンプレートでは、名前、部門、役職、開始日、および従業員種別の各値を含む項目を入力ペイロードから選択します。 ```html
First Name Last Name Department Job Title Start Date Employee Type
#[payload['first_name']] #[payload['last_name']] #[payload['department']] #[payload['job_title']] #[payload['start_date']] #[payload['employee_type']]
``` #### [](#configuration-xml-設定-xml)Configuration XML (設定 XML) この例の Mule 設定 XML では、Parse Template で設定 ​`location="src/main/resources/responseHtml.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml SELECT * FROM Employees WHERE id=#[attributes.queryParams['id']] ``` #### [](#テンプレートの出力)テンプレートの出力 この​[例](#template)​では、テンプレートで構築された出力が返されます。出力は、選択された従業員データを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
"Melba" "Roy Mouton" "Computers" "Assistant Chief of Research Programs" "01/01/2021" "mathematician"
``` ### [](#ex_2)HTML 行でのデータの動的な生成 この例では、オブジェクトの配列として表される従業員レコードで Parse Template を使用します。 ![parse template flow2](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/parse-template-flow2.png) #### [](#parse-template-への入力-2)Parse Template への入力 Parse Template コンポーネントは Set Payload から次のペイロードを受け取るとします。 ```html { Employee: [ { "first_name" : "Melba", "last_name" : "Roy Mouton", "department" : "Computers", "job_title" : "Assistant Chief of Research Programs", "start_date" : "01/01/2021", "employee_type" : "mathematician" }, { "first_name" : "Annie", "last_name" : "Easley", "department" : "Software Development", "job_title" : "Technical Lead", "start_date" : "06/02/2020", "employee_type" : "Rocket Scientist" } ] } ``` #### [](#template2)テンプレートコンテンツ 次のテンプレートでは、DataWeave スクリプトを使用して入力配列を反復処理し、配列内のオブジェクトごとに HTML 行を作成します。 ```html #[%dw 2.0 output application/java --- payload.*Employee[0] map ((item) -> "") joinBy ""]
First Name Last Name Department Job Title Start Date Employee Type
" ++ (item.first_name default "") ++ "" ++ (item.last_name default "") ++ "" ++ (item.department default "") ++ "" ++ (item.job_title default "") ++ "" ++ (item.start_date default "") ++ "" ++ (item.employee_type default "") ++ "
``` #### [](#configuration-xml-設定-xml-2)Configuration XML (設定 XML) Mule 設定 XML では、Parse Template で設定 ​`location="/path/to/my.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml ``` #### [](#テンプレートの出力-2)テンプレートの出力 この​[例](#template2)​では、テンプレートで構築された出力が返されます。出力は、動的に作成された行と、配列内のオブジェクトのデータを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
Melba Roy Mouton Computers Assistant Chief of Research Programs 01/01/2021 mathematician
Annie Easley Software Development Technical Lead 06/02/2020 Rocket Scientist
``` ## [](#特殊文字)特殊文字 Parse Template は、テンプレート内での式の使用や、これらの式でのリテラルの使用をサポートします。テンプレートは、​`\#[`​ といったシーケンスや引用符など、一部の特殊文字を認識します。これらの文字をエスケープすることで通常の文字として扱うことができます。 - `#[an-expression]`​: テンプレート内では ​`#[]`​ を使用して式を指定します。たとえば、テンプレートの HTML 要素内で ​`#[upper("mulesoft")]`​ という式を指定すると ​`MULESOFT`​ に解決されます。空白の式 (​`#[]`​) はエラーとなりますが、​`#['']`​ や ​`#[""]`​ などの空白文字列は有効な式です。 - サブ式: 引用符で囲まれたサブ式を解決するには、サブ式を別の ​`#[]`​ で囲みます。たとえば、次のテンプレートスニペットでは、4 つの要素で同じサブ式 (​`upper("world")`​) が引用符の内部または外部に指定されています。最初の 2 つは同じ結果を返します。最後の 2 つは、サブ式が引用符内に指定されていますが、別の ​`#[]`​ で囲まれていないため、​`upper("world")`​ を処理せずにそのまま返します。 Parse Template スニペット: ```XML #['hello #[upper("world")]'] #['hello ' ++ upper("world")] #['hello upper("world")'] #['hello ++ upper("world")'] ``` 出力される値: ```XML hello WORLD hello WORLD hello upper("world") hello ++ upper("world") ``` - エスケープ文字 (​`\`​): Parse Template は、文字シーケンスの ​`#[`​ で式の開始を示します。この文字シーケンスを式として解釈せずにリテラル文字として扱うには、​`\`​ でエスケープします。たとえば、​`#[`​ は ​`#[`​ を返します。 また、式の文字列に含まれる特殊文字を通常の文字として扱いたい場合があります。式に含まれる文字列内の特殊文字をエスケープするには、特殊文字の前に ​`\`​ を付けます。特殊文字の例としては、​`#[`​ のシーケンス、引用符 (​`'`​ または ​`"`​)、アポストロフィ (​`'`​)、​`$`​ などがあります。​`\#`​ や ​`[`​ は、文字列内でこれらの 2 文字が (​`\#`​ が ​`[`​ の前に来て) 連続していない限り、エスケープする必要はありません。 Parse Template スニペット: ```XML \#[ #['abcd\#[-1234' ++ now() as String ++ '.log'] 'abc'def' #['abc\'def'] "xyz"xyz" #["xyz\"xyz"] #["abc\$DEF\#ghi\[JKL]"] ``` 出力される値: ```XML #[ abcd#[-12342020-07-06T17:20:10.683-07:00.log 'abc'def' abc'def "xyz"xyz" xyz"xyz abc$DEF#ghi[JKL] ``` 詳細は、​[「特殊文字のエスケープ」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#escape-special-characters)​を参照してください。 ## [](#関連情報)関連情報 [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.7/variable-transformer-reference) # Parse Template リファレンス Parse Template はテンプレートを処理して結果を得るために使用する Mule コンポーネントです。テンプレートはテキストとして定義され、埋め込まれた Mule 式は評価され、結果に置き換えられます。 外部ファイル参照を使用してテンプレートを設定することも、コンポーネント定義自体に埋め込むこともできます。 [例](#code_example) ## [](#parse-template-の設定)Parse Template の設定 1. Studio で、Parse Template メッセージプロセッサーをパレットからキャンバスまでドラッグします。 2. この表で説明している項目を設定します。 ![エラーメッセージが表示されている Parse Template](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/parse.png)
項目 値 説明

Content (コンテンツ)

テンプレート文字列

テンプレートとして使用する文字列。外部ファイルでテンプレートを定義する代わりに、この項目を使用してインラインで記述できます。評価され、結果に置き換えられる式を埋め込むことができます。

Display Name (表示名)

Parse Template

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。

Location (場所)

ファイルパス

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義します。

Target Variable (対象変数)

変数名

[Target Value (対象値)] で定義された式を評価した結果を保存する変数の名前。

Target Value (対象値)

式

Parse Template の実行後に評価される Mule 式。この式の結果は、[Target Variable (対象変数)] 項目で定義された名前の変数に保存されます。
Studio または Standalone Mule インスタンスで XML エディターを使用している場合: - `parse-template`​ 要素をフローに追加してから、下の表に従って設定します。 ```xml ``` `parse-template`​ 要素の属性:
要素属性 値

content​

使用するテンプレートを表す文字列であり、このテンプレートでは埋め込まれた式が評価され、その結果に置き換えられます。

location​

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義するファイルパス。

doc:name​

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。(注意: Mule スタンドアロンでは不要)。

target​

Parse Template が実行された後に ​targetValue​ で定義された式の結果が保存される変数の名前。

targetValue

Parse Template が実行された後に評価され、結果が ​target​ 属性で定義された名前の変数に保存される Mule 式。
## [](#code_example)例 この例では、Parse Template を使用してデータを HTML に動的に読み込みます。 - [データベースクエリの結果の動的処理](#ex_1) - [HTML 行でのデータの動的な生成](#ex_2) ### [](#ex_1)データベースクエリの結果の動的処理 この例では、データベースから従業員データを HTML テンプレートに読み込む Mule アプリケーションで Parse Template を使用します。フローは、テンプレートで構築された出力をコール元に返します。 ![Parse Template を使用した Listener から Error handling へのステップが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/parse-template-flow.png) #### [](#parse-template-への入力)Parse Template への入力 `http://localhost:8081/getEmployee?id=1234`​ など、従業員の ID を識別するクエリパラメーターを含む URI でフローを開始し、Select 操作で次の入力を Parse Template に返すとします。 ```html { "first_name": "Melba", "last_name": "Roy Mouton", "department": "Computers", "job_title": "Assistant Chief of Research Programs", "start_date": "01/01/2021", "employee_type": "mathematician" } ``` #### [](#template)テンプレートコンテンツ テンプレートでは、名前、部門、役職、開始日、および従業員種別の各値を含む項目を入力ペイロードから選択します。 ```html
First Name Last Name Department Job Title Start Date Employee Type
#[payload['first_name']] #[payload['last_name']] #[payload['department']] #[payload['job_title']] #[payload['start_date']] #[payload['employee_type']]
``` #### [](#configuration-xml-設定-xml)Configuration XML (設定 XML) この例の Mule 設定 XML では、Parse Template で設定 ​`location="src/main/resources/responseHtml.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml SELECT * FROM Employees WHERE id=#[attributes.queryParams['id']] ``` #### [](#テンプレートの出力)テンプレートの出力 この​[例](#template)​では、テンプレートで構築された出力が返されます。出力は、選択された従業員データを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
"Melba" "Roy Mouton" "Computers" "Assistant Chief of Research Programs" "01/01/2021" "mathematician"
``` ### [](#ex_2)HTML 行でのデータの動的な生成 この例では、オブジェクトの配列として表される従業員レコードで Parse Template を使用します。 ![Listener、Set Payload、Parse Template、Logger が含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/parse-template-flow2.png) #### [](#parse-template-への入力-2)Parse Template への入力 Parse Template コンポーネントは Set Payload から次のペイロードを受け取るとします。 ```html { Employee: [ { "first_name" : "Melba", "last_name" : "Roy Mouton", "department" : "Computers", "job_title" : "Assistant Chief of Research Programs", "start_date" : "01/01/2021", "employee_type" : "mathematician" }, { "first_name" : "Annie", "last_name" : "Easley", "department" : "Software Development", "job_title" : "Technical Lead", "start_date" : "06/02/2020", "employee_type" : "Rocket Scientist" } ] } ``` #### [](#template2)テンプレートコンテンツ 次のテンプレートでは、DataWeave スクリプトを使用して入力配列を反復処理し、配列内のオブジェクトごとに HTML 行を作成します。 ```html #[%dw 2.0 output application/java --- payload.*Employee[0] map ((item) -> "") joinBy ""]
First Name Last Name Department Job Title Start Date Employee Type
" ++ (item.first_name default "") ++ "" ++ (item.last_name default "") ++ "" ++ (item.department default "") ++ "" ++ (item.job_title default "") ++ "" ++ (item.start_date default "") ++ "" ++ (item.employee_type default "") ++ "
``` #### [](#configuration-xml-設定-xml-2)Configuration XML (設定 XML) Mule 設定 XML では、Parse Template で設定 ​`location="/path/to/my.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml ``` #### [](#テンプレートの出力-2)テンプレートの出力 この​[例](#template2)​では、テンプレートで構築された出力が返されます。出力は、動的に作成された行と、配列内のオブジェクトのデータを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
Melba Roy Mouton Computers Assistant Chief of Research Programs 01/01/2021 mathematician
Annie Easley Software Development Technical Lead 06/02/2020 Rocket Scientist
``` ## [](#特殊文字)特殊文字 Parse Template は、テンプレート内での式の使用や、これらの式でのリテラルの使用をサポートします。テンプレートは、​`\#[`​ といったシーケンスや引用符など、一部の特殊文字を認識します。これらの文字をエスケープすることで通常の文字として扱うことができます。 - `#[an-expression]`​: テンプレート内では ​`#[]`​ を使用して式を指定します。たとえば、テンプレートの HTML 要素内で ​`#[upper("mulesoft")]`​ という式を指定すると ​`MULESOFT`​ に解決されます。空白の式 (​`#[]`​) はエラーとなりますが、​`#['']`​ や ​`#[""]`​ などの空白文字列は有効な式です。 - サブ式: 引用符で囲まれたサブ式を解決するには、サブ式を別の ​`#[]`​ で囲みます。たとえば、次のテンプレートスニペットでは、4 つの要素で同じサブ式 (​`upper("world")`​) が引用符の内部または外部に指定されています。最初の 2 つは同じ結果を返します。最後の 2 つは、サブ式が引用符内に指定されていますが、別の ​`#[]`​ で囲まれていないため、​`upper("world")`​ を処理せずにそのまま返します。 Parse Template スニペット: ```XML #['hello #[upper("world")]'] #['hello ' ++ upper("world")] #['hello upper("world")'] #['hello ++ upper("world")'] ``` 出力される値: ```XML hello WORLD hello WORLD hello upper("world") hello ++ upper("world") ``` - エスケープ文字 (​`\`​): Parse Template は、文字シーケンスの ​`#[`​ で式の開始を示します。この文字シーケンスを式として解釈せずにリテラル文字として扱うには、​`\`​ でエスケープします。たとえば、​`#[`​ は ​`#[`​ を返します。 また、式の文字列に含まれる特殊文字を通常の文字として扱いたい場合があります。式に含まれる文字列内の特殊文字をエスケープするには、特殊文字の前に ​`\`​ を付けます。特殊文字の例としては、​`#[`​ のシーケンス、引用符 (​`'`​ または ​`"`​)、アポストロフィ (​`'`​)、​`$`​ などがあります。​`\#`​ や ​`[`​ は、文字列内でこれらの 2 文字が (​`\#`​ が ​`[`​ の前に来て) 連続していない限り、エスケープする必要はありません。 Parse Template スニペット: ```XML \#[ #['abcd\#[-1234' ++ now() as String ++ '.log'] 'abc'def' #['abc\'def'] "xyz"xyz" #["xyz\"xyz"] #["abc\$DEF\#ghi\[JKL]"] ``` 出力される値: ```XML #[ abcd#[-12342020-07-06T17:20:10.683-07:00.log 'abc'def' abc'def "xyz"xyz" xyz"xyz abc$DEF#ghi[JKL] ``` 詳細は、​[「特殊文字のエスケープ」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#escape-special-characters)​を参照してください。 ## [](#関連情報)関連情報 [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.8/variable-transformer-reference) # Parse Template リファレンス Parse Template はテンプレートを処理して結果を得るために使用する Mule コンポーネントです。テンプレートはテキストとして定義され、埋め込まれた Mule 式は評価され、結果に置き換えられます。 外部ファイル参照を使用してテンプレートを設定することも、コンポーネント定義自体に埋め込むこともできます。 [例](#code_example) ## [](#parse-template-の設定)Parse Template の設定 1. Studio で、Parse Template メッセージプロセッサーをパレットからキャンバスまでドラッグします。 2. この表で説明している項目を設定します。 ![エラーメッセージが表示されている Parse Template](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/parse.png)
項目 値 説明

Content (コンテンツ)

テンプレート文字列

テンプレートとして使用する文字列。外部ファイルでテンプレートを定義する代わりに、この項目を使用してインラインで記述できます。評価され、結果に置き換えられる式を埋め込むことができます。

Display Name (表示名)

Parse Template

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。

Location (場所)

ファイルパス

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義します。

Target Variable (対象変数)

変数名

[Target Value (対象値)] で定義された式を評価した結果を保存する変数の名前。

Target Value (対象値)

式

Parse Template の実行後に評価される Mule 式。この式の結果は、[Target Variable (対象変数)] 項目で定義された名前の変数に保存されます。
Studio または Standalone Mule インスタンスで XML エディターを使用している場合: - `parse-template`​ 要素をフローに追加してから、下の表に従って設定します。 ```xml ``` `parse-template`​ 要素の属性:
要素属性 値

content​

使用するテンプレートを表す文字列であり、このテンプレートでは埋め込まれた式が評価され、その結果に置き換えられます。

location​

メッセージプロパティまたは変数から抽出された値を挿入するテンプレートとして Mule が使用するファイルの場所を定義するファイルパス。

doc:name​

アプリケーションのトランスフォーマーの一意な名前を表示するためにカスタマイズします。(注意: Mule スタンドアロンでは不要)。

target​

Parse Template が実行された後に ​targetValue​ で定義された式の結果が保存される変数の名前。

targetValue

Parse Template が実行された後に評価され、結果が ​target​ 属性で定義された名前の変数に保存される Mule 式。
## [](#code_example)例 この例では、Parse Template を使用してデータを HTML に動的に読み込みます。 - [データベースクエリの結果の動的処理](#ex_1) - [HTML 行でのデータの動的な生成](#ex_2) ### [](#ex_1)データベースクエリの結果の動的処理 この例では、データベースから従業員データを HTML テンプレートに読み込む Mule アプリケーションで Parse Template を使用します。フローは、テンプレートで構築された出力をコール元に返します。 ![Parse Template を使用した Listener から Error handling へのステップが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/parse-template-flow.png) #### [](#parse-template-への入力)Parse Template への入力 `http://localhost:8081/getEmployee?id=1234`​ など、従業員の ID を識別するクエリパラメーターを含む URI でフローを開始し、Select 操作で次の入力を Parse Template に返すとします。 ```html { "first_name": "Melba", "last_name": "Roy Mouton", "department": "Computers", "job_title": "Assistant Chief of Research Programs", "start_date": "01/01/2021", "employee_type": "mathematician" } ``` #### [](#template)テンプレートコンテンツ テンプレートでは、名前、部門、役職、開始日、および従業員種別の各値を含む項目を入力ペイロードから選択します。 ```html
First Name Last Name Department Job Title Start Date Employee Type
#[payload['first_name']] #[payload['last_name']] #[payload['department']] #[payload['job_title']] #[payload['start_date']] #[payload['employee_type']]
``` #### [](#configuration-xml-設定-xml)Configuration XML (設定 XML) この例の Mule 設定 XML では、Parse Template で設定 ​`location="src/main/resources/responseHtml.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml SELECT * FROM Employees WHERE id=#[attributes.queryParams['id']] ``` #### [](#テンプレートの出力)テンプレートの出力 この​[例](#template)​では、テンプレートで構築された出力が返されます。出力は、選択された従業員データを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
"Melba" "Roy Mouton" "Computers" "Assistant Chief of Research Programs" "01/01/2021" "mathematician"
``` ### [](#ex_2)HTML 行でのデータの動的な生成 この例では、オブジェクトの配列として表される従業員レコードで Parse Template を使用します。 ![Listener、Set Payload、Parse Template、Logger が含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/parse-template-flow2.png) #### [](#parse-template-への入力-2)Parse Template への入力 Parse Template コンポーネントは Set Payload から次のペイロードを受け取るとします。 ```html { Employee: [ { "first_name" : "Melba", "last_name" : "Roy Mouton", "department" : "Computers", "job_title" : "Assistant Chief of Research Programs", "start_date" : "01/01/2021", "employee_type" : "mathematician" }, { "first_name" : "Annie", "last_name" : "Easley", "department" : "Software Development", "job_title" : "Technical Lead", "start_date" : "06/02/2020", "employee_type" : "Rocket Scientist" } ] } ``` #### [](#template2)テンプレートコンテンツ 次のテンプレートでは、DataWeave スクリプトを使用して入力配列を反復処理し、配列内のオブジェクトごとに HTML 行を作成します。 ```html #[%dw 2.0 output application/java --- payload.*Employee[0] map ((item) -> "") joinBy ""]
First Name Last Name Department Job Title Start Date Employee Type
" ++ (item.first_name default "") ++ "" ++ (item.last_name default "") ++ "" ++ (item.department default "") ++ "" ++ (item.job_title default "") ++ "" ++ (item.start_date default "") ++ "" ++ (item.employee_type default "") ++ "
``` #### [](#configuration-xml-設定-xml-2)Configuration XML (設定 XML) Mule 設定 XML では、Parse Template で設定 ​`location="/path/to/my.template"`​ を使用してテンプレートファイルを読み込みます。 ```xml ``` #### [](#テンプレートの出力-2)テンプレートの出力 この​[例](#template2)​では、テンプレートで構築された出力が返されます。出力は、動的に作成された行と、配列内のオブジェクトのデータを含む HTML です。 ```xml
First Name Last Name Department Job Title Start Date Employee Type
Melba Roy Mouton Computers Assistant Chief of Research Programs 01/01/2021 mathematician
Annie Easley Software Development Technical Lead 06/02/2020 Rocket Scientist
``` ## [](#特殊文字)特殊文字 Parse Template は、テンプレート内での式の使用や、これらの式でのリテラルの使用をサポートします。テンプレートは、​`\#[`​ といったシーケンスや引用符など、一部の特殊文字を認識します。これらの文字をエスケープすることで通常の文字として扱うことができます。 - `#[an-expression]`​: テンプレート内では ​`#[]`​ を使用して式を指定します。たとえば、テンプレートの HTML 要素内で ​`#[upper("mulesoft")]`​ という式を指定すると ​`MULESOFT`​ に解決されます。空白の式 (​`#[]`​) はエラーとなりますが、​`#['']`​ や ​`#[""]`​ などの空白文字列は有効な式です。 - サブ式: 引用符で囲まれたサブ式を解決するには、サブ式を別の ​`#[]`​ で囲みます。たとえば、次のテンプレートスニペットでは、4 つの要素で同じサブ式 (​`upper("world")`​) が引用符の内部または外部に指定されています。最初の 2 つは同じ結果を返します。最後の 2 つは、サブ式が引用符内に指定されていますが、別の ​`#[]`​ で囲まれていないため、​`upper("world")`​ を処理せずにそのまま返します。 Parse Template スニペット: ```XML #['hello #[upper("world")]'] #['hello ' ++ upper("world")] #['hello upper("world")'] #['hello ++ upper("world")'] ``` 出力される値: ```XML hello WORLD hello WORLD hello upper("world") hello ++ upper("world") ``` - エスケープ文字 (​`\`​): Parse Template は、文字シーケンスの ​`#[`​ で式の開始を示します。この文字シーケンスを式として解釈せずにリテラル文字として扱うには、​`\`​ でエスケープします。たとえば、​`#[`​ は ​`#[`​ を返します。 また、式の文字列に含まれる特殊文字を通常の文字として扱いたい場合があります。式に含まれる文字列内の特殊文字をエスケープするには、特殊文字の前に ​`\`​ を付けます。特殊文字の例としては、​`#[`​ のシーケンス、引用符 (​`'`​ または ​`"`​)、アポストロフィ (​`'`​)、​`$`​ などがあります。​`\#`​ や ​`[`​ は、文字列内でこれらの 2 文字が (​`\#`​ が ​`[`​ の前に来て) 連続していない限り、エスケープする必要はありません。 Parse Template スニペット: ```XML \#[ #['abcd\#[-1234' ++ now() as String ++ '.log'] 'abc'def' #['abc\'def'] "xyz"xyz" #["xyz\"xyz"] #["abc\$DEF\#ghi\[JKL]"] ``` 出力される値: ```XML #[ abcd#[-12342020-07-06T17:20:10.683-07:00.log 'abc'def' abc'def "xyz"xyz" xyz"xyz abc$DEF#ghi[JKL] ``` 詳細は、​[「特殊文字のエスケープ」](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction#escape-special-characters)​を参照してください。 ## [](#関連情報)関連情報 [Set Variable トランスフォーマー](https://docs.mulesoft.com/jp/mule-runtime/4.9/variable-transformer-reference) # Poll コンポーネントの移行 Mule 3 では、​``​ 要素を使用して特定のフローを固定頻度でトリガーしました。この要素はスコープでもあり、その内部にメッセージプロセッサーが 1 つだけ含まれている必要がありました。そのプロセッサーから出力されるのは、フローが受信するメッセージです。 Mule 3 の例: Poll ```xml SELECT * FROM PERSON> ``` Mule 4 では ​``​ 要素が ​``​ 要素に置き換わりました。主な違いは次のとおりです。 - ただフローをトリガーします。スコープではなくなりました。 - 固定頻度と cron 式の両方がサポートされます。 Mule 4 の例: Scheduler ```xml SELECT * FROM PERSON> ``` ``​ 要素の詳細については、​[スケジューラーに関するドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.3/scheduler-concept)​を参照してください。 ## [](#ウォーターマークの移行)ウォーターマークの移行 ``​ 要素では、同期を補助、スケジュールするために使用される ​``​ 要素もサポートされていました。その要素はなくなりました。代わりに、​[「ウォーターマークの移行」](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-patterns-watermark)​ページを参照してください。 ## [](#qz)Quartz トランスポート Mule 3 では、​`quartz`​ トランスポートが非推奨となり、代わりに ​`poll`​ が使用されました。したがって、Mule 4 でもそのほとんどが ​`scheduler`​ に置き換わる可能性があります。 `quartz`​ トランスポートの一部の機能は Mule 4 には存在しないので、それらのユースケースを移行するには違うアプローチが必要です。 ### [](#qz_repeat_count)repeatCount Mule 4 では、​`repeatCount`​ は ​`scheduler`​ でサポートされていません。 フェッチする必要がある場合は、​[オブジェクトストア](https://docs.mulesoft.com/object-store-connector/latest/)​でカウンターを比較し保存します。 ### [](#qz_outbound_endpoint)quartz:outbound-endpoint このエンドポイントは、Mule 4 ではサポートされていません。 代替のアプローチとして、キュー (JMS や VM など) にイベントを書き込み、キューのすべてのメッセージをコンシュームして処理するスケジューラーを含む、別のフローを使用します。 ### [](#qz_job_endpoint)サポートされていない job-endpoint `job-endpoint`​ で使用されるトランスポートは、Mule 4 に移行するとき、ポーリング取得元のあるコネクタ (File Connector など) に移行できます。その場合、スケジューラー設定を直接ポーリング取得元に含めることができます。 Mule 3 の例: ポーリング取得元 ```xml ``` Mule 4 の例: ポーリング取得元 ```xml ``` ## [](#関連情報)関連情報 - [スケジューラーエンドポイント (トリガー)](https://docs.mulesoft.com/jp/mule-runtime/4.3/scheduler-concept) # Poll コンポーネントの移行 Mule 3 では、​``​ 要素を使用して特定のフローを固定頻度でトリガーしました。この要素はスコープでもあり、その内部にメッセージプロセッサーが 1 つだけ含まれている必要がありました。そのプロセッサーから出力されるのは、フローが受信するメッセージです。 Mule 3 の例: Poll ```xml SELECT * FROM PERSON> ``` Mule 4 では ​``​ 要素が ​``​ 要素に置き換わりました。主な違いは次のとおりです。 - ただフローをトリガーします。スコープではなくなりました。 - 固定頻度と cron 式の両方がサポートされます。 Mule 4 の例: Scheduler ```xml SELECT * FROM PERSON> ``` ``​ 要素の詳細については、​[スケジューラーに関するドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.4/scheduler-concept)​を参照してください。 ## [](#ウォーターマークの移行)ウォーターマークの移行 ``​ 要素では、同期を補助、スケジュールするために使用される ​``​ 要素もサポートされていました。その要素はなくなりました。代わりに、​[「ウォーターマークの移行」](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-patterns-watermark)​ページを参照してください。 ## [](#qz)Quartz トランスポート Mule 3 では、​`quartz`​ トランスポートが非推奨となり、代わりに ​`poll`​ が使用されました。したがって、Mule 4 でもそのほとんどが ​`scheduler`​ に置き換わる可能性があります。 `quartz`​ トランスポートの一部の機能は Mule 4 には存在しないので、それらのユースケースを移行するには違うアプローチが必要です。 ### [](#qz_repeat_count)repeatCount Mule 4 では、​`repeatCount`​ は ​`scheduler`​ でサポートされていません。 フェッチする必要がある場合は、​[オブジェクトストア](https://docs.mulesoft.com/object-store-connector/latest/)​でカウンターを比較し保存します。 ### [](#qz_outbound_endpoint)quartz:outbound-endpoint このエンドポイントは、Mule 4 ではサポートされていません。 代替のアプローチとして、キュー (JMS や VM など) にイベントを書き込み、キューのすべてのメッセージをコンシュームして処理するスケジューラーを含む、別のフローを使用します。 ### [](#qz_job_endpoint)サポートされていない job-endpoint `job-endpoint`​ で使用されるトランスポートは、Mule 4 に移行するとき、ポーリング取得元のあるコネクタ (File Connector など) に移行できます。その場合、スケジューラー設定を直接ポーリング取得元に含めることができます。 Mule 3 の例: ポーリング取得元 ```xml ``` Mule 4 の例: ポーリング取得元 ```xml ``` ## [](#関連情報)関連情報 - [スケジューラーエンドポイント (トリガー)](https://docs.mulesoft.com/jp/mule-runtime/4.4/scheduler-concept) # Poll コンポーネントの移行 Mule 3 では、​``​ 要素を使用して特定のフローを固定頻度でトリガーしました。この要素はスコープでもあり、その内部にメッセージプロセッサーが 1 つだけ含まれている必要がありました。そのプロセッサーから出力されるのは、フローが受信するメッセージです。 Mule 3 の例: Poll ```xml SELECT * FROM PERSON> ``` Mule 4 では ​``​ 要素が ​``​ 要素に置き換わりました。主な違いは次のとおりです。 - ただフローをトリガーします。スコープではなくなりました。 - 固定頻度と cron 式の両方がサポートされます。 Mule 4 の例: Scheduler ```xml SELECT * FROM PERSON> ``` ``​ 要素の詳細については、​[スケジューラーに関するドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.5/scheduler-concept)​を参照してください。 ## [](#ウォーターマークの移行)ウォーターマークの移行 ``​ 要素では、同期を補助、スケジュールするために使用される ​``​ 要素もサポートされていました。その要素はなくなりました。代わりに、​[「ウォーターマークの移行」](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-patterns-watermark)​ページを参照してください。 ## [](#qz)Quartz トランスポート Mule 3 では、​`quartz`​ トランスポートが非推奨となり、代わりに ​`poll`​ が使用されました。したがって、Mule 4 でもそのほとんどが ​`scheduler`​ に置き換わる可能性があります。 `quartz`​ トランスポートの一部の機能は Mule 4 には存在しないので、それらのユースケースを移行するには違うアプローチが必要です。 ### [](#qz_repeat_count)repeatCount Mule 4 では、​`repeatCount`​ は ​`scheduler`​ でサポートされていません。 フェッチする必要がある場合は、​[オブジェクトストア](https://docs.mulesoft.com/object-store-connector/latest/)​でカウンターを比較し保存します。 ### [](#qz_outbound_endpoint)quartz:outbound-endpoint このエンドポイントは、Mule 4 ではサポートされていません。 代替のアプローチとして、キュー (JMS や VM など) にイベントを書き込み、キューのすべてのメッセージをコンシュームして処理するスケジューラーを含む、別のフローを使用します。 ### [](#qz_job_endpoint)サポートされていない job-endpoint `job-endpoint`​ で使用されるトランスポートは、Mule 4 に移行するとき、ポーリング取得元のあるコネクタ (ファイルコネクタなど) に移行できます。その場合、スケジューラー設定を直接ポーリング取得元に含めることができます。 Mule 3 の例: ポーリング取得元 ```xml ``` Mule 4 の例: ポーリング取得元 ```xml ``` ## [](#関連情報)関連情報 - [スケジューラーエンドポイント (トリガー)](https://docs.mulesoft.com/jp/mule-runtime/4.5/scheduler-concept) # Poll コンポーネントの移行 Mule 3 では、​``​ 要素を使用して特定のフローを固定頻度でトリガーしました。この要素はスコープでもあり、その内部にメッセージプロセッサーが 1 つだけ含まれている必要がありました。そのプロセッサーから出力されるのは、フローが受信するメッセージです。 Mule 3 の例: Poll ```xml SELECT * FROM PERSON> ``` Mule 4 では ​``​ 要素が ​``​ 要素に置き換わりました。主な違いは次のとおりです。 - ただフローをトリガーします。スコープではなくなりました。 - 固定頻度と cron 式の両方がサポートされます。 Mule 4 の例: Scheduler ```xml SELECT * FROM PERSON> ``` ``​ 要素の詳細については、​[スケジューラーに関するドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.6/scheduler-concept)​を参照してください。 ## [](#ウォーターマークの移行)ウォーターマークの移行 ``​ 要素では、同期を補助、スケジュールするために使用される ​``​ 要素もサポートされていました。その要素はなくなりました。代わりに、​[「ウォーターマークの移行」](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-patterns-watermark)​ページを参照してください。 ## [](#qz)Quartz トランスポート Mule 3 では、​`quartz`​ トランスポートが非推奨となり、代わりに ​`poll`​ が使用されました。したがって、Mule 4 でもそのほとんどが ​`scheduler`​ に置き換わる可能性があります。 `quartz`​ トランスポートの一部の機能は Mule 4 には存在しないので、それらのユースケースを移行するには違うアプローチが必要です。 ### [](#qz_repeat_count)repeatCount Mule 4 では、​`repeatCount`​ は ​`scheduler`​ でサポートされていません。 フェッチする必要がある場合は、​[オブジェクトストア](https://docs.mulesoft.com/object-store-connector/latest/)​でカウンターを比較し保存します。 ### [](#qz_outbound_endpoint)quartz:outbound-endpoint このエンドポイントは、Mule 4 ではサポートされていません。 代替のアプローチとして、キュー (JMS や VM など) にイベントを書き込み、キューのすべてのメッセージをコンシュームして処理するスケジューラーを含む、別のフローを使用します。 ### [](#qz_job_endpoint)サポートされていない job-endpoint `job-endpoint`​ で使用されるトランスポートは、Mule 4 に移行するとき、ポーリング取得元のあるコネクタ (File Connector など) に移行できます。その場合、スケジューラー設定を直接ポーリング取得元に含めることができます。 Mule 3 の例: ポーリング取得元 ```xml ``` Mule 4 の例: ポーリング取得元 ```xml ``` ## [](#関連情報)関連情報 - [スケジューラーエンドポイント (トリガー)](https://docs.mulesoft.com/jp/mule-runtime/4.6/scheduler-concept) # Poll コンポーネントの移行 Mule 3 では、​``​ 要素を使用して特定のフローを固定頻度でトリガーしました。この要素はスコープでもあり、その内部にメッセージプロセッサーが 1 つだけ含まれている必要がありました。そのプロセッサーから出力されるのは、フローが受信するメッセージです。 Mule 3 の例: Poll ```xml SELECT * FROM PERSON> ``` Mule 4 では ​``​ 要素が ​``​ 要素に置き換わりました。主な違いは次のとおりです。 - ただフローをトリガーします。スコープではなくなりました。 - 固定頻度と cron 式の両方がサポートされます。 Mule 4 の例: Scheduler ```xml SELECT * FROM PERSON> ``` ``​ 要素の詳細については、​[スケジューラーに関するドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.7/scheduler-concept)​を参照してください。 ## [](#ウォーターマークの移行)ウォーターマークの移行 ``​ 要素では、同期を補助、スケジュールするために使用される ​``​ 要素もサポートされていました。その要素はなくなりました。代わりに、​[「ウォーターマークの移行」](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-patterns-watermark)​ページを参照してください。 ## [](#qz)Quartz トランスポート Mule 3 では、​`quartz`​ トランスポートが非推奨となり、代わりに ​`poll`​ が使用されました。したがって、Mule 4 でもそのほとんどが ​`scheduler`​ に置き換わる可能性があります。 `quartz`​ トランスポートの一部の機能は Mule 4 には存在しないので、それらのユースケースを移行するには違うアプローチが必要です。 ### [](#qz_repeat_count)repeatCount Mule 4 では、​`repeatCount`​ は ​`scheduler`​ でサポートされていません。 フェッチする必要がある場合は、​[オブジェクトストア](https://docs.mulesoft.com/object-store-connector/latest/)​でカウンターを比較し保存します。 ### [](#qz_outbound_endpoint)quartz:outbound-endpoint このエンドポイントは、Mule 4 ではサポートされていません。 代替のアプローチとして、キュー (JMS や VM など) にイベントを書き込み、キューのすべてのメッセージをコンシュームして処理するスケジューラーを含む、別のフローを使用します。 ### [](#qz_job_endpoint)サポートされていない job-endpoint `job-endpoint`​ で使用されるトランスポートは、Mule 4 に移行するとき、ポーリング取得元のあるコネクタ (File Connector など) に移行できます。その場合、スケジューラー設定を直接ポーリング取得元に含めることができます。 Mule 3 の例: ポーリング取得元 ```xml ``` Mule 4 の例: ポーリング取得元 ```xml ``` ## [](#関連情報)関連情報 - [スケジューラーエンドポイント (トリガー)](https://docs.mulesoft.com/jp/mule-runtime/4.7/scheduler-concept) # Poll コンポーネントの移行 Mule 3 では、​``​ 要素を使用して特定のフローを固定頻度でトリガーしました。この要素はスコープでもあり、その内部にメッセージプロセッサーが 1 つだけ含まれている必要がありました。そのプロセッサーから出力されるのは、フローが受信するメッセージです。 Mule 3 の例: Poll ```xml SELECT * FROM PERSON> ``` Mule 4 では ​``​ 要素が ​``​ 要素に置き換わりました。主な違いは次のとおりです。 - ただフローをトリガーします。スコープではなくなりました。 - 固定頻度と cron 式の両方がサポートされます。 Mule 4 の例: Scheduler ```xml SELECT * FROM PERSON> ``` ``​ 要素の詳細については、​[スケジューラーに関するドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.8/scheduler-concept)​を参照してください。 ## [](#ウォーターマークの移行)ウォーターマークの移行 ``​ 要素では、同期を補助、スケジュールするために使用される ​``​ 要素もサポートされていました。その要素はなくなりました。代わりに、​[「ウォーターマークの移行」](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-patterns-watermark)​ページを参照してください。 ## [](#qz)Quartz トランスポート Mule 3 では、​`quartz`​ トランスポートが非推奨となり、代わりに ​`poll`​ が使用されました。したがって、Mule 4 でもそのほとんどが ​`scheduler`​ に置き換わる可能性があります。 `quartz`​ トランスポートの一部の機能は Mule 4 には存在しないので、それらのユースケースを移行するには違うアプローチが必要です。 ### [](#qz_repeat_count)repeatCount Mule 4 では、​`repeatCount`​ は ​`scheduler`​ でサポートされていません。 フェッチする必要がある場合は、​[オブジェクトストア](https://docs.mulesoft.com/object-store-connector/latest/)​でカウンターを比較し保存します。 ### [](#qz_outbound_endpoint)quartz:outbound-endpoint このエンドポイントは、Mule 4 ではサポートされていません。 代替のアプローチとして、キュー (JMS や VM など) にイベントを書き込み、キューのすべてのメッセージをコンシュームして処理するスケジューラーを含む、別のフローを使用します。 ### [](#qz_job_endpoint)サポートされていない job-endpoint `job-endpoint`​ で使用されるトランスポートは、Mule 4 に移行するとき、ポーリング取得元のあるコネクタ (File Connector など) に移行できます。その場合、スケジューラー設定を直接ポーリング取得元に含めることができます。 Mule 3 の例: ポーリング取得元 ```xml ``` Mule 4 の例: ポーリング取得元 ```xml ``` ## [](#関連情報)関連情報 - [スケジューラーエンドポイント (トリガー)](https://docs.mulesoft.com/jp/mule-runtime/4.8/scheduler-concept) # Poll コンポーネントの移行 Mule 3 では、​``​ 要素を使用して特定のフローを固定頻度でトリガーしました。この要素はスコープでもあり、その内部にメッセージプロセッサーが 1 つだけ含まれている必要がありました。そのプロセッサーから出力されるのは、フローが受信するメッセージです。 Mule 3 の例: Poll ```xml SELECT * FROM PERSON> ``` Mule 4 では ​``​ 要素が ​``​ 要素に置き換わりました。主な違いは次のとおりです。 - ただフローをトリガーします。スコープではなくなりました。 - 固定頻度と cron 式の両方がサポートされます。 Mule 4 の例: Scheduler ```xml SELECT * FROM PERSON> ``` ``​ 要素の詳細については、​[スケジューラーに関するドキュメント](https://docs.mulesoft.com/jp/mule-runtime/4.9/scheduler-concept)​を参照してください。 ## [](#ウォーターマークの移行)ウォーターマークの移行 ``​ 要素では、同期を補助、スケジュールするために使用される ​``​ 要素もサポートされていました。その要素はなくなりました。代わりに、​[「ウォーターマークの移行」](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-patterns-watermark)​ページを参照してください。 ## [](#qz)Quartz トランスポート Mule 3 では、​`quartz`​ トランスポートが非推奨となり、代わりに ​`poll`​ が使用されました。したがって、Mule 4 でもそのほとんどが ​`scheduler`​ に置き換わる可能性があります。 `quartz`​ トランスポートの一部の機能は Mule 4 には存在しないので、それらのユースケースを移行するには違うアプローチが必要です。 ### [](#qz_repeat_count)repeatCount Mule 4 では、​`repeatCount`​ は ​`scheduler`​ でサポートされていません。 フェッチする必要がある場合は、​[オブジェクトストア](https://docs.mulesoft.com/object-store-connector/latest/)​でカウンターを比較し保存します。 ### [](#qz_outbound_endpoint)quartz:outbound-endpoint このエンドポイントは、Mule 4 ではサポートされていません。 代替のアプローチとして、キュー (JMS や VM など) にイベントを書き込み、キューのすべてのメッセージをコンシュームして処理するスケジューラーを含む、別のフローを使用します。 ### [](#qz_job_endpoint)サポートされていない job-endpoint `job-endpoint`​ で使用されるトランスポートは、Mule 4 に移行するとき、ポーリング取得元のあるコネクタ (File Connector など) に移行できます。その場合、スケジューラー設定を直接ポーリング取得元に含めることができます。 Mule 3 の例: ポーリング取得元 ```xml ``` Mule 4 の例: ポーリング取得元 ```xml ``` ## [](#関連情報)関連情報 - [スケジューラーエンドポイント (トリガー)](https://docs.mulesoft.com/jp/mule-runtime/4.9/scheduler-concept) # Raise Error コンポーネント このコアコンポーネントは、障害が発生したかのように Mule エラーを生成し、その説明および種別をカスタマイズできます。 このコンポーネントは、次のエラーを生成するためにのみ使用します。 - `MULE:SECURITY`​、​`MULE:CONNECTIVITY`​ などのコアランタイムエラー。 - カスタムエラー種別。
別のコネクタや ​FILE:FILE_NOT_FOUND​ や ​JSON:INVALID_SCHEMA​ などのモジュールからエラーを発生させることはできません。コネクタの既存の名前空間を使用することはできません。
## [](#エラー生成設定)エラー生成設定
項目 値 説明 例

説明

String (文字列) または DataWeave 式

エラーの説明を指定します。

description="Error description message."​

型

String (文字列)

エラーの種別を指定します。

type="CUSTOM:CUSTOM_ERROR"
## [](#コアランタイムエラー生成種別)コアランタイムエラー生成種別 コアランタイムエラー種別では、暗黙的な名前空間および識別子を使用する必要があり、エラーの説明メッセージのみカスタマイズできます。次に例を示します。 ```xml ``` ## [](#カスタムエラー生成種別)カスタムエラー生成種別 カスタムエラー種別では、新しい名前空間を宣言します。エラー種別の名前空間は、エラーの起源を特定するのに役立ちます。次に例を示します。 ```xml ``` コネクタまたはモジュールでは定義済みの名前空間があるため、これらから既存の名前空間を使用することはできません。 `raise-error`​ で使用することでカスタム名前空間を宣言した場合は、他の ​`raise-error`​ コンポーネントおよびカスタム種別で使用できます。 ## [](#例)例 次の運転教習プラットフォームの例では、ユーザーが運転可能な 16 歳以上であることを確認します。ユーザーが 16 歳未満の年齢を入力すると、フローで ​`PRECONDITIONS:INCORRECT_AGE`​ エラーが生成されます。 - Choice Router コンポーネントにより、条件処理がフローに追加されます。 - 要求で送信された age パラメーターが 16 ​`[http://localhost:8081/test?age=15](http://localhost:8081/test?age=15)`​ 未満の場合、Raise Error コンポーネントでエラー種別 ​`PRECONDITIONS:INCORRECT_AGE`​ と説明 ​`Minimum age of 16 required to drive`​ が生成されます。 - 次に、On-Error Continue コンポーネントでエラー ​`PRECONDITIONS:INCORRECT_AGE`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってエラーメッセージ ​`Minimum age of 16 required to drive`​ が記録されます。 - 要求 ​`[http://localhost:8081/test?age=17](http://localhost:8081/test?age=17)`​ の age パラメーターが 16 より大きい場合、Logger コンポーネントでデフォルトのメッセージ「​`User age above 16 years.`​」が返されます。​\` Allowed to drive\`​ が返されます。 - 要求 ​`[http://localhost:8081/test](http://localhost:8081/test)`​ で age パラメーターが渡されない場合、式 ​`#[message.attributes.queryParams.age < 16]`​ を評価しようとしたときに Choice コンポーネントで自動的に ​`MULE:EXPRESSION`​ エラーが生成されます。これは、要求で age パラメーターが指定されなかったことで、その値が null になっているためです。 - 次に、On-Error Continue コンポーネントでエラー ​`MULE:EXPRESSION`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってメッセージ ​`The parameter age is missing or invalid`​ が返されます。 フローの XML 設定: ```xml ``` `[https://unsecurebank.com/balance](https://unsecurebank.com/balance)`​ に対して要求を行ったときに勘定残高を返す API を考えます。 次の例では、この API に対する要求を行って値を ​`balance`​ 変数に保存し、​`payload.amount`​ と比較して操作が可能かどうかを判断します。 振込金額が利用可能残高を超えると Choice Router で ​`ACCOUNT:INSUFFICIENT_FUNDS`​ エラーが生成され、振込が行われないようにします。さらに、失敗の詳細が含まれる式を提供することで、動的な説明が生成されます。 フローの XML 設定: ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/on-error-scope-concept) # Raise Error コンポーネント このコアコンポーネントは、障害が発生したかのように Mule エラーを生成し、その説明および種別をカスタマイズできます。 このコンポーネントは、次のエラーを生成するためにのみ使用します。 - `MULE:SECURITY`​、​`MULE:CONNECTIVITY`​ などのコアランタイムエラー。 - カスタムエラー種別。
別のコネクタや ​FILE:FILE_NOT_FOUND​ や ​JSON:INVALID_SCHEMA​ などのモジュールからエラーを発生させることはできません。コネクタの既存の名前空間を使用することはできません。
## [](#エラー生成設定)エラー生成設定
項目 値 説明 例

説明

String (文字列) または DataWeave 式

エラーの説明を指定します。

description="Error description message."​

型

String (文字列)

エラーの種別を指定します。

type="CUSTOM:CUSTOM_ERROR"
## [](#コアランタイムエラー生成種別)コアランタイムエラー生成種別 コアランタイムエラー種別では、暗黙的な名前空間および識別子を使用する必要があり、エラーの説明メッセージのみカスタマイズできます。次に例を示します。 ```xml ``` ## [](#カスタムエラー生成種別)カスタムエラー生成種別 カスタムエラー種別では、新しい名前空間を宣言します。エラー種別の名前空間は、エラーの起源を特定するのに役立ちます。次に例を示します。 ```xml ``` コネクタまたはモジュールでは定義済みの名前空間があるため、これらから既存の名前空間を使用することはできません。 `raise-error`​ で使用することでカスタム名前空間を宣言した場合は、他の ​`raise-error`​ コンポーネントおよびカスタム種別で使用できます。 ## [](#例)例 次の運転教習プラットフォームの例では、ユーザーが運転可能な 16 歳以上であることを確認します。ユーザーが 16 歳未満の年齢を入力すると、フローで ​`PRECONDITIONS:INCORRECT_AGE`​ エラーが生成されます。 - Choice Router コンポーネントにより、条件処理がフローに追加されます。 - 要求で送信された age パラメーターが 16 ​`[http://localhost:8081/test?age=15](http://localhost:8081/test?age=15)`​ 未満の場合、Raise Error コンポーネントでエラー種別 ​`PRECONDITIONS:INCORRECT_AGE`​ と説明 ​`Minimum age of 16 required to drive`​ が生成されます。 - 次に、On-Error Continue コンポーネントでエラー ​`PRECONDITIONS:INCORRECT_AGE`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってエラーメッセージ ​`Minimum age of 16 required to drive`​ が記録されます。 - 要求 ​`[http://localhost:8081/test?age=17](http://localhost:8081/test?age=17)`​ の age パラメーターが 16 より大きい場合、Logger コンポーネントでデフォルトのメッセージ「​`User age above 16 years.`​」が返されます。​\` Allowed to drive\`​ が返されます。 - 要求 ​`[http://localhost:8081/test](http://localhost:8081/test)`​ で age パラメーターが渡されない場合、式 ​`#[message.attributes.queryParams.age < 16]`​ を評価しようとしたときに Choice コンポーネントで自動的に ​`MULE:EXPRESSION`​ エラーが生成されます。これは、要求で age パラメーターが指定されなかったことで、その値が null になっているためです。 - 次に、On-Error Continue コンポーネントでエラー ​`MULE:EXPRESSION`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってメッセージ ​`The parameter age is missing or invalid`​ が返されます。 フローの XML 設定: ```xml ``` `[https://unsecurebank.com/balance](https://unsecurebank.com/balance)`​ に対して要求を行ったときに勘定残高を返す API を考えます。 次の例では、この API に対する要求を行って値を ​`balance`​ 変数に保存し、​`payload.amount`​ と比較して操作が可能かどうかを判断します。 振込金額が利用可能残高を超えると Choice Router で ​`ACCOUNT:INSUFFICIENT_FUNDS`​ エラーが生成され、振込が行われないようにします。さらに、失敗の詳細が含まれる式を提供することで、動的な説明が生成されます。 フローの XML 設定: ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/on-error-scope-concept) # Raise Error コンポーネント このコアコンポーネントは、障害が発生したかのように Mule エラーを生成し、その説明および種別をカスタマイズできます。 このコンポーネントは、次のエラーを生成するためにのみ使用します。 - `MULE:SECURITY`​、​`MULE:CONNECTIVITY`​ などのコアランタイムエラー。 - カスタムエラー種別。
別のコネクタや ​FILE:FILE_NOT_FOUND​ や ​JSON:INVALID_SCHEMA​ などのモジュールからエラーを発生させることはできません。コネクタの既存の名前空間を使用することはできません。
## [](#エラー生成設定)エラー生成設定
項目 値 説明 例

説明

String (文字列) または DataWeave 式

エラーの説明を指定します。

description="Error description message."​

Type (種別)

String (文字列)

エラーの種別を指定します。

type="CUSTOM:CUSTOM_ERROR"
## [](#コアランタイムエラー生成種別)コアランタイムエラー生成種別 コアランタイムエラー種別では、暗黙的な名前空間および識別子を使用する必要があり、エラーの説明メッセージのみカスタマイズできます。次に例を示します。 ```xml ``` ## [](#カスタムエラー生成種別)カスタムエラー生成種別 カスタムエラー種別では、新しい名前空間を宣言します。エラー種別の名前空間は、エラーの起源を特定するのに役立ちます。次に例を示します。 ```xml ``` コネクタまたはモジュールでは定義済みの名前空間があるため、これらから既存の名前空間を使用することはできません。 `raise-error`​ で使用することでカスタム名前空間を宣言した場合は、他の ​`raise-error`​ コンポーネントおよびカスタム種別で使用できます。 ## [](#例)例 次の運転教習プラットフォームの例では、ユーザーが運転可能な 16 歳以上であることを確認します。ユーザーが 16 歳未満の年齢を入力すると、フローで ​`PRECONDITIONS:INCORRECT_AGE`​ エラーが生成されます。 - Choice Router コンポーネントにより、条件処理がフローに追加されます。 - 要求で送信された age パラメーターが 16 ​`[http://localhost:8081/test?age=15](http://localhost:8081/test?age=15)`​ 未満の場合、Raise Error コンポーネントでエラー種別 ​`PRECONDITIONS:INCORRECT_AGE`​ と説明 ​`Minimum age of 16 required to drive`​ が生成されます。 - 次に、On-Error Continue コンポーネントでエラー ​`PRECONDITIONS:INCORRECT_AGE`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってエラーメッセージ ​`Minimum age of 16 required to drive`​ が記録されます。 - 要求 ​`[http://localhost:8081/test?age=17](http://localhost:8081/test?age=17)`​ の age パラメーターが 16 より大きい場合、Logger コンポーネントで次のデフォルトのメッセージが返されます。​`User age above 16 years. Allowed to drive`​ が返されます。 - 要求 ​`[http://localhost:8081/test](http://localhost:8081/test)`​ で age パラメーターが渡されない場合、式 ​`#[message.attributes.queryParams.age < 16]`​ を評価しようとしたときに Choice コンポーネントで自動的に ​`MULE:EXPRESSION`​ エラーが生成されます。これは、要求で age パラメーターが指定されなかったことで、その値が null になっているためです。 - 次に、On-Error Continue コンポーネントでエラー ​`MULE:EXPRESSION`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってメッセージ ​`The parameter age is missing or invalid`​ が返されます。 フローの XML 設定: ```xml ``` `[https://unsecurebank.com/balance](https://unsecurebank.com/balance)`​ に対して要求を行ったときに勘定残高を返す API を考えます。 次の例では、この API に対する要求を行って値を ​`balance`​ 変数に保存し、​`payload.amount`​ と比較して操作が可能かどうかを判断します。 振込金額が利用可能残高を超えると Choice Router で ​`ACCOUNT:INSUFFICIENT_FUNDS`​ エラーが生成され、振込が行われないようにします。さらに、失敗の詳細が含まれる式を提供することで、動的な説明が生成されます。 フローの XML 設定: ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/on-error-scope-concept) # Raise Error コンポーネント このコアコンポーネントは、障害が発生したかのように Mule エラーを生成し、その説明および種別をカスタマイズできます。 このコンポーネントは、次のエラーを生成するためにのみ使用します。 - `MULE:SECURITY`​、​`MULE:CONNECTIVITY`​ などのコアランタイムエラー。 - カスタムエラー種別。
別のコネクタや ​FILE:FILE_NOT_FOUND​ や ​JSON:INVALID_SCHEMA​ などのモジュールからエラーを発生させることはできません。コネクタの既存の名前空間を使用することはできません。
## [](#エラー生成設定)エラー生成設定
項目 値 説明 例

説明

String (文字列) または DataWeave 式

エラーの説明を指定します。

description="Error description message."​

型

String (文字列)

エラーの種別を指定します。

type="CUSTOM:CUSTOM_ERROR"
## [](#コアランタイムエラー生成種別)コアランタイムエラー生成種別 コアランタイムエラー種別では、暗黙的な名前空間および識別子を使用する必要があり、エラーの説明メッセージのみカスタマイズできます。次に例を示します。 ```xml ``` ## [](#カスタムエラー生成種別)カスタムエラー生成種別 カスタムエラー種別では、新しい名前空間を宣言します。エラー種別の名前空間は、エラーの起源を特定するのに役立ちます。次に例を示します。 ```xml ``` コネクタまたはモジュールでは定義済みの名前空間があるため、これらから既存の名前空間を使用することはできません。 `raise-error`​ で使用することでカスタム名前空間を宣言した場合は、他の ​`raise-error`​ コンポーネントおよびカスタム種別で使用できます。 ## [](#例)例 次の運転教習プラットフォームの例では、ユーザーが運転可能な 16 歳以上であることを確認します。ユーザーが 16 歳未満の年齢を入力すると、フローで ​`PRECONDITIONS:INCORRECT_AGE`​ エラーが生成されます。 - Choice Router コンポーネントにより、条件処理がフローに追加されます。 - 要求で送信された age パラメーターが 16 ​`[http://localhost:8081/test?age=15](http://localhost:8081/test?age=15)`​ 未満の場合、Raise Error コンポーネントでエラー種別 ​`PRECONDITIONS:INCORRECT_AGE`​ と説明 ​`Minimum age of 16 required to drive`​ が生成されます。 - 次に、On-Error Continue コンポーネントでエラー ​`PRECONDITIONS:INCORRECT_AGE`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってエラーメッセージ ​`Minimum age of 16 required to drive`​ が記録されます。 - 要求 ​`[http://localhost:8081/test?age=17](http://localhost:8081/test?age=17)`​ の age パラメーターが 16 より大きい場合、Logger コンポーネントでデフォルトのメッセージ「​`User age above 16 years.`​」が返されます。​\` Allowed to drive\`​ が返されます。 - 要求 ​`[http://localhost:8081/test](http://localhost:8081/test)`​ で age パラメーターが渡されない場合、式 ​`#[message.attributes.queryParams.age < 16]`​ を評価しようとしたときに Choice コンポーネントで自動的に ​`MULE:EXPRESSION`​ エラーが生成されます。これは、要求で age パラメーターが指定されなかったことで、その値が null になっているためです。 - 次に、On-Error Continue コンポーネントでエラー ​`MULE:EXPRESSION`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってメッセージ ​`The parameter age is missing or invalid`​ が返されます。 フローの XML 設定: ```xml ``` `[https://unsecurebank.com/balance](https://unsecurebank.com/balance)`​ に対して要求を行ったときに勘定残高を返す API を考えます。 次の例では、この API に対する要求を行って値を ​`balance`​ 変数に保存し、​`payload.amount`​ と比較して操作が可能かどうかを判断します。 振込金額が利用可能残高を超えると Choice Router で ​`ACCOUNT:INSUFFICIENT_FUNDS`​ エラーが生成され、振込が行われないようにします。さらに、失敗の詳細が含まれる式を提供することで、動的な説明が生成されます。 フローの XML 設定: ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/on-error-scope-concept) # Raise Error コンポーネント このコアコンポーネントは、障害が発生したかのように Mule エラーを生成し、その説明および種別をカスタマイズできます。 このコンポーネントは、次のエラーを生成するためにのみ使用します。 - `MULE:SECURITY`​、​`MULE:CONNECTIVITY`​ などのコアランタイムエラー。 - カスタムエラー種別。
別のコネクタや ​FILE:FILE_NOT_FOUND​ や ​JSON:INVALID_SCHEMA​ などのモジュールからエラーを発生させることはできません。コネクタの既存の名前空間を使用することはできません。
## [](#エラー生成設定)エラー生成設定
項目 値 説明 例

説明

String (文字列) または DataWeave 式

エラーの説明を指定します。

description="Error description message."​

型

String (文字列)

エラーの種別を指定します。

type="CUSTOM:CUSTOM_ERROR"
## [](#コアランタイムエラー生成種別)コアランタイムエラー生成種別 コアランタイムエラー種別では、暗黙的な名前空間および識別子を使用する必要があり、エラーの説明メッセージのみカスタマイズできます。次に例を示します。 ```xml ``` ## [](#カスタムエラー生成種別)カスタムエラー生成種別 カスタムエラー種別では、新しい名前空間を宣言します。エラー種別の名前空間は、エラーの起源を特定するのに役立ちます。次に例を示します。 ```xml ``` コネクタまたはモジュールでは定義済みの名前空間があるため、これらから既存の名前空間を使用することはできません。 `raise-error`​ で使用することでカスタム名前空間を宣言した場合は、他の ​`raise-error`​ コンポーネントおよびカスタム種別で使用できます。 ## [](#例)例 次の運転教習プラットフォームの例では、ユーザーが運転可能な 16 歳以上であることを確認します。ユーザーが 16 歳未満の年齢を入力すると、フローで ​`PRECONDITIONS:INCORRECT_AGE`​ エラーが生成されます。 - Choice Router コンポーネントにより、条件処理がフローに追加されます。 - 要求で送信された age パラメーターが 16 ​`[http://localhost:8081/test?age=15](http://localhost:8081/test?age=15)`​ 未満の場合、Raise Error コンポーネントでエラー種別 ​`PRECONDITIONS:INCORRECT_AGE`​ と説明 ​`Minimum age of 16 required to drive`​ が生成されます。 - 次に、On-Error Continue コンポーネントでエラー ​`PRECONDITIONS:INCORRECT_AGE`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってエラーメッセージ ​`Minimum age of 16 required to drive`​ が記録されます。 - 要求 ​`[http://localhost:8081/test?age=17](http://localhost:8081/test?age=17)`​ の age パラメーターが 16 より大きい場合、Logger コンポーネントでデフォルトのメッセージ「​`User age above 16 years.`​」が返されます。​\` Allowed to drive\`​ が返されます。 - 要求 ​`[http://localhost:8081/test](http://localhost:8081/test)`​ で age パラメーターが渡されない場合、式 ​`#[message.attributes.queryParams.age < 16]`​ を評価しようとしたときに Choice コンポーネントで自動的に ​`MULE:EXPRESSION`​ エラーが生成されます。これは、要求で age パラメーターが指定されなかったことで、その値が null になっているためです。 - 次に、On-Error Continue コンポーネントでエラー ​`MULE:EXPRESSION`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってメッセージ ​`The parameter age is missing or invalid`​ が返されます。 フローの XML 設定: ```xml ``` `[https://unsecurebank.com/balance](https://unsecurebank.com/balance)`​ に対して要求を行ったときに勘定残高を返す API を考えます。 次の例では、この API に対する要求を行って値を ​`balance`​ 変数に保存し、​`payload.amount`​ と比較して操作が可能かどうかを判断します。 振込金額が利用可能残高を超えると Choice Router で ​`ACCOUNT:INSUFFICIENT_FUNDS`​ エラーが生成され、振込が行われないようにします。さらに、失敗の詳細が含まれる式を提供することで、動的な説明が生成されます。 フローの XML 設定: ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/on-error-scope-concept) # Raise Error コンポーネント このコアコンポーネントは、障害が発生したかのように Mule エラーを生成し、その説明および種別をカスタマイズできます。 このコンポーネントは、次のエラーを生成するためにのみ使用します。 - `MULE:SECURITY`​、​`MULE:CONNECTIVITY`​ などのコアランタイムエラー。 - カスタムエラー種別。
別のコネクタや ​FILE:FILE_NOT_FOUND​ や ​JSON:INVALID_SCHEMA​ などのモジュールからエラーを発生させることはできません。コネクタの既存の名前空間を使用することはできません。
## [](#エラー生成設定)エラー生成設定
項目 値 説明 例

説明

String (文字列) または DataWeave 式

エラーの説明を指定します。

description="Error description message."​

型

String (文字列)

エラーの種別を指定します。

type="CUSTOM:CUSTOM_ERROR"
## [](#コアランタイムエラー生成種別)コアランタイムエラー生成種別 コアランタイムエラー種別では、暗黙的な名前空間および識別子を使用する必要があり、エラーの説明メッセージのみカスタマイズできます。次に例を示します。 ```xml ``` ## [](#カスタムエラー生成種別)カスタムエラー生成種別 カスタムエラー種別では、新しい名前空間を宣言します。エラー種別の名前空間は、エラーの起源を特定するのに役立ちます。次に例を示します。 ```xml ``` コネクタまたはモジュールでは定義済みの名前空間があるため、これらから既存の名前空間を使用することはできません。 `raise-error`​ で使用することでカスタム名前空間を宣言した場合は、他の ​`raise-error`​ コンポーネントおよびカスタム種別で使用できます。 ## [](#例)例 次の運転教習プラットフォームの例では、ユーザーが運転可能な 16 歳以上であることを確認します。ユーザーが 16 歳未満の年齢を入力すると、フローで ​`PRECONDITIONS:INCORRECT_AGE`​ エラーが生成されます。 - Choice Router コンポーネントにより、条件処理がフローに追加されます。 - 要求で送信された age パラメーターが 16 ​`[http://localhost:8081/test?age=15](http://localhost:8081/test?age=15)`​ 未満の場合、Raise Error コンポーネントでエラー種別 ​`PRECONDITIONS:INCORRECT_AGE`​ と説明 ​`Minimum age of 16 required to drive`​ が生成されます。 - 次に、On-Error Continue コンポーネントでエラー ​`PRECONDITIONS:INCORRECT_AGE`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってエラーメッセージ ​`Minimum age of 16 required to drive`​ が記録されます。 - 要求 ​`[http://localhost:8081/test?age=17](http://localhost:8081/test?age=17)`​ の age パラメーターが 16 より大きい場合、Logger コンポーネントでデフォルトのメッセージ「​`User age above 16 years.`​」が返されます。​\` Allowed to drive\`​ が返されます。 - 要求 ​`[http://localhost:8081/test](http://localhost:8081/test)`​ で age パラメーターが渡されない場合、式 ​`#[message.attributes.queryParams.age < 16]`​ を評価しようとしたときに Choice コンポーネントで自動的に ​`MULE:EXPRESSION`​ エラーが生成されます。これは、要求で age パラメーターが指定されなかったことで、その値が null になっているためです。 - 次に、On-Error Continue コンポーネントでエラー ​`MULE:EXPRESSION`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってメッセージ ​`The parameter age is missing or invalid`​ が返されます。 フローの XML 設定: ```xml ``` `[https://unsecurebank.com/balance](https://unsecurebank.com/balance)`​ に対して要求を行ったときに勘定残高を返す API を考えます。 次の例では、この API に対する要求を行って値を ​`balance`​ 変数に保存し、​`payload.amount`​ と比較して操作が可能かどうかを判断します。 振込金額が利用可能残高を超えると Choice Router で ​`ACCOUNT:INSUFFICIENT_FUNDS`​ エラーが生成され、振込が行われないようにします。さらに、失敗の詳細が含まれる式を提供することで、動的な説明が生成されます。 フローの XML 設定: ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/on-error-scope-concept) # Raise Error コンポーネント このコアコンポーネントは、障害が発生したかのように Mule エラーを生成し、その説明および種別をカスタマイズできます。 このコンポーネントは、次のエラーを生成するためにのみ使用します。 - `MULE:SECURITY`​、​`MULE:CONNECTIVITY`​ などのコアランタイムエラー。 - カスタムエラー種別。
別のコネクタや ​FILE:FILE_NOT_FOUND​ や ​JSON:INVALID_SCHEMA​ などのモジュールからエラーを発生させることはできません。コネクタの既存の名前空間を使用することはできません。
## [](#エラー生成設定)エラー生成設定
項目 値 説明 例

説明

String (文字列) または DataWeave 式

エラーの説明を指定します。

description="Error description message."​

型

String (文字列)

エラーの種別を指定します。

type="CUSTOM:CUSTOM_ERROR"
## [](#コアランタイムエラー生成種別)コアランタイムエラー生成種別 コアランタイムエラー種別では、暗黙的な名前空間および識別子を使用する必要があり、エラーの説明メッセージのみカスタマイズできます。次に例を示します。 ```xml ``` ## [](#カスタムエラー生成種別)カスタムエラー生成種別 カスタムエラー種別では、新しい名前空間を宣言します。エラー種別の名前空間は、エラーの起源を特定するのに役立ちます。次に例を示します。 ```xml ``` コネクタまたはモジュールでは定義済みの名前空間があるため、これらから既存の名前空間を使用することはできません。 `raise-error`​ で使用することでカスタム名前空間を宣言した場合は、他の ​`raise-error`​ コンポーネントおよびカスタム種別で使用できます。 ## [](#例)例 次の運転教習プラットフォームの例では、ユーザーが運転可能な 16 歳以上であることを確認します。ユーザーが 16 歳未満の年齢を入力すると、フローで ​`PRECONDITIONS:INCORRECT_AGE`​ エラーが生成されます。 - Choice Router コンポーネントにより、条件処理がフローに追加されます。 - 要求で送信された age パラメーターが 16 ​`[http://localhost:8081/test?age=15](http://localhost:8081/test?age=15)`​ 未満の場合、Raise Error コンポーネントでエラー種別 ​`PRECONDITIONS:INCORRECT_AGE`​ と説明 ​`Minimum age of 16 required to drive`​ が生成されます。 - 次に、On-Error Continue コンポーネントでエラー ​`PRECONDITIONS:INCORRECT_AGE`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってエラーメッセージ ​`Minimum age of 16 required to drive`​ が記録されます。 - 要求 ​`[http://localhost:8081/test?age=17](http://localhost:8081/test?age=17)`​ の age パラメーターが 16 より大きい場合、Logger コンポーネントでデフォルトのメッセージ「​`User age above 16 years.`​」が返されます。​\` Allowed to drive\`​ が返されます。 - 要求 ​`[http://localhost:8081/test](http://localhost:8081/test)`​ で age パラメーターが渡されない場合、式 ​`#[message.attributes.queryParams.age < 16]`​ を評価しようとしたときに Choice コンポーネントで自動的に ​`MULE:EXPRESSION`​ エラーが生成されます。これは、要求で age パラメーターが指定されなかったことで、その値が null になっているためです。 - 次に、On-Error Continue コンポーネントでエラー ​`MULE:EXPRESSION`​ の種別が照合され、そのスコープ内で Logger コンポーネントが実行されます。Logger コンポーネントによってメッセージ ​`The parameter age is missing or invalid`​ が返されます。 フローの XML 設定: ```xml ``` `[https://unsecurebank.com/balance](https://unsecurebank.com/balance)`​ に対して要求を行ったときに勘定残高を返す API を考えます。 次の例では、この API に対する要求を行って値を ​`balance`​ 変数に保存し、​`payload.amount`​ と比較して操作が可能かどうかを判断します。 振込金額が利用可能残高を超えると Choice Router で ​`ACCOUNT:INSUFFICIENT_FUNDS`​ エラーが生成され、振込が行われないようにします。さらに、失敗の詳細が含まれる式を提供することで、動的な説明が生成されます。 フローの XML 設定: ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/on-error-scope-concept) # Remove Variable トランスフォーマー Remove Variable コンポーネントは、変数名を受け入れて、Mule イベントから変数を削除します。
項目 説明

Display Name (表示名) (​doc:name​)

このコンポーネントの一意の名前をフローで表示するようにカスタマイズします。デフォルトは Remove Variable です。

Name (名前) (​variableName​)

削除する変数の名前。
## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.3/target-variables) # Remove Variable トランスフォーマー Remove Variable コンポーネントは、Mule 変数名を受け入れて、Mule イベントから変数を削除します。
項目 XML 説明

Display Name (表示名)

doc:name

このコンポーネントの一意の名前を Anypoint Studio で表示するようにカスタマイズします。デフォルトは ​Remove Variable​ です。

Name (名前)

variableName

削除する変数の名前。変数がフローに存在しない場合、コンポーネントによって警告がログに記録されます (​WARN​)。存在しない変数の値にアクセスしようとすると、​null​ 値が返されます。​[example]​を参照してください。
## [](#例)例 次の基本的な例は、フローから Mule 変数を削除する方法を示しています。 ```xml ``` フローでは次のプロセッサーが使用されます。 - Scheduler コンポーネントによってフローがトリガーされます。 - Set Variable によって Mule 変数 (​`myMuleVar`​) が作成されます。 - フローの最初の Logger によって変数の値 (​`"value of my Mule variable"`​) が出力されます。 - Remove Variable によって Mule イベントから変数を削除するための変数 (​`variableName="myMuleVar"`​) の名前が含まれる文字列が提供されます。 - Mule 変数が存在しなくなっているため、2 番目の Logger によって ​`null`​ が出力されます。 - Mule イベントに存在していない Mule 変数 (​`banana`​) の削除を試みるため、2 番目の Remove Variable によって ​`WARN`​ メッセージがログに記録されます。 次の例は、このフローの実行のログを示しています。 ```logs INFO 2022-12-15 08:33:20,151 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] PRINT VALUE OF VARIABLE: "value of my Mule variable" INFO 2022-12-15 08:33:20,155 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ATTEMPT TO PRINT VALUE OF REMOVED VARIABLE: null WARN 2022-12-15 08:33:20,156 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ...RemoveFlowVariableProcessor: There is no variable named 'banana'. Check the 'variableName' parameter in the 'remove-variable' component at remove-variable-ex/processors/4 ``` ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.4/target-variables) # Remove Variable トランスフォーマー Remove Variable コンポーネントは、Mule 変数名を受け入れて、Mule イベントから変数を削除します。
項目 XML 説明

Display Name (表示名)

doc:name

このコンポーネントの一意の名前を Anypoint Studio で表示するようにカスタマイズします。デフォルトは ​Remove Variable​ です。

Name (名前)

variableName

削除する変数の名前。変数がフローに存在しない場合、コンポーネントによって警告がログに記録されます (​WARN​)。存在しない変数の値にアクセスしようとすると、​null​ 値が返されます。「​例​」を参照してください。
## [](#例)例 次の基本的な例は、フローから Mule 変数を削除する方法を示しています。 ```xml ``` フローでは次のプロセッサーが使用されます。 - Scheduler コンポーネントによってフローがトリガーされます。 - Set Variable によって Mule 変数 (​`myMuleVar`​) が作成されます。 - フローの最初の Logger によって変数の値 (​`"value of my Mule variable"`​) が出力されます。 - Remove Variable によって Mule イベントから変数を削除するための変数 (​`variableName="myMuleVar"`​) の名前が含まれる文字列が提供されます。 - Mule 変数が存在しなくなっているため、2 番目の Logger によって ​`null`​ が出力されます。 - Mule イベントに存在していない Mule 変数 (​`banana`​) の削除を試みるため、2 番目の Remove Variable によって ​`WARN`​ メッセージがログに記録されます。 次の例は、このフローの実行のログを示しています。 ```logs INFO 2022-12-15 08:33:20,151 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] PRINT VALUE OF VARIABLE: "value of my Mule variable" INFO 2022-12-15 08:33:20,155 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ATTEMPT TO PRINT VALUE OF REMOVED VARIABLE: null WARN 2022-12-15 08:33:20,156 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ...RemoveFlowVariableProcessor: There is no variable named 'banana'. Check the 'variableName' parameter in the 'remove-variable' component at remove-variable-ex/processors/4 ``` ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.5/target-variables) # Remove Variable トランスフォーマー Remove Variable コンポーネントは、Mule 変数名を受け入れて、Mule イベントから変数を削除します。
項目 XML 説明

Display Name (表示名)

doc:name

このコンポーネントの一意の名前を Anypoint Studio で表示するようにカスタマイズします。デフォルトは ​Remove Variable​ です。

Name (名前)

variableName

削除する変数の名前。変数がフローに存在しない場合、コンポーネントによって警告がログに記録されます (​WARN​)。存在しない変数の値にアクセスしようとすると、​null​ 値が返されます。​[example]​を参照してください。
## [](#例)例 次の基本的な例は、フローから Mule 変数を削除する方法を示しています。 ```xml ``` フローでは次のプロセッサーが使用されます。 - Scheduler コンポーネントによってフローがトリガーされます。 - Set Variable によって Mule 変数 (​`myMuleVar`​) が作成されます。 - フローの最初の Logger によって変数の値 (​`"value of my Mule variable"`​) が出力されます。 - Remove Variable によって Mule イベントから変数を削除するための変数 (​`variableName="myMuleVar"`​) の名前が含まれる文字列が提供されます。 - Mule 変数が存在しなくなっているため、2 番目の Logger によって ​`null`​ が出力されます。 - Mule イベントに存在していない Mule 変数 (​`banana`​) の削除を試みるため、2 番目の Remove Variable によって ​`WARN`​ メッセージがログに記録されます。 次の例は、このフローの実行のログを示しています。 ```logs INFO 2022-12-15 08:33:20,151 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] PRINT VALUE OF VARIABLE: "value of my Mule variable" INFO 2022-12-15 08:33:20,155 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ATTEMPT TO PRINT VALUE OF REMOVED VARIABLE: null WARN 2022-12-15 08:33:20,156 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ...RemoveFlowVariableProcessor: There is no variable named 'banana'. Check the 'variableName' parameter in the 'remove-variable' component at remove-variable-ex/processors/4 ``` ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.6/target-variables) # Remove Variable トランスフォーマー Remove Variable コンポーネントは、Mule 変数名を受け入れて、Mule イベントから変数を削除します。
項目 XML 説明

Display Name (表示名)

doc:name

このコンポーネントの一意の名前を Anypoint Studio で表示するようにカスタマイズします。デフォルトは ​Remove Variable​ です。

Name (名前)

variableName

削除する変数の名前。変数がフローに存在しない場合、コンポーネントによって警告がログに記録されます (​WARN​)。存在しない変数の値にアクセスしようとすると、​null​ 値が返されます。​[example]​を参照してください。
## [](#例)例 次の基本的な例は、フローから Mule 変数を削除する方法を示しています。 ```xml ``` フローでは次のプロセッサーが使用されます。 - Scheduler コンポーネントによってフローがトリガーされます。 - Set Variable によって Mule 変数 (​`myMuleVar`​) が作成されます。 - フローの最初の Logger によって変数の値 (​`"value of my Mule variable"`​) が出力されます。 - Remove Variable によって Mule イベントから変数を削除するための変数 (​`variableName="myMuleVar"`​) の名前が含まれる文字列が提供されます。 - Mule 変数が存在しなくなっているため、2 番目の Logger によって ​`null`​ が出力されます。 - Mule イベントに存在していない Mule 変数 (​`banana`​) の削除を試みるため、2 番目の Remove Variable によって ​`WARN`​ メッセージがログに記録されます。 次の例は、このフローの実行のログを示しています。 ```logs INFO 2022-12-15 08:33:20,151 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] PRINT VALUE OF VARIABLE: "value of my Mule variable" INFO 2022-12-15 08:33:20,155 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ATTEMPT TO PRINT VALUE OF REMOVED VARIABLE: null WARN 2022-12-15 08:33:20,156 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ...RemoveFlowVariableProcessor: There is no variable named 'banana'. Check the 'variableName' parameter in the 'remove-variable' component at remove-variable-ex/processors/4 ``` ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.7/target-variables) # Remove Variable トランスフォーマー Remove Variable コンポーネントは、Mule 変数名を受け入れて、Mule イベントから変数を削除します。
項目 XML 説明

Display Name (表示名)

doc:name

このコンポーネントの一意の名前を Anypoint Studio で表示するようにカスタマイズします。デフォルトは ​Remove Variable​ です。

Name (名前)

variableName

削除する変数の名前。変数がフローに存在しない場合、コンポーネントによって警告がログに記録されます (​WARN​)。存在しない変数の値にアクセスしようとすると、​null​ 値が返されます。​[example]​を参照してください。
## [](#例)例 次の基本的な例は、フローから Mule 変数を削除する方法を示しています。 ```xml ``` フローでは次のプロセッサーが使用されます。 - Scheduler コンポーネントによってフローがトリガーされます。 - Set Variable によって Mule 変数 (​`myMuleVar`​) が作成されます。 - フローの最初の Logger によって変数の値 (​`"value of my Mule variable"`​) が出力されます。 - Remove Variable によって Mule イベントから変数を削除するための変数 (​`variableName="myMuleVar"`​) の名前が含まれる文字列が提供されます。 - Mule 変数が存在しなくなっているため、2 番目の Logger によって ​`null`​ が出力されます。 - Mule イベントに存在していない Mule 変数 (​`banana`​) の削除を試みるため、2 番目の Remove Variable によって ​`WARN`​ メッセージがログに記録されます。 次の例は、このフローの実行のログを示しています。 ```logs INFO 2022-12-15 08:33:20,151 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] PRINT VALUE OF VARIABLE: "value of my Mule variable" INFO 2022-12-15 08:33:20,155 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ATTEMPT TO PRINT VALUE OF REMOVED VARIABLE: null WARN 2022-12-15 08:33:20,156 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ...RemoveFlowVariableProcessor: There is no variable named 'banana'. Check the 'variableName' parameter in the 'remove-variable' component at remove-variable-ex/processors/4 ``` ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.8/target-variables) # Remove Variable トランスフォーマー Remove Variable コンポーネントは、Mule 変数名を受け入れて、Mule イベントから変数を削除します。
項目 XML 説明

Display Name (表示名)

doc:name

このコンポーネントの一意の名前を Anypoint Studio で表示するようにカスタマイズします。デフォルトは ​Remove Variable​ です。

Name (名前)

variableName

削除する変数の名前。変数がフローに存在しない場合、コンポーネントによって警告がログに記録されます (​WARN​)。存在しない変数の値にアクセスしようとすると、​null​ 値が返されます。​[example]​を参照してください。
## [](#例)例 次の基本的な例は、フローから Mule 変数を削除する方法を示しています。 ```xml ``` フローでは次のプロセッサーが使用されます。 - Scheduler コンポーネントによってフローがトリガーされます。 - Set Variable によって Mule 変数 (​`myMuleVar`​) が作成されます。 - フローの最初の Logger によって変数の値 (​`"value of my Mule variable"`​) が出力されます。 - Remove Variable によって Mule イベントから変数を削除するための変数 (​`variableName="myMuleVar"`​) の名前が含まれる文字列が提供されます。 - Mule 変数が存在しなくなっているため、2 番目の Logger によって ​`null`​ が出力されます。 - Mule イベントに存在していない Mule 変数 (​`banana`​) の削除を試みるため、2 番目の Remove Variable によって ​`WARN`​ メッセージがログに記録されます。 次の例は、このフローの実行のログを示しています。 ```logs INFO 2022-12-15 08:33:20,151 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] PRINT VALUE OF VARIABLE: "value of my Mule variable" INFO 2022-12-15 08:33:20,155 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ATTEMPT TO PRINT VALUE OF REMOVED VARIABLE: null WARN 2022-12-15 08:33:20,156 ...event: 2f65e920-7c96-11ed-97ec-147ddaaf4f97] ...RemoveFlowVariableProcessor: There is no variable named 'banana'. Check the 'variableName' parameter in the 'remove-variable' component at remove-variable-ex/processors/4 ``` ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.9/target-variables) # REST API の例 次の例では、Anypoint Studio または Mule Runtime Engine のスタンドアロン XML を使用して、公開されている REST API からデータを取得する API を記述する方法を説明しています。この API の例では、lorem ipsum テキストを生成し、次の場所にある Bacon Ipsum REST API を照会します。 http://baconipsum.com/ ## [](#anypoint-studio-で-rest-api-をコンシュームする)Anypoint Studio で REST API をコンシュームする Studio で REST API をコンシュームするには、HTTP Connector を設定し、File Write 操作を追加して、アプリケーションを実行します。 1. 最初に、Studio で HTTP リスナーと HTTP Request Connector を追加して設定します。HTTPS を使用したりアカウントをセットアップしたりする必要はありません。 ![HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-rest-api-example-1.png) Figure 1. HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー。 この時点で、API をコールして Web ブラウザーで ​`bacon ipsum`​ テキストを受信できます。 1. 次に、File Write コンポーネントを追加して ​`bacon ipsum`​ テキストの要求の出力をファイルシステムのファイルに保存します。 ![HTTP Listener Connector、HTTP Request Connector、File Write コンポーネントを使用したフロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-rest-api-example-2.png) Figure 2. HTTP リスナー、HTTP Request Connector、File Write コンポーネントを使用したフロー。 最初の要素である HTTP Listener は、ローカルホストポート 8081 (デフォルト) 上で受信 GET 要求をリスンします。ブラウザーからリスナーをコールすると、フローがトリガーされます。 1. 最後に、次の構文を使用して要求を送信します。 http://localhost:8081? ``​ は REST API によって受け入れられるパラメーターで構成されます。HTTP Listener が HTTP Request を受信すると、アプリケーションによって ​``​ が一連のクエリパラメーターとして記録されます。HTTP Listener によってこれらのパラメーターがフローの次の要素である HTTP Request 操作に渡されます。この操作は、​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ でリモート REST API を照会するように設定されています。HTTP Request Connector では DataWeave 式を使用してメッセージのプロパティからクエリパラメーターを抽出し、クエリパラメーターを含めてリモート API の完全な URL を作成します。 たとえば、次のローカルブラウザー要求を入力するとします。 http://localhost:8081?type=meat-and-filler 結果として、アプリケーションで次のクエリが発行されます。 http://baconipsum.com/api/?type=meat-and-filler ### [](#http-connector-を設定する)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー)HTTP リスナー HTTP リスナーを設定するには、次の手順に従います。 1. HTTP Listener コンポーネントを選択します。 2. **\[Connector Configuration (コネクタ設定)\]**​ で ​![mruntime add plus](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-add-plus.png)​ をクリックし、​**\[Host (ホスト)\]**​ を ​`localhost`​、​**\[Port (ポート)\]**​ を ​`8081`​ に設定します。 3. **\[OK\]**​ をクリックします。 ![ホストとポートを使用した HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-rest-api-example-3.png) Figure 3. ホストとポートを使用した HTTP リスナー設定。 1. HTTP リスナーのプロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に設定します。 ![パスを使用した HTTP リスナーのプロパティエディター](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-rest-api-example-4.png) Figure 4. パスを使用した HTTP リスナーのプロパティエディター。 #### [](#http-要求)HTTP 要求 1. **\[Connector Configuration (コネクタ設定)\]**​ で ​![mruntime add plus](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-add-plus.png)​ をクリックし、​**\[Host (ホスト)\]**​ を ​`baconipsum.com`​、​**\[Port (ポート)\]**​ を ​`80`​、​**\[Base Path (ベースパス)\]**​ を ​`api`​ に設定します。この設定により、要求は ​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ に送信されます。 2. **\[OK\]**​ をクリックします。 ![HTTP Request Connector の設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-rest-api-example-5.png) Figure 5. HTTP Request Connector の設定。 1. プロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に、​**\[Method (メソッド)\]**​ を ​`GET`​ に設定します。 2. \[Query Parameters (クエリパラメーター)\] タブで、2 つのクエリパラメーターを追加します。 各 ​`value`​ 項目に、最初に HTTP リスナーに到達した要求のクエリパラメーターから指定された値を取得する Mule 式を入力します。
パラメーター 値

Type (型)

query-param

Name (名前)

type

Value (値)

#[message.attributes.queryParams['type']]
パラメーター 値

Type (型)

query-param

Name (名前)

sentences

Value (値)

`#[message.attributes.queryParams['sentences']]
![名前と値が含まれるクエリパラメーター](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-rest-api-example-6.png) Figure 6. 名前と値が含まれるクエリパラメーター。 Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、このアプリケーションでは ​`type`​ と ​`sentences`​ パラメーターのみを使用します。省略可能な ​`sentences`​ パラメーターによって、JSON 応答で返す文の数が決定されます。 ### [](#file-write-操作)File Write 操作 アプリケーションの出力をファイルに保存するように File Write コンポーネントのプロパティをセットアップします。 1. File Write コンポーネントをキャンバスにドラッグします。 2. プロパティエディターで、出力を保存するためのディレクトリとファイル名を設定します: `/tmp/output`​。 ![mruntime rest api example 2](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-rest-api-example-2.png) 3. プロパティエディターで、​**\[Path (パス)\]**​ のファイルシステムの実際のパスを指定します。 ![File Write プロパティエディターと \[Path (パス)\]](_images/mruntime-rest-api-example-7.png) Figure 7. File Write プロパティエディターと \[Path (パス)\]。 ### [](#アプリケーションを実行して-rest-api-をコンシュームする)アプリケーションを実行して REST API をコンシュームする 以下の手順でアプリケーションを実行します。 1. Studio のプロジェクト内で ​![2%](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-run-button.png)​ をクリックして Mule アプリケーションとして例を実行します。テストします。 2. Web ブラウザーウィンドウでローカルホストポート 8081 で HTTP Listener を照会して、アプリケーションのフローをトリガーします。 http://localhost:8081?type=meat-and-filler Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、HTTP Request Connector を設定するときは、​`type`​ と ​`sentences`​ パラメーターのみを使用するようにコネクタをセットアップします。 - 最初のパラメーター=値のペアの前に ​`?`​ 演算子を追加する必要があります。 - 追加のパラメーター=値のペアを挿入するには、​`&`​ 演算子を使用します。 次のクエリは、ローカルホストポート 8081 で HTTP リスナーに送信できる例です。 http://localhost:8081?type=meat-and-filler http://localhost:8081?sentences=2 http://localhost:8081?type=all-meat&sentences=3 `type=meat-and-filler`​ の例では、次の出力が返されます。 \["Doner ullamco ea non, porchetta incididunt brisket ball tip in chuck ex bresaola beef tongue. Et aute ham hock kielbasa chuck fatback short ribs. Kevin in reprehenderit est esse, ham bacon ut ball tip. Laborum ut nulla ex irure t-bone flank, biltong cupidatat venison proident aliquip pork belly ham hock. In consequat proident, cillum labore pariatur nisi. Reprehenderit boudin beef ribs, frankfurter cillum enim pork loin consectetur kielbasa laboris. Hamburger prosciutto nisi, jerky biltong ex pork chop venison.","Fatback tongue anim, irure ut ut cupidatat occaecat eiusmod ham hock laborum commodo. Anim pig shank kielbasa, drumstick corned beef esse nostrud ham salami id laborum ribeye aute. Duis pancetta sunt magna occaecat dolor leberkas, short loin meatloaf flank enim pastrami. Prosciutto proident landjaeger deserunt tenderloin short loin. Adipisicing aute in bresaola meatball, ut frankfurter pastrami shoulder porchetta turducken strip steak doner. In filet mignon bresaola, sed deserunt pariatur eu mollit commodo shankle laborum. Andouille aliqua jowl pork chop jerky sed consequat turkey voluptate bacon pastrami.","Ground round elit boudin reprehenderit. Brisket shankle esse, leberkas veniam andouille rump proident drumstick. Consequat sausage do ut prosciutto nostrud andouille tongue ullamco bacon est exercitation. Do fugiat biltong est tempor short ribs reprehenderit adipisicing shoulder. Tail venison shank incididunt, hamburger adipisicing voluptate corned beef fugiat sirloin fatback in tri-tip nisi ut. Tail non excepteur, fugiat veniam corned beef dolore ex pig pork belly sint mollit chuck pork.","Pig hamburger dolore proident brisket landjaeger in boudin kielbasa ut elit. Velit incididunt boudin qui. Fatback anim adipisicing, pig jowl voluptate sirloin drumstick chicken esse. Strip steak consequat tenderloin pastrami, ullamco brisket hamburger bacon beef adipisicing. Tri-tip ham hock eu non et, flank dolore kevin. Et duis frankfurter, ut ullamco do non quis boudin andouille aliqua venison ham. Ut aliqua shoulder, aliquip pariatur bacon spare ribs irure.","Aliqua jerky frankfurter, swine ham in ground round sed qui laborum cow. Sint turducken shank ut ea id. Kevin dolore pig excepteur, anim ut magna. Enim consequat short ribs corned beef ham hock nostrud fugiat chuck. Tail spare ribs dolore boudin, andouille incididunt laboris occaecat strip steak. Cow frankfurter capicola, landjaeger cupidatat porchetta ad ground round voluptate."\] ## [](#スタンドアロン-xml-で-rest-api-をコンシュームする)スタンドアロン XML で REST API をコンシュームする スタンドアロン XML で REST API をコンシュームするには、HTTP リスナーと HTTP Request Connector を設定すると共に File Write コンポーネントを追加する必要があります。 ### [](#http-connector-を設定する-2)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー-2)HTTP リスナー HTTP リスナーを設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照してください。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` #### [](#http-要求-2)HTTP 要求 HTTP 要求を設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照する必要があります。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` ### [](#file-write-操作-2)File Write 操作 最後に、XML で File Write 操作を追加します。 ```xml ``` ### [](#xml)XML 完成した XML を確認します。 ```xml ``` ## [](#関連情報)関連情報 - [API からのデータのコンシューム](https://docs.mulesoft.com/jp/mule-runtime/4.3/consume-data-from-an-api) # REST API の例 次の例では、Anypoint Studio または Mule Runtime Engine のスタンドアロン XML を使用して、公開されている REST API からデータを取得する API を記述する方法を説明しています。この API の例では、lorem ipsum テキストを生成し、次の場所にある Bacon Ipsum REST API を照会します。 http://baconipsum.com/ ## [](#anypoint-studio-で-rest-api-をコンシュームする)Anypoint Studio で REST API をコンシュームする Studio で REST API をコンシュームするには、HTTP Connector を設定し、File Write 操作を追加して、アプリケーションを実行します。 1. 最初に、Studio で HTTP リスナーと HTTP Request Connector を追加して設定します。HTTPS を使用したりアカウントをセットアップしたりする必要はありません。 ![HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-rest-api-example-1.png) Figure 1. HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー。 この時点で、API をコールして Web ブラウザーで ​`bacon ipsum`​ テキストを受信できます。 1. 次に、File Write コンポーネントを追加して ​`bacon ipsum`​ テキストの要求の出力をファイルシステムのファイルに保存します。 ![HTTP Listener Connector、HTTP Request Connector、File Write コンポーネントを使用したフロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-rest-api-example-2.png) Figure 2. HTTP リスナー、HTTP Request Connector、File Write コンポーネントを使用したフロー。 最初の要素である HTTP Listener は、ローカルホストポート 8081 (デフォルト) 上で受信 GET 要求をリスンします。ブラウザーからリスナーをコールすると、フローがトリガーされます。 1. 最後に、次の構文を使用して要求を送信します。 http://localhost:8081? ``​ は REST API によって受け入れられるパラメーターで構成されます。HTTP Listener が HTTP Request を受信すると、アプリケーションによって ​``​ が一連のクエリパラメーターとして記録されます。HTTP Listener によってこれらのパラメーターがフローの次の要素である HTTP Request 操作に渡されます。この操作は、​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ でリモート REST API を照会するように設定されています。HTTP Request Connector では DataWeave 式を使用してメッセージのプロパティからクエリパラメーターを抽出し、クエリパラメーターを含めてリモート API の完全な URL を作成します。 たとえば、次のローカルブラウザー要求を入力するとします。 http://localhost:8081?type=meat-and-filler 結果として、アプリケーションで次のクエリが発行されます。 http://baconipsum.com/api/?type=meat-and-filler ### [](#http-connector-を設定する)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー)HTTP リスナー HTTP リスナーを設定するには、次の手順に従います。 1. HTTP Listener コンポーネントを選択します。 2. **\[Connector Configuration (コネクタ設定)\]**​ で ​![mruntime add plus](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-add-plus.png)​ をクリックし、​**\[Host (ホスト)\]**​ を ​`localhost`​、​**\[Port (ポート)\]**​ を ​`8081`​ に設定します。 3. **\[OK\]**​ をクリックします。 ![ホストとポートを使用した HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-rest-api-example-3.png) Figure 3. ホストとポートを使用した HTTP リスナー設定。 1. HTTP リスナーのプロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に設定します。 ![パスを使用した HTTP リスナーのプロパティエディター](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-rest-api-example-4.png) Figure 4. パスを使用した HTTP リスナーのプロパティエディター。 #### [](#http-要求)HTTP 要求 1. **\[Connector Configuration (コネクタ設定)\]**​ で ​![mruntime add plus](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-add-plus.png)​ をクリックし、​**\[Host (ホスト)\]**​ を ​`baconipsum.com`​、​**\[Port (ポート)\]**​ を ​`80`​、​**\[Base Path (ベースパス)\]**​ を ​`api`​ に設定します。この設定により、要求は ​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ に送信されます。 2. **\[OK\]**​ をクリックします。 ![HTTP Request Connector の設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-rest-api-example-5.png) Figure 5. HTTP Request Connector の設定。 1. プロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に、​**\[Method (メソッド)\]**​ を ​`GET`​ に設定します。 2. \[Query Parameters (クエリパラメーター)\] タブで、2 つのクエリパラメーターを追加します。 各 ​`value`​ 項目に、最初に HTTP リスナーに到達した要求のクエリパラメーターから指定された値を取得する Mule 式を入力します。
パラメーター 値

Type (型)

query-param

Name (名前)

type

Value (値)

#[message.attributes.queryParams['type']]
パラメーター 値

Type (型)

query-param

Name (名前)

sentences

Value (値)

`#[message.attributes.queryParams['sentences']]
![名前と値が含まれるクエリパラメーター](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-rest-api-example-6.png) Figure 6. 名前と値が含まれるクエリパラメーター。 Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、このアプリケーションでは ​`type`​ と ​`sentences`​ パラメーターのみを使用します。省略可能な ​`sentences`​ パラメーターによって、JSON 応答で返す文の数が決定されます。 ### [](#file-write-操作)File Write 操作 アプリケーションの出力をファイルに保存するように File Write コンポーネントのプロパティをセットアップします。 1. File Write コンポーネントをキャンバスにドラッグします。 2. プロパティエディターで、出力を保存するためのディレクトリとファイル名を設定します: `/tmp/output`​。 ![mruntime rest api example 2](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-rest-api-example-2.png) 3. プロパティエディターで、​**\[Path (パス)\]**​ のファイルシステムの実際のパスを指定します。 ![File Write プロパティエディターと \[Path (パス)\]](_images/mruntime-rest-api-example-7.png) Figure 7. File Write プロパティエディターと \[Path (パス)\]。 ### [](#アプリケーションを実行して-rest-api-をコンシュームする)アプリケーションを実行して REST API をコンシュームする 以下の手順でアプリケーションを実行します。 1. Studio のプロジェクト内で ​![2%](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-run-button.png)​ をクリックして Mule アプリケーションとして例を実行します。テスト 2. Web ブラウザーウィンドウでローカルホストポート 8081 で HTTP Listener を照会して、アプリケーションのフローをトリガーします。 http://localhost:8081?type=meat-and-filler Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、HTTP Request Connector を設定するときは、​`type`​ と ​`sentences`​ パラメーターのみを使用するようにコネクタをセットアップします。 - 最初のパラメーター=値のペアの前に ​`?`​ 演算子を追加する必要があります。 - 追加のパラメーター=値のペアを挿入するには、​`&`​ 演算子を使用します。 次のクエリは、ローカルホストポート 8081 で HTTP リスナーに送信できる例です。 http://localhost:8081?type=meat-and-filler http://localhost:8081?sentences=2 http://localhost:8081?type=all-meat&sentences=3 `type=meat-and-filler`​ の例では、次の出力が返されます。 \["Doner ullamco ea non, porchetta incididunt brisket ball tip in chuck ex bresaola beef tongue. Et aute ham hock kielbasa chuck fatback short ribs. Kevin in reprehenderit est esse, ham bacon ut ball tip. Laborum ut nulla ex irure t-bone flank, biltong cupidatat venison proident aliquip pork belly ham hock. In consequat proident, cillum labore pariatur nisi. Reprehenderit boudin beef ribs, frankfurter cillum enim pork loin consectetur kielbasa laboris. Hamburger prosciutto nisi, jerky biltong ex pork chop venison.","Fatback tongue anim, irure ut ut cupidatat occaecat eiusmod ham hock laborum commodo. Anim pig shank kielbasa, drumstick corned beef esse nostrud ham salami id laborum ribeye aute. Duis pancetta sunt magna occaecat dolor leberkas, short loin meatloaf flank enim pastrami. Prosciutto proident landjaeger deserunt tenderloin short loin. Adipisicing aute in bresaola meatball, ut frankfurter pastrami shoulder porchetta turducken strip steak doner. In filet mignon bresaola, sed deserunt pariatur eu mollit commodo shankle laborum. Andouille aliqua jowl pork chop jerky sed consequat turkey voluptate bacon pastrami.","Ground round elit boudin reprehenderit. Brisket shankle esse, leberkas veniam andouille rump proident drumstick. Consequat sausage do ut prosciutto nostrud andouille tongue ullamco bacon est exercitation. Do fugiat biltong est tempor short ribs reprehenderit adipisicing shoulder. Tail venison shank incididunt, hamburger adipisicing voluptate corned beef fugiat sirloin fatback in tri-tip nisi ut. Tail non excepteur, fugiat veniam corned beef dolore ex pig pork belly sint mollit chuck pork.","Pig hamburger dolore proident brisket landjaeger in boudin kielbasa ut elit. Velit incididunt boudin qui. Fatback anim adipisicing, pig jowl voluptate sirloin drumstick chicken esse. Strip steak consequat tenderloin pastrami, ullamco brisket hamburger bacon beef adipisicing. Tri-tip ham hock eu non et, flank dolore kevin. Et duis frankfurter, ut ullamco do non quis boudin andouille aliqua venison ham. Ut aliqua shoulder, aliquip pariatur bacon spare ribs irure.","Aliqua jerky frankfurter, swine ham in ground round sed qui laborum cow. Sint turducken shank ut ea id. Kevin dolore pig excepteur, anim ut magna. Enim consequat short ribs corned beef ham hock nostrud fugiat chuck. Tail spare ribs dolore boudin, andouille incididunt laboris occaecat strip steak. Cow frankfurter capicola, landjaeger cupidatat porchetta ad ground round voluptate."\] ## [](#スタンドアロン-xml-で-rest-api-をコンシュームする)スタンドアロン XML で REST API をコンシュームする スタンドアロン XML で REST API をコンシュームするには、HTTP リスナーと HTTP Request Connector を設定すると共に File Write コンポーネントを追加する必要があります。 ### [](#http-connector-を設定する-2)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー-2)HTTP リスナー HTTP リスナーを設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照してください。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` #### [](#http-要求-2)HTTP 要求 HTTP 要求を設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照する必要があります。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` ### [](#file-write-操作-2)File Write 操作 最後に、XML で File Write 操作を追加します。 ```xml ``` ### [](#xml)XML 完成した XML を確認します。 ```xml ``` ## [](#関連情報)関連情報 - [API からのデータのコンシューム](https://docs.mulesoft.com/jp/mule-runtime/4.4/consume-data-from-an-api) # REST API の例 次の例では、Anypoint Studio または Mule Runtime Engine のスタンドアロン XML を使用して、公開されている REST API からデータを取得する API を記述する方法を説明しています。この API の例では、lorem ipsum テキストを生成し、次の場所にある Bacon Ipsum REST API を照会します。 http://baconipsum.com/ ## [](#anypoint-studio-で-rest-api-をコンシュームする)Anypoint Studio で REST API をコンシュームする Studio で REST API をコンシュームするには、HTTP Connector を設定し、File Write 操作を追加して、アプリケーションを実行します。 1. 最初に、Studio で HTTP リスナーと HTTP Request Connector を追加して設定します。HTTPS を使用したりアカウントをセットアップしたりする必要はありません。 ![HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-rest-api-example-1.png) Figure 1. HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー。 この時点で、API をコールして Web ブラウザーで ​`bacon ipsum`​ テキストを受信できます。 1. 次に、File Write コンポーネントを追加して ​`bacon ipsum`​ テキストの要求の出力をファイルシステムのファイルに保存します。 ![HTTP Listener Connector、HTTP Request Connector、File Write コンポーネントを使用したフロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-rest-api-example-2.png) Figure 2. HTTP リスナー、HTTP Request Connector、File Write コンポーネントを使用したフロー。 最初の要素である HTTP Listener は、ローカルホストポート 8081 (デフォルト) 上で受信 GET 要求をリスンします。ブラウザーからリスナーをコールすると、フローがトリガーされます。 1. 最後に、次の構文を使用して要求を送信します。 http://localhost:8081? ``​ は REST API によって受け入れられるパラメーターで構成されます。HTTP Listener が HTTP Request を受信すると、アプリケーションによって ​``​ が一連のクエリパラメーターとして記録されます。HTTP Listener によってこれらのパラメーターがフローの次の要素である HTTP Request 操作に渡されます。この操作は、​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ でリモート REST API を照会するように設定されています。HTTP Request Connector では DataWeave 式を使用してメッセージのプロパティからクエリパラメーターを抽出し、クエリパラメーターを含めてリモート API の完全な URL を作成します。 たとえば、次のローカルブラウザー要求を入力するとします。 http://localhost:8081?type=meat-and-filler 結果として、アプリケーションで次のクエリが発行されます。 http://baconipsum.com/api/?type=meat-and-filler ### [](#http-connector-を設定する)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-listener-http-リスナー)HTTP Listener (HTTP リスナー) HTTP リスナーを設定するには、次の手順に従います。 1. HTTP Listener コンポーネントを選択します。 2. **\[Connector Configuration (コネクタ設定)\]**​ で、![mruntime add plus](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-add-plus.png) をクリックして、​**\[Host (ホスト)\]**​ を ​`localhost`​ に、​**\[Port (ポート)\]**​ を ​`8081`​ に設定します。 3. **\[OK\]**​ をクリックします。 ![ホストとポートを使用した HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-rest-api-example-3.png) Figure 3. ホストとポートを使用した HTTP リスナー設定。 1. HTTP リスナーのプロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に設定します。 ![パスを使用した HTTP リスナーのプロパティエディター](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-rest-api-example-4.png) Figure 4. パスを使用した HTTP リスナーのプロパティエディター。 #### [](#http-要求)HTTP 要求 1. **\[Connector Configuration (コネクタ設定)\]**​ で、![mruntime add plus](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-add-plus.png) をクリックして、​**\[Host (ホスト)\]**​ を ​`baconipsum.com`​ に、​**\[Port (ポート)\]**​ を ​`80`​ に、​**\[Base Path (ベースパス)\]**​ を ​`api`​ に設定します。この設定により、要求が ​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ に送信されます。 2. **\[OK\]**​ をクリックします。 ![HTTP Request Connector の設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-rest-api-example-5.png) Figure 5. HTTP Request Connector の設定。 1. プロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に、​**\[Method (メソッド)\]**​ を ​`GET`​ に設定します。 2. \[Query Parameters (クエリパラメーター)\] タブで、2 つのクエリパラメーターを追加します。 各 ​`value`​ 項目に、最初に HTTP リスナーに到達した要求のクエリパラメーターから指定された値を取得する Mule 式を入力します。
パラメーター Value (値)

Type (種別)

query-param

Name (名前)

type

Value (値)

#[message.attributes.queryParams['type']]
パラメーター Value (値)

Type (種別)

query-param

Name (名前)

sentences

Value (値)

`#[message.attributes.queryParams['sentences']]
![名前と値が含まれるクエリパラメーター](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-rest-api-example-6.png) Figure 6. 名前と値が含まれるクエリパラメーター。 Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、このアプリケーションでは ​`type`​ と ​`sentences`​ パラメーターのみを使用します。省略可能な ​`sentences`​ パラメーターによって、JSON 応答で返す文の数が決定されます。 ### [](#file-write-操作)File Write 操作 アプリケーションの出力をファイルに保存するように File Write コンポーネントのプロパティをセットアップします。 1. File Write コンポーネントをキャンバスにドラッグします。 2. プロパティエディターで、出力を保存するためのディレクトリとファイル名を設定します: `/tmp/output`​。 ![mruntime rest api example 2](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-rest-api-example-2.png) 3. プロパティエディターで、​**\[Path (パス)\]**​ のファイルシステムの実際のパスを指定します。 ![File Write プロパティエディターと \[Path (パス)\]](_images/mruntime-rest-api-example-7.png) Figure 7. File Write プロパティエディターと \[Path (パス)\]。 ### [](#アプリケーションを実行して-rest-api-をコンシュームする)アプリケーションを実行して REST API をコンシュームする 以下の手順でアプリケーションを実行します。 1. Studio のプロジェクト内で ​![2%](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-run-button.png)​ をクリックして Mule アプリケーションとして例を実行します。テストします。 2. Web ブラウザーウィンドウでローカルホストポート 8081 で HTTP Listener を照会して、アプリケーションのフローをトリガーします。 http://localhost:8081?type=meat-and-filler Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、HTTP Request Connector をセットアップするときは、​`type`​ と ​`sentences`​ パラメーターのみを使用するようにコネクタをセットアップします。 - 最初のパラメーター=値のペアの前に ​`?`​ 演算子を追加する必要があります。 - 追加のパラメーター=値のペアを挿入するには、​`&`​ 演算子を使用します。 次のクエリは、ローカルホストポート 8081 で HTTP リスナーに送信できる例です。 http://localhost:8081?type=meat-and-filler http://localhost:8081?sentences=2 http://localhost:8081?type=all-meat&sentences=3 `type=meat-and-filler`​ の例では、次の出力が返されます。 \["Doner ullamco ea non, porchetta incididunt brisket ball tip in chuck ex bresaola beef tongue. Et aute ham hock kielbasa chuck fatback short ribs. Kevin in reprehenderit est esse, ham bacon ut ball tip. Laborum ut nulla ex irure t-bone flank, biltong cupidatat venison proident aliquip pork belly ham hock. In consequat proident, cillum labore pariatur nisi. Reprehenderit boudin beef ribs, frankfurter cillum enim pork loin consectetur kielbasa laboris. Hamburger prosciutto nisi, jerky biltong ex pork chop venison.","Fatback tongue anim, irure ut ut cupidatat occaecat eiusmod ham hock laborum commodo. Anim pig shank kielbasa, drumstick corned beef esse nostrud ham salami id laborum ribeye aute. Duis pancetta sunt magna occaecat dolor leberkas, short loin meatloaf flank enim pastrami. Prosciutto proident landjaeger deserunt tenderloin short loin. Adipisicing aute in bresaola meatball, ut frankfurter pastrami shoulder porchetta turducken strip steak doner. In filet mignon bresaola, sed deserunt pariatur eu mollit commodo shankle laborum. Andouille aliqua jowl pork chop jerky sed consequat turkey voluptate bacon pastrami.","Ground round elit boudin reprehenderit. Brisket shankle esse, leberkas veniam andouille rump proident drumstick. Consequat sausage do ut prosciutto nostrud andouille tongue ullamco bacon est exercitation. Do fugiat biltong est tempor short ribs reprehenderit adipisicing shoulder. Tail venison shank incididunt, hamburger adipisicing voluptate corned beef fugiat sirloin fatback in tri-tip nisi ut. Tail non excepteur, fugiat veniam corned beef dolore ex pig pork belly sint mollit chuck pork.","Pig hamburger dolore proident brisket landjaeger in boudin kielbasa ut elit. Velit incididunt boudin qui. Fatback anim adipisicing, pig jowl voluptate sirloin drumstick chicken esse. Strip steak consequat tenderloin pastrami, ullamco brisket hamburger bacon beef adipisicing. Tri-tip ham hock eu non et, flank dolore kevin. Et duis frankfurter, ut ullamco do non quis boudin andouille aliqua venison ham. Ut aliqua shoulder, aliquip pariatur bacon spare ribs irure.","Aliqua jerky frankfurter, swine ham in ground round sed qui laborum cow. Sint turducken shank ut ea id. Kevin dolore pig excepteur, anim ut magna. Enim consequat short ribs corned beef ham hock nostrud fugiat chuck. Tail spare ribs dolore boudin, andouille incididunt laboris occaecat strip steak. Cow frankfurter capicola, landjaeger cupidatat porchetta ad ground round voluptate."\] ## [](#スタンドアロン-xml-で-rest-api-をコンシュームする)スタンドアロン XML で REST API をコンシュームする スタンドアロン XML で REST API をコンシュームするには、HTTP リスナーと HTTP Request Connector を設定すると共に File Write コンポーネントを追加する必要があります。 ### [](#http-connector-を設定する-2)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-listener-http-リスナー-2)HTTP Listener (HTTP リスナー) HTTP リスナーを設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照してください。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` #### [](#http-要求-2)HTTP 要求 HTTP 要求を設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照する必要があります。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` ### [](#file-write-操作-2)File Write 操作 最後に、XML で File Write 操作を追加します。 ```xml ``` ### [](#xml)XML 完成した XML を確認します。 ```xml ``` ## [](#関連情報)関連情報 - [API からのデータのコンシューム](https://docs.mulesoft.com/jp/mule-runtime/4.5/consume-data-from-an-api) # REST API の例 次の例では、Anypoint Studio または Mule Runtime Engine のスタンドアロン XML を使用して、公開されている REST API からデータを取得する API を記述する方法を説明しています。この API の例では、lorem ipsum テキストを生成し、次の場所にある Bacon Ipsum REST API を照会します。 http://baconipsum.com/ ## [](#anypoint-studio-で-rest-api-をコンシュームする)Anypoint Studio で REST API をコンシュームする Studio で REST API をコンシュームするには、HTTP Connector を設定し、File Write 操作を追加して、アプリケーションを実行します。 1. 最初に、Studio で HTTP リスナーと HTTP Request Connector を追加して設定します。HTTPS を使用したりアカウントをセットアップしたりする必要はありません。 ![HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-rest-api-example-1.png) Figure 1. HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー。 この時点で、API をコールして Web ブラウザーで ​`bacon ipsum`​ テキストを受信できます。 1. 次に、File Write コンポーネントを追加して ​`bacon ipsum`​ テキストの要求の出力をファイルシステムのファイルに保存します。 ![HTTP Listener Connector、HTTP Request Connector、File Write コンポーネントを使用したフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-rest-api-example-2.png) Figure 2. HTTP リスナー、HTTP Request Connector、File Write コンポーネントを使用したフロー。 最初の要素である HTTP Listener は、ローカルホストポート 8081 (デフォルト) 上で受信 GET 要求をリスンします。ブラウザーからリスナーをコールすると、フローがトリガーされます。 1. 最後に、次の構文を使用して要求を送信します。 http://localhost:8081? ``​ は REST API によって受け入れられるパラメーターで構成されます。HTTP Listener が HTTP Request を受信すると、アプリケーションによって ​``​ が一連のクエリパラメーターとして記録されます。HTTP Listener によってこれらのパラメーターがフローの次の要素である HTTP Request 操作に渡されます。この操作は、​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ でリモート REST API を照会するように設定されています。HTTP Request Connector では DataWeave 式を使用してメッセージのプロパティからクエリパラメーターを抽出し、クエリパラメーターを含めてリモート API の完全な URL を作成します。 たとえば、次のローカルブラウザー要求を入力するとします。 http://localhost:8081?type=meat-and-filler 結果として、アプリケーションで次のクエリが発行されます。 http://baconipsum.com/api/?type=meat-and-filler ### [](#http-connector-を設定する)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー)HTTP リスナー HTTP リスナーを設定するには、次の手順に従います。 1. HTTP Listener コンポーネントを選択します。 2. **\[Connector Configuration (コネクタ設定)\]**​ で ​![mruntime add plus](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-add-plus.png)​ をクリックし、​**\[Host (ホスト)\]**​ を ​`localhost`​、​**\[Port (ポート)\]**​ を ​`8081`​ に設定します。 3. **\[OK\]**​ をクリックします。 ![ホストとポートを使用した HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-rest-api-example-3.png) Figure 3. ホストとポートを使用した HTTP リスナー設定。 1. HTTP リスナーのプロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に設定します。 ![パスを使用した HTTP リスナーのプロパティエディター](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-rest-api-example-4.png) Figure 4. パスを使用した HTTP リスナーのプロパティエディター。 #### [](#http-要求)HTTP 要求 1. **\[Connector Configuration (コネクタ設定)\]**​ で ​![mruntime add plus](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-add-plus.png)​ をクリックし、​**\[Host (ホスト)\]**​ を ​`baconipsum.com`​、​**\[Port (ポート)\]**​ を ​`80`​、​**\[Base Path (ベースパス)\]**​ を ​`api`​ に設定します。この設定により、要求は ​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ に送信されます。 2. **\[OK\]**​ をクリックします。 ![HTTP Request Connector の設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-rest-api-example-5.png) Figure 5. HTTP Request Connector の設定。 1. プロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に、​**\[Method (メソッド)\]**​ を ​`GET`​ に設定します。 2. \[Query Parameters (クエリパラメーター)\] タブで、2 つのクエリパラメーターを追加します。 各 ​`value`​ 項目に、最初に HTTP リスナーに到達した要求のクエリパラメーターから指定された値を取得する Mule 式を入力します。
パラメーター 値

Type (型)

query-param

Name (名前)

type

Value (値)

#[message.attributes.queryParams['type']]
パラメーター 値

Type (型)

query-param

Name (名前)

sentences

Value (値)

`#[message.attributes.queryParams['sentences']]
![名前と値が含まれるクエリパラメーター](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-rest-api-example-6.png) Figure 6. 名前と値が含まれるクエリパラメーター。 Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、このアプリケーションでは ​`type`​ と ​`sentences`​ パラメーターのみを使用します。省略可能な ​`sentences`​ パラメーターによって、JSON 応答で返す文の数が決定されます。 ### [](#file-write-操作)File Write 操作 アプリケーションの出力をファイルに保存するように File Write コンポーネントのプロパティをセットアップします。 1. File Write コンポーネントをキャンバスにドラッグします。 2. プロパティエディターで、出力を保存するためのディレクトリとファイル名を設定します: `/tmp/output`​。 ![mruntime rest api example 2](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-rest-api-example-2.png) 3. プロパティエディターで、​**\[Path (パス)\]**​ のファイルシステムの実際のパスを指定します。 ![File Write プロパティエディターと \[Path (パス)\]](_images/mruntime-rest-api-example-7.png) Figure 7. File Write プロパティエディターと \[Path (パス)\]。 ### [](#アプリケーションを実行して-rest-api-をコンシュームする)アプリケーションを実行して REST API をコンシュームする 以下の手順でアプリケーションを実行します。 1. Studio のプロジェクト内で ​![2%](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-run-button.png)​ をクリックして Mule アプリケーションとして例を実行します。 2. Web ブラウザーウィンドウでローカルホストポート 8081 で HTTP Listener を照会して、アプリケーションのフローをトリガーします。 http://localhost:8081?type=meat-and-filler Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、HTTP Request Connector をセットアップするときは、​`type`​ と ​`sentences`​ パラメーターのみを使用するようにコネクタをセットアップします。 - 最初のパラメーター=値のペアの前に ​`?`​ 演算子を追加する必要があります。 - 追加のパラメーター=値のペアを挿入するには、​`&`​ 演算子を使用します。 次のクエリは、ローカルホストポート 8081 で HTTP リスナーに送信できる例です。 http://localhost:8081?type=meat-and-filler http://localhost:8081?sentences=2 http://localhost:8081?type=all-meat&sentences=3 `type=meat-and-filler`​ の例では、次の出力が返されます。 \["Doner ullamco ea non, porchetta incididunt brisket ball tip in chuck ex bresaola beef tongue. Et aute ham hock kielbasa chuck fatback short ribs. Kevin in reprehenderit est esse, ham bacon ut ball tip. Laborum ut nulla ex irure t-bone flank, biltong cupidatat venison proident aliquip pork belly ham hock. In consequat proident, cillum labore pariatur nisi. Reprehenderit boudin beef ribs, frankfurter cillum enim pork loin consectetur kielbasa laboris. Hamburger prosciutto nisi, jerky biltong ex pork chop venison.","Fatback tongue anim, irure ut ut cupidatat occaecat eiusmod ham hock laborum commodo. Anim pig shank kielbasa, drumstick corned beef esse nostrud ham salami id laborum ribeye aute. Duis pancetta sunt magna occaecat dolor leberkas, short loin meatloaf flank enim pastrami. Prosciutto proident landjaeger deserunt tenderloin short loin. Adipisicing aute in bresaola meatball, ut frankfurter pastrami shoulder porchetta turducken strip steak doner. In filet mignon bresaola, sed deserunt pariatur eu mollit commodo shankle laborum. Andouille aliqua jowl pork chop jerky sed consequat turkey voluptate bacon pastrami.","Ground round elit boudin reprehenderit. Brisket shankle esse, leberkas veniam andouille rump proident drumstick. Consequat sausage do ut prosciutto nostrud andouille tongue ullamco bacon est exercitation. Do fugiat biltong est tempor short ribs reprehenderit adipisicing shoulder. Tail venison shank incididunt, hamburger adipisicing voluptate corned beef fugiat sirloin fatback in tri-tip nisi ut. Tail non excepteur, fugiat veniam corned beef dolore ex pig pork belly sint mollit chuck pork.","Pig hamburger dolore proident brisket landjaeger in boudin kielbasa ut elit. Velit incididunt boudin qui. Fatback anim adipisicing, pig jowl voluptate sirloin drumstick chicken esse. Strip steak consequat tenderloin pastrami, ullamco brisket hamburger bacon beef adipisicing. Tri-tip ham hock eu non et, flank dolore kevin. Et duis frankfurter, ut ullamco do non quis boudin andouille aliqua venison ham. Ut aliqua shoulder, aliquip pariatur bacon spare ribs irure.","Aliqua jerky frankfurter, swine ham in ground round sed qui laborum cow. Sint turducken shank ut ea id. Kevin dolore pig excepteur, anim ut magna. Enim consequat short ribs corned beef ham hock nostrud fugiat chuck. Tail spare ribs dolore boudin, andouille incididunt laboris occaecat strip steak. Cow frankfurter capicola, landjaeger cupidatat porchetta ad ground round voluptate."\] ## [](#スタンドアロン-xml-で-rest-api-をコンシュームする)スタンドアロン XML で REST API をコンシュームする スタンドアロン XML で REST API をコンシュームするには、HTTP リスナーと HTTP Request Connector を設定すると共に File Write コンポーネントを追加する必要があります。 ### [](#http-connector-を設定する-2)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー-2)HTTP リスナー HTTP リスナーを設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照してください。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` #### [](#http-要求-2)HTTP 要求 HTTP 要求を設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照する必要があります。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` ### [](#file-write-操作-2)File Write 操作 最後に、XML で File Write 操作を追加します。 ```xml ``` ### [](#xml)XML 完成した XML を確認します。 ```xml ``` ## [](#関連情報)関連情報 - [API からのデータのコンシューム](https://docs.mulesoft.com/jp/mule-runtime/4.6/consume-data-from-an-api) # REST API の例 次の例では、Anypoint Studio または Mule Runtime Engine のスタンドアロン XML を使用して、公開されている REST API からデータを取得する API を記述する方法を説明しています。この API の例では、lorem ipsum テキストを生成し、次の場所にある Bacon Ipsum REST API を照会します。 http://baconipsum.com/ ## [](#anypoint-studio-で-rest-api-をコンシュームする)Anypoint Studio で REST API をコンシュームする Studio で REST API をコンシュームするには、HTTP Connector を設定し、File Write 操作を追加して、アプリケーションを実行します。 1. 最初に、Studio で HTTP リスナーと HTTP Request Connector を追加して設定します。HTTPS を使用したりアカウントをセットアップしたりする必要はありません。 ![HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-rest-api-example-1.png) Figure 1. HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー。 この時点で、API をコールして Web ブラウザーで ​`bacon ipsum`​ テキストを受信できます。 1. 次に、File Write コンポーネントを追加して ​`bacon ipsum`​ テキストの要求の出力をファイルシステムのファイルに保存します。 ![HTTP Listener Connector、HTTP Request Connector、File Write コンポーネントを使用したフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-rest-api-example-2.png) Figure 2. HTTP リスナー、HTTP Request Connector、File Write コンポーネントを使用したフロー。 最初の要素である HTTP Listener は、ローカルホストポート 8081 (デフォルト) 上で受信 GET 要求をリスンします。ブラウザーからリスナーをコールすると、フローがトリガーされます。 1. 最後に、次の構文を使用して要求を送信します。 http://localhost:8081? ``​ は REST API によって受け入れられるパラメーターで構成されます。HTTP Listener が HTTP Request を受信すると、アプリケーションによって ​``​ が一連のクエリパラメーターとして記録されます。HTTP Listener によってこれらのパラメーターがフローの次の要素である HTTP Request 操作に渡されます。この操作は、​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ でリモート REST API を照会するように設定されています。HTTP Request Connector では DataWeave 式を使用してメッセージのプロパティからクエリパラメーターを抽出し、クエリパラメーターを含めてリモート API の完全な URL を作成します。 たとえば、次のローカルブラウザー要求を入力するとします。 http://localhost:8081?type=meat-and-filler 結果として、アプリケーションで次のクエリが発行されます。 http://baconipsum.com/api/?type=meat-and-filler ### [](#http-connector-を設定する)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー)HTTP リスナー HTTP リスナーを設定するには、次の手順に従います。 1. HTTP Listener コンポーネントを選択します。 2. **\[Connector Configuration (コネクタ設定)\]**​ で、​![追加アイコン](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-add-plus.png)​ をクリックして、​**\[Host (ホスト)\]**​ を ​`localhost`​ に、​**\[Port (ポート)\]**​ を ​`8081`​ に設定します。 3. **\[OK\]**​ をクリックします。 ![ホストとポートを使用した HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-rest-api-example-3.png) Figure 3. ホストとポートを使用した HTTP リスナー設定。 1. HTTP リスナーのプロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に設定します。 ![パスを使用した HTTP リスナーのプロパティエディター](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-rest-api-example-4.png) Figure 4. パスを使用した HTTP リスナーのプロパティエディター。 #### [](#http-要求)HTTP 要求 1. **\[Connector Configuration (コネクタ設定)\]**​ で、​![追加アイコン](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-add-plus.png)​ をクリックして、​**\[Host (ホスト)\]**​ を ​`baconipsum.com`​ に、​**\[Port (ポート)\]**​ を ​`80`​ に、​**\[Base Path (ベースパス)\]**​ を ​`api`​ に設定します。この設定により、要求が ​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ に送信されます。 2. **\[OK\]**​ をクリックします。 ![HTTP Request Connector の設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-rest-api-example-5.png) Figure 5. HTTP Request Connector の設定。 1. プロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に、​**\[Method (メソッド)\]**​ を ​`GET`​ に設定します。 2. \[Query Parameters (クエリパラメーター)\] タブで、2 つのクエリパラメーターを追加します。 各 ​`value`​ 項目に、最初に HTTP リスナーに到達した要求のクエリパラメーターから指定された値を取得する Mule 式を入力します。
パラメーター 値

Type (型)

query-param

Name (名前)

type

Value (値)

#[message.attributes.queryParams['type']]
パラメーター 値

Type (型)

query-param

Name (名前)

sentences

Value (値)

`#[message.attributes.queryParams['sentences']]
![名前と値が含まれるクエリパラメーター](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-rest-api-example-6.png) Figure 6. 名前と値が含まれるクエリパラメーター。 Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、このアプリケーションでは ​`type`​ と ​`sentences`​ パラメーターのみを使用します。省略可能な ​`sentences`​ パラメーターによって、JSON 応答で返す文の数が決定されます。 ### [](#file-write-操作)File Write 操作 アプリケーションの出力をファイルに保存するように File Write コンポーネントのプロパティをセットアップします。 1. File Write コンポーネントをキャンバスにドラッグします。 2. プロパティエディターで、出力を保存するためのディレクトリとファイル名を設定します: `/tmp/output`​。 ![mruntime rest api example 2](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-rest-api-example-2.png) 3. プロパティエディターで、​**\[Path (パス)\]**​ のファイルシステムの実際のパスを指定します。 ![File Write プロパティエディターと \[Path (パス)\]](_images/mruntime-rest-api-example-7.png) Figure 7. File Write プロパティエディターと \[Path (パス)\]。 ### [](#アプリケーションを実行して-rest-api-をコンシュームする)アプリケーションを実行して REST API をコンシュームする 以下の手順でアプリケーションを実行します。 1. Studio のプロジェクト内で ​![実行アイコン](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-run-button.png)​ をクリックして Mule アプリケーションとして例を実行します。テスト 2. Web ブラウザーウィンドウでローカルホストポート 8081 で HTTP Listener を照会して、アプリケーションのフローをトリガーします。 http://localhost:8081?type=meat-and-filler Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、HTTP Request Connector をセットアップするときは、​`type`​ と ​`sentences`​ パラメーターのみを使用するようにコネクタをセットアップします。 - 最初のパラメーター=値のペアの前に ​`?`​ 演算子を追加する必要があります。 - 追加のパラメーター=値のペアを挿入するには、​`&`​ 演算子を使用します。 次のクエリは、ローカルホストポート 8081 で HTTP リスナーに送信できる例です。 http://localhost:8081?type=meat-and-filler http://localhost:8081?sentences=2 http://localhost:8081?type=all-meat&sentences=3 `type=meat-and-filler`​ の例では、次の出力が返されます。 \["Doner ullamco ea non, porchetta incididunt brisket ball tip in chuck ex bresaola beef tongue. Et aute ham hock kielbasa chuck fatback short ribs. Kevin in reprehenderit est esse, ham bacon ut ball tip. Laborum ut nulla ex irure t-bone flank, biltong cupidatat venison proident aliquip pork belly ham hock. In consequat proident, cillum labore pariatur nisi. Reprehenderit boudin beef ribs, frankfurter cillum enim pork loin consectetur kielbasa laboris. Hamburger prosciutto nisi, jerky biltong ex pork chop venison.","Fatback tongue anim, irure ut ut cupidatat occaecat eiusmod ham hock laborum commodo. Anim pig shank kielbasa, drumstick corned beef esse nostrud ham salami id laborum ribeye aute. Duis pancetta sunt magna occaecat dolor leberkas, short loin meatloaf flank enim pastrami. Prosciutto proident landjaeger deserunt tenderloin short loin. Adipisicing aute in bresaola meatball, ut frankfurter pastrami shoulder porchetta turducken strip steak doner. In filet mignon bresaola, sed deserunt pariatur eu mollit commodo shankle laborum. Andouille aliqua jowl pork chop jerky sed consequat turkey voluptate bacon pastrami.","Ground round elit boudin reprehenderit. Brisket shankle esse, leberkas veniam andouille rump proident drumstick. Consequat sausage do ut prosciutto nostrud andouille tongue ullamco bacon est exercitation. Do fugiat biltong est tempor short ribs reprehenderit adipisicing shoulder. Tail venison shank incididunt, hamburger adipisicing voluptate corned beef fugiat sirloin fatback in tri-tip nisi ut. Tail non excepteur, fugiat veniam corned beef dolore ex pig pork belly sint mollit chuck pork.","Pig hamburger dolore proident brisket landjaeger in boudin kielbasa ut elit. Velit incididunt boudin qui. Fatback anim adipisicing, pig jowl voluptate sirloin drumstick chicken esse. Strip steak consequat tenderloin pastrami, ullamco brisket hamburger bacon beef adipisicing. Tri-tip ham hock eu non et, flank dolore kevin. Et duis frankfurter, ut ullamco do non quis boudin andouille aliqua venison ham. Ut aliqua shoulder, aliquip pariatur bacon spare ribs irure.","Aliqua jerky frankfurter, swine ham in ground round sed qui laborum cow. Sint turducken shank ut ea id. Kevin dolore pig excepteur, anim ut magna. Enim consequat short ribs corned beef ham hock nostrud fugiat chuck. Tail spare ribs dolore boudin, andouille incididunt laboris occaecat strip steak. Cow frankfurter capicola, landjaeger cupidatat porchetta ad ground round voluptate."\] ## [](#スタンドアロン-xml-で-rest-api-をコンシュームする)スタンドアロン XML で REST API をコンシュームする スタンドアロン XML で REST API をコンシュームするには、HTTP リスナーと HTTP Request Connector を設定すると共に File Write コンポーネントを追加する必要があります。 ### [](#http-connector-を設定する-2)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー-2)HTTP リスナー HTTP リスナーを設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照してください。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` #### [](#http-要求-2)HTTP 要求 HTTP 要求を設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照する必要があります。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` ### [](#file-write-操作-2)File Write 操作 最後に、XML で File Write 操作を追加します。 ```xml ``` ### [](#xml)XML 完成した XML を確認します。 ```xml ``` ## [](#関連情報)関連情報 - [API からのデータのコンシューム](https://docs.mulesoft.com/jp/mule-runtime/4.7/consume-data-from-an-api) # REST API の例 次の例では、Anypoint Studio または Mule Runtime Engine のスタンドアロン XML を使用して、公開されている REST API からデータを取得する API を記述する方法を説明しています。この API の例では、lorem ipsum テキストを生成し、次の場所にある Bacon Ipsum REST API を照会します。 http://baconipsum.com/ ## [](#anypoint-studio-で-rest-api-をコンシュームする)Anypoint Studio で REST API をコンシュームする Studio で REST API をコンシュームするには、HTTP Connector を設定し、File Write 操作を追加して、アプリケーションを実行します。 1. 最初に、Studio で HTTP リスナーと HTTP Request Connector を追加して設定します。HTTPS を使用したりアカウントをセットアップしたりする必要はありません。 ![REST API をコンシュームするコンポーネント (Listener、Request、Error handling など) が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-api-example-1.png) Figure 1. HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー。 この時点で、API をコールして Web ブラウザーで ​`bacon ipsum`​ テキストを受信できます。 1. 次に、File Write コンポーネントを追加して ​`bacon ipsum`​ テキストの要求の出力をファイルシステムのファイルに保存します。 ![REST API をコンシュームするコンポーネント (Listener、Request、Write など) が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-api-example-2.png) Figure 2. HTTP リスナー、HTTP Request Connector、File Write コンポーネントを使用したフロー。 最初の要素である HTTP Listener は、ローカルホストポート 8081 (デフォルト) 上で受信 GET 要求をリスンします。ブラウザーからリスナーをコールすると、フローがトリガーされます。 1. 最後に、次の構文を使用して要求を送信します。 http://localhost:8081? ``​ は REST API によって受け入れられるパラメーターで構成されます。HTTP Listener が HTTP Request を受信すると、アプリケーションによって ​``​ が一連のクエリパラメーターとして記録されます。HTTP Listener によってこれらのパラメーターがフローの次の要素である HTTP Request 操作に渡されます。この操作は、​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ でリモート REST API を照会するように設定されています。HTTP Request Connector では DataWeave 式を使用してメッセージのプロパティからクエリパラメーターを抽出し、クエリパラメーターを含めてリモート API の完全な URL を作成します。 たとえば、次のローカルブラウザー要求を入力するとします。 http://localhost:8081?type=meat-and-filler 結果として、アプリケーションで次のクエリが発行されます。 http://baconipsum.com/api/?type=meat-and-filler ### [](#http-connector-を設定する)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー)HTTP リスナー HTTP リスナーを設定するには、次の手順に従います。 1. HTTP Listener コンポーネントを選択します。 2. **\[Connector Configuration (コネクタ設定)\]**​ で、​![追加アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-add-plus.png)​ をクリックして、​**\[Host (ホスト)\]**​ を ​`localhost`​ に、​**\[Port (ポート)\]**​ を ​`8081`​ に設定します。 3. **\[OK\]**​ をクリックします。 ![プロトコル、ホスト、ポート設定が表示されている HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-api-example-3.png) Figure 3. ホストとポートを使用した HTTP リスナー設定。 1. HTTP リスナーのプロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に設定します。 ![HTTP リスナーの設定 (パス、MIME タイプ、エラー処理など)](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-api-example-4.png) Figure 4. パスを使用した HTTP リスナーのプロパティエディター。 #### [](#http-要求)HTTP 要求 1. **\[Connector Configuration (コネクタ設定)\]**​ で、​![追加アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-add-plus.png)​ をクリックして、​**\[Host (ホスト)\]**​ を ​`baconipsum.com`​ に、​**\[Port (ポート)\]**​ を ​`80`​ に、​**\[Base Path (ベースパス)\]**​ を ​`api`​ に設定します。この設定により、要求が ​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ に送信されます。 2. **\[OK\]**​ をクリックします。 ![HTTP 要求の設定 (URL、ホスト、ポート、接続の詳細など)](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-api-example-5.png) Figure 5. HTTP Request Connector の設定。 1. プロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に、​**\[Method (メソッド)\]**​ を ​`GET`​ に設定します。 2. \[Query Parameters (クエリパラメーター)\] タブで、2 つのクエリパラメーターを追加します。 各 ​`value`​ 項目に、最初に HTTP リスナーに到達した要求のクエリパラメーターから指定された値を取得する Mule 式を入力します。
パラメーター 値

Type (型)

query-param

Name (名前)

type

Value (値)

#[message.attributes.queryParams['type']]
パラメーター 値

Type (型)

query-param

Name (名前)

sentences

Value (値)

`#[message.attributes.queryParams['sentences']]
![メソッド、パス、URL 設定が表示されている HTTP 要求の設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-api-example-6.png) Figure 6. 名前と値が含まれるクエリパラメーター。 Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、このアプリケーションでは ​`type`​ と ​`sentences`​ パラメーターのみを使用します。省略可能な ​`sentences`​ パラメーターによって、JSON 応答で返す文の数が決定されます。 ### [](#file-write-操作)File Write 操作 アプリケーションの出力をファイルに保存するように File Write コンポーネントのプロパティをセットアップします。 1. File Write コンポーネントをキャンバスにドラッグします。 2. プロパティエディターで、出力を保存するためのディレクトリとファイル名を設定します: `/tmp/output`​。 ![REST API をコンシュームするコンポーネント (Listener、Request、Write など) が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-api-example-2.png) 3. プロパティエディターで、​**\[Path (パス)\]**​ のファイルシステムの実際のパスを指定します。 ![パス、コンテンツタイプ、書き込みモードが表示されている File Write 操作の設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-rest-api-example-7.png) Figure 7. File Write プロパティエディターと \[Path (パス)\]。 ### [](#アプリケーションを実行して-rest-api-をコンシュームする)アプリケーションを実行して REST API をコンシュームする 以下の手順でアプリケーションを実行します。 1. Studio のプロジェクト内で ​![実行アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-run-button.png)​ をクリックして Mule アプリケーションとして例を実行します。テスト 2. Web ブラウザーウィンドウでローカルホストポート 8081 で HTTP Listener を照会して、アプリケーションのフローをトリガーします。 http://localhost:8081?type=meat-and-filler Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、HTTP Request Connector をセットアップするときは、​`type`​ と ​`sentences`​ パラメーターのみを使用するようにコネクタをセットアップします。 - 最初のパラメーター=値のペアの前に ​`?`​ 演算子を追加する必要があります。 - 追加のパラメーター=値のペアを挿入するには、​`&`​ 演算子を使用します。 次のクエリは、ローカルホストポート 8081 で HTTP リスナーに送信できる例です。 http://localhost:8081?type=meat-and-filler http://localhost:8081?sentences=2 http://localhost:8081?type=all-meat&sentences=3 `type=meat-and-filler`​ の例では、次の出力が返されます。 \["Doner ullamco ea non, porchetta incididunt brisket ball tip in chuck ex bresaola beef tongue. Et aute ham hock kielbasa chuck fatback short ribs. Kevin in reprehenderit est esse, ham bacon ut ball tip. Laborum ut nulla ex irure t-bone flank, biltong cupidatat venison proident aliquip pork belly ham hock. In consequat proident, cillum labore pariatur nisi. Reprehenderit boudin beef ribs, frankfurter cillum enim pork loin consectetur kielbasa laboris. Hamburger prosciutto nisi, jerky biltong ex pork chop venison.","Fatback tongue anim, irure ut ut cupidatat occaecat eiusmod ham hock laborum commodo. Anim pig shank kielbasa, drumstick corned beef esse nostrud ham salami id laborum ribeye aute. Duis pancetta sunt magna occaecat dolor leberkas, short loin meatloaf flank enim pastrami. Prosciutto proident landjaeger deserunt tenderloin short loin. Adipisicing aute in bresaola meatball, ut frankfurter pastrami shoulder porchetta turducken strip steak doner. In filet mignon bresaola, sed deserunt pariatur eu mollit commodo shankle laborum. Andouille aliqua jowl pork chop jerky sed consequat turkey voluptate bacon pastrami.","Ground round elit boudin reprehenderit. Brisket shankle esse, leberkas veniam andouille rump proident drumstick. Consequat sausage do ut prosciutto nostrud andouille tongue ullamco bacon est exercitation. Do fugiat biltong est tempor short ribs reprehenderit adipisicing shoulder. Tail venison shank incididunt, hamburger adipisicing voluptate corned beef fugiat sirloin fatback in tri-tip nisi ut. Tail non excepteur, fugiat veniam corned beef dolore ex pig pork belly sint mollit chuck pork.","Pig hamburger dolore proident brisket landjaeger in boudin kielbasa ut elit. Velit incididunt boudin qui. Fatback anim adipisicing, pig jowl voluptate sirloin drumstick chicken esse. Strip steak consequat tenderloin pastrami, ullamco brisket hamburger bacon beef adipisicing. Tri-tip ham hock eu non et, flank dolore kevin. Et duis frankfurter, ut ullamco do non quis boudin andouille aliqua venison ham. Ut aliqua shoulder, aliquip pariatur bacon spare ribs irure.","Aliqua jerky frankfurter, swine ham in ground round sed qui laborum cow. Sint turducken shank ut ea id. Kevin dolore pig excepteur, anim ut magna. Enim consequat short ribs corned beef ham hock nostrud fugiat chuck. Tail spare ribs dolore boudin, andouille incididunt laboris occaecat strip steak. Cow frankfurter capicola, landjaeger cupidatat porchetta ad ground round voluptate."\] ## [](#スタンドアロン-xml-で-rest-api-をコンシュームする)スタンドアロン XML で REST API をコンシュームする スタンドアロン XML で REST API をコンシュームするには、HTTP リスナーと HTTP Request Connector を設定すると共に File Write コンポーネントを追加する必要があります。 ### [](#http-connector-を設定する-2)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー-2)HTTP リスナー HTTP リスナーを設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照してください。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` #### [](#http-要求-2)HTTP 要求 HTTP 要求を設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照する必要があります。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` ### [](#file-write-操作-2)File Write 操作 最後に、XML で File Write 操作を追加します。 ```xml ``` ### [](#xml)XML 完成した XML を確認します。 ```xml ``` ## [](#関連情報)関連情報 - [API からのデータのコンシューム](https://docs.mulesoft.com/jp/mule-runtime/4.8/consume-data-from-an-api) # REST API の例 次の例では、Anypoint Studio または Mule Runtime Engine のスタンドアロン XML を使用して、公開されている REST API からデータを取得する API を記述する方法を説明しています。この API の例では、lorem ipsum テキストを生成し、次の場所にある Bacon Ipsum REST API を照会します。 http://baconipsum.com/ ## [](#anypoint-studio-で-rest-api-をコンシュームする)Anypoint Studio で REST API をコンシュームする Studio で REST API をコンシュームするには、HTTP Connector を設定し、File Write 操作を追加して、アプリケーションを実行します。 1. 最初に、Studio で HTTP リスナーと HTTP Request Connector を追加して設定します。HTTPS を使用したりアカウントをセットアップしたりする必要はありません。 ![REST API をコンシュームするコンポーネント (Listener、Request、Error handling など) が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-api-example-1.png) Figure 1. HTTP Listener Connector と HTTP Request Connector を使用した ConsumeRestAPI フロー。 この時点で、API をコールして Web ブラウザーで ​`bacon ipsum`​ テキストを受信できます。 1. 次に、File Write コンポーネントを追加して ​`bacon ipsum`​ テキストの要求の出力をファイルシステムのファイルに保存します。 ![REST API をコンシュームするコンポーネント (Listener、Request、Write など) が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-api-example-2.png) Figure 2. HTTP リスナー、HTTP Request Connector、File Write コンポーネントを使用したフロー。 最初の要素である HTTP Listener は、ローカルホストポート 8081 (デフォルト) 上で受信 GET 要求をリスンします。ブラウザーからリスナーをコールすると、フローがトリガーされます。 1. 最後に、次の構文を使用して要求を送信します。 http://localhost:8081? ``​ は REST API によって受け入れられるパラメーターで構成されます。HTTP Listener が HTTP Request を受信すると、アプリケーションによって ​``​ が一連のクエリパラメーターとして記録されます。HTTP Listener によってこれらのパラメーターがフローの次の要素である HTTP Request 操作に渡されます。この操作は、​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ でリモート REST API を照会するように設定されています。HTTP Request Connector では DataWeave 式を使用してメッセージのプロパティからクエリパラメーターを抽出し、クエリパラメーターを含めてリモート API の完全な URL を作成します。 たとえば、次のローカルブラウザー要求を入力するとします。 http://localhost:8081?type=meat-and-filler 結果として、アプリケーションで次のクエリが発行されます。 http://baconipsum.com/api/?type=meat-and-filler ### [](#http-connector-を設定する)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー)HTTP リスナー HTTP リスナーを設定するには、次の手順に従います。 1. HTTP Listener コンポーネントを選択します。 2. **\[Connector Configuration (コネクタ設定)\]**​ で、​![追加アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-add-plus.png)​ をクリックして、​**\[Host (ホスト)\]**​ を ​`localhost`​ に、​**\[Port (ポート)\]**​ を ​`8081`​ に設定します。 3. **\[OK\]**​ をクリックします。 ![プロトコル、ホスト、ポート設定が表示されている HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-api-example-3.png) Figure 3. ホストとポートを使用した HTTP リスナー設定。 1. HTTP リスナーのプロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に設定します。 ![HTTP リスナーの設定 (パス、MIME タイプ、エラー処理など)](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-api-example-4.png) Figure 4. パスを使用した HTTP リスナーのプロパティエディター。 #### [](#http-要求)HTTP 要求 1. **\[Connector Configuration (コネクタ設定)\]**​ で、​![追加アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-add-plus.png)​ をクリックして、​**\[Host (ホスト)\]**​ を ​`baconipsum.com`​ に、​**\[Port (ポート)\]**​ を ​`80`​ に、​**\[Base Path (ベースパス)\]**​ を ​`api`​ に設定します。この設定により、要求が ​`[http://baconipsum.com/api](http://baconipsum.com/api)`​ に送信されます。 2. **\[OK\]**​ をクリックします。 ![HTTP 要求の設定 (URL、ホスト、ポート、接続の詳細など)](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-api-example-5.png) Figure 5. HTTP Request Connector の設定。 1. プロパティエディターで、​**\[Path (パス)\]**​ を ​`/`​ に、​**\[Method (メソッド)\]**​ を ​`GET`​ に設定します。 2. \[Query Parameters (クエリパラメーター)\] タブで、2 つのクエリパラメーターを追加します。 各 ​`value`​ 項目に、最初に HTTP リスナーに到達した要求のクエリパラメーターから指定された値を取得する Mule 式を入力します。
パラメーター 値

Type (型)

query-param

Name (名前)

type

Value (値)

#[message.attributes.queryParams['type']]
パラメーター 値

Type (型)

query-param

Name (名前)

sentences

Value (値)

`#[message.attributes.queryParams['sentences']]
![メソッド、パス、URL 設定が表示されている HTTP 要求の設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-api-example-6.png) Figure 6. 名前と値が含まれるクエリパラメーター。 Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、このアプリケーションでは ​`type`​ と ​`sentences`​ パラメーターのみを使用します。省略可能な ​`sentences`​ パラメーターによって、JSON 応答で返す文の数が決定されます。 ### [](#file-write-操作)File Write 操作 アプリケーションの出力をファイルに保存するように File Write コンポーネントのプロパティをセットアップします。 1. File Write コンポーネントをキャンバスにドラッグします。 2. プロパティエディターで、出力を保存するためのディレクトリとファイル名を設定します: `/tmp/output`​。 ![REST API をコンシュームするコンポーネント (Listener、Request、Write など) が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-api-example-2.png) 3. プロパティエディターで、​**\[Path (パス)\]**​ のファイルシステムの実際のパスを指定します。 ![パス、コンテンツタイプ、書き込みモードが表示されている File Write 操作の設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-rest-api-example-7.png) Figure 7. File Write プロパティエディターと \[Path (パス)\]。 ### [](#アプリケーションを実行して-rest-api-をコンシュームする)アプリケーションを実行して REST API をコンシュームする 以下の手順でアプリケーションを実行します。 1. Studio のプロジェクト内で ​![実行アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-run-button.png)​ をクリックして Mule アプリケーションとして例を実行します。テスト 2. Web ブラウザーウィンドウでローカルホストポート 8081 で HTTP Listener を照会して、アプリケーションのフローをトリガーします。 http://localhost:8081?type=meat-and-filler Bacon Ipsum API ページには使用できるパラメーターのリストが記載されていますが、HTTP Request Connector をセットアップするときは、​`type`​ と ​`sentences`​ パラメーターのみを使用するようにコネクタをセットアップします。 - 最初のパラメーター=値のペアの前に ​`?`​ 演算子を追加する必要があります。 - 追加のパラメーター=値のペアを挿入するには、​`&`​ 演算子を使用します。 次のクエリは、ローカルホストポート 8081 で HTTP リスナーに送信できる例です。 http://localhost:8081?type=meat-and-filler http://localhost:8081?sentences=2 http://localhost:8081?type=all-meat&sentences=3 `type=meat-and-filler`​ の例では、次の出力が返されます。 \["Doner ullamco ea non, porchetta incididunt brisket ball tip in chuck ex bresaola beef tongue. Et aute ham hock kielbasa chuck fatback short ribs. Kevin in reprehenderit est esse, ham bacon ut ball tip. Laborum ut nulla ex irure t-bone flank, biltong cupidatat venison proident aliquip pork belly ham hock. In consequat proident, cillum labore pariatur nisi. Reprehenderit boudin beef ribs, frankfurter cillum enim pork loin consectetur kielbasa laboris. Hamburger prosciutto nisi, jerky biltong ex pork chop venison.","Fatback tongue anim, irure ut ut cupidatat occaecat eiusmod ham hock laborum commodo. Anim pig shank kielbasa, drumstick corned beef esse nostrud ham salami id laborum ribeye aute. Duis pancetta sunt magna occaecat dolor leberkas, short loin meatloaf flank enim pastrami. Prosciutto proident landjaeger deserunt tenderloin short loin. Adipisicing aute in bresaola meatball, ut frankfurter pastrami shoulder porchetta turducken strip steak doner. In filet mignon bresaola, sed deserunt pariatur eu mollit commodo shankle laborum. Andouille aliqua jowl pork chop jerky sed consequat turkey voluptate bacon pastrami.","Ground round elit boudin reprehenderit. Brisket shankle esse, leberkas veniam andouille rump proident drumstick. Consequat sausage do ut prosciutto nostrud andouille tongue ullamco bacon est exercitation. Do fugiat biltong est tempor short ribs reprehenderit adipisicing shoulder. Tail venison shank incididunt, hamburger adipisicing voluptate corned beef fugiat sirloin fatback in tri-tip nisi ut. Tail non excepteur, fugiat veniam corned beef dolore ex pig pork belly sint mollit chuck pork.","Pig hamburger dolore proident brisket landjaeger in boudin kielbasa ut elit. Velit incididunt boudin qui. Fatback anim adipisicing, pig jowl voluptate sirloin drumstick chicken esse. Strip steak consequat tenderloin pastrami, ullamco brisket hamburger bacon beef adipisicing. Tri-tip ham hock eu non et, flank dolore kevin. Et duis frankfurter, ut ullamco do non quis boudin andouille aliqua venison ham. Ut aliqua shoulder, aliquip pariatur bacon spare ribs irure.","Aliqua jerky frankfurter, swine ham in ground round sed qui laborum cow. Sint turducken shank ut ea id. Kevin dolore pig excepteur, anim ut magna. Enim consequat short ribs corned beef ham hock nostrud fugiat chuck. Tail spare ribs dolore boudin, andouille incididunt laboris occaecat strip steak. Cow frankfurter capicola, landjaeger cupidatat porchetta ad ground round voluptate."\] ## [](#スタンドアロン-xml-で-rest-api-をコンシュームする)スタンドアロン XML で REST API をコンシュームする スタンドアロン XML で REST API をコンシュームするには、HTTP リスナーと HTTP Request Connector を設定すると共に File Write コンポーネントを追加する必要があります。 ### [](#http-connector-を設定する-2)HTTP Connector を設定する HTTP リスナーと HTTP Request Connector を設定して、API をコールする方法と返す内容を指定します。 #### [](#http-リスナー-2)HTTP リスナー HTTP リスナーを設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照してください。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` #### [](#http-要求-2)HTTP 要求 HTTP 要求を設定するには、​**\[Connector Configuration (コネクタ設定)\]**​ と呼ばれる抽象的な要素を参照する必要があります。ここには、概要レベルの必須設定プロパティがいくつか含まれます。 ```xml ``` コネクタの ​`config-ref`​ 属性は、このコネクタ設定要素を参照します。今度は、参照される名前に一致する要素をフローの外側で作成する必要があります。 ```xml ``` ### [](#file-write-操作-2)File Write 操作 最後に、XML で File Write 操作を追加します。 ```xml ``` ### [](#xml)XML 完成した XML を確認します。 ```xml ``` ## [](#関連情報)関連情報 - [API からのデータのコンシューム](https://docs.mulesoft.com/jp/mule-runtime/4.9/consume-data-from-an-api) # Round Robin ルーター Round Robin ルーターは、リストに指定されている複数のルートを順番に繰り返し選択しますが、実行時に使用するルートは ​_1 つ_​だけです。前回のルートを記録し、同じルートを連続して使用することはありません。たとえば、Round Robin を最初に実行すると、リストの最初のルートが使用されます。次回の実行時には 2 番目のルートが選択されます。前回のルートがリストで最後のルートであれば、次は最初のルートが再び選択されます。 ```xml ``` 上の例では、Round Robin を最初に実行すると、​`Route1`​ と出力されます。次回は ​`Route2`​ を表示します。リストには 2 つのルートしかないため、3 回目は再び最初のルートが選択され、​`Route1`​ と出力されます。 ## [](#スロー)スロー - `MULE:ROUTING` # Round Robin ルーター Round Robin は、2 つ以上の処理ルートが含まれる Mule コンポーネントであり、フローでコンポーネントが実行されるたびに ​_1 つ_​のルートのみを実行します。Round Robin 内の各ルートは、1 つ以上のプロセッサーを含むことができるスコープです。Round Robin は最初のルートから Mule イベントへのルート内でプロセッサーの実行を開始し、結果をフローの次のプロセッサーに送信します。Round Robin は前回選択したルートを記録し、同じルートを連続して使用することはありません。たとえば、Round Robin が最初に実行されると、コンポーネントによって最初のルートが選択されます。次回の実行時には 2 番目のルートが選択されます。前回選択されたルートが最後のルートだった場合、最初のルートが実行されます。 Round Robin に達した Mule イベントのペイロード、変数、属性はルート内で処理を行うためにアクセスできます。ルート内の Mule イベントを変更すると、Round Robin 後のプロセッサーに伝播されます。 次の例は、Round Robin の機能を示しています。 ```xml ``` 1. Scheduler (​``​) が 10 秒ごとにフローを実行します。 2. Set Payload (​``​) によって配列 ​`[1,2,3,4]`​ が提供されます。 3. Round Robin の​_前_​の Logger コンポーネントによって最初のペイロード ​`[1,2,3,4]`​ が出力されます。 4. Round Robin の​_最初_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload - 4`​ を使用して最初のペイロードの最後の要素が削除され、そのルートの Logger によって生成されたペイロードがキー ​`"r1"`​ の値 ​`{ "r1": [1,2,3] }`​ として出力されます。 5. Round Robin の ​_2 つ目_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload + 5`​ を使用して新しい要素が最初のペイロードに追加され、そのルートの Logger によって生成されたペイロードがキー ​`"r2"`​ の値 ​`{ "r2": [1,2,3,4,5] }`​ として出力されます。 6. Round Robin の​_後_​の Logger コンポーネントによって、Round Robin の実行によって処理されたルートのペイロードが出力されます。最初の実行では ​`[1, 2, 3]`​ が出力されます。次の実行では ​`[1, 2, 3, 4, 5]`​ が出力されます。その次には ​`[1, 2, 3]`​ が出力される、といった具合になります。 次の抜粋では、ログに Round Robin ルーターの 3 つの実行が表示されています。この例では、フローによって ID が ​`4df56260`​、​`53eb1c50`​、​`59e12460`​ で始まる Mule イベントが処理されます。(この例は読みやすくするために編集されています)。 ... INFO 2022-12-19 10:02:30,233 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:30,290 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1,2,3\] } INFO 2022-12-19 10:02:30,291 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] INFO 2022-12-19 10:02:40,154 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:40,167 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 2 PAYLOAD: { "r2": \[1, 2, 3, 4, 5\] } INFO 2022-12-19 10:02:40,168 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3, 4, 5\] INFO 2022-12-19 10:02:50,151 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1, 2, 3\] } INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] ... ## [](#参照)参照 Round Robin によって、​``​ 要素に対して設定可能な属性が提供されます。
名前 XML 説明

ビジネスイベント

tracking:enable-default-events="true"

デフォルトは ​false​ です。ビジネスイベントを追跡できるようにします。ビジネスイベントを参照してください。
## [](#スロー)スロー - `MULE:ROUTING` # Round Robin ルーター Round Robin は、2 つ以上の処理ルートが含まれる Mule コンポーネントであり、フローでコンポーネントが実行されるたびに ​_1 つ_​のルートのみを実行します。Round Robin 内の各ルートは、1 つ以上のプロセッサーを含むことができるスコープです。Round Robin は最初のルートから Mule イベントへのルート内でプロセッサーの実行を開始し、結果をフローの次のプロセッサーに送信します。Round Robin は前回選択したルートを記録し、同じルートを連続して使用することはありません。たとえば、Round Robin が最初に実行されると、コンポーネントによって最初のルートが選択されます。次回の実行時には 2 番目のルートが選択されます。前回選択されたルートが最後のルートだった場合、最初のルートが実行されます。 Round Robin に達した Mule イベントのペイロード、変数、属性はルート内で処理を行うためにアクセスできます。ルート内の Mule イベントを変更すると、Round Robin 後のプロセッサーに伝播されます。 次の例は、Round Robin の機能を示しています。 ```xml ``` 1. Scheduler (​``​) が 10 秒ごとにフローを実行します。 2. Set Payload (​``​) によって配列 ​`[1,2,3,4]`​ が提供されます。 3. Round Robin の​_前_​の Loggerコンポーネントによって最初のペイロード ​`[1,2,3,4]`​ が出力されます。 4. Round Robin の​_最初_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload - 4`​ を使用して最初のペイロードの最後の要素が削除され、そのルートの Logger によって生成されたペイロードがキー ​`"r1"`​ の値 ​`{ "r1": [1,2,3] }`​ として出力されます。 5. Round Robin の ​_2 つ目_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload + 5`​ を使用して新しい要素が最初のペイロードに追加され、そのルートの Logger によって生成されたペイロードがキー ​`"r2"`​ の値 ​`{ "r2": [1,2,3,4,5] }`​ として出力されます。 6. Round Robin の​_後_​の Logger コンポーネントによって、Round Robin の実行によって処理されたルートのペイロードが出力されます。最初の実行では ​`[1, 2, 3]`​ が出力されます。次の実行では ​`[1, 2, 3, 4, 5]`​ が出力されます。その次には ​`[1, 2, 3]`​ が出力される、といった具合になります。 次の抜粋では、ログに Round Robin ルーターの 3 つの実行が表示されています。この例では、フローによって ID が ​`4df56260`​、​`53eb1c50`​、​`59e12460`​ で始まる Mule イベントが処理されます(この例は読みやすくするために編集されています)。 ... INFO 2022-12-19 10:02:30,233 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:30,290 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1,2,3\] } INFO 2022-12-19 10:02:30,291 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] INFO 2022-12-19 10:02:40,154 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:40,167 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 2 PAYLOAD: { "r2": \[1, 2, 3, 4, 5\] } INFO 2022-12-19 10:02:40,168 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3, 4, 5\] INFO 2022-12-19 10:02:50,151 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1, 2, 3\] } INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] ... ## [](#参照)参照 Round Robin によって、​``​ 要素に対して設定可能な属性が提供されます。
名前 XML 説明

ビジネスイベント

tracking:enable-default-events="true"

デフォルトは ​false​ です。ビジネスイベントを追跡できるようにします。ビジネスイベントを参照してください。
## [](#スロー)スロー - `MULE:ROUTING` # Round Robin ルーター Round Robin は、2 つ以上の処理ルートが含まれる Mule コンポーネントであり、フローでコンポーネントが実行されるたびに ​_1 つ_​のルートのみを実行します。Round Robin 内の各ルートは、1 つ以上のプロセッサーを含むことができるスコープです。Round Robin は最初のルートから Mule イベントへのルート内でプロセッサーの実行を開始し、結果をフローの次のプロセッサーに送信します。Round Robin は前回選択したルートを記録し、同じルートを連続して使用することはありません。たとえば、Round Robin が最初に実行されると、コンポーネントによって最初のルートが選択されます。次回の実行時には 2 番目のルートが選択されます。前回選択されたルートが最後のルートだった場合、最初のルートが実行されます。 Round Robin に達した Mule イベントのペイロード、変数、属性はルート内で処理を行うためにアクセスできます。ルート内の Mule イベントを変更すると、Round Robin 後のプロセッサーに伝播されます。 次の例は、Round Robin の機能を示しています。 ```xml ``` 1. Scheduler (​``​) が 10 秒ごとにフローを実行します。 2. Set Payload (​``​) によって配列 ​`[1,2,3,4]`​ が提供されます。 3. Round Robin の​_前_​の Logger コンポーネントによって最初のペイロード ​`[1,2,3,4]`​ が出力されます。 4. Round Robin の​_最初_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload - 4`​ を使用して最初のペイロードの最後の要素が削除され、そのルートの Logger によって生成されたペイロードがキー ​`"r1"`​ の値 ​`{ "r1": [1,2,3] }`​ として出力されます。 5. Round Robin の ​_2 つ目_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload + 5`​ を使用して新しい要素が最初のペイロードに追加され、そのルートの Logger によって生成されたペイロードがキー ​`"r2"`​ の値 ​`{ "r2": [1,2,3,4,5] }`​ として出力されます。 6. Round Robin の​_後_​の Logger コンポーネントによって、Round Robin の実行によって処理されたルートのペイロードが出力されます。最初の実行では ​`[1, 2, 3]`​ が出力されます。次の実行では ​`[1, 2, 3, 4, 5]`​ が出力されます。その次には ​`[1, 2, 3]`​ が出力される、といった具合になります。 次の抜粋では、ログに Round Robin ルーターの 3 つの実行が表示されています。この例では、フローによって ID が ​`4df56260`​、​`53eb1c50`​、​`59e12460`​ で始まる Mule イベントが処理されます。(この例は読みやすくするために編集されています)。 ... INFO 2022-12-19 10:02:30,233 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:30,290 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1,2,3\] } INFO 2022-12-19 10:02:30,291 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] INFO 2022-12-19 10:02:40,154 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:40,167 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 2 PAYLOAD: { "r2": \[1, 2, 3, 4, 5\] } INFO 2022-12-19 10:02:40,168 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3, 4, 5\] INFO 2022-12-19 10:02:50,151 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1, 2, 3\] } INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] ... ## [](#参照)参照 Round Robin によって、​``​ 要素に対して設定可能な属性が提供されます。
名前 XML 説明

ビジネスイベント

tracking:enable-default-events="true"

デフォルトは ​false​ です。ビジネスイベントを追跡できるようにします。ビジネスイベントを参照してください。
## [](#スロー)スロー - `MULE:ROUTING` # Round Robin ルーター Round Robin は、2 つ以上の処理ルートが含まれる Mule コンポーネントであり、フローでコンポーネントが実行されるたびに ​_1 つ_​のルートのみを実行します。Round Robin 内の各ルートは、1 つ以上のプロセッサーを含むことができるスコープです。Round Robin は最初のルートから Mule イベントへのルート内でプロセッサーの実行を開始し、結果をフローの次のプロセッサーに送信します。Round Robin は前回選択したルートを記録し、同じルートを連続して使用することはありません。たとえば、Round Robin が最初に実行されると、コンポーネントによって最初のルートが選択されます。次回の実行時には 2 番目のルートが選択されます。前回選択されたルートが最後のルートだった場合、最初のルートが実行されます。 Round Robin に達した Mule イベントのペイロード、変数、属性はルート内で処理を行うためにアクセスできます。ルート内の Mule イベントを変更すると、Round Robin 後のプロセッサーに伝播されます。 次の例は、Round Robin の機能を示しています。 ```xml ``` 1. Scheduler (​``​) が 10 秒ごとにフローを実行します。 2. Set Payload (​``​) によって配列 ​`[1,2,3,4]`​ が提供されます。 3. Round Robin の​_前_​の Logger コンポーネントによって最初のペイロード ​`[1,2,3,4]`​ が出力されます。 4. Round Robin の​_最初_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload - 4`​ を使用して最初のペイロードの最後の要素が削除され、そのルートの Logger によって生成されたペイロードがキー ​`"r1"`​ の値 ​`{ "r1": [1,2,3] }`​ として出力されます。 5. Round Robin の ​_2 つ目_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload + 5`​ を使用して新しい要素が最初のペイロードに追加され、そのルートの Logger によって生成されたペイロードがキー ​`"r2"`​ の値 ​`{ "r2": [1,2,3,4,5] }`​ として出力されます。 6. Round Robin の​_後_​の Logger コンポーネントによって、Round Robin の実行によって処理されたルートのペイロードが出力されます。最初の実行では ​`[1, 2, 3]`​ が出力されます。次の実行では ​`[1, 2, 3, 4, 5]`​ が出力されます。その次には ​`[1, 2, 3]`​ が出力される、といった具合になります。 次の抜粋では、ログに Round Robin ルーターの 3 つの実行が表示されています。この例では、フローによって ID が ​`4df56260`​、​`53eb1c50`​、​`59e12460`​ で始まる Mule イベントが処理されます。(この例は読みやすくするために編集されています)。 ... INFO 2022-12-19 10:02:30,233 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:30,290 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1,2,3\] } INFO 2022-12-19 10:02:30,291 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] INFO 2022-12-19 10:02:40,154 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:40,167 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 2 PAYLOAD: { "r2": \[1, 2, 3, 4, 5\] } INFO 2022-12-19 10:02:40,168 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3, 4, 5\] INFO 2022-12-19 10:02:50,151 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1, 2, 3\] } INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] ... ## [](#参照)参照 Round Robin によって、​``​ 要素に対して設定可能な属性が提供されます。
名前 XML 説明

ビジネスイベント

tracking:enable-default-events="true"

デフォルトは ​false​ です。ビジネスイベントを追跡できるようにします。ビジネスイベント を参照してください。
## [](#スロー)スロー - `MULE:ROUTING` # Round Robin ルーター Round Robin は、2 つ以上の処理ルートが含まれる Mule コンポーネントであり、フローでコンポーネントが実行されるたびに ​_1 つ_​のルートのみを実行します。Round Robin 内の各ルートは、1 つ以上のプロセッサーを含むことができるスコープです。Round Robin は最初のルートから Mule イベントへのルート内でプロセッサーの実行を開始し、結果をフローの次のプロセッサーに送信します。Round Robin は前回選択したルートを記録し、同じルートを連続して使用することはありません。たとえば、Round Robin が最初に実行されると、コンポーネントによって最初のルートが選択されます。次回の実行時には 2 番目のルートが選択されます。前回選択されたルートが最後のルートだった場合、最初のルートが実行されます。 Round Robin に達した Mule イベントのペイロード、変数、属性はルート内で処理を行うためにアクセスできます。ルート内の Mule イベントを変更すると、Round Robin 後のプロセッサーに伝播されます。 次の例は、Round Robin の機能を示しています。 ```xml ``` 1. Scheduler (​``​) が 10 秒ごとにフローを実行します。 2. Set Payload (​``​) によって配列 ​`[1,2,3,4]`​ が提供されます。 3. Round Robin の​_前_​の Logger コンポーネントによって最初のペイロード ​`[1,2,3,4]`​ が出力されます。 4. Round Robin の​_最初_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload - 4`​ を使用して最初のペイロードの最後の要素が削除され、そのルートの Logger によって生成されたペイロードがキー ​`"r1"`​ の値 ​`{ "r1": [1,2,3] }`​ として出力されます。 5. Round Robin の ​_2 つ目_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload + 5`​ を使用して新しい要素が最初のペイロードに追加され、そのルートの Logger によって生成されたペイロードがキー ​`"r2"`​ の値 ​`{ "r2": [1,2,3,4,5] }`​ として出力されます。 6. Round Robin の​_後_​の Logger コンポーネントによって、Round Robin の実行によって処理されたルートのペイロードが出力されます。最初の実行では ​`[1, 2, 3]`​ が出力されます。次の実行では ​`[1, 2, 3, 4, 5]`​ が出力されます。その次には ​`[1, 2, 3]`​ が出力される、といった具合になります。 次の抜粋では、ログに Round Robin ルーターの 3 つの実行が表示されています。この例では、フローによって ID が ​`4df56260`​、​`53eb1c50`​、​`59e12460`​ で始まる Mule イベントが処理されます。(この例は読みやすくするために編集されています)。 ... INFO 2022-12-19 10:02:30,233 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:30,290 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1,2,3\] } INFO 2022-12-19 10:02:30,291 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] INFO 2022-12-19 10:02:40,154 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:40,167 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 2 PAYLOAD: { "r2": \[1, 2, 3, 4, 5\] } INFO 2022-12-19 10:02:40,168 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3, 4, 5\] INFO 2022-12-19 10:02:50,151 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1, 2, 3\] } INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] ... ## [](#参照)参照 Round Robin によって、​``​ 要素に対して設定可能な属性が提供されます。
名前 XML 説明

ビジネスイベント

tracking:enable-default-events="true"

デフォルトは ​false​ です。ビジネスイベントを追跡できるようにします。ビジネスイベント を参照してください。
## [](#スロー)スロー - `MULE:ROUTING` # Round Robin ルーター Round Robin は、2 つ以上の処理ルートが含まれる Mule コンポーネントであり、フローでコンポーネントが実行されるたびに ​_1 つ_​のルートのみを実行します。Round Robin 内の各ルートは、1 つ以上のプロセッサーを含むことができるスコープです。Round Robin は最初のルートから Mule イベントへのルート内でプロセッサーの実行を開始し、結果をフローの次のプロセッサーに送信します。Round Robin は前回選択したルートを記録し、同じルートを連続して使用することはありません。たとえば、Round Robin が最初に実行されると、コンポーネントによって最初のルートが選択されます。次回の実行時には 2 番目のルートが選択されます。前回選択されたルートが最後のルートだった場合、最初のルートが実行されます。 Round Robin に達した Mule イベントのペイロード、変数、属性はルート内で処理を行うためにアクセスできます。ルート内の Mule イベントを変更すると、Round Robin 後のプロセッサーに伝播されます。 次の例は、Round Robin の機能を示しています。 ```xml ``` 1. Scheduler (​``​) が 10 秒ごとにフローを実行します。 2. Set Payload (​``​) によって配列 ​`[1,2,3,4]`​ が提供されます。 3. Round Robin の​_前_​の Logger コンポーネントによって最初のペイロード ​`[1,2,3,4]`​ が出力されます。 4. Round Robin の​_最初_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload - 4`​ を使用して最初のペイロードの最後の要素が削除され、そのルートの Logger によって生成されたペイロードがキー ​`"r1"`​ の値 ​`{ "r1": [1,2,3] }`​ として出力されます。 5. Round Robin の ​_2 つ目_​のルート (​``​) である Set Payload コンポーネントによって、DataWeave 式 ​`payload + 5`​ を使用して新しい要素が最初のペイロードに追加され、そのルートの Logger によって生成されたペイロードがキー ​`"r2"`​ の値 ​`{ "r2": [1,2,3,4,5] }`​ として出力されます。 6. Round Robin の​_後_​の Logger コンポーネントによって、Round Robin の実行によって処理されたルートのペイロードが出力されます。最初の実行では ​`[1, 2, 3]`​ が出力されます。次の実行では ​`[1, 2, 3, 4, 5]`​ が出力されます。その次には ​`[1, 2, 3]`​ が出力される、といった具合になります。 次の抜粋では、ログに Round Robin ルーターの 3 つの実行が表示されています。この例では、フローによって ID が ​`4df56260`​、​`53eb1c50`​、​`59e12460`​ で始まる Mule イベントが処理されます。(この例は読みやすくするために編集されています)。 ... INFO 2022-12-19 10:02:30,233 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:30,290 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1,2,3\] } INFO 2022-12-19 10:02:30,291 ...event: 4df56260-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] INFO 2022-12-19 10:02:40,154 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:40,167 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 2 PAYLOAD: { "r2": \[1, 2, 3, 4, 5\] } INFO 2022-12-19 10:02:40,168 ...event: 53eb1c50-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3, 4, 5\] INFO 2022-12-19 10:02:50,151 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD BEFORE ROUND ROBIN: \[1, 2, 3, 4\] INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] ROUTE 1 PAYLOAD: { "r1": \[1, 2, 3\] } INFO 2022-12-19 10:02:50,154 ...event: 59e12460-7fc7-11ed-957f-147ddaaf4f97\] PAYLOAD OUTSIDE ROUND ROBIN: \[1, 2, 3\] ... ## [](#参照)参照 Round Robin によって、​``​ 要素に対して設定可能な属性が提供されます。
名前 XML 説明

ビジネスイベント

tracking:enable-default-events="true"

デフォルトは ​false​ です。ビジネスイベントを追跡できるようにします。ビジネスイベント を参照してください。
## [](#スロー)スロー - `MULE:ROUTING` # Scatter-Gather ルーター Scatter-Gather コンポーネントは、異なるイベントプロセッサーを持つ異なる並列処理ルートで Mule イベントを処理するルーティングイベントプロセッサーです。各ルートは、Mule イベントへの参照を受け取り、1 つ以上の一連のイベントプロセッサーを実行します。各ルートは個別のスレッドを使用してイベントプロセッサーを実行します。実行後の Mule イベントは、元と同じ未変更の Mule イベントか、もしくは独自のペイロード、属性、変数を持つ新しい Mule イベントになります。Scatter-Gather コンポーネントは、各処理ルートから返された Mule イベントを新しい Mule イベントとして統合し、すべてのルートが正常に完了した場合にのみ、この Mule イベントを次のイベントプロセッサーに渡します。 Scatter-Gather コンポーネントは、複数のルートを (順次ではなく) 並列に実行します。ルートを並列実行することで、Mule アプリケーションの効率が大幅に向上し、順次処理よりも多くの情報を提供できます。 Scatter-Gather コンポーネントは、反復可能ストリームを処理します。失われる前に 1 回だけ読み取ることができる反復不可能なストリームは処理しません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 Scatter-Gather コンポーネントの詳細な動作を次の図に示します。 ![Scatter-Gather コンポーネントの図](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-scatter-gather.png)
1Scatter-Gather コンポーネントは Mule イベントを受け取って、この Mule イベントの参照を各処理ルートに送信します。
2各処理ルートは並列に実行を開始します。ルート内のすべてのプロセッサーが処理を完了すると、そのルートは Mule イベントを返します。この Mule イベントは、元と同じ未変更の Mule イベントか、もしくはルート内のプロセッサーによって変更が加えられて作成された新しい Mule イベントになります。
3すべての処理ルートが処理を完了すると、Scatter-Gather コンポーネントはすべてのルートから返された Mule イベントを統合して、フロー内の次のコンポーネントに渡します。
Scatter-Gather コンポーネントは、2 本以上のルートで設定してください。そうしないと、Mule アプリケーションは例外を返して実行されません。
## [](#変数の伝播)変数の伝播 すべてのルートは同じ初期変数値で開始します。特定のルート内の変数の変更は他のルートに影響しません。そのため、1 つのルートで変数が追加されたり変更されたりした場合、集約後に、その値はそのルートによって定義されます。複数のルートによって変数が追加されたり変更されたりした場合、その値はすべてのルート内のその変数について定義されたすべての値のリストに追加されます。例: ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "newValue", var3: ["appleVal, bananaVal, otherVal"], var4: "val4"}` ## [](#scatter-gather-ルート内のエラー処理)Scatter-Gather ルート内のエラー処理 Scatter-Gather コンポーネントの各ルートで Try スコープを使用して、ルートのイベントプロセッサーで生成されるエラーを処理できます。実行されたいずれかのルートでエラーが発生すると、Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ 種別のエラーをスローし、フローの処理はその Scatter-Gather コンポーネントから先には進みません。その代わりに、フローはエラー処理イベントプロセッサーに分岐します。 `MULE:COMPOSITE_ROUTING`​ エラーオブジェクトは、失敗したルートからのエラーだけではなく、正常に完了したルートからの Mule イベントも収集します。そのためアプリケーションは、エラー処理イベントプロセッサーを使用して、完了したルートからの Mule イベントを処理できます。 2 つのケースを使用して、この仕組みを分かりやすく説明します。 - Scatter-Gather コンポーネントの各ルートに Try スコープがあるケース。 いずれか 1 本のルートでエラーが生成され、そのルートの Try スコープで ​`on-error-continue`​ エラーハンドラーを使用して正常に処理されたため、そのルートは正常に完了します。Scatter-Gather コンポーネントは、すべてのルートからの Mule イベントを統合して新しい Mule イベントを生成し、統合したイベントを次のイベントプロセッサーに渡します。 - Scatter-Gather コンポーネントのいずれかのルートが Try スコープを持たないか、またはそのルートの Try スコープで該当のエラー種別を処理できないエラーハンドラーを使用しているか、あるいはエラーハンドラーの種別が ​`on-error-propagate`​ であるケース。 このルートでエラーが発生すると、ルートは失敗して Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ エラーをスローします。フローは、完了したルートからの Mule イベントを処理できるエラー処理イベントプロセッサーに分岐します。 こうしたエラーの処理の例: ```xml ``` ## [](#scatter-gather-でのタイムアウトエラーの処理)Scatter-Gather でのタイムアウトエラーの処理 Scatter-Gather コンポーネントでタイムアウトを設定してある場合、そのタイムアウト時間内にルートが処理を完了しないと、そのルートは ​`MULE:TIMEOUT`​ エラーを返します。このエラーは、ルートで発生する他のエラーと同じように処理されます。各ルートが (処理を正常に完了するか、または ​`MULE:TIMEOUT`​ エラーをスローして) 完了すると、成功した結果とエラーが Scatter-Gather コンポーネントによって収集され、​`MULE:COMPOSITE_ROUTING`​ エラーとしてスローされます。このエラーは、設定されているエラーハンドラーで処理されます。 ## [](#サンプルプロジェクト)サンプルプロジェクト Scatter-Gather コンポーネントの使い方の詳細を見るには、Anypoint Studio で Anypoint Exchange からサンプルプロジェクトの ​_Scatter-Gather Flow Control (スキャッターギャザーフロー制御)_​ をダウンロードします。このサンプルは、データを並列に集約して結果を JSON で返すための Scatter-Gather 制御フローを示します。 また、このサンプルは用意されているデータを、集約する 2 つのリソースへの入力として使用します。このデータは、2 人の取引先責任者の情報を表し、次の構造となっています。

リソース

firstname

surname

phone

email

contacts-1.csv

John

Doe

096548763

john.doe@texasComp.com

contacts-2.csv

Jane

Doe

091558780

jane.doe@texasComp.com
データの集約には DataWeave が使用されます。取引先責任者の情報は、両方のリソースからのデータを表す JSON 構造に集約されます。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#scatter-gather-xml-リファレンス)Scatter-Gather XML リファレンス
要素 説明

scatter-gather

複数の対象に要求メッセージを同時に送信します。応答をすべてのルートから収集して、単一のメッセージに集約します。

属性

timeout

送信したメッセージからの応答のタイムアウトをミリ秒単位で指定します。0 または負の値を指定すると、タイムアウトは設定されません。

maxConcurrency

処理する並列ルートの最大数を指定します。
デフォルトでは、すべてのルートが並列処理されます。

この値を 1 に設定すると、scatter-gather はルートを 1 本ずつ順次処理します。

target

対象変数の名前。

targetValue

対象変数に格納するデータの値。
設定しないと、デフォルト値の ​#[payload]​ が使用されます。
この項目は、変数が受け入れるすべての値を受け入れます。

  • サポートされる任意のデータ型。

  • DataWeave 式。

  • キーワードの ​payload​、​attributes​、​message​。​vars​ は​受け入れられません​。
子要素 説明

route

scatter-gather ルーター内のいずれかのルート。
### [](#スロー)スロー - `MULE:ROUTING` - `MULE:COMPOSITE_ROUTING` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management#tx_scopes_routers) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept) # Scatter-Gather ルーター Scatter-Gather コンポーネントは、異なるイベントプロセッサーを持つ異なる並列処理ルートで Mule イベントを処理するルーティングイベントプロセッサーです。各ルートは、Mule イベントへの参照を受け取り、1 つ以上の一連のイベントプロセッサーを実行します。各ルートは個別のスレッドを使用してイベントプロセッサーを実行します。実行後の Mule イベントは、元と同じ未変更の Mule イベントか、もしくは独自のペイロード、属性、変数を持つ新しい Mule イベントになります。Scatter-Gather コンポーネントは、各処理ルートから返された Mule イベントを新しい Mule イベントとして統合し、すべてのルートが正常に完了した場合にのみ、この Mule イベントを次のイベントプロセッサーに渡します。 Scatter-Gather コンポーネントは、複数のルートを (順次ではなく) 並列に実行します。ルートを並列実行することで、Mule アプリケーションの効率が大幅に向上し、順次処理よりも多くの情報を提供できます。 Scatter-Gather コンポーネントは、反復可能ストリームを処理します。失われる前に 1 回だけ読み取ることができる反復不可能なストリームは処理しません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 Scatter-Gather コンポーネントの詳細な動作を次の図に示します。 ![Scatter-Gather コンポーネントの図](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-scatter-gather.png)
1Scatter-Gather コンポーネントは Mule イベントを受け取って、この Mule イベントの参照を各処理ルートに送信します。
2各処理ルートは並列に実行を開始します。ルート内のすべてのプロセッサーが処理を完了すると、そのルートは Mule イベントを返します。この Mule イベントは、元と同じ未変更の Mule イベントか、もしくはルート内のプロセッサーによって変更が加えられて作成された新しい Mule イベントになります。
3すべての処理ルートが処理を完了すると、Scatter-Gather コンポーネントはすべてのルートから返された Mule イベントを統合して、フロー内の次のコンポーネントに渡します。
Scatter-Gather コンポーネントは、2 本以上のルートで設定してください。そうしないと、Mule アプリケーションは例外を返して実行されません。
## [](#結果)結果 すべてのルートが完了すると、コンポーネントによって次の形式で結果が出力されます: `{0: messageFromRoute0, 1: messageFromRoute1, …​}` 生成されたすべてのペイロードを配列に抽出するには、次のような DataWeave スクリプトを使用します。 ```dw flatten(valuesOf(payload) map ((item, index) -> item.*payload)) ``` ## [](#変数の伝播)変数の伝播 すべてのルートは同じ初期変数値で開始します。特定のルート内の変数の変更は他のルートに影響しません。そのため、1 つのルートで変数が追加されたり変更されたりした場合、集約後に、その値はそのルートによって定義されます。複数のルートによって変数が追加されたり変更されたりした場合、その値はすべてのルート内のその変数について定義されたすべての値のリストに追加されます。例: ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "newValue", var3: ["appleVal, bananaVal, otherVal"], var4: "val4"}` ## [](#scatter-gather-ルート内のエラー処理)Scatter-Gather ルート内のエラー処理 Scatter-Gather コンポーネントの各ルートで Try スコープを使用して、ルートのイベントプロセッサーで生成されるエラーを処理できます。実行されたいずれかのルートでエラーが発生すると、Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ 種別のエラーをスローし、フローの処理はその Scatter-Gather コンポーネントから先には進みません。その代わりに、フローはエラー処理イベントプロセッサーに分岐します。 `MULE:COMPOSITE_ROUTING`​ エラーオブジェクトは、失敗したルートからのエラーだけではなく、正常に完了したルートからの Mule イベントも収集します。そのためアプリケーションは、エラー処理イベントプロセッサーを使用して、完了したルートからの Mule イベントを処理できます。 2 つのケースを使用して、この仕組みを分かりやすく説明します。 - Scatter-Gather コンポーネントの各ルートに Try スコープがあるケース。 いずれか 1 本のルートでエラーが生成され、そのルートの Try スコープで ​`on-error-continue`​ エラーハンドラーを使用して正常に処理されたため、そのルートは正常に完了します。Scatter-Gather コンポーネントは、すべてのルートからの Mule イベントを統合して新しい Mule イベントを生成し、統合したイベントを次のイベントプロセッサーに渡します。 - Scatter-Gather コンポーネントのいずれかのルートが Try スコープを持たないか、またはそのルートの Try スコープで該当のエラー種別を処理できないエラーハンドラーを使用しているか、あるいはエラーハンドラーの種別が ​`on-error-propagate`​ であるケース。 このルートでエラーが発生すると、ルートは失敗して Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ エラーをスローします。フローは、完了したルートからの Mule イベントを処理できるエラー処理イベントプロセッサーに分岐します。 こうしたエラーの処理の例: ```xml ``` ## [](#scatter-gather-でのタイムアウトエラーの処理)Scatter-Gather でのタイムアウトエラーの処理 Scatter-Gather コンポーネントでタイムアウトを設定してある場合、そのタイムアウト時間内にルートが処理を完了しないと、そのルートは ​`MULE:TIMEOUT`​ エラーを返します。このエラーは、ルートで発生する他のエラーと同じように処理されます。各ルートが (処理を正常に完了するか、または ​`MULE:TIMEOUT`​ エラーをスローして) 完了すると、成功した結果とエラーが Scatter-Gather コンポーネントによって収集され、​`MULE:COMPOSITE_ROUTING`​ エラーとしてスローされます。このエラーは、設定されているエラーハンドラーで処理されます。 ## [](#サンプルプロジェクト)サンプルプロジェクト Scatter-Gather コンポーネントの使い方の詳細を見るには、Anypoint Studio で Anypoint Exchange からサンプルプロジェクトの ​_Scatter-Gather Flow Control (スキャッターギャザーフロー制御)_​ をダウンロードします。このサンプルは、データを並列に集約して結果を JSON で返すための Scatter-Gather 制御フローを示します。 また、このサンプルは用意されているデータを、集約する 2 つのリソースへの入力として使用します。このデータは、2 人の取引先責任者の情報を表し、次の構造となっています。

リソース

firstname

surname

phone

email

contacts-1.csv

John

Doe

096548763

john.doe@texasComp.com

contacts-2.csv

Jane

Doe

091558780

jane.doe@texasComp.com
データの集約には DataWeave が使用されます。取引先責任者の情報は、両方のリソースからのデータを表す JSON 構造に集約されます。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#scatter-gather-xml-リファレンス)Scatter-Gather XML リファレンス
要素 説明

scatter-gather

複数の対象に要求メッセージを同時に送信します。応答をすべてのルートから収集して、単一のメッセージに集約します。

属性

timeout

送信したメッセージからの応答のタイムアウトをミリ秒単位で指定します。0 または負の値を指定すると、タイムアウトは設定されません。

maxConcurrency

処理する並列ルートの最大数を指定します。
デフォルトでは、すべてのルートが並列処理されます。

この値を 1 に設定すると、scatter-gather はルートを 1 本ずつ順次処理します。

target

対象変数の名前。

targetValue

対象変数に格納するデータの値。
設定しないと、デフォルト値の ​#[payload]​ が使用されます。
この項目は、変数が受け入れるすべての値を受け入れます。

  • サポートされる任意のデータ型。

  • DataWeave 式。

  • キーワードの ​payload​、​attributes​、​message​。​vars​ は​受け入れられません​。
子要素 説明

route

scatter-gather ルーター内のいずれかのルート。
### [](#スロー)スロー - `MULE:ROUTING` - `MULE:COMPOSITE_ROUTING` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management#tx_scopes_routers) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept) # Scatter-Gather ルーター Scatter-Gather コンポーネントは、異なるイベントプロセッサーを持つ異なる並列処理ルートで Mule イベントを処理するルーティングイベントプロセッサーです。各ルートは、Mule イベントへの参照を受け取り、1 つ以上の一連のイベントプロセッサーを実行します。各ルートは個別のスレッドを使用してイベントプロセッサーを実行します。実行後の Mule イベントは、元と同じ未変更の Mule イベントか、もしくは独自のペイロード、属性、変数を持つ新しい Mule イベントになります。Scatter-Gather コンポーネントは、各処理ルートから返された Mule イベントを新しい Mule イベントとして統合し、すべてのルートが正常に完了した場合にのみ、この Mule イベントを次のイベントプロセッサーに渡します。 Scatter-Gather コンポーネントは、複数のルートを (順次ではなく) 並列に実行します。ルートを並列実行することで、Mule アプリケーションの効率が大幅に向上し、順次処理よりも多くの情報を提供できます。 Scatter-Gather コンポーネントは、反復可能ストリームを処理します。失われる前に 1 回だけ読み取ることができる反復不可能なストリームは処理しません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 Scatter-Gather コンポーネントの詳細な動作を次の図に示します。 ![Scatter-Gather コンポーネントの図](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-scatter-gather.png)
1Scatter-Gather コンポーネントは Mule イベントを受け取って、この Mule イベントの参照を各処理ルートに送信します。
2各処理ルートは並列に実行を開始します。ルート内のすべてのプロセッサーが処理を完了すると、そのルートは Mule イベントを返します。この Mule イベントは、元と同じ未変更の Mule イベントか、もしくはルート内のプロセッサーによって変更が加えられて作成された新しい Mule イベントになります。
3すべての処理ルートが処理を完了すると、Scatter-Gather コンポーネントはすべてのルートから返された Mule イベントを統合して、フロー内の次のコンポーネントに渡します。
Scatter-Gather コンポーネントは、2 本以上のルートで設定してください。そうしないと、Mule アプリケーションは例外を返して実行されません。
## [](#結果)結果 すべてのルートが完了すると、コンポーネントによって次の形式で結果が出力されます: `{0: messageFromRoute0, 1: messageFromRoute1, …​}` 生成されたすべてのペイロードを配列に抽出するには、次のような DataWeave スクリプトを使用します。 ```dw flatten(valuesOf(payload) map ((item, index) -> item.*payload)) ``` ## [](#変数の伝播)変数の伝播 すべてのルートは同じ初期変数値で開始します。特定のルート内の変数の変更は他のルートに影響しません。そのため、1 つのルートで変数が追加されたり変更されたりした場合、集約後に、その値はそのルートによって定義されます。複数のルートによって変数が追加されたり変更されたりした場合、その値はすべてのルート内のその変数について定義されたすべての値のリストに追加されます。例: ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "newValue", var3: ["appleVal, bananaVal, otherVal"], var4: "val4"}` ## [](#scatter-gather-ルート内のエラー処理)Scatter-Gather ルート内のエラー処理 Scatter-Gather コンポーネントの各ルートで Try スコープを使用して、ルートのイベントプロセッサーで生成されるエラーを処理できます。実行されたいずれかのルートでエラーが発生すると、Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ 種別のエラーをスローし、フローの処理はその Scatter-Gather コンポーネントから先には進みません。その代わりに、フローはエラー処理イベントプロセッサーに分岐します。 `MULE:COMPOSITE_ROUTING`​ エラーオブジェクトは、失敗したルートからのエラーだけではなく、正常に完了したルートからの Mule イベントも収集します。そのためアプリケーションは、エラー処理イベントプロセッサーを使用して、完了したルートからの Mule イベントを処理できます。 2 つのケースを使用して、この仕組みを分かりやすく説明します。 - Scatter-Gather コンポーネントの各ルートに Try スコープがあるケース。 いずれか 1 本のルートでエラーが生成され、そのルートの Try スコープで ​`on-error-continue`​ エラーハンドラーを使用して正常に処理されたため、そのルートは正常に完了します。Scatter-Gather コンポーネントは、すべてのルートからの Mule イベントを統合して新しい Mule イベントを生成し、統合したイベントを次のイベントプロセッサーに渡します。 - Scatter-Gather コンポーネントのいずれかのルートが Try スコープを持たないか、またはそのルートの Try スコープで該当のエラーの種類を処理できないエラーハンドラーを使用しているか、あるいはエラーハンドラーの種別が ​`on-error-propagate`​ であるケース。 このルートでエラーが発生すると、ルートは失敗して Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ エラーをスローします。フローは、完了したルートからの Mule イベントを処理できるエラー処理イベントプロセッサーに分岐します。 こうしたエラーの処理の例: ```xml ``` ## [](#scatter-gather-でのタイムアウトエラーの処理)Scatter-Gather でのタイムアウトエラーの処理 Scatter-Gather コンポーネントでタイムアウトを設定してある場合、そのタイムアウト時間内にルートが処理を完了しないと、そのルートは ​`MULE:TIMEOUT`​ エラーを返します。このエラーは、ルートで発生する他のエラーと同じように処理されます。各ルートが (処理を正常に完了するか、または ​`MULE:TIMEOUT`​ エラーをスローして) 完了すると、成功した結果とエラーが Scatter-Gather コンポーネントによって収集され、​`MULE:COMPOSITE_ROUTING`​ エラーとしてスローされます。このエラーは、設定されているエラーハンドラーで処理されます。 ## [](#サンプルプロジェクト)サンプルプロジェクト Scatter-Gather コンポーネントの使い方の詳細を見るには、Anypoint Studio で Anypoint Exchange からサンプルプロジェクトの ​_Scatter-Gather Flow Control (スキャッターギャザーフロー制御)_​ をダウンロードします。このサンプルは、データを並列に集約して結果を JSON で返すための Scatter-Gather 制御フローを示します。 また、このサンプルは用意されているデータを、集約する 2 つのリソースへの入力として使用します。このデータは、2 人の取引先責任者の情報を表し、次の構造となっています。

リソース

firstname

surname

phone

email

contacts-1.csv

John

Doe

096548763

john.doe@texasComp.com

contacts-2.csv

Jane

Doe

091558780

jane.doe@texasComp.com
データの集約には DataWeave が使用されます。取引先責任者の情報は、両方のリソースからのデータを表す JSON 構造に集約されます。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#scatter-gather-xml-リファレンス)Scatter-Gather XML リファレンス
要素 説明

scatter-gather

複数の対象に要求メッセージを同時に送信します。応答をすべてのルートから収集して、単一のメッセージに集約します。

属性

timeout

送信したメッセージからの応答のタイムアウトをミリ秒単位で指定します。0 または負の値を指定すると、タイムアウトは設定されません。

maxConcurrency

処理する並列ルートの最大数を指定します。
デフォルトでは、すべてのルートが並列処理されます。

この値を 1 に設定すると、scatter-gather はルートを 1 本ずつ順次処理します。

target

対象変数の名前。

targetValue

対象変数に格納するデータの値。
設定しないと、デフォルト値の ​#[payload]​ が使用されます。
この項目は、変数が受け入れるすべての値を受け入れます。

  • サポートされる任意のデータ型。

  • DataWeave 式。

  • キーワードの ​payload​、​attributes​、​message​。​vars​ は​受け入れられません​。
子要素 説明

route

scatter-gather ルーター内のいずれかのルート。
### [](#スロー)スロー - `MULE:ROUTING` - `MULE:COMPOSITE_ROUTING` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management#tx_scopes_routers) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept) # Scatter-Gather ルーター Scatter-Gather コンポーネントは、異なるイベントプロセッサーを持つ異なる並列処理ルートで Mule イベントを処理するルーティングイベントプロセッサーです。各ルートは、Mule イベントへの参照を受け取り、1 つ以上の一連のイベントプロセッサーを実行します。各ルートは個別のスレッドを使用してイベントプロセッサーを実行します。実行後の Mule イベントは、元と同じ未変更の Mule イベントか、もしくは独自のペイロード、属性、変数を持つ新しい Mule イベントになります。Scatter-Gather コンポーネントは、各処理ルートから返された Mule イベントを新しい Mule イベントとして統合し、すべてのルートが正常に完了した場合にのみ、この Mule イベントを次のイベントプロセッサーに渡します。 Scatter-Gather コンポーネントは、複数のルートを (順次ではなく) 並列に実行します。ルートを並列実行することで、Mule アプリケーションの効率が大幅に向上し、順次処理よりも多くの情報を提供できます。 Scatter-Gather コンポーネントは、反復可能ストリームを処理します。失われる前に 1 回だけ読み取ることができる反復不可能なストリームは処理しません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 Scatter-Gather コンポーネントの詳細な動作を次の図に示します。 ![Scatter-Gather コンポーネントの図](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-scatter-gather.png)
1Scatter-Gather コンポーネントは Mule イベントを受け取って、この Mule イベントの参照を各処理ルートに送信します。
2各処理ルートは並列に実行を開始します。ルート内のすべてのプロセッサーが処理を完了すると、そのルートは Mule イベントを返します。この Mule イベントは、元と同じ未変更の Mule イベントか、もしくはルート内のプロセッサーによって変更が加えられて作成された新しい Mule イベントになります。
3すべての処理ルートが処理を完了すると、Scatter-Gather コンポーネントはすべてのルートから返された Mule イベントを統合して、フロー内の次のコンポーネントに渡します。
Scatter-Gather コンポーネントは、2 本以上のルートで設定してください。そうしないと、Mule アプリケーションは例外を返して実行されません。
## [](#結果)結果 すべてのルートが完了すると、コンポーネントによって次の形式で結果が出力されます: `{0: messageFromRoute0, 1: messageFromRoute1, …​}` 生成されたすべてのペイロードを配列に抽出するには、次のような DataWeave スクリプトを使用します。 ```dw flatten(valuesOf(payload) map ((item, index) -> item.*payload)) ``` ## [](#変数の伝播)変数の伝播 すべてのルートは同じ初期変数値で開始します。特定のルート内の変数の変更は他のルートに影響しません。そのため、1 つのルートで変数が追加されたり変更されたりした場合、集約後に、その値はそのルートによって定義されます。複数のルートによって変数が追加されたり変更されたりした場合、その値はすべてのルート内のその変数について定義されたすべての値のリストに追加されます。例: ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "newValue", var3: ["appleVal, bananaVal, otherVal"], var4: "val4"}` ## [](#scatter-gather-ルート内のエラー処理)Scatter-Gather ルート内のエラー処理 Scatter-Gather コンポーネントの各ルートで Try スコープを使用して、ルートのイベントプロセッサーで生成されるエラーを処理できます。実行されたいずれかのルートでエラーが発生すると、Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ 種別のエラーをスローし、フローの処理はその Scatter-Gather コンポーネントから先には進みません。その代わりに、フローはエラー処理イベントプロセッサーに分岐します。 `MULE:COMPOSITE_ROUTING`​ エラーオブジェクトは、失敗したルートからのエラーだけではなく、正常に完了したルートからの Mule イベントも収集します。そのためアプリケーションは、エラー処理イベントプロセッサーを使用して、完了したルートからの Mule イベントを処理できます。 2 つのケースを使用して、この仕組みを分かりやすく説明します。 - Scatter-Gather コンポーネントの各ルートに Try スコープがあるケース。 いずれか 1 本のルートでエラーが生成され、そのルートの Try スコープで ​`on-error-continue`​ エラーハンドラーを使用して正常に処理されたため、そのルートは正常に完了します。Scatter-Gather コンポーネントは、すべてのルートからの Mule イベントを統合して新しい Mule イベントを生成し、統合したイベントを次のイベントプロセッサーに渡します。 - Scatter-Gather コンポーネントのいずれかのルートが Try スコープを持たないか、またはそのルートの Try スコープで該当のエラー種別を処理できないエラーハンドラーを使用しているか、あるいはエラーハンドラーの種別が ​`on-error-propagate`​ であるケース。 このルートでエラーが発生すると、ルートは失敗して Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ エラーをスローします。フローは、完了したルートからの Mule イベントを処理できるエラー処理イベントプロセッサーに分岐します。 こうしたエラーの処理の例: ```xml ``` ## [](#scatter-gather-でのタイムアウトエラーの処理)Scatter-Gather でのタイムアウトエラーの処理 Scatter-Gather コンポーネントでタイムアウトを設定してある場合、そのタイムアウト時間内にルートが処理を完了しないと、そのルートは ​`MULE:TIMEOUT`​ エラーを返します。このエラーは、ルートで発生する他のエラーと同じように処理されます。各ルートが (処理を正常に完了するか、または ​`MULE:TIMEOUT`​ エラーをスローして) 完了すると、成功した結果とエラーが Scatter-Gather コンポーネントによって収集され、​`MULE:COMPOSITE_ROUTING`​ エラーとしてスローされます。このエラーは、設定されているエラーハンドラーで処理されます。 ## [](#サンプルプロジェクト)サンプルプロジェクト Scatter-Gather コンポーネントの使い方の詳細を見るには、Anypoint Studio で Anypoint Exchange からサンプルプロジェクトの ​_Scatter-Gather Flow Control (スキャッターギャザーフロー制御)_​ をダウンロードします。このサンプルは、データを並列に集約して結果を JSON で返すための Scatter-Gather 制御フローを示します。 また、このサンプルは用意されているデータを、集約する 2 つのリソースへの入力として使用します。このデータは、2 人の取引先責任者の情報を表し、次の構造となっています。

リソース

firstname

surname

phone

email

contacts-1.csv

John

Doe

096548763

john.doe@texasComp.com

contacts-2.csv

Jane

Doe

091558780

jane.doe@texasComp.com
データの集約には DataWeave が使用されます。取引先責任者の情報は、両方のリソースからのデータを表す JSON 構造に集約されます。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#scatter-gather-xml-リファレンス)Scatter-Gather XML リファレンス
要素 説明

scatter-gather

複数の対象に要求メッセージを同時に送信します。応答をすべてのルートから収集して、単一のメッセージに集約します。

属性

timeout

送信したメッセージからの応答のタイムアウトをミリ秒単位で指定します。0 または負の値を指定すると、タイムアウトは設定されません。

maxConcurrency

処理する並列ルートの最大数を指定します。
デフォルトでは、すべてのルートが並列処理されます。

この値を 1 に設定すると、scatter-gather はルートを 1 本ずつ順次処理します。

target

対象変数の名前。

targetValue

対象変数に格納するデータの値。
設定しないと、デフォルト値の ​#[payload]​ が使用されます。
この項目は、変数が受け入れるすべての値を受け入れます。

  • サポートされる任意のデータ型。

  • DataWeave 式。

  • キーワードの ​payload​、​attributes​、​message​。​vars​ は​受け入れられません​。
子要素 説明

route

scatter-gather ルーター内のいずれかのルート。
### [](#スロー)スロー - `MULE:ROUTING` - `MULE:COMPOSITE_ROUTING` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management#tx_scopes_routers) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept) # Scatter-Gather ルーター Scatter-Gather コンポーネントは、異なるイベントプロセッサーを持つ異なる並列処理ルートで Mule イベントを処理するルーティングイベントプロセッサーです。各ルートは、Mule イベントへの参照を受け取り、1 つ以上の一連のイベントプロセッサーを実行します。各ルートは個別のスレッドを使用してイベントプロセッサーを実行します。実行後の Mule イベントは、元と同じ未変更の Mule イベントか、もしくは独自のペイロード、属性、変数を持つ新しい Mule イベントになります。Scatter-Gather コンポーネントは、各処理ルートから返された Mule イベントを新しい Mule イベントとして統合し、すべてのルートが正常に完了した場合にのみ、この Mule イベントを次のイベントプロセッサーに渡します。 Scatter-Gather コンポーネントは、複数のルートを (順次ではなく) 並列に実行します。ルートを並列実行することで、Mule アプリケーションの効率が大幅に向上し、順次処理よりも多くの情報を提供できます。 Scatter-Gather コンポーネントは、反復可能ストリームを処理します。失われる前に 1 回だけ読み取ることができる反復不可能なストリームは処理しません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 Scatter-Gather コンポーネントの詳細な動作を次の図に示します。 ![Scatter-Gather コンポーネントの図](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-scatter-gather.png)
1Scatter-Gather コンポーネントは Mule イベントを受け取って、この Mule イベントの参照を各処理ルートに送信します。
2各処理ルートは並列に実行を開始します。ルート内のすべてのプロセッサーが処理を完了すると、そのルートは Mule イベントを返します。この Mule イベントは、元と同じ未変更の Mule イベントか、もしくはルート内のプロセッサーによって変更が加えられて作成された新しい Mule イベントになります。
3すべての処理ルートが処理を完了すると、Scatter-Gather コンポーネントはすべてのルートから返された Mule イベントを統合して、フロー内の次のコンポーネントに渡します。
Scatter-Gather コンポーネントは、2 本以上のルートで設定してください。そうしないと、Mule アプリケーションは例外を返して実行されません。
## [](#結果)結果 すべてのルートが完了すると、コンポーネントによって次の形式で結果が出力されます: `{0: messageFromRoute0, 1: messageFromRoute1, …​}` 生成されたすべてのペイロードを配列に抽出するには、次のような DataWeave スクリプトを使用します。 ```dw flatten(valuesOf(payload) map ((item, index) -> item.*payload)) ``` ## [](#変数の伝播)変数の伝播 すべてのルートは同じ初期変数値で開始します。特定のルート内の変数の変更は他のルートに影響しません。そのため、1 つのルートで変数が追加されたり変更されたりした場合、集約後に、その値はそのルートによって定義されます。複数のルートによって変数が追加されたり変更されたりした場合、その値はすべてのルート内のその変数について定義されたすべての値のリストに追加されます。例: ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "newValue", var3: ["appleVal, bananaVal, otherVal"], var4: "val4"}` ## [](#scatter-gather-ルート内のエラー処理)Scatter-Gather ルート内のエラー処理 Scatter-Gather コンポーネントの各ルートで Try スコープを使用して、ルートのイベントプロセッサーで生成されるエラーを処理できます。実行されたいずれかのルートでエラーが発生すると、Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ 種別のエラーをスローし、フローの処理はその Scatter-Gather コンポーネントから先には進みません。その代わりに、フローはエラー処理イベントプロセッサーに分岐します。 `MULE:COMPOSITE_ROUTING`​ エラーオブジェクトは、失敗したルートからのエラーだけではなく、正常に完了したルートからの Mule イベントも収集します。そのためアプリケーションは、エラー処理イベントプロセッサーを使用して、完了したルートからの Mule イベントを処理できます。 2 つのケースを使用して、この仕組みを分かりやすく説明します。 - Scatter-Gather コンポーネントの各ルートに Try スコープがあるケース。 いずれか 1 本のルートでエラーが生成され、そのルートの Try スコープで ​`on-error-continue`​ エラーハンドラーを使用して正常に処理されたため、そのルートは正常に完了します。Scatter-Gather コンポーネントは、すべてのルートからの Mule イベントを統合して新しい Mule イベントを生成し、統合したイベントを次のイベントプロセッサーに渡します。 - Scatter-Gather コンポーネントのいずれかのルートが Try スコープを持たないか、またはそのルートの Try スコープで該当のエラー種別を処理できないエラーハンドラーを使用しているか、あるいはエラーハンドラーの種別が ​`on-error-propagate`​ であるケース。 このルートでエラーが発生すると、ルートは失敗して Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ エラーをスローします。フローは、完了したルートからの Mule イベントを処理できるエラー処理イベントプロセッサーに分岐します。 こうしたエラーの処理の例: ```xml ``` ## [](#scatter-gather-でのタイムアウトエラーの処理)Scatter-Gather でのタイムアウトエラーの処理 Scatter-Gather コンポーネントでタイムアウトを設定してある場合、そのタイムアウト時間内にルートが処理を完了しないと、そのルートは ​`MULE:TIMEOUT`​ エラーを返します。このエラーは、ルートで発生する他のエラーと同じように処理されます。各ルートが (処理を正常に完了するか、または ​`MULE:TIMEOUT`​ エラーをスローして) 完了すると、成功した結果とエラーが Scatter-Gather コンポーネントによって収集され、​`MULE:COMPOSITE_ROUTING`​ エラーとしてスローされます。このエラーは、設定されているエラーハンドラーで処理されます。 ## [](#サンプルプロジェクト)サンプルプロジェクト Scatter-Gather コンポーネントの使い方の詳細を見るには、Anypoint Studio で Anypoint Exchange からサンプルプロジェクトの ​_Scatter-Gather Flow Control (スキャッターギャザーフロー制御)_​ をダウンロードします。このサンプルは、データを並列に集約して結果を JSON で返すための Scatter-Gather 制御フローを示します。 また、このサンプルは用意されているデータを、集約する 2 つのリソースへの入力として使用します。このデータは、2 人の取引先責任者の情報を表し、次の構造となっています。

リソース

firstname

surname

phone

email

contacts-1.csv

John

Doe

096548763

john.doe@texasComp.com

contacts-2.csv

Jane

Doe

091558780

jane.doe@texasComp.com
データの集約には DataWeave が使用されます。取引先責任者の情報は、両方のリソースからのデータを表す JSON 構造に集約されます。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#scatter-gather-xml-リファレンス)Scatter-Gather XML リファレンス
要素 説明

scatter-gather

複数の対象に要求メッセージを同時に送信します。応答をすべてのルートから収集して、単一のメッセージに集約します。

属性

timeout

送信したメッセージからの応答のタイムアウトをミリ秒単位で指定します。0 または負の値を指定すると、タイムアウトは設定されません。

maxConcurrency

処理する並列ルートの最大数を指定します。
デフォルトでは、すべてのルートが並列処理されます。

この値を 1 に設定すると、scatter-gather はルートを 1 本ずつ順次処理します。

target

対象変数の名前。

targetValue

対象変数に格納するデータの値。
設定しないと、デフォルト値の ​#[payload]​ が使用されます。
この項目は、変数が受け入れるすべての値を受け入れます。

  • サポートされる任意のデータ型。

  • DataWeave 式。

  • キーワードの ​payload​、​attributes​、​message​。​vars​ は​受け入れられません​。
子要素 説明

route

scatter-gather ルーター内のいずれかのルート。
### [](#スロー)スロー - `MULE:ROUTING` - `MULE:COMPOSITE_ROUTING` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management#tx_scopes_routers) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept) # Scatter-Gather ルーター Scatter-Gather コンポーネントは、異なるイベントプロセッサーを持つ異なる並列処理ルートで Mule イベントを処理するルーティングイベントプロセッサーです。各ルートは、Mule イベントへの参照を受け取り、1 つ以上の一連のイベントプロセッサーを実行します。各ルートは個別のスレッドを使用してイベントプロセッサーを実行します。実行後の Mule イベントは、元と同じ未変更の Mule イベントか、もしくは独自のペイロード、属性、変数を持つ新しい Mule イベントになります。Scatter-Gather コンポーネントは、各処理ルートから返された Mule イベントを新しい Mule イベントとして統合し、すべてのルートが正常に完了した場合にのみ、この Mule イベントを次のイベントプロセッサーに渡します。 Scatter-Gather コンポーネントは、複数のルートを (順次ではなく) 並列に実行します。ルートを並列実行することで、Mule アプリケーションの効率が大幅に向上し、順次処理よりも多くの情報を提供できます。 Scatter-Gather コンポーネントは、反復可能ストリームを処理します。失われる前に 1 回だけ読み取ることができる反復不可能なストリームは処理しません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 Scatter-Gather コンポーネントの詳細な動作を次の図に示します。 ![Mule アプリケーションの複数のイベントを処理する Scatter-Gather コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-scatter-gather.png)
1Scatter-Gather コンポーネントは Mule イベントを受け取って、この Mule イベントの参照を各処理ルートに送信します。
2各処理ルートは並列に実行を開始します。ルート内のすべてのプロセッサーが処理を完了すると、そのルートは Mule イベントを返します。この Mule イベントは、元と同じ未変更の Mule イベントか、もしくはルート内のプロセッサーによって変更が加えられて作成された新しい Mule イベントになります。
3すべての処理ルートが処理を完了すると、Scatter-Gather コンポーネントはすべてのルートから返された Mule イベントを統合して、フロー内の次のコンポーネントに渡します。
Scatter-Gather コンポーネントは、2 本以上のルートで設定してください。そうしないと、Mule アプリケーションは例外を返して実行されません。
## [](#結果)結果 すべてのルートが完了すると、コンポーネントによって次の形式で結果が出力されます: `{0: messageFromRoute0, 1: messageFromRoute1, …​}` 生成されたすべてのペイロードを配列に抽出するには、次のような DataWeave スクリプトを使用します。 ```dw flatten(valuesOf(payload) map ((item, index) -> item.*payload)) ``` ## [](#変数の伝播)変数の伝播 すべてのルートは同じ初期変数値で開始します。特定のルート内の変数の変更は他のルートに影響しません。そのため、1 つのルートで変数が追加されたり変更されたりした場合、集約後に、その値はそのルートによって定義されます。複数のルートによって変数が追加されたり変更されたりした場合、その値はすべてのルート内のその変数について定義されたすべての値のリストに追加されます。例: ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "newValue", var3: ["appleVal, bananaVal, otherVal"], var4: "val4"}` ## [](#scatter-gather-ルート内のエラー処理)Scatter-Gather ルート内のエラー処理 Scatter-Gather コンポーネントの各ルートで Try スコープを使用して、ルートのイベントプロセッサーで生成されるエラーを処理できます。実行されたいずれかのルートでエラーが発生すると、Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ 種別のエラーをスローし、フローの処理はその Scatter-Gather コンポーネントから先には進みません。その代わりに、フローはエラー処理イベントプロセッサーに分岐します。 `MULE:COMPOSITE_ROUTING`​ エラーオブジェクトは、失敗したルートからのエラーだけではなく、正常に完了したルートからの Mule イベントも収集します。そのためアプリケーションは、エラー処理イベントプロセッサーを使用して、完了したルートからの Mule イベントを処理できます。 2 つのケースを使用して、この仕組みを分かりやすく説明します。 - Scatter-Gather コンポーネントの各ルートに Try スコープがあるケース。 いずれか 1 本のルートでエラーが生成され、そのルートの Try スコープで ​`on-error-continue`​ エラーハンドラーを使用して正常に処理されたため、そのルートは正常に完了します。Scatter-Gather コンポーネントは、すべてのルートからの Mule イベントを統合して新しい Mule イベントを生成し、統合したイベントを次のイベントプロセッサーに渡します。 - Scatter-Gather コンポーネントのいずれかのルートが Try スコープを持たないか、またはそのルートの Try スコープで該当のエラー種別を処理できないエラーハンドラーを使用しているか、あるいはエラーハンドラーの種別が ​`on-error-propagate`​ であるケース。 このルートでエラーが発生すると、ルートは失敗して Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ エラーをスローします。フローは、完了したルートからの Mule イベントを処理できるエラー処理イベントプロセッサーに分岐します。 こうしたエラーの処理の例: ```xml ``` ## [](#scatter-gather-でのタイムアウトエラーの処理)Scatter-Gather でのタイムアウトエラーの処理 Scatter-Gather コンポーネントでタイムアウトを設定してある場合、そのタイムアウト時間内にルートが処理を完了しないと、そのルートは ​`MULE:TIMEOUT`​ エラーを返します。このエラーは、ルートで発生する他のエラーと同じように処理されます。各ルートが (処理を正常に完了するか、または ​`MULE:TIMEOUT`​ エラーをスローして) 完了すると、成功した結果とエラーが Scatter-Gather コンポーネントによって収集され、​`MULE:COMPOSITE_ROUTING`​ エラーとしてスローされます。このエラーは、設定されているエラーハンドラーで処理されます。 ## [](#サンプルプロジェクト)サンプルプロジェクト Scatter-Gather コンポーネントの使い方の詳細を見るには、Anypoint Studio で Anypoint Exchange からサンプルプロジェクトの ​_Scatter-Gather Flow Control (スキャッターギャザーフロー制御)_​ をダウンロードします。このサンプルは、データを並列に集約して結果を JSON で返すための Scatter-Gather 制御フローを示します。 また、このサンプルは用意されているデータを、集約する 2 つのリソースへの入力として使用します。このデータは、2 人の取引先責任者の情報を表し、次の構造となっています。

リソース

firstname

surname

phone

email

contacts-1.csv

John

Doe

096548763

john.doe@texasComp.com

contacts-2.csv

Jane

Doe

091558780

jane.doe@texasComp.com
データの集約には DataWeave が使用されます。取引先責任者の情報は、両方のリソースからのデータを表す JSON 構造に集約されます。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#scatter-gather-xml-リファレンス)Scatter-Gather XML リファレンス
要素 説明

scatter-gather

複数の対象に要求メッセージを同時に送信します。応答をすべてのルートから収集して、単一のメッセージに集約します。

属性

timeout

送信したメッセージからの応答のタイムアウトをミリ秒単位で指定します。0 または負の値を指定すると、タイムアウトは設定されません。

maxConcurrency

処理する並列ルートの最大数を指定します。
デフォルトでは、すべてのルートが並列処理されます。

この値を 1 に設定すると、scatter-gather はルートを 1 本ずつ順次処理します。

target

対象変数の名前。

targetValue

対象変数に格納するデータの値。
設定しないと、デフォルト値の ​#[payload]​ が使用されます。
この項目は、変数が受け入れるすべての値を受け入れます。

  • サポートされる任意のデータ型。

  • DataWeave 式。

  • キーワードの ​payload​、​attributes​、​message​。​vars​ は​受け入れられません​。
子要素 説明

route

scatter-gather ルーター内のいずれかのルート。
### [](#スロー)スロー - `MULE:ROUTING` - `MULE:COMPOSITE_ROUTING` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management#tx_scopes_routers) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept) # Scatter-Gather ルーター Scatter-Gather コンポーネントは、異なるイベントプロセッサーを持つ異なる並列処理ルートで Mule イベントを処理するルーティングイベントプロセッサーです。各ルートは、Mule イベントへの参照を受け取り、1 つ以上の一連のイベントプロセッサーを実行します。各ルートは個別のスレッドを使用してイベントプロセッサーを実行します。実行後の Mule イベントは、元と同じ未変更の Mule イベントか、もしくは独自のペイロード、属性、変数を持つ新しい Mule イベントになります。Scatter-Gather コンポーネントは、各処理ルートから返された Mule イベントを新しい Mule イベントとして統合し、すべてのルートが正常に完了した場合にのみ、この Mule イベントを次のイベントプロセッサーに渡します。 Scatter-Gather コンポーネントは、複数のルートを (順次ではなく) 並列に実行します。ルートを並列実行することで、Mule アプリケーションの効率が大幅に向上し、順次処理よりも多くの情報を提供できます。 Scatter-Gather コンポーネントは、反復可能ストリームを処理します。失われる前に 1 回だけ読み取ることができる反復不可能なストリームは処理しません。コンポーネントのストリーム戦略が反復不可能に設定されていない限り、デフォルトではすべてのストリームが Mule で反復可能です。 Scatter-Gather コンポーネントの詳細な動作を次の図に示します。 ![Mule アプリケーションの複数のイベントを処理する Scatter-Gather コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-scatter-gather.png)
1Scatter-Gather コンポーネントは Mule イベントを受け取って、この Mule イベントの参照を各処理ルートに送信します。
2各処理ルートは並列に実行を開始します。ルート内のすべてのプロセッサーが処理を完了すると、そのルートは Mule イベントを返します。この Mule イベントは、元と同じ未変更の Mule イベントか、もしくはルート内のプロセッサーによって変更が加えられて作成された新しい Mule イベントになります。
3すべての処理ルートが処理を完了すると、Scatter-Gather コンポーネントはすべてのルートから返された Mule イベントを統合して、フロー内の次のコンポーネントに渡します。
Scatter-Gather コンポーネントは、2 本以上のルートで設定してください。そうしないと、Mule アプリケーションは例外を返して実行されません。
## [](#結果)結果 すべてのルートが完了すると、コンポーネントによって次の形式で結果が出力されます: `{0: messageFromRoute0, 1: messageFromRoute1, …​}` 生成されたすべてのペイロードを配列に抽出するには、次のような DataWeave スクリプトを使用します。 ```dw flatten(valuesOf(payload) map ((item, index) -> item.*payload)) ``` ## [](#変数の伝播)変数の伝播 すべてのルートは同じ初期変数値で開始します。特定のルート内の変数の変更は他のルートに影響しません。そのため、1 つのルートで変数が追加されたり変更されたりした場合、集約後に、その値はそのルートによって定義されます。複数のルートによって変数が追加されたり変更されたりした場合、その値はすべてのルート内のその変数について定義されたすべての値のリストに追加されます。例: ```xml ``` 集約後、変数は次のようになります。 `{var1: "var1", var2: "newValue", var3: ["appleVal, bananaVal, otherVal"], var4: "val4"}` ## [](#scatter-gather-ルート内のエラー処理)Scatter-Gather ルート内のエラー処理 Scatter-Gather コンポーネントの各ルートで Try スコープを使用して、ルートのイベントプロセッサーで生成されるエラーを処理できます。実行されたいずれかのルートでエラーが発生すると、Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ 種別のエラーをスローし、フローの処理はその Scatter-Gather コンポーネントから先には進みません。その代わりに、フローはエラー処理イベントプロセッサーに分岐します。 `MULE:COMPOSITE_ROUTING`​ エラーオブジェクトは、失敗したルートからのエラーだけではなく、正常に完了したルートからの Mule イベントも収集します。そのためアプリケーションは、エラー処理イベントプロセッサーを使用して、完了したルートからの Mule イベントを処理できます。 2 つのケースを使用して、この仕組みを分かりやすく説明します。 - Scatter-Gather コンポーネントの各ルートに Try スコープがあるケース。 いずれか 1 本のルートでエラーが生成され、そのルートの Try スコープで ​`on-error-continue`​ エラーハンドラーを使用して正常に処理されたため、そのルートは正常に完了します。Scatter-Gather コンポーネントは、すべてのルートからの Mule イベントを統合して新しい Mule イベントを生成し、統合したイベントを次のイベントプロセッサーに渡します。 - Scatter-Gather コンポーネントのいずれかのルートが Try スコープを持たないか、またはそのルートの Try スコープで該当のエラー種別を処理できないエラーハンドラーを使用しているか、あるいはエラーハンドラーの種別が ​`on-error-propagate`​ であるケース。 このルートでエラーが発生すると、ルートは失敗して Scatter-Gather コンポーネントは ​`MULE:COMPOSITE_ROUTING`​ エラーをスローします。フローは、完了したルートからの Mule イベントを処理できるエラー処理イベントプロセッサーに分岐します。 こうしたエラーの処理の例: ```xml ``` ## [](#scatter-gather-でのタイムアウトエラーの処理)Scatter-Gather でのタイムアウトエラーの処理 Scatter-Gather コンポーネントでタイムアウトを設定してある場合、そのタイムアウト時間内にルートが処理を完了しないと、そのルートは ​`MULE:TIMEOUT`​ エラーを返します。このエラーは、ルートで発生する他のエラーと同じように処理されます。各ルートが (処理を正常に完了するか、または ​`MULE:TIMEOUT`​ エラーをスローして) 完了すると、成功した結果とエラーが Scatter-Gather コンポーネントによって収集され、​`MULE:COMPOSITE_ROUTING`​ エラーとしてスローされます。このエラーは、設定されているエラーハンドラーで処理されます。 ## [](#サンプルプロジェクト)サンプルプロジェクト Scatter-Gather コンポーネントの使い方の詳細を見るには、Anypoint Studio で Anypoint Exchange からサンプルプロジェクトの ​_Scatter-Gather Flow Control (スキャッターギャザーフロー制御)_​ をダウンロードします。このサンプルは、データを並列に集約して結果を JSON で返すための Scatter-Gather 制御フローを示します。 また、このサンプルは用意されているデータを、集約する 2 つのリソースへの入力として使用します。このデータは、2 人の取引先責任者の情報を表し、次の構造となっています。

リソース

firstname

surname

phone

email

contacts-1.csv

John

Doe

096548763

john.doe@texasComp.com

contacts-2.csv

Jane

Doe

091558780

jane.doe@texasComp.com
データの集約には DataWeave が使用されます。取引先責任者の情報は、両方のリソースからのデータを表す JSON 構造に集約されます。 Anypoint Studio でこのサンプルプロジェクトをダウンロードして開くには、左上隅にある \[Exchange\] アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#scatter-gather-xml-リファレンス)Scatter-Gather XML リファレンス
要素 説明

scatter-gather

複数の対象に要求メッセージを同時に送信します。応答をすべてのルートから収集して、単一のメッセージに集約します。

属性

timeout

送信したメッセージからの応答のタイムアウトをミリ秒単位で指定します。0 または負の値を指定すると、タイムアウトは設定されません。

maxConcurrency

処理する並列ルートの最大数を指定します。
デフォルトでは、すべてのルートが並列処理されます。

この値を 1 に設定すると、scatter-gather はルートを 1 本ずつ順次処理します。

target

対象変数の名前。

targetValue

対象変数に格納するデータの値。
設定しないと、デフォルト値の ​#[payload]​ が使用されます。
この項目は、変数が受け入れるすべての値を受け入れます。

  • サポートされる任意のデータ型。

  • DataWeave 式。

  • キーワードの ​payload​、​attributes​、​message​。​vars​ は​受け入れられません​。
子要素 説明

route

scatter-gather ルーター内のいずれかのルート。
### [](#スロー)スロー - `MULE:ROUTING` - `MULE:COMPOSITE_ROUTING` ## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-components) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management#tx_scopes_routers) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept) # Scatter-Gather ルーターの移行 Mule 3 と Mule 4 の Scatter-Gather ルーターでの最も重要な変更は、異なるルートの結果をまとめるために使用される ​`AggregationStrategy`​ で行われました。集約ロジックで Java クラスを提供する代わりに、DataWeave 変換で集約を実行できます。 Scatter-Gather から返されるペイロードは、メッセージのコレクションで、各メッセージは各ルートの結果です。それらのメッセージには DataWeave を使用してアクセスできます。 ## [](#例)例 これは、aggregation strategy (集約戦略) がある Java クラスを参照する ​`custom-aggregation-strategy`​ 要素を使用した Mule 3 の Scatter-Gather です。 ... ... aggregation strategy (集約戦略) の実装は次のとおりです。 package com.example.poc; import ... public class CustomSGAggregationStrategy implements AggregationStrategy { @Override public MuleEvent aggregate(AggregationContext context) throws MuleException { StringBuilder responseBuilder = new StringBuilder(); MuleEvent result = null; ArrayList < MarketRate > marketRates = new ArrayList < > (); for (MuleEvent event: context.collectEventsWithoutExceptions()) { String response = (String) event.getMessage().getPayload(); String\[\] spiltResponse = StringUtils.split(response, ","); MarketRate marketRate = new MarketRate(); marketRate.setEvent(event); marketRate.setMarketName(spiltResponse\[0\]); marketRate.setMarketRate(new Integer(spiltResponse\[1\])); marketRates.add(marketRate); System.out.println(marketRate); } Collections.sort(marketRates); result = DefaultMuleEvent.copy(marketRates.get(0).getEvent()); result.getMessage().setPayload(marketRates.get(0).toString()); return result; } } Mule 4 では Java クラスが削除され、フロー要素は次のようになります。 ... ... (response.payload splitBy(','))\[1\]) orderBy ((rate, index) -> rate))\[0\] \]\]\]> Java ではなく、DataWeave で ​`CustomSGAggregationStrategy`​ のロジックを複製する ​`ee:transform`​ 要素に留意してください。 ## [](#関連情報)関連情報 [Scatter-Gather について](https://docs.mulesoft.com/jp/mule-runtime/4.3/scatter-gather-concept) [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about) [DataWeave スクリプト](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-language-introduction) # Scatter-Gather ルーターの移行 Mule 3 と Mule 4 の Scatter-Gather ルーターでの最も重要な変更は、異なるルートの結果をまとめるために使用される ​`AggregationStrategy`​ で行われました。集約ロジックで Java クラスを提供する代わりに、DataWeave 変換で集約を実行できます。 Scatter-Gather から返されるペイロードは、メッセージのコレクションで、各メッセージは各ルートの結果です。それらのメッセージには DataWeave を使用してアクセスできます。 ## [](#例)例 これは、aggregation strategy (集約戦略) がある Java クラスを参照する ​`custom-aggregation-strategy`​ 要素を使用した Mule 3 の Scatter-Gather です。 ... ... aggregation strategy (集約戦略) の実装は次のとおりです。 package com.example.poc; import ... public class CustomSGAggregationStrategy implements AggregationStrategy { @Override public MuleEvent aggregate(AggregationContext context) throws MuleException { StringBuilder responseBuilder = new StringBuilder(); MuleEvent result = null; ArrayList < MarketRate > marketRates = new ArrayList < > (); for (MuleEvent event: context.collectEventsWithoutExceptions()) { String response = (String) event.getMessage().getPayload(); String\[\] spiltResponse = StringUtils.split(response, ","); MarketRate marketRate = new MarketRate(); marketRate.setEvent(event); marketRate.setMarketName(spiltResponse\[0\]); marketRate.setMarketRate(new Integer(spiltResponse\[1\])); marketRates.add(marketRate); System.out.println(marketRate); } Collections.sort(marketRates); result = DefaultMuleEvent.copy(marketRates.get(0).getEvent()); result.getMessage().setPayload(marketRates.get(0).toString()); return result; } } Mule 4 では Java クラスが削除され、フロー要素は次のようになります。 ... ... (response.payload splitBy(','))\[1\]) orderBy ((rate, index) -> rate))\[0\] \]\]\]> Java ではなく、DataWeave で ​`CustomSGAggregationStrategy`​ のロジックを複製する ​`ee:transform`​ 要素に留意してください。 ## [](#関連情報)関連情報 [Scatter-Gather について](https://docs.mulesoft.com/jp/mule-runtime/4.4/scatter-gather-concept) [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about) [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) # Scatter-Gather ルーターの移行 Mule 3 と Mule 4 の Scatter-Gather ルーターでの最も重要な変更は、異なるルートの結果をまとめるために使用される ​`AggregationStrategy`​ で行われました。集約ロジックで Java クラスを提供する代わりに、DataWeave 変換で集約を実行できます。 Scatter-Gather から返されるペイロードは、メッセージのコレクションで、各メッセージは各ルートの結果です。それらのメッセージには DataWeave を使用してアクセスできます。 ## [](#例)例 これは、aggregation strategy (集約戦略) がある Java クラスを参照する ​`custom-aggregation-strategy`​ 要素を使用した Mule 3 の Scatter-Gather です。 ... ... aggregation strategy (集約戦略) の実装は次のとおりです。 package com.example.poc; import ... public class CustomSGAggregationStrategy implements AggregationStrategy { @Override public MuleEvent aggregate(AggregationContext context) throws MuleException { StringBuilder responseBuilder = new StringBuilder(); MuleEvent result = null; ArrayList < MarketRate > marketRates = new ArrayList < > (); for (MuleEvent event: context.collectEventsWithoutExceptions()) { String response = (String) event.getMessage().getPayload(); String\[\] spiltResponse = StringUtils.split(response, ","); MarketRate marketRate = new MarketRate(); marketRate.setEvent(event); marketRate.setMarketName(spiltResponse\[0\]); marketRate.setMarketRate(new Integer(spiltResponse\[1\])); marketRates.add(marketRate); System.out.println(marketRate); } Collections.sort(marketRates); result = DefaultMuleEvent.copy(marketRates.get(0).getEvent()); result.getMessage().setPayload(marketRates.get(0).toString()); return result; } } Mule 4 では Java クラスが削除され、フロー要素は次のようになります。 ... ... (response.payload splitBy(','))\[1\]) orderBy ((rate, index) -> rate))\[0\] \]\]\]> Java ではなく、DataWeave で ​`CustomSGAggregationStrategy`​ のロジックを複製する ​`ee:transform`​ 要素に留意してください。 ## [](#関連情報)関連情報 [Scatter-Gather について](https://docs.mulesoft.com/jp/mule-runtime/4.5/scatter-gather-concept) [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about) [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) # Scatter-Gather ルーターの移行 Mule 3 と Mule 4 の Scatter-Gather ルーターでの最も重要な変更は、異なるルートの結果をまとめるために使用される ​`AggregationStrategy`​ で行われました。集約ロジックで Java クラスを提供する代わりに、DataWeave 変換で集約を実行できます。 Scatter-Gather から返されるペイロードは、メッセージのコレクションで、各メッセージは各ルートの結果です。それらのメッセージには DataWeave を使用してアクセスできます。 ## [](#例)例 これは、aggregation strategy (集約戦略) がある Java クラスを参照する ​`custom-aggregation-strategy`​ 要素を使用した Mule 3 の Scatter-Gather です。 ... ... aggregation strategy (集約戦略) の実装は次のとおりです。 package com.example.poc; import ... public class CustomSGAggregationStrategy implements AggregationStrategy { @Override public MuleEvent aggregate(AggregationContext context) throws MuleException { StringBuilder responseBuilder = new StringBuilder(); MuleEvent result = null; ArrayList < MarketRate > marketRates = new ArrayList < > (); for (MuleEvent event: context.collectEventsWithoutExceptions()) { String response = (String) event.getMessage().getPayload(); String\[\] spiltResponse = StringUtils.split(response, ","); MarketRate marketRate = new MarketRate(); marketRate.setEvent(event); marketRate.setMarketName(spiltResponse\[0\]); marketRate.setMarketRate(new Integer(spiltResponse\[1\])); marketRates.add(marketRate); System.out.println(marketRate); } Collections.sort(marketRates); result = DefaultMuleEvent.copy(marketRates.get(0).getEvent()); result.getMessage().setPayload(marketRates.get(0).toString()); return result; } } Mule 4 では Java クラスが削除され、フロー要素は次のようになります。 ... ... (response.payload splitBy(','))\[1\]) orderBy ((rate, index) -> rate))\[0\] \]\]\]> Java ではなく、DataWeave で ​`CustomSGAggregationStrategy`​ のロジックを複製する ​`ee:transform`​ 要素に留意してください。 ## [](#関連情報)関連情報 [Scatter-Gather について](https://docs.mulesoft.com/jp/mule-runtime/4.6/scatter-gather-concept) [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about) [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) # Scatter-Gather ルーターの移行 Mule 3 と Mule 4 の Scatter-Gather ルーターでの最も重要な変更は、異なるルートの結果をまとめるために使用される ​`AggregationStrategy`​ で行われました。集約ロジックで Java クラスを提供する代わりに、DataWeave 変換で集約を実行できます。 Scatter-Gather から返されるペイロードは、メッセージのコレクションで、各メッセージは各ルートの結果です。それらのメッセージには DataWeave を使用してアクセスできます。 ## [](#例)例 これは、aggregation strategy (集約戦略) がある Java クラスを参照する ​`custom-aggregation-strategy`​ 要素を使用した Mule 3 の Scatter-Gather です。 ... ... aggregation strategy (集約戦略) の実装は次のとおりです。 package com.example.poc; import ... public class CustomSGAggregationStrategy implements AggregationStrategy { @Override public MuleEvent aggregate(AggregationContext context) throws MuleException { StringBuilder responseBuilder = new StringBuilder(); MuleEvent result = null; ArrayList < MarketRate > marketRates = new ArrayList < > (); for (MuleEvent event: context.collectEventsWithoutExceptions()) { String response = (String) event.getMessage().getPayload(); String\[\] spiltResponse = StringUtils.split(response, ","); MarketRate marketRate = new MarketRate(); marketRate.setEvent(event); marketRate.setMarketName(spiltResponse\[0\]); marketRate.setMarketRate(new Integer(spiltResponse\[1\])); marketRates.add(marketRate); System.out.println(marketRate); } Collections.sort(marketRates); result = DefaultMuleEvent.copy(marketRates.get(0).getEvent()); result.getMessage().setPayload(marketRates.get(0).toString()); return result; } } Mule 4 では Java クラスが削除され、フロー要素は次のようになります。 ... ... (response.payload splitBy(','))\[1\]) orderBy ((rate, index) -> rate))\[0\] \]\]\]> Java ではなく、DataWeave で ​`CustomSGAggregationStrategy`​ のロジックを複製する ​`ee:transform`​ 要素に留意してください。 ## [](#関連情報)関連情報 [Scatter-Gather について](https://docs.mulesoft.com/jp/mule-runtime/4.7/scatter-gather-concept) [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about) [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) # Scatter-Gather ルーターの移行 Mule 3 と Mule 4 の Scatter-Gather ルーターでの最も重要な変更は、異なるルートの結果をまとめるために使用される ​`AggregationStrategy`​ で行われました。集約ロジックで Java クラスを提供する代わりに、DataWeave 変換で集約を実行できます。 Scatter-Gather から返されるペイロードは、メッセージのコレクションで、各メッセージは各ルートの結果です。それらのメッセージには DataWeave を使用してアクセスできます。 ## [](#例)例 これは、aggregation strategy (集約戦略) がある Java クラスを参照する ​`custom-aggregation-strategy`​ 要素を使用した Mule 3 の Scatter-Gather です。 ... ... aggregation strategy (集約戦略) の実装は次のとおりです。 package com.example.poc; import ... public class CustomSGAggregationStrategy implements AggregationStrategy { @Override public MuleEvent aggregate(AggregationContext context) throws MuleException { StringBuilder responseBuilder = new StringBuilder(); MuleEvent result = null; ArrayList < MarketRate > marketRates = new ArrayList < > (); for (MuleEvent event: context.collectEventsWithoutExceptions()) { String response = (String) event.getMessage().getPayload(); String\[\] spiltResponse = StringUtils.split(response, ","); MarketRate marketRate = new MarketRate(); marketRate.setEvent(event); marketRate.setMarketName(spiltResponse\[0\]); marketRate.setMarketRate(new Integer(spiltResponse\[1\])); marketRates.add(marketRate); System.out.println(marketRate); } Collections.sort(marketRates); result = DefaultMuleEvent.copy(marketRates.get(0).getEvent()); result.getMessage().setPayload(marketRates.get(0).toString()); return result; } } Mule 4 では Java クラスが削除され、フロー要素は次のようになります。 ... ... (response.payload splitBy(','))\[1\]) orderBy ((rate, index) -> rate))\[0\] \]\]\]> Java ではなく、DataWeave で ​`CustomSGAggregationStrategy`​ のロジックを複製する ​`ee:transform`​ 要素に留意してください。 ## [](#関連情報)関連情報 [Scatter-Gather について](https://docs.mulesoft.com/jp/mule-runtime/4.8/scatter-gather-concept) [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about) [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) # Scatter-Gather ルーターの移行 Mule 3 と Mule 4 の Scatter-Gather ルーターでの最も重要な変更は、異なるルートの結果をまとめるために使用される ​`AggregationStrategy`​ で行われました。集約ロジックで Java クラスを提供する代わりに、DataWeave 変換で集約を実行できます。 Scatter-Gather から返されるペイロードは、メッセージのコレクションで、各メッセージは各ルートの結果です。それらのメッセージには DataWeave を使用してアクセスできます。 ## [](#例)例 これは、aggregation strategy (集約戦略) がある Java クラスを参照する ​`custom-aggregation-strategy`​ 要素を使用した Mule 3 の Scatter-Gather です。 ... ... aggregation strategy (集約戦略) の実装は次のとおりです。 package com.example.poc; import ... public class CustomSGAggregationStrategy implements AggregationStrategy { @Override public MuleEvent aggregate(AggregationContext context) throws MuleException { StringBuilder responseBuilder = new StringBuilder(); MuleEvent result = null; ArrayList < MarketRate > marketRates = new ArrayList < > (); for (MuleEvent event: context.collectEventsWithoutExceptions()) { String response = (String) event.getMessage().getPayload(); String\[\] spiltResponse = StringUtils.split(response, ","); MarketRate marketRate = new MarketRate(); marketRate.setEvent(event); marketRate.setMarketName(spiltResponse\[0\]); marketRate.setMarketRate(new Integer(spiltResponse\[1\])); marketRates.add(marketRate); System.out.println(marketRate); } Collections.sort(marketRates); result = DefaultMuleEvent.copy(marketRates.get(0).getEvent()); result.getMessage().setPayload(marketRates.get(0).toString()); return result; } } Mule 4 では Java クラスが削除され、フロー要素は次のようになります。 ... ... (response.payload splitBy(','))\[1\]) orderBy ((rate, index) -> rate))\[0\] \]\]\]> Java ではなく、DataWeave で ​`CustomSGAggregationStrategy`​ のロジックを複製する ​`ee:transform`​ 要素に留意してください。 ## [](#関連情報)関連情報 [Scatter-Gather について](https://docs.mulesoft.com/jp/mule-runtime/4.9/scatter-gather-concept) [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about) [DataWeave スクリプト](https://docs.mulesoft.com/dataweave/latest/dataweave-language-introduction) # Scheduler XML リファレンス Scheduler 用の XML には次の要素があります。 - `scheduler`​ 親要素は他の要素を包含します。 - `scheduling-strategy`​ ブロックは ​`scheduler`​ の内部に置かれます。 - `fixed-frequency`​ または ​`cron`​ 要素は ​`scheduling-strategy`​ ブロックの内部に置かれます。 ## [](#scheduler-プロパティ)``​ プロパティ
属性 説明 例

disallowConcurrentExecution

前回のフロー実行が終了していない場合、次にスケジュールされているフロー実行をスキップします。次の実行試行は、別の頻度期間の後になります。デフォルト値は ​false​ です。

disallowConcurrentExecution="true"
```xml ``` ## [](#fixed-frequency-プロパティ)``​ プロパティ
属性 説明 例

frequency

時間単位で指定されるトリガー頻度。​0​ または負の値に指定すると、デフォルト値 (1 分) が使用されます。

frequency="1000"

timeUnit

frequency 値と startDelay 値の時間単位:

MILLISECONDS (ミリ秒)、SECONDS (秒)、MINUTES (分)、HOURS (時)、DAYS (日)

timeUnit="MILLISECONDS"

startDelay

フローを最初にトリガーしたときに、Mule はスケジューラーの最初の実行を指定時間だけ遅らせます。この時間は、頻度と同じ時間単位で表されます。

startDelay="0"
```xml ``` ## [](#cron-プロパティ)``​ プロパティ Cron 式を使用することで、より複雑なスケジューリング戦略を設定できます。
パラメーター デフォルト値 説明 例

expression

-

Cron 式を使用してトリガーのタイミングを指定します。

expression="1 1 1 1,7 * ?"​

timeZone

システムプロパティとして渡されるタイムゾーン、またはマシンのオペレーティングシステムで設定されているタイムゾーン。

Java のタイムゾーン​形式のタイムゾーン

timeZone="America/Argentina/Buenos_Aires"
Cron 式を使用した例: ```xml ``` ## [](#関連情報)関連情報 - [スケジューラーエンドポイント (トリガー)](https://docs.mulesoft.com/jp/mule-runtime/4.3/scheduler-concept) # Scheduler エンドポイント (トリガー) Scheduler コンポーネントは、時間ベースの条件に基づいてフローの実行をトリガーする Mule イベントソースです。たとえば Scheduler によって、5 秒ごと、または指定したタイムゾーンで毎日 12 時 00 分にフロー処理をトリガーするメッセージを作成して送信される場合があります。 Mule アプリケーションに Scheduler を追加するときは次の点を考慮してください。 - Scheduler は、Mule が動作しているマシンと同じタイムゾーンを使用します。ただし、アプリケーションが CloudHub で動作している場合は、アプリケーションが動作している地理的リージョンに関係なく、Scheduler は UTC タイムゾーンに準拠します。 Scheduler 用に別のタイムゾーンを設定する場合は、​[Cron (​``​)](#props_cron_expressions)​の​`「timeZone」`​を参照してください。 - `disallowConcurrentExecution`​ プロパティを使用すると、以前にトリガーされた実行の処理中に Scheduler でフローの実行がトリガーできないようにできます。 - スケジュールされたトリガー時に利用できるリソースが 1 つもないために ​[back-pressure](https://docs.mulesoft.com/jp/mule-runtime/4.5/execution-engine#backpressure)​ が発生した場合、その実行はスキップされます。 - Mule Runtime Engine クラスターやマルチワーカー CloudHub デプロイメントでは、Scheduler はプライマリノードのみで (つまり 1 つの Mule インスタンスのみで) 実行されます。 ## [](#アーキテクチャ)アーキテクチャ 他の Mule イベントソースコンポーネントと同様、Scheduler は Mule フローの最初のコンポーネントです。 ![Mule フローの Scheduler コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/scheduler-component-ex.png) Scheduler の XML は以下の要素で構成されます。 - ``​: Scheduler の最上位レベルの要素。 - ``​: 次のいずれかの子を受け入れる第 2 レベル要素。 - ``​: 毎秒などの一般的なスケジュール頻度向け。 - ``​: [Cron 式](#cron_expressions)​およびタイムゾーン設定向け。 Scheduler により、固定の頻度、または Cron 式に基づいた間隔でスケジュール戦略が設定されます。次に例を示します。 - 次の Scheduler の固定の頻度設定では、15 秒ごとに実行されます。 ```xml ``` - Scheduler の Cron 式によって 15 秒ごとにフローが新たに実行され、Mule メッセージの生成がトリガーされます。 ```xml ``` 1 つ以上のプロセッサーが Scheduler に従う必要があります。プロセッサーには、HTTP Request 操作や Transform Message コンポーネントなど、Mule コンポーネントやコネクタ操作が含まれます。プロセッサーを提供しない場合、​`MuleRuntimeException`​ が発生し、Mule アプリケーションのデプロイメントが失敗して、次の ERROR メッセージがログに記録されます (読みやすいように編集済み)。 ```logs ERROR ...MuleRuntimeException ... The content of element 'flow' is not complete. One of '{"http://www.mulesoft.org/schema/mule/core":abstract-message-processor, "http://www.mulesoft.org/schema/mule/core":abstract-mixed-content-message-processor}' is expected. ``` Scheduler 属性については、​[参照](#reference)​を参照してください。 ## [](#reference)参照 Scheduler 要素は実行間隔および同時実行を設定するための属性を受け入れます。 ### [](#props_scheduler)Scheduler (​``​) デフォルトでは、Scheduler は設定されたケイデンスでフローの別のインスタンスを実行する前にそのフローの前の実行が完了するまで待機しません。この動作は、設定 XML で ​`disallowConcurrentExecution="true"`​ 属性を設定することで変更できます。
属性 XML 説明

disallowConcurrentExecution

この属性を ​true​ に設定すると、Scheduler は前の実行がまだ処理中であればスケジュールされた実行をスキップします。フローが完了すると、Scheduler は次に設定された間隔で実行されます。デフォルト値は ​false​ です。
次の例では、Scheduler はフローが完了までに要する時間が固定の頻度である 10 ミリ秒を超えると実行をスキップします。 ```xml ``` Scheduler が実行をスキップするたびに、たとえば次のような ​`Execution skipped`​ メッセージがログに記録されます (読みやすいように編集済み)。 ```logs INFO 2022-11-09 15:15:43,082 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. INFO 2022-11-09 15:15:43,083 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. ``` ### [](#props_fixed_frequency)固定頻度 (​``​) 固定頻度のスケジュール戦略では、次の属性を受け入れます。
属性 XML Default (デフォルト) 説明

Frequency (頻度)

frequency

1000

指定された ​timeUnit​ 設定で Scheduler がフローをトリガーする頻度。

Start Delay (開始遅延)

startDelay

0

アプリケーションが起動した後で Scheduler の最初の実行を遅延する時間。このプロパティでは頻度と同じ ​timeUnit​ を使用します。

Time Unit (時間単位)

timeUnit

MILLISECONDS

frequency​ と ​startDelay​ の値の次のいずれかの時間単位。

MILLISECONDS (ミリ秒)​、​SECONDS (秒)​、​MINUTES (分)​、​HOURS (時)​、または ​DAYS (日)​
次の戦略では、最初の 10 秒の遅延後、10 秒ごとに Scheduler の実行を遅延します。 ```xml ``` ### [](#props_cron_expressions)Cron (​``​) Cron 式を使用することで、より複雑なスケジューリング戦略を設定できます。
属性 XML 説明

Expression (式)

expression

Scheduler をトリガーする Cron 式。デフォルトの Cron 式はありません。式の詳細は、​Cron 式​を参照してください。例: expression="1 1 1 1,7 * ?"​

Time Zone (タイムゾーン)

timeZone

システムプロパティとして渡されるタイムゾーン、またはマシンのオペレーティングシステムで設定されているタイムゾーン。 Java のタイムゾーン​の値がサポートされます。Java の短縮表記 (​PST​ や ​AGT​) は使用せず、Java の完全表記 (​America/Los_Angeles​ など) を使用してください。例: timeZone="America/Argentina/Buenos_Aires"
次の例では、​`America/Los_Angeles`​ タイムゾーンで毎日 12 時 00 分にフローをトリガーする Cron 式を使用します。 ```xml ``` ## [](#cron_expressions)Cron 式 Cron は、日時情報を記述するのに広く利用されている標準です。Cron 式 (​``​ スケジュール戦略 (​``​) は、固定頻度スケジュール戦略では不可能な間隔でフローをトリガーする場合に便利です。 Scheduler は、毎秒を監視し、Quartz Cron 式が日時の設定と一致すると Mule イベントを作成します。イベントは 1 回だけ、または一定間隔でトリガーできます。 日時の式は、6 つの必須設定と、年の設定 (省略可能) で構成されます。設定は以下の順序で指定します。 1. 秒 (​`0`​-​`59`​) 2. 分 (​`0`​-​`59`​) 3. 時 (​`0`​-​`23`​) 4. 日 (​`1`​-​`31`​) 5. 月 (​`1`​-​`12`​ または ​`JAN`​-​`DEC`​) 6. 曜日 (​`1`​-​`7`​ or ​`SUN`​-​`SAT`​) 7. 年 (空白、または ​`1970`​-​`2099`​ の範囲内の 4 桁。例: `2019`​) Scheduler は Quartz Cron 式をサポートします。例をいくつか示します。
式 動作

1/2 * * * * ?

毎日 2 秒おきに実行。

0 15 10 ? * *

毎日午前 10 時 15 分に実行。 0 15 10 * * ? ​` と ​0 15 10 *​`0 15 10 * * ?​ は同じ結果になります。

0 15 10 * * ? 2019

2019 年の毎日午前 10 時 15 分に実行。

0 * 14 * * ?

毎日午後 2 時から 2 時 59 分まで、毎分実行。

0 0/5 14 * * ?

毎日午後 2 時から 2 時 55 分まで、5 分おきに実行。

1 1 1 1,7 * ?

毎月 1 日と 7 日の午前 1 時 1 分 1 秒に実行。
Scheduler コンポーネントは、Quartz Scheduler の特殊文字もサポートします。 - `*`​: すべての値。 - `?`​: 任意の 1 つの値。 - `-`​: 値の範囲。例: `1-3`​。 - `,`​: 追加の値。例: `1,7`​。 - `/`​: 増分値。例: `1/7`​。 - `L`​: 週または月の最終日、または月の最後の特定の曜日 (例: `6L`​ は月の最後の土曜日)。 - `W`​: 平日。日付項目で有効で、特定の日付以降になります。例: `15W`​ はその月の 15 日に最も近い平日を表します。 - `#`​: 月の "n" 日目。例: `#3`​ は月の 3 日。 詳細は、 [「CronExpression」](https://www.quartz-scheduler.org/api/2.3.0/org/quartz/CronExpression.html)​を参照してください。 次の例は、「hello」というメッセージを毎秒ログに記録します。 ```XML ``` Cron 式をビルドするための無料のオンラインツールがたくさんあります。 ## [](#anypoint-exchange-での例)Anypoint Exchange での例 [Anypoint Exchange](https://www.mulesoft.com/exchange/)​ での次の例は、Scheduler コンポーネントのユースケースを示しています。 - _Data Sync Using Watermarking and Batch (ウォーターマークとバッチを使用したデータの同期)_ - _Import Contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Import Leads into Salesforce (Salesforce へのリードのインポート)_ - _Importing a CSV File into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment Using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Salesforce to MySQL Database Using Batch Processing (バッチ処理を使用した Salesforce から MySQL データベースへのインポート)_ - _Sending a CSV File Through Email Using SMTP (SMTP を使用したメールでの CSV ファイルの送信)_ Anypoint Studio からプロジェクトをダウンロードして開くには、[Import a Mule Project from Exchange](https://docs.mulesoft.com/studio/import-project-exchange)を参照してください。 ## [](#anypoint-studio-でのデバッグ)Anypoint Studio でのデバッグ Anypoint Studio の​[デバッグモード](https://docs.mulesoft.com/studio/visual-debugger-concept)​では、Mule アプリケーションはイベントをトリガーできません。デバッグ時に、たとえば次のようにコンポーネントの下に表示される Studio の緑色の矢印アイコンをクリックすることで Scheduler を手動実行できます。 ![Scheduler での \[Debug (デバッグ)](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/scheduler-component-debug-ex.png) 矢印\] ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/flow-component) # Scheduler エンドポイント (トリガー) Scheduler コンポーネントは、時間ベースの条件に基づいてフローの実行をトリガーする Mule イベントソースです。たとえば Scheduler によって、5 秒ごと、または指定したタイムゾーンで毎日 12 時 00 分にフロー処理をトリガーするメッセージを作成して送信される場合があります。 Mule アプリケーションに Scheduler を追加するときは次の点を考慮してください。 - Scheduler は、Mule が動作しているマシンと同じタイムゾーンを使用します。ただし、アプリケーションが CloudHub で動作している場合は、アプリケーションが動作している地理的リージョンに関係なく、Scheduler は UTC タイムゾーンに準拠します。 Scheduler 用に別のタイムゾーンを設定する場合は、​[Cron (​``​)](#props_cron_expressions)​の​`「timeZone」`​を参照してください。 - `disallowConcurrentExecution`​ プロパティを使用すると、以前にトリガーされた実行の処理中に Scheduler でフローの実行がトリガーできないようにできます。 - スケジュールされたトリガー時に利用できるリソースが 1 つもないために ​[back-pressure](https://docs.mulesoft.com/jp/mule-runtime/4.7/execution-engine#backpressure)​ が発生した場合、その実行はスキップされます。 - Mule Runtime Engine クラスターやマルチワーカー CloudHub デプロイメントでは、Scheduler はプライマリノードのみで (つまり 1 つの Mule インスタンスのみで) 実行されます。 ## [](#アーキテクチャ)アーキテクチャ 他の Mule イベントソースコンポーネントと同様、Scheduler は Mule フローの最初のコンポーネントです。 ![Mule フローの Scheduler コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/scheduler-component-ex.png) Scheduler の XML は以下の要素で構成されます。 - ``​: Scheduler の最上位レベルの要素。 - ``​: 次のいずれかの子を受け入れる第 2 レベル要素。 - ``​: 毎秒などの一般的なスケジュール頻度向け。 - ``​: [Cron 式](#cron_expressions)​およびタイムゾーン設定向け。 Scheduler により、固定の頻度、または Cron 式に基づいた間隔でスケジュール戦略が設定されます。次に例を示します。 - 次の Scheduler の固定の頻度設定では、15 秒ごとに実行されます。 ```xml ``` - Scheduler の Cron 式によって 15 秒ごとにフローが新たに実行され、Mule メッセージの生成がトリガーされます。 ```xml ``` 1 つ以上のプロセッサーが Scheduler に従う必要があります。プロセッサーには、HTTP Request 操作や Transform Message コンポーネントなど、Mule コンポーネントやコネクタ操作が含まれます。プロセッサーを提供しない場合、​`MuleRuntimeException`​ が発生し、Mule アプリケーションのデプロイメントが失敗して、次の ERROR メッセージがログに記録されます (読みやすいように編集済み)。 ```logs ERROR ...MuleRuntimeException ... The content of element 'flow' is not complete. One of '{"http://www.mulesoft.org/schema/mule/core":abstract-message-processor, "http://www.mulesoft.org/schema/mule/core":abstract-mixed-content-message-processor}' is expected. ``` Scheduler 属性については、​[参照](#reference)​を参照してください。 ## [](#reference)参照 Scheduler 要素は実行間隔および同時実行を設定するための属性を受け入れます。 ### [](#props_scheduler)Scheduler (​``​) デフォルトでは、Scheduler は設定されたケイデンスでフローの別のインスタンスを実行する前にそのフローの前の実行が完了するまで待機しません。この動作は、設定 XML で ​`disallowConcurrentExecution="true"`​ 属性を設定することで変更できます。
属性 XML 説明

disallowConcurrentExecution

この属性を ​true​ に設定すると、Scheduler は前の実行がまだ処理中であればスケジュールされた実行をスキップします。フローが完了すると、Scheduler は次に設定された間隔で実行されます。デフォルト値は ​false​ です。
次の例では、Scheduler はフローが完了までに要する時間が固定の頻度である 10 ミリ秒を超えると実行をスキップします。 ```xml ``` Scheduler が実行をスキップするたびに、たとえば次のような ​`Execution skipped`​ メッセージがログに記録されます (読みやすいように編集済み)。 ```logs INFO 2022-11-09 15:15:43,082 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. INFO 2022-11-09 15:15:43,083 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. ``` ### [](#props_fixed_frequency)固定頻度 (​``​) 固定頻度のスケジュール戦略では、次の属性を受け入れます。
属性 XML Default (デフォルト) 説明

Frequency (頻度)

frequency

1000

指定された ​timeUnit​ 設定で Scheduler がフローをトリガーする頻度。

Start Delay (開始遅延)

startDelay

0

アプリケーションが起動した後で Scheduler の最初の実行を遅延する時間。このプロパティでは頻度と同じ ​timeUnit​ を使用します。

Time Unit (時間単位)

timeUnit

MILLISECONDS

frequency​ と ​startDelay​ の値の次のいずれかの時間単位。

MILLISECONDS (ミリ秒)​、​SECONDS (秒)​、​MINUTES (分)​、​HOURS (時)​、または ​DAYS (日)​
次の戦略では、最初の 10 秒の遅延後、10 秒ごとに Scheduler の実行を遅延します。 ```xml ``` ### [](#props_cron_expressions)Cron (​``​) Cron 式を使用することで、より複雑なスケジューリング戦略を設定できます。
属性 XML 説明

Expression (式)

expression

Scheduler をトリガーする Cron 式。デフォルトの Cron 式はありません。式の詳細は、​Cron 式​を参照してください。例: expression="1 1 1 1,7 * ?"​

Time Zone (タイムゾーン)

timeZone

システムプロパティとして渡されるタイムゾーン、またはマシンのオペレーティングシステムで設定されているタイムゾーン。 Java のタイムゾーン​の値がサポートされます。Java の短縮表記 (​PST​ や ​AGT​) は使用せず、Java の完全表記 (​America/Los_Angeles​ など) を使用してください。例: timeZone="America/Argentina/Buenos_Aires"
次の例では、​`America/Los_Angeles`​ タイムゾーンで毎日 12 時 00 分にフローをトリガーする Cron 式を使用します。 ```xml ``` ## [](#cron_expressions)Cron 式 Cron は、日時情報を記述するのに広く利用されている標準です。Cron 式 (​``​ スケジュール戦略 (​``​) は、固定頻度スケジュール戦略では不可能な間隔でフローをトリガーする場合に便利です。 Scheduler は、毎秒を監視し、Quartz Cron 式が日時の設定と一致すると Mule イベントを作成します。イベントは 1 回だけ、または一定間隔でトリガーできます。 日時の式は、6 つの必須設定と、年の設定 (省略可能) で構成されます。設定は以下の順序で指定します。 1. 秒 (​`0`​-​`59`​) 2. 分 (​`0`​-​`59`​) 3. 時 (​`0`​-​`23`​) 4. 日 (​`1`​-​`31`​) 5. 月 (​`1`​-​`12`​ または ​`JAN`​-​`DEC`​) 6. 曜日 (​`1`​-​`7`​ or ​`SUN`​-​`SAT`​) 7. 年 (空白、または ​`1970`​-​`2099`​ の範囲内の 4 桁。例: `2019`​) Scheduler は Quartz Cron 式をサポートします。例をいくつか示します。
式 動作

1/2 * * * * ?

毎日 2 秒おきに実行。

0 15 10 ? * *

毎日午前 10 時 15 分に実行。 0 15 10 * * ? ​` と ​0 15 10 *​`0 15 10 * * ?​ は同じ結果になります。

0 15 10 * * ? 2019

2019 年の毎日午前 10 時 15 分に実行。

0 * 14 * * ?

毎日午後 2 時から 2 時 59 分まで、毎分実行。

0 0/5 14 * * ?

毎日午後 2 時から 2 時 55 分まで、5 分おきに実行。

1 1 1 1,7 * ?

毎月 1 日と 7 日の午前 1 時 1 分 1 秒に実行。
Scheduler コンポーネントは、Quartz Scheduler の特殊文字もサポートします。 - `*`​: すべての値。 - `?`​: 任意の 1 つの値。 - `-`​: 値の範囲。例: `1-3`​。 - `,`​: 追加の値。例: `1,7`​。 - `/`​: 増分値。例: `1/7`​。 - `L`​: 週または月の最終日、または月の最後の特定の曜日 (例: `6L`​ は月の最後の土曜日)。 - `W`​: 平日。日付項目で有効で、特定の日付以降になります。例: `15W`​ はその月の 15 日に最も近い平日を表します。 - `#`​: 月の "n" 日目。例: `#3`​ は月の 3 日。 詳細は、 [「CronExpression」](https://www.quartz-scheduler.org/api/2.3.0/org/quartz/CronExpression.html)​を参照してください。 次の例は、「hello」というメッセージを毎秒ログに記録します。 ```XML ``` Cron 式をビルドするための無料のオンラインツールがたくさんあります。 ## [](#anypoint-exchange-での例)Anypoint Exchange での例 [Anypoint Exchange](https://www.mulesoft.com/exchange/)​ での次の例は、Scheduler コンポーネントのユースケースを示しています。 - _Data Sync Using Watermarking and Batch (ウォーターマークとバッチを使用したデータの同期)_ - _Import Contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Import Leads into Salesforce (Salesforce へのリードのインポート)_ - _Importing a CSV File into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment Using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Salesforce to MySQL Database Using Batch Processing (バッチ処理を使用した Salesforce から MySQL データベースへのインポート)_ - _Sending a CSV File Through Email Using SMTP (SMTP を使用したメールでの CSV ファイルの送信)_ Anypoint Studio からプロジェクトをダウンロードして開くには、[Import a Mule Project from Exchange](https://docs.mulesoft.com/studio/import-project-exchange) を参照してください。 ## [](#anypoint-studio-でのデバッグ)Anypoint Studio でのデバッグ Anypoint Studio の​[デバッグモード](https://docs.mulesoft.com/studio/visual-debugger-concept)​では、Mule アプリケーションはイベントをトリガーできません。デバッグ時に、たとえば次のようにコンポーネントの下に表示される Studio の緑色の矢印アイコンをクリックすることで Scheduler を手動実行できます。 ![Scheduler での \[Debug (デバッグ)](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/scheduler-component-debug-ex.png) 矢印\] ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/flow-component) # Scheduler エンドポイント (トリガー) Scheduler コンポーネントは、時間ベースの条件に基づいてフローの実行をトリガーする Mule イベントソースです。たとえば Scheduler によって、5 秒ごと、または指定したタイムゾーンで毎日 12 時 00 分にフロー処理をトリガーするメッセージを作成して送信される場合があります。 Mule アプリケーションに Scheduler を追加するときは次の点を考慮してください。 - Scheduler は、Mule が動作しているマシンと同じタイムゾーンを使用します。ただし、アプリケーションが CloudHub で動作している場合は、アプリケーションが動作している地理的リージョンに関係なく、Scheduler は UTC タイムゾーンに準拠します。 Scheduler 用に別のタイムゾーンを設定する場合は、​[Cron (​``​)](#props_cron_expressions)​の​`「timeZone」`​を参照してください。 - `disallowConcurrentExecution`​ プロパティを使用すると、以前にトリガーされた実行の処理中に Scheduler でフローの実行がトリガーできないようにできます。 - スケジュールされたトリガー時に利用できるリソースが 1 つもないために ​[back-pressure](https://docs.mulesoft.com/jp/mule-runtime/4.8/execution-engine#backpressure)​ が発生した場合、その実行はスキップされます。 - Mule Runtime Engine クラスターやマルチワーカー CloudHub デプロイメントでは、Scheduler はプライマリノードのみで (つまり 1 つの Mule インスタンスのみで) 実行されます。 ## [](#アーキテクチャ)アーキテクチャ 他の Mule イベントソースコンポーネントと同様、Scheduler は Mule フローの最初のコンポーネントです。 ![複数の Processor が表示されている、Mule フローの例の Scheduler コンポーネントのセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/scheduler-component-ex.png) Scheduler の XML は以下の要素で構成されます。 - ``​: Scheduler の最上位レベルの要素。 - ``​: 次のいずれかの子を受け入れる第 2 レベル要素。 - ``​: 毎秒などの一般的なスケジュール頻度向け。 - ``​: [Cron 式](#cron_expressions)​およびタイムゾーン設定向け。 Scheduler により、固定の頻度、または Cron 式に基づいた間隔でスケジュール戦略が設定されます。次に例を示します。 - 次の Scheduler の固定の頻度設定では、15 秒ごとに実行されます。 ```xml ``` - Scheduler の Cron 式によって 15 秒ごとにフローが新たに実行され、Mule メッセージの生成がトリガーされます。 ```xml ``` 1 つ以上のプロセッサーが Scheduler に従う必要があります。プロセッサーには、HTTP Request 操作や Transform Message コンポーネントなど、Mule コンポーネントやコネクタ操作が含まれます。プロセッサーを提供しない場合、​`MuleRuntimeException`​ が発生し、Mule アプリケーションのデプロイメントが失敗して、次の ERROR メッセージがログに記録されます (読みやすいように編集済み)。 ```logs ERROR ...MuleRuntimeException ... The content of element 'flow' is not complete. One of '{"http://www.mulesoft.org/schema/mule/core":abstract-message-processor, "http://www.mulesoft.org/schema/mule/core":abstract-mixed-content-message-processor}' is expected. ``` Scheduler 属性については、​[参照](#reference)​を参照してください。 ## [](#reference)参照 Scheduler 要素は実行間隔および同時実行を設定するための属性を受け入れます。 ### [](#props_scheduler)Scheduler (​``​) デフォルトでは、Scheduler は設定されたケイデンスでフローの別のインスタンスを実行する前にそのフローの前の実行が完了するまで待機しません。この動作は、設定 XML で ​`disallowConcurrentExecution="true"`​ 属性を設定することで変更できます。
属性 XML 説明

disallowConcurrentExecution

この属性を ​true​ に設定すると、Scheduler は前の実行がまだ処理中であればスケジュールされた実行をスキップします。フローが完了すると、Scheduler は次に設定された間隔で実行されます。デフォルト値は ​false​ です。
次の例では、Scheduler はフローが完了までに要する時間が固定の頻度である 10 ミリ秒を超えると実行をスキップします。 ```xml ``` Scheduler が実行をスキップするたびに、たとえば次のような ​`Execution skipped`​ メッセージがログに記録されます (読みやすいように編集済み)。 ```logs INFO 2022-11-09 15:15:43,082 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. INFO 2022-11-09 15:15:43,083 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. ``` ### [](#props_fixed_frequency)固定頻度 (​``​) 固定頻度のスケジュール戦略では、次の属性を受け入れます。
属性 XML Default (デフォルト) 説明

Frequency (頻度)

frequency

1000

指定された ​timeUnit​ 設定で Scheduler がフローをトリガーする頻度。

Start Delay (開始遅延)

startDelay

0

アプリケーションが起動した後で Scheduler の最初の実行を遅延する時間。このプロパティでは頻度と同じ ​timeUnit​ を使用します。

Time Unit (時間単位)

timeUnit

MILLISECONDS

frequency​ と ​startDelay​ の値の次のいずれかの時間単位。

MILLISECONDS (ミリ秒)​、​SECONDS (秒)​、​MINUTES (分)​、​HOURS (時)​、または ​DAYS (日)​
次の戦略では、最初の 10 秒の遅延後、10 秒ごとに Scheduler の実行を遅延します。 ```xml ``` ### [](#props_cron_expressions)Cron (​``​) Cron 式を使用することで、より複雑なスケジューリング戦略を設定できます。
属性 XML 説明

Expression (式)

expression

Scheduler をトリガーする Cron 式。デフォルトの Cron 式はありません。式の詳細は、​Cron 式​を参照してください。例: expression="1 1 1 1,7 * ?"​

Time Zone (タイムゾーン)

timeZone

システムプロパティとして渡されるタイムゾーン、またはマシンのオペレーティングシステムで設定されているタイムゾーン。 Java のタイムゾーン​の値がサポートされます。Java の短縮表記 (​PST​ や ​AGT​) は使用せず、Java の完全表記 (​America/Los_Angeles​ など) を使用してください。例: timeZone="America/Argentina/Buenos_Aires"
次の例では、​`America/Los_Angeles`​ タイムゾーンで毎日 12 時 00 分にフローをトリガーする Cron 式を使用します。 ```xml ``` ## [](#cron_expressions)Cron 式 Cron は、日時情報を記述するのに広く利用されている標準です。Cron 式 (​``​ スケジュール戦略 (​``​) は、固定頻度スケジュール戦略では不可能な間隔でフローをトリガーする場合に便利です。 Scheduler は、毎秒を監視し、Quartz Cron 式が日時の設定と一致すると Mule イベントを作成します。イベントは 1 回だけ、または一定間隔でトリガーできます。 日時の式は、6 つの必須設定と、年の設定 (省略可能) で構成されます。設定は以下の順序で指定します。 1. 秒 (​`0`​-​`59`​) 2. 分 (​`0`​-​`59`​) 3. 時 (​`0`​-​`23`​) 4. 日 (​`1`​-​`31`​) 5. 月 (​`1`​-​`12`​ または ​`JAN`​-​`DEC`​) 6. 曜日 (​`1`​-​`7`​ or ​`SUN`​-​`SAT`​) 7. 年 (空白、または ​`1970`​-​`2099`​ の範囲内の 4 桁。例: `2019`​) Scheduler は Quartz Cron 式をサポートします。例をいくつか示します。
式 動作

1/2 * * * * ?

毎日 2 秒おきに実行。

0 15 10 ? * *

毎日午前 10 時 15 分に実行。 0 15 10 * * ? ​` と ​0 15 10 *​`0 15 10 * * ?​ は同じ結果になります。

0 15 10 * * ? 2019

2019 年の毎日午前 10 時 15 分に実行。

0 * 14 * * ?

毎日午後 2 時から 2 時 59 分まで、毎分実行。

0 0/5 14 * * ?

毎日午後 2 時から 2 時 55 分まで、5 分おきに実行。

1 1 1 1,7 * ?

毎月 1 日と 7 日の午前 1 時 1 分 1 秒に実行。
Scheduler コンポーネントは、Quartz Scheduler の特殊文字もサポートします。 - `*`​: すべての値。 - `?`​: 任意の 1 つの値。 - `-`​: 値の範囲。例: `1-3`​。 - `,`​: 追加の値。例: `1,7`​。 - `/`​: 増分値。例: `1/7`​。 - `L`​: 週または月の最終日、または月の最後の特定の曜日 (例: `6L`​ は月の最後の土曜日)。 - `W`​: 平日。日付項目で有効で、特定の日付以降になります。例: `15W`​ はその月の 15 日に最も近い平日を表します。 - `#`​: 月の "n" 日目。例: `#3`​ は月の 3 日。 詳細は、 [「CronExpression」](https://www.quartz-scheduler.org/api/2.3.0/org/quartz/CronExpression.html)​を参照してください。 次の例は、「hello」というメッセージを毎秒ログに記録します。 ```XML ``` Cron 式をビルドするための無料のオンラインツールがたくさんあります。 ## [](#anypoint-exchange-での例)Anypoint Exchange での例 [Anypoint Exchange](https://www.mulesoft.com/exchange/)​ での次の例は、Scheduler コンポーネントのユースケースを示しています。 - _Data Sync Using Watermarking and Batch (ウォーターマークとバッチを使用したデータの同期)_ - _Import Contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Import Leads into Salesforce (Salesforce へのリードのインポート)_ - _Importing a CSV File into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment Using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Salesforce to MySQL Database Using Batch Processing (バッチ処理を使用した Salesforce から MySQL データベースへのインポート)_ - _Sending a CSV File Through Email Using SMTP (SMTP を使用したメールでの CSV ファイルの送信)_ Anypoint Studio からプロジェクトをダウンロードして開くには、[Import a Mule Project from Exchange](https://docs.mulesoft.com/studio/import-project-exchange) を参照してください。 ## [](#anypoint-studio-でのデバッグ)Anypoint Studio でのデバッグ Anypoint Studio の​[デバッグモード](https://docs.mulesoft.com/studio/visual-debugger-concept)​では、Mule アプリケーションはイベントをトリガーできません。デバッグ時に、たとえば次のようにコンポーネントの下に表示される Studio の緑色の矢印アイコンをクリックすることで Scheduler を手動実行できます。 ![Process と Error handling が表示されている、フローの例の Scheduler コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/scheduler-component-debug-ex.png) ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/flow-component) # Scheduler エンドポイント (トリガー) Scheduler コンポーネントは、時間ベースの条件に基づいてフローの実行をトリガーする Mule イベントソースです。たとえば Scheduler によって、5 秒ごと、または指定したタイムゾーンで毎日 12 時 00 分にフロー処理をトリガーするメッセージを作成して送信される場合があります。 Mule アプリケーションに Scheduler を追加するときは次の点を考慮してください。 - Scheduler は、Mule が動作しているマシンと同じタイムゾーンを使用します。ただし、アプリケーションが CloudHub で動作している場合は、アプリケーションが動作している地理的リージョンに関係なく、Scheduler は UTC タイムゾーンに準拠します。 Scheduler 用に別のタイムゾーンを設定する場合は、​[Cron (​``​)](#props_cron_expressions)​の​`「timeZone」`​を参照してください。 - `disallowConcurrentExecution`​ プロパティを使用すると、以前にトリガーされた実行の処理中に Scheduler でフローの実行がトリガーできないようにできます。 - スケジュールされたトリガー時に利用できるリソースが 1 つもないために ​[back-pressure](https://docs.mulesoft.com/jp/mule-runtime/4.9/execution-engine#backpressure)​ が発生した場合、その実行はスキップされます。 - Mule Runtime Engine クラスターやマルチワーカー CloudHub デプロイメントでは、Scheduler はプライマリノードのみで (つまり 1 つの Mule インスタンスのみで) 実行されます。 ## [](#アーキテクチャ)アーキテクチャ 他の Mule イベントソースコンポーネントと同様、Scheduler は Mule フローの最初のコンポーネントです。 ![複数の Processor が表示されている、Mule フローの例の Scheduler コンポーネントのセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/scheduler-component-ex.png) Scheduler の XML は以下の要素で構成されます。 - ``​: Scheduler の最上位レベルの要素。 - ``​: 次のいずれかの子を受け入れる第 2 レベル要素。 - ``​: 毎秒などの一般的なスケジュール頻度向け。 - ``​: [Cron 式](#cron_expressions)​およびタイムゾーン設定向け。 Scheduler により、固定の頻度、または Cron 式に基づいた間隔でスケジュール戦略が設定されます。次に例を示します。 - 次の Scheduler の固定の頻度設定では、15 秒ごとに実行されます。 ```xml ``` - Scheduler の Cron 式によって 15 秒ごとにフローが新たに実行され、Mule メッセージの生成がトリガーされます。 ```xml ``` 1 つ以上のプロセッサーが Scheduler に従う必要があります。プロセッサーには、HTTP Request 操作や Transform Message コンポーネントなど、Mule コンポーネントやコネクタ操作が含まれます。プロセッサーを提供しない場合、​`MuleRuntimeException`​ が発生し、Mule アプリケーションのデプロイメントが失敗して、次の ERROR メッセージがログに記録されます (読みやすいように編集済み)。 ```logs ERROR ...MuleRuntimeException ... The content of element 'flow' is not complete. One of '{"http://www.mulesoft.org/schema/mule/core":abstract-message-processor, "http://www.mulesoft.org/schema/mule/core":abstract-mixed-content-message-processor}' is expected. ``` Scheduler 属性については、​[参照](#reference)​を参照してください。 ## [](#reference)参照 Scheduler 要素は実行間隔および同時実行を設定するための属性を受け入れます。 ### [](#props_scheduler)Scheduler (​``​) デフォルトでは、Scheduler は設定されたケイデンスでフローの別のインスタンスを実行する前にそのフローの前の実行が完了するまで待機しません。この動作は、設定 XML で ​`disallowConcurrentExecution="true"`​ 属性を設定することで変更できます。
属性 XML 説明

disallowConcurrentExecution

この属性を ​true​ に設定すると、Scheduler は前の実行がまだ処理中であればスケジュールされた実行をスキップします。フローが完了すると、Scheduler は次に設定された間隔で実行されます。デフォルト値は ​false​ です。
次の例では、Scheduler はフローが完了までに要する時間が固定の頻度である 10 ミリ秒を超えると実行をスキップします。 ```xml ``` Scheduler が実行をスキップするたびに、たとえば次のような ​`Execution skipped`​ メッセージがログに記録されます (読みやすいように編集済み)。 ```logs INFO 2022-11-09 15:15:43,082 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. INFO 2022-11-09 15:15:43,083 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. ``` ### [](#props_fixed_frequency)固定頻度 (​``​) 固定頻度のスケジュール戦略では、次の属性を受け入れます。
属性 XML Default (デフォルト) 説明

Frequency (頻度)

frequency

1000

指定された ​timeUnit​ 設定で Scheduler がフローをトリガーする頻度。

Start Delay (開始遅延)

startDelay

0

アプリケーションが起動した後で Scheduler の最初の実行を遅延する時間。このプロパティでは頻度と同じ ​timeUnit​ を使用します。

Time Unit (時間単位)

timeUnit

MILLISECONDS

frequency​ と ​startDelay​ の値の次のいずれかの時間単位。

MILLISECONDS (ミリ秒)​、​SECONDS (秒)​、​MINUTES (分)​、​HOURS (時)​、または ​DAYS (日)​
次の戦略では、最初の 10 秒の遅延後、10 秒ごとに Scheduler の実行を遅延します。 ```xml ``` ### [](#props_cron_expressions)Cron (​``​) Cron 式を使用することで、より複雑なスケジューリング戦略を設定できます。
属性 XML 説明

Expression (式)

expression

Scheduler をトリガーする Cron 式。デフォルトの Cron 式はありません。式の詳細は、​Cron 式​を参照してください。例: expression="1 1 1 1,7 * ?"​

Time Zone (タイムゾーン)

timeZone

システムプロパティとして渡されるタイムゾーン、またはマシンのオペレーティングシステムで設定されているタイムゾーン。 Java のタイムゾーン​の値がサポートされます。Java の短縮表記 (​PST​ や ​AGT​) は使用せず、Java の完全表記 (​America/Los_Angeles​ など) を使用してください。例: timeZone="America/Argentina/Buenos_Aires"
次の例では、​`America/Los_Angeles`​ タイムゾーンで毎日 12 時 00 分にフローをトリガーする Cron 式を使用します。 ```xml ``` ## [](#cron_expressions)Cron 式 Cron は、日時情報を記述するのに広く利用されている標準です。Cron 式 (​``​ スケジュール戦略 (​``​) は、固定頻度スケジュール戦略では不可能な間隔でフローをトリガーする場合に便利です。 Scheduler は、毎秒を監視し、Quartz Cron 式が日時の設定と一致すると Mule イベントを作成します。イベントは 1 回だけ、または一定間隔でトリガーできます。 日時の式は、6 つの必須設定と、年の設定 (省略可能) で構成されます。設定は以下の順序で指定します。 1. 秒 (​`0`​-​`59`​) 2. 分 (​`0`​-​`59`​) 3. 時 (​`0`​-​`23`​) 4. 日 (​`1`​-​`31`​) 5. 月 (​`1`​-​`12`​ または ​`JAN`​-​`DEC`​) 6. 曜日 (​`1`​-​`7`​ or ​`SUN`​-​`SAT`​) 7. 年 (空白、または ​`1970`​-​`2099`​ の範囲内の 4 桁。例: `2019`​) Scheduler は Quartz Cron 式をサポートします。例をいくつか示します。
式 動作

1/2 * * * * ?

毎日 2 秒おきに実行。

0 15 10 ? * *

毎日午前 10 時 15 分に実行。 0 15 10 * * ? ​` と ​0 15 10 *​`0 15 10 * * ?​ は同じ結果になります。

0 15 10 * * ? 2019

2019 年の毎日午前 10 時 15 分に実行。

0 * 14 * * ?

毎日午後 2 時から 2 時 59 分まで、毎分実行。

0 0/5 14 * * ?

毎日午後 2 時から 2 時 55 分まで、5 分おきに実行。

1 1 1 1,7 * ?

毎月 1 日と 7 日の午前 1 時 1 分 1 秒に実行。
Scheduler コンポーネントは、Quartz Scheduler の特殊文字もサポートします。 - `*`​: すべての値。 - `?`​: 任意の 1 つの値。 - `-`​: 値の範囲。例: `1-3`​。 - `,`​: 追加の値。例: `1,7`​。 - `/`​: 増分値。例: `1/7`​。 - `L`​: 週または月の最終日、または月の最後の特定の曜日 (例: `6L`​ は月の最後の土曜日)。 - `W`​: 平日。日付項目で有効で、特定の日付以降になります。例: `15W`​ はその月の 15 日に最も近い平日を表します。 - `#`​: 月の "n" 日目。例: `#3`​ は月の 3 日。 詳細は、 [「CronExpression」](https://www.quartz-scheduler.org/api/2.3.0/org/quartz/CronExpression.html)​を参照してください。 次の例は、「hello」というメッセージを毎秒ログに記録します。 ```XML ``` Cron 式をビルドするための無料のオンラインツールがたくさんあります。 ## [](#anypoint-exchange-での例)Anypoint Exchange での例 [Anypoint Exchange](https://www.mulesoft.com/exchange/)​ での次の例は、Scheduler コンポーネントのユースケースを示しています。 - _Data Sync Using Watermarking and Batch (ウォーターマークとバッチを使用したデータの同期)_ - _Import Contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Import Leads into Salesforce (Salesforce へのリードのインポート)_ - _Importing a CSV File into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment Using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Salesforce to MySQL Database Using Batch Processing (バッチ処理を使用した Salesforce から MySQL データベースへのインポート)_ - _Sending a CSV File Through Email Using SMTP (SMTP を使用したメールでの CSV ファイルの送信)_ Anypoint Studio からプロジェクトをダウンロードして開くには、[Import a Mule Project from Exchange](https://docs.mulesoft.com/studio/import-project-exchange) を参照してください。 ## [](#anypoint-studio-でのデバッグ)Anypoint Studio でのデバッグ Anypoint Studio の​[デバッグモード](https://docs.mulesoft.com/studio/visual-debugger-concept)​では、Mule アプリケーションはイベントをトリガーできません。デバッグ時に、たとえば次のようにコンポーネントの下に表示される Studio の緑色の矢印アイコンをクリックすることで Scheduler を手動実行できます。 ![Process と Error handling が表示されている、フローの例の Scheduler コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/scheduler-component-debug-ex.png) ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/flow-component) # Scripting コンポーネントの移行 Mule 3 の ​``​ コンポーネントは、新しい ​``​ モジュールに置き換わります。この新しいモジュールは、構文が少し変更されていますが、機能面ではかなり似ています。 Mule 3 の例: スクリプティング ```xml ``` + Mule 4 の例: スクリプティング ```xml ${file::greedy.groovy} #[{currency: vars.currency}] ``` このように、主な違いは DataWeave を使用して入力パラメーターを生成できるようになったことです。 ## [](#スクリプトから変数へのアクセス)スクリプトから変数へのアクセス 上の例では、変数を使用してパラメーターをスクリプトに渡す方法を示しています。Mule アプリケーションの変更によりスクリプトを変更する必要がないように、スクリプトをフローの残りの部分から分離しておくことが最良の方法です。 ただし、​`vars`​ キーワードを使用して、引き続きスクリプトから変数にアクセスすることができます。例: Mule 4 の例: 変数への直接アクセス ```xml return "currency is " + vars.currency ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module ドキュメント](https://docs.mulesoft.com/jp/scripting-module/latest/) # Scripting コンポーネントの移行 Mule 3 の ​``​ コンポーネントは、新しい ​``​ モジュールに置き換わります。この新しいモジュールは、構文が少し変更されていますが、機能面ではかなり似ています。 Mule 3 の例: スクリプティング ```xml ``` + Mule 4 の例: スクリプティング ```xml ${file::greedy.groovy} #[{currency: vars.currency}] ``` このように、主な違いは DataWeave を使用して入力パラメーターを生成できるようになったことです。 ## [](#スクリプトから変数へのアクセス)スクリプトから変数へのアクセス 上の例では、変数を使用してパラメーターをスクリプトに渡す方法を示しています。Mule アプリケーションの変更によりスクリプトを変更する必要がないように、スクリプトをフローの残りの部分から分離しておくことが最良の方法です。 ただし、​`vars`​ キーワードを使用して、引き続きスクリプトから変数にアクセスすることができます。例: Mule 4 の例: 変数への直接アクセス ```xml return "currency is " + vars.currency ``` スクリプティングモジュールを使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module ドキュメント](https://docs.mulesoft.com/jp/scripting-module/latest/) # Scripting コンポーネントの移行 Mule 3 の ​``​ コンポーネントは、新しい ​``​ モジュールに置き換わります。この新しいモジュールは、構文が少し変更されていますが、機能面ではかなり似ています。 Mule 3 の例: スクリプティング ```xml ``` + Mule 4 の例: スクリプティング ```xml ${file::greedy.groovy} #[{currency: vars.currency}] ``` このように、主な違いは DataWeave を使用して入力パラメーターを生成できるようになったことです。 ## [](#スクリプトから変数へのアクセス)スクリプトから変数へのアクセス 上の例では、変数を使用してパラメーターをスクリプトに渡す方法を示しています。Mule アプリケーションの変更によりスクリプトを変更する必要がないように、スクリプトをフローの残りの部分から分離しておくことが最良の方法です。 ただし、​`vars`​ キーワードを使用して、引き続きスクリプトから変数にアクセスすることができます。次に例を示します。 Mule 4 の例: 変数への直接アクセス ```xml return "currency is " + vars.currency ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module ドキュメント](https://docs.mulesoft.com/jp/scripting-module/latest/) # Scripting コンポーネントの移行 Mule 3 の ​``​ コンポーネントは、新しい ​``​ モジュールに置き換わります。この新しいモジュールは、構文が少し変更されていますが、機能面ではかなり似ています。 Mule 3 の例: スクリプティング ```xml ``` + Mule 4 の例: スクリプティング ```xml ${file::greedy.groovy} #[{currency: vars.currency}] ``` このように、主な違いは DataWeave を使用して入力パラメーターを生成できるようになったことです。 ## [](#スクリプトから変数へのアクセス)スクリプトから変数へのアクセス 上の例では、変数を使用してパラメーターをスクリプトに渡す方法を示しています。Mule アプリケーションの変更によりスクリプトを変更する必要がないように、スクリプトをフローの残りの部分から分離しておくことが最良の方法です。 ただし、​`vars`​ キーワードを使用して、引き続きスクリプトから変数にアクセスすることができます。例: Mule 4 の例: 変数への直接アクセス ```xml return "currency is " + vars.currency ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module ドキュメント](https://docs.mulesoft.com/jp/scripting-module/latest/) # Scripting コンポーネントの移行 Mule 3 の ​``​ コンポーネントは、新しい ​``​ モジュールに置き換わります。この新しいモジュールは、構文が少し変更されていますが、機能面ではかなり似ています。 Mule 3 の例: スクリプティング ```xml ``` + Mule 4 の例: スクリプティング ```xml ${file::greedy.groovy} #[{currency: vars.currency}] ``` このように、主な違いは DataWeave を使用して入力パラメーターを生成できるようになったことです。 ## [](#スクリプトから変数へのアクセス)スクリプトから変数へのアクセス 上の例では、変数を使用してパラメーターをスクリプトに渡す方法を示しています。Mule アプリケーションの変更によりスクリプトを変更する必要がないように、スクリプトをフローの残りの部分から分離しておくことが最良の方法です。 ただし、​`vars`​ キーワードを使用して、引き続きスクリプトから変数にアクセスすることができます。例: Mule 4 の例: 変数への直接アクセス ```xml return "currency is " + vars.currency ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module ドキュメント](https://docs.mulesoft.com/jp/scripting-module/latest/) # Scripting コンポーネントの移行 Mule 3 の ​``​ コンポーネントは、新しい ​``​ モジュールに置き換わります。この新しいモジュールは、構文が少し変更されていますが、機能面ではかなり似ています。 Mule 3 の例: スクリプティング ```xml ``` + Mule 4 の例: スクリプティング ```xml ${file::greedy.groovy} #[{currency: vars.currency}] ``` このように、主な違いは DataWeave を使用して入力パラメーターを生成できるようになったことです。 ## [](#スクリプトから変数へのアクセス)スクリプトから変数へのアクセス 上の例では、変数を使用してパラメーターをスクリプトに渡す方法を示しています。Mule アプリケーションの変更によりスクリプトを変更する必要がないように、スクリプトをフローの残りの部分から分離しておくことが最良の方法です。 ただし、​`vars`​ キーワードを使用して、引き続きスクリプトから変数にアクセスすることができます。例: Mule 4 の例: 変数への直接アクセス ```xml return "currency is " + vars.currency ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module ドキュメント](https://docs.mulesoft.com/jp/scripting-module/latest/) # Scripting コンポーネントの移行 Mule 3 の ​``​ コンポーネントは、新しい ​``​ モジュールに置き換わります。この新しいモジュールは、構文が少し変更されていますが、機能面ではかなり似ています。 Mule 3 の例: スクリプティング ```xml ``` + Mule 4 の例: スクリプティング ```xml ${file::greedy.groovy} #[{currency: vars.currency}] ``` このように、主な違いは DataWeave を使用して入力パラメーターを生成できるようになったことです。 ## [](#スクリプトから変数へのアクセス)スクリプトから変数へのアクセス 上の例では、変数を使用してパラメーターをスクリプトに渡す方法を示しています。Mule アプリケーションの変更によりスクリプトを変更する必要がないように、スクリプトをフローの残りの部分から分離しておくことが最良の方法です。 ただし、​`vars`​ キーワードを使用して、引き続きスクリプトから変数にアクセスすることができます。例: Mule 4 の例: 変数への直接アクセス ```xml return "currency is " + vars.currency ``` Scripting Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-scripting-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Scripting Module ドキュメント](https://docs.mulesoft.com/jp/scripting-module/latest/) # Set Payload トランスフォーマー Set Payload (​`set-payload`​) コンポーネントは、メッセージのペイロードを更新します。 ペイロードは、文字列リテラルまたは DataWeave 式です。ただし、​`set-payload`​ コンポーネントは複雑な式や変換には向いておらず、選択などのシンプルな処理に適しています。複雑なシナリオでは ​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about)​を使用してください。
項目 使い方 説明

Value (値) (​value​)

必須

文字列リテラルまたはペイロードの設定方法を定義した DataWeave 式を指定できます。例: "some string"​ または ​#[now()]​。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

ペイロードに割り当てる値の MIME タイプ。例: text/plain​ または ​application/json​。

Encoding (エンコード) (​encoding​)

省略可能

ペイロードに割り当てる値のエンコード方式。例: UTF-8​。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、出力される Mule メッセージにのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
次の XML 例では、静的な値でペイロードを設定しています。 静的なコンテンツの例: ```xml ``` 次の例では、メッセージのペイロードを「Hello, World」という文字列リテラルと、​`#['Hello World!' ++ ' Today is ' ++ now()]`​ という DataWeave 式を使用した今日の日付に設定しています。 式によるコンテンツの例: ```xml ``` ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-message) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # Set Payload トランスフォーマー Set Payload (​`set-payload`​) コンポーネントは、メッセージのペイロードを更新します。 ペイロードは、文字列リテラルまたは DataWeave 式です。ただし、​`set-payload`​ コンポーネントは複雑な式や変換には向いておらず、選択などのシンプルな処理に適しています。複雑なシナリオでは ​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about)​を使用してください。
項目 使い方 説明

Value (値) (​value​)

必須

文字列リテラルまたはペイロードの設定方法を定義した DataWeave 式を指定できます。例: "some string"​ または ​#[now()]​。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

ペイロードに割り当てる値の MIME タイプ。例: text/plain​ または ​application/json​。

Encoding (エンコード) (​encoding​)

省略可能

ペイロードに割り当てる値のエンコード方式。例: UTF-8​。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、出力される Mule メッセージにのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
次の XML 例では、静的な値でペイロードを設定しています。 静的なコンテンツの例: ```xml ``` 次の例では、メッセージのペイロードを「Hello, World」という文字列リテラルと、​`#['Hello World!' ++ ' Today is ' ++ now()]`​ という DataWeave 式を使用した今日の日付に設定しています。 式によるコンテンツの例: ```xml ``` ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-message) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # Set Payload トランスフォーマー Set Payload (​`set-payload`​) コンポーネントは、メッセージのペイロードを更新します。 ペイロードは、文字列リテラルまたは DataWeave 式です。ただし、​`set-payload`​ コンポーネントは複雑な式や変換には向いておらず、選択などのシンプルな処理に適しています。複雑なシナリオでは ​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about)​を使用してください。
項目 使用方法 説明

Value (値) (​value​)

必須

文字列リテラルまたはペイロードの設定方法を定義した DataWeave 式を指定できます。例: "some string"​ または ​#[now()]​。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

ペイロードに割り当てる値の MIME タイプ。例: text/plain​ または ​application/json​。

Encoding (エンコード) (​encoding​)

省略可能

ペイロードに割り当てる値のエンコード方式。例: UTF-8

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、出力される Mule メッセージにのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
次の XML 例では、静的な値でペイロードを設定しています。 静的なコンテンツの例: ```xml ``` 次の例では、メッセージのペイロードを「Hello, World」という文字列リテラルと、​`#['Hello World!' ++ ' Today is ' ++ now()]`​ という DataWeave 式を使用した今日の日付に設定しています。 式によるコンテンツの例: ```xml ``` ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-message) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # Set Payload トランスフォーマー Set Payload (​`set-payload`​) コンポーネントは、メッセージのペイロードを更新します。 ペイロードは、文字列リテラルまたは DataWeave 式です。ただし、​`set-payload`​ コンポーネントは複雑な式や変換には向いておらず、選択などのシンプルな処理に適しています。複雑なシナリオでは ​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about)​を使用してください。
項目 使い方 説明

Value (値) (​value​)

必須

文字列リテラルまたはペイロードの設定方法を定義した DataWeave 式を指定できます。例: "some string"​ または ​#[now()]​。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

ペイロードに割り当てる値の MIME タイプ。例: text/plain​ または ​application/json​。

Encoding (エンコード) (​encoding​)

省略可能

ペイロードに割り当てる値のエンコード方式。例: UTF-8​。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、出力される Mule メッセージにのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
次の XML 例では、静的な値でペイロードを設定しています。 静的なコンテンツの例: ```xml ``` 次の例では、メッセージのペイロードを「Hello, World」という文字列リテラルと、​`#['Hello World!' ++ ' Today is ' ++ now()]`​ という DataWeave 式を使用した今日の日付に設定しています。 式によるコンテンツの例: ```xml ``` ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-message) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # Set Payload トランスフォーマー Set Payload (​`set-payload`​) コンポーネントは、メッセージのペイロードを更新します。 ペイロードは、文字列リテラルまたは DataWeave 式です。ただし、​`set-payload`​ コンポーネントは複雑な式や変換には向いておらず、選択などのシンプルな処理に適しています。複雑なシナリオでは ​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about)​を使用してください。
項目 使い方 説明

Value (値) (​value​)

必須

文字列リテラルまたはペイロードの設定方法を定義した DataWeave 式を指定できます。例: "some string"​ または ​#[now()]​。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

ペイロードに割り当てる値の MIME タイプ。例: text/plain​ または ​application/json​。

Encoding (エンコード) (​encoding​)

省略可能

ペイロードに割り当てる値のエンコード方式。例: UTF-8​。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、出力される Mule メッセージにのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
次の XML 例では、静的な値でペイロードを設定しています。 静的なコンテンツの例: ```xml ``` 次の例では、メッセージのペイロードを「Hello, World」という文字列リテラルと、​`#['Hello World!' ++ ' Today is ' ++ now()]`​ という DataWeave 式を使用した今日の日付に設定しています。 式によるコンテンツの例: ```xml ``` ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-message) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # Set Payload トランスフォーマー Set Payload (​`set-payload`​) コンポーネントは、メッセージのペイロードを更新します。 ペイロードは、文字列リテラルまたは DataWeave 式です。ただし、​`set-payload`​ コンポーネントは複雑な式や変換には向いておらず、選択などのシンプルな処理に適しています。複雑なシナリオでは ​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about)​を使用してください。
項目 使い方 説明

Value (値) (​value​)

必須

文字列リテラルまたはペイロードの設定方法を定義した DataWeave 式を指定できます。例: "some string"​ または ​#[now()]​。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

ペイロードに割り当てる値の MIME タイプ。例: text/plain​ または ​application/json​。

Encoding (エンコード) (​encoding​)

省略可能

ペイロードに割り当てる値のエンコード方式。例: UTF-8​。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、出力される Mule メッセージにのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
次の XML 例では、静的な値でペイロードを設定しています。 静的なコンテンツの例: ```xml ``` 次の例では、メッセージのペイロードを「Hello, World」という文字列リテラルと、​`#['Hello World!' ++ ' Today is ' ++ now()]`​ という DataWeave 式を使用した今日の日付に設定しています。 式によるコンテンツの例: ```xml ``` ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-message) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # Set Payload トランスフォーマー Set Payload (​`set-payload`​) コンポーネントは、メッセージのペイロードを更新します。 ペイロードは、文字列リテラルまたは DataWeave 式です。ただし、​`set-payload`​ コンポーネントは複雑な式や変換には向いておらず、選択などのシンプルな処理に適しています。複雑なシナリオでは ​[Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about)​を使用してください。
項目 使い方 説明

Value (値) (​value​)

必須

文字列リテラルまたはペイロードの設定方法を定義した DataWeave 式を指定できます。例: "some string"​ または ​#[now()]​。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

ペイロードに割り当てる値の MIME タイプ。例: text/plain​ または ​application/json​。

Encoding (エンコード) (​encoding​)

省略可能

ペイロードに割り当てる値のエンコード方式。例: UTF-8​。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、出力される Mule メッセージにのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
次の XML 例では、静的な値でペイロードを設定しています。 静的なコンテンツの例: ```xml ``` 次の例では、メッセージのペイロードを「Hello, World」という文字列リテラルと、​`#['Hello World!' ++ ' Today is ' ++ now()]`​ という DataWeave 式を使用した今日の日付に設定しています。 式によるコンテンツの例: ```xml ``` ## [](#関連情報)関連情報 - [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-message) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # Set Transaction Id Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![custom-transaction-id](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#set-transaction-id-リファレンス)Set Transaction ID リファレンス
項目 説明

Transaction ID (トランザクション ID) (​id​)

識別子の値を定義します。式またはリテラルにすることができます。デフォルトでは、コンポーネントには数値が割り当てられます。
## [](#関連情報)関連情報 - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events-in-components) # Set Transaction Id Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![custom-transaction-id](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#set-transaction-id-リファレンス)Set Transaction ID リファレンス
項目 説明

Transaction ID (トランザクション ID) (​id​)

識別子の値を定義します。式またはリテラルにすることができます。デフォルトでは、コンポーネントには数値が割り当てられます。
## [](#関連情報)関連情報 - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events-in-components) # Set Transaction Id Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![custom-transaction-id](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#set-transaction-id-リファレンス)Set Transaction ID リファレンス
項目 説明

Transaction ID (トランザクション ID) (​id​)

識別子の値を定義します。式またはリテラルにすることができます。デフォルトでは、コンポーネントには数値が割り当てられます。
## [](#関連情報)関連情報 - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events-in-components) # Set Transaction Id Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![custom-transaction-id](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#set-transaction-id-リファレンス)Set Transaction ID リファレンス
項目 説明

Transaction ID (トランザクション ID) (​id​)

識別子の値を定義します。式またはリテラルにすることができます。デフォルトでは、コンポーネントには数値が割り当てられます。
## [](#関連情報)関連情報 - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events-in-components) # Set Transaction Id Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![Mule フローのトランザクション ID を定義する設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#set-transaction-id-リファレンス)Set Transaction ID リファレンス
項目 説明

Transaction ID (トランザクション ID) (​id​)

識別子の値を定義します。式またはリテラルにすることができます。デフォルトでは、コンポーネントには数値が割り当てられます。
## [](#関連情報)関連情報 - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events-in-components) # Set Transaction Id Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![Mule フローのトランザクション ID を定義する設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#set-transaction-id-リファレンス)Set Transaction ID リファレンス
項目 説明

Transaction ID (トランザクション ID) (​id​)

識別子の値を定義します。式またはリテラルにすることができます。デフォルトでは、コンポーネントには数値が割り当てられます。
## [](#関連情報)関連情報 - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events-in-components) # Set Transaction Id Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![Mule フローのトランザクション ID を定義する設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#set-transaction-id-リファレンス)Set Transaction ID リファレンス
項目 説明

Transaction ID (トランザクション ID) (​id​)

識別子の値を定義します。式またはリテラルにすることができます。デフォルトでは、コンポーネントには数値が割り当てられます。
## [](#関連情報)関連情報 - [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events-in-components) # Set Variable トランスフォーマー Set Variable (​`set-variable`​) コンポーネントは、Mule アプリケーションのフロー内で使用する値を格納するための変数を作成または更新します。文字列やメッセージといったシンプルなリテラル値、メッセージペイロード、または属性オブジェクトを格納できます。たとえば、メッセージの元の (処理前の) ペイロードを格納しておくことで、後でフローやエラーハンドラーで使用できるようにします。 `set-variable`​ コンポーネントは、複雑な式や変換には向いていません。このコンポーネントは選択などのシンプルな処理に使用し、複雑なシナリオでは ​[Transform コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about)​を使用してください。
項目 使い方 説明

Variable Name (変数名) (​variableName​)

必須

変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。

Value (値) (​value​)

必須

変数の値で、文字列または DataWeave 式を指定できます。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

変数の MIME 型 (​text/plain​ や ​application/json​ など) を設定します。

Encoding (エンコード) (​encoding​)

省略可能

変数のエンコード (​ISO 10646/Unicode(UTF-8)​ など) を設定します。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、格納されている出力値にのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
## [](#例)例 次の例では、変数を文字列に設定しています。 - Name (名前) = ​`myVar` - Value (値) = ​`my first variable` 次の例は、​`5`​ の値を生成する DataWeave 操作を使用して変数を設定しています。 - Name (名前) = ​`myVar` - Value (値) = Anypoint Studio では ​`#[max([1,2,3] ++ [3,4,5])]`​。 次の例は、変数をメッセージペイロードに設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`payload`​、Anypoint Studio では ​`#[payload]`​。 次の例は、変数をメッセージ属性に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`attributes`​、Anypoint Studio では ​`#[attributes]`​。 次の例は、変数をメッセージ全体に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`message`​、Anypoint Studio では ​`#[message]`​。 次の XML 例では、マップを値として取る変数を設定しています。 ​`` 次の例では、DataWeave スクリプトのセレクターを使用して、同じ変数を設定しています。この例では、​`name`​ 属性が Set Variable への入力として利用できることを前提としています。 ​`` これらの例では、変数をブール値 ​`true`​ に設定しています。 - Name (名前) = ​`myVar` - Value (値) = - Design Center では ​`true`​、Anypoint Studio では ​`#[true]` - Design Center では ​`true as Boolean`​、Anypoint Studio では ​`#[true as Boolean]` - `(1 + 1 == 2)`​ は Design Center では ​`true`​、​`#[(1 + 1 == 2)]`​ は Anypoint Studio では ​`true` Design Center で Logger コンポーネントを使用して変数の値を表示するには、​`vars.myVar`​ ではなく ​`#[vars.myVar]`​ のように Anypoint Studio の構文を使用する必要がある場合があります。 ## [](#他のイベントプロセッサーの変数へのアクセス)他のイベントプロセッサーの変数へのアクセス Set Variable は、現在の Mule イベントで変数を設定し、設定された変数は Mule イベントと一緒に下流のイベントプロセッサーに伝播されます。DataWeave では、​`vars`​ を使用することで任意の変数にアクセスできます。たとえば、lastMessage という名前の変数を設定してある場合は、​`vars.lastMessage`​ としてアクセスできます。 Transform Message コンポーネントでは変数を設定でき、多くのコネクタやイベントプロセッサーでは \[Advanced (詳細)\] タブで対象を設定できます。これらによってフロー変数を設定し、同じようにキーワードの ​`vars.`​ を使用してアクセスできます。 ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.3/target-variables) # Set Variable トランスフォーマー Set Variable (​`set-variable`​) コンポーネントは、Mule アプリケーションのフロー内で使用する値を格納するための ​[Mule 変数](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-variables)​を作成または更新します。Mule 変数は ​[Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-event)​の一部です。文字列やメッセージといったシンプルなリテラル値、メッセージペイロード、または属性オブジェクトを格納できます。たとえば、メッセージの元の (処理前の) ペイロードを格納しておくことで、後でフローやエラーハンドラーで使用できるようにします。 `set-variable`​ コンポーネントは、複雑な式や変換には向いていません。このコンポーネントは選択などのシンプルな処理に使用し、複雑なシナリオでは ​[Transform コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about)​を使用してください。 ## [](#参照)参照 Set Variable により、設定可能なプロパティと一緒に、Mule 変数の名前と値を設定できます。
項目 使用方法 説明

Variable Name (変数名) (​variableName​)

必須

変数の名前 (文字列である必要があります)。変数名には、数字、文字、およびアンダースコアのみを含めることができます。たとえば、名前にハイフンは使用できません。

Value (値) (​value​)

必須

変数の値で、文字列または DataWeave 式を指定できます。式を使用する例については、Use Dynamic Writer Propertiesを参照してください。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

変数の MIME 型 (​text/plain​ や ​application/json​ など) を設定します。

Encoding (エンコード) (​encoding​)

省略可能

変数のエンコード (​ISO 10646/Unicode(UTF-8)​ など) を設定します。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、格納されている出力値にのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
## [](#例)例 次の例では、変数を文字列に設定しています。 - Name (名前) = ​`myVar` - Value (値) = ​`my first variable` 次の例は、​`5`​ の値を生成する DataWeave 操作を使用して変数を設定しています。 - Name (名前) = ​`myVar` - Value (値) = Anypoint Studio では ​`#[max([1,2,3] ++ [3,4,5])]`​。 次の例は、変数をメッセージペイロードに設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`payload`​、Anypoint Studio では ​`#[payload]`​。 次の例は、変数をメッセージ属性に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`attributes`​、Anypoint Studio では ​`#[attributes]`​。 次の例は、変数をメッセージ全体に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`message`​、Anypoint Studio では ​`#[message]`​。 次の XML 例では、マップを値として取る変数を設定しています。 ​`` 次の例では、DataWeave スクリプトのセレクターを使用して、同じ変数を設定しています。この例では、​`name`​ 属性が Set Variable への入力として利用できることを前提としています。 ​`` これらの例では、変数をブール値 ​`true`​ に設定しています。 - Name (名前) = ​`myVar` - Value (値) = - Design Center では ​`true`​、Anypoint Studio では ​`#[true]` - Design Center では ​`true as Boolean`​、Anypoint Studio では ​`#[true as Boolean]` - `(1 + 1 == 2)`​ は Design Center では ​`true`​、​`#[(1 + 1 == 2)]`​ は Anypoint Studio では ​`true`​。 次の例では、DataWeave スクリプトを使用して変数を Java オブジェクトに設定しています。このスクリプトは、Java 形式でオブジェクトを出力します。 ​``​。 Java データ形式の詳細は、​[Java 形式の例](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-java#format_examples)​ドキュメントを参照してください。 Design Center で Logger コンポーネントを使用して変数の値を表示するには、​`vars.myVar`​ ではなく ​`#[vars.myVar]`​ のように Anypoint Studio の構文を使用する必要がある場合があります。 ## [](#他のイベントプロセッサーの変数へのアクセス)他のイベントプロセッサーの変数へのアクセス Set Variable は、現在の Mule イベントで変数を設定し、設定された変数は Mule イベントと一緒に下流のイベントプロセッサーに伝播されます。DataWeave では、​`vars`​ を使用することで任意の変数にアクセスできます。たとえば、lastMessage という名前の変数を設定してある場合は、​`vars.lastMessage`​ としてアクセスできます。 Transform Message コンポーネントでは変数を設定でき、多くのコネクタやイベントプロセッサーでは \[Advanced (詳細)\] タブで対象を設定できます。これらによってフロー変数を設定し、同じようにキーワードの ​`vars.`​ を使用してアクセスできます。 ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.4/target-variables) # Set Variable トランスフォーマー Set Variable (​`set-variable`​) コンポーネントは、Mule アプリケーションのフロー内で使用する値を格納するための ​[Mule 変数](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-variables)​を作成または更新します。Mule 変数は ​[Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-event)​の一部です。文字列やメッセージといったシンプルなリテラル値、メッセージペイロード、または属性オブジェクトを格納できます。たとえば、メッセージの元の (処理前の) ペイロードを格納しておくことで、後でフローやエラーハンドラーで使用できるようにします。 `set-variable`​ コンポーネントは、複雑な式や変換には向いていません。このコンポーネントは選択などのシンプルな処理に使用し、複雑なシナリオでは ​[Transform コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about)​を使用してください。 ## [](#参照)参照 Set Variable により、設定可能なプロパティと一緒に、Mule 変数の名前と値を設定できます。
項目 使用方法 説明

Variable Name (変数名) (​variableName​)

必須

変数の名前 (文字列である必要があります)。変数名には、数字、文字、およびアンダースコアのみを含めることができます。たとえば、名前にハイフンは使用できません。

Value (値) (​value​)

必須

変数の値で、文字列または DataWeave 式を指定できます。式を使用する例については、Use Dynamic Writer Propertiesを参照してください。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

変数の MIME 型 (​text/plain​ や ​application/json​ など) を設定します。

Encoding (エンコード) (​encoding​)

省略可能

変数のエンコード (​ISO 10646/Unicode(UTF-8)​ など) を設定します。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、格納されている出力値にのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
## [](#例)例 次の例では、変数を文字列に設定しています。 - Name (名前) = ​`myVar` - Value (値) = ​`my first variable` 次の例は、​`5`​ の値を生成する DataWeave 操作を使用して変数を設定しています。 - Name (名前) = ​`myVar` - Value (値) = Anypoint Studio では ​`#[max([1,2,3] ++ [3,4,5])]` 次の例は、変数をメッセージペイロードに設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`payload`​、Anypoint Studio では ​`#[payload]` 次の例は、変数をメッセージ属性に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`attributes`​、Anypoint Studio では ​`#[attributes]` 次の例は、変数をメッセージ全体に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`message`​、Anypoint Studio では ​`#[message]` 次の XML 例では、マップを値として取る変数を設定しています。 ​`` 次の例では、DataWeave スクリプトのセレクターを使用して、同じ変数を設定しています。この例では、​`name`​ 属性が Set Variable への入力として利用できることを前提としています。 ​`` これらの例では、変数をブール値 ​`true`​ に設定しています。 - Name (名前) = ​`myVar` - Value (値) = - Design Center では ​`true`​、Anypoint Studio では ​`#[true]` - Design Center では ​`true as Boolean`​、Anypoint Studio では ​`#[true as Boolean]` - `(1 + 1 == 2)`​ は Design Center では ​`true`​、​`#[(1 + 1 == 2)]`​ は Anypoint Studio では ​`true`​。 次の例では、DataWeave スクリプトを使用して変数を Java オブジェクトに設定しています。このスクリプトは、Java 形式でオブジェクトを出力します。 ​``​。 Java データ形式の詳細は、​[Java 形式の例](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-java#format_examples)​ドキュメントを参照してください。 Design Center で Logger コンポーネントを使用して変数の値を表示するには、​`vars.myVar`​ ではなく ​`#[vars.myVar]`​ のように Anypoint Studio の構文を使用する必要がある場合があります。 ## [](#他のイベントプロセッサーの変数へのアクセス)他のイベントプロセッサーの変数へのアクセス Set Variable は、現在の Mule イベントで変数を設定し、設定された変数は Mule イベントと一緒に下流のイベントプロセッサーに伝播されます。DataWeave では、​`vars`​ を使用することで任意の変数にアクセスできます。たとえば、lastMessage という名前の変数を設定してある場合は、​`vars.lastMessage`​ としてアクセスできます。 Transform Message コンポーネントでは変数を設定でき、多くのコネクタやイベントプロセッサーでは \[Advanced (詳細)\] タブで対象を設定できます。これらによってフロー変数を設定し、同じようにキーワードの ​`vars.`​ を使用してアクセスできます。 ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.5/target-variables) # Set Variable トランスフォーマー Set Variable (​`set-variable`​) コンポーネントは、Mule アプリケーションのフロー内で使用する値を格納するための ​[Mule 変数](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-variables)​を作成または更新します。Mule 変数は ​[Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-event)​の一部です。文字列やメッセージといったシンプルなリテラル値、メッセージペイロード、または属性オブジェクトを格納できます。たとえば、メッセージの元の (処理前の) ペイロードを格納しておくことで、後でフローやエラーハンドラーで使用できるようにします。 `set-variable`​ コンポーネントは、複雑な式や変換には向いていません。このコンポーネントは選択などのシンプルな処理に使用し、複雑なシナリオでは ​[Transform コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about)​を使用してください。 ## [](#参照)参照 Set Variable により、設定可能なプロパティと一緒に、Mule 変数の名前と値を設定できます。
項目 使い方 説明

Variable Name (変数名) (​variableName​)

必須

変数の名前 (文字列である必要があります)。変数名には、数字、文字、およびアンダースコアのみを含めることができます。たとえば、名前にハイフンは使用できません。

Value (値) (​value​)

必須

変数の値で、文字列または DataWeave 式を指定できます。式を使用する例については、Use Dynamic Writer Propertiesを参照してください。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

変数の MIME 型 (​text/plain​ や ​application/json​ など) を設定します。

Encoding (エンコード) (​encoding​)

省略可能

変数のエンコード (​ISO 10646/Unicode(UTF-8)​ など) を設定します。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、格納されている出力値にのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
## [](#例)例 次の例では、変数を文字列に設定しています。 - Name (名前) = ​`myVar` - Value (値) = ​`my first variable` 次の例は、​`5`​ の値を生成する DataWeave 操作を使用して変数を設定しています。 - Name (名前) = ​`myVar` - Value (値) = Anypoint Studio では ​`#[max([1,2,3] ++ [3,4,5])]`​。 次の例は、変数をメッセージペイロードに設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`payload`​、Anypoint Studio では ​`#[payload]`​。 次の例は、変数をメッセージ属性に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`attributes`​、Anypoint Studio では ​`#[attributes]`​。 次の例は、変数をメッセージ全体に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`message`​、Anypoint Studio では ​`#[message]`​。 次の XML 例では、マップを値として取る変数を設定しています。 ​`` 次の例では、DataWeave スクリプトのセレクターを使用して、同じ変数を設定しています。この例では、​`name`​ 属性が Set Variable への入力として利用できることを前提としています。 ​`` これらの例では、変数をブール値 ​`true`​ に設定しています。 - Name (名前) = ​`myVar` - Value (値) = - Design Center では ​`true`​、Anypoint Studio では ​`#[true]` - Design Center では ​`true as Boolean`​、Anypoint Studio では ​`#[true as Boolean]` - `(1 + 1 == 2)`​ は Design Center では ​`true`​、​`#[(1 + 1 == 2)]`​ は Anypoint Studio では ​`true`​。 次の例では、DataWeave スクリプトを使用して変数を Java オブジェクトに設定しています。このスクリプトは、Java 形式でオブジェクトを出力します。 ​``​。 Java データ形式の詳細は、​[Java 形式の例](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-java#format_examples)​ドキュメントを参照してください。 Design Center で Logger コンポーネントを使用して変数の値を表示するには、​`vars.myVar`​ ではなく ​`#[vars.myVar]`​ のように Anypoint Studio の構文を使用する必要がある場合があります。 ## [](#他のイベントプロセッサーの変数へのアクセス)他のイベントプロセッサーの変数へのアクセス Set Variable は、現在の Mule イベントで変数を設定し、設定された変数は Mule イベントと一緒に下流のイベントプロセッサーに伝播されます。DataWeave では、​`vars`​ を使用することで任意の変数にアクセスできます。たとえば、lastMessage という名前の変数を設定してある場合は、​`vars.lastMessage`​ としてアクセスできます。 Transform Message コンポーネントでは変数を設定でき、多くのコネクタやイベントプロセッサーでは \[Advanced (詳細)\] タブで対象を設定できます。これらによってフロー変数を設定し、同じようにキーワードの ​`vars.`​ を使用してアクセスできます。 ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.6/target-variables) # Set Variable トランスフォーマー Set Variable (​`set-variable`​) コンポーネントは、Mule アプリケーションのフロー内で使用する値を格納するための ​[Mule 変数](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-variables)​を作成または更新します。Mule 変数は ​[Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-event)​の一部です。文字列やメッセージといったシンプルなリテラル値、メッセージペイロード、または属性オブジェクトを格納できます。たとえば、メッセージの元の (処理前の) ペイロードを格納しておくことで、後でフローやエラーハンドラーで使用できるようにします。 `set-variable`​ コンポーネントは、複雑な式や変換には向いていません。このコンポーネントは選択などのシンプルな処理に使用し、複雑なシナリオでは ​[Transform コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about)​を使用してください。 ## [](#参照)参照 Set Variable により、設定可能なプロパティと一緒に、Mule 変数の名前と値を設定できます。
項目 使用方法 説明

Variable Name (変数名) (​variableName​)

必須

変数の名前 (文字列である必要があります)。変数名には、数字、文字、およびアンダースコアのみを含めることができます。たとえば、名前にハイフンは使用できません。

Value (値) (​value​)

必須

変数の値で、文字列または DataWeave 式を指定できます。式を使用する例については、Use Dynamic Writer Properties を参照してください。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

変数の MIME 型 (​text/plain​ や ​application/json​ など) を設定します。

Encoding (エンコード) (​encoding​)

省略可能

変数のエンコード (​ISO 10646/Unicode(UTF-8)​ など) を設定します。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、格納されている出力値にのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
## [](#例)例 次の例では、変数を文字列に設定しています。 - Name (名前) = ​`myVar` - Value (値) = ​`my first variable` 次の例は、​`5`​ の値を生成する DataWeave 操作を使用して変数を設定しています。 - Name (名前) = ​`myVar` - Value (値) = Anypoint Studio では ​`#[max([1,2,3] ++ [3,4,5])]`​。 次の例は、変数をメッセージペイロードに設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`payload`​、Anypoint Studio では ​`#[payload]`​。 次の例は、変数をメッセージ属性に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`attributes`​、Anypoint Studio では ​`#[attributes]`​。 次の例は、変数をメッセージ全体に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`message`​、Anypoint Studio では ​`#[message]`​。 次の XML 例では、マップを値として取る変数を設定しています。 ​`` 次の例では、DataWeave スクリプトのセレクターを使用して、同じ変数を設定しています。この例では、​`name`​ 属性が Set Variable への入力として利用できることを前提としています。 ​`` これらの例では、変数をブール値 ​`true`​ に設定しています。 - Name (名前) = ​`myVar` - Value (値) = - Design Center では ​`true`​、Anypoint Studio では ​`#[true]` - Design Center では ​`true as Boolean`​、Anypoint Studio では ​`#[true as Boolean]` - `(1 + 1 == 2)`​ は Design Center では ​`true`​、​`#[(1 + 1 == 2)]`​ は Anypoint Studio では ​`true`​。 次の例では、DataWeave スクリプトを使用して変数を Java オブジェクトに設定しています。このスクリプトは、Java 形式でオブジェクトを出力します。 ​``​。 Java データ形式の詳細は、​[Java 形式の例](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-java#format_examples)​ドキュメントを参照してください。 Design Center で Logger コンポーネントを使用して変数の値を表示するには、​`vars.myVar`​ ではなく ​`#[vars.myVar]`​ のように Anypoint Studio の構文を使用する必要がある場合があります。 ## [](#他のイベントプロセッサーの変数へのアクセス)他のイベントプロセッサーの変数へのアクセス Set Variable は、現在の Mule イベントで変数を設定し、設定された変数は Mule イベントと一緒に下流のイベントプロセッサーに伝播されます。DataWeave では、​`vars`​ を使用することで任意の変数にアクセスできます。たとえば、lastMessage という名前の変数を設定してある場合は、​`vars.lastMessage`​ としてアクセスできます。 Transform Message コンポーネントでは変数を設定でき、多くのコネクタやイベントプロセッサーでは \[Advanced (詳細)\] タブで対象を設定できます。これらによってフロー変数を設定し、同じようにキーワードの ​`vars.`​ を使用してアクセスできます。 ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.7/target-variables) # Set Variable トランスフォーマー Set Variable (​`set-variable`​) コンポーネントは、Mule アプリケーションのフロー内で使用する値を格納するための ​[Mule 変数](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-variables)​を作成または更新します。Mule 変数は ​[Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-event)​の一部です。文字列やメッセージといったシンプルなリテラル値、メッセージペイロード、または属性オブジェクトを格納できます。たとえば、メッセージの元の (処理前の) ペイロードを格納しておくことで、後でフローやエラーハンドラーで使用できるようにします。 `set-variable`​ コンポーネントは、複雑な式や変換には向いていません。このコンポーネントは選択などのシンプルな処理に使用し、複雑なシナリオでは ​[Transform コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about)​を使用してください。 ## [](#参照)参照 Set Variable により、設定可能なプロパティと一緒に、Mule 変数の名前と値を設定できます。
項目 使用方法 説明

Variable Name (変数名) (​variableName​)

必須

変数の名前 (文字列である必要があります)。変数名には、数字、文字、およびアンダースコアのみを含めることができます。たとえば、名前にハイフンは使用できません。

Value (値) (​value​)

必須

変数の値で、文字列または DataWeave 式を指定できます。式を使用する例については、Use Dynamic Writer Properties を参照してください。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

変数の MIME 型 (​text/plain​ や ​application/json​ など) を設定します。

Encoding (エンコード) (​encoding​)

省略可能

変数のエンコード (​ISO 10646/Unicode(UTF-8)​ など) を設定します。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、格納されている出力値にのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
## [](#例)例 次の例では、変数を文字列に設定しています。 - Name (名前) = ​`myVar` - Value (値) = ​`my first variable` 次の例は、​`5`​ の値を生成する DataWeave 操作を使用して変数を設定しています。 - Name (名前) = ​`myVar` - Value (値) = Anypoint Studio では ​`#[max([1,2,3] ++ [3,4,5])]`​。 次の例は、変数をメッセージペイロードに設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`payload`​、Anypoint Studio では ​`#[payload]`​。 次の例は、変数をメッセージ属性に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`attributes`​、Anypoint Studio では ​`#[attributes]`​。 次の例は、変数をメッセージ全体に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`message`​、Anypoint Studio では ​`#[message]`​。 次の XML 例では、マップを値として取る変数を設定しています。 ​`` 次の例では、DataWeave スクリプトのセレクターを使用して、同じ変数を設定しています。この例では、​`name`​ 属性が Set Variable への入力として利用できることを前提としています。 ​`` これらの例では、変数をブール値 ​`true`​ に設定しています。 - Name (名前) = ​`myVar` - Value (値) = - Design Center では ​`true`​、Anypoint Studio では ​`#[true]` - Design Center では ​`true as Boolean`​、Anypoint Studio では ​`#[true as Boolean]` - `(1 + 1 == 2)`​ は Design Center では ​`true`​、​`#[(1 + 1 == 2)]`​ は Anypoint Studio では ​`true`​。 次の例では、DataWeave スクリプトを使用して変数を Java オブジェクトに設定しています。このスクリプトは、Java 形式でオブジェクトを出力します。 ​``​。 Java データ形式の詳細は、​[Java 形式の例](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-java#format_examples)​ドキュメントを参照してください。 Design Center で Logger コンポーネントを使用して変数の値を表示するには、​`vars.myVar`​ ではなく ​`#[vars.myVar]`​ のように Anypoint Studio の構文を使用する必要がある場合があります。 ## [](#他のイベントプロセッサーの変数へのアクセス)他のイベントプロセッサーの変数へのアクセス Set Variable は、現在の Mule イベントで変数を設定し、設定された変数は Mule イベントと一緒に下流のイベントプロセッサーに伝播されます。DataWeave では、​`vars`​ を使用することで任意の変数にアクセスできます。たとえば、lastMessage という名前の変数を設定してある場合は、​`vars.lastMessage`​ としてアクセスできます。 Transform Message コンポーネントでは変数を設定でき、多くのコネクタやイベントプロセッサーでは \[Advanced (詳細)\] タブで対象を設定できます。これらによってフロー変数を設定し、同じようにキーワードの ​`vars.`​ を使用してアクセスできます。 ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.8/target-variables) # Set Variable トランスフォーマー Set Variable (​`set-variable`​) コンポーネントは、Mule アプリケーションのフロー内で使用する値を格納するための ​[Mule 変数](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-variables)​を作成または更新します。Mule 変数は ​[Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-event)​の一部です。文字列やメッセージといったシンプルなリテラル値、メッセージペイロード、または属性オブジェクトを格納できます。たとえば、メッセージの元の (処理前の) ペイロードを格納しておくことで、後でフローやエラーハンドラーで使用できるようにします。 `set-variable`​ コンポーネントは、複雑な式や変換には向いていません。このコンポーネントは選択などのシンプルな処理に使用し、複雑なシナリオでは ​[Transform コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about)​を使用してください。 ## [](#参照)参照 Set Variable により、設定可能なプロパティと一緒に、Mule 変数の名前と値を設定できます。
項目 使用方法 説明

Variable Name (変数名) (​variableName​)

必須

変数の名前 (文字列である必要があります)。変数名には、数字、文字、およびアンダースコアのみを含めることができます。たとえば、名前にハイフンは使用できません。

Value (値) (​value​)

必須

変数の値で、文字列または DataWeave 式を指定できます。式を使用する例については、Use Dynamic Writer Properties を参照してください。

Mime Type (MIME タイプ) (​mimeType​)

省略可能

変数の MIME 型 (​text/plain​ や ​application/json​ など) を設定します。

Encoding (エンコード) (​encoding​)

省略可能

変数のエンコード (​ISO 10646/Unicode(UTF-8)​ など) を設定します。

mimeType​ 属性と ​encoding​ 属性は、​value​ に指定された DataWeave 式には影響しません。これらは、格納されている出力値にのみ影響します。変換が必要な場合には、DataWeave 式に明示的な出力ディレクティブを指定する必要があります。
## [](#例)例 次の例では、変数を文字列に設定しています。 - Name (名前) = ​`myVar` - Value (値) = ​`my first variable` 次の例は、​`5`​ の値を生成する DataWeave 操作を使用して変数を設定しています。 - Name (名前) = ​`myVar` - Value (値) = Anypoint Studio では ​`#[max([1,2,3] ++ [3,4,5])]`​。 次の例は、変数をメッセージペイロードに設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`payload`​、Anypoint Studio では ​`#[payload]`​。 次の例は、変数をメッセージ属性に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`attributes`​、Anypoint Studio では ​`#[attributes]`​。 次の例は、変数をメッセージ全体に設定しています。 - Name (名前) = ​`myVar` - Value (値) = Design Center では ​`message`​、Anypoint Studio では ​`#[message]`​。 次の XML 例では、マップを値として取る変数を設定しています。 ​`` 次の例では、DataWeave スクリプトのセレクターを使用して、同じ変数を設定しています。この例では、​`name`​ 属性が Set Variable への入力として利用できることを前提としています。 ​`` これらの例では、変数をブール値 ​`true`​ に設定しています。 - Name (名前) = ​`myVar` - Value (値) = - Design Center では ​`true`​、Anypoint Studio では ​`#[true]` - Design Center では ​`true as Boolean`​、Anypoint Studio では ​`#[true as Boolean]` - `(1 + 1 == 2)`​ は Design Center では ​`true`​、​`#[(1 + 1 == 2)]`​ は Anypoint Studio では ​`true`​。 次の例では、DataWeave スクリプトを使用して変数を Java オブジェクトに設定しています。このスクリプトは、Java 形式でオブジェクトを出力します。 ​``​。 Java データ形式の詳細は、​[Java 形式の例](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-java#format_examples)​ドキュメントを参照してください。 Design Center で Logger コンポーネントを使用して変数の値を表示するには、​`vars.myVar`​ ではなく ​`#[vars.myVar]`​ のように Anypoint Studio の構文を使用する必要がある場合があります。 ## [](#他のイベントプロセッサーの変数へのアクセス)他のイベントプロセッサーの変数へのアクセス Set Variable は、現在の Mule イベントで変数を設定し、設定された変数は Mule イベントと一緒に下流のイベントプロセッサーに伝播されます。DataWeave では、​`vars`​ を使用することで任意の変数にアクセスできます。たとえば、lastMessage という名前の変数を設定してある場合は、​`vars.lastMessage`​ としてアクセスできます。 Transform Message コンポーネントでは変数を設定でき、多くのコネクタやイベントプロセッサーでは \[Advanced (詳細)\] タブで対象を設定できます。これらによってフロー変数を設定し、同じようにキーワードの ​`vars.`​ を使用してアクセスできます。 ## [](#関連情報)関連情報 - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-variables) - [対象変数を使用したデータの強化](https://docs.mulesoft.com/jp/mule-runtime/4.9/target-variables) # Spring Module の移行 Mule 3 では、Spring DSL を直接使用して、Mule アプリケーションの一部として Spring bean を定義できました。このアプローチでは、ランタイムの内部で使用される Spring バージョンおよびコンポーネントに、Mule アプリケーションを公開する必要があります。これにより 2 つの問題が発生します。 - ユーザーは Mule Runtime で使用できる Spring バージョンおよびモジュールに制限されていた。 - ランタイムでの変更またはアップグレードが、定義するアプリケーションに影響する可能性がある。 Mule 4 でこの問題を修正するために、Spring のサポートを別個のモジュールとしてパッケージすることにしました。したがって、Spring bean をアプリケーション上で直接定義する代わりに、独自のファイルで定義し、Spring Module を使用してそれらを参照する必要があります。 Mule 3 の例: ```xml ... ``` Mule 4 の例: ```xml ... ```
XML ファイルの例や設定手順の詳細は、​「Spring Module」​を参照してください。
## [](#mule-4-での-spring-module-連動関係の設定)Mule 4 での Spring Module 連動関係の設定 Spring Module には Spring 連動関係は含まれませんので、連動関係を使用する場合は設定が必要です。 Mule Connector 連動関係は相互に、そして Mule アプリケーションの連動関係から分離されているため、設定した Spring 連動関係を Spring Module で使用するためには、設定後に共有ライブラリとして宣言する必要があります。 Spring 連動関係を設定して共有ライブラリとして宣言するには、アプリケーションの ​`pom.xml`​ に以下を追加します。 ```xml 4.3.17.RELEASE 4.2.6.RELEASE 3.4.0 org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.springframework.security spring-security-core org.springframework spring-beans org.springframework spring-context org.springframework spring-core org.springframework.security spring-security-config org.springframework.security spring-security-core ${springSecurityVersion} org.springframework spring-beans ${springVersion} org.springframework spring-context ${springVersion} org.springframework spring-core ${springVersion} org.springframework.security spring-security-config ${springSecurityVersion} ``` ## [](#spring-module-を-mule-4-プロジェクトに追加します)Spring Module を Mule 4 プロジェクトに追加します。 Spring Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-spring-module 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Mule 4 の Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Mule 4 での共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept#configure-shared-libraries) - [Mule 4 でのクラスローディングの分離](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-classloading-isolation) # Spring Module の移行 Mule 3 では、Spring DSL を直接使用して、Mule アプリケーションの一部として Spring bean を定義できました。このアプローチでは、ランタイムの内部で使用される Spring バージョンおよびコンポーネントに、Mule アプリケーションを公開する必要があります。これにより 2 つの問題が発生します。 - ユーザーは Mule Runtime で使用できる Spring バージョンおよびモジュールに制限されていた。 - ランタイムでの変更またはアップグレードが、定義するアプリケーションに影響する可能性がある。 Mule 4 でこの問題を修正するために、Spring のサポートを別個のモジュールとしてパッケージすることにしました。したがって、Spring bean をアプリケーション上で直接定義する代わりに、独自のファイルで定義し、Spring Module を使用してそれらを参照する必要があります。 Mule 3 の例: ```xml ... ``` Mule 4 の例: ```xml ... ```
XML ファイルの例や設定手順の詳細は、​「Spring Module」​を参照してください。
## [](#mule-4-での-spring-module-連動関係の設定)Mule 4 での Spring Module 連動関係の設定 Spring Module には Spring 連動関係は含まれませんので、連動関係を使用する場合は設定が必要です。 Mule Connector 連動関係は相互に、そして Mule アプリケーションの連動関係から分離されているため、設定した Spring 連動関係を Spring Module で使用するためには、設定後に共有ライブラリとして宣言する必要があります。 Spring 連動関係を設定して共有ライブラリとして宣言するには、アプリケーションの ​`pom.xml`​ に以下を追加します。 ```xml 4.3.17.RELEASE 4.2.6.RELEASE 3.4.0 org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.springframework.security spring-security-core org.springframework spring-beans org.springframework spring-context org.springframework spring-core org.springframework.security spring-security-config org.springframework.security spring-security-core ${springSecurityVersion} org.springframework spring-beans ${springVersion} org.springframework spring-context ${springVersion} org.springframework spring-core ${springVersion} org.springframework.security spring-security-config ${springSecurityVersion} ``` ## [](#spring-module-を-mule-4-プロジェクトに追加します)Spring Module を Mule 4 プロジェクトに追加します。 Spring Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-spring-module 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Mule 4 の Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Mule 4 での共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept#configure-shared-libraries) - [Mule 4 でのクラスローディングの分離](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-classloading-isolation) # Spring Module の移行 Mule 3 では、Spring DSL を直接使用して、Mule アプリケーションの一部として Spring bean を定義できました。このアプローチでは、ランタイムの内部で使用される Spring バージョンおよびコンポーネントに、Mule アプリケーションを公開する必要があります。これにより 2 つの問題が発生します。 - ユーザーは Mule Runtime で使用できる Spring バージョンおよびモジュールに制限されていた。 - ランタイムでの変更またはアップグレードが、定義するアプリケーションに影響する可能性がある。 Mule 4 でこの問題を修正するために、Spring のサポートを別個のモジュールとしてパッケージすることにしました。したがって、Spring bean をアプリケーション上で直接定義する代わりに、独自のファイルで定義し、Spring Module を使用してそれらを参照する必要があります。 Mule 3 の例: ```xml ... ``` Mule 4 の例: ```xml ... ```
XML ファイルの例や設定手順の詳細は、​「Spring Module」​を参照してください。
## [](#mule-4-での-spring-module-連動関係の設定)Mule 4 での Spring Module 連動関係の設定 Spring Module には Spring 連動関係は含まれませんので、連動関係を使用する場合は設定が必要です。 Mule Connector 連動関係は相互に、そして Mule アプリケーションの連動関係から分離されているため、設定した Spring 連動関係を Spring Module で使用するためには、設定後に共有ライブラリとして宣言する必要があります。 Spring 連動関係を設定して共有ライブラリとして宣言するには、アプリケーションの ​`pom.xml`​ に以下を追加します。 ```xml 4.3.17.RELEASE 4.2.6.RELEASE 3.4.0 org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.springframework.security spring-security-core org.springframework spring-beans org.springframework spring-context org.springframework spring-core org.springframework.security spring-security-config org.springframework.security spring-security-core ${springSecurityVersion} org.springframework spring-beans ${springVersion} org.springframework spring-context ${springVersion} org.springframework spring-core ${springVersion} org.springframework.security spring-security-config ${springSecurityVersion} ``` ## [](#spring-module-を-mule-4-プロジェクトに追加します)Spring Module を Mule 4 プロジェクトに追加します。 Spring Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-spring-module 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Mule 4 の Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Mule 4 での共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept#configure-shared-libraries) - [Mule 4 でのクラスローディングの分離](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-classloading-isolation) # Spring Module の移行 Mule 3 では、Spring DSL を直接使用して、Mule アプリケーションの一部として Spring bean を定義できました。このアプローチでは、ランタイムの内部で使用される Spring バージョンおよびコンポーネントに、Mule アプリケーションを公開する必要があります。これにより 2 つの問題が発生します。 - ユーザーは Mule Runtime で使用できる Spring バージョンおよびモジュールに制限されていた。 - ランタイムでの変更またはアップグレードが、定義するアプリケーションに影響する可能性がある。 Mule 4 でこの問題を修正するために、Spring のサポートを別個のモジュールとしてパッケージすることにしました。したがって、Spring bean をアプリケーション上で直接定義する代わりに、独自のファイルで定義し、Spring Module を使用してそれらを参照する必要があります。 Mule 3 の例: ```xml ... ``` Mule 4 の例: ```xml ... ```
XML ファイルの例や設定手順の詳細は、​「Spring Module」​を参照してください。
## [](#mule-4-での-spring-module-連動関係の設定)Mule 4 での Spring Module 連動関係の設定 Spring Module には Spring 連動関係は含まれませんので、連動関係を使用する場合は設定が必要です。 Mule Connector 連動関係は相互に、そして Mule アプリケーションの連動関係から分離されているため、設定した Spring 連動関係を Spring Module で使用するためには、設定後に共有ライブラリとして宣言する必要があります。 Spring 連動関係を設定して共有ライブラリとして宣言するには、アプリケーションの ​`pom.xml`​ に以下を追加します。 ```xml 4.3.17.RELEASE 4.2.6.RELEASE 3.4.0 org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.springframework.security spring-security-core org.springframework spring-beans org.springframework spring-context org.springframework spring-core org.springframework.security spring-security-config org.springframework.security spring-security-core ${springSecurityVersion} org.springframework spring-beans ${springVersion} org.springframework spring-context ${springVersion} org.springframework spring-core ${springVersion} org.springframework.security spring-security-config ${springSecurityVersion} ``` ## [](#spring-module-を-mule-4-プロジェクトに追加します)Spring Module を Mule 4 プロジェクトに追加します。 Spring Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-spring-module 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Mule 4 の Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Mule 4 での共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept#configure-shared-libraries) - [Mule 4 でのクラスローディングの分離](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-classloading-isolation) # Spring Module の移行 Mule 3 では、Spring DSL を直接使用して、Mule アプリケーションの一部として Spring bean を定義できました。このアプローチでは、ランタイムの内部で使用される Spring バージョンおよびコンポーネントに、Mule アプリケーションを公開する必要があります。これにより 2 つの問題が発生します。 - ユーザーは Mule Runtime で使用できる Spring バージョンおよびモジュールに制限されていた。 - ランタイムでの変更またはアップグレードが、定義するアプリケーションに影響する可能性がある。 Mule 4 でこの問題を修正するために、Spring のサポートを別個のモジュールとしてパッケージすることにしました。したがって、Spring bean をアプリケーション上で直接定義する代わりに、独自のファイルで定義し、Spring Module を使用してそれらを参照する必要があります。 Mule 3 の例: ```xml ... ``` Mule 4 の例: ```xml ... ```
XML ファイルの例や設定手順の詳細は、​「Spring Module」​を参照してください。
## [](#mule-4-での-spring-module-連動関係の設定)Mule 4 での Spring Module 連動関係の設定 Spring Module には Spring 連動関係は含まれませんので、連動関係を使用する場合は設定が必要です。 Mule Connector 連動関係は相互に、そして Mule アプリケーションの連動関係から分離されているため、設定した Spring 連動関係を Spring Module で使用するためには、設定後に共有ライブラリとして宣言する必要があります。 Spring 連動関係を設定して共有ライブラリとして宣言するには、アプリケーションの ​`pom.xml`​ に以下を追加します。 ```xml 4.3.17.RELEASE 4.2.6.RELEASE 3.4.0 org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.springframework.security spring-security-core org.springframework spring-beans org.springframework spring-context org.springframework spring-core org.springframework.security spring-security-config org.springframework.security spring-security-core ${springSecurityVersion} org.springframework spring-beans ${springVersion} org.springframework spring-context ${springVersion} org.springframework spring-core ${springVersion} org.springframework.security spring-security-config ${springSecurityVersion} ``` ## [](#spring-module-を-mule-4-プロジェクトに追加します)Spring Module を Mule 4 プロジェクトに追加します。 Spring Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-spring-module 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Mule 4 の Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Mule 4 での共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept#configure-shared-libraries) - [Mule 4 でのクラスローディングの分離](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-classloading-isolation) # Spring Module の移行 Mule 3 では、Spring DSL を直接使用して、Mule アプリケーションの一部として Spring bean を定義できました。このアプローチでは、ランタイムの内部で使用される Spring バージョンおよびコンポーネントに、Mule アプリケーションを公開する必要があります。これにより 2 つの問題が発生します。 - ユーザーは Mule Runtime で使用できる Spring バージョンおよびモジュールに制限されていた。 - ランタイムでの変更またはアップグレードが、定義するアプリケーションに影響する可能性がある。 Mule 4 でこの問題を修正するために、Spring のサポートを別個のモジュールとしてパッケージすることにしました。したがって、Spring bean をアプリケーション上で直接定義する代わりに、独自のファイルで定義し、Spring Module を使用してそれらを参照する必要があります。 Mule 3 の例: ```xml ... ``` Mule 4 の例: ```xml ... ```
XML ファイルの例や設定手順の詳細は、​「Spring Module」​を参照してください。
## [](#mule-4-での-spring-module-連動関係の設定)Mule 4 での Spring Module 連動関係の設定 Spring Module には Spring 連動関係は含まれませんので、連動関係を使用する場合は設定が必要です。 Mule Connector 連動関係は相互に、そして Mule アプリケーションの連動関係から分離されているため、設定した Spring 連動関係を Spring Module で使用するためには、設定後に共有ライブラリとして宣言する必要があります。 Spring 連動関係を設定して共有ライブラリとして宣言するには、アプリケーションの ​`pom.xml`​ に以下を追加します。 ```xml 4.3.17.RELEASE 4.2.6.RELEASE 3.4.0 org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.springframework.security spring-security-core org.springframework spring-beans org.springframework spring-context org.springframework spring-core org.springframework.security spring-security-config org.springframework.security spring-security-core ${springSecurityVersion} org.springframework spring-beans ${springVersion} org.springframework spring-context ${springVersion} org.springframework spring-core ${springVersion} org.springframework.security spring-security-config ${springSecurityVersion} ``` ## [](#spring-module-を-mule-4-プロジェクトに追加します)Spring Module を Mule 4 プロジェクトに追加します。 Spring Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-spring-module 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Mule 4 の Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Mule 4 での共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept#configure-shared-libraries) - [Mule 4 でのクラスローディングの分離](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-classloading-isolation) # Spring Module の移行 Mule 3 では、Spring DSL を直接使用して、Mule アプリケーションの一部として Spring bean を定義できました。このアプローチでは、ランタイムの内部で使用される Spring バージョンおよびコンポーネントに、Mule アプリケーションを公開する必要があります。これにより 2 つの問題が発生します。 - ユーザーは Mule Runtime で使用できる Spring バージョンおよびモジュールに制限されていた。 - ランタイムでの変更またはアップグレードが、定義するアプリケーションに影響する可能性がある。 Mule 4 でこの問題を修正するために、Spring のサポートを別個のモジュールとしてパッケージすることにしました。したがって、Spring bean をアプリケーション上で直接定義する代わりに、独自のファイルで定義し、Spring Module を使用してそれらを参照する必要があります。 Mule 3 の例: ```xml ... ``` Mule 4 の例: ```xml ... ```
XML ファイルの例や設定手順の詳細は、​「Spring Module」​を参照してください。
## [](#mule-4-での-spring-module-連動関係の設定)Mule 4 での Spring Module 連動関係の設定 Spring Module には Spring 連動関係は含まれませんので、連動関係を使用する場合は設定が必要です。 Mule Connector 連動関係は相互に、そして Mule アプリケーションの連動関係から分離されているため、設定した Spring 連動関係を Spring Module で使用するためには、設定後に共有ライブラリとして宣言する必要があります。 Spring 連動関係を設定して共有ライブラリとして宣言するには、アプリケーションの ​`pom.xml`​ に以下を追加します。 ```xml 4.3.17.RELEASE 4.2.6.RELEASE 3.4.0 org.mule.tools.maven mule-maven-plugin ${mule.maven.plugin.version} org.springframework.security spring-security-core org.springframework spring-beans org.springframework spring-context org.springframework spring-core org.springframework.security spring-security-config org.springframework.security spring-security-core ${springSecurityVersion} org.springframework spring-beans ${springVersion} org.springframework spring-context ${springVersion} org.springframework spring-core ${springVersion} org.springframework.security spring-security-config ${springSecurityVersion} ``` ## [](#spring-module-を-mule-4-プロジェクトに追加します)Spring Module を Mule 4 プロジェクトに追加します。 Spring Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-spring-module 1.2.0 mule-plugin ``` ## [](#関連情報)関連情報 - [Mule 4 の Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Mule 4 での共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept#configure-shared-libraries) - [Mule 4 でのクラスローディングの分離](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-classloading-isolation) # Spring セキュリティの LDAP プロバイダーの設定 Mule 4 では、Spring セキュリティ LDAP プロバイダーを使用して、コンポーネントの認証を実行するか、または Spring Module 経由で Mule セキュリティプロバイダーとして使用できます。LDAP プロバイダーを設定する前に Spring JAR ファイルを入手して Spring Bean を宣言してください。 ## [](#jar-ファイルの入手)JAR ファイルの入手 Mule ソフトウェアディストリビューションの ​`/lib/opt`​ ディレクトリに、必要な Spring JAR ファイルが入っています。 - `spring-ldap-core-2.3.2.RELEASE.jar` - `spring-security-config-4.2.6.RELEASE.jar` - `spring-security-core-4.2.6.RELEASE.jar` - `spring-security-ldap-4.2.6.RELEASE.jar` - `spring-security-web-4.2.6.RELEASE.jar` ## [](#spring-bean-の宣言)Spring Bean の宣言 [DefaultSpringSecurityContextSource](https://docs.spring.io/spring-security/site/docs/4.0.x/apidocs/org/springframework/security/ldap/DefaultSpringSecurityContextSource.html)​ クラスが LDAP コンテキストを取得するためのアクセスポイントとなります。 `DefaultSpringSecurityContextSource`​ の Spring Bean は、resources フォルダーの個別の ​`beans.xml`​ ファイルで宣言する必要があります。 たとえば、ユーザーを検索して認証するために、Spring セキュリティ認証プロバイダーで使用する LDAP コンテキストソースをセットアップする必要があります。また、次のコードサンプルに示すように、​`ldap-authentication-provider`​ クラスが埋め込まれた ​`authentication-manager`​ インターフェースを定義する必要もあります。 ```xml ``` ## [](#mule-セキュリティプロバイダーの設定)Mule セキュリティプロバイダーの設定 `SpringSecurityProviderAdapter`​ は、​`LdapAuthenticationProvider`​ のような ​`AuthenticationProvider`​ に認証プロセスを委任します。Mule セキュリティプロバイダーを設定するには、1 つ以上のセキュリティプロバイダーを必要とする Mule のコネクタレベルのセキュリティや他のセキュリティ機能の設定方法を示した次の例を参考にしてください。 ```xml ``` 次の設定例では、基本 HTTP セキュリティ検索条件を参照しています。 ```xml ``` ## [](#コンポーネント認証の設定)コンポーネント認証の設定 コンポーネント認証を設定するには、​`authorization-filter`​ 項目を次のように宣言します。 ```xml ``` ## [](#関連情報)関連情報 - [Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.3/component-authorization-using-spring-security) - [LDAP Spring セキュリティ](https://docs.spring.io/spring-security/site/docs/3.1.x/reference/ldap.html) - [Spring セキュリティリファレンス](https://docs.spring.io/spring-security/site/docs/4.0.1.RELEASE/reference/html/) # Spring セキュリティの LDAP プロバイダーの設定 Mule 4 では、Spring セキュリティ LDAP プロバイダーを使用して、コンポーネントの認証を実行するか、または Spring Module 経由で Mule セキュリティプロバイダーとして使用できます。LDAP プロバイダーを設定する前に Spring JAR ファイルを入手して Spring Bean を宣言してください。 ## [](#jar-ファイルの入手)JAR ファイルの入手 Mule ソフトウェアディストリビューションの ​`/lib/opt`​ ディレクトリに、必要な Spring JAR ファイルが入っています。 - `spring-ldap-core-2.3.2.RELEASE.jar` - `spring-security-config-4.2.6.RELEASE.jar` - `spring-security-core-4.2.6.RELEASE.jar` - `spring-security-ldap-4.2.6.RELEASE.jar` - `spring-security-web-4.2.6.RELEASE.jar` ## [](#spring-bean-の宣言)Spring Bean の宣言 [DefaultSpringSecurityContextSource](https://docs.spring.io/spring-security/site/docs/4.0.x/apidocs/org/springframework/security/ldap/DefaultSpringSecurityContextSource.html)​ クラスが LDAP コンテキストを取得するためのアクセスポイントとなります。 `DefaultSpringSecurityContextSource`​ の Spring Bean は、resources フォルダーの個別の ​`beans.xml`​ ファイルで宣言する必要があります。 たとえば、ユーザーを検索して認証するために、Spring セキュリティ認証プロバイダーで使用する LDAP コンテキストソースをセットアップする必要があります。また、次のコードサンプルに示すように、​`ldap-authentication-provider`​ クラスが埋め込まれた ​`authentication-manager`​ インターフェースを定義する必要もあります。 ```xml ``` ## [](#mule-セキュリティプロバイダーの設定)Mule セキュリティプロバイダーの設定 `SpringSecurityProviderAdapter`​ は、​`LdapAuthenticationProvider`​ のような ​`AuthenticationProvider`​ に認証プロセスを委任します。Mule セキュリティプロバイダーを設定するには、1 つ以上のセキュリティプロバイダーを必要とする Mule のコネクタレベルのセキュリティや他のセキュリティ機能の設定方法を示した次の例を参考にしてください。 ```xml ``` 次の設定例では、基本 HTTP セキュリティ検索条件を参照しています。 ```xml ``` ## [](#コンポーネント認証の設定)コンポーネント認証の設定 コンポーネント認証を設定するには、​`authorization-filter`​ 項目を次のように宣言します。 ```xml ``` ## [](#関連情報)関連情報 - [Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.4/component-authorization-using-spring-security) - [LDAP Spring セキュリティ](https://docs.spring.io/spring-security/site/docs/3.1.x/reference/ldap.html) - [Spring セキュリティリファレンス](https://docs.spring.io/spring-security/site/docs/4.0.1.RELEASE/reference/html/) # Spring セキュリティの LDAP プロバイダーの設定 Mule 4 では、Spring セキュリティ LDAP プロバイダーを使用して、コンポーネントの認証を実行するか、または Spring Module 経由で Mule セキュリティプロバイダーとして使用できます。LDAP プロバイダーを設定する前に Spring JAR ファイルを入手して Spring Bean を宣言してください。 ## [](#jar-ファイルの入手)JAR ファイルの入手 Mule ソフトウェアディストリビューションの ​`/lib/opt`​ ディレクトリに、必要な Spring JAR ファイルが入っています。 - `spring-ldap-core-2.3.2.RELEASE.jar` - `spring-security-config-4.2.6.RELEASE.jar` - `spring-security-core-4.2.6.RELEASE.jar` - `spring-security-ldap-4.2.6.RELEASE.jar` - `spring-security-web-4.2.6.RELEASE.jar` ## [](#spring-bean-の宣言)Spring Bean の宣言 [DefaultSpringSecurityContextSource](https://docs.spring.io/spring-security/site/docs/4.0.x/apidocs/org/springframework/security/ldap/DefaultSpringSecurityContextSource.html)​ クラスが LDAP コンテキストを取得するためのアクセスポイントとなります。 `DefaultSpringSecurityContextSource`​ の Spring Bean は、resources フォルダーの個別の ​`beans.xml`​ ファイルで宣言する必要があります。 たとえば、ユーザーを検索して認証するために、Spring セキュリティ認証プロバイダーで使用する LDAP コンテキストソースをセットアップする必要があります。また、次のコードサンプルに示すように、​`ldap-authentication-provider`​ クラスが埋め込まれた ​`authentication-manager`​ インターフェースを定義する必要もあります。 ```xml ``` ## [](#mule-セキュリティプロバイダーの設定)Mule セキュリティプロバイダーの設定 `SpringSecurityProviderAdapter`​ は、​`LdapAuthenticationProvider`​ のような ​`AuthenticationProvider`​ に認証プロセスを委任します。Mule セキュリティプロバイダーを設定するには、1 つ以上のセキュリティプロバイダーを必要とする Mule のコネクタレベルのセキュリティや他のセキュリティ機能の設定方法を示した次の例を参考にしてください。 ```xml ``` 次の設定例では、基本 HTTP セキュリティ検索条件を参照しています。 ```xml ``` ## [](#コンポーネント認証の設定)コンポーネント認証の設定 コンポーネント認証を設定するには、​`authorization-filter`​ 項目を次のように宣言します。 ```xml ``` ## [](#関連情報)関連情報 - [Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.5/component-authorization-using-spring-security) - [LDAP Spring セキュリティ](https://docs.spring.io/spring-security/site/docs/3.1.x/reference/ldap.html) - [Spring セキュリティリファレンス](https://docs.spring.io/spring-security/site/docs/4.0.1.RELEASE/reference/html/) # Spring セキュリティの LDAP プロバイダーの設定 Mule 4 では、Spring セキュリティ LDAP プロバイダーを使用して、コンポーネントの認証を実行するか、または Spring Module 経由で Mule セキュリティプロバイダーとして使用できます。LDAP プロバイダーを設定する前に Spring JAR ファイルを入手して Spring Bean を宣言してください。 ## [](#jar-ファイルの入手)JAR ファイルの入手 Mule ソフトウェアディストリビューションの ​`/lib/opt`​ ディレクトリに、必要な Spring JAR ファイルが入っています。 - `spring-ldap-core-2.3.2.RELEASE.jar` - `spring-security-config-4.2.6.RELEASE.jar` - `spring-security-core-4.2.6.RELEASE.jar` - `spring-security-ldap-4.2.6.RELEASE.jar` - `spring-security-web-4.2.6.RELEASE.jar` ## [](#spring-bean-の宣言)Spring Bean の宣言 [DefaultSpringSecurityContextSource](https://docs.spring.io/spring-security/site/docs/4.0.x/apidocs/org/springframework/security/ldap/DefaultSpringSecurityContextSource.html)​ クラスが LDAP コンテキストを取得するためのアクセスポイントとなります。 `DefaultSpringSecurityContextSource`​ の Spring Bean は、resources フォルダーの個別の ​`beans.xml`​ ファイルで宣言する必要があります。 たとえば、ユーザーを検索して認証するために、Spring セキュリティ認証プロバイダーで使用する LDAP コンテキストソースをセットアップする必要があります。また、次のコードサンプルに示すように、​`ldap-authentication-provider`​ クラスが埋め込まれた ​`authentication-manager`​ インターフェースを定義する必要もあります。 ```xml ``` ## [](#mule-セキュリティプロバイダーの設定)Mule セキュリティプロバイダーの設定 `SpringSecurityProviderAdapter`​ は、​`LdapAuthenticationProvider`​ のような ​`AuthenticationProvider`​ に認証プロセスを委任します。Mule セキュリティプロバイダーを設定するには、1 つ以上のセキュリティプロバイダーを必要とする Mule のコネクタレベルのセキュリティや他のセキュリティ機能の設定方法を示した次の例を参考にしてください。 ```xml ``` 次の設定例では、基本 HTTP セキュリティ検索条件を参照しています。 ```xml ``` ## [](#コンポーネント認証の設定)コンポーネント認証の設定 コンポーネント認証を設定するには、​`authorization-filter`​ 項目を次のように宣言します。 ```xml ``` ## [](#関連情報)関連情報 - [Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.6/component-authorization-using-spring-security) - [LDAP Spring セキュリティ](https://docs.spring.io/spring-security/site/docs/3.1.x/reference/ldap.html) - [Spring セキュリティリファレンス](https://docs.spring.io/spring-security/site/docs/4.0.1.RELEASE/reference/html/) # Spring セキュリティの LDAP プロバイダーの設定 Mule 4 では、Spring セキュリティ LDAP プロバイダーを使用して、コンポーネントの認証を実行するか、または Spring Module 経由で Mule セキュリティプロバイダーとして使用できます。LDAP プロバイダーを設定する前に Spring JAR ファイルを入手して Spring Bean を宣言してください。 ## [](#jar-ファイルの入手)JAR ファイルの入手 Mule ソフトウェアディストリビューションの ​`/lib/opt`​ ディレクトリに、必要な Spring JAR ファイルが入っています。 - `spring-ldap-core-2.3.2.RELEASE.jar` - `spring-security-config-4.2.6.RELEASE.jar` - `spring-security-core-4.2.6.RELEASE.jar` - `spring-security-ldap-4.2.6.RELEASE.jar` - `spring-security-web-4.2.6.RELEASE.jar` ## [](#spring-bean-の宣言)Spring Bean の宣言 [DefaultSpringSecurityContextSource](https://docs.spring.io/spring-security/site/docs/4.0.x/apidocs/org/springframework/security/ldap/DefaultSpringSecurityContextSource.html)​ クラスが LDAP コンテキストを取得するためのアクセスポイントとなります。 `DefaultSpringSecurityContextSource`​ の Spring Bean は、resources フォルダーの個別の ​`beans.xml`​ ファイルで宣言する必要があります。 たとえば、ユーザーを検索して認証するために、Spring セキュリティ認証プロバイダーで使用する LDAP コンテキストソースをセットアップする必要があります。また、次のコードサンプルに示すように、​`ldap-authentication-provider`​ クラスが埋め込まれた ​`authentication-manager`​ インターフェースを定義する必要もあります。 ```xml ``` ## [](#mule-セキュリティプロバイダーの設定)Mule セキュリティプロバイダーの設定 `SpringSecurityProviderAdapter`​ は、​`LdapAuthenticationProvider`​ のような ​`AuthenticationProvider`​ に認証プロセスを委任します。Mule セキュリティプロバイダーを設定するには、1 つ以上のセキュリティプロバイダーを必要とする Mule のコネクタレベルのセキュリティや他のセキュリティ機能の設定方法を示した次の例を参考にしてください。 ```xml ``` 次の設定例では、基本 HTTP セキュリティ検索条件を参照しています。 ```xml ``` ## [](#コンポーネント認証の設定)コンポーネント認証の設定 コンポーネント認証を設定するには、​`authorization-filter`​ 項目を次のように宣言します。 ```xml ``` ## [](#関連情報)関連情報 - [Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.7/component-authorization-using-spring-security) - [LDAP Spring セキュリティ](https://docs.spring.io/spring-security/site/docs/3.1.x/reference/ldap.html) - [Spring セキュリティリファレンス](https://docs.spring.io/spring-security/site/docs/4.0.1.RELEASE/reference/html/) # Spring セキュリティの LDAP プロバイダーの設定 Mule 4 では、Spring セキュリティ LDAP プロバイダーを使用して、コンポーネントの認証を実行するか、または Spring Module 経由で Mule セキュリティプロバイダーとして使用できます。LDAP プロバイダーを設定する前に Spring JAR ファイルを入手して Spring Bean を宣言してください。 ## [](#jar-ファイルの入手)JAR ファイルの入手 Mule ソフトウェアディストリビューションの ​`/lib/opt`​ ディレクトリに、必要な Spring JAR ファイルが入っています。 - `spring-ldap-core-2.3.2.RELEASE.jar` - `spring-security-config-4.2.6.RELEASE.jar` - `spring-security-core-4.2.6.RELEASE.jar` - `spring-security-ldap-4.2.6.RELEASE.jar` - `spring-security-web-4.2.6.RELEASE.jar` ## [](#spring-bean-の宣言)Spring Bean の宣言 [DefaultSpringSecurityContextSource](https://docs.spring.io/spring-security/site/docs/4.0.x/apidocs/org/springframework/security/ldap/DefaultSpringSecurityContextSource.html)​ クラスが LDAP コンテキストを取得するためのアクセスポイントとなります。 `DefaultSpringSecurityContextSource`​ の Spring Bean は、resources フォルダーの個別の ​`beans.xml`​ ファイルで宣言する必要があります。 たとえば、ユーザーを検索して認証するために、Spring セキュリティ認証プロバイダーで使用する LDAP コンテキストソースをセットアップする必要があります。また、次のコードサンプルに示すように、​`ldap-authentication-provider`​ クラスが埋め込まれた ​`authentication-manager`​ インターフェースを定義する必要もあります。 ```xml ``` ## [](#mule-セキュリティプロバイダーの設定)Mule セキュリティプロバイダーの設定 `SpringSecurityProviderAdapter`​ は、​`LdapAuthenticationProvider`​ のような ​`AuthenticationProvider`​ に認証プロセスを委任します。Mule セキュリティプロバイダーを設定するには、1 つ以上のセキュリティプロバイダーを必要とする Mule のコネクタレベルのセキュリティや他のセキュリティ機能の設定方法を示した次の例を参考にしてください。 ```xml ``` 次の設定例では、基本 HTTP セキュリティ検索条件を参照しています。 ```xml ``` ## [](#コンポーネント認証の設定)コンポーネント認証の設定 コンポーネント認証を設定するには、​`authorization-filter`​ 項目を次のように宣言します。 ```xml ``` ## [](#関連情報)関連情報 - [Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.8/component-authorization-using-spring-security) - [LDAP Spring セキュリティ](https://docs.spring.io/spring-security/site/docs/3.1.x/reference/ldap.html) - [Spring セキュリティリファレンス](https://docs.spring.io/spring-security/site/docs/4.0.1.RELEASE/reference/html/) # Spring セキュリティの LDAP プロバイダーの設定 Mule 4 では、Spring セキュリティ LDAP プロバイダーを使用して、コンポーネントの認証を実行するか、または Spring Module 経由で Mule セキュリティプロバイダーとして使用できます。LDAP プロバイダーを設定する前に Spring JAR ファイルを入手して Spring Bean を宣言してください。 ## [](#jar-ファイルの入手)JAR ファイルの入手 Mule ソフトウェアディストリビューションの ​`/lib/opt`​ ディレクトリに、必要な Spring JAR ファイルが入っています。 - `spring-ldap-core-2.3.2.RELEASE.jar` - `spring-security-config-4.2.6.RELEASE.jar` - `spring-security-core-4.2.6.RELEASE.jar` - `spring-security-ldap-4.2.6.RELEASE.jar` - `spring-security-web-4.2.6.RELEASE.jar` ## [](#spring-bean-の宣言)Spring Bean の宣言 [DefaultSpringSecurityContextSource](https://docs.spring.io/spring-security/site/docs/4.0.x/apidocs/org/springframework/security/ldap/DefaultSpringSecurityContextSource.html)​ クラスが LDAP コンテキストを取得するためのアクセスポイントとなります。 `DefaultSpringSecurityContextSource`​ の Spring Bean は、resources フォルダーの個別の ​`beans.xml`​ ファイルで宣言する必要があります。 たとえば、ユーザーを検索して認証するために、Spring セキュリティ認証プロバイダーで使用する LDAP コンテキストソースをセットアップする必要があります。また、次のコードサンプルに示すように、​`ldap-authentication-provider`​ クラスが埋め込まれた ​`authentication-manager`​ インターフェースを定義する必要もあります。 ```xml ``` ## [](#mule-セキュリティプロバイダーの設定)Mule セキュリティプロバイダーの設定 `SpringSecurityProviderAdapter`​ は、​`LdapAuthenticationProvider`​ のような ​`AuthenticationProvider`​ に認証プロセスを委任します。Mule セキュリティプロバイダーを設定するには、1 つ以上のセキュリティプロバイダーを必要とする Mule のコネクタレベルのセキュリティや他のセキュリティ機能の設定方法を示した次の例を参考にしてください。 ```xml ``` 次の設定例では、基本 HTTP セキュリティ検索条件を参照しています。 ```xml ``` ## [](#コンポーネント認証の設定)コンポーネント認証の設定 コンポーネント認証を設定するには、​`authorization-filter`​ 項目を次のように宣言します。 ```xml ``` ## [](#関連情報)関連情報 - [Spring Module](https://docs.mulesoft.com/spring-module/latest/) - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.9/component-authorization-using-spring-security) - [LDAP Spring セキュリティ](https://docs.spring.io/spring-security/site/docs/3.1.x/reference/ldap.html) - [Spring セキュリティリファレンス](https://docs.spring.io/spring-security/site/docs/4.0.1.RELEASE/reference/html/) # Spring セキュリティを使用したコンポーネントの認証 ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定する方法を学習します。 ## [](#spring-セキュリティ認証マネージャーの設定)Spring セキュリティ認証マネージャーの設定 Spring セキュリティインターフェース認証マネージャーは、認証プロバイダーオブジェクトのチェーン内での要求の受け渡しを管理します。フローコンポーネントへのコールでセキュリティを確保するには、設定済みの ​`authenticationManager`​ をアプリケーションコンテキストに追加する必要があります。 次の例では、保護されているプロセッサーへのアクセスレベルが異なるロールを定義しています。 ```xml ``` 次の例は、定義されている ​`authenticationManager`​ を参照して、​`requiredAuthorities`​ 項目で ​`ROLE_ADMIN`​ ロールを持つユーザーのみが操作にアクセスできるようにしています。 ```xml ``` ## [](#非同期システムでのセキュアコンポーネントの設定)非同期システムでのセキュアコンポーネントの設定 複数のスレッドで認証を設定するためには、セキュリティプロバイダーにセキュリティプロパティを追加する必要があるため、非同期システムでは Spring セキュリティが便利です。 次の例では、​`MODE_GLOBAL`​ が追加されたセキュリティプロパティです。 ```xml ``` # Spring セキュリティを使用したコンポーネントの認証 ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定する方法を学習します。 ## [](#spring-セキュリティ認証マネージャーの設定)Spring セキュリティ認証マネージャーの設定 Spring セキュリティインターフェース認証マネージャーは、認証プロバイダーオブジェクトのチェーン内での要求の受け渡しを管理します。フローコンポーネントへのコールでセキュリティを確保するには、設定済みの ​`authenticationManager`​ をアプリケーションコンテキストに追加する必要があります。 次の例では、保護されているプロセッサーへのアクセスレベルが異なるロールを定義しています。 ```xml ``` 次の例は、定義されている ​`authenticationManager`​ を参照して、​`requiredAuthorities`​ 項目で ​`ROLE_ADMIN`​ ロールを持つユーザーのみが操作にアクセスできるようにしています。 ```xml ``` ## [](#非同期システムでのセキュアコンポーネントの設定)非同期システムでのセキュアコンポーネントの設定 複数のスレッドで認証を設定するためには、セキュリティプロバイダーにセキュリティプロパティを追加する必要があるため、非同期システムでは Spring セキュリティが便利です。 次の例では、​`MODE_GLOBAL`​ が追加されたセキュリティプロパティです。 ```xml ``` # Spring セキュリティを使用したコンポーネントの認証 ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定する方法を学習します。 ## [](#spring-セキュリティ認証マネージャーの設定)Spring セキュリティ認証マネージャーの設定 Spring セキュリティインターフェース認証マネージャーは、認証プロバイダーオブジェクトのチェーン内での要求の受け渡しを管理します。フローコンポーネントへのコールでセキュリティを確保するには、設定済みの ​`authenticationManager`​ をアプリケーションコンテキストに追加する必要があります。 次の例では、保護されているプロセッサーへのアクセスレベルが異なるロールを定義しています。 ```xml ``` 次の例は、定義されている ​`authenticationManager`​ を参照して、​`requiredAuthorities`​ 項目で ​`ROLE_ADMIN`​ ロールを持つユーザーのみが操作にアクセスできるようにしています。 ```xml ``` ## [](#非同期システムでのセキュアコンポーネントの設定)非同期システムでのセキュアコンポーネントの設定 複数のスレッドで認証を設定するためには、セキュリティプロバイダーにセキュリティプロパティを追加する必要があるため、非同期システムでは Spring セキュリティが便利です。 次の例では、​`MODE_GLOBAL`​ が追加されたセキュリティプロパティです。 ```xml ``` # Spring セキュリティを使用したコンポーネントの認証 ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定する方法を学習します。 ## [](#spring-セキュリティ認証マネージャーの設定)Spring セキュリティ認証マネージャーの設定 Spring セキュリティインターフェース認証マネージャーは、認証プロバイダーオブジェクトのチェーン内での要求の受け渡しを管理します。フローコンポーネントへのコールでセキュリティを確保するには、設定済みの ​`authenticationManager`​ をアプリケーションコンテキストに追加する必要があります。 次の例では、保護されているプロセッサーへのアクセスレベルが異なるロールを定義しています。 ```xml ``` 次の例は、定義されている ​`authenticationManager`​ を参照して、​`requiredAuthorities`​ 項目で ​`ROLE_ADMIN`​ ロールを持つユーザーのみが操作にアクセスできるようにしています。 ```xml ``` ## [](#非同期システムでのセキュアコンポーネントの設定)非同期システムでのセキュアコンポーネントの設定 複数のスレッドで認証を設定するためには、セキュリティプロバイダーにセキュリティプロパティを追加する必要があるため、非同期システムでは Spring セキュリティが便利です。 次の例では、​`MODE_GLOBAL`​ が追加されたセキュリティプロパティです。 ```xml ``` # Spring セキュリティを使用したコンポーネントの認証 ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定する方法を学習します。 ## [](#spring-セキュリティ認証マネージャーの設定)Spring セキュリティ認証マネージャーの設定 Spring セキュリティインターフェース認証マネージャーは、認証プロバイダーオブジェクトのチェーン内での要求の受け渡しを管理します。フローコンポーネントへのコールでセキュリティを確保するには、設定済みの ​`authenticationManager`​ をアプリケーションコンテキストに追加する必要があります。 次の例では、保護されているプロセッサーへのアクセスレベルが異なるロールを定義しています。 ```xml ``` 次の例は、定義されている ​`authenticationManager`​ を参照して、​`requiredAuthorities`​ 項目で ​`ROLE_ADMIN`​ ロールを持つユーザーのみが操作にアクセスできるようにしています。 ```xml ``` ## [](#非同期システムでのセキュアコンポーネントの設定)非同期システムでのセキュアコンポーネントの設定 複数のスレッドで認証を設定するためには、セキュリティプロバイダーにセキュリティプロパティを追加する必要があるため、非同期システムでは Spring セキュリティが便利です。 次の例では、​`MODE_GLOBAL`​ が追加されたセキュリティプロパティです。 ```xml ``` # Spring セキュリティを使用したコンポーネントの認証 ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定する方法を学習します。 ## [](#spring-セキュリティ認証マネージャーの設定)Spring セキュリティ認証マネージャーの設定 Spring セキュリティインターフェース認証マネージャーは、認証プロバイダーオブジェクトのチェーン内での要求の受け渡しを管理します。フローコンポーネントへのコールでセキュリティを確保するには、設定済みの ​`authenticationManager`​ をアプリケーションコンテキストに追加する必要があります。 次の例では、保護されているプロセッサーへのアクセスレベルが異なるロールを定義しています。 ```xml ``` 次の例は、定義されている ​`authenticationManager`​ を参照して、​`requiredAuthorities`​ 項目で ​`ROLE_ADMIN`​ ロールを持つユーザーのみが操作にアクセスできるようにしています。 ```xml ``` ## [](#非同期システムでのセキュアコンポーネントの設定)非同期システムでのセキュアコンポーネントの設定 複数のスレッドで認証を設定するためには、セキュリティプロバイダーにセキュリティプロパティを追加する必要があるため、非同期システムでは Spring セキュリティが便利です。 次の例では、​`MODE_GLOBAL`​ が追加されたセキュリティプロパティです。 ```xml ``` # Spring セキュリティを使用したコンポーネントの認証 ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定する方法を学習します。 ## [](#spring-セキュリティ認証マネージャーの設定)Spring セキュリティ認証マネージャーの設定 Spring セキュリティインターフェース認証マネージャーは、認証プロバイダーオブジェクトのチェーン内での要求の受け渡しを管理します。フローコンポーネントへのコールでセキュリティを確保するには、設定済みの ​`authenticationManager`​ をアプリケーションコンテキストに追加する必要があります。 次の例では、保護されているプロセッサーへのアクセスレベルが異なるロールを定義しています。 ```xml ``` 次の例は、定義されている ​`authenticationManager`​ を参照して、​`requiredAuthorities`​ 項目で ​`ROLE_ADMIN`​ ロールを持つユーザーのみが操作にアクセスできるようにしています。 ```xml ``` ## [](#非同期システムでのセキュアコンポーネントの設定)非同期システムでのセキュアコンポーネントの設定 複数のスレッドで認証を設定するためには、セキュリティプロバイダーにセキュリティプロパティを追加する必要があるため、非同期システムでは Spring セキュリティが便利です。 次の例では、​`MODE_GLOBAL`​ が追加されたセキュリティプロパティです。 ```xml ``` # Spring 設定用のプレースホルダーの作成 Mule アプリケーションの Spring Module はすべての種類の Spring 設定を使用できます。Spring プロパティプレースホルダーは ​`.properties`​ ファイル (たとえば、​`spring-properties.properties`​) で設定できます。このファイルは、Spring Module と完全に相互運用可能です。 このファイルのプロパティは次の形式になります。 springPropertyA=springPropertyAValue springPropertyB=springPropertyBValue Anypoint Studio では、ファイルは Mule アプリケーションのプロジェクトディレクトリに保存する必要があります。 - `/src/main/resources` 設定プロパティと呼ばれるグローバル要素を通じて ​`.properties`​ ファイルを Mule アプリケーションに追加できます。この要素の XML は次のようになります。 `` YAML ファイルを使用して Spring プロパティプレースホルダーを作成することはできませんが、Spring 以外のモジュールでは可能です。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties) - [Mule アプリケーション用のプロパティプレースホルダーの作成](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-app-properties-to-configure) # Spring 設定用のプレースホルダーの作成 Mule アプリケーションの Spring Module はすべての種類の Spring 設定を使用できます。Spring プロパティプレースホルダーは ​`.properties`​ ファイル (たとえば、​`spring-properties.properties`​) で設定できます。このファイルは、Spring Module と完全に相互運用可能です。 このファイルのプロパティは次の形式になります。 springPropertyA=springPropertyAValue springPropertyB=springPropertyBValue Anypoint Studio では、ファイルは Mule アプリケーションのプロジェクトディレクトリに保存する必要があります。 - `/src/main/resources` 設定プロパティと呼ばれるグローバル要素を通じて ​`.properties`​ ファイルを Mule アプリケーションに追加できます。この要素の XML は次のようになります。 `` YAML ファイルを使用して Spring プロパティプレースホルダーを作成することはできませんが、Spring 以外のモジュールでは可能です。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties) - [Mule アプリケーション用のプロパティプレースホルダーの作成](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-app-properties-to-configure) # Spring 設定用のプレースホルダーの作成 Mule アプリケーションの Spring Module はすべての種類の Spring 設定を使用できます。Spring プロパティプレースホルダーは ​`.properties`​ ファイル (たとえば、​`spring-properties.properties`​) で設定できます。このファイルは、Spring Module と完全に相互運用可能です。 このファイルのプロパティは次の形式になります。 springPropertyA=springPropertyAValue springPropertyB=springPropertyBValue Anypoint Studio では、ファイルは Mule アプリケーションのプロジェクトディレクトリに保存する必要があります。 - `/src/main/resources` 設定プロパティと呼ばれるグローバル要素を通じて ​`.properties`​ ファイルを Mule アプリケーションに追加できます。この要素の XML は次のようになります。 `` YAML ファイルを使用して Spring プロパティプレースホルダーを作成することはできませんが、Spring 以外のモジュールでは可能です。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties) - [Mule アプリケーション用のプロパティプレースホルダーの作成](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-app-properties-to-configure) # Spring 設定用のプレースホルダーの作成 Mule アプリケーションの Spring Module はすべての種類の Spring 設定を使用できます。Spring プロパティプレースホルダーは ​`.properties`​ ファイル (たとえば、​`spring-properties.properties`​) で設定できます。このファイルは、Spring Module と完全に相互運用可能です。 このファイルのプロパティは次の形式になります。 springPropertyA=springPropertyAValue springPropertyB=springPropertyBValue Anypoint Studio では、ファイルは Mule アプリケーションのプロジェクトディレクトリに保存する必要があります。 - `/src/main/resources` 設定プロパティと呼ばれるグローバル要素を通じて ​`.properties`​ ファイルを Mule アプリケーションに追加できます。この要素の XML は次のようになります。 `` YAML ファイルを使用して Spring プロパティプレースホルダーを作成することはできませんが、Spring 以外のモジュールでは可能です。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties) - [Mule アプリケーション用のプロパティプレースホルダーの作成](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-app-properties-to-configure) # Spring 設定用のプレースホルダーの作成 Mule アプリケーションの Spring Module はすべての種類の Spring 設定を使用できます。Spring プロパティプレースホルダーは ​`.properties`​ ファイル (たとえば、​`spring-properties.properties`​) で設定できます。このファイルは、Spring Module と完全に相互運用可能です。 このファイルのプロパティは次の形式になります。 springPropertyA=springPropertyAValue springPropertyB=springPropertyBValue Anypoint Studio では、ファイルは Mule アプリケーションのプロジェクトディレクトリに保存する必要があります。 - `/src/main/resources` 設定プロパティと呼ばれるグローバル要素を通じて ​`.properties`​ ファイルを Mule アプリケーションに追加できます。この要素の XML は次のようになります。 `` YAML ファイルを使用して Spring プロパティプレースホルダーを作成することはできませんが、Spring 以外のモジュールでは可能です。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties) - [Mule アプリケーション用のプロパティプレースホルダーの作成](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-app-properties-to-configure) # Spring 設定用のプレースホルダーの作成 Mule アプリケーションの Spring Module はすべての種類の Spring 設定を使用できます。Spring プロパティプレースホルダーは ​`.properties`​ ファイル (たとえば、​`spring-properties.properties`​) で設定できます。このファイルは、Spring Module と完全に相互運用可能です。 このファイルのプロパティは次の形式になります。 springPropertyA=springPropertyAValue springPropertyB=springPropertyBValue Anypoint Studio では、ファイルは Mule アプリケーションのプロジェクトディレクトリに保存する必要があります。 - `/src/main/resources` 設定プロパティと呼ばれるグローバル要素を通じて ​`.properties`​ ファイルを Mule アプリケーションに追加できます。この要素の XML は次のようになります。 `` YAML ファイルを使用して Spring プロパティプレースホルダーを作成することはできませんが、Spring 以外のモジュールでは可能です。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties) - [Mule アプリケーション用のプロパティプレースホルダーの作成](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-app-properties-to-configure) # Spring 設定用のプレースホルダーの作成 Mule アプリケーションの Spring Module はすべての種類の Spring 設定を使用できます。Spring プロパティプレースホルダーは ​`.properties`​ ファイル (たとえば、​`spring-properties.properties`​) で設定できます。このファイルは、Spring Module と完全に相互運用可能です。 このファイルのプロパティは次の形式になります。 springPropertyA=springPropertyAValue springPropertyB=springPropertyBValue Anypoint Studio では、ファイルは Mule アプリケーションのプロジェクトディレクトリに保存する必要があります。 - `/src/main/resources` 設定プロパティと呼ばれるグローバル要素を通じて ​`.properties`​ ファイルを Mule アプリケーションに追加できます。この要素の XML は次のようになります。 `` YAML ファイルを使用して Spring プロパティプレースホルダーを作成することはできませんが、Spring 以外のモジュールでは可能です。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties) - [Mule アプリケーション用のプロパティプレースホルダーの作成](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-app-properties-to-configure) # Studio 外でのデバッグ Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。 Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。 ## [](#munit-を使用したアプリケーションのテスト)MUnit を使用したアプリケーションのテスト MUnit とは Mule アプリケーションテストフレームワークであり、インテグレーションおよび API の自動テストをビルドできます。完全なインテグレーションおよびユニットテスト機能が提供され、継続的なデプロイメント環境とのインテグレーション用に Maven および Surefire と完全に統合されています。 詳細は MUnit のドキュメントを参照してください。 ## [](#リモートデバッグのアクティブ化)リモートデバッグのアクティブ化 次の Linux の例のように、​**\-debug**​ オプションを使用して Mule を開始し、リモートデバッグをアクティブ化することができます。 $MULE\_HOME/bin/mule -debug このオプションを使用すると、Mule は通常どおりに開始され、次のメッセージがコンソールに記録されます。 Listening for transport dt\_socket at address: 5005 これで Mule をポート 5005 でリモートでデバッグできます。以下の手順に従って。Mule をデバッグします。 1. Eclipse にアクセスし、​**\[Run (実行)\] > \[Debug Configurations (デバッグ設定)\]**​ メニューを選択します。ここで、ポート 5005 を使用する ​**\[Remote Java Application (リモート Java アプリケーション)\]**​ 設定を作成します。 2. 設定パネルの 2 番目のタブで、Mule ローカルインスタンスのソースコードを外部アーカイブとして追加します。 3. 設定画面の右下隅にある ​**\[Debug (デバッグ)\]**​ ボタンをクリックします。ローカルの Mule インスタンスがその起動シーケンスを再開し、これでアプリケーションをステップごとにデバッグできます。 5005 以外のポートを使用する場合は、Mule のデバッグ手順を実行する前に Mule 起動スクリプト内の ​JPDA\_OPTS​ プロパティファイルを変更します。 # Studio 外でのデバッグ Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。 Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。 ## [](#munit-を使用したアプリケーションのテスト)MUnit を使用したアプリケーションのテスト MUnit とは Mule アプリケーションテストフレームワークであり、インテグレーションおよび API の自動テストをビルドできます。完全なインテグレーションおよびユニットテスト機能が提供され、継続的なデプロイメント環境とのインテグレーション用に Maven および Surefire と完全に統合されています。 詳細は MUnit のドキュメントを参照してください。 ## [](#リモートデバッグのアクティブ化)リモートデバッグのアクティブ化 次の Linux の例のように、​**\-debug**​ オプションを使用して Mule を開始し、リモートデバッグをアクティブ化することができます。 $MULE\_HOME/bin/mule -debug このオプションを使用すると、Mule は通常どおりに開始され、次のメッセージがコンソールに記録されます。 Listening for transport dt\_socket at address: 5005 これで Mule をポート 5005 でリモートでデバッグできます。以下の手順に従って。Mule をデバッグします。 1. Eclipse にアクセスし、​**\[Run (実行)\] > \[Debug Configurations (デバッグ設定)\]**​ メニューを選択します。ここで、ポート 5005 を使用する ​**\[Remote Java Application (リモート Java アプリケーション)\]**​ 設定を作成します。 2. 設定パネルの 2 番目のタブで、Mule ローカルインスタンスのソースコードを外部アーカイブとして追加します。 3. 設定画面の右下隅にある ​**\[Debug (デバッグ)\]**​ ボタンをクリックします。ローカルの Mule インスタンスがその起動シーケンスを再開し、これでアプリケーションをステップごとにデバッグできます。 5005 以外のポートを使用する場合は、Mule のデバッグ手順を実行する前に Mule 起動スクリプト内の ​JPDA\_OPTS​ プロパティファイルを変更します。 # Studio 外でのデバッグ Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。 Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。 ## [](#munit-を使用したアプリケーションのテスト)MUnit を使用したアプリケーションのテスト MUnit とは Mule アプリケーションテストフレームワークであり、インテグレーションおよび API の自動テストをビルドできます。完全なインテグレーションおよびユニットテスト機能が提供され、継続的なデプロイメント環境とのインテグレーション用に Maven および Surefire と完全に統合されています。 詳細は MUnit のドキュメントを参照してください。 ## [](#リモートデバッグのアクティブ化)リモートデバッグのアクティブ化 次の Linux の例のように、​**\-debug**​ オプションを使用して Mule を開始し、リモートデバッグをアクティブ化することができます。 $MULE\_HOME/bin/mule -debug このオプションを使用すると、Mule は通常どおりに開始され、次のメッセージがコンソールに記録されます。 Listening for transport dt\_socket at address: 5005 これで Mule をポート 5005 でリモートでデバッグできます。以下の手順に従って。Mule をデバッグします。 1. Eclipse にアクセスし、​**\[Run (実行)\] > \[Debug Configurations (デバッグ設定)\]**​ メニューを選択します。ここで、ポート 5005 を使用する ​**\[Remote Java Application (リモート Java アプリケーション)\]**​ 設定を作成します。 2. 設定パネルの 2 番目のタブで、Mule ローカルインスタンスのソースコードを外部アーカイブとして追加します。 3. 設定画面の右下隅にある ​**\[Debug (デバッグ)\]**​ ボタンをクリックします。ローカルの Mule インスタンスがその起動シーケンスを再開し、これでアプリケーションをステップごとにデバッグできます。 5005 以外のポートを使用する場合は、Mule のデバッグ手順を実行する前に Mule 起動スクリプト内の ​JPDA\_OPTS​ プロパティファイルを変更します。 # Studio 外でのデバッグ Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。 Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。 ## [](#munit-を使用したアプリケーションのテスト)MUnit を使用したアプリケーションのテスト MUnit とは Mule アプリケーションテストフレームワークであり、インテグレーションおよび API の自動テストをビルドできます。完全なインテグレーションおよびユニットテスト機能が提供され、継続的なデプロイメント環境とのインテグレーション用に Maven および Surefire と完全に統合されています。 詳細は MUnit のドキュメントを参照してください。 ## [](#リモートデバッグのアクティブ化)リモートデバッグのアクティブ化 次の Linux の例のように、​**\-debug**​ オプションを使用して Mule を開始し、リモートデバッグをアクティブ化することができます。 $MULE\_HOME/bin/mule -debug このオプションを使用すると、Mule は通常どおりに開始され、次のメッセージがコンソールに記録されます。 Listening for transport dt\_socket at address: 5005 これで Mule をポート 5005 でリモートでデバッグできます。以下の手順に従って。Mule をデバッグします。 1. Eclipse にアクセスし、​**\[Run (実行)\] > \[Debug Configurations (デバッグ設定)\]**​ メニューを選択します。ここで、ポート 5005 を使用する ​**\[Remote Java Application (リモート Java アプリケーション)\]**​ 設定を作成します。 2. 設定パネルの 2 番目のタブで、Mule ローカルインスタンスのソースコードを外部アーカイブとして追加します。 3. 設定画面の右下隅にある ​**\[Debug (デバッグ)\]**​ ボタンをクリックします。ローカルの Mule インスタンスがその起動シーケンスを再開し、これでアプリケーションをステップごとにデバッグできます。 5005 以外のポートを使用する場合は、Mule のデバッグ手順を実行する前に Mule 起動スクリプト内の ​JPDA\_OPTS​ プロパティファイルを変更します。 # Studio 外でのデバッグ Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。 Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。 ## [](#munit-を使用したアプリケーションのテスト)MUnit を使用したアプリケーションのテスト MUnit とは Mule アプリケーションテストフレームワークであり、インテグレーションおよび API の自動テストをビルドできます。完全なインテグレーションおよびユニットテスト機能が提供され、継続的なデプロイメント環境とのインテグレーション用に Maven および Surefire と完全に統合されています。 詳細は MUnit のドキュメントを参照してください。 ## [](#リモートデバッグのアクティブ化)リモートデバッグのアクティブ化 次の Linux の例のように、​**\-debug**​ オプションを使用して Mule を開始し、リモートデバッグをアクティブ化することができます。 $MULE\_HOME/bin/mule -debug このオプションを使用すると、Mule は通常どおりに開始され、次のメッセージがコンソールに記録されます。 Listening for transport dt\_socket at address: 5005 これで Mule をポート 5005 でリモートでデバッグできます。以下の手順に従って。Mule をデバッグします。 1. Eclipse にアクセスし、​**\[Run (実行)\] > \[Debug Configurations (デバッグ設定)\]**​ メニューを選択します。ここで、ポート 5005 を使用する ​**\[Remote Java Application (リモート Java アプリケーション)\]**​ 設定を作成します。 2. 設定パネルの 2 番目のタブで、Mule ローカルインスタンスのソースコードを外部アーカイブとして追加します。 3. 設定画面の右下隅にある ​**\[Debug (デバッグ)\]**​ ボタンをクリックします。ローカルの Mule インスタンスがその起動シーケンスを再開し、これでアプリケーションをステップごとにデバッグできます。 5005 以外のポートを使用する場合は、Mule のデバッグ手順を実行する前に Mule 起動スクリプト内の ​JPDA\_OPTS​ プロパティファイルを変更します。 # Studio 外でのデバッグ Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。 Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。 ## [](#munit-を使用したアプリケーションのテスト)MUnit を使用したアプリケーションのテスト MUnit とは Mule アプリケーションテストフレームワークであり、インテグレーションおよび API の自動テストをビルドできます。完全なインテグレーションおよびユニットテスト機能が提供され、継続的なデプロイメント環境とのインテグレーション用に Maven および Surefire と完全に統合されています。 詳細は MUnit のドキュメントを参照してください。 ## [](#リモートデバッグのアクティブ化)リモートデバッグのアクティブ化 次の Linux の例のように、​**\-debug**​ オプションを使用して Mule を開始し、リモートデバッグをアクティブ化することができます。 $MULE\_HOME/bin/mule -debug このオプションを使用すると、Mule は通常どおりに開始され、次のメッセージがコンソールに記録されます。 Listening for transport dt\_socket at address: 5005 これで Mule をポート 5005 でリモートでデバッグできます。以下の手順に従って。Mule をデバッグします。 1. Eclipse にアクセスし、​**\[Run (実行)\] > \[Debug Configurations (デバッグ設定)\]**​ メニューを選択します。ここで、ポート 5005 を使用する ​**\[Remote Java Application (リモート Java アプリケーション)\]**​ 設定を作成します。 2. 設定パネルの 2 番目のタブで、Mule ローカルインスタンスのソースコードを外部アーカイブとして追加します。 3. 設定画面の右下隅にある ​**\[Debug (デバッグ)\]**​ ボタンをクリックします。ローカルの Mule インスタンスがその起動シーケンスを再開し、これでアプリケーションをステップごとにデバッグできます。 5005 以外のポートを使用する場合は、Mule のデバッグ手順を実行する前に Mule 起動スクリプト内の ​JPDA\_OPTS​ プロパティファイルを変更します。 # Studio 外でのデバッグ Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。 Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。 ## [](#munit-を使用したアプリケーションのテスト)MUnit を使用したアプリケーションのテスト MUnit とは Mule アプリケーションテストフレームワークであり、インテグレーションおよび API の自動テストをビルドできます。完全なインテグレーションおよびユニットテスト機能が提供され、継続的なデプロイメント環境とのインテグレーション用に Maven および Surefire と完全に統合されています。 詳細は MUnit のドキュメントを参照してください。 ## [](#リモートデバッグのアクティブ化)リモートデバッグのアクティブ化 次の Linux の例のように、​**\-debug**​ オプションを使用して Mule を開始し、リモートデバッグをアクティブ化することができます。 $MULE\_HOME/bin/mule -debug このオプションを使用すると、Mule は通常どおりに開始され、次のメッセージがコンソールに記録されます。 Listening for transport dt\_socket at address: 5005 これで Mule をポート 5005 でリモートでデバッグできます。以下の手順に従って。Mule をデバッグします。 1. Eclipse にアクセスし、​**\[Run (実行)\] > \[Debug Configurations (デバッグ設定)\]**​ メニューを選択します。ここで、ポート 5005 を使用する ​**\[Remote Java Application (リモート Java アプリケーション)\]**​ 設定を作成します。 2. 設定パネルの 2 番目のタブで、Mule ローカルインスタンスのソースコードを外部アーカイブとして追加します。 3. 設定画面の右下隅にある ​**\[Debug (デバッグ)\]**​ ボタンをクリックします。ローカルの Mule インスタンスがその起動シーケンスを再開し、これでアプリケーションをステップごとにデバッグできます。 5005 以外のポートを使用する場合は、Mule のデバッグ手順を実行する前に Mule 起動スクリプト内の ​JPDA\_OPTS​ プロパティファイルを変更します。 # Transform Message コンポーネント Transform (または Transform Message) コンポーネントは、入力データを新しい出力構造または形式に変換します。コンポーネントのビジュアルマッパーを使用して受信したデータ構造の要素をドラッグアンドドロップすることで変換を暗黙的にビルドするか、または DataWeave 式言語で変換スクリプトを明示的に作成できます。 - グラフィカルビュー (ドラッグアンドドロップエディター): 2 つのツリービューに、入力と出力の予想されるメタデータ構造が表示されます。これら 2 つのツリー間のマッピングは、入力項目を出力項目に接続するラインによって表されます。ラインを作成するには、要素を入力から出力の別の要素にドラッグアンドドロップします。 ![transform message component concept design center b3dc0](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/transform-message-component-concept-design-center-b3dc0.png) Figure 1. Transform コンポーネントのドラッグアンドドロップエディター - スクリプトビュー: ヴィジュアルマッピングは DataWeave コードとして表現できます。ここでは、集約、正規化、グループ化、結合、パーティション、ピボット、および検索条件といった高度な変換をコーディングできます。 ![transform message component concept design center d3719](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/transform-message-component-concept-design-center-d3719.png) Figure 2. Transform コンポーネントの DataWeave スクリプト 1 つのビューで変更を行うと、他方のビューにリアルタイムで反映されます。 ## [](#プレビュー)プレビュー 出力のプレビューは、サンプルデータ (JSON スニペットなど) を使用して表示され、変換を編集するとリアルタイムで更新されます。 ![using dataweave in studio b504a](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/using-dataweave-in-studio-b504a.png) Figure 3. Anypoint Studio の Transform コンポーネント ## [](#メタデータ)メタデータ Transform コンポーネントは、メッセージペイロード、変数、または属性の入力および出力ペイロードを受け入れます。​[サポートされている MIME タイプ (形式)](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats)​ に対して、形式特有のリソースと設定を提供できます。 - CSV サンプルまたは RAML 定義 - Copybook ファイルまたはスキーマ - 1 つまたは複数のシートの Excel 列名と型定義 (String、Number、Boolean、Date、および DateTime) - 固定幅の列名、型 (String、Integer、Decimal、Boolean、Date、および DateTime)、幅、形式の設定 - フラットファイルスキーマ - JSON サンプルまたはスキーマ - オブジェクトクラスまたは RAML 定義 - シンプルな型 (String、Number、Integer、Boolean、Date、または DateTime) - XML サンプルまたはスキーマ ## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-workflow-create-mapping-ui-studio) [ヒント: Transform Message UI](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-tips-transform-message-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # Transform Message コンポーネント Transform (または Transform Message) コンポーネントは、入力データを新しい出力構造または形式に変換します。コンポーネントのビジュアルマッパーを使用して受信したデータ構造の要素をドラッグアンドドロップすることで変換を暗黙的にビルドするか、または DataWeave 式言語で変換スクリプトを明示的に作成できます。 - グラフィカルビュー (ドラッグアンドドロップエディター): 2 つのツリービューに、入力と出力の予想されるメタデータ構造が表示されます。これら 2 つのツリー間のマッピングは、入力項目を出力項目に接続するラインによって表されます。ラインを作成するには、要素を入力から出力の別の要素にドラッグアンドドロップします。 ![transform message component concept design center b3dc0](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/transform-message-component-concept-design-center-b3dc0.png) Figure 1. Transform コンポーネントのドラッグアンドドロップエディター - スクリプトビュー: ヴィジュアルマッピングは DataWeave コードとして表現できます。ここでは、集約、正規化、グループ化、結合、パーティション、ピボット、および検索条件といった高度な変換をコーディングできます。 ![transform message component concept design center d3719](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/transform-message-component-concept-design-center-d3719.png) Figure 2. Transform コンポーネントの DataWeave スクリプト 1 つのビューで変更を行うと、他方のビューにリアルタイムで反映されます。 ## [](#プレビュー)プレビュー 出力のプレビューは、サンプルデータ (JSON スニペットなど) を使用して表示され、変換を編集するとリアルタイムで更新されます。 ![using dataweave in studio b504a](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/using-dataweave-in-studio-b504a.png) Figure 3. Anypoint Studio の Transform コンポーネント ## [](#メタデータ)メタデータ Transform コンポーネントは、メッセージペイロード、変数、または属性の入力および出力ペイロードを受け入れます。​[サポートされている MIME タイプ (形式)](https://docs.mulesoft.com/dataweave/latest/dataweave-formats)​ に対して、形式特有のリソースと設定を提供できます。 - CSV サンプルまたは RAML 定義 - Copybook ファイルまたはスキーマ - 1 つまたは複数のシートの Excel 列名と型定義 (String、Number、Boolean、Date、および DateTime) - 固定幅の列名、型 (String、Integer、Decimal、Boolean、Date、および DateTime)、幅、形式の設定 - フラットファイルスキーマ - JSON サンプルまたはスキーマ - オブジェクトクラスまたは RAML 定義 - シンプルな型 (String、Number、Integer、Boolean、Date、または DateTime) - XML サンプルまたはスキーマ ## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-workflow-create-mapping-ui-studio) [ヒント: Transform Message UI](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-tips-transform-message-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # Transform Message コンポーネント Transform (または Transform Message) コンポーネントは、入力データを新しい出力構造または形式に変換します。コンポーネントのビジュアルマッパーを使用して受信したデータ構造の要素をドラッグアンドドロップすることで変換を暗黙的にビルドするか、または DataWeave 式言語で変換スクリプトを明示的に作成できます。 - グラフィカルビュー (ドラッグアンドドロップエディター): 2 つのツリービューに、入力と出力の予想されるメタデータ構造が表示されます。これら 2 つのツリー間のマッピングは、入力項目を出力項目に接続するラインによって表されます。ラインを作成するには、要素を入力から出力の別の要素にドラッグアンドドロップします。 ![transform message component concept design center b3dc0](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/transform-message-component-concept-design-center-b3dc0.png) Figure 1. Transform コンポーネントのドラッグアンドドロップエディター - スクリプトビュー: ヴィジュアルマッピングは DataWeave コードとして表現できます。ここでは、集約、正規化、グループ化、結合、パーティション、ピボット、および検索条件といった高度な変換をコーディングできます。 ![transform message component concept design center d3719](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/transform-message-component-concept-design-center-d3719.png) Figure 2. Transform コンポーネントの DataWeave スクリプト 1 つのビューで変更を行うと、他方のビューにリアルタイムで反映されます。 ## [](#プレビュー)プレビュー 出力のプレビューは、サンプルデータ (JSON スニペットなど) を使用して表示され、変換を編集するとリアルタイムで更新されます。 ![using dataweave in studio b504a](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/using-dataweave-in-studio-b504a.png) Figure 3. Anypoint Studio の Transform コンポーネント ## [](#メタデータ)メタデータ Transform コンポーネントは、メッセージペイロード、変数、または属性の入力および出力ペイロードを受け入れます。​[サポートされている MIME タイプ (形式)](https://docs.mulesoft.com/dataweave/latest/dataweave-formats)​ に対して、形式特有のリソースと設定を提供できます。 - CSV サンプルまたは RAML 定義 - Copybook ファイルまたはスキーマ - 1 つまたは複数のシートの Excel 列名と型定義 (String、Number、Boolean、Date、および DateTime) - 固定幅の列名、型 (String、Integer、Decimal、Boolean、Date、および DateTime)、幅、形式の設定 - フラットファイルスキーマ - JSON サンプルまたはスキーマ - オブジェクトクラスまたは RAML 定義 - 単純型 (String、Number、Integer、Boolean、Date、または DateTime) - XML サンプルまたはスキーマ ## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-workflow-create-mapping-ui-studio) [ヒント: Transform Message UI](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-tips-transform-message-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # Transform Message コンポーネント Transform (または Transform Message) コンポーネントは、入力データを新しい出力構造または形式に変換します。コンポーネントのビジュアルマッパーを使用して受信したデータ構造の要素をドラッグアンドドロップすることで変換を暗黙的にビルドするか、または DataWeave 式言語で変換スクリプトを明示的に作成できます。 - グラフィカルビュー (ドラッグアンドドロップエディター): 2 つのツリービューに、入力と出力の予想されるメタデータ構造が表示されます。これら 2 つのツリー間のマッピングは、入力項目を出力項目に接続するラインによって表されます。ラインを作成するには、要素を入力から出力の別の要素にドラッグアンドドロップします。 ![transform message component concept design center b3dc0](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/transform-message-component-concept-design-center-b3dc0.png) Figure 1. Transform コンポーネントのドラッグアンドドロップエディター - スクリプトビュー: ヴィジュアルマッピングは DataWeave コードとして表現できます。ここでは、集約、正規化、グループ化、結合、パーティション、ピボット、および検索条件といった高度な変換をコーディングできます。 ![transform message component concept design center d3719](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/transform-message-component-concept-design-center-d3719.png) Figure 2. Transform コンポーネントの DataWeave スクリプト 1 つのビューで変更を行うと、他方のビューにリアルタイムで反映されます。 ## [](#プレビュー)プレビュー 出力のプレビューは、サンプルデータ (JSON スニペットなど) を使用して表示され、変換を編集するとリアルタイムで更新されます。 ![using dataweave in studio b504a](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/using-dataweave-in-studio-b504a.png) Figure 3. Anypoint Studio の Transform コンポーネント ## [](#メタデータ)メタデータ Transform コンポーネントは、メッセージペイロード、変数、または属性の入力および出力ペイロードを受け入れます。​[サポートされている MIME タイプ (形式)](https://docs.mulesoft.com/dataweave/latest/dataweave-formats)​ に対して、形式特有のリソースと設定を提供できます。 - CSV サンプルまたは RAML 定義 - Copybook ファイルまたはスキーマ - 1 つまたは複数のシートの Excel 列名と型定義 (String、Number、Boolean、Date、および DateTime) - 固定幅の列名、型 (String、Integer、Decimal、Boolean、Date、および DateTime)、幅、形式の設定 - フラットファイルスキーマ - JSON サンプルまたはスキーマ - オブジェクトクラスまたは RAML 定義 - 単純型 (String、Number、Integer、Boolean、Date、または DateTime) - XML サンプルまたはスキーマ ## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-workflow-create-mapping-ui-studio) [ヒント: Transform Message UI](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-tips-transform-message-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # Transform Message コンポーネント Transform (または Transform Message) コンポーネントは、入力データを新しい出力構造または形式に変換します。コンポーネントのビジュアルマッパーを使用して受信したデータ構造の要素をドラッグアンドドロップすることで変換を暗黙的にビルドするか、または DataWeave 式言語で変換スクリプトを明示的に作成できます。 - グラフィカルビュー (ドラッグアンドドロップエディター): 2 つのツリービューに、入力と出力の予想されるメタデータ構造が表示されます。これら 2 つのツリー間のマッピングは、入力項目を出力項目に接続するラインによって表されます。ラインを作成するには、要素を入力から出力の別の要素にドラッグアンドドロップします。 ![transform message component concept design center b3dc0](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/transform-message-component-concept-design-center-b3dc0.png) Figure 1. Transform コンポーネントのドラッグアンドドロップエディター - スクリプトビュー: ヴィジュアルマッピングは DataWeave コードとして表現できます。ここでは、集約、正規化、グループ化、結合、パーティション、ピボット、および検索条件といった高度な変換をコーディングできます。 ![transform message component concept design center d3719](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/transform-message-component-concept-design-center-d3719.png) Figure 2. Transform コンポーネントの DataWeave スクリプト 1 つのビューで変更を行うと、他方のビューにリアルタイムで反映されます。 ## [](#プレビュー)プレビュー 出力のプレビューは、サンプルデータ (JSON スニペットなど) を使用して表示され、変換を編集するとリアルタイムで更新されます。 ![using dataweave in studio b504a](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/using-dataweave-in-studio-b504a.png) Figure 3. Anypoint Studio の Transform コンポーネント ## [](#メタデータ)メタデータ Transform コンポーネントは、メッセージペイロード、変数、または属性の入力および出力ペイロードを受け入れます。​[サポートされている MIME タイプ (形式)](https://docs.mulesoft.com/dataweave/latest/dataweave-formats)​ に対して、形式特有のリソースと設定を提供できます。 - CSV サンプルまたは RAML 定義 - Copybook ファイルまたはスキーマ - 1 つまたは複数のシートの Excel 列名と型定義 (String、Number、Boolean、Date、および DateTime) - 固定幅の列名、型 (String、Integer、Decimal、Boolean、Date、および DateTime)、幅、形式の設定 - フラットファイルスキーマ - JSON サンプルまたはスキーマ - オブジェクトクラスまたは RAML 定義 - 単純型 (String、Number、Integer、Boolean、Date、または DateTime) - XML サンプルまたはスキーマ ## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-workflow-create-mapping-ui-studio) [ヒント: Transform Message UI](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-tips-transform-message-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # Transform Message コンポーネント Transform (または Transform Message) コンポーネントは、入力データを新しい出力構造または形式に変換します。コンポーネントのビジュアルマッパーを使用して受信したデータ構造の要素をドラッグアンドドロップすることで変換を暗黙的にビルドするか、または DataWeave 式言語で変換スクリプトを明示的に作成できます。 - グラフィカルビュー (ドラッグアンドドロップエディター): 2 つのツリービューに、入力と出力の予想されるメタデータ構造が表示されます。これら 2 つのツリー間のマッピングは、入力項目を出力項目に接続するラインによって表されます。ラインを作成するには、要素を入力から出力の別の要素にドラッグアンドドロップします。 ![変換メッセージコンポーネントの入構造と出力構造](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/transform-message-component-concept-design-center-b3dc0.png) Figure 1. Transform コンポーネントのドラッグアンドドロップエディター - スクリプトビュー: ヴィジュアルマッピングは DataWeave コードとして表現できます。ここでは、集約、正規化、グループ化、結合、パーティション、ピボット、および検索条件といった高度な変換をコーディングできます。 ![バージョン番号、ストア ID、項目 ID が含まれる JSON を出力する DataWeave スクリプト](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/transform-message-component-concept-design-center-d3719.png) Figure 2. Transform コンポーネントの DataWeave スクリプト 1 つのビューで変更を行うと、他方のビューにリアルタイムで反映されます。 ## [](#プレビュー)プレビュー 出力のプレビューは、サンプルデータ (JSON スニペットなど) を使用して表示され、変換を編集するとリアルタイムで更新されます。 ![XML から JSON への DataWeave 変換](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/using-dataweave-in-studio-b504a.png) Figure 3. Anypoint Studio の Transform コンポーネント ## [](#メタデータ)メタデータ Transform コンポーネントは、メッセージペイロード、変数、または属性の入力および出力ペイロードを受け入れます。​[サポートされている MIME タイプ (形式)](https://docs.mulesoft.com/dataweave/latest/dataweave-formats)​ に対して、形式特有のリソースと設定を提供できます。 - CSV サンプルまたは RAML 定義 - Copybook ファイルまたはスキーマ - 1 つまたは複数のシートの Excel 列名と型定義 (String、Number、Boolean、Date、および DateTime) - 固定幅の列名、型 (String、Integer、Decimal、Boolean、Date、および DateTime)、幅、形式の設定 - フラットファイルスキーマ - JSON サンプルまたはスキーマ - オブジェクトクラスまたは RAML 定義 - 単純型 (String、Number、Integer、Boolean、Date、または DateTime) - XML サンプルまたはスキーマ ## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-workflow-create-mapping-ui-studio) [ヒント: Transform Message UI](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-tips-transform-message-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # Transform Message コンポーネント Transform (または Transform Message) コンポーネントは、入力データを新しい出力構造または形式に変換します。コンポーネントのビジュアルマッパーを使用して受信したデータ構造の要素をドラッグアンドドロップすることで変換を暗黙的にビルドするか、または DataWeave 式言語で変換スクリプトを明示的に作成できます。 - グラフィカルビュー (ドラッグアンドドロップエディター): 2 つのツリービューに、入力と出力の予想されるメタデータ構造が表示されます。これら 2 つのツリー間のマッピングは、入力項目を出力項目に接続するラインによって表されます。ラインを作成するには、要素を入力から出力の別の要素にドラッグアンドドロップします。 ![変換メッセージコンポーネントの入構造と出力構造](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/transform-message-component-concept-design-center-b3dc0.png) Figure 1. Transform コンポーネントのドラッグアンドドロップエディター - スクリプトビュー: ヴィジュアルマッピングは DataWeave コードとして表現できます。ここでは、集約、正規化、グループ化、結合、パーティション、ピボット、および検索条件といった高度な変換をコーディングできます。 ![バージョン番号、ストア ID、項目 ID が含まれる JSON を出力する DataWeave スクリプト](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/transform-message-component-concept-design-center-d3719.png) Figure 2. Transform コンポーネントの DataWeave スクリプト 1 つのビューで変更を行うと、他方のビューにリアルタイムで反映されます。 ## [](#プレビュー)プレビュー 出力のプレビューは、サンプルデータ (JSON スニペットなど) を使用して表示され、変換を編集するとリアルタイムで更新されます。 ![XML から JSON への DataWeave 変換](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/using-dataweave-in-studio-b504a.png) Figure 3. Anypoint Studio の Transform コンポーネント ## [](#メタデータ)メタデータ Transform コンポーネントは、メッセージペイロード、変数、または属性の入力および出力ペイロードを受け入れます。​[サポートされている MIME タイプ (形式)](https://docs.mulesoft.com/dataweave/latest/dataweave-formats)​ に対して、形式特有のリソースと設定を提供できます。 - CSV サンプルまたは RAML 定義 - Copybook ファイルまたはスキーマ - 1 つまたは複数のシートの Excel 列名と型定義 (String、Number、Boolean、Date、および DateTime) - 固定幅の列名、型 (String、Integer、Decimal、Boolean、Date、および DateTime)、幅、形式の設定 - フラットファイルスキーマ - JSON サンプルまたはスキーマ - オブジェクトクラスまたは RAML 定義 - 単純型 (String、Number、Integer、Boolean、Date、または DateTime) - XML サンプルまたはスキーマ ## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-workflow-create-mapping-ui-studio) [ヒント: Transform Message UI](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-tips-transform-message-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # Transform Message コンポーネント XML リファレンス Studio UI を使用して Mule プロジェクトに DataWeave 言語を取り込むだけではなく、Studio の \[XML\] タブまたは外部エディターで、Transform Message コンポーネントをすべて XML で作成して設定することができます。 UI を使用して要素を作成および設定すると、対応する XML 設定が XML エディターで自動的に作成されます。 ## [](#名前空間とスキーマの場所)名前空間とスキーマの場所 Mule プロジェクトの最初に、次の連動関係を取り込む必要があります。 ```xml ``` Transform コンポーネントをキャンバスにドラッグアンドドロップすると、Studio はこれらの連動関係を自動的に追加します。 ## [](#eetransform) ``​ 要素は、Transform コンポーネントのトップレベル XML タグです。
<ee:transform>​ 属性 説明

doc:name

Studio キャンバスに表示される要素の名前を定義します。

mode

遅延実行​を参照します。使用可能な値: immediate​ または ​deferred​。​DataWeave のメモリ管理​を参照してください。
## [](#transform-コンポーネントへの-dataweave-スクリプトの追加)Transform コンポーネントへの DataWeave スクリプトの追加 [変換](#transformations)​要素内で ​`CDATA`​ を使用して DataWeave コードを XML に入力するか、または外部の ​`.dwl`​ ファイルを参照できます。 この例では、​``​ 変換要素内で DataWeave スクリプトを作成しています。 ```xml ``` 次の例では、外部の ​`.dwl`​ ファイルを呼び出して同じ設定を行っています。 ```xml ``` これらのファイルは、デフォルトではプロジェクトの ​`src/main/resources`​ フォルダーにあります。 ## [](#transformations)変換 単一の Transform コンポーネント要素 (​``​) で、Mule イベントのすべての部分のコンテンツを指定できます。 - ``​ には、​``​ と ​``​ を定義できます。 - ``​ には、1 つまたは複数の ​``​ 要素を定義できます。 例 ```xml ``` 子要素には、同じ属性の一部を定義できます。
属性 説明

resource

DataWeave 変換スクリプトが格納された ​.dwl​ ファイルを参照します。これらの値は静的に解決されます。たとえば、​<ee:set-payload resource="myscript-${env}.dwl"/>​ を使用すると Transform Message UI で ​Unexpected end of input, expected header or content​ というエラーが発生します。

variableName

出力変数専用で、変数の名前を定義します。
## [](#完全な-xml-の例)完全な XML の例 ペイロード、属性、および変数の変換を作成する例です。 ```xml { id: value0.id, username: value0.username, address: { street: value0.address.street }, website: value0.website })]]> ``` ## [](#関連情報)関連情報 [DataWeave セレクター](#dataweave-selectors.adoc) # Transform Message コンポーネント XML リファレンス Studio UI を使用して Mule プロジェクトに DataWeave 言語を取り込むだけではなく、Studio の \[XML\] タブまたは外部エディターで、Transform Message コンポーネントをすべて XML で作成して設定することができます。 UI を使用して要素を作成および設定すると、対応する XML 設定が XML エディターで自動的に作成されます。 ## [](#名前空間とスキーマの場所)名前空間とスキーマの場所 Mule プロジェクトの最初に、次の連動関係を取り込む必要があります。 ```xml ``` Transform コンポーネントをキャンバスにドラッグアンドドロップすると、Studio はこれらの連動関係を自動的に追加します。 ## [](#eetransform) ``​ 要素は、Transform コンポーネントのトップレベル XML タグです。
<ee:transform>​ 属性 説明

doc:name

Studio キャンバスに表示される要素の名前を定義します。

mode

遅延実行​を参照します。使用可能な値: immediate​ または ​deferred​。​DataWeave のメモリ管理​を参照してください。
## [](#transform-コンポーネントへの-dataweave-スクリプトの追加)Transform コンポーネントへの DataWeave スクリプトの追加 [変換](#transformations)​要素内で ​`CDATA`​ を使用して DataWeave コードを XML に入力するか、または外部の ​`.dwl`​ ファイルを参照できます。 この例では、​``​ 変換要素内で DataWeave スクリプトを作成しています。 ```xml ``` 次の例では、外部の ​`.dwl`​ ファイルを呼び出して同じ設定を行っています。 ```xml ``` これらのファイルは、デフォルトではプロジェクトの ​`src/main/resources`​ フォルダーにあります。 ## [](#transformations)変換 単一の Transform コンポーネント要素 (​``​) で、Mule イベントのすべての部分のコンテンツを指定できます。 - ``​ には、​``​ と ​``​ を定義できます。 - ``​ には、1 つまたは複数の ​``​ 要素を定義できます。 例 ```xml ``` 子要素には、同じ属性の一部を定義できます。
属性 説明

resource

DataWeave 変換スクリプトが格納された ​.dwl​ ファイルを参照します。これらの値は静的に解決されます。たとえば、​<ee:set-payload resource="myscript-${env}.dwl"/>​ を使用すると Transform Message UI で ​Unexpected end of input, expected header or content​ というエラーが発生します。

variableName

出力変数専用で、変数の名前を定義します。
## [](#完全な-xml-の例)完全な XML の例 ペイロード、属性、および変数の変換を作成する例です。 ```xml { id: value0.id, username: value0.username, address: { street: value0.address.street }, website: value0.website })]]> ``` ## [](#関連情報)関連情報 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) # Transform Message コンポーネント XML リファレンス Studio UI を使用して Mule プロジェクトに DataWeave 言語を取り込むだけではなく、Studio の \[XML\] タブまたは外部エディターで、Transform Message コンポーネントをすべて XML で作成して設定することができます。 UI を使用して要素を作成および設定すると、対応する XML 設定が XML エディターで自動的に作成されます。 ## [](#名前空間とスキーマの場所)名前空間とスキーマの場所 Mule プロジェクトの最初に、次の連動関係を取り込む必要があります。 ```xml ``` Transform コンポーネントをキャンバスにドラッグアンドドロップすると、Studio はこれらの連動関係を自動的に追加します。 ## [](#eetransform) ``​ 要素は、Transform コンポーネントのトップレベル XML タグです。
<ee:transform>​ Attributes 説明

doc:name

Studio キャンバスに表示される要素の名前を定義します。

mode

遅延実行​を参照します。使用可能な値: immediate​ または ​deferred​。​DataWeave のメモリ管理​を参照してください。
## [](#transform-コンポーネントへの-dataweave-スクリプトの追加)Transform コンポーネントへの DataWeave スクリプトの追加 [変換](#transformations)​要素内で ​`CDATA`​ を使用して DataWeave コードを XML に入力するか、または外部の ​`.dwl`​ ファイルを参照できます。 この例では、​``​ 変換要素内で DataWeave スクリプトを作成しています。 ```xml ``` 次の例では、外部の ​`.dwl`​ ファイルを呼び出して同じ設定を行っています。 ```xml ``` これらのファイルは、デフォルトではプロジェクトの ​`src/main/resources`​ フォルダーにあります。 ## [](#transformations)変換 単一の Transform コンポーネント要素 (​``​) で、Mule イベントのすべての部分の内容を指定できます。 - ``​ には、​``​ と ​``​ を定義できます。 - ``​ には、1 つまたは複数の ​``​ 要素を定義できます。 例 ```xml ``` 子要素には、同じ属性の一部を定義できます。
属性 説明

resource

DataWeave 変換スクリプトが格納された ​.dwl​ ファイルを参照します。これらの値は静的に解決されます。たとえば、​<ee:set-payload resource="myscript-${env}.dwl"/>​ を使用すると Transform Message UI で ​Unexpected end of input, expected header or content​ というエラーが発生します。

variableName

出力変数専用で、変数の名前を定義します。
## [](#完全な-xml-の例)完全な XML の例 ペイロード、属性、および変数の変換を作成する例です。 ```xml { id: value0.id, username: value0.username, address: { street: value0.address.street }, website: value0.website })]]> ``` ## [](#関連情報)関連情報 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) # Transform Message コンポーネント XML リファレンス Studio UI を使用して Mule プロジェクトに DataWeave 言語を取り込むだけではなく、Studio の \[XML\] タブまたは外部エディターで、Transform Message コンポーネントをすべて XML で作成して設定することができます。 UI を使用して要素を作成および設定すると、対応する XML 設定が XML エディターで自動的に作成されます。 ## [](#名前空間とスキーマの場所)名前空間とスキーマの場所 Mule プロジェクトの最初に、次の連動関係を取り込む必要があります。 ```xml ``` Transform コンポーネントをキャンバスにドラッグアンドドロップすると、Studio はこれらの連動関係を自動的に追加します。 ## [](#eetransform) ``​ 要素は、Transform コンポーネントのトップレベル XML タグです。
<ee:transform>​ 属性 説明

doc:name

Studio キャンバスに表示される要素の名前を定義します。

mode

遅延実行​を参照します。使用可能な値: immediate​ または ​deferred​。​DataWeave のメモリ管理​を参照してください。
## [](#transform-コンポーネントへの-dataweave-スクリプトの追加)Transform コンポーネントへの DataWeave スクリプトの追加 [変換](#transformations)​要素内で ​`CDATA`​ を使用して DataWeave コードを XML に入力するか、または外部の ​`.dwl`​ ファイルを参照できます。 この例では、​``​ 変換要素内で DataWeave スクリプトを作成しています。 ```xml ``` 次の例では、外部の ​`.dwl`​ ファイルを呼び出して同じ設定を行っています。 ```xml ``` これらのファイルは、デフォルトではプロジェクトの ​`src/main/resources`​ フォルダーにあります。 ## [](#transformations)変換 単一の Transform コンポーネント要素 (​``​) で、Mule イベントのすべての部分のコンテンツを指定できます。 - ``​ には、​``​ と ​``​ を定義できます。 - ``​ には、1 つまたは複数の ​``​ 要素を定義できます。 例 ```xml ``` 子要素には、同じ属性の一部を定義できます。
属性 説明

resource

DataWeave 変換スクリプトが格納された ​.dwl​ ファイルを参照します。これらの値は静的に解決されます。たとえば、​<ee:set-payload resource="myscript-${env}.dwl"/>​ を使用すると Transform Message UI で ​Unexpected end of input, expected header or content​ というエラーが発生します。

variableName

出力変数専用で、変数の名前を定義します。
## [](#完全な-xml-の例)完全な XML の例 ペイロード、属性、および変数の変換を作成する例です。 ```xml { id: value0.id, username: value0.username, address: { street: value0.address.street }, website: value0.website })]]> ``` ## [](#関連情報)関連情報 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) # Transform Message コンポーネント XML リファレンス Studio UI を使用して Mule プロジェクトに DataWeave 言語を取り込むだけではなく、Studio の \[XML\] タブまたは外部エディターで、Transform Message コンポーネントをすべて XML で作成して設定することができます。 UI を使用して要素を作成および設定すると、対応する XML 設定が XML エディターで自動的に作成されます。 ## [](#名前空間とスキーマの場所)名前空間とスキーマの場所 Mule プロジェクトの最初に、次の連動関係を取り込む必要があります。 ```xml ``` Transform コンポーネントをキャンバスにドラッグアンドドロップすると、Studio はこれらの連動関係を自動的に追加します。 ## [](#eetransform) ``​ 要素は、Transform コンポーネントのトップレベル XML タグです。
<ee:transform>​ 属性 説明

doc:name

Studio キャンバスに表示される要素の名前を定義します。

mode

遅延実行​を参照します。使用可能な値: immediate​ または ​deferred​。​DataWeave のメモリ管理​を参照してください。
## [](#transform-コンポーネントへの-dataweave-スクリプトの追加)Transform コンポーネントへの DataWeave スクリプトの追加 [変換](#transformations)​要素内で ​`CDATA`​ を使用して DataWeave コードを XML に入力するか、または外部の ​`.dwl`​ ファイルを参照できます。 この例では、​``​ 変換要素内で DataWeave スクリプトを作成しています。 ```xml ``` 次の例では、外部の ​`.dwl`​ ファイルを呼び出して同じ設定を行っています。 ```xml ``` これらのファイルは、デフォルトではプロジェクトの ​`src/main/resources`​ フォルダーにあります。 ## [](#transformations)変換 単一の Transform コンポーネント要素 (​``​) で、Mule イベントのすべての部分のコンテンツを指定できます。 - ``​ には、​``​ と ​``​ を定義できます。 - ``​ には、1 つまたは複数の ​``​ 要素を定義できます。 例 ```xml ``` 子要素には、同じ属性の一部を定義できます。
属性 説明

resource

DataWeave 変換スクリプトが格納された ​.dwl​ ファイルを参照します。これらの値は静的に解決されます。たとえば、​<ee:set-payload resource="myscript-${env}.dwl"/>​ を使用すると Transform Message UI で ​Unexpected end of input, expected header or content​ というエラーが発生します。

variableName

出力変数専用で、変数の名前を定義します。
## [](#完全な-xml-の例)完全な XML の例 ペイロード、属性、および変数の変換を作成する例です。 ```xml { id: value0.id, username: value0.username, address: { street: value0.address.street }, website: value0.website })]]> ``` ## [](#関連情報)関連情報 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) # Transform Message コンポーネント XML リファレンス Studio UI を使用して Mule プロジェクトに DataWeave 言語を取り込むだけではなく、Studio の \[XML\] タブまたは外部エディターで、Transform Message コンポーネントをすべて XML で作成して設定することができます。 UI を使用して要素を作成および設定すると、対応する XML 設定が XML エディターで自動的に作成されます。 ## [](#名前空間とスキーマの場所)名前空間とスキーマの場所 Mule プロジェクトの最初に、次の連動関係を取り込む必要があります。 ```xml ``` Transform コンポーネントをキャンバスにドラッグアンドドロップすると、Studio はこれらの連動関係を自動的に追加します。 ## [](#eetransform) ``​ 要素は、Transform コンポーネントのトップレベル XML タグです。
<ee:transform>​ 属性 説明

doc:name

Studio キャンバスに表示される要素の名前を定義します。

mode

遅延実行​を参照します。使用可能な値: immediate​ または ​deferred​。​DataWeave のメモリ管理​を参照してください。
## [](#transform-コンポーネントへの-dataweave-スクリプトの追加)Transform コンポーネントへの DataWeave スクリプトの追加 [変換](#transformations)​要素内で ​`CDATA`​ を使用して DataWeave コードを XML に入力するか、または外部の ​`.dwl`​ ファイルを参照できます。 この例では、​``​ 変換要素内で DataWeave スクリプトを作成しています。 ```xml ``` 次の例では、外部の ​`.dwl`​ ファイルを呼び出して同じ設定を行っています。 ```xml ``` これらのファイルは、デフォルトではプロジェクトの ​`src/main/resources`​ フォルダーにあります。 ## [](#transformations)変換 単一の Transform コンポーネント要素 (​``​) で、Mule イベントのすべての部分のコンテンツを指定できます。 - ``​ には、​``​ と ​``​ を定義できます。 - ``​ には、1 つまたは複数の ​``​ 要素を定義できます。 例 ```xml ``` 子要素には、同じ属性の一部を定義できます。
属性 説明

resource

DataWeave 変換スクリプトが格納された ​.dwl​ ファイルを参照します。これらの値は静的に解決されます。たとえば、​<ee:set-payload resource="myscript-${env}.dwl"/>​ を使用すると Transform Message UI で ​Unexpected end of input, expected header or content​ というエラーが発生します。

variableName

出力変数専用で、変数の名前を定義します。
## [](#完全な-xml-の例)完全な XML の例 ペイロード、属性、および変数の変換を作成する例です。 ```xml { id: value0.id, username: value0.username, address: { street: value0.address.street }, website: value0.website })]]> ``` ## [](#関連情報)関連情報 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) # Transform Message コンポーネント XML リファレンス Studio UI を使用して Mule プロジェクトに DataWeave 言語を取り込むだけではなく、Studio の \[XML\] タブまたは外部エディターで、Transform Message コンポーネントをすべて XML で作成して設定することができます。 UI を使用して要素を作成および設定すると、対応する XML 設定が XML エディターで自動的に作成されます。 ## [](#名前空間とスキーマの場所)名前空間とスキーマの場所 Mule プロジェクトの最初に、次の連動関係を取り込む必要があります。 ```xml ``` Transform コンポーネントをキャンバスにドラッグアンドドロップすると、Studio はこれらの連動関係を自動的に追加します。 ## [](#eetransform) ``​ 要素は、Transform コンポーネントのトップレベル XML タグです。
<ee:transform>​ 属性 説明

doc:name

Studio キャンバスに表示される要素の名前を定義します。

mode

遅延実行​を参照します。使用可能な値: immediate​ または ​deferred​。​DataWeave のメモリ管理​を参照してください。
## [](#transform-コンポーネントへの-dataweave-スクリプトの追加)Transform コンポーネントへの DataWeave スクリプトの追加 [変換](#transformations)​要素内で ​`CDATA`​ を使用して DataWeave コードを XML に入力するか、または外部の ​`.dwl`​ ファイルを参照できます。 この例では、​``​ 変換要素内で DataWeave スクリプトを作成しています。 ```xml ``` 次の例では、外部の ​`.dwl`​ ファイルを呼び出して同じ設定を行っています。 ```xml ``` これらのファイルは、デフォルトではプロジェクトの ​`src/main/resources`​ フォルダーにあります。 ## [](#transformations)変換 単一の Transform コンポーネント要素 (​``​) で、Mule イベントのすべての部分のコンテンツを指定できます。 - ``​ には、​``​ と ​``​ を定義できます。 - ``​ には、1 つまたは複数の ​``​ 要素を定義できます。 例 ```xml ``` 子要素には、同じ属性の一部を定義できます。
属性 説明

resource

DataWeave 変換スクリプトが格納された ​.dwl​ ファイルを参照します。これらの値は静的に解決されます。たとえば、​<ee:set-payload resource="myscript-${env}.dwl"/>​ を使用すると Transform Message UI で ​Unexpected end of input, expected header or content​ というエラーが発生します。

variableName

出力変数専用で、変数の名前を定義します。
## [](#完全な-xml-の例)完全な XML の例 ペイロード、属性、および変数の変換を作成する例です。 ```xml { id: value0.id, username: value0.username, address: { street: value0.address.street }, website: value0.website })]]> ``` ## [](#関連情報)関連情報 [DataWeave セレクター](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors) # Transform Message コンポーネントへの出力の追加 (Anypoint Studio) 単一の Transform Message コンポーネントにより、出力 Mule イベントの各部分 (ペイロード、変数、属性) を定義することができます。それぞれの異なる出力部分は、​``​ XML 要素内の個別の対象 XML 要素に、DataWeave コードの別のブロックとして定義する必要があります。Anypoint Studio 7 でこれを行うには、\[Transform (変換)\] ペインの個別のタブで DataWeave コードを作成します。たとえば、1 つのタブでペイロードを定義し、別のタブで属性を定義すると、これらはどちらも同じ出力 Mule イベントの一部となります。 新しい出力対象を追加する手順は次の通りです。 1. **\[Add new target (新規対象の追加)\]**​ をクリックします。 ![using dataweave in studio 34a3e](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/using-dataweave-in-studio-34a3e.png) 2. この新しい DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![新規変数](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/dw-new-variable.png) 複数の出力の実行順序が変わることがあります。各変換が実行順序や他の出力の影響を受けないようにしてください。 ## [](#transform-message-コンポーネントを設定-xml-ファイルで定義する方法)Transform Message コンポーネントを設定 XML ファイルで定義する方法 ペイロードは、​``​ 要素の子要素である ​``​ 要素で定義します。 ```xml ``` 属性は、​``​ 要素の子要素である ​``​ 要素でまとめて定義します。 ```xml ... ``` 各変数は、​``​ 親要素の子要素である ​``​ 要素で定義します。​``​ 要素は ​``​ 要素の直接の子であるため、​``​ 要素には含まれません。この XML 構造は、変数とメッセージが親イベントオブジェクトと一緒に保持されることを表しています。 Transform Message コンポーネント内で定義される変数対象の例を次に示します。 ```xml ... ``` ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about) [変換の出力対象の変更](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-change-target-output-transformation-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # Transform Message コンポーネントへの出力の追加 (Anypoint Studio) 単一の Transform Message コンポーネントにより、出力 Mule イベントの各部分 (ペイロード、変数、属性) を定義することができます。それぞれの異なる出力部分は、​``​ XML 要素内の個別の対象 XML 要素に、DataWeave コードの別のブロックとして定義する必要があります。Anypoint Studio 7 でこれを行うには、\[Transform (変換)\] ペインの個別のタブで DataWeave コードを作成します。たとえば、1 つのタブでペイロードを定義し、別のタブで属性を定義すると、これらはどちらも同じ出力 Mule イベントの一部となります。 新しい出力対象を追加する手順は次の通りです。 1. **\[Add new target (新規対象の追加)\]**​ をクリックします。 ![using dataweave in studio 34a3e](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/using-dataweave-in-studio-34a3e.png) 2. この新しい DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![新規変数](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/dw-new-variable.png) 複数の出力の実行順序が変わることがあります。各変換が実行順序や他の出力の影響を受けないようにしてください。 ## [](#transform-message-コンポーネントを設定-xml-ファイルで定義する方法)Transform Message コンポーネントを設定 XML ファイルで定義する方法 ペイロードは、​``​ 要素の子要素である ​``​ 要素で定義します。 ```xml ``` 属性は、​``​ 要素の子要素である ​``​ 要素でまとめて定義します。 ```xml ... ``` 各変数は、​``​ 親要素の子要素である ​``​ 要素で定義します。​``​ 要素は ​``​ 要素の直接の子であるため、​``​ 要素には含まれません。この XML 構造は、変数とメッセージが親イベントオブジェクトと一緒に保持されることを表しています。 Transform Message コンポーネント内で定義される変数対象の例を次に示します。 ```xml ... ``` ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about) [変換の出力対象の変更](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-change-target-output-transformation-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # Transform Message コンポーネントへの出力の追加 (Anypoint Studio) 単一の Transform Message コンポーネントにより、出力 Mule イベントの各部分 (ペイロード、変数、属性) を定義することができます。それぞれの異なる出力部分は、​``​ XML 要素内の個別の対象 XML 要素に、DataWeave コードの別のブロックとして定義する必要があります。Anypoint Studio 7 でこれを行うには、\[Transform (変換)\] ペインの個別のタブで DataWeave コードを作成します。たとえば、1 つのタブでペイロードを定義し、別のタブで属性を定義すると、これらはどちらも同じ出力 Mule イベントの一部となります。 新しい出力対象を追加する手順は次の通りです。 1. **\[Add new target (新規対象の追加)\]**​ をクリックします。 ![using dataweave in studio 34a3e](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/using-dataweave-in-studio-34a3e.png) 2. この新しい DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![新規変数](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/dw-new-variable.png) 複数の出力の実行順序が変わることがあります。各変換が実行順序や他の出力の影響を受けないようにしてください。 ## [](#transform-message-コンポーネントを設定-xml-ファイルで定義する方法)Transform Message コンポーネントを設定 XML ファイルで定義する方法 ペイロードは、​``​ 要素の子要素である ​``​ 要素で定義します。 ```xml ``` 属性は、​``​ 要素の子要素である ​``​ 要素でまとめて定義します。 ```xml ... ``` 各変数は、​``​ 親要素の子要素である ​``​ 要素で定義します。​``​ 要素は ​``​ 要素の直接の子であるため、​``​ 要素には含まれません。この XML 構造は、変数とメッセージが親イベントオブジェクトと一緒に保持されることを表しています。 Transform Message コンポーネント内で定義される変数対象の例を次に示します。 ```xml ... ``` ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about) [変換の出力対象の変更](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-change-target-output-transformation-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # Transform Message コンポーネントへの出力の追加 (Anypoint Studio) 単一の Transform Message コンポーネントにより、出力 Mule イベントの各部分 (ペイロード、変数、属性) を定義することができます。それぞれの異なる出力部分は、​``​ XML 要素内の個別の対象 XML 要素に、DataWeave コードの別のブロックとして定義する必要があります。Anypoint Studio 7 でこれを行うには、\[Transform (変換)\] ペインの個別のタブで DataWeave コードを作成します。たとえば、1 つのタブでペイロードを定義し、別のタブで属性を定義すると、これらはどちらも同じ出力 Mule イベントの一部となります。 新しい出力対象を追加する手順は次の通りです。 1. **\[Add new target (新規対象の追加)\]**​ をクリックします。 ![using dataweave in studio 34a3e](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/using-dataweave-in-studio-34a3e.png) 2. この新しい DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![新規変数](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/dw-new-variable.png) 複数の出力の実行順序が変わることがあります。各変換が実行順序や他の出力の影響を受けないようにしてください。 ## [](#transform-message-コンポーネントを設定-xml-ファイルで定義する方法)Transform Message コンポーネントを設定 XML ファイルで定義する方法 ペイロードは、​``​ 要素の子要素である ​``​ 要素で定義します。 ```xml ``` 属性は、​``​ 要素の子要素である ​``​ 要素でまとめて定義します。 ```xml ... ``` 各変数は、​``​ 親要素の子要素である ​``​ 要素で定義します。​``​ 要素は ​``​ 要素の直接の子であるため、​``​ 要素には含まれません。この XML 構造は、変数とメッセージが親イベントオブジェクトと一緒に保持されることを表しています。 Transform Message コンポーネント内で定義される変数対象の例を次に示します。 ```xml ... ``` ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about) [変換の出力対象の変更](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-change-target-output-transformation-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # Transform Message コンポーネントへの出力の追加 (Anypoint Studio) 単一の Transform Message コンポーネントにより、出力 Mule イベントの各部分 (ペイロード、変数、属性) を定義することができます。それぞれの異なる出力部分は、​``​ XML 要素内の個別の対象 XML 要素に、DataWeave コードの別のブロックとして定義する必要があります。Anypoint Studio 7 でこれを行うには、\[Transform (変換)\] ペインの個別のタブで DataWeave コードを作成します。たとえば、1 つのタブでペイロードを定義し、別のタブで属性を定義すると、これらはどちらも同じ出力 Mule イベントの一部となります。 新しい出力対象を追加する手順は次の通りです。 1. **\[Add new target (新規対象の追加)\]**​ をクリックします。 ![using dataweave in studio 34a3e](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/using-dataweave-in-studio-34a3e.png) 2. この新しい DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![ソースコードを選択するオプションが含まれる \[Selection dialog (選択ダイアログ)\] の出力](_images/dw-new-variable.png) 複数の出力の実行順序が変わることがあります。各変換が実行順序や他の出力の影響を受けないようにしてください。 ## [](#transform-message-コンポーネントを設定-xml-ファイルで定義する方法)Transform Message コンポーネントを設定 XML ファイルで定義する方法 ペイロードは、​``​ 要素の子要素である ​``​ 要素で定義します。 ```xml ``` 属性は、​``​ 要素の子要素である ​``​ 要素でまとめて定義します。 ```xml ... ``` 各変数は、​``​ 親要素の子要素である ​``​ 要素で定義します。​``​ 要素は ​``​ 要素の直接の子であるため、​``​ 要素には含まれません。この XML 構造は、変数とメッセージが親イベントオブジェクトと一緒に保持されることを表しています。 Transform Message コンポーネント内で定義される変数対象の例を次に示します。 ```xml ... ``` ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about) [変換の出力対象の変更](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-change-target-output-transformation-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # Transform Message コンポーネントへの出力の追加 (Anypoint Studio) 単一の Transform Message コンポーネントにより、出力 Mule イベントの各部分 (ペイロード、変数、属性) を定義することができます。それぞれの異なる出力部分は、​``​ XML 要素内の個別の対象 XML 要素に、DataWeave コードの別のブロックとして定義する必要があります。Anypoint Studio 7 でこれを行うには、\[Transform (変換)\] ペインの個別のタブで DataWeave コードを作成します。たとえば、1 つのタブでペイロードを定義し、別のタブで属性を定義すると、これらはどちらも同じ出力 Mule イベントの一部となります。 新しい出力対象を追加する手順は次の通りです。 1. **\[Add new target (新規対象の追加)\]**​ をクリックします。 ![追加アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/using-dataweave-in-studio-34a3e.png) 2. この新しい DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![ソースコードを選択するオプションが含まれる \[Selection dialog (選択ダイアログ)\] の出力](_images/dw-new-variable.png) 複数の出力の実行順序が変わることがあります。各変換が実行順序や他の出力の影響を受けないようにしてください。 ## [](#transform-message-コンポーネントを設定-xml-ファイルで定義する方法)Transform Message コンポーネントを設定 XML ファイルで定義する方法 ペイロードは、​``​ 要素の子要素である ​``​ 要素で定義します。 ```xml ``` 属性は、​``​ 要素の子要素である ​``​ 要素でまとめて定義します。 ```xml ... ``` 各変数は、​``​ 親要素の子要素である ​``​ 要素で定義します。​``​ 要素は ​``​ 要素の直接の子であるため、​``​ 要素には含まれません。この XML 構造は、変数とメッセージが親イベントオブジェクトと一緒に保持されることを表しています。 Transform Message コンポーネント内で定義される変数対象の例を次に示します。 ```xml ... ``` ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about) [変換の出力対象の変更](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-change-target-output-transformation-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # Transform Message コンポーネントへの出力の追加 (Anypoint Studio) 単一の Transform Message コンポーネントにより、出力 Mule イベントの各部分 (ペイロード、変数、属性) を定義することができます。それぞれの異なる出力部分は、​``​ XML 要素内の個別の対象 XML 要素に、DataWeave コードの別のブロックとして定義する必要があります。Anypoint Studio 7 でこれを行うには、\[Transform (変換)\] ペインの個別のタブで DataWeave コードを作成します。たとえば、1 つのタブでペイロードを定義し、別のタブで属性を定義すると、これらはどちらも同じ出力 Mule イベントの一部となります。 新しい出力対象を追加する手順は次の通りです。 1. **\[Add new target (新規対象の追加)\]**​ をクリックします。 ![追加アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/using-dataweave-in-studio-34a3e.png) 2. この新しい DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![ソースコードを選択するオプションが含まれる \[Selection dialog (選択ダイアログ)\] の出力](_images/dw-new-variable.png) 複数の出力の実行順序が変わることがあります。各変換が実行順序や他の出力の影響を受けないようにしてください。 ## [](#transform-message-コンポーネントを設定-xml-ファイルで定義する方法)Transform Message コンポーネントを設定 XML ファイルで定義する方法 ペイロードは、​``​ 要素の子要素である ​``​ 要素で定義します。 ```xml ``` 属性は、​``​ 要素の子要素である ​``​ 要素でまとめて定義します。 ```xml ... ``` 各変数は、​``​ 親要素の子要素である ​``​ 要素で定義します。​``​ 要素は ​``​ 要素の直接の子であるため、​``​ 要素には含まれません。この XML 構造は、変数とメッセージが親イベントオブジェクトと一緒に保持されることを表しています。 Transform Message コンポーネント内で定義される変数対象の例を次に示します。 ```xml ... ``` ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about) [変換の出力対象の変更](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-change-target-output-transformation-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # Try スコープ Try スコープを使用すると、Try スコープ内のコンポーネントの実行時に発生するエラーを処理できます。トランザクションもサポートします。Try スコープは、1 つまたは複数の操作をラップし、内部の操作がスローする例外をキャッチして処理します。まるで、エラー処理戦略が設定された別のフローにこれらのイベントコンポーネントを抽出したような動作となりますが、実際には新しいフローは定義せず、すべてインラインで処理を実行します。 ## [](#try-スコープでのエラー処理)Try スコープでのエラー処理 フローを設計するときは、Try スコープの内部でエラーが発生しやすい操作をグループ化するようにしてください。Try スコープにより、フローで問題を起こす可能性のある操作を隔離して、エラー処理メソッドに割り当てることができます。また、Try スコープ内の操作をトランザクションとして処理するように設定することもできます。 Try スコープはエラー処理戦略を持ち、フローのエラー処理を設定するのと同じように設定できます。 Try スコープは、さまざまなエラー種別の条件を見極めて、異なる動作を適用します。Try スコープ内のコンポーネントでエラーが発生すると、Try スコープのエラーハンドラーが実行されます。この時点で、エラーを調査することができ、ハンドラーは状況に応じて実行および動作できます。 - On Error Continue 実行後に結果をコンテナ Try スコープに送信します。コンテナ Try スコープは、渡された結果を使用して実行を正常に完了します。この時点でのトランザクションはすべてコミットされます。 - On Error Propagate すべてのトランザクションをロールバックし、実行後に結果を使用して既存のエラーを再びスローします。これにより、コンテナ Try スコープの実行は失敗します。 Try スコープの設定例 ![Try スコープでのエラー処理](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-try-scope.png) 前の例では、On Error Propagate (エラー時伝播) (​`on-error-propagate`​) エラーハンドラーによってデータベース接続エラー (​`DB:CONNECTIVITY`​) が伝播されます。このエラーの伝播により、Try スコープの実行は失敗し、フローのエラーハンドラーが実行されます。他のエラーは On Error Continue (エラー時続行) (​`on-error-continue`​) エラーハンドラーによって処理されるため、これらのエラーの発生時には Try スコープの実行は成功したように扱われ、次の操作である HTTP 要求が実行を続行します。 Try スコープに複数のコンポーネントがある場合、1 つのコンポーネントが例外をスローすると、例外をキャッチしたエラーハンドラーの種別には関係なく、Try スコープ内の以降のコンポーネントは実行されません。On Error Propagate (エラー時伝播) の場合、まるで Try スコープが存在しないかのように、エラーがフローのエラーハンドラーに伝播されます。On Error Continue (エラー時続行) の場合は、まるで Try スコープが例外をスローしなかったかのように、Try スコープ外部の次のフローコンポーネントから処理が続行します。 ## [](#トランザクションの処理)トランザクションの処理 トランザクションとは、絶対に部分的には実行されない一連のアクションです。エラーが伝播されてトランザクションがロールバックされるか、またはエラーが処理されてトランザクションがコミットされるかによって 1 つの単位として成功または失敗を判断する複数の操作が 1 つのセットになるように Try スコープを設定します。どちらの場合でも、Try スコープが存在するプロセスフローは処理を続行します。 ![Try スコープの設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-try-scope-config.png) トランザクションアクション (​`transactionalAction`​) が ​`ALWAYS_BEGIN`​ または ​`BEGIN_OR_JOIN`​ に設定されている場合、Try スコープは、子操作をトランザクションとして扱います。次のように設定できます。 - Ignore (無視) (​`INDIFFERENT`​) デフォルト。トランザクションがアクティブであれば、スコープがトランザクションに結合します。そうでない場合は、スコープはトランザクションを作成しません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) スコープを実行する度に、新しいトランザクションが開始されます。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) 実行順序が (フロー外で発生する非同期アクションなどによって) 変化する場合にのみ適用されます。 フローの現在の処理ですでにトランザクションが開始されている場合は、スコープはそのトランザクションに結合します。そうでない場合は、スコープは新しいトランザクションを開始します。 ### [](#try-スコープでの異なるトランザクションアクションの分析)Try スコープでの異なるトランザクションアクションの分析 次の例は、フローレベルでトランザクションを開始するように設定された ​`jms:listener`​ 操作、トランザクションを (設定に従って) 開始または結合しようとする Try スコープ、そしてトランザクションの外部で実行するように設定された ​`jms:publish`​ 操作を示しています。 ```xml ``` Try スコープ内の操作でエラーが発生しなければ、設定されている ​`transactionalAction`​ 値には関係なく、スコープは実行を完了してトランザクションをコミットします。 ``​ コンポーネントが追加されると、Try スコープの ​`transactionalAction`​ によってトランザクションとメッセージの処理方法が変わります。 - Ignore (無視) (​`INDIFFERENT`​) この場合は、Try スコープ内で操作を実行しながらトランザクションが継続します。エラーが発生すると、ソースに伝播されます (​``​ エラーハンドラーでは処理しません)。トランザクションがロールバックされ、メッセージが JMS キューで再び使用できるようになります。このロールバックは、すでに完了している ​`jms:publish`​ 操作には影響しません。​`transactionAction`​ がデフォルトの ​`NOT_SUPPORTED`​ に設定されているため、この操作はトランザクションスコープの外部となります。 `transactionAction`​ が ​`JOIN_IF_POSSIBLE`​ に設定されていれば、​`jms:publish`​ 操作もロールバックされます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) この場合は、すでにトランザクションが開始されているため、スコープはアクティブなトランザクションに結合します。結果は ​`INDIFFERENT`​ の場合と同じです。 #### [](#フローレベルでのエラーハンドラー)フローレベルでのエラーハンドラー 次の例では、エラーハンドラーをフローレベルで追加しています。 ```xml ``` この例の動作は次のようになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行します。エラーは ​`on-error-continue`​ エラーハンドラーで処理されるため、トランザクションはコミットされます。​`jms:listener`​ ソースから読み出されたメッセージはコンシュームされ、​`jms:publish`​ 操作で処理されたメッセージが実際に送信されます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 #### [](#try-スコープ内のエラーハンドラー)Try スコープ内のエラーハンドラー この場合は、エラーハンドラーが Try スコープ内にあり、スコープの実行後にエラーが発生します。 ```xml ``` 設定されている ​`transactionalAction`​ に従って、Try スコープ内の動作は次のいずれかになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行しますが、エラーはフローレベルの ​`on-error-continue`​ では処理されないため、トランザクションがロールバックされ、メッセージは送信されません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 ### [](#ローカルまたは-xa-トランザクションの設定)ローカルまたは XA トランザクションの設定 トランザクションアクションの設定に加えて、トランザクション種別をローカル (単一リソース) または XA トランザクションに設定できます。 Try スコープは、新しいトランザクションが作成されたときのみ、トランザクション種別設定を使用します。トランザクションの実行中は種別を変更できません。 動作はトランザクションアクションごとに変わります。 - Ignore (無視) (​`INDIFFERENT`​) すでに作成されているトランザクションを使用します (存在する場合)。このトランザクションアクションでは、トランザクション種別を設定しても何も変わりません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) トランザクションは、トランザクション種別設定で指定されている種別で作成されます。単一リソーストランザクション内での実行中は、​`ALWAYS_BEGIN`​ は無効な設定になることを忘れないでください。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) トランザクションがすでに作成されていれば、​`INDIFFERENT`​ の場合と同じように、トランザクション種別を設定しても何も変わりません。トランザクションが存在しない場合は、​`ALWAYS_BEGIN`​ の場合と同じように、トランザクション種別で指定されている種別のトランザクションが作成されます。 ## [](#変数とペイロードの伝播)変数とペイロードの伝播 ペイロードを変更したり、変数を追加、変更、または削除したりすると、実行の残りの部分に伝播されます。エラーハンドラー内での変更も伝播されます。 ## [](#関連情報)関連情報 - [Try スコープ XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-xml-reference) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management) # Try スコープ Try スコープを使用すると、Try スコープ内のコンポーネントの実行時に発生するエラーを処理できます。トランザクションもサポートします。Try スコープは、1 つまたは複数の操作をラップし、内部の操作がスローする例外をキャッチして処理します。まるで、エラー処理戦略が設定された別のフローにこれらのイベントコンポーネントを抽出したような動作となりますが、実際には新しいフローは定義せず、すべてインラインで処理を実行します。 ## [](#try-スコープでのエラー処理)Try スコープでのエラー処理 フローを設計するときは、Try スコープの内部でエラーが発生しやすい操作をグループ化するようにしてください。Try スコープにより、フローで問題を起こす可能性のある操作を隔離して、エラー処理メソッドに割り当てることができます。また、Try スコープ内の操作をトランザクションとして処理するように設定することもできます。 Try スコープはエラー処理戦略を持ち、フローのエラー処理を設定するのと同じように設定できます。 Try スコープは、さまざまなエラー種別の条件を見極めて、異なる動作を適用します。Try スコープ内のコンポーネントでエラーが発生すると、Try スコープのエラーハンドラーが実行されます。この時点で、エラーを調査することができ、ハンドラーは状況に応じて実行および動作できます。 - On Error Continue 実行後に結果をコンテナ Try スコープに送信します。コンテナ Try スコープは、渡された結果を使用して実行を正常に完了します。この時点でのトランザクションはすべてコミットされます。 - On Error Propagate すべてのトランザクションをロールバックし、実行後に結果を使用して既存のエラーを再びスローします。これにより、コンテナ Try スコープの実行は失敗します。 Try スコープの設定例 ![Try スコープでのエラー処理](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-try-scope.png) 前の例では、On Error Propagate (エラー時伝播) (​`on-error-propagate`​) エラーハンドラーによってデータベース接続エラー (​`DB:CONNECTIVITY`​) が伝播されます。このエラーの伝播により、Try スコープの実行は失敗し、フローのエラーハンドラーが実行されます。他のエラーは On Error Continue (エラー時続行) (​`on-error-continue`​) エラーハンドラーによって処理されるため、これらのエラーの発生時には Try スコープの実行は成功したように扱われ、次の操作である HTTP 要求が実行を続行します。 Try スコープに複数のコンポーネントがある場合、1 つのコンポーネントが例外をスローすると、例外をキャッチしたエラーハンドラーの種別には関係なく、Try スコープ内の以降のコンポーネントは実行されません。On Error Propagate (エラー時伝播) の場合、まるで Try スコープが存在しないかのように、エラーがフローのエラーハンドラーに伝播されます。On Error Continue (エラー時続行) の場合は、まるで Try スコープが例外をスローしなかったかのように、Try スコープ外部の次のフローコンポーネントから処理が続行します。 ## [](#トランザクションの処理)トランザクションの処理 トランザクションとは、絶対に部分的には実行されない一連のアクションです。エラーが伝播されてトランザクションがロールバックされるか、またはエラーが処理されてトランザクションがコミットされるかによって 1 つの単位として成功または失敗を判断する複数の操作が 1 つのセットになるように Try スコープを設定します。どちらの場合でも、Try スコープが存在するプロセスフローは処理を続行します。 ![Try スコープの設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-try-scope-config.png) トランザクションアクション (​`transactionalAction`​) が ​`ALWAYS_BEGIN`​ または ​`BEGIN_OR_JOIN`​ に設定されている場合、Try スコープは、子操作をトランザクションとして扱います。次のように設定できます。 - Ignore (無視) (​`INDIFFERENT`​) デフォルト。トランザクションがアクティブであれば、スコープがトランザクションに結合します。そうでない場合は、スコープはトランザクションを作成しません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) スコープを実行する度に、新しいトランザクションが開始されます。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) 実行順序が (フロー外で発生する非同期アクションなどによって) 変化する場合にのみ適用されます。 フローの現在の処理ですでにトランザクションが開始されている場合は、スコープはそのトランザクションに結合します。そうでない場合は、スコープは新しいトランザクションを開始します。 ### [](#try-スコープでの異なるトランザクションアクションの分析)Try スコープでの異なるトランザクションアクションの分析 次の例は、フローレベルでトランザクションを開始するように設定された ​`jms:listener`​ 操作、トランザクションを (設定に従って) 開始または結合しようとする Try スコープ、そしてトランザクションの外部で実行するように設定された ​`jms:publish`​ 操作を示しています。 ```xml ``` Try スコープ内の操作でエラーが発生しなければ、設定されている ​`transactionalAction`​ 値には関係なく、スコープは実行を完了してトランザクションをコミットします。 ``​ コンポーネントが追加されると、Try スコープの ​`transactionalAction`​ によってトランザクションとメッセージの処理方法が変わります。 - Ignore (無視) (​`INDIFFERENT`​) この場合は、Try スコープ内で操作を実行しながらトランザクションが継続します。エラーが発生すると、ソースに伝播されます (​``​ エラーハンドラーでは処理しません)。トランザクションがロールバックされ、メッセージが JMS キューで再び使用できるようになります。このロールバックは、すでに完了している ​`jms:publish`​ 操作には影響しません。​`transactionAction`​ がデフォルトの ​`NOT_SUPPORTED`​ に設定されているため、この操作はトランザクションスコープの外部となります。 `transactionAction`​ が ​`JOIN_IF_POSSIBLE`​ に設定されていれば、​`jms:publish`​ 操作もロールバックされます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) この場合は、すでにトランザクションが開始されているため、スコープはアクティブなトランザクションに結合します。結果は ​`INDIFFERENT`​ の場合と同じです。 #### [](#フローレベルでのエラーハンドラー)フローレベルでのエラーハンドラー 次の例では、エラーハンドラーをフローレベルで追加しています。 ```xml ``` この例の動作は次のようになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行します。エラーは ​`on-error-continue`​ エラーハンドラーで処理されるため、トランザクションはコミットされます。​`jms:listener`​ ソースから読み出されたメッセージはコンシュームされ、​`jms:publish`​ 操作で処理されたメッセージが実際に送信されます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 #### [](#try-スコープ内のエラーハンドラー)Try スコープ内のエラーハンドラー この場合は、エラーハンドラーが Try スコープ内にあり、スコープの実行後にエラーが発生します。 ```xml ``` 設定されている ​`transactionalAction`​ に従って、Try スコープ内の動作は次のいずれかになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行しますが、エラーはフローレベルの ​`on-error-continue`​ では処理されないため、トランザクションがロールバックされ、メッセージは送信されません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 ### [](#ローカルまたは-xa-トランザクションの設定)ローカルまたは XA トランザクションの設定 トランザクションアクションの設定に加えて、トランザクション種別をローカル (単一リソース) または XA トランザクションに設定できます。 Try スコープは、新しいトランザクションが作成されたときのみ、トランザクション種別設定を使用します。トランザクションの実行中は種別を変更できません。 動作はトランザクションアクションごとに変わります。 - Ignore (無視) (​`INDIFFERENT`​) すでに作成されているトランザクションを使用します (存在する場合)。このトランザクションアクションでは、トランザクション種別を設定しても何も変わりません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) トランザクションは、トランザクション種別設定で指定されている種別で作成されます。単一リソーストランザクション内での実行中は、​`ALWAYS_BEGIN`​ は無効な設定になることを忘れないでください。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) トランザクションがすでに作成されていれば、​`INDIFFERENT`​ の場合と同じように、トランザクション種別を設定しても何も変わりません。トランザクションが存在しない場合は、​`ALWAYS_BEGIN`​ の場合と同じように、トランザクション種別で指定されている種別のトランザクションが作成されます。 ## [](#変数とペイロードの伝播)変数とペイロードの伝播 ペイロードを変更したり、変数を追加、変更、または削除したりすると、実行の残りの部分に伝播されます。エラーハンドラー内での変更も伝播されます。 ## [](#関連情報)関連情報 - [Try スコープ XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-xml-reference) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management) # Try スコープ Try スコープを使用すると、Try スコープ内のコンポーネントの実行時に発生するエラーを処理できます。トランザクションもサポートします。Try スコープは、1 つまたは複数の操作をラップし、内部の操作がスローする例外をキャッチして処理します。まるで、エラー処理戦略が設定された別のフローにこれらのイベントコンポーネントを抽出したような動作となりますが、実際には新しいフローは定義せず、すべてインラインで処理を実行します。 ## [](#try-スコープでのエラー処理)Try スコープでのエラー処理 フローを設計するときは、Try スコープの内部でエラーが発生しやすい操作をグループ化するようにしてください。Try スコープにより、フローで問題を起こす可能性のある操作を隔離して、エラー処理メソッドに割り当てることができます。また、Try スコープ内の操作をトランザクションとして処理するように設定することもできます。 Try スコープはエラー処理戦略を持ち、フローのエラー処理を設定するのと同じように設定できます。 Try スコープは、さまざまなエラー種別の条件を見極めて、異なる動作を適用します。Try スコープ内のコンポーネントでエラーが発生すると、Try スコープのエラーハンドラーが実行されます。この時点で、エラーを調査することができ、ハンドラーは状況に応じて実行および動作できます。 - On Error Continue 実行後に結果をコンテナ Try スコープに送信します。コンテナ Try スコープは、渡された結果を使用して実行を正常に完了します。この時点でのトランザクションはすべてコミットされます。 - On Error Propagate すべてのトランザクションをロールバックし、実行後に結果を使用して既存のエラーを再びスローします。これにより、コンテナ Try スコープの実行は失敗します。 Try スコープの設定例 ![Try スコープでのエラー処理](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-try-scope.png) 前の例では、On Error Propagate (エラー時伝播) (​`on-error-propagate`​) エラーハンドラーによってデータベース接続エラー (​`DB:CONNECTIVITY`​) が伝播されます。このエラーの伝播により、Try スコープの実行は失敗し、フローのエラーハンドラーが実行されます。他のエラーは On Error Continue (エラー時続行) (​`on-error-continue`​) エラーハンドラーによって処理されるため、これらのエラーの発生時には Try スコープの実行は成功したように扱われ、次の操作である HTTP 要求が実行を続行します。 Try スコープに複数のコンポーネントがある場合、1 つのコンポーネントが例外をスローすると、例外をキャッチしたエラーハンドラーの種別には関係なく、Try スコープ内の以降のコンポーネントは実行されません。On Error Propagate (エラー時伝播) の場合、まるで Try スコープが存在しないかのように、エラーがフローのエラーハンドラーに伝播されます。On Error Continue (エラー時続行) の場合は、まるで Try スコープが例外をスローしなかったかのように、Try スコープ外部の次のフローコンポーネントから処理が続行します。 ## [](#トランザクションの処理)トランザクションの処理 トランザクションとは、絶対に部分的には実行されない一連のアクションです。エラーが伝播されてトランザクションがロールバックされるか、またはエラーが処理されてトランザクションがコミットされるかによって 1 つの単位として成功または失敗を判断する複数の操作が 1 つのセットになるように Try スコープを設定します。どちらの場合でも、Try スコープが存在するプロセスフローは処理を続行します。 ![Try スコープの設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-try-scope-config.png) トランザクションアクション (​`transactionalAction`​) が ​`ALWAYS_BEGIN`​ または ​`BEGIN_OR_JOIN`​ に設定されている場合、Try スコープは、子操作をトランザクションとして扱います。次のように設定できます。 - Ignore (無視) (​`INDIFFERENT`​) デフォルト。トランザクションが有効であれば、スコープがトランザクションに結合します。そうでない場合は、スコープはトランザクションを作成しません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) スコープを実行する度に、新しいトランザクションが開始されます。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) 実行順序が (フロー外で発生する非同期アクションなどによって) 変化する場合にのみ適用されます。 フローの現在の処理ですでにトランザクションが開始されている場合は、スコープはそのトランザクションに結合します。そうでない場合は、スコープは新しいトランザクションを開始します。 ### [](#try-スコープでの異なるトランザクションアクションの分析)Try スコープでの異なるトランザクションアクションの分析 次の例は、フローレベルでトランザクションを開始するように設定された ​`jms:listener`​ 操作、トランザクションを (設定に従って) 開始または結合しようとする Try スコープ、そしてトランザクションの外部で実行するように設定された ​`jms:publish`​ 操作を示しています。 ```xml ``` Try スコープ内の操作でエラーが発生しなければ、設定されている ​`transactionalAction`​ 値には関係なく、スコープは実行を完了してトランザクションをコミットします。 ``​ コンポーネントが追加されると、Try スコープの ​`transactionalAction`​ によってトランザクションとメッセージの処理方法が変わります。 - Ignore (無視) (​`INDIFFERENT`​) この場合は、Try スコープ内で操作を実行しながらトランザクションが継続します。エラーが発生すると、接続元に伝播されます (​``​ エラーハンドラーでは処理しません)。トランザクションがロールバックされ、メッセージが JMS キューで再び使用できるようになります。このロールバックは、すでに完了している ​`jms:publish`​ 操作には影響しません。​`transactionAction`​ がデフォルトの ​`NOT_SUPPORTED`​ に設定されているため、この操作はトランザクションスコープの外部となります。 `transactionAction`​ が ​`JOIN_IF_POSSIBLE`​ に設定されていれば、​`jms:publish`​ 操作もロールバックされます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) 有効なトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) この場合は、すでにトランザクションが開始されているため、スコープは有効なトランザクションに結合します。結果は ​`INDIFFERENT`​ の場合と同じです。 #### [](#フローレベルでのエラーハンドラー)フローレベルでのエラーハンドラー 次の例では、エラーハンドラーをフローレベルで追加しています。 ```xml ``` この例の動作は次のようになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行します。エラーは ​`on-error-continue`​ エラーハンドラーで処理されるため、トランザクションはコミットされます。​`jms:listener`​ 接続元から読み出されたメッセージはコンシュームされ、​`jms:publish`​ 操作で処理されたメッセージが実際に送信されます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) 有効なトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 #### [](#try-スコープ内のエラーハンドラー)Try スコープ内のエラーハンドラー この場合は、エラーハンドラーが Try スコープ内にあり、スコープの実行後にエラーが発生します。 ```xml ``` 設定されている ​`transactionalAction`​ に従って、Try スコープ内の動作は次のいずれかになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行しますが、エラーはフローレベルの ​`on-error-continue`​ では処理されないため、トランザクションがロールバックされ、メッセージは送信されません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) 有効なトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 ### [](#ローカルまたは-xa-トランザクションの設定)ローカルまたは XA トランザクションの設定 トランザクションアクションの設定に加えて、トランザクション種別をローカル (単一リソース) または XA トランザクションに設定できます。 Try スコープは、新しいトランザクションが作成されたときのみ、トランザクション種別設定を使用します。トランザクションの実行中は種別を変更できません。 動作はトランザクションアクションごとに変わります。 - Ignore (無視) (​`INDIFFERENT`​) すでに作成されているトランザクションを使用します (存在する場合)。このトランザクションアクションでは、トランザクション種別を設定しても何も変わりません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) トランザクションは、トランザクション種別設定で指定されている種別で作成されます。単一リソーストランザクション内での実行中は、​`ALWAYS_BEGIN`​ は無効な設定になることを忘れないでください。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) トランザクションがすでに作成されていれば、​`INDIFFERENT`​ の場合と同じように、トランザクション種別を設定しても何も変わりません。トランザクションが存在しない場合は、​`ALWAYS_BEGIN`​ の場合と同じように、トランザクション種別で指定されている種別のトランザクションが作成されます。 ## [](#変数とペイロードの伝播)変数とペイロードの伝播 ペイロードを変更したり、変数を追加、変更、または削除したりすると、実行の残りの部分に伝播されます。エラーハンドラー内での変更も伝播されます。 ## [](#関連情報)関連情報 - [Try スコープ XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-xml-reference) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management) # Try スコープ Try スコープを使用すると、Try スコープ内のコンポーネントの実行時に発生するエラーを処理できます。トランザクションもサポートします。Try スコープは、1 つまたは複数の操作をラップし、内部の操作がスローする例外をキャッチして処理します。まるで、エラー処理戦略が設定された別のフローにこれらのイベントコンポーネントを抽出したような動作となりますが、実際には新しいフローは定義せず、すべてインラインで処理を実行します。 ## [](#try-スコープでのエラー処理)Try スコープでのエラー処理 フローを設計するときは、Try スコープの内部でエラーが発生しやすい操作をグループ化するようにしてください。Try スコープにより、フローで問題を起こす可能性のある操作を隔離して、エラー処理メソッドに割り当てることができます。また、Try スコープ内の操作をトランザクションとして処理するように設定することもできます。 Try スコープはエラー処理戦略を持ち、フローのエラー処理を設定するのと同じように設定できます。 Try スコープは、さまざまなエラー種別の条件を見極めて、異なる動作を適用します。Try スコープ内のコンポーネントでエラーが発生すると、Try スコープのエラーハンドラーが実行されます。この時点で、エラーを調査することができ、ハンドラーは状況に応じて実行および動作できます。 - On Error Continue 実行後に結果をコンテナ Try スコープに送信します。コンテナ Try スコープは、渡された結果を使用して実行を正常に完了します。この時点でのトランザクションはすべてコミットされます。 - On Error Propagate すべてのトランザクションをロールバックし、実行後に結果を使用して既存のエラーを再びスローします。これにより、コンテナ Try スコープの実行は失敗します。 Try スコープの設定例 ![Try スコープでのエラー処理](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-try-scope.png) 前の例では、On Error Propagate (エラー時伝播) (​`on-error-propagate`​) エラーハンドラーによってデータベース接続エラー (​`DB:CONNECTIVITY`​) が伝播されます。このエラーの伝播により、Try スコープの実行は失敗し、フローのエラーハンドラーが実行されます。他のエラーは On Error Continue (エラー時続行) (​`on-error-continue`​) エラーハンドラーによって処理されるため、これらのエラーの発生時には Try スコープの実行は成功したように扱われ、次の操作である HTTP 要求が実行を続行します。 Try スコープに複数のコンポーネントがある場合、1 つのコンポーネントが例外をスローすると、例外をキャッチしたエラーハンドラーの種別には関係なく、Try スコープ内の以降のコンポーネントは実行されません。On Error Propagate (エラー時伝播) の場合、まるで Try スコープが存在しないかのように、エラーがフローのエラーハンドラーに伝播されます。On Error Continue (エラー時続行) の場合は、まるで Try スコープが例外をスローしなかったかのように、Try スコープ外部の次のフローコンポーネントから処理が続行します。 ## [](#トランザクションの処理)トランザクションの処理 トランザクションとは、絶対に部分的には実行されない一連のアクションです。エラーが伝播されてトランザクションがロールバックされるか、またはエラーが処理されてトランザクションがコミットされるかによって 1 つの単位として成功または失敗を判断する複数の操作が 1 つのセットになるように Try スコープを設定します。どちらの場合でも、Try スコープが存在するプロセスフローは処理を続行します。 ![Try スコープの設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-try-scope-config.png) トランザクションアクション (​`transactionalAction`​) が ​`ALWAYS_BEGIN`​ または ​`BEGIN_OR_JOIN`​ に設定されている場合、Try スコープは、子操作をトランザクションとして扱います。次のように設定できます。 - Ignore (無視) (​`INDIFFERENT`​) デフォルト。トランザクションがアクティブであれば、スコープがトランザクションに結合します。そうでない場合は、スコープはトランザクションを作成しません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) スコープを実行する度に、新しいトランザクションが開始されます。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) 実行順序が (フロー外で発生する非同期アクションなどによって) 変化する場合にのみ適用されます。 フローの現在の処理ですでにトランザクションが開始されている場合は、スコープはそのトランザクションに結合します。そうでない場合は、スコープは新しいトランザクションを開始します。 ### [](#try-スコープでの異なるトランザクションアクションの分析)Try スコープでの異なるトランザクションアクションの分析 次の例は、フローレベルでトランザクションを開始するように設定された ​`jms:listener`​ 操作、トランザクションを (設定に従って) 開始または結合しようとする Try スコープ、そしてトランザクションの外部で実行するように設定された ​`jms:publish`​ 操作を示しています。 ```xml ``` Try スコープ内の操作でエラーが発生しなければ、設定されている ​`transactionalAction`​ 値には関係なく、スコープは実行を完了してトランザクションをコミットします。 ``​ コンポーネントが追加されると、Try スコープの ​`transactionalAction`​ によってトランザクションとメッセージの処理方法が変わります。 - Ignore (無視) (​`INDIFFERENT`​) この場合は、Try スコープ内で操作を実行しながらトランザクションが継続します。エラーが発生すると、接続元に伝播されます (​``​ エラーハンドラーでは処理しません)。トランザクションがロールバックされ、メッセージが JMS キューで再び使用できるようになります。このロールバックは、すでに完了している ​`jms:publish`​ 操作には影響しません。​`transactionAction`​ がデフォルトの ​`NOT_SUPPORTED`​ に設定されているため、この操作はトランザクションスコープの外部となります。 `transactionAction`​ が ​`JOIN_IF_POSSIBLE`​ に設定されていれば、​`jms:publish`​ 操作もロールバックされます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) この場合は、すでにトランザクションが開始されているため、スコープはアクティブなトランザクションに結合します。結果は ​`INDIFFERENT`​ の場合と同じです。 #### [](#フローレベルでのエラーハンドラー)フローレベルでのエラーハンドラー 次の例では、エラーハンドラーをフローレベルで追加しています。 ```xml ``` この例の動作は次のようになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行します。エラーは ​`on-error-continue`​ エラーハンドラーで処理されるため、トランザクションはコミットされます。​`jms:listener`​ 接続元から読み出されたメッセージはコンシュームされ、​`jms:publish`​ 操作で処理されたメッセージが実際に送信されます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 #### [](#try-スコープ内のエラーハンドラー)Try スコープ内のエラーハンドラー この場合は、エラーハンドラーが Try スコープ内にあり、スコープの実行後にエラーが発生します。 ```xml ``` 設定されている ​`transactionalAction`​ に従って、Try スコープ内の動作は次のいずれかになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行しますが、エラーはフローレベルの ​`on-error-continue`​ では処理されないため、トランザクションがロールバックされ、メッセージは送信されません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 ### [](#ローカルまたは-xa-トランザクションの設定)ローカルまたは XA トランザクションの設定 トランザクションアクションの設定に加えて、トランザクション種別をローカル (単一リソース) または XA トランザクションに設定できます。 Try スコープは、新しいトランザクションが作成されたときのみ、トランザクション種別設定を使用します。トランザクションの実行中は種別を変更できません。 動作はトランザクションアクションごとに変わります。 - Ignore (無視) (​`INDIFFERENT`​) すでに作成されているトランザクションを使用します (存在する場合)。このトランザクションアクションでは、トランザクション種別を設定しても何も変わりません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) トランザクションは、トランザクション種別設定で指定されている種別で作成されます。単一リソーストランザクション内での実行中は、​`ALWAYS_BEGIN`​ は無効な設定になることを忘れないでください。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) トランザクションがすでに作成されていれば、​`INDIFFERENT`​ の場合と同じように、トランザクション種別を設定しても何も変わりません。トランザクションが存在しない場合は、​`ALWAYS_BEGIN`​ の場合と同じように、トランザクション種別で指定されている種別のトランザクションが作成されます。 ## [](#変数とペイロードの伝播)変数とペイロードの伝播 ペイロードを変更したり、変数を追加、変更、または削除したりすると、実行の残りの部分に伝播されます。エラーハンドラー内での変更も伝播されます。 ## [](#関連情報)関連情報 - [Try スコープ XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-xml-reference) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management) # Try スコープ Try スコープを使用すると、Try スコープ内のコンポーネントの実行時に発生するエラーを処理できます。トランザクションもサポートします。Try スコープは、1 つまたは複数の操作をラップし、内部の操作がスローする例外をキャッチして処理します。まるで、エラー処理戦略が設定された別のフローにこれらのイベントコンポーネントを抽出したような動作となりますが、実際には新しいフローは定義せず、すべてインラインで処理を実行します。 ## [](#try-スコープでのエラー処理)Try スコープでのエラー処理 フローを設計するときは、Try スコープの内部でエラーが発生しやすい操作をグループ化するようにしてください。Try スコープにより、フローで問題を起こす可能性のある操作を隔離して、エラー処理メソッドに割り当てることができます。また、Try スコープ内の操作をトランザクションとして処理するように設定することもできます。 Try スコープはエラー処理戦略を持ち、フローのエラー処理を設定するのと同じように設定できます。 Try スコープは、さまざまなエラー種別の条件を見極めて、異なる動作を適用します。Try スコープ内のコンポーネントでエラーが発生すると、Try スコープのエラーハンドラーが実行されます。この時点で、エラーを調査することができ、ハンドラーは状況に応じて実行および動作できます。 - On Error Continue 実行後に結果をコンテナ Try スコープに送信します。コンテナ Try スコープは、渡された結果を使用して実行を正常に完了します。この時点でのトランザクションはすべてコミットされます。 - On Error Propagate すべてのトランザクションをロールバックし、実行後に結果を使用して既存のエラーを再びスローします。これにより、コンテナ Try スコープの実行は失敗します。 Try スコープの設定例 ![エラー処理オプションが含まれる Try スコープ設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-try-scope.png) 前の例では、On Error Propagate (エラー時伝播) (​`on-error-propagate`​) エラーハンドラーによってデータベース接続エラー (​`DB:CONNECTIVITY`​) が伝播されます。このエラーの伝播により、Try スコープの実行は失敗し、フローのエラーハンドラーが実行されます。他のエラーは On Error Continue (エラー時続行) (​`on-error-continue`​) エラーハンドラーによって処理されるため、これらのエラーの発生時には Try スコープの実行は成功したように扱われ、次の操作である HTTP 要求が実行を続行します。 Try スコープに複数のコンポーネントがある場合、1 つのコンポーネントが例外をスローすると、例外をキャッチしたエラーハンドラーの種別には関係なく、Try スコープ内の以降のコンポーネントは実行されません。On Error Propagate (エラー時伝播) の場合、まるで Try スコープが存在しないかのように、エラーがフローのエラーハンドラーに伝播されます。On Error Continue (エラー時続行) の場合は、まるで Try スコープが例外をスローしなかったかのように、Try スコープ外部の次のフローコンポーネントから処理が続行します。 ## [](#トランザクションの処理)トランザクションの処理 トランザクションとは、絶対に部分的には実行されない一連のアクションです。エラーが伝播されてトランザクションがロールバックされるか、またはエラーが処理されてトランザクションがコミットされるかによって 1 つの単位として成功または失敗を判断する複数の操作が 1 つのセットになるように Try スコープを設定します。どちらの場合でも、Try スコープが存在するプロセスフローは処理を続行します。 ![トランザクション設定が含まれる Mule の Try スコープの設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-try-scope-config.png) トランザクションアクション (​`transactionalAction`​) が ​`ALWAYS_BEGIN`​ または ​`BEGIN_OR_JOIN`​ に設定されている場合、Try スコープは、子操作をトランザクションとして扱います。次のように設定できます。 - Ignore (無視) (​`INDIFFERENT`​) デフォルト。トランザクションがアクティブであれば、スコープがトランザクションに結合します。そうでない場合は、スコープはトランザクションを作成しません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) スコープを実行する度に、新しいトランザクションが開始されます。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) 実行順序が (フロー外で発生する非同期アクションなどによって) 変化する場合にのみ適用されます。 フローの現在の処理ですでにトランザクションが開始されている場合は、スコープはそのトランザクションに結合します。そうでない場合は、スコープは新しいトランザクションを開始します。 ### [](#try-スコープでの異なるトランザクションアクションの分析)Try スコープでの異なるトランザクションアクションの分析 次の例は、フローレベルでトランザクションを開始するように設定された ​`jms:listener`​ 操作、トランザクションを (設定に従って) 開始または結合しようとする Try スコープ、そしてトランザクションの外部で実行するように設定された ​`jms:publish`​ 操作を示しています。 ```xml ``` Try スコープ内の操作でエラーが発生しなければ、設定されている ​`transactionalAction`​ 値には関係なく、スコープは実行を完了してトランザクションをコミットします。 ``​ コンポーネントが追加されると、Try スコープの ​`transactionalAction`​ によってトランザクションとメッセージの処理方法が変わります。 - Ignore (無視) (​`INDIFFERENT`​) この場合は、Try スコープ内で操作を実行しながらトランザクションが継続します。エラーが発生すると、接続元に伝播されます (​``​ エラーハンドラーでは処理しません)。トランザクションがロールバックされ、メッセージが JMS キューで再び使用できるようになります。このロールバックは、すでに完了している ​`jms:publish`​ 操作には影響しません。​`transactionAction`​ がデフォルトの ​`NOT_SUPPORTED`​ に設定されているため、この操作はトランザクションスコープの外部となります。 `transactionAction`​ が ​`JOIN_IF_POSSIBLE`​ に設定されていれば、​`jms:publish`​ 操作もロールバックされます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) この場合は、すでにトランザクションが開始されているため、スコープはアクティブなトランザクションに結合します。結果は ​`INDIFFERENT`​ の場合と同じです。 #### [](#フローレベルでのエラーハンドラー)フローレベルでのエラーハンドラー 次の例では、エラーハンドラーをフローレベルで追加しています。 ```xml ``` この例の動作は次のようになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行します。エラーは ​`on-error-continue`​ エラーハンドラーで処理されるため、トランザクションはコミットされます。​`jms:listener`​ 接続元から読み出されたメッセージはコンシュームされ、​`jms:publish`​ 操作で処理されたメッセージが実際に送信されます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 #### [](#try-スコープ内のエラーハンドラー)Try スコープ内のエラーハンドラー この場合は、エラーハンドラーが Try スコープ内にあり、スコープの実行後にエラーが発生します。 ```xml ``` 設定されている ​`transactionalAction`​ に従って、Try スコープ内の動作は次のいずれかになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行しますが、エラーはフローレベルの ​`on-error-continue`​ では処理されないため、トランザクションがロールバックされ、メッセージは送信されません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 ### [](#ローカルまたは-xa-トランザクションの設定)ローカルまたは XA トランザクションの設定 トランザクションアクションの設定に加えて、トランザクション種別をローカル (単一リソース) または XA トランザクションに設定できます。 Try スコープは、新しいトランザクションが作成されたときのみ、トランザクション種別設定を使用します。トランザクションの実行中は種別を変更できません。 動作はトランザクションアクションごとに変わります。 - Ignore (無視) (​`INDIFFERENT`​) すでに作成されているトランザクションを使用します (存在する場合)。このトランザクションアクションでは、トランザクション種別を設定しても何も変わりません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) トランザクションは、トランザクション種別設定で指定されている種別で作成されます。単一リソーストランザクション内での実行中は、​`ALWAYS_BEGIN`​ は無効な設定になることを忘れないでください。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) トランザクションがすでに作成されていれば、​`INDIFFERENT`​ の場合と同じように、トランザクション種別を設定しても何も変わりません。トランザクションが存在しない場合は、​`ALWAYS_BEGIN`​ の場合と同じように、トランザクション種別で指定されている種別のトランザクションが作成されます。 ## [](#変数とペイロードの伝播)変数とペイロードの伝播 ペイロードを変更したり、変数を追加、変更、または削除したりすると、実行の残りの部分に伝播されます。エラーハンドラー内での変更も伝播されます。 ## [](#関連情報)関連情報 - [Try スコープ XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-xml-reference) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management) # Try スコープ Try スコープを使用すると、Try スコープ内のコンポーネントの実行時に発生するエラーを処理できます。トランザクションもサポートします。Try スコープは、1 つまたは複数の操作をラップし、内部の操作がスローする例外をキャッチして処理します。まるで、エラー処理戦略が設定された別のフローにこれらのイベントコンポーネントを抽出したような動作となりますが、実際には新しいフローは定義せず、すべてインラインで処理を実行します。 ## [](#try-スコープでのエラー処理)Try スコープでのエラー処理 フローを設計するときは、Try スコープの内部でエラーが発生しやすい操作をグループ化するようにしてください。Try スコープにより、フローで問題を起こす可能性のある操作を隔離して、エラー処理メソッドに割り当てることができます。また、Try スコープ内の操作をトランザクションとして処理するように設定することもできます。 Try スコープはエラー処理戦略を持ち、フローのエラー処理を設定するのと同じように設定できます。 Try スコープは、さまざまなエラー種別の条件を見極めて、異なる動作を適用します。Try スコープ内のコンポーネントでエラーが発生すると、Try スコープのエラーハンドラーが実行されます。この時点で、エラーを調査することができ、ハンドラーは状況に応じて実行および動作できます。 - On Error Continue 実行後に結果をコンテナ Try スコープに送信します。コンテナ Try スコープは、渡された結果を使用して実行を正常に完了します。この時点でのトランザクションはすべてコミットされます。 - On Error Propagate すべてのトランザクションをロールバックし、実行後に結果を使用して既存のエラーを再びスローします。これにより、コンテナ Try スコープの実行は失敗します。 Try スコープの設定例 ![エラー処理オプションが含まれる Try スコープ設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-handling-try-scope.png) 前の例では、On Error Propagate (エラー時伝播) (​`on-error-propagate`​) エラーハンドラーによってデータベース接続エラー (​`DB:CONNECTIVITY`​) が伝播されます。このエラーの伝播により、Try スコープの実行は失敗し、フローのエラーハンドラーが実行されます。他のエラーは On Error Continue (エラー時続行) (​`on-error-continue`​) エラーハンドラーによって処理されるため、これらのエラーの発生時には Try スコープの実行は成功したように扱われ、次の操作である HTTP 要求が実行を続行します。 Try スコープに複数のコンポーネントがある場合、1 つのコンポーネントが例外をスローすると、例外をキャッチしたエラーハンドラーの種別には関係なく、Try スコープ内の以降のコンポーネントは実行されません。On Error Propagate (エラー時伝播) の場合、まるで Try スコープが存在しないかのように、エラーがフローのエラーハンドラーに伝播されます。On Error Continue (エラー時続行) の場合は、まるで Try スコープが例外をスローしなかったかのように、Try スコープ外部の次のフローコンポーネントから処理が続行します。 ## [](#トランザクションの処理)トランザクションの処理 トランザクションとは、絶対に部分的には実行されない一連のアクションです。エラーが伝播されてトランザクションがロールバックされるか、またはエラーが処理されてトランザクションがコミットされるかによって 1 つの単位として成功または失敗を判断する複数の操作が 1 つのセットになるように Try スコープを設定します。どちらの場合でも、Try スコープが存在するプロセスフローは処理を続行します。 ![トランザクション設定が含まれる Mule の Try スコープの設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-handling-try-scope-config.png) トランザクションアクション (​`transactionalAction`​) が ​`ALWAYS_BEGIN`​ または ​`BEGIN_OR_JOIN`​ に設定されている場合、Try スコープは、子操作をトランザクションとして扱います。次のように設定できます。 - Ignore (無視) (​`INDIFFERENT`​) デフォルト。トランザクションがアクティブであれば、スコープがトランザクションに結合します。そうでない場合は、スコープはトランザクションを作成しません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) スコープを実行する度に、新しいトランザクションが開始されます。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) 実行順序が (フロー外で発生する非同期アクションなどによって) 変化する場合にのみ適用されます。 フローの現在の処理ですでにトランザクションが開始されている場合は、スコープはそのトランザクションに結合します。そうでない場合は、スコープは新しいトランザクションを開始します。 ### [](#try-スコープでの異なるトランザクションアクションの分析)Try スコープでの異なるトランザクションアクションの分析 次の例は、フローレベルでトランザクションを開始するように設定された ​`jms:listener`​ 操作、トランザクションを (設定に従って) 開始または結合しようとする Try スコープ、そしてトランザクションの外部で実行するように設定された ​`jms:publish`​ 操作を示しています。 ```xml ``` Try スコープ内の操作でエラーが発生しなければ、設定されている ​`transactionalAction`​ 値には関係なく、スコープは実行を完了してトランザクションをコミットします。 ``​ コンポーネントが追加されると、Try スコープの ​`transactionalAction`​ によってトランザクションとメッセージの処理方法が変わります。 - Ignore (無視) (​`INDIFFERENT`​) この場合は、Try スコープ内で操作を実行しながらトランザクションが継続します。エラーが発生すると、接続元に伝播されます (​``​ エラーハンドラーでは処理しません)。トランザクションがロールバックされ、メッセージが JMS キューで再び使用できるようになります。このロールバックは、すでに完了している ​`jms:publish`​ 操作には影響しません。​`transactionAction`​ がデフォルトの ​`NOT_SUPPORTED`​ に設定されているため、この操作はトランザクションスコープの外部となります。 `transactionAction`​ が ​`JOIN_IF_POSSIBLE`​ に設定されていれば、​`jms:publish`​ 操作もロールバックされます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) この場合は、すでにトランザクションが開始されているため、スコープはアクティブなトランザクションに結合します。結果は ​`INDIFFERENT`​ の場合と同じです。 #### [](#フローレベルでのエラーハンドラー)フローレベルでのエラーハンドラー 次の例では、エラーハンドラーをフローレベルで追加しています。 ```xml ``` この例の動作は次のようになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行します。エラーは ​`on-error-continue`​ エラーハンドラーで処理されるため、トランザクションはコミットされます。​`jms:listener`​ 接続元から読み出されたメッセージはコンシュームされ、​`jms:publish`​ 操作で処理されたメッセージが実際に送信されます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 #### [](#try-スコープ内のエラーハンドラー)Try スコープ内のエラーハンドラー この場合は、エラーハンドラーが Try スコープ内にあり、スコープの実行後にエラーが発生します。 ```xml ``` 設定されている ​`transactionalAction`​ に従って、Try スコープ内の動作は次のいずれかになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行しますが、エラーはフローレベルの ​`on-error-continue`​ では処理されないため、トランザクションがロールバックされ、メッセージは送信されません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 ### [](#ローカルまたは-xa-トランザクションの設定)ローカルまたは XA トランザクションの設定 トランザクションアクションの設定に加えて、トランザクション種別をローカル (単一リソース) または XA トランザクションに設定できます。 Try スコープは、新しいトランザクションが作成されたときのみ、トランザクション種別設定を使用します。トランザクションの実行中は種別を変更できません。 動作はトランザクションアクションごとに変わります。 - Ignore (無視) (​`INDIFFERENT`​) すでに作成されているトランザクションを使用します (存在する場合)。このトランザクションアクションでは、トランザクション種別を設定しても何も変わりません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) トランザクションは、トランザクション種別設定で指定されている種別で作成されます。単一リソーストランザクション内での実行中は、​`ALWAYS_BEGIN`​ は無効な設定になることを忘れないでください。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) トランザクションがすでに作成されていれば、​`INDIFFERENT`​ の場合と同じように、トランザクション種別を設定しても何も変わりません。トランザクションが存在しない場合は、​`ALWAYS_BEGIN`​ の場合と同じように、トランザクション種別で指定されている種別のトランザクションが作成されます。 ## [](#変数とペイロードの伝播)変数とペイロードの伝播 ペイロードを変更したり、変数を追加、変更、または削除したりすると、実行の残りの部分に伝播されます。エラーハンドラー内での変更も伝播されます。 ## [](#関連情報)関連情報 - [Try スコープ XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-xml-reference) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management) # Try スコープ Try スコープを使用すると、Try スコープ内のコンポーネントの実行時に発生するエラーを処理できます。トランザクションもサポートします。Try スコープは、1 つまたは複数の操作をラップし、内部の操作がスローする例外をキャッチして処理します。まるで、エラー処理戦略が設定された別のフローにこれらのイベントコンポーネントを抽出したような動作となりますが、実際には新しいフローは定義せず、すべてインラインで処理を実行します。 ## [](#try-スコープでのエラー処理)Try スコープでのエラー処理 フローを設計するときは、Try スコープの内部でエラーが発生しやすい操作をグループ化するようにしてください。Try スコープにより、フローで問題を起こす可能性のある操作を隔離して、エラー処理メソッドに割り当てることができます。また、Try スコープ内の操作をトランザクションとして処理するように設定することもできます。 Try スコープはエラー処理戦略を持ち、フローのエラー処理を設定するのと同じように設定できます。 Try スコープは、さまざまなエラー種別の条件を見極めて、異なる動作を適用します。Try スコープ内のコンポーネントでエラーが発生すると、Try スコープのエラーハンドラーが実行されます。この時点で、エラーを調査することができ、ハンドラーは状況に応じて実行および動作できます。 - On Error Continue 実行後に結果をコンテナ Try スコープに送信します。コンテナ Try スコープは、渡された結果を使用して実行を正常に完了します。この時点でのトランザクションはすべてコミットされます。 - On Error Propagate すべてのトランザクションをロールバックし、実行後に結果を使用して既存のエラーを再びスローします。これにより、コンテナ Try スコープの実行は失敗します。 Try スコープの設定例 ![エラー処理オプションが含まれる Try スコープ設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handling-try-scope.png) 前の例では、On Error Propagate (エラー時伝播) (​`on-error-propagate`​) エラーハンドラーによってデータベース接続エラー (​`DB:CONNECTIVITY`​) が伝播されます。このエラーの伝播により、Try スコープの実行は失敗し、フローのエラーハンドラーが実行されます。他のエラーは On Error Continue (エラー時続行) (​`on-error-continue`​) エラーハンドラーによって処理されるため、これらのエラーの発生時には Try スコープの実行は成功したように扱われ、次の操作である HTTP 要求が実行を続行します。 Try スコープに複数のコンポーネントがある場合、1 つのコンポーネントが例外をスローすると、例外をキャッチしたエラーハンドラーの種別には関係なく、Try スコープ内の以降のコンポーネントは実行されません。On Error Propagate (エラー時伝播) の場合、まるで Try スコープが存在しないかのように、エラーがフローのエラーハンドラーに伝播されます。On Error Continue (エラー時続行) の場合は、まるで Try スコープが例外をスローしなかったかのように、Try スコープ外部の次のフローコンポーネントから処理が続行します。 ## [](#トランザクションの処理)トランザクションの処理 トランザクションとは、絶対に部分的には実行されない一連のアクションです。エラーが伝播されてトランザクションがロールバックされるか、またはエラーが処理されてトランザクションがコミットされるかによって 1 つの単位として成功または失敗を判断する複数の操作が 1 つのセットになるように Try スコープを設定します。どちらの場合でも、Try スコープが存在するプロセスフローは処理を続行します。 ![トランザクション設定が含まれる Mule の Try スコープの設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handling-try-scope-config.png) トランザクションアクション (​`transactionalAction`​) が ​`ALWAYS_BEGIN`​ または ​`BEGIN_OR_JOIN`​ に設定されている場合、Try スコープは、子操作をトランザクションとして扱います。次のように設定できます。 - Ignore (無視) (​`INDIFFERENT`​) デフォルト。トランザクションがアクティブであれば、スコープがトランザクションに結合します。そうでない場合は、スコープはトランザクションを作成しません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) スコープを実行する度に、新しいトランザクションが開始されます。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) 実行順序が (フロー外で発生する非同期アクションなどによって) 変化する場合にのみ適用されます。 フローの現在の処理ですでにトランザクションが開始されている場合は、スコープはそのトランザクションに結合します。そうでない場合は、スコープは新しいトランザクションを開始します。 ### [](#try-スコープでの異なるトランザクションアクションの分析)Try スコープでの異なるトランザクションアクションの分析 次の例は、フローレベルでトランザクションを開始するように設定された ​`jms:listener`​ 操作、トランザクションを (設定に従って) 開始または結合しようとする Try スコープ、そしてトランザクションの外部で実行するように設定された ​`jms:publish`​ 操作を示しています。 ```xml ``` Try スコープ内の操作でエラーが発生しなければ、設定されている ​`transactionalAction`​ 値には関係なく、スコープは実行を完了してトランザクションをコミットします。 ``​ コンポーネントが追加されると、Try スコープの ​`transactionalAction`​ によってトランザクションとメッセージの処理方法が変わります。 - Ignore (無視) (​`INDIFFERENT`​) この場合は、Try スコープ内で操作を実行しながらトランザクションが継続します。エラーが発生すると、接続元に伝播されます (​``​ エラーハンドラーでは処理しません)。トランザクションがロールバックされ、メッセージが JMS キューで再び使用できるようになります。このロールバックは、すでに完了している ​`jms:publish`​ 操作には影響しません。​`transactionAction`​ がデフォルトの ​`NOT_SUPPORTED`​ に設定されているため、この操作はトランザクションスコープの外部となります。 `transactionAction`​ が ​`JOIN_IF_POSSIBLE`​ に設定されていれば、​`jms:publish`​ 操作もロールバックされます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) この場合は、すでにトランザクションが開始されているため、スコープはアクティブなトランザクションに結合します。結果は ​`INDIFFERENT`​ の場合と同じです。 #### [](#フローレベルでのエラーハンドラー)フローレベルでのエラーハンドラー 次の例では、エラーハンドラーをフローレベルで追加しています。 ```xml ``` この例の動作は次のようになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行します。エラーは ​`on-error-continue`​ エラーハンドラーで処理されるため、トランザクションはコミットされます。​`jms:listener`​ 接続元から読み出されたメッセージはコンシュームされ、​`jms:publish`​ 操作で処理されたメッセージが実際に送信されます。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 #### [](#try-スコープ内のエラーハンドラー)Try スコープ内のエラーハンドラー この場合は、エラーハンドラーが Try スコープ内にあり、スコープの実行後にエラーが発生します。 ```xml ``` 設定されている ​`transactionalAction`​ に従って、Try スコープ内の動作は次のいずれかになります。 - Ignore (無視) (​`INDIFFERENT`​) トランザクションは続行しますが、エラーはフローレベルの ​`on-error-continue`​ では処理されないため、トランザクションがロールバックされ、メッセージは送信されません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) アクティブなトランザクションがすでに存在するため、エラーが発生します。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) `INDIFFERENT`​ と同じ動作となります。 ### [](#ローカルまたは-xa-トランザクションの設定)ローカルまたは XA トランザクションの設定 トランザクションアクションの設定に加えて、トランザクション種別をローカル (単一リソース) または XA トランザクションに設定できます。 Try スコープは、新しいトランザクションが作成されたときのみ、トランザクション種別設定を使用します。トランザクションの実行中は種別を変更できません。 動作はトランザクションアクションごとに変わります。 - Ignore (無視) (​`INDIFFERENT`​) すでに作成されているトランザクションを使用します (存在する場合)。このトランザクションアクションでは、トランザクション種別を設定しても何も変わりません。 - Always Begin (常に開始) (​`ALWAYS_BEGIN`​) トランザクションは、トランザクション種別設定で指定されている種別で作成されます。単一リソーストランザクション内での実行中は、​`ALWAYS_BEGIN`​ は無効な設定になることを忘れないでください。 - Begin or Join (開始または結合) (​`BEGIN_OR_JOIN`​) トランザクションがすでに作成されていれば、​`INDIFFERENT`​ の場合と同じように、トランザクション種別を設定しても何も変わりません。トランザクションが存在しない場合は、​`ALWAYS_BEGIN`​ の場合と同じように、トランザクション種別で指定されている種別のトランザクションが作成されます。 ## [](#変数とペイロードの伝播)変数とペイロードの伝播 ペイロードを変更したり、変数を追加、変更、または削除したりすると、実行の残りの部分に伝播されます。エラーハンドラー内での変更も伝播されます。 ## [](#関連情報)関連情報 - [Try スコープ XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-xml-reference) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management) # Try スコープ XML リファレンス Try スコープは、次の構造で定義します。 - 1 つのルート要素 ​`` - Try スコープが定義するエラー処理ルールに従って実行されるコンポーネントは、​`try`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 - 1 つの ​``​ 要素で、スコープのすべてのエラー処理戦略を定義します。 - エラーハンドラーでは、1 つまたは複数の ​`on-error-continue`​ と ​`on-error-propagate`​ によってさまざまな戦略を定義します。いずれか 1 つは必須です。 - 一致するエラーが発生した時点で実行されるコンポーネントは、​`on-error`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 ```xml ``` Try スコープ (​`on-error-*`​) の各エラー処理戦略は、条件に従って実行されます。この条件は、通常は現在のエラーと一致するエラー種別 (または複数種別のリスト) です。​`error.cause.message.contains("fatal")`​ のように、自由に作成した式として条件を定義することもできます。
条件は順番に評価され、最初に一致した戦略のみが実行されます。
2 つのエラー処理戦略を定義した例を示します。それぞれがロガーコンポーネントを実行します。 ```xml ``` ## [](#try-のプロパティ)Try のプロパティ
プロパティ デフォルト 説明

transactionalAction

INDIFFERENT

スコープ内のアクションをトランザクションとして扱うかどうかを定義します。可能な値:

  • INDIFFERENT: スコープ内のアクションをトランザクションとして扱いません。

  • ALWAYS_BEGIN​: スコープを実行する度に、新しいトランザクションが開始されます。

  • BEGIN_OR_JOIN​: フローの現在の処理ですでにトランザクションが開始されている場合は、そのトランザクションに結合します。開始されていなければ、新しいトランザクションを開始します。(実行順序が変化する場合にのみ適用されます。)

transactionalType

LOCAL

使用するトランザクションの種別を定義します。可能な値:

  • "LOCAL"

  • "XA"
## [](#関連情報)関連情報 - [Try スコープの概念](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling) # Try スコープ XML リファレンス Try スコープは、次の構造で定義します。 - 1 つのルート要素 ​`` - Try スコープが定義するエラー処理ルールに従って実行されるコンポーネントは、​`try`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 - 1 つの ​``​ 要素で、スコープのすべてのエラー処理戦略を定義します。 - エラーハンドラーでは、1 つまたは複数の ​`on-error-continue`​ と ​`on-error-propagate`​ によってさまざまな戦略を定義します。いずれか 1 つは必須です。 - 一致するエラーが発生した時点で実行されるコンポーネントは、​`on-error`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 ```xml ``` Try スコープ (​`on-error-*`​) の各エラー処理戦略は、条件に従って実行されます。この条件は、通常は現在のエラーと一致するエラー種別 (または複数種別のリスト) です。​`error.cause.message.contains("fatal")`​ のように、自由に作成した式として条件を定義することもできます。
条件は順番に評価され、最初に一致した戦略のみが実行されます。
2 つのエラー処理戦略を定義した例を示します。それぞれがロガーコンポーネントを実行します。 ```xml ``` ## [](#try-のプロパティ)Try のプロパティ
プロパティ デフォルト 説明

transactionalAction

INDIFFERENT

スコープ内のアクションをトランザクションとして扱うかどうかを定義します。可能な値:

  • INDIFFERENT: スコープ内のアクションをトランザクションとして扱いません。

  • ALWAYS_BEGIN​: スコープを実行する度に、新しいトランザクションが開始されます。

  • BEGIN_OR_JOIN​: フローの現在の処理ですでにトランザクションが開始されている場合は、そのトランザクションに結合します。開始されていなければ、新しいトランザクションを開始します。(実行順序が変化する場合にのみ適用されます。)

transactionalType

LOCAL

使用するトランザクションの種別を定義します。可能な値:

  • "LOCAL"

  • "XA"
## [](#関連情報)関連情報 - [Try スコープの概念](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling) # Try スコープ XML リファレンス Try スコープは、次の構造で定義します。 - 1 つのルート要素 ​`` - Try スコープが定義するエラー処理ルールに従って実行されるコンポーネントは、​`try`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 - 1 つの ​``​ 要素で、スコープのすべてのエラー処理戦略を定義します。 - エラーハンドラーでは、1 つまたは複数の ​`on-error-continue`​ と ​`on-error-propagate`​ によってさまざまな戦略を定義します。いずれか 1 つは必須です。 - 一致するエラーが発生した時点で実行されるコンポーネントは、​`on-error`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 ```xml ``` Try スコープ (​`on-error-*`​) の各エラー処理戦略は、条件に従って実行されます。この条件は、通常は現在のエラーと一致するエラー種別 (または複数種別のリスト) です。​`error.cause.message.contains("fatal")`​ のように、自由に作成した式として条件を定義することもできます。
条件は順番に評価され、最初に一致した戦略のみが実行されます。
2 つのエラー処理戦略を定義した例を示します。それぞれがロガーコンポーネントを実行します。 ```xml ``` ## [](#try-のプロパティ)Try のプロパティ
プロパティ デフォルト 説明

transactionalAction

INDIFFERENT

スコープ内のアクションをトランザクションとして扱うかどうかを定義します。可能な値:

  • INDIFFERENT: スコープ内のアクションをトランザクションとして扱いません。

  • ALWAYS_BEGIN​: スコープを実行する度に、新しいトランザクションが開始されます。

  • BEGIN_OR_JOIN​: フローの現在の処理ですでにトランザクションが開始されている場合は、そのトランザクションに結合します。開始されていなければ、新しいトランザクションを開始します。(実行順序が変化する場合にのみ適用されます。)

transactionalType

LOCAL

使用するトランザクションの種別を定義します。可能な値:

  • "LOCAL"

  • "XA"
## [](#関連情報)関連情報 - [Try スコープの概念](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling) # Try スコープ XML リファレンス Try スコープは、次の構造で定義します。 - 1 つのルート要素 ​`` - Try スコープが定義するエラー処理ルールに従って実行されるコンポーネントは、​`try`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 - 1 つの ​``​ 要素で、スコープのすべてのエラー処理戦略を定義します。 - エラーハンドラーでは、1 つまたは複数の ​`on-error-continue`​ と ​`on-error-propagate`​ によってさまざまな戦略を定義します。いずれか 1 つは必須です。 - 一致するエラーが発生した時点で実行されるコンポーネントは、​`on-error`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 ```xml ``` Try スコープ (​`on-error-*`​) の各エラー処理戦略は、条件に従って実行されます。この条件は、通常は現在のエラーと一致するエラー種別 (または複数種別のリスト) です。​`error.cause.message.contains("fatal")`​ のように、自由に作成した式として条件を定義することもできます。
条件は順番に評価され、最初に一致した戦略のみが実行されます。
2 つのエラー処理戦略を定義した例を示します。それぞれがロガーコンポーネントを実行します。 ```xml ``` ## [](#try-のプロパティ)Try のプロパティ
プロパティ Default (デフォルト) 説明

transactionalAction

INDIFFERENT

スコープ内のアクションをトランザクションとして扱うかどうかを定義します。可能な値:

  • INDIFFERENT: スコープ内のアクションをトランザクションとして扱いません。

  • ALWAYS_BEGIN​: スコープを実行する度に、新しいトランザクションが開始されます。

  • BEGIN_OR_JOIN​: フローの現在の処理ですでにトランザクションが開始されている場合は、そのトランザクションに結合します。開始されていなければ、新しいトランザクションを開始します。(実行順序が変化する場合にのみ適用されます。)

transactionalType

LOCAL

使用するトランザクションの種別を定義します。可能な値:

  • "LOCAL"

  • "XA"
## [](#関連情報)関連情報 - [Try スコープの概念](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling) # Try スコープ XML リファレンス Try スコープは、次の構造で定義します。 - 1 つのルート要素 ​`` - Try スコープが定義するエラー処理ルールに従って実行されるコンポーネントは、​`try`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 - 1 つの ​``​ 要素で、スコープのすべてのエラー処理戦略を定義します。 - エラーハンドラーでは、1 つまたは複数の ​`on-error-continue`​ と ​`on-error-propagate`​ によってさまざまな戦略を定義します。いずれか 1 つは必須です。 - 一致するエラーが発生した時点で実行されるコンポーネントは、​`on-error`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 ```xml ``` Try スコープ (​`on-error-*`​) の各エラー処理戦略は、条件に従って実行されます。この条件は、通常は現在のエラーと一致するエラー種別 (または複数種別のリスト) です。​`error.cause.message.contains("fatal")`​ のように、自由に作成した式として条件を定義することもできます。
条件は順番に評価され、最初に一致した戦略のみが実行されます。
2 つのエラー処理戦略を定義した例を示します。それぞれがロガーコンポーネントを実行します。 ```xml ``` ## [](#try-のプロパティ)Try のプロパティ
プロパティ Default (デフォルト) 説明

transactionalAction

INDIFFERENT

スコープ内のアクションをトランザクションとして扱うかどうかを定義します。可能な値:

  • INDIFFERENT: スコープ内のアクションをトランザクションとして扱いません。

  • ALWAYS_BEGIN​: スコープを実行する度に、新しいトランザクションが開始されます。

  • BEGIN_OR_JOIN​: フローの現在の処理ですでにトランザクションが開始されている場合は、そのトランザクションに結合します。開始されていなければ、新しいトランザクションを開始します。(実行順序が変化する場合にのみ適用されます。)

transactionalType

LOCAL

使用するトランザクションの種別を定義します。可能な値:

  • "LOCAL"

  • "XA"
## [](#関連情報)関連情報 - [Try スコープの概念](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling) # Try スコープ XML リファレンス Try スコープは、次の構造で定義します。 - 1 つのルート要素 ​`` - Try スコープが定義するエラー処理ルールに従って実行されるコンポーネントは、​`try`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 - 1 つの ​``​ 要素で、スコープのすべてのエラー処理戦略を定義します。 - エラーハンドラーでは、1 つまたは複数の ​`on-error-continue`​ と ​`on-error-propagate`​ によってさまざまな戦略を定義します。いずれか 1 つは必須です。 - 一致するエラーが発生した時点で実行されるコンポーネントは、​`on-error`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 ```xml ``` Try スコープ (​`on-error-*`​) の各エラー処理戦略は、条件に従って実行されます。この条件は、通常は現在のエラーと一致するエラー種別 (または複数種別のリスト) です。​`error.cause.message.contains("fatal")`​ のように、自由に作成した式として条件を定義することもできます。
条件は順番に評価され、最初に一致した戦略のみが実行されます。
2 つのエラー処理戦略を定義した例を示します。それぞれがロガーコンポーネントを実行します。 ```xml ``` ## [](#try-のプロパティ)Try のプロパティ
プロパティ Default (デフォルト) 説明

transactionalAction

INDIFFERENT

スコープ内のアクションをトランザクションとして扱うかどうかを定義します。可能な値:

  • INDIFFERENT: スコープ内のアクションをトランザクションとして扱いません。

  • ALWAYS_BEGIN​: スコープを実行する度に、新しいトランザクションが開始されます。

  • BEGIN_OR_JOIN​: フローの現在の処理ですでにトランザクションが開始されている場合は、そのトランザクションに結合します。開始されていなければ、新しいトランザクションを開始します。(実行順序が変化する場合にのみ適用されます。)

transactionalType

LOCAL

使用するトランザクションの種別を定義します。可能な値:

  • "LOCAL"

  • "XA"
## [](#関連情報)関連情報 - [Try スコープの概念](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling) # Try スコープ XML リファレンス Try スコープは、次の構造で定義します。 - 1 つのルート要素 ​`` - Try スコープが定義するエラー処理ルールに従って実行されるコンポーネントは、​`try`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 - 1 つの ​``​ 要素で、スコープのすべてのエラー処理戦略を定義します。 - エラーハンドラーでは、1 つまたは複数の ​`on-error-continue`​ と ​`on-error-propagate`​ によってさまざまな戦略を定義します。いずれか 1 つは必須です。 - 一致するエラーが発生した時点で実行されるコンポーネントは、​`on-error`​ 要素の子要素として定義されます。1 つまたは複数のコンポーネントを定義できます。 ```xml ``` Try スコープ (​`on-error-*`​) の各エラー処理戦略は、条件に従って実行されます。この条件は、通常は現在のエラーと一致するエラー種別 (または複数種別のリスト) です。​`error.cause.message.contains("fatal")`​ のように、自由に作成した式として条件を定義することもできます。
条件は順番に評価され、最初に一致した戦略のみが実行されます。
2 つのエラー処理戦略を定義した例を示します。それぞれがロガーコンポーネントを実行します。 ```xml ``` ## [](#try-のプロパティ)Try のプロパティ
プロパティ Default (デフォルト) 説明

transactionalAction

INDIFFERENT

スコープ内のアクションをトランザクションとして扱うかどうかを定義します。可能な値:

  • INDIFFERENT: スコープ内のアクションをトランザクションとして扱いません。

  • ALWAYS_BEGIN​: スコープを実行する度に、新しいトランザクションが開始されます。

  • BEGIN_OR_JOIN​: フローの現在の処理ですでにトランザクションが開始されている場合は、そのトランザクションに結合します。開始されていなければ、新しいトランザクションを開始します。(実行順序が変化する場合にのみ適用されます。)

transactionalType

LOCAL

使用するトランザクションの種別を定義します。可能な値:

  • "LOCAL"

  • "XA"
## [](#関連情報)関連情報 - [Try スコープの概念](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept) - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling) # Until Successful スコープ Until Successful スコープは、内部のコンポーネントが成功するか、または最大再試行回数に達するまで、内部のコンポーネントを順番に処理します。Async 以外のすべてのコアコンポーネントと同様に、Until Successful は同期的に実行されます。スコープ内のコンポーネントが接続に失敗したり、正常に結果を生成できなかったりした場合、Until Successful では設定されている最大再試行回数まで失敗したコンポーネントをやり直します。再試行が成功すると、スコープは次のコンポーネントに進みます。最後の再試行に失敗すると、Until Successful はエラーをスローします。 Until Successful を使用する一般的な処理は次の通りです。 - アウトバウンドエンドポイントへのディスパッチ (可用性に問題があるかも知れないリモート Web サービスを呼び出す場合など)。 - コンポーネントメソッドの実行 (信頼性の低いリソースに依存する Spring bean を実行する場合など)。 - サブフローを使用した、いくつかのアクションが成功するまでの再試行。 ## [](#until-successful-スコープ設定)Until Successful スコープ設定 Until Successful スコープを設定するには、​``​ XML 要素をアプリケーションフロー内に追加します。 Until Successful スコープでは次の属性を設定できます。
属性 説明

Max Retries (最大再試行回数) (​maxRetries​)

許容される再試行の最大回数を指定します。この属性は、数値、または数値に解決される式にできます。最大回数に達すると、​Message: 'until-successful' retries exhausted.​ のようなエラーメッセージが出力されます。Mule エラー種別は ​MULE:RETRY_EXHAUSTED​ です。

Milliseconds Between Retries (再試行回数間のミリ秒数) (​millisBetweenRetries​)

再試行間の最小間隔をミリ秒単位で指定します。実際の間隔は前回の試行の期間によって変わりますが、この値の 2 倍を超えてはいけません。デフォルトは ​60000​ (1 分) です。この属性は、数値、または数値に解決される式にできます。
## [](#until-successful-スコープの設定例)Until Successful スコープの設定例 次の XML の例では、Scheduler コンポーネントによりトリガーされるフローと、FTP Write 操作を実行する Until Successful スコープを設定します。 ```xml ``` サンプルアプリケーションの動作: - FTP Write 操作が失敗した場合 Until Successful スコープでは、操作が成功するまで ​`3000`​ ミリ秒ごとに操作を再試行します。ただし、​`5`​ 回の再試行回数の制限があります。最後の実行が失敗すると ​`MULE:RETRY_EXHAUSTED`​ エラーがスローされます。次に、​``​ でエラーが処理され、Logger が実行されて、​`File upload failed`​ というメッセージが表示されます。 - いずれかの試行で FTP Write 操作の実行が成功した場合 Until Successful スコープの後の次のプロセッサーが実行されます。この事例では、Logger で ​`File upload success`​ というメッセージが表示されます。 ## [](#変数の伝播)変数の伝播 Until Successful スコープは毎回必ず、ブロックの実行前に存在していた変数と値を使用して実行が開始されます。1 つの要素の処理中に新しい変数を追加したり既存の変数を変更したりした場合でも (エラーが発生した場合に備えて) 次の実行では認識されません。実行が正常に完了すると、変数 (およびペイロード) はフローの残り部分に伝播されます。 ## [](#関連情報)関連情報 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management#tx_scopes_routers) # Until Successful スコープ Until Successful スコープは、内部のプロセッサーがすべて成功するか、またはスコープが最大再試行回数に達するまで、内部のコンポーネントを順番に処理します。 Until Successful は同期的に実行されます。スコープ内のプロセッサーが接続に失敗したり、正常に結果を生成できなかったりした場合、Until Successful では設定されている最大再試行回数まで、失敗したプロセッサーを含めて内部のすべてのプロセッサーをやり直します。再試行が成功すると、スコープは次のコンポーネントに進みます。最後の再試行に失敗すると、Until Successful はエラーをスローします。 例外が発生しない場合、または応答が式に一致する場合、ルーティングは成功です。 Until Successful を使用する一般的な処理は次の通りです。 - アウトバウンドエンドポイントへのディスパッチ (可用性に問題があるかも知れないリモート Web サービスを呼び出す場合など)。 - コンポーネントメソッドの実行 (信頼性の低いリソースに依存する Spring bean を実行する場合など)。 - サブフローを使用した、いくつかのアクションが成功するまでの再試行。 ## [](#until-successful-スコープ設定)Until Successful スコープ設定 Until Successful スコープを設定するには、​``​ XML 要素をアプリケーションフロー内に追加します。 Until Successful スコープでは次の属性を設定できます。
項目 XML 説明

Max Retries (最大再試行回数)

maxRetries

許容される再試行の最大回数を指定します。この属性は、数値、または数値に解決される式にできます。最大回数に達すると、​Message: 'until-successful' retries exhausted.​ のようなエラーメッセージが出力されます。Mule エラー種別は ​MULE:RETRY_EXHAUSTED​ です。

Milliseconds Between Retries (再試行回数間のミリ秒数)

millisBetweenRetries

再試行間の最小間隔をミリ秒単位で指定します。実際の間隔は前回の試行の期間によって変わりますが、この値の 2 倍を超えてはいけません。デフォルトは ​60000​ (1 分) です。この属性は、数値、または数値に解決される式にできます。
## [](#until-successful-スコープの設定例)Until Successful スコープの設定例 次の XML の例では、Scheduler コンポーネントによりトリガーされるフローと、FTP Write 操作を実行する Until Successful スコープを設定します。 ```xml ``` サンプルアプリケーションの動作: - FTP Write 操作が失敗した場合 Until Successful スコープでは、操作が成功するまで ​`3000`​ ミリ秒ごとに操作を再試行します。ただし、​`5`​ 回の再試行回数の制限があります。最後の実行が失敗すると ​`MULE:RETRY_EXHAUSTED`​ エラーがスローされます。次に、​``​ でエラーが処理され、Logger が実行されて、​`File upload failed`​ というメッセージが表示されます。 `MULE:RETRY_EXHAUSTED`​ をスローする前に、Mule では、たとえば次のように、Mule イベントでプロセッサーの実行をやり直すために失敗した各試行をログにも記録します。 ```logs ERROR 2022-12-09 17:41:44,910 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 1 of 5. ... ERROR 2022-12-09 17:41:55,079 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 5 of 5. ``` - いずれかの試行で FTP Write 操作の実行が成功した場合 Until Successful スコープの後の次のプロセッサーが実行されます。この事例では、Logger で ​`File upload success`​ というメッセージが表示されます。 ## [](#変数の伝播)変数の伝播 Until Successful スコープは毎回必ず、ブロックの実行前に存在していた変数と値を使用して実行が開始されます。1 つの要素の処理中に新しい変数を追加したり既存の変数を変更したりした場合でも (エラーが発生した場合に備えて) 次の実行では認識されません。実行が正常に完了すると、変数 (およびペイロード) はフローの残り部分に伝播されます。 ## [](#関連情報)関連情報 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management#tx_scopes_routers) # Until Successful スコープ Until Successful スコープは、内部のプロセッサーがすべて成功するか、またはスコープが最大再試行回数に達するまで、内部のコンポーネントを順番に処理します。 Until Successful は同期的に実行されます。スコープ内のプロセッサーが接続に失敗したり、正常に結果を生成できなかったりした場合、Until Successful では設定されている最大再試行回数まで、失敗したプロセッサーを含めて内部のすべてのプロセッサーをやり直します。再試行が成功すると、スコープは次のコンポーネントに進みます。最後の再試行に失敗すると、Until Successful はエラーをスローします。 例外が発生しない場合、または応答が式に一致する場合、ルーティングは成功です。 Until Successful を使用する一般的な処理は次の通りです。 - アウトバウンドエンドポイントへのディスパッチ (可用性に問題があるかも知れないリモート Web サービスを呼び出す場合など)。 - コンポーネントメソッドの実行 (信頼性の低いリソースに依存する Spring bean を実行する場合など)。 - サブフローを使用した、いくつかのアクションが成功するまでの再試行。 ## [](#until-successful-スコープ設定)Until Successful スコープ設定 Until Successful スコープを設定するには、​``​ XML 要素をアプリケーションフロー内に追加します。 Until Successful スコープでは次の属性を設定できます。
項目 XML 説明

Max Retries (最大再試行回数)

maxRetries

許容される再試行の最大回数を指定します。この属性は、数値、または数値に解決される式にできます。最大回数に達すると、​Message: 'until-successful' retries exhausted.​ のようなエラーメッセージが出力されます。Mule エラー種別は ​MULE:RETRY_EXHAUSTED​ です。

Milliseconds Between Retries (再試行回数間のミリ秒数)

millisBetweenRetries

再試行間の最小間隔をミリ秒単位で指定します。実際の間隔は前回の試行の期間によって変わりますが、この値の 2 倍を超えてはいけません。デフォルトは ​60000​ (1 分) です。この属性は、数値、または数値に解決される式にできます。
## [](#until-successful-スコープの設定例)Until Successful スコープの設定例 次の XML の例では、Scheduler コンポーネントによりトリガーされるフローと、FTP Write 操作を実行する Until Successful スコープを設定します。 ```xml ``` サンプルアプリケーションの動作: - FTP Write 操作が失敗した場合 Until Successful スコープでは、操作が成功するまで ​`3000`​ ミリ秒ごとに操作を再試行します。ただし、​`5`​ 回の再試行回数の制限があります。最後の実行が失敗すると ​`MULE:RETRY_EXHAUSTED`​ エラーがスローされます。次に、​``​ でエラーが処理され、Logger が実行されて、​`File upload failed`​ というメッセージが表示されます。 `MULE:RETRY_EXHAUSTED`​ をスローする前に、Mule では、たとえば次のように、Mule イベントでプロセッサーの実行をやり直すために失敗した各試行をログにも記録します。 ```logs ERROR 2022-12-09 17:41:44,910 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 1 of 5. ... ERROR 2022-12-09 17:41:55,079 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 5 of 5. ``` - いずれかの試行で FTP Write 操作の実行が成功した場合 Until Successful スコープの後の次のプロセッサーが実行されます。この事例では、Logger で ​`File upload success`​ というメッセージが表示されます。 ## [](#変数の伝播)変数の伝播 Until Successful スコープは毎回必ず、ブロックの実行前に存在していた変数と値を使用して実行が開始されます。1 つの要素の処理中に新しい変数を追加したり既存の変数を変更したりした場合でも (エラーが発生した場合に備えて) 次の実行では認識されません。実行が正常に完了すると、変数 (およびペイロード) はフローの残り部分に伝播されます。 ## [](#関連情報)関連情報 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management#tx_scopes_routers) # Until Successful スコープ Until Successful スコープは、内部のプロセッサーがすべて成功するか、またはスコープが最大再試行回数に達するまで、内部のコンポーネントを順番に処理します。 Until Successful は同期的に実行されます。スコープ内のプロセッサーが接続に失敗したり、正常に結果を生成できなかったりした場合、Until Successful では設定されている最大再試行回数まで、失敗したプロセッサーを含めて内部のすべてのプロセッサーをやり直します。再試行が成功すると、スコープは次のコンポーネントに進みます。最後の再試行に失敗すると、Until Successful はエラーをスローします。 例外が発生しない場合、または応答が式に一致する場合、ルーティングは成功です。 Until Successful を使用する一般的な処理は次の通りです。 - アウトバウンドエンドポイントへのディスパッチ (可用性に問題があるかも知れないリモート Web サービスを呼び出す場合など)。 - コンポーネントメソッドの実行 (信頼性の低いリソースに依存する Spring bean を実行する場合など)。 - サブフローを使用した、いくつかのアクションが成功するまでの再試行。 ## [](#until-successful-スコープ設定)Until Successful スコープ設定 Until Successful スコープを設定するには、​``​ XML 要素をアプリケーションフロー内に追加します。 Until Successful スコープでは次の属性を設定できます。
項目 XML 説明

Max Retries (最大再試行回数)

maxRetries

許容される再試行の最大回数を指定します。この属性は、数値、または数値に解決される式にできます。最大回数に達すると、​Message: 'until-successful' retries exhausted.​ のようなエラーメッセージが出力されます。Mule エラー種別は ​MULE:RETRY_EXHAUSTED​ です。

Milliseconds Between Retries (再試行回数間のミリ秒数)

millisBetweenRetries

再試行間の最小間隔をミリ秒単位で指定します。実際の間隔は前回の試行の期間によって変わりますが、この値の 2 倍を超えてはいけません。デフォルトは ​60000​ (1 分) です。この属性は、数値、または数値に解決される式にできます。
## [](#until-successful-スコープの設定例)Until Successful スコープの設定例 次の XML の例では、Scheduler コンポーネントによりトリガーされるフローと、FTP Write 操作を実行する Until Successful スコープを設定します。 ```xml ``` サンプルアプリケーションの動作: - FTP Write 操作が失敗した場合 Until Successful スコープでは、操作が成功するまで ​`3000`​ ミリ秒ごとに操作を再試行します。ただし、​`5`​ 回の再試行回数の制限があります。最後の実行が失敗すると ​`MULE:RETRY_EXHAUSTED`​ エラーがスローされます。次に、​``​ でエラーが処理され、Logger が実行されて、​`File upload failed`​ というメッセージが表示されます。 `MULE:RETRY_EXHAUSTED`​ をスローする前に、Mule では、たとえば次のように、Mule イベントでプロセッサーの実行をやり直すために失敗した各試行をログにも記録します。 ```logs ERROR 2022-12-09 17:41:44,910 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 1 of 5. ... ERROR 2022-12-09 17:41:55,079 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 5 of 5. ``` - いずれかの試行で FTP Write 操作の実行が成功した場合 Until Successful スコープの後の次のプロセッサーが実行されます。この事例では、Logger で ​`File upload success`​ というメッセージが表示されます。 ## [](#変数の伝播)変数の伝播 Until Successful スコープは毎回必ず、ブロックの実行前に存在していた変数と値を使用して実行が開始されます。1 つの要素の処理中に新しい変数を追加したり既存の変数を変更したりした場合でも (エラーが発生した場合に備えて) 次の実行では認識されません。実行が正常に完了すると、変数 (およびペイロード) はフローの残り部分に伝播されます。 ## [](#関連情報)関連情報 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management#tx_scopes_routers) # Until Successful スコープ Until Successful スコープは、内部のプロセッサーがすべて成功するか、またはスコープが最大再試行回数に達するまで、内部のコンポーネントを順番に処理します。 Until Successful は同期的に実行されます。スコープ内のプロセッサーが接続に失敗したり、正常に結果を生成できなかったりした場合、Until Successful では設定されている最大再試行回数まで、失敗したプロセッサーを含めて内部のすべてのプロセッサーをやり直します。再試行が成功すると、スコープは次のコンポーネントに進みます。最後の再試行に失敗すると、Until Successful はエラーをスローします。 例外が発生しない場合、または応答が式に一致する場合、ルーティングは成功です。 Until Successful を使用する一般的な処理は次の通りです。 - アウトバウンドエンドポイントへのディスパッチ (可用性に問題があるかも知れないリモート Web サービスを呼び出す場合など)。 - コンポーネントメソッドの実行 (信頼性の低いリソースに依存する Spring bean を実行する場合など)。 - サブフローを使用した、いくつかのアクションが成功するまでの再試行。 ## [](#until-successful-スコープ設定)Until Successful スコープ設定 Until Successful スコープを設定するには、​``​ XML 要素をアプリケーションフロー内に追加します。 Until Successful スコープでは次の属性を設定できます。
項目 XML 説明

Max Retries (最大再試行回数)

maxRetries

許容される再試行の最大回数を指定します。この属性は、数値、または数値に解決される式にできます。最大回数に達すると、​Message: 'until-successful' retries exhausted.​ のようなエラーメッセージが出力されます。Mule エラー種別は ​MULE:RETRY_EXHAUSTED​ です。

Milliseconds Between Retries (再試行回数間のミリ秒数)

millisBetweenRetries

再試行間の最小間隔をミリ秒単位で指定します。実際の間隔は前回の試行の期間によって変わりますが、この値の 2 倍を超えてはいけません。デフォルトは ​60000​ (1 分) です。この属性は、数値、または数値に解決される式にできます。
## [](#until-successful-スコープの設定例)Until Successful スコープの設定例 次の XML の例では、Scheduler コンポーネントによりトリガーされるフローと、FTP Write 操作を実行する Until Successful スコープを設定します。 ```xml ``` サンプルアプリケーションの動作: - FTP Write 操作が失敗した場合 Until Successful スコープでは、操作が成功するまで ​`3000`​ ミリ秒ごとに操作を再試行します。ただし、​`5`​ 回の再試行回数の制限があります。最後の実行が失敗すると ​`MULE:RETRY_EXHAUSTED`​ エラーがスローされます。次に、​``​ でエラーが処理され、Logger が実行されて、​`File upload failed`​ というメッセージが表示されます。 `MULE:RETRY_EXHAUSTED`​ をスローする前に、Mule では、たとえば次のように、Mule イベントでプロセッサーの実行をやり直すために失敗した各試行をログにも記録します。 ```logs ERROR 2022-12-09 17:41:44,910 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 1 of 5. ... ERROR 2022-12-09 17:41:55,079 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 5 of 5. ``` - いずれかの試行で FTP Write 操作の実行が成功した場合 Until Successful スコープの後の次のプロセッサーが実行されます。この事例では、Logger で ​`File upload success`​ というメッセージが表示されます。 ## [](#変数の伝播)変数の伝播 Until Successful スコープは毎回必ず、ブロックの実行前に存在していた変数と値を使用して実行が開始されます。1 つの要素の処理中に新しい変数を追加したり既存の変数を変更したりした場合でも (エラーが発生した場合に備えて) 次の実行では認識されません。実行が正常に完了すると、変数 (およびペイロード) はフローの残り部分に伝播されます。 ## [](#関連情報)関連情報 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management#tx_scopes_routers) # Until Successful スコープ Until Successful スコープは、内部のプロセッサーがすべて成功するか、またはスコープが最大再試行回数に達するまで、内部のコンポーネントを順番に処理します。 Until Successful は同期的に実行されます。スコープ内のプロセッサーが接続に失敗したり、正常に結果を生成できなかったりした場合、Until Successful では設定されている最大再試行回数まで、失敗したプロセッサーを含めて内部のすべてのプロセッサーをやり直します。再試行が成功すると、スコープは次のコンポーネントに進みます。最後の再試行に失敗すると、Until Successful はエラーをスローします。 例外が発生しない場合、または応答が式に一致する場合、ルーティングは成功です。 Until Successful を使用する一般的な処理は次の通りです。 - アウトバウンドエンドポイントへのディスパッチ (可用性に問題があるかも知れないリモート Web サービスを呼び出す場合など)。 - コンポーネントメソッドの実行 (信頼性の低いリソースに依存する Spring bean を実行する場合など)。 - サブフローを使用した、いくつかのアクションが成功するまでの再試行。 ## [](#until-successful-スコープ設定)Until Successful スコープ設定 Until Successful スコープを設定するには、​``​ XML 要素をアプリケーションフロー内に追加します。 Until Successful スコープでは次の属性を設定できます。
項目 XML 説明

Max Retries (最大再試行回数)

maxRetries

許容される再試行の最大回数を指定します。この属性は、数値、または数値に解決される式にできます。最大回数に達すると、​Message: 'until-successful' retries exhausted.​ のようなエラーメッセージが出力されます。Mule エラー種別は ​MULE:RETRY_EXHAUSTED​ です。

Milliseconds Between Retries (再試行回数間のミリ秒数)

millisBetweenRetries

再試行間の最小間隔をミリ秒単位で指定します。実際の間隔は前回の試行の期間によって変わりますが、この値の 2 倍を超えてはいけません。デフォルトは ​60000​ (1 分) です。この属性は、数値、または数値に解決される式にできます。
## [](#until-successful-スコープの設定例)Until Successful スコープの設定例 次の XML の例では、Scheduler コンポーネントによりトリガーされるフローと、FTP Write 操作を実行する Until Successful スコープを設定します。 ```xml ``` サンプルアプリケーションの動作: - FTP Write 操作が失敗した場合 Until Successful スコープでは、操作が成功するまで ​`3000`​ ミリ秒ごとに操作を再試行します。ただし、​`5`​ 回の再試行回数の制限があります。最後の実行が失敗すると ​`MULE:RETRY_EXHAUSTED`​ エラーがスローされます。次に、​``​ でエラーが処理され、Logger が実行されて、​`File upload failed`​ というメッセージが表示されます。 `MULE:RETRY_EXHAUSTED`​ をスローする前に、Mule では、たとえば次のように、Mule イベントでプロセッサーの実行をやり直すために失敗した各試行をログにも記録します。 ```logs ERROR 2022-12-09 17:41:44,910 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 1 of 5. ... ERROR 2022-12-09 17:41:55,079 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 5 of 5. ``` - いずれかの試行で FTP Write 操作の実行が成功した場合 Until Successful スコープの後の次のプロセッサーが実行されます。この事例では、Logger で ​`File upload success`​ というメッセージが表示されます。 ## [](#変数の伝播)変数の伝播 Until Successful スコープは毎回必ず、ブロックの実行前に存在していた変数と値を使用して実行が開始されます。1 つの要素の処理中に新しい変数を追加したり既存の変数を変更したりした場合でも (エラーが発生した場合に備えて) 次の実行では認識されません。実行が正常に完了すると、変数 (およびペイロード) はフローの残り部分に伝播されます。 ## [](#関連情報)関連情報 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management#tx_scopes_routers) # Until Successful スコープ Until Successful スコープは、内部のプロセッサーがすべて成功するか、またはスコープが最大再試行回数に達するまで、内部のコンポーネントを順番に処理します。 Until Successful は同期的に実行されます。スコープ内のプロセッサーが接続に失敗したり、正常に結果を生成できなかったりした場合、Until Successful では設定されている最大再試行回数まで、失敗したプロセッサーを含めて内部のすべてのプロセッサーをやり直します。再試行が成功すると、スコープは次のコンポーネントに進みます。最後の再試行に失敗すると、Until Successful はエラーをスローします。 例外が発生しない場合、または応答が式に一致する場合、ルーティングは成功です。 Until Successful を使用する一般的な処理は次の通りです。 - アウトバウンドエンドポイントへのディスパッチ (可用性に問題があるかも知れないリモート Web サービスを呼び出す場合など)。 - コンポーネントメソッドの実行 (信頼性の低いリソースに依存する Spring bean を実行する場合など)。 - サブフローを使用した、いくつかのアクションが成功するまでの再試行。 ## [](#until-successful-スコープ設定)Until Successful スコープ設定 Until Successful スコープを設定するには、​``​ XML 要素をアプリケーションフロー内に追加します。 Until Successful スコープでは次の属性を設定できます。
項目 XML 説明

Max Retries (最大再試行回数)

maxRetries

許容される再試行の最大回数を指定します。この属性は、数値、または数値に解決される式にできます。最大回数に達すると、​Message: 'until-successful' retries exhausted.​ のようなエラーメッセージが出力されます。Mule エラー種別は ​MULE:RETRY_EXHAUSTED​ です。

Milliseconds Between Retries (再試行回数間のミリ秒数)

millisBetweenRetries

再試行間の最小間隔をミリ秒単位で指定します。実際の間隔は前回の試行の期間によって変わりますが、この値の 2 倍を超えてはいけません。デフォルトは ​60000​ (1 分) です。この属性は、数値、または数値に解決される式にできます。
## [](#until-successful-スコープの設定例)Until Successful スコープの設定例 次の XML の例では、Scheduler コンポーネントによりトリガーされるフローと、FTP Write 操作を実行する Until Successful スコープを設定します。 ```xml ``` サンプルアプリケーションの動作: - FTP Write 操作が失敗した場合 Until Successful スコープでは、操作が成功するまで ​`3000`​ ミリ秒ごとに操作を再試行します。ただし、​`5`​ 回の再試行回数の制限があります。最後の実行が失敗すると ​`MULE:RETRY_EXHAUSTED`​ エラーがスローされます。次に、​``​ でエラーが処理され、Logger が実行されて、​`File upload failed`​ というメッセージが表示されます。 `MULE:RETRY_EXHAUSTED`​ をスローする前に、Mule では、たとえば次のように、Mule イベントでプロセッサーの実行をやり直すために失敗した各試行をログにも記録します。 ```logs ERROR 2022-12-09 17:41:44,910 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 1 of 5. ... ERROR 2022-12-09 17:41:55,079 ... event: cdad31c0-782b-11ed-af21-147ddaaf4f97] ...UntilSuccessfulRouter: Retrying execution of event, attempt 5 of 5. ``` - いずれかの試行で FTP Write 操作の実行が成功した場合 Until Successful スコープの後の次のプロセッサーが実行されます。この事例では、Logger で ​`File upload success`​ というメッセージが表示されます。 ## [](#変数の伝播)変数の伝播 Until Successful スコープは毎回必ず、ブロックの実行前に存在していた変数と値を使用して実行が開始されます。1 つの要素の処理中に新しい変数を追加したり既存の変数を変更したりした場合でも (エラーが発生した場合に備えて) 次の実行では認識されません。実行が正常に完了すると、変数 (およびペイロード) はフローの残り部分に伝播されます。 ## [](#関連情報)関連情報 - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management#tx_scopes_routers) # Until Successful の移行 Mule 4 の Until Successful コンポーネントでは、一部のプロセスの処理方法が Mule 3 の場合と異なります。これらの変更に関連する一部の要素と属性は、Mule 4 には存在しません。Mule 4 では、異なる属性やコンポーネントを使用して同じ機能を実行できるか、Mule 4 でその機能を設定する必要がなくなったかのいずれかです。 Until Successful コンポーネントの手動移行では、以下の変更を行います。 - ``​ 要素をすべて削除する。 - `secondsBetweenRetries`​ 属性を ​`millisBetweenRetries`​ に置き換える。 - `failureExpression`​ を削除し、代わりに Mule 4 の検証プロセッサーを使用する。 - `deadLetterQueue-ref`​ 属性を Mule 4 のエラーハンドラーに置き換える。 - ``​ 要素をすべて削除する。 - `ackExpression`​ 属性を削除し、代わりに Set Payload コンポーネントを使用する。 - `synchronous`​ 属性をすべて削除する。 以下の各セクションで、これらの変更について説明します。 ## [](#mule-4-で使用されなくなったプロセッサーチェーン)Mule 4 で使用されなくなったプロセッサーチェーン Mule 3 では、Until Successful スコープの内側で複数のプロセッサーを実行するには、プロセッサーチェーン (​``​) の内側にプロセッサーをラップする必要がありました。Mule 4 の Until Successful では複数のプロセッサーがサポートされ、プロセッサーチェーンは必要ありません。 Mule 3: ```xml ``` Mule 4 の例には、​``​ 要素がありません。 Mule 4: ```xml ``` ## [](#mule-4-で変更された再試行属性)Mule 4 で変更された再試行属性 Mule 3 の ​`secondsBetweenRetries`​ 属性は Mule 4 から削除されました。Mule 4 では ​`millisBetweenRetries`​ 属性を使用できます。 Mule 3: ```xml ``` Mule 4 の例では、​`secondsBetweenRetries="10"`​ が ​`millisBetweenRetries="10000"`​ に置き換わっています。 Mule 4: ```xml ``` ## [](#変更が必要な失敗式)変更が必要な失敗式 `failureExpression`​ 属性は削除されました。検証式を設定する検証プロセッサーに置き換えることができます。 Mule 3: ```xml ``` Mule 3 の例にある ​`failureExpression`​ 設定は、Mule 4 では ​``​ 設定に置き換わります。 Mule 4: ```xml ``` ## [](#mule-4-のエラーハンドラーを使用したデッドレターキューの参照)Mule 4 のエラーハンドラーを使用したデッドレターキューの参照 Mule 3 の ​`deadLetterQueue-ref`​ 属性では、すべての再試行が失敗したら、配信不能メッセージをエンドポイントまたはプロセッサーに送信できます。Mule 4 では、代わりにエラーハンドラーを使用して、すべての ​`RETRY_EXHAUSTED`​ 例外をキャッチし、メッセージをそのエンドポイントまたはプロセッサーに送信できます。 Mule 3: ```xml ``` Mule 4 の例では、エラーハンドラー ​``​ 内の On Error Propagate (エラー時に伝搬) ​``​ 要素を使用して ​`dlqChannel`​ を参照します。 Mule 4: ```xml ``` ## [](#mule-4-で不要になり削除されたスレッドプロファイル)Mule 4 で不要になり削除されたスレッドプロファイル Mule 3 では、​``​ 子要素を使用して、実行スレッドを調整できます。Mule 4 では、実行エンジンでいくつかの変更が行われました。 Mule 4 では非ブロックアーキテクチャとの関連付けにより、スレッドを手動で調整する必要がなくなりました。 Mule 3: ```xml ``` Mule 4 の例では、​``​ 要素を削除します。 Mule 4: ```xml ``` ## [](#削除された-ackexpression-属性と-set-payload-の使用)削除された ackExpression 属性と Set Payload の使用 Mule 3 の ​`ackExpression`​ 属性は、応答ペイロードの同期生成を設定します。この属性は Mule 4 には存在しません。アプリケーションでこの動作を実行するには、Until Successful の後に Set Payload コンポーネントを設定できます。 Mule 3: ```xml ``` Mule 4 の例では、Set Payload ​``​ コンポーネントを使用して ​`#[message:correlationId]`​ 値を設定します。 Mule 4: ```xml ``` ## [](#不要になり削除された同期属性)不要になり削除された同期属性 `synchronous`​ 属性は不要になったため削除されました。Mule 4 では、実行エンジンでいくつかの変更が行われました。非ブロックアーキテクチャでは不要になりました。 ## [](#関連情報)関連情報 - [Mule 4 の概要: 実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-engine)​。 - [実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.3/execution-engine) - [Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/until-successful-scope) # Until Successful の移行 Mule 4 の Until Successful コンポーネントでは、一部のプロセスの処理方法が Mule 3 の場合と異なります。これらの変更に関連する一部の要素と属性は、Mule 4 には存在しません。Mule 4 では、異なる属性やコンポーネントを使用して同じ機能を実行できるか、Mule 4 でその機能を設定する必要がなくなったかのいずれかです。 Until Successful コンポーネントの手動移行では、以下の変更を行います。 - ``​ 要素をすべて削除する。 - `secondsBetweenRetries`​ 属性を ​`millisBetweenRetries`​ に置き換える。 - `failureExpression`​ を削除し、代わりに Mule 4 の検証プロセッサーを使用する。 - `deadLetterQueue-ref`​ 属性を Mule 4 のエラーハンドラーに置き換える。 - ``​ 要素をすべて削除する。 - `ackExpression`​ 属性を削除し、代わりに Set Payload コンポーネントを使用する。 - `synchronous`​ 属性をすべて削除する。 以下の各セクションで、これらの変更について説明します。 ## [](#mule-4-で使用されなくなったプロセッサーチェーン)Mule 4 で使用されなくなったプロセッサーチェーン Mule 3 では、Until Successful スコープの内側で複数のプロセッサーを実行するには、プロセッサーチェーン (​``​) の内側にプロセッサーをラップする必要がありました。Mule 4 の Until Successful では複数のプロセッサーがサポートされ、プロセッサーチェーンは必要ありません。 Mule 3: ```xml ``` Mule 4 の例には、​``​ 要素がありません。 Mule 4: ```xml ``` ## [](#mule-4-で変更された再試行属性)Mule 4 で変更された再試行属性 Mule 3 の ​`secondsBetweenRetries`​ 属性は Mule 4 から削除されました。Mule 4 では ​`millisBetweenRetries`​ 属性を使用できます。 Mule 3: ```xml ``` Mule 4 の例では、​`secondsBetweenRetries="10"`​ が ​`millisBetweenRetries="10000"`​ に置き換わっています。 Mule 4: ```xml ``` ## [](#変更が必要な失敗式)変更が必要な失敗式 `failureExpression`​ 属性は削除されました。検証式を設定する検証プロセッサーに置き換えることができます。 Mule 3: ```xml ``` Mule 3 の例にある ​`failureExpression`​ 設定は、Mule 4 では ​``​ 設定に置き換わります。 Mule 4: ```xml ``` ## [](#mule-4-のエラーハンドラーを使用したデッドレターキューの参照)Mule 4 のエラーハンドラーを使用したデッドレターキューの参照 Mule 3 の ​`deadLetterQueue-ref`​ 属性では、すべての再試行が失敗したら、配信不能メッセージをエンドポイントまたはプロセッサーに送信できます。Mule 4 では、代わりにエラーハンドラーを使用して、すべての ​`RETRY_EXHAUSTED`​ 例外をキャッチし、メッセージをそのエンドポイントまたはプロセッサーに送信できます。 Mule 3: ```xml ``` Mule 4 の例では、エラーハンドラー ​``​ 内の On Error Propagate (エラー時に伝搬) ​``​ 要素を使用して ​`dlqChannel`​ を参照します。 Mule 4: ```xml ``` ## [](#mule-4-で不要になり削除されたスレッドプロファイル)Mule 4 で不要になり削除されたスレッドプロファイル Mule 3 では、​``​ 子要素を使用して、実行スレッドを調整できます。Mule 4 では、実行エンジンでいくつかの変更が行われました。 Mule 4 では非ブロックアーキテクチャとの関連付けにより、スレッドを手動で調整する必要がなくなりました。 Mule 3: ```xml ``` Mule 4 の例では、​``​ 要素を削除します。 Mule 4: ```xml ``` ## [](#削除された-ackexpression-属性と-set-payload-の使用)削除された ackExpression 属性と Set Payload の使用 Mule 3 の ​`ackExpression`​ 属性は、応答ペイロードの同期生成を設定します。この属性は Mule 4 には存在しません。アプリケーションでこの動作を実行するには、Until Successful の後に Set Payload コンポーネントを設定できます。 Mule 3: ```xml ``` Mule 4 の例では、Set Payload ​``​ コンポーネントを使用して ​`#[message:correlationId]`​ 値を設定します。 Mule 4: ```xml ``` ## [](#不要になり削除された同期属性)不要になり削除された同期属性 `synchronous`​ 属性は不要になったため削除されました。Mule 4 では、実行エンジンでいくつかの変更が行われました。非ブロックアーキテクチャでは不要になりました。 ## [](#関連情報)関連情報 - [Mule 4 の概要: 実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-engine)​。 - [実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.4/execution-engine) - [Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/until-successful-scope) # Until Successful の移行 Mule 4 の Until Successful コンポーネントでは、一部のプロセスの処理方法が Mule 3 の場合と異なります。これらの変更に関連する一部の要素と属性は、Mule 4 には存在しません。Mule 4 では、異なる属性やコンポーネントを使用して同じ機能を実行できるか、Mule 4 でその機能を設定する必要がなくなったかのいずれかです。 Until Successful コンポーネントの手動移行では、以下の変更を行います。 - ``​ 要素をすべて削除する。 - `secondsBetweenRetries`​ 属性を ​`millisBetweenRetries`​ に置き換える。 - `failureExpression`​ を削除し、代わりに Mule 4 の検証プロセッサーを使用する。 - `deadLetterQueue-ref`​ 属性を Mule 4 のエラーハンドラーに置き換える。 - ``​ 要素をすべて削除する。 - `ackExpression`​ 属性を削除し、代わりに Set Payload コンポーネントを使用する。 - `synchronous`​ 属性をすべて削除する。 以下の各セクションで、これらの変更について説明します。 ## [](#mule-4-で使用されなくなったプロセッサーチェーン)Mule 4 で使用されなくなったプロセッサーチェーン Mule 3 では、Until Successful スコープの内側で複数のプロセッサーを実行するには、プロセッサーチェーン (​``​) の内側にプロセッサーをラップする必要がありました。Mule 4 の Until Successful では複数のプロセッサーがサポートされ、プロセッサーチェーンは必要ありません。 Mule 3: ```xml ``` Mule 4 の例には、​``​ 要素がありません。 Mule 4: ```xml ``` ## [](#mule-4-で変更された再試行属性)Mule 4 で変更された再試行属性 Mule 3 の ​`secondsBetweenRetries`​ 属性は Mule 4 から削除されました。Mule 4 では ​`millisBetweenRetries`​ 属性を使用できます。 Mule 3: ```xml ``` Mule 4 の例では、​`secondsBetweenRetries="10"`​ が ​`millisBetweenRetries="10000"`​ に置き換わっています。 Mule 4: ```xml ``` ## [](#変更が必要な失敗式)変更が必要な失敗式 `failureExpression`​ 属性は削除されました。検証式を設定する検証プロセッサーに置き換えることができます。 Mule 3: ```xml ``` Mule 3 の例にある ​`failureExpression`​ 設定は、Mule 4 では ​``​ 設定に置き換わります。 Mule 4: ```xml ``` ## [](#mule-4-のエラーハンドラーを使用したデッドレターキューの参照)Mule 4 のエラーハンドラーを使用したデッドレターキューの参照 Mule 3 の ​`deadLetterQueue-ref`​ 属性では、すべての再試行が失敗したら、配信不能メッセージをエンドポイントまたはプロセッサーに送信できます。Mule 4 では、代わりにエラーハンドラーを使用して、すべての ​`RETRY_EXHAUSTED`​ 例外をキャッチし、メッセージをそのエンドポイントまたはプロセッサーに送信できます。 Mule 3: ```xml ``` Mule 4 の例では、エラーハンドラー ​``​ 内の On Error Propagate (エラー時に伝搬) ​``​ 要素を使用して ​`dlqChannel`​ を参照します。 Mule 4: ```xml ``` ## [](#mule-4-で不要になり削除されたスレッドプロファイル)Mule 4 で不要になり削除されたスレッドプロファイル Mule 3 では、​``​ 子要素を使用して、実行スレッドを調整できます。Mule 4 では、実行エンジンでいくつかの変更が行われました。 Mule 4 では非ブロックアーキテクチャとの関連付けにより、スレッドを手動で調整する必要がなくなりました。 Mule 3: ```xml ``` Mule 4 の例では、​``​ 要素を削除します。 Mule 4: ```xml ``` ## [](#削除された-ackexpression-属性と-set-payload-の使用)削除された ackExpression 属性と Set Payload の使用 Mule 3 の ​`ackExpression`​ 属性は、応答ペイロードの同期生成を設定します。この属性は Mule 4 には存在しません。アプリケーションでこの動作を実行するには、Until Successful の後に Set Payload コンポーネントを設定できます。 Mule 3: ```xml ``` Mule 4 の例では、Set Payload ​``​ コンポーネントを使用して ​`#[message:correlationId]`​ 値を設定します。 Mule 4: ```xml ``` ## [](#不要になり削除された同期属性)不要になり削除された同期属性 `synchronous`​ 属性は不要になったため削除されました。Mule 4 では、実行エンジンでいくつかの変更が行われました。非ブロックアーキテクチャでは不要になりました。 ## [](#関連情報)関連情報 - [Mule 4 の概要: 実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-engine)​。 - [実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.5/execution-engine) - [Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/until-successful-scope) # Until Successful の移行 Mule 4 の Until Successful コンポーネントでは、一部のプロセスの処理方法が Mule 3 の場合と異なります。これらの変更に関連する一部の要素と属性は、Mule 4 には存在しません。Mule 4 では、異なる属性やコンポーネントを使用して同じ機能を実行できるか、Mule 4 でその機能を設定する必要がなくなったかのいずれかです。 Until Successful コンポーネントの手動移行では、以下の変更を行います。 - ``​ 要素をすべて削除する。 - `secondsBetweenRetries`​ 属性を ​`millisBetweenRetries`​ に置き換える。 - `failureExpression`​ を削除し、代わりに Mule 4 の検証プロセッサーを使用する。 - `deadLetterQueue-ref`​ 属性を Mule 4 のエラーハンドラーに置き換える。 - ``​ 要素をすべて削除する。 - `ackExpression`​ 属性を削除し、代わりに Set Payload コンポーネントを使用する。 - `synchronous`​ 属性をすべて削除する。 以下の各セクションで、これらの変更について説明します。 ## [](#mule-4-で使用されなくなったプロセッサーチェーン)Mule 4 で使用されなくなったプロセッサーチェーン Mule 3 では、Until Successful スコープの内側で複数のプロセッサーを実行するには、プロセッサーチェーン (​``​) の内側にプロセッサーをラップする必要がありました。Mule 4 の Until Successful では複数のプロセッサーがサポートされ、プロセッサーチェーンは必要ありません。 Mule 3: ```xml ``` Mule 4 の例には、​``​ 要素がありません。 Mule 4: ```xml ``` ## [](#mule-4-で変更された再試行属性)Mule 4 で変更された再試行属性 Mule 3 の ​`secondsBetweenRetries`​ 属性は Mule 4 から削除されました。Mule 4 では ​`millisBetweenRetries`​ 属性を使用できます。 Mule 3: ```xml ``` Mule 4 の例では、​`secondsBetweenRetries="10"`​ が ​`millisBetweenRetries="10000"`​ に置き換わっています。 Mule 4: ```xml ``` ## [](#変更が必要な失敗式)変更が必要な失敗式 `failureExpression`​ 属性は削除されました。検証式を設定する検証プロセッサーに置き換えることができます。 Mule 3: ```xml ``` Mule 3 の例にある ​`failureExpression`​ 設定は、Mule 4 では ​``​ 設定に置き換わります。 Mule 4: ```xml ``` ## [](#mule-4-のエラーハンドラーを使用したデッドレターキューの参照)Mule 4 のエラーハンドラーを使用したデッドレターキューの参照 Mule 3 の ​`deadLetterQueue-ref`​ 属性では、すべての再試行が失敗したら、配信不能メッセージをエンドポイントまたはプロセッサーに送信できます。Mule 4 では、代わりにエラーハンドラーを使用して、すべての ​`RETRY_EXHAUSTED`​ 例外をキャッチし、メッセージをそのエンドポイントまたはプロセッサーに送信できます。 Mule 3: ```xml ``` Mule 4 の例では、エラーハンドラー ​``​ 内の On Error Propagate (エラー時に伝搬) ​``​ 要素を使用して ​`dlqChannel`​ を参照します。 Mule 4: ```xml ``` ## [](#mule-4-で不要になり削除されたスレッドプロファイル)Mule 4 で不要になり削除されたスレッドプロファイル Mule 3 では、​``​ 子要素を使用して、実行スレッドを調整できます。Mule 4 では、実行エンジンでいくつかの変更が行われました。 Mule 4 では非ブロックアーキテクチャとの関連付けにより、スレッドを手動で調整する必要がなくなりました。 Mule 3: ```xml ``` Mule 4 の例では、​``​ 要素を削除します。 Mule 4: ```xml ``` ## [](#削除された-ackexpression-属性と-set-payload-の使用)削除された ackExpression 属性と Set Payload の使用 Mule 3 の ​`ackExpression`​ 属性は、応答ペイロードの同期生成を設定します。この属性は Mule 4 には存在しません。アプリケーションでこの動作を実行するには、Until Successful の後に Set Payload コンポーネントを設定できます。 Mule 3: ```xml ``` Mule 4 の例では、Set Payload ​``​ コンポーネントを使用して ​`#[message:correlationId]`​ 値を設定します。 Mule 4: ```xml ``` ## [](#不要になり削除された同期属性)不要になり削除された同期属性 `synchronous`​ 属性は不要になったため削除されました。Mule 4 では、実行エンジンでいくつかの変更が行われました。非ブロックアーキテクチャでは不要になりました。 ## [](#関連情報)関連情報 - [Mule 4 の概要: 実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-engine)​。 - [実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.6/execution-engine) - [Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/until-successful-scope) # Until Successful の移行 Mule 4 の Until Successful コンポーネントでは、一部のプロセスの処理方法が Mule 3 の場合と異なります。これらの変更に関連する一部の要素と属性は、Mule 4 には存在しません。Mule 4 では、異なる属性やコンポーネントを使用して同じ機能を実行できるか、Mule 4 でその機能を設定する必要がなくなったかのいずれかです。 Until Successful コンポーネントの手動移行では、以下の変更を行います。 - ``​ 要素をすべて削除する。 - `secondsBetweenRetries`​ 属性を ​`millisBetweenRetries`​ に置き換える。 - `failureExpression`​ を削除し、代わりに Mule 4 の検証プロセッサーを使用する。 - `deadLetterQueue-ref`​ 属性を Mule 4 のエラーハンドラーに置き換える。 - ``​ 要素をすべて削除する。 - `ackExpression`​ 属性を削除し、代わりに Set Payload コンポーネントを使用する。 - `synchronous`​ 属性をすべて削除する。 以下の各セクションで、これらの変更について説明します。 ## [](#mule-4-で使用されなくなったプロセッサーチェーン)Mule 4 で使用されなくなったプロセッサーチェーン Mule 3 では、Until Successful スコープの内側で複数のプロセッサーを実行するには、プロセッサーチェーン (​``​) の内側にプロセッサーをラップする必要がありました。Mule 4 の Until Successful では複数のプロセッサーがサポートされ、プロセッサーチェーンは必要ありません。 Mule 3: ```xml ``` Mule 4 の例には、​``​ 要素がありません。 Mule 4: ```xml ``` ## [](#mule-4-で変更された再試行属性)Mule 4 で変更された再試行属性 Mule 3 の ​`secondsBetweenRetries`​ 属性は Mule 4 から削除されました。Mule 4 では ​`millisBetweenRetries`​ 属性を使用できます。 Mule 3: ```xml ``` Mule 4 の例では、​`secondsBetweenRetries="10"`​ が ​`millisBetweenRetries="10000"`​ に置き換わっています。 Mule 4: ```xml ``` ## [](#変更が必要な失敗式)変更が必要な失敗式 `failureExpression`​ 属性は削除されました。検証式を設定する検証プロセッサーに置き換えることができます。 Mule 3: ```xml ``` Mule 3 の例にある ​`failureExpression`​ 設定は、Mule 4 では ​``​ 設定に置き換わります。 Mule 4: ```xml ``` ## [](#mule-4-のエラーハンドラーを使用したデッドレターキューの参照)Mule 4 のエラーハンドラーを使用したデッドレターキューの参照 Mule 3 の ​`deadLetterQueue-ref`​ 属性では、すべての再試行が失敗したら、配信不能メッセージをエンドポイントまたはプロセッサーに送信できます。Mule 4 では、代わりにエラーハンドラーを使用して、すべての ​`RETRY_EXHAUSTED`​ 例外をキャッチし、メッセージをそのエンドポイントまたはプロセッサーに送信できます。 Mule 3: ```xml ``` Mule 4 の例では、エラーハンドラー ​``​ 内の On Error Propagate (エラー時に伝搬) ​``​ 要素を使用して ​`dlqChannel`​ を参照します。 Mule 4: ```xml ``` ## [](#mule-4-で不要になり削除されたスレッドプロファイル)Mule 4 で不要になり削除されたスレッドプロファイル Mule 3 では、​``​ 子要素を使用して、実行スレッドを調整できます。Mule 4 では、実行エンジンでいくつかの変更が行われました。 Mule 4 では非ブロックアーキテクチャとの関連付けにより、スレッドを手動で調整する必要がなくなりました。 Mule 3: ```xml ``` Mule 4 の例では、​``​ 要素を削除します。 Mule 4: ```xml ``` ## [](#削除された-ackexpression-属性と-set-payload-の使用)削除された ackExpression 属性と Set Payload の使用 Mule 3 の ​`ackExpression`​ 属性は、応答ペイロードの同期生成を設定します。この属性は Mule 4 には存在しません。アプリケーションでこの動作を実行するには、Until Successful の後に Set Payload コンポーネントを設定できます。 Mule 3: ```xml ``` Mule 4 の例では、Set Payload ​``​ コンポーネントを使用して ​`#[message:correlationId]`​ 値を設定します。 Mule 4: ```xml ``` ## [](#不要になり削除された同期属性)不要になり削除された同期属性 `synchronous`​ 属性は不要になったため削除されました。Mule 4 では、実行エンジンでいくつかの変更が行われました。非ブロックアーキテクチャでは不要になりました。 ## [](#関連情報)関連情報 - [Mule 4 の概要: 実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-engine)​。 - [実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.7/execution-engine) - [Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/until-successful-scope) # Until Successful の移行 Mule 4 の Until Successful コンポーネントでは、一部のプロセスの処理方法が Mule 3 の場合と異なります。これらの変更に関連する一部の要素と属性は、Mule 4 には存在しません。Mule 4 では、異なる属性やコンポーネントを使用して同じ機能を実行できるか、Mule 4 でその機能を設定する必要がなくなったかのいずれかです。 Until Successful コンポーネントの手動移行では、以下の変更を行います。 - ``​ 要素をすべて削除する。 - `secondsBetweenRetries`​ 属性を ​`millisBetweenRetries`​ に置き換える。 - `failureExpression`​ を削除し、代わりに Mule 4 の検証プロセッサーを使用する。 - `deadLetterQueue-ref`​ 属性を Mule 4 のエラーハンドラーに置き換える。 - ``​ 要素をすべて削除する。 - `ackExpression`​ 属性を削除し、代わりに Set Payload コンポーネントを使用する。 - `synchronous`​ 属性をすべて削除する。 以下の各セクションで、これらの変更について説明します。 ## [](#mule-4-で使用されなくなったプロセッサーチェーン)Mule 4 で使用されなくなったプロセッサーチェーン Mule 3 では、Until Successful スコープの内側で複数のプロセッサーを実行するには、プロセッサーチェーン (​``​) の内側にプロセッサーをラップする必要がありました。Mule 4 の Until Successful では複数のプロセッサーがサポートされ、プロセッサーチェーンは必要ありません。 Mule 3: ```xml ``` Mule 4 の例には、​``​ 要素がありません。 Mule 4: ```xml ``` ## [](#mule-4-で変更された再試行属性)Mule 4 で変更された再試行属性 Mule 3 の ​`secondsBetweenRetries`​ 属性は Mule 4 から削除されました。Mule 4 では ​`millisBetweenRetries`​ 属性を使用できます。 Mule 3: ```xml ``` Mule 4 の例では、​`secondsBetweenRetries="10"`​ が ​`millisBetweenRetries="10000"`​ に置き換わっています。 Mule 4: ```xml ``` ## [](#変更が必要な失敗式)変更が必要な失敗式 `failureExpression`​ 属性は削除されました。検証式を設定する検証プロセッサーに置き換えることができます。 Mule 3: ```xml ``` Mule 3 の例にある ​`failureExpression`​ 設定は、Mule 4 では ​``​ 設定に置き換わります。 Mule 4: ```xml ``` ## [](#mule-4-のエラーハンドラーを使用したデッドレターキューの参照)Mule 4 のエラーハンドラーを使用したデッドレターキューの参照 Mule 3 の ​`deadLetterQueue-ref`​ 属性では、すべての再試行が失敗したら、配信不能メッセージをエンドポイントまたはプロセッサーに送信できます。Mule 4 では、代わりにエラーハンドラーを使用して、すべての ​`RETRY_EXHAUSTED`​ 例外をキャッチし、メッセージをそのエンドポイントまたはプロセッサーに送信できます。 Mule 3: ```xml ``` Mule 4 の例では、エラーハンドラー ​``​ 内の On Error Propagate (エラー時に伝搬) ​``​ 要素を使用して ​`dlqChannel`​ を参照します。 Mule 4: ```xml ``` ## [](#mule-4-で不要になり削除されたスレッドプロファイル)Mule 4 で不要になり削除されたスレッドプロファイル Mule 3 では、​``​ 子要素を使用して、実行スレッドを調整できます。Mule 4 では、実行エンジンでいくつかの変更が行われました。 Mule 4 では非ブロックアーキテクチャとの関連付けにより、スレッドを手動で調整する必要がなくなりました。 Mule 3: ```xml ``` Mule 4 の例では、​``​ 要素を削除します。 Mule 4: ```xml ``` ## [](#削除された-ackexpression-属性と-set-payload-の使用)削除された ackExpression 属性と Set Payload の使用 Mule 3 の ​`ackExpression`​ 属性は、応答ペイロードの同期生成を設定します。この属性は Mule 4 には存在しません。アプリケーションでこの動作を実行するには、Until Successful の後に Set Payload コンポーネントを設定できます。 Mule 3: ```xml ``` Mule 4 の例では、Set Payload ​``​ コンポーネントを使用して ​`#[message:correlationId]`​ 値を設定します。 Mule 4: ```xml ``` ## [](#不要になり削除された同期属性)不要になり削除された同期属性 `synchronous`​ 属性は不要になったため削除されました。Mule 4 では、実行エンジンでいくつかの変更が行われました。非ブロックアーキテクチャでは不要になりました。 ## [](#関連情報)関連情報 - [Mule 4 の概要: 実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-engine)​。 - [実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.8/execution-engine) - [Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/until-successful-scope) # Until Successful の移行 Mule 4 の Until Successful コンポーネントでは、一部のプロセスの処理方法が Mule 3 の場合と異なります。これらの変更に関連する一部の要素と属性は、Mule 4 には存在しません。Mule 4 では、異なる属性やコンポーネントを使用して同じ機能を実行できるか、Mule 4 でその機能を設定する必要がなくなったかのいずれかです。 Until Successful コンポーネントの手動移行では、以下の変更を行います。 - ``​ 要素をすべて削除する。 - `secondsBetweenRetries`​ 属性を ​`millisBetweenRetries`​ に置き換える。 - `failureExpression`​ を削除し、代わりに Mule 4 の検証プロセッサーを使用する。 - `deadLetterQueue-ref`​ 属性を Mule 4 のエラーハンドラーに置き換える。 - ``​ 要素をすべて削除する。 - `ackExpression`​ 属性を削除し、代わりに Set Payload コンポーネントを使用する。 - `synchronous`​ 属性をすべて削除する。 以下の各セクションで、これらの変更について説明します。 ## [](#mule-4-で使用されなくなったプロセッサーチェーン)Mule 4 で使用されなくなったプロセッサーチェーン Mule 3 では、Until Successful スコープの内側で複数のプロセッサーを実行するには、プロセッサーチェーン (​``​) の内側にプロセッサーをラップする必要がありました。Mule 4 の Until Successful では複数のプロセッサーがサポートされ、プロセッサーチェーンは必要ありません。 Mule 3: ```xml ``` Mule 4 の例には、​``​ 要素がありません。 Mule 4: ```xml ``` ## [](#mule-4-で変更された再試行属性)Mule 4 で変更された再試行属性 Mule 3 の ​`secondsBetweenRetries`​ 属性は Mule 4 から削除されました。Mule 4 では ​`millisBetweenRetries`​ 属性を使用できます。 Mule 3: ```xml ``` Mule 4 の例では、​`secondsBetweenRetries="10"`​ が ​`millisBetweenRetries="10000"`​ に置き換わっています。 Mule 4: ```xml ``` ## [](#変更が必要な失敗式)変更が必要な失敗式 `failureExpression`​ 属性は削除されました。検証式を設定する検証プロセッサーに置き換えることができます。 Mule 3: ```xml ``` Mule 3 の例にある ​`failureExpression`​ 設定は、Mule 4 では ​``​ 設定に置き換わります。 Mule 4: ```xml ``` ## [](#mule-4-のエラーハンドラーを使用したデッドレターキューの参照)Mule 4 のエラーハンドラーを使用したデッドレターキューの参照 Mule 3 の ​`deadLetterQueue-ref`​ 属性では、すべての再試行が失敗したら、配信不能メッセージをエンドポイントまたはプロセッサーに送信できます。Mule 4 では、代わりにエラーハンドラーを使用して、すべての ​`RETRY_EXHAUSTED`​ 例外をキャッチし、メッセージをそのエンドポイントまたはプロセッサーに送信できます。 Mule 3: ```xml ``` Mule 4 の例では、エラーハンドラー ​``​ 内の On Error Propagate (エラー時に伝搬) ​``​ 要素を使用して ​`dlqChannel`​ を参照します。 Mule 4: ```xml ``` ## [](#mule-4-で不要になり削除されたスレッドプロファイル)Mule 4 で不要になり削除されたスレッドプロファイル Mule 3 では、​``​ 子要素を使用して、実行スレッドを調整できます。Mule 4 では、実行エンジンでいくつかの変更が行われました。 Mule 4 では非ブロックアーキテクチャとの関連付けにより、スレッドを手動で調整する必要がなくなりました。 Mule 3: ```xml ``` Mule 4 の例では、​``​ 要素を削除します。 Mule 4: ```xml ``` ## [](#削除された-ackexpression-属性と-set-payload-の使用)削除された ackExpression 属性と Set Payload の使用 Mule 3 の ​`ackExpression`​ 属性は、応答ペイロードの同期生成を設定します。この属性は Mule 4 には存在しません。アプリケーションでこの動作を実行するには、Until Successful の後に Set Payload コンポーネントを設定できます。 Mule 3: ```xml ``` Mule 4 の例では、Set Payload ​``​ コンポーネントを使用して ​`#[message:correlationId]`​ 値を設定します。 Mule 4: ```xml ``` ## [](#不要になり削除された同期属性)不要になり削除された同期属性 `synchronous`​ 属性は不要になったため削除されました。Mule 4 では、実行エンジンでいくつかの変更が行われました。非ブロックアーキテクチャでは不要になりました。 ## [](#関連情報)関連情報 - [Mule 4 の概要: 実行エンジンのスレッドと同時実行](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-engine)​。 - [実行エンジン](https://docs.mulesoft.com/jp/mule-runtime/4.9/execution-engine) - [Until Successful スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/until-successful-scope) # Validation Module の移行 Mule 4 の Validation Module は、Mule 3 の Validation Module と非常に似ています。これらのメジャーバージョン間で最も大きな影響を受けたのは、エラー処理と式のサポートでした。 Mule 4 拡張機能では、別の方法でエラー種別を使用してエラーを宣言するので、エラー処理が異なります。式に関しては、Mule 4 では MEL 式がサポートされるのは互換性のあるモジュール内のみで、それ以外の式はすべて DataWeave 式にする必要があります。 このセクションの内容 - [エラーの種類](#errors) - [MEL 式の関数から DataWeave の関数へ](#functions) - [All スコープの使用](#all_scope) - [カスタムバリデーターのビルド](#custom_validator) ## [](#errors)エラーの種類 Mule 3 の Validation Module は、検証中に失敗すると同じ例外または設定された例外をスローします。ユーザーはエラーに応じたメッセージをカスタマイズできます。一方、Mule 4 では、モジュールが独自のエラー種別を宣言します。このモジュールの場合、検証操作には、失敗した検証の種別を暗黙に示すさまざまなエラー種別があります。​`all`​ スコープの場合、​`all`​ スコープの内側で失敗した検証に関係なく、種別は ​**VALIDATION:MULTIPLE**​ です。エラーメッセージをカスタマイズするか、デフォルトのエラーメッセージを使用できます。 以下の例は、変数 email が有効なメールでない場合に失敗するバリデーターを示しています。 Mule 3 の例 ```xml ``` この検証が失敗すると、​**ValidationException**​ がスローされます。 Mule 4 の例 ```xml ``` この検証が失敗すると、エラーの種別は ​**VALIDATION:INVALID\_EMAIL**​ になります。 ## [](#functions)MEL 式の関数から DataWeave の関数へ 式で検証を実行できた Mule 3 と同じように、Mule 4 でも検証を行うことができます。 相違点は、Mule 4 の場合、これらの検証は MEL 式ではなく DataWeave 式内でコールされることです。 Mule 4 でサポートされている関数は ​`isEmail`​、​`matchesRegex`​、​`isTime`​、​`isNumber`​、​`isIp`​、​`isUrl`​ です。 以下の例は、unknownVariable という変数のコンテンツが有効なメールか、有効な URL か、またはどちらでもない場合に応じて、異なる操作を実行する方法を示しています。 Mule 3 の例 ```xml ``` MEL 式の内側でバリデーターを使用して検証メソッドにアクセスしました。 Mule 4 の例 ```xml ``` Validation Module には、DataWeave 式内からコールされるよう宣言された関数があります。 Mule 4 のその他の関数と同じく、これらは ExtensionName::functionName、この場合は ​`Validation::isEmail(vars.email)`​ を使用して呼び出されます。 ## [](#all_scope)All スコープの使用 Mule 4 では、dsl の一部が若干変更されただけで、Mule 3 と同じように一連の検証をグループ化することができます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#custom_validator)カスタムバリデーターのビルド カスタムバリデーターは、拡張機能バリデーターに置き換わりました。これらのバリデーターは、操作のようなものですが、常に void を返すという相違点があります。検証が失敗したことを示すために、Java メソッドは ​`ModuleException`​ とそれぞれのエラー種別をスローする必要があります。これらのバリデーターを使用することで、失敗した検証をより適切に説明する独自のエラー種別を作成できます。これらを使用するユーザーエクスペリエンスは、その他の操作を使用する場合と同じです。拡張機能バリデーターについての詳細は、拡張機能バリデーターに関するドキュメントを参照してください。 **注意:**​ これらのバリデーターは、​`all`​ 検証スコープの内側でも使用できます。 Mule 3 のカスタムバリデーターを Mule 4 に移行する方法を見てみましょう。以下の例から、以前はイベント全体を取得し、そこから検証に必要な情報を取得していたことがわかります。 Mule 4 の例では、バリデーターに必要なパラメーターのみを提供しています。 Mule 3 の例 これは、dsl でカスタムバリデーターがどのように記述されていたかを示しています。 ```xml ``` これは、バリデーターインターフェースがどのように実行されたかを示しています。検証のために取得した情報は、メッセージの特定の部分に関するものである必要がありました。この場合は、フロー変数である price と balance です。 ```java public class BalanceValidator implements Validator { @Override public ValidationResult validate(MuleEvent event) { Integer price = new Integer((String) event.getMessage().getInvocationProperty("price")); Integer balance = new Integer((String) event.getMessage().getInvocationProperty("balance")); return new ValidationResult() { @Override public boolean isError() { return price > balance; } @Override public String getMessage() { return "There is not enough money to make the transaction"; } }; } } ``` Mule 4 の例 これは、Mule 4 で拡張機能バリデーターを使用する方法を示しています。名前空間とタグ名から、何を検証しているのかがわかりやすくなっています。また、ここにあるパラメーターは dsl の一部です。変数に設定する代わりに、ここに式を入力することができます。 ```xml ``` これを実行するために、​`balance`​ という簡単な拡張機能を作成します。 ```java @Operations({BalanceOperations.class}) @Extension(name = "balance") @ErrorTypes(BalanceError.class) public class BalanceExtension { } ``` `BalanceOperations`​ クラスに検証メソッドを追加し、​`@Validator`​ で注釈を付けます。このメソッドは、汎用的な検証エラー種別から取得するエラー種別をスローする必要があります。 ```java public class BalanceOperations { @Validator @Throws(BalanceErrorsProvider.class) public void hasSufficientFunds(Integer balance, Integer price) throws Exception { if (price > balance){ throw new ModuleException(BalanceError.INSUFFICIENT_FUNDS, new IllegalArgumentException("There is not enough money to make the transaction")); } } } ``` 次に、検証が失敗した場合にスローされるエラーを作成します。これには検証の失敗に応じた名前が付いています。 ```java public enum BalanceError implements ErrorTypeDefinition { INSUFFICIENT_FUNDS(MuleErrors.VALIDATION); private ErrorTypeDefinition> parent; BalanceError(ErrorTypeDefinition> parent) { this.parent = parent; } @Override public Optional>> getParent() { return Optional.ofNullable(parent); } } ``` バリデーターのメソッドには、検証がスローできるすべてのエラー種別を認識する ​`ErrorTypeProvider`​ が必要です。この場合、メソッドがスローできるエラーの種別は ​**BALANCE:INSUFFICIENT\_FUNDS**​ のみであることを指定する ​`ErrorTypeProvider`​ を作成します。 ```java public class BalanceErrorsProvider implements ErrorTypeProvider { @Override public Set getErrorTypes() { HashSet errors = new HashSet<>(); errors.add(BalanceError.INSUFFICIENT_FUNDS); return errors; } } ``` # Validation Module の移行 Mule 4 の Validation Module は、Mule 3 の Validation Module と非常に似ています。これらのメジャーバージョン間で最も大きな影響を受けたのは、エラー処理と式のサポートでした。 Mule 4 拡張機能では、別の方法でエラー種別を使用してエラーを宣言するので、エラー処理が異なります。式に関しては、Mule 4 では MEL 式がサポートされるのは互換性のあるモジュール内のみで、それ以外の式はすべて DataWeave 式にする必要があります。 このセクションの内容 - [エラーの種類](#errors) - [MEL 式の関数から DataWeave の関数へ](#functions) - [All スコープの使用](#all_scope) - [カスタムバリデーターのビルド](#custom_validator) ## [](#errors)エラーの種類 Mule 3 の Validation Module は、検証中に失敗すると同じ例外または設定された例外をスローします。ユーザーはエラーに応じたメッセージをカスタマイズできます。一方、Mule 4 では、モジュールが独自のエラー種別を宣言します。このモジュールの場合、検証操作には、失敗した検証の種別を暗黙に示すさまざまなエラー種別があります。​`all`​ スコープの場合、​`all`​ スコープの内側で失敗した検証に関係なく、種別は ​**VALIDATION:MULTIPLE**​ です。エラーメッセージをカスタマイズするか、デフォルトのエラーメッセージを使用できます。 以下の例は、変数 email が有効なメールでない場合に失敗するバリデーターを示しています。 Mule 3 の例 ```xml ``` この検証が失敗すると、​**ValidationException**​ がスローされます。 Mule 4 の例 ```xml ``` この検証が失敗すると、エラーの種別は ​**VALIDATION:INVALID\_EMAIL**​ になります。 ## [](#functions)MEL 式の関数から DataWeave の関数へ 式で検証を実行できた Mule 3 と同じように、Mule 4 でも検証を行うことができます。 相違点は、Mule 4 の場合、これらの検証は MEL 式ではなく DataWeave 式内でコールされることです。 Mule 4 でサポートされている関数は ​`isEmail`​、​`matchesRegex`​、​`isTime`​、​`isNumber`​、​`isIp`​、​`isUrl`​ です。 以下の例は、unknownVariable という変数のコンテンツが有効なメールか、有効な URL か、またはどちらでもない場合に応じて、異なる操作を実行する方法を示しています。 Mule 3 の例 ```xml ``` MEL 式の内側でバリデーターを使用して検証メソッドにアクセスしました。 Mule 4 の例 ```xml ``` Validation Module には、DataWeave 式内からコールされるよう宣言された関数があります。 Mule 4 のその他の関数と同じく、これらは ExtensionName::functionName、この場合は ​`Validation::isEmail(vars.email)`​ を使用して呼び出されます。 ## [](#all_scope)All スコープの使用 Mule 4 では、dsl の一部が若干変更されただけで、Mule 3 と同じように一連の検証をグループ化することができます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#custom_validator)カスタムバリデーターのビルド カスタムバリデーターは、拡張機能バリデーターに置き換わりました。これらのバリデーターは、操作のようなものですが、常に void を返すという相違点があります。検証が失敗したことを示すために、Java メソッドは ​`ModuleException`​ とそれぞれのエラー種別をスローする必要があります。これらのバリデーターを使用することで、失敗した検証をより適切に説明する独自のエラー種別を作成できます。これらを使用するユーザーエクスペリエンスは、その他の操作を使用する場合と同じです。拡張機能バリデーターについての詳細は、拡張機能バリデーターに関するドキュメントを参照してください。 **注意:**​ これらのバリデーターは、​`all`​ 検証スコープの内側でも使用できます。 Mule 3 のカスタムバリデーターを Mule 4 に移行する方法を見てみましょう。以下の例から、以前はイベント全体を取得し、そこから検証に必要な情報を取得していたことがわかります。 Mule 4 の例では、バリデーターに必要なパラメーターのみを提供しています。 Mule 3 の例 これは、dsl でカスタムバリデーターがどのように記述されていたかを示しています。 ```xml ``` これは、バリデーターインターフェースがどのように実行されたかを示しています。検証のために取得した情報は、メッセージの特定の部分に関するものである必要がありました。この場合は、フロー変数である price と balance です。 ```java public class BalanceValidator implements Validator { @Override public ValidationResult validate(MuleEvent event) { Integer price = new Integer((String) event.getMessage().getInvocationProperty("price")); Integer balance = new Integer((String) event.getMessage().getInvocationProperty("balance")); return new ValidationResult() { @Override public boolean isError() { return price > balance; } @Override public String getMessage() { return "There is not enough money to make the transaction"; } }; } } ``` Mule 4 の例 これは、Mule 4 で拡張機能バリデーターを使用する方法を示しています。名前空間とタグ名から、何を検証しているのかがわかりやすくなっています。また、ここにあるパラメーターは dsl の一部です。変数に設定する代わりに、ここに式を入力することができます。 ```xml ``` これを実行するために、​`balance`​ という簡単な拡張機能を作成します。 ```java @Operations({BalanceOperations.class}) @Extension(name = "balance") @ErrorTypes(BalanceError.class) public class BalanceExtension { } ``` `BalanceOperations`​ クラスに検証メソッドを追加し、​`@Validator`​ で注釈を付けます。このメソッドは、汎用的な検証エラー種別から取得するエラー種別をスローする必要があります。 ```java public class BalanceOperations { @Validator @Throws(BalanceErrorsProvider.class) public void hasSufficientFunds(Integer balance, Integer price) throws Exception { if (price > balance){ throw new ModuleException(BalanceError.INSUFFICIENT_FUNDS, new IllegalArgumentException("There is not enough money to make the transaction")); } } } ``` 次に、検証が失敗した場合にスローされるエラーを作成します。これには検証の失敗に応じた名前が付いています。 ```java public enum BalanceError implements ErrorTypeDefinition { INSUFFICIENT_FUNDS(MuleErrors.VALIDATION); private ErrorTypeDefinition> parent; BalanceError(ErrorTypeDefinition> parent) { this.parent = parent; } @Override public Optional>> getParent() { return Optional.ofNullable(parent); } } ``` バリデーターのメソッドには、検証がスローできるすべてのエラー種別を認識する ​`ErrorTypeProvider`​ が必要です。この場合、メソッドがスローできるエラーの種別は ​**BALANCE:INSUFFICIENT\_FUNDS**​ のみであることを指定する ​`ErrorTypeProvider`​ を作成します。 ```java public class BalanceErrorsProvider implements ErrorTypeProvider { @Override public Set getErrorTypes() { HashSet errors = new HashSet<>(); errors.add(BalanceError.INSUFFICIENT_FUNDS); return errors; } } ``` # Validation Module の移行 Mule 4 の Validation Module は、Mule 3 の Validation Module と非常に似ています。これらのメジャーバージョン間で最も大きな影響を受けたのは、エラー処理と式のサポートでした。 Mule 4 拡張機能では、別の方法でエラー種別を使用してエラーを宣言するので、エラー処理が異なります。式に関しては、Mule 4 では MEL 式がサポートされるのは互換性のあるモジュール内のみで、それ以外の式はすべて DataWeave 式にする必要があります。 このセクションの内容 - [エラー種別](#errors) - [MEL 式の関数から DataWeave の関数へ](#functions) - [All スコープの使用](#all_scope) - [カスタムバリデーターのビルド](#custom_validator) ## [](#errors)エラー種別 Mule 3 の Validation Module は、検証中に失敗すると同じ例外または設定された例外をスローします。ユーザーはエラーに応じたメッセージをカスタマイズできます。一方、Mule 4 では、モジュールが独自のエラー種別を宣言します。このモジュールの場合、検証操作には、失敗した検証の種別を暗黙に示すさまざまなエラー種別があります。​`all`​ スコープの場合、​`all`​ スコープの内側で失敗した検証に関係なく、種別は ​**VALIDATION:MULTIPLE**​ です。エラーメッセージをカスタマイズするか、デフォルトのエラーメッセージを使用できます。 以下の例は、変数 email が有効なメールでない場合に失敗するバリデーターを示しています。 Mule 3 の例 ```xml ``` この検証が失敗すると、​**ValidationException**​ がスローされます。 Mule 4 の例 ```xml ``` この検証が失敗すると、エラーの種別は ​**VALIDATION:INVALID\_EMAIL**​ になります。 ## [](#functions)MEL 式の関数から DataWeave の関数へ 式で検証を実行できた Mule 3 と同じように、Mule 4 でも検証を行うことができます。 相違点は、Mule 4 の場合、これらの検証は MEL 式ではなく DataWeave 式内でコールされることです。 Mule 4 でサポートされている関数は ​`isEmail`​、​`matchesRegex`​、​`isTime`​、​`isNumber`​、​`isIp`​、​`isUrl`​ です。 以下の例は、unknownVariable という変数のコンテンツが有効なメールか、有効な URL か、またはどちらでもない場合に応じて、異なる操作を実行する方法を示しています。 Mule 3 の例 ```xml ``` MEL 式の内側でバリデーターを使用して検証メソッドにアクセスしました。 Mule 4 の例 ```xml ``` Validation Module には、DataWeave 式内からコールされるよう宣言された関数があります。 Mule 4 のその他の関数と同じく、これらは ExtensionName::functionName、この場合は ​`Validation::isEmail(vars.email)`​ を使用して呼び出されます。 ## [](#all_scope)All スコープの使用 Mule 4 では、dsl の一部が若干変更されただけで、Mule 3 と同じように一連の検証をグループ化することができます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#custom_validator)カスタムバリデーターのビルド カスタムバリデーターは、拡張機能バリデーターに置き換わりました。これらのバリデーターは、操作のようなものですが、常に void を返すという相違点があります。検証が失敗したことを示すために、Java メソッドは ​`ModuleException`​ とそれぞれのエラー種別をスローする必要があります。これらのバリデーターを使用することで、失敗した検証をより適切に説明する独自のエラー種別を作成できます。これらを使用するユーザーエクスペリエンスは、その他の操作を使用する場合と同じです。拡張機能バリデーターについての詳細は、拡張機能バリデーターに関するドキュメントを参照してください。 **注意:**​ これらのバリデーターは、​`all`​ 検証スコープの内側でも使用できます。 Mule 3 のカスタムバリデーターを Mule 4 に移行する方法を見てみましょう。以下の例から、以前はイベント全体を取得し、そこから検証に必要な情報を取得していたことがわかります。 Mule 4 の例では、バリデーターに必要なパラメーターのみを提供しています。 Mule 3 の例 これは、dsl でカスタムバリデーターがどのように記述されていたかを示しています。 ```xml ``` これは、バリデーターインターフェースがどのように実行されたかを示しています。検証のために取得した情報は、メッセージの特定の部分に関するものである必要がありました。この場合は、フロー変数である price と balance です。 ```java public class BalanceValidator implements Validator { @Override public ValidationResult validate(MuleEvent event) { Integer price = new Integer((String) event.getMessage().getInvocationProperty("price")); Integer balance = new Integer((String) event.getMessage().getInvocationProperty("balance")); return new ValidationResult() { @Override public boolean isError() { return price > balance; } @Override public String getMessage() { return "There is not enough money to make the transaction"; } }; } } ``` Mule 4 の例 これは、Mule 4 で拡張機能バリデーターを使用する方法を示しています。名前空間とタグ名から、何を検証しているのかがわかりやすくなっています。また、ここにあるパラメーターは dsl の一部です。変数に設定する代わりに、ここに式を入力することができます。 ```xml ``` これを実行するために、​`balance`​ という簡単な拡張機能を作成します。 ```java @Operations({BalanceOperations.class}) @Extension(name = "balance") @ErrorTypes(BalanceError.class) public class BalanceExtension { } ``` `BalanceOperations`​ クラスに検証メソッドを追加し、​`@Validator`​ で注釈を付けます。このメソッドは、汎用的な検証エラー種別から取得するエラー種別をスローする必要があります。 ```java public class BalanceOperations { @Validator @Throws(BalanceErrorsProvider.class) public void hasSufficientFunds(Integer balance, Integer price) throws Exception { if (price > balance){ throw new ModuleException(BalanceError.INSUFFICIENT_FUNDS, new IllegalArgumentException("There is not enough money to make the transaction")); } } } ``` 次に、検証が失敗した場合にスローされるエラーを作成します。これには検証の失敗に応じた名前が付いています。 ```java public enum BalanceError implements ErrorTypeDefinition { INSUFFICIENT_FUNDS(MuleErrors.VALIDATION); private ErrorTypeDefinition> parent; BalanceError(ErrorTypeDefinition> parent) { this.parent = parent; } @Override public Optional>> getParent() { return Optional.ofNullable(parent); } } ``` バリデーターのメソッドには、検証がスローできるすべてのエラー種別を認識する ​`ErrorTypeProvider`​ が必要です。この場合、メソッドがスローできるエラーの種別は ​**BALANCE:INSUFFICIENT\_FUNDS**​ のみであることを指定する ​`ErrorTypeProvider`​ を作成します。 ```java public class BalanceErrorsProvider implements ErrorTypeProvider { @Override public Set getErrorTypes() { HashSet errors = new HashSet<>(); errors.add(BalanceError.INSUFFICIENT_FUNDS); return errors; } } ``` # Validation Module の移行 Mule 4 の Validation Module は、Mule 3 の Validation Module と非常に似ています。これらのメジャーバージョン間で最も大きな影響を受けたのは、エラー処理と式のサポートでした。 Mule 4 拡張機能では、別の方法でエラー種別を使用してエラーを宣言するので、エラー処理が異なります。式に関しては、Mule 4 では MEL 式がサポートされるのは互換性のあるモジュール内のみで、それ以外の式はすべて DataWeave 式にする必要があります。 このセクションの内容 - [エラーの種類](#errors) - [MEL 式の関数から DataWeave の関数へ](#functions) - [All スコープの使用](#all_scope) - [カスタムバリデーターのビルド](#custom_validator) ## [](#errors)エラーの種類 Mule 3 の Validation Module は、検証中に失敗すると同じ例外または設定された例外をスローします。ユーザーはエラーに応じたメッセージをカスタマイズできます。一方、Mule 4 では、モジュールが独自のエラー種別を宣言します。このモジュールの場合、検証操作には、失敗した検証の種別を暗黙に示すさまざまなエラー種別があります。​`all`​ スコープの場合、​`all`​ スコープの内側で失敗した検証に関係なく、種別は ​**VALIDATION:MULTIPLE**​ です。エラーメッセージをカスタマイズするか、デフォルトのエラーメッセージを使用できます。 以下の例は、変数 email が有効なメールでない場合に失敗するバリデーターを示しています。 Mule 3 の例 ```xml ``` この検証が失敗すると、​**ValidationException**​ がスローされます。 Mule 4 の例 ```xml ``` この検証が失敗すると、エラーの種別は ​**VALIDATION:INVALID\_EMAIL**​ になります。 ## [](#functions)MEL 式の関数から DataWeave の関数へ 式で検証を実行できた Mule 3 と同じように、Mule 4 でも検証を行うことができます。 相違点は、Mule 4 の場合、これらの検証は MEL 式ではなく DataWeave 式内でコールされることです。 Mule 4 でサポートされている関数は ​`isEmail`​、​`matchesRegex`​、​`isTime`​、​`isNumber`​、​`isIp`​、​`isUrl`​ です。 以下の例は、unknownVariable という変数のコンテンツが有効なメールか、有効な URL か、またはどちらでもない場合に応じて、異なる操作を実行する方法を示しています。 Mule 3 の例 ```xml ``` MEL 式の内側でバリデーターを使用して検証メソッドにアクセスしました。 Mule 4 の例 ```xml ``` Validation Module には、DataWeave 式内からコールされるよう宣言された関数があります。 Mule 4 のその他の関数と同じく、これらは ExtensionName::functionName、この場合は ​`Validation::isEmail(vars.email)`​ を使用して呼び出されます。 ## [](#all_scope)All スコープの使用 Mule 4 では、dsl の一部が若干変更されただけで、Mule 3 と同じように一連の検証をグループ化することができます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#custom_validator)カスタムバリデーターのビルド カスタムバリデーターは、拡張機能バリデーターに置き換わりました。これらのバリデーターは、操作のようなものですが、常に void を返すという相違点があります。検証が失敗したことを示すために、Java メソッドは ​`ModuleException`​ とそれぞれのエラー種別をスローする必要があります。これらのバリデーターを使用することで、失敗した検証をより適切に説明する独自のエラー種別を作成できます。これらを使用するユーザーエクスペリエンスは、その他の操作を使用する場合と同じです。拡張機能バリデーターについての詳細は、拡張機能バリデーターに関するドキュメントを参照してください。 **注意:**​ これらのバリデーターは、​`all`​ 検証スコープの内側でも使用できます。 Mule 3 のカスタムバリデーターを Mule 4 に移行する方法を見てみましょう。以下の例から、以前はイベント全体を取得し、そこから検証に必要な情報を取得していたことがわかります。 Mule 4 の例では、バリデーターに必要なパラメーターのみを提供しています。 Mule 3 の例 これは、dsl でカスタムバリデーターがどのように記述されていたかを示しています。 ```xml ``` これは、バリデーターインターフェースがどのように実行されたかを示しています。検証のために取得した情報は、メッセージの特定の部分に関するものである必要がありました。この場合は、フロー変数である price と balance です。 ```java public class BalanceValidator implements Validator { @Override public ValidationResult validate(MuleEvent event) { Integer price = new Integer((String) event.getMessage().getInvocationProperty("price")); Integer balance = new Integer((String) event.getMessage().getInvocationProperty("balance")); return new ValidationResult() { @Override public boolean isError() { return price > balance; } @Override public String getMessage() { return "There is not enough money to make the transaction"; } }; } } ``` Mule 4 の例 これは、Mule 4 で拡張機能バリデーターを使用する方法を示しています。名前空間とタグ名から、何を検証しているのかがわかりやすくなっています。また、ここにあるパラメーターは dsl の一部です。変数に設定する代わりに、ここに式を入力することができます。 ```xml ``` これを実行するために、​`balance`​ という簡単な拡張機能を作成します。 ```java @Operations({BalanceOperations.class}) @Extension(name = "balance") @ErrorTypes(BalanceError.class) public class BalanceExtension { } ``` `BalanceOperations`​ クラスに検証メソッドを追加し、​`@Validator`​ で注釈を付けます。このメソッドは、汎用的な検証エラー種別から取得するエラー種別をスローする必要があります。 ```java public class BalanceOperations { @Validator @Throws(BalanceErrorsProvider.class) public void hasSufficientFunds(Integer balance, Integer price) throws Exception { if (price > balance){ throw new ModuleException(BalanceError.INSUFFICIENT_FUNDS, new IllegalArgumentException("There is not enough money to make the transaction")); } } } ``` 次に、検証が失敗した場合にスローされるエラーを作成します。これには検証の失敗に応じた名前が付いています。 ```java public enum BalanceError implements ErrorTypeDefinition { INSUFFICIENT_FUNDS(MuleErrors.VALIDATION); private ErrorTypeDefinition> parent; BalanceError(ErrorTypeDefinition> parent) { this.parent = parent; } @Override public Optional>> getParent() { return Optional.ofNullable(parent); } } ``` バリデーターのメソッドには、検証がスローできるすべてのエラー種別を認識する ​`ErrorTypeProvider`​ が必要です。この場合、メソッドがスローできるエラーの種別は ​**BALANCE:INSUFFICIENT\_FUNDS**​ のみであることを指定する ​`ErrorTypeProvider`​ を作成します。 ```java public class BalanceErrorsProvider implements ErrorTypeProvider { @Override public Set getErrorTypes() { HashSet errors = new HashSet<>(); errors.add(BalanceError.INSUFFICIENT_FUNDS); return errors; } } ``` # Validation Module の移行 Mule 4 の Validation Module は、Mule 3 の Validation Module と非常に似ています。これらのメジャーバージョン間で最も大きな影響を受けたのは、エラー処理と式のサポートでした。 Mule 4 拡張機能では、別の方法でエラー種別を使用してエラーを宣言するので、エラー処理が異なります。式に関しては、Mule 4 では MEL 式がサポートされるのは互換性のあるモジュール内のみで、それ以外の式はすべて DataWeave 式にする必要があります。 このセクションの内容 - [エラーの種類](#errors) - [MEL 式の関数から DataWeave の関数へ](#functions) - [All スコープの使用](#all_scope) - [カスタムバリデーターのビルド](#custom_validator) ## [](#errors)エラーの種類 Mule 3 の Validation Module は、検証中に失敗すると同じ例外または設定された例外をスローします。ユーザーはエラーに応じたメッセージをカスタマイズできます。一方、Mule 4 では、モジュールが独自のエラー種別を宣言します。このモジュールの場合、検証操作には、失敗した検証の種別を暗黙に示すさまざまなエラー種別があります。​`all`​ スコープの場合、​`all`​ スコープの内側で失敗した検証に関係なく、種別は ​**VALIDATION:MULTIPLE**​ です。エラーメッセージをカスタマイズするか、デフォルトのエラーメッセージを使用できます。 以下の例は、変数 email が有効なメールでない場合に失敗するバリデーターを示しています。 Mule 3 の例 ```xml ``` この検証が失敗すると、​**ValidationException**​ がスローされます。 Mule 4 の例 ```xml ``` この検証が失敗すると、エラーの種別は ​**VALIDATION:INVALID\_EMAIL**​ になります。 ## [](#functions)MEL 式の関数から DataWeave の関数へ 式で検証を実行できた Mule 3 と同じように、Mule 4 でも検証を行うことができます。 相違点は、Mule 4 の場合、これらの検証は MEL 式ではなく DataWeave 式内でコールされることです。 Mule 4 でサポートされている関数は ​`isEmail`​、​`matchesRegex`​、​`isTime`​、​`isNumber`​、​`isIp`​、​`isUrl`​ です。 以下の例は、unknownVariable という変数のコンテンツが有効なメールか、有効な URL か、またはどちらでもない場合に応じて、異なる操作を実行する方法を示しています。 Mule 3 の例 ```xml ``` MEL 式の内側でバリデーターを使用して検証メソッドにアクセスしました。 Mule 4 の例 ```xml ``` Validation Module には、DataWeave 式内からコールされるよう宣言された関数があります。 Mule 4 のその他の関数と同じく、これらは ExtensionName::functionName、この場合は ​`Validation::isEmail(vars.email)`​ を使用して呼び出されます。 ## [](#all_scope)All スコープの使用 Mule 4 では、dsl の一部が若干変更されただけで、Mule 3 と同じように一連の検証をグループ化することができます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#custom_validator)カスタムバリデーターのビルド カスタムバリデーターは、拡張機能バリデーターに置き換わりました。これらのバリデーターは、操作のようなものですが、常に void を返すという相違点があります。検証が失敗したことを示すために、Java メソッドは ​`ModuleException`​ とそれぞれのエラー種別をスローする必要があります。これらのバリデーターを使用することで、失敗した検証をより適切に説明する独自のエラー種別を作成できます。これらを使用するユーザーエクスペリエンスは、その他の操作を使用する場合と同じです。拡張機能バリデーターについての詳細は、拡張機能バリデーターに関するドキュメントを参照してください。 **注意:**​ これらのバリデーターは、​`all`​ 検証スコープの内側でも使用できます。 Mule 3 のカスタムバリデーターを Mule 4 に移行する方法を見てみましょう。以下の例から、以前はイベント全体を取得し、そこから検証に必要な情報を取得していたことがわかります。 Mule 4 の例では、バリデーターに必要なパラメーターのみを提供しています。 Mule 3 の例 これは、dsl でカスタムバリデーターがどのように記述されていたかを示しています。 ```xml ``` これは、バリデーターインターフェースがどのように実行されたかを示しています。検証のために取得した情報は、メッセージの特定の部分に関するものである必要がありました。この場合は、フロー変数である price と balance です。 ```java public class BalanceValidator implements Validator { @Override public ValidationResult validate(MuleEvent event) { Integer price = new Integer((String) event.getMessage().getInvocationProperty("price")); Integer balance = new Integer((String) event.getMessage().getInvocationProperty("balance")); return new ValidationResult() { @Override public boolean isError() { return price > balance; } @Override public String getMessage() { return "There is not enough money to make the transaction"; } }; } } ``` Mule 4 の例 これは、Mule 4 で拡張機能バリデーターを使用する方法を示しています。名前空間とタグ名から、何を検証しているのかがわかりやすくなっています。また、ここにあるパラメーターは dsl の一部です。変数に設定する代わりに、ここに式を入力することができます。 ```xml ``` これを実行するために、​`balance`​ という簡単な拡張機能を作成します。 ```java @Operations({BalanceOperations.class}) @Extension(name = "balance") @ErrorTypes(BalanceError.class) public class BalanceExtension { } ``` `BalanceOperations`​ クラスに検証メソッドを追加し、​`@Validator`​ で注釈を付けます。このメソッドは、汎用的な検証エラー種別から取得するエラー種別をスローする必要があります。 ```java public class BalanceOperations { @Validator @Throws(BalanceErrorsProvider.class) public void hasSufficientFunds(Integer balance, Integer price) throws Exception { if (price > balance){ throw new ModuleException(BalanceError.INSUFFICIENT_FUNDS, new IllegalArgumentException("There is not enough money to make the transaction")); } } } ``` 次に、検証が失敗した場合にスローされるエラーを作成します。これには検証の失敗に応じた名前が付いています。 ```java public enum BalanceError implements ErrorTypeDefinition { INSUFFICIENT_FUNDS(MuleErrors.VALIDATION); private ErrorTypeDefinition> parent; BalanceError(ErrorTypeDefinition> parent) { this.parent = parent; } @Override public Optional>> getParent() { return Optional.ofNullable(parent); } } ``` バリデーターのメソッドには、検証がスローできるすべてのエラー種別を認識する ​`ErrorTypeProvider`​ が必要です。この場合、メソッドがスローできるエラーの種別は ​**BALANCE:INSUFFICIENT\_FUNDS**​ のみであることを指定する ​`ErrorTypeProvider`​ を作成します。 ```java public class BalanceErrorsProvider implements ErrorTypeProvider { @Override public Set getErrorTypes() { HashSet errors = new HashSet<>(); errors.add(BalanceError.INSUFFICIENT_FUNDS); return errors; } } ``` # Validation Module の移行 Mule 4 の Validation Module は、Mule 3 の Validation Module と非常に似ています。これらのメジャーバージョン間で最も大きな影響を受けたのは、エラー処理と式のサポートでした。 Mule 4 拡張機能では、別の方法でエラー種別を使用してエラーを宣言するので、エラー処理が異なります。式に関しては、Mule 4 では MEL 式がサポートされるのは互換性のあるモジュール内のみで、それ以外の式はすべて DataWeave 式にする必要があります。 このセクションの内容 - [エラーの種類](#errors) - [MEL 式の関数から DataWeave の関数へ](#functions) - [All スコープの使用](#all_scope) - [カスタムバリデーターのビルド](#custom_validator) ## [](#errors)エラーの種類 Mule 3 の Validation Module は、検証中に失敗すると同じ例外または設定された例外をスローします。ユーザーはエラーに応じたメッセージをカスタマイズできます。一方、Mule 4 では、モジュールが独自のエラー種別を宣言します。このモジュールの場合、検証操作には、失敗した検証の種別を暗黙に示すさまざまなエラー種別があります。​`all`​ スコープの場合、​`all`​ スコープの内側で失敗した検証に関係なく、種別は ​**VALIDATION:MULTIPLE**​ です。エラーメッセージをカスタマイズするか、デフォルトのエラーメッセージを使用できます。 以下の例は、変数 email が有効なメールでない場合に失敗するバリデーターを示しています。 Mule 3 の例 ```xml ``` この検証が失敗すると、​**ValidationException**​ がスローされます。 Mule 4 の例 ```xml ``` この検証が失敗すると、エラーの種別は ​**VALIDATION:INVALID\_EMAIL**​ になります。 ## [](#functions)MEL 式の関数から DataWeave の関数へ 式で検証を実行できた Mule 3 と同じように、Mule 4 でも検証を行うことができます。 相違点は、Mule 4 の場合、これらの検証は MEL 式ではなく DataWeave 式内でコールされることです。 Mule 4 でサポートされている関数は ​`isEmail`​、​`matchesRegex`​、​`isTime`​、​`isNumber`​、​`isIp`​、​`isUrl`​ です。 以下の例は、unknownVariable という変数のコンテンツが有効なメールか、有効な URL か、またはどちらでもない場合に応じて、異なる操作を実行する方法を示しています。 Mule 3 の例 ```xml ``` MEL 式の内側でバリデーターを使用して検証メソッドにアクセスしました。 Mule 4 の例 ```xml ``` Validation Module には、DataWeave 式内からコールされるよう宣言された関数があります。 Mule 4 のその他の関数と同じく、これらは ExtensionName::functionName、この場合は ​`Validation::isEmail(vars.email)`​ を使用して呼び出されます。 ## [](#all_scope)All スコープの使用 Mule 4 では、dsl の一部が若干変更されただけで、Mule 3 と同じように一連の検証をグループ化することができます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#custom_validator)カスタムバリデーターのビルド カスタムバリデーターは、拡張機能バリデーターに置き換わりました。これらのバリデーターは、操作のようなものですが、常に void を返すという相違点があります。検証が失敗したことを示すために、Java メソッドは ​`ModuleException`​ とそれぞれのエラー種別をスローする必要があります。これらのバリデーターを使用することで、失敗した検証をより適切に説明する独自のエラー種別を作成できます。これらを使用するユーザーエクスペリエンスは、その他の操作を使用する場合と同じです。拡張機能バリデーターについての詳細は、拡張機能バリデーターに関するドキュメントを参照してください。 **注意:**​ これらのバリデーターは、​`all`​ 検証スコープの内側でも使用できます。 Mule 3 のカスタムバリデーターを Mule 4 に移行する方法を見てみましょう。以下の例から、以前はイベント全体を取得し、そこから検証に必要な情報を取得していたことがわかります。 Mule 4 の例では、バリデーターに必要なパラメーターのみを提供しています。 Mule 3 の例 これは、dsl でカスタムバリデーターがどのように記述されていたかを示しています。 ```xml ``` これは、バリデーターインターフェースがどのように実行されたかを示しています。検証のために取得した情報は、メッセージの特定の部分に関するものである必要がありました。この場合は、フロー変数である price と balance です。 ```java public class BalanceValidator implements Validator { @Override public ValidationResult validate(MuleEvent event) { Integer price = new Integer((String) event.getMessage().getInvocationProperty("price")); Integer balance = new Integer((String) event.getMessage().getInvocationProperty("balance")); return new ValidationResult() { @Override public boolean isError() { return price > balance; } @Override public String getMessage() { return "There is not enough money to make the transaction"; } }; } } ``` Mule 4 の例 これは、Mule 4 で拡張機能バリデーターを使用する方法を示しています。名前空間とタグ名から、何を検証しているのかがわかりやすくなっています。また、ここにあるパラメーターは dsl の一部です。変数に設定する代わりに、ここに式を入力することができます。 ```xml ``` これを実行するために、​`balance`​ という簡単な拡張機能を作成します。 ```java @Operations({BalanceOperations.class}) @Extension(name = "balance") @ErrorTypes(BalanceError.class) public class BalanceExtension { } ``` `BalanceOperations`​ クラスに検証メソッドを追加し、​`@Validator`​ で注釈を付けます。このメソッドは、汎用的な検証エラー種別から取得するエラー種別をスローする必要があります。 ```java public class BalanceOperations { @Validator @Throws(BalanceErrorsProvider.class) public void hasSufficientFunds(Integer balance, Integer price) throws Exception { if (price > balance){ throw new ModuleException(BalanceError.INSUFFICIENT_FUNDS, new IllegalArgumentException("There is not enough money to make the transaction")); } } } ``` 次に、検証が失敗した場合にスローされるエラーを作成します。これには検証の失敗に応じた名前が付いています。 ```java public enum BalanceError implements ErrorTypeDefinition { INSUFFICIENT_FUNDS(MuleErrors.VALIDATION); private ErrorTypeDefinition> parent; BalanceError(ErrorTypeDefinition> parent) { this.parent = parent; } @Override public Optional>> getParent() { return Optional.ofNullable(parent); } } ``` バリデーターのメソッドには、検証がスローできるすべてのエラー種別を認識する ​`ErrorTypeProvider`​ が必要です。この場合、メソッドがスローできるエラーの種別は ​**BALANCE:INSUFFICIENT\_FUNDS**​ のみであることを指定する ​`ErrorTypeProvider`​ を作成します。 ```java public class BalanceErrorsProvider implements ErrorTypeProvider { @Override public Set getErrorTypes() { HashSet errors = new HashSet<>(); errors.add(BalanceError.INSUFFICIENT_FUNDS); return errors; } } ``` # Validation Module の移行 Mule 4 の Validation Module は、Mule 3 の Validation Module と非常に似ています。これらのメジャーバージョン間で最も大きな影響を受けたのは、エラー処理と式のサポートでした。 Mule 4 拡張機能では、別の方法でエラー種別を使用してエラーを宣言するので、エラー処理が異なります。式に関しては、Mule 4 では MEL 式がサポートされるのは互換性のあるモジュール内のみで、それ以外の式はすべて DataWeave 式にする必要があります。 このセクションの内容 - [エラーの種類](#errors) - [MEL 式の関数から DataWeave の関数へ](#functions) - [All スコープの使用](#all_scope) - [カスタムバリデーターのビルド](#custom_validator) ## [](#errors)エラーの種類 Mule 3 の Validation Module は、検証中に失敗すると同じ例外または設定された例外をスローします。ユーザーはエラーに応じたメッセージをカスタマイズできます。一方、Mule 4 では、モジュールが独自のエラー種別を宣言します。このモジュールの場合、検証操作には、失敗した検証の種別を暗黙に示すさまざまなエラー種別があります。​`all`​ スコープの場合、​`all`​ スコープの内側で失敗した検証に関係なく、種別は ​**VALIDATION:MULTIPLE**​ です。エラーメッセージをカスタマイズするか、デフォルトのエラーメッセージを使用できます。 以下の例は、変数 email が有効なメールでない場合に失敗するバリデーターを示しています。 Mule 3 の例 ```xml ``` この検証が失敗すると、​**ValidationException**​ がスローされます。 Mule 4 の例 ```xml ``` この検証が失敗すると、エラーの種別は ​**VALIDATION:INVALID\_EMAIL**​ になります。 ## [](#functions)MEL 式の関数から DataWeave の関数へ 式で検証を実行できた Mule 3 と同じように、Mule 4 でも検証を行うことができます。 相違点は、Mule 4 の場合、これらの検証は MEL 式ではなく DataWeave 式内でコールされることです。 Mule 4 でサポートされている関数は ​`isEmail`​、​`matchesRegex`​、​`isTime`​、​`isNumber`​、​`isIp`​、​`isUrl`​ です。 以下の例は、unknownVariable という変数のコンテンツが有効なメールか、有効な URL か、またはどちらでもない場合に応じて、異なる操作を実行する方法を示しています。 Mule 3 の例 ```xml ``` MEL 式の内側でバリデーターを使用して検証メソッドにアクセスしました。 Mule 4 の例 ```xml ``` Validation Module には、DataWeave 式内からコールされるよう宣言された関数があります。 Mule 4 のその他の関数と同じく、これらは ExtensionName::functionName、この場合は ​`Validation::isEmail(vars.email)`​ を使用して呼び出されます。 ## [](#all_scope)All スコープの使用 Mule 4 では、dsl の一部が若干変更されただけで、Mule 3 と同じように一連の検証をグループ化することができます。 Mule 3 の例 ```xml ``` Mule 4 の例 ```xml ``` ## [](#custom_validator)カスタムバリデーターのビルド カスタムバリデーターは、拡張機能バリデーターに置き換わりました。これらのバリデーターは、操作のようなものですが、常に void を返すという相違点があります。検証が失敗したことを示すために、Java メソッドは ​`ModuleException`​ とそれぞれのエラー種別をスローする必要があります。これらのバリデーターを使用することで、失敗した検証をより適切に説明する独自のエラー種別を作成できます。これらを使用するユーザーエクスペリエンスは、その他の操作を使用する場合と同じです。拡張機能バリデーターについての詳細は、拡張機能バリデーターに関するドキュメントを参照してください。 **注意:**​ これらのバリデーターは、​`all`​ 検証スコープの内側でも使用できます。 Mule 3 のカスタムバリデーターを Mule 4 に移行する方法を見てみましょう。以下の例から、以前はイベント全体を取得し、そこから検証に必要な情報を取得していたことがわかります。 Mule 4 の例では、バリデーターに必要なパラメーターのみを提供しています。 Mule 3 の例 これは、dsl でカスタムバリデーターがどのように記述されていたかを示しています。 ```xml ``` これは、バリデーターインターフェースがどのように実行されたかを示しています。検証のために取得した情報は、メッセージの特定の部分に関するものである必要がありました。この場合は、フロー変数である price と balance です。 ```java public class BalanceValidator implements Validator { @Override public ValidationResult validate(MuleEvent event) { Integer price = new Integer((String) event.getMessage().getInvocationProperty("price")); Integer balance = new Integer((String) event.getMessage().getInvocationProperty("balance")); return new ValidationResult() { @Override public boolean isError() { return price > balance; } @Override public String getMessage() { return "There is not enough money to make the transaction"; } }; } } ``` Mule 4 の例 これは、Mule 4 で拡張機能バリデーターを使用する方法を示しています。名前空間とタグ名から、何を検証しているのかがわかりやすくなっています。また、ここにあるパラメーターは dsl の一部です。変数に設定する代わりに、ここに式を入力することができます。 ```xml ``` これを実行するために、​`balance`​ という簡単な拡張機能を作成します。 ```java @Operations({BalanceOperations.class}) @Extension(name = "balance") @ErrorTypes(BalanceError.class) public class BalanceExtension { } ``` `BalanceOperations`​ クラスに検証メソッドを追加し、​`@Validator`​ で注釈を付けます。このメソッドは、汎用的な検証エラー種別から取得するエラー種別をスローする必要があります。 ```java public class BalanceOperations { @Validator @Throws(BalanceErrorsProvider.class) public void hasSufficientFunds(Integer balance, Integer price) throws Exception { if (price > balance){ throw new ModuleException(BalanceError.INSUFFICIENT_FUNDS, new IllegalArgumentException("There is not enough money to make the transaction")); } } } ``` 次に、検証が失敗した場合にスローされるエラーを作成します。これには検証の失敗に応じた名前が付いています。 ```java public enum BalanceError implements ErrorTypeDefinition { INSUFFICIENT_FUNDS(MuleErrors.VALIDATION); private ErrorTypeDefinition> parent; BalanceError(ErrorTypeDefinition> parent) { this.parent = parent; } @Override public Optional>> getParent() { return Optional.ofNullable(parent); } } ``` バリデーターのメソッドには、検証がスローできるすべてのエラー種別を認識する ​`ErrorTypeProvider`​ が必要です。この場合、メソッドがスローできるエラーの種別は ​**BALANCE:INSUFFICIENT\_FUNDS**​ のみであることを指定する ​`ErrorTypeProvider`​ を作成します。 ```java public class BalanceErrorsProvider implements ErrorTypeProvider { @Override public Set getErrorTypes() { HashSet errors = new HashSet<>(); errors.add(BalanceError.INSUFFICIENT_FUNDS); return errors; } } ``` # VM トランスポートの移行 VM トランスポートは完全に書き換えられました。Mule 3 トランスポートモデルを操作ベースのコネクタへと進化させました。このため、多数の新しい機能が可能になります。 - ポーリングインバウンドエンドポイントのみが提供された古いトランスポートとは異なり、オンデマンドでキューからメッセージをコンシュームする機能。 - 拡張された ​[DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​。 ## [](#whats_covered_here)このトピックの内容 - [VM トランスポート設定の移行](#file_configs) - [インバウンドエンドポイントの移行](#vm_listener) - [アウトバウンドエンドポイントの移行](#vm_outbound) ## [](#file_configs)VM トランスポート設定の移行 Mule 3 では、トランスポート設定はすべて ​``​ と呼ばれる最上位レベルの要素の下に設定されます。各設定は複数のキューを処理できますが、それらはすべて一時的キューか永続的キューのいずれかでなければならないという制限がありました。一時的と永続的を組み合わせるには、個別に 2 つのトランスポート設定が必要でした。 Mule 3 の例: 永続的 VM トランスポートの定義 ```xml ``` Mule 4 では、各コネクタ設定が処理を行うキューを事前に定義します。これらのキューのそれぞれに、明確で柔軟な独自の設定を使用することができます。ただし、設定がアクセスできるのは、それぞれが定義したキューのみです。これは、誰もリスンしていないキューにメッセージをパブリッシュしないように設けられた制限です。 Mule 4 の例: VM Connector 設定の定義 ```xml ``` ## [](#vm_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用して、特定のキューのメッセージをリスンしていました。キュー内の要素ごとに、新しいメッセージがトリガーされました。 Mule 3 の例: VM インバウンドエンドポイント ```xml ... ``` この設定では、​`persistentQueue`​ と呼ばれるキューをリスンするトランザクションのインバウンドエンドポイントが定義されています。また、フローが応答を送信するものなのかどうかを判断するために、​`exchange-pattern`​ パラメーターが使用されました。​`request-response`​ に設定すると、エンドポイントはフローの最後に取得されたメッセージで応答します (この詳細は​[アウトバウンドエンドポイントの移行](#vm_outbound)​セクションで説明します)。 Mule 4 では代わりに ​``​ メッセージソースが使用されます。 Mule 4 の例: VM リスナー ```xml #[lower(payload.salute)] ... ``` 主な違いは次のとおりです。 - リスナーは config を参照しており、その config で定義されたキューのみをリスンできます。 - ``​ 要素を使用して応答を制御できるようになりました。指定しない場合、フローの最後に生成されるメッセージペイロードが設定になります。 - 応答が送信されるかどうかを制御するために ​`exchange-pattern`​ を使用する必要がなくなりました。コネクタでは、​``​ または ​``​ 操作で生成されるメッセージに応じて、送信が自動的に判断されます。 ### [](#メッセージの順次リスン)メッセージの順次リスン インバウンドエンドポイントのもう 1 つのユースケースは、メッセージの順次リスンです。Mule 3 では、これは ​`numberOfConcurrentTransactedReceivers`​ パラメーターを使用してコネクタレベルで設定する必要がありました。 Mule 3 の例: メッセージの順次リスン ```xml ``` Mule 4 では、これをリスナーレベルで行うことができます。 Mule 4 の例: メッセージの順次リスン ```xml ... ``` フローの ​`maxConcurrency`​ とリスナーの ​`numberOfConsumers`​ を両方とも 1 に設定することで、メッセージを順次処理できます。 ## [](#vm_outbound)アウトバウンドエンドポイントの移行 Mule 3 トランスポートでは、​``​ コンポーネントを使用してメッセージをキューにパブリッシュします。 Mule 3 の例: キューへのメッセージの投稿 ```xml ``` `exchange-pattern`​ パラメーターが上記の例の動作で重要な役割を果たします。パターンが ​`one-way`​ の場合はメッセージが送信され、同じメッセージペイロードを使用して実行が続行されます。​`request-response`​ が使用されている場合、同じキューでリスンしている ​``​ を使用するフローからの応答を待機し、取得した応答は次のメッセージプロセッサーに伝搬されます。 Mule 4 ではこれを 2 つの異なる操作を使用して行います。 Mule 4 の例: キューへのメッセージの投稿 ```xml #[upper(payload)] #[upper(payload)] ``` 両方の操作は同じように設定になっており、DataWeave を使用して、送信されるメッセージのコンテンツをビルドできます。ただし、​``​ 操作はコンテンツをパブリッシュし、同じメッセージを使用して続行されるのに対し、​``​ 操作は参照するキューの ​``​ から応答が生成されるのを待機します。 VM Connector を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-vm-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [ファイルコネクタについて](https://docs.mulesoft.com/jp/file-connector/latest/) # VM トランスポートの移行 VM トランスポートは完全に書き換えられました。Mule 3 トランスポートモデルを操作ベースのコネクタへと進化させました。このため、多数の新しい機能が可能になります。 - ポーリングインバウンドエンドポイントのみが提供された古いトランスポートとは異なり、オンデマンドでキューからメッセージをコンシュームする機能。 - 拡張された ​[DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​。 ## [](#whats_covered_here)このトピックの内容 - [VM トランスポート設定の移行](#file_configs) - [インバウンドエンドポイントの移行](#vm_listener) - [アウトバウンドエンドポイントの移行](#vm_outbound) ## [](#file_configs)VM トランスポート設定の移行 Mule 3 では、トランスポート設定はすべて ​``​ と呼ばれる最上位レベルの要素の下に設定されます。各設定は複数のキューを処理できますが、それらはすべて一時的キューか永続的キューのいずれかでなければならないという制限がありました。一時的と永続的を組み合わせるには、個別に 2 つのトランスポート設定が必要でした。 Mule 3 の例: 永続的 VM トランスポートの定義 ```xml ``` Mule 4 では、各コネクタ設定が処理を行うキューを事前に定義します。これらのキューのそれぞれに、明確で柔軟な独自の設定を使用することができます。ただし、設定がアクセスできるのは、それぞれが定義したキューのみです。これは、誰もリスンしていないキューにメッセージをパブリッシュしないように設けられた制限です。 Mule 4 の例: VM Connector 設定の定義 ```xml ``` ## [](#vm_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用して、特定のキューのメッセージをリスンしていました。キュー内の要素ごとに、新しいメッセージがトリガーされました。 Mule 3 の例: VM インバウンドエンドポイント ```xml ... ``` この設定では、​`persistentQueue`​ と呼ばれるキューをリスンするトランザクションのインバウンドエンドポイントが定義されています。また、フローが応答を送信するものなのかどうかを判断するために、​`exchange-pattern`​ パラメーターが使用されました。​`request-response`​ に設定すると、エンドポイントはフローの最後に取得されたメッセージで応答します (この詳細は​[アウトバウンドエンドポイントの移行](#vm_outbound)​セクションで説明します)。 Mule 4 では代わりに ​``​ イベントソースが使用されます。 Mule 4 の例: VM リスナー ```xml #[lower(payload.salute)] ... ``` 主な違いは次のとおりです。 - リスナーは config を参照しており、その config で定義されたキューのみをリスンできます。 - ``​ 要素を使用して応答を制御できるようになりました。指定しない場合、フローの最後に生成されるメッセージペイロードが設定になります。 - 応答が送信されるかどうかを制御するために ​`exchange-pattern`​ を使用する必要がなくなりました。コネクタでは、​``​ または ​``​ 操作で生成されるメッセージに応じて、送信が自動的に判断されます。 ### [](#メッセージの順次リスン)メッセージの順次リスン インバウンドエンドポイントのもう 1 つのユースケースは、メッセージの順次リスンです。Mule 3 では、これは ​`numberOfConcurrentTransactedReceivers`​ パラメーターを使用してコネクタレベルで設定する必要がありました。 Mule 3 の例: メッセージの順次リスン ```xml ``` Mule 4 では、これをリスナーレベルで行うことができます。 Mule 4 の例: メッセージの順次リスン ```xml ... ``` フローの ​`maxConcurrency`​ とリスナーの ​`numberOfConsumers`​ を両方とも 1 に設定することで、メッセージを順次処理できます。 ## [](#vm_outbound)アウトバウンドエンドポイントの移行 Mule 3 トランスポートでは、​``​ コンポーネントを使用してメッセージをキューにパブリッシュします。 Mule 3 の例: キューへのメッセージの投稿 ```xml ``` `exchange-pattern`​ パラメーターが上記の例の動作で重要な役割を果たします。パターンが ​`one-way`​ の場合はメッセージが送信され、同じメッセージペイロードを使用して実行が続行されます。​`request-response`​ が使用されている場合、同じキューでリスンしている ​``​ を使用するフローからの応答を待機し、取得した応答は次のメッセージプロセッサーに伝搬されます。 Mule 4 ではこれを 2 つの異なる操作を使用して行います。 Mule 4 の例: キューへのメッセージの投稿 ```xml #[upper(payload)] #[upper(payload)] ``` 両方の操作は同じように設定になっており、DataWeave を使用して、送信されるメッセージのコンテンツをビルドできます。ただし、​``​ 操作はコンテンツをパブリッシュし、同じメッセージを使用して続行されるのに対し、​``​ 操作は参照するキューの ​``​ から応答が生成されるのを待機します。 VM Connector を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-vm-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector について](https://docs.mulesoft.com/jp/file-connector/latest/) # VM トランスポートの移行 VM トランスポートは完全に書き換えられました。Mule 3 トランスポートモデルを操作ベースのコネクタへと進化させました。このため、多数の新しい機能が可能になります。 - ポーリングインバウンドエンドポイントのみが提供された古いトランスポートとは異なり、オンデマンドでキューからメッセージをコンシュームする機能。 - 拡張された ​[DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​。 ## [](#whats_covered_here)このトピックの内容 - [VM トランスポート設定の移行](#file_configs) - [インバウンドエンドポイントの移行](#vm_listener) - [アウトバウンドエンドポイントの移行](#vm_outbound) ## [](#file_configs)VM トランスポート設定の移行 Mule 3 では、トランスポート設定はすべて ​``​ と呼ばれる最上位レベルの要素の下に設定されます。各設定は複数のキューを処理できますが、それらはすべて一時的キューか永続的キューのいずれかでなければならないという制限がありました。一時的と永続的を組み合わせるには、個別に 2 つのトランスポート設定が必要でした。 Mule 3 の例: 永続的 VM トランスポートの定義 ```xml ``` Mule 4 では、各コネクタ設定が処理を行うキューを事前に定義します。これらのキューのそれぞれに、明確で柔軟な独自の設定を使用することができます。ただし、設定がアクセスできるのは、それぞれが定義したキューのみです。これは、誰もリスンしていないキューにメッセージをパブリッシュしないように設けられた制限です。 Mule 4 の例: VM Connector 設定の定義 ```xml ``` ## [](#vm_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用して、特定のキューのメッセージをリスンしていました。キュー内の要素ごとに、新しいメッセージがトリガーされました。 Mule 3 の例: VM インバウンドエンドポイント ```xml ... ``` この設定では、​`persistentQueue`​ と呼ばれるキューをリスンするトランザクションのインバウンドエンドポイントが定義されています。また、フローが応答を送信するものなのかどうかを判断するために、​`exchange-pattern`​ パラメーターが使用されました。​`request-response`​ に設定すると、エンドポイントはフローの最後に取得されたメッセージで応答します (この詳細は​[アウトバウンドエンドポイントの移行](#vm_outbound)​セクションで説明します)。 Mule 4 では代わりに ​``​ イベントソースが使用されます。 Mule 4 の例: VM リスナー ```xml #[lower(payload.salute)] ... ``` 主な違いは次のとおりです。 - リスナーは config を参照しており、その config で定義されたキューのみをリスンできます。 - ``​ 要素を使用して応答を制御できるようになりました。指定しない場合、フローの最後に生成されるメッセージペイロードが設定になります。 - 応答が送信されるかどうかを制御するために ​`exchange-pattern`​ を使用する必要がなくなりました。コネクタでは、​``​ または ​``​ 操作で生成されるメッセージに応じて、送信が自動的に判断されます。 ### [](#メッセージの順次リスン)メッセージの順次リスン インバウンドエンドポイントのもう 1 つのユースケースは、メッセージの順次リスンです。Mule 3 では、これは ​`numberOfConcurrentTransactedReceivers`​ パラメーターを使用してコネクタレベルで設定する必要がありました。 Mule 3 の例: メッセージの順次リスン ```xml ``` Mule 4 では、これをリスナーレベルで行うことができます。 Mule 4 の例: メッセージの順次リスン ```xml ... ``` フローの ​`maxConcurrency`​ とリスナーの ​`numberOfConsumers`​ を両方とも 1 に設定することで、メッセージを順次処理できます。 ## [](#vm_outbound)アウトバウンドエンドポイントの移行 Mule 3 トランスポートでは、​``​ コンポーネントを使用してメッセージをキューにパブリッシュします。 Mule 3 の例: キューへのメッセージの投稿 ```xml ``` `exchange-pattern`​ パラメーターが上記の例の動作で重要な役割を果たします。パターンが ​`one-way`​ の場合はメッセージが送信され、同じメッセージペイロードを使用して実行が続行されます。​`request-response`​ が使用されている場合、同じキューでリスンしている ​``​ を使用するフローからの応答を待機し、取得した応答は次のメッセージプロセッサーに伝搬されます。 Mule 4 ではこれを 2 つの異なる操作を使用して行います。 Mule 4 の例: キューへのメッセージの投稿 ```xml #[upper(payload)] #[upper(payload)] ``` 両方の操作は同じように設定になっており、DataWeave を使用して、送信されるメッセージのコンテンツをビルドできます。ただし、​``​ 操作はコンテンツをパブリッシュし、同じメッセージを使用して続行されるのに対し、​``​ 操作は参照するキューの ​``​ から応答が生成されるのを待機します。 VM Connector を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-vm-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector について](https://docs.mulesoft.com/jp/file-connector/latest/) # VM トランスポートの移行 VM トランスポートは完全に書き換えられました。Mule 3 トランスポートモデルを操作ベースのコネクタへと進化させました。このため、多数の新しい機能が可能になります。 - ポーリングインバウンドエンドポイントのみが提供された古いトランスポートとは異なり、オンデマンドでキューからメッセージをコンシュームする機能。 - 拡張された ​[DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​。 ## [](#whats_covered_here)このトピックの内容 - [VM トランスポート設定の移行](#file_configs) - [インバウンドエンドポイントの移行](#vm_listener) - [アウトバウンドエンドポイントの移行](#vm_outbound) ## [](#file_configs)VM トランスポート設定の移行 Mule 3 では、トランスポート設定はすべて ​``​ と呼ばれる最上位レベルの要素の下に設定されます。各設定は複数のキューを処理できますが、それらはすべて一時的キューか永続的キューのいずれかでなければならないという制限がありました。一時的と永続的を組み合わせるには、個別に 2 つのトランスポート設定が必要でした。 Mule 3 の例: 永続的 VM トランスポートの定義 ```xml ``` Mule 4 では、各コネクタ設定が処理を行うキューを事前に定義します。これらのキューのそれぞれに、明確で柔軟な独自の設定を使用することができます。ただし、設定がアクセスできるのは、それぞれが定義したキューのみです。これは、誰もリスンしていないキューにメッセージをパブリッシュしないように設けられた制限です。 Mule 4 の例: VM Connector 設定の定義 ```xml ``` ## [](#vm_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用して、特定のキューのメッセージをリスンしていました。キュー内の要素ごとに、新しいメッセージがトリガーされました。 Mule 3 の例: VM インバウンドエンドポイント ```xml ... ``` この設定では、​`persistentQueue`​ と呼ばれるキューをリスンするトランザクションのインバウンドエンドポイントが定義されています。また、フローが応答を送信するものなのかどうかを判断するために、​`exchange-pattern`​ パラメーターが使用されました。​`request-response`​ に設定すると、エンドポイントはフローの最後に取得されたメッセージで応答します (この詳細は​[アウトバウンドエンドポイントの移行](#vm_outbound)​セクションで説明します)。 Mule 4 では代わりに ​``​ イベントソースが使用されます。 Mule 4 の例: VM リスナー ```xml #[lower(payload.salute)] ... ``` 主な違いは次のとおりです。 - リスナーは config を参照しており、その config で定義されたキューのみをリスンできます。 - ``​ 要素を使用して応答を制御できるようになりました。指定しない場合、フローの最後に生成されるメッセージペイロードが設定になります。 - 応答が送信されるかどうかを制御するために ​`exchange-pattern`​ を使用する必要がなくなりました。コネクタでは、​``​ または ​``​ 操作で生成されるメッセージに応じて、送信が自動的に判断されます。 ### [](#メッセージの順次リスン)メッセージの順次リスン インバウンドエンドポイントのもう 1 つのユースケースは、メッセージの順次リスンです。Mule 3 では、これは ​`numberOfConcurrentTransactedReceivers`​ パラメーターを使用してコネクタレベルで設定する必要がありました。 Mule 3 の例: メッセージの順次リスン ```xml ``` Mule 4 では、これをリスナーレベルで行うことができます。 Mule 4 の例: メッセージの順次リスン ```xml ... ``` フローの ​`maxConcurrency`​ とリスナーの ​`numberOfConsumers`​ を両方とも 1 に設定することで、メッセージを順次処理できます。 ## [](#vm_outbound)アウトバウンドエンドポイントの移行 Mule 3 トランスポートでは、​``​ コンポーネントを使用してメッセージをキューにパブリッシュします。 Mule 3 の例: キューへのメッセージの投稿 ```xml ``` `exchange-pattern`​ パラメーターが上記の例の動作で重要な役割を果たします。パターンが ​`one-way`​ の場合はメッセージが送信され、同じメッセージペイロードを使用して実行が続行されます。​`request-response`​ が使用されている場合、同じキューでリスンしている ​``​ を使用するフローからの応答を待機し、取得した応答は次のメッセージプロセッサーに伝搬されます。 Mule 4 ではこれを 2 つの異なる操作を使用して行います。 Mule 4 の例: キューへのメッセージの投稿 ```xml #[upper(payload)] #[upper(payload)] ``` 両方の操作は同じように設定になっており、DataWeave を使用して、送信されるメッセージのコンテンツをビルドできます。ただし、​``​ 操作はコンテンツをパブリッシュし、同じメッセージを使用して続行されるのに対し、​``​ 操作は参照するキューの ​``​ から応答が生成されるのを待機します。 VM Connector を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-vm-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector について](https://docs.mulesoft.com/jp/file-connector/latest/) # VM トランスポートの移行 VM トランスポートは完全に書き換えられました。Mule 3 トランスポートモデルを操作ベースのコネクタへと進化させました。このため、多数の新しい機能が可能になります。 - ポーリングインバウンドエンドポイントのみが提供された古いトランスポートとは異なり、オンデマンドでキューからメッセージをコンシュームする機能。 - 拡張された ​[DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​。 ## [](#whats_covered_here)このトピックの内容 - [VM トランスポート設定の移行](#file_configs) - [インバウンドエンドポイントの移行](#vm_listener) - [アウトバウンドエンドポイントの移行](#vm_outbound) ## [](#file_configs)VM トランスポート設定の移行 Mule 3 では、トランスポート設定はすべて ​``​ と呼ばれる最上位レベルの要素の下に設定されます。各設定は複数のキューを処理できますが、それらはすべて一時的キューか永続的キューのいずれかでなければならないという制限がありました。一時的と永続的を組み合わせるには、個別に 2 つのトランスポート設定が必要でした。 Mule 3 の例: 永続的 VM トランスポートの定義 ```xml ``` Mule 4 では、各コネクタ設定が処理を行うキューを事前に定義します。これらのキューのそれぞれに、明確で柔軟な独自の設定を使用することができます。ただし、設定がアクセスできるのは、それぞれが定義したキューのみです。これは、誰もリスンしていないキューにメッセージをパブリッシュしないように設けられた制限です。 Mule 4 の例: VM Connector 設定の定義 ```xml ``` ## [](#vm_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用して、特定のキューのメッセージをリスンしていました。キュー内の要素ごとに、新しいメッセージがトリガーされました。 Mule 3 の例: VM インバウンドエンドポイント ```xml ... ``` この設定では、​`persistentQueue`​ と呼ばれるキューをリスンするトランザクションのインバウンドエンドポイントが定義されています。また、フローが応答を送信するものなのかどうかを判断するために、​`exchange-pattern`​ パラメーターが使用されました。​`request-response`​ に設定すると、エンドポイントはフローの最後に取得されたメッセージで応答します (この詳細は​[アウトバウンドエンドポイントの移行](#vm_outbound)​セクションで説明します)。 Mule 4 では代わりに ​``​ イベントソースが使用されます。 Mule 4 の例: VM リスナー ```xml #[lower(payload.salute)] ... ``` 主な違いは次のとおりです。 - リスナーは config を参照しており、その config で定義されたキューのみをリスンできます。 - ``​ 要素を使用して応答を制御できるようになりました。指定しない場合、フローの最後に生成されるメッセージペイロードが設定になります。 - 応答が送信されるかどうかを制御するために ​`exchange-pattern`​ を使用する必要がなくなりました。コネクタでは、​``​ または ​``​ 操作で生成されるメッセージに応じて、送信が自動的に判断されます。 ### [](#メッセージの順次リスン)メッセージの順次リスン インバウンドエンドポイントのもう 1 つのユースケースは、メッセージの順次リスンです。Mule 3 では、これは ​`numberOfConcurrentTransactedReceivers`​ パラメーターを使用してコネクタレベルで設定する必要がありました。 Mule 3 の例: メッセージの順次リスン ```xml ``` Mule 4 では、これをリスナーレベルで行うことができます。 Mule 4 の例: メッセージの順次リスン ```xml ... ``` フローの ​`maxConcurrency`​ とリスナーの ​`numberOfConsumers`​ を両方とも 1 に設定することで、メッセージを順次処理できます。 ## [](#vm_outbound)アウトバウンドエンドポイントの移行 Mule 3 トランスポートでは、​``​ コンポーネントを使用してメッセージをキューにパブリッシュします。 Mule 3 の例: キューへのメッセージの投稿 ```xml ``` `exchange-pattern`​ パラメーターが上記の例の動作で重要な役割を果たします。パターンが ​`one-way`​ の場合はメッセージが送信され、同じメッセージペイロードを使用して実行が続行されます。​`request-response`​ が使用されている場合、同じキューでリスンしている ​``​ を使用するフローからの応答を待機し、取得した応答は次のメッセージプロセッサーに伝搬されます。 Mule 4 ではこれを 2 つの異なる操作を使用して行います。 Mule 4 の例: キューへのメッセージの投稿 ```xml #[upper(payload)] #[upper(payload)] ``` 両方の操作は同じように設定になっており、DataWeave を使用して、送信されるメッセージのコンテンツをビルドできます。ただし、​``​ 操作はコンテンツをパブリッシュし、同じメッセージを使用して続行されるのに対し、​``​ 操作は参照するキューの ​``​ から応答が生成されるのを待機します。 VM Connector を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-vm-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector について](https://docs.mulesoft.com/jp/file-connector/latest/) # VM トランスポートの移行 VM トランスポートは完全に書き換えられました。Mule 3 トランスポートモデルを操作ベースのコネクタへと進化させました。このため、多数の新しい機能が可能になります。 - ポーリングインバウンドエンドポイントのみが提供された古いトランスポートとは異なり、オンデマンドでキューからメッセージをコンシュームする機能。 - 拡張された ​[DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​。 ## [](#whats_covered_here)このトピックの内容 - [VM トランスポート設定の移行](#file_configs) - [インバウンドエンドポイントの移行](#vm_listener) - [アウトバウンドエンドポイントの移行](#vm_outbound) ## [](#file_configs)VM トランスポート設定の移行 Mule 3 では、トランスポート設定はすべて ​``​ と呼ばれる最上位レベルの要素の下に設定されます。各設定は複数のキューを処理できますが、それらはすべて一時的キューか永続的キューのいずれかでなければならないという制限がありました。一時的と永続的を組み合わせるには、個別に 2 つのトランスポート設定が必要でした。 Mule 3 の例: 永続的 VM トランスポートの定義 ```xml ``` Mule 4 では、各コネクタ設定が処理を行うキューを事前に定義します。これらのキューのそれぞれに、明確で柔軟な独自の設定を使用することができます。ただし、設定がアクセスできるのは、それぞれが定義したキューのみです。これは、誰もリスンしていないキューにメッセージをパブリッシュしないように設けられた制限です。 Mule 4 の例: VM Connector 設定の定義 ```xml ``` ## [](#vm_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用して、特定のキューのメッセージをリスンしていました。キュー内の要素ごとに、新しいメッセージがトリガーされました。 Mule 3 の例: VM インバウンドエンドポイント ```xml ... ``` この設定では、​`persistentQueue`​ と呼ばれるキューをリスンするトランザクションのインバウンドエンドポイントが定義されています。また、フローが応答を送信するものなのかどうかを判断するために、​`exchange-pattern`​ パラメーターが使用されました。​`request-response`​ に設定すると、エンドポイントはフローの最後に取得されたメッセージで応答します (この詳細は​[アウトバウンドエンドポイントの移行](#vm_outbound)​セクションで説明します)。 Mule 4 では代わりに ​``​ イベントソースが使用されます。 Mule 4 の例: VM リスナー ```xml #[lower(payload.salute)] ... ``` 主な違いは次のとおりです。 - リスナーは config を参照しており、その config で定義されたキューのみをリスンできます。 - ``​ 要素を使用して応答を制御できるようになりました。指定しない場合、フローの最後に生成されるメッセージペイロードが設定になります。 - 応答が送信されるかどうかを制御するために ​`exchange-pattern`​ を使用する必要がなくなりました。コネクタでは、​``​ または ​``​ 操作で生成されるメッセージに応じて、送信が自動的に判断されます。 ### [](#メッセージの順次リスン)メッセージの順次リスン インバウンドエンドポイントのもう 1 つのユースケースは、メッセージの順次リスンです。Mule 3 では、これは ​`numberOfConcurrentTransactedReceivers`​ パラメーターを使用してコネクタレベルで設定する必要がありました。 Mule 3 の例: メッセージの順次リスン ```xml ``` Mule 4 では、これをリスナーレベルで行うことができます。 Mule 4 の例: メッセージの順次リスン ```xml ... ``` フローの ​`maxConcurrency`​ とリスナーの ​`numberOfConsumers`​ を両方とも 1 に設定することで、メッセージを順次処理できます。 ## [](#vm_outbound)アウトバウンドエンドポイントの移行 Mule 3 トランスポートでは、​``​ コンポーネントを使用してメッセージをキューにパブリッシュします。 Mule 3 の例: キューへのメッセージの投稿 ```xml ``` `exchange-pattern`​ パラメーターが上記の例の動作で重要な役割を果たします。パターンが ​`one-way`​ の場合はメッセージが送信され、同じメッセージペイロードを使用して実行が続行されます。​`request-response`​ が使用されている場合、同じキューでリスンしている ​``​ を使用するフローからの応答を待機し、取得した応答は次のメッセージプロセッサーに伝搬されます。 Mule 4 ではこれを 2 つの異なる操作を使用して行います。 Mule 4 の例: キューへのメッセージの投稿 ```xml #[upper(payload)] #[upper(payload)] ``` 両方の操作は同じように設定になっており、DataWeave を使用して、送信されるメッセージのコンテンツをビルドできます。ただし、​``​ 操作はコンテンツをパブリッシュし、同じメッセージを使用して続行されるのに対し、​``​ 操作は参照するキューの ​``​ から応答が生成されるのを待機します。 VM Connector を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-vm-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector について](https://docs.mulesoft.com/jp/file-connector/latest/) # VM トランスポートの移行 VM トランスポートは完全に書き換えられました。Mule 3 トランスポートモデルを操作ベースのコネクタへと進化させました。このため、多数の新しい機能が可能になります。 - ポーリングインバウンドエンドポイントのみが提供された古いトランスポートとは異なり、オンデマンドでキューからメッセージをコンシュームする機能。 - 拡張された ​[DataSense](https://docs.mulesoft.com/studio/datasense-explorer)​。 ## [](#whats_covered_here)このトピックの内容 - [VM トランスポート設定の移行](#file_configs) - [インバウンドエンドポイントの移行](#vm_listener) - [アウトバウンドエンドポイントの移行](#vm_outbound) ## [](#file_configs)VM トランスポート設定の移行 Mule 3 では、トランスポート設定はすべて ​``​ と呼ばれる最上位レベルの要素の下に設定されます。各設定は複数のキューを処理できますが、それらはすべて一時的キューか永続的キューのいずれかでなければならないという制限がありました。一時的と永続的を組み合わせるには、個別に 2 つのトランスポート設定が必要でした。 Mule 3 の例: 永続的 VM トランスポートの定義 ```xml ``` Mule 4 では、各コネクタ設定が処理を行うキューを事前に定義します。これらのキューのそれぞれに、明確で柔軟な独自の設定を使用することができます。ただし、設定がアクセスできるのは、それぞれが定義したキューのみです。これは、誰もリスンしていないキューにメッセージをパブリッシュしないように設けられた制限です。 Mule 4 の例: VM Connector 設定の定義 ```xml ``` ## [](#vm_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用して、特定のキューのメッセージをリスンしていました。キュー内の要素ごとに、新しいメッセージがトリガーされました。 Mule 3 の例: VM インバウンドエンドポイント ```xml ... ``` この設定では、​`persistentQueue`​ と呼ばれるキューをリスンするトランザクションのインバウンドエンドポイントが定義されています。また、フローが応答を送信するものなのかどうかを判断するために、​`exchange-pattern`​ パラメーターが使用されました。​`request-response`​ に設定すると、エンドポイントはフローの最後に取得されたメッセージで応答します (この詳細は​[アウトバウンドエンドポイントの移行](#vm_outbound)​セクションで説明します)。 Mule 4 では代わりに ​``​ イベントソースが使用されます。 Mule 4 の例: VM リスナー ```xml #[lower(payload.salute)] ... ``` 主な違いは次のとおりです。 - リスナーは config を参照しており、その config で定義されたキューのみをリスンできます。 - ``​ 要素を使用して応答を制御できるようになりました。指定しない場合、フローの最後に生成されるメッセージペイロードが設定になります。 - 応答が送信されるかどうかを制御するために ​`exchange-pattern`​ を使用する必要がなくなりました。コネクタでは、​``​ または ​``​ 操作で生成されるメッセージに応じて、送信が自動的に判断されます。 ### [](#メッセージの順次リスン)メッセージの順次リスン インバウンドエンドポイントのもう 1 つのユースケースは、メッセージの順次リスンです。Mule 3 では、これは ​`numberOfConcurrentTransactedReceivers`​ パラメーターを使用してコネクタレベルで設定する必要がありました。 Mule 3 の例: メッセージの順次リスン ```xml ``` Mule 4 では、これをリスナーレベルで行うことができます。 Mule 4 の例: メッセージの順次リスン ```xml ... ``` フローの ​`maxConcurrency`​ とリスナーの ​`numberOfConsumers`​ を両方とも 1 に設定することで、メッセージを順次処理できます。 ## [](#vm_outbound)アウトバウンドエンドポイントの移行 Mule 3 トランスポートでは、​``​ コンポーネントを使用してメッセージをキューにパブリッシュします。 Mule 3 の例: キューへのメッセージの投稿 ```xml ``` `exchange-pattern`​ パラメーターが上記の例の動作で重要な役割を果たします。パターンが ​`one-way`​ の場合はメッセージが送信され、同じメッセージペイロードを使用して実行が続行されます。​`request-response`​ が使用されている場合、同じキューでリスンしている ​``​ を使用するフローからの応答を待機し、取得した応答は次のメッセージプロセッサーに伝搬されます。 Mule 4 ではこれを 2 つの異なる操作を使用して行います。 Mule 4 の例: キューへのメッセージの投稿 ```xml #[upper(payload)] #[upper(payload)] ``` 両方の操作は同じように設定になっており、DataWeave を使用して、送信されるメッセージのコンテンツをビルドできます。ただし、​``​ 操作はコンテンツをパブリッシュし、同じメッセージを使用して続行されるのに対し、​``​ 操作は参照するキューの ​``​ から応答が生成されるのを待機します。 VM Connector を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-vm-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [File Connector について](https://docs.mulesoft.com/jp/file-connector/latest/) # WSC の移行 Web サービスコンシューマーを使用するいくつかの一般的なケースを、Mule 3 での行われていた方法と新しい Mule 4 リリースではどのように行うのかについて説明します。 ## [](#web-サービスとの接続)Web サービスとの接続 Mule 4 では、接続パラメーターをその他の設定パラメーターから分離する概念が導入されました。そのため、以下の説明では、設定に新しい タグが含まれています。Web サービスコンシューマーのすべての必須パラメーターは接続を作成するために使用されているので、それらはすべて グループに移動されました。 ### [](#単純な-web-サービス設定)単純な Web サービス設定 パラメーターは同じですが、唯一の違いは、操作内にあった設定に ​`mtomEnabled`​ という新しいパラメーターが追加されたことです。 Mule 3.x では、次のように設定内にすべての要素を定義しました。 ```xml ``` パラメーターはすべて接続内に定義されるようになりました。 ```xml ``` #### [](#メッセージを送信するカスタム-http-設定の定義)メッセージを送信するカスタム http 設定の定義 Mule 3 では、カスタム設定 (TLS、さまざまな HTTP 認証種別など) を使用する HTTP プロトコル経由でメッセージを送信するために、Web サービスコンシューマーが使用できるカスタム 設定を定義することが一般的でした。もちろん、これは Mule 4 でも行えます。 `connector-ref`​ 設定パラメーターは、メッセージを送信するコネクタを設定するために使用されていました (これは HTTP と JMS のみ可能)。 ```xml ``` 新しい WSC で同じことを行うには、​``​ パラメーターを接続に追加し、必要な http 設定を指定する必要があります。 これが可能なのは HTTP リクエスター設定​**のみ**​で、正しく設定されていなければ実行時に失敗します。 ```xml ``` ## [](#web-サービスのコンシューム)Web サービスのコンシューム Mule 3 の場合、WSC ではペイロードはすでに作成済みの XML 本文であることが期待されるので、ほとんどの場合、WSC コンポーネントは Transform コンポーネントの後に使用されていました。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` そのコンポーネントを追加する必要がなくなり、DataWeave を使用して、consume 操作で operataion パラメーターとして本文 XML を直接ビルドできるようになりました。次に例を示します。 ```xml ... #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` ### [](#ヘッダーの送信)ヘッダーの送信 Mule 3 では、WSC は ​`soap.`​ で始まるすべての outboundProperties を収集することで添付ファイルを操作します。たとえば、変数 ​`soap.CrazyHeader`​ を追加した場合、実行すると、変数のコンテンツが取得され、その変数コンテンツがエンベロープの SoapHeaders 要素に挿入されます。これは最適な動作ではありません。Mule 4 ではヘッダーが単なるパラメーターであるのはそのためです (当然ですが、ヘッダーにはメタデータもあります)。 Mule 3 のサンプル XML を見てみましょう。 ```xml ... ``` 次は Mule 4 の場合です。 ```xml #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- "headers": { con#aHeader: { text: "Hello!" }, con#anotherHeader: "Hello! says another header" }] ``` ヘッダーは DataWeave スクリプトを使用した操作の内側で直接構築できます。このためのメタデータがあるので非常に簡単にできます。 ### [](#添付ファイルの追加)添付ファイルの追加 添付ファイルの追加がかなり容易になりました。Mule 3 で ​**MTOM 添付ファイル**​を操作する場合は、​`set-attachment`​ コンポーネントを使用して新しいアウトバウンド添付ファイルを作成し、エンベロープ本文は、その追加される添付ファイルへの XOP 参照を追加して構築する必要がありました。
mtomEnabled パラメーターは、操作から接続に移動されました。
```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` MTOM ではなく、​**添付ファイルを含む Soap**​ を操作する場合、Mule 開発者が、Base64 でエンコードされた添付ファイルを内側に含む本文をビルドする必要がありました (DataWeave ではこのための関数が提供されていました)。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` Mule 4 では、MTOM か SWA かに関係なく、開発者は常に同じように添付ファイルを操作します。新しい添付ファイルを作成し、それにコンテンツを割り当てるだけです (mimetype は、コンテンツに関連付けられているものを使用します)。 たとえば、次の場合は、File Connector を使用して JSON ファイルを読み取った後、ペイロードで file:read 操作によって返されたコンテンツを渡して新しい添付ファイルを作成します。 ```xml ... #[{ attach: payload } ] ... ``` Web サービスコンシューマーを使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-wsc-connector 1.1.0 mule-plugin ``` # WSC の移行 Web サービスコンシューマーを使用するいくつかの一般的なケースを、Mule 3 での行われていた方法と新しい Mule 4 リリースではどのように行うのかについて説明します。
Mule 4 の Web Service Consumer Connector では JMS トランスポートの機能はサポートされません。
## [](#web-サービスとの接続)Web サービスとの接続 Mule 4 では、接続パラメーターをその他の設定パラメーターから分離する概念が導入されました。そのため、以下の説明では、設定に新しい タグが含まれています。Web サービスコンシューマーのすべての必須パラメーターは接続を作成するために使用されているので、それらはすべて グループに移動されました。 ### [](#単純な-web-サービス設定)単純な Web サービス設定 パラメーターは同じですが、唯一の違いは、操作内にあった設定に ​`mtomEnabled`​ という新しいパラメーターが追加されたことです。 Mule 3.x では、次のように設定内にすべての要素を定義しました。 ```xml ``` パラメーターはすべて接続内に定義されるようになりました。 ```xml ``` #### [](#メッセージを送信するカスタム-http-設定の定義)メッセージを送信するカスタム http 設定の定義 Mule 3 では、カスタム設定 (TLS、さまざまな HTTP 認証種別など) を使用する HTTP プロトコル経由でメッセージを送信するために、Web サービスコンシューマーが使用できるカスタム 設定を定義することが一般的でした。もちろん、これは Mule 4 でも行えます。 `connector-ref`​ 設定パラメーターは、メッセージを送信するコネクタを設定するために使用されていました (これは HTTP と JMS のみ可能)。 ```xml ``` 新しい WSC で同じことを行うには、​``​ パラメーターを接続に追加し、必要な http 設定を指定する必要があります。 これが可能なのは HTTP リクエスター設定​**のみ**​で、正しく設定されていなければ実行時に失敗します。 ```xml ``` ## [](#web-サービスのコンシューム)Web サービスのコンシューム Mule 3 の場合、WSC ではペイロードはすでに作成済みの XML 本文であることが期待されるので、ほとんどの場合、WSC コンポーネントは Transform コンポーネントの後に使用されていました。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` そのコンポーネントを追加する必要がなくなり、DataWeave を使用して、consume 操作で operataion パラメーターとして本文 XML を直接ビルドできるようになりました。次に例を示します。 ```xml ... #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` ### [](#ヘッダーの送信)ヘッダーの送信 Mule 3 では、WSC は ​`soap.`​ で始まるすべての outboundProperties を収集することで添付ファイルを操作します。たとえば、変数 ​`soap.CrazyHeader`​ を追加した場合、実行すると、変数のコンテンツが取得され、その変数コンテンツがエンベロープの SoapHeaders 要素に挿入されます。これは最適な動作ではありません。Mule 4 ではヘッダーが単なるパラメーターであるのはそのためです (当然ですが、ヘッダーにはメタデータもあります)。 Mule 3 のサンプル XML を見てみましょう。 ```xml ... ``` 次は Mule 4 の場合です。 ```xml #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- "headers": { con#aHeader: { text: "Hello!" }, con#anotherHeader: "Hello! says another header" }] ``` ヘッダーは DataWeave スクリプトを使用した操作の内側で直接構築できます。このためのメタデータがあるので非常に簡単にできます。 ### [](#添付ファイルの追加)添付ファイルの追加 添付ファイルの追加がかなり容易になりました。Mule 3 で ​**MTOM 添付ファイル**​を操作する場合は、​`set-attachment`​ コンポーネントを使用して新しいアウトバウンド添付ファイルを作成し、エンベロープ本文は、その追加される添付ファイルへの XOP 参照を追加して構築する必要がありました。
mtomEnabled パラメーターは、操作から接続に移動されました。
```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` MTOM ではなく、​**添付ファイルを含む Soap**​ を操作する場合、Mule 開発者が、Base64 でエンコードされた添付ファイルを内側に含む本文をビルドする必要がありました (DataWeave ではこのための関数が提供されていました)。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` Mule 4 では、MTOM か SWA かに関係なく、開発者は常に同じように添付ファイルを操作します。新しい添付ファイルを作成し、それにコンテンツを割り当てるだけです (mimetype は、コンテンツに関連付けられているものを使用します)。 たとえば、次の場合は、File Connector を使用して JSON ファイルを読み取った後、ペイロードで file:read 操作によって返されたコンテンツを渡して新しい添付ファイルを作成します。 ```xml ... #[{ attach: payload } ] ... ``` Web サービスコンシューマーを使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-wsc-connector 1.1.0 mule-plugin ``` # WSC の移行 Web サービスコンシューマーを使用するいくつかの一般的なケースを、Mule 3 での行われていた方法と新しい Mule 4 リリースではどのように行うのかについて説明します。
Mule 4 の Web Service Consumer Connector では JMS トランスポートの機能はサポートされません。
## [](#web-サービスとの接続)Web サービスとの接続 Mule 4 では、接続パラメーターをその他の設定パラメーターから分離する概念が導入されました。そのため、以下の説明では、設定に新しい タグが含まれています。Web サービスコンシューマーのすべての必須パラメーターは接続を作成するために使用されているので、それらはすべて グループに移動されました。 ### [](#単純な-web-サービス設定)単純な Web サービス設定 パラメーターは同じですが、唯一の違いは、操作内にあった設定に ​`mtomEnabled`​ という新しいパラメーターが追加されたことです。 Mule 3.x では、次のように設定内にすべての要素を定義しました。 ```xml ``` パラメーターはすべて接続内に定義されるようになりました。 ```xml ``` #### [](#メッセージを送信するカスタム-http-設定の定義)メッセージを送信するカスタム http 設定の定義 Mule 3 では、カスタム設定 (TLS、さまざまな HTTP 認証種別など) を使用する HTTP プロトコル経由でメッセージを送信するために、Web サービスコンシューマーが使用できるカスタム 設定を定義することが一般的でした。もちろん、これは Mule 4 でも行えます。 `connector-ref`​ 設定パラメーターは、メッセージを送信するコネクタを設定するために使用されていました (これは HTTP と JMS のみ可能)。 ```xml ``` 新しい WSC で同じことを行うには、​``​ パラメーターを接続に追加し、必要な http 設定を指定する必要があります。 これが可能なのは HTTP リクエスター設定​**のみ**​で、正しく設定されていなければ実行時に失敗します。 ```xml ``` ## [](#web-サービスのコンシューム)Web サービスのコンシューム Mule 3 の場合、WSC ではペイロードはすでに作成済みの XML 本文であることが期待されるので、ほとんどの場合、WSC コンポーネントは Transform コンポーネントの後に使用されていました。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` そのコンポーネントを追加する必要がなくなり、DataWeave を使用して、consume 操作で operataion パラメーターとして本文 XML を直接ビルドできるようになりました。次に例を示します。 ```xml ... #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` ### [](#ヘッダーの送信)ヘッダーの送信 Mule 3 では、WSC は ​`soap.`​ で始まるすべての outboundProperties を収集することで添付ファイルを操作します。たとえば、変数 ​`soap.CrazyHeader`​ を追加した場合、実行すると、変数のコンテンツが取得され、その変数コンテンツがエンベロープの SoapHeaders 要素に挿入されます。これは最適な動作ではありません。Mule 4 ではヘッダーが単なるパラメーターであるのはそのためです (当然ですが、ヘッダーにはメタデータもあります)。 Mule 3 のサンプル XML を見てみましょう。 ```xml ... ``` 次は Mule 4 の場合です。 ```xml #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- "headers": { con#aHeader: { text: "Hello!" }, con#anotherHeader: "Hello! says another header" }] ``` ヘッダーは DataWeave スクリプトを使用した操作の内側で直接構築できます。このためのメタデータがあるので非常に簡単にできます。 ### [](#添付ファイルの追加)添付ファイルの追加 添付ファイルの追加がかなり容易になりました。Mule 3 で ​**MTOM 添付ファイル**​を操作する場合は、​`set-attachment`​ コンポーネントを使用して新しいアウトバウンド添付ファイルを作成し、エンベロープ本文は、その追加される添付ファイルへの XOP 参照を追加して構築する必要がありました。
mtomEnabled パラメーターは、操作から接続に移動されました。
```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` MTOM ではなく、​**添付ファイルを含む Soap**​ を操作する場合、Mule 開発者が、Base64 でエンコードされた添付ファイルを内側に含む本文をビルドする必要がありました (DataWeave ではこのための関数が提供されていました)。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` Mule 4 では、MTOM か SWA かに関係なく、開発者は常に同じように添付ファイルを操作します。新しい添付ファイルを作成し、それにコンテンツを割り当てるだけです (mimetype は、コンテンツに関連付けられているものを使用します)。 たとえば、次の場合は、File Connector を使用して JSON ファイルを読み取った後、ペイロードで file:read 操作によって返されたコンテンツを渡して新しい添付ファイルを作成します。 ```xml ... #[{ attach: payload } ] ... ``` Web サービスコンシューマーを使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-wsc-connector 1.1.0 mule-plugin ``` # WSC の移行 Web サービスコンシューマーを使用するいくつかの一般的なケースを、Mule 3 での行われていた方法と新しい Mule 4 リリースではどのように行うのかについて説明します。
Mule 4 の Web Service Consumer Connector では JMS トランスポートの機能はサポートされません。
## [](#web-サービスとの接続)Web サービスとの接続 Mule 4 では、接続パラメーターをその他の設定パラメーターから分離する概念が導入されました。そのため、以下の説明では、設定に新しい タグが含まれています。Web サービスコンシューマーのすべての必須パラメーターは接続を作成するために使用されているので、それらはすべて グループに移動されました。 ### [](#単純な-web-サービス設定)単純な Web サービス設定 パラメーターは同じですが、唯一の違いは、操作内にあった設定に ​`mtomEnabled`​ という新しいパラメーターが追加されたことです。 Mule 3.x では、次のように設定内にすべての要素を定義しました。 ```xml ``` パラメーターはすべて接続内に定義されるようになりました。 ```xml ``` #### [](#メッセージを送信するカスタム-http-設定の定義)メッセージを送信するカスタム http 設定の定義 Mule 3 では、カスタム設定 (TLS、さまざまな HTTP 認証種別など) を使用する HTTP プロトコル経由でメッセージを送信するために、Web サービスコンシューマーが使用できるカスタム 設定を定義することが一般的でした。もちろん、これは Mule 4 でも行えます。 `connector-ref`​ 設定パラメーターは、メッセージを送信するコネクタを設定するために使用されていました (これは HTTP と JMS のみ可能)。 ```xml ``` 新しい WSC で同じことを行うには、​``​ パラメーターを接続に追加し、必要な http 設定を指定する必要があります。 これが可能なのは HTTP リクエスター設定​**のみ**​で、正しく設定されていなければ実行時に失敗します。 ```xml ``` ## [](#web-サービスのコンシューム)Web サービスのコンシューム Mule 3 の場合、WSC ではペイロードはすでに作成済みの XML 本文であることが期待されるので、ほとんどの場合、WSC コンポーネントは Transform コンポーネントの後に使用されていました。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` そのコンポーネントを追加する必要がなくなり、DataWeave を使用して、consume 操作で operataion パラメーターとして本文 XML を直接ビルドできるようになりました。次に例を示します。 ```xml ... #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` ### [](#ヘッダーの送信)ヘッダーの送信 Mule 3 では、WSC は ​`soap.`​ で始まるすべての outboundProperties を収集することで添付ファイルを操作します。たとえば、変数 ​`soap.CrazyHeader`​ を追加した場合、実行すると、変数のコンテンツが取得され、その変数コンテンツがエンベロープの SoapHeaders 要素に挿入されます。これは最適な動作ではありません。Mule 4 ではヘッダーが単なるパラメーターであるのはそのためです (当然ですが、ヘッダーにはメタデータもあります)。 Mule 3 のサンプル XML を見てみましょう。 ```xml ... ``` 次は Mule 4 の場合です。 ```xml #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- "headers": { con#aHeader: { text: "Hello!" }, con#anotherHeader: "Hello! says another header" }] ``` ヘッダーは DataWeave スクリプトを使用した操作の内側で直接構築できます。このためのメタデータがあるので非常に簡単にできます。 ### [](#添付ファイルの追加)添付ファイルの追加 添付ファイルの追加がかなり容易になりました。Mule 3 で ​**MTOM 添付ファイル**​を操作する場合は、​`set-attachment`​ コンポーネントを使用して新しいアウトバウンド添付ファイルを作成し、エンベロープ本文は、その追加される添付ファイルへの XOP 参照を追加して構築する必要がありました。
mtomEnabled パラメーターは、操作から接続に移動されました。
```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` MTOM ではなく、​**添付ファイルを含む Soap**​ を操作する場合、Mule 開発者が、Base64 でエンコードされた添付ファイルを内側に含む本文をビルドする必要がありました (DataWeave ではこのための関数が提供されていました)。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` Mule 4 では、MTOM か SWA かに関係なく、開発者は常に同じように添付ファイルを操作します。新しい添付ファイルを作成し、それにコンテンツを割り当てるだけです (mimetype は、コンテンツに関連付けられているものを使用します)。 たとえば、次の場合は、File Connector を使用して JSON ファイルを読み取った後、ペイロードで file:read 操作によって返されたコンテンツを渡して新しい添付ファイルを作成します。 ```xml ... #[{ attach: payload } ] ... ``` Web サービスコンシューマーを使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-wsc-connector 1.1.0 mule-plugin ``` # WSC の移行 Web サービスコンシューマーを使用するいくつかの一般的なケースを、Mule 3 での行われていた方法と新しい Mule 4 リリースではどのように行うのかについて説明します。
Mule 4 の Web Service Consumer Connector では JMS トランスポートの機能はサポートされません。
## [](#web-サービスとの接続)Web サービスとの接続 Mule 4 では、接続パラメーターをその他の設定パラメーターから分離する概念が導入されました。そのため、以下の説明では、設定に新しい タグが含まれています。Web サービスコンシューマーのすべての必須パラメーターは接続を作成するために使用されているので、それらはすべて グループに移動されました。 ### [](#単純な-web-サービス設定)単純な Web サービス設定 パラメーターは同じですが、唯一の違いは、操作内にあった設定に ​`mtomEnabled`​ という新しいパラメーターが追加されたことです。 Mule 3.x では、次のように設定内にすべての要素を定義しました。 ```xml ``` パラメーターはすべて接続内に定義されるようになりました。 ```xml ``` #### [](#メッセージを送信するカスタム-http-設定の定義)メッセージを送信するカスタム http 設定の定義 Mule 3 では、カスタム設定 (TLS、さまざまな HTTP 認証種別など) を使用する HTTP プロトコル経由でメッセージを送信するために、Web サービスコンシューマーが使用できるカスタム 設定を定義することが一般的でした。もちろん、これは Mule 4 でも行えます。 `connector-ref`​ 設定パラメーターは、メッセージを送信するコネクタを設定するために使用されていました (これは HTTP と JMS のみ可能)。 ```xml ``` 新しい WSC で同じことを行うには、​``​ パラメーターを接続に追加し、必要な http 設定を指定する必要があります。 これが可能なのは HTTP リクエスター設定​**のみ**​で、正しく設定されていなければ実行時に失敗します。 ```xml ``` ## [](#web-サービスのコンシューム)Web サービスのコンシューム Mule 3 の場合、WSC ではペイロードはすでに作成済みの XML 本文であることが期待されるので、ほとんどの場合、WSC コンポーネントは Transform コンポーネントの後に使用されていました。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` そのコンポーネントを追加する必要がなくなり、DataWeave を使用して、consume 操作で operataion パラメーターとして本文 XML を直接ビルドできるようになりました。次に例を示します。 ```xml ... #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` ### [](#ヘッダーの送信)ヘッダーの送信 Mule 3 では、WSC は ​`soap.`​ で始まるすべての outboundProperties を収集することで添付ファイルを操作します。たとえば、変数 ​`soap.CrazyHeader`​ を追加した場合、実行すると、変数のコンテンツが取得され、その変数コンテンツがエンベロープの SoapHeaders 要素に挿入されます。これは最適な動作ではありません。Mule 4 ではヘッダーが単なるパラメーターであるのはそのためです (当然ですが、ヘッダーにはメタデータもあります)。 Mule 3 のサンプル XML を見てみましょう。 ```xml ... ``` 次は Mule 4 の場合です。 ```xml #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- "headers": { con#aHeader: { text: "Hello!" }, con#anotherHeader: "Hello! says another header" }] ``` ヘッダーは DataWeave スクリプトを使用した操作の内側で直接構築できます。このためのメタデータがあるので非常に簡単にできます。 ### [](#添付ファイルの追加)添付ファイルの追加 添付ファイルの追加がかなり容易になりました。Mule 3 で ​**MTOM 添付ファイル**​を操作する場合は、​`set-attachment`​ コンポーネントを使用して新しいアウトバウンド添付ファイルを作成し、エンベロープ本文は、その追加される添付ファイルへの XOP 参照を追加して構築する必要がありました。
mtomEnabled パラメーターは、操作から接続に移動されました。
```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` MTOM ではなく、​**添付ファイルを含む Soap**​ を操作する場合、Mule 開発者が、Base64 でエンコードされた添付ファイルを内側に含む本文をビルドする必要がありました (DataWeave ではこのための関数が提供されていました)。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` Mule 4 では、MTOM か SWA かに関係なく、開発者は常に同じように添付ファイルを操作します。新しい添付ファイルを作成し、それにコンテンツを割り当てるだけです (mimetype は、コンテンツに関連付けられているものを使用します)。 たとえば、次の場合は、File Connector を使用して JSON ファイルを読み取った後、ペイロードで file:read 操作によって返されたコンテンツを渡して新しい添付ファイルを作成します。 ```xml ... #[{ attach: payload } ] ... ``` Web サービスコンシューマーを使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-wsc-connector 1.1.0 mule-plugin ``` # WSC の移行 Web サービスコンシューマーを使用するいくつかの一般的なケースを、Mule 3 での行われていた方法と新しい Mule 4 リリースではどのように行うのかについて説明します。
Mule 4 の Web Service Consumer Connector では JMS トランスポートの機能はサポートされません。
## [](#web-サービスとの接続)Web サービスとの接続 Mule 4 では、接続パラメーターをその他の設定パラメーターから分離する概念が導入されました。そのため、以下の説明では、設定に新しい タグが含まれています。Web サービスコンシューマーのすべての必須パラメーターは接続を作成するために使用されているので、それらはすべて グループに移動されました。 ### [](#単純な-web-サービス設定)単純な Web サービス設定 パラメーターは同じですが、唯一の違いは、操作内にあった設定に ​`mtomEnabled`​ という新しいパラメーターが追加されたことです。 Mule 3.x では、次のように設定内にすべての要素を定義しました。 ```xml ``` パラメーターはすべて接続内に定義されるようになりました。 ```xml ``` #### [](#メッセージを送信するカスタム-http-設定の定義)メッセージを送信するカスタム http 設定の定義 Mule 3 では、カスタム設定 (TLS、さまざまな HTTP 認証種別など) を使用する HTTP プロトコル経由でメッセージを送信するために、Web サービスコンシューマーが使用できるカスタム 設定を定義することが一般的でした。もちろん、これは Mule 4 でも行えます。 `connector-ref`​ 設定パラメーターは、メッセージを送信するコネクタを設定するために使用されていました (これは HTTP と JMS のみ可能)。 ```xml ``` 新しい WSC で同じことを行うには、​``​ パラメーターを接続に追加し、必要な http 設定を指定する必要があります。 これが可能なのは HTTP リクエスター設定​**のみ**​で、正しく設定されていなければ実行時に失敗します。 ```xml ``` ## [](#web-サービスのコンシューム)Web サービスのコンシューム Mule 3 の場合、WSC ではペイロードはすでに作成済みの XML 本文であることが期待されるので、ほとんどの場合、WSC コンポーネントは Transform コンポーネントの後に使用されていました。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` そのコンポーネントを追加する必要がなくなり、DataWeave を使用して、consume 操作で operataion パラメーターとして本文 XML を直接ビルドできるようになりました。次に例を示します。 ```xml ... #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` ### [](#ヘッダーの送信)ヘッダーの送信 Mule 3 では、WSC は ​`soap.`​ で始まるすべての outboundProperties を収集することで添付ファイルを操作します。たとえば、変数 ​`soap.CrazyHeader`​ を追加した場合、実行すると、変数のコンテンツが取得され、その変数コンテンツがエンベロープの SoapHeaders 要素に挿入されます。これは最適な動作ではありません。Mule 4 ではヘッダーが単なるパラメーターであるのはそのためです (当然ですが、ヘッダーにはメタデータもあります)。 Mule 3 のサンプル XML を見てみましょう。 ```xml ... ``` 次は Mule 4 の場合です。 ```xml #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- "headers": { con#aHeader: { text: "Hello!" }, con#anotherHeader: "Hello! says another header" }] ``` ヘッダーは DataWeave スクリプトを使用した操作の内側で直接構築できます。このためのメタデータがあるので非常に簡単にできます。 ### [](#添付ファイルの追加)添付ファイルの追加 添付ファイルの追加がかなり容易になりました。Mule 3 で ​**MTOM 添付ファイル**​を操作する場合は、​`set-attachment`​ コンポーネントを使用して新しいアウトバウンド添付ファイルを作成し、エンベロープ本文は、その追加される添付ファイルへの XOP 参照を追加して構築する必要がありました。
mtomEnabled パラメーターは、操作から接続に移動されました。
```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` MTOM ではなく、​**添付ファイルを含む Soap**​ を操作する場合、Mule 開発者が、Base64 でエンコードされた添付ファイルを内側に含む本文をビルドする必要がありました (DataWeave ではこのための関数が提供されていました)。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` Mule 4 では、MTOM か SWA かに関係なく、開発者は常に同じように添付ファイルを操作します。新しい添付ファイルを作成し、それにコンテンツを割り当てるだけです (mimetype は、コンテンツに関連付けられているものを使用します)。 たとえば、次の場合は、File Connector を使用して JSON ファイルを読み取った後、ペイロードで file:read 操作によって返されたコンテンツを渡して新しい添付ファイルを作成します。 ```xml ... #[{ attach: payload } ] ... ``` Web サービスコンシューマーを使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-wsc-connector 1.1.0 mule-plugin ``` # WSC の移行 Web サービスコンシューマーを使用するいくつかの一般的なケースを、Mule 3 での行われていた方法と新しい Mule 4 リリースではどのように行うのかについて説明します。
Mule 4 の Web Service Consumer Connector では JMS トランスポートの機能はサポートされません。
## [](#web-サービスとの接続)Web サービスとの接続 Mule 4 では、接続パラメーターをその他の設定パラメーターから分離する概念が導入されました。そのため、以下の説明では、設定に新しい タグが含まれています。Web サービスコンシューマーのすべての必須パラメーターは接続を作成するために使用されているので、それらはすべて グループに移動されました。 ### [](#単純な-web-サービス設定)単純な Web サービス設定 パラメーターは同じですが、唯一の違いは、操作内にあった設定に ​`mtomEnabled`​ という新しいパラメーターが追加されたことです。 Mule 3.x では、次のように設定内にすべての要素を定義しました。 ```xml ``` パラメーターはすべて接続内に定義されるようになりました。 ```xml ``` #### [](#メッセージを送信するカスタム-http-設定の定義)メッセージを送信するカスタム http 設定の定義 Mule 3 では、カスタム設定 (TLS、さまざまな HTTP 認証種別など) を使用する HTTP プロトコル経由でメッセージを送信するために、Web サービスコンシューマーが使用できるカスタム 設定を定義することが一般的でした。もちろん、これは Mule 4 でも行えます。 `connector-ref`​ 設定パラメーターは、メッセージを送信するコネクタを設定するために使用されていました (これは HTTP と JMS のみ可能)。 ```xml ``` 新しい WSC で同じことを行うには、​``​ パラメーターを接続に追加し、必要な http 設定を指定する必要があります。 これが可能なのは HTTP リクエスター設定​**のみ**​で、正しく設定されていなければ実行時に失敗します。 ```xml ``` ## [](#web-サービスのコンシューム)Web サービスのコンシューム Mule 3 の場合、WSC ではペイロードはすでに作成済みの XML 本文であることが期待されるので、ほとんどの場合、WSC コンポーネントは Transform コンポーネントの後に使用されていました。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` そのコンポーネントを追加する必要がなくなり、DataWeave を使用して、consume 操作で operataion パラメーターとして本文 XML を直接ビルドできるようになりました。次に例を示します。 ```xml ... #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- con#echo: { text: "Hello!" } ] ... ``` ### [](#ヘッダーの送信)ヘッダーの送信 Mule 3 では、WSC は ​`soap.`​ で始まるすべての outboundProperties を収集することで添付ファイルを操作します。たとえば、変数 ​`soap.CrazyHeader`​ を追加した場合、実行すると、変数のコンテンツが取得され、その変数コンテンツがエンベロープの SoapHeaders 要素に挿入されます。これは最適な動作ではありません。Mule 4 ではヘッダーが単なるパラメーターであるのはそのためです (当然ですが、ヘッダーにはメタデータもあります)。 Mule 3 のサンプル XML を見てみましょう。 ```xml ... ``` 次は Mule 4 の場合です。 ```xml #[ %dw 2.0 output application/xml ns con http://service.soap.service.mule.org/ --- "headers": { con#aHeader: { text: "Hello!" }, con#anotherHeader: "Hello! says another header" }] ``` ヘッダーは DataWeave スクリプトを使用した操作の内側で直接構築できます。このためのメタデータがあるので非常に簡単にできます。 ### [](#添付ファイルの追加)添付ファイルの追加 添付ファイルの追加がかなり容易になりました。Mule 3 で ​**MTOM 添付ファイル**​を操作する場合は、​`set-attachment`​ コンポーネントを使用して新しいアウトバウンド添付ファイルを作成し、エンベロープ本文は、その追加される添付ファイルへの XOP 参照を追加して構築する必要がありました。
mtomEnabled パラメーターは、操作から接続に移動されました。
```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` MTOM ではなく、​**添付ファイルを含む Soap**​ を操作する場合、Mule 開発者が、Base64 でエンコードされた添付ファイルを内側に含む本文をビルドする必要がありました (DataWeave ではこのための関数が提供されていました)。 ```xml ... #[ %dw 1.0 output application/xml ns con http://service.soap.service.mule.org/ ns xop http://www.w3.org/2004/08/xop/include --- con#echo: { attachment: { xop: "cid:attach" } } ] ... ``` Mule 4 では、MTOM か SWA かに関係なく、開発者は常に同じように添付ファイルを操作します。新しい添付ファイルを作成し、それにコンテンツを割り当てるだけです (mimetype は、コンテンツに関連付けられているものを使用します)。 たとえば、次の場合は、File Connector を使用して JSON ファイルを読み取った後、ペイロードで file:read 操作によって返されたコンテンツを渡して新しい添付ファイルを作成します。 ```xml ... #[{ attach: payload } ] ... ``` Web サービスコンシューマーを使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.connectors mule-wsc-connector 1.1.0 mule-plugin ``` # XA トランザクション 拡張アーキテクチャトランザクション (XA トランザクション) を使用すると、VM、JMS、データベースといった複数のトランザクションリソースから一連の操作を取り出して、単一の信頼できるグローバルトランザクションとしてグループ化できます。 XA (eXtended Architecture: 拡張アーキテクチャ) 標準は、グローバルトランザクションマネージャーとローカルトランザクションリソースマネージャーとのインターフェースを定義する X/Open グループの標準です。XA プロトコルが定義する 2 フェーズコミットプロトコルを使用すると、種類の異なる複数のサーバーにまたがる一連のアトミック操作を高い信頼性で調整して順序付けることができます。各ローカル XA リソースマネージャーは、XA リソースマネージャーが管理するリソース内での一連の操作の完了を保証するのに役立つ ACID (Atomicity: 不可分性、Consistency: 一貫性、Isolation: 独立性、Durability: 永続性) プロパティをサポートします。ローカル XA リソースマネージャーをよく使うトランザクションシステムの例としては、データベース、アプリケーションサーバー、メッセージングキュー、トランザクションキャッシュなどがあります。 グローバルトランザクションマネージャーは、グローバルトランザクションに関与するすべてのローカル XA トランザクションマネージャー間で、グローバルトランザクションのトランザクションセマンティクスを調整する責任を持ちます。そのため、各ローカル XA リソースマネージャーとの間で、2 フェーズコミットの準備フェーズとコミットフェーズがそれぞれグローバルに (通常はネットワークを介して) 調整されます。 XA グローバルトランザクションのメリットは、1 つのグローバルトランザクションマネージャーが、複数の異なるトランザクションリソースとの間で、共通した標準的な方法でコミュニケーションと調整を行えるという点です。グローバルトランザクションでいずれかのローカルリソースマネージャーがエラーを報告すると、グローバルトランザクションマネージャーは、他のそれぞれのローカルリソースマネージャーですでに準備ができている操作のロールバックを調整します。 たとえば、グローバルトランザクションに、1 つまたは複数のデータベースに対する複数の操作と、JMS サーバーに送信される 1 つまたは複数のトピックに関連したメッセージが含まれるとします。トランザクションで何らかのエラーが発生すると、グローバルトランザクションマネージャーは、すべてのリソースがグローバルトランザクションの開始前の状態にリセットされることを保証します。このため、開発者は複雑なロールバックロジックや復元ロジックをアプリケーションの外部で定義しなくても済みます。 XA グローバルトランザクションのデメリットは、特に低速または信頼性の低いネットワーク接続経由でリソースが分散している場合には、トランザクションのレイテンシーが大幅に増大するという点です。また、グローバルに分散されているトランザクションの途中のシステムで物理的な障害が発生した場合には、復元が困難になることがあります。 ## [](#パフォーマンスに関する考慮事項)パフォーマンスに関する考慮事項 グローバル XA トランザクションは、高い信頼性で複数の XA リソースを調整できますが、多くの場合はレイテンシーが増大する上、外部トランザクションマネージャーなどの追加リソースが必要になります。また、グローバルトランザクションの信頼性は、グローバルトランザクションマネージャー自身の信頼性と同じです。さらに信頼性を高めるには、グローバルトランザクション中にトランザクションマネージャーがエラーとなったり、いずれかのローカル XA リソースマネージャーとの接続が失われたりした場合に備えて、グローバルトランザクションが準備フェーズ、そしてコミットフェーズへと進むに従って各 XA リソースの状態を格納しておくためのトランザクションマネージャーが必要です。 ## [](#xa-トランザクションを使用するためのリソースの設定)XA トランザクションを使用するためのリソースの設定 XA トランザクションをサポートするメッセージソースの設定については、コネクタのドキュメントを参照してください。 - [JMS](https://docs.mulesoft.com/jms-connector/latest/jms-connector-reference#parameters-7) - [IBMMQ](https://docs.mulesoft.com/ibm-mq-connector/latest/ibm-mq-transactions#xa-transactions) - [VM](https://docs.mulesoft.com/jp/vm-connector/latest/vm-reference#parameters-6) - [データベース](https://docs.mulesoft.com/db-connector/latest/database-connector-xa-transactions) ## [](#xa-トランザクションを使用するための-try-スコープの設定)XA トランザクションを使用するための Try スコープの設定 XA トランザクションを使用するように Try スコープを設定するための手順は、次のとおりです。 1. Mule パレットから Try スコープを追加します。 2. \[Try\] 設定パネルで ​**\[General (一般)\]**​ タブに移動します。 3. Try スコープの ​`Transactional Action`​ を ​`ALWAYS_BEGIN`​、​`Transaction Type`​ を ​`XA`​ に設定します。 Try スコープがどのようにトランザクションを処理するかについての詳細は、​[「Try スコープの概念」](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept)​を参照してください。 ## [](#異なるリソースでの-xa-トランザクションの使用)異なるリソースでの XA トランザクションの使用 トランザクションをどのように (トランザクションメッセージソースから、または Try スコープから) 開始するかには関係なく、トランザクションをサポートするコネクタ操作は、トランザクションアクションを ​`ALWAYS_JOIN`​ または ​`JOIN_IF_POSSIBLE`​ に設定することで、トランザクションを結合することができます。 XA トランザクションは、異なるリソースでも動作するため、異なるリソースからの操作でもトランザクションを結合できます。例: ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗すると、トランザクションがロールバックされてからエラーハンドラー (​`on-error-propagate`​) が実行されます。そのため、​`vm:publish`​ 経由で送信されるメッセージは送信されたかどうかが確定されず、​`jms:consume`​ のメッセージは実際にはコンシュームされず、次回に再びコンシュームできるように使用できます。 次の例では、エラーハンドラーが ​`on-error-continue`​ に変更されています。 ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗しても、トランザクションはロールバックされません。その代わりに、トランザクションは (XA トランザクション内で実行される) ​`jms:publish`​ の実行後にコミットされます。そのため、​`vm:publish`​ を使用して送信されるメッセージはパブリッシュされ、​`jms:consume`​ からのメッセージはコンシュームされ、​`jms:publish`​ を使用して送信されるメッセージもパブリッシュされます。 `on-error-continue`​ 内の ​`jms:publish`​ には、別のコネクタ設定もあります。これは必須ではありませんが可能です。ただし、単一の接続元 (ローカル) トランザクションでは、トランザクションを結合するすべての操作が同じ設定を使用しなければ設計通りには機能しないため、この設定は有効ではありません。 ## [](#ネストされたトランザクション)ネストされたトランザクション XA トランザクションは、ネストされたトランザクションをサポートします。Try スコープを使用して、すでに実行中のトランザクションの中に新しいトランザクションを作成することができます。新しいトランザクション内で実行される操作は、新しいトランザクションに属します。ネストされたトランザクションがロールバックされても、その親トランザクションもロールバックされるとは限りません。ネストされたトランザクションが (コミットまたはロールバックで) 完了すると、親トランザクションは実行を続行します。 例: ```xml ${insertQuery} ``` 上の例では、最初の ​`try`​ スコープでトランザクションを作成しています。そして、2 番目の ​`try`​ スコープで 2 番目のトランザクションを作成しています。​`vm:publish`​ 操作は最初のトランザクション内で実行され、​`jms:consume`​ と ​`db:insert`​ は 2 番目のトランザクション内で実行されます。エラーが発生すると、2 番目のトランザクションが ​`jms:consume`​ および ​`db:insert`​ 操作と共にロールバックされます。一方で、最初の ​`try`​ が ​`on-error-continue`​ でエラーを処理するため、最初のトランザクションは ​`vm:publish`​ 操作と共にコミットされます。 次の例を考えてみましょう。 ```xml ${insertQuery} ``` この例では、2 番目の ​`try`​ スコープはトランザクションを作成せず、以降の操作が継続できるようにエラーを処理するだけです。トランザクションを作成するのは 3 番目の ​`try`​ スコープです。​`vm:publish`​ と ​`db:insert`​ はどちらも最初のトランザクションで実行され、​`jms:consume`​ 操作は 2 番目のトランザクションで実行されます。エラーが発生すると、2 番目の操作がロールバックされます。エラーは、伝播されて 2 番目の ​`try`​ スコープの ​`on-error-continue`​ によって処理されます。その後、最初の ​`try`​ スコープが実行 (​`db:insert`​ 操作) を続行し、最初のトランザクションがコミットされます。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept) - [Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/using-bitronix-to-manage-transactions) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management) # XA トランザクション 拡張アーキテクチャトランザクション (XA トランザクション) を使用すると、VM、JMS、データベースといった複数のトランザクションリソースから一連の操作を取り出して、単一の信頼できるグローバルトランザクションとしてグループ化できます。 XA (eXtended Architecture: 拡張アーキテクチャ) 標準は、グローバルトランザクションマネージャーとローカルトランザクションリソースマネージャーとのインターフェースを定義する X/Open グループの標準です。XA プロトコルが定義する 2 フェーズコミットプロトコルを使用すると、種類の異なる複数のサーバーにまたがる一連のアトミック操作を高い信頼性で調整して順序付けることができます。各ローカル XA リソースマネージャーは、XA リソースマネージャーが管理するリソース内での一連の操作の完了を保証するのに役立つ ACID (Atomicity: 不可分性、Consistency: 一貫性、Isolation: 独立性、Durability: 永続性) プロパティをサポートします。ローカル XA リソースマネージャーをよく使うトランザクションシステムの例としては、データベース、アプリケーションサーバー、メッセージングキュー、トランザクションキャッシュなどがあります。 グローバルトランザクションマネージャーは、グローバルトランザクションに関与するすべてのローカル XA トランザクションマネージャー間で、グローバルトランザクションのトランザクションセマンティクスを調整する責任を持ちます。そのため、各ローカル XA リソースマネージャーとの間で、2 フェーズコミットの準備フェーズとコミットフェーズがそれぞれグローバルに (通常はネットワークを介して) 調整されます。 XA グローバルトランザクションのメリットは、1 つのグローバルトランザクションマネージャーが、複数の異なるトランザクションリソースとの間で、共通した標準的な方法でコミュニケーションと調整を行えるという点です。グローバルトランザクションでいずれかのローカルリソースマネージャーがエラーを報告すると、グローバルトランザクションマネージャーは、他のそれぞれのローカルリソースマネージャーですでに準備ができている操作のロールバックを調整します。 たとえば、グローバルトランザクションに、1 つまたは複数のデータベースに対する複数の操作と、JMS サーバーに送信される 1 つまたは複数のトピックに関連したメッセージが含まれるとします。トランザクションで何らかのエラーが発生すると、グローバルトランザクションマネージャーは、すべてのリソースがグローバルトランザクションの開始前の状態にリセットされることを保証します。このため、開発者は複雑なロールバックロジックや復元ロジックをアプリケーションの外部で定義しなくても済みます。 XA グローバルトランザクションのデメリットは、特に低速または信頼性の低いネットワーク接続経由でリソースが分散している場合には、トランザクションのレイテンシーが大幅に増大するという点です。また、グローバルに分散されているトランザクションの途中のシステムで物理的な障害が発生した場合には、復元が困難になることがあります。 ## [](#パフォーマンスに関する考慮事項)パフォーマンスに関する考慮事項 グローバル XA トランザクションは、高い信頼性で複数の XA リソースを調整できますが、多くの場合はレイテンシーが増大する上、外部トランザクションマネージャーなどの追加リソースが必要になります。また、グローバルトランザクションの信頼性は、グローバルトランザクションマネージャー自身の信頼性と同じです。さらに信頼性を高めるには、グローバルトランザクション中にトランザクションマネージャーがエラーとなったり、いずれかのローカル XA リソースマネージャーとの接続が失われたりした場合に備えて、グローバルトランザクションが準備フェーズ、そしてコミットフェーズへと進むに従って各 XA リソースの状態を格納しておくためのトランザクションマネージャーが必要です。 ## [](#xa-トランザクションを使用するためのリソースの設定)XA トランザクションを使用するためのリソースの設定 XA トランザクションをサポートするイベントソースの設定については、コネクタのドキュメントを参照してください。 - [JMS](https://docs.mulesoft.com/jms-connector/latest/jms-connector-reference#parameters-7) - [IBMMQ](https://docs.mulesoft.com/ibm-mq-connector/latest/ibm-mq-transactions#xa-transactions) - [VM](https://docs.mulesoft.com/jp/vm-connector/latest/vm-reference#parameters-6) - [データベース](https://docs.mulesoft.com/db-connector/latest/database-connector-xa-transactions) ## [](#xa-トランザクションを使用するための-try-スコープの設定)XA トランザクションを使用するための Try スコープの設定 XA トランザクションを使用するように Try スコープを設定するための手順は、次のとおりです。 1. Mule パレットから Try スコープを追加します。 2. \[Try\] 設定パネルで ​**\[General (一般)\]**​ タブに移動します。 3. Try スコープの ​`Transactional Action`​ を ​`ALWAYS_BEGIN`​、​`Transaction Type`​ を ​`XA`​ に設定します。 Try スコープがどのようにトランザクションを処理するかについての詳細は、​[「Try スコープの概念」](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept)​を参照してください。 ## [](#異なるリソースでの-xa-トランザクションの使用)異なるリソースでの XA トランザクションの使用 トランザクションをどのように (トランザクションイベントソースから、または Try スコープから) 開始するかには関係なく、トランザクションをサポートするコネクタ操作は、トランザクションアクションを ​`ALWAYS_JOIN`​ または ​`JOIN_IF_POSSIBLE`​ に設定することで、トランザクションを結合することができます。 XA トランザクションは、異なるリソースでも動作するため、異なるリソースからの操作でもトランザクションを結合できます。例: ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗すると、トランザクションがロールバックされてからエラーハンドラー (​`on-error-propagate`​) が実行されます。そのため、​`vm:publish`​ 経由で送信されるメッセージは送信されたかどうかが確定されず、​`jms:consume`​ のメッセージは実際にはコンシュームされず、次回に再びコンシュームできるように使用できます。 次の例では、エラーハンドラーが ​`on-error-continue`​ に変更されています。 ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗しても、トランザクションはロールバックされません。その代わりに、トランザクションは (XA トランザクション内で実行される) ​`jms:publish`​ の実行後にコミットされます。そのため、​`vm:publish`​ を使用して送信されるメッセージはパブリッシュされ、​`jms:consume`​ からのメッセージはコンシュームされ、​`jms:publish`​ を使用して送信されるメッセージもパブリッシュされます。 `on-error-continue`​ 内の ​`jms:publish`​ には、別のコネクタ設定もあります。これは必須ではありませんが可能です。ただし、単一の接続元 (ローカル) トランザクションでは、トランザクションを結合するすべての操作が同じ設定を使用しなければ設計通りには機能しないため、この設定は有効ではありません。 ## [](#ネストされたトランザクション)ネストされたトランザクション XA トランザクションは、ネストされたトランザクションをサポートします。Try スコープを使用して、すでに実行中のトランザクションの中に新しいトランザクションを作成することができます。新しいトランザクション内で実行される操作は、新しいトランザクションに属します。ネストされたトランザクションがロールバックされても、その親トランザクションもロールバックされるとは限りません。ネストされたトランザクションが (コミットまたはロールバックで) 完了すると、親トランザクションは実行を続行します。 例: ```xml ${insertQuery} ``` 上の例では、最初の ​`try`​ スコープでトランザクションを作成しています。そして、2 番目の ​`try`​ スコープで 2 番目のトランザクションを作成しています。​`vm:publish`​ 操作は最初のトランザクション内で実行され、​`jms:consume`​ と ​`db:insert`​ は 2 番目のトランザクション内で実行されます。エラーが発生すると、2 番目のトランザクションが ​`jms:consume`​ および ​`db:insert`​ 操作と共にロールバックされます。一方で、最初の ​`try`​ が ​`on-error-continue`​ でエラーを処理するため、最初のトランザクションは ​`vm:publish`​ 操作と共にコミットされます。 次の例を考えてみましょう。 ```xml ${insertQuery} ``` この場合、2 番目の ​`try`​ スコープはトランザクションを作成しません。このスコープは、以降の操作が継続できるようにエラーを処理するだけです。トランザクションを作成するのは 3 番目の ​`try`​ スコープです。​`vm:publish`​ と ​`db:insert`​ はどちらも最初のトランザクションで実行され、​`jms:consume`​ 操作は 2 番目のトランザクションで実行されます。エラーが発生すると、2 番目の操作がロールバックされます。エラーは、伝播されて 2 番目の ​`try`​ スコープの ​`on-error-continue`​ によって処理されます。その後、最初の ​`try`​ スコープが実行 (​`db:insert`​ 操作) を続行し、最初のトランザクションがコミットされます。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept) - [Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/using-bitronix-to-manage-transactions) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management) # XA トランザクション 拡張アーキテクチャトランザクション (XA トランザクション) を使用すると、VM、JMS、データベースといった複数のトランザクションリソースから一連の操作を取り出して、単一の信頼できるグローバルトランザクションとしてグループ化できます。 XA (eXtended Architecture: 拡張アーキテクチャ) 標準は、グローバルトランザクションマネージャーとローカルトランザクションリソースマネージャーとのインターフェースを定義する X/Open グループの標準です。XA プロトコルが定義する 2 フェーズコミットプロトコルを使用すると、種類の異なる複数のサーバーにまたがる一連のアトミック操作を高い信頼性で調整して順序付けることができます。各ローカル XA リソースマネージャーは、XA リソースマネージャーが管理するリソース内での一連の操作の完了を保証するのに役立つ ACID (Atomicity: 不可分性、Consistency: 一貫性、Isolation: 独立性、Durability: 永続性) プロパティをサポートします。ローカル XA リソースマネージャーをよく使うトランザクションシステムの例としては、データベース、アプリケーションサーバー、メッセージングキュー、トランザクションキャッシュなどがあります。 グローバルトランザクションマネージャーは、グローバルトランザクションに関与するすべてのローカル XA トランザクションマネージャー間で、グローバルトランザクションのトランザクションセマンティクスを調整する責任を持ちます。そのため、各ローカル XA リソースマネージャーとの間で、2 フェーズコミットの準備フェーズとコミットフェーズがそれぞれグローバルに (通常はネットワークを介して) 調整されます。 XA グローバルトランザクションのメリットは、1 つのグローバルトランザクションマネージャーが、複数の異なるトランザクションリソースとの間で、共通した標準的な方法でコミュニケーションと調整を行えるという点です。グローバルトランザクションでいずれかのローカルリソースマネージャーがエラーを報告すると、グローバルトランザクションマネージャーは、他のそれぞれのローカルリソースマネージャーですでに準備ができている操作のロールバックを調整します。 たとえば、グローバルトランザクションに、1 つまたは複数のデータベースに対する複数の操作と、JMS サーバーに送信される 1 つまたは複数のトピックに関連したメッセージが含まれるとします。トランザクションで何らかのエラーが発生すると、グローバルトランザクションマネージャーは、すべてのリソースがグローバルトランザクションの開始前の状態にリセットされることを保証します。このため、開発者は複雑なロールバックロジックや復元ロジックをアプリケーションの外部で定義しなくても済みます。 XA グローバルトランザクションのデメリットは、特に低速または信頼性の低いネットワーク接続経由でリソースが分散している場合には、トランザクションのレイテンシーが大幅に増大するという点です。また、グローバルに分散されているトランザクションの途中のシステムで物理的な障害が発生した場合には、復元が困難になることがあります。 ## [](#パフォーマンスに関する考慮事項)パフォーマンスに関する考慮事項 グローバル XA トランザクションは、高い信頼性で複数の XA リソースを調整できますが、多くの場合はレイテンシーが増大する上、外部トランザクションマネージャーなどの追加リソースが必要になります。また、グローバルトランザクションの信頼性は、グローバルトランザクションマネージャー自身の信頼性と同じです。さらに信頼性を高めるには、グローバルトランザクション中にトランザクションマネージャーがエラーとなったり、いずれかのローカル XA リソースマネージャーとの接続が失われたりした場合に備えて、グローバルトランザクションが準備フェーズ、そしてコミットフェーズへと進むに従って各 XA リソースの状態を格納しておくためのトランザクションマネージャーが必要です。 ## [](#xa-トランザクションを使用するためのリソースの設定)XA トランザクションを使用するためのリソースの設定 XA トランザクションをサポートするイベントソースの設定については、コネクタのドキュメントを参照してください。 - [JMS](https://docs.mulesoft.com/jms-connector/latest/jms-connector-reference#parameters-7) - [IBMMQ](https://docs.mulesoft.com/ibm-mq-connector/latest/ibm-mq-transactions#xa-transactions) - [VM](https://docs.mulesoft.com/jp/vm-connector/latest/vm-reference#parameters-6) - [データベース](https://docs.mulesoft.com/db-connector/latest/database-connector-xa-transactions) ## [](#xa-トランザクションを使用するための-try-スコープの設定)XA トランザクションを使用するための Try スコープの設定 XA トランザクションを使用するように Try スコープを設定するための手順は、次のとおりです。 1. Mule パレットから Try スコープを追加します。 2. \[Try\] 設定パネルで ​**\[General (一般)\]**​ タブに移動します。 3. Try スコープの ​`Transactional Action`​ を ​`ALWAYS_BEGIN`​、​`Transaction Type`​ を ​`XA`​ に設定します。 Try スコープがどのようにトランザクションを処理するかについての詳細は、​[「Try スコープの概念」](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept)​を参照してください。 ## [](#異なるリソースでの-xa-トランザクションの使用)異なるリソースでの XA トランザクションの使用 トランザクションをどのように (トランザクションイベントソースから、または Try スコープから) 開始するかには関係なく、トランザクションをサポートするコネクタ操作は、トランザクションアクションを ​`ALWAYS_JOIN`​ または ​`JOIN_IF_POSSIBLE`​ に設定することで、トランザクションを結合することができます。 XA トランザクションは、異なるリソースでも動作するため、異なるリソースからの操作でもトランザクションを結合できます。例: ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗すると、トランザクションがロールバックされてからエラーハンドラー (​`on-error-propagate`​) が実行されます。そのため、​`vm:publish`​ 経由で送信されるメッセージは送信されたかどうかが確定されず、​`jms:consume`​ のメッセージは実際にはコンシュームされず、次回に再びコンシュームできるように使用できます。 次の例では、エラーハンドラーが ​`on-error-continue`​ に変更されています。 ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗しても、トランザクションはロールバックされません。その代わりに、トランザクションは (XA トランザクション内で実行される) ​`jms:publish`​ の実行後にコミットされます。そのため、​`vm:publish`​ を使用して送信されるメッセージはパブリッシュされ、​`jms:consume`​ からのメッセージはコンシュームされ、​`jms:publish`​ を使用して送信されるメッセージもパブリッシュされます。 `on-error-continue`​ 内の ​`jms:publish`​ には、別のコネクタ設定もあります。これは必須ではありませんが可能です。ただし、単一の接続元 (ローカル) トランザクションでは、トランザクションを結合するすべての操作が同じ設定を使用しなければ設計通りには機能しないため、この設定は有効ではありません。 ## [](#ネストされたトランザクション)ネストされたトランザクション XA トランザクションは、ネストされたトランザクションをサポートします。Try スコープを使用して、すでに実行中のトランザクションの中に新しいトランザクションを作成することができます。新しいトランザクション内で実行される操作は、新しいトランザクションに属します。ネストされたトランザクションがロールバックされても、その親トランザクションもロールバックされるとは限りません。ネストされたトランザクションが (コミットまたはロールバックで) 完了すると、親トランザクションは実行を続行します。 例: ```xml ${insertQuery} ``` 上の例では、最初の ​`try`​ スコープでトランザクションを作成しています。そして、2 番目の ​`try`​ スコープで 2 番目のトランザクションを作成しています。​`vm:publish`​ 操作は最初のトランザクション内で実行され、​`jms:consume`​ と ​`db:insert`​ は 2 番目のトランザクション内で実行されます。エラーが発生すると、2 番目のトランザクションが ​`jms:consume`​ および ​`db:insert`​ 操作と共にロールバックされます。一方で、最初の ​`try`​ が ​`on-error-continue`​ でエラーを処理するため、最初のトランザクションは ​`vm:publish`​ 操作と共にコミットされます。 次の例を考えてみましょう。 ```xml ${insertQuery} ``` この例では、2 番目の ​`try`​ スコープはトランザクションを作成せず、以降の操作が継続できるようにエラーを処理するだけです。トランザクションを作成するのは 3 番目の ​`try`​ スコープです。​`vm:publish`​ と ​`db:insert`​ はどちらも最初のトランザクションで実行され、​`jms:consume`​ 操作は 2 番目のトランザクションで実行されます。エラーが発生すると、2 番目の操作がロールバックされます。エラーは、伝播されて 2 番目の ​`try`​ スコープの ​`on-error-continue`​ によって処理されます。その後、最初の ​`try`​ スコープが実行 (​`db:insert`​ 操作) を続行し、最初のトランザクションがコミットされます。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept) - [Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/using-bitronix-to-manage-transactions) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management) # XA トランザクション 拡張アーキテクチャトランザクション (XA トランザクション) を使用すると、VM、JMS、データベースといった複数のトランザクションリソースから一連の操作を取り出して、単一の信頼できるグローバルトランザクションとしてグループ化できます。 XA (eXtended Architecture: 拡張アーキテクチャ) 標準は、グローバルトランザクションマネージャーとローカルトランザクションリソースマネージャーとのインターフェースを定義する X/Open グループの標準です。XA プロトコルが定義する 2 フェーズコミットプロトコルを使用すると、種類の異なる複数のサーバーにまたがる一連のアトミック操作を高い信頼性で調整して順序付けることができます。各ローカル XA リソースマネージャーは、XA リソースマネージャーが管理するリソース内での一連の操作の完了を保証するのに役立つ ACID (Atomicity: 不可分性、Consistency: 一貫性、Isolation: 独立性、Durability: 永続性) プロパティをサポートします。ローカル XA リソースマネージャーをよく使うトランザクションシステムの例としては、データベース、アプリケーションサーバー、メッセージングキュー、トランザクションキャッシュなどがあります。 グローバルトランザクションマネージャーは、グローバルトランザクションに関与するすべてのローカル XA トランザクションマネージャー間で、グローバルトランザクションのトランザクションセマンティクスを調整する責任を持ちます。そのため、各ローカル XA リソースマネージャーとの間で、2 フェーズコミットの準備フェーズとコミットフェーズがそれぞれグローバルに (通常はネットワークを介して) 調整されます。 XA グローバルトランザクションのメリットは、1 つのグローバルトランザクションマネージャーが、複数の異なるトランザクションリソースとの間で、共通した標準的な方法でコミュニケーションと調整を行えるという点です。グローバルトランザクションでいずれかのローカルリソースマネージャーがエラーを報告すると、グローバルトランザクションマネージャーは、他のそれぞれのローカルリソースマネージャーですでに準備ができている操作のロールバックを調整します。 たとえば、グローバルトランザクションに、1 つまたは複数のデータベースに対する複数の操作と、JMS サーバーに送信される 1 つまたは複数のトピックに関連したメッセージが含まれるとします。トランザクションで何らかのエラーが発生すると、グローバルトランザクションマネージャーは、すべてのリソースがグローバルトランザクションの開始前の状態にリセットされることを保証します。このため、開発者は複雑なロールバックロジックや復元ロジックをアプリケーションの外部で定義しなくても済みます。 XA グローバルトランザクションのデメリットは、特に低速または信頼性の低いネットワーク接続経由でリソースが分散している場合には、トランザクションのレイテンシーが大幅に増大するという点です。また、グローバルに分散されているトランザクションの途中のシステムで物理的な障害が発生した場合には、復元が困難になることがあります。 ## [](#パフォーマンスに関する考慮事項)パフォーマンスに関する考慮事項 グローバル XA トランザクションは、高い信頼性で複数の XA リソースを調整できますが、多くの場合はレイテンシーが増大する上、外部トランザクションマネージャーなどの追加リソースが必要になります。また、グローバルトランザクションの信頼性は、グローバルトランザクションマネージャー自身の信頼性と同じです。さらに信頼性を高めるには、グローバルトランザクション中にトランザクションマネージャーがエラーとなったり、いずれかのローカル XA リソースマネージャーとの接続が失われたりした場合に備えて、グローバルトランザクションが準備フェーズ、そしてコミットフェーズへと進むに従って各 XA リソースの状態を格納しておくためのトランザクションマネージャーが必要です。 ## [](#xa-トランザクションを使用するためのリソースの設定)XA トランザクションを使用するためのリソースの設定 XA トランザクションをサポートするイベントソースの設定については、コネクタのドキュメントを参照してください。 - [JMS](https://docs.mulesoft.com/jms-connector/latest/jms-connector-reference#parameters-7) - [IBMMQ](https://docs.mulesoft.com/ibm-mq-connector/latest/ibm-mq-transactions#xa-transactions) - [VM](https://docs.mulesoft.com/jp/vm-connector/latest/vm-reference#parameters-6) - [データベース](https://docs.mulesoft.com/db-connector/latest/database-connector-xa-transactions) ## [](#xa-トランザクションを使用するための-try-スコープの設定)XA トランザクションを使用するための Try スコープの設定 XA トランザクションを使用するように Try スコープを設定するための手順は、次のとおりです。 1. Mule パレットから Try スコープを追加します。 2. \[Try\] 設定パネルで ​**\[General (一般)\]**​ タブに移動します。 3. Try スコープの ​`Transactional Action`​ を ​`ALWAYS_BEGIN`​、​`Transaction Type`​ を ​`XA`​ に設定します。 Try スコープがどのようにトランザクションを処理するかについての詳細は、​[「Try スコープの概念」](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept)​を参照してください。 ## [](#異なるリソースでの-xa-トランザクションの使用)異なるリソースでの XA トランザクションの使用 トランザクションをどのように (トランザクションイベントソースから、または Try スコープから) 開始するかには関係なく、トランザクションをサポートするコネクタ操作は、トランザクションアクションを ​`ALWAYS_JOIN`​ または ​`JOIN_IF_POSSIBLE`​ に設定することで、トランザクションを結合することができます。 XA トランザクションは、異なるリソースでも動作するため、異なるリソースからの操作でもトランザクションを結合できます。例: ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗すると、トランザクションがロールバックされてからエラーハンドラー (​`on-error-propagate`​) が実行されます。そのため、​`vm:publish`​ 経由で送信されるメッセージは送信されたかどうかが確定されず、​`jms:consume`​ のメッセージは実際にはコンシュームされず、次回に再びコンシュームできるように使用できます。 次の例では、エラーハンドラーが ​`on-error-continue`​ に変更されています。 ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗しても、トランザクションはロールバックされません。その代わりに、トランザクションは (XA トランザクション内で実行される) ​`jms:publish`​ の実行後にコミットされます。そのため、​`vm:publish`​ を使用して送信されるメッセージはパブリッシュされ、​`jms:consume`​ からのメッセージはコンシュームされ、​`jms:publish`​ を使用して送信されるメッセージもパブリッシュされます。 `on-error-continue`​ 内の ​`jms:publish`​ には、別のコネクタ設定もあります。これは必須ではありませんが可能です。ただし、単一の接続元 (ローカル) トランザクションでは、トランザクションを結合するすべての操作が同じ設定を使用しなければ設計通りには機能しないため、この設定は有効ではありません。 ## [](#ネストされたトランザクション)ネストされたトランザクション XA トランザクションは、ネストされたトランザクションをサポートします。Try スコープを使用して、すでに実行中のトランザクションの中に新しいトランザクションを作成することができます。新しいトランザクション内で実行される操作は、新しいトランザクションに属します。ネストされたトランザクションがロールバックされても、その親トランザクションもロールバックされるとは限りません。ネストされたトランザクションが (コミットまたはロールバックで) 完了すると、親トランザクションは実行を続行します。 例: ```xml ${insertQuery} ``` 上の例では、最初の ​`try`​ スコープでトランザクションを作成しています。そして、2 番目の ​`try`​ スコープで 2 番目のトランザクションを作成しています。​`vm:publish`​ 操作は最初のトランザクション内で実行され、​`jms:consume`​ と ​`db:insert`​ は 2 番目のトランザクション内で実行されます。エラーが発生すると、2 番目のトランザクションが ​`jms:consume`​ および ​`db:insert`​ 操作と共にロールバックされます。一方で、最初の ​`try`​ が ​`on-error-continue`​ でエラーを処理するため、最初のトランザクションは ​`vm:publish`​ 操作と共にコミットされます。 次の例を考えてみましょう。 ```xml ${insertQuery} ``` この例では、2 番目の ​`try`​ スコープはトランザクションを作成せず、以降の操作が継続できるようにエラーを処理するだけです。トランザクションを作成するのは 3 番目の ​`try`​ スコープです。​`vm:publish`​ と ​`db:insert`​ はどちらも最初のトランザクションで実行され、​`jms:consume`​ 操作は 2 番目のトランザクションで実行されます。エラーが発生すると、2 番目の操作がロールバックされます。エラーは、伝播されて 2 番目の ​`try`​ スコープの ​`on-error-continue`​ によって処理されます。その後、最初の ​`try`​ スコープが実行 (​`db:insert`​ 操作) を続行し、最初のトランザクションがコミットされます。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept) - [Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/using-bitronix-to-manage-transactions) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management) # XA トランザクション 拡張アーキテクチャトランザクション (XA トランザクション) を使用すると、VM、JMS、データベースといった複数のトランザクションリソースから一連の操作を取り出して、単一の信頼できるグローバルトランザクションとしてグループ化できます。 XA (eXtended Architecture: 拡張アーキテクチャ) 標準は、グローバルトランザクションマネージャーとローカルトランザクションリソースマネージャーとのインターフェースを定義する X/Open グループの標準です。XA プロトコルが定義する 2 フェーズコミットプロトコルを使用すると、種類の異なる複数のサーバーにまたがる一連のアトミック操作を高い信頼性で調整して順序付けることができます。各ローカル XA リソースマネージャーは、XA リソースマネージャーが管理するリソース内での一連の操作の完了を保証するのに役立つ ACID (Atomicity: 不可分性、Consistency: 一貫性、Isolation: 独立性、Durability: 永続性) プロパティをサポートします。ローカル XA リソースマネージャーをよく使うトランザクションシステムの例としては、データベース、アプリケーションサーバー、メッセージングキュー、トランザクションキャッシュなどがあります。 グローバルトランザクションマネージャーは、グローバルトランザクションに関与するすべてのローカル XA トランザクションマネージャー間で、グローバルトランザクションのトランザクションセマンティクスを調整する責任を持ちます。そのため、各ローカル XA リソースマネージャーとの間で、2 フェーズコミットの準備フェーズとコミットフェーズがそれぞれグローバルに (通常はネットワークを介して) 調整されます。 XA グローバルトランザクションのメリットは、1 つのグローバルトランザクションマネージャーが、複数の異なるトランザクションリソースとの間で、共通した標準的な方法でコミュニケーションと調整を行えるという点です。グローバルトランザクションでいずれかのローカルリソースマネージャーがエラーを報告すると、グローバルトランザクションマネージャーは、他のそれぞれのローカルリソースマネージャーですでに準備ができている操作のロールバックを調整します。 たとえば、グローバルトランザクションに、1 つまたは複数のデータベースに対する複数の操作と、JMS サーバーに送信される 1 つまたは複数のトピックに関連したメッセージが含まれるとします。トランザクションで何らかのエラーが発生すると、グローバルトランザクションマネージャーは、すべてのリソースがグローバルトランザクションの開始前の状態にリセットされることを保証します。このため、開発者は複雑なロールバックロジックや復元ロジックをアプリケーションの外部で定義しなくても済みます。 XA グローバルトランザクションのデメリットは、特に低速または信頼性の低いネットワーク接続経由でリソースが分散している場合には、トランザクションのレイテンシーが大幅に増大するという点です。また、グローバルに分散されているトランザクションの途中のシステムで物理的な障害が発生した場合には、復元が困難になることがあります。 ## [](#パフォーマンスに関する考慮事項)パフォーマンスに関する考慮事項 グローバル XA トランザクションは、高い信頼性で複数の XA リソースを調整できますが、多くの場合はレイテンシーが増大する上、外部トランザクションマネージャーなどの追加リソースが必要になります。また、グローバルトランザクションの信頼性は、グローバルトランザクションマネージャー自身の信頼性と同じです。さらに信頼性を高めるには、グローバルトランザクション中にトランザクションマネージャーがエラーとなったり、いずれかのローカル XA リソースマネージャーとの接続が失われたりした場合に備えて、グローバルトランザクションが準備フェーズ、そしてコミットフェーズへと進むに従って各 XA リソースの状態を格納しておくためのトランザクションマネージャーが必要です。 ## [](#xa-トランザクションを使用するためのリソースの設定)XA トランザクションを使用するためのリソースの設定 XA トランザクションをサポートするイベントソースの設定については、コネクタのドキュメントを参照してください。 - [JMS](https://docs.mulesoft.com/jms-connector/latest/jms-connector-reference#parameters-7) - [IBMMQ](https://docs.mulesoft.com/ibm-mq-connector/latest/ibm-mq-transactions#xa-transactions) - [VM](https://docs.mulesoft.com/jp/vm-connector/latest/vm-reference#parameters-6) - [データベース](https://docs.mulesoft.com/db-connector/latest/database-connector-xa-transactions) ## [](#xa-トランザクションを使用するための-try-スコープの設定)XA トランザクションを使用するための Try スコープの設定 XA トランザクションを使用するように Try スコープを設定するための手順は、次のとおりです。 1. Mule パレットから Try スコープを追加します。 2. \[Try\] 設定パネルで ​**\[General (一般)\]**​ タブに移動します。 3. Try スコープの ​`Transactional Action`​ を ​`ALWAYS_BEGIN`​、​`Transaction Type`​ を ​`XA`​ に設定します。 Try スコープがどのようにトランザクションを処理するかについての詳細は、​[「Try スコープの概念」](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept)​を参照してください。 ## [](#異なるリソースでの-xa-トランザクションの使用)異なるリソースでの XA トランザクションの使用 トランザクションをどのように (トランザクションイベントソースから、または Try スコープから) 開始するかには関係なく、トランザクションをサポートするコネクタ操作は、トランザクションアクションを ​`ALWAYS_JOIN`​ または ​`JOIN_IF_POSSIBLE`​ に設定することで、トランザクションを結合することができます。 XA トランザクションは、異なるリソースでも動作するため、異なるリソースからの操作でもトランザクションを結合できます。例: ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗すると、トランザクションがロールバックされてからエラーハンドラー (​`on-error-propagate`​) が実行されます。そのため、​`vm:publish`​ 経由で送信されるメッセージは送信されたかどうかが確定されず、​`jms:consume`​ のメッセージは実際にはコンシュームされず、次回に再びコンシュームできるように使用できます。 次の例では、エラーハンドラーが ​`on-error-continue`​ に変更されています。 ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗しても、トランザクションはロールバックされません。その代わりに、トランザクションは (XA トランザクション内で実行される) ​`jms:publish`​ の実行後にコミットされます。そのため、​`vm:publish`​ を使用して送信されるメッセージはパブリッシュされ、​`jms:consume`​ からのメッセージはコンシュームされ、​`jms:publish`​ を使用して送信されるメッセージもパブリッシュされます。 `on-error-continue`​ 内の ​`jms:publish`​ には、別のコネクタ設定もあります。これは必須ではありませんが可能です。ただし、単一の接続元 (ローカル) トランザクションでは、トランザクションを結合するすべての操作が同じ設定を使用しなければ設計通りには機能しないため、この設定は有効ではありません。 ## [](#ネストされたトランザクション)ネストされたトランザクション XA トランザクションは、ネストされたトランザクションをサポートします。Try スコープを使用して、すでに実行中のトランザクションの中に新しいトランザクションを作成することができます。新しいトランザクション内で実行される操作は、新しいトランザクションに属します。ネストされたトランザクションがロールバックされても、その親トランザクションもロールバックされるとは限りません。ネストされたトランザクションが (コミットまたはロールバックで) 完了すると、親トランザクションは実行を続行します。 例: ```xml ${insertQuery} ``` 上の例では、最初の ​`try`​ スコープでトランザクションを作成しています。そして、2 番目の ​`try`​ スコープで 2 番目のトランザクションを作成しています。​`vm:publish`​ 操作は最初のトランザクション内で実行され、​`jms:consume`​ と ​`db:insert`​ は 2 番目のトランザクション内で実行されます。エラーが発生すると、2 番目のトランザクションが ​`jms:consume`​ および ​`db:insert`​ 操作と共にロールバックされます。一方で、最初の ​`try`​ が ​`on-error-continue`​ でエラーを処理するため、最初のトランザクションは ​`vm:publish`​ 操作と共にコミットされます。 次の例を考えてみましょう。 ```xml ${insertQuery} ``` この場合、2 番目の ​`try`​ スコープはトランザクションを作成しません。このスコープは、以降の操作が継続できるようにエラーを処理するだけです。トランザクションを作成するのは 3 番目の ​`try`​ スコープです。​`vm:publish`​ と ​`db:insert`​ はどちらも最初のトランザクションで実行され、​`jms:consume`​ 操作は 2 番目のトランザクションで実行されます。エラーが発生すると、2 番目の操作がロールバックされます。エラーは、伝播されて 2 番目の ​`try`​ スコープの ​`on-error-continue`​ によって処理されます。その後、最初の ​`try`​ スコープが実行 (​`db:insert`​ 操作) を続行し、最初のトランザクションがコミットされます。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept) - [Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/using-bitronix-to-manage-transactions) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management) # XA トランザクション 拡張アーキテクチャトランザクション (XA トランザクション) を使用すると、VM、JMS、データベースといった複数のトランザクションリソースから一連の操作を取り出して、単一の信頼できるグローバルトランザクションとしてグループ化できます。 XA (eXtended Architecture: 拡張アーキテクチャ) 標準は、グローバルトランザクションマネージャーとローカルトランザクションリソースマネージャーとのインターフェースを定義する X/Open グループの標準です。XA プロトコルが定義する 2 フェーズコミットプロトコルを使用すると、種類の異なる複数のサーバーにまたがる一連のアトミック操作を高い信頼性で調整して順序付けることができます。各ローカル XA リソースマネージャーは、XA リソースマネージャーが管理するリソース内での一連の操作の完了を保証するのに役立つ ACID (Atomicity: 不可分性、Consistency: 一貫性、Isolation: 独立性、Durability: 永続性) プロパティをサポートします。ローカル XA リソースマネージャーをよく使うトランザクションシステムの例としては、データベース、アプリケーションサーバー、メッセージングキュー、トランザクションキャッシュなどがあります。 グローバルトランザクションマネージャーは、グローバルトランザクションに関与するすべてのローカル XA トランザクションマネージャー間で、グローバルトランザクションのトランザクションセマンティクスを調整する責任を持ちます。そのため、各ローカル XA リソースマネージャーとの間で、2 フェーズコミットの準備フェーズとコミットフェーズがそれぞれグローバルに (通常はネットワークを介して) 調整されます。 XA グローバルトランザクションのメリットは、1 つのグローバルトランザクションマネージャーが、複数の異なるトランザクションリソースとの間で、共通した標準的な方法でコミュニケーションと調整を行えるという点です。グローバルトランザクションでいずれかのローカルリソースマネージャーがエラーを報告すると、グローバルトランザクションマネージャーは、他のそれぞれのローカルリソースマネージャーですでに準備ができている操作のロールバックを調整します。 たとえば、グローバルトランザクションに、1 つまたは複数のデータベースに対する複数の操作と、JMS サーバーに送信される 1 つまたは複数のトピックに関連したメッセージが含まれるとします。トランザクションで何らかのエラーが発生すると、グローバルトランザクションマネージャーは、すべてのリソースがグローバルトランザクションの開始前の状態にリセットされることを保証します。このため、開発者は複雑なロールバックロジックや復元ロジックをアプリケーションの外部で定義しなくても済みます。 XA グローバルトランザクションのデメリットは、特に低速または信頼性の低いネットワーク接続経由でリソースが分散している場合には、トランザクションのレイテンシーが大幅に増大するという点です。また、グローバルに分散されているトランザクションの途中のシステムで物理的な障害が発生した場合には、復元が困難になることがあります。 ## [](#パフォーマンスに関する考慮事項)パフォーマンスに関する考慮事項 グローバル XA トランザクションは、高い信頼性で複数の XA リソースを調整できますが、多くの場合はレイテンシーが増大する上、外部トランザクションマネージャーなどの追加リソースが必要になります。また、グローバルトランザクションの信頼性は、グローバルトランザクションマネージャー自身の信頼性と同じです。さらに信頼性を高めるには、グローバルトランザクション中にトランザクションマネージャーがエラーとなったり、いずれかのローカル XA リソースマネージャーとの接続が失われたりした場合に備えて、グローバルトランザクションが準備フェーズ、そしてコミットフェーズへと進むに従って各 XA リソースの状態を格納しておくためのトランザクションマネージャーが必要です。 ## [](#xa-トランザクションを使用するためのリソースの設定)XA トランザクションを使用するためのリソースの設定 XA トランザクションをサポートするイベントソースの設定については、コネクタのドキュメントを参照してください。 - [JMS](https://docs.mulesoft.com/jms-connector/latest/jms-connector-reference#parameters-7) - [IBMMQ](https://docs.mulesoft.com/ibm-mq-connector/latest/ibm-mq-transactions#xa-transactions) - [VM](https://docs.mulesoft.com/jp/vm-connector/latest/vm-reference#parameters-6) - [データベース](https://docs.mulesoft.com/db-connector/latest/database-connector-xa-transactions) ## [](#xa-トランザクションを使用するための-try-スコープの設定)XA トランザクションを使用するための Try スコープの設定 XA トランザクションを使用するように Try スコープを設定するための手順は、次のとおりです。 1. Mule パレットから Try スコープを追加します。 2. \[Try\] 設定パネルで ​**\[General (一般)\]**​ タブに移動します。 3. Try スコープの ​`Transactional Action`​ を ​`ALWAYS_BEGIN`​、​`Transaction Type`​ を ​`XA`​ に設定します。 Try スコープがどのようにトランザクションを処理するかについての詳細は、​[「Try スコープの概念」](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept)​を参照してください。 ## [](#異なるリソースでの-xa-トランザクションの使用)異なるリソースでの XA トランザクションの使用 トランザクションをどのように (トランザクションイベントソースから、または Try スコープから) 開始するかには関係なく、トランザクションをサポートするコネクタ操作は、トランザクションアクションを ​`ALWAYS_JOIN`​ または ​`JOIN_IF_POSSIBLE`​ に設定することで、トランザクションを結合することができます。 XA トランザクションは、異なるリソースでも動作するため、異なるリソースからの操作でもトランザクションを結合できます。例: ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗すると、トランザクションがロールバックされてからエラーハンドラー (​`on-error-propagate`​) が実行されます。そのため、​`vm:publish`​ 経由で送信されるメッセージは送信されたかどうかが確定されず、​`jms:consume`​ のメッセージは実際にはコンシュームされず、次回に再びコンシュームできるように使用できます。 次の例では、エラーハンドラーが ​`on-error-continue`​ に変更されています。 ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗しても、トランザクションはロールバックされません。その代わりに、トランザクションは (XA トランザクション内で実行される) ​`jms:publish`​ の実行後にコミットされます。そのため、​`vm:publish`​ を使用して送信されるメッセージはパブリッシュされ、​`jms:consume`​ からのメッセージはコンシュームされ、​`jms:publish`​ を使用して送信されるメッセージもパブリッシュされます。 `on-error-continue`​ 内の ​`jms:publish`​ には、別のコネクタ設定もあります。これは必須ではありませんが可能です。ただし、単一の接続元 (ローカル) トランザクションでは、トランザクションを結合するすべての操作が同じ設定を使用しなければ設計通りには機能しないため、この設定は有効ではありません。 ## [](#ネストされたトランザクション)ネストされたトランザクション XA トランザクションは、ネストされたトランザクションをサポートします。Try スコープを使用して、すでに実行中のトランザクションの中に新しいトランザクションを作成することができます。新しいトランザクション内で実行される操作は、新しいトランザクションに属します。ネストされたトランザクションがロールバックされても、その親トランザクションもロールバックされるとは限りません。ネストされたトランザクションが (コミットまたはロールバックで) 完了すると、親トランザクションは実行を続行します。 例: ```xml ${insertQuery} ``` 上の例では、最初の ​`try`​ スコープでトランザクションを作成しています。そして、2 番目の ​`try`​ スコープで 2 番目のトランザクションを作成しています。​`vm:publish`​ 操作は最初のトランザクション内で実行され、​`jms:consume`​ と ​`db:insert`​ は 2 番目のトランザクション内で実行されます。エラーが発生すると、2 番目のトランザクションが ​`jms:consume`​ および ​`db:insert`​ 操作と共にロールバックされます。一方で、最初の ​`try`​ が ​`on-error-continue`​ でエラーを処理するため、最初のトランザクションは ​`vm:publish`​ 操作と共にコミットされます。 次の例を考えてみましょう。 ```xml ${insertQuery} ``` この場合、2 番目の ​`try`​ スコープはトランザクションを作成しません。このスコープは、以降の操作が継続できるようにエラーを処理するだけです。トランザクションを作成するのは 3 番目の ​`try`​ スコープです。​`vm:publish`​ と ​`db:insert`​ はどちらも最初のトランザクションで実行され、​`jms:consume`​ 操作は 2 番目のトランザクションで実行されます。エラーが発生すると、2 番目の操作がロールバックされます。エラーは、伝播されて 2 番目の ​`try`​ スコープの ​`on-error-continue`​ によって処理されます。その後、最初の ​`try`​ スコープが実行 (​`db:insert`​ 操作) を続行し、最初のトランザクションがコミットされます。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept) - [Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/using-bitronix-to-manage-transactions) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management) # XA トランザクション 拡張アーキテクチャトランザクション (XA トランザクション) を使用すると、VM、JMS、データベースといった複数のトランザクションリソースから一連の操作を取り出して、単一の信頼できるグローバルトランザクションとしてグループ化できます。 XA (eXtended Architecture: 拡張アーキテクチャ) 標準は、グローバルトランザクションマネージャーとローカルトランザクションリソースマネージャーとのインターフェースを定義する X/Open グループの標準です。XA プロトコルが定義する 2 フェーズコミットプロトコルを使用すると、種類の異なる複数のサーバーにまたがる一連のアトミック操作を高い信頼性で調整して順序付けることができます。各ローカル XA リソースマネージャーは、XA リソースマネージャーが管理するリソース内での一連の操作の完了を保証するのに役立つ ACID (Atomicity: 不可分性、Consistency: 一貫性、Isolation: 独立性、Durability: 永続性) プロパティをサポートします。ローカル XA リソースマネージャーをよく使うトランザクションシステムの例としては、データベース、アプリケーションサーバー、メッセージングキュー、トランザクションキャッシュなどがあります。 グローバルトランザクションマネージャーは、グローバルトランザクションに関与するすべてのローカル XA トランザクションマネージャー間で、グローバルトランザクションのトランザクションセマンティクスを調整する責任を持ちます。そのため、各ローカル XA リソースマネージャーとの間で、2 フェーズコミットの準備フェーズとコミットフェーズがそれぞれグローバルに (通常はネットワークを介して) 調整されます。 XA グローバルトランザクションのメリットは、1 つのグローバルトランザクションマネージャーが、複数の異なるトランザクションリソースとの間で、共通した標準的な方法でコミュニケーションと調整を行えるという点です。グローバルトランザクションでいずれかのローカルリソースマネージャーがエラーを報告すると、グローバルトランザクションマネージャーは、他のそれぞれのローカルリソースマネージャーですでに準備ができている操作のロールバックを調整します。 たとえば、グローバルトランザクションに、1 つまたは複数のデータベースに対する複数の操作と、JMS サーバーに送信される 1 つまたは複数のトピックに関連したメッセージが含まれるとします。トランザクションで何らかのエラーが発生すると、グローバルトランザクションマネージャーは、すべてのリソースがグローバルトランザクションの開始前の状態にリセットされることを保証します。このため、開発者は複雑なロールバックロジックや復元ロジックをアプリケーションの外部で定義しなくても済みます。 XA グローバルトランザクションのデメリットは、特に低速または信頼性の低いネットワーク接続経由でリソースが分散している場合には、トランザクションのレイテンシーが大幅に増大するという点です。また、グローバルに分散されているトランザクションの途中のシステムで物理的な障害が発生した場合には、復元が困難になることがあります。 ## [](#パフォーマンスに関する考慮事項)パフォーマンスに関する考慮事項 グローバル XA トランザクションは、高い信頼性で複数の XA リソースを調整できますが、多くの場合はレイテンシーが増大する上、外部トランザクションマネージャーなどの追加リソースが必要になります。また、グローバルトランザクションの信頼性は、グローバルトランザクションマネージャー自身の信頼性と同じです。さらに信頼性を高めるには、グローバルトランザクション中にトランザクションマネージャーがエラーとなったり、いずれかのローカル XA リソースマネージャーとの接続が失われたりした場合に備えて、グローバルトランザクションが準備フェーズ、そしてコミットフェーズへと進むに従って各 XA リソースの状態を格納しておくためのトランザクションマネージャーが必要です。 ## [](#xa-トランザクションを使用するためのリソースの設定)XA トランザクションを使用するためのリソースの設定 XA トランザクションをサポートするイベントソースの設定については、コネクタのドキュメントを参照してください。 - [JMS Connector](https://docs.mulesoft.com/jms-connector/latest/jms-xa-transactions) - [IBM MQ Connector](https://docs.mulesoft.com/ibm-mq-connector/latest/ibm-mq-transactions#xa-transactions) - [VM Connector](https://docs.mulesoft.com/jp/vm-connector/latest/vm-reference#parameters-6) - [Database Connector](https://docs.mulesoft.com/db-connector/latest/database-connector-xa-transactions) ## [](#xa-トランザクションを使用するための-try-スコープの設定)XA トランザクションを使用するための Try スコープの設定 XA トランザクションを使用するように Try スコープを設定するための手順は、次のとおりです。 1. Mule パレットから Try スコープを追加します。 2. \[Try\] 設定パネルで ​**\[General (一般)\]**​ タブに移動します。 3. Try スコープの ​`Transactional Action`​ を ​`ALWAYS_BEGIN`​、​`Transaction Type`​ を ​`XA`​ に設定します。 Try スコープがどのようにトランザクションを処理するかについての詳細は、​[「Try スコープの概念」](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept)​を参照してください。 ## [](#異なるリソースでの-xa-トランザクションの使用)異なるリソースでの XA トランザクションの使用 トランザクションをどのように (トランザクションイベントソースから、または Try スコープから) 開始するかには関係なく、トランザクションをサポートするコネクタ操作は、トランザクションアクションを ​`ALWAYS_JOIN`​ または ​`JOIN_IF_POSSIBLE`​ に設定することで、トランザクションを結合することができます。 XA トランザクションは、異なるリソースでも動作するため、異なるリソースからの操作でもトランザクションを結合できます。例: ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗すると、トランザクションがロールバックされてからエラーハンドラー (​`on-error-propagate`​) が実行されます。そのため、​`vm:publish`​ 経由で送信されるメッセージは送信されたかどうかが確定されず、​`jms:consume`​ のメッセージは実際にはコンシュームされず、次回に再びコンシュームできるように使用できます。 次の例では、エラーハンドラーが ​`on-error-continue`​ に変更されています。 ```xml ${insertQuery} ``` `db:insert`​ 操作が失敗しても、トランザクションはロールバックされません。その代わりに、トランザクションは (XA トランザクション内で実行される) ​`jms:publish`​ の実行後にコミットされます。そのため、​`vm:publish`​ を使用して送信されるメッセージはパブリッシュされ、​`jms:consume`​ からのメッセージはコンシュームされ、​`jms:publish`​ を使用して送信されるメッセージもパブリッシュされます。 `on-error-continue`​ 内の ​`jms:publish`​ には、別のコネクタ設定もあります。これは必須ではありませんが可能です。ただし、単一の接続元 (ローカル) トランザクションでは、トランザクションを結合するすべての操作が同じ設定を使用しなければ設計通りには機能しないため、この設定は有効ではありません。 ## [](#ネストされたトランザクション)ネストされたトランザクション XA トランザクションは、ネストされたトランザクションをサポートします。Try スコープを使用して、すでに実行中のトランザクションの中に新しいトランザクションを作成することができます。新しいトランザクション内で実行される操作は、新しいトランザクションに属します。ネストされたトランザクションがロールバックされても、その親トランザクションもロールバックされるとは限りません。ネストされたトランザクションが (コミットまたはロールバックで) 完了すると、親トランザクションは実行を続行します。 例: ```xml ${insertQuery} ``` 上の例では、最初の ​`try`​ スコープでトランザクションを作成しています。そして、2 番目の ​`try`​ スコープで 2 番目のトランザクションを作成しています。​`vm:publish`​ 操作は最初のトランザクション内で実行され、​`jms:consume`​ と ​`db:insert`​ は 2 番目のトランザクション内で実行されます。エラーが発生すると、2 番目のトランザクションが ​`jms:consume`​ および ​`db:insert`​ 操作と共にロールバックされます。一方で、最初の ​`try`​ が ​`on-error-continue`​ でエラーを処理するため、最初のトランザクションは ​`vm:publish`​ 操作と共にコミットされます。 次の例を考えてみましょう。 ```xml ${insertQuery} ``` この場合、2 番目の ​`try`​ スコープはトランザクションを作成しません。このスコープは、以降の操作が継続できるようにエラーを処理するだけです。トランザクションを作成するのは 3 番目の ​`try`​ スコープです。​`vm:publish`​ と ​`db:insert`​ はどちらも最初のトランザクションで実行され、​`jms:consume`​ 操作は 2 番目のトランザクションで実行されます。エラーが発生すると、2 番目の操作がロールバックされます。エラーは、伝播されて 2 番目の ​`try`​ スコープの ​`on-error-continue`​ によって処理されます。その後、最初の ​`try`​ スコープが実行 (​`db:insert`​ 操作) を続行し、最初のトランザクションがコミットされます。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept) - [Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/using-bitronix-to-manage-transactions) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management) # XML Module の移行 Mule 3 にバンドルされていた XML Module が、Mule 4 で新しい XML Module に置き換わります。主な変更は次のとおりです。 - Mule 3.6 で非推奨となったコンポーネント、式、関数、エバリュエーターの削除。 - jxpath-filter - jaxen-filter - jxpath-extractor-transformer - is-xml-filter - xpath-filter - 新しい Mule 4 コンポーネントとの一貫性を保つために、主に次に関して XPath、XSLT、XQuery コンポーネントで行われた変更。 - `mxml`​ から ​`xml-module`​ に変更された DSL 名前空間プレフィックス - 戻り値の型の一貫性 - 構文と UX の変更 - `xpath()`​ 関数と ​`xpath3()`​ 関数が ​`XmlModule::xpath()`​ 関数に置き換わりました。 - スキーマ検証機能のエラーレポートが改善されました。 - `schema-validation-filter`​ が ​`schema-validator`​ に置き換わりました。 - Java との関連付けがなくなり、SAX、StaX、DOM 型は使用されなくなりました。Mule 4 では、厳密に型指定されるようになり、どのデータが XML 形式なのかについて MIME タイプの情報を把握しています。残りは Runtime によって自動的に行われます。すべての XML ドキュメントは、文字列またはストリームのいずれかとして表されます。つまり、次は存在しません (不要になりました)。 - dom-to-xml-transformer - dom-to-output-handler-transformer - xml-to-dom-transformer - xml-prettyprinter-transformer - jaxb-object-to-xml-transformer - jaxb-xml-to-object-transformer - jaxb-context - object-to-xml-transformer - xml-to-object-transformer ## [](#xslt-操作の移行)XSLT 操作の移行 ### [](#外部ファイルでの-xsl-スタイルシートの使用)外部ファイルでの XSL スタイルシートの使用 Mule 3 の例: 外部ファイルでの XSL シートの使用方法 ```xml ``` Mule 4 の場合: Mule 4 の例: 外部ファイルでの XSL シートの使用方法 ```xml ${file:::cities.xslt} ``` ### [](#コンテキストプロパティの使用)コンテキストプロパティの使用 Mule 3 の例: コンテキストプロパティの設定方法 ```xml ``` Mule 4 の例: コンテキストプロパティの設定方法 ```xml ${file::cities.xslt} #[{'output_location': vars.outputFile, 'user_id': vars.userId}] ``` ## [](#xpath-操作と式の移行)XPath 操作と式の移行 ### [](#xpath-抽出器トランスフォーマーの使用)XPath 抽出器トランスフォーマーの使用 XPath extractor (XPath エクストラクター) では、カスタム ​`resultType`​ パラメーターがサポートされなくなりました。一致するすべての要素を含む文字列のリストが常に返されるようになります。 Mule 3 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` Mule 4 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` ### [](#xpath-式関数の使用)XPath 式関数の使用 Mule 3 には元々、​`xpath()`​ MEL 関数がありました。それが Mule 3.6 で非推奨となり、新しい ​`xpath3()`​ 関数が使用されました。今回は、両方の関数が新しい ​`XmlModule::xpath()`​ DataWeave 関数に置き換わります。これは、アプリケーションにモジュールを追加すると使用可能になります。 Mule 3 の例: xpath3 関数の使用 ```xml ``` Mule 3 の ​`xpath3()`​ 関数では、XPath 式と入力値を指定でき、予期される出力では、​`BOOLEAN`​、​`STRING`​、​`NUMBER`​、​`NODESET`​、または ​`NODE`​ というさまざまなオプションが用意されていました。​`NODESET`​ と ​`NODE`​ の場合は、Java の DOM ツリー表現を理解している必要がありました。 また、新しい関数は XPath 式と入力を受け入れますが、次の点で異なります。 - カスタムコンテキストプロパティのサポートが追加される。 - 出力タイプを指定できない。​``​ と同様に、常に文字列のリストが返される。 Mule 4 の例: xpath 関数の使用 ```xml ```
この関数は、どの DataWeave 変換内でも使用できます。
### [](#カスタム名前空間を指定した-xpath-の使用)カスタム名前空間を指定した XPath の使用 Mule 3 でカスタム名前空間プレフィックスをマップするには ​``​ が必要です。 Mule 3 の例: カスタム名前空間の使用 ```xml ``` このアプローチには、アプリケーションごとに使用できる namespace-manager は 1 つだけという制限があります。Mule 4 では、必要な数だけ ​`namespace-directory`​ 要素を宣言し、各操作で必要なものを参照できます。 Mule 4 の例: カスタム名前空間の使用 ```xml ``` さらに、「namespace-directory」を宣言しないことも可能で、代わりに名前空間をインラインでマップできます。 Mule 4 の例: インラインのカスタム名前空間マッピング ```xml ``` ## [](#xquery-操作の移行)XQuery 操作の移行 主な違いは、Mule 3 ではこのトランスフォーマーの出力タイプは変換の結果に応じて異なるということです。 - 変換で要素が多数生成される場合は、リストが返されます。 - 変換に応じて、そのリストの要素は文字列になるか、​`Node`​ などの汎用 Java 表現になります。 - 変換により要素が 1 つだけ生成される場合は、その要素が返されます。 Mule 4 では、常に文字列のリストが返されます。 それ以外の変更は、構文に関するもののみです。 Mule 3 の例: XQuery トランスフォーマーの使用 ```xml { for $b in $books/BOOKLIST/BOOKS/ITEM, $c in $cities/cities/city return } ]]> ``` Mule 4 の場合: Mule 4 の例: XQuery トランスフォーマーの使用 ```xml { for $b in fn:doc($books)/BOOKLIST/BOOKS/ITEM, $c in fn:doc($cities)/cities/city return } ]]> #[{'books' : vars.books, 'cities': vars.cities}] ``` ## [](#スキーマに対する-xml-の検証)スキーマに対する XML の検証 Mule 3 では、検索条件を使用してスキーマの検証が行われていました。 Mule 3 の例: Schema validation filter (スキーマ検証検索条件) ```xml ``` 検証が失敗すると、メッセージは放棄されます。 Mule 4 では、検索条件がバリデーターに置き換わりました。 Mule 4 の例: スキーマバリデーター ```xml ``` このバリデーターは、​`XML-MODULE:SCHEMA_NOT_HONOURED`​ エラーを発生させます。 ## [](#xml-module-のインストール)XML Module のインストール XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # XML Module の移行 Mule 3 にバンドルされていた XML Module が、Mule 4 で新しい XML Module に置き換わります。主な変更は次のとおりです。 - Mule 3.6 で非推奨となったコンポーネント、式、関数、エバリュエーターの削除。 - jxpath-filter - jaxen-filter - jxpath-extractor-transformer - is-xml-filter - xpath-filter - 新しい Mule 4 コンポーネントとの一貫性を保つために、主に次に関して XPath、XSLT、XQuery コンポーネントで行われた変更。 - `mxml`​ から ​`xml-module`​ に変更された DSL 名前空間プレフィックス - 戻り値の型の一貫性 - 構文と UX の変更 - `xpath()`​ 関数と ​`xpath3()`​ 関数が ​`XmlModule::xpath()`​ 関数に置き換わりました。 - スキーマ検証機能のエラーレポートが改善されました。 - `schema-validation-filter`​ が ​`schema-validator`​ に置き換わりました。 - Java との関連付けがなくなり、SAX、StaX、DOM 型は使用されなくなりました。Mule 4 では、厳密に型指定されるようになり、どのデータが XML 形式なのかについて MIME タイプの情報を把握しています。残りは Runtime によって自動的に行われます。すべての XML ドキュメントは、文字列またはストリームのいずれかとして表されます。つまり、次は存在しません (不要になりました)。 - dom-to-xml-transformer - dom-to-output-handler-transformer - xml-to-dom-transformer - xml-prettyprinter-transformer - jaxb-object-to-xml-transformer - jaxb-xml-to-object-transformer - jaxb-context - object-to-xml-transformer - xml-to-object-transformer ## [](#xslt-操作の移行)XSLT 操作の移行 ### [](#外部ファイルでの-xsl-スタイルシートの使用)外部ファイルでの XSL スタイルシートの使用 Mule 3 の例: 外部ファイルでの XSL シートの使用方法 ```xml ``` Mule 4 の場合: Mule 4 の例: 外部ファイルでの XSL シートの使用方法 ```xml ${file:::cities.xslt} ``` ### [](#コンテキストプロパティの使用)コンテキストプロパティの使用 Mule 3 の例: コンテキストプロパティの設定方法 ```xml ``` Mule 4 の例: コンテキストプロパティの設定方法 ```xml ${file::cities.xslt} #[{'output_location': vars.outputFile, 'user_id': vars.userId}] ``` ## [](#xpath-操作と式の移行)XPath 操作と式の移行 ### [](#xpath-抽出器トランスフォーマーの使用)XPath 抽出器トランスフォーマーの使用 XPath extractor (XPath エクストラクター) では、カスタム ​`resultType`​ パラメーターがサポートされなくなりました。一致するすべての要素を含む文字列のリストが常に返されるようになります。 Mule 3 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` Mule 4 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` ### [](#xpath-式関数の使用)XPath 式関数の使用 Mule 3 には元々、​`xpath()`​ MEL 関数がありました。それが Mule 3.6 で非推奨となり、新しい ​`xpath3()`​ 関数が使用されました。今回は、両方の関数が新しい ​`XmlModule::xpath()`​ DataWeave 関数に置き換わります。これは、アプリケーションにモジュールを追加すると使用可能になります。 Mule 3 の例: xpath3 関数の使用 ```xml ``` Mule 3 の ​`xpath3()`​ 関数では、XPath 式と入力値を指定でき、予期される出力では、​`BOOLEAN`​、​`STRING`​、​`NUMBER`​、​`NODESET`​、または ​`NODE`​ というさまざまなオプションが用意されていました。​`NODESET`​ と ​`NODE`​ の場合は、Java の DOM ツリー表現を理解している必要がありました。 また、新しい関数は XPath 式と入力を受け入れますが、次の点で異なります。 - カスタムコンテキストプロパティのサポートが追加される。 - 出力タイプを指定できない。​``​ と同様に、常に文字列のリストが返される。 Mule 4 の例: xpath 関数の使用 ```xml ```
この関数は、どの DataWeave 変換内でも使用できます。
### [](#カスタム名前空間を指定した-xpath-の使用)カスタム名前空間を指定した XPath の使用 Mule 3 でカスタム名前空間プレフィックスをマップするには ​``​ が必要です。 Mule 3 の例: カスタム名前空間の使用 ```xml ``` このアプローチには、アプリケーションごとに使用できる namespace-manager は 1 つだけという制限があります。Mule 4 では、必要な数だけ ​`namespace-directory`​ 要素を宣言し、各操作で必要なものを参照できます。 Mule 4 の例: カスタム名前空間の使用 ```xml ``` さらに、「namespace-directory」を宣言しないことも可能で、代わりに名前空間をインラインでマップできます。 Mule 4 の例: インラインのカスタム名前空間マッピング ```xml ``` ## [](#xquery-操作の移行)XQuery 操作の移行 主な違いは、Mule 3 ではこのトランスフォーマーの出力タイプは変換の結果に応じて異なるということです。 - 変換で要素が多数生成される場合は、リストが返されます。 - 変換に応じて、そのリストの要素は文字列になるか、​`Node`​ などの汎用 Java 表現になります。 - 変換により要素が 1 つだけ生成される場合は、その要素が返されます。 Mule 4 では、常に文字列のリストが返されます。 それ以外の変更は、構文に関するもののみです。 Mule 3 の例: XQuery トランスフォーマーの使用 ```xml { for $b in $books/BOOKLIST/BOOKS/ITEM, $c in $cities/cities/city return } ]]> ``` Mule 4 の場合: Mule 4 の例: XQuery トランスフォーマーの使用 ```xml { for $b in fn:doc($books)/BOOKLIST/BOOKS/ITEM, $c in fn:doc($cities)/cities/city return } ]]> #[{'books' : vars.books, 'cities': vars.cities}] ``` ## [](#スキーマに対する-xml-の検証)スキーマに対する XML の検証 Mule 3 では、検索条件を使用してスキーマの検証が行われていました。 Mule 3 の例: Schema validation filter (スキーマ検証検索条件) ```xml ``` 検証が失敗すると、メッセージは放棄されます。 Mule 4 では、検索条件がバリデーターに置き換わりました。 Mule 4 の例: スキーマバリデーター ```xml ``` このバリデーターは、​`XML-MODULE:SCHEMA_NOT_HONOURED`​ エラーを発生させます。 ## [](#xml-module-のインストール)XML Module のインストール XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # XML Module の移行 Mule 3 にバンドルされていた XML Module が、Mule 4 で新しい XML Module に置き換わります。主な変更は次のとおりです。 - Mule 3.6 で非推奨となったコンポーネント、式、関数、エバリュエーターの削除。 - jxpath-filter - jaxen-filter - jxpath-extractor-transformer - is-xml-filter - xpath-filter - 新しい Mule 4 コンポーネントとの一貫性を保つために、主に次に関して XPath、XSLT、XQuery コンポーネントで行われた変更。 - `mxml`​ から ​`xml-module`​ に変更された DSL 名前空間プレフィックス - 戻り値の型の一貫性 - 構文と UX の変更 - `xpath()`​ 関数と ​`xpath3()`​ 関数が ​`XmlModule::xpath()`​ 関数に置き換わりました。 - スキーマ検証機能のエラーレポートが改善されました。 - `schema-validation-filter`​ が ​`schema-validator`​ に置き換わりました。 - Java との関連付けがなくなり、SAX、StaX、DOM 型は使用されなくなりました。Mule 4 では、厳密に型指定されるようになり、どのデータが XML 形式なのかについて MIME タイプの情報を把握しています。残りは Runtime によって自動的に行われます。すべての XML ドキュメントは、文字列またはストリームのいずれかとして表されます。つまり、次は存在しません (不要になりました)。 - dom-to-xml-transformer - dom-to-output-handler-transformer - xml-to-dom-transformer - xml-prettyprinter-transformer - jaxb-object-to-xml-transformer - jaxb-xml-to-object-transformer - jaxb-context - object-to-xml-transformer - xml-to-object-transformer ## [](#xslt-操作の移行)XSLT 操作の移行 ### [](#外部ファイルでの-xsl-スタイルシートの使用)外部ファイルでの XSL スタイルシートの使用 Mule 3 の例: 外部ファイルでの XSL シートの使用方法 ```xml ``` Mule 4 の場合: Mule 4 の例: 外部ファイルでの XSL シートの使用方法 ```xml ${file:::cities.xslt} ``` ### [](#コンテキストプロパティの使用)コンテキストプロパティの使用 Mule 3 の例: コンテキストプロパティの設定方法 ```xml ``` Mule 4 の例: コンテキストプロパティの設定方法 ```xml ${file::cities.xslt} #[{'output_location': vars.outputFile, 'user_id': vars.userId}] ``` ## [](#xpath-操作と式の移行)XPath 操作と式の移行 ### [](#xpath-抽出器トランスフォーマーの使用)XPath 抽出器トランスフォーマーの使用 XPath extractor (XPath エクストラクター) では、カスタム ​`resultType`​ パラメーターがサポートされなくなりました。一致するすべての要素を含む文字列のリストが常に返されるようになります。 Mule 3 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` Mule 4 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` ### [](#xpath-式関数の使用)XPath 式関数の使用 Mule 3 には元々、​`xpath()`​ MEL 関数がありました。それが Mule 3.6 で非推奨となり、新しい ​`xpath3()`​ 関数が使用されました。今回は、両方の関数が新しい ​`XmlModule::xpath()`​ DataWeave 関数に置き換わります。これは、アプリケーションにモジュールを追加すると使用可能になります。 Mule 3 の例: xpath3 関数の使用 ```xml ``` Mule 3 の ​`xpath3()`​ 関数では、XPath 式と入力値を指定でき、予期される出力では、​`BOOLEAN`​、​`STRING`​、​`NUMBER`​、​`NODESET`​、または ​`NODE`​ というさまざまなオプションが用意されていました。​`NODESET`​ と ​`NODE`​ の場合は、Java の DOM ツリー表現を理解している必要がありました。 また、新しい関数は XPath 式と入力を受け入れますが、次の点で異なります。 - カスタムコンテキストプロパティのサポートが追加される。 - 出力タイプを指定できない。​``​ と同様に、常に文字列のリストが返される。 Mule 4 の例: xpath 関数の使用 ```xml ```
この関数は、どの DataWeave 変換内でも使用できます。
### [](#カスタム名前空間を指定した-xpath-の使用)カスタム名前空間を指定した XPath の使用 Mule 3 でカスタム名前空間プレフィックスをマップするには ​``​ が必要です。 Mule 3 の例: カスタム名前空間の使用 ```xml ``` このアプローチには、アプリケーションごとに使用できる namespace-manager は 1 つだけという制限があります。Mule 4 では、必要な数だけ ​`namespace-directory`​ 要素を宣言し、各操作で必要なものを参照できます。 Mule 4 の例: カスタム名前空間の使用 ```xml ``` さらに、'namespace-directory' を宣言しないことも可能で、代わりに名前空間をインラインでマップできます。 Mule 4 の例: インラインのカスタム名前空間マッピング ```xml ``` ## [](#xquery-操作の移行)XQuery 操作の移行 主な違いは、Mule 3 ではこのトランスフォーマーの出力タイプは変換の結果に応じて異なるということです。 - 変換で要素が多数生成される場合は、リストが返されます。 - 変換に応じて、そのリストの要素は文字列になるか、​`Node`​ などの汎用 Java 表現になります。 - 変換により要素が 1 つだけ生成される場合は、その要素が返されます。 Mule 4 では、常に文字列のリストが返されます。 それ以外の変更は、構文に関するもののみです。 Mule 3 の例: XQuery トランスフォーマーの使用 ```xml { for $b in $books/BOOKLIST/BOOKS/ITEM, $c in $cities/cities/city return } ]]> ``` Mule 4 の場合: Mule 4 の例: XQuery トランスフォーマーの使用 ```xml { for $b in fn:doc($books)/BOOKLIST/BOOKS/ITEM, $c in fn:doc($cities)/cities/city return } ]]> #[{'books' : vars.books, 'cities': vars.cities}] ``` ## [](#スキーマに対する-xml-の検証)スキーマに対する XML の検証 Mule 3 では、検索条件を使用してスキーマの検証が行われていました。 Mule 3 の例: Schema validation filter (スキーマ検証検索条件) ```xml ``` 検証が失敗すると、メッセージは放棄されます。 Mule 4 では、検索条件がバリデーターに置き換わりました。 Mule 4 の例: スキーマバリデーター ```xml ``` このバリデーターは、​`XML-MODULE:SCHEMA_NOT_HONOURED`​ エラーを発生させます。 ## [](#xml-module-のインストール)XML Module のインストール XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # XML Module の移行 Mule 3 にバンドルされていた XML Module が、Mule 4 で新しい XML Module に置き換わります。主な変更は次のとおりです。 - Mule 3.6 で非推奨となったコンポーネント、式、関数、エバリュエーターの削除。 - jxpath-filter - jaxen-filter - jxpath-extractor-transformer - is-xml-filter - xpath-filter - 新しい Mule 4 コンポーネントとの一貫性を保つために、主に次に関して XPath、XSLT、XQuery コンポーネントで行われた変更。 - `mxml`​ から ​`xml-module`​ に変更された DSL 名前空間プレフィックス - 戻り値の型の一貫性 - 構文と UX の変更 - `xpath()`​ 関数と ​`xpath3()`​ 関数が ​`XmlModule::xpath()`​ 関数に置き換わりました。 - スキーマ検証機能のエラーレポートが改善されました。 - `schema-validation-filter`​ が ​`schema-validator`​ に置き換わりました。 - Java との関連付けがなくなり、SAX、StaX、DOM 型は使用されなくなりました。Mule 4 では、厳密に型指定されるようになり、どのデータが XML 形式なのかについて MIME タイプの情報を把握しています。残りは Runtime によって自動的に行われます。すべての XML ドキュメントは、文字列またはストリームのいずれかとして表されます。つまり、次は存在しません (不要になりました)。 - dom-to-xml-transformer - dom-to-output-handler-transformer - xml-to-dom-transformer - xml-prettyprinter-transformer - jaxb-object-to-xml-transformer - jaxb-xml-to-object-transformer - jaxb-context - object-to-xml-transformer - xml-to-object-transformer ## [](#xslt-操作の移行)XSLT 操作の移行 ### [](#外部ファイルでの-xsl-スタイルシートの使用)外部ファイルでの XSL スタイルシートの使用 Mule 3 の例: 外部ファイルでの XSL シートの使用方法 ```xml ``` Mule 4 の場合: Mule 4 の例: 外部ファイルでの XSL シートの使用方法 ```xml ${file:::cities.xslt} ``` ### [](#コンテキストプロパティの使用)コンテキストプロパティの使用 Mule 3 の例: コンテキストプロパティの設定方法 ```xml ``` Mule 4 の例: コンテキストプロパティの設定方法 ```xml ${file::cities.xslt} #[{'output_location': vars.outputFile, 'user_id': vars.userId}] ``` ## [](#xpath-操作と式の移行)XPath 操作と式の移行 ### [](#xpath-抽出器トランスフォーマーの使用)XPath 抽出器トランスフォーマーの使用 XPath extractor (XPath エクストラクター) では、カスタム ​`resultType`​ パラメーターがサポートされなくなりました。一致するすべての要素を含む文字列のリストが常に返されるようになります。 Mule 3 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` Mule 4 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` ### [](#xpath-式関数の使用)XPath 式関数の使用 Mule 3 には元々、​`xpath()`​ MEL 関数がありました。それが Mule 3.6 で非推奨となり、新しい ​`xpath3()`​ 関数が使用されました。今回は、両方の関数が新しい ​`XmlModule::xpath()`​ DataWeave 関数に置き換わります。これは、アプリケーションにモジュールを追加すると使用可能になります。 Mule 3 の例: xpath3 関数の使用 ```xml ``` Mule 3 の ​`xpath3()`​ 関数では、XPath 式と入力値を指定でき、予期される出力では、​`BOOLEAN`​、​`STRING`​、​`NUMBER`​、​`NODESET`​、または ​`NODE`​ というさまざまなオプションが用意されていました。​`NODESET`​ と ​`NODE`​ の場合は、Java の DOM ツリー表現を理解している必要がありました。 また、新しい関数は XPath 式と入力を受け入れますが、次の点で異なります。 - カスタムコンテキストプロパティのサポートが追加される。 - 出力タイプを指定できない。​``​ と同様に、常に文字列のリストが返される。 Mule 4 の例: xpath 関数の使用 ```xml ```
この関数は、どの DataWeave 変換内でも使用できます。
### [](#カスタム名前空間を指定した-xpath-の使用)カスタム名前空間を指定した XPath の使用 Mule 3 でカスタム名前空間プレフィックスをマップするには ​``​ が必要です。 Mule 3 の例: カスタム名前空間の使用 ```xml ``` このアプローチには、アプリケーションごとに使用できる namespace-manager は 1 つだけという制限があります。Mule 4 では、必要な数だけ ​`namespace-directory`​ 要素を宣言し、各操作で必要なものを参照できます。 Mule 4 の例: カスタム名前空間の使用 ```xml ``` さらに、'namespace-directory' を宣言しないことも可能で、代わりに名前空間をインラインでマップできます。 Mule 4 の例: インラインのカスタム名前空間マッピング ```xml ``` ## [](#xquery-操作の移行)XQuery 操作の移行 主な違いは、Mule 3 ではこのトランスフォーマーの出力タイプは変換の結果に応じて異なるということです。 - 変換で要素が多数生成される場合は、リストが返されます。 - 変換に応じて、そのリストの要素は文字列になるか、​`Node`​ などの汎用 Java 表現になります。 - 変換により要素が 1 つだけ生成される場合は、その要素が返されます。 Mule 4 では、常に文字列のリストが返されます。 それ以外の変更は、構文に関するもののみです。 Mule 3 の例: XQuery トランスフォーマーの使用 ```xml { for $b in $books/BOOKLIST/BOOKS/ITEM, $c in $cities/cities/city return } ]]> ``` Mule 4 の場合: Mule 4 の例: XQuery トランスフォーマーの使用 ```xml { for $b in fn:doc($books)/BOOKLIST/BOOKS/ITEM, $c in fn:doc($cities)/cities/city return } ]]> #[{'books' : vars.books, 'cities': vars.cities}] ``` ## [](#スキーマに対する-xml-の検証)スキーマに対する XML の検証 Mule 3 では、検索条件を使用してスキーマの検証が行われていました。 Mule 3 の例: Schema validation filter (スキーマ検証検索条件) ```xml ``` 検証が失敗すると、メッセージは放棄されます。 Mule 4 では、検索条件がバリデーターに置き換わりました。 Mule 4 の例: スキーマバリデーター ```xml ``` このバリデーターは、​`XML-MODULE:SCHEMA_NOT_HONOURED`​ エラーを発生させます。 ## [](#xml-module-のインストール)XML Module のインストール XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # XML Module の移行 Mule 3 にバンドルされていた XML Module が、Mule 4 で新しい XML Module に置き換わります。主な変更は次のとおりです。 - Mule 3.6 で非推奨となったコンポーネント、式、関数、エバリュエーターの削除。 - jxpath-filter - jaxen-filter - jxpath-extractor-transformer - is-xml-filter - xpath-filter - 新しい Mule 4 コンポーネントとの一貫性を保つために、主に次に関して XPath、XSLT、XQuery コンポーネントで行われた変更。 - `mxml`​ から ​`xml-module`​ に変更された DSL 名前空間プレフィックス - 戻り値の型の一貫性 - 構文と UX の変更 - `xpath()`​ 関数と ​`xpath3()`​ 関数が ​`XmlModule::xpath()`​ 関数に置き換わりました。 - スキーマ検証機能のエラーレポートが改善されました。 - `schema-validation-filter`​ が ​`schema-validator`​ に置き換わりました。 - Java との関連付けがなくなり、SAX、StaX、DOM 型は使用されなくなりました。Mule 4 では、厳密に型指定されるようになり、どのデータが XML 形式なのかについて MIME タイプの情報を把握しています。残りは Runtime によって自動的に行われます。すべての XML ドキュメントは、文字列またはストリームのいずれかとして表されます。つまり、次は存在しません (不要になりました)。 - dom-to-xml-transformer - dom-to-output-handler-transformer - xml-to-dom-transformer - xml-prettyprinter-transformer - jaxb-object-to-xml-transformer - jaxb-xml-to-object-transformer - jaxb-context - object-to-xml-transformer - xml-to-object-transformer ## [](#xslt-操作の移行)XSLT 操作の移行 ### [](#外部ファイルでの-xsl-スタイルシートの使用)外部ファイルでの XSL スタイルシートの使用 Mule 3 の例: 外部ファイルでの XSL シートの使用方法 ```xml ``` Mule 4 の場合: Mule 4 の例: 外部ファイルでの XSL シートの使用方法 ```xml ${file:::cities.xslt} ``` ### [](#コンテキストプロパティの使用)コンテキストプロパティの使用 Mule 3 の例: コンテキストプロパティの設定方法 ```xml ``` Mule 4 の例: コンテキストプロパティの設定方法 ```xml ${file::cities.xslt} #[{'output_location': vars.outputFile, 'user_id': vars.userId}] ``` ## [](#xpath-操作と式の移行)XPath 操作と式の移行 ### [](#xpath-抽出器トランスフォーマーの使用)XPath 抽出器トランスフォーマーの使用 XPath extractor (XPath エクストラクター) では、カスタム ​`resultType`​ パラメーターがサポートされなくなりました。一致するすべての要素を含む文字列のリストが常に返されるようになります。 Mule 3 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` Mule 4 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` ### [](#xpath-式関数の使用)XPath 式関数の使用 Mule 3 には元々、​`xpath()`​ MEL 関数がありました。それが Mule 3.6 で非推奨となり、新しい ​`xpath3()`​ 関数が使用されました。今回は、両方の関数が新しい ​`XmlModule::xpath()`​ DataWeave 関数に置き換わります。これは、アプリケーションにモジュールを追加すると使用可能になります。 Mule 3 の例: xpath3 関数の使用 ```xml ``` Mule 3 の ​`xpath3()`​ 関数では、XPath 式と入力値を指定でき、予期される出力では、​`BOOLEAN`​、​`STRING`​、​`NUMBER`​、​`NODESET`​、または ​`NODE`​ というさまざまなオプションが用意されていました。​`NODESET`​ と ​`NODE`​ の場合は、Java の DOM ツリー表現を理解している必要がありました。 また、新しい関数は XPath 式と入力を受け入れますが、次の点で異なります。 - カスタムコンテキストプロパティのサポートが追加される。 - 出力タイプを指定できない。​``​ と同様に、常に文字列のリストが返される。 Mule 4 の例: xpath 関数の使用 ```xml ```
この関数は、どの DataWeave 変換内でも使用できます。
### [](#カスタム名前空間を指定した-xpath-の使用)カスタム名前空間を指定した XPath の使用 Mule 3 でカスタム名前空間プレフィックスをマップするには ​``​ が必要です。 Mule 3 の例: カスタム名前空間の使用 ```xml ``` このアプローチには、アプリケーションごとに使用できる namespace-manager は 1 つだけという制限があります。Mule 4 では、必要な数だけ ​`namespace-directory`​ 要素を宣言し、各操作で必要なものを参照できます。 Mule 4 の例: カスタム名前空間の使用 ```xml ``` さらに、「namespace-directory」を宣言しないことも可能で、代わりに名前空間をインラインでマップできます。 Mule 4 の例: インラインのカスタム名前空間マッピング ```xml ``` ## [](#xquery-操作の移行)XQuery 操作の移行 主な違いは、Mule 3 ではこのトランスフォーマーの出力タイプは変換の結果に応じて異なるということです。 - 変換で要素が多数生成される場合は、リストが返されます。 - 変換に応じて、そのリストの要素は文字列になるか、​`Node`​ などの汎用 Java 表現になります。 - 変換により要素が 1 つだけ生成される場合は、その要素が返されます。 Mule 4 では、常に文字列のリストが返されます。 それ以外の変更は、構文に関するもののみです。 Mule 3 の例: XQuery トランスフォーマーの使用 ```xml { for $b in $books/BOOKLIST/BOOKS/ITEM, $c in $cities/cities/city return } ]]> ``` Mule 4 の場合: Mule 4 の例: XQuery トランスフォーマーの使用 ```xml { for $b in fn:doc($books)/BOOKLIST/BOOKS/ITEM, $c in fn:doc($cities)/cities/city return } ]]> #[{'books' : vars.books, 'cities': vars.cities}] ``` ## [](#スキーマに対する-xml-の検証)スキーマに対する XML の検証 Mule 3 では、検索条件を使用してスキーマの検証が行われていました。 Mule 3 の例: Schema validation filter (スキーマ検証検索条件) ```xml ``` 検証が失敗すると、メッセージは放棄されます。 Mule 4 では、検索条件がバリデーターに置き換わりました。 Mule 4 の例: スキーマバリデーター ```xml ``` このバリデーターは、​`XML-MODULE:SCHEMA_NOT_HONOURED`​ エラーを発生させます。 ## [](#xml-module-のインストール)XML Module のインストール XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # XML Module の移行 Mule 3 にバンドルされていた XML Module が、Mule 4 で新しい XML Module に置き換わります。主な変更は次のとおりです。 - Mule 3.6 で非推奨となったコンポーネント、式、関数、エバリュエーターの削除。 - jxpath-filter - jaxen-filter - jxpath-extractor-transformer - is-xml-filter - xpath-filter - 新しい Mule 4 コンポーネントとの一貫性を保つために、主に次に関して XPath、XSLT、XQuery コンポーネントで行われた変更。 - `mxml`​ から ​`xml-module`​ に変更された DSL 名前空間プレフィックス - 戻り値の型の一貫性 - 構文と UX の変更 - `xpath()`​ 関数と ​`xpath3()`​ 関数が ​`XmlModule::xpath()`​ 関数に置き換わりました。 - スキーマ検証機能のエラーレポートが改善されました。 - `schema-validation-filter`​ が ​`schema-validator`​ に置き換わりました。 - Java との関連付けがなくなり、SAX、StaX、DOM 型は使用されなくなりました。Mule 4 では、厳密に型指定されるようになり、どのデータが XML 形式なのかについて MIME タイプの情報を把握しています。残りは Runtime によって自動的に行われます。すべての XML ドキュメントは、文字列またはストリームのいずれかとして表されます。つまり、次は存在しません (不要になりました)。 - dom-to-xml-transformer - dom-to-output-handler-transformer - xml-to-dom-transformer - xml-prettyprinter-transformer - jaxb-object-to-xml-transformer - jaxb-xml-to-object-transformer - jaxb-context - object-to-xml-transformer - xml-to-object-transformer ## [](#xslt-操作の移行)XSLT 操作の移行 ### [](#外部ファイルでの-xsl-スタイルシートの使用)外部ファイルでの XSL スタイルシートの使用 Mule 3 の例: 外部ファイルでの XSL シートの使用方法 ```xml ``` Mule 4 の場合: Mule 4 の例: 外部ファイルでの XSL シートの使用方法 ```xml ${file:::cities.xslt} ``` ### [](#コンテキストプロパティの使用)コンテキストプロパティの使用 Mule 3 の例: コンテキストプロパティの設定方法 ```xml ``` Mule 4 の例: コンテキストプロパティの設定方法 ```xml ${file::cities.xslt} #[{'output_location': vars.outputFile, 'user_id': vars.userId}] ``` ## [](#xpath-操作と式の移行)XPath 操作と式の移行 ### [](#xpath-抽出器トランスフォーマーの使用)XPath 抽出器トランスフォーマーの使用 XPath extractor (XPath エクストラクター) では、カスタム ​`resultType`​ パラメーターがサポートされなくなりました。一致するすべての要素を含む文字列のリストが常に返されるようになります。 Mule 3 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` Mule 4 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` ### [](#xpath-式関数の使用)XPath 式関数の使用 Mule 3 には元々、​`xpath()`​ MEL 関数がありました。それが Mule 3.6 で非推奨となり、新しい ​`xpath3()`​ 関数が使用されました。今回は、両方の関数が新しい ​`XmlModule::xpath()`​ DataWeave 関数に置き換わります。これは、アプリケーションにモジュールを追加すると使用可能になります。 Mule 3 の例: xpath3 関数の使用 ```xml ``` Mule 3 の ​`xpath3()`​ 関数では、XPath 式と入力値を指定でき、予期される出力では、​`BOOLEAN`​、​`STRING`​、​`NUMBER`​、​`NODESET`​、または ​`NODE`​ というさまざまなオプションが用意されていました。​`NODESET`​ と ​`NODE`​ の場合は、Java の DOM ツリー表現を理解している必要がありました。 また、新しい関数は XPath 式と入力を受け入れますが、次の点で異なります。 - カスタムコンテキストプロパティのサポートが追加される。 - 出力タイプを指定できない。​``​ と同様に、常に文字列のリストが返される。 Mule 4 の例: xpath 関数の使用 ```xml ```
この関数は、どの DataWeave 変換内でも使用できます。
### [](#カスタム名前空間を指定した-xpath-の使用)カスタム名前空間を指定した XPath の使用 Mule 3 でカスタム名前空間プレフィックスをマップするには ​``​ が必要です。 Mule 3 の例: カスタム名前空間の使用 ```xml ``` このアプローチには、アプリケーションごとに使用できる namespace-manager は 1 つだけという制限があります。Mule 4 では、必要な数だけ ​`namespace-directory`​ 要素を宣言し、各操作で必要なものを参照できます。 Mule 4 の例: カスタム名前空間の使用 ```xml ``` さらに、「namespace-directory」を宣言しないことも可能で、代わりに名前空間をインラインでマップできます。 Mule 4 の例: インラインのカスタム名前空間マッピング ```xml ``` ## [](#xquery-操作の移行)XQuery 操作の移行 主な違いは、Mule 3 ではこのトランスフォーマーの出力タイプは変換の結果に応じて異なるということです。 - 変換で要素が多数生成される場合は、リストが返されます。 - 変換に応じて、そのリストの要素は文字列になるか、​`Node`​ などの汎用 Java 表現になります。 - 変換により要素が 1 つだけ生成される場合は、その要素が返されます。 Mule 4 では、常に文字列のリストが返されます。 それ以外の変更は、構文に関するもののみです。 Mule 3 の例: XQuery トランスフォーマーの使用 ```xml { for $b in $books/BOOKLIST/BOOKS/ITEM, $c in $cities/cities/city return } ]]> ``` Mule 4 の場合: Mule 4 の例: XQuery トランスフォーマーの使用 ```xml { for $b in fn:doc($books)/BOOKLIST/BOOKS/ITEM, $c in fn:doc($cities)/cities/city return } ]]> #[{'books' : vars.books, 'cities': vars.cities}] ``` ## [](#スキーマに対する-xml-の検証)スキーマに対する XML の検証 Mule 3 では、検索条件を使用してスキーマの検証が行われていました。 Mule 3 の例: Schema validation filter (スキーマ検証検索条件) ```xml ``` 検証が失敗すると、メッセージは放棄されます。 Mule 4 では、検索条件がバリデーターに置き換わりました。 Mule 4 の例: スキーマバリデーター ```xml ``` このバリデーターは、​`XML-MODULE:SCHEMA_NOT_HONOURED`​ エラーを発生させます。 ## [](#xml-module-のインストール)XML Module のインストール XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # XML Module の移行 Mule 3 にバンドルされていた XML Module が、Mule 4 で新しい XML Module に置き換わります。主な変更は次のとおりです。 - Mule 3.6 で非推奨となったコンポーネント、式、関数、エバリュエーターの削除。 - jxpath-filter - jaxen-filter - jxpath-extractor-transformer - is-xml-filter - xpath-filter - 新しい Mule 4 コンポーネントとの一貫性を保つために、主に次に関して XPath、XSLT、XQuery コンポーネントで行われた変更。 - `mxml`​ から ​`xml-module`​ に変更された DSL 名前空間プレフィックス - 戻り値の型の一貫性 - 構文と UX の変更 - `xpath()`​ 関数と ​`xpath3()`​ 関数が ​`XmlModule::xpath()`​ 関数に置き換わりました。 - スキーマ検証機能のエラーレポートが改善されました。 - `schema-validation-filter`​ が ​`schema-validator`​ に置き換わりました。 - Java との関連付けがなくなり、SAX、StaX、DOM 型は使用されなくなりました。Mule 4 では、厳密に型指定されるようになり、どのデータが XML 形式なのかについて MIME タイプの情報を把握しています。残りは Runtime によって自動的に行われます。すべての XML ドキュメントは、文字列またはストリームのいずれかとして表されます。つまり、次は存在しません (不要になりました)。 - dom-to-xml-transformer - dom-to-output-handler-transformer - xml-to-dom-transformer - xml-prettyprinter-transformer - jaxb-object-to-xml-transformer - jaxb-xml-to-object-transformer - jaxb-context - object-to-xml-transformer - xml-to-object-transformer ## [](#xslt-操作の移行)XSLT 操作の移行 ### [](#外部ファイルでの-xsl-スタイルシートの使用)外部ファイルでの XSL スタイルシートの使用 Mule 3 の例: 外部ファイルでの XSL シートの使用方法 ```xml ``` Mule 4 の場合: Mule 4 の例: 外部ファイルでの XSL シートの使用方法 ```xml ${file:::cities.xslt} ``` ### [](#コンテキストプロパティの使用)コンテキストプロパティの使用 Mule 3 の例: コンテキストプロパティの設定方法 ```xml ``` Mule 4 の例: コンテキストプロパティの設定方法 ```xml ${file::cities.xslt} #[{'output_location': vars.outputFile, 'user_id': vars.userId}] ``` ## [](#xpath-操作と式の移行)XPath 操作と式の移行 ### [](#xpath-抽出器トランスフォーマーの使用)XPath 抽出器トランスフォーマーの使用 XPath extractor (XPath エクストラクター) では、カスタム ​`resultType`​ パラメーターがサポートされなくなりました。一致するすべての要素を含む文字列のリストが常に返されるようになります。 Mule 3 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` Mule 4 の例: XPath extractor (Xpath エクストラクター) の使用方法 ```xml ``` ### [](#xpath-式関数の使用)XPath 式関数の使用 Mule 3 には元々、​`xpath()`​ MEL 関数がありました。それが Mule 3.6 で非推奨となり、新しい ​`xpath3()`​ 関数が使用されました。今回は、両方の関数が新しい ​`XmlModule::xpath()`​ DataWeave 関数に置き換わります。これは、アプリケーションにモジュールを追加すると使用可能になります。 Mule 3 の例: xpath3 関数の使用 ```xml ``` Mule 3 の ​`xpath3()`​ 関数では、XPath 式と入力値を指定でき、予期される出力では、​`BOOLEAN`​、​`STRING`​、​`NUMBER`​、​`NODESET`​、または ​`NODE`​ というさまざまなオプションが用意されていました。​`NODESET`​ と ​`NODE`​ の場合は、Java の DOM ツリー表現を理解している必要がありました。 また、新しい関数は XPath 式と入力を受け入れますが、次の点で異なります。 - カスタムコンテキストプロパティのサポートが追加される。 - 出力タイプを指定できない。​``​ と同様に、常に文字列のリストが返される。 Mule 4 の例: xpath 関数の使用 ```xml ```
この関数は、どの DataWeave 変換内でも使用できます。
### [](#カスタム名前空間を指定した-xpath-の使用)カスタム名前空間を指定した XPath の使用 Mule 3 でカスタム名前空間プレフィックスをマップするには ​``​ が必要です。 Mule 3 の例: カスタム名前空間の使用 ```xml ``` このアプローチには、アプリケーションごとに使用できる namespace-manager は 1 つだけという制限があります。Mule 4 では、必要な数だけ ​`namespace-directory`​ 要素を宣言し、各操作で必要なものを参照できます。 Mule 4 の例: カスタム名前空間の使用 ```xml ``` さらに、「namespace-directory」を宣言しないことも可能で、代わりに名前空間をインラインでマップできます。 Mule 4 の例: インラインのカスタム名前空間マッピング ```xml ``` ## [](#xquery-操作の移行)XQuery 操作の移行 主な違いは、Mule 3 ではこのトランスフォーマーの出力タイプは変換の結果に応じて異なるということです。 - 変換で要素が多数生成される場合は、リストが返されます。 - 変換に応じて、そのリストの要素は文字列になるか、​`Node`​ などの汎用 Java 表現になります。 - 変換により要素が 1 つだけ生成される場合は、その要素が返されます。 Mule 4 では、常に文字列のリストが返されます。 それ以外の変更は、構文に関するもののみです。 Mule 3 の例: XQuery トランスフォーマーの使用 ```xml { for $b in $books/BOOKLIST/BOOKS/ITEM, $c in $cities/cities/city return } ]]> ``` Mule 4 の場合: Mule 4 の例: XQuery トランスフォーマーの使用 ```xml { for $b in fn:doc($books)/BOOKLIST/BOOKS/ITEM, $c in fn:doc($cities)/cities/city return } ]]> #[{'books' : vars.books, 'cities': vars.cities}] ``` ## [](#スキーマに対する-xml-の検証)スキーマに対する XML の検証 Mule 3 では、検索条件を使用してスキーマの検証が行われていました。 Mule 3 の例: Schema validation filter (スキーマ検証検索条件) ```xml ``` 検証が失敗すると、メッセージは放棄されます。 Mule 4 では、検索条件がバリデーターに置き換わりました。 Mule 4 の例: スキーマバリデーター ```xml ``` このバリデーターは、​`XML-MODULE:SCHEMA_NOT_HONOURED`​ エラーを発生させます。 ## [](#xml-module-のインストール)XML Module のインストール XML Module を使用するには、Studio のパレットを使用してアプリケーションに追加するか、​`pom.xml`​ ファイルで次の連動関係を追加します。 ```xml org.mule.modules mule-xml-module 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [XML Module](https://docs.mulesoft.com/jp/xml-module/latest/) # アプリケーションの共有 チームで作業をしていると、Mule Runtime Engine プロジェクトの規模が拡大し、コラボレーションを行う必要がある開発者の人数が増加して、テスト環境と本番環境の両方でプロジェクトを実行する必要が生じます。ただし、アプリケーションを共有することでこうしたプロジェクト拡大のペースを落とすことができます。 チームが同じ包括的なプロジェクトに取り組んでいるか、再利用を意図した異なるプロジェクトに取り組んでいるかに関係なく、アプリケーションの共有は、チーム間で作業を分割する機会となります。 アプリケーションは内蔵型のアーカイブに保存されるため、単純なファイルや Web サーバーを使用して共有できます。 アプリケーションを共有するには、次の手順に従います。 1. 各アプリケーションで使用すると予想されるプロパティファイルの名前とコンテンツを文書化します。 Mule アプリケーションをデプロイして実行するシステム管理者は、​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/secure-configuration-properties)​で説明しているように、プロパティファイルを暗号化できます。システム管理者は、プロパティファイルの復号化キーをセキュアに保つ必要があります。 1. 次の 2 つの方法のいずれかで、アプリケーションを共有するために使用するファイルを生成します。 - Anypoint Studio からアプリケーションをエクスポートして、デプロイ可能なアーカイブ ​`.jar`​ ファイルを生成する。 - Mule Maven プラグインを使用してアプリケーションを次の 3 つのいずれかの種別の ​`.jar`​ ファイルにパッケージ化する。 - 実行中の Mule Runtime Engine にデプロイするデプロイ可能なアーカイブ ​`.jar`​ ファイル。 - Studio にインポートする Mule アプリケーションパッケージ ​`.jar`​ ファイル。 - 後で Studio にインポートする Mule アプリケーション軽量パッケージ ​`.jar`​ ファイル。 1. 必要に応じて、​`.jar`​ ファイルを他の開発者と共有します。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule アプリケーションのパッケージ](https://docs.mulesoft.com/jp/mule-runtime/4.3/package-a-mule-application) # アプリケーションの共有 チームで作業をしていると、Mule Runtime Engine プロジェクトの規模が拡大し、コラボレーションを行う必要がある開発者の人数が増加して、テスト環境と本番環境の両方でプロジェクトを実行する必要が生じます。ただし、アプリケーションを共有することでこうしたプロジェクト拡大のペースを落とすことができます。 チームが同じ包括的なプロジェクトに取り組んでいるか、再利用を意図した異なるプロジェクトに取り組んでいるかに関係なく、アプリケーションの共有は、チーム間で作業を分割する機会となります。 アプリケーションは内蔵型のアーカイブに保存されるため、単純なファイルや Web サーバーを使用して共有できます。 アプリケーションを共有するには、次の手順に従います。 1. 各アプリケーションで使用すると予想されるプロパティファイルの名前とコンテンツを文書化します。 Mule アプリケーションをデプロイして実行するシステム管理者は、​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/secure-configuration-properties)​で説明しているように、プロパティファイルを暗号化できます。システム管理者は、プロパティファイルの復号化キーをセキュアに保つ必要があります。 1. 次の 2 つの方法のいずれかで、アプリケーションを共有するために使用するファイルを生成します。 - Anypoint Studio からアプリケーションをエクスポートして、デプロイ可能なアーカイブ ​`.jar`​ ファイルを生成する。 - Mule Maven プラグインを使用してアプリケーションを次の 3 つのいずれかの種別の ​`.jar`​ ファイルにパッケージ化する。 - 実行中の Mule Runtime Engine にデプロイするデプロイ可能なアーカイブ ​`.jar`​ ファイル。 - Studio にインポートする Mule アプリケーションパッケージ ​`.jar`​ ファイル。 - 後で Studio にインポートする Mule アプリケーション軽量パッケージ ​`.jar`​ ファイル。 1. 必要に応じて、​`.jar`​ ファイルを他の開発者と共有します。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule アプリケーションのパッケージ](https://docs.mulesoft.com/jp/mule-runtime/4.4/package-a-mule-application) # アプリケーションの共有 チームで作業をしていると、Mule Runtime Engine プロジェクトの規模が拡大し、コラボレーションを行う必要がある開発者の人数が増加して、テスト環境と本番環境の両方でプロジェクトを実行する必要が生じます。ただし、アプリケーションを共有することでこうしたプロジェクト拡大のペースを落とすことができます。 チームが同じ包括的なプロジェクトに取り組んでいるか、再利用を意図した異なるプロジェクトに取り組んでいるかに関係なく、アプリケーションの共有は、チーム間で作業を分割する機会となります。 アプリケーションは内蔵型のアーカイブに保存されるため、単純なファイルや Web サーバーを使用して共有できます。 アプリケーションを共有するには、次の手順に従います。 1. 各アプリケーションで使用すると予想されるプロパティファイルの名前とコンテンツを文書化します。 Mule アプリケーションをデプロイして実行するシステム管理者は、​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/secure-configuration-properties)​で説明しているように、プロパティファイルを暗号化できます。システム管理者は、プロパティファイルの復号化キーをセキュアに保つ必要があります。 1. 次の 2 つの方法のいずれかで、アプリケーションを共有するために使用するファイルを生成します。 - Anypoint Studio からアプリケーションをエクスポートして、デプロイ可能なアーカイブ ​`.jar`​ ファイルを生成する。 - Mule Maven プラグインを使用してアプリケーションを次の 3 つのいずれかの種別の ​`.jar`​ ファイルにパッケージ化する。 - 実行中の Mule Runtime Engine にデプロイするデプロイ可能なアーカイブ ​`.jar`​ ファイル。 - Studio にインポートする Mule アプリケーションパッケージ ​`.jar`​ ファイル。 - 後で Studio にインポートする Mule アプリケーション軽量パッケージ ​`.jar`​ ファイル。 1. 必要に応じて、​`.jar`​ ファイルを他の開発者と共有します。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule アプリケーションのパッケージ](https://docs.mulesoft.com/jp/mule-runtime/4.5/package-a-mule-application) # アプリケーションの共有 チームで作業をしていると、Mule Runtime Engine プロジェクトの規模が拡大し、コラボレーションを行う必要がある開発者の人数が増加して、テスト環境と本番環境の両方でプロジェクトを実行する必要が生じます。ただし、アプリケーションを共有することでこうしたプロジェクト拡大のペースを落とすことができます。 チームが同じ包括的なプロジェクトに取り組んでいるか、再利用を意図した異なるプロジェクトに取り組んでいるかに関係なく、アプリケーションの共有は、チーム間で作業を分割する機会となります。 アプリケーションは内蔵型のアーカイブに保存されるため、単純なファイルや Web サーバーを使用して共有できます。 アプリケーションを共有するには、次の手順に従います。 1. 各アプリケーションで使用すると予想されるプロパティファイルの名前とコンテンツを文書化します。 Mule アプリケーションをデプロイして実行するシステム管理者は、​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/secure-configuration-properties)​で説明しているように、プロパティファイルを暗号化できます。システム管理者は、プロパティファイルの復号化キーをセキュアに保つ必要があります。 1. 次の 2 つの方法のいずれかで、アプリケーションを共有するために使用するファイルを生成します。 - Anypoint Studio からアプリケーションをエクスポートして、デプロイ可能なアーカイブ ​`.jar`​ ファイルを生成する。 - Mule Maven プラグインを使用してアプリケーションを次の 3 つのいずれかの種別の ​`.jar`​ ファイルにパッケージ化する。 - 実行中の Mule Runtime Engine にデプロイするデプロイ可能なアーカイブ ​`.jar`​ ファイル。 - Studio にインポートする Mule アプリケーションパッケージ ​`.jar`​ ファイル。 - 後で Studio にインポートする Mule アプリケーション軽量パッケージ ​`.jar`​ ファイル。 1. 必要に応じて、​`.jar`​ ファイルを他の開発者と共有します。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule アプリケーションのパッケージ](https://docs.mulesoft.com/jp/mule-runtime/4.6/package-a-mule-application) # アプリケーションの共有 チームで作業をしていると、Mule Runtime Engine プロジェクトの規模が拡大し、コラボレーションを行う必要がある開発者の人数が増加して、テスト環境と本番環境の両方でプロジェクトを実行する必要が生じます。ただし、アプリケーションを共有することでこうしたプロジェクト拡大のペースを落とすことができます。 チームが同じ包括的なプロジェクトに取り組んでいるか、再利用を意図した異なるプロジェクトに取り組んでいるかに関係なく、アプリケーションの共有は、チーム間で作業を分割する機会となります。 アプリケーションは内蔵型のアーカイブに保存されるため、単純なファイルや Web サーバーを使用して共有できます。 アプリケーションを共有するには、次の手順に従います。 1. 各アプリケーションで使用すると予想されるプロパティファイルの名前とコンテンツを文書化します。 Mule アプリケーションをデプロイして実行するシステム管理者は、​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/secure-configuration-properties)​で説明しているように、プロパティファイルを暗号化できます。システム管理者は、プロパティファイルの復号化キーをセキュアに保つ必要があります。 1. 次の 2 つの方法のいずれかで、アプリケーションを共有するために使用するファイルを生成します。 - Anypoint Studio からアプリケーションをエクスポートして、デプロイ可能なアーカイブ ​`.jar`​ ファイルを生成する。 - Mule Maven プラグインを使用してアプリケーションを次の 3 つのいずれかの種別の ​`.jar`​ ファイルにパッケージ化する。 - 実行中の Mule Runtime Engine にデプロイするデプロイ可能なアーカイブ ​`.jar`​ ファイル。 - Studio にインポートする Mule アプリケーションパッケージ ​`.jar`​ ファイル。 - 後で Studio にインポートする Mule アプリケーション軽量パッケージ ​`.jar`​ ファイル。 1. 必要に応じて、​`.jar`​ ファイルを他の開発者と共有します。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule アプリケーションのパッケージ](https://docs.mulesoft.com/jp/mule-runtime/4.7/package-a-mule-application) # アプリケーションの共有 チームで作業をしていると、Mule Runtime Engine プロジェクトの規模が拡大し、コラボレーションを行う必要がある開発者の人数が増加して、テスト環境と本番環境の両方でプロジェクトを実行する必要が生じます。ただし、アプリケーションを共有することでこうしたプロジェクト拡大のペースを落とすことができます。 チームが同じ包括的なプロジェクトに取り組んでいるか、再利用を意図した異なるプロジェクトに取り組んでいるかに関係なく、アプリケーションの共有は、チーム間で作業を分割する機会となります。 アプリケーションは内蔵型のアーカイブに保存されるため、単純なファイルや Web サーバーを使用して共有できます。 アプリケーションを共有するには、次の手順に従います。 1. 各アプリケーションで使用すると予想されるプロパティファイルの名前とコンテンツを文書化します。 Mule アプリケーションをデプロイして実行するシステム管理者は、​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/secure-configuration-properties)​で説明しているように、プロパティファイルを暗号化できます。システム管理者は、プロパティファイルの復号化キーをセキュアに保つ必要があります。 1. 次の 2 つの方法のいずれかで、アプリケーションを共有するために使用するファイルを生成します。 - Anypoint Studio からアプリケーションをエクスポートして、デプロイ可能なアーカイブ ​`.jar`​ ファイルを生成する。 - Mule Maven プラグインを使用してアプリケーションを次の 3 つのいずれかの種別の ​`.jar`​ ファイルにパッケージ化する。 - 実行中の Mule Runtime Engine にデプロイするデプロイ可能なアーカイブ ​`.jar`​ ファイル。 - Studio にインポートする Mule アプリケーションパッケージ ​`.jar`​ ファイル。 - 後で Studio にインポートする Mule アプリケーション軽量パッケージ ​`.jar`​ ファイル。 1. 必要に応じて、​`.jar`​ ファイルを他の開発者と共有します。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule アプリケーションのパッケージ](https://docs.mulesoft.com/jp/mule-runtime/4.8/package-a-mule-application) # アプリケーションの共有 チームで作業をしていると、Mule Runtime Engine プロジェクトの規模が拡大し、コラボレーションを行う必要がある開発者の人数が増加して、テスト環境と本番環境の両方でプロジェクトを実行する必要が生じます。ただし、アプリケーションを共有することでこうしたプロジェクト拡大のペースを落とすことができます。 チームが同じ包括的なプロジェクトに取り組んでいるか、再利用を意図した異なるプロジェクトに取り組んでいるかに関係なく、アプリケーションの共有は、チーム間で作業を分割する機会となります。 アプリケーションは内蔵型のアーカイブに保存されるため、単純なファイルや Web サーバーを使用して共有できます。 アプリケーションを共有するには、次の手順に従います。 1. 各アプリケーションで使用すると予想されるプロパティファイルの名前とコンテンツを文書化します。 Mule アプリケーションをデプロイして実行するシステム管理者は、​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/secure-configuration-properties)​で説明しているように、プロパティファイルを暗号化できます。システム管理者は、プロパティファイルの復号化キーをセキュアに保つ必要があります。 1. 次の 2 つの方法のいずれかで、アプリケーションを共有するために使用するファイルを生成します。 - Anypoint Studio からアプリケーションをエクスポートして、デプロイ可能なアーカイブ ​`.jar`​ ファイルを生成する。 - Mule Maven プラグインを使用してアプリケーションを次の 3 つのいずれかの種別の ​`.jar`​ ファイルにパッケージ化する。 - 実行中の Mule Runtime Engine にデプロイするデプロイ可能なアーカイブ ​`.jar`​ ファイル。 - Studio にインポートする Mule アプリケーションパッケージ ​`.jar`​ ファイル。 - 後で Studio にインポートする Mule アプリケーション軽量パッケージ ​`.jar`​ ファイル。 1. 必要に応じて、​`.jar`​ ファイルを他の開発者と共有します。 ## [](#関連情報)関連情報 - [Studio からのプロジェクトのエクスポート](https://docs.mulesoft.com/studio/import-export-packages#export-project-studio) - [Mule アプリケーションのパッケージ](https://docs.mulesoft.com/jp/mule-runtime/4.9/package-a-mule-application) # ウォーターマークの移行 ウォーターマークは通常、たとえばレガシーリソースをポーリングして新しいデータを取得し、別の宛先エンドポイントと同期するときなど、データ同期を実行するために使用されます。ウォーターマークの技法により、定期的な同期が次に実行されるときに再開する時点を保存して取得します。ウォーターマークは通常、ObjectStore と一緒に使用されます。 Mule 3 アプローチについては、次の MuleSoft ブログを参照してください: [「Data Synchronizing made easy with Watermarks (ウォーターマークでデータ同期が簡単になる)」](https://blogs.mulesoft.com/dev/anypoint-platform-dev/data-synchronizing-made-easy-with-mule-watermarks/)​。 ここで、そのブログから引用した Mule 3 のウォーターマークの例を紹介します。 Mule 3 の例: ウォーターマークを使用した Salesforce 取引先責任者のポーリング ```xml ``` Anypoint Platform が拡張され、ユースケースが複雑になるに従って、Mule 3 アプローチでの制限が明らかになり始めました。 - 以前の ​``​ コンポーネントではカスタム ObjectStore の設定が可能でしたが、作成するのは簡単ではありませんでした。この問題についてはこのドキュメントですでに説明済みであり、新しい ObjectStore Connector では修正されます。 - ``​ 要素では、​``​ コンポーネント (現在は ​``​ に置換) が反復可能なペイロードを返す必要がありました。さらに、新しいウォーターマーク値を取得するには、そのペイロードを最後まで反復処理する必要がありました。その処理に失敗すると、値が不正確に更新されるか、一切更新されませんでした。 - フローでエラーがスローされた場合、コンテンジェンシー値でウォーターマークを更新する方法はありませんでした。 - いつどのように値が更新されるか、エキスパート以外のユーザーにはよくわかりませんでした。 このユースケースをどうすれば改善できるか検討しているとき、問題の本当の根本は、実際には はまったく不要であることだと気付きました。これは単に、他のコンポーネントの制限事項の影響で存在していたのです。 - ウォーターマークの人為的な反復は、多くのデータセットが 1 回しか反復できないという事実を補う方法でしかありませんでした。特に、バイナリストリームを処理する場合や、コネクタで自動ページ設定を行う場合がこれに当てはまります。Mule 4 では、この問題は反復可能なストリーミング機能によって修正されました。 - コンポーネントによる ObjectStore の自動処理は、古い ObjectStore サポートの UX の問題を埋め合わせるためだけのものでした。新しいコネクタでより簡単なセマンティクスを提供できれば、まったく必要がなくなります。 Mule 4 では、次のように上記の Mule 3 ブログ記事で説明しているユースケースを実行できます。 ```xml 2017-09-11T00:00:00.000Z " ++ vars.watermark] ]]> #[max(payload map $.LastModifiedDate)] ``` この例をステップごとに説明していきましょう。 - まず、このフローは汎用です。特定の方法でトリガーする必要はありません。別のフローから呼び出しても、​``​ を追加しても構いません。何らかの種別のトリガーを強制しなくても、ウォーターマークのセマンティクスを実現できるようになりました。 - この設定では、最初にウォーターマークのカスタム ObjectStore を定義しています。これは必須ではありません。ObjectStore を定義できず、単にすべてのアプリケーションで暗黙的な ObjectStore を使用する場合もあります。しかし、ここでは例として、独自の ObjectStore を使用します。 - このフローは、最後のウォーターマーク値を取得するための retrieve 操作で開始します。以下の点に注意してください。 - retrieve 操作ではデフォルト値が指定されます。これは、フローが最初に実行されるときにウォーターマークがまだ計算されていなくても、使用可能な値を取得できるようにするためです。これにより、​``​ → ​``​ のようなパターンが必要にならないようにしています。 - Target (対象) (​`target`​) パラメーターは、コネクタにメッセージペイロードをウォーターマークで上書きするのではなく、代わりに変数に配置するように指示するために使用されます。これはメッセージに悪影響を及ぼさないため、フローは再利用可能になり、保守するのが容易になります。これは、retrieve 操作の前に任意の種類の操作を追加でき、中断が起こらないためです。 - 次に、クエリを実行し、そのクエリでウォーターマークを使用して取得した結果を絞り込みます。 - 続いて、必要な処理をすべて実行します。こうした処理として、別のシステムに送信しても、変換しても構いません。 - 最後に、ウォーターマーク値を更新します。このステップに関しても重要な点がいくつもあります。 - 新しいウォーターマーク値は、最大の更新タイムスタンプにする必要があります。その値を取得するために DataWeave 式を使用します。 - 反復可能なストリーミング機能によって、インテグレーションロジックがどのようなものだったかを意識する必要がなくなりました。クエリ操作で自動ページ設定されるとしても (実際に自動ページ設定されます!)、この機能で結果セットを再度反復できることが保証されます。 - `failIfPresent`​ パラメーターが false に設定されます。そうしないと、操作は初回のみ機能し、ウォーターマークがすでにオブジェクトストアにある場合は失敗します。false に設定することで、値が存在すれば更新されるようになります。 - そして最後に、​`failOnNullValue`​ パラメーターが false に設定されました。なぜでしょうか? これは、クエリの結果が空の場合、値がないため、最大値を見つける DW 式が null を返すからです。これを true に設定すると、コネクタは自動的に null 値をスキップするため、ユーザーは ​``​ ルーターを使用して状況を確認する必要がなくなります。 ## [](#自動ウォーターマーク)自動ウォーターマーク 上記の機能は優れており、Mule 3 にあった機能よりも強力ですが、さらにシンプルな機能にしたいと考えました。そのため一部のコネクタには、上記のステップを一切実行しなくても、自動的にウォーターマークを行うことができるメッセージソースがすでに含まれています。このドキュメントを執筆している時点で、ファイル、Ftp、Sftp、データベース、Salesforce の各コネクタにはこの機能がありますが、引き続き他のコネクタにもこの機能のサポートを追加していく予定です。 File Connector を使用して、この機能の仕組みの例を確認してみましょう。 Mule 4 の例: File Connector の自動ウォーターマーク ```xml ``` この例では、作成時刻を検索条件として使用し、自動ウォーターマークを実現しています。​`watermarkMode`​ パラメーターは、代わりに変更されたファイルをリスンする場合には ​`MODIFIED_TIMESTAMP`​ に設定でき、ウォーターマークがまったく必要ない場合は ​`DISABLED`​ に設定することもできます。 最初の例で説明している「手間のかかる方法」を利用することをお勧めするのは、以下の場合のみです。 - ユースケースが極めてカスタムな場合。 - 自動ウォーターマークをサポートしていないコネクタを使用している場合。 それ以外の場合は、こうしたユースケースに対処する最適な方法として自動ウォーターマークをお勧めします。 ## [](#関連情報)関連情報 - [Object Store Connector ドキュメント](https://docs.mulesoft.com/object-store-connector/latest/) # ウォーターマークの移行 ウォーターマークは通常、たとえばレガシーリソースをポーリングして新しいデータを取得し、別の宛先エンドポイントと同期するときなど、データ同期を実行するために使用されます。ウォーターマークの技法により、定期的な同期が次に実行されるときに再開する時点を保存して取得します。ウォーターマークは通常、ObjectStore と一緒に使用されます。 Mule 3 アプローチについては、次の MuleSoft ブログを参照してください: [「Data Synchronizing made easy with Watermarks (ウォーターマークでデータ同期が簡単になる)」](https://blogs.mulesoft.com/dev/anypoint-platform-dev/data-synchronizing-made-easy-with-mule-watermarks/)​。 ここで、そのブログから引用した Mule 3 のウォーターマークの例を紹介します。 Mule 3 の例: ウォーターマークを使用した Salesforce 取引先責任者のポーリング ```xml ``` Anypoint Platform が拡張され、ユースケースが複雑になるに従って、Mule 3 アプローチでの制限が明らかになり始めました。 - 以前の ​``​ コンポーネントではカスタム ObjectStore の設定が可能でしたが、作成するのは簡単ではありませんでした。この問題についてはこのドキュメントですでに説明済みであり、新しい ObjectStore Connector では修正されます。 - ``​ 要素では、​``​ コンポーネント (現在は ​``​ に置換) が反復可能なペイロードを返す必要がありました。さらに、新しいウォーターマーク値を取得するには、そのペイロードを最後まで反復処理する必要がありました。その処理に失敗すると、値が不正確に更新されるか、一切更新されませんでした。 - フローでエラーがスローされた場合、コンテンジェンシー値でウォーターマークを更新する方法はありませんでした。 - いつどのように値が更新されるか、エキスパート以外のユーザーにはよくわかりませんでした。 このユースケースをどうすれば改善できるか検討しているとき、問題の本当の根本は、実際には はまったく不要であることだと気付きました。これは単に、他のコンポーネントの制限事項の影響で存在していたのです。 - ウォーターマークの人為的な反復は、多くのデータセットが 1 回しか反復できないという事実を補う方法でしかありませんでした。特に、バイナリストリームを処理する場合や、コネクタで自動ページ設定を行う場合がこれに当てはまります。Mule 4 では、この問題は反復可能なストリーミング機能によって修正されました。 - コンポーネントによる ObjectStore の自動処理は、古い ObjectStore サポートの UX の問題を埋め合わせるためだけのものでした。新しいコネクタでより簡単なセマンティクスを提供できれば、まったく必要がなくなります。 Mule 4 では、次のように上記の Mule 3 ブログ記事で説明しているユースケースを実行できます。 ```xml 2017-09-11T00:00:00.000Z " ++ vars.watermark] ]]> #[max(payload map $.LastModifiedDate)] ``` この例をステップごとに説明していきましょう。 - まず、このフローは汎用です。特定の方法でトリガーする必要はありません。別のフローから呼び出しても、​``​ を追加しても構いません。何らかの種別のトリガーを強制しなくても、ウォーターマークのセマンティクスを実現できるようになりました。 - この設定では、最初にウォーターマークのカスタム ObjectStore を定義しています。これは必須ではありません。ObjectStore を定義できず、単にすべてのアプリケーションで暗黙的な ObjectStore を使用する場合もあります。しかし、ここでは例として、独自の ObjectStore を使用します。 - このフローは、最後のウォーターマーク値を取得するための retrieve 操作で開始します。以下の点に注意してください。 - retrieve 操作ではデフォルト値が指定されます。これは、フローが最初に実行されるときにウォーターマークがまだ計算されていなくても、使用可能な値を取得できるようにするためです。これにより、​``​ → ​``​ のようなパターンが必要にならないようにしています。 - Target (対象) (​`target`​) パラメーターは、コネクタにメッセージペイロードをウォーターマークで上書きするのではなく、代わりに変数に配置するように指示するために使用されます。これはメッセージに悪影響を及ぼさないため、フローは再利用可能になり、保守するのが容易になります。これは、retrieve 操作の前に任意の種類の操作を追加でき、中断が起こらないためです。 - 次に、クエリを実行し、そのクエリでウォーターマークを使用して取得した結果を絞り込みます。 - 続いて、必要な処理をすべて実行します。こうした処理として、別のシステムに送信しても、変換しても構いません。 - 最後に、ウォーターマーク値を更新します。このステップに関しても重要な点がいくつもあります。 - 新しいウォーターマーク値は、最大の更新タイムスタンプにする必要があります。その値を取得するために DataWeave 式を使用します。 - 反復可能なストリーミング機能によって、インテグレーションロジックがどのようなものだったかを意識する必要がなくなりました。クエリ操作で自動ページ設定されるとしても (実際に自動ページ設定されます!)、この機能で結果セットを再度反復できることが保証されます。 - `failIfPresent`​ パラメーターが false に設定されます。そうしないと、操作は初回のみ機能し、ウォーターマークがすでにオブジェクトストアにある場合は失敗します。false に設定することで、値が存在すれば更新されるようになります。 - そして最後に、​`failOnNullValue`​ パラメーターが false に設定されました。なぜでしょうか? これは、クエリの結果が空の場合、値がないため、最大値を見つける DW 式が null を返すからです。これを true に設定すると、コネクタは自動的に null 値をスキップするため、ユーザーは ​``​ ルーターを使用して状況を確認する必要がなくなります。 ## [](#自動ウォーターマーク)自動ウォーターマーク 上記の機能は優れており、Mule 3 にあった機能よりも強力ですが、さらにシンプルな機能にしたいと考えました。そのため一部のコネクタには、上記のステップを一切実行しなくても、自動的にウォーターマークを行うことができるイベントソースがすでに含まれています。このドキュメントを執筆している時点で、ファイル、Ftp、Sftp、データベース、Salesforce の各コネクタにはこの機能がありますが、引き続き他のコネクタにもこの機能のサポートを追加していく予定です。 File Connector を使用して、この機能の仕組みの例を確認してみましょう。 Mule 4 の例: File Connector の自動ウォーターマーク ```xml ``` この例では、作成時刻を検索条件として使用し、自動ウォーターマークを実現しています。​`watermarkMode`​ パラメーターは、代わりに変更されたファイルをリスンする場合には ​`MODIFIED_TIMESTAMP`​ に設定でき、ウォーターマークがまったく必要ない場合は ​`DISABLED`​ に設定することもできます。 最初の例で説明している「手間のかかる方法」を利用することをお勧めするのは、以下の場合のみです。 - ユースケースが極めてカスタムな場合。 - 自動ウォーターマークをサポートしていないコネクタを使用している場合。 それ以外の場合は、こうしたユースケースに対処する最適な方法として自動ウォーターマークをお勧めします。 ## [](#関連情報)関連情報 - [Object Store Connector ドキュメント](https://docs.mulesoft.com/object-store-connector/latest/) # ウォーターマークの移行 ウォーターマークは通常、たとえばレガシーリソースをポーリングして新しいデータを取得し、別の宛先エンドポイントと同期するときなど、データ同期を実行するために使用されます。ウォーターマークの技法により、定期的な同期が次に実行されるときに再開する時点を保存して取得します。ウォーターマークは通常、ObjectStore と一緒に使用されます。 Mule 3 アプローチについては、次の MuleSoft ブログを参照してください: [「Data Synchronizing made easy with Watermarks (ウォーターマークでデータ同期が簡単になる)」](https://blogs.mulesoft.com/dev/anypoint-platform-dev/data-synchronizing-made-easy-with-mule-watermarks/)​。 ここで、そのブログから引用した Mule 3 のウォーターマークの例を紹介します。 Mule 3 の例: ウォーターマークを使用した Salesforce 取引先責任者のポーリング ```xml ``` Anypoint Platform が拡張され、ユースケースが複雑になるに従って、Mule 3 アプローチでの制限が明らかになり始めました。 - 以前の ​``​ コンポーネントではカスタム ObjectStore の設定が可能でしたが、作成するのは簡単ではありませんでした。この問題についてはこのドキュメントですでに説明済みであり、新しい ObjectStore Connector では修正されます。 - ``​ 要素では、​``​ コンポーネント (現在は ​``​ に置換) が反復可能なペイロードを返す必要がありました。さらに、新しいウォーターマーク値を取得するには、そのペイロードを最後まで反復処理する必要がありました。その処理に失敗すると、値が不正確に更新されるか、一切更新されませんでした。 - フローでエラーがスローされた場合、コンテンジェンシー値でウォーターマークを更新する方法はありませんでした。 - いつどのように値が更新されるか、エキスパート以外のユーザーにはよくわかりませんでした。 このユースケースをどうすれば改善できるか検討しているとき、問題の本当の根本は、実際には はまったく不要であることだと気付きました。これは単に、他のコンポーネントの制限事項の影響で存在していたのです。 - ウォーターマークの人為的な反復は、多くのデータセットが 1 回しか反復できないという事実を補う方法でしかありませんでした。特に、バイナリストリームを処理する場合や、コネクタで自動ページ設定を行う場合がこれに当てはまります。Mule 4 では、この問題は反復可能なストリーミング機能によって修正されました。 - コンポーネントによる ObjectStore の自動処理は、古い ObjectStore サポートの UX の問題を埋め合わせるためだけのものでした。新しいコネクタでより簡単なセマンティクスを提供できれば、まったく必要がなくなります。 Mule 4 では、次のように上記の Mule 3 ブログ記事で説明しているユースケースを実行できます。 ```xml 2017-09-11T00:00:00.000Z " ++ vars.watermark] ]]> #[max(payload map $.LastModifiedDate)] ``` この例をステップごとに説明していきましょう。 - まず、このフローは汎用です。特定の方法でトリガーする必要はありません。別のフローから呼び出しても、​``​ を追加しても構いません。何らかの種別のトリガーを強制しなくても、ウォーターマークのセマンティクスを実現できるようになりました。 - この設定では、最初にウォーターマークのカスタム ObjectStore を定義しています。これは必須ではありません。ObjectStore を定義できず、単にすべてのアプリケーションで暗黙的な ObjectStore を使用する場合もあります。しかし、ここでは例として、独自の ObjectStore を使用します。 - このフローは、最後のウォーターマーク値を取得するための retrieve 操作で開始します。以下の点に注意してください。 - retrieve 操作ではデフォルト値が指定されます。これは、フローが最初に実行されるときにウォーターマークがまだ計算されていなくても、使用可能な値を取得できるようにするためです。これにより、​``​ → ​``​ のようなパターンが必要にならないようにしています。 - Target (対象) (​`target`​) パラメーターは、コネクタにメッセージペイロードをウォーターマークで上書きするのではなく、代わりに変数に配置するように指示するために使用されます。これはメッセージに悪影響を及ぼさないため、フローは再利用可能になり、保守するのが容易になります。これは、retrieve 操作の前に任意の種類の操作を追加でき、中断が起こらないためです。 - 次に、クエリを実行し、そのクエリでウォーターマークを使用して取得した結果を絞り込みます。 - 続いて、必要な処理をすべて実行します。こうした処理として、別のシステムに送信しても、変換しても構いません。 - 最後に、ウォーターマーク値を更新します。このステップに関しても重要な点がいくつもあります。 - 新しいウォーターマーク値は、最大の更新タイムスタンプにする必要があります。その値を取得するために DataWeave 式を使用します。 - 反復可能なストリーミング機能によって、インテグレーションロジックがどのようなものだったかを意識する必要がなくなりました。クエリ操作で自動ページ設定されるとしても (実際に自動ページ設定されます!)、この機能で結果セットを再度反復できることが保証されます。 - `failIfPresent`​ パラメーターが false に設定されます。そうしないと、操作は初回のみ機能し、ウォーターマークがすでにオブジェクトストアにある場合は失敗します。false に設定することで、値が存在すれば更新されるようになります。 - そして最後に、​`failOnNullValue`​ パラメーターが false に設定されました。なぜでしょうか? これは、クエリの結果が空の場合、値がないため、最大値を見つける DW 式が null を返すからです。これを true に設定すると、コネクタは自動的に null 値をスキップするため、ユーザーは ​``​ ルーターを使用して状況を確認する必要がなくなります。 ## [](#自動ウォーターマーク)自動ウォーターマーク 上記の機能は優れており、Mule 3 にあった機能よりも強力ですが、さらにシンプルな機能にしたいと考えました。そのため一部のコネクタには、上記のステップを一切実行しなくても、自動的にウォーターマークを行うことができるイベントソースがすでに含まれています。このドキュメントを執筆している時点で、ファイル、Ftp、Sftp、データベース、Salesforce の各コネクタにはこの機能がありますが、引き続き他のコネクタにもこの機能のサポートを追加していく予定です。 File Connector を使用して、この機能の仕組みの例を確認してみましょう。 Mule 4 の例: File Connector の自動ウォーターマーク ```xml ``` この例では、作成時刻を検索条件として使用し、自動ウォーターマークを実現しています。​`watermarkMode`​ パラメーターは、代わりに変更されたファイルをリスンする場合には ​`MODIFIED_TIMESTAMP`​ に設定でき、ウォーターマークがまったく必要ない場合は ​`DISABLED`​ に設定することもできます。 最初の例で説明している「手間のかかる方法」を利用することをお勧めするのは、以下の場合のみです。 - ユースケースが極めてカスタムな場合。 - 自動ウォーターマークをサポートしていないコネクタを使用している場合。 それ以外の場合は、こうしたユースケースに対処する最適な方法として自動ウォーターマークをお勧めします。 ## [](#関連情報)関連情報 - [Object Store Connector ドキュメント](https://docs.mulesoft.com/object-store-connector/latest/) # ウォーターマークの移行 ウォーターマークは通常、たとえばレガシーリソースをポーリングして新しいデータを取得し、別の宛先エンドポイントと同期するときなど、データ同期を実行するために使用されます。ウォーターマークの技法により、定期的な同期が次に実行されるときに再開する時点を保存して取得します。ウォーターマークは通常、ObjectStore と一緒に使用されます。 Mule 3 アプローチについては、次の MuleSoft ブログを参照してください: [「Data Synchronizing made easy with Watermarks (ウォーターマークでデータ同期が簡単になる)」](https://blogs.mulesoft.com/dev/anypoint-platform-dev/data-synchronizing-made-easy-with-mule-watermarks/)​。 ここで、そのブログから引用した Mule 3 のウォーターマークの例を紹介します。 Mule 3 の例: ウォーターマークを使用した Salesforce 取引先責任者のポーリング ```xml ``` Anypoint Platform が拡張され、ユースケースが複雑になるに従って、Mule 3 アプローチでの制限が明らかになり始めました。 - 以前の ​``​ コンポーネントではカスタム ObjectStore の設定が可能でしたが、作成するのは簡単ではありませんでした。この問題についてはこのドキュメントですでに説明済みであり、新しい ObjectStore Connector では修正されます。 - ``​ 要素では、​``​ コンポーネント (現在は ​``​ に置換) が反復可能なペイロードを返す必要がありました。さらに、新しいウォーターマーク値を取得するには、そのペイロードを最後まで反復処理する必要がありました。その処理に失敗すると、値が不正確に更新されるか、一切更新されませんでした。 - フローでエラーがスローされた場合、コンテンジェンシー値でウォーターマークを更新する方法はありませんでした。 - いつどのように値が更新されるか、エキスパート以外のユーザーにはよくわかりませんでした。 このユースケースをどうすれば改善できるか検討しているとき、問題の本当の根本は、実際には はまったく不要であることだと気付きました。これは単に、他のコンポーネントの制限事項の影響で存在していたのです。 - ウォーターマークの人為的な反復は、多くのデータセットが 1 回しか反復できないという事実を補う方法でしかありませんでした。特に、バイナリストリームを処理する場合や、コネクタで自動ページ設定を行う場合がこれに当てはまります。Mule 4 では、この問題は反復可能なストリーミング機能によって修正されました。 - コンポーネントによる ObjectStore の自動処理は、古い ObjectStore サポートの UX の問題を埋め合わせるためだけのものでした。新しいコネクタでより簡単なセマンティクスを提供できれば、まったく必要がなくなります。 Mule 4 では、次のように上記の Mule 3 ブログ記事で説明しているユースケースを実行できます。 ```xml 2017-09-11T00:00:00.000Z " ++ vars.watermark] ]]> #[max(payload map $.LastModifiedDate)] ``` この例をステップごとに説明していきましょう。 - まず、このフローは汎用です。特定の方法でトリガーする必要はありません。別のフローから呼び出しても、​``​ を追加しても構いません。何らかの種別のトリガーを強制しなくても、ウォーターマークのセマンティクスを実現できるようになりました。 - この設定では、最初にウォーターマークのカスタム ObjectStore を定義しています。これは必須ではありません。ObjectStore を定義できず、単にすべてのアプリケーションで暗黙的な ObjectStore を使用する場合もあります。しかし、ここでは例として、独自の ObjectStore を使用します。 - このフローは、最後のウォーターマーク値を取得するための retrieve 操作で開始します。以下の点に注意してください。 - retrieve 操作ではデフォルト値が指定されます。これは、フローが最初に実行されるときにウォーターマークがまだ計算されていなくても、使用可能な値を取得できるようにするためです。これにより、​``​ → ​``​ のようなパターンが必要にならないようにしています。 - Target (対象) (​`target`​) パラメーターは、コネクタにメッセージペイロードをウォーターマークで上書きするのではなく、代わりに変数に配置するように指示するために使用されます。これはメッセージに悪影響を及ぼさないため、フローは再利用可能になり、保守するのが容易になります。これは、retrieve 操作の前に任意の種類の操作を追加でき、中断が起こらないためです。 - 次に、クエリを実行し、そのクエリでウォーターマークを使用して取得した結果を絞り込みます。 - 続いて、必要な処理をすべて実行します。こうした処理として、別のシステムに送信しても、変換しても構いません。 - 最後に、ウォーターマーク値を更新します。このステップに関しても重要な点がいくつもあります。 - 新しいウォーターマーク値は、最大の更新タイムスタンプにする必要があります。その値を取得するために DataWeave 式を使用します。 - 反復可能なストリーミング機能によって、インテグレーションロジックがどのようなものだったかを意識する必要がなくなりました。クエリ操作で自動ページ設定されるとしても (実際に自動ページ設定されます!)、この機能で結果セットを再度反復できることが保証されます。 - `failIfPresent`​ パラメーターが false に設定されます。そうしないと、操作は初回のみ機能し、ウォーターマークがすでにオブジェクトストアにある場合は失敗します。false に設定することで、値が存在すれば更新されるようになります。 - そして最後に、​`failOnNullValue`​ パラメーターが false に設定されました。なぜでしょうか? これは、クエリの結果が空の場合、値がないため、最大値を見つける DW 式が null を返すからです。これを true に設定すると、コネクタは自動的に null 値をスキップするため、ユーザーは ​``​ ルーターを使用して状況を確認する必要がなくなります。 ## [](#自動ウォーターマーク)自動ウォーターマーク 上記の機能は優れており、Mule 3 にあった機能よりも強力ですが、さらにシンプルな機能にしたいと考えました。そのため一部のコネクタには、上記のステップを一切実行しなくても、自動的にウォーターマークを行うことができるイベントソースがすでに含まれています。このドキュメントを執筆している時点で、ファイル、Ftp、Sftp、データベース、Salesforce の各コネクタにはこの機能がありますが、引き続き他のコネクタにもこの機能のサポートを追加していく予定です。 File Connector を使用して、この機能の仕組みの例を確認してみましょう。 Mule 4 の例: File Connector の自動ウォーターマーク ```xml ``` この例では、作成時刻を検索条件として使用し、自動ウォーターマークを実現しています。​`watermarkMode`​ パラメーターは、代わりに変更されたファイルをリスンする場合には ​`MODIFIED_TIMESTAMP`​ に設定でき、ウォーターマークがまったく必要ない場合は ​`DISABLED`​ に設定することもできます。 最初の例で説明している「手間のかかる方法」を利用することをお勧めするのは、以下の場合のみです。 - ユースケースが極めてカスタムな場合。 - 自動ウォーターマークをサポートしていないコネクタを使用している場合。 それ以外の場合は、こうしたユースケースに対処する最適な方法として自動ウォーターマークをお勧めします。 ## [](#関連情報)関連情報 - [Object Store Connector ドキュメント](https://docs.mulesoft.com/object-store-connector/latest/) # ウォーターマークの移行 ウォーターマークは通常、たとえばレガシーリソースをポーリングして新しいデータを取得し、別の宛先エンドポイントと同期するときなど、データ同期を実行するために使用されます。ウォーターマークの技法により、定期的な同期が次に実行されるときに再開する時点を保存して取得します。ウォーターマークは通常、ObjectStore と一緒に使用されます。 Mule 3 アプローチについては、次の MuleSoft ブログを参照してください: [「Data Synchronizing made easy with Watermarks (ウォーターマークでデータ同期が簡単になる)」](https://blogs.mulesoft.com/dev/anypoint-platform-dev/data-synchronizing-made-easy-with-mule-watermarks/)​。 ここで、そのブログから引用した Mule 3 のウォーターマークの例を紹介します。 Mule 3 の例: ウォーターマークを使用した Salesforce 取引先責任者のポーリング ```xml ``` Anypoint Platform が拡張され、ユースケースが複雑になるに従って、Mule 3 アプローチでの制限が明らかになり始めました。 - 以前の ​``​ コンポーネントではカスタム ObjectStore の設定が可能でしたが、作成するのは簡単ではありませんでした。この問題についてはこのドキュメントですでに説明済みであり、新しい ObjectStore Connector では修正されます。 - ``​ 要素では、​``​ コンポーネント (現在は ​``​ に置換) が反復可能なペイロードを返す必要がありました。さらに、新しいウォーターマーク値を取得するには、そのペイロードを最後まで反復処理する必要がありました。その処理に失敗すると、値が不正確に更新されるか、一切更新されませんでした。 - フローでエラーがスローされた場合、コンテンジェンシー値でウォーターマークを更新する方法はありませんでした。 - いつどのように値が更新されるか、エキスパート以外のユーザーにはよくわかりませんでした。 このユースケースをどうすれば改善できるか検討しているとき、問題の本当の根本は、実際には はまったく不要であることだと気付きました。これは単に、他のコンポーネントの制限事項の影響で存在していたのです。 - ウォーターマークの人為的な反復は、多くのデータセットが 1 回しか反復できないという事実を補う方法でしかありませんでした。特に、バイナリストリームを処理する場合や、コネクタで自動ページ設定を行う場合がこれに当てはまります。Mule 4 では、この問題は反復可能なストリーミング機能によって修正されました。 - コンポーネントによる ObjectStore の自動処理は、古い ObjectStore サポートの UX の問題を埋め合わせるためだけのものでした。新しいコネクタでより簡単なセマンティクスを提供できれば、まったく必要がなくなります。 Mule 4 では、次のように上記の Mule 3 ブログ記事で説明しているユースケースを実行できます。 ```xml 2017-09-11T00:00:00.000Z " ++ vars.watermark] ]]> #[max(payload map $.LastModifiedDate)] ``` この例をステップごとに説明していきましょう。 - まず、このフローは汎用です。特定の方法でトリガーする必要はありません。別のフローから呼び出しても、​``​ を追加しても構いません。何らかの種別のトリガーを強制しなくても、ウォーターマークのセマンティクスを実現できるようになりました。 - この設定では、最初にウォーターマークのカスタム ObjectStore を定義しています。これは必須ではありません。ObjectStore を定義できず、単にすべてのアプリケーションで暗黙的な ObjectStore を使用する場合もあります。しかし、ここでは例として、独自の ObjectStore を使用します。 - このフローは、最後のウォーターマーク値を取得するための retrieve 操作で開始します。以下の点に注意してください。 - retrieve 操作ではデフォルト値が指定されます。これは、フローが最初に実行されるときにウォーターマークがまだ計算されていなくても、使用可能な値を取得できるようにするためです。これにより、​``​ → ​``​ のようなパターンが必要にならないようにしています。 - Target (対象) (​`target`​) パラメーターは、コネクタにメッセージペイロードをウォーターマークで上書きするのではなく、代わりに変数に配置するように指示するために使用されます。これはメッセージに悪影響を及ぼさないため、フローは再利用可能になり、保守するのが容易になります。これは、retrieve 操作の前に任意の種類の操作を追加でき、中断が起こらないためです。 - 次に、クエリを実行し、そのクエリでウォーターマークを使用して取得した結果を絞り込みます。 - 続いて、必要な処理をすべて実行します。こうした処理として、別のシステムに送信しても、変換しても構いません。 - 最後に、ウォーターマーク値を更新します。このステップに関しても重要な点がいくつもあります。 - 新しいウォーターマーク値は、最大の更新タイムスタンプにする必要があります。その値を取得するために DataWeave 式を使用します。 - 反復可能なストリーミング機能によって、インテグレーションロジックがどのようなものだったかを意識する必要がなくなりました。クエリ操作で自動ページ設定されるとしても (実際に自動ページ設定されます!)、この機能で結果セットを再度反復できることが保証されます。 - `failIfPresent`​ パラメーターが false に設定されます。そうしないと、操作は初回のみ機能し、ウォーターマークがすでにオブジェクトストアにある場合は失敗します。false に設定することで、値が存在すれば更新されるようになります。 - そして最後に、​`failOnNullValue`​ パラメーターが false に設定されました。なぜでしょうか? これは、クエリの結果が空の場合、値がないため、最大値を見つける DW 式が null を返すからです。これを true に設定すると、コネクタは自動的に null 値をスキップするため、ユーザーは ​``​ ルーターを使用して状況を確認する必要がなくなります。 ## [](#自動ウォーターマーク)自動ウォーターマーク 上記の機能は優れており、Mule 3 にあった機能よりも強力ですが、さらにシンプルな機能にしたいと考えました。そのため一部のコネクタには、上記のステップを一切実行しなくても、自動的にウォーターマークを行うことができるイベントソースがすでに含まれています。このドキュメントを執筆している時点で、ファイル、Ftp、Sftp、データベース、Salesforce の各コネクタにはこの機能がありますが、引き続き他のコネクタにもこの機能のサポートを追加していく予定です。 File Connector を使用して、この機能の仕組みの例を確認してみましょう。 Mule 4 の例: File Connector の自動ウォーターマーク ```xml ``` この例では、作成時刻を検索条件として使用し、自動ウォーターマークを実現しています。​`watermarkMode`​ パラメーターは、代わりに変更されたファイルをリスンする場合には ​`MODIFIED_TIMESTAMP`​ に設定でき、ウォーターマークがまったく必要ない場合は ​`DISABLED`​ に設定することもできます。 最初の例で説明している「手間のかかる方法」を利用することをお勧めするのは、以下の場合のみです。 - ユースケースが極めてカスタムな場合。 - 自動ウォーターマークをサポートしていないコネクタを使用している場合。 それ以外の場合は、こうしたユースケースに対処する最適な方法として自動ウォーターマークをお勧めします。 ## [](#関連情報)関連情報 - [Object Store Connector ドキュメント](https://docs.mulesoft.com/object-store-connector/latest/) # ウォーターマークの移行 ウォーターマークは通常、たとえばレガシーリソースをポーリングして新しいデータを取得し、別の宛先エンドポイントと同期するときなど、データ同期を実行するために使用されます。ウォーターマークの技法により、定期的な同期が次に実行されるときに再開する時点を保存して取得します。ウォーターマークは通常、ObjectStore と一緒に使用されます。 Mule 3 アプローチについては、次の MuleSoft ブログを参照してください: [「Data Synchronizing made easy with Watermarks (ウォーターマークでデータ同期が簡単になる)」](https://blogs.mulesoft.com/dev/anypoint-platform-dev/data-synchronizing-made-easy-with-mule-watermarks/)​。 ここで、そのブログから引用した Mule 3 のウォーターマークの例を紹介します。 Mule 3 の例: ウォーターマークを使用した Salesforce 取引先責任者のポーリング ```xml ``` Anypoint Platform が拡張され、ユースケースが複雑になるに従って、Mule 3 アプローチでの制限が明らかになり始めました。 - 以前の ​``​ コンポーネントではカスタム ObjectStore の設定が可能でしたが、作成するのは簡単ではありませんでした。この問題についてはこのドキュメントですでに説明済みであり、新しい ObjectStore Connector では修正されます。 - ``​ 要素では、​``​ コンポーネント (現在は ​``​ に置換) が反復可能なペイロードを返す必要がありました。さらに、新しいウォーターマーク値を取得するには、そのペイロードを最後まで反復処理する必要がありました。その処理に失敗すると、値が不正確に更新されるか、一切更新されませんでした。 - フローでエラーがスローされた場合、コンテンジェンシー値でウォーターマークを更新する方法はありませんでした。 - いつどのように値が更新されるか、エキスパート以外のユーザーにはよくわかりませんでした。 このユースケースをどうすれば改善できるか検討しているとき、問題の本当の根本は、実際には はまったく不要であることだと気付きました。これは単に、他のコンポーネントの制限事項の影響で存在していたのです。 - ウォーターマークの人為的な反復は、多くのデータセットが 1 回しか反復できないという事実を補う方法でしかありませんでした。特に、バイナリストリームを処理する場合や、コネクタで自動ページ設定を行う場合がこれに当てはまります。Mule 4 では、この問題は反復可能なストリーミング機能によって修正されました。 - コンポーネントによる ObjectStore の自動処理は、古い ObjectStore サポートの UX の問題を埋め合わせるためだけのものでした。新しいコネクタでより簡単なセマンティクスを提供できれば、まったく必要がなくなります。 Mule 4 では、次のように上記の Mule 3 ブログ記事で説明しているユースケースを実行できます。 ```xml 2017-09-11T00:00:00.000Z " ++ vars.watermark] ]]> #[max(payload map $.LastModifiedDate)] ``` この例をステップごとに説明していきましょう。 - まず、このフローは汎用です。特定の方法でトリガーする必要はありません。別のフローから呼び出しても、​``​ を追加しても構いません。何らかの種別のトリガーを強制しなくても、ウォーターマークのセマンティクスを実現できるようになりました。 - この設定では、最初にウォーターマークのカスタム ObjectStore を定義しています。これは必須ではありません。ObjectStore を定義できず、単にすべてのアプリケーションで暗黙的な ObjectStore を使用する場合もあります。しかし、ここでは例として、独自の ObjectStore を使用します。 - このフローは、最後のウォーターマーク値を取得するための retrieve 操作で開始します。以下の点に注意してください。 - retrieve 操作ではデフォルト値が指定されます。これは、フローが最初に実行されるときにウォーターマークがまだ計算されていなくても、使用可能な値を取得できるようにするためです。これにより、​``​ → ​``​ のようなパターンが必要にならないようにしています。 - Target (対象) (​`target`​) パラメーターは、コネクタにメッセージペイロードをウォーターマークで上書きするのではなく、代わりに変数に配置するように指示するために使用されます。これはメッセージに悪影響を及ぼさないため、フローは再利用可能になり、保守するのが容易になります。これは、retrieve 操作の前に任意の種類の操作を追加でき、中断が起こらないためです。 - 次に、クエリを実行し、そのクエリでウォーターマークを使用して取得した結果を絞り込みます。 - 続いて、必要な処理をすべて実行します。こうした処理として、別のシステムに送信しても、変換しても構いません。 - 最後に、ウォーターマーク値を更新します。このステップに関しても重要な点がいくつもあります。 - 新しいウォーターマーク値は、最大の更新タイムスタンプにする必要があります。その値を取得するために DataWeave 式を使用します。 - 反復可能なストリーミング機能によって、インテグレーションロジックがどのようなものだったかを意識する必要がなくなりました。クエリ操作で自動ページ設定されるとしても (実際に自動ページ設定されます!)、この機能で結果セットを再度反復できることが保証されます。 - `failIfPresent`​ パラメーターが false に設定されます。そうしないと、操作は初回のみ機能し、ウォーターマークがすでにオブジェクトストアにある場合は失敗します。false に設定することで、値が存在すれば更新されるようになります。 - そして最後に、​`failOnNullValue`​ パラメーターが false に設定されました。なぜでしょうか? これは、クエリの結果が空の場合、値がないため、最大値を見つける DW 式が null を返すからです。これを true に設定すると、コネクタは自動的に null 値をスキップするため、ユーザーは ​``​ ルーターを使用して状況を確認する必要がなくなります。 ## [](#自動ウォーターマーク)自動ウォーターマーク 上記の機能は優れており、Mule 3 にあった機能よりも強力ですが、さらにシンプルな機能にしたいと考えました。そのため一部のコネクタには、上記のステップを一切実行しなくても、自動的にウォーターマークを行うことができるイベントソースがすでに含まれています。このドキュメントを執筆している時点で、ファイル、Ftp、Sftp、データベース、Salesforce の各コネクタにはこの機能がありますが、引き続き他のコネクタにもこの機能のサポートを追加していく予定です。 File Connector を使用して、この機能の仕組みの例を確認してみましょう。 Mule 4 の例: File Connector の自動ウォーターマーク ```xml ``` この例では、作成時刻を検索条件として使用し、自動ウォーターマークを実現しています。​`watermarkMode`​ パラメーターは、代わりに変更されたファイルをリスンする場合には ​`MODIFIED_TIMESTAMP`​ に設定でき、ウォーターマークがまったく必要ない場合は ​`DISABLED`​ に設定することもできます。 最初の例で説明している「手間のかかる方法」を利用することをお勧めするのは、以下の場合のみです。 - ユースケースが極めてカスタムな場合。 - 自動ウォーターマークをサポートしていないコネクタを使用している場合。 それ以外の場合は、こうしたユースケースに対処する最適な方法として自動ウォーターマークをお勧めします。 ## [](#関連情報)関連情報 - [Object Store Connector ドキュメント](https://docs.mulesoft.com/object-store-connector/latest/) # ウォーターマークの移行 ウォーターマークは通常、たとえばレガシーリソースをポーリングして新しいデータを取得し、別の宛先エンドポイントと同期するときなど、データ同期を実行するために使用されます。ウォーターマークの技法により、定期的な同期が次に実行されるときに再開する時点を保存して取得します。ウォーターマークは通常、ObjectStore と一緒に使用されます。 Mule 3 アプローチについては、次の MuleSoft ブログを参照してください: [「Data Synchronizing made easy with Watermarks (ウォーターマークでデータ同期が簡単になる)」](https://blogs.mulesoft.com/dev/anypoint-platform-dev/data-synchronizing-made-easy-with-mule-watermarks/)​。 ここで、そのブログから引用した Mule 3 のウォーターマークの例を紹介します。 Mule 3 の例: ウォーターマークを使用した Salesforce 取引先責任者のポーリング ```xml ``` Anypoint Platform が拡張され、ユースケースが複雑になるに従って、Mule 3 アプローチでの制限が明らかになり始めました。 - 以前の ​``​ コンポーネントではカスタム ObjectStore の設定が可能でしたが、作成するのは簡単ではありませんでした。この問題についてはこのドキュメントですでに説明済みであり、新しい ObjectStore Connector では修正されます。 - ``​ 要素では、​``​ コンポーネント (現在は ​``​ に置換) が反復可能なペイロードを返す必要がありました。さらに、新しいウォーターマーク値を取得するには、そのペイロードを最後まで反復処理する必要がありました。その処理に失敗すると、値が不正確に更新されるか、一切更新されませんでした。 - フローでエラーがスローされた場合、コンテンジェンシー値でウォーターマークを更新する方法はありませんでした。 - いつどのように値が更新されるか、エキスパート以外のユーザーにはよくわかりませんでした。 このユースケースをどうすれば改善できるか検討しているとき、問題の本当の根本は、実際には はまったく不要であることだと気付きました。これは単に、他のコンポーネントの制限事項の影響で存在していたのです。 - ウォーターマークの人為的な反復は、多くのデータセットが 1 回しか反復できないという事実を補う方法でしかありませんでした。特に、バイナリストリームを処理する場合や、コネクタで自動ページ設定を行う場合がこれに当てはまります。Mule 4 では、この問題は反復可能なストリーミング機能によって修正されました。 - コンポーネントによる ObjectStore の自動処理は、古い ObjectStore サポートの UX の問題を埋め合わせるためだけのものでした。新しいコネクタでより簡単なセマンティクスを提供できれば、まったく必要がなくなります。 Mule 4 では、次のように上記の Mule 3 ブログ記事で説明しているユースケースを実行できます。 ```xml 2017-09-11T00:00:00.000Z " ++ vars.watermark] ]]> #[max(payload map $.LastModifiedDate)] ``` この例をステップごとに説明していきましょう。 - まず、このフローは汎用です。特定の方法でトリガーする必要はありません。別のフローから呼び出しても、​``​ を追加しても構いません。何らかの種別のトリガーを強制しなくても、ウォーターマークのセマンティクスを実現できるようになりました。 - この設定では、最初にウォーターマークのカスタム ObjectStore を定義しています。これは必須ではありません。ObjectStore を定義できず、単にすべてのアプリケーションで暗黙的な ObjectStore を使用する場合もあります。しかし、ここでは例として、独自の ObjectStore を使用します。 - このフローは、最後のウォーターマーク値を取得するための retrieve 操作で開始します。以下の点に注意してください。 - retrieve 操作ではデフォルト値が指定されます。これは、フローが最初に実行されるときにウォーターマークがまだ計算されていなくても、使用可能な値を取得できるようにするためです。これにより、​``​ → ​``​ のようなパターンが必要にならないようにしています。 - Target (対象) (​`target`​) パラメーターは、コネクタにメッセージペイロードをウォーターマークで上書きするのではなく、代わりに変数に配置するように指示するために使用されます。これはメッセージに悪影響を及ぼさないため、フローは再利用可能になり、保守するのが容易になります。これは、retrieve 操作の前に任意の種類の操作を追加でき、中断が起こらないためです。 - 次に、クエリを実行し、そのクエリでウォーターマークを使用して取得した結果を絞り込みます。 - 続いて、必要な処理をすべて実行します。こうした処理として、別のシステムに送信しても、変換しても構いません。 - 最後に、ウォーターマーク値を更新します。このステップに関しても重要な点がいくつもあります。 - 新しいウォーターマーク値は、最大の更新タイムスタンプにする必要があります。その値を取得するために DataWeave 式を使用します。 - 反復可能なストリーミング機能によって、インテグレーションロジックがどのようなものだったかを意識する必要がなくなりました。クエリ操作で自動ページ設定されるとしても (実際に自動ページ設定されます!)、この機能で結果セットを再度反復できることが保証されます。 - `failIfPresent`​ パラメーターが false に設定されます。そうしないと、操作は初回のみ機能し、ウォーターマークがすでにオブジェクトストアにある場合は失敗します。false に設定することで、値が存在すれば更新されるようになります。 - そして最後に、​`failOnNullValue`​ パラメーターが false に設定されました。なぜでしょうか? これは、クエリの結果が空の場合、値がないため、最大値を見つける DW 式が null を返すからです。これを true に設定すると、コネクタは自動的に null 値をスキップするため、ユーザーは ​``​ ルーターを使用して状況を確認する必要がなくなります。 ## [](#自動ウォーターマーク)自動ウォーターマーク 上記の機能は優れており、Mule 3 にあった機能よりも強力ですが、さらにシンプルな機能にしたいと考えました。そのため一部のコネクタには、上記のステップを一切実行しなくても、自動的にウォーターマークを行うことができるイベントソースがすでに含まれています。このドキュメントを執筆している時点で、ファイル、Ftp、Sftp、データベース、Salesforce の各コネクタにはこの機能がありますが、引き続き他のコネクタにもこの機能のサポートを追加していく予定です。 File Connector を使用して、この機能の仕組みの例を確認してみましょう。 Mule 4 の例: File Connector の自動ウォーターマーク ```xml ``` この例では、作成時刻を検索条件として使用し、自動ウォーターマークを実現しています。​`watermarkMode`​ パラメーターは、代わりに変更されたファイルをリスンする場合には ​`MODIFIED_TIMESTAMP`​ に設定でき、ウォーターマークがまったく必要ない場合は ​`DISABLED`​ に設定することもできます。 最初の例で説明している「手間のかかる方法」を利用することをお勧めするのは、以下の場合のみです。 - ユースケースが極めてカスタムな場合。 - 自動ウォーターマークをサポートしていないコネクタを使用している場合。 それ以外の場合は、こうしたユースケースに対処する最適な方法として自動ウォーターマークをお勧めします。 ## [](#関連情報)関連情報 - [Object Store Connector ドキュメント](https://docs.mulesoft.com/object-store-connector/latest/) # エラーハンドラー Mule で発生するエラーは、次の 2 つの主要カテゴリのいずれかに分類されます。 - [システムエラー](#system_errors) - [メッセージングエラー](#messaging_errors) ## [](#system_errors)システムエラー システムレベルで例外が発生し、Mule イベントが関係していない場合、システムエラーがスローされます。システムエラーハンドラーは、次の状況で発生した例外を管理します。 - アプリケーションの起動中。 - 外部システムへの接続が失敗した場合。 システムエラーが発生すると、Mule は、登録されているリスナーにエラー通知を送信し、エラーを記録し、エラーが接続の失敗によるものであれば再接続戦略を実行します。 システムエラーハンドラーは、Mule では設定できません。 ## [](#messaging_errors)メッセージングエラー Mule イベントと Mule イベントに含まれるメッセージを処理する Mule アプリケーションのフロー内で問題が発生すると、Mule はメッセージングエラー (​[Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-error-concept)​) をスローします。 Mule メッセージングエラーは複数の方法で処理できます。 - [デフォルトのエラー処理](#default_error_handling)​メカニズムを使用できます。 - フロー内では、フローの組み込み Error Handler コンポーネント内で ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/on-error-scope-concept)​ (On Error Continue および On Error Propagate) をセットアップできます。これらのコンポーネントには、エラーを処理するための任意の数のコンポーネントを含めることができます。 次の図は、イベントプロセッサー (HTTP Request 操作やデータベース操作など) でエラーがスローされたときの動作を示しています。 ![error handling 39be7](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-39be7.png) - フロー外では、​[Error Handler](#global_error_handler)​ コンポーネントをセットアップし、そのコンポーネントを他のエラーハンドラー設定から参照できます。グローバルエラーハンドラーには、On Error コンポーネントとそのコンテンツを含めることもできます。 - エラー処理は、フローに存在する ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept)​内からセットアップすることもできます。スコープ内には組み込みエラーハンドラーが含まれ、その中で On Error コンポーネントとそのコンテンツを設定できます。 ### [](#default_error_handling)メッセージのデフォルトエラー処理の使用 デフォルトでは、未処理のメッセージングエラーは記録され、伝達されます。フローで処理されている Mule メッセージでエラーが発生すると、フローの通常の実行は停止し、プロセスがフローのデフォルトのエラーハンドラーに転送され、そのエラーハンドラーでエラーが伝達されます。 次の例は、エラーを管理するように明示的に設定したエラー処理コンポーネントを使用するのではなく、デフォルトのエラー処理を使用する簡単な Mule アプリケーション設定を示しています。 ![デフォルトのエラー処理メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-error-handling-default.png) デフォルトのエラー処理の例の XML は次のようになります。 ```xml ``` この設定で Mule アプリケーションを開始し、​`[http://0.0.0.0:8081/users](http://0.0.0.0:8081/users)`​ を (たとえばブラウザーなどに) 読み込むことで HTTP リスナーをトリガーすると、フローは、存在しないファイルに対して HTTP 要求 (​`http://jsonplaceholder.typicode.com:80/somebadrequest`​) を実行します。結果として、Anypoint Studio コンソールでエラーが記録されて Web ブラウザーに伝達されます。 - Anypoint Studio コンソールログ Studio コンソールはエラーメッセージを出力します。このメッセージは、HTTP GET 要求から返された 404 エラーがデフォルトハンドラー (​`OnErrorPropagateHandler`​) により伝達されていることを示します。Mule はこのエラーを HTTP:NOT\_FOUND​ として識別します。 ```txt ERROR 2021-01-19 18:48:50,392 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-example/processors/0; event: 1d3baf11-5aa0-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request) Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-example(error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request)) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ``` Studio コンソールのエラーログは次の情報を表します。 - **Message (メッセージ)**​: エラーの説明 - **Element (要素)**​: 実行を失敗させ、エラーの原因となった XML 要素 - **Element DSL (要素 DSL)**​: 実行を失敗させ、エラーの原因となった XML 要素。DSL 形式で表現されます。 - **Error type (エラー種別)**​: Mule アプリケーションで発生した Mule エラーの種別 - **Flowstack (フロースタック)**​: フロースタックトレースのエラーログ この項目には、Mule イベントを処理した各フローと、イベントを次のフローに送信したプロセッサーのエントリがリストされます。最後のエントリには、イベントの処理中に失敗したフローとプロセッサーが示されます。 Mule 4.3.0 以降、フロースタックエントリはデフォルトで有効になっています。フロースタックログを無効にするには、​`mule.flowTrace`​ 設定プロパティを ​`false`​ に設定することができます。 - Web ブラウザーへのエラーの伝達 HTTP:NOT\_FOUND​ エラーの説明は、リスナーをトリガーするために使用したブラウザータブに表示されます。 ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` この Mule エラーの説明は、次の 2 つの理由でブラウザーに表示されます。 - デフォルトのエラーハンドラーで On Error Propagate プロセス (​`OnErrorPropagateHandler`​) を使用しています。 On Error Propagate コンポーネントによって、フローが失敗し、HTTP リスナーで、見つからないファイルに関連付けられる ​`404`​ エラーのエラー応答が準備されます。 - HTTP リスナーでデフォルトのエラー (​`error.description`​) および成功 (​`payload`​) 応答を使用してメッセージ本文を返しています。 カスタム応答が設定されていないため、ブラウザーにエラーの説明が表示されます。 ### [](#on_error_continue)On-Error コンポーネントを使用したメッセージングエラーの処理 デフォルトのエラー処理メカニズムを使用する代わりに ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/on-error-scope-concept)​ (On Error Continue および On Error Propagate) を組み込みまたは外部の Error Handler コンポーネント内で使用できます。 次の例は、HTTP リスナーがトリガーされたときに HTTP 要求の結果を返すように Studio で設定された簡単なフローを示しています。​[デフォルトのエラー処理の例](#default_error_handling)​とは異なり、この例では、On Error Continue (​`on-error-continue`​) がフローの組み込み Error Handler (​`error-handler`​) コンポーネント内で設定され、On Error Continue には、エラーの説明を書き込む Logger が含まれます。 ![mruntime on error continue](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-on-error-continue.png) この例の XML は次のようになります。 ```xml ``` デフォルトのエラー処理の例と同様に、要求されたページが見つからないため、フローは 404 エラーを返し、Mule はこのエラーを HTTP:NOT\_FOUND​ エラーとして識別します。 ただし、このケースでは、エラーが伝達されないため、HTTP リスナーをトリガーするために使用したブラウザーのタブは空白になります。On Error Continue を使用すると、例のフローは、ページが見つからなくても、GET 要求の 200 と共に正常終了したかのように処理されます。HTTP リスナーはデフォルトの成功応答の動作 (メッセージ本文として ​`payload`​ コンテンツを返す) を実行します。ページが見つからなかったため、ブラウザーに表示するコンテンツはありません。このため、ブラウザータブは空白になります。 Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージ (以下の 1 番目の ERROR メッセージ) も出力されます。また、Mule エラーについて説明する (​`error.description`​。​[「Mule エラーのセレクター式」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-error-concept#selector_expressions)​を参照)、ロガーからの ERROR メッセージ (以下の 2 番目の ERROR) が出力されます。 ```txt ERROR 2021-01-19 18:42:04,583 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorContinueHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15 Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-normalFlow(error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ERROR 2021-01-19 18:42:04,586 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/errorHandler/0/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` On Error Continue (​`on-error-continue`​) の代わりに On Error Propagate (​`on-error-propagate`​) を使用して同じ Mule アプリケーションを作成した場合、同じエラーメッセージが Studio コンソールに表示されますが、記録されたエラーメッセージがブラウザーにも表示されます。この動作はデフォルトのエラー処理動作と同じです。どちらも On Error Propagate を使用するためです。 各 On Error コンポーネント内で、定義するエラーパスには任意の数のイベントプロセッサーを組み込むことができるため、特定のエラー種別を必要なだけ正確に処理できます。On-Error コンポーネントで処理する特定の Mule エラーを選択できます。Error Handler コンポーネントは、エラーに一致する最初の On Error コンポーネントにエラーを転送します。 フローレベルでのより複雑なエラー処理設定については、​[「Mule 4 の概要: エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-error-handlers)​を参照してください。 On Error Continue および On Error Propagate についての詳細は、​[「On-Error コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.3/on-error-scope-concept)​を参照してください。 ### [](#global_error_handler)グローバルエラーハンドラーの参照 グローバルエラーハンドラーは、同じ方法でエラーを処理する複数のフローまたは Try スコープが必要な場合に役立つ可能性があります。エラーハンドラーへの参照を提供することで、再利用設定を作成できます。 - [グローバルエラー処理設定の定義](#global_error_config_set) - [フローからのエラー処理設定の参照](#global_error_config_ref) #### [](#global_error_config_set)グローバルエラー処理設定の定義 次の XML 設定では、​``​ を使用して ​``​ 設定を参照するデフォルトのエラー処理設定を定義します。 ```xml ``` Studio UI では、グローバルエラー処理の例は次のようになります。 ![error handlers global](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handlers-global.png) この例には、エラーを処理するための 2 つの主要なコンポーネントが含まれます。Studio キャンバスに表示される埋め込みコンポーネントを含む Error Handler (​`error-handler`​) と、キャンバスに表示されないグローバルエラー処理設定です。 UI の例のフロー (​**someFlow**​) は、Error Handler コンポーネントが Mule アプリケーションのフローの外側にあることを示しています。 要求により HTTP:NOT\_FOUND​ エラーが生成されるため、Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージが出力されます。 On Error Continue 設定では、処理するエラーが伝達されません (​[On-Error コンポーネントを使用したメッセージングエラーの処理](#on_error_continue)​を参照)。 XML マークアップで設定を記述する代わりに Studio UI でグローバルエラー処理の例をセットアップする方法は、次のとおりです。 1. \[Error Handler\] コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ から Studio キャンバスにドラッグし、​**「allErrorHandler」**​という名前を付けます。 このコンポーネントはどのフローにも含まれません。 2. \[On Error Continue\] コンポーネントを \[Error Handler\] コンポーネントにドラッグします。 3. \[Set Payload\] コンポーネントを \[On Error Continue\] コンポーネントにドラッグします。 \[Set Payload\] コンポーネントは 1 つの例です。Logger など、他のコンポーネントを使用して、そのコンポーネント内で独自のエラーメッセージを記述することができます。Set Payload の例では、エラーの説明に Mule 変数を使用します (詳細は、​[「定義済み変数」](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-variables-context)​の ​`error`​ 変数を参照)。 4. Studio でグローバルエラー処理参照を作成します。 1. **\[Global Elements (グローバル要素)\]**​ をクリックして ​**\[Global Configuration Elements (グローバル設定要素)\]**​ を開きます。 **\[Global Elements (グローバル要素)\]**​ は Studio キャンバスの下にあります。 2. **\[Global Configuration Elements (グローバル設定要素)\]**​ で ​**\[Create (作成)\]**​ をクリックして ​**\[Choose Global Type (グローバル種別の選択)\]**​ ダイアログを開きます。 ![error handling global type](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-global-type.png) 3. ダイアログから ​**\[Global Configuration (グローバル設定)\]**​ -→ ​**\[Configuration (設定)\]**​ を選択し、​**\[OK\]**​ をクリックして、​**\[Configuration (設定)\]**​ ダイアログを開きます。 ![error handling global config](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/error-handling-global-config.png) 4. **\[Configuration (設定)\]**​ ダイアログから、​**\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ 項目で ​**\[allErrorHandler\]**​ を選択し、​**\[OK\]**​ をクリックします。 5. XML で記述された値を使用して、HTTP Listener および HTTP Request コンポーネントをセットアップします。 6. (Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックして、XML 設定が正しいことを確認します。 ### [](#global_error_config_ref)フローからのエラー処理設定の参照
この例の一部の要素の設定は XML のみです。
フローは、フローの外側にあるグローバルエラーハンドラーを参照できます。フローはそのすべてのエラーを、参照を介して記録します。 例: アプリケーションの XML 設定 ```xml ``` この XML の例では、グローバルエラーハンドラーは、​`loggingErrorHandler`​ という名前の ​``​ 要素を介して設定されます。フローは ​``​ を使用してエラーハンドラーを参照します。 Studio でフローからグローバルエラーハンドラー設定を参照する手順は、次のとおりです。 1. Studio で、​**\[Error Handler\]**​ コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ からキャンバスにドラッグし、UI を使用してそのコンポーネントを設定します。 2. Mule アプリケーションで、(Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックします。 3. (XML のみの設定) ​``​ 要素内で、参照の XML を入力します (例: ``​)。 次の例では、`` 要素内の ​``​ を使用してグローバル On Error Continue 要素 (​``​) を参照します。 どちらも、UI ではなく、​**\[Configuration XML (設定 XML)\]**​ を介した手動設定が必要です。 ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept) - [Raise Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/raise-error-component-reference) - [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-error-handlers) - [Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-core-exception-strategies) # エラーハンドラー Mule で発生するエラーは、次の 2 つの主要カテゴリのいずれかに分類されます。 - [システムエラー](#system_errors) - [メッセージングエラー](#messaging_errors) ## [](#system_errors)システムエラー システムレベルで例外が発生し、Mule イベントが関係していない場合、システムエラーがスローされます。システムエラーハンドラーは、次の状況で発生した例外を管理します。 - アプリケーションの起動中。 - 外部システムへの接続が失敗した場合。 システムエラーが発生すると、Mule は、登録されているリスナーにエラー通知を送信し、エラーを記録し、エラーが接続の失敗によるものであれば再接続戦略を実行します。 システムエラーハンドラーは、Mule では設定できません。 ## [](#messaging_errors)メッセージングエラー Mule イベントと Mule イベントに含まれるメッセージを処理する Mule アプリケーションのフロー内で問題が発生すると、Mule はメッセージングエラー (​[Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-error-concept)​) をスローします。 Mule メッセージングエラーは複数の方法で処理できます。 - [デフォルトのエラー処理](#default_error_handling)​メカニズムを使用できます。 - フロー内では、フローの組み込み Error Handler コンポーネント内で ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/on-error-scope-concept)​ (On Error Continue および On Error Propagate) をセットアップできます。これらのコンポーネントには、エラーを処理するための任意の数のコンポーネントを含めることができます。 次の図は、イベントプロセッサー (HTTP Request 操作やデータベース操作など) でエラーがスローされたときの動作を示しています。 ![error handling 39be7](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-39be7.png) - フロー外では、​[Error Handler](#global_error_handler)​ コンポーネントをセットアップし、そのコンポーネントを他のエラーハンドラー設定から参照できます。グローバルエラーハンドラーには、On Error コンポーネントとそのコンテンツを含めることもできます。 - エラー処理は、フローに存在する ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept)​内からセットアップすることもできます。スコープ内には組み込みエラーハンドラーが含まれ、その中で On Error コンポーネントとそのコンテンツを設定できます。 ### [](#default_error_handling)メッセージのデフォルトエラー処理の使用 デフォルトでは、未処理のメッセージングエラーは記録され、伝達されます。フローで処理されている Mule メッセージでエラーが発生すると、フローの通常の実行は停止し、プロセスがフローのデフォルトのエラーハンドラーに転送され、そのエラーハンドラーでエラーが伝達されます。 次の例は、エラーを管理するように明示的に設定したエラー処理コンポーネントを使用するのではなく、デフォルトのエラー処理を使用する簡単な Mule アプリケーション設定を示しています。 ![デフォルトのエラー処理メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-error-handling-default.png) デフォルトのエラー処理の例の XML は次のようになります。 ```xml ``` この設定で Mule アプリケーションを開始し、​`[http://0.0.0.0:8081/users](http://0.0.0.0:8081/users)`​ を (たとえばブラウザーなどに) 読み込むことで HTTP リスナーをトリガーすると、フローは、存在しないファイルに対して HTTP 要求 (​`http://jsonplaceholder.typicode.com:80/somebadrequest`​) を実行します。結果として、Anypoint Studio コンソールでエラーが記録されて Web ブラウザーに伝達されます。 - Anypoint Studio コンソールログ Studio コンソールはエラーメッセージを出力します。このメッセージは、HTTP GET 要求から返された 404 エラーがデフォルトハンドラー (​`OnErrorPropagateHandler`​) により伝達されていることを示します。Mule はこのエラーを HTTP:NOT\_FOUND​ として識別します。 ```txt ERROR 2021-01-19 18:48:50,392 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-example/processors/0; event: 1d3baf11-5aa0-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request) Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-example(error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request)) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ``` Studio コンソールのエラーログは次の情報を表します。 - **Message (メッセージ)**​: エラーの説明 - **Element (要素)**​: 実行を失敗させ、エラーの原因となった XML 要素 - **Element DSL (要素 DSL)**​: 実行を失敗させ、エラーの原因となった XML 要素。DSL 形式で表現されます。 - **Error type (エラー種別)**​: Mule アプリケーションで発生した Mule エラーの種別 - **Flowstack (フロースタック)**​: フロースタックトレースのエラーログ この項目には、Mule イベントを処理した各フローと、イベントを次のフローに送信したプロセッサーのエントリがリストされます。最後のエントリには、イベントの処理中に失敗したフローとプロセッサーが示されます。 Mule 4.3.0 以降、フロースタックエントリはデフォルトで有効になっています。フロースタックログを無効にするには、​`mule.flowTrace`​ 設定プロパティを ​`false`​ に設定することができます。 - Web ブラウザーへのエラーの伝達 HTTP:NOT\_FOUND​ エラーの説明は、リスナーをトリガーするために使用したブラウザータブに表示されます。 ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` この Mule エラーの説明は、次の 2 つの理由でブラウザーに表示されます。 - デフォルトのエラーハンドラーで On Error Propagate プロセス (​`OnErrorPropagateHandler`​) を使用しています。 On Error Propagate コンポーネントによって、フローが失敗し、HTTP リスナーで、見つからないファイルに関連付けられる ​`404`​ エラーのエラー応答が準備されます。 - HTTP リスナーでデフォルトのエラー (​`error.description`​) および成功 (​`payload`​) 応答を使用してメッセージ本文を返しています。 カスタム応答が設定されていないため、ブラウザーにエラーの説明が表示されます。 ### [](#on_error_continue)On-Error コンポーネントを使用したメッセージングエラーの処理 デフォルトのエラー処理メカニズムを使用する代わりに ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/on-error-scope-concept)​ (On Error Continue および On Error Propagate) を組み込みまたは外部の Error Handler コンポーネント内で使用できます。 次の例は、HTTP リスナーがトリガーされたときに HTTP 要求の結果を返すように Studio で設定された簡単なフローを示しています。​[デフォルトのエラー処理の例](#default_error_handling)​とは異なり、この例では、On Error Continue (​`on-error-continue`​) がフローの組み込み Error Handler (​`error-handler`​) コンポーネント内で設定され、On Error Continue には、エラーの説明を書き込む Logger が含まれます。 ![mruntime on error continue](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-on-error-continue.png) この例の XML は次のようになります。 ```xml ``` デフォルトのエラー処理の例と同様に、要求されたページが見つからないため、フローは 404 エラーを返し、Mule はこのエラーを HTTP:NOT\_FOUND​ エラーとして識別します。 ただし、このケースでは、エラーが伝達されないため、HTTP リスナーをトリガーするために使用したブラウザーのタブは空白になります。On Error Continue を使用すると、例のフローは、ページが見つからなくても、GET 要求の 200 と共に正常終了したかのように処理されます。HTTP リスナーはデフォルトの成功応答の動作 (メッセージ本文として ​`payload`​ コンテンツを返す) を実行します。ページが見つからなかったため、ブラウザーに表示するコンテンツはありません。このため、ブラウザータブは空白になります。 Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージ (以下の 1 番目の ERROR メッセージ) も出力されます。また、Mule エラーについて説明する (​`error.description`​。​[「Mule エラーのセレクター式」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-error-concept#selector_expressions)​を参照)、ロガーからの ERROR メッセージ (以下の 2 番目の ERROR) が出力されます。 ```txt ERROR 2021-01-19 18:42:04,583 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorContinueHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15 Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-normalFlow(error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ERROR 2021-01-19 18:42:04,586 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/errorHandler/0/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` On Error Continue (​`on-error-continue`​) の代わりに On Error Propagate (​`on-error-propagate`​) を使用して同じ Mule アプリケーションを作成した場合、同じエラーメッセージが Studio コンソールに表示されますが、記録されたエラーメッセージがブラウザーにも表示されます。この動作はデフォルトのエラー処理動作と同じです。どちらも On Error Propagate を使用するためです。 各 On Error コンポーネント内で、定義するエラーパスには任意の数のイベントプロセッサーを組み込むことができるため、特定のエラー種別を必要なだけ正確に処理できます。On-Error コンポーネントで処理する特定の Mule エラーを選択できます。Error Handler コンポーネントは、エラーに一致する最初の On Error コンポーネントにエラーを転送します。 フローレベルでのより複雑なエラー処理設定については、​[「Mule 4 の概要: エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-error-handlers)​を参照してください。 On Error Continue および On Error Propagate についての詳細は、​[「On-Error コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.4/on-error-scope-concept)​を参照してください。 ### [](#global_error_handler)グローバルエラーハンドラーの参照 グローバルエラーハンドラーは、同じ方法でエラーを処理する複数のフローまたは Try スコープが必要な場合に役立つ可能性があります。エラーハンドラーへの参照を提供することで、再利用設定を作成できます。 - [グローバルエラー処理設定の定義](#global_error_config_set) - [フローからのエラー処理設定の参照](#global_error_config_ref) #### [](#global_error_config_set)グローバルエラー処理設定の定義 次の XML 設定では、​``​ を使用して ​``​ 設定を参照するデフォルトのエラー処理設定を定義します。 ```xml ``` Studio UI では、グローバルエラー処理の例は次のようになります。 ![error handlers global](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handlers-global.png) この例には、エラーを処理するための 2 つの主要なコンポーネントが含まれます。Studio キャンバスに表示される埋め込みコンポーネントを含む Error Handler (​`error-handler`​) と、キャンバスに表示されないグローバルエラー処理設定です。 UI の例のフロー (​**someFlow**​) は、Error Handler コンポーネントが Mule アプリケーションのフローの外側にあることを示しています。 要求により HTTP:NOT\_FOUND​ エラーが生成されるため、Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージが出力されます。 On Error Continue 設定では、処理するエラーが伝達されません (​[On-Error コンポーネントを使用したメッセージングエラーの処理](#on_error_continue)​を参照)。 XML マークアップで設定を記述する代わりに Studio UI でグローバルエラー処理の例をセットアップする方法は、次のとおりです。 1. \[Error Handler\] コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ から Studio キャンバスにドラッグし、​**「allErrorHandler」**​という名前を付けます。 このコンポーネントはどのフローにも含まれません。 2. \[On Error Continue\] コンポーネントを \[Error Handler\] コンポーネントにドラッグします。 3. \[Set Payload\] コンポーネントを \[On Error Continue\] コンポーネントにドラッグします。 \[Set Payload\] コンポーネントは 1 つの例です。Logger など、他のコンポーネントを使用して、そのコンポーネント内で独自のエラーメッセージを記述することができます。Set Payload の例では、エラーの説明に Mule 変数を使用します (詳細は、​[「定義済み変数」](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​の ​`error`​ 変数を参照)。 4. Studio でグローバルエラー処理参照を作成します。 1. **\[Global Elements (グローバル要素)\]**​ をクリックして ​**\[Global Configuration Elements (グローバル設定要素)\]**​ を開きます。 **\[Global Elements (グローバル要素)\]**​ は Studio キャンバスの下にあります。 2. **\[Global Configuration Elements (グローバル設定要素)\]**​ で ​**\[Create (作成)\]**​ をクリックして ​**\[Choose Global Type (グローバル種別の選択)\]**​ ダイアログを開きます。 ![error handling global type](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-global-type.png) 3. ダイアログから ​**\[Global Configuration (グローバル設定)\]**​ -→ ​**\[Configuration (設定)\]**​ を選択し、​**\[OK\]**​ をクリックして、​**\[Configuration (設定)\]**​ ダイアログを開きます。 ![error handling global config](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/error-handling-global-config.png) 4. **\[Configuration (設定)\]**​ ダイアログから、​**\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ 項目で ​**\[allErrorHandler\]**​ を選択し、​**\[OK\]**​ をクリックします。 5. XML で記述された値を使用して、HTTP Listener および HTTP Request コンポーネントをセットアップします。 6. (Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックして、XML 設定が正しいことを確認します。 ### [](#global_error_config_ref)フローからのエラー処理設定の参照
この例の一部の要素の設定は XML のみです。
フローは、フローの外側にあるグローバルエラーハンドラーを参照できます。フローはそのすべてのエラーを、参照を介して記録します。 例: アプリケーションの XML 設定 ```xml ``` この XML の例では、グローバルエラーハンドラーは、​`loggingErrorHandler`​ という名前の ​``​ 要素を介して設定されます。フローは ​``​ を使用してエラーハンドラーを参照します。 Studio でフローからグローバルエラーハンドラー設定を参照する手順は、次のとおりです。 1. Studio で、​**\[Error Handler\]**​ コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ からキャンバスにドラッグし、UI を使用してそのコンポーネントを設定します。 2. Mule アプリケーションで、(Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックします。 3. (XML のみの設定) ​``​ 要素内で、参照の XML を入力します (例: ``​)。 次の例では、`` 要素内の ​``​ を使用してグローバル On Error Continue 要素 (​``​) を参照します。 どちらも、UI ではなく、​**\[Configuration XML (設定 XML)\]**​ を介した手動設定が必要です。 ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept) - [Raise Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/raise-error-component-reference) - [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-error-handlers) - [Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-core-exception-strategies) # エラーハンドラー Mule で発生するエラーは、次の 2 つの主要カテゴリのいずれかに分類されます。 - [システムエラー](#system_errors) - [メッセージングエラー](#messaging_errors) ## [](#system_errors)システムエラー システムレベルで例外が発生し、Mule イベントが関係していない場合、システムエラーがスローされます。システムエラーハンドラーは、次の状況で発生した例外を管理します。 - アプリケーションの起動中。 - 外部システムへの接続が失敗した場合。 システムエラーが発生すると、Mule は、登録されているリスナーにエラー通知を送信し、エラーを記録し、エラーが接続の失敗によるものであれば再接続戦略を実行します。 システムエラーハンドラーは、Mule では設定できません。 ## [](#messaging_errors)メッセージングエラー Mule イベントと Mule イベントに含まれるメッセージを処理する Mule アプリケーションのフロー内で問題が発生すると、Mule はメッセージングエラー (​[Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-error-concept)​) をスローします。 Mule メッセージングエラーは複数の方法で処理できます。 - [デフォルトのエラー処理](#default_error_handling)​メカニズムを使用できます。 - フロー内では、フローの組み込み Error Handler コンポーネント内で ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/on-error-scope-concept)​ (On Error Continue および On Error Propagate) をセットアップできます。これらのコンポーネントには、エラーを処理するための任意の数のコンポーネントを含めることができます。 次の図は、イベントプロセッサー (HTTP Request 操作やデータベース操作など) でエラーがスローされたときの動作を示しています。 ![error handling 39be7](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-39be7.png) - フロー外では、​[Error Handler](#global_error_handler)​ コンポーネントをセットアップし、そのコンポーネントを他のエラーハンドラー設定から参照できます。グローバルエラーハンドラーには、On Error コンポーネントとそのコンテンツを含めることもできます。 - エラー処理は、フローに存在する ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept)​内からセットアップすることもできます。スコープ内には組み込みエラーハンドラーが含まれ、その中で On Error コンポーネントとそのコンテンツを設定できます。 ### [](#default_error_handling)メッセージのデフォルトエラー処理の使用 デフォルトでは、未処理のメッセージングエラーは記録され、伝達されます。フローで処理されている Mule メッセージでエラーが発生すると、フローの通常の実行は停止し、プロセスがフローのデフォルトのエラーハンドラーに転送され、そのエラーハンドラーでエラーが伝達されます。 次の例は、エラーを管理するように明示的に設定したエラー処理コンポーネントを使用するのではなく、デフォルトのエラー処理を使用する簡単な Mule アプリケーション設定を示しています。 ![デフォルトのエラー処理メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-error-handling-default.png) デフォルトのエラー処理の例の XML は次のようになります。 ```xml ``` この設定で Mule アプリケーションを開始し、​`[http://0.0.0.0:8081/users](http://0.0.0.0:8081/users)`​ を (たとえばブラウザーなどに) 読み込むことで HTTP リスナーをトリガーすると、フローは、存在しないファイルに対して HTTP 要求 (​`http://jsonplaceholder.typicode.com:80/somebadrequest`​) を実行します。結果として、Anypoint Studio コンソールでエラーが記録されて Web ブラウザーに伝達されます。 - Anypoint Studio コンソールログ Studio コンソールはエラーメッセージを出力します。このメッセージは、HTTP GET 要求から返された 404 エラーがデフォルトハンドラー (​`OnErrorPropagateHandler`​) により伝達されていることを示します。Mule はこのエラーを HTTP:NOT\_FOUND​ として識別します。 ```txt ERROR 2021-01-19 18:48:50,392 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-example/processors/0; event: 1d3baf11-5aa0-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request) Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-example(error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request)) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ``` Studio コンソールのエラーログは次の情報を表します。 - **Message (メッセージ)**​: エラーの説明 - **Element (要素)**​: 実行を失敗させ、エラーの原因となった XML 要素 - **Element DSL (要素 DSL)**​: 実行を失敗させ、エラーの原因となった XML 要素。DSL 形式で表現されます。 - **Error type (エラー種別)**​: Mule アプリケーションで発生した Mule エラーの種別 - **Flowstack (フロースタック)**​: フロースタックトレースのエラーログ この項目には、Mule イベントを処理した各フローと、イベントを次のフローに送信したプロセッサーのエントリがリストされます。最後のエントリには、イベントの処理中に失敗したフローとプロセッサーが示されます。 Mule 4.3.0 以降、フロースタックエントリはデフォルトで有効になっています。フロースタックログを無効にするには、​`mule.flowTrace`​ 設定プロパティを ​`false`​ に設定することができます。 - Web ブラウザーへのエラーの伝達 HTTP:NOT\_FOUND​ エラーの説明は、リスナーをトリガーするために使用したブラウザータブに表示されます。 ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` この Mule エラーの説明は、次の 2 つの理由でブラウザーに表示されます。 - デフォルトのエラーハンドラーで On Error Propagate プロセス (​`OnErrorPropagateHandler`​) を使用しています。 On Error Propagate コンポーネントによって、フローが失敗し、HTTP リスナーで、見つからないファイルに関連付けられる ​`404`​ エラーのエラー応答が準備されます。 - HTTP リスナーでデフォルトのエラー (​`error.description`​) および成功 (​`payload`​) 応答を使用してメッセージ本文を返しています。 カスタム応答が設定されていないため、ブラウザーにエラーの説明が表示されます。 ### [](#on_error_continue)On-Error コンポーネントを使用したメッセージングエラーの処理 デフォルトのエラー処理メカニズムを使用する代わりに ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/on-error-scope-concept)​ (On Error Continue および On Error Propagate) を組み込みまたは外部の Error Handler コンポーネント内で使用できます。 次の例は、HTTP リスナーがトリガーされたときに HTTP 要求の結果を返すように Studio で設定された簡単なフローを示しています。​[デフォルトのエラー処理の例](#default_error_handling)​とは異なり、この例では、On Error Continue (​`on-error-continue`​) がフローの組み込み Error Handler (​`error-handler`​) コンポーネント内で設定され、On Error Continue には、エラーの説明を書き込む Logger が含まれます。 ![mruntime on error continue](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-on-error-continue.png) この例の XML は次のようになります。 ```xml ``` デフォルトのエラー処理の例と同様に、要求されたページが見つからないため、フローは 404 エラーを返し、Mule はこのエラーを HTTP:NOT\_FOUND​ エラーとして識別します。 ただし、このケースでは、エラーが伝達されないため、HTTP リスナーをトリガーするために使用したブラウザーのタブは空白になります。On Error Continue を使用すると、例のフローは、ページが見つからなくても、GET 要求の 200 と共に正常終了したかのように処理されます。HTTP リスナーはデフォルトの成功応答の動作 (メッセージ本文として ​`payload`​ コンテンツを返す) を実行します。ページが見つからなかったため、ブラウザーに表示するコンテンツはありません。このため、ブラウザータブは空白になります。 Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージ (以下の 1 番目の ERROR メッセージ) も出力されます。また、Mule エラーについて説明する (​`error.description`​。​[「Mule エラーのセレクター式」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-error-concept#selector_expressions)​を参照)、ロガーからの ERROR メッセージ (以下の 2 番目の ERROR) が出力されます。 ```txt ERROR 2021-01-19 18:42:04,583 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorContinueHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15 Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-normalFlow(error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ERROR 2021-01-19 18:42:04,586 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/errorHandler/0/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` On Error Continue (​`on-error-continue`​) の代わりに On Error Propagate (​`on-error-propagate`​) を使用して同じ Mule アプリケーションを作成した場合、同じエラーメッセージが Studio コンソールに表示されますが、記録されたエラーメッセージがブラウザーにも表示されます。この動作はデフォルトのエラー処理動作と同じです。どちらも On Error Propagate を使用するためです。 各 On Error コンポーネント内で、定義するエラーパスには任意の数のイベントプロセッサーを組み込むことができるため、特定のエラー種別を必要なだけ正確に処理できます。On-Error コンポーネントで処理する特定の Mule エラーを選択できます。Error Handler コンポーネントは、エラーに一致する最初の On Error コンポーネントにエラーを転送します。 フローレベルでのより複雑なエラー処理設定については、​[「Mule 4 の概要: エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-error-handlers)​を参照してください。 On Error Continue および On Error Propagate についての詳細は、​[「On-Error コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.5/on-error-scope-concept)​を参照してください。 ### [](#global_error_handler)グローバルエラーハンドラーの参照 グローバルエラーハンドラーは、同じ方法でエラーを処理する複数のフローまたは Try スコープが必要な場合に役立つ可能性があります。エラーハンドラーへの参照を提供することで、再利用設定を作成できます。 - [グローバルエラー処理設定の定義](#global_error_config_set) - [フローからのエラー処理設定の参照](#global_error_config_ref) #### [](#global_error_config_set)グローバルエラー処理設定の定義 次の XML 設定では、​``​ を使用して ​``​ 設定を参照するデフォルトのエラー処理設定を定義します。 ```xml ``` Studio UI では、グローバルエラー処理の例は次のようになります。 ![error handlers global](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handlers-global.png) この例には、エラーを処理するための 2 つの主要なコンポーネントが含まれます。Studio キャンバスに表示される埋め込みコンポーネントを含む Error Handler (​`error-handler`​) と、キャンバスに表示されないグローバルエラー処理設定です。 UI の例のフロー (​**someFlow**​) は、Error Handler コンポーネントが Mule アプリケーションのフローの外側にあることを示しています。 要求により HTTP:NOT\_FOUND​ エラーが生成されるため、Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージが出力されます。 On Error Continue 設定では、処理するエラーが伝達されません (​[On-Error コンポーネントを使用したメッセージングエラーの処理](#on_error_continue)​ を参照)。 XML マークアップで設定を記述する代わりに Studio UI でグローバルエラー処理の例をセットアップする方法は、次のとおりです。 1. \[Error Handler\] コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ から Studio キャンバスにドラッグし、​**「allErrorHandler」**​という名前を付けます。 このコンポーネントはどのフローにも含まれません。 2. \[On Error Continue\] コンポーネントを \[Error Handler\] コンポーネントにドラッグします。 3. \[Set Payload\] コンポーネントを \[On Error Continue\] コンポーネントにドラッグします。 \[Set Payload\] コンポーネントは 1 つの例です。Logger など、他のコンポーネントを使用して、そのコンポーネント内で独自のエラーメッセージを記述することができます。Set Payload の例では、エラーの説明に Mule 変数を使用します (詳細は、​[「定義済み変数」](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​の ​`error`​ 変数を参照)。 4. Studio でグローバルエラー処理参照を作成します。 1. **\[Global Elements (グローバル要素)\]**​ をクリックして ​**\[Global Configuration Elements (グローバル設定要素)\]**​ を開きます。 **\[Global Elements (グローバル要素)\]**​ は Studio キャンバスの下にあります。 2. **\[Global Configuration Elements (グローバル設定要素)\]**​ で ​**\[Create (作成)\]**​ をクリックして ​**\[Choose Global Type (グローバル種別の選択)\]**​ ダイアログを開きます。 ![error handling global type](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-global-type.png) 3. ダイアログから ​**\[Global Configuration (グローバル設定)\]**​ -→ ​**\[Configuration (設定)\]**​ を選択し、​**\[OK\]**​ をクリックして、​**\[Configuration (設定)\]**​ ダイアログを開きます。 ![error handling global config](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/error-handling-global-config.png) 4. **\[Configuration (設定)\]**​ ダイアログから、​**\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ 項目で ​**\[allErrorHandler\]**​ を選択し、​**\[OK\]**​ をクリックします。 5. XML で記述された値を使用して、HTTP Listener および HTTP Request コンポーネントをセットアップします。 6. (Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックして、XML 設定が正しいことを確認します。 ### [](#global_error_config_ref)フローからのエラー処理設定の参照
この例の一部の要素の設定は XML のみです。
フローは、フローの外側にあるグローバルエラーハンドラーを参照できます。フローはそのすべてのエラーを、参照を介して記録します。 例: アプリケーションの XML 設定 ```xml ``` この XML の例では、グローバルエラーハンドラーは、​`loggingErrorHandler`​ という名前の ​``​ 要素を介して設定されます。フローは ​``​ を使用してエラーハンドラーを参照します。 Studio でフローからグローバルエラーハンドラー設定を参照する手順は、次のとおりです。 1. Studio で、​**\[Error Handler\]**​ コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ からキャンバスにドラッグし、UI を使用してそのコンポーネントを設定します。 2. Mule アプリケーションで、(Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックします。 3. (XML のみの設定) ​``​ 要素内で、参照の XML を入力します (例: ``​)。 次の例では、​``​ 要素内の ​``​ を使用してグローバル On Error Continue 要素 (​``​) を参照します。 どちらも、UI ではなく、​**\[Configuration XML (設定 XML)\]**​ を介した手動設定が必要です。 ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept) - [Raise Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/raise-error-component-reference) - [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-error-handlers) - [Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-core-exception-strategies) # エラーハンドラー Mule で発生するエラーは、次の 2 つの主要カテゴリのいずれかに分類されます。 - [システムエラー](#system_errors) - [メッセージングエラー](#messaging_errors) ## [](#system_errors)システムエラー システムレベルで例外が発生し、Mule イベントが関係していない場合、システムエラーがスローされます。システムエラーハンドラーは、次の状況で発生した例外を管理します。 - アプリケーションの起動中。 - 外部システムへの接続が失敗した場合。 システムエラーが発生すると、Mule は、登録されているリスナーにエラー通知を送信し、エラーを記録し、エラーが接続の失敗によるものであれば再接続戦略を実行します。 システムエラーハンドラーは、Mule では設定できません。 ## [](#messaging_errors)メッセージングエラー Mule イベントと Mule イベントに含まれるメッセージを処理する Mule アプリケーションのフロー内で問題が発生すると、Mule はメッセージングエラー (​[Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-error-concept)​) をスローします。 Mule メッセージングエラーは複数の方法で処理できます。 - [デフォルトのエラー処理](#default_error_handling)​メカニズムを使用できます。 - フロー内では、フローの組み込み Error Handler コンポーネント内で ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/on-error-scope-concept)​ (On Error Continue および On Error Propagate) をセットアップできます。これらのコンポーネントには、エラーを処理するための任意の数のコンポーネントを含めることができます。 次の図は、イベントプロセッサー (HTTP Request 操作やデータベース操作など) でエラーがスローされたときの動作を示しています。 ![error handling 39be7](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-39be7.png) - フロー外では、​[Error Handler](#global_error_handler)​ コンポーネントをセットアップし、そのコンポーネントを他のエラーハンドラー設定から参照できます。グローバルエラーハンドラーには、On Error コンポーネントとそのコンテンツを含めることもできます。 - エラー処理は、フローに存在する ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept)​内からセットアップすることもできます。スコープ内には組み込みエラーハンドラーが含まれ、その中で On Error コンポーネントとそのコンテンツを設定できます。 ### [](#default_error_handling)メッセージのデフォルトエラー処理の使用 デフォルトでは、未処理のメッセージングエラーは記録され、伝達されます。フローで処理されている Mule メッセージでエラーが発生すると、フローの通常の実行は停止し、プロセスがフローのデフォルトのエラーハンドラーに転送され、そのエラーハンドラーでエラーが伝達されます。 次の例は、エラーを管理するように明示的に設定したエラー処理コンポーネントを使用するのではなく、デフォルトのエラー処理を使用する簡単な Mule アプリケーション設定を示しています。 ![デフォルトのエラー処理メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-error-handling-default.png) デフォルトのエラー処理の例の XML は次のようになります。 ```xml ``` この設定で Mule アプリケーションを開始し、​`[http://0.0.0.0:8081/users](http://0.0.0.0:8081/users)`​ を (たとえばブラウザーなどに) 読み込むことで HTTP リスナーをトリガーすると、フローは、存在しないファイルに対して HTTP 要求 (​`http://jsonplaceholder.typicode.com:80/somebadrequest`​) を実行します。結果として、Anypoint Studio コンソールでエラーが記録されて Web ブラウザーに伝達されます。 - Anypoint Studio コンソールログ Studio コンソールはエラーメッセージを出力します。このメッセージは、HTTP GET 要求から返された 404 エラーがデフォルトハンドラー (​`OnErrorPropagateHandler`​) により伝達されていることを示します。Mule はこのエラーを HTTP:NOT\_FOUND​ として識別します。 ```txt ERROR 2021-01-19 18:48:50,392 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-example/processors/0; event: 1d3baf11-5aa0-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request) Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-example(error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request)) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ``` Studio コンソールのエラーログは次の情報を表します。 - **Message (メッセージ)**​: エラーの説明 - **Element (要素)**​: 実行を失敗させ、エラーの原因となった XML 要素 - **Element DSL (要素 DSL)**​: 実行を失敗させ、エラーの原因となった XML 要素。DSL 形式で表現されます。 - **Error type (エラー種別)**​: Mule アプリケーションで発生した Mule エラーの種別 - **Flowstack (フロースタック)**​: フロースタックトレースのエラーログ この項目には、Mule イベントを処理した各フローと、イベントを次のフローに送信したプロセッサーのエントリがリストされます。最後のエントリには、イベントの処理中に失敗したフローとプロセッサーが示されます。 Mule 4.3.0 以降、フロースタックエントリはデフォルトで有効になっています。フロースタックログを無効にするには、​`mule.flowTrace`​ 設定プロパティを ​`false`​ に設定することができます。 - Web ブラウザーへのエラーの伝達 HTTP:NOT\_FOUND​ エラーの説明は、リスナーをトリガーするために使用したブラウザータブに表示されます。 ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` この Mule エラーの説明は、次の 2 つの理由でブラウザーに表示されます。 - デフォルトのエラーハンドラーで On Error Propagate プロセス (​`OnErrorPropagateHandler`​) を使用しています。 On Error Propagate コンポーネントによって、フローが失敗し、HTTP リスナーで、見つからないファイルに関連付けられる ​`404`​ エラーのエラー応答が準備されます。 - HTTP リスナーでデフォルトのエラー (​`error.description`​) および成功 (​`payload`​) 応答を使用してメッセージ本文を返しています。 カスタム応答が設定されていないため、ブラウザーにエラーの説明が表示されます。 ### [](#on_error_continue)On-Error コンポーネントを使用したメッセージングエラーの処理 デフォルトのエラー処理メカニズムを使用する代わりに ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/on-error-scope-concept)​ (On Error Continue および On Error Propagate) を組み込みまたは外部の Error Handler コンポーネント内で使用できます。 次の例は、HTTP リスナーがトリガーされたときに HTTP 要求の結果を返すように Studio で設定された簡単なフローを示しています。​[デフォルトのエラー処理の例](#default_error_handling)​とは異なり、この例では、On Error Continue (​`on-error-continue`​) がフローの組み込み Error Handler (​`error-handler`​) コンポーネント内で設定され、On Error Continue には、エラーの説明を書き込む Logger が含まれます。 ![mruntime on error continue](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-on-error-continue.png) この例の XML は次のようになります。 ```xml ``` デフォルトのエラー処理の例と同様に、要求されたページが見つからないため、フローは 404 エラーを返し、Mule はこのエラーを HTTP:NOT\_FOUND​ エラーとして識別します。 ただし、このケースでは、エラーが伝達されないため、HTTP リスナーをトリガーするために使用したブラウザーのタブは空白になります。On Error Continue を使用すると、例のフローは、ページが見つからなくても、GET 要求の 200 と共に正常終了したかのように処理されます。HTTP リスナーはデフォルトの成功応答の動作 (メッセージ本文として ​`payload`​ コンテンツを返す) を実行します。ページが見つからなかったため、ブラウザーに表示するコンテンツはありません。このため、ブラウザータブは空白になります。 Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージ (以下の 1 番目の ERROR メッセージ) も出力されます。また、Mule エラーについて説明する (​`error.description`​。​[「Mule エラーのセレクター式」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-error-concept#selector_expressions)​を参照)、ロガーからの ERROR メッセージ (以下の 2 番目の ERROR) が出力されます。 ```txt ERROR 2021-01-19 18:42:04,583 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorContinueHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15 Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-normalFlow(error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ERROR 2021-01-19 18:42:04,586 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/errorHandler/0/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` On Error Continue (​`on-error-continue`​) の代わりに On Error Propagate (​`on-error-propagate`​) を使用して同じ Mule アプリケーションを作成した場合、同じエラーメッセージが Studio コンソールに表示されますが、記録されたエラーメッセージがブラウザーにも表示されます。この動作はデフォルトのエラー処理動作と同じです。どちらも On Error Propagate を使用するためです。 各 On Error コンポーネント内で、定義するエラーパスには任意の数のイベントプロセッサーを組み込むことができるため、特定のエラー種別を必要なだけ正確に処理できます。On-Error コンポーネントで処理する特定の Mule エラーを選択できます。Error Handler コンポーネントは、エラーに一致する最初の On Error コンポーネントにエラーを転送します。 フローレベルでのより複雑なエラー処理設定については、​[「Mule 4 の概要: エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-error-handlers)​を参照してください。 On Error Continue および On Error Propagate についての詳細は、​[「On-Error コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.6/on-error-scope-concept)​を参照してください。 ### [](#global_error_handler)グローバルエラーハンドラーの参照 グローバルエラーハンドラーは、同じ方法でエラーを処理する複数のフローまたは Try スコープが必要な場合に役立つ可能性があります。エラーハンドラーへの参照を提供することで、再利用設定を作成できます。 - [グローバルエラー処理設定の定義](#global_error_config_set) - [フローからのエラー処理設定の参照](#global_error_config_ref) #### [](#global_error_config_set)グローバルエラー処理設定の定義 次の XML 設定では、​``​ を使用して ​``​ 設定を参照するデフォルトのエラー処理設定を定義します。 ```xml ``` Studio UI では、グローバルエラー処理の例は次のようになります。 ![error handlers global](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handlers-global.png) この例には、エラーを処理するための 2 つの主要なコンポーネントが含まれます。Studio キャンバスに表示される埋め込みコンポーネントを含む Error Handler (​`error-handler`​) と、キャンバスに表示されないグローバルエラー処理設定です。 UI の例のフロー (​**someFlow**​) は、Error Handler コンポーネントが Mule アプリケーションのフローの外側にあることを示しています。 要求により HTTP:NOT\_FOUND​ エラーが生成されるため、Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージが出力されます。 On Error Continue 設定では、処理するエラーが伝達されません (​[On-Error コンポーネントを使用したメッセージングエラーの処理](#on_error_continue)​を参照)。 XML マークアップで設定を記述する代わりに Studio UI でグローバルエラー処理の例をセットアップする方法は、次のとおりです。 1. \[Error Handler\] コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ から Studio キャンバスにドラッグし、​**「allErrorHandler」**​という名前を付けます。 このコンポーネントはどのフローにも含まれません。 2. \[On Error Continue\] コンポーネントを \[Error Handler\] コンポーネントにドラッグします。 3. \[Set Payload\] コンポーネントを \[On Error Continue\] コンポーネントにドラッグします。 \[Set Payload\] コンポーネントは 1 つの例です。Logger など、他のコンポーネントを使用して、そのコンポーネント内で独自のエラーメッセージを記述することができます。Set Payload の例では、エラーの説明に Mule 変数を使用します (詳細は、​[「定義済み変数」](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​の ​`error`​ 変数を参照)。 4. Studio でグローバルエラー処理参照を作成します。 1. **\[Global Elements (グローバル要素)\]**​ をクリックして ​**\[Global Configuration Elements (グローバル設定要素)\]**​ を開きます。 **\[Global Elements (グローバル要素)\]**​ は Studio キャンバスの下にあります。 2. **\[Global Configuration Elements (グローバル設定要素)\]**​ で ​**\[Create (作成)\]**​ をクリックして ​**\[Choose Global Type (グローバル種別の選択)\]**​ ダイアログを開きます。 ![error handling global type](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-global-type.png) 3. ダイアログから ​**\[Global Configuration (グローバル設定)\]**​ -→ ​**\[Configuration (設定)\]**​ を選択し、​**\[OK\]**​ をクリックして、​**\[Configuration (設定)\]**​ ダイアログを開きます。 ![error handling global config](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/error-handling-global-config.png) 4. **\[Configuration (設定)\]**​ ダイアログから、​**\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ 項目で ​**\[allErrorHandler\]**​ を選択し、​**\[OK\]**​ をクリックします。 5. XML で記述された値を使用して、HTTP Listener および HTTP Request コンポーネントをセットアップします。 6. (Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックして、XML 設定が正しいことを確認します。 ### [](#global_error_config_ref)フローからのエラー処理設定の参照
この例の一部の要素の設定は XML のみです。
フローは、フローの外側にあるグローバルエラーハンドラーを参照できます。フローはそのすべてのエラーを、参照を介して記録します。 例: アプリケーションの XML 設定 ```xml ``` この XML の例では、グローバルエラーハンドラーは、​`loggingErrorHandler`​ という名前の ​``​ 要素を介して設定されます。フローは ​``​ を使用してエラーハンドラーを参照します。 Studio でフローからグローバルエラーハンドラー設定を参照する手順は、次のとおりです。 1. Studio で、​**\[Error Handler\]**​ コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ からキャンバスにドラッグし、UI を使用してそのコンポーネントを設定します。 2. Mule アプリケーションで、(Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックします。 3. (XML のみの設定) ​``​ 要素内で、参照の XML を入力します (例: ``​)。 次の例では、`` 要素内の ​``​ を使用してグローバル On Error Continue 要素 (​``​) を参照します。 どちらも、UI ではなく、​**\[Configuration XML (設定 XML)\]**​ を介した手動設定が必要です。 ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept) - [Raise Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/raise-error-component-reference) - [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-error-handlers) - [Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-core-exception-strategies) # エラーハンドラー Mule で発生するエラーは、次の 2 つの主要カテゴリのいずれかに分類されます。 - [システムエラー](#system_errors) - [メッセージングエラー](#messaging_errors) ## [](#system_errors)システムエラー システムレベルで例外が発生し、Mule イベントが関係していない場合、システムエラーがスローされます。システムエラーハンドラーは、次の状況で発生した例外を管理します。 - アプリケーションの起動中。 - 外部システムへの接続が失敗した場合。 システムエラーが発生すると、Mule は、登録されているリスナーにエラー通知を送信し、エラーを記録し、エラーが接続の失敗によるものであれば再接続戦略を実行します。 システムエラーハンドラーは、Mule では設定できません。 ## [](#messaging_errors)メッセージングエラー Mule イベントと Mule イベントに含まれるメッセージを処理する Mule アプリケーションのフロー内で問題が発生すると、Mule はメッセージングエラー (​[Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-error-concept)​) をスローします。 Mule メッセージングエラーは複数の方法で処理できます。 - [デフォルトのエラー処理](#default_error_handling)​メカニズムを使用できます。 - フロー内では、フローの組み込み Error Handler コンポーネント内で ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/on-error-scope-concept)​ (On Error Continue および On Error Propagate) をセットアップできます。これらのコンポーネントには、エラーを処理するための任意の数のコンポーネントを含めることができます。 次の図は、イベントプロセッサー (HTTP Request 操作やデータベース操作など) でエラーがスローされたときの動作を示しています。 ![複数のイベントプロセッサーとエラー処理コンポーネントが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-39be7.png) - フロー外では、​[Error Handler](#global_error_handler)​ コンポーネントをセットアップし、そのコンポーネントを他のエラーハンドラー設定から参照できます。グローバルエラーハンドラーには、On Error コンポーネントとそのコンテンツを含めることもできます。 - エラー処理は、フローに存在する ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept)​内からセットアップすることもできます。スコープ内には組み込みエラーハンドラーが含まれ、その中で On Error コンポーネントとそのコンテンツを設定できます。 ### [](#default_error_handling)メッセージのデフォルトエラー処理の使用 デフォルトでは、未処理のメッセージングエラーは記録され、伝達されます。フローで処理されている Mule メッセージでエラーが発生すると、フローの通常の実行は停止し、プロセスがフローのデフォルトのエラーハンドラーに転送され、そのエラーハンドラーでエラーが伝達されます。 次の例は、エラーを管理するように明示的に設定したエラー処理コンポーネントを使用するのではなく、デフォルトのエラー処理を使用する簡単な Mule アプリケーション設定を示しています。 ![デフォルトのエラー処理メッセージ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-error-handling-default.png) デフォルトのエラー処理の例の XML は次のようになります。 ```xml ``` この設定で Mule アプリケーションを開始し、​`[http://0.0.0.0:8081/users](http://0.0.0.0:8081/users)`​ を (たとえばブラウザーなどに) 読み込むことで HTTP リスナーをトリガーすると、フローは、存在しないファイルに対して HTTP 要求 (​`http://jsonplaceholder.typicode.com:80/somebadrequest`​) を実行します。結果として、Anypoint Studio コンソールでエラーが記録されて Web ブラウザーに伝達されます。 - Anypoint Studio コンソールログ Studio コンソールはエラーメッセージを出力します。このメッセージは、HTTP GET 要求から返された 404 エラーがデフォルトハンドラー (​`OnErrorPropagateHandler`​) により伝達されていることを示します。Mule はこのエラーを HTTP:NOT\_FOUND​ として識別します。 ```txt ERROR 2021-01-19 18:48:50,392 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-example/processors/0; event: 1d3baf11-5aa0-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request) Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-example(error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request)) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ``` Studio コンソールのエラーログは次の情報を表します。 - **Message (メッセージ)**​: エラーの説明 - **Element (要素)**​: 実行を失敗させ、エラーの原因となった XML 要素 - **Element DSL (要素 DSL)**​: 実行を失敗させ、エラーの原因となった XML 要素。DSL 形式で表現されます。 - **Error type (エラー種別)**​: Mule アプリケーションで発生した Mule エラーの種別 - **Flowstack (フロースタック)**​: フロースタックトレースのエラーログ この項目には、Mule イベントを処理した各フローと、イベントを次のフローに送信したプロセッサーのエントリがリストされます。最後のエントリには、イベントの処理中に失敗したフローとプロセッサーが示されます。 Mule 4.3.0 以降、フロースタックエントリはデフォルトで有効になっています。フロースタックログを無効にするには、​`mule.flowTrace`​ 設定プロパティを ​`false`​ に設定することができます。 - Web ブラウザーへのエラーの伝達 HTTP:NOT\_FOUND​ エラーの説明は、リスナーをトリガーするために使用したブラウザータブに表示されます。 ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` この Mule エラーの説明は、次の 2 つの理由でブラウザーに表示されます。 - デフォルトのエラーハンドラーで On Error Propagate プロセス (​`OnErrorPropagateHandler`​) を使用しています。 On Error Propagate コンポーネントによって、フローが失敗し、HTTP リスナーで、見つからないファイルに関連付けられる ​`404`​ エラーのエラー応答が準備されます。 - HTTP リスナーでデフォルトのエラー (​`error.description`​) および成功 (​`payload`​) 応答を使用してメッセージ本文を返しています。 カスタム応答が設定されていないため、ブラウザーにエラーの説明が表示されます。 ### [](#on_error_continue)On-Error コンポーネントを使用したメッセージングエラーの処理 デフォルトのエラー処理メカニズムを使用する代わりに ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/on-error-scope-concept)​ (On Error Continue および On Error Propagate) を組み込みまたは外部の Error Handler コンポーネント内で使用できます。 次の例は、HTTP リスナーがトリガーされたときに HTTP 要求の結果を返すように Studio で設定された簡単なフローを示しています。​[デフォルトのエラー処理の例](#default_error_handling)​とは異なり、この例では、On Error Continue (​`on-error-continue`​) がフローの組み込み Error Handler (​`error-handler`​) コンポーネント内で設定され、On Error Continue には、エラーの説明を書き込む Logger が含まれます。 ![mruntime on error continue](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-on-error-continue.png) この例の XML は次のようになります。 ```xml ``` デフォルトのエラー処理の例と同様に、要求されたページが見つからないため、フローは 404 エラーを返し、Mule はこのエラーを HTTP:NOT\_FOUND​ エラーとして識別します。 ただし、このケースでは、エラーが伝達されないため、HTTP リスナーをトリガーするために使用したブラウザーのタブは空白になります。On Error Continue を使用すると、例のフローは、ページが見つからなくても、GET 要求の 200 と共に正常終了したかのように処理されます。HTTP リスナーはデフォルトの成功応答の動作 (メッセージ本文として ​`payload`​ コンテンツを返す) を実行します。ページが見つからなかったため、ブラウザーに表示するコンテンツはありません。このため、ブラウザータブは空白になります。 Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージ (以下の 1 番目の ERROR メッセージ) も出力されます。また、Mule エラーについて説明する (​`error.description`​。​[「Mule エラーのセレクター式」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-error-concept#selector_expressions)​を参照)、ロガーからの ERROR メッセージ (以下の 2 番目の ERROR) が出力されます。 ```txt ERROR 2021-01-19 18:42:04,583 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorContinueHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15 Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-normalFlow(error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ERROR 2021-01-19 18:42:04,586 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/errorHandler/0/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` On Error Continue (​`on-error-continue`​) の代わりに On Error Propagate (​`on-error-propagate`​) を使用して同じ Mule アプリケーションを作成した場合、同じエラーメッセージが Studio コンソールに表示されますが、記録されたエラーメッセージがブラウザーにも表示されます。この動作はデフォルトのエラー処理動作と同じです。どちらも On Error Propagate を使用するためです。 各 On Error コンポーネント内で、定義するエラーパスには任意の数のイベントプロセッサーを組み込むことができるため、特定のエラー種別を必要なだけ正確に処理できます。On-Error コンポーネントで処理する特定の Mule エラーを選択できます。Error Handler コンポーネントは、エラーに一致する最初の On Error コンポーネントにエラーを転送します。 フローレベルでのより複雑なエラー処理設定については、​[「Mule 4 の概要: エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-error-handlers)​を参照してください。 On Error Continue および On Error Propagate についての詳細は、​[「On-Error コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.7/on-error-scope-concept)​を参照してください。 ### [](#global_error_handler)グローバルエラーハンドラーの参照 グローバルエラーハンドラーは、同じ方法でエラーを処理する複数のフローまたは Try スコープが必要な場合に役立つ可能性があります。エラーハンドラーへの参照を提供することで、再利用設定を作成できます。 - [グローバルエラー処理設定の定義](#global_error_config_set) - [フローからのエラー処理設定の参照](#global_error_config_ref) #### [](#global_error_config_set)グローバルエラー処理設定の定義 次の XML 設定では、​``​ を使用して ​``​ 設定を参照するデフォルトのエラー処理設定を定義します。 ```xml ``` Studio UI では、グローバルエラー処理の例は次のようになります。 ![グローバルエラーハンドラー設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handlers-global.png) この例には、エラーを処理するための 2 つの主要なコンポーネントが含まれます。Studio キャンバスに表示される埋め込みコンポーネントを含む Error Handler (​`error-handler`​) と、キャンバスに表示されないグローバルエラー処理設定です。 UI の例のフロー (​**someFlow**​) は、Error Handler コンポーネントが Mule アプリケーションのフローの外側にあることを示しています。 要求により HTTP:NOT\_FOUND​ エラーが生成されるため、Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージが出力されます。 On Error Continue 設定では、処理するエラーが伝達されません (​[On-Error コンポーネントを使用したメッセージングエラーの処理](#on_error_continue)​を参照)。 XML マークアップで設定を記述する代わりに Studio UI でグローバルエラー処理の例をセットアップする方法は、次のとおりです。 1. \[Error Handler\] コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ から Studio キャンバスにドラッグし、​**「allErrorHandler」**​という名前を付けます。 このコンポーネントはどのフローにも含まれません。 2. \[On Error Continue\] コンポーネントを \[Error Handler\] コンポーネントにドラッグします。 3. \[Set Payload\] コンポーネントを \[On Error Continue\] コンポーネントにドラッグします。 \[Set Payload\] コンポーネントは 1 つの例です。Logger など、他のコンポーネントを使用して、そのコンポーネント内で独自のエラーメッセージを記述することができます。Set Payload の例では、エラーの説明に Mule 変数を使用します (詳細は、​[「定義済み変数」](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​の ​`error`​ 変数を参照)。 4. Studio でグローバルエラー処理参照を作成します。 1. **\[Global Elements (グローバル要素)\]**​ をクリックして ​**\[Global Configuration Elements (グローバル設定要素)\]**​ を開きます。 **\[Global Elements (グローバル要素)\]**​ は Studio キャンバスの下にあります。 2. **\[Global Configuration Elements (グローバル設定要素)\]**​ で ​**\[Create (作成)\]**​ をクリックして ​**\[Choose Global Type (グローバル種別の選択)\]**​ ダイアログを開きます。 ![\[Configuration (設定)\] などのグローバル要素種別を選択する設定パネル](_images/error-handling-global-type.png) 3. ダイアログから ​**\[Global Configuration (グローバル設定)\]**​ -→ ​**\[Configuration (設定)\]**​ を選択し、​**\[OK\]**​ をクリックして、​**\[Configuration (設定)\]**​ ダイアログを開きます。 ![\[Configuration (設定)\] ダイアログの \[General (一般)\] 項目 (\[Settings (設定)\] など)](_images/error-handling-global-config.png) 4. **\[Configuration (設定)\]**​ ダイアログから、​**\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ 項目で ​**\[allErrorHandler\]**​ を選択し、​**\[OK\]**​ をクリックします。 5. XML で記述された値を使用して、HTTP Listener および HTTP Request コンポーネントをセットアップします。 6. (Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックして、XML 設定が正しいことを確認します。 ### [](#global_error_config_ref)フローからのエラー処理設定の参照
この例の一部の要素の設定は XML のみです。
フローは、フローの外側にあるグローバルエラーハンドラーを参照できます。フローはそのすべてのエラーを、参照を介して記録します。 例: アプリケーションの XML 設定 ```xml ``` この XML の例では、グローバルエラーハンドラーは、​`loggingErrorHandler`​ という名前の ​``​ 要素を介して設定されます。フローは ​``​ を使用してエラーハンドラーを参照します。 Studio でフローからグローバルエラーハンドラー設定を参照する手順は、次のとおりです。 1. Studio で、​**\[Error Handler\]**​ コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ からキャンバスにドラッグし、UI を使用してそのコンポーネントを設定します。 2. Mule アプリケーションで、(Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックします。 3. (XML のみの設定) ​``​ 要素内で、参照の XML を入力します (例: ``​)。 次の例では、​``​ 要素内の ​``​ を使用してグローバル On Error Continue 要素 (​``​) を参照します。 どちらも、UI ではなく、​**\[Configuration XML (設定 XML)\]**​ を介した手動設定が必要です。 ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept) - [Raise Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/raise-error-component-reference) - [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-error-handlers) - [Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-core-exception-strategies) # エラーハンドラー Mule で発生するエラーは、次の 2 つの主要カテゴリのいずれかに分類されます。 - [システムエラー](#system_errors) - [メッセージングエラー](#messaging_errors) ## [](#system_errors)システムエラー システムレベルで例外が発生し、Mule イベントが関係していない場合、システムエラーがスローされます。システムエラーハンドラーは、次の状況で発生した例外を管理します。 - アプリケーションの起動中。 - 外部システムへの接続が失敗した場合。 システムエラーが発生すると、Mule は、登録されているリスナーにエラー通知を送信し、エラーを記録し、エラーが接続の失敗によるものであれば再接続戦略を実行します。 システムエラーハンドラーは、Mule では設定できません。 ## [](#messaging_errors)メッセージングエラー Mule イベントと Mule イベントに含まれるメッセージを処理する Mule アプリケーションのフロー内で問題が発生すると、Mule はメッセージングエラー (​[Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-error-concept)​) をスローします。 Mule メッセージングエラーは複数の方法で処理できます。 - [デフォルトのエラー処理](#default_error_handling)​メカニズムを使用できます。 - フロー内では、フローの組み込み Error Handler コンポーネント内で ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/on-error-scope-concept)​ (On Error Continue および On Error Propagate) をセットアップできます。これらのコンポーネントには、エラーを処理するための任意の数のコンポーネントを含めることができます。 次の図は、イベントプロセッサー (HTTP Request 操作やデータベース操作など) でエラーがスローされたときの動作を示しています。 ![複数のイベントプロセッサーとエラー処理コンポーネントが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-handling-39be7.png) - フロー外では、​[Error Handler](#global_error_handler)​ コンポーネントをセットアップし、そのコンポーネントを他のエラーハンドラー設定から参照できます。グローバルエラーハンドラーには、On Error コンポーネントとそのコンテンツを含めることもできます。 - エラー処理は、フローに存在する ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept)​内からセットアップすることもできます。スコープ内には組み込みエラーハンドラーが含まれ、その中で On Error コンポーネントとそのコンテンツを設定できます。 ### [](#default_error_handling)メッセージのデフォルトエラー処理の使用 デフォルトでは、未処理のメッセージングエラーは記録され、伝達されます。フローで処理されている Mule メッセージでエラーが発生すると、フローの通常の実行は停止し、プロセスがフローのデフォルトのエラーハンドラーに転送され、そのエラーハンドラーでエラーが伝達されます。 次の例は、エラーを管理するように明示的に設定したエラー処理コンポーネントを使用するのではなく、デフォルトのエラー処理を使用する簡単な Mule アプリケーション設定を示しています。 ![Mule アプリケーションの HTTP 要求の失敗に起因するエラーメッセージ表示](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-error-handling-default.png) デフォルトのエラー処理の例の XML は次のようになります。 ```xml ``` この設定で Mule アプリケーションを開始し、​`[http://0.0.0.0:8081/users](http://0.0.0.0:8081/users)`​ を (たとえばブラウザーなどに) 読み込むことで HTTP リスナーをトリガーすると、フローは、存在しないファイルに対して HTTP 要求 (​`http://jsonplaceholder.typicode.com:80/somebadrequest`​) を実行します。結果として、Anypoint Studio コンソールでエラーが記録されて Web ブラウザーに伝達されます。 - Anypoint Studio コンソールログ Studio コンソールはエラーメッセージを出力します。このメッセージは、HTTP GET 要求から返された 404 エラーがデフォルトハンドラー (​`OnErrorPropagateHandler`​) により伝達されていることを示します。Mule はこのエラーを HTTP:NOT\_FOUND​ として識別します。 ```txt ERROR 2021-01-19 18:48:50,392 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-example/processors/0; event: 1d3baf11-5aa0-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request) Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-example(error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request)) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ``` Studio コンソールのエラーログは次の情報を表します。 - **Message (メッセージ)**​: エラーの説明 - **Element (要素)**​: 実行を失敗させ、エラーの原因となった XML 要素 - **Element DSL (要素 DSL)**​: 実行を失敗させ、エラーの原因となった XML 要素。DSL 形式で表現されます。 - **Error type (エラー種別)**​: Mule アプリケーションで発生した Mule エラーの種別 - **Flowstack (フロースタック)**​: フロースタックトレースのエラーログ この項目には、Mule イベントを処理した各フローと、イベントを次のフローに送信したプロセッサーのエントリがリストされます。最後のエントリには、イベントの処理中に失敗したフローとプロセッサーが示されます。 Mule 4.3.0 以降、フロースタックエントリはデフォルトで有効になっています。フロースタックログを無効にするには、​`mule.flowTrace`​ 設定プロパティを ​`false`​ に設定することができます。 - Web ブラウザーへのエラーの伝達 HTTP:NOT\_FOUND​ エラーの説明は、リスナーをトリガーするために使用したブラウザータブに表示されます。 ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` この Mule エラーの説明は、次の 2 つの理由でブラウザーに表示されます。 - デフォルトのエラーハンドラーで On Error Propagate プロセス (​`OnErrorPropagateHandler`​) を使用しています。 On Error Propagate コンポーネントによって、フローが失敗し、HTTP リスナーで、見つからないファイルに関連付けられる ​`404`​ エラーのエラー応答が準備されます。 - HTTP リスナーでデフォルトのエラー (​`error.description`​) および成功 (​`payload`​) 応答を使用してメッセージ本文を返しています。 カスタム応答が設定されていないため、ブラウザーにエラーの説明が表示されます。 ### [](#on_error_continue)On-Error コンポーネントを使用したメッセージングエラーの処理 デフォルトのエラー処理メカニズムを使用する代わりに ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/on-error-scope-concept)​ (On Error Continue および On Error Propagate) を組み込みまたは外部の Error Handler コンポーネント内で使用できます。 次の例は、HTTP リスナーがトリガーされたときに HTTP 要求の結果を返すように Studio で設定された簡単なフローを示しています。​[デフォルトのエラー処理の例](#default_error_handling)​とは異なり、この例では、On Error Continue (​`on-error-continue`​) がフローの組み込み Error Handler (​`error-handler`​) コンポーネント内で設定され、On Error Continue には、エラーの説明を書き込む Logger が含まれます。 ![Listener、Request、Logger などのコンポーネントが含まれる、エラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-on-error-continue.png) この例の XML は次のようになります。 ```xml ``` デフォルトのエラー処理の例と同様に、要求されたページが見つからないため、フローは 404 エラーを返し、Mule はこのエラーを HTTP:NOT\_FOUND​ エラーとして識別します。 ただし、このケースでは、エラーが伝達されないため、HTTP リスナーをトリガーするために使用したブラウザーのタブは空白になります。On Error Continue を使用すると、例のフローは、ページが見つからなくても、GET 要求の 200 と共に正常終了したかのように処理されます。HTTP リスナーはデフォルトの成功応答の動作 (メッセージ本文として ​`payload`​ コンテンツを返す) を実行します。ページが見つからなかったため、ブラウザーに表示するコンテンツはありません。このため、ブラウザータブは空白になります。 Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージ (以下の 1 番目の ERROR メッセージ) も出力されます。また、Mule エラーについて説明する (​`error.description`​。​[「Mule エラーのセレクター式」](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-error-concept#selector_expressions)​を参照)、ロガーからの ERROR メッセージ (以下の 2 番目の ERROR) が出力されます。 ```txt ERROR 2021-01-19 18:42:04,583 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorContinueHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15 Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-normalFlow(error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ERROR 2021-01-19 18:42:04,586 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/errorHandler/0/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` On Error Continue (​`on-error-continue`​) の代わりに On Error Propagate (​`on-error-propagate`​) を使用して同じ Mule アプリケーションを作成した場合、同じエラーメッセージが Studio コンソールに表示されますが、記録されたエラーメッセージがブラウザーにも表示されます。この動作はデフォルトのエラー処理動作と同じです。どちらも On Error Propagate を使用するためです。 各 On Error コンポーネント内で、定義するエラーパスには任意の数のイベントプロセッサーを組み込むことができるため、特定のエラー種別を必要なだけ正確に処理できます。On-Error コンポーネントで処理する特定の Mule エラーを選択できます。Error Handler コンポーネントは、エラーに一致する最初の On Error コンポーネントにエラーを転送します。 フローレベルでのより複雑なエラー処理設定については、​[「Mule 4 の概要: エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-error-handlers)​を参照してください。 On Error Continue および On Error Propagate についての詳細は、​[「On-Error コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.8/on-error-scope-concept)​を参照してください。 ### [](#global_error_handler)グローバルエラーハンドラーの参照 グローバルエラーハンドラーは、同じ方法でエラーを処理する複数のフローまたは Try スコープが必要な場合に役立つ可能性があります。エラーハンドラーへの参照を提供することで、再利用設定を作成できます。 - [グローバルエラー処理設定の定義](#global_error_config_set) - [フローからのエラー処理設定の参照](#global_error_config_ref) #### [](#global_error_config_set)グローバルエラー処理設定の定義 次の XML 設定では、​``​ を使用して ​``​ 設定を参照するデフォルトのエラー処理設定を定義します。 ```xml ``` Studio UI では、グローバルエラー処理の例は次のようになります。 ![グローバルエラーハンドラー設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/error-handlers-global.png) この例には、エラーを処理するための 2 つの主要なコンポーネントが含まれます。Studio キャンバスに表示される埋め込みコンポーネントを含む Error Handler (​`error-handler`​) と、キャンバスに表示されないグローバルエラー処理設定です。 UI の例のフロー (​**someFlow**​) は、Error Handler コンポーネントが Mule アプリケーションのフローの外側にあることを示しています。 要求により HTTP:NOT\_FOUND​ エラーが生成されるため、Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージが出力されます。 On Error Continue 設定では、処理するエラーが伝達されません (​[On-Error コンポーネントを使用したメッセージングエラーの処理](#on_error_continue)​を参照)。 XML マークアップで設定を記述する代わりに Studio UI でグローバルエラー処理の例をセットアップする方法は、次のとおりです。 1. \[Error Handler\] コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ から Studio キャンバスにドラッグし、​**「allErrorHandler」**​という名前を付けます。 このコンポーネントはどのフローにも含まれません。 2. \[On Error Continue\] コンポーネントを \[Error Handler\] コンポーネントにドラッグします。 3. \[Set Payload\] コンポーネントを \[On Error Continue\] コンポーネントにドラッグします。 \[Set Payload\] コンポーネントは 1 つの例です。Logger など、他のコンポーネントを使用して、そのコンポーネント内で独自のエラーメッセージを記述することができます。Set Payload の例では、エラーの説明に Mule 変数を使用します (詳細は、​[「定義済み変数」](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​の ​`error`​ 変数を参照)。 4. Studio でグローバルエラー処理参照を作成します。 1. **\[Global Elements (グローバル要素)\]**​ をクリックして ​**\[Global Configuration Elements (グローバル設定要素)\]**​ を開きます。 **\[Global Elements (グローバル要素)\]**​ は Studio キャンバスの下にあります。 2. **\[Global Configuration Elements (グローバル設定要素)\]**​ で ​**\[Create (作成)\]**​ をクリックして ​**\[Choose Global Type (グローバル種別の選択)\]**​ ダイアログを開きます。 ![\[Configuration (設定)\] などのグローバル要素種別を選択する設定パネル](_images/error-handling-global-type.png) 3. ダイアログから ​**\[Global Configuration (グローバル設定)\]**​ -→ ​**\[Configuration (設定)\]**​ を選択し、​**\[OK\]**​ をクリックして、​**\[Configuration (設定)\]**​ ダイアログを開きます。 ![\[Configuration (設定)\] ダイアログの \[General (一般)\] 項目 (\[Settings (設定)\] など)](_images/error-handling-global-config.png) 4. **\[Configuration (設定)\]**​ ダイアログから、​**\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ 項目で ​**\[allErrorHandler\]**​ を選択し、​**\[OK\]**​ をクリックします。 5. XML で記述された値を使用して、HTTP Listener および HTTP Request コンポーネントをセットアップします。 6. (Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックして、XML 設定が正しいことを確認します。 ### [](#global_error_config_ref)フローからのエラー処理設定の参照
この例の一部の要素の設定は XML のみです。
フローは、フローの外側にあるグローバルエラーハンドラーを参照できます。フローはそのすべてのエラーを、参照を介して記録します。 例: アプリケーションの XML 設定 ```xml ``` この XML の例では、グローバルエラーハンドラーは、​`loggingErrorHandler`​ という名前の ​``​ 要素を介して設定されます。フローは ​``​ を使用してエラーハンドラーを参照します。 Studio でフローからグローバルエラーハンドラー設定を参照する手順は、次のとおりです。 1. Studio で、​**\[Error Handler\]**​ コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ からキャンバスにドラッグし、UI を使用してそのコンポーネントを設定します。 2. Mule アプリケーションで、(Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックします。 3. (XML のみの設定) ​``​ 要素内で、参照の XML を入力します (例: ``​)。 次の例では、​``​ 要素内の ​``​ を使用してグローバル On Error Continue 要素 (​``​) を参照します。 どちらも、UI ではなく、​**\[Configuration XML (設定 XML)\]**​ を介した手動設定が必要です。 ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept) - [Raise Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/raise-error-component-reference) - [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-error-handlers) - [Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-core-exception-strategies) # エラーハンドラー Mule で発生するエラーは、次の 2 つの主要カテゴリのいずれかに分類されます。 - [システムエラー](#system_errors) - [メッセージングエラー](#messaging_errors) ## [](#system_errors)システムエラー システムレベルで例外が発生し、Mule イベントが関係していない場合、システムエラーがスローされます。システムエラーハンドラーは、次の状況で発生した例外を管理します。 - アプリケーションの起動中。 - 外部システムへの接続が失敗した場合。 システムエラーが発生すると、Mule は、登録されているリスナーにエラー通知を送信し、エラーを記録し、エラーが接続の失敗によるものであれば再接続戦略を実行します。 システムエラーハンドラーは、Mule では設定できません。 ## [](#messaging_errors)メッセージングエラー Mule イベントと Mule イベントに含まれるメッセージを処理する Mule アプリケーションのフロー内で問題が発生すると、Mule はメッセージングエラー (​[Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-error-concept)​) をスローします。 Mule メッセージングエラーは複数の方法で処理できます。 - [デフォルトのエラー処理](#default_error_handling)​メカニズムを使用できます。 - フロー内では、フローの組み込み Error Handler コンポーネント内で ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/on-error-scope-concept)​ (On Error Continue および On Error Propagate) をセットアップできます。これらのコンポーネントには、エラーを処理するための任意の数のコンポーネントを含めることができます。 次の図は、イベントプロセッサー (HTTP Request 操作やデータベース操作など) でエラーがスローされたときの動作を示しています。 ![複数のイベントプロセッサーとエラー処理コンポーネントが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handling-39be7.png) - フロー外では、​[Error Handler](#global_error_handler)​ コンポーネントをセットアップし、そのコンポーネントを他のエラーハンドラー設定から参照できます。グローバルエラーハンドラーには、On Error コンポーネントとそのコンテンツを含めることもできます。 - エラー処理は、フローに存在する ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept)​内からセットアップすることもできます。スコープ内には組み込みエラーハンドラーが含まれ、その中で On Error コンポーネントとそのコンテンツを設定できます。 ### [](#default_error_handling)メッセージのデフォルトエラー処理の使用 デフォルトでは、未処理のメッセージングエラーは記録され、伝達されます。フローで処理されている Mule メッセージでエラーが発生すると、フローの通常の実行は停止し、プロセスがフローのデフォルトのエラーハンドラーに転送され、そのエラーハンドラーでエラーが伝達されます。 次の例は、エラーを管理するように明示的に設定したエラー処理コンポーネントを使用するのではなく、デフォルトのエラー処理を使用する簡単な Mule アプリケーション設定を示しています。 ![Mule アプリケーションの HTTP 要求の失敗に起因するエラーメッセージ表示](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-error-handling-default.png) デフォルトのエラー処理の例の XML は次のようになります。 ```xml ``` この設定で Mule アプリケーションを開始し、​`[http://0.0.0.0:8081/users](http://0.0.0.0:8081/users)`​ を (たとえばブラウザーなどに) 読み込むことで HTTP リスナーをトリガーすると、フローは、存在しないファイルに対して HTTP 要求 (​`http://jsonplaceholder.typicode.com:80/somebadrequest`​) を実行します。結果として、Anypoint Studio コンソールでエラーが記録されて Web ブラウザーに伝達されます。 - Anypoint Studio コンソールログ Studio コンソールはエラーメッセージを出力します。このメッセージは、HTTP GET 要求から返された 404 エラーがデフォルトハンドラー (​`OnErrorPropagateHandler`​) により伝達されていることを示します。Mule はこのエラーを HTTP:NOT\_FOUND​ として識別します。 ```txt ERROR 2021-01-19 18:48:50,392 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-example/processors/0; event: 1d3baf11-5aa0-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request) Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-example(error-handlers-example/processors/0 @ error-handlers-example:error-handlers-example.xml:15 (Request)) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ``` Studio コンソールのエラーログは次の情報を表します。 - **Message (メッセージ)**​: エラーの説明 - **Element (要素)**​: 実行を失敗させ、エラーの原因となった XML 要素 - **Element DSL (要素 DSL)**​: 実行を失敗させ、エラーの原因となった XML 要素。DSL 形式で表現されます。 - **Error type (エラー種別)**​: Mule アプリケーションで発生した Mule エラーの種別 - **Flowstack (フロースタック)**​: フロースタックトレースのエラーログ この項目には、Mule イベントを処理した各フローと、イベントを次のフローに送信したプロセッサーのエントリがリストされます。最後のエントリには、イベントの処理中に失敗したフローとプロセッサーが示されます。 Mule 4.3.0 以降、フロースタックエントリはデフォルトで有効になっています。フロースタックログを無効にするには、​`mule.flowTrace`​ 設定プロパティを ​`false`​ に設定することができます。 - Web ブラウザーへのエラーの伝達 HTTP:NOT\_FOUND​ エラーの説明は、リスナーをトリガーするために使用したブラウザータブに表示されます。 ```txt HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` この Mule エラーの説明は、次の 2 つの理由でブラウザーに表示されます。 - デフォルトのエラーハンドラーで On Error Propagate プロセス (​`OnErrorPropagateHandler`​) を使用しています。 On Error Propagate コンポーネントによって、フローが失敗し、HTTP リスナーで、見つからないファイルに関連付けられる ​`404`​ エラーのエラー応答が準備されます。 - HTTP リスナーでデフォルトのエラー (​`error.description`​) および成功 (​`payload`​) 応答を使用してメッセージ本文を返しています。 カスタム応答が設定されていないため、ブラウザーにエラーの説明が表示されます。 ### [](#on_error_continue)On-Error コンポーネントを使用したメッセージングエラーの処理 デフォルトのエラー処理メカニズムを使用する代わりに ​[On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/on-error-scope-concept)​ (On Error Continue および On Error Propagate) を組み込みまたは外部の Error Handler コンポーネント内で使用できます。 次の例は、HTTP リスナーがトリガーされたときに HTTP 要求の結果を返すように Studio で設定された簡単なフローを示しています。​[デフォルトのエラー処理の例](#default_error_handling)​とは異なり、この例では、On Error Continue (​`on-error-continue`​) がフローの組み込み Error Handler (​`error-handler`​) コンポーネント内で設定され、On Error Continue には、エラーの説明を書き込む Logger が含まれます。 ![Listener、Request、Logger などのコンポーネントが含まれる、エラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-on-error-continue.png) この例の XML は次のようになります。 ```xml ``` デフォルトのエラー処理の例と同様に、要求されたページが見つからないため、フローは 404 エラーを返し、Mule はこのエラーを HTTP:NOT\_FOUND​ エラーとして識別します。 ただし、このケースでは、エラーが伝達されないため、HTTP リスナーをトリガーするために使用したブラウザーのタブは空白になります。On Error Continue を使用すると、例のフローは、ページが見つからなくても、GET 要求の 200 と共に正常終了したかのように処理されます。HTTP リスナーはデフォルトの成功応答の動作 (メッセージ本文として ​`payload`​ コンテンツを返す) を実行します。ページが見つからなかったため、ブラウザーに表示するコンテンツはありません。このため、ブラウザータブは空白になります。 Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージ (以下の 1 番目の ERROR メッセージ) も出力されます。また、Mule エラーについて説明する (​`error.description`​。​[「Mule エラーのセレクター式」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-error-concept#selector_expressions)​を参照)、ロガーからの ERROR メッセージ (以下の 2 番目の ERROR) が出力されます。 ```txt ERROR 2021-01-19 18:42:04,583 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.exception.OnErrorContinueHandler: ******************************************************************************** Message : HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). Element : error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15 Element DSL : Error type : HTTP:NOT_FOUND FlowStack : at error-handlers-normalFlow(error-handlers-normalFlow/processors/0 @ error-handlers-example:error-handlers-example.xml:15) (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** ERROR 2021-01-19 18:42:04,586 [[error-handlers-example].http.requester.HTTP_Request_configuration.11 SelectorRunner] [processor: error-handlers-normalFlow/errorHandler/0/processors/0; event: 2a95eaa1-5a9f-11eb-b96f-a483e7abe2b5] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: HTTP GET on resource 'http://jsonplaceholder.typicode.com:80/somebadrequest' failed: not found (404). ``` On Error Continue (​`on-error-continue`​) の代わりに On Error Propagate (​`on-error-propagate`​) を使用して同じ Mule アプリケーションを作成した場合、同じエラーメッセージが Studio コンソールに表示されますが、記録されたエラーメッセージがブラウザーにも表示されます。この動作はデフォルトのエラー処理動作と同じです。どちらも On Error Propagate を使用するためです。 各 On Error コンポーネント内で、定義するエラーパスには任意の数のイベントプロセッサーを組み込むことができるため、特定のエラー種別を必要なだけ正確に処理できます。On-Error コンポーネントで処理する特定の Mule エラーを選択できます。Error Handler コンポーネントは、エラーに一致する最初の On Error コンポーネントにエラーを転送します。 フローレベルでのより複雑なエラー処理設定については、​[「Mule 4 の概要: エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-error-handlers)​を参照してください。 On Error Continue および On Error Propagate についての詳細は、​[「On-Error コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.9/on-error-scope-concept)​を参照してください。 ### [](#global_error_handler)グローバルエラーハンドラーの参照 グローバルエラーハンドラーは、同じ方法でエラーを処理する複数のフローまたは Try スコープが必要な場合に役立つ可能性があります。エラーハンドラーへの参照を提供することで、再利用設定を作成できます。 - [グローバルエラー処理設定の定義](#global_error_config_set) - [フローからのエラー処理設定の参照](#global_error_config_ref) #### [](#global_error_config_set)グローバルエラー処理設定の定義 次の XML 設定では、​``​ を使用して ​``​ 設定を参照するデフォルトのエラー処理設定を定義します。 ```xml ``` Studio UI では、グローバルエラー処理の例は次のようになります。 ![グローバルエラーハンドラー設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/error-handlers-global.png) この例には、エラーを処理するための 2 つの主要なコンポーネントが含まれます。Studio キャンバスに表示される埋め込みコンポーネントを含む Error Handler (​`error-handler`​) と、キャンバスに表示されないグローバルエラー処理設定です。 UI の例のフロー (​**someFlow**​) は、Error Handler コンポーネントが Mule アプリケーションのフローの外側にあることを示しています。 要求により HTTP:NOT\_FOUND​ エラーが生成されるため、Studio コンソールには、​`OnErrorContinueHandler`​ がエラーを処理していることを示すエラーメッセージが出力されます。 On Error Continue 設定では、処理するエラーが伝達されません (​[On-Error コンポーネントを使用したメッセージングエラーの処理](#on_error_continue)​を参照)。 XML マークアップで設定を記述する代わりに Studio UI でグローバルエラー処理の例をセットアップする方法は、次のとおりです。 1. \[Error Handler\] コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ から Studio キャンバスにドラッグし、​**「allErrorHandler」**​という名前を付けます。 このコンポーネントはどのフローにも含まれません。 2. \[On Error Continue\] コンポーネントを \[Error Handler\] コンポーネントにドラッグします。 3. \[Set Payload\] コンポーネントを \[On Error Continue\] コンポーネントにドラッグします。 \[Set Payload\] コンポーネントは 1 つの例です。Logger など、他のコンポーネントを使用して、そのコンポーネント内で独自のエラーメッセージを記述することができます。Set Payload の例では、エラーの説明に Mule 変数を使用します (詳細は、​[「定義済み変数」](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​の ​`error`​ 変数を参照)。 4. Studio でグローバルエラー処理参照を作成します。 1. **\[Global Elements (グローバル要素)\]**​ をクリックして ​**\[Global Configuration Elements (グローバル設定要素)\]**​ を開きます。 **\[Global Elements (グローバル要素)\]**​ は Studio キャンバスの下にあります。 2. **\[Global Configuration Elements (グローバル設定要素)\]**​ で ​**\[Create (作成)\]**​ をクリックして ​**\[Choose Global Type (グローバル種別の選択)\]**​ ダイアログを開きます。 ![\[Configuration (設定)\] などのグローバル要素種別を選択する設定パネル](_images/error-handling-global-type.png) 3. ダイアログから ​**\[Global Configuration (グローバル設定)\]**​ -→ ​**\[Configuration (設定)\]**​ を選択し、​**\[OK\]**​ をクリックして、​**\[Configuration (設定)\]**​ ダイアログを開きます。 ![\[Configuration (設定)\] ダイアログの \[General (一般)\] 項目 (\[Settings (設定)\] など)](_images/error-handling-global-config.png) 4. **\[Configuration (設定)\]**​ ダイアログから、​**\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ 項目で ​**\[allErrorHandler\]**​ を選択し、​**\[OK\]**​ をクリックします。 5. XML で記述された値を使用して、HTTP Listener および HTTP Request コンポーネントをセットアップします。 6. (Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックして、XML 設定が正しいことを確認します。 ### [](#global_error_config_ref)フローからのエラー処理設定の参照
この例の一部の要素の設定は XML のみです。
フローは、フローの外側にあるグローバルエラーハンドラーを参照できます。フローはそのすべてのエラーを、参照を介して記録します。 例: アプリケーションの XML 設定 ```xml ``` この XML の例では、グローバルエラーハンドラーは、​`loggingErrorHandler`​ という名前の ​``​ 要素を介して設定されます。フローは ​``​ を使用してエラーハンドラーを参照します。 Studio でフローからグローバルエラーハンドラー設定を参照する手順は、次のとおりです。 1. Studio で、​**\[Error Handler\]**​ コンポーネントを ​**\[Mule Palette (Mule パレット)\]**​ からキャンバスにドラッグし、UI を使用してそのコンポーネントを設定します。 2. Mule アプリケーションで、(Studio キャンバスの下にある) ​**\[Configuration XML (設定 XML)\]**​ をクリックします。 3. (XML のみの設定) ​``​ 要素内で、参照の XML を入力します (例: ``​)。 次の例では、​``​ 要素内の ​``​ を使用してグローバル On Error Continue 要素 (​``​) を参照します。 どちらも、UI ではなく、​**\[Configuration XML (設定 XML)\]**​ を介した手動設定が必要です。 ```xml ``` ## [](#関連情報)関連情報 - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept) - [Raise Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/raise-error-component-reference) - [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-error-handlers) - [Mule エラーハンドラーへの Exception Strategy (例外戦略) の移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-core-exception-strategies) # オブジェクトストアを使用したアプリケーションデータの保存 オブジェクトストアは、Mule アプリケーション内または複数の Mule アプリケーションにわたってオブジェクトを保存する機能です。Mule Runtime Engine (Mule) はオブジェクトストアを使用して、最終的に取得するデータを保持します。Mule の内部では、さまざまな検索条件、ルーター、およびメッセージ間で状態を保存する必要があるその他のメッセージプロセッサーでオブジェクトストアを使用します。 オブジェクトストアは、すべてのデプロイメント対象で使用できます。アプリケーションを CloudHub にデプロイする場合は、Object Store V2 も使用できます。 ## [](#ユースケース)ユースケース 次のシナリオで使用するようにカスタムオブジェクトストアを設定できます。 - 冪等性のあるメッセージ検証機能を設定するときに、指定したオブジェクトストアに一意の ID を保存する。 - リスナー (HTTP、ファイル、JMS、VM、ソケット) で再配信ポリシーを設定するときに、指定したオブジェクトストアに再配信数を保存する。 - カスタムキャッシュ戦略を使用する Cache スコープを設定するときに、指定されたオブジェクトストアにキャッシュデータを保存する。 - カスタムコンポーネントでオブジェクトストアを使用して情報を保持する。 - オブジェクトストア用 Anypoint Connector (Object Store Connector) を使用して、Mule フローから情報を保存または取得する。 ## [](#object-store-config)オブジェクトストア設定 各 Mule アプリケーションには、デフォルトで、常にアプリケーションが使用できる永続的なオブジェクトストアがあります。また、永続的かメモリ内のカスタムオブジェクトストアを作成することもできます。 オブジェクトストアをグローバル要素として設定して、アプリケーションの任意のコンポーネントからアクセスできるようにするか、その使用をサポートする特定のコンポーネント用のカスタムオブジェクトストアを設定できます。 ### [](#オブジェクトストアを設定する)オブジェクトストアを設定する アプリケーション内の他のコンポーネントから参照できるグローバルオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Global Elements (グローバル要素)\]**​ タブを開きます。 2. **\[Create (作成)\]**​ をクリックします。 3. **\[Component configurations (コンポーネント設定)\]**​ > ​**\[Object Store (オブジェクトストア)\]**​ を選択します。 4. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![グローバルオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-object-store-global.png) または、次のコードをアプリケーション XML の最上位要素として含めることで、グローバルオブジェクトストアを作成できます。 ```xml ``` 目的の値で各属性を設定します。 各 XML 属性の定義の ​[\[Object Store Reference (オブジェクトストア参照)](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore)\]​ を参照してください。 ## [](#特定のコンポーネントのオブジェクトストアを設定する)特定のコンポーネントのオブジェクトストアを設定する 特定のコンポーネントのみで使用可能なオブジェクトストアを設定できます。たとえば、冪等性のあるメッセージ検証機能用のオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Idempotent Message Validator (冪等性のあるメッセージ検証機能)\]**​ プロパティを開きます。 2. **\[Object Store (オブジェクトストア)\]**​ で、​**\[Edit Inline (インライン編集)\]**​ を選択します。 3. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![インラインオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-object-store-inline.png) または、オブジェクトストア設定を XML 設定ファイルのコンポーネント要素内に含めることで、オブジェクトストアを作成できます。 ```xml ``` ## [](#object-store-connector-を使用したデータの管理)Object Store Connector を使用したデータの管理 Object Store Connector を使用すると、Mule アプリケーションでオブジェクトストアとやり取りするためのさまざまな操作を実行できます。操作の例として、保存、取得、削除などがあります。 使用可能な操作と設定例についての詳細は、​[「Object Store Connector」](https://docs.mulesoft.com/object-store-connector/latest/)​ドキュメントを参照してください。 ## [](#関連情報)関連情報 - [例: オブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os) - [Object Store v2](https://docs.mulesoft.com/jp/object-store/) - [Idempotent Message Validator](https://docs.mulesoft.com/jp/mule-runtime/4.3/idempotent-message-validator) - [Redelivery Policy (再配信ポリシー)](https://docs.mulesoft.com/jp/mule-runtime/4.3/redelivery-policy) - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/cache-scope) # オブジェクトストアを使用したアプリケーションデータの保存 オブジェクトストアは、Mule アプリケーション内または複数の Mule アプリケーションにわたってオブジェクトを保存する機能です。Mule Runtime Engine (Mule) はオブジェクトストアを使用して、最終的に取得するデータを保持します。Mule の内部では、さまざまな検索条件、ルーター、およびメッセージ間で状態を保存する必要があるその他のメッセージプロセッサーでオブジェクトストアを使用します。 オブジェクトストアは、すべてのデプロイメント対象で使用できます。アプリケーションを CloudHub にデプロイする場合は、Object Store V2 も使用できます。 ## [](#ユースケース)ユースケース 次のシナリオで使用するようにカスタムオブジェクトストアを設定できます。 - 冪等性のあるメッセージ検証機能を設定するときに、指定したオブジェクトストアに一意の ID を保存する。 - リスナー (HTTP、ファイル、JMS、VM、ソケット) で再配信ポリシーを設定するときに、指定したオブジェクトストアに再配信数を保存する。 - カスタムキャッシュ戦略を使用する Cache スコープを設定するときに、指定されたオブジェクトストアにキャッシュデータを保存する。 - カスタムコンポーネントでオブジェクトストアを使用して情報を保持する。 - オブジェクトストア用 Anypoint Connector (Object Store Connector) を使用して、Mule フローから情報を保存または取得する。 ## [](#object-store-config)オブジェクトストア設定 各 Mule アプリケーションには、デフォルトで、常にアプリケーションが使用できる永続的なオブジェクトストアがあります。また、永続的かメモリ内のカスタムオブジェクトストアを作成することもできます。 オブジェクトストアをグローバル要素として設定して、アプリケーションの任意のコンポーネントからアクセスできるようにするか、その使用をサポートする特定のコンポーネント用のカスタムオブジェクトストアを設定できます。 ### [](#オブジェクトストアを設定する)オブジェクトストアを設定する アプリケーション内の他のコンポーネントから参照できるグローバルオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Global Elements (グローバル要素)\]**​ タブを開きます。 2. **\[Create (作成)\]**​ をクリックします。 3. **\[Component configurations (コンポーネント設定)\]**​ > ​**\[Object Store (オブジェクトストア)\]**​ を選択します。 4. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![グローバルオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-object-store-global.png) または、次のコードをアプリケーション XML の最上位要素として含めることで、グローバルオブジェクトストアを作成できます。 ```xml ``` 目的の値で各属性を設定します。 各 XML 属性の定義の ​[\[Object Store Reference (オブジェクトストア参照)](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore)\]​ を参照してください。 ## [](#特定のコンポーネントのオブジェクトストアを設定する)特定のコンポーネントのオブジェクトストアを設定する 特定のコンポーネントのみで使用可能なオブジェクトストアを設定できます。たとえば、冪等性のあるメッセージ検証機能用のオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Idempotent Message Validator (冪等性のあるメッセージ検証機能)\]**​ プロパティを開きます。 2. **\[Object Store (オブジェクトストア)\]**​ で、​**\[Edit Inline (インライン編集)\]**​ を選択します。 3. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![インラインオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-object-store-inline.png) または、オブジェクトストア設定を XML 設定ファイルのコンポーネント要素内に含めることで、オブジェクトストアを作成できます。 ```xml ``` ## [](#object-store-connector-を使用したデータの管理)Object Store Connector を使用したデータの管理 Object Store Connector を使用すると、Mule アプリケーションでオブジェクトストアとやり取りするためのさまざまな操作を実行できます。操作の例として、保存、取得、削除などがあります。 使用可能な操作と設定例についての詳細は、​[「Object Store Connector」](https://docs.mulesoft.com/object-store-connector/latest/)​ドキュメントを参照してください。 ## [](#関連情報)関連情報 - [例: オブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os) - [Object Store v2](https://docs.mulesoft.com/jp/object-store/) - [Idempotent Message Validator](https://docs.mulesoft.com/jp/mule-runtime/4.4/idempotent-message-validator) - [Redelivery Policy (再配信ポリシー)](https://docs.mulesoft.com/jp/mule-runtime/4.4/redelivery-policy) - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/cache-scope) # オブジェクトストアを使用したアプリケーションデータの保存 オブジェクトストアは、Mule アプリケーション内または複数の Mule アプリケーションにわたってオブジェクトを保存する機能です。Mule Runtime Engine (Mule) はオブジェクトストアを使用して、最終的に取得するデータを保持します。Mule の内部では、さまざまな検索条件、ルーター、およびメッセージ間で状態を保存する必要があるその他のメッセージプロセッサーでオブジェクトストアを使用します。 オブジェクトストアは、すべてのデプロイメント対象で使用できます。アプリケーションを CloudHub にデプロイする場合は、Object Store V2 も使用できます。 ## [](#ユースケース)ユースケース 次のシナリオで使用するようにカスタムオブジェクトストアを設定できます。 - 冪等性のあるメッセージ検証機能を設定するときに、指定したオブジェクトストアに一意の ID を保存する。 - リスナー (HTTP、ファイル、JMS、VM、ソケット) で再配信ポリシーを設定するときに、指定したオブジェクトストアに再配信数を保存する。 - カスタムキャッシュ戦略を使用する Cache スコープを設定するときに、指定されたオブジェクトストアにキャッシュデータを保存する。 - カスタムコンポーネントでオブジェクトストアを使用して情報を保持する。 - オブジェクトストア用 Anypoint Connector (Object Store Connector) を使用して、Mule フローから情報を保存または取得する。 ## [](#object-store-config)オブジェクトストア設定 各 Mule アプリケーションには、デフォルトで、常にアプリケーションが使用できる永続的なオブジェクトストアがあります。また、永続的かメモリ内のカスタムオブジェクトストアを作成することもできます。 オブジェクトストアをグローバル要素として設定して、アプリケーションの任意のコンポーネントからアクセスできるようにするか、その使用をサポートする特定のコンポーネント用のカスタムオブジェクトストアを設定できます。 ### [](#オブジェクトストアを設定する)オブジェクトストアを設定する アプリケーション内の他のコンポーネントから参照できるグローバルオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Global Elements (グローバル要素)\]**​ タブを開きます。 2. **\[Create (作成)\]**​ をクリックします。 3. **\[Component configurations (コンポーネント設定)\]**​ > ​**\[Object Store (オブジェクトストア)\]**​ を選択します。 4. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![グローバルオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-object-store-global.png) または、次のコードをアプリケーション XML の最上位要素として含めることで、グローバルオブジェクトストアを作成できます。 ```xml ``` 目的の値で各属性を設定します。 各 XML 属性の定義の ​[\[Object Store Reference (オブジェクトストア参照)](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore)\]​ を参照してください。 ## [](#特定のコンポーネントのオブジェクトストアを設定する)特定のコンポーネントのオブジェクトストアを設定する 特定のコンポーネントのみで使用可能なオブジェクトストアを設定できます。たとえば、冪等性のあるメッセージ検証機能用のオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Idempotent Message Validator (冪等性のあるメッセージ検証機能)\]**​ プロパティを開きます。 2. **\[Object Store (オブジェクトストア)\]**​ で、​**\[Edit Inline (インライン編集)\]**​ を選択します。 3. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![インラインオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-object-store-inline.png) または、オブジェクトストア設定を XML 設定ファイルのコンポーネント要素内に含めることで、オブジェクトストアを作成できます。 ```xml ``` ## [](#object-store-connector-を使用したデータの管理)Object Store Connector を使用したデータの管理 Object Store Connector を使用すると、Mule アプリケーションでオブジェクトストアとやり取りするためのさまざまな操作を実行できます。操作の例として、保存、取得、削除などがあります。 使用可能な操作と設定例についての詳細は、​[「Object Store Connector」](https://docs.mulesoft.com/object-store-connector/latest/)​ドキュメントを参照してください。 ## [](#関連情報)関連情報 - [例: オブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os) - [Object Store v2](https://docs.mulesoft.com/jp/object-store/) - [Idempotent Message Validator](https://docs.mulesoft.com/jp/mule-runtime/4.5/idempotent-message-validator) - [Redelivery Policy (再配信ポリシー)](https://docs.mulesoft.com/jp/mule-runtime/4.5/redelivery-policy) - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/cache-scope) # オブジェクトストアを使用したアプリケーションデータの保存 オブジェクトストアは、Mule アプリケーション内または複数の Mule アプリケーションにわたってオブジェクトを保存する機能です。Mule Runtime Engine (Mule) はオブジェクトストアを使用して、最終的に取得するデータを保持します。Mule の内部では、さまざまな検索条件、ルーター、およびメッセージ間で状態を保存する必要があるその他のメッセージプロセッサーでオブジェクトストアを使用します。 オブジェクトストアは、すべてのデプロイメント対象で使用できます。アプリケーションを CloudHub にデプロイする場合は、Object Store V2 も使用できます。 ## [](#ユースケース)ユースケース 次のシナリオで使用するようにカスタムオブジェクトストアを設定できます。 - 冪等性のあるメッセージ検証機能を設定するときに、指定したオブジェクトストアに一意の ID を保存する。 - リスナー (HTTP、ファイル、JMS、VM、ソケット) で再配信ポリシーを設定するときに、指定したオブジェクトストアに再配信数を保存する。 - カスタムキャッシュ戦略を使用する Cache スコープを設定するときに、指定されたオブジェクトストアにキャッシュデータを保存する。 - カスタムコンポーネントでオブジェクトストアを使用して情報を保持する。 - オブジェクトストア用 Anypoint Connector (Object Store Connector) を使用して、Mule フローから情報を保存または取得する。 ## [](#object-store-config)オブジェクトストア設定 各 Mule アプリケーションには、デフォルトで、常にアプリケーションが使用できる永続的なオブジェクトストアがあります。また、永続的かメモリ内のカスタムオブジェクトストアを作成することもできます。 オブジェクトストアをグローバル要素として設定して、アプリケーションの任意のコンポーネントからアクセスできるようにするか、その使用をサポートする特定のコンポーネント用のカスタムオブジェクトストアを設定できます。 ### [](#オブジェクトストアを設定する)オブジェクトストアを設定する アプリケーション内の他のコンポーネントから参照できるグローバルオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Global Elements (グローバル要素)\]**​ タブを開きます。 2. **\[Create (作成)\]**​ をクリックします。 3. **\[Component configurations (コンポーネント設定)\]**​ > ​**\[Object Store (オブジェクトストア)\]**​ を選択します。 4. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![グローバルオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-object-store-global.png) または、次のコードをアプリケーション XML の最上位要素として含めることで、グローバルオブジェクトストアを作成できます。 ```xml ``` 目的の値で各属性を設定します。 各 XML 属性の定義の ​[\[Object Store Reference (オブジェクトストア参照)](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore)\]​ を参照してください。 ## [](#特定のコンポーネントのオブジェクトストアを設定する)特定のコンポーネントのオブジェクトストアを設定する 特定のコンポーネントのみで使用可能なオブジェクトストアを設定できます。たとえば、冪等性のあるメッセージ検証機能用のオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Idempotent Message Validator (冪等性のあるメッセージ検証機能)\]**​ プロパティを開きます。 2. **\[Object Store (オブジェクトストア)\]**​ で、​**\[Edit Inline (インライン編集)\]**​ を選択します。 3. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![インラインオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-object-store-inline.png) または、オブジェクトストア設定を XML 設定ファイルのコンポーネント要素内に含めることで、オブジェクトストアを作成できます。 ```xml ``` ## [](#object-store-connector-を使用したデータの管理)Object Store Connector を使用したデータの管理 Object Store Connector を使用すると、Mule アプリケーションでオブジェクトストアとやり取りするためのさまざまな操作を実行できます。操作の例として、保存、取得、削除などがあります。 使用可能な操作と設定例についての詳細は、​[「Object Store Connector」](https://docs.mulesoft.com/object-store-connector/latest/)​ドキュメントを参照してください。 ## [](#関連情報)関連情報 - [例: オブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os) - [Object Store v2](https://docs.mulesoft.com/jp/object-store/) - [Idempotent Message Validator](https://docs.mulesoft.com/jp/mule-runtime/4.6/idempotent-message-validator) - [Redelivery Policy (再配信ポリシー)](https://docs.mulesoft.com/jp/mule-runtime/4.6/redelivery-policy) - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/cache-scope) # オブジェクトストアを使用したアプリケーションデータの保存 オブジェクトストアは、Mule アプリケーション内または複数の Mule アプリケーションにわたってオブジェクトを保存する機能です。Mule Runtime Engine (Mule) はオブジェクトストアを使用して、最終的に取得するデータを保持します。Mule の内部では、さまざまな検索条件、ルーター、およびメッセージ間で状態を保存する必要があるその他のメッセージプロセッサーでオブジェクトストアを使用します。 オブジェクトストアは、すべてのデプロイメント対象で使用できます。アプリケーションを CloudHub にデプロイする場合は、Object Store V2 も使用できます。 ## [](#ユースケース)ユースケース 次のシナリオで使用するようにカスタムオブジェクトストアを設定できます。 - 冪等性のあるメッセージ検証機能を設定するときに、指定したオブジェクトストアに一意の ID を保存する。 - リスナー (HTTP、ファイル、JMS、VM、ソケット) で再配信ポリシーを設定するときに、指定したオブジェクトストアに再配信数を保存する。 - カスタムキャッシュ戦略を使用する Cache スコープを設定するときに、指定されたオブジェクトストアにキャッシュデータを保存する。 - カスタムコンポーネントでオブジェクトストアを使用して情報を保持する。 - オブジェクトストア用 Anypoint Connector (Object Store Connector) を使用して、Mule フローから情報を保存または取得する。 ## [](#object-store-config)オブジェクトストア設定 各 Mule アプリケーションには、デフォルトで、常にアプリケーションが使用できる永続的なオブジェクトストアがあります。また、永続的かメモリ内のカスタムオブジェクトストアを作成することもできます。 オブジェクトストアをグローバル要素として設定して、アプリケーションの任意のコンポーネントからアクセスできるようにするか、その使用をサポートする特定のコンポーネント用のカスタムオブジェクトストアを設定できます。 ### [](#オブジェクトストアを設定する)オブジェクトストアを設定する アプリケーション内の他のコンポーネントから参照できるグローバルオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Global Elements (グローバル要素)\]**​ タブを開きます。 2. **\[Create (作成)\]**​ をクリックします。 3. **\[Component configurations (コンポーネント設定)\]**​ > ​**\[Object Store (オブジェクトストア)\]**​ を選択します。 4. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![グローバルオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-object-store-global.png) または、次のコードをアプリケーション XML の最上位要素として含めることで、グローバルオブジェクトストアを作成できます。 ```xml ``` 目的の値で各属性を設定します。 各 XML 属性の定義の ​[\[Object Store Reference (オブジェクトストア参照)](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore)\]​ を参照してください。 ## [](#特定のコンポーネントのオブジェクトストアを設定する)特定のコンポーネントのオブジェクトストアを設定する 特定のコンポーネントのみで使用可能なオブジェクトストアを設定できます。たとえば、冪等性のあるメッセージ検証機能用のオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Idempotent Message Validator (冪等性のあるメッセージ検証機能)\]**​ プロパティを開きます。 2. **\[Object Store (オブジェクトストア)\]**​ で、​**\[Edit Inline (インライン編集)\]**​ を選択します。 3. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![インラインオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-object-store-inline.png) または、オブジェクトストア設定を XML 設定ファイルのコンポーネント要素内に含めることで、オブジェクトストアを作成できます。 ```xml ``` ## [](#object-store-connector-を使用したデータの管理)Object Store Connector を使用したデータの管理 Object Store Connector を使用すると、Mule アプリケーションでオブジェクトストアとやり取りするためのさまざまな操作を実行できます。操作の例として、保存、取得、削除などがあります。 使用可能な操作と設定例についての詳細は、​[「Object Store Connector」](https://docs.mulesoft.com/object-store-connector/latest/)​ドキュメントを参照してください。 ## [](#関連情報)関連情報 - [例: オブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os) - [Object Store v2](https://docs.mulesoft.com/jp/object-store/) - [Idempotent Message Validator](https://docs.mulesoft.com/jp/mule-runtime/4.7/idempotent-message-validator) - [Redelivery Policy (再配信ポリシー)](https://docs.mulesoft.com/jp/mule-runtime/4.7/redelivery-policy) - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/cache-scope) # オブジェクトストアを使用したアプリケーションデータの保存 オブジェクトストアは、Mule アプリケーション内または複数の Mule アプリケーションにわたってオブジェクトを保存する機能です。Mule Runtime Engine (Mule) はオブジェクトストアを使用して、最終的に取得するデータを保持します。Mule の内部では、さまざまな検索条件、ルーター、およびメッセージ間で状態を保存する必要があるその他のメッセージプロセッサーでオブジェクトストアを使用します。 オブジェクトストアは、すべてのデプロイメント対象で使用できます。アプリケーションを CloudHub にデプロイする場合は、Object Store V2 も使用できます。 ## [](#ユースケース)ユースケース 次のシナリオで使用するようにカスタムオブジェクトストアを設定できます。 - 冪等性のあるメッセージ検証機能を設定するときに、指定したオブジェクトストアに一意の ID を保存する。 - リスナー (HTTP、ファイル、JMS、VM、ソケット) で再配信ポリシーを設定するときに、指定したオブジェクトストアに再配信数を保存する。 - カスタムキャッシュ戦略を使用する Cache スコープを設定するときに、指定されたオブジェクトストアにキャッシュデータを保存する。 - カスタムコンポーネントでオブジェクトストアを使用して情報を保持する。 - オブジェクトストア用 Anypoint Connector (Object Store Connector) を使用して、Mule フローから情報を保存または取得する。 ## [](#object-store-config)オブジェクトストア設定 各 Mule アプリケーションには、デフォルトで、常にアプリケーションが使用できる永続的なオブジェクトストアがあります。また、永続的かメモリ内のカスタムオブジェクトストアを作成することもできます。 オブジェクトストアをグローバル要素として設定して、アプリケーションの任意のコンポーネントからアクセスできるようにするか、その使用をサポートする特定のコンポーネント用のカスタムオブジェクトストアを設定できます。 ### [](#オブジェクトストアを設定する)オブジェクトストアを設定する アプリケーション内の他のコンポーネントから参照できるグローバルオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Global Elements (グローバル要素)\]**​ タブを開きます。 2. **\[Create (作成)\]**​ をクリックします。 3. **\[Component configurations (コンポーネント設定)\]**​ > ​**\[Object Store (オブジェクトストア)\]**​ を選択します。 4. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![Mule のグローバルオブジェクトストアを設定するプロパティパネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-object-store-global.png) または、次のコードをアプリケーション XML の最上位要素として含めることで、グローバルオブジェクトストアを作成できます。 ```xml ``` 目的の値で各属性を設定します。 各 XML 属性の定義の ​[\[Object Store Reference (オブジェクトストア参照)](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore)\]​ を参照してください。 ## [](#特定のコンポーネントのオブジェクトストアを設定する)特定のコンポーネントのオブジェクトストアを設定する 特定のコンポーネントのみで使用可能なオブジェクトストアを設定できます。たとえば、冪等性のあるメッセージ検証機能用のオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Idempotent Message Validator (冪等性のあるメッセージ検証機能)\]**​ プロパティを開きます。 2. **\[Object Store (オブジェクトストア)\]**​ で、​**\[Edit Inline (インライン編集)\]**​ を選択します。 3. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![インラインオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-object-store-inline.png) または、オブジェクトストア設定を XML 設定ファイルのコンポーネント要素内に含めることで、オブジェクトストアを作成できます。 ```xml ``` ## [](#object-store-connector-を使用したデータの管理)Object Store Connector を使用したデータの管理 Object Store Connector を使用すると、Mule アプリケーションでオブジェクトストアとやり取りするためのさまざまな操作を実行できます。操作の例として、保存、取得、削除などがあります。 使用可能な操作と設定例についての詳細は、​[「Object Store Connector」](https://docs.mulesoft.com/object-store-connector/latest/)​ドキュメントを参照してください。 ## [](#関連情報)関連情報 - [例: オブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os) - [Object Store v2](https://docs.mulesoft.com/jp/object-store/) - [Idempotent Message Validator](https://docs.mulesoft.com/jp/mule-runtime/4.8/idempotent-message-validator) - [Redelivery Policy (再配信ポリシー)](https://docs.mulesoft.com/jp/mule-runtime/4.8/redelivery-policy) - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/cache-scope) # オブジェクトストアを使用したアプリケーションデータの保存 オブジェクトストアは、Mule アプリケーション内または複数の Mule アプリケーションにわたってオブジェクトを保存する機能です。Mule Runtime Engine (Mule) はオブジェクトストアを使用して、最終的に取得するデータを保持します。Mule の内部では、さまざまな検索条件、ルーター、およびメッセージ間で状態を保存する必要があるその他のメッセージプロセッサーでオブジェクトストアを使用します。 オブジェクトストアは、すべてのデプロイメント対象で使用できます。アプリケーションを CloudHub にデプロイする場合は、Object Store V2 も使用できます。 ## [](#ユースケース)ユースケース 次のシナリオで使用するようにカスタムオブジェクトストアを設定できます。 - 冪等性のあるメッセージ検証機能を設定するときに、指定したオブジェクトストアに一意の ID を保存する。 - リスナー (HTTP、ファイル、JMS、VM、ソケット) で再配信ポリシーを設定するときに、指定したオブジェクトストアに再配信数を保存する。 - カスタムキャッシュ戦略を使用する Cache スコープを設定するときに、指定されたオブジェクトストアにキャッシュデータを保存する。 - カスタムコンポーネントでオブジェクトストアを使用して情報を保持する。 - オブジェクトストア用 Anypoint Connector (Object Store Connector) を使用して、Mule フローから情報を保存または取得する。 ## [](#object-store-config)オブジェクトストア設定 各 Mule アプリケーションには、デフォルトで、常にアプリケーションが使用できる永続的なオブジェクトストアがあります。また、永続的かメモリ内のカスタムオブジェクトストアを作成することもできます。 オブジェクトストアをグローバル要素として設定して、アプリケーションの任意のコンポーネントからアクセスできるようにするか、その使用をサポートする特定のコンポーネント用のカスタムオブジェクトストアを設定できます。 ### [](#オブジェクトストアを設定する)オブジェクトストアを設定する アプリケーション内の他のコンポーネントから参照できるグローバルオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Global Elements (グローバル要素)\]**​ タブを開きます。 2. **\[Create (作成)\]**​ をクリックします。 3. **\[Component configurations (コンポーネント設定)\]**​ > ​**\[Object Store (オブジェクトストア)\]**​ を選択します。 4. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![Mule のグローバルオブジェクトストアを設定するプロパティパネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-object-store-global.png) または、次のコードをアプリケーション XML の最上位要素として含めることで、グローバルオブジェクトストアを作成できます。 ```xml ``` 目的の値で各属性を設定します。 各 XML 属性の定義の ​[\[Object Store Reference (オブジェクトストア参照)](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore)\]​ を参照してください。 ## [](#特定のコンポーネントのオブジェクトストアを設定する)特定のコンポーネントのオブジェクトストアを設定する 特定のコンポーネントのみで使用可能なオブジェクトストアを設定できます。たとえば、冪等性のあるメッセージ検証機能用のオブジェクトストアを設定するには、Anypoint Studio で以下の手順を実行します。 1. **\[Idempotent Message Validator (冪等性のあるメッセージ検証機能)\]**​ プロパティを開きます。 2. **\[Object Store (オブジェクトストア)\]**​ で、​**\[Edit Inline (インライン編集)\]**​ を選択します。 3. 必要な設定属性を入力して、​**\[OK\]**​ をクリックします。 ![インラインオブジェクトストア](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-object-store-inline.png) または、オブジェクトストア設定を XML 設定ファイルのコンポーネント要素内に含めることで、オブジェクトストアを作成できます。 ```xml ``` ## [](#object-store-connector-を使用したデータの管理)Object Store Connector を使用したデータの管理 Object Store Connector を使用すると、Mule アプリケーションでオブジェクトストアとやり取りするためのさまざまな操作を実行できます。操作の例として、保存、取得、削除などがあります。 使用可能な操作と設定例についての詳細は、​[「Object Store Connector」](https://docs.mulesoft.com/object-store-connector/latest/)​ドキュメントを参照してください。 ## [](#関連情報)関連情報 - [例: オブジェクトストアの定義](https://docs.mulesoft.com/object-store-connector/latest/object-store-to-define-a-new-os) - [Object Store v2](https://docs.mulesoft.com/jp/object-store/) - [Idempotent Message Validator](https://docs.mulesoft.com/jp/mule-runtime/4.9/idempotent-message-validator) - [Redelivery Policy (再配信ポリシー)](https://docs.mulesoft.com/jp/mule-runtime/4.9/redelivery-policy) - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/cache-scope) # オンプレミスでの Mule Runtime Engine の実行 アプリケーションをオンプレミスでデプロイする場合は、Mule インスタンスを完全に制御できるため、​[オンプレミスデプロイメントモデル](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-deployment-model)​の特定の特性を活用できます。 自分の環境で Mule Runtime Engine をホストする場合は、最初に​[ハードウェアおよびソフトウェアのすべての要件を満たしていることを確認し](https://docs.mulesoft.com/jp/mule-runtime/4.3/hardware-and-software-requirements)​、​[Mule をダウンロードしてインストールしてください](https://docs.mulesoft.com/jp/mule-runtime/4.3/runtime-installation-task)​。 以下のシナリオでは、Mule をインストールする必要はありません。 - 開発およびテストに Anypoint Studio (Mule が含まれる) を使用する場合 - CloudHub または Anypoint Runtime Fabric にアプリケーションをデプロイする場合。 Mule のインストールが完了したら、​[Enterprise ライセンスをインストール](https://docs.mulesoft.com/jp/mule-runtime/4.3/installing-an-enterprise-license)​して Mule Runtime Engine のすべての機能を有効化します。 [Mule Runtime Engine を起動および停止して](https://docs.mulesoft.com/jp/mule-runtime/4.3/starting-and-stopping-mule-esb)​ Mule アプリケーションをデプロイする方法を説明します。 Mule アプリケーションを本番環境に昇格する準備ができたら、​[「Mule インストールの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.3/hardening-your-mule-installation)​の手順を実行してください。 Runtime Manager を使用してオンプレミスの Mule インスタンスを管理する場合は、​[Runtime Manager エージェントを使用して登録してください](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​。 可用性、フォールトトレランス、パフォーマンスの特性を強化するための​[クラスターランタイムインスタンスの選択](https://docs.mulesoft.com/jp/mule-runtime/4.3/choosing-the-right-clustering-topology)​方法を学習します。 # オンプレミスでの Mule Runtime Engine の実行 アプリケーションをオンプレミスでデプロイする場合は、Mule インスタンスを完全に制御できるため、​[オンプレミスデプロイメントモデル](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-deployment-model)​の特定の特性を活用できます。 自分の環境で Mule Runtime Engine をホストする場合は、最初に​[ハードウェアおよびソフトウェアのすべての要件を満たしていることを確認し](https://docs.mulesoft.com/jp/mule-runtime/4.4/hardware-and-software-requirements)​、​[Mule をダウンロードしてインストールしてください](https://docs.mulesoft.com/jp/mule-runtime/4.4/runtime-installation-task)​。 以下のシナリオでは、Mule をインストールする必要はありません。 - 開発およびテストに Anypoint Studio (Mule が含まれる) を使用する場合 - CloudHub または Anypoint Runtime Fabric にアプリケーションをデプロイする場合。 Mule のインストールが完了したら、​[Enterprise ライセンスをインストール](https://docs.mulesoft.com/jp/mule-runtime/4.4/installing-an-enterprise-license)​して Mule Runtime Engine のすべての機能を有効化します。 [Mule Runtime Engine を起動および停止して](https://docs.mulesoft.com/jp/mule-runtime/4.4/starting-and-stopping-mule-esb)​ Mule アプリケーションをデプロイする方法を説明します。 Mule アプリケーションを本番環境に昇格する準備ができたら、​[「Mule インストールの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.4/hardening-your-mule-installation)​の手順を実行してください。 Runtime Manager を使用してオンプレミスの Mule インスタンスを管理する場合は、​[Runtime Manager エージェントを使用して登録してください](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​。 可用性、フォールトトレランス、パフォーマンスの特性を強化するための​[クラスターランタイムインスタンスの選択](https://docs.mulesoft.com/jp/mule-runtime/4.4/choosing-the-right-clustering-topology)​方法を学習します。 # オンプレミスでの Mule Runtime Engine の実行 アプリケーションをオンプレミスでデプロイする場合は、Mule インスタンスを完全に制御できるため、​[オンプレミスデプロイメントモデル](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-deployment-model)​の特定の特性を活用できます。 自分の環境で Mule Runtime Engine をホストする場合は、最初に​[ハードウェアおよびソフトウェアのすべての要件を満たしていることを確認し](https://docs.mulesoft.com/jp/mule-runtime/4.5/hardware-and-software-requirements)​、​[Mule をダウンロードしてインストールしてください](https://docs.mulesoft.com/jp/mule-runtime/4.5/runtime-installation-task)​。 以下のシナリオでは、Mule をインストールする必要はありません。 - 開発およびテストに Anypoint Studio (Mule が含まれる) を使用する場合 - CloudHub または Anypoint Runtime Fabric にアプリケーションをデプロイする場合。 Mule のインストールが完了したら、​[Enterprise ライセンスをインストール](https://docs.mulesoft.com/jp/mule-runtime/4.5/installing-an-enterprise-license)​して Mule Runtime Engine のすべての機能を有効化します。 [Mule Runtime Engine を起動および停止して](https://docs.mulesoft.com/jp/mule-runtime/4.5/starting-and-stopping-mule-esb)​ Mule アプリケーションをデプロイする方法を説明します。 Mule アプリケーションを本番環境に昇格する準備ができたら、​[「Mule インストールの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.5/hardening-your-mule-installation)​の手順を実行してください。 Runtime Manager を使用してオンプレミスの Mule インスタンスを管理する場合は、​[Runtime Manager エージェントを使用して登録してください](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​。 可用性、フォールトトレランス、パフォーマンスの特性を強化するための​[クラスターランタイムインスタンスの選択](https://docs.mulesoft.com/jp/mule-runtime/4.5/choosing-the-right-clustering-topology)​方法を学習します。 # オンプレミスでの Mule Runtime Engine の実行 アプリケーションをオンプレミスでデプロイする場合は、Mule インスタンスを完全に制御できるため、​[オンプレミスデプロイメントモデル](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-deployment-model)​の特定の特性を活用できます。 自分の環境で Mule Runtime Engine をホストする場合は、最初に​[ハードウェアおよびソフトウェアのすべての要件を満たしていることを確認し](https://docs.mulesoft.com/jp/mule-runtime/4.6/hardware-and-software-requirements)​、​[Mule をダウンロードしてインストールしてください](https://docs.mulesoft.com/jp/mule-runtime/4.6/runtime-installation-task)​。 以下のシナリオでは、Mule をインストールする必要はありません。 - 開発およびテストに Anypoint Studio (Mule が含まれる) を使用する場合 - CloudHub または Anypoint Runtime Fabric にアプリケーションをデプロイする場合。 Mule のインストールが完了したら、​[Enterprise ライセンスをインストール](https://docs.mulesoft.com/jp/mule-runtime/4.6/installing-an-enterprise-license)​して Mule Runtime Engine のすべての機能を有効化します。 [Mule Runtime Engine を起動および停止して](https://docs.mulesoft.com/jp/mule-runtime/4.6/starting-and-stopping-mule-esb)​ Mule アプリケーションをデプロイする方法を説明します。 Mule アプリケーションを本番環境に昇格する準備ができたら、​[「Mule インストールの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.6/hardening-your-mule-installation)​の手順を実行してください。 Runtime Manager を使用してオンプレミスの Mule インスタンスを管理する場合は、​[Runtime Manager エージェントを使用して登録してください](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​。 可用性、フォールトトレランス、パフォーマンスの特性を強化するための​[クラスターランタイムインスタンスの選択](https://docs.mulesoft.com/jp/mule-runtime/4.6/choosing-the-right-clustering-topology)​方法を学習します。 # オンプレミスでの Mule Runtime Engine の実行 アプリケーションをオンプレミスでデプロイする場合は、Mule インスタンスを完全に制御できるため、​[オンプレミスデプロイメントモデル](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-deployment-model)​の特定の特性を活用できます。 自分の環境で Mule Runtime Engine をホストする場合は、最初に​[ハードウェアおよびソフトウェアのすべての要件を満たしていることを確認し](https://docs.mulesoft.com/jp/mule-runtime/4.7/hardware-and-software-requirements)​、​[Mule をダウンロードしてインストールしてください](https://docs.mulesoft.com/jp/mule-runtime/4.7/runtime-installation-task)​。 以下のシナリオでは、Mule をインストールする必要はありません。 - 開発およびテストに Anypoint Studio (Mule が含まれる) を使用する場合 - CloudHub または Anypoint Runtime Fabric にアプリケーションをデプロイする場合。 Mule のインストールが完了したら、​[Enterprise ライセンスをインストール](https://docs.mulesoft.com/jp/mule-runtime/4.7/installing-an-enterprise-license)​して Mule Runtime Engine のすべての機能を有効化します。 [Mule Runtime Engine を起動および停止して](https://docs.mulesoft.com/jp/mule-runtime/4.7/starting-and-stopping-mule-esb)​ Mule アプリケーションをデプロイする方法を説明します。 Mule アプリケーションを本番環境に昇格する準備ができたら、​[「Mule インストールの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.7/hardening-your-mule-installation)​の手順を実行してください。 Runtime Manager を使用してオンプレミスの Mule インスタンスを管理する場合は、​[Runtime Manager エージェントを使用して登録してください](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​。 可用性、フォールトトレランス、パフォーマンスの特性を強化するための​[クラスターランタイムインスタンスの選択](https://docs.mulesoft.com/jp/mule-runtime/4.7/choosing-the-right-clustering-topology)​方法を学習します。 # オンプレミスでの Mule Runtime Engine の実行 アプリケーションをオンプレミスでデプロイする場合は、Mule インスタンスを完全に制御できるため、​[オンプレミスデプロイメントモデル](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-deployment-model)​の特定の特性を活用できます。 自分の環境で Mule Runtime Engine をホストする場合は、最初に​[ハードウェアおよびソフトウェアのすべての要件を満たしていることを確認し](https://docs.mulesoft.com/jp/mule-runtime/4.8/hardware-and-software-requirements)​、​[Mule をダウンロードしてインストールしてください](https://docs.mulesoft.com/jp/mule-runtime/4.8/runtime-installation-task)​。 以下のシナリオでは、Mule をインストールする必要はありません。 - 開発およびテストに Anypoint Studio (Mule が含まれる) を使用する場合 - CloudHub または Anypoint Runtime Fabric にアプリケーションをデプロイする場合。 Mule のインストールが完了したら、​[Enterprise ライセンスをインストール](https://docs.mulesoft.com/jp/mule-runtime/4.8/installing-an-enterprise-license)​して Mule Runtime Engine のすべての機能を有効化します。 [Mule Runtime Engine を起動および停止して](https://docs.mulesoft.com/jp/mule-runtime/4.8/starting-and-stopping-mule-esb)​ Mule アプリケーションをデプロイする方法を説明します。 Mule アプリケーションを本番環境に昇格する準備ができたら、​[「Mule インストールの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.8/hardening-your-mule-installation)​の手順を実行してください。 Runtime Manager を使用してオンプレミスの Mule インスタンスを管理する場合は、​[Runtime Manager エージェントを使用して登録してください](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​。 可用性、フォールトトレランス、パフォーマンスの特性を強化するための​[クラスターランタイムインスタンスの選択](https://docs.mulesoft.com/jp/mule-runtime/4.8/choosing-the-right-clustering-topology)​方法を学習します。 # オンプレミスでの Mule Runtime Engine の実行 アプリケーションをオンプレミスでデプロイする場合は、Mule インスタンスを完全に制御できるため、​[オンプレミスデプロイメントモデル](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-deployment-model)​の特定の特性を活用できます。 自分の環境で Mule Runtime Engine をホストする場合は、最初に​[ハードウェアおよびソフトウェアのすべての要件を満たしていることを確認し](https://docs.mulesoft.com/jp/mule-runtime/4.9/hardware-and-software-requirements)​、​[Mule をダウンロードしてインストールしてください](https://docs.mulesoft.com/jp/mule-runtime/4.9/runtime-installation-task)​。 以下のシナリオでは、Mule をインストールする必要はありません。 - 開発およびテストに Anypoint Studio (Mule が含まれる) を使用する場合 - CloudHub または Anypoint Runtime Fabric にアプリケーションをデプロイする場合。 Mule のインストールが完了したら、​[Enterprise ライセンスをインストール](https://docs.mulesoft.com/jp/mule-runtime/4.9/installing-an-enterprise-license)​して Mule Runtime Engine のすべての機能を有効化します。 [Mule Runtime Engine を起動および停止して](https://docs.mulesoft.com/jp/mule-runtime/4.9/starting-and-stopping-mule-esb)​ Mule アプリケーションをデプロイする方法を説明します。 Mule アプリケーションを本番環境に昇格する準備ができたら、​[「Mule インストールの強化」](https://docs.mulesoft.com/jp/mule-runtime/4.9/hardening-your-mule-installation)​の手順を実行してください。 Runtime Manager を使用してオンプレミスの Mule インスタンスを管理する場合は、​[Runtime Manager エージェントを使用して登録してください](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​。 可用性、フォールトトレランス、パフォーマンスの特性を強化するための​[クラスターランタイムインスタンスの選択](https://docs.mulesoft.com/jp/mule-runtime/4.9/choosing-the-right-clustering-topology)​方法を学習します。 # オンプレミスデプロイモデル Mule アプリケーションのデプロイメントには 2 つの大きな要素があります。 - Mule Runtime Engine インスタンス - その Mule インスタンスにデプロイされる Mule アプリケーション CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが管理します。 アプリケーションをオンプレミスでデプロイする場合は、Mule アプリケーションを実行する Mule Runtime Engine のインストールと設定はユーザーの責任となります。オンプレミスインスタンスは (CloudHub や Runtime Fabric デプロイメントとは異なり) ユーザーが完全に制御するため、オンプレミスデプロイに特有の特性について理解しておく必要があります。 ## [](#1-つの-mule-インスタンスでの複数のアプリケーションの実行)1 つの Mule インスタンスでの複数のアプリケーションの実行 Mule Runtime Engine の 1 つのインスタンスで複数のアプリケーションを実行することができるため、異なるアプリケーションで競合したり、情報を共有したりせずに同じ名前空間を利用できます。これにより、次のような利点がもたらされます。 - 複雑なアプリケーションをそれぞれが特有のロジックを持つ複数の Mule アプリケーションに分割して、これらの Mule アプリケーションを 1 つの Mule インスタンスにデプロイできます。 - ドメインを使用して、複数のアプリケーション間で設定を共有できます。 - アプリケーションは異なるライブラリバージョンに依存できます。 - 複数のバージョンのアプリケーションを同じ Mule インスタンス内で実行できます。 ## [](#アプリケーションのパッケージとデプロイメント)アプリケーションのパッケージとデプロイメント Mule Runtime Engine は、すべてのアプリケーションを実行時に展開し、元の ​`.jar`​ ファイルを ​`/apps`​ ディレクトリから削除し、アプリケーションごとに新しいフォルダーを作成して、各フォルダーにアプリケーションファイルと同じ名前 (から ​`.jar`​ 拡張子を削除したもの) を付けます。 デプロイメントが成功したかどうかは以下で確認してください。 - コンソールに表示されるアプリケーションの状況が ​`DEPLOYED`​ である。 - Mule インスタンスの ​`/apps`​ ディレクトリに展開されたアプリケーションフォルダー (例: `stockTrader.jar`​ であれば ​`$MULE_HOME/apps/stockTrader`​) が存在する。 - 実行中のアプリケーション用のアンカーファイル (例: `$MULE_HOME/apps/stockTrader-anchor.txt`​) が存在する。 アプリケーションを別の場所に保存する場合、​`$MULE_HOME/apps`​ からアプリケーションディレクトリへのシンボリックリンクを作成して、Unix ベースのシステムに保存できます。 ## [](#アプリケーションとドメインのデプロイメント)アプリケーションとドメインのデプロイメント すべてのアプリケーションは​_ドメイン_​内で一緒にデプロイされます。デフォルトでは、アプリケーションは ​`default`​ のドメインを参照し、追加の設定は必要ありません。コンソールでアプリケーションと一緒にドメインがデプロイされるのを確認できます。 ![deploy+domain](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploy-domain.png) 複数のアプリケーションを同じ Mule インスタンスにデプロイしていて、アプリケーションが同じリソースを共有する必要がある場合は、共通の​_ドメイン_​を作成して複数のプロジェクトから参照できる設定を定義できます。この方法なら、競合を起こすことなく、同じ HTTP ホストおよびポートから異なるプロジェクトの異なるサービスを公開できます。 ## [](#アプリケーションのホットデプロイメント)アプリケーションのホットデプロイメント Mule アプリケーションの設定ファイルとカスタムクラスを変更した場合は、Mule を再起動せずにそれらを読み込み直すことができます。 Mule は、​`$MULE_HOME/apps`​ ディレクトリ下の設定ファイルが更新されているかどうかを 3 秒ごとに確認し、更新された設定ファイルを見つけると、設定ファイルと JAR をそのアプリケーションの ​`java`​ ソースディレクトリに再読み込みします。 Mule を起動し、​`mule.deploy.applications`​ プロパティを使用してアプリケーションを指定する場合、ホットデプロイメントプロセスは、指定されたアプリケーションに対してのみ機能します。 アプリケーションを再読み込みするには、以下の操作を実行できます。 - 該当のアプリケーションのアンカーファイルを ​`touch`​ します。 - `mule-artifact.json`​ ファイル内で宣言されている Mule 設定ファイルのいずれかを ​`touch`​ または更新します。 たとえば、カスタムクラスの 1 つを変更する場合、そのカスタムクラスに変更を加え、更新したクラスを Java ディレクトリにコピーした後、アンカーファイルを ​`touch`​ します。 ## [](#mule-インスタンスと管理ペイン間の通信)Mule インスタンスと管理ペイン間の通信 Mule インスタンスは管理ペインを使用して個別に実行され、インテグレーションロジックの実行や API 要求の提供を行います。このアーキテクチャにより、Mule Runtime Engine を戦略的にデプロイし、通信のボトルネックにならないようにすることができます。 Mule インスタンスが管理ペインから切断されるようなイベントが発生すると、設計どおりに実行が継続され、インテグレーションの実行や API の提供が中断することなく行われます。ただし、新しいまたは更新されたポリシーは、接続が再確立されるまで取り込まれず、更新されません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.3/shared-resources) - [オンプレミスでの Mule Runtime Engine の実行](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-standalone) # オンプレミスデプロイモデル Mule アプリケーションのデプロイメントには 2 つの大きな要素があります。 - Mule Runtime Engine インスタンス - その Mule インスタンスにデプロイされる Mule アプリケーション CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが管理します。 アプリケーションをオンプレミスでデプロイする場合は、Mule アプリケーションを実行する Mule Runtime Engine のインストールと設定はユーザーの責任となります。オンプレミスインスタンスは (CloudHub や Runtime Fabric デプロイメントとは異なり) ユーザーが完全に制御するため、オンプレミスデプロイに特有の特性について理解しておく必要があります。 ## [](#1-つの-mule-インスタンスでの複数のアプリケーションの実行)1 つの Mule インスタンスでの複数のアプリケーションの実行 Mule Runtime Engine の 1 つのインスタンスで複数のアプリケーションを実行することができるため、異なるアプリケーションで競合したり、情報を共有したりせずに同じ名前空間を利用できます。これにより、次のような利点がもたらされます。 - 複雑なアプリケーションをそれぞれが特有のロジックを持つ複数の Mule アプリケーションに分割して、これらの Mule アプリケーションを 1 つの Mule インスタンスにデプロイできます。 - ドメインを使用して、複数のアプリケーション間で設定を共有できます。 - アプリケーションは異なるライブラリバージョンに依存できます。 - 複数のバージョンのアプリケーションを同じ Mule インスタンス内で実行できます。 ## [](#アプリケーションのパッケージとデプロイメント)アプリケーションのパッケージとデプロイメント Mule Runtime Engine は、すべてのアプリケーションを実行時に展開し、元の ​`.jar`​ ファイルを ​`/apps`​ ディレクトリから削除し、アプリケーションごとに新しいフォルダーを作成して、各フォルダーにアプリケーションファイルと同じ名前 (から ​`.jar`​ 拡張子を削除したもの) を付けます。 デプロイメントが成功したかどうかは以下で確認してください。 - コンソールに表示されるアプリケーションの状況が ​`DEPLOYED`​ である。 - Mule インスタンスの ​`/apps`​ ディレクトリに展開されたアプリケーションフォルダー (例: `stockTrader.jar`​ であれば ​`$MULE_HOME/apps/stockTrader`​) が存在する。 - 実行中のアプリケーション用のアンカーファイル (例: `$MULE_HOME/apps/stockTrader-anchor.txt`​) が存在する。 アプリケーションを別の場所に保存する場合、​`$MULE_HOME/apps`​ からアプリケーションディレクトリへのシンボリックリンクを作成して、Unix ベースのシステムに保存できます。 ## [](#アプリケーションとドメインのデプロイメント)アプリケーションとドメインのデプロイメント すべてのアプリケーションは​_ドメイン_​内で一緒にデプロイされます。デフォルトでは、アプリケーションは ​`default`​ のドメインを参照し、追加の設定は必要ありません。コンソールでアプリケーションと一緒にドメインがデプロイされるのを確認できます。 ![deploy+domain](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploy-domain.png) 複数のアプリケーションを同じ Mule インスタンスにデプロイしていて、アプリケーションが同じリソースを共有する必要がある場合は、共通の​_ドメイン_​を作成して複数のプロジェクトから参照できる設定を定義できます。この方法なら、競合を起こすことなく、同じ HTTP ホストおよびポートから異なるプロジェクトの異なるサービスを公開できます。 ## [](#アプリケーションのホットデプロイメント)アプリケーションのホットデプロイメント Mule アプリケーションの設定ファイルとカスタムクラスを変更した場合は、Mule を再起動せずにそれらを読み込み直すことができます。 Mule は、​`$MULE_HOME/apps`​ ディレクトリ下の設定ファイルが更新されているかどうかを 3 秒ごとに確認し、更新された設定ファイルを見つけると、設定ファイルと JAR をそのアプリケーションの ​`java`​ ソースディレクトリに再読み込みします。 Mule を起動し、​`mule.deploy.applications`​ プロパティを使用してアプリケーションを指定する場合、ホットデプロイメントプロセスは、指定されたアプリケーションに対してのみ機能します。 アプリケーションを再読み込みするには、以下の操作を実行できます。 - 該当のアプリケーションのアンカーファイルを ​`touch`​ します。 - `mule-artifact.json`​ ファイル内で宣言されている Mule 設定ファイルのいずれかを ​`touch`​ または更新します。 たとえば、カスタムクラスの 1 つを変更する場合、そのカスタムクラスに変更を加え、更新したクラスを Java ディレクトリにコピーした後、アンカーファイルを ​`touch`​ します。 ## [](#mule-インスタンスと管理ペイン間の通信)Mule インスタンスと管理ペイン間の通信 Mule インスタンスは管理ペインを使用して個別に実行され、インテグレーションロジックの実行や API 要求の提供を行います。このアーキテクチャにより、Mule Runtime Engine を戦略的にデプロイし、通信のボトルネックにならないようにすることができます。 Mule インスタンスが管理ペインから切断されるようなイベントが発生すると、設計どおりに実行が継続され、インテグレーションの実行や API の提供が中断することなく行われます。ただし、新しいまたは更新されたポリシーは、接続が再確立されるまで取り込まれず、更新されません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.4/shared-resources) - [オンプレミスでの Mule Runtime Engine の実行](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-standalone) # オンプレミスデプロイモデル Mule アプリケーションのデプロイメントには 2 つの大きな要素があります。 - Mule Runtime Engine インスタンス - その Mule インスタンスにデプロイされる Mule アプリケーション CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが管理します。 アプリケーションをオンプレミスでデプロイする場合は、Mule アプリケーションを実行する Mule Runtime Engine のインストールと設定はユーザーの責任となります。オンプレミスインスタンスは (CloudHub や Runtime Fabric デプロイメントとは異なり) ユーザーが完全に制御するため、オンプレミスデプロイに特有の特性について理解しておく必要があります。 ## [](#1-つの-mule-インスタンスでの複数のアプリケーションの実行)1 つの Mule インスタンスでの複数のアプリケーションの実行 Mule Runtime Engine の 1 つのインスタンスで複数のアプリケーションを実行することができるため、異なるアプリケーションで競合したり、情報を共有したりせずに同じ名前空間を利用できます。これにより、次のような利点がもたらされます。 - 複雑なアプリケーションをそれぞれが特有のロジックを持つ複数の Mule アプリケーションに分割して、これらの Mule アプリケーションを 1 つの Mule インスタンスにデプロイできます。 - ドメインを使用して、複数のアプリケーション間で設定を共有できます。 - アプリケーションは異なるライブラリバージョンに依存できます。 - 複数のバージョンのアプリケーションを同じ Mule インスタンス内で実行できます。 ## [](#アプリケーションのパッケージとデプロイメント)アプリケーションのパッケージとデプロイメント Mule Runtime Engine は、すべてのアプリケーションを実行時に展開し、元の ​`.jar`​ ファイルを ​`/apps`​ ディレクトリから削除し、アプリケーションごとに新しいフォルダーを作成して、各フォルダーにアプリケーションファイルと同じ名前 (から ​`.jar`​ 拡張子を削除したもの) を付けます。 デプロイメントが成功したかどうかは以下で確認してください。 - コンソールに表示されるアプリケーションの状況が ​`DEPLOYED`​ である。 - Mule インスタンスの ​`/apps`​ ディレクトリに展開されたアプリケーションフォルダー (例: `stockTrader.jar`​ であれば ​`$MULE_HOME/apps/stockTrader`​) が存在する。 - 実行中のアプリケーション用のアンカーファイル (例: `$MULE_HOME/apps/stockTrader-anchor.txt`​) が存在する。 アプリケーションを別の場所に保存する場合、​`$MULE_HOME/apps`​ からアプリケーションディレクトリへのシンボリックリンクを作成して、Unix ベースのシステムに保存できます。 ## [](#アプリケーションとドメインのデプロイメント)アプリケーションとドメインのデプロイメント すべてのアプリケーションは​_ドメイン_​内で一緒にデプロイされます。デフォルトでは、アプリケーションは ​`default`​ のドメインを参照し、追加の設定は必要ありません。コンソールでアプリケーションと一緒にドメインがデプロイされるのを確認できます。 ![deploy+domain](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploy-domain.png) 複数のアプリケーションを同じ Mule インスタンスにデプロイしていて、アプリケーションが同じリソースを共有する必要がある場合は、共通の​_ドメイン_​を作成して複数のプロジェクトから参照できる設定を定義できます。この方法なら、競合を起こすことなく、同じ HTTP ホストおよびポートから異なるプロジェクトの異なるサービスを公開できます。 ## [](#アプリケーションのホットデプロイメント)アプリケーションのホットデプロイメント Mule アプリケーションの設定ファイルとカスタムクラスを変更した場合は、Mule を再起動せずにそれらを読み込み直すことができます。Mule アプリケーションの設定ファイルから変更を取得するには、システムプロパティ ​`mule.deployment.forceParseConfigXmls`​ が ​`true`​ に設定されている必要があります。Mule アプリケーションの設定ファイルを変更して強制的に再デプロイした場合、アプリケーションがパッケージ化された場合に行われる検証は実行されないことに注意してください。 Mule は、​`$MULE_HOME/apps`​ ディレクトリ下の設定ファイルが更新されているかどうかを 3 秒ごとに確認し、更新された設定ファイルを見つけると、設定ファイルと JAR をそのアプリケーションの ​`java`​ ソースディレクトリに再読み込みします。 Mule を起動し、​`mule.deploy.applications`​ プロパティを使用してアプリケーションを指定する場合、ホットデプロイメントプロセスは、指定されたアプリケーションに対してのみ機能します。 アプリケーションを再読み込みするには、以下の操作を実行できます。 - 該当のアプリケーションのアンカーファイルを ​`touch`​ します。 - `mule-artifact.json`​ ファイル内で宣言されている Mule 設定ファイルのいずれかを ​`touch`​ または更新します。 たとえば、カスタムクラスの 1 つを変更する場合、そのカスタムクラスに変更を加え、更新したクラスを Java ディレクトリにコピーした後、アンカーファイルを ​`touch`​ します。 ## [](#mule-インスタンスと管理ペイン間の通信)Mule インスタンスと管理ペイン間の通信 Mule インスタンスは管理ペインを使用して個別に実行され、インテグレーションロジックの実行や API 要求の提供を行います。このアーキテクチャにより、Mule Runtime Engine を戦略的にデプロイし、通信のボトルネックにならないようにすることができます。 Mule インスタンスが管理ペインから切断されるようなイベントが発生すると、設計どおりに実行が継続され、インテグレーションの実行や API の提供が中断することなく行われます。ただし、新しいまたは更新されたポリシーは、接続が再確立されるまで取り込まれず、更新されません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.5/shared-resources) - [オンプレミスでの Mule Runtime Engine の実行](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-standalone) # オンプレミスデプロイモデル Mule アプリケーションのデプロイメントには 2 つの大きな要素があります。 - Mule Runtime Engine インスタンス - その Mule インスタンスにデプロイされる Mule アプリケーション CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが管理します。 アプリケーションをオンプレミスでデプロイする場合は、Mule アプリケーションを実行する Mule Runtime Engine のインストールと設定はユーザーの責任となります。オンプレミスインスタンスは (CloudHub や Runtime Fabric デプロイメントとは異なり) ユーザーが完全に制御するため、オンプレミスデプロイに特有の特性について理解しておく必要があります。 ## [](#1-つの-mule-インスタンスでの複数のアプリケーションの実行)1 つの Mule インスタンスでの複数のアプリケーションの実行 Mule Runtime Engine の 1 つのインスタンスで複数のアプリケーションを実行することができるため、異なるアプリケーションで競合したり、情報を共有したりせずに同じ名前空間を利用できます。これにより、次のような利点がもたらされます。 - 複雑なアプリケーションをそれぞれが特有のロジックを持つ複数の Mule アプリケーションに分割して、これらの Mule アプリケーションを 1 つの Mule インスタンスにデプロイできます。 - ドメインを使用して、複数のアプリケーション間で設定を共有できます。 - アプリケーションは異なるライブラリバージョンに依存できます。 - 複数のバージョンのアプリケーションを同じ Mule インスタンス内で実行できます。 ## [](#アプリケーションのパッケージとデプロイメント)アプリケーションのパッケージとデプロイメント Mule Runtime Engine は、すべてのアプリケーションを実行時に展開し、元の ​`.jar`​ ファイルを ​`/apps`​ ディレクトリから削除し、アプリケーションごとに新しいフォルダーを作成して、各フォルダーにアプリケーションファイルと同じ名前 (から ​`.jar`​ 拡張子を削除したもの) を付けます。 デプロイメントが成功したかどうかは以下で確認してください。 - コンソールに表示されるアプリケーションの状況が ​`DEPLOYED`​ である。 - Mule インスタンスの ​`/apps`​ ディレクトリに展開されたアプリケーションフォルダー (例: `stockTrader.jar`​ であれば ​`$MULE_HOME/apps/stockTrader`​) が存在する。 - 実行中のアプリケーション用のアンカーファイル (例: `$MULE_HOME/apps/stockTrader-anchor.txt`​) が存在する。 アプリケーションを別の場所に保存する場合、​`$MULE_HOME/apps`​ からアプリケーションディレクトリへのシンボリックリンクを作成して、Unix ベースのシステムに保存できます。 ## [](#アプリケーションとドメインのデプロイメント)アプリケーションとドメインのデプロイメント すべてのアプリケーションは​_ドメイン_​内で一緒にデプロイされます。デフォルトでは、アプリケーションは ​`default`​ のドメインを参照し、追加の設定は必要ありません。コンソールでアプリケーションと一緒にドメインがデプロイされるのを確認できます。 ![deploy+domain](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploy-domain.png) 複数のアプリケーションを同じ Mule インスタンスにデプロイしていて、アプリケーションが同じリソースを共有する必要がある場合は、共通の​_ドメイン_​を作成して複数のプロジェクトから参照できる設定を定義できます。この方法なら、競合を起こすことなく、同じ HTTP ホストおよびポートから異なるプロジェクトの異なるサービスを公開できます。 ## [](#アプリケーションのホットデプロイメント)アプリケーションのホットデプロイメント Mule アプリケーションの設定ファイルとカスタムクラスを変更した場合は、Mule を再起動せずにそれらを読み込み直すことができます。Mule アプリケーションの設定ファイルから変更を取得するには、システムプロパティ ​`mule.deployment.forceParseConfigXmls`​ が ​`true`​ に設定されている必要があります。Mule アプリケーションの設定ファイルを変更して強制的に再デプロイした場合、アプリケーションがパッケージ化された場合に行われる検証は実行されないことに注意してください。 Mule は、​`$MULE_HOME/apps`​ ディレクトリ下の設定ファイルが更新されているかどうかを 3 秒ごとに確認し、更新された設定ファイルを見つけると、設定ファイルと JAR をそのアプリケーションの ​`java`​ ソースディレクトリに再読み込みします。 Mule を起動し、​`mule.deploy.applications`​ プロパティを使用してアプリケーションを指定する場合、ホットデプロイメントプロセスは、指定されたアプリケーションに対してのみ機能します。 アプリケーションを再読み込みするには、以下の操作を実行できます。 - 該当のアプリケーションのアンカーファイルを ​`touch`​ します。 - `mule-artifact.json`​ ファイル内で宣言されている Mule 設定ファイルのいずれかを ​`touch`​ または更新します。 たとえば、カスタムクラスの 1 つを変更する場合、そのカスタムクラスに変更を加え、更新したクラスを Java ディレクトリにコピーした後、アンカーファイルを ​`touch`​ します。 ## [](#mule-インスタンスと管理ペイン間の通信)Mule インスタンスと管理ペイン間の通信 Mule インスタンスは管理ペインを使用して個別に実行され、インテグレーションロジックの実行や API 要求の提供を行います。このアーキテクチャにより、Mule Runtime Engine を戦略的にデプロイし、通信のボトルネックにならないようにすることができます。 Mule インスタンスが管理ペインから切断されるようなイベントが発生すると、設計どおりに実行が継続され、インテグレーションの実行や API の提供が中断することなく行われます。ただし、新しいまたは更新されたポリシーは、接続が再確立されるまで取り込まれず、更新されません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.6/shared-resources) - [オンプレミスでの Mule Runtime Engine の実行](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-standalone) # オンプレミスデプロイモデル Mule アプリケーションのデプロイメントには 2 つの大きな要素があります。 - Mule Runtime Engine インスタンス - その Mule インスタンスにデプロイされる Mule アプリケーション CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが管理します。 アプリケーションをオンプレミスでデプロイする場合は、Mule アプリケーションを実行する Mule Runtime Engine のインストールと設定はユーザーの責任となります。オンプレミスインスタンスは (CloudHub や Runtime Fabric デプロイメントとは異なり) ユーザーが完全に制御するため、オンプレミスデプロイに特有の特性について理解しておく必要があります。 ## [](#1-つの-mule-インスタンスでの複数のアプリケーションの実行)1 つの Mule インスタンスでの複数のアプリケーションの実行 Mule Runtime Engine の 1 つのインスタンスで複数のアプリケーションを実行することができるため、異なるアプリケーションで競合したり、情報を共有したりせずに同じ名前空間を利用できます。これにより、次のような利点がもたらされます。 - 複雑なアプリケーションをそれぞれが特有のロジックを持つ複数の Mule アプリケーションに分割して、これらの Mule アプリケーションを 1 つの Mule インスタンスにデプロイできます。 - ドメインを使用して、複数のアプリケーション間で設定を共有できます。 - アプリケーションは異なるライブラリバージョンに依存できます。 - 複数のバージョンのアプリケーションを同じ Mule インスタンス内で実行できます。 ## [](#アプリケーションのパッケージとデプロイメント)アプリケーションのパッケージとデプロイメント Mule Runtime Engine は、すべてのアプリケーションを実行時に展開し、元の ​`.jar`​ ファイルを ​`/apps`​ ディレクトリから削除し、アプリケーションごとに新しいフォルダーを作成して、各フォルダーにアプリケーションファイルと同じ名前 (から ​`.jar`​ 拡張子を削除したもの) を付けます。 デプロイメントが成功したかどうかは以下で確認してください。 - コンソールに表示されるアプリケーションの状況が ​`DEPLOYED`​ である。 - Mule インスタンスの ​`/apps`​ ディレクトリに展開されたアプリケーションフォルダー (例: `stockTrader.jar`​ であれば ​`$MULE_HOME/apps/stockTrader`​) が存在する。 - 実行中のアプリケーション用のアンカーファイル (例: `$MULE_HOME/apps/stockTrader-anchor.txt`​) が存在する。 アプリケーションを別の場所に保存する場合、​`$MULE_HOME/apps`​ からアプリケーションディレクトリへのシンボリックリンクを作成して、Unix ベースのシステムに保存できます。 ## [](#アプリケーションとドメインのデプロイメント)アプリケーションとドメインのデプロイメント すべてのアプリケーションは​_ドメイン_​内で一緒にデプロイされます。デフォルトでは、アプリケーションは ​`default`​ のドメインを参照し、追加の設定は必要ありません。コンソールでアプリケーションと一緒にドメインがデプロイされるのを確認できます。 ![ドメインとデプロイ済みアプリケーションおよびその状況](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/deploy-domain.png) 複数のアプリケーションを同じ Mule インスタンスにデプロイしていて、アプリケーションが同じリソースを共有する必要がある場合は、共通の​_ドメイン_​を作成して複数のプロジェクトから参照できる設定を定義できます。この方法なら、競合を起こすことなく、同じ HTTP ホストおよびポートから異なるプロジェクトの異なるサービスを公開できます。 ## [](#アプリケーションのホットデプロイメント)アプリケーションのホットデプロイメント Mule アプリケーションの設定ファイルとカスタムクラスを変更した場合は、Mule を再起動せずにそれらを読み込み直すことができます。Mule アプリケーションの設定ファイルから変更を取得するには、システムプロパティ ​`mule.deployment.forceParseConfigXmls`​ が ​`true`​ に設定されている必要があります。Mule アプリケーションの設定ファイルを変更して強制的に再デプロイした場合、アプリケーションがパッケージ化された場合に行われる検証は実行されないことに注意してください。 Mule は、​`$MULE_HOME/apps`​ ディレクトリ下の設定ファイルが更新されているかどうかを 3 秒ごとに確認し、更新された設定ファイルを見つけると、設定ファイルと JAR をそのアプリケーションの ​`java`​ ソースディレクトリに再読み込みします。 Mule を起動し、​`mule.deploy.applications`​ プロパティを使用してアプリケーションを指定する場合、ホットデプロイメントプロセスは、指定されたアプリケーションに対してのみ機能します。 アプリケーションを再読み込みするには、以下の操作を実行できます。 - 該当のアプリケーションのアンカーファイルを ​`touch`​ します。 - `mule-artifact.json`​ ファイル内で宣言されている Mule 設定ファイルのいずれかを ​`touch`​ または更新します。 たとえば、カスタムクラスの 1 つを変更する場合、そのカスタムクラスに変更を加え、更新したクラスを Java ディレクトリにコピーした後、アンカーファイルを ​`touch`​ します。 ## [](#mule-インスタンスと管理ペイン間の通信)Mule インスタンスと管理ペイン間の通信 Mule インスタンスは管理ペインを使用して個別に実行され、インテグレーションロジックの実行や API 要求の提供を行います。このアーキテクチャにより、Mule Runtime Engine を戦略的にデプロイし、通信のボトルネックにならないようにすることができます。 Mule インスタンスが管理ペインから切断されるようなイベントが発生すると、設計どおりに実行が継続され、インテグレーションの実行や API の提供が中断することなく行われます。ただし、新しいまたは更新されたポリシーは、接続が再確立されるまで取り込まれず、更新されません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.7/shared-resources) - [オンプレミスでの Mule Runtime Engine の実行](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-standalone) # オンプレミスデプロイモデル Mule アプリケーションのデプロイメントには 2 つの大きな要素があります。 - Mule Runtime Engine インスタンス - その Mule インスタンスにデプロイされる Mule アプリケーション CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが管理します。 アプリケーションをオンプレミスでデプロイする場合は、Mule アプリケーションを実行する Mule Runtime Engine のインストールと設定はユーザーの責任となります。オンプレミスインスタンスは (CloudHub や Runtime Fabric デプロイメントとは異なり) ユーザーが完全に制御するため、オンプレミスデプロイに特有の特性について理解しておく必要があります。 ## [](#1-つの-mule-インスタンスでの複数のアプリケーションの実行)1 つの Mule インスタンスでの複数のアプリケーションの実行 Mule Runtime Engine の 1 つのインスタンスで複数のアプリケーションを実行することができるため、異なるアプリケーションで競合したり、情報を共有したりせずに同じ名前空間を利用できます。これにより、次のような利点がもたらされます。 - 複雑なアプリケーションをそれぞれが特有のロジックを持つ複数の Mule アプリケーションに分割して、これらの Mule アプリケーションを 1 つの Mule インスタンスにデプロイできます。 - ドメインを使用して、複数のアプリケーション間で設定を共有できます。 - アプリケーションは異なるライブラリバージョンに依存できます。 - 複数のバージョンのアプリケーションを同じ Mule インスタンス内で実行できます。 ## [](#アプリケーションのパッケージとデプロイメント)アプリケーションのパッケージとデプロイメント Mule Runtime Engine は、すべてのアプリケーションを実行時に展開し、元の ​`.jar`​ ファイルを ​`/apps`​ ディレクトリから削除し、アプリケーションごとに新しいフォルダーを作成して、各フォルダーにアプリケーションファイルと同じ名前 (から ​`.jar`​ 拡張子を削除したもの) を付けます。 デプロイメントが成功したかどうかは以下で確認してください。 - コンソールに表示されるアプリケーションの状況が ​`DEPLOYED`​ である。 - Mule インスタンスの ​`/apps`​ ディレクトリに展開されたアプリケーションフォルダー (例: `stockTrader.jar`​ であれば ​`$MULE_HOME/apps/stockTrader`​) が存在する。 - 実行中のアプリケーション用のアンカーファイル (例: `$MULE_HOME/apps/stockTrader-anchor.txt`​) が存在する。 アプリケーションを別の場所に保存する場合、​`$MULE_HOME/apps`​ からアプリケーションディレクトリへのシンボリックリンクを作成して、Unix ベースのシステムに保存できます。 ## [](#アプリケーションとドメインのデプロイメント)アプリケーションとドメインのデプロイメント すべてのアプリケーションは​_ドメイン_​内で一緒にデプロイされます。デフォルトでは、アプリケーションは ​`default`​ のドメインを参照し、追加の設定は必要ありません。コンソールでアプリケーションと一緒にドメインがデプロイされるのを確認できます。 ![ドメインとデプロイ済みアプリケーションおよびその状況](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/deploy-domain.png) 複数のアプリケーションを同じ Mule インスタンスにデプロイしていて、アプリケーションが同じリソースを共有する必要がある場合は、共通の​_ドメイン_​を作成して複数のプロジェクトから参照できる設定を定義できます。この方法なら、競合を起こすことなく、同じ HTTP ホストおよびポートから異なるプロジェクトの異なるサービスを公開できます。 ## [](#アプリケーションのホットデプロイメント)アプリケーションのホットデプロイメント Mule アプリケーションの設定ファイルとカスタムクラスを変更した場合は、Mule を再起動せずにそれらを読み込み直すことができます。Mule アプリケーションの設定ファイルから変更を取得するには、システムプロパティ ​`mule.deployment.forceParseConfigXmls`​ が ​`true`​ に設定されている必要があります。Mule アプリケーションの設定ファイルを変更して強制的に再デプロイした場合、アプリケーションがパッケージ化された場合に行われる検証は実行されないことに注意してください。 Mule は、​`$MULE_HOME/apps`​ ディレクトリ下の設定ファイルが更新されているかどうかを 3 秒ごとに確認し、更新された設定ファイルを見つけると、設定ファイルと JAR をそのアプリケーションの ​`java`​ ソースディレクトリに再読み込みします。 Mule を起動し、​`mule.deploy.applications`​ プロパティを使用してアプリケーションを指定する場合、ホットデプロイメントプロセスは、指定されたアプリケーションに対してのみ機能します。 アプリケーションを再読み込みするには、以下の操作を実行できます。 - 該当のアプリケーションのアンカーファイルを ​`touch`​ します。 - `mule-artifact.json`​ ファイル内で宣言されている Mule 設定ファイルのいずれかを ​`touch`​ または更新します。 たとえば、カスタムクラスの 1 つを変更する場合、そのカスタムクラスに変更を加え、更新したクラスを Java ディレクトリにコピーした後、アンカーファイルを ​`touch`​ します。 ## [](#mule-インスタンスと管理ペイン間の通信)Mule インスタンスと管理ペイン間の通信 Mule インスタンスは管理ペインを使用して個別に実行され、インテグレーションロジックの実行や API 要求の提供を行います。このアーキテクチャにより、Mule Runtime Engine を戦略的にデプロイし、通信のボトルネックにならないようにすることができます。 Mule インスタンスが管理ペインから切断されるようなイベントが発生すると、設計どおりに実行が継続され、インテグレーションの実行や API の提供が中断することなく行われます。ただし、新しいまたは更新されたポリシーは、接続が再確立されるまで取り込まれず、更新されません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.8/shared-resources) - [オンプレミスでの Mule Runtime Engine の実行](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-standalone) # オンプレミスデプロイモデル Mule アプリケーションのデプロイメントには 2 つの大きな要素があります。 - Mule Runtime Engine インスタンス - その Mule インスタンスにデプロイされる Mule アプリケーション CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが管理します。 アプリケーションをオンプレミスでデプロイする場合は、Mule アプリケーションを実行する Mule Runtime Engine のインストールと設定はユーザーの責任となります。オンプレミスインスタンスは (CloudHub や Runtime Fabric デプロイメントとは異なり) ユーザーが完全に制御するため、オンプレミスデプロイに特有の特性について理解しておく必要があります。 ## [](#1-つの-mule-インスタンスでの複数のアプリケーションの実行)1 つの Mule インスタンスでの複数のアプリケーションの実行 Mule Runtime Engine の 1 つのインスタンスで複数のアプリケーションを実行することができるため、異なるアプリケーションで競合したり、情報を共有したりせずに同じ名前空間を利用できます。これにより、次のような利点がもたらされます。 - 複雑なアプリケーションをそれぞれが特有のロジックを持つ複数の Mule アプリケーションに分割して、これらの Mule アプリケーションを 1 つの Mule インスタンスにデプロイできます。 - ドメインを使用して、複数のアプリケーション間で設定を共有できます。 - アプリケーションは異なるライブラリバージョンに依存できます。 - 複数のバージョンのアプリケーションを同じ Mule インスタンス内で実行できます。 ## [](#アプリケーションのパッケージとデプロイメント)アプリケーションのパッケージとデプロイメント Mule Runtime Engine は、すべてのアプリケーションを実行時に展開し、元の ​`.jar`​ ファイルを ​`/apps`​ ディレクトリから削除し、アプリケーションごとに新しいフォルダーを作成して、各フォルダーにアプリケーションファイルと同じ名前 (から ​`.jar`​ 拡張子を削除したもの) を付けます。 デプロイメントが成功したかどうかは以下で確認してください。 - コンソールに表示されるアプリケーションの状況が ​`DEPLOYED`​ である。 - Mule インスタンスの ​`/apps`​ ディレクトリに展開されたアプリケーションフォルダー (例: `stockTrader.jar`​ であれば ​`$MULE_HOME/apps/stockTrader`​) が存在する。 - 実行中のアプリケーション用のアンカーファイル (例: `$MULE_HOME/apps/stockTrader-anchor.txt`​) が存在する。 アプリケーションを別の場所に保存する場合、​`$MULE_HOME/apps`​ からアプリケーションディレクトリへのシンボリックリンクを作成して、Unix ベースのシステムに保存できます。 ## [](#アプリケーションとドメインのデプロイメント)アプリケーションとドメインのデプロイメント すべてのアプリケーションは​_ドメイン_​内で一緒にデプロイされます。デフォルトでは、アプリケーションは ​`default`​ のドメインを参照し、追加の設定は必要ありません。コンソールでアプリケーションと一緒にドメインがデプロイされるのを確認できます。 ![ドメインとデプロイ済みアプリケーションおよびその状況](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/deploy-domain.png) 複数のアプリケーションを同じ Mule インスタンスにデプロイしていて、アプリケーションが同じリソースを共有する必要がある場合は、共通の​_ドメイン_​を作成して複数のプロジェクトから参照できる設定を定義できます。この方法なら、競合を起こすことなく、同じ HTTP ホストおよびポートから異なるプロジェクトの異なるサービスを公開できます。 ## [](#アプリケーションのホットデプロイメント)アプリケーションのホットデプロイメント Mule アプリケーションの設定ファイルとカスタムクラスを変更した場合は、Mule を再起動せずにそれらを読み込み直すことができます。Mule アプリケーションの設定ファイルから変更を取得するには、システムプロパティ ​`mule.deployment.forceParseConfigXmls`​ が ​`true`​ に設定されている必要があります。Mule アプリケーションの設定ファイルを変更して強制的に再デプロイした場合、アプリケーションがパッケージ化された場合に行われる検証は実行されないことに注意してください。 Mule は、​`$MULE_HOME/apps`​ ディレクトリ下の設定ファイルが更新されているかどうかを 3 秒ごとに確認し、更新された設定ファイルを見つけると、設定ファイルと JAR をそのアプリケーションの ​`java`​ ソースディレクトリに再読み込みします。 Mule を起動し、​`mule.deploy.applications`​ プロパティを使用してアプリケーションを指定する場合、ホットデプロイメントプロセスは、指定されたアプリケーションに対してのみ機能します。 アプリケーションを再読み込みするには、以下の操作を実行できます。 - 該当のアプリケーションのアンカーファイルを ​`touch`​ します。 - `mule-artifact.json`​ ファイル内で宣言されている Mule 設定ファイルのいずれかを ​`touch`​ または更新します。 たとえば、カスタムクラスの 1 つを変更する場合、そのカスタムクラスに変更を加え、更新したクラスを Java ディレクトリにコピーした後、アンカーファイルを ​`touch`​ します。 ## [](#mule-インスタンスと管理ペイン間の通信)Mule インスタンスと管理ペイン間の通信 Mule インスタンスは管理ペインを使用して個別に実行され、インテグレーションロジックの実行や API 要求の提供を行います。このアーキテクチャにより、Mule Runtime Engine を戦略的にデプロイし、通信のボトルネックにならないようにすることができます。 Mule インスタンスが管理ペインから切断されるようなイベントが発生すると、設計どおりに実行が継続され、インテグレーションの実行や API の提供が中断することなく行われます。ただし、新しいまたは更新されたポリシーは、接続が再確立されるまで取り込まれず、更新されません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.9/shared-resources) - [オンプレミスでの Mule Runtime Engine の実行](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-standalone) # カスタムシリアライザーの設定 デフォルトでは、Mule Runtime Engine (Mule) は通常の Java シリアル化を使用します。ただし、Mule アプリケーションで ​`defaultObjectSerializer`​ を設定すると、異なるシリアル化メカニズム (Kryo シリアライザーや他のカスタムシリアライザーなど) を指定できます。 カスタムシリアライザーを使用すると、Mule で次のいずれかのプロセスを実行する場合に機能とパフォーマンスが向上する可能性があります。 - 永続的なオブジェクトストアに対する読み書き - 永続的な VM キューまたは JMS キューに対する読み書き - Mule クラスターを介したオブジェクトの配信 - ファイルからのオブジェクトに対する読み書き カスタマイズは Batch Module の動作に影響しません。Batch Module では Kryo シリアライザーが常に使用されます。 ## [](#シリアライザーと-mule-の互換性)シリアライザーと Mule の互換性 Mule Runtime Engine (Enterprise Edition) を実行している場合、Kryo シリアライザーを設定してパフォーマンスを向上できます。 Mule Kernel (Community Edition) を使用している場合は、シリアル化 API を使用してカスタムシリアライザーを作成できます。 ## [](#kryo-シリアライザーの設定)Kryo シリアライザーの設定 Mule では、Kryo フレームワークに依存する ​`ObjectSerializer`​ の実装が提供されます。Kryo を使用すると、次の利点が得られます。 - パフォーマンスの向上 Kryo は Java シリアル化よりも大幅に高速です。 - より広範な Java 型のサポート Kryo は、Java シリアル化のほとんどの制限に拘束されません。たとえば、​`Serializable`​ インターフェースを実装する必要はなく、デフォルトのコンストラクターを持つ必要もありません。 - 圧縮のサポート Deflate または GZip 圧縮アルゴリズムを使用できます。 Kryo 名前空間を使用すると、カスタム Spring bean を定義せずに、Mule アプリケーション内でこのシリアライザーを有効にできます。次の設定例では、デフォルトのシリアライザーを Kryo ベースのシリアライザーに設定します。 ```xml ``` 圧縮を設定するための ​`compressionMode`​ XML 属性を含めることもできます。 ```xml ``` ## [](#シリアル化-api-を使用したカスタムシリアライザーの作成)シリアル化 API を使用したカスタムシリアライザーの作成 オープンソースのシリアル化 API で提供されている ​`ObjectSerializer.java`​ インターフェースを使用して、オブジェクトをバイト配列にシリアル化したり、非シリアル化したりできます。 [GitHub の ObjectSerializer.java](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/ObjectSerializer.java)​ を参照してください。 シリアル API には次の機能があります。 - スレッドセーフである - シリアル化およびストリーミング時に OutputStream を渡す - 入力ソースとして InputStream を使用可能 Mule でシリアル化および非シリアル化する場合、​`getInternalProtocol()`​ メソッドを定義する必要があります。 シリアル化されたオブジェクトを外部システムで使用する場合、そのオブジェクトを ​`getExternalProtocol()`​ メソッドで定義します。 [Serialization Protocol (シリアル化プロトコル)](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/SerializationProtocol.java)​ は、シリアル化および非シリアル化するために使用するオブジェクトです。 ## [](#カスタムシリアライザーの設定)カスタムシリアライザーの設定 Mule の ​``​ タグを使用して、Mule アプリケーションのデフォルトの ​`ObjectSerializer`​ を設定します。 ```xml ``` 次に、​`serializer.xml`​ ファイルで bean を設定します。 ```xml ``` ## [](#設定済みの-objectserializer-の取得)設定済みの ObjectSerializer の取得 Java コード内で ​`ObjectSerializer`​ を取得するさまざまな方法があります。一般に、連動関係を挿入する方法をお勧めします。次のコード例は、現在設定されている ​`ObjectSerializer`​ を取得する方法を示しています。 ```java public class MyClass { @Inject private ObjectSerializer objectSerializer; } ``` 特定の名前のシリアライザーが必要な場合 (それがデフォルトかどうかに関係なく)、名前でシリアライザーにアクセスできます。 ```java public class MyClass { @Inject @Named ("mySerializer") private ObjectSerializer objectSerializer; } ``` ## [](#kryo-を使用したパフォーマンスの向上)Kryo を使用したパフォーマンスの向上 次のコンポーネントを使用している場合、Kryo を使用すると、通常の Java シリアル化よりもパフォーマンスが特に向上します。 - 永続的なオブジェクトストアまたはクラスタリングされたオブジェクトストア - 永続的な VM キューまたは分散 VM キュー - JMS Connector どのような場合も、圧縮を使用しない Kryo シリアライザーは通常の Java シリアライザーよりも大幅に高速です。ただし、高可用性 (HA) の場合に限り、圧縮モードでパフォーマンスが向上します。 圧縮を価値のあるものにするには、圧縮と圧縮解除にかかる CPU 時間が、ペイロードサイズの縮小によって節約された I/O 時間を大幅に下回る必要があります。通常、ネットワーク操作はディスク操作よりも低速です。また、HA クラスタリングにはノードの複製が必要です (つまり、より多くのトラフィックが発生します)。このため、圧縮は HA 環境でのみ役立ちます。 これは普遍定数ではありません。低速のディスクや高い I/O 要求のあるマシンで Mule を実行する場合があります。どのような場合も、この状況では圧縮に価値がある可能性があります。また、テストは 1 MB のペイロードを使用して実行されました。データストリームがこれより大きい場合、圧縮の価値がさらに高まります。 ## [](#シリアル化を使用する場合の考慮事項)シリアル化を使用する場合の考慮事項 シリアル化を使用する場合は、以下の制限と考慮事項に注意してください。 ### [](#シリアライザーの変更には白紙の状態が必要)シリアライザーの変更には白紙の状態が必要 シリアライザーは相互運用可能ではなく、代替可能でもありません。つまり、アプリケーションで使用するシリアライザーを変更する場合は、VM および JMS キュー内のすべてのメッセージがコンシュームされていること、および新しいシリアライザーに引き継がれるまでにそれらのキューが空になっていることを確認します。 Kryo シリアライザーは、Java シリアライザーが書き込んだデータグラムを読み取ることはできません (その逆も同様)。永続的なオブジェクトストアでも同様です。1 つのシリアライザーで生成されたエントリを別のシリアライザーで読み取ることはできません。 ### [](#共有された-vm-connector-ではドメインのデフォルトのシリアライザーを使用)共有された VM Connector ではドメインのデフォルトのシリアライザーを使用 ドメインを使用すると、アプリケーション間でリソースを共有できます。たとえば、ドメインで VM Connector を定義すると、VM メッセージキューを介してアプリケーション間の通信ができます。 ただし、シリアライザーはアプリケーションレベルでのみ設定できます。シリアライザーをドメインレベルで設定することはできません。 アプリケーション A と B が、その両方が属しているドメインで定義された VM Connector を介して、相互に通信するとします。ただし、A はシリアル化に Java を使用し、B は Kryo を使用します。この場合、その特定のメッセージはアプリケーションのシリアライザーではシリアル化されず、VM Connector で使用されているシリアライザー (ドメインレベルのデフォルトのシリアライザー) でシリアル化されるため、シリアル化は機能します。これは「プラグアンドプレー環境」には適していますが、共有された VM Connector で Kryo を使用すると、パフォーマンスの向上を実現することはできません。 ### [](#ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上)ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上 ローカルの永続的なオブジェクトストアでは、オブジェクトストアの実装に対する競合が多いためにパフォーマンス上の利点はありません。 ### [](#jms-キューでのわずかなパフォーマンスの向上)JMS キューでのわずかなパフォーマンスの向上 JMS API では、キューが ​`javax.jms.Message`​ クラスのインスタンスを提供する必要があることが指定されており、キューは未加工のペイロードオブジェクトを操作しません。メッセージをシリアル化するのは Mule ではなくブローカークライアントです。そのため、このシナリオでは、Kryo の設定による影響は最小限に抑えられます。 JMS で Kryo を使用する場合のパフォーマンス上の利点は、Mule が MuleSession をシリアル化して Base64 形式でヘッダーとして使用することのみです。Kryo を使用して MuleSession をシリアル化すると、パフォーマンスが最大 10% 向上する可能性がありますが、これは Mule ではなく主に JMS ブローカーによるものです。 ### [](#問題のある型)問題のある型 Kryo は、​`Serializable`​ インターフェースを実装していないオブジェクトをシリアル化できますが、Kryo をデフォルトのシリアライザーとして設定しても、それは、VM Connector、ObjectSerializer、クラスターなどのコンポーネントがこのインターフェースを実装していないオブジェクトを処理できることを意味しません。Kryo はこのようなオブジェクトを操作できますが、これらのコンポーネントの Java API では、メソッドの署名内の ​`Serializable`​ のインスタンスが引き続き予期されます。 `Serializable`​ インターフェースを実装していないオブジェクトでは、通常の Java シリアル化は失敗します。ただし、シリアル化可能なインターフェースを実装していない別のオブジェクトがシリアル化に含まれていても、Kryo は成功する可能性があります (ただし保証できません)。典型的な例として、 [NetSuite](https://anypoint.mulesoft.com/exchange/?search=netsuite)​ または [Microsoft Dynamics CRM](https://anypoint.mulesoft.com/exchange/?search=Microsoft+Dynamics+CRM&type=connector)​ Connector で使用されている ​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl,`​ を含む POJO があります。 ## [](#関連情報)関連情報 - [Kryo 情報](https://github.com/EsotericSoftware/kryo) # カスタムシリアライザーの設定 デフォルトでは、Mule Runtime Engine (Mule) は通常の Java シリアル化を使用します。ただし、Mule アプリケーションで ​`defaultObjectSerializer`​ を設定すると、異なるシリアル化メカニズム (Kryo シリアライザーや他のカスタムシリアライザーなど) を指定できます。 カスタムシリアライザーを使用すると、Mule で次のいずれかのプロセスを実行する場合に機能とパフォーマンスが向上する可能性があります。 - 永続的なオブジェクトストアに対する読み書き - 永続的な VM キューまたは JMS キューに対する読み書き - Mule クラスターを介したオブジェクトの配信 - ファイルからのオブジェクトに対する読み書き カスタマイズはバッチモジュールの動作に影響しません。バッチモジュールでは Kryo シリアライザーが常に使用されます。 ## [](#シリアライザーと-mule-の互換性)シリアライザーと Mule の互換性 Mule Runtime Engine (Enterprise Edition) を実行している場合、Kryo シリアライザーを設定してパフォーマンスを向上できます。 Mule Kernel (Community Edition) を使用している場合は、シリアル化 API を使用してカスタムシリアライザーを作成できます。 ## [](#kryo-シリアライザーの設定)Kryo シリアライザーの設定 Mule では、Kryo フレームワークに依存する ​`ObjectSerializer`​ の実装が提供されます。Kryo を使用すると、次の利点が得られます。 - パフォーマンスの向上 Kryo は Java シリアル化よりも大幅に高速です。 - より広範な Java 型のサポート Kryo は、Java シリアル化のほとんどの制限に拘束されません。たとえば、​`Serializable`​ インターフェースを実装する必要はなく、デフォルトのコンストラクターを持つ必要もありません。 - 圧縮のサポート Deflate または GZip 圧縮アルゴリズムを使用できます。 Kryo 名前空間を使用すると、カスタム Spring bean を定義せずに、Mule アプリケーション内でこのシリアライザーを有効にできます。次の設定例では、デフォルトのシリアライザーを Kryo ベースのシリアライザーに設定します。 ```xml ``` 圧縮を設定するための ​`compressionMode`​ XML 属性を含めることもできます。 ```xml ``` ## [](#シリアル化-api-を使用したカスタムシリアライザーの作成)シリアル化 API を使用したカスタムシリアライザーの作成 オープンソースのシリアル化 API で提供されている ​`ObjectSerializer.java`​ インターフェースを使用して、オブジェクトをバイト配列にシリアル化したり、非シリアル化したりできます。 [GitHub の ObjectSerializer.java](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/ObjectSerializer.java)​ を参照してください。 シリアル API には次の機能があります。 - スレッドセーフである - シリアル化およびストリーミング時に OutputStream を渡す - 入力ソースとして InputStream を使用可能 Mule でシリアル化および非シリアル化する場合、​`getInternalProtocol()`​ メソッドを定義する必要があります。 シリアル化されたオブジェクトを外部システムで使用する場合、そのオブジェクトを ​`getExternalProtocol()`​ メソッドで定義します。 [Serialization Protocol (シリアル化プロトコル)](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/SerializationProtocol.java)​ は、シリアル化および非シリアル化するために使用するオブジェクトです。 ## [](#カスタムシリアライザーの設定)カスタムシリアライザーの設定 Mule の ​``​ タグを使用して、Mule アプリケーションのデフォルトの ​`ObjectSerializer`​ を設定します。 ```xml ``` 次に、​`serializer.xml`​ ファイルで bean を設定します。 ```xml ``` ## [](#設定済みの-objectserializer-の取得)設定済みの ObjectSerializer の取得 Java コード内で ​`ObjectSerializer`​ を取得するさまざまな方法があります。一般に、連動関係を挿入する方法をお勧めします。次のコード例は、現在設定されている ​`ObjectSerializer`​ を取得する方法を示しています。 ```java public class MyClass { @Inject private ObjectSerializer objectSerializer; } ``` 特定の名前のシリアライザーが必要な場合 (それがデフォルトかどうかに関係なく)、名前でシリアライザーにアクセスできます。 ```java public class MyClass { @Inject @Named ("mySerializer") private ObjectSerializer objectSerializer; } ``` ## [](#kryo-を使用したパフォーマンスの向上)Kryo を使用したパフォーマンスの向上 次のコンポーネントを使用している場合、Kryo を使用すると、通常の Java シリアル化よりもパフォーマンスが特に向上します。 - 永続的なオブジェクトストアまたはクラスタリングされたオブジェクトストア - 永続的な VM キューまたは分散 VM キュー - JMS Connector どのような場合も、圧縮を使用しない Kryo シリアライザーは通常の Java シリアライザーよりも大幅に高速です。ただし、高可用性 (HA) の場合に限り、圧縮モードでパフォーマンスが向上します。 圧縮を価値のあるものにするには、圧縮と圧縮解除にかかる CPU 時間が、ペイロードサイズの縮小によって節約された I/O 時間を大幅に下回る必要があります。通常、ネットワーク操作はディスク操作よりも低速です。また、HA クラスタリングにはノードの複製が必要です (つまり、より多くのトラフィックが発生します)。このため、圧縮は HA 環境でのみ役立ちます。 これは普遍定数ではありません。低速のディスクや高い I/O 要求のあるマシンで Mule を実行する場合があります。どのような場合も、この状況では圧縮に価値がある可能性があります。また、テストは 1 MB のペイロードを使用して実行されました。データストリームがこれより大きい場合、圧縮の価値がさらに高まります。 ## [](#シリアル化を使用する場合の考慮事項)シリアル化を使用する場合の考慮事項 シリアル化を使用する場合は、以下の制限と考慮事項に注意してください。 ### [](#シリアライザーの変更には白紙の状態が必要)シリアライザーの変更には白紙の状態が必要 シリアライザーは相互運用可能ではなく、代替可能でもありません。つまり、アプリケーションで使用するシリアライザーを変更する場合は、VM および JMS キュー内のすべてのメッセージがコンシュームされていること、および新しいシリアライザーに引き継がれるまでにそれらのキューが空になっていることを確認します。 Kryo シリアライザーは、Java シリアライザーが書き込んだデータグラムを読み取ることはできません (その逆も同様)。永続的なオブジェクトストアでも同様です。1 つのシリアライザーで生成されたエントリを別のシリアライザーで読み取ることはできません。 ### [](#共有された-vm-connector-ではドメインのデフォルトのシリアライザーを使用)共有された VM Connector ではドメインのデフォルトのシリアライザーを使用 ドメインを使用すると、アプリケーション間でリソースを共有できます。たとえば、ドメインで VM Connector を定義すると、VM メッセージキューを介してアプリケーション間の通信ができます。 ただし、シリアライザーはアプリケーションレベルでのみ設定できます。シリアライザーをドメインレベルで設定することはできません。 アプリケーション A と B が、その両方が属しているドメインで定義された VM Connector を介して、相互に通信するとします。ただし、A はシリアル化に Java を使用し、B は Kryo を使用します。この場合、その特定のメッセージはアプリケーションのシリアライザーではシリアル化されず、VM Connector で使用されているシリアライザー (ドメインレベルのデフォルトのシリアライザー) でシリアル化されるため、シリアル化は機能します。これは「プラグアンドプレー環境」には適していますが、共有された VM Connector で Kryo を使用すると、パフォーマンスの向上を実現することはできません。 ### [](#ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上)ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上 ローカルの永続的なオブジェクトストアでは、オブジェクトストアの実装に対する競合が多いためにパフォーマンス上の利点はありません。 ### [](#jms-キューでのわずかなパフォーマンスの向上)JMS キューでのわずかなパフォーマンスの向上 JMS API では、キューが ​`javax.jms.Message`​ クラスのインスタンスを提供する必要があることが指定されており、キューは未加工のペイロードオブジェクトを操作しません。メッセージをシリアル化するのは Mule ではなくブローカークライアントです。そのため、このシナリオでは、Kryo の設定による影響は最小限に抑えられます。 JMS で Kryo を使用する場合のパフォーマンス上の利点は、Mule が MuleSession をシリアル化して Base64 形式でヘッダーとして使用することのみです。Kryo を使用して MuleSession をシリアル化すると、パフォーマンスが最大 10% 向上する可能性がありますが、これは Mule ではなく主に JMS ブローカーによるものです。 ### [](#問題のある型)問題のある型 Kryo は、​`Serializable`​ インターフェースを実装していないオブジェクトをシリアル化できますが、Kryo をデフォルトのシリアライザーとして設定しても、それは、VM Connector、ObjectSerializer、クラスターなどのコンポーネントがこのインターフェースを実装していないオブジェクトを処理できることを意味しません。Kryo はこのようなオブジェクトを操作できますが、これらのコンポーネントの Java API では、メソッドの署名内の ​`Serializable`​ のインスタンスが引き続き予期されます。 `Serializable`​ インターフェースを実装していないオブジェクトでは、通常の Java シリアル化は失敗します。ただし、シリアル化可能なインターフェースを実装していない別のオブジェクトがシリアル化に含まれていても、Kryo は成功する可能性があります (ただし保証できません)。典型的な例として、 [NetSuite](https://anypoint.mulesoft.com/exchange/?search=netsuite)​ または [Microsoft Dynamics CRM](https://anypoint.mulesoft.com/exchange/?search=Microsoft+Dynamics+CRM&type=connector)​ Connector で使用されている ​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl,`​ を含む POJO があります。 ## [](#関連情報)関連情報 - [Kryo 情報](https://github.com/EsotericSoftware/kryo) # カスタムシリアライザーの設定 デフォルトでは、Mule Runtime Engine (Mule) は通常の Java シリアル化を使用します。ただし、Mule アプリケーションで ​`defaultObjectSerializer`​ を設定すると、異なるシリアル化メカニズム (Kryo シリアライザーや他のカスタムシリアライザーなど) を指定できます。 カスタムシリアライザーを使用すると、Mule で次のいずれかのプロセスを実行する場合に機能とパフォーマンスが向上する可能性があります。 - 永続的なオブジェクトストアに対する読み書き - 永続的な VM キューまたは JMS キューに対する読み書き - Mule クラスターを介したオブジェクトの配信 - ファイルからのオブジェクトに対する読み書き カスタマイズは Batch Module の動作に影響しません。Batch Module では Kryo シリアライザーが常に使用されます。 ## [](#シリアライザーと-mule-の互換性)シリアライザーと Mule の互換性 Mule Runtime Engine (Enterprise Edition) を実行している場合、Kryo シリアライザーを設定してパフォーマンスを向上できます。 Mule Kernel (Community Edition) を使用している場合は、シリアル化 API を使用してカスタムシリアライザーを作成できます。 ## [](#kryo-シリアライザーの設定)Kryo シリアライザーの設定 Mule では、Kryo フレームワークに依存する ​`ObjectSerializer`​ の実装が提供されます。Kryo を使用すると、次の利点が得られます。 - パフォーマンスの向上 Kryo は Java シリアル化よりも大幅に高速です。 - より広範な Java 型のサポート Kryo は、Java シリアル化のほとんどの制限に拘束されません。たとえば、​`Serializable`​ インターフェースを実装する必要はなく、デフォルトのコンストラクターを持つ必要もありません。 - 圧縮のサポート Deflate または GZip 圧縮アルゴリズムを使用できます。 Kryo 名前空間を使用すると、カスタム Spring bean を定義せずに、Mule アプリケーション内でこのシリアライザーを有効にできます。次の設定例では、デフォルトのシリアライザーを Kryo ベースのシリアライザーに設定します。 ```xml ``` 圧縮を設定するための ​`compressionMode`​ XML 属性を含めることもできます。 ```xml ``` ## [](#シリアル化-api-を使用したカスタムシリアライザーの作成)シリアル化 API を使用したカスタムシリアライザーの作成 オープンソースのシリアル化 API で提供されている ​`ObjectSerializer.java`​ インターフェースを使用して、オブジェクトをバイト配列にシリアル化したり、非シリアル化したりできます。 [GitHub の ObjectSerializer.java](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/ObjectSerializer.java)​ を参照してください。 シリアル API には次の機能があります。 - スレッドセーフである - シリアル化およびストリーミング時に OutputStream を渡す - 入力ソースとして InputStream を使用可能 Mule でシリアル化および非シリアル化する場合、​`getInternalProtocol()`​ メソッドを定義する必要があります。 シリアル化されたオブジェクトを外部システムで使用する場合、そのオブジェクトを ​`getExternalProtocol()`​ メソッドで定義します。 [Serialization Protocol (シリアル化プロトコル)](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/SerializationProtocol.java)​ は、シリアル化および非シリアル化するために使用するオブジェクトです。 ## [](#カスタムシリアライザーの設定)カスタムシリアライザーの設定 Mule の ​``​ タグを使用して、Mule アプリケーションのデフォルトの ​`ObjectSerializer`​ を設定します。 ```xml ``` 次に、​`serializer.xml`​ ファイルで bean を設定します。 ```xml ``` ## [](#設定済みの-objectserializer-の取得)設定済みの ObjectSerializer の取得 Java コード内で ​`ObjectSerializer`​ を取得するさまざまな方法があります。一般に、連動関係を挿入する方法をお勧めします。次のコード例は、現在設定されている ​`ObjectSerializer`​ を取得する方法を示しています。 ```java public class MyClass { @Inject private ObjectSerializer objectSerializer; } ``` 特定の名前のシリアライザーが必要な場合 (それがデフォルトかどうかに関係なく)、名前でシリアライザーにアクセスできます。 ```java public class MyClass { @Inject @Named ("mySerializer") private ObjectSerializer objectSerializer; } ``` ## [](#kryo-を使用したパフォーマンスの向上)Kryo を使用したパフォーマンスの向上 次のコンポーネントを使用している場合、Kryo を使用すると、通常の Java シリアル化よりもパフォーマンスが特に向上します。 - 永続的なオブジェクトストアまたはクラスタリングされたオブジェクトストア - 永続的な VM キューまたは分散 VM キュー - JMS Connector どのような場合も、圧縮を使用しない Kryo シリアライザーは通常の Java シリアライザーよりも大幅に高速です。ただし、高可用性 (HA) の場合に限り、圧縮モードでパフォーマンスが向上します。 圧縮を価値のあるものにするには、圧縮と圧縮解除にかかる CPU 時間が、ペイロードサイズの縮小によって節約された I/O 時間を大幅に下回る必要があります。通常、ネットワーク操作はディスク操作よりも低速です。また、HA クラスタリングにはノードの複製が必要です (つまり、より多くのトラフィックが発生します)。このため、圧縮は HA 環境でのみ役立ちます。 これは普遍定数ではありません。低速のディスクや高い I/O 要求のあるマシンで Mule を実行する場合があります。どのような場合も、この状況では圧縮に価値がある可能性があります。また、テストは 1 MB のペイロードを使用して実行されました。データストリームがこれより大きい場合、圧縮の価値がさらに高まります。 ## [](#シリアル化を使用する場合の考慮事項)シリアル化を使用する場合の考慮事項 シリアル化を使用する場合は、以下の制限と考慮事項に注意してください。 ### [](#シリアライザーの変更には白紙の状態が必要)シリアライザーの変更には白紙の状態が必要 シリアライザーは相互運用可能ではなく、代替可能でもありません。つまり、アプリケーションで使用するシリアライザーを変更する場合は、VM および JMS キュー内のすべてのメッセージがコンシュームされていること、および新しいシリアライザーに引き継がれるまでにそれらのキューが空になっていることを確認します。 Kryo シリアライザーは、Java シリアライザーが書き込んだデータグラムを読み取ることはできません (その逆も同様)。永続的なオブジェクトストアでも同様です。1 つのシリアライザーで生成されたエントリを別のシリアライザーで読み取ることはできません。 ### [](#共有された-vm-connector-ではドメインのデフォルトのシリアライザーを使用)共有された VM Connector ではドメインのデフォルトのシリアライザーを使用 ドメインを使用すると、アプリケーション間でリソースを共有できます。たとえば、ドメインで VM Connector を定義すると、VM メッセージキューを介してアプリケーション間の通信ができます。 ただし、シリアライザーはアプリケーションレベルでのみ設定できます。シリアライザーをドメインレベルで設定することはできません。 アプリケーション A と B が、その両方が属しているドメインで定義された VM Connector を介して、相互に通信するとします。ただし、A はシリアル化に Java を使用し、B は Kryo を使用します。この場合、その特定のメッセージはアプリケーションのシリアライザーではシリアル化されず、VM Connector で使用されているシリアライザー (ドメインレベルのデフォルトのシリアライザー) でシリアル化されるため、シリアル化は機能します。これは「プラグアンドプレー環境」には適していますが、共有された VM Connector で Kryo を使用すると、パフォーマンスの向上を実現することはできません。 ### [](#ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上)ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上 ローカルの永続的なオブジェクトストアでは、オブジェクトストアの実装に対する競合が多いためにパフォーマンス上の利点はありません。 ### [](#jms-キューでのわずかなパフォーマンスの向上)JMS キューでのわずかなパフォーマンスの向上 JMS API では、キューが ​`javax.jms.Message`​ クラスのインスタンスを提供する必要があることが指定されており、キューは未加工のペイロードオブジェクトを操作しません。メッセージをシリアル化するのは Mule ではなくブローカークライアントです。そのため、このシナリオでは、Kryo の設定による影響は最小限に抑えられます。 JMS で Kryo を使用する場合のパフォーマンス上の利点は、Mule が MuleSession をシリアル化して Base64 形式でヘッダーとして使用することのみです。Kryo を使用して MuleSession をシリアル化すると、パフォーマンスが最大 10% 向上する可能性がありますが、これは Mule ではなく主に JMS ブローカーによるものです。 ### [](#問題のある型)問題のある型 Kryo は、​`Serializable`​ インターフェースを実装していないオブジェクトをシリアル化できますが、Kryo をデフォルトのシリアライザーとして設定しても、それは、VM Connector、ObjectSerializer、クラスターなどのコンポーネントがこのインターフェースを実装していないオブジェクトを処理できることを意味しません。Kryo はこのようなオブジェクトを操作できますが、これらのコンポーネントの Java API では、メソッドの署名内の ​`Serializable`​ のインスタンスが引き続き予期されます。 `Serializable`​ インターフェースを実装していないオブジェクトでは、通常の Java シリアル化は失敗します。ただし、シリアル化可能なインターフェースを実装していない別のオブジェクトがシリアル化に含まれていても、Kryo は成功する可能性があります (ただし保証できません)。典型的な例として、 [NetSuite](https://anypoint.mulesoft.com/exchange/?search=netsuite)​ または [Microsoft Dynamics CRM](https://anypoint.mulesoft.com/exchange/?search=Microsoft+Dynamics+CRM&type=connector)​ Connector で使用されている ​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl,`​ を含む POJO があります。 ## [](#関連情報)関連情報 - [Kryo 情報](https://github.com/EsotericSoftware/kryo) # カスタムシリアライザーの設定 デフォルトでは、Mule Runtime Engine (Mule) は通常の Java シリアル化を使用します。ただし、Mule アプリケーションで ​`defaultObjectSerializer`​ を設定すると、異なるシリアル化メカニズム (Kryo シリアライザーや他のカスタムシリアライザーなど) を指定できます。 カスタムシリアライザーを使用すると、Mule で次のいずれかのプロセスを実行する場合に機能とパフォーマンスが向上する可能性があります。 - 永続的なオブジェクトストアに対する読み書き - 永続的な VM キューまたは JMS キューに対する読み書き - Mule クラスターを介したオブジェクトの配信 - ファイルからのオブジェクトに対する読み書き カスタマイズはバッチモジュールの動作に影響しません。バッチモジュールでは Kryo シリアライザーが常に使用されます。 ## [](#シリアライザーと-mule-の互換性)シリアライザーと Mule の互換性 Mule Runtime Engine (Enterprise Edition) を実行している場合、Kryo シリアライザーを設定してパフォーマンスを向上できます。 Mule Kernel (Community Edition) を使用している場合は、シリアル化 API を使用してカスタムシリアライザーを作成できます。 ## [](#kryo-シリアライザーの設定)Kryo シリアライザーの設定 Mule では、Kryo フレームワークに依存する ​`ObjectSerializer`​ の実装が提供されます。Kryo を使用すると、次の利点が得られます。 - パフォーマンスの向上 Kryo は Java シリアル化よりも大幅に高速です。 - より広範な Java 型のサポート Kryo は、Java シリアル化のほとんどの制限に拘束されません。たとえば、​`Serializable`​ インターフェースを実装する必要はなく、デフォルトのコンストラクターを持つ必要もありません。 - 圧縮のサポート Deflate または GZip 圧縮アルゴリズムを使用できます。 Kryo 名前空間を使用すると、カスタム Spring bean を定義せずに、Mule アプリケーション内でこのシリアライザーを有効にできます。次の設定例では、デフォルトのシリアライザーを Kryo ベースのシリアライザーに設定します。 ```xml ``` 圧縮を設定するための ​`compressionMode`​ XML 属性を含めることもできます。 ```xml ``` ## [](#シリアル化-api-を使用したカスタムシリアライザーの作成)シリアル化 API を使用したカスタムシリアライザーの作成 オープンソースのシリアル化 API で提供されている ​`ObjectSerializer.java`​ インターフェースを使用して、オブジェクトをバイト配列にシリアル化したり、非シリアル化したりできます。 [GitHub の ObjectSerializer.java](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/ObjectSerializer.java)​ を参照してください。 シリアル API には次の機能があります。 - スレッドセーフである - シリアル化およびストリーミング時に OutputStream を渡す - 入力ソースとして InputStream を使用可能 Mule でシリアル化および非シリアル化する場合、​`getInternalProtocol()`​ メソッドを定義する必要があります。 シリアル化されたオブジェクトを外部システムで使用する場合、そのオブジェクトを ​`getExternalProtocol()`​ メソッドで定義します。 [Serialization Protocol (シリアル化プロトコル)](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/SerializationProtocol.java)​ は、シリアル化および非シリアル化するために使用するオブジェクトです。 ## [](#カスタムシリアライザーの設定)カスタムシリアライザーの設定 Mule の ​``​ タグを使用して、Mule アプリケーションのデフォルトの ​`ObjectSerializer`​ を設定します。 ```xml ``` 次に、​`serializer.xml`​ ファイルで bean を設定します。 ```xml ``` ## [](#設定済みの-objectserializer-の取得)設定済みの ObjectSerializer の取得 Java コード内で ​`ObjectSerializer`​ を取得するさまざまな方法があります。一般に、連動関係を挿入する方法をお勧めします。次のコード例は、現在設定されている ​`ObjectSerializer`​ を取得する方法を示しています。 ```java public class MyClass { @Inject private ObjectSerializer objectSerializer; } ``` 特定の名前のシリアライザーが必要な場合 (それがデフォルトかどうかに関係なく)、名前でシリアライザーにアクセスできます。 ```java public class MyClass { @Inject @Named ("mySerializer") private ObjectSerializer objectSerializer; } ``` ## [](#kryo-を使用したパフォーマンスの向上)Kryo を使用したパフォーマンスの向上 次のコンポーネントを使用している場合、Kryo を使用すると、通常の Java シリアル化よりもパフォーマンスが特に向上します。 - 永続的なオブジェクトストアまたはクラスタリングされたオブジェクトストア - 永続的な VM キューまたは分散 VM キュー - JMS Connector どのような場合も、圧縮を使用しない Kryo シリアライザーは通常の Java シリアライザーよりも大幅に高速です。ただし、高可用性 (HA) の場合に限り、圧縮モードでパフォーマンスが向上します。 圧縮を価値のあるものにするには、圧縮と圧縮解除にかかる CPU 時間が、ペイロードサイズの縮小によって節約された I/O 時間を大幅に下回る必要があります。通常、ネットワーク操作はディスク操作よりも低速です。また、HA クラスタリングにはノードの複製が必要です (つまり、より多くのトラフィックが発生します)。このため、圧縮は HA 環境でのみ役立ちます。 これは普遍定数ではありません。低速のディスクや高い I/O 要求のあるマシンで Mule を実行する場合があります。どのような場合も、この状況では圧縮に価値がある可能性があります。また、テストは 1 MB のペイロードを使用して実行されました。データストリームがこれより大きい場合、圧縮の価値がさらに高まります。 ## [](#シリアル化を使用する場合の考慮事項)シリアル化を使用する場合の考慮事項 シリアル化を使用する場合は、以下の制限と考慮事項に注意してください。 ### [](#シリアライザーの変更には白紙の状態が必要)シリアライザーの変更には白紙の状態が必要 シリアライザーは相互運用可能ではなく、代替可能でもありません。つまり、アプリケーションで使用するシリアライザーを変更する場合は、VM および JMS キュー内のすべてのメッセージがコンシュームされていること、および新しいシリアライザーに引き継がれるまでにそれらのキューが空になっていることを確認します。 Kryo シリアライザーは、Java シリアライザーが書き込んだデータグラムを読み取ることはできません (その逆も同様)。永続的なオブジェクトストアでも同様です。1 つのシリアライザーで生成されたエントリを別のシリアライザーで読み取ることはできません。 ### [](#共有された-vm-connector-ではドメインのデフォルトのシリアライザーを使用)共有された VM Connector ではドメインのデフォルトのシリアライザーを使用 ドメインを使用すると、アプリケーション間でリソースを共有できます。たとえば、ドメインで VM Connector を定義すると、VM メッセージキューを介してアプリケーション間の通信ができます。 ただし、シリアライザーはアプリケーションレベルでのみ設定できます。シリアライザーをドメインレベルで設定することはできません。 アプリケーション A と B が、その両方が属しているドメインで定義された VM Connector を介して、相互に通信するとします。ただし、A はシリアル化に Java を使用し、B は Kryo を使用します。この場合、その特定のメッセージはアプリケーションのシリアライザーではシリアル化されず、VM Connector で使用されているシリアライザー (ドメインレベルのデフォルトのシリアライザー) でシリアル化されるため、シリアル化は機能します。これは「プラグアンドプレー環境」には適していますが、共有された VM Connector で Kryo を使用することによるパフォーマンスの向上を実現することはできません。 ### [](#java-17-のサポート)Java 17 のサポート バージョン 4.6 以降、Mule Runtime は Java 17 をサポートしています。Java 17 では JPMS が適用されます。この機能を実現するため、Mulesoft ではデフォルトの Kryo フレームワークに替わるいくつかのカスタムシリアライザーが導入されます。これは、デフォルトのフレームワークで使用するメカニズムでは JPMS のカプセル化が壊れるためです。 Mule Runtime 4.6 と Java 17 への移行時に、Kryo シリアライザーが HTTP Connector 証明書をシリアル化しない可能性があります。この問題は、属性内に証明書がある HTTP Connector と一緒に Kryo シリアライザーを使用している場合に発生します。 ### [](#ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上)ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上 ローカルの永続的なオブジェクトストアでは、オブジェクトストアの実装に対する競合が多いためにパフォーマンス上の利点はありません。 ### [](#jms-キューでのわずかなパフォーマンスの向上)JMS キューでのわずかなパフォーマンスの向上 JMS API では、キューが ​`javax.jms.Message`​ クラスのインスタンスを提供する必要があることが指定されており、キューは未加工のペイロードオブジェクトを操作しません。メッセージをシリアル化するのは Mule ではなくブローカークライアントです。そのため、このシナリオでは、Kryo の設定による影響は最小限に抑えられます。 JMS で Kryo を使用する場合のパフォーマンス上の利点は、Mule が MuleSession をシリアル化して Base64 形式でヘッダーとして使用することのみです。Kryo を使用して MuleSession をシリアル化すると、パフォーマンスが最大 10% 向上する可能性がありますが、これは Mule ではなく主に JMS ブローカーによるものです。 ### [](#問題のある型)問題のある型 Kryo は、​`Serializable`​ インターフェースを実装していないオブジェクトをシリアル化できますが、Kryo をデフォルトのシリアライザーとして設定しても、それは、VM Connector、ObjectSerializer、クラスターなどのコンポーネントがこのインターフェースを実装していないオブジェクトを処理できることを意味しません。Kryo はこのようなオブジェクトを操作できますが、これらのコンポーネントの Java API では、メソッドの署名内の ​`Serializable`​ のインスタンスが引き続き予期されます。 `Serializable`​ インターフェースを実装していないオブジェクトでは、通常の Java シリアル化は失敗します。ただし、Serializable インターフェースを実装していない別のオブジェクトがシリアル化に含まれていても、Kryo は成功する可能性があります (ただし保証できません)。典型的な例として、 [NetSuite](https://anypoint.mulesoft.com/exchange/?search=netsuite)​ または [Microsoft Dynamics CRM](https://anypoint.mulesoft.com/exchange/?search=Microsoft+Dynamics+CRM&type=connector)​ Connector で使用されている ​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl,`​ を含む POJO があります。 ## [](#関連情報)関連情報 - [Kryo 情報](https://github.com/EsotericSoftware/kryo) # カスタムシリアライザーの設定 デフォルトでは、Mule Runtime Engine (Mule) は通常の Java シリアル化を使用します。ただし、Mule アプリケーションで ​`defaultObjectSerializer`​ を設定すると、異なるシリアル化メカニズム (Kryo シリアライザーや他のカスタムシリアライザーなど) を指定できます。 カスタムシリアライザーを使用すると、Mule で次のいずれかのプロセスを実行する場合に機能とパフォーマンスが向上する可能性があります。 - 永続的なオブジェクトストアに対する読み書き - 永続的な VM キューまたは JMS キューに対する読み書き - Mule クラスターを介したオブジェクトの配信 - ファイルからのオブジェクトに対する読み書き カスタマイズはバッチモジュールの動作に影響しません。バッチモジュールでは Kryo シリアライザーが常に使用されます。 ## [](#シリアライザーと-mule-の互換性)シリアライザーと Mule の互換性 Mule Runtime Engine (Enterprise Edition) を実行している場合、Kryo シリアライザーを設定してパフォーマンスを向上できます。 Mule Kernel (Community Edition) を使用している場合は、シリアル化 API を使用してカスタムシリアライザーを作成できます。 ## [](#kryo-シリアライザーの設定)Kryo シリアライザーの設定 Mule では、Kryo フレームワークに依存する ​`ObjectSerializer`​ の実装が提供されます。Kryo を使用すると、次の利点が得られます。 - パフォーマンスの向上 Kryo は Java シリアル化よりも大幅に高速です。 - より広範な Java 型のサポート Kryo は、Java シリアル化のほとんどの制限に拘束されません。たとえば、​`Serializable`​ インターフェースを実装する必要はなく、デフォルトのコンストラクターを持つ必要もありません。 - 圧縮のサポート Deflate または GZip 圧縮アルゴリズムを使用できます。 Kryo 名前空間を使用すると、カスタム Spring bean を定義せずに、Mule アプリケーション内でこのシリアライザーを有効にできます。次の設定例では、デフォルトのシリアライザーを Kryo ベースのシリアライザーに設定します。 ```xml ``` 圧縮を設定するための ​`compressionMode`​ XML 属性を含めることもできます。 ```xml ``` ## [](#シリアル化-api-を使用したカスタムシリアライザーの作成)シリアル化 API を使用したカスタムシリアライザーの作成 オープンソースのシリアル化 API で提供されている ​`ObjectSerializer.java`​ インターフェースを使用して、オブジェクトをバイト配列にシリアル化したり、非シリアル化したりできます。 [GitHub の ObjectSerializer.java](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/ObjectSerializer.java)​ を参照してください。 シリアル API には次の機能があります。 - スレッドセーフである - シリアル化およびストリーミング時に OutputStream を渡す - 入力ソースとして InputStream を使用可能 Mule でシリアル化および非シリアル化する場合、​`getInternalProtocol()`​ メソッドを定義する必要があります。 シリアル化されたオブジェクトを外部システムで使用する場合、そのオブジェクトを ​`getExternalProtocol()`​ メソッドで定義します。 [Serialization Protocol (シリアル化プロトコル)](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/SerializationProtocol.java)​ は、シリアル化および非シリアル化するために使用するオブジェクトです。 ## [](#カスタムシリアライザーの設定)カスタムシリアライザーの設定 Mule の ​``​ タグを使用して、Mule アプリケーションのデフォルトの ​`ObjectSerializer`​ を設定します。 ```xml ``` 次に、​`serializer.xml`​ ファイルで bean を設定します。 ```xml ``` ## [](#設定済みの-objectserializer-の取得)設定済みの ObjectSerializer の取得 Java コード内で ​`ObjectSerializer`​ を取得するさまざまな方法があります。一般に、連動関係を挿入する方法をお勧めします。次のコード例は、現在設定されている ​`ObjectSerializer`​ を取得する方法を示しています。 ```java public class MyClass { @Inject private ObjectSerializer objectSerializer; } ``` 特定の名前のシリアライザーが必要な場合 (それがデフォルトかどうかに関係なく)、名前でシリアライザーにアクセスできます。 ```java public class MyClass { @Inject @Named ("mySerializer") private ObjectSerializer objectSerializer; } ``` ## [](#kryo-を使用したパフォーマンスの向上)Kryo を使用したパフォーマンスの向上 次のコンポーネントを使用している場合、Kryo を使用すると、通常の Java シリアル化よりもパフォーマンスが特に向上します。 - 永続的なオブジェクトストアまたはクラスタリングされたオブジェクトストア - 永続的な VM キューまたは分散 VM キュー - JMS Connector どのような場合も、圧縮を使用しない Kryo シリアライザーは通常の Java シリアライザーよりも大幅に高速です。ただし、高可用性 (HA) の場合に限り、圧縮モードでパフォーマンスが向上します。 圧縮を価値のあるものにするには、圧縮と圧縮解除にかかる CPU 時間が、ペイロードサイズの縮小によって節約された I/O 時間を大幅に下回る必要があります。通常、ネットワーク操作はディスク操作よりも低速です。また、HA クラスタリングにはノードの複製が必要です (つまり、より多くのトラフィックが発生します)。このため、圧縮は HA 環境でのみ役立ちます。 これは普遍定数ではありません。低速のディスクや高い I/O 要求のあるマシンで Mule を実行する場合があります。どのような場合も、この状況では圧縮に価値がある可能性があります。また、テストは 1 MB のペイロードを使用して実行されました。データストリームがこれより大きい場合、圧縮の価値がさらに高まります。 ## [](#シリアル化を使用する場合の考慮事項)シリアル化を使用する場合の考慮事項 シリアル化を使用する場合は、以下の制限と考慮事項に注意してください。 ### [](#シリアライザーの変更には白紙の状態が必要)シリアライザーの変更には白紙の状態が必要 シリアライザーは相互運用可能ではなく、代替可能でもありません。つまり、アプリケーションで使用するシリアライザーを変更する場合は、VM および JMS キュー内のすべてのメッセージがコンシュームされていること、および新しいシリアライザーに引き継がれるまでにそれらのキューが空になっていることを確認します。 Kryo シリアライザーは、Java シリアライザーが書き込んだデータグラムを読み取ることはできません (その逆も同様)。永続的なオブジェクトストアでも同様です。1 つのシリアライザーで生成されたエントリを別のシリアライザーで読み取ることはできません。 ### [](#共有された-vm-connector-ではドメインのデフォルトのシリアライザーを使用)共有された VM Connector ではドメインのデフォルトのシリアライザーを使用 ドメインを使用すると、アプリケーション間でリソースを共有できます。たとえば、ドメインで VM Connector を定義すると、VM メッセージキューを介してアプリケーション間の通信ができます。 ただし、シリアライザーはアプリケーションレベルでのみ設定できます。シリアライザーをドメインレベルで設定することはできません。 アプリケーション A と B が、その両方が属しているドメインで定義された VM Connector を介して、相互に通信するとします。ただし、A はシリアル化に Java を使用し、B は Kryo を使用します。この場合、その特定のメッセージはアプリケーションのシリアライザーではシリアル化されず、VM Connector で使用されているシリアライザー (ドメインレベルのデフォルトのシリアライザー) でシリアル化されるため、シリアル化は機能します。これは「プラグアンドプレー環境」には適していますが、共有された VM Connector で Kryo を使用することによるパフォーマンスの向上を実現することはできません。 ### [](#java-17-のサポート)Java 17 のサポート バージョン 4.6 以降、Mule Runtime は Java 17 をサポートしています。Java 17 では JPMS が適用されます。この機能を実現するため、Mulesoft ではデフォルトの Kryo フレームワークに替わるいくつかのカスタムシリアライザーが導入されます。これは、デフォルトのフレームワークで使用するメカニズムでは JPMS のカプセル化が壊れるためです。 Mule Runtime 4.6 と Java 17 への移行時に、Kryo シリアライザーが HTTP Connector 証明書をシリアル化しない可能性があります。この問題は、属性内に証明書がある HTTP Connector と一緒に Kryo シリアライザーを使用している場合に発生します。 ### [](#ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上)ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上 ローカルの永続的なオブジェクトストアでは、オブジェクトストアの実装に対する競合が多いためにパフォーマンス上の利点はありません。 ### [](#jms-キューでのわずかなパフォーマンスの向上)JMS キューでのわずかなパフォーマンスの向上 JMS API では、キューが ​`javax.jms.Message`​ クラスのインスタンスを提供する必要があることが指定されており、キューは未加工のペイロードオブジェクトを操作しません。メッセージをシリアル化するのは Mule ではなくブローカークライアントです。そのため、このシナリオでは、Kryo の設定による影響は最小限に抑えられます。 JMS で Kryo を使用する場合のパフォーマンス上の利点は、Mule が MuleSession をシリアル化して Base64 形式でヘッダーとして使用することのみです。Kryo を使用して MuleSession をシリアル化すると、パフォーマンスが最大 10% 向上する可能性がありますが、これは Mule ではなく主に JMS ブローカーによるものです。 ### [](#問題のある型)問題のある型 Kryo は、​`Serializable`​ インターフェースを実装していないオブジェクトをシリアル化できますが、Kryo をデフォルトのシリアライザーとして設定しても、それは、VM Connector、ObjectSerializer、クラスターなどのコンポーネントがこのインターフェースを実装していないオブジェクトを処理できることを意味しません。Kryo はこのようなオブジェクトを操作できますが、これらのコンポーネントの Java API では、メソッドの署名内の ​`Serializable`​ のインスタンスが引き続き予期されます。 `Serializable`​ インターフェースを実装していないオブジェクトでは、通常の Java シリアル化は失敗します。ただし、Serializable インターフェースを実装していない別のオブジェクトがシリアル化に含まれていても、Kryo は成功する可能性があります (ただし保証できません)。典型的な例として、 [NetSuite](https://anypoint.mulesoft.com/exchange/?search=netsuite)​ または [Microsoft Dynamics CRM](https://anypoint.mulesoft.com/exchange/?search=Microsoft+Dynamics+CRM&type=connector)​ Connector で使用されている ​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl,`​ を含む POJO があります。 ## [](#関連情報)関連情報 - [Kryo 情報](https://github.com/EsotericSoftware/kryo) # カスタムシリアライザーの設定 デフォルトでは、Mule Runtime Engine (Mule) は通常の Java シリアル化を使用します。ただし、Mule アプリケーションで ​`defaultObjectSerializer`​ を設定すると、異なるシリアル化メカニズム (Kryo シリアライザーや他のカスタムシリアライザーなど) を指定できます。 カスタムシリアライザーを使用すると、Mule で次のいずれかのプロセスを実行する場合に機能とパフォーマンスが向上する可能性があります。 - 永続的なオブジェクトストアに対する読み書き - 永続的な VM キューまたは JMS キューに対する読み書き - Mule クラスターを介したオブジェクトの配信 - ファイルからのオブジェクトに対する読み書き カスタマイズはバッチモジュールの動作に影響しません。バッチモジュールでは Kryo シリアライザーが常に使用されます。 ## [](#シリアライザーと-mule-の互換性)シリアライザーと Mule の互換性 Mule Runtime Engine (Enterprise Edition) を実行している場合、Kryo シリアライザーを設定してパフォーマンスを向上できます。 Mule Kernel (Community Edition) を使用している場合は、シリアル化 API を使用してカスタムシリアライザーを作成できます。 ## [](#kryo-シリアライザーの設定)Kryo シリアライザーの設定 Mule では、Kryo フレームワークに依存する ​`ObjectSerializer`​ の実装が提供されます。Kryo を使用すると、次の利点が得られます。 - パフォーマンスの向上 Kryo は Java シリアル化よりも大幅に高速です。 - より広範な Java 型のサポート Kryo は、Java シリアル化のほとんどの制限に拘束されません。たとえば、​`Serializable`​ インターフェースを実装する必要はなく、デフォルトのコンストラクターを持つ必要もありません。 - 圧縮のサポート Deflate または GZip 圧縮アルゴリズムを使用できます。 Kryo 名前空間を使用すると、カスタム Spring bean を定義せずに、Mule アプリケーション内でこのシリアライザーを有効にできます。次の設定例では、デフォルトのシリアライザーを Kryo ベースのシリアライザーに設定します。 ```xml ``` 圧縮を設定するための ​`compressionMode`​ XML 属性を含めることもできます。 ```xml ``` ## [](#シリアル化-api-を使用したカスタムシリアライザーの作成)シリアル化 API を使用したカスタムシリアライザーの作成 オープンソースのシリアル化 API で提供されている ​`ObjectSerializer.java`​ インターフェースを使用して、オブジェクトをバイト配列にシリアル化したり、非シリアル化したりできます。 [GitHub の ObjectSerializer.java](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/ObjectSerializer.java)​ を参照してください。 シリアル API には次の機能があります。 - スレッドセーフである - シリアル化およびストリーミング時に OutputStream を渡す - 入力ソースとして InputStream を使用可能 Mule でシリアル化および非シリアル化する場合、​`getInternalProtocol()`​ メソッドを定義する必要があります。 シリアル化されたオブジェクトを外部システムで使用する場合、そのオブジェクトを ​`getExternalProtocol()`​ メソッドで定義します。 [Serialization Protocol (シリアル化プロトコル)](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/SerializationProtocol.java)​ は、シリアル化および非シリアル化するために使用するオブジェクトです。 ## [](#カスタムシリアライザーの設定)カスタムシリアライザーの設定 Mule の ​``​ タグを使用して、Mule アプリケーションのデフォルトの ​`ObjectSerializer`​ を設定します。 ```xml ``` 次に、​`serializer.xml`​ ファイルで bean を設定します。 ```xml ``` ## [](#設定済みの-objectserializer-の取得)設定済みの ObjectSerializer の取得 Java コード内で ​`ObjectSerializer`​ を取得するさまざまな方法があります。一般に、連動関係を挿入する方法をお勧めします。次のコード例は、現在設定されている ​`ObjectSerializer`​ を取得する方法を示しています。 ```java public class MyClass { @Inject private ObjectSerializer objectSerializer; } ``` 特定の名前のシリアライザーが必要な場合 (それがデフォルトかどうかに関係なく)、名前でシリアライザーにアクセスできます。 ```java public class MyClass { @Inject @Named ("mySerializer") private ObjectSerializer objectSerializer; } ``` ## [](#kryo-を使用したパフォーマンスの向上)Kryo を使用したパフォーマンスの向上 次のコンポーネントを使用している場合、Kryo を使用すると、通常の Java シリアル化よりもパフォーマンスが特に向上します。 - 永続的なオブジェクトストアまたはクラスタリングされたオブジェクトストア - 永続的な VM キューまたは分散 VM キュー - JMS Connector どのような場合も、圧縮を使用しない Kryo シリアライザーは通常の Java シリアライザーよりも大幅に高速です。ただし、高可用性 (HA) の場合に限り、圧縮モードでパフォーマンスが向上します。 圧縮を価値のあるものにするには、圧縮と圧縮解除にかかる CPU 時間が、ペイロードサイズの縮小によって節約された I/O 時間を大幅に下回る必要があります。通常、ネットワーク操作はディスク操作よりも低速です。また、HA クラスタリングにはノードの複製が必要です (つまり、より多くのトラフィックが発生します)。このため、圧縮は HA 環境でのみ役立ちます。 これは普遍定数ではありません。低速のディスクや高い I/O 要求のあるマシンで Mule を実行する場合があります。どのような場合も、この状況では圧縮に価値がある可能性があります。また、テストは 1 MB のペイロードを使用して実行されました。データストリームがこれより大きい場合、圧縮の価値がさらに高まります。 ## [](#シリアル化を使用する場合の考慮事項)シリアル化を使用する場合の考慮事項 シリアル化を使用する場合は、以下の制限と考慮事項に注意してください。 ### [](#シリアライザーの変更には白紙の状態が必要)シリアライザーの変更には白紙の状態が必要 シリアライザーは相互運用可能ではなく、代替可能でもありません。つまり、アプリケーションで使用するシリアライザーを変更する場合は、VM および JMS キュー内のすべてのメッセージがコンシュームされていること、および新しいシリアライザーに引き継がれるまでにそれらのキューが空になっていることを確認します。 Kryo シリアライザーは、Java シリアライザーが書き込んだデータグラムを読み取ることはできません (その逆も同様)。永続的なオブジェクトストアでも同様です。1 つのシリアライザーで生成されたエントリを別のシリアライザーで読み取ることはできません。 ### [](#共有された-vm-connector-ではドメインのデフォルトのシリアライザーを使用)共有された VM Connector ではドメインのデフォルトのシリアライザーを使用 ドメインを使用すると、アプリケーション間でリソースを共有できます。たとえば、ドメインで VM Connector を定義すると、VM メッセージキューを介してアプリケーション間の通信ができます。 ただし、シリアライザーはアプリケーションレベルでのみ設定できます。シリアライザーをドメインレベルで設定することはできません。 アプリケーション A と B が、その両方が属しているドメインで定義された VM Connector を介して、相互に通信するとします。ただし、A はシリアル化に Java を使用し、B は Kryo を使用します。この場合、その特定のメッセージはアプリケーションのシリアライザーではシリアル化されず、VM Connector で使用されているシリアライザー (ドメインレベルのデフォルトのシリアライザー) でシリアル化されるため、シリアル化は機能します。これは「プラグアンドプレー環境」には適していますが、共有された VM Connector で Kryo を使用することによるパフォーマンスの向上を実現することはできません。 ### [](#java-17-のサポート)Java 17 のサポート バージョン 4.6 以降、Mule Runtime は Java 17 をサポートしています。Java 17 では JPMS が適用されます。この機能を実現するため、Mulesoft ではデフォルトの Kryo フレームワークに替わるいくつかのカスタムシリアライザーが導入されます。これは、デフォルトのフレームワークで使用するメカニズムでは JPMS のカプセル化が壊れるためです。 Mule Runtime 4.6 と Java 17 への移行時に、Kryo シリアライザーが HTTP Connector 証明書をシリアル化しない可能性があります。この問題は、属性内に証明書がある HTTP Connector と一緒に Kryo シリアライザーを使用している場合に発生します。 ### [](#ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上)ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上 ローカルの永続的なオブジェクトストアでは、オブジェクトストアの実装に対する競合が多いためにパフォーマンス上の利点はありません。 ### [](#jms-キューでのわずかなパフォーマンスの向上)JMS キューでのわずかなパフォーマンスの向上 JMS API では、キューが ​`javax.jms.Message`​ クラスのインスタンスを提供する必要があることが指定されており、キューは未加工のペイロードオブジェクトを操作しません。メッセージをシリアル化するのは Mule ではなくブローカークライアントです。そのため、このシナリオでは、Kryo の設定による影響は最小限に抑えられます。 JMS で Kryo を使用する場合のパフォーマンス上の利点は、Mule が MuleSession をシリアル化して Base64 形式でヘッダーとして使用することのみです。Kryo を使用して MuleSession をシリアル化すると、パフォーマンスが最大 10% 向上する可能性がありますが、これは Mule ではなく主に JMS ブローカーによるものです。 ### [](#問題のある型)問題のある型 Kryo は、​`Serializable`​ インターフェースを実装していないオブジェクトをシリアル化できますが、Kryo をデフォルトのシリアライザーとして設定しても、それは、VM Connector、ObjectSerializer、クラスターなどのコンポーネントがこのインターフェースを実装していないオブジェクトを処理できることを意味しません。Kryo はこのようなオブジェクトを操作できますが、これらのコンポーネントの Java API では、メソッドの署名内の ​`Serializable`​ のインスタンスが引き続き予期されます。 `Serializable`​ インターフェースを実装していないオブジェクトでは、通常の Java シリアル化は失敗します。ただし、Serializable インターフェースを実装していない別のオブジェクトがシリアル化に含まれていても、Kryo は成功する可能性があります (ただし保証できません)。典型的な例として、 [NetSuite](https://anypoint.mulesoft.com/exchange/?search=netsuite)​ または [Microsoft Dynamics CRM](https://anypoint.mulesoft.com/exchange/?search=Microsoft+Dynamics+CRM&type=connector)​ Connector で使用されている ​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl,`​ を含む POJO があります。 ## [](#関連情報)関連情報 - [Kryo 情報](https://github.com/EsotericSoftware/kryo) # カスタムシリアライザーの設定 デフォルトでは、Mule Runtime Engine (Mule) は通常の Java シリアル化を使用します。ただし、Mule アプリケーションで ​`defaultObjectSerializer`​ を設定すると、異なるシリアル化メカニズム (Kryo シリアライザーや他のカスタムシリアライザーなど) を指定できます。 カスタムシリアライザーを使用すると、Mule で次のいずれかのプロセスを実行する場合に機能とパフォーマンスが向上する可能性があります。 - 永続的なオブジェクトストアに対する読み書き - 永続的な VM キューまたは JMS キューに対する読み書き - Mule クラスターを介したオブジェクトの配信 - ファイルからのオブジェクトに対する読み書き カスタマイズはバッチモジュールの動作に影響しません。バッチモジュールでは Kryo シリアライザーが常に使用されます。 ## [](#シリアライザーと-mule-の互換性)シリアライザーと Mule の互換性 Mule Runtime Engine (Enterprise Edition) を実行している場合、Kryo シリアライザーを設定してパフォーマンスを向上できます。 Mule Kernel (Community Edition) を使用している場合は、シリアル化 API を使用してカスタムシリアライザーを作成できます。 ## [](#kryo-シリアライザーの設定)Kryo シリアライザーの設定 Mule では、Kryo フレームワークに依存する ​`ObjectSerializer`​ の実装が提供されます。Kryo を使用すると、次の利点が得られます。 - パフォーマンスの向上 Kryo は Java シリアル化よりも大幅に高速です。 - より広範な Java 型のサポート Kryo は、Java シリアル化のほとんどの制限に拘束されません。たとえば、​`Serializable`​ インターフェースを実装する必要はなく、デフォルトのコンストラクターを持つ必要もありません。 - 圧縮のサポート Deflate または GZip 圧縮アルゴリズムを使用できます。 Kryo 名前空間を使用すると、カスタム Spring bean を定義せずに、Mule アプリケーション内でこのシリアライザーを有効にできます。次の設定例では、デフォルトのシリアライザーを Kryo ベースのシリアライザーに設定します。 ```xml ``` 圧縮を設定するための ​`compressionMode`​ XML 属性を含めることもできます。 ```xml ``` ## [](#シリアル化-api-を使用したカスタムシリアライザーの作成)シリアル化 API を使用したカスタムシリアライザーの作成 オープンソースのシリアル化 API で提供されている ​`ObjectSerializer.java`​ インターフェースを使用して、オブジェクトをバイト配列にシリアル化したり、非シリアル化したりできます。 [GitHub の ObjectSerializer.java](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/ObjectSerializer.java)​ を参照してください。 シリアル API には次の機能があります。 - スレッドセーフである - シリアル化およびストリーミング時に OutputStream を渡す - 入力ソースとして InputStream を使用可能 Mule でシリアル化および非シリアル化する場合、​`getInternalProtocol()`​ メソッドを定義する必要があります。 シリアル化されたオブジェクトを外部システムで使用する場合、そのオブジェクトを ​`getExternalProtocol()`​ メソッドで定義します。 [Serialization Protocol (シリアル化プロトコル)](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/SerializationProtocol.java)​ は、シリアル化および非シリアル化するために使用するオブジェクトです。 ## [](#カスタムシリアライザーの設定)カスタムシリアライザーの設定 Mule の ​``​ タグを使用して、Mule アプリケーションのデフォルトの ​`ObjectSerializer`​ を設定します。 ```xml ``` 次に、​`serializer.xml`​ ファイルで bean を設定します。 ```xml ``` ## [](#設定済みの-objectserializer-の取得)設定済みの ObjectSerializer の取得 Java コード内で ​`ObjectSerializer`​ を取得するさまざまな方法があります。一般に、連動関係を挿入する方法をお勧めします。次のコード例は、現在設定されている ​`ObjectSerializer`​ を取得する方法を示しています。 ```java public class MyClass { @Inject private ObjectSerializer objectSerializer; } ``` 特定の名前のシリアライザーが必要な場合 (それがデフォルトかどうかに関係なく)、名前でシリアライザーにアクセスできます。 ```java public class MyClass { @Inject @Named ("mySerializer") private ObjectSerializer objectSerializer; } ``` ## [](#kryo-を使用したパフォーマンスの向上)Kryo を使用したパフォーマンスの向上 次のコンポーネントを使用している場合、Kryo を使用すると、通常の Java シリアル化よりもパフォーマンスが特に向上します。 - 永続的なオブジェクトストアまたはクラスタリングされたオブジェクトストア - 永続的な VM キューまたは分散 VM キュー - JMS Connector どのような場合も、圧縮を使用しない Kryo シリアライザーは通常の Java シリアライザーよりも大幅に高速です。ただし、高可用性 (HA) の場合に限り、圧縮モードでパフォーマンスが向上します。 圧縮を価値のあるものにするには、圧縮と圧縮解除にかかる CPU 時間が、ペイロードサイズの縮小によって節約された I/O 時間を大幅に下回る必要があります。通常、ネットワーク操作はディスク操作よりも低速です。また、HA クラスタリングにはノードの複製が必要です (つまり、より多くのトラフィックが発生します)。このため、圧縮は HA 環境でのみ役立ちます。 これは普遍定数ではありません。低速のディスクや高い I/O 要求のあるマシンで Mule を実行する場合があります。どのような場合も、この状況では圧縮に価値がある可能性があります。また、テストは 1 MB のペイロードを使用して実行されました。データストリームがこれより大きい場合、圧縮の価値がさらに高まります。 ## [](#シリアル化を使用する場合の考慮事項)シリアル化を使用する場合の考慮事項 シリアル化を使用する場合は、以下の制限と考慮事項に注意してください。 ### [](#シリアライザーの変更には白紙の状態が必要)シリアライザーの変更には白紙の状態が必要 シリアライザーは相互運用可能ではなく、代替可能でもありません。つまり、アプリケーションで使用するシリアライザーを変更する場合は、VM および JMS キュー内のすべてのメッセージがコンシュームされていること、および新しいシリアライザーに引き継がれるまでにそれらのキューが空になっていることを確認します。 Kryo シリアライザーは、Java シリアライザーが書き込んだデータグラムを読み取ることはできません (その逆も同様)。永続的なオブジェクトストアでも同様です。1 つのシリアライザーで生成されたエントリを別のシリアライザーで読み取ることはできません。 ### [](#共有された-vm-connector-ではドメインのデフォルトのシリアライザーを使用)共有された VM Connector ではドメインのデフォルトのシリアライザーを使用 ドメインを使用すると、アプリケーション間でリソースを共有できます。たとえば、ドメインで VM Connector を定義すると、VM メッセージキューを介してアプリケーション間の通信ができます。 ただし、シリアライザーはアプリケーションレベルでのみ設定できます。シリアライザーをドメインレベルで設定することはできません。 アプリケーション A と B が、その両方が属しているドメインで定義された VM Connector を介して、相互に通信するとします。ただし、A はシリアル化に Java を使用し、B は Kryo を使用します。この場合、その特定のメッセージはアプリケーションのシリアライザーではシリアル化されず、VM Connector で使用されているシリアライザー (ドメインレベルのデフォルトのシリアライザー) でシリアル化されるため、シリアル化は機能します。これは「プラグアンドプレー環境」には適していますが、共有された VM Connector で Kryo を使用することによるパフォーマンスの向上を実現することはできません。 ### [](#java-17-のサポート)Java 17 のサポート バージョン 4.6 以降、Mule Runtime は Java 17 をサポートしています。Java 17 では JPMS が適用されます。この機能を実現するため、Mulesoft ではデフォルトの Kryo フレームワークに替わるいくつかのカスタムシリアライザーが導入されます。これは、デフォルトのフレームワークで使用するメカニズムでは JPMS のカプセル化が壊れるためです。 Mule Runtime 4.6 と Java 17 への移行時に、Kryo シリアライザーが HTTP Connector 証明書をシリアル化しない可能性があります。この問題は、属性内に証明書がある HTTP Connector と一緒に Kryo シリアライザーを使用している場合に発生します。 ### [](#ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上)ローカルの永続的なオブジェクトストアでのわずかなパフォーマンスの向上 ローカルの永続的なオブジェクトストアでは、オブジェクトストアの実装に対する競合が多いためにパフォーマンス上の利点はありません。 ### [](#jms-キューでのわずかなパフォーマンスの向上)JMS キューでのわずかなパフォーマンスの向上 JMS API では、キューが ​`javax.jms.Message`​ クラスのインスタンスを提供する必要があることが指定されており、キューは未加工のペイロードオブジェクトを操作しません。メッセージをシリアル化するのは Mule ではなくブローカークライアントです。そのため、このシナリオでは、Kryo の設定による影響は最小限に抑えられます。 JMS で Kryo を使用する場合のパフォーマンス上の利点は、Mule が MuleSession をシリアル化して Base64 形式でヘッダーとして使用することのみです。Kryo を使用して MuleSession をシリアル化すると、パフォーマンスが最大 10% 向上する可能性がありますが、これは Mule ではなく主に JMS ブローカーによるものです。 ### [](#問題のある型)問題のある型 Kryo は、​`Serializable`​ インターフェースを実装していないオブジェクトをシリアル化できますが、Kryo をデフォルトのシリアライザーとして設定しても、それは、VM Connector、ObjectSerializer、クラスターなどのコンポーネントがこのインターフェースを実装していないオブジェクトを処理できることを意味しません。Kryo はこのようなオブジェクトを操作できますが、これらのコンポーネントの Java API では、メソッドの署名内の ​`Serializable`​ のインスタンスが引き続き予期されます。 `Serializable`​ インターフェースを実装していないオブジェクトでは、通常の Java シリアル化は失敗します。ただし、Serializable インターフェースを実装していない別のオブジェクトがシリアル化に含まれていても、Kryo は成功する可能性があります (ただし保証できません)。典型的な例として、 [NetSuite](https://anypoint.mulesoft.com/exchange/?search=netsuite)​ または [Microsoft Dynamics CRM](https://anypoint.mulesoft.com/exchange/?search=Microsoft+Dynamics+CRM&type=connector)​ Connector で使用されている ​`org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl,`​ を含む POJO があります。 ## [](#関連情報)関連情報 - [Kryo 情報](https://github.com/EsotericSoftware/kryo) # カスタム設定プロパティプロバイダー Mule SDK および Mule API を使用して、アプリケーションで設定プロパティ値を検出できるようにするカスタム設定プロパティプロバイダーを作成できます。 ## [](#mule-api)Mule API API のメインインターフェースは次のとおりです。 - `ConfigurationPropertiesProviderFactory` このインターフェースは、設定プロパティプロバイダーのカスタム実装を検出するために使用されます。Mule Runtime Engine (Mule) は、​`getSupportedComponentIdentifier()`​ メソッドによって提供される名前空間と名前に一致する設定要素を検出すると、​`createProvider(..)`​ メソッドで定義した設定を使用して ​`ConfigurationPropertiesProvider`​ を作成するようにファクトリーに要求します。Mule は、SPI を使用して ​`ConfigurationPropertiesProviderFactory`​ のインスタンスを検出します。 - `ConfigurationPropertiesProvider` Mule が設定プロパティを検出すると、このインターフェースを呼び出してプロパティの値を解決します。 ## [](#例-セキュア設定プロパティプロバイダー)例: セキュア設定プロパティプロバイダー セキュリティモジュールは、API を使用して ​`ConfigurationPropertiesProviderFactory`​ を実装します。 ```java import static org.mule.runtime.api.component.ComponentIdentifier.builder; public class SecureConfigurationPropertiesProviderFactory implements ConfigurationPropertiesProviderFactory { public static final String EXTENSION_NAMESPACE = "secure-properties"; public static final String SECURE_CONFIGURATION_PROPERTIES_ELEMENT = "config"; public static final ComponentIdentifier SECURE_CONFIGURATION_PROPERTIES = builder().namespace(EXTENSION_NAMESPACE).name(SECURE_CONFIGURATION_PROPERTIES_ELEMENT).build(); ... @Override public ComponentIdentifier getSupportedComponentIdentifier() { return SECURE_CONFIGURATION_PROPERTIES; } @Override public SecureConfigurationPropertiesProvider createProvider(ConfigurationParameters parameters, ResourceProvider externalResourceProvider) { String file = parameters.getStringParameter("file"); .. String key = parameters.getStringParameter("key"); ... return new SecureConfigurationPropertiesProvider(..); } } ``` `getSupportedComponentIdentifier()`​ によって返される ​`ComponentIdentifier`​ は、次の設定コンポーネントに対して照合されます。 ```xml ``` Mule は、設定を処理するときに ​`secure-properties:config`​ コンポーネントを検出し、​`SecureConfigurationPropertiesProvider.createProvider(..)`​ メソッドを呼び出して、設定プロパティを解決するために使用される ​`SecureConfigurationPropertiesProvider`​ のインスタンスを作成します。 ```java public class SecureConfigurationPropertiesProvider extends DefaultConfigurationPropertiesProvider { private final static String SECURE_PREFIX = "secure::"; private final static Pattern SECURE_PATTERN = Pattern.compile("\\$\\{" + SECURE_PREFIX + "[^}]*}"); private final EncryptionAlgorithm algorithm; private final EncryptionMode mode; private final boolean fileLevelEncryption; private final SecurePropertyPlaceholderModule securePropertyPlaceholderModule = new SecurePropertyPlaceholderModule(); public SecureConfigurationPropertiesProvider(ResourceProvider resourceProvider, String file, EncryptionAlgorithm algorithm, String key, EncryptionMode mode, String encoding, boolean fileLevelEncryption) { ... } @Override public Optional getConfigurationProperty(String configurationAttributeKey) { if (configurationAttributeKey.startsWith(SECURE_PREFIX)) { String effectiveKey = configurationAttributeKey.substring(SECURE_PREFIX.length()); ConfigurationProperty originalConfigurationProperty = configurationAttributes.get(effectiveKey); if (originalConfigurationProperty == null) { return empty(); } String originalString = ((String) originalConfigurationProperty.getRawValue()); String encryptedValue = originalString.substring(originalConfigurationProperty.getKey().length() + 1, originalString.length() - algorithm.name().length() - mode.name().length() - 2); final String decryptedValue = resolveInnerProperties(securePropertyPlaceholderModule.convertPropertyValue(encryptedValue)); return of(new ConfigurationProperty() { @Override public Object getSource() { return originalConfigurationProperty.getSource(); } @Override public Object getRawValue() { return decryptedValue; } @Override public String getKey() { return originalConfigurationProperty.getKey(); } }); } else { return empty(); } } @Override public String getDescription() { ComponentLocation location = (ComponentLocation) getAnnotation(LOCATION_KEY); return format(" - file: %s, line number: %s", fileLocation, location.getFileName().orElse(UNKNOWN), location.getLineInFile().map(String::valueOf).orElse("unknown")); } ... } ``` このリゾルバーに固有のプレフィックス (​`PREFIX::`​ 形式) を定義します。プレフィックスにより、ユーザーは特定のリゾルバーに絞り込むことができます。これは、​`SECURE_PREFIX`​ で定義されるプレフィックスを使用して ​`SecureConfigurationPropertiesProvider`​ に実装されます。 設定では、プレフィックスを次のように使用する必要があります。 ```xml ``` `set-payload`​ の ​`value`​ 属性でどのようにセキュアなプロパティのリゾルバー (​`secure::`​ プレフィックス) が使用されているのかを確認してください。 ## [](#例-mule-sdk-モジュール)例: Mule SDK モジュール Studio 内でカスタム設定プロパティプロバイダーを有効にする設定要素を作成するには、Mule SDK モジュールを作成する必要があります。 カスタム設定プロパティリゾルバー拡張機能の実装を開始するためのすべてのインフラストラクチャコードが含まれる [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​をダウンロードまたはチェックアウトできます。 このサンプルプロジェクトは、Mule SDK モジュールです。詳細は、​[「Mule SDK の使用開始」](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​を参照してください。 ### [](#カスタムプロパティソースにアクセスするモジュールをカスタマイズする)カスタムプロパティソースにアクセスするモジュールをカスタマイズする Mule SDK モジュールをカスタマイズする手順は次のとおりです。 1. [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​を任意の IDE にインポートします。 2. `pom.xml`​ ファイルを開きます。 1. モジュールの GAV (​`groupId`​、​`artifactId`​、​`version`​) を定義します。 2. モジュールの ​`name`​ を定義します。 3. プロパティプロバイダーが必要とする最小 Mule バージョンを確認します。この例は、考えられるすべてのシナリオをカバーできる Mule 4.1.1 以降と互換性があります。​[「SDK バージョンの選択」](https://docs.mulesoft.com/mule-sdk/latest/choosing-version)​を参照してください。 3. コードのパッケージ名 (​`com.my.company.custom.provider.api`​) を変更します。 4. `resources/META-INF/services/org.mule.runtime.config.api.dsl.model.properties.ConfigurationPropertiesProviderFactory`​ を開き、以前に変更したパッケージ名に合わせてコンテンツを変更します。 5. `CustomConfigurationPropertiesExtension`​ クラスを開きます。 1. `EXTENSION_NAME`​ 定数をモジュールの名前に変更します。 2. `@Extension`​ アノテーションの ​`vendor`​ メソッドパラメーターを会社名に変更します。 3. 最後のセクションをカスタマイズして、モジュールの ​`config`​ 要素で設定できるパラメーターを定義します。 6. `CustomConfigurationPropertiesProviderFactory`​ クラスを開きます。 1. モジュールで解決する必要のある設定プロパティに合わせて、​`CUSTOM_PROPERTIES_PREFIX`​ 値をわかりやすいプレフィックスに変更します。 2. カスタムソースのプロパティをルックアップするようにクラス実装を変更します。 7. 新しいモジュール機能をカバーするために、より多くのテストケースで ​`test/munit`​ の MUnit テストケースを更新します。 モジュールの準備ができたら、​`mvn clean install`​ を使用してローカルにインストールし、Studio からモジュールにアクセスできるようにすることができます。 ## [](#mule-アプリケーションでカスタムプロパティプロバイダーを使用する)Mule アプリケーションでカスタムプロパティプロバイダーを使用する カスタムプロパティプロバイダーを使用する手順は、次のとおりです。 1. Studio でアプリケーションを作成します。 2. 新しいモジュールに連動関係を追加します。 1. `pom.xml`​ ファイルを開きます。 2. GAV を使用して、モジュールに配置する新しい連動関係を ​``​ タグ内に追加します。 3. `mule-plugin`​ は、Mule モジュールであるため忘れずに追加します。 4. 変更を保存します。 次に、アプリケーション XML ファイルを開き、​**\[Global Elements (グローバル要素)\]**​ タブで ​**\[Create (作成)\]**​ をクリックします。​**\[Connector Configuration (コネクタ設定)\]**​ には、次のようにカスタムモジュールの設定を選択するオプションがあります。 ![custom configuration provider](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/custom-configuration-provider.png) これで、新しいコンポーネントを設定し、モジュールで定義されたプレフィックスのプロパティを使用できるようになりました。 ## [](#カスタム設定プロパティプロバイダーの使用とコネクタの使用)カスタム設定プロパティプロバイダーの使用とコネクタの使用 静的プロパティの場合、実行時に変更されないため、プロパティプロバイダーのアプローチを使用します。実行時にプロパティが変更される可能性がある場合、そのいずれかの操作として値を提供できるコネクタを作成します。
Java 用 Mule SDK​ は、カスタム設定プロパティプロバイダーを実装するために使用されますが、​ConnectionProviders​ を使用して外部ソースに接続することはできません。これは、​ConnectionProviders​ が Mule Runtime によって管理されており、静的プロパティの解決後のフェーズで初期化されるためです。そのため、接続テストはカスタムプロパティプロバイダーではサポートされません。
# カスタム設定プロパティプロバイダー Mule SDK および Mule API を使用して、アプリケーションで設定プロパティ値を検出できるようにするカスタム設定プロパティプロバイダーを作成できます。 ## [](#mule-api)Mule API API のメインインターフェースは次のとおりです。 - `ConfigurationPropertiesProviderFactory` このインターフェースは、設定プロパティプロバイダーのカスタム実装を検出するために使用されます。Mule Runtime Engine (Mule) は、​`getSupportedComponentIdentifier()`​ メソッドによって提供される名前空間と名前に一致する設定要素を検出すると、​`createProvider(..)`​ メソッドで定義した設定を使用して ​`ConfigurationPropertiesProvider`​ を作成するようにファクトリーに要求します。Mule は、SPI を使用して ​`ConfigurationPropertiesProviderFactory`​ のインスタンスを検出します。 - `ConfigurationPropertiesProvider` Mule が設定プロパティを検出すると、このインターフェースを呼び出してプロパティの値を解決します。 ## [](#例-セキュア設定プロパティプロバイダー)例: セキュア設定プロパティプロバイダー セキュリティモジュールは、API を使用して ​`ConfigurationPropertiesProviderFactory`​ を実装します。 ```java import static org.mule.runtime.api.component.ComponentIdentifier.builder; public class SecureConfigurationPropertiesProviderFactory implements ConfigurationPropertiesProviderFactory { public static final String EXTENSION_NAMESPACE = "secure-properties"; public static final String SECURE_CONFIGURATION_PROPERTIES_ELEMENT = "config"; public static final ComponentIdentifier SECURE_CONFIGURATION_PROPERTIES = builder().namespace(EXTENSION_NAMESPACE).name(SECURE_CONFIGURATION_PROPERTIES_ELEMENT).build(); ... @Override public ComponentIdentifier getSupportedComponentIdentifier() { return SECURE_CONFIGURATION_PROPERTIES; } @Override public SecureConfigurationPropertiesProvider createProvider(ConfigurationParameters parameters, ResourceProvider externalResourceProvider) { String file = parameters.getStringParameter("file"); .. String key = parameters.getStringParameter("key"); ... return new SecureConfigurationPropertiesProvider(..); } } ``` `getSupportedComponentIdentifier()`​ によって返される ​`ComponentIdentifier`​ は、次の設定コンポーネントに対して照合されます。 ```xml ``` Mule は、設定を処理するときに ​`secure-properties:config`​ コンポーネントを検出し、​`SecureConfigurationPropertiesProvider.createProvider(..)`​ メソッドを呼び出して、設定プロパティを解決するために使用される ​`SecureConfigurationPropertiesProvider`​ のインスタンスを作成します。 ```java public class SecureConfigurationPropertiesProvider extends DefaultConfigurationPropertiesProvider { private final static String SECURE_PREFIX = "secure::"; private final static Pattern SECURE_PATTERN = Pattern.compile("\\$\\{" + SECURE_PREFIX + "[^}]*}"); private final EncryptionAlgorithm algorithm; private final EncryptionMode mode; private final boolean fileLevelEncryption; private final SecurePropertyPlaceholderModule securePropertyPlaceholderModule = new SecurePropertyPlaceholderModule(); public SecureConfigurationPropertiesProvider(ResourceProvider resourceProvider, String file, EncryptionAlgorithm algorithm, String key, EncryptionMode mode, String encoding, boolean fileLevelEncryption) { ... } @Override public Optional getConfigurationProperty(String configurationAttributeKey) { if (configurationAttributeKey.startsWith(SECURE_PREFIX)) { String effectiveKey = configurationAttributeKey.substring(SECURE_PREFIX.length()); ConfigurationProperty originalConfigurationProperty = configurationAttributes.get(effectiveKey); if (originalConfigurationProperty == null) { return empty(); } String originalString = ((String) originalConfigurationProperty.getRawValue()); String encryptedValue = originalString.substring(originalConfigurationProperty.getKey().length() + 1, originalString.length() - algorithm.name().length() - mode.name().length() - 2); final String decryptedValue = resolveInnerProperties(securePropertyPlaceholderModule.convertPropertyValue(encryptedValue)); return of(new ConfigurationProperty() { @Override public Object getSource() { return originalConfigurationProperty.getSource(); } @Override public Object getRawValue() { return decryptedValue; } @Override public String getKey() { return originalConfigurationProperty.getKey(); } }); } else { return empty(); } } @Override public String getDescription() { ComponentLocation location = (ComponentLocation) getAnnotation(LOCATION_KEY); return format(" - file: %s, line number: %s", fileLocation, location.getFileName().orElse(UNKNOWN), location.getLineInFile().map(String::valueOf).orElse("unknown")); } ... } ``` このリゾルバーに固有のプレフィックス (​`PREFIX::`​ 形式) を定義します。プレフィックスにより、ユーザーは特定のリゾルバーに絞り込むことができます。これは、​`SECURE_PREFIX`​ で定義されるプレフィックスを使用して ​`SecureConfigurationPropertiesProvider`​ に実装されます。 設定では、プレフィックスを次のように使用する必要があります。 ```xml ``` `set-payload`​ の ​`value`​ 属性でどのようにセキュアなプロパティのリゾルバー (​`secure::`​ プレフィックス) が使用されているのかを確認してください。 ## [](#例-mule-sdk-モジュール)例: Mule SDK モジュール Studio 内でカスタム設定プロパティプロバイダーを有効にする設定要素を作成するには、Mule SDK モジュールを作成する必要があります。 カスタム設定プロパティリゾルバー拡張機能の実装を開始するためのすべてのインフラストラクチャコードが含まれる [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​をダウンロードまたはチェックアウトできます。 このサンプルプロジェクトは、Mule SDK モジュールです。詳細は、​[「Mule SDK の使用開始」](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​を参照してください。 ### [](#カスタムプロパティソースにアクセスするモジュールをカスタマイズする)カスタムプロパティソースにアクセスするモジュールをカスタマイズする Mule SDK モジュールをカスタマイズする手順は次のとおりです。 1. [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​を任意の IDE にインポートします。 2. `pom.xml`​ ファイルを開きます。 1. モジュールの GAV (​`groupId`​、​`artifactId`​、​`version`​) を定義します。 2. モジュールの ​`name`​ を定義します。 3. プロパティプロバイダーが必要とする最小 Mule バージョンを確認します。この例は、考えられるすべてのシナリオをカバーできる Mule 4.1.1 以降と互換性があります。​[「SDK バージョンの選択」](https://docs.mulesoft.com/mule-sdk/latest/choosing-version)​を参照してください。 3. コードのパッケージ名 (​`com.my.company.custom.provider.api`​) を変更します。 4. `resources/META-INF/services/org.mule.runtime.config.api.dsl.model.properties.ConfigurationPropertiesProviderFactory`​ を開き、以前に変更したパッケージ名に合わせてコンテンツを変更します。 5. `CustomConfigurationPropertiesExtension`​ クラスを開きます。 1. `EXTENSION_NAME`​ 定数をモジュールの名前に変更します。 2. `@Extension`​ アノテーションの ​`vendor`​ メソッドパラメーターを会社名に変更します。 3. 最後のセクションをカスタマイズして、モジュールの ​`config`​ 要素で設定できるパラメーターを定義します。 6. `CustomConfigurationPropertiesProviderFactory`​ クラスを開きます。 1. モジュールで解決する必要のある設定プロパティに合わせて、​`CUSTOM_PROPERTIES_PREFIX`​ 値をわかりやすいプレフィックスに変更します。 2. カスタムソースのプロパティをルックアップするようにクラス実装を変更します。 7. 新しいモジュール機能をカバーするために、より多くのテストケースで ​`test/munit`​ の MUnit テストケースを更新します。 モジュールの準備ができたら、​`mvn clean install`​ を使用してローカルにインストールし、Studio からモジュールにアクセスできるようにすることができます。 ## [](#mule-アプリケーションでカスタムプロパティプロバイダーを使用する)Mule アプリケーションでカスタムプロパティプロバイダーを使用する カスタムプロパティプロバイダーを使用する手順は、次のとおりです。 1. Studio でアプリケーションを作成します。 2. 新しいモジュールに連動関係を追加します。 1. `pom.xml`​ ファイルを開きます。 2. GAV を使用して、モジュールに配置する新しい連動関係を ​``​ タグ内に追加します。 3. `mule-plugin`​ は、Mule モジュールであるため忘れずに追加します。 4. 変更を保存します。 次に、アプリケーション XML ファイルを開き、​**\[Global Elements (グローバル要素)\]**​ タブで ​**\[Create (作成)\]**​ をクリックします。​**\[Connector Configuration (コネクタ設定)\]**​ には、次のようにカスタムモジュールの設定を選択するオプションがあります。 ![custom configuration provider](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/custom-configuration-provider.png) これで、新しいコンポーネントを設定し、モジュールで定義されたプレフィックスのプロパティを使用できるようになりました。 ## [](#カスタム設定プロパティプロバイダーの使用とコネクタの使用)カスタム設定プロパティプロバイダーの使用とコネクタの使用 静的プロパティの場合、実行時に変更されないため、プロパティプロバイダーのアプローチを使用します。実行時にプロパティが変更される可能性がある場合、そのいずれかの操作として値を提供できるコネクタを作成します。
Java 用 Mule SDK​ は、カスタム設定プロパティプロバイダーを実装するために使用されますが、​ConnectionProviders​ を使用して外部ソースに接続することはできません。これは、​ConnectionProviders​ が Mule Runtime によって管理されており、静的プロパティの解決後のフェーズで初期化されるためです。そのため、接続テストはカスタムプロパティプロバイダーではサポートされません。
# カスタム設定プロパティプロバイダー Mule SDK および Mule API を使用して、アプリケーションで設定プロパティ値を検出できるようにするカスタム設定プロパティプロバイダーを作成できます。 ## [](#mule-api)Mule API API のメインインターフェースは次のとおりです。 - `ConfigurationPropertiesProviderFactory` このインターフェースは、設定プロパティプロバイダーのカスタム実装を検出するために使用されます。Mule Runtime Engine (Mule) は、​`getSupportedComponentIdentifier()`​ メソッドによって提供される名前空間と名前に一致する設定要素を検出すると、​`createProvider(..)`​ メソッドで定義した設定を使用して ​`ConfigurationPropertiesProvider`​ を作成するようにファクトリーに要求します。Mule は、SPI を使用して ​`ConfigurationPropertiesProviderFactory`​ のインスタンスを検出します。 - `ConfigurationPropertiesProvider` Mule が設定プロパティを検出すると、このインターフェースを呼び出してプロパティの値を解決します。 ## [](#例-セキュア設定プロパティプロバイダー)例: セキュア設定プロパティプロバイダー セキュリティモジュールは、API を使用して ​`ConfigurationPropertiesProviderFactory`​ を実装します。 ```java import static org.mule.runtime.api.component.ComponentIdentifier.builder; public class SecureConfigurationPropertiesProviderFactory implements ConfigurationPropertiesProviderFactory { public static final String EXTENSION_NAMESPACE = "secure-properties"; public static final String SECURE_CONFIGURATION_PROPERTIES_ELEMENT = "config"; public static final ComponentIdentifier SECURE_CONFIGURATION_PROPERTIES = builder().namespace(EXTENSION_NAMESPACE).name(SECURE_CONFIGURATION_PROPERTIES_ELEMENT).build(); ... @Override public ComponentIdentifier getSupportedComponentIdentifier() { return SECURE_CONFIGURATION_PROPERTIES; } @Override public SecureConfigurationPropertiesProvider createProvider(ConfigurationParameters parameters, ResourceProvider externalResourceProvider) { String file = parameters.getStringParameter("file"); .. String key = parameters.getStringParameter("key"); ... return new SecureConfigurationPropertiesProvider(..); } } ``` `getSupportedComponentIdentifier()`​ によって返される ​`ComponentIdentifier`​ は、次の設定コンポーネントに対して照合されます。 ```xml ``` Mule は、設定を処理するときに ​`secure-properties:config`​ コンポーネントを検出し、​`SecureConfigurationPropertiesProvider.createProvider(..)`​ メソッドを呼び出して、設定プロパティを解決するために使用される ​`SecureConfigurationPropertiesProvider`​ のインスタンスを作成します。 ```java public class SecureConfigurationPropertiesProvider extends DefaultConfigurationPropertiesProvider { private final static String SECURE_PREFIX = "secure::"; private final static Pattern SECURE_PATTERN = Pattern.compile("\\$\\{" + SECURE_PREFIX + "[^}]*}"); private final EncryptionAlgorithm algorithm; private final EncryptionMode mode; private final boolean fileLevelEncryption; private final SecurePropertyPlaceholderModule securePropertyPlaceholderModule = new SecurePropertyPlaceholderModule(); public SecureConfigurationPropertiesProvider(ResourceProvider resourceProvider, String file, EncryptionAlgorithm algorithm, String key, EncryptionMode mode, String encoding, boolean fileLevelEncryption) { ... } @Override public Optional getConfigurationProperty(String configurationAttributeKey) { if (configurationAttributeKey.startsWith(SECURE_PREFIX)) { String effectiveKey = configurationAttributeKey.substring(SECURE_PREFIX.length()); ConfigurationProperty originalConfigurationProperty = configurationAttributes.get(effectiveKey); if (originalConfigurationProperty == null) { return empty(); } String originalString = ((String) originalConfigurationProperty.getRawValue()); String encryptedValue = originalString.substring(originalConfigurationProperty.getKey().length() + 1, originalString.length() - algorithm.name().length() - mode.name().length() - 2); final String decryptedValue = resolveInnerProperties(securePropertyPlaceholderModule.convertPropertyValue(encryptedValue)); return of(new ConfigurationProperty() { @Override public Object getSource() { return originalConfigurationProperty.getSource(); } @Override public Object getRawValue() { return decryptedValue; } @Override public String getKey() { return originalConfigurationProperty.getKey(); } }); } else { return empty(); } } @Override public String getDescription() { ComponentLocation location = (ComponentLocation) getAnnotation(LOCATION_KEY); return format(" - file: %s, line number: %s", fileLocation, location.getFileName().orElse(UNKNOWN), location.getLineInFile().map(String::valueOf).orElse("unknown")); } ... } ``` このリゾルバーに固有のプレフィックス (​`PREFIX::`​ 形式) を定義します。プレフィックスにより、ユーザーは特定のリゾルバーに絞り込むことができます。これは、​`SECURE_PREFIX`​ で定義されるプレフィックスを使用して ​`SecureConfigurationPropertiesProvider`​ に実装されます。 設定では、プレフィックスを次のように使用する必要があります。 ```xml ``` `set-payload`​ の ​`value`​ 属性でどのようにセキュアなプロパティのリゾルバー (​`secure::`​ プレフィックス) が使用されているのかを確認してください。 ## [](#例-mule-sdk-モジュール)例: Mule SDK モジュール Studio 内でカスタム設定プロパティプロバイダーを有効にする設定要素を作成するには、Mule SDK モジュールを作成する必要があります。 カスタム設定プロパティリゾルバー拡張機能の実装を開始するためのすべてのインフラストラクチャコードが含まれる [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​をダウンロードまたはチェックアウトできます。 このサンプルプロジェクトは、Mule SDK モジュールです。詳細は、​[「Mule SDK の使用開始」](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​を参照してください。 ### [](#カスタムプロパティソースにアクセスするモジュールをカスタマイズする)カスタムプロパティソースにアクセスするモジュールをカスタマイズする Mule SDK モジュールをカスタマイズする手順は次のとおりです。 1. [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​を任意の IDE にインポートします。 2. `pom.xml`​ ファイルを開きます。 1. モジュールの GAV (​`groupId`​、​`artifactId`​、​`version`​) を定義します。 2. モジュールの ​`name`​ を定義します。 3. プロパティプロバイダーが必要とする最小 Mule バージョンを確認します。この例は、考えられるすべてのシナリオをカバーできる Mule 4.1.1 以降と互換性があります。​[「SDK バージョンの選択」](https://docs.mulesoft.com/mule-sdk/latest/choosing-version)​を参照してください。 3. コードのパッケージ名 (​`com.my.company.custom.provider.api`​) を変更します。 4. `resources/META-INF/services/org.mule.runtime.config.api.dsl.model.properties.ConfigurationPropertiesProviderFactory`​ を開き、以前に変更したパッケージ名に合わせてコンテンツを変更します。 5. `CustomConfigurationPropertiesExtension`​ クラスを開きます。 1. `EXTENSION_NAME`​ 定数をモジュールの名前に変更します。 2. `@Extension`​ アノテーションの ​`vendor`​ メソッドパラメーターを会社名に変更します。 3. 最後のセクションをカスタマイズして、モジュールの ​`config`​ 要素で設定できるパラメーターを定義します。 6. `CustomConfigurationPropertiesProviderFactory`​ クラスを開きます。 1. モジュールで解決する必要のある設定プロパティに合わせて、​`CUSTOM_PROPERTIES_PREFIX`​ 値をわかりやすいプレフィックスに変更します。 2. カスタムソースのプロパティをルックアップするようにクラス実装を変更します。 7. 新しいモジュール機能をカバーするために、より多くのテストケースで ​`test/munit`​ の MUnit テストケースを更新します。 モジュールの準備ができたら、​`mvn clean install`​ を使用してローカルにインストールし、Studio からモジュールにアクセスできるようにすることができます。 ## [](#mule-アプリケーションでカスタムプロパティプロバイダーを使用する)Mule アプリケーションでカスタムプロパティプロバイダーを使用する カスタムプロパティプロバイダーを使用する手順は、次のとおりです。 1. Studio でアプリケーションを作成します。 2. 新しいモジュールに連動関係を追加します。 1. `pom.xml`​ ファイルを開きます。 2. GAV を使用して、モジュールに配置する新しい連動関係を ​``​ タグ内に追加します。 3. `mule-plugin`​ は、Mule モジュールであるため忘れずに追加します。 4. 変更を保存します。 次に、アプリケーション XML ファイルを開き、​**\[Global Elements (グローバル要素)\]**​ タブで ​**\[Create (作成)\]**​ をクリックします。​**\[Connector Configuration (コネクタ設定)\]**​ には、次のようにカスタムモジュールの設定を選択するオプションがあります。 ![custom configuration provider](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/custom-configuration-provider.png) これで、新しいコンポーネントを設定し、モジュールで定義されたプレフィックスのプロパティを使用できるようになりました。 ## [](#カスタム設定プロパティプロバイダーの使用とコネクタの使用)カスタム設定プロパティプロバイダーの使用とコネクタの使用 静的プロパティの場合、実行時に変更されないため、プロパティプロバイダーのアプローチを使用します。実行時にプロパティが変更される可能性がある場合、そのいずれかの操作として値を提供できるコネクタを作成します。
Java 用 Mule SDK​ は、カスタム設定プロパティプロバイダーを実装するために使用されますが、​ConnectionProviders​ を使用して外部ソースに接続することはできません。これは、​ConnectionProviders​ が Mule Runtime によって管理されており、静的プロパティの解決後のフェーズで初期化されるためです。そのため、接続テストはカスタムプロパティプロバイダーではサポートされません。
# カスタム設定プロパティプロバイダー Mule SDK および Mule API を使用して、アプリケーションで設定プロパティ値を検出できるようにするカスタム設定プロパティプロバイダーを作成できます。 ## [](#mule-api)Mule API API のメインインターフェースは次のとおりです。 - `ConfigurationPropertiesProviderFactory` このインターフェースは、設定プロパティプロバイダーのカスタム実装を検出するために使用されます。Mule Runtime Engine (Mule) は、​`getSupportedComponentIdentifier()`​ メソッドによって提供される名前空間と名前に一致する設定要素を検出すると、​`createProvider(..)`​ メソッドで定義した設定を使用して ​`ConfigurationPropertiesProvider`​ を作成するようにファクトリーに要求します。Mule は、SPI を使用して ​`ConfigurationPropertiesProviderFactory`​ のインスタンスを検出します。 - `ConfigurationPropertiesProvider` Mule が設定プロパティを検出すると、このインターフェースを呼び出してプロパティの値を解決します。 ## [](#例-セキュア設定プロパティプロバイダー)例: セキュア設定プロパティプロバイダー セキュリティモジュールは、API を使用して ​`ConfigurationPropertiesProviderFactory`​ を実装します。 ```java import static org.mule.runtime.api.component.ComponentIdentifier.builder; public class SecureConfigurationPropertiesProviderFactory implements ConfigurationPropertiesProviderFactory { public static final String EXTENSION_NAMESPACE = "secure-properties"; public static final String SECURE_CONFIGURATION_PROPERTIES_ELEMENT = "config"; public static final ComponentIdentifier SECURE_CONFIGURATION_PROPERTIES = builder().namespace(EXTENSION_NAMESPACE).name(SECURE_CONFIGURATION_PROPERTIES_ELEMENT).build(); ... @Override public ComponentIdentifier getSupportedComponentIdentifier() { return SECURE_CONFIGURATION_PROPERTIES; } @Override public SecureConfigurationPropertiesProvider createProvider(ConfigurationParameters parameters, ResourceProvider externalResourceProvider) { String file = parameters.getStringParameter("file"); .. String key = parameters.getStringParameter("key"); ... return new SecureConfigurationPropertiesProvider(..); } } ``` `getSupportedComponentIdentifier()`​ によって返される ​`ComponentIdentifier`​ は、次の設定コンポーネントに対して照合されます。 ```xml ``` Mule は、設定を処理するときに ​`secure-properties:config`​ コンポーネントを検出し、​`SecureConfigurationPropertiesProvider.createProvider(..)`​ メソッドを呼び出して、設定プロパティを解決するために使用される ​`SecureConfigurationPropertiesProvider`​ のインスタンスを作成します。 ```java public class SecureConfigurationPropertiesProvider extends DefaultConfigurationPropertiesProvider { private final static String SECURE_PREFIX = "secure::"; private final static Pattern SECURE_PATTERN = Pattern.compile("\\$\\{" + SECURE_PREFIX + "[^}]*}"); private final EncryptionAlgorithm algorithm; private final EncryptionMode mode; private final boolean fileLevelEncryption; private final SecurePropertyPlaceholderModule securePropertyPlaceholderModule = new SecurePropertyPlaceholderModule(); public SecureConfigurationPropertiesProvider(ResourceProvider resourceProvider, String file, EncryptionAlgorithm algorithm, String key, EncryptionMode mode, String encoding, boolean fileLevelEncryption) { ... } @Override public Optional getConfigurationProperty(String configurationAttributeKey) { if (configurationAttributeKey.startsWith(SECURE_PREFIX)) { String effectiveKey = configurationAttributeKey.substring(SECURE_PREFIX.length()); ConfigurationProperty originalConfigurationProperty = configurationAttributes.get(effectiveKey); if (originalConfigurationProperty == null) { return empty(); } String originalString = ((String) originalConfigurationProperty.getRawValue()); String encryptedValue = originalString.substring(originalConfigurationProperty.getKey().length() + 1, originalString.length() - algorithm.name().length() - mode.name().length() - 2); final String decryptedValue = resolveInnerProperties(securePropertyPlaceholderModule.convertPropertyValue(encryptedValue)); return of(new ConfigurationProperty() { @Override public Object getSource() { return originalConfigurationProperty.getSource(); } @Override public Object getRawValue() { return decryptedValue; } @Override public String getKey() { return originalConfigurationProperty.getKey(); } }); } else { return empty(); } } @Override public String getDescription() { ComponentLocation location = (ComponentLocation) getAnnotation(LOCATION_KEY); return format(" - file: %s, line number: %s", fileLocation, location.getFileName().orElse(UNKNOWN), location.getLineInFile().map(String::valueOf).orElse("unknown")); } ... } ``` このリゾルバーに固有のプレフィックス (​`PREFIX::`​ 形式) を定義します。プレフィックスにより、ユーザーは特定のリゾルバーに絞り込むことができます。これは、​`SECURE_PREFIX`​ で定義されるプレフィックスを使用して ​`SecureConfigurationPropertiesProvider`​ に実装されます。 設定では、プレフィックスを次のように使用する必要があります。 ```xml ``` `set-payload`​ の ​`value`​ 属性でどのようにセキュアなプロパティのリゾルバー (​`secure::`​ プレフィックス) が使用されているのかを確認してください。 ## [](#例-mule-sdk-モジュール)例: Mule SDK モジュール Studio 内でカスタム設定プロパティプロバイダーを有効にする設定要素を作成するには、Mule SDK モジュールを作成する必要があります。 カスタム設定プロパティリゾルバー拡張機能の実装を開始するためのすべてのインフラストラクチャコードが含まれる [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​をダウンロードまたはチェックアウトできます。 このサンプルプロジェクトは、Mule SDK モジュールです。詳細は、​[「Mule SDK の使用開始」](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​を参照してください。 ### [](#カスタムプロパティソースにアクセスするモジュールをカスタマイズする)カスタムプロパティソースにアクセスするモジュールをカスタマイズする Mule SDK モジュールをカスタマイズする手順は次のとおりです。 1. [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​を任意の IDE にインポートします。 2. `pom.xml`​ ファイルを開きます。 1. モジュールの GAV (​`groupId`​、​`artifactId`​、​`version`​) を定義します。 2. モジュールの ​`name`​ を定義します。 3. プロパティプロバイダーが必要とする最小 Mule バージョンを確認します。この例は、考えられるすべてのシナリオをカバーできる Mule 4.1.1 以降と互換性があります。​[「SDK バージョンの選択」](https://docs.mulesoft.com/mule-sdk/latest/choosing-version)​を参照してください。 3. コードのパッケージ名 (​`com.my.company.custom.provider.api`​) を変更します。 4. `resources/META-INF/services/org.mule.runtime.config.api.dsl.model.properties.ConfigurationPropertiesProviderFactory`​ を開き、以前に変更したパッケージ名に合わせてコンテンツを変更します。 5. `CustomConfigurationPropertiesExtension`​ クラスを開きます。 1. `EXTENSION_NAME`​ 定数をモジュールの名前に変更します。 2. `@Extension`​ アノテーションの ​`vendor`​ メソッドパラメーターを会社名に変更します。 3. 最後のセクションをカスタマイズして、モジュールの ​`config`​ 要素で設定できるパラメーターを定義します。 6. `CustomConfigurationPropertiesProviderFactory`​ クラスを開きます。 1. モジュールで解決する必要のある設定プロパティに合わせて、​`CUSTOM_PROPERTIES_PREFIX`​ 値をわかりやすいプレフィックスに変更します。 2. カスタムソースのプロパティをルックアップするようにクラス実装を変更します。 7. 新しいモジュール機能をカバーするために、より多くのテストケースで ​`test/munit`​ の MUnit テストケースを更新します。 モジュールの準備ができたら、​`mvn clean install`​ を使用してローカルにインストールし、Studio からモジュールにアクセスできるようにすることができます。 ## [](#mule-アプリケーションでカスタムプロパティプロバイダーを使用する)Mule アプリケーションでカスタムプロパティプロバイダーを使用する カスタムプロパティプロバイダーを使用する手順は、次のとおりです。 1. Studio でアプリケーションを作成します。 2. 新しいモジュールに連動関係を追加します。 1. `pom.xml`​ ファイルを開きます。 2. GAV を使用して、モジュールに配置する新しい連動関係を ​``​ タグ内に追加します。 3. `mule-plugin`​ は、Mule モジュールであるため忘れずに追加します。 4. 変更を保存します。 次に、アプリケーション XML ファイルを開き、​**\[Global Elements (グローバル要素)\]**​ タブで ​**\[Create (作成)\]**​ をクリックします。​**\[Connector Configuration (コネクタ設定)\]**​ には、次のようにカスタムモジュールの設定を選択するオプションがあります。 ![custom configuration provider](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/custom-configuration-provider.png) これで、新しいコンポーネントを設定し、モジュールで定義されたプレフィックスのプロパティを使用できるようになりました。 ## [](#カスタム設定プロパティプロバイダーの使用とコネクタの使用)カスタム設定プロパティプロバイダーの使用とコネクタの使用 静的プロパティの場合、実行時に変更されないため、プロパティプロバイダーのアプローチを使用します。実行時にプロパティが変更される可能性がある場合、そのいずれかの操作として値を提供できるコネクタを作成します。
Java 用 Mule SDK​ は、カスタム設定プロパティプロバイダーを実装するために使用されますが、​ConnectionProviders​ を使用して外部ソースに接続することはできません。これは、​ConnectionProviders​ が Mule Runtime によって管理されており、静的プロパティの解決後のフェーズで初期化されるためです。そのため、接続テストはカスタムプロパティプロバイダーではサポートされません。
# カスタム設定プロパティプロバイダー Mule SDK および Mule API を使用して、アプリケーションで設定プロパティ値を検出できるようにするカスタム設定プロパティプロバイダーを作成できます。 ## [](#mule-api)Mule API API のメインインターフェースは次のとおりです。 - `ConfigurationPropertiesProviderFactory` このインターフェースは、設定プロパティプロバイダーのカスタム実装を検出するために使用されます。Mule Runtime Engine (Mule) は、​`getSupportedComponentIdentifier()`​ メソッドによって提供される名前空間と名前に一致する設定要素を検出すると、​`createProvider(..)`​ メソッドで定義した設定を使用して ​`ConfigurationPropertiesProvider`​ を作成するようにファクトリーに要求します。Mule は、SPI を使用して ​`ConfigurationPropertiesProviderFactory`​ のインスタンスを検出します。 - `ConfigurationPropertiesProvider` Mule が設定プロパティを検出すると、このインターフェースを呼び出してプロパティの値を解決します。 ## [](#例-セキュア設定プロパティプロバイダー)例: セキュア設定プロパティプロバイダー セキュリティモジュールは、API を使用して ​`ConfigurationPropertiesProviderFactory`​ を実装します。 ```java import static org.mule.runtime.api.component.ComponentIdentifier.builder; import org.mule.runtime.properties.api.ConfigurationPropertiesProviderFactory; public class SecureConfigurationPropertiesProviderFactory implements ConfigurationPropertiesProviderFactory { public static final String EXTENSION_NAMESPACE = "secure-properties"; public static final String SECURE_CONFIGURATION_PROPERTIES_ELEMENT = "config"; public static final ComponentIdentifier SECURE_CONFIGURATION_PROPERTIES = builder().namespace(EXTENSION_NAMESPACE).name(SECURE_CONFIGURATION_PROPERTIES_ELEMENT).build(); ... @Override public ComponentIdentifier getSupportedComponentIdentifier() { return SECURE_CONFIGURATION_PROPERTIES; } @Override public SecureConfigurationPropertiesProvider createProvider(ConfigurationParameters parameters, ResourceProvider externalResourceProvider) { String file = parameters.getStringParameter("file"); .. String key = parameters.getStringParameter("key"); ... return new SecureConfigurationPropertiesProvider(..); } } ``` `getSupportedComponentIdentifier()`​ によって返される ​`ComponentIdentifier`​ は、次の設定コンポーネントに対して照合されます。 ```xml ``` Mule は、設定を処理するときに ​`secure-properties:config`​ コンポーネントを検出し、​`SecureConfigurationPropertiesProvider.createProvider(..)`​ メソッドを呼び出して、設定プロパティを解決するために使用される ​`SecureConfigurationPropertiesProvider`​ のインスタンスを作成します。 ```java public class SecureConfigurationPropertiesProvider extends DefaultConfigurationPropertiesProvider { private final static String SECURE_PREFIX = "secure::"; private final static Pattern SECURE_PATTERN = Pattern.compile("\\$\\{" + SECURE_PREFIX + "[^}]*}"); private final EncryptionAlgorithm algorithm; private final EncryptionMode mode; private final boolean fileLevelEncryption; private final SecurePropertyPlaceholderModule securePropertyPlaceholderModule = new SecurePropertyPlaceholderModule(); public SecureConfigurationPropertiesProvider(ResourceProvider resourceProvider, String file, EncryptionAlgorithm algorithm, String key, EncryptionMode mode, String encoding, boolean fileLevelEncryption) { ... } @Override public Optional getConfigurationProperty(String configurationAttributeKey) { if (configurationAttributeKey.startsWith(SECURE_PREFIX)) { String effectiveKey = configurationAttributeKey.substring(SECURE_PREFIX.length()); ConfigurationProperty originalConfigurationProperty = configurationAttributes.get(effectiveKey); if (originalConfigurationProperty == null) { return empty(); } String originalString = ((String) originalConfigurationProperty.getRawValue()); String encryptedValue = originalString.substring(originalConfigurationProperty.getKey().length() + 1, originalString.length() - algorithm.name().length() - mode.name().length() - 2); final String decryptedValue = resolveInnerProperties(securePropertyPlaceholderModule.convertPropertyValue(encryptedValue)); return of(new ConfigurationProperty() { @Override public Object getSource() { return originalConfigurationProperty.getSource(); } @Override public Object getRawValue() { return decryptedValue; } @Override public String getKey() { return originalConfigurationProperty.getKey(); } }); } else { return empty(); } } @Override public String getDescription() { ComponentLocation location = (ComponentLocation) getAnnotation(LOCATION_KEY); return format(" - file: %s, line number: %s", fileLocation, location.getFileName().orElse(UNKNOWN), location.getLineInFile().map(String::valueOf).orElse("unknown")); } ... } ``` このリゾルバーに固有のプレフィックス (​`PREFIX::`​ 形式) を定義します。プレフィックスにより、ユーザーは特定のリゾルバーに絞り込むことができます。これは、​`SECURE_PREFIX`​ で定義されるプレフィックスを使用して ​`SecureConfigurationPropertiesProvider`​ に実装されます。 設定では、プレフィックスを次のように使用する必要があります。 ```xml ``` `set-payload`​ の ​`value`​ 属性でどのようにセキュアなプロパティのリゾルバー (​`secure::`​ プレフィックス) が使用されているのかを確認してください。 ## [](#例-mule-sdk-モジュール)例: Mule SDK モジュール Studio 内でカスタム設定プロパティプロバイダーを有効にする設定要素を作成するには、Mule SDK モジュールを作成する必要があります。 カスタム設定プロパティリゾルバー拡張機能の実装を開始するためのすべてのインフラストラクチャコードが含まれる [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​をダウンロードまたはチェックアウトできます。 このサンプルプロジェクトは、Mule SDK モジュールです。詳細は、​[「Mule SDK の使用開始」](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​を参照してください。 ### [](#カスタムプロパティソースにアクセスするモジュールをカスタマイズする)カスタムプロパティソースにアクセスするモジュールをカスタマイズする Mule SDK モジュールをカスタマイズする手順は次のとおりです。 1. [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​を任意の IDE にインポートします。 2. `pom.xml`​ ファイルを開きます。 1. モジュールの GAV (​`groupId`​、​`artifactId`​、​`version`​) を定義します。 2. モジュールの ​`name`​ を定義します。 3. プロパティプロバイダーが必要とする最小 Mule バージョンを確認します。この例は、考えられるすべてのシナリオをカバーできる Mule 4.1.1 以降と互換性があります。​[「SDK バージョンの選択」](https://docs.mulesoft.com/mule-sdk/latest/choosing-version)​を参照してください。 3. コードのパッケージ名 (​`com.my.company.custom.provider.api`​) を変更します。 4. `resources/META-INF/services/org.mule.runtime.config.api.dsl.model.properties.ConfigurationPropertiesProviderFactory`​ を開き、以前に変更したパッケージ名に合わせてコンテンツを変更します。 5. `CustomConfigurationPropertiesExtension`​ クラスを開きます。 1. `EXTENSION_NAME`​ 定数をモジュールの名前に変更します。 2. `@Extension`​ アノテーションの ​`vendor`​ メソッドパラメーターを会社名に変更します。 3. 最後のセクションをカスタマイズして、モジュールの ​`config`​ 要素で設定できるパラメーターを定義します。 6. `CustomConfigurationPropertiesProviderFactory`​ クラスを開きます。 1. モジュールで解決する必要のある設定プロパティに合わせて、​`CUSTOM_PROPERTIES_PREFIX`​ 値をわかりやすいプレフィックスに変更します。 2. カスタムソースのプロパティをルックアップするようにクラス実装を変更します。 7. 新しいモジュール機能をカバーするために、より多くのテストケースで ​`test/munit`​ の MUnit テストケースを更新します。 モジュールの準備ができたら、​`mvn clean install`​ を使用してローカルにインストールし、Studio からモジュールにアクセスできるようにすることができます。 ## [](#mule-アプリケーションでカスタムプロパティプロバイダーを使用する)Mule アプリケーションでカスタムプロパティプロバイダーを使用する カスタムプロパティプロバイダーを使用する手順は、次のとおりです。 1. Studio でアプリケーションを作成します。 2. 新しいモジュールに連動関係を追加します。 1. `pom.xml`​ ファイルを開きます。 2. GAV を使用して、モジュールに配置する新しい連動関係を ​``​ タグ内に追加します。 3. `mule-plugin`​ は、Mule モジュールであるため忘れずに追加します。 4. 変更を保存します。 次に、アプリケーション XML ファイルを開き、​**\[Global Elements (グローバル要素)\]**​ タブで ​**\[Create (作成)\]**​ をクリックします。​**\[Connector Configuration (コネクタ設定)\]**​ には、次のようにカスタムモジュールの設定を選択するオプションがあります。 ![検索機能が含まれる、グローバル設定要素の種別を選択する画面](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/custom-configuration-provider.png) これで、新しいコンポーネントを設定し、モジュールで定義されたプレフィックスのプロパティを使用できるようになりました。 ## [](#カスタム設定プロパティプロバイダーの使用とコネクタの使用)カスタム設定プロパティプロバイダーの使用とコネクタの使用 静的プロパティの場合、実行時に変更されないため、プロパティプロバイダーのアプローチを使用します。実行時にプロパティが変更される可能性がある場合、そのいずれかの操作として値を提供できるコネクタを作成します。
Java 用 Mule SDK​ は、カスタム設定プロパティプロバイダーを実装するために使用されますが、​ConnectionProviders​ を使用して外部ソースに接続することはできません。これは、​ConnectionProviders​ が Mule Runtime によって管理されており、静的プロパティの解決後のフェーズで初期化されるためです。そのため、接続テストはカスタムプロパティプロバイダーではサポートされません。
# カスタム設定プロパティプロバイダー Mule SDK および Mule API を使用して、アプリケーションで設定プロパティ値を検出できるようにするカスタム設定プロパティプロバイダーを作成できます。 ## [](#mule-api)Mule API API のメインインターフェースは次のとおりです。 - `ConfigurationPropertiesProviderFactory` このインターフェースは、設定プロパティプロバイダーのカスタム実装を検出するために使用されます。Mule Runtime Engine (Mule) は、​`getSupportedComponentIdentifier()`​ メソッドによって提供される名前空間と名前に一致する設定要素を検出すると、​`createProvider(..)`​ メソッドで定義した設定を使用して ​`ConfigurationPropertiesProvider`​ を作成するようにファクトリーに要求します。Mule は、SPI を使用して ​`ConfigurationPropertiesProviderFactory`​ のインスタンスを検出します。 - `ConfigurationPropertiesProvider` Mule が設定プロパティを検出すると、このインターフェースを呼び出してプロパティの値を解決します。 ## [](#例-セキュア設定プロパティプロバイダー)例: セキュア設定プロパティプロバイダー セキュリティモジュールは、API を使用して ​`ConfigurationPropertiesProviderFactory`​ を実装します。 ```java import static org.mule.runtime.api.component.ComponentIdentifier.builder; import org.mule.runtime.properties.api.ConfigurationPropertiesProviderFactory; public class SecureConfigurationPropertiesProviderFactory implements ConfigurationPropertiesProviderFactory { public static final String EXTENSION_NAMESPACE = "secure-properties"; public static final String SECURE_CONFIGURATION_PROPERTIES_ELEMENT = "config"; public static final ComponentIdentifier SECURE_CONFIGURATION_PROPERTIES = builder().namespace(EXTENSION_NAMESPACE).name(SECURE_CONFIGURATION_PROPERTIES_ELEMENT).build(); ... @Override public ComponentIdentifier getSupportedComponentIdentifier() { return SECURE_CONFIGURATION_PROPERTIES; } @Override public SecureConfigurationPropertiesProvider createProvider(ConfigurationParameters parameters, ResourceProvider externalResourceProvider) { String file = parameters.getStringParameter("file"); .. String key = parameters.getStringParameter("key"); ... return new SecureConfigurationPropertiesProvider(..); } } ``` `getSupportedComponentIdentifier()`​ によって返される ​`ComponentIdentifier`​ は、次の設定コンポーネントに対して照合されます。 ```xml ``` Mule は、設定を処理するときに ​`secure-properties:config`​ コンポーネントを検出し、​`SecureConfigurationPropertiesProvider.createProvider(..)`​ メソッドを呼び出して、設定プロパティを解決するために使用される ​`SecureConfigurationPropertiesProvider`​ のインスタンスを作成します。 ```java public class SecureConfigurationPropertiesProvider extends DefaultConfigurationPropertiesProvider { private final static String SECURE_PREFIX = "secure::"; private final static Pattern SECURE_PATTERN = Pattern.compile("\\$\\{" + SECURE_PREFIX + "[^}]*}"); private final EncryptionAlgorithm algorithm; private final EncryptionMode mode; private final boolean fileLevelEncryption; private final SecurePropertyPlaceholderModule securePropertyPlaceholderModule = new SecurePropertyPlaceholderModule(); public SecureConfigurationPropertiesProvider(ResourceProvider resourceProvider, String file, EncryptionAlgorithm algorithm, String key, EncryptionMode mode, String encoding, boolean fileLevelEncryption) { ... } @Override public Optional getConfigurationProperty(String configurationAttributeKey) { if (configurationAttributeKey.startsWith(SECURE_PREFIX)) { String effectiveKey = configurationAttributeKey.substring(SECURE_PREFIX.length()); ConfigurationProperty originalConfigurationProperty = configurationAttributes.get(effectiveKey); if (originalConfigurationProperty == null) { return empty(); } String originalString = ((String) originalConfigurationProperty.getRawValue()); String encryptedValue = originalString.substring(originalConfigurationProperty.getKey().length() + 1, originalString.length() - algorithm.name().length() - mode.name().length() - 2); final String decryptedValue = resolveInnerProperties(securePropertyPlaceholderModule.convertPropertyValue(encryptedValue)); return of(new ConfigurationProperty() { @Override public Object getSource() { return originalConfigurationProperty.getSource(); } @Override public Object getRawValue() { return decryptedValue; } @Override public String getKey() { return originalConfigurationProperty.getKey(); } }); } else { return empty(); } } @Override public String getDescription() { ComponentLocation location = (ComponentLocation) getAnnotation(LOCATION_KEY); return format(" - file: %s, line number: %s", fileLocation, location.getFileName().orElse(UNKNOWN), location.getLineInFile().map(String::valueOf).orElse("unknown")); } ... } ``` このリゾルバーに固有のプレフィックス (​`PREFIX::`​ 形式) を定義します。プレフィックスにより、ユーザーは特定のリゾルバーに絞り込むことができます。これは、​`SECURE_PREFIX`​ で定義されるプレフィックスを使用して ​`SecureConfigurationPropertiesProvider`​ に実装されます。 設定では、プレフィックスを次のように使用する必要があります。 ```xml ``` `set-payload`​ の ​`value`​ 属性でどのようにセキュアなプロパティのリゾルバー (​`secure::`​ プレフィックス) が使用されているのかを確認してください。 ## [](#例-mule-sdk-モジュール)例: Mule SDK モジュール Studio 内でカスタム設定プロパティプロバイダーを有効にする設定要素を作成するには、Mule SDK モジュールを作成する必要があります。 カスタム設定プロパティリゾルバー拡張機能の実装を開始するためのすべてのインフラストラクチャコードが含まれる [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​をダウンロードまたはチェックアウトできます。 このサンプルプロジェクトは、Mule SDK モジュールです。詳細は、​[「Mule SDK の使用開始」](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​を参照してください。 ### [](#カスタムプロパティソースにアクセスするモジュールをカスタマイズする)カスタムプロパティソースにアクセスするモジュールをカスタマイズする Mule SDK モジュールをカスタマイズする手順は次のとおりです。 1. [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​を任意の IDE にインポートします。 2. `pom.xml`​ ファイルを開きます。 1. モジュールの GAV (​`groupId`​、​`artifactId`​、​`version`​) を定義します。 2. モジュールの ​`name`​ を定義します。 3. プロパティプロバイダーが必要とする最小 Mule バージョンを確認します。この例は、考えられるすべてのシナリオをカバーできる Mule 4.1.1 以降と互換性があります。​[「SDK バージョンの選択」](https://docs.mulesoft.com/mule-sdk/latest/choosing-version)​を参照してください。 3. コードのパッケージ名 (​`com.my.company.custom.provider.api`​) を変更します。 4. `resources/META-INF/services/org.mule.runtime.config.api.dsl.model.properties.ConfigurationPropertiesProviderFactory`​ を開き、以前に変更したパッケージ名に合わせてコンテンツを変更します。 5. `CustomConfigurationPropertiesExtension`​ クラスを開きます。 1. `EXTENSION_NAME`​ 定数をモジュールの名前に変更します。 2. `@Extension`​ アノテーションの ​`vendor`​ メソッドパラメーターを会社名に変更します。 3. 最後のセクションをカスタマイズして、モジュールの ​`config`​ 要素で設定できるパラメーターを定義します。 6. `CustomConfigurationPropertiesProviderFactory`​ クラスを開きます。 1. モジュールで解決する必要のある設定プロパティに合わせて、​`CUSTOM_PROPERTIES_PREFIX`​ 値をわかりやすいプレフィックスに変更します。 2. カスタムソースのプロパティをルックアップするようにクラス実装を変更します。 7. 新しいモジュール機能をカバーするために、より多くのテストケースで ​`test/munit`​ の MUnit テストケースを更新します。 モジュールの準備ができたら、​`mvn clean install`​ を使用してローカルにインストールし、Studio からモジュールにアクセスできるようにすることができます。 ## [](#mule-アプリケーションでカスタムプロパティプロバイダーを使用する)Mule アプリケーションでカスタムプロパティプロバイダーを使用する カスタムプロパティプロバイダーを使用する手順は、次のとおりです。 1. Studio でアプリケーションを作成します。 2. 新しいモジュールに連動関係を追加します。 1. `pom.xml`​ ファイルを開きます。 2. GAV を使用して、モジュールに配置する新しい連動関係を ​``​ タグ内に追加します。 3. `mule-plugin`​ は、Mule モジュールであるため忘れずに追加します。 4. 変更を保存します。 次に、アプリケーション XML ファイルを開き、​**\[Global Elements (グローバル要素)\]**​ タブで ​**\[Create (作成)\]**​ をクリックします。​**\[Connector Configuration (コネクタ設定)\]**​ には、次のようにカスタムモジュールの設定を選択するオプションがあります。 ![検索機能が含まれる、グローバル設定要素の種別を選択する画面](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/custom-configuration-provider.png) これで、新しいコンポーネントを設定し、モジュールで定義されたプレフィックスのプロパティを使用できるようになりました。 ## [](#カスタム設定プロパティプロバイダーの使用とコネクタの使用)カスタム設定プロパティプロバイダーの使用とコネクタの使用 静的プロパティの場合、実行時に変更されないため、プロパティプロバイダーのアプローチを使用します。実行時にプロパティが変更される可能性がある場合、そのいずれかの操作として値を提供できるコネクタを作成します。
Java 用 Mule SDK​ は、カスタム設定プロパティプロバイダーを実装するために使用されますが、​ConnectionProviders​ を使用して外部ソースに接続することはできません。これは、​ConnectionProviders​ が Mule Runtime によって管理されており、静的プロパティの解決後のフェーズで初期化されるためです。そのため、接続テストはカスタムプロパティプロバイダーではサポートされません。
# カスタム設定プロパティプロバイダー Mule SDK および Mule API を使用して、アプリケーションで設定プロパティ値を検出できるようにするカスタム設定プロパティプロバイダーを作成できます。 ## [](#mule-api)Mule API API のメインインターフェースは次のとおりです。 - `ConfigurationPropertiesProviderFactory` このインターフェースは、設定プロパティプロバイダーのカスタム実装を検出するために使用されます。Mule Runtime Engine (Mule) は、​`getSupportedComponentIdentifier()`​ メソッドによって提供される名前空間と名前に一致する設定要素を検出すると、​`createProvider(..)`​ メソッドで定義した設定を使用して ​`ConfigurationPropertiesProvider`​ を作成するようにファクトリーに要求します。Mule は、SPI を使用して ​`ConfigurationPropertiesProviderFactory`​ のインスタンスを検出します。 - `ConfigurationPropertiesProvider` Mule が設定プロパティを検出すると、このインターフェースを呼び出してプロパティの値を解決します。 ## [](#例-セキュア設定プロパティプロバイダー)例: セキュア設定プロパティプロバイダー セキュリティモジュールは、API を使用して ​`ConfigurationPropertiesProviderFactory`​ を実装します。 ```java import static org.mule.runtime.api.component.ComponentIdentifier.builder; import org.mule.runtime.properties.api.ConfigurationPropertiesProviderFactory; public class SecureConfigurationPropertiesProviderFactory implements ConfigurationPropertiesProviderFactory { public static final String EXTENSION_NAMESPACE = "secure-properties"; public static final String SECURE_CONFIGURATION_PROPERTIES_ELEMENT = "config"; public static final ComponentIdentifier SECURE_CONFIGURATION_PROPERTIES = builder().namespace(EXTENSION_NAMESPACE).name(SECURE_CONFIGURATION_PROPERTIES_ELEMENT).build(); ... @Override public ComponentIdentifier getSupportedComponentIdentifier() { return SECURE_CONFIGURATION_PROPERTIES; } @Override public SecureConfigurationPropertiesProvider createProvider(ConfigurationParameters parameters, ResourceProvider externalResourceProvider) { String file = parameters.getStringParameter("file"); .. String key = parameters.getStringParameter("key"); ... return new SecureConfigurationPropertiesProvider(..); } } ``` `getSupportedComponentIdentifier()`​ によって返される ​`ComponentIdentifier`​ は、次の設定コンポーネントに対して照合されます。 ```xml ``` Mule は、設定を処理するときに ​`secure-properties:config`​ コンポーネントを検出し、​`SecureConfigurationPropertiesProvider.createProvider(..)`​ メソッドを呼び出して、設定プロパティを解決するために使用される ​`SecureConfigurationPropertiesProvider`​ のインスタンスを作成します。 ```java public class SecureConfigurationPropertiesProvider extends DefaultConfigurationPropertiesProvider { private final static String SECURE_PREFIX = "secure::"; private final static Pattern SECURE_PATTERN = Pattern.compile("\\$\\{" + SECURE_PREFIX + "[^}]*}"); private final EncryptionAlgorithm algorithm; private final EncryptionMode mode; private final boolean fileLevelEncryption; private final SecurePropertyPlaceholderModule securePropertyPlaceholderModule = new SecurePropertyPlaceholderModule(); public SecureConfigurationPropertiesProvider(ResourceProvider resourceProvider, String file, EncryptionAlgorithm algorithm, String key, EncryptionMode mode, String encoding, boolean fileLevelEncryption) { ... } @Override public Optional getConfigurationProperty(String configurationAttributeKey) { if (configurationAttributeKey.startsWith(SECURE_PREFIX)) { String effectiveKey = configurationAttributeKey.substring(SECURE_PREFIX.length()); ConfigurationProperty originalConfigurationProperty = configurationAttributes.get(effectiveKey); if (originalConfigurationProperty == null) { return empty(); } String originalString = ((String) originalConfigurationProperty.getRawValue()); String encryptedValue = originalString.substring(originalConfigurationProperty.getKey().length() + 1, originalString.length() - algorithm.name().length() - mode.name().length() - 2); final String decryptedValue = resolveInnerProperties(securePropertyPlaceholderModule.convertPropertyValue(encryptedValue)); return of(new ConfigurationProperty() { @Override public Object getSource() { return originalConfigurationProperty.getSource(); } @Override public Object getRawValue() { return decryptedValue; } @Override public String getKey() { return originalConfigurationProperty.getKey(); } }); } else { return empty(); } } @Override public String getDescription() { ComponentLocation location = (ComponentLocation) getAnnotation(LOCATION_KEY); return format(" - file: %s, line number: %s", fileLocation, location.getFileName().orElse(UNKNOWN), location.getLineInFile().map(String::valueOf).orElse("unknown")); } ... } ``` このリゾルバーに固有のプレフィックス (​`PREFIX::`​ 形式) を定義します。プレフィックスにより、ユーザーは特定のリゾルバーに絞り込むことができます。これは、​`SECURE_PREFIX`​ で定義されるプレフィックスを使用して ​`SecureConfigurationPropertiesProvider`​ に実装されます。 設定では、プレフィックスを次のように使用する必要があります。 ```xml ``` `set-payload`​ の ​`value`​ 属性でどのようにセキュアなプロパティのリゾルバー (​`secure::`​ プレフィックス) が使用されているのかを確認してください。 ## [](#例-mule-sdk-モジュール)例: Mule SDK モジュール Studio 内でカスタム設定プロパティプロバイダーを有効にする設定要素を作成するには、Mule SDK モジュールを作成する必要があります。 カスタム設定プロパティリゾルバー拡張機能の実装を開始するためのすべてのインフラストラクチャコードが含まれる [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​をダウンロードまたはチェックアウトできます。 このサンプルプロジェクトは、Mule SDK モジュールです。詳細は、​[「Mule SDK の使用開始」](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​を参照してください。 ### [](#カスタムプロパティソースにアクセスするモジュールをカスタマイズする)カスタムプロパティソースにアクセスするモジュールをカスタマイズする Mule SDK モジュールをカスタマイズする手順は次のとおりです。 1. [サンプルプロジェクト](https://github.com/mulesoft/mule-custom-properties-providers-module-example)​を任意の IDE にインポートします。 2. `pom.xml`​ ファイルを開きます。 1. モジュールの GAV (​`groupId`​、​`artifactId`​、​`version`​) を定義します。 2. モジュールの ​`name`​ を定義します。 3. プロパティプロバイダーが必要とする最小 Mule バージョンを確認します。この例は、考えられるすべてのシナリオをカバーできる Mule 4.1.1 以降と互換性があります。​[「SDK バージョンの選択」](https://docs.mulesoft.com/mule-sdk/latest/choosing-version)​を参照してください。 3. コードのパッケージ名 (​`com.my.company.custom.provider.api`​) を変更します。 4. `resources/META-INF/services/org.mule.runtime.config.api.dsl.model.properties.ConfigurationPropertiesProviderFactory`​ を開き、以前に変更したパッケージ名に合わせてコンテンツを変更します。 5. `CustomConfigurationPropertiesExtension`​ クラスを開きます。 1. `EXTENSION_NAME`​ 定数をモジュールの名前に変更します。 2. `@Extension`​ アノテーションの ​`vendor`​ メソッドパラメーターを会社名に変更します。 3. 最後のセクションをカスタマイズして、モジュールの ​`config`​ 要素で設定できるパラメーターを定義します。 6. `CustomConfigurationPropertiesProviderFactory`​ クラスを開きます。 1. モジュールで解決する必要のある設定プロパティに合わせて、​`CUSTOM_PROPERTIES_PREFIX`​ 値をわかりやすいプレフィックスに変更します。 2. カスタムソースのプロパティをルックアップするようにクラス実装を変更します。 7. 新しいモジュール機能をカバーするために、より多くのテストケースで ​`test/munit`​ の MUnit テストケースを更新します。 モジュールの準備ができたら、​`mvn clean install`​ を使用してローカルにインストールし、Studio からモジュールにアクセスできるようにすることができます。 ## [](#mule-アプリケーションでカスタムプロパティプロバイダーを使用する)Mule アプリケーションでカスタムプロパティプロバイダーを使用する カスタムプロパティプロバイダーを使用する手順は、次のとおりです。 1. Studio でアプリケーションを作成します。 2. 新しいモジュールに連動関係を追加します。 1. `pom.xml`​ ファイルを開きます。 2. GAV を使用して、モジュールに配置する新しい連動関係を ​``​ タグ内に追加します。 3. `mule-plugin`​ は、Mule モジュールであるため忘れずに追加します。 4. 変更を保存します。 次に、アプリケーション XML ファイルを開き、​**\[Global Elements (グローバル要素)\]**​ タブで ​**\[Create (作成)\]**​ をクリックします。​**\[Connector Configuration (コネクタ設定)\]**​ には、次のようにカスタムモジュールの設定を選択するオプションがあります。 ![検索機能が含まれる、グローバル設定要素の種別を選択する画面](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/custom-configuration-provider.png) これで、新しいコンポーネントを設定し、モジュールで定義されたプレフィックスのプロパティを使用できるようになりました。 ## [](#カスタム設定プロパティプロバイダーの使用とコネクタの使用)カスタム設定プロパティプロバイダーの使用とコネクタの使用 静的プロパティの場合、実行時に変更されないため、プロパティプロバイダーのアプローチを使用します。実行時にプロパティが変更される可能性がある場合、そのいずれかの操作として値を提供できるコネクタを作成します。
Java 用 Mule SDK​ は、カスタム設定プロパティプロバイダーを実装するために使用されますが、​ConnectionProviders​ を使用して外部ソースに接続することはできません。これは、​ConnectionProviders​ が Mule Runtime によって管理されており、静的プロパティの解決後のフェーズで初期化されるためです。そのため、接続テストはカスタムプロパティプロバイダーではサポートされません。
# キーストアとトラストストアを使用した TLS の設定 TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。TLS には、認証キーをエクスチェンジし、データを暗号化し、メッセージの整合性を保証するための多くの方法があります。このトピックでは、Mule が TLS をどのようにサポートするか、そして Mule アプリケーションで TLS をどのように設定するかについて説明します。 ## [](#tls_compatibility)TLS 互換性マトリックス TLS との互換性は、Mule デプロイメントモデルと TLS バージョンによって異なります。
TLS バージョン オンプレミス CloudHub Anypoint Runtime Fabric

1.3

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされますが、デフォルトでは​有効化されていません

サポート対象外

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされ、有効化されます

1.2

すべてのデプロイメントモデルでサポートされ、有効化されます

1.1

すべてのデプロイメントモデルでサポートされ、有効化されます
## [](#tlscontext-要素)tls:context 要素 `tls:context`​ 要素は、TLS をサポートするすべてのコネクタで使用します。たとえば、TLS は HTTP (サーバーとクライアント)、FTPS (クライアント)、メール (クライアント)、またはソケット (クライアント) などのコネクタで設定できます。

コネクタで TLS がサポートされる場合、Studio には次のいずれかが表示されます。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[TLS/SSL]​ タブ。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[General (一般)]​ タブの ​[TLS Configuration (TLS 設定)]​ 項目。
## [](#tls-対応のサーバーとクライアント)TLS 対応のサーバーとクライアント TLS 対応のサーバーには、非公開キーと公開証明書が含まれます。 - 非公開キーはサーバーの外部には送信されません。 - 公開証明書は TLS 経由で公開されます。 TLS 対応クライアントは、自身が保管する信頼済みの証明書を使用して公開証明書を検証することで、サーバーが信頼できるかどうかを確認します。 Mule 4 で TLS 通信セキュリティを使用するには、証明書と非公開キーをキーストアファイルにインポートします。トラストストアファイルは、慣例として信頼済みのサーバー公開証明書のみが格納されるキーストアでもあります。 標準 JRE 配布には、デフォルトの Java トラストストアはありますが、デフォルトの Java キーストアはありません。自身のキーストアを TLS コンテキストに追加してください。すでにクライアントアプリケーション用に企業の証明書があれば、新たに作成する必要はありません。これらの証明書の多くは JRE トラストストアでも使用できるため、その場合は TLS コンテキストでのセットアップは不要です。 証明書は、よく知られた証明書機関 (CA) が生成するか、またはユーザーが外部承認なしでローカルに証明書 (自己署名証明書) を生成することができます。トラストストアには、サーバーから提供された証明書をクライアントが検証するために使用する信頼済みの CA があります。 ## [](#キーストアとトラストストア)キーストアとトラストストア Mule 設定の ​`tls:trust-store`​ 要素と ​`tls:key-store`​ 要素は、特定の証明書とキーを参照しますが、​`tls:trust-store`​ の値を指定しないと、Mule はデフォルトの Java トラストストアを参照します。Java を更新するとデフォルトのトラストストアも更新されますので、よく知られた CA 証明書を最新に保つために、定期的な更新をお勧めします。 トラストストアとキーストアは、クライアントとサーバーのどちらで使用するかによってコンテンツが異なります。 - サーバー用: トラストストアには信頼済みのクライアントの証明書、キーストアにはサーバーの非公開キーと公開キーが格納されています。 - クライアント用: トラストストアには信頼済みのサーバーの証明書、キーストアにはクライアントの非公開キーと公開キーが格納されています。 キーストアとトラストストアの両方を追加すると、相互認証とも呼ばれる両方向の TLS 認証を実装できます。 キーストアには 1 つまたは 2 つのパスワードがあります。 - `password`​ はキーストアファイル全体にアクセスします。 - `keyPassword`​ は、キーストアにあるサーバーの非公開キーにアクセスします。 ## [](#クライアントの設定)クライアントの設定 `tls:context`​ に空白のトラストストアが定義されている場合は、JVM のデフォルト値 (通常は、すべての主要証明機関の証明書が格納されたトラストストア) が使用されます。次のシナリオを考えてみます。 - トラストストアがインラインで定義されている場合: - トラストストアがグローバル要素を使用して定義されている場合: クライアントが接続しようとしているサーバーからの証明書を必要とする場合は、​`tls:trust-store`​ 要素を追加します。​`path`​ には、信頼済みのサーバーの証明書が格納されているトラストストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する場合は、​`tls:key-store`​ 要素に、クライアントの非公開/公開キーが格納されたキーストアファイルの場所が設定された ​`path`​ を組み合わせる必要があります。 設定の手順は、​[「Mule 4 での TLS の設定」](#configure-tls-in-mule-4)​を参照してください。 ## [](#サーバーの設定)サーバーの設定 `tls:context`​ には、HTTPS などのセキュアな接続を使用して要求をリッスンする ​`tls:key-store`​ 要素を指定する必要があります。​`path`​ には、サーバーの非公開/公開キーが格納されているキーストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する必要がある場合は、​`tls:trust-store`​ 要素を追加し、信頼済みのクライアントの証明書が格納されたトラストストアファイルの場所を ​`path`​ に設定します。 Mule は、多くのキーストア種別をサポートします。例: - `JCEKS` - `PKCS12` - `JKS` キーストア種別は JRE に指定します。 Mule アプリケーション用に TLS を完全に設定するための手順は次の通りです。 1. Oracle の Java keytool を使用して​[キーストアとトラストストアを生成します](https://docs.mulesoft.com/jp/mule-runtime/4.3/%3C#Generate a Keystore>)​。 2. [Mule でクライアントまたはサーバー用の TLS をグローバルに設定します](https://docs.mulesoft.com/jp/mule-runtime/4.3/%3C#Configure TLS in Mule 4>)​。 3. [省略可能: プロトコルと暗号化スイートを指定します](https://docs.mulesoft.com/jp/mule-runtime/4.3/%3C#Optional: Specify Protocols and Cipher Suites>)​。 ## [](#キーストアの生成)キーストアの生成 標準 JDK 配布には、デフォルトではキーストアが含まれていないため、​`keytool`​ を使用してキーストアおよび証明書を生成します。生成したキーストアには、非公開キーと公開証明書が格納されます。この証明書は自己署名であるため、クライアントと公開証明書を共有するまでは、クライアントには信頼されません。 ### [](#要件)要件 Java 8 を使用してキーストアを生成します。別の JDK バージョンを使用すると非互換のキーストアが生成され、Mule アプリケーションがキーストアを読み込もうとすると無効なキーストア形式ランタイムエラーが発生します。 ### [](#キーストアを生成する)キーストアを生成する 次の手順に従い、キーストアを生成して自己署名証明書をエクスポートします。 1. サーバーの証明書を公開するキーストアを生成します。 たとえば、次のコマンドを実行します。 keytool -genkey -keyalg RSA -alias -keystore .jks ``​ は選択した一意の別名に置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 必要に応じて、​`-keyalg RSA`​ の代わりに ​`-keyalg EC`​ を指定して、暗号化アルゴリズムを ECDSA に設定できます。
暗号化アルゴリズムを指定しない場合、ツールではデフォルトで DSA が使用されます。DSA には TLS 1.2 との互換性がないため、Mule アプリケーションで HTTPS 要求を受信すると SSL ハンドシェイクが失敗します。
2. ツールの要求メッセージに応答します。応答例: Enter keystore password: mule123 Re-enter new password: mule123 3. 入力画面に対して他の値を入力します。目的の値を入力します。応答例: What is your first and last name? \[Unknown\]: max What is the name of your organizational unit? \[Unknown\]: MuleSoft What is the name of your organization? \[Unknown\]: MuleSoft Inc What is the name of your City or Locality? \[Unknown\]: San Francisco What is the name of your State or Province? \[Unknown\]: CA What is the two-letter country code for this unit? \[Unknown\]: 01 4. 次の入力画面に対して ​`yes`​ と入力します。 Is CN=max, OU=MuleSoft, O=MuleSoft Inc, L=San Francisco, ST=CA, C=01 correct? \[no\]: yes 5. 次の入力画面に応答します。たとえば、RETURN キーを押して同じパスワードを使用します。 Enter key password for (RETURN if same as keystore password): 6. 公開キーを認証する自己署名証明書をエクスポートするために次のコマンドを入力します。 keytool -export -alias -keystore .jks -file .cer ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書に使用する名前に置き換えます。 7. 証明書に関連付けられたキーストア用にセットアップしたパスワードを入力します。 Enter keystore password: mule123 ### [](#認証機関による署名を要求する)認証機関による署名を要求する 認証機関 (CA) から証明書への署名を受けるには、次の手順に従います。 1. 証明書を標準 CSR 形式でエクスポートします。そのためには、次のコマンドを実行できます。 keytool -certreq -keystore .jks -alias -file .csr ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書署名要求ファイルに使用する名前に置き換えます。 2. 前のステップで生成された CSR ファイルを認証機関に送信し、手順に従って署名を取得します。 CA の署名を取得したら、次のコマンドを使用して署名済みの証明書ファイルをインポートできます。 keytool -import -keystore .jks -alias -file ``​ は目的の新しい値に置き換えます。定義した別名を既存のキーにリンクさせないでください。リンクさせるとプロセスが失敗します。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は認証機関から受信した署名済み証明書の名前に置き換えます。 ## [](#トラストストアの生成)トラストストアの生成 標準 JRE 配布には、いくつかの主要証明機関 (CA) の証明書が格納されたデフォルトのトラストストアがあり、デフォルトで tls:trust-store 要素で使用されますが、より強力なセキュリティが必要な場合や、自己署名証明書を使用する場合には、新たにトラストストアを作成できます。 トラストストアは Oracle Java keytool で作成します。 クライアントは、信頼の連鎖 (chain of trust) が確立されることでサーバーを信頼します。信頼の連鎖は、クライアントとサーバーの間で直接 (クライアントのトラストストアにサーバーの証明書が格納されることで) 確立されるか、またはクライアントのトラストストアに証明書が格納されている署名 CA 経由で確立されます。信頼の連鎖が確立されていないと、接続が失敗します。自己署名証明書を使用する場合は、トラストストアを定義する必要があります。 ## [](#mule-4-での-tls-の設定)Mule 4 での TLS の設定 Mule アプリケーションで TLS を有効にするには、次の 3 つの方法のいずれかを使用して Mule XML 設定ファイルで ​`tls:context`​ 要素を設定します。 - [XML ファイルを直接編集する。](https://docs.mulesoft.com/jp/mule-runtime/4.3/%3C#Edit XML to Configure TLS>) - [Anypoint Studio 7 を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.3/%3C#Use Anypoint Studio to Configure TLS>) - [Design Center を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.3/%3C#Use Design Center to Configure TLS>) どの方法を使用する場合でも、​[\[Edit XML to Configure TLS\]](<#Edit XML to Configure TLS>)​の情報を参照して、​`tls:context`​ の属性がどのように機能するのかを理解しておくことをお勧めします。 ### [](#xml-の編集による-tls-の設定)XML の編集による TLS の設定 `tls:context`​ 要素は、Mule アプリケーションで TLS 通信を定義します。特別な要件がない限り、TLS はグローバルに設定して、HTTPS のリスンや送信といった特定の用途に適用してください。 #### [](#tls-要素のグローバル設定)TLS 要素のグローバル設定 `tls:context`​ 要素は、クライアント側とサーバー側の両方から使用できる TLS の設定を定義します。この要素は、他のモジュールの設定オブジェクトから参照したり、いずれかのオブジェクトのネストされた要素として定義したりすることができます。 ネストされた要素を最低 1 つは含めます (key-store と trust-store)。 ```xml ``` #### [](#tls-context-要素の省略可能な属性)`tls-context`​ 要素の省略可能な属性 プロトコルと暗号化スイートを指定して有効にすることができます (省略可能)。 - `enabledProtocols`​: グローバル TLS 設定のプロトコル - `enabledCipherSuites`​: グローバル TLS 設定の暗号化スイート [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.3/%3C#Optional: Specify Protocols and Cipher Suites>)​で説明するように、これらの値は、グローバル TLS 設定で何も指定されていないか、またはこれらの値がグローバル TLS 設定で有効化されている場合に使用されます。 #### [](#trust-store-要素の属性)`trust-store`​ 要素の属性 `path`​ を指定する場合は、​`password`​ 属性が必要です。そうでない場合は省略可能です。 - `path`​: トラストストアが格納されているファイルへのパス - `type`​: トラストストアの種別。デフォルトは JKS - `password`​: トラストストアのパスワード (​`path`​ を指定した場合は必須) - `algorithm`​: トラストストアが使用するアルゴリズム。デフォルトは ​`SunX509` - `insecure`​: トラストストアを検証するかどうかを決定するブール値。​`true`​ に設定すると検証は行われません。デフォルト値は ​`false`​ です。
insecure​ を ​true​ に設定すると、接続が攻撃に対して脆弱になります。この設定は、プロトタイプ開発やテストにおいてのみ使用してください。本番環境では絶対に使用しないでください。
#### [](#key-store-要素の属性)`key-store`​ 要素の属性 `path`​ 以外の属性は省略可能です。 - `path`​: キーストアが格納されているファイルへのパス (必須) - `type`​: キーストアの種別 (デフォルトは JKS) - `password`​: キーストアのパスワード - `keyPassword`​: キーマネージャーのパスワード。キーストア内の非公開キーのパスワードです - `algorithm`​: キーストアで使用するアルゴリズム。デフォルト値は ​`SunX509`​ です。 ### [](#design-center-を使用して-tls-を設定する)Design Center を使用して TLS を設定する Design Center を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Design Center にログインします。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[Configuration (設定)\] タブで ​**\[Edit (編集)\]**​ をクリックします。 5. \[TLS\] タブで、上記の TLS 設定項目を設定します。 6. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.3/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ### [](#anypoint-studio-を使用して-tls-を設定する)Anypoint Studio を使用して TLS を設定する Anypoint Studio (Studio) を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Studio Center を開きます。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[General (一般)\] タブで、既存の設定を選択するか、または新しい設定を作成します。 5. \[HTTP Listener config (HTTP リスナーの設定)\] ダイアログで、\[TLS\] タブを選択します。 6. \[TLS\] タブの \[TLS Configuration type (TLS 設定種別)\] で ​**\[Edit Inline (インライン編集)\]**​ を選択して、値を入力します。 7. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.3/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、\[Advanced (詳細)\] セクションの ​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ## [](#省略可能-プロトコルと暗号化スイートの指定)省略可能: プロトコルと暗号化スイートの指定 2 つのシステムの間で TLS 通信が行われると、使用するプロトコルと暗号化スイートがネゴシエーションによって決定します。必要に応じて、管理者が使用するプロトコルと暗号化スイートを指定して、アプリケーション開発者がそれらを ​`tls:context`​ で指定することができます。
使用するプロトコルと暗号化スイートは、Mule Runtime と各アプリケーションで有効化しておく必要があります。プロトコルと暗号化スイートが両方の場所で有効化されていないと、Java 環境のデフォルトのプロトコルと暗号化スイートが使用されます。
Mule Runtime でプロトコルと暗号化スイートを設定する手順は次の通りです。 1. Mule 管理者は、​`$MULE_HOME`​ の下にある ​`/conf`​ ディレクトリを編集します。​`$MULE_HOME`​ は、Mule がインストールされているディレクトリを参照します。例: `/opt/mule-4.0`​。暗号化スイートとプロトコルを指定するための適切なファイルを選択します。 - `tls-default.conf`​ は、Mule が Federal Information Processing Standards (FIPS) セキュリティモードで動作するように設定されていない場合に使用します。 - `tls-fips140-2.conf`​ Mule が FIPS セキュリティモードで動作するように設定されている場合に使用します。 関連するファイルを開き、リストの項目をコメントまたはコメント解除することで、使用する暗号化スイートと TLS プロトコルを手動で設定します。これらのファイルを編集しないと、設定されているセキュリティマネージャーが Mule アプリケーション用の暗号化スイートとプロトコルを選択します。 2. これらの設定ファイルで管理者が設定したプロトコルと暗号化スイートのリストは、アプリケーション開発者がそれぞれの ​`tls:context`​ 要素で指定する内容によってローカルに制約できます。アプリケーション開発者は、​`tls:context`​ 要素の設定値またはデフォルト値のサブセットを TLS で使用するように指定します。プロトコルと暗号化スイートは、​`tls:context`​ 要素の ​`enabledProtocols`​ と ​`enabledCipherSuites`​ で指定します。 `tls:context`​ 要素では、Mule グローバル TLS 設定ファイルで指定されているプロトコルまたは暗号化スイート、またはデフォルトのみを参照できます。​`tls:context`​ で、Mule アプリケーション用の ​`enabledProtocols`​ と ​`enabledCipherSuite`​ を ​`default`​ に設定します。これらの値を設定すると、TLS は次のプロトコルと暗号化スイートを使用します。 - グローバル TLS 設定が存在する場合は、指定されているプロトコルと暗号化スイート - グローバル TLS 設定が存在しない場合は、Java 環境のデフォルト 暗号化スイート名は長くなることがあり、XML コードが読みづらくなります。読みやすくするためには、これらの名前を Mule プロジェクトの外部プロパティファイルに格納します。そして、プロパティを参照します。例: ```xml ``` ## [](#tls-の設定例)TLS の設定例 TLS は、クライアントまたはサーバー用の Mule XML 設定ファイルでセットアップできます。 ### [](#例-クライアント用の-tls-の設定)例: クライアント用の TLS の設定 次の例では、トラストストアをセットアップすることで FTPS クライアントのセキュリティを確保しています。 ```xml ``` ### [](#例-サーバー用の-tls-の設定)例: サーバー用の TLS の設定 次の例では、キーストアをセットアップすることで HTTP リスナーのセキュリティを確保しています。 ```xml ``` ### [](#例-両方向認証用の-tls-の設定)例: 両方向認証用の TLS の設定 次の例では、HTTP リスナー用に両方向認証 (相互認証) をセットアップしています。 ```xml ``` ### [](#例-tls-検証の無効化)例: TLS 検証の無効化 次の例では、​`insecure`​ プロパティを使用して、プロトタイプ作成と開発で検証を無効化しています。
insecure​ は、本番環境では使用しないでください。
```xml ``` ### [](#例-暗号化スイートとプロトコルの制約の追加)例: 暗号化スイートとプロトコルの制約の追加 次の例では、Mule 管理者がグローバル TLS 設定で何も指定していないか、または暗号化スイートとプロトコルをここで指定できるように有効化してあるという前提で、アプリケーションでプロトコルと暗号化スイートを有効化しています。 ```xml ``` ## [](#関連情報)関連情報 - [Oracle のセキュリティ](http://docs.oracle.com/javase/8/docs/technotes/tools/#security) - [Oracle Java keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) # キーストアとトラストストアを使用した TLS の設定 TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。TLS には、認証キーをエクスチェンジし、データを暗号化し、メッセージの整合性を保証するための多くの方法があります。このトピックでは、Mule が TLS をどのようにサポートするか、そして Mule アプリケーションで TLS をどのように設定するかについて説明します。 ## [](#tls_compatibility)TLS 互換性マトリックス TLS との互換性は、Mule デプロイメントモデルと TLS バージョンによって異なります。
TLS バージョン オンプレミス CloudHub Anypoint Runtime Fabric

1.3

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされますが、デフォルトでは​有効化されていません

このデプロイメントモデルでホストされている Mule アプリケーションでサポートされます

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされ、有効化されます

1.2

すべてのデプロイメントモデルでサポートされ、有効化されます

1.1

すべてのデプロイメントモデルでサポートされ、有効化されます
## [](#tlscontext-要素)tls:context 要素 `tls:context`​ 要素は、TLS をサポートするすべてのコネクタで使用します。たとえば、TLS は HTTP (サーバーとクライアント)、FTPS (クライアント)、メール (クライアント)、またはソケット (クライアント) などのコネクタで設定できます。

コネクタで TLS がサポートされる場合、Studio には次のいずれかが表示されます。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[TLS/SSL]​ タブ。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[General (一般)]​ タブの ​[TLS Configuration (TLS 設定)]​ 項目。
## [](#tls-対応のサーバーとクライアント)TLS 対応のサーバーとクライアント TLS 対応のサーバーには、非公開キーと公開証明書が含まれます。 - 非公開キーはサーバーの外部には送信されません。 - 公開証明書は TLS 経由で公開されます。 TLS 対応クライアントは、自身が保管する信頼済みの証明書を使用して公開証明書を検証することで、サーバーが信頼できるかどうかを確認します。 Mule 4 で TLS 通信セキュリティを使用するには、証明書と非公開キーをキーストアファイルにインポートします。トラストストアファイルは、慣例として信頼済みのサーバー公開証明書のみが格納されるキーストアでもあります。 標準 JRE 配布には、デフォルトの Java トラストストアはありますが、デフォルトの Java キーストアはありません。自身のキーストアを TLS コンテキストに追加してください。すでにクライアントアプリケーション用に企業の証明書があれば、新たに作成する必要はありません。これらの証明書の多くは JRE トラストストアでも使用できるため、その場合は TLS コンテキストでのセットアップは不要です。 証明書は、よく知られた証明書機関 (CA) が生成するか、またはユーザーが外部承認なしでローカルに証明書 (自己署名証明書) を生成することができます。トラストストアには、サーバーから提供された証明書をクライアントが検証するために使用する信頼済みの CA があります。 ## [](#キーストアとトラストストア)キーストアとトラストストア Mule 設定の ​`tls:trust-store`​ 要素と ​`tls:key-store`​ 要素は、特定の証明書とキーを参照しますが、​`tls:trust-store`​ の値を指定しないと、Mule はデフォルトの Java トラストストアを参照します。Java を更新するとデフォルトのトラストストアも更新されますので、よく知られた CA 証明書を最新に保つために、定期的な更新をお勧めします。 トラストストアとキーストアは、クライアントとサーバーのどちらで使用するかによってコンテンツが異なります。 - サーバー用: トラストストアには信頼済みのクライアントの証明書、キーストアにはサーバーの非公開キーと公開キーが格納されています。 - クライアント用: トラストストアには信頼済みのサーバーの証明書、キーストアにはクライアントの非公開キーと公開キーが格納されています。 キーストアとトラストストアの両方を追加すると、相互認証とも呼ばれる両方向の TLS 認証を実装できます。 キーストアには 1 つまたは 2 つのパスワードがあります。 - `password`​ はキーストアファイル全体にアクセスします。 - `keyPassword`​ は、キーストアにあるサーバーの非公開キーにアクセスします。 ## [](#クライアントの設定)クライアントの設定 `tls:context`​ に空白のトラストストアが定義されている場合は、JVM のデフォルト値 (通常は、すべての主要証明機関の証明書が格納されたトラストストア) が使用されます。次のシナリオを考えてみます。 - トラストストアがインラインで定義されている場合: - トラストストアがグローバル要素を使用して定義されている場合: クライアントが接続しようとしているサーバーからの証明書を必要とする場合は、​`tls:trust-store`​ 要素を追加します。​`path`​ には、信頼済みのサーバーの証明書が格納されているトラストストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する場合は、​`tls:key-store`​ 要素に、クライアントの非公開/公開キーが格納されたキーストアファイルの場所が設定された ​`path`​ を組み合わせる必要があります。 設定の手順は、​[「Mule 4 での TLS の設定」](#configure-tls-in-mule-4)​を参照してください。 ## [](#サーバーの設定)サーバーの設定 `tls:context`​ には、HTTPS などのセキュアな接続を使用して要求をリッスンする ​`tls:key-store`​ 要素を指定する必要があります。​`path`​ には、サーバーの非公開/公開キーが格納されているキーストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する必要がある場合は、​`tls:trust-store`​ 要素を追加し、信頼済みのクライアントの証明書が格納されたトラストストアファイルの場所を ​`path`​ に設定します。 Mule は、多くのキーストア種別をサポートします。例: - `JCEKS` - `PKCS12` - `JKS` キーストア種別は JRE に指定します。 Mule アプリケーション用に TLS を完全に設定するための手順は次の通りです。 1. Oracle の Java keytool を使用して​[キーストアとトラストストアを生成します](https://docs.mulesoft.com/jp/mule-runtime/4.4/%3C#Generate a Keystore>)​。 2. [Mule でクライアントまたはサーバー用の TLS をグローバルに設定します](https://docs.mulesoft.com/jp/mule-runtime/4.4/%3C#Configure TLS in Mule 4>)​。 3. [省略可能: プロトコルと暗号化スイートを指定します](https://docs.mulesoft.com/jp/mule-runtime/4.4/%3C#Optional: Specify Protocols and Cipher Suites>)​。 ## [](#キーストアの生成)キーストアの生成 標準 JDK 配布には、デフォルトではキーストアが含まれていないため、​`keytool`​ を使用してキーストアおよび証明書を生成します。生成したキーストアには、非公開キーと公開証明書が格納されます。この証明書は自己署名であるため、クライアントと公開証明書を共有するまでは、クライアントには信頼されません。 ### [](#要件)要件 Java 8 を使用してキーストアを生成します。別の JDK バージョンを使用すると非互換のキーストアが生成され、Mule アプリケーションがキーストアを読み込もうとすると無効なキーストア形式ランタイムエラーが発生します。 ### [](#キーストアを生成する)キーストアを生成する 次の手順に従い、キーストアを生成して自己署名証明書をエクスポートします。 1. サーバーの証明書を公開するキーストアを生成します。 たとえば、次のいずれかのコマンドを実行します。 keytool -genkey -keyalg RSA -alias -keystore .jks keytool -genkey -alias -keyalg RSA -keystore .jks -storepass ``​ は選択した一意の別名に置き換えます。 ``​ は選択したパスワードに置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 必要に応じて、​`-keyalg RSA`​ の代わりに ​`-keyalg EC`​ を指定して、暗号化アルゴリズムを ECDSA に設定できます。
暗号化アルゴリズムを指定しない場合、ツールではデフォルトで DSA が使用されます。DSA には TLS 1.2 との互換性がないため、Mule アプリケーションで HTTPS 要求を受信すると SSL ハンドシェイクが失敗します。
2. ツールの要求メッセージに応答します。応答例: Enter keystore password: mule123 Re-enter new password: mule123 3. 入力画面に対して他の値を入力します。目的の値を入力します。応答例: What is your first and last name? \[Unknown\]: max What is the name of your organizational unit? \[Unknown\]: MuleSoft What is the name of your organization? \[Unknown\]: MuleSoft Inc What is the name of your City or Locality? \[Unknown\]: San Francisco What is the name of your State or Province? \[Unknown\]: CA What is the two-letter country code for this unit? \[Unknown\]: 01 4. 次の入力画面に対して ​`yes`​ と入力します。 Is CN=max, OU=MuleSoft, O=MuleSoft Inc, L=San Francisco, ST=CA, C=01 correct? \[no\]: yes 5. 次の入力画面に応答します。たとえば、RETURN キーを押して同じパスワードを使用します。 Enter key password for (RETURN if same as keystore password): 6. 公開キーを認証する自己署名証明書をエクスポートするために次のコマンドを入力します。 keytool -export -alias -keystore .jks -file .cer ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書に使用する名前に置き換えます。 7. 証明書に関連付けられたキーストア用にセットアップしたパスワードを入力します。 Enter keystore password: mule123 ### [](#認証機関による署名を要求する)認証機関による署名を要求する 認証機関 (CA) から証明書への署名を受けるには、次の手順に従います。 1. 証明書を標準 CSR 形式でエクスポートします。そのためには、次のコマンドを実行できます。 keytool -certreq -keystore .jks -alias -file .csr ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書署名要求ファイルに使用する名前に置き換えます。 2. 前のステップで生成された CSR ファイルを認証機関に送信し、手順に従って署名を取得します。 CA の署名を取得したら、次のコマンドを使用して署名済みの証明書ファイルをインポートできます。 keytool -import -keystore .jks -alias -file ``​ は目的の新しい値に置き換えます。定義した別名を既存のキーにリンクさせないでください。リンクさせるとプロセスが失敗します。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は認証機関から受信した署名済み証明書の名前に置き換えます。 1. 証明書を標準 PEM 形式でエクスポートします。最初にキーストア種別を確認してから証明書をエクスポートします。 keytool -list -v -keystore .jks openssl -in .jks -out .key.pem -nocerts -nodes openssl -in .jks -out .crt.pem -nocerts -nodes ``​ はキーストア種別の形式 (PKCS12 など) で新しい目的の値に置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 ``​ は PEM ファイルに使用する名前に置き換えます。 ## [](#トラストストアの生成)トラストストアの生成 標準 JRE 配布には、いくつかの主要証明機関 (CA) の証明書が格納されたデフォルトのトラストストアがあり、デフォルトで tls:trust-store 要素で使用されますが、より強力なセキュリティが必要な場合や、自己署名証明書を使用する場合には、新たにトラストストアを作成できます。 トラストストアは Oracle Java keytool で作成します。 クライアントは、信頼の連鎖 (chain of trust) が確立されることでサーバーを信頼します。信頼の連鎖は、クライアントとサーバーの間で直接 (クライアントのトラストストアにサーバーの証明書が格納されることで) 確立されるか、またはクライアントのトラストストアに証明書が格納されている署名 CA 経由で確立されます。信頼の連鎖が確立されていないと、接続が失敗します。自己署名証明書を使用する場合は、トラストストアを定義する必要があります。 ## [](#mule-4-での-tls-の設定)Mule 4 での TLS の設定 Mule アプリケーションで TLS を有効にするには、次の 3 つの方法のいずれかを使用して Mule XML 設定ファイルで ​`tls:context`​ 要素を設定します。 - [XML ファイルを直接編集する。](https://docs.mulesoft.com/jp/mule-runtime/4.4/%3C#Edit XML to Configure TLS>) - [Anypoint Studio 7 を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.4/%3C#Use Anypoint Studio to Configure TLS>) - [Design Center を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.4/%3C#Use Design Center to Configure TLS>) どの方法を使用する場合でも、​[\[Edit XML to Configure TLS\]](<#Edit XML to Configure TLS>)​の情報を参照して、​`tls:context`​ の属性がどのように機能するのかを理解しておくことをお勧めします。 ### [](#xml-の編集による-tls-の設定)XML の編集による TLS の設定 `tls:context`​ 要素は、Mule アプリケーションで TLS 通信を定義します。特別な要件がない限り、TLS はグローバルに設定して、HTTPS のリスンや送信といった特定の用途に適用してください。 #### [](#tls-要素のグローバル設定)TLS 要素のグローバル設定 `tls:context`​ 要素は、クライアント側とサーバー側の両方から使用できる TLS の設定を定義します。この要素は、他のモジュールの設定オブジェクトから参照したり、いずれかのオブジェクトのネストされた要素として定義したりすることができます。 ネストされた要素を最低 1 つは含めます (key-store と trust-store)。 ```xml ``` #### [](#tls-context-要素の省略可能な属性)`tls-context`​ 要素の省略可能な属性 プロトコルと暗号化スイートを指定して有効にすることができます (省略可能)。 - `enabledProtocols`​: グローバル TLS 設定のプロトコル - `enabledCipherSuites`​: グローバル TLS 設定の暗号化スイート [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.4/%3C#Optional: Specify Protocols and Cipher Suites>)​で説明するように、これらの値は、グローバル TLS 設定で何も指定されていないか、またはこれらの値がグローバル TLS 設定で有効化されている場合に使用されます。 #### [](#trust-store-要素の属性)`trust-store`​ 要素の属性 `path`​ を指定する場合は、​`password`​ 属性が必要です。そうでない場合は省略可能です。 - `path`​: トラストストアが格納されているファイルへのパス - `type`​: トラストストアの種別。デフォルトは JKS - `password`​: トラストストアのパスワード (​`path`​ を指定した場合は必須) - `algorithm`​: トラストストアが使用するアルゴリズム。デフォルトは ​`SunX509` - `insecure`​: トラストストアを検証するかどうかを決定するブール値。​`true`​ に設定すると検証は行われません。デフォルト値は ​`false`​ です。
insecure​ を ​true​ に設定すると、接続が攻撃に対して脆弱になります。この設定は、プロトタイプ開発やテストにおいてのみ使用してください。本番環境では絶対に使用しないでください。
#### [](#key-store-要素の属性)`key-store`​ 要素の属性 `path`​ 以外の属性は省略可能です。 - `path`​: キーストアが格納されているファイルへのパス (必須) - `type`​: キーストアの種別 (デフォルトは JKS) - `password`​: キーストアのパスワード - `keyPassword`​: キーマネージャーのパスワード。キーストア内の非公開キーのパスワードです - `algorithm`​: キーストアで使用するアルゴリズム。デフォルト値は ​`SunX509`​ です。 ### [](#design-center-を使用して-tls-を設定する)Design Center を使用して TLS を設定する Design Center を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Design Center にログインします。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[Configuration (設定)\] タブで ​**\[Edit (編集)\]**​ をクリックします。 5. \[TLS\] タブで、上記の TLS 設定項目を設定します。 6. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.4/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ### [](#anypoint-studio-を使用して-tls-を設定する)Anypoint Studio を使用して TLS を設定する Anypoint Studio (Studio) を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Studio Center を開きます。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[General (一般)\] タブで、既存の設定を選択するか、または新しい設定を作成します。 5. \[HTTP Listener config (HTTP リスナーの設定)\] ダイアログで、\[TLS\] タブを選択します。 6. \[TLS\] タブの \[TLS Configuration type (TLS 設定種別)\] で ​**\[Edit Inline (インライン編集)\]**​ を選択して、値を入力します。 7. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.4/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、\[Advanced (詳細)\] セクションの ​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ## [](#省略可能-プロトコルと暗号化スイートの指定)省略可能: プロトコルと暗号化スイートの指定 2 つのシステムの間で TLS 通信が行われると、使用するプロトコルと暗号化スイートがネゴシエーションによって決定します。必要に応じて、管理者が使用するプロトコルと暗号化スイートを指定して、アプリケーション開発者がそれらを ​`tls:context`​ で指定することができます。
使用するプロトコルと暗号化スイートは、Mule Runtime と各アプリケーションで有効化しておく必要があります。プロトコルと暗号化スイートが両方の場所で有効化されていないと、Java 環境のデフォルトのプロトコルと暗号化スイートが使用されます。
Mule Runtime でプロトコルと暗号化スイートを設定する手順は次の通りです。 1. Mule 管理者は、​`$MULE_HOME`​ の下にある ​`/conf`​ ディレクトリを編集します。​`$MULE_HOME`​ は、Mule がインストールされているディレクトリを参照します。例: `/opt/mule-4.0`​。暗号化スイートとプロトコルを指定するための適切なファイルを選択します。 - `tls-default.conf`​ は、Mule が Federal Information Processing Standards (FIPS) セキュリティモードで動作するように設定されていない場合に使用します。 - `tls-fips140-2.conf`​ Mule が FIPS セキュリティモードで動作するように設定されている場合に使用します。 関連するファイルを開き、リストの項目をコメントまたはコメント解除することで、使用する暗号化スイートと TLS プロトコルを手動で設定します。これらのファイルを編集しないと、設定されているセキュリティマネージャーが Mule アプリケーション用の暗号化スイートとプロトコルを選択します。 2. これらの設定ファイルで管理者が設定したプロトコルと暗号化スイートのリストは、アプリケーション開発者がそれぞれの ​`tls:context`​ 要素で指定する内容によってローカルに制約できます。アプリケーション開発者は、​`tls:context`​ 要素の設定値またはデフォルト値のサブセットを TLS で使用するように指定します。プロトコルと暗号化スイートは、​`tls:context`​ 要素の ​`enabledProtocols`​ と ​`enabledCipherSuites`​ で指定します。 `tls:context`​ 要素では、Mule グローバル TLS 設定ファイルで指定されているプロトコルまたは暗号化スイート、またはデフォルトのみを参照できます。​`tls:context`​ で、Mule アプリケーション用の ​`enabledProtocols`​ と ​`enabledCipherSuite`​ を ​`default`​ に設定します。これらの値を設定すると、TLS は次のプロトコルと暗号化スイートを使用します。 - グローバル TLS 設定が存在する場合は、指定されているプロトコルと暗号化スイート - グローバル TLS 設定が存在しない場合は、Java 環境のデフォルト 暗号化スイート名は長くなることがあり、XML コードが読みづらくなります。読みやすくするためには、これらの名前を Mule プロジェクトの外部プロパティファイルに格納します。そして、プロパティを参照します。例: ```xml ``` ## [](#デプロイメント後のテストの例)デプロイメント後のテストの例 time curl -i -k --cert ./.crt.pem --cert-type PEM --key ./.key.pem https://: ``​ は定義された値名に置き換えます。 ``​ は Anypoint Platform によって定義された値名に置き換えます。 ``​ は Mule アプリケーションで定義された値名に置き換えます。 ## [](#tls-の設定例)TLS の設定例 TLS は、クライアントまたはサーバー用の Mule XML 設定ファイルでセットアップできます。 ### [](#例-クライアント用の-tls-の設定)例: クライアント用の TLS の設定 次の例では、トラストストアをセットアップすることで FTPS クライアントのセキュリティを確保しています。 ```xml ``` ### [](#例-サーバー用の-tls-の設定)例: サーバー用の TLS の設定 次の例では、キーストアをセットアップすることで HTTP リスナーのセキュリティを確保しています。 ```xml ``` ### [](#例-両方向認証用の-tls-の設定)例: 両方向認証用の TLS の設定 次の例では、HTTP リスナー用に両方向認証 (相互認証) をセットアップしています。 ```xml ``` ### [](#例-tls-検証の無効化)例: TLS 検証の無効化 次の例では、​`insecure`​ プロパティを使用して、プロトタイプ作成と開発で検証を無効化しています。
insecure​ は、本番環境では使用しないでください。
```xml ``` ### [](#例-暗号化スイートとプロトコルの制約の追加)例: 暗号化スイートとプロトコルの制約の追加 次の例では、Mule 管理者がグローバル TLS 設定で何も指定していないか、または暗号化スイートとプロトコルをここで指定できるように有効化してあるという前提で、アプリケーションでプロトコルと暗号化スイートを有効化しています。 ```xml ``` ## [](#関連情報)関連情報 - [Oracle のセキュリティ](http://docs.oracle.com/javase/8/docs/technotes/tools/#security) - [Oracle Java keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) # キーストアとトラストストアを使用した TLS の設定 TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。TLS には、認証キーをエクスチェンジし、データを暗号化し、メッセージの整合性を保証するための多くの方法があります。このトピックでは、Mule が TLS をどのようにサポートするか、そして Mule アプリケーションで TLS をどのように設定するかについて説明します。 ## [](#tls_compatibility)TLS 互換性マトリックス TLS との互換性は、Mule デプロイメントモデルと TLS バージョンによって異なります。
TLS バージョン オンプレミス CloudHub Anypoint Runtime Fabric

1.3

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされますが、デフォルトでは​有効化されていません

このデプロイメントモデルでホストされている Mule アプリケーションでサポートされます

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされ、有効化されます

1.2

すべてのデプロイメントモデルでサポートされ、有効化されます

1.1

すべてのデプロイメントモデルでサポートされ、有効化されます
## [](#tlscontext-要素)tls:context 要素 `tls:context`​ 要素は、TLS をサポートするすべてのコネクタで使用します。たとえば、TLS は HTTP (サーバーとクライアント)、FTPS (クライアント)、メール (クライアント)、またはソケット (クライアント) などのコネクタで設定できます。

コネクタで TLS がサポートされる場合、Studio には次のいずれかが表示されます。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[TLS/SSL]​ タブ。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[General (一般)]​ タブの ​[TLS Configuration (TLS 設定)]​ 項目。
## [](#tls-対応のサーバーとクライアント)TLS 対応のサーバーとクライアント TLS 対応のサーバーには、非公開キーと公開証明書が含まれます。 - 非公開キーはサーバーの外部には送信されません。 - 公開証明書は TLS 経由で公開されます。 TLS 対応クライアントは、自身が保管する信頼済みの証明書を使用して公開証明書を検証することで、サーバーが信頼できるかどうかを確認します。 Mule 4 で TLS 通信セキュリティを使用するには、証明書と非公開キーをキーストアファイルにインポートします。トラストストアファイルは、慣例として信頼済みのサーバー公開証明書のみが格納されるキーストアでもあります。 標準 JRE 配布には、デフォルトの Java トラストストアはありますが、デフォルトの Java キーストアはありません。自身のキーストアを TLS コンテキストに追加してください。すでにクライアントアプリケーション用に企業の証明書があれば、新たに作成する必要はありません。これらの証明書の多くは JRE トラストストアでも使用できるため、その場合は TLS コンテキストでのセットアップは不要です。 証明書は、よく知られた証明書機関 (CA) が生成するか、またはユーザーが外部承認なしでローカルに証明書 (自己署名証明書) を生成することができます。トラストストアには、サーバーから提供された証明書をクライアントが検証するために使用する信頼済みの CA があります。 ## [](#キーストアとトラストストア)キーストアとトラストストア Mule 設定の ​`tls:trust-store`​ 要素と ​`tls:key-store`​ 要素は、特定の証明書とキーを参照しますが、​`tls:trust-store`​ の値を指定しないと、Mule はデフォルトの Java トラストストアを参照します。Java を更新するとデフォルトのトラストストアも更新されますので、よく知られた CA 証明書を最新に保つために、定期的な更新をお勧めします。 トラストストアとキーストアは、クライアントとサーバーのどちらで使用するかによってコンテンツが異なります。 - サーバー用: トラストストアには信頼済みのクライアントの証明書、キーストアにはサーバーの非公開キーと公開キーが格納されています。 - クライアント用: トラストストアには信頼済みのサーバーの証明書、キーストアにはクライアントの非公開キーと公開キーが格納されています。 キーストアとトラストストアの両方を追加すると、相互認証とも呼ばれる両方向の TLS 認証を実装できます。 キーストアには 1 つまたは 2 つのパスワードがあります。 - `password`​ はキーストアファイル全体にアクセスします。 - `keyPassword`​ は、キーストアにあるサーバーの非公開キーにアクセスします。 ## [](#クライアントの設定)クライアントの設定 `tls:context`​ に空白のトラストストアが定義されている場合は、JVM のデフォルト値 (通常は、すべての主要証明機関の証明書が格納されたトラストストア) が使用されます。次のシナリオを考えてみます。 - トラストストアがインラインで定義されている場合: - トラストストアがグローバル要素を使用して定義されている場合: クライアントが接続しようとしているサーバーからの証明書を必要とする場合は、​`tls:trust-store`​ 要素を追加します。​`path`​ には、信頼済みのサーバーの証明書が格納されているトラストストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する場合は、​`tls:key-store`​ 要素に、クライアントの非公開/公開キーが格納されたキーストアファイルの場所が設定された ​`path`​ を組み合わせる必要があります。 設定の手順は、​[「Mule 4 での TLS の設定」](#configure-tls-in-mule-4)​を参照してください。 ## [](#サーバーの設定)サーバーの設定 `tls:context`​ には、HTTPS などのセキュアな接続を使用して要求をリッスンする ​`tls:key-store`​ 要素を指定する必要があります。​`path`​ には、サーバーの非公開/公開キーが格納されているキーストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する必要がある場合は、​`tls:trust-store`​ 要素を追加し、信頼済みのクライアントの証明書が格納されたトラストストアファイルの場所を ​`path`​ に設定します。 Mule は、多くのキーストア種別をサポートします。例: - `JCEKS` - `PKCS12` - `JKS` キーストア種別は JRE に指定します。 Mule アプリケーション用に TLS を完全に設定するための手順は次の通りです。 1. Oracle の Java keytool を使用して​[キーストアとトラストストアを生成します](https://docs.mulesoft.com/jp/mule-runtime/4.5/%3C#Generate a Keystore>)​。 2. [Mule でクライアントまたはサーバー用の TLS をグローバルに設定します](https://docs.mulesoft.com/jp/mule-runtime/4.5/%3C#Configure TLS in Mule 4>)​。 3. [省略可能: プロトコルと暗号化スイートを指定します](https://docs.mulesoft.com/jp/mule-runtime/4.5/%3C#Optional: Specify Protocols and Cipher Suites>)​。 ## [](#キーストアの生成)キーストアの生成 標準 JDK 配布には、デフォルトではキーストアが含まれていないため、​`keytool`​ を使用してキーストアおよび証明書を生成します。生成したキーストアには、非公開キーと公開証明書が格納されます。この証明書は自己署名であるため、クライアントと公開証明書を共有するまでは、クライアントには信頼されません。 ### [](#要件)要件 Java 8 を使用してキーストアを生成します。別の JDK バージョンを使用すると非互換のキーストアが生成され、Mule アプリケーションがキーストアを読み込もうとすると無効なキーストア形式ランタイムエラーが発生します。 ### [](#キーストアを生成する)キーストアを生成する 次の手順に従い、キーストアを生成して自己署名証明書をエクスポートします。 1. サーバーの証明書を公開するキーストアを生成します。 たとえば、次のいずれかのコマンドを実行します。 keytool -genkey -keyalg RSA -alias -keystore .jks keytool -genkey -alias -keyalg RSA -keystore .jks -storepass ``​ は選択した一意の別名に置き換えます。 ``​ は選択したパスワードに置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 必要に応じて、​`-keyalg RSA`​ の代わりに ​`-keyalg EC`​ を指定して、暗号化アルゴリズムを ECDSA に設定できます。
暗号化アルゴリズムを指定しない場合、ツールではデフォルトで DSA が使用されます。DSA には TLS 1.2 との互換性がないため、Mule アプリケーションで HTTPS 要求を受信すると SSL ハンドシェイクが失敗します。
2. ツールの要求メッセージに応答します。応答例: Enter keystore password: mule123 Re-enter new password: mule123 3. 入力画面に対して他の値を入力します。目的の値を入力します。応答例: What is your first and last name? \[Unknown\]: max What is the name of your organizational unit? \[Unknown\]: MuleSoft What is the name of your organization? \[Unknown\]: MuleSoft Inc What is the name of your City or Locality? \[Unknown\]: San Francisco What is the name of your State or Province? \[Unknown\]: CA What is the two-letter country code for this unit? \[Unknown\]: 01 4. 次の入力画面に対して ​`yes`​ と入力します。 Is CN=max, OU=MuleSoft, O=MuleSoft Inc, L=San Francisco, ST=CA, C=01 correct? \[no\]: yes 5. 次の入力画面に応答します。たとえば、RETURN キーを押して同じパスワードを使用します。 Enter key password for (RETURN if same as keystore password): 6. 公開キーを認証する自己署名証明書をエクスポートするために次のコマンドを入力します。 keytool -export -alias -keystore .jks -file .cer ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書に使用する名前に置き換えます。 7. 証明書に関連付けられたキーストア用にセットアップしたパスワードを入力します。 Enter keystore password: mule123 ### [](#認証機関による署名を要求する)認証機関による署名を要求する 認証機関 (CA) から証明書への署名を受けるには、次の手順に従います。 1. 証明書を標準 CSR 形式でエクスポートします。そのためには、次のコマンドを実行できます。 keytool -certreq -keystore .jks -alias -file .csr ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書署名要求ファイルに使用する名前に置き換えます。 2. 前のステップで生成された CSR ファイルを認証機関に送信し、手順に従って署名を取得します。 CA の署名を取得したら、次のコマンドを使用して署名済みの証明書ファイルをインポートできます。 keytool -import -keystore .jks -alias -file ``​ は目的の新しい値に置き換えます。定義した別名を既存のキーにリンクさせないでください。リンクさせるとプロセスが失敗します。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は認証機関から受信した署名済み証明書の名前に置き換えます。 1. 証明書を標準 PEM 形式でエクスポートします。最初にキーストア種別を確認してから証明書をエクスポートします。 keytool -list -v -keystore .jks openssl -in .jks -out .key.pem -nocerts -nodes openssl -in .jks -out .crt.pem -nocerts -nodes ``​ はキーストア種別の形式 (PKCS12 など) で新しい目的の値に置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 ``​ は PEM ファイルに使用する名前に置き換えます。 ## [](#トラストストアの生成)トラストストアの生成 標準 JRE 配布には、いくつかの主要証明機関 (CA) の証明書が格納されたデフォルトのトラストストアがあり、デフォルトで tls:trust-store 要素で使用されますが、より強力なセキュリティが必要な場合や、自己署名証明書を使用する場合には、新たにトラストストアを作成できます。 トラストストアは Oracle Java keytool で作成します。 クライアントは、信頼の連鎖 (chain of trust) が確立されることでサーバーを信頼します。信頼の連鎖は、クライアントとサーバーの間で直接 (クライアントのトラストストアにサーバーの証明書が格納されることで) 確立されるか、またはクライアントのトラストストアに証明書が格納されている署名 CA 経由で確立されます。信頼の連鎖が確立されていないと、接続が失敗します。自己署名証明書を使用する場合は、トラストストアを定義する必要があります。 ## [](#mule-4-での-tls-の設定)Mule 4 での TLS の設定 Mule アプリケーションで TLS を有効にするには、次の 3 つの方法のいずれかを使用して Mule XML 設定ファイルで ​`tls:context`​ 要素を設定します。 - [XML ファイルを直接編集する。](https://docs.mulesoft.com/jp/mule-runtime/4.5/%3C#Edit XML to Configure TLS>) - [Anypoint Studio 7 を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.5/%3C#Use Anypoint Studio to Configure TLS>) - [Design Center を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.5/%3C#Use Design Center to Configure TLS>) どの方法を使用する場合でも、​[\[Edit XML to Configure TLS\]](<#Edit XML to Configure TLS>)​の情報を参照して、​`tls:context`​ の属性がどのように機能するのかを理解しておくことをお勧めします。 ### [](#xml-の編集による-tls-の設定)XML の編集による TLS の設定 `tls:context`​ 要素は、Mule アプリケーションで TLS 通信を定義します。特別な要件がない限り、TLS はグローバルに設定して、HTTPS のリスンや送信といった特定の用途に適用してください。 #### [](#tls-要素のグローバル設定)TLS 要素のグローバル設定 `tls:context`​ 要素は、クライアント側とサーバー側の両方から使用できる TLS の設定を定義します。この要素は、他のモジュールの設定オブジェクトから参照したり、いずれかのオブジェクトのネストされた要素として定義したりすることができます。 ネストされた要素を最低 1 つは含めます (key-store と trust-store)。 ```xml ``` #### [](#tls-context-要素の省略可能な属性)`tls-context`​ 要素の省略可能な属性 プロトコルと暗号化スイートを指定して有効にすることができます (省略可能)。 - `enabledProtocols`​: グローバル TLS 設定のプロトコル - `enabledCipherSuites`​: グローバル TLS 設定の暗号化スイート [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.5/%3C#Optional: Specify Protocols and Cipher Suites>)​で説明するように、これらの値は、グローバル TLS 設定で何も指定されていないか、またはこれらの値がグローバル TLS 設定で有効化されている場合に使用されます。 #### [](#trust-store-要素の属性)`trust-store`​ 要素の属性 `path`​ を指定する場合は、​`password`​ 属性が必要です。そうでない場合は省略可能です。 - `path`​: トラストストアが格納されているファイルへのパス - `type`​: トラストストアの種別。デフォルトは JKS - `password`​: トラストストアのパスワード (​`path`​ を指定した場合は必須) - `algorithm`​: トラストストアが使用するアルゴリズム。デフォルトは ​`SunX509` - `insecure`​: トラストストアを検証するかどうかを決定するブール値。​`true`​ に設定すると検証は行われません。デフォルト値は ​`false`​ です。
insecure​ を ​true​ に設定すると、接続が攻撃に対して脆弱になります。この設定は、プロトタイプ開発やテストにおいてのみ使用してください。本番環境では絶対に使用しないでください。
#### [](#key-store-要素の属性)`key-store`​ 要素の属性 `path`​ 以外の属性は省略可能です。 - `path`​: キーストアが格納されているファイルへのパス (必須) - `type`​: キーストアの種別 (デフォルトは JKS) - `password`​: キーストアのパスワード - `keyPassword`​: キーマネージャーのパスワード。キーストア内の非公開キーのパスワードです - `algorithm`​: キーストアで使用するアルゴリズム。デフォルト値は ​`SunX509`​ です。 ### [](#design-center-を使用して-tls-を設定する)Design Center を使用して TLS を設定する Design Center を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Design Center にログインします。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[Configuration (設定)\] タブで ​**\[Edit (編集)\]**​ をクリックします。 5. \[TLS\] タブで、上記の TLS 設定項目を設定します。 6. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.5/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ### [](#anypoint-studio-を使用して-tls-を設定する)Anypoint Studio を使用して TLS を設定する Anypoint Studio (Studio) を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Studio Center を開きます。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[General (一般)\] タブで、既存の設定を選択するか、または新しい設定を作成します。 5. \[HTTP Listener config (HTTP リスナーの設定)\] ダイアログで、\[TLS\] タブを選択します。 6. \[TLS\] タブの \[TLS Configuration type (TLS 設定種別)\] で ​**\[Edit Inline (インライン編集)\]**​ を選択して、値を入力します。 7. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.5/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、\[Advanced (詳細)\] セクションの ​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ## [](#省略可能-プロトコルと暗号化スイートの指定)省略可能: プロトコルと暗号化スイートの指定 2 つのシステムの間で TLS 通信が行われると、使用するプロトコルと暗号化スイートがネゴシエーションによって決定します。必要に応じて、管理者が使用するプロトコルと暗号化スイートを指定して、アプリケーション開発者がそれらを ​`tls:context`​ で指定することができます。
使用するプロトコルと暗号化スイートは、Mule Runtime と各アプリケーションで有効化しておく必要があります。プロトコルと暗号化スイートが両方の場所で有効化されていないと、Java 環境のデフォルトのプロトコルと暗号化スイートが使用されます。
Mule Runtime でプロトコルと暗号化スイートを設定する手順は次の通りです。 1. Mule 管理者は、​`$MULE_HOME`​ の下にある ​`/conf`​ ディレクトリを編集します。​`$MULE_HOME`​ は、Mule がインストールされているディレクトリを参照します。例: `/opt/mule-4.0`​。暗号化スイートとプロトコルを指定するための適切なファイルを選択します。 - `tls-default.conf`​ は、Mule が Federal Information Processing Standards (FIPS) セキュリティモードで動作するように設定されていない場合に使用します。 - `tls-fips140-2.conf`​ Mule が FIPS セキュリティモードで動作するように設定されている場合に使用します。 関連するファイルを開き、リストの項目をコメントまたはコメント解除することで、使用する暗号化スイートと TLS プロトコルを手動で設定します。これらのファイルを編集しないと、設定されているセキュリティマネージャーが Mule アプリケーション用の暗号化スイートとプロトコルを選択します。 2. これらの設定ファイルで管理者が設定したプロトコルと暗号化スイートのリストは、アプリケーション開発者がそれぞれの ​`tls:context`​ 要素で指定する内容によってローカルに制約できます。アプリケーション開発者は、​`tls:context`​ 要素の設定値またはデフォルト値のサブセットを TLS で使用するように指定します。プロトコルと暗号化スイートは、​`tls:context`​ 要素の ​`enabledProtocols`​ と ​`enabledCipherSuites`​ で指定します。 `tls:context`​ 要素では、Mule グローバル TLS 設定ファイルで指定されているプロトコルまたは暗号化スイート、またはデフォルトのみを参照できます。​`tls:context`​ で、Mule アプリケーション用の ​`enabledProtocols`​ と ​`enabledCipherSuite`​ を ​`default`​ に設定します。これらの値を設定すると、TLS は次のプロトコルと暗号化スイートを使用します。 - グローバル TLS 設定が存在する場合は、指定されているプロトコルと暗号化スイート - グローバル TLS 設定が存在しない場合は、Java 環境のデフォルト 暗号化スイート名は長くなることがあり、XML コードが読みづらくなります。読みやすくするためには、これらの名前を Mule プロジェクトの外部プロパティファイルに格納します。そして、プロパティを参照します。次に例を示します。 ```xml ``` ## [](#デプロイメント後のテストの例)デプロイメント後のテストの例 time curl -i -k --cert ./.crt.pem --cert-type PEM --key ./.key.pem https://: ``​ は定義された値名に置き換えます。 ``​ は Anypoint Platform によって定義された値名に置き換えます。 ``​ は Mule アプリケーションで定義された値名に置き換えます。 ## [](#tls-の設定例)TLS の設定例 TLS は、クライアントまたはサーバー用の Mule XML 設定ファイルでセットアップできます。 ### [](#例-クライアント用の-tls-の設定)例: クライアント用の TLS の設定 次の例では、トラストストアをセットアップすることで FTPS クライアントのセキュリティを確保しています。 ```xml ``` ### [](#例-サーバー用の-tls-の設定)例: サーバー用の TLS の設定 次の例では、キーストアをセットアップすることで HTTP リスナーのセキュリティを確保しています。 ```xml ``` ### [](#例-両方向認証用の-tls-の設定)例: 両方向認証用の TLS の設定 次の例では、HTTP リスナー用に両方向認証 (相互認証) をセットアップしています。 ```xml ``` ### [](#例-tls-検証の無効化)例: TLS 検証の無効化 次の例では、​`insecure`​ プロパティを使用して、プロトタイプ作成と開発で検証を無効化しています。
insecure​ は、本番環境では使用しないでください。
```xml ``` ### [](#例-暗号化スイートとプロトコルの制約の追加)例: 暗号化スイートとプロトコルの制約の追加 次の例では、Mule 管理者がグローバル TLS 設定で何も指定していないか、または暗号化スイートとプロトコルをここで指定できるように有効化してあるという前提で、アプリケーションでプロトコルと暗号化スイートを有効化しています。 ```xml ``` ## [](#関連情報)関連情報 - [Oracle のセキュリティ](http://docs.oracle.com/javase/8/docs/technotes/tools/#security) - [Oracle Java keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) # キーストアとトラストストアを使用した TLS の設定 TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。TLS には、認証キーをエクスチェンジし、データを暗号化し、メッセージの整合性を保証するための多くの方法があります。このトピックでは、Mule が TLS をどのようにサポートするか、そして Mule アプリケーションで TLS をどのように設定するかについて説明します。 ## [](#tls_compatibility)TLS 互換性マトリックス TLS との互換性は、Mule デプロイメントモデルと TLS バージョンによって異なります。
TLS バージョン オンプレミス CloudHub Anypoint Runtime Fabric

1.3

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされますが、デフォルトでは​有効化されていません

このデプロイメントモデルでホストされている Mule アプリケーションでサポートされます

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされ、有効化されます

1.2

すべてのデプロイメントモデルでサポートされ、有効化されます

1.1

すべてのデプロイメントモデルでサポートされ、有効化されます
## [](#tlscontext-要素)tls:context 要素 `tls:context`​ 要素は、TLS をサポートするすべてのコネクタで使用します。たとえば、TLS は HTTP (サーバーとクライアント)、FTPS (クライアント)、メール (クライアント)、またはソケット (クライアント) などのコネクタで設定できます。

コネクタで TLS がサポートされる場合、Studio には次のいずれかが表示されます。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[TLS/SSL]​ タブ。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[General (一般)]​ タブの ​[TLS Configuration (TLS 設定)]​ 項目。
## [](#tls-対応のサーバーとクライアント)TLS 対応のサーバーとクライアント TLS 対応のサーバーには、非公開キーと公開証明書が含まれます。 - 非公開キーはサーバーの外部には送信されません。 - 公開証明書は TLS 経由で公開されます。 TLS 対応クライアントは、自身が保管する信頼済みの証明書を使用して公開証明書を検証することで、サーバーが信頼できるかどうかを確認します。 Mule 4 で TLS 通信セキュリティを使用するには、証明書と非公開キーをキーストアファイルにインポートします。トラストストアファイルは、慣例として信頼済みのサーバー公開証明書のみが格納されるキーストアでもあります。 標準 JRE 配布には、デフォルトの Java トラストストアはありますが、デフォルトの Java キーストアはありません。自身のキーストアを TLS コンテキストに追加してください。すでにクライアントアプリケーション用に企業の証明書があれば、新たに作成する必要はありません。これらの証明書の多くは JRE トラストストアでも使用できるため、その場合は TLS コンテキストでのセットアップは不要です。 証明書は、よく知られた証明書機関 (CA) が生成するか、またはユーザーが外部承認なしでローカルに証明書 (自己署名証明書) を生成することができます。トラストストアには、サーバーから提供された証明書をクライアントが検証するために使用する信頼済みの CA があります。 ## [](#キーストアとトラストストア)キーストアとトラストストア Mule 設定の ​`tls:trust-store`​ 要素と ​`tls:key-store`​ 要素は、特定の証明書とキーを参照しますが、​`tls:trust-store`​ の値を指定しないと、Mule はデフォルトの Java トラストストアを参照します。Java を更新するとデフォルトのトラストストアも更新されますので、よく知られた CA 証明書を最新に保つために、定期的な更新をお勧めします。 トラストストアとキーストアは、クライアントとサーバーのどちらで使用するかによってコンテンツが異なります。 - サーバー用: トラストストアには信頼済みのクライアントの証明書、キーストアにはサーバーの非公開キーと公開キーが格納されています。 - クライアント用: トラストストアには信頼済みのサーバーの証明書、キーストアにはクライアントの非公開キーと公開キーが格納されています。 キーストアとトラストストアの両方を追加すると、相互認証とも呼ばれる両方向の TLS 認証を実装できます。 キーストアには 1 つまたは 2 つのパスワードがあります。 - `password`​ はキーストアファイル全体にアクセスします。 - `keyPassword`​ は、キーストアにあるサーバーの非公開キーにアクセスします。 ## [](#クライアントの設定)クライアントの設定 `tls:context`​ に空白のトラストストアが定義されている場合は、JVM のデフォルト値 (通常は、すべての主要証明機関の証明書が格納されたトラストストア) が使用されます。次のシナリオを考えてみます。 - トラストストアがインラインで定義されている場合: - トラストストアがグローバル要素を使用して定義されている場合: クライアントが接続しようとしているサーバーからの証明書を必要とする場合は、​`tls:trust-store`​ 要素を追加します。​`path`​ には、信頼済みのサーバーの証明書が格納されているトラストストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する場合は、​`tls:key-store`​ 要素に、クライアントの非公開/公開キーが格納されたキーストアファイルの場所が設定された ​`path`​ を組み合わせる必要があります。 設定の手順は、​[「Mule 4 での TLS の設定」](#configure-tls-in-mule-4)​を参照してください。 ## [](#サーバーの設定)サーバーの設定 `tls:context`​ には、HTTPS などのセキュアな接続を使用して要求をリスンする ​`tls:key-store`​ 要素を指定する必要があります。​`path`​ には、サーバーの非公開/公開キーが格納されているキーストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する必要がある場合は、​`tls:trust-store`​ 要素を追加し、信頼済みのクライアントの証明書が格納されたトラストストアファイルの場所を ​`path`​ に設定します。 Mule は、多くのキーストア種別をサポートします。例: - `JCEKS` - `PKCS12` - `JKS` キーストア種別は JRE に指定します。 Mule アプリケーション用に TLS を完全に設定するための手順は次の通りです。 1. Oracle の Java keytool を使用して​[キーストアとトラストストアを生成します](https://docs.mulesoft.com/jp/mule-runtime/4.6/%3C#Generate a Keystore>)​。 2. [Mule でクライアントまたはサーバー用の TLS をグローバルに設定します](https://docs.mulesoft.com/jp/mule-runtime/4.6/%3C#Configure TLS in Mule 4>)​。 3. [省略可能: プロトコルと暗号化スイートを指定します](https://docs.mulesoft.com/jp/mule-runtime/4.6/%3C#Optional: Specify Protocols and Cipher Suites>)​。 ## [](#キーストアの生成)キーストアの生成 標準 JDK 配布には、デフォルトではキーストアが含まれていないため、​`keytool`​ を使用してキーストアおよび証明書を生成します。生成したキーストアには、非公開キーと公開証明書が格納されます。この証明書は自己署名であるため、クライアントと公開証明書を共有するまでは、クライアントには信頼されません。 ### [](#要件)要件 Java 8 以降のバージョンを使用してキーストアを生成します。別の JDK バージョンを使用すると非互換のキーストアが生成され、Mule アプリケーションがキーストアを読み込もうとすると無効なキーストア形式ランタイムエラーが発生します。 ### [](#キーストアを生成する)キーストアを生成する 次の手順に従い、キーストアを生成して自己署名証明書をエクスポートします。 1. サーバーの証明書を公開するキーストアを生成します。 たとえば、次のいずれかのコマンドを実行します。 keytool -genkey -keyalg RSA -alias -keystore .jks keytool -genkey -alias -keyalg RSA -keystore .jks -storepass ``​ は選択した一意の別名に置き換えます。 ``​ は選択したパスワードに置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 必要に応じて、​`-keyalg RSA`​ の代わりに ​`-keyalg EC`​ を指定して、暗号化アルゴリズムを ECDSA に設定できます。
暗号化アルゴリズムを指定しない場合、ツールではデフォルトで DSA が使用されます。DSA には TLS 1.2 との互換性がないため、Mule アプリケーションで HTTPS 要求を受信すると SSL ハンドシェイクが失敗します。
2. ツールの要求メッセージに応答します。応答例: Enter keystore password: mule123 Re-enter new password: mule123 3. 入力画面に対して他の値を入力します。目的の値を入力します。応答例: What is your first and last name? \[Unknown\]: max What is the name of your organizational unit? \[Unknown\]: MuleSoft What is the name of your organization? \[Unknown\]: MuleSoft Inc What is the name of your City or Locality? \[Unknown\]: San Francisco What is the name of your State or Province? \[Unknown\]: CA What is the two-letter country code for this unit? \[Unknown\]: 01 4. 次の入力画面に対して ​`yes`​ と入力します。 Is CN=max, OU=MuleSoft, O=MuleSoft Inc, L=San Francisco, ST=CA, C=01 correct? \[no\]: yes 5. 次の入力画面に応答します。たとえば、RETURN キーを押して同じパスワードを使用します。 Enter key password for (RETURN if same as keystore password): 6. 公開キーを認証する自己署名証明書をエクスポートするために次のコマンドを入力します。 keytool -export -alias -keystore .jks -file .cer ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書に使用する名前に置き換えます。 7. 証明書に関連付けられたキーストア用にセットアップしたパスワードを入力します。 Enter keystore password: mule123 ### [](#認証機関による署名を要求する)認証機関による署名を要求する 認証機関 (CA) から証明書への署名を受けるには、次の手順に従います。 1. 証明書を標準 CSR 形式でエクスポートします。そのためには、次のコマンドを実行できます。 keytool -certreq -keystore .jks -alias -file .csr ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書署名要求ファイルに使用する名前に置き換えます。 2. 前のステップで生成された CSR ファイルを認証機関に送信し、手順に従って署名を取得します。 CA の署名を取得したら、次のコマンドを使用して署名済みの証明書ファイルをインポートできます。 keytool -import -keystore .jks -alias -file ``​ は目的の新しい値に置き換えます。定義した別名を既存のキーにリンクさせないでください。リンクさせるとプロセスが失敗します。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は認証機関から受信した署名済み証明書の名前に置き換えます。 1. 証明書を標準 PEM 形式でエクスポートします。最初にキーストア種別を確認してから証明書をエクスポートします。 keytool -list -v -keystore .jks openssl -in .jks -out .key.pem -nocerts -nodes openssl -in .jks -out .crt.pem -nocerts -nodes ``​ はキーストア種別の形式 (PKCS12 など) で新しい目的の値に置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 ``​ は PEM ファイルに使用する名前に置き換えます。 ## [](#トラストストアの生成)トラストストアの生成 標準 JRE 配布には、いくつかの主要証明機関 (CA) の証明書が格納されたデフォルトのトラストストアがあり、デフォルトで tls:trust-store 要素で使用されますが、より強力なセキュリティが必要な場合や、自己署名証明書を使用する場合には、新たにトラストストアを作成できます。 トラストストアは Oracle Java keytool で作成します。 クライアントは、信頼の連鎖 (chain of trust) が確立されることでサーバーを信頼します。信頼の連鎖は、クライアントとサーバーの間で直接 (クライアントのトラストストアにサーバーの証明書が格納されることで) 確立されるか、またはクライアントのトラストストアに証明書が格納されている署名 CA 経由で確立されます。信頼の連鎖が確立されていないと、接続が失敗します。自己署名証明書を使用する場合は、トラストストアを定義する必要があります。 ## [](#mule-4-での-tls-の設定)Mule 4 での TLS の設定 Mule アプリケーションで TLS を有効にするには、次の 3 つの方法のいずれかを使用して Mule XML 設定ファイルで ​`tls:context`​ 要素を設定します。 - [XML ファイルを直接編集する。](https://docs.mulesoft.com/jp/mule-runtime/4.6/%3C#Edit XML to Configure TLS>) - [Anypoint Studio 7 を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.6/%3C#Use Anypoint Studio to Configure TLS>) - [Design Center を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.6/%3C#Use Design Center to Configure TLS>) どの方法を使用する場合でも、​[\[Edit XML to Configure TLS\]](<#Edit XML to Configure TLS>)​の情報を参照して、​`tls:context`​ の属性がどのように機能するのかを理解しておくことをお勧めします。 ### [](#xml-の編集による-tls-の設定)XML の編集による TLS の設定 `tls:context`​ 要素は、Mule アプリケーションで TLS 通信を定義します。特別な要件がない限り、TLS はグローバルに設定して、HTTPS のリスンや送信といった特定の用途に適用してください。 #### [](#tls-要素のグローバル設定)TLS 要素のグローバル設定 `tls:context`​ 要素は、クライアント側とサーバー側の両方から使用できる TLS の設定を定義します。この要素は、他のモジュールの設定オブジェクトから参照したり、いずれかのオブジェクトのネストされた要素として定義したりすることができます。 ネストされた要素を最低 1 つは含めます (key-store と trust-store)。 ```xml ``` #### [](#tls-context-要素の省略可能な属性)`tls-context`​ 要素の省略可能な属性 プロトコルと暗号化スイートを指定して有効にすることができます (省略可能)。 - `enabledProtocols`​: グローバル TLS 設定のプロトコル - `enabledCipherSuites`​: グローバル TLS 設定の暗号化スイート [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.6/%3C#Optional: Specify Protocols and Cipher Suites>)​で説明するように、これらの値は、グローバル TLS 設定で何も指定されていないか、またはこれらの値がグローバル TLS 設定で有効化されている場合に使用されます。 #### [](#trust-store-要素の属性)`trust-store`​ 要素の属性 `path`​ を指定する場合は、​`password`​ 属性が必要です。そうでない場合は省略可能です。 - `path`​: トラストストアが格納されているファイルへのパス - `type`​: トラストストアの種別。デフォルトは JKS - `password`​: トラストストアのパスワード (​`path`​ を指定した場合は必須) - `algorithm`​: トラストストアが使用するアルゴリズム。デフォルトは ​`SunX509` - `insecure`​: トラストストアを検証するかどうかを決定するブール値。​`true`​ に設定すると検証は行われません。デフォルト値は ​`false`​ です。
insecure​ を ​true​ に設定すると、接続が攻撃に対して脆弱になります。この設定は、プロトタイプ開発やテストにおいてのみ使用してください。本番環境では絶対に使用しないでください。
#### [](#key-store-要素の属性)`key-store`​ 要素の属性 `path`​ 以外の属性は省略可能です。 - `path`​: キーストアが格納されているファイルへのパス (必須) - `type`​: キーストアの種別 (デフォルトは JKS) - `password`​: キーストアのパスワード - `keyPassword`​: キーマネージャーのパスワード。キーストア内の非公開キーのパスワードです - `algorithm`​: キーストアで使用するアルゴリズム。デフォルト値は ​`SunX509`​ です。 ### [](#design-center-を使用して-tls-を設定する)Design Center を使用して TLS を設定する Design Center を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Design Center にログインします。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[Configuration (設定)\] タブで ​**\[Edit (編集)\]**​ をクリックします。 5. \[TLS\] タブで、上記の TLS 設定項目を設定します。 6. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.6/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ### [](#anypoint-studio-を使用して-tls-を設定する)Anypoint Studio を使用して TLS を設定する Anypoint Studio (Studio) を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Studio Center を開きます。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[General (一般)\] タブで、既存の設定を選択するか、または新しい設定を作成します。 5. \[HTTP Listener config (HTTP リスナーの設定)\] ダイアログで、\[TLS\] タブを選択します。 6. \[TLS\] タブの \[TLS Configuration type (TLS 設定種別)\] で ​**\[Edit Inline (インライン編集)\]**​ を選択して、値を入力します。 7. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.6/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、\[Advanced (詳細)\] セクションの ​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ## [](#省略可能-プロトコルと暗号化スイートの指定)省略可能: プロトコルと暗号化スイートの指定 2 つのシステムの間で TLS 通信が行われると、使用するプロトコルと暗号化スイートがネゴシエーションによって決定します。必要に応じて、管理者が使用するプロトコルと暗号化スイートを指定して、アプリケーション開発者がそれらを ​`tls:context`​ で指定することができます。
使用するプロトコルと暗号化スイートは、Mule Runtime と各アプリケーションで有効化しておく必要があります。プロトコルと暗号化スイートが両方の場所で有効化されていないと、Java 環境のデフォルトのプロトコルと暗号化スイートが使用されます。
Mule Runtime でプロトコルと暗号化スイートを設定する手順は次の通りです。 1. Mule 管理者は、​`$MULE_HOME`​ の下にある ​`/conf`​ ディレクトリを編集します。​`$MULE_HOME`​ は、Mule がインストールされているディレクトリを参照します。例: `/opt/mule-4.0`​。暗号化スイートとプロトコルを指定するための適切なファイルを選択します。 - `tls-default.conf`​ は、Mule が Federal Information Processing Standards (FIPS) セキュリティモードで動作するように設定されていない場合に使用します。 - `tls-fips140-2.conf`​ Mule が FIPS セキュリティモードで動作するように設定されている場合に使用します。 関連するファイルを開き、リストの項目をコメントまたはコメント解除することで、使用する暗号化スイートと TLS プロトコルを手動で設定します。これらのファイルを編集しないと、設定されているセキュリティマネージャーが Mule アプリケーション用の暗号化スイートとプロトコルを選択します。 2. これらの設定ファイルで管理者が設定したプロトコルと暗号化スイートのリストは、アプリケーション開発者がそれぞれの ​`tls:context`​ 要素で指定する内容によってローカルに制約できます。アプリケーション開発者は、​`tls:context`​ 要素の設定値またはデフォルト値のサブセットを TLS で使用するように指定します。プロトコルと暗号化スイートは、​`tls:context`​ 要素の ​`enabledProtocols`​ と ​`enabledCipherSuites`​ で指定します。 `tls:context`​ 要素では、Mule グローバル TLS 設定ファイルで指定されているプロトコルまたは暗号化スイート、またはデフォルトのみを参照できます。​`tls:context`​ で、Mule アプリケーション用の ​`enabledProtocols`​ と ​`enabledCipherSuite`​ を ​`default`​ に設定します。これらの値を設定すると、TLS は次のプロトコルと暗号化スイートを使用します。 - グローバル TLS 設定が存在する場合は、指定されているプロトコルと暗号化スイート - グローバル TLS 設定が存在しない場合は、Java 環境のデフォルト 暗号化スイート名は長くなることがあり、XML コードが読みづらくなります。読みやすくするためには、これらの名前を Mule プロジェクトの外部プロパティファイルに格納します。そして、プロパティを参照します。次に例を示します。 ```xml ``` ## [](#デプロイメント後のテストの例)デプロイメント後のテストの例 time curl -i -k --cert ./.crt.pem --cert-type PEM --key ./.key.pem https://: ``​ は定義された値名に置き換えます。 ``​ は Anypoint Platform によって定義された値名に置き換えます。 ``​ は Mule アプリケーションで定義された値名に置き換えます。 ## [](#tls-の設定例)TLS の設定例 TLS は、クライアントまたはサーバー用の Mule XML 設定ファイルでセットアップできます。 ### [](#例-クライアント用の-tls-の設定)例: クライアント用の TLS の設定 次の例では、トラストストアをセットアップすることで FTPS クライアントのセキュリティを確保しています。 ```xml ``` ### [](#例-サーバー用の-tls-の設定)例: サーバー用の TLS の設定 次の例では、キーストアをセットアップすることで HTTP リスナーのセキュリティを確保しています。 ```xml ``` ### [](#例-両方向認証用の-tls-の設定)例: 両方向認証用の TLS の設定 次の例では、HTTP リスナー用に両方向認証 (相互認証) をセットアップしています。 ```xml ``` ### [](#例-tls-検証の無効化)例: TLS 検証の無効化 次の例では、​`insecure`​ プロパティを使用して、プロトタイプ作成と開発で検証を無効化しています。
insecure​ は、本番環境では使用しないでください。
```xml ``` ### [](#例-暗号化スイートとプロトコルの制約の追加)例: 暗号化スイートとプロトコルの制約の追加 次の例では、Mule 管理者がグローバル TLS 設定で何も指定していないか、または暗号化スイートとプロトコルをここで指定できるように有効化してあるという前提で、アプリケーションでプロトコルと暗号化スイートを有効化しています。 ```xml ``` ## [](#関連情報)関連情報 - [Oracle のセキュリティ](http://docs.oracle.com/javase/8/docs/technotes/tools/#security) - [Oracle Java keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) # キーストアとトラストストアを使用した TLS の設定 TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。TLS には、認証鍵をエクスチェンジし、データを暗号化し、メッセージの整合性を保証するための多くの方法があります。このトピックでは、Mule が TLS をどのようにサポートするか、そして Mule アプリケーションで TLS をどのように設定するかについて説明します。 ## [](#tls_compatibility)TLS 互換性マトリックス TLS との互換性は、Mule デプロイメントモデルと TLS バージョンによって異なります。
TLS バージョン オンプレミス CloudHub Anypoint Runtime Fabric

1.3

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされますが、デフォルトでは​有効化されていません

このデプロイメントモデルでホストされている Mule アプリケーションでサポートされます

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされ、有効化されます

1.2

すべてのデプロイメントモデルでサポートされ、有効化されます

1.1

すべてのデプロイメントモデルでサポートされ、有効化されます
## [](#tlscontext-要素)tls:context 要素 `tls:context`​ 要素は、TLS をサポートするすべてのコネクタで使用します。たとえば、TLS は HTTP (サーバーとクライアント)、FTPS (クライアント)、メール (クライアント)、またはソケット (クライアント) などのコネクタで設定できます。

コネクタで TLS がサポートされる場合、Studio には次のいずれかが表示されます。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[TLS/SSL]​ タブ。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[General (一般)]​ タブの ​[TLS Configuration (TLS 設定)]​ 項目。
## [](#tls-対応のサーバーとクライアント)TLS 対応のサーバーとクライアント TLS 対応のサーバーには、非公開鍵と公開証明書が含まれます。 - 非公開鍵はサーバーの外部には送信されません。 - 公開証明書は TLS 経由で公開されます。 TLS 対応クライアントは、自身が保管する信頼済みの証明書を使用して公開証明書を検証することで、サーバーが信頼できるかどうかを確認します。 Mule 4 で TLS 通信セキュリティを使用するには、証明書と非公開鍵をキーストアファイルにインポートします。トラストストアファイルは、慣例として信頼済みのサーバー公開証明書のみが格納されるキーストアでもあります。 標準 JRE 配布には、デフォルトの Java トラストストアはありますが、デフォルトの Java キーストアはありません。自身のキーストアを TLS コンテキストに追加してください。すでにクライアントアプリケーション用に企業の証明書があれば、新たに作成する必要はありません。これらの証明書の多くは JRE トラストストアでも使用できるため、その場合は TLS コンテキストでのセットアップは不要です。 証明書は、よく知られた証明書機関 (CA) が生成するか、またはユーザーが外部承認なしでローカルに証明書 (自己署名証明書) を生成することができます。トラストストアには、サーバーから提供された証明書をクライアントが検証するために使用する信頼済みの CA があります。 ## [](#キーストアとトラストストア)キーストアとトラストストア Mule 設定の ​`tls:trust-store`​ 要素と ​`tls:key-store`​ 要素は、特定の証明書とキーを参照しますが、​`tls:trust-store`​ の値を指定しないと、Mule はデフォルトの Java トラストストアを参照します。Java を更新するとデフォルトのトラストストアも更新されますので、よく知られた CA 証明書を最新に保つために、定期的な更新をお勧めします。 トラストストアとキーストアは、クライアントとサーバーのどちらで使用するかによってコンテンツが異なります。 - サーバー用: トラストストアには信頼済みのクライアントの証明書、キーストアにはサーバーの非公開鍵と公開鍵が格納されています。 - クライアント用: トラストストアには信頼済みのサーバーの証明書、キーストアにはクライアントの非公開鍵と公開鍵が格納されています。 キーストアとトラストストアの両方を追加すると、相互認証とも呼ばれる両方向の TLS 認証を実装できます。 キーストアには 1 つまたは 2 つのパスワードがあります。 - `password`​ はキーストアファイル全体にアクセスします。 - `keyPassword`​ は、キーストアにあるサーバーの非公開鍵にアクセスします。 ## [](#クライアントの設定)クライアントの設定 `tls:context`​ に空白のトラストストアが定義されている場合は、JVM のデフォルト値 (通常は、すべての主要証明機関の証明書が格納されたトラストストア) が使用されます。次のシナリオを考えてみます。 - トラストストアがインラインで定義されている場合: - トラストストアがグローバル要素を使用して定義されている場合: クライアントが接続しようとしているサーバーからの証明書を必要とする場合は、​`tls:trust-store`​ 要素を追加します。​`path`​ には、信頼済みのサーバーの証明書が格納されているトラストストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する場合は、​`tls:key-store`​ 要素に、クライアントの非公開/公開鍵が格納されたキーストアファイルの場所が設定された ​`path`​ を組み合わせる必要があります。 設定の手順は、​[「Mule 4 での TLS の設定」](#configure-tls-in-mule-4)​を参照してください。 ## [](#サーバーの設定)サーバーの設定 `tls:context`​ には、HTTPS などのセキュアな接続を使用して要求をリスンする ​`tls:key-store`​ 要素を指定する必要があります。​`path`​ には、サーバーの非公開/公開鍵が格納されているキーストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する必要がある場合は、​`tls:trust-store`​ 要素を追加し、信頼済みのクライアントの証明書が格納されたトラストストアファイルの場所を ​`path`​ に設定します。 Mule は、多くのキーストア種別をサポートします。例: - `JCEKS` - `PKCS12` - `JKS` キーストア種別は JRE に指定します。 Mule アプリケーション用に TLS を完全に設定するための手順は次の通りです。 1. Oracle の Java keytool を使用して​[キーストアとトラストストアを生成します](https://docs.mulesoft.com/jp/mule-runtime/4.7/%3C#Generate a Keystore>)​。 2. [Mule でクライアントまたはサーバー用の TLS をグローバルに設定します](https://docs.mulesoft.com/jp/mule-runtime/4.7/%3C#Configure TLS in Mule 4>)​。 3. [省略可能: プロトコルと暗号化スイートを指定します](https://docs.mulesoft.com/jp/mule-runtime/4.7/%3C#Optional: Specify Protocols and Cipher Suites>)​。 ## [](#キーストアの生成)キーストアの生成 標準 JDK 配布には、デフォルトではキーストアが含まれていないため、​`keytool`​ を使用してキーストアおよび証明書を生成します。生成したキーストアには、非公開鍵と公開証明書が格納されます。この証明書は自己署名であるため、クライアントと公開証明書を共有するまでは、クライアントには信頼されません。 ### [](#要件)要件 Java 8 以降のバージョンを使用してキーストアを生成します。別の JDK バージョンを使用すると非互換のキーストアが生成され、Mule アプリケーションがキーストアを読み込もうとすると無効なキーストア形式ランタイムエラーが発生します。 ### [](#キーストアを生成する)キーストアを生成する 次の手順に従い、キーストアを生成して自己署名証明書をエクスポートします。 1. サーバーの証明書を公開するキーストアを生成します。 たとえば、次のいずれかのコマンドを実行します。 keytool -genkey -keyalg RSA -alias -keystore .jks keytool -genkey -alias -keyalg RSA -keystore .jks -storepass ``​ は選択した一意の別名に置き換えます。 ``​ は選択したパスワードに置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 必要に応じて、​`-keyalg RSA`​ の代わりに ​`-keyalg EC`​ を指定して、暗号化アルゴリズムを ECDSA に設定できます。
暗号化アルゴリズムを指定しない場合、ツールではデフォルトで DSA が使用されます。DSA には TLS 1.2 との互換性がないため、Mule アプリケーションで HTTPS 要求を受信すると SSL ハンドシェイクが失敗します。
2. ツールの要求メッセージに応答します。応答例: Enter keystore password: mule123 Re-enter new password: mule123 3. 入力画面に対して他の値を入力します。目的の値を入力します。応答例: What is your first and last name? \[Unknown\]: max What is the name of your organizational unit? \[Unknown\]: MuleSoft What is the name of your organization? \[Unknown\]: MuleSoft Inc What is the name of your City or Locality? \[Unknown\]: San Francisco What is the name of your State or Province? \[Unknown\]: CA What is the two-letter country code for this unit? \[Unknown\]: 01 4. 次の入力画面に対して ​`yes`​ と入力します。 Is CN=max, OU=MuleSoft, O=MuleSoft Inc, L=San Francisco, ST=CA, C=01 correct? \[no\]: yes 5. 次の入力画面に応答します。たとえば、RETURN キーを押して同じパスワードを使用します。 Enter key password for (RETURN if same as keystore password): 6. 公開鍵を認証する自己署名証明書をエクスポートするために次のコマンドを入力します。 keytool -export -alias -keystore .jks -file .cer ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書に使用する名前に置き換えます。 7. 証明書に関連付けられたキーストア用にセットアップしたパスワードを入力します。 Enter keystore password: mule123 ### [](#認証機関による署名を要求する)認証機関による署名を要求する 認証機関 (CA) から証明書への署名を受けるには、次の手順に従います。 1. 証明書を標準 CSR 形式でエクスポートします。そのためには、次のコマンドを実行できます。 keytool -certreq -keystore .jks -alias -file .csr ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書署名要求ファイルに使用する名前に置き換えます。 2. 前のステップで生成された CSR ファイルを認証機関に送信し、手順に従って署名を取得します。 CA の署名を取得したら、次のコマンドを使用して署名済みの証明書ファイルをインポートできます。 keytool -import -keystore .jks -alias -file ``​ は目的の新しい値に置き換えます。定義した別名を既存のキーにリンクさせないでください。リンクさせるとプロセスが失敗します。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は認証機関から受信した署名済み証明書の名前に置き換えます。 1. 証明書を標準 PEM 形式でエクスポートします。最初にキーストア種別を確認してから証明書をエクスポートします。 keytool -list -v -keystore .jks openssl -in .jks -out .key.pem -nocerts -nodes openssl -in .jks -out .crt.pem -nocerts -nodes ``​ はキーストア種別の形式 (PKCS12 など) で新しい目的の値に置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 ``​ は PEM ファイルに使用する名前に置き換えます。 ## [](#トラストストアの生成)トラストストアの生成 標準 JRE 配布には、いくつかの主要証明機関 (CA) の証明書が格納されたデフォルトのトラストストアがあり、デフォルトで tls:trust-store 要素で使用されますが、より強力なセキュリティが必要な場合や、自己署名証明書を使用する場合には、新たにトラストストアを作成できます。 トラストストアは Oracle Java keytool で作成します。 クライアントは、信頼の連鎖 (chain of trust) が確立されることでサーバーを信頼します。信頼の連鎖は、クライアントとサーバーの間で直接 (クライアントのトラストストアにサーバーの証明書が格納されることで) 確立されるか、またはクライアントのトラストストアに証明書が格納されている署名 CA 経由で確立されます。信頼の連鎖が確立されていないと、接続が失敗します。自己署名証明書を使用する場合は、トラストストアを定義する必要があります。 ## [](#mule-4-での-tls-の設定)Mule 4 での TLS の設定 Mule アプリケーションで TLS を有効にするには、次の 3 つの方法のいずれかを使用して Mule XML 設定ファイルで ​`tls:context`​ 要素を設定します。 - [XML ファイルを直接編集する。](https://docs.mulesoft.com/jp/mule-runtime/4.7/%3C#Edit XML to Configure TLS>) - [Anypoint Studio 7 を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.7/%3C#Use Anypoint Studio to Configure TLS>) - [Design Center を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.7/%3C#Use Design Center to Configure TLS>) どの方法を使用する場合でも、​[\[Edit XML to Configure TLS\]](<#Edit XML to Configure TLS>)​の情報を参照して、​`tls:context`​ の属性がどのように機能するのかを理解しておくことをお勧めします。 ### [](#xml-の編集による-tls-の設定)XML の編集による TLS の設定 `tls:context`​ 要素は、Mule アプリケーションで TLS 通信を定義します。特別な要件がない限り、TLS はグローバルに設定して、HTTPS のリスンや送信といった特定の用途に適用してください。 #### [](#tls-要素のグローバル設定)TLS 要素のグローバル設定 `tls:context`​ 要素は、クライアント側とサーバー側の両方から使用できる TLS の設定を定義します。この要素は、他のモジュールの設定オブジェクトから参照したり、いずれかのオブジェクトのネストされた要素として定義したりすることができます。 ネストされた要素を最低 1 つは含めます (key-store と trust-store)。 ```xml ``` #### [](#tls-context-要素の省略可能な属性)`tls-context`​ 要素の省略可能な属性 プロトコルと暗号化スイートを指定して有効にすることができます (省略可能)。 - `enabledProtocols`​: グローバル TLS 設定のプロトコル - `enabledCipherSuites`​: グローバル TLS 設定の暗号化スイート [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.7/%3C#Optional: Specify Protocols and Cipher Suites>)​で説明するように、これらの値は、グローバル TLS 設定で何も指定されていないか、またはこれらの値がグローバル TLS 設定で有効化されている場合に使用されます。 #### [](#trust-store-要素の属性)`trust-store`​ 要素の属性 `path`​ を指定する場合は、​`password`​ 属性が必要です。そうでない場合は省略可能です。 - `path`​: トラストストアが格納されているファイルへのパス - `type`​: トラストストアの種別。デフォルトは JKS - `password`​: トラストストアのパスワード (​`path`​ を指定した場合は必須) - `algorithm`​: トラストストアが使用するアルゴリズム。デフォルトは ​`SunX509` - `insecure`​: トラストストアを検証するかどうかを決定するブール値。​`true`​ に設定すると検証は行われません。デフォルト値は ​`false`​ です。
insecure​ を ​true​ に設定すると、接続が攻撃に対して脆弱になります。この設定は、プロトタイプ開発やテストにおいてのみ使用してください。本番環境では絶対に使用しないでください。
#### [](#key-store-要素の属性)`key-store`​ 要素の属性 `path`​ 以外の属性は省略可能です。 - `path`​: キーストアが格納されているファイルへのパス (必須) - `type`​: キーストアの種別 (デフォルトは JKS) - `password`​: キーストアのパスワード - `keyPassword`​: キーマネージャーのパスワード。キーストア内の非公開鍵のパスワードです - `algorithm`​: キーストアで使用するアルゴリズム。デフォルト値は ​`SunX509`​ です。 ### [](#design-center-を使用して-tls-を設定する)Design Center を使用して TLS を設定する Design Center を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Design Center にログインします。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[Configuration (設定)\] タブで ​**\[Edit (編集)\]**​ をクリックします。 5. \[TLS\] タブで、上記の TLS 設定項目を設定します。 6. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.7/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ### [](#anypoint-studio-を使用して-tls-を設定する)Anypoint Studio を使用して TLS を設定する Anypoint Studio (Studio) を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Studio Center を開きます。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[General (一般)\] タブで、既存の設定を選択するか、または新しい設定を作成します。 5. \[HTTP Listener config (HTTP リスナーの設定)\] ダイアログで、\[TLS\] タブを選択します。 6. \[TLS\] タブの \[TLS Configuration type (TLS 設定種別)\] で ​**\[Edit Inline (インライン編集)\]**​ を選択して、値を入力します。 7. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.7/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、\[Advanced (詳細)\] セクションの ​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ## [](#省略可能-プロトコルと暗号化スイートの指定)省略可能: プロトコルと暗号化スイートの指定 2 つのシステムの間で TLS 通信が行われると、使用するプロトコルと暗号化スイートがネゴシエーションによって決定します。必要に応じて、管理者が使用するプロトコルと暗号化スイートを指定して、アプリケーション開発者がそれらを ​`tls:context`​ で指定することができます。
使用するプロトコルと暗号化スイートは、Mule Runtime と各アプリケーションで有効化しておく必要があります。プロトコルと暗号化スイートが両方の場所で有効化されていないと、Java 環境のデフォルトのプロトコルと暗号化スイートが使用されます。
Mule Runtime でプロトコルと暗号化スイートを設定する手順は次の通りです。 1. Mule 管理者は、​`$MULE_HOME`​ の下にある ​`/conf`​ ディレクトリを編集します。​`$MULE_HOME`​ は、Mule がインストールされているディレクトリを参照します。例: `/opt/mule-4.0`​。暗号化スイートとプロトコルを指定するための適切なファイルを選択します。 - `tls-default.conf`​ は、Mule が Federal Information Processing Standards (FIPS) セキュリティモードで動作するように設定されていない場合に使用します。 - `tls-fips140-2.conf`​ Mule が FIPS セキュリティモードで動作するように設定されている場合に使用します。 関連するファイルを開き、リストの項目をコメントまたはコメント解除することで、使用する暗号化スイートと TLS プロトコルを手動で設定します。これらのファイルを編集しないと、設定されているセキュリティマネージャーが Mule アプリケーション用の暗号化スイートとプロトコルを選択します。 2. これらの設定ファイルで管理者が設定したプロトコルと暗号化スイートのリストは、アプリケーション開発者がそれぞれの ​`tls:context`​ 要素で指定する内容によってローカルに制約できます。アプリケーション開発者は、​`tls:context`​ 要素の設定値またはデフォルト値のサブセットを TLS で使用するように指定します。プロトコルと暗号化スイートは、​`tls:context`​ 要素の ​`enabledProtocols`​ と ​`enabledCipherSuites`​ で指定します。 `tls:context`​ 要素では、Mule グローバル TLS 設定ファイルで指定されているプロトコルまたは暗号化スイート、またはデフォルトのみを参照できます。​`tls:context`​ で、Mule アプリケーション用の ​`enabledProtocols`​ と ​`enabledCipherSuite`​ を ​`default`​ に設定します。これらの値を設定すると、TLS は次のプロトコルと暗号化スイートを使用します。 - グローバル TLS 設定が存在する場合は、指定されているプロトコルと暗号化スイート - グローバル TLS 設定が存在しない場合は、Java 環境のデフォルト 暗号化スイート名は長くなることがあり、XML コードが読みづらくなります。読みやすくするためには、これらの名前を Mule プロジェクトの外部プロパティファイルに格納します。そして、プロパティを参照します。次に例を示します。 ```xml ``` ## [](#デプロイメント後のテストの例)デプロイメント後のテストの例 time curl -i -k --cert ./.crt.pem --cert-type PEM --key ./.key.pem https://: ``​ は定義された値名に置き換えます。 ``​ は Anypoint Platform によって定義された値名に置き換えます。 ``​ は Mule アプリケーションで定義された値名に置き換えます。 ## [](#tls-の設定例)TLS の設定例 TLS は、クライアントまたはサーバー用の Mule XML 設定ファイルでセットアップできます。 ### [](#例-クライアント用の-tls-の設定)例: クライアント用の TLS の設定 次の例では、トラストストアをセットアップすることで FTPS クライアントのセキュリティを確保しています。 ```xml ``` ### [](#例-サーバー用の-tls-の設定)例: サーバー用の TLS の設定 次の例では、キーストアをセットアップすることで HTTP リスナーのセキュリティを確保しています。 ```xml ``` ### [](#例-両方向認証用の-tls-の設定)例: 両方向認証用の TLS の設定 次の例では、HTTP リスナー用に両方向認証 (相互認証) をセットアップしています。 ```xml ``` ### [](#例-tls-検証の無効化)例: TLS 検証の無効化 次の例では、​`insecure`​ プロパティを使用して、プロトタイプ作成と開発で検証を無効化しています。
insecure​ は、本番環境では使用しないでください。
```xml ``` ### [](#例-暗号化スイートとプロトコルの制約の追加)例: 暗号化スイートとプロトコルの制約の追加 次の例では、Mule 管理者がグローバル TLS 設定で何も指定していないか、または暗号化スイートとプロトコルをここで指定できるように有効化してあるという前提で、アプリケーションでプロトコルと暗号化スイートを有効化しています。暗号化スイートには IANA (Internet Assigned Numbers Authority) 命名規則を使用します。 [OpenSSL - IANA マッピング](https://testssl.sh/openssl-iana.mapping.html)​を参照してください。 ```xml ``` ## [](#関連情報)関連情報 - [Oracle のセキュリティ](http://docs.oracle.com/javase/8/docs/technotes/tools/#security) - [Oracle Java keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) # キーストアとトラストストアを使用した TLS の設定 TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。TLS には、認証鍵をエクスチェンジし、データを暗号化し、メッセージの整合性を保証するための多くの方法があります。このトピックでは、Mule が TLS をどのようにサポートするか、そして Mule アプリケーションで TLS をどのように設定するかについて説明します。 ## [](#tls_compatibility)TLS 互換性マトリックス TLS との互換性は、Mule デプロイメントモデルと TLS バージョンによって異なります。
TLS バージョン オンプレミス CloudHub Anypoint Runtime Fabric

1.3

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされますが、デフォルトでは​有効化されていません

このデプロイメントモデルでホストされている Mule アプリケーションでサポートされます

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされ、有効化されます

1.2

すべてのデプロイメントモデルでサポートされ、有効化されます

1.1

すべてのデプロイメントモデルでサポートされ、有効化されます
## [](#tlscontext-要素)tls:context 要素 `tls:context`​ 要素は、TLS をサポートするすべてのコネクタで使用します。たとえば、TLS は HTTP (サーバーとクライアント)、FTPS (クライアント)、メール (クライアント)、またはソケット (クライアント) などのコネクタで設定できます。

コネクタで TLS がサポートされる場合、Studio には次のいずれかが表示されます。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[TLS/SSL]​ タブ。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[General (一般)]​ タブの ​[TLS Configuration (TLS 設定)]​ 項目。
## [](#tls-対応のサーバーとクライアント)TLS 対応のサーバーとクライアント TLS 対応のサーバーには、非公開鍵と公開証明書が含まれます。 - 非公開鍵はサーバーの外部には送信されません。 - 公開証明書は TLS 経由で公開されます。 TLS 対応クライアントは、自身が保管する信頼済みの証明書を使用して公開証明書を検証することで、サーバーが信頼できるかどうかを確認します。 Mule 4 で TLS 通信セキュリティを使用するには、証明書と非公開鍵をキーストアファイルにインポートします。トラストストアファイルは、慣例として信頼済みのサーバー公開証明書のみが格納されるキーストアでもあります。 標準 JRE 配布には、デフォルトの Java トラストストアはありますが、デフォルトの Java キーストアはありません。自身のキーストアを TLS コンテキストに追加してください。すでにクライアントアプリケーション用に企業の証明書があれば、新たに作成する必要はありません。これらの証明書の多くは JRE トラストストアでも使用できるため、その場合は TLS コンテキストでのセットアップは不要です。 証明書は、よく知られた証明書機関 (CA) が生成するか、またはユーザーが外部承認なしでローカルに証明書 (自己署名証明書) を生成することができます。トラストストアには、サーバーから提供された証明書をクライアントが検証するために使用する信頼済みの CA があります。 ## [](#キーストアとトラストストア)キーストアとトラストストア Mule 設定の ​`tls:trust-store`​ 要素と ​`tls:key-store`​ 要素は、特定の証明書とキーを参照しますが、​`tls:trust-store`​ の値を指定しないと、Mule はデフォルトの Java トラストストアを参照します。Java を更新するとデフォルトのトラストストアも更新されますので、よく知られた CA 証明書を最新に保つために、定期的な更新をお勧めします。 トラストストアとキーストアは、クライアントとサーバーのどちらで使用するかによってコンテンツが異なります。 - サーバー用: トラストストアには信頼済みのクライアントの証明書、キーストアにはサーバーの非公開鍵と公開鍵が格納されています。 - クライアント用: トラストストアには信頼済みのサーバーの証明書、キーストアにはクライアントの非公開鍵と公開鍵が格納されています。 キーストアとトラストストアの両方を追加すると、相互認証とも呼ばれる両方向の TLS 認証を実装できます。 キーストアには 1 つまたは 2 つのパスワードがあります。 - `password`​ はキーストアファイル全体にアクセスします。 - `keyPassword`​ は、キーストアにあるサーバーの非公開鍵にアクセスします。 ## [](#クライアントの設定)クライアントの設定 `tls:context`​ に空白のトラストストアが定義されている場合は、JVM のデフォルト値 (通常は、すべての主要証明機関の証明書が格納されたトラストストア) が使用されます。次のシナリオを考えてみます。 - トラストストアがインラインで定義されている場合: - トラストストアがグローバル要素を使用して定義されている場合: クライアントが接続しようとしているサーバーからの証明書を必要とする場合は、​`tls:trust-store`​ 要素を追加します。​`path`​ には、信頼済みのサーバーの証明書が格納されているトラストストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する場合は、​`tls:key-store`​ 要素に、クライアントの非公開/公開鍵が格納されたキーストアファイルの場所が設定された ​`path`​ を組み合わせる必要があります。 設定の手順は、​[「Mule 4 での TLS の設定」](#configure-tls-in-mule-4)​を参照してください。 ## [](#サーバーの設定)サーバーの設定 `tls:context`​ には、HTTPS などのセキュアな接続を使用して要求をリスンする ​`tls:key-store`​ 要素を指定する必要があります。​`path`​ には、サーバーの非公開/公開鍵が格納されているキーストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する必要がある場合は、​`tls:trust-store`​ 要素を追加し、信頼済みのクライアントの証明書が格納されたトラストストアファイルの場所を ​`path`​ に設定します。 Mule は、多くのキーストア種別をサポートします。例: - `JCEKS` - `PKCS12` - `JKS` キーストア種別は JRE に指定します。 Mule アプリケーション用に TLS を完全に設定するための手順は次の通りです。 1. Oracle の Java keytool を使用して​[キーストアとトラストストアを生成します](https://docs.mulesoft.com/jp/mule-runtime/4.8/%3C#Generate a Keystore>)​。 2. [Mule でクライアントまたはサーバー用の TLS をグローバルに設定します](https://docs.mulesoft.com/jp/mule-runtime/4.8/%3C#Configure TLS in Mule 4>)​。 3. [省略可能: プロトコルと暗号化スイートを指定します](https://docs.mulesoft.com/jp/mule-runtime/4.8/%3C#Optional: Specify Protocols and Cipher Suites>)​。 ## [](#キーストアの生成)キーストアの生成 標準 JDK 配布には、デフォルトではキーストアが含まれていないため、​`keytool`​ を使用してキーストアおよび証明書を生成します。生成したキーストアには、非公開鍵と公開証明書が格納されます。この証明書は自己署名であるため、クライアントと公開証明書を共有するまでは、クライアントには信頼されません。 ### [](#要件)要件 Java 8 以降のバージョンを使用してキーストアを生成します。別の JDK バージョンを使用すると非互換のキーストアが生成され、Mule アプリケーションがキーストアを読み込もうとすると無効なキーストア形式ランタイムエラーが発生します。 ### [](#キーストアを生成する)キーストアを生成する 次の手順に従い、キーストアを生成して自己署名証明書をエクスポートします。 1. サーバーの証明書を公開するキーストアを生成します。 たとえば、次のいずれかのコマンドを実行します。 keytool -genkey -keyalg RSA -alias -keystore .jks keytool -genkey -alias -keyalg RSA -keystore .jks -storepass ``​ は選択した一意の別名に置き換えます。 ``​ は選択したパスワードに置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 必要に応じて、​`-keyalg RSA`​ の代わりに ​`-keyalg EC`​ を指定して、暗号化アルゴリズムを ECDSA に設定できます。
暗号化アルゴリズムを指定しない場合、ツールではデフォルトで DSA が使用されます。DSA には TLS 1.2 との互換性がないため、Mule アプリケーションで HTTPS 要求を受信すると SSL ハンドシェイクが失敗します。
2. ツールの要求メッセージに応答します。応答例: Enter keystore password: mule123 Re-enter new password: mule123 3. 入力画面に対して他の値を入力します。目的の値を入力します。応答例: What is your first and last name? \[Unknown\]: max What is the name of your organizational unit? \[Unknown\]: MuleSoft What is the name of your organization? \[Unknown\]: MuleSoft Inc What is the name of your City or Locality? \[Unknown\]: San Francisco What is the name of your State or Province? \[Unknown\]: CA What is the two-letter country code for this unit? \[Unknown\]: 01 4. 次の入力画面に対して ​`yes`​ と入力します。 Is CN=max, OU=MuleSoft, O=MuleSoft Inc, L=San Francisco, ST=CA, C=01 correct? \[no\]: yes 5. 次の入力画面に応答します。たとえば、RETURN キーを押して同じパスワードを使用します。 Enter key password for (RETURN if same as keystore password): 6. 公開鍵を認証する自己署名証明書をエクスポートするために次のコマンドを入力します。 keytool -export -alias -keystore .jks -file .cer ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書に使用する名前に置き換えます。 7. 証明書に関連付けられたキーストア用にセットアップしたパスワードを入力します。 Enter keystore password: mule123 ### [](#認証機関による署名を要求する)認証機関による署名を要求する 認証機関 (CA) から証明書への署名を受けるには、次の手順に従います。 1. 証明書を標準 CSR 形式でエクスポートします。そのためには、次のコマンドを実行できます。 keytool -certreq -keystore .jks -alias -file .csr ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書署名要求ファイルに使用する名前に置き換えます。 2. 前のステップで生成された CSR ファイルを認証機関に送信し、手順に従って署名を取得します。 CA の署名を取得したら、次のコマンドを使用して署名済みの証明書ファイルをインポートできます。 keytool -import -keystore .jks -alias -file ``​ は目的の新しい値に置き換えます。定義した別名を既存のキーにリンクさせないでください。リンクさせるとプロセスが失敗します。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は認証機関から受信した署名済み証明書の名前に置き換えます。 1. 証明書を標準 PEM 形式でエクスポートします。最初にキーストア種別を確認してから証明書をエクスポートします。 keytool -list -v -keystore .jks openssl -in .jks -out .key.pem -nocerts -nodes openssl -in .jks -out .crt.pem -nocerts -nodes ``​ はキーストア種別の形式 (PKCS12 など) で新しい目的の値に置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 ``​ は PEM ファイルに使用する名前に置き換えます。 ## [](#トラストストアの生成)トラストストアの生成 標準 JRE 配布には、いくつかの主要証明機関 (CA) の証明書が格納されたデフォルトのトラストストアがあり、デフォルトで tls:trust-store 要素で使用されますが、より強力なセキュリティが必要な場合や、自己署名証明書を使用する場合には、新たにトラストストアを作成できます。 トラストストアは Oracle Java keytool で作成します。 クライアントは、信頼の連鎖 (chain of trust) が確立されることでサーバーを信頼します。信頼の連鎖は、クライアントとサーバーの間で直接 (クライアントのトラストストアにサーバーの証明書が格納されることで) 確立されるか、またはクライアントのトラストストアに証明書が格納されている署名 CA 経由で確立されます。信頼の連鎖が確立されていないと、接続が失敗します。自己署名証明書を使用する場合は、トラストストアを定義する必要があります。 ## [](#mule-4-での-tls-の設定)Mule 4 での TLS の設定 Mule アプリケーションで TLS を有効にするには、次の 3 つの方法のいずれかを使用して Mule XML 設定ファイルで ​`tls:context`​ 要素を設定します。 - [XML ファイルを直接編集する。](https://docs.mulesoft.com/jp/mule-runtime/4.8/%3C#Edit XML to Configure TLS>) - [Anypoint Studio 7 を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.8/%3C#Use Anypoint Studio to Configure TLS>) - [Design Center を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.8/%3C#Use Design Center to Configure TLS>) どの方法を使用する場合でも、​[\[Edit XML to Configure TLS\]](<#Edit XML to Configure TLS>)​の情報を参照して、​`tls:context`​ の属性がどのように機能するのかを理解しておくことをお勧めします。 ### [](#xml-の編集による-tls-の設定)XML の編集による TLS の設定 `tls:context`​ 要素は、Mule アプリケーションで TLS 通信を定義します。特別な要件がない限り、TLS はグローバルに設定して、HTTPS のリスンや送信といった特定の用途に適用してください。 #### [](#tls-要素のグローバル設定)TLS 要素のグローバル設定 `tls:context`​ 要素は、クライアント側とサーバー側の両方から使用できる TLS の設定を定義します。この要素は、他のモジュールの設定オブジェクトから参照したり、いずれかのオブジェクトのネストされた要素として定義したりすることができます。 ネストされた要素を最低 1 つは含めます (key-store と trust-store)。 ```xml ``` #### [](#tls-context-要素の省略可能な属性)`tls-context`​ 要素の省略可能な属性 プロトコルと暗号化スイートを指定して有効にすることができます (省略可能)。 - `enabledProtocols`​: グローバル TLS 設定のプロトコル - `enabledCipherSuites`​: グローバル TLS 設定の暗号化スイート [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.8/%3C#Optional: Specify Protocols and Cipher Suites>)​で説明するように、これらの値は、グローバル TLS 設定で何も指定されていないか、またはこれらの値がグローバル TLS 設定で有効化されている場合に使用されます。 #### [](#trust-store-要素の属性)`trust-store`​ 要素の属性 `path`​ を指定する場合は、​`password`​ 属性が必要です。そうでない場合は省略可能です。 - `path`​: トラストストアが格納されているファイルへのパス - `type`​: トラストストアの種別。デフォルトは JKS - `password`​: トラストストアのパスワード (​`path`​ を指定した場合は必須) - `algorithm`​: トラストストアが使用するアルゴリズム。デフォルトは ​`SunX509` - `insecure`​: トラストストアを検証するかどうかを決定するブール値。​`true`​ に設定すると検証は行われません。デフォルト値は ​`false`​ です。
insecure​ を ​true​ に設定すると、接続が攻撃に対して脆弱になります。この設定は、プロトタイプ開発やテストにおいてのみ使用してください。本番環境では絶対に使用しないでください。
#### [](#key-store-要素の属性)`key-store`​ 要素の属性 `path`​ 以外の属性は省略可能です。 - `path`​: キーストアが格納されているファイルへのパス (必須) - `type`​: キーストアの種別 (デフォルトは JKS) - `password`​: キーストアのパスワード - `keyPassword`​: キーマネージャーのパスワード。キーストア内の非公開鍵のパスワードです - `algorithm`​: キーストアで使用するアルゴリズム。デフォルト値は ​`SunX509`​ です。 ### [](#design-center-を使用して-tls-を設定する)Design Center を使用して TLS を設定する Design Center を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Design Center にログインします。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[Configuration (設定)\] タブで ​**\[Edit (編集)\]**​ をクリックします。 5. \[TLS\] タブで、上記の TLS 設定項目を設定します。 6. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.8/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ### [](#anypoint-studio-を使用して-tls-を設定する)Anypoint Studio を使用して TLS を設定する Anypoint Studio (Studio) を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Studio Center を開きます。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[General (一般)\] タブで、既存の設定を選択するか、または新しい設定を作成します。 5. \[HTTP Listener config (HTTP リスナーの設定)\] ダイアログで、\[TLS\] タブを選択します。 6. \[TLS\] タブの \[TLS Configuration type (TLS 設定種別)\] で ​**\[Edit Inline (インライン編集)\]**​ を選択して、値を入力します。 7. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.8/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、\[Advanced (詳細)\] セクションの ​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ## [](#省略可能-プロトコルと暗号化スイートの指定)省略可能: プロトコルと暗号化スイートの指定 2 つのシステムの間で TLS 通信が行われると、使用するプロトコルと暗号化スイートがネゴシエーションによって決定します。必要に応じて、管理者が使用するプロトコルと暗号化スイートを指定して、アプリケーション開発者がそれらを ​`tls:context`​ で指定することができます。
使用するプロトコルと暗号化スイートは、Mule Runtime と各アプリケーションで有効化しておく必要があります。プロトコルと暗号化スイートが両方の場所で有効化されていないと、Java 環境のデフォルトのプロトコルと暗号化スイートが使用されます。
Mule Runtime でプロトコルと暗号化スイートを設定する手順は次の通りです。 1. Mule 管理者は、​`$MULE_HOME`​ の下にある ​`/conf`​ ディレクトリを編集します。​`$MULE_HOME`​ は、Mule がインストールされているディレクトリを参照します。例: `/opt/mule-4.0`​。暗号化スイートとプロトコルを指定するための適切なファイルを選択します。 - `tls-default.conf`​ は、Mule が Federal Information Processing Standards (FIPS) セキュリティモードで動作するように設定されていない場合に使用します。 - `tls-fips140-2.conf`​ Mule が FIPS セキュリティモードで動作するように設定されている場合に使用します。 関連するファイルを開き、リストの項目をコメントまたはコメント解除することで、使用する暗号化スイートと TLS プロトコルを手動で設定します。これらのファイルを編集しないと、設定されているセキュリティマネージャーが Mule アプリケーション用の暗号化スイートとプロトコルを選択します。 2. これらの設定ファイルで管理者が設定したプロトコルと暗号化スイートのリストは、アプリケーション開発者がそれぞれの ​`tls:context`​ 要素で指定する内容によってローカルに制約できます。アプリケーション開発者は、​`tls:context`​ 要素の設定値またはデフォルト値のサブセットを TLS で使用するように指定します。プロトコルと暗号化スイートは、​`tls:context`​ 要素の ​`enabledProtocols`​ と ​`enabledCipherSuites`​ で指定します。 `tls:context`​ 要素では、Mule グローバル TLS 設定ファイルで指定されているプロトコルまたは暗号化スイート、またはデフォルトのみを参照できます。​`tls:context`​ で、Mule アプリケーション用の ​`enabledProtocols`​ と ​`enabledCipherSuite`​ を ​`default`​ に設定します。これらの値を設定すると、TLS は次のプロトコルと暗号化スイートを使用します。 - グローバル TLS 設定が存在する場合は、指定されているプロトコルと暗号化スイート - グローバル TLS 設定が存在しない場合は、Java 環境のデフォルト 暗号化スイート名は長くなることがあり、XML コードが読みづらくなります。読みやすくするためには、これらの名前を Mule プロジェクトの外部プロパティファイルに格納します。そして、プロパティを参照します。次に例を示します。 ```xml ``` ## [](#デプロイメント後のテストの例)デプロイメント後のテストの例 time curl -i -k --cert ./.crt.pem --cert-type PEM --key ./.key.pem https://: ``​ は定義された値名に置き換えます。 ``​ は Anypoint Platform によって定義された値名に置き換えます。 ``​ は Mule アプリケーションで定義された値名に置き換えます。 ## [](#tls-の設定例)TLS の設定例 TLS は、クライアントまたはサーバー用の Mule XML 設定ファイルでセットアップできます。 ### [](#例-クライアント用の-tls-の設定)例: クライアント用の TLS の設定 次の例では、トラストストアをセットアップすることで FTPS クライアントのセキュリティを確保しています。 ```xml ``` ### [](#例-サーバー用の-tls-の設定)例: サーバー用の TLS の設定 次の例では、キーストアをセットアップすることで HTTP リスナーのセキュリティを確保しています。 ```xml ``` ### [](#例-両方向認証用の-tls-の設定)例: 両方向認証用の TLS の設定 次の例では、HTTP リスナー用に両方向認証 (相互認証) をセットアップしています。 ```xml ``` ### [](#例-tls-検証の無効化)例: TLS 検証の無効化 次の例では、​`insecure`​ プロパティを使用して、プロトタイプ作成と開発で検証を無効化しています。
insecure​ は、本番環境では使用しないでください。
```xml ``` ### [](#例-暗号化スイートとプロトコルの制約の追加)例: 暗号化スイートとプロトコルの制約の追加 次の例では、Mule 管理者がグローバル TLS 設定で何も指定していないか、または暗号化スイートとプロトコルをここで指定できるように有効化してあるという前提で、アプリケーションでプロトコルと暗号化スイートを有効化しています。暗号化スイートには IANA (Internet Assigned Numbers Authority) 命名規則を使用します。 [OpenSSL - IANA マッピング](https://testssl.sh/openssl-iana.mapping.html)​を参照してください。 ```xml ``` ## [](#関連情報)関連情報 - [Oracle のセキュリティ](http://docs.oracle.com/javase/8/docs/technotes/tools/#security) - [Oracle Java keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) # キーストアとトラストストアを使用した TLS の設定 TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。TLS には、認証鍵をエクスチェンジし、データを暗号化し、メッセージの整合性を保証するための多くの方法があります。このトピックでは、Mule が TLS をどのようにサポートするか、そして Mule アプリケーションで TLS をどのように設定するかについて説明します。 ## [](#tls_compatibility)TLS 互換性マトリックス TLS との互換性は、Mule デプロイメントモデルと TLS バージョンによって異なります。
TLS バージョン オンプレミス CloudHub Anypoint Runtime Fabric

1.3

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされますが、デフォルトでは​有効化されていません

このデプロイメントモデルでホストされている Mule アプリケーションでサポートされます

TLS 1.3 をサポートする JDK 上で Mule を実行する場合にサポートされ、有効化されます

1.2

すべてのデプロイメントモデルでサポートされ、有効化されます

1.1

すべてのデプロイメントモデルでサポートされ、有効化されます
## [](#tlscontext-要素)tls:context 要素 `tls:context`​ 要素は、TLS をサポートするすべてのコネクタで使用します。たとえば、TLS は HTTP (サーバーとクライアント)、FTPS (クライアント)、メール (クライアント)、またはソケット (クライアント) などのコネクタで設定できます。

コネクタで TLS がサポートされる場合、Studio には次のいずれかが表示されます。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[TLS/SSL]​ タブ。

  • そのコネクタの [Global Element Properties (グローバル要素のプロパティ)] の ​[General (一般)]​ タブの ​[TLS Configuration (TLS 設定)]​ 項目。
## [](#tls-対応のサーバーとクライアント)TLS 対応のサーバーとクライアント TLS 対応のサーバーには、非公開鍵と公開証明書が含まれます。 - 非公開鍵はサーバーの外部には送信されません。 - 公開証明書は TLS 経由で公開されます。 TLS 対応クライアントは、自身が保管する信頼済みの証明書を使用して公開証明書を検証することで、サーバーが信頼できるかどうかを確認します。 Mule 4 で TLS 通信セキュリティを使用するには、証明書と非公開鍵をキーストアファイルにインポートします。トラストストアファイルは、慣例として信頼済みのサーバー公開証明書のみが格納されるキーストアでもあります。 標準 JRE 配布には、デフォルトの Java トラストストアはありますが、デフォルトの Java キーストアはありません。自身のキーストアを TLS コンテキストに追加してください。すでにクライアントアプリケーション用に企業の証明書があれば、新たに作成する必要はありません。これらの証明書の多くは JRE トラストストアでも使用できるため、その場合は TLS コンテキストでのセットアップは不要です。 証明書は、よく知られた証明書機関 (CA) が生成するか、またはユーザーが外部承認なしでローカルに証明書 (自己署名証明書) を生成することができます。トラストストアには、サーバーから提供された証明書をクライアントが検証するために使用する信頼済みの CA があります。 ## [](#キーストアとトラストストア)キーストアとトラストストア Mule 設定の ​`tls:trust-store`​ 要素と ​`tls:key-store`​ 要素は、特定の証明書とキーを参照しますが、​`tls:trust-store`​ の値を指定しないと、Mule はデフォルトの Java トラストストアを参照します。Java を更新するとデフォルトのトラストストアも更新されますので、よく知られた CA 証明書を最新に保つために、定期的な更新をお勧めします。 トラストストアとキーストアは、クライアントとサーバーのどちらで使用するかによってコンテンツが異なります。 - サーバー用: トラストストアには信頼済みのクライアントの証明書、キーストアにはサーバーの非公開鍵と公開鍵が格納されています。 - クライアント用: トラストストアには信頼済みのサーバーの証明書、キーストアにはクライアントの非公開鍵と公開鍵が格納されています。 キーストアとトラストストアの両方を追加すると、相互認証とも呼ばれる両方向の TLS 認証を実装できます。 キーストアには 1 つまたは 2 つのパスワードがあります。 - `password`​ はキーストアファイル全体にアクセスします。 - `keyPassword`​ は、キーストアにあるサーバーの非公開鍵にアクセスします。 ## [](#クライアントの設定)クライアントの設定 `tls:context`​ に空白のトラストストアが定義されている場合は、JVM のデフォルト値 (通常は、すべての主要証明機関の証明書が格納されたトラストストア) が使用されます。次のシナリオを考えてみます。 - トラストストアがインラインで定義されている場合: - トラストストアがグローバル要素を使用して定義されている場合: クライアントが接続しようとしているサーバーからの証明書を必要とする場合は、​`tls:trust-store`​ 要素を追加します。​`path`​ には、信頼済みのサーバーの証明書が格納されているトラストストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する場合は、​`tls:key-store`​ 要素に、クライアントの非公開/公開鍵が格納されたキーストアファイルの場所が設定された ​`path`​ を組み合わせる必要があります。 設定の手順は、​[「Mule 4 での TLS の設定」](#configure-tls-in-mule-4)​を参照してください。 ## [](#サーバーの設定)サーバーの設定 `tls:context`​ には、HTTPS などのセキュアな接続を使用して要求をリスンする ​`tls:key-store`​ 要素を指定する必要があります。​`path`​ には、サーバーの非公開/公開鍵が格納されているキーストアファイルの場所を設定します。 サーバーがクライアントからの証明書を検証する必要がある場合は、​`tls:trust-store`​ 要素を追加し、信頼済みのクライアントの証明書が格納されたトラストストアファイルの場所を ​`path`​ に設定します。 Mule は、多くのキーストア種別をサポートします。例: - `JCEKS` - `PKCS12` - `JKS` キーストア種別は JRE に指定します。 Mule アプリケーション用に TLS を完全に設定するための手順は次の通りです。 1. Oracle の Java keytool を使用して​[キーストアとトラストストアを生成します](https://docs.mulesoft.com/jp/mule-runtime/4.9/%3C#Generate a Keystore>)​。 2. [Mule でクライアントまたはサーバー用の TLS をグローバルに設定します](https://docs.mulesoft.com/jp/mule-runtime/4.9/%3C#Configure TLS in Mule 4>)​。 3. [省略可能: プロトコルと暗号化スイートを指定します](https://docs.mulesoft.com/jp/mule-runtime/4.9/%3C#Optional: Specify Protocols and Cipher Suites>)​。 ## [](#キーストアの生成)キーストアの生成 標準 JDK 配布には、デフォルトではキーストアが含まれていないため、​`keytool`​ を使用してキーストアおよび証明書を生成します。生成したキーストアには、非公開鍵と公開証明書が格納されます。この証明書は自己署名であるため、クライアントと公開証明書を共有するまでは、クライアントには信頼されません。 ### [](#要件)要件 Java 17 を使用してキーストアを生成します。別の JDK バージョンを使用すると非互換のキーストアが生成され、Mule アプリケーションがキーストアを読み込もうとすると無効なキーストア形式ランタイムエラーが発生します。 ### [](#キーストアを生成する)キーストアを生成する 次の手順に従い、キーストアを生成して自己署名証明書をエクスポートします。 1. サーバーの証明書を公開するキーストアを生成します。 たとえば、次のいずれかのコマンドを実行します。 keytool -genkey -keyalg RSA -alias -keystore .jks keytool -genkey -alias -keyalg RSA -keystore .jks -storepass ``​ は選択した一意の別名に置き換えます。 ``​ は選択したパスワードに置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 必要に応じて、​`-keyalg RSA`​ の代わりに ​`-keyalg EC`​ を指定して、暗号化アルゴリズムを ECDSA に設定できます。
暗号化アルゴリズムを指定しない場合、ツールではデフォルトで DSA が使用されます。DSA には TLS 1.2 との互換性がないため、Mule アプリケーションで HTTPS 要求を受信すると SSL ハンドシェイクが失敗します。
2. ツールの要求メッセージに応答します。応答例: Enter keystore password: mule123 Re-enter new password: mule123 3. 入力画面に対して他の値を入力します。目的の値を入力します。応答例: What is your first and last name? \[Unknown\]: max What is the name of your organizational unit? \[Unknown\]: MuleSoft What is the name of your organization? \[Unknown\]: MuleSoft Inc What is the name of your City or Locality? \[Unknown\]: San Francisco What is the name of your State or Province? \[Unknown\]: CA What is the two-letter country code for this unit? \[Unknown\]: 01 4. 次の入力画面に対して ​`yes`​ と入力します。 Is CN=max, OU=MuleSoft, O=MuleSoft Inc, L=San Francisco, ST=CA, C=01 correct? \[no\]: yes 5. 次の入力画面に応答します。たとえば、RETURN キーを押して同じパスワードを使用します。 Enter key password for (RETURN if same as keystore password): 6. 公開鍵を認証する自己署名証明書をエクスポートするために次のコマンドを入力します。 keytool -export -alias -keystore .jks -file .cer ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書に使用する名前に置き換えます。 7. 証明書に関連付けられたキーストア用にセットアップしたパスワードを入力します。 Enter keystore password: mule123 ### [](#認証機関による署名を要求する)認証機関による署名を要求する 認証機関 (CA) から証明書への署名を受けるには、次の手順に従います。 1. 証明書を標準 CSR 形式でエクスポートします。そのためには、次のコマンドを実行できます。 keytool -certreq -keystore .jks -alias -file .csr ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は証明書署名要求ファイルに使用する名前に置き換えます。 2. 前のステップで生成された CSR ファイルを認証機関に送信し、手順に従って署名を取得します。 CA の署名を取得したら、次のコマンドを使用して署名済みの証明書ファイルをインポートできます。 keytool -import -keystore .jks -alias -file ``​ は目的の新しい値に置き換えます。定義した別名を既存のキーにリンクさせないでください。リンクさせるとプロセスが失敗します。 ``​ は前のステップで使用したのと同じ値に置き換えます。 ``​ は認証機関から受信した署名済み証明書の名前に置き換えます。 1. 証明書を標準 PEM 形式でエクスポートします。最初にキーストア種別を確認してから証明書をエクスポートします。 keytool -list -v -keystore .jks openssl -in .jks -out .key.pem -nocerts -nodes openssl -in .jks -out .crt.pem -nocerts -nodes ``​ はキーストア種別の形式 (PKCS12 など) で新しい目的の値に置き換えます。 ``​ はキーストアに使用する名前に置き換えます。 ``​ は PEM ファイルに使用する名前に置き換えます。 ## [](#トラストストアの生成)トラストストアの生成 標準 JRE 配布には、いくつかの主要証明機関 (CA) の証明書が格納されたデフォルトのトラストストアがあり、デフォルトで tls:trust-store 要素で使用されますが、より強力なセキュリティが必要な場合や、自己署名証明書を使用する場合には、新たにトラストストアを作成できます。 トラストストアは Oracle Java keytool で作成します。 クライアントは、信頼の連鎖 (chain of trust) が確立されることでサーバーを信頼します。信頼の連鎖は、クライアントとサーバーの間で直接 (クライアントのトラストストアにサーバーの証明書が格納されることで) 確立されるか、またはクライアントのトラストストアに証明書が格納されている署名 CA 経由で確立されます。信頼の連鎖が確立されていないと、接続が失敗します。自己署名証明書を使用する場合は、トラストストアを定義する必要があります。 ## [](#mule-4-での-tls-の設定)Mule 4 での TLS の設定 Mule アプリケーションで TLS を有効にするには、次の 3 つの方法のいずれかを使用して Mule XML 設定ファイルで ​`tls:context`​ 要素を設定します。 - [XML ファイルを直接編集する。](https://docs.mulesoft.com/jp/mule-runtime/4.9/%3C#Edit XML to Configure TLS>) - [Anypoint Studio 7 を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.9/%3C#Use Anypoint Studio to Configure TLS>) - [Design Center を使用する。](https://docs.mulesoft.com/jp/mule-runtime/4.9/%3C#Use Design Center to Configure TLS>) どの方法を使用する場合でも、​[\[Edit XML to Configure TLS\]](<#Edit XML to Configure TLS>)​の情報を参照して、​`tls:context`​ の属性がどのように機能するのかを理解しておくことをお勧めします。 ### [](#xml-の編集による-tls-の設定)XML の編集による TLS の設定 `tls:context`​ 要素は、Mule アプリケーションで TLS 通信を定義します。特別な要件がない限り、TLS はグローバルに設定して、HTTPS のリスンや送信といった特定の用途に適用してください。 #### [](#tls-要素のグローバル設定)TLS 要素のグローバル設定 `tls:context`​ 要素は、クライアント側とサーバー側の両方から使用できる TLS の設定を定義します。この要素は、他のモジュールの設定オブジェクトから参照したり、いずれかのオブジェクトのネストされた要素として定義したりすることができます。 ネストされた要素を最低 1 つは含めます (key-store と trust-store)。 ```xml ``` #### [](#tls-context-要素の省略可能な属性)`tls-context`​ 要素の省略可能な属性 プロトコルと暗号化スイートを指定して有効にすることができます (省略可能)。 - `enabledProtocols`​: グローバル TLS 設定のプロトコル - `enabledCipherSuites`​: グローバル TLS 設定の暗号化スイート [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.9/%3C#Optional: Specify Protocols and Cipher Suites>)​で説明するように、これらの値は、グローバル TLS 設定で何も指定されていないか、またはこれらの値がグローバル TLS 設定で有効化されている場合に使用されます。 #### [](#trust-store-要素の属性)`trust-store`​ 要素の属性 `path`​ を指定する場合は、​`password`​ 属性が必要です。そうでない場合は省略可能です。 - `path`​: トラストストアが格納されているファイルへのパス - `type`​: トラストストアの種別。デフォルトは JKS - `password`​: トラストストアのパスワード (​`path`​ を指定した場合は必須) - `algorithm`​: トラストストアが使用するアルゴリズム。デフォルトは ​`SunX509` - `insecure`​: トラストストアを検証するかどうかを決定するブール値。​`true`​ に設定すると検証は行われません。デフォルト値は ​`false`​ です。
insecure​ を ​true​ に設定すると、接続が攻撃に対して脆弱になります。この設定は、プロトタイプ開発やテストにおいてのみ使用してください。本番環境では絶対に使用しないでください。
#### [](#key-store-要素の属性)`key-store`​ 要素の属性 `path`​ 以外の属性は省略可能です。 - `path`​: キーストアが格納されているファイルへのパス (必須) - `type`​: キーストアの種別 (デフォルトは JKS) - `password`​: キーストアのパスワード - `keyPassword`​: キーマネージャーのパスワード。キーストア内の非公開鍵のパスワードです - `algorithm`​: キーストアで使用するアルゴリズム。デフォルト値は ​`SunX509`​ です。 ### [](#design-center-を使用して-tls-を設定する)Design Center を使用して TLS を設定する Design Center を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Design Center にログインします。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[Configuration (設定)\] タブで ​**\[Edit (編集)\]**​ をクリックします。 5. \[TLS\] タブで、上記の TLS 設定項目を設定します。 6. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.9/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ### [](#anypoint-studio-を使用して-tls-を設定する)Anypoint Studio を使用して TLS を設定する Anypoint Studio (Studio) を使用してアプリケーション用に TLS を設定できます。たとえば、HTTP リスナー用に TLS を設定する手順は次の通りです。 1. Studio Center を開きます。 2. プロジェクトを開きます。 3. HTTP リスナーを開きます。 4. \[General (一般)\] タブで、既存の設定を選択するか、または新しい設定を作成します。 5. \[HTTP Listener config (HTTP リスナーの設定)\] ダイアログで、\[TLS\] タブを選択します。 6. \[TLS\] タブの \[TLS Configuration type (TLS 設定種別)\] で ​**\[Edit Inline (インライン編集)\]**​ を選択して、値を入力します。 7. [省略可能: プロトコルと暗号化スイートの指定](https://docs.mulesoft.com/jp/mule-runtime/4.9/%3C#Optional: Specify Protocols and Cipher Suites>)​の説明に従って、\[Advanced (詳細)\] セクションの ​**\[Enabled Protocols (有効化されたプロトコル)\]**​ 項目と ​**\[Enabled Cipher Suites (有効化された暗号化スイート)\]**​ 項目を設定します (省略可能)。 設定内容を保存してテストします。 ## [](#省略可能-プロトコルと暗号化スイートの指定)省略可能: プロトコルと暗号化スイートの指定 2 つのシステムの間で TLS 通信が行われると、使用するプロトコルと暗号化スイートがネゴシエーションによって決定します。必要に応じて、管理者が使用するプロトコルと暗号化スイートを指定して、アプリケーション開発者がそれらを ​`tls:context`​ で指定することができます。
使用するプロトコルと暗号化スイートは、Mule Runtime と各アプリケーションで有効化しておく必要があります。プロトコルと暗号化スイートが両方の場所で有効化されていないと、Java 環境のデフォルトのプロトコルと暗号化スイートが使用されます。
Mule Runtime でプロトコルと暗号化スイートを設定する手順は次の通りです。 1. Mule 管理者は、​`$MULE_HOME`​ の下にある ​`/conf`​ ディレクトリを編集します。​`$MULE_HOME`​ は、Mule がインストールされているディレクトリを参照します。例: `/opt/mule-4.0`​。暗号化スイートとプロトコルを指定するための適切なファイルを選択します。 - `tls-default.conf`​ は、Mule が Federal Information Processing Standards (FIPS) セキュリティモードで動作するように設定されていない場合に使用します。 - `tls-fips140-2.conf`​ Mule が FIPS セキュリティモードで動作するように設定されている場合に使用します。 関連するファイルを開き、リストの項目をコメントまたはコメント解除することで、使用する暗号化スイートと TLS プロトコルを手動で設定します。これらのファイルを編集しないと、設定されているセキュリティマネージャーが Mule アプリケーション用の暗号化スイートとプロトコルを選択します。 2. これらの設定ファイルで管理者が設定したプロトコルと暗号化スイートのリストは、アプリケーション開発者がそれぞれの ​`tls:context`​ 要素で指定する内容によってローカルに制約できます。アプリケーション開発者は、​`tls:context`​ 要素の設定値またはデフォルト値のサブセットを TLS で使用するように指定します。プロトコルと暗号化スイートは、​`tls:context`​ 要素の ​`enabledProtocols`​ と ​`enabledCipherSuites`​ で指定します。 `tls:context`​ 要素では、Mule グローバル TLS 設定ファイルで指定されているプロトコルまたは暗号化スイート、またはデフォルトのみを参照できます。​`tls:context`​ で、Mule アプリケーション用の ​`enabledProtocols`​ と ​`enabledCipherSuite`​ を ​`default`​ に設定します。これらの値を設定すると、TLS は次のプロトコルと暗号化スイートを使用します。 - グローバル TLS 設定が存在する場合は、指定されているプロトコルと暗号化スイート - グローバル TLS 設定が存在しない場合は、Java 環境のデフォルト 暗号化スイート名は長くなることがあり、XML コードが読みづらくなります。読みやすくするためには、これらの名前を Mule プロジェクトの外部プロパティファイルに格納します。そして、プロパティを参照します。次に例を示します。 ```xml ``` ## [](#デプロイメント後のテストの例)デプロイメント後のテストの例 time curl -i -k --cert ./.crt.pem --cert-type PEM --key ./.key.pem https://: ``​ は定義された値名に置き換えます。 ``​ は Anypoint Platform によって定義された値名に置き換えます。 ``​ は Mule アプリケーションで定義された値名に置き換えます。 ## [](#tls-の設定例)TLS の設定例 TLS は、クライアントまたはサーバー用の Mule XML 設定ファイルでセットアップできます。 ### [](#例-クライアント用の-tls-の設定)例: クライアント用の TLS の設定 次の例では、トラストストアをセットアップすることで FTPS クライアントのセキュリティを確保しています。 ```xml ``` ### [](#例-サーバー用の-tls-の設定)例: サーバー用の TLS の設定 次の例では、キーストアをセットアップすることで HTTP リスナーのセキュリティを確保しています。 ```xml ``` ### [](#例-両方向認証用の-tls-の設定)例: 両方向認証用の TLS の設定 次の例では、HTTP リスナー用に両方向認証 (相互認証) をセットアップしています。 ```xml ``` ### [](#例-tls-検証の無効化)例: TLS 検証の無効化 次の例では、​`insecure`​ プロパティを使用して、プロトタイプ作成と開発で検証を無効化しています。
insecure​ は、本番環境では使用しないでください。
```xml ``` ### [](#例-暗号化スイートとプロトコルの制約の追加)例: 暗号化スイートとプロトコルの制約の追加 次の例では、Mule 管理者がグローバル TLS 設定で何も指定していないか、または暗号化スイートとプロトコルをここで指定できるように有効化してあるという前提で、アプリケーションでプロトコルと暗号化スイートを有効化しています。暗号化スイートには IANA (Internet Assigned Numbers Authority) 命名規則を使用します。 [OpenSSL - IANA マッピング](https://testssl.sh/openssl-iana.mapping.html)​を参照してください。 ```xml ``` ## [](#関連情報)関連情報 - [Oracle のセキュリティ](http://docs.oracle.com/javase/8/docs/technotes/tools/#security) - [Oracle Java keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html) # キャッシュ キャッシュするタイミングや使用するキャッシュ戦略など、データの主要な側面を見極めることで、処理のパフォーマンスを高めることができます。 - データを呼び出す頻度は高いか? 結果が反復されることが多いか? - データソースとキャッシュ情報の一貫性を維持できるか? 最低でもキャッシュが更新されるまでの間。 Mule Runtime Engine (Mule) では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能な戦略によってニーズに合わせたキャッシュ処理を実現できます。どちらの戦略も、処理負荷、特にリモートホストとのネットワークインタラクションを減らすことで、同じデータを頻繁に要求するアプリケーションに役立ちます。 Cache スコープは、デフォルトのメモリ内キャッシュがメモリリソースをすべてコンシュームしてしまうような本番環境に適しています。これを回避するには、慎重に定義されたストレージポリシーと有効期限ポリシーによるオブジェクトストアキャッシュ設定を使用します。 ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/cache-scope) - [HTTP キャッシュ](https://docs.mulesoft.com/gateway/latest/policies-included-http-caching) # キャッシュ キャッシュするタイミングや使用するキャッシュ戦略など、データの主要な側面を見極めることで、処理のパフォーマンスを高めることができます。 - データを呼び出す頻度は高いか? 結果が反復されることが多いか? - データソースとキャッシュ情報の一貫性を維持できるか? 最低でもキャッシュが更新されるまでの間。 Mule Runtime Engine (Mule) では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能な戦略によってニーズに合わせたキャッシュ処理を実現できます。どちらの戦略も、処理負荷、特にリモートホストとのネットワークインタラクションを減らすことで、同じデータを頻繁に要求するアプリケーションに役立ちます。 Cache スコープは、デフォルトのメモリ内キャッシュがメモリリソースをすべてコンシュームしてしまうような本番環境に適しています。これを回避するには、慎重に定義されたストレージポリシーと有効期限ポリシーによるオブジェクトストアキャッシュ設定を使用します。 ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/cache-scope) - [HTTP キャッシュ](https://docs.mulesoft.com/gateway/latest/policies-included-http-caching) # キャッシュ キャッシュするタイミングや使用するキャッシュ戦略など、データの主要な側面を見極めることで、処理のパフォーマンスを高めることができます。 - データを呼び出す頻度は高いか? 結果が反復されることが多いか? - データソースとキャッシュ情報の一貫性を維持できるか? 最低でもキャッシュが更新されるまでの間。 Mule Runtime Engine (Mule) では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能な戦略によってニーズに合わせたキャッシュ処理を実現できます。どちらの戦略も、処理負荷、特にリモートホストとのネットワークインタラクションを減らすことで、同じデータを頻繁に要求するアプリケーションに役立ちます。 Cache スコープは、デフォルトのメモリ内キャッシュがメモリリソースをすべて消費してしまうような本番環境に適しています。これを回避するには、慎重に定義されたストレージポリシーと有効期限ポリシーによるオブジェクトストアキャッシュ設定を使用します。 ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/cache-scope) - [HTTP キャッシュ](https://docs.mulesoft.com/gateway/latest/policies-included-http-caching) # キャッシュ キャッシュするタイミングや使用するキャッシュ戦略など、データの主要な側面を見極めることで、処理のパフォーマンスを高めることができます。 - データを呼び出す頻度は高いか? 結果が反復されることが多いか? - データソースとキャッシュ情報の一貫性を維持できるか? 最低でもキャッシュが更新されるまでの間。 Mule Runtime Engine (Mule) では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能な戦略によってニーズに合わせたキャッシュ処理を実現できます。どちらの戦略も、処理負荷、特にリモートホストとのネットワークインタラクションを減らすことで、同じデータを頻繁に要求するアプリケーションに役立ちます。 Cache スコープは、デフォルトのメモリ内キャッシュがメモリリソースをすべてコンシュームしてしまうような本番環境に適しています。これを回避するには、慎重に定義されたストレージポリシーと有効期限ポリシーによるオブジェクトストアキャッシュ設定を使用します。 ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/cache-scope) - [HTTP キャッシュ](https://docs.mulesoft.com/gateway/latest/policies-included-http-caching) # キャッシュ キャッシュするタイミングや使用するキャッシュ戦略など、データの主要な側面を見極めることで、処理のパフォーマンスを高めることができます。 - データを呼び出す頻度は高いか? 結果が反復されることが多いか? - データソースとキャッシュ情報の一貫性を維持できるか? 最低でもキャッシュが更新されるまでの間。 Mule Runtime Engine (Mule) では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能な戦略によってニーズに合わせたキャッシュ処理を実現できます。どちらの戦略も、処理負荷、特にリモートホストとのネットワークインタラクションを減らすことで、同じデータを頻繁に要求するアプリケーションに役立ちます。 Cache スコープは、デフォルトのメモリ内キャッシュがメモリリソースをすべてコンシュームしてしまうような本番環境に適しています。これを回避するには、慎重に定義されたストレージポリシーと有効期限ポリシーによるオブジェクトストアキャッシュ設定を使用します。 ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/cache-scope) - [HTTP キャッシュ](https://docs.mulesoft.com/gateway/latest/policies-included-http-caching) # キャッシュ キャッシュするタイミングや使用するキャッシュ戦略など、データの主要な側面を見極めることで、処理のパフォーマンスを高めることができます。 - データを呼び出す頻度は高いか? 結果が反復されることが多いか? - データソースとキャッシュ情報の一貫性を維持できるか? 最低でもキャッシュが更新されるまでの間。 Mule Runtime Engine (Mule) では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能な戦略によってニーズに合わせたキャッシュ処理を実現できます。どちらの戦略も、処理負荷、特にリモートホストとのネットワークインタラクションを減らすことで、同じデータを頻繁に要求するアプリケーションに役立ちます。 Cache スコープは、デフォルトのメモリ内キャッシュがメモリリソースをすべてコンシュームしてしまうような本番環境に適しています。これを回避するには、慎重に定義されたストレージポリシーと有効期限ポリシーによるオブジェクトストアキャッシュ設定を使用します。 ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/cache-scope) - [HTTP キャッシュ](https://docs.mulesoft.com/gateway/latest/policies-included-http-caching) # キャッシュ キャッシュするタイミングや使用するキャッシュ戦略など、データの主要な側面を見極めることで、処理のパフォーマンスを高めることができます。 - データを呼び出す頻度は高いか? 結果が反復されることが多いか? - データソースとキャッシュ情報の一貫性を維持できるか? 最低でもキャッシュが更新されるまでの間。 Mule Runtime Engine (Mule) では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能な戦略によってニーズに合わせたキャッシュ処理を実現できます。どちらの戦略も、処理負荷、特にリモートホストとのネットワークインタラクションを減らすことで、同じデータを頻繁に要求するアプリケーションに役立ちます。 Cache スコープは、デフォルトのメモリ内キャッシュがメモリリソースをすべてコンシュームしてしまうような本番環境に適しています。これを回避するには、慎重に定義されたストレージポリシーと有効期限ポリシーによるオブジェクトストアキャッシュ設定を使用します。 ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/cache-scope) - [HTTP キャッシュ](https://docs.mulesoft.com/gateway/latest/policies-included-http-caching) # キャッシュエントリの無効化 Cache スコープでキャッシュエントリの値を再計算するには、キャッシュエントリを無効化します。 Invalidate Key コンポーネントと Invalidate Cache コンポーネントを使用することで、それぞれキャッシュキーとキャッシュ全体を無効化できます。また、時間に基づいてエントリを無効化するようにキャッシュ戦略を設定することもできます。 ## [](#キャッシュキーの無効化)キャッシュキーの無効化 参照先のキャッシュ戦略でキャッシュキーを無効化するように、アプリケーションフローで Invalidate Key コンポーネントを設定します。
Invalidate Key と Invalidate Cache コンポーネントで同じキャッシュ戦略を参照している場合、そのキャッシュ戦略で同期アクセスを無効化していない限り、Invalidate Key または Invalidate Cache コンポーネントを Cache スコープ内で指定しないでください。指定すると、ロックされたキャッシュをアプリケーションで無効化しようとしたときに、アプリケーションが応答しなくなります。
### [](#invalidate-key-コンポーネントの設定)Invalidate Key コンポーネントの設定 Invalidate Key コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Key**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Key**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化するキャッシュキーが保存されている​**キャッシュ戦略**​を指定します。 4. 必要に応じて、キャッシュキーを計算するための方法を選択します。 ### [](#キャッシュキーの無効化の設定例)キャッシュキーの無効化の設定例 ```xml ``` ## [](#キャッシュ全体の無効化)キャッシュ全体の無効化 参照先のキャッシュ戦略でキャッシュ全体を無効化するように、アプリケーションフローで Invalidate Cache コンポーネントを設定します。 ### [](#invalidate-cache-コンポーネントの設定)Invalidate Cache コンポーネントの設定 Invalidate Cache コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Cache**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Cache**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化する​**キャッシュ戦略**​を指定します。 ### [](#キャッシュ全体の無効化の設定例)キャッシュ全体の無効化の設定例 ```xml ``` ## [](#自動無効化)自動無効化 キャッシュ戦略を設定するときに、カスタムオブジェクトストアの設定で存続期間 (​`entryTtl`​) 値を指定することで、保存されているキャッシュキーが一定期間後に期限切れになるように設定できます。 ### [](#キャッシュ戦略でのオブジェクトストアの設定)キャッシュ戦略でのオブジェクトストアの設定 キャッシュキーが設定時間後に自動的に無効化されるようにオブジェクトストアをキャッシュ戦略で設定する手順は次のとおりです。 1. [「キャッシュ戦略のセットアップ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/cache-scope-strategy)​の手順を実行します。 2. キャッシュ戦略でオブジェクトストアを設定する際に、​**\[Entry TTL (エントリ TTL)\]**​ の値を指定します。 この値は、キャッシュエントリが期限切れになる時間を表します。 3. オブジェクトストアの設定を完了します。 ### [](#自動無効化の設定例)自動無効化の設定例 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.3/cache-scope-strategy) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-object-stores#object-store-config) - [オブジェクトストア参照](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore) # キャッシュエントリの無効化 Cache スコープでキャッシュエントリの値を再計算するには、キャッシュエントリを無効化します。 Invalidate Key コンポーネントと Invalidate Cache コンポーネントを使用することで、それぞれキャッシュキーとキャッシュ全体を無効化できます。また、時間に基づいてエントリを無効化するようにキャッシュ戦略を設定することもできます。 ## [](#キャッシュキーの無効化)キャッシュキーの無効化 参照先のキャッシュ戦略でキャッシュキーを無効化するように、アプリケーションフローで Invalidate Key コンポーネントを設定します。
Invalidate Key と Invalidate Cache コンポーネントで同じキャッシュ戦略を参照している場合、そのキャッシュ戦略で同期アクセスを無効化していない限り、Invalidate Key または Invalidate Cache コンポーネントを Cache スコープ内で指定しないでください。指定すると、ロックされたキャッシュをアプリケーションで無効化しようとしたときに、アプリケーションが応答しなくなります。
### [](#invalidate-key-コンポーネントの設定)Invalidate Key コンポーネントの設定 Invalidate Key コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Key**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Key**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化するキャッシュキーが保存されている​**キャッシュ戦略**​を指定します。 4. 必要に応じて、キャッシュキーを計算するための方法を選択します。 ### [](#キャッシュキーの無効化の設定例)キャッシュキーの無効化の設定例 ```xml ``` ## [](#キャッシュ全体の無効化)キャッシュ全体の無効化 参照先のキャッシュ戦略でキャッシュ全体を無効化するように、アプリケーションフローで Invalidate Cache コンポーネントを設定します。 ### [](#invalidate-cache-コンポーネントの設定)Invalidate Cache コンポーネントの設定 Invalidate Cache コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Cache**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Cache**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化する​**キャッシュ戦略**​を指定します。 ### [](#キャッシュ全体の無効化の設定例)キャッシュ全体の無効化の設定例 ```xml ``` ## [](#自動無効化)自動無効化 キャッシュ戦略を設定するときに、カスタムオブジェクトストアの設定で存続期間 (​`entryTtl`​) 値を指定することで、保存されているキャッシュキーが一定期間後に期限切れになるように設定できます。 ### [](#キャッシュ戦略でのオブジェクトストアの設定)キャッシュ戦略でのオブジェクトストアの設定 キャッシュキーが設定時間後に自動的に無効化されるようにオブジェクトストアをキャッシュ戦略で設定する手順は次のとおりです。 1. [「キャッシュ戦略のセットアップ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/cache-scope-strategy)​の手順を実行します。 2. キャッシュ戦略でオブジェクトストアを設定する際に、​**\[Entry TTL (エントリ TTL)\]**​ の値を指定します。 この値は、キャッシュエントリが期限切れになる時間を表します。 3. オブジェクトストアの設定を完了します。 ### [](#自動無効化の設定例)自動無効化の設定例 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.4/cache-scope-strategy) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-object-stores#object-store-config) - [オブジェクトストア参照](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore) # キャッシュエントリの無効化 Cache スコープでキャッシュエントリの値を再計算するには、キャッシュエントリを無効化します。 Invalidate Key コンポーネントと Invalidate Cache コンポーネントを使用することで、それぞれキャッシュキーとキャッシュ全体を無効化できます。また、時間に基づいてエントリを無効化するようにキャッシュ戦略を設定することもできます。 ## [](#キャッシュキーの無効化)キャッシュキーの無効化 参照先のキャッシュ戦略でキャッシュキーを無効化するように、アプリケーションフローで Invalidate Key コンポーネントを設定します。
Invalidate Key と Invalidate Cache コンポーネントで同じキャッシュ戦略を参照している場合、そのキャッシュ戦略で同期アクセスを無効化していない限り、Invalidate Key または Invalidate Cache コンポーネントを Cache スコープ内で指定しないでください。指定すると、ロックされたキャッシュをアプリケーションで無効化しようとしたときに、アプリケーションが応答しなくなります。
### [](#invalidate-key-コンポーネントの設定)Invalidate Key コンポーネントの設定 Invalidate Key コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Key**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Key**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化するキャッシュキーが保存されている​**キャッシュ戦略**​を指定します。 4. 必要に応じて、キャッシュキーを計算するための方法を選択します。 ### [](#キャッシュキーの無効化の設定例)キャッシュキーの無効化の設定例 ```xml ``` ## [](#キャッシュ全体の無効化)キャッシュ全体の無効化 参照先のキャッシュ戦略でキャッシュ全体を無効化するように、アプリケーションフローで Invalidate Cache コンポーネントを設定します。 ### [](#invalidate-cache-コンポーネントの設定)Invalidate Cache コンポーネントの設定 Invalidate Cache コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Cache**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Cache**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化する​**キャッシュ戦略**​を指定します。 ### [](#キャッシュ全体の無効化の設定例)キャッシュ全体の無効化の設定例 ```xml ``` ## [](#自動無効化)自動無効化 キャッシュ戦略を設定するときに、カスタムオブジェクトストアの設定で存続期間 (​`entryTtl`​) 値を指定することで、保存されているキャッシュキーが一定期間後に期限切れになるように設定できます。 ### [](#キャッシュ戦略でのオブジェクトストアの設定)キャッシュ戦略でのオブジェクトストアの設定 キャッシュキーが設定時間後に自動的に無効化されるようにオブジェクトストアをキャッシュ戦略で設定する手順は次のとおりです。 1. [「キャッシュ戦略のセットアップ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/cache-scope-strategy)​の手順を実行します。 2. キャッシュ戦略でオブジェクトストアを設定する際に、​**\[Entry TTL (エントリ TTL)\]**​ の値を指定します。 この値は、キャッシュエントリが期限切れになる時間を表します。 3. オブジェクトストアの設定を完了します。 ### [](#自動無効化の設定例)自動無効化の設定例 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.5/cache-scope-strategy) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-object-stores#object-store-config) - [オブジェクトストア参照](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore) # キャッシュエントリの無効化 Cache スコープでキャッシュエントリの値を再計算するには、キャッシュエントリを無効化します。 Invalidate Key コンポーネントと Invalidate Cache コンポーネントを使用することで、それぞれキャッシュキーとキャッシュ全体を無効化できます。また、時間に基づいてエントリを無効化するようにキャッシュ戦略を設定することもできます。 ## [](#キャッシュキーの無効化)キャッシュキーの無効化 参照先のキャッシュ戦略でキャッシュキーを無効化するように、アプリケーションフローで Invalidate Key コンポーネントを設定します。
Invalidate Key と Invalidate Cache コンポーネントで同じキャッシュ戦略を参照している場合、そのキャッシュ戦略で同期アクセスを無効化していない限り、Invalidate Key または Invalidate Cache コンポーネントを Cache スコープ内で指定しないでください。指定すると、ロックされたキャッシュをアプリケーションで無効化しようとしたときに、アプリケーションが応答しなくなります。
### [](#invalidate-key-コンポーネントの設定)Invalidate Key コンポーネントの設定 Invalidate Key コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Key**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Key**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化するキャッシュキーが保存されている​**キャッシュ戦略**​を指定します。 4. 必要に応じて、キャッシュキーを計算するための方法を選択します。 ### [](#キャッシュキーの無効化の設定例)キャッシュキーの無効化の設定例 ```xml ``` ## [](#キャッシュ全体の無効化)キャッシュ全体の無効化 参照先のキャッシュ戦略でキャッシュ全体を無効化するように、アプリケーションフローで Invalidate Cache コンポーネントを設定します。 ### [](#invalidate-cache-コンポーネントの設定)Invalidate Cache コンポーネントの設定 Invalidate Cache コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Cache**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Cache**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化する​**キャッシュ戦略**​を指定します。 ### [](#キャッシュ全体の無効化の設定例)キャッシュ全体の無効化の設定例 ```xml ``` ## [](#自動無効化)自動無効化 キャッシュ戦略を設定するときに、カスタムオブジェクトストアの設定で存続期間 (​`entryTtl`​) 値を指定することで、保存されているキャッシュキーが一定期間後に期限切れになるように設定できます。 ### [](#キャッシュ戦略でのオブジェクトストアの設定)キャッシュ戦略でのオブジェクトストアの設定 キャッシュキーが設定時間後に自動的に無効化されるようにオブジェクトストアをキャッシュ戦略で設定する手順は次のとおりです。 1. [「キャッシュ戦略のセットアップ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/cache-scope-strategy)​の手順を実行します。 2. キャッシュ戦略でオブジェクトストアを設定する際に、​**\[Entry TTL (エントリ TTL)\]**​ の値を指定します。 この値は、キャッシュエントリが期限切れになる時間を表します。 3. オブジェクトストアの設定を完了します。 ### [](#自動無効化の設定例)自動無効化の設定例 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.6/cache-scope-strategy) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-object-stores#object-store-config) - [オブジェクトストア参照](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore) # キャッシュエントリの無効化 Cache スコープでキャッシュエントリの値を再計算するには、キャッシュエントリを無効化します。 Invalidate Key コンポーネントと Invalidate Cache コンポーネントを使用することで、それぞれキャッシュキーとキャッシュ全体を無効化できます。また、時間に基づいてエントリを無効化するようにキャッシュ戦略を設定することもできます。 ## [](#キャッシュキーの無効化)キャッシュキーの無効化 参照先のキャッシュ戦略でキャッシュキーを無効化するように、アプリケーションフローで Invalidate Key コンポーネントを設定します。
Invalidate Key と Invalidate Cache コンポーネントで同じキャッシュ戦略を参照している場合、そのキャッシュ戦略で同期アクセスを無効化していない限り、Invalidate Key または Invalidate Cache コンポーネントを Cache スコープ内で指定しないでください。指定すると、ロックされたキャッシュをアプリケーションで無効化しようとしたときに、アプリケーションが応答しなくなります。
### [](#invalidate-key-コンポーネントの設定)Invalidate Key コンポーネントの設定 Invalidate Key コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Key**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Key**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化するキャッシュキーが保存されている​**キャッシュ戦略**​を指定します。 4. 必要に応じて、キャッシュキーを計算するための方法を選択します。 ### [](#キャッシュキーの無効化の設定例)キャッシュキーの無効化の設定例 ```xml ``` ## [](#キャッシュ全体の無効化)キャッシュ全体の無効化 参照先のキャッシュ戦略でキャッシュ全体を無効化するように、アプリケーションフローで Invalidate Cache コンポーネントを設定します。 ### [](#invalidate-cache-コンポーネントの設定)Invalidate Cache コンポーネントの設定 Invalidate Cache コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Cache**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Cache**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化する​**キャッシュ戦略**​を指定します。 ### [](#キャッシュ全体の無効化の設定例)キャッシュ全体の無効化の設定例 ```xml ``` ## [](#自動無効化)自動無効化 キャッシュ戦略を設定するときに、カスタムオブジェクトストアの設定で存続期間 (​`entryTtl`​) 値を指定することで、保存されているキャッシュキーが一定期間後に期限切れになるように設定できます。 ### [](#キャッシュ戦略でのオブジェクトストアの設定)キャッシュ戦略でのオブジェクトストアの設定 キャッシュキーが設定時間後に自動的に無効化されるようにオブジェクトストアをキャッシュ戦略で設定する手順は次のとおりです。 1. [「キャッシュ戦略のセットアップ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/cache-scope-strategy)​の手順を実行します。 2. キャッシュ戦略でオブジェクトストアを設定する際に、​**\[Entry TTL (エントリ TTL)\]**​ の値を指定します。 この値は、キャッシュエントリが期限切れになる時間を表します。 3. オブジェクトストアの設定を完了します。 ### [](#自動無効化の設定例)自動無効化の設定例 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.7/cache-scope-strategy) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-object-stores#object-store-config) - [オブジェクトストア参照](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore) # キャッシュエントリの無効化 Cache スコープでキャッシュエントリの値を再計算するには、キャッシュエントリを無効化します。 Invalidate Key コンポーネントと Invalidate Cache コンポーネントを使用することで、それぞれキャッシュキーとキャッシュ全体を無効化できます。また、時間に基づいてエントリを無効化するようにキャッシュ戦略を設定することもできます。 ## [](#キャッシュキーの無効化)キャッシュキーの無効化 参照先のキャッシュ戦略でキャッシュキーを無効化するように、アプリケーションフローで Invalidate Key コンポーネントを設定します。
Invalidate Key と Invalidate Cache コンポーネントで同じキャッシュ戦略を参照している場合、そのキャッシュ戦略で同期アクセスを無効化していない限り、Invalidate Key または Invalidate Cache コンポーネントを Cache スコープ内で指定しないでください。指定すると、ロックされたキャッシュをアプリケーションで無効化しようとしたときに、アプリケーションが応答しなくなります。
### [](#invalidate-key-コンポーネントの設定)Invalidate Key コンポーネントの設定 Invalidate Key コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Key**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Key**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化するキャッシュキーが保存されている​**キャッシュ戦略**​を指定します。 4. 必要に応じて、キャッシュキーを計算するための方法を選択します。 ### [](#キャッシュキーの無効化の設定例)キャッシュキーの無効化の設定例 ```xml ``` ## [](#キャッシュ全体の無効化)キャッシュ全体の無効化 参照先のキャッシュ戦略でキャッシュ全体を無効化するように、アプリケーションフローで Invalidate Cache コンポーネントを設定します。 ### [](#invalidate-cache-コンポーネントの設定)Invalidate Cache コンポーネントの設定 Invalidate Cache コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Cache**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Cache**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化する​**キャッシュ戦略**​を指定します。 ### [](#キャッシュ全体の無効化の設定例)キャッシュ全体の無効化の設定例 ```xml ``` ## [](#自動無効化)自動無効化 キャッシュ戦略を設定するときに、カスタムオブジェクトストアの設定で存続期間 (​`entryTtl`​) 値を指定することで、保存されているキャッシュキーが一定期間後に期限切れになるように設定できます。 ### [](#キャッシュ戦略でのオブジェクトストアの設定)キャッシュ戦略でのオブジェクトストアの設定 キャッシュキーが設定時間後に自動的に無効化されるようにオブジェクトストアをキャッシュ戦略で設定する手順は次のとおりです。 1. [「キャッシュ戦略のセットアップ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/cache-scope-strategy)​の手順を実行します。 2. キャッシュ戦略でオブジェクトストアを設定する際に、​**\[Entry TTL (エントリ TTL)\]**​ の値を指定します。 この値は、キャッシュエントリが期限切れになる時間を表します。 3. オブジェクトストアの設定を完了します。 ### [](#自動無効化の設定例)自動無効化の設定例 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.8/cache-scope-strategy) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-object-stores#object-store-config) - [オブジェクトストア参照](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore) # キャッシュエントリの無効化 Cache スコープでキャッシュエントリの値を再計算するには、キャッシュエントリを無効化します。 Invalidate Key コンポーネントと Invalidate Cache コンポーネントを使用することで、それぞれキャッシュキーとキャッシュ全体を無効化できます。また、時間に基づいてエントリを無効化するようにキャッシュ戦略を設定することもできます。 ## [](#キャッシュキーの無効化)キャッシュキーの無効化 参照先のキャッシュ戦略でキャッシュキーを無効化するように、アプリケーションフローで Invalidate Key コンポーネントを設定します。
Invalidate Key と Invalidate Cache コンポーネントで同じキャッシュ戦略を参照している場合、そのキャッシュ戦略で同期アクセスを無効化していない限り、Invalidate Key または Invalidate Cache コンポーネントを Cache スコープ内で指定しないでください。指定すると、ロックされたキャッシュをアプリケーションで無効化しようとしたときに、アプリケーションが応答しなくなります。
### [](#invalidate-key-コンポーネントの設定)Invalidate Key コンポーネントの設定 Invalidate Key コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Key**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Key**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化するキャッシュキーが保存されている​**キャッシュ戦略**​を指定します。 4. 必要に応じて、キャッシュキーを計算するための方法を選択します。 ### [](#キャッシュキーの無効化の設定例)キャッシュキーの無効化の設定例 ```xml ``` ## [](#キャッシュ全体の無効化)キャッシュ全体の無効化 参照先のキャッシュ戦略でキャッシュ全体を無効化するように、アプリケーションフローで Invalidate Cache コンポーネントを設定します。 ### [](#invalidate-cache-コンポーネントの設定)Invalidate Cache コンポーネントの設定 Invalidate Cache コンポーネントを設定する手順は次のとおりです。 1. **Anypoint Studio**​ で ​**Invalidate Cache**​ コンポーネントをドラッグしてフローに追加します。 2. フロー内で ​**Invalidate Cache**​ コンポーネントをクリックしてプロパティを開きます。 3. 無効化する​**キャッシュ戦略**​を指定します。 ### [](#キャッシュ全体の無効化の設定例)キャッシュ全体の無効化の設定例 ```xml ``` ## [](#自動無効化)自動無効化 キャッシュ戦略を設定するときに、カスタムオブジェクトストアの設定で存続期間 (​`entryTtl`​) 値を指定することで、保存されているキャッシュキーが一定期間後に期限切れになるように設定できます。 ### [](#キャッシュ戦略でのオブジェクトストアの設定)キャッシュ戦略でのオブジェクトストアの設定 キャッシュキーが設定時間後に自動的に無効化されるようにオブジェクトストアをキャッシュ戦略で設定する手順は次のとおりです。 1. [「キャッシュ戦略のセットアップ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/cache-scope-strategy)​の手順を実行します。 2. キャッシュ戦略でオブジェクトストアを設定する際に、​**\[Entry TTL (エントリ TTL)\]**​ の値を指定します。 この値は、キャッシュエントリが期限切れになる時間を表します。 3. オブジェクトストアの設定を完了します。 ### [](#自動無効化の設定例)自動無効化の設定例 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/cache-scope-to-configure) - [キャッシュ戦略のセットアップ](https://docs.mulesoft.com/jp/mule-runtime/4.9/cache-scope-strategy) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-object-stores#object-store-config) - [オブジェクトストア参照](https://docs.mulesoft.com/object-store-connector/latest/object-store-connector-reference#objectStore) # キャッシュ戦略のセットアップ キャッシュ戦略は、Anypoint Studio の Cache スコープのプロパティパネルまたはグローバル要素設定から作成できます。戦略を作成したら、フローの Cache コンポーネントで参照できます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。 キャッシュ戦略を設定する手順は次のとおりです。 1. \[Caching Strategy configuration (キャッシュ戦略設定)\] ウィンドウを開きます。 このウィンドウは、Cache スコープのパネルまたは、Studio の \[Global Elements (グローバル要素)\] タブの ​**\[Caching Strategies (キャッシュ戦略)\]**​ オプションから開くことができます。 ![キャッシュ戦略の設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-caching-strategy.png) 2. キャッシュ戦略の​**名前**​を定義します。 3. 次のいずれかのオプションを選択して、使用する​**オブジェクトストア**​を定義します。 - **Edit Inline (インライン編集)**​ このオプションは、このキャッシュ戦略に特有のオブジェクトストア設定を作成します。 - **Global Reference (グローバル参照)**​ このオプションは、既存のオブジェクトストアを選択するか、またはこのキャッシュ戦略とアプリケーション内の他のすべてのコンポーネントから参照できる新しいグローバルオブジェクトストアを作成します。 4. キャッシュ戦略内でイベントを保存するために使用されるキーを生成するメカニズムを選択します。 - **デフォルト** - **Key Expression (キー式)** DataWeave 式 (​`keyGenerationExpression="#[vars.requestId]"`​ など)。 同じ (「等しい」) 2 つの要求の場合、同じキーを生成する必要があります。そのようにしないと、誤った結果を取得する可能性があります。 - **Key Generator (キージェネレーター)** `com.mulesoft.mule.runtime.cache.api.key.MuleEventKeyGenerator`​ インターフェースを実装する必要があります。 5. (省略可能) プロパティウィンドウで ​**\[Advanced (詳細)\]**​ タブを開いて詳細設定を行います。 ![キャッシュ戦略の詳細設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-caching-strategy-advanced.png) - **応答ジェネレーター**​を選択または作成する。 このステップでは、​`com.mulesoft.mule.runtime.cache.api.response.ResponseGenerator`​ インターフェースを実装する必要があります。 - **イベントコピー戦略**​を選択する: - **シンプルイベントコピー戦略** データは不変です。これがデフォルト値です。 - **シリアル化可能イベントコピー戦略** データは変化します。 ## [](#キャッシュへの同期アクセス)キャッシュへの同期アクセス デフォルトでは、(同じまたは異なる Mule インスタンスの) 複数のメッセージプロセッサーが同時にキャッシュを使用する場合の予期しない結果を回避ために、Mule ではキャッシュへのアクセスが同期されます。 2 つのメッセージプロセッサーがキャッシュから値を取得しようとして、キャッシュ内に値が見つからないシナリオを考えてみます。この場合、各メッセージプロセッサーは値を個別に計算し、その値をキャッシュに挿入します。キャッシュへのアクセスが同期されない場合、2 番目のメッセージプロセッサーによって挿入された値が、最初のメッセージプロセッサーによって挿入された値を上書きします。値が異なる場合、同じ入力に対して 2 つの異なる結果が取得され、最後の 1 つのみがキャッシュに保存されます。 一部のシナリオではこの結果は有効ですが、アプリケーションがキャッシュコヒーレンスを必要とする場合は問題になる可能性があります。キャッシング戦略を同期することで、このコヒーレンスが保証されます。同期されたキャッシュは、メッセージプロセッサーによって変更されているときにロックされます。前のシナリオのロックされたキャッシュでは、最初のメッセージプロセッサーが値を計算するまで 2 番目のメッセージプロセッサーは強制的に待機させられ、その後キャッシュから値を取得します。 キャッシュの同期を無効にするには、​``​ 要素で ​`synchronized`​ プロパティを定義して ​`false`​ に設定することができます。
同期はパフォーマンスに影響し、その影響はクラスターモードで最も深刻になります。
## [](#キャッシュ戦略の例)キャッシュ戦略の例 次の XML スニペットは、キャッシュへのアクセスを同期し、キャッシュされた応答を保存する永続的なオブジェクトストアを定義するキャッシュ戦略の設定例を示しています。このキャッシュ戦略は、Cache スコープによって参照されています。 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/cache-scope) - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/cache-scope-to-configure) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-object-stores#object-store-config) - [Global Element (グローバル要素)](https://docs.mulesoft.com/jp/mule-runtime/4.3/global-elements) # キャッシュ戦略のセットアップ キャッシュ戦略は、Anypoint Studio の Cache スコープのプロパティパネルまたはグローバル要素設定から作成できます。戦略を作成したら、フローの Cache コンポーネントで参照できます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。 キャッシュ戦略を設定する手順は次のとおりです。 1. \[Caching Strategy configuration (キャッシュ戦略設定)\] ウィンドウを開きます。 このウィンドウは、Cache スコープのパネルまたは、Studio の \[Global Elements (グローバル要素)\] タブの ​**\[Caching Strategies (キャッシュ戦略)\]**​ オプションから開くことができます。 ![キャッシュ戦略の設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-caching-strategy.png) 2. キャッシュ戦略の​**名前**​を定義します。 3. 次のいずれかのオプションを選択して、使用する​**オブジェクトストア**​を定義します。 - **Edit Inline (インライン編集)**​ このオプションは、このキャッシュ戦略に特有のオブジェクトストア設定を作成します。 - **Global Reference (グローバル参照)**​ このオプションは、既存のオブジェクトストアを選択するか、またはこのキャッシュ戦略とアプリケーション内の他のすべてのコンポーネントから参照できる新しいグローバルオブジェクトストアを作成します。 4. キャッシュ戦略内でイベントを保存するために使用されるキーを生成するメカニズムを選択します。 - **デフォルト** - **Key Expression (キー式)** DataWeave 式 (​`keyGenerationExpression="#[vars.requestId]"`​ など)。 同じ (「等しい」) 2 つの要求の場合、同じキーを生成する必要があります。そのようにしないと、誤った結果を取得する可能性があります。 - **Key Generator (キージェネレーター)** `com.mulesoft.mule.runtime.cache.api.key.MuleEventKeyGenerator`​ インターフェースを実装する必要があります。 5. (省略可能) プロパティウィンドウで ​**\[Advanced (詳細)\]**​ タブを開いて詳細設定を行います。 ![キャッシュ戦略の詳細設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-caching-strategy-advanced.png) - **応答ジェネレーター**​を選択または作成する。 このステップでは、​`com.mulesoft.mule.runtime.cache.api.response.ResponseGenerator`​ インターフェースを実装する必要があります。 - **イベントコピー戦略**​を選択する: - **シンプルイベントコピー戦略** データは不変です。これがデフォルト値です。 - **シリアル化可能イベントコピー戦略** データは変化します。 ## [](#キャッシュへの同期アクセス)キャッシュへの同期アクセス デフォルトでは、(同じまたは異なる Mule インスタンスの) 複数のメッセージプロセッサーが同時にキャッシュを使用する場合の予期しない結果を回避ために、Mule ではキャッシュへのアクセスが同期されます。 2 つのメッセージプロセッサーがキャッシュから値を取得しようとして、キャッシュ内に値が見つからないシナリオを考えてみます。この場合、各メッセージプロセッサーは値を個別に計算し、その値をキャッシュに挿入します。キャッシュへのアクセスが同期されない場合、2 番目のメッセージプロセッサーによって挿入された値が、最初のメッセージプロセッサーによって挿入された値を上書きします。値が異なる場合、同じ入力に対して 2 つの異なる結果が取得され、最後の 1 つのみがキャッシュに保存されます。 一部のシナリオではこの結果は有効ですが、アプリケーションがキャッシュコヒーレンスを必要とする場合は問題になる可能性があります。キャッシング戦略を同期することで、このコヒーレンスが保証されます。同期されたキャッシュは、メッセージプロセッサーによって変更されているときにロックされます。前のシナリオのロックされたキャッシュでは、最初のメッセージプロセッサーが値を計算するまで 2 番目のメッセージプロセッサーは強制的に待機させられ、その後キャッシュから値を取得します。 キャッシュの同期を無効にするには、​``​ 要素で ​`synchronized`​ プロパティを定義して ​`false`​ に設定することができます。
同期はパフォーマンスに影響し、その影響はクラスターモードで最も深刻になります。
## [](#キャッシュ戦略の例)キャッシュ戦略の例 次の XML スニペットは、キャッシュへのアクセスを同期し、キャッシュされた応答を保存する永続的なオブジェクトストアを定義するキャッシュ戦略の設定例を示しています。このキャッシュ戦略は、Cache スコープによって参照されています。 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/cache-scope) - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/cache-scope-to-configure) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-object-stores#object-store-config) - [Global Element (グローバル要素)](https://docs.mulesoft.com/jp/mule-runtime/4.4/global-elements) # キャッシュ戦略のセットアップ キャッシュ戦略は、Anypoint Studio の Cache スコープのプロパティパネルまたはグローバル要素設定から作成できます。戦略を作成したら、フローの Cache コンポーネントで参照できます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。 キャッシュ戦略を設定する手順は次のとおりです。 1. \[Caching Strategy configuration (キャッシュ戦略設定)\] ウィンドウを開きます。 このウィンドウは、Cache スコープのパネルまたは、Studio の \[Global Elements (グローバル要素)\] タブの ​**\[Caching Strategies (キャッシュ戦略)\]**​ オプションから開くことができます。 ![キャッシュ戦略の設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-caching-strategy.png) 2. キャッシュ戦略の​**名前**​を定義します。 3. 次のいずれかのオプションを選択して、使用する​**オブジェクトストア**​を定義します。 - **Edit Inline (インライン編集)**​ このオプションは、このキャッシュ戦略に特有のオブジェクトストア設定を作成します。 - **Global Reference (グローバル参照)**​ このオプションは、既存のオブジェクトストアを選択するか、またはこのキャッシュ戦略とアプリケーション内の他のすべてのコンポーネントから参照できる新しいグローバルオブジェクトストアを作成します。 4. キャッシュ戦略内でイベントを保存するために使用されるキーを生成するメカニズムを選択します。 - **デフォルト** - **Key Expression (キー式)** DataWeave 式 (​`keyGenerationExpression="#[vars.requestId]"`​ など)。 同じ (「等しい」) 2 つの要求の場合、同じキーを生成する必要があります。そのようにしないと、誤った結果を取得する可能性があります。 - **Key Generator (キージェネレーター)** `com.mulesoft.mule.runtime.cache.api.key.MuleEventKeyGenerator`​ インターフェースを実装する必要があります。 5. (省略可能) プロパティウィンドウで ​**\[Advanced (詳細)\]**​ タブを開いて詳細設定を行います。 ![キャッシュ戦略の詳細設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-caching-strategy-advanced.png) - **応答ジェネレーター**​を選択または作成する。 このステップでは、​`com.mulesoft.mule.runtime.cache.api.response.ResponseGenerator`​ インターフェースを実装する必要があります。 - **イベントコピー戦略**​を選択する: - **シンプルイベントコピー戦略** データは不変です。これがデフォルト値です。 - **シリアル化可能イベントコピー戦略** データは変化します。 ## [](#キャッシュへの同期アクセス)キャッシュへの同期アクセス デフォルトでは、(同じまたは異なる Mule インスタンスの) 複数のメッセージプロセッサーが同時にキャッシュを使用する場合の予期しない結果を回避ために、Mule ではキャッシュへのアクセスが同期されます。 2 つのメッセージプロセッサーがキャッシュから値を取得しようとして、キャッシュ内に値が見つからないシナリオを考えてみます。この場合、各メッセージプロセッサーは値を個別に計算し、その値をキャッシュに挿入します。キャッシュへのアクセスが同期されない場合、2 番目のメッセージプロセッサーによって挿入された値が、最初のメッセージプロセッサーによって挿入された値を上書きします。値が異なる場合、同じ入力に対して 2 つの異なる結果が取得され、最後の 1 つのみがキャッシュに保存されます。 一部のシナリオではこの結果は有効ですが、アプリケーションがキャッシュコヒーレンスを必要とする場合は問題になる可能性があります。キャッシング戦略を同期することで、このコヒーレンスが保証されます。同期されたキャッシュは、メッセージプロセッサーによって変更されているときにロックされます。前のシナリオのロックされたキャッシュでは、最初のメッセージプロセッサーが値を計算するまで 2 番目のメッセージプロセッサーは強制的に待機させられ、その後キャッシュから値を取得します。 キャッシュの同期を無効にするには、​``​ 要素で ​`synchronized`​ プロパティを定義して ​`false`​ に設定することができます。
同期はパフォーマンスに影響し、その影響はクラスターモードで最も深刻になります。
## [](#キャッシュ戦略の例)キャッシュ戦略の例 次の XML スニペットは、キャッシュへのアクセスを同期し、キャッシュされた応答を保存する永続的なオブジェクトストアを定義するキャッシュ戦略の設定例を示しています。このキャッシュ戦略は、Cache スコープによって参照されています。 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/cache-scope) - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/cache-scope-to-configure) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-object-stores#object-store-config) - [Global Element (グローバル要素)](https://docs.mulesoft.com/jp/mule-runtime/4.5/global-elements) # キャッシュ戦略のセットアップ キャッシュ戦略は、Anypoint Studio の Cache スコープのプロパティパネルまたはグローバル要素設定から作成できます。戦略を作成したら、フローの Cache コンポーネントで参照できます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。 キャッシュ戦略を設定する手順は次のとおりです。 1. \[Caching Strategy configuration (キャッシュ戦略設定)\] ウィンドウを開きます。 このウィンドウは、Cache スコープのパネルまたは、Studio の \[Global Elements (グローバル要素)\] タブの ​**\[Caching Strategies (キャッシュ戦略)\]**​ オプションから開くことができます。 ![キャッシュ戦略の設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-caching-strategy.png) 2. キャッシュ戦略の​**名前**​を定義します。 3. 次のいずれかのオプションを選択して、使用する​**オブジェクトストア**​を定義します。 - **Edit Inline (インライン編集)**​ このオプションは、このキャッシュ戦略に特有のオブジェクトストア設定を作成します。 - **Global Reference (グローバル参照)**​ このオプションは、既存のオブジェクトストアを選択するか、またはこのキャッシュ戦略とアプリケーション内の他のすべてのコンポーネントから参照できる新しいグローバルオブジェクトストアを作成します。 4. キャッシュ戦略内でイベントを保存するために使用されるキーを生成するメカニズムを選択します。 - **デフォルト** - **Key Expression (キー式)** DataWeave 式 (​`keyGenerationExpression="#[vars.requestId]"`​ など)。 同じ (「等しい」) 2 つの要求の場合、同じキーを生成する必要があります。そのようにしないと、誤った結果を取得する可能性があります。 - **Key Generator (キージェネレーター)** `com.mulesoft.mule.runtime.cache.api.key.MuleEventKeyGenerator`​ インターフェースを実装する必要があります。 5. (省略可能) プロパティウィンドウで ​**\[Advanced (詳細)\]**​ タブを開いて詳細設定を行います。 ![キャッシュ戦略の詳細設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-caching-strategy-advanced.png) - **応答ジェネレーター**​を選択または作成する。 このステップでは、​`com.mulesoft.mule.runtime.cache.api.response.ResponseGenerator`​ インターフェースを実装する必要があります。 - **イベントコピー戦略**​を選択する: - **シンプルイベントコピー戦略** データは不変です。これがデフォルト値です。 - **シリアル化可能イベントコピー戦略** データは変化します。 ## [](#キャッシュへの同期アクセス)キャッシュへの同期アクセス デフォルトでは、(同じまたは異なる Mule インスタンスの) 複数のメッセージプロセッサーが同時にキャッシュを使用する場合の予期しない結果を回避ために、Mule ではキャッシュへのアクセスが同期されます。 2 つのメッセージプロセッサーがキャッシュから値を取得しようとして、キャッシュ内に値が見つからないシナリオを考えてみます。この場合、各メッセージプロセッサーは値を個別に計算し、その値をキャッシュに挿入します。キャッシュへのアクセスが同期されない場合、2 番目のメッセージプロセッサーによって挿入された値が、最初のメッセージプロセッサーによって挿入された値を上書きします。値が異なる場合、同じ入力に対して 2 つの異なる結果が取得され、最後の 1 つのみがキャッシュに保存されます。 一部のシナリオではこの結果は有効ですが、アプリケーションがキャッシュコヒーレンスを必要とする場合は問題になる可能性があります。キャッシング戦略を同期することで、このコヒーレンスが保証されます。同期されたキャッシュは、メッセージプロセッサーによって変更されているときにロックされます。前のシナリオのロックされたキャッシュでは、最初のメッセージプロセッサーが値を計算するまで 2 番目のメッセージプロセッサーは強制的に待機させられ、その後キャッシュから値を取得します。 キャッシュの同期を無効にするには、​``​ 要素で ​`synchronized`​ プロパティを定義して ​`false`​ に設定することができます。
同期はパフォーマンスに影響し、その影響はクラスターモードで最も深刻になります。
## [](#キャッシュ戦略の例)キャッシュ戦略の例 次の XML スニペットは、キャッシュへのアクセスを同期し、キャッシュされた応答を保存する永続的なオブジェクトストアを定義するキャッシュ戦略の設定例を示しています。このキャッシュ戦略は、Cache スコープによって参照されています。 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/cache-scope) - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/cache-scope-to-configure) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-object-stores#object-store-config) - [Global Element (グローバル要素)](https://docs.mulesoft.com/jp/mule-runtime/4.6/global-elements) # キャッシュ戦略のセットアップ キャッシュ戦略は、Anypoint Studio の Cache スコープのプロパティパネルまたはグローバル要素設定から作成できます。戦略を作成したら、フローの Cache コンポーネントで参照できます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。 キャッシュ戦略を設定する手順は次のとおりです。 1. \[Caching Strategy configuration (キャッシュ戦略設定)\] ウィンドウを開きます。 このウィンドウは、Cache スコープのパネルまたは、Studio の \[Global Elements (グローバル要素)\] タブの ​**\[Caching Strategies (キャッシュ戦略)\]**​ オプションから開くことができます。 ![キャッシュ戦略の設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-caching-strategy.png) 2. キャッシュ戦略の​**名前**​を定義します。 3. 次のいずれかのオプションを選択して、使用する​**オブジェクトストア**​を定義します。 - **Edit Inline (インライン編集)**​ このオプションは、このキャッシュ戦略に特有のオブジェクトストア設定を作成します。 - **Global Reference (グローバル参照)**​ このオプションは、既存のオブジェクトストアを選択するか、またはこのキャッシュ戦略とアプリケーション内の他のすべてのコンポーネントから参照できる新しいグローバルオブジェクトストアを作成します。 4. キャッシュ戦略内でイベントを保存するために使用されるキーを生成するメカニズムを選択します。 - **デフォルト** - **Key Expression (キー式)** DataWeave 式 (​`keyGenerationExpression="#[vars.requestId]"`​ など)。 同じ (「等しい」) 2 つの要求の場合、同じキーを生成する必要があります。そのようにしないと、誤った結果を取得する可能性があります。 - **Key Generator (キージェネレーター)** `com.mulesoft.mule.runtime.cache.api.key.MuleEventKeyGenerator`​ インターフェースを実装する必要があります。 5. (省略可能) プロパティウィンドウで ​**\[Advanced (詳細)\]**​ タブを開いて詳細設定を行います。 ![キャッシュ戦略の詳細設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-caching-strategy-advanced.png) - **応答ジェネレーター**​を選択または作成する。 このステップでは、​`com.mulesoft.mule.runtime.cache.api.response.ResponseGenerator`​ インターフェースを実装する必要があります。 - **イベントコピー戦略**​を選択する: - **シンプルイベントコピー戦略** データは不変です。これがデフォルト値です。 - **シリアル化可能イベントコピー戦略** データは変化します。 ## [](#キャッシュへの同期アクセス)キャッシュへの同期アクセス デフォルトでは、(同じまたは異なる Mule インスタンスの) 複数のメッセージプロセッサーが同時にキャッシュを使用する場合の予期しない結果を回避ために、Mule ではキャッシュへのアクセスが同期されます。 2 つのメッセージプロセッサーがキャッシュから値を取得しようとして、キャッシュ内に値が見つからないシナリオを考えてみます。この場合、各メッセージプロセッサーは値を個別に計算し、その値をキャッシュに挿入します。キャッシュへのアクセスが同期されない場合、2 番目のメッセージプロセッサーによって挿入された値が、最初のメッセージプロセッサーによって挿入された値を上書きします。値が異なる場合、同じ入力に対して 2 つの異なる結果が取得され、最後の 1 つのみがキャッシュに保存されます。 一部のシナリオではこの結果は有効ですが、アプリケーションがキャッシュコヒーレンスを必要とする場合は問題になる可能性があります。キャッシング戦略を同期することで、このコヒーレンスエンジンが保証されます。同期されたキャッシュは、メッセージプロセッサーによって変更されているときにロックされます。前のシナリオのロックされたキャッシュでは、最初のメッセージプロセッサーが値を計算するまで 2 番目のメッセージプロセッサーは強制的に待機させられ、その後キャッシュから値を取得します。 キャッシュの同期を無効にするには、​``​ 要素で ​`synchronized`​ プロパティを定義して ​`false`​ に設定することができます。
同期はパフォーマンスに影響し、その影響はクラスターモードで最も深刻になります。
## [](#キャッシュ戦略の例)キャッシュ戦略の例 次の XML スニペットは、キャッシュへのアクセスを同期し、キャッシュされた応答を保存する永続的なオブジェクトストアを定義するキャッシュ戦略の設定例を示しています。このキャッシュ戦略は、Cache スコープによって参照されています。 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/cache-scope) - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/cache-scope-to-configure) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-object-stores#object-store-config) - [Global Element (グローバル要素)](https://docs.mulesoft.com/jp/mule-runtime/4.7/global-elements) # キャッシュ戦略のセットアップ キャッシュ戦略は、Anypoint Studio の Cache スコープのプロパティパネルまたはグローバル要素設定から作成できます。戦略を作成したら、フローの Cache コンポーネントで参照できます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。 キャッシュ戦略を設定する手順は次のとおりです。 1. \[Caching Strategy configuration (キャッシュ戦略設定)\] ウィンドウを開きます。 このウィンドウは、Cache スコープのパネルまたは、Studio の \[Global Elements (グローバル要素)\] タブの ​**\[Caching Strategies (キャッシュ戦略)\]**​ オプションから開くことができます。 !["オブジェクトストアとイベントキー生成のオプションが含まれる \[Caching Strategy (キャッシュ戦略)](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-caching-strategy.png) セットアップ"\] 2. キャッシュ戦略の​**名前**​を定義します。 3. 次のいずれかのオプションを選択して、使用する​**オブジェクトストア**​を定義します。 - **Edit Inline (インライン編集)**​ このオプションは、このキャッシュ戦略に特有のオブジェクトストア設定を作成します。 - **Global Reference (グローバル参照)**​ このオプションは、既存のオブジェクトストアを選択するか、またはこのキャッシュ戦略とアプリケーション内の他のすべてのコンポーネントから参照できる新しいグローバルオブジェクトストアを作成します。 4. キャッシュ戦略内でイベントを保存するために使用されるキーを生成するメカニズムを選択します。 - **デフォルト** - **Key Expression (キー式)** DataWeave 式 (​`keyGenerationExpression="#[vars.requestId]"`​ など)。 同じ (「等しい」) 2 つの要求の場合、同じキーを生成する必要があります。そのようにしないと、誤った結果を取得する可能性があります。 - **Key Generator (キージェネレーター)** `com.mulesoft.mule.runtime.cache.api.key.MuleEventKeyGenerator`​ インターフェースを実装する必要があります。 5. (省略可能) プロパティウィンドウで ​**\[Advanced (詳細)\]**​ タブを開いて詳細設定を行います。 ![キャッシュ動作と応答ジェネレーターの設定が表示されているキャッシュ戦略の設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-caching-strategy-advanced.png) - **応答ジェネレーター**​を選択または作成する。 このステップでは、​`com.mulesoft.mule.runtime.cache.api.response.ResponseGenerator`​ インターフェースを実装する必要があります。 - **イベントコピー戦略**​を選択する: - **シンプルイベントコピー戦略** データは不変です。これがデフォルト値です。 - **シリアル化可能イベントコピー戦略** データは変化します。 ## [](#キャッシュへの同期アクセス)キャッシュへの同期アクセス デフォルトでは、(同じまたは異なる Mule インスタンスの) 複数のメッセージプロセッサーが同時にキャッシュを使用する場合の予期しない結果を回避ために、Mule ではキャッシュへのアクセスが同期されます。 2 つのメッセージプロセッサーがキャッシュから値を取得しようとして、キャッシュ内に値が見つからないシナリオを考えてみます。この場合、各メッセージプロセッサーは値を個別に計算し、その値をキャッシュに挿入します。キャッシュへのアクセスが同期されない場合、2 番目のメッセージプロセッサーによって挿入された値が、最初のメッセージプロセッサーによって挿入された値を上書きします。値が異なる場合、同じ入力に対して 2 つの異なる結果が取得され、最後の 1 つのみがキャッシュに保存されます。 一部のシナリオではこの結果は有効ですが、アプリケーションがキャッシュコヒーレンスを必要とする場合は問題になる可能性があります。キャッシング戦略を同期することで、このコヒーレンスエンジンが保証されます。同期されたキャッシュは、メッセージプロセッサーによって変更されているときにロックされます。前のシナリオのロックされたキャッシュでは、最初のメッセージプロセッサーが値を計算するまで 2 番目のメッセージプロセッサーは強制的に待機させられ、その後キャッシュから値を取得します。 キャッシュの同期を無効にするには、​``​ 要素で ​`synchronized`​ プロパティを定義して ​`false`​ に設定することができます。
同期はパフォーマンスに影響し、その影響はクラスターモードで最も深刻になります。
## [](#キャッシュ戦略の例)キャッシュ戦略の例 次の XML スニペットは、キャッシュへのアクセスを同期し、キャッシュされた応答を保存する永続的なオブジェクトストアを定義するキャッシュ戦略の設定例を示しています。このキャッシュ戦略は、Cache スコープによって参照されています。 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/cache-scope) - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/cache-scope-to-configure) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-object-stores#object-store-config) - [Global Element (グローバル要素)](https://docs.mulesoft.com/jp/mule-runtime/4.8/global-elements) # キャッシュ戦略のセットアップ キャッシュ戦略は、Anypoint Studio の Cache スコープのプロパティパネルまたはグローバル要素設定から作成できます。戦略を作成したら、フローの Cache コンポーネントで参照できます。 キャッシュ戦略から定義または参照されるオブジェクトストアでこれらの値を設定することで、キャッシュサイズ、有効期限、許容される最大エントリ数を設定できます。 キャッシュ戦略を設定する手順は次のとおりです。 1. \[Caching Strategy configuration (キャッシュ戦略設定)\] ウィンドウを開きます。 このウィンドウは、Cache スコープのパネルまたは、Studio の \[Global Elements (グローバル要素)\] タブの ​**\[Caching Strategies (キャッシュ戦略)\]**​ オプションから開くことができます。 !["オブジェクトストアとイベントキー生成のオプションが含まれる \[Caching Strategy (キャッシュ戦略)](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-caching-strategy.png) セットアップ"\] 2. キャッシュ戦略の​**名前**​を定義します。 3. 次のいずれかのオプションを選択して、使用する​**オブジェクトストア**​を定義します。 - **Edit Inline (インライン編集)**​ このオプションは、このキャッシュ戦略に特有のオブジェクトストア設定を作成します。 - **Global Reference (グローバル参照)**​ このオプションは、既存のオブジェクトストアを選択するか、またはこのキャッシュ戦略とアプリケーション内の他のすべてのコンポーネントから参照できる新しいグローバルオブジェクトストアを作成します。 4. キャッシュ戦略内でイベントを保存するために使用されるキーを生成するメカニズムを選択します。 - **デフォルト** - **Key Expression (キー式)** DataWeave 式 (​`keyGenerationExpression="#[vars.requestId]"`​ など)。 同じ (「等しい」) 2 つの要求の場合、同じキーを生成する必要があります。そのようにしないと、誤った結果を取得する可能性があります。 - **Key Generator (キージェネレーター)** `com.mulesoft.mule.runtime.cache.api.key.MuleEventKeyGenerator`​ インターフェースを実装する必要があります。 5. (省略可能) プロパティウィンドウで ​**\[Advanced (詳細)\]**​ タブを開いて詳細設定を行います。 ![キャッシュ動作と応答ジェネレーターの設定が表示されているキャッシュ戦略の設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-caching-strategy-advanced.png) - **応答ジェネレーター**​を選択または作成する。 このステップでは、​`com.mulesoft.mule.runtime.cache.api.response.ResponseGenerator`​ インターフェースを実装する必要があります。 - **イベントコピー戦略**​を選択する: - **シンプルイベントコピー戦略** データは不変です。これがデフォルト値です。 - **シリアル化可能イベントコピー戦略** データは変化します。 ## [](#キャッシュへの同期アクセス)キャッシュへの同期アクセス デフォルトでは、(同じまたは異なる Mule インスタンスの) 複数のメッセージプロセッサーが同時にキャッシュを使用する場合の予期しない結果を回避ために、Mule ではキャッシュへのアクセスが同期されます。 2 つのメッセージプロセッサーがキャッシュから値を取得しようとして、キャッシュ内に値が見つからないシナリオを考えてみます。この場合、各メッセージプロセッサーは値を個別に計算し、その値をキャッシュに挿入します。キャッシュへのアクセスが同期されない場合、2 番目のメッセージプロセッサーによって挿入された値が、最初のメッセージプロセッサーによって挿入された値を上書きします。値が異なる場合、同じ入力に対して 2 つの異なる結果が取得され、最後の 1 つのみがキャッシュに保存されます。 一部のシナリオではこの結果は有効ですが、アプリケーションがキャッシュコヒーレンスを必要とする場合は問題になる可能性があります。キャッシング戦略を同期することで、このコヒーレンスエンジンが保証されます。同期されたキャッシュは、メッセージプロセッサーによって変更されているときにロックされます。前のシナリオのロックされたキャッシュでは、最初のメッセージプロセッサーが値を計算するまで 2 番目のメッセージプロセッサーは強制的に待機させられ、その後キャッシュから値を取得します。 キャッシュの同期を無効にするには、​``​ 要素で ​`synchronized`​ プロパティを定義して ​`false`​ に設定することができます。
同期はパフォーマンスに影響し、その影響はクラスターモードで最も深刻になります。
## [](#キャッシュ戦略の例)キャッシュ戦略の例 次の XML スニペットは、キャッシュへのアクセスを同期し、キャッシュされた応答を保存する永続的なオブジェクトストアを定義するキャッシュ戦略の設定例を示しています。このキャッシュ戦略は、Cache スコープによって参照されています。 ```xml ``` ## [](#関連情報)関連情報 - [Cache スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/cache-scope) - [Cache スコープの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/cache-scope-to-configure) - [オブジェクトストア設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-object-stores#object-store-config) - [Global Element (グローバル要素)](https://docs.mulesoft.com/jp/mule-runtime/4.9/global-elements) # クラスターランタイムインスタンス Mule は、さまざまなトポロジーでデプロイできます。Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。このページでは、クラスタリングを介してこれらの特性を適切に融合するためのいくつかのソリューションについて説明します。1 つのアプローチですべてのユーザーに適切に対応することはできません。システム設計は、芸術と科学の両方で成り立っています。さらにサポートが必要な場合、MuleSoft プロフェッショナルサービスがアーキテクチャプランの確認や設定を行うことができます。詳細は、 [お問い合わせ](http://www.mulesoft.com/contact)​ください。 ## [](#クラスタリングについて)クラスタリングについて 以下の実現するには、アプリケーションをクラスターにデプロイすることが効果的です。 - 高可用性 (HA): クラスターの 1 つ以上のサーバーまたはデータセンターに障害が発生してもシステムを継続的に使用できます。 - フォールトトレランス (FT): 基盤となるコンポーネントの障害から回復できます。通常、回復はトランザクションロールバックまたは補正アクションによって行われます。 - スケーリング: 需要の増加に合わせてアプリケーションを垂直スケーリングできます。 このページでは、いくつかのクラスタリングソリューション候補について説明します。 ## [](#mule-高可用性)Mule 高可用性 **_Enterprise Edition_**

Mule 高可用性では、Mule の基本的なフェールオーバー機能が提供されます。(JVM またはハードウェアの致命的な障害のため) プライマリ Mule インスタンスが使用できなくなった場合、バックアップ Mule インスタンスが即座にプライマリノードになり、障害の発生したインスタンスが中断した場所から処理を再開します。システム管理者が障害が発生した Mule インスタンスを回復してオンラインに戻すと、自動的にバックアップノードになります。

シームレスなフェールオーバーは、次のようなクラスター化された Mule インスタンスですべての一時的な状態の情報を共有する分散メモリストアによって実現します。

  • SEDA サービスイベントキュー

  • メモリ内メッセージキュー

現在、Mule 高可用性は次のトランスポートで使用できます。

  • HTTP (CXF Web サービスを含む)

  • JMS

  • WebSphere MQ

  • JDBC

  • ファイル

  • FTP

  • クラスター (ローカル VM トランスポートを置き換える)

HA-arch
Mule 高可用性は、Mule Enterprise サブスクリプションで使用できます。テクニカルハイライト、要件、インストールなどの詳細は、[お問い合わせください](mailto:sales@mulesoft.com)。 ## [](#jms-キュー)JMS キュー JMS を使用すれば、メッセージを JMS キューを介してルーティングして HA & FT を実現できます。この場合、各メッセージはコンポーネント間の移動時に必ず JMS キューを介してルーティングされます。 ![jms queues](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/jms-queues.png) プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - 多くのトランザクションが必要となり、トランザクションが複雑になる可能性がある - XA を使用している場合、パフォーマンスが低下する ## [](#ロードバランサー)ロードバランサー ロードバランサーは、各サーバーの現在の負荷と現在稼働しているサーバーに基づいて、要求を各サーバーにルーティングします。ロードバランサーは、ソフトウェアベースまたはハードウェアベースになります。このアプローチは、一般的にクラスター化されたデータベースで使用されます (下記参照)。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - これ自体では完全なソリューションにはならず、フォールトトレランスが提供されない。 ## [](#例)例 このサンプルアーキテクチャでは、HTTP 要求がロードバランサーから入り、即座に JMS キューに配置されます。JMS キューは、異なるサーバー間でクラスター化されています。サーバーは、JMS キューのメッセージの処理を開始し、トランザクションのすべてをラップします。 ![http\_and\_jms](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/http-and-jms.png) サーバーがダウンすると、トランザクションがロールバックされ、別のサーバーがメッセージを取得して処理を開始します。 **注意**​: ロードバランサーはサーバー間で接続を透過的に切り替えないため、このプロセスの間に HTTP 接続が開いていると、このアプローチは機能しません。その場合、HTTP クライアントは要求を再試行する必要があります。 ## [](#データベースでの状態の保持)データベースでの状態の保持 クラスター化されたデータベースがある場合、アプリケーションですべての状態をデータベースに保存し、それを使用してサーバー間で継続的にデータを複製できます。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - すべての状態をデータベースに保存できるわけではない ## [](#ステートフルコンポーネントの処理)ステートフルコンポーネントの処理 上記の手法で大部分のアプリケーションをサポートできますが、JVM 間でより深く状態を共有することが必要になる場合もあります。 この一般的な例として、Aggregator コンポーネントが挙げられます。たとえば、2 つの異なるプロデューサーのメッセージを集計するアグリゲーターがあるとします。プロデューサー #1 は、アグリゲーターにメッセージを送信します。アグリゲーターは、そのメッセージを受信して、プロデューサー #2 がメッセージを送信するまでメモリに保持します。 ```text Producer #1 ---> |----------| |Aggregator| --> Some other component Producer #2 ---> |----------| ``` プロデューサー #1 がメッセージを送信してからプロデューサー #2 がメッセージを送信する間にアグリゲーターのあるサーバーがダウンすると、プロデューサー #2 はそのメッセージを別のサーバーに送信できません (そのサーバーにプロデューサー #1 のメッセージがないため)。 この解決策は、Terracotta、Oracle Coherence、JGroups などのクラスタリングソフトウェアを介して Aggregator コンポーネントの状態を各マシンで共有することです。 これらのツールのいずれかを使用することで、プロデューサー #2 は別のサーバーにフェールオーバーできます。MuleSoft は、これらのツールで Mule をテストしていないため、正式にはサポートしていません。 プラス面: - すべてのクラスタリングケースで機能する - キャッシュとしても機能する マイナス面: - MuleSoft で正式にサポートされていない - 効率化のためにパフォーマンス調整が必要となる ## [](#関連トピック)関連トピック このドキュメントには記載されていませんが、トポロジーを設計するときに考慮すべきいくつかのトピックが他にもあります。 - 各地域に分散しているクラスターの管理 - データパーティション分割 - ACID トランザクションと BASE トランザクション - 補正とトランザクション # クラスターランタイムインスタンス Mule は、さまざまなトポロジーでデプロイできます。Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。このページでは、オンプレミスにアプリケーションをデプロイするときにクラスタリングを介してこれらの特性を適切に融合するためのいくつかのソリューションについて説明します。1 つのアプローチですべてのユーザーに適切に対応することはできません。システム設計は、芸術と科学の両方で成り立っています。さらにサポートが必要な場合、MuleSoft プロフェッショナルサービスがアーキテクチャプランの確認や設定を行うことができます。詳細は、 [お問い合わせ](http://www.mulesoft.com/contact)​ください。 ## [](#クラスタリングについて)クラスタリングについて 以下の実現するには、アプリケーションをクラスターにデプロイすることが効果的です。 - 高可用性 (HA): クラスターの 1 つ以上のサーバーまたはデータセンターに障害が発生してもシステムを継続的に使用できます。 - フォールトトレランス (FT): 基盤となるコンポーネントの障害から回復できます。通常、回復はトランザクションロールバックまたは補正アクションによって行われます。 - スケーリング: 需要の増加に合わせてアプリケーションを垂直スケーリングできます。 このページでは、いくつかのクラスタリングソリューション候補について説明します。 ## [](#mule-高可用性)Mule 高可用性 **_Enterprise Edition_**

Mule 高可用性では、Mule の基本的なフェールオーバー機能が提供されます。(JVM またはハードウェアの致命的な障害のため) プライマリ Mule インスタンスが使用できなくなった場合、バックアップ Mule インスタンスが即座にプライマリノードになり、障害の発生したインスタンスが中断した場所から処理を再開します。システム管理者が障害が発生した Mule インスタンスを回復してオンラインに戻すと、自動的にバックアップノードになります。

シームレスなフェールオーバーは、次のようなクラスタリングされた Mule インスタンスですべての一時的な状態の情報を共有する分散メモリストアによって実現します。

  • SEDA サービスイベントキュー

  • メモリ内メッセージキュー

現在、Mule 高可用性は次のトランスポートで使用できます。

  • HTTP (CXF Web サービスを含む)

  • JMS

  • WebSphere MQ

  • JDBC

  • ファイル

  • FTP

  • クラスター (ローカル VM トランスポートを置き換える)

HA-arch
Mule 高可用性は、Mule Enterprise サブスクリプションで使用できます。テクニカルハイライト、要件、インストールなどの詳細は、[お問い合わせください](mailto:sales@mulesoft.com)。 ## [](#jms-キュー)JMS キュー JMS を使用すれば、メッセージを JMS キューを介してルーティングして HA & FT を実現できます。この場合、各メッセージはコンポーネント間の移動時に必ず JMS キューを介してルーティングされます。 ![jms queues](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/jms-queues.png) プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - 多くのトランザクションが必要となり、トランザクションが複雑になる可能性がある - XA を使用している場合、パフォーマンスが低下する ## [](#ロードバランサー)ロードバランサー ロードバランサーは、各サーバーの現在の負荷と現在稼働しているサーバーに基づいて、要求を各サーバーにルーティングします。ロードバランサーは、ソフトウェアベースまたはハードウェアベースになります。このアプローチは、一般的にクラスタリングされたデータベースで使用されます (下記参照)。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - これ自体では完全なソリューションにはならず、フォールトトレランスが提供されない。 ## [](#例)例 このサンプルアーキテクチャでは、HTTP 要求がロードバランサーから入り、即座に JMS キューに配置されます。JMS キューは、異なるサーバー間でクラスタリングされています。サーバーは、JMS キューのメッセージの処理を開始し、トランザクションのすべてをラップします。 ![http\_and\_jms](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/http-and-jms.png) サーバーがダウンすると、トランザクションがロールバックされ、別のサーバーがメッセージを取得して処理を開始します。 **注意**​: ロードバランサーはサーバー間で接続を透過的に切り替えないため、このプロセスの間に HTTP 接続が開いていると、このアプローチは機能しません。その場合、HTTP クライアントは要求を再試行する必要があります。 ## [](#データベースでの状態の保持)データベースでの状態の保持 クラスタリングされたデータベースがある場合、アプリケーションですべての状態をデータベースに保存し、それを使用してサーバー間で継続的にデータを複製できます。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - すべての状態をデータベースに保存できるわけではない ## [](#ステートフルコンポーネントの処理)ステートフルコンポーネントの処理 上記の手法で大部分のアプリケーションをサポートできますが、JVM 間でより深く状態を共有することが必要になる場合もあります。 この一般的な例として、Aggregator コンポーネントが挙げられます。たとえば、2 つの異なるプロデューサーのメッセージを集計するアグリゲーターがあるとします。プロデューサー #1 は、アグリゲーターにメッセージを送信します。アグリゲーターは、そのメッセージを受信して、プロデューサー #2 がメッセージを送信するまでメモリに保持します。 ```text Producer #1 ---> |----------| |Aggregator| --> Some other component Producer #2 ---> |----------| ``` プロデューサー #1 がメッセージを送信してからプロデューサー #2 がメッセージを送信する間にアグリゲーターのあるサーバーがダウンすると、プロデューサー #2 はそのメッセージを別のサーバーに送信できません (そのサーバーにプロデューサー #1 のメッセージがないため)。 この解決策は、Terracotta、Oracle Coherence、JGroups などのクラスタリングソフトウェアを介して Aggregator コンポーネントの状態を各マシンで共有することです。 これらのツールのいずれかを使用することで、プロデューサー #2 は別のサーバーにフェールオーバーできます。MuleSoft は、これらのツールで Mule をテストしていないため、正式にはサポートしていません。 プラス面: - すべてのクラスタリングケースで機能する - キャッシュとしても機能する マイナス面: - MuleSoft で正式にサポートされていない - 効率化のためにパフォーマンス調整が必要となる ## [](#関連トピック)関連トピック このドキュメントには記載されていませんが、トポロジーを設計するときに考慮すべきいくつかのトピックが他にもあります。 - 各地域に分散しているクラスターの管理 - データパーティション分割 - ACID トランザクションと BASE トランザクション - 補正とトランザクション # クラスターランタイムインスタンス Mule は、さまざまなトポロジーでデプロイできます。Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。このページでは、クラスタリングを介してこれらの特性を適切に融合するためのいくつかのソリューションについて説明します。1 つのアプローチですべてのユーザーに適切に対応することはできません。システム設計は、芸術と科学の両方で成り立っています。さらにサポートが必要な場合、MuleSoft プロフェッショナルサービスがアーキテクチャプランの確認や設定を行うことができます。詳細は、 [お問い合わせ](http://www.mulesoft.com/contact)​ください。 ## [](#クラスタリングについて)クラスタリングについて 以下の実現するには、アプリケーションをクラスターにデプロイすることが効果的です。 - 高可用性 (HA): クラスターの 1 つ以上のサーバーまたはデータセンターに障害が発生してもシステムを継続的に使用できます。 - フォールトトレランス (FT): 基盤となるコンポーネントの障害から回復できます。通常、回復はトランザクションロールバックまたは補正アクションによって行われます。 - スケーリング: 需要の増加に合わせてアプリケーションを垂直スケーリングできます。 このページでは、いくつかのクラスタリングソリューション候補について説明します。 ## [](#mule-高可用性)Mule 高可用性 **_Enterprise Edition_**

Mule 高可用性では、Mule の基本的なフェールオーバー機能が提供されます。(JVM またはハードウェアの致命的な障害のため) プライマリ Mule インスタンスが使用できなくなった場合、バックアップ Mule インスタンスが即座にプライマリノードになり、障害の発生したインスタンスが中断した場所から処理を再開します。システム管理者が障害が発生した Mule インスタンスを回復してオンラインに戻すと、自動的にバックアップノードになります。

シームレスなフェールオーバーは、次のようなクラスター化された Mule インスタンスですべての一時的な状態の情報を共有する分散メモリストアによって実現します。

  • SEDA サービスイベントキュー

  • メモリ内メッセージキュー

現在、Mule 高可用性は次のトランスポートで使用できます。

  • HTTP (CXF Web サービスを含む)

  • JMS

  • WebSphere MQ

  • JDBC

  • ファイル

  • FTP

  • クラスター (ローカル VM トランスポートを置き換える)

HA-arch
Mule 高可用性は、Mule Enterprise サブスクリプションで使用できます。テクニカルハイライト、要件、インストールなどの詳細は、[お問い合わせください](mailto:sales@mulesoft.com)。 ## [](#jms-キュー)JMS キュー JMS を使用すれば、メッセージを JMS キューを介してルーティングして HA & FT を実現できます。この場合、各メッセージはコンポーネント間の移動時に必ず JMS キューを介してルーティングされます。 ![jms queues](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/jms-queues.png) プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - 多くのトランザクションが必要となり、トランザクションが複雑になる可能性がある - XA を使用している場合、パフォーマンスが低下する ## [](#ロードバランサー)ロードバランサー ロードバランサーは、各サーバーの現在の負荷と現在稼働しているサーバーに基づいて、要求を各サーバーにルーティングします。ロードバランサーは、ソフトウェアベースまたはハードウェアベースになります。このアプローチは、一般的にクラスター化されたデータベースで使用されます (下記参照)。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - これ自体では完全なソリューションにはならず、フォールトトレランスが提供されない。 ## [](#例)例 このサンプルアーキテクチャでは、HTTP 要求がロードバランサーから入り、即座に JMS キューに配置されます。JMS キューは、異なるサーバー間でクラスター化されています。サーバーは、JMS キューのメッセージの処理を開始し、トランザクションのすべてをラップします。 ![http\_and\_jms](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/http-and-jms.png) サーバーがダウンすると、トランザクションがロールバックされ、別のサーバーがメッセージを取得して処理を開始します。 **注意**​: ロードバランサーはサーバー間で接続を透過的に切り替えないため、このプロセスの間に HTTP 接続が開いていると、このアプローチは機能しません。その場合、HTTP クライアントは要求を再試行する必要があります。 ## [](#データベースでの状態の保持)データベースでの状態の保持 クラスター化されたデータベースがある場合、アプリケーションですべての状態をデータベースに保存し、それを使用してサーバー間で継続的にデータを複製できます。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - すべての状態をデータベースに保存できるわけではない ## [](#ステートフルコンポーネントの処理)ステートフルコンポーネントの処理 上記の手法で大部分のアプリケーションをサポートできますが、JVM 間でより深く状態を共有することが必要になる場合もあります。 この一般的な例として、Aggregator コンポーネントが挙げられます。たとえば、2 つの異なるプロデューサーのメッセージを集計するアグリゲーターがあるとします。プロデューサー #1 は、アグリゲーターにメッセージを送信します。アグリゲーターは、そのメッセージを受信して、プロデューサー #2 がメッセージを送信するまでメモリに保持します。 ```text Producer #1 ---> |----------| |Aggregator| --> Some other component Producer #2 ---> |----------| ``` プロデューサー #1 がメッセージを送信してからプロデューサー #2 がメッセージを送信する間にアグリゲーターのあるサーバーがダウンすると、プロデューサー #2 はそのメッセージを別のサーバーに送信できません (そのサーバーにプロデューサー #1 のメッセージがないため)。 この解決策は、Terracotta、Oracle Coherence、JGroups などのクラスタリングソフトウェアを介して Aggregator コンポーネントの状態を各マシンで共有することです。 これらのツールのいずれかを使用することで、プロデューサー #2 は別のサーバーにフェールオーバーできます。MuleSoft は、これらのツールで Mule をテストしていないため、正式にはサポートしていません。 プラス面: - すべてのクラスタリングケースで機能する - キャッシュとしても機能する マイナス面: - MuleSoft で正式にサポートされていない - 効率化のためにパフォーマンス調整が必要となる ## [](#関連トピック)関連トピック このドキュメントには記載されていませんが、トポロジーを設計するときに考慮すべきいくつかのトピックが他にもあります。 - 各地域に分散しているクラスターの管理 - データパーティション分割 - ACID トランザクションと BASE トランザクション - 補正とトランザクション # クラスターランタイムインスタンス Mule は、さまざまなトポロジーでデプロイできます。Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。このページでは、オンプレミスにアプリケーションをデプロイするときにクラスタリングを介してこれらの特性を適切に融合するためのいくつかのソリューションについて説明します。1 つのアプローチですべてのユーザーに適切に対応することはできません。システム設計は、芸術と科学の両方で成り立っています。さらにサポートが必要な場合、MuleSoft プロフェッショナルサービスがアーキテクチャプランの確認や設定を行うことができます。詳細は、 [お問い合わせ](http://www.mulesoft.com/contact)​ください。 ## [](#クラスタリングについて)クラスタリングについて 以下の実現するには、アプリケーションをクラスターにデプロイすることが効果的です。 - 高可用性 (HA): クラスターの 1 つ以上のサーバーまたはデータセンターに障害が発生してもシステムを継続的に使用できます。 - フォールトトレランス (FT): 基盤となるコンポーネントの障害から回復できます。通常、回復はトランザクションロールバックまたは補正アクションによって行われます。 - スケーリング: 需要の増加に合わせてアプリケーションを垂直スケーリングできます。 このページでは、いくつかのクラスタリングソリューション候補について説明します。 ## [](#mule-高可用性)Mule 高可用性 **_Enterprise Edition_**

Mule 高可用性では、Mule の基本的なフェールオーバー機能が提供されます。(JVM またはハードウェアの致命的な障害のため) プライマリ Mule インスタンスが使用できなくなった場合、バックアップ Mule インスタンスが即座にプライマリノードになり、障害の発生したインスタンスが中断した場所から処理を再開します。システム管理者が障害が発生した Mule インスタンスを回復してオンラインに戻すと、自動的にバックアップノードになります。

シームレスなフェールオーバーは、次のようなクラスタリングされた Mule インスタンスですべての一時的な状態の情報を共有する分散メモリストアによって実現します。

  • SEDA サービスイベントキュー

  • メモリ内メッセージキュー

現在、Mule 高可用性は次のトランスポートで使用できます。

  • HTTP (CXF Web サービスを含む)

  • JMS

  • WebSphere MQ

  • JDBC

  • ファイル

  • FTP

  • クラスター (ローカル VM トランスポートを置き換える)

HA-arch
Mule 高可用性は、Mule Enterprise サブスクリプションで使用できます。テクニカルハイライト、要件、インストールなどの詳細は、[お問い合わせください](mailto:sales@mulesoft.com)。 ## [](#jms-キュー)JMS キュー JMS を使用すれば、メッセージを JMS キューを介してルーティングして HA & FT を実現できます。この場合、各メッセージはコンポーネント間の移動時に必ず JMS キューを介してルーティングされます。 ![jms queues](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/jms-queues.png) プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - 多くのトランザクションが必要となり、トランザクションが複雑になる可能性がある - XA を使用している場合、パフォーマンスが低下する ## [](#ロードバランサー)ロードバランサー ロードバランサーは、各サーバーの現在の負荷と現在稼働しているサーバーに基づいて、要求を各サーバーにルーティングします。ロードバランサーは、ソフトウェアベースまたはハードウェアベースになります。このアプローチは、一般的にクラスタリングされたデータベースで使用されます (下記参照)。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - これ自体では完全なソリューションにはならず、フォールトトレランスが提供されない。 ## [](#例)例 このサンプルアーキテクチャでは、HTTP 要求がロードバランサーから入り、即座に JMS キューに配置されます。JMS キューは、異なるサーバー間でクラスタリングされています。サーバーは、JMS キューのメッセージの処理を開始し、トランザクションのすべてをラップします。 ![http\_and\_jms](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/http-and-jms.png) サーバーがダウンすると、トランザクションがロールバックされ、別のサーバーがメッセージを取得して処理を開始します。 **注意**​: ロードバランサーはサーバー間で接続を透過的に切り替えないため、このプロセスの間に HTTP 接続が開いていると、このアプローチは機能しません。その場合、HTTP クライアントは要求を再試行する必要があります。 ## [](#データベースでの状態の保持)データベースでの状態の保持 クラスタリングされたデータベースがある場合、アプリケーションですべての状態をデータベースに保存し、それを使用してサーバー間で継続的にデータを複製できます。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - すべての状態をデータベースに保存できるわけではない ## [](#ステートフルコンポーネントの処理)ステートフルコンポーネントの処理 上記の手法で大部分のアプリケーションをサポートできますが、JVM 間でより深く状態を共有することが必要になる場合もあります。 この一般的な例として、Aggregator コンポーネントが挙げられます。たとえば、2 つの異なるプロデューサーのメッセージを集計するアグリゲーターがあるとします。プロデューサー #1 は、アグリゲーターにメッセージを送信します。アグリゲーターは、そのメッセージを受信して、プロデューサー #2 がメッセージを送信するまでメモリに保持します。 ```text Producer #1 ---> |----------| |Aggregator| --> Some other component Producer #2 ---> |----------| ``` プロデューサー #1 がメッセージを送信してからプロデューサー #2 がメッセージを送信する間にアグリゲーターのあるサーバーがダウンすると、プロデューサー #2 はそのメッセージを別のサーバーに送信できません (そのサーバーにプロデューサー #1 のメッセージがないため)。 この解決策は、Terracotta、Oracle Coherence、JGroups などのクラスタリングソフトウェアを介して Aggregator コンポーネントの状態を各マシンで共有することです。 これらのツールのいずれかを使用することで、プロデューサー #2 は別のサーバーにフェールオーバーできます。MuleSoft は、これらのツールで Mule をテストしていないため、正式にはサポートしていません。 プラス面: - すべてのクラスタリングケースで機能する - キャッシュとしても機能する マイナス面: - MuleSoft で正式にサポートされていない - 効率化のためにパフォーマンス調整が必要となる ## [](#関連トピック)関連トピック このドキュメントには記載されていませんが、トポロジーを設計するときに考慮すべきいくつかのトピックが他にもあります。 - 各地域に分散しているクラスターの管理 - データパーティション分割 - ACID トランザクションと BASE トランザクション - 補正とトランザクション # クラスターランタイムインスタンス Mule は、さまざまなトポロジーでデプロイできます。Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。このページでは、オンプレミスにアプリケーションをデプロイするときにクラスタリングを介してこれらの特性を適切に融合するためのいくつかのソリューションについて説明します。1 つのアプローチですべてのユーザーに適切に対応することはできません。システム設計は、芸術と科学の両方で成り立っています。さらにサポートが必要な場合、MuleSoft プロフェッショナルサービスがアーキテクチャプランの確認や設定を行うことができます。詳細は、 [お問い合わせ](http://www.mulesoft.com/contact)​ください。 ## [](#クラスタリングについて)クラスタリングについて 以下の実現するには、アプリケーションをクラスターにデプロイすることが効果的です。 - 高可用性 (HA): クラスターの 1 つ以上のサーバーまたはデータセンターに障害が発生してもシステムを継続的に使用できます。 - フォールトトレランス (FT): 基盤となるコンポーネントの障害から回復できます。通常、回復はトランザクションロールバックまたは補正アクションによって行われます。 - スケーリング: 需要の増加に合わせてアプリケーションを垂直スケーリングできます。 このページでは、いくつかのクラスタリングソリューション候補について説明します。 ## [](#mule-高可用性)Mule 高可用性 **_Enterprise Edition_**

Mule 高可用性では、Mule の基本的なフェールオーバー機能が提供されます。(JVM またはハードウェアの致命的な障害のため) プライマリ Mule インスタンスが使用できなくなった場合、バックアップ Mule インスタンスが即座にプライマリノードになり、障害の発生したインスタンスが中断した場所から処理を再開します。システム管理者が障害が発生した Mule インスタンスを回復してオンラインに戻すと、自動的にバックアップノードになります。

シームレスなフェールオーバーは、次のようなクラスタリングされた Mule インスタンスですべての一時的な状態の情報を共有する分散メモリストアによって実現します。

  • SEDA サービスイベントキュー

  • メモリ内メッセージキュー

現在、Mule 高可用性は次のトランスポートで使用できます。

  • HTTP (CXF Web サービスを含む)

  • JMS

  • WebSphere MQ

  • JDBC

  • ファイル

  • FTP

  • クラスター (ローカル VM トランスポートを置き換える)

Web サービスおよびリバースプロキシサーバーがある高可用性アーキテクチャ
Mule 高可用性は、Mule Enterprise サブスクリプションで使用できます。テクニカルハイライト、要件、インストールなどの詳細は、[お問い合わせください](mailto:sales@mulesoft.com)。 ## [](#jms-キュー)JMS キュー JMS を使用すれば、メッセージを JMS キューを介してルーティングして HA & FT を実現できます。この場合、各メッセージはコンポーネント間の移動時に必ず JMS キューを介してルーティングされます。 ![外部 JMS キューと連動する Mule サーバークラスター](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/jms-queues.png) プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - 多くのトランザクションが必要となり、トランザクションが複雑になる可能性がある - XA を使用している場合、パフォーマンスが低下する ## [](#ロードバランサー)ロードバランサー ロードバランサーは、各サーバーの現在の負荷と現在稼働しているサーバーに基づいて、要求を各サーバーにルーティングします。ロードバランサーは、ソフトウェアベースまたはハードウェアベースになります。このアプローチは、一般的にクラスタリングされたデータベースで使用されます (下記参照)。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - これ自体では完全なソリューションにはならず、フォールトトレランスが提供されない。 ## [](#例)例 このサンプルアーキテクチャでは、HTTP 要求がロードバランサーから入り、即座に JMS キューに配置されます。JMS キューは、異なるサーバー間でクラスタリングされています。サーバーは、JMS キューのメッセージの処理を開始し、トランザクションのすべてをラップします。 ![HTTP および JMS 設定が含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/http-and-jms.png) サーバーがダウンすると、トランザクションがロールバックされ、別のサーバーがメッセージを取得して処理を開始します。 **注意**​: ロードバランサーはサーバー間で接続を透過的に切り替えないため、このプロセスの間に HTTP 接続が開いていると、このアプローチは機能しません。その場合、HTTP クライアントは要求を再試行する必要があります。 ## [](#データベースでの状態の保持)データベースでの状態の保持 クラスタリングされたデータベースがある場合、アプリケーションですべての状態をデータベースに保存し、それを使用してサーバー間で継続的にデータを複製できます。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - すべての状態をデータベースに保存できるわけではない ## [](#ステートフルコンポーネントの処理)ステートフルコンポーネントの処理 上記の手法で大部分のアプリケーションをサポートできますが、JVM 間でより深く状態を共有することが必要になる場合もあります。 この一般的な例として、Aggregator コンポーネントが挙げられます。たとえば、2 つの異なるプロデューサーのメッセージを集計するアグリゲーターがあるとします。プロデューサー #1 は、アグリゲーターにメッセージを送信します。アグリゲーターは、そのメッセージを受信して、プロデューサー #2 がメッセージを送信するまでメモリに保持します。 ```text Producer #1 ---> |----------| |Aggregator| --> Some other component Producer #2 ---> |----------| ``` プロデューサー #1 がメッセージを送信してからプロデューサー #2 がメッセージを送信する間にアグリゲーターのあるサーバーがダウンすると、プロデューサー #2 はそのメッセージを別のサーバーに送信できません (そのサーバーにプロデューサー #1 のメッセージがないため)。 この解決策は、Terracotta、Oracle Coherence、JGroups などのクラスタリングソフトウェアを介して Aggregator コンポーネントの状態を各マシンで共有することです。 これらのツールのいずれかを使用することで、プロデューサー #2 は別のサーバーにフェールオーバーできます。MuleSoft は、これらのツールで Mule をテストしていないため、正式にはサポートしていません。 プラス面: - すべてのクラスタリングケースで機能する - キャッシュとしても機能する マイナス面: - MuleSoft で正式にサポートされていない - 効率化のためにパフォーマンス調整が必要となる ## [](#関連トピック)関連トピック このドキュメントには記載されていませんが、トポロジーを設計するときに考慮すべきいくつかのトピックが他にもあります。 - 各地域に分散しているクラスターの管理 - データパーティション分割 - ACID トランザクションと BASE トランザクション - 補正とトランザクション # クラスターランタイムインスタンス Mule は、さまざまなトポロジーでデプロイできます。Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。このページでは、オンプレミスにアプリケーションをデプロイするときにクラスタリングを介してこれらの特性を適切に融合するためのいくつかのソリューションについて説明します。1 つのアプローチですべてのユーザーに適切に対応することはできません。システム設計は、芸術と科学の両方で成り立っています。さらにサポートが必要な場合、MuleSoft プロフェッショナルサービスがアーキテクチャプランの確認や設定を行うことができます。詳細は、 [お問い合わせ](http://www.mulesoft.com/contact)​ください。 ## [](#クラスタリングについて)クラスタリングについて 以下の実現するには、アプリケーションをクラスターにデプロイすることが効果的です。 - 高可用性 (HA): クラスターの 1 つ以上のサーバーまたはデータセンターに障害が発生してもシステムを継続的に使用できます。 - フォールトトレランス (FT): 基盤となるコンポーネントの障害から回復できます。通常、回復はトランザクションロールバックまたは補正アクションによって行われます。 - スケーリング: 需要の増加に合わせてアプリケーションを垂直スケーリングできます。 このページでは、いくつかのクラスタリングソリューション候補について説明します。 ## [](#mule-高可用性)Mule 高可用性 **_Enterprise Edition_**

Mule 高可用性では、Mule の基本的なフェールオーバー機能が提供されます。(JVM またはハードウェアの致命的な障害のため) プライマリ Mule インスタンスが使用できなくなった場合、バックアップ Mule インスタンスが即座にプライマリノードになり、障害の発生したインスタンスが中断した場所から処理を再開します。システム管理者が障害が発生した Mule インスタンスを回復してオンラインに戻すと、自動的にバックアップノードになります。

シームレスなフェールオーバーは、次のようなクラスタリングされた Mule インスタンスですべての一時的な状態の情報を共有する分散メモリストアによって実現します。

  • SEDA サービスイベントキュー

  • メモリ内メッセージキュー

現在、Mule 高可用性は次のトランスポートで使用できます。

  • HTTP (CXF Web サービスを含む)

  • JMS

  • WebSphere MQ

  • JDBC

  • ファイル

  • FTP

  • クラスター (ローカル VM トランスポートを置き換える)

Web サービスおよびリバースプロキシサーバーがある高可用性アーキテクチャ
Mule 高可用性は、Mule Enterprise サブスクリプションで使用できます。テクニカルハイライト、要件、インストールなどの詳細は、[お問い合わせください](mailto:sales@mulesoft.com)。 ## [](#jms-キュー)JMS キュー JMS を使用すれば、メッセージを JMS キューを介してルーティングして HA & FT を実現できます。この場合、各メッセージはコンポーネント間の移動時に必ず JMS キューを介してルーティングされます。 ![外部 JMS キューと連動する Mule サーバークラスター](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/jms-queues.png) プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - 多くのトランザクションが必要となり、トランザクションが複雑になる可能性がある - XA を使用している場合、パフォーマンスが低下する ## [](#ロードバランサー)ロードバランサー ロードバランサーは、各サーバーの現在の負荷と現在稼働しているサーバーに基づいて、要求を各サーバーにルーティングします。ロードバランサーは、ソフトウェアベースまたはハードウェアベースになります。このアプローチは、一般的にクラスタリングされたデータベースで使用されます (下記参照)。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - これ自体では完全なソリューションにはならず、フォールトトレランスが提供されない。 ## [](#例)例 このサンプルアーキテクチャでは、HTTP 要求がロードバランサーから入り、即座に JMS キューに配置されます。JMS キューは、異なるサーバー間でクラスタリングされています。サーバーは、JMS キューのメッセージの処理を開始し、トランザクションのすべてをラップします。 ![HTTP および JMS 設定が含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/http-and-jms.png) サーバーがダウンすると、トランザクションがロールバックされ、別のサーバーがメッセージを取得して処理を開始します。 **注意**​: ロードバランサーはサーバー間で接続を透過的に切り替えないため、このプロセスの間に HTTP 接続が開いていると、このアプローチは機能しません。その場合、HTTP クライアントは要求を再試行する必要があります。 ## [](#データベースでの状態の保持)データベースでの状態の保持 クラスタリングされたデータベースがある場合、アプリケーションですべての状態をデータベースに保存し、それを使用してサーバー間で継続的にデータを複製できます。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - すべての状態をデータベースに保存できるわけではない ## [](#ステートフルコンポーネントの処理)ステートフルコンポーネントの処理 上記の手法で大部分のアプリケーションをサポートできますが、JVM 間でより深く状態を共有することが必要になる場合もあります。 この一般的な例として、Aggregator コンポーネントが挙げられます。たとえば、2 つの異なるプロデューサーのメッセージを集計するアグリゲーターがあるとします。プロデューサー #1 は、アグリゲーターにメッセージを送信します。アグリゲーターは、そのメッセージを受信して、プロデューサー #2 がメッセージを送信するまでメモリに保持します。 ```text Producer #1 ---> |----------| |Aggregator| --> Some other component Producer #2 ---> |----------| ``` プロデューサー #1 がメッセージを送信してからプロデューサー #2 がメッセージを送信する間にアグリゲーターのあるサーバーがダウンすると、プロデューサー #2 はそのメッセージを別のサーバーに送信できません (そのサーバーにプロデューサー #1 のメッセージがないため)。 この解決策は、Terracotta、Oracle Coherence、JGroups などのクラスタリングソフトウェアを介して Aggregator コンポーネントの状態を各マシンで共有することです。 これらのツールのいずれかを使用することで、プロデューサー #2 は別のサーバーにフェールオーバーできます。MuleSoft は、これらのツールで Mule をテストしていないため、正式にはサポートしていません。 プラス面: - すべてのクラスタリングケースで機能する - キャッシュとしても機能する マイナス面: - MuleSoft で正式にサポートされていない - 効率化のためにパフォーマンス調整が必要となる ## [](#関連トピック)関連トピック このドキュメントには記載されていませんが、トポロジーを設計するときに考慮すべきいくつかのトピックが他にもあります。 - 各地域に分散しているクラスターの管理 - データパーティション分割 - ACID トランザクションと BASE トランザクション - 補正とトランザクション # クラスターランタイムインスタンス Mule は、さまざまなトポロジーでデプロイできます。Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。このページでは、オンプレミスにアプリケーションをデプロイするときにクラスタリングを介してこれらの特性を適切に融合するためのいくつかのソリューションについて説明します。1 つのアプローチですべてのユーザーに適切に対応することはできません。システム設計は、芸術と科学の両方で成り立っています。さらにサポートが必要な場合、MuleSoft プロフェッショナルサービスがアーキテクチャプランの確認や設定を行うことができます。詳細は、 [お問い合わせ](http://www.mulesoft.com/contact)​ください。 ## [](#クラスタリングについて)クラスタリングについて 以下の実現するには、アプリケーションをクラスターにデプロイすることが効果的です。 - 高可用性 (HA): クラスターの 1 つ以上のサーバーまたはデータセンターに障害が発生してもシステムを継続的に使用できます。 - フォールトトレランス (FT): 基盤となるコンポーネントの障害から回復できます。通常、回復はトランザクションロールバックまたは補正アクションによって行われます。 - スケーリング: 需要の増加に合わせてアプリケーションを垂直スケーリングできます。 このページでは、いくつかのクラスタリングソリューション候補について説明します。 ## [](#mule-高可用性)Mule 高可用性 **_Enterprise Edition_**

Mule 高可用性では、Mule の基本的なフェールオーバー機能が提供されます。(JVM またはハードウェアの致命的な障害のため) プライマリ Mule インスタンスが使用できなくなった場合、バックアップ Mule インスタンスが即座にプライマリノードになり、障害の発生したインスタンスが中断した場所から処理を再開します。システム管理者が障害が発生した Mule インスタンスを回復してオンラインに戻すと、自動的にバックアップノードになります。

シームレスなフェールオーバーは、次のようなクラスタリングされた Mule インスタンスですべての一時的な状態の情報を共有する分散メモリストアによって実現します。

  • SEDA サービスイベントキュー

  • メモリ内メッセージキュー

現在、Mule 高可用性は次のトランスポートで使用できます。

  • HTTP (CXF Web サービスを含む)

  • JMS

  • WebSphere MQ

  • JDBC

  • ファイル

  • FTP

  • クラスター (ローカル VM トランスポートを置き換える)

Web サービスおよびリバースプロキシサーバーがある高可用性アーキテクチャ
Mule 高可用性は、Mule Enterprise サブスクリプションで使用できます。テクニカルハイライト、要件、インストールなどの詳細は、[お問い合わせください](mailto:sales@mulesoft.com)。 ## [](#jms-キュー)JMS キュー JMS を使用すれば、メッセージを JMS キューを介してルーティングして HA & FT を実現できます。この場合、各メッセージはコンポーネント間の移動時に必ず JMS キューを介してルーティングされます。 ![外部 JMS キューと連動する Mule サーバークラスター](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/jms-queues.png) プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - 多くのトランザクションが必要となり、トランザクションが複雑になる可能性がある - XA を使用している場合、パフォーマンスが低下する ## [](#ロードバランサー)ロードバランサー ロードバランサーは、各サーバーの現在の負荷と現在稼働しているサーバーに基づいて、要求を各サーバーにルーティングします。ロードバランサーは、ソフトウェアベースまたはハードウェアベースになります。このアプローチは、一般的にクラスタリングされたデータベースで使用されます (下記参照)。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - これ自体では完全なソリューションにはならず、フォールトトレランスが提供されない。 ## [](#例)例 このサンプルアーキテクチャでは、HTTP 要求がロードバランサーから入り、即座に JMS キューに配置されます。JMS キューは、異なるサーバー間でクラスタリングされています。サーバーは、JMS キューのメッセージの処理を開始し、トランザクションのすべてをラップします。 ![HTTP および JMS 設定が含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/http-and-jms.png) サーバーがダウンすると、トランザクションがロールバックされ、別のサーバーがメッセージを取得して処理を開始します。 **注意**​: ロードバランサーはサーバー間で接続を透過的に切り替えないため、このプロセスの間に HTTP 接続が開いていると、このアプローチは機能しません。その場合、HTTP クライアントは要求を再試行する必要があります。 ## [](#データベースでの状態の保持)データベースでの状態の保持 クラスタリングされたデータベースがある場合、アプリケーションですべての状態をデータベースに保存し、それを使用してサーバー間で継続的にデータを複製できます。 プラス面: - 簡単に実行できる - 開発者の理解が深い マイナス面: - すべての状態をデータベースに保存できるわけではない ## [](#ステートフルコンポーネントの処理)ステートフルコンポーネントの処理 上記の手法で大部分のアプリケーションをサポートできますが、JVM 間でより深く状態を共有することが必要になる場合もあります。 この一般的な例として、Aggregator コンポーネントが挙げられます。たとえば、2 つの異なるプロデューサーのメッセージを集計するアグリゲーターがあるとします。プロデューサー #1 は、アグリゲーターにメッセージを送信します。アグリゲーターは、そのメッセージを受信して、プロデューサー #2 がメッセージを送信するまでメモリに保持します。 ```text Producer #1 ---> |----------| |Aggregator| --> Some other component Producer #2 ---> |----------| ``` プロデューサー #1 がメッセージを送信してからプロデューサー #2 がメッセージを送信する間にアグリゲーターのあるサーバーがダウンすると、プロデューサー #2 はそのメッセージを別のサーバーに送信できません (そのサーバーにプロデューサー #1 のメッセージがないため)。 この解決策は、Terracotta、Oracle Coherence、JGroups などのクラスタリングソフトウェアを介して Aggregator コンポーネントの状態を各マシンで共有することです。 これらのツールのいずれかを使用することで、プロデューサー #2 は別のサーバーにフェールオーバーできます。MuleSoft は、これらのツールで Mule をテストしていないため、正式にはサポートしていません。 プラス面: - すべてのクラスタリングケースで機能する - キャッシュとしても機能する マイナス面: - MuleSoft で正式にサポートされていない - 効率化のためにパフォーマンス調整が必要となる ## [](#関連トピック)関連トピック このドキュメントには記載されていませんが、トポロジーを設計するときに考慮すべきいくつかのトピックが他にもあります。 - 各地域に分散しているクラスターの管理 - データパーティション分割 - ACID トランザクションと BASE トランザクション - 補正とトランザクション # クラスローディングの分離 Mule Runtime Engine は、Java やその他多くのサードパーティライブラリを使用して開発されています。Mule アプリケーションには、Java ライブラリ、特に Mule を拡張してインテグレーション機能を提供するモジュール (HTTP 用 Anypoint Connector や XML Module など) を含めることもできます。これらの拡張モジュールに Java (JAR) ライブラリを含めることもできます。 JVM のデフォルトのクラスローディングメカニズムにより、同じ JAR ファイルのバージョンが競合する可能性があります。Mule では、各アーティファクト (ランタイム、Mule アプリケーション、Mule 拡張) は単独で開発およびリリースされますが、これらのアーティファクトの JAR はすべて同じ場所にあります。たとえば、Mule アプリケーションで Apache Commons Collections 2.1 を使用しているとします。使用する拡張には Apache Commons Collections 3.1 が必要な場合、Commons Collections 2.1 と Commons Collections 3.1 のリソースが競合するため、アプリケーションは期待どおりに機能しない可能性があります。 - Mule 3 での解決方法 異なるアプリケーション間の競合の問題を解決するため、Mule 3 はクラスローダーの階層組織を使用していました。Mule アプリケーションは、その拡張、その中にバンドルされているライブラリ、そのランタイムライブラリを参照できますが、他のアプリケーションのライブラリにはアクセスできません。 Mule 3 では、異なる拡張のライブラリ間の競合、拡張とアプリケーションのライブラリ間の競合、アプリケーションとランタイムのライブラリ間の競合など、その他の潜在的競合が残っていました。 - Mule 4 での解決方法 Mule 4 では、クラスローディングメカニズムで上述の Mule 3 のすべての問題が対応されています。 ## [](#api-定義)API 定義 Mule Runtime Engine とアーティファクト (アプリケーション、ドメイン、ポリシー、拡張) には、各アーティファクトのコントラクトを指定し、他のアーティファクトへのアーティファクトコンテンツの公開を制限する明確な API 定義が必要です。 各アーティファクトの明確な API 定義では、クラスとライブラリのスコープを制限する方法が提供されます。これにより、すべて共有することを防ぐクラスローダーを作成できます。 ### [](#mule-4-api)Mule 4 API Mule 3 は、そのライブラリ内にバンドルされているすべてのクラスを公開します。この公開により、ランタイムの変更がカスタム Java クラスに影響する可能性があるため、Mule バージョンを別のランタイムにアップグレードするときに問題が発生していました。 Mule 4 では、Mule の拡張を容易にする明確に定義された API が備えられ、適切な拡張ポイントが明確化されています。 - コア API: Mule メッセージ。 - 拡張 API: Mule Runtime 4 を拡張するモジュール、メッセージプロセッサー、変換、その他の要素。 - Tooling API: すべての DataSense メタデータと伝播が Mule Runtime 4 に含まれるようになりました。この API は Runtime Manager エージェントにバンドルされています。 ### [](#アーティファクト-api)アーティファクト API アーティファクト (アプリケーション、ドメイン、ポリシー、または拡張) を作成する場合、そのモジュールの公開 API を宣言する必要があります。 #### [](#公開-api-の定義方法)公開 API の定義方法 アーティファクトのリソースをエクスポートするには、​[「リソースのエクスポート」](https://docs.mulesoft.com/jp/mule-runtime/4.3/how-to-export-resources)​を参照してください。 #### [](#考慮事項)考慮事項 - エクスポートされていないリソースとクラスは他のアーティファクトから参照できない。 - アーティファクトから最小限必要なパッケージとリソースのセットを公開する。 - 必要でない限り、サードパーティのライブラリはエクスポートしない。 - Guava、Apache common-collections などのサードパーティの共通ライブラリは絶対公開しない。公開すると、他のアーティファクトと競合します。 - 理想的には、アーティファクト (または JDK) のクラスのみを公開する。 ### [](#semver)Semver Mule 4 ので提供されるすべての API は、​ [セマンティックバージョニング 2.0.0](https://semver.org/)​ に従います。 ### [](#api-制限)API 制限 すべての公開 API には制限が適用される可能性があります。これらの制限により、API の使用方法が制限されます。詳細は、 [「API annotations」モジュール](https://github.com/mulesoft/api-annotations)​を参照してください。
API に定義されている API 制限により、異なるバージョン間で発生する可能性がある API の変更に対する柔軟性が向上するため、それらの制限を考慮する必要があります。
## [](#クラスローディング分離メカニズム)クラスローディング分離メカニズム API が明確に定義されたら、アーティファクトの内部クラスへのアクセスを防ぎ、外部からは公開 API にのみアクセス可能にすることができます。API を保護するため、Mule 4 はカスタムクラスローディングメカニズムを使用しています。 次の拡張ファイル構造を考えてみます。 com/example/extension/api/MyClass.class com/example/extension/internal/Util.class transformations/customer-to-user.dwl license.txt META-INF/mule-artifact/mule-artifact.json また、この拡張には次の ​`mule-artifact.json`​ 記述子ファイルがあります。 ```json { "name": "my-test-extension", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "transformations/customer-to-user.dwl" ], "exportedPackages": [ "com/example/extension/api" ] } } } ``` 次の図は ​`mule-artifact.json`​ によってエクスポートされたリソースがアプリケーション内に適用される方法を示しています。 ![単純なクラスローディング図](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/simple-classloading-diagram.png) Artifact Class Loader (アーティファクトクラスローダー) 拡張に含まれる JAR ファイルを指す通常の Java クラスローダー。このクラスローダーは、拡張のすべてのファイルとクラスを読み込みます。 Artifact Filtering Class Loader (アーティファクト絞り込みクラスローダー) アーティファクトクラスローダー上に作成されたラッパー。外部アーティファクト (アプリケーションまたは他のプラグイン) の拡張コードへのアクセスを制限します。​`mule-artifact.json`​ 記述子のコンテンツを使用して、何が公開されるかを判断します。 Extension Code (拡張コード) Mule 拡張コード。アーティファクトクラスローダー (制限なし) を使用し、プラグイン自体のリソースの検出のみが可能です。 Application Code (アプリケーションコード) Mule アプリケーションコード。拡張のアーティファクト絞り込みクラスローダーを使用して、制限されたコードやリソースにアプリケーションがアクセスすることを防ぎます。 ## [](#コネクタへの連動関係の追加)コネクタへの連動関係の追加 アプリケーションのコネクタがプロジェクト内の連動関係にアクセスする必要がある場合、連動関係を設定してコネクタのクラスローダーから参照できるようにします。これには 2 つの方法があります。 - アプリケーションの連動関係を​[共有ライブラリ](#shared-libraries)​として設定する。 - コネクタの​[追加プラグイン連動関係](#additional-plugin-dependencies)​を設定する。 ### [](#shared-libraries)共有ライブラリ アプリケーションの ​`pom.xml`​ ファイル内で宣言されたすべての連動関係 (JAR ファイルなど) は、アプリケーションのクラスローダーからは参照できますが、アプリケーション内で使用される各コネクタのクラスローダーからは参照できません。Mule Runtime Engine のクラスローディングメカニズムは、各コネクタを分離することで、他のコネクタのクラスにアクセスすることを防ぎます。コネクタのクラスローダーがアプリケーション連動関係にアクセスする必要がある場合は、この連動関係を共有ライブラリとして宣言します。 Java 用 Anypoint Connector を使用するアプリケーションについて考えてみます。コネクタはアプリケーションの ​`pom.xml`​ ファイル内で宣言された JAR 連動関係に含まれるクラスを使用する必要があります。ただし、コネクタのクラスローダーがそのクラスを見つけることができないため、それができません。コネクタがこのクラスを参照できるようにするには、そのクラスを含む連動関係を共有ライブラリとして、アプリケーションの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内で宣言する必要があります。 Anypoint Studio を使用して、外部ライブラリを使用するコネクタを設定する場合は、連動関係は自動的に共有ライブラリとして追加されます。たとえば、データベース用 Anypoint Connector をアプリケーションに追加してから Anypoint Studio を使用して接続ドライバーを設定すると、ドライバーは自動的にプロジェクトの ​`pom.xml`​ ファイルに共有ライブラリとして追加されます。 設定の手順は、​[「共有ライブラリの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept#configure-shared-libraries)​を参照してください。
共有ライブラリは、アプリケーション内のすべてのコネクタから参照可能です。共有ライブラリに含まれているのと同じクラスの別のバージョンが他のコネクタやその連動関係内にある場合は、共有ライブラリを設定すると問題が発生することがあります。
### [](#additional-plugin-dependencies)追加プラグイン連動関係 共有ライブラリを設定してアプリケーションの連動関係をアプリケーション内のすべてのコネクタから参照可能にする代わりに、追加プラグイン連動関係を設定して特定のコネクタのクラスパスを強化できます。この設定を使用すると、コネクタの ​`pom.xml`​ ファイルで新しい連動関係が宣言されたかのように、連動関係を効果的にコネクタに追加できます。 追加プラグイン連動関係を設定すると、その連動関係は設定されたコネクタでのみ使用できるようになり、アプリケーションの連動関係として宣言する必要はありません。 追加プラグイン連動関係を設定するときには、連動関係のバージョンを指定する必要があります。 設定の手順は、​[「追加プラグイン連動関係の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept#configure-plugin-dependencies)​を参照してください。 ## [](#関連情報)関連情報 - [Mule SDK - クラスローディング分離について](https://docs.mulesoft.com/mule-sdk/latest/isolation) # クラスローディングの分離 Mule Runtime Engine は、Java やその他多くのサードパーティライブラリを使用して開発されています。Mule アプリケーションには、Java ライブラリ、特に Mule を拡張してインテグレーション機能を提供するモジュール (HTTP 用 Anypoint Connector や XML Module など) を含めることもできます。これらの拡張モジュールに Java (JAR) ライブラリを含めることもできます。 JVM のデフォルトのクラスローディングメカニズムにより、同じ JAR ファイルのバージョンが競合する可能性があります。Mule では、各アーティファクト (ランタイム、Mule アプリケーション、Mule 拡張) は単独で開発およびリリースされますが、これらのアーティファクトの JAR はすべて同じ場所にあります。たとえば、Mule アプリケーションで Apache Commons Collections 2.1 を使用しているとします。使用する拡張には Apache Commons Collections 3.1 が必要な場合、Commons Collections 2.1 と Commons Collections 3.1 のリソースが競合するため、アプリケーションは期待どおりに機能しない可能性があります。 - Mule 3 での解決方法 異なるアプリケーション間の競合の問題を解決するため、Mule 3 はクラスローダーの階層組織を使用していました。Mule アプリケーションは、その拡張、その中にバンドルされているライブラリ、そのランタイムライブラリを参照できますが、他のアプリケーションのライブラリにはアクセスできません。 Mule 3 では、異なる拡張のライブラリ間の競合、拡張とアプリケーションのライブラリ間の競合、アプリケーションとランタイムのライブラリ間の競合など、その他の潜在的競合が残っていました。 - Mule 4 での解決方法 Mule 4 では、クラスローディングメカニズムで上述の Mule 3 のすべての問題が対応されています。 ## [](#api-定義)API 定義 Mule Runtime Engine とアーティファクト (アプリケーション、ドメイン、ポリシー、拡張) には、各アーティファクトのコントラクトを指定し、他のアーティファクトへのアーティファクトコンテンツの公開を制限する明確な API 定義が必要です。 各アーティファクトの明確な API 定義では、クラスとライブラリのスコープを制限する方法が提供されます。これにより、すべて共有することを防ぐクラスローダーを作成できます。 ### [](#mule-4-api)Mule 4 API Mule 3 は、そのライブラリ内にバンドルされているすべてのクラスを公開します。この公開により、ランタイムの変更がカスタム Java クラスに影響する可能性があるため、Mule バージョンを別のランタイムにアップグレードするときに問題が発生していました。 Mule 4 では、Mule の拡張を容易にする明確に定義された API が備えられ、適切な拡張ポイントが明確化されています。 - コア API: Mule メッセージ。 - 拡張 API: Mule Runtime 4 を拡張するモジュール、メッセージプロセッサー、変換、その他の要素。 - Tooling API: すべての DataSense メタデータと伝播が Mule Runtime 4 に含まれるようになりました。この API は Runtime Manager エージェントにバンドルされています。 ### [](#アーティファクト-api)アーティファクト API アーティファクト (アプリケーション、ドメイン、ポリシー、または拡張) を作成する場合、そのモジュールの公開 API を宣言する必要があります。 #### [](#公開-api-の定義方法)公開 API の定義方法 アーティファクトのリソースをエクスポートするには、​[「リソースのエクスポート」](https://docs.mulesoft.com/jp/mule-runtime/4.4/how-to-export-resources)​を参照してください。 #### [](#考慮事項)考慮事項 - エクスポートされていないリソースとクラスは他のアーティファクトから参照できない。 - アーティファクトから最小限必要なパッケージとリソースのセットを公開する。 - 必要でない限り、サードパーティのライブラリはエクスポートしない。 - Guava、Apache common-collections などのサードパーティの共通ライブラリは絶対公開しない。公開すると、他のアーティファクトと競合します。 - 理想的には、アーティファクト (または JDK) のクラスのみを公開する。 ### [](#semver)Semver Mule 4 ので提供されるすべての API は [セマンティックバージョニング 2.0.0](https://semver.org/)​ に従います。 ### [](#api-制限)API 制限 すべての公開 API には制限が適用される可能性があります。これらの制限により、API の使用方法が制限されます。詳細は、 [「API annotations」モジュール](https://github.com/mulesoft/api-annotations)​を参照してください。
API に定義されている API 制限により、異なるバージョン間で発生する可能性がある API の変更に対する柔軟性が向上するため、それらの制限を考慮する必要があります。
## [](#クラスローディング分離メカニズム)クラスローディング分離メカニズム API が明確に定義されたら、アーティファクトの内部クラスへのアクセスを防ぎ、外部からは公開 API にのみアクセス可能にすることができます。API を保護するため、Mule 4 はカスタムクラスローディングメカニズムを使用しています。 次の拡張ファイル構造を考えてみます。 com/example/extension/api/MyClass.class com/example/extension/internal/Util.class transformations/customer-to-user.dwl license.txt META-INF/mule-artifact/mule-artifact.json また、この拡張には次の ​`mule-artifact.json`​ 記述子ファイルがあります。 ```json { "name": "my-test-extension", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "transformations/customer-to-user.dwl" ], "exportedPackages": [ "com/example/extension/api" ] } } } ``` 次の図は ​`mule-artifact.json`​ によってエクスポートされたリソースがアプリケーション内に適用される方法を示しています。 ![単純なクラスローディング図](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/simple-classloading-diagram.png) Artifact Class Loader (アーティファクトクラスローダー) 拡張に含まれる JAR ファイルを指す通常の Java クラスローダー。このクラスローダーは、拡張のすべてのファイルとクラスを読み込みます。 Artifact Filtering Class Loader (アーティファクト絞り込みクラスローダー) アーティファクトクラスローダー上に作成されたラッパー。外部アーティファクト (アプリケーションまたは他のプラグイン) の拡張コードへのアクセスを制限します。​`mule-artifact.json`​ 記述子のコンテンツを使用して、何が公開されるかを判断します。 Extension Code (拡張コード) Mule 拡張コード。アーティファクトクラスローダー (制限なし) を使用し、プラグイン自体のリソースの検出のみが可能です。 Application Code (アプリケーションコード) Mule アプリケーションコード。拡張のアーティファクト絞り込みクラスローダーを使用して、制限されたコードやリソースにアプリケーションがアクセスすることを防ぎます。 ## [](#コネクタへの連動関係の追加)コネクタへの連動関係の追加 アプリケーションのコネクタがプロジェクト内の連動関係にアクセスする必要がある場合、連動関係を設定してコネクタのクラスローダーから参照できるようにします。これには 2 つの方法があります。 - アプリケーションの連動関係を​[共有ライブラリ](#shared-libraries)​として設定する。 - コネクタの​[追加プラグイン連動関係](#additional-plugin-dependencies)​を設定する。 ### [](#shared-libraries)共有ライブラリ アプリケーションの ​`pom.xml`​ ファイル内で宣言されたすべての連動関係 (JAR ファイルなど) は、アプリケーションのクラスローダーからは参照できますが、アプリケーション内で使用される各コネクタのクラスローダーからは参照できません。Mule Runtime Engine のクラスローディングメカニズムは、各コネクタを分離することで、他のコネクタのクラスにアクセスすることを防ぎます。コネクタのクラスローダーがアプリケーション連動関係にアクセスする必要がある場合は、この連動関係を共有ライブラリとして宣言します。 Java 用 Anypoint Connector を使用するアプリケーションについて考えてみます。コネクタはアプリケーションの ​`pom.xml`​ ファイル内で宣言された JAR 連動関係に含まれるクラスを使用する必要があります。ただし、コネクタのクラスローダーがそのクラスを見つけることができないため、それができません。コネクタがこのクラスを参照できるようにするには、そのクラスを含む連動関係を共有ライブラリとして、アプリケーションの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内で宣言する必要があります。 Anypoint Studio を使用して、外部ライブラリを使用するコネクタを設定する場合は、連動関係は自動的に共有ライブラリとして追加されます。たとえば、データベース用 Anypoint Connector をアプリケーションに追加してから Anypoint Studio を使用して接続ドライバーを設定すると、ドライバーは自動的にプロジェクトの ​`pom.xml`​ ファイルに共有ライブラリとして追加されます。 設定の手順は、​[「共有ライブラリの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept#configure-shared-libraries)​を参照してください。
共有ライブラリは、アプリケーション内のすべてのコネクタから参照可能です。共有ライブラリに含まれているのと同じクラスの別のバージョンが他のコネクタやその連動関係内にある場合は、共有ライブラリを設定すると問題が発生することがあります。
### [](#additional-plugin-dependencies)追加プラグイン連動関係 共有ライブラリを設定してアプリケーションの連動関係をアプリケーション内のすべてのコネクタから参照可能にする代わりに、追加プラグイン連動関係を設定して特定のコネクタのクラスパスを強化できます。この設定を使用すると、コネクタの ​`pom.xml`​ ファイルで新しい連動関係が宣言されたかのように、連動関係を効果的にコネクタに追加できます。 追加プラグイン連動関係を設定すると、その連動関係は設定されたコネクタでのみ使用できるようになり、アプリケーションの連動関係として宣言する必要はありません。 追加プラグイン連動関係を設定するときには、連動関係のバージョンを指定する必要があります。 設定の手順は、​[「追加プラグイン連動関係の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept#configure-plugin-dependencies)​を参照してください。 ## [](#関連情報)関連情報 - [Mule SDK - クラスローディング分離について](https://docs.mulesoft.com/mule-sdk/latest/isolation) # クラスローディングの分離 Mule Runtime Engine は、Java やその他多くのサードパーティライブラリを使用して開発されています。Mule アプリケーションには、Java ライブラリ、特に Mule を拡張してインテグレーション機能を提供するモジュール (HTTP 用 Anypoint Connector や XML Module など) を含めることもできます。これらの拡張モジュールに Java (JAR) ライブラリを含めることもできます。 JVM のデフォルトのクラスローディングメカニズムにより、同じ JAR ファイルのバージョンが競合する可能性があります。Mule では、各アーティファクト (ランタイム、Mule アプリケーション、Mule 拡張) は単独で開発およびリリースされますが、これらのアーティファクトの JAR はすべて同じ場所にあります。たとえば、Mule アプリケーションで Apache Commons Collections 2.1 を使用しているとします。使用する拡張には Apache Commons Collections 3.1 が必要な場合、Commons Collections 2.1 と Commons Collections 3.1 のリソースが競合するため、アプリケーションは期待どおりに機能しない可能性があります。 - Mule 3 での解決方法 異なるアプリケーション間の競合の問題を解決するため、Mule 3 はクラスローダーの階層組織を使用していました。Mule アプリケーションは、その拡張、その中にバンドルされているライブラリ、そのランタイムライブラリを参照できますが、他のアプリケーションのライブラリにはアクセスできません。 Mule 3 では、異なる拡張のライブラリ間の競合、拡張とアプリケーションのライブラリ間の競合、アプリケーションとランタイムのライブラリ間の競合など、その他の潜在的競合が残っていました。 - Mule 4 での解決方法 Mule 4 では、クラスローディングメカニズムで上述の Mule 3 のすべての問題が対応されています。 ## [](#api-定義)API 定義 Mule Runtime Engine とアーティファクト (アプリケーション、ドメイン、ポリシー、拡張) には、各アーティファクトのコントラクトを指定し、他のアーティファクトへのアーティファクトコンテンツの公開を制限する明確な API 定義が必要です。 各アーティファクトの明確な API 定義では、クラスとライブラリのスコープを制限する方法が提供されます。これにより、すべて共有することを防ぐクラスローダーを作成できます。 ### [](#mule-4-api)Mule 4 API Mule 3 は、そのライブラリ内にバンドルされているすべてのクラスを公開します。この公開により、ランタイムの変更がカスタム Java クラスに影響する可能性があるため、Mule バージョンを別のランタイムにアップグレードするときに問題が発生していました。 Mule 4 では、Mule の拡張を容易にする明確に定義された API が備えられ、適切な拡張ポイントが明確化されています。 - コア API: Mule メッセージ。 - 拡張 API: Mule Runtime 4 を拡張するモジュール、メッセージプロセッサー、変換、その他の要素。 - Tooling API: すべての DataSense メタデータと伝播が Mule Runtime 4 に含まれるようになりました。この API は Runtime Manager エージェントにバンドルされています。 ### [](#アーティファクト-api)アーティファクト API アーティファクト (アプリケーション、ドメイン、ポリシー、または拡張) を作成する場合、そのモジュールの公開 API を宣言する必要があります。 #### [](#公開-api-の定義方法)公開 API の定義方法 アーティファクトのリソースをエクスポートするには、​[「リソースのエクスポート」](https://docs.mulesoft.com/jp/mule-runtime/4.5/how-to-export-resources)​を参照してください。 #### [](#考慮事項)考慮事項 - エクスポートされていないリソースとクラスは他のアーティファクトから参照できない。 - アーティファクトから最小限必要なパッケージとリソースのセットを公開する。 - 必要でない限り、サードパーティのライブラリはエクスポートしない。 - Guava、Apache common-collections などのサードパーティの共通ライブラリは絶対公開しない。公開すると、他のアーティファクトと競合します。 - 理想的には、アーティファクト (または JDK) のクラスのみを公開する。 ### [](#semver)Semver Mule 4 ので提供されるすべての API は [セマンティックバージョニング 2.0.0](https://semver.org/)​ に従います。 ### [](#api-制限)API 制限 すべての公開 API には制限が適用される可能性があります。これらの制限により、API の使用方法が制限されます。詳細は、 [「API annotations」モジュール](https://github.com/mulesoft/api-annotations)​を参照してください。
API に定義されている API 制限により、異なるバージョン間で発生する可能性がある API の変更に対する柔軟性が向上するため、それらの制限を考慮する必要があります。
## [](#クラスローディング分離メカニズム)クラスローディング分離メカニズム API が明確に定義されたら、アーティファクトの内部クラスへのアクセスを防ぎ、外部からは公開 API にのみアクセス可能にすることができます。API を保護するため、Mule 4 はカスタムクラスローディングメカニズムを使用しています。 次の拡張ファイル構造を考えてみます。 com/example/extension/api/MyClass.class com/example/extension/internal/Util.class transformations/customer-to-user.dwl license.txt META-INF/mule-artifact/mule-artifact.json また、この拡張には次の ​`mule-artifact.json`​ 記述子ファイルがあります。 ```json { "name": "my-test-extension", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "transformations/customer-to-user.dwl" ], "exportedPackages": [ "com/example/extension/api" ] } } } ``` 次の図は ​`mule-artifact.json`​ によってエクスポートされたリソースがアプリケーション内に適用される方法を示しています。 ![単純なクラスローディング図](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/simple-classloading-diagram.png) Artifact Class Loader (アーティファクトクラスローダー) 拡張に含まれる JAR ファイルを指す通常の Java クラスローダー。このクラスローダーは、拡張のすべてのファイルとクラスを読み込みます。 Artifact Filtering Class Loader (アーティファクト絞り込みクラスローダー) アーティファクトクラスローダー上に作成されたラッパー。外部アーティファクト (アプリケーションまたは他のプラグイン) の拡張コードへのアクセスを制限します。​`mule-artifact.json`​ 記述子のコンテンツを使用して、何が公開されるかを判断します。 Extension Code (拡張コード) Mule 拡張コード。アーティファクトクラスローダー (制限なし) を使用し、プラグイン自体のリソースの検出のみが可能です。 Application Code (アプリケーションコード) Mule アプリケーションコード。拡張のアーティファクト絞り込みクラスローダーを使用して、制限されたコードやリソースにアプリケーションがアクセスすることを防ぎます。 ## [](#コネクタへの連動関係の追加)コネクタへの連動関係の追加 アプリケーションのコネクタがプロジェクト内の連動関係にアクセスする必要がある場合、連動関係を設定してコネクタのクラスローダーから参照できるようにします。これには 2 つの方法があります。 - アプリケーションの連動関係を​[共有ライブラリ](#shared-libraries)​として設定する。 - コネクタの​[追加プラグイン連動関係](#additional-plugin-dependencies)​を設定する。 ### [](#shared-libraries)共有ライブラリ アプリケーションの ​`pom.xml`​ ファイル内で宣言されたすべての連動関係 (JAR ファイルなど) は、アプリケーションのクラスローダーからは参照できますが、アプリケーション内で使用される各コネクタのクラスローダーからは参照できません。Mule Runtime Engine のクラスローディングメカニズムは、各コネクタを分離することで、他のコネクタのクラスにアクセスすることを防ぎます。コネクタのクラスローダーがアプリケーション連動関係にアクセスする必要がある場合は、この連動関係を共有ライブラリとして宣言します。 Java 用 Anypoint Connector を使用するアプリケーションについて考えてみます。コネクタはアプリケーションの ​`pom.xml`​ ファイル内で宣言された JAR 連動関係に含まれるクラスを使用する必要があります。ただし、コネクタのクラスローダーがそのクラスを見つけることができないため、それができません。コネクタがこのクラスを参照できるようにするには、そのクラスを含む連動関係を共有ライブラリとして、アプリケーションの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内で宣言する必要があります。 Anypoint Studio を使用して、外部ライブラリを使用するコネクタを設定する場合は、連動関係は自動的に共有ライブラリとして追加されます。たとえば、データベース用 Anypoint Connector をアプリケーションに追加してから Anypoint Studio を使用して接続ドライバーを設定すると、ドライバーは自動的にプロジェクトの ​`pom.xml`​ ファイルに共有ライブラリとして追加されます。 設定の手順は、​[「共有ライブラリの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept#configure-shared-libraries)​を参照してください。
共有ライブラリは、アプリケーション内のすべてのコネクタから参照可能です。共有ライブラリに含まれているのと同じクラスの別のバージョンが他のコネクタやその連動関係内にある場合は、共有ライブラリを設定すると問題が発生することがあります。
### [](#additional-plugin-dependencies)追加プラグイン連動関係 共有ライブラリを設定してアプリケーションの連動関係をアプリケーション内のすべてのコネクタから参照可能にする代わりに、追加プラグイン連動関係を設定して特定のコネクタのクラスパスを強化できます。この設定を使用すると、コネクタの ​`pom.xml`​ ファイルで新しい連動関係が宣言されたかのように、連動関係を効果的にコネクタに追加できます。 追加プラグイン連動関係を設定すると、その連動関係は設定されたコネクタでのみ使用できるようになり、アプリケーションの連動関係として宣言する必要はありません。 追加プラグイン連動関係を設定するときには、連動関係のバージョンを指定する必要があります。 設定の手順は、​[「追加プラグイン連動関係の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept#configure-plugin-dependencies)​を参照してください。 ## [](#関連情報)関連情報 - [Mule SDK - クラスローディング分離について](https://docs.mulesoft.com/mule-sdk/latest/isolation) # クラスローディングの分離 Mule Runtime Engine は、Java やその他多くのサードパーティライブラリを使用して開発されています。Mule アプリケーションには、Java ライブラリ、特に Mule を拡張してインテグレーション機能を提供するモジュール (HTTP 用 Anypoint Connector や XML Module など) を含めることもできます。これらの拡張モジュールに Java (JAR) ライブラリを含めることもできます。 JVM のデフォルトのクラスローディングメカニズムにより、同じ JAR ファイルのバージョンが競合する可能性があります。Mule では、各アーティファクト (ランタイム、Mule アプリケーション、Mule 拡張) は単独で開発およびリリースされますが、これらのアーティファクトの JAR はすべて同じ場所にあります。たとえば、Mule アプリケーションで Apache Commons Collections 2.1 を使用しているとします。使用する拡張には Apache Commons Collections 3.1 が必要な場合、Commons Collections 2.1 と Commons Collections 3.1 のリソースが競合するため、アプリケーションは期待どおりに機能しない可能性があります。 - Mule 3 での解決方法 異なるアプリケーション間の競合の問題を解決するため、Mule 3 はクラスローダーの階層組織を使用していました。Mule アプリケーションは、その拡張、その中にバンドルされているライブラリ、そのランタイムライブラリを参照できますが、他のアプリケーションのライブラリにはアクセスできません。 Mule 3 では、異なる拡張のライブラリ間の競合、拡張とアプリケーションのライブラリ間の競合、アプリケーションとランタイムのライブラリ間の競合など、その他の潜在的競合が残っていました。 - Mule 4 での解決方法 Mule 4 では、クラスローディングメカニズムで上述の Mule 3 のすべての問題が対応されています。 ## [](#api-定義)API 定義 Mule Runtime Engine とアーティファクト (アプリケーション、ドメイン、ポリシー、拡張) には、各アーティファクトのコントラクトを指定し、他のアーティファクトへのアーティファクトコンテンツの公開を制限する明確な API 定義が必要です。 各アーティファクトの明確な API 定義では、クラスとライブラリのスコープを制限する方法が提供されます。これにより、すべて共有することを防ぐクラスローダーを作成できます。 ### [](#mule-4-api)Mule 4 API Mule 3 は、そのライブラリ内にバンドルされているすべてのクラスを公開します。この公開により、ランタイムの変更がカスタム Java クラスに影響する可能性があるため、Mule バージョンを別のランタイムにアップグレードするときに問題が発生していました。 Mule 4 では、Mule の拡張を容易にする明確に定義された API が備えられ、適切な拡張ポイントが明確化されています。 - コア API: Mule メッセージ。 - 拡張 API: Mule Runtime 4 を拡張するモジュール、メッセージプロセッサー、変換、その他の要素。 - Tooling API: すべての DataSense メタデータと伝播が Mule Runtime 4 に含まれるようになりました。この API は Runtime Manager エージェントにバンドルされています。 ### [](#アーティファクト-api)アーティファクト API アーティファクト (アプリケーション、ドメイン、ポリシー、または拡張) を作成する場合、そのモジュールの公開 API を宣言する必要があります。 #### [](#公開-api-の定義方法)公開 API の定義方法 アーティファクトのリソースをエクスポートするには、​[「リソースのエクスポート」](https://docs.mulesoft.com/jp/mule-runtime/4.6/how-to-export-resources)​を参照してください。 #### [](#考慮事項)考慮事項 - エクスポートされていないリソースとクラスは他のアーティファクトから参照できない。 - アーティファクトから最小限必要なパッケージとリソースのセットを公開する。 - 必要でない限り、サードパーティのライブラリはエクスポートしない。 - Guava、Apache common-collections などのサードパーティの共通ライブラリは絶対公開しない。公開すると、他のアーティファクトと競合します。 - 理想的には、アーティファクト (または JDK) のクラスのみを公開する。 ### [](#semver)Semver Mule 4 ので提供されるすべての API は [セマンティックバージョニング 2.0.0](https://semver.org/)​ に従います。 ### [](#api-制限)API 制限 すべての公開 API には制限が適用される可能性があります。これらの制限により、API の使用方法が制限されます。詳細は、 [「API annotations」モジュール](https://github.com/mulesoft/api-annotations)​を参照してください。
API に定義されている API 制限により、異なるバージョン間で発生する可能性がある API の変更に対する柔軟性が向上するため、それらの制限を考慮する必要があります。
## [](#クラスローディング分離メカニズム)クラスローディング分離メカニズム API が明確に定義されたら、アーティファクトの内部クラスへのアクセスを防ぎ、外部からは公開 API にのみアクセス可能にすることができます。API を保護するため、Mule 4 はカスタムクラスローディングメカニズムを使用しています。 次の拡張ファイル構造を考えてみます。 com/example/extension/api/MyClass.class com/example/extension/internal/Util.class transformations/customer-to-user.dwl license.txt META-INF/mule-artifact/mule-artifact.json また、この拡張には次の ​`mule-artifact.json`​ 記述子ファイルがあります。 ```json { "name": "my-test-extension", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "transformations/customer-to-user.dwl" ], "exportedPackages": [ "com/example/extension/api" ] } } } ``` 次の図は ​`mule-artifact.json`​ によってエクスポートされたリソースがアプリケーション内に適用される方法を示しています。 ![単純なクラスローディング図](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/simple-classloading-diagram.png) Artifact Class Loader (アーティファクトクラスローダー) 拡張に含まれる JAR ファイルを指す通常の Java クラスローダー。このクラスローダーは、拡張のすべてのファイルとクラスを読み込みます。 Artifact Filtering Class Loader (アーティファクト絞り込みクラスローダー) アーティファクトクラスローダー上に作成されたラッパー。外部アーティファクト (アプリケーションまたは他のプラグイン) の拡張コードへのアクセスを制限します。​`mule-artifact.json`​ 記述子のコンテンツを使用して、何が公開されるかを判断します。 Extension Code (拡張コード) Mule 拡張コード。アーティファクトクラスローダー (制限なし) を使用し、プラグイン自体のリソースの検出のみが可能です。 Application Code (アプリケーションコード) Mule アプリケーションコード。拡張のアーティファクト絞り込みクラスローダーを使用して、制限されたコードやリソースにアプリケーションがアクセスすることを防ぎます。 ## [](#コネクタへの連動関係の追加)コネクタへの連動関係の追加 アプリケーションのコネクタがプロジェクト内の連動関係にアクセスする必要がある場合、連動関係を設定してコネクタのクラスローダーから参照できるようにします。これには 2 つの方法があります。 - アプリケーションの連動関係を​[共有ライブラリ](#shared-libraries)​として設定する。 - コネクタの​[追加プラグイン連動関係](#additional-plugin-dependencies)​を設定する。 ### [](#shared-libraries)共有ライブラリ アプリケーションの ​`pom.xml`​ ファイル内で宣言されたすべての連動関係 (JAR ファイルなど) は、アプリケーションのクラスローダーからは参照できますが、アプリケーション内で使用される各コネクタのクラスローダーからは参照できません。Mule Runtime Engine のクラスローディングメカニズムは、各コネクタを分離することで、他のコネクタのクラスにアクセスすることを防ぎます。コネクタのクラスローダーがアプリケーション連動関係にアクセスする必要がある場合は、この連動関係を共有ライブラリとして宣言します。 Java 用 Anypoint Connector を使用するアプリケーションについて考えてみます。コネクタはアプリケーションの ​`pom.xml`​ ファイル内で宣言された JAR 連動関係に含まれるクラスを使用する必要があります。ただし、コネクタのクラスローダーがそのクラスを見つけることができないため、それができません。コネクタがこのクラスを参照できるようにするには、そのクラスを含む連動関係を共有ライブラリとして、アプリケーションの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内で宣言する必要があります。 Anypoint Studio を使用して、外部ライブラリを使用するコネクタを設定する場合は、連動関係は自動的に共有ライブラリとして追加されます。たとえば、データベース用 Anypoint Connector をアプリケーションに追加してから Anypoint Studio を使用して接続ドライバーを設定すると、ドライバーは自動的にプロジェクトの ​`pom.xml`​ ファイルに共有ライブラリとして追加されます。 設定の手順は、​[「共有ライブラリの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept#configure-shared-libraries)​を参照してください。
共有ライブラリは、アプリケーション内のすべてのコネクタから参照可能です。共有ライブラリに含まれているのと同じクラスの別のバージョンが他のコネクタやその連動関係内にある場合は、共有ライブラリを設定すると問題が発生することがあります。
### [](#additional-plugin-dependencies)追加プラグイン連動関係 共有ライブラリを設定してアプリケーションの連動関係をアプリケーション内のすべてのコネクタから参照可能にする代わりに、追加プラグイン連動関係を設定して特定のコネクタのクラスパスを強化できます。この設定を使用すると、コネクタの ​`pom.xml`​ ファイルで新しい連動関係が宣言されたかのように、連動関係を効果的にコネクタに追加できます。 追加プラグイン連動関係を設定すると、その連動関係は設定されたコネクタでのみ使用できるようになり、アプリケーションの連動関係として宣言する必要はありません。 追加プラグイン連動関係を設定するときには、連動関係のバージョンを指定する必要があります。 設定の手順は、​[「追加プラグイン連動関係の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept#configure-plugin-dependencies)​を参照してください。 ## [](#関連情報)関連情報 - [Mule SDK - クラスローディング分離について](https://docs.mulesoft.com/mule-sdk/latest/isolation) # クラスローディングの分離 Mule Runtime Engine は、Java やその他多くのサードパーティライブラリを使用して開発されています。Mule アプリケーションには、Java ライブラリ、特に Mule を拡張してインテグレーション機能を提供するモジュール (HTTP 用 Anypoint Connector や XML Module など) を含めることもできます。これらの拡張モジュールに Java (JAR) ライブラリを含めることもできます。 JVM のデフォルトのクラスローディングメカニズムにより、同じ JAR ファイルのバージョンが競合する可能性があります。Mule では、各アーティファクト (ランタイム、Mule アプリケーション、Mule 拡張) は単独で開発およびリリースされますが、これらのアーティファクトの JAR はすべて同じ場所にあります。たとえば、Mule アプリケーションで Apache Commons Collections 2.1 を使用しているとします。使用する拡張には Apache Commons Collections 3.1 が必要な場合、Commons Collections 2.1 と Commons Collections 3.1 のリソースが競合するため、アプリケーションは期待どおりに機能しない可能性があります。 - Mule 3 での解決方法 異なるアプリケーション間の競合の問題を解決するため、Mule 3 はクラスローダーの階層組織を使用していました。Mule アプリケーションは、その拡張、その中にバンドルされているライブラリ、そのランタイムライブラリを参照できますが、他のアプリケーションのライブラリにはアクセスできません。 Mule 3 では、異なる拡張のライブラリ間の競合、拡張とアプリケーションのライブラリ間の競合、アプリケーションとランタイムのライブラリ間の競合など、その他の潜在的競合が残っていました。 - Mule 4 での解決方法 Mule 4 では、クラスローディングメカニズムで上述の Mule 3 のすべての問題が対応されています。 ## [](#api-定義)API 定義 Mule Runtime Engine とアーティファクト (アプリケーション、ドメイン、ポリシー、拡張) には、各アーティファクトのコントラクトを指定し、他のアーティファクトへのアーティファクトコンテンツの公開を制限する明確な API 定義が必要です。 各アーティファクトの明確な API 定義では、クラスとライブラリのスコープを制限する方法が提供されます。これにより、すべて共有することを防ぐクラスローダーを作成できます。 ### [](#mule-4-api)Mule 4 API Mule 3 は、そのライブラリ内にバンドルされているすべてのクラスを公開します。この公開により、ランタイムの変更がカスタム Java クラスに影響する可能性があるため、Mule バージョンを別のランタイムにアップグレードするときに問題が発生していました。 Mule 4 では、Mule の拡張を容易にする明確に定義された API が備えられ、適切な拡張ポイントが明確化されています。 - コア API: Mule メッセージ。 - 拡張 API: Mule Runtime 4 を拡張するモジュール、メッセージプロセッサー、変換、その他の要素。 - Tooling API: すべての DataSense メタデータと伝播が Mule Runtime 4 に含まれるようになりました。この API は Runtime Manager エージェントにバンドルされています。 ### [](#アーティファクト-api)アーティファクト API アーティファクト (アプリケーション、ドメイン、ポリシー、または拡張) を作成する場合、そのモジュールの公開 API を宣言する必要があります。 #### [](#公開-api-の定義方法)公開 API の定義方法 アーティファクトのリソースをエクスポートするには、​[「リソースのエクスポート」](https://docs.mulesoft.com/jp/mule-runtime/4.7/how-to-export-resources)​を参照してください。 #### [](#考慮事項)考慮事項 - エクスポートされていないリソースとクラスは他のアーティファクトから参照できない。 - アーティファクトから最小限必要なパッケージとリソースのセットを公開する。 - 必要でない限り、サードパーティのライブラリはエクスポートしない。 - Guava、Apache common-collections などのサードパーティの共通ライブラリは絶対公開しない。公開すると、他のアーティファクトと競合します。 - 理想的には、アーティファクト (または JDK) のクラスのみを公開する。 ### [](#semver)Semver Mule 4 で提供されるすべての API は [セマンティックバージョニング 2.0.0](https://semver.org/)​ に従います。 ### [](#api-制限)API 制限 すべての公開 API には制限が適用される可能性があります。これらの制限により、API の使用方法が制限されます。詳細は、 [「API annotations」モジュール](https://github.com/mulesoft/api-annotations)​を参照してください。
API に定義されている API 制限により、異なるバージョン間で発生する可能性がある API の変更に対する柔軟性が向上するため、それらの制限を考慮する必要があります。
## [](#クラスローディング分離メカニズム)クラスローディング分離メカニズム API が明確に定義されたら、アーティファクトの内部クラスへのアクセスを防ぎ、外部からは公開 API にのみアクセス可能にすることができます。API を保護するため、Mule 4 はカスタムクラスローディングメカニズムを使用しています。 次の拡張ファイル構造を考えてみます。 com/example/extension/api/MyClass.class com/example/extension/internal/Util.class transformations/customer-to-user.dwl license.txt META-INF/mule-artifact/mule-artifact.json また、この拡張には次の ​`mule-artifact.json`​ 記述子ファイルがあります。 ```json { "name": "my-test-extension", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "transformations/customer-to-user.dwl" ], "exportedPackages": [ "com/example/extension/api" ] } } } ``` 次の図は ​`mule-artifact.json`​ によってエクスポートされたリソースがアプリケーション内に適用される方法を示しています。 ![Mule アプリケーションのクラスローディング図](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/simple-classloading-diagram.png) Artifact Class Loader (アーティファクトクラスローダー) 拡張に含まれる JAR ファイルを指す通常の Java クラスローダー。このクラスローダーは、拡張のすべてのファイルとクラスを読み込みます。 Artifact Filtering Class Loader (アーティファクト絞り込みクラスローダー) アーティファクトクラスローダー上に作成されたラッパー。外部アーティファクト (アプリケーションまたは他のプラグイン) の拡張コードへのアクセスを制限します。​`mule-artifact.json`​ 記述子のコンテンツを使用して、何が公開されるかを判断します。 Extension Code (拡張コード) Mule 拡張コード。アーティファクトクラスローダー (制限なし) を使用し、プラグイン自体のリソースの検出のみが可能です。 Application Code (アプリケーションコード) Mule アプリケーションコード。拡張のアーティファクト絞り込みクラスローダーを使用して、制限されたコードやリソースにアプリケーションがアクセスすることを防ぎます。 ## [](#コネクタへの連動関係の追加)コネクタへの連動関係の追加 アプリケーションのコネクタがプロジェクト内の連動関係にアクセスする必要がある場合、連動関係を設定してコネクタのクラスローダーから参照できるようにします。これには 2 つの方法があります。 - アプリケーションの連動関係を​[共有ライブラリ](#shared-libraries)​として設定する。 - コネクタの​[追加プラグイン連動関係](#additional-plugin-dependencies)​を設定する。 ### [](#shared-libraries)共有ライブラリ アプリケーションの ​`pom.xml`​ ファイル内で宣言されたすべての連動関係 (JAR ファイルなど) は、アプリケーションのクラスローダーからは参照できますが、アプリケーション内で使用される各コネクタのクラスローダーからは参照できません。Mule Runtime Engine のクラスローディングメカニズムは、各コネクタを分離することで、他のコネクタのクラスにアクセスすることを防ぎます。コネクタのクラスローダーがアプリケーション連動関係にアクセスする必要がある場合は、この連動関係を共有ライブラリとして宣言します。 Java 用 Anypoint Connector を使用するアプリケーションについて考えてみます。コネクタはアプリケーションの ​`pom.xml`​ ファイル内で宣言された JAR 連動関係に含まれるクラスを使用する必要があります。ただし、コネクタのクラスローダーがそのクラスを見つけることができないため、それができません。コネクタがこのクラスを参照できるようにするには、そのクラスを含む連動関係を共有ライブラリとして、アプリケーションの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内で宣言する必要があります。 Anypoint Studio を使用して、外部ライブラリを使用するコネクタを設定する場合は、連動関係は自動的に共有ライブラリとして追加されます。たとえば、データベース用 Anypoint Connector をアプリケーションに追加してから Anypoint Studio を使用して接続ドライバーを設定すると、ドライバーは自動的にプロジェクトの ​`pom.xml`​ ファイルに共有ライブラリとして追加されます。 設定の手順は、​[「共有ライブラリの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept#configure-shared-libraries)​を参照してください。
共有ライブラリは、アプリケーション内のすべてのコネクタから参照可能です。共有ライブラリに含まれているのと同じクラスの別のバージョンが他のコネクタやその連動関係内にある場合は、共有ライブラリを設定すると問題が発生することがあります。
### [](#additional-plugin-dependencies)追加プラグイン連動関係 共有ライブラリを設定してアプリケーションの連動関係をアプリケーション内のすべてのコネクタから参照可能にする代わりに、追加プラグイン連動関係を設定して特定のコネクタのクラスパスを強化できます。この設定を使用すると、コネクタの ​`pom.xml`​ ファイルで新しい連動関係が宣言されたかのように、連動関係を効果的にコネクタに追加できます。 追加プラグイン連動関係を設定すると、その連動関係は設定されたコネクタでのみ使用できるようになり、アプリケーションの連動関係として宣言する必要はありません。 追加プラグイン連動関係を設定するときには、連動関係のバージョンを指定する必要があります。 設定の手順は、​[「追加プラグイン連動関係の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept#configure-plugin-dependencies)​を参照してください。 ## [](#関連情報)関連情報 - [Mule SDK - クラスローディング分離について](https://docs.mulesoft.com/mule-sdk/latest/isolation) # クラスローディングの分離 Mule Runtime Engine は、Java やその他多くのサードパーティライブラリを使用して開発されています。Mule アプリケーションには、Java ライブラリ、特に Mule を拡張してインテグレーション機能を提供するモジュール (HTTP 用 Anypoint Connector や XML Module など) を含めることもできます。これらの拡張モジュールに Java (JAR) ライブラリを含めることもできます。 JVM のデフォルトのクラスローディングメカニズムにより、同じ JAR ファイルのバージョンが競合する可能性があります。Mule では、各アーティファクト (ランタイム、Mule アプリケーション、Mule 拡張) は単独で開発およびリリースされますが、これらのアーティファクトの JAR はすべて同じ場所にあります。たとえば、Mule アプリケーションで Apache Commons Collections 2.1 を使用しているとします。使用する拡張には Apache Commons Collections 3.1 が必要な場合、Commons Collections 2.1 と Commons Collections 3.1 のリソースが競合するため、アプリケーションは期待どおりに機能しない可能性があります。 - Mule 3 での解決方法 異なるアプリケーション間の競合の問題を解決するため、Mule 3 はクラスローダーの階層組織を使用していました。Mule アプリケーションは、その拡張、その中にバンドルされているライブラリ、そのランタイムライブラリを参照できますが、他のアプリケーションのライブラリにはアクセスできません。 Mule 3 では、異なる拡張のライブラリ間の競合、拡張とアプリケーションのライブラリ間の競合、アプリケーションとランタイムのライブラリ間の競合など、その他の潜在的競合が残っていました。 - Mule 4 での解決方法 Mule 4 では、クラスローディングメカニズムで上述の Mule 3 のすべての問題が対応されています。 ## [](#api-定義)API 定義 Mule Runtime Engine とアーティファクト (アプリケーション、ドメイン、ポリシー、拡張) には、各アーティファクトのコントラクトを指定し、他のアーティファクトへのアーティファクトコンテンツの公開を制限する明確な API 定義が必要です。 各アーティファクトの明確な API 定義では、クラスとライブラリのスコープを制限する方法が提供されます。これにより、すべて共有することを防ぐクラスローダーを作成できます。 ### [](#mule-4-api)Mule 4 API Mule 3 は、そのライブラリ内にバンドルされているすべてのクラスを公開します。この公開により、ランタイムの変更がカスタム Java クラスに影響する可能性があるため、Mule バージョンを別のランタイムにアップグレードするときに問題が発生していました。 Mule 4 では、Mule の拡張を容易にする明確に定義された API が備えられ、適切な拡張ポイントが明確化されています。 - コア API: Mule メッセージ。 - 拡張 API: Mule Runtime 4 を拡張するモジュール、メッセージプロセッサー、変換、その他の要素。 - Tooling API: すべての DataSense メタデータと伝播が Mule Runtime 4 に含まれるようになりました。この API は Runtime Manager エージェントにバンドルされています。 ### [](#アーティファクト-api)アーティファクト API アーティファクト (アプリケーション、ドメイン、ポリシー、または拡張) を作成する場合、そのモジュールの公開 API を宣言する必要があります。 #### [](#公開-api-の定義方法)公開 API の定義方法 アーティファクトのリソースをエクスポートするには、​[「リソースのエクスポート」](https://docs.mulesoft.com/jp/mule-runtime/4.8/how-to-export-resources)​を参照してください。 #### [](#考慮事項)考慮事項 - エクスポートされていないリソースとクラスは他のアーティファクトから参照できない。 - アーティファクトから最小限必要なパッケージとリソースのセットを公開する。 - 必要でない限り、サードパーティのライブラリはエクスポートしない。 - Guava、Apache common-collections などのサードパーティの共通ライブラリは絶対公開しない。公開すると、他のアーティファクトと競合します。 - 理想的には、アーティファクト (または JDK) のクラスのみを公開する。 ### [](#semver)Semver Mule 4 で提供されるすべての API は [セマンティックバージョニング 2.0.0](https://semver.org/)​ に従います。 ### [](#api-制限)API 制限 すべての公開 API には制限が適用される可能性があります。これらの制限により、API の使用方法が制限されます。詳細は、 [「API annotations」モジュール](https://github.com/mulesoft/api-annotations)​を参照してください。
API に定義されている API 制限により、異なるバージョン間で発生する可能性がある API の変更に対する柔軟性が向上するため、それらの制限を考慮する必要があります。
## [](#クラスローディング分離メカニズム)クラスローディング分離メカニズム API が明確に定義されたら、アーティファクトの内部クラスへのアクセスを防ぎ、外部からは公開 API にのみアクセス可能にすることができます。API を保護するため、Mule 4 はカスタムクラスローディングメカニズムを使用しています。 次の拡張ファイル構造を考えてみます。 com/example/extension/api/MyClass.class com/example/extension/internal/Util.class transformations/customer-to-user.dwl license.txt META-INF/mule-artifact/mule-artifact.json また、この拡張には次の ​`mule-artifact.json`​ 記述子ファイルがあります。 ```json { "name": "my-test-extension", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "transformations/customer-to-user.dwl" ], "exportedPackages": [ "com/example/extension/api" ] } } } ``` 次の図は ​`mule-artifact.json`​ によってエクスポートされたリソースがアプリケーション内に適用される方法を示しています。 ![Mule アプリケーションのクラスローディング図](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/simple-classloading-diagram.png) Artifact Class Loader (アーティファクトクラスローダー) 拡張に含まれる JAR ファイルを指す通常の Java クラスローダー。このクラスローダーは、拡張のすべてのファイルとクラスを読み込みます。 Artifact Filtering Class Loader (アーティファクト絞り込みクラスローダー) アーティファクトクラスローダー上に作成されたラッパー。外部アーティファクト (アプリケーションまたは他のプラグイン) の拡張コードへのアクセスを制限します。​`mule-artifact.json`​ 記述子のコンテンツを使用して、何が公開されるかを判断します。 Extension Code (拡張コード) Mule 拡張コード。アーティファクトクラスローダー (制限なし) を使用し、プラグイン自体のリソースの検出のみが可能です。 Application Code (アプリケーションコード) Mule アプリケーションコード。拡張のアーティファクト絞り込みクラスローダーを使用して、制限されたコードやリソースにアプリケーションがアクセスすることを防ぎます。 ## [](#コネクタへの連動関係の追加)コネクタへの連動関係の追加 アプリケーションのコネクタがプロジェクト内の連動関係にアクセスする必要がある場合、連動関係を設定してコネクタのクラスローダーから参照できるようにします。これには 2 つの方法があります。 - アプリケーションの連動関係を​[共有ライブラリ](#shared-libraries)​として設定する。 - コネクタの​[追加プラグイン連動関係](#additional-plugin-dependencies)​を設定する。 ### [](#shared-libraries)共有ライブラリ アプリケーションの ​`pom.xml`​ ファイル内で宣言されたすべての連動関係 (JAR ファイルなど) は、アプリケーションのクラスローダーからは参照できますが、アプリケーション内で使用される各コネクタのクラスローダーからは参照できません。Mule Runtime Engine のクラスローディングメカニズムは、各コネクタを分離することで、他のコネクタのクラスにアクセスすることを防ぎます。コネクタのクラスローダーがアプリケーション連動関係にアクセスする必要がある場合は、この連動関係を共有ライブラリとして宣言します。 Java 用 Anypoint Connector を使用するアプリケーションについて考えてみます。コネクタはアプリケーションの ​`pom.xml`​ ファイル内で宣言された JAR 連動関係に含まれるクラスを使用する必要があります。ただし、コネクタのクラスローダーがそのクラスを見つけることができないため、それができません。コネクタがこのクラスを参照できるようにするには、そのクラスを含む連動関係を共有ライブラリとして、アプリケーションの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内で宣言する必要があります。 Anypoint Studio を使用して、外部ライブラリを使用するコネクタを設定する場合は、連動関係は自動的に共有ライブラリとして追加されます。たとえば、データベース用 Anypoint Connector をアプリケーションに追加してから Anypoint Studio を使用して接続ドライバーを設定すると、ドライバーは自動的にプロジェクトの ​`pom.xml`​ ファイルに共有ライブラリとして追加されます。 設定の手順は、​[「共有ライブラリの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept#configure-shared-libraries)​を参照してください。
共有ライブラリは、アプリケーション内のすべてのコネクタから参照可能です。共有ライブラリに含まれているのと同じクラスの別のバージョンが他のコネクタやその連動関係内にある場合は、共有ライブラリを設定すると問題が発生することがあります。
### [](#additional-plugin-dependencies)追加プラグイン連動関係 共有ライブラリを設定してアプリケーションの連動関係をアプリケーション内のすべてのコネクタから参照可能にする代わりに、追加プラグイン連動関係を設定して特定のコネクタのクラスパスを強化できます。この設定を使用すると、コネクタの ​`pom.xml`​ ファイルで新しい連動関係が宣言されたかのように、連動関係を効果的にコネクタに追加できます。 追加プラグイン連動関係を設定すると、その連動関係は設定されたコネクタでのみ使用できるようになり、アプリケーションの連動関係として宣言する必要はありません。 追加プラグイン連動関係を設定するときには、連動関係のバージョンを指定する必要があります。 設定の手順は、​[「追加プラグイン連動関係の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept#configure-plugin-dependencies)​を参照してください。 ## [](#関連情報)関連情報 - [Mule SDK - クラスローディング分離について](https://docs.mulesoft.com/mule-sdk/latest/isolation) # クラスローディングの分離 Mule Runtime Engine は、Java やその他多くのサードパーティライブラリを使用して開発されています。Mule アプリケーションには、Java ライブラリ、特に Mule を拡張してインテグレーション機能を提供するモジュール (HTTP 用 Anypoint Connector や XML Module など) を含めることもできます。これらの拡張モジュールに Java (JAR) ライブラリを含めることもできます。 JVM のデフォルトのクラスローディングメカニズムにより、同じ JAR ファイルのバージョンが競合する可能性があります。Mule では、各アーティファクト (ランタイム、Mule アプリケーション、Mule 拡張) は単独で開発およびリリースされますが、これらのアーティファクトの JAR はすべて同じ場所にあります。たとえば、Mule アプリケーションで Apache Commons Collections 2.1 を使用しているとします。使用する拡張には Apache Commons Collections 3.1 が必要な場合、Commons Collections 2.1 と Commons Collections 3.1 のリソースが競合するため、アプリケーションは期待どおりに機能しない可能性があります。 - Mule 3 での解決方法 異なるアプリケーション間の競合の問題を解決するため、Mule 3 はクラスローダーの階層組織を使用していました。Mule アプリケーションは、その拡張、その中にバンドルされているライブラリ、そのランタイムライブラリを参照できますが、他のアプリケーションのライブラリにはアクセスできません。 Mule 3 では、異なる拡張のライブラリ間の競合、拡張とアプリケーションのライブラリ間の競合、アプリケーションとランタイムのライブラリ間の競合など、その他の潜在的競合が残っていました。 - Mule 4 での解決方法 Mule 4 では、クラスローディングメカニズムで上述の Mule 3 のすべての問題が対応されています。 ## [](#api-定義)API 定義 Mule Runtime Engine とアーティファクト (アプリケーション、ドメイン、ポリシー、拡張) には、各アーティファクトのコントラクトを指定し、他のアーティファクトへのアーティファクトコンテンツの公開を制限する明確な API 定義が必要です。 各アーティファクトの明確な API 定義では、クラスとライブラリのスコープを制限する方法が提供されます。これにより、すべて共有することを防ぐクラスローダーを作成できます。 ### [](#mule-4-api)Mule 4 API Mule 3 は、そのライブラリ内にバンドルされているすべてのクラスを公開します。この公開により、ランタイムの変更がカスタム Java クラスに影響する可能性があるため、Mule バージョンを別のランタイムにアップグレードするときに問題が発生していました。 Mule 4 では、Mule の拡張を容易にする明確に定義された API が備えられ、適切な拡張ポイントが明確化されています。 - コア API: Mule メッセージ。 - 拡張 API: Mule Runtime 4 を拡張するモジュール、メッセージプロセッサー、変換、その他の要素。 - Tooling API: すべての DataSense メタデータと伝播が Mule Runtime 4 に含まれるようになりました。この API は Runtime Manager エージェントにバンドルされています。 ### [](#アーティファクト-api)アーティファクト API アーティファクト (アプリケーション、ドメイン、ポリシー、または拡張) を作成する場合、そのモジュールの公開 API を宣言する必要があります。 #### [](#公開-api-の定義方法)公開 API の定義方法 アーティファクトのリソースをエクスポートするには、​[「リソースのエクスポート」](https://docs.mulesoft.com/jp/mule-runtime/4.9/how-to-export-resources)​を参照してください。 #### [](#考慮事項)考慮事項 - エクスポートされていないリソースとクラスは他のアーティファクトから参照できない。 - アーティファクトから最小限必要なパッケージとリソースのセットを公開する。 - 必要でない限り、サードパーティのライブラリはエクスポートしない。 - Guava、Apache common-collections などのサードパーティの共通ライブラリは絶対公開しない。公開すると、他のアーティファクトと競合します。 - 理想的には、アーティファクト (または JDK) のクラスのみを公開する。 ### [](#semver)Semver Mule 4 で提供されるすべての API は [セマンティックバージョニング 2.0.0](https://semver.org/)​ に従います。 ### [](#api-制限)API 制限 すべての公開 API には制限が適用される可能性があります。これらの制限により、API の使用方法が制限されます。詳細は、 [「API annotations」モジュール](https://github.com/mulesoft/api-annotations)​を参照してください。
API に定義されている API 制限により、異なるバージョン間で発生する可能性がある API の変更に対する柔軟性が向上するため、それらの制限を考慮する必要があります。
## [](#クラスローディング分離メカニズム)クラスローディング分離メカニズム API が明確に定義されたら、アーティファクトの内部クラスへのアクセスを防ぎ、外部からは公開 API にのみアクセス可能にすることができます。API を保護するため、Mule 4 はカスタムクラスローディングメカニズムを使用しています。 次の拡張ファイル構造を考えてみます。 com/example/extension/api/MyClass.class com/example/extension/internal/Util.class transformations/customer-to-user.dwl license.txt META-INF/mule-artifact/mule-artifact.json また、この拡張には次の ​`mule-artifact.json`​ 記述子ファイルがあります。 ```json { "name": "my-test-extension", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "transformations/customer-to-user.dwl" ], "exportedPackages": [ "com/example/extension/api" ] } } } ``` 次の図は ​`mule-artifact.json`​ によってエクスポートされたリソースがアプリケーション内に適用される方法を示しています。 ![Mule アプリケーションのクラスローディング図](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/simple-classloading-diagram.png) Artifact Class Loader (アーティファクトクラスローダー) 拡張に含まれる JAR ファイルを指す通常の Java クラスローダー。このクラスローダーは、拡張のすべてのファイルとクラスを読み込みます。 Artifact Filtering Class Loader (アーティファクト絞り込みクラスローダー) アーティファクトクラスローダー上に作成されたラッパー。外部アーティファクト (アプリケーションまたは他のプラグイン) の拡張コードへのアクセスを制限します。​`mule-artifact.json`​ 記述子のコンテンツを使用して、何が公開されるかを判断します。 Extension Code (拡張コード) Mule 拡張コード。アーティファクトクラスローダー (制限なし) を使用し、プラグイン自体のリソースの検出のみが可能です。 Application Code (アプリケーションコード) Mule アプリケーションコード。拡張のアーティファクト絞り込みクラスローダーを使用して、制限されたコードやリソースにアプリケーションがアクセスすることを防ぎます。 ## [](#コネクタへの連動関係の追加)コネクタへの連動関係の追加 アプリケーションのコネクタがプロジェクト内の連動関係にアクセスする必要がある場合、連動関係を設定してコネクタのクラスローダーから参照できるようにします。これには 2 つの方法があります。 - アプリケーションの連動関係を​[共有ライブラリ](#shared-libraries)​として設定する。 - コネクタの​[追加プラグイン連動関係](#additional-plugin-dependencies)​を設定する。 ### [](#shared-libraries)共有ライブラリ アプリケーションの ​`pom.xml`​ ファイル内で宣言されたすべての連動関係 (JAR ファイルなど) は、アプリケーションのクラスローダーからは参照できますが、アプリケーション内で使用される各コネクタのクラスローダーからは参照できません。Mule Runtime Engine のクラスローディングメカニズムは、各コネクタを分離することで、他のコネクタのクラスにアクセスすることを防ぎます。コネクタのクラスローダーがアプリケーション連動関係にアクセスする必要がある場合は、この連動関係を共有ライブラリとして宣言します。 Java 用 Anypoint Connector を使用するアプリケーションについて考えてみます。コネクタはアプリケーションの ​`pom.xml`​ ファイル内で宣言された JAR 連動関係に含まれるクラスを使用する必要があります。ただし、コネクタのクラスローダーがそのクラスを見つけることができないため、それができません。コネクタがこのクラスを参照できるようにするには、そのクラスを含む連動関係を共有ライブラリとして、アプリケーションの ​`pom.xml`​ ファイルの Mule Maven プラグイン設定内で宣言する必要があります。 Anypoint Studio を使用して、外部ライブラリを使用するコネクタを設定する場合は、連動関係は自動的に共有ライブラリとして追加されます。たとえば、データベース用 Anypoint Connector をアプリケーションに追加してから Anypoint Studio を使用して接続ドライバーを設定すると、ドライバーは自動的にプロジェクトの ​`pom.xml`​ ファイルに共有ライブラリとして追加されます。 設定の手順は、​[「共有ライブラリの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept#configure-shared-libraries)​を参照してください。
共有ライブラリは、アプリケーション内のすべてのコネクタから参照可能です。共有ライブラリに含まれているのと同じクラスの別のバージョンが他のコネクタやその連動関係内にある場合は、共有ライブラリを設定すると問題が発生することがあります。
### [](#additional-plugin-dependencies)追加プラグイン連動関係 共有ライブラリを設定してアプリケーションの連動関係をアプリケーション内のすべてのコネクタから参照可能にする代わりに、追加プラグイン連動関係を設定して特定のコネクタのクラスパスを強化できます。この設定を使用すると、コネクタの ​`pom.xml`​ ファイルで新しい連動関係が宣言されたかのように、連動関係を効果的にコネクタに追加できます。 追加プラグイン連動関係を設定すると、その連動関係は設定されたコネクタでのみ使用できるようになり、アプリケーションの連動関係として宣言する必要はありません。 追加プラグイン連動関係を設定するときには、連動関係のバージョンを指定する必要があります。 設定の手順は、​[「追加プラグイン連動関係の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept#configure-plugin-dependencies)​を参照してください。 ## [](#関連情報)関連情報 - [Mule SDK - クラスローディング分離について](https://docs.mulesoft.com/mule-sdk/latest/isolation) # グラフィカルなマッピングの構築 (Anypoint Studio) Transform Message コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。それぞれの作業を行うと、アクションを記述した行が DataWeave コードに追加されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、それらの要素を連結するラインが作成されます。 ![using dataweave in studio 8e6e0](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/using-dataweave-in-studio-8e6e0.png) ## [](#構造のマッピング)構造のマッピング 要素のリストまたは内部項目を含むハイレベル構造を出力の要素にドラッグします。マップされた構造を覆うように影付きの領域が作成されます。これらの構造で同じ名前を持つ項目も自動的にマップされます。 ![using dataweave in studio 6b171](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/using-dataweave-in-studio-6b171.png) ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリー上の項目をダブルクリックします。関数アイコン ​![using dataweave in studio 66cdc](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/using-dataweave-in-studio-66cdc.png)​ が隣に表示されます。 2. デフォルトの ​`null`​ 値を項目に割り当てるための新しい行が DataWeave コードに追加されます。この行はハイライトされています。値を好きなように変更してください。 次の値を追加できます。 - " "で囲んだ固定文字列値。 - 入力項目への参照。 - 関数を含む DataWeave ステートメント。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # グラフィカルなマッピングの構築 (Anypoint Studio) Transform Message コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。それぞれの作業を行うと、アクションを記述した行が DataWeave コードに追加されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、それらの要素を連結するラインが作成されます。 ![using dataweave in studio 8e6e0](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/using-dataweave-in-studio-8e6e0.png) ## [](#構造のマッピング)構造のマッピング 要素のリストまたは内部項目を含むハイレベル構造を出力の要素にドラッグします。マップされた構造を覆うように影付きの領域が作成されます。これらの構造で同じ名前を持つ項目も自動的にマップされます。 ![using dataweave in studio 6b171](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/using-dataweave-in-studio-6b171.png) ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリー上の項目をダブルクリックします。関数アイコン ​![using dataweave in studio 66cdc](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/using-dataweave-in-studio-66cdc.png)​ が隣に表示されます。 2. デフォルトの ​`null`​ 値を項目に割り当てるための新しい行が DataWeave コードに追加されます。この行はハイライトされています。値を好きなように変更してください。 次の値を追加できます。 - 「 」で囲んだ固定文字列値。 - 入力項目への参照。 - 関数を含む DataWeave ステートメント。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # グラフィカルなマッピングの構築 (Anypoint Studio) Transform Message コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。それぞれの作業を行うと、アクションを記述した行が DataWeave コードに追加されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、それらの要素を連結するラインが作成されます。 ![using dataweave in studio 8e6e0](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/using-dataweave-in-studio-8e6e0.png) ## [](#構造のマッピング)構造のマッピング 要素のリストまたは内部項目を含むハイレベル構造を出力の要素にドラッグします。マップされた構造を覆うように影付きの領域が作成されます。これらの構造で同じ名前を持つ項目も自動的にマップされます。 ![using dataweave in studio 6b171](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/using-dataweave-in-studio-6b171.png) ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリー上の項目をダブルクリックします。関数アイコン ![using dataweave in studio 66cdc](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/using-dataweave-in-studio-66cdc.png) が隣に表示されます。 2. デフォルトの ​`null`​ 値を項目に割り当てるための新しい行が DataWeave コードに追加されます。この行はハイライトされています。値を好きなように変更してください。 次の値を追加できます。 - " " で囲んだ固定文字列値。 - 入力項目への参照。 - 関数を含む DataWeave ステートメント。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # グラフィカルなマッピングの構築 (Anypoint Studio) Transform Message コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。それぞれの作業を行うと、アクションを記述した行が DataWeave コードに追加されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、それらの要素を連結するラインが作成されます。 ![using dataweave in studio 8e6e0](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/using-dataweave-in-studio-8e6e0.png) ## [](#構造のマッピング)構造のマッピング 要素のリストまたは内部項目を含むハイレベル構造を出力の要素にドラッグします。マップされた構造を覆うように影付きの領域が作成されます。これらの構造で同じ名前を持つ項目も自動的にマップされます。 ![using dataweave in studio 6b171](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/using-dataweave-in-studio-6b171.png) ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリー上の項目をダブルクリックします。関数アイコン ​![using dataweave in studio 66cdc](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/using-dataweave-in-studio-66cdc.png)​ が隣に表示されます。 2. デフォルトの ​`null`​ 値を項目に割り当てるための新しい行が DataWeave コードに追加されます。この行はハイライトされています。値を好きなように変更してください。 次の値を追加できます。 - " "で囲んだ固定文字列値。 - 入力項目への参照。 - 関数を含む DataWeave ステートメント。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # グラフィカルなマッピングの構築 (Anypoint Studio) Transform Message コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。それぞれの作業を行うと、アクションを記述した行が DataWeave コードに追加されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、それらの要素を連結するラインが作成されます。 ![using dataweave in studio 8e6e0](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/using-dataweave-in-studio-8e6e0.png) ## [](#構造のマッピング)構造のマッピング 要素のリストまたは内部項目を含むハイレベル構造を出力の要素にドラッグします。マップされた構造を覆うように影付きの領域が作成されます。これらの構造で同じ名前を持つ項目も自動的にマップされます。 ![using dataweave in studio 6b171](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/using-dataweave-in-studio-6b171.png) ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリー上の項目をダブルクリックします。関数アイコン ​![using dataweave in studio 66cdc](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/using-dataweave-in-studio-66cdc.png)​ が隣に表示されます。 2. デフォルトの ​`null`​ 値を項目に割り当てるための新しい行が DataWeave コードに追加されます。この行はハイライトされています。値を好きなように変更してください。 次の値を追加できます。 - " "で囲んだ固定文字列値。 - 入力項目への参照。 - 関数を含む DataWeave ステートメント。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # グラフィカルなマッピングの構築 (Anypoint Studio) Transform Message コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。それぞれの作業を行うと、アクションを記述した行が DataWeave コードに追加されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、それらの要素を連結するラインが作成されます。 ![JSON の入構造と出力構造](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/using-dataweave-in-studio-8e6e0.png) ## [](#構造のマッピング)構造のマッピング 要素のリストまたは内部項目を含むハイレベル構造を出力の要素にドラッグします。マップされた構造を覆うように影付きの領域が作成されます。これらの構造で同じ名前を持つ項目も自動的にマップされます。 ![ItemID や DeliveryMethod などの項目が表示されている項目のリスト](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/using-dataweave-in-studio-6b171.png) ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリー上の項目をダブルクリックします。これにより、その横に関数アイコン ​![関数アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/using-dataweave-in-studio-66cdc.png)​ が追加されます。 2. デフォルトの ​`null`​ 値を項目に割り当てるための新しい行が DataWeave コードに追加されます。この行はハイライトされています。値を好きなように変更してください。 次の値を追加できます。 - " "で囲んだ固定文字列値。 - 入力項目への参照。 - 関数を含む DataWeave ステートメント。 ## [](#関連情報)関連情報 - [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about) - [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-workflow-create-mapping-ui-studio) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # グラフィカルなマッピングの構築 (Anypoint Studio) Transform Message コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。それぞれの作業を行うと、アクションを記述した行が DataWeave コードに追加されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、それらの要素を連結するラインが作成されます。 ![JSON の入構造と出力構造](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/using-dataweave-in-studio-8e6e0.png) ## [](#構造のマッピング)構造のマッピング 要素のリストまたは内部項目を含むハイレベル構造を出力の要素にドラッグします。マップされた構造を覆うように影付きの領域が作成されます。これらの構造で同じ名前を持つ項目も自動的にマップされます。 ![ItemID や DeliveryMethod などの項目が表示されている項目のリスト](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/using-dataweave-in-studio-6b171.png) ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリー上の項目をダブルクリックします。これにより、その横に関数アイコン ​![関数アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/using-dataweave-in-studio-66cdc.png)​ が追加されます。 2. デフォルトの ​`null`​ 値を項目に割り当てるための新しい行が DataWeave コードに追加されます。この行はハイライトされています。値を好きなように変更してください。 次の値を追加できます。 - " "で囲んだ固定文字列値。 - 入力項目への参照。 - 関数を含む DataWeave ステートメント。 ## [](#関連情報)関連情報 - [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about) - [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-workflow-create-mapping-ui-studio) - [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # グラフィカルなマッピングの構築 (Design Center) Transform コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。各作業では、それぞれのアクションを記述した DataWeave ソースコードが生成されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、2 つの要素を連結するラインが作成されます。 ![to transform data c2fc6](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/to-transform-data-c2fc6.png) ![to transform data afe5b](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/to-transform-data-afe5b.png) ## [](#マッピングの削除)マッピングの削除 1. 対応する入力要素を選択します。 ゴミ箱のアイコン ​![graphically construct mapping design center task 2457b](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/graphically-construct-mapping-design-center-task-2457b.png)​ が接続上に表示されます。 2. ゴミ箱のアイコンをクリックします。 ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリーで (子を持たない) 項目をダブルクリックします。関数アイコン ​![graphically construct mapping design center task 8a822](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/graphically-construct-mapping-design-center-task-8a822.png)​ が隣に表示されます。 2. デフォルト値の ​`null`​ が入ったボックスが表示されます。​`null`​ を好きなように変更します。例: - " "で囲んだ固定テキスト値。 - 入力項目への参照。 - DataWeave 関数を含むステートメント。 これは、各項目が別の項目を直接参照したり、他の項目への参照が関与する関数の結果が項目に表示されたりするスプレッドシートと似ています。
関数を削除するには、隣に表示されているゴミ箱のアイコンをクリックします。
## [](#関連情報)関連情報 [DataWeave 関数リファレンス](https://docs.mulesoft.com/jp/dataweave/2.3/dw-functions) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # グラフィカルなマッピングの構築 (Design Center) Transform コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。各作業では、それぞれのアクションを記述した DataWeave ソースコードが生成されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、2 つの要素を連結するラインが作成されます。 ![to transform data c2fc6](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/to-transform-data-c2fc6.png) ![to transform data afe5b](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/to-transform-data-afe5b.png) ## [](#マッピングの削除)マッピングの削除 1. 対応する入力要素を選択します。 ゴミ箱のアイコン ​![graphically construct mapping design center task 2457b](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/graphically-construct-mapping-design-center-task-2457b.png)​ が接続上に表示されます。 2. ゴミ箱のアイコンをクリックします。 ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリーで (子を持たない) 項目をダブルクリックします。関数アイコン ​![graphically construct mapping design center task 8a822](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/graphically-construct-mapping-design-center-task-8a822.png)​ が隣に表示されます。 2. デフォルト値の ​`null`​ が入ったボックスが表示されます。​`null`​ を好きなように変更します。例: - " "で囲んだ固定テキスト値。 - 入力項目への参照。 - DataWeave 関数を含むステートメント。 これは、各項目が別の項目を直接参照したり、他の項目への参照が関与する関数の結果が項目に表示されたりするスプレッドシートと似ています。
関数を削除するには、隣に表示されているゴミ箱のアイコンをクリックします。
## [](#関連情報)関連情報 [DataWeave 関数リファレンス](https://docs.mulesoft.com/dataweave/latest/dw-functions) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # グラフィカルなマッピングの構築 (Design Center) Transform コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。各作業では、それぞれのアクションを記述した DataWeave ソースコードが生成されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、2 つの要素を連結するラインが作成されます。 ![to transform data c2fc6](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/to-transform-data-c2fc6.png) ![to transform data afe5b](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/to-transform-data-afe5b.png) ## [](#マッピングの削除)マッピングの削除 1. 対応する入力要素を選択します。 ゴミ箱のアイコン ![graphically construct mapping design center task 2457b](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/graphically-construct-mapping-design-center-task-2457b.png) が接続上に表示されます。 2. ゴミ箱のアイコンをクリックします。 ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリーで (子を持たない) 項目をダブルクリックします。関数アイコン ![graphically construct mapping design center task 8a822](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/graphically-construct-mapping-design-center-task-8a822.png) が隣に表示されます。 2. デフォルト値の ​`null`​ が入ったボックスが表示されます。​`null`​ を好きなように変更します。例: - " "で囲んだ固定テキスト値。 - 入力項目への参照。 - DataWeave 関数を含むステートメント。 これは、各項目が別の項目を直接参照したり、他の項目への参照が関与する関数の結果が項目に表示されたりするスプレッドシートと似ています。
関数を削除するには、隣に表示されているゴミ箱のアイコンをクリックします。
## [](#関連情報)関連情報 [DataWeave 関数リファレンス](https://docs.mulesoft.com/dataweave/latest/dw-functions) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # グラフィカルなマッピングの構築 (Design Center) Transform コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。各作業では、それぞれのアクションを記述した DataWeave ソースコードが生成されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、2 つの要素を連結するラインが作成されます。 ![to transform data c2fc6](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/to-transform-data-c2fc6.png) ![to transform data afe5b](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/to-transform-data-afe5b.png) ## [](#マッピングの削除)マッピングの削除 1. 対応する入力要素を選択します。 ゴミ箱のアイコン ​![graphically construct mapping design center task 2457b](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/graphically-construct-mapping-design-center-task-2457b.png)​ が接続上に表示されます。 2. ゴミ箱のアイコンをクリックします。 ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリーで (子を持たない) 項目をダブルクリックします。関数アイコン ​![graphically construct mapping design center task 8a822](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/graphically-construct-mapping-design-center-task-8a822.png)​ が隣に表示されます。 2. デフォルト値の ​`null`​ が入ったボックスが表示されます。​`null`​ を好きなように変更します。例: - " "で囲んだ固定テキスト値。 - 入力項目への参照。 - DataWeave 関数を含むステートメント。 これは、各項目が別の項目を直接参照したり、他の項目への参照が関与する関数の結果が項目に表示されたりするスプレッドシートと似ています。
関数を削除するには、隣に表示されているゴミ箱のアイコンをクリックします。
## [](#関連情報)関連情報 [DataWeave 関数リファレンス](https://docs.mulesoft.com/dataweave/latest/dw-functions) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # グラフィカルなマッピングの構築 (Design Center) Transform コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。各作業では、それぞれのアクションを記述した DataWeave ソースコードが生成されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、2 つの要素を連結するラインが作成されます。 ![to transform data c2fc6](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/to-transform-data-c2fc6.png) ![to transform data afe5b](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/to-transform-data-afe5b.png) ## [](#マッピングの削除)マッピングの削除 1. 対応する入力要素を選択します。 接続にゴミ箱アイコン ​![削除アイコン](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/graphically-construct-mapping-design-center-task-2457b.png)​ が表示されます。 2. ゴミ箱のアイコンをクリックします。 ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリーで (子を持たない) 項目をダブルクリックします。これにより、その横に関数アイコン ​![関数アイコン](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/graphically-construct-mapping-design-center-task-8a822.png)​ が追加されます。 2. デフォルト値の ​`null`​ が入ったボックスが表示されます。​`null`​ を好きなように変更します。例: - " "で囲んだ固定テキスト値。 - 入力項目への参照。 - DataWeave 関数を含むステートメント。 これは、各項目が別の項目を直接参照したり、他の項目への参照が関与する関数の結果が項目に表示されたりするスプレッドシートと似ています。
関数を削除するには、隣に表示されているゴミ箱のアイコンをクリックします。
## [](#関連情報)関連情報 [DataWeave 関数リファレンス](https://docs.mulesoft.com/dataweave/latest/dw-functions) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # グラフィカルなマッピングの構築 (Design Center) Transform コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。各作業では、それぞれのアクションを記述した DataWeave ソースコードが生成されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、2 つの要素を連結するラインが作成されます。 ![ペイロードの項目種別および価格からの変換フロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/to-transform-data-c2fc6.png) ![\[title (タイトル)\]、\[author (作成者)\]、\[item (項目)\]、\[year (年)\] のプロパティが表示されているテーブル](_images/to-transform-data-afe5b.png) ## [](#マッピングの削除)マッピングの削除 1. 対応する入力要素を選択します。 接続にゴミ箱アイコン ​![削除アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/graphically-construct-mapping-design-center-task-2457b.png)​ が表示されます。 2. ゴミ箱のアイコンをクリックします。 ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリーで (子を持たない) 項目をダブルクリックします。これにより、その横に関数アイコン ​![関数アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/graphically-construct-mapping-design-center-task-8a822.png)​ が追加されます。 2. デフォルト値の ​`null`​ が入ったボックスが表示されます。​`null`​ を好きなように変更します。例: - " "で囲んだ固定テキスト値。 - 入力項目への参照。 - DataWeave 関数を含むステートメント。 これは、各項目が別の項目を直接参照したり、他の項目への参照が関与する関数の結果が項目に表示されたりするスプレッドシートと似ています。
関数を削除するには、隣に表示されているゴミ箱のアイコンをクリックします。
## [](#関連情報)関連情報 [DataWeave 関数リファレンス](https://docs.mulesoft.com/dataweave/latest/dw-functions) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # グラフィカルなマッピングの構築 (Design Center) Transform コンポーネントのグラフィカル UI を使用して、以下の作業を行うことができます。各作業では、それぞれのアクションを記述した DataWeave ソースコードが生成されます。 ## [](#項目のマッピング)項目のマッピング 入力構造の要素を出力構造上の別の要素までドラッグすると、2 つの要素を連結するラインが作成されます。 ![ペイロードの項目種別および価格からの変換フロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/to-transform-data-c2fc6.png) ![\[title (タイトル)\]、\[author (作成者)\]、\[item (項目)\]、\[year (年)\] のプロパティが表示されているテーブル](_images/to-transform-data-afe5b.png) ## [](#マッピングの削除)マッピングの削除 1. 対応する入力要素を選択します。 接続にゴミ箱アイコン ​![削除アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/graphically-construct-mapping-design-center-task-2457b.png)​ が表示されます。 2. ゴミ箱のアイコンをクリックします。 ## [](#固定値または関数の設定)固定値または関数の設定 1. 出力ツリーで (子を持たない) 項目をダブルクリックします。これにより、その横に関数アイコン ​![関数アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/graphically-construct-mapping-design-center-task-8a822.png)​ が追加されます。 2. デフォルト値の ​`null`​ が入ったボックスが表示されます。​`null`​ を好きなように変更します。例: - " "で囲んだ固定テキスト値。 - 入力項目への参照。 - DataWeave 関数を含むステートメント。 これは、各項目が別の項目を直接参照したり、他の項目への参照が関与する関数の結果が項目に表示されたりするスプレッドシートと似ています。
関数を削除するには、隣に表示されているゴミ箱のアイコンをクリックします。
## [](#関連情報)関連情報 [DataWeave 関数リファレンス](https://docs.mulesoft.com/dataweave/latest/dw-functions) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # グローバル設定 Mule アプリケーションのグローバル設定 (デフォルトトランザクションタイムアウトやデフォルトエラーハンドラーなど) は、​[Mule 設定ファイル](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-configuration)​のルートレベルにある ​``​ 要素で設定できます。 ## [](#studio-からグローバル設定を作成する)Studio からグローバル設定を作成する グローバル設定を作成する手順は次のとおりです。 1. Studio で ​**\[Global Elements (グローバル要素)\]**​ タブに移動して、​**\[Create (作成)\]**​ をクリックします。 ![create-global-settings](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-global-settings-create.png) 2. **\[Global Configurations (グローバル設定)\]**​ > ​**\[Configuration (設定)\]**​ を選択します。 ![configure-global-settings](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-global-configurations.png) 3. **\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ と ​**\[HA Profile (HA プロファイル)\]**​ の値を設定します。 ## [](#xml-の編集によるグローバル設定の作成)XML の編集によるグローバル設定の作成 次の例では、グローバルエラーハンドラーを定義してから、デフォルトのトランザクションタイムアウトを指定したグローバル設定を定義し、グローバルエラーハンドラーをデフォルトとして参照しています。 ```xml ... ... ... ``` ## [](#グローバル設定リファレンス)グローバル設定リファレンス 次の表に ​``​ 要素のすべての属性を示します。
名前 型 必須 デフォルト 説明

defaultResponseTimeout

string

いいえ

10000

同期応答を待つデフォルトの時間 (ミリ秒)。

defaultTransactionTimeout

string

いいえ

30000

トランザクションのデフォルトのタイムアウト (ミリ秒)。これは、トランザクションでも設定できます。その場合、このデフォルトではなくトランザクションの設定が使用されます。

defaultErrorHandler-ref

string

いいえ

なし

すべてのフローのデフォルトのエラーハンドラー。これは、グローバルエラーハンドラーへの参照である必要があります。

shutdownTimeout

integer

いいえ

5000

(Mule 2.2.2 以降) Mule をシャットダウンする前に、処理中のメッセージの処理が完了するのを待つ時間 (ミリ秒)。このしきい値に達すると、Mule はスレッドの中断を開始するため、メッセージが失われる可能性があります。同じ Mule インスタンスに非常に多くのサービスがある場合や、処理に数秒以上かかるコンポーネントがある場合、あるいは大きなペイロードや遅いトランスポートを使用している場合は、シャットダウンが適切に行われるようにこの値を大きくする必要があります。指定した値はサービスに適用され、ディスパッチャーにも別個に適用されます。そのため、デフォルト値の 5000 ミリ秒の場合、シャットダウンが開始されてから Mule がメッセージの処理とディスパッチを適切に行う時間は 10 秒間です。

maxQueueTransactionFilesSize

integer

いいえ

500

トランザクションログファイルが永続的なトランザクションキューのために使用するおおよその最大容量 (メガバイト)。この数値は、XA トランザクションとローカルトランザクションの両方のトランザクションログファイルセットに適用されることを考慮する必要があります。両方の種別のトランザクションが使用されている場合は、使用されるおおよその最大容量は、設定値の 2 倍になります。

defaultObjectSerializer-ref

string

いいえ

なし

省略可能。アプリケーションのデフォルトとして使用する ObjectSerializer への参照。
### [](#configuration-の子要素) の子要素
名前 説明

dynamic-config-expiration

省略可能。動的設定のデフォルトの有効期限設定。コネクタによって使用されます。これは、コネクタでも設定できます。その場合、このデフォルトではなくコネクタの設定が使用されます。
設定の詳細は、​「動的設定の有効期限」​を参照してください。

cluster-config

省略可能。Mule アプリケーションクラスターの設定。
設定の詳細は、​「高パフォーマンスのためのクラスタリング」​を参照してください。
## [](#関連情報)関連情報 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling) - [Dynamic Configurations (動的設定)](https://docs.mulesoft.com/mule-sdk/latest/static-dynamic-configs) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-high-availability-ha-clusters) # グローバル設定 Mule アプリケーションのグローバル設定 (デフォルトトランザクションタイムアウトやデフォルトエラーハンドラーなど) は、​[Mule 設定ファイル](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-configuration)​のルートレベルにある ​``​ 要素で設定できます。 ## [](#studio-からグローバル設定を作成する)Studio からグローバル設定を作成する グローバル設定を作成する手順は次のとおりです。 1. Studio で ​**\[Global Elements (グローバル要素)\]**​ タブに移動して、​**\[Create (作成)\]**​ をクリックします。 ![create-global-settings](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-global-settings-create.png) 2. **\[Global Configurations (グローバル設定)\]**​ > ​**\[Configuration (設定)\]**​ を選択します。 ![configure-global-settings](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-global-configurations.png) 3. **\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ と ​**\[HA Profile (HA プロファイル)\]**​ の値を設定します。 ## [](#xml-の編集によるグローバル設定の作成)XML の編集によるグローバル設定の作成 次の例では、グローバルエラーハンドラーを定義してから、デフォルトのトランザクションタイムアウトを指定したグローバル設定を定義し、グローバルエラーハンドラーをデフォルトとして参照しています。 ```xml ... ... ... ``` ## [](#グローバル設定リファレンス)グローバル設定リファレンス 次の表に ​``​ 要素のすべての属性を示します。
名前 型 必須 デフォルト 説明

defaultResponseTimeout

string

いいえ

10000

同期応答を待つデフォルトの時間 (ミリ秒)。

defaultTransactionTimeout

string

いいえ

30000

トランザクションのデフォルトのタイムアウト (ミリ秒)。これは、トランザクションでも設定できます。その場合、このデフォルトではなくトランザクションの設定が使用されます。

defaultErrorHandler-ref

string

いいえ

なし

すべてのフローのデフォルトのエラーハンドラー。これは、グローバルエラーハンドラーへの参照である必要があります。

shutdownTimeout

integer

いいえ

5000

(Mule 2.2.2 以降) Mule をシャットダウンする前に、処理中のメッセージの処理が完了するのを待つ時間 (ミリ秒)。このしきい値に達すると、Mule はスレッドの中断を開始するため、メッセージが失われる可能性があります。同じ Mule インスタンスに非常に多くのサービスがある場合や、処理に数秒以上かかるコンポーネントがある場合、あるいは大きなペイロードや遅いトランスポートを使用している場合は、シャットダウンが適切に行われるようにこの値を大きくする必要があります。指定した値はサービスに適用され、ディスパッチャーにも別個に適用されます。そのため、デフォルト値の 5000 ミリ秒の場合、シャットダウンが開始されてから Mule がメッセージの処理とディスパッチを適切に行う時間は 5 秒間です。

maxQueueTransactionFilesSize

integer

いいえ

500

トランザクションログファイルが永続的なトランザクションキューのために使用するおおよその最大容量 (メガバイト)。この数値は、XA トランザクションとローカルトランザクションの両方のトランザクションログファイルセットに適用されることを考慮する必要があります。両方の種別のトランザクションが使用されている場合は、使用されるおおよその最大容量は、設定値の 2 倍になります。

defaultObjectSerializer-ref

string

いいえ

なし

省略可能。アプリケーションのデフォルトとして使用する ObjectSerializer への参照。
### [](#configuration-の子要素) の子要素
名前 説明

dynamic-config-expiration

省略可能。動的設定のデフォルトの有効期限設定。コネクタによって使用されます。これは、コネクタでも設定できます。その場合、このデフォルトではなくコネクタの設定が使用されます。
設定の詳細は、​「動的設定の有効期限」​を参照してください。

cluster-config

省略可能。Mule アプリケーションクラスターの設定。
設定の詳細は、​「高パフォーマンスのためのクラスタリング」​を参照してください。
## [](#関連情報)関連情報 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling) - [Dynamic Configurations (動的設定)](https://docs.mulesoft.com/mule-sdk/latest/static-dynamic-configs) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-high-availability-ha-clusters) # グローバル設定 Mule アプリケーションのグローバル設定 (デフォルトトランザクションタイムアウトやデフォルトエラーハンドラーなど) は、​[Mule 設定ファイル](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-configuration)​のルートレベルにある ​``​ 要素で設定できます。 ## [](#studio-からグローバル設定を作成する)Studio からグローバル設定を作成する グローバル設定を作成する手順は次のとおりです。 1. Studio で ​**\[Global Elements (グローバル要素)\]**​ タブに移動して、​**\[Create (作成)\]**​ をクリックします。 ![create-global-settings](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-global-settings-create.png) 2. **\[Global Configurations (グローバル設定)\]**​ > ​**\[Configuration (設定)\]**​ を選択します。 ![configure-global-settings](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-global-configurations.png) 3. **\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ と ​**\[HA Profile (HA プロファイル)\]**​ の値を設定します。 ## [](#xml-の編集によるグローバル設定の作成)XML の編集によるグローバル設定の作成 次の例では、グローバルエラーハンドラーを定義してから、デフォルトのトランザクションタイムアウトを指定したグローバル設定を定義し、グローバルエラーハンドラーをデフォルトとして参照しています。 ```xml ... ... ... ``` ## [](#グローバル設定リファレンス)グローバル設定リファレンス 次の表に ​``​ 要素のすべての属性を示します。
名前 型 必須 デフォルト 説明

defaultResponseTimeout

string

いいえ

10000

同期応答を待つデフォルトの時間 (ミリ秒)。

defaultTransactionTimeout

string

いいえ

30000

トランザクションのデフォルトのタイムアウト (ミリ秒)。これは、トランザクションでも設定できます。その場合、このデフォルトではなくトランザクションの設定が使用されます。

defaultErrorHandler-ref

string

いいえ

なし

すべてのフローのデフォルトのエラーハンドラー。これは、グローバルエラーハンドラーへの参照である必要があります。

shutdownTimeout

integer

いいえ

5000

(Mule 2.2.2 以降) Mule をシャットダウンする前に、処理中のメッセージの処理が完了するのを待つ時間 (ミリ秒)。このしきい値に達すると、Mule はスレッドの中断を開始するため、メッセージが失われる可能性があります。同じ Mule インスタンスに非常に多くのサービスがある場合や、処理に数秒以上かかるコンポーネントがある場合、あるいは大きなペイロードや遅いトランスポートを使用している場合は、シャットダウンが適切に行われるようにこの値を大きくする必要があります。指定した値はサービスに適用され、ディスパッチャーにも別個に適用されます。そのため、デフォルト値の 5000 ミリ秒の場合、シャットダウンが開始されてから Mule がメッセージの処理とディスパッチを適切に行う時間は 5 秒間です。

maxQueueTransactionFilesSize

integer

いいえ

500

トランザクションログファイルが永続的なトランザクションキューのために使用するおおよその最大容量 (メガバイト)。この数値は、XA トランザクションとローカルトランザクションの両方のトランザクションログファイルセットに適用されることを考慮する必要があります。両方の種別のトランザクションが使用されている場合は、使用されるおおよその最大容量は、設定値の 2 倍になります。

defaultObjectSerializer-ref

string

いいえ

なし

省略可能。アプリケーションのデフォルトとして使用する ObjectSerializer への参照。
### [](#configuration-の子要素) の子要素
名前 説明

dynamic-config-expiration

省略可能。動的設定のデフォルトの有効期限設定。コネクタによって使用されます。これは、コネクタでも設定できます。その場合、このデフォルトではなくコネクタの設定が使用されます。
設定の詳細は、​「動的設定の有効期限」​を参照してください。

cluster-config

省略可能。Mule アプリケーションクラスターの設定。
設定の詳細は、​「高パフォーマンスのためのクラスタリング」​を参照してください。
## [](#関連情報)関連情報 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling) - [Dynamic Configurations (動的設定)](https://docs.mulesoft.com/mule-sdk/latest/static-dynamic-configs) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-high-availability-ha-clusters) # グローバル設定 Mule アプリケーションのグローバル設定 (デフォルトトランザクションタイムアウトやデフォルトエラーハンドラーなど) は、​[Mule 設定ファイル](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-configuration)​のルートレベルにある ​``​ 要素で設定できます。 ## [](#studio-からグローバル設定を作成する)Studio からグローバル設定を作成する グローバル設定を作成する手順は次のとおりです。 1. Studio で ​**\[Global Elements (グローバル要素)\]**​ タブに移動して、​**\[Create (作成)\]**​ をクリックします。 ![create-global-settings](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-global-settings-create.png) 2. **\[Global Configurations (グローバル設定)\]**​ > ​**\[Configuration (設定)\]**​ を選択します。 ![configure-global-settings](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-global-configurations.png) 3. **\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ と ​**\[HA Profile (HA プロファイル)\]**​ の値を設定します。 ## [](#xml-の編集によるグローバル設定の作成)XML の編集によるグローバル設定の作成 次の例では、グローバルエラーハンドラーを定義してから、デフォルトのトランザクションタイムアウトを指定したグローバル設定を定義し、グローバルエラーハンドラーをデフォルトとして参照しています。 ```xml ... ... ... ``` ## [](#グローバル設定リファレンス)グローバル設定リファレンス 次の表に ​``​ 要素のすべての属性を示します。
名前 型 必須 Default (デフォルト) 説明

defaultResponseTimeout

string

no (いいえ)

10000

同期応答を待つデフォルトの時間 (ミリ秒)。

defaultTransactionTimeout

string

no (いいえ)

30000

トランザクションのデフォルトのタイムアウト (ミリ秒)。これは、トランザクションでも設定できます。その場合、このデフォルトではなくトランザクションの設定が使用されます。

defaultErrorHandler-ref

string

no (いいえ)

なし

すべてのフローのデフォルトのエラーハンドラー。これは、グローバルエラーハンドラーへの参照である必要があります。

shutdownTimeout

integer

no (いいえ)

5000

(Mule 2.2.2 以降) Mule をシャットダウンする前に、処理中のメッセージの処理が完了するのを待つ時間 (ミリ秒)。このしきい値に達すると、Mule はスレッドの中断を開始するため、メッセージが失われる可能性があります。同じ Mule インスタンスに非常に多くのサービスがある場合や、処理に数秒以上かかるコンポーネントがある場合、あるいは大きなペイロードや遅いトランスポートを使用している場合は、シャットダウンが適切に行われるようにこの値を大きくする必要があります。指定した値はサービスに適用され、ディスパッチャーにも別個に適用されます。そのため、デフォルト値の 5000 ミリ秒の場合、シャットダウンが開始されてから Mule がメッセージの処理とディスパッチを適切に行う時間は 5 秒間です。

maxQueueTransactionFilesSize

integer

no (いいえ)

500

トランザクションログファイルが永続的なトランザクションキューのために使用するおおよその最大容量 (メガバイト)。この数値は、XA トランザクションとローカルトランザクションの両方のトランザクションログファイルセットに適用されることを考慮する必要があります。両方の種別のトランザクションが使用されている場合は、使用されるおおよその最大容量は、設定値の 2 倍になります。

defaultObjectSerializer-ref

string

no (いいえ)

なし

省略可能。アプリケーションのデフォルトとして使用する ObjectSerializer への参照。
### [](#configuration-の子要素) の子要素
名前 説明

dynamic-config-expiration

省略可能。動的設定のデフォルトの有効期限設定。コネクタによって使用されます。これは、コネクタでも設定できます。その場合、このデフォルトではなくコネクタの設定が使用されます。
設定の詳細は、​「動的設定の有効期限」​を参照してください。

cluster-config

省略可能。Mule アプリケーションクラスターの設定。
設定の詳細は、​「高パフォーマンスのためのクラスタリング」​を参照してください。
## [](#関連情報)関連情報 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling) - [Dynamic Configurations (動的設定)](https://docs.mulesoft.com/mule-sdk/latest/static-dynamic-configs) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-high-availability-ha-clusters) # グローバル設定 Mule アプリケーションのグローバル設定 (デフォルトトランザクションタイムアウトやデフォルトエラーハンドラーなど) は、​[Mule 設定ファイル](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-configuration)​のルートレベルにある ​``​ 要素で設定できます。 ## [](#studio-からグローバル設定を作成する)Studio からグローバル設定を作成する グローバル設定を作成する手順は次のとおりです。 1. Studio で ​**\[Global Elements (グローバル要素)\]**​ タブに移動して、​**\[Create (作成)\]**​ をクリックします。 ![create-global-settings](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-global-settings-create.png) 2. **\[Global Configurations (グローバル設定)\]**​ > ​**\[Configuration (設定)\]**​ を選択します。 ![configure-global-settings](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-global-configurations.png) 3. **\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ と ​**\[HA Profile (HA プロファイル)\]**​ の値を設定します。 ## [](#xml-の編集によるグローバル設定の作成)XML の編集によるグローバル設定の作成 次の例では、グローバルエラーハンドラーを定義してから、デフォルトのトランザクションタイムアウトを指定したグローバル設定を定義し、グローバルエラーハンドラーをデフォルトとして参照しています。 ```xml ... ... ... ``` ## [](#グローバル設定リファレンス)グローバル設定リファレンス 次の表に ​``​ 要素のすべての属性を示します。
名前 型 必須 デフォルト 説明

defaultResponseTimeout

string

いいえ

10000

同期応答を待つデフォルトの時間 (ミリ秒)。

defaultTransactionTimeout

string

いいえ

30000

トランザクションのデフォルトのタイムアウト (ミリ秒)。これは、トランザクションでも設定できます。その場合、このデフォルトではなくトランザクションの設定が使用されます。

defaultErrorHandler-ref

string

いいえ

なし

すべてのフローのデフォルトのエラーハンドラー。これは、グローバルエラーハンドラーへの参照である必要があります。

shutdownTimeout

integer

いいえ

5000

(Mule 2.2.2 以降) Mule をシャットダウンする前に、処理中のメッセージの処理が完了するのを待つ時間 (ミリ秒)。このしきい値に達すると、Mule はスレッドの中断を開始するため、メッセージが失われる可能性があります。同じ Mule インスタンスに非常に多くのサービスがある場合や、処理に数秒以上かかるコンポーネントがある場合、あるいは大きなペイロードや遅いトランスポートを使用している場合は、シャットダウンが適切に行われるようにこの値を大きくする必要があります。指定した値はサービスに適用され、ディスパッチャーにも別個に適用されます。そのため、デフォルト値の 5000 ミリ秒の場合、シャットダウンが開始されてから Mule がメッセージの処理とディスパッチを適切に行う時間は 5 秒間です。

maxQueueTransactionFilesSize

integer

いいえ

500

トランザクションログファイルが永続的なトランザクションキューのために使用するおおよその最大容量 (メガバイト)。この数値は、XA トランザクションとローカルトランザクションの両方のトランザクションログファイルセットに適用されることを考慮する必要があります。両方の種別のトランザクションが使用されている場合は、使用されるおおよその最大容量は、設定値の 2 倍になります。

defaultObjectSerializer-ref

string

いいえ

なし

省略可能。アプリケーションのデフォルトとして使用する ObjectSerializer への参照。
### [](#configuration-の子要素) の子要素
名前 説明

dynamic-config-expiration

省略可能。動的設定のデフォルトの有効期限設定。コネクタによって使用されます。これは、コネクタでも設定できます。その場合、このデフォルトではなくコネクタの設定が使用されます。
設定の詳細は、​「動的設定の有効期限」​を参照してください。

cluster-config

省略可能。Mule アプリケーションクラスターの設定。
設定の詳細は、​「高パフォーマンスのためのクラスタリング」​を参照してください。
## [](#関連情報)関連情報 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling) - [Dynamic Configurations (動的設定)](https://docs.mulesoft.com/mule-sdk/latest/static-dynamic-configs) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-high-availability-ha-clusters) # グローバル設定 Mule アプリケーションのグローバル設定 (デフォルトトランザクションタイムアウトやデフォルトエラーハンドラーなど) は、​[Mule 設定ファイル](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-configuration)​のルートレベルにある ​``​ 要素で設定できます。 ## [](#studio-からグローバル設定を作成する)Studio からグローバル設定を作成する グローバル設定を作成する手順は次のとおりです。 1. Studio で ​**\[Global Elements (グローバル要素)\]**​ タブに移動して、​**\[Create (作成)\]**​ をクリックします。 ![HTTP リスナー設定の項目が含まれる、グローバル設定を作成する設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-global-settings-create.png) 2. **\[Global Configurations (グローバル設定)\]**​ > ​**\[Configuration (設定)\]**​ を選択します。 ![キャッシュおよびスケジューラー設定が含まれる、グローバル設定の種別を選択するメニュー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-global-configurations.png) 3. **\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ と ​**\[HA Profile (HA プロファイル)\]**​ の値を設定します。 ## [](#xml-の編集によるグローバル設定の作成)XML の編集によるグローバル設定の作成 次の例では、グローバルエラーハンドラーを定義してから、デフォルトのトランザクションタイムアウトを指定したグローバル設定を定義し、グローバルエラーハンドラーをデフォルトとして参照しています。 ```xml ... ... ... ``` ## [](#グローバル設定リファレンス)グローバル設定リファレンス 次の表に ​``​ 要素のすべての属性を示します。
名前 型 必須 デフォルト 説明

defaultResponseTimeout

string

いいえ

10000

同期応答を待つデフォルトの時間 (ミリ秒)。

defaultTransactionTimeout

string

いいえ

30000

トランザクションのデフォルトのタイムアウト (ミリ秒)。これは、トランザクションでも設定できます。その場合、このデフォルトではなくトランザクションの設定が使用されます。

defaultErrorHandler-ref

string

いいえ

なし

すべてのフローのデフォルトのエラーハンドラー。これは、グローバルエラーハンドラーへの参照である必要があります。

shutdownTimeout

integer

いいえ

5000

(Mule 2.2.2 以降) Mule をシャットダウンする前に、処理中のメッセージの処理が完了するのを待つ時間 (ミリ秒)。このしきい値に達すると、Mule はスレッドの中断を開始するため、メッセージが失われる可能性があります。同じ Mule インスタンスに非常に多くのサービスがある場合や、処理に数秒以上かかるコンポーネントがある場合、あるいは大きなペイロードや遅いトランスポートを使用している場合は、シャットダウンが適切に行われるようにこの値を大きくする必要があります。指定した値はサービスに適用され、ディスパッチャーにも別個に適用されます。そのため、デフォルト値の 5000 ミリ秒の場合、シャットダウンが開始されてから Mule がメッセージの処理とディスパッチを適切に行う時間は 5 秒間です。

maxQueueTransactionFilesSize

integer

いいえ

500

トランザクションログファイルが永続的なトランザクションキューのために使用するおおよその最大容量 (メガバイト)。この数値は、XA トランザクションとローカルトランザクションの両方のトランザクションログファイルセットに適用されることを考慮する必要があります。両方の種別のトランザクションが使用されている場合は、使用されるおおよその最大容量は、設定値の 2 倍になります。

defaultObjectSerializer-ref

string

いいえ

なし

省略可能。アプリケーションのデフォルトとして使用する ObjectSerializer への参照。
### [](#configuration-の子要素) の子要素
名前 説明

dynamic-config-expiration

省略可能。動的設定のデフォルトの有効期限設定。コネクタによって使用されます。これは、コネクタでも設定できます。その場合、このデフォルトではなくコネクタの設定が使用されます。
設定の詳細は、​「動的設定の有効期限」​を参照してください。

cluster-config

省略可能。Mule アプリケーションクラスターの設定。
設定の詳細は、​「高パフォーマンスのためのクラスタリング」​を参照してください。
## [](#関連情報)関連情報 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling) - [Dynamic Configurations (動的設定)](https://docs.mulesoft.com/mule-sdk/latest/static-dynamic-configs) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-high-availability-ha-clusters) # グローバル設定 Mule アプリケーションのグローバル設定 (デフォルトトランザクションタイムアウトやデフォルトエラーハンドラーなど) は、​[Mule 設定ファイル](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-configuration)​のルートレベルにある ​``​ 要素で設定できます。 ## [](#studio-からグローバル設定を作成する)Studio からグローバル設定を作成する グローバル設定を作成する手順は次のとおりです。 1. Studio で ​**\[Global Elements (グローバル要素)\]**​ タブに移動して、​**\[Create (作成)\]**​ をクリックします。 ![HTTP リスナー設定の項目が含まれる、グローバル設定を作成する設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-global-settings-create.png) 2. **\[Global Configurations (グローバル設定)\]**​ > ​**\[Configuration (設定)\]**​ を選択します。 ![キャッシュおよびスケジューラー設定が含まれる、グローバル設定の種別を選択するメニュー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-global-configurations.png) 3. **\[Default Error Handler (デフォルトのエラーハンドラー)\]**​ と ​**\[HA Profile (HA プロファイル)\]**​ の値を設定します。 ## [](#xml-の編集によるグローバル設定の作成)XML の編集によるグローバル設定の作成 次の例では、グローバルエラーハンドラーを定義してから、デフォルトのトランザクションタイムアウトを指定したグローバル設定を定義し、グローバルエラーハンドラーをデフォルトとして参照しています。 ```xml ... ... ... ``` ## [](#グローバル設定リファレンス)グローバル設定リファレンス 次の表に ​``​ 要素のすべての属性を示します。
名前 型 必須 デフォルト 説明

defaultResponseTimeout

string

いいえ

10000

同期応答を待つデフォルトの時間 (ミリ秒)。

defaultTransactionTimeout

string

いいえ

30000

トランザクションのデフォルトのタイムアウト (ミリ秒)。これは、トランザクションでも設定できます。その場合、このデフォルトではなくトランザクションの設定が使用されます。

defaultErrorHandler-ref

string

いいえ

なし

すべてのフローのデフォルトのエラーハンドラー。これは、グローバルエラーハンドラーへの参照である必要があります。

shutdownTimeout

integer

いいえ

5000

(Mule 2.2.2 以降) Mule をシャットダウンする前に、処理中のメッセージの処理が完了するのを待つ時間 (ミリ秒)。このしきい値に達すると、Mule はスレッドの中断を開始するため、メッセージが失われる可能性があります。同じ Mule インスタンスに非常に多くのサービスがある場合や、処理に数秒以上かかるコンポーネントがある場合、あるいは大きなペイロードや遅いトランスポートを使用している場合は、シャットダウンが適切に行われるようにこの値を大きくする必要があります。指定した値はサービスに適用され、ディスパッチャーにも別個に適用されます。そのため、デフォルト値の 5000 ミリ秒の場合、シャットダウンが開始されてから Mule がメッセージの処理とディスパッチを適切に行う時間は 5 秒間です。

maxQueueTransactionFilesSize

integer

いいえ

500

トランザクションログファイルが永続的なトランザクションキューのために使用するおおよその最大容量 (メガバイト)。この数値は、XA トランザクションとローカルトランザクションの両方のトランザクションログファイルセットに適用されることを考慮する必要があります。両方の種別のトランザクションが使用されている場合は、使用されるおおよその最大容量は、設定値の 2 倍になります。

defaultObjectSerializer-ref

string

いいえ

なし

省略可能。アプリケーションのデフォルトとして使用する ObjectSerializer への参照。
### [](#configuration-の子要素) の子要素
名前 説明

dynamic-config-expiration

省略可能。動的設定のデフォルトの有効期限設定。コネクタによって使用されます。これは、コネクタでも設定できます。その場合、このデフォルトではなくコネクタの設定が使用されます。
設定の詳細は、​「動的設定の有効期限」​を参照してください。

cluster-config

省略可能。Mule アプリケーションクラスターの設定。
設定の詳細は、​「高パフォーマンスのためのクラスタリング」​を参照してください。
## [](#関連情報)関連情報 - [エラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling) - [Dynamic Configurations (動的設定)](https://docs.mulesoft.com/mule-sdk/latest/static-dynamic-configs) - [Mule 高可用性クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-high-availability-ha-clusters) # コアコンポーネント コネクタとモジュールでの操作と同様に、コアコンポーネントは Mule アプリケーションのフローの重要なビルディングブロックです。コアコンポーネントは、Mule イベントが アプリケーションでリンクされた一連のステップを通過するときに処理する ロジックを提供します。たとえば、Scheduler、For Each、Logger などのコンポーネントがあります。 Studio では、Mule パレットから ​**\[Core (コア)\]**​ をクリックして Mule コンポーネントにアクセスできます。 \+ image::components-core-studio.png\[Studio でのコアコンポーネント\] \+ コンポーネントは \[Batch (バッチ)\]、\[Error Handling (エラー処理)\]、 \[Flow Control (フローコントロール)\] などの種類に細分化されています。 ## [](#バッチ)バッチ Mule メッセージをバッチで処理するには、すべてまとめて処理する代わりに、 バッチコンポーネントを使用できます。このコンポーネントには次が含まれます。 - Batch Aggregator - Batch Job - Batch Step [「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-processing-concept)​を参照してください。 ## [](#コンポーネント)コンポーネント 次のコアコンポーネントはさまざまなタスクを実行します。 - [Custom Business Events](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events-custom)​: ビジネストランザクションを 処理するフローおよびメッセージプロセッサーに関する情報を収集。​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events)​も参照してください。 - [Dynamic Evaluate](https://docs.mulesoft.com/jp/mule-runtime/4.3/dynamic-evaluate-component-reference)​: Transform Message コンポーネントを 使用してスクリプトを強制的にハードコードする代わりに、動的に選択。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.3/flowref-about)​: Mule アプリケーション内で、 Mule イベントを別のフローまたはサブフローに転送。 - [Logger](https://docs.mulesoft.com/jp/mule-runtime/4.3/logger-component-reference)​: エラーメッセージや状況通知など、 Mule アプリケーションに関する重要な情報をログに記録。 - [Parse Template](https://docs.mulesoft.com/jp/mule-runtime/4.3/parse-template-reference)​: テンプレートを処理して結果を取得。 - [Transform Message](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about)​: 入力データを新しい出力構造 または形式に変換。 ## [](#エンドポイント)エンドポイント エンドポイント (Studio ではソースとも呼ばれる) には、 Mule フローで処理を開始 (またはトリガー) するコンポーネントが含まれます。​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.3/scheduler-concept)​ はエンドポイントです。設定可能な間隔で開始する フローをトリガーします。 一部のコネクタでは、エンドポイントとして機能するリスナーが提供されます。リスナーは、 外部要求を受け取ったときにフローをトリガーできます。たとえば、特定の URL に 設定された HTTP リスナーは、誰かまたはプロセスがその URL にアクセスしたときに フローをトリガーできます。 ## [](#エラー処理)エラー処理 エラー処理コンポーネントは、Mule アプリケーションで発生した Mule エラーの転送と処理を行います。 - Error Handler - On Error Continue - On Error Propagate [「エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.3/error-handling)​を参照してください。 ## [](#フローコントロール-ルーター)フローコントロール (ルーター) フローコントロールコンポーネント (ルーター) は、入力 Mule イベントを取得し、 コンポーネントの 1 つ以上の個別のシーケンスに転送します。フローコントロールには次のコンポーネントがあります。 - Choice - First Successful - Round Robin - Scatter-Gather たとえば、​[Choice ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.3/choice-router-concept)​は DataWeave ロジックを適用して複数のルートから 1 つを選択します。各ルートは イベントプロセッサーの個別のシーケンスです。 [Scatter-Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.3/scatter-gather-concept)​は入力イベントを すべてのルートに送信し、各ルートは単独でイベントを処理します。 すべてのルートでイベントが処理されたら、すべてのルートの結果が 1 つの出力イベントにまとめられます。 ## [](#スコープ)スコープ スコープは、イベントプロセッサーのシーケンス (他のコアコンポーネント、 モジュールとコネクタ両方からの操作など) をグループ化し、その分離された イベントプロセッサーのシーケンスにプログラミング動作を適用するコンポーネントの種類です。 スコープには次のコンポーネントがあります。 - Async - Cache - Flow - For Each - Try - Until Successful たとえば、Try スコープでは、フローの特定のシーケンスで発生するエラーを 分離して処理できます。そのため、アウトバウンド HTTP Request Connector (および Transform Message コンポーネントや Logging コンポーネントなど、HTTP Request Connector 前後にあるいくつかの周辺コンポーネント) を Try スコープでラップし、 エラーが発生した場合に、そのコンポーネントのグルーピングに固有のログまたは 補正ロジックを適用できます。​[「Try スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept)​を参照してください。 別の例として For Each (または Foreach) スコープがあります。このスコープは通常、 現在の入力イベントから抽出されたデータのコレクションを取得し、コレクション 内のすべての項目に同じイベントプロセッサーのシーケンスを適用します。たとえば、 For Each スコープはデータベースクエリから返された各行、または CSV ファイルの 各行を処理するために使用できます。​[「For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/for-each-scope-concept)​を参照してください。 ## [](#トランスフォーマー)トランスフォーマー トランスフォーマーは、Mule イベントの一部を設定または削除するために使用できるコンポーネントです。 トランスフォーマーには次のコンポーネントがあります。 - [Remove Variable](https://docs.mulesoft.com/jp/mule-runtime/4.3/remove-variable) - [Set Payload](https://docs.mulesoft.com/jp/mule-runtime/4.3/set-payload-transformer-reference) - [Set Variable](https://docs.mulesoft.com/jp/mule-runtime/4.3/variable-transformer-reference) ## [](#関連情報)関連情報 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) # コアコンポーネント コネクタとモジュールでの操作と同様に、コアコンポーネントは Mule アプリケーションのフローの重要なビルディングブロックです。コアコンポーネントは、Mule イベントが アプリケーションでリンクされた一連のステップを通過するときに処理する ロジックを提供します。たとえば、Scheduler、For Each、Logger などのコンポーネントがあります。 Studio では、Mule パレットから ​**\[Core (コア)\]**​ をクリックして Mule コンポーネントにアクセスできます。 \+ image::components-core-studio.png\[Studio でのコアコンポーネント\] \+ コンポーネントは \[Batch (バッチ)\]、\[Error Handling (エラー処理)\]、 \[Flow Control (フローコントロール)\] などの種類に細分化されています。 ## [](#バッチ)バッチ Mule メッセージをバッチで処理するには、すべてまとめて処理する代わりに、 バッチコンポーネントを使用できます。このコンポーネントには次が含まれます。 - Batch Aggregator - Batch Job - Batch Step [「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-processing-concept)​を参照してください。 ## [](#コンポーネント)コンポーネント 次のコアコンポーネントはさまざまなタスクを実行します。 - [Custom Business Events](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events-custom)​: ビジネストランザクションを 処理するフローおよびメッセージプロセッサーに関する情報を収集。​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events)​も参照してください。 - [Dynamic Evaluate](https://docs.mulesoft.com/jp/mule-runtime/4.4/dynamic-evaluate-component-reference)​: Transform Message コンポーネントを 使用してスクリプトを強制的にハードコードする代わりに、動的に選択。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.4/flowref-about)​: Mule アプリケーション内で、 Mule イベントを別のフローまたはサブフローに転送。 - [Logger](https://docs.mulesoft.com/jp/mule-runtime/4.4/logger-component-reference)​: エラーメッセージや状況通知など、 Mule アプリケーションに関する重要な情報をログに記録。 - [Parse Template](https://docs.mulesoft.com/jp/mule-runtime/4.4/parse-template-reference)​: テンプレートを処理して結果を取得。 - [Transform Message](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about)​: 入力データを新しい出力構造 または形式に変換。 ## [](#エンドポイント)エンドポイント エンドポイント (Studio ではソースとも呼ばれる) には、 Mule フローで処理を開始 (またはトリガー) するコンポーネントが含まれます。​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.4/scheduler-concept)​ はエンドポイントです。設定可能な間隔で開始する フローをトリガーします。 一部のコネクタでは、エンドポイントとして機能するリスナーが提供されます。リスナーは、 外部要求を受け取ったときにフローをトリガーできます。たとえば、特定の URL に 設定された HTTP リスナーは、誰かまたはプロセスがその URL にアクセスしたときに フローをトリガーできます。 ## [](#エラー処理)エラー処理 エラー処理コンポーネントは、Mule アプリケーションで発生した Mule エラーの転送と処理を行います。 - Error Handler - On Error Continue - On Error Propagate [「エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.4/error-handling)​を参照してください。 ## [](#フローコントロール-ルーター)フローコントロール (ルーター) フローコントロールコンポーネント (ルーター) は、入力 Mule イベントを取得し、 コンポーネントの 1 つ以上の個別のシーケンスに転送します。フローコントロールには次のコンポーネントがあります。 - Choice - First Successful - Round Robin - Scatter-Gather たとえば、​[Choice ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.4/choice-router-concept)​は DataWeave ロジックを適用して複数のルートから 1 つを選択します。各ルートは イベントプロセッサーの個別のシーケンスです。 [Scatter-Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.4/scatter-gather-concept)​は入力イベントを すべてのルートに送信し、各ルートは単独でイベントを処理します。 すべてのルートでイベントが処理されたら、すべてのルートの結果が 1 つの出力イベントにまとめられます。 ## [](#スコープ)スコープ スコープは、イベントプロセッサーのシーケンス (他のコアコンポーネント、 モジュールとコネクタ両方からの操作など) をグループ化し、その分離された イベントプロセッサーのシーケンスにプログラミング動作を適用するコンポーネントの種類です。 スコープには次のコンポーネントがあります。 - Async - Cache - Flow - For Each - Try - Until Successful たとえば、Try スコープでは、フローの特定のシーケンスで発生するエラーを 分離して処理できます。そのため、アウトバウンド HTTP Request Connector (および Transform Message コンポーネントや Logging コンポーネントなど、HTTP Request Connector 前後にあるいくつかの周辺コンポーネント) を Try スコープでラップし、 エラーが発生した場合に、そのコンポーネントのグルーピングに固有のログまたは 補正ロジックを適用できます。​[「Try スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept)​を参照してください。 別の例として For Each (または Foreach) スコープがあります。このスコープは通常、 現在の入力イベントから抽出されたデータのコレクションを取得し、コレクション 内のすべての項目に同じイベントプロセッサーのシーケンスを適用します。たとえば、 For Each スコープはデータベースクエリから返された各行、または CSV ファイルの 各行を処理するために使用できます。​[「For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/for-each-scope-concept)​を参照してください。 ## [](#トランスフォーマー)トランスフォーマー トランスフォーマーは、Mule イベントの一部を設定または削除するために使用できるコンポーネントです。 トランスフォーマーには次のコンポーネントがあります。 - [Remove Variable](https://docs.mulesoft.com/jp/mule-runtime/4.4/remove-variable) - [Set Payload](https://docs.mulesoft.com/jp/mule-runtime/4.4/set-payload-transformer-reference) - [Set Variable](https://docs.mulesoft.com/jp/mule-runtime/4.4/variable-transformer-reference) ## [](#関連情報)関連情報 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) # コアコンポーネント コネクタとモジュールでの操作と同様に、コアコンポーネントは Mule アプリケーションのフローの重要なビルディングブロックです。コアコンポーネントは、Mule イベントが アプリケーションでリンクされた一連のステップを通過するときに処理する ロジックを提供します。たとえば、Scheduler、For Each、Logger などのコンポーネントがあります。 Studio では、Mule パレットから ​**\[Core (コア)\]**​ をクリックして Mule コンポーネントにアクセスできます。 \+ image::components-core-studio.png\[Studio でのコアコンポーネント\] \+ コンポーネントは \[Batch (バッチ)\]、\[Error Handling (エラー処理)\]、 \[Flow Control (フローコントロール)\] などの種類に細分化されています。 ## [](#バッチ)バッチ Mule メッセージをバッチで処理するには、すべてまとめて処理する代わりに、 バッチコンポーネントを使用できます。このコンポーネントには次が含まれます。 - Batch Aggregator - Batch Job - Batch Step [「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-processing-concept)​を参照してください。 ## [](#コンポーネント)コンポーネント 次のコアコンポーネントはさまざまなタスクを実行します。 - [Custom Business Events](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events-custom)​: ビジネストランザクションを 処理するフローおよびメッセージプロセッサーに関する情報を収集。​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events)​も参照してください。 - [Dynamic Evaluate](https://docs.mulesoft.com/jp/mule-runtime/4.5/dynamic-evaluate-component-reference)​: Transform Message コンポーネントを 使用してスクリプトを強制的にハードコードする代わりに、動的に選択。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.5/flowref-about)​: Mule アプリケーション内で、 Mule イベントを別のフローまたはサブフローに転送。 - [Logger](https://docs.mulesoft.com/jp/mule-runtime/4.5/logger-component-reference)​: エラーメッセージや状況通知など、 Mule アプリケーションに関する重要な情報をログに記録。 - [Parse Template](https://docs.mulesoft.com/jp/mule-runtime/4.5/parse-template-reference)​: テンプレートを処理して結果を取得。 - [Transform Message](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about)​: 入力データを新しい出力構造 または形式に変換。 ## [](#エンドポイント)エンドポイント エンドポイント (Studio ではソースとも呼ばれる) には、 Mule フローで処理を開始 (またはトリガー) するコンポーネントが含まれます。​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.5/scheduler-concept)​ はエンドポイントです。設定可能な間隔で開始する フローをトリガーします。 一部のコネクタでは、エンドポイントとして機能するリスナーが提供されます。リスナーは、 外部要求を受け取ったときにフローをトリガーできます。たとえば、特定の URL に 設定された HTTP リスナーは、誰かまたはプロセスがその URL にアクセスしたときに フローをトリガーできます。 ## [](#エラー処理)エラー処理 エラー処理コンポーネントは、Mule アプリケーションで発生した Mule エラーの転送と処理を行います。 - Error Handler - On Error Continue - On Error Propagate [「エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.5/error-handling)​を参照してください。 ## [](#フローコントロール-ルーター)フローコントロール (ルーター) フローコントロールコンポーネント (ルーター) は、入力 Mule イベントを取得し、 コンポーネントの 1 つ以上の個別のシーケンスに転送します。フローコントロールには次のコンポーネントがあります。 - Choice - First Successful - Round Robin - Scatter-Gather たとえば、​[Choice ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.5/choice-router-concept)​は DataWeave ロジックを適用して複数のルートから 1 つを選択します。各ルートは イベントプロセッサーの個別のシーケンスです。 [Scatter-Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.5/scatter-gather-concept)​は入力イベントを すべてのルートに送信し、各ルートは単独でイベントを処理します。 すべてのルートでイベントが処理されたら、すべてのルートの結果が 1 つの出力イベントにまとめられます。 ## [](#スコープ)スコープ スコープは、イベントプロセッサーのシーケンス (他のコアコンポーネント、 モジュールとコネクタ両方からの操作など) をグループ化し、その分離された イベントプロセッサーのシーケンスにプログラミング動作を適用するコンポーネントの種類です。 スコープには次のコンポーネントがあります。 - Async - Cache - Flow - For Each - Try - Until Successful たとえば、Try スコープでは、フローの特定のシーケンスで発生するエラーを 分離して処理できます。そのため、アウトバウンド HTTP Request Connector (および Transform Message コンポーネントや Logging コンポーネントなど、HTTP Request Connector 前後にあるいくつかの周辺コンポーネント) を Try スコープでラップし、 エラーが発生した場合に、そのコンポーネントのグルーピングに固有のログまたは 補正ロジックを適用できます。​[「Try スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept)​を参照してください。 別の例として For Each (または Foreach) スコープがあります。このスコープは通常、 現在の入力イベントから抽出されたデータのコレクションを取得し、コレクション 内のすべての項目に同じイベントプロセッサーのシーケンスを適用します。たとえば、 For Each スコープはデータベースクエリから返された各行、または CSV ファイルの 各行を処理するために使用できます。​[「For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/for-each-scope-concept)​を参照してください。 ## [](#トランスフォーマー)トランスフォーマー トランスフォーマーは、Mule イベントの一部を設定または削除するために使用できるコンポーネントです。 トランスフォーマーには次のコンポーネントがあります。 - [Remove Variable](https://docs.mulesoft.com/jp/mule-runtime/4.5/remove-variable) - [Set Payload](https://docs.mulesoft.com/jp/mule-runtime/4.5/set-payload-transformer-reference) - [Set Variable](https://docs.mulesoft.com/jp/mule-runtime/4.5/variable-transformer-reference) ## [](#関連情報)関連情報 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) # コアコンポーネント コネクタとモジュールでの操作と同様に、コアコンポーネントは Mule アプリケーションのフローの重要なビルディングブロックです。コアコンポーネントは、Mule イベントが アプリケーションでリンクされた一連のステップを通過するときに処理する ロジックを提供します。たとえば、Scheduler、For Each、Logger などのコンポーネントがあります。 Studio では、Mule パレットから ​**\[Core (コア)\]**​ をクリックして Mule コンポーネントにアクセスできます。 \+ image::components-core-studio.png\[Studio でのコアコンポーネント\] \+ コンポーネントは \[Batch (バッチ)\]、\[Error Handling (エラー処理)\]、 \[Flow Control (フローコントロール)\] などの種類に細分化されています。 ## [](#バッチ)バッチ Mule メッセージをバッチで処理するには、すべてまとめて処理する代わりに、 バッチコンポーネントを使用できます。このコンポーネントには次が含まれます。 - Batch Aggregator - Batch Job - Batch Step [「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-processing-concept)​を参照してください。 ## [](#コンポーネント)コンポーネント 次のコアコンポーネントはさまざまなタスクを実行します。 - [Custom Business Events](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events-custom)​: ビジネストランザクションを 処理するフローおよびメッセージプロセッサーに関する情報を収集。​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events)​も参照してください。 - [Dynamic Evaluate](https://docs.mulesoft.com/jp/mule-runtime/4.6/dynamic-evaluate-component-reference)​: Transform Message コンポーネントを 使用してスクリプトを強制的にハードコードする代わりに、動的に選択。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.6/flowref-about)​: Mule アプリケーション内で、 Mule イベントを別のフローまたはサブフローに転送。 - [Logger](https://docs.mulesoft.com/jp/mule-runtime/4.6/logger-component-reference)​: エラーメッセージや状況通知など、 Mule アプリケーションに関する重要な情報をログに記録。 - [Parse Template](https://docs.mulesoft.com/jp/mule-runtime/4.6/parse-template-reference)​: テンプレートを処理して結果を取得。 - [Transform Message](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about)​: 入力データを新しい出力構造 または形式に変換。 ## [](#エンドポイント)エンドポイント エンドポイント (Studio ではソースとも呼ばれる) には、 Mule フローで処理を開始 (またはトリガー) するコンポーネントが含まれます。​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.6/scheduler-concept)​ はエンドポイントです。設定可能な間隔で開始する フローをトリガーします。 一部のコネクタでは、エンドポイントとして機能するリスナーが提供されます。リスナーは、 外部要求を受け取ったときにフローをトリガーできます。たとえば、特定の URL に 設定された HTTP リスナーは、誰かまたはプロセスがその URL にアクセスしたときに フローをトリガーできます。 ## [](#エラー処理)エラー処理 エラー処理コンポーネントは、Mule アプリケーションで発生した Mule エラーの転送と処理を行います。 - Error Handler - On Error Continue - On Error Propagate [「エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.6/error-handling)​を参照してください。 ## [](#フローコントロール-ルーター)フローコントロール (ルーター) フローコントロールコンポーネント (ルーター) は、入力 Mule イベントを取得し、 コンポーネントの 1 つ以上の個別のシーケンスに転送します。フローコントロールには次のコンポーネントがあります。 - Choice - First Successful - Round Robin - Scatter-Gather たとえば、​[Choice ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.6/choice-router-concept)​は DataWeave ロジックを適用して複数のルートから 1 つを選択します。各ルートは イベントプロセッサーの個別のシーケンスです。 [Scatter-Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.6/scatter-gather-concept)​は入力イベントを すべてのルートに送信し、各ルートは単独でイベントを処理します。 すべてのルートでイベントが処理されたら、すべてのルートの結果が 1 つの出力イベントにまとめられます。 ## [](#スコープ)スコープ スコープは、イベントプロセッサーのシーケンス (他のコアコンポーネント、 モジュールとコネクタ両方からの操作など) をグループ化し、その分離された イベントプロセッサーのシーケンスにプログラミング動作を適用するコンポーネントの種類です。 スコープには次のコンポーネントがあります。 - Async - Cache - Flow - For Each - Try - Until Successful たとえば、Try スコープでは、フローの特定のシーケンスで発生するエラーを 分離して処理できます。そのため、アウトバウンド HTTP Request Connector (および Transform Message コンポーネントや Logging コンポーネントなど、HTTP Request Connector 前後にあるいくつかの周辺コンポーネント) を Try スコープでラップし、 エラーが発生した場合に、そのコンポーネントのグルーピングに固有のログまたは 補正ロジックを適用できます。​[「Try スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept)​を参照してください。 別の例として For Each (または Foreach) スコープがあります。このスコープは通常、 現在の入力イベントから抽出されたデータのコレクションを取得し、コレクション 内のすべての項目に同じイベントプロセッサーのシーケンスを適用します。たとえば、 For Each スコープはデータベースクエリから返された各行、または CSV ファイルの 各行を処理するために使用できます。​[「For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/for-each-scope-concept)​を参照してください。 ## [](#トランスフォーマー)トランスフォーマー トランスフォーマーは、Mule イベントの一部を設定または削除するために使用できるコンポーネントです。 トランスフォーマーには次のコンポーネントがあります。 - [Remove Variable](https://docs.mulesoft.com/jp/mule-runtime/4.6/remove-variable) - [Set Payload](https://docs.mulesoft.com/jp/mule-runtime/4.6/set-payload-transformer-reference) - [Set Variable](https://docs.mulesoft.com/jp/mule-runtime/4.6/variable-transformer-reference) ## [](#関連情報)関連情報 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) # コアコンポーネント コネクタとモジュールでの操作と同様に、コアコンポーネントは Mule アプリケーションのフローの重要なビルディングブロックです。コアコンポーネントは、Mule イベントが アプリケーションでリンクされた一連のステップを通過するときに処理する ロジックを提供します。たとえば、Scheduler、For Each、Logger などのコンポーネントがあります。 Studio では、Mule パレットから ​**\[Core (コア)\]**​ をクリックして Mule コンポーネントにアクセスできます。 ![Anypoint Studio のコアコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/components-core-studio.png) コンポーネントは \[Batch (バッチ)\]、\[Error Handling (エラー処理)\]、 \[Flow Control (フローコントロール)\] などの種類に細分化されています。 ## [](#バッチ)バッチ Mule メッセージをバッチで処理するには、すべてまとめて処理する代わりに、 バッチコンポーネントを使用できます。このコンポーネントには次が含まれます。 - Batch Aggregator - Batch Job - Batch Step [「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-processing-concept)​を参照してください。 ## [](#コンポーネント)コンポーネント 次のコアコンポーネントはさまざまなタスクを実行します。 - [Custom Business Events](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events-custom)​: ビジネストランザクションを 処理するフローおよびメッセージプロセッサーに関する情報を収集。​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events)​も参照してください。 - [Dynamic Evaluate](https://docs.mulesoft.com/jp/mule-runtime/4.7/dynamic-evaluate-component-reference)​: Transform Message コンポーネントを 使用してスクリプトを強制的にハードコードする代わりに、動的に選択。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.7/flowref-about)​: Mule アプリケーション内で、 Mule イベントを別のフローまたはサブフローに転送。 - [Logger](https://docs.mulesoft.com/jp/mule-runtime/4.7/logger-component-reference)​: エラーメッセージや状況通知など、 Mule アプリケーションに関する重要な情報をログに記録。 - [Parse Template](https://docs.mulesoft.com/jp/mule-runtime/4.7/parse-template-reference)​: テンプレートを処理して結果を取得。 - [Transform Message](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about)​: 入力データを新しい出力構造 または形式に変換。 ## [](#エンドポイント)エンドポイント エンドポイント (Studio ではソースとも呼ばれる) には、 Mule フローで処理を開始 (またはトリガー) するコンポーネントが含まれます。​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.7/scheduler-concept)​ はエンドポイントです。設定可能な間隔で開始する フローをトリガーします。 一部のコネクタでは、エンドポイントとして機能するリスナーが提供されます。リスナーは、 外部要求を受け取ったときにフローをトリガーできます。たとえば、特定の URL に 設定された HTTP リスナーは、誰かまたはプロセスがその URL にアクセスしたときに フローをトリガーできます。 ## [](#エラー処理)エラー処理 エラー処理コンポーネントは、Mule アプリケーションで発生した Mule エラーの転送と処理を行います。 - Error Handler - On Error Continue - On Error Propagate [「エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling)​を参照してください。 ## [](#フローコントロール-ルーター)フローコントロール (ルーター) フローコントロールコンポーネント (ルーター) は、入力 Mule イベントを取得し、 コンポーネントの 1 つ以上の個別のシーケンスに転送します。フローコントロールには次のコンポーネントがあります。 - Choice - First Successful - Round Robin - Scatter-Gather たとえば、​[Choice ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.7/choice-router-concept)​は DataWeave ロジックを適用して複数のルートから 1 つを選択します。各ルートは イベントプロセッサーの個別のシーケンスです。 [Scatter-Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.7/scatter-gather-concept)​は入力イベントを すべてのルートに送信し、各ルートは単独でイベントを処理します。 すべてのルートでイベントが処理されたら、すべてのルートの結果が 1 つの出力イベントにまとめられます。 ## [](#スコープ)スコープ スコープは、イベントプロセッサーのシーケンス (他のコアコンポーネント、 モジュールとコネクタ両方からの操作など) をグループ化し、その分離された イベントプロセッサーのシーケンスにプログラミング動作を適用するコンポーネントの種類です。 スコープには次のコンポーネントがあります。 - Async - Cache - Flow - For Each - Try - Until Successful たとえば、Try スコープでは、フローの特定のシーケンスで発生するエラーを 分離して処理できます。そのため、アウトバウンド HTTP Request Connector (および Transform Message コンポーネントや Logging コンポーネントなど、HTTP Request Connector 前後にあるいくつかの周辺コンポーネント) を Try スコープでラップし、 エラーが発生した場合に、そのコンポーネントのグルーピングに固有のログまたは 補正ロジックを適用できます。​[「Try スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept)​を参照してください。 別の例として For Each (または Foreach) スコープがあります。このスコープは通常、 現在の入力イベントから抽出されたデータのコレクションを取得し、コレクション 内のすべての項目に同じイベントプロセッサーのシーケンスを適用します。たとえば、 For Each スコープはデータベースクエリから返された各行、または CSV ファイルの 各行を処理するために使用できます。​[「For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/for-each-scope-concept)​を参照してください。 ## [](#トランスフォーマー)トランスフォーマー トランスフォーマーは、Mule イベントの一部を設定または削除するために使用できるコンポーネントです。 トランスフォーマーには次のコンポーネントがあります。 - [Remove Variable](https://docs.mulesoft.com/jp/mule-runtime/4.7/remove-variable) - [Set Payload](https://docs.mulesoft.com/jp/mule-runtime/4.7/set-payload-transformer-reference) - [Set Variable](https://docs.mulesoft.com/jp/mule-runtime/4.7/variable-transformer-reference) ## [](#関連情報)関連情報 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) # コアコンポーネント コネクタとモジュールでの操作と同様に、コアコンポーネントは Mule アプリケーションのフローの重要なビルディングブロックです。コアコンポーネントは、Mule イベントが アプリケーションでリンクされた一連のステップを通過するときに処理する ロジックを提供します。たとえば、Scheduler、For Each、Logger などのコンポーネントがあります。 Studio では、Mule パレットから ​**\[Core (コア)\]**​ をクリックして Mule コンポーネントにアクセスできます。 ![Anypoint Studio のコアコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/components-core-studio.png) コンポーネントは \[Batch (バッチ)\]、\[Error Handling (エラー処理)\]、 \[Flow Control (フローコントロール)\] などの種類に細分化されています。 ## [](#バッチ)バッチ Mule メッセージをバッチで処理するには、すべてまとめて処理する代わりに、 バッチコンポーネントを使用できます。このコンポーネントには次が含まれます。 - Batch Aggregator - Batch Job - Batch Step [「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-processing-concept)​を参照してください。 ## [](#コンポーネント)コンポーネント 次のコアコンポーネントはさまざまなタスクを実行します。 - [Custom Business Events](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events-custom)​: ビジネストランザクションを 処理するフローおよびメッセージプロセッサーに関する情報を収集。​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events)​も参照してください。 - [Dynamic Evaluate](https://docs.mulesoft.com/jp/mule-runtime/4.8/dynamic-evaluate-component-reference)​: Transform Message コンポーネントを 使用してスクリプトを強制的にハードコードする代わりに、動的に選択。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.8/flowref-about)​: Mule アプリケーション内で、 Mule イベントを別のフローまたはサブフローに転送。 - [Logger](https://docs.mulesoft.com/jp/mule-runtime/4.8/logger-component-reference)​: エラーメッセージや状況通知など、 Mule アプリケーションに関する重要な情報をログに記録。 - [Parse Template](https://docs.mulesoft.com/jp/mule-runtime/4.8/parse-template-reference)​: テンプレートを処理して結果を取得。 - [Transform Message](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about)​: 入力データを新しい出力構造 または形式に変換。 ## [](#エンドポイント)エンドポイント エンドポイント (Studio ではソースとも呼ばれる) には、 Mule フローで処理を開始 (またはトリガー) するコンポーネントが含まれます。​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.8/scheduler-concept)​ はエンドポイントです。設定可能な間隔で開始する フローをトリガーします。 一部のコネクタでは、エンドポイントとして機能するリスナーが提供されます。リスナーは、 外部要求を受け取ったときにフローをトリガーできます。たとえば、特定の URL に 設定された HTTP リスナーは、誰かまたはプロセスがその URL にアクセスしたときに フローをトリガーできます。 ## [](#エラー処理)エラー処理 エラー処理コンポーネントは、Mule アプリケーションで発生した Mule エラーの転送と処理を行います。 - Error Handler - On Error Continue - On Error Propagate [「エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.8/error-handling)​を参照してください。 ## [](#フローコントロール-ルーター)フローコントロール (ルーター) フローコントロールコンポーネント (ルーター) は、入力 Mule イベントを取得し、 コンポーネントの 1 つ以上の個別のシーケンスに転送します。フローコントロールには次のコンポーネントがあります。 - Choice - First Successful - Round Robin - Scatter-Gather たとえば、​[Choice ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.8/choice-router-concept)​は DataWeave ロジックを適用して複数のルートから 1 つを選択します。各ルートは イベントプロセッサーの個別のシーケンスです。 [Scatter-Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.8/scatter-gather-concept)​は入力イベントを すべてのルートに送信し、各ルートは単独でイベントを処理します。 すべてのルートでイベントが処理されたら、すべてのルートの結果が 1 つの出力イベントにまとめられます。 ## [](#スコープ)スコープ スコープは、イベントプロセッサーのシーケンス (他のコアコンポーネント、 モジュールとコネクタ両方からの操作など) をグループ化し、その分離された イベントプロセッサーのシーケンスにプログラミング動作を適用するコンポーネントの種類です。 スコープには次のコンポーネントがあります。 - Async - Cache - Flow - For Each - Try - Until Successful たとえば、Try スコープでは、フローの特定のシーケンスで発生するエラーを 分離して処理できます。そのため、アウトバウンド HTTP Request Connector (および Transform Message コンポーネントや Logging コンポーネントなど、HTTP Request Connector 前後にあるいくつかの周辺コンポーネント) を Try スコープでラップし、 エラーが発生した場合に、そのコンポーネントのグルーピングに固有のログまたは 補正ロジックを適用できます。​[「Try スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept)​を参照してください。 別の例として For Each (または Foreach) スコープがあります。このスコープは通常、 現在の入力イベントから抽出されたデータのコレクションを取得し、コレクション 内のすべての項目に同じイベントプロセッサーのシーケンスを適用します。たとえば、 For Each スコープはデータベースクエリから返された各行、または CSV ファイルの 各行を処理するために使用できます。​[「For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/for-each-scope-concept)​を参照してください。 ## [](#トランスフォーマー)トランスフォーマー トランスフォーマーは、Mule イベントの一部を設定または削除するために使用できるコンポーネントです。 トランスフォーマーには次のコンポーネントがあります。 - [Remove Variable](https://docs.mulesoft.com/jp/mule-runtime/4.8/remove-variable) - [Set Payload](https://docs.mulesoft.com/jp/mule-runtime/4.8/set-payload-transformer-reference) - [Set Variable](https://docs.mulesoft.com/jp/mule-runtime/4.8/variable-transformer-reference) ## [](#関連情報)関連情報 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) # コアコンポーネント コネクタとモジュールでの操作と同様に、コアコンポーネントは Mule アプリケーションのフローの重要なビルディングブロックです。コアコンポーネントは、Mule イベントが アプリケーションでリンクされた一連のステップを通過するときに処理する ロジックを提供します。たとえば、Scheduler、For Each、Logger などのコンポーネントがあります。 Studio では、Mule パレットから ​**\[Core (コア)\]**​ をクリックして Mule コンポーネントにアクセスできます。 ![Anypoint Studio のコアコンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/components-core-studio.png) コンポーネントは \[Batch (バッチ)\]、\[Error Handling (エラー処理)\]、 \[Flow Control (フローコントロール)\] などの種類に細分化されています。 ## [](#バッチ)バッチ Mule メッセージをバッチで処理するには、すべてまとめて処理する代わりに、 バッチコンポーネントを使用できます。このコンポーネントには次が含まれます。 - Batch Aggregator - Batch Job - Batch Step [「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-processing-concept)​を参照してください。 ## [](#コンポーネント)コンポーネント 次のコアコンポーネントはさまざまなタスクを実行します。 - [Custom Business Events](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events-custom)​: ビジネストランザクションを 処理するフローおよびメッセージプロセッサーに関する情報を収集。​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events)​も参照してください。 - [Dynamic Evaluate](https://docs.mulesoft.com/jp/mule-runtime/4.9/dynamic-evaluate-component-reference)​: Transform Message コンポーネントを 使用してスクリプトを強制的にハードコードする代わりに、動的に選択。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.9/flowref-about)​: Mule アプリケーション内で、 Mule イベントを別のフローまたはサブフローに転送。 - [Logger](https://docs.mulesoft.com/jp/mule-runtime/4.9/logger-component-reference)​: エラーメッセージや状況通知など、 Mule アプリケーションに関する重要な情報をログに記録。 - [Parse Template](https://docs.mulesoft.com/jp/mule-runtime/4.9/parse-template-reference)​: テンプレートを処理して結果を取得。 - [Transform Message](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about)​: 入力データを新しい出力構造 または形式に変換。 ## [](#エンドポイント)エンドポイント エンドポイント (Studio ではソースとも呼ばれる) には、 Mule フローで処理を開始 (またはトリガー) するコンポーネントが含まれます。​[Scheduler](https://docs.mulesoft.com/jp/mule-runtime/4.9/scheduler-concept)​ はエンドポイントです。設定可能な間隔で開始する フローをトリガーします。 一部のコネクタでは、エンドポイントとして機能するリスナーが提供されます。リスナーは、 外部要求を受け取ったときにフローをトリガーできます。たとえば、特定の URL に 設定された HTTP リスナーは、誰かまたはプロセスがその URL にアクセスしたときに フローをトリガーできます。 ## [](#エラー処理)エラー処理 エラー処理コンポーネントは、Mule アプリケーションで発生した Mule エラーの転送と処理を行います。 - Error Handler - On Error Continue - On Error Propagate [「エラーハンドラー」](https://docs.mulesoft.com/jp/mule-runtime/4.9/error-handling)​を参照してください。 ## [](#フローコントロール-ルーター)フローコントロール (ルーター) フローコントロールコンポーネント (ルーター) は、入力 Mule イベントを取得し、 コンポーネントの 1 つ以上の個別のシーケンスに転送します。フローコントロールには次のコンポーネントがあります。 - Choice - First Successful - Round Robin - Scatter-Gather たとえば、​[Choice ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.9/choice-router-concept)​は DataWeave ロジックを適用して複数のルートから 1 つを選択します。各ルートは イベントプロセッサーの個別のシーケンスです。 [Scatter-Gather ルーター](https://docs.mulesoft.com/jp/mule-runtime/4.9/scatter-gather-concept)​は入力イベントを すべてのルートに送信し、各ルートは単独でイベントを処理します。 すべてのルートでイベントが処理されたら、すべてのルートの結果が 1 つの出力イベントにまとめられます。 ## [](#スコープ)スコープ スコープは、イベントプロセッサーのシーケンス (他のコアコンポーネント、 モジュールとコネクタ両方からの操作など) をグループ化し、その分離された イベントプロセッサーのシーケンスにプログラミング動作を適用するコンポーネントの種類です。 スコープには次のコンポーネントがあります。 - Async - Cache - Flow - For Each - Try - Until Successful たとえば、Try スコープでは、フローの特定のシーケンスで発生するエラーを 分離して処理できます。そのため、アウトバウンド HTTP Request Connector (および Transform Message コンポーネントや Logging コンポーネントなど、HTTP Request Connector 前後にあるいくつかの周辺コンポーネント) を Try スコープでラップし、 エラーが発生した場合に、そのコンポーネントのグルーピングに固有のログまたは 補正ロジックを適用できます。​[「Try スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept)​を参照してください。 別の例として For Each (または Foreach) スコープがあります。このスコープは通常、 現在の入力イベントから抽出されたデータのコレクションを取得し、コレクション 内のすべての項目に同じイベントプロセッサーのシーケンスを適用します。たとえば、 For Each スコープはデータベースクエリから返された各行、または CSV ファイルの 各行を処理するために使用できます。​[「For Each スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/for-each-scope-concept)​を参照してください。 ## [](#トランスフォーマー)トランスフォーマー トランスフォーマーは、Mule イベントの一部を設定または削除するために使用できるコンポーネントです。 トランスフォーマーには次のコンポーネントがあります。 - [Remove Variable](https://docs.mulesoft.com/jp/mule-runtime/4.9/remove-variable) - [Set Payload](https://docs.mulesoft.com/jp/mule-runtime/4.9/set-payload-transformer-reference) - [Set Variable](https://docs.mulesoft.com/jp/mule-runtime/4.9/variable-transformer-reference) ## [](#関連情報)関連情報 - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) # コアコンポーネントの移行 以下の表は、Mule 3.x の各コンポーネントが Mule 4 では何に相当するのかを示しています。
Mule 3.x のコンポーネント Mule 4.0 の代替法

すべての router

代わりに ​Scatter Gather​ を使用するか、異なる対象属性を使用して操作を次々と実行した後に DW を使用して結果をマージします。

async[​processingStrategy​]

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

asynchronous-processing-strategy

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

bridge

同等のフローをビルドします。

catch-exception-strategy

on-error-continue​ 戦略を使用する ​error-handler​ を使用します。

choice-exception-strategy

エラー種別選択または when 属性を使用して、内部に異なる戦略を含む ​error-handler​ を使用します。

combine-collections-transformer

簡略化されたメッセージモデルでは不要になりました。MuleMessageCollections は Mule メッセージの配列に置き換わります。これは、DataWeave や foreach などの任意の Mule コンポーネントを使用してマージまたは反復できます。

コンポーネント

Java Module​ を使用します。

composite-source

各取得元に 1 つのフローを作成し、共通機能の flow-ref を使用して非公開フローを呼び出します。

configuration[​defaultExceptionStrategy-ref​]

新しい名前は ​defaultErrorHandler-ref​ です。

configuration[​flowEndingWithOneWayEndpointReturnsNull​]

新しい実行エンジンでは不要になりました。

configuration[​useExtendedTransformations​]

排除されました。

configuration[​enricherPropagatesSessionVariableChanges​]

排除されました。

copy-attachments

新しい​メッセージ構造​により、添付ファイルはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

copy-properties

新しい​メッセージ構造​により、プロパティはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

custom-agent

サポートされなくなりました。

custom-aggregator

Mule SDK​ を使用して、カスタムアグリゲーターをビルドします。

custom-connector

Mule SDK​ を使用して、独自のコネクタをビルドします。

custom-exception-strategy

不要になりました。​error-handler​ を使用します。

custom-lifecycle-adapter-factory

サポートされなくなりました。

custom-object-store

Object Store Connector​ を使用してカスタムストアを作成します。

custom-processor

Mule SDK​ を使用するか、​Scripting Module​ を使用します。

custom-queue-store

新しい ​VM Connector​ を使用します。

custom-router-resolver

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-router

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-service

フローを使用します。

custom-source

Mule SDK​ を使用して、新しいイベント取得元を記述します。

custom-splitter

DataWeave または ​Mule SDK​ を使用します。

custom-transaction-manager

<bti:transaction-manager/>​ を使用します。

custom-transaction

サポートされなくなりました。

default-exception-strategy

on-error-propagate​ 戦略を使用する ​error-handler​ を使用します。

default-in-memory-queue-store

新しい ​VM Connector​ を使用します。

default-persistent-queue-store

新しい ​VM Connector​ を使用します。

default-service-exception-strategy

on-error-propagate 戦略を使用する ​error-handler​ を使用します。

endpoint

コネクタを使用します。

exception-strategy

error-handler​ を使用します。

expression-component

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

file-queue-store

新しい ​VM Connector​ を使用します。

flow[​processingStrategy​]

排除されました。非ブロック実行エンジンを使用すれば、ユーザーはこれを調整する必要がありません。

idempotent-message-filter

Idempotent-message-validator​ に置き換わりました。

idempotent-redelivery-policy

新しい名前は ​redelivery-policy​ です。

idempotent-secure-hash-message-filter

Idempotent-message-validator​ に置き換わりました。

in-memory-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

inbound-endpoint

各コネクタまたはモジュールで定義されたイベント取得元またはトリガーを使用します。

include-entry-point

Java Module​ を使用します。

interceptor-stack

排除されました。カスタムポリシーを使用します。

invoke

Java Module​ を使用します。

jndi-transaction-manager

<bti:transaction-manager/>​ を使用します。

jrun-transaction-manager

<bti:transaction-manager/>​ を使用します。

legacy-abstract-exception-strategy

新しい ​error-handler​ を使用します。

managed-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

message-properties-transformer

Transform コンポーネントと DataWeave を使用します。

model

排除されました。代わりにフローを使用します。

mule[​version​]

outbound-endpoint

要素はコアの名前空間から新しいトランスポートの名前空間に移動されました。

poll → watermark

この機能は、Salesforce Connector、Database Connector、SFTP Connector、File Connector など、多数のコネクタのイベント取得元内に組み込まれました。 Object Store Connector を使用して、​手動で watermark (ウォーターマーク) 値を設定することもできます​。

poll

scheduler コンポーネント​に置き換わりました。

processor

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

prototype-object

Java Module または Spring Module を使用します。

queue-profile

VM Connector​ を使用します。

queue-store

VM Connector​。

recipient-list

排除されました。

reconnect-custom-notifier

排除されました。

reconnect-custom-strategy

排除されました。

reconnect-notifier

排除されました。

remove-attachment

新しい​メッセージ構造​により、添付ファイルは不要になりました。

remove-property

新しい​メッセージ構造​により、添付ファイルは不要になりました。

response

不要になりました。

request-reply

Mule 4 では、すべてのコネクタで request-reply がサポートされなくなります。“request-reply” 動作があったコネクタには、JMS の ​publish-consume​ 操作など、“request-reply” 操作が組み込まれます。

resin-transaction-manager

排除されました。

rollback-exception-strategy

on-error-propagate 戦略を使用する error-handler を使用します。

scatter-gather[​threading-profile​]

Mule 4 は非ブロックなので不要になりました。

seda-model

Mule 4 では SEDA キューがなくなりました。Mule 4 の実行エンジンは非ブロックです。

service

フローを使用します。

set-attachment

不要になりました。添付ファイルを変数として保存できます。

set-property

新しいメッセージモデルではプロパティが使用されなくなりました。Mule メッセージからの属性は変数に保存できます。

set-session-variable

セッション変数は削除されました。ユーザーはトランスポートの境界を越えて明示的にヘッダーを渡す必要があります。

simple-in-memory-queue-store

新しい VM Connector を使用します。

simple-service

フローを使用します。

simple-text-file-store

Object Store Module 拡張機能を使用してカスタムストアを作成します。

singleton-object

Java Module または Spring Module を使用します。

spring-object

Java Module または Spring Module を使用します。

synchronous-processing-strategy

フローコンポーネントの実行に関連する動作は、4.x のフローと同じですが、必ずしも 3.x と同じスレッドでは実行されません。

transactional scope

“try” スコープに置き換わりました。

username-password-filter

排除されました。

validator

排除されました。

weblogic-transaction-manager

<bti:transaction-manager/>​ を使用します。

websphere-transaction-manager

<bti:transaction-manager/>​ を使用します。

all-strategy

排除されました。

entry-point-resolver

Java Module​ を使用します。

filter

filter は ​Validation Module​ に置き換わります。

interceptor

interceptor はカスタムポリシーに置き換わります。

message-info-mapping

不要になりました。

point-resolver-set

Java Module​ を使用します。

router

排除されました。

threading-profile

不要になりました。Runtime で自動調整されます。

トランスフォーマー

排除されました。ほとんどの明示的な変換は不要になりました。コーナーケースには DataWeave を使用します。
# コアコンポーネントの移行 以下の表は、Mule 3.x の各コンポーネントが Mule 4 では何に相当するのかを示しています。
Mule 3.x のコンポーネント Mule 4.0 の代替法

すべての router

代わりに ​Scatter Gather​ を使用するか、異なる対象属性を使用して操作を次々と実行した後に DW を使用して結果をマージします。

async[​processingStrategy​]

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

asynchronous-processing-strategy

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

bridge

同等のフローをビルドします。

catch-exception-strategy

on-error-continue​ 戦略を使用する ​error-handler​ を使用します。

choice-exception-strategy

エラー種別選択または when 属性を使用して、内部に異なる戦略を含む ​error-handler​ を使用します。

combine-collections-transformer

簡略化されたメッセージモデルでは不要になりました。MuleMessageCollections は Mule メッセージの配列に置き換わります。これは、DataWeave や foreach などの任意の Mule コンポーネントを使用してマージまたは反復できます。

コンポーネント

Java Module​ を使用します。

composite-source

各取得元に 1 つのフローを作成し、共通機能の flow-ref を使用して非公開フローを呼び出します。

configuration[​defaultExceptionStrategy-ref​]

新しい名前は ​defaultErrorHandler-ref​ です。

configuration[​flowEndingWithOneWayEndpointReturnsNull​]

新しい実行エンジンでは不要になりました。

configuration[​useExtendedTransformations​]

排除されました。

configuration[​enricherPropagatesSessionVariableChanges​]

排除されました。

copy-attachments

新しい​メッセージ構造​により、添付ファイルはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

copy-properties

新しい​メッセージ構造​により、プロパティはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

custom-agent

サポートされなくなりました。

custom-aggregator

Mule SDK​ を使用して、カスタムアグリゲーターをビルドします。

custom-connector

Mule SDK​ を使用して、独自のコネクタをビルドします。

custom-exception-strategy

不要になりました。​error-handler​ を使用します。

custom-lifecycle-adapter-factory

サポートされなくなりました。

custom-object-store

Object Store Connector​ を使用してカスタムストアを作成します。

custom-processor

Mule SDK​ を使用するか、​Scripting Module​ を使用します。

custom-queue-store

新しい ​VM Connector​ を使用します。

custom-router-resolver

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-router

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-service

フローを使用します。

custom-source

Mule SDK​ を使用して、新しいイベント取得元を記述します。

custom-splitter

DataWeave または ​Mule SDK​ を使用します。

custom-transaction-manager

<bti:transaction-manager/>​ を使用します。

custom-transaction

サポートされなくなりました。

default-exception-strategy

on-error-propagate​ 戦略を使用する ​error-handler​ を使用します。

default-in-memory-queue-store

新しい ​VM Connector​ を使用します。

default-persistent-queue-store

新しい ​VM Connector​ を使用します。

default-service-exception-strategy

on-error-propagate 戦略を使用する ​error-handler​ を使用します。

endpoint

コネクタを使用します。

exception-strategy

error-handler​ を使用します。

expression-component

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

file-queue-store

新しい ​VM Connector​ を使用します。

flow[​processingStrategy​]

排除されました。非ブロック実行エンジンを使用すれば、ユーザーはこれを調整する必要がありません。

idempotent-message-filter

Idempotent-message-validator​ に置き換わりました。

idempotent-redelivery-policy

新しい名前は ​redelivery-policy​ です。

idempotent-secure-hash-message-filter

Idempotent-message-validator​ に置き換わりました。

in-memory-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

inbound-endpoint

各コネクタまたはモジュールで定義されたイベント取得元またはトリガーを使用します。

include-entry-point

Java Module​ を使用します。

interceptor-stack

排除されました。カスタムポリシーを使用します。

invoke

Java Module​ を使用します。

jndi-transaction-manager

<bti:transaction-manager/>​ を使用します。

jrun-transaction-manager

<bti:transaction-manager/>​ を使用します。

legacy-abstract-exception-strategy

新しい ​error-handler​ を使用します。

managed-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

message-properties-transformer

Transform コンポーネントと DataWeave を使用します。

model

排除されました。代わりにフローを使用します。

mule[​version​]

outbound-endpoint

要素はコアの名前空間から新しいトランスポートの名前空間に移動されました。

poll → watermark

この機能は、Salesforce Connector、Database Connector、SFTP Connector、File Connector など、多数のコネクタのイベント取得元内に組み込まれました。 Object Store Connector を使用して、​手動で watermark (ウォーターマーク) 値を設定することもできます​。

poll

scheduler コンポーネント​に置き換わりました。

processor

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

prototype-object

Java Module または Spring Module を使用します。

queue-profile

VM Connector​ を使用します。

queue-store

VM Connector​。

recipient-list

排除されました。

reconnect-custom-notifier

排除されました。

reconnect-custom-strategy

排除されました。

reconnect-notifier

排除されました。

remove-attachment

新しい​メッセージ構造​により、添付ファイルは不要になりました。

remove-property

新しい​メッセージ構造​により、添付ファイルは不要になりました。

response

不要になりました。

request-reply

Mule 4 では、すべてのコネクタで request-reply がサポートされなくなります。「request-reply」動作があったコネクタには、JMS の ​publish-consume​ 操作など、「request-reply」操作が組み込まれます。

resin-transaction-manager

排除されました。

rollback-exception-strategy

on-error-propagate 戦略を使用する error-handler を使用します。

scatter-gather[​threading-profile​]

Mule 4 は非ブロックなので不要になりました。

seda-model

Mule 4 では SEDA キューがなくなりました。Mule 4 の実行エンジンは非ブロックです。

service

フローを使用します。

set-attachment

不要になりました。添付ファイルを変数として保存できます。

set-property

新しいメッセージモデルではプロパティが使用されなくなりました。Mule メッセージからの属性は変数に保存できます。

set-session-variable

セッション変数は削除されました。ユーザーはトランスポートの境界を越えて明示的にヘッダーを渡す必要があります。

simple-in-memory-queue-store

新しい VM Connector を使用します。

simple-service

フローを使用します。

simple-text-file-store

Object Store Module 拡張機能を使用してカスタムストアを作成します。

singleton-object

Java Module または Spring Module を使用します。

spring-object

Java Module または Spring Module を使用します。

synchronous-processing-strategy

フローコンポーネントの実行に関連する動作は、4.x のフローと同じですが、必ずしも 3.x と同じスレッドでは実行されません。

transactional scope

「try」スコープに置き換わりました。

username-password-filter

排除されました。

validator

排除されました。

weblogic-transaction-manager

<bti:transaction-manager/>​ を使用します。

websphere-transaction-manager

<bti:transaction-manager/>​ を使用します。

all-strategy

排除されました。

entry-point-resolver

Java Module​ を使用します。

filter

filter は ​Validation Module​ に置き換わります。

interceptor

interceptor はカスタムポリシーに置き換わります。

message-info-mapping

不要になりました。

point-resolver-set

Java Module​ を使用します。

router

排除されました。

threading-profile

不要になりました。Runtime で自動調整されます。

トランスフォーマー

排除されました。ほとんどの明示的な変換は不要になりました。コーナーケースには DataWeave を使用します。
# コアコンポーネントの移行 以下の表は、Mule 3.x の各コンポーネントが Mule 4 では何に相当するのかを示しています。
Mule 3.x のコンポーネント Mule 4.0 の代替法

すべての router

代わりに ​Scatter Gather​ を使用するか、異なる対象属性を使用して操作を次々と実行した後に DW を使用して結果をマージします。

async[​processingStrategy​]

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

asynchronous-processing-strategy

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

bridge

同等のフローをビルドします。

catch-exception-strategy

on-error-continue​ 戦略を使用する ​error-handler​ を使用します。

choice-exception-strategy

エラー種別選択または when 属性を使用して、内部に異なる戦略を含む ​error-handler​ を使用します。

combine-collections-transformer

簡略化されたメッセージモデルでは不要になりました。MuleMessageCollections は Mule メッセージの配列に置き換わります。これは、DataWeave や foreach などの任意の Mule コンポーネントを使用してマージまたは反復できます。

コンポーネント

Java Module​ を使用します。

composite-source

各取得元に 1 つのフローを作成し、共通機能の flow-ref を使用して非公開フローを呼び出します。

configuration[​defaultExceptionStrategy-ref​]

新しい名前は ​defaultErrorHandler-ref​ です。

configuration[​flowEndingWithOneWayEndpointReturnsNull​]

新しい実行エンジンでは不要になりました。

configuration[​useExtendedTransformations​]

排除されました。

configuration[​enricherPropagatesSessionVariableChanges​]

排除されました。

copy-attachments

新しい​メッセージ構造​により、添付ファイルはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

copy-properties

新しい​メッセージ構造​により、プロパティはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

custom-agent

サポートされなくなりました。

custom-aggregator

Mule SDK​ を使用して、カスタムアグリゲーターをビルドします。

custom-connector

Mule SDK​ を使用して、独自のコネクタをビルドします。

custom-exception-strategy

不要になりました。​error-handler​ を使用します。

custom-lifecycle-adapter-factory

サポートされなくなりました。

custom-object-store

Object Store Connector​ を使用してカスタムストアを作成します。

custom-processor

Mule SDK​ を使用するか、​Scripting Module​ を使用します。

custom-queue-store

新しい ​VM Connector​ を使用します。

custom-router-resolver

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-router

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-service

フローを使用します。

custom-source

Mule SDK​ を使用して、新しいイベント取得元を記述します。

custom-splitter

DataWeave または ​Mule SDK​ を使用します。

custom-transaction-manager

<bti:transaction-manager/>​ を使用します。

custom-transaction

サポートされなくなりました。

default-exception-strategy

on-error-propagate​ 戦略を使用する ​error-handler​ を使用します。

default-in-memory-queue-store

新しい ​VM Connector ​を使用します。

default-persistent-queue-store

新しい ​VM Connector​ を使用します。

default-service-exception-strategy

on-error-propagate 戦略を使用する ​error-handler​ を使用します。

endpoint

コネクタを使用します。

exception-strategy

error-handler​ を使用します。

expression-component

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

file-queue-store

新しい ​VM Connector​ を使用します。

flow[​processingStrategy​]

排除されました。非ブロック実行エンジンを使用すれば、ユーザーはこれを調整する必要がありません。

idempotent-message-filter

Idempotent-message-validator​ に置き換わりました。

idempotent-redelivery-policy

新しい名前は ​redelivery-policy​ です。

idempotent-secure-hash-message-filter

Idempotent-message-validator​ に置き換わりました。

in-memory-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

inbound-endpoint

各コネクタまたはモジュールで定義されたイベント取得元またはトリガーを使用します。

include-entry-point

Java Module​ を使用します。

interceptor-stack

排除されました。カスタムポリシーを使用します。

invoke

Java Module​ を使用します。

jndi-transaction-manager

<bti:transaction-manager/>​ を使用します。

jrun-transaction-manager

<bti:transaction-manager/>​ を使用します。

legacy-abstract-exception-strategy

新しい ​error-handler​ を使用します。

managed-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

message-properties-transformer

Transform コンポーネントと DataWeave を使用します。

model

排除されました。代わりにフローを使用します。

mule[​version​]

outbound-endpoint

要素はコアの名前空間から新しいトランスポートの名前空間に移動されました。

poll → watermark

この機能は、Salesforce Connector、Database Connector、SFTP Connector、File Connector など、多数のコネクタのイベント取得元内に組み込まれました。 Object Store Connector を使用して、​手動で watermark (ウォーターマーク) 値を設定することもできます​。

poll

scheduler コンポーネント​に置き換わりました。

processor

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

prototype-object

Java Module または Spring Module を使用します。

queue-profile

VM Connector​ を使用します。

queue-store

VM Connector​。

recipient-list

排除されました。

reconnect-custom-notifier

排除されました。

reconnect-custom-strategy

排除されました。

reconnect-notifier

排除されました。

remove-attachment

新しい​メッセージ構造​により、添付ファイルは不要になりました。

remove-property

新しい​メッセージ構造​により、添付ファイルは不要になりました。

response

不要になりました。

request-reply

Mule 4 では、すべてのコネクタで request-reply がサポートされなくなります。「request-reply」動作があったコネクタには、JMS の ​publish-consume​ 操作など、「request-reply」操作が組み込まれます。

resin-transaction-manager

排除されました。

rollback-exception-strategy

on-error-propagate 戦略を使用する error-handler を使用します。

scatter-gather[​threading-profile​]

Mule 4 は非ブロックなので不要になりました。

seda-model

Mule 4 では SEDA キューがなくなりました。Mule 4 の実行エンジンは非ブロックです。

service

フローを使用します。

set-attachment

不要になりました。添付ファイルを変数として保存できます。

set-property

新しいメッセージモデルではプロパティが使用されなくなりました。Mule メッセージからの属性は変数に保存できます。

set-session-variable

セッション変数は削除されました。ユーザーはトランスポートの境界を越えて明示的にヘッダーを渡す必要があります。

simple-in-memory-queue-store

新しい VM Connector を使用します。

simple-service

フローを使用します。

simple-text-file-store

Object Store Module 拡張機能を使用してカスタムストアを作成します。

singleton-object

Java Module または Spring Module を使用します。

spring-object

Java Module または Spring Module を使用します。

synchronous-processing-strategy

フローコンポーネントの実行に関連する動作は、4.x のフローと同じですが、必ずしも 3.x と同じスレッドでは実行されません。

transactional scope

「try」スコープに置き換わりました。

username-password-filter

排除されました。

validator

排除されました。

weblogic-transaction-manager

<bti:transaction-manager/>​ を使用します。

websphere-transaction-manager

<bti:transaction-manager/>​ を使用します。

all-strategy

排除されました。

entry-point-resolver

Java Module​ を使用します。

filter

filter は ​Validation Module​ に置き換わります。

interceptor

interceptor はカスタムポリシーに置き換わります。

message-info-mapping

不要になりました。

point-resolver-set

Java Module​ を使用します。

router

排除されました。

threading-profile

不要になりました。Runtime で自動調整されます。

トランスフォーマー

排除されました。ほとんどの明示的な変換は不要になりました。コーナーケースには DataWeave を使用します。
# コアコンポーネントの移行 以下の表は、Mule 3.x の各コンポーネントが Mule 4 では何に相当するのかを示しています。
Mule 3.x のコンポーネント Mule 4.0 の代替法

すべての router

代わりに ​Scatter Gather​ を使用するか、異なる対象属性を使用して操作を次々と実行した後に DW を使用して結果をマージします。

async[​processingStrategy​]

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

asynchronous-processing-strategy

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

bridge

同等のフローをビルドします。

catch-exception-strategy

on-error-continue​ 戦略を使用する ​error-handler​ を使用します。

choice-exception-strategy

エラー種別選択または when 属性を使用して、内部に異なる戦略を含む ​error-handler​ を使用します。

combine-collections-transformer

簡略化されたメッセージモデルでは不要になりました。MuleMessageCollections は Mule メッセージの配列に置き換わります。これは、DataWeave や foreach などの任意の Mule コンポーネントを使用してマージまたは反復できます。

コンポーネント

Java Module​ を使用します。

composite-source

各取得元に 1 つのフローを作成し、共通機能の flow-ref を使用して非公開フローを呼び出します。

configuration[​defaultExceptionStrategy-ref​]

新しい名前は ​defaultErrorHandler-ref​ です。

configuration[​flowEndingWithOneWayEndpointReturnsNull​]

新しい実行エンジンでは不要になりました。

configuration[​useExtendedTransformations​]

排除されました。

configuration[​enricherPropagatesSessionVariableChanges​]

排除されました。

copy-attachments

新しい​メッセージ構造​により、添付ファイルはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

copy-properties

新しい​メッセージ構造​により、プロパティはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

custom-agent

サポートされなくなりました。

custom-aggregator

Mule SDK​ を使用して、カスタムアグリゲーターをビルドします。

custom-connector

Mule SDK​ を使用して、独自のコネクタをビルドします。

custom-exception-strategy

不要になりました。​error-handler​ を使用します。

custom-lifecycle-adapter-factory

サポートされなくなりました。

custom-object-store

Object Store Connector​ を使用してカスタムストアを作成します。

custom-processor

Mule SDK​ を使用するか、​Scripting Module​ を使用します。

custom-queue-store

新しい ​VM Connector ​を使用します。

custom-router-resolver

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-router

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-service

フローを使用します。

custom-source

Mule SDK​ を使用して、新しいイベント取得元を記述します。

custom-splitter

DataWeave または ​Mule SDK​ を使用します。

custom-transaction-manager

<bti:transaction-manager/>​ を使用します。

custom-transaction

サポートされなくなりました。

default-exception-strategy

on-error-propagate​ 戦略を使用する ​error-handler​ を使用します。

default-in-memory-queue-store

新しい ​VM Connector ​を使用します。

default-persistent-queue-store

新しい ​VM Connector ​を使用します。

default-service-exception-strategy

on-error-propagate 戦略を使用する ​error-handler​ を使用します。

endpoint

コネクタを使用します。

exception-strategy

error-handler​ を使用します。

expression-component

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

file-queue-store

新しい ​VM Connector ​を使用します。

flow[​processingStrategy​]

排除されました。非ブロック実行エンジンを使用すれば、ユーザーはこれを調整する必要がありません。

idempotent-message-filter

Idempotent-message-validator​ に置き換わりました。

idempotent-redelivery-policy

新しい名前は ​redelivery-policy​ です。

idempotent-secure-hash-message-filter

Idempotent-message-validator​ に置き換わりました。

in-memory-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

inbound-endpoint

各コネクタまたはモジュールで定義されたイベント取得元またはトリガーを使用します。

include-entry-point

Java Module​ を使用します。

interceptor-stack

排除されました。カスタムポリシーを使用します。

invoke

Java Module​ を使用します。

jndi-transaction-manager

<bti:transaction-manager/>​ を使用します。

jrun-transaction-manager

<bti:transaction-manager/>​ を使用します。

legacy-abstract-exception-strategy

新しい ​error-handler​ を使用します。

managed-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

message-properties-transformer

Transform コンポーネントと DataWeave を使用します。

model

排除されました。代わりにフローを使用します。

mule[​version​]

outbound-endpoint

要素はコアの名前空間から新しいトランスポートの名前空間に移動されました。

poll → watermark

この機能は、Salesforce Connector、Database Connector、SFTP Connector、File Connector など、多数のコネクタのイベント取得元内に組み込まれました。 Object Store Connector を使用して、​手動で watermark (ウォーターマーク) 値を設定することもできます​。

poll

scheduler コンポーネント​に置き換わりました。

processor

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

prototype-object

Java Module または Spring Module を使用します。

queue-profile

VM Connector ​を使用します。

queue-store

VM Connector​。

recipient-list

排除されました。

reconnect-custom-notifier

排除されました。

reconnect-custom-strategy

排除されました。

reconnect-notifier

排除されました。

remove-attachment

新しい​メッセージ構造​により、添付ファイルは不要になりました。

remove-property

新しい​メッセージ構造​により、添付ファイルは不要になりました。

response

不要になりました。

request-reply

Mule 4 では、すべてのコネクタで request-reply がサポートされなくなります。「request-reply」動作があったコネクタには、JMS の ​publish-consume​ 操作など、「request-reply」操作が組み込まれます。

resin-transaction-manager

排除されました。

rollback-exception-strategy

on-error-propagate 戦略を使用する error-handler を使用します。

scatter-gather[​threading-profile​]

Mule 4 は非ブロックなので不要になりました。

seda-model

Mule 4 では SEDA キューがなくなりました。Mule 4 の実行エンジンは非ブロックです。

service

フローを使用します。

set-attachment

不要になりました。添付ファイルを変数として保存できます。

set-property

新しいメッセージモデルではプロパティが使用されなくなりました。Mule メッセージからの属性は変数に保存できます。

set-session-variable

セッション変数は削除されました。ユーザーはトランスポートの境界を越えて明示的にヘッダーを渡す必要があります。

simple-in-memory-queue-store

新しい VM Connector を使用します。

simple-service

フローを使用します。

simple-text-file-store

Object Store Module 拡張機能を使用してカスタムストアを作成します。

singleton-object

Java Module または Spring Module を使用します。

spring-object

Java Module または Spring Module を使用します。

synchronous-processing-strategy

フローコンポーネントの実行に関連する動作は、4.x のフローと同じですが、必ずしも 3.x と同じスレッドでは実行されません。

transactional scope

「try」スコープに置き換わりました。

username-password-filter

排除されました。

validator

排除されました。

weblogic-transaction-manager

<bti:transaction-manager/>​ を使用します。

websphere-transaction-manager

<bti:transaction-manager/>​ を使用します。

all-strategy

排除されました。

entry-point-resolver

Java Module​ を使用します。

filter

filter は ​Validation Module​ に置き換わります。

interceptor

interceptor はカスタムポリシーに置き換わります。

message-info-mapping

不要になりました。

point-resolver-set

Java Module​ を使用します。

router

排除されました。

threading-profile

不要になりました。Runtime で自動調整されます。

トランスフォーマー

排除されました。ほとんどの明示的な変換は不要になりました。コーナーケースには DataWeave を使用します。
# コアコンポーネントの移行 以下の表は、Mule 3.x の各コンポーネントが Mule 4 では何に相当するのかを示しています。
Mule 3.x のコンポーネント Mule 4.0 の代替法

すべての router

代わりに ​Scatter Gather​ を使用するか、異なる対象属性を使用して操作を次々と実行した後に DW を使用して結果をマージします。

async[​processingStrategy​]

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

asynchronous-processing-strategy

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

bridge

同等のフローをビルドします。

catch-exception-strategy

on-error-continue​ 戦略を使用する ​error-handler​ を使用します。

choice-exception-strategy

エラー種別選択または when 属性を使用して、内部に異なる戦略を含む ​error-handler​ を使用します。

combine-collections-transformer

簡略化されたメッセージモデルでは不要になりました。MuleMessageCollections は Mule メッセージの配列に置き換わります。これは、DataWeave や foreach などの任意の Mule コンポーネントを使用してマージまたは反復できます。

コンポーネント

Java Module​ を使用します。

composite-source

各取得元に 1 つのフローを作成し、共通機能の flow-ref を使用して非公開フローを呼び出します。

configuration[​defaultExceptionStrategy-ref​]

新しい名前は ​defaultErrorHandler-ref​ です。

configuration[​flowEndingWithOneWayEndpointReturnsNull​]

新しい実行エンジンでは不要になりました。

configuration[​useExtendedTransformations​]

排除されました。

configuration[​enricherPropagatesSessionVariableChanges​]

排除されました。

copy-attachments

新しい​メッセージ構造​により、添付ファイルはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

copy-properties

新しい​メッセージ構造​により、プロパティはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

custom-agent

サポートされなくなりました。

custom-aggregator

Mule SDK​ を使用して、カスタムアグリゲーターをビルドします。

custom-connector

Mule SDK​ を使用して、独自のコネクタをビルドします。

custom-exception-strategy

不要になりました。​error-handler​ を使用します。

custom-lifecycle-adapter-factory

サポートされなくなりました。

custom-object-store

Object Store Connector​ を使用してカスタムストアを作成します。

custom-processor

Mule SDK​ を使用するか、​Scripting Module​ を使用します。

custom-queue-store

新しい ​VM Connector ​を使用します。

custom-router-resolver

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-router

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-service

フローを使用します。

custom-source

Mule SDK​ を使用して、新しいイベント取得元を記述します。

custom-splitter

DataWeave または ​Mule SDK​ を使用します。

custom-transaction-manager

<bti:transaction-manager/>​ を使用します。

custom-transaction

サポートされなくなりました。

default-exception-strategy

on-error-propagate​ 戦略を使用する ​error-handler​ を使用します。

default-in-memory-queue-store

新しい ​VM Connector ​を使用します。

default-persistent-queue-store

新しい ​VM Connector ​を使用します。

default-service-exception-strategy

on-error-propagate 戦略を使用する ​error-handler​ を使用します。

endpoint

コネクタを使用します。

exception-strategy

error-handler​ を使用します。

expression-component

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

file-queue-store

新しい ​VM Connector ​を使用します。

flow[​processingStrategy​]

排除されました。非ブロック実行エンジンを使用すれば、ユーザーはこれを調整する必要がありません。

idempotent-message-filter

Idempotent-message-validator​ に置き換わりました。

idempotent-redelivery-policy

新しい名前は ​redelivery-policy​ です。

idempotent-secure-hash-message-filter

Idempotent-message-validator​ に置き換わりました。

in-memory-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

inbound-endpoint

各コネクタまたはモジュールで定義されたイベント取得元またはトリガーを使用します。

include-entry-point

Java Module​ を使用します。

interceptor-stack

排除されました。カスタムポリシーを使用します。

invoke

Java Module​ を使用します。

jndi-transaction-manager

<bti:transaction-manager/>​ を使用します。

jrun-transaction-manager

<bti:transaction-manager/>​ を使用します。

legacy-abstract-exception-strategy

新しい ​error-handler​ を使用します。

managed-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

message-properties-transformer

Transform コンポーネントと DataWeave を使用します。

model

排除されました。代わりにフローを使用します。

mule[​version​]

outbound-endpoint

要素はコアの名前空間から新しいトランスポートの名前空間に移動されました。

poll → watermark

この機能は、Salesforce Connector、Database Connector、SFTP Connector、File Connector など、多数のコネクタのイベント取得元内に組み込まれました。 Object Store Connector を使用して、​手動で watermark (ウォーターマーク) 値を設定することもできます​。

poll

scheduler コンポーネント​に置き換わりました。

processor

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

prototype-object

Java Module または Spring Module を使用します。

queue-profile

VM Connector ​を使用します。

queue-store

VM Connector​。

recipient-list

排除されました。

reconnect-custom-notifier

排除されました。

reconnect-custom-strategy

排除されました。

reconnect-notifier

排除されました。

remove-attachment

新しい​メッセージ構造​により、添付ファイルは不要になりました。

remove-property

新しい​メッセージ構造​により、添付ファイルは不要になりました。

response

不要になりました。

request-reply

Mule 4 では、すべてのコネクタで request-reply がサポートされなくなります。「request-reply」動作があったコネクタには、JMS の ​publish-consume​ 操作など、「request-reply」操作が組み込まれます。

resin-transaction-manager

排除されました。

rollback-exception-strategy

on-error-propagate 戦略を使用する error-handler を使用します。

scatter-gather[​threading-profile​]

Mule 4 は非ブロックなので不要になりました。

seda-model

Mule 4 では SEDA キューがなくなりました。Mule 4 の実行エンジンは非ブロックです。

service

フローを使用します。

set-attachment

不要になりました。添付ファイルを変数として保存できます。

set-property

新しいメッセージモデルではプロパティが使用されなくなりました。Mule メッセージからの属性は変数に保存できます。

set-session-variable

セッション変数は削除されました。ユーザーはトランスポートの境界を越えて明示的にヘッダーを渡す必要があります。

simple-in-memory-queue-store

新しい VM Connector を使用します。

simple-service

フローを使用します。

simple-text-file-store

Object Store Module 拡張機能を使用してカスタムストアを作成します。

singleton-object

Java Module または Spring Module を使用します。

spring-object

Java Module または Spring Module を使用します。

synchronous-processing-strategy

フローコンポーネントの実行に関連する動作は、4.x のフローと同じですが、必ずしも 3.x と同じスレッドでは実行されません。

transactional scope

「try」スコープに置き換わりました。

username-password-filter

排除されました。

validator

排除されました。

weblogic-transaction-manager

<bti:transaction-manager/>​ を使用します。

websphere-transaction-manager

<bti:transaction-manager/>​ を使用します。

all-strategy

排除されました。

entry-point-resolver

Java Module​ を使用します。

filter

filter は ​Validation Module​ に置き換わります。

interceptor

interceptor はカスタムポリシーに置き換わります。

message-info-mapping

不要になりました。

point-resolver-set

Java Module​ を使用します。

router

排除されました。

threading-profile

不要になりました。Runtime で自動調整されます。

トランスフォーマー

排除されました。ほとんどの明示的な変換は不要になりました。コーナーケースには DataWeave を使用します。
# コアコンポーネントの移行 以下の表は、Mule 3.x の各コンポーネントが Mule 4 では何に相当するのかを示しています。
Mule 3.x のコンポーネント Mule 4.0 の代替法

すべての router

代わりに ​Scatter Gather​ を使用するか、異なる対象属性を使用して操作を次々と実行した後に DW を使用して結果をマージします。

async[​processingStrategy​]

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

asynchronous-processing-strategy

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

bridge

同等のフローをビルドします。

catch-exception-strategy

on-error-continue​ 戦略を使用する ​error-handler​ を使用します。

choice-exception-strategy

エラー種別選択または when 属性を使用して、内部に異なる戦略を含む ​error-handler​ を使用します。

combine-collections-transformer

簡略化されたメッセージモデルでは不要になりました。MuleMessageCollections は Mule メッセージの配列に置き換わります。これは、DataWeave や foreach などの任意の Mule コンポーネントを使用してマージまたは反復できます。

コンポーネント

Java Module​ を使用します。

composite-source

各取得元に 1 つのフローを作成し、共通機能の flow-ref を使用して非公開フローを呼び出します。

configuration[​defaultExceptionStrategy-ref​]

新しい名前は ​defaultErrorHandler-ref​ です。

configuration[​flowEndingWithOneWayEndpointReturnsNull​]

新しい実行エンジンでは不要になりました。

configuration[​useExtendedTransformations​]

排除されました。

configuration[​enricherPropagatesSessionVariableChanges​]

排除されました。

copy-attachments

新しい​メッセージ構造​により、添付ファイルはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

copy-properties

新しい​メッセージ構造​により、プロパティはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

custom-agent

サポートされなくなりました。

custom-aggregator

Mule SDK​ を使用して、カスタムアグリゲーターをビルドします。

custom-connector

Mule SDK​ を使用して、独自のコネクタをビルドします。

custom-exception-strategy

不要になりました。​error-handler​ を使用します。

custom-lifecycle-adapter-factory

サポートされなくなりました。

custom-object-store

Object Store Connector​ を使用してカスタムストアを作成します。

custom-processor

Mule SDK​ を使用するか、​Scripting Module​ を使用します。

custom-queue-store

新しい ​VM Connector ​を使用します。

custom-router-resolver

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-router

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-service

フローを使用します。

custom-source

Mule SDK​ を使用して、新しいイベント取得元を記述します。

custom-splitter

DataWeave または ​Mule SDK​ を使用します。

custom-transaction-manager

<bti:transaction-manager/>​ を使用します。

custom-transaction

サポートされなくなりました。

default-exception-strategy

on-error-propagate​ 戦略を使用する ​error-handler​ を使用します。

default-in-memory-queue-store

新しい ​VM Connector ​を使用します。

default-persistent-queue-store

新しい ​VM Connector ​を使用します。

default-service-exception-strategy

on-error-propagate 戦略を使用する ​error-handler​ を使用します。

endpoint

コネクタを使用します。

exception-strategy

error-handler​ を使用します。

expression-component

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

file-queue-store

新しい ​VM Connector ​を使用します。

flow[​processingStrategy​]

排除されました。非ブロック実行エンジンを使用すれば、ユーザーはこれを調整する必要がありません。

idempotent-message-filter

Idempotent-message-validator​ に置き換わりました。

idempotent-redelivery-policy

新しい名前は ​redelivery-policy​ です。

idempotent-secure-hash-message-filter

Idempotent-message-validator​ に置き換わりました。

in-memory-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

inbound-endpoint

各コネクタまたはモジュールで定義されたイベント取得元またはトリガーを使用します。

include-entry-point

Java Module​ を使用します。

interceptor-stack

排除されました。カスタムポリシーを使用します。

invoke

Java Module​ を使用します。

jndi-transaction-manager

<bti:transaction-manager/>​ を使用します。

jrun-transaction-manager

<bti:transaction-manager/>​ を使用します。

legacy-abstract-exception-strategy

新しい ​error-handler​ を使用します。

managed-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

message-properties-transformer

Transform コンポーネントと DataWeave を使用します。

model

排除されました。代わりにフローを使用します。

mule[​version​]

outbound-endpoint

要素はコアの名前空間から新しいトランスポートの名前空間に移動されました。

poll → watermark

この機能は、Salesforce Connector、Database Connector、SFTP Connector、File Connector など、多数のコネクタのイベント取得元内に組み込まれました。 Object Store Connector を使用して、​手動で watermark (ウォーターマーク) 値を設定することもできます​。

poll

scheduler コンポーネント​に置き換わりました。

processor

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

prototype-object

Java Module または Spring Module を使用します。

queue-profile

VM Connector ​を使用します。

queue-store

VM Connector​。

recipient-list

排除されました。

reconnect-custom-notifier

排除されました。

reconnect-custom-strategy

排除されました。

reconnect-notifier

排除されました。

remove-attachment

新しい​メッセージ構造​により、添付ファイルは不要になりました。

remove-property

新しい​メッセージ構造​により、添付ファイルは不要になりました。

response

不要になりました。

request-reply

Mule 4 では、すべてのコネクタで request-reply がサポートされなくなります。「request-reply」動作があったコネクタには、JMS の ​publish-consume​ 操作など、「request-reply」操作が組み込まれます。

resin-transaction-manager

排除されました。

rollback-exception-strategy

on-error-propagate 戦略を使用する error-handler を使用します。

scatter-gather[​threading-profile​]

Mule 4 は非ブロックなので不要になりました。

seda-model

Mule 4 では SEDA キューがなくなりました。Mule 4 の実行エンジンは非ブロックです。

service

フローを使用します。

set-attachment

不要になりました。添付ファイルを変数として保存できます。

set-property

新しいメッセージモデルではプロパティが使用されなくなりました。Mule メッセージからの属性は変数に保存できます。

set-session-variable

セッション変数は削除されました。ユーザーはトランスポートの境界を越えて明示的にヘッダーを渡す必要があります。

simple-in-memory-queue-store

新しい VM Connector を使用します。

simple-service

フローを使用します。

simple-text-file-store

Object Store Module 拡張機能を使用してカスタムストアを作成します。

singleton-object

Java Module または Spring Module を使用します。

spring-object

Java Module または Spring Module を使用します。

synchronous-processing-strategy

フローコンポーネントの実行に関連する動作は、4.x のフローと同じですが、必ずしも 3.x と同じスレッドでは実行されません。

transactional scope

「try」スコープに置き換わりました。

username-password-filter

排除されました。

validator

排除されました。

weblogic-transaction-manager

<bti:transaction-manager/>​ を使用します。

websphere-transaction-manager

<bti:transaction-manager/>​ を使用します。

all-strategy

排除されました。

entry-point-resolver

Java Module​ を使用します。

filter

filter は ​Validation Module​ に置き換わります。

interceptor

interceptor はカスタムポリシーに置き換わります。

message-info-mapping

不要になりました。

point-resolver-set

Java Module​ を使用します。

router

排除されました。

threading-profile

不要になりました。Runtime で自動調整されます。

トランスフォーマー

排除されました。ほとんどの明示的な変換は不要になりました。コーナーケースには DataWeave を使用します。
# コアコンポーネントの移行 以下の表は、Mule 3.x の各コンポーネントが Mule 4 では何に相当するのかを示しています。
Mule 3.x のコンポーネント Mule 4.0 の代替法

すべての router

代わりに ​Scatter Gather​ を使用するか、異なる対象属性を使用して操作を次々と実行した後に DW を使用して結果をマージします。

async[​processingStrategy​]

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

asynchronous-processing-strategy

非ブロック実行エンジンには非同期処理戦略が不要になりました。Mule 4 に移行するときに、スコープからすべての処理戦略を削除してください。非同期で実行する必要があるすべてのコンポーネントをラップする ​Async​ スコープを使用します。

bridge

同等のフローをビルドします。

catch-exception-strategy

on-error-continue​ 戦略を使用する ​error-handler​ を使用します。

choice-exception-strategy

エラー種別選択または when 属性を使用して、内部に異なる戦略を含む ​error-handler​ を使用します。

combine-collections-transformer

簡略化されたメッセージモデルでは不要になりました。MuleMessageCollections は Mule メッセージの配列に置き換わります。これは、DataWeave や foreach などの任意の Mule コンポーネントを使用してマージまたは反復できます。

コンポーネント

Java Module​ を使用します。

composite-source

各取得元に 1 つのフローを作成し、共通機能の flow-ref を使用して非公開フローを呼び出します。

configuration[​defaultExceptionStrategy-ref​]

新しい名前は ​defaultErrorHandler-ref​ です。

configuration[​flowEndingWithOneWayEndpointReturnsNull​]

新しい実行エンジンでは不要になりました。

configuration[​useExtendedTransformations​]

排除されました。

configuration[​enricherPropagatesSessionVariableChanges​]

排除されました。

copy-attachments

新しい​メッセージ構造​により、添付ファイルはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

copy-properties

新しい​メッセージ構造​により、プロパティはメッセージの属性の一部になります。添付ファイルは DataWeave を使用して自由に操作できます。

custom-agent

サポートされなくなりました。

custom-aggregator

Mule SDK​ を使用して、カスタムアグリゲーターをビルドします。

custom-connector

Mule SDK​ を使用して、独自のコネクタをビルドします。

custom-exception-strategy

不要になりました。​error-handler​ を使用します。

custom-lifecycle-adapter-factory

サポートされなくなりました。

custom-object-store

Object Store Connector​ を使用してカスタムストアを作成します。

custom-processor

Mule SDK​ を使用するか、​Scripting Module​ を使用します。

custom-queue-store

新しい ​VM Connector ​を使用します。

custom-router-resolver

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-router

Mule SDK​ を使用して、カスタムルーターをビルドします。

custom-service

フローを使用します。

custom-source

Mule SDK​ を使用して、新しいイベント取得元を記述します。

custom-splitter

DataWeave または ​Mule SDK​ を使用します。

custom-transaction-manager

<bti:transaction-manager/>​ を使用します。

custom-transaction

サポートされなくなりました。

default-exception-strategy

on-error-propagate​ 戦略を使用する ​error-handler​ を使用します。

default-in-memory-queue-store

新しい ​VM Connector ​を使用します。

default-persistent-queue-store

新しい ​VM Connector ​を使用します。

default-service-exception-strategy

on-error-propagate 戦略を使用する ​error-handler​ を使用します。

endpoint

コネクタを使用します。

exception-strategy

error-handler​ を使用します。

expression-component

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

file-queue-store

新しい ​VM Connector ​を使用します。

flow[​processingStrategy​]

排除されました。非ブロック実行エンジンを使用すれば、ユーザーはこれを調整する必要がありません。

idempotent-message-filter

Idempotent-message-validator​ に置き換わりました。

idempotent-redelivery-policy

新しい名前は ​redelivery-policy​ です。

idempotent-secure-hash-message-filter

Idempotent-message-validator​ に置き換わりました。

in-memory-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

inbound-endpoint

各コネクタまたはモジュールで定義されたイベント取得元またはトリガーを使用します。

include-entry-point

Java Module​ を使用します。

interceptor-stack

排除されました。カスタムポリシーを使用します。

invoke

Java Module​ を使用します。

jndi-transaction-manager

<bti:transaction-manager/>​ を使用します。

jrun-transaction-manager

<bti:transaction-manager/>​ を使用します。

legacy-abstract-exception-strategy

新しい ​error-handler​ を使用します。

managed-store

Object Store Connector​ を使用して​カスタムストア​を作成します。

message-properties-transformer

Transform コンポーネントと DataWeave を使用します。

model

排除されました。代わりにフローを使用します。

mule[​version​]

outbound-endpoint

要素はコアの名前空間から新しいトランスポートの名前空間に移動されました。

poll → watermark

この機能は、Salesforce Connector、Database Connector、SFTP Connector、File Connector など、多数のコネクタのイベント取得元内に組み込まれました。 Object Store Connector を使用して、​手動で watermark (ウォーターマーク) 値を設定することもできます​。

poll

scheduler コンポーネント​に置き換わりました。

processor

式の機能に応じて、データアクセスの式には DataWeave を、アルゴリズムの式には ​Scripting Module​ または ​Mule SDK​ を、単に Java にアクセスする式には ​Java Module​ を使用できます。

prototype-object

Java Module または Spring Module を使用します。

queue-profile

VM Connector ​を使用します。

queue-store

VM Connector​。

recipient-list

排除されました。

reconnect-custom-notifier

排除されました。

reconnect-custom-strategy

排除されました。

reconnect-notifier

排除されました。

remove-attachment

新しい​メッセージ構造​により、添付ファイルは不要になりました。

remove-property

新しい​メッセージ構造​により、添付ファイルは不要になりました。

response

不要になりました。

request-reply

Mule 4 では、すべてのコネクタで request-reply がサポートされなくなります。「request-reply」動作があったコネクタには、JMS の ​publish-consume​ 操作など、「request-reply」操作が組み込まれます。

resin-transaction-manager

排除されました。

rollback-exception-strategy

on-error-propagate 戦略を使用する error-handler を使用します。

scatter-gather[​threading-profile​]

Mule 4 は非ブロックなので不要になりました。

seda-model

Mule 4 では SEDA キューがなくなりました。Mule 4 の実行エンジンは非ブロックです。

service

フローを使用します。

set-attachment

不要になりました。添付ファイルを変数として保存できます。

set-property

新しいメッセージモデルではプロパティが使用されなくなりました。Mule メッセージからの属性は変数に保存できます。

set-session-variable

セッション変数は削除されました。ユーザーはトランスポートの境界を越えて明示的にヘッダーを渡す必要があります。

simple-in-memory-queue-store

新しい VM Connector を使用します。

simple-service

フローを使用します。

simple-text-file-store

Object Store Module 拡張機能を使用してカスタムストアを作成します。

singleton-object

Java Module または Spring Module を使用します。

spring-object

Java Module または Spring Module を使用します。

synchronous-processing-strategy

フローコンポーネントの実行に関連する動作は、4.x のフローと同じですが、必ずしも 3.x と同じスレッドでは実行されません。

transactional scope

「try」スコープに置き換わりました。

username-password-filter

排除されました。

validator

排除されました。

weblogic-transaction-manager

<bti:transaction-manager/>​ を使用します。

websphere-transaction-manager

<bti:transaction-manager/>​ を使用します。

all-strategy

排除されました。

entry-point-resolver

Java Module​ を使用します。

filter

filter は ​Validation Module​ に置き換わります。

interceptor

interceptor はカスタムポリシーに置き換わります。

message-info-mapping

不要になりました。

point-resolver-set

Java Module​ を使用します。

router

排除されました。

threading-profile

不要になりました。Runtime で自動調整されます。

トランスフォーマー

排除されました。ほとんどの明示的な変換は不要になりました。コーナーケースには DataWeave を使用します。
# コネクタとモジュールの Mule 4 への移行 このセクションでは、コネクタに固有の機能の移行について説明し、Mule 4 で廃止または排除されたコネクタの一覧を示します。 ## [](#廃止または排除されたコネクタ)廃止または排除されたコネクタ 次表は、廃止/排除された Mule 3.x のモジュールと Mule 4.0 の代替方法を示しています。
Mule 3.x のモジュール Mule 4.0 の代替法

Ajax

APIkit + 標準 REST を使用します。

Atom

代わりに HTTP + DataWeave が導入されました。

Axis

Web サービスコンシューマー/APIkit for SOAP を使用します。

BPM

Pega/Appian for BPM への接続性が提供されました。

CXF

Web サービスコンシューマーを使用します。

Drools

排除されました。

EJB

排除されました。

Guice

排除されました。

jBPM

Pega/Appian for BPM への接続性が提供されました。

Jetty

新しい HTTP Module を使用します。

OGNL

代わりに DataWeave 式言語、Compatibility Module には MEL が導入されました。

パターン

排除されました。代わりにフローを使用します。

Quartz

新しい Scheduler コンポーネントを使用します。

RSS

HTTP + DataWeave を使用します。

Servlet

新しい組み込みモードを開発中です。

Stdio

排除されました。

SXC

DataWeave を使用します。

Tomcat

新しい組み込みモードを開発中です。

UDP

Sockets Connector を使用します。

XMPP

排除されました。
# コネクタとモジュールの Mule 4 への移行 このセクションでは、コネクタに固有の機能の移行について説明し、Mule 4 で廃止または排除されたコネクタの一覧を示します。 ## [](#廃止または排除されたコネクタ)廃止または排除されたコネクタ 次表は、廃止/排除された Mule 3.x のモジュールと Mule 4.0 の代替方法を示しています。
Mule 3.x のモジュール Mule 4.0 の代替法

Ajax

APIkit + 標準 REST を使用します。

Atom

代わりに HTTP + DataWeave が導入されました。

Axis

Web サービスコンシューマー/APIkit for SOAP を使用します。

BPM

Pega/Appian for BPM への接続性が提供されました。

CXF

Web サービスコンシューマーを使用します。

Drools

排除されました。

EJB

排除されました。

Guice

排除されました。

jBPM

Pega/Appian for BPM への接続性が提供されました。

Jetty

新しい HTTP Module を使用します。

OGNL

代わりに DataWeave 式言語、Compatibility Module には MEL が導入されました。

パターン

排除されました。代わりにフローを使用します。

Quartz

新しい Scheduler コンポーネントを使用します。

RSS

HTTP + DataWeave を使用します。

Servlet

新しい組み込みモードを開発中です。

Stdio

排除されました。

SXC

DataWeave を使用します。

Tomcat

新しい組み込みモードを開発中です。

UDP

Sockets Connector を使用します。

XMPP

排除されました。
# コネクタとモジュールの Mule 4 への移行 このセクションでは、コネクタに固有の機能の移行について説明し、Mule 4 で廃止または排除されたコネクタの一覧を示します。 ## [](#廃止または排除されたコネクタ)廃止または排除されたコネクタ 次表は、廃止/排除された Mule 3.x のモジュールと Mule 4.0 の代替方法を示しています。
Mule 3.x のモジュール Mule 4.0 の代替法

Ajax

APIkit + 標準 REST を使用します。

Atom

代わりに HTTP + DataWeave が導入されました。

Axis

Web サービスコンシューマー/APIkit for SOAP を使用します。

BPM

Pega/Appian for BPM への接続性が提供されました。

CXF

Web サービスコンシューマーを使用します。

Drools

排除されました。

EJB

排除されました。

Guice

排除されました。

jBPM

Pega/Appian for BPM への接続性が提供されました。

Jetty

新しい HTTP Module を使用します。

OGNL

代わりに DataWeave 式言語、Compatibility Module には MEL が導入されました。

パターン

排除されました。代わりにフローを使用します。

Quartz

新しい Scheduler コンポーネントを使用します。

RSS

HTTP + DataWeave を使用します。

Servlet

新しい組み込みモードを開発中です。

Stdio

排除されました。

SXC

DataWeave を使用します。

Tomcat

新しい組み込みモードを開発中です。

UDP

Sockets Connector を使用します。

XMPP

排除されました。
# コネクタとモジュールの Mule 4 への移行 このセクションでは、コネクタに固有の機能の移行について説明し、Mule 4 で廃止または排除されたコネクタの一覧を示します。 ## [](#廃止または排除されたコネクタ)廃止または排除されたコネクタ 次表は、廃止/排除された Mule 3.x のモジュールと Mule 4.0 の代替方法を示しています。
Mule 3.x のモジュール Mule 4.0 の代替法

Ajax

APIkit + 標準 REST を使用します。

Atom

代わりに HTTP + DataWeave が導入されました。

Axis

Web サービスコンシューマー/APIkit for SOAP を使用します。

BPM

Pega/Appian for BPM への接続性が提供されました。

CXF

Web サービスコンシューマーを使用します。

Drools

排除されました。

EJB

排除されました。

Guice

排除されました。

jBPM

Pega/Appian for BPM への接続性が提供されました。

Jetty

新しい HTTP Module を使用します。

OGNL

代わりに DataWeave 式言語、Compatibility Module には MEL が導入されました。

パターン

排除されました。代わりにフローを使用します。

Quartz

新しい Scheduler コンポーネントを使用します。

RSS

HTTP + DataWeave を使用します。

Servlet

新しい組み込みモードを開発中です。

Stdio

排除されました。

SXC

DataWeave を使用します。

Tomcat

新しい組み込みモードを開発中です。

UDP

Sockets Connector を使用します。

XMPP

排除されました。
# コネクタとモジュールの Mule 4 への移行 このセクションでは、コネクタに固有の機能の移行について説明し、Mule 4 で廃止または排除されたコネクタの一覧を示します。 ## [](#廃止または排除されたコネクタ)廃止または排除されたコネクタ 次表は、廃止/排除された Mule 3.x のモジュールと Mule 4.0 の代替方法を示しています。
Mule 3.x のモジュール Mule 4.0 の代替法

Ajax

APIkit + 標準 REST を使用します。

Atom

代わりに HTTP + DataWeave が導入されました。

Axis

Web サービスコンシューマー/APIkit for SOAP を使用します。

BPM

Pega/Appian for BPM への接続性が提供されました。

CXF

Web サービスコンシューマーを使用します。

Drools

排除されました。

EJB

排除されました。

Guice

排除されました。

jBPM

Pega/Appian for BPM への接続性が提供されました。

Jetty

新しい HTTP Module を使用します。

OGNL

代わりに DataWeave 式言語、Compatibility Module には MEL が導入されました。

パターン

排除されました。代わりにフローを使用します。

Quartz

新しい Scheduler コンポーネントを使用します。

RSS

HTTP + DataWeave を使用します。

Servlet

新しい組み込みモードを開発中です。

Stdio

排除されました。

SXC

DataWeave を使用します。

Tomcat

新しい組み込みモードを開発中です。

UDP

Sockets Connector を使用します。

XMPP

排除されました。
# コネクタとモジュールの Mule 4 への移行 このセクションでは、コネクタに固有の機能の移行について説明し、Mule 4 で廃止または排除されたコネクタの一覧を示します。 ## [](#廃止または排除されたコネクタ)廃止または排除されたコネクタ 次表は、廃止/排除された Mule 3.x のモジュールと Mule 4.0 の代替方法を示しています。
Mule 3.x のモジュール Mule 4.0 の代替法

Ajax

APIkit + 標準 REST を使用します。

Atom

代わりに HTTP + DataWeave が導入されました。

Axis

Web サービスコンシューマー/APIkit for SOAP を使用します。

BPM

Pega/Appian for BPM への接続性が提供されました。

CXF

Web サービスコンシューマーを使用します。

Drools

排除されました。

EJB

排除されました。

Guice

排除されました。

jBPM

Pega/Appian for BPM への接続性が提供されました。

Jetty

新しい HTTP Module を使用します。

OGNL

代わりに DataWeave 式言語、Compatibility Module には MEL が導入されました。

パターン

排除されました。代わりにフローを使用します。

Quartz

新しい Scheduler コンポーネントを使用します。

RSS

HTTP + DataWeave を使用します。

Servlet

新しい組み込みモードを開発中です。

Stdio

排除されました。

SXC

DataWeave を使用します。

Tomcat

新しい組み込みモードを開発中です。

UDP

Sockets Connector を使用します。

XMPP

排除されました。
# コネクタとモジュールの Mule 4 への移行 このセクションでは、コネクタに固有の機能の移行について説明し、Mule 4 で廃止または排除されたコネクタの一覧を示します。 ## [](#廃止または排除されたコネクタ)廃止または排除されたコネクタ 次表は、廃止/排除された Mule 3.x のモジュールと Mule 4.0 の代替方法を示しています。
Mule 3.x のモジュール Mule 4.0 の代替法

Ajax

APIkit + 標準 REST を使用します。

Atom

代わりに HTTP + DataWeave が導入されました。

Axis

Web サービスコンシューマー/APIkit for SOAP を使用します。

BPM

Pega/Appian for BPM への接続性が提供されました。

CXF

Web サービスコンシューマーを使用します。

Drools

排除されました。

EJB

排除されました。

Guice

排除されました。

jBPM

Pega/Appian for BPM への接続性が提供されました。

Jetty

新しい HTTP Module を使用します。

OGNL

代わりに DataWeave 式言語、Compatibility Module には MEL が導入されました。

パターン

排除されました。代わりにフローを使用します。

Quartz

新しい Scheduler コンポーネントを使用します。

RSS

HTTP + DataWeave を使用します。

Servlet

新しい組み込みモードを開発中です。

Stdio

排除されました。

SXC

DataWeave を使用します。

Tomcat

新しい組み込みモードを開発中です。

UDP

Sockets Connector を使用します。

XMPP

排除されました。
# システムプロパティ システムプロパティを使用して、Mule アプリケーションのコネクタまたはコンポーネントが使用するプロパティプレースホルダー値を指定または上書きできます。MuleSoft では、アプリケーションを新しい環境にデプロイして Mule アプリケーション用の設定プロパティファイルの値を上書きする必要がある場合には、この方法をお勧めします。 システムプロパティは以下の方法で管理できます。 - Anypoint Studio のプロジェクトの \[Run Configurations (設定を実行)\] ウィンドウから。 - スタンドアロン Mule インスタンスのコマンドラインから。 ## [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Studio の Package Explorer からプロジェクトを起動するときにプロパティを追加できます。 1. Package Explorer で Mule アプリケーション用のプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. 引数を ​**\[VM Arguments (VM 引数)\]**​ 項目に追加し、プロパティ名の先頭に ​`-D`​ を追加します。 ![Arguments+Tab](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/arguments-tab.png) Studio からアプリケーションをデプロイする場合、プロパティプレースホルダーの新しい値がそのプレースホルダーについて設定された他の値よりも優先されます。 ```xml ``` ## [](#set-properties)オンプレミスデプロイメント用にシステムプロパティを設定する オンプレミス Mule インスタンス用に、コマンドラインからシステムプロパティを設定および変更することも、​`wrapper.conf`​ ファイルで定義することもできます。 ### [](#mule-を開始するときにシステムプロパティを設定する)Mule を開始するときにシステムプロパティを設定する `-M-Dmule.=`​ を ​`mule`​ または ​`mule start`​ コマンドに追加してシステムプロパティを設定します。 ``​ を目的のプロパティ名に置き換えます。 ``​ をプロパティに定義する値に置き換えます。 次の例では、Mule を開始して異なる値で 2 つのプロパティを定義します。 $ mule start -M-Dmule.myEnv=prod -M-Dmule.myValue=1234 ### [](#wrapper-conf-ファイルでシステムプロパティを設定する)wrapper.conf ファイルでシステムプロパティを設定する `wrapper.java.additional.`​ エントリを ​`${MULE_HOME}/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルに追加して、プロパティ名の先頭に ​`-D`​ を追加します。 たとえば、Mule エンコードを設定するには、次の行をラッパー設定ファイルに追加します。 ```none wrapper.java.additional.999=-Dmule.encoding=ISO-8859-1 ``` #### [](#システムプロパティの追加に関する考慮事項)システムプロパティの追加に関する考慮事項 - 新しいプロパティのエントリ番号が使用中でないことを確認します。 設定ファイルに ​`wrapper.java.additional.`​ エントリを追加する場合、必ず ​``​ の各インスタンスを未使用の新しい番号に変更してください。それ以外の番号にすると、Java はプロパティを正しく解析しません。 - インクルードファイル内のプロパティのシーケンス以外の値を使用します。 インクルードファイルに ​`wrapper.java.additional.`​ エントリを追加する場合は、高い ​``​ 値を設定して、プロパティの数値が標準シーケンス以外になるようにします。また、​`wrapper.ignore_sequence_gaps`​ プロパティが ​`true`​ に設定されていることを確認します。次に例を示します。 ```none wrapper.java.additional.1900=-Dprop=value1 wrapper.java.additional.1901=-DotherProp=value2 wrapper.ignore_sequence_gaps=TRUE ``` ## [](#関連情報)関連情報 - [Mule 設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties) # システムプロパティ システムプロパティを使用して、Mule アプリケーションのコネクタまたはコンポーネントが使用するプロパティプレースホルダー値を指定または上書きできます。MuleSoft では、アプリケーションを新しい環境にデプロイして Mule アプリケーション用の設定プロパティファイルの値を上書きする必要がある場合には、この方法をお勧めします。 システムプロパティは以下の方法で管理できます。 - Anypoint Studio のプロジェクトの \[Run Configurations (設定を実行)\] ウィンドウから。 - スタンドアロン Mule インスタンスのコマンドラインから。 ## [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Studio の Package Explorer からプロジェクトを起動するときにプロパティを追加できます。 1. Package Explorer で Mule アプリケーション用のプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. 引数を ​**\[VM Arguments (VM 引数)\]**​ 項目に追加し、プロパティ名の先頭に ​`-D`​ を追加します。 ![Arguments+Tab](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/arguments-tab.png) Studio からアプリケーションをデプロイする場合、プロパティプレースホルダーの新しい値がそのプレースホルダーについて設定された他の値よりも優先されます。 ```xml ``` ## [](#set-properties)オンプレミスデプロイメント用にシステムプロパティを設定する オンプレミス Mule インスタンス用に、コマンドラインからシステムプロパティを設定および変更することも、​`wrapper.conf`​ ファイルで定義することもできます。 ### [](#mule-を開始するときにシステムプロパティを設定する)Mule を開始するときにシステムプロパティを設定する `-M-Dmule.=`​ を ​`mule`​ または ​`mule start`​ コマンドに追加してシステムプロパティを設定します。 ``​ を目的のプロパティ名に置き換えます。 ``​ をプロパティに定義する値に置き換えます。 次の例では、Mule を開始して異なる値で 2 つのプロパティを定義します。 $ mule start -M-Dmule.myEnv=prod -M-Dmule.myValue=1234 ### [](#wrapper-conf-ファイルでシステムプロパティを設定する)wrapper.conf ファイルでシステムプロパティを設定する `wrapper.java.additional.`​ エントリを ​`${MULE_HOME}/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルに追加して、プロパティ名の先頭に ​`-D`​ を追加します。 たとえば、Mule エンコードを設定するには、次の行をラッパー設定ファイルに追加します。 ```none wrapper.java.additional.999=-Dmule.encoding=ISO-8859-1 ``` #### [](#システムプロパティの追加に関する考慮事項)システムプロパティの追加に関する考慮事項 - 新しいプロパティのエントリ番号が使用中でないことを確認します。 設定ファイルに ​`wrapper.java.additional.`​ エントリを追加する場合、必ず ​``​ の各インスタンスを未使用の新しい番号に変更してください。それ以外の番号にすると、Java はプロパティを正しく解析しません。 - インクルードファイル内のプロパティのシーケンス以外の値を使用します。 インクルードファイルに ​`wrapper.java.additional.`​ エントリを追加する場合は、高い ​``​ 値を設定して、プロパティの数値が標準シーケンス以外になるようにします。また、​`wrapper.ignore_sequence_gaps`​ プロパティが ​`true`​ に設定されていることを確認します。次に例を示します。 ```none wrapper.java.additional.1900=-Dprop=value1 wrapper.java.additional.1901=-DotherProp=value2 wrapper.ignore_sequence_gaps=TRUE ``` ## [](#関連情報)関連情報 - [Mule 設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties) # システムプロパティ システムプロパティを使用して、Mule アプリケーションのコネクタまたはコンポーネントが使用するプロパティプレースホルダー値を指定または上書きできます。MuleSoft では、アプリケーションを新しい環境にデプロイして Mule アプリケーション用の設定プロパティファイルの値を上書きする必要がある場合には、この方法をお勧めします。 システムプロパティは以下の方法で管理できます。 - Anypoint Studio のプロジェクトの \[Run Configurations (設定を実行)\] ウィンドウから。 - スタンドアロン Mule インスタンスのコマンドラインから。 ## [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Studio の Package Explorer からプロジェクトを起動するときにプロパティを追加できます。 1. Package Explorer で Mule アプリケーション用のプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. 引数を ​**\[VM Arguments (VM 引数)\]**​ 項目に追加し、プロパティ名の先頭に ​`-D`​ を追加します。 ![Arguments+Tab](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/arguments-tab.png) Studio からアプリケーションをデプロイする場合、プロパティプレースホルダーの新しい値がそのプレースホルダーについて設定された他の値よりも優先されます。 ```xml ``` ## [](#set-properties)オンプレミスデプロイメント用にシステムプロパティを設定する オンプレミス Mule インスタンス用に、コマンドラインからシステムプロパティを設定および変更することも、​`wrapper.conf`​ ファイルで定義することもできます。 ### [](#mule-を開始するときにシステムプロパティを設定する)Mule を開始するときにシステムプロパティを設定する `-M-Dmule.=`​ を ​`mule`​ または ​`mule start`​ コマンドに追加してシステムプロパティを設定します。 ``​ を目的のプロパティ名に置き換えます。 ``​ をプロパティに定義する値に置き換えます。 次の例では、Mule を開始して異なる値で 2 つのプロパティを定義します。 $ mule start -M-Dmule.myEnv=prod -M-Dmule.myValue=1234 ### [](#wrapper-conf-ファイルでシステムプロパティを設定する)wrapper.conf ファイルでシステムプロパティを設定する `wrapper.java.additional.`​ エントリを ​`${MULE_HOME}/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルに追加して、プロパティ名の先頭に ​`-D`​ を追加します。 たとえば、Mule エンコードを設定するには、次の行をラッパー設定ファイルに追加します。 ```none wrapper.java.additional.999=-Dmule.encoding=ISO-8859-1 ``` #### [](#システムプロパティの追加に関する考慮事項)システムプロパティの追加に関する考慮事項 - 新しいプロパティのエントリ番号が使用中でないことを確認します。 設定ファイルに ​`wrapper.java.additional.`​ エントリを追加する場合、必ず ​``​ の各インスタンスを未使用の新しい番号に変更してください。それ以外の番号にすると、Java はプロパティを正しく解析しません。 - インクルードファイル内のプロパティのシーケンス以外の値を使用します。 インクルードファイルに ​`wrapper.java.additional.`​ エントリを追加する場合は、高い ​``​ 値を設定して、プロパティの数値が標準シーケンス以外になるようにします。また、​`wrapper.ignore_sequence_gaps`​ プロパティが ​`true`​ に設定されていることを確認します。次に例を示します。 ```none wrapper.java.additional.1900=-Dprop=value1 wrapper.java.additional.1901=-DotherProp=value2 wrapper.ignore_sequence_gaps=TRUE ``` ## [](#関連情報)関連情報 - [Mule 設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties) # システムプロパティ システムプロパティを使用して、Mule アプリケーションのコネクタまたはコンポーネントが使用するプロパティプレースホルダー値を指定または上書きできます。MuleSoft では、アプリケーションを新しい環境にデプロイして Mule アプリケーション用の設定プロパティファイルの値を上書きする必要がある場合には、この方法をお勧めします。 システムプロパティは以下の方法で管理できます。 - Anypoint Studio のプロジェクトの \[Run Configurations (設定を実行)\] ウィンドウから。 - スタンドアロン Mule インスタンスのコマンドラインから。 ## [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Studio の Package Explorer からプロジェクトを起動するときにプロパティを追加できます。 1. Package Explorer で Mule アプリケーション用のプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. 引数を ​**\[VM Arguments (VM 引数)\]**​ 項目に追加し、プロパティ名の先頭に ​`-D`​ を追加します。 ![Arguments+Tab](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/arguments-tab.png) Studio からアプリケーションをデプロイする場合、プロパティプレースホルダーの新しい値がそのプレースホルダーについて設定された他の値よりも優先されます。 ```xml ``` ## [](#set-properties)オンプレミスデプロイメント用にシステムプロパティを設定する オンプレミス Mule インスタンス用に、コマンドラインからシステムプロパティを設定および変更することも、​`wrapper.conf`​ ファイルで定義することもできます。 ### [](#mule-を開始するときにシステムプロパティを設定する)Mule を開始するときにシステムプロパティを設定する `-M-Dmule.=`​ を ​`mule`​ または ​`mule start`​ コマンドに追加してシステムプロパティを設定します。 ``​ を目的のプロパティ名に置き換えます。 ``​ をプロパティに定義する値に置き換えます。 次の例では、Mule を開始して異なる値で 2 つのプロパティを定義します。 $ mule start -M-Dmule.myEnv=prod -M-Dmule.myValue=1234 ### [](#wrapper-conf-ファイルでシステムプロパティを設定する)wrapper.conf ファイルでシステムプロパティを設定する `wrapper.java.additional.`​ エントリを ​`${MULE_HOME}/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルに追加して、プロパティ名の先頭に ​`-D`​ を追加します。 たとえば、Mule エンコードを設定するには、次の行をラッパー設定ファイルに追加します。 ```none wrapper.java.additional.999=-Dmule.encoding=ISO-8859-1 ``` #### [](#システムプロパティの追加に関する考慮事項)システムプロパティの追加に関する考慮事項 - 新しいプロパティのエントリ番号が使用中でないことを確認します。 設定ファイルに ​`wrapper.java.additional.`​ エントリを追加する場合、必ず ​``​ の各インスタンスを未使用の新しい番号に変更してください。それ以外の番号にすると、Java はプロパティを正しく解析しません。 - インクルードファイル内のプロパティのシーケンス以外の値を使用します。 インクルードファイルに ​`wrapper.java.additional.`​ エントリを追加する場合は、高い ​``​ 値を設定して、プロパティの数値が標準シーケンス以外になるようにします。また、​`wrapper.ignore_sequence_gaps`​ プロパティが ​`true`​ に設定されていることを確認します。次に例を示します。 ```none wrapper.java.additional.1900=-Dprop=value1 wrapper.java.additional.1901=-DotherProp=value2 wrapper.ignore_sequence_gaps=TRUE ``` ## [](#関連情報)関連情報 - [Mule 設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties) # システムプロパティ システムプロパティを使用して、Mule アプリケーションのコネクタまたはコンポーネントが使用するプロパティプレースホルダー値を指定または上書きできます。MuleSoft では、アプリケーションを新しい環境にデプロイして Mule アプリケーション用の設定プロパティファイルの値を上書きする必要がある場合には、この方法をお勧めします。 システムプロパティは以下の方法で管理できます。 - Anypoint Studio のプロジェクトの \[Run Configurations (設定を実行)\] ウィンドウから。 - スタンドアロン Mule インスタンスのコマンドラインから。 ## [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Studio の Package Explorer からプロジェクトを起動するときにプロパティを追加できます。 1. Package Explorer で Mule アプリケーション用のプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. 引数を ​**\[VM Arguments (VM 引数)\]**​ 項目に追加し、プロパティ名の先頭に ​`-D`​ を追加します。 ![Anypoint Studio の JVM 引数の設定が表示されている \[Arguments (引数)\] タブ](_images/arguments-tab.png) Studio からアプリケーションをデプロイする場合、プロパティプレースホルダーの新しい値がそのプレースホルダーについて設定された他の値よりも優先されます。 ```xml ``` ## [](#set-properties)オンプレミスデプロイメント用にシステムプロパティを設定する オンプレミス Mule インスタンス用に、コマンドラインからシステムプロパティを設定および変更することも、​`wrapper.conf`​ ファイルで定義することもできます。 ### [](#mule-を開始するときにシステムプロパティを設定する)Mule を開始するときにシステムプロパティを設定する `-M-Dmule.=`​ を ​`mule`​ または ​`mule start`​ コマンドに追加してシステムプロパティを設定します。 ``​ を目的のプロパティ名に置き換えます。 ``​ をプロパティに定義する値に置き換えます。 次の例では、Mule を開始して異なる値で 2 つのプロパティを定義します。 $ mule start -M-Dmule.myEnv=prod -M-Dmule.myValue=1234 ### [](#wrapper-conf-ファイルでシステムプロパティを設定する)wrapper.conf ファイルでシステムプロパティを設定する `wrapper.java.additional.`​ エントリを ​`${MULE_HOME}/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルに追加して、プロパティ名の先頭に ​`-D`​ を追加します。 たとえば、Mule エンコードを設定するには、次の行をラッパー設定ファイルに追加します。 ```none wrapper.java.additional.999=-Dmule.encoding=ISO-8859-1 ``` #### [](#システムプロパティの追加に関する考慮事項)システムプロパティの追加に関する考慮事項 - 新しいプロパティのエントリ番号が使用中でないことを確認します。 設定ファイルに ​`wrapper.java.additional.`​ エントリを追加する場合、必ず ​``​ の各インスタンスを未使用の新しい番号に変更してください。それ以外の番号にすると、Java はプロパティを正しく解析しません。 - インクルードファイル内のプロパティのシーケンス以外の値を使用します。 インクルードファイルに ​`wrapper.java.additional.`​ エントリを追加する場合は、高い ​``​ 値を設定して、プロパティの数値が標準シーケンス以外になるようにします。また、​`wrapper.ignore_sequence_gaps`​ プロパティが ​`true`​ に設定されていることを確認します。次に例を示します。 ```none wrapper.java.additional.1900=-Dprop=value1 wrapper.java.additional.1901=-DotherProp=value2 wrapper.ignore_sequence_gaps=TRUE ``` ## [](#関連情報)関連情報 - [Mule 設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties) # システムプロパティ システムプロパティを使用して、Mule アプリケーションのコネクタまたはコンポーネントが使用するプロパティプレースホルダー値を指定または上書きできます。MuleSoft では、アプリケーションを新しい環境にデプロイして Mule アプリケーション用の設定プロパティファイルの値を上書きする必要がある場合には、この方法をお勧めします。 システムプロパティは以下の方法で管理できます。 - Anypoint Studio のプロジェクトの \[Run Configurations (設定を実行)\] ウィンドウから。 - スタンドアロン Mule インスタンスのコマンドラインから。 ## [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Studio の Package Explorer からプロジェクトを起動するときにプロパティを追加できます。 1. Package Explorer で Mule アプリケーション用のプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. 引数を ​**\[VM Arguments (VM 引数)\]**​ 項目に追加し、プロパティ名の先頭に ​`-D`​ を追加します。 ![Anypoint Studio の JVM 引数の設定が表示されている \[Arguments (引数)\] タブ](_images/arguments-tab.png) Studio からアプリケーションをデプロイする場合、プロパティプレースホルダーの新しい値がそのプレースホルダーについて設定された他の値よりも優先されます。 ```xml ``` ## [](#set-properties)オンプレミスデプロイメント用にシステムプロパティを設定する オンプレミス Mule インスタンス用に、コマンドラインからシステムプロパティを設定および変更することも、​`wrapper.conf`​ ファイルで定義することもできます。 ### [](#mule-を開始するときにシステムプロパティを設定する)Mule を開始するときにシステムプロパティを設定する `-M-Dmule.=`​ を ​`mule`​ または ​`mule start`​ コマンドに追加してシステムプロパティを設定します。 ``​ を目的のプロパティ名に置き換えます。 ``​ をプロパティに定義する値に置き換えます。 次の例では、Mule を開始して異なる値で 2 つのプロパティを定義します。 $ mule start -M-Dmule.myEnv=prod -M-Dmule.myValue=1234 ### [](#wrapper-conf-ファイルでシステムプロパティを設定する)wrapper.conf ファイルでシステムプロパティを設定する `wrapper.java.additional.`​ エントリを ​`${MULE_HOME}/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルに追加して、プロパティ名の先頭に ​`-D`​ を追加します。 たとえば、Mule エンコードを設定するには、次の行をラッパー設定ファイルに追加します。 ```none wrapper.java.additional.999=-Dmule.encoding=ISO-8859-1 ``` #### [](#システムプロパティの追加に関する考慮事項)システムプロパティの追加に関する考慮事項 - 新しいプロパティのエントリ番号が使用中でないことを確認します。 設定ファイルに ​`wrapper.java.additional.`​ エントリを追加する場合、必ず ​``​ の各インスタンスを未使用の新しい番号に変更してください。それ以外の番号にすると、Java はプロパティを正しく解析しません。 - インクルードファイル内のプロパティのシーケンス以外の値を使用します。 インクルードファイルに ​`wrapper.java.additional.`​ エントリを追加する場合は、高い ​``​ 値を設定して、プロパティの数値が標準シーケンス以外になるようにします。また、​`wrapper.ignore_sequence_gaps`​ プロパティが ​`true`​ に設定されていることを確認します。次に例を示します。 ```none wrapper.java.additional.1900=-Dprop=value1 wrapper.java.additional.1901=-DotherProp=value2 wrapper.ignore_sequence_gaps=TRUE ``` ## [](#関連情報)関連情報 - [Mule 設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties) # システムプロパティ システムプロパティを使用して、Mule アプリケーションのコネクタまたはコンポーネントが使用するプロパティプレースホルダー値を指定または上書きできます。MuleSoft では、アプリケーションを新しい環境にデプロイして Mule アプリケーション用の設定プロパティファイルの値を上書きする必要がある場合には、この方法をお勧めします。 システムプロパティは以下の方法で管理できます。 - Anypoint Studio のプロジェクトの \[Run Configurations (設定を実行)\] ウィンドウから。 - スタンドアロン Mule インスタンスのコマンドラインから。 ## [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Studio の Package Explorer からプロジェクトを起動するときにプロパティを追加できます。 1. Package Explorer で Mule アプリケーション用のプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. 引数を ​**\[VM Arguments (VM 引数)\]**​ 項目に追加し、プロパティ名の先頭に ​`-D`​ を追加します。 ![Anypoint Studio の JVM 引数の設定が表示されている \[Arguments (引数)\] タブ](_images/arguments-tab.png) Studio からアプリケーションをデプロイする場合、プロパティプレースホルダーの新しい値がそのプレースホルダーについて設定された他の値よりも優先されます。 ```xml ``` ## [](#set-properties)オンプレミスデプロイメント用にシステムプロパティを設定する オンプレミス Mule インスタンス用に、コマンドラインからシステムプロパティを設定および変更することも、​`wrapper.conf`​ ファイルで定義することもできます。 ### [](#mule-を開始するときにシステムプロパティを設定する)Mule を開始するときにシステムプロパティを設定する `-M-Dmule.=`​ を ​`mule`​ または ​`mule start`​ コマンドに追加してシステムプロパティを設定します。 ``​ を目的のプロパティ名に置き換えます。 ``​ をプロパティに定義する値に置き換えます。 次の例では、Mule を開始して異なる値で 2 つのプロパティを定義します。 $ mule start -M-Dmule.myEnv=prod -M-Dmule.myValue=1234 ### [](#wrapper-conf-ファイルでシステムプロパティを設定する)wrapper.conf ファイルでシステムプロパティを設定する `wrapper.java.additional.`​ エントリを ​`${MULE_HOME}/conf`​ ディレクトリの ​`wrapper.conf`​ ファイルに追加して、プロパティ名の先頭に ​`-D`​ を追加します。 たとえば、Mule エンコードを設定するには、次の行をラッパー設定ファイルに追加します。 ```none wrapper.java.additional.999=-Dmule.encoding=ISO-8859-1 ``` #### [](#システムプロパティの追加に関する考慮事項)システムプロパティの追加に関する考慮事項 - 新しいプロパティのエントリ番号が使用中でないことを確認します。 設定ファイルに ​`wrapper.java.additional.`​ エントリを追加する場合、必ず ​``​ の各インスタンスを未使用の新しい番号に変更してください。それ以外の番号にすると、Java はプロパティを正しく解析しません。 - インクルードファイル内のプロパティのシーケンス以外の値を使用します。 インクルードファイルに ​`wrapper.java.additional.`​ エントリを追加する場合は、高い ​``​ 値を設定して、プロパティの数値が標準シーケンス以外になるようにします。また、​`wrapper.ignore_sequence_gaps`​ プロパティが ​`true`​ に設定されていることを確認します。次に例を示します。 ```none wrapper.java.additional.1900=-Dprop=value1 wrapper.java.additional.1901=-DotherProp=value2 wrapper.ignore_sequence_gaps=TRUE ``` ## [](#関連情報)関連情報 - [Mule 設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties) # スケジューラーエンドポイント (トリガー) Scheduler コンポーネントは、時間ベースの条件が成立した時点でフローをトリガーします。Scheduler は、一定間隔でトリガーするように設定したり、より柔軟な Cron 式を使用して設定したりすることができます。たとえば、フローを開始するイベントを 5 秒おきにトリガーするように Scheduler を設定できます。 Mule アプリケーションに Scheduler を実装するときは次の点を考慮してください。 - Scheduler は、Mule が動作しているマシンと同じタイムゾーンを使用します。ただし、アプリケーションが CloudHub で動作している場合は、アプリケーションが動作している地理的リージョンに関係なく、Scheduler は UTC タイムゾーンに準拠します。 - `disallowConcurrentExecution`​ プロパティを使用すると、フローの処理が終了するまで Scheduler でそのフローを再トリガーできないようにすることができます。​[「 プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/scheduler-xml-reference#scheduler-properties)​を参照してください。 - スケジュールされたトリガー時に利用できるリソースが 1 つもないために ​[back-pressure](https://docs.mulesoft.com/jp/mule-runtime/4.3/execution-engine#backpressure)​ が発生した場合、そのトリガーはスキップされます。 - Mule Runtime Engine クラスターやマルチワーカー CloudHub デプロイメントでは、Scheduler はプライマリノードのみで (つまり 1 つの Mule インスタンスのみで) 実行 (フローがトリガー) されます。 ## [](#サンプルプロジェクト)サンプルプロジェクト Anypoint Exchange には、Anypoint Studio で開いて Scheduler コンポーネントの詳細を見るためのサンプルプロジェクトがいくつかあります。 - _Data Sync Using Watermarking and Batch (ウォーターマークとバッチを使用したデータの同期)_ - _Import Contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Import Leads into Salesforce (Salesforce へのリードのインポート)_ - _Importing a CSV File into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment Using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Salesforce to MySQL Database Using Batch Processing (バッチ処理を使用した Salesforce から MySQL データベースへのインポート)_ - _Sending a CSV File Through Email Using SMTP (SMTP を使用したメールでの CSV ファイルの送信)_ Anypoint Studio でサンプルプロジェクトをダウンロードして開くには、左上隅にある Exchange アイコンをクリックします。次に、開いたウィンドウで、Anypoint Exchange にログインし、プロジェクトの名前を検索します。 ## [](#一定間隔)一定間隔 次のパラメーターを使用して、Scheduler がフローを一定間隔でトリガーするように設定できます。
属性 説明 デフォルト

Frequency (頻度)

Scheduler がフローをトリガーする頻度。単位は ​Time unit (時間単位)​ 項目で選択できます。値を ​0​ または負の値を指定すると、デフォルト値が使用されます。

1000

Start Delay (開始遅延)

アプリケーションが起動してからフローを最初にトリガーするまで待つ時間。値は、頻度と同じ時間単位で表されます。

0

Time Unit (時間単位)

Frequency (頻度)​ と ​Start Delay (開始遅延)​ の値の時間単位。可能な値:

MILLISECONDS (ミリ秒)、SECONDS (秒)、MINUTES (分)、HOURS (時)、DAYS (日)

MILLISECONDS
## [](#cron-式)Cron 式 Cron は、日時情報を記述するのに広く利用されている標準です。 Scheduler は、毎秒を監視し、Quartz Cron 式が日時の設定と一致すると Mule イベントを作成します。イベントは 1 回だけ、または一定間隔でトリガーできます。 日時の式は、6 つの必須設定と、年の設定 (省略可能) で構成されます。設定は以下の順序で指定します。 1. 秒 (0-59) 2. 分 (0-59) 3. 時 (0-23) 4. 日 (1-31) 5. 月 (1-12 または JAN-DEC) 6. 曜日 (1-7 または SUN-SAT) 7. 年 (空白、または 1970-2099 の範囲内の 4 桁。例: 2019) Scheduler は Quartz Cron 式をサポートします。例をいくつか示します。
式 動作

1/2 * * * * ?

毎日 2 秒おきに実行。

0 15 10 ? * *

毎日午前 10 時 15 分に実行。 0 15 10 * * ? ​` と ​0 15 10 *​`0 15 10 * * ?​ は同じ結果になります。

0 15 10 * * ? 2019

2019 年の毎日午前 10 時 15 分に実行。

0 * 14 * * ?

毎日午後 2 時から 2 時 59 分まで、毎分実行。

0 0/5 14 * * ?

毎日午後 2 時から 2 時 55 分まで、5 分おきに実行。

1 1 1 1,7 * ?

毎月 1 日と 7 日の午前 1 時 1 分 1 秒に実行。
Scheduler コンポーネントは、Quartz Scheduler の特殊も時もサポートします。 - `*`​: すべての値。 - `?`​: 任意の 1 つの値。 - `-`​: 値の範囲。例: `1-3`​。 - `,`​: 追加の値。例: `1,7`​。 - `/`​: 増分値。例: `1/7`​。 - `L`​: 週または月の最終日、または月の最後の特定の曜日 (例: `6L`​ は月の最後の土曜日)。 - `W`​: 平日。日付項目で有効で、特定の日付以降になります。例: `15W`​ はその月の 15 日に最も近い平日を表します。 - `#`​: 月の n 日目。例: `#3`​ は月の 3 日。 詳細は、 [「CronExpression」](https://www.quartz-scheduler.org/api/2.3.0/org/quartz/CronExpression.html)​を参照してください。 次の例は、「hello」というメッセージを毎秒ログに記録します。 ```XML ``` Cron 式をビルドするための無料のオンラインツールがたくさんあります。 ### [](#タイムゾーン-timezone)タイムゾーン (timeZone) Cron 式では Java の ​`timeZone`​ 値がサポートされます。Java の短縮表記 (​`PST`​ や ​`AGT`​) は使用せず、Java の完全表記 (​`America/Los_Angeles`​ や ​`America/Argentina/Buenos_Aires`​) を使用してください。 ## [](#デバッグ)デバッグ Studio の ​**\[Debug Mode (デバッグモード)\]**​ ビューでは、Mule アプリケーションはイベントをトリガーできません。その代わりに、デバッグ時には Scheduler コンポーネントの下に表示される緑色の矢印アイコンをクリックすることで Scheduler を実行できます。 ## [](#関連情報)関連情報 - [Scheduler XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/scheduler-xml-reference) # スケジューラーエンドポイント (トリガー) Scheduler コンポーネントは、時間ベースの条件に基づいてフローの実行をトリガーする Mule イベントソースです。たとえば Scheduler によって、5 秒ごと、または指定したタイムゾーンで毎日 12 時 00 分にフロー処理をトリガーするメッセージを作成して送信される場合があります。 Mule アプリケーションに Scheduler を追加するときは次の点を考慮してください。 - Scheduler は、Mule が動作しているマシンと同じタイムゾーンを使用します。ただし、アプリケーションが CloudHub で動作している場合は、アプリケーションが動作している地理的リージョンに関係なく、Scheduler は UTC タイムゾーンに準拠します。 Scheduler 用に別のタイムゾーンを設定する場合は、​[Cron (​``​)](#props_cron_expressions)​の​`「timeZone」`​を参照してください。 - `disallowConcurrentExecution`​ プロパティを使用すると、以前にトリガーされた実行の処理中に Scheduler でフローの実行がトリガーできないようにできます。 - スケジュールされたトリガー時に利用できるリソースが 1 つもないために ​[back-pressure](https://docs.mulesoft.com/jp/mule-runtime/4.4/execution-engine#backpressure)​ が発生した場合、その実行はスキップされます。 - Mule Runtime Engine クラスターやマルチワーカー CloudHub デプロイメントでは、Scheduler はプライマリノードのみで (つまり 1 つの Mule インスタンスのみで) 実行されます。 ## [](#アーキテクチャ)アーキテクチャ 他の Mule イベントソースコンポーネントと同様、Scheduler は Mule フローの最初のコンポーネントです。 ![Mule フローの Scheduler コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/scheduler-component-ex.png) Scheduler の XML は以下の要素で構成されます。 - ``​: Scheduler の最上位レベルの要素。 - ``​: 次のいずれかの子を受け入れる第 2 レベル要素。 - ``​: 毎秒などの一般的なスケジュール頻度向け。 - ``​: [Cron 式](#cron_expressions)​およびタイムゾーン設定向け。 Scheduler により、固定の頻度、または Cron 式に基づいた間隔でスケジュール戦略が設定されます。次に例を示します。 - 次の Scheduler の固定の頻度設定では、15 秒ごとに実行されます。 ```xml ``` - Scheduler の Cron 式によって 15 秒ごとにフローが新たに実行され、Mule メッセージの生成がトリガーされます。 ```xml ``` 1 つ以上のプロセッサーが Scheduler に従う必要があります。プロセッサーには、HTTP Request 操作や Transform Message コンポーネントなど、Mule コンポーネントやコネクタ操作が含まれます。プロセッサーを提供しない場合、​`MuleRuntimeException`​ が発生し、Mule アプリケーションのデプロイメントが失敗して、次の ERROR メッセージがログに記録されます (読みやすいように編集済み)。 ```logs ERROR ...MuleRuntimeException ... The content of element 'flow' is not complete. One of '{"http://www.mulesoft.org/schema/mule/core":abstract-message-processor, "http://www.mulesoft.org/schema/mule/core":abstract-mixed-content-message-processor}' is expected. ``` Scheduler 属性については、​[参照](#reference)​を参照してください。 ## [](#reference)参照 Scheduler 要素は実行間隔および同時実行を設定するための属性を受け入れます。 ### [](#props_scheduler)Scheduler (​``​) デフォルトでは、Scheduler は設定されたケイデンスでフローの別のインスタンスを実行する前にそのフローの前の実行が完了するまで待機しません。この動作は、設定 XML で ​`disallowConcurrentExecution="true"`​ 属性を設定することで変更できます。
属性 XML 説明

disallowConcurrentExecution

この属性を ​true​ に設定すると、Scheduler は前の実行がまだ処理中であればスケジュールされた実行をスキップします。フローが完了すると、Scheduler は次に設定された間隔で実行されます。デフォルト値は ​false​ です。
次の例では、Scheduler はフローが完了までに要する時間が固定の頻度である 10 ミリ秒を超えると実行をスキップします。 ```xml ``` Scheduler が実行をスキップするたびに、たとえば次のような ​`Execution skipped`​ メッセージがログに記録されます (読みやすいように編集済み)。 ```logs INFO 2022-11-09 15:15:43,082 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. INFO 2022-11-09 15:15:43,083 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. ``` ### [](#props_fixed_frequency)固定頻度 (​``​) 固定頻度のスケジュール戦略では、次の属性を受け入れます。
属性 XML デフォルト 説明

Frequency (頻度)

frequency

1000

指定された ​timeUnit​ 設定で Scheduler がフローをトリガーする頻度。

Start Delay (開始遅延)

startDelay

0

アプリケーションが起動した後で Scheduler の最初の実行を遅延する時間。このプロパティでは頻度と同じ ​timeUnit​ を使用します。

Time Unit (時間単位)

timeUnit

MILLISECONDS

frequency​ と ​startDelay​ の値の次のいずれかの時間単位。

MILLISECONDS (ミリ秒)​、​SECONDS (秒)​、​MINUTES (分)​、​HOURS (時)​、または ​DAYS (日)​
次の戦略では、最初の 10 秒の遅延後、10 秒ごとに Scheduler の実行を遅延します。 ```xml ``` ### [](#props_cron_expressions)Cron (​``​) Cron 式を使用することで、より複雑なスケジューリング戦略を設定できます。
属性 XML 説明

Expression (式)

expression

Scheduler をトリガーする Cron 式。デフォルトの Cron 式はありません。式の詳細は、​Cron 式​を参照してください。例: expression="1 1 1 1,7 * ?"​

Time Zone (タイムゾーン)

timeZone

システムプロパティとして渡されるタイムゾーン、またはマシンのオペレーティングシステムで設定されているタイムゾーン。 Java のタイムゾーン​の値がサポートされます。Java の短縮表記 (​PST​ や ​AGT​) は使用せず、Java の完全表記 (​America/Los_Angeles​ など) を使用してください。例: timeZone="America/Argentina/Buenos_Aires"
次の例では、​`America/Los_Angeles`​ タイムゾーンで毎日 12 時 00 分にフローをトリガーする Cron 式を使用します。 ```xml ``` ## [](#cron_expressions)Cron 式 Cron は、日時情報を記述するのに広く利用されている標準です。Cron 式 (​``​ スケジュール戦略 (​``​) は、固定頻度スケジュール戦略では不可能な間隔でフローをトリガーする場合に便利です。 Scheduler は、毎秒を監視し、Quartz Cron 式が日時の設定と一致すると Mule イベントを作成します。イベントは 1 回だけ、または一定間隔でトリガーできます。 日時の式は、6 つの必須設定と、年の設定 (省略可能) で構成されます。設定は以下の順序で指定します。 1. 秒 (​`0`​-​`59`​) 2. 分 (​`0`​-​`59`​) 3. 時 (​`0`​-​`23`​) 4. 日 (​`1`​-​`31`​) 5. 月 (​`1`​-​`12`​ または ​`JAN`​-​`DEC`​) 6. 曜日 (​`1`​-​`7`​ or ​`SUN`​-​`SAT`​) 7. 年 (空白、または ​`1970`​-​`2099`​ の範囲内の 4 桁。例: `2019`​) Scheduler は Quartz Cron 式をサポートします。例をいくつか示します。
式 動作

1/2 * * * * ?

毎日 2 秒おきに実行。

0 15 10 ? * *

毎日午前 10 時 15 分に実行。 0 15 10 * * ? ​` と ​0 15 10 *​`0 15 10 * * ?​ は同じ結果になります。

0 15 10 * * ? 2019

2019 年の毎日午前 10 時 15 分に実行。

0 * 14 * * ?

毎日午後 2 時から 2 時 59 分まで、毎分実行。

0 0/5 14 * * ?

毎日午後 2 時から 2 時 55 分まで、5 分おきに実行。

1 1 1 1,7 * ?

毎月 1 日と 7 日の午前 1 時 1 分 1 秒に実行。
Scheduler コンポーネントは、Quartz Scheduler の特殊文字もサポートします。 - `*`​: すべての値。 - `?`​: 任意の 1 つの値。 - `-`​: 値の範囲。例: `1-3`​。 - `,`​: 追加の値。例: `1,7`​。 - `/`​: 増分値。例: `1/7`​。 - `L`​: 週または月の最終日、または月の最後の特定の曜日 (例: `6L`​ は月の最後の土曜日)。 - `W`​: 平日。日付項目で有効で、特定の日付以降になります。例: `15W`​ はその月の 15 日に最も近い平日を表します。 - `#`​: 月の "n" 日目。例: `#3`​ は月の 3 日。 詳細は、 [「CronExpression」](https://www.quartz-scheduler.org/api/2.3.0/org/quartz/CronExpression.html)​を参照してください。 次の例は、「hello」というメッセージを毎秒ログに記録します。 ```XML ``` Cron 式をビルドするための無料のオンラインツールがたくさんあります。 ## [](#anypoint-exchange-での例)Anypoint Exchange での例 [Anypoint Exchange](https://www.mulesoft.com/exchange/)​ での次の例は、Scheduler コンポーネントのユースケースを示しています。 - _Data Sync Using Watermarking and Batch (ウォーターマークとバッチを使用したデータの同期)_ - _Import Contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Import Leads into Salesforce (Salesforce へのリードのインポート)_ - _Importing a CSV File into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment Using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Salesforce to MySQL Database Using Batch Processing (バッチ処理を使用した Salesforce から MySQL データベースへのインポート)_ - _Sending a CSV File Through Email Using SMTP (SMTP を使用したメールでの CSV ファイルの送信)_ Anypoint Studio からプロジェクトをダウンロードして開くには、[Import a Mule Project from Exchange](https://docs.mulesoft.com/studio/import-project-exchange)を参照してください。 ## [](#anypoint-studio-でのデバッグ)Anypoint Studio でのデバッグ Anypoint Studio の​[デバッグモード](https://docs.mulesoft.com/studio/visual-debugger-concept)​では、Mule アプリケーションはイベントをトリガーできません。デバッグ時に、たとえば次のようにコンポーネントの下に表示される Studio の緑色の矢印アイコンをクリックすることで Scheduler を手動実行できます。 ![Scheduler での \[Debug (デバッグ)](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/scheduler-component-debug-ex.png) 矢印\] ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/flow-component) # スケジューラーエンドポイント (トリガー) Scheduler コンポーネントは、時間ベースの条件に基づいてフローの実行をトリガーする Mule イベントソースです。たとえば Scheduler によって、5 秒ごと、または指定したタイムゾーンで毎日 12 時 00 分にフロー処理をトリガーするメッセージを作成して送信される場合があります。 Mule アプリケーションに Scheduler を追加するときは次の点を考慮してください。 - Scheduler は、Mule が動作しているマシンと同じタイムゾーンを使用します。ただし、アプリケーションが CloudHub で動作している場合は、アプリケーションが動作している地理的リージョンに関係なく、Scheduler は UTC タイムゾーンに準拠します。 Scheduler 用に別のタイムゾーンを設定する場合は、​[Cron (​``​)](#props_cron_expressions)​の​`「timeZone」`​を参照してください。 - `disallowConcurrentExecution`​ プロパティを使用すると、以前にトリガーされた実行の処理中に Scheduler でフローの実行がトリガーできないようにできます。 - スケジュールされたトリガー時に利用できるリソースが 1 つもないために ​[back-pressure](https://docs.mulesoft.com/jp/mule-runtime/4.6/execution-engine#backpressure)​ が発生した場合、その実行はスキップされます。 - Mule Runtime Engine クラスターやマルチワーカー CloudHub デプロイメントでは、Scheduler はプライマリノードのみで (つまり 1 つの Mule インスタンスのみで) 実行されます。 ## [](#アーキテクチャ)アーキテクチャ 他の Mule イベントソースコンポーネントと同様、Scheduler は Mule フローの最初のコンポーネントです。 ![Mule フローの Scheduler コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/scheduler-component-ex.png) Scheduler の XML は以下の要素で構成されます。 - ``​: Scheduler の最上位レベルの要素。 - ``​: 次のいずれかの子を受け入れる第 2 レベル要素。 - ``​: 毎秒などの一般的なスケジュール頻度向け。 - ``​: [Cron 式](#cron_expressions)​およびタイムゾーン設定向け。 Scheduler により、固定の頻度、または Cron 式に基づいた間隔でスケジュール戦略が設定されます。次に例を示します。 - 次の Scheduler の固定の頻度設定では、15 秒ごとに実行されます。 ```xml ``` - Scheduler の Cron 式によって 15 秒ごとにフローが新たに実行され、Mule メッセージの生成がトリガーされます。 ```xml ``` 1 つ以上のプロセッサーが Scheduler に従う必要があります。プロセッサーには、HTTP Request 操作や Transform Message コンポーネントなど、Mule コンポーネントやコネクタ操作が含まれます。プロセッサーを提供しない場合、​`MuleRuntimeException`​ が発生し、Mule アプリケーションのデプロイメントが失敗して、次の ERROR メッセージがログに記録されます (読みやすいように編集済み)。 ```logs ERROR ...MuleRuntimeException ... The content of element 'flow' is not complete. One of '{"http://www.mulesoft.org/schema/mule/core":abstract-message-processor, "http://www.mulesoft.org/schema/mule/core":abstract-mixed-content-message-processor}' is expected. ``` Scheduler 属性については、​[参照](#reference)​を参照してください。 ## [](#reference)参照 Scheduler 要素は実行間隔および同時実行を設定するための属性を受け入れます。 ### [](#props_scheduler)Scheduler (​``​) デフォルトでは、Scheduler は設定されたケイデンスでフローの別のインスタンスを実行する前にそのフローの前の実行が完了するまで待機しません。この動作は、設定 XML で ​`disallowConcurrentExecution="true"`​ 属性を設定することで変更できます。
属性 XML 説明

disallowConcurrentExecution

この属性を ​true​ に設定すると、Scheduler は前の実行がまだ処理中であればスケジュールされた実行をスキップします。フローが完了すると、Scheduler は次に設定された間隔で実行されます。デフォルト値は ​false​ です。
次の例では、Scheduler はフローが完了までに要する時間が固定の頻度である 10 ミリ秒を超えると実行をスキップします。 ```xml ``` Scheduler が実行をスキップするたびに、たとえば次のような ​`Execution skipped`​ メッセージがログに記録されます (読みやすいように編集済み)。 ```logs INFO 2022-11-09 15:15:43,082 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. INFO 2022-11-09 15:15:43,083 ... ...scheduler.DefaultSchedulerMessageSource: Flow 'scheduler-disallowConcurrentExecution-ex' is already running and 'disallowConcurrentExecution' is set to 'true'. Execution skipped. ``` ### [](#props_fixed_frequency)固定頻度 (​``​) 固定頻度のスケジュール戦略では、次の属性を受け入れます。
属性 XML デフォルト 説明

Frequency (頻度)

frequency

1000

指定された ​timeUnit​ 設定で Scheduler がフローをトリガーする頻度。

Start Delay (開始遅延)

startDelay

0

アプリケーションが起動した後で Scheduler の最初の実行を遅延する時間。このプロパティでは頻度と同じ ​timeUnit​ を使用します。

Time Unit (時間単位)

timeUnit

MILLISECONDS

frequency​ と ​startDelay​ の値の次のいずれかの時間単位。

MILLISECONDS (ミリ秒)​、​SECONDS (秒)​、​MINUTES (分)​、​HOURS (時)​、または ​DAYS (日)​
次の戦略では、最初の 10 秒の遅延後、10 秒ごとに Scheduler の実行を遅延します。 ```xml ``` ### [](#props_cron_expressions)Cron (​``​) Cron 式を使用することで、より複雑なスケジューリング戦略を設定できます。
属性 XML 説明

Expression (式)

expression

Scheduler をトリガーする Cron 式。デフォルトの Cron 式はありません。式の詳細は、​Cron 式​を参照してください。例: expression="1 1 1 1,7 * ?"​

Time Zone (タイムゾーン)

timeZone

システムプロパティとして渡されるタイムゾーン、またはマシンのオペレーティングシステムで設定されているタイムゾーン。 Java のタイムゾーン​の値がサポートされます。Java の短縮表記 (​PST​ や ​AGT​) は使用せず、Java の完全表記 (​America/Los_Angeles​ など) を使用してください。例: timeZone="America/Argentina/Buenos_Aires"
次の例では、​`America/Los_Angeles`​ タイムゾーンで毎日 12 時 00 分にフローをトリガーする Cron 式を使用します。 ```xml ``` ## [](#cron_expressions)Cron 式 Cron は、日時情報を記述するのに広く利用されている標準です。Cron 式 (​``​ スケジュール戦略 (​``​) は、固定頻度スケジュール戦略では不可能な間隔でフローをトリガーする場合に便利です。 Scheduler は、毎秒を監視し、Quartz Cron 式が日時の設定と一致すると Mule イベントを作成します。イベントは 1 回だけ、または一定間隔でトリガーできます。 日時の式は、6 つの必須設定と、年の設定 (省略可能) で構成されます。設定は以下の順序で指定します。 1. 秒 (​`0`​-​`59`​) 2. 分 (​`0`​-​`59`​) 3. 時 (​`0`​-​`23`​) 4. 日 (​`1`​-​`31`​) 5. 月 (​`1`​-​`12`​ または ​`JAN`​-​`DEC`​) 6. 曜日 (​`1`​-​`7`​ or ​`SUN`​-​`SAT`​) 7. 年 (空白、または ​`1970`​-​`2099`​ の範囲内の 4 桁。例: `2019`​) Scheduler は Quartz Cron 式をサポートします。例をいくつか示します。
式 動作

1/2 * * * * ?

毎日 2 秒おきに実行。

0 15 10 ? * *

毎日午前 10 時 15 分に実行。 0 15 10 * * ? ​` と ​0 15 10 *​`0 15 10 * * ?​ は同じ結果になります。

0 15 10 * * ? 2019

2019 年の毎日午前 10 時 15 分に実行。

0 * 14 * * ?

毎日午後 2 時から 2 時 59 分まで、毎分実行。

0 0/5 14 * * ?

毎日午後 2 時から 2 時 55 分まで、5 分おきに実行。

1 1 1 1,7 * ?

毎月 1 日と 7 日の午前 1 時 1 分 1 秒に実行。
Scheduler コンポーネントは、Quartz Scheduler の特殊文字もサポートします。 - `*`​: すべての値。 - `?`​: 任意の 1 つの値。 - `-`​: 値の範囲。例: `1-3`​。 - `,`​: 追加の値。例: `1,7`​。 - `/`​: 増分値。例: `1/7`​。 - `L`​: 週または月の最終日、または月の最後の特定の曜日 (例: `6L`​ は月の最後の土曜日)。 - `W`​: 平日。日付項目で有効で、特定の日付以降になります。例: `15W`​ はその月の 15 日に最も近い平日を表します。 - `#`​: 月の "n" 日目。例: `#3`​ は月の 3 日。 詳細は、 [「CronExpression」](https://www.quartz-scheduler.org/api/2.3.0/org/quartz/CronExpression.html)​を参照してください。 次の例は、「hello」というメッセージを毎秒ログに記録します。 ```XML ``` Cron 式をビルドするための無料のオンラインツールがたくさんあります。 ## [](#anypoint-exchange-での例)Anypoint Exchange での例 [Anypoint Exchange](https://www.mulesoft.com/exchange/)​ での次の例は、Scheduler コンポーネントのユースケースを示しています。 - _Data Sync Using Watermarking and Batch (ウォーターマークとバッチを使用したデータの同期)_ - _Import Contacts into Microsoft Dynamics CRM (Microsoft Dynamics CRM への取引先責任者のインポート)_ - _Import Leads into Salesforce (Salesforce へのリードのインポート)_ - _Importing a CSV File into mongoDB (mongoDB への CSV ファイルのインポート)_ - _Importing an Email Attachment Using the IMAP Connector (IMAP Connector を使用したメールの添付ファイルのインポート)_ - _Salesforce to MySQL Database Using Batch Processing (バッチ処理を使用した Salesforce から MySQL データベースへのインポート)_ - _Sending a CSV File Through Email Using SMTP (SMTP を使用したメールでの CSV ファイルの送信)_ Anypoint Studio からプロジェクトをダウンロードして開くには、[Import a Mule Project from Exchange](https://docs.mulesoft.com/studio/import-project-exchange)を参照してください。 ## [](#anypoint-studio-でのデバッグ)Anypoint Studio でのデバッグ Anypoint Studio の​[デバッグモード](https://docs.mulesoft.com/studio/visual-debugger-concept)​では、Mule アプリケーションはイベントをトリガーできません。デバッグ時に、たとえば次のようにコンポーネントの下に表示される Studio の緑色の矢印アイコンをクリックすることで Scheduler を手動実行できます。 ![Scheduler での \[Debug (デバッグ)](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/scheduler-component-debug-ex.png) 矢印\] ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/flow-component) # スタック追跡の設定 デフォルトでは、一部のスタック追跡は Mule に表示されません。Mule にスタック追跡が表示さている場合でも、わかりやすい出力を生成するために一部の内部クラスの参照が除外されています。 Mule スタック追跡の動作は、次の 2 つの方法で制御できます。 - コマンドライン引数を使用する - Anypoint Studio でプロパティを設定する ## [](#コマンドライン引数を使用する)コマンドライン引数を使用する 次のコマンドライン引数と共に ​`-M-DpropertyName`​ を使用して、スタック追跡の動作を制御します。 - `mule.verbose.exceptions`​ - ​**true**​ に設定すると、絞り込まれたスタック追跡が Mule に表示されます。 - `mule.stacktrace.filter`​ - スタック追跡から削除するパッケージやクラスのカンマ区切りリスト。​`string.startsWith()`​ を使用して照合されます。

これらの引数は、Mule 開発者および管理者がトラブルシューティング時に使用できます。これらは、エンドユーザーが使用することを想定していません。
## [](#anypoint-studio-でプロパティを設定する)Anypoint Studio でプロパティを設定する Studio で、上記で指定したプロパティを設定し、スタック追跡の提供や、削除するパッケージまたはクラスの除外を行うように Mule に指示できます。これらの設定を調整する手順は、次のとおりです。 1. **\[Run (実行)\]**​ > ​**\[Run Configurations…​ (設定を実行…​)\]**​ を選択します。 2. プロパティを定義して、目的の動作を指定します。 以下の例では、​`mule.verbose.exceptions`​ プロパティが ​**true**​ に設定されています。 ![Studio-config-stacktrace](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/stack-traces-studio.png) ## [](#スタック追跡とスレッドダンプを取得する)スタック追跡とスレッドダンプを取得する Mule が停止して、その原因を見つけるために詳細情報が必要な場合、以下の手順に従って Mule をトラブルシューティングします。 1. Mule プロセス ID (​`MULE_PID`​) を識別します。 2. スレッドダンプを取得します。 3. Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 ### [](#mule-プロセス-id-の識別)Mule プロセス ID の識別 Mule プロセス ID を識別するには、Unix/Linux ​`ps`​ コマンドを使用するか、ターミナルから ​`jps`​ コマンドを実行します。​`jps`​ ツールは、Mule を実行するために使用される JDK に付属しています。 たとえば、​`MuleContainerBootstrap`​ や ​`ApplicationDeployer`​ などが含まれる行で Mule プロセスを識別します。 ### [](#スレッドダンプの取得)スレッドダンプの取得 最新の JDK で入手できる ​`jstack`​ ツールを使用して、スレッドダンプを取得します。 jstack -l MULE\_PID > filename.tdump ### [](#ヒープダンプの取得)ヒープダンプの取得 Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 Oracle JVM は、この情報を収集する JVM 修飾子を提供します。この変更を適用したら Mule サーバーを再起動して、メモリ不足エラーをもう一度再現する必要があります。 Mule が使用する JVM にこの修飾子を適用するには、ヒープダンプの作成が自動的にトリガーされるように Mule の ​`/conf/wrapper.conf`​ ファイルで次のパラメーターを設定します。 wrapper.java.additional.=-XX:+HeapDumpOnOutOfMemoryError wrapper.java.additional.=-XX:HeapDumpPath=path/to/dumps パラメーターを設定する場合、 を ​`wrapper.conf`​ の順序の次の数値に変更します。

デフォルトでは、Mule には ​HeapDumpOnOutOfMemoryError​ プロパティが含まれていますが、ヒープダンプのパスは定義されていません。
ヒープダンプのパスが定義されていない場合、java プロセスが起動したディレクトリにファイルが作成されます。その後、ヒープダンプファイルが ​`java_pid.hprof.`​ として生成されます。 # スタック追跡の設定 デフォルトでは、一部のスタック追跡は Mule に表示されません。Mule にスタック追跡が表示さている場合でも、わかりやすい出力を生成するために一部の内部クラスの参照が除外されています。 Mule スタック追跡の動作は、次の 2 つの方法で制御できます。 - コマンドライン引数を使用する - Anypoint Studio でプロパティを設定する ## [](#コマンドライン引数を使用する)コマンドライン引数を使用する 次のコマンドライン引数と共に ​`-M-DpropertyName`​ を使用して、スタック追跡の動作を制御します。 - `mule.verbose.exceptions`​ - ​**true**​ に設定すると、絞り込まれたスタック追跡が Mule に表示されます。 - `mule.stacktrace.filter`​ - スタック追跡から削除するパッケージやクラスのカンマ区切りリスト。​`string.startsWith()`​ を使用して照合されます。

これらの引数は、Mule 開発者および管理者がトラブルシューティング時に使用できます。これらは、エンドユーザーが使用することを想定していません。
## [](#anypoint-studio-でプロパティを設定する)Anypoint Studio でプロパティを設定する Studio で、上記で指定したプロパティを設定し、スタック追跡の提供や、削除するパッケージまたはクラスの除外を行うように Mule に指示できます。これらの設定を調整する手順は、次のとおりです。 1. **\[Run (実行)\]**​ > ​**\[Run Configurations…​ (設定を実行…​)\]**​ を選択します。 2. プロパティを定義して、目的の動作を指定します。 以下の例では、​`mule.verbose.exceptions`​ プロパティが ​**true**​ に設定されています。 ![Studio-config-stacktrace](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/stack-traces-studio.png) ## [](#スタック追跡とスレッドダンプを取得する)スタック追跡とスレッドダンプを取得する Mule が停止して、その原因を見つけるために詳細情報が必要な場合、以下の手順に従って Mule をトラブルシューティングします。 1. Mule プロセス ID (​`MULE_PID`​) を識別します。 2. スレッドダンプを取得します。 3. Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 ### [](#mule-プロセス-id-の識別)Mule プロセス ID の識別 Mule プロセス ID を識別するには、Unix/Linux ​`ps`​ コマンドを使用するか、ターミナルから ​`jps`​ コマンドを実行します。​`jps`​ ツールは、Mule を実行するために使用される JDK に付属しています。 たとえば、​`MuleContainerBootstrap`​ や ​`ApplicationDeployer`​ などが含まれる行で Mule プロセスを識別します。 ### [](#スレッドダンプの取得)スレッドダンプの取得 最新の JDK で入手できる ​`jstack`​ ツールを使用して、スレッドダンプを取得します。 jstack -l MULE\_PID > filename.tdump ### [](#ヒープダンプの取得)ヒープダンプの取得 Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 Oracle JVM は、この情報を収集する JVM 修飾子を提供します。この変更を適用したら Mule サーバーを再起動して、メモリ不足エラーをもう一度再現する必要があります。 Mule が使用する JVM にこの修飾子を適用するには、ヒープダンプの作成が自動的にトリガーされるように Mule の ​`/conf/wrapper.conf`​ ファイルで次のパラメーターを設定します。 wrapper.java.additional.=-XX:+HeapDumpOnOutOfMemoryError wrapper.java.additional.=-XX:HeapDumpPath=path/to/dumps パラメーターを設定する場合、 を ​`wrapper.conf`​ の順序の次の数値に変更します。

デフォルトでは、Mule には ​HeapDumpOnOutOfMemoryError​ プロパティが含まれていますが、ヒープダンプのパスは定義されていません。
ヒープダンプのパスが定義されていない場合、java プロセスが起動したディレクトリにファイルが作成されます。その後、ヒープダンプファイルが ​`java_pid.hprof.`​ として生成されます。 # スタック追跡の設定 デフォルトでは、一部のスタック追跡は Mule に表示されません。Mule にスタック追跡が表示さている場合でも、わかりやすい出力を生成するために一部の内部クラスの参照が除外されています。 Mule スタック追跡の動作は、次の 2 つの方法で制御できます。 - コマンドライン引数を使用する - Anypoint Studio でプロパティを設定する ## [](#コマンドライン引数を使用する)コマンドライン引数を使用する 次のコマンドライン引数と共に ​`-M-DpropertyName`​ を使用して、スタック追跡の動作を制御します。 - `mule.verbose.exceptions`​ - ​**true**​ に設定すると、絞り込まれたスタック追跡が Mule に表示されます。 - `mule.stacktrace.filter`​ - スタック追跡から削除するパッケージやクラスのカンマ区切りリスト。​`string.startsWith()`​ を使用して照合されます。

これらの引数は、Mule 開発者および管理者がトラブルシューティング時に使用できます。これらは、エンドユーザーが使用することを想定していません。
## [](#anypoint-studio-でプロパティを設定する)Anypoint Studio でプロパティを設定する Studio で、上記で指定したプロパティを設定し、スタック追跡の提供や、削除するパッケージまたはクラスの除外を行うように Mule に指示できます。これらの設定を調整する手順は、次のとおりです。 1. **\[Run (実行)\]**​ > ​**\[Run Configurations…​ (設定を実行…​)\]**​ を選択します。 2. プロパティを定義して、目的の動作を指定します。 以下の例では、​`mule.verbose.exceptions`​ プロパティが ​**true**​ に設定されています。 ![Studio-config-stacktrace](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/stack-traces-studio.png) ## [](#スタック追跡とスレッドダンプを取得する)スタック追跡とスレッドダンプを取得する Mule が停止して、その原因を見つけるために詳細情報が必要な場合、以下の手順に従って Mule をトラブルシューティングします。 1. Mule プロセス ID (​`MULE_PID`​) を識別します。 2. スレッドダンプを取得します。 3. Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 ### [](#mule-プロセス-id-の識別)Mule プロセス ID の識別 Mule プロセス ID を識別するには、Unix/Linux ​`ps`​ コマンドを使用するか、ターミナルから ​`jps`​ コマンドを実行します。​`jps`​ ツールは、Mule を実行するために使用される JDK に付属しています。 たとえば、​`MuleContainerBootstrap`​ や ​`ApplicationDeployer`​ などが含まれる行で Mule プロセスを識別します。 ### [](#スレッドダンプの取得)スレッドダンプの取得 最新の JDK で入手できる ​`jstack`​ ツールを使用して、スレッドダンプを取得します。 jstack -l MULE\_PID > filename.tdump ### [](#ヒープダンプの取得)ヒープダンプの取得 Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 Oracle JVM は、この情報を収集する JVM 修飾子を提供します。この変更を適用したら Mule サーバーを再起動して、メモリ不足エラーをもう一度再現する必要があります。 Mule が使用する JVM にこの修飾子を適用するには、ヒープダンプの作成が自動的にトリガーされるように Mule の ​`/conf/wrapper.conf`​ ファイルで次のパラメーターを設定します。 wrapper.java.additional.=-XX:+HeapDumpOnOutOfMemoryError wrapper.java.additional.=-XX:HeapDumpPath=path/to/dumps パラメーターを設定する場合、 を ​`wrapper.conf`​ の順序の次の数値に変更します。

デフォルトでは、Mule には ​HeapDumpOnOutOfMemoryError​ プロパティが含まれていますが、ヒープダンプのパスは定義されていません。
ヒープダンプのパスが定義されていない場合、java プロセスが起動したディレクトリにファイルが作成されます。その後、ヒープダンプファイルが ​`java_pid.hprof.`​ として生成されます。 # スタック追跡の設定 デフォルトでは、一部のスタック追跡は Mule に表示されません。Mule にスタック追跡が表示さている場合でも、わかりやすい出力を生成するために一部の内部クラスの参照が除外されています。 Mule スタック追跡の動作は、次の 2 つの方法で制御できます。 - コマンドライン引数を使用する - Anypoint Studio でプロパティを設定する ## [](#コマンドライン引数を使用する)コマンドライン引数を使用する 次のコマンドライン引数と共に ​`-M-DpropertyName`​ を使用して、スタック追跡の動作を制御します。 - `mule.verbose.exceptions`​ - ​**true**​ に設定すると、絞り込まれたスタック追跡が Mule に表示されます。 - `mule.stacktrace.filter`​ - スタック追跡から削除するパッケージやクラスのカンマ区切りリスト。​`string.startsWith()`​ を使用して照合されます。

これらの引数は、Mule 開発者および管理者がトラブルシューティング時に使用できます。これらは、エンドユーザーが使用することを想定していません。
## [](#anypoint-studio-でプロパティを設定する)Anypoint Studio でプロパティを設定する Studio で、上記で指定したプロパティを設定し、スタック追跡の提供や、削除するパッケージまたはクラスの除外を行うように Mule に指示できます。これらの設定を調整する手順は、次のとおりです。 1. **\[Run (実行)\]**​ > ​**\[Run Configurations…​ (設定を実行…​)\]**​ を選択します。 2. プロパティを定義して、目的の動作を指定します。 以下の例では、​`mule.verbose.exceptions`​ プロパティが ​**true**​ に設定されています。 ![Studio-config-stacktrace](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/stack-traces-studio.png) ## [](#スタック追跡とスレッドダンプを取得する)スタック追跡とスレッドダンプを取得する Mule が停止して、その原因を見つけるために詳細情報が必要な場合、以下の手順に従って Mule をトラブルシューティングします。 1. Mule プロセス ID (​`MULE_PID`​) を識別します。 2. スレッドダンプを取得します。 3. Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 ### [](#mule-プロセス-id-の識別)Mule プロセス ID の識別 Mule プロセス ID を識別するには、Unix/Linux ​`ps`​ コマンドを使用するか、ターミナルから ​`jps`​ コマンドを実行します。​`jps`​ ツールは、Mule を実行するために使用される JDK に付属しています。 たとえば、​`MuleContainerBootstrap`​ や ​`ApplicationDeployer`​ などが含まれる行で Mule プロセスを識別します。 ### [](#スレッドダンプの取得)スレッドダンプの取得 最新の JDK で入手できる ​`jstack`​ ツールを使用して、スレッドダンプを取得します。 jstack -l MULE\_PID > filename.tdump ### [](#ヒープダンプの取得)ヒープダンプの取得 Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 Oracle JVM は、この情報を収集する JVM 修飾子を提供します。この変更を適用したら Mule サーバーを再起動して、メモリ不足エラーをもう一度再現する必要があります。 Mule が使用する JVM にこの修飾子を適用するには、ヒープダンプの作成が自動的にトリガーされるように Mule の ​`/conf/wrapper.conf`​ ファイルで次のパラメーターを設定します。 wrapper.java.additional.=-XX:+HeapDumpOnOutOfMemoryError wrapper.java.additional.=-XX:HeapDumpPath=path/to/dumps パラメーターを設定する場合、 を ​`wrapper.conf`​ の順序の次の数値に変更します。

デフォルトでは、Mule には ​HeapDumpOnOutOfMemoryError​ プロパティが含まれていますが、ヒープダンプのパスは定義されていません。
ヒープダンプのパスが定義されていない場合、java プロセスが起動したディレクトリにファイルが作成されます。その後、ヒープダンプファイルが ​`java_pid.hprof.`​ として生成されます。 # スタック追跡の設定 デフォルトでは、一部のスタック追跡は Mule に表示されません。Mule にスタック追跡が表示さている場合でも、わかりやすい出力を生成するために一部の内部クラスの参照が除外されています。 Mule スタック追跡の動作は、次の 2 つの方法で制御できます。 - コマンドライン引数を使用する - Anypoint Studio でプロパティを設定する ## [](#コマンドライン引数を使用する)コマンドライン引数を使用する 次のコマンドライン引数と共に ​`-M-DpropertyName`​ を使用して、スタック追跡の動作を制御します。 - `mule.verbose.exceptions`​ - ​**true**​ に設定すると、絞り込まれたスタック追跡が Mule に表示されます。 - `mule.stacktrace.filter`​ - スタック追跡から削除するパッケージやクラスのカンマ区切りリスト。​`string.startsWith()`​ を使用して照合されます。

これらの引数は、Mule 開発者および管理者がトラブルシューティング時に使用できます。これらは、エンドユーザーが使用することを想定していません。
## [](#anypoint-studio-でプロパティを設定する)Anypoint Studio でプロパティを設定する Studio で、上記で指定したプロパティを設定し、スタック追跡の提供や、削除するパッケージまたはクラスの除外を行うように Mule に指示できます。これらの設定を調整する手順は、次のとおりです。 1. **\[Run (実行)\]**​ > ​**\[Run Configurations…​ (設定を実行…​)\]**​ を選択します。 2. プロパティを定義して、目的の動作を指定します。 以下の例では、​`mule.verbose.exceptions`​ プロパティが ​**true**​ に設定されています。 ![Studio-config-stacktrace](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/stack-traces-studio.png) ## [](#スタック追跡とスレッドダンプを取得する)スタック追跡とスレッドダンプを取得する Mule が停止して、その原因を見つけるために詳細情報が必要な場合、以下の手順に従って Mule をトラブルシューティングします。 1. Mule プロセス ID (​`MULE_PID`​) を識別します。 2. スレッドダンプを取得します。 3. Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 ### [](#mule-プロセス-id-の識別)Mule プロセス ID の識別 Mule プロセス ID を識別するには、Unix/Linux ​`ps`​ コマンドを使用するか、ターミナルから ​`jps`​ コマンドを実行します。​`jps`​ ツールは、Mule を実行するために使用される JDK に付属しています。 たとえば、​`MuleContainerBootstrap`​ や ​`ApplicationDeployer`​ などが含まれる行で Mule プロセスを識別します。 ### [](#スレッドダンプの取得)スレッドダンプの取得 最新の JDK で入手できる ​`jstack`​ ツールを使用して、スレッドダンプを取得します。 jstack -l MULE\_PID > filename.tdump ### [](#ヒープダンプの取得)ヒープダンプの取得 Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 Oracle JVM は、この情報を収集する JVM 修飾子を提供します。この変更を適用したら Mule サーバーを再起動して、メモリ不足エラーをもう一度再現する必要があります。 Mule が使用する JVM にこの修飾子を適用するには、ヒープダンプの作成が自動的にトリガーされるように Mule の ​`/conf/wrapper.conf`​ ファイルで次のパラメーターを設定します。 wrapper.java.additional.=-XX:+HeapDumpOnOutOfMemoryError wrapper.java.additional.=-XX:HeapDumpPath=path/to/dumps パラメーターを設定する場合、 を ​`wrapper.conf`​ の順序の次の数値に変更します。

デフォルトでは、Mule には ​HeapDumpOnOutOfMemoryError​ プロパティが含まれていますが、ヒープダンプのパスは定義されていません。
ヒープダンプのパスが定義されていない場合、java プロセスが起動したディレクトリにファイルが作成されます。その後、ヒープダンプファイルが ​`java_pid.hprof.`​ として生成されます。 # スタック追跡の設定 デフォルトでは、一部のスタック追跡は Mule に表示されません。Mule にスタック追跡が表示さている場合でも、わかりやすい出力を生成するために一部の内部クラスの参照が除外されています。 Mule スタック追跡の動作は、次の 2 つの方法で制御できます。 - コマンドライン引数を使用する - Anypoint Studio でプロパティを設定する ## [](#コマンドライン引数を使用する)コマンドライン引数を使用する 次のコマンドライン引数と共に ​`-M-DpropertyName`​ を使用して、スタック追跡の動作を制御します。 - `mule.verbose.exceptions`​ - ​**true**​ に設定すると、絞り込まれたスタック追跡が Mule に表示されます。 - `mule.stacktrace.filter`​ - スタック追跡から削除するパッケージやクラスのカンマ区切りリスト。​`string.startsWith()`​ を使用して照合されます。

これらの引数は、Mule 開発者および管理者がトラブルシューティング時に使用できます。これらは、エンドユーザーが使用することを想定していません。
## [](#anypoint-studio-でプロパティを設定する)Anypoint Studio でプロパティを設定する Studio で、上記で指定したプロパティを設定し、スタック追跡の提供や、削除するパッケージまたはクラスの除外を行うように Mule に指示できます。これらの設定を調整する手順は、次のとおりです。 1. **\[Run (実行)\]**​ > ​**\[Run Configurations…​ (設定を実行…​)\]**​ を選択します。 2. プロパティを定義して、目的の動作を指定します。 以下の例では、​`mule.verbose.exceptions`​ プロパティが ​**true**​ に設定されています。 ![VM 引数が含まれる設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/stack-traces-studio.png) ## [](#スタック追跡とスレッドダンプを取得する)スタック追跡とスレッドダンプを取得する Mule が停止して、その原因を見つけるために詳細情報が必要な場合、以下の手順に従って Mule をトラブルシューティングします。 1. Mule プロセス ID (​`MULE_PID`​) を識別します。 2. スレッドダンプを取得します。 3. Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 ### [](#mule-プロセス-id-の識別)Mule プロセス ID の識別 Mule プロセス ID を識別するには、Unix/Linux ​`ps`​ コマンドを使用するか、ターミナルから ​`jps`​ コマンドを実行します。​`jps`​ ツールは、Mule を実行するために使用される JDK に付属しています。 たとえば、​`MuleContainerBootstrap`​ や ​`ApplicationDeployer`​ などが含まれる行で Mule プロセスを識別します。 ### [](#スレッドダンプの取得)スレッドダンプの取得 最新の JDK で入手できる ​`jstack`​ ツールを使用して、スレッドダンプを取得します。 jstack -l MULE\_PID > filename.tdump ### [](#ヒープダンプの取得)ヒープダンプの取得 Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 Oracle JVM は、この情報を収集する JVM 修飾子を提供します。この変更を適用したら Mule サーバーを再起動して、メモリ不足エラーをもう一度再現する必要があります。 Mule が使用する JVM にこの修飾子を適用するには、ヒープダンプの作成が自動的にトリガーされるように Mule の ​`/conf/wrapper.conf`​ ファイルで次のパラメーターを設定します。 wrapper.java.additional.=-XX:+HeapDumpOnOutOfMemoryError wrapper.java.additional.=-XX:HeapDumpPath=path/to/dumps パラメーターを設定する場合、 を ​`wrapper.conf`​ の順序の次の数値に変更します。

デフォルトでは、Mule には ​HeapDumpOnOutOfMemoryError​ プロパティが含まれていますが、ヒープダンプのパスは定義されていません。
ヒープダンプのパスが定義されていない場合、java プロセスが起動したディレクトリにファイルが作成されます。その後、ヒープダンプファイルが ​`java_pid.hprof.`​ として生成されます。 # スタック追跡の設定 デフォルトでは、一部のスタック追跡は Mule に表示されません。Mule にスタック追跡が表示さている場合でも、わかりやすい出力を生成するために一部の内部クラスの参照が除外されています。 Mule スタック追跡の動作は、次の 2 つの方法で制御できます。 - コマンドライン引数を使用する - Anypoint Studio でプロパティを設定する ## [](#コマンドライン引数を使用する)コマンドライン引数を使用する 次のコマンドライン引数と共に ​`-M-DpropertyName`​ を使用して、スタック追跡の動作を制御します。 - `mule.verbose.exceptions`​ - ​**true**​ に設定すると、絞り込まれたスタック追跡が Mule に表示されます。 - `mule.stacktrace.filter`​ - スタック追跡から削除するパッケージやクラスのカンマ区切りリスト。​`string.startsWith()`​ を使用して照合されます。

これらの引数は、Mule 開発者および管理者がトラブルシューティング時に使用できます。これらは、エンドユーザーが使用することを想定していません。
## [](#anypoint-studio-でプロパティを設定する)Anypoint Studio でプロパティを設定する Studio で、上記で指定したプロパティを設定し、スタック追跡の提供や、削除するパッケージまたはクラスの除外を行うように Mule に指示できます。これらの設定を調整する手順は、次のとおりです。 1. **\[Run (実行)\]**​ > ​**\[Run Configurations…​ (設定を実行…​)\]**​ を選択します。 2. プロパティを定義して、目的の動作を指定します。 以下の例では、​`mule.verbose.exceptions`​ プロパティが ​**true**​ に設定されています。 ![VM 引数が含まれる設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/stack-traces-studio.png) ## [](#スタック追跡とスレッドダンプを取得する)スタック追跡とスレッドダンプを取得する Mule が停止して、その原因を見つけるために詳細情報が必要な場合、以下の手順に従って Mule をトラブルシューティングします。 1. Mule プロセス ID (​`MULE_PID`​) を識別します。 2. スレッドダンプを取得します。 3. Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 ### [](#mule-プロセス-id-の識別)Mule プロセス ID の識別 Mule プロセス ID を識別するには、Unix/Linux ​`ps`​ コマンドを使用するか、ターミナルから ​`jps`​ コマンドを実行します。​`jps`​ ツールは、Mule を実行するために使用される JDK に付属しています。 たとえば、​`MuleContainerBootstrap`​ や ​`ApplicationDeployer`​ などが含まれる行で Mule プロセスを識別します。 ### [](#スレッドダンプの取得)スレッドダンプの取得 最新の JDK で入手できる ​`jstack`​ ツールを使用して、スレッドダンプを取得します。 jstack -l MULE\_PID > filename.tdump ### [](#ヒープダンプの取得)ヒープダンプの取得 Mule サーバーでメモリ不足エラー ​`java.lang.OutOfMemoryError: Java heap space`​ がスローされた場合、ヒープダンプを取得します。 Oracle JVM は、この情報を収集する JVM 修飾子を提供します。この変更を適用したら Mule サーバーを再起動して、メモリ不足エラーをもう一度再現する必要があります。 Mule が使用する JVM にこの修飾子を適用するには、ヒープダンプの作成が自動的にトリガーされるように Mule の ​`/conf/wrapper.conf`​ ファイルで次のパラメーターを設定します。 wrapper.java.additional.=-XX:+HeapDumpOnOutOfMemoryError wrapper.java.additional.=-XX:HeapDumpPath=path/to/dumps パラメーターを設定する場合、 を ​`wrapper.conf`​ の順序の次の数値に変更します。

デフォルトでは、Mule には ​HeapDumpOnOutOfMemoryError​ プロパティが含まれていますが、ヒープダンプのパスは定義されていません。
ヒープダンプのパスが定義されていない場合、java プロセスが起動したディレクトリにファイルが作成されます。その後、ヒープダンプファイルが ​`java_pid.hprof.`​ として生成されます。 # ストリーミング戦略リファレンス デフォルトのストリーミング戦略設定を使用することも、ニーズに合わせて設定することもできます。これらの戦略についての詳細は、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.3/streaming-about)​を参照してください。 ## [](#反復可能メモリ内ストリームリファレンス)反復可能メモリ内ストリームリファレンス
パラメーター名 必須 式 デフォルト値 説明

initialBufferSize

いいえ

いいえ

512

ストリームをコンシュームし、ランダムアクセスを提供するために割り当てられたメモリ量。このバッファに入りきらない量のデータがストリームに含まれている場合、​bufferSizeIncrement​ 属性と ​maxInMemorySize​ の上限に従ってメモリが拡張されます。

bufferSizeIncrement

いいえ

いいえ

512

ストリームのサイズが初期バッファサイズを超えた場合にバッファサイズを拡張する量。値を 0 または負の値に設定すると、バッファは拡張されず、バッファがいっぱいになると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。

maxInMemorySize

いいえ

いいえ

1024

使用するメモリの最大量。ストリームのサイズが最大量を超えると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。0 以下の値は無制限を意味します。デフォルトは 1024 です。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
### [](#ファイルに格納された入力ストリーム)ファイルに格納された入力ストリーム ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
パラメーター名 必須 式 デフォルト値 説明

inMemorySize

いいえ

いいえ

512

データをメモリ内に保持するためのストリームの最大メモリサイズを定義します。 設定された以上の量がコンシュームされると、戦略によってディスクへのコンテンツのバッファが開始されます。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.3/streaming-about) # ストリーミング戦略リファレンス デフォルトのストリーミング戦略設定を使用することも、ニーズに合わせて設定することもできます。これらの戦略についての詳細は、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.4/streaming-about)​を参照してください。 ## [](#反復可能メモリ内ストリームリファレンス)反復可能メモリ内ストリームリファレンス
パラメーター名 必須 式 デフォルト値 説明

initialBufferSize

いいえ

いいえ

512

ストリームをコンシュームし、ランダムアクセスを提供するために割り当てられたメモリ量。このバッファに入りきらない量のデータがストリームに含まれている場合、​bufferSizeIncrement​ 属性と ​maxInMemorySize​ の上限に従ってメモリが拡張されます。

bufferSizeIncrement

いいえ

いいえ

512

ストリームのサイズが初期バッファサイズを超えた場合にバッファサイズを拡張する量。値を 0 または負の値に設定すると、バッファは拡張されず、バッファがいっぱいになると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。

maxInMemorySize

いいえ

いいえ

1024

使用するメモリの最大量。ストリームのサイズが最大量を超えると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。0 以下の値は無制限を意味します。デフォルトは 1024 です。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
### [](#ファイルに格納された入力ストリーム)ファイルに格納された入力ストリーム ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
パラメーター名 必須 式 デフォルト値 説明

inMemorySize

いいえ

いいえ

512

データをメモリ内に保持するためのストリームの最大メモリサイズを定義します。 設定された以上の量がコンシュームされると、戦略によってディスクへのコンテンツのバッファが開始されます。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.4/streaming-about) # ストリーミング戦略リファレンス デフォルトのストリーミング戦略設定を使用することも、ニーズに合わせて設定することもできます。これらの戦略についての詳細は、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.5/streaming-about)​を参照してください。 ## [](#反復可能メモリ内ストリームリファレンス)反復可能メモリ内ストリームリファレンス
パラメーター名 必須 式 デフォルト値 説明

initialBufferSize

いいえ

いいえ

512

ストリームをコンシュームし、ランダムアクセスを提供するために割り当てられたメモリ量。このバッファに入りきらない量のデータがストリームに含まれている場合、​bufferSizeIncrement​ 属性と ​maxInMemorySize​ の上限に従ってメモリが拡張されます。

bufferSizeIncrement

いいえ

いいえ

512

ストリームのサイズが初期バッファサイズを超えた場合にバッファサイズを拡張する量。値を 0 または負の値に設定すると、バッファは拡張されず、バッファがいっぱいになると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。

maxInMemorySize

いいえ

いいえ

1024

使用するメモリの最大量。ストリームのサイズが最大量を超えると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。0 以下の値は無制限を意味します。デフォルトは 1024 です。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
### [](#ファイルに格納された入力ストリーム)ファイルに格納された入力ストリーム ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
パラメーター名 必須 式 デフォルト値 説明

inMemorySize

いいえ

いいえ

512

データをメモリ内に保持するためのストリームの最大メモリサイズを定義します。 設定された以上の量がコンシュームされると、戦略によってディスクへのコンテンツのバッファが開始されます。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.5/streaming-about) # ストリーミング戦略リファレンス デフォルトのストリーミング戦略設定を使用することも、ニーズに合わせて設定することもできます。これらの戦略についての詳細は、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.6/streaming-about)​を参照してください。 ## [](#反復可能メモリ内ストリームリファレンス)反復可能メモリ内ストリームリファレンス
パラメーター名 必須 式 デフォルト値 説明

initialBufferSize

いいえ

いいえ

512

ストリームをコンシュームし、ランダムアクセスを提供するために割り当てられたメモリ量。このバッファに入りきらない量のデータがストリームに含まれている場合、​bufferSizeIncrement​ 属性と ​maxInMemorySize​ の上限に従ってメモリが拡張されます。

bufferSizeIncrement

いいえ

いいえ

512

ストリームのサイズが初期バッファサイズを超えた場合にバッファサイズを拡張する量。値を 0 または負の値に設定すると、バッファは拡張されず、バッファがいっぱいになると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。

maxInMemorySize

いいえ

いいえ

1024

使用するメモリの最大量。ストリームのサイズが最大量を超えると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。0 以下の値は無制限を意味します。デフォルトは 1024 です。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
### [](#ファイルに格納された入力ストリーム)ファイルに格納された入力ストリーム ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
パラメーター名 必須 式 デフォルト値 説明

inMemorySize

いいえ

いいえ

512

データをメモリ内に保持するためのストリームの最大メモリサイズを定義します。 設定された以上の量がコンシュームされると、戦略によってディスクへのコンテンツのバッファが開始されます。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.6/streaming-about) # ストリーミング戦略リファレンス デフォルトのストリーミング戦略設定を使用することも、ニーズに合わせて設定することもできます。これらの戦略についての詳細は、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.7/streaming-about)​を参照してください。 ## [](#反復可能メモリ内ストリームリファレンス)反復可能メモリ内ストリームリファレンス
パラメーター名 必須 式 デフォルト値 説明

initialBufferSize

いいえ

いいえ

512

ストリームをコンシュームし、ランダムアクセスを提供するために割り当てられたメモリ量。このバッファに入りきらない量のデータがストリームに含まれている場合、​bufferSizeIncrement​ 属性と ​maxInMemorySize​ の上限に従ってメモリが拡張されます。

bufferSizeIncrement

いいえ

いいえ

512

ストリームのサイズが初期バッファサイズを超えた場合にバッファサイズを拡張する量。値を 0 または負の値に設定すると、バッファは拡張されず、バッファがいっぱいになると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。

maxInMemorySize

いいえ

いいえ

1024

使用するメモリの最大量。ストリームのサイズが最大量を超えると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。0 以下の値は無制限を意味します。デフォルトは 1024 です。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
### [](#ファイルに格納された入力ストリーム)ファイルに格納された入力ストリーム ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
パラメーター名 必須 式 デフォルト値 説明

inMemorySize

いいえ

いいえ

512

データをメモリ内に保持するためのストリームの最大メモリサイズを定義します。 設定された以上の量がコンシュームされると、戦略によってディスクへのコンテンツのバッファが開始されます。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.7/streaming-about) # ストリーミング戦略リファレンス デフォルトのストリーミング戦略設定を使用することも、ニーズに合わせて設定することもできます。これらの戦略についての詳細は、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.8/streaming-about)​を参照してください。 ## [](#反復可能メモリ内ストリームリファレンス)反復可能メモリ内ストリームリファレンス
パラメーター名 必須 式 デフォルト値 説明

initialBufferSize

いいえ

いいえ

512

ストリームをコンシュームし、ランダムアクセスを提供するために割り当てられたメモリ量。このバッファに入りきらない量のデータがストリームに含まれている場合、​bufferSizeIncrement​ 属性と ​maxInMemorySize​ の上限に従ってメモリが拡張されます。

bufferSizeIncrement

いいえ

いいえ

512

ストリームのサイズが初期バッファサイズを超えた場合にバッファサイズを拡張する量。値を 0 または負の値に設定すると、バッファは拡張されず、バッファがいっぱいになると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。

maxInMemorySize

いいえ

いいえ

1024

使用するメモリの最大量。ストリームのサイズが最大量を超えると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。0 以下の値は無制限を意味します。デフォルトは 1024 です。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
### [](#ファイルに格納された入力ストリーム)ファイルに格納された入力ストリーム ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
パラメーター名 必須 式 デフォルト値 説明

inMemorySize

いいえ

いいえ

512

データをメモリ内に保持するためのストリームの最大メモリサイズを定義します。 設定された以上の量がコンシュームされると、戦略によってディスクへのコンテンツのバッファが開始されます。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.8/streaming-about) # ストリーミング戦略リファレンス デフォルトのストリーミング戦略設定を使用することも、ニーズに合わせて設定することもできます。これらの戦略についての詳細は、​[「Mule アプリケーションでのストリーミング」](https://docs.mulesoft.com/jp/mule-runtime/4.9/streaming-about)​を参照してください。 ## [](#反復可能メモリ内ストリームリファレンス)反復可能メモリ内ストリームリファレンス
パラメーター名 必須 式 デフォルト値 説明

initialBufferSize

いいえ

いいえ

512

ストリームをコンシュームし、ランダムアクセスを提供するために割り当てられたメモリ量。このバッファに入りきらない量のデータがストリームに含まれている場合、​bufferSizeIncrement​ 属性と ​maxInMemorySize​ の上限に従ってメモリが拡張されます。

bufferSizeIncrement

いいえ

いいえ

512

ストリームのサイズが初期バッファサイズを超えた場合にバッファサイズを拡張する量。値を 0 または負の値に設定すると、バッファは拡張されず、バッファがいっぱいになると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。

maxInMemorySize

いいえ

いいえ

1024

使用するメモリの最大量。ストリームのサイズが最大量を超えると、​STREAM_MAXIMUM_SIZE_EXCEEDED​ エラーが生成されます。0 以下の値は無制限を意味します。デフォルトは 1024 です。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
### [](#ファイルに格納された入力ストリーム)ファイルに格納された入力ストリーム ファイルストレージは Mule Enterprise Edition (Mule EE) でのみ使用できます。
パラメーター名 必須 式 デフォルト値 説明

inMemorySize

いいえ

いいえ

512

データをメモリ内に保持するためのストリームの最大メモリサイズを定義します。 設定された以上の量がコンシュームされると、戦略によってディスクへのコンテンツのバッファが開始されます。

bufferUnit

いいえ

いいえ

KB

これらのすべての属性の単位。可能な値: BYTE (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)。
## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.9/streaming-about) # スプリッターとアグリゲーターの移行 スプリッターは Mule 4 ではサポートされなくなりました。要素のコレクションを順次処理する場合は、​[For Each コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/for-each-scope-concept)​を使用します。 [アグリゲーター](https://docs.mulesoft.com/jp/aggregators-module/latest/)​はかなり動作が異なりますが、別個のモジュールとして Mule 4 に残されています。 ## [](#スプリッター)スプリッター Mule 3 のスプリッターと Mule 4 の For Each コンポーネントの主な違いは、​`foreach`​ 要素はスコープであるということです。つまり反復される要素を処理するために使用されるコンポーネントは ​`foreach`​ 内に定義する必要があります。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` また、​`foreach`​ 要素は、処理されたすべての値の結果を含むコレクションを返しません。代わりに、入力として受け取った同じコレクションを返します。したがって、上記の例の動作は同じではありません。 Mule 3 のアグリゲーターがあるかどうかは関係ありません。処理された値の結果を保存するには、Mule 4 のアグリゲーターを使用する必要があります。 ### [](#単純な移行)単純な移行 移行のデフォルトの形式は次のとおりです。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約の完了後に結果を保存するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。 - `foreach`​ 要素の後のペイロードは、受け取った入力と同じになるので、​`set-payload`​ を使用して、ペイロードを ​`aggregation-complete`​ ルートの内側に定義された変数の保存値として設定します。 ### [](#complex_migration)複雑な移行 スプリッターとアグリゲーターを使用する Mule 3 設定では、場合によってはさらにパラメーターが追加されることがあります。そのため、Mule 4 で Mule 3 の動作を実行する場合は移行がやや複雑になります。 Mule 3 のアグリゲーターでは、​`timeout`​ と ​`failOnTimeout`​ という 2 つの属性を設定することができました。​`timeout`​ 属性 (0 より大きい値を持つ) がある場合、移行は以下の例のようになります。
タイムアウトになった集約がある場合にロジックを追加する方法があり、​failOnTimeout​ が ​true​ に設定されている場合でも、Mule 3 と同じ動作にはなりません。Mule 4 のアグリゲーターでは、タイムアウトになった集約がある場合にエラーが発生したり、通知がディスパッチされたりすることはありません。
Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - 集約が終了したのは、タイムアウトになったからなのか、または処理が完了したからなのかを示すインジケーターを保存する必要がある場合は、別の変数 ​`collection-splitter0-aggregator-complete-aggregation`​ を作成します。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。 予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約のタイムアウトは、Mule 3 のアグリゲーターに含まれているタイムアウトに設定します。 集約が完了したことを設定するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。(そのルートは、完了した集約によってのみ実行されます)。 もう 1 つフローを作成し、​`aggregator:aggregator-listener`​ を取得元として追加します。すべての集約 (完了してもしなくても) によってそのリスナーがトリガーされます。次に、集約は ​`vm:publish`​ 操作によってメインフローに送信されます。 - `vm:consume`​ 操作が ​`foreach`​ 要素の後に追加され、集約を待機します。値を読み取ったら、フローは実行を続行します。 - `collection-splitter0-aggregator-complete-aggregation`​ は集約が完了した場合にのみ true に設定されるので、ロジックを追加してその変数の値を (​`choice`​ と ​`when`​ で) チェックすることができます。これで、Mule 3 エラーハンドラーに以前追加された、タイムアウトエラーが発生した場合のロジックをシミュレートできます。 ### [](#その他の属性)その他の属性 すべてのスプリッターでは ​`enableCorrelation`​ 属性の設定が可能でした。 `enableCorrelation="NEVER"`​ 設定を移行する方法はありません。相関 ID は常に ​`foreach`​ 要素によってコレクションから処理されたイベントに設定されます。 式のスプリッター (​``​) では、​`evaluator`​ と ​`custom-evaluator`​ という 2 つの属性の設定が可能でした。式のエバリュエーターは設定できなくなりました。DataWeave のみを使用できます。 ### [](#使用可能なスプリッターの移行)使用可能なスプリッターの移行 Mule 3 には以下のスプリッターがありました。その中には、移行するためにはロジックを追加する必要があるものと、まったく移行できないものがあります。 - `collection-splitter`​: メインの例で定義されたとおり。 - `custom-splitter`​: Mule 4 ではカスタムクラスの使用が許されていないので、このスプリッターは移行できません。 - `splitter`​ (式のスプリッター): 使用される式は、​`foreach`​ 要素の ​`collection`​ 属性として設定します。 - Mule 3: `` - Mule 4: `` - `map-splitter`​ : DataWeave 式 ​`#[dw::core::Objects::entrySet(payload)]`​ は ​`foreach`​ 要素の ​`collection`​ 属性として使用します。 - Mule 3: `` - Mule 4: `` - `message-chunk-splitter`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ### [](#アグリゲーター)アグリゲーター Mule 3 のアグリゲーターで許可されていたほとんどのパラメーターは、Mule 4 では許可されていません。 - `timeout`​: 新しいアグリゲーターで timeout パラメーターを設定できますが、相違点がいくつかあります。まず、時間単位を指定するために ​`timeoutUnit`​ も作成します。また、集約タイムアウトの動作は、Mule 4 のアグリゲーターでは大きく異なります。詳細は、​[「アグリゲーターモジュールリファレンス」](https://docs.mulesoft.com/jp/aggregators-module/latest/aggregators-module-reference)​を参照してください。 - `failOnTimeout`​: 使用できなくなりました。ただし、​[複雑な移行](#complex_migration)​で説明したとおり、同じような動作を実行することはできます。 - `processed-groups-object-store-ref`​: 処理されたグループは、別個のオブジェクトストアに保存されなくなりました。このパラメーターは許可されなくなりました。 - `event-groups-object-store-ref`​: Mule 4 のアグリゲーターでは、​`objectStore`​ 属性を使用してこのオブジェクトストアを設定できます。 - `persistentStores`​: 許可されなくなりました。永続的なオブジェクトストアが必要な場合、​`objectStore`​ 属性は永続的なオブジェクトストアの名前にします。 - `storePrefix`​: 許可されなくなりました。 ### [](#使用可能なアグリゲーターの移行)使用可能なアグリゲーターの移行 - `collection-aggregator`​: メインの例で定義されたとおりに移行します。 - `custom-aggregator`​: 移行できません。Mule 4 には、インターフェースのカスタム実装を追加する方法がありません。 - `message-chunk-aggregator`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ## [](#関連情報)関連情報 [アグリゲーターモジュール](https://docs.mulesoft.com/jp/aggregators-module/latest/) [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/for-each-scope-concept) [For Each スコープリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/for-each-scope-concept) # スプリッターとアグリゲーターの移行 スプリッターは Mule 4 ではサポートされなくなりました。要素のコレクションを順次処理する場合は、​[For Each コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/for-each-scope-concept)​を使用します。 [アグリゲーター](https://docs.mulesoft.com/jp/aggregators-module/latest/)​はかなり動作が異なりますが、別個のモジュールとして Mule 4 に残されています。 ## [](#スプリッター)スプリッター Mule 3 のスプリッターと Mule 4 の For Each コンポーネントの主な違いは、​`foreach`​ 要素はスコープであるということです。つまり反復される要素を処理するために使用されるコンポーネントは ​`foreach`​ 内に定義する必要があります。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` また、​`foreach`​ 要素は、処理されたすべての値の結果を含むコレクションを返しません。代わりに、入力として受け取った同じコレクションを返します。したがって、上記の例の動作は同じではありません。 Mule 3 のアグリゲーターがあるかどうかは関係ありません。処理された値の結果を保存するには、Mule 4 のアグリゲーターを使用する必要があります。 ### [](#単純な移行)単純な移行 移行のデフォルトの形式は次のとおりです。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約の完了後に結果を保存するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。 - `foreach`​ 要素の後のペイロードは、受け取った入力と同じになるので、​`set-payload`​ を使用して、ペイロードを ​`aggregation-complete`​ ルートの内側に定義された変数の保存値として設定します。 ### [](#complex_migration)複雑な移行 スプリッターとアグリゲーターを使用する Mule 3 設定では、場合によってはさらにパラメーターが追加されることがあります。そのため、Mule 4 で Mule 3 の動作を実行する場合は移行がやや複雑になります。 Mule 3 のアグリゲーターでは、​`timeout`​ と ​`failOnTimeout`​ という 2 つの属性を設定することができました。​`timeout`​ 属性 (0 より大きい値を持つ) がある場合、移行は以下の例のようになります。
タイムアウトになった集約がある場合にロジックを追加する方法があり、​failOnTimeout​ が ​true​ に設定されている場合でも、Mule 3 と同じ動作にはなりません。Mule 4 のアグリゲーターでは、タイムアウトになった集約がある場合にエラーが発生したり、通知がディスパッチされたりすることはありません。
Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - 集約が終了したのは、タイムアウトになったからなのか、または処理が完了したからなのかを示すインジケーターを保存する必要がある場合は、別の変数 ​`collection-splitter0-aggregator-complete-aggregation`​ を作成します。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。 予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約のタイムアウトは、Mule 3 のアグリゲーターに含まれているタイムアウトに設定します。 集約が完了したことを設定するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。(そのルートは、完了した集約によってのみ実行されます)。 もう 1 つフローを作成し、​`aggregator:aggregator-listener`​ を取得元として追加します。すべての集約 (完了してもしなくても) によってそのリスナーがトリガーされます。次に、集約は ​`vm:publish`​ 操作によってメインフローに送信されます。 - `vm:consume`​ 操作が ​`foreach`​ 要素の後に追加され、集約を待機します。値を読み取ったら、フローは実行を続行します。 - `collection-splitter0-aggregator-complete-aggregation`​ は集約が完了した場合にのみ true に設定されるので、ロジックを追加してその変数の値を (​`choice`​ と ​`when`​ で) チェックすることができます。これで、Mule 3 エラーハンドラーに以前追加された、タイムアウトエラーが発生した場合のロジックをシミュレートできます。 ### [](#その他の属性)その他の属性 すべてのスプリッターでは ​`enableCorrelation`​ 属性の設定が可能でした。 `enableCorrelation="NEVER"`​ 設定を移行する方法はありません。相関 ID は常に ​`foreach`​ 要素によってコレクションから処理されたイベントに設定されます。 式のスプリッター (​``​) では、​`evaluator`​ と ​`custom-evaluator`​ という 2 つの属性の設定が可能でした。式のエバリュエーターは設定できなくなりました。DataWeave のみを使用できます。 ### [](#使用可能なスプリッターの移行)使用可能なスプリッターの移行 Mule 3 には以下のスプリッターがありました。その中には、移行するためにはロジックを追加する必要があるものと、まったく移行できないものがあります。 - `collection-splitter`​: メインの例で定義されたとおり。 - `custom-splitter`​: Mule 4 ではカスタムクラスの使用が許されていないので、このスプリッターは移行できません。 - `splitter`​ (式のスプリッター): 使用される式は、​`foreach`​ 要素の ​`collection`​ 属性として設定します。 - Mule 3: `` - Mule 4: `` - `map-splitter`​ : DataWeave 式 ​`#[dw::core::Objects::entrySet(payload)]`​ は ​`foreach`​ 要素の ​`collection`​ 属性として使用します。 - Mule 3: `` - Mule 4: `` - `message-chunk-splitter`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ### [](#アグリゲーター)アグリゲーター Mule 3 のアグリゲーターで許可されていたほとんどのパラメーターは、Mule 4 では許可されていません。 - `timeout`​: 新しいアグリゲーターで timeout パラメーターを設定できますが、相違点がいくつかあります。まず、時間単位を指定するために ​`timeoutUnit`​ も作成します。また、集約タイムアウトの動作は、Mule 4 のアグリゲーターでは大きく異なります。詳細は、​[「アグリゲーターモジュールリファレンス」](https://docs.mulesoft.com/jp/aggregators-module/latest/aggregators-module-reference)​を参照してください。 - `failOnTimeout`​: 使用できなくなりました。ただし、​[複雑な移行](#complex_migration)​で説明したとおり、同じような動作を実行することはできます。 - `processed-groups-object-store-ref`​: 処理されたグループは、別個のオブジェクトストアに保存されなくなりました。このパラメーターは許可されなくなりました。 - `event-groups-object-store-ref`​: Mule 4 のアグリゲーターでは、​`objectStore`​ 属性を使用してこのオブジェクトストアを設定できます。 - `persistentStores`​: 許可されなくなりました。永続的なオブジェクトストアが必要な場合、​`objectStore`​ 属性は永続的なオブジェクトストアの名前にします。 - `storePrefix`​: 許可されなくなりました。 ### [](#使用可能なアグリゲーターの移行)使用可能なアグリゲーターの移行 - `collection-aggregator`​: メインの例で定義されたとおりに移行します。 - `custom-aggregator`​: 移行できません。Mule 4 には、インターフェースのカスタム実装を追加する方法がありません。 - `message-chunk-aggregator`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ## [](#関連情報)関連情報 [アグリゲーターモジュール](https://docs.mulesoft.com/jp/aggregators-module/latest/) [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/for-each-scope-concept) [For Each スコープリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/for-each-scope-concept) # スプリッターとアグリゲーターの移行 スプリッターは Mule 4 ではサポートされなくなりました。要素のコレクションを順次処理する場合は、​[For Each コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/for-each-scope-concept)​を使用します。 [アグリゲーター](https://docs.mulesoft.com/jp/aggregators-module/latest/)​はかなり動作が異なりますが、別個のモジュールとして Mule 4 に残されています。 ## [](#スプリッター)スプリッター Mule 3 のスプリッターと Mule 4 の For Each コンポーネントの主な違いは、​`foreach`​ 要素はスコープであるということです。つまり反復される要素を処理するために使用されるコンポーネントは ​`foreach`​ 内に定義する必要があります。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` また、​`foreach`​ 要素は、処理されたすべての値の結果を含むコレクションを返しません。代わりに、入力として受け取った同じコレクションを返します。したがって、上記の例の動作は同じではありません。 Mule 3 のアグリゲーターがあるかどうかは関係ありません。処理された値の結果を保存するには、Mule 4 のアグリゲーターを使用する必要があります。 ### [](#単純な移行)単純な移行 移行のデフォルトの形式は次のとおりです。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約の完了後に結果を保存するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。 - `foreach`​ 要素の後のペイロードは、受け取った入力と同じになるので、​`set-payload`​ を使用して、ペイロードを ​`aggregation-complete`​ ルートの内側に定義された変数の保存値として設定します。 ### [](#complex_migration)複雑な移行 スプリッターとアグリゲーターを使用する Mule 3 設定では、場合によってはさらにパラメーターが追加されることがあります。そのため、Mule 4 で Mule 3 の動作を実行する場合は移行がやや複雑になります。 Mule 3 のアグリゲーターでは、​`timeout`​ と ​`failOnTimeout`​ という 2 つの属性を設定することができました。​`timeout`​ 属性 (0 より大きい値を持つ) がある場合、移行は以下の例のようになります。
タイムアウトになった集約がある場合にロジックを追加する方法があり、​failOnTimeout​ が ​true​ に設定されている場合でも、Mule 3 と同じ動作にはなりません。Mule 4 のアグリゲーターでは、タイムアウトになった集約がある場合にエラーが発生したり、通知がディスパッチされたりすることはありません。
Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - 集約が終了したのは、タイムアウトになったからなのか、または処理が完了したからなのかを示すインジケーターを保存する必要がある場合は、別の変数 ​`collection-splitter0-aggregator-complete-aggregation`​ を作成します。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。 予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約のタイムアウトは、Mule 3 のアグリゲーターに含まれているタイムアウトに設定します。 集約が完了したことを設定するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。(そのルートは、完了した集約によってのみ実行されます)。 もう 1 つフローを作成し、​`aggregator:aggregator-listener`​ を取得元として追加します。すべての集約 (完了してもしなくても) によってそのリスナーがトリガーされます。次に、集約は ​`vm:publish`​ 操作によってメインフローに送信されます。 - `vm:consume`​ 操作が ​`foreach`​ 要素の後に追加され、集約を待機します。値を読み取ったら、フローは実行を続行します。 - `collection-splitter0-aggregator-complete-aggregation`​ は集約が完了した場合にのみ true に設定されるので、ロジックを追加してその変数の値を (​`choice`​ と ​`when`​ で) チェックすることができます。これで、Mule 3 エラーハンドラーに以前追加された、タイムアウトエラーが発生した場合のロジックをシミュレートできます。 ### [](#その他の属性)その他の属性 すべてのスプリッターでは ​`enableCorrelation`​ 属性の設定が可能でした。 `enableCorrelation="NEVER"`​ 設定を移行する方法はありません。相関 ID は常に ​`foreach`​ 要素によってコレクションから処理されたイベントに設定されます。 式のスプリッター (​``​) では、​`evaluator`​ と ​`custom-evaluator`​ という 2 つの属性の設定が可能でした。式のエバリュエーターは設定できなくなりました。DataWeave のみを使用できます。 ### [](#使用可能なスプリッターの移行)使用可能なスプリッターの移行 Mule 3 には以下のスプリッターがありました。その中には、移行するためにはロジックを追加する必要があるものと、まったく移行できないものがあります。 - `collection-splitter`​: メインの例で定義されたとおり。 - `custom-splitter`​: Mule 4 ではカスタムクラスの使用が許されていないので、このスプリッターは移行できません。 - `splitter`​ (式のスプリッター): 使用される式は、​`foreach`​ 要素の ​`collection`​ 属性として設定します。 - Mule 3: `` - Mule 4: `` - `map-splitter`​ : DataWeave 式 ​`#[dw::core::Objects::entrySet(payload)]`​ は ​`foreach`​ 要素の ​`collection`​ 属性として使用します。 - Mule 3: `` - Mule 4: `` - `message-chunk-splitter`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ### [](#アグリゲーター)アグリゲーター Mule 3 のアグリゲーターで許可されていたほとんどのパラメーターは、Mule 4 では許可されていません。 - `timeout`​: 新しいアグリゲーターで timeout パラメーターを設定できますが、相違点がいくつかあります。まず、時間単位を指定するために ​`timeoutUnit`​ も作成します。また、集約タイムアウトの動作は、Mule 4 のアグリゲーターでは大きく異なります。詳細は、​[「アグリゲーターモジュールリファレンス」](https://docs.mulesoft.com/jp/aggregators-module/latest/aggregators-module-reference)​を参照してください。 - `failOnTimeout`​: 使用できなくなりました。ただし、​[複雑な移行](#complex_migration)​で説明したとおり、同じような動作を実行することはできます。 - `processed-groups-object-store-ref`​: 処理されたグループは、別個のオブジェクトストアに保存されなくなりました。このパラメーターは許可されなくなりました。 - `event-groups-object-store-ref`​: Mule 4 のアグリゲーターでは、​`objectStore`​ 属性を使用してこのオブジェクトストアを設定できます。 - `persistentStores`​: 許可されなくなりました。永続的なオブジェクトストアが必要な場合、​`objectStore`​ 属性は永続的なオブジェクトストアの名前にします。 - `storePrefix`​: 許可されなくなりました。 ### [](#使用可能なアグリゲーターの移行)使用可能なアグリゲーターの移行 - `collection-aggregator`​: メインの例で定義されたとおりに移行します。 - `custom-aggregator`​: 移行できません。Mule 4 には、インターフェースのカスタム実装を追加する方法がありません。 - `message-chunk-aggregator`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ## [](#関連情報)関連情報 [アグリゲーターモジュール](https://docs.mulesoft.com/jp/aggregators-module/latest/) [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/for-each-scope-concept) [For Each スコープリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/for-each-scope-concept) # スプリッターとアグリゲーターの移行 スプリッターは Mule 4 ではサポートされなくなりました。要素のコレクションを順次処理する場合は、​[For Each コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/for-each-scope-concept)​を使用します。 [アグリゲーター](https://docs.mulesoft.com/jp/aggregators-module/latest/)​はかなり動作が異なりますが、別個のモジュールとして Mule 4 に残されています。 ## [](#スプリッター)スプリッター Mule 3 のスプリッターと Mule 4 の For Each コンポーネントの主な違いは、​`foreach`​ 要素はスコープであるということです。つまり反復される要素を処理するために使用されるコンポーネントは ​`foreach`​ 内に定義する必要があります。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` また、​`foreach`​ 要素は、処理されたすべての値の結果を含むコレクションを返しません。代わりに、入力として受け取った同じコレクションを返します。したがって、上記の例の動作は同じではありません。 Mule 3 のアグリゲーターがあるかどうかは関係ありません。処理された値の結果を保存するには、Mule 4 のアグリゲーターを使用する必要があります。 ### [](#単純な移行)単純な移行 移行のデフォルトの形式は次のとおりです。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約の完了後に結果を保存するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。 - `foreach`​ 要素の後のペイロードは、受け取った入力と同じになるので、​`set-payload`​ を使用して、ペイロードを ​`aggregation-complete`​ ルートの内側に定義された変数の保存値として設定します。 ### [](#complex_migration)複雑な移行 スプリッターとアグリゲーターを使用する Mule 3 設定では、場合によってはさらにパラメーターが追加されることがあります。そのため、Mule 4 で Mule 3 の動作を実行する場合は移行がやや複雑になります。 Mule 3 のアグリゲーターでは、​`timeout`​ と ​`failOnTimeout`​ という 2 つの属性を設定することができました。​`timeout`​ 属性 (0 より大きい値を持つ) がある場合、移行は以下の例のようになります。
タイムアウトになった集約がある場合にロジックを追加する方法があり、​failOnTimeout​ が ​true​ に設定されている場合でも、Mule 3 と同じ動作にはなりません。Mule 4 のアグリゲーターでは、タイムアウトになった集約がある場合にエラーが発生したり、通知がディスパッチされたりすることはありません。
Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - 集約が終了したのは、タイムアウトになったからなのか、または処理が完了したからなのかを示すインジケーターを保存する必要がある場合は、別の変数 ​`collection-splitter0-aggregator-complete-aggregation`​ を作成します。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。 予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約のタイムアウトは、Mule 3 のアグリゲーターに含まれているタイムアウトに設定します。 集約が完了したことを設定するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。(そのルートは、完了した集約によってのみ実行されます)。 もう 1 つフローを作成し、​`aggregator:aggregator-listener`​ を取得元として追加します。すべての集約 (完了してもしなくても) によってそのリスナーがトリガーされます。次に、集約は ​`vm:publish`​ 操作によってメインフローに送信されます。 - `vm:consume`​ 操作が ​`foreach`​ 要素の後に追加され、集約を待機します。値を読み取ったら、フローは実行を続行します。 - `collection-splitter0-aggregator-complete-aggregation`​ は集約が完了した場合にのみ true に設定されるので、ロジックを追加してその変数の値を (​`choice`​ と ​`when`​ で) チェックすることができます。これで、Mule 3 エラーハンドラーに以前追加された、タイムアウトエラーが発生した場合のロジックをシミュレートできます。 ### [](#その他の属性)その他の属性 すべてのスプリッターでは ​`enableCorrelation`​ 属性の設定が可能でした。 `enableCorrelation="NEVER"`​ 設定を移行する方法はありません。相関 ID は常に ​`foreach`​ 要素によってコレクションから処理されたイベントに設定されます。 式のスプリッター (​``​) では、​`evaluator`​ と ​`custom-evaluator`​ という 2 つの属性の設定が可能でした。式のエバリュエーターは設定できなくなりました。DataWeave のみを使用できます。 ### [](#使用可能なスプリッターの移行)使用可能なスプリッターの移行 Mule 3 には以下のスプリッターがありました。その中には、移行するためにはロジックを追加する必要があるものと、まったく移行できないものがあります。 - `collection-splitter`​: メインの例で定義されたとおり。 - `custom-splitter`​: Mule 4 ではカスタムクラスの使用が許されていないので、このスプリッターは移行できません。 - `splitter`​ (式のスプリッター): 使用される式は、​`foreach`​ 要素の ​`collection`​ 属性として設定します。 - Mule 3: `` - Mule 4: `` - `map-splitter`​ : DataWeave 式 ​`#[dw::core::Objects::entrySet(payload)]`​ は ​`foreach`​ 要素の ​`collection`​ 属性として使用します。 - Mule 3: `` - Mule 4: `` - `message-chunk-splitter`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ### [](#アグリゲーター)アグリゲーター Mule 3 のアグリゲーターで許可されていたほとんどのパラメーターは、Mule 4 では許可されていません。 - `timeout`​: 新しいアグリゲーターで timeout パラメーターを設定できますが、相違点がいくつかあります。まず、時間単位を指定するために ​`timeoutUnit`​ も作成します。また、集約タイムアウトの動作は、Mule 4 のアグリゲーターでは大きく異なります。詳細は、​[「アグリゲーターモジュールリファレンス」](https://docs.mulesoft.com/jp/aggregators-module/latest/aggregators-module-reference)​を参照してください。 - `failOnTimeout`​: 使用できなくなりました。ただし、​[複雑な移行](#complex_migration)​で説明したとおり、同じような動作を実行することはできます。 - `processed-groups-object-store-ref`​: 処理されたグループは、別個のオブジェクトストアに保存されなくなりました。このパラメーターは許可されなくなりました。 - `event-groups-object-store-ref`​: Mule 4 のアグリゲーターでは、​`objectStore`​ 属性を使用してこのオブジェクトストアを設定できます。 - `persistentStores`​: 許可されなくなりました。永続的なオブジェクトストアが必要な場合、​`objectStore`​ 属性は永続的なオブジェクトストアの名前にします。 - `storePrefix`​: 許可されなくなりました。 ### [](#使用可能なアグリゲーターの移行)使用可能なアグリゲーターの移行 - `collection-aggregator`​: メインの例で定義されたとおりに移行します。 - `custom-aggregator`​: 移行できません。Mule 4 には、インターフェースのカスタム実装を追加する方法がありません。 - `message-chunk-aggregator`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ## [](#関連情報)関連情報 [アグリゲーターモジュール](https://docs.mulesoft.com/jp/aggregators-module/latest/) [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/for-each-scope-concept) [For Each スコープリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/for-each-scope-concept) # スプリッターとアグリゲーターの移行 スプリッターは Mule 4 ではサポートされなくなりました。要素のコレクションを順次処理する場合は、​[For Each コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/for-each-scope-concept)​を使用します。 [アグリゲーター](https://docs.mulesoft.com/jp/aggregators-module/latest/)​はかなり動作が異なりますが、別個のモジュールとして Mule 4 に残されています。 ## [](#スプリッター)スプリッター Mule 3 のスプリッターと Mule 4 の For Each コンポーネントの主な違いは、​`foreach`​ 要素はスコープであるということです。つまり反復される要素を処理するために使用されるコンポーネントは ​`foreach`​ 内に定義する必要があります。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` また、​`foreach`​ 要素は、処理されたすべての値の結果を含むコレクションを返しません。代わりに、入力として受け取った同じコレクションを返します。したがって、上記の例の動作は同じではありません。 Mule 3 のアグリゲーターがあるかどうかは関係ありません。処理された値の結果を保存するには、Mule 4 のアグリゲーターを使用する必要があります。 ### [](#単純な移行)単純な移行 移行のデフォルトの形式は次のとおりです。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約の完了後に結果を保存するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。 - `foreach`​ 要素の後のペイロードは、受け取った入力と同じになるので、​`set-payload`​ を使用して、ペイロードを ​`aggregation-complete`​ ルートの内側に定義された変数の保存値として設定します。 ### [](#complex_migration)複雑な移行 スプリッターとアグリゲーターを使用する Mule 3 設定では、場合によってはさらにパラメーターが追加されることがあります。そのため、Mule 4 で Mule 3 の動作を実行する場合は移行がやや複雑になります。 Mule 3 のアグリゲーターでは、​`timeout`​ と ​`failOnTimeout`​ という 2 つの属性を設定することができました。​`timeout`​ 属性 (0 より大きい値を持つ) がある場合、移行は以下の例のようになります。
タイムアウトになった集約がある場合にロジックを追加する方法があり、​failOnTimeout​ が ​true​ に設定されている場合でも、Mule 3 と同じ動作にはなりません。Mule 4 のアグリゲーターでは、タイムアウトになった集約がある場合にエラーが発生したり、通知がディスパッチされたりすることはありません。
Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - 集約が終了したのは、タイムアウトになったからなのか、または処理が完了したからなのかを示すインジケーターを保存する必要がある場合は、別の変数 ​`collection-splitter0-aggregator-complete-aggregation`​ を作成します。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。 予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約のタイムアウトは、Mule 3 のアグリゲーターに含まれているタイムアウトに設定します。 集約が完了したことを設定するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。(そのルートは、完了した集約によってのみ実行されます)。 もう 1 つフローを作成し、​`aggregator:aggregator-listener`​ を取得元として追加します。すべての集約 (完了してもしなくても) によってそのリスナーがトリガーされます。次に、集約は ​`vm:publish`​ 操作によってメインフローに送信されます。 - `vm:consume`​ 操作が ​`foreach`​ 要素の後に追加され、集約を待機します。値を読み取ったら、フローは実行を続行します。 - `collection-splitter0-aggregator-complete-aggregation`​ は集約が完了した場合にのみ true に設定されるので、ロジックを追加してその変数の値を (​`choice`​ と ​`when`​ で) チェックすることができます。これで、Mule 3 エラーハンドラーに以前追加された、タイムアウトエラーが発生した場合のロジックをシミュレートできます。 ### [](#その他の属性)その他の属性 すべてのスプリッターでは ​`enableCorrelation`​ 属性の設定が可能でした。 `enableCorrelation="NEVER"`​ 設定を移行する方法はありません。相関 ID は常に ​`foreach`​ 要素によってコレクションから処理されたイベントに設定されます。 式のスプリッター (​``​) では、​`evaluator`​ と ​`custom-evaluator`​ という 2 つの属性の設定が可能でした。式のエバリュエーターは設定できなくなりました。DataWeave のみを使用できます。 ### [](#使用可能なスプリッターの移行)使用可能なスプリッターの移行 Mule 3 には以下のスプリッターがありました。その中には、移行するためにはロジックを追加する必要があるものと、まったく移行できないものがあります。 - `collection-splitter`​: メインの例で定義されたとおり。 - `custom-splitter`​: Mule 4 ではカスタムクラスの使用が許されていないので、このスプリッターは移行できません。 - `splitter`​ (式のスプリッター): 使用される式は、​`foreach`​ 要素の ​`collection`​ 属性として設定します。 - Mule 3: `` - Mule 4: `` - `map-splitter`​ : DataWeave 式 ​`#[dw::core::Objects::entrySet(payload)]`​ は ​`foreach`​ 要素の ​`collection`​ 属性として使用します。 - Mule 3: `` - Mule 4: `` - `message-chunk-splitter`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ### [](#アグリゲーター)アグリゲーター Mule 3 のアグリゲーターで許可されていたほとんどのパラメーターは、Mule 4 では許可されていません。 - `timeout`​: 新しいアグリゲーターで timeout パラメーターを設定できますが、相違点がいくつかあります。まず、時間単位を指定するために ​`timeoutUnit`​ も作成します。また、集約タイムアウトの動作は、Mule 4 のアグリゲーターでは大きく異なります。詳細は、​[「アグリゲーターモジュールリファレンス」](https://docs.mulesoft.com/jp/aggregators-module/latest/aggregators-module-reference)​を参照してください。 - `failOnTimeout`​: 使用できなくなりました。ただし、​[複雑な移行](#complex_migration)​で説明したとおり、同じような動作を実行することはできます。 - `processed-groups-object-store-ref`​: 処理されたグループは、別個のオブジェクトストアに保存されなくなりました。このパラメーターは許可されなくなりました。 - `event-groups-object-store-ref`​: Mule 4 のアグリゲーターでは、​`objectStore`​ 属性を使用してこのオブジェクトストアを設定できます。 - `persistentStores`​: 許可されなくなりました。永続的なオブジェクトストアが必要な場合、​`objectStore`​ 属性は永続的なオブジェクトストアの名前にします。 - `storePrefix`​: 許可されなくなりました。 ### [](#使用可能なアグリゲーターの移行)使用可能なアグリゲーターの移行 - `collection-aggregator`​: メインの例で定義されたとおりに移行します。 - `custom-aggregator`​: 移行できません。Mule 4 には、インターフェースのカスタム実装を追加する方法がありません。 - `message-chunk-aggregator`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ## [](#関連情報)関連情報 [アグリゲーターモジュール](https://docs.mulesoft.com/jp/aggregators-module/latest/) [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/for-each-scope-concept) [For Each スコープリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/for-each-scope-concept) # スプリッターとアグリゲーターの移行 スプリッターは Mule 4 ではサポートされなくなりました。要素のコレクションを順次処理する場合は、​[For Each コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/for-each-scope-concept)​を使用します。 [アグリゲーター](https://docs.mulesoft.com/jp/aggregators-module/latest/)​はかなり動作が異なりますが、別個のモジュールとして Mule 4 に残されています。 ## [](#スプリッター)スプリッター Mule 3 のスプリッターと Mule 4 の For Each コンポーネントの主な違いは、​`foreach`​ 要素はスコープであるということです。つまり反復される要素を処理するために使用されるコンポーネントは ​`foreach`​ 内に定義する必要があります。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` また、​`foreach`​ 要素は、処理されたすべての値の結果を含むコレクションを返しません。代わりに、入力として受け取った同じコレクションを返します。したがって、上記の例の動作は同じではありません。 Mule 3 のアグリゲーターがあるかどうかは関係ありません。処理された値の結果を保存するには、Mule 4 のアグリゲーターを使用する必要があります。 ### [](#単純な移行)単純な移行 移行のデフォルトの形式は次のとおりです。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約の完了後に結果を保存するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。 - `foreach`​ 要素の後のペイロードは、受け取った入力と同じになるので、​`set-payload`​ を使用して、ペイロードを ​`aggregation-complete`​ ルートの内側に定義された変数の保存値として設定します。 ### [](#complex_migration)複雑な移行 スプリッターとアグリゲーターを使用する Mule 3 設定では、場合によってはさらにパラメーターが追加されることがあります。そのため、Mule 4 で Mule 3 の動作を実行する場合は移行がやや複雑になります。 Mule 3 のアグリゲーターでは、​`timeout`​ と ​`failOnTimeout`​ という 2 つの属性を設定することができました。​`timeout`​ 属性 (0 より大きい値を持つ) がある場合、移行は以下の例のようになります。
タイムアウトになった集約がある場合にロジックを追加する方法があり、​failOnTimeout​ が ​true​ に設定されている場合でも、Mule 3 と同じ動作にはなりません。Mule 4 のアグリゲーターでは、タイムアウトになった集約がある場合にエラーが発生したり、通知がディスパッチされたりすることはありません。
Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - 集約が終了したのは、タイムアウトになったからなのか、または処理が完了したからなのかを示すインジケーターを保存する必要がある場合は、別の変数 ​`collection-splitter0-aggregator-complete-aggregation`​ を作成します。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。 予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約のタイムアウトは、Mule 3 のアグリゲーターに含まれているタイムアウトに設定します。 集約が完了したことを設定するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。(そのルートは、完了した集約によってのみ実行されます)。 もう 1 つフローを作成し、​`aggregator:aggregator-listener`​ を取得元として追加します。すべての集約 (完了してもしなくても) によってそのリスナーがトリガーされます。次に、集約は ​`vm:publish`​ 操作によってメインフローに送信されます。 - `vm:consume`​ 操作が ​`foreach`​ 要素の後に追加され、集約を待機します。値を読み取ったら、フローは実行を続行します。 - `collection-splitter0-aggregator-complete-aggregation`​ は集約が完了した場合にのみ true に設定されるので、ロジックを追加してその変数の値を (​`choice`​ と ​`when`​ で) チェックすることができます。これで、Mule 3 エラーハンドラーに以前追加された、タイムアウトエラーが発生した場合のロジックをシミュレートできます。 ### [](#その他の属性)その他の属性 すべてのスプリッターでは ​`enableCorrelation`​ 属性の設定が可能でした。 `enableCorrelation="NEVER"`​ 設定を移行する方法はありません。相関 ID は常に ​`foreach`​ 要素によってコレクションから処理されたイベントに設定されます。 式のスプリッター (​``​) では、​`evaluator`​ と ​`custom-evaluator`​ という 2 つの属性の設定が可能でした。式のエバリュエーターは設定できなくなりました。DataWeave のみを使用できます。 ### [](#使用可能なスプリッターの移行)使用可能なスプリッターの移行 Mule 3 には以下のスプリッターがありました。その中には、移行するためにはロジックを追加する必要があるものと、まったく移行できないものがあります。 - `collection-splitter`​: メインの例で定義されたとおり。 - `custom-splitter`​: Mule 4 ではカスタムクラスの使用が許されていないので、このスプリッターは移行できません。 - `splitter`​ (式のスプリッター): 使用される式は、​`foreach`​ 要素の ​`collection`​ 属性として設定します。 - Mule 3: `` - Mule 4: `` - `map-splitter`​ : DataWeave 式 ​`#[dw::core::Objects::entrySet(payload)]`​ は ​`foreach`​ 要素の ​`collection`​ 属性として使用します。 - Mule 3: `` - Mule 4: `` - `message-chunk-splitter`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ### [](#アグリゲーター)アグリゲーター Mule 3 のアグリゲーターで許可されていたほとんどのパラメーターは、Mule 4 では許可されていません。 - `timeout`​: 新しいアグリゲーターで timeout パラメーターを設定できますが、相違点がいくつかあります。まず、時間単位を指定するために ​`timeoutUnit`​ も作成します。また、集約タイムアウトの動作は、Mule 4 のアグリゲーターでは大きく異なります。詳細は、​[「Aggregators Module リファレンス」](https://docs.mulesoft.com/jp/aggregators-module/latest/aggregators-module-reference)​を参照してください。 - `failOnTimeout`​: 使用できなくなりました。ただし、​[複雑な移行](#complex_migration)​で説明したとおり、同じような動作を実行することはできます。 - `processed-groups-object-store-ref`​: 処理されたグループは、別個のオブジェクトストアに保存されなくなりました。このパラメーターは許可されなくなりました。 - `event-groups-object-store-ref`​: Mule 4 のアグリゲーターでは、​`objectStore`​ 属性を使用してこのオブジェクトストアを設定できます。 - `persistentStores`​: 許可されなくなりました。永続的なオブジェクトストアが必要な場合、​`objectStore`​ 属性は永続的なオブジェクトストアの名前にします。 - `storePrefix`​: 許可されなくなりました。 ### [](#使用可能なアグリゲーターの移行)使用可能なアグリゲーターの移行 - `collection-aggregator`​: メインの例で定義されたとおりに移行します。 - `custom-aggregator`​: 移行できません。Mule 4 には、インターフェースのカスタム実装を追加する方法がありません。 - `message-chunk-aggregator`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ## [](#関連情報)関連情報 [Aggregators Module](https://docs.mulesoft.com/jp/aggregators-module/latest/) [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/for-each-scope-concept) [For Each スコープリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/for-each-scope-concept) # スプリッターとアグリゲーターの移行 スプリッターは Mule 4 ではサポートされなくなりました。要素のコレクションを順次処理する場合は、​[For Each コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/for-each-scope-concept)​を使用します。 [アグリゲーター](https://docs.mulesoft.com/jp/aggregators-module/latest/)​はかなり動作が異なりますが、別個のモジュールとして Mule 4 に残されています。 ## [](#スプリッター)スプリッター Mule 3 のスプリッターと Mule 4 の For Each コンポーネントの主な違いは、​`foreach`​ 要素はスコープであるということです。つまり反復される要素を処理するために使用されるコンポーネントは ​`foreach`​ 内に定義する必要があります。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` また、​`foreach`​ 要素は、処理されたすべての値の結果を含むコレクションを返しません。代わりに、入力として受け取った同じコレクションを返します。したがって、上記の例の動作は同じではありません。 Mule 3 のアグリゲーターがあるかどうかは関係ありません。処理された値の結果を保存するには、Mule 4 のアグリゲーターを使用する必要があります。 ### [](#単純な移行)単純な移行 移行のデフォルトの形式は次のとおりです。 Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約の完了後に結果を保存するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。 - `foreach`​ 要素の後のペイロードは、受け取った入力と同じになるので、​`set-payload`​ を使用して、ペイロードを ​`aggregation-complete`​ ルートの内側に定義された変数の保存値として設定します。 ### [](#complex_migration)複雑な移行 スプリッターとアグリゲーターを使用する Mule 3 設定では、場合によってはさらにパラメーターが追加されることがあります。そのため、Mule 4 で Mule 3 の動作を実行する場合は移行がやや複雑になります。 Mule 3 のアグリゲーターでは、​`timeout`​ と ​`failOnTimeout`​ という 2 つの属性を設定することができました。​`timeout`​ 属性 (0 より大きい値を持つ) がある場合、移行は以下の例のようになります。
タイムアウトになった集約がある場合にロジックを追加する方法があり、​failOnTimeout​ が ​true​ に設定されている場合でも、Mule 3 と同じ動作にはなりません。Mule 4 のアグリゲーターでは、タイムアウトになった集約がある場合にエラーが発生したり、通知がディスパッチされたりすることはありません。
Mule 3 の例 ```xml ... ... ``` Mule 4 の例 ```xml ... ... ... ``` この例では、 - コレクションのサイズを保存する変数 ​`collection-splitter0-group-size`​ を作成します。そうする必要があるのは、​`foreach`​ スコープの内側では、ペイロードは処理されるコレクションからの要素に対応するからです。 - 集約が終了したのは、タイムアウトになったからなのか、または処理が完了したからなのかを示すインジケーターを保存する必要がある場合は、別の変数 ​`collection-splitter0-aggregator-complete-aggregation`​ を作成します。 - `collection-splitter`​ と ​`collection-aggregator`​ の間にあるコンポーネントはすべて ​`foreach`​ スコープの内側にラップされます。 - すべての結果を保存するために、​`foreach`​ スコープの最後に ​`group-based-aggregator`​ が追加されます。 予期される集約のサイズは、​`collection-splitter0-group-size`​ 変数に保存される値に対応します。 集約のタイムアウトは、Mule 3 のアグリゲーターに含まれているタイムアウトに設定します。 集約が完了したことを設定するために、​`set-variable`​ が ​`aggregation-complete`​ の内側に追加されます。(そのルートは、完了した集約によってのみ実行されます)。 もう 1 つフローを作成し、​`aggregator:aggregator-listener`​ を取得元として追加します。すべての集約 (完了してもしなくても) によってそのリスナーがトリガーされます。次に、集約は ​`vm:publish`​ 操作によってメインフローに送信されます。 - `vm:consume`​ 操作が ​`foreach`​ 要素の後に追加され、集約を待機します。値を読み取ったら、フローは実行を続行します。 - `collection-splitter0-aggregator-complete-aggregation`​ は集約が完了した場合にのみ true に設定されるので、ロジックを追加してその変数の値を (​`choice`​ と ​`when`​ で) チェックすることができます。これで、Mule 3 エラーハンドラーに以前追加された、タイムアウトエラーが発生した場合のロジックをシミュレートできます。 ### [](#その他の属性)その他の属性 すべてのスプリッターでは ​`enableCorrelation`​ 属性の設定が可能でした。 `enableCorrelation="NEVER"`​ 設定を移行する方法はありません。相関 ID は常に ​`foreach`​ 要素によってコレクションから処理されたイベントに設定されます。 式のスプリッター (​``​) では、​`evaluator`​ と ​`custom-evaluator`​ という 2 つの属性の設定が可能でした。式のエバリュエーターは設定できなくなりました。DataWeave のみを使用できます。 ### [](#使用可能なスプリッターの移行)使用可能なスプリッターの移行 Mule 3 には以下のスプリッターがありました。その中には、移行するためにはロジックを追加する必要があるものと、まったく移行できないものがあります。 - `collection-splitter`​: メインの例で定義されたとおり。 - `custom-splitter`​: Mule 4 ではカスタムクラスの使用が許されていないので、このスプリッターは移行できません。 - `splitter`​ (式のスプリッター): 使用される式は、​`foreach`​ 要素の ​`collection`​ 属性として設定します。 - Mule 3: `` - Mule 4: `` - `map-splitter`​ : DataWeave 式 ​`#[dw::core::Objects::entrySet(payload)]`​ は ​`foreach`​ 要素の ​`collection`​ 属性として使用します。 - Mule 3: `` - Mule 4: `` - `message-chunk-splitter`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ### [](#アグリゲーター)アグリゲーター Mule 3 のアグリゲーターで許可されていたほとんどのパラメーターは、Mule 4 では許可されていません。 - `timeout`​: 新しいアグリゲーターで timeout パラメーターを設定できますが、相違点がいくつかあります。まず、時間単位を指定するために ​`timeoutUnit`​ も作成します。また、集約タイムアウトの動作は、Mule 4 のアグリゲーターでは大きく異なります。詳細は、​[「Aggregators Module リファレンス」](https://docs.mulesoft.com/jp/aggregators-module/latest/aggregators-module-reference)​を参照してください。 - `failOnTimeout`​: 使用できなくなりました。ただし、​[複雑な移行](#complex_migration)​で説明したとおり、同じような動作を実行することはできます。 - `processed-groups-object-store-ref`​: 処理されたグループは、別個のオブジェクトストアに保存されなくなりました。このパラメーターは許可されなくなりました。 - `event-groups-object-store-ref`​: Mule 4 のアグリゲーターでは、​`objectStore`​ 属性を使用してこのオブジェクトストアを設定できます。 - `persistentStores`​: 許可されなくなりました。永続的なオブジェクトストアが必要な場合、​`objectStore`​ 属性は永続的なオブジェクトストアの名前にします。 - `storePrefix`​: 許可されなくなりました。 ### [](#使用可能なアグリゲーターの移行)使用可能なアグリゲーターの移行 - `collection-aggregator`​: メインの例で定義されたとおりに移行します。 - `custom-aggregator`​: 移行できません。Mule 4 には、インターフェースのカスタム実装を追加する方法がありません。 - `message-chunk-aggregator`​: 同じような動作は Mule 4 に存在しません。これは移行できません。 ## [](#関連情報)関連情報 [Aggregators Module](https://docs.mulesoft.com/jp/aggregators-module/latest/) [For Each スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/for-each-scope-concept) [For Each スコープリファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/for-each-scope-concept) # セキュアプロパティプレースホルダーの移行 Mule 3 では、セキュアプロパティプレースホルダーはセキュリティモジュールの一部でした。Mule 4 では、独自のセキュア設定プロパティモジュールで分離されました。 例: Mule 3 での完全なセキュアプロパティプレースホルダー ```xml ``` Mule 3 と Mule 4 の違い: - 他のコンポーネントの一貫性を保つため、Mule 3 の ​`location`​ 属性は Mule 4 では ​`file`​ に置き換えられました。 - Mule 3 では、​`location`​ は複数のファイルをカンマ (​`,`​) で区切って定義できます。Mule 4 では、トラブルを避けるため、できなくなりました。代わりに、各ファイルに ​``​ タグを定義する必要があります。 - ファイル間で重複するプロパティでは、Mule 3 では最後の定義が保持されます。Mule 4 モジュールでは最初の定義が保持されます。 - 暗号化属性 (​`mode`​ および ​`algorithm`​) は子タグ ​``​ で定義され、サポートされるアルゴリズムおよびモードは Mule 3 と 4 で同じです (​[「Mule 4 のセキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/secure-configuration-properties)​を参照)。 Mule 3 の完全な移行の例は次のようになります。 例: 完全な移行の例 ```xml ``` ## [](#see_also)関連情報 [Mule 4 のセキュア設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.3/secure-configuration-properties) # セキュアプロパティプレースホルダーの移行 Mule 3 では、セキュアプロパティプレースホルダーはセキュリティモジュールの一部でした。Mule 4 では、独自のセキュア設定プロパティモジュールで分離されました。 例: Mule 3 での完全なセキュアプロパティプレースホルダー ```xml ``` Mule 3 と Mule 4 の違い: - 他のコンポーネントの一貫性を保つため、Mule 3 の ​`location`​ 属性は Mule 4 では ​`file`​ に置き換えられました。 - Mule 3 では、​`location`​ は複数のファイルをカンマ (​`,`​) で区切って定義できます。Mule 4 では、トラブルを避けるため、できなくなりました。代わりに、各ファイルに ​``​ タグを定義する必要があります。 - ファイル間で重複するプロパティでは、Mule 3 では最後の定義が保持されます。Mule 4 モジュールでは最初の定義が保持されます。 - 暗号化属性 (​`mode`​ および ​`algorithm`​) は子タグ ​``​ で定義され、サポートされるアルゴリズムおよびモードは Mule 3 と 4 で同じです (​[「Mule 4 のセキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/secure-configuration-properties)​を参照)。 Mule 3 の完全な移行の例は次のようになります。 例: 完全な移行の例 ```xml ``` ## [](#see_also)関連情報 [Mule 4 のセキュア設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.4/secure-configuration-properties) # セキュアプロパティプレースホルダーの移行 Mule 3 では、セキュアプロパティプレースホルダーはセキュリティモジュールの一部でした。Mule 4 では、独自のセキュア設定プロパティモジュールで分離されました。 例: Mule 3 での完全なセキュアプロパティプレースホルダー ```xml ``` Mule 3 と Mule 4 の違い: - 他のコンポーネントの一貫性を保つため、Mule 3 の ​`location`​ 属性は Mule 4 では ​`file`​ に置き換えられました。 - Mule 3 では、​`location`​ は複数のファイルをカンマ (​`,`​) で区切って定義できます。Mule 4 では、トラブルを避けるため、できなくなりました。代わりに、各ファイルに ​``​ タグを定義する必要があります。 - ファイル間で重複するプロパティでは、Mule 3 では最後の定義が保持されます。Mule 4 モジュールでは最初の定義が保持されます。 - 暗号化属性 (​`mode`​ および ​`algorithm`​) は子タグ ​``​ で定義され、サポートされるアルゴリズムおよびモードは Mule 3 と 4 で同じです (​[「Mule 4 のセキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/secure-configuration-properties)​を参照)。 Mule 3 の完全な移行の例は次のようになります。 例: 完全な移行の例 ```xml ``` ## [](#see_also)関連情報 [Mule 4 のセキュア設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.5/secure-configuration-properties) # セキュアプロパティプレースホルダーの移行 Mule 3 では、セキュアプロパティプレースホルダーはセキュリティモジュールの一部でした。Mule 4 では、独自のセキュア設定プロパティモジュールで分離されました。 例: Mule 3 での完全なセキュアプロパティプレースホルダー ```xml ``` Mule 3 と Mule 4 の違い: - 他のコンポーネントの一貫性を保つため、Mule 3 の ​`location`​ 属性は Mule 4 では ​`file`​ に置き換えられました。 - Mule 3 では、​`location`​ は複数のファイルをカンマ (​`,`​) で区切って定義できます。Mule 4 では、トラブルを避けるため、できなくなりました。代わりに、各ファイルに ​``​ タグを定義する必要があります。 - ファイル間で重複するプロパティでは、Mule 3 では最後の定義が保持されます。Mule 4 モジュールでは最初の定義が保持されます。 - 暗号化属性 (​`mode`​ および ​`algorithm`​) は子タグ ​``​ で定義され、サポートされるアルゴリズムおよびモードは Mule 3 と 4 で同じです (​[「Mule 4 のセキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/secure-configuration-properties)​を参照)。 Mule 3 の完全な移行の例は次のようになります。 例: 完全な移行の例 ```xml ``` ## [](#see_also)関連情報 [Mule 4 のセキュア設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.6/secure-configuration-properties) # セキュアプロパティプレースホルダーの移行 Mule 3 では、セキュアプロパティプレースホルダーはセキュリティモジュールの一部でした。Mule 4 では、独自のセキュア設定プロパティモジュールで分離されました。 例: Mule 3 での完全なセキュアプロパティプレースホルダー ```xml ``` Mule 3 と Mule 4 の違い: - 他のコンポーネントの一貫性を保つため、Mule 3 の ​`location`​ 属性は Mule 4 では ​`file`​ に置き換えられました。 - Mule 3 では、​`location`​ は複数のファイルをカンマ (​`,`​) で区切って定義できます。Mule 4 では、トラブルを避けるため、できなくなりました。代わりに、各ファイルに ​``​ タグを定義する必要があります。 - ファイル間で重複するプロパティでは、Mule 3 では最後の定義が保持されます。Mule 4 モジュールでは最初の定義が保持されます。 - 暗号化属性 (​`mode`​ および ​`algorithm`​) は子タグ ​``​ で定義され、サポートされるアルゴリズムおよびモードは Mule 3 と 4 で同じです (​[「Mule 4 のセキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/secure-configuration-properties)​を参照)。 Mule 3 の完全な移行の例は次のようになります。 例: 完全な移行の例 ```xml ``` ## [](#see_also)関連情報 [Mule 4 のセキュア設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.7/secure-configuration-properties) # セキュアプロパティプレースホルダーの移行 Mule 3 では、セキュアプロパティプレースホルダーはセキュリティモジュールの一部でした。Mule 4 では、独自のセキュア設定プロパティモジュールで分離されました。 例: Mule 3 での完全なセキュアプロパティプレースホルダー ```xml ``` Mule 3 と Mule 4 の違い: - 他のコンポーネントの一貫性を保つため、Mule 3 の ​`location`​ 属性は Mule 4 では ​`file`​ に置き換えられました。 - Mule 3 では、​`location`​ は複数のファイルをカンマ (​`,`​) で区切って定義できます。Mule 4 では、トラブルを避けるため、できなくなりました。代わりに、各ファイルに ​``​ タグを定義する必要があります。 - ファイル間で重複するプロパティでは、Mule 3 では最後の定義が保持されます。Mule 4 モジュールでは最初の定義が保持されます。 - 暗号化属性 (​`mode`​ および ​`algorithm`​) は子タグ ​``​ で定義され、サポートされるアルゴリズムおよびモードは Mule 3 と 4 で同じです (​[「Mule 4 のセキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/secure-configuration-properties)​を参照)。 Mule 3 の完全な移行の例は次のようになります。 例: 完全な移行の例 ```xml ``` ## [](#see_also)関連情報 [Mule 4 のセキュア設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.8/secure-configuration-properties) # セキュアプロパティプレースホルダーの移行 Mule 3 では、セキュアプロパティプレースホルダーはセキュリティモジュールの一部でした。Mule 4 では、独自のセキュア設定プロパティモジュールで分離されました。 例: Mule 3 での完全なセキュアプロパティプレースホルダー ```xml ``` Mule 3 と Mule 4 の違い: - 他のコンポーネントの一貫性を保つため、Mule 3 の ​`location`​ 属性は Mule 4 では ​`file`​ に置き換えられました。 - Mule 3 では、​`location`​ は複数のファイルをカンマ (​`,`​) で区切って定義できます。Mule 4 では、トラブルを避けるため、できなくなりました。代わりに、各ファイルに ​``​ タグを定義する必要があります。 - ファイル間で重複するプロパティでは、Mule 3 では最後の定義が保持されます。Mule 4 モジュールでは最初の定義が保持されます。 - 暗号化属性 (​`mode`​ および ​`algorithm`​) は子タグ ​``​ で定義され、サポートされるアルゴリズムおよびモードは Mule 3 と 4 で同じです (​[「Mule 4 のセキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/secure-configuration-properties)​を参照)。 Mule 3 の完全な移行の例は次のようになります。 例: 完全な移行の例 ```xml ``` ## [](#see_also)関連情報 [Mule 4 のセキュア設定プロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.9/secure-configuration-properties) # セキュア設定プロパティ 設定プロパティはアプリケーションの別のセキュリティレベルとして暗号化できます。セキュア設定プロパティを作成するには、次のプロセスを確認してください。 1. セキュア設定プロパティファイルを作成します。 2. 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。 3. Mule Secure Configuration Properties Extension Module を使用してプロジェクトでファイルを設定します。ファイルでは復号化キーを参照するか、復号化キーが含まれている必要があります。 ## [](#属性)属性 セキュアなプロパティファイルを作成してそのプロパティを定義する前に、プロセスで使用されるセキュア設定プロパティ属性と暗号化属性を確認してください。
Table 1. セキュア設定プロパティの属性
属性名 説明

Name (名前)

グローバルセキュア設定プロパティの一意の名前。

Key (キー)

プロパティ値をロック解除するために指定する単語またはフレーズ。たとえば、​${production.myproperty}​ と指定すると、Mule Runtime Engine は実行時にキーを要求します。

ファイル

キーが復号化するファイルの場所。

Encoding (エンコード)

キーがロック解除するファイルのエンコーディング。デフォルト値は UTF-8 です。

File Level Encryption (ファイルレベル暗号化)

ファイル全体を暗号化する場合は ​true​ に設定します。デフォルト値は ​false​ です。
Table 2. セキュア設定プロパティの暗号化属性
属性名 説明

Algorithm (アルゴリズム)

プロパティのコンテンツを暗号化するために使用するアルゴリズムの種別。完全なリストについては、​サポートされているアルゴリズム​を参照してください。

Mode (モード)

Mule Runtime Engine が単一のキーでブロック暗号を繰り返し使用するためのプロシージャーです。完全なリストについては、​サポートされているモード​を参照してください。

Use random IVs (ランダム IV の使用)

ランダム初期化ベクトル (IV) を使用するには、この属性を ​true​ にします。このオプションを ​true​ に設定すると、復号化アルゴリズムは復号化操作中に IV が暗号テキストの先頭に追加されていると見なします。
## [](#セキュア設定プロパティファイルを作成する)セキュア設定プロパティファイルを作成する 設定プロパティをセキュアにする最初のタスクは、プロパティを定義する YAML 設定ファイル (​`.yaml`​) または Spring 形式のプロパティファイル (​`.properties`​) を作成することです。Mule Secure Configuration Properties Extension Module を使用すれば、YAML またはプロパティファイル種別を設定できます。 セキュア設定プロパティファイルは、Mule プロジェクトの ​`src/main/resources`​ で、または絶対パスを使用して作成できます。 ## [](#ファイルでセキュア設定プロパティを定義する)ファイルでセキュア設定プロパティを定義する 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。このファイルには、Mule アプリケーション内のどの場所でも使用できる暗号化された値と暗号化されていない値の両方を含むことができます。
オペレーティングシステムへのアクセスをセキュアにしてください。​ps​ コマンドを実行できたり、Java コンソールを表示できたりするユーザーであれば、Mule アプリケーションのメモリに格納されている復号化された値を見ることができてしまうからです。
次の ​`file1.yaml`​ の例には、暗号化された設定プロパティ値と暗号化されていない設定プロパティ値が含まれています。 encrypted: value1: "!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\]" value2: "!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\]" testPropertyA: "testValueA" testPropertyB: "testValueB"
暗号化された値は、文字列として読めるように引用符で囲む必要があります。
次の ​`file1.properties`​ の例には、前の例で使用した設定プロパティが含まれていますが、Spring 形式のプロパティファイルを使用しています。 encrypted.value1=!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\] encrypted.value2=!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\] testPropertyA=testValueA testPropertyB=testValueB ## [](#secure_props_tool)セキュアプロパティツールを使用してプロパティを暗号化する テキスト文字列、プロパティファイル内の値、またはプロパティファイルのすべてのコンテンツを暗号化または復号化するには、セキュアプロパティツールを使用します。 この記事で説明するすべての機能を使用するには、このツールの使用可能な最新バージョンを使用していることを確認してください。 ダウンロードリンク: [セキュアプロパティツール Jar ファイル](https://docs.mulesoft.com/jp/mule-runtime/4.3/_attachments/secure-properties-tool.jar)​。 最新リリース: 2022 年 9 月 14 日。 構文は、以前のバージョンから変更されています。問題を回避するため、この記事で指定されている構文と JAR ファイルを使用してください。 受け入れられるすべてのパラメーターの完全なリストおよび定義については、​[パラメーターリファレンス](#parameter-reference)​を参照してください。 ### [](#テキスト文字列を暗号化する)テキスト文字列を暗号化する 次の構文を使用して、パラメーターとして指定されたテキスト文字列を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - テキスト文字列を処理するようにツールを設定するには、​``​ を ​`string`​ に設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次の操作を実行するとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ string \ encrypt \ Blowfish \ CBC \ mulesoft \ "some value to encrypt" ``` この場合、ツールで次の内容が返されます。 ```console.linenums 8q5e1+jy0cND2iV2WPThahmz6XsDwB6Z ``` ### [](#ファイルを暗号化する)ファイルを暗号化する 文字列の処理に加えて、暗号化ツールでは ​`.yaml`​ または ​`.properties`​ ファイルも処理されます。プロパティファイル内の値、またはファイルのすべてのコンテンツを暗号化または復号化できます。 #### [](#ファイル内のプロパティを暗号化する)ファイル内のプロパティを暗号化する 次の構文を使用して、プロパティファイル内のすべての値を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```yaml properties: example1: value: "![qCReIPK3jcqD7WR84ISSIQ==]" example2: "![En8lII21ZHrdIaINw0+mSA==]" ``` #### [](#ファイルのすべてのコンテンツを暗号化する)ファイルのすべてのコンテンツを暗号化する 次の構文を使用して、プロパティファイルのすべてのコンテンツを暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file-level`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file-level \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```txt k/J1EHyxJagOcyQELoaqIDCzzKc1bLGJiHY2dv6jzuhtVpP1LTlgK3y8EH7OkK5iuuu8kik3P5dCDMixZXwn/EV6xbUwLFKnEb4x1pUX6aopLP/KULm0pQ== ``` ### [](#parameter-reference)パラメーターリファレンス
パラメーター 説明

<method>

暗号化または復号化メソッドを設定します。可能な値:

string​

パラメーター ​<value>​ として指定された 1 つのテキスト文字列を暗号化します。

file​

パラメーター ​<input file>​ として指定されたプロパティファイルで設定された各プロパティの値を暗号化します。

file-level​

​<input file>​ として指定されたプロパティファイルのすべてのコンテンツを暗号化します。

<operation>

実行する操作を設定します。可能な値:

encrypt​

暗号化する操作を設定します。

decrypt​

復号化する操作を設定します。

<algorithm>

操作中に使用するアルゴリズムを指定します。
完全なリストについては、​サポートされているアルゴリズム​を参照してください。

<mode>

操作中に使用するモードを指定します。
完全なリストについては、​サポートされているモード​を参照してください。

<key>

操作中にファイルまたは値をロックまたはロック解除するために使用する単語を指定します。

  • キーで ​$​ 文字を使用する場合、その前に ​\​ を置く必要があります。 たとえば、キー ​myKey#$%123​ を使用するには、​<key>​ パラメーターを ​myKey#\$%123​ として指定する必要があります。

  • Java Cryptography Extension (JCE) バージョン 1.8.0_161​ 以降、AES キーの長さは 32 文字 (256 ビット) 以上が必要になりました。

<value>

string​ 操作中に暗号化または復号化される文字列値を指定します。

<use random IV>

操作中にランダム初期化ベクトル (IV) が使用されるかどうかを指定します。

<input file>

file​ または ​file-level​ 操作中に暗号化または復号化されるプロパティファイルを指定します。

<output file>

file​ または ​file-level​ 操作後に作成される暗号化または復号化されたプロパティファイルを指定します。
## [](#プロジェクトでファイルを設定する)プロジェクトでファイルを設定する セキュアなプロパティファイルは、 [Exchange](https://anypoint.mulesoft.com/exchange/com.mulesoft.modules/mule-secure-configuration-property-module/)​ から入手できる Mule Secure Configuration Properties Extension Module を使用して、スタンドアロン XML と Anypoint Studio のどちらでも設定できます。 ### [](#xml-で-extension-module-を使用してファイルを設定する)XML で Extension Module を使用してファイルを設定する XML フローで、モジュール ​``​ を使用してファイルを設定します。次の例を確認してください。 **デフォルト値を使用したセキュア設定プロパティ** ```xml ``` - デフォルト値を使用する場合でも ​``​ タグは必要です。 - プレフィックス ​`secure::`​ はキーの読み込みに必要です。
セキュアなプロパティファイル内の値にアクセスするには、値が暗号化されていない場合でも ​secure::​ プレフィックスを使用する必要があります。これにより、設定全体を変更しなくてもファイル (または環境) を切り替えることができます。
- デプロイメント時に、復号化キーはシステム環境変数 ​`runtime.property`​ として Mule Runtime Engine に渡されます。このプロパティは、​`file1.yaml`​ ファイルに格納されている値を暗号化するために使用するのとまったく同じキーでなければなりません。 - デフォルトの暗号化アルゴリズムとモードが使用されます。 - たとえば、​`property.key1`​ プロパティの実際の (復号化された) 値が ​`"property"`​ であれば、​`prop`​ プロパティの値は ​`"my-property"`​ となります。 ``​ タグで追加の属性を設定して、暗号化アルゴリズムや暗号化モードを変更することもできます。 **カスタム値を使用したセキュア設定プロパティ** ```xml ``` 上の例で、​``​ タグでは ​`AES`​ アルゴリズム、​`CBC`​ モード、​`random IV`​ を使用しています。

<secure-properties:config>​ で設定された ​key​、​algorithm​、​mode​、​useRandomIVs​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
### [](#studio-で-extension-module-を使用してファイルを設定する)Studio で Extension Module を使用してファイルを設定する Anypoint Studio を使用してアプリケーションを開発している場合、Mule アプリケーションで連動関係として追加したモジュールを使用してセキュア設定プロパティを作成することもできます。 #### [](#extension-module-をインストールする)Extension Module をインストールする 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] セクションに移動します。 3. **\[Search in Exchange (Exchange 内を検索)\]**​ をクリックします。 4. \[Add Module to Project (モジュールをプロジェクトに追加)\] ウィンドウの ​**\[Type a search term to look up in Exchange (検索語を入力して Exchange 内で検索)\]**​ ボックスで、​**\[Mule Secure Configuration Property Extension (Mule セキュア設定プロパティ拡張)\]**​ を検索します。 5. リストでモジュール名を選択します。 6. **\[Add (追加)\]**​ に続いて ​**\[Finish (完了)\]**​ をクリックします。 #### [](#セキュア設定プロパティをアプリケーションに追加して設定する)セキュア設定プロパティをアプリケーションに追加して設定する 1. Mule アプリケーションの設定ファイルに移動します。 2. **\[Global Elements (グローバル要素)\]**​ タブを選択します。 3. **\[Create (作成)\]**​ をクリックします。 4. **\[Secure Properties Config (セキュアプロパティ設定)\]**​ を選択します。 5. **\[File (ファイル)\]**​ の場所、​**\[Key (キー)\]**​、​**\[Algorithm (アルゴリズム)\]**​、​**\[Mode (モード)\]**​、​**\[Use random IV (ランダム IV の使用)\]**​、​**\[File level encryption (ファイルレベル暗号化)\]**​、​**\[Encoding (エンコード)\]**​ を使用してグローバル要素を設定します。 6. **\[OK\]**​ をクリックします。 ![設定の拡張](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-secure-config-properties-studio.png)

Secure Configuration Properties Module で設定された ​key​、​algorithm​、​mode​、​use random IV​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
#### [](#開発時にセキュア設定プロパティを確認する)開発時にセキュア設定プロパティを確認する Studio でアプリケーションを開発している場合、コネクタ接続をテストしてコネクタのセキュア設定プロパティが正しくセットアップされていることを確認できます。 次の例では、そのセキュアプロパティ (ユーザー名、パスワード、トークン) が ​`.yaml`​ ファイルで暗号化された Salesforce Connector 設定を示しています。 ![config extension2](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-secure-config-properties-studio2.png) 値が暗号化されていない場合でもセキュアなプロパティファイル内のすべての値にアクセスできるように、​`secure::`​ プレフィックスがプロパティ名の定義の前に追加されます。 **\[Test Connection (接続をテスト)\]**​ をクリックすれば、接続が期待どおりに機能していることを確認し、セキュアなプロパティが正常に読み取られることを保証できます。 ## [](#ファイルレベル暗号化)ファイルレベル暗号化 セキュア設定プロパティモジュールのバージョン 1.1.0 以降では、各プロパティの値だけでなく、ファイル全体を暗号化できるようになっています。XML または Anypoint Studio の両方でファイルを暗号化できます。 XML フローで、​`fileLevelEncryption`​ 属性を追加して ​`true`​ に設定します。 ```xml ``` Studio の \[Secure Configuration Properties (セキュア設定プロパティ)\] ウィンドウで、​**\[File level encryption (ファイルレベル暗号化)\]**​ に ​**\[True\]**​ を選択します。 ![config extension3](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-secure-config-properties-studio3.png) ## [](#セキュア設定プロパティのユースケース)セキュア設定プロパティのユースケース セキュア設定プロパティに関する次のユースケースを確認してください。このユースケースでは、フローで暗号化された値と暗号化されていない値を使用する方法、セキュア設定プロパティファイルを動的に設定する方法、複数の設定ファイルを使用する方法を学ぶことができます。 ### [](#暗号化された値と暗号化されていない値)暗号化された値と暗号化されていない値 次の例では、フローで暗号化された ​`encrypted.value1`​ 値を使用してペイロードを設定する方法を示しています。実行時には、復号化アルゴリズムによって ​`encrypted.value1`​ を復号化した値をメモリに格納します。 ```xml ``` 次の例では、フローで同じセキュアプロパティファイルから暗号化されていない値を使用する方法を示しています。 ```xml ``` ### [](#セキュア設定プロパティファイルを動的に設定する)セキュア設定プロパティファイルを動的に設定する 一般的な設定のユースケースとして、プロパティ (例: `env`​) によって使用するファイルを決定するようにファイルを設定することができます。 たとえば、開発フェーズ中に (暗号化できなかった) ​`development-properties`​ ファイルと (暗号化された値を使用する) 本番ファイルのどちらかを使用するように設定できます。 **環境ファイルが定義されたセキュア設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティの値によって、セキュア設定プロパティを読み込むために使用するファイルが決定されます。その ​`env`​ プロパティは、​`global property`​、システムプロパティ、または環境プロパティで設定することもできます。 **環境ファイルが定義されたセキュアなグローバル設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティのデフォルト値は ​`"dev"`​ になりますが、システムプロパティや環境プロパティで上書きすることはできます。Anypoint Studio では、この方法はメタデータの解決に​**必須**​となります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらのプロパティに連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 ### [](#複数の設定ファイルを操作する)複数の設定ファイルを操作する プロパティを読み込む設定ファイルを複数定義することができます。必要なのは、読み込みたい各ファイルに対して ​``​ タグを定義するだけです。各セキュア設定プロパティファイルは、それぞれの暗号化アルゴリズム、暗号化モード、そして暗号化/復号化キーによって独立して設定されます。これらの設定はファイル間で同じになるとは限りません。 次の例は、複数の設定ファイルの使用方法を示しています。 ```xml ``` ## [](#サポートされる設定ファイル種別)サポートされる設定ファイル種別 - Spring 形式のプロパティ: `.properties` - YAML: `.yaml` ## [](#supported_crypto)サポートされているアルゴリズムとモード ### [](#supported_algorithms)サポートされているアルゴリズム - AES (デフォルト) - Blowfish - DES - DESede - RC2 - RCA 次のアルゴリズムは、サポートが追加される [Java Cryptography Extension (JCE) プロバイダー](https://docs.oracle.com/cd/E19830-01/819-4712/ablsc/index.html)​を設定する場合のみ使用できます。 - Camellia - CAST5 - CAST6 - Noekeon - Rijndael - SEED - Serpent - Skipjack - TEA - Twofish - XTEA - RC5 - RC6 ### [](#supported_modes)サポートされているモード - CBC (デフォルト) - CFB - ECB - OFB ## [](#よくある質問と回答)よくある質問と回答 セキュア設定プロパティファイルについて学び、作成して、しばらく使用したら、トラブルシューティングおよびその最大限の活用法についてさらに疑問が生まれる可能性もあります。一般的な質問と回答をいくつか紹介します。「関連情報」でリンクしているトピックも参照してください。 **複数のファイルで同じプロパティを設定したらどうなりますか?** その場合は、最初に定義されたプロパティの値が実際のプロパティ値となります。 **以前に定義したセキュアプロパティに依存するセキュアプロパティを定義できますか?** はい。単に同じ構文を使用するだけです: `property=My dependent ${secure::dependent.property} value`​。 セキュア設定プロパティは他のセキュア設定プロパティには依存できますが、他の Mule 設定プロパティには依存できません。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties) # セキュア設定プロパティ 設定プロパティはアプリケーションの別のセキュリティレベルとして暗号化できます。セキュア設定プロパティを作成するには、次のプロセスを確認してください。 1. セキュア設定プロパティファイルを作成します。 2. 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。 3. Mule Secure Configuration Properties Extension Module を使用してプロジェクトでファイルを設定します。ファイルでは復号化キーを参照するか、復号化キーが含まれている必要があります。 ## [](#属性)属性 セキュアなプロパティファイルを作成してそのプロパティを定義する前に、プロセスで使用されるセキュア設定プロパティ属性と暗号化属性を確認してください。
Table 1. セキュア設定プロパティの属性
属性名 説明

Name (名前)

グローバルセキュア設定プロパティの一意の名前。

Key (キー)

プロパティ値をロック解除するために指定する単語またはフレーズ。たとえば、​${production.myproperty}​ と指定すると、Mule Runtime Engine は実行時にキーを要求します。

File (ファイル)

キーが復号化するファイルの場所。

Encoding (エンコード)

キーがロック解除するファイルのエンコード。デフォルト値は UTF-8 です。

File Level Encryption (ファイルレベル暗号化)

ファイル全体を暗号化する場合は ​true​ に設定します。デフォルト値は ​false​ です。
Table 2. セキュア設定プロパティの暗号化属性
属性名 説明

Algorithm (アルゴリズム)

プロパティのコンテンツを暗号化するために使用するアルゴリズムの種別。完全なリストについては、「​サポートされているアルゴリズム​」を参照してください。

Mode (モード)

Mule Runtime Engine が単一のキーでブロック暗号を繰り返し使用するためのプロシージャーです。完全なリストについては、「​サポートされているモード​」を参照してください。

Use random IVs (ランダム IV の使用)

ランダム初期化ベクトル (IV) を使用するには、この属性を ​true​ にします。このオプションを ​true​ に設定すると、復号化アルゴリズムは復号化操作中に IV が暗号テキストの先頭に追加されていると見なします。
## [](#セキュア設定プロパティファイルを作成する)セキュア設定プロパティファイルを作成する 設定プロパティをセキュアにする最初のタスクは、プロパティを定義する YAML 設定ファイル (​`.yaml`​) または Spring 形式のプロパティファイル (​`.properties`​) を作成することです。Mule Secure Configuration Properties Extension Module を使用すれば、YAML またはプロパティファイル種別を設定できます。 セキュア設定プロパティファイルは、Mule プロジェクトの ​`src/main/resources`​ で、または絶対パスを使用して作成できます。 ## [](#ファイルでセキュア設定プロパティを定義する)ファイルでセキュア設定プロパティを定義する 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。このファイルには、Mule アプリケーション内のどの場所でも使用できる暗号化された値と暗号化されていない値の両方を含むことができます。
オペレーティングシステムへのアクセスをセキュアにしてください。​ps​ コマンドを実行できたり、Java コンソールを表示できたりするユーザーであれば、Mule アプリケーションのメモリに格納されている復号化された値を見ることができてしまうからです。
次の ​`file1.yaml`​ の例には、暗号化された設定プロパティ値と暗号化されていない設定プロパティ値が含まれています。 encrypted: value1: "!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\]" value2: "!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\]" testPropertyA: "testValueA" testPropertyB: "testValueB"
暗号化された値は、文字列として読めるように引用符で囲む必要があります。
次の ​`file1.properties`​ の例には、前の例で使用した設定プロパティが含まれていますが、Spring 形式のプロパティファイルを使用しています。 encrypted.value1=!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\] encrypted.value2=!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\] testPropertyA=testValueA testPropertyB=testValueB ## [](#secure_props_tool)セキュアプロパティツールを使用してプロパティを暗号化する テキスト文字列、プロパティファイル内の値、またはプロパティファイルのすべてのコンテンツを暗号化または復号化するには、セキュアプロパティツールを使用します。 この記事で説明するすべての機能を使用するには、このツールの使用可能な最新バージョンを使用していることを確認してください。 ダウンロードリンク: [セキュアプロパティツール Jar ファイル](https://docs.mulesoft.com/jp/mule-runtime/4.4/_attachments/secure-properties-tool.jar)​。 最新リリース: 2022 年 9 月 14 日。 構文は、以前のバージョンから変更されています。問題を回避するため、この記事で指定されている構文と JAR ファイルを使用してください。 受け入れられるすべてのパラメーターの完全なリストおよび定義については、「​[\[パラメーターリファレンス\]](#パラメーターリファレンス)​」を参照してください。 ### [](#テキスト文字列を暗号化する)テキスト文字列を暗号化する 次の構文を使用して、パラメーターとして指定されたテキスト文字列を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - テキスト文字列を処理するようにツールを設定するには、​``​ を ​`string`​ に設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次の操作を実行するとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ string \ encrypt \ Blowfish \ CBC \ mulesoft \ "some value to encrypt" ``` この場合、ツールで次の内容が返されます。 ```console.linenums 8q5e1+jy0cND2iV2WPThahmz6XsDwB6Z ``` ### [](#ファイルを暗号化する)ファイルを暗号化する 文字列の処理に加えて、暗号化ツールでは ​`.yaml`​ または ​`.properties`​ ファイルも処理されます。プロパティファイル内の値、またはファイルのすべてのコンテンツを暗号化または復号化できます。 #### [](#ファイル内のプロパティを暗号化する)ファイル内のプロパティを暗号化する 次の構文を使用して、プロパティファイル内のすべての値を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```yaml properties: example1: value: "![qCReIPK3jcqD7WR84ISSIQ==]" example2: "![En8lII21ZHrdIaINw0+mSA==]" ``` #### [](#ファイルのすべてのコンテンツを暗号化する)ファイルのすべてのコンテンツを暗号化する 次の構文を使用して、プロパティファイルのすべてのコンテンツを暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file-level`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file-level \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```txt k/J1EHyxJagOcyQELoaqIDCzzKc1bLGJiHY2dv6jzuhtVpP1LTlgK3y8EH7OkK5iuuu8kik3P5dCDMixZXwn/EV6xbUwLFKnEb4x1pUX6aopLP/KULm0pQ== ``` ### [](#parameter-reference)パラメーターリファレンス
パラメーター 説明

<method>

暗号化または復号化メソッドを設定します。可能な値:

string​

パラメーター ​<value>​ として指定された 1 つのテキスト文字列を暗号化します。

file​

パラメーター ​<input file>​ として指定されたプロパティファイルで設定された各プロパティの値を暗号化します。

file-level​

​<input file>​ として指定されたプロパティファイルのすべてのコンテンツを暗号化します。

<operation>

実行する操作を設定します。可能な値:

encrypt​

暗号化する操作を設定します。

decrypt​

復号化する操作を設定します。

<algorithm>

操作中に使用するアルゴリズムを指定します。
完全なリストについては、「​サポートされているアルゴリズム​」を参照してください。

<mode>

操作中に使用するモードを指定します。
完全なリストについては、「​サポートされているモード​」を参照してください。

<key>

操作中にファイルまたは値をロックまたはロック解除するために使用する単語を指定します。

  • キーで ​$​ 文字を使用する場合、その前に ​\​ を置く必要があります。 たとえば、キー ​myKey#$%123​ を使用するには、​<key>​ パラメーターを ​myKey#\$%123​ として指定する必要があります。

  • Java Cryptography Extension (JCE) バージョン 1.8.0_161​ 以降、AES キーの長さは 32 文字 (256 ビット) 以上が必要になりました。

<value>

string​ 操作中に暗号化または復号化される文字列値を指定します。

<use random IV>

操作中にランダム初期化ベクトル (IV) が使用されるかどうかを指定します。

<input file>

file​ または ​file-level​ 操作中に暗号化または復号化されるプロパティファイルを指定します。

<output file>

file​ または ​file-level​ 操作後に作成される暗号化または復号化されたプロパティファイルを指定します。
## [](#プロジェクトでファイルを設定する)プロジェクトでファイルを設定する セキュアなプロパティファイルは、 [Exchange](https://anypoint.mulesoft.com/exchange/com.mulesoft.modules/mule-secure-configuration-property-module/)​ から入手できる Mule Secure Configuration Properties Extension Module を使用して、スタンドアロン XML と Anypoint Studio のどちらでも設定できます。 ### [](#xml-で-extension-module-を使用してファイルを設定する)XML で Extension Module を使用してファイルを設定する XML フローで、モジュール ​``​ を使用してファイルを設定します。次の例を確認してください。 **デフォルト値を使用したセキュア設定プロパティ** ```xml ``` - デフォルト値を使用する場合でも ​``​ タグは必要です。 - プレフィックス ​`secure::`​ はキーの読み込みに必要です。
セキュアなプロパティファイル内の値にアクセスするには、値が暗号化されていない場合でも ​secure::​ プレフィックスを使用する必要があります。これにより、設定全体を変更しなくてもファイル (または環境) を切り替えることができます。
- デプロイメント時に、復号化キーはシステム環境変数 ​`runtime.property`​ として Mule Runtime Engine に渡されます。このプロパティは、​`file1.yaml`​ ファイルに格納されている値を暗号化するために使用するのとまったく同じキーでなければなりません。 - デフォルトの暗号化アルゴリズムとモードが使用されます。 - たとえば、​`property.key1`​ プロパティの実際の (復号化された) 値が ​`"property"`​ であれば、​`prop`​ プロパティの値は ​`"my-property"`​ となります。 ``​ タグで追加の属性を設定して、暗号化アルゴリズムや暗号化モードを変更することもできます。 **カスタム値を使用したセキュア設定プロパティ** ```xml ``` 上の例で、​``​ タグでは ​`AES`​ アルゴリズム、​`CBC`​ モード、​`random IV`​ を使用しています。

<secure-properties:config>​ で設定された ​key​、​algorithm​、​mode​、​useRandomIVs​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
### [](#studio-で-extension-module-を使用してファイルを設定する)Studio で Extension Module を使用してファイルを設定する Anypoint Studio を使用してアプリケーションを開発している場合、Mule アプリケーションで連動関係として追加したモジュールを使用してセキュア設定プロパティを作成することもできます。 #### [](#extension-module-をインストールする)Extension Module をインストールする 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] セクションに移動します。 3. **\[Search in Exchange (Exchange 内を検索)\]**​ をクリックします。 4. \[Add Module to Project (モジュールをプロジェクトに追加)\] ウィンドウの ​**\[Type a search term to look up in Exchange (検索語を入力して Exchange 内で検索)\]**​ ボックスで、​**\[Mule Secure Configuration Property Extension (Mule セキュア設定プロパティ拡張)\]**​ を検索します。 5. リストでモジュール名を選択します。 6. **\[Add (追加)\]**​ に続いて ​**\[Finish (完了)\]**​ をクリックします。 #### [](#セキュア設定プロパティをアプリケーションに追加して設定する)セキュア設定プロパティをアプリケーションに追加して設定する 1. Mule アプリケーションの設定ファイルに移動します。 2. **\[Global Elements (グローバル要素)\]**​ タブを選択します。 3. **\[Create (作成)\]**​ をクリックします。 4. **\[Secure Properties Config (セキュアプロパティ設定)\]**​ を選択します。 5. **\[File (ファイル)\]**​ の場所、​**\[Key (キー)\]**​、​**\[Algorithm (アルゴリズム)\]**​、​**\[Mode (モード)\]**​、​**\[Use random IV (ランダム IV の使用)\]**​、​**\[File level encryption (ファイルレベル暗号化)\]**​、​**\[Encoding (エンコード)\]**​ を使用してグローバル要素を設定します。 6. **\[OK\]**​ をクリックします。 ![設定の拡張](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-secure-config-properties-studio.png)

Secure Configuration Properties Module で設定された ​key​、​algorithm​、​mode​、​use random IV​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
#### [](#開発時にセキュア設定プロパティを確認する)開発時にセキュア設定プロパティを確認する Studio でアプリケーションを開発している場合、コネクタ接続をテストしてコネクタのセキュア設定プロパティが正しくセットアップされていることを確認できます。 次の例では、そのセキュアプロパティ (ユーザー名、パスワード、トークン) が ​`.yaml`​ ファイルで暗号化された Salesforce Connector 設定を示しています。 ![config extension2](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-secure-config-properties-studio2.png) 値が暗号化されていない場合でもセキュアなプロパティファイル内のすべての値にアクセスできるように、​`secure::`​ プレフィックスがプロパティ名の定義の前に追加されます。 **\[Test Connection (接続をテスト)\]**​ をクリックすれば、接続が期待どおりに機能していることを確認し、セキュアなプロパティが正常に読み取られることを保証できます。 ## [](#ファイルレベル暗号化)ファイルレベル暗号化 Secure Configuration Properties Module のバージョン 1.1.0 以降では、各プロパティの値だけでなく、ファイル全体を暗号化できるようになっています。XML または Anypoint Studio の両方でファイルを暗号化できます。 XML フローで、​`fileLevelEncryption`​ 属性を追加して ​`true`​ に設定します。 ```xml ``` Studio の \[Secure Configuration Properties (セキュア設定プロパティ)\] ウィンドウで、​**\[File level encryption (ファイルレベル暗号化)\]**​ に ​**\[True\]**​ を選択します。 ![config extension3](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-secure-config-properties-studio3.png) ## [](#セキュア設定プロパティのユースケース)セキュア設定プロパティのユースケース セキュア設定プロパティに関する次のユースケースを確認してください。このユースケースでは、フローで暗号化された値と暗号化されていない値を使用する方法、セキュア設定プロパティファイルを動的に設定する方法、複数の設定ファイルを使用する方法を学ぶことができます。 ### [](#暗号化された値と暗号化されていない値)暗号化された値と暗号化されていない値 次の例では、フローで暗号化された ​`encrypted.value1`​ 値を使用してペイロードを設定する方法を示しています。実行時には、復号化アルゴリズムによって ​`encrypted.value1`​ を復号化した値をメモリに格納します。 ```xml ``` 次の例では、フローで同じセキュアプロパティファイルから暗号化されていない値を使用する方法を示しています。 ```xml ``` ### [](#セキュア設定プロパティファイルを動的に設定する)セキュア設定プロパティファイルを動的に設定する 一般的な設定のユースケースとして、プロパティ (例: `env`​) によって使用するファイルを決定するようにファイルを設定することができます。 たとえば、開発フェーズ中に (暗号化できなかった) ​`development-properties`​ ファイルと (暗号化された値を使用する) 本番ファイルのどちらかを使用するように設定できます。 **環境ファイルが定義されたセキュア設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティの値によって、セキュア設定プロパティを読み込むために使用するファイルが決定されます。その ​`env`​ プロパティは、​`global property`​、システムプロパティ、または環境プロパティで設定することもできます。 **環境ファイルが定義されたセキュアなグローバル設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティのデフォルト値は ​`"dev"`​ になりますが、システムプロパティや環境プロパティで上書きすることはできます。Anypoint Studio では、この方法はメタデータの解決に​**必須**​となります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらのプロパティに連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 ### [](#複数の設定ファイルを操作する)複数の設定ファイルを操作する プロパティを読み込む設定ファイルを複数定義することができます。必要なのは、読み込みたい各ファイルに対して ​``​ タグを定義するだけです。各セキュア設定プロパティファイルは、それぞれの暗号化アルゴリズム、暗号化モード、そして暗号化/復号化キーによって独立して設定されます。これらの設定はファイル間で同じになるとは限りません。 次の例は、複数の設定ファイルの使用方法を示しています。 ```xml ``` ## [](#サポートされる設定ファイル種別)サポートされる設定ファイル種別 - Spring 形式のプロパティ: `.properties` - YAML: `.yaml` ## [](#supported_crypto)サポートされているアルゴリズムとモード ### [](#supported_algorithms)サポートされているアルゴリズム - AES (デフォルト) - Blowfish - DES - DESede - RC2 - RCA 次のアルゴリズムは、サポートが追加される [Java Cryptography Extension (JCE) プロバイダー](https://docs.oracle.com/cd/E19830-01/819-4712/ablsc/index.html)​を設定する場合のみ使用できます。 - Camellia - CAST5 - CAST6 - Noekeon - Rijndael - SEED - Serpent - Skipjack - TEA - Twofish - XTEA - RC5 - RC6 ### [](#supported_modes)サポートされているモード - CBC (デフォルト) - CFB - ECB - OFB ## [](#よくある質問と回答)よくある質問と回答 セキュア設定プロパティファイルについて学び、作成して、しばらく使用したら、トラブルシューティングおよびその最大限の活用法についてさらに疑問が生まれる可能性もあります。一般的な質問と回答をいくつか紹介します。「関連情報」でリンクしているトピックも参照してください。 **複数のファイルで同じプロパティを設定したらどうなりますか?** その場合は、最初に定義されたプロパティの値が実際のプロパティ値となります。 **以前に定義したセキュアプロパティに依存するセキュアプロパティを定義できますか?** はい。単に同じ構文を使用するだけです: `property=My dependent ${secure::dependent.property} value`​。 セキュア設定プロパティは他のセキュア設定プロパティには依存できますが、他の Mule 設定プロパティには依存できません。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties) - [Define and Secure Properties for a Mule Application in Anypoint Code Builder (Anypoint Code Builder での Mule アプリケーションのプロパティの定義と保護)](https://docs.mulesoft.com/jp/anypoint-code-builder/int-create-secure-configs) # セキュア設定プロパティ 設定プロパティはアプリケーションの別のセキュリティレベルとして暗号化できます。セキュア設定プロパティを作成するには、次のプロセスを確認してください。 1. セキュア設定プロパティファイルを作成します。 2. 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。 3. Mule Secure Configuration Properties Extension Module を使用してプロジェクトでファイルを設定します。ファイルでは復号化キーを参照するか、復号化キーが含まれている必要があります。 ## [](#属性)属性 セキュアなプロパティファイルを作成してそのプロパティを定義する前に、プロセスで使用されるセキュア設定プロパティ属性と暗号化属性を確認してください。
Table 1. セキュア設定プロパティの属性
属性名 説明

Name (名前)

グローバルセキュア設定プロパティの一意の名前。

Key (キー)

プロパティ値をロック解除するために指定する単語またはフレーズ。たとえば、​${production.myproperty}​ と指定すると、Mule Runtime Engine は実行時にキーを要求します。

ファイル

キーが復号化するファイルの場所。

Encoding (エンコード)

キーがロック解除するファイルのエンコード。デフォルト値は UTF-8 です。

File Level Encryption (ファイルレベル暗号化)

ファイル全体を暗号化する場合は ​true​ に設定します。デフォルト値は ​false​ です。
Table 2. セキュア設定プロパティの暗号化属性
属性名 説明

Algorithm (アルゴリズム)

プロパティのコンテンツを暗号化するために使用するアルゴリズムの種別。完全なリストについては、​サポートされているアルゴリズム​を参照してください。

Mode (モード)

Mule Runtime Engine が単一のキーでブロック暗号を繰り返し使用するためのプロシージャーです。完全なリストについては、​サポートされているモード​を参照してください。

Use random IVs (ランダム IV の使用)

ランダム初期化ベクトル (IV) を使用するには、この属性を ​true​ にします。このオプションを ​true​ に設定すると、復号化アルゴリズムは復号化操作中に IV が暗号テキストの先頭に追加されていると見なします。
## [](#セキュア設定プロパティファイルを作成する)セキュア設定プロパティファイルを作成する 設定プロパティをセキュアにする最初のタスクは、プロパティを定義する YAML 設定ファイル (​`.yaml`​) または Spring 形式のプロパティファイル (​`.properties`​) を作成することです。Mule Secure Configuration Properties Extension Module を使用すれば、YAML またはプロパティファイル種別を設定できます。 セキュア設定プロパティファイルは、Mule プロジェクトの ​`src/main/resources`​ で、または絶対パスを使用して作成できます。 ## [](#ファイルでセキュア設定プロパティを定義する)ファイルでセキュア設定プロパティを定義する 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。このファイルには、Mule アプリケーション内のどの場所でも使用できる暗号化された値と暗号化されていない値の両方を含むことができます。
オペレーティングシステムへのアクセスをセキュアにしてください。​ps​ コマンドを実行できたり、Java コンソールを表示できたりするユーザーであれば、Mule アプリケーションのメモリに格納されている復号化された値を見ることができてしまうからです。
次の ​`file1.yaml`​ の例には、暗号化された設定プロパティ値と暗号化されていない設定プロパティ値が含まれています。 encrypted: value1: "!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\]" value2: "!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\]" testPropertyA: "testValueA" testPropertyB: "testValueB"
暗号化された値は、文字列として読めるように引用符で囲む必要があります。
次の ​`file1.properties`​ の例には、前の例で使用した設定プロパティが含まれていますが、Spring 形式のプロパティファイルを使用しています。 encrypted.value1=!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\] encrypted.value2=!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\] testPropertyA=testValueA testPropertyB=testValueB ## [](#secure_props_tool)セキュアプロパティツールを使用してプロパティを暗号化する テキスト文字列、プロパティファイル内の値、またはプロパティファイルのすべてのコンテンツを暗号化または復号化するには、セキュアプロパティツールを使用します。 この記事で説明するすべての機能を使用するには、このツールの使用可能な最新バージョンを使用していることを確認してください。 ダウンロードリンク: [セキュアプロパティツール Jar ファイル](https://docs.mulesoft.com/jp/mule-runtime/4.5/_attachments/secure-properties-tool.jar)​。 最新リリース: 2022 年 9 月 14 日。 構文は、以前のバージョンから変更されています。問題を回避するため、この記事で指定されている構文と JAR ファイルを使用してください。 受け入れられるすべてのパラメーターの完全なリストおよび定義については、​[パラメーターリファレンス](#parameter-reference)​を参照してください。 ### [](#テキスト文字列を暗号化する)テキスト文字列を暗号化する 次の構文を使用して、パラメーターとして指定されたテキスト文字列を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - テキスト文字列を処理するようにツールを設定するには、​``​ を ​`string`​ に設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次の操作を実行するとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ string \ encrypt \ Blowfish \ CBC \ mulesoft \ "some value to encrypt" ``` この場合、ツールで次の内容が返されます。 ```console.linenums 8q5e1+jy0cND2iV2WPThahmz6XsDwB6Z ``` ### [](#ファイルを暗号化する)ファイルを暗号化する 文字列の処理に加えて、暗号化ツールでは ​`.yaml`​ または ​`.properties`​ ファイルも処理されます。プロパティファイル内の値、またはファイルのすべてのコンテンツを暗号化または復号化できます。 #### [](#ファイル内のプロパティを暗号化する)ファイル内のプロパティを暗号化する 次の構文を使用して、プロパティファイル内のすべての値を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```yaml properties: example1: value: "![qCReIPK3jcqD7WR84ISSIQ==]" example2: "![En8lII21ZHrdIaINw0+mSA==]" ``` #### [](#ファイルのすべてのコンテンツを暗号化する)ファイルのすべてのコンテンツを暗号化する 次の構文を使用して、プロパティファイルのすべてのコンテンツを暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file-level`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file-level \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```txt k/J1EHyxJagOcyQELoaqIDCzzKc1bLGJiHY2dv6jzuhtVpP1LTlgK3y8EH7OkK5iuuu8kik3P5dCDMixZXwn/EV6xbUwLFKnEb4x1pUX6aopLP/KULm0pQ== ``` ### [](#parameter-reference)パラメーターリファレンス
パラメーター 説明

<method>

暗号化または復号化メソッドを設定します。可能な値:

string​

パラメーター ​<value>​ として指定された 1 つのテキスト文字列を暗号化します。

file​

パラメーター ​<input file>​ として指定されたプロパティファイルで設定された各プロパティの値を暗号化します。

file-level​

​<input file>​ として指定されたプロパティファイルのすべてのコンテンツを暗号化します。

<operation>

実行する操作を設定します。可能な値:

encrypt​

暗号化する操作を設定します。

decrypt​

復号化する操作を設定します。

<algorithm>

操作中に使用するアルゴリズムを指定します。
完全なリストについては、​サポートされているアルゴリズム​を参照してください。

<mode>

操作中に使用するモードを指定します。
完全なリストについては、​サポートされているモード​を参照してください。

<key>

操作中にファイルまたは値をロックまたはロック解除するために使用する単語を指定します。

  • キーで ​$​ 文字を使用する場合、その前に ​\​ を置く必要があります。 たとえば、キー ​myKey#$%123​ を使用するには、​<key>​ パラメーターを ​myKey#\$%123​ として指定する必要があります。

  • Java Cryptography Extension (JCE) バージョン 1.8.0_161​ 以降、AES キーの長さは 32 文字 (128 ビット) にする必要があります。

<value>

string​ 操作中に暗号化または復号化される文字列値を指定します。

<use random IV>

操作中にランダム初期化ベクトル (IV) が使用されるかどうかを指定します。

<input file>

file​ または ​file-level​ 操作中に暗号化または復号化されるプロパティファイルを指定します。

<output file>

file​ または ​file-level​ 操作後に作成される暗号化または復号化されたプロパティファイルを指定します。
## [](#プロジェクトでファイルを設定する)プロジェクトでファイルを設定する セキュアなプロパティファイルは、 [Exchange](https://anypoint.mulesoft.com/exchange/com.mulesoft.modules/mule-secure-configuration-property-module/)​ から入手できる Mule Secure Configuration Properties Extension Module を使用して、スタンドアロン XML と Anypoint Studio のどちらでも設定できます。 ### [](#xml-で-extension-module-を使用してファイルを設定する)XML で Extension Module を使用してファイルを設定する XML フローで、モジュール ​``​ を使用してファイルを設定します。次の例を確認してください。 **デフォルト値を使用したセキュア設定プロパティ** ```xml ``` - デフォルト値を使用する場合でも ​``​ タグは必要です。 - プレフィックス ​`secure::`​ はキーの読み込みに必要です。
セキュアなプロパティファイル内の値にアクセスするには、値が暗号化されていない場合でも ​secure::​ プレフィックスを使用する必要があります。これにより、設定全体を変更しなくてもファイル (または環境) を切り替えることができます。
- デプロイメント時に、復号化キーはシステム環境変数 ​`runtime.property`​ として Mule Runtime Engine に渡されます。このプロパティは、​`file1.yaml`​ ファイルに格納されている値を暗号化するために使用するのとまったく同じキーでなければなりません。 - デフォルトの暗号化アルゴリズムとモードが使用されます。 - たとえば、​`property.key1`​ プロパティの実際の (復号化された) 値が ​`"property"`​ であれば、​`prop`​ プロパティの値は ​`"my-property"`​ となります。 ``​ タグで追加の属性を設定して、暗号化アルゴリズムや暗号化モードを変更することもできます。 **カスタム値を使用したセキュア設定プロパティ** ```xml ``` 上の例で、​``​ タグでは ​`AES`​ アルゴリズム、​`CBC`​ モード、​`random IV`​ を使用しています。

<secure-properties:config>​ で設定された ​key​、​algorithm​、​mode​、​useRandomIVs​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
### [](#studio-で-extension-module-を使用してファイルを設定する)Studio で Extension Module を使用してファイルを設定する Anypoint Studio を使用してアプリケーションを開発している場合、Mule アプリケーションで連動関係として追加したモジュールを使用してセキュア設定プロパティを作成することもできます。 #### [](#extension-module-をインストールする)Extension Module をインストールする 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] セクションに移動します。 3. **\[Search in Exchange (Exchange 内を検索)\]**​ をクリックします。 4. \[Add Module to Project (モジュールをプロジェクトに追加)\] ウィンドウの ​**\[Type a search term to look up in Exchange (検索語を入力して Exchange 内で検索)\]**​ ボックスで、​**\[Mule Secure Configuration Property Extension (Mule セキュア設定プロパティ拡張)\]**​ を検索します。 5. リストでモジュール名を選択します。 6. **\[Add (追加)\]**​ に続いて ​**\[Finish (完了)\]**​ をクリックします。 #### [](#セキュア設定プロパティをアプリケーションに追加して設定する)セキュア設定プロパティをアプリケーションに追加して設定する 1. Mule アプリケーションの設定ファイルに移動します。 2. **\[Global Elements (グローバル要素)\]**​ タブを選択します。 3. **\[Create (作成)\]**​ をクリックします。 4. **\[Secure Properties Config (セキュアプロパティ設定)\]**​ を選択します。 5. **\[File (ファイル)\]**​ の場所、​**\[Key (キー)\]**​、​**\[Algorithm (アルゴリズム)\]**​、​**\[Mode (モード)\]**​、​**\[Use random IV (ランダム IV の使用)\]**​、​**\[File level encryption (ファイルレベル暗号化)\]**​、​**\[Encoding (エンコード)\]**​ を使用してグローバル要素を設定します。 6. **\[OK\]**​ をクリックします。 ![設定の拡張](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-secure-config-properties-studio.png)

Secure Configuration Properties Module で設定された ​key​、​algorithm​、​mode​、​use random IV​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
#### [](#開発時にセキュア設定プロパティを確認する)開発時にセキュア設定プロパティを確認する Studio でアプリケーションを開発している場合、コネクタ接続をテストしてコネクタのセキュア設定プロパティが正しくセットアップされていることを確認できます。 次の例では、そのセキュアプロパティ (ユーザー名、パスワード、トークン) が ​`.yaml`​ ファイルで暗号化された Salesforce Connector 設定を示しています。 ![config extension2](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-secure-config-properties-studio2.png) 値が暗号化されていない場合でもセキュアなプロパティファイル内のすべての値にアクセスできるように、​`secure::`​ プレフィックスがプロパティ名の定義の前に追加されます。 **\[Test Connection (接続をテスト)\]**​ をクリックすれば、接続が期待どおりに機能していることを確認し、セキュアなプロパティが正常に読み取られることを保証できます。 ## [](#ファイルレベル暗号化)ファイルレベル暗号化 セキュア設定プロパティモジュールのバージョン 1.1.0 以降では、各プロパティの値だけでなく、ファイル全体を暗号化できるようになっています。XML または Anypoint Studio の両方でファイルを暗号化できます。 XML フローで、​`fileLevelEncryption`​ 属性を追加して ​`true`​ に設定します。 ```xml ``` Studio の \[Secure Configuration Properties (セキュア設定プロパティ)\] ウィンドウで、​**\[File level encryption (ファイルレベル暗号化)\]**​ に ​**\[True\]**​ を選択します。 ![config extension3](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-secure-config-properties-studio3.png) ## [](#セキュア設定プロパティのユースケース)セキュア設定プロパティのユースケース セキュア設定プロパティに関する次のユースケースを確認してください。このユースケースでは、フローで暗号化された値と暗号化されていない値を使用する方法、セキュア設定プロパティファイルを動的に設定する方法、複数の設定ファイルを使用する方法を学ぶことができます。 ### [](#暗号化された値と暗号化されていない値)暗号化された値と暗号化されていない値 次の例では、フローで暗号化された ​`encrypted.value1`​ 値を使用してペイロードを設定する方法を示しています。実行時には、復号化アルゴリズムによって ​`encrypted.value1`​ を復号化した値をメモリに格納します。 ```xml ``` 次の例では、フローで同じセキュアプロパティファイルから暗号化されていない値を使用する方法を示しています。 ```xml ``` ### [](#セキュア設定プロパティファイルを動的に設定する)セキュア設定プロパティファイルを動的に設定する 一般的な設定のユースケースとして、プロパティ (例: `env`​) によって使用するファイルを決定するようにファイルを設定することができます。 たとえば、開発フェーズ中に (暗号化できなかった) ​`development-properties`​ ファイルと (暗号化された値を使用する) 本番ファイルのどちらかを使用するように設定できます。 **環境ファイルが定義されたセキュア設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティの値によって、セキュア設定プロパティを読み込むために使用するファイルが決定されます。その ​`env`​ プロパティは、​`global property`​、システムプロパティ、または環境プロパティで設定することもできます。 **環境ファイルが定義されたセキュアなグローバル設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティのデフォルト値は ​`"dev"`​ になりますが、システムプロパティや環境プロパティで上書きすることはできます。Anypoint Studio では、この方法はメタデータの解決に​**必須**​となります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらのプロパティに連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 ### [](#複数の設定ファイルを操作する)複数の設定ファイルを操作する プロパティを読み込む設定ファイルを複数定義することができます。必要なのは、読み込みたい各ファイルに対して ​``​ タグを定義するだけです。各セキュア設定プロパティファイルは、それぞれの暗号化アルゴリズム、暗号化モード、そして暗号化/復号化キーによって独立して設定されます。これらの設定はファイル間で同じになるとは限りません。 次の例は、複数の設定ファイルの使用方法を示しています。 ```xml ``` ## [](#サポートされる設定ファイル種別)サポートされる設定ファイル種別 - Spring 形式のプロパティ: `.properties` - YAML: `.yaml` ## [](#supported_crypto)サポートされているアルゴリズムとモード ### [](#supported_algorithms)サポートされているアルゴリズム - AES (デフォルト) - Blowfish - DES - DESede - RC2 - RCA 次のアルゴリズムは、サポートが追加される [Java Cryptography Extension (JCE) プロバイダー](https://docs.oracle.com/cd/E19830-01/819-4712/ablsc/index.html)​を設定する場合のみ使用できます。 - Camellia - CAST5 - CAST6 - Noekeon - Rijndael - SEED - Serpent - Skipjack - TEA - Twofish - XTEA - RC5 - RC6 ### [](#supported_modes)サポートされているモード - CBC (デフォルト) - CFB - ECB - OFB ## [](#よくある質問と回答)よくある質問と回答 セキュア設定プロパティファイルについて学び、作成して、しばらく使用したら、トラブルシューティングおよびその最大限の活用法についてさらに疑問が生まれる可能性もあります。一般的な質問と回答をいくつか紹介します。「関連情報」でリンクしているトピックも参照してください。 **複数のファイルで同じプロパティを設定したらどうなりますか?** その場合は、最初に定義されたプロパティの値が実際のプロパティ値となります。 **以前に定義したセキュアプロパティに依存するセキュアプロパティを定義できますか?** はい。単に同じ構文を使用するだけです: `property=My dependent ${secure::dependent.property} value`​。 セキュア設定プロパティは他のセキュア設定プロパティには依存できますが、他の Mule 設定プロパティには依存できません。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties) - [Define and Secure Properties for a Mule Application in Anypoint Code Builder (Anypoint Code Builder での Mule アプリケーションのプロパティの定義と保護)](https://docs.mulesoft.com/jp/anypoint-code-builder/int-create-secure-configs) # セキュア設定プロパティ 設定プロパティはアプリケーションの別のセキュリティレベルとして暗号化できます。セキュア設定プロパティを作成するには、次のプロセスを確認してください。 1. セキュア設定プロパティファイルを作成します。 2. 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。 3. Mule Secure Configuration Properties Extension Module を使用してプロジェクトでファイルを設定します。ファイルでは復号化キーを参照するか、復号化キーが含まれている必要があります。 ## [](#属性)属性 セキュアなプロパティファイルを作成してそのプロパティを定義する前に、プロセスで使用されるセキュア設定プロパティ属性と暗号化属性を確認してください。
Table 1. セキュア設定プロパティの属性
属性名 説明

Name (名前)

グローバルセキュア設定プロパティの一意の名前。

キー

プロパティ値をロック解除するために指定する単語またはフレーズ。たとえば、​${production.myproperty}​ と指定すると、Mule Runtime Engine は実行時にキーを要求します。

ファイル

キーが復号化するファイルの場所。

エンコード

キーがロック解除するファイルのエンコード。デフォルト値は UTF-8 です。

File Level Encryption (ファイルレベル暗号化)

ファイル全体を暗号化する場合は ​true​ に設定します。デフォルト値は ​false​ です。
Table 2. セキュア設定プロパティの暗号化属性
属性名 説明

Algorithm (アルゴリズム)

プロパティのコンテンツを暗号化するために使用するアルゴリズムの種別。完全なリストについては、​サポートされているアルゴリズム​を参照してください。

Mode (モード)

Mule Runtime Engine が単一のキーでブロック暗号を繰り返し使用するためのプロシージャーです。完全なリストについては、​サポートされているモード​を参照してください。

Use random IVs (ランダム IV の使用)

ランダム初期化ベクトル (IV) を使用するには、この属性を ​true​ にします。このオプションを ​true​ に設定すると、復号化アルゴリズムは復号化操作中に IV が暗号テキストの先頭に追加されていると見なします。
## [](#セキュア設定プロパティファイルを作成する)セキュア設定プロパティファイルを作成する 設定プロパティをセキュアにする最初のタスクは、プロパティを定義する YAML 設定ファイル (​`.yaml`​) または Spring 形式のプロパティファイル (​`.properties`​) を作成することです。Mule Secure Configuration Properties Extension Module を使用すれば、YAML またはプロパティファイル種別を設定できます。 セキュア設定プロパティファイルは、Mule プロジェクトの ​`src/main/resources`​ で、または絶対パスを使用して作成できます。 ## [](#ファイルでセキュア設定プロパティを定義する)ファイルでセキュア設定プロパティを定義する 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。このファイルには、Mule アプリケーション内のどの場所でも使用できる暗号化された値と暗号化されていない値の両方を含むことができます。
オペレーティングシステムへのアクセスをセキュアにしてください。​ps​ コマンドを実行できたり、Java コンソールを表示できたりするユーザーであれば、Mule アプリケーションのメモリに格納されている復号化された値を見ることができてしまうからです。
次の ​`file1.yaml`​ の例には、暗号化された設定プロパティ値と暗号化されていない設定プロパティ値が含まれています。 encrypted: value1: "!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\]" value2: "!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\]" testPropertyA: "testValueA" testPropertyB: "testValueB"
暗号化された値は、文字列として読めるように引用符で囲む必要があります。
次の ​`file1.properties`​ の例には、前の例で使用した設定プロパティが含まれていますが、Spring 形式のプロパティファイルを使用しています。 encrypted.value1=!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\] encrypted.value2=!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\] testPropertyA=testValueA testPropertyB=testValueB ## [](#secure_props_tool)セキュアプロパティツールを使用してプロパティを暗号化する テキスト文字列、プロパティファイル内の値、またはプロパティファイルのすべてのコンテンツを暗号化または復号化するには、セキュアプロパティツールを使用します。 この記事で説明するすべての機能を使用するには、このツールの使用可能な最新バージョンを使用していることを確認してください。 [セキュアプロパティツール Jar ファイル - Java 17 をサポート](https://docs.mulesoft.com/jp/mule-runtime/4.6/_attachments/secure-properties-tool-j17.jar)​。 最新リリース: 2024 年 11 月 22 日。 [セキュアプロパティツール Jar ファイル - Java 8 および 11 をサポート](https://docs.mulesoft.com/jp/mule-runtime/4.6/_attachments/secure-properties-tool.jar)​。 最新リリース: 2022 年 9 月 14 日。 構文は、以前のバージョンから変更されています。問題を回避するため、この記事で指定されている構文と JAR ファイルを使用してください。 受け入れられるすべてのパラメーターの完全なリストおよび定義については、​[パラメーターリファレンス](#parameter-reference)​を参照してください。 ### [](#テキスト文字列を暗号化する)テキスト文字列を暗号化する 次の構文を使用して、パラメーターとして指定されたテキスト文字列を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - テキスト文字列を処理するようにツールを設定するには、​``​ を ​`string`​ に設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次の操作を実行するとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ string \ encrypt \ Blowfish \ CBC \ mulesoft \ "some value to encrypt" ``` この場合、ツールで次の内容が返されます。 ```console.linenums 8q5e1+jy0cND2iV2WPThahmz6XsDwB6Z ``` ### [](#ファイルを暗号化する)ファイルを暗号化する 文字列の処理に加えて、暗号化ツールでは ​`.yaml`​ または ​`.properties`​ ファイルも処理されます。プロパティファイル内の値、またはファイルのすべてのコンテンツを暗号化または復号化できます。 #### [](#ファイル内のプロパティを暗号化する)ファイル内のプロパティを暗号化する 次の構文を使用して、プロパティファイル内のすべての値を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```yaml properties: example1: value: "![qCReIPK3jcqD7WR84ISSIQ==]" example2: "![En8lII21ZHrdIaINw0+mSA==]" ``` #### [](#ファイルのすべてのコンテンツを暗号化する)ファイルのすべてのコンテンツを暗号化する 次の構文を使用して、プロパティファイルのすべてのコンテンツを暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file-level`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file-level \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```txt k/J1EHyxJagOcyQELoaqIDCzzKc1bLGJiHY2dv6jzuhtVpP1LTlgK3y8EH7OkK5iuuu8kik3P5dCDMixZXwn/EV6xbUwLFKnEb4x1pUX6aopLP/KULm0pQ== ``` ### [](#parameter-reference)パラメーターリファレンス
パラメーター 説明

<method>

暗号化または復号化メソッドを設定します。可能な値:

string​

パラメーター ​<value>​ として指定された 1 つのテキスト文字列を暗号化します。

file​

パラメーター ​<input file>​ として指定されたプロパティファイルで設定された各プロパティの値を暗号化します。

file-level​

​<input file>​ として指定されたプロパティファイルのすべてのコンテンツを暗号化します。

<operation>

実行する操作を設定します。可能な値:

encrypt​

暗号化する操作を設定します。

decrypt​

復号化する操作を設定します。

<algorithm>

操作中に使用するアルゴリズムを指定します。
完全なリストについては、​サポートされているアルゴリズム​を参照してください。

<mode>

操作中に使用するモードを指定します。
完全なリストについては、​サポートされているモード​を参照してください。

<key>

操作中にファイルまたは値をロックまたはロック解除するために使用する単語を指定します。

  • キーで ​$​ 文字を使用する場合、その前に ​\​ を置く必要があります。 たとえば、キー ​myKey#$%123​ を使用するには、​<key>​ パラメーターを ​myKey#\$%123​ として指定する必要があります。

  • Java Cryptography Extension (JCE) バージョン 1.8.0_161​ 以降、AES キーの長さは 32 文字 (128 ビット) にする必要があります。

<value>

string​ 操作中に暗号化または復号化される文字列値を指定します。

<use random IV>

操作中にランダム初期化ベクトル (IV) が使用されるかどうかを指定します。

<input file>

file​ または ​file-level​ 操作中に暗号化または復号化されるプロパティファイルを指定します。

<output file>

file​ または ​file-level​ 操作後に作成される暗号化または復号化されたプロパティファイルを指定します。
## [](#プロジェクトでファイルを設定する)プロジェクトでファイルを設定する セキュアなプロパティファイルは、 [Exchange](https://anypoint.mulesoft.com/exchange/com.mulesoft.modules/mule-secure-configuration-property-module/)​ から入手できる Mule Secure Configuration Properties Extension Module を使用して、スタンドアロン XML と Anypoint Studio のどちらでも設定できます。
常に Anypoint Exchange から入手可能な最新の secure-configuration-properties 拡張を使用する必要があります。
### [](#xml-で-extension-module-を使用してファイルを設定する)XML で Extension Module を使用してファイルを設定する XML フローで、モジュール ​``​ を使用してファイルを設定します。次の例を確認してください。 **デフォルト値を使用したセキュア設定プロパティ** ```xml ``` - デフォルト値を使用する場合でも ​``​ タグは必要です。 - プレフィックス ​`secure::`​ はキーの読み込みに必要です。
セキュアなプロパティファイル内の値にアクセスするには、値が暗号化されていない場合でも ​secure::​ プレフィックスを使用する必要があります。これにより、設定全体を変更しなくてもファイル (または環境) を切り替えることができます。
- デプロイメント時に、復号化キーはシステム環境変数 ​`runtime.property`​ として Mule Runtime Engine に渡されます。このプロパティは、​`file1.yaml`​ ファイルに格納されている値を暗号化するために使用するのとまったく同じキーでなければなりません。 - デフォルトの暗号化アルゴリズムとモードが使用されます。 - たとえば、​`property.key1`​ プロパティの実際の (復号化された) 値が ​`"property"`​ であれば、​`prop`​ プロパティの値は ​`"my-property"`​ となります。 ``​ タグで追加の属性を設定して、暗号化アルゴリズムや暗号化モードを変更することもできます。 **カスタム値を使用したセキュア設定プロパティ** ```xml ``` 上の例で、​``​ タグでは ​`AES`​ アルゴリズム、​`CBC`​ モード、​`random IV`​ を使用しています。

<secure-properties:config>​ で設定された ​key​、​algorithm​、​mode​、​useRandomIVs​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
### [](#studio-で-extension-module-を使用してファイルを設定する)Studio で Extension Module を使用してファイルを設定する Anypoint Studio を使用してアプリケーションを開発している場合、Mule アプリケーションで連動関係として追加したモジュールを使用してセキュア設定プロパティを作成することもできます。 #### [](#extension-module-をインストールする)Extension Module をインストールする 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] セクションに移動します。 3. **\[Search in Exchange (Exchange 内を検索)\]**​ をクリックします。 4. \[Add Module to Project (モジュールをプロジェクトに追加)\] ウィンドウの ​**\[Type a search term to look up in Exchange (検索語を入力して Exchange 内で検索)\]**​ ボックスで、​**\[Mule Secure Configuration Property Extension (Mule セキュア設定プロパティ拡張)\]**​ を検索します。 5. リストでモジュール名を選択します。 6. **\[Add (追加)\]**​ に続いて ​**\[Finish (完了)\]**​ をクリックします。 #### [](#セキュア設定プロパティをアプリケーションに追加して設定する)セキュア設定プロパティをアプリケーションに追加して設定する 1. Mule アプリケーションの設定ファイルに移動します。 2. **\[Global Elements (グローバル要素)\]**​ タブを選択します。 3. **\[Create (作成)\]**​ をクリックします。 4. **\[Secure Properties Config (セキュアプロパティ設定)\]**​ を選択します。 5. **\[File (ファイル)\]**​ の場所、​**\[Key (キー)\]**​、​**\[Algorithm (アルゴリズム)\]**​、​**\[Mode (モード)\]**​、​**\[Use random IV (ランダム IV の使用)\]**​、​**\[File level encryption (ファイルレベル暗号化)\]**​、​**\[Encoding (エンコード)\]**​ を使用してグローバル要素を設定します。 6. **\[OK\]**​ をクリックします。 ![設定の拡張](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-secure-config-properties-studio.png)

Secure Configuration Properties Module で設定された ​key​、​algorithm​、​mode​、​use random IV​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
#### [](#開発時にセキュア設定プロパティを確認する)開発時にセキュア設定プロパティを確認する Studio でアプリケーションを開発している場合、コネクタ接続をテストしてコネクタのセキュア設定プロパティが正しくセットアップされていることを確認できます。 次の例では、そのセキュアプロパティ (ユーザー名、パスワード、トークン) が ​`.yaml`​ ファイルで暗号化された Salesforce Connector 設定を示しています。 ![config extension2](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-secure-config-properties-studio2.png) 値が暗号化されていない場合でもセキュアなプロパティファイル内のすべての値にアクセスできるように、​`secure::`​ プレフィックスがプロパティ名の定義の前に追加されます。 **\[Test Connection (接続をテスト)\]**​ をクリックすれば、接続が期待どおりに機能していることを確認し、セキュアなプロパティが正常に読み取られることを保証できます。 ## [](#ファイルレベル暗号化)ファイルレベル暗号化 セキュア設定プロパティモジュールのバージョン 1.1.0 以降では、各プロパティの値だけでなく、ファイル全体を暗号化できるようになっています。XML または Anypoint Studio の両方でファイルを暗号化できます。 XML フローで、​`fileLevelEncryption`​ 属性を追加して ​`true`​ に設定します。 ```xml ``` Studio の \[Secure Configuration Properties (セキュア設定プロパティ)\] ウィンドウで、​**\[File level encryption (ファイルレベル暗号化)\]**​ に ​**\[True\]**​ を選択します。 ![config extension3](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-secure-config-properties-studio3.png) ## [](#セキュア設定プロパティのユースケース)セキュア設定プロパティのユースケース セキュア設定プロパティに関する次のユースケースを確認してください。このユースケースでは、フローで暗号化された値と暗号化されていない値を使用する方法、セキュア設定プロパティファイルを動的に設定する方法、複数の設定ファイルを使用する方法を学ぶことができます。 ### [](#暗号化された値と暗号化されていない値)暗号化された値と暗号化されていない値 次の例では、フローで暗号化された ​`encrypted.value1`​ 値を使用してペイロードを設定する方法を示しています。実行時には、復号化アルゴリズムによって ​`encrypted.value1`​ を復号化した値をメモリに格納します。 ```xml ``` 次の例では、フローで同じセキュアプロパティファイルから暗号化されていない値を使用する方法を示しています。 ```xml ``` ### [](#セキュア設定プロパティファイルを動的に設定する)セキュア設定プロパティファイルを動的に設定する 一般的な設定のユースケースとして、プロパティ (例: `env`​) によって使用するファイルを決定するようにファイルを設定することができます。 たとえば、開発フェーズ中に (暗号化できなかった) ​`development-properties`​ ファイルと (暗号化された値を使用する) 本番ファイルのどちらかを使用するように設定できます。 **環境ファイルが定義されたセキュア設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティの値によって、セキュア設定プロパティを読み込むために使用するファイルが決定されます。その ​`env`​ プロパティは、​`global property`​、システムプロパティ、または環境プロパティで設定することもできます。 **環境ファイルが定義されたセキュアなグローバル設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティのデフォルト値は ​`"dev"`​ になりますが、システムプロパティや環境プロパティで上書きすることはできます。Anypoint Studio では、この方法はメタデータの解決に​**必須**​となります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらのプロパティに連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 ### [](#複数の設定ファイルを操作する)複数の設定ファイルを操作する プロパティを読み込む設定ファイルを複数定義することができます。必要なのは、読み込みたい各ファイルに対して ​``​ タグを定義するだけです。各セキュア設定プロパティファイルは、それぞれの暗号化アルゴリズム、暗号化モード、そして暗号化/復号化キーによって独立して設定されます。これらの設定はファイル間で同じになるとは限りません。 次の例は、複数の設定ファイルの使用方法を示しています。 ```xml ``` ## [](#サポートされる設定ファイル種別)サポートされる設定ファイル種別 - Spring 形式のプロパティ: `.properties` - YAML: `.yaml` ## [](#supported_crypto)サポートされているアルゴリズムとモード ### [](#supported_algorithms)サポートされているアルゴリズム - AES (デフォルト) - Blowfish - DES - DESede - RC2 - RCA 次のアルゴリズムは、サポートが追加される [Java Cryptography Extension (JCE) プロバイダー](https://docs.oracle.com/cd/E19830-01/819-4712/ablsc/index.html)​を設定する場合のみ使用できます。 - Camellia - CAST5 - CAST6 - Noekeon - Rijndael - SEED - Serpent - Skipjack - TEA - Twofish - XTEA - RC5 - RC6 ### [](#supported_modes)サポートされているモード - CBC (デフォルト) - CFB - ECB - OFB ## [](#よくある質問と回答)よくある質問と回答 セキュア設定プロパティファイルについて学び、作成して、しばらく使用したら、トラブルシューティングおよびその最大限の活用法についてさらに疑問が生まれる可能性もあります。一般的な質問と回答をいくつか紹介します。「関連情報」でリンクしているトピックも参照してください。 **複数のファイルで同じプロパティを設定したらどうなりますか?** その場合は、最初に定義されたプロパティの値が実際のプロパティ値となります。 **以前に定義したセキュアプロパティに依存するセキュアプロパティを定義できますか?** はい。単に同じ構文を使用するだけです: `property=My dependent ${secure::dependent.property} value`​。 セキュア設定プロパティは他のセキュア設定プロパティには依存できますが、他の Mule 設定プロパティには依存できません。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties) - [Define and Secure Properties for a Mule Application in Anypoint Code Builder (Anypoint Code Builder での Mule アプリケーションのプロパティの定義と保護)](https://docs.mulesoft.com/jp/anypoint-code-builder/int-create-secure-configs) # セキュア設定プロパティ 設定プロパティはアプリケーションの別のセキュリティレベルとして暗号化できます。セキュア設定プロパティを作成するには、次のプロセスを確認してください。 1. セキュア設定プロパティファイルを作成します。 2. 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。 3. Mule Secure Configuration Properties Extension Module を使用してプロジェクトでファイルを設定します。ファイルでは復号化キーを参照するか、復号化キーが含まれている必要があります。 ## [](#属性)属性 セキュアなプロパティファイルを作成してそのプロパティを定義する前に、プロセスで使用されるセキュア設定プロパティ属性と暗号化属性を確認してください。
Table 1. セキュア設定プロパティの属性
属性名 説明

Name (名前)

グローバルセキュア設定プロパティの一意の名前。

Key (キー)

プロパティ値をロック解除するために指定する単語またはフレーズ。たとえば、​${production.myproperty}​ と指定すると、Mule Runtime Engine は実行時にキーを要求します。

ファイル

キーが復号化するファイルの場所。

Encoding (エンコード)

キーがロック解除するファイルのエンコード。デフォルト値は UTF-8 です。

File Level Encryption (ファイルレベル暗号化)

ファイル全体を暗号化する場合は ​true​ に設定します。デフォルト値は ​false​ です。
Table 2. セキュア設定プロパティの暗号化属性
属性名 説明

Algorithm (アルゴリズム)

プロパティのコンテンツを暗号化するために使用するアルゴリズムの種別。完全なリストについては、​サポートされているアルゴリズム​を参照してください。

Mode (モード)

Mule Runtime Engine が単一のキーでブロック暗号を繰り返し使用するためのプロシージャーです。完全なリストについては、​サポートされているモード​を参照してください。

Use random IVs (ランダム IV の使用)

ランダム初期化ベクトル (IV) を使用するには、この属性を ​true​ にします。このオプションを ​true​ に設定すると、復号化アルゴリズムは復号化操作中に IV が暗号テキストの先頭に追加されていると見なします。
## [](#セキュア設定プロパティファイルを作成する)セキュア設定プロパティファイルを作成する 設定プロパティをセキュアにする最初のタスクは、プロパティを定義する YAML 設定ファイル (​`.yaml`​) または Spring 形式のプロパティファイル (​`.properties`​) を作成することです。Mule Secure Configuration Properties Extension Module を使用すれば、YAML またはプロパティファイル種別を設定できます。 セキュア設定プロパティファイルは、Mule プロジェクトの ​`src/main/resources`​ で、または絶対パスを使用して作成できます。 ## [](#ファイルでセキュア設定プロパティを定義する)ファイルでセキュア設定プロパティを定義する 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。このファイルには、Mule アプリケーション内のどの場所でも使用できる暗号化された値と暗号化されていない値の両方を含むことができます。
オペレーティングシステムへのアクセスをセキュアにしてください。​ps​ コマンドを実行できたり、Java コンソールを表示できたりするユーザーであれば、Mule アプリケーションのメモリに格納されている復号化された値を見ることができてしまうからです。
次の ​`file1.yaml`​ の例には、暗号化された設定プロパティ値と暗号化されていない設定プロパティ値が含まれています。 encrypted: value1: "!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\]" value2: "!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\]" testPropertyA: "testValueA" testPropertyB: "testValueB"
暗号化された値は、文字列として読めるように引用符で囲む必要があります。
次の ​`file1.properties`​ の例には、前の例で使用した設定プロパティが含まれていますが、Spring 形式のプロパティファイルを使用しています。 encrypted.value1=!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\] encrypted.value2=!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\] testPropertyA=testValueA testPropertyB=testValueB ## [](#secure_props_tool)セキュアプロパティツールを使用してプロパティを暗号化する テキスト文字列、プロパティファイル内の値、またはプロパティファイルのすべてのコンテンツを暗号化または復号化するには、セキュアプロパティツールを使用します。 この記事で説明するすべての機能を使用するには、このツールの使用可能な最新バージョンを使用していることを確認してください。 [セキュアプロパティツール Jar ファイル - Java 17 をサポート](https://docs.mulesoft.com/jp/mule-runtime/4.7/_attachments/secure-properties-tool-j17.jar)​。 最新リリース: 2024 年 11 月 22 日。 [セキュアプロパティツール Jar ファイル - Java 8 および 11 をサポート](https://docs.mulesoft.com/jp/mule-runtime/4.7/_attachments/secure-properties-tool.jar)​。 最新リリース: 2022 年 9 月 14 日。 構文は、以前のバージョンから変更されています。問題を回避するため、この記事で指定されている構文と JAR ファイルを使用してください。 受け入れられるすべてのパラメーターの完全なリストおよび定義については、​[パラメーターリファレンス](#parameter-reference)​を参照してください。 ### [](#テキスト文字列を暗号化する)テキスト文字列を暗号化する 次の構文を使用して、パラメーターとして指定されたテキスト文字列を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - テキスト文字列を処理するようにツールを設定するには、​``​ を ​`string`​ に設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次の操作を実行するとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ string \ encrypt \ Blowfish \ CBC \ mulesoft \ "some value to encrypt" ``` この場合、ツールで次の内容が返されます。 ```console.linenums 8q5e1+jy0cND2iV2WPThahmz6XsDwB6Z ``` ### [](#ファイルを暗号化する)ファイルを暗号化する 文字列の処理に加えて、暗号化ツールでは ​`.yaml`​ または ​`.properties`​ ファイルも処理されます。プロパティファイル内の値、またはファイルのすべてのコンテンツを暗号化または復号化できます。 #### [](#ファイル内のプロパティを暗号化する)ファイル内のプロパティを暗号化する 次の構文を使用して、プロパティファイル内のすべての値を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```yaml properties: example1: value: "![qCReIPK3jcqD7WR84ISSIQ==]" example2: "![En8lII21ZHrdIaINw0+mSA==]" ``` #### [](#ファイルのすべてのコンテンツを暗号化する)ファイルのすべてのコンテンツを暗号化する 次の構文を使用して、プロパティファイルのすべてのコンテンツを暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file-level`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file-level \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```txt k/J1EHyxJagOcyQELoaqIDCzzKc1bLGJiHY2dv6jzuhtVpP1LTlgK3y8EH7OkK5iuuu8kik3P5dCDMixZXwn/EV6xbUwLFKnEb4x1pUX6aopLP/KULm0pQ== ``` ### [](#parameter-reference)パラメーターリファレンス
パラメーター 説明

<method>

暗号化または復号化メソッドを設定します。可能な値:

string​

パラメーター ​<value>​ として指定された 1 つのテキスト文字列を暗号化します。

file​

パラメーター ​<input file>​ として指定されたプロパティファイルで設定された各プロパティの値を暗号化します。

file-level​

​<input file>​ として指定されたプロパティファイルのすべてのコンテンツを暗号化します。

<operation>

実行する操作を設定します。可能な値:

encrypt​

暗号化する操作を設定します。

decrypt​

復号化する操作を設定します。

<algorithm>

操作中に使用するアルゴリズムを指定します。
完全なリストについては、​サポートされているアルゴリズム​を参照してください。

<mode>

操作中に使用するモードを指定します。
完全なリストについては、​サポートされているモード​を参照してください。

<key>

操作中にファイルまたは値をロックまたはロック解除するために使用する単語を指定します。

  • キーで ​$​ 文字を使用する場合、その前に ​\​ を置く必要があります。 たとえば、キー ​myKey#$%123​ を使用するには、​<key>​ パラメーターを ​myKey#\$%123​ として指定する必要があります。

  • Java Cryptography Extension (JCE) バージョン 1.8.0_161​ 以降、AES キーの長さは 32 文字 (128 ビット) にする必要があります。

<value>

string​ 操作中に暗号化または復号化される文字列値を指定します。

<use random IV>

操作中にランダム初期化ベクトル (IV) が使用されるかどうかを指定します。

<input file>

file​ または ​file-level​ 操作中に暗号化または復号化されるプロパティファイルを指定します。

<output file>

file​ または ​file-level​ 操作後に作成される暗号化または復号化されたプロパティファイルを指定します。
## [](#プロジェクトでファイルを設定する)プロジェクトでファイルを設定する セキュアなプロパティファイルは、 [Exchange](https://anypoint.mulesoft.com/exchange/com.mulesoft.modules/mule-secure-configuration-property-module/)​ から入手できる Mule Secure Configuration Properties Extension Module を使用して、スタンドアロン XML と Anypoint Studio のどちらでも設定できます。 ### [](#xml-で-extension-module-を使用してファイルを設定する)XML で Extension Module を使用してファイルを設定する XML フローで、モジュール ​``​ を使用してファイルを設定します。次の例を確認してください。 **デフォルト値を使用したセキュア設定プロパティ** ```xml ``` - デフォルト値を使用する場合でも ​``​ タグは必要です。 - プレフィックス ​`secure::`​ はキーの読み込みに必要です。
セキュアなプロパティファイル内の値にアクセスするには、値が暗号化されていない場合でも ​secure::​ プレフィックスを使用する必要があります。これにより、設定全体を変更しなくてもファイル (または環境) を切り替えることができます。
- デプロイメント時に、復号化キーはシステム環境変数 ​`runtime.property`​ として Mule Runtime Engine に渡されます。このプロパティは、​`file1.yaml`​ ファイルに格納されている値を暗号化するために使用するのとまったく同じキーでなければなりません。 - デフォルトの暗号化アルゴリズムとモードが使用されます。 - たとえば、​`property.key1`​ プロパティの実際の (復号化された) 値が ​`"property"`​ であれば、​`prop`​ プロパティの値は ​`"my-property"`​ となります。 ``​ タグで追加の属性を設定して、暗号化アルゴリズムや暗号化モードを変更することもできます。 **カスタム値を使用したセキュア設定プロパティ** ```xml ``` 上の例で、​``​ タグでは ​`AES`​ アルゴリズム、​`CBC`​ モード、​`random IV`​ を使用しています。

<secure-properties:config>​ で設定された ​key​、​algorithm​、​mode​、​useRandomIVs​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
### [](#studio-で-extension-module-を使用してファイルを設定する)Studio で Extension Module を使用してファイルを設定する Anypoint Studio を使用してアプリケーションを開発している場合、Mule アプリケーションで連動関係として追加したモジュールを使用してセキュア設定プロパティを作成することもできます。 #### [](#extension-module-をインストールする)Extension Module をインストールする 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] セクションに移動します。 3. **\[Search in Exchange (Exchange 内を検索)\]**​ をクリックします。 4. \[Add Module to Project (モジュールをプロジェクトに追加)\] ウィンドウの ​**\[Type a search term to look up in Exchange (検索語を入力して Exchange 内で検索)\]**​ ボックスで、​**\[Mule Secure Configuration Property Extension (Mule セキュア設定プロパティ拡張)\]**​ を検索します。 5. リストでモジュール名を選択します。 6. **\[Add (追加)\]**​ に続いて ​**\[Finish (完了)\]**​ をクリックします。 #### [](#セキュア設定プロパティをアプリケーションに追加して設定する)セキュア設定プロパティをアプリケーションに追加して設定する 1. Mule アプリケーションの設定ファイルに移動します。 2. **\[Global Elements (グローバル要素)\]**​ タブを選択します。 3. **\[Create (作成)\]**​ をクリックします。 4. **\[Secure Properties Config (セキュアプロパティ設定)\]**​ を選択します。 5. **\[File (ファイル)\]**​ の場所、​**\[Key (キー)\]**​、​**\[Algorithm (アルゴリズム)\]**​、​**\[Mode (モード)\]**​、​**\[Use random IV (ランダム IV の使用)\]**​、​**\[File level encryption (ファイルレベル暗号化)\]**​、​**\[Encoding (エンコード)\]**​ を使用してグローバル要素を設定します。 6. **\[OK\]**​ をクリックします。 ![設定の拡張](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-secure-config-properties-studio.png)

Secure Configuration Properties Module で設定された ​key​、​algorithm​、​mode​、​use random IV​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
#### [](#開発時にセキュア設定プロパティを確認する)開発時にセキュア設定プロパティを確認する Studio でアプリケーションを開発している場合、コネクタ接続をテストしてコネクタのセキュア設定プロパティが正しくセットアップされていることを確認できます。 次の例では、そのセキュアプロパティ (ユーザー名、パスワード、トークン) が ​`.yaml`​ ファイルで暗号化された Salesforce Connector 設定を示しています。 ![config extension2](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-secure-config-properties-studio2.png) 値が暗号化されていない場合でもセキュアなプロパティファイル内のすべての値にアクセスできるように、​`secure::`​ プレフィックスがプロパティ名の定義の前に追加されます。 **\[Test Connection (接続をテスト)\]**​ をクリックすれば、接続が期待どおりに機能していることを確認し、セキュアなプロパティが正常に読み取られることを保証できます。 ## [](#ファイルレベル暗号化)ファイルレベル暗号化 セキュア設定プロパティモジュールのバージョン 1.1.0 以降では、各プロパティの値だけでなく、ファイル全体を暗号化できるようになっています。XML または Anypoint Studio の両方でファイルを暗号化できます。 XML フローで、​`fileLevelEncryption`​ 属性を追加して ​`true`​ に設定します。 ```xml ``` Studio の \[Secure Configuration Properties (セキュア設定プロパティ)\] ウィンドウで、​**\[File level encryption (ファイルレベル暗号化)\]**​ に ​**\[True\]**​ を選択します。 ![config extension3](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-secure-config-properties-studio3.png) ## [](#セキュア設定プロパティのユースケース)セキュア設定プロパティのユースケース セキュア設定プロパティに関する次のユースケースを確認してください。このユースケースでは、フローで暗号化された値と暗号化されていない値を使用する方法、セキュア設定プロパティファイルを動的に設定する方法、複数の設定ファイルを使用する方法を学ぶことができます。 ### [](#暗号化された値と暗号化されていない値)暗号化された値と暗号化されていない値 次の例では、フローで暗号化された ​`encrypted.value1`​ 値を使用してペイロードを設定する方法を示しています。実行時には、復号化アルゴリズムによって ​`encrypted.value1`​ を復号化した値をメモリに格納します。 ```xml ``` 次の例では、フローで同じセキュアプロパティファイルから暗号化されていない値を使用する方法を示しています。 ```xml ``` ### [](#セキュア設定プロパティファイルを動的に設定する)セキュア設定プロパティファイルを動的に設定する 一般的な設定のユースケースとして、プロパティ (例: `env`​) によって使用するファイルを決定するようにファイルを設定することができます。 たとえば、開発フェーズ中に (暗号化できなかった) ​`development-properties`​ ファイルと (暗号化された値を使用する) 本番ファイルのどちらかを使用するように設定できます。 **環境ファイルが定義されたセキュア設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティの値によって、セキュア設定プロパティを読み込むために使用するファイルが決定されます。その ​`env`​ プロパティは、​`global property`​、システムプロパティ、または環境プロパティで設定することもできます。 **環境ファイルが定義されたセキュアなグローバル設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティのデフォルト値は ​`"dev"`​ になりますが、システムプロパティや環境プロパティで上書きすることはできます。Anypoint Studio では、この方法はメタデータの解決に​**必須**​となります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらのプロパティに連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 ### [](#複数の設定ファイルを操作する)複数の設定ファイルを操作する プロパティを読み込む設定ファイルを複数定義することができます。必要なのは、読み込みたい各ファイルに対して ​``​ タグを定義するだけです。各セキュア設定プロパティファイルは、それぞれの暗号化アルゴリズム、暗号化モード、そして暗号化/復号化キーによって独立して設定されます。これらの設定はファイル間で同じになるとは限りません。 次の例は、複数の設定ファイルの使用方法を示しています。 ```xml ``` ## [](#サポートされる設定ファイル種別)サポートされる設定ファイル種別 - Spring 形式のプロパティ: `.properties` - YAML: `.yaml` ## [](#supported_crypto)サポートされているアルゴリズムとモード ### [](#supported_algorithms)サポートされているアルゴリズム - AES (デフォルト) - Blowfish - DES - DESede - RC2 - RCA 次のアルゴリズムは、サポートが追加される [Java Cryptography Extension (JCE) プロバイダー](https://docs.oracle.com/cd/E19830-01/819-4712/ablsc/index.html)​を設定する場合のみ使用できます。 - Camellia - CAST5 - CAST6 - Noekeon - Rijndael - SEED - Serpent - Skipjack - TEA - Twofish - XTEA - RC5 - RC6 ### [](#supported_modes)サポートされているモード - CBC (デフォルト) - CFB - ECB - OFB ## [](#よくある質問と回答)よくある質問と回答 セキュア設定プロパティファイルについて学び、作成して、しばらく使用したら、トラブルシューティングおよびその最大限の活用法についてさらに疑問が生まれる可能性もあります。一般的な質問と回答をいくつか紹介します。「関連情報」でリンクしているトピックも参照してください。 **複数のファイルで同じプロパティを設定したらどうなりますか?** その場合は、最初に定義されたプロパティの値が実際のプロパティ値となります。 **以前に定義したセキュアプロパティに依存するセキュアプロパティを定義できますか?** はい。単に同じ構文を使用するだけです: `property=My dependent ${secure::dependent.property} value`​。 セキュア設定プロパティは他のセキュア設定プロパティには依存できますが、他の Mule 設定プロパティには依存できません。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties) - [Define and Secure Properties for a Mule Application in Anypoint Code Builder (Anypoint Code Builder での Mule アプリケーションのプロパティの定義と保護)](https://docs.mulesoft.com/jp/anypoint-code-builder/int-create-secure-configs) # セキュア設定プロパティ 設定プロパティはアプリケーションの別のセキュリティレベルとして暗号化できます。セキュア設定プロパティを作成するには、次のプロセスを確認してください。 1. セキュア設定プロパティファイルを作成します。 2. 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。 3. Mule Secure Configuration Properties Extension Module を使用してプロジェクトでファイルを設定します。ファイルでは復号化キーを参照するか、復号化キーが含まれている必要があります。 ## [](#属性)属性 セキュアなプロパティファイルを作成してそのプロパティを定義する前に、プロセスで使用されるセキュア設定プロパティ属性と暗号化属性を確認してください。
Table 1. セキュア設定プロパティの属性
属性名 説明

Name (名前)

グローバルセキュア設定プロパティの一意の名前。

Key (キー)

プロパティ値をロック解除するために指定する単語またはフレーズ。たとえば、​${production.myproperty}​ と指定すると、Mule Runtime Engine は実行時にキーを要求します。

ファイル

キーが復号化するファイルの場所。

Encoding (エンコード)

キーがロック解除するファイルのエンコード。デフォルト値は UTF-8 です。

File Level Encryption (ファイルレベル暗号化)

ファイル全体を暗号化する場合は ​true​ に設定します。デフォルト値は ​false​ です。
Table 2. セキュア設定プロパティの暗号化属性
属性名 説明

Algorithm (アルゴリズム)

プロパティのコンテンツを暗号化するために使用するアルゴリズムの種別。完全なリストについては、​サポートされているアルゴリズム​を参照してください。

Mode (モード)

Mule Runtime Engine が単一のキーでブロック暗号を繰り返し使用するためのプロシージャーです。完全なリストについては、​サポートされているモード​を参照してください。

Use random IVs (ランダム IV の使用)

ランダム初期化ベクトル (IV) を使用するには、この属性を ​true​ にします。このオプションを ​true​ に設定すると、復号化アルゴリズムは復号化操作中に IV が暗号テキストの先頭に追加されていると見なします。
## [](#セキュア設定プロパティファイルを作成する)セキュア設定プロパティファイルを作成する 設定プロパティをセキュアにする最初のタスクは、プロパティを定義する YAML 設定ファイル (​`.yaml`​) または Spring 形式のプロパティファイル (​`.properties`​) を作成することです。Mule Secure Configuration Properties Extension Module を使用すれば、YAML またはプロパティファイル種別を設定できます。 セキュア設定プロパティファイルは、Mule プロジェクトの ​`src/main/resources`​ で、または絶対パスを使用して作成できます。 ## [](#ファイルでセキュア設定プロパティを定義する)ファイルでセキュア設定プロパティを定義する 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。このファイルには、Mule アプリケーション内のどの場所でも使用できる暗号化された値と暗号化されていない値の両方を含むことができます。
オペレーティングシステムへのアクセスをセキュアにしてください。​ps​ コマンドを実行できたり、Java コンソールを表示できたりするユーザーであれば、Mule アプリケーションのメモリに格納されている復号化された値を見ることができてしまうからです。
次の ​`file1.yaml`​ の例には、暗号化された設定プロパティ値と暗号化されていない設定プロパティ値が含まれています。 encrypted: value1: "!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\]" value2: "!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\]" testPropertyA: "testValueA" testPropertyB: "testValueB"
暗号化された値は、文字列として読めるように引用符で囲む必要があります。
次の ​`file1.properties`​ の例には、前の例で使用した設定プロパティが含まれていますが、Spring 形式のプロパティファイルを使用しています。 encrypted.value1=!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\] encrypted.value2=!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\] testPropertyA=testValueA testPropertyB=testValueB ## [](#secure_props_tool)セキュアプロパティツールを使用してプロパティを暗号化する テキスト文字列、プロパティファイル内の値、またはプロパティファイルのすべてのコンテンツを暗号化または復号化するには、セキュアプロパティツールを使用します。 この記事で説明するすべての機能を使用するには、このツールの使用可能な最新バージョンを使用していることを確認してください。 [セキュアプロパティツール Jar ファイル - Java 17 をサポート](https://docs.mulesoft.com/jp/mule-runtime/4.8/_attachments/secure-properties-tool-j17.jar)​。 最新リリース: 2024 年 11 月 22 日。 [セキュアプロパティツール Jar ファイル - Java 8 および 11 をサポート](https://docs.mulesoft.com/jp/mule-runtime/4.8/_attachments/secure-properties-tool.jar)​。 最新リリース: 2022 年 9 月 14 日。 構文は、以前のバージョンから変更されています。問題を回避するため、この記事で指定されている構文と JAR ファイルを使用してください。また、ツールの入力テキストでハッシュ文字 ​`#`​ を使用することはできません。 受け入れられるすべてのパラメーターの完全なリストおよび定義については、​[パラメーターリファレンス](#parameter-reference)​を参照してください。 ### [](#テキスト文字列を暗号化する)テキスト文字列を暗号化する 次の構文を使用して、パラメーターとして指定されたテキスト文字列を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - テキスト文字列を処理するようにツールを設定するには、​``​ を ​`string`​ に設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次の操作を実行するとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ string \ encrypt \ Blowfish \ CBC \ mulesoft \ "some value to encrypt" ``` この場合、ツールで次の内容が返されます。 ```console.linenums 8q5e1+jy0cND2iV2WPThahmz6XsDwB6Z ``` ### [](#ファイルを暗号化する)ファイルを暗号化する 文字列の処理に加えて、暗号化ツールでは ​`.yaml`​ または ​`.properties`​ ファイルも処理されます。プロパティファイル内の値、またはファイルのすべてのコンテンツを暗号化または復号化できます。 #### [](#ファイル内のプロパティを暗号化する)ファイル内のプロパティを暗号化する 次の構文を使用して、プロパティファイル内のすべての値を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```yaml properties: example1: value: "![qCReIPK3jcqD7WR84ISSIQ==]" example2: "![En8lII21ZHrdIaINw0+mSA==]" ``` #### [](#ファイルのすべてのコンテンツを暗号化する)ファイルのすべてのコンテンツを暗号化する 次の構文を使用して、プロパティファイルのすべてのコンテンツを暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file-level`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file-level \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```txt k/J1EHyxJagOcyQELoaqIDCzzKc1bLGJiHY2dv6jzuhtVpP1LTlgK3y8EH7OkK5iuuu8kik3P5dCDMixZXwn/EV6xbUwLFKnEb4x1pUX6aopLP/KULm0pQ== ``` ### [](#parameter-reference)パラメーターリファレンス
パラメーター 説明

<method>

暗号化または復号化メソッドを設定します。可能な値:

string​

パラメーター ​<value>​ として指定された 1 つのテキスト文字列を暗号化します。

file​

パラメーター ​<input file>​ として指定されたプロパティファイルで設定された各プロパティの値を暗号化します。

file-level​

​<input file>​ として指定されたプロパティファイルのすべてのコンテンツを暗号化します。

<operation>

実行する操作を設定します。可能な値:

encrypt​

暗号化する操作を設定します。

decrypt​

復号化する操作を設定します。

<algorithm>

操作中に使用するアルゴリズムを指定します。
完全なリストについては、​サポートされているアルゴリズム​を参照してください。

<mode>

操作中に使用するモードを指定します。
完全なリストについては、​サポートされているモード​を参照してください。

<key>

操作中にファイルまたは値をロックまたはロック解除するために使用する単語を指定します。

  • キーで ​$​ 文字を使用する場合、その前に ​\​ を置く必要があります。 たとえば、キー ​myKey#$%123​ を使用するには、​<key>​ パラメーターを ​myKey#\$%123​ として指定する必要があります。

  • Java Cryptography Extension (JCE) バージョン 1.8.0_161​ 以降、AES キーの長さは 32 文字 (128 ビット) にする必要があります。

<value>

string​ 操作中に暗号化または復号化される文字列値を指定します。

<use random IV>

操作中にランダム初期化ベクトル (IV) が使用されるかどうかを指定します。

<input file>

file​ または ​file-level​ 操作中に暗号化または復号化されるプロパティファイルを指定します。

<output file>

file​ または ​file-level​ 操作後に作成される暗号化または復号化されたプロパティファイルを指定します。
## [](#プロジェクトでファイルを設定する)プロジェクトでファイルを設定する セキュアなプロパティファイルは、 [Exchange](https://anypoint.mulesoft.com/exchange/com.mulesoft.modules/mule-secure-configuration-property-module/)​ から入手できる Mule Secure Configuration Properties Extension Module を使用して、スタンドアロン XML と Anypoint Studio のどちらでも設定できます。 ### [](#xml-で-extension-module-を使用してファイルを設定する)XML で Extension Module を使用してファイルを設定する XML フローで、モジュール ​``​ を使用してファイルを設定します。次の例を確認してください。 **デフォルト値を使用したセキュア設定プロパティ** ```xml ``` - デフォルト値を使用する場合でも ​``​ タグは必要です。 - プレフィックス ​`secure::`​ はキーの読み込みに必要です。
セキュアなプロパティファイル内の値にアクセスするには、値が暗号化されていない場合でも ​secure::​ プレフィックスを使用する必要があります。これにより、設定全体を変更しなくてもファイル (または環境) を切り替えることができます。
- デプロイメント時に、復号化キーはシステム環境変数 ​`runtime.property`​ として Mule Runtime Engine に渡されます。このプロパティは、​`file1.yaml`​ ファイルに格納されている値を暗号化するために使用するのとまったく同じキーでなければなりません。 - デフォルトの暗号化アルゴリズムとモードが使用されます。 - たとえば、​`property.key1`​ プロパティの実際の (復号化された) 値が ​`"property"`​ であれば、​`prop`​ プロパティの値は ​`"my-property"`​ となります。 ``​ タグで追加の属性を設定して、暗号化アルゴリズムや暗号化モードを変更することもできます。 **カスタム値を使用したセキュア設定プロパティ** ```xml ``` 上の例で、​``​ タグでは ​`AES`​ アルゴリズム、​`CBC`​ モード、​`random IV`​ を使用しています。

<secure-properties:config>​ で設定された ​key​、​algorithm​、​mode​、​useRandomIVs​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
### [](#studio-で-extension-module-を使用してファイルを設定する)Studio で Extension Module を使用してファイルを設定する Anypoint Studio を使用してアプリケーションを開発している場合、Mule アプリケーションで連動関係として追加したモジュールを使用してセキュア設定プロパティを作成することもできます。 #### [](#extension-module-をインストールする)Extension Module をインストールする 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] セクションに移動します。 3. **\[Search in Exchange (Exchange 内を検索)\]**​ をクリックします。 4. \[Add Module to Project (モジュールをプロジェクトに追加)\] ウィンドウの ​**\[Type a search term to look up in Exchange (検索語を入力して Exchange 内で検索)\]**​ ボックスで、​**\[Mule Secure Configuration Property Extension (Mule セキュア設定プロパティ拡張)\]**​ を検索します。 5. リストでモジュール名を選択します。 6. **\[Add (追加)\]**​ に続いて ​**\[Finish (完了)\]**​ をクリックします。 #### [](#セキュア設定プロパティをアプリケーションに追加して設定する)セキュア設定プロパティをアプリケーションに追加して設定する 1. Mule アプリケーションの設定ファイルに移動します。 2. **\[Global Elements (グローバル要素)\]**​ タブを選択します。 3. **\[Create (作成)\]**​ をクリックします。 4. **\[Secure Properties Config (セキュアプロパティ設定)\]**​ を選択します。 5. **\[File (ファイル)\]**​ の場所、​**\[Key (キー)\]**​、​**\[Algorithm (アルゴリズム)\]**​、​**\[Mode (モード)\]**​、​**\[Use random IV (ランダム IV の使用)\]**​、​**\[File level encryption (ファイルレベル暗号化)\]**​、​**\[Encoding (エンコード)\]**​ を使用してグローバル要素を設定します。 6. **\[OK\]**​ をクリックします。 ![セキュアプロパティの設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-secure-config-properties-studio.png)

Secure Configuration Properties Module で設定された ​key​、​algorithm​、​mode​、​use random IV​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
#### [](#開発時にセキュア設定プロパティを確認する)開発時にセキュア設定プロパティを確認する Studio でアプリケーションを開発している場合、コネクタ接続をテストしてコネクタのセキュア設定プロパティが正しくセットアップされていることを確認できます。 次の例では、そのセキュアプロパティ (ユーザー名、パスワード、トークン) が ​`.yaml`​ ファイルで暗号化された Salesforce Connector 設定を示しています。 ![Salesforce 接続の設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-secure-config-properties-studio2.png) 値が暗号化されていない場合でもセキュアなプロパティファイル内のすべての値にアクセスできるように、​`secure::`​ プレフィックスがプロパティ名の定義の前に追加されます。 **\[Test Connection (接続をテスト)\]**​ をクリックすれば、接続が期待どおりに機能していることを確認し、セキュアなプロパティが正常に読み取られることを保証できます。 ## [](#ファイルレベル暗号化)ファイルレベル暗号化 セキュア設定プロパティモジュールのバージョン 1.1.0 以降では、各プロパティの値だけでなく、ファイル全体を暗号化できるようになっています。XML または Anypoint Studio の両方でファイルを暗号化できます。 XML フローで、​`fileLevelEncryption`​ 属性を追加して ​`true`​ に設定します。 ```xml ``` Studio の \[Secure Configuration Properties (セキュア設定プロパティ)\] ウィンドウで、​**\[File level encryption (ファイルレベル暗号化)\]**​ に ​**\[True\]**​ を選択します。 ![AES 暗号化と CBC モード設定が表示されているセキュアプロパティ設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-secure-config-properties-studio3.png) ## [](#セキュア設定プロパティのユースケース)セキュア設定プロパティのユースケース セキュア設定プロパティに関する次のユースケースを確認してください。このユースケースでは、フローで暗号化された値と暗号化されていない値を使用する方法、セキュア設定プロパティファイルを動的に設定する方法、複数の設定ファイルを使用する方法を学ぶことができます。 ### [](#暗号化された値と暗号化されていない値)暗号化された値と暗号化されていない値 次の例では、フローで暗号化された ​`encrypted.value1`​ 値を使用してペイロードを設定する方法を示しています。実行時には、復号化アルゴリズムによって ​`encrypted.value1`​ を復号化した値をメモリに格納します。 ```xml ``` 次の例では、フローで同じセキュアプロパティファイルから暗号化されていない値を使用する方法を示しています。 ```xml ``` ### [](#セキュア設定プロパティファイルを動的に設定する)セキュア設定プロパティファイルを動的に設定する 一般的な設定のユースケースとして、プロパティ (例: `env`​) によって使用するファイルを決定するようにファイルを設定することができます。 たとえば、開発フェーズ中に (暗号化できなかった) ​`development-properties`​ ファイルと (暗号化された値を使用する) 本番ファイルのどちらかを使用するように設定できます。 **環境ファイルが定義されたセキュア設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティの値によって、セキュア設定プロパティを読み込むために使用するファイルが決定されます。その ​`env`​ プロパティは、​`global property`​、システムプロパティ、または環境プロパティで設定することもできます。 **環境ファイルが定義されたセキュアなグローバル設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティのデフォルト値は ​`"dev"`​ になりますが、システムプロパティや環境プロパティで上書きすることはできます。Anypoint Studio では、この方法はメタデータの解決に​**必須**​となります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらのプロパティに連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 ### [](#複数の設定ファイルを操作する)複数の設定ファイルを操作する プロパティを読み込む設定ファイルを複数定義することができます。必要なのは、読み込みたい各ファイルに対して ​``​ タグを定義するだけです。各セキュア設定プロパティファイルは、それぞれの暗号化アルゴリズム、暗号化モード、そして暗号化/復号化キーによって独立して設定されます。これらの設定はファイル間で同じになるとは限りません。 次の例は、複数の設定ファイルの使用方法を示しています。 ```xml ``` ## [](#サポートされる設定ファイル種別)サポートされる設定ファイル種別 - Spring 形式のプロパティ: `.properties` - YAML: `.yaml` ## [](#supported_crypto)サポートされているアルゴリズムとモード ### [](#supported_algorithms)サポートされているアルゴリズム - AES (デフォルト) - Blowfish - DES - DESede - RC2 - RCA 次のアルゴリズムは、サポートが追加される [Java Cryptography Extension (JCE) プロバイダー](https://docs.oracle.com/cd/E19830-01/819-4712/ablsc/index.html)​を設定する場合のみ使用できます。 - Camellia - CAST5 - CAST6 - Noekeon - Rijndael - SEED - Serpent - Skipjack - TEA - Twofish - XTEA - RC5 - RC6 ### [](#supported_modes)サポートされているモード - CBC (デフォルト) - CFB - ECB - OFB ## [](#よくある質問と回答)よくある質問と回答 セキュア設定プロパティファイルについて学び、作成して、しばらく使用したら、トラブルシューティングおよびその最大限の活用法についてさらに疑問が生まれる可能性もあります。一般的な質問と回答をいくつか紹介します。「関連情報」でリンクしているトピックも参照してください。 **複数のファイルで同じプロパティを設定したらどうなりますか?** その場合は、最初に定義されたプロパティの値が実際のプロパティ値となります。 **以前に定義したセキュアプロパティに依存するセキュアプロパティを定義できますか?** はい。単に同じ構文を使用するだけです: `property=My dependent ${secure::dependent.property} value`​。 セキュア設定プロパティは他のセキュア設定プロパティには依存できますが、他の Mule 設定プロパティには依存できません。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties) - [Define and Secure Properties for a Mule Application in Anypoint Code Builder (Anypoint Code Builder での Mule アプリケーションのプロパティの定義と保護)](https://docs.mulesoft.com/jp/anypoint-code-builder/int-create-secure-configs) # セキュア設定プロパティ 設定プロパティはアプリケーションの別のセキュリティレベルとして暗号化できます。セキュア設定プロパティを作成するには、次のプロセスを確認してください。 1. セキュア設定プロパティファイルを作成します。 2. 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。 3. Mule Secure Configuration Properties Extension Module を使用してプロジェクトでファイルを設定します。ファイルでは復号化キーを参照するか、復号化キーが含まれている必要があります。 ## [](#属性)属性 セキュアなプロパティファイルを作成してそのプロパティを定義する前に、プロセスで使用されるセキュア設定プロパティ属性と暗号化属性を確認してください。
Table 1. セキュア設定プロパティの属性
属性名 説明

Name (名前)

グローバルセキュア設定プロパティの一意の名前。

Key (キー)

プロパティ値をロック解除するために指定する単語またはフレーズ。たとえば、​${production.myproperty}​ と指定すると、Mule Runtime Engine は実行時にキーを要求します。

ファイル

キーが復号化するファイルの場所。

Encoding (エンコード)

キーがロック解除するファイルのエンコード。デフォルト値は UTF-8 です。

File Level Encryption (ファイルレベル暗号化)

ファイル全体を暗号化する場合は ​true​ に設定します。デフォルト値は ​false​ です。
Table 2. セキュア設定プロパティの暗号化属性
属性名 説明

Algorithm (アルゴリズム)

プロパティのコンテンツを暗号化するために使用するアルゴリズムの種別。完全なリストについては、​サポートされているアルゴリズム​を参照してください。

Mode (モード)

Mule Runtime Engine が単一のキーでブロック暗号を繰り返し使用するためのプロシージャーです。完全なリストについては、​サポートされているモード​を参照してください。

Use random IVs (ランダム IV の使用)

ランダム初期化ベクトル (IV) を使用するには、この属性を ​true​ にします。このオプションを ​true​ に設定すると、復号化アルゴリズムは復号化操作中に IV が暗号テキストの先頭に追加されていると見なします。
## [](#セキュア設定プロパティファイルを作成する)セキュア設定プロパティファイルを作成する 設定プロパティをセキュアにする最初のタスクは、プロパティを定義する YAML 設定ファイル (​`.yaml`​) または Spring 形式のプロパティファイル (​`.properties`​) を作成することです。Mule Secure Configuration Properties Extension Module を使用すれば、YAML またはプロパティファイル種別を設定できます。 セキュア設定プロパティファイルは、Mule プロジェクトの ​`src/main/resources`​ で、または絶対パスを使用して作成できます。 ## [](#ファイルでセキュア設定プロパティを定義する)ファイルでセキュア設定プロパティを定義する 暗号化された値をシーケンス ​`![value]`​ 間に囲み、ファイルでセキュアプロパティを定義します。このファイルには、Mule アプリケーション内のどの場所でも使用できる暗号化された値と暗号化されていない値の両方を含むことができます。
オペレーティングシステムへのアクセスをセキュアにしてください。​ps​ コマンドを実行できたり、Java コンソールを表示できたりするユーザーであれば、Mule アプリケーションのメモリに格納されている復号化された値を見ることができてしまうからです。
次の ​`file1.yaml`​ の例には、暗号化された設定プロパティ値と暗号化されていない設定プロパティ値が含まれています。 encrypted: value1: "!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\]" value2: "!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\]" testPropertyA: "testValueA" testPropertyB: "testValueB"
暗号化された値は、文字列として読めるように引用符で囲む必要があります。
次の ​`file1.properties`​ の例には、前の例で使用した設定プロパティが含まれていますが、Spring 形式のプロパティファイルを使用しています。 encrypted.value1=!\[nHWo5JhNAYM+TzxqeHdRDXx15Q5R56YVGiQgXCoBCew=\] encrypted.value2=!\[nHWo6XyCADP+TzxqeHdRDXx15Q5R56YVGiQgXCoDFaj=\] testPropertyA=testValueA testPropertyB=testValueB ## [](#secure_props_tool)セキュアプロパティツールを使用してプロパティを暗号化する テキスト文字列、プロパティファイル内の値、またはプロパティファイルのすべてのコンテンツを暗号化または復号化するには、セキュアプロパティツールを使用します。 この記事で説明するすべての機能を使用するには、このツールの使用可能な最新バージョンを使用していることを確認してください。 [セキュアプロパティツール Jar ファイル - Java 17 をサポート](https://docs.mulesoft.com/jp/mule-runtime/4.9/_attachments/secure-properties-tool-j17.jar)​。 最新リリース: 2024 年 11 月 22 日。 構文は、以前のバージョンから変更されています。問題を回避するため、この記事で指定されている構文と JAR ファイルを使用してください。また、ツールの入力テキストでハッシュ文字 ​`#`​ を使用することはできません。 受け入れられるすべてのパラメーターの完全なリストおよび定義については、​[パラメーターリファレンス](#parameter-reference)​を参照してください。 ### [](#テキスト文字列を暗号化する)テキスト文字列を暗号化する 次の構文を使用して、パラメーターとして指定されたテキスト文字列を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - テキスト文字列を処理するようにツールを設定するには、​``​ を ​`string`​ に設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次の操作を実行するとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ string \ encrypt \ Blowfish \ CBC \ mulesoft \ "some value to encrypt" ``` この場合、ツールで次の内容が返されます。 ```console.linenums 8q5e1+jy0cND2iV2WPThahmz6XsDwB6Z ``` ### [](#ファイルを暗号化する)ファイルを暗号化する 文字列の処理に加えて、暗号化ツールでは ​`.yaml`​ または ​`.properties`​ ファイルも処理されます。プロパティファイル内の値、またはファイルのすべてのコンテンツを暗号化または復号化できます。 #### [](#ファイル内のプロパティを暗号化する)ファイル内のプロパティを暗号化する 次の構文を使用して、プロパティファイル内のすべての値を暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```yaml properties: example1: value: "![qCReIPK3jcqD7WR84ISSIQ==]" example2: "![En8lII21ZHrdIaINw0+mSA==]" ``` #### [](#ファイルのすべてのコンテンツを暗号化する)ファイルのすべてのコンテンツを暗号化する 次の構文を使用して、プロパティファイルのすべてのコンテンツを暗号化または復号化します。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ \ \ \ \ \ \ --use-random-iv [optional] ``` - ``​ を ​`file-level`​ に設定します。 - ``​ を処理するプロパティファイルに設定します。 - ``​ をプロセス後に生成されるファイルに設定します。 - 目的の操作が実行されるようにその他のパラメーターを指定します。 たとえば、次のコンテンツが含まれるファイル ​`example_in.yaml`​ を考えます。 ```yaml properties: example1: value: "Muleman is here" example2: "Max the mule" ``` 次の操作を実行したとします。 ```console.linenums java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \ file-level \ encrypt \ Blowfish \ CBC \ mulesoft \ example_in.yaml \ example_out.yaml ``` この場合、ツールで次のコンテンツが含まれるファイル ​`example_out.yaml`​ が生成されます。 ```txt k/J1EHyxJagOcyQELoaqIDCzzKc1bLGJiHY2dv6jzuhtVpP1LTlgK3y8EH7OkK5iuuu8kik3P5dCDMixZXwn/EV6xbUwLFKnEb4x1pUX6aopLP/KULm0pQ== ``` ### [](#parameter-reference)パラメーターリファレンス
パラメーター 説明

<method>

暗号化または復号化メソッドを設定します。可能な値:

string​

パラメーター ​<value>​ として指定された 1 つのテキスト文字列を暗号化します。

file​

パラメーター ​<input file>​ として指定されたプロパティファイルで設定された各プロパティの値を暗号化します。

file-level​

​<input file>​ として指定されたプロパティファイルのすべてのコンテンツを暗号化します。

<operation>

実行する操作を設定します。可能な値:

encrypt​

暗号化する操作を設定します。

decrypt​

復号化する操作を設定します。

<algorithm>

操作中に使用するアルゴリズムを指定します。
完全なリストについては、​サポートされているアルゴリズム​を参照してください。

<mode>

操作中に使用するモードを指定します。
完全なリストについては、​サポートされているモード​を参照してください。

<key>

操作中にファイルまたは値をロックまたはロック解除するために使用する単語を指定します。

  • キーで ​$​ 文字を使用する場合、その前に ​\​ を置く必要があります。 たとえば、キー ​myKey#$%123​ を使用するには、​<key>​ パラメーターを ​myKey#\$%123​ として指定する必要があります。

  • Java Cryptography Extension (JCE) バージョン 1.8.0_161​ 以降、AES キーの長さは 32 文字 (128 ビット) にする必要があります。

<value>

string​ 操作中に暗号化または復号化される文字列値を指定します。

<use random IV>

操作中にランダム初期化ベクトル (IV) が使用されるかどうかを指定します。

<input file>

file​ または ​file-level​ 操作中に暗号化または復号化されるプロパティファイルを指定します。

<output file>

file​ または ​file-level​ 操作後に作成される暗号化または復号化されたプロパティファイルを指定します。
## [](#プロジェクトでファイルを設定する)プロジェクトでファイルを設定する セキュアなプロパティファイルは、 [Exchange](https://anypoint.mulesoft.com/exchange/com.mulesoft.modules/mule-secure-configuration-property-module/)​ から入手できる Mule Secure Configuration Properties Extension Module を使用して、スタンドアロン XML と Anypoint Studio のどちらでも設定できます。 ### [](#xml-で-extension-module-を使用してファイルを設定する)XML で Extension Module を使用してファイルを設定する XML フローで、モジュール ​``​ を使用してファイルを設定します。次の例を確認してください。 **デフォルト値を使用したセキュア設定プロパティ** ```xml ``` - デフォルト値を使用する場合でも ​``​ タグは必要です。 - プレフィックス ​`secure::`​ はキーの読み込みに必要です。
セキュアなプロパティファイル内の値にアクセスするには、値が暗号化されていない場合でも ​secure::​ プレフィックスを使用する必要があります。これにより、設定全体を変更しなくてもファイル (または環境) を切り替えることができます。
- デプロイメント時に、復号化キーはシステム環境変数 ​`runtime.property`​ として Mule Runtime Engine に渡されます。このプロパティは、​`file1.yaml`​ ファイルに格納されている値を暗号化するために使用するのとまったく同じキーでなければなりません。 - デフォルトの暗号化アルゴリズムとモードが使用されます。 - たとえば、​`property.key1`​ プロパティの実際の (復号化された) 値が ​`"property"`​ であれば、​`prop`​ プロパティの値は ​`"my-property"`​ となります。 ``​ タグで追加の属性を設定して、暗号化アルゴリズムや暗号化モードを変更することもできます。 **カスタム値を使用したセキュア設定プロパティ** ```xml ``` 上の例で、​``​ タグでは ​`AES`​ アルゴリズム、​`CBC`​ モード、​`random IV`​ を使用しています。

<secure-properties:config>​ で設定された ​key​、​algorithm​、​mode​、​useRandomIVs​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
### [](#studio-で-extension-module-を使用してファイルを設定する)Studio で Extension Module を使用してファイルを設定する Anypoint Studio を使用してアプリケーションを開発している場合、Mule アプリケーションで連動関係として追加したモジュールを使用してセキュア設定プロパティを作成することもできます。 #### [](#extension-module-をインストールする)Extension Module をインストールする 1. Anypoint Studio で Mule プロジェクトを開きます。 2. \[Mule Palette (Mule パレット)\] セクションに移動します。 3. **\[Search in Exchange (Exchange 内を検索)\]**​ をクリックします。 4. \[Add Module to Project (モジュールをプロジェクトに追加)\] ウィンドウの ​**\[Type a search term to look up in Exchange (検索語を入力して Exchange 内で検索)\]**​ ボックスで、​**\[Mule Secure Configuration Property Extension (Mule セキュア設定プロパティ拡張)\]**​ を検索します。 5. リストでモジュール名を選択します。 6. **\[Add (追加)\]**​ に続いて ​**\[Finish (完了)\]**​ をクリックします。 #### [](#セキュア設定プロパティをアプリケーションに追加して設定する)セキュア設定プロパティをアプリケーションに追加して設定する 1. Mule アプリケーションの設定ファイルに移動します。 2. **\[Global Elements (グローバル要素)\]**​ タブを選択します。 3. **\[Create (作成)\]**​ をクリックします。 4. **\[Secure Properties Config (セキュアプロパティ設定)\]**​ を選択します。 5. **\[File (ファイル)\]**​ の場所、​**\[Key (キー)\]**​、​**\[Algorithm (アルゴリズム)\]**​、​**\[Mode (モード)\]**​、​**\[Use random IV (ランダム IV の使用)\]**​、​**\[File level encryption (ファイルレベル暗号化)\]**​、​**\[Encoding (エンコード)\]**​ を使用してグローバル要素を設定します。 6. **\[OK\]**​ をクリックします。 ![セキュアプロパティの設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-secure-config-properties-studio.png)

Secure Configuration Properties Module で設定された ​key​、​algorithm​、​mode​、​use random IV​ の値は、プロパティファイルを暗号化するために使用した値と一致する必要があります。
#### [](#開発時にセキュア設定プロパティを確認する)開発時にセキュア設定プロパティを確認する Studio でアプリケーションを開発している場合、コネクタ接続をテストしてコネクタのセキュア設定プロパティが正しくセットアップされていることを確認できます。 次の例では、そのセキュアプロパティ (ユーザー名、パスワード、トークン) が ​`.yaml`​ ファイルで暗号化された Salesforce Connector 設定を示しています。 ![Salesforce 接続の設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-secure-config-properties-studio2.png) 値が暗号化されていない場合でもセキュアなプロパティファイル内のすべての値にアクセスできるように、​`secure::`​ プレフィックスがプロパティ名の定義の前に追加されます。 **\[Test Connection (接続をテスト)\]**​ をクリックすれば、接続が期待どおりに機能していることを確認し、セキュアなプロパティが正常に読み取られることを保証できます。 ## [](#ファイルレベル暗号化)ファイルレベル暗号化 セキュア設定プロパティモジュールのバージョン 1.1.0 以降では、各プロパティの値だけでなく、ファイル全体を暗号化できるようになっています。XML または Anypoint Studio の両方でファイルを暗号化できます。 XML フローで、​`fileLevelEncryption`​ 属性を追加して ​`true`​ に設定します。 ```xml ``` Studio の \[Secure Configuration Properties (セキュア設定プロパティ)\] ウィンドウで、​**\[File level encryption (ファイルレベル暗号化)\]**​ に ​**\[True\]**​ を選択します。 ![AES 暗号化と CBC モード設定が表示されているセキュアプロパティ設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-secure-config-properties-studio3.png) ## [](#セキュア設定プロパティのユースケース)セキュア設定プロパティのユースケース セキュア設定プロパティに関する次のユースケースを確認してください。このユースケースでは、フローで暗号化された値と暗号化されていない値を使用する方法、セキュア設定プロパティファイルを動的に設定する方法、複数の設定ファイルを使用する方法を学ぶことができます。 ### [](#暗号化された値と暗号化されていない値)暗号化された値と暗号化されていない値 次の例では、フローで暗号化された ​`encrypted.value1`​ 値を使用してペイロードを設定する方法を示しています。実行時には、復号化アルゴリズムによって ​`encrypted.value1`​ を復号化した値をメモリに格納します。 ```xml ``` 次の例では、フローで同じセキュアプロパティファイルから暗号化されていない値を使用する方法を示しています。 ```xml ``` ### [](#セキュア設定プロパティファイルを動的に設定する)セキュア設定プロパティファイルを動的に設定する 一般的な設定のユースケースとして、プロパティ (例: `env`​) によって使用するファイルを決定するようにファイルを設定することができます。 たとえば、開発フェーズ中に (暗号化できなかった) ​`development-properties`​ ファイルと (暗号化された値を使用する) 本番ファイルのどちらかを使用するように設定できます。 **環境ファイルが定義されたセキュア設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティの値によって、セキュア設定プロパティを読み込むために使用するファイルが決定されます。その ​`env`​ プロパティは、​`global property`​、システムプロパティ、または環境プロパティで設定することもできます。 **環境ファイルが定義されたセキュアなグローバル設定プロパティ** ```xml ``` この方法を使用すると、​`env`​ プロパティのデフォルト値は ​`"dev"`​ になりますが、システムプロパティや環境プロパティで上書きすることはできます。Anypoint Studio では、この方法はメタデータの解決に​**必須**​となります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらのプロパティに連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 ### [](#複数の設定ファイルを操作する)複数の設定ファイルを操作する プロパティを読み込む設定ファイルを複数定義することができます。必要なのは、読み込みたい各ファイルに対して ​``​ タグを定義するだけです。各セキュア設定プロパティファイルは、それぞれの暗号化アルゴリズム、暗号化モード、そして暗号化/復号化キーによって独立して設定されます。これらの設定はファイル間で同じになるとは限りません。 次の例は、複数の設定ファイルの使用方法を示しています。 ```xml ``` ## [](#サポートされる設定ファイル種別)サポートされる設定ファイル種別 - Spring 形式のプロパティ: `.properties` - YAML: `.yaml` ## [](#supported_crypto)サポートされているアルゴリズムとモード ### [](#supported_algorithms)サポートされているアルゴリズム - AES (デフォルト) - Blowfish - DES - DESede - RC2 - RCA 次のアルゴリズムは、サポートが追加される [Java Cryptography Extension (JCE) プロバイダー](https://docs.oracle.com/cd/E19830-01/819-4712/ablsc/index.html)​を設定する場合のみ使用できます。 - Camellia - CAST5 - CAST6 - Noekeon - Rijndael - SEED - Serpent - Skipjack - TEA - Twofish - XTEA - RC5 - RC6 ### [](#supported_modes)サポートされているモード - CBC (デフォルト) - CFB - ECB - OFB ## [](#よくある質問と回答)よくある質問と回答 セキュア設定プロパティファイルについて学び、作成して、しばらく使用したら、トラブルシューティングおよびその最大限の活用法についてさらに疑問が生まれる可能性もあります。一般的な質問と回答をいくつか紹介します。「関連情報」でリンクしているトピックも参照してください。 **複数のファイルで同じプロパティを設定したらどうなりますか?** その場合は、最初に定義されたプロパティの値が実際のプロパティ値となります。 **以前に定義したセキュアプロパティに依存するセキュアプロパティを定義できますか?** はい。単に同じ構文を使用するだけです: `property=My dependent ${secure::dependent.property} value`​。 セキュア設定プロパティは他のセキュア設定プロパティには依存できますが、他の Mule 設定プロパティには依存できません。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties) - [Define and Secure Properties for a Mule Application in Anypoint Code Builder (Anypoint Code Builder での Mule アプリケーションのプロパティの定義と保護)](https://docs.mulesoft.com/jp/anypoint-code-builder/int-create-secure-configs) # セキュリティ 会社で保管され、ソフトウェアアプリケーションや Web サービスを介して提供される重要な情報のセキュリティを確保し、不正アクセスや悪意のある攻撃から保護することが重要です。その一方で、業務を円滑に遂行するためには、認証された正当なユーザーやシステムが保護されたリソース (クレジットカード情報や社会保障番号など) に速やかにアクセスできることも同じく重要です。 さまざまなセキュリティ手段を用いることで、情報、アプリケーション、サービスへの安全なアクセスを提供できます。Mule Runtime Engine (Mule) は、アプリケーションを保護するためのツールや方法をいくつか提供しています。 - アプリケーション設定プロパティの保護 - Cryptography Module の使用 - FIPS 140-2 認証環境の設定 - Spring セキュリティによるフローの保護 - TLS 暗号化プロトコルの設定 - OAuth 認証許可種別を使用した保護リソースへのアクセス許可 - Mule セキュアトークンサービスの設定 ## [](#セキュア設定プロパティ)セキュア設定プロパティ アプリケーションの設定プロパティを暗号化するには、セキュアな設定プロパティファイルを作成し、ファイルでセキュアなプロパティを定義して、Mule セキュア設定プロパティ拡張モジュールを使用してプロジェクト内でファイルを設定します。 詳細は​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/secure-configuration-properties)​を参照してください。 ## [](#cryptography-module)Cryptography Module Cryptography Module は、Mule アプリケーションに暗号化機能を提供します。この主な機能は次のとおりです。 - メッセージの対称暗号化および対称復号化。 - メッセージの非対称暗号化および非対称復号化。 - メッセージの署名と署名されたメッセージの署名検証。 このモジュールでは、メッセージを暗号化および署名する 3 つの戦略がサポートされています。 - JCE Java Cryptography Extension の暗号化機能を提供します。 - PGP Pretty Good Privacy を使用して署名と暗号化を提供します。 - XML XML ドキュメントまたは要素の署名と暗号化を提供します。 詳細は、​[「Cryptography Module」](https://docs.mulesoft.com/cryptography-module/latest/)​を参照してください。 ## [](#fips-140-2-コンプライアンスサポート)FIPS 140-2 コンプライアンスサポート 次の 2 つの要件を満足すれば、Mule 4 を FIPS 140-2 認証環境で実行するように設定できます。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule 設定が FIPS セキュリティモードで実行されるように調整されている。 詳細は​[「FIPS 140-2 コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.3/fips-140-2-compliance-support)​を参照してください。 ## [](#spring-セキュリティ)Spring セキュリティ Spring セキュリティは、JAAS、LDAP、CAS (イェール大学で開発された Central Authentication Service)、および DAO による認証を行います。以下のトピックでは、Spring セキュリティを使用したフローの保護を開始するのに役立つ情報を提供しています。 - [Spring セキュリティの LDAP プロバイダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/setting-up-ldap-provider-for-spring-security) コンポーネントの認証を実行するか、または Mule セキュリティプロバイダーとして使用します。 - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.3/component-authorization-using-spring-security) ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定します。 ## [](#tls-configuration-tls-設定)TLS Configuration (TLS 設定) TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。Mule 4.x は、Transport Layer Security (TLS) 1.1 および 1.2 をサポートしています。 詳細は​[「TLS の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tls-configuration)​を参照してください。 ## [](#oauth-認証許可種別)OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するのに使用できる認証許可種別には、認証コード、暗黙的、リソースオーナーのパスワードログイン情報、クライアントログイン情報の 4 つがあります。 詳細は​[「OAuth 認証許可種別」](https://docs.mulesoft.com/jp/mule-runtime/4.3/authorization-grant-types)​を参照してください。 ## [](#mule-セキュアトークンサービス)Mule セキュアトークンサービス Mule は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、ユーザーの OAuth ロールと目的によって異なります。 詳細は​[「Mule セキュアトークンサービス」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-secure-token-service)​を参照してください。 # セキュリティ 会社で保管され、ソフトウェアアプリケーションや Web サービスを介して提供される重要な情報のセキュリティを確保し、不正アクセスや悪意のある攻撃から保護することが重要です。その一方で、業務を円滑に遂行するためには、認証された正当なユーザーやシステムが保護されたリソース (クレジットカード情報や社会保障番号など) に速やかにアクセスできることも同じく重要です。 さまざまなセキュリティ手段を用いることで、情報、アプリケーション、サービスへの安全なアクセスを提供できます。Mule Runtime Engine (Mule) は、アプリケーションを保護するためのツールや方法をいくつか提供しています。 - アプリケーション設定プロパティの保護 - Cryptography Module の使用 - FIPS 140-2 認証環境の設定 - Spring セキュリティによるフローの保護 - TLS 暗号化プロトコルの設定 - OAuth 認証許可種別を使用した保護リソースへのアクセス許可 - Mule セキュアトークンサービスの設定 ## [](#セキュア設定プロパティ)セキュア設定プロパティ アプリケーションの設定プロパティを暗号化するには、セキュアな設定プロパティファイルを作成し、ファイルでセキュアなプロパティを定義して、Mule セキュア設定プロパティ拡張モジュールを使用してプロジェクト内でファイルを設定します。 詳細は​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/secure-configuration-properties)​を参照してください。 ## [](#cryptography-module)Cryptography Module Cryptography Module は、Mule アプリケーションに暗号化機能を提供します。この主な機能は次のとおりです。 - メッセージの対称暗号化および対称復号化。 - メッセージの非対称暗号化および非対称復号化。 - メッセージの署名と署名されたメッセージの署名検証。 このモジュールでは、メッセージを暗号化および署名する 3 つの戦略がサポートされています。 - JCE Java Cryptography Extension の暗号化機能を提供します。 - PGP Pretty Good Privacy を使用して署名と暗号化を提供します。 - XML XML ドキュメントまたは要素の署名と暗号化を提供します。 詳細は、​[「Cryptography Module」](https://docs.mulesoft.com/cryptography-module/latest/)​を参照してください。 ## [](#fips-140-2-コンプライアンスサポート)FIPS 140-2 コンプライアンスサポート 次の 2 つの要件を満足すれば、Mule 4 を FIPS 140-2 認証環境で実行するように設定できます。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule 設定が FIPS セキュリティモードで実行されるように調整されている。 詳細は​[「FIPS 140-2 コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.4/fips-140-2-compliance-support)​を参照してください。 ## [](#spring-セキュリティ)Spring セキュリティ Spring セキュリティは、JAAS、LDAP、CAS (イェール大学で開発された Central Authentication Service)、および DAO による認証を行います。以下のトピックでは、Spring セキュリティを使用したフローの保護を開始するのに役立つ情報を提供しています。 - [Spring セキュリティの LDAP プロバイダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/setting-up-ldap-provider-for-spring-security) コンポーネントの認証を実行するか、または Mule セキュリティプロバイダーとして使用します。 - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.4/component-authorization-using-spring-security) ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定します。 ## [](#tls-configuration-tls-設定)TLS Configuration (TLS 設定) TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。Mule 4.x は、Transport Layer Security (TLS) 1.1 および 1.2 をサポートしています。 詳細は​[「TLS の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tls-configuration)​を参照してください。 ## [](#oauth-認証許可種別)OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するのに使用できる認証許可種別には、認証コード、暗黙的、リソースオーナーのパスワードログイン情報、クライアントログイン情報の 4 つがあります。 詳細は​[「OAuth 認証許可種別」](https://docs.mulesoft.com/jp/mule-runtime/4.4/authorization-grant-types)​を参照してください。 ## [](#mule-セキュアトークンサービス)Mule セキュアトークンサービス Mule は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、ユーザーの OAuth ロールと目的によって異なります。 詳細は​[「Mule セキュアトークンサービス」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-secure-token-service)​を参照してください。 # セキュリティ 会社で保管され、ソフトウェアアプリケーションや Web サービスを介して提供される重要な情報のセキュリティを確保し、不正アクセスや悪意のある攻撃から保護することが重要です。その一方で、業務を円滑に遂行するためには、認証された正当なユーザーやシステムが保護されたリソース (クレジットカード情報や社会保障番号など) に速やかにアクセスできることも同じく重要です。 さまざまなセキュリティ手段を用いることで、情報、アプリケーション、サービスへの安全なアクセスを提供できます。Mule Runtime Engine (Mule) は、アプリケーションを保護するためのツールや方法をいくつか提供しています。 - アプリケーション設定プロパティの保護 - Cryptography Module の使用 - FIPS 140-2 認証環境の設定 - Spring セキュリティによるフローの保護 - TLS 暗号化プロトコルの設定 - OAuth 認証許可種別を使用した保護リソースへのアクセス許可 - Mule セキュアトークンサービスの設定 ## [](#セキュア設定プロパティ)セキュア設定プロパティ アプリケーションの設定プロパティを暗号化するには、セキュアな設定プロパティファイルを作成し、ファイルでセキュアなプロパティを定義して、Mule セキュア設定プロパティ拡張モジュールを使用してプロジェクト内でファイルを設定します。 詳細は​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/secure-configuration-properties)​を参照してください。 ## [](#cryptography-module)Cryptography Module Cryptography Module は、Mule アプリケーションに暗号化機能を提供します。この主な機能は次のとおりです。 - メッセージの対称暗号化および対称復号化。 - メッセージの非対称暗号化および非対称復号化。 - メッセージの署名と署名されたメッセージの署名検証。 このモジュールでは、メッセージを暗号化および署名する 3 つの戦略がサポートされています。 - JCE Java Cryptography Extension の暗号化機能を提供します。 - PGP Pretty Good Privacy を使用して署名と暗号化を提供します。 - XML XML ドキュメントまたは要素の署名と暗号化を提供します。 詳細は、​[「Cryptography Module」](https://docs.mulesoft.com/cryptography-module/latest/)​を参照してください。 ## [](#fips-140-2-コンプライアンスサポート)FIPS 140-2 コンプライアンスサポート 次の 2 つの要件を満足すれば、Mule 4 を FIPS 140-2 認証環境で実行するように設定できます。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule 設定が FIPS セキュリティモードで実行されるように調整されている。 詳細は​[「FIPS 140-2 コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.5/fips-140-2-compliance-support)​を参照してください。 ## [](#spring-セキュリティ)Spring セキュリティ Spring セキュリティは、JAAS、LDAP、CAS (イェール大学で開発された Central Authentication Service)、および DAO による認証を行います。以下のトピックでは、Spring セキュリティを使用したフローの保護を開始するのに役立つ情報を提供しています。 - [Spring セキュリティの LDAP プロバイダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/setting-up-ldap-provider-for-spring-security) コンポーネントの認証を実行するか、または Mule セキュリティプロバイダーとして使用します。 - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.5/component-authorization-using-spring-security) ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定します。 ## [](#tls-configuration-tls-設定)TLS Configuration (TLS 設定) TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。Mule 4.x は、Transport Layer Security (TLS) 1.1 および 1.2 をサポートしています。 詳細は​[「TLS の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tls-configuration)​を参照してください。 ## [](#oauth-認証許可種別)OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するのに使用できる認証許可種別には、認証コード、暗黙的、リソースオーナーのパスワードログイン情報、クライアントログイン情報の 4 つがあります。 詳細は​[「OAuth 認証許可種別」](https://docs.mulesoft.com/jp/mule-runtime/4.5/authorization-grant-types)​を参照してください。 ## [](#mule-セキュアトークンサービス)Mule セキュアトークンサービス Mule は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、ユーザーの OAuth ロールと目的によって異なります。 詳細は​[「Mule セキュアトークンサービス」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-secure-token-service)​を参照してください。 # セキュリティ 会社で保管され、ソフトウェアアプリケーションや Web サービスを介して提供される重要な情報のセキュリティを確保し、不正アクセスや悪意のある攻撃から保護することが重要です。その一方で、業務を円滑に遂行するためには、認証された正当なユーザーやシステムが保護されたリソース (クレジットカード情報や社会保障番号など) に速やかにアクセスできることも同じく重要です。 さまざまなセキュリティ手段を用いることで、情報、アプリケーション、サービスへの安全なアクセスを提供できます。Mule Runtime Engine (Mule) は、アプリケーションを保護するためのツールや方法をいくつか提供しています。 - アプリケーション設定プロパティの保護 - Cryptography Module の使用 - FIPS 140-2 認証環境の設定 - Spring セキュリティによるフローの保護 - TLS 暗号化プロトコルの設定 - OAuth 認証許可種別を使用した保護リソースへのアクセス許可 - Mule セキュアトークンサービスの設定 ## [](#セキュア設定プロパティ)セキュア設定プロパティ アプリケーションの設定プロパティを暗号化するには、セキュアな設定プロパティファイルを作成し、ファイルでセキュアなプロパティを定義して、Mule セキュア設定プロパティ拡張モジュールを使用してプロジェクト内でファイルを設定します。 詳細は​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/secure-configuration-properties)​を参照してください。 ## [](#cryptography-module)Cryptography Module Cryptography Module は、Mule アプリケーションに暗号化機能を提供します。この主な機能は次のとおりです。 - メッセージの対称暗号化および対称復号化。 - メッセージの非対称暗号化および非対称復号化。 - メッセージの署名と署名されたメッセージの署名検証。 このモジュールでは、メッセージを暗号化および署名する 3 つの戦略がサポートされています。 - JCE Java Cryptography Extension の暗号化機能を提供します。 - PGP Pretty Good Privacy を使用して署名と暗号化を提供します。 - XML XML ドキュメントまたは要素の署名と暗号化を提供します。 詳細は、​[「Cryptography Module」](https://docs.mulesoft.com/cryptography-module/latest/)​を参照してください。 ## [](#fips-140-2-コンプライアンスサポート)FIPS 140-2 コンプライアンスサポート 次の 2 つの要件を満足すれば、Mule 4 を FIPS 140-2 認証環境で実行するように設定できます。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule 設定が FIPS セキュリティモードで実行されるように調整されている。 詳細は​[「FIPS 140-2 コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.6/fips-140-2-compliance-support)​を参照してください。 ## [](#spring-セキュリティ)Spring セキュリティ Spring セキュリティは、JAAS、LDAP、CAS (イェール大学で開発された Central Authentication Service)、および DAO による認証を行います。以下のトピックでは、Spring セキュリティを使用したフローの保護を開始するのに役立つ情報を提供しています。 - [Spring セキュリティの LDAP プロバイダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/setting-up-ldap-provider-for-spring-security) コンポーネントの認証を実行するか、または Mule セキュリティプロバイダーとして使用します。 - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.6/component-authorization-using-spring-security) ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定します。 ## [](#tls-configuration-tls-設定)TLS Configuration (TLS 設定) TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。Mule 4.x は、Transport Layer Security (TLS) 1.1 および 1.2 をサポートしています。 詳細は​[「TLS の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tls-configuration)​を参照してください。 ## [](#oauth-認証許可種別)OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するのに使用できる認証許可種別には、認証コード、暗黙的、リソースオーナーのパスワードログイン情報、クライアントログイン情報の 4 つがあります。 詳細は​[「OAuth 認証許可種別」](https://docs.mulesoft.com/jp/mule-runtime/4.6/authorization-grant-types)​を参照してください。 ## [](#mule-セキュアトークンサービス)Mule セキュアトークンサービス Mule は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、ユーザーの OAuth ロールと目的によって異なります。 詳細は​[「Mule セキュアトークンサービス」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-secure-token-service)​を参照してください。 # セキュリティ 会社で保管され、ソフトウェアアプリケーションや Web サービスを介して提供される重要な情報のセキュリティを確保し、不正アクセスや悪意のある攻撃から保護することが重要です。その一方で、業務を円滑に遂行するためには、認証された正当なユーザーやシステムが保護されたリソース (クレジットカード情報や社会保障番号など) に速やかにアクセスできることも同じく重要です。 さまざまなセキュリティ手段を用いることで、情報、アプリケーション、サービスへの安全なアクセスを提供できます。Mule Runtime Engine (Mule) は、アプリケーションを保護するためのツールや方法をいくつか提供しています。 - アプリケーション設定プロパティの保護 - Cryptography Module の使用 - FIPS 140-2 認証環境の設定 - Spring セキュリティによるフローの保護 - TLS 暗号化プロトコルの設定 - OAuth 認証許可種別を使用した保護リソースへのアクセス許可 - Mule セキュアトークンサービスの設定 ## [](#セキュア設定プロパティ)セキュア設定プロパティ アプリケーションの設定プロパティを暗号化するには、セキュアな設定プロパティファイルを作成し、ファイルでセキュアなプロパティを定義して、Mule セキュア設定プロパティ拡張モジュールを使用してプロジェクト内でファイルを設定します。 詳細は​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/secure-configuration-properties)​を参照してください。 ## [](#cryptography-module)Cryptography Module Cryptography Module は、Mule アプリケーションに暗号化機能を提供します。この主な機能は次のとおりです。 - メッセージの対称暗号化および対称復号化。 - メッセージの非対称暗号化および非対称復号化。 - メッセージの署名と署名されたメッセージの署名検証。 このモジュールでは、メッセージを暗号化および署名する 3 つの戦略がサポートされています。 - JCE Java Cryptography Extension の暗号化機能を提供します。 - PGP Pretty Good Privacy を使用して署名と暗号化を提供します。 - XML XML ドキュメントまたは要素の署名と暗号化を提供します。 詳細は、​[「Cryptography Module」](https://docs.mulesoft.com/cryptography-module/latest/)​を参照してください。 ## [](#fips-140-2-コンプライアンスサポート)FIPS 140-2 コンプライアンスサポート 次の 2 つの要件を満足すれば、Mule 4 を FIPS 140-2 認証環境で実行するように設定できます。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule 設定が FIPS セキュリティモードで実行されるように調整されている。 詳細は​[「FIPS 140-2 コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.7/fips-140-2-compliance-support)​を参照してください。 ## [](#spring-セキュリティ)Spring セキュリティ Spring セキュリティは、JAAS、LDAP、CAS (イェール大学で開発された Central Authentication Service)、および DAO による認証を行います。以下のトピックでは、Spring セキュリティを使用したフローの保護を開始するのに役立つ情報を提供しています。 - [Spring セキュリティの LDAP プロバイダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/setting-up-ldap-provider-for-spring-security) コンポーネントの認証を実行するか、または Mule セキュリティプロバイダーとして使用します。 - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.7/component-authorization-using-spring-security) ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定します。 ## [](#tls-configuration-tls-設定)TLS Configuration (TLS 設定) TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。Mule 4.x は、Transport Layer Security (TLS) 1.1 および 1.2 をサポートしています。 詳細は​[「TLS の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tls-configuration)​を参照してください。 ## [](#oauth-認証許可種別)OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するのに使用できる認証許可種別には、認証コード、暗黙的、リソースオーナーのパスワードログイン情報、クライアントログイン情報の 4 つがあります。 詳細は​[「OAuth 認証許可種別」](https://docs.mulesoft.com/jp/mule-runtime/4.7/authorization-grant-types)​を参照してください。 ## [](#mule-セキュアトークンサービス)Mule セキュアトークンサービス Mule は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、ユーザーの OAuth ロールと目的によって異なります。 詳細は​[「Mule セキュアトークンサービス」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-secure-token-service)​を参照してください。 # セキュリティ 会社で保管され、ソフトウェアアプリケーションや Web サービスを介して提供される重要な情報のセキュリティを確保し、不正アクセスや悪意のある攻撃から保護することが重要です。その一方で、業務を円滑に遂行するためには、認証された正当なユーザーやシステムが保護されたリソース (クレジットカード情報や社会保障番号など) に速やかにアクセスできることも同じく重要です。 さまざまなセキュリティ手段を用いることで、情報、アプリケーション、サービスへの安全なアクセスを提供できます。Mule Runtime Engine (Mule) は、アプリケーションを保護するためのツールや方法をいくつか提供しています。 - アプリケーション設定プロパティの保護 - Cryptography Module の使用 - FIPS 140-2 認証環境の設定 - Spring セキュリティによるフローの保護 - TLS 暗号化プロトコルの設定 - OAuth 認証許可種別を使用した保護リソースへのアクセス許可 - Mule セキュアトークンサービスの設定 ## [](#セキュア設定プロパティ)セキュア設定プロパティ アプリケーションの設定プロパティを暗号化するには、セキュアな設定プロパティファイルを作成し、ファイルでセキュアなプロパティを定義して、Mule セキュア設定プロパティ拡張モジュールを使用してプロジェクト内でファイルを設定します。 詳細は​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/secure-configuration-properties)​を参照してください。 ## [](#cryptography-module)Cryptography Module Cryptography Module は、Mule アプリケーションに暗号化機能を提供します。この主な機能は次のとおりです。 - メッセージの対称暗号化および対称復号化。 - メッセージの非対称暗号化および非対称復号化。 - メッセージの署名と署名されたメッセージの署名検証。 このモジュールでは、メッセージを暗号化および署名する 3 つの戦略がサポートされています。 - JCE Java Cryptography Extension の暗号化機能を提供します。 - PGP Pretty Good Privacy を使用して署名と暗号化を提供します。 - XML XML ドキュメントまたは要素の署名と暗号化を提供します。 詳細は、​[「Cryptography Module」](https://docs.mulesoft.com/cryptography-module/latest/)​を参照してください。 ## [](#fips-140-2-コンプライアンスサポート)FIPS 140-2 コンプライアンスサポート 次の 2 つの要件を満足すれば、Mule 4 を FIPS 140-2 認証環境で実行するように設定できます。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule 設定が FIPS セキュリティモードで実行されるように調整されている。 詳細は​[「FIPS 140-2 コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.8/fips-140-2-compliance-support)​を参照してください。 ## [](#spring-セキュリティ)Spring セキュリティ Spring セキュリティは、JAAS、LDAP、CAS (イェール大学で開発された Central Authentication Service)、および DAO による認証を行います。以下のトピックでは、Spring セキュリティを使用したフローの保護を開始するのに役立つ情報を提供しています。 - [Spring セキュリティの LDAP プロバイダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/setting-up-ldap-provider-for-spring-security) コンポーネントの認証を実行するか、または Mule セキュリティプロバイダーとして使用します。 - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.8/component-authorization-using-spring-security) ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定します。 ## [](#tls-configuration-tls-設定)TLS Configuration (TLS 設定) TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。Mule 4.x は、Transport Layer Security (TLS) 1.1 および 1.2 をサポートしています。 詳細は​[「TLS の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tls-configuration)​を参照してください。 ## [](#oauth-認証許可種別)OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するのに使用できる認証許可種別には、認証コード、暗黙的、リソースオーナーのパスワードログイン情報、クライアントログイン情報の 4 つがあります。 詳細は​[「OAuth 認証許可種別」](https://docs.mulesoft.com/jp/mule-runtime/4.8/authorization-grant-types)​を参照してください。 ## [](#mule-セキュアトークンサービス)Mule セキュアトークンサービス Mule は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、ユーザーの OAuth ロールと目的によって異なります。 詳細は​[「Mule セキュアトークンサービス」](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-secure-token-service)​を参照してください。 # セキュリティ 会社で保管され、ソフトウェアアプリケーションや Web サービスを介して提供される重要な情報のセキュリティを確保し、不正アクセスや悪意のある攻撃から保護することが重要です。その一方で、業務を円滑に遂行するためには、認証された正当なユーザーやシステムが保護されたリソース (クレジットカード情報や社会保障番号など) に速やかにアクセスできることも同じく重要です。 さまざまなセキュリティ手段を用いることで、情報、アプリケーション、サービスへの安全なアクセスを提供できます。Mule Runtime Engine (Mule) は、アプリケーションを保護するためのツールや方法をいくつか提供しています。 - アプリケーション設定プロパティの保護 - Cryptography Module の使用 - FIPS 140-2 認証環境の設定 - Spring セキュリティによるフローの保護 - TLS 暗号化プロトコルの設定 - OAuth 認証許可種別を使用した保護リソースへのアクセス許可 - Mule セキュアトークンサービスの設定 ## [](#セキュア設定プロパティ)セキュア設定プロパティ アプリケーションの設定プロパティを暗号化するには、セキュアな設定プロパティファイルを作成し、ファイルでセキュアなプロパティを定義して、Mule セキュア設定プロパティ拡張モジュールを使用してプロジェクト内でファイルを設定します。 詳細は​[「セキュア設定プロパティ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/secure-configuration-properties)​を参照してください。 ## [](#cryptography-module)Cryptography Module Cryptography Module は、Mule アプリケーションに暗号化機能を提供します。この主な機能は次のとおりです。 - メッセージの対称暗号化および対称復号化。 - メッセージの非対称暗号化および非対称復号化。 - メッセージの署名と署名されたメッセージの署名検証。 このモジュールでは、メッセージを暗号化および署名する 3 つの戦略がサポートされています。 - JCE Java Cryptography Extension の暗号化機能を提供します。 - PGP Pretty Good Privacy を使用して署名と暗号化を提供します。 - XML XML ドキュメントまたは要素の署名と暗号化を提供します。 詳細は、​[「Cryptography Module」](https://docs.mulesoft.com/cryptography-module/latest/)​を参照してください。 ## [](#fips-140-2-コンプライアンスサポート)FIPS 140-2 コンプライアンスサポート 次の 2 つの要件を満足すれば、Mule 4 を FIPS 140-2 認証環境で実行するように設定できます。 - 認証済みの Cryptography Module が Java 環境にインストールされている。 - Mule 設定が FIPS セキュリティモードで実行されるように調整されている。 詳細は​[「FIPS 140-2 コンプライアンスサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.9/fips-140-2-compliance-support)​を参照してください。 ## [](#spring-セキュリティ)Spring セキュリティ Spring セキュリティは、JAAS、LDAP、CAS (イェール大学で開発された Central Authentication Service)、および DAO による認証を行います。以下のトピックでは、Spring セキュリティを使用したフローの保護を開始するのに役立つ情報を提供しています。 - [Spring セキュリティの LDAP プロバイダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/setting-up-ldap-provider-for-spring-security) コンポーネントの認証を実行するか、または Mule セキュリティプロバイダーとして使用します。 - [Spring セキュリティを使用したコンポーネントの認証](https://docs.mulesoft.com/jp/mule-runtime/4.9/component-authorization-using-spring-security) ユーザーが呼び出せるメソッドをロールごとに限定するために、Spring セキュリティ機能を使用した認証を Mule コンポーネントで設定します。 ## [](#tls-configuration-tls-設定)TLS Configuration (TLS 設定) TLS は、Mule アプリケーションの通信セキュリティを確保する暗号化プロトコルです。Mule 4.x は、Transport Layer Security (TLS) 1.1 および 1.2 をサポートしています。 詳細は​[「TLS の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tls-configuration)​を参照してください。 ## [](#oauth-認証許可種別)OAuth 認証許可種別 OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するのに使用できる認証許可種別には、認証コード、暗黙的、リソースオーナーのパスワードログイン情報、クライアントログイン情報の 4 つがあります。 詳細は​[「OAuth 認証許可種別」](https://docs.mulesoft.com/jp/mule-runtime/4.9/authorization-grant-types)​を参照してください。 ## [](#mule-セキュアトークンサービス)Mule セキュアトークンサービス Mule は OAuth 2.0 プロトコルをサポートしています。OAuth 2.0 認証の設定方法は、ユーザーの OAuth ロールと目的によって異なります。 詳細は​[「Mule セキュアトークンサービス」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-secure-token-service)​を参照してください。 # セキュリティ検索条件の移行 Mule 3 では、セキュリティ検索条件は Mule Module セキュリティの一部でした。Mule 4 では、​[Mule Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ に移行されました。 ## [](#ip-検索条件)IP 検索条件 Mule 3 では、IP で絞り込むための 3 つの異なるオプションがありました: \* `` \* `` \* `` ### [](#1-つの-ip-による絞り込み)1 つの IP による絞り込み 例: Mule 3 での 1 つの IP による絞り込み ```xml ``` これにより、正規表現に一致する IP に絞り込まれます。Mule 4 では次のようになります。 例: Mule 4 での 1 つの IP による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 ### [](#ip-の範囲による絞り込み)IP の範囲による絞り込み Mule 3 では、サブネットマスクを定義して絞り込む 2 つの方法がありました。 例: Mule 3 での IP 範囲による絞り込み ```xml ``` いずれも、次の方法によって置き換えられます。 例: Mule 4 での IP 範囲による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、IP 検索条件リストに記載された IP のみを許可するホワイトリスト検証もあります。 ## [](#時間経過検索条件)時間経過検索条件 Mule 3 では、開始日から定義された一定期間を経過したメッセージを絞り込むことができました。例: 例: Mule 3 での経過時間による絞り込み ```xml ``` Mule 4 では、この検証は Validation Module にあります。 例: Mule 4 での経過時間による絞り込み ```xml ``` 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、経過時間が一定の時間を超えた場合に検証する経過時間検証もあります。 ## [](#関連情報)関連情報 [Validation Connector テクニカルリファレンス](https://docs.mulesoft.com/jp/validation-connector/latest/validation-documentation) # セキュリティ検索条件の移行

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Mule 3 では、セキュリティ検索条件は Mule Module セキュリティの一部でした。Mule 4 では、​[Mule Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ に移行されました。 ## [](#ip-検索条件)IP 検索条件 Mule 3 では、IP で絞り込むための 3 つの異なるオプションがありました: \* `` \* `` \* `` ### [](#1-つの-ip-による絞り込み)1 つの IP による絞り込み 例: Mule 3 での 1 つの IP による絞り込み ```xml ``` これにより、正規表現に一致する IP に絞り込まれます。Mule 4 では次のようになります。 例: Mule 4 での 1 つの IP による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 ### [](#ip-の範囲による絞り込み)IP の範囲による絞り込み Mule 3 では、サブネットマスクを定義して絞り込む 2 つの方法がありました。 例: Mule 3 での IP 範囲による絞り込み ```xml ``` いずれも、次の方法によって置き換えられます。 例: Mule 4 での IP 範囲による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、IP 検索条件リストに記載された IP のみを許可するホワイトリスト検証もあります。 ## [](#時間経過検索条件)時間経過検索条件 Mule 3 では、開始日から定義された一定期間を経過したメッセージを絞り込むことができました。例: 例: Mule 3 での経過時間による絞り込み ```xml ``` Mule 4 では、この検証は Validation Module にあります。 例: Mule 4 での経過時間による絞り込み ```xml ``` 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、経過時間が一定の時間を超えた場合に検証する経過時間検証もあります。 ## [](#関連情報)関連情報 [Validation Connector テクニカルリファレンス](https://docs.mulesoft.com/jp/validation-connector/latest/validation-documentation) # セキュリティ検索条件の移行

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Mule 3 では、セキュリティ検索条件は Mule Module セキュリティの一部でした。Mule 4 では、​[Mule Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ に移行されました。 ## [](#ip-検索条件)IP 検索条件 Mule 3 では、IP で絞り込むための 3 つの異なるオプションがありました: \* `` \* `` \* `` ### [](#1-つの-ip-による絞り込み)1 つの IP による絞り込み 例: Mule 3 での 1 つの IP による絞り込み ```xml ``` これにより、正規表現に一致する IP に絞り込まれます。Mule 4 では次のようになります。 例: Mule 4 での 1 つの IP による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 ### [](#ip-の範囲による絞り込み)IP の範囲による絞り込み Mule 3 では、サブネットマスクを定義して絞り込む 2 つの方法がありました。 例: Mule 3 での IP 範囲による絞り込み ```xml ``` いずれも、次の方法によって置き換えられます。 例: Mule 4 での IP 範囲による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、IP 検索条件リストに記載された IP のみを許可するホワイトリスト検証もあります。 ## [](#時間経過検索条件)時間経過検索条件 Mule 3 では、開始日から定義された一定期間を経過したメッセージを絞り込むことができました。例: 例: Mule 3 での経過時間による絞り込み ```xml ``` Mule 4 では、この検証は Validation Module にあります。 例: Mule 4 での経過時間による絞り込み ```xml ``` 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、経過時間が一定の時間を超えた場合に検証する経過時間検証もあります。 ## [](#関連情報)関連情報 ​[Validation Connector テクニカルリファレンス](https://docs.mulesoft.com/jp/validation-connector/latest/validation-documentation) # セキュリティ検索条件の移行

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Mule 3 では、セキュリティ検索条件は Mule Module セキュリティの一部でした。Mule 4 では、​[Mule Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ に移行されました。 ## [](#ip-検索条件)IP 検索条件 Mule 3 では、IP で絞り込むための 3 つの異なるオプションがありました: \* `` \* `` \* `` ### [](#1-つの-ip-による絞り込み)1 つの IP による絞り込み 例: Mule 3 での 1 つの IP による絞り込み ```xml ``` これにより、正規表現に一致する IP に絞り込まれます。Mule 4 では次のようになります。 例: Mule 4 での 1 つの IP による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 ### [](#ip-の範囲による絞り込み)IP の範囲による絞り込み Mule 3 では、サブネットマスクを定義して絞り込む 2 つの方法がありました。 例: Mule 3 での IP 範囲による絞り込み ```xml ``` いずれも、次の方法によって置き換えられます。 例: Mule 4 での IP 範囲による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、IP 検索条件リストに記載された IP のみを許可するホワイトリスト検証もあります。 ## [](#時間経過検索条件)時間経過検索条件 Mule 3 では、開始日から定義された一定期間を経過したメッセージを絞り込むことができました。例: 例: Mule 3 での経過時間による絞り込み ```xml ``` Mule 4 では、この検証は Validation Module にあります。 例: Mule 4 での経過時間による絞り込み ```xml ``` 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、経過時間が一定の時間を超えた場合に検証する経過時間検証もあります。 ## [](#関連情報)関連情報 [Validation Connector テクニカルリファレンス](https://docs.mulesoft.com/jp/validation-connector/latest/validation-documentation) # セキュリティ検索条件の移行

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Mule 3 では、セキュリティ検索条件は Mule Module セキュリティの一部でした。Mule 4 では、​[Mule Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ に移行されました。 ## [](#ip-検索条件)IP 検索条件 Mule 3 では、IP で絞り込むための 3 つの異なるオプションがありました: \* `` \* `` \* `` ### [](#1-つの-ip-による絞り込み)1 つの IP による絞り込み 例: Mule 3 での 1 つの IP による絞り込み ```xml ``` これにより、正規表現に一致する IP に絞り込まれます。Mule 4 では次のようになります。 例: Mule 4 での 1 つの IP による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 ### [](#ip-の範囲による絞り込み)IP の範囲による絞り込み Mule 3 では、サブネットマスクを定義して絞り込む 2 つの方法がありました。 例: Mule 3 での IP 範囲による絞り込み ```xml ``` いずれも、次の方法によって置き換えられます。 例: Mule 4 での IP 範囲による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、IP 検索条件リストに記載された IP のみを許可するホワイトリスト検証もあります。 ## [](#時間経過検索条件)時間経過検索条件 Mule 3 では、開始日から定義された一定期間を経過したメッセージを絞り込むことができました。例: 例: Mule 3 での経過時間による絞り込み ```xml ``` Mule 4 では、この検証は Validation Module にあります。 例: Mule 4 での経過時間による絞り込み ```xml ``` 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、経過時間が一定の時間を超えた場合に検証する経過時間検証もあります。 ## [](#関連情報)関連情報 [Validation Connector テクニカルリファレンス](https://docs.mulesoft.com/jp/validation-connector/latest/validation-documentation) # セキュリティ検索条件の移行

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Mule 3 では、セキュリティ検索条件は Mule Module セキュリティの一部でした。Mule 4 では、​[Mule Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ に移行されました。 ## [](#ip-検索条件)IP 検索条件 Mule 3 では、IP で絞り込むための 3 つの異なるオプションがありました: \* `` \* `` \* `` ### [](#1-つの-ip-による絞り込み)1 つの IP による絞り込み 例: Mule 3 での 1 つの IP による絞り込み ```xml ``` これにより、正規表現に一致する IP に絞り込まれます。Mule 4 では次のようになります。 例: Mule 4 での 1 つの IP による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 ### [](#ip-の範囲による絞り込み)IP の範囲による絞り込み Mule 3 では、サブネットマスクを定義して絞り込む 2 つの方法がありました。 例: Mule 3 での IP 範囲による絞り込み ```xml ``` いずれも、次の方法によって置き換えられます。 例: Mule 4 での IP 範囲による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、IP 検索条件リストに記載された IP のみを許可するホワイトリスト検証もあります。 ## [](#時間経過検索条件)時間経過検索条件 Mule 3 では、開始日から定義された一定期間を経過したメッセージを絞り込むことができました。例: 例: Mule 3 での経過時間による絞り込み ```xml ``` Mule 4 では、この検証は Validation Module にあります。 例: Mule 4 での経過時間による絞り込み ```xml ``` 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、経過時間が一定の時間を超えた場合に検証する経過時間検証もあります。 ## [](#関連情報)関連情報 [Validation Connector テクニカルリファレンス](https://docs.mulesoft.com/jp/validation-connector/latest/validation-documentation) # セキュリティ検索条件の移行

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Mule 3 では、セキュリティ検索条件は Mule Module セキュリティの一部でした。Mule 4 では、​[Mule Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ に移行されました。 ## [](#ip-検索条件)IP 検索条件 Mule 3 では、IP で絞り込むための 3 つの異なるオプションがありました: \* `` \* `` \* `` ### [](#1-つの-ip-による絞り込み)1 つの IP による絞り込み 例: Mule 3 での 1 つの IP による絞り込み ```xml ``` これにより、正規表現に一致する IP に絞り込まれます。Mule 4 では次のようになります。 例: Mule 4 での 1 つの IP による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 ### [](#ip-の範囲による絞り込み)IP の範囲による絞り込み Mule 3 では、サブネットマスクを定義して絞り込む 2 つの方法がありました。 例: Mule 3 での IP 範囲による絞り込み ```xml ``` いずれも、次の方法によって置き換えられます。 例: Mule 4 での IP 範囲による絞り込み ```xml ``` この場合、その ​`ip`​ 変数を設定する必要があります (または、適合するいずれかの変数)。 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、IP 検索条件リストに記載された IP のみを許可するホワイトリスト検証もあります。 ## [](#時間経過検索条件)時間経過検索条件 Mule 3 では、開始日から定義された一定期間を経過したメッセージを絞り込むことができました。例: 例: Mule 3 での経過時間による絞り込み ```xml ``` Mule 4 では、この検証は Validation Module にあります。 例: Mule 4 での経過時間による絞り込み ```xml ``` 1. _他に Mule 4 で追加された同様の検証はありますか?_ はい、経過時間が一定の時間を超えた場合に検証する経過時間検証もあります。 ## [](#関連情報)関連情報 [Validation Connector テクニカルリファレンス](https://docs.mulesoft.com/jp/validation-connector/latest/validation-documentation) # チュートリアル: 「Hello World」Mule アプリケーションの作成 このチュートリアルでは、Web ブラウザーから送信された要求に対して「Hello Mule」というメッセージを返す例を使用して、Mule アプリケーションがどのようにやり取りするのかをシンプルな HTTP 要求-返信フローで実際に示します。 この例は非常にシンプルです。より複雑なアプリケーションでは、外部サーバー (SAP、Salesforce、データベース、FTP サーバーなど) への接続、Mule プロジェクト内での API 仕様の直接インポートと実装、セキュリティのセットアップ、データの処理や変換などをプログラムで行うことができます。これらの作業の説明は、この例の範囲を超えています。 ![Hello Mule](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule.png) Figure 1. Anypoint Studio での hellomule このアプリケーションは、Anypoint Studio でプロジェクトとしてセットアップして実行します。 ## [](#前提条件)前提条件 - [Anypoint Studio 7](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [「Anypoint Studio」](https://docs.mulesoft.com/studio/)​に説明されている Anypoint Studio UI (パレット、キャンバス、フロー) の操作に関する知識 Anypoint Studio をインストールしたら、例をセットアップして実行できます。 ## [](#例のしくみ)例のしくみ Hello Mule の例は、1 つのシンプルな Mule フローで構成されています。このフローは、HTTP 要求を受け入れ、メッセージに対して静的ペイロードを設定して、応答を返します。 インバウンド HTTP エンドポイントは、Web サービスに対して送信された要求を受け取ります。 メッセージ交換パターンは要求-応答であるため、HTTP エンドポイントはメッセージの受信と返信を管理します。 Set Payload コンポーネントは、その名前が示すようにメッセージペイロードに値を設定します。この例では、値として DataWeave 式を使用して静的文字列をペイロードに対して設定します。 ## [](#例をセットアップする)例をセットアップする 以下の手順に従って、自分の Anypoint Studio インスタンスで例を作成してください。Anypoint Studio でテンプレートアプリケーションを作成し、ユースケースに基づいたテンプレートの設定を調整することで、Mule でカスタムアプリケーションを作成することができます。 1. Anypoint Studio で ​`hellomule`​ という名前のプロジェクトを作成します。 1. **\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Project (Mule プロジェクト)\]**​ を選択し、表示されたダイアログの ​**\[Project Name (プロジェクト名)\]**​ に「hellomule」と入力します。 ![Hello Mule](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule-create-project.png) プロジェクト名には、空白スペースを含めません。 2. **\[Finish (完了)\]**​ をクリックします。 2. HTTP Listener コンポーネントを ​**hellomule**​ のキャンバスにドラッグします。 1. プロジェクトの ​**\[Mule Palette (Mule パレット)\]**​ タブで ​**\[HTTP\]**​ をクリックします。 ![Mule パレットの HTTP Connector](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule-empty-canvas.png) 2. **Listener**​ コンポーネントを ​**hellomuleFlow**​ キャンバスにドラッグします。 ![HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule-listener-config.png) **\[Listener\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Listener**​ コンポーネントをクリックして開きます。 タブ内に赤いボックスが表示されていますが、これは ​**\[Connector configuration (設定)\]**​ と ​**\[Path (パス)\]**​ の項目に値が必要であるためです。 3. **\[Listener\]**​ タブで ​**Listener**​ コンポーネントを設定します。 ![HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule-listener-path.png) 1. リスナーの ​**\[Path (パス)\]**​ 項目にパス ​`/hellomule`​ を入力します。 2. リスナーの ​**\[Connector configuration (設定)\]**​ 項目の下にある緑色のプラスアイコン (​**+**​) をクリックして、​**\[HTTP Listener config (HTTP Listener 設定)\]**​ ダイアログを開きます。 3. ダイアログで ​**\[Test Connection (接続をテスト)\]**​ をクリックして、デフォルトのリスナー設定を確認します。 ![リスナー接続のテスト、90%](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule-test-connection.png) - 接続に成功すると、​**\[Test connection (接続をテスト)\]**​ ダイアログが開いて「Test connection successful! (テスト正続に成功しました)」と表示されます。 - 接続に失敗した場合は、使用していないポート番号 (​`8082`​ や ​`8083`​ など) を使用して接続を再テストしてから、設定を追加してください。 4. **\[OK\]**​ をクリックして、有効な設定をプロジェクトに追加します。 4. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Set Payload**​ コンポーネントを見つけてキャンバスの ​**\[Process (プロセス)\]**​ エリアにドラッグします。 ![Set Payload の設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule-payload-config.png) - **Set Payload**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Set Payload\]**​ タブの設定 UI が開いていない場合は、​**Set Payload**​ コンポーネントをクリックして設定 UI を開いてください。 5. **Set Payload**​ コンポーネントの ​**\[Value (値)\]**​ 項目で ​**\[fx\]**​ 項目を​_選択解除して_​、文字列 ​`"Hello Mule!"`​ を入力します。 **\[fx\]**​ の選択を解除すると、項目の内容は文字列 ​`"Hello Mule"`​ のみとなり、ハッシュ (​`#`​) や角括弧 (​`[]`​) は​_含まれません_​。 6. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Logger**​ コンポーネントを探して Transform Message コンポーネントの右側にドラッグします。 ![Hello Mule のロガー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule-logger.png) - **Logger**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Logger\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Logger**​ コンポーネントをクリックして開きます。 7. ロガーの ​**\[Message (メッセージ)\]**​ 項目で、​**\[fx\]**​ ボタンをクリックして、要求パスを Anypoint Studio コンソールに出力するために次の DataWeave 式を追加します。 `attributes.requestPath` 8. Anypoint Studio で ​**\[File (ファイル)\]**​ > ​**\[Save (保存)\]**​ を選択してプロジェクトを保存します。 9. [Hello Mule の例を実行してテストする](#run_example)​に進みます。 ## [](#run_example)Hello Mule の例を実行してテストする Anypoint Studio で Hello Mule をセットアップしたら、実行してテストします。 1. Anypoint Studio キャンバスを右クリックし、​**\[Run project hellomule (hellomule プロジェクトを実行)\]**​ を選択して ​**hellomule**​ アプリケーションを実行します。 ![Hello Mule の実行](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule-run.png) または、Anypoint Studio の一番上にある 「Run (実行)」 ボタン (​![「Run (実行)」 ボタン](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-run-button.png)) をクリックして、表示されたドロップダウンメニューから ​**hellomule**​ を選択することもできます。 どちらの操作を実行した場合もビルドプロセスが開始され、Anypoint Studio コンソールが開いて、2 フェーズのビルドおよびデプロイメントプロセスに関する重要なログ情報が表示されます。 最後が次のようになっているメッセージが Anypoint Studio コンソールに表示されれば、プロジェクトは実行中です。 ```txt ********************************************************** * - - + DOMAIN + - - * - - + STATUS + - - * ********************************************************** * default * DEPLOYED * ********************************************************** ******************************************************************************* * - - + APPLICATION + - - * - - + DOMAIN + - - * - - + STATUS + - - * ******************************************************************************* * hellomule * default * DEPLOYED * ******************************************************************************* ``` `DEPLOYED`​ 通知ではなく失敗通知 (​`FAILED`​) が表示された場合は、エラーメッセージを確認してください。次のようなメッセージが表示された場合は、HTTP Listener の設定で別の HTTP ポートを指定してください。 ```txt Could not create server: A server in port(8081) already exists for host(0.0.0.0) or one overlapping it (0.0.0.0).` ``` その後、プロジェクトを保存して再実行します。エラーが繰り返される場合は、ホストを ​`localhost`​ に変更してみてください。 2. アプリケーションが実行されたら、ブラウザーウィンドウを開き、リスナーへの URL を入力してアプリケーションをトリガーします。 ![Hello Mule のトリガー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule-browser-response.png) HTTP Listener で設定されているのと同じホストとポート (例: `http://0.0.0.0:8081/hellomule`​) を使用する必要があります。 3. ブラウザーに ​`Hello Mule!`​ のメッセージが表示されることを確認します。 4. Anypoint Studio の ​**\[Console (コンソール)\]**​ タブに表示されるメッセージで、最初の ​`INFO`​ 行の​_最後_​に要求のパス (​`/hellomule`​) が付加されていることを確認します (​`org.mule.runtime.core.internal.processor.LoggerMessageProcessor: /hellomule`​)。 ![Hello Mule コンソール](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule-console.png) ## [](#hello-mule-の例の設定-xml)Hello Mule の例の設定 XML 次の XML は、例で使用したフローと HTTP Listener の設定を示しています。スペースを節約するため、必要のない ​`doc:id`​ 属性は省略してあります。 Anypoint Studio からの XML 設定 ```XML ``` キャンバスの下にある ​**\[XML Configuration (XML 設定)\]**​ タブは、XML の編集ページを提供します。 ![Hello Mule の XML 設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-hellomule-xml.png) ## [](#関連情報)関連情報 - [チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-app-tutorial) - [DataWeave クイックスタート](#dataweave-quickstart.adoc) # チュートリアル: 「Hello World」Mule アプリケーションの作成 このチュートリアルでは、Web ブラウザーから送信された要求に対して「Hello Mule」というメッセージを返す例を使用して、Mule アプリケーションがどのようにやり取りするのかをシンプルな HTTP 要求-返信フローで実際に示します。 この例は非常にシンプルです。より複雑なアプリケーションでは、外部サーバー (SAP、Salesforce、データベース、FTP サーバーなど) への接続、Mule プロジェクト内での API 仕様の直接インポートと実装、セキュリティのセットアップ、データの処理や変換などをプログラムで行うことができます。これらの作業の説明は、この例のスコープを超えています。 ![Hello Mule](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule.png) Figure 1. Anypoint Studio での hellomule このアプリケーションは、Anypoint Studio でプロジェクトとしてセットアップして実行します。 ## [](#前提条件)前提条件 - [Anypoint Studio 7](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [「Anypoint Studio」](https://docs.mulesoft.com/studio/)​に説明されている Anypoint Studio UI (パレット、キャンバス、フロー) の操作に関する知識 Anypoint Studio をインストールしたら、例をセットアップして実行できます。 ## [](#例のしくみ)例のしくみ Hello Mule の例は、1 つのシンプルな Mule フローで構成されています。このフローは、HTTP 要求を受け入れ、メッセージに対して静的ペイロードを設定して、応答を返します。 インバウンド HTTP エンドポイントは、Web サービスに対して送信された要求を受け取ります。 メッセージ交換パターンは要求-応答であるため、HTTP エンドポイントはメッセージの受信と返信を管理します。 Set Payload コンポーネントは、その名前が示すようにメッセージペイロードに値を設定します。この例では、値として DataWeave 式を使用して静的文字列をペイロードに対して設定します。 ## [](#例をセットアップする)例をセットアップする 以下の手順に従って、自分の Anypoint Studio インスタンスで例を作成してください。Anypoint Studio でテンプレートアプリケーションを作成し、ユースケースに基づいたテンプレートの設定を調整することで、Mule でカスタムアプリケーションを作成することができます。 1. Anypoint Studio で ​`hellomule`​ という名前のプロジェクトを作成します。 1. **\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Project (Mule プロジェクト)\]**​ を選択し、表示されたダイアログの ​**\[Project Name (プロジェクト名)\]**​ に「hellomule」と入力します。 ![Hello Mule](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule-create-project.png) プロジェクト名には、空白スペースを含めません。 2. **\[Finish (完了)\]**​ をクリックします。 2. HTTP Listener コンポーネントを ​**hellomule**​ のキャンバスにドラッグします。 1. プロジェクトの ​**\[Mule Palette (Mule パレット)\]**​ タブで ​**\[HTTP\]**​ をクリックします。 ![Mule パレットの HTTP Connector](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule-empty-canvas.png) 2. **Listener**​ コンポーネントを ​**hellomuleFlow**​ キャンバスにドラッグします。 ![HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule-listener-config.png) **\[Listener\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Listener**​ コンポーネントをクリックして開きます。 タブ内に赤いボックスが表示されていますが、これは ​**\[Connector configuration (設定)\]**​ と ​**\[Path (パス)\]**​ の項目に値が必要であるためです。 3. **\[Listener\]**​ タブで ​**Listener**​ コンポーネントを設定します。 ![HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule-listener-path.png) 1. リスナーの ​**\[Path (パス)\]**​ 項目にパス ​`/hellomule`​ を入力します。 2. リスナーの ​**\[Connector configuration (設定)\]**​ 項目の下にある緑色のプラスアイコン (​**+**​) をクリックして、​**\[HTTP Listener config (HTTP Listener 設定)\]**​ ダイアログを開きます。 3. ダイアログで ​**\[Test Connection (接続をテスト)\]**​ をクリックして、デフォルトのリスナー設定を確認します。 ![リスナー接続のテスト、90%](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule-test-connection.png) - 接続に成功すると、​**\[Test connection (接続をテスト)\]**​ ダイアログが開いて「Test connection successful! (テスト正続に成功しました)」と表示されます。 - 接続に失敗した場合は、使用していないポート番号 (​`8082`​ や ​`8083`​ など) を使用して接続を再テストしてから、設定を追加してください。 4. **\[OK\]**​ をクリックして、有効な設定をプロジェクトに追加します。 4. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Set Payload**​ コンポーネントを見つけてキャンバスの ​**\[Process (プロセス)\]**​ エリアにドラッグします。 ![Set Payload の設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule-payload-config.png) - **Set Payload**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Set Payload\]**​ タブの設定 UI が開いていない場合は、​**Set Payload**​ コンポーネントをクリックして設定 UI を開いてください。 5. **Set Payload**​ コンポーネントの ​**\[Value (値)\]**​ 項目で ​**\[fx\]**​ 項目を​_選択解除して_​、文字列 ​`"Hello Mule!"`​ を入力します。 **\[fx\]**​ の選択を解除すると、項目のコンテンツは文字列 ​`"Hello Mule"`​ のみとなり、ハッシュ (​`#`​) や角括弧 (​`[]`​) は​_含まれません_​。 6. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Logger**​ コンポーネントを探して Transform Message コンポーネントの右側にドラッグします。 ![Hello Mule のロガー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule-logger.png) - **Logger**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Logger\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Logger**​ コンポーネントをクリックして開きます。 7. ロガーの ​**\[Message (メッセージ)\]**​ 項目で、​**\[fx\]**​ ボタンをクリックして、要求パスを Anypoint Studio コンソールに出力するために次の DataWeave 式を追加します。 `attributes.requestPath` 8. Anypoint Studio で ​**\[File (ファイル)\]**​ > ​**\[Save (保存)\]**​ を選択してプロジェクトを保存します。 9. [Hello Mule の例を実行してテストする](#run_example)​に進みます。 ## [](#run_example)Hello Mule の例を実行してテストする Anypoint Studio で Hello Mule をセットアップしたら、実行してテストします。 1. Anypoint Studio キャンバスを右クリックし、​**\[Run project hellomule (hellomule プロジェクトを実行)\]**​ を選択して ​**hellomule**​ アプリケーションを実行します。 ![Hello Mule の実行](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule-run.png) または、Anypoint Studio の一番上にある 「Run (実行)」 ボタン (​![「Run (実行)」 ボタン](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-run-button.png)) をクリックして、表示されたドロップダウンメニューから ​**hellomule**​ を選択することもできます。 どちらの操作を実行した場合もビルドプロセスが開始され、Anypoint Studio コンソールが開いて、2 フェーズのビルドおよびデプロイメントプロセスに関する重要なログ情報が表示されます。 最後が次のようになっているメッセージが Anypoint Studio コンソールに表示されれば、プロジェクトは実行中です。 ```txt ********************************************************** * - - + DOMAIN + - - * - - + STATUS + - - * ********************************************************** * default * DEPLOYED * ********************************************************** ******************************************************************************* * - - + APPLICATION + - - * - - + DOMAIN + - - * - - + STATUS + - - * ******************************************************************************* * hellomule * default * DEPLOYED * ******************************************************************************* ``` `DEPLOYED`​ 通知ではなく失敗通知 (​`FAILED`​) が表示された場合は、エラーメッセージを確認してください。次のようなメッセージが表示された場合は、HTTP Listener の設定で別の HTTP ポートを指定してください。 ```txt Could not create server: A server in port(8081) already exists for host(0.0.0.0) or one overlapping it (0.0.0.0).` ``` その後、プロジェクトを保存して再実行します。エラーが繰り返される場合は、ホストを ​`localhost`​ に変更してみてください。 2. アプリケーションが実行されたら、ブラウザーウィンドウを開き、リスナーへの URL を入力してアプリケーションをトリガーします。 ![Hello Mule のトリガー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule-browser-response.png) HTTP Listener で設定されているのと同じホストとポート (例: `http://0.0.0.0:8081/hellomule`​) を使用する必要があります。 3. ブラウザーに ​`Hello Mule!`​ のメッセージが表示されることを確認します。 4. Anypoint Studio の ​**\[Console (コンソール)\]**​ タブに表示されるメッセージで、最初の ​`INFO`​ 行の​_最後_​に要求のパス (​`/hellomule`​) が付加されていることを確認します (​`org.mule.runtime.core.internal.processor.LoggerMessageProcessor: /hellomule`​)。 ![Hello Mule コンソール](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule-console.png) ## [](#hello-mule-の例の設定-xml)Hello Mule の例の設定 XML 次の XML は、例で使用したフローと HTTP Listener の設定を示しています。スペースを節約するため、必要のない ​`doc:id`​ 属性は省略してあります。 Anypoint Studio からの XML 設定 ```XML ``` キャンバスの下にある ​**\[XML Configuration (XML 設定)\]**​ タブは、XML の編集ページを提供します。 ![Hello Mule の XML 設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-hellomule-xml.png) ## [](#関連情報)関連情報 - [チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-app-tutorial) - [DataWeave クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart) # チュートリアル: 「Hello World」Mule アプリケーションの作成 このチュートリアルでは、Web ブラウザーから送信された要求に対して「Hello Mule」というメッセージを返す例を使用して、Mule アプリケーションがどのようにやり取りするのかをシンプルな HTTP 要求-返信フローで実際に示します。 この例は非常にシンプルです。より複雑なアプリケーションでは、外部サーバー (SAP、Salesforce、データベース、FTP サーバーなど) への接続、Mule プロジェクト内での API 仕様の直接インポートと実装、セキュリティのセットアップ、データの処理や変換などをプログラムで行うことができます。これらの作業の説明は、この例のスコープを超えています。 ![Hello Mule](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule.png) Figure 1. Anypoint Studio での hellomule このアプリケーションは、Anypoint Studio でプロジェクトとしてセットアップして実行します。 ## [](#前提条件)前提条件 - [Anypoint Studio 7](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [「Anypoint Studio」](https://docs.mulesoft.com/studio/)​に説明されている Anypoint Studio UI (パレット、キャンバス、フロー) の操作に関する知識 Anypoint Studio をインストールしたら、例をセットアップして実行できます。 ## [](#例のしくみ)例のしくみ Hello Mule の例は、1 つのシンプルな Mule フローで構成されています。このフローは、HTTP 要求を受け入れ、メッセージに対して静的ペイロードを設定して、応答を返します。 インバウンド HTTP エンドポイントは、Web サービスに対して送信された要求を受け取ります。 メッセージ交換パターンは要求-応答であるため、HTTP エンドポイントはメッセージの受信と返信を管理します。 Set Payload コンポーネントは、その名前が示すようにメッセージペイロードに値を設定します。この例では、値として DataWeave 式を使用して静的文字列をペイロードに対して設定します。 ## [](#例をセットアップする)例をセットアップする 以下の手順に従って、自分の Anypoint Studio インスタンスで例を作成してください。Anypoint Studio でテンプレートアプリケーションを作成し、ユースケースに基づいたテンプレートの設定を調整することで、Mule でカスタムアプリケーションを作成することができます。 1. Anypoint Studio で ​`hellomule`​ という名前のプロジェクトを作成します。 1. **\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Project (Mule プロジェクト)\]**​ を選択し、表示されたダイアログの ​**\[Project Name (プロジェクト名)\]**​ に「hellomule」と入力します。 ![Hello Mule](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule-create-project.png) プロジェクト名には、空白スペースを含めません。 2. **\[Finish (完了)\]**​ をクリックします。 2. HTTP Listener コンポーネントを ​**hellomule**​ のキャンバスにドラッグします。 1. プロジェクトの ​**\[Mule Palette (Mule パレット)\]**​ タブで ​**\[HTTP\]**​ をクリックします。 ![Mule パレットの HTTP Connector](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule-empty-canvas.png) 2. **Listener**​ コンポーネントを ​**hellomuleFlow**​ キャンバスにドラッグします。 ![HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule-listener-config.png) **\[Listener\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Listener**​ コンポーネントをクリックして開きます。 タブ内に赤いボックスが表示されていますが、これは ​**\[Connector configuration (設定)\]**​ と ​**\[Path (パス)\]**​ の項目に値が必要であるためです。 3. **\[Listener\]**​ タブで ​**Listener**​ コンポーネントを設定します。 ![HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule-listener-path.png) 1. リスナーの ​**\[Path (パス)\]**​ 項目にパス ​`/hellomule`​ を入力します。 2. リスナーの ​**\[Connector configuration (設定)\]**​ 項目の下にある緑色のプラスアイコン (​**+**​) をクリックして、​**\[HTTP Listener config (HTTP Listener 設定)\]**​ ダイアログを開きます。 3. ダイアログで ​**\[Test Connection (接続をテスト)\]**​ をクリックして、デフォルトのリスナー設定を確認します。 ![リスナー接続のテスト、90%](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule-test-connection.png) - 接続に成功すると、​**\[Test connection (接続をテスト)\]**​ ダイアログが開いて「Test connection successful! (テスト正続に成功しました)」と表示されます。 - 接続に失敗した場合は、使用していないポート番号 (​`8082`​ や ​`8083`​ など) を使用して接続を再テストしてから、設定を追加してください。 4. **\[OK\]**​ をクリックして、有効な設定をプロジェクトに追加します。 4. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Set Payload**​ コンポーネントを見つけてキャンバスの ​**\[Process (プロセス)\]**​ エリアにドラッグします。 ![Set Payload の設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule-payload-config.png) - **Set Payload**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Set Payload\]**​ タブの設定 UI が開いていない場合は、​**Set Payload**​ コンポーネントをクリックして設定 UI を開いてください。 5. **Set Payload**​ コンポーネントの ​**\[Value (値)\]**​ 項目で ​**\[fx\]**​ 項目を​_選択解除して_​、文字列 ​`"Hello Mule!"`​ を入力します。 **\[fx\]**​ の選択を解除すると、項目のコンテンツは文字列 ​`"Hello Mule"`​ のみとなり、ハッシュ (​`#`​) や角括弧 (​`[]`​) は​_含まれません_​。 6. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Logger**​ コンポーネントを探して Transform Message コンポーネントの右側にドラッグします。 ![Hello Mule のロガー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule-logger.png) - **Logger**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Logger\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Logger**​ コンポーネントをクリックして開きます。 7. ロガーの ​**\[Message (メッセージ)\]**​ 項目で、​**\[fx\]**​ ボタンをクリックして、要求パスを Anypoint Studio コンソールに出力するために次の DataWeave 式を追加します。 `attributes.requestPath` 8. Anypoint Studio で ​**\[File (ファイル)\]**​ > ​**\[Save (保存)\]**​ を選択してプロジェクトを保存します。 9. [Hello Mule の例を実行してテストする](#run_example)​に進みます。 ## [](#run_example)Hello Mule の例を実行してテストする Anypoint Studio で Hello Mule をセットアップしたら、実行してテストします。 1. Anypoint Studio キャンバスを右クリックし、​**\[Run project hellomule (hellomule プロジェクトを実行)\]**​ を選択して ​**hellomule**​ アプリケーションを実行します。 ![Hello Mule の実行](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule-run.png) または、Anypoint Studio の一番上にある 「Run (実行)」 ボタン (​![「Run (実行)」 ボタン](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-run-button.png)) をクリックして、表示されたドロップダウンメニューから ​**hellomule**​ を選択することもできます。 どちらの操作を実行した場合もビルドプロセスが開始され、Anypoint Studio コンソールが開いて、2 フェーズのビルドおよびデプロイメントプロセスに関する重要なログ情報が表示されます。 最後が次のようになっているメッセージが Anypoint Studio コンソールに表示されれば、プロジェクトは実行中です。 ```txt ********************************************************** * - - + DOMAIN + - - * - - + STATUS + - - * ********************************************************** * default * DEPLOYED * ********************************************************** ******************************************************************************* * - - + APPLICATION + - - * - - + DOMAIN + - - * - - + STATUS + - - * ******************************************************************************* * hellomule * default * DEPLOYED * ******************************************************************************* ``` `DEPLOYED`​ 通知ではなく失敗通知 (​`FAILED`​) が表示された場合は、エラーメッセージを確認してください。次のようなメッセージが表示された場合は、HTTP Listener の設定で別の HTTP ポートを指定してください。 ```txt Could not create server: A server in port(8081) already exists for host(0.0.0.0) or one overlapping it (0.0.0.0).` ``` その後、プロジェクトを保存して再実行します。エラーが繰り返される場合は、ホストを ​`localhost`​ に変更してみてください。 2. アプリケーションが実行されたら、ブラウザーウィンドウを開き、リスナーへの URL を入力してアプリケーションをトリガーします。 ![Hello Mule のトリガー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule-browser-response.png) HTTP Listener で設定されているのと同じホストとポート (例: `http://0.0.0.0:8081/hellomule`​) を使用する必要があります。 3. ブラウザーに ​`Hello Mule!`​ のメッセージが表示されることを確認します。 4. Anypoint Studio の ​**\[Console (コンソール)\]**​ タブに表示されるメッセージで、最初の ​`INFO`​ 行の​_最後_​に要求のパス (​`/hellomule`​) が付加されていることを確認します (​`org.mule.runtime.core.internal.processor.LoggerMessageProcessor: /hellomule`​)。 ![Hello Mule コンソール](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule-console.png) ## [](#hello-mule-の例の設定-xml)Hello Mule の例の設定 XML 次の XML は、例で使用したフローと HTTP Listener の設定を示しています。スペースを節約するため、必要のない ​`doc:id`​ 属性は省略してあります。 Anypoint Studio からの XML 設定 ```XML ``` キャンバスの下にある ​**\[XML Configuration (XML 設定)\]**​ タブは、XML の編集ページを提供します。 ![Hello Mule の XML 設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-hellomule-xml.png) ## [](#関連情報)関連情報 - [チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-app-tutorial) - [DataWeave クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart) # チュートリアル: 「Hello World」Mule アプリケーションの作成 このチュートリアルでは、Web ブラウザーから送信された要求に対して「Hello Mule」というメッセージを返す例を使用して、Mule アプリケーションがどのようにやり取りするのかをシンプルな HTTP 要求-返信フローで実際に示します。 この例は非常にシンプルです。より複雑なアプリケーションでは、外部サーバー (SAP、Salesforce、データベース、FTP サーバーなど) への接続、Mule プロジェクト内での API 仕様の直接インポートと実装、セキュリティのセットアップ、データの処理や変換などをプログラムで行うことができます。これらの作業の説明は、この例のスコープを超えています。 ![Hello Mule](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule.png) Figure 1. Anypoint Studio での hellomule このアプリケーションは、Anypoint Studio でプロジェクトとしてセットアップして実行します。 ## [](#前提条件)前提条件 - [Anypoint Studio 7](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [「Anypoint Studio」](https://docs.mulesoft.com/studio/)​に説明されている Anypoint Studio UI (パレット、キャンバス、フロー) の操作に関する知識 Anypoint Studio をインストールしたら、例をセットアップして実行できます。 ## [](#例のしくみ)例のしくみ Hello Mule の例は、1 つのシンプルな Mule フローで構成されています。このフローは、HTTP 要求を受け入れ、メッセージに対して静的ペイロードを設定して、応答を返します。 インバウンド HTTP エンドポイントは、Web サービスに対して送信された要求を受け取ります。 メッセージ交換パターンは要求-応答であるため、HTTP エンドポイントはメッセージの受信と返信を管理します。 Set Payload コンポーネントは、その名前が示すようにメッセージペイロードに値を設定します。この例では、値として DataWeave 式を使用して静的文字列をペイロードに対して設定します。 ## [](#例をセットアップする)例をセットアップする 以下の手順に従って、自分の Anypoint Studio インスタンスで例を作成してください。Anypoint Studio でテンプレートアプリケーションを作成し、ユースケースに基づいたテンプレートの設定を調整することで、Mule でカスタムアプリケーションを作成することができます。 1. Anypoint Studio で ​`hellomule`​ という名前のプロジェクトを作成します。 1. **\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Project (Mule プロジェクト)\]**​ を選択し、表示されたダイアログの ​**\[Project Name (プロジェクト名)\]**​ に「hellomule」と入力します。 ![Hello Mule](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule-create-project.png) プロジェクト名には、空白スペースを含めません。 2. **\[Finish (完了)\]**​ をクリックします。 2. HTTP Listener コンポーネントを ​**hellomule**​ のキャンバスにドラッグします。 1. プロジェクトの ​**\[Mule Palette (Mule パレット)\]**​ タブで ​**\[HTTP\]**​ をクリックします。 ![Mule パレットの HTTP Connector](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule-empty-canvas.png) 2. **Listener**​ コンポーネントを ​**hellomuleFlow**​ キャンバスにドラッグします。 ![HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule-listener-config.png) **\[Listener\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Listener**​ コンポーネントをクリックして開きます。 タブ内に赤いボックスが表示されていますが、これは ​**\[Connector configuration (設定)\]**​ と ​**\[Path (パス)\]**​ の項目に値が必要であるためです。 3. **\[Listener\]**​ タブで ​**Listener**​ コンポーネントを設定します。 ![HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule-listener-path.png) 1. リスナーの ​**\[Path (パス)\]**​ 項目にパス ​`/hellomule`​ を入力します。 2. リスナーの ​**\[Connector configuration (設定)\]**​ 項目の下にある緑色のプラスアイコン (​**+**​) をクリックして、​**\[HTTP Listener config (HTTP Listener 設定)\]**​ ダイアログを開きます。 3. ダイアログで ​**\[Test Connection (接続をテスト)\]**​ をクリックして、デフォルトのリスナー設定を確認します。 ![リスナー接続のテスト、90%](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule-test-connection.png) - 接続に成功すると、​**\[Test connection (接続をテスト)\]**​ ダイアログが開いて「Test connection successful! (テスト正続に成功しました)」と表示されます。 - 接続に失敗した場合は、使用していないポート番号 (​`8082`​ や ​`8083`​ など) を使用して接続を再テストしてから、設定を追加してください。 4. **\[OK\]**​ をクリックして、有効な設定をプロジェクトに追加します。 4. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Set Payload**​ コンポーネントを見つけてキャンバスの ​**\[Process (プロセス)\]**​ エリアにドラッグします。 ![Set Payload の設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule-payload-config.png) - **Set Payload**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Set Payload\]**​ タブの設定 UI が開いていない場合は、​**Set Payload**​ コンポーネントをクリックして設定 UI を開いてください。 5. **Set Payload**​ コンポーネントの ​**\[Value (値)\]**​ 項目で ​**\[fx\]**​ 項目を​_選択解除して_​、文字列 ​`"Hello Mule!"`​ を入力します。 **\[fx\]**​ の選択を解除すると、項目のコンテンツは文字列 ​`"Hello Mule"`​ のみとなり、ハッシュ (​`#`​) や角括弧 (​`[]`​) は​_含まれません_​。 6. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Logger**​ コンポーネントを探して Transform Message コンポーネントの右側にドラッグします。 ![Hello Mule のロガー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule-logger.png) - **Logger**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Logger\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Logger**​ コンポーネントをクリックして開きます。 7. ロガーの ​**\[Message (メッセージ)\]**​ 項目で、​**\[fx\]**​ ボタンをクリックして、要求パスを Anypoint Studio コンソールに出力するために次の DataWeave 式を追加します。 `attributes.requestPath` 8. Anypoint Studio で ​**\[File (ファイル)\]**​ > ​**\[Save (保存)\]**​ を選択してプロジェクトを保存します。 9. [Hello Mule の例を実行してテストする](#run_example)​に進みます。 ## [](#run_example)Hello Mule の例を実行してテストする Anypoint Studio で Hello Mule をセットアップしたら、実行してテストします。 1. Anypoint Studio キャンバスを右クリックし、​**\[Run project hellomule (hellomule プロジェクトを実行)\]**​ を選択して ​**hellomule**​ アプリケーションを実行します。 ![Hello Mule の実行](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule-run.png) または、Anypoint Studio の一番上にある 「Run (実行)」 ボタン (​![「Run (実行)」 ボタン](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-run-button.png)) をクリックして、表示されたドロップダウンメニューから ​**hellomule**​ を選択することもできます。 どちらの操作を実行した場合もビルドプロセスが開始され、Anypoint Studio コンソールが開いて、2 フェーズのビルドおよびデプロイメントプロセスに関する重要なログ情報が表示されます。 最後が次のようになっているメッセージが Anypoint Studio コンソールに表示されれば、プロジェクトは実行中です。 ```txt ********************************************************** * - - + DOMAIN + - - * - - + STATUS + - - * ********************************************************** * default * DEPLOYED * ********************************************************** ******************************************************************************* * - - + APPLICATION + - - * - - + DOMAIN + - - * - - + STATUS + - - * ******************************************************************************* * hellomule * default * DEPLOYED * ******************************************************************************* ``` `DEPLOYED`​ 通知ではなく失敗通知 (​`FAILED`​) が表示された場合は、エラーメッセージを確認してください。次のようなメッセージが表示された場合は、HTTP Listener の設定で別の HTTP ポートを指定してください。 ```txt Could not create server: A server in port(8081) already exists for host(0.0.0.0) or one overlapping it (0.0.0.0).` ``` その後、プロジェクトを保存して再実行します。エラーが繰り返される場合は、ホストを ​`localhost`​ に変更してみてください。 2. アプリケーションが実行されたら、ブラウザーウィンドウを開き、リスナーへの URL を入力してアプリケーションをトリガーします。 ![Hello Mule のトリガー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule-browser-response.png) HTTP Listener で設定されているのと同じホストとポート (例: `http://0.0.0.0:8081/hellomule`​) を使用する必要があります。 3. ブラウザーに ​`Hello Mule!`​ のメッセージが表示されることを確認します。 4. Anypoint Studio の ​**\[Console (コンソール)\]**​ タブに表示されるメッセージで、最初の ​`INFO`​ 行の​_最後_​に要求のパス (​`/hellomule`​) が付加されていることを確認します (​`org.mule.runtime.core.internal.processor.LoggerMessageProcessor: /hellomule`​)。 ![Hello Mule コンソール](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule-console.png) ## [](#hello-mule-の例の設定-xml)Hello Mule の例の設定 XML 次の XML は、例で使用したフローと HTTP Listener の設定を示しています。スペースを節約するため、必要のない ​`doc:id`​ 属性は省略してあります。 Anypoint Studio からの XML 設定 ```XML ``` キャンバスの下にある ​**\[XML Configuration (XML 設定)\]**​ タブは、XML の編集ページを提供します。 ![Hello Mule の XML 設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-hellomule-xml.png) ## [](#関連情報)関連情報 - [チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-app-tutorial) - [DataWeave クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart) # チュートリアル: 「Hello World」Mule アプリケーションの作成 このチュートリアルでは、Web ブラウザーから送信された要求に対して「Hello Mule」というメッセージを返す例を使用して、Mule アプリケーションがどのようにやり取りするのかをシンプルな HTTP 要求-返信フローで実際に示します。 この例は非常にシンプルです。より複雑なアプリケーションでは、外部サーバー (SAP、Salesforce、データベース、FTP サーバーなど) への接続、Mule プロジェクト内での API 仕様の直接インポートと実装、セキュリティのセットアップ、データの処理や変換などをプログラムで行うことができます。これらの作業の説明は、この例のスコープを超えています。 ![Hello Mule](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule.png) Figure 1. Anypoint Studio での hellomule このアプリケーションは、Anypoint Studio でプロジェクトとしてセットアップして実行します。 ## [](#前提条件)前提条件 - [Anypoint Studio 7](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [「Anypoint Studio」](https://docs.mulesoft.com/studio/)​に説明されている Anypoint Studio UI (パレット、キャンバス、フロー) の操作に関する知識 Anypoint Studio をインストールしたら、例をセットアップして実行できます。 ## [](#例のしくみ)例のしくみ Hello Mule の例は、1 つのシンプルな Mule フローで構成されています。このフローは、HTTP 要求を受け入れ、メッセージに対して静的ペイロードを設定して、応答を返します。 インバウンド HTTP エンドポイントは、Web サービスに対して送信された要求を受け取ります。 メッセージ交換パターンは要求-応答であるため、HTTP エンドポイントはメッセージの受信と返信を管理します。 Set Payload コンポーネントは、その名前が示すようにメッセージペイロードに値を設定します。この例では、値として DataWeave 式を使用して静的文字列をペイロードに対して設定します。 ## [](#例をセットアップする)例をセットアップする 以下の手順に従って、自分の Anypoint Studio インスタンスで例を作成してください。Anypoint Studio でテンプレートアプリケーションを作成し、ユースケースに基づいたテンプレートの設定を調整することで、Mule でカスタムアプリケーションを作成することができます。 1. Anypoint Studio で ​`hellomule`​ という名前のプロジェクトを作成します。 1. **\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Project (Mule プロジェクト)\]**​ を選択し、表示されたダイアログの ​**\[Project Name (プロジェクト名)\]**​ に「hellomule」と入力します。 ![Hello Mule](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule-create-project.png) プロジェクト名には、空白スペースを含めません。 2. **\[Finish (完了)\]**​ をクリックします。 2. HTTP Listener コンポーネントを ​**hellomule**​ のキャンバスにドラッグします。 1. プロジェクトの ​**\[Mule Palette (Mule パレット)\]**​ タブで ​**\[HTTP\]**​ をクリックします。 ![Mule パレットの HTTP Connector](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule-empty-canvas.png) 2. **Listener**​ コンポーネントを ​**hellomuleFlow**​ キャンバスにドラッグします。 ![HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule-listener-config.png) **\[Listener\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Listener**​ コンポーネントをクリックして開きます。 タブ内に赤いボックスが表示されていますが、これは ​**\[Connector configuration (設定)\]**​ と ​**\[Path (パス)\]**​ の項目に値が必要であるためです。 3. **\[Listener\]**​ タブで ​**Listener**​ コンポーネントを設定します。 ![HTTP リスナー設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule-listener-path.png) 1. リスナーの ​**\[Path (パス)\]**​ 項目にパス ​`/hellomule`​ を入力します。 2. リスナーの ​**\[Connector configuration (設定)\]**​ 項目の下にある緑色のプラスアイコン (​**+**​) をクリックして、​**\[HTTP Listener config (HTTP Listener 設定)\]**​ ダイアログを開きます。 3. ダイアログで ​**\[Test Connection (接続をテスト)\]**​ をクリックして、デフォルトのリスナー設定を確認します。 ![リスナー接続のテスト、90%](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule-test-connection.png) - 接続に成功すると、​**\[Test connection (接続をテスト)\]**​ ダイアログが開いて「Test connection successful! (テスト正続に成功しました)」と表示されます。 - 接続に失敗した場合は、使用していないポート番号 (​`8082`​ や ​`8083`​ など) を使用して接続を再テストしてから、設定を追加してください。 4. **\[OK\]**​ をクリックして、有効な設定をプロジェクトに追加します。 4. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Set Payload**​ コンポーネントを見つけてキャンバスの ​**\[Process (プロセス)\]**​ エリアにドラッグします。 ![Set Payload の設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule-payload-config.png) - **Set Payload**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Set Payload\]**​ タブの設定 UI が開いていない場合は、​**Set Payload**​ コンポーネントをクリックして設定 UI を開いてください。 5. **Set Payload**​ コンポーネントの ​**\[Value (値)\]**​ 項目で ​**\[fx\]**​ 項目を​_選択解除して_​、文字列 ​`"Hello Mule!"`​ を入力します。 **\[fx\]**​ の選択を解除すると、項目のコンテンツは文字列 ​`"Hello Mule"`​ のみとなり、ハッシュ (​`#`​) や角括弧 (​`[]`​) は​_含まれません_​。 6. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Logger**​ コンポーネントを探して Transform Message コンポーネントの右側にドラッグします。 ![Hello Mule のロガー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule-logger.png) - **Logger**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Logger\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Logger**​ コンポーネントをクリックして開きます。 7. ロガーの ​**\[Message (メッセージ)\]**​ 項目で、​**\[fx\]**​ ボタンをクリックして、要求パスを Anypoint Studio コンソールに出力するために次の DataWeave 式を追加します。 `attributes.requestPath` 8. Anypoint Studio で ​**\[File (ファイル)\]**​ > ​**\[Save (保存)\]**​ を選択してプロジェクトを保存します。 9. [Hello Mule の例を実行してテストする](#run_example)​に進みます。 ## [](#run_example)Hello Mule の例を実行してテストする Anypoint Studio で Hello Mule をセットアップしたら、実行してテストします。 1. Anypoint Studio キャンバスを右クリックし、​**\[Run project hellomule (hellomule プロジェクトを実行)\]**​ を選択して ​**hellomule**​ アプリケーションを実行します。 ![Hello Mule の実行](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule-run.png) または、Anypoint Studio の一番上にある \[Run (実行)\] ボタン (​![実行アイコン](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-run-button.png)​) をクリックして、表示されたドロップダウンメニューから ​**hellomule**​ を選択することもできます。 どちらの操作を実行した場合もビルドプロセスが開始され、Anypoint Studio コンソールが開いて、2 フェーズのビルドおよびデプロイメントプロセスに関する重要なログ情報が表示されます。 最後が次のようになっているメッセージが Anypoint Studio コンソールに表示されれば、プロジェクトは実行中です。 ```txt ********************************************************** * - - + DOMAIN + - - * - - + STATUS + - - * ********************************************************** * default * DEPLOYED * ********************************************************** ******************************************************************************* * - - + APPLICATION + - - * - - + DOMAIN + - - * - - + STATUS + - - * ******************************************************************************* * hellomule * default * DEPLOYED * ******************************************************************************* ``` `DEPLOYED`​ 通知ではなく失敗通知 (​`FAILED`​) が表示された場合は、エラーメッセージを確認してください。次のようなメッセージが表示された場合は、HTTP Listener の設定で別の HTTP ポートを指定してください。 ```txt Could not create server: A server in port(8081) already exists for host(0.0.0.0) or one overlapping it (0.0.0.0).` ``` その後、プロジェクトを保存して再実行します。エラーが繰り返される場合は、ホストを ​`localhost`​ に変更してみてください。 2. アプリケーションが実行されたら、ブラウザーウィンドウを開き、リスナーへの URL を入力してアプリケーションをトリガーします。 ![Hello Mule のトリガー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule-browser-response.png) HTTP Listener で設定されているのと同じホストとポート (例: `http://0.0.0.0:8081/hellomule`​) を使用する必要があります。 3. ブラウザーに ​`Hello Mule!`​ のメッセージが表示されることを確認します。 4. Anypoint Studio の ​**\[Console (コンソール)\]**​ タブに表示されるメッセージで、最初の ​`INFO`​ 行の​_最後_​に要求のパス (​`/hellomule`​) が付加されていることを確認します (​`org.mule.runtime.core.internal.processor.LoggerMessageProcessor: /hellomule`​)。 ![Hello Mule コンソール](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule-console.png) ## [](#hello-mule-の例の設定-xml)Hello Mule の例の設定 XML 次の XML は、例で使用したフローと HTTP Listener の設定を示しています。スペースを節約するため、必要のない ​`doc:id`​ 属性は省略してあります。 Anypoint Studio からの XML 設定 ```XML ``` キャンバスの下にある ​**\[XML Configuration (XML 設定)\]**​ タブは、XML の編集ページを提供します。 ![Hello Mule の XML 設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-hellomule-xml.png) ## [](#関連情報)関連情報 - [チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-app-tutorial) - [DataWeave クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart) # チュートリアル: 「Hello World」Mule アプリケーションの作成 このチュートリアルでは、Web ブラウザーから送信された要求に対して「Hello Mule」というメッセージを返す例を使用して、Mule アプリケーションがどのようにやり取りするのかをシンプルな HTTP 要求-返信フローで実際に示します。 この例は非常にシンプルです。より複雑なアプリケーションでは、外部サーバー (SAP、Salesforce、データベース、FTP サーバーなど) への接続、Mule プロジェクト内での API 仕様の直接インポートと実装、セキュリティのセットアップ、データの処理や変換などをプログラムで行うことができます。これらの作業の説明は、この例のスコープを超えています。 ![「Hello Mule」という名前の Mule アプリケーションと、Listener、Set Payload、Logger などのコンポーネントが表示されている開発環境](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule.png) Figure 1. Anypoint Studio での hellomule このアプリケーションは、Anypoint Studio でプロジェクトとしてセットアップして実行します。 ## [](#前提条件)前提条件 - [Anypoint Studio 7](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [「Anypoint Studio」](https://docs.mulesoft.com/studio/)​に説明されている Anypoint Studio UI (パレット、キャンバス、フロー) の操作に関する知識 Anypoint Studio をインストールしたら、例をセットアップして実行できます。 ## [](#例のしくみ)例のしくみ Hello Mule の例は、1 つのシンプルな Mule フローで構成されています。このフローは、HTTP 要求を受け入れ、メッセージに対して静的ペイロードを設定して、応答を返します。 インバウンド HTTP エンドポイントは、Web サービスに対して送信された要求を受け取ります。 メッセージ交換パターンは要求-応答であるため、HTTP エンドポイントはメッセージの受信と返信を管理します。 Set Payload コンポーネントは、その名前が示すようにメッセージペイロードに値を設定します。この例では、値として DataWeave 式を使用して静的文字列をペイロードに対して設定します。 ## [](#例をセットアップする)例をセットアップする 以下の手順に従って、自分の Anypoint Studio インスタンスで例を作成してください。Anypoint Studio でテンプレートアプリケーションを作成し、ユースケースに基づいたテンプレートの設定を調整することで、Mule でカスタムアプリケーションを作成することができます。 1. Anypoint Studio で ​`hellomule`​ という名前のプロジェクトを作成します。 1. **\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Project (Mule プロジェクト)\]**​ を選択し、表示されたダイアログの ​**\[Project Name (プロジェクト名)\]**​ に「hellomule」と入力します。 ![ランタイムバージョンを選択するオプションが表示されている、「Hello Mule」という名前の新しい Mule プロジェクトを作成するためのダイアログボックス](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule-create-project.png) プロジェクト名には、空白スペースを含めません。 2. **\[Finish (完了)\]**​ をクリックします。 2. HTTP Listener コンポーネントを ​**hellomule**​ のキャンバスにドラッグします。 1. プロジェクトの ​**\[Mule Palette (Mule パレット)\]**​ タブで ​**\[HTTP\]**​ をクリックします。 ![Mule パレットの HTTP Connector](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule-empty-canvas.png) 2. **Listener**​ コンポーネントを ​**hellomuleFlow**​ キャンバスにドラッグします。 ![Mule アプリケーションの HTTP Listener 設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule-listener-config.png) **\[Listener\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Listener**​ コンポーネントをクリックして開きます。 タブ内に赤いボックスが表示されていますが、これは ​**\[Connector configuration (設定)\]**​ と ​**\[Path (パス)\]**​ の項目に値が必要であるためです。 3. **\[Listener\]**​ タブで ​**Listener**​ コンポーネントを設定します。 ![Mule アプリケーションの HTTP Listener の設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule-listener-path.png) 1. リスナーの ​**\[Path (パス)\]**​ 項目にパス ​`/hellomule`​ を入力します。 2. リスナーの ​**\[Connector configuration (設定)\]**​ 項目の下にある緑色のプラスアイコン (​**+**​) をクリックして、​**\[HTTP Listener config (HTTP Listener 設定)\]**​ ダイアログを開きます。 3. ダイアログで ​**\[Test Connection (接続をテスト)\]**​ をクリックして、デフォルトのリスナー設定を確認します。 ![Mule の成功した HTTP Listener 接続テストが表示されているパネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule-test-connection.png) - 接続に成功すると、​**\[Test connection (接続をテスト)\]**​ ダイアログが開いて「Test connection successful! (テスト正続に成功しました)」と表示されます。 - 接続に失敗した場合は、使用していないポート番号 (​`8082`​ や ​`8083`​ など) を使用して接続を再テストしてから、設定を追加してください。 4. **\[OK\]**​ をクリックして、有効な設定をプロジェクトに追加します。 4. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Set Payload**​ コンポーネントを見つけてキャンバスの ​**\[Process (プロセス)\]**​ エリアにドラッグします。 ![Mule フローのペイロードを設定する設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule-payload-config.png) - **Set Payload**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Set Payload\]**​ タブの設定 UI が開いていない場合は、​**Set Payload**​ コンポーネントをクリックして設定 UI を開いてください。 5. **Set Payload**​ コンポーネントの ​**\[Value (値)\]**​ 項目で ​**\[fx\]**​ 項目を​_選択解除して_​、文字列 ​`"Hello Mule!"`​ を入力します。 **\[fx\]**​ の選択を解除すると、項目のコンテンツは文字列 ​`"Hello Mule"`​ のみとなり、ハッシュ (​`#`​) や角括弧 (​`[]`​) は​_含まれません_​。 6. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Logger**​ コンポーネントを探して Transform Message コンポーネントの右側にドラッグします。 ![Hello Mule の Logger コンポーネント設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule-logger.png) - **Logger**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Logger\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Logger**​ コンポーネントをクリックして開きます。 7. ロガーの ​**\[Message (メッセージ)\]**​ 項目で、​**\[fx\]**​ ボタンをクリックして、要求パスを Anypoint Studio コンソールに出力するために次の DataWeave 式を追加します。 `attributes.requestPath` 8. Anypoint Studio で ​**\[File (ファイル)\]**​ > ​**\[Save (保存)\]**​ を選択してプロジェクトを保存します。 9. [Hello Mule の例を実行してテストする](#run_example)​に進みます。 ## [](#run_example)Hello Mule の例を実行してテストする Anypoint Studio で Hello Mule をセットアップしたら、実行してテストします。 1. Anypoint Studio キャンバスを右クリックし、​**\[Run project hellomule (hellomule プロジェクトを実行)\]**​ を選択して ​**hellomule**​ アプリケーションを実行します。 ![Hello Mule の実行](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule-run.png) または、Anypoint Studio の一番上にある \[Run (実行)\] ボタン (​![実行アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-run-button.png)​) をクリックして、表示されたドロップダウンメニューから ​**hellomule**​ を選択することもできます。 どちらの操作を実行した場合もビルドプロセスが開始され、Anypoint Studio コンソールが開いて、2 フェーズのビルドおよびデプロイメントプロセスに関する重要なログ情報が表示されます。 最後が次のようになっているメッセージが Anypoint Studio コンソールに表示されれば、プロジェクトは実行中です。 ```txt ********************************************************** * - - + DOMAIN + - - * - - + STATUS + - - * ********************************************************** * default * DEPLOYED * ********************************************************** ******************************************************************************* * - - + APPLICATION + - - * - - + DOMAIN + - - * - - + STATUS + - - * ******************************************************************************* * hellomule * default * DEPLOYED * ******************************************************************************* ``` `DEPLOYED`​ 通知ではなく失敗通知 (​`FAILED`​) が表示された場合は、エラーメッセージを確認してください。次のようなメッセージが表示された場合は、HTTP Listener の設定で別の HTTP ポートを指定してください。 ```txt Could not create server: A server in port(8081) already exists for host(0.0.0.0) or one overlapping it (0.0.0.0).` ``` その後、プロジェクトを保存して再実行します。エラーが繰り返される場合は、ホストを ​`localhost`​ に変更してみてください。 2. アプリケーションが実行されたら、ブラウザーウィンドウを開き、リスナーへの URL を入力してアプリケーションをトリガーします。 ![ローカルサーバーからの応答「Hello Mule!」が表示されている Web ブラウザー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule-browser-response.png) HTTP Listener で設定されているのと同じホストとポート (例: `http://0.0.0.0:8081/hellomule`​) を使用する必要があります。 3. ブラウザーに ​`Hello Mule!`​ のメッセージが表示されることを確認します。 4. Anypoint Studio の ​**\[Console (コンソール)\]**​ タブに表示されるメッセージで、最初の ​`INFO`​ 行の​_最後_​に要求のパス (​`/hellomule`​) が付加されていることを確認します (​`org.mule.runtime.core.internal.processor.LoggerMessageProcessor: /hellomule`​)。 ![「Hello Mule」という名前の Mule アプリケーションからのログが表示されているコンソール出力](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule-console.png) ## [](#hello-mule-の例の設定-xml)Hello Mule の例の設定 XML 次の XML は、例で使用したフローと HTTP Listener の設定を示しています。スペースを節約するため、必要のない ​`doc:id`​ 属性は省略してあります。 Anypoint Studio からの XML 設定 ```XML ``` キャンバスの下にある ​**\[XML Configuration (XML 設定)\]**​ タブは、XML の編集ページを提供します。 ![Hello Mule の XML 設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-hellomule-xml.png) ## [](#関連情報)関連情報 - [チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-app-tutorial) - [DataWeave クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart) # チュートリアル: 「Hello World」Mule アプリケーションの作成 このチュートリアルでは、Web ブラウザーから送信された要求に対して「Hello Mule」というメッセージを返す例を使用して、Mule アプリケーションがどのようにやり取りするのかをシンプルな HTTP 要求-返信フローで実際に示します。 この例は非常にシンプルです。より複雑なアプリケーションでは、外部サーバー (SAP、Salesforce、データベース、FTP サーバーなど) への接続、Mule プロジェクト内での API 仕様の直接インポートと実装、セキュリティのセットアップ、データの処理や変換などをプログラムで行うことができます。これらの作業の説明は、この例のスコープを超えています。 ![「Hello Mule」という名前の Mule アプリケーションと、Listener、Set Payload、Logger などのコンポーネントが表示されている開発環境](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule.png) Figure 1. Anypoint Studio での hellomule このアプリケーションは、Anypoint Studio でプロジェクトとしてセットアップして実行します。 ## [](#前提条件)前提条件 - [Anypoint Studio 7](https://docs.mulesoft.com/studio/to-download-and-install-studio) - [「Anypoint Studio」](https://docs.mulesoft.com/studio/)​に説明されている Anypoint Studio UI (パレット、キャンバス、フロー) の操作に関する知識 Anypoint Studio をインストールしたら、例をセットアップして実行できます。 ## [](#例のしくみ)例のしくみ Hello Mule の例は、1 つのシンプルな Mule フローで構成されています。このフローは、HTTP 要求を受け入れ、メッセージに対して静的ペイロードを設定して、応答を返します。 インバウンド HTTP エンドポイントは、Web サービスに対して送信された要求を受け取ります。 メッセージ交換パターンは要求-応答であるため、HTTP エンドポイントはメッセージの受信と返信を管理します。 Set Payload コンポーネントは、その名前が示すようにメッセージペイロードに値を設定します。この例では、値として DataWeave 式を使用して静的文字列をペイロードに対して設定します。 ## [](#例をセットアップする)例をセットアップする 以下の手順に従って、自分の Anypoint Studio インスタンスで例を作成してください。Anypoint Studio でテンプレートアプリケーションを作成し、ユースケースに基づいたテンプレートの設定を調整することで、Mule でカスタムアプリケーションを作成することができます。 1. Anypoint Studio で ​`hellomule`​ という名前のプロジェクトを作成します。 1. **\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Project (Mule プロジェクト)\]**​ を選択し、表示されたダイアログの ​**\[Project Name (プロジェクト名)\]**​ に「hellomule」と入力します。 ![ランタイムバージョンを選択するオプションが表示されている、「Hello Mule」という名前の新しい Mule プロジェクトを作成するためのダイアログボックス](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule-create-project.png) プロジェクト名には、空白スペースを含めません。 2. **\[Finish (完了)\]**​ をクリックします。 2. HTTP Listener コンポーネントを ​**hellomule**​ のキャンバスにドラッグします。 1. プロジェクトの ​**\[Mule Palette (Mule パレット)\]**​ タブで ​**\[HTTP\]**​ をクリックします。 ![Mule パレットの HTTP Connector](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule-empty-canvas.png) 2. **Listener**​ コンポーネントを ​**hellomuleFlow**​ キャンバスにドラッグします。 ![Mule アプリケーションの HTTP Listener 設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule-listener-config.png) **\[Listener\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Listener**​ コンポーネントをクリックして開きます。 タブ内に赤いボックスが表示されていますが、これは ​**\[Connector configuration (設定)\]**​ と ​**\[Path (パス)\]**​ の項目に値が必要であるためです。 3. **\[Listener\]**​ タブで ​**Listener**​ コンポーネントを設定します。 ![Mule アプリケーションの HTTP Listener の設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule-listener-path.png) 1. リスナーの ​**\[Path (パス)\]**​ 項目にパス ​`/hellomule`​ を入力します。 2. リスナーの ​**\[Connector configuration (設定)\]**​ 項目の下にある緑色のプラスアイコン (​**+**​) をクリックして、​**\[HTTP Listener config (HTTP Listener 設定)\]**​ ダイアログを開きます。 3. ダイアログで ​**\[Test Connection (接続をテスト)\]**​ をクリックして、デフォルトのリスナー設定を確認します。 ![Mule の成功した HTTP Listener 接続テストが表示されているパネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule-test-connection.png) - 接続に成功すると、​**\[Test connection (接続をテスト)\]**​ ダイアログが開いて「Test connection successful! (テスト正続に成功しました)」と表示されます。 - 接続に失敗した場合は、使用していないポート番号 (​`8082`​ や ​`8083`​ など) を使用して接続を再テストしてから、設定を追加してください。 4. **\[OK\]**​ をクリックして、有効な設定をプロジェクトに追加します。 4. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Set Payload**​ コンポーネントを見つけてキャンバスの ​**\[Process (プロセス)\]**​ エリアにドラッグします。 ![Mule フローのペイロードを設定する設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule-payload-config.png) - **Set Payload**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Set Payload\]**​ タブの設定 UI が開いていない場合は、​**Set Payload**​ コンポーネントをクリックして設定 UI を開いてください。 5. **Set Payload**​ コンポーネントの ​**\[Value (値)\]**​ 項目で ​**\[fx\]**​ 項目を​_選択解除して_​、文字列 ​`"Hello Mule!"`​ を入力します。 **\[fx\]**​ の選択を解除すると、項目のコンテンツは文字列 ​`"Hello Mule"`​ のみとなり、ハッシュ (​`#`​) や角括弧 (​`[]`​) は​_含まれません_​。 6. **\[Mule Palette (Mule パレット)\]**​ タブで ​**\[Core (コア)\]**​ をクリックし、​**Logger**​ コンポーネントを探して Transform Message コンポーネントの右側にドラッグします。 ![Hello Mule の Logger コンポーネント設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule-logger.png) - **Logger**​ コンポーネントが見つからない場合は、​**\[Mule Palette (Mule パレット)\]**​ タブの一番上にある検索項目を試してください。 - **\[Logger\]**​ タブの設定 UI が開いていない場合は、キャンバスの ​**Logger**​ コンポーネントをクリックして開きます。 7. ロガーの ​**\[Message (メッセージ)\]**​ 項目で、​**\[fx\]**​ ボタンをクリックして、要求パスを Anypoint Studio コンソールに出力するために次の DataWeave 式を追加します。 `attributes.requestPath` 8. Anypoint Studio で ​**\[File (ファイル)\]**​ > ​**\[Save (保存)\]**​ を選択してプロジェクトを保存します。 9. [Hello Mule の例を実行してテストする](#run_example)​に進みます。 ## [](#run_example)Hello Mule の例を実行してテストする Anypoint Studio で Hello Mule をセットアップしたら、実行してテストします。 1. Anypoint Studio キャンバスを右クリックし、​**\[Run project hellomule (hellomule プロジェクトを実行)\]**​ を選択して ​**hellomule**​ アプリケーションを実行します。 ![Hello Mule の実行](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule-run.png) または、Anypoint Studio の一番上にある \[Run (実行)\] ボタン (​![実行アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-run-button.png)​) をクリックして、表示されたドロップダウンメニューから ​**hellomule**​ を選択することもできます。 どちらの操作を実行した場合もビルドプロセスが開始され、Anypoint Studio コンソールが開いて、2 フェーズのビルドおよびデプロイメントプロセスに関する重要なログ情報が表示されます。 最後が次のようになっているメッセージが Anypoint Studio コンソールに表示されれば、プロジェクトは実行中です。 ```txt ********************************************************** * - - + DOMAIN + - - * - - + STATUS + - - * ********************************************************** * default * DEPLOYED * ********************************************************** ******************************************************************************* * - - + APPLICATION + - - * - - + DOMAIN + - - * - - + STATUS + - - * ******************************************************************************* * hellomule * default * DEPLOYED * ******************************************************************************* ``` `DEPLOYED`​ 通知ではなく失敗通知 (​`FAILED`​) が表示された場合は、エラーメッセージを確認してください。次のようなメッセージが表示された場合は、HTTP Listener の設定で別の HTTP ポートを指定してください。 ```txt Could not create server: A server in port(8081) already exists for host(0.0.0.0) or one overlapping it (0.0.0.0).` ``` その後、プロジェクトを保存して再実行します。エラーが繰り返される場合は、ホストを ​`localhost`​ に変更してみてください。 2. アプリケーションが実行されたら、ブラウザーウィンドウを開き、リスナーへの URL を入力してアプリケーションをトリガーします。 ![ローカルサーバーからの応答「Hello Mule!」が表示されている Web ブラウザー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule-browser-response.png) HTTP Listener で設定されているのと同じホストとポート (例: `http://0.0.0.0:8081/hellomule`​) を使用する必要があります。 3. ブラウザーに ​`Hello Mule!`​ のメッセージが表示されることを確認します。 4. Anypoint Studio の ​**\[Console (コンソール)\]**​ タブに表示されるメッセージで、最初の ​`INFO`​ 行の​_最後_​に要求のパス (​`/hellomule`​) が付加されていることを確認します (​`org.mule.runtime.core.internal.processor.LoggerMessageProcessor: /hellomule`​)。 ![「Hello Mule」という名前の Mule アプリケーションからのログが表示されているコンソール出力](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule-console.png) ## [](#hello-mule-の例の設定-xml)Hello Mule の例の設定 XML 次の XML は、例で使用したフローと HTTP Listener の設定を示しています。スペースを節約するため、必要のない ​`doc:id`​ 属性は省略してあります。 Anypoint Studio からの XML 設定 ```XML ``` キャンバスの下にある ​**\[XML Configuration (XML 設定)\]**​ タブは、XML の編集ページを提供します。 ![Hello Mule の XML 設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-hellomule-xml.png) ## [](#関連情報)関連情報 - [チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-app-tutorial) - [DataWeave クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart) # チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成 ほとんどのインテグレーションでは、ソースから宛先に移動するときのデータの構造を変更する必要があります。Mule アプリケーション内で、Transform Message コンポーネントのドラッグアンドドロップインターフェースを使用して 1 つの項目または形式から別の項目または形式にデータをマップすることも、DataWeave スクリプト内でマッピングを手動で記述することもできます。通常、Mule アプリケーションは Studio でビルドしますが、Mule アプリケーション設定を XML で手動で記述することもできます。このチュートリアルでは、Studio を使用します。 小さなデータセットと Exchange で使用可能なトレーニング API を使用して、プロジェクトを作成し、API から異なる構造およびプロトコルへの変換マッピングを定義します。ドラッグアンドドロップを使用しますが、変換を定義する ​[DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave)​ コードも示しています。このチュートリアルを完了したら、独自のデータマッピングを作成する準備が整います。 ## [](#前提条件)前提条件 データマッピングワークフローに集中できるように、MuleSoft ではいくつかのセットアップタスクを完了することをお勧めします。 1. Exchange で [\[Training: American Flights API (トレーニング: American Flights API)](https://anypoint.mulesoft.com/exchange/68ef9520-24e9-4cf2-b2f5-620025690913/training-american-flights-api/)\]​ に移動し、\[GET (取得)\] ボタンをクリックして JSON でサンプル応答を表示します。 ![mruntime quickstart json](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-json.png) この構造を変換します。 2. [Anypoint Studio](https://docs.mulesoft.com/studio/to-download-and-install-studio)​ をダウンロードしてインストールします。 3. [Anypoint Platform トライアルアカウント](https://anypoint.mulesoft.com/login/#/signin?apintent=exchange)​がない場合は作成します。 4. Postman や Advanced REST クライアントなどの REST API クライアントを選択します。このチュートリアルでは、Advanced REST クライアントを使用します。 ## [](#ステップ-1-mule-4-プロジェクトを作成する)ステップ 1: Mule 4 プロジェクトを作成する Mule アプリケーションが含まれるプロジェクトを作成します。 1. Anypoint Studio を開き、​**\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ を ​`dw-tutorial4-flights-ws`​ に設定します。 3. その他はすべてデフォルトのままにして、​**\[Finish (完了)\]**​ を選択してプロジェクトを作成します。 完了したら、​**Package Explorer**​ ウィンドウで新しいプロジェクトのコンテンツを確認します。 ![mruntime quickstart package explorer](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-package-explorer.png) ## [](#ステップ-2-mule-4-アプリケーションを作成して設定する)ステップ 2: Mule 4 アプリケーションを作成して設定する 今度は、API からデータを取得するために必要な要素を追加し、DataWeave を使用して異なる構造に変換します。 1. American Flights API をリスンするために HTTP Listener 操作を追加します。\[Mule Palette (Mule パレット)\] で、HTTP 操作を表示するために \[HTTP\] を選択し、Listener 操作をキャンバスまでドラッグします。 ![mruntime quickstart listener](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-listener.png) \[Mule Palette (Mule パレット)\] に何も表示されない場合、Package Explorer で ​`src/main/mule`​ フォルダーのプロジェクトファイル ​`dw-tutorial4-flights-ws.xml`​ を開きます。 2. Listener 操作をダブルクリックしてそのプロパティタブを表示し、緑色のプラス記号をクリックして新しい設定を追加します。 ![mruntime quickstart listener properties](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-listener-properties.png) 3. HTTP Listener 設定ダイアログで、以下の値を追加します。 - **Host (ホスト)**​: `0.0.0.0` - **Port (ポート)**​: `8081` 4. **\[OK\]**​ をクリックしてこれらの変更を保存し、ダイアログを閉じます。 5. Listener の \[General (全般)\] タブで、​**\[Path: (パス:)\]**​ 項目を ​`/flights`​ に変更します。変更は自動的に保存されます。 ![mruntime quickstart path](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-path.png) 6. \[Mule Palette (Mule パレット)\] で、​**\[Add Modules (モジュールを追加)\]**​ を選択してモジュールおよびコネクタのリストを表示し、Database Connector を \[Mule Palette (Mule パレット)\] の左側までドラッグします。バージョンの選択を要求される場合があります。最新バージョンを選択します。 ![mruntime quickstart add db1](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-add-db1.png) 7. Database Connector が \[Mule Palette (Mule パレット)\] に追加され、その操作を表示できるようになります。Select 操作をフローまでドラッグします。 ![mruntime quickstart add db2](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-add-db2.png) 8. MuleSoft サンプル MySQL データベースからの応答をリスンするように Database 操作を設定しましょう。Select オペレーターをクリックしてそのプロパティタブを表示し、追加ボタン (緑色の十字) をクリックして \[Database Config (データベース設定)\] ダイアログを開きます。 9. ダイアログで Mule のサンプルデータベース値を選択または入力します。 - Connection (接続): `MySQL Connection` - **Host (ホスト)**​: `mudb.learn.mulesoft.com` - **Port (ポート)**​: `3306` - **User (ユーザー)**​: `mule` - **Password (パスワード)**​: `mule` - **Database (データベース)**​: `training` ![mruntime quickstart db values](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-db-values.png) 10. \[Database Config (データベース設定)\] ダイアログを表示したまま、​**\[Configure (設定)\] > \[Add Maven dependency (Maven 連動関係を追加)\]**​ を選択します。 11. **\[Pick a Maven dependency (Maven 連動関係を選択)\]**​ ダイアログで、​**\[Search Maven Central (Maven Central を検索)\]**​ 検索項目に ​`mysql-`​ と入力します。 12. 表示された項目から ​`mysql:mysql-connector-java`​ を選択します。 13. **\[Finish (完了)\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 ![mruntime quickstart db driver](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-db-driver.png) 14. **\[Test Connection (接続をテスト)\]**​ を選択します。​`Test connection successful`​ メッセージが表示されます。このメッセージが表示されない場合、前のステップに戻り、エラーを探してください。 15. **\[OK\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 16. Training: American Flights API からのすべてのフライトを返すクエリを作成します。 1. まだ開いていない場合、Select 操作をクリックしてそのプロパティタブを表示します。 2. クエリ項目で select ステートメントを追加します: `SELECT * FROM american`​。変更は自動的に保存されます。 ![mruntime quickstart select query](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-select-query.png) 17. さらに設定をテストするには、プロジェクトを実行します。フローが定義されているキャンバスを右クリックして、​**\[Run Project dw-tutorial4-flights-ws (プロジェクト dw-tutorial4-flights-ws を実行)\]**​ を選択できます。 18. \[Console (コンソール)\] タブを確認し、アプリケーションが実行されたら REST API クライアントを開きます。 19. クライアントで、要求を ​`http://localhost:8081/flights/`​ に送信します。この時点で、アプリケーションは American Flights API に対するクエリから受け取ったデータを処理できないため、​`500 Server Error`​ メッセージを返します。このエラーに対処するため、トレーニングの次のセクションでフローに Transform コンポーネントを追加します。 ![mruntime quickstart object](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-object.png) これでアプリケーションがセットアップされたため、JSON を必要とするサービスでコンシュームできるようにデータを JSON に変換する準備ができました。 アプリケーションで指定されたポートをふさぐ可能性があるオーファンプロセスが誤って作成されるのを防ぐために、Mule アプリケーションは実行されたままにしておいてください。 ## [](#ステップ-3-dataweave-データ変換を作成してテストする)ステップ 3: DataWeave データ変換を作成してテストする これで Mule アプリケーションが機能し、Training: American Flights API をリスンするようになたため、Transform Message コンポーネントを追加し、DataWeave のドラッグアンドドロップインターフェースを使用して Mule オブジェクトから JSON への変換を定義します。 1. \[Mule Palette (Mule パレット)\] で \[Core (コア)\] を選択し、\[Transform Message\] コンポーネントを見つけます。 ![mruntime quickstart add transform](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-add-transform.png) 2. \[Transform Message\] をキャンバスの Select 操作の右側までドラッグアンドドロップします。 ![mruntime quickstart canvas](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-canvas.png) 3. \[Transform Message\] コンポーネントをクリックしてグラフィカルビューとソースコードビューを表示します。 ![mruntime quickstart dw blank palette](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-dw-blank-palette.png) - 左側は入力および出力のメタデータ構造のグラフィカルビューです。マッピングは中央の線とノードポイントで表現されます。 - 右側は同じ構造およびマッピングのコードビューです。コードビューとグラフィカルビューでは同期が保たれます。 4. コードビューで、行 2 の出力タイプを ​`application/java`​ から ​`application/json`​ に変更し、行 4 および 5 の括弧を ​`payload`​ に置き換えます。 ![mruntime quickstart dw palette](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-dw-palette.png) 5. 変更内容を保存して、プロジェクトを再デプロイします。 6. REST クライアントで GET 要求を送信し、この変更内容をテストします: `GET http://localhost:8081/flights`​。 ![mruntime quickstart json1](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-json1.png) DataWeave スクリプトの 2 つの単語だけを使用して、Mule オブジェクトを JSON に変換しました。次に、既存のデータを API から提供した例に基づくデータ構造にマップします。この例は、もう 2 つ目のサービスが Training: American Flights API からデータをコンシュームする必要があることを示しています。 7. \[Transform Message\] の \[Output (出力)\] パネルで、​**\[Define metadata (メタデータを定義)\]**​ を選択して ​**\[Select metadata type (メタデータ型を選択)\]**​ ダイアログを開きます。 8. **\[Add (追加)\]**​ を選択して ​**\[Create new type (新しい型を作成)\]**​ ダイアログを開きます。 9. `american_flights_json`​ を入力して ​**\[Create type (型を作成)\]**​ を選択します。 ![mruntime quickstart empty type](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-empty-type.png) 10. **\[Select metadata type (メタデータ型を選択)\]**​ ダイアログで、型を ​**\[JSON\]**​ に設定します。 11. \[Type (型)\] の下のドロップダウンで、​**\[Schema (スキーマ)\]**​ を ​**\[Example (例)\]**​ に変更します。 12. 次の内容をコピーしてファイルに貼り付け、ローカルマシンまたは環境で保存します。ファイルに ​`american-flights-example.json`​ という名前を付けます。 ```json [{ "ID": 1, "code": "ER38sd", "price": 400.00, "departureDate": "2016/03/20", "origin": "MUA", "destination": "SFO", "emptySeats": 0, "plane": { "type": "Boeing 737", "totalSeats": 150 } }, { "ID": 2, "code": "ER45if", "price": 345.99, "departureDate": "2016/02/11", "origin": "MUA", "destination": "LAX", "emptySeats": 52, "plane": { "type": "Boeing 777", "totalSeats": 300 } }] ``` 13. **\[Select metadata type (メタデータ型)\]**​ ダイアログで、3 つのドットのボタンをクリックして作成したばかりのファイルに移動し、選択します。 ![mruntime quickstart json example2](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-json-example2.png) 14. **\[Select (選択)\]**​ を選択して変更内容を保存します。入力および出力のデータ構造が DataWeave インターフェースに表示されます。 ![mruntime quickstart input output](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-input-output.png) 15. 項目のマッピングを開始して変換を作成しましょう。 - 入力セクションから出力セクションまでドラッグして、同じ名前の項目をマップします。 - `ID` - `price` - `totalSeats` ドラッグアンドドロップすると、DataWeave コードが一番右側のペインで記述されます。 ![mruntime quickstart same name](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-same-name.png) - 残りのデータをマップします。 - `toAirport`​ から ​`destination` - `takeOffDate`​ から ​`departureDate` - `fromAirport`​ から ​`origin` - `seatsAvailable`​ から ​`emptySeats` - `planeType`​ から ​`type` - `code1`​ と ​`code2`​ の両方を ​`code`​ にドラッグします。 変換を作成するために項目をドラッグアンドドロップすると、DataWeave コードが生成されます。入力項目を誤った出力項目にドロップするなど、間違った場合、コードビューでエラーがマークされます。出力項目を右クリックし、​**\[Remove field mapping (項目マッピングを削除)\]**​ を選択してエラーを削除します。 16. サンプルデータを追加して、マッピング結果をプレビューしましょう。(不要であればこのステップはスキップできます)。コードビューで ​**\[Preview (プレビュー)\]**​ を選択し、​**\[Create required sample data to execute preview (プレビューを実行するために必要なサンプルデータを作成)\]**​ リンクをクリックします。 ![mruntime quickstart sample data1](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-sample-data1.png) 17. 入力パネルの ​**\[payload (ペイロード)\]**​ タブで、すべてのクエスチョンマークをデータに置き換えます。これらの値は \[Output (出力)\] パネルにも表示されます。Studio のメインメニューから ​**\[File (ファイル)\] > \[Save All (すべて保存)\]**​ を選択します。 18. 変換の定義が完了したら、テストしましょう。前にお勧めしたとおりに Mule アプリケーションを実行したままにしているとして、REST クライアントを開いて別の要求を API に送信します: `GET http://localhost:8081/flights`​。 ![mruntime quickstart transformed](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-quickstart-transformed.png) データが以前のクエリのように \[Input (入力)\] ペインの構造に従うのではなく、\[Output (出力)\] パネルで記述されている構造になっていることに注意してください。 これで、Mule オブジェクトから JSON へ、1 つのデータ構造から別のデータ構造へのデータの変換に成功したため、DataWeave 言語でのスクリプト作成を開始し (​[「DataWeave 言語クイックスタート」](#dataweave-quickstart.adoc)​を参照)、他の​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-components)​および他の​[コネクタおよびモジュール](https://docs.mulesoft.com/connectors/)​について調べる準備ができました。 # チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成 ほとんどのインテグレーションでは、ソースから宛先に移動するときのデータの構造を変更する必要があります。Mule アプリケーション内で、Transform Message コンポーネントのドラッグアンドドロップインターフェースを使用して 1 つの項目または形式から別の項目または形式にデータをマップすることも、DataWeave スクリプト内でマッピングを手動で記述することもできます。通常、Mule アプリケーションは Studio でビルドしますが、Mule アプリケーション設定を XML で手動で記述することもできます。このチュートリアルでは、Studio を使用します。 小さなデータセットと Exchange で使用可能なトレーニング API を使用して、プロジェクトを作成し、API から異なる構造およびプロトコルへの変換マッピングを定義します。ドラッグアンドドロップを使用しますが、変換を定義する ​[DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave)​ コードも示しています。このチュートリアルを完了したら、独自のデータマッピングを作成する準備が整います。 ## [](#前提条件)前提条件 データマッピングワークフローに集中できるように、MuleSoft ではいくつかのセットアップタスクを完了することをお勧めします。 1. Exchange で [\[Training: American Flights API (トレーニング: American Flights API)](https://anypoint.mulesoft.com/exchange/68ef9520-24e9-4cf2-b2f5-620025690913/training-american-flights-api/)\]​ に移動し、\[GET (取得)\] ボタンをクリックして JSON でサンプル応答を表示します。 ![mruntime quickstart json](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-json.png) この構造を変換します。 2. [Anypoint Studio](https://docs.mulesoft.com/studio/to-download-and-install-studio)​ をダウンロードしてインストールします。 3. [Anypoint Platform トライアルアカウント](https://anypoint.mulesoft.com/login/#/signin?apintent=exchange)​がない場合は作成します。 4. Postman や Advanced REST クライアントなどの REST API クライアントを選択します。このチュートリアルでは、Advanced REST クライアントを使用します。 ## [](#ステップ-1-mule-4-プロジェクトを作成する)ステップ 1: Mule 4 プロジェクトを作成する Mule アプリケーションが含まれるプロジェクトを作成します。 1. Anypoint Studio を開き、​**\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ を ​`dw-tutorial4-flights-ws`​ に設定します。 3. その他はすべてデフォルトのままにして、​**\[Finish (完了)\]**​ を選択してプロジェクトを作成します。 完了したら、​**Package Explorer**​ ウィンドウで新しいプロジェクトのコンテンツを確認します。 ![mruntime quickstart package explorer](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-package-explorer.png) ## [](#ステップ-2-mule-4-アプリケーションを作成して設定する)ステップ 2: Mule 4 アプリケーションを作成して設定する 今度は、API からデータを取得するために必要な要素を追加し、DataWeave を使用して異なる構造に変換します。 1. American Flights API をリスンするために HTTP Listener 操作を追加します。\[Mule Palette (Mule パレット)\] で、HTTP 操作を表示するために \[HTTP\] を選択し、Listener 操作をキャンバスまでドラッグします。 ![mruntime quickstart listener](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-listener.png) \[Mule Palette (Mule パレット)\] に何も表示されない場合、Package Explorer で ​`src/main/mule`​ フォルダーのプロジェクトファイル ​`dw-tutorial4-flights-ws.xml`​ を開きます。 2. Listener 操作をダブルクリックしてそのプロパティタブを表示し、緑色のプラス記号をクリックして新しい設定を追加します。 ![mruntime quickstart listener properties](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-listener-properties.png) 3. HTTP Listener 設定ダイアログで、以下の値を追加します。 - **Host (ホスト)**​: `0.0.0.0` - **Port (ポート)**​: `8081` 4. **\[OK\]**​ をクリックしてこれらの変更を保存し、ダイアログを閉じます。 5. Listener の \[General (全般)\] タブで、​**\[Path: (パス:)\]**​ 項目を ​`/flights`​ に変更します。変更は自動的に保存されます。 ![mruntime quickstart path](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-path.png) 6. \[Mule Palette (Mule パレット)\] で、​**\[Add Modules (モジュールを追加)\]**​ を選択してモジュールおよびコネクタのリストを表示し、Database Connector を \[Mule Palette (Mule パレット)\] の左側までドラッグします。バージョンの選択を要求される場合があります。最新バージョンを選択します。 ![mruntime quickstart add db1](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-add-db1.png) 7. Database Connector が \[Mule Palette (Mule パレット)\] に追加され、その操作を表示できるようになります。Select 操作をフローまでドラッグします。 ![mruntime quickstart add db2](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-add-db2.png) 8. MuleSoft サンプル MySQL データベースからの応答をリスンするように Database 操作を設定しましょう。Select オペレーターをクリックしてそのプロパティタブを表示し、追加ボタン (緑色の十字) をクリックして \[Database Config (データベース設定)\] ダイアログを開きます。 9. ダイアログで Mule のサンプルデータベース値を選択または入力します。 - Connection (接続): `MySQL Connection` - **Host (ホスト)**​: `mudb.learn.mulesoft.com` - **Port (ポート)**​: `3306` - **User (ユーザー)**​: `mule` - **Password (パスワード)**​: `mule` - **Database (データベース)**​: `training` ![mruntime quickstart db values](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-db-values.png) 10. \[Database Config (データベース設定)\] ダイアログを表示したまま、​**\[Configure (設定)\] > \[Add Maven dependency (Maven 連動関係を追加)\]**​ を選択します。 11. **\[Pick a Maven dependency (Maven 連動関係を選択)\]**​ ダイアログで、​**\[Search Maven Central (Maven Central を検索)\]**​ 検索項目に ​`mysql-`​ と入力します。 12. 表示された項目から ​`mysql:mysql-connector-java`​ を選択します。 13. **\[Finish (完了)\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 ![mruntime quickstart db driver](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-db-driver.png) 14. **\[Test Connection (接続をテスト)\]**​ を選択します。​`Test connection successful`​ メッセージが表示されます。このメッセージが表示されない場合、前のステップに戻り、エラーを探してください。 15. **\[OK\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 16. Training: American Flights API からのすべてのフライトを返すクエリを作成します。 1. まだ開いていない場合、Select 操作をクリックしてそのプロパティタブを表示します。 2. クエリ項目で select ステートメントを追加します: `SELECT * FROM american`​。変更は自動的に保存されます。 ![mruntime quickstart select query](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-select-query.png) 17. さらに設定をテストするには、プロジェクトを実行します。フローが定義されているキャンバスを右クリックして、​**\[Run Project dw-tutorial4-flights-ws (プロジェクト dw-tutorial4-flights-ws を実行)\]**​ を選択できます。 18. \[Console (コンソール)\] タブを確認し、アプリケーションが実行されたら REST API クライアントを開きます。 19. クライアントで、要求を ​`http://localhost:8081/flights/`​ に送信します。この時点で、アプリケーションは American Flights API に対するクエリから受け取ったデータを処理できないため、​`500 Server Error`​ メッセージを返します。このエラーに対処するため、トレーニングの次のセクションでフローに Transform コンポーネントを追加します。 ![mruntime quickstart object](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-object.png) これでアプリケーションがセットアップされたため、JSON を必要とするサービスでコンシュームできるようにデータを JSON に変換する準備ができました。
アプリケーションで指定されたポートをふさぐ可能性があるオーファンプロセスが誤って作成されるのを防ぐために、Mule アプリケーションは実行されたままにしておいてください。
## [](#ステップ-3-dataweave-データ変換を作成してテストする)ステップ 3: DataWeave データ変換を作成してテストする これで Mule アプリケーションが機能し、Training: American Flights API をリスンするようになたため、Transform Message コンポーネントを追加し、DataWeave のドラッグアンドドロップインターフェースを使用して Mule オブジェクトから JSON への変換を定義します。 1. \[Mule Palette (Mule パレット)\] で \[Core (コア)\] を選択し、\[Transform Message\] コンポーネントを見つけます。 ![mruntime quickstart add transform](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-add-transform.png) 2. \[Transform Message\] をキャンバスの Select 操作の右側までドラッグアンドドロップします。 ![mruntime quickstart canvas](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-canvas.png) 3. \[Transform Message\] コンポーネントをクリックしてグラフィカルビューとソースコードビューを表示します。 ![mruntime quickstart dw blank palette](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-dw-blank-palette.png) - 左側は入力および出力のメタデータ構造のグラフィカルビューです。マッピングは中央の線とノードポイントで表現されます。 - 右側は同じ構造およびマッピングのコードビューです。コードビューとグラフィカルビューでは同期が保たれます。 4. コードビューで、行 2 の出力タイプを ​`application/java`​ から ​`application/json`​ に変更し、行 4 および 5 の括弧を ​`payload`​ に置き換えます。 ![mruntime quickstart dw palette](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-dw-palette.png) 5. 変更内容を保存して、プロジェクトを再デプロイします。 6. REST クライアントで GET 要求を送信し、この変更内容をテストします: `GET http://localhost:8081/flights`​。 ![mruntime quickstart json1](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-json1.png) DataWeave スクリプトの 2 つの単語だけを使用して、Mule オブジェクトを JSON に変換しました。次に、既存のデータを API から提供した例に基づくデータ構造にマップします。この例は、もう 2 つ目のサービスが Training: American Flights API からデータをコンシュームする必要があることを示しています。 7. \[Transform Message\] の \[Output (出力)\] パネルで、​**\[Define metadata (メタデータを定義)\]**​ を選択して ​**\[Select metadata type (メタデータ型を選択)\]**​ ダイアログを開きます。 8. **\[Add (追加)\]**​ を選択して ​**\[Create new type (新しい型を作成)\]**​ ダイアログを開きます。 9. `american_flights_json`​ を入力して ​**\[Create type (型を作成)\]**​ を選択します。 ![mruntime quickstart empty type](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-empty-type.png) 10. **\[Select metadata type (メタデータ型を選択)\]**​ ダイアログで、型を ​**\[JSON\]**​ に設定します。 11. \[Type (型)\] の下のドロップダウンで、​**\[Schema (スキーマ)\]**​ を ​**\[Example (例)\]**​ に変更します。 12. 次の内容をコピーしてファイルに貼り付け、ローカルマシンまたは環境で保存します。ファイルに ​`american-flights-example.json`​ という名前を付けます。 ```json [{ "ID": 1, "code": "ER38sd", "price": 400.00, "departureDate": "2016/03/20", "origin": "MUA", "destination": "SFO", "emptySeats": 0, "plane": { "type": "Boeing 737", "totalSeats": 150 } }, { "ID": 2, "code": "ER45if", "price": 345.99, "departureDate": "2016/02/11", "origin": "MUA", "destination": "LAX", "emptySeats": 52, "plane": { "type": "Boeing 777", "totalSeats": 300 } }] ``` 13. **\[Select metadata type (メタデータ型)\]**​ ダイアログで、3 つのドットのボタンをクリックして作成したばかりのファイルに移動し、選択します。 ![mruntime quickstart json example2](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-json-example2.png) 14. **\[Select (選択)\]**​ を選択して変更内容を保存します。入力および出力のデータ構造が DataWeave インターフェースに表示されます。 ![mruntime quickstart input output](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-input-output.png) 15. 項目のマッピングを開始して変換を作成しましょう。 - 入力セクションから出力セクションまでドラッグして、同じ名前の項目をマップします。 - `ID` - `price` - `totalSeats` ドラッグアンドドロップすると、DataWeave コードが一番右側のペインで記述されます。 ![mruntime quickstart same name](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-same-name.png) - 残りのデータをマップします。 - `toAirport`​ から ​`destination` - `takeOffDate`​ から ​`departureDate` - `fromAirport`​ から ​`origin` - `seatsAvailable`​ から ​`emptySeats` - `planeType`​ から ​`type` - `code1`​ と ​`code2`​ の両方を ​`code`​ にドラッグします。 変換を作成するために項目をドラッグアンドドロップすると、DataWeave コードが生成されます。入力項目を誤った出力項目にドロップするなど、間違った場合、コードビューでエラーがマークされます。出力項目を右クリックし、​**\[Remove field mapping (項目マッピングを削除)\]**​ を選択してエラーを削除します。 16. サンプルデータを追加して、マッピング結果をプレビューしましょう。(不要であればこのステップはスキップできます)。コードビューで ​**\[Preview (プレビュー)\]**​ を選択し、​**\[Create required sample data to execute preview (プレビューを実行するために必要なサンプルデータを作成)\]**​ リンクをクリックします。 ![mruntime quickstart sample data1](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-sample-data1.png) 17. 入力パネルの ​**\[payload (ペイロード)\]**​ タブで、すべてのクエスチョンマークをデータに置き換えます。これらの値は \[Output (出力)\] パネルにも表示されます。Studio のメインメニューから ​**\[File (ファイル)\] > \[Save All (すべて保存)\]**​ を選択します。 18. 変換の定義が完了したら、テストしましょう。前にお勧めしたとおりに Mule アプリケーションを実行したままにしているとして、REST クライアントを開いて別の要求を API に送信します: `GET http://localhost:8081/flights`​。 ![mruntime quickstart transformed](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-quickstart-transformed.png) データが以前のクエリのように \[Input (入力)\] ペインの構造に従うのではなく、\[Output (出力)\] パネルで記述されている構造になっていることに注意してください。 これで、Mule オブジェクトから JSON へ、1 つのデータ構造から別のデータ構造へのデータの変換に成功したため、DataWeave 言語でのスクリプト作成を開始し (​[「DataWeave 言語クイックスタート」](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照)、他の​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-components)​および他の​[コネクタおよびモジュール](https://docs.mulesoft.com/connectors/)​について調べる準備ができました。 # チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成 ほとんどのインテグレーションでは、提供元から宛先に移動するときのデータの構造を変更する必要があります。Mule アプリケーション内で、Transform Message コンポーネントのドラッグアンドドロップインターフェースを使用して 1 つの項目または形式から別の項目または形式にデータをマップすることも、DataWeave スクリプト内でマッピングを手動で記述することもできます。通常、Mule アプリケーションは Studio でビルドしますが、Mule アプリケーション設定を XML で手動で記述することもできます。このチュートリアルでは、Studio を使用します。 小さなデータセットと Exchange で使用可能なトレーニング API を使用して、プロジェクトを作成し、API から異なる構造およびプロトコルへの変換マッピングを定義します。ドラッグアンドドロップを使用しますが、変換を定義する ​[DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave)​ コードも示しています。このチュートリアルを完了したら、独自のデータマッピングを作成する準備が整います。 ## [](#前提条件)前提条件 データマッピングワークフローに集中できるように、MuleSoft ではいくつかのセットアップタスクを完了することをお勧めします。 1. Exchange で [\[Training: American Flights API (トレーニング: American Flights API)](https://anypoint.mulesoft.com/exchange/68ef9520-24e9-4cf2-b2f5-620025690913/training-american-flights-api/)\]​ に移動し、\[GET (取得)\] ボタンをクリックして JSON でサンプル応答を表示します。 ![mruntime quickstart json](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-json.png) この構造を変換します。 2. [Anypoint Studio](https://docs.mulesoft.com/studio/to-download-and-install-studio)​ をダウンロードしてインストールします。 3. [Anypoint Platform トライアルアカウント](https://anypoint.mulesoft.com/login/#/signin?apintent=exchange)​がない場合は作成します。 4. Postman や Advanced REST クライアントなどの REST API クライアントを選択します。このチュートリアルでは、Advanced REST クライアントを使用します。 ## [](#ステップ-1-mule-4-プロジェクトを作成する)ステップ 1: Mule 4 プロジェクトを作成する Mule アプリケーションが含まれるプロジェクトを作成します。 1. Anypoint Studio を開き、​**\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ を ​`dw-tutorial4-flights-ws`​ に設定します。 3. その他はすべてデフォルトのままにして、​**\[Finish (完了)\]**​ を選択してプロジェクトを作成します。 完了したら、​**Package Explorer**​ ウィンドウで新しいプロジェクトのコンテンツを確認します。 ![mruntime quickstart package explorer](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-package-explorer.png) ## [](#ステップ-2-mule-4-アプリケーションを作成して設定する)ステップ 2: Mule 4 アプリケーションを作成して設定する 今度は、API からデータを取得するために必要な要素を追加し、DataWeave を使用して異なる構造に変換します。 1. American Flights API をリスンするために HTTP Listener 操作を追加します。\[Mule Palette (Mule パレット)\] で、HTTP 操作を表示するために \[HTTP\] を選択し、Listener 操作をキャンバスまでドラッグします。 ![mruntime quickstart listener](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-listener.png) \[Mule Palette (Mule パレット)\] に何も表示されない場合、Package Explorer で ​`src/main/mule`​ フォルダーのプロジェクトファイル ​`dw-tutorial4-flights-ws.xml`​ を開きます。 2. Listener 操作をダブルクリックしてそのプロパティタブを表示し、緑色のプラス記号をクリックして新しい設定を追加します。 ![mruntime quickstart listener properties](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-listener-properties.png) 3. HTTP Listener 設定ダイアログで、以下の値を追加します。 - **Host (ホスト)**​: `0.0.0.0` - **Port (ポート)**​: `8081` 4. **\[OK\]**​ をクリックしてこれらの変更を保存し、ダイアログを閉じます。 5. Listener の \[General (全般)\] タブで、​**\[Path: (パス:)\]**​ 項目を ​`/flights`​ に変更します。変更は自動的に保存されます。 ![mruntime quickstart path](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-path.png) 6. \[Mule Palette (Mule パレット)\] で、​**\[Add Modules (モジュールを追加)\]**​ を選択してモジュールおよびコネクタのリストを表示し、Database Connector を \[Mule Palette (Mule パレット)\] の左側までドラッグします。バージョンの選択を要求される場合があります。最新バージョンを選択します。 ![mruntime quickstart add db1](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-add-db1.png) 7. Database Connector が \[Mule Palette (Mule パレット)\] に追加され、その操作を表示できるようになります。Select 操作をフローまでドラッグします。 ![mruntime quickstart add db2](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-add-db2.png) 8. MuleSoft サンプル MySQL データベースからの応答をリスンするように Database 操作を設定しましょう。Select オペレーターをクリックしてそのプロパティタブを表示し、追加ボタン (緑色の十字) をクリックして \[Database Config (データベース設定)\] ダイアログを開きます。 9. ダイアログで Mule のサンプルデータベース値を選択または入力します。 - Connection (接続): `MySQL Connection` - **Host (ホスト)**​: `mudb.learn.mulesoft.com` - **Port (ポート)**​: `3306` - **User (ユーザー)**​: `mule` - **Password (パスワード)**​: `mule` - **Database (データベース)**​: `training` ![mruntime quickstart db values](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-db-values.png) 10. \[Database Config (データベース設定)\] ダイアログを表示したまま、​**\[Configure (設定)\] > \[Add Maven dependency (Maven 連動関係を追加)\]**​ を選択します。 11. **\[Pick a Maven dependency (Maven 連動関係を選択)\]**​ ダイアログで、​**\[Search Maven Central (Maven Central を検索)\]**​ 検索項目に ​`mysql-`​ と入力します。 12. 表示された項目から ​`mysql:mysql-connector-java`​ を選択します。 13. **\[Finish (完了)\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 ![mruntime quickstart db driver](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-db-driver.png) 14. **\[Test Connection (接続をテスト)\]**​ を選択します。​`Test connection successful`​ メッセージが表示されます。このメッセージが表示されない場合、前のステップに戻り、エラーを探してください。 15. **\[OK\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 16. Training: American Flights API からのすべてのフライトを返すクエリを作成します。 1. まだ開いていない場合、Select 操作をクリックしてそのプロパティタブを表示します。 2. クエリ項目で select ステートメントを追加します: `SELECT * FROM american`​。変更は自動的に保存されます。 ![mruntime quickstart select query](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-select-query.png) 17. さらに設定をテストするには、プロジェクトを実行します。フローが定義されているキャンバスを右クリックして、​**\[Run Project dw-tutorial4-flights-ws (プロジェクト dw-tutorial4-flights-ws を実行)\]**​ を選択できます。 18. \[Console (コンソール)\] タブを確認し、アプリケーションが実行されたら REST API クライアントを開きます。 19. クライアントで、要求を ​`http://localhost:8081/flights/`​ に送信します。この時点で、アプリケーションは American Flights API に対するクエリから受け取ったデータを処理できないため、​`500 Server Error`​ メッセージを返します。このエラーに対処するため、トレーニングの次のセクションでフローに Transform コンポーネントを追加します。 ![mruntime quickstart object](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-object.png) これでアプリケーションがセットアップされたため、JSON を必要とするサービスでコンシュームできるようにデータを JSON に変換する準備ができました。
アプリケーションで指定されたポートをふさぐ可能性があるオーファンプロセスが誤って作成されるのを防ぐために、Mule アプリケーションは実行されたままにしておいてください。
## [](#ステップ-3-dataweave-データ変換を作成してテストする)ステップ 3: DataWeave データ変換を作成してテストする これで Mule アプリケーションが機能し、Training: American Flights API をリスンするようになたため、Transform Message コンポーネントを追加し、DataWeave のドラッグアンドドロップインターフェースを使用して Mule オブジェクトから JSON への変換を定義します。 1. \[Mule Palette (Mule パレット)\] で \[Core (コア)\] を選択し、\[Transform Message\] コンポーネントを見つけます。 ![mruntime quickstart add transform](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-add-transform.png) 2. \[Transform Message\] をキャンバスの Select 操作の右側までドラッグアンドドロップします。 ![mruntime quickstart canvas](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-canvas.png) 3. \[Transform Message\] コンポーネントをクリックしてグラフィカルビューとソースコードビューを表示します。 ![mruntime quickstart dw blank palette](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-dw-blank-palette.png) - 左側は入力および出力のメタデータ構造のグラフィカルビューです。マッピングは中央の線とノードポイントで表現されます。 - 右側は同じ構造およびマッピングのコードビューです。コードビューとグラフィカルビューでは同期が保たれます。 4. コードビューで、行 2 の出力タイプを ​`application/java`​ から ​`application/json`​ に変更し、行 4 および 5 の括弧を ​`payload`​ に置き換えます。 ![mruntime quickstart dw palette](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-dw-palette.png) 5. 変更内容を保存して、プロジェクトを再デプロイします。 6. REST クライアントで GET 要求を送信し、この変更内容をテストします: `GET http://localhost:8081/flights`​。 ![mruntime quickstart json1](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-json1.png) DataWeave スクリプトの 2 つの単語だけを使用して、Mule オブジェクトを JSON に変換しました。次に、既存のデータを API から提供した例に基づくデータ構造にマップします。この例は、もう 2 つ目のサービスが Training: American Flights API からデータをコンシュームする必要があることを示しています。 7. \[Transform Message\] の \[Output (出力)\] パネルで、​**\[Define metadata (メタデータを定義)\]**​ を選択して ​**\[Select metadata type (メタデータ型を選択)\]**​ ダイアログを開きます。 8. **\[Add (追加)\]**​ を選択して ​**\[Create new type (新しい型を作成)\]**​ ダイアログを開きます。 9. `american_flights_json`​ を入力して ​**\[Create type (型を作成)\]**​ を選択します。 ![mruntime quickstart empty type](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-empty-type.png) 10. **\[Select metadata type (メタデータ型を選択)\]**​ ダイアログで、型を ​**\[JSON\]**​ に設定します。 11. \[Type (型)\] の下のドロップダウンで、​**\[Schema (スキーマ)\]**​ を ​**\[Example (例)\]**​ に変更します。 12. 次の内容をコピーしてファイルに貼り付け、ローカルマシンまたは環境で保存します。ファイルに ​`american-flights-example.json`​ という名前を付けます。 ```json [{ "ID": 1, "code": "ER38sd", "price": 400.00, "departureDate": "2016/03/20", "origin": "MUA", "destination": "SFO", "emptySeats": 0, "plane": { "type": "Boeing 737", "totalSeats": 150 } }, { "ID": 2, "code": "ER45if", "price": 345.99, "departureDate": "2016/02/11", "origin": "MUA", "destination": "LAX", "emptySeats": 52, "plane": { "type": "Boeing 777", "totalSeats": 300 } }] ``` 13. **\[Select metadata type (メタデータ型)\]**​ ダイアログで、3 つのドットのボタンをクリックして作成したばかりのファイルに移動し、選択します。 ![mruntime quickstart json example2](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-json-example2.png) 14. **\[Select (選択)\]**​ を選択して変更内容を保存します。入力および出力のデータ構造が DataWeave インターフェースに表示されます。 ![mruntime quickstart input output](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-input-output.png) 15. 項目のマッピングを開始して変換を作成しましょう。 - 入力セクションから出力セクションまでドラッグして、同じ名前の項目をマップします。 - `ID` - `price` - `totalSeats` ドラッグアンドドロップすると、DataWeave コードが一番右側のペインで記述されます。 ![mruntime quickstart same name](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-same-name.png) - 残りのデータをマップします。 - `toAirport`​ から ​`destination` - `takeOffDate`​ から ​`departureDate` - `fromAirport`​ から ​`origin` - `seatsAvailable`​ から ​`emptySeats` - `planeType`​ から ​`type` - `code1`​ と ​`code2`​ の両方を ​`code`​ にドラッグします。 変換を作成するために項目をドラッグアンドドロップすると、DataWeave コードが生成されます。入力項目を誤った出力項目にドロップするなど、間違った場合、コードビューでエラーがマークされます。出力項目を右クリックし、​**\[Remove field mapping (項目マッピングを削除)\]**​ を選択してエラーを削除します。 16. サンプルデータを追加して、マッピング結果をプレビューしましょう。(不要であればこのステップはスキップできます)。コードビューで ​**\[Preview (プレビュー)\]**​ を選択し、​**\[Create required sample data to execute preview (プレビューを実行するために必要なサンプルデータを作成)\]**​ リンクをクリックします。 ![mruntime quickstart sample data1](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-sample-data1.png) 17. 入力パネルの ​**\[payload (ペイロード)\]**​ タブで、すべてのクエスチョンマークをデータに置き換えます。これらの値は \[Output (出力)\] パネルにも表示されます。Studio のメインメニューから ​**\[File (ファイル)\] > \[Save All (すべて保存)\]**​ を選択します。 18. 変換の定義が完了したら、テストしましょう。前にお勧めしたとおりに Mule アプリケーションを実行したままにしているとして、REST クライアントを開いて別の要求を API に送信します: `GET http://localhost:8081/flights`​。 ![mruntime quickstart transformed](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-quickstart-transformed.png) データが以前のクエリのように \[Input (入力)\] ペインの構造に従うのではなく、\[Output (出力)\] パネルで記述されている構造になっていることに注意してください。 これで、Mule オブジェクトから JSON へ、1 つのデータ構造から別のデータ構造へのデータの変換に成功したため、DataWeave 言語でのスクリプト作成を開始し (​[「DataWeave 言語クイックスタート」](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照)、他の​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-components)​および他の​[コネクタおよびモジュール](https://docs.mulesoft.com/connectors/)​について調べる準備ができました。 # チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成 ほとんどのインテグレーションでは、ソースから宛先に移動するときのデータの構造を変更する必要があります。Mule アプリケーション内で、Transform Message コンポーネントのドラッグアンドドロップインターフェースを使用して 1 つの項目または形式から別の項目または形式にデータをマップすることも、DataWeave スクリプト内でマッピングを手動で記述することもできます。通常、Mule アプリケーションは Studio でビルドしますが、Mule アプリケーション設定を XML で手動で記述することもできます。このチュートリアルでは、Studio を使用します。 小さなデータセットと Exchange で使用可能なトレーニング API を使用して、プロジェクトを作成し、API から異なる構造およびプロトコルへの変換マッピングを定義します。ドラッグアンドドロップを使用しますが、変換を定義する ​[DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave)​ コードも示しています。このチュートリアルを完了したら、独自のデータマッピングを作成する準備が整います。 ## [](#前提条件)前提条件 データマッピングワークフローに集中できるように、MuleSoft ではいくつかのセットアップタスクを完了することをお勧めします。 1. Exchange で [\[Training: American Flights API (トレーニング: American Flights API)](https://anypoint.mulesoft.com/exchange/68ef9520-24e9-4cf2-b2f5-620025690913/training-american-flights-api/)\]​ に移動し、\[GET (取得)\] ボタンをクリックして JSON でサンプル応答を表示します。 ![mruntime quickstart json](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-json.png) この構造を変換します。 2. [Anypoint Studio](https://docs.mulesoft.com/studio/to-download-and-install-studio)​ をダウンロードしてインストールします。 3. [Anypoint Platform トライアルアカウント](https://anypoint.mulesoft.com/login/#/signin?apintent=exchange)​がない場合は作成します。 4. Postman や Advanced REST クライアントなどの REST API クライアントを選択します。このチュートリアルでは、Advanced REST クライアントを使用します。 ## [](#ステップ-1-mule-4-プロジェクトを作成する)ステップ 1: Mule 4 プロジェクトを作成する Mule アプリケーションが含まれるプロジェクトを作成します。 1. Anypoint Studio を開き、​**\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ を ​`dw-tutorial4-flights-ws`​ に設定します。 3. その他はすべてデフォルトのままにして、​**\[Finish (完了)\]**​ を選択してプロジェクトを作成します。 完了したら、​**Package Explorer**​ ウィンドウで新しいプロジェクトのコンテンツを確認します。 ![mruntime quickstart package explorer](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-package-explorer.png) ## [](#ステップ-2-mule-4-アプリケーションを作成して設定する)ステップ 2: Mule 4 アプリケーションを作成して設定する 今度は、API からデータを取得するために必要な要素を追加し、DataWeave を使用して異なる構造に変換します。 1. American Flights API をリスンするために HTTP Listener 操作を追加します。\[Mule Palette (Mule パレット)\] で、HTTP 操作を表示するために \[HTTP\] を選択し、Listener 操作をキャンバスまでドラッグします。 ![mruntime quickstart listener](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-listener.png) \[Mule Palette (Mule パレット)\] に何も表示されない場合、Package Explorer で ​`src/main/mule`​ フォルダーのプロジェクトファイル ​`dw-tutorial4-flights-ws.xml`​ を開きます。 2. Listener 操作をダブルクリックしてそのプロパティタブを表示し、緑色のプラス記号をクリックして新しい設定を追加します。 ![mruntime quickstart listener properties](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-listener-properties.png) 3. HTTP Listener 設定ダイアログで、以下の値を追加します。 - **Host (ホスト)**​: `0.0.0.0` - **Port (ポート)**​: `8081` 4. **\[OK\]**​ をクリックしてこれらの変更を保存し、ダイアログを閉じます。 5. Listener の \[General (全般)\] タブで、​**\[Path: (パス:)\]**​ 項目を ​`/flights`​ に変更します。変更は自動的に保存されます。 ![mruntime quickstart path](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-path.png) 6. \[Mule Palette (Mule パレット)\] で、​**\[Add Modules (モジュールを追加)\]**​ を選択してモジュールおよびコネクタのリストを表示し、Database Connector を \[Mule Palette (Mule パレット)\] の左側までドラッグします。バージョンの選択を要求される場合があります。最新バージョンを選択します。 ![mruntime quickstart add db1](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-add-db1.png) 7. Database Connector が \[Mule Palette (Mule パレット)\] に追加され、その操作を表示できるようになります。Select 操作をフローまでドラッグします。 ![mruntime quickstart add db2](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-add-db2.png) 8. MuleSoft サンプル MySQL データベースからの応答をリスンするように Database 操作を設定しましょう。Select オペレーターをクリックしてそのプロパティタブを表示し、追加ボタン (緑色の十字) をクリックして \[Database Config (データベース設定)\] ダイアログを開きます。 9. ダイアログで Mule のサンプルデータベース値を選択または入力します。 - Connection (接続): `MySQL Connection` - **Host (ホスト)**​: `mudb.learn.mulesoft.com` - **Port (ポート)**​: `3306` - **User (ユーザー)**​: `mule` - **Password (パスワード)**​: `mule` - **Database (データベース)**​: `training` ![mruntime quickstart db values](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-db-values.png) 10. \[Database Config (データベース設定)\] ダイアログを表示したまま、​**\[Configure (設定)\] > \[Add Maven dependency (Maven 連動関係を追加)\]**​ を選択します。 11. **\[Pick a Maven dependency (Maven 連動関係を選択)\]**​ ダイアログで、​**\[Search Maven Central (Maven Central を検索)\]**​ 検索項目に ​`mysql-`​ と入力します。 12. 表示された項目から ​`mysql:mysql-connector-java`​ を選択します。 13. **\[Finish (完了)\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 ![mruntime quickstart db driver](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-db-driver.png) 14. **\[Test Connection (接続をテスト)\]**​ を選択します。​`Test connection successful`​ メッセージが表示されます。このメッセージが表示されない場合、前のステップに戻り、エラーを探してください。 15. **\[OK\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 16. Training: American Flights API からのすべてのフライトを返すクエリを作成します。 1. まだ開いていない場合、Select 操作をクリックしてそのプロパティタブを表示します。 2. クエリ項目で select ステートメントを追加します: `SELECT * FROM american`​。変更は自動的に保存されます。 ![mruntime quickstart select query](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-select-query.png) 17. さらに設定をテストするには、プロジェクトを実行します。フローが定義されているキャンバスを右クリックして、​**\[Run Project dw-tutorial4-flights-ws (プロジェクト dw-tutorial4-flights-ws を実行)\]**​ を選択できます。 18. \[Console (コンソール)\] タブを確認し、アプリケーションが実行されたら REST API クライアントを開きます。 19. クライアントで、要求を ​`http://localhost:8081/flights/`​ に送信します。この時点で、アプリケーションは American Flights API に対するクエリから受け取ったデータを処理できないため、​`500 Server Error`​ メッセージを返します。このエラーに対処するため、トレーニングの次のセクションでフローに Transform コンポーネントを追加します。 ![mruntime quickstart object](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-object.png) これでアプリケーションがセットアップされたため、JSON を必要とするサービスでコンシュームできるようにデータを JSON に変換する準備ができました。
アプリケーションで指定されたポートをふさぐ可能性があるオーファンプロセスが誤って作成されるのを防ぐために、Mule アプリケーションは実行されたままにしておいてください。
## [](#ステップ-3-dataweave-データ変換を作成してテストする)ステップ 3: DataWeave データ変換を作成してテストする これで Mule アプリケーションが機能し、Training: American Flights API をリスンするようになたため、Transform Message コンポーネントを追加し、DataWeave のドラッグアンドドロップインターフェースを使用して Mule オブジェクトから JSON への変換を定義します。 1. \[Mule Palette (Mule パレット)\] で \[Core (コア)\] を選択し、\[Transform Message\] コンポーネントを見つけます。 ![mruntime quickstart add transform](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-add-transform.png) 2. \[Transform Message\] をキャンバスの Select 操作の右側までドラッグアンドドロップします。 ![mruntime quickstart canvas](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-canvas.png) 3. \[Transform Message\] コンポーネントをクリックしてグラフィカルビューとソースコードビューを表示します。 ![mruntime quickstart dw blank palette](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-dw-blank-palette.png) - 左側は入力および出力のメタデータ構造のグラフィカルビューです。マッピングは中央の線とノードポイントで表現されます。 - 右側は同じ構造およびマッピングのコードビューです。コードビューとグラフィカルビューでは同期が保たれます。 4. コードビューで、行 2 の出力タイプを ​`application/java`​ から ​`application/json`​ に変更し、行 4 および 5 の括弧を ​`payload`​ に置き換えます。 ![mruntime quickstart dw palette](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-dw-palette.png) 5. 変更内容を保存して、プロジェクトを再デプロイします。 6. REST クライアントで GET 要求を送信し、この変更内容をテストします: `GET http://localhost:8081/flights`​。 ![mruntime quickstart json1](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-json1.png) DataWeave スクリプトの 2 つの単語だけを使用して、Mule オブジェクトを JSON に変換しました。次に、既存のデータを API から提供した例に基づくデータ構造にマップします。この例は、もう 2 つ目のサービスが Training: American Flights API からデータをコンシュームする必要があることを示しています。 7. \[Transform Message\] の \[Output (出力)\] パネルで、​**\[Define metadata (メタデータを定義)\]**​ を選択して ​**\[Select metadata type (メタデータ型を選択)\]**​ ダイアログを開きます。 8. **\[Add (追加)\]**​ を選択して ​**\[Create new type (新しい型を作成)\]**​ ダイアログを開きます。 9. `american_flights_json`​ を入力して ​**\[Create type (型を作成)\]**​ を選択します。 ![mruntime quickstart empty type](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-empty-type.png) 10. **\[Select metadata type (メタデータ型を選択)\]**​ ダイアログで、型を ​**\[JSON\]**​ に設定します。 11. \[Type (型)\] の下のドロップダウンで、​**\[Schema (スキーマ)\]**​ を ​**\[Example (例)\]**​ に変更します。 12. 次の内容をコピーしてファイルに貼り付け、ローカルマシンまたは環境で保存します。ファイルに ​`american-flights-example.json`​ という名前を付けます。 ```json [{ "ID": 1, "code": "ER38sd", "price": 400.00, "departureDate": "2016/03/20", "origin": "MUA", "destination": "SFO", "emptySeats": 0, "plane": { "type": "Boeing 737", "totalSeats": 150 } }, { "ID": 2, "code": "ER45if", "price": 345.99, "departureDate": "2016/02/11", "origin": "MUA", "destination": "LAX", "emptySeats": 52, "plane": { "type": "Boeing 777", "totalSeats": 300 } }] ``` 13. **\[Select metadata type (メタデータ型)\]**​ ダイアログで、3 つのドットのボタンをクリックして作成したばかりのファイルに移動し、選択します。 ![mruntime quickstart json example2](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-json-example2.png) 14. **\[Select (選択)\]**​ を選択して変更内容を保存します。入力および出力のデータ構造が DataWeave インターフェースに表示されます。 ![mruntime quickstart input output](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-input-output.png) 15. 項目のマッピングを開始して変換を作成しましょう。 - 入力セクションから出力セクションまでドラッグして、同じ名前の項目をマップします。 - `ID` - `price` - `totalSeats` ドラッグアンドドロップすると、DataWeave コードが一番右側のペインで記述されます。 ![mruntime quickstart same name](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-same-name.png) - 残りのデータをマップします。 - `toAirport`​ から ​`destination` - `takeOffDate`​ から ​`departureDate` - `fromAirport`​ から ​`origin` - `seatsAvailable`​ から ​`emptySeats` - `planeType`​ から ​`type` - `code1`​ と ​`code2`​ の両方を ​`code`​ にドラッグします。 変換を作成するために項目をドラッグアンドドロップすると、DataWeave コードが生成されます。入力項目を誤った出力項目にドロップするなど、間違った場合、コードビューでエラーがマークされます。出力項目を右クリックし、​**\[Remove field mapping (項目マッピングを削除)\]**​ を選択してエラーを削除します。 16. サンプルデータを追加して、マッピング結果をプレビューしましょう。(不要であればこのステップはスキップできます)。コードビューで ​**\[Preview (プレビュー)\]**​ を選択し、​**\[Create required sample data to execute preview (プレビューを実行するために必要なサンプルデータを作成)\]**​ リンクをクリックします。 ![mruntime quickstart sample data1](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-sample-data1.png) 17. 入力パネルの ​**\[payload (ペイロード)\]**​ タブで、すべてのクエスチョンマークをデータに置き換えます。これらの値は \[Output (出力)\] パネルにも表示されます。Studio のメインメニューから ​**\[File (ファイル)\] > \[Save All (すべて保存)\]**​ を選択します。 18. 変換の定義が完了したら、テストしましょう。前にお勧めしたとおりに Mule アプリケーションを実行したままにしているとして、REST クライアントを開いて別の要求を API に送信します: `GET http://localhost:8081/flights`​。 ![mruntime quickstart transformed](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-quickstart-transformed.png) データが以前のクエリのように \[Input (入力)\] ペインの構造に従うのではなく、\[Output (出力)\] パネルで記述されている構造になっていることに注意してください。 これで、Mule オブジェクトから JSON へ、1 つのデータ構造から別のデータ構造へのデータの変換に成功したため、DataWeave 言語でのスクリプト作成を開始し (​[「DataWeave 言語クイックスタート」](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照)、他の​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-components)​および他の​[コネクタおよびモジュール](https://docs.mulesoft.com/connectors/)​について調べる準備ができました。 # チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成 ほとんどのインテグレーションでは、提供元から宛先に移動するときのデータの構造を変更する必要があります。Mule アプリケーション内で、Transform Message コンポーネントのドラッグアンドドロップインターフェースを使用して 1 つの項目または形式から別の項目または形式にデータをマップすることも、DataWeave スクリプト内でマッピングを手動で記述することもできます。通常、Mule アプリケーションは Studio でビルドしますが、Mule アプリケーション設定を XML で手動で記述することもできます。このチュートリアルでは、Studio を使用します。 小さなデータセットと Exchange で使用可能なトレーニング API を使用して、プロジェクトを作成し、API から異なる構造およびプロトコルへの変換マッピングを定義します。ドラッグアンドドロップを使用しますが、変換を定義する ​[DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave)​ コードも示しています。このチュートリアルを完了したら、独自のデータマッピングを作成する準備が整います。 ## [](#前提条件)前提条件 データマッピングワークフローに集中できるように、MuleSoft ではいくつかのセットアップタスクを完了することをお勧めします。 1. Exchange で [\[Training: American Flights API (トレーニング: American Flights API)](https://anypoint.mulesoft.com/exchange/68ef9520-24e9-4cf2-b2f5-620025690913/training-american-flights-api/)\]​ に移動し、\[GET (取得)\] ボタンをクリックして JSON でサンプル応答を表示します。 ![mruntime quickstart json](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-json.png) この構造を変換します。 2. [Anypoint Studio](https://docs.mulesoft.com/studio/to-download-and-install-studio)​ をダウンロードしてインストールします。 3. [Anypoint Platform トライアルアカウント](https://anypoint.mulesoft.com/login/#/signin?apintent=exchange)​がない場合は作成します。 4. Postman や Advanced REST クライアントなどの REST API クライアントを選択します。このチュートリアルでは、Advanced REST クライアントを使用します。 ## [](#ステップ-1-mule-4-プロジェクトを作成する)ステップ 1: Mule 4 プロジェクトを作成する Mule アプリケーションが含まれるプロジェクトを作成します。 1. Anypoint Studio を開き、​**\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ を ​`dw-tutorial4-flights-ws`​ に設定します。 3. その他はすべてデフォルトのままにして、​**\[Finish (完了)\]**​ を選択してプロジェクトを作成します。 完了したら、​**Package Explorer**​ ウィンドウで新しいプロジェクトのコンテンツを確認します。 ![mruntime quickstart package explorer](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-package-explorer.png) ## [](#ステップ-2-mule-4-アプリケーションを作成して設定する)ステップ 2: Mule 4 アプリケーションを作成して設定する 今度は、API からデータを取得するために必要な要素を追加し、DataWeave を使用して異なる構造に変換します。 1. American Flights API をリスンするために HTTP Listener 操作を追加します。\[Mule Palette (Mule パレット)\] で、HTTP 操作を表示するために \[HTTP\] を選択し、Listener 操作をキャンバスまでドラッグします。 ![mruntime quickstart listener](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-listener.png) \[Mule Palette (Mule パレット)\] に何も表示されない場合、Package Explorer で ​`src/main/mule`​ フォルダーのプロジェクトファイル ​`dw-tutorial4-flights-ws.xml`​ を開きます。 2. Listener 操作をダブルクリックしてそのプロパティタブを表示し、緑色のプラス記号をクリックして新しい設定を追加します。 ![mruntime quickstart listener properties](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-listener-properties.png) 3. HTTP Listener 設定ダイアログで、以下の値を追加します。 - **Host (ホスト)**​: `0.0.0.0` - **Port (ポート)**​: `8081` 4. **\[OK\]**​ をクリックしてこれらの変更を保存し、ダイアログを閉じます。 5. Listener の \[General (全般)\] タブで、​**\[Path: (パス:)\]**​ 項目を ​`/flights`​ に変更します。変更は自動的に保存されます。 ![mruntime quickstart path](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-path.png) 6. \[Mule Palette (Mule パレット)\] で、​**\[Add Modules (モジュールを追加)\]**​ を選択してモジュールおよびコネクタのリストを表示し、Database Connector を \[Mule Palette (Mule パレット)\] の左側までドラッグします。バージョンの選択を要求される場合があります。最新バージョンを選択します。 ![mruntime quickstart add db1](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-add-db1.png) 7. Database Connector が \[Mule Palette (Mule パレット)\] に追加され、その操作を表示できるようになります。Select 操作をフローまでドラッグします。 ![mruntime quickstart add db2](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-add-db2.png) 8. MuleSoft サンプル MySQL データベースからの応答をリスンするように Database 操作を設定しましょう。Select オペレーターをクリックしてそのプロパティタブを表示し、追加ボタン (緑色の十字) をクリックして \[Database Config (データベース設定)\] ダイアログを開きます。 9. ダイアログで Mule のサンプルデータベース値を選択または入力します。 - Connection (接続): `MySQL Connection` - **Host (ホスト)**​: `mudb.learn.mulesoft.com` - **Port (ポート)**​: `3306` - **User (ユーザー)**​: `mule` - **Password (パスワード)**​: `mule` - **Database (データベース)**​: `training` ![mruntime quickstart db values](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-db-values.png) 10. \[Database Config (データベース設定)\] ダイアログを表示したまま、​**\[Configure (設定)\] > \[Add Maven dependency (Maven 連動関係を追加)\]**​ を選択します。 11. **\[Pick a Maven dependency (Maven 連動関係を選択)\]**​ ダイアログで、​**\[Search Maven Central (Maven Central を検索)\]**​ 検索項目に ​`mysql-`​ と入力します。 12. 表示された項目から ​`mysql:mysql-connector-java`​ を選択します。 13. **\[Finish (完了)\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 ![mruntime quickstart db driver](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-db-driver.png) 14. **\[Test Connection (接続をテスト)\]**​ を選択します。​`Test connection successful`​ メッセージが表示されます。このメッセージが表示されない場合、前のステップに戻り、エラーを探してください。 15. **\[OK\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 16. Training: American Flights API からのすべてのフライトを返すクエリを作成します。 1. まだ開いていない場合、Select 操作をクリックしてそのプロパティタブを表示します。 2. クエリ項目で select ステートメントを追加します: `SELECT * FROM american`​。変更は自動的に保存されます。 ![mruntime quickstart select query](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-select-query.png) 17. さらに設定をテストするには、プロジェクトを実行します。フローが定義されているキャンバスを右クリックして、​**\[Run Project dw-tutorial4-flights-ws (プロジェクト dw-tutorial4-flights-ws を実行)\]**​ を選択できます。 18. \[Console (コンソール)\] タブを確認し、アプリケーションが実行されたら REST API クライアントを開きます。 19. クライアントで、要求を ​`http://localhost:8081/flights/`​ に送信します。この時点で、アプリケーションは American Flights API に対するクエリから受け取ったデータを処理できないため、​`500 Server Error`​ メッセージを返します。このエラーに対処するため、トレーニングの次のセクションでフローに Transform コンポーネントを追加します。 ![mruntime quickstart object](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-object.png) これでアプリケーションがセットアップされたため、JSON を必要とするサービスでコンシュームできるようにデータを JSON に変換する準備ができました。
アプリケーションで指定されたポートをふさぐ可能性があるオーファンプロセスが誤って作成されるのを防ぐために、Mule アプリケーションは実行されたままにしておいてください。
## [](#ステップ-3-dataweave-データ変換を作成してテストする)ステップ 3: DataWeave データ変換を作成してテストする これで Mule アプリケーションが機能し、Training: American Flights API をリスンするようになたため、Transform Message コンポーネントを追加し、DataWeave のドラッグアンドドロップインターフェースを使用して Mule オブジェクトから JSON への変換を定義します。 1. \[Mule Palette (Mule パレット)\] で \[Core (コア)\] を選択し、\[Transform Message\] コンポーネントを見つけます。 ![mruntime quickstart add transform](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-add-transform.png) 2. \[Transform Message\] をキャンバスの Select 操作の右側までドラッグアンドドロップします。 ![mruntime quickstart canvas](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-canvas.png) 3. \[Transform Message\] コンポーネントをクリックしてグラフィカルビューとソースコードビューを表示します。 ![mruntime quickstart dw blank palette](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-dw-blank-palette.png) - 左側は入力および出力のメタデータ構造のグラフィカルビューです。マッピングは中央の線とノードポイントで表現されます。 - 右側は同じ構造およびマッピングのコードビューです。コードビューとグラフィカルビューでは同期が保たれます。 4. コードビューで、行 2 の出力タイプを ​`application/java`​ から ​`application/json`​ に変更し、行 4 および 5 の括弧を ​`payload`​ に置き換えます。 ![mruntime quickstart dw palette](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-dw-palette.png) 5. 変更内容を保存して、プロジェクトを再デプロイします。 6. REST クライアントで GET 要求を送信し、この変更内容をテストします: `GET http://localhost:8081/flights`​。 ![mruntime quickstart json1](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-json1.png) DataWeave スクリプトの 2 つの単語だけを使用して、Mule オブジェクトを JSON に変換しました。次に、既存のデータを API から提供した例に基づくデータ構造にマップします。この例は、もう 2 つ目のサービスが Training: American Flights API からデータをコンシュームする必要があることを示しています。 7. \[Transform Message\] の \[Output (出力)\] パネルで、​**\[Define metadata (メタデータを定義)\]**​ を選択して ​**\[Select metadata type (メタデータ型を選択)\]**​ ダイアログを開きます。 8. **\[Add (追加)\]**​ を選択して ​**\[Create new type (新しい型を作成)\]**​ ダイアログを開きます。 9. `american_flights_json`​ を入力して ​**\[Create type (型を作成)\]**​ を選択します。 ![mruntime quickstart empty type](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-empty-type.png) 10. **\[Select metadata type (メタデータ型を選択)\]**​ ダイアログで、型を ​**\[JSON\]**​ に設定します。 11. \[Type (型)\] の下のドロップダウンで、​**\[Schema (スキーマ)\]**​ を ​**\[Example (例)\]**​ に変更します。 12. 次の内容をコピーしてファイルに貼り付け、ローカルマシンまたは環境で保存します。ファイルに ​`american-flights-example.json`​ という名前を付けます。 ```json [{ "ID": 1, "code": "ER38sd", "price": 400.00, "departureDate": "2016/03/20", "origin": "MUA", "destination": "SFO", "emptySeats": 0, "plane": { "type": "Boeing 737", "totalSeats": 150 } }, { "ID": 2, "code": "ER45if", "price": 345.99, "departureDate": "2016/02/11", "origin": "MUA", "destination": "LAX", "emptySeats": 52, "plane": { "type": "Boeing 777", "totalSeats": 300 } }] ``` 13. **\[Select metadata type (メタデータ型)\]**​ ダイアログで、3 つのドットのボタンをクリックして作成したばかりのファイルに移動し、選択します。 ![mruntime quickstart json example2](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-json-example2.png) 14. **\[Select (選択)\]**​ を選択して変更内容を保存します。入力および出力のデータ構造が DataWeave インターフェースに表示されます。 ![mruntime quickstart input output](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-input-output.png) 15. 項目のマッピングを開始して変換を作成しましょう。 - 入力セクションから出力セクションまでドラッグして、同じ名前の項目をマップします。 - `ID` - `price` - `totalSeats` ドラッグアンドドロップすると、DataWeave コードが一番右側のペインで記述されます。 ![mruntime quickstart same name](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-same-name.png) - 残りのデータをマップします。 - `toAirport`​ から ​`destination` - `takeOffDate`​ から ​`departureDate` - `fromAirport`​ から ​`origin` - `seatsAvailable`​ から ​`emptySeats` - `planeType`​ から ​`type` - `code1`​ と ​`code2`​ の両方を ​`code`​ にドラッグします。 変換を作成するために項目をドラッグアンドドロップすると、DataWeave コードが生成されます。入力項目を誤った出力項目にドロップするなど、間違った場合、コードビューでエラーがマークされます。出力項目を右クリックし、​**\[Remove field mapping (項目マッピングを削除)\]**​ を選択してエラーを削除します。 16. サンプルデータを追加して、マッピング結果をプレビューしましょう。(不要であればこのステップはスキップできます)。コードビューで ​**\[Preview (プレビュー)\]**​ を選択し、​**\[Create required sample data to execute preview (プレビューを実行するために必要なサンプルデータを作成)\]**​ リンクをクリックします。 ![mruntime quickstart sample data1](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-sample-data1.png) 17. 入力パネルの ​**\[payload (ペイロード)\]**​ タブで、すべてのクエスチョンマークをデータに置き換えます。これらの値は \[Output (出力)\] パネルにも表示されます。Studio のメインメニューから ​**\[File (ファイル)\] > \[Save All (すべて保存)\]**​ を選択します。 18. 変換の定義が完了したら、テストしましょう。前にお勧めしたとおりに Mule アプリケーションを実行したままにしているとして、REST クライアントを開いて別の要求を API に送信します: `GET http://localhost:8081/flights`​。 ![mruntime quickstart transformed](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-quickstart-transformed.png) データが以前のクエリのように \[Input (入力)\] ペインの構造に従うのではなく、\[Output (出力)\] パネルで記述されている構造になっていることに注意してください。 これで、Mule オブジェクトから JSON へ、1 つのデータ構造から別のデータ構造へのデータの変換に成功したため、DataWeave 言語でのスクリプト作成を開始し (​[「DataWeave 言語クイックスタート」](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照)、他の​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-components)​および他の​[コネクタおよびモジュール](https://docs.mulesoft.com/connectors/)​について調べる準備ができました。 # チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成 ほとんどのインテグレーションでは、提供元から宛先に移動するときのデータの構造を変更する必要があります。Mule アプリケーション内で、Transform Message コンポーネントのドラッグアンドドロップインターフェースを使用して 1 つの項目または形式から別の項目または形式にデータをマップすることも、DataWeave スクリプト内でマッピングを手動で記述することもできます。通常、Mule アプリケーションは Studio でビルドしますが、Mule アプリケーション設定を XML で手動で記述することもできます。このチュートリアルでは、Studio を使用します。 小さなデータセットと Exchange で使用可能なトレーニング API を使用して、プロジェクトを作成し、API から異なる構造およびプロトコルへの変換マッピングを定義します。ドラッグアンドドロップを使用しますが、変換を定義する ​[DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave)​ コードも示しています。このチュートリアルを完了したら、独自のデータマッピングを作成する準備が整います。 ## [](#前提条件)前提条件 データマッピングワークフローに集中できるように、MuleSoft ではいくつかのセットアップタスクを完了することをお勧めします。 1. Exchange で [\[Training: American Flights API (トレーニング: American Flights API)](https://anypoint.mulesoft.com/exchange/68ef9520-24e9-4cf2-b2f5-620025690913/training-american-flights-api/)\]​ に移動し、\[GET (取得)\] ボタンをクリックして JSON でサンプル応答を表示します。 ![データが表示されているテスト環境の JSON 応答の例](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-json.png) この構造を変換します。 2. [Anypoint Studio](https://docs.mulesoft.com/studio/to-download-and-install-studio)​ をダウンロードしてインストールします。 3. [Anypoint Platform トライアルアカウント](https://anypoint.mulesoft.com/login/#/signin?apintent=exchange)​がない場合は作成します。 4. Postman や Advanced REST クライアントなどの REST API クライアントを選択します。このチュートリアルでは、Advanced REST クライアントを使用します。 ## [](#ステップ-1-mule-4-プロジェクトを作成する)ステップ 1: Mule 4 プロジェクトを作成する Mule アプリケーションが含まれるプロジェクトを作成します。 1. Anypoint Studio を開き、​**\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ を ​`dw-tutorial4-flights-ws`​ に設定します。 3. その他はすべてデフォルトのままにして、​**\[Finish (完了)\]**​ を選択してプロジェクトを作成します。 完了したら、​**Package Explorer**​ ウィンドウで新しいプロジェクトのコンテンツを確認します。 ![メイン、テスト、リソースのディレクトリが表示されている Mule プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-package-explorer.png) ## [](#ステップ-2-mule-4-アプリケーションを作成して設定する)ステップ 2: Mule 4 アプリケーションを作成して設定する 今度は、API からデータを取得するために必要な要素を追加し、DataWeave を使用して異なる構造に変換します。 1. American Flights API をリスンするために HTTP Listener 操作を追加します。\[Mule Palette (Mule パレット)\] で、HTTP 操作を表示するために \[HTTP\] を選択し、Listener 操作をキャンバスまでドラッグします。 ![Listener や Transform Message などのコンポーネントが表示されているパレットメニュー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-listener.png) \[Mule Palette (Mule パレット)\] に何も表示されない場合、Package Explorer で ​`src/main/mule`​ フォルダーのプロジェクトファイル ​`dw-tutorial4-flights-ws.xml`​ を開きます。 2. Listener 操作をダブルクリックしてそのプロパティタブを表示し、緑色のプラス記号をクリックして新しい設定を追加します。 ![コネクタ設定に必要な設定が表示されている Mule の Listener 設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-listener-properties.png) 3. HTTP Listener 設定ダイアログで、以下の値を追加します。 - **Host (ホスト)**​: `0.0.0.0` - **Port (ポート)**​: `8081` 4. **\[OK\]**​ をクリックしてこれらの変更を保存し、ダイアログを閉じます。 5. Listener の \[General (全般)\] タブで、​**\[Path: (パス:)\]**​ 項目を ​`/flights`​ に変更します。変更は自動的に保存されます。 ![パスおよびコネクタ設定の設定が表示されている Listener コンポーネントの設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-path.png) 6. \[Mule Palette (Mule パレット)\] で、​**\[Add Modules (モジュールを追加)\]**​ を選択してモジュールおよびコネクタのリストを表示し、Database Connector を \[Mule Palette (Mule パレット)\] の左側までドラッグします。バージョンの選択を要求される場合があります。最新バージョンを選択します。 ![Database、HTTP、APIKit for SOAP などの使用可能なモジュールが表示されている Mule インターフェースのパレットメニュー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-add-db1.png) 7. Database Connector が \[Mule Palette (Mule パレット)\] に追加され、その操作を表示できるようになります。Select 操作をフローまでドラッグします。 ![Listener や Error handling などの要素が表示されている Mule フロー設定インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-add-db2.png) 8. MuleSoft サンプル MySQL データベースからの応答をリスンするように Database 操作を設定しましょう。Select オペレーターをクリックしてそのプロパティタブを表示し、追加ボタン (緑色の十字) をクリックして \[Database Config (データベース設定)\] ダイアログを開きます。 9. ダイアログで Mule のサンプルデータベース値を選択または入力します。 - Connection (接続): `MySQL Connection` - **Host (ホスト)**​: `mudb.learn.mulesoft.com` - **Port (ポート)**​: `3306` - **User (ユーザー)**​: `mule` - **Password (パスワード)**​: `mule` - **Database (データベース)**​: `training` ![ホスト、ポート、ユーザー、データベースの項目が表示されている MySQL 接続のデータベース設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-db-values.png) 10. \[Database Config (データベース設定)\] ダイアログを表示したまま、​**\[Configure (設定)\] > \[Add Maven dependency (Maven 連動関係を追加)\]**​ を選択します。 11. **\[Pick a Maven dependency (Maven 連動関係を選択)\]**​ ダイアログで、​**\[Search Maven Central (Maven Central を検索)\]**​ 検索項目に ​`mysql-`​ と入力します。 12. 表示された項目から ​`mysql:mysql-connector-java`​ を選択します。 13. **\[Finish (完了)\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 ![MySQL 接続設定と必要な JDBC ドライバー情報が表示されているデータベース設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-db-driver.png) 14. **\[Test Connection (接続をテスト)\]**​ を選択します。​`Test connection successful`​ メッセージが表示されます。このメッセージが表示されない場合、前のステップに戻り、エラーを探してください。 15. **\[OK\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 16. Training: American Flights API からのすべてのフライトを返すクエリを作成します。 1. まだ開いていない場合、Select 操作をクリックしてそのプロパティタブを表示します。 2. クエリ項目で select ステートメントを追加します: `SELECT * FROM american`​。変更は自動的に保存されます。 ![SQL テキストが表示されているデータベースクエリセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-select-query.png) 17. さらに設定をテストするには、プロジェクトを実行します。フローが定義されているキャンバスを右クリックして、​**\[Run Project dw-tutorial4-flights-ws (プロジェクト dw-tutorial4-flights-ws を実行)\]**​ を選択できます。 18. \[Console (コンソール)\] タブを確認し、アプリケーションが実行されたら REST API クライアントを開きます。 19. クライアントで、要求を ​`http://localhost:8081/flights/`​ に送信します。この時点で、アプリケーションは American Flights API に対するクエリから受け取ったデータを処理できないため、​`500 Server Error`​ メッセージを返します。このエラーに対処するため、トレーニングの次のセクションでフローに Transform コンポーネントを追加します。 ![変換プロセスのサポートされていないソース種別に起因するサーバーエラーを示すエラーメッセージ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-object.png) これでアプリケーションがセットアップされたため、JSON を必要とするサービスでコンシュームできるようにデータを JSON に変換する準備ができました。
アプリケーションで指定されたポートをふさぐ可能性があるオーファンプロセスが誤って作成されるのを防ぐために、Mule アプリケーションは実行されたままにしておいてください。
## [](#ステップ-3-dataweave-データ変換を作成してテストする)ステップ 3: DataWeave データ変換を作成してテストする これで Mule アプリケーションが機能し、Training: American Flights API をリスンするようになたため、Transform Message コンポーネントを追加し、DataWeave のドラッグアンドドロップインターフェースを使用して Mule オブジェクトから JSON への変換を定義します。 1. \[Mule Palette (Mule パレット)\] で \[Core (コア)\] を選択し、\[Transform Message\] コンポーネントを見つけます。 ![Database、HTTP、Batch などのコンポーネントが表示されているパレットメニュー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-add-transform.png) 2. \[Transform Message\] をキャンバスの Select 操作の右側までドラッグアンドドロップします。 ![Listener や Transform Message などのフライトサービスワークフローのコンポーネントが表示されている Mule のビジュアルエディター](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-canvas.png) 3. \[Transform Message\] コンポーネントをクリックしてグラフィカルビューとソースコードビューを表示します。 ![入力および出力メタデータを定義するオプションが表示されている空のデータ変換インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-dw-blank-palette.png) - 左側は入力および出力のメタデータ構造のグラフィカルビューです。マッピングは中央の線とノードポイントで表現されます。 - 右側は同じ構造およびマッピングのコードビューです。コードビューとグラフィカルビューでは同期が保たれます。 4. コードビューで、行 2 の出力タイプを ​`application/java`​ から ​`application/json`​ に変更し、行 4 および 5 の括弧を ​`payload`​ に置き換えます。 ![JSON 出力構造を定義する項目が表示されている DataWeave 変換インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-dw-palette.png) 5. 変更内容を保存して、プロジェクトを再デプロイします。 6. REST クライアントで GET 要求を送信し、この変更内容をテストします: `GET http://localhost:8081/flights`​。 ![メソッド、URL、ヘッダーが表示されている HTTP 要求セットアップ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-json1.png) DataWeave スクリプトの 2 つの単語だけを使用して、Mule オブジェクトを JSON に変換しました。次に、既存のデータを API から提供した例に基づくデータ構造にマップします。この例は、もう 2 つ目のサービスが Training: American Flights API からデータをコンシュームする必要があることを示しています。 7. \[Transform Message\] の \[Output (出力)\] パネルで、​**\[Define metadata (メタデータを定義)\]**​ を選択して ​**\[Select metadata type (メタデータ型を選択)\]**​ ダイアログを開きます。 8. **\[Add (追加)\]**​ を選択して ​**\[Create new type (新しい型を作成)\]**​ ダイアログを開きます。 9. `american_flights_json`​ を入力して ​**\[Create type (型を作成)\]**​ を選択します。 ![単純型とユーザー定義型のオプションが表示されている、メタデータ型を選択するためのインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-empty-type.png) 10. **\[Select metadata type (メタデータ型を選択)\]**​ ダイアログで、型を ​**\[JSON\]**​ に設定します。 11. \[Type (型)\] の下のドロップダウンで、​**\[Schema (スキーマ)\]**​ を ​**\[Example (例)\]**​ に変更します。 12. 次の内容をコピーしてファイルに貼り付け、ローカルマシンまたは環境で保存します。ファイルに ​`american-flights-example.json`​ という名前を付けます。 ```json [{ "ID": 1, "code": "ER38sd", "price": 400.00, "departureDate": "2016/03/20", "origin": "MUA", "destination": "SFO", "emptySeats": 0, "plane": { "type": "Boeing 737", "totalSeats": 150 } }, { "ID": 2, "code": "ER45if", "price": 345.99, "departureDate": "2016/02/11", "origin": "MUA", "destination": "LAX", "emptySeats": 52, "plane": { "type": "Boeing 777", "totalSeats": 300 } }] ``` 13. **\[Select metadata type (メタデータ型)\]**​ ダイアログで、3 つのドットのボタンをクリックして作成したばかりのファイルに移動し、選択します。 ![JSON 型とユーザー定義型のオプションが表示されている、メタデータ型を選択するためのダイアログボックス](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-json-example2.png) 14. **\[Select (選択)\]**​ を選択して変更内容を保存します。入力および出力のデータ構造が DataWeave インターフェースに表示されます。 ![入力構造と出力構造がある変換セットアップが表示されている DataWeave エディター](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-input-output.png) 15. 項目のマッピングを開始して変換を作成しましょう。 - 入力セクションから出力セクションまでドラッグして、同じ名前の項目をマップします。 - `ID` - `price` - `totalSeats` ドラッグアンドドロップすると、DataWeave コードが一番右側のペインで記述されます。 ![\[ID\] や \[code (コード)\] などの項目が含まれる JSON 形式への変換データが表示されている DataWeave エディター](_images/mruntime-quickstart-same-name.png) - 残りのデータをマップします。 - `toAirport`​ から ​`destination` - `takeOffDate`​ から ​`departureDate` - `fromAirport`​ から ​`origin` - `seatsAvailable`​ から ​`emptySeats` - `planeType`​ から ​`type` - `code1`​ と ​`code2`​ の両方を ​`code`​ にドラッグします。 変換を作成するために項目をドラッグアンドドロップすると、DataWeave コードが生成されます。入力項目を誤った出力項目にドロップするなど、間違った場合、コードビューでエラーがマークされます。出力項目を右クリックし、​**\[Remove field mapping (項目マッピングを削除)\]**​ を選択してエラーを削除します。 16. サンプルデータを追加して、マッピング結果をプレビューしましょう。(不要であればこのステップはスキップできます)。コードビューで ​**\[Preview (プレビュー)\]**​ を選択し、​**\[Create required sample data to execute preview (プレビューを実行するために必要なサンプルデータを作成)\]**​ リンクをクリックします。 ![\[ID\] や \[code (コード)\] などの項目のマッピングが表示されている DataWeave スクリプト](_images/mruntime-quickstart-sample-data1.png) 17. 入力パネルの ​**\[payload (ペイロード)\]**​ タブで、すべてのクエスチョンマークをデータに置き換えます。これらの値は \[Output (出力)\] パネルにも表示されます。Studio のメインメニューから ​**\[File (ファイル)\] > \[Save All (すべて保存)\]**​ を選択します。 18. 変換の定義が完了したら、テストしましょう。前にお勧めしたとおりに Mule アプリケーションを実行したままにしているとして、REST クライアントを開いて別の要求を API に送信します: `GET http://localhost:8081/flights`​。 ![成功した GET 要求と応答の詳細](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-quickstart-transformed.png) データが以前のクエリのように \[Input (入力)\] ペインの構造に従うのではなく、\[Output (出力)\] パネルで記述されている構造になっていることに注意してください。 これで、Mule オブジェクトから JSON へ、1 つのデータ構造から別のデータ構造へのデータの変換に成功したため、DataWeave 言語でのスクリプト作成を開始し (​[「DataWeave 言語クイックスタート」](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照)、他の​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-components)​および他の​[コネクタおよびモジュール](https://docs.mulesoft.com/connectors/)​について調べる準備ができました。 # チュートリアル: Database Connector と DataWeave を使用する Mule アプリケーションの作成 ほとんどのインテグレーションでは、提供元から宛先に移動するときのデータの構造を変更する必要があります。Mule アプリケーション内で、Transform Message コンポーネントのドラッグアンドドロップインターフェースを使用して 1 つの項目または形式から別の項目または形式にデータをマップすることも、DataWeave スクリプト内でマッピングを手動で記述することもできます。通常、Mule アプリケーションは Studio でビルドしますが、Mule アプリケーション設定を XML で手動で記述することもできます。このチュートリアルでは、Studio を使用します。 小さなデータセットと Exchange で使用可能なトレーニング API を使用して、プロジェクトを作成し、API から異なる構造およびプロトコルへの変換マッピングを定義します。ドラッグアンドドロップを使用しますが、変換を定義する ​[DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave)​ コードも示しています。このチュートリアルを完了したら、独自のデータマッピングを作成する準備が整います。 ## [](#前提条件)前提条件 データマッピングワークフローに集中できるように、MuleSoft ではいくつかのセットアップタスクを完了することをお勧めします。 1. Exchange で [\[Training: American Flights API (トレーニング: American Flights API)](https://anypoint.mulesoft.com/exchange/68ef9520-24e9-4cf2-b2f5-620025690913/training-american-flights-api/)\]​ に移動し、\[GET (取得)\] ボタンをクリックして JSON でサンプル応答を表示します。 ![データが表示されているテスト環境の JSON 応答の例](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-json.png) この構造を変換します。 2. [Anypoint Studio](https://docs.mulesoft.com/studio/to-download-and-install-studio)​ をダウンロードしてインストールします。 3. [Anypoint Platform トライアルアカウント](https://anypoint.mulesoft.com/login/#/signin?apintent=exchange)​がない場合は作成します。 4. Postman や Advanced REST クライアントなどの REST API クライアントを選択します。このチュートリアルでは、Advanced REST クライアントを使用します。 ## [](#ステップ-1-mule-4-プロジェクトを作成する)ステップ 1: Mule 4 プロジェクトを作成する Mule アプリケーションが含まれるプロジェクトを作成します。 1. Anypoint Studio を開き、​**\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 2. **\[Project Name (プロジェクト名)\]**​ を ​`dw-tutorial4-flights-ws`​ に設定します。 3. その他はすべてデフォルトのままにして、​**\[Finish (完了)\]**​ を選択してプロジェクトを作成します。 完了したら、​**Package Explorer**​ ウィンドウで新しいプロジェクトのコンテンツを確認します。 ![メイン、テスト、リソースのディレクトリが表示されている Mule プロジェクト](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-package-explorer.png) ## [](#ステップ-2-mule-4-アプリケーションを作成して設定する)ステップ 2: Mule 4 アプリケーションを作成して設定する 今度は、API からデータを取得するために必要な要素を追加し、DataWeave を使用して異なる構造に変換します。 1. American Flights API をリスンするために HTTP Listener 操作を追加します。\[Mule Palette (Mule パレット)\] で、HTTP 操作を表示するために \[HTTP\] を選択し、Listener 操作をキャンバスまでドラッグします。 ![Listener や Transform Message などのコンポーネントが表示されているパレットメニュー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-listener.png) \[Mule Palette (Mule パレット)\] に何も表示されない場合、Package Explorer で ​`src/main/mule`​ フォルダーのプロジェクトファイル ​`dw-tutorial4-flights-ws.xml`​ を開きます。 2. Listener 操作をダブルクリックしてそのプロパティタブを表示し、緑色のプラス記号をクリックして新しい設定を追加します。 ![コネクタ設定に必要な設定が表示されている Mule の Listener 設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-listener-properties.png) 3. HTTP Listener 設定ダイアログで、以下の値を追加します。 - **Host (ホスト)**​: `0.0.0.0` - **Port (ポート)**​: `8081` 4. **\[OK\]**​ をクリックしてこれらの変更を保存し、ダイアログを閉じます。 5. Listener の \[General (全般)\] タブで、​**\[Path: (パス:)\]**​ 項目を ​`/flights`​ に変更します。変更は自動的に保存されます。 ![パスおよびコネクタ設定の設定が表示されている Listener コンポーネントの設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-path.png) 6. \[Mule Palette (Mule パレット)\] で、​**\[Add Modules (モジュールを追加)\]**​ を選択してモジュールおよびコネクタのリストを表示し、Database Connector を \[Mule Palette (Mule パレット)\] の左側までドラッグします。バージョンの選択を要求される場合があります。最新バージョンを選択します。 ![Database、HTTP、APIKit for SOAP などの使用可能なモジュールが表示されている Mule インターフェースのパレットメニュー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-add-db1.png) 7. Database Connector が \[Mule Palette (Mule パレット)\] に追加され、その操作を表示できるようになります。Select 操作をフローまでドラッグします。 ![Listener や Error handling などの要素が表示されている Mule フロー設定インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-add-db2.png) 8. MuleSoft サンプル MySQL データベースからの応答をリスンするように Database 操作を設定しましょう。Select オペレーターをクリックしてそのプロパティタブを表示し、追加ボタン (緑色の十字) をクリックして \[Database Config (データベース設定)\] ダイアログを開きます。 9. ダイアログで Mule のサンプルデータベース値を選択または入力します。 - Connection (接続): `MySQL Connection` - **Host (ホスト)**​: `mudb.learn.mulesoft.com` - **Port (ポート)**​: `3306` - **User (ユーザー)**​: `mule` - **Password (パスワード)**​: `mule` - **Database (データベース)**​: `training` ![ホスト、ポート、ユーザー、データベースの項目が表示されている MySQL 接続のデータベース設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-db-values.png) 10. \[Database Config (データベース設定)\] ダイアログを表示したまま、​**\[Configure (設定)\] > \[Add Maven dependency (Maven 連動関係を追加)\]**​ を選択します。 11. **\[Pick a Maven dependency (Maven 連動関係を選択)\]**​ ダイアログで、​**\[Search Maven Central (Maven Central を検索)\]**​ 検索項目に ​`mysql-`​ と入力します。 12. 表示された項目から ​`mysql:mysql-connector-java`​ を選択します。 13. **\[Finish (完了)\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 ![MySQL 接続設定と必要な JDBC ドライバー情報が表示されているデータベース設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-db-driver.png) 14. **\[Test Connection (接続をテスト)\]**​ を選択します。​`Test connection successful`​ メッセージが表示されます。このメッセージが表示されない場合、前のステップに戻り、エラーを探してください。 15. **\[OK\]**​ を選択して \[Database Config (データベース設定)\] ダイアログに戻ります。 16. Training: American Flights API からのすべてのフライトを返すクエリを作成します。 1. まだ開いていない場合、Select 操作をクリックしてそのプロパティタブを表示します。 2. クエリ項目で select ステートメントを追加します: `SELECT * FROM american`​。変更は自動的に保存されます。 ![SQL テキストが表示されているデータベースクエリセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-select-query.png) 17. さらに設定をテストするには、プロジェクトを実行します。フローが定義されているキャンバスを右クリックして、​**\[Run Project dw-tutorial4-flights-ws (プロジェクト dw-tutorial4-flights-ws を実行)\]**​ を選択できます。 18. \[Console (コンソール)\] タブを確認し、アプリケーションが実行されたら REST API クライアントを開きます。 19. クライアントで、要求を ​`http://localhost:8081/flights/`​ に送信します。この時点で、アプリケーションは American Flights API に対するクエリから受け取ったデータを処理できないため、​`500 Server Error`​ メッセージを返します。このエラーに対処するため、トレーニングの次のセクションでフローに Transform コンポーネントを追加します。 ![変換プロセスのサポートされていないソース種別に起因するサーバーエラーを示すエラーメッセージ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-object.png) これでアプリケーションがセットアップされたため、JSON を必要とするサービスでコンシュームできるようにデータを JSON に変換する準備ができました。
アプリケーションで指定されたポートをふさぐ可能性があるオーファンプロセスが誤って作成されるのを防ぐために、Mule アプリケーションは実行されたままにしておいてください。
## [](#ステップ-3-dataweave-データ変換を作成してテストする)ステップ 3: DataWeave データ変換を作成してテストする これで Mule アプリケーションが機能し、Training: American Flights API をリスンするようになたため、Transform Message コンポーネントを追加し、DataWeave のドラッグアンドドロップインターフェースを使用して Mule オブジェクトから JSON への変換を定義します。 1. \[Mule Palette (Mule パレット)\] で \[Core (コア)\] を選択し、\[Transform Message\] コンポーネントを見つけます。 ![Database、HTTP、Batch などのコンポーネントが表示されているパレットメニュー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-add-transform.png) 2. \[Transform Message\] をキャンバスの Select 操作の右側までドラッグアンドドロップします。 ![Listener や Transform Message などのフライトサービスワークフローのコンポーネントが表示されている Mule のビジュアルエディター](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-canvas.png) 3. \[Transform Message\] コンポーネントをクリックしてグラフィカルビューとソースコードビューを表示します。 ![入力および出力メタデータを定義するオプションが表示されている空のデータ変換インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-dw-blank-palette.png) - 左側は入力および出力のメタデータ構造のグラフィカルビューです。マッピングは中央の線とノードポイントで表現されます。 - 右側は同じ構造およびマッピングのコードビューです。コードビューとグラフィカルビューでは同期が保たれます。 4. コードビューで、行 2 の出力タイプを ​`application/java`​ から ​`application/json`​ に変更し、行 4 および 5 の括弧を ​`payload`​ に置き換えます。 ![JSON 出力構造を定義する項目が表示されている DataWeave 変換インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-dw-palette.png) 5. 変更内容を保存して、プロジェクトを再デプロイします。 6. REST クライアントで GET 要求を送信し、この変更内容をテストします: `GET http://localhost:8081/flights`​。 ![メソッド、URL、ヘッダーが表示されている HTTP 要求セットアップ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-json1.png) DataWeave スクリプトの 2 つの単語だけを使用して、Mule オブジェクトを JSON に変換しました。次に、既存のデータを API から提供した例に基づくデータ構造にマップします。この例は、もう 2 つ目のサービスが Training: American Flights API からデータをコンシュームする必要があることを示しています。 7. \[Transform Message\] の \[Output (出力)\] パネルで、​**\[Define metadata (メタデータを定義)\]**​ を選択して ​**\[Select metadata type (メタデータ型を選択)\]**​ ダイアログを開きます。 8. **\[Add (追加)\]**​ を選択して ​**\[Create new type (新しい型を作成)\]**​ ダイアログを開きます。 9. `american_flights_json`​ を入力して ​**\[Create type (型を作成)\]**​ を選択します。 ![単純型とユーザー定義型のオプションが表示されている、メタデータ型を選択するためのインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-empty-type.png) 10. **\[Select metadata type (メタデータ型を選択)\]**​ ダイアログで、型を ​**\[JSON\]**​ に設定します。 11. \[Type (型)\] の下のドロップダウンで、​**\[Schema (スキーマ)\]**​ を ​**\[Example (例)\]**​ に変更します。 12. 次の内容をコピーしてファイルに貼り付け、ローカルマシンまたは環境で保存します。ファイルに ​`american-flights-example.json`​ という名前を付けます。 ```json [{ "ID": 1, "code": "ER38sd", "price": 400.00, "departureDate": "2016/03/20", "origin": "MUA", "destination": "SFO", "emptySeats": 0, "plane": { "type": "Boeing 737", "totalSeats": 150 } }, { "ID": 2, "code": "ER45if", "price": 345.99, "departureDate": "2016/02/11", "origin": "MUA", "destination": "LAX", "emptySeats": 52, "plane": { "type": "Boeing 777", "totalSeats": 300 } }] ``` 13. **\[Select metadata type (メタデータ型)\]**​ ダイアログで、3 つのドットのボタンをクリックして作成したばかりのファイルに移動し、選択します。 ![JSON 型とユーザー定義型のオプションが表示されている、メタデータ型を選択するためのダイアログボックス](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-json-example2.png) 14. **\[Select (選択)\]**​ を選択して変更内容を保存します。入力および出力のデータ構造が DataWeave インターフェースに表示されます。 ![入力構造と出力構造がある変換セットアップが表示されている DataWeave エディター](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-input-output.png) 15. 項目のマッピングを開始して変換を作成しましょう。 - 入力セクションから出力セクションまでドラッグして、同じ名前の項目をマップします。 - `ID` - `price` - `totalSeats` ドラッグアンドドロップすると、DataWeave コードが一番右側のペインで記述されます。 ![\[ID\] や \[code (コード)\] などの項目が含まれる JSON 形式への変換データが表示されている DataWeave エディター](_images/mruntime-quickstart-same-name.png) - 残りのデータをマップします。 - `toAirport`​ から ​`destination` - `takeOffDate`​ から ​`departureDate` - `fromAirport`​ から ​`origin` - `seatsAvailable`​ から ​`emptySeats` - `planeType`​ から ​`type` - `code1`​ と ​`code2`​ の両方を ​`code`​ にドラッグします。 変換を作成するために項目をドラッグアンドドロップすると、DataWeave コードが生成されます。入力項目を誤った出力項目にドロップするなど、間違った場合、コードビューでエラーがマークされます。出力項目を右クリックし、​**\[Remove field mapping (項目マッピングを削除)\]**​ を選択してエラーを削除します。 16. サンプルデータを追加して、マッピング結果をプレビューしましょう。(不要であればこのステップはスキップできます)。コードビューで ​**\[Preview (プレビュー)\]**​ を選択し、​**\[Create required sample data to execute preview (プレビューを実行するために必要なサンプルデータを作成)\]**​ リンクをクリックします。 ![\[ID\] や \[code (コード)\] などの項目のマッピングが表示されている DataWeave スクリプト](_images/mruntime-quickstart-sample-data1.png) 17. 入力パネルの ​**\[payload (ペイロード)\]**​ タブで、すべてのクエスチョンマークをデータに置き換えます。これらの値は \[Output (出力)\] パネルにも表示されます。Studio のメインメニューから ​**\[File (ファイル)\] > \[Save All (すべて保存)\]**​ を選択します。 18. 変換の定義が完了したら、テストしましょう。前にお勧めしたとおりに Mule アプリケーションを実行したままにしているとして、REST クライアントを開いて別の要求を API に送信します: `GET http://localhost:8081/flights`​。 ![成功した GET 要求と応答の詳細](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-quickstart-transformed.png) データが以前のクエリのように \[Input (入力)\] ペインの構造に従うのではなく、\[Output (出力)\] パネルで記述されている構造になっていることに注意してください。 これで、Mule オブジェクトから JSON へ、1 つのデータ構造から別のデータ構造へのデータの変換に成功したため、DataWeave 言語でのスクリプト作成を開始し (​[「DataWeave 言語クイックスタート」](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​を参照)、他の​[コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-components)​および他の​[コネクタおよびモジュール](https://docs.mulesoft.com/connectors/)​について調べる準備ができました。 # チューニングの推奨事項 Mule 4 は、Mule Runtime Engine (Mule) をデプロイした環境の動作条件に従って自己チューニングを行い、自身を最適なパフォーマンスに調整します。 自己チューニングにより、Mule の内部処理ではなく自分のアプリケーションに集中できるため、最適化プロセスが容易になります。また、Mule は出荷時に最も一般的なユースケースに合わせて最適なパフォーマンスにチューニングされていますので、パラメーターの変更は、それによる影響を完全に理解している場合にのみ行ってください。 以下に、アプリケーションレベルで適用することで特定のユースケースにおいて有効なチューニングの推奨事項を紹介します。 ## [](#反復可能ストリームと反復不可能ストリーム)反復可能ストリームと反復不可能ストリーム 自分のユースケースで最適なフローパフォーマンスを実現するストリーミング戦略を理解してください。 - 反復可能ストリーム (ペイロードを複数回読み取る) - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) 詳細は、​[「反復可能ストリームと反復不可能ストリーム」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-repeatable-nonrepeatable)​を参照してください。 ## [](#back-pressure-と-maxconcurrency)back-pressure と maxConcurrency バックプレッシャーと ​`maxConcurrency`​ パラメーターの使い方を理解して、フローに送信される同時メッセージ数をチューニングします。 詳細は、​[「back-pressure と maxConcurrency」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-backpressure-maxconcurrency)​を参照してください。 ## [](#バックエンドサーバーの応答時間)バックエンドサーバーの応答時間 バックエンドサーバーの平均レイテンシーとスループットによってアプリケーションの拡張性やパフォーマンスが制限されていないかを確認します。 詳細は、​[「バックエンドサーバーの応答時間」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-backend-server)​を参照してください。 ## [](#キャッシュ)キャッシュ データの主要な側面に基づいて、キャッシュするタイミングや使用するキャッシュ戦略を決定します。Mule では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能なメカニズムによってニーズに合わせたキャッシュ処理を実現できます。 詳細は​[「キャッシュ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-caching)​を参照してください。 ## [](#プーリングプロファイル)プーリングプロファイル コンポーネントをプールすることで、同時に受信する要求を効率よく処理できます。パフォーマンステストで必要だと判明した場合には、​`pooling-profile`​ をコネクタに追加してください。 詳細は、​[「プーリングプロファイル」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-pooling-profiles)​を参照してください。 ## [](#ドメイン)ドメイン ドメインを使用することで、すべての共有リソースの中央リポジトリが用意され、クラスローディングプロセスが容易になります。同じオンプレミスの Mule Runtime Engine インスタンスに複数のサービスをデプロイする場合には、ドメインによってパフォーマンスが向上します。 詳細は​[「ドメイン」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-domains)​を参照してください。 ## [](#ログ記録)ログ記録 非同期ログのほうが同期ログよりパフォーマンスが高い理由を理解してください。 詳細は​[「ログ記録」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-logging)​を参照してください。 ## [](#バッチ処理)バッチ処理 Mule はメッセージをバッチ処理できますが、バッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。アプリケーションに合わせたバッチブロックサイズプロパティを設定する方法を理解してください。 詳細は​[「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-batch-processing)​を参照してください。 ## [](#アプリケーション設計のベストプラクティス)アプリケーション設計のベストプラクティス 設計フェーズで特定のプラクティスに従うことにより、Mule アプリケーションのパフォーマンスを高めることができます。 詳細は​[「アプリケーションの設計」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-app-design)​を参照してください。 ## [](#関連情報)関連情報 - [パフォーマンスチューニングガイド](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-guide) # チューニングの推奨事項 Mule 4 は、Mule Runtime Engine (Mule) をデプロイした環境の動作条件に従って自己チューニングを行い、自身を最適なパフォーマンスに調整します。 自己チューニングにより、Mule の内部処理ではなく自分のアプリケーションに集中できるため、最適化プロセスが容易になります。また、Mule は出荷時に最も一般的なユースケースに合わせて最適なパフォーマンスにチューニングされていますので、パラメーターの変更は、それによる影響を完全に理解している場合にのみ行ってください。 以下に、アプリケーションレベルで適用することで特定のユースケースにおいて有効なチューニングの推奨事項を紹介します。 ## [](#反復可能ストリームと反復不可能ストリーム)反復可能ストリームと反復不可能ストリーム 自分のユースケースで最適なフローパフォーマンスを実現するストリーミング戦略を理解してください。 - 反復可能ストリーム (ペイロードを複数回読み取る) - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) 詳細は、​[「反復可能ストリームと反復不可能ストリーム」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-repeatable-nonrepeatable)​を参照してください。 ## [](#back-pressure-と-maxconcurrency)back-pressure と maxConcurrency バックプレッシャーと ​`maxConcurrency`​ パラメーターの使い方を理解して、フローに送信される同時メッセージ数をチューニングします。 詳細は、​[「back-pressure と maxConcurrency」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-backpressure-maxconcurrency)​を参照してください。 ## [](#バックエンドサーバーの応答時間)バックエンドサーバーの応答時間 バックエンドサーバーの平均レイテンシーとスループットによってアプリケーションの拡張性やパフォーマンスが制限されていないかを確認します。 詳細は、​[「バックエンドサーバーの応答時間」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-backend-server)​を参照してください。 ## [](#キャッシュ)キャッシュ データの主要な側面に基づいて、キャッシュするタイミングや使用するキャッシュ戦略を決定します。Mule では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能なメカニズムによってニーズに合わせたキャッシュ処理を実現できます。 詳細は​[「キャッシュ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-caching)​を参照してください。 ## [](#プーリングプロファイル)プーリングプロファイル コンポーネントをプールすることで、同時に受信する要求を効率よく処理できます。パフォーマンステストで必要だと判明した場合には、​`pooling-profile`​ をコネクタに追加してください。 詳細は、​[「プーリングプロファイル」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-pooling-profiles)​を参照してください。 ## [](#ドメイン)ドメイン ドメインを使用することで、すべての共有リソースの中央リポジトリが用意され、クラスローディングプロセスが容易になります。同じオンプレミスの Mule Runtime Engine インスタンスに複数のサービスをデプロイする場合には、ドメインによってパフォーマンスが向上します。 詳細は​[「ドメイン」](#tuning-domains.adoc)​を参照してください。 ## [](#ログ記録)ログ記録 非同期ログのほうが同期ログよりパフォーマンスが高い理由を理解してください。 詳細は​[「ログ記録」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-logging)​を参照してください。 ## [](#バッチ処理)バッチ処理 Mule はメッセージをバッチ処理できますが、バッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。アプリケーションに合わせたバッチブロックサイズプロパティを設定する方法を理解してください。 詳細は​[「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-batch-processing)​を参照してください。 ## [](#アプリケーション設計のベストプラクティス)アプリケーション設計のベストプラクティス 設計フェーズで特定のプラクティスに従うことにより、Mule アプリケーションのパフォーマンスを高めることができます。 詳細は​[「アプリケーションの設計」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-app-design)​を参照してください。 ## [](#関連情報)関連情報 - [パフォーマンスチューニングガイド](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-guide) # チューニングの推奨事項 Mule 4 は、Mule Runtime Engine (Mule) をデプロイした環境の動作条件に従って自己チューニングを行い、自身を最適なパフォーマンスに調整します。 自己チューニングにより、Mule の内部処理ではなく自分のアプリケーションに集中できるため、最適化プロセスが容易になります。また、Mule は出荷時に最も一般的な使用事例に合わせて最適なパフォーマンスにチューニングされていますので、パラメーターの変更は、それによる影響を完全に理解している場合にのみ行ってください。 以下に、アプリケーションレベルで適用することで特定の使用事例において有効なチューニングの推奨事項を紹介します。 ## [](#反復可能ストリームと反復不可能ストリーム)反復可能ストリームと反復不可能ストリーム 自分の使用事例で最適なフローパフォーマンスを実現するストリーミング戦略を理解してください。 - 反復可能ストリーム (ペイロードを複数回読み取る) - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) 詳細は、​[「反復可能ストリームと反復不可能ストリーム」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-repeatable-nonrepeatable)​を参照してください。 ## [](#back-pressure-と-maxconcurrency)back-pressure と maxConcurrency バックプレッシャーと ​`maxConcurrency`​ パラメーターの使い方を理解して、フローに送信される同時メッセージ数をチューニングします。 詳細は、​[「back-pressure と maxConcurrency」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-backpressure-maxconcurrency)​を参照してください。 ## [](#バックエンドサーバーの応答時間)バックエンドサーバーの応答時間 バックエンドサーバーの平均レイテンシーとスループットによってアプリケーションの拡張性やパフォーマンスが制限されていないかを確認します。 詳細は、​[「バックエンドサーバーの応答時間」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-backend-server)​を参照してください。 ## [](#キャッシュ)キャッシュ データの主要な側面に基づいて、キャッシュするタイミングや使用するキャッシュ戦略を決定します。Mule では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能なメカニズムによってニーズに合わせたキャッシュ処理を実現できます。 詳細は​[「キャッシュ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-caching)​を参照してください。 ## [](#プーリングプロファイル)プーリングプロファイル コンポーネントをプールすることで、同時に受信する要求を効率よく処理できます。パフォーマンステストで必要だと判明した場合には、​`pooling-profile`​ をコネクタに追加してください。 詳細は、​[「プーリングプロファイル」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-pooling-profiles)​を参照してください。 ## [](#ドメイン)ドメイン ドメインを使用することで、すべての共有リソースの中央リポジトリが用意され、クラスローディングプロセスが容易になります。同じオンプレミスの Mule Runtime Engine インスタンスに複数のサービスをデプロイする場合には、ドメインによってパフォーマンスが向上します。 詳細は​[「ドメイン」](#tuning-domains.adoc)​を参照してください。 ## [](#ログ)ログ 非同期ログのほうが同期ログよりパフォーマンスが高い理由を理解してください。 詳細は​[「ログ記録」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-logging)​を参照してください。 ## [](#バッチ処理)バッチ処理 Mule はメッセージをバッチ処理できますが、バッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。アプリケーションに合わせたバッチブロックサイズプロパティを設定する方法を理解してください。 詳細は​[「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-batch-processing)​を参照してください。 ## [](#アプリケーション設計のベストプラクティス)アプリケーション設計のベストプラクティス 設計フェーズで特定のプラクティスに従うことにより、Mule アプリケーションのパフォーマンスを高めることができます。 詳細は​[「アプリケーションの設計」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-app-design)​を参照してください。 ## [](#関連情報)関連情報 - [パフォーマンスチューニングガイド](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-guide) # チューニングの推奨事項 Mule 4 は、Mule Runtime Engine (Mule) をデプロイした環境の動作条件に従って自己チューニングを行い、自身を最適なパフォーマンスに調整します。 自己チューニングにより、Mule の内部処理ではなく自分のアプリケーションに集中できるため、最適化プロセスが容易になります。また、Mule は出荷時に最も一般的なユースケースに合わせて最適なパフォーマンスにチューニングされていますので、パラメーターの変更は、それによる影響を完全に理解している場合にのみ行ってください。 以下に、アプリケーションレベルで適用することで特定のユースケースにおいて有効なチューニングの推奨事項を紹介します。 ## [](#反復可能ストリームと反復不可能ストリーム)反復可能ストリームと反復不可能ストリーム 自分のユースケースで最適なフローパフォーマンスを実現するストリーミング戦略を理解してください。 - 反復可能ストリーム (ペイロードを複数回読み取る) - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) 詳細は、​[「反復可能ストリームと反復不可能ストリーム」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-repeatable-nonrepeatable)​を参照してください。 ## [](#back-pressure-と-maxconcurrency)back-pressure と maxConcurrency バックプレッシャーと ​`maxConcurrency`​ パラメーターの使い方を理解して、フローに送信される同時メッセージ数をチューニングします。 詳細は、​[「back-pressure と maxConcurrency」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-backpressure-maxconcurrency)​を参照してください。 ## [](#バックエンドサーバーの応答時間)バックエンドサーバーの応答時間 バックエンドサーバーの平均レイテンシーとスループットによってアプリケーションの拡張性やパフォーマンスが制限されていないかを確認します。 詳細は、​[「バックエンドサーバーの応答時間」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-backend-server)​を参照してください。 ## [](#キャッシュ)キャッシュ データの主要な側面に基づいて、キャッシュするタイミングや使用するキャッシュ戦略を決定します。Mule では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能なメカニズムによってニーズに合わせたキャッシュ処理を実現できます。 詳細は​[「キャッシュ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-caching)​を参照してください。 ## [](#プーリングプロファイル)プーリングプロファイル コンポーネントをプールすることで、同時に受信する要求を効率よく処理できます。パフォーマンステストで必要だと判明した場合には、​`pooling-profile`​ をコネクタに追加してください。 詳細は、​[「プーリングプロファイル」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-pooling-profiles)​を参照してください。 ## [](#ドメイン)ドメイン ドメインを使用することで、すべての共有リソースの中央リポジトリが用意され、クラスローディングプロセスが容易になります。同じオンプレミスの Mule Runtime Engine インスタンスに複数のサービスをデプロイする場合には、ドメインによってパフォーマンスが向上します。 詳細は​[「ドメイン」](#tuning-domains.adoc)​を参照してください。 ## [](#ログ記録)ログ記録 非同期ログのほうが同期ログよりパフォーマンスが高い理由を理解してください。 詳細は​[「ログ記録」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-logging)​を参照してください。 ## [](#バッチ処理)バッチ処理 Mule はメッセージをバッチ処理できますが、バッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。アプリケーションに合わせたバッチブロックサイズプロパティを設定する方法を理解してください。 詳細は​[「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-batch-processing)​を参照してください。 ## [](#アプリケーション設計のベストプラクティス)アプリケーション設計のベストプラクティス 設計フェーズで特定のプラクティスに従うことにより、Mule アプリケーションのパフォーマンスを高めることができます。 詳細は​[「アプリケーションの設計」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-app-design)​を参照してください。 ## [](#関連情報)関連情報 - [パフォーマンスチューニングガイド](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-guide) # チューニングの推奨事項 Mule 4 は、Mule Runtime Engine (Mule) をデプロイした環境の動作条件に従って自己チューニングを行い、自身を最適なパフォーマンスに調整します。 自己チューニングにより、Mule の内部処理ではなく自分のアプリケーションに集中できるため、最適化プロセスが容易になります。また、Mule は出荷時に最も一般的なユースケースに合わせて最適なパフォーマンスにチューニングされていますので、パラメーターの変更は、それによる影響を完全に理解している場合にのみ行ってください。 以下に、アプリケーションレベルで適用することで特定のユースケースにおいて有効なチューニングの推奨事項を紹介します。 ## [](#反復可能ストリームと反復不可能ストリーム)反復可能ストリームと反復不可能ストリーム 自分のユースケースで最適なフローパフォーマンスを実現するストリーミング戦略を理解してください。 - 反復可能ストリーム (ペイロードを複数回読み取る) - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) 詳細は、​[「反復可能ストリームと反復不可能ストリーム」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-repeatable-nonrepeatable)​を参照してください。 ## [](#back-pressure-と-maxconcurrency)back-pressure と maxConcurrency バックプレッシャーと ​`maxConcurrency`​ パラメーターの使い方を理解して、フローに送信される同時メッセージ数をチューニングします。 詳細は、​[「back-pressure と maxConcurrency」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-backpressure-maxconcurrency)​を参照してください。 ## [](#バックエンドサーバーの応答時間)バックエンドサーバーの応答時間 バックエンドサーバーの平均レイテンシーとスループットによってアプリケーションの拡張性やパフォーマンスが制限されていないかを確認します。 詳細は、​[「バックエンドサーバーの応答時間」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-backend-server)​を参照してください。 ## [](#キャッシュ)キャッシュ データの主要な側面に基づいて、キャッシュするタイミングや使用するキャッシュ戦略を決定します。Mule では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能なメカニズムによってニーズに合わせたキャッシュ処理を実現できます。 詳細は​[「キャッシュ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-caching)​を参照してください。 ## [](#プーリングプロファイル)プーリングプロファイル コンポーネントをプールすることで、同時に受信する要求を効率よく処理できます。パフォーマンステストで必要だと判明した場合には、​`pooling-profile`​ をコネクタに追加してください。 詳細は、​[「プーリングプロファイル」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-pooling-profiles)​を参照してください。 ## [](#ドメイン)ドメイン ドメインを使用することで、すべての共有リソースの中央リポジトリが用意され、クラスローディングプロセスが容易になります。同じオンプレミスの Mule Runtime Engine インスタンスに複数のサービスをデプロイする場合には、ドメインによってパフォーマンスが向上します。 詳細は​[「ドメイン」](#tuning-domains.adoc)​を参照してください。 ## [](#ログ記録)ログ記録 非同期ログのほうが同期ログよりパフォーマンスが高い理由を理解してください。 詳細は​[「ログ記録」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-logging)​を参照してください。 ## [](#バッチ処理)バッチ処理 Mule はメッセージをバッチ処理できますが、バッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。アプリケーションに合わせたバッチブロックサイズプロパティを設定する方法を理解してください。 詳細は​[「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-batch-processing)​を参照してください。 ## [](#アプリケーション設計のベストプラクティス)アプリケーション設計のベストプラクティス 設計フェーズで特定のプラクティスに従うことにより、Mule アプリケーションのパフォーマンスを高めることができます。 詳細は​[「アプリケーションの設計」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-app-design)​を参照してください。 ## [](#関連情報)関連情報 - [パフォーマンスチューニングガイド](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-guide) # チューニングの推奨事項 Mule 4 は、Mule Runtime Engine (Mule) をデプロイした環境の動作条件に従って自己チューニングを行い、自身を最適なパフォーマンスに調整します。 自己チューニングにより、Mule の内部処理ではなく自分のアプリケーションに集中できるため、最適化プロセスが容易になります。また、Mule は出荷時に最も一般的なユースケースに合わせて最適なパフォーマンスにチューニングされていますので、パラメーターの変更は、それによる影響を完全に理解している場合にのみ行ってください。 以下に、アプリケーションレベルで適用することで特定のユースケースにおいて有効なチューニングの推奨事項を紹介します。 ## [](#反復可能ストリームと反復不可能ストリーム)反復可能ストリームと反復不可能ストリーム 自分のユースケースで最適なフローパフォーマンスを実現するストリーミング戦略を理解してください。 - 反復可能ストリーム (ペイロードを複数回読み取る) - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) 詳細は、​[「反復可能ストリームと反復不可能ストリーム」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-repeatable-nonrepeatable)​を参照してください。 ## [](#back-pressure-と-maxconcurrency)back-pressure と maxConcurrency バックプレッシャーと ​`maxConcurrency`​ パラメーターの使い方を理解して、フローに送信される同時メッセージ数をチューニングします。 詳細は、​[「back-pressure と maxConcurrency」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-backpressure-maxconcurrency)​を参照してください。 ## [](#バックエンドサーバーの応答時間)バックエンドサーバーの応答時間 バックエンドサーバーの平均レイテンシーとスループットによってアプリケーションの拡張性やパフォーマンスが制限されていないかを確認します。 詳細は、​[「バックエンドサーバーの応答時間」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-backend-server)​を参照してください。 ## [](#キャッシュ)キャッシュ データの主要な側面に基づいて、キャッシュするタイミングや使用するキャッシュ戦略を決定します。Mule では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能なメカニズムによってニーズに合わせたキャッシュ処理を実現できます。 詳細は​[「キャッシュ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-caching)​を参照してください。 ## [](#プーリングプロファイル)プーリングプロファイル コンポーネントをプールすることで、同時に受信する要求を効率よく処理できます。パフォーマンステストで必要だと判明した場合には、​`pooling-profile`​ をコネクタに追加してください。 詳細は、​[「プーリングプロファイル」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-pooling-profiles)​を参照してください。 ## [](#ドメイン)ドメイン ドメインを使用することで、すべての共有リソースの中央リポジトリが用意され、クラスローディングプロセスが容易になります。同じオンプレミスの Mule Runtime Engine インスタンスに複数のサービスをデプロイする場合には、ドメインによってパフォーマンスが向上します。 詳細は​[「ドメイン」](#tuning-domains.adoc)​を参照してください。 ## [](#ログ記録)ログ記録 非同期ログのほうが同期ログよりパフォーマンスが高い理由を理解してください。 詳細は​[「ログ記録」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-logging)​を参照してください。 ## [](#バッチ処理)バッチ処理 Mule はメッセージをバッチ処理できますが、バッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。アプリケーションに合わせたバッチブロックサイズプロパティを設定する方法を理解してください。 詳細は​[「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-batch-processing)​を参照してください。 ## [](#アプリケーション設計のベストプラクティス)アプリケーション設計のベストプラクティス 設計フェーズで特定のプラクティスに従うことにより、Mule アプリケーションのパフォーマンスを高めることができます。 詳細は​[「アプリケーションの設計」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-app-design)​を参照してください。 ## [](#関連情報)関連情報 - [パフォーマンスチューニングガイド](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-guide) # チューニングの推奨事項 Mule 4 は、Mule Runtime Engine (Mule) をデプロイした環境の動作条件に従って自己チューニングを行い、自身を最適なパフォーマンスに調整します。 自己チューニングにより、Mule の内部処理ではなく自分のアプリケーションに集中できるため、最適化プロセスが容易になります。また、Mule は出荷時に最も一般的なユースケースに合わせて最適なパフォーマンスにチューニングされていますので、パラメーターの変更は、それによる影響を完全に理解している場合にのみ行ってください。 以下に、アプリケーションレベルで適用することで特定のユースケースにおいて有効なチューニングの推奨事項を紹介します。 ## [](#反復可能ストリームと反復不可能ストリーム)反復可能ストリームと反復不可能ストリーム 自分のユースケースで最適なフローパフォーマンスを実現するストリーミング戦略を理解してください。 - 反復可能ストリーム (ペイロードを複数回読み取る) - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) 詳細は、​[「反復可能ストリームと反復不可能ストリーム」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-repeatable-nonrepeatable)​を参照してください。 ## [](#back-pressure-と-maxconcurrency)back-pressure と maxConcurrency バックプレッシャーと ​`maxConcurrency`​ パラメーターの使い方を理解して、フローに送信される同時メッセージ数をチューニングします。 詳細は、​[「back-pressure と maxConcurrency」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-backpressure-maxconcurrency)​を参照してください。 ## [](#バックエンドサーバーの応答時間)バックエンドサーバーの応答時間 バックエンドサーバーの平均レイテンシーとスループットによってアプリケーションの拡張性やパフォーマンスが制限されていないかを確認します。 詳細は、​[「バックエンドサーバーの応答時間」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-backend-server)​を参照してください。 ## [](#キャッシュ)キャッシュ データの主要な側面に基づいて、キャッシュするタイミングや使用するキャッシュ戦略を決定します。Mule では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能なメカニズムによってニーズに合わせたキャッシュ処理を実現できます。 詳細は​[「キャッシュ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-caching)​を参照してください。 ## [](#プーリングプロファイル)プーリングプロファイル コンポーネントをプールすることで、同時に受信する要求を効率よく処理できます。パフォーマンステストで必要だと判明した場合には、​`pooling-profile`​ をコネクタに追加してください。 詳細は、​[「プーリングプロファイル」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-pooling-profiles)​を参照してください。 ## [](#ドメイン)ドメイン ドメインを使用することで、すべての共有リソースの中央リポジトリが用意され、クラスローディングプロセスが容易になります。同じオンプレミスの Mule Runtime Engine インスタンスに複数のサービスをデプロイする場合には、ドメインによってパフォーマンスが向上します。 詳細は​[「ドメイン」](#tuning-domains.adoc)​を参照してください。 ## [](#ログ記録)ログ記録 非同期ログのほうが同期ログよりパフォーマンスが高い理由を理解してください。 詳細は​[「ログ記録」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-logging)​を参照してください。 ## [](#バッチ処理)バッチ処理 Mule はメッセージをバッチ処理できますが、バッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。アプリケーションに合わせたバッチブロックサイズプロパティを設定する方法を理解してください。 詳細は​[「バッチ処理」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-batch-processing)​を参照してください。 ## [](#アプリケーション設計のベストプラクティス)アプリケーション設計のベストプラクティス 設計フェーズで特定のプラクティスに従うことにより、Mule アプリケーションのパフォーマンスを高めることができます。 詳細は​[「アプリケーションの設計」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-app-design)​を参照してください。 ## [](#関連情報)関連情報 - [パフォーマンスチューニングガイド](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-guide) # テスト構造 (MUnit) の移行 MUnit テストは、3 つのスコープに分かれています。すべて省略可能です。
スコープ 説明

動作

Behavior スコープ (​<munit:behavior/>​) は、テストロジックを実行する前に前提条件を設定することを目的としています。
このセクションには、モックやスパイが含まれます。

Execution

Execution スコープ (​<munit:execution/>​) には、次のスコープを実行する前にすべてのプロセスが終了するまで待機するテストロジックがあります。

Validation

Validation スコープ (​<munit:validation/>​) には、Execution スコープの結果に関連するすべての検証があります。
Validation スコープには、アサーションや検証が含まれます。
次の例では、1.x と 2.x の MUnit テストを比較しています。 MUnit 1.x のテスト ```xml ``` MUnit 2.x のテスト ```xml ``` ## [](#関連情報)関連情報 - [MUnit 2 テスト構造](https://docs.mulesoft.com/munit/latest/munit-test-concept) # テスト構造 (MUnit) の移行 MUnit テストは、3 つのスコープに分かれています。すべて省略可能です。
スコープ 説明

Behavior

Behavior スコープ (​<munit:behavior/>​) は、テストロジックを実行する前に前提条件を設定することを目的としています。
このセクションには、モックやスパイが含まれます。

Execution

Execution スコープ (​<munit:execution/>​) には、次のスコープを実行する前にすべてのプロセスが終了するまで待機するテストロジックがあります。

Validation

Validation スコープ (​<munit:validation/>​) には、Execution スコープの結果に関連するすべての検証があります。
Validation スコープには、アサーションや検証が含まれます。
次の例では、1.x と 2.x の MUnit テストを比較しています。 MUnit 1.x のテスト ```xml ``` MUnit 2.x のテスト ```xml ``` ## [](#関連情報)関連情報 - [MUnit 2 テスト構造](https://docs.mulesoft.com/munit/latest/munit-test-concept) # テスト構造 (MUnit) の移行 MUnit テストは、3 つのスコープに分かれています。すべて省略可能です。
スコープ 説明

Behavior

Behavior スコープ (​<munit:behavior/>​) は、テストロジックを実行する前に前提条件を設定することを目的としています。
このセクションには、モックやスパイが含まれます。

Execution

Execution スコープ (​<munit:execution/>​) には、次のスコープを実行する前にすべてのプロセスが終了するまで待機するテストロジックがあります。

Validation

Validation スコープ (​<munit:validation/>​) には、Execution スコープの結果に関連するすべての検証があります。
Validation スコープには、アサーションや検証が含まれます。
次の例では、1.x と 2.x の MUnit テストを比較しています。 MUnit 1.x のテスト ```xml ``` MUnit 2.x のテスト ```xml ``` ## [](#関連情報)関連情報 - [MUnit 2 テスト構造](https://docs.mulesoft.com/munit/latest/munit-test-concept) # テスト構造 (MUnit) の移行 MUnit テストは、3 つのスコープに分かれています。すべて省略可能です。
スコープ 説明

Behavior

Behavior スコープ (​<munit:behavior/>​) は、テストロジックを実行する前に前提条件を設定することを目的としています。
このセクションには、モックやスパイが含まれます。

Execution

Execution スコープ (​<munit:execution/>​) には、次のスコープを実行する前にすべてのプロセスが終了するまで待機するテストロジックがあります。

Validation

Validation スコープ (​<munit:validation/>​) には、Execution スコープの結果に関連するすべての検証があります。
Validation スコープには、アサーションや検証が含まれます。
次の例では、1.x と 2.x の MUnit テストを比較しています。 MUnit 1.x のテスト ```xml ``` MUnit 2.x のテスト ```xml ``` ## [](#関連情報)関連情報 - [MUnit 2 テスト構造](https://docs.mulesoft.com/munit/latest/munit-test-concept) # テスト構造 (MUnit) の移行 MUnit テストは、3 つのスコープに分かれています。すべて省略可能です。
スコープ 説明

動作

Behavior スコープ (​<munit:behavior/>​) は、テストロジックを実行する前に前提条件を設定することを目的としています。
このセクションには、モックやスパイが含まれます。

Execution

Execution スコープ (​<munit:execution/>​) には、次のスコープを実行する前にすべてのプロセスが終了するまで待機するテストロジックがあります。

Validation

Validation スコープ (​<munit:validation/>​) には、Execution スコープの結果に関連するすべての検証があります。
Validation スコープには、アサーションや検証が含まれます。
次の例では、1.x と 2.x の MUnit テストを比較しています。 MUnit 1.x のテスト ```xml ``` MUnit 2.x のテスト ```xml ``` ## [](#関連情報)関連情報 - [MUnit 2 テスト構造](https://docs.mulesoft.com/munit/latest/munit-test-concept) # テスト構造 (MUnit) の移行 MUnit テストは、3 つのスコープに分かれています。すべて省略可能です。
スコープ 説明

動作

Behavior スコープ (​<munit:behavior/>​) は、テストロジックを実行する前に前提条件を設定することを目的としています。
このセクションには、モックやスパイが含まれます。

Execution

Execution スコープ (​<munit:execution/>​) には、次のスコープを実行する前にすべてのプロセスが終了するまで待機するテストロジックがあります。

Validation

Validation スコープ (​<munit:validation/>​) には、Execution スコープの結果に関連するすべての検証があります。
Validation スコープには、アサーションや検証が含まれます。
次の例では、1.x と 2.x の MUnit テストを比較しています。 MUnit 1.x のテスト ```xml ``` MUnit 2.x のテスト ```xml ``` ## [](#関連情報)関連情報 - [MUnit 2 テスト構造](https://docs.mulesoft.com/munit/latest/munit-test-concept) # テスト構造 (MUnit) の移行 MUnit テストは、3 つのスコープに分かれています。すべて省略可能です。
スコープ 説明

動作

Behavior スコープ (​<munit:behavior/>​) は、テストロジックを実行する前に前提条件を設定することを目的としています。
このセクションには、モックやスパイが含まれます。

Execution

Execution スコープ (​<munit:execution/>​) には、次のスコープを実行する前にすべてのプロセスが終了するまで待機するテストロジックがあります。

Validation

Validation スコープ (​<munit:validation/>​) には、Execution スコープの結果に関連するすべての検証があります。
Validation スコープには、アサーションや検証が含まれます。
次の例では、1.x と 2.x の MUnit テストを比較しています。 MUnit 1.x のテスト ```xml ``` MUnit 2.x のテスト ```xml ``` ## [](#関連情報)関連情報 - [MUnit 2 テスト構造](https://docs.mulesoft.com/munit/latest/munit-test-concept) # デフォルトイベント追跡の設定 イベント追跡を行うと、Mule Runtime Engine で生成されるイベントを集約および保存するための処理やネットワークオーバーヘッドが必要になるため、デフォルトでは、イベント追跡は無効になっています。ただし、イベント追跡をサポートするコネクタまたはメッセージプロセッサーに対して、次の 2 つのいずれかのレベルでデフォルトイベント追跡を有効化し、設定することができます。 - フローレベル - メッセージプロセッサー (コネクタまたはコンポーネント) レベル (フローレベルの設定よりも優先される) イベント追跡を有効にしたら、特定の追跡対象イベントを識別するようにトランザクション ID をカスタマイズして、実行時にそのイベントを分析できるようにします。 ## [](#フローレベルのイベント追跡)フローレベルのイベント追跡 イベント追跡をサポートするフローのすべての要素のデフォルトイベント追跡を有効にするには、このオプションを使用します。 特定のプロセッサーまたはコネクタの追跡を無効にして、フローレベルの設定を上書きできます。 フローのすべてのコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. フローコンポーネントを選択して、プロパティビューを開きます。 2. UI または XML を使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![default-event-tracking-flow](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-business-event-flow.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ を ​`flow`​ 要素に追加します。 ```xml ``` 3. 設定を保存します。 ## [](#メッセージプロセッサーレベルのイベント追跡)メッセージプロセッサーレベルのイベント追跡 イベント追跡をサポートする個々のコネクタおよびコンポーネントでイベント追跡を有効にできます。 個々のコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. コネクタまたはコンポーネントのプロパティビューを開きます。 2. 次のいずれかのオプションを使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![default-event-tracking-component](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-business-event-component.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ をコンポーネント要素の内側に追加します。 ```xml ... ... ``` 3. 設定を保存します。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![custom-transaction-id](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events) # デフォルトイベント追跡の設定 イベント追跡を行うと、Mule Runtime Engine で生成されるイベントを集約および保存するための処理やネットワークオーバーヘッドが必要になるため、デフォルトでは、イベント追跡は無効になっています。ただし、イベント追跡をサポートするコネクタまたはメッセージプロセッサーに対して、次の 2 つのいずれかのレベルでデフォルトイベント追跡を有効化し、設定することができます。 - フローレベル - メッセージプロセッサー (コネクタまたはコンポーネント) レベル (フローレベルの設定よりも優先される) イベント追跡を有効にしたら、特定の追跡対象イベントを識別するようにトランザクション ID をカスタマイズして、実行時にそのイベントを分析できるようにします。 ## [](#フローレベルのイベント追跡)フローレベルのイベント追跡 イベント追跡をサポートするフローのすべての要素のデフォルトイベント追跡を有効にするには、​[Flow](https://docs.mulesoft.com/jp/mule-runtime/4.4/flow-component)​ コンポーネントでこのオプションを使用します。 特定のプロセッサーまたはコネクタの追跡を無効にして、フローレベルの設定を上書きできます。 フローのすべてのコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. フローコンポーネントを選択して、プロパティビューを開きます。 2. UI または XML を使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![default-event-tracking-flow](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-business-event-flow.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ を ​`flow`​ 要素に追加します。 ```xml ``` 3. 設定を保存します。 ## [](#メッセージプロセッサーレベルのイベント追跡)メッセージプロセッサーレベルのイベント追跡 イベント追跡をサポートする個々のコネクタおよび Mule コンポーネントでイベント追跡を有効にできます。 次の Mule コンポーネントでは、ビジネスイベントを有効にするための設定が提供されます。 - [Choice](https://docs.mulesoft.com/jp/mule-runtime/4.4/choice-router-concept)​ ルーター - [Round Robin](https://docs.mulesoft.com/jp/mule-runtime/4.4/round-robin)​ ルーター - [First Successful](https://docs.mulesoft.com/jp/mule-runtime/4.4/first-successful)​ ルーター 個々のコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. コネクタまたはコンポーネントのプロパティビューを開きます。 2. 次のいずれかのオプションを使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![default-event-tracking-component](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-business-event-component.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ をコンポーネント要素の内側に追加します。 ```xml ... ... ``` 3. 設定を保存します。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![custom-transaction-id](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events) # デフォルトイベント追跡の設定 イベント追跡を行うと、Mule Runtime Engine で生成されるイベントを集約および保存するための処理やネットワークオーバーヘッドが必要になるため、デフォルトでは、イベント追跡は無効になっています。ただし、イベント追跡をサポートするコネクタまたはメッセージプロセッサーに対して、次の 2 つのいずれかのレベルでデフォルトイベント追跡を有効化し、設定することができます。 - フローレベル - メッセージプロセッサー (コネクタまたはコンポーネント) レベル (フローレベルの設定よりも優先される) イベント追跡を有効にしたら、特定の追跡対象イベントを識別するようにトランザクション ID をカスタマイズして、実行時にそのイベントを分析できるようにします。 ## [](#フローレベルのイベント追跡)フローレベルのイベント追跡 イベント追跡をサポートするフローのすべての要素のデフォルトイベント追跡を有効にするには、​[Flow](https://docs.mulesoft.com/jp/mule-runtime/4.5/flow-component)​ コンポーネントでこのオプションを使用します。 特定のプロセッサーまたはコネクタの追跡を無効にして、フローレベルの設定を上書きできます。 フローのすべてのコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. フローコンポーネントを選択して、プロパティビューを開きます。 2. UI または XML を使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![default-event-tracking-flow](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-business-event-flow.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ を ​`flow`​ 要素に追加します。 ```xml ``` 3. 設定を保存します。 ## [](#メッセージプロセッサーレベルのイベント追跡)メッセージプロセッサーレベルのイベント追跡 イベント追跡をサポートする個々のコネクタおよび Mule コンポーネントでイベント追跡を有効にできます。 次の Mule コンポーネントでは、ビジネスイベントを有効にするための設定が提供されます。 - [Choice](https://docs.mulesoft.com/jp/mule-runtime/4.5/choice-router-concept)​ ルーター - [Round Robin](https://docs.mulesoft.com/jp/mule-runtime/4.5/round-robin)​ ルーター - [First Successful](https://docs.mulesoft.com/jp/mule-runtime/4.5/first-successful)​ ルーター 個々のコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. コネクタまたはコンポーネントのプロパティビューを開きます。 2. 次のいずれかのオプションを使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![default-event-tracking-component](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-business-event-component.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ をコンポーネント要素の内側に追加します。 ```xml ... ... ``` 3. 設定を保存します。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![custom-transaction-id](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events) # デフォルトイベント追跡の設定 イベント追跡を行うと、Mule Runtime Engine で生成されるイベントを集約および保存するための処理やネットワークオーバーヘッドが必要になるため、デフォルトでは、イベント追跡は無効になっています。ただし、イベント追跡をサポートするコネクタまたはメッセージプロセッサーに対して、次の 2 つのいずれかのレベルでデフォルトイベント追跡を有効化し、設定することができます。 - フローレベル - メッセージプロセッサー (コネクタまたはコンポーネント) レベル (フローレベルの設定よりも優先される) イベント追跡を有効にしたら、特定の追跡対象イベントを識別するようにトランザクション ID をカスタマイズして、実行時にそのイベントを分析できるようにします。 ## [](#フローレベルのイベント追跡)フローレベルのイベント追跡 イベント追跡をサポートするフローのすべての要素のデフォルトイベント追跡を有効にするには、​[Flow](https://docs.mulesoft.com/jp/mule-runtime/4.6/flow-component)​ コンポーネントでこのオプションを使用します。 特定のプロセッサーまたはコネクタの追跡を無効にして、フローレベルの設定を上書きできます。 フローのすべてのコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. フローコンポーネントを選択して、プロパティビューを開きます。 2. UI または XML を使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![default-event-tracking-flow](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-business-event-flow.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ を ​`flow`​ 要素に追加します。 ```xml ``` 3. 設定を保存します。 ## [](#メッセージプロセッサーレベルのイベント追跡)メッセージプロセッサーレベルのイベント追跡 イベント追跡をサポートする個々のコネクタおよび Mule コンポーネントでイベント追跡を有効にできます。 次の Mule コンポーネントでは、ビジネスイベントを有効にするための設定が提供されます。 - [Choice](https://docs.mulesoft.com/jp/mule-runtime/4.6/choice-router-concept)​ ルーター - [Round Robin](https://docs.mulesoft.com/jp/mule-runtime/4.6/round-robin)​ ルーター - [First Successful](https://docs.mulesoft.com/jp/mule-runtime/4.6/first-successful)​ ルーター 個々のコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. コネクタまたはコンポーネントのプロパティビューを開きます。 2. 次のいずれかのオプションを使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![default-event-tracking-component](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-business-event-component.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ をコンポーネント要素の内側に追加します。 ```xml ... ... ``` 3. 設定を保存します。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![custom-transaction-id](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events) # デフォルトイベント追跡の設定 イベント追跡を行うと、Mule Runtime Engine で生成されるイベントを集約および保存するための処理やネットワークオーバーヘッドが必要になるため、デフォルトでは、イベント追跡は無効になっています。ただし、イベント追跡をサポートするコネクタまたはメッセージプロセッサーに対して、次の 2 つのいずれかのレベルでデフォルトイベント追跡を有効化し、設定することができます。 - フローレベル - メッセージプロセッサー (コネクタまたはコンポーネント) レベル (フローレベルの設定よりも優先される) イベント追跡を有効にしたら、特定の追跡対象イベントを識別するようにトランザクション ID をカスタマイズして、実行時にそのイベントを分析できるようにします。 ## [](#フローレベルのイベント追跡)フローレベルのイベント追跡 イベント追跡をサポートするフローのすべての要素のデフォルトイベント追跡を有効にするには、​[Flow](https://docs.mulesoft.com/jp/mule-runtime/4.7/flow-component)​ コンポーネントでこのオプションを使用します。 特定のプロセッサーまたはコネクタの追跡を無効にして、フローレベルの設定を上書きできます。 フローのすべてのコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. フローコンポーネントを選択して、プロパティビューを開きます。 2. UI または XML を使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![default-event-tracking-flow](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-business-event-flow.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ を ​`flow`​ 要素に追加します。 ```xml ``` 3. 設定を保存します。 ## [](#メッセージプロセッサーレベルのイベント追跡)メッセージプロセッサーレベルのイベント追跡 イベント追跡をサポートする個々のコネクタおよび Mule コンポーネントでイベント追跡を有効にできます。 次の Mule コンポーネントでは、ビジネスイベントを有効にするための設定が提供されます。 - [Choice](https://docs.mulesoft.com/jp/mule-runtime/4.7/choice-router-concept)​ ルーター - [Round Robin](https://docs.mulesoft.com/jp/mule-runtime/4.7/round-robin)​ ルーター - [First Successful](https://docs.mulesoft.com/jp/mule-runtime/4.7/first-successful)​ ルーター 個々のコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. コネクタまたはコンポーネントのプロパティビューを開きます。 2. 次のいずれかのオプションを使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![default-event-tracking-component](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-business-event-component.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ をコンポーネント要素の内側に追加します。 ```xml ... ... ``` 3. 設定を保存します。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![Mule フローのトランザクション ID を定義する設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events) # デフォルトイベント追跡の設定 イベント追跡を行うと、Mule Runtime Engine で生成されるイベントを集約および保存するための処理やネットワークオーバーヘッドが必要になるため、デフォルトでは、イベント追跡は無効になっています。ただし、イベント追跡をサポートするコネクタまたはメッセージプロセッサーに対して、次の 2 つのいずれかのレベルでデフォルトイベント追跡を有効化し、設定することができます。 - フローレベル - メッセージプロセッサー (コネクタまたはコンポーネント) レベル (フローレベルの設定よりも優先される) イベント追跡を有効にしたら、特定の追跡対象イベントを識別するようにトランザクション ID をカスタマイズして、実行時にそのイベントを分析できるようにします。 ## [](#フローレベルのイベント追跡)フローレベルのイベント追跡 イベント追跡をサポートするフローのすべての要素のデフォルトイベント追跡を有効にするには、​[Flow](https://docs.mulesoft.com/jp/mule-runtime/4.8/flow-component)​ コンポーネントでこのオプションを使用します。 特定のプロセッサーまたはコネクタの追跡を無効にして、フローレベルの設定を上書きできます。 フローのすべてのコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. フローコンポーネントを選択して、プロパティビューを開きます。 2. UI または XML を使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![イベント追跡を有効にするオプションが含まれる、JMS 処理のフロー設定インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-business-event-flow.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ を ​`flow`​ 要素に追加します。 ```xml ``` 3. 設定を保存します。 ## [](#メッセージプロセッサーレベルのイベント追跡)メッセージプロセッサーレベルのイベント追跡 イベント追跡をサポートする個々のコネクタおよび Mule コンポーネントでイベント追跡を有効にできます。 次の Mule コンポーネントでは、ビジネスイベントを有効にするための設定が提供されます。 - [Choice](https://docs.mulesoft.com/jp/mule-runtime/4.8/choice-router-concept)​ ルーター - [Round Robin](https://docs.mulesoft.com/jp/mule-runtime/4.8/round-robin)​ ルーター - [First Successful](https://docs.mulesoft.com/jp/mule-runtime/4.8/first-successful)​ ルーター 個々のコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. コネクタまたはコンポーネントのプロパティビューを開きます。 2. 次のいずれかのオプションを使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![Choice コンポーネント内のビジネスイベント追跡](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-business-event-component.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ をコンポーネント要素の内側に追加します。 ```xml ... ... ``` 3. 設定を保存します。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![Mule フローのトランザクション ID を定義する設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events) # デフォルトイベント追跡の設定 イベント追跡を行うと、Mule Runtime Engine で生成されるイベントを集約および保存するための処理やネットワークオーバーヘッドが必要になるため、デフォルトでは、イベント追跡は無効になっています。ただし、イベント追跡をサポートするコネクタまたはメッセージプロセッサーに対して、次の 2 つのいずれかのレベルでデフォルトイベント追跡を有効化し、設定することができます。 - フローレベル - メッセージプロセッサー (コネクタまたはコンポーネント) レベル (フローレベルの設定よりも優先される) イベント追跡を有効にしたら、特定の追跡対象イベントを識別するようにトランザクション ID をカスタマイズして、実行時にそのイベントを分析できるようにします。 ## [](#フローレベルのイベント追跡)フローレベルのイベント追跡 イベント追跡をサポートするフローのすべての要素のデフォルトイベント追跡を有効にするには、​[Flow](https://docs.mulesoft.com/jp/mule-runtime/4.9/flow-component)​ コンポーネントでこのオプションを使用します。 特定のプロセッサーまたはコネクタの追跡を無効にして、フローレベルの設定を上書きできます。 フローのすべてのコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. フローコンポーネントを選択して、プロパティビューを開きます。 2. UI または XML を使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![イベント追跡を有効にするオプションが含まれる、JMS 処理のフロー設定インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-business-event-flow.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ を ​`flow`​ 要素に追加します。 ```xml ``` 3. 設定を保存します。 ## [](#メッセージプロセッサーレベルのイベント追跡)メッセージプロセッサーレベルのイベント追跡 イベント追跡をサポートする個々のコネクタおよび Mule コンポーネントでイベント追跡を有効にできます。 次の Mule コンポーネントでは、ビジネスイベントを有効にするための設定が提供されます。 - [Choice](https://docs.mulesoft.com/jp/mule-runtime/4.9/choice-router-concept)​ ルーター - [Round Robin](https://docs.mulesoft.com/jp/mule-runtime/4.9/round-robin)​ ルーター - [First Successful](https://docs.mulesoft.com/jp/mule-runtime/4.9/first-successful)​ ルーター 個々のコンポーネントのデフォルトイベント追跡を有効にする手順は、次のとおりです。 1. コネクタまたはコンポーネントのプロパティビューを開きます。 2. 次のいずれかのオプションを使用して、デフォルトビジネスイベントを有効にします。 - UI では、​**\[Enable default events tracking (デフォルトイベント追跡を有効化)\]**​ をオンにします。 ![Choice コンポーネント内のビジネスイベント追跡](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-business-event-component.png) - XML では、属性 ​`tracking:enable-default-events="true"`​ をコンポーネント要素の内側に追加します。 ```xml ... ... ``` 3. 設定を保存します。 ## [](#customize-transaction-id)トランザクション ID のカスタマイズ Set Transaction Id コンポーネントを使用すると、すべての追跡対象イベントの識別子を設定できるため、Anypoint Runtime Manager または CloudHub のどちらを使用しているかにかかわらず、実行時に追跡対象イベントを分析するときにトランザクションの有用な情報 (注文番号など) が表示されます。 トランザクション ID は DataWeave 式をサポートするため、ID を動的に作成し、イベントに関連する情報を ID に含めることができます。 Anypoint Studio で、または設定 XML を編集して、次の手順に従ってトランザクション ID を設定します。 - Studio UI: 1. **\[Set Transaction Id\]**​ コンポーネントをフローにドラッグします。 2. **\[Set Transaction ID\]**​ 設定画面の ​**\[Transaction ID (トランザクション ID)\]**​ 項目で、ID 値を設定します。 ![Mule フローのトランザクション ID を定義する設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-custom-transaction-id.png) - XML エディター: - `flow`​ 要素に子要素を追加します。 ```xml ... ... ``` ## [](#関連情報)関連情報 [ビジネスイベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events) # ドメイン 同じオンプレミス Mule Runtime Engine (Mule) に複数のサービスをデプロイする場合は、ドメインを使用することでパフォーマンスを高めることができます。ドメインは、すべての共有リソースに対して中央管理ポイントを提供することにより、特に ​`pom.xml`​ ファイルで宣言されているドメインの連動関係もドメインアプリケーション間で共有するため、クラスローディングプロセス (そしてメタスペースメモリの使用) をより効率的にします。 ## [](#ドメインを使用することによるパフォーマンス向上の例)ドメインを使用することによるパフォーマンス向上の例 1 つのゲートウェイポリシー (IP ホワイトリストなど) も適用する HTTP プロキシアプリケーション群があるとします。各アプリケーションは同じバックエンドとやり取りします。2 GB のヒープメモリと 256 MB のメタスペースが設定された Mule インスタンスで、適切なドメインを使用せずにこれらのアプリケーションを 60 件以上、別々にデプロイすると、リソースの飽和によって TPS (毎秒のトランザクション数) が大幅に低下します。80 件のアプリケーションをデプロイすると、メモリ不足例外によってデプロイエラーとなります。 この問題は、バックエンドサーバー設定を共有するドメインを使用するだけで大幅に改善され、デプロイするアプリケーション数が 100 件を超えても、マシンリソースはバランスよく使用されて良好なパフォーマンスが維持されます。 ドメインを使用することでパフォーマンスは明らかに向上しますが、デプロイされる各アプリケーションには、共有インフラストラクチャリソースによる複雑さが追加されます。パフォーマンスへの影響を回避するため、アプリケーションを追加する前に、各アプリケーションを個別にテストすることでオーバーヘッドを特定してから、他のアプリケーションと共存させてテストしてください。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.3/shared-resources) # トランザクションの管理 トランザクションとは、結果が不確定になることができない Mule アプリケーションの操作です。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 たとえば、トランザクションを使用して、データベースに情報をコミットするためのフロー内の複数のステップをカプセル化することができます。このようなシナリオでは、コミット (トランザクション) は、全体が完了 (成功) するか、不完全に終了 (失敗) するかのどちらかとなります。部分的に完了しても、コミットは失敗となります。トランザクションが失敗すると、一部だけで部分的な完了とならないように Mule は操作をトランザクション内でロールバックします。 アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、信頼性の高いメッセージングができるように​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.3/reliability-patterns)​を実装してアプリケーションをデザインしてください。 Mule アプリケーションでトランザクションを管理するように Bitronix を設定することもできます。 ## [](#トランザクション種別)トランザクション種別 Mule は、単一リソース (ローカル、デフォルト) および拡張アーキテクチャ (​`XA`​) トランザクション種別 (​`transactionType`​) をサポートします。トランザクション種別を定義できるコンポーネントはメッセージソース (たとえば、​`jms:listener`​ や ​`vm:listener`​) と Try スコープのみです。 次の表で、各トランザクション種別の特性とトランザクションを結合するための操作の要件について説明します。
トランザクション種別 特性 トランザクションを結合するための要件

単一リソース (ローカル)

  • XA トランザクションよりパフォーマンスが高くなります。

  • ネストされたトランザクションをサポートしていません。

  • 操作がトランザクションをサポートする必要があります。

  • トランザクション内のすべての操作が同じコネクタに属している必要があります。(たとえば、​jms:listener​、​jms:consume​、​jms:publish​)。

  • すべての操作で同じグローバル設定 (​config-ref​) を使用する必要があります。

拡張アーキテクチャ (XA)

  • 2 段階のコミットプロトコル (2PC) を使用します。

  • 単一リソーストランザクションより遅くなりますが、信頼性は高くなります。

  • ネストされたトランザクションをサポートしています。

  • 操作がトランザクションをサポートする必要があります。
## [](#トランザクションのアクション)トランザクションのアクション トランザクションアクション (​`transactionalAction`​) は、トランザクションに関して操作で実行できるアクションの種別を定義します。次の表で、使用可能なすべてのトランザクションアクションについて説明します。
アクション 動作 使用可能な場所

ALWAYS_BEGIN

メッセージの受信時に常に新しいトランザクションを開始します。単一リソーストランザクションが存在する場合、エラーが発生します。XA トランザクションが存在する場合、ネストされたトランザクションが作成されます。

  • トランザクションをサポートするリスナー

  • Try スコープ

ALWAYS_JOIN

メッセージの受信時に常にトランザクションが進行中であると想定します。トランザクションがない場合、エラーが発生します。

  • トランザクションをサポートする操作

BEGIN_OR_JOIN

メッセージの受信時にトランザクションが進行中である場合、可能であればトランザクションを結合します。可能でなければ新しいトランザクションを開始します。

  • Try スコープ

JOIN_IF_POSSIBLE

現在のトランザクションが使用可能な場合、そのトランザクションを結合します。可能でなければトランザクションは作成されません。

  • トランザクションをサポートする操作

INDIFFERENT

アクションをトランザクションとして扱いません。

  • Try スコープ

NONE

トランザクションを開始しません。

  • トランザクションをサポートするリスナー

NOT_SUPPORTED

存在するトランザクションの外部で実行します。

  • トランザクションをサポートする操作
## [](#メッセージソースでのトランザクションの設定)メッセージソースでのトランザクションの設定 トランザクションをメッセージソースから開始できます。この場合は、フロー全体が 1 つのトランザクションとなります。この方法は、メッセージングコネクタを使用して、メッセージングの処理中に問題が発生した場合にはメッセージをコンシュームしないようにして、後で (ロールバックによって) 再試行できるようにしたいときに便利です。 トランザクションをメッセージソースから開始するには、そのトランザクション種別とトランザクションアクションを設定します。 - Anypoint Studio では、次の手順を実行します。 リスナーの ​**\[Advanced (詳細)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![transaction-config-studio-vm](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/transaction-config-studio-vm.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例は、単一リソース (ローカル) トランザクションを開始するように設定された ​`vm:listener`​ メッセージソースを示しています。 ```xml ``` ## [](#try-スコープでのトランザクションの設定)Try スコープでのトランザクションの設定 Mule フローは、フロー内のトランザクションを必要とする非トランザクションコネクタ (HTTP など) で開始する場合もあります。たとえば、Mule フローで外部 Web サービスから情報を受け入れ、クレジットカードに請求してインボイス情報をデータベースに保存する前にデータを変換するとします。この場合は Try スコープを使用して、クレジットカードへの請求操作とデータベースへのコミット操作をラップすることでトランザクションをセットアップすれば、常に完全な成功または完全な失敗とロールバックのどちらかの結果になることを保証できます。 トランザクション種別とトランザクションアクションを設定して、Try スコープコンポーネントでトランザクションを設定できます。 - Anypoint Studio では、次の手順を実行します。 Try スコープの ​**\[General (一般)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![transaction-config-studio](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/transaction-config-studio.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例では、Try スコープによってデータベース操作 (​`db:insert`​) と VM 操作 (​`vm:publish`​) を含むトランザクションを区分しています。プロセス全体が成功した場合は両方が適用され、Try スコープ内でエラーが発生した場合はどちらも適用されません。 ```xml INSERT INTO main_flow_audit (errorType, description) VALUES (:errorType, :description) ``` ## [](#tx_scopes_routers)トランザクションによるスコープとルーターへの影響 トランザクションスコープで実行する場合は、プロセス全体を同じスレッドで実行する必要があります。これにより、スコープの実行方法、またはトランザクションの処理方法を変更できます。以下で、トランザクションスコープで実行するときに考慮する必要があるスコープおよびルーターの動作について詳しく説明します。 ### [](#スコープ)スコープ - [Async](https://docs.mulesoft.com/jp/mule-runtime/4.3/async-scope-reference)​: トランザクション内で実行した場合、Async スコープは引き続き別のスレッドで実行されます (非同期のまま)。ただし、これはこのスコープ内のプロセッサーの実行全体がトランザクションスコープ外で行われることを意味します。そのため、Async スコープ内でエラーが発生してもロールバックにはなりません。 - [Until Successful](https://docs.mulesoft.com/jp/mule-runtime/4.3/until-successful-scope)​: トランザクション内で実行した場合、Until Successful スコープはスレッドをブロックします。つまり、Until Successful スコープが再試行間の遅延を実行している間、この実行によって使用されるスレッドを使用して他の要求を処理することはできません。 - [Parallel Foreach](https://docs.mulesoft.com/jp/mule-runtime/4.3/parallel-foreach-scope)​: トランザクション内で実行した場合、Parallel Foreach スコープは並列で実行されません。つまり、Foreach スコープとして実行することになります。コレクションの 2 番目の要素は最初の要素が完了した後に処理されます。これは、このスコープによるエラーの処理に影響を及ぼしません。 - [Batch Processing](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-processing-concept)​: Batch Processing は Async スコープとして並列で機能するように設計されており、すべてのレコードはトランザクションとして扱われるため (内部 Batch トランザクションを含む)、Batch 実行はトランザクションの一部ではありません。 ### [](#ルーター)ルーター - [Scatter Gather](https://docs.mulesoft.com/jp/mule-runtime/4.3/scatter-gather-concept)​: トランザクション内で実行した場合、Scatter Gather は並列で実行されません。つまり、2 番目のルーターは最初のルーターが処理された後で実行され、3 番目のルーターは 2 番目のルーターの後で実行される、といった具合になります。 これは、このコンポーネントによるエラーの処理に影響を及ぼしません。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.3/flowref-about)​: 実行中のフロー (またはサブフロー) がトランザクション内で実行されている場合、Flow Reference コンポーネントによって参照先のフロー (またはサブフロー) の実行は同じトランザクションで続行されます。参照先のフローにトランザクションを開始するメッセージソースがある場合 (たとえば、​`transactionalAction="ALWAYS_BEGIN"`​ の ​`jms:listener`​ ソース)、​`transactionalAction`​ は無視されます。Flow Reference コンポーネントは、そのメッセージソースを除いて参照先のフローコンポーネントを実行します。 その他のルーターまたはスコープ (たとえば、Foreach) はトランザクションで続行され、その動作は変更されません。 ## [](#エラー処理)エラー処理 トランザクション中にエラーが発生した場合、アプリケーションはエラーを処理して続行するか、ロールバックを実行する必要があります。 エラーハンドラーには 2 つの種別があり、トランザクション中にエラーが発生したときの動作が異なります。 - On Error Propagate - `on-error-propagate`​ エラーハンドラーがトランザクションを開始したコンポーネントに対応する ​`error-handler`​ スコープ内にある場合: `on-error-propagate`​ スコープのプロセッサーを実行する前にトランザクションがロールバックされます。つまり、エラーハンドラー内のプロセッサーはトランザクション内で実行されません。 - `on-error-propagate`​ エラーハンドラーがトランザクションを開始しなかった要素内にある場合: トランザクションはロールバックされず、​`on-error-propagate`​ エラーハンドラー内のプロセッサーはトランザクション内で実行されます。一部のスコープやルーターでは、トランザクション内で実行したときに動作が異なります。 - On Error Continue エラーが処理され、トランザクションはアクティブなままになり、コミット可能です。​`on-error-continue`​ 内のプロセッサーはトランザクション内で実行されます。 ### [](#例-try-スコープでのエラー発生)例: Try スコープでのエラー発生 メッセージソース (​`jms:listener`​) がトランザクションを開始し、このトランザクションが Try スコープによって続行される (​`transactionalAction`​ はデフォルトの ​`INDIFFERENT`​ に設定) 例について考えてみます。 エラーが発生すると、最初に Try スコープの ​`error-handler`​ によって処理されます。エラーは ​`on-error-propagate`​ エラーハンドラーによって処理されますが、トランザクションを開始したのが Try スコープではないため、トランザクションはロールバックされません。トランザクションはフローレベルで (そのメッセージソースから) 開始されたため、トランザクションをロールバックできるのはフローエラーハンドラーのみです。 `on-error-propagate`​ エラーハンドラー内の ​`jms:publish`​ 操作はトランザクションを結合します。次にエラーはフロー ​`error-handler`​ に伝播され、このフローが ​`on-error-continue`​ エラーハンドラーを使用してエラーを処理します。​`on-error-continue`​ エラーハンドラー内の ​`jms:consume`​ 操作はトランザクション内で実行されます。最後に、トランザクションがコミットされます。 ```xml ``` 前の例で ​`on-error-continue`​ エラーハンドラーを ​`on-error-propagate`​ エラーハンドラーに置き換えると、プロセッサーの実行前にトランザクションがロールバックされます。このシナリオでは、​`jms:consume`​ 操作はトランザクションを結合できないため、この設定は正しくありません。 ### [](#例-参照先のフローでのエラー発生)例: 参照先のフローでのエラー発生 次の例の動作は前の例と同じですが、Try スコープの代わりに Flow Reference を使用し、参照先のフローでエラーが発生します。 ```xml ``` `someFlowContinuesTx`​ フローがトランザクションを開始したのではないため、そのエラーハンドラーはトランザクションをロールバックしません。 ### [](#例-エラーハンドラーの比較)例: エラーハンドラーの比較 この例は、​`on-error-continue`​ エラーハンドラーと ​`on-error-propagate`​ エラーハンドラーの違いを示しています。 ```xml ``` `flow1`​ で、​`on-error-continue`​ エラーハンドラーはトランザクションをアクティブに保ちますが、その中の Try スコープは新しいトランザクションを開始しようとします。この設定は有効ではなく、エラーが発生します。 `flow2`​ で、​`on-error-propagate`​ エラーハンドラーがトランザクションをロールバックし、​`on-error-propagate`​ エラーハンドラー内のプロセッサーが実行され、トランザクションが新規作成されます。この設定は正しくなります。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept) - [信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.3/reliability-patterns) - [On-Error スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/on-error-scope-concept) # トランザクションの管理 トランザクションとは、結果が不確定になることができない Mule アプリケーションの操作です。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 たとえば、トランザクションを使用して、データベースに情報をコミットするためのフロー内の複数のステップをカプセル化することができます。このようなシナリオでは、コミット (トランザクション) は、全体が完了 (成功) するか、不完全に終了 (失敗) するかのどちらかとなります。部分的に完了しても、コミットは失敗となります。トランザクションが失敗すると、一部だけで部分的な完了とならないように Mule は操作をトランザクション内でロールバックします。 アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、信頼性の高いメッセージングができるように​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.4/reliability-patterns)​を実装してアプリケーションをデザインしてください。 Mule アプリケーションでトランザクションを管理するように Bitronix を設定することもできます。 ## [](#トランザクション種別)トランザクション種別 Mule は、単一リソース (ローカル、デフォルト) および拡張アーキテクチャ (​`XA`​) トランザクション種別 (​`transactionType`​) をサポートします。トランザクション種別を定義できるコンポーネントはイベントソース (たとえば、​`jms:listener`​ や ​`vm:listener`​) と Try スコープのみです。 次の表で、各トランザクション種別の特性とトランザクションを結合するための操作の要件について説明します。
トランザクション種別 特性 トランザクションを結合するための要件

単一リソース (ローカル)

  • XA トランザクションよりパフォーマンスが高くなります。

  • ネストされたトランザクションをサポートしていません。

  • 操作がトランザクションをサポートする必要があります。

  • トランザクション内のすべての操作が同じコネクタに属している必要があります。(たとえば、​jms:listener​、​jms:consume​、​jms:publish​)。

  • すべての操作で同じグローバル設定 (​config-ref​) を使用する必要があります。

拡張アーキテクチャ (XA)

  • 2 段階のコミットプロトコル (2PC) を使用します。

  • 単一リソーストランザクションより遅くなりますが、信頼性は高くなります。

  • ネストされたトランザクションをサポートしています。

  • 操作がトランザクションをサポートする必要があります。
## [](#トランザクションのアクション)トランザクションのアクション トランザクションアクション (​`transactionalAction`​) は、トランザクションに関して操作で実行できるアクションの種別を定義します。次の表で、使用可能なすべてのトランザクションアクションについて説明します。
アクション 動作 使用可能な場所

ALWAYS_BEGIN

メッセージの受信時に常に新しいトランザクションを開始します。単一リソーストランザクションが存在する場合、エラーが発生します。XA トランザクションが存在する場合、ネストされたトランザクションが作成されます。

  • トランザクションをサポートするリスナー

  • Try スコープ

ALWAYS_JOIN

メッセージの受信時に常にトランザクションが進行中であると想定します。トランザクションがない場合、エラーが発生します。

  • トランザクションをサポートする操作

BEGIN_OR_JOIN

メッセージの受信時にトランザクションが進行中である場合、可能であればトランザクションを結合します。可能でなければ新しいトランザクションを開始します。

  • Try スコープ

JOIN_IF_POSSIBLE

現在のトランザクションが使用可能な場合、そのトランザクションを結合します。可能でなければトランザクションは作成されません。

  • トランザクションをサポートする操作

INDIFFERENT

アクションをトランザクションとして扱いません。

  • Try スコープ

NONE

トランザクションを開始しません。

  • トランザクションをサポートするリスナー

NOT_SUPPORTED

存在するトランザクションの外部で実行します。

  • トランザクションをサポートする操作
## [](#イベントソースでのトランザクションの設定)イベントソースでのトランザクションの設定 トランザクションを Mule イベントソースから開始できます。この場合は、フロー全体が 1 つのトランザクションとなります。この方法は、メッセージングコネクタを使用して、メッセージングの処理中に問題が発生した場合にはメッセージをコンシュームしないようにして、後で (ロールバックによって) 再試行できるようにしたいときに便利です。 トランザクションを Mule イベントソースから開始するには、そのトランザクション種別とトランザクションアクションを設定します。 - Anypoint Studio では、次の手順を実行します。 リスナーの ​**\[Advanced (詳細)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![transaction-config-studio-vm](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/transaction-config-studio-vm.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例は、単一リソース (ローカル) トランザクションを開始するように設定された ​`vm:listener`​ イベントソースを示しています。 ```xml ``` ## [](#try-スコープでのトランザクションの設定)Try スコープでのトランザクションの設定 Mule フローは、フロー内のトランザクションを必要とする非トランザクションコネクタ (HTTP など) で開始する場合もあります。たとえば、Mule フローで外部 Web サービスから情報を受け入れ、クレジットカードに請求してインボイス情報をデータベースに保存する前にデータを変換するとします。この場合は Try スコープを使用して、クレジットカードへの請求操作とデータベースへのコミット操作をラップすることでトランザクションをセットアップすれば、常に完全な成功または完全な失敗とロールバックのどちらかの結果になることを保証できます。 トランザクション種別とトランザクションアクションを設定して、Try スコープコンポーネントでトランザクションを設定できます。 - Anypoint Studio では、次の手順を実行します。 Try スコープの ​**\[General (一般)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![transaction-config-studio](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/transaction-config-studio.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例では、Try スコープによってデータベース操作 (​`db:insert`​) と VM 操作 (​`vm:publish`​) を含むトランザクションを区分しています。プロセス全体が成功した場合は両方が適用され、Try スコープ内でエラーが発生した場合はどちらも適用されません。 ```xml INSERT INTO main_flow_audit (errorType, description) VALUES (:errorType, :description) ``` ## [](#tx_scopes_routers)トランザクションによるスコープとルーターへの影響 トランザクションスコープで実行する場合は、プロセス全体を同じスレッドで実行する必要があります。これにより、スコープの実行方法、またはトランザクションの処理方法を変更できます。以下で、トランザクションスコープで実行するときに考慮する必要があるスコープおよびルーターの動作について詳しく説明します。 ### [](#スコープ)スコープ - [Async](https://docs.mulesoft.com/jp/mule-runtime/4.4/async-scope-reference)​: トランザクション内で実行した場合、Async スコープは引き続き別のスレッドで実行されます (非同期のまま)。ただし、これはこのスコープ内のプロセッサーの実行全体がトランザクションスコープ外で行われることを意味します。そのため、Async スコープ内でエラーが発生してもロールバックにはなりません。 - [Until Successful](https://docs.mulesoft.com/jp/mule-runtime/4.4/until-successful-scope)​: トランザクション内で実行した場合、Until Successful スコープはスレッドをブロックします。つまり、Until Successful スコープが再試行間の遅延を実行している間、この実行によって使用されるスレッドを使用して他の要求を処理することはできません。 - [Parallel Foreach](https://docs.mulesoft.com/jp/mule-runtime/4.4/parallel-foreach-scope)​: トランザクション内で実行した場合、Parallel Foreach スコープは並列で実行されません。つまり、Foreach スコープとして実行することになります。コレクションの 2 番目の要素は最初の要素が完了した後に処理されます。これは、このスコープによるエラーの処理に影響を及ぼしません。 - [Batch Processing](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-processing-concept)​: Batch Processing は Async スコープとして並列で機能するように設計されており、すべてのレコードはトランザクションとして扱われるため (内部 Batch トランザクションを含む)、Batch 実行はトランザクションの一部ではありません。 ### [](#ルーター)ルーター - [Scatter Gather](https://docs.mulesoft.com/jp/mule-runtime/4.4/scatter-gather-concept)​: トランザクション内で実行した場合、Scatter Gather は並列で実行されません。つまり、2 番目のルーターは最初のルーターが処理された後で実行され、3 番目のルーターは 2 番目のルーターの後で実行される、といった具合になります。 これは、このコンポーネントによるエラーの処理に影響を及ぼしません。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.4/flowref-about)​: 実行中のフロー (またはサブフロー) がトランザクション内で実行されている場合、Flow Reference コンポーネントによって参照先のフロー (またはサブフロー) の実行は同じトランザクションで続行されます。参照先のフローにトランザクションを開始する Mule イベントソースがある場合 (たとえば、​`transactionalAction="ALWAYS_BEGIN"`​ の ​`jms:listener`​ ソース)、​`transactionalAction`​ は無視されます。Flow Reference コンポーネントは、そのイベントソースを除いて参照先のフローコンポーネントを実行します。 その他のルーターまたはスコープ (たとえば、Foreach) はトランザクションで続行され、その動作は変更されません。 ## [](#エラー処理)エラー処理 トランザクション中にエラーが発生した場合、アプリケーションはエラーを処理して続行するか、ロールバックを実行する必要があります。 エラーハンドラーには 2 つの種別があり、トランザクション中にエラーが発生したときの動作が異なります。 - On Error Propagate - `on-error-propagate`​ エラーハンドラーがトランザクションを開始したコンポーネントに対応する ​`error-handler`​ スコープ内にある場合: `on-error-propagate`​ スコープのプロセッサーを実行する前にトランザクションがロールバックされます。つまり、エラーハンドラー内のプロセッサーはトランザクション内で実行されません。 - `on-error-propagate`​ エラーハンドラーがトランザクションを開始しなかった要素内にある場合: トランザクションはロールバックされず、​`on-error-propagate`​ エラーハンドラー内のプロセッサーはトランザクション内で実行されます。一部のスコープやルーターでは、トランザクション内で実行したときに動作が異なります。 - On Error Continue エラーが処理され、トランザクションはアクティブなままになり、コミット可能です。​`on-error-continue`​ 内のプロセッサーはトランザクション内で実行されます。 ### [](#例-try-スコープでのエラー発生)例: Try スコープでのエラー発生 イベントソース (​`jms:listener`​) がトランザクションを開始し、このトランザクションが Try スコープによって続行される (​`transactionalAction`​ はデフォルトの ​`INDIFFERENT`​ に設定) 例について考えてみます。 エラーが発生すると、最初に Try スコープの ​`error-handler`​ によって処理されます。エラーは ​`on-error-propagate`​ エラーハンドラーによって処理されますが、トランザクションを開始したのが Try スコープではないため、トランザクションはロールバックされません。トランザクションはフローレベルで (そのイベントソースから) 開始されたため、トランザクションをロールバックできるのはフローエラーハンドラーのみです。 `on-error-propagate`​ エラーハンドラー内の ​`jms:publish`​ 操作はトランザクションを結合します。次にエラーはフロー ​`error-handler`​ に伝播され、このフローが ​`on-error-continue`​ エラーハンドラーを使用してエラーを処理します。​`on-error-continue`​ エラーハンドラー内の ​`jms:consume`​ 操作はトランザクション内で実行されます。最後に、トランザクションがコミットされます。 ```xml ``` 前の例で ​`on-error-continue`​ エラーハンドラーを ​`on-error-propagate`​ エラーハンドラーに置き換えると、プロセッサーの実行前にトランザクションがロールバックされます。このシナリオでは、​`jms:consume`​ 操作はトランザクションを結合できないため、この設定は正しくありません。 ### [](#例-参照先のフローでのエラー発生)例: 参照先のフローでのエラー発生 次の例の動作は前の例と同じですが、Try スコープの代わりに Flow Reference を使用し、参照先のフローでエラーが発生します。 ```xml ``` `someFlowContinuesTx`​ フローがトランザクションを開始したのではないため、そのエラーハンドラーはトランザクションをロールバックしません。 ### [](#例-エラーハンドラーの比較)例: エラーハンドラーの比較 この例は、​`on-error-continue`​ エラーハンドラーと ​`on-error-propagate`​ エラーハンドラーの違いを示しています。 ```xml ``` `flow1`​ で、​`on-error-continue`​ エラーハンドラーはトランザクションをアクティブに保ちますが、その中の Try スコープは新しいトランザクションを開始しようとします。この設定は有効ではなく、エラーが発生します。 `flow2`​ で、​`on-error-propagate`​ エラーハンドラーがトランザクションをロールバックし、​`on-error-propagate`​ エラーハンドラー内のプロセッサーが実行され、トランザクションが新規作成されます。この設定は正しくなります。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept) - [信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.4/reliability-patterns) - [On-Error スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/on-error-scope-concept) # トランザクションの管理 トランザクションとは、結果が不確定になることができない Mule アプリケーションの操作です。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 たとえば、トランザクションを使用して、データベースに情報をコミットするためのフロー内の複数のステップをカプセル化することができます。このようなシナリオでは、コミット (トランザクション) は、全体が完了 (成功) するか、不完全に終了 (失敗) するかのどちらかとなります。部分的に完了しても、コミットは失敗となります。トランザクションが失敗すると、一部だけで部分的な完了とならないように Mule は操作をトランザクション内でロールバックします。 アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、信頼性の高いメッセージングができるように​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.5/reliability-patterns)​を実装してアプリケーションをデザインしてください。 Mule アプリケーションでトランザクションを管理するように Bitronix を設定することもできます。 ## [](#トランザクション種別)トランザクション種別 Mule は、単一リソース (ローカル、デフォルト) および拡張アーキテクチャ (​`XA`​) トランザクション種別 (​`transactionType`​) をサポートします。トランザクション種別を定義できるコンポーネントはイベントソース (たとえば、​`jms:listener`​ や ​`vm:listener`​) と Try スコープのみです。 次の表で、各トランザクション種別の特性とトランザクションを結合するための操作の要件について説明します。
トランザクション種別 特性 トランザクションを結合するための要件

単一リソース (ローカル)

  • XA トランザクションよりパフォーマンスが高くなります。

  • ネストされたトランザクションをサポートしていません。

  • 操作がトランザクションをサポートする必要があります。

  • トランザクション内のすべての操作が同じコネクタに属している必要があります。(たとえば、​jms:listener​、​jms:consume​、​jms:publish​)。

  • すべての操作で同じグローバル設定 (​config-ref​) を使用する必要があります。

拡張アーキテクチャ (XA)

  • 2 段階のコミットプロトコル (2PC) を使用します。

  • 単一リソーストランザクションより遅くなりますが、信頼性は高くなります。

  • ネストされたトランザクションをサポートしています。

  • 操作がトランザクションをサポートする必要があります。
## [](#トランザクションのアクション)トランザクションのアクション トランザクションアクション (​`transactionalAction`​) は、トランザクションに関して操作で実行できるアクションの種別を定義します。次の表で、使用可能なすべてのトランザクションアクションについて説明します。
アクション 動作 使用可能な場所

ALWAYS_BEGIN

メッセージの受信時に常に新しいトランザクションを開始します。単一リソーストランザクションが存在する場合、エラーが発生します。XA トランザクションが存在する場合、ネストされたトランザクションが作成されます。

  • トランザクションをサポートするリスナー

  • Try スコープ

ALWAYS_JOIN

メッセージの受信時に常にトランザクションが進行中であると想定します。トランザクションがない場合、エラーが発生します。

  • トランザクションをサポートする操作

BEGIN_OR_JOIN

メッセージの受信時にトランザクションが進行中である場合、可能であればトランザクションを結合します。可能でなければ新しいトランザクションを開始します。

  • Try スコープ

JOIN_IF_POSSIBLE

現在のトランザクションが使用可能な場合、そのトランザクションを結合します。可能でなければトランザクションは作成されません。

  • トランザクションをサポートする操作

INDIFFERENT

アクションをトランザクションとして扱いません。

  • Try スコープ

NONE

トランザクションを開始しません。

  • トランザクションをサポートするリスナー

NOT_SUPPORTED

存在するトランザクションの外部で実行します。

  • トランザクションをサポートする操作
## [](#イベントソースでのトランザクションの設定)イベントソースでのトランザクションの設定 トランザクションを Mule イベントソースから開始できます。この場合は、フロー全体が 1 つのトランザクションとなります。この方法は、メッセージングコネクタを使用して、メッセージングの処理中に問題が発生した場合にはメッセージをコンシュームしないようにして、後で (ロールバックによって) 再試行できるようにしたいときに便利です。 トランザクションを Mule イベントソースから開始するには、そのトランザクション種別とトランザクションアクションを設定します。 - Anypoint Studio では、次の手順を実行します。 リスナーの ​**\[Advanced (詳細)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![transaction-config-studio-vm](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/transaction-config-studio-vm.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例は、単一リソース (ローカル) トランザクションを開始するように設定された ​`vm:listener`​ イベントソースを示しています。 ```xml ``` ## [](#try-スコープでのトランザクションの設定)Try スコープでのトランザクションの設定 Mule フローは、フロー内のトランザクションを必要とする非トランザクションコネクタ (HTTP など) で開始する場合もあります。たとえば、Mule フローで外部 Web サービスから情報を受け入れ、クレジットカードに請求してインボイス情報をデータベースに保存する前にデータを変換するとします。この場合は Try スコープを使用して、クレジットカードへの請求操作とデータベースへのコミット操作をラップすることでトランザクションをセットアップすれば、常に完全な成功または完全な失敗とロールバックのどちらかの結果になることを保証できます。 トランザクション種別とトランザクションアクションを設定して、Try スコープコンポーネントでトランザクションを設定できます。 - Anypoint Studio では、次の手順を実行します。 Try スコープの ​**\[General (一般)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![transaction-config-studio](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/transaction-config-studio.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例では、Try スコープによってデータベース操作 (​`db:insert`​) と VM 操作 (​`vm:publish`​) を含むトランザクションを区分しています。プロセス全体が成功した場合は両方が適用され、Try スコープ内でエラーが発生した場合はどちらも適用されません。 ```xml INSERT INTO main_flow_audit (errorType, description) VALUES (:errorType, :description) ``` ## [](#tx_scopes_routers)トランザクションによるスコープとルーターへの影響 トランザクションスコープで実行する場合は、プロセス全体を同じスレッドで実行する必要があります。これにより、スコープの実行方法、またはトランザクションの処理方法を変更できます。以下で、トランザクションスコープで実行するときに考慮する必要があるスコープおよびルーターの動作について詳しく説明します。 ### [](#スコープ)スコープ - [Async](https://docs.mulesoft.com/jp/mule-runtime/4.5/async-scope-reference)​: トランザクション内で実行した場合、Async スコープは引き続き別のスレッドで実行されます (非同期のまま)。ただし、これはこのスコープ内のプロセッサーの実行全体がトランザクションスコープ外で行われることを意味します。そのため、Async スコープ内でエラーが発生してもロールバックにはなりません。 - [Until Successful](https://docs.mulesoft.com/jp/mule-runtime/4.5/until-successful-scope)​: トランザクション内で実行した場合、Until Successful スコープはスレッドをブロックします。つまり、Until Successful スコープが再試行間の遅延を実行している間、この実行によって使用されるスレッドを使用して他の要求を処理することはできません。 - [Parallel Foreach](https://docs.mulesoft.com/jp/mule-runtime/4.5/parallel-foreach-scope)​: トランザクション内で実行した場合、Parallel Foreach スコープは並列で実行されません。つまり、Foreach スコープとして実行することになります。コレクションの 2 番目の要素は最初の要素が完了した後に処理されます。これは、このスコープによるエラーの処理に影響を及ぼしません。 - [Batch Processing](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-processing-concept)​: Batch Processing は Async スコープとして並列で機能するように設計されており、すべてのレコードはトランザクションとして扱われるため (内部 Batch トランザクションを含む)、Batch 実行はトランザクションの一部ではありません。 ### [](#ルーター)ルーター - [Scatter Gather](https://docs.mulesoft.com/jp/mule-runtime/4.5/scatter-gather-concept)​: トランザクション内で実行した場合、Scatter Gather は並列で実行されません。つまり、2 番目のルーターは最初のルーターが処理された後で実行され、3 番目のルーターは 2 番目のルーターの後で実行される、といった具合になります。これは、このコンポーネントによるエラーの処理に影響を及ぼしません。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.5/flowref-about)​: 実行中のフロー (またはサブフロー) がトランザクション内で実行されている場合、Flow Reference コンポーネントによって参照先のフロー (またはサブフロー) の実行は同じトランザクションで続行されます。参照先のフローにトランザクションを開始する Mule イベントソースがある場合 (たとえば、​`transactionalAction="ALWAYS_BEGIN"`​ の ​`jms:listener`​ ソース)、​`transactionalAction`​ は無視されます。Flow Reference コンポーネントは、そのイベントソースを除いて参照先のフローコンポーネントを実行します。 その他のルーターまたはスコープ (たとえば、Foreach) はトランザクションで続行され、その動作は変更されません。 ## [](#エラー処理)エラー処理 トランザクション中にエラーが発生した場合、アプリケーションはエラーを処理して続行するか、ロールバックを実行する必要があります。 エラーハンドラーには 2 つの種別があり、トランザクション中にエラーが発生したときの動作が異なります。 - On Error Propagate - `on-error-propagate`​ エラーハンドラーがトランザクションを開始したコンポーネントに対応する ​`error-handler`​ スコープ内にある場合: `on-error-propagate`​ スコープのプロセッサーを実行する前にトランザクションがロールバックされます。つまり、エラーハンドラー内のプロセッサーはトランザクション内で実行されません。 - `on-error-propagate`​ エラーハンドラーがトランザクションを開始しなかった要素内にある場合: トランザクションはロールバックされず、​`on-error-propagate`​ エラーハンドラー内のプロセッサーはトランザクション内で実行されます。一部のスコープやルーターでは、トランザクション内で実行したときに動作が異なります。 - On Error Continue エラーが処理され、トランザクションはアクティブなままになり、コミット可能です。​`on-error-continue`​ 内のプロセッサーはトランザクション内で実行されます。 ### [](#例-try-スコープでのエラー発生)例: Try スコープでのエラー発生 イベントソース (​`jms:listener`​) がトランザクションを開始し、このトランザクションが Try スコープによって続行される (​`transactionalAction`​ はデフォルトの ​`INDIFFERENT`​ に設定) 例について考えてみます。 エラーが発生すると、最初に Try スコープの ​`error-handler`​ によって処理されます。エラーは ​`on-error-propagate`​ エラーハンドラーによって処理されますが、トランザクションを開始したのが Try スコープではないため、トランザクションはロールバックされません。トランザクションはフローレベルで (そのイベントソースから) 開始されたため、トランザクションをロールバックできるのはフローエラーハンドラーのみです。 `on-error-propagate`​ エラーハンドラー内の ​`jms:publish`​ 操作はトランザクションを結合します。次にエラーはフロー ​`error-handler`​ に伝播され、このフローが ​`on-error-continue`​ エラーハンドラーを使用してエラーを処理します。​`on-error-continue`​ エラーハンドラー内の ​`jms:consume`​ 操作はトランザクション内で実行されます。最後に、トランザクションがコミットされます。 ```xml ``` 前の例で ​`on-error-continue`​ エラーハンドラーを ​`on-error-propagate`​ エラーハンドラーに置き換えると、プロセッサーの実行前にトランザクションがロールバックされます。このシナリオでは、​`jms:consume`​ 操作はトランザクションを結合できないため、この設定は正しくありません。 ### [](#例-参照先のフローでのエラー発生)例: 参照先のフローでのエラー発生 次の例の動作は前の例と同じですが、Try スコープの代わりに Flow Reference を使用し、参照先のフローでエラーが発生します。 ```xml ``` `someFlowContinuesTx`​ フローがトランザクションを開始したのではないため、そのエラーハンドラーはトランザクションをロールバックしません。 ### [](#例-エラーハンドラーの比較)例: エラーハンドラーの比較 この例は、​`on-error-continue`​ エラーハンドラーと ​`on-error-propagate`​ エラーハンドラーの違いを示しています。 ```xml ``` `flow1`​ で、​`on-error-continue`​ エラーハンドラーはトランザクションをアクティブに保ちますが、その中の Try スコープは新しいトランザクションを開始しようとします。この設定は有効ではなく、エラーが発生します。 `flow2`​ で、​`on-error-propagate`​ エラーハンドラーがトランザクションをロールバックし、​`on-error-propagate`​ エラーハンドラー内のプロセッサーが実行され、トランザクションが新規作成されます。この設定は正しくなります。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept) - [信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.5/reliability-patterns) - [On-Error スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/on-error-scope-concept) # トランザクションの管理 トランザクションとは、結果が不確定になることができない Mule アプリケーションの操作です。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 たとえば、トランザクションを使用して、データベースに情報をコミットするためのフロー内の複数のステップをカプセル化することができます。このようなシナリオでは、コミット (トランザクション) は、全体が完了 (成功) するか、不完全に終了 (失敗) するかのどちらかとなります。部分的に完了しても、コミットは失敗となります。トランザクションが失敗すると、一部だけで部分的な完了とならないように Mule は操作をトランザクション内でロールバックします。 アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、信頼性の高いメッセージングができるように​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.6/reliability-patterns)​を実装してアプリケーションをデザインしてください。 Mule アプリケーションでトランザクションを管理するように Bitronix を設定することもできます。 ## [](#トランザクション種別)トランザクション種別 Mule は、単一リソース (ローカル、デフォルト) および拡張アーキテクチャ (​`XA`​) トランザクション種別 (​`transactionType`​) をサポートします。トランザクション種別を定義できるコンポーネントはイベントソース (たとえば、​`jms:listener`​ や ​`vm:listener`​) と Try スコープのみです。 次の表で、各トランザクション種別の特性とトランザクションを結合するための操作の要件について説明します。
トランザクション種別 特性 トランザクションを結合するための要件

単一リソース (ローカル)

  • XA トランザクションよりパフォーマンスが高くなります。

  • ネストされたトランザクションをサポートしていません。

  • 操作がトランザクションをサポートする必要があります。

  • トランザクション内のすべての操作が同じコネクタに属している必要があります。(たとえば、​jms:listener​、​jms:consume​、​jms:publish​)。

  • すべての操作で同じグローバル設定 (​config-ref​) を使用する必要があります。

拡張アーキテクチャ (XA)

  • 2 段階のコミットプロトコル (2PC) を使用します。

  • 単一リソーストランザクションより遅くなりますが、信頼性は高くなります。

  • ネストされたトランザクションをサポートしています。

  • 操作がトランザクションをサポートする必要があります。
## [](#トランザクションのアクション)トランザクションのアクション トランザクションアクション (​`transactionalAction`​) は、トランザクションに関して操作で実行できるアクションの種別を定義します。次の表で、使用可能なすべてのトランザクションアクションについて説明します。
アクション 動作 使用可能な場所

ALWAYS_BEGIN

メッセージの受信時に常に新しいトランザクションを開始します。単一リソーストランザクションが存在する場合、エラーが発生します。XA トランザクションが存在する場合、ネストされたトランザクションが作成されます。

  • トランザクションをサポートするリスナー

  • Try スコープ

ALWAYS_JOIN

メッセージの受信時に常にトランザクションが進行中であると想定します。トランザクションがない場合、エラーが発生します。

  • トランザクションをサポートする操作

BEGIN_OR_JOIN

メッセージの受信時にトランザクションが進行中である場合、可能であればトランザクションを結合します。可能でなければ新しいトランザクションを開始します。

  • Try スコープ

JOIN_IF_POSSIBLE

現在のトランザクションが使用可能な場合、そのトランザクションを結合します。可能でなければトランザクションは作成されません。

  • トランザクションをサポートする操作

INDIFFERENT

アクションをトランザクションとして扱いません。

  • Try スコープ

NONE

トランザクションを開始しません。

  • トランザクションをサポートするリスナー

NOT_SUPPORTED

存在するトランザクションの外部で実行します。

  • トランザクションをサポートする操作
## [](#イベントソースでのトランザクションの設定)イベントソースでのトランザクションの設定 トランザクションを Mule イベントソースから開始できます。この場合は、フロー全体が 1 つのトランザクションとなります。この方法は、メッセージングコネクタを使用して、メッセージングの処理中に問題が発生した場合にはメッセージをコンシュームしないようにして、後で (ロールバックによって) 再試行できるようにしたいときに便利です。 トランザクションを Mule イベントソースから開始するには、そのトランザクション種別とトランザクションアクションを設定します。 - Anypoint Studio では、次の手順を実行します。 リスナーの ​**\[Advanced (詳細)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![transaction-config-studio-vm](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/transaction-config-studio-vm.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例は、単一リソース (ローカル) トランザクションを開始するように設定された ​`vm:listener`​ イベントソースを示しています。 ```xml ``` ## [](#try-スコープでのトランザクションの設定)Try スコープでのトランザクションの設定 Mule フローは、フロー内のトランザクションを必要とする非トランザクションコネクタ (HTTP など) で開始する場合もあります。たとえば、Mule フローで外部 Web サービスから情報を受け入れ、クレジットカードに請求してインボイス情報をデータベースに保存する前にデータを変換するとします。この場合は Try スコープを使用して、クレジットカードへの請求操作とデータベースへのコミット操作をラップすることでトランザクションをセットアップすれば、常に完全な成功または完全な失敗とロールバックのどちらかの結果になることを保証できます。 トランザクション種別とトランザクションアクションを設定して、Try スコープコンポーネントでトランザクションを設定できます。 - Anypoint Studio では、次の手順を実行します。 Try スコープの ​**\[General (一般)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![transaction-config-studio](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/transaction-config-studio.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例では、Try スコープによってデータベース操作 (​`db:insert`​) と VM 操作 (​`vm:publish`​) を含むトランザクションを区分しています。プロセス全体が成功した場合は両方が適用され、Try スコープ内でエラーが発生した場合はどちらも適用されません。 ```xml INSERT INTO main_flow_audit (errorType, description) VALUES (:errorType, :description) ``` ## [](#tx_scopes_routers)トランザクションによるスコープとルーターへの影響 トランザクションスコープで実行する場合は、プロセス全体を同じスレッドで実行する必要があります。これにより、スコープの実行方法、またはトランザクションの処理方法を変更できます。以下で、トランザクションスコープで実行するときに考慮する必要があるスコープおよびルーターの動作について詳しく説明します。 ### [](#スコープ)スコープ - [Async](https://docs.mulesoft.com/jp/mule-runtime/4.6/async-scope-reference)​: トランザクション内で実行した場合、Async スコープは引き続き別のスレッドで実行されます (非同期のまま)。ただし、これはこのスコープ内のプロセッサーの実行全体がトランザクションスコープ外で行われることを意味します。そのため、Async スコープ内でエラーが発生してもロールバックにはなりません。 - [Until Successful](https://docs.mulesoft.com/jp/mule-runtime/4.6/until-successful-scope)​: トランザクション内で実行した場合、Until Successful スコープはスレッドをブロックします。つまり、Until Successful スコープが再試行間の遅延を実行している間、この実行によって使用されるスレッドを使用して他の要求を処理することはできません。 - [Parallel Foreach](https://docs.mulesoft.com/jp/mule-runtime/4.6/parallel-foreach-scope)​: トランザクション内で実行した場合、Parallel Foreach スコープは並列で実行されません。つまり、Foreach スコープとして実行することになります。コレクションの 2 番目の要素は最初の要素が完了した後に処理されます。これは、このスコープによるエラーの処理に影響を及ぼしません。 - [Batch Processing](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-processing-concept)​: Batch Processing は Async スコープとして並列で機能するように設計されており、すべてのレコードはトランザクションとして扱われるため (内部 Batch トランザクションを含む)、Batch 実行はトランザクションの一部ではありません。 ### [](#ルーター)ルーター - [Scatter Gather](https://docs.mulesoft.com/jp/mule-runtime/4.6/scatter-gather-concept)​: トランザクション内で実行した場合、Scatter Gather は並列で実行されません。つまり、2 番目のルーターは最初のルーターが処理された後で実行され、3 番目のルーターは 2 番目のルーターの後で実行される、といった具合になります。 これは、このコンポーネントによるエラーの処理に影響を及ぼしません。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.6/flowref-about)​: 実行中のフロー (またはサブフロー) がトランザクション内で実行されている場合、Flow Reference コンポーネントによって参照先のフロー (またはサブフロー) の実行は同じトランザクションで続行されます。参照先のフローにトランザクションを開始する Mule イベントソースがある場合 (たとえば、​`transactionalAction="ALWAYS_BEGIN"`​ の ​`jms:listener`​ ソース)、​`transactionalAction`​ は無視されます。Flow Reference コンポーネントは、そのイベントソースを除いて参照先のフローコンポーネントを実行します。 その他のルーターまたはスコープ (たとえば、Foreach) はトランザクションで続行され、その動作は変更されません。 ## [](#エラー処理)エラー処理 トランザクション中にエラーが発生した場合、アプリケーションはエラーを処理して続行するか、ロールバックを実行する必要があります。 エラーハンドラーには 2 つの種別があり、トランザクション中にエラーが発生したときの動作が異なります。 - On Error Propagate - `on-error-propagate`​ エラーハンドラーがトランザクションを開始したコンポーネントに対応する ​`error-handler`​ スコープ内にある場合: `on-error-propagate`​ スコープのプロセッサーを実行する前にトランザクションがロールバックされます。つまり、エラーハンドラー内のプロセッサーはトランザクション内で実行されません。 - `on-error-propagate`​ エラーハンドラーがトランザクションを開始しなかった要素内にある場合: トランザクションはロールバックされず、​`on-error-propagate`​ エラーハンドラー内のプロセッサーはトランザクション内で実行されます。一部のスコープやルーターでは、トランザクション内で実行したときに動作が異なります。 - On Error Continue エラーが処理され、トランザクションはアクティブなままになり、コミット可能です。​`on-error-continue`​ 内のプロセッサーはトランザクション内で実行されます。 ### [](#例-try-スコープでのエラー発生)例: Try スコープでのエラー発生 イベントソース (​`jms:listener`​) がトランザクションを開始し、このトランザクションが Try スコープによって続行される (​`transactionalAction`​ はデフォルトの ​`INDIFFERENT`​ に設定) 例について考えてみます。 エラーが発生すると、最初に Try スコープの ​`error-handler`​ によって処理されます。エラーは ​`on-error-propagate`​ エラーハンドラーによって処理されますが、トランザクションを開始したのが Try スコープではないため、トランザクションはロールバックされません。トランザクションはフローレベルで (そのイベントソースから) 開始されたため、トランザクションをロールバックできるのはフローエラーハンドラーのみです。 `on-error-propagate`​ エラーハンドラー内の ​`jms:publish`​ 操作はトランザクションを結合します。次にエラーはフロー ​`error-handler`​ に伝播され、このフローが ​`on-error-continue`​ エラーハンドラーを使用してエラーを処理します。​`on-error-continue`​ エラーハンドラー内の ​`jms:consume`​ 操作はトランザクション内で実行されます。最後に、トランザクションがコミットされます。 ```xml ``` 前の例で ​`on-error-continue`​ エラーハンドラーを ​`on-error-propagate`​ エラーハンドラーに置き換えると、プロセッサーの実行前にトランザクションがロールバックされます。このシナリオでは、​`jms:consume`​ 操作はトランザクションを結合できないため、この設定は正しくありません。 ### [](#例-参照先のフローでのエラー発生)例: 参照先のフローでのエラー発生 次の例の動作は前の例と同じですが、Try スコープの代わりに Flow Reference を使用し、参照先のフローでエラーが発生します。 ```xml ``` `someFlowContinuesTx`​ フローがトランザクションを開始したのではないため、そのエラーハンドラーはトランザクションをロールバックしません。 ### [](#例-エラーハンドラーの比較)例: エラーハンドラーの比較 この例は、​`on-error-continue`​ エラーハンドラーと ​`on-error-propagate`​ エラーハンドラーの違いを示しています。 ```xml ``` `flow1`​ で、​`on-error-continue`​ エラーハンドラーはトランザクションをアクティブに保ちますが、その中の Try スコープは新しいトランザクションを開始しようとします。この設定は有効ではなく、エラーが発生します。 `flow2`​ で、​`on-error-propagate`​ エラーハンドラーがトランザクションをロールバックし、​`on-error-propagate`​ エラーハンドラー内のプロセッサーが実行され、トランザクションが新規作成されます。この設定は正しくなります。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept) - [信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.6/reliability-patterns) - [On-Error スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/on-error-scope-concept) # トランザクションの管理 トランザクションとは、結果が不確定になることができない Mule アプリケーションの操作です。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 たとえば、トランザクションを使用して、データベースに情報をコミットするためのフロー内の複数のステップをカプセル化することができます。このようなシナリオでは、コミット (トランザクション) は、全体が完了 (成功) するか、不完全に終了 (失敗) するかのどちらかとなります。部分的に完了しても、コミットは失敗となります。トランザクションが失敗すると、一部だけで部分的な完了とならないように Mule は操作をトランザクション内でロールバックします。 アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、信頼性の高いメッセージングができるように​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.7/reliability-patterns)​を実装してアプリケーションをデザインしてください。 Mule アプリケーションでトランザクションを管理するように Bitronix を設定することもできます。 ## [](#トランザクション種別)トランザクション種別 Mule は、単一リソース (ローカル、デフォルト) および拡張アーキテクチャ (​`XA`​) トランザクション種別 (​`transactionType`​) をサポートします。トランザクション種別を定義できるコンポーネントはイベントソース (たとえば、​`jms:listener`​ や ​`vm:listener`​) と Try スコープのみです。 次の表で、各トランザクション種別の特性とトランザクションを結合するための操作の要件について説明します。
トランザクション種別 特性 トランザクションを結合するための要件

単一リソース (ローカル)

  • XA トランザクションよりパフォーマンスが高くなります。

  • ネストされたトランザクションをサポートしていません。

  • 操作がトランザクションをサポートする必要があります。

  • トランザクション内のすべての操作が同じコネクタに属している必要があります。(たとえば、​jms:listener​、​jms:consume​、​jms:publish​)。

  • すべての操作で同じグローバル設定 (​config-ref​) を使用する必要があります。

拡張アーキテクチャ (XA)

  • 2 段階のコミットプロトコル (2PC) を使用します。

  • 単一リソーストランザクションより遅くなりますが、信頼性は高くなります。

  • ネストされたトランザクションをサポートしています。

  • 操作がトランザクションをサポートする必要があります。
## [](#トランザクションのアクション)トランザクションのアクション トランザクションアクション (​`transactionalAction`​) は、トランザクションに関して操作で実行できるアクションの種別を定義します。次の表で、使用可能なすべてのトランザクションアクションについて説明します。
アクション 動作 使用可能な場所

ALWAYS_BEGIN

メッセージの受信時に常に新しいトランザクションを開始します。単一リソーストランザクションが存在する場合、エラーが発生します。XA トランザクションが存在する場合、ネストされたトランザクションが作成されます。

  • トランザクションをサポートするリスナー

  • Try スコープ

ALWAYS_JOIN

メッセージの受信時に常にトランザクションが進行中であると想定します。トランザクションがない場合、エラーが発生します。

  • トランザクションをサポートする操作

BEGIN_OR_JOIN

メッセージの受信時にトランザクションが進行中である場合、可能であればトランザクションを結合します。可能でなければ新しいトランザクションを開始します。

  • Try スコープ

JOIN_IF_POSSIBLE

現在のトランザクションが使用可能な場合、そのトランザクションを結合します。可能でなければトランザクションは作成されません。

  • トランザクションをサポートする操作

INDIFFERENT

アクションをトランザクションとして扱いません。

  • Try スコープ

NONE

トランザクションを開始しません。

  • トランザクションをサポートするリスナー

NOT_SUPPORTED

存在するトランザクションの外部で実行します。

  • トランザクションをサポートする操作
## [](#イベントソースでのトランザクションの設定)イベントソースでのトランザクションの設定 トランザクションを Mule イベントソースから開始できます。この場合は、フロー全体が 1 つのトランザクションとなります。この方法は、メッセージングコネクタを使用して、メッセージングの処理中に問題が発生した場合にはメッセージをコンシュームしないようにして、後で (ロールバックによって) 再試行できるようにしたいときに便利です。 トランザクションを Mule イベントソースから開始するには、そのトランザクション種別とトランザクションアクションを設定します。 - Anypoint Studio では、次の手順を実行します。 リスナーの ​**\[Advanced (詳細)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![transaction-config-studio-vm](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/transaction-config-studio-vm.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例は、単一リソース (ローカル) トランザクションを開始するように設定された ​`vm:listener`​ イベントソースを示しています。 ```xml ``` ## [](#try-スコープでのトランザクションの設定)Try スコープでのトランザクションの設定 Mule フローは、フロー内のトランザクションを必要とする非トランザクションコネクタ (HTTP など) で開始する場合もあります。たとえば、Mule フローで外部 Web サービスから情報を受け入れ、クレジットカードに請求してインボイス情報をデータベースに保存する前にデータを変換するとします。この場合は Try スコープを使用して、クレジットカードへの請求操作とデータベースへのコミット操作をラップすることでトランザクションをセットアップすれば、常に完全な成功または完全な失敗とロールバックのどちらかの結果になることを保証できます。 トランザクション種別とトランザクションアクションを設定して、Try スコープコンポーネントでトランザクションを設定できます。 - Anypoint Studio では、次の手順を実行します。 Try スコープの ​**\[General (一般)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![transaction-config-studio](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/transaction-config-studio.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例では、Try スコープによってデータベース操作 (​`db:insert`​) と VM 操作 (​`vm:publish`​) を含むトランザクションを区分しています。プロセス全体が成功した場合は両方が適用され、Try スコープ内でエラーが発生した場合はどちらも適用されません。 ```xml INSERT INTO main_flow_audit (errorType, description) VALUES (:errorType, :description) ``` ## [](#tx_scopes_routers)トランザクションによるスコープとルーターへの影響 トランザクションスコープで実行する場合は、プロセス全体を同じスレッドで実行する必要があります。これにより、スコープの実行方法、またはトランザクションの処理方法を変更できます。以下で、トランザクションスコープで実行するときに考慮する必要があるスコープおよびルーターの動作について詳しく説明します。 ### [](#スコープ)スコープ - [Async](https://docs.mulesoft.com/jp/mule-runtime/4.7/async-scope-reference)​: トランザクション内で実行した場合、Async スコープは引き続き別のスレッドで実行されます (非同期のまま)。ただし、これはこのスコープ内のプロセッサーの実行全体がトランザクションスコープ外で行われることを意味します。そのため、Async スコープ内でエラーが発生してもロールバックにはなりません。 - [Until Successful](https://docs.mulesoft.com/jp/mule-runtime/4.7/until-successful-scope)​: トランザクション内で実行した場合、Until Successful スコープはスレッドをブロックします。つまり、Until Successful スコープが再試行間の遅延を実行している間、この実行によって使用されるスレッドを使用して他の要求を処理することはできません。 - [Parallel Foreach](https://docs.mulesoft.com/jp/mule-runtime/4.7/parallel-foreach-scope)​: トランザクション内で実行した場合、Parallel Foreach スコープは並列で実行されません。つまり、Foreach スコープとして実行することになります。コレクションの 2 番目の要素は最初の要素が完了した後に処理されます。これは、このスコープによるエラーの処理に影響を及ぼしません。 - [Batch Processing](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-processing-concept)​: Batch Processing は Async スコープとして並列で機能するように設計されており、すべてのレコードはトランザクションとして扱われるため (内部 Batch トランザクションを含む)、Batch 実行はトランザクションの一部ではありません。 ### [](#ルーター)ルーター - [Scatter Gather](https://docs.mulesoft.com/jp/mule-runtime/4.7/scatter-gather-concept)​: トランザクション内で実行した場合、Scatter Gather は並列で実行されません。つまり、2 番目のルーターは最初のルーターが処理された後で実行され、3 番目のルーターは 2 番目のルーターの後で実行される、といった具合になります。 これは、このコンポーネントによるエラーの処理に影響を及ぼしません。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.7/flowref-about)​: 実行中のフロー (またはサブフロー) がトランザクション内で実行されている場合、Flow Reference コンポーネントによって参照先のフロー (またはサブフロー) の実行は同じトランザクションで続行されます。参照先のフローにトランザクションを開始する Mule イベントソースがある場合 (たとえば、​`transactionalAction="ALWAYS_BEGIN"`​ の ​`jms:listener`​ ソース)、​`transactionalAction`​ は無視されます。Flow Reference コンポーネントは、そのイベントソースを除いて参照先のフローコンポーネントを実行します。 その他のルーターまたはスコープ (たとえば、Foreach) はトランザクションで続行され、その動作は変更されません。 ## [](#エラー処理)エラー処理 トランザクション中にエラーが発生した場合、アプリケーションはエラーを処理して続行するか、ロールバックを実行する必要があります。 エラーハンドラーには 2 つの種別があり、トランザクション中にエラーが発生したときの動作が異なります。 - On Error Propagate - `on-error-propagate`​ エラーハンドラーがトランザクションを開始したコンポーネントに対応する ​`error-handler`​ スコープ内にある場合: `on-error-propagate`​ スコープのプロセッサーを実行する前にトランザクションがロールバックされます。つまり、エラーハンドラー内のプロセッサーはトランザクション内で実行されません。 - `on-error-propagate`​ エラーハンドラーがトランザクションを開始しなかった要素内にある場合: トランザクションはロールバックされず、​`on-error-propagate`​ エラーハンドラー内のプロセッサーはトランザクション内で実行されます。一部のスコープやルーターでは、トランザクション内で実行したときに動作が異なります。 - On Error Continue エラーが処理され、トランザクションはアクティブなままになり、コミット可能です。​`on-error-continue`​ 内のプロセッサーはトランザクション内で実行されます。 ### [](#例-try-スコープでのエラー発生)例: Try スコープでのエラー発生 イベントソース (​`jms:listener`​) がトランザクションを開始し、このトランザクションが Try スコープによって続行される (​`transactionalAction`​ はデフォルトの ​`INDIFFERENT`​ に設定) 例について考えてみます。 エラーが発生すると、最初に Try スコープの ​`error-handler`​ によって処理されます。エラーは ​`on-error-propagate`​ エラーハンドラーによって処理されますが、トランザクションを開始したのが Try スコープではないため、トランザクションはロールバックされません。トランザクションはフローレベルで (そのイベントソースから) 開始されたため、トランザクションをロールバックできるのはフローエラーハンドラーのみです。 `on-error-propagate`​ エラーハンドラー内の ​`jms:publish`​ 操作はトランザクションを結合します。次にエラーはフロー ​`error-handler`​ に伝播され、このフローが ​`on-error-continue`​ エラーハンドラーを使用してエラーを処理します。​`on-error-continue`​ エラーハンドラー内の ​`jms:consume`​ 操作はトランザクション内で実行されます。最後に、トランザクションがコミットされます。 ```xml ``` 前の例で ​`on-error-continue`​ エラーハンドラーを ​`on-error-propagate`​ エラーハンドラーに置き換えると、プロセッサーの実行前にトランザクションがロールバックされます。このシナリオでは、​`jms:consume`​ 操作はトランザクションを結合できないため、この設定は正しくありません。 ### [](#例-参照先のフローでのエラー発生)例: 参照先のフローでのエラー発生 次の例の動作は前の例と同じですが、Try スコープの代わりに Flow Reference を使用し、参照先のフローでエラーが発生します。 ```xml ``` `someFlowContinuesTx`​ フローがトランザクションを開始したのではないため、そのエラーハンドラーはトランザクションをロールバックしません。 ### [](#例-エラーハンドラーの比較)例: エラーハンドラーの比較 この例は、​`on-error-continue`​ エラーハンドラーと ​`on-error-propagate`​ エラーハンドラーの違いを示しています。 ```xml ``` `flow1`​ で、​`on-error-continue`​ エラーハンドラーはトランザクションをアクティブに保ちますが、その中の Try スコープは新しいトランザクションを開始しようとします。この設定は有効ではなく、エラーが発生します。 `flow2`​ で、​`on-error-propagate`​ エラーハンドラーがトランザクションをロールバックし、​`on-error-propagate`​ エラーハンドラー内のプロセッサーが実行され、トランザクションが新規作成されます。この設定は正しくなります。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept) - [信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.7/reliability-patterns) - [On-Error スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/on-error-scope-concept) # トランザクションの管理 トランザクションとは、結果が不確定になることができない Mule アプリケーションの操作です。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 たとえば、トランザクションを使用して、データベースに情報をコミットするためのフロー内の複数のステップをカプセル化することができます。このようなシナリオでは、コミット (トランザクション) は、全体が完了 (成功) するか、不完全に終了 (失敗) するかのどちらかとなります。部分的に完了しても、コミットは失敗となります。トランザクションが失敗すると、一部だけで部分的な完了とならないように Mule は操作をトランザクション内でロールバックします。 アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、信頼性の高いメッセージングができるように​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.8/reliability-patterns)​を実装してアプリケーションをデザインしてください。 Mule アプリケーションでトランザクションを管理するように Bitronix を設定することもできます。 ## [](#トランザクション種別)トランザクション種別 Mule は、単一リソース (ローカル、デフォルト) および拡張アーキテクチャ (​`XA`​) トランザクション種別 (​`transactionType`​) をサポートします。トランザクション種別を定義できるコンポーネントはイベントソース (たとえば、​`jms:listener`​ や ​`vm:listener`​) と Try スコープのみです。 次の表で、各トランザクション種別の特性とトランザクションを結合するための操作の要件について説明します。
トランザクション種別 特性 トランザクションを結合するための要件

単一リソース (ローカル)

  • XA トランザクションよりパフォーマンスが高くなります。

  • ネストされたトランザクションをサポートしていません。

  • 操作がトランザクションをサポートする必要があります。

  • トランザクション内のすべての操作が同じコネクタに属している必要があります。(たとえば、​jms:listener​、​jms:consume​、​jms:publish​)。

  • すべての操作で同じグローバル設定 (​config-ref​) を使用する必要があります。

拡張アーキテクチャ (XA)

  • 2 段階のコミットプロトコル (2PC) を使用します。

  • 単一リソーストランザクションより遅くなりますが、信頼性は高くなります。

  • ネストされたトランザクションをサポートしています。

  • 操作がトランザクションをサポートする必要があります。
## [](#トランザクションのアクション)トランザクションのアクション トランザクションアクション (​`transactionalAction`​) は、トランザクションに関して操作で実行できるアクションの種別を定義します。次の表で、使用可能なすべてのトランザクションアクションについて説明します。
アクション 動作 使用可能な場所

ALWAYS_BEGIN

メッセージの受信時に常に新しいトランザクションを開始します。単一リソーストランザクションが存在する場合、エラーが発生します。XA トランザクションが存在する場合、ネストされたトランザクションが作成されます。

  • トランザクションをサポートするリスナー

  • Try スコープ

ALWAYS_JOIN

メッセージの受信時に常にトランザクションが進行中であると想定します。トランザクションがない場合、エラーが発生します。

  • トランザクションをサポートする操作

BEGIN_OR_JOIN

メッセージの受信時にトランザクションが進行中である場合、可能であればトランザクションを結合します。可能でなければ新しいトランザクションを開始します。

  • Try スコープ

JOIN_IF_POSSIBLE

現在のトランザクションが使用可能な場合、そのトランザクションを結合します。可能でなければトランザクションは作成されません。

  • トランザクションをサポートする操作

INDIFFERENT

アクションをトランザクションとして扱いません。

  • Try スコープ

NONE

トランザクションを開始しません。

  • トランザクションをサポートするリスナー

NOT_SUPPORTED

存在するトランザクションの外部で実行します。

  • トランザクションをサポートする操作
## [](#イベントソースでのトランザクションの設定)イベントソースでのトランザクションの設定 トランザクションを Mule イベントソースから開始できます。この場合は、フロー全体が 1 つのトランザクションとなります。この方法は、メッセージングコネクタを使用して、メッセージングの処理中に問題が発生した場合にはメッセージをコンシュームしないようにして、後で (ロールバックによって) 再試行できるようにしたいときに便利です。 トランザクションを Mule イベントソースから開始するには、そのトランザクション種別とトランザクションアクションを設定します。 - Anypoint Studio では、次の手順を実行します。 リスナーの ​**\[Advanced (詳細)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![アクションと種別の設定が表示されているトランザクション設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/transaction-config-studio-vm.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例は、単一リソース (ローカル) トランザクションを開始するように設定された ​`vm:listener`​ イベントソースを示しています。 ```xml ``` ## [](#try-スコープでのトランザクションの設定)Try スコープでのトランザクションの設定 Mule フローは、フロー内のトランザクションを必要とする非トランザクションコネクタ (HTTP など) で開始する場合もあります。たとえば、Mule フローで外部 Web サービスから情報を受け入れ、クレジットカードに請求してインボイス情報をデータベースに保存する前にデータを変換するとします。この場合は Try スコープを使用して、クレジットカードへの請求操作とデータベースへのコミット操作をラップすることでトランザクションをセットアップすれば、常に完全な成功または完全な失敗とロールバックのどちらかの結果になることを保証できます。 トランザクション種別とトランザクションアクションを設定して、Try スコープコンポーネントでトランザクションを設定できます。 - Anypoint Studio では、次の手順を実行します。 Try スコープの ​**\[General (一般)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![アクションと種別の設定が表示されているトランザクション設定インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/transaction-config-studio.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例では、Try スコープによってデータベース操作 (​`db:insert`​) と VM 操作 (​`vm:publish`​) を含むトランザクションを区分しています。プロセス全体が成功した場合は両方が適用され、Try スコープ内でエラーが発生した場合はどちらも適用されません。 ```xml INSERT INTO main_flow_audit (errorType, description) VALUES (:errorType, :description) ``` ## [](#tx_scopes_routers)トランザクションによるスコープとルーターへの影響 トランザクションスコープで実行する場合は、プロセス全体を同じスレッドで実行する必要があります。これにより、スコープの実行方法、またはトランザクションの処理方法を変更できます。以下で、トランザクションスコープで実行するときに考慮する必要があるスコープおよびルーターの動作について詳しく説明します。 ### [](#スコープ)スコープ - [Async](https://docs.mulesoft.com/jp/mule-runtime/4.8/async-scope-reference)​: トランザクション内で実行した場合、Async スコープは引き続き別のスレッドで実行されます (非同期のまま)。ただし、これはこのスコープ内のプロセッサーの実行全体がトランザクションスコープ外で行われることを意味します。そのため、Async スコープ内でエラーが発生してもロールバックにはなりません。 - [Until Successful](https://docs.mulesoft.com/jp/mule-runtime/4.8/until-successful-scope)​: トランザクション内で実行した場合、Until Successful スコープはスレッドをブロックします。つまり、Until Successful スコープが再試行間の遅延を実行している間、この実行によって使用されるスレッドを使用して他の要求を処理することはできません。 - [Parallel Foreach](https://docs.mulesoft.com/jp/mule-runtime/4.8/parallel-foreach-scope)​: トランザクション内で実行した場合、Parallel Foreach スコープは並列で実行されません。つまり、Foreach スコープとして実行することになります。コレクションの 2 番目の要素は最初の要素が完了した後に処理されます。これは、このスコープによるエラーの処理に影響を及ぼしません。 - [Batch Processing](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-processing-concept)​: Batch Processing は Async スコープとして並列で機能するように設計されており、すべてのレコードはトランザクションとして扱われるため (内部 Batch トランザクションを含む)、Batch 実行はトランザクションの一部ではありません。 ### [](#ルーター)ルーター - [Scatter Gather](https://docs.mulesoft.com/jp/mule-runtime/4.8/scatter-gather-concept)​: トランザクション内で実行した場合、Scatter Gather は並列で実行されません。つまり、2 番目のルーターは最初のルーターが処理された後で実行され、3 番目のルーターは 2 番目のルーターの後で実行される、といった具合になります。 これは、このコンポーネントによるエラーの処理に影響を及ぼしません。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.8/flowref-about)​: 実行中のフロー (またはサブフロー) がトランザクション内で実行されている場合、Flow Reference コンポーネントによって参照先のフロー (またはサブフロー) の実行は同じトランザクションで続行されます。参照先のフローにトランザクションを開始する Mule イベントソースがある場合 (たとえば、​`transactionalAction="ALWAYS_BEGIN"`​ の ​`jms:listener`​ ソース)、​`transactionalAction`​ は無視されます。Flow Reference コンポーネントは、そのイベントソースを除いて参照先のフローコンポーネントを実行します。 その他のルーターまたはスコープ (たとえば、Foreach) はトランザクションで続行され、その動作は変更されません。 ## [](#エラー処理)エラー処理 トランザクション中にエラーが発生した場合、アプリケーションはエラーを処理して続行するか、ロールバックを実行する必要があります。 エラーハンドラーには 2 つの種別があり、トランザクション中にエラーが発生したときの動作が異なります。 - On Error Propagate - `on-error-propagate`​ エラーハンドラーがトランザクションを開始したコンポーネントに対応する ​`error-handler`​ スコープ内にある場合: `on-error-propagate`​ スコープのプロセッサーを実行する前にトランザクションがロールバックされます。つまり、エラーハンドラー内のプロセッサーはトランザクション内で実行されません。 - `on-error-propagate`​ エラーハンドラーがトランザクションを開始しなかった要素内にある場合: トランザクションはロールバックされず、​`on-error-propagate`​ エラーハンドラー内のプロセッサーはトランザクション内で実行されます。一部のスコープやルーターでは、トランザクション内で実行したときに動作が異なります。 - On Error Continue エラーが処理され、トランザクションはアクティブなままになり、コミット可能です。​`on-error-continue`​ 内のプロセッサーはトランザクション内で実行されます。 ### [](#例-try-スコープでのエラー発生)例: Try スコープでのエラー発生 イベントソース (​`jms:listener`​) がトランザクションを開始し、このトランザクションが Try スコープによって続行される (​`transactionalAction`​ はデフォルトの ​`INDIFFERENT`​ に設定) 例について考えてみます。 エラーが発生すると、最初に Try スコープの ​`error-handler`​ によって処理されます。エラーは ​`on-error-propagate`​ エラーハンドラーによって処理されますが、トランザクションを開始したのが Try スコープではないため、トランザクションはロールバックされません。トランザクションはフローレベルで (そのイベントソースから) 開始されたため、トランザクションをロールバックできるのはフローエラーハンドラーのみです。 `on-error-propagate`​ エラーハンドラー内の ​`jms:publish`​ 操作はトランザクションを結合します。次にエラーはフロー ​`error-handler`​ に伝播され、このフローが ​`on-error-continue`​ エラーハンドラーを使用してエラーを処理します。​`on-error-continue`​ エラーハンドラー内の ​`jms:consume`​ 操作はトランザクション内で実行されます。最後に、トランザクションがコミットされます。 ```xml ``` 前の例で ​`on-error-continue`​ エラーハンドラーを ​`on-error-propagate`​ エラーハンドラーに置き換えると、プロセッサーの実行前にトランザクションがロールバックされます。このシナリオでは、​`jms:consume`​ 操作はトランザクションを結合できないため、この設定は正しくありません。 ### [](#例-参照先のフローでのエラー発生)例: 参照先のフローでのエラー発生 次の例の動作は前の例と同じですが、Try スコープの代わりに Flow Reference を使用し、参照先のフローでエラーが発生します。 ```xml ``` `someFlowContinuesTx`​ フローがトランザクションを開始したのではないため、そのエラーハンドラーはトランザクションをロールバックしません。 ### [](#例-エラーハンドラーの比較)例: エラーハンドラーの比較 この例は、​`on-error-continue`​ エラーハンドラーと ​`on-error-propagate`​ エラーハンドラーの違いを示しています。 ```xml ``` `flow1`​ で、​`on-error-continue`​ エラーハンドラーはトランザクションをアクティブに保ちますが、その中の Try スコープは新しいトランザクションを開始しようとします。この設定は有効ではなく、エラーが発生します。 `flow2`​ で、​`on-error-propagate`​ エラーハンドラーがトランザクションをロールバックし、​`on-error-propagate`​ エラーハンドラー内のプロセッサーが実行され、トランザクションが新規作成されます。この設定は正しくなります。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept) - [信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.8/reliability-patterns) - [On-Error スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/on-error-scope-concept) # トランザクションの管理 トランザクションとは、結果が不確定になることができない Mule アプリケーションの操作です。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 たとえば、トランザクションを使用して、データベースに情報をコミットするためのフロー内の複数のステップをカプセル化することができます。このようなシナリオでは、コミット (トランザクション) は、全体が完了 (成功) するか、不完全に終了 (失敗) するかのどちらかとなります。部分的に完了しても、コミットは失敗となります。トランザクションが失敗すると、一部だけで部分的な完了とならないように Mule は操作をトランザクション内でロールバックします。 アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、信頼性の高いメッセージングができるように​[信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.9/reliability-patterns)​を実装してアプリケーションをデザインしてください。 Mule アプリケーションでトランザクションを管理するように Bitronix を設定することもできます。 ## [](#トランザクション種別)トランザクション種別 Mule は、単一リソース (ローカル、デフォルト) および拡張アーキテクチャ (​`XA`​) トランザクション種別 (​`transactionType`​) をサポートします。トランザクション種別を定義できるコンポーネントはイベントソース (たとえば、​`jms:listener`​ や ​`vm:listener`​) と Try スコープのみです。 次の表で、各トランザクション種別の特性とトランザクションを結合するための操作の要件について説明します。
トランザクション種別 特性 トランザクションを結合するための要件

単一リソース (ローカル)

  • XA トランザクションよりパフォーマンスが高くなります。

  • ネストされたトランザクションをサポートしていません。

  • 操作がトランザクションをサポートする必要があります。

  • トランザクション内のすべての操作が同じコネクタに属している必要があります。(たとえば、​jms:listener​、​jms:consume​、​jms:publish​)。

  • すべての操作で同じグローバル設定 (​config-ref​) を使用する必要があります。

拡張アーキテクチャ (XA)

  • 2 段階のコミットプロトコル (2PC) を使用します。

  • 単一リソーストランザクションより遅くなりますが、信頼性は高くなります。

  • ネストされたトランザクションをサポートしています。

  • 操作がトランザクションをサポートする必要があります。
## [](#トランザクションのアクション)トランザクションのアクション トランザクションアクション (​`transactionalAction`​) は、トランザクションに関して操作で実行できるアクションの種別を定義します。次の表で、使用可能なすべてのトランザクションアクションについて説明します。
アクション 動作 使用可能な場所

ALWAYS_BEGIN

メッセージの受信時に常に新しいトランザクションを開始します。単一リソーストランザクションが存在する場合、エラーが発生します。XA トランザクションが存在する場合、ネストされたトランザクションが作成されます。

  • トランザクションをサポートするリスナー

  • Try スコープ

ALWAYS_JOIN

メッセージの受信時に常にトランザクションが進行中であると想定します。トランザクションがない場合、エラーが発生します。

  • トランザクションをサポートする操作

BEGIN_OR_JOIN

メッセージの受信時にトランザクションが進行中である場合、可能であればトランザクションを結合します。可能でなければ新しいトランザクションを開始します。

  • Try スコープ

JOIN_IF_POSSIBLE

現在のトランザクションが使用可能な場合、そのトランザクションを結合します。可能でなければトランザクションは作成されません。

  • トランザクションをサポートする操作

INDIFFERENT

アクションをトランザクションとして扱いません。

  • Try スコープ

NONE

トランザクションを開始しません。

  • トランザクションをサポートするリスナー

NOT_SUPPORTED

存在するトランザクションの外部で実行します。

  • トランザクションをサポートする操作
## [](#イベントソースでのトランザクションの設定)イベントソースでのトランザクションの設定 トランザクションを Mule イベントソースから開始できます。この場合は、フロー全体が 1 つのトランザクションとなります。この方法は、メッセージングコネクタを使用して、メッセージングの処理中に問題が発生した場合にはメッセージをコンシュームしないようにして、後で (ロールバックによって) 再試行できるようにしたいときに便利です。 トランザクションを Mule イベントソースから開始するには、そのトランザクション種別とトランザクションアクションを設定します。 - Anypoint Studio では、次の手順を実行します。 リスナーの ​**\[Advanced (詳細)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![アクションと種別の設定が表示されているトランザクション設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/transaction-config-studio-vm.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例は、単一リソース (ローカル) トランザクションを開始するように設定された ​`vm:listener`​ イベントソースを示しています。 ```xml ``` ## [](#try-スコープでのトランザクションの設定)Try スコープでのトランザクションの設定 Mule フローは、フロー内のトランザクションを必要とする非トランザクションコネクタ (HTTP など) で開始する場合もあります。たとえば、Mule フローで外部 Web サービスから情報を受け入れ、クレジットカードに請求してインボイス情報をデータベースに保存する前にデータを変換するとします。この場合は Try スコープを使用して、クレジットカードへの請求操作とデータベースへのコミット操作をラップすることでトランザクションをセットアップすれば、常に完全な成功または完全な失敗とロールバックのどちらかの結果になることを保証できます。 トランザクション種別とトランザクションアクションを設定して、Try スコープコンポーネントでトランザクションを設定できます。 - Anypoint Studio では、次の手順を実行します。 Try スコープの ​**\[General (一般)\]**​ タブで、​**\[Transaction type (トランザクション種別)\]**​ と ​**\[Transactional action (トランザクションアクション)\]**​ の値を設定します。 ![アクションと種別の設定が表示されているトランザクション設定インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/transaction-config-studio.png) - \[Configuration XML (設定 XML)\] では、次の手順を実行します。 `transactionalAction`​ 要素と ​`transactionType`​ 要素 (必要な場合) を追加し、その値を設定します。 次の XML 例では、Try スコープによってデータベース操作 (​`db:insert`​) と VM 操作 (​`vm:publish`​) を含むトランザクションを区分しています。プロセス全体が成功した場合は両方が適用され、Try スコープ内でエラーが発生した場合はどちらも適用されません。 ```xml INSERT INTO main_flow_audit (errorType, description) VALUES (:errorType, :description) ``` ## [](#tx_scopes_routers)トランザクションによるスコープとルーターへの影響 トランザクションスコープで実行する場合は、プロセス全体を同じスレッドで実行する必要があります。これにより、スコープの実行方法、またはトランザクションの処理方法を変更できます。以下で、トランザクションスコープで実行するときに考慮する必要があるスコープおよびルーターの動作について詳しく説明します。 ### [](#スコープ)スコープ - [Async](https://docs.mulesoft.com/jp/mule-runtime/4.9/async-scope-reference)​: トランザクション内で実行した場合、Async スコープは引き続き別のスレッドで実行されます (非同期のまま)。ただし、これはこのスコープ内のプロセッサーの実行全体がトランザクションスコープ外で行われることを意味します。そのため、Async スコープ内でエラーが発生してもロールバックにはなりません。 - [Until Successful](https://docs.mulesoft.com/jp/mule-runtime/4.9/until-successful-scope)​: トランザクション内で実行した場合、Until Successful スコープはスレッドをブロックします。つまり、Until Successful スコープが再試行間の遅延を実行している間、この実行によって使用されるスレッドを使用して他の要求を処理することはできません。 - [Parallel Foreach](https://docs.mulesoft.com/jp/mule-runtime/4.9/parallel-foreach-scope)​: トランザクション内で実行した場合、Parallel Foreach スコープは並列で実行されません。つまり、Foreach スコープとして実行することになります。コレクションの 2 番目の要素は最初の要素が完了した後に処理されます。これは、このスコープによるエラーの処理に影響を及ぼしません。 - [Batch Processing](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-processing-concept)​: Batch Processing は Async スコープとして並列で機能するように設計されており、すべてのレコードはトランザクションとして扱われるため (内部 Batch トランザクションを含む)、Batch 実行はトランザクションの一部ではありません。 ### [](#ルーター)ルーター - [Scatter Gather](https://docs.mulesoft.com/jp/mule-runtime/4.9/scatter-gather-concept)​: トランザクション内で実行した場合、Scatter Gather は並列で実行されません。つまり、2 番目のルーターは最初のルーターが処理された後で実行され、3 番目のルーターは 2 番目のルーターの後で実行される、といった具合になります。 これは、このコンポーネントによるエラーの処理に影響を及ぼしません。 - [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.9/flowref-about)​: 実行中のフロー (またはサブフロー) がトランザクション内で実行されている場合、Flow Reference コンポーネントによって参照先のフロー (またはサブフロー) の実行は同じトランザクションで続行されます。参照先のフローにトランザクションを開始する Mule イベントソースがある場合 (たとえば、​`transactionalAction="ALWAYS_BEGIN"`​ の ​`jms:listener`​ ソース)、​`transactionalAction`​ は無視されます。Flow Reference コンポーネントは、そのイベントソースを除いて参照先のフローコンポーネントを実行します。 その他のルーターまたはスコープ (たとえば、Foreach) はトランザクションで続行され、その動作は変更されません。 ## [](#エラー処理)エラー処理 トランザクション中にエラーが発生した場合、アプリケーションはエラーを処理して続行するか、ロールバックを実行する必要があります。 エラーハンドラーには 2 つの種別があり、トランザクション中にエラーが発生したときの動作が異なります。 - On Error Propagate - `on-error-propagate`​ エラーハンドラーがトランザクションを開始したコンポーネントに対応する ​`error-handler`​ スコープ内にある場合: `on-error-propagate`​ スコープのプロセッサーを実行する前にトランザクションがロールバックされます。つまり、エラーハンドラー内のプロセッサーはトランザクション内で実行されません。 - `on-error-propagate`​ エラーハンドラーがトランザクションを開始しなかった要素内にある場合: トランザクションはロールバックされず、​`on-error-propagate`​ エラーハンドラー内のプロセッサーはトランザクション内で実行されます。一部のスコープやルーターでは、トランザクション内で実行したときに動作が異なります。 - On Error Continue エラーが処理され、トランザクションはアクティブなままになり、コミット可能です。​`on-error-continue`​ 内のプロセッサーはトランザクション内で実行されます。 ### [](#例-try-スコープでのエラー発生)例: Try スコープでのエラー発生 イベントソース (​`jms:listener`​) がトランザクションを開始し、このトランザクションが Try スコープによって続行される (​`transactionalAction`​ はデフォルトの ​`INDIFFERENT`​ に設定) 例について考えてみます。 エラーが発生すると、最初に Try スコープの ​`error-handler`​ によって処理されます。エラーは ​`on-error-propagate`​ エラーハンドラーによって処理されますが、トランザクションを開始したのが Try スコープではないため、トランザクションはロールバックされません。トランザクションはフローレベルで (そのイベントソースから) 開始されたため、トランザクションをロールバックできるのはフローエラーハンドラーのみです。 `on-error-propagate`​ エラーハンドラー内の ​`jms:publish`​ 操作はトランザクションを結合します。次にエラーはフロー ​`error-handler`​ に伝播され、このフローが ​`on-error-continue`​ エラーハンドラーを使用してエラーを処理します。​`on-error-continue`​ エラーハンドラー内の ​`jms:consume`​ 操作はトランザクション内で実行されます。最後に、トランザクションがコミットされます。 ```xml ``` 前の例で ​`on-error-continue`​ エラーハンドラーを ​`on-error-propagate`​ エラーハンドラーに置き換えると、プロセッサーの実行前にトランザクションがロールバックされます。このシナリオでは、​`jms:consume`​ 操作はトランザクションを結合できないため、この設定は正しくありません。 ### [](#例-参照先のフローでのエラー発生)例: 参照先のフローでのエラー発生 次の例の動作は前の例と同じですが、Try スコープの代わりに Flow Reference を使用し、参照先のフローでエラーが発生します。 ```xml ``` `someFlowContinuesTx`​ フローがトランザクションを開始したのではないため、そのエラーハンドラーはトランザクションをロールバックしません。 ### [](#例-エラーハンドラーの比較)例: エラーハンドラーの比較 この例は、​`on-error-continue`​ エラーハンドラーと ​`on-error-propagate`​ エラーハンドラーの違いを示しています。 ```xml ``` `flow1`​ で、​`on-error-continue`​ エラーハンドラーはトランザクションをアクティブに保ちますが、その中の Try スコープは新しいトランザクションを開始しようとします。この設定は有効ではなく、エラーが発生します。 `flow2`​ で、​`on-error-propagate`​ エラーハンドラーがトランザクションをロールバックし、​`on-error-propagate`​ エラーハンドラー内のプロセッサーが実行され、トランザクションが新規作成されます。この設定は正しくなります。 ## [](#関連情報)関連情報 - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept) - [信頼性パターン](https://docs.mulesoft.com/jp/mule-runtime/4.9/reliability-patterns) - [On-Error スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/on-error-scope-concept) # トランスフォーマーについて (非推奨) Object to XML や Object to String などのトランスフォーマーは、Transform コンポーネントとは異なる非推奨のデータ変換コンポーネントです。 このリリースでは、非推奨のコンポーネントを使用する代わりに、Transform コンポーネントで DataWeave 式を使用してデータ変換を実行する必要があります。 トランスフォーマーは、Compatibility Module (Mule バージョン 4.1 以降で使用可能) を介してのみ使用できます。 ## [](#関連情報)関連情報 [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about) # トランスフォーマーについて (非推奨) Object to XML や Object to String などのトランスフォーマーは、Transform コンポーネントとは異なる非推奨のデータ変換コンポーネントです。 このリリースでは、非推奨のコンポーネントを使用する代わりに、Transform コンポーネントで DataWeave 式を使用してデータ変換を実行する必要があります。 トランスフォーマーは、Compatibility Module (Mule バージョン 4.1 以降で使用可能) を介してのみ使用できます。 ## [](#関連情報)関連情報 [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about) # トランスフォーマーについて (非推奨) Object to XML や Object to String などのトランスフォーマーは、Transform コンポーネントとは異なる非推奨のデータ変換コンポーネントです。 このリリースでは、非推奨のコンポーネントを使用する代わりに、Transform コンポーネントで DataWeave 式を使用してデータ変換を実行する必要があります。 トランスフォーマーは、Compatibility Module (Mule バージョン 4.1 以降で使用可能) を介してのみ使用できます。 ## [](#関連情報)関連情報 [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about) # トランスフォーマーについて (非推奨) Object to XML や Object to String などのトランスフォーマーは、Transform コンポーネントとは異なる非推奨のデータ変換コンポーネントです。 このリリースでは、非推奨のコンポーネントを使用する代わりに、Transform コンポーネントで DataWeave 式を使用してデータ変換を実行する必要があります。 トランスフォーマーは、Compatibility Module (Mule バージョン 4.1 以降で使用可能) を介してのみ使用できます。 ## [](#関連情報)関連情報 [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about) # トランスフォーマーについて (非推奨) Object to XML や Object to String などのトランスフォーマーは、Transform コンポーネントとは異なる非推奨のデータ変換コンポーネントです。 このリリースでは、非推奨のコンポーネントを使用する代わりに、Transform コンポーネントで DataWeave 式を使用してデータ変換を実行する必要があります。 トランスフォーマーは、Compatibility Module (Mule バージョン 4.1 以降で使用可能) を介してのみ使用できます。 ## [](#関連情報)関連情報 [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about) # トランスフォーマーについて (非推奨) Object to XML や Object to String などのトランスフォーマーは、Transform コンポーネントとは異なる非推奨のデータ変換コンポーネントです。 このリリースでは、非推奨のコンポーネントを使用する代わりに、Transform コンポーネントで DataWeave 式を使用してデータ変換を実行する必要があります。 トランスフォーマーは、Compatibility Module (Mule バージョン 4.1 以降で使用可能) を介してのみ使用できます。 ## [](#関連情報)関連情報 [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about) # トランスフォーマーについて (非推奨) Object to XML や Object to String などのトランスフォーマーは、Transform コンポーネントとは異なる非推奨のデータ変換コンポーネントです。 このリリースでは、非推奨のコンポーネントを使用する代わりに、Transform コンポーネントで DataWeave 式を使用してデータ変換を実行する必要があります。 トランスフォーマーは、Compatibility Module (Mule バージョン 4.1 以降で使用可能) を介してのみ使用できます。 ## [](#関連情報)関連情報 [Transform コンポーネントについて](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about) # トランスフォーマーの移行 Mule 4 では ​`transformers`​ は必要なくなりました。DataWeave がデフォルトの式言語になり、反復可能なストリーム機能がサポートされるようになったため、トランスフォーマーが必要なシナリオは (まったくとは言わないまでも) ほとんど存在しません。 ## [](#型のトランスフォーマーの移行)型のトランスフォーマーの移行 Mule 3 では、異なる型を使用して同じデータを表現できます。たとえば、JSON は ​`String`​、​`InputStream`​、​`OutputHandler`​、または ​`ByteArray`​ を使用して保存できます。同じように、XML はこれらの同じ型を使用するか、Java DOM ドキュメントで表現できます。 Mule 4 では、バイナリ以外のすべての形式が自動的に Mule によって処理されます。そのため、コンテンツが含まれている型を気にする必要がありません。 ### [](#文字列変換に対する-inputstream)文字列変換に対する InputStream Mule 3 では、​`InputStream`​ によって保持されるデータを複数のプロセッサーでコンシュームできるように、​``​ が一般に使用されていました。Mule 4 には反復可能なストリームの概念があるため、これは必要なくなりました。 ### [](#json-および-xml-のオブジェクトモデル表現)JSON および XML のオブジェクトモデル表現 Mule 3 の XML または JSON ドキュメントのコンテンツにアクセスするには、後で Java コードまたは MEL を使用できるように Java オブジェクト表現モデルへの変換が必要でした。Mule 4 では、runtime の式言語が JSON および XML (およびその他の多くの形式) を完全にサポートしているため、この変換は必要なくなりました。単に DataWeave 式を使用してデータにアクセスします。 ## [](#カスタムトランスフォーマーの移行)カスタムトランスフォーマーの移行 ほとんどの場合、サポートされるデータ形式を処理するために使用していたカスタムトランスフォーマーは必要なくなったため、式言語を使用するために移行できます。複数の場所で同じ変換を実行する必要がある場合、DataWeave スクリプトをファイルに外部化できます。 DataWeave がサポートしていない方法でデータを変換する場合、Java Module または Scripting Module を使用し、カスタムコードを使用して変換を実行する必要があります。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.3/streaming-about) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # トランスフォーマーの移行 Mule 4 では ​`transformers`​ は必要なくなりました。DataWeave がデフォルトの式言語になり、反復可能なストリーム機能がサポートされるようになったため、トランスフォーマーが必要なシナリオは (まったくとは言わないまでも) ほとんど存在しません。 ## [](#型のトランスフォーマーの移行)型のトランスフォーマーの移行 Mule 3 では、異なる型を使用して同じデータを表現できます。たとえば、JSON は ​`String`​、​`InputStream`​、​`OutputHandler`​、または ​`ByteArray`​ を使用して保存できます。同じように、XML はこれらの同じ型を使用するか、Java DOM ドキュメントで表現できます。 Mule 4 では、バイナリ以外のすべての形式が自動的に Mule によって処理されます。そのため、コンテンツが含まれている型を気にする必要がありません。 ### [](#文字列変換に対する-inputstream)文字列変換に対する InputStream Mule 3 では、​`InputStream`​ によって保持されるデータを複数のプロセッサーでコンシュームできるように、​``​ が一般に使用されていました。Mule 4 には反復可能なストリームの概念があるため、これは必要なくなりました。 ### [](#json-および-xml-のオブジェクトモデル表現)JSON および XML のオブジェクトモデル表現 Mule 3 の XML または JSON ドキュメントのコンテンツにアクセスするには、後で Java コードまたは MEL を使用できるように Java オブジェクト表現モデルへの変換が必要でした。Mule 4 では、runtime の式言語が JSON および XML (およびその他の多くの形式) を完全にサポートしているため、この変換は必要なくなりました。単に DataWeave 式を使用してデータにアクセスします。 ## [](#カスタムトランスフォーマーの移行)カスタムトランスフォーマーの移行 ほとんどの場合、サポートされるデータ形式を処理するために使用していたカスタムトランスフォーマーは必要なくなったため、式言語を使用するために移行できます。複数の場所で同じ変換を実行する必要がある場合、DataWeave スクリプトをファイルに外部化できます。 DataWeave がサポートしていない方法でデータを変換する場合、Java Module または Scripting Module を使用し、カスタムコードを使用して変換を実行する必要があります。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java モジュール](https://docs.mulesoft.com/jp/java-module/latest/) [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.4/streaming-about) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # トランスフォーマーの移行 Mule 4 では ​`transformers`​ は必要なくなりました。DataWeave がデフォルトの式言語になり、反復可能なストリーム機能がサポートされるようになったため、トランスフォーマーが必要なシナリオは (まったくとは言わないまでも) ほとんど存在しません。 ## [](#型のトランスフォーマーの移行)型のトランスフォーマーの移行 Mule 3 では、異なる型を使用して同じデータを表現できます。たとえば、JSON は ​`String`​、​`InputStream`​、​`OutputHandler`​、または ​`ByteArray`​ を使用して保存できます。同じように、XML はこれらの同じ型を使用するか、Java DOM ドキュメントで表現できます。 Mule 4 では、バイナリ以外のすべての形式が自動的に Mule によって処理されます。そのため、コンテンツが含まれている型を気にする必要がありません。 ### [](#文字列変換に対する-inputstream)文字列変換に対する InputStream Mule 3 では、​`InputStream`​ によって保持されるデータを複数のプロセッサーでコンシュームできるように、​``​ が一般に使用されていました。Mule 4 には反復可能なストリームの概念があるため、これは必要なくなりました。 ### [](#json-および-xml-のオブジェクトモデル表現)JSON および XML のオブジェクトモデル表現 Mule 3 の XML または JSON ドキュメントのコンテンツにアクセスするには、後で Java コードまたは MEL を使用できるように Java オブジェクト表現モデルへの変換が必要でした。Mule 4 では、runtime の式言語が JSON および XML (およびその他の多くの形式) を完全にサポートしているため、この変換は必要なくなりました。単に DataWeave 式を使用してデータにアクセスします。 ## [](#カスタムトランスフォーマーの移行)カスタムトランスフォーマーの移行 ほとんどの場合、サポートされるデータ形式を処理するために使用していたカスタムトランスフォーマーは必要なくなったため、式言語を使用するために移行できます。複数の場所で同じ変換を実行する必要がある場合、DataWeave スクリプトをファイルに外部化できます。 DataWeave がサポートしていない方法でデータを変換する場合、Java Module または Scripting Module を使用し、カスタムコードを使用して変換を実行する必要があります。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.5/streaming-about) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # トランスフォーマーの移行 Mule 4 では ​`transformers`​ は必要なくなりました。DataWeave がデフォルトの式言語になり、反復可能なストリーム機能がサポートされるようになったため、トランスフォーマーが必要なシナリオは (まったくとは言わないまでも) ほとんど存在しません。 ## [](#型のトランスフォーマーの移行)型のトランスフォーマーの移行 Mule 3 では、異なる型を使用して同じデータを表現できます。たとえば、JSON は ​`String`​、​`InputStream`​、​`OutputHandler`​、または ​`ByteArray`​ を使用して保存できます。同じように、XML はこれらの同じ型を使用するか、Java DOM ドキュメントで表現できます。 Mule 4 では、バイナリ以外のすべての形式が自動的に Mule によって処理されます。そのため、コンテンツが含まれている型を気にする必要がありません。 ### [](#文字列変換に対する-inputstream)文字列変換に対する InputStream Mule 3 では、​`InputStream`​ によって保持されるデータを複数のプロセッサーでコンシュームできるように、​``​ が一般に使用されていました。Mule 4 には反復可能なストリームの概念があるため、これは必要なくなりました。 ### [](#json-および-xml-のオブジェクトモデル表現)JSON および XML のオブジェクトモデル表現 Mule 3 の XML または JSON ドキュメントのコンテンツにアクセスするには、後で Java コードまたは MEL を使用できるように Java オブジェクト表現モデルへの変換が必要でした。Mule 4 では、runtime の式言語が JSON および XML (およびその他の多くの形式) を完全にサポートしているため、この変換は必要なくなりました。単に DataWeave 式を使用してデータにアクセスします。 ## [](#カスタムトランスフォーマーの移行)カスタムトランスフォーマーの移行 ほとんどの場合、サポートされるデータ形式を処理するために使用していたカスタムトランスフォーマーは必要なくなったため、式言語を使用するために移行できます。複数の場所で同じ変換を実行する必要がある場合、DataWeave スクリプトをファイルに外部化できます。 DataWeave がサポートしていない方法でデータを変換する場合、Java Module または Scripting Module を使用し、カスタムコードを使用して変換を実行する必要があります。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.6/streaming-about) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # トランスフォーマーの移行 Mule 4 では ​`transformers`​ は必要なくなりました。DataWeave がデフォルトの式言語になり、反復可能なストリーム機能がサポートされるようになったため、トランスフォーマーが必要なシナリオは (まったくとは言わないまでも) ほとんど存在しません。 ## [](#型のトランスフォーマーの移行)型のトランスフォーマーの移行 Mule 3 では、異なる型を使用して同じデータを表現できます。たとえば、JSON は ​`String`​、​`InputStream`​、​`OutputHandler`​、または ​`ByteArray`​ を使用して保存できます。同じように、XML はこれらの同じ型を使用するか、Java DOM ドキュメントで表現できます。 Mule 4 では、バイナリ以外のすべての形式が自動的に Mule によって処理されます。そのため、コンテンツが含まれている型を気にする必要がありません。 ### [](#文字列変換に対する-inputstream)文字列変換に対する InputStream Mule 3 では、​`InputStream`​ によって保持されるデータを複数のプロセッサーでコンシュームできるように、​``​ が一般に使用されていました。Mule 4 には反復可能なストリームの概念があるため、これは必要なくなりました。 ### [](#json-および-xml-のオブジェクトモデル表現)JSON および XML のオブジェクトモデル表現 Mule 3 の XML または JSON ドキュメントのコンテンツにアクセスするには、後で Java コードまたは MEL を使用できるように Java オブジェクト表現モデルへの変換が必要でした。Mule 4 では、runtime の式言語が JSON および XML (およびその他の多くの形式) を完全にサポートしているため、この変換は必要なくなりました。単に DataWeave 式を使用してデータにアクセスします。 ## [](#カスタムトランスフォーマーの移行)カスタムトランスフォーマーの移行 ほとんどの場合、サポートされるデータ形式を処理するために使用していたカスタムトランスフォーマーは必要なくなったため、式言語を使用するために移行できます。複数の場所で同じ変換を実行する必要がある場合、DataWeave スクリプトをファイルに外部化できます。 DataWeave がサポートしていない方法でデータを変換する場合、Java Module または Scripting Module を使用し、カスタムコードを使用して変換を実行する必要があります。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.7/streaming-about) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # トランスフォーマーの移行 Mule 4 では ​`transformers`​ は必要なくなりました。DataWeave がデフォルトの式言語になり、反復可能なストリーム機能がサポートされるようになったため、トランスフォーマーが必要なシナリオは (まったくとは言わないまでも) ほとんど存在しません。 ## [](#型のトランスフォーマーの移行)型のトランスフォーマーの移行 Mule 3 では、異なる型を使用して同じデータを表現できます。たとえば、JSON は ​`String`​、​`InputStream`​、​`OutputHandler`​、または ​`ByteArray`​ を使用して保存できます。同じように、XML はこれらの同じ型を使用するか、Java DOM ドキュメントで表現できます。 Mule 4 では、バイナリ以外のすべての形式が自動的に Mule によって処理されます。そのため、コンテンツが含まれている型を気にする必要がありません。 ### [](#文字列変換に対する-inputstream)文字列変換に対する InputStream Mule 3 では、​`InputStream`​ によって保持されるデータを複数のプロセッサーでコンシュームできるように、​``​ が一般に使用されていました。Mule 4 には反復可能なストリームの概念があるため、これは必要なくなりました。 ### [](#json-および-xml-のオブジェクトモデル表現)JSON および XML のオブジェクトモデル表現 Mule 3 の XML または JSON ドキュメントのコンテンツにアクセスするには、後で Java コードまたは MEL を使用できるように Java オブジェクト表現モデルへの変換が必要でした。Mule 4 では、runtime の式言語が JSON および XML (およびその他の多くの形式) を完全にサポートしているため、この変換は必要なくなりました。単に DataWeave 式を使用してデータにアクセスします。 ## [](#カスタムトランスフォーマーの移行)カスタムトランスフォーマーの移行 ほとんどの場合、サポートされるデータ形式を処理するために使用していたカスタムトランスフォーマーは必要なくなったため、式言語を使用するために移行できます。複数の場所で同じ変換を実行する必要がある場合、DataWeave スクリプトをファイルに外部化できます。 DataWeave がサポートしていない方法でデータを変換する場合、Java Module または Scripting Module を使用し、カスタムコードを使用して変換を実行する必要があります。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.8/streaming-about) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # トランスフォーマーの移行 Mule 4 では ​`transformers`​ は必要なくなりました。DataWeave がデフォルトの式言語になり、反復可能なストリーム機能がサポートされるようになったため、トランスフォーマーが必要なシナリオは (まったくとは言わないまでも) ほとんど存在しません。 ## [](#型のトランスフォーマーの移行)型のトランスフォーマーの移行 Mule 3 では、異なる型を使用して同じデータを表現できます。たとえば、JSON は ​`String`​、​`InputStream`​、​`OutputHandler`​、または ​`ByteArray`​ を使用して保存できます。同じように、XML はこれらの同じ型を使用するか、Java DOM ドキュメントで表現できます。 Mule 4 では、バイナリ以外のすべての形式が自動的に Mule によって処理されます。そのため、コンテンツが含まれている型を気にする必要がありません。 ### [](#文字列変換に対する-inputstream)文字列変換に対する InputStream Mule 3 では、​`InputStream`​ によって保持されるデータを複数のプロセッサーでコンシュームできるように、​``​ が一般に使用されていました。Mule 4 には反復可能なストリームの概念があるため、これは必要なくなりました。 ### [](#json-および-xml-のオブジェクトモデル表現)JSON および XML のオブジェクトモデル表現 Mule 3 の XML または JSON ドキュメントのコンテンツにアクセスするには、後で Java コードまたは MEL を使用できるように Java オブジェクト表現モデルへの変換が必要でした。Mule 4 では、runtime の式言語が JSON および XML (およびその他の多くの形式) を完全にサポートしているため、この変換は必要なくなりました。単に DataWeave 式を使用してデータにアクセスします。 ## [](#カスタムトランスフォーマーの移行)カスタムトランスフォーマーの移行 ほとんどの場合、サポートされるデータ形式を処理するために使用していたカスタムトランスフォーマーは必要なくなったため、式言語を使用するために移行できます。複数の場所で同じ変換を実行する必要がある場合、DataWeave スクリプトをファイルに外部化できます。 DataWeave がサポートしていない方法でデータを変換する場合、Java Module または Scripting Module を使用し、カスタムコードを使用して変換を実行する必要があります。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.9/streaming-about) [Why DataWeave is the Main Expression Language in Mule 4 Beta (Mule 4 ベータ版で DataWeave が主要な式言語である理由)](https://blogs.mulesoft.com/dev/mule-dev/why-dataweave-main-expression-language-mule-4/) # トランスポートの移行 Mule 3 トランスポートはコネクタに置き換えられており、コネクタは Mule 4 の操作モデルに従います。ほとんどの Mule トランスポートは、Mule 4 の対応するコネクタに 置き換え可能です。 すべてのトランスポートに共通の移行に関する問題がいくつかあります。トランスポート固有の 移行ドキュメントについては、 ​[「コネクタおよびモジュールの Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-connectors)​および その子ページを代わりに参照してください。 ## [](#address)エンドポイントアドレス Mule 3 では、エンドポイントはトランスポート固有の属性 (たとえば、HTTP エンドポイントは ​`host`​、​`port`​、​`path`​ を使用できました) または汎用の ​`address`​ 属性を使用して設定できました。 汎用の ​`address`​ 属性を使用した場合、たとえば以下のようにプロパティを 参照できました。 ```xml ``` `External.URL`​ について設定されたプロパティは次のようになります。 ```text External.URL=http://0.0.0.0:8080/rootPath ``` Mule 4 では、コネクタが接続属性を個別に定義するため、完全なアドレスプロパティはコンポーネントに分割する必要があります。 ```xml ... ``` プロパティの設定は次のようになります。 ```text External.URL.host=0.0.0.0 External.URL.port=8080 External.URL.path=/rootPath ``` コネクタ固有のドキュメント (HTTP Connector や Email Connector 用のドキュメントなど) には、コネクタに必要な正確なプロパティに関する詳細が記載されています。 ## [](#service_overrides)サービスの上書き Mule 4 では、カスタム Java コードを使用したサービスの上書きのカスタマイズは サポートされていません。 Mule 3 では、コネクタの ​`service-overrides`​ 要素を使用してトランスポートの動作を カスタマイズできます。この要素により、 新しい機能を提供するカスタムコードを使用して Java クラスを参照できます。 Mule 3 の例: `service-overrides`​ を含むコネクタ ```xml ``` こうしたカスタマイズを Mule 4 に移行する方法は、 カスタムコードの動作に応じて異なるため、以下の方法が考えられます。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave)​ 変換、​[Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ などの他の Mule 機能やコンポーネントを使用してこの機能を提供する。 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して、カスタマイズした トランスポート機能を提供するコネクタを作成する。開始点として、オープンソースのコネクタを連動関係として使用できます (たとえば、​[https://github.com/mulesoft/mule-http-connector)。](https://github.com/mulesoft/mule-http-connector\)。) - 前の手法と同じように、オープンソースのコネクタリポジトリをフォークして、 カスタムコードをフォークに追加できます。MuleSoft では変更のプル要求を歓迎します。 - MuleSoft に機能要求を行う。​`service-overrides`​ を通じてカスタムコードで提供した機能を追加するよう MuleSoft に要求できます。こうした要求を 送信するには、 [MuleSoft サポートの「Ideas (アイデア)」](https://help.mulesoft.com/s/ideas)​にアクセスして ください。 ## [](#関連情報)関連情報 [コネクタとモジュールの Mule 4 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-connectors) [Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-java-integration) [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) # トランスポートの移行 Mule 3 トランスポートはコネクタに置き換えられており、コネクタは Mule 4 の操作モデルに従います。ほとんどの Mule トランスポートは、Mule 4 の対応するコネクタに 置き換え可能です。 すべてのトランスポートに共通の移行に関する問題がいくつかあります。トランスポート固有の 移行ドキュメントについては、 ​[「コネクタおよびモジュールの Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-connectors)​および その子ページを代わりに参照してください。 ## [](#address)エンドポイントアドレス Mule 3 では、エンドポイントはトランスポート固有の属性 (たとえば、HTTP エンドポイントは ​`host`​、​`port`​、​`path`​ を使用できました) または汎用の ​`address`​ 属性を使用して設定できました。 汎用の ​`address`​ 属性を使用した場合、たとえば以下のようにプロパティを 参照できました。 ```xml ``` `External.URL`​ について設定されたプロパティは次のようになります。 ```text External.URL=http://0.0.0.0:8080/rootPath ``` Mule 4 では、コネクタが接続属性を個別に定義するため、完全なアドレスプロパティはコンポーネントに分割する必要があります。 ```xml ... ``` プロパティの設定は次のようになります。 ```text External.URL.host=0.0.0.0 External.URL.port=8080 External.URL.path=/rootPath ``` コネクタ固有のドキュメント (HTTP Connector や Email Connector 用のドキュメントなど) には、コネクタに必要な正確なプロパティに関する詳細が記載されています。 ## [](#service_overrides)サービスの上書き Mule 4 では、カスタム Java コードを使用したサービスの上書きのカスタマイズは サポートされていません。 Mule 3 では、コネクタの ​`service-overrides`​ 要素を使用してトランスポートの動作を カスタマイズできます。この要素により、 新しい機能を提供するカスタムコードを使用して Java クラスを参照できます。 Mule 3 の例: `service-overrides`​ を含むコネクタ ```xml ``` こうしたカスタマイズを Mule 4 に移行する方法は、 カスタムコードの動作に応じて異なるため、以下の方法が考えられます。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave)​ 変換、​[Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ などの他の Mule 機能やコンポーネントを使用してこの機能を提供する。 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して、カスタマイズした トランスポート機能を提供するコネクタを作成する。開始点として、オープンソースのコネクタを連動関係として使用できます (たとえば、​[https://github.com/mulesoft/mule-http-connector)。](https://github.com/mulesoft/mule-http-connector\)。) - 前の手法と同じように、オープンソースのコネクタリポジトリをフォークして、 カスタムコードをフォークに追加できます。MuleSoft では変更のプル要求を歓迎します。 - MuleSoft に機能要求を行う。​`service-overrides`​ を通じてカスタムコードで提供した機能を追加するよう MuleSoft に要求できます。こうした要求を 送信するには、 [MuleSoft サポートの「Ideas (アイデア)」](https://help.mulesoft.com/s/ideas)​にアクセスして ください。 ## [](#関連情報)関連情報 [コネクタとモジュールの Mule 4 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-connectors) [Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-java-integration) [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) # トランスポートの移行 Mule 3 トランスポートはコネクタに置き換えられており、コネクタは Mule 4 の操作モデルに従います。ほとんどの Mule トランスポートは、Mule 4 の対応するコネクタに 置き換え可能です。 すべてのトランスポートに共通の移行に関する問題がいくつかあります。トランスポート固有の 移行ドキュメントについては、 ​[「コネクタおよびモジュールの Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-connectors)​および その子ページを代わりに参照してください。 ## [](#address)エンドポイントアドレス Mule 3 では、エンドポイントはトランスポート固有の属性 (たとえば、HTTP エンドポイントは ​`host`​、​`port`​、​`path`​ を使用できました) または汎用の ​`address`​ 属性を使用して設定できました。 汎用の ​`address`​ 属性を使用した場合、たとえば以下のようにプロパティを 参照できました。 ```xml ``` `External.URL`​ について設定されたプロパティは次のようになります。 ```text External.URL=http://0.0.0.0:8080/rootPath ``` Mule 4 では、コネクタが接続属性を個別に定義するため、完全なアドレスプロパティはコンポーネントに分割する必要があります。 ```xml ... ``` プロパティの設定は次のようになります。 ```text External.URL.host=0.0.0.0 External.URL.port=8080 External.URL.path=/rootPath ``` コネクタ固有のドキュメント (HTTP Connector や Email Connector 用のドキュメントなど) には、コネクタに必要な正確なプロパティに関する詳細が記載されています。 ## [](#service_overrides)サービスの上書き Mule 4 では、カスタム Java コードを使用したサービスの上書きのカスタマイズは サポートされていません。 Mule 3 では、コネクタの ​`service-overrides`​ 要素を使用してトランスポートの動作を カスタマイズできます。この要素により、 新しい機能を提供するカスタムコードを使用して Java クラスを参照できます。 Mule 3 の例: `service-overrides`​ を含むコネクタ ```xml ``` こうしたカスタマイズを Mule 4 に移行する方法は、 カスタムコードの動作に応じて異なるため、以下の方法が考えられます。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave)​ 変換、​[Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ などの他の Mule 機能やコンポーネントを使用してこの機能を提供する。 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して、カスタマイズした トランスポート機能を提供するコネクタを作成する。開始点として、オープンソースのコネクタを連動関係として使用できます (たとえば、​[https://github.com/mulesoft/mule-http-connector)。](https://github.com/mulesoft/mule-http-connector\)。) - 前の手法と同じように、オープンソースのコネクタリポジトリをフォークして、 カスタムコードをフォークに追加できます。MuleSoft では変更のプル要求を歓迎します。 - MuleSoft に機能要求を行う。​`service-overrides`​ を通じてカスタムコードで提供した機能を追加するよう MuleSoft に要求できます。こうした要求を 送信するには、 [MuleSoft サポートの「Ideas (アイデア)」](https://help.mulesoft.com/s/ideas)​にアクセスして ください。 ## [](#関連情報)関連情報 [コネクタとモジュールの Mule 4 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-connectors) [Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-java-integration) [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) # トランスポートの移行 Mule 3 トランスポートはコネクタに置き換えられており、コネクタは Mule 4 の操作モデルに従います。ほとんどの Mule トランスポートは、Mule 4 の対応するコネクタに 置き換え可能です。 すべてのトランスポートに共通の移行に関する問題がいくつかあります。トランスポート固有の 移行ドキュメントについては、 ​[「コネクタおよびモジュールの Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-connectors)​および その子ページを代わりに参照してください。 ## [](#address)エンドポイントアドレス Mule 3 では、エンドポイントはトランスポート固有の属性 (たとえば、HTTP エンドポイントは ​`host`​、​`port`​、​`path`​ を使用できました) または汎用の ​`address`​ 属性を使用して設定できました。 汎用の ​`address`​ 属性を使用した場合、たとえば以下のようにプロパティを 参照できました。 ```xml ``` `External.URL`​ について設定されたプロパティは次のようになります。 ```text External.URL=http://0.0.0.0:8080/rootPath ``` Mule 4 では、コネクタが接続属性を個別に定義するため、完全なアドレスプロパティはコンポーネントに分割する必要があります。 ```xml ... ``` プロパティの設定は次のようになります。 ```text External.URL.host=0.0.0.0 External.URL.port=8080 External.URL.path=/rootPath ``` コネクタ固有のドキュメント (HTTP Connector や Email Connector 用のドキュメントなど) には、コネクタに必要な正確なプロパティに関する詳細が記載されています。 ## [](#service_overrides)サービスの上書き Mule 4 では、カスタム Java コードを使用したサービスの上書きのカスタマイズは サポートされていません。 Mule 3 では、コネクタの ​`service-overrides`​ 要素を使用してトランスポートの動作を カスタマイズできます。この要素により、 新しい機能を提供するカスタムコードを使用して Java クラスを参照できます。 Mule 3 の例: `service-overrides`​ を含むコネクタ ```xml ``` こうしたカスタマイズを Mule 4 に移行する方法は、 カスタムコードの動作に応じて異なるため、以下の方法が考えられます。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave)​ 変換、​[Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ などの他の Mule 機能やコンポーネントを使用してこの機能を提供する。 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して、カスタマイズした トランスポート機能を提供するコネクタを作成する。開始点として、オープンソースのコネクタを連動関係として使用できます (たとえば、​[https://github.com/mulesoft/mule-http-connector)。](https://github.com/mulesoft/mule-http-connector\)。) - 前の手法と同じように、オープンソースのコネクタリポジトリをフォークして、 カスタムコードをフォークに追加できます。MuleSoft では変更のプル要求を歓迎します。 - MuleSoft に機能要求を行う。​`service-overrides`​ を通じてカスタムコードで提供した機能を追加するよう MuleSoft に要求できます。こうした要求を 送信するには、 [MuleSoft サポートの「Ideas (アイデア)」](https://help.mulesoft.com/s/ideas)​にアクセスして ください。 ## [](#関連情報)関連情報 [コネクタとモジュールの Mule 4 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-connectors) [Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-java-integration) [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) # トランスポートの移行 Mule 3 トランスポートはコネクタに置き換えられており、コネクタは Mule 4 の操作モデルに従います。ほとんどの Mule トランスポートは、Mule 4 の対応するコネクタに 置き換え可能です。 すべてのトランスポートに共通の移行に関する問題がいくつかあります。トランスポート固有の 移行ドキュメントについては、 ​[「コネクタおよびモジュールの Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-connectors)​および その子ページを代わりに参照してください。 ## [](#address)エンドポイントアドレス Mule 3 では、エンドポイントはトランスポート固有の属性 (たとえば、HTTP エンドポイントは ​`host`​、​`port`​、​`path`​ を使用できました) または汎用の ​`address`​ 属性を使用して設定できました。 汎用の ​`address`​ 属性を使用した場合、たとえば以下のようにプロパティを 参照できました。 ```xml ``` `External.URL`​ について設定されたプロパティは次のようになります。 ```text External.URL=http://0.0.0.0:8080/rootPath ``` Mule 4 では、コネクタが接続属性を個別に定義するため、完全なアドレスプロパティはコンポーネントに分割する必要があります。 ```xml ... ``` プロパティの設定は次のようになります。 ```text External.URL.host=0.0.0.0 External.URL.port=8080 External.URL.path=/rootPath ``` コネクタ固有のドキュメント (HTTP Connector や Email Connector 用のドキュメントなど) には、コネクタに必要な正確なプロパティに関する詳細が記載されています。 ## [](#service_overrides)サービスの上書き Mule 4 では、カスタム Java コードを使用したサービスの上書きのカスタマイズは サポートされていません。 Mule 3 では、コネクタの ​`service-overrides`​ 要素を使用してトランスポートの動作を カスタマイズできます。この要素により、 新しい機能を提供するカスタムコードを使用して Java クラスを参照できます。 Mule 3 の例: `service-overrides`​ を含むコネクタ ```xml ``` こうしたカスタマイズを Mule 4 に移行する方法は、 カスタムコードの動作に応じて異なるため、以下の方法が考えられます。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave)​ 変換、​[Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ などの他の Mule 機能やコンポーネントを使用してこの機能を提供する。 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して、カスタマイズした トランスポート機能を提供するコネクタを作成する。開始点として、オープンソースのコネクタを連動関係として使用できます (たとえば、​[https://github.com/mulesoft/mule-http-connector)。](https://github.com/mulesoft/mule-http-connector\)。) - 前の手法と同じように、オープンソースのコネクタリポジトリをフォークして、 カスタムコードをフォークに追加できます。MuleSoft では変更のプル要求を歓迎します。 - MuleSoft に機能要求を行う。​`service-overrides`​ を通じてカスタムコードで提供した機能を追加するよう MuleSoft に要求できます。こうした要求を 送信するには、 [MuleSoft サポートの「Ideas (アイデア)」](https://help.mulesoft.com/s/ideas)​にアクセスして ください。 ## [](#関連情報)関連情報 [コネクタとモジュールの Mule 4 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-connectors) [Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-java-integration) [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) # トランスポートの移行 Mule 3 トランスポートはコネクタに置き換えられており、コネクタは Mule 4 の操作モデルに従います。ほとんどの Mule トランスポートは、Mule 4 の対応するコネクタに 置き換え可能です。 すべてのトランスポートに共通の移行に関する問題がいくつかあります。トランスポート固有の 移行ドキュメントについては、 ​[「コネクタおよびモジュールの Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-connectors)​および その子ページを代わりに参照してください。 ## [](#address)エンドポイントアドレス Mule 3 では、エンドポイントはトランスポート固有の属性 (たとえば、HTTP エンドポイントは ​`host`​、​`port`​、​`path`​ を使用できました) または汎用の ​`address`​ 属性を使用して設定できました。 汎用の ​`address`​ 属性を使用した場合、たとえば以下のようにプロパティを 参照できました。 ```xml ``` `External.URL`​ について設定されたプロパティは次のようになります。 ```text External.URL=http://0.0.0.0:8080/rootPath ``` Mule 4 では、コネクタが接続属性を個別に定義するため、完全なアドレスプロパティはコンポーネントに分割する必要があります。 ```xml ... ``` プロパティの設定は次のようになります。 ```text External.URL.host=0.0.0.0 External.URL.port=8080 External.URL.path=/rootPath ``` コネクタ固有のドキュメント (HTTP Connector や Email Connector 用のドキュメントなど) には、コネクタに必要な正確なプロパティに関する詳細が記載されています。 ## [](#service_overrides)サービスの上書き Mule 4 では、カスタム Java コードを使用したサービスの上書きのカスタマイズは サポートされていません。 Mule 3 では、コネクタの ​`service-overrides`​ 要素を使用してトランスポートの動作を カスタマイズできます。この要素により、 新しい機能を提供するカスタムコードを使用して Java クラスを参照できます。 Mule 3 の例: `service-overrides`​ を含むコネクタ ```xml ``` こうしたカスタマイズを Mule 4 に移行する方法は、 カスタムコードの動作に応じて異なるため、以下の方法が考えられます。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave)​ 変換、​[Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ などの他の Mule 機能やコンポーネントを使用してこの機能を提供する。 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して、カスタマイズした トランスポート機能を提供するコネクタを作成する。開始点として、オープンソースのコネクタを連動関係として使用できます (たとえば、​[https://github.com/mulesoft/mule-http-connector)。](https://github.com/mulesoft/mule-http-connector\)。) - 前の手法と同じように、オープンソースのコネクタリポジトリをフォークして、 カスタムコードをフォークに追加できます。MuleSoft では変更のプル要求を歓迎します。 - MuleSoft に機能要求を行う。​`service-overrides`​ を通じてカスタムコードで提供した機能を追加するよう MuleSoft に要求できます。こうした要求を 送信するには、 [MuleSoft サポートの「Ideas (アイデア)」](https://help.mulesoft.com/s/ideas)​にアクセスして ください。 ## [](#関連情報)関連情報 [コネクタとモジュールの Mule 4 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-connectors) [Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-java-integration) [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) # トランスポートの移行 Mule 3 トランスポートはコネクタに置き換えられており、コネクタは Mule 4 の操作モデルに従います。ほとんどの Mule トランスポートは、Mule 4 の対応するコネクタに 置き換え可能です。 すべてのトランスポートに共通の移行に関する問題がいくつかあります。トランスポート固有の 移行ドキュメントについては、 ​[「コネクタおよびモジュールの Mule 4 への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-connectors)​および その子ページを代わりに参照してください。 ## [](#address)エンドポイントアドレス Mule 3 では、エンドポイントはトランスポート固有の属性 (たとえば、HTTP エンドポイントは ​`host`​、​`port`​、​`path`​ を使用できました) または汎用の ​`address`​ 属性を使用して設定できました。 汎用の ​`address`​ 属性を使用した場合、たとえば以下のようにプロパティを 参照できました。 ```xml ``` `External.URL`​ について設定されたプロパティは次のようになります。 ```text External.URL=http://0.0.0.0:8080/rootPath ``` Mule 4 では、コネクタが接続属性を個別に定義するため、完全なアドレスプロパティはコンポーネントに分割する必要があります。 ```xml ... ``` プロパティの設定は次のようになります。 ```text External.URL.host=0.0.0.0 External.URL.port=8080 External.URL.path=/rootPath ``` コネクタ固有のドキュメント (HTTP Connector や Email Connector 用のドキュメントなど) には、コネクタに必要な正確なプロパティに関する詳細が記載されています。 ## [](#service_overrides)サービスの上書き Mule 4 では、カスタム Java コードを使用したサービスの上書きのカスタマイズは サポートされていません。 Mule 3 では、コネクタの ​`service-overrides`​ 要素を使用してトランスポートの動作を カスタマイズできます。この要素により、 新しい機能を提供するカスタムコードを使用して Java クラスを参照できます。 Mule 3 の例: `service-overrides`​ を含むコネクタ ```xml ``` こうしたカスタマイズを Mule 4 に移行する方法は、 カスタムコードの動作に応じて異なるため、以下の方法が考えられます。 - [DataWeave](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave)​ 変換、​[Java Module](https://docs.mulesoft.com/jp/java-module/latest/)​、​[Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/)​ などの他の Mule 機能やコンポーネントを使用してこの機能を提供する。 - [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/)​ を使用して、カスタマイズした トランスポート機能を提供するコネクタを作成する。開始点として、オープンソースのコネクタを連動関係として使用できます (たとえば、​[https://github.com/mulesoft/mule-http-connector)。](https://github.com/mulesoft/mule-http-connector\)。) - 前の手法と同じように、オープンソースのコネクタリポジトリをフォークして、 カスタムコードをフォークに追加できます。MuleSoft では変更のプル要求を歓迎します。 - MuleSoft に機能要求を行う。​`service-overrides`​ を通じてカスタムコードで提供した機能を追加するよう MuleSoft に要求できます。こうした要求を 送信するには、 [MuleSoft サポートの「Ideas (アイデア)」](https://help.mulesoft.com/s/ideas)​にアクセスして ください。 ## [](#関連情報)関連情報 [コネクタとモジュールの Mule 4 への移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-connectors) [Java インテグレーション](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-java-integration) [Mule SDK](https://docs.mulesoft.com/mule-sdk/latest/) # ハードウェアおよびソフトウェアの要件 Mule をオンプレミスでインストールして実行する場合は、インストール前にハードウェアとソフトウェアの最小要件を確認します。 ## [](#最小ハードウェア要件)最小ハードウェア要件 - 2 GHz の CPU または仮想環境の 1 仮想 CPU。 - 1 GB の RAM。 - 4 GB のストレージ。 レイテンシー要件と、アプリケーションで処理する同時メッセージのサイズおよび数に合わせて、RAM を調整します。 ## [](#必須ソフトウェア)必須ソフトウェア Mule をインストールする前に、サポートされているバージョンの Java を使用していることを確認してください。
ソフトウェア バージョン

JDK

JDK 1.8.0 または JDK 11
別の JDK を実行することもできますが、その JDK が原因で問題が発生した場合、MuleSoft は修正のためのサポートを提供したり、対応策を講じたりすることはありません。
## [](#サポート対象のソフトウェア)サポート対象のソフトウェア Mule は、サポート対象の JDK から Java Runtime Environment (JRE) を実行するすべてのオペレーティングシステムでサポートされます。 ### [](#テスト済みソフトウェア)テスト済みソフトウェア Mule Runtime Engine は、次のソフトウェアおよびオペレーティングシステムに対する機能テストに合格しました。
ソフトウェア バージョン

OS

MacOS 10.15、HP-UX 11i V3、AIX 7.2、Windows Server 2019、Windows 10、Solaris 11.3、RHEL 8、Ubuntu Server 20.04

JDK

Adoptium OpenJDK ディストリビューション
このバージョンの Mule Runtime Engine は Runtime Manager エージェントプラグインバージョン 2.4.5 にバンドルされています。Runtime Manager エージェントの互換性については、​[Runtime Manager エージェントのリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-manager-agent/runtime-manager-agent-release-notes)​を参照してください。 ## [](#関連情報)関連情報 - [Anypoint Platform PCE の前提条件](https://docs.mulesoft.com/private-cloud/latest/install-checklist) # ハードウェアおよびソフトウェアの要件 Mule をオンプレミスでインストールして実行する場合は、インストール前にハードウェアとソフトウェアの最小要件を確認します。 ## [](#最小ハードウェア要件)最小ハードウェア要件 - 2 GHz の CPU または仮想環境の 1 仮想 CPU。 - 1 GB の RAM。 - 4 GB のストレージ。 レイテンシー要件と、アプリケーションで処理する同時メッセージのサイズおよび数に合わせて、RAM を調整します。 Mule では、x86 および x64 アーキテクチャがサポートされています。 ## [](#必須ソフトウェア)必須ソフトウェア Mule をインストールする前に、サポートされているバージョンの Java を使用していることを確認してください。
ソフトウェア バージョン

JDK

JDK 1.8.0 または JDK 11
別の JDK を実行することもできますが、その JDK が原因で問題が発生した場合、MuleSoft は修正のためのサポートを提供したり、対応策を講じたりすることはありません。
## [](#サポート対象のソフトウェア)サポート対象のソフトウェア Mule は、サポート対象の JDK から Java Runtime Environment (JRE) を実行するすべてのオペレーティングシステムでサポートされます。 ### [](#テスト済みソフトウェア)テスト済みソフトウェア Mule Runtime Engine は、次のソフトウェアおよびオペレーティングシステムに対する機能テストに合格しました。
ソフトウェア バージョン

OS

MacOS 10.15、HP-UX 11i V3、AIX 7.2、Windows Server 2019、Windows 10、Solaris 11.3、Red Hat Enterprise Linux 8.8、Ubuntu Server 20.04

JDK

Adoptium OpenJDK ディストリビューション
このバージョンの Mule Runtime Engine は Runtime Manager エージェントプラグインバージョン 2.4.21 にバンドルされています。Runtime Manager エージェントの互換性については、​[Runtime Manager エージェントのリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-manager-agent/runtime-manager-agent-release-notes)​を参照してください。 ## [](#関連情報)関連情報 - [Anypoint Platform PCE の前提条件](https://docs.mulesoft.com/private-cloud/latest/install-checklist) # ハードウェアおよびソフトウェアの要件 Mule をオンプレミスでインストールして実行する場合は、インストール前にハードウェアとソフトウェアの最小要件を確認します。 ## [](#最小ハードウェア要件)最小ハードウェア要件 - 2 GHz の CPU または仮想環境の 1 仮想 CPU。 - 1 GB の RAM。 - 4 GB のストレージ。 レイテンシー要件と、アプリケーションで処理する同時メッセージのサイズおよび数に合わせて、RAM を調整します。 Mule では、x86 および x64 アーキテクチャがサポートされています。 ## [](#必須ソフトウェア)必須ソフトウェア Mule をインストールする前に、サポートされているバージョンの Java を使用していることを確認してください。
ソフトウェア バージョン

JDK

JDK 1.8.0 または JDK 11
別の JDK を実行することもできますが、その JDK が原因で問題が発生した場合、MuleSoft は修正のためのサポートを提供したり、対応策を講じたりすることはありません。
## [](#サポート対象のソフトウェア)サポート対象のソフトウェア Mule は、サポート対象の JDK から Java Runtime Environment (JRE) を実行するすべてのオペレーティングシステムでサポートされます。 ### [](#テスト済みソフトウェア)テスト済みソフトウェア Mule Runtime Engine は、次のソフトウェアおよびオペレーティングシステムに対する機能テストに合格しました。
ソフトウェア バージョン

OS

MacOS 10.15、HP-UX 11i V3、AIX 7.2、Windows Server 2019、Windows 10、Solaris 11.3、Red Hat Enterprise Linux 8.8、Ubuntu Server 20.04

JDK

Adoptium OpenJDK ディストリビューション
このバージョンの Mule Runtime Engine は Runtime Manager エージェントプラグインバージョン 2.4.21 にバンドルされています。Runtime Manager エージェントの互換性については、​[Runtime Manager エージェントのリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-manager-agent/runtime-manager-agent-release-notes)​を参照してください。 ## [](#関連情報)関連情報 - [Anypoint Platform PCE の前提条件](https://docs.mulesoft.com/private-cloud/latest/install-checklist) # ハードウェアおよびソフトウェアの要件 Mule をオンプレミスでインストールして実行する場合は、インストール前にハードウェアとソフトウェアの最小要件を確認します。 ## [](#最小ハードウェア要件)最小ハードウェア要件 - 2 GHz の CPU または仮想環境の 1 仮想 CPU。 - 1 GB の RAM。 - 4 GB のストレージ。 レイテンシー要件と、アプリケーションで処理する同時メッセージのサイズおよび数に合わせて、RAM を調整します。 Mule では、x86 および x64 アーキテクチャがサポートされています。 ## [](#必須ソフトウェア)必須ソフトウェア Mule をインストールする前に、サポートされているバージョンの Java を使用していることを確認してください。
ソフトウェア バージョン

JDK

JDK 1.8.0、JDK 11、JDK 17
別の JDK を実行することもできますが、その JDK が原因で問題が発生した場合、MuleSoft は修正のためのサポートを提供したり、対応策を講じたりすることはありません。
## [](#サポート対象のソフトウェア)サポート対象のソフトウェア Mule は、サポート対象の JDK から Java Runtime Environment (JRE) を実行するすべてのオペレーティングシステムでサポートされます。 ### [](#テスト済みソフトウェア)テスト済みソフトウェア Mule Runtime Engine は、次のソフトウェアおよびオペレーティングシステムに対する機能テストに合格しました。
ソフトウェア バージョン

OS

MacOS 10.15、HP-UX 11i V3、AIX 7.2、Windows Server 2019、Windows 10、Solaris 11.3、Red Hat Enterprise Linux 9.4、Ubuntu Server 20.04

JDK

Adoptium OpenJDK ディストリビューション
このバージョンの Mule Runtime Engine は Runtime Manager エージェントプラグインバージョン 2.4.21 にバンドルされています。Runtime Manager エージェントの互換性については、​[Runtime Manager エージェントのリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-manager-agent/runtime-manager-agent-release-notes)​を参照してください。 ## [](#関連情報)関連情報 - [Anypoint Platform PCE の前提条件](https://docs.mulesoft.com/private-cloud/latest/install-checklist) # ハードウェアおよびソフトウェアの要件 Mule をオンプレミスでインストールして実行する場合は、インストール前にハードウェアとソフトウェアの最小要件を確認します。 ## [](#最小ハードウェア要件)最小ハードウェア要件 - 2 GHz の CPU または仮想環境の 1 仮想 CPU。 - 1 GB の RAM。 - 4 GB のストレージ。 レイテンシー要件と、アプリケーションで処理する同時メッセージのサイズおよび数に合わせて、RAM を調整します。 Mule では、x86 および x64 アーキテクチャがサポートされています。 ## [](#必須ソフトウェア)必須ソフトウェア Mule をインストールする前に、サポートされているバージョンの Java を使用していることを確認してください。
ソフトウェア バージョン

JDK

JDK 1.8.0、JDK 11、JDK 17
別の JDK を実行することもできますが、その JDK が原因で問題が発生した場合、MuleSoft は修正のためのサポートを提供したり、対応策を講じたりすることはありません。
## [](#サポート対象のソフトウェア)サポート対象のソフトウェア Mule は、サポート対象の JDK から Java Runtime Environment (JRE) を実行するすべてのオペレーティングシステムでサポートされます。 ### [](#テスト済みソフトウェア)テスト済みソフトウェア Mule Runtime Engine は、次のソフトウェアおよびオペレーティングシステムに対する機能テストに合格しました。
ソフトウェア バージョン

OS

MacOS 10.15、HP-UX 11i V3、AIX 7.2、Windows Server 2019、Windows 10、Solaris 11.3、Red Hat Enterprise Linux 8.8、Ubuntu Server 20.04

JDK

Adoptium OpenJDK ディストリビューション
このバージョンの Mule Runtime Engine は Runtime Manager エージェントプラグインバージョン 2.4.21 にバンドルされています。Runtime Manager エージェントの互換性については、​[Runtime Manager エージェントのリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-manager-agent/runtime-manager-agent-release-notes)​を参照してください。 ## [](#関連情報)関連情報 - [Anypoint Platform PCE の前提条件](https://docs.mulesoft.com/private-cloud/latest/install-checklist) # ハードウェアおよびソフトウェアの要件 Mule をオンプレミスでインストールして実行する場合は、インストール前にハードウェアとソフトウェアの最小要件を確認します。 ## [](#最小ハードウェア要件)最小ハードウェア要件 - 2 GHz の CPU または仮想環境の 1 仮想 CPU。 - 1 GB の RAM。 - 4 GB のストレージ。 レイテンシー要件と、アプリケーションで処理する同時メッセージのサイズおよび数に合わせて、RAM を調整します。 Mule では、x86 および x64 アーキテクチャがサポートされています。 ## [](#必須ソフトウェア)必須ソフトウェア Mule をインストールする前に、サポートされているバージョンの Java を使用していることを確認してください。
ソフトウェア バージョン

JDK

JDK 1.8.0、JDK 11、JDK 17
別の JDK を実行することもできますが、その JDK が原因で問題が発生した場合、MuleSoft は修正のためのサポートを提供したり、対応策を講じたりすることはありません。
## [](#サポート対象のソフトウェア)サポート対象のソフトウェア Mule は、サポート対象の JDK から Java Runtime Environment (JRE) を実行するすべてのオペレーティングシステムでサポートされます。 ### [](#テスト済みソフトウェア)テスト済みソフトウェア Mule Runtime Engine は、次のソフトウェアおよびオペレーティングシステムに対する機能テストに合格しました。
ソフトウェア バージョン

OS

MacOS 10.15、HP-UX 11i V3、AIX 7.2、Windows Server 2019、Windows 10、Solaris 11.3、Red Hat Enterprise Linux 9.4、Ubuntu Server 20.04

JDK

Adoptium OpenJDK ディストリビューション
このバージョンの Mule Runtime Engine は Runtime Manager エージェントプラグインバージョン 2.4.21 にバンドルされています。Runtime Manager エージェントの互換性については、​[Runtime Manager エージェントのリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-manager-agent/runtime-manager-agent-release-notes)​を参照してください。 ## [](#関連情報)関連情報 - [Anypoint Platform PCE の前提条件](https://docs.mulesoft.com/private-cloud/latest/install-checklist) # ハードウェアおよびソフトウェアの要件 Mule をオンプレミスでインストールして実行する場合は、インストール前にハードウェアとソフトウェアの最小要件を確認します。 ## [](#最小ハードウェア要件)最小ハードウェア要件 - 2 GHz の CPU または仮想環境の 1 仮想 CPU。 - 1 GB の RAM。 - 4 GB のストレージ。 レイテンシー要件と、アプリケーションで処理する同時メッセージのサイズおよび数に合わせて、RAM を調整します。 Mule では、x86 および x64 アーキテクチャがサポートされています。 ## [](#必須ソフトウェア)必須ソフトウェア Mule をインストールする前に、サポートされているバージョンの Java を使用していることを確認してください。
ソフトウェア バージョン

JDK

JDK 17
別の JDK を実行することもできますが、その JDK が原因で問題が発生した場合、MuleSoft は修正のためのサポートを提供したり、対応策を講じたりすることはありません。
## [](#サポート対象のソフトウェア)サポート対象のソフトウェア Mule は、サポート対象の JDK から Java Runtime Environment (JRE) を実行するすべてのオペレーティングシステムでサポートされます。 ### [](#テスト済みソフトウェア)テスト済みソフトウェア Mule Runtime Engine は、次のソフトウェアおよびオペレーティングシステムに対する機能テストに合格しました。
ソフトウェア バージョン

OS

MacOS 10.15、HP-UX 11i V3、AIX 7.2、Windows Server 2019、Windows 10、Solaris 11.3、Red Hat Enterprise Linux 9.4、Ubuntu Server 20.04

JDK

Adoptium OpenJDK ディストリビューション
このバージョンの Mule Runtime Engine は Runtime Manager エージェントプラグインバージョン 2.4.21 にバンドルされています。Runtime Manager エージェントの互換性については、​[Runtime Manager エージェントのリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-manager-agent/runtime-manager-agent-release-notes)​を参照してください。 ## [](#関連情報)関連情報 - [Anypoint Platform PCE の前提条件](https://docs.mulesoft.com/private-cloud/latest/install-checklist) # バックエンドサーバーの応答時間 パフォーマンスの問題をトラブルシューティングするには、まず、フローが接続されているリモートホストのレイテンシーによってフローのパフォーマンスが大きく影響されるかどうかを調べます。 アプリケーションとリモートホストの間の通信の複雑さによってフローに付加されるパフォーマンスオーバーヘッドを考慮しないと、最適化が効果を発揮せず、パフォーマンスがほとんど改善されない場合があります。 そのため、Mule アプリケーションの最適化を開始する前に、バックエンドサーバーの平均レイテンシーとスループットを数値化して、アプリケーションの拡張性やパフォーマンスの妨げになっていないかどうかを判断することが重要です。 考慮すべき点をいくつか挙げます。 - アプリケーションとリモートホストとの間で交換されるペイロードの平均サイズ - アプリケーションとリモートホストの物理的な位置に起因するネットワークレイテンシー アプリケーションとリモートホストが同じネットワーク、同じ地域、同じ国に存在するのか、あるいはそれぞれが地球の反対側に存在するのかを確認します。 - リモートホストの応答時間。 リモートホストがアプリケーションと同じネットワーク境界内に存在すれば、アプリケーションのスループットと応答時間は良好な状態となります。一方で、アプリケーションのローカルネットワークの外にリモートホストが存在する場合は、ペイロードサイズには関係なく、リモートホストの応答時間に直接比例してレイテンシーが増大します。 アプリケーションのスループットに影響する他の要因としては、外部の連動関係、同時実行数、フローの複雑さ、デプロイメントの特性、マシンの構成などがあります。 # バックエンドサーバーの応答時間 パフォーマンスの問題をトラブルシューティングするには、まず、フローが接続されているリモートホストのレイテンシーによってフローのパフォーマンスが大きく影響されるかどうかを調べます。 アプリケーションとリモートホストの間の通信の複雑さによってフローに付加されるパフォーマンスオーバーヘッドを考慮しないと、最適化が効果を発揮せず、パフォーマンスがほとんど改善されない場合があります。 そのため、Mule アプリケーションの最適化を開始する前に、バックエンドサーバーの平均レイテンシーとスループットを数値化して、アプリケーションの拡張性やパフォーマンスの妨げになっていないかどうかを判断することが重要です。 考慮すべき点をいくつか挙げます。 - アプリケーションとリモートホストとの間で交換されるペイロードの平均サイズ - アプリケーションとリモートホストの物理的な位置に起因するネットワークレイテンシー アプリケーションとリモートホストが同じネットワーク、同じ地域、同じ国に存在するのか、あるいはそれぞれが地球の反対側に存在するのかを確認します。 - リモートホストの応答時間。 リモートホストがアプリケーションと同じネットワーク境界内に存在すれば、アプリケーションのスループットと応答時間は良好な状態となります。一方で、アプリケーションのローカルネットワークの外にリモートホストが存在する場合は、ペイロードサイズには関係なく、リモートホストの応答時間に直接比例してレイテンシーが増大します。 アプリケーションのスループットに影響する他の要因としては、外部の連動関係、同時実行数、フローの複雑さ、デプロイメントの特性、マシンの構成などがあります。 # バックエンドサーバーの応答時間 パフォーマンスの問題をトラブルシューティングするには、まず、フローが接続されているリモートホストのレイテンシーによってフローのパフォーマンスが大きく影響されるかどうかを調べます。 アプリケーションとリモートホストの間の通信の複雑さによってフローに付加されるパフォーマンスオーバーヘッドを考慮しないと、最適化が効果を発揮せず、パフォーマンスがほとんど改善されない場合があります。 そのため、Mule アプリケーションの最適化を開始する前に、バックエンドサーバーの平均レイテンシーとスループットを数値化して、アプリケーションの拡張性やパフォーマンスの妨げになっていないかどうかを判断することが重要です。 考慮すべき点をいくつか挙げます。 - アプリケーションとリモートホストとの間で交換されるペイロードの平均サイズ - アプリケーションとリモートホストの物理的な位置に起因するネットワークレイテンシー アプリケーションとリモートホストが同じネットワーク、同じ地域、同じ国に存在するのか、あるいはそれぞれが地球の反対側に存在するのかを確認します。 - リモートホストの応答時間。 リモートホストがアプリケーションと同じネットワーク境界内に存在すれば、アプリケーションのスループットと応答時間は良好な状態となります。一方で、アプリケーションのローカルネットワークの外にリモートホストが存在する場合は、ペイロードサイズには関係なく、リモートホストの応答時間に直接比例してレイテンシーが増大します。 アプリケーションのスループットに影響する他の要因としては、外部の連動関係、同時実行数、フローの複雑さ、デプロイメントの特性、マシンの構成などがあります。 # バックエンドサーバーの応答時間 パフォーマンスの問題をトラブルシューティングするには、まず、フローが接続されているリモートホストのレイテンシーによってフローのパフォーマンスが大きく影響されるかどうかを調べます。 アプリケーションとリモートホストの間の通信の複雑さによってフローに付加されるパフォーマンスオーバーヘッドを考慮しないと、最適化が効果を発揮せず、パフォーマンスがほとんど改善されない場合があります。 そのため、Mule アプリケーションの最適化を開始する前に、バックエンドサーバーの平均レイテンシーとスループットを数値化して、アプリケーションの拡張性やパフォーマンスの妨げになっていないかどうかを判断することが重要です。 考慮すべき点をいくつか挙げます。 - アプリケーションとリモートホストとの間で交換されるペイロードの平均サイズ - アプリケーションとリモートホストの物理的な位置に起因するネットワークレイテンシー アプリケーションとリモートホストが同じネットワーク、同じ地域、同じ国に存在するのか、あるいはそれぞれが地球の反対側に存在するのかを確認します。 - リモートホストの応答時間。 リモートホストがアプリケーションと同じネットワーク境界内に存在すれば、アプリケーションのスループットと応答時間は良好な状態となります。一方で、アプリケーションのローカルネットワークの外にリモートホストが存在する場合は、ペイロードサイズには関係なく、リモートホストの応答時間に直接比例してレイテンシーが増大します。 アプリケーションのスループットに影響する他の要因としては、外部の連動関係、同時実行数、フローの複雑さ、デプロイメントの特性、マシンの構成などがあります。 # バックエンドサーバーの応答時間 パフォーマンスの問題をトラブルシューティングするには、まず、フローが接続されているリモートホストのレイテンシーによってフローのパフォーマンスが大きく影響されるかどうかを調べます。 アプリケーションとリモートホストの間の通信の複雑さによってフローに付加されるパフォーマンスオーバーヘッドを考慮しないと、最適化が効果を発揮せず、パフォーマンスがほとんど改善されない場合があります。 そのため、Mule アプリケーションの最適化を開始する前に、バックエンドサーバーの平均レイテンシーとスループットを数値化して、アプリケーションの拡張性やパフォーマンスの妨げになっていないかどうかを判断することが重要です。 考慮すべき点をいくつか挙げます。 - アプリケーションとリモートホストとの間で交換されるペイロードの平均サイズ - アプリケーションとリモートホストの物理的な位置に起因するネットワークレイテンシー アプリケーションとリモートホストが同じネットワーク、同じ地域、同じ国に存在するのか、あるいはそれぞれが地球の反対側に存在するのかを確認します。 - リモートホストの応答時間。 リモートホストがアプリケーションと同じネットワーク境界内に存在すれば、アプリケーションのスループットと応答時間は良好な状態となります。一方で、アプリケーションのローカルネットワークの外にリモートホストが存在する場合は、ペイロードサイズには関係なく、リモートホストの応答時間に直接比例してレイテンシーが増大します。 アプリケーションのスループットに影響する他の要因としては、外部の連動関係、同時実行数、フローの複雑さ、デプロイメントの特性、マシンの構成などがあります。 # バックエンドサーバーの応答時間 パフォーマンスの問題をトラブルシューティングするには、まず、フローが接続されているリモートホストのレイテンシーによってフローのパフォーマンスが大きく影響されるかどうかを調べます。 アプリケーションとリモートホストの間の通信の複雑さによってフローに付加されるパフォーマンスオーバーヘッドを考慮しないと、最適化が効果を発揮せず、パフォーマンスがほとんど改善されない場合があります。 そのため、Mule アプリケーションの最適化を開始する前に、バックエンドサーバーの平均レイテンシーとスループットを数値化して、アプリケーションの拡張性やパフォーマンスの妨げになっていないかどうかを判断することが重要です。 考慮すべき点をいくつか挙げます。 - アプリケーションとリモートホストとの間で交換されるペイロードの平均サイズ - アプリケーションとリモートホストの物理的な位置に起因するネットワークレイテンシー アプリケーションとリモートホストが同じネットワーク、同じ地域、同じ国に存在するのか、あるいはそれぞれが地球の反対側に存在するのかを確認します。 - リモートホストの応答時間。 リモートホストがアプリケーションと同じネットワーク境界内に存在すれば、アプリケーションのスループットと応答時間は良好な状態となります。一方で、アプリケーションのローカルネットワークの外にリモートホストが存在する場合は、ペイロードサイズには関係なく、リモートホストの応答時間に直接比例してレイテンシーが増大します。 アプリケーションのスループットに影響する他の要因としては、外部の連動関係、同時実行数、フローの複雑さ、デプロイメントの特性、マシンの構成などがあります。 # バックエンドサーバーの応答時間 パフォーマンスの問題をトラブルシューティングするには、まず、フローが接続されているリモートホストのレイテンシーによってフローのパフォーマンスが大きく影響されるかどうかを調べます。 アプリケーションとリモートホストの間の通信の複雑さによってフローに付加されるパフォーマンスオーバーヘッドを考慮しないと、最適化が効果を発揮せず、パフォーマンスがほとんど改善されない場合があります。 そのため、Mule アプリケーションの最適化を開始する前に、バックエンドサーバーの平均レイテンシーとスループットを数値化して、アプリケーションの拡張性やパフォーマンスの妨げになっていないかどうかを判断することが重要です。 考慮すべき点をいくつか挙げます。 - アプリケーションとリモートホストとの間で交換されるペイロードの平均サイズ - アプリケーションとリモートホストの物理的な位置に起因するネットワークレイテンシー アプリケーションとリモートホストが同じネットワーク、同じ地域、同じ国に存在するのか、あるいはそれぞれが地球の反対側に存在するのかを確認します。 - リモートホストの応答時間。 リモートホストがアプリケーションと同じネットワーク境界内に存在すれば、アプリケーションのスループットと応答時間は良好な状態となります。一方で、アプリケーションのローカルネットワークの外にリモートホストが存在する場合は、ペイロードサイズには関係なく、リモートホストの応答時間に直接比例してレイテンシーが増大します。 アプリケーションのスループットに影響する他の要因としては、外部の連動関係、同時実行数、フローの複雑さ、デプロイメントの特性、マシンの構成などがあります。 # バッチコンポーネントリファレンス Mule バッチコンポーネントでは、デフォルトのコンポーネント設定に対する調整を最小限に抑えてレコードのバッチ処理を管理します。コンポーネントは、処理およびパフォーマンスに関する特定の要件に合わせて高度に設定可能です。 Batch Job コンポーネントには 1 つ以上の Batch Step コンポーネントが含まれている必要があります。必要に応じて、各 Batch Step コンポーネントには 1 つの Batch Aggregator コンポーネントを含めることができます。次の図の Mule フローはバッチコンポーネントを示しています。 ![Studio 内の Mule フローのバッチ処理コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/batch-flow-generic-example.png) Batch Job コンポーネントでは Mule メッセージのペイロードをレコードに分割します。Batch Step コンポーネントおよび Batch Aggregator コンポーネント内で、これらのレコードはキーワード ​`payload`​ で使用でき、Mule 変数は ​`vars`​ キーワードを使用してアクセスすることもできます。ただし、Mule 属性はこれらのコンポーネント内からアクセスできません。どちらのコンポーネントも ​`attributes`​ で ​`null`​ を返します。 このリファレンスでは、読者が Batch Job インスタンスの​[バッチ処理フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases)​に精通していることを前提としています。 ## [](#ref_batch_job_component)Batch Job コンポーネント () このコンポーネントでは、処理用の入力を準備し、その処理の結果が記載されたレポートを出力します。準備は Batch Job インスタンスの ​[Load and Dispatch](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases#phase_load_dispatch)​ フェーズ中に行われ、レポートは ​[On Complete](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases#phase_on_complete)​ フェーズで使用できます。 Studio では、これらのプロパティをコンポーネントの ​[\[General (一般)\]](#ref_batch_job_general_fields)​ タブと ​[\[History (履歴)\]](#ref_batch_job_history_fields)​ タブで設定できます。 ### [](#ref_batch_job_general_fields)Batch Job のプロパティ Batch Job コンポーネントには、バッチ処理の実行方法を決定する設定可能な多数のプロパティが用意されています。また、入力ペイロードをフローの後続のコンポーネントで使用できるように対象変数に格納することもできます。Batch Job コンポーネントはメッセージペイロードをコンシュームするため、これは便利な可能性があります。 Anypoint Studio の ​**\[General (一般)\]**​ タブには次の項目があります。 ![Studio の Batch Job の項目](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/batch-job-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
Field Name (項目名) XML 説明

Name (名前)

name

Batch Job コンポーネントの設定可能な名前。デフォルトの名前はアプリケーションの名前に ​Batch_Job​ を追加したものです。

Max Failed Records (最大失敗レコード数)

maxFailedRecords

Batch Job インスタンスの実行が停止する前にその Batch Job インスタンス内で失敗できるレコードの最大数。デフォルトは ​0​ です。無制限にする場合は、​-1​ を使用します。この設定は、Batch Job コンポーネント内の ​Batch Step コンポーネント​のどの受け入れポリシー (​acceptPolicy​) または式 (​acceptExpression​) 検索条件よりも優先されます。Batch Job インスタンスが ​maxFailedRecords​ 値を超えると、Batch Job コンポーネントでエラーが発生した Batch Job インスタンスの処理が停止され、インスタンスに状況 ​FAILED_PROCESS_RECORDS​ が割り当てられ、インスタンスで失敗したレコードの数が報告されます。Batch Job インスタンスがこのしきい値に達すると、コンソールでは次のようなメッセージが出力されます (読みやすいように編集済み)。

INFO  ... DefaultBatchEngine:
 instance '6d85c380-f332-11ec-bb5f-147ddaaf4f97' of job 'Batch_Job_in_Mule_Flow'
 has reached the max allowed number of failed records. Record will be added to
 failed list and the instance will be removed from execution pool.
...
INFO  ... DefaultBatchEngine:
 instance 6d85c380-f332-11ec-bb5f-147ddaaf4f97 of job Batch_Job_in_Mule_Flow
 has been stopped. Instance status is FAILED_PROCESS_RECORDS

Batch Job インスタンス内の並列処理により、複数のレコードで同時に失敗できるようになるため、エラー数が設定した最大値を超えることができます。

Scheduling Strategy (スケジュール戦略)

schedulingStrategy

Batch Job コンポーネントが繰り返しトリガーする場合、複数の Batch Job インスタンスを同時に実行するように準備できます。インスタンスは作成タイムスタンプに基づいて (デフォルト)、または使用可能なリソースの使用を最大化しようとするラウンドロビンアルゴリズムに従って順次実行できます。この設定は、処理順序が保証されないため、他のレコードに対する副作用や連動関係がないジョブのみに適しています。

  • ORDERED_SQUENTIAL​ (デフォルト): この設定では、Batch Job インスタンスは作成タイムスタンプで確立された順序で一度に 1 つずつ実行されます。先に作成されたインスタンスが後の日時に作成されたインスタンスの前に実行されます。

  • ROUND_ROBIN​: この設定では、すべての Batch Job インスタンスが使用可能なリソースを割り当てるラウンドロビンアルゴリズムに基づいて実行されます。実行の順序は事前に決定されません。バッチインスタンスはどの順序でも実行できます。このオプションが適しているのは、インスタンスの実行で別のインスタンスの実行に対する副作用が発生しないことが確かな場合のみです。ベストプラクティスは次のとおりです。

    • 同時に実行される Batch Job インスタンスで同じレコードが更新されるのを避けるために、この戦略をデータ同期ジョブに使用しないでください。データを同期するときにこの戦略を使用すると、事前に誤ったバージョンのデータで結果を返すことが可能になります。

    • Batch Job でデータベースから新しいレコードのみを取得する場合など、Batch Job コンポーネント内の別のレコードの処理に依存するレコードがないことが確かな場合に、この戦略を使用して Batch Job インスタンスを並列実行するようにしてください。

Job Instance ID (ジョブインスタンス ID)

jobInstanceId

バッチインスタンスの認識可能な一意の名前を提供する省略可能な式。名前を一意にするには、この項目内でたとえば ​#[jobInstanceId="#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]​ などの DataWeave 式を使用する必要があります。式で同じ値が 2 回以上返される場合、Mule では ​Batch Job 'my-batch-job-example' already has an instance with id 'my-repeated-id'​ のようなメッセージでエラーがスローされます。Batch Job コンポーネントではこの値を使用して Mule フローが Batch Job コンポーネントに達するたびに新しい識別子を作成します。ID を指定しないと、Mule によって各 Batch Job インスタンスの識別子となる UUID が自動的に作成されます。

Batch Block Size (バッチブロックサイズ)

blockSize

レコードブロックあたりの処理するレコードの件数。デフォルトはブロックあたり ​100​ 件のレコードです。処理できるレコードが設定したサイズより少ない場合、Mule によってレコードプロセッサーに送信されるブロックのサイズが小さくなります。このような状況は、たとえば、1010 件のレコードがあり、ブロックサイズが 100 の場合に発生する可能性があります。これは、剰余が 0 ではなく 10 であるためです。ブロックサイズの設定により、各ブロックのレコードのサイズと ​maxConcurrency​ 設定の影響を受けるパフォーマンスを調整できます。

Max Concurrency (最大同時実行)

maxConcurrency

コンポーネント内でレコードブロックを処理するときに許可する並列性の最大レベルを設定するプロパティ。デフォルトは CPU で使用可能なコア数の 2 倍です。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。​blockSize​ 設定と同様、この設定により、パフォーマンスを調整できます。

変換先

target

Batch Job コンポーネントの​後​に配置されたコンポーネントの Batch Job インスタンスで受け取られたペイロードを使用するには、​target​ の一意の値を指定して、ダウンストリームコンポーネントの ​payload​ を使用してそのペイロードにアクセスします。対象値がない場合、Batch Job コンポーネントへの入力ペイロードをダウンストリームコンポーネントで使用できません。対象変数についての詳細は、対象変数を使用したデータの強化 を参照してください。デフォルト値はありません。
### [](#ref_batch_job_history_fields)Batch Job 履歴 () Batch Job 履歴設定により、Batch Job インスタンスの履歴データが一時的な Mule ディレクトリで保持される期間を調整することにより、​`No space left on device`​ エラーを解決できます。このエラーは、空きディスクスペース、または指定したサイズの CloudHub ワーカーに対して処理するレコードの頻度が高すぎるか数が多すぎて処理できない場合に発生する可能性があります。 デフォルトでは、Batch Job インスタンスの履歴は 7 日間保持されます。この期間が経過すると、監視プロセスによりその履歴が自動的に削除されます。 ![Studio の Batch Job 履歴の項目](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/batch-job-fields-history-studio.png) 次の表に、各項目と項目の XML 属性を示します。
Name (名前) XML 説明

Max Age (最長有効期間)

maxAge

ジョブインスタンスが期限切れになる前の最長有効期間。例: expiration maxAge="10"​。デフォルト: maxAge=7​。

Time Unit (時間単位)

ageUnit

maxAge​ に適用する時間の単位。有効な値: DAYS​、​HOURS​、​MILLISECONDS​、​MINUTES​、​SECONDS​。デフォルト: ageUnit=DAYS​。
これらの項目は、​``​ 内に埋め込まれる ​``​ 要素に対する属性です。 ```xml ``` XML の例は、バッチ履歴項目の設定に焦点を絞るために編集されています。 ## [](#ref_batch_step_component)Batch Step コンポーネント () Batch Step コンポーネントは、Load and Dispatch フェーズや On Complete フェーズ中ではなく、Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases#phase_process)​中に実行されます。 Batch Job コンポーネント内には 1 つ以上の Batch Step コンポーネントが必要です。Batch Step コンポーネントの名前を変更するだけでなく、コンポーネントがコンポーネント内の処理に受け入れるレコードを決定する​_検索条件_​を設定できます。コンポーネントに追加したプロセッサーは、Batch Job コンポーネントが受け入れるレコードに対するアクションを実行します。 ![Studio の Batch Step の項目](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/batch-step-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
Field Name (項目名) XML 説明

Name (名前)

name

Batch Step コンポーネントの設定可能な名前。Batch Job コンポーネント内の最初の Batch Step コンポーネントでは、デフォルトは ​Batch_Step​ です。後続のステップでは、​Batch_Step1​、​Batch_Step2​、といった順序に従い、一意の番号が名前に付加されます。

Accept Expression (受け入れ式)

acceptExpression

コンポーネントでレコードを処理するかどうかを決定する検索条件の省略可能な DataWeave 式。レコードの ​acceptExpression ​と​ ​acceptPolicy​ の​両方​の値が ​true​ に評価される場合、コンポーネントでは処理するためにレコードを受け入れます。それ以外の場合、コンポーネントではレコードをスキップし、レコードはダウンストリームの Batch Step コンポーネントで使用可能になります。例:

  • age​ 項目があるペイロードでは ​acceptExpression="#[payload.age > 21]"​

  • name​ 項目があるペイロードでは ​acceptExpression="#[not isBlank(payload.name)]"​。

Accept Policy (受け入れポリシー)

acceptPolicy

ポリシーがそのレコードで ​true​ に評価される場合のみ処理するためにレコードを受け入れます。受け入れの基準を、Batch Job コンポーネント内の​先行する​ (アップストリームの) Batch Step コンポーネントでレコードの処理に成功したか失敗したかにできます。コンポーネントは、正常に処理されたレコードのみを処理する、正常に処理できなかったレコードのみを処理する、または正常に処理されたかどうかに関係なくすべてのレコードを処理するように設定できます。デフォルトは ​NO_FAILURES​ です。​acceptPolicy​ はコンポーネントのどの ​acceptExpression​ よりも前に評価され、​Batch Job コンポーネント​の ​maxFailedRecords​ 設定は ​acceptPolicy​ 設定よりも優先される点に注意してください。

  • NO_FAILURES​: デフォルト設定。レコードが先行する Batch Step コンポーネント内で処理に失敗したことがない場合、またはアップストリームの Batch Step コンポーネントがない場合にレコードを処理するために受け入れます。

  • ONLY_FAILURES​: レコードが先行する Batch Step コンポーネント内で処理に失敗した場合にレコードを処理するために受け入れます。

  • ALL​: 先行する Batch Step コンポーネント内での処理に成功したか失敗したかに関係なくレコードを処理するために受け入れます。
## [](#ref_batch_aggregator_component)Batch Aggregator コンポーネント () Batch Aggregator コンポーネントはレコードの配列に対してアクションを実行する省略可能なコンポーネントです。集計は Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases#phase_process)​中に行われます。 Batch Aggregator コンポーネントにはデフォルトの設定はありません。このコンポーネントを使用する場合は、レコードをストリーミングするか (​`streaming`​)、キューから固定サイズ (​`size`​) の別の配列にレコードを取り込むか、どちらも行わないかを指定する必要があります。これらの設定は相互に排他的です。ストリーミングされたレコードへのランダムアクセスはできません。 Batch Aggregator コンポーネントではメッセージ ​`payload`​ として 1 つ以上のプロセッサーを受け入れます。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.4/for-each-scope-concept)​ スコープなど、アグリゲーター内のスコープを使用して各レコードに対して反復し、スコープ内の子プロセッサーが個別に各レコードに対するアクションを実行できるようにするのが一般的です。 Batch Aggregator コンポーネントにより、固定サイズ (​`size`​) として集計しているレコードの一部にアクセスする場合に必要な MIME タイプのレコード (​`preserveMimeTypes`​) を保持することもできます。​[「集約されたレコードの MIME タイプの保持」](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-filters-and-batch-aggregator#preserving-the-mime-types-of-the-aggregated-records)​を参照してください。このコンポーネント内のレコード処理についての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases#batch_aggregator_processing)​のバッチ集計に関する情報を参照してください。 [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#upsert)​ などの一部のコネクタには、バッチ集計プロセスを失敗させることなくレコードレベルのエラーを処理できる操作が用意されています。 Batch Aggregator を使用するときは、次の制限事項を考慮してください。 - Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java ​`Map`​ を使用してシリアル化の問題を回避します。 - Batch Aggregator コンポーネントでは、ジョブインスタンス全体の​[トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management)​がサポートされません。Batch Step コンポーネント内で、各レコードを個別のトランザクションで処理するトランザクションを定義できます。ただし、Batch Step コンポーネントによって開始されたトランザクションは、Batch Aggregator コンポーネントが処理を開始する前に終了します。トランザクションはコンポーネント間の境界を越えることができないため、コンポーネントはトランザクションを共有できます。 ![Studio の Batch Aggregator の項目](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/batch-aggregator-fields-studio.png) 次の表に、各項目と項目の XML 要素を示します。
Field Name (項目名) XML 説明

Display Name (表示名)

doc:name

コンポーネントの設定可能な名前。例: doc:name="My Aggregator"​。デフォルトの名前は ​Batch Aggregator​ です。

Aggregator Size (Aggregator サイズ)

size

処理するレコードの各配列のサイズ。デフォルトのサイズはありません。コンポーネント内のプロセッサーは入力として配列を受け入れる必要があります。コンポーネントはレコードを残りがなくなるまでバッチステッピングキューから設定したサイズの配列に取り込み続けます。キューに含まれるレコードが設定したサイズより少ない場合、コンポーネントがこれらのレコードを処理するための取り込み先の配列が小さくなります。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

この設定を使用するときは、コンポーネントは Batch Step コンポーネントがインスタンスまたはバッチのすべてのレコードの処理を完了するのを待機しません。ステッピングキューで設定した数のレコードが使用可能になると、Batch Aggregator コンポーネントはこれらのレコードを配列に取り込んで処理します。

ストリーミング

streaming

streaming=true​ の場合、コンポーネントは Batch Job インスタンスのすべてのレコードに対するアクションを実行し、インスタンスのレコード数と同じサイズの配列で結果を返します。Batch Job コンポーネントを使用してバッチサイズを設定しても、処理するレコード数または配列で返すレコード数は制限されません。たとえば、Aggregator が ​{"id": 1}​、​{"id": 2}​、といった形式の ​10​ 個のレコードのみを処理する小さな Batch Job インスタンスの数値の ID を返すとします。この場合、Batch Job コンポーネントの ​blockSize​ が ​5​ のようにインスタンスのレコード数より小さい数に設定されていたとしても、インスタンスの出力配列には ​[1, 6, 2, 7, 3, 8, 4, 9, 5, 10]​ などの 10 個の ID が含まれます。

プロセッサーはストリーミングされたレコードの配列に順次アクセスできます。Aggregator では処理されたレコードが保持されないため、ストリーミングされたレコードへのランダムアクセスはできません。

デフォルトはありません。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

Preserve Mime Types (MIME タイプを保持)

preserveMimeTypes

デフォルトは ​false​ です。このコンポーネント内で処理されるレコードの MIME タイプを保持するには、この属性を ​true​ に設定します。 データの MIME タイプを判断できないプロセッサーは、​null​ や、​[[B@e596d5c, [B@1c4c3b32], …​]​ などの判読できないペイロードへの参照を出力として返します。​preserveMimeTypes=true​ の設定は、コンポーネントが固定数 (​size​) のレコードを処理するように設定されている場合に便利です。
集計されたレコードをストリーミングするかどうかを決定するときは、次の点を考慮してください。 - SaaS プロバイダーでは、ストリーミング入力の受入に制約がある場合が多くあります。 - バッチストリーミングは、CSV、JSON、XML などのファイルに書き込む場合のバッチ処理に便利な場合が多くあります。 - レコードの配列は RAM に格納され、トランザクションの処理速度が低下する可能性があるため、バッチストリーミングはアプリケーションのパフォーマンスに影響します。パフォーマンスは低下しますが、その分、ストリーミングデータが確実に使用できるようになる可能性があります。 - ストリーミングのコミットは 1 つずつの読み取りで前方移動のみのイテレーターであるため、ストリーミングではレコードへのランダムアクセスはできません。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.4/for-each-scope-concept)​ などのコンポーネントを使用した場合はストリーミング時にランダムアクセス操作を実行できます。For Each により、レコードの個別の配列が提供され、その ​`records`​ 変数を使用してアクセスできます。 # バッチコンポーネントリファレンス Mule バッチコンポーネントでは、デフォルトのコンポーネント設定に対する調整を最小限に抑えてレコードのバッチ処理を管理します。コンポーネントは、処理およびパフォーマンスに関する特定の要件に合わせて高度に設定可能です。 Batch Job コンポーネントには 1 つ以上の Batch Step コンポーネントが含まれている必要があります。必要に応じて、各 Batch Step コンポーネントには 1 つの Batch Aggregator コンポーネントを含めることができます。次の図の Mule フローはバッチコンポーネントを示しています。 ![Studio 内の Mule フローのバッチ処理コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/batch-flow-generic-example.png) Batch Job コンポーネントでは Mule メッセージのペイロードをレコードに分割します。Batch Step コンポーネントおよび Batch Aggregator コンポーネント内で、これらのレコードはキーワード ​`payload`​ で使用でき、Mule 変数は ​`vars`​ キーワードを使用してアクセスすることもできます。ただし、Mule 属性はこれらのコンポーネント内からアクセスできません。どちらのコンポーネントも ​`attributes`​ で ​`null`​ を返します。 このリファレンスでは、読者が Batch Job インスタンスの​[バッチ処理フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases)​に精通していることを前提としています。 ## [](#ref_batch_job_component)Batch Job コンポーネント () このコンポーネントでは、処理用の入力を準備し、その処理の結果が記載されたレポートを出力します。準備は Batch Job インスタンスの ​[Load and Dispatch](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases#phase_load_dispatch)​ フェーズ中に行われ、レポートは ​[On Complete](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases#phase_on_complete)​ フェーズで使用できます。 Studio では、これらのプロパティをコンポーネントの ​[\[General (一般)\]](#ref_batch_job_general_fields)​ タブと ​[\[History (履歴)\]](#ref_batch_job_history_fields)​ タブで設定できます。 ### [](#ref_batch_job_general_fields)Batch Job のプロパティ Batch Job コンポーネントには、バッチ処理の実行方法を決定する設定可能な多数のプロパティが用意されています。また、入力ペイロードをフローの後続のコンポーネントで使用できるように対象変数に格納することもできます。Batch Job コンポーネントはメッセージペイロードをコンシュームするため、これは便利な可能性があります。 Anypoint Studio の ​**\[General (一般)\]**​ タブには次の項目があります。 ![Studio の Batch Job の項目](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/batch-job-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
項目名 XML 説明

Name (名前)

name

Batch Job コンポーネントの設定可能な名前。デフォルトの名前はアプリケーションの名前に ​Batch_Job​ を追加したものです。

Max Failed Records (最大失敗レコード数)

maxFailedRecords

Batch Job インスタンスの実行が停止する前にその Batch Job インスタンス内で失敗できるレコードの最大数。デフォルトは ​0​ です。無制限にする場合は、​-1​ を使用します。この設定は、Batch Job コンポーネント内の ​Batch Step コンポーネント​のどの受け入れポリシー (​acceptPolicy​) または式 (​acceptExpression​) 検索条件よりも優先されます。Batch Job インスタンスが ​maxFailedRecords​ 値を超えると、Batch Job コンポーネントでエラーが発生した Batch Job インスタンスの処理が停止され、インスタンスに状況 ​FAILED_PROCESS_RECORDS​ が割り当てられ、インスタンスで失敗したレコードの数が報告されます。Batch Job インスタンスがこのしきい値に達すると、コンソールでは次のようなメッセージが出力されます (読みやすいように編集済み)。

INFO  ... DefaultBatchEngine:
 instance '6d85c380-f332-11ec-bb5f-147ddaaf4f97' of job 'Batch_Job_in_Mule_Flow'
 has reached the max allowed number of failed records. Record will be added to
 failed list and the instance will be removed from execution pool.
...
INFO  ... DefaultBatchEngine:
 instance 6d85c380-f332-11ec-bb5f-147ddaaf4f97 of job Batch_Job_in_Mule_Flow
 has been stopped. Instance status is FAILED_PROCESS_RECORDS

Batch Job インスタンス内の並列処理により、複数のレコードで同時に失敗できるようになるため、エラー数が設定した最大値を超えることができます。

Scheduling Strategy (スケジュール戦略)

schedulingStrategy

Batch Job コンポーネントが繰り返しトリガーする場合、複数の Batch Job インスタンスを同時に実行するように準備できます。インスタンスは作成タイムスタンプに基づいて (デフォルト)、または使用可能なリソースの使用を最大化しようとするラウンドロビンアルゴリズムに従って順次実行できます。この設定は、処理順序が保証されないため、他のレコードに対する副作用や連動関係がないジョブのみに適しています。

  • ORDERED_SQUENTIAL​ (デフォルト): この設定では、Batch Job インスタンスは作成タイムスタンプで確立された順序で一度に 1 つずつ実行されます。先に作成されたインスタンスが後の日時に作成されたインスタンスの前に実行されます。

  • ROUND_ROBIN​: この設定では、すべての Batch Job インスタンスが使用可能なリソースを割り当てるラウンドロビンアルゴリズムに基づいて実行されます。実行の順序は事前に決定されません。バッチインスタンスはどの順序でも実行できます。このオプションが適しているのは、インスタンスの実行で別のインスタンスの実行に対する副作用が発生しないことが確かな場合のみです。ベストプラクティスは次のとおりです。

    • 同時に実行される Batch Job インスタンスで同じレコードが更新されるのを避けるために、この戦略をデータ同期ジョブに使用しないでください。データを同期するときにこの戦略を使用すると、事前に誤ったバージョンのデータで結果を返すことが可能になります。

    • Batch Job でデータベースから新しいレコードのみを取得する場合など、Batch Job コンポーネント内の別のレコードの処理に依存するレコードがないことが確かな場合に、この戦略を使用して Batch Job インスタンスを並列実行するようにしてください。

Job Instance ID (ジョブインスタンス ID)

jobInstanceId

バッチインスタンスの認識可能な一意の名前を提供する省略可能な式。名前を一意にするには、この項目内でたとえば ​#[jobInstanceId="#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]​ などの DataWeave 式を使用する必要があります。式で同じ値が 2 回以上返される場合、Mule では ​Batch Job 'my-batch-job-example' already has an instance with id 'my-repeated-id'​ のようなメッセージでエラーがスローされます。Batch Job コンポーネントではこの値を使用して Mule フローが Batch Job コンポーネントに達するたびに新しい識別子を作成します。ID を指定しないと、Mule によって各 Batch Job インスタンスの識別子となる UUID が自動的に作成されます。

Batch Block Size (バッチブロックサイズ)

blockSize

レコードブロックあたりの処理するレコードの件数。デフォルトはブロックあたり ​100​ 件のレコードです。処理できるレコードが設定したサイズより少ない場合、Mule によってレコードプロセッサーに送信されるブロックのサイズが小さくなります。このような状況は、たとえば、1010 件のレコードがあり、ブロックサイズが 100 の場合に発生する可能性があります。これは、剰余が 0 ではなく 10 であるためです。ブロックサイズの設定により、各ブロックのレコードのサイズと ​maxConcurrency​ 設定の影響を受けるパフォーマンスを調整できます。

Max Concurrency (最大同時実行)

maxConcurrency

コンポーネント内でレコードブロックを処理するときに許可する並列性の最大レベルを設定するプロパティ。デフォルトは CPU で使用可能なコア数の 2 倍です。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。​blockSize​ 設定と同様、この設定により、パフォーマンスを調整できます。

変換先

target

Batch Job コンポーネントの​後​に配置されたコンポーネントの Batch Job インスタンスで受け取られたペイロードを使用するには、​target​ の一意の値を指定して、ダウンストリームコンポーネントの ​payload​ を使用してそのペイロードにアクセスします。対象値がない場合、Batch Job コンポーネントへの入力ペイロードをダウンストリームコンポーネントで使用できません。対象変数についての詳細は、対象変数を使用したデータの強化を参照してください。デフォルト値はありません。
### [](#ref_batch_job_history_fields)Batch Job 履歴 () Batch Job 履歴設定により、Batch Job インスタンスの履歴データが一時的な Mule ディレクトリで保持される期間を調整することにより、​`No space left on device`​ エラーを解決できます。このエラーは、空きディスクスペース、または指定したサイズの CloudHub ワーカーに対して処理するレコードの頻度が高すぎるか数が多すぎて処理できない場合に発生する可能性があります。 デフォルトでは、Batch Job インスタンスの履歴は 7 日間保持されます。この期間が経過すると、監視プロセスによりその履歴が自動的に削除されます。 ![Studio の Batch Job 履歴の項目](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/batch-job-fields-history-studio.png) 次の表に、各項目と項目の XML 属性を示します。
名前 XML 説明

Max Age (最長有効期間)

maxAge

ジョブインスタンスが期限切れになる前の最長有効期間。例: expiration maxAge="10"​。デフォルト: maxAge=7​。

Time Unit (時間単位)

ageUnit

maxAge​ に適用する時間の単位。有効な値: DAYS​、​HOURS​、​MILLISECONDS​、​MINUTES​、​SECONDS​。デフォルト: ageUnit=DAYS​。
これらの項目は、​``​ 内に埋め込まれる ​``​ 要素に対する属性です。 ```xml ``` XML の例は、バッチ履歴項目の設定に焦点を絞るために編集されています。 ## [](#ref_batch_step_component)Batch Step コンポーネント () Batch Step コンポーネントは、Load and Dispatch フェーズや On Complete フェーズ中ではなく、Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases#phase_process)​中に実行されます。 Batch Job コンポーネント内には 1 つ以上の Batch Step コンポーネントが必要です。Batch Step コンポーネントの名前を変更するだけでなく、コンポーネントがコンポーネント内の処理に受け入れるレコードを決定する​_検索条件_​を設定できます。コンポーネントに追加したプロセッサーは、Batch Job コンポーネントが受け入れるレコードに対するアクションを実行します。 ![Studio の Batch Step の項目](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/batch-step-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
項目名 XML 説明

Name (名前)

name

Batch Step コンポーネントの設定可能な名前。Batch Job コンポーネント内の最初の Batch Step コンポーネントでは、デフォルトは ​Batch_Step​ です。後続のステップでは、​Batch_Step1​、​Batch_Step2​、といった順序に従い、一意の番号が名前に付加されます。

Accept Expression (受け入れ式)

acceptExpression

コンポーネントでレコードを処理するかどうかを決定する検索条件の省略可能な DataWeave 式。レコードの ​acceptExpression ​と​ ​acceptPolicy​ の​両方​の値が ​true​ に評価される場合、コンポーネントでは処理するためにレコードを受け入れます。それ以外の場合、コンポーネントではレコードをスキップし、レコードはダウンストリームの Batch Step コンポーネントで使用可能になります。例:

  • age​ 項目があるペイロードでは ​acceptExpression="#[payload.age > 21]"​

  • name​ 項目があるペイロードでは ​acceptExpression="#[not isBlank(payload.name)]"​。

Accept Policy (受け入れポリシー)

acceptPolicy

ポリシーがそのレコードで ​true​ に評価される場合のみ処理するためにレコードを受け入れます。受け入れの基準を、Batch Job コンポーネント内の​先行する​ (アップストリームの) Batch Step コンポーネントでレコードの処理に成功したか失敗したかにできます。コンポーネントは、正常に処理されたレコードのみを処理する、正常に処理できなかったレコードのみを処理する、または正常に処理されたかどうかに関係なくすべてのレコードを処理するように設定できます。デフォルトは ​NO_FAILURES​ です。​acceptPolicy​ はコンポーネントのどの ​acceptExpression​ よりも前に評価され、​Batch Job コンポーネント​の ​maxFailedRecords​ 設定は ​acceptPolicy​ 設定よりも優先される点に注意してください。

  • NO_FAILURES​: デフォルト設定。レコードが先行する Batch Step コンポーネント内で処理に失敗したことがない場合、またはアップストリームの Batch Step コンポーネントがない場合にレコードを処理するために受け入れます。

  • ONLY_FAILURES​: レコードが先行する Batch Step コンポーネント内で処理に失敗した場合にレコードを処理するために受け入れます。

  • ALL​: 先行する Batch Step コンポーネント内での処理に成功したか失敗したかに関係なくレコードを処理するために受け入れます。
## [](#ref_batch_aggregator_component)Batch Aggregator コンポーネント () Batch Aggregator コンポーネントはレコードの配列に対してアクションを実行する省略可能なコンポーネントです。集計は Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases#phase_process)​中に行われます。 Batch Aggregator コンポーネントにはデフォルトの設定はありません。このコンポーネントを使用する場合は、レコードをストリーミングするか (​`streaming`​)、キューから固定サイズ (​`size`​) の別の配列にレコードを取り込むか、どちらも行わないかを指定する必要があります。これらの設定は相互に排他的です。ストリーミングされたレコードへのランダムアクセスはできません。 Batch Aggregator コンポーネントではメッセージ ​`payload`​ として 1 つ以上のプロセッサーを受け入れます。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.5/for-each-scope-concept)​ スコープなど、アグリゲーター内のスコープを使用して各レコードに対して反復し、スコープ内の子プロセッサーが個別に各レコードに対するアクションを実行できるようにするのが一般的です。 Batch Aggregator コンポーネントにより、固定サイズ (​`size`​) として集計しているレコードの一部にアクセスする場合に必要な MIME タイプのレコード (​`preserveMimeTypes`​) を保持することもできます。​[「集約されたレコードの MIME タイプの保持」](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-filters-and-batch-aggregator#preserving-the-mime-types-of-the-aggregated-records)​を参照してください。このコンポーネント内のレコード処理についての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases#batch_aggregator_processing)​のバッチ集計に関する情報を参照してください。 [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#upsert)​ などの一部のコネクタには、バッチ集計プロセスを失敗させることなくレコードレベルのエラーを処理できる操作が用意されています。 Batch Aggregator を使用するときは、次の制限事項を考慮してください。 - Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java ​`Map`​ を使用してシリアル化の問題を回避します。 - Batch Aggregator コンポーネントでは、ジョブインスタンス全体の​[トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management)​がサポートされません。Batch Step コンポーネント内で、各レコードを個別のトランザクションで処理するトランザクションを定義できます。ただし、Batch Step コンポーネントによって開始されたトランザクションは、Batch Aggregator コンポーネントが処理を開始する前に終了します。トランザクションはコンポーネント間の境界を越えることができないため、コンポーネントはトランザクションを共有できます。 ![Studio の Batch Aggregator の項目](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/batch-aggregator-fields-studio.png) 次の表に、各項目と項目の XML 要素を示します。
項目名 XML 説明

Display Name (表示名)

doc:name

コンポーネントの設定可能な名前。例: doc:name="My Aggregator"​.デフォルトの名前は ​Batch Aggregator​ です。

Aggregator Size (Aggregator サイズ)

size

処理するレコードの各配列のサイズ。デフォルトのサイズはありません。コンポーネント内のプロセッサーは入力として配列を受け入れる必要があります。コンポーネントはレコードを残りがなくなるまでバッチステッピングキューから設定したサイズの配列に取り込み続けます。キューに含まれるレコードが設定したサイズより少ない場合、コンポーネントがこれらのレコードを処理するための取り込み先の配列が小さくなります。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

この設定を使用するときは、コンポーネントは Batch Step コンポーネントがインスタンスまたはバッチのすべてのレコードの処理を完了するのを待機しません。ステッピングキューで設定した数のレコードが使用可能になると、Batch Aggregator コンポーネントはこれらのレコードを配列に取り込んで処理します。

ストリーミング

streaming

streaming=true​ の場合、コンポーネントは Batch Job インスタンスのすべてのレコードに対するアクションを実行し、インスタンスのレコード数と同じサイズの配列で結果を返します。Batch Job コンポーネントを使用してバッチサイズを設定しても、処理するレコード数または配列で返すレコード数は制限されません。たとえば、Aggregator が ​{"id": 1}​、​{"id": 2}​、といった形式の ​10​ 個のレコードのみを処理する小さな Batch Job インスタンスの数値の ID を返すとします。この場合、Batch Job コンポーネントの ​blockSize​ が ​5​ のようにインスタンスのレコード数より小さい数に設定されていたとしても、インスタンスの出力配列には ​[1, 6, 2, 7, 3, 8, 4, 9, 5, 10]​ などの 10 個の ID が含まれます。

プロセッサーはストリーミングされたレコードの配列に順次アクセスできます。Aggregator では処理されたレコードが保持されないため、ストリーミングされたレコードへのランダムアクセスはできません。

デフォルトはありません。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

Preserve Mime Types (MIME タイプを保持)

preserveMimeTypes

デフォルトは ​false​ です。このコンポーネント内で処理されるレコードの MIME タイプを保持するには、この属性を ​true​ に設定します。 データの MIME タイプを判断できないプロセッサーは、​null​ や、​[[B@e596d5c, [B@1c4c3b32], …​]​ などの判読できないペイロードへの参照を出力として返します。​preserveMimeTypes=true​ の設定は、コンポーネントが固定数 (​size​) のレコードを処理するように設定されている場合に便利です。
集計されたレコードをストリーミングするかどうかを決定するときは、次の点を考慮してください。 - SaaS プロバイダーでは、ストリーミング入力の受入に制約がある場合が多くあります。 - バッチストリーミングは、CSV、JSON、XML などのファイルに書き込む場合のバッチ処理に便利な場合が多くあります。 - レコードの配列は RAM に格納され、トランザクションの処理速度が低下する可能性があるため、バッチストリーミングはアプリケーションのパフォーマンスに影響します。パフォーマンスは低下しますが、その分、ストリーミングデータが確実に使用できるようになる可能性があります。 - ストリーミングのコミットは 1 つずつの読み取りで前方移動のみのイテレーターであるため、ストリーミングではレコードへのランダムアクセスはできません。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.5/for-each-scope-concept)​ などのコンポーネントを使用した場合はストリーミング時にランダムアクセス操作を実行できます。For Each により、レコードの個別の配列が提供され、その ​`records`​ 変数を使用してアクセスできます。 # バッチコンポーネントリファレンス Mule バッチコンポーネントでは、デフォルトのコンポーネント設定に対する調整を最小限に抑えてレコードのバッチ処理を管理します。コンポーネントは、処理およびパフォーマンスに関する特定の要件に合わせて高度に設定可能です。 Batch Job コンポーネントには 1 つ以上の Batch Step コンポーネントが含まれている必要があります。必要に応じて、各 Batch Step コンポーネントには 1 つの Batch Aggregator コンポーネントを含めることができます。次の図の Mule フローはバッチコンポーネントを示しています。 ![Studio 内の Mule フローのバッチ処理コンポーネント](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/batch-flow-generic-example.png) Batch Job コンポーネントでは Mule メッセージのペイロードをレコードに分割します。Batch Step コンポーネントおよび Batch Aggregator コンポーネント内で、これらのレコードはキーワード ​`payload`​ で使用でき、Mule 変数は ​`vars`​ キーワードを使用してアクセスすることもできます。ただし、Mule 属性はこれらのコンポーネント内からアクセスできません。どちらのコンポーネントも ​`attributes`​ で ​`null`​ を返します。 このリファレンスでは、読者が Batch Job インスタンスの​[バッチ処理フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases)​に精通していることを前提としています。 ## [](#ref_batch_job_component)Batch Job コンポーネント () このコンポーネントでは、処理用の入力を準備し、その処理の結果が記載されたレポートを出力します。準備は Batch Job インスタンスの ​[Load and Dispatch](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases#phase_load_dispatch)​ フェーズ中に行われ、レポートは ​[On Complete](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases#phase_on_complete)​ フェーズで使用できます。 Studio では、これらのプロパティをコンポーネントの ​[\[General (一般)\]](#ref_batch_job_general_fields)​ タブと ​[\[History (履歴)\]](#ref_batch_job_history_fields)​ タブで設定できます。 ### [](#ref_batch_job_general_fields)Batch Job のプロパティ Batch Job コンポーネントには、バッチ処理の実行方法を決定する設定可能な多数のプロパティが用意されています。また、入力ペイロードをフローの後続のコンポーネントで使用できるように対象変数に格納することもできます。Batch Job コンポーネントはメッセージペイロードをコンシュームするため、これは便利な可能性があります。 Anypoint Studio の ​**\[General (一般)\]**​ タブには次の項目があります。 ![Studio の Batch Job の項目](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/batch-job-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
項目名 XML 説明

Name (名前)

name

Batch Job コンポーネントの設定可能な名前。デフォルトの名前はアプリケーションの名前に ​Batch_Job​ を追加したものです。

Max Failed Records (最大失敗レコード数)

maxFailedRecords

Batch Job インスタンスの実行が停止する前にその Batch Job インスタンス内で失敗できるレコードの最大数。デフォルトは ​0​ です。無制限にする場合は、​-1​ を使用します。この設定は、Batch Job コンポーネント内の ​Batch Step コンポーネント​のどの受け入れポリシー (​acceptPolicy​) または式 (​acceptExpression​) 検索条件よりも優先されます。Batch Job インスタンスが ​maxFailedRecords​ 値を超えると、Batch Job コンポーネントでエラーが発生した Batch Job インスタンスの処理が停止され、インスタンスに状況 ​FAILED_PROCESS_RECORDS​ が割り当てられ、インスタンスで失敗したレコードの数が報告されます。Batch Job インスタンスがこのしきい値に達すると、コンソールでは次のようなメッセージが出力されます (読みやすいように編集済み)。

INFO  ... DefaultBatchEngine:
 instance '6d85c380-f332-11ec-bb5f-147ddaaf4f97' of job 'Batch_Job_in_Mule_Flow'
 has reached the max allowed number of failed records. Record will be added to
 failed list and the instance will be removed from execution pool.
...
INFO  ... DefaultBatchEngine:
 instance 6d85c380-f332-11ec-bb5f-147ddaaf4f97 of job Batch_Job_in_Mule_Flow
 has been stopped. Instance status is FAILED_PROCESS_RECORDS

Batch Job インスタンス内の並列処理により、複数のレコードで同時に失敗できるようになるため、エラー数が設定した最大値を超えることができます。

Scheduling Strategy (スケジュール戦略)

schedulingStrategy

Batch Job コンポーネントが繰り返しトリガーする場合、複数の Batch Job インスタンスを同時に実行するように準備できます。インスタンスは作成タイムスタンプに基づいて (デフォルト)、または使用可能なリソースの使用を最大化しようとするラウンドロビンアルゴリズムに従って順次実行できます。この設定は、処理順序が保証されないため、他のレコードに対する副作用や連動関係がないジョブのみに適しています。

  • ORDERED_SQUENTIAL​ (デフォルト): この設定では、Batch Job インスタンスは作成タイムスタンプで確立された順序で一度に 1 つずつ実行されます。先に作成されたインスタンスが後の日時に作成されたインスタンスの前に実行されます。

  • ROUND_ROBIN​: この設定では、すべての Batch Job インスタンスが使用可能なリソースを割り当てるラウンドロビンアルゴリズムに基づいて実行されます。実行の順序は事前に決定されません。バッチインスタンスはどの順序でも実行できます。このオプションが適しているのは、インスタンスの実行で別のインスタンスの実行に対する副作用が発生しないことが確かな場合のみです。ベストプラクティスは次のとおりです。

    • 同時に実行される Batch Job インスタンスで同じレコードが更新されるのを避けるために、この戦略をデータ同期ジョブに使用しないでください。データを同期するときにこの戦略を使用すると、事前に誤ったバージョンのデータで結果を返すことが可能になります。

    • Batch Job でデータベースから新しいレコードのみを取得する場合など、Batch Job コンポーネント内の別のレコードの処理に依存するレコードがないことが確かな場合に、この戦略を使用して Batch Job インスタンスを並列実行するようにしてください。

Job Instance ID (ジョブインスタンス ID)

jobInstanceId

バッチインスタンスの認識可能な一意の名前を提供する省略可能な式。名前を一意にするには、この項目内でたとえば ​#[jobInstanceId="#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]​ などの DataWeave 式を使用する必要があります。式で同じ値が 2 回以上返される場合、Mule では ​Batch Job 'my-batch-job-example' already has an instance with id 'my-repeated-id'​ のようなメッセージでエラーがスローされます。Batch Job コンポーネントではこの値を使用して Mule フローが Batch Job コンポーネントに達するたびに新しい識別子を作成します。ID を指定しないと、Mule によって各 Batch Job インスタンスの識別子となる UUID が自動的に作成されます。

Batch Block Size (バッチブロックサイズ)

blockSize

レコードブロックあたりの処理するレコードの件数。デフォルトはブロックあたり ​100​ 件のレコードです。処理できるレコードが設定したサイズより少ない場合、Mule によってレコードプロセッサーに送信されるブロックのサイズが小さくなります。このような状況は、たとえば、1010 件のレコードがあり、ブロックサイズが 100 の場合に発生する可能性があります。これは、剰余が 0 ではなく 10 であるためです。ブロックサイズの設定により、各ブロックのレコードのサイズと ​maxConcurrency​ 設定の影響を受けるパフォーマンスを調整できます。

Max Concurrency (最大同時実行)

maxConcurrency

コンポーネント内でレコードブロックを処理するときに許可する並列性の最大レベルを設定するプロパティ。デフォルトは CPU で使用可能なコア数の 2 倍です。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。​blockSize​ 設定と同様、この設定により、パフォーマンスを調整できます。

変換先

target

Batch Job コンポーネントの​後​に配置されたコンポーネントの Batch Job インスタンスで受け取られたペイロードを使用するには、​target​ の一意の値を指定して、ダウンストリームコンポーネントの ​payload​ を使用してそのペイロードにアクセスします。対象値がない場合、Batch Job コンポーネントへの入力ペイロードをダウンストリームコンポーネントで使用できません。対象変数についての詳細は、対象変数を使用したデータの強化を参照してください。デフォルト値はありません。
### [](#ref_batch_job_history_fields)Batch Job 履歴 () Batch Job 履歴設定により、Batch Job インスタンスの履歴データが一時的な Mule ディレクトリで保持される期間を調整することにより、​`No space left on device`​ エラーを解決できます。このエラーは、空きディスクスペース、または指定したサイズの CloudHub ワーカーに対して処理するレコードの頻度が高すぎるか数が多すぎて処理できない場合に発生する可能性があります。 デフォルトでは、Batch Job インスタンスの履歴は 7 日間保持されます。この期間が経過すると、監視プロセスによりその履歴が自動的に削除されます。 ![Studio の Batch Job 履歴の項目](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/batch-job-fields-history-studio.png) 次の表に、各項目と項目の XML 属性を示します。
名前 XML 説明

Max Age (最長有効期間)

maxAge

ジョブインスタンスが期限切れになる前の最長有効期間。例: expiration maxAge="10"​。デフォルト: maxAge=7​。

Time Unit (時間単位)

ageUnit

maxAge​ に適用する時間の単位。有効な値: DAYS​、​HOURS​、​MILLISECONDS​、​MINUTES​、​SECONDS​。デフォルト: ageUnit=DAYS​。
これらの項目は、​``​ 内に埋め込まれる ​``​ 要素に対する属性です。 ```xml ``` XML の例は、バッチ履歴項目の設定に焦点を絞るために編集されています。 ## [](#ref_batch_step_component)Batch Step コンポーネント () Batch Step コンポーネントは、Load and Dispatch フェーズや On Complete フェーズ中ではなく、Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases#phase_process)​中に実行されます。 Batch Job コンポーネント内には 1 つ以上の Batch Step コンポーネントが必要です。Batch Step コンポーネントの名前を変更するだけでなく、コンポーネントがコンポーネント内の処理に受け入れるレコードを決定する​_検索条件_​を設定できます。コンポーネントに追加したプロセッサーは、Batch Job コンポーネントが受け入れるレコードに対するアクションを実行します。 ![Studio の Batch Step の項目](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/batch-step-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
項目名 XML 説明

Name (名前)

name

Batch Step コンポーネントの設定可能な名前。Batch Job コンポーネント内の最初の Batch Step コンポーネントでは、デフォルトは ​Batch_Step​ です。後続のステップでは、​Batch_Step1​、​Batch_Step2​、といった順序に従い、一意の番号が名前に付加されます。

Accept Expression (受け入れ式)

acceptExpression

コンポーネントでレコードを処理するかどうかを決定する検索条件の省略可能な DataWeave 式。レコードの ​acceptExpression ​と​ ​acceptPolicy​ の​両方​の値が ​true​ に評価される場合、コンポーネントでは処理するためにレコードを受け入れます。それ以外の場合、コンポーネントではレコードをスキップし、レコードはダウンストリームの Batch Step コンポーネントで使用可能になります。例:

  • age​ 項目があるペイロードでは ​acceptExpression="#[payload.age > 21]"​

  • name​ 項目があるペイロードでは ​acceptExpression="#[not isBlank(payload.name)]"​。

Accept Policy (受け入れポリシー)

acceptPolicy

ポリシーがそのレコードで ​true​ に評価される場合のみ処理するためにレコードを受け入れます。受け入れの基準を、Batch Job コンポーネント内の​先行する​ (アップストリームの) Batch Step コンポーネントでレコードの処理に成功したか失敗したかにできます。コンポーネントは、正常に処理されたレコードのみを処理する、正常に処理できなかったレコードのみを処理する、または正常に処理されたかどうかに関係なくすべてのレコードを処理するように設定できます。デフォルトは ​NO_FAILURES​ です。​acceptPolicy​ はコンポーネントのどの ​acceptExpression​ よりも前に評価され、​Batch Job コンポーネント​の ​maxFailedRecords​ 設定は ​acceptPolicy​ 設定よりも優先される点に注意してください。

  • NO_FAILURES​: デフォルト設定。レコードが先行する Batch Step コンポーネント内で処理に失敗したことがない場合、またはアップストリームの Batch Step コンポーネントがない場合にレコードを処理するために受け入れます。

  • ONLY_FAILURES​: レコードが先行する Batch Step コンポーネント内で処理に失敗した場合にレコードを処理するために受け入れます。

  • ALL​: 先行する Batch Step コンポーネント内での処理に成功したか失敗したかに関係なくレコードを処理するために受け入れます。
## [](#ref_batch_aggregator_component)Batch Aggregator コンポーネント () Batch Aggregator コンポーネントはレコードの配列に対してアクションを実行する省略可能なコンポーネントです。集計は Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases#phase_process)​中に行われます。 Batch Aggregator コンポーネントにはデフォルトの設定はありません。このコンポーネントを使用する場合は、レコードをストリーミングするか (​`streaming`​)、キューから固定サイズ (​`size`​) の別の配列にレコードを取り込むか、どちらも行わないかを指定する必要があります。これらの設定は相互に排他的です。ストリーミングされたレコードへのランダムアクセスはできません。 Batch Aggregator コンポーネントではメッセージ ​`payload`​ として 1 つ以上のプロセッサーを受け入れます。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.6/for-each-scope-concept)​ スコープなど、アグリゲーター内のスコープを使用して各レコードに対して反復し、スコープ内の子プロセッサーが個別に各レコードに対するアクションを実行できるようにするのが一般的です。 Batch Aggregator コンポーネントにより、固定サイズ (​`size`​) として集計しているレコードの一部にアクセスする場合に必要な MIME タイプのレコード (​`preserveMimeTypes`​) を保持することもできます。​[「集約されたレコードの MIME タイプの保持」](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-filters-and-batch-aggregator#preserving-the-mime-types-of-the-aggregated-records)​を参照してください。このコンポーネント内のレコード処理についての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases#batch_aggregator_processing)​のバッチ集計に関する情報を参照してください。 [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#upsert)​ などの一部のコネクタには、バッチ集計プロセスを失敗させることなくレコードレベルのエラーを処理できる操作が用意されています。 Batch Aggregator を使用するときは、次の制限事項を考慮してください。 - Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java ​`Map`​ を使用してシリアル化の問題を回避します。 - Batch Aggregator コンポーネントでは、ジョブインスタンス全体の​[トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management)​がサポートされません。Batch Step コンポーネント内で、各レコードを個別のトランザクションで処理するトランザクションを定義できます。ただし、Batch Step コンポーネントによって開始されたトランザクションは、Batch Aggregator コンポーネントが処理を開始する前に終了します。トランザクションはコンポーネント間の境界を越えることができないため、コンポーネントはトランザクションを共有できます。 ![Studio の Batch Aggregator の項目](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/batch-aggregator-fields-studio.png) 次の表に、各項目と項目の XML 要素を示します。
項目名 XML 説明

Display Name (表示名)

doc:name

コンポーネントの設定可能な名前。例: doc:name="My Aggregator"​。デフォルトの名前は ​Batch Aggregator​ です。

Aggregator Size (Aggregator サイズ)

size

処理するレコードの各配列のサイズ。デフォルトのサイズはありません。コンポーネント内のプロセッサーは入力として配列を受け入れる必要があります。コンポーネントはレコードを残りがなくなるまでバッチステッピングキューから設定したサイズの配列に取り込み続けます。キューに含まれるレコードが設定したサイズより少ない場合、コンポーネントがこれらのレコードを処理するための取り込み先の配列が小さくなります。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

この設定を使用するときは、コンポーネントは Batch Step コンポーネントがインスタンスまたはバッチのすべてのレコードの処理を完了するのを待機しません。ステッピングキューで設定した数のレコードが使用可能になると、Batch Aggregator コンポーネントはこれらのレコードを配列に取り込んで処理します。

ストリーミング

streaming

streaming=true​ の場合、コンポーネントは Batch Job インスタンスのすべてのレコードに対するアクションを実行し、インスタンスのレコード数と同じサイズの配列で結果を返します。Batch Job コンポーネントを使用してバッチサイズを設定しても、処理するレコード数または配列で返すレコード数は制限されません。たとえば、Aggregator が ​{"id": 1}​、​{"id": 2}​、といった形式の ​10​ 個のレコードのみを処理する小さな Batch Job インスタンスの数値の ID を返すとします。この場合、Batch Job コンポーネントの ​blockSize​ が ​5​ のようにインスタンスのレコード数より小さい数に設定されていたとしても、インスタンスの出力配列には ​[1, 6, 2, 7, 3, 8, 4, 9, 5, 10]​ などの 10 個の ID が含まれます。

プロセッサーはストリーミングされたレコードの配列に順次アクセスできます。Aggregator では処理されたレコードが保持されないため、ストリーミングされたレコードへのランダムアクセスはできません。

デフォルトはありません。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

Preserve Mime Types (MIME タイプを保持)

preserveMimeTypes

デフォルトは ​false​ です。このコンポーネント内で処理されるレコードの MIME タイプを保持するには、この属性を ​true​ に設定します。 データの MIME タイプを判断できないプロセッサーは、​null​ や、​[[B@e596d5c, [B@1c4c3b32], …​]​ などの判読できないペイロードへの参照を出力として返します。​preserveMimeTypes=true​ の設定は、コンポーネントが固定数 (​size​) のレコードを処理するように設定されている場合に便利です。
集計されたレコードをストリーミングするかどうかを決定するときは、次の点を考慮してください。 - SaaS プロバイダーでは、ストリーミング入力の受入に制約がある場合が多くあります。 - バッチストリーミングは、CSV、JSON、XML などのファイルに書き込む場合のバッチ処理に便利な場合が多くあります。 - レコードの配列は RAM に格納され、トランザクションの処理速度が低下する可能性があるため、バッチストリーミングはアプリケーションのパフォーマンスに影響します。パフォーマンスは低下しますが、その分、ストリーミングデータが確実に使用できるようになる可能性があります。 - ストリーミングのコミットは 1 つずつの読み取りで前方移動のみのイテレーターであるため、ストリーミングではレコードへのランダムアクセスはできません。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.6/for-each-scope-concept)​ などのコンポーネントを使用した場合はストリーミング時にランダムアクセス操作を実行できます。For Each により、レコードの個別の配列が提供され、その ​`records`​ 変数を使用してアクセスできます。 # バッチコンポーネントリファレンス Mule バッチコンポーネントでは、デフォルトのコンポーネント設定に対する調整を最小限に抑えてレコードのバッチ処理を管理します。コンポーネントは、処理およびパフォーマンスに関する特定の要件に合わせて高度に設定可能です。 Batch Job コンポーネントには 1 つ以上の Batch Step コンポーネントが含まれている必要があります。必要に応じて、各 Batch Step コンポーネントには 1 つの Batch Aggregator コンポーネントを含めることができます。次の図の Mule フローはバッチコンポーネントを示しています。 ![Anypoint Studio のバッチ処理コンポーネントが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/batch-flow-generic-example.png) Batch Job コンポーネントでは Mule メッセージのペイロードをレコードに分割します。Batch Step コンポーネントおよび Batch Aggregator コンポーネント内で、これらのレコードはキーワード ​`payload`​ で使用でき、Mule 変数は ​`vars`​ キーワードを使用してアクセスすることもできます。ただし、Mule 属性はこれらのコンポーネント内からアクセスできません。どちらのコンポーネントも ​`attributes`​ で ​`null`​ を返します。 このリファレンスでは、読者が Batch Job インスタンスの​[バッチ処理フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases)​に精通していることを前提としています。 ## [](#ref_batch_job_component)Batch Job コンポーネント () このコンポーネントでは、処理用の入力を準備し、その処理の結果が記載されたレポートを出力します。準備は Batch Job インスタンスの ​[Load and Dispatch](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases#phase_load_dispatch)​ フェーズ中に行われ、レポートは ​[On Complete](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases#phase_on_complete)​ フェーズで使用できます。 Studio では、これらのプロパティをコンポーネントの ​[\[General (一般)\]](#ref_batch_job_general_fields)​ タブと ​[\[History (履歴)\]](#ref_batch_job_history_fields)​ タブで設定できます。 ### [](#ref_batch_job_general_fields)Batch Job のプロパティ Batch Job コンポーネントには、バッチ処理の実行方法を決定する設定可能な多数のプロパティが用意されています。また、入力ペイロードをフローの後続のコンポーネントで使用できるように対象変数に格納することもできます。Batch Job コンポーネントはメッセージペイロードをコンシュームするため、これは便利な可能性があります。 Anypoint Studio の ​**\[General (一般)\]**​ タブには次の項目があります。 ![Anypoint Studio の Batch Job の項目](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/batch-job-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
項目名 XML 説明

名前

name

Batch Job コンポーネントの設定可能な名前。デフォルトの名前はアプリケーションの名前に ​Batch_Job​ を追加したものです。

Max Failed Records (最大失敗レコード数)

maxFailedRecords

Batch Job インスタンスの実行が停止する前にその Batch Job インスタンス内で失敗できるレコードの最大数。デフォルトは ​0​ です。無制限にする場合は、​-1​ を使用します。この設定は、Batch Job コンポーネント内の ​Batch Step コンポーネント​のどの受け入れポリシー (​acceptPolicy​) または式 (​acceptExpression​) 検索条件よりも優先されます。Batch Job インスタンスが ​maxFailedRecords​ 値を超えると、Batch Job コンポーネントでエラーが発生した Batch Job インスタンスの処理が停止され、インスタンスに状況 ​FAILED_PROCESS_RECORDS​ が割り当てられ、インスタンスで失敗したレコードの数が報告されます。Batch Job インスタンスがこのしきい値に達すると、コンソールでは次のようなメッセージが出力されます (読みやすいように編集済み)。

INFO  ... DefaultBatchEngine:
 instance '6d85c380-f332-11ec-bb5f-147ddaaf4f97' of job 'Batch_Job_in_Mule_Flow'
 has reached the max allowed number of failed records. Record will be added to
 failed list and the instance will be removed from execution pool.
...
INFO  ... DefaultBatchEngine:
 instance 6d85c380-f332-11ec-bb5f-147ddaaf4f97 of job Batch_Job_in_Mule_Flow
 has been stopped. Instance status is FAILED_PROCESS_RECORDS

Batch Job インスタンス内の並列処理により、複数のレコードで同時に失敗できるようになるため、エラー数が設定した最大値を超えることができます。

Scheduling Strategy (スケジュール戦略)

schedulingStrategy

Batch Job コンポーネントが繰り返しトリガーする場合、複数の Batch Job インスタンスを同時に実行するように準備できます。インスタンスは作成タイムスタンプに基づいて (デフォルト)、または使用可能なリソースの使用を最大化しようとするラウンドロビンアルゴリズムに従って順次実行できます。この設定は、処理順序が保証されないため、他のレコードに対する副作用や連動関係がないジョブのみに適しています。

  • ORDERED_SQUENTIAL​ (デフォルト): この設定では、Batch Job インスタンスは作成タイムスタンプで確立された順序で一度に 1 つずつ実行されます。先に作成されたインスタンスが後の日時に作成されたインスタンスの前に実行されます。

  • ROUND_ROBIN​: この設定では、すべての Batch Job インスタンスが使用可能なリソースを割り当てるラウンドロビンアルゴリズムに基づいて実行されます。実行の順序は事前に決定されません。バッチインスタンスはどの順序でも実行できます。このオプションが適しているのは、インスタンスの実行で別のインスタンスの実行に対する副作用が発生しないことが確かな場合のみです。ベストプラクティスは次のとおりです。

    • 同時に実行される Batch Job インスタンスで同じレコードが更新されるのを避けるために、この戦略をデータ同期ジョブに使用しないでください。データを同期するときにこの戦略を使用すると、事前に誤ったバージョンのデータで結果を返すことが可能になります。

    • Batch Job でデータベースから新しいレコードのみを取得する場合など、Batch Job コンポーネント内の別のレコードの処理に依存するレコードがないことが確かな場合に、この戦略を使用して Batch Job インスタンスを並列実行するようにしてください。

Job Instance ID (ジョブインスタンス ID)

jobInstanceId

バッチインスタンスの認識可能な一意の名前を提供する省略可能な式。名前を一意にするには、この項目内でたとえば ​#[jobInstanceId="#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]​ などの DataWeave 式を使用する必要があります。式で同じ値が 2 回以上返される場合、Mule では ​Batch Job 'my-batch-job-example' already has an instance with id 'my-repeated-id'​ のようなメッセージでエラーがスローされます。Batch Job コンポーネントではこの値を使用して Mule フローが Batch Job コンポーネントに達するたびに新しい識別子を作成します。ID を指定しないと、Mule によって各 Batch Job インスタンスの識別子となる UUID が自動的に作成されます。

Batch Block Size (バッチブロックサイズ)

blockSize

レコードブロックあたりの処理するレコードの件数。デフォルトはブロックあたり ​100​ 件のレコードです。処理できるレコードが設定したサイズより少ない場合、Mule によってレコードプロセッサーに送信されるブロックのサイズが小さくなります。このような状況は、たとえば、1010 件のレコードがあり、ブロックサイズが 100 の場合に発生する可能性があります。これは、剰余が 0 ではなく 10 であるためです。ブロックサイズの設定により、各ブロックのレコードのサイズと ​maxConcurrency​ 設定の影響を受けるパフォーマンスを調整できます。

Max Concurrency (最大同時実行)

maxConcurrency

コンポーネント内でレコードブロックを処理するときに許可する並列性の最大レベルを設定するプロパティ。デフォルトは CPU で使用可能なコア数の 2 倍です。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。​blockSize​ 設定と同様、この設定により、パフォーマンスを調整できます。

変換先

target

Batch Job コンポーネントの​後​に配置されたコンポーネントの Batch Job インスタンスで受け取られたペイロードを使用するには、​target​ の一意の値を指定して、ダウンストリームコンポーネントの ​payload​ を使用してそのペイロードにアクセスします。対象値がない場合、Batch Job コンポーネントへの入力ペイロードをダウンストリームコンポーネントで使用できません。対象変数についての詳細は、対象変数を使用したデータの強化を参照してください。デフォルト値はありません。
### [](#ref_batch_job_history_fields)Batch Job 履歴 () Batch Job 履歴設定により、Batch Job インスタンスの履歴データが一時的な Mule ディレクトリで保持される期間を調整することにより、​`No space left on device`​ エラーを解決できます。このエラーは、空きディスクスペース、または指定したサイズの CloudHub ワーカーに対して処理するレコードの頻度が高すぎるか数が多すぎて処理できない場合に発生する可能性があります。 デフォルトでは、Batch Job インスタンスの履歴は 7 日間保持されます。この期間が経過すると、監視プロセスによりその履歴が自動的に削除されます。 ![Anypoint Studio の Batch Job の \[History (履歴)\] 項目](_images/batch-job-fields-history-studio.png) 次の表に、各項目と項目の XML 属性を示します。
名前 XML 説明

Max Age (最長有効期間)

maxAge

ジョブインスタンスが期限切れになる前の最長有効期間。例: expiration maxAge="10"​。デフォルト: maxAge=7​。

Time Unit (時間単位)

ageUnit

maxAge​ に適用する時間の単位。有効な値: DAYS​、​HOURS​、​MILLISECONDS​、​MINUTES​、​SECONDS​。デフォルト: ageUnit=DAYS​。
これらの項目は、​``​ 内に埋め込まれる ​``​ 要素に対する属性です。 ```xml ``` XML の例は、バッチ履歴項目の設定に焦点を絞るために編集されています。 ## [](#ref_batch_step_component)Batch Step コンポーネント () Batch Step コンポーネントは、Load and Dispatch フェーズや On Complete フェーズ中ではなく、Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases#phase_process)​中に実行されます。 Batch Job コンポーネント内には 1 つ以上の Batch Step コンポーネントが必要です。Batch Step コンポーネントの名前を変更するだけでなく、コンポーネントがコンポーネント内の処理に受け入れるレコードを決定する​_検索条件_​を設定できます。コンポーネントに追加したプロセッサーは、Batch Job コンポーネントが受け入れるレコードに対するアクションを実行します。 ![Anypoint Studio の Batch Job の \[General (一般)\] 項目](_images/batch-step-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
項目名 XML 説明

名前

name

Batch Step コンポーネントの設定可能な名前。Batch Job コンポーネント内の最初の Batch Step コンポーネントでは、デフォルトは ​Batch_Step​ です。後続のステップでは、​Batch_Step1​、​Batch_Step2​、といった順序に従い、一意の番号が名前に付加されます。

Accept Expression (受け入れ式)

acceptExpression

コンポーネントでレコードを処理するかどうかを決定する検索条件の省略可能な DataWeave 式。レコードの ​acceptExpression ​と​ ​acceptPolicy​ の​両方​の値が ​true​ に評価される場合、コンポーネントでは処理するためにレコードを受け入れます。それ以外の場合、コンポーネントではレコードをスキップし、レコードはダウンストリームの Batch Step コンポーネントで使用可能になります。例:

  • age​ 項目があるペイロードでは ​acceptExpression="#[payload.age > 21]"​

  • name​ 項目があるペイロードでは ​acceptExpression="#[not isBlank(payload.name)]"​。

Accept Policy (受け入れポリシー)

acceptPolicy

ポリシーがそのレコードで ​true​ に評価される場合のみ処理するためにレコードを受け入れます。受け入れの基準を、Batch Job コンポーネント内の​先行する​ (アップストリームの) Batch Step コンポーネントでレコードの処理に成功したか失敗したかにできます。コンポーネントは、正常に処理されたレコードのみを処理する、正常に処理できなかったレコードのみを処理する、または正常に処理されたかどうかに関係なくすべてのレコードを処理するように設定できます。デフォルトは ​NO_FAILURES​ です。​acceptPolicy​ はコンポーネントのどの ​acceptExpression​ よりも前に評価され、​Batch Job コンポーネント​の ​maxFailedRecords​ 設定は ​acceptPolicy​ 設定よりも優先される点に注意してください。

  • NO_FAILURES​: デフォルト設定。レコードが先行する Batch Step コンポーネント内で処理に失敗したことがない場合、またはアップストリームの Batch Step コンポーネントがない場合にレコードを処理するために受け入れます。

  • ONLY_FAILURES​: レコードが先行する Batch Step コンポーネント内で処理に失敗した場合にレコードを処理するために受け入れます。

  • ALL​: 先行する Batch Step コンポーネント内での処理に成功したか失敗したかに関係なくレコードを処理するために受け入れます。
## [](#ref_batch_aggregator_component)Batch Aggregator コンポーネント () Batch Aggregator コンポーネントはレコードの配列に対してアクションを実行する省略可能なコンポーネントです。集計は Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases#phase_process)​中に行われます。 Batch Aggregator コンポーネントにはデフォルトの設定はありません。このコンポーネントを使用する場合は、レコードをストリーミングするか (​`streaming`​)、キューから固定サイズ (​`size`​) の別の配列にレコードを取り込むか、どちらも行わないかを指定する必要があります。これらの設定は相互に排他的です。ストリーミングされたレコードへのランダムアクセスはできません。 Batch Aggregator コンポーネントではメッセージ ​`payload`​ として 1 つ以上のプロセッサーを受け入れます。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.7/for-each-scope-concept)​ スコープなど、アグリゲーター内のスコープを使用して各レコードに対して反復し、スコープ内の子プロセッサーが個別に各レコードに対するアクションを実行できるようにするのが一般的です。 Batch Aggregator コンポーネントにより、固定サイズ (​`size`​) として集計しているレコードの一部にアクセスする場合に必要な MIME タイプのレコード (​`preserveMimeTypes`​) を保持することもできます。​[「集約されたレコードの MIME タイプの保持」](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-filters-and-batch-aggregator#preserving-the-mime-types-of-the-aggregated-records)​を参照してください。このコンポーネント内のレコード処理についての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases#batch_aggregator_processing)​のバッチ集計に関する情報を参照してください。 [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#upsert)​ などの一部のコネクタには、バッチ集計プロセスを失敗させることなくレコードレベルのエラーを処理できる操作が用意されています。 Batch Aggregator を使用するときは、次の制限事項を考慮してください。 - Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java ​`Map`​ を使用してシリアル化の問題を回避します。 - Batch Aggregator コンポーネントでは、ジョブインスタンス全体の​[トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management)​がサポートされません。Batch Step コンポーネント内で、各レコードを個別のトランザクションで処理するトランザクションを定義できます。ただし、Batch Step コンポーネントによって開始されたトランザクションは、Batch Aggregator コンポーネントが処理を開始する前に終了します。トランザクションはコンポーネント間の境界を越えることができないため、コンポーネントはトランザクションを共有できます。 ![Anypoint Studio の Batch Aggregator コンポーネントの項目](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/batch-aggregator-fields-studio.png) 次の表に、各項目と項目の XML 要素を示します。
項目名 XML 説明

Display Name (表示名)

doc:name

コンポーネントの設定可能な名前。例: doc:name="My Aggregator"​。デフォルトの名前は ​Batch Aggregator​ です。

Aggregator Size (Aggregator サイズ)

size

処理するレコードの各配列のサイズ。デフォルトのサイズはありません。コンポーネント内のプロセッサーは入力として配列を受け入れる必要があります。コンポーネントはレコードを残りがなくなるまでバッチステッピングキューから設定したサイズの配列に取り込み続けます。キューに含まれるレコードが設定したサイズより少ない場合、コンポーネントがこれらのレコードを処理するための取り込み先の配列が小さくなります。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

この設定を使用するときは、コンポーネントは Batch Step コンポーネントがインスタンスまたはバッチのすべてのレコードの処理を完了するのを待機しません。ステッピングキューで設定した数のレコードが使用可能になると、Batch Aggregator コンポーネントはこれらのレコードを配列に取り込んで処理します。

ストリーミング

streaming

streaming=true​ の場合、コンポーネントは Batch Job インスタンスのすべてのレコードに対するアクションを実行し、インスタンスのレコード数と同じサイズの配列で結果を返します。Batch Job コンポーネントを使用してバッチサイズを設定しても、処理するレコード数または配列で返すレコード数は制限されません。たとえば、Aggregator が ​{"id": 1}​、​{"id": 2}​、といった形式の ​10​ 個のレコードのみを処理する小さな Batch Job インスタンスの数値の ID を返すとします。この場合、Batch Job コンポーネントの ​blockSize​ が ​5​ のようにインスタンスのレコード数より小さい数に設定されていたとしても、インスタンスの出力配列には ​[1, 6, 2, 7, 3, 8, 4, 9, 5, 10]​ などの 10 個の ID が含まれます。

プロセッサーはストリーミングされたレコードの配列に順次アクセスできます。Aggregator では処理されたレコードが保持されないため、ストリーミングされたレコードへのランダムアクセスはできません。

デフォルトはありません。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

Preserve Mime Types (MIME タイプを保持)

preserveMimeTypes

デフォルトは ​false​ です。このコンポーネント内で処理されるレコードの MIME タイプを保持するには、この属性を ​true​ に設定します。 データの MIME タイプを判断できないプロセッサーは、​null​ や、​[[B@e596d5c, [B@1c4c3b32], …​]​ などの判読できないペイロードへの参照を出力として返します。​preserveMimeTypes=true​ の設定は、コンポーネントが固定数 (​size​) のレコードを処理するように設定されている場合に便利です。
集計されたレコードをストリーミングするかどうかを決定するときは、次の点を考慮してください。 - SaaS プロバイダーでは、ストリーミング入力の受入に制約がある場合が多くあります。 - バッチストリーミングは、CSV、JSON、XML などのファイルに書き込む場合のバッチ処理に便利な場合が多くあります。 - レコードの配列は RAM に格納され、トランザクションの処理速度が低下する可能性があるため、バッチストリーミングはアプリケーションのパフォーマンスに影響します。パフォーマンスは低下しますが、その分、ストリーミングデータが確実に使用できるようになる可能性があります。 - ストリーミングのコミットは 1 つずつの読み取りで前方移動のみのイテレーターであるため、ストリーミングではレコードへのランダムアクセスはできません。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.7/for-each-scope-concept)​ などのコンポーネントを使用した場合はストリーミング時にランダムアクセス操作を実行できます。For Each により、レコードの個別の配列が提供され、その ​`records`​ 変数を使用してアクセスできます。 # バッチコンポーネントリファレンス Mule バッチコンポーネントでは、デフォルトのコンポーネント設定に対する調整を最小限に抑えてレコードのバッチ処理を管理します。コンポーネントは、処理およびパフォーマンスに関する特定の要件に合わせて高度に設定可能です。 Batch Job コンポーネントには 1 つ以上の Batch Step コンポーネントが含まれている必要があります。必要に応じて、各 Batch Step コンポーネントには 1 つの Batch Aggregator コンポーネントを含めることができます。次の図の Mule フローはバッチコンポーネントを示しています。 ![Anypoint Studio のバッチ処理コンポーネントが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/batch-flow-generic-example.png) Batch Job コンポーネントでは Mule メッセージのペイロードをレコードに分割します。Batch Step コンポーネントおよび Batch Aggregator コンポーネント内で、これらのレコードはキーワード ​`payload`​ で使用でき、Mule 変数は ​`vars`​ キーワードを使用してアクセスすることもできます。ただし、Mule 属性はこれらのコンポーネント内からアクセスできません。どちらのコンポーネントも ​`attributes`​ で ​`null`​ を返します。 このリファレンスでは、読者が Batch Job インスタンスの​[バッチ処理フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases)​に精通していることを前提としています。 ## [](#ref_batch_job_component)Batch Job コンポーネント () このコンポーネントでは、処理用の入力を準備し、その処理の結果が記載されたレポートを出力します。準備は Batch Job インスタンスの ​[Load and Dispatch](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases#phase_load_dispatch)​ フェーズ中に行われ、レポートは ​[On Complete](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases#phase_on_complete)​ フェーズで使用できます。 Studio では、これらのプロパティをコンポーネントの ​[\[General (一般)\]](#ref_batch_job_general_fields)​ タブと ​[\[History (履歴)\]](#ref_batch_job_history_fields)​ タブで設定できます。 ### [](#ref_batch_job_general_fields)Batch Job のプロパティ Batch Job コンポーネントには、バッチ処理の実行方法を決定する設定可能な多数のプロパティが用意されています。また、入力ペイロードをフローの後続のコンポーネントで使用できるように対象変数に格納することもできます。Batch Job コンポーネントはメッセージペイロードをコンシュームするため、これは便利な可能性があります。 Anypoint Studio の ​**\[General (一般)\]**​ タブには次の項目があります。 ![Anypoint Studio の Batch Job の項目](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/batch-job-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
項目名 XML 説明

名前

name

Batch Job コンポーネントの設定可能な名前。デフォルトの名前はアプリケーションの名前に ​Batch_Job​ を追加したものです。

Max Failed Records (最大失敗レコード数)

maxFailedRecords

Batch Job インスタンスの実行が停止する前にその Batch Job インスタンス内で失敗できるレコードの最大数。デフォルトは ​0​ です。無制限にする場合は、​-1​ を使用します。この設定は、Batch Job コンポーネント内の ​Batch Step コンポーネント​のどの受け入れポリシー (​acceptPolicy​) または式 (​acceptExpression​) 検索条件よりも優先されます。Batch Job インスタンスが ​maxFailedRecords​ 値を超えると、Batch Job コンポーネントでエラーが発生した Batch Job インスタンスの処理が停止され、インスタンスに状況 ​FAILED_PROCESS_RECORDS​ が割り当てられ、インスタンスで失敗したレコードの数が報告されます。Batch Job インスタンスがこのしきい値に達すると、コンソールでは次のようなメッセージが出力されます (読みやすいように編集済み)。

INFO  ... DefaultBatchEngine:
 instance '6d85c380-f332-11ec-bb5f-147ddaaf4f97' of job 'Batch_Job_in_Mule_Flow'
 has reached the max allowed number of failed records. Record will be added to
 failed list and the instance will be removed from execution pool.
...
INFO  ... DefaultBatchEngine:
 instance 6d85c380-f332-11ec-bb5f-147ddaaf4f97 of job Batch_Job_in_Mule_Flow
 has been stopped. Instance status is FAILED_PROCESS_RECORDS

Batch Job インスタンス内の並列処理により、複数のレコードで同時に失敗できるようになるため、エラー数が設定した最大値を超えることができます。

Scheduling Strategy (スケジュール戦略)

schedulingStrategy

Batch Job コンポーネントが繰り返しトリガーする場合、複数の Batch Job インスタンスを同時に実行するように準備できます。インスタンスは作成タイムスタンプに基づいて (デフォルト)、または使用可能なリソースの使用を最大化しようとするラウンドロビンアルゴリズムに従って順次実行できます。この設定は、処理順序が保証されないため、他のレコードに対する副作用や連動関係がないジョブのみに適しています。

  • ORDERED_SQUENTIAL​ (デフォルト): この設定では、Batch Job インスタンスは作成タイムスタンプで確立された順序で一度に 1 つずつ実行されます。先に作成されたインスタンスが後の日時に作成されたインスタンスの前に実行されます。

  • ROUND_ROBIN​: この設定では、すべての Batch Job インスタンスが使用可能なリソースを割り当てるラウンドロビンアルゴリズムに基づいて実行されます。実行の順序は事前に決定されません。バッチインスタンスはどの順序でも実行できます。このオプションが適しているのは、インスタンスの実行で別のインスタンスの実行に対する副作用が発生しないことが確かな場合のみです。ベストプラクティスは次のとおりです。

    • 同時に実行される Batch Job インスタンスで同じレコードが更新されるのを避けるために、この戦略をデータ同期ジョブに使用しないでください。データを同期するときにこの戦略を使用すると、事前に誤ったバージョンのデータで結果を返すことが可能になります。

    • Batch Job でデータベースから新しいレコードのみを取得する場合など、Batch Job コンポーネント内の別のレコードの処理に依存するレコードがないことが確かな場合に、この戦略を使用して Batch Job インスタンスを並列実行するようにしてください。

Job Instance ID (ジョブインスタンス ID)

jobInstanceId

バッチインスタンスの認識可能な一意の名前を提供する省略可能な式。名前を一意にするには、この項目内でたとえば ​#[jobInstanceId="#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]​ などの DataWeave 式を使用する必要があります。式で同じ値が 2 回以上返される場合、Mule では ​Batch Job 'my-batch-job-example' already has an instance with id 'my-repeated-id'​ のようなメッセージでエラーがスローされます。Batch Job コンポーネントではこの値を使用して Mule フローが Batch Job コンポーネントに達するたびに新しい識別子を作成します。ID を指定しないと、Mule によって各 Batch Job インスタンスの識別子となる UUID が自動的に作成されます。

Batch Block Size (バッチブロックサイズ)

blockSize

レコードブロックあたりの処理するレコードの件数。デフォルトはブロックあたり ​100​ 件のレコードです。処理できるレコードが設定したサイズより少ない場合、Mule によってレコードプロセッサーに送信されるブロックのサイズが小さくなります。このような状況は、たとえば、1010 件のレコードがあり、ブロックサイズが 100 の場合に発生する可能性があります。これは、剰余が 0 ではなく 10 であるためです。ブロックサイズの設定により、各ブロックのレコードのサイズと ​maxConcurrency​ 設定の影響を受けるパフォーマンスを調整できます。

Max Concurrency (最大同時実行)

maxConcurrency

コンポーネント内でレコードブロックを処理するときに許可する並列性の最大レベルを設定するプロパティ。デフォルトは CPU で使用可能なコア数の 2 倍です。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。​blockSize​ 設定と同様、この設定により、パフォーマンスを調整できます。

変換先

target

Batch Job コンポーネントの​後​に配置されたコンポーネントの Batch Job インスタンスで受け取られたペイロードを使用するには、​target​ の一意の値を指定して、ダウンストリームコンポーネントの ​payload​ を使用してそのペイロードにアクセスします。対象値がない場合、Batch Job コンポーネントへの入力ペイロードをダウンストリームコンポーネントで使用できません。対象変数についての詳細は、対象変数を使用したデータの強化を参照してください。デフォルト値はありません。
### [](#ref_batch_job_history_fields)Batch Job 履歴 () Batch Job 履歴設定により、Batch Job インスタンスの履歴データが一時的な Mule ディレクトリで保持される期間を調整することにより、​`No space left on device`​ エラーを解決できます。このエラーは、空きディスクスペース、または指定したサイズの CloudHub ワーカーに対して処理するレコードの頻度が高すぎるか数が多すぎて処理できない場合に発生する可能性があります。 デフォルトでは、Batch Job インスタンスの履歴は 7 日間保持されます。この期間が経過すると、監視プロセスによりその履歴が自動的に削除されます。 ![Anypoint Studio の Batch Job の \[History (履歴)\] 項目](_images/batch-job-fields-history-studio.png) 次の表に、各項目と項目の XML 属性を示します。
名前 XML 説明

Max Age (最長有効期間)

maxAge

ジョブインスタンスが期限切れになる前の最長有効期間。例: expiration maxAge="10"​。デフォルト: maxAge=7​。

Time Unit (時間単位)

ageUnit

maxAge​ に適用する時間の単位。有効な値: DAYS​、​HOURS​、​MILLISECONDS​、​MINUTES​、​SECONDS​。デフォルト: ageUnit=DAYS​。
これらの項目は、​``​ 内に埋め込まれる ​``​ 要素に対する属性です。 ```xml ``` XML の例は、バッチ履歴項目の設定に焦点を絞るために編集されています。 ## [](#ref_batch_step_component)Batch Step コンポーネント () Batch Step コンポーネントは、Load and Dispatch フェーズや On Complete フェーズ中ではなく、Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases#phase_process)​中に実行されます。 Batch Job コンポーネント内には 1 つ以上の Batch Step コンポーネントが必要です。Batch Step コンポーネントの名前を変更するだけでなく、コンポーネントがコンポーネント内の処理に受け入れるレコードを決定する​_検索条件_​を設定できます。コンポーネントに追加したプロセッサーは、Batch Job コンポーネントが受け入れるレコードに対するアクションを実行します。 ![Anypoint Studio の Batch Job の \[General (一般)\] 項目](_images/batch-step-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
項目名 XML 説明

名前

name

Batch Step コンポーネントの設定可能な名前。Batch Job コンポーネント内の最初の Batch Step コンポーネントでは、デフォルトは ​Batch_Step​ です。後続のステップでは、​Batch_Step1​、​Batch_Step2​、といった順序に従い、一意の番号が名前に付加されます。

Accept Expression (受け入れ式)

acceptExpression

コンポーネントでレコードを処理するかどうかを決定する検索条件の省略可能な DataWeave 式。レコードの ​acceptExpression ​と​ ​acceptPolicy​ の​両方​の値が ​true​ に評価される場合、コンポーネントでは処理するためにレコードを受け入れます。それ以外の場合、コンポーネントではレコードをスキップし、レコードはダウンストリームの Batch Step コンポーネントで使用可能になります。例:

  • age​ 項目があるペイロードでは ​acceptExpression="#[payload.age > 21]"​

  • name​ 項目があるペイロードでは ​acceptExpression="#[not isBlank(payload.name)]"​。

Accept Policy (受け入れポリシー)

acceptPolicy

ポリシーがそのレコードで ​true​ に評価される場合のみ処理するためにレコードを受け入れます。受け入れの基準を、Batch Job コンポーネント内の​先行する​ (アップストリームの) Batch Step コンポーネントでレコードの処理に成功したか失敗したかにできます。コンポーネントは、正常に処理されたレコードのみを処理する、正常に処理できなかったレコードのみを処理する、または正常に処理されたかどうかに関係なくすべてのレコードを処理するように設定できます。デフォルトは ​NO_FAILURES​ です。​acceptPolicy​ はコンポーネントのどの ​acceptExpression​ よりも前に評価され、​Batch Job コンポーネント​の ​maxFailedRecords​ 設定は ​acceptPolicy​ 設定よりも優先される点に注意してください。

  • NO_FAILURES​: デフォルト設定。レコードが先行する Batch Step コンポーネント内で処理に失敗したことがない場合、またはアップストリームの Batch Step コンポーネントがない場合にレコードを処理するために受け入れます。

  • ONLY_FAILURES​: レコードが先行する Batch Step コンポーネント内で処理に失敗した場合にレコードを処理するために受け入れます。

  • ALL​: 先行する Batch Step コンポーネント内での処理に成功したか失敗したかに関係なくレコードを処理するために受け入れます。
## [](#ref_batch_aggregator_component)Batch Aggregator コンポーネント () Batch Aggregator コンポーネントはレコードの配列に対してアクションを実行する省略可能なコンポーネントです。集計は Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases#phase_process)​中に行われます。 Batch Aggregator コンポーネントにはデフォルトの設定はありません。このコンポーネントを使用する場合は、レコードをストリーミングするか (​`streaming`​)、キューから固定サイズ (​`size`​) の別の配列にレコードを取り込むか、どちらも行わないかを指定する必要があります。これらの設定は相互に排他的です。ストリーミングされたレコードへのランダムアクセスはできません。 Batch Aggregator コンポーネントではメッセージ ​`payload`​ として 1 つ以上のプロセッサーを受け入れます。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.8/for-each-scope-concept)​ スコープなど、アグリゲーター内のスコープを使用して各レコードに対して反復し、スコープ内の子プロセッサーが個別に各レコードに対するアクションを実行できるようにするのが一般的です。 Batch Aggregator コンポーネントにより、固定サイズ (​`size`​) として集計しているレコードの一部にアクセスする場合に必要な MIME タイプのレコード (​`preserveMimeTypes`​) を保持することもできます。​[「集約されたレコードの MIME タイプの保持」](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-filters-and-batch-aggregator#preserving-the-mime-types-of-the-aggregated-records)​を参照してください。このコンポーネント内のレコード処理についての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases#batch_aggregator_processing)​のバッチ集計に関する情報を参照してください。 [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#upsert)​ などの一部のコネクタには、バッチ集計プロセスを失敗させることなくレコードレベルのエラーを処理できる操作が用意されています。 Batch Aggregator を使用するときは、次の制限事項を考慮してください。 - Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java ​`Map`​ を使用してシリアル化の問題を回避します。 - Batch Aggregator コンポーネントでは、ジョブインスタンス全体の​[トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management)​がサポートされません。Batch Step コンポーネント内で、各レコードを個別のトランザクションで処理するトランザクションを定義できます。ただし、Batch Step コンポーネントによって開始されたトランザクションは、Batch Aggregator コンポーネントが処理を開始する前に終了します。トランザクションはコンポーネント間の境界を越えることができないため、コンポーネントはトランザクションを共有できます。 ![Anypoint Studio の Batch Aggregator コンポーネントの項目](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/batch-aggregator-fields-studio.png) 次の表に、各項目と項目の XML 要素を示します。
項目名 XML 説明

Display Name (表示名)

doc:name

コンポーネントの設定可能な名前。例: doc:name="My Aggregator"​。デフォルトの名前は ​Batch Aggregator​ です。

Aggregator Size (Aggregator サイズ)

size

処理するレコードの各配列のサイズ。デフォルトのサイズはありません。コンポーネント内のプロセッサーは入力として配列を受け入れる必要があります。コンポーネントはレコードを残りがなくなるまでバッチステッピングキューから設定したサイズの配列に取り込み続けます。キューに含まれるレコードが設定したサイズより少ない場合、コンポーネントがこれらのレコードを処理するための取り込み先の配列が小さくなります。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

この設定を使用するときは、コンポーネントは Batch Step コンポーネントがインスタンスまたはバッチのすべてのレコードの処理を完了するのを待機しません。ステッピングキューで設定した数のレコードが使用可能になると、Batch Aggregator コンポーネントはこれらのレコードを配列に取り込んで処理します。

ストリーミング

streaming

streaming=true​ の場合、コンポーネントは Batch Job インスタンスのすべてのレコードに対するアクションを実行し、インスタンスのレコード数と同じサイズの配列で結果を返します。Batch Job コンポーネントを使用してバッチサイズを設定しても、処理するレコード数または配列で返すレコード数は制限されません。たとえば、Aggregator が ​{"id": 1}​、​{"id": 2}​、といった形式の ​10​ 個のレコードのみを処理する小さな Batch Job インスタンスの数値の ID を返すとします。この場合、Batch Job コンポーネントの ​blockSize​ が ​5​ のようにインスタンスのレコード数より小さい数に設定されていたとしても、インスタンスの出力配列には ​[1, 6, 2, 7, 3, 8, 4, 9, 5, 10]​ などの 10 個の ID が含まれます。

プロセッサーはストリーミングされたレコードの配列に順次アクセスできます。Aggregator では処理されたレコードが保持されないため、ストリーミングされたレコードへのランダムアクセスはできません。

デフォルトはありません。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

Preserve Mime Types (MIME タイプを保持)

preserveMimeTypes

デフォルトは ​false​ です。このコンポーネント内で処理されるレコードの MIME タイプを保持するには、この属性を ​true​ に設定します。 データの MIME タイプを判断できないプロセッサーは、​null​ や、​[[B@e596d5c, [B@1c4c3b32], …​]​ などの判読できないペイロードへの参照を出力として返します。​preserveMimeTypes=true​ の設定は、コンポーネントが固定数 (​size​) のレコードを処理するように設定されている場合に便利です。
集計されたレコードをストリーミングするかどうかを決定するときは、次の点を考慮してください。 - SaaS プロバイダーでは、ストリーミング入力の受入に制約がある場合が多くあります。 - バッチストリーミングは、CSV、JSON、XML などのファイルに書き込む場合のバッチ処理に便利な場合が多くあります。 - レコードの配列は RAM に格納され、トランザクションの処理速度が低下する可能性があるため、バッチストリーミングはアプリケーションのパフォーマンスに影響します。パフォーマンスは低下しますが、その分、ストリーミングデータが確実に使用できるようになる可能性があります。 - ストリーミングのコミットは 1 つずつの読み取りで前方移動のみのイテレーターであるため、ストリーミングではレコードへのランダムアクセスはできません。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.8/for-each-scope-concept)​ などのコンポーネントを使用した場合はストリーミング時にランダムアクセス操作を実行できます。For Each により、レコードの個別の配列が提供され、その ​`records`​ 変数を使用してアクセスできます。 # バッチコンポーネントリファレンス Mule バッチコンポーネントでは、デフォルトのコンポーネント設定に対する調整を最小限に抑えてレコードのバッチ処理を管理します。コンポーネントは、処理およびパフォーマンスに関する特定の要件に合わせて高度に設定可能です。 Batch Job コンポーネントには 1 つ以上の Batch Step コンポーネントが含まれている必要があります。必要に応じて、各 Batch Step コンポーネントには 1 つの Batch Aggregator コンポーネントを含めることができます。次の図の Mule フローはバッチコンポーネントを示しています。 ![Anypoint Studio のバッチ処理コンポーネントが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/batch-flow-generic-example.png) Batch Job コンポーネントでは Mule メッセージのペイロードをレコードに分割します。Batch Step コンポーネントおよび Batch Aggregator コンポーネント内で、これらのレコードはキーワード ​`payload`​ で使用でき、Mule 変数は ​`vars`​ キーワードを使用してアクセスすることもできます。ただし、Mule 属性はこれらのコンポーネント内からアクセスできません。どちらのコンポーネントも ​`attributes`​ で ​`null`​ を返します。 このリファレンスでは、読者が Batch Job インスタンスの​[バッチ処理フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases)​に精通していることを前提としています。 ## [](#ref_batch_job_component)Batch Job コンポーネント () このコンポーネントでは、処理用の入力を準備し、その処理の結果が記載されたレポートを出力します。準備は Batch Job インスタンスの ​[Load and Dispatch](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases#phase_load_dispatch)​ フェーズ中に行われ、レポートは ​[On Complete](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases#phase_on_complete)​ フェーズで使用できます。 Studio では、これらのプロパティをコンポーネントの ​[\[General (一般)\]](#ref_batch_job_general_fields)​ タブと ​[\[History (履歴)\]](#ref_batch_job_history_fields)​ タブで設定できます。 ### [](#ref_batch_job_general_fields)Batch Job のプロパティ Batch Job コンポーネントには、バッチ処理の実行方法を決定する設定可能な多数のプロパティが用意されています。また、入力ペイロードをフローの後続のコンポーネントで使用できるように対象変数に格納することもできます。Batch Job コンポーネントはメッセージペイロードをコンシュームするため、これは便利な可能性があります。 Anypoint Studio の ​**\[General (一般)\]**​ タブには次の項目があります。 ![Anypoint Studio の Batch Job の項目](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/batch-job-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
項目名 XML 説明

名前

name

Batch Job コンポーネントの設定可能な名前。デフォルトの名前はアプリケーションの名前に ​Batch_Job​ を追加したものです。

Max Failed Records (最大失敗レコード数)

maxFailedRecords

Batch Job インスタンスの実行が停止する前にその Batch Job インスタンス内で失敗できるレコードの最大数。デフォルトは ​0​ です。無制限にする場合は、​-1​ を使用します。この設定は、Batch Job コンポーネント内の ​Batch Step コンポーネント​のどの受け入れポリシー (​acceptPolicy​) または式 (​acceptExpression​) 検索条件よりも優先されます。Batch Job インスタンスが ​maxFailedRecords​ 値を超えると、Batch Job コンポーネントでエラーが発生した Batch Job インスタンスの処理が停止され、インスタンスに状況 ​FAILED_PROCESS_RECORDS​ が割り当てられ、インスタンスで失敗したレコードの数が報告されます。Batch Job インスタンスがこのしきい値に達すると、コンソールでは次のようなメッセージが出力されます (読みやすいように編集済み)。

INFO  ... DefaultBatchEngine:
 instance '6d85c380-f332-11ec-bb5f-147ddaaf4f97' of job 'Batch_Job_in_Mule_Flow'
 has reached the max allowed number of failed records. Record will be added to
 failed list and the instance will be removed from execution pool.
...
INFO  ... DefaultBatchEngine:
 instance 6d85c380-f332-11ec-bb5f-147ddaaf4f97 of job Batch_Job_in_Mule_Flow
 has been stopped. Instance status is FAILED_PROCESS_RECORDS

Batch Job インスタンス内の並列処理により、複数のレコードで同時に失敗できるようになるため、エラー数が設定した最大値を超えることができます。

Scheduling Strategy (スケジュール戦略)

schedulingStrategy

Batch Job コンポーネントが繰り返しトリガーする場合、複数の Batch Job インスタンスを同時に実行するように準備できます。インスタンスは作成タイムスタンプに基づいて (デフォルト)、または使用可能なリソースの使用を最大化しようとするラウンドロビンアルゴリズムに従って順次実行できます。この設定は、処理順序が保証されないため、他のレコードに対する副作用や連動関係がないジョブのみに適しています。

  • ORDERED_SQUENTIAL​ (デフォルト): この設定では、Batch Job インスタンスは作成タイムスタンプで確立された順序で一度に 1 つずつ実行されます。先に作成されたインスタンスが後の日時に作成されたインスタンスの前に実行されます。

  • ROUND_ROBIN​: この設定では、すべての Batch Job インスタンスが使用可能なリソースを割り当てるラウンドロビンアルゴリズムに基づいて実行されます。実行の順序は事前に決定されません。バッチインスタンスはどの順序でも実行できます。このオプションが適しているのは、インスタンスの実行で別のインスタンスの実行に対する副作用が発生しないことが確かな場合のみです。ベストプラクティスは次のとおりです。

    • 同時に実行される Batch Job インスタンスで同じレコードが更新されるのを避けるために、この戦略をデータ同期ジョブに使用しないでください。データを同期するときにこの戦略を使用すると、事前に誤ったバージョンのデータで結果を返すことが可能になります。

    • Batch Job でデータベースから新しいレコードのみを取得する場合など、Batch Job コンポーネント内の別のレコードの処理に依存するレコードがないことが確かな場合に、この戦略を使用して Batch Job インスタンスを並列実行するようにしてください。

Job Instance ID (ジョブインスタンス ID)

jobInstanceId

バッチインスタンスの認識可能な一意の名前を提供する省略可能な式。名前を一意にするには、この項目内でたとえば ​#[jobInstanceId="#['Job From ' ++ now() as String {format: 'dd/MM/yy hh:mm:ss'}]​ などの DataWeave 式を使用する必要があります。式で同じ値が 2 回以上返される場合、Mule では ​Batch Job 'my-batch-job-example' already has an instance with id 'my-repeated-id'​ のようなメッセージでエラーがスローされます。Batch Job コンポーネントではこの値を使用して Mule フローが Batch Job コンポーネントに達するたびに新しい識別子を作成します。ID を指定しないと、Mule によって各 Batch Job インスタンスの識別子となる UUID が自動的に作成されます。

Batch Block Size (バッチブロックサイズ)

blockSize

レコードブロックあたりの処理するレコードの件数。デフォルトはブロックあたり ​100​ 件のレコードです。処理できるレコードが設定したサイズより少ない場合、Mule によってレコードプロセッサーに送信されるブロックのサイズが小さくなります。このような状況は、たとえば、1010 件のレコードがあり、ブロックサイズが 100 の場合に発生する可能性があります。これは、剰余が 0 ではなく 10 であるためです。ブロックサイズの設定により、各ブロックのレコードのサイズと ​maxConcurrency​ 設定の影響を受けるパフォーマンスを調整できます。

Max Concurrency (最大同時実行)

maxConcurrency

コンポーネント内でレコードブロックを処理するときに許可する並列性の最大レベルを設定するプロパティ。デフォルトは CPU で使用可能なコア数の 2 倍です。Mule インスタンスを実行しているシステムの容量によっても、同時実行が制限されます。​blockSize​ 設定と同様、この設定により、パフォーマンスを調整できます。

変換先

target

Batch Job コンポーネントの​後​に配置されたコンポーネントの Batch Job インスタンスで受け取られたペイロードを使用するには、​target​ の一意の値を指定して、ダウンストリームコンポーネントの ​payload​ を使用してそのペイロードにアクセスします。対象値がない場合、Batch Job コンポーネントへの入力ペイロードをダウンストリームコンポーネントで使用できません。対象変数についての詳細は、対象変数を使用したデータの強化を参照してください。デフォルト値はありません。
### [](#ref_batch_job_history_fields)Batch Job 履歴 () Batch Job 履歴設定により、Batch Job インスタンスの履歴データが一時的な Mule ディレクトリで保持される期間を調整することにより、​`No space left on device`​ エラーを解決できます。このエラーは、空きディスクスペース、または指定したサイズの CloudHub ワーカーに対して処理するレコードの頻度が高すぎるか数が多すぎて処理できない場合に発生する可能性があります。 デフォルトでは、Batch Job インスタンスの履歴は 7 日間保持されます。この期間が経過すると、監視プロセスによりその履歴が自動的に削除されます。 ![Anypoint Studio の Batch Job の \[History (履歴)\] 項目](_images/batch-job-fields-history-studio.png) 次の表に、各項目と項目の XML 属性を示します。
名前 XML 説明

Max Age (最長有効期間)

maxAge

ジョブインスタンスが期限切れになる前の最長有効期間。例: expiration maxAge="10"​。デフォルト: maxAge=7​。

Time Unit (時間単位)

ageUnit

maxAge​ に適用する時間の単位。有効な値: DAYS​、​HOURS​、​MILLISECONDS​、​MINUTES​、​SECONDS​。デフォルト: ageUnit=DAYS​。
これらの項目は、​``​ 内に埋め込まれる ​``​ 要素に対する属性です。 ```xml ``` XML の例は、バッチ履歴項目の設定に焦点を絞るために編集されています。 ## [](#ref_batch_step_component)Batch Step コンポーネント () Batch Step コンポーネントは、Load and Dispatch フェーズや On Complete フェーズ中ではなく、Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases#phase_process)​中に実行されます。 Batch Job コンポーネント内には 1 つ以上の Batch Step コンポーネントが必要です。Batch Step コンポーネントの名前を変更するだけでなく、コンポーネントがコンポーネント内の処理に受け入れるレコードを決定する​_検索条件_​を設定できます。コンポーネントに追加したプロセッサーは、Batch Job コンポーネントが受け入れるレコードに対するアクションを実行します。 ![Anypoint Studio の Batch Job の \[General (一般)\] 項目](_images/batch-step-fields-studio.png) 次の表に、各項目と項目の XML 属性を示します。
項目名 XML 説明

名前

name

Batch Step コンポーネントの設定可能な名前。Batch Job コンポーネント内の最初の Batch Step コンポーネントでは、デフォルトは ​Batch_Step​ です。後続のステップでは、​Batch_Step1​、​Batch_Step2​、といった順序に従い、一意の番号が名前に付加されます。

Accept Expression (受け入れ式)

acceptExpression

コンポーネントでレコードを処理するかどうかを決定する検索条件の省略可能な DataWeave 式。レコードの ​acceptExpression ​と​ ​acceptPolicy​ の​両方​の値が ​true​ に評価される場合、コンポーネントでは処理するためにレコードを受け入れます。それ以外の場合、コンポーネントではレコードをスキップし、レコードはダウンストリームの Batch Step コンポーネントで使用可能になります。例:

  • age​ 項目があるペイロードでは ​acceptExpression="#[payload.age > 21]"​

  • name​ 項目があるペイロードでは ​acceptExpression="#[not isBlank(payload.name)]"​。

Accept Policy (受け入れポリシー)

acceptPolicy

ポリシーがそのレコードで ​true​ に評価される場合のみ処理するためにレコードを受け入れます。受け入れの基準を、Batch Job コンポーネント内の​先行する​ (アップストリームの) Batch Step コンポーネントでレコードの処理に成功したか失敗したかにできます。コンポーネントは、正常に処理されたレコードのみを処理する、正常に処理できなかったレコードのみを処理する、または正常に処理されたかどうかに関係なくすべてのレコードを処理するように設定できます。デフォルトは ​NO_FAILURES​ です。​acceptPolicy​ はコンポーネントのどの ​acceptExpression​ よりも前に評価され、​Batch Job コンポーネント​の ​maxFailedRecords​ 設定は ​acceptPolicy​ 設定よりも優先される点に注意してください。

  • NO_FAILURES​: デフォルト設定。レコードが先行する Batch Step コンポーネント内で処理に失敗したことがない場合、またはアップストリームの Batch Step コンポーネントがない場合にレコードを処理するために受け入れます。

  • ONLY_FAILURES​: レコードが先行する Batch Step コンポーネント内で処理に失敗した場合にレコードを処理するために受け入れます。

  • ALL​: 先行する Batch Step コンポーネント内での処理に成功したか失敗したかに関係なくレコードを処理するために受け入れます。
## [](#ref_batch_aggregator_component)Batch Aggregator コンポーネント () Batch Aggregator コンポーネントはレコードの配列に対してアクションを実行する省略可能なコンポーネントです。集計は Batch Job インスタンスの ​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases#phase_process)​中に行われます。 Batch Aggregator コンポーネントにはデフォルトの設定はありません。このコンポーネントを使用する場合は、レコードをストリーミングするか (​`streaming`​)、キューから固定サイズ (​`size`​) の別の配列にレコードを取り込むか、どちらも行わないかを指定する必要があります。これらの設定は相互に排他的です。ストリーミングされたレコードへのランダムアクセスはできません。 Batch Aggregator コンポーネントではメッセージ ​`payload`​ として 1 つ以上のプロセッサーを受け入れます。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.9/for-each-scope-concept)​ スコープなど、アグリゲーター内のスコープを使用して各レコードに対して反復し、スコープ内の子プロセッサーが個別に各レコードに対するアクションを実行できるようにするのが一般的です。 Batch Aggregator コンポーネントにより、固定サイズ (​`size`​) として集計しているレコードの一部にアクセスする場合に必要な MIME タイプのレコード (​`preserveMimeTypes`​) を保持することもできます。​[「集約されたレコードの MIME タイプの保持」](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-filters-and-batch-aggregator#preserving-the-mime-types-of-the-aggregated-records)​を参照してください。このコンポーネント内のレコード処理についての詳細は、​[「Process フェーズ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases#batch_aggregator_processing)​のバッチ集計に関する情報を参照してください。 [Salesforce 用 Anypoint Connector (Salesforce Connector)](https://docs.mulesoft.com/salesforce-connector/latest/salesforce-connector-reference#upsert)​ や ​[NetSuite 用 Anypoint Connector (NetSuite Connector)](https://docs.mulesoft.com/netsuite-connector/latest/netsuite-reference#upsert)​ などの一部のコネクタには、バッチ集計プロセスを失敗させることなくレコードレベルのエラーを処理できる操作が用意されています。 Batch Aggregator を使用するときは、次の制限事項を考慮してください。 - Batch Aggregator コンポーネントを使用するときには、​`ImmutableMap`​ などの Guava データ型を処理しようとしないでください。代わりに、Java ​`Map`​ を使用してシリアル化の問題を回避します。 - Batch Aggregator コンポーネントでは、ジョブインスタンス全体の​[トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management)​がサポートされません。Batch Step コンポーネント内で、各レコードを個別のトランザクションで処理するトランザクションを定義できます。ただし、Batch Step コンポーネントによって開始されたトランザクションは、Batch Aggregator コンポーネントが処理を開始する前に終了します。トランザクションはコンポーネント間の境界を越えることができないため、コンポーネントはトランザクションを共有できます。 ![Anypoint Studio の Batch Aggregator コンポーネントの項目](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/batch-aggregator-fields-studio.png) 次の表に、各項目と項目の XML 要素を示します。
項目名 XML 説明

Display Name (表示名)

doc:name

コンポーネントの設定可能な名前。例: doc:name="My Aggregator"​。デフォルトの名前は ​Batch Aggregator​ です。

Aggregator Size (Aggregator サイズ)

size

処理するレコードの各配列のサイズ。デフォルトのサイズはありません。コンポーネント内のプロセッサーは入力として配列を受け入れる必要があります。コンポーネントはレコードを残りがなくなるまでバッチステッピングキューから設定したサイズの配列に取り込み続けます。キューに含まれるレコードが設定したサイズより少ない場合、コンポーネントがこれらのレコードを処理するための取り込み先の配列が小さくなります。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

この設定を使用するときは、コンポーネントは Batch Step コンポーネントがインスタンスまたはバッチのすべてのレコードの処理を完了するのを待機しません。ステッピングキューで設定した数のレコードが使用可能になると、Batch Aggregator コンポーネントはこれらのレコードを配列に取り込んで処理します。

ストリーミング

streaming

streaming=true​ の場合、コンポーネントは Batch Job インスタンスのすべてのレコードに対するアクションを実行し、インスタンスのレコード数と同じサイズの配列で結果を返します。Batch Job コンポーネントを使用してバッチサイズを設定しても、処理するレコード数または配列で返すレコード数は制限されません。たとえば、Aggregator が ​{"id": 1}​、​{"id": 2}​、といった形式の ​10​ 個のレコードのみを処理する小さな Batch Job インスタンスの数値の ID を返すとします。この場合、Batch Job コンポーネントの ​blockSize​ が ​5​ のようにインスタンスのレコード数より小さい数に設定されていたとしても、インスタンスの出力配列には ​[1, 6, 2, 7, 3, 8, 4, 9, 5, 10]​ などの 10 個の ID が含まれます。

プロセッサーはストリーミングされたレコードの配列に順次アクセスできます。Aggregator では処理されたレコードが保持されないため、ストリーミングされたレコードへのランダムアクセスはできません。

デフォルトはありません。Size (サイズ) (​size​) または Streaming (ストリーミング) (​streaming​) プロパティを設定する必要がありますが、両方を設定することはできません。

Preserve Mime Types (MIME タイプを保持)

preserveMimeTypes

デフォルトは ​false​ です。このコンポーネント内で処理されるレコードの MIME タイプを保持するには、この属性を ​true​ に設定します。 データの MIME タイプを判断できないプロセッサーは、​null​ や、​[[B@e596d5c, [B@1c4c3b32], …​]​ などの判読できないペイロードへの参照を出力として返します。​preserveMimeTypes=true​ の設定は、コンポーネントが固定数 (​size​) のレコードを処理するように設定されている場合に便利です。
集計されたレコードをストリーミングするかどうかを決定するときは、次の点を考慮してください。 - SaaS プロバイダーでは、ストリーミング入力の受入に制約がある場合が多くあります。 - バッチストリーミングは、CSV、JSON、XML などのファイルに書き込む場合のバッチ処理に便利な場合が多くあります。 - レコードの配列は RAM に格納され、トランザクションの処理速度が低下する可能性があるため、バッチストリーミングはアプリケーションのパフォーマンスに影響します。パフォーマンスは低下しますが、その分、ストリーミングデータが確実に使用できるようになる可能性があります。 - ストリーミングのコミットは 1 つずつの読み取りで前方移動のみのイテレーターであるため、ストリーミングではレコードへのランダムアクセスはできません。ただし、​[For Each](https://docs.mulesoft.com/jp/mule-runtime/4.9/for-each-scope-concept)​ などのコンポーネントを使用した場合はストリーミング時にランダムアクセス操作を実行できます。For Each により、レコードの個別の配列が提供され、その ​`records`​ 変数を使用してアクセスできます。 # バッチモジュールの移行 バッチモジュールは Extract Transform Load (ETL) 機能を処理するために導入されました。 このセクションの内容 - [バッチ要素の移行](#batch_scope) - [Record Vars から Vars への移行](#record_var) - [非 Java データセットのサポート](#non_java_datasets) - [Mule 4 のバッチ要素および属性の XML 変更](#xml_changes) ## [](#batch_scope)バッチ要素の移行 Mule 3 では、バッチはフローと同じ最上位レベルの要素でした。Mule 4 の場合、​``​ 要素は、わかりやすく、動的な呼び出しや他の Mule コンポーネントとのやり取りがしやすいようにフローの内部に配置するスコープです。 これは ​``​ は使用されなくなることを意味します。​``​ の役割は、​``​ がトリガーされる前に、フロー内にある一連のプロセッサーによって果たされます。 - ``​: バッチはスコープですが名前が付いています。Mule アプリケーションでは、同じ名前の付いた 2 つの ​``​ 定義を使用することはできません。これにより、1 つのフローで複数のジョブが定義される場合の追跡と管理が向上します。 - ``​: この操作はなくなりました。代わりに、バッチジョブを含むフローを呼び出します。 Mule 3 の例 ```xml <> > ``` Mule 4 の例 ```xml ``` ## [](#record_var)Record Vars から Vars への移行 通常のフローとは異なり、バッチはメッセージレベルではなく、レコードレベルで処理を行います。 Mule 3 では、Mule メッセージにフロー変数 (​`flowVars`​) を使用するのと同様に、レコードレベル変数 (​`recordVars`​) を使用して変数を特定のレコードに添付します。 Mule 4 では ​`recordVars`​ が変数 (​`vars`​) に置き換わります。変数は Mule 4 の Mule イベントの一部です。​``​ 内から、​``​ の実行開始前に存在した変数を変更できます。これは他のレコードへの副作用がなく、特定の 1 つのレコードに対して行うことができます。 次の Mule 3 の例では、For Each コンポーネントの式内で ​`recordVars`​ が使用されています。 Mule 3 の例 ```xml record.payload = 'foo'; record.recordVars['marco'] = 'polo'; ``` 次の Mule 4 の例では、For Each コンポーネントの式内で ​`vars`​ が使用されています。 Mule 4 の例 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` ## [](#non_java_datasets)非 Java データセットのサポート Mule 3 では、バッチの入力フェーズは Java 構造であることが必要でした。そのため、XML 形式や JSON 形式などの入力データは、最初に Java に変換し、その変換では、DataWeave でストリーミングを使用してデータセットが大きい場合にメモリ不足にならないようにする必要がありました。 たとえば、HTTP コールでアプリケーションにプッシュされる次のようなソースデータがあるとします。 例: JSON 入力データ \[ { "name": "Luke Skywalker", "darkSide": true }, { "name": "Ben Solo", "darkSide": true }, { "name": "Obi-Wan Kenobi", "darkSide": false } \] Mule 3 では、この JSON を渡す前に Java に変更する必要がありました。次のようになります。 Mule 3 の例 ```xml <> <> ..... ``` Mule 4 では、バッチでペイロードが JSON 配列であることを自動的に判断し、単独で分割を実行できます。次に例を示します。 Mule 4 の例 ```xml .... ``` Mule 4 では、自動ストリーミングフレームワークが使用されているため、ストリーミングを設定する必要がなくなりました。したがって、Mule 4 に移行すると、変換ステップを回避できます。 ## [](#xml_changes)Mule 4 のバッチ要素および属性の XML 変更 - キャメルケース表記の属性: Mule 4 DSL ガイドラインに従い、一貫性を向上させるために、すべての DSL 属性はキャメルケースに変更されました。たとえば、​`max-failed-records`​ は ​`maxFailedRecords`​、​`accept-policy`​ は ​`acceptPolicy`​ のようになります。 - MuleSoft では、​`` ` ``​ 要素から ​`filter-expression`​ パラメーターを削除しました。この属性は Mule 3.6 で非推奨になったため、​`accept-expression`​ パラメーターに置き換える必要があります。 - ``​ は ​``​ と呼ばれるようになりました。 ## [](#関連情報)関連情報 - [バッチプロセッサー](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-processing-concept) # バッチモジュールの移行 バッチモジュールは Extract Transform Load (ETL) 機能を処理するために導入されました。 このセクションの内容 - [バッチ要素の移行](#batch_scope) - [Record Vars から Vars への移行](#record_var) - [非 Java データセットのサポート](#non_java_datasets) - [Mule 4 のバッチ要素および属性の XML 変更](#xml_changes) ## [](#batch_scope)バッチ要素の移行 Mule 3 では、バッチはフローと同じ最上位レベルの要素でした。Mule 4 の場合、​``​ 要素は、わかりやすく、動的な呼び出しや他の Mule コンポーネントとのやり取りがしやすいようにフローの内部に配置するスコープです。 これは ​``​ は使用されなくなることを意味します。​``​ の役割は、​``​ がトリガーされる前に、フロー内にある一連のプロセッサーによって果たされます。 - ``​: バッチはスコープですが名前が付いています。Mule アプリケーションでは、同じ名前の付いた 2 つの ​``​ 定義を使用することはできません。これにより、1 つのフローで複数のジョブが定義される場合の追跡と管理が向上します。 - ``​: この操作はなくなりました。代わりに、バッチジョブを含むフローを呼び出します。 Mule 3 の例 ```xml <> > ``` Mule 4 の例 ```xml ``` ## [](#record_var)Record Vars から Vars への移行 通常のフローとは異なり、バッチはメッセージレベルではなく、レコードレベルで処理を行います。 Mule 3 では、Mule メッセージにフロー変数 (​`flowVars`​) を使用するのと同様に、レコードレベル変数 (​`recordVars`​) を使用して変数を特定のレコードに添付します。 Mule 4 では ​`recordVars`​ が変数 (​`vars`​) に置き換わります。変数は Mule 4 の Mule イベントの一部です。​``​ 内から、​``​ の実行開始前に存在した変数を変更できます。これは他のレコードへの副作用がなく、特定の 1 つのレコードに対して行うことができます。 次の Mule 3 の例では、For Each コンポーネントの式内で ​`recordVars`​ が使用されています。 Mule 3 の例 ```xml record.payload = 'foo'; record.recordVars['marco'] = 'polo'; ``` 次の Mule 4 の例では、For Each コンポーネントの式内で ​`vars`​ が使用されています。 Mule 4 の例 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` ## [](#non_java_datasets)非 Java データセットのサポート Mule 3 では、バッチの入力フェーズは Java 構造であることが必要でした。そのため、XML 形式や JSON 形式などの入力データは、最初に Java に変換し、その変換では、DataWeave でストリーミングを使用してデータセットが大きい場合にメモリ不足にならないようにする必要がありました。 たとえば、HTTP コールでアプリケーションにプッシュされる次のようなソースデータがあるとします。 例: JSON 入力データ \[ { "name": "Luke Skywalker", "darkSide": true }, { "name": "Ben Solo", "darkSide": true }, { "name": "Obi-Wan Kenobi", "darkSide": false } \] Mule 3 では、この JSON を渡す前に Java に変更する必要がありました。次のようになります。 Mule 3 の例 ```xml <> <> ..... ``` Mule 4 では、バッチでペイロードが JSON 配列であることを自動的に判断し、単独で分割を実行できます。次に例を示します。 Mule 4 の例 ```xml .... ``` Mule 4 では、自動ストリーミングフレームワークが使用されているため、ストリーミングを設定する必要がなくなりました。したがって、Mule 4 に移行すると、変換ステップを回避できます。 ## [](#xml_changes)Mule 4 のバッチ要素および属性の XML 変更 - キャメルケース表記の属性: Mule 4 DSL ガイドラインに従い、一貫性を向上させるために、すべての DSL 属性はキャメルケースに変更されました。たとえば、​`max-failed-records`​ は ​`maxFailedRecords`​、​`accept-policy`​ は ​`acceptPolicy`​ のようになります。 - MuleSoft では、​`` ` ``​ 要素から ​`filter-expression`​ パラメーターを削除しました。この属性は Mule 3.6 で非推奨になったため、​`accept-expression`​ パラメーターに置き換える必要があります。 - ``​ は ​``​ と呼ばれるようになりました。 ## [](#関連情報)関連情報 - [バッチプロセッサー](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-processing-concept) # バッチモジュールの移行 バッチモジュールは Extract Transform Load (ETL) 機能を処理するために導入されました。 このセクションの内容 - [バッチ要素の移行](#batch_scope) - [Record Vars から Vars への移行](#record_var) - [非 Java データセットのサポート](#non_java_datasets) - [Mule 4 のバッチ要素および属性の XML 変更](#xml_changes) ## [](#batch_scope)バッチ要素の移行 Mule 3 では、バッチはフローと同じ最上位レベルの要素でした。Mule 4 の場合、​``​ 要素は、わかりやすく、動的な呼び出しや他の Mule コンポーネントとのやり取りがしやすいようにフローの内部に配置するスコープです。 これは ​``​ は使用されなくなることを意味します。​``​ の役割は、​``​ がトリガーされる前に、フロー内にある一連のプロセッサーによって果たされます。 - ``​: バッチはスコープですが名前が付いています。Mule アプリケーションでは、同じ名前の付いた 2 つの ​``​ 定義を使用することはできません。これにより、1 つのフローで複数のジョブが定義される場合の追跡と管理が向上します。 - ``​: この操作はなくなりました。代わりに、バッチジョブを含むフローを呼び出します。 Mule 3 の例 ```xml <> > ``` Mule 4 の例 ```xml ``` ## [](#record_var)Record Vars から Vars への移行 通常のフローとは異なり、バッチはメッセージレベルではなく、レコードレベルで処理を行います。 Mule 3 では、Mule メッセージにフロー変数 (​`flowVars`​) を使用するのと同様に、レコードレベル変数 (​`recordVars`​) を使用して変数を特定のレコードに添付します。 Mule 4 では ​`recordVars`​ が変数 (​`vars`​) に置き換わります。変数は Mule 4 の Mule イベントの一部です。​``​ 内から、​``​ の実行開始前に存在した変数を変更できます。これは他のレコードへの副作用がなく、特定の 1 つのレコードに対して行うことができます。 次の Mule 3 の例では、For Each コンポーネントの式内で ​`recordVars`​ が使用されています。 Mule 3 の例 ```xml record.payload = 'foo'; record.recordVars['marco'] = 'polo'; ``` 次の Mule 4 の例では、For Each コンポーネントの式内で ​`vars`​ が使用されています。 Mule 4 の例 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` ## [](#non_java_datasets)非 Java データセットのサポート Mule 3 では、バッチの入力フェーズは Java 構造であることが必要でした。そのため、XML 形式や JSON 形式などの入力データは、最初に Java に変換し、その変換では、DataWeave でストリーミングを使用してデータセットが大きい場合にメモリ不足にならないようにする必要がありました。 たとえば、HTTP コールでアプリケーションにプッシュされる次のようなソースデータがあるとします。 例: JSON 入力データ \[ { "name": "Luke Skywalker", "darkSide": true }, { "name": "Ben Solo", "darkSide": true }, { "name": "Obi-Wan Kenobi", "darkSide": false } \] Mule 3 では、この JSON を渡す前に Java に変更する必要がありました。次のようになります。 Mule 3 の例 ```xml <> <> ..... ``` Mule 4 では、バッチでペイロードが JSON 配列であることを自動的に判断し、単独で分割を実行できます。次に例を示します。 Mule 4 の例 ```xml .... ``` Mule 4 では、自動ストリーミングフレームワークが使用されているため、ストリーミングを設定する必要がなくなりました。したがって、Mule 4 に移行すると、変換ステップを回避できます。 ## [](#xml_changes)Mule 4 のバッチ要素および属性の XML 変更 - キャメルケース表記の属性: Mule 4 DSL ガイドラインに従い、一貫性を向上させるために、すべての DSL 属性はキャメルケースに変更されました。たとえば、​`max-failed-records`​ は ​`maxFailedRecords`​、​`accept-policy`​ は ​`acceptPolicy`​ のようになります。 - MuleSoft では、​`` ` ``​ 要素から ​`filter-expression`​ パラメーターを削除しました。この属性は Mule 3.6 で非推奨になったため、​`accept-expression`​ パラメーターに置き換える必要があります。 - ``​ は ​``​ と呼ばれるようになりました。 ## [](#関連情報)関連情報 - [バッチプロセッサー](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-processing-concept) # バッチモジュールの移行 バッチモジュールは Extract Transform Load (ETL) 機能を処理するために導入されました。 このセクションの内容 - [バッチ要素の移行](#batch_scope) - [Record Vars から Vars への移行](#record_var) - [非 Java データセットのサポート](#non_java_datasets) - [Mule 4 のバッチ要素および属性の XML 変更](#xml_changes) ## [](#batch_scope)バッチ要素の移行 Mule 3 では、バッチはフローと同じ最上位レベルの要素でした。Mule 4 の場合、​``​ 要素は、わかりやすく、動的な呼び出しや他の Mule コンポーネントとのやり取りがしやすいようにフローの内部に配置するスコープです。 これは ​``​ は使用されなくなることを意味します。​``​ の役割は、​``​ がトリガーされる前に、フロー内にある一連のプロセッサーによって果たされます。 - ``​: バッチはスコープですが名前が付いています。Mule アプリケーションでは、同じ名前の付いた 2 つの ​``​ 定義を使用することはできません。これにより、1 つのフローで複数のジョブが定義される場合の追跡と管理が向上します。 - ``​: この操作はなくなりました。代わりに、バッチジョブを含むフローを呼び出します。 Mule 3 の例 ```xml <> > ``` Mule 4 の例 ```xml ``` ## [](#record_var)Record Vars から Vars への移行 通常のフローとは異なり、バッチはメッセージレベルではなく、レコードレベルで処理を行います。 Mule 3 では、Mule メッセージにフロー変数 (​`flowVars`​) を使用するのと同様に、レコードレベル変数 (​`recordVars`​) を使用して変数を特定のレコードに添付します。 Mule 4 では ​`recordVars`​ が変数 (​`vars`​) に置き換わります。変数は Mule 4 の Mule イベントの一部です。​``​ 内から、​``​ の実行開始前に存在した変数を変更できます。これは他のレコードへの副作用がなく、特定の 1 つのレコードに対して行うことができます。 次の Mule 3 の例では、For Each コンポーネントの式内で ​`recordVars`​ が使用されています。 Mule 3 の例 ```xml record.payload = 'foo'; record.recordVars['marco'] = 'polo'; ``` 次の Mule 4 の例では、For Each コンポーネントの式内で ​`vars`​ が使用されています。 Mule 4 の例 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` ## [](#non_java_datasets)非 Java データセットのサポート Mule 3 では、バッチの入力フェーズは Java 構造であることが必要でした。そのため、XML 形式や JSON 形式などの入力データは、最初に Java に変換し、その変換では、DataWeave でストリーミングを使用してデータセットが大きい場合にメモリ不足にならないようにする必要がありました。 たとえば、HTTP コールでアプリケーションにプッシュされる次のようなソースデータがあるとします。 例: JSON 入力データ \[ { "name": "Luke Skywalker", "darkSide": true }, { "name": "Ben Solo", "darkSide": true }, { "name": "Obi-Wan Kenobi", "darkSide": false } \] Mule 3 では、この JSON を渡す前に Java に変更する必要がありました。次のようになります。 Mule 3 の例 ```xml <> <> ..... ``` Mule 4 では、バッチでペイロードが JSON 配列であることを自動的に判断し、単独で分割を実行できます。次に例を示します。 Mule 4 の例 ```xml .... ``` Mule 4 では、自動ストリーミングフレームワークが使用されているため、ストリーミングを設定する必要がなくなりました。したがって、Mule 4 に移行すると、変換ステップを回避できます。 ## [](#xml_changes)Mule 4 のバッチ要素および属性の XML 変更 - キャメルケース表記の属性: Mule 4 DSL ガイドラインに従い、一貫性を向上させるために、すべての DSL 属性はキャメルケースに変更されました。たとえば、​`max-failed-records`​ は ​`maxFailedRecords`​、​`accept-policy`​ は ​`acceptPolicy`​ のようになります。 - MuleSoft では、​`` ` ``​ 要素から ​`filter-expression`​ パラメーターを削除しました。この属性は Mule 3.6 で非推奨になったため、​`accept-expression`​ パラメーターに置き換える必要があります。 - ``​ は ​``​ と呼ばれるようになりました。 ## [](#関連情報)関連情報 - [バッチプロセッサー](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-processing-concept) # バッチモジュールの移行 バッチモジュールは Extract Transform Load (ETL) 機能を処理するために導入されました。 このセクションの内容 - [バッチ要素の移行](#batch_scope) - [Record Vars から Vars への移行](#record_var) - [非 Java データセットのサポート](#non_java_datasets) - [Mule 4 のバッチ要素および属性の XML 変更](#xml_changes) ## [](#batch_scope)バッチ要素の移行 Mule 3 では、バッチはフローと同じ最上位レベルの要素でした。Mule 4 の場合、​``​ 要素は、わかりやすく、動的な呼び出しや他の Mule コンポーネントとのやり取りがしやすいようにフローの内部に配置するスコープです。 これは ​``​ は使用されなくなることを意味します。​``​ の役割は、​``​ がトリガーされる前に、フロー内にある一連のプロセッサーによって果たされます。 - ``​: バッチはスコープですが名前が付いています。Mule アプリケーションでは、同じ名前の付いた 2 つの ​``​ 定義を使用することはできません。これにより、1 つのフローで複数のジョブが定義される場合の追跡と管理が向上します。 - ``​: この操作はなくなりました。代わりに、バッチジョブを含むフローを呼び出します。 Mule 3 の例 ```xml <> > ``` Mule 4 の例 ```xml ``` ## [](#record_var)Record Vars から Vars への移行 通常のフローとは異なり、バッチはメッセージレベルではなく、レコードレベルで処理を行います。 Mule 3 では、Mule メッセージにフロー変数 (​`flowVars`​) を使用するのと同様に、レコードレベル変数 (​`recordVars`​) を使用して変数を特定のレコードに添付します。 Mule 4 では ​`recordVars`​ が変数 (​`vars`​) に置き換わります。変数は Mule 4 の Mule イベントの一部です。​``​ 内から、​``​ の実行開始前に存在した変数を変更できます。これは他のレコードへの副作用がなく、特定の 1 つのレコードに対して行うことができます。 次の Mule 3 の例では、For Each コンポーネントの式内で ​`recordVars`​ が使用されています。 Mule 3 の例 ```xml record.payload = 'foo'; record.recordVars['marco'] = 'polo'; ``` 次の Mule 4 の例では、For Each コンポーネントの式内で ​`vars`​ が使用されています。 Mule 4 の例 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` ## [](#non_java_datasets)非 Java データセットのサポート Mule 3 では、バッチの入力フェーズは Java 構造であることが必要でした。そのため、XML 形式や JSON 形式などの入力データは、最初に Java に変換し、その変換では、DataWeave でストリーミングを使用してデータセットが大きい場合にメモリ不足にならないようにする必要がありました。 たとえば、HTTP コールでアプリケーションにプッシュされる次のようなソースデータがあるとします。 例: JSON 入力データ \[ { "name": "Luke Skywalker", "darkSide": true }, { "name": "Ben Solo", "darkSide": true }, { "name": "Obi-Wan Kenobi", "darkSide": false } \] Mule 3 では、この JSON を渡す前に Java に変更する必要がありました。次のようになります。 Mule 3 の例 ```xml <> <> ..... ``` Mule 4 では、バッチでペイロードが JSON 配列であることを自動的に判断し、単独で分割を実行できます。次に例を示します。 Mule 4 の例 ```xml .... ``` Mule 4 では、自動ストリーミングフレームワークが使用されているため、ストリーミングを設定する必要がなくなりました。したがって、Mule 4 に移行すると、変換ステップを回避できます。 ## [](#xml_changes)Mule 4 のバッチ要素および属性の XML 変更 - キャメルケース表記の属性: Mule 4 DSL ガイドラインに従い、一貫性を向上させるために、すべての DSL 属性はキャメルケースに変更されました。たとえば、​`max-failed-records`​ は ​`maxFailedRecords`​、​`accept-policy`​ は ​`acceptPolicy`​ のようになります。 - MuleSoft では、​`` ` ``​ 要素から ​`filter-expression`​ パラメーターを削除しました。この属性は Mule 3.6 で非推奨になったため、​`accept-expression`​ パラメーターに置き換える必要があります。 - ``​ は ​``​ と呼ばれるようになりました。 ## [](#関連情報)関連情報 - [バッチプロセッサー](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-processing-concept) # バッチモジュールの移行 バッチモジュールは Extract Transform Load (ETL) 機能を処理するために導入されました。 このセクションの内容 - [バッチ要素の移行](#batch_scope) - [Record Vars から Vars への移行](#record_var) - [非 Java データセットのサポート](#non_java_datasets) - [Mule 4 のバッチ要素および属性の XML 変更](#xml_changes) ## [](#batch_scope)バッチ要素の移行 Mule 3 では、バッチはフローと同じ最上位レベルの要素でした。Mule 4 の場合、​``​ 要素は、わかりやすく、動的な呼び出しや他の Mule コンポーネントとのやり取りがしやすいようにフローの内部に配置するスコープです。 これは ​``​ は使用されなくなることを意味します。​``​ の役割は、​``​ がトリガーされる前に、フロー内にある一連のプロセッサーによって果たされます。 - ``​: バッチはスコープですが名前が付いています。Mule アプリケーションでは、同じ名前の付いた 2 つの ​``​ 定義を使用することはできません。これにより、1 つのフローで複数のジョブが定義される場合の追跡と管理が向上します。 - ``​: この操作はなくなりました。代わりに、バッチジョブを含むフローを呼び出します。 Mule 3 の例 ```xml <> > ``` Mule 4 の例 ```xml ``` ## [](#record_var)Record Vars から Vars への移行 通常のフローとは異なり、バッチはメッセージレベルではなく、レコードレベルで処理を行います。 Mule 3 では、Mule メッセージにフロー変数 (​`flowVars`​) を使用するのと同様に、レコードレベル変数 (​`recordVars`​) を使用して変数を特定のレコードに添付します。 Mule 4 では ​`recordVars`​ が変数 (​`vars`​) に置き換わります。変数は Mule 4 の Mule イベントの一部です。​``​ 内から、​``​ の実行開始前に存在した変数を変更できます。これは他のレコードへの副作用がなく、特定の 1 つのレコードに対して行うことができます。 次の Mule 3 の例では、For Each コンポーネントの式内で ​`recordVars`​ が使用されています。 Mule 3 の例 ```xml record.payload = 'foo'; record.recordVars['marco'] = 'polo'; ``` 次の Mule 4 の例では、For Each コンポーネントの式内で ​`vars`​ が使用されています。 Mule 4 の例 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` ## [](#non_java_datasets)非 Java データセットのサポート Mule 3 では、バッチの入力フェーズは Java 構造であることが必要でした。そのため、XML 形式や JSON 形式などの入力データは、最初に Java に変換し、その変換では、DataWeave でストリーミングを使用してデータセットが大きい場合にメモリ不足にならないようにする必要がありました。 たとえば、HTTP コールでアプリケーションにプッシュされる次のようなソースデータがあるとします。 例: JSON 入力データ \[ { "name": "Luke Skywalker", "darkSide": true }, { "name": "Ben Solo", "darkSide": true }, { "name": "Obi-Wan Kenobi", "darkSide": false } \] Mule 3 では、この JSON を渡す前に Java に変更する必要がありました。次のようになります。 Mule 3 の例 ```xml <> <> ..... ``` Mule 4 では、バッチでペイロードが JSON 配列であることを自動的に判断し、単独で分割を実行できます。次に例を示します。 Mule 4 の例 ```xml .... ``` Mule 4 では、自動ストリーミングフレームワークが使用されているため、ストリーミングを設定する必要がなくなりました。したがって、Mule 4 に移行すると、変換ステップを回避できます。 ## [](#xml_changes)Mule 4 のバッチ要素および属性の XML 変更 - キャメルケース表記の属性: Mule 4 DSL ガイドラインに従い、一貫性を向上させるために、すべての DSL 属性はキャメルケースに変更されました。たとえば、​`max-failed-records`​ は ​`maxFailedRecords`​、​`accept-policy`​ は ​`acceptPolicy`​ のようになります。 - MuleSoft では、​`` ` ``​ 要素から ​`filter-expression`​ パラメーターを削除しました。この属性は Mule 3.6 で非推奨になったため、​`accept-expression`​ パラメーターに置き換える必要があります。 - ``​ は ​``​ と呼ばれるようになりました。 ## [](#関連情報)関連情報 - [バッチプロセッサー](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-processing-concept) # バッチモジュールの移行 バッチモジュールは Extract Transform Load (ETL) 機能を処理するために導入されました。 このセクションの内容 - [バッチ要素の移行](#batch_scope) - [Record Vars から Vars への移行](#record_var) - [非 Java データセットのサポート](#non_java_datasets) - [Mule 4 のバッチ要素および属性の XML 変更](#xml_changes) ## [](#batch_scope)バッチ要素の移行 Mule 3 では、バッチはフローと同じ最上位レベルの要素でした。Mule 4 の場合、​``​ 要素は、わかりやすく、動的な呼び出しや他の Mule コンポーネントとのやり取りがしやすいようにフローの内部に配置するスコープです。 これは ​``​ は使用されなくなることを意味します。​``​ の役割は、​``​ がトリガーされる前に、フロー内にある一連のプロセッサーによって果たされます。 - ``​: バッチはスコープですが名前が付いています。Mule アプリケーションでは、同じ名前の付いた 2 つの ​``​ 定義を使用することはできません。これにより、1 つのフローで複数のジョブが定義される場合の追跡と管理が向上します。 - ``​: この操作はなくなりました。代わりに、バッチジョブを含むフローを呼び出します。 Mule 3 の例 ```xml <> > ``` Mule 4 の例 ```xml ``` ## [](#record_var)Record Vars から Vars への移行 通常のフローとは異なり、バッチはメッセージレベルではなく、レコードレベルで処理を行います。 Mule 3 では、Mule メッセージにフロー変数 (​`flowVars`​) を使用するのと同様に、レコードレベル変数 (​`recordVars`​) を使用して変数を特定のレコードに添付します。 Mule 4 では ​`recordVars`​ が変数 (​`vars`​) に置き換わります。変数は Mule 4 の Mule イベントの一部です。​``​ 内から、​``​ の実行開始前に存在した変数を変更できます。これは他のレコードへの副作用がなく、特定の 1 つのレコードに対して行うことができます。 次の Mule 3 の例では、For Each コンポーネントの式内で ​`recordVars`​ が使用されています。 Mule 3 の例 ```xml record.payload = 'foo'; record.recordVars['marco'] = 'polo'; ``` 次の Mule 4 の例では、For Each コンポーネントの式内で ​`vars`​ が使用されています。 Mule 4 の例 ```xml vars['marco'] = 'polo' vars['record'].payload = 'foo' ``` ## [](#non_java_datasets)非 Java データセットのサポート Mule 3 では、バッチの入力フェーズは Java 構造であることが必要でした。そのため、XML 形式や JSON 形式などの入力データは、最初に Java に変換し、その変換では、DataWeave でストリーミングを使用してデータセットが大きい場合にメモリ不足にならないようにする必要がありました。 たとえば、HTTP コールでアプリケーションにプッシュされる次のようなソースデータがあるとします。 例: JSON 入力データ \[ { "name": "Luke Skywalker", "darkSide": true }, { "name": "Ben Solo", "darkSide": true }, { "name": "Obi-Wan Kenobi", "darkSide": false } \] Mule 3 では、この JSON を渡す前に Java に変更する必要がありました。次のようになります。 Mule 3 の例 ```xml <> <> ..... ``` Mule 4 では、バッチでペイロードが JSON 配列であることを自動的に判断し、単独で分割を実行できます。次に例を示します。 Mule 4 の例 ```xml .... ``` Mule 4 では、自動ストリーミングフレームワークが使用されているため、ストリーミングを設定する必要がなくなりました。したがって、Mule 4 に移行すると、変換ステップを回避できます。 ## [](#xml_changes)Mule 4 のバッチ要素および属性の XML 変更 - キャメルケース表記の属性: Mule 4 DSL ガイドラインに従い、一貫性を向上させるために、すべての DSL 属性はキャメルケースに変更されました。たとえば、​`max-failed-records`​ は ​`maxFailedRecords`​、​`accept-policy`​ は ​`acceptPolicy`​ のようになります。 - MuleSoft では、​`` ` ``​ 要素から ​`filter-expression`​ パラメーターを削除しました。この属性は Mule 3.6 で非推奨になったため、​`accept-expression`​ パラメーターに置き換える必要があります。 - ``​ は ​``​ と呼ばれるようになりました。 ## [](#関連情報)関連情報 - [バッチプロセッサー](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-processing-concept) # バッチ処理
バッチ処理は Mule Enterprise ランタイム専用です。
Mule では、メッセージをバッチで処理できます。 アプリケーション内で Batch Job スコープを開始できます。これによって、メッセージが個々のレコードに分割され、各レコードに対してアクションが実行され、その結果が報告され、場合によっては処理された出力が他のシステムまたはキューに転送されます。 たとえば、次の場合にバッチ処理を使用できます。 - NetSuite と Salesforce 間の連絡先の同期など、ビジネスアプリケーション間でデータセットを同期する。 - フラットファイル (CSV) から Hadoop へのデータのアップロードなど、対象システムへの情報の抽出、変換、および読み込み (ETL) を行う。 - API から従来のシステムへの大量の受信データを処理する。 Mule 3.x のバッチ処理にすでに精通している場合は、記事​[「バッチモジュールの移行」](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-core-batch)​で Mule 4.x のバッチとの違いの概要を確認してください。 ## [](#概要)概要 Mule アプリケーション内では、バッチ処理は、個々のレコードに分割される、メモリ量を上回るデータセットを非同期で処理するための構造を提供します。Batch Job を使用すると、ソースデータを自動的に分割して永続的なキューに保存する信頼できるプロセスを記述できるため、大量のデータセットを処理しながら信頼性を提供できます。アプリケーションを再デプロイする場合、または Mule がクラッシュした場合、ジョブが停止した位置でジョブの実行を再開できます。 ![batch main3](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/batch-main3.png) これで、個々のレコードの処理の観点でジョブが表わされるため、レコードレベルの変数、集約、およびエラー処理のセマンティクスが提供されます。 ## [](#基本的なアーキテクチャ)基本的なアーキテクチャ Mule のバッチ処理の中心は Batch Job です。Batch Job は、大きなメッセージを Mule が非同期で処理するレコードに分割するスコープです。フローがメッセージを処理する方法と同様に、Batch Job はレコードを処理します。 ![batch processing concept d1bdd](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/batch-processing-concept-d1bdd.png) バッチ XML 構造は Mule 4.0 で変更されました。次の例は、バッチ要素を強調表示するため省略された詳細を示しています。 ```xml ``` Batch Job には、レコードが Batch Job 内を移動するときにレコードに対して実行する 1 つ以上の Batch Step が含まれます。 Batch Job の各 Batch Step には、レコードに対してその中に含まれるデータを変換、転送、強化、または別の方法で処理するプロセッサーが含まれます。既存の Mule プロセッサーの機能を利用することで、Batch Job がレコードを処理する方法を Batch Step で柔軟に制御できます。詳細は、​[「Batch Step 処理の絞り込み」](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-filters-and-batch-aggregator)​を参照してください。 フローが Batch Job の process-records セクションに到達すると、その Batch Job が実行されます。トリガーされると、Mule は新しい Batch Job インスタンスを作成します。 ジョブインスタンスが実行可能になると、バッチエンジンは各レコードブロックのタスクを I/O プールに送信して各レコードを処理します。並列処理はレコードブロックレベルで自動的に行われます。Mule Runtime Engine では、自動調整機能によって、使用するスレッド数と適用する並列性レベルが決定されます (​[「実行エンジン」](https://docs.mulesoft.com/jp/mule-runtime/4.3/execution-engine)​参照)。 Batch Job の実行が開始されると、Mule は受信メッセージをレコードに分割して永続的なキューに保存し、処理するレコードのブロックでそれらのレコードのクエリとスケジュールを実行します。デフォルトでは、ランタイムは各 Batch Step に 100 件のレコードを保存します。必要なパフォーマンスに応じて、このサイズをカスタマイズできます。詳細は、​[「Batch Step 処理の絞り込み」](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-filters-and-batch-aggregator)​を参照してください。 すべてのレコードがすべての Batch Step を通過したら、ランタイムは Batch Job インスタンスを終了し、処理中に成功したレコードと失敗したレコードを示す Batch Job の結果を報告します。 ### [](#mule-メッセージ分割プロセス)Mule メッセージ分割プロセス Batch Job では、Mule メッセージで、Java イテラブル、Java イテレーター、Java 配列のほか、JSON ペイロードと XML ペイロードを認識する暗黙的な分割操作が実行されます。Batch Job では他のデータ形式を分割できません。分割プロセスとの互換性がないデータ形式を使用する場合は、Batch Job に入る前にペイロードをサポートされる形式に変換してください。 ### [](#エラー処理)エラー処理 Batch Job は、Batch Job 全体の失敗を回避するため、処理中に発生する可能性があるレコードレベルの失敗を処理できます。また、バッチ処理中に Mule が変数 (上記で割り当て済み) に従って Batch Job 内のレコードの転送またはアクションを実行できるように、個々のレコードの変数を設定または削除できます。詳細は、​[「Batch Job 中のエラー処理」](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-error-handling-faq)​を参照してください。 ### [](#batch-job-と-batch-job-インスタンスの比較)Batch Job と Batch Job インスタンスの比較 上記のコンテキストで定義されていますが、​_Batch Job_​ と ​_Batch Job インスタンス_​という用語は相互に関連するため、詳しく説明します。 - Batch Job は、Mule がメッセージペイロードをレコードのバッチとして処理する、アプリケーションのスコープ要素です。Batch Job という用語は、Load and Dispatch (読み込みおよびディスパッチ)、Process (プロセス)、On Complete (完了時) の 3 つの処理フェーズすべてを含みます。 - Batch Job インスタンスは、Mule フローが Batch Job を実行するたびに Mule アプリケーションで発生します。Mule は Load and Dispatch (読み込みおよびディスパッチ) フェーズで Batch Job インスタンスを作成します。すべての Batch Job インスタンスは、Batch ​_Job インスタンス ID_​ と呼ばれる一意の文字列を使用して内部的に識別されます。 この識別子は、たとえばデータを参照および管理するためにローカルジョブインスタンス ID を外部システムに渡したり、ジョブのカスタムログを改善したり、特定の Batch Job インスタンスに関する重要なイベントのメールまたは SMS 通知を送信したりする場合に役立ちます。この識別子とそのカスタマイズ方法についての詳細は、​[「Batch Job インスタンス ID」](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-job-instance-id)​を参照してください。 ## [](#batch-job-処理フェーズ)Batch Job 処理フェーズ 各 Batch Job には 3 つの異なるフェーズがあります。 1. Load and Dispatch (読み込みおよびディスパッチ)。 2. Process (プロセス)。 3. On Complete (完了時)。 ### [](#load-and-dispatch-読み込みおよびディスパッチ)Load and Dispatch (読み込みおよびディスパッチ) この最初のフェーズは暗黙的です。このフェーズでは、ランタイムはすべてのバックグラウンド処理を実行して Batch Job インスタンスを作成します。基本的に、これは Mule がバッチとして処理するためにシリアル化されたメッセージペイロードをレコードのコレクションに変換するフェーズです。このアクティビティが発生するために何も設定する必要はありませんが、Mule がこのフェーズ中に完了するタスクを理解しておくと役立ちます。 1. Mule は DataWeave を使用してメッセージを分割します。この最初の手順では、新しい ​_Batch Job インスタンス_​が作成されます。 Mule は ​`batchJobInstanceId`​ 変数を使用して Batch Job インスタンス ID を公開します。この変数はすべてのステップと on-complete フェーズで使用可能です。 2. Mule は永続的なキューを作成して新しい Batch Job インスタンスに関連付けます。 キュー名には ​`BSQ`​ のプレフィックスが付けられ、それを Anypoint Runtime Manager で確認できます。 ![Batch Step キュートランザクションログ](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-batch-bsq.png) 3. スプリッターによって生成された各アイテムに対して、Mule はレコードを作成してキューに保存します。このアクティビティは「オールオアナッシング」です。つまり、Mule がすべての項目のレコードを正常に生成してキューに追加するか、このフェーズ中にメッセージ全体が失敗します。 4. Mule は Batch Job のインスタンスとキュー内のすべてのレコードを処理用の最初の Batch Step に渡します。 このフェーズが完了したら、フローは Batch Job がすべてのレコードの処理を完了するのを待たずに実行を続行します。この動作は、次のフェーズである ​_Process (プロセス)_​ が非同期なために発生します。 ### [](#process-プロセス)Process (プロセス) _Process (プロセス)_​ フェーズ中、Mule はステッピングキューからのレコードの取り込みを開始し、設定済みバッチブロックサイズのレコードブロックを作成します。その後、対応する Batch Step にレコードブロックを送信して非同期で処理します。各 Batch Step で複数のレコードブロックの並列処理が開始されますが、各ブロック内のレコードは順次処理されます。Batch Step でブロック内のすべてのレコードが処理されると、それらのレコードはステッピングキューに送信されます。ステッピングキューでは、レコードは次の Batch Step で処理されるまで待機します (各レコードで、完了したステップが追跡されます)。すべてのレコードが Batch Job インスタンスのすべての Batch Step を通過するまで、このプロセスが続行されます。 ![バッチ + 図](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/batch-diagram.jpg) Batch Job インスタンスは、キューに追加されたすべてのレコードが 1 つの Batch Step での処理を終了するのを待たずに、レコードを次の Batch Step に転送します。ただし、アグリゲーターを設定した場合、アグリゲーターの設定に応じて、レコードを処理している間の Batch Job Step の動作が変わります。 - アグリゲーターが固定サイズで設定されている場合の動作 このシナリオでは、Batch Step で処理済みのレコードをアグリゲーターに送信し、アグリゲーターでは、レコードを処理し、アグリゲーターの設定済みサイズに達するまでレコードをバッファ処理します。設定済みサイズに達したら、アグリゲーターは集約したレコードをステッピングキューに送信します。 ![固定サイズのアグリゲーターを使用する Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-batch-job-process-aggregator-fixed.png)
1Batch Job で設定済みブロックサイズのレコードブロックを作成し、対応する Batch Step に送信して処理します。
2各 Batch Step で 1 つ以上のレコードブロックを受信し、レコードブロックの並列処理を開始します。
3Batch Step でレコードを処理したら、レコードをアグリゲーターに送信してさらに処理を行います。
4アグリゲーターでは、集約したレコードの数がアグリゲーターの設定済みサイズに達するまでレコードの処理を続行します。
5アグリゲーターは集約したすべてのレコードをステッピングキューに送信します。
- ストリーミング用にアグリゲーターが設定されている場合の動作 このシナリオでは、Batch Step で処理済みのレコードをアグリゲーターに送信し、アグリゲーターでは、現在の Batch Step からのすべてのレコードが処理され、集約されるまでレコードの処理を継続します。 ![ストリーミング用にアグリゲーターが設定されている場合の Batch Job プロセス](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-batch-job-process-aggregator-streaming.png)
1Batch Job で設定済みブロックサイズのレコードブロックを作成し、対応する Batch Step に送信して処理します。
2各 Batch Step で 1 つ以上のレコードブロックを受信し、レコードブロックの並列処理を開始します。
3Batch Step でレコードを処理したら、レコードをアグリゲーターに送信してさらに処理を行います。
4アグリゲーターでは、現在の Batch Step による処理を待機している、ステッピングキュー内のレコードがなくなるまでレコードの処理を継続します。
5アグリゲーターは集約したすべてのレコードをステッピングキューに送信します。
Mule は、各 Batch Step での処理に成功または失敗したすべてのレコードのリストを保持しています。Batch Step のイベントプロセッサーでレコードの処理に失敗した場合、Mule はバッチの処理を続行し、後続の各 Batch Step では失敗したレコードをスキップします。 このフェーズの終了時に Batch Job インスタンスは完了し、消滅します。 #### [](#batch-step-処理の絞り込み)Batch Step 処理の絞り込み レコードの単純な処理以外に、Batch Step 内でレコードを使用してできることがいくつかあります。 - 各 Batch Step 内に acceptExpressions を追加して検索条件を追加し、ステップが特定のレコードを処理しないようにする。 たとえば、先行するステップで処理に失敗したレコードがステップで処理されないようにする検索条件を設定できます。 - Batch Aggregator プロセッサーを使用して、レコードをグループに集約し、それらを一括更新/挿入で外部ソースまたはサービスに送信可能。 たとえば、各連絡先 (レコード) を Google コンタクトにバッチで更新/挿入する代わりに、100 件のレコードを蓄積するようにバッチアグリゲーターを設定して、そのすべてを 1 つのチャンクで Google コンタクトに更新/挿入できます。 詳細は、​[「Batch Step 処理の絞り込み」](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-filters-and-batch-aggregator)​を参照してください。 ### [](#on-complete-完了時)On Complete (完了時) このフェーズ中、必要に応じて、特定の Batch Job インスタンスで処理したレコードのレポートまたは概要を作成するようにランタイムを設定できます。このフェーズは、入力データに存在する可能性がある問題に対処できなかったレコードに関するインサイトをシステム管理者と開発者に提供するために存在します。 ```xml ``` Mule が Batch Job 全体を実行したら、出力は Batch Job 結果オブジェクト (​`BatchJobResult`​) になります。Mule は Batch Job を非同期の一方向フローとして処理するため、バッチ処理の結果は、そのトリガー元のフローに戻されることも、呼び出し元への応答として返されることもありません。データを Batch Job に送り込むイベントソースは、要求 - 応答ではなく一方向である必要があります。 出力を操作する方法は 2 つあります。 - On Complete (完了時) フェーズで、失敗したレコード数や正常に処理されたレコード数などの情報を使用する DataWeave を使用して、エラーが発生した可能性があるステップに関するレポートを作成する。 - Mule アプリケーションの他の場所にある Batch Job 結果オブジェクトを参照し、特定の Batch Job インスタンスで処理に失敗したレコード数などのバッチメタデータを取得および使用する。 On Complete (完了時) フェーズを空のままにし、アプリケーションの他の場所で Batch Job 結果オブジェクトを参照しない場合は、失敗したか成功したかに関係なく、Batch Job は単に完了します。

失敗または成功したレコードについて報告するための何らかのメカニズムを設定し、必要な場合は追加アクションの実行を促すことをお勧めします。
### [](#変数の伝播)変数の伝播 Batch Job インスタンスの各処理済みレコードは、ブロックの実行前に提供された変数と値で開始されます。各レコードには独自の一連の変数があるため、特定のレコードの処理中の新しい変数またはすでに存在している変数の変更は、別のレコードの処理中に表示されません。それらの変数 (および変更) は、レコードごとに異なる Batch Step で伝播されます。たとえば、レコード R1 で変数 ​`varName: "hello"`​ を設定し、レコード R2 で ​`varName: "world"`​ を設定して、レコード R3 でこの変数を設定しない場合、次のステップで R1 には値 ​`"hello"`​ が表示され、R2 には ​`"world"`​ が表示されて、R3 にはその変数の値が表示されません。 On Complete フェーズでは、これらのどの変数 (元の変数も含む) も表示されません。このフェーズでは、最終結果のみを使用できます。さらに、Batch Job インスタンスは、フローの残りの部分から非同期で実行されるため、Batch Step または On Complete フェーズで設定された変数は、Batch スコープ外で表示されません。 ### [](#scheduling-strategy-スケジュール戦略)Scheduling Strategy (スケジュール戦略) Mule アプリケーションには、複数の Batch Job 定義を含めることができます。各定義には固有のスケジュール戦略が設定されます。​**スケジュール戦略**​を使用すると、特定の Batch Job のインスタンスの実行方法を制御できます。 - `ORDERED_SQUENTIAL`​ (デフォルト): 複数のジョブインスタンスが同時に実行可能状態になっている場合、インスタンスは作成タイムスタンプに基づいて 1 つずつ実行されます。 - `ROUND_ROBIN`​: この設定では、使用可能なリソースをラウンドロビンアルゴリズムを使用して割り当てて、Batch Job の実行可能なすべてのインスタンスを実行しようとします。 他のジョブ実行に副次的影響を及ぼすジョブ実行がないと保証できる場合は、​`ROUND_ROBIN`​ オプションが役立ちます。データ同期ジョブの場合、同時に実行される 2 つのジョブによって同じレコードが更新される可能性があるため、このオプションは適していません。ジョブ実行の順序が保証されないため、結果は以前のバージョンのデータになる可能性があります。ただし、Batch Job によってデータベースから新しいレコードのみを取得したり、SFTP サーバーから個別ファイルを取得したりするときに、すべてのレコードが完全に独立していることが確信できる場合は、この戦略を安全に使用してジョブの実行を並列化することができます。 これらのいずれの戦略でも、レコードが順番に処理されることは保証されません。 戦略は Batch Job でのレコードの実行順序は制御せず、各インスタンスに含まれるレコード数によって決まることもありません。 ## [](#関連情報)関連情報 - [Batch Step 処理の絞り込み](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-filters-and-batch-aggregator) - [バッチ要素の移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-core-batch) - [トランザクションによるスコープとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management#tx_scopes_routers) # バッチ処理 Mule Runtime Engine (Mule) では、メッセージをバッチ処理できます。バッチジョブは、アプリケーション内で開始できます。これは、大きなメッセージを個々のレコードに分割し、各レコードに対してアクションを実行してから、結果を報告し、場合によっては処理された出力を他のシステムまたはキューに転送するコードブロックです。 100 万件のレコードであっても、バッチアプリケーションなら 3 つのステップで処理できるのです。Mule ジョブのフェーズを移動しながら各レコードを処理している間には、いくつかの I/O 操作が発生します。バッチジョブのパフォーマンスは、ディスクの特性とワークロードのサイズに大きく左右されます。特に入力フェーズでは、ディスク上にキューが作成され、処理するレコードが登録されます。このキューはフローによって継続的に読み書きされるため、I/O 負荷が大きくなります。 さらにバッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 ## [](#batch-block-size-バッチブロックサイズ)Batch Block Size (バッチブロックサイズ) デフォルトでは、バッチブロックサイズは 100 に設定されています。さまざまなレコードサイズで代表的なバッチのユースケースを分析した結果、このサイズが最もパフォーマンスとワーキングメモリ要件のバランスが取れていることが判明しています。ただし、各アプリケーションの最適な値は、ユースケースによって異なります。 このプロパティは、バッチジョブごとに設定できます。特定のユースケースでカスタムサイズが最適であると思われる場合は、いろいろなサイズで比較テストを実行して、ユースケースに最適なサイズを見つけてください。次の例にバッチブロックサイズを示します。 ```xml ``` ## [](#max-concurrency-最大同時実行)Max Concurrency (最大同時実行) Batch スコープ内の処理に使用されるスレッドの最大数は、デフォルトで JVM で検出されるコア数の 2 倍になります。CloudHub や Anypoint Runtime Fabric のような断片的コアデプロイメントの場合、JVM では​_非断片的_​コア数が検出されます。自動設定された同時実行設定を手動で増減できます。Max Concurrency (最大同時実行) 設定には、それを上回るスレッドを保証するにはレコード数が足りない場合などに、バッチジョブインスタンスに使用するスレッドの上限数を設定できます。 次の例では、自動設定された ​`maxConcurrency`​ (デフォルトでプロパティから読み込まれた設定になる) を上書きします。 ```xml ``` ## [](#batch-aggregator)Batch Aggregator スレッドが 1 つか複数かに関係なく、100 万回ネットワークを往復すればネットワークに影響を与えます。SaaS システムとの通信ではすぐに API コールのクォータがコンシュームされることがあります。レコードを 1 件ずつ処理するのではなく、Batch Aggregator スコープを使用し、レコードの配列に対して一括操作を実行することでパフォーマンスを改善できます。このスコープではアグリゲーターのサイズ設定を使用して各配列のレコード数を制限します。 1 つのレコード配列で処理するレコード数を決定するときには、通信に使用するシステムの操作で許可される最大レコード数を考慮する必要があります。アグリゲーターのサイズ設定と​_それより小さい値_​でパフォーマンステストを実施することが重要です。ロジックは設定値以下のどのレコード数でも処理する必要があります。システムが受信するレコードの数が指定値よりも少ない可能性があるからです。たとえば、120 レコードがあり、アグリゲーターのサイズ設定が 50 の場合、最後の送信は 20 レコードになります。 次の例は、Batch Aggregator スコープが固定サイズの ​`50`​ に設定された Batch Step スコープを示します。 ```xml ``` アグリゲーターにデータのストリーミング操作が含まれる場合、アグリゲーターのサイズ設定 (​`streaming="true"`​) を使用する代わりにスコープのストリーミングオプション (​`size="50"`​) をアクティブ化できます。 ## [](#batch-job-の複数同時インスタンス)Batch Job の複数同時インスタンス Batch Job スコープの多くのユースケースでは一度に 1 つの要求 (バッチジョブインスタンス) のみを処理しますが、同時に複数のバッチジョブインスタンスを実行するケースもあります。そうしたケースのスレッドプール共有をチューニングするために、次のいずれかのスケジュール戦略を設定できます。各戦略はバッチインスタンス ID で別個に追跡されます。 - `ORDERED_SEQUENTIAL`​: インスタンスをトリガーされた順に処理することで同時インスタンスの影響を制限するデフォルトのスケジュール戦略。この戦略は、同じバッチジョブを順不同で処理するとデータの不整合などの問題が発生したり、リソース制限に達したりする可能性がある場合に便利です。 - `ROUND_ROBIN`​: スレッドを「インフライト」のバッチジョブインスタンスと共有するスケジュール戦略です。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.3/batch-processing-concept) # バッチ処理 Mule バッチ処理コンポーネントは、メモリ量を上回るデータセットの信頼できる非同期処理を行うよう設計されています。コンポーネントには Batch Job、Batch Step、Batch Aggregator があります。Batch Job コンポーネントではソースデータを自動的に分割して永続的なキューに格納するため、大量のデータセットを処理しながら信頼性を提供できます。アプリケーションを再デプロイする場合、または Mule がクラッシュした場合、ジョブが停止した位置でジョブの実行を再開できます。

Mule バッチ処理コンポーネントは Mule の Enterprise Edition (EE) バージョン専用です。オープンソースの Mule Kernel を通じてコンポーネントを使用することはできません。

Mule 3.x でのバッチ処理に慣れている場合は、Mule 4.x でのバッチ処理の違いの概要について​「Batch Module の移行」​を参照してください。
バッチ処理の一般的なユースケースを次に挙げます。 - NetSuite と Salesforce 間の連絡先の同期など、ビジネスアプリケーション間でデータセットを同期する。 - フラットファイル (CSV) から Hadoop へのデータのアップロードなど、対象システムへの情報の抽出、変換、および読み込み (ETL) を行う。 - API から従来のシステムへの大量の受信データを処理する。 例については ​[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-filters-and-batch-aggregator) and [Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-error-handling-faq)​ を参照してください。 ## [](#アーキテクチャ)アーキテクチャ Mule バッチ処理コンポーネントでは、レコードを一括で処理できるように準備し、これらのレコードでプロセッサーを実行して、処理の結果に関するレポートを発行します。レコードの準備とレポートは Batch Job コンポーネント内で行われます。処理は 1 つ以上の Batch Step コンポーネント内で行われ、必要に応じて、Batch Step コンポーネント内の Batch Aggregator コンポーネント内で行われます。 ![バッチコンポーネントとプロセッサーが含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-batch-job-overview.png) バッチ処理コンポーネント内に配置したプロセッサーはレコードに対するアクションを実行します。各レコードは Mule イベントに似ています。プロセッサーは ​`payload`​ キーワードを使用して各レコードのペイロードへのアクセス、変更、ルーティングを行うことができ、​`vars`​ を使用して Mule 変数を操作できます。ただし、Batch Job コンポーネントへの入力から Mule 属性 (​`attributes`​) へのアクセスや変更を行うことは​_できません_​。 次の例は、バッチ処理を実行し、その処理の結果が記載されたレポートを返す Mule フローの XML 構造の概要を示しています。 ```xml (1) (2) (3) (4) (5) (6) (7) (8) ``` 例に含まれる ​``​ などのさまざまな ​`placeholder`​ エントリはコネクタ操作、Mule コアコンポーネントなど、Mule メッセージ、レコード、バッチ処理レポートを処理する実際のプロセッサーの場所を示している点に注意してください。これらは​_実際のプロセッサーではありません_​。 1. Mule イベントソースにより Mule フローがトリガーされます。一般的なイベントソースには HTTP 用 Anypoint Connector (HTTP Connector)、Scheduler コンポーネント、新しいファイルをポーリングするコネクタ操作からの HTTP リスナーなどのリスナーがあります。 2. Batch Job コンポーネントのアップストリームに配置されたプロセッサーは通常コンシュームする Batch Job コンポーネントメッセージを取得し、必要に応じてこのメッセージを準備します。たとえば、HTTP 要求操作では処理するデータを取得する場合があり、Transform Message コンポーネントの DataWeave スクリプトではデータを受信する Batch Job コンポーネントにとって​[有効な形式](#valid_input)​に変換する場合があります。 3. Batch Job コンポーネントでフローのアップストリームプロセッサーからメッセージを受信すると、​[Load and Dispatch フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases#phase_load_dispatch)​が開始されます。このフェーズでは、コンポーネントでレコードとして処理するための入力が準備されます。これには処理が行われる Batch Job インスタンスの作成などがあります。 4. Batch Job インスタンスは、Batch Job インスタンスが ​``​ に達した時点で実行されます。この時点で、​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases#phase_process)​が開始されます。すべてのレコード処理はこのフェーズ中に行われます。 5. 各 Batch Step コンポーネントには、レコードに対してその中に含まれるデータを変換、転送、強化、または変更する 1 つ以上のプロセッサーが含まれます。たとえば、処理したレコードを 1 つずつ外部サーバーに渡すようにコネクタ操作を設定する場合があります。 6. Batch Aggregator コンポーネントは省略可能です。Batch Step コンポーネントに追加できるのは 1 つのみです。Batch Aggregator 内の最初のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。バッチ集計は処理したレコードの配列を外部サーバーに読み込む場合に便利です。他のプロセッサーでレコードを 1 つずつ処理できるように、For Each など、配列に対して反復処理を行うコンポーネントを使用することもできます。Batch Aggregator コンポーネントには、レコードの処理方法を示す ​[`streaming`​ または ​`size`](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-reference#ref_batch_aggregator_component)​ 設定が必要です。 7. 追加の Batch Step コンポーネントは省略可能です。この例には、Batch Aggregator コンポーネントは含まれません。 8. レコードがすべての Batch Step コンポーネントを通過したら、Mule で Batch Job インスタンスが完了され、処理中に成功したレコードと失敗したレコードを示す結果がオブジェクトで報告されます。​``​ 内の Logger などのプロセッサーを使用して結果を取得または記録できます。 Batch Job コンポーネントではレコードが ​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases#phase_on_complete)​でコンシュームされます。このフェーズは Batch Job インスタンスのすべてのレコード処理が完了した後に発生し、処理したレコードは Batch Job コンポーネントの外側の外部コンポーネントに伝播されません。ただし、多くの Mule コンポーネントと同じように、Batch Job コンポーネントにより、Batch Job の外側のダウンストリームコンポーネントで Batch Job コンポーネントが受け取る​_事前に処理されたペイロード_​にアクセスするために使用する​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-reference#ref_batch_job_component)​ (​`target`​) プロパティを設定できます。 詳細は、[Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases)を参照してください。 ## [](#valid_input)Batch Job コンポーネントに対する有効な入力 フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Mule メッセージ入力に対する暗黙的な分割操作が実行されます。この操作では、Java イテラブル、イテレーター、配列のほか、JSON ペイロードと XML ペイロードを受け入れます。このコンポーネントでは他のデータ形式を分割できません。 分割プロセスとの互換性がないデータ形式を使用する場合は、Batch Job コンポーネントに入る前にペイロードをサポートされる形式に変換してください。 ## [](#variable_propagation)Mule 変数の伝播 Batch Job インスタンスの各レコードは、Batch Job コンポーネントへの入力から Mule イベント変数を継承します。これらの変数の値は Process フェーズ中に実行される Batch Step コンポーネントおよび Batch Aggregator コンポーネントでアクセスして変更でき、これらのコンポーネント内で新しい変数を作成できます。このフェーズ内の各レコードについて、変数 (およびこれらの変数に対する変更) は Batch Job コンポーネント内の各 Batch Step コンポーネントおよび Aggregator コンポーネントを通じて伝播されます。たとえば、レコード R1 で Mule 変数 ​`varName`​ を ​`"hello"`​ に設定し、レコード R2 で ​`varName`​ を ​`"world"`​ に設定して、レコード R3 でこの変数を設定しない場合、次の Batch Step コンポーネント R1 には値 ​`"hello"`​ が表示され、R2 には値 ​`"world"`​ が表示されて、R3 はその変数について ​`null`​ を返します。 似たようなシナリオで、​`varName`​ が Batch Job コンポーネントの​_前_​のフローで設定され、レコード 3 (R3) で ​`varName`​ の値が変更されない場合、R3 はその値を継承します。この点について説明するために、Mule フローが Batch Job コンポーネントに配列 ​`[1,2,3,4]`​ の ​`payload`​ および値が ​`"my variable before batch job"`​ の Mule 変数 ​`varName`​ を送信するとします。次の例では、Choice ルーター (​`choice`​) を使用して最初と 2 番目のレコードで ​`varName`​ の新しい値を設定していますが、3 番目のレコードでは設定していません。後続のレコードでも新しい ​`varName`​ 値を設定しています。 ```xml ``` ログでは Batch Job インスタンスの次のメッセージが出力されます (読みやすいように編集済み)。 ```logs ... INFO ...PRINT VARIABLE BEFORE BATCH: "my variable before batch job" ... INFO ...PRINT VARIABLE VALUES AFTER BATCH JOB: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 1 INFO ...R1: PRINT VARIABLE for PAYLOAD is 1: "hello" INFO ...PRINT RECORD NUMBER: 2 INFO ...R2: PRINT VARIABLE for PAYLOAD is 2: "world" INFO ...PRINT RECORD NUMBER: 3 INFO ...R3: PRINT VARIABLE for PAYLOAD is 3: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 4 INFO ...Rn: PRINT DEFAULT VARIABLE: "some other value" ... INFO ...PRINT VARIABLES IN SECOND STEP: {payload 1="hello"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 2="world"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 3="my variable before batch job"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 4="some other value"} ... ``` 3 番目のレコード (R3) が Batch Job コンポーネントの前で設定された ​`varName`​ の値を継承している点に注意してください。R3 より後のレコードでは変数を ​`"some other value"`​ に設定しています。2 番目の Batch Step に記録されたレコードは最初の Batch Step から変数の値を継承しています。Batch Job インスタンスが処理を完了する​_前_​に非同期で処理される Batch Job コンポーネントの​_後_​の Logger は、Batch Job が実行される​_前_​の ​`varName`​ の値である ​`"my variable before batch job"`​ も受け取ります。 [Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases#phase_process)​中に Mule 変数を変更または追加しても、​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases#phase_on_complete)​には伝播されません。Batch Job コンポーネントへのトリガーイベントから継承された変数のみが On Complete フェーズに伝播され、​`batchJobInstanceId`​ など、Batch Job レポートに含まれる標準変数はこのフェーズでも表示されます。On Complete フェーズでは、このフェーズの最後までは保持されるが On Complete が終了した後は保持されない変数を作成できます。 たとえば、On Complete フェーズで新しい変数 (​`myOnCompleteVar`​) を設定し、このフェーズで見つかったすべての変数 (​`vars`​) を記録するとします。 ```xml ``` On Complete レポートには、たとえば次のように Batch Job インスタンスで最終的に設定される変数が表示されます。 INFO ... PRINT ON COMPLETE VARIABLES: { varName=TypedValue\[value: '"my variable before batch job"', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\], batchJobInstanceId=TypedValue\[value: '869ae510-5c84-11ed-bc38-147ddaaf4f97', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*'}'\], myOnCompleteVar=TypedValue\[value: 'Hello On Complete Variable', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\]} レポートオブジェクトの変数の例は以下に従います。 - `varName`​ は Batch Job コンポーネントに達する前に作成された変数の例です。この変数には、コンポーネントに入ったときの値が保持されます。Process フェーズ中に値を変更しても、On Complete フェーズでは保持されません。 - `batchJobInstanceId`​ は Batch Job インスタンスを識別する標準変数です。 - `myOnCompleteVar`​ は On Complete フェーズ内で作成された変数の例です。レポートには表示されますが、On Complete フェーズの終了後は保持されません。 Batch Job コンポーネントからのダウンロードストリームでは、​`varName`​ のみが保持されます。レコードやその属性と同じように、レコードの変数は Batch Job コンポーネント内で完全にコンシュームされます。Batch Job インスタンスはフローの残りの部分から非同期で実行されるため、Process フェーズまたは On Complete フェーズ内で作成された変数は Batch Job コンポーネント外で保持されません。 ## [](#エラー処理)エラー処理 Batch Job 全体の失敗を防止するために、Batch Job コンポーネントではレコードレベルで発生する失敗を処理できます。また、バッチ処理中に Mule が変数に従って Batch Job インスタンス内のレコードの転送またはアクションを実行できるように、個々のレコードの変数を設定または削除できます。詳細は、​[「Batch Job 中のエラー処理」](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-error-handling-faq)​を参照してください。 ## [](#関連情報)関連情報 - [Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-phases) - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-filters-and-batch-aggregator) - [バッチ処理の調整](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-batch-processing) - [トランザクションによるコンポーネントとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management#tx_components_routers) - [バッチモジュールの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-core-batch) - [バッチジョブが含まれるアプリケーションの永続的なキュー](https://docs.mulesoft.com/cloudhub/cloudhub-fabric#persistent-queues-for-applications-containing-batch-jobs.adoc) # バッチ処理 Mule Runtime Engine (Mule) では、メッセージをバッチ処理できます。バッチジョブは、アプリケーション内で開始できます。これは、大きなメッセージを個々のレコードに分割し、各レコードに対してアクションを実行してから、結果を報告し、場合によっては処理された出力を他のシステムまたはキューに転送するコードブロックです。 100 万件のレコードであっても、バッチアプリケーションなら 3 つのステップで処理できるのです。Mule ジョブのフェーズを移動しながら各レコードを処理している間には、いくつかの I/O 操作が発生します。バッチジョブのパフォーマンスは、ディスクの特性とワークロードのサイズに大きく左右されます。特に入力フェーズでは、ディスク上にキューが作成され、処理するレコードが登録されます。このキューはフローによって継続的に読み書きされるため、I/O 負荷が大きくなります。 さらにバッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 ## [](#batch-block-size-バッチブロックサイズ)Batch Block Size (バッチブロックサイズ) デフォルトでは、バッチブロックサイズは 100 に設定されています。さまざまなレコードサイズで代表的なバッチのユースケースを分析した結果、このサイズが最もパフォーマンスとワーキングメモリ要件のバランスが取れていることが判明しています。ただし、各アプリケーションの最適な値は、ユースケースによって異なります。 このプロパティは、バッチジョブごとに設定できます。特定のユースケースでカスタムサイズが最適であると思われる場合は、いろいろなサイズで比較テストを実行して、ユースケースに最適なサイズを見つけてください。次の例にバッチブロックサイズを示します。 ```xml ``` ## [](#max-concurrency-最大同時実行)Max Concurrency (最大同時実行) Batch スコープ内の処理に使用されるスレッドの最大数は、デフォルトで JVM で検出されるコア数の 2 倍になります。CloudHub や Anypoint Runtime Fabric のような断片的コアデプロイメントの場合、JVM では​_非断片的_​コア数が検出されます。自動設定された同時実行設定を手動で増減できます。Max Concurrency (最大同時実行) 設定には、それを上回るスレッドを保証するにはレコード数が足りない場合などに、バッチジョブインスタンスに使用するスレッドの上限数を設定できます。 次の例では、自動設定された ​`maxConcurrency`​ (デフォルトでプロパティから読み込まれた設定になる) を上書きします。 ```xml ``` ## [](#batch-aggregator)Batch Aggregator スレッドが 1 つか複数かに関係なく、100 万回ネットワークを往復すればネットワークに影響を与えます。SaaS システムとの通信ではすぐに API コールのクォータがコンシュームされることがあります。レコードを 1 件ずつ処理するのではなく、Batch Aggregator スコープを使用し、レコードの配列に対して一括操作を実行することでパフォーマンスを改善できます。このスコープではアグリゲーターのサイズ設定を使用して各配列のレコード数を制限します。 1 つのレコード配列で処理するレコード数を決定するときには、通信に使用するシステムの操作で許可される最大レコード数を考慮する必要があります。アグリゲーターのサイズ設定と​_それより小さい値_​でパフォーマンステストを実施することが重要です。ロジックは設定値以下のどのレコード数でも処理する必要があります。システムが受信するレコードの数が指定値よりも少ない可能性があるからです。たとえば、120 レコードがあり、アグリゲーターのサイズ設定が 50 の場合、最後の送信は 20 レコードになります。 次の例は、Batch Aggregator スコープが固定サイズの ​`50`​ に設定された Batch Step スコープを示します。 ```xml ``` アグリゲーターにデータのストリーミング操作が含まれる場合、アグリゲーターのサイズ設定 (​`streaming="true"`​) を使用する代わりにスコープのストリーミングオプション (​`size="50"`​) をアクティブ化できます。 ## [](#batch-job-の複数同時インスタンス)Batch Job の複数同時インスタンス Batch Job スコープの多くのユースケースでは一度に 1 つの要求 (バッチジョブインスタンス) のみを処理しますが、同時に複数のバッチジョブインスタンスを実行するケースもあります。そうしたケースのスレッドプール共有をチューニングするために、次のいずれかのスケジュール戦略を設定できます。各戦略はバッチインスタンス ID で別個に追跡されます。 - `ORDERED_SEQUENTIAL`​: インスタンスをトリガーされた順に処理することで同時インスタンスの影響を制限するデフォルトのスケジュール戦略。この戦略は、同じバッチジョブを順不同で処理するとデータの不整合などの問題が発生したり、リソース制限に達したりする可能性がある場合に便利です。 - `ROUND_ROBIN`​: スレッドを「インフライト」のバッチジョブインスタンスと共有するスケジュール戦略です。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.4/batch-processing-concept) # バッチ処理 Mule バッチ処理コンポーネントは、メモリ量を上回るデータセットの信頼できる非同期処理を行うよう設計されています。コンポーネントには Batch Job、Batch Step、Batch Aggregator があります。Batch Job コンポーネントではソースデータを自動的に分割して永続的なキューに格納するため、大量のデータセットを処理しながら信頼性を提供できます。アプリケーションを再デプロイする場合、または Mule がクラッシュした場合、ジョブが停止した位置でジョブの実行を再開できます。

Mule バッチ処理コンポーネントは Mule の Enterprise Edition (EE) バージョン専用です。オープンソースの Mule Kernel を通じてコンポーネントを使用することはできません。

Mule 3.x でのバッチ処理に慣れている場合は、Mule 4.x でのバッチ処理の違いの概要について​「Batch Module の移行」​を参照してください。
バッチ処理の一般的なユースケースを次に挙げます。 - NetSuite と Salesforce 間の連絡先の同期など、ビジネスアプリケーション間でデータセットを同期する。 - フラットファイル (CSV) から Hadoop へのデータのアップロードなど、対象システムへの情報の抽出、変換、および読み込み (ETL) を行う。 - API から従来のシステムへの大量の受信データを処理する。 例については ​[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-filters-and-batch-aggregator) and [Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-error-handling-faq)​ を参照してください。 ## [](#アーキテクチャ)アーキテクチャ Mule バッチ処理コンポーネントでは、レコードを一括で処理できるように準備し、これらのレコードでプロセッサーを実行して、処理の結果に関するレポートを発行します。レコードの準備とレポートは Batch Job コンポーネント内で行われます。処理は 1 つ以上の Batch Step コンポーネント内で行われ、必要に応じて、Batch Step コンポーネント内の Batch Aggregator コンポーネント内で行われます。 ![バッチコンポーネントとプロセッサーが含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-batch-job-overview.png) バッチ処理コンポーネント内に配置したプロセッサーはレコードに対するアクションを実行します。各レコードは Mule イベントに似ています。プロセッサーは ​`payload`​ キーワードを使用して各レコードのペイロードへのアクセス、変更、ルーティングを行うことができ、​`vars`​ を使用して Mule 変数を操作できます。ただし、Batch Job コンポーネントへの入力から Mule 属性 (​`attributes`​) へのアクセスや変更を行うことは​_できません_​。 次の例は、バッチ処理を実行し、その処理の結果が記載されたレポートを返す Mule フローの XML 構造の概要を示しています。 ```xml (1) (2) (3) (4) (5) (6) (7) (8) ``` 例に含まれる ​``​ などのさまざまな ​`placeholder`​ エントリはコネクタ操作、Mule コアコンポーネントなど、Mule メッセージ、レコード、バッチ処理レポートを処理する実際のプロセッサーの場所を示している点に注意してください。これらは​_実際のプロセッサーではありません_​。 1. Mule イベントソースにより Mule フローがトリガーされます。一般的なイベントソースには HTTP 用 Anypoint Connector (HTTP Connector)、Scheduler コンポーネント、新しいファイルをポーリングするコネクタ操作からの HTTP リスナーなどのリスナーがあります。 2. Batch Job コンポーネントのアップストリームに配置されたプロセッサーは通常コンシュームする Batch Job コンポーネントメッセージを取得し、必要に応じてこのメッセージを準備します。たとえば、HTTP 要求操作では処理するデータを取得する場合があり、Transform Message コンポーネントの DataWeave スクリプトではデータを受信する Batch Job コンポーネントにとって​[有効な形式](#valid_input)​に変換する場合があります。 3. Batch Job コンポーネントでフローのアップストリームプロセッサーからメッセージを受信すると、​[Load and Dispatch フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases#phase_load_dispatch)​が開始されます。このフェーズでは、コンポーネントでレコードとして処理するための入力が準備されます。これには処理が行われる Batch Job インスタンスの作成などがあります。 4. Batch Job インスタンスは、Batch Job インスタンスが ​``​ に達した時点で実行されます。この時点で、​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases#phase_process)​が開始されます。すべてのレコード処理はこのフェーズ中に行われます。 5. 各 Batch Step コンポーネントには、レコードに対してその中に含まれるデータを変換、転送、強化、または変更する 1 つ以上のプロセッサーが含まれます。たとえば、処理したレコードを 1 つずつ外部サーバーに渡すようにコネクタ操作を設定する場合があります。 6. Batch Aggregator コンポーネントは省略可能です。Batch Step コンポーネントに追加できるのは 1 つのみです。Batch Aggregator 内の最初のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。バッチ集計は処理したレコードの配列を外部サーバーに読み込む場合に便利です。他のプロセッサーでレコードを 1 つずつ処理できるように、For Each など、配列に対して反復処理を行うコンポーネントを使用することもできます。Batch Aggregator コンポーネントには、レコードの処理方法を示す ​[`streaming`​ または ​`size`](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-reference#ref_batch_aggregator_component)​ 設定が必要です。 7. 追加の Batch Step コンポーネントは省略可能です。この例には、Batch Aggregator コンポーネントは含まれません。 8. レコードがすべての Batch Step コンポーネントを通過したら、Mule で Batch Job インスタンスが完了され、処理中に成功したレコードと失敗したレコードを示す結果がオブジェクトで報告されます。​``​ 内の Logger などのプロセッサーを使用して結果を取得または記録できます。 Batch Job コンポーネントではレコードが ​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases#phase_on_complete)​でコンシュームされます。このフェーズは Batch Job インスタンスのすべてのレコード処理が完了した後に発生し、処理したレコードは Batch Job コンポーネントの外側の外部コンポーネントに伝播されません。ただし、多くの Mule コンポーネントと同じように、Batch Job コンポーネントにより、Batch Job の外側のダウンストリームコンポーネントで Batch Job コンポーネントが受け取る​_事前に処理されたペイロード_​にアクセスするために使用する​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-reference#ref_batch_job_component)​ (​`target`​) プロパティを設定できます。 詳細は、[Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases)を参照してください。 ## [](#valid_input)Batch Job コンポーネントに対する有効な入力 フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Mule メッセージ入力に対する暗黙的な分割操作が実行されます。この操作では、Java イテラブル、イテレーター、配列のほか、JSON ペイロードと XML ペイロードを受け入れます。このコンポーネントでは他のデータ形式を分割できません。 分割プロセスとの互換性がないデータ形式を使用する場合は、Batch Job コンポーネントに入る前にペイロードをサポートされる形式に変換してください。 ## [](#variable_propagation)Mule 変数の伝播 Batch Job インスタンスの各レコードは、Batch Job コンポーネントへの入力から Mule イベント変数を継承します。これらの変数の値は Process フェーズ中に実行される Batch Step コンポーネントおよび Batch Aggregator コンポーネントでアクセスして変更でき、これらのコンポーネント内で新しい変数を作成できます。このフェーズ内の各レコードについて、変数 (およびこれらの変数に対する変更) は Batch Job コンポーネント内の各 Batch Step コンポーネントよび Aggregator コンポーネントを通じて伝播されます。たとえば、レコード R1 で Mule 変数 ​`varName`​ を ​`"hello"`​ に設定し、レコード R2 で ​`varName`​ を ​`"world"`​ に設定して、レコード R3 でこの変数を設定しない場合、次の Batch Step コンポーネント R1 には値 ​`"hello"`​ が表示され、R2 には値 ​`"world"`​ が表示されて、R3 はその変数について ​`null`​ を返します。 似たようなシナリオで、​`varName`​ が Batch Job コンポーネントの​_前_​のフローで設定され、レコード 3 (R3) で ​`varName`​ の値が変更されない場合、R3 はその値を継承します。この点について説明するために、Mule フローが Batch Job コンポーネントに配列 ​`[1,2,3,4]`​ の ​`payload`​ および値が ​`"my variable before batch job"`​ の Mule 変数 ​`varName`​ を送信するとします。次の例では、Choice ルーター (​`choice`​) を使用して最初と 2 番目のレコードで ​`varName`​ の新しい値を設定していますが、3 番目のレコードでは設定していません。後続のレコードでも新しい ​`varName`​ 値を設定しています。 ```xml ``` ログでは Batch Job インスタンスの次のメッセージが出力されます (読みやすいように編集済み)。 ```logs ... INFO ...PRINT VARIABLE BEFORE BATCH: "my variable before batch job" ... INFO ...PRINT VARIABLE VALUES AFTER BATCH JOB: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 1 INFO ...R1: PRINT VARIABLE for PAYLOAD is 1: "hello" INFO ...PRINT RECORD NUMBER: 2 INFO ...R2: PRINT VARIABLE for PAYLOAD is 2: "world" INFO ...PRINT RECORD NUMBER: 3 INFO ...R3: PRINT VARIABLE for PAYLOAD is 3: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 4 INFO ...Rn: PRINT DEFAULT VARIABLE: "some other value" ... INFO ...PRINT VARIABLES IN SECOND STEP: {payload 1="hello"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 2="world"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 3="my variable before batch job"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 4="some other value"} ... ``` 3 番目のレコード (R3) が Batch Job コンポーネントの前で設定された ​`varName`​ の値を継承している点に注意してください。R3 より後のレコードでは変数を ​`"some other value"`​ に設定しています。2 番目の Batch Step に記録されたレコードは最初の Batch Step から変数の値を継承しています。Batch Job インスタンスが処理を完了する​_前_​に非同期で処理される Batch Job コンポーネントの​_後_​の Logger は、Batch Job が実行される​_前_​の ​`varName`​ の値である ​`"my variable before batch job"`​ も受け取ります。 [Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases#phase_process)​中に Mule 変数を変更または追加しても、​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases#phase_on_complete)​には伝播されません。Batch Job コンポーネントへのトリガーイベントから継承された変数のみが On Complete フェーズに伝播され、​`batchJobInstanceId`​ など、Batch Job レポートに含まれる標準変数はこのフェーズでも表示されます。On Complete フェーズでは、このフェーズの最後までは保持されるが On Complete が終了した後は保持されない変数を作成できます。 たとえば、On Complete フェーズで新しい変数 (​`myOnCompleteVar`​) を設定し、このフェーズで見つかったすべての変数 (​`vars`​) を記録するとします。 ```xml ``` On Complete レポートには、たとえば次のように Batch Job インスタンスで最終的に設定される変数が表示されます。 INFO ... PRINT ON COMPLETE VARIABLES: { varName=TypedValue\[value: '"my variable before batch job"', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\], batchJobInstanceId=TypedValue\[value: '869ae510-5c84-11ed-bc38-147ddaaf4f97', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*'}'\], myOnCompleteVar=TypedValue\[value: 'Hello On Complete Variable', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\]} レポートオブジェクトの変数の例は以下に従います。 - `varName`​ は Batch Job コンポーネントに達する前に作成された変数の例です。この変数には、コンポーネントに入ったときの値が保持されます。Process フェーズ中に値を変更しても、On Complete フェーズでは保持されません。 - `batchJobInstanceId`​ は Batch Job インスタンスを識別する標準変数です。 - `myOnCompleteVar`​ は On Complete フェーズ内で作成された変数の例です。レポートには表示されますが、On Complete フェーズの終了後は保持されません。 Batch Job コンポーネントからのダウンロードストリームでは、​`varName`​ のみが保持されます。レコードやその属性と同じように、レコードの変数は Batch Job コンポーネント内で完全にコンシュームされます。Batch Job インスタンスはフローの残りの部分から非同期で実行されるため、Process フェーズまたは On Complete フェーズ内で作成された変数は Batch Job コンポーネント外で保持されません。 ## [](#エラー処理)エラー処理 Batch Job 全体の失敗を防止するために、Batch Job コンポーネントではレコードレベルで発生する失敗を処理できます。また、バッチ処理中に Mule が変数に従って Batch Job インスタンス内のレコードの転送またはアクションを実行できるように、個々のレコードの変数を設定または削除できます。詳細は、​[「Batch Job 中のエラー処理」](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-error-handling-faq)​を参照してください。 ## [](#関連情報)関連情報 - [Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-phases) - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-filters-and-batch-aggregator) - [バッチ処理の調整](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-batch-processing) - [トランザクションによるコンポーネントとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management#tx_components_routers) - [バッチモジュールの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-core-batch) - [バッチジョブが含まれるアプリケーションの永続的なキュー](https://docs.mulesoft.com/cloudhub/cloudhub-fabric#persistent-queues-for-applications-containing-batch-jobs.adoc) # バッチ処理 Mule Runtime Engine (Mule) では、メッセージをバッチ処理できます。バッチジョブは、アプリケーション内で開始できます。これは、大きなメッセージを個々のレコードに分割し、各レコードに対してアクションを実行してから、結果を報告し、場合によっては処理された出力を他のシステムまたはキューに転送するコードブロックです。 100 万件のレコードであっても、バッチアプリケーションなら 3 つのステップで処理できるのです。Mule ジョブのフェーズを移動しながら各レコードを処理している間には、いくつかの I/O 操作が発生します。バッチジョブのパフォーマンスは、ディスクの特性とワークロードのサイズに大きく左右されます。特に入力フェーズでは、ディスク上にキューが作成され、処理するレコードが登録されます。このキューはフローによって継続的に読み書きされるため、I/O 負荷が大きくなります。 さらにバッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 ## [](#batch-block-size-バッチブロックサイズ)Batch Block Size (バッチブロックサイズ) デフォルトでは、バッチブロックサイズは 100 に設定されています。さまざまなレコードサイズで代表的なバッチのユースケースを分析した結果、このサイズが最もパフォーマンスとワーキングメモリ要件のバランスが取れていることが判明しています。ただし、各アプリケーションの最適な値は、ユースケースによって異なります。 このプロパティは、バッチジョブごとに設定できます。特定のユースケースでカスタムサイズが最適であると思われる場合は、いろいろなサイズで比較テストを実行して、ユースケースに最適なサイズを見つけてください。次の例にバッチブロックサイズを示します。 ```xml ``` ## [](#max-concurrency-最大同時実行)Max Concurrency (最大同時実行) Batch スコープ内の処理に使用されるスレッドの最大数は、デフォルトで JVM で検出されるコア数の 2 倍になります。CloudHub や Anypoint Runtime Fabric のような断片的コアデプロイメントの場合、JVM では​_非断片的_​コア数が検出されます。自動設定された同時実行設定を手動で増減できます。Max Concurrency (最大同時実行) 設定には、それを上回るスレッドを保証するにはレコード数が足りない場合などに、バッチジョブインスタンスに使用するスレッドの上限数を設定できます。 次の例では、自動設定された ​`maxConcurrency`​ (デフォルトでプロパティから読み込まれた設定になる) を上書きします。 ```xml ``` ## [](#batch-aggregator)Batch Aggregator スレッドが 1 つか複数かに関係なく、100 万回ネットワークを往復すればネットワークに影響を与えます。SaaS システムとの通信ではすぐに API コールのクォータがコンシュームされることがあります。レコードを 1 件ずつ処理するのではなく、Batch Aggregator スコープを使用し、レコードの配列に対して一括操作を実行することでパフォーマンスを改善できます。このスコープではアグリゲーターのサイズ設定を使用して各配列のレコード数を制限します。 1 つのレコード配列で処理するレコード数を決定するときには、通信に使用するシステムの操作で許可される最大レコード数を考慮する必要があります。アグリゲーターのサイズ設定と​_それより小さい値_​でパフォーマンステストを実施することが重要です。ロジックは設定値以下のどのレコード数でも処理する必要があります。システムが受信するレコードの数が指定値よりも少ない可能性があるからです。たとえば、120 レコードがあり、アグリゲーターのサイズ設定が 50 の場合、最後の送信は 20 レコードになります。 次の例は、Batch Aggregator スコープが固定サイズの ​`50`​ に設定された Batch Step スコープを示します。 ```xml ``` アグリゲーターにデータのストリーミング操作が含まれる場合、アグリゲーターのサイズ設定 (​`streaming="true"`​) を使用する代わりにスコープのストリーミングオプション (​`size="50"`​) をアクティブ化できます。 ## [](#batch-job-の複数同時インスタンス)Batch Job の複数同時インスタンス Batch Job スコープの多くのユースケースでは一度に 1 つの要求 (バッチジョブインスタンス) のみを処理しますが、同時に複数のバッチジョブインスタンスを実行するケースもあります。そうしたケースのスレッドプール共有をチューニングするために、次のいずれかのスケジュール戦略を設定できます。各戦略はバッチインスタンス ID で別個に追跡されます。 - `ORDERED_SEQUENTIAL`​: インスタンスをトリガーされた順に処理することで同時インスタンスの影響を制限するデフォルトのスケジュール戦略。この戦略は、同じバッチジョブを順不同で処理するとデータの不整合などの問題が発生したり、リソース制限に達したりする可能性がある場合に便利です。 - `ROUND_ROBIN`​: スレッドを「インフライト」のバッチジョブインスタンスと共有するスケジュール戦略です。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.5/batch-processing-concept) # バッチ処理 Mule バッチ処理コンポーネントは、メモリ量を上回るデータセットの信頼できる非同期処理を行うよう設計されています。コンポーネントには Batch Job、Batch Step、Batch Aggregator があります。Batch Job コンポーネントではソースデータを自動的に分割して永続的なキューに格納するため、大量のデータセットを処理しながら信頼性を提供できます。アプリケーションを再デプロイする場合、または Mule がクラッシュした場合、ジョブが停止した位置でジョブの実行を再開できます。

Mule バッチ処理コンポーネントは Mule の Enterprise Edition (EE) バージョン専用です。オープンソースの Mule Kernel を通じてコンポーネントを使用することはできません。

Mule 3.x でのバッチ処理に慣れている場合は、Mule 4.x でのバッチ処理の違いの概要について​「Batch Module の移行」​を参照してください。
バッチ処理の一般的なユースケースを次に挙げます。 - NetSuite と Salesforce 間の連絡先の同期など、ビジネスアプリケーション間でデータセットを同期する。 - フラットファイル (CSV) から Hadoop へのデータのアップロードなど、対象システムへの情報の抽出、変換、および読み込み (ETL) を行う。 - API から従来のシステムへの大量の受信データを処理する。 例については ​[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-filters-and-batch-aggregator) and [Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-error-handling-faq)​を参照してください。 ## [](#アーキテクチャ)アーキテクチャ Mule バッチ処理コンポーネントでは、レコードを一括で処理できるように準備し、これらのレコードでプロセッサーを実行して、処理の結果に関するレポートを発行します。レコードの準備とレポートは Batch Job コンポーネント内で行われます。処理は 1 つ以上の Batch Step コンポーネント内で行われ、必要に応じて、Batch Step コンポーネント内の Batch Aggregator コンポーネント内で行われます。 ![バッチコンポーネントとプロセッサーが含まれるフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-batch-job-overview.png) バッチ処理コンポーネント内に配置したプロセッサーはレコードに対するアクションを実行します。各レコードは Mule イベントに似ています。プロセッサーは ​`payload`​ キーワードを使用して各レコードのペイロードへのアクセス、変更、ルーティングを行うことができ、​`vars`​ を使用して Mule 変数を操作できます。ただし、Batch Job コンポーネントへの入力から Mule 属性 (​`attributes`​) へのアクセスや変更を行うことは​_できません_​。 次の例は、バッチ処理を実行し、その処理の結果が記載されたレポートを返す Mule フローの XML 構造の概要を示しています。 ```xml (1) (2) (3) (4) (5) (6) (7) (8) ``` 例に含まれる ​``​ などのさまざまな ​`placeholder`​ エントリはコネクタ操作、Mule コアコンポーネントなど、Mule メッセージ、レコード、バッチ処理レポートを処理する実際のプロセッサーの場所を示している点に注意してください。これらは​_実際のプロセッサーではありません_​。 1. Mule イベントソースにより Mule フローがトリガーされます。一般的なイベントソースには HTTP 用 Anypoint Connector (HTTP Connector)、Scheduler コンポーネント、新しいファイルをポーリングするコネクタ操作からの HTTP リスナーなどのリスナーがあります。 2. Batch Job コンポーネントのアップストリームに配置されたプロセッサーは通常コンシュームする Batch Job コンポーネントメッセージを取得し、必要に応じてこのメッセージを準備します。たとえば、HTTP 要求操作では処理するデータを取得する場合があり、Transform Message コンポーネントの DataWeave スクリプトではデータを受信する Batch Job コンポーネントにとって​[有効な形式](#valid_input)​に変換する場合があります。 3. Batch Job コンポーネントでフローのアップストリームプロセッサーからメッセージを受信すると、​[Load and Dispatch フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases#phase_load_dispatch)​が開始されます。このフェーズでは、コンポーネントでレコードとして処理するための入力が準備されます。これには処理が行われる Batch Job インスタンスの作成などがあります。 4. Batch Job インスタンスは、Batch Job インスタンスが ​``​ に達した時点で実行されます。この時点で、​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases#phase_process)​が開始されます。すべてのレコード処理はこのフェーズ中に行われます。 5. 各 Batch Step コンポーネントには、レコードに対してその中に含まれるデータを変換、転送、強化、または変更する 1 つ以上のプロセッサーが含まれます。たとえば、処理したレコードを 1 つずつ外部サーバーに渡すようにコネクタ操作を設定する場合があります。 6. Batch Aggregator コンポーネントは省略可能です。Batch Step コンポーネントに追加できるのは 1 つのみです。Batch Aggregator 内の最初のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。バッチ集計は処理したレコードの配列を外部サーバーに読み込む場合に便利です。他のプロセッサーでレコードを 1 つずつ処理できるように、For Each など、配列に対して反復処理を行うコンポーネントを使用することもできます。Batch Aggregator コンポーネントには、レコードの処理方法を示す ​[`streaming`​ または ​`size`](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-reference#ref_batch_aggregator_component)​ 設定が必要です。 7. 追加の Batch Step コンポーネントは省略可能です。この例には、Batch Aggregator コンポーネントは含まれません。 8. レコードがすべての Batch Step コンポーネントを通過したら、Mule で Batch Job インスタンスが完了され、処理中に成功したレコードと失敗したレコードを示す結果がオブジェクトで報告されます。​``​ 内の Logger などのプロセッサーを使用して結果を取得または記録できます。 Batch Job コンポーネントではレコードが ​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases#phase_on_complete)​でコンシュームされます。このフェーズは Batch Job インスタンスのすべてのレコード処理が完了した後に発生し、処理したレコードは Batch Job コンポーネントの外側の外部コンポーネントに伝播されません。ただし、多くの Mule コンポーネントと同じように、Batch Job コンポーネントにより、Batch Job の外側のダウンストリームコンポーネントで Batch Job コンポーネントが受け取る​_事前に処理されたペイロード_​にアクセスするために使用する​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-reference#ref_batch_job_component)​ (​`target`​) プロパティを設定できます。 詳細は、[Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases)を参照してください。 ## [](#valid_input)Batch Job コンポーネントに対する有効な入力 フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Mule メッセージ入力に対する暗黙的な分割操作が実行されます。この操作では、Java イテラブル、イテレーター、配列のほか、JSON ペイロードと XML ペイロードを受け入れます。このコンポーネントでは他のデータ形式を分割できません。 分割プロセスとの互換性がないデータ形式を使用する場合は、Batch Job コンポーネントに入る前にペイロードをサポートされる形式に変換してください。 ## [](#variable_propagation)Mule 変数の伝播 Batch Job インスタンスの各レコードは、Batch Job コンポーネントへの入力から Mule イベント変数を継承します。これらの変数の値は Process フェーズ中に実行される Batch Step コンポーネントおよび Batch Aggregator コンポーネントでアクセスして変更でき、これらのコンポーネント内で新しい変数を作成できます。このフェーズ内の各レコードについて、変数 (およびこれらの変数に対する変更) は Batch Job コンポーネント内の各 Batch Step コンポーネントおよび Aggregator コンポーネントを通じて伝播されます。たとえば、レコード R1 で Mule 変数 ​`varName`​ を ​`"hello"`​ に設定し、レコード R2 で ​`varName`​ を ​`"world"`​ に設定して、レコード R3 でこの変数を設定しない場合、次の Batch Step コンポーネント R1 には値 ​`"hello"`​ が表示され、R2 には値 ​`"world"`​ が表示されて、R3 はその変数について ​`null`​ を返します。 似たようなシナリオで、​`varName`​ が Batch Job コンポーネントの​_前_​のフローで設定され、レコード 3 (R3) で ​`varName`​ の値が変更されない場合、R3 はその値を継承します。この点について説明するために、Mule フローが Batch Job コンポーネントに配列 ​`[1,2,3,4]`​ の ​`payload`​ および値が ​`"my variable before batch job"`​ の Mule 変数 ​`varName`​ を送信するとします。次の例では、Choice ルーター (​`choice`​) を使用して最初と 2 番目のレコードで ​`varName`​ の新しい値を設定していますが、3 番目のレコードでは設定していません。後続のレコードでも新しい ​`varName`​ 値を設定しています。 ```xml ``` ログでは Batch Job インスタンスの次のメッセージが出力されます (読みやすいように編集済み)。 ```logs ... INFO ...PRINT VARIABLE BEFORE BATCH: "my variable before batch job" ... INFO ...PRINT VARIABLE VALUES AFTER BATCH JOB: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 1 INFO ...R1: PRINT VARIABLE for PAYLOAD is 1: "hello" INFO ...PRINT RECORD NUMBER: 2 INFO ...R2: PRINT VARIABLE for PAYLOAD is 2: "world" INFO ...PRINT RECORD NUMBER: 3 INFO ...R3: PRINT VARIABLE for PAYLOAD is 3: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 4 INFO ...Rn: PRINT DEFAULT VARIABLE: "some other value" ... INFO ...PRINT VARIABLES IN SECOND STEP: {payload 1="hello"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 2="world"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 3="my variable before batch job"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 4="some other value"} ... ``` 3 番目のレコード (R3) が Batch Job コンポーネントの前で設定された ​`varName`​ の値を継承している点に注意してください。R3 より後のレコードでは変数を ​`"some other value"`​ に設定しています。2 番目の Batch Step に記録されたレコードは最初の Batch Step から変数の値を継承しています。Batch Job インスタンスが処理を完了する​_前_​に非同期で処理される Batch Job コンポーネントの​_後_​の Logger は、Batch Job が実行される​_前_​の ​`varName`​ の値である ​`"my variable before batch job"`​ も受け取ります。 [Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases#phase_process)​中に Mule 変数を変更または追加しても、​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases#phase_on_complete)​には伝播されません。Batch Job コンポーネントへのトリガーイベントから継承された変数のみが On Complete フェーズに伝播され、​`batchJobInstanceId`​ など、Batch Job レポートに含まれる標準変数はこのフェーズでも表示されます。On Complete フェーズでは、このフェーズの最後までは保持されるが On Complete が終了した後は保持されない変数を作成できます。 たとえば、On Complete フェーズで新しい変数 (​`myOnCompleteVar`​) を設定し、このフェーズで見つかったすべての変数 (​`vars`​) を記録するとします。 ```xml ``` On Complete レポートには、たとえば次のように Batch Job インスタンスで最終的に設定される変数が表示されます。 INFO ... PRINT ON COMPLETE VARIABLES: { varName=TypedValue\[value: '"my variable before batch job"', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\], batchJobInstanceId=TypedValue\[value: '869ae510-5c84-11ed-bc38-147ddaaf4f97', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*'}'\], myOnCompleteVar=TypedValue\[value: 'Hello On Complete Variable', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\]} レポートオブジェクトの変数の例は以下に従います。 - `varName`​ は Batch Job コンポーネントに達する前に作成された変数の例です。この変数には、コンポーネントに入ったときの値が保持されます。Process フェーズ中に値を変更しても、On Complete フェーズでは保持されません。 - `batchJobInstanceId`​ は Batch Job インスタンスを識別する標準変数です。 - `myOnCompleteVar`​ は On Complete フェーズ内で作成された変数の例です。レポートには表示されますが、On Complete フェーズの終了後は保持されません。 Batch Job コンポーネントからのダウンロードストリームでは、​`varName`​ のみが保持されます。レコードやその属性と同じように、レコードの変数は Batch Job コンポーネント内で完全にコンシュームされます。Batch Job インスタンスはフローの残りの部分から非同期で実行されるため、Process フェーズまたは On Complete フェーズ内で作成された変数は Batch Job コンポーネント外で保持されません。 ## [](#エラー処理)エラー処理 Batch Job 全体の失敗を防止するために、Batch Job コンポーネントではレコードレベルで発生する失敗を処理できます。また、バッチ処理中に Mule が変数に従って Batch Job インスタンス内のレコードの転送またはアクションを実行できるように、個々のレコードの変数を設定または削除できます。詳細は、​[「Batch Job 中のエラー処理」](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-error-handling-faq)​を参照してください。 ## [](#関連情報)関連情報 - [Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-phases) - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-filters-and-batch-aggregator) - [バッチ処理の調整](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-batch-processing) - [トランザクションによるコンポーネントとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management#tx_components_routers) - [バッチモジュールの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-core-batch) - [バッチジョブが含まれるアプリケーションの永続的なキュー](https://docs.mulesoft.com/cloudhub/cloudhub-fabric#persistent-queues-for-applications-containing-batch-jobs.adoc) # バッチ処理 Mule Runtime Engine (Mule) では、メッセージをバッチ処理できます。バッチジョブは、アプリケーション内で開始できます。これは、大きなメッセージを個々のレコードに分割し、各レコードに対してアクションを実行してから、結果を報告し、場合によっては処理された出力を他のシステムまたはキューに転送するコードブロックです。 100 万件のレコードであっても、バッチアプリケーションなら 3 つのステップで処理できるのです。Mule ジョブのフェーズを移動しながら各レコードを処理している間には、いくつかの I/O 操作が発生します。バッチジョブのパフォーマンスは、ディスクの特性とワークロードのサイズに大きく左右されます。特に入力フェーズでは、ディスク上にキューが作成され、処理するレコードが登録されます。このキューはフローによって継続的に読み書きされるため、I/O 負荷が大きくなります。 さらにバッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 ## [](#batch-block-size-バッチブロックサイズ)Batch Block Size (バッチブロックサイズ) デフォルトでは、バッチブロックサイズは 100 に設定されています。さまざまなレコードサイズで代表的なバッチのユースケースを分析した結果、このサイズが最もパフォーマンスとワーキングメモリ要件のバランスが取れていることが判明しています。ただし、各アプリケーションの最適な値は、ユースケースによって異なります。 このプロパティは、バッチジョブごとに設定できます。特定のユースケースでカスタムサイズが最適であると思われる場合は、いろいろなサイズで比較テストを実行して、ユースケースに最適なサイズを見つけてください。次の例にバッチブロックサイズを示します。 ```xml ``` ## [](#max-concurrency-最大同時実行)Max Concurrency (最大同時実行) Batch スコープ内の処理に使用されるスレッドの最大数は、デフォルトで JVM で検出されるコア数の 2 倍になります。CloudHub や Anypoint Runtime Fabric のような断片的コアデプロイメントの場合、JVM では​_非断片的_​コア数が検出されます。自動設定された同時実行設定を手動で増減できます。Max Concurrency (最大同時実行) 設定には、それを上回るスレッドを保証するにはレコード数が足りない場合などに、バッチジョブインスタンスに使用するスレッドの上限数を設定できます。 次の例では、自動設定された ​`maxConcurrency`​ (デフォルトでプロパティから読み込まれた設定になる) を上書きします。 ```xml ``` ## [](#batch-aggregator)Batch Aggregator スレッドが 1 つか複数かに関係なく、100 万回ネットワークを往復すればネットワークに影響を与えます。SaaS システムとの通信ではすぐに API コールのクォータがコンシュームされることがあります。レコードを 1 件ずつ処理するのではなく、Batch Aggregator スコープを使用し、レコードの配列に対して一括操作を実行することでパフォーマンスを改善できます。このスコープではアグリゲーターのサイズ設定を使用して各配列のレコード数を制限します。 1 つのレコード配列で処理するレコード数を決定するときには、通信に使用するシステムの操作で許可される最大レコード数を考慮する必要があります。アグリゲーターのサイズ設定と​_それより小さい値_​でパフォーマンステストを実施することが重要です。ロジックは設定値以下のどのレコード数でも処理する必要があります。システムが受信するレコードの数が指定値よりも少ない可能性があるからです。たとえば、120 レコードがあり、アグリゲーターのサイズ設定が 50 の場合、最後の送信は 20 レコードになります。 次の例は、Batch Aggregator スコープが固定サイズの ​`50`​ に設定された Batch Step スコープを示します。 ```xml ``` アグリゲーターにデータのストリーミング操作が含まれる場合、アグリゲーターのサイズ設定 (​`streaming="true"`​) を使用する代わりにスコープのストリーミングオプション (​`size="50"`​) をアクティブ化できます。 ## [](#batch-job-の複数同時インスタンス)Batch Job の複数同時インスタンス Batch Job スコープの多くのユースケースでは一度に 1 つの要求 (バッチジョブインスタンス) のみを処理しますが、同時に複数のバッチジョブインスタンスを実行するケースもあります。そうしたケースのスレッドプール共有をチューニングするために、次のいずれかのスケジュール戦略を設定できます。各戦略はバッチインスタンス ID で別個に追跡されます。 - `ORDERED_SEQUENTIAL`​: インスタンスをトリガーされた順に処理することで同時インスタンスの影響を制限するデフォルトのスケジュール戦略。この戦略は、同じバッチジョブを順不同で処理するとデータの不整合などの問題が発生したり、リソース制限に達したりする可能性がある場合に便利です。 - `ROUND_ROBIN`​: スレッドを「インフライト」のバッチジョブインスタンスと共有するスケジュール戦略です。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.6/batch-processing-concept) # バッチ処理 Mule バッチ処理コンポーネントは、メモリ量を上回るデータセットの信頼できる非同期処理を行うよう設計されています。コンポーネントには Batch Job、Batch Step、Batch Aggregator があります。Batch Job コンポーネントではソースデータを自動的に分割して永続的なキューに格納するため、大量のデータセットを処理しながら信頼性を提供できます。アプリケーションを再デプロイする場合、または Mule がクラッシュした場合、ジョブが停止した位置でジョブの実行を再開できます。

Mule バッチ処理コンポーネントは Mule の Enterprise Edition (EE) バージョン専用です。オープンソースの Mule Kernel を通じてコンポーネントを使用することはできません。

Mule 3.x でのバッチ処理に慣れている場合は、Mule 4.x でのバッチ処理の違いの概要について​「Batch Module の移行」​を参照してください。
バッチ処理の一般的なユースケースを次に挙げます。 - NetSuite と Salesforce 間の連絡先の同期など、ビジネスアプリケーション間でデータセットを同期する。 - フラットファイル (CSV) から Hadoop へのデータのアップロードなど、対象システムへの情報の抽出、変換、および読み込み (ETL) を行う。 - API から従来のシステムへの大量の受信データを処理する。 例については​[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-filters-and-batch-aggregator) and [Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-error-handling-faq)​を参照してください。 ## [](#アーキテクチャ)アーキテクチャ Mule バッチ処理コンポーネントでは、レコードを一括で処理できるように準備し、これらのレコードでプロセッサーを実行して、処理の結果に関するレポートを発行します。レコードの準備とレポートは Batch Job コンポーネント内で行われます。処理は 1 つ以上の Batch Step コンポーネント内で行われ、必要に応じて、Batch Step コンポーネント内の Batch Aggregator コンポーネント内で行われます。 ![バッチコンポーネントとプロセッサーが含まれる Mule フロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-batch-job-overview.png) バッチ処理コンポーネント内に配置したプロセッサーはレコードに対するアクションを実行します。各レコードは Mule イベントに似ています。プロセッサーは ​`payload`​ キーワードを使用して各レコードのペイロードへのアクセス、変更、ルーティングを行うことができ、​`vars`​ を使用して Mule 変数を操作できます。ただし、Batch Job コンポーネントへの入力から Mule 属性 (​`attributes`​) へのアクセスや変更を行うことは​_できません_​。 次の例は、バッチ処理を実行し、その処理の結果が記載されたレポートを返す Mule フローの XML 構造の概要を示しています。 ```xml (1) (2) (3) (4) (5) (6) (7) (8) ``` 例に含まれる ​``​ などのさまざまな ​`placeholder`​ エントリはコネクタ操作、Mule コアコンポーネントなど、Mule メッセージ、レコード、バッチ処理レポートを処理する実際のプロセッサーの場所を示している点に注意してください。これらは​_実際のプロセッサーではありません_​。 1. Mule イベントソースにより Mule フローがトリガーされます。一般的なイベントソースには HTTP 用 Anypoint Connector (HTTP Connector)、Scheduler コンポーネント、新しいファイルをポーリングするコネクタ操作からの HTTP リスナーなどのリスナーがあります。 2. Batch Job コンポーネントのアップストリームに配置されたプロセッサーは通常コンシュームする Batch Job コンポーネントメッセージを取得し、必要に応じてこのメッセージを準備します。たとえば、HTTP 要求操作では処理するデータを取得する場合があり、Transform Message コンポーネントの DataWeave スクリプトではデータを受信する Batch Job コンポーネントにとって​[有効な形式](#valid_input)​に変換する場合があります。 3. Batch Job コンポーネントでフローのアップストリームプロセッサーからメッセージを受信すると、​[Load and Dispatch フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases#phase_load_dispatch)​が開始されます。このフェーズでは、コンポーネントでレコードとして処理するための入力が準備されます。これには処理が行われる Batch Job インスタンスの作成などがあります。 4. Batch Job インスタンスは、Batch Job インスタンスが ​``​ に達した時点で実行されます。この時点で、​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases#phase_process)​が開始されます。すべてのレコード処理はこのフェーズ中に行われます。 5. 各 Batch Step コンポーネントには、レコードに対してその中に含まれるデータを変換、転送、強化、または変更する 1 つ以上のプロセッサーが含まれます。たとえば、処理したレコードを 1 つずつ外部サーバーに渡すようにコネクタ操作を設定する場合があります。 6. Batch Aggregator コンポーネントは省略可能です。Batch Step コンポーネントに追加できるのは 1 つのみです。Batch Aggregator 内の最初のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。バッチ集計は処理したレコードの配列を外部サーバーに読み込む場合に便利です。他のプロセッサーでレコードを 1 つずつ処理できるように、For Each など、配列に対して反復処理を行うコンポーネントを使用することもできます。Batch Aggregator コンポーネントには、レコードの処理方法を示す ​[`streaming`​ または ​`size`](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-reference#ref_batch_aggregator_component)​ 設定が必要です。 7. 追加の Batch Step コンポーネントは省略可能です。この例には、Batch Aggregator コンポーネントは含まれません。 8. レコードがすべての Batch Step コンポーネントを通過したら、Mule で Batch Job インスタンスが完了され、処理中に成功したレコードと失敗したレコードを示す結果がオブジェクトで報告されます。​``​ 内の Logger などのプロセッサーを使用して結果を取得または記録できます。 Batch Job コンポーネントではレコードが ​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases#phase_on_complete)​でコンシュームされます。このフェーズは Batch Job インスタンスのすべてのレコード処理が完了した後に発生し、処理したレコードは Batch Job コンポーネントの外側の外部コンポーネントに伝播されません。ただし、多くの Mule コンポーネントと同じように、Batch Job コンポーネントにより、Batch Job の外側のダウンストリームコンポーネントで Batch Job コンポーネントが受け取る​_事前に処理されたペイロード_​にアクセスするために使用する​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-reference#ref_batch_job_component)​ (​`target`​) プロパティを設定できます。 詳細は、[Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases)を参照してください。 ## [](#valid_input)Batch Job コンポーネントに対する有効な入力 フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Mule メッセージ入力に対する暗黙的な分割操作が実行されます。この操作では、Java イテラブル、イテレーター、配列のほか、JSON ペイロードと XML ペイロードを受け入れます。このコンポーネントでは他のデータ形式を分割できません。 分割プロセスとの互換性がないデータ形式を使用する場合は、Batch Job コンポーネントに入る前にペイロードをサポートされる形式に変換してください。 ## [](#variable_propagation)Mule 変数の伝播 Batch Job インスタンスの各レコードは、Batch Job コンポーネントへの入力から Mule イベント変数を継承します。これらの変数の値は Process フェーズ中に実行される Batch Step コンポーネントおよび Batch Aggregator コンポーネントでアクセスして変更でき、これらのコンポーネント内で新しい変数を作成できます。このフェーズ内の各レコードについて、変数 (およびこれらの変数に対する変更) は Batch Job コンポーネント内の各 Batch Step コンポーネントおよび Aggregator コンポーネントを通じて伝播されます。たとえば、レコード R1 で Mule 変数 ​`varName`​ を ​`"hello"`​ に設定し、レコード R2 で ​`varName`​ を ​`"world"`​ に設定して、レコード R3 でこの変数を設定しない場合、次の Batch Step コンポーネント R1 には値 ​`"hello"`​ が表示され、R2 には値 ​`"world"`​ が表示されて、R3 はその変数について ​`null`​ を返します。 似たようなシナリオで、​`varName`​ が Batch Job コンポーネントの​_前_​のフローで設定され、レコード 3 (R3) で ​`varName`​ の値が変更されない場合、R3 はその値を継承します。この点について説明するために、Mule フローが Batch Job コンポーネントに配列 ​`[1,2,3,4]`​ の ​`payload`​ および値が ​`"my variable before batch job"`​ の Mule 変数 ​`varName`​ を送信するとします。次の例では、Choice ルーター (​`choice`​) を使用して最初と 2 番目のレコードで ​`varName`​ の新しい値を設定していますが、3 番目のレコードでは設定していません。後続のレコードでも新しい ​`varName`​ 値を設定しています。 ```xml ``` ログでは Batch Job インスタンスの次のメッセージが出力されます (読みやすいように編集済み)。 ```logs ... INFO ...PRINT VARIABLE BEFORE BATCH: "my variable before batch job" ... INFO ...PRINT VARIABLE VALUES AFTER BATCH JOB: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 1 INFO ...R1: PRINT VARIABLE for PAYLOAD is 1: "hello" INFO ...PRINT RECORD NUMBER: 2 INFO ...R2: PRINT VARIABLE for PAYLOAD is 2: "world" INFO ...PRINT RECORD NUMBER: 3 INFO ...R3: PRINT VARIABLE for PAYLOAD is 3: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 4 INFO ...Rn: PRINT DEFAULT VARIABLE: "some other value" ... INFO ...PRINT VARIABLES IN SECOND STEP: {payload 1="hello"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 2="world"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 3="my variable before batch job"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 4="some other value"} ... ``` 3 番目のレコード (R3) が Batch Job コンポーネントの前で設定された ​`varName`​ の値を継承している点に注意してください。R3 より後のレコードでは変数を ​`"some other value"`​ に設定しています。2 番目の Batch Step に記録されたレコードは最初の Batch Step から変数の値を継承しています。Batch Job インスタンスが処理を完了する​_前_​に非同期で処理される Batch Job コンポーネントの​_後_​の Logger は、Batch Job が実行される​_前_​の ​`varName`​ の値である ​`"my variable before batch job"`​ も受け取ります。 [Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases#phase_process)​中に Mule 変数を変更または追加しても、​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases#phase_on_complete)​には伝播されません。Batch Job コンポーネントへのトリガーイベントから継承された変数のみが On Complete フェーズに伝播され、​`batchJobInstanceId`​ など、Batch Job レポートに含まれる標準変数はこのフェーズでも表示されます。On Complete フェーズでは、このフェーズの最後までは保持されるが On Complete が終了した後は保持されない変数を作成できます。 たとえば、On Complete フェーズで新しい変数 (​`myOnCompleteVar`​) を設定し、このフェーズで見つかったすべての変数 (​`vars`​) を記録するとします。 ```xml ``` On Complete レポートには、たとえば次のように Batch Job インスタンスで最終的に設定される変数が表示されます。 INFO ... PRINT ON COMPLETE VARIABLES: { varName=TypedValue\[value: '"my variable before batch job"', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\], batchJobInstanceId=TypedValue\[value: '869ae510-5c84-11ed-bc38-147ddaaf4f97', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*'}'\], myOnCompleteVar=TypedValue\[value: 'Hello On Complete Variable', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\]} レポートオブジェクトの変数の例は以下に従います。 - `varName`​ は Batch Job コンポーネントに達する前に作成された変数の例です。この変数には、コンポーネントに入ったときの値が保持されます。Process フェーズ中に値を変更しても、On Complete フェーズでは保持されません。 - `batchJobInstanceId`​ は Batch Job インスタンスを識別する標準変数です。 - `myOnCompleteVar`​ は On Complete フェーズ内で作成された変数の例です。レポートには表示されますが、On Complete フェーズの終了後は保持されません。 Batch Job コンポーネントからのダウンロードストリームでは、​`varName`​ のみが保持されます。レコードやその属性と同じように、レコードの変数は Batch Job コンポーネント内で完全にコンシュームされます。Batch Job インスタンスはフローの残りの部分から非同期で実行されるため、Process フェーズまたは On Complete フェーズ内で作成された変数は Batch Job コンポーネント外で保持されません。 ## [](#エラー処理)エラー処理 Batch Job 全体の失敗を防止するために、Batch Job コンポーネントではレコードレベルで発生する失敗を処理できます。また、バッチ処理中に Mule が変数に従って Batch Job インスタンス内のレコードの転送またはアクションを実行できるように、個々のレコードの変数を設定または削除できます。詳細は、​[「Batch Job 中のエラー処理」](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-error-handling-faq)​を参照してください。 ## [](#関連情報)関連情報 - [Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-phases) - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-filters-and-batch-aggregator) - [バッチ処理の調整](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-batch-processing) - [トランザクションによるコンポーネントとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management#tx_components_routers) - [バッチモジュールの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-core-batch) - [バッチジョブが含まれるアプリケーションの永続的なキュー](https://docs.mulesoft.com/cloudhub/cloudhub-fabric#persistent-queues-for-applications-containing-batch-jobs.adoc) # バッチ処理 Mule Runtime Engine (Mule) では、メッセージをバッチ処理できます。バッチジョブは、アプリケーション内で開始できます。これは、大きなメッセージを個々のレコードに分割し、各レコードに対してアクションを実行してから、結果を報告し、場合によっては処理された出力を他のシステムまたはキューに転送するコードブロックです。 100 万件のレコードであっても、バッチアプリケーションなら 3 つのステップで処理できるのです。Mule ジョブのフェーズを移動しながら各レコードを処理している間には、いくつかの I/O 操作が発生します。バッチジョブのパフォーマンスは、ディスクの特性とワークロードのサイズに大きく左右されます。特に入力フェーズでは、ディスク上にキューが作成され、処理するレコードが登録されます。このキューはフローによって継続的に読み書きされるため、I/O 負荷が大きくなります。 さらにバッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 ## [](#batch-block-size-バッチブロックサイズ)Batch Block Size (バッチブロックサイズ) デフォルトでは、バッチブロックサイズは 100 に設定されています。さまざまなレコードサイズで代表的なバッチのユースケースを分析した結果、このサイズが最もパフォーマンスとワーキングメモリ要件のバランスが取れていることが判明しています。ただし、各アプリケーションの最適な値は、ユースケースによって異なります。 このプロパティは、バッチジョブごとに設定できます。特定のユースケースでカスタムサイズが最適であると思われる場合は、いろいろなサイズで比較テストを実行して、ユースケースに最適なサイズを見つけてください。次の例にバッチブロックサイズを示します。 ```xml ``` ## [](#max-concurrency-最大同時実行)Max Concurrency (最大同時実行) Batch スコープ内の処理に使用されるスレッドの最大数は、デフォルトで JVM で検出されるコア数の 2 倍になります。CloudHub や Anypoint Runtime Fabric のような断片的コアデプロイメントの場合、JVM では​_非断片的_​コア数が検出されます。自動設定された同時実行設定を手動で増減できます。Max Concurrency (最大同時実行) 設定には、それを上回るスレッドを保証するにはレコード数が足りない場合などに、バッチジョブインスタンスに使用するスレッドの上限数を設定できます。 次の例では、自動設定された ​`maxConcurrency`​ (デフォルトでプロパティから読み込まれた設定になる) を上書きします。 ```xml ``` ## [](#batch-aggregator)Batch Aggregator スレッドが 1 つか複数かに関係なく、100 万回ネットワークを往復すればネットワークに影響を与えます。SaaS システムとの通信ではすぐに API コールのクォータがコンシュームされることがあります。レコードを 1 件ずつ処理するのではなく、Batch Aggregator スコープを使用し、レコードの配列に対して一括操作を実行することでパフォーマンスを改善できます。このスコープではアグリゲーターのサイズ設定を使用して各配列のレコード数を制限します。 1 つのレコード配列で処理するレコード数を決定するときには、通信に使用するシステムの操作で許可される最大レコード数を考慮する必要があります。アグリゲーターのサイズ設定と​_それより小さい値_​でパフォーマンステストを実施することが重要です。ロジックは設定値以下のどのレコード数でも処理する必要があります。システムが受信するレコードの数が指定値よりも少ない可能性があるからです。たとえば、120 レコードがあり、アグリゲーターのサイズ設定が 50 の場合、最後の送信は 20 レコードになります。 次の例は、Batch Aggregator スコープが固定サイズの ​`50`​ に設定された Batch Step スコープを示します。 ```xml ``` アグリゲーターにデータのストリーミング操作が含まれる場合、アグリゲーターのサイズ設定 (​`streaming="true"`​) を使用する代わりにスコープのストリーミングオプション (​`size="50"`​) をアクティブ化できます。 ## [](#batch-job-の複数同時インスタンス)Batch Job の複数同時インスタンス Batch Job スコープの多くのユースケースでは一度に 1 つの要求 (バッチジョブインスタンス) のみを処理しますが、同時に複数のバッチジョブインスタンスを実行するケースもあります。そうしたケースのスレッドプール共有をチューニングするために、次のいずれかのスケジュール戦略を設定できます。各戦略はバッチインスタンス ID で別個に追跡されます。 - `ORDERED_SEQUENTIAL`​: インスタンスをトリガーされた順に処理することで同時インスタンスの影響を制限するデフォルトのスケジュール戦略。この戦略は、同じバッチジョブを順不同で処理するとデータの不整合などの問題が発生したり、リソース制限に達したりする可能性がある場合に便利です。 - `ROUND_ROBIN`​: スレッドを「インフライト」のバッチジョブインスタンスと共有するスケジュール戦略です。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.7/batch-processing-concept) # バッチ処理 Mule バッチ処理コンポーネントは、メモリ量を上回るデータセットの信頼できる非同期処理を行うよう設計されています。コンポーネントには Batch Job、Batch Step、Batch Aggregator があります。Batch Job コンポーネントではソースデータを自動的に分割して永続的なキューに格納するため、大量のデータセットを処理しながら信頼性を提供できます。アプリケーションを再デプロイする場合、または Mule がクラッシュした場合、ジョブが停止した位置でジョブの実行を再開できます。

Mule バッチ処理コンポーネントは Mule の Enterprise Edition (EE) バージョン専用です。オープンソースの Mule Kernel を通じてコンポーネントを使用することはできません。

Mule 3.x でのバッチ処理に慣れている場合は、Mule 4.x でのバッチ処理の違いの概要について​「Batch Module の移行」​を参照してください。
バッチ処理の一般的なユースケースを次に挙げます。 - NetSuite と Salesforce 間の連絡先の同期など、ビジネスアプリケーション間でデータセットを同期する。 - フラットファイル (CSV) から Hadoop へのデータのアップロードなど、対象システムへの情報の抽出、変換、および読み込み (ETL) を行う。 - API から従来のシステムへの大量の受信データを処理する。 例については​[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-filters-and-batch-aggregator) and [Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-error-handling-faq)​を参照してください。 ## [](#アーキテクチャ)アーキテクチャ Mule バッチ処理コンポーネントでは、レコードを一括で処理できるように準備し、これらのレコードでプロセッサーを実行して、処理の結果に関するレポートを発行します。レコードの準備とレポートは Batch Job コンポーネント内で行われます。処理は 1 つ以上の Batch Step コンポーネント内で行われ、必要に応じて、Batch Step コンポーネント内の Batch Aggregator コンポーネント内で行われます。 ![バッチコンポーネントとプロセッサーが含まれる Mule フロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-batch-job-overview.png) バッチ処理コンポーネント内に配置したプロセッサーはレコードに対するアクションを実行します。各レコードは Mule イベントに似ています。プロセッサーは ​`payload`​ キーワードを使用して各レコードのペイロードへのアクセス、変更、ルーティングを行うことができ、​`vars`​ を使用して Mule 変数を操作できます。ただし、Batch Job コンポーネントへの入力から Mule 属性 (​`attributes`​) へのアクセスや変更を行うことは​_できません_​。 次の例は、バッチ処理を実行し、その処理の結果が記載されたレポートを返す Mule フローの XML 構造の概要を示しています。 ```xml (1) (2) (3) (4) (5) (6) (7) (8) ``` 例に含まれる ​``​ などのさまざまな ​`placeholder`​ エントリはコネクタ操作、Mule コアコンポーネントなど、Mule メッセージ、レコード、バッチ処理レポートを処理する実際のプロセッサーの場所を示している点に注意してください。これらは​_実際のプロセッサーではありません_​。 1. Mule イベントソースにより Mule フローがトリガーされます。一般的なイベントソースには HTTP 用 Anypoint Connector (HTTP Connector)、Scheduler コンポーネント、新しいファイルをポーリングするコネクタ操作からの HTTP リスナーなどのリスナーがあります。 2. Batch Job コンポーネントのアップストリームに配置されたプロセッサーは通常コンシュームする Batch Job コンポーネントメッセージを取得し、必要に応じてこのメッセージを準備します。たとえば、HTTP 要求操作では処理するデータを取得する場合があり、Transform Message コンポーネントの DataWeave スクリプトではデータを受信する Batch Job コンポーネントにとって​[有効な形式](#valid_input)​に変換する場合があります。 3. Batch Job コンポーネントでフローのアップストリームプロセッサーからメッセージを受信すると、​[Load and Dispatch フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases#phase_load_dispatch)​が開始されます。このフェーズでは、コンポーネントでレコードとして処理するための入力が準備されます。これには処理が行われる Batch Job インスタンスの作成などがあります。 4. Batch Job インスタンスは、Batch Job インスタンスが ​``​ に達した時点で実行されます。この時点で、​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases#phase_process)​が開始されます。すべてのレコード処理はこのフェーズ中に行われます。 5. 各 Batch Step コンポーネントには、レコードに対してその中に含まれるデータを変換、転送、強化、または変更する 1 つ以上のプロセッサーが含まれます。たとえば、処理したレコードを 1 つずつ外部サーバーに渡すようにコネクタ操作を設定する場合があります。 6. Batch Aggregator コンポーネントは省略可能です。Batch Step コンポーネントに追加できるのは 1 つのみです。Batch Aggregator 内の最初のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。バッチ集計は処理したレコードの配列を外部サーバーに読み込む場合に便利です。他のプロセッサーでレコードを 1 つずつ処理できるように、For Each など、配列に対して反復処理を行うコンポーネントを使用することもできます。Batch Aggregator コンポーネントには、レコードの処理方法を示す ​[`streaming`​ または ​`size`](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-reference#ref_batch_aggregator_component)​ 設定が必要です。 7. 追加の Batch Step コンポーネントは省略可能です。この例には、Batch Aggregator コンポーネントは含まれません。 8. レコードがすべての Batch Step コンポーネントを通過したら、Mule で Batch Job インスタンスが完了され、処理中に成功したレコードと失敗したレコードを示す結果がオブジェクトで報告されます。​``​ 内の Logger などのプロセッサーを使用して結果を取得または記録できます。 Batch Job コンポーネントではレコードが ​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases#phase_on_complete)​でコンシュームされます。このフェーズは Batch Job インスタンスのすべてのレコード処理が完了した後に発生し、処理したレコードは Batch Job コンポーネントの外側の外部コンポーネントに伝播されません。ただし、多くの Mule コンポーネントと同じように、Batch Job コンポーネントにより、Batch Job の外側のダウンストリームコンポーネントで Batch Job コンポーネントが受け取る​_事前に処理されたペイロード_​にアクセスするために使用する​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-reference#ref_batch_job_component)​ (​`target`​) プロパティを設定できます。 詳細は、[Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases)を参照してください。 ## [](#valid_input)Batch Job コンポーネントに対する有効な入力 フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Mule メッセージ入力に対する暗黙的な分割操作が実行されます。この操作では、Java イテラブル、イテレーター、配列のほか、JSON ペイロードと XML ペイロードを受け入れます。このコンポーネントでは他のデータ形式を分割できません。 分割プロセスとの互換性がないデータ形式を使用する場合は、Batch Job コンポーネントに入る前にペイロードをサポートされる形式に変換してください。 ## [](#variable_propagation)Mule 変数の伝播 Batch Job インスタンスの各レコードは、Batch Job コンポーネントへの入力から Mule イベント変数を継承します。これらの変数の値は Process フェーズ中に実行される Batch Step コンポーネントおよび Batch Aggregator コンポーネントでアクセスして変更でき、これらのコンポーネント内で新しい変数を作成できます。このフェーズ内の各レコードについて、変数 (およびこれらの変数に対する変更) は Batch Job コンポーネント内の各 Batch Step コンポーネントおよび Aggregator コンポーネントを通じて伝播されます。たとえば、レコード R1 で Mule 変数 ​`varName`​ を ​`"hello"`​ に設定し、レコード R2 で ​`varName`​ を ​`"world"`​ に設定して、レコード R3 でこの変数を設定しない場合、次の Batch Step コンポーネント R1 には値 ​`"hello"`​ が表示され、R2 には値 ​`"world"`​ が表示されて、R3 はその変数について ​`null`​ を返します。 似たようなシナリオで、​`varName`​ が Batch Job コンポーネントの​_前_​のフローで設定され、レコード 3 (R3) で ​`varName`​ の値が変更されない場合、R3 はその値を継承します。この点について説明するために、Mule フローが Batch Job コンポーネントに配列 ​`[1,2,3,4]`​ の ​`payload`​ および値が ​`"my variable before batch job"`​ の Mule 変数 ​`varName`​ を送信するとします。次の例では、Choice ルーター (​`choice`​) を使用して最初と 2 番目のレコードで ​`varName`​ の新しい値を設定していますが、3 番目のレコードでは設定していません。後続のレコードでも新しい ​`varName`​ 値を設定しています。 ```xml ``` ログでは Batch Job インスタンスの次のメッセージが出力されます (読みやすいように編集済み)。 ```logs ... INFO ...PRINT VARIABLE BEFORE BATCH: "my variable before batch job" ... INFO ...PRINT VARIABLE VALUES AFTER BATCH JOB: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 1 INFO ...R1: PRINT VARIABLE for PAYLOAD is 1: "hello" INFO ...PRINT RECORD NUMBER: 2 INFO ...R2: PRINT VARIABLE for PAYLOAD is 2: "world" INFO ...PRINT RECORD NUMBER: 3 INFO ...R3: PRINT VARIABLE for PAYLOAD is 3: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 4 INFO ...Rn: PRINT DEFAULT VARIABLE: "some other value" ... INFO ...PRINT VARIABLES IN SECOND STEP: {payload 1="hello"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 2="world"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 3="my variable before batch job"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 4="some other value"} ... ``` 3 番目のレコード (R3) が Batch Job コンポーネントの前で設定された ​`varName`​ の値を継承している点に注意してください。R3 より後のレコードでは変数を ​`"some other value"`​ に設定しています。2 番目の Batch Step に記録されたレコードは最初の Batch Step から変数の値を継承しています。Batch Job インスタンスが処理を完了する​_前_​に非同期で処理される Batch Job コンポーネントの​_後_​の Logger は、Batch Job が実行される​_前_​の ​`varName`​ の値である ​`"my variable before batch job"`​ も受け取ります。 [Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases#phase_process)​中に Mule 変数を変更または追加しても、​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases#phase_on_complete)​には伝播されません。Batch Job コンポーネントへのトリガーイベントから継承された変数のみが On Complete フェーズに伝播され、​`batchJobInstanceId`​ など、Batch Job レポートに含まれる標準変数はこのフェーズでも表示されます。On Complete フェーズでは、このフェーズの最後までは保持されるが On Complete が終了した後は保持されない変数を作成できます。 たとえば、On Complete フェーズで新しい変数 (​`myOnCompleteVar`​) を設定し、このフェーズで見つかったすべての変数 (​`vars`​) を記録するとします。 ```xml ``` On Complete レポートには、たとえば次のように Batch Job インスタンスで最終的に設定される変数が表示されます。 INFO ... PRINT ON COMPLETE VARIABLES: { varName=TypedValue\[value: '"my variable before batch job"', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\], batchJobInstanceId=TypedValue\[value: '869ae510-5c84-11ed-bc38-147ddaaf4f97', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*'}'\], myOnCompleteVar=TypedValue\[value: 'Hello On Complete Variable', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\]} レポートオブジェクトの変数の例は以下に従います。 - `varName`​ は Batch Job コンポーネントに達する前に作成された変数の例です。この変数には、コンポーネントに入ったときの値が保持されます。Process フェーズ中に値を変更しても、On Complete フェーズでは保持されません。 - `batchJobInstanceId`​ は Batch Job インスタンスを識別する標準変数です。 - `myOnCompleteVar`​ は On Complete フェーズ内で作成された変数の例です。レポートには表示されますが、On Complete フェーズの終了後は保持されません。 Batch Job コンポーネントからのダウンロードストリームでは、​`varName`​ のみが保持されます。レコードやその属性と同じように、レコードの変数は Batch Job コンポーネント内で完全にコンシュームされます。Batch Job インスタンスはフローの残りの部分から非同期で実行されるため、Process フェーズまたは On Complete フェーズ内で作成された変数は Batch Job コンポーネント外で保持されません。 ## [](#エラー処理)エラー処理 Batch Job 全体の失敗を防止するために、Batch Job コンポーネントではレコードレベルで発生する失敗を処理できます。また、バッチ処理中に Mule が変数に従って Batch Job インスタンス内のレコードの転送またはアクションを実行できるように、個々のレコードの変数を設定または削除できます。詳細は、​[「Batch Job 中のエラー処理」](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-error-handling-faq)​を参照してください。 ## [](#関連情報)関連情報 - [Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-phases) - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-filters-and-batch-aggregator) - [バッチ処理の調整](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-batch-processing) - [トランザクションによるコンポーネントとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management#tx_components_routers) - [バッチモジュールの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-core-batch) - [バッチジョブが含まれるアプリケーションの永続的なキュー](https://docs.mulesoft.com/cloudhub/cloudhub-fabric#persistent-queues-for-applications-containing-batch-jobs.adoc) # バッチ処理 Mule Runtime Engine (Mule) では、メッセージをバッチ処理できます。バッチジョブは、アプリケーション内で開始できます。これは、大きなメッセージを個々のレコードに分割し、各レコードに対してアクションを実行してから、結果を報告し、場合によっては処理された出力を他のシステムまたはキューに転送するコードブロックです。 100 万件のレコードであっても、バッチアプリケーションなら 3 つのステップで処理できるのです。Mule ジョブのフェーズを移動しながら各レコードを処理している間には、いくつかの I/O 操作が発生します。バッチジョブのパフォーマンスは、ディスクの特性とワークロードのサイズに大きく左右されます。特に入力フェーズでは、ディスク上にキューが作成され、処理するレコードが登録されます。このキューはフローによって継続的に読み書きされるため、I/O 負荷が大きくなります。 さらにバッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 ## [](#batch-block-size-バッチブロックサイズ)Batch Block Size (バッチブロックサイズ) デフォルトでは、バッチブロックサイズは 100 に設定されています。さまざまなレコードサイズで代表的なバッチのユースケースを分析した結果、このサイズが最もパフォーマンスとワーキングメモリ要件のバランスが取れていることが判明しています。ただし、各アプリケーションの最適な値は、ユースケースによって異なります。 このプロパティは、バッチジョブごとに設定できます。特定のユースケースでカスタムサイズが最適であると思われる場合は、いろいろなサイズで比較テストを実行して、ユースケースに最適なサイズを見つけてください。次の例にバッチブロックサイズを示します。 ```xml ``` ## [](#max-concurrency-最大同時実行)Max Concurrency (最大同時実行) Batch スコープ内の処理に使用されるスレッドの最大数は、デフォルトで JVM で検出されるコア数の 2 倍になります。CloudHub や Anypoint Runtime Fabric のような断片的コアデプロイメントの場合、JVM では​_非断片的_​コア数が検出されます。自動設定された同時実行設定を手動で増減できます。Max Concurrency (最大同時実行) 設定には、それを上回るスレッドを保証するにはレコード数が足りない場合などに、バッチジョブインスタンスに使用するスレッドの上限数を設定できます。 次の例では、自動設定された ​`maxConcurrency`​ (デフォルトでプロパティから読み込まれた設定になる) を上書きします。 ```xml ``` ## [](#batch-aggregator)Batch Aggregator スレッドが 1 つか複数かに関係なく、100 万回ネットワークを往復すればネットワークに影響を与えます。SaaS システムとの通信ではすぐに API コールのクォータがコンシュームされることがあります。レコードを 1 件ずつ処理するのではなく、Batch Aggregator スコープを使用し、レコードの配列に対して一括操作を実行することでパフォーマンスを改善できます。このスコープではアグリゲーターのサイズ設定を使用して各配列のレコード数を制限します。 1 つのレコード配列で処理するレコード数を決定するときには、通信に使用するシステムの操作で許可される最大レコード数を考慮する必要があります。アグリゲーターのサイズ設定と​_それより小さい値_​でパフォーマンステストを実施することが重要です。ロジックは設定値以下のどのレコード数でも処理する必要があります。システムが受信するレコードの数が指定値よりも少ない可能性があるからです。たとえば、120 レコードがあり、アグリゲーターのサイズ設定が 50 の場合、最後の送信は 20 レコードになります。 次の例は、Batch Aggregator スコープが固定サイズの ​`50`​ に設定された Batch Step スコープを示します。 ```xml ``` アグリゲーターにデータのストリーミング操作が含まれる場合、アグリゲーターのサイズ設定 (​`streaming="true"`​) を使用する代わりにスコープのストリーミングオプション (​`size="50"`​) をアクティブ化できます。 ## [](#batch-job-の複数同時インスタンス)Batch Job の複数同時インスタンス Batch Job スコープの多くのユースケースでは一度に 1 つの要求 (バッチジョブインスタンス) のみを処理しますが、同時に複数のバッチジョブインスタンスを実行するケースもあります。そうしたケースのスレッドプール共有をチューニングするために、次のいずれかのスケジュール戦略を設定できます。各戦略はバッチインスタンス ID で別個に追跡されます。 - `ORDERED_SEQUENTIAL`​: インスタンスをトリガーされた順に処理することで同時インスタンスの影響を制限するデフォルトのスケジュール戦略。この戦略は、同じバッチジョブを順不同で処理するとデータの不整合などの問題が発生したり、リソース制限に達したりする可能性がある場合に便利です。 - `ROUND_ROBIN`​: スレッドを「インフライト」のバッチジョブインスタンスと共有するスケジュール戦略です。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.8/batch-processing-concept) # バッチ処理 Mule バッチ処理コンポーネントは、メモリ量を上回るデータセットの信頼できる非同期処理を行うよう設計されています。コンポーネントには Batch Job、Batch Step、Batch Aggregator があります。Batch Job コンポーネントではソースデータを自動的に分割して永続的なキューに格納するため、大量のデータセットを処理しながら信頼性を提供できます。アプリケーションを再デプロイする場合、または Mule がクラッシュした場合、ジョブが停止した位置でジョブの実行を再開できます。

Mule バッチ処理コンポーネントは Mule の Enterprise Edition (EE) バージョン専用です。オープンソースの Mule Kernel を通じてコンポーネントを使用することはできません。

Mule 3.x でのバッチ処理に慣れている場合は、Mule 4.x でのバッチ処理の違いの概要について​「Batch Module の移行」​を参照してください。
バッチ処理の一般的なユースケースを次に挙げます。 - NetSuite と Salesforce 間の連絡先の同期など、ビジネスアプリケーション間でデータセットを同期する。 - フラットファイル (CSV) から Hadoop へのデータのアップロードなど、対象システムへの情報の抽出、変換、および読み込み (ETL) を行う。 - API から従来のシステムへの大量の受信データを処理する。 例については​[Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-filters-and-batch-aggregator) and [Batch Job 中のエラー処理](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-error-handling-faq)​を参照してください。 ## [](#アーキテクチャ)アーキテクチャ Mule バッチ処理コンポーネントでは、レコードを一括で処理できるように準備し、これらのレコードでプロセッサーを実行して、処理の結果に関するレポートを発行します。レコードの準備とレポートは Batch Job コンポーネント内で行われます。処理は 1 つ以上の Batch Step コンポーネント内で行われ、必要に応じて、Batch Step コンポーネント内の Batch Aggregator コンポーネント内で行われます。 ![バッチコンポーネントとプロセッサーが含まれる Mule フロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-batch-job-overview.png) バッチ処理コンポーネント内に配置したプロセッサーはレコードに対するアクションを実行します。各レコードは Mule イベントに似ています。プロセッサーは ​`payload`​ キーワードを使用して各レコードのペイロードへのアクセス、変更、ルーティングを行うことができ、​`vars`​ を使用して Mule 変数を操作できます。ただし、Batch Job コンポーネントへの入力から Mule 属性 (​`attributes`​) へのアクセスや変更を行うことは​_できません_​。 次の例は、バッチ処理を実行し、その処理の結果が記載されたレポートを返す Mule フローの XML 構造の概要を示しています。 ```xml (1) (2) (3) (4) (5) (6) (7) (8) ``` 例に含まれる ​``​ などのさまざまな ​`placeholder`​ エントリはコネクタ操作、Mule コアコンポーネントなど、Mule メッセージ、レコード、バッチ処理レポートを処理する実際のプロセッサーの場所を示している点に注意してください。これらは​_実際のプロセッサーではありません_​。 1. Mule イベントソースにより Mule フローがトリガーされます。一般的なイベントソースには HTTP 用 Anypoint Connector (HTTP Connector)、Scheduler コンポーネント、新しいファイルをポーリングするコネクタ操作からの HTTP リスナーなどのリスナーがあります。 2. Batch Job コンポーネントのアップストリームに配置されたプロセッサーは通常コンシュームする Batch Job コンポーネントメッセージを取得し、必要に応じてこのメッセージを準備します。たとえば、HTTP 要求操作では処理するデータを取得する場合があり、Transform Message コンポーネントの DataWeave スクリプトではデータを受信する Batch Job コンポーネントにとって​[有効な形式](#valid_input)​に変換する場合があります。 3. Batch Job コンポーネントでフローのアップストリームプロセッサーからメッセージを受信すると、​[Load and Dispatch フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases#phase_load_dispatch)​が開始されます。このフェーズでは、コンポーネントでレコードとして処理するための入力が準備されます。これには処理が行われる Batch Job インスタンスの作成などがあります。 4. Batch Job インスタンスは、Batch Job インスタンスが ​``​ に達した時点で実行されます。この時点で、​[Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases#phase_process)​が開始されます。すべてのレコード処理はこのフェーズ中に行われます。 5. 各 Batch Step コンポーネントには、レコードに対してその中に含まれるデータを変換、転送、強化、または変更する 1 つ以上のプロセッサーが含まれます。たとえば、処理したレコードを 1 つずつ外部サーバーに渡すようにコネクタ操作を設定する場合があります。 6. Batch Aggregator コンポーネントは省略可能です。Batch Step コンポーネントに追加できるのは 1 つのみです。Batch Aggregator 内の最初のプロセッサーは入力としてレコードの配列を受け入れることができる必要があります。バッチ集計は処理したレコードの配列を外部サーバーに読み込む場合に便利です。他のプロセッサーでレコードを 1 つずつ処理できるように、For Each など、配列に対して反復処理を行うコンポーネントを使用することもできます。Batch Aggregator コンポーネントには、レコードの処理方法を示す ​[`streaming`​ または ​`size`](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-reference#ref_batch_aggregator_component)​ 設定が必要です。 7. 追加の Batch Step コンポーネントは省略可能です。この例には、Batch Aggregator コンポーネントは含まれません。 8. レコードがすべての Batch Step コンポーネントを通過したら、Mule で Batch Job インスタンスが完了され、処理中に成功したレコードと失敗したレコードを示す結果がオブジェクトで報告されます。​``​ 内の Logger などのプロセッサーを使用して結果を取得または記録できます。 Batch Job コンポーネントではレコードが ​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases#phase_on_complete)​でコンシュームされます。このフェーズは Batch Job インスタンスのすべてのレコード処理が完了した後に発生し、処理したレコードは Batch Job コンポーネントの外側の外部コンポーネントに伝播されません。ただし、多くの Mule コンポーネントと同じように、Batch Job コンポーネントにより、Batch Job の外側のダウンストリームコンポーネントで Batch Job コンポーネントが受け取る​_事前に処理されたペイロード_​にアクセスするために使用する​[対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-reference#ref_batch_job_component)​ (​`target`​) プロパティを設定できます。 詳細は、[Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases)を参照してください。 ## [](#valid_input)Batch Job コンポーネントに対する有効な入力 フローのアップストリームイベントによって Batch Job コンポーネントがトリガーされると、Mule メッセージ入力に対する暗黙的な分割操作が実行されます。この操作では、Java イテラブル、イテレーター、配列のほか、JSON ペイロードと XML ペイロードを受け入れます。このコンポーネントでは他のデータ形式を分割できません。 分割プロセスとの互換性がないデータ形式を使用する場合は、Batch Job コンポーネントに入る前にペイロードをサポートされる形式に変換してください。 ## [](#variable_propagation)Mule 変数の伝播 Batch Job インスタンスの各レコードは、Batch Job コンポーネントへの入力から Mule イベント変数を継承します。これらの変数の値は Process フェーズ中に実行される Batch Step コンポーネントおよび Batch Aggregator コンポーネントでアクセスして変更でき、これらのコンポーネント内で新しい変数を作成できます。このフェーズ内の各レコードについて、変数 (およびこれらの変数に対する変更) は Batch Job コンポーネント内の各 Batch Step コンポーネントおよび Aggregator コンポーネントを通じて伝播されます。たとえば、レコード R1 で Mule 変数 ​`varName`​ を ​`"hello"`​ に設定し、レコード R2 で ​`varName`​ を ​`"world"`​ に設定して、レコード R3 でこの変数を設定しない場合、次の Batch Step コンポーネント R1 には値 ​`"hello"`​ が表示され、R2 には値 ​`"world"`​ が表示されて、R3 はその変数について ​`null`​ を返します。 似たようなシナリオで、​`varName`​ が Batch Job コンポーネントの​_前_​のフローで設定され、レコード 3 (R3) で ​`varName`​ の値が変更されない場合、R3 はその値を継承します。この点について説明するために、Mule フローが Batch Job コンポーネントに配列 ​`[1,2,3,4]`​ の ​`payload`​ および値が ​`"my variable before batch job"`​ の Mule 変数 ​`varName`​ を送信するとします。次の例では、Choice ルーター (​`choice`​) を使用して最初と 2 番目のレコードで ​`varName`​ の新しい値を設定していますが、3 番目のレコードでは設定していません。後続のレコードでも新しい ​`varName`​ 値を設定しています。 ```xml ``` ログでは Batch Job インスタンスの次のメッセージが出力されます (読みやすいように編集済み)。 ```logs ... INFO ...PRINT VARIABLE BEFORE BATCH: "my variable before batch job" ... INFO ...PRINT VARIABLE VALUES AFTER BATCH JOB: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 1 INFO ...R1: PRINT VARIABLE for PAYLOAD is 1: "hello" INFO ...PRINT RECORD NUMBER: 2 INFO ...R2: PRINT VARIABLE for PAYLOAD is 2: "world" INFO ...PRINT RECORD NUMBER: 3 INFO ...R3: PRINT VARIABLE for PAYLOAD is 3: "my variable before batch job" INFO ...PRINT RECORD NUMBER: 4 INFO ...Rn: PRINT DEFAULT VARIABLE: "some other value" ... INFO ...PRINT VARIABLES IN SECOND STEP: {payload 1="hello"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 2="world"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 3="my variable before batch job"} INFO ...PRINT VARIABLES IN SECOND STEP: {payload 4="some other value"} ... ``` 3 番目のレコード (R3) が Batch Job コンポーネントの前で設定された ​`varName`​ の値を継承している点に注意してください。R3 より後のレコードでは変数を ​`"some other value"`​ に設定しています。2 番目の Batch Step に記録されたレコードは最初の Batch Step から変数の値を継承しています。Batch Job インスタンスが処理を完了する​_前_​に非同期で処理される Batch Job コンポーネントの​_後_​の Logger は、Batch Job が実行される​_前_​の ​`varName`​ の値である ​`"my variable before batch job"`​ も受け取ります。 [Process フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases#phase_process)​中に Mule 変数を変更または追加しても、​[On Complete フェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases#phase_on_complete)​には伝播されません。Batch Job コンポーネントへのトリガーイベントから継承された変数のみが On Complete フェーズに伝播され、​`batchJobInstanceId`​ など、Batch Job レポートに含まれる標準変数はこのフェーズでも表示されます。On Complete フェーズでは、このフェーズの最後までは保持されるが On Complete が終了した後は保持されない変数を作成できます。 たとえば、On Complete フェーズで新しい変数 (​`myOnCompleteVar`​) を設定し、このフェーズで見つかったすべての変数 (​`vars`​) を記録するとします。 ```xml ``` On Complete レポートには、たとえば次のように Batch Job インスタンスで最終的に設定される変数が表示されます。 INFO ... PRINT ON COMPLETE VARIABLES: { varName=TypedValue\[value: '"my variable before batch job"', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\], batchJobInstanceId=TypedValue\[value: '869ae510-5c84-11ed-bc38-147ddaaf4f97', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*'}'\], myOnCompleteVar=TypedValue\[value: 'Hello On Complete Variable', dataType: 'SimpleDataType{type=java.lang.String, mimeType='\*/\*; charset=UTF-8'}'\]} レポートオブジェクトの変数の例は以下に従います。 - `varName`​ は Batch Job コンポーネントに達する前に作成された変数の例です。この変数には、コンポーネントに入ったときの値が保持されます。Process フェーズ中に値を変更しても、On Complete フェーズでは保持されません。 - `batchJobInstanceId`​ は Batch Job インスタンスを識別する標準変数です。 - `myOnCompleteVar`​ は On Complete フェーズ内で作成された変数の例です。レポートには表示されますが、On Complete フェーズの終了後は保持されません。 Batch Job コンポーネントからのダウンロードストリームでは、​`varName`​ のみが保持されます。レコードやその属性と同じように、レコードの変数は Batch Job コンポーネント内で完全にコンシュームされます。Batch Job インスタンスはフローの残りの部分から非同期で実行されるため、Process フェーズまたは On Complete フェーズ内で作成された変数は Batch Job コンポーネント外で保持されません。 ## [](#エラー処理)エラー処理 Batch Job 全体の失敗を防止するために、Batch Job コンポーネントではレコードレベルで発生する失敗を処理できます。また、バッチ処理中に Mule が変数に従って Batch Job インスタンス内のレコードの転送またはアクションを実行できるように、個々のレコードの変数を設定または削除できます。詳細は、​[「Batch Job 中のエラー処理」](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-error-handling-faq)​を参照してください。 ## [](#関連情報)関連情報 - [Batch Job のフェーズ](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-phases) - [Batch コンポーネントの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-filters-and-batch-aggregator) - [バッチ処理の調整](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-batch-processing) - [トランザクションによるコンポーネントとルーターへの影響](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management#tx_components_routers) - [バッチモジュールの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-core-batch) - [バッチジョブが含まれるアプリケーションの永続的なキュー](https://docs.mulesoft.com/cloudhub/cloudhub-fabric#persistent-queues-for-applications-containing-batch-jobs.adoc) # バッチ処理 Mule Runtime Engine (Mule) では、メッセージをバッチ処理できます。バッチジョブは、アプリケーション内で開始できます。これは、大きなメッセージを個々のレコードに分割し、各レコードに対してアクションを実行してから、結果を報告し、場合によっては処理された出力を他のシステムまたはキューに転送するコードブロックです。 100 万件のレコードであっても、バッチアプリケーションなら 3 つのステップで処理できるのです。Mule ジョブのフェーズを移動しながら各レコードを処理している間には、いくつかの I/O 操作が発生します。バッチジョブのパフォーマンスは、ディスクの特性とワークロードのサイズに大きく左右されます。特に入力フェーズでは、ディスク上にキューが作成され、処理するレコードが登録されます。このキューはフローによって継続的に読み書きされるため、I/O 負荷が大きくなります。 さらにバッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。レコードとその数量が大きいほど、バッチ処理に必要な使用可能メモリが多くなります。 ## [](#batch-block-size-バッチブロックサイズ)Batch Block Size (バッチブロックサイズ) デフォルトでは、バッチブロックサイズは 100 に設定されています。さまざまなレコードサイズで代表的なバッチのユースケースを分析した結果、このサイズが最もパフォーマンスとワーキングメモリ要件のバランスが取れていることが判明しています。ただし、各アプリケーションの最適な値は、ユースケースによって異なります。 このプロパティは、バッチジョブごとに設定できます。特定のユースケースでカスタムサイズが最適であると思われる場合は、いろいろなサイズで比較テストを実行して、ユースケースに最適なサイズを見つけてください。次の例にバッチブロックサイズを示します。 ```xml ``` ## [](#max-concurrency-最大同時実行)Max Concurrency (最大同時実行) Batch スコープ内の処理に使用されるスレッドの最大数は、デフォルトで JVM で検出されるコア数の 2 倍になります。CloudHub や Anypoint Runtime Fabric のような断片的コアデプロイメントの場合、JVM では​_非断片的_​コア数が検出されます。自動設定された同時実行設定を手動で増減できます。Max Concurrency (最大同時実行) 設定には、それを上回るスレッドを保証するにはレコード数が足りない場合などに、バッチジョブインスタンスに使用するスレッドの上限数を設定できます。 次の例では、自動設定された ​`maxConcurrency`​ (デフォルトでプロパティから読み込まれた設定になる) を上書きします。 ```xml ``` ## [](#batch-aggregator)Batch Aggregator スレッドが 1 つか複数かに関係なく、100 万回ネットワークを往復すればネットワークに影響を与えます。SaaS システムとの通信ではすぐに API コールのクォータがコンシュームされることがあります。レコードを 1 件ずつ処理するのではなく、Batch Aggregator スコープを使用し、レコードの配列に対して一括操作を実行することでパフォーマンスを改善できます。このスコープではアグリゲーターのサイズ設定を使用して各配列のレコード数を制限します。 1 つのレコード配列で処理するレコード数を決定するときには、通信に使用するシステムの操作で許可される最大レコード数を考慮する必要があります。アグリゲーターのサイズ設定と​_それより小さい値_​でパフォーマンステストを実施することが重要です。ロジックは設定値以下のどのレコード数でも処理する必要があります。システムが受信するレコードの数が指定値よりも少ない可能性があるからです。たとえば、120 レコードがあり、アグリゲーターのサイズ設定が 50 の場合、最後の送信は 20 レコードになります。 次の例は、Batch Aggregator スコープが固定サイズの ​`50`​ に設定された Batch Step スコープを示します。 ```xml ``` アグリゲーターにデータのストリーミング操作が含まれる場合、アグリゲーターのサイズ設定 (​`streaming="true"`​) を使用する代わりにスコープのストリーミングオプション (​`size="50"`​) をアクティブ化できます。 ## [](#batch-job-の複数同時インスタンス)Batch Job の複数同時インスタンス Batch Job スコープの多くのユースケースでは一度に 1 つの要求 (バッチジョブインスタンス) のみを処理しますが、同時に複数のバッチジョブインスタンスを実行するケースもあります。そうしたケースのスレッドプール共有をチューニングするために、次のいずれかのスケジュール戦略を設定できます。各戦略はバッチインスタンス ID で別個に追跡されます。 - `ORDERED_SEQUENTIAL`​: インスタンスをトリガーされた順に処理することで同時インスタンスの影響を制限するデフォルトのスケジュール戦略。この戦略は、同じバッチジョブを順不同で処理するとデータの不整合などの問題が発生したり、リソース制限に達したりする可能性がある場合に便利です。 - `ROUND_ROBIN`​: スレッドを「インフライト」のバッチジョブインスタンスと共有するスケジュール戦略です。 ## [](#関連情報)関連情報 - [バッチ処理](https://docs.mulesoft.com/jp/mule-runtime/4.9/batch-processing-concept) # パフォーマンスチューニングガイド Mule アプリケーションから最適なパフォーマンスを引き出すには、アプリケーション自身と、アプリケーションが実行される環境の両方を評価する必要があります。Mule 4 は自身でチューニングできるように設計されていますが、初期の構成や連動関係によってパフォーマンスの問題が発生することがあります。 同様に、オンプレミスのインストールでは、Mule アプリケーションが環境をフルに活用できるように、環境自身のチューニングが必要な場合もあります。パフォーマンスは多くの変動要素の影響を受けるため、アプリケーションを最適な状態にチューニングするには、ある程度の試行錯誤が必要です。 ドキュメントに記載されているベストプラクティスを実施して、理想的なテスト環境でアプリケーションをテストするだけでパフォーマンスをチューニングすることもできます。 以下の推奨事項は、開発チームとサービスエンジニアリングチームから、そして MuleSoft パフォーマンスエンジニアリングチームによるベンチマークテストの結果として得られたものです。 ## [](#パフォーマンスチューニングサマリー)パフォーマンスチューニングサマリー Mule アプリケーションのパフォーマンスを最適化するには、以下のアクションが必要です。 - アプリケーションレベルでチューニングの推奨事項を適用する 詳細は​[「パフォーマンスチューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-recommendations)​を参照してください。 - テストを実施する前にチューニングの前提条件とベストプラクティスを考慮する 詳細は​[「パフォーマンステスト検証」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-test-validations)​を参照してください。 - テスト中にパフォーマンスを監視して、Mule Runtime Engine (Mule) が必要とするリソースを決定する 詳細は​[「パフォーマンス監視」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-monitoring)​を参照してください。 # パフォーマンスチューニングガイド Mule アプリケーションから最適なパフォーマンスを引き出すには、アプリケーション自身と、アプリケーションが実行される環境の両方を評価する必要があります。Mule 4 は自身でチューニングできるように設計されていますが、初期の構成や連動関係によってパフォーマンスの問題が発生することがあります。 同様に、オンプレミスのインストールでは、Mule アプリケーションが環境をフルに活用できるように、環境自身のチューニングが必要な場合もあります。パフォーマンスは多くの変動要素の影響を受けるため、アプリケーションを最適な状態にチューニングするには、ある程度の試行錯誤が必要です。 ドキュメントに記載されているベストプラクティスを実施して、理想的なテスト環境でアプリケーションをテストするだけでパフォーマンスをチューニングすることもできます。 以下の推奨事項は、開発チームとサービスエンジニアリングチームから、そして MuleSoft パフォーマンスエンジニアリングチームによるベンチマークテストの結果として得られたものです。 ## [](#パフォーマンスチューニングサマリー)パフォーマンスチューニングサマリー Mule アプリケーションのパフォーマンスを最適化するには、以下のアクションが必要です。 - アプリケーションレベルでチューニングの推奨事項を適用する 詳細は​[「パフォーマンスチューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-recommendations)​を参照してください。 - テストを実施する前にチューニングの前提条件とベストプラクティスを考慮する 詳細は​[「パフォーマンステスト検証」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-test-validations)​を参照してください。 - テスト中にパフォーマンスを監視して、Mule Runtime Engine (Mule) が必要とするリソースを決定する 詳細は​[「パフォーマンス監視」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-monitoring)​を参照してください。 # パフォーマンスチューニングガイド Mule アプリケーションから最適なパフォーマンスを引き出すには、アプリケーション自身と、アプリケーションが実行される環境の両方を評価する必要があります。Mule 4 は自身でチューニングできるように設計されていますが、初期の構成や連動関係によってパフォーマンスの問題が発生することがあります。 同様に、オンプレミスのインストールでは、Mule アプリケーションが環境をフルに活用できるように、環境自身のチューニングが必要な場合もあります。パフォーマンスは多くの変動要素の影響を受けるため、アプリケーションを最適な状態にチューニングするには、ある程度の試行錯誤が必要です。 ドキュメントに記載されているベストプラクティスを実施して、理想的なテスト環境でアプリケーションをテストするだけでパフォーマンスをチューニングすることもできます。 以下の推奨事項は、開発チームとサービスエンジニアリングチームから、そして MuleSoft パフォーマンスエンジニアリングチームによるベンチマークテストの結果として得られたものです。 ## [](#パフォーマンスチューニングサマリー)パフォーマンスチューニングサマリー Mule アプリケーションのパフォーマンスを最適化するには、以下のアクションが必要です。 - アプリケーションレベルでチューニングの推奨事項を適用する 詳細は​[「パフォーマンスチューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-recommendations)​を参照してください。 - テストを実施する前にチューニングの前提条件とベストプラクティスを考慮する 詳細は​[「パフォーマンステスト検証」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-test-validations)​を参照してください。 - テスト中にパフォーマンスを監視して、Mule Runtime Engine (Mule) が必要とするリソースを決定する 詳細は​[「パフォーマンス監視」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-monitoring)​を参照してください。 # パフォーマンスチューニングガイド Mule アプリケーションから最適なパフォーマンスを引き出すには、アプリケーション自身と、アプリケーションが実行される環境の両方を評価する必要があります。Mule 4 は自身でチューニングできるように設計されていますが、初期の構成や連動関係によってパフォーマンスの問題が発生することがあります。 同様に、オンプレミスのインストールでは、Mule アプリケーションが環境をフルに活用できるように、環境自身のチューニングが必要な場合もあります。パフォーマンスは多くの変動要素の影響を受けるため、アプリケーションを最適な状態にチューニングするには、ある程度の試行錯誤が必要です。 ドキュメントに記載されているベストプラクティスを実施して、理想的なテスト環境でアプリケーションをテストするだけでパフォーマンスをチューニングすることもできます。 以下の推奨事項は、開発チームとサービスエンジニアリングチームから、そして MuleSoft パフォーマンスエンジニアリングチームによるベンチマークテストの結果として得られたものです。 ## [](#パフォーマンスチューニングサマリー)パフォーマンスチューニングサマリー Mule アプリケーションのパフォーマンスを最適化するには、以下のアクションが必要です。 - アプリケーションレベルでチューニングの推奨事項を適用する 詳細は​[「パフォーマンスチューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-recommendations)​を参照してください。 - テストを実施する前にチューニングの前提条件とベストプラクティスを考慮する 詳細は​[「パフォーマンステスト検証」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-test-validations)​を参照してください。 - テスト中にパフォーマンスを監視して、Mule Runtime Engine (Mule) が必要とするリソースを決定する 詳細は​[「パフォーマンス監視」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-monitoring)​を参照してください。 # パフォーマンスチューニングガイド Mule アプリケーションから最適なパフォーマンスを引き出すには、アプリケーション自身と、アプリケーションが実行される環境の両方を評価する必要があります。Mule 4 は自身でチューニングできるように設計されていますが、初期の構成や連動関係によってパフォーマンスの問題が発生することがあります。 同様に、オンプレミスのインストールでは、Mule アプリケーションが環境をフルに活用できるように、環境自身のチューニングが必要な場合もあります。パフォーマンスは多くの変動要素の影響を受けるため、アプリケーションを最適な状態にチューニングするには、ある程度の試行錯誤が必要です。 ドキュメントに記載されているベストプラクティスを実施して、理想的なテスト環境でアプリケーションをテストするだけでパフォーマンスをチューニングすることもできます。 以下の推奨事項は、開発チームとサービスエンジニアリングチームから、そして MuleSoft パフォーマンスエンジニアリングチームによるベンチマークテストの結果として得られたものです。 ## [](#パフォーマンスチューニングサマリー)パフォーマンスチューニングサマリー Mule アプリケーションのパフォーマンスを最適化するには、以下のアクションが必要です。 - アプリケーションレベルでチューニングの推奨事項を適用する 詳細は​[「パフォーマンスチューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-recommendations)​を参照してください。 - テストを実施する前にチューニングの前提条件とベストプラクティスを考慮する 詳細は​[「パフォーマンステスト検証」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-test-validations)​を参照してください。 - テスト中にパフォーマンスを監視して、Mule Runtime Engine (Mule) が必要とするリソースを決定する 詳細は​[「パフォーマンス監視」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-monitoring)​を参照してください。 # パフォーマンスチューニングガイド Mule アプリケーションから最適なパフォーマンスを引き出すには、アプリケーション自身と、アプリケーションが実行される環境の両方を評価する必要があります。Mule 4 は自身でチューニングできるように設計されていますが、初期の構成や連動関係によってパフォーマンスの問題が発生することがあります。 同様に、オンプレミスのインストールでは、Mule アプリケーションが環境をフルに活用できるように、環境自身のチューニングが必要な場合もあります。パフォーマンスは多くの変動要素の影響を受けるため、アプリケーションを最適な状態にチューニングするには、ある程度の試行錯誤が必要です。 ドキュメントに記載されているベストプラクティスを実施して、理想的なテスト環境でアプリケーションをテストするだけでパフォーマンスをチューニングすることもできます。 以下の推奨事項は、開発チームとサービスエンジニアリングチームから、そして MuleSoft パフォーマンスエンジニアリングチームによるベンチマークテストの結果として得られたものです。 ## [](#パフォーマンスチューニングサマリー)パフォーマンスチューニングサマリー Mule アプリケーションのパフォーマンスを最適化するには、以下のアクションが必要です。 - アプリケーションレベルでチューニングの推奨事項を適用する 詳細は​[「パフォーマンスチューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-recommendations)​を参照してください。 - テストを実施する前にチューニングの前提条件とベストプラクティスを考慮する 詳細は​[「パフォーマンステスト検証」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-test-validations)​を参照してください。 - テスト中にパフォーマンスを監視して、Mule Runtime Engine (Mule) が必要とするリソースを決定する 詳細は​[「パフォーマンス監視」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-monitoring)​を参照してください。 # パフォーマンスチューニングガイド Mule アプリケーションから最適なパフォーマンスを引き出すには、アプリケーション自身と、アプリケーションが実行される環境の両方を評価する必要があります。Mule 4 は自身でチューニングできるように設計されていますが、初期の構成や連動関係によってパフォーマンスの問題が発生することがあります。 同様に、オンプレミスのインストールでは、Mule アプリケーションが環境をフルに活用できるように、環境自身のチューニングが必要な場合もあります。パフォーマンスは多くの変動要素の影響を受けるため、アプリケーションを最適な状態にチューニングするには、ある程度の試行錯誤が必要です。 ドキュメントに記載されているベストプラクティスを実施して、理想的なテスト環境でアプリケーションをテストするだけでパフォーマンスをチューニングすることもできます。 以下の推奨事項は、開発チームとサービスエンジニアリングチームから、そして MuleSoft パフォーマンスエンジニアリングチームによるベンチマークテストの結果として得られたものです。 ## [](#パフォーマンスチューニングサマリー)パフォーマンスチューニングサマリー Mule アプリケーションのパフォーマンスを最適化するには、以下のアクションが必要です。 - アプリケーションレベルでチューニングの推奨事項を適用する 詳細は​[「パフォーマンスチューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-recommendations)​を参照してください。 - テストを実施する前にチューニングの前提条件とベストプラクティスを考慮する 詳細は​[「パフォーマンステスト検証」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-test-validations)​を参照してください。 - テスト中にパフォーマンスを監視して、Mule Runtime Engine (Mule) が必要とするリソースを決定する 詳細は​[「パフォーマンス監視」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-monitoring)​を参照してください。 # パフォーマンステスト検証 アプリケーションのパフォーマンスを検証する手順は次のとおりです。 1. テストの前提条件を確認する。 2. ベストプラクティスに従う。 3. パフォーマンステストを実行する。 ## [](#パフォーマンステスト検証の前提条件)パフォーマンステスト検証の前提条件 パフォーマンステストを実行する前に、以下を行ってください。 - Mule アプリケーションとその機能が想定通りに機能することを確認します。フローが正しくないと偽陽性データが生成されることがあります。 - 以下の質問を自問してパフォーマンステストの条件を確立します。 - 平均とピーク時のワークロードは? - ユースケースで対処する必要のある特定のニーズは? - 大量のトランザクションを高優先度で処理する場合のスループット。 - アクティビティの急増がユーザーエクスペリエンスに影響する場合の応答時間またはレイテンシー。 - 多くのユーザーが同時に接続する状況をサポートする必要がある場合の同時実行数。 - アプリケーションが 1 MB を超えるペイロードを転送、キャッシュ、保存、または処理する場合の大規模メッセージの管理。 - 許容できる最小スループットは? - 許容できる最大応答時間は? ## [](#パフォーマンステスト検証のベストプラクティス)パフォーマンステスト検証のベストプラクティス テストのベストプラクティスでは、テスト環境、テストツール、コンポーネントの分離、代表的なワークロードを考慮する必要があります。 ### [](#制御された環境の使用)制御された環境の使用 自己制御された環境を使用して、再現性と信頼性の高い一貫したデータを取得します。 - 3 台の専用ホストで構成されるインフラストラクチャを使用する: - オンプレミステストの場合は、Mule アプリケーション専用のホストを使用してアプリケーション情報を分離することで、他の実行プロセスによる干渉を防止します。 - 実行する負荷クライアントツールがボトルネックとならずに負荷を提供できるように、分離された専用のホストを使用します。 - データベース、Tomcat、JMS、ActiveMQ などのバックエンドサービスを実行するための専用のホストを使用します。本番環境でアプリケーションが使用しているのと同じホストを使用してテストします。 - オンプレミステストの場合は、負荷クライアント、ランタイムサーバー、バックエンドサーバーを同じ Anypoint Virtual Private Cloud (Anypoint VPC) で実行することで、ネットワークレイテンシーを抑えます。 - CloudHub テストの場合は、CloudHub ワーカーとは別でありながらも同じリージョンに存在する専用マシンで負荷クライアントとバックエンドサーバーを実行することで、ネットワークレイテンシーを抑えます。 - 優先接続された安定したネットワークを使用する。 - 顧客の環境にデプロイされている同じアプリケーションより性能が上回る可能性があるため (特に仮想化されている場合)、ノート PC は使用しない。 ![パフォーマンステストインフラストラクチャ](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-tuning-test-infrastructure.png) Figure 1. パフォーマンステストのインフラストラクチャ (ホストを分けることで干渉を防止) ### [](#適切なコンポーネントツールの選択)適切なコンポーネントツールの選択 テストで使用するコンポーネントによって、ユースケースで大きな違いが出ることがあります。現実的なパフォーマンスデータが得られるように、最も適切な負荷インジェクターとバックエンドサービスを、顧客環境と同じ設定で使用してください。そして、ユースケースに最適な負荷テストツールを選択してください。MuleSoft パフォーマンスチームは Apache JMeter を使用していますが、提供されている多くの市販またはオープンソースの負荷ツールの中から、シングルスレッド、マルチスレッド、非ブロックなど、さまざまな実装に合わせて好きなツールを選んでください。 適切なテストツールを選んで使い始めた後は、一貫してテスト結果が得られるように、同じツールを使い続けてください。選んだツールがユースケースに適していないと判断してツールを変更した場合は、テストをすべてやり直してください。 ### [](#テストのコンポーネントの分離)テストのコンポーネントの分離 パフォーマンスの測定とは、多くの変動要素が結果に影響する反復プロセスであるため、問題の原因となる変動要素を特定して分離できるようにしておくことが重要です。そのためには、それぞれがフロー内の特定のコンポーネントやコネクタを対象とする、いくつかの小さいピースにアプリケーションを分割します。これによってボトルネックが特定しやすくなり、特定のフロー要素に的を絞って最適化を直接行うことができます。 ### [](#代表的なワークロードの使用)代表的なワークロードの使用 アプリケーションをテストするときには、現実的な顧客のユースケースを模倣することが重要です。そのため、実際の顧客シナリオにおける以下の特性に関する情報を収集してください。 - ユーザーの動作 - ワークロード (仮想ユーザー数、メッセージ数など) - ペイロード (種別、サイズ、複雑さ) この情報に基づいて、エラーを発生させることなく Mule のパフォーマンス限界をテストするための、反復可能で共通したいくつかの高負荷シナリオを作成できます。実際の顧客動作を模倣するには、要求間の思考時間や、バックエンドサービスに対するレイテンシーなども導入してください。 ## [](#パフォーマンステスト検証の実行)パフォーマンステスト検証の実行 テストの実行を開始する前に、スループットの計算結果に影響する可能性のある、接続、切断、エラーパーセンテージの設定を削除しておくのが理想的です。前のセクションのベストプラクティスを考慮して、テストを実行します。 1. アプリケーションのボトルネックを特定して検証するためのパフォーマンステストを適用します。 2. 反復的なアプローチで、見つけた問題の改善に取り組みます。 - CloudHub アプリケーションの場合は、Mule フローと設定をチューニングします。 - オンプレミスアプリケーションの場合: 1. Mule フローと設定をチューニングします。 2. JVM、GC、などをチューニングします。 3. オペレーティングシステム変数をチューニングします。 3. テストを数回実行して、信頼できる結果を得ます。​[「チューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.3/tuning-recommendations)​の項目を 1 つずつ変更してテストを再実行してください。 4. テスト結果を確認します。 # パフォーマンステスト検証 アプリケーションのパフォーマンスを検証する手順は次のとおりです。 1. テストの前提条件を確認する。 2. ベストプラクティスに従う。 3. パフォーマンステストを実行する。 ## [](#パフォーマンステスト検証の前提条件)パフォーマンステスト検証の前提条件 パフォーマンステストを実行する前に、以下を行ってください。 - Mule アプリケーションとその機能が想定通りに機能することを確認します。フローが正しくないと偽陽性データが生成されることがあります。 - 以下の質問を自問してパフォーマンステストの条件を確立します。 - 平均とピーク時のワークロードは? - ユースケースで対処する必要のある特定のニーズは? - 大量のトランザクションを高優先度で処理する場合のスループット。 - アクティビティの急増がユーザーエクスペリエンスに影響する場合の応答時間またはレイテンシー。 - 多くのユーザーが同時に接続する状況をサポートする必要がある場合の同時実行数。 - アプリケーションが 1 MB を超えるペイロードを転送、キャッシュ、保存、または処理する場合の大規模メッセージの管理。 - 許容できる最小スループットは? - 許容できる最大応答時間は? ## [](#パフォーマンステスト検証のベストプラクティス)パフォーマンステスト検証のベストプラクティス テストのベストプラクティスでは、テスト環境、テストツール、コンポーネントの分離、代表的なワークロードを考慮する必要があります。 ### [](#制御された環境の使用)制御された環境の使用 自己制御された環境を使用して、再現性と信頼性の高い一貫したデータを取得します。 - 3 台の専用ホストで構成されるインフラストラクチャを使用する: - オンプレミステストの場合は、Mule アプリケーション専用のホストを使用してアプリケーション情報を分離することで、他の実行プロセスによる干渉を防止します。 - 実行する負荷クライアントツールがボトルネックとならずに負荷を提供できるように、分離された専用のホストを使用します。 - データベース、Tomcat、JMS、ActiveMQ などのバックエンドサービスを実行するための専用のホストを使用します。本番環境でアプリケーションが使用しているのと同じホストを使用してテストします。 - オンプレミステストの場合は、負荷クライアント、ランタイムサーバー、バックエンドサーバーを同じ Anypoint Virtual Private Cloud (Anypoint VPC) で実行することで、ネットワークレイテンシーを抑えます。 - CloudHub テストの場合は、CloudHub ワーカーとは別でありながらも同じリージョンに存在する専用マシンで負荷クライアントとバックエンドサーバーを実行することで、ネットワークレイテンシーを抑えます。 - 優先接続された安定したネットワークを使用する。 - 顧客の環境にデプロイされている同じアプリケーションより性能が上回る可能性があるため (特に仮想化されている場合)、ノート PC は使用しない。 ![パフォーマンステストインフラストラクチャ](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-tuning-test-infrastructure.png) Figure 1. パフォーマンステストのインフラストラクチャ (ホストを分けることで干渉を防止) ### [](#適切なコンポーネントツールの選択)適切なコンポーネントツールの選択 テストで使用するコンポーネントによって、ユースケースで大きな違いが出ることがあります。現実的なパフォーマンスデータが得られるように、最も適切な負荷インジェクターとバックエンドサービスを、顧客環境と同じ設定で使用してください。そして、ユースケースに最適な負荷テストツールを選択してください。MuleSoft パフォーマンスチームは Apache JMeter を使用していますが、提供されている多くの市販またはオープンソースの負荷ツールの中から、シングルスレッド、マルチスレッド、非ブロックなど、さまざまな実装に合わせて好きなツールを選んでください。 適切なテストツールを選んで使い始めた後は、一貫してテスト結果が得られるように、同じツールを使い続けてください。選んだツールがユースケースに適していないと判断してツールを変更した場合は、テストをすべてやり直してください。 ### [](#テストのコンポーネントの分離)テストのコンポーネントの分離 パフォーマンスの測定とは、多くの変動要素が結果に影響する反復プロセスであるため、問題の原因となる変動要素を特定して分離できるようにしておくことが重要です。そのためには、それぞれがフロー内の特定のコンポーネントやコネクタを対象とする、いくつかの小さいピースにアプリケーションを分割します。これによってボトルネックが特定しやすくなり、特定のフロー要素に的を絞って最適化を直接行うことができます。 ### [](#代表的なワークロードの使用)代表的なワークロードの使用 アプリケーションをテストするときには、現実的な顧客のユースケースを模倣することが重要です。そのため、実際の顧客シナリオにおける以下の特性に関する情報を収集してください。 - ユーザーの動作 - ワークロード (仮想ユーザー数、メッセージ数など) - ペイロード (種別、サイズ、複雑さ) この情報に基づいて、エラーを発生させることなく Mule のパフォーマンス限界をテストするための、反復可能で共通したいくつかの高負荷シナリオを作成できます。実際の顧客動作を模倣するには、要求間の思考時間や、バックエンドサービスに対するレイテンシーなども導入してください。 ## [](#パフォーマンステスト検証の実行)パフォーマンステスト検証の実行 テストの実行を開始する前に、スループットの計算結果に影響する可能性のある、接続、切断、エラーパーセンテージの設定を削除しておくのが理想的です。前のセクションのベストプラクティスを考慮して、テストを実行します。 1. アプリケーションのボトルネックを特定して検証するためのパフォーマンステストを適用します。 2. 反復的なアプローチで、見つけた問題の改善に取り組みます。 - CloudHub アプリケーションの場合は、Mule フローと設定をチューニングします。 - オンプレミスアプリケーションの場合: 1. Mule フローと設定をチューニングします。 2. JVM、GC、などをチューニングします。 3. オペレーティングシステム変数をチューニングします。 3. テストを数回実行して、信頼できる結果を得ます。​[「チューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.4/tuning-recommendations)​の項目を 1 つずつ変更してテストを再実行してください。 4. テスト結果を確認します。 # パフォーマンステスト検証 アプリケーションのパフォーマンスを検証する手順は次のとおりです。 1. テストの前提条件を確認する。 2. ベストプラクティスに従う。 3. パフォーマンステストを実行する。 ## [](#パフォーマンステスト検証の前提条件)パフォーマンステスト検証の前提条件 パフォーマンステストを実行する前に、以下を行ってください。 - Mule アプリケーションとその機能が想定通りに機能することを確認します。フローが正しくないと偽陽性データが生成されることがあります。 - 以下の質問を自問してパフォーマンステストの条件を確立します。 - 平均とピーク時のワークロードは? - ユースケースで対処する必要のある特定のニーズは? - 大量のトランザクションを高優先度で処理する場合のスループット。 - アクティビティの急増がユーザーエクスペリエンスに影響する場合の応答時間またはレイテンシー。 - 多くのユーザーが同時に接続する状況をサポートする必要がある場合の同時実行数。 - アプリケーションが 1 MB を超えるペイロードを転送、キャッシュ、保存、または処理する場合の大規模メッセージの管理。 - 許容できる最小スループットは? - 許容できる最大応答時間は? ## [](#パフォーマンステスト検証のベストプラクティス)パフォーマンステスト検証のベストプラクティス テストのベストプラクティスでは、テスト環境、テストツール、コンポーネントの分離、代表的なワークロードを考慮する必要があります。 ### [](#制御された環境の使用)制御された環境の使用 自己制御された環境を使用して、再現性と信頼性の高い一貫したデータを取得します。 - 3 台の専用ホストで構成されるインフラストラクチャを使用する: - オンプレミステストの場合は、Mule アプリケーション専用のホストを使用してアプリケーション情報を分離することで、他の実行プロセスによる干渉を防止します。 - 実行する負荷クライアントツールがボトルネックとならずに負荷を提供できるように、分離された専用のホストを使用します。 - データベース、Tomcat、JMS、ActiveMQ などのバックエンドサービスを実行するための専用のホストを使用します。本番環境でアプリケーションが使用しているのと同じホストを使用してテストします。 - オンプレミステストの場合は、負荷クライアント、ランタイムサーバー、バックエンドサーバーを同じ Anypoint Virtual Private Cloud (Anypoint VPC) で実行することで、ネットワークレイテンシーを抑えます。 - CloudHub テストの場合は、CloudHub ワーカーとは別でありながらも同じリージョンに存在する専用マシンで負荷クライアントとバックエンドサーバーを実行することで、ネットワークレイテンシーを抑えます。 - 優先接続された安定したネットワークを使用する。 - 顧客の環境にデプロイされている同じアプリケーションより性能が上回る可能性があるため (特に仮想化されている場合)、ノート PC は使用しない。 ![パフォーマンステストインフラストラクチャ](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-tuning-test-infrastructure.png) Figure 1. パフォーマンステストのインフラストラクチャ (ホストを分けることで干渉を防止) ### [](#適切なコンポーネントツールの選択)適切なコンポーネントツールの選択 テストで使用するコンポーネントによって、ユースケースで大きな違いが出ることがあります。現実的なパフォーマンスデータが得られるように、最も適切な負荷インジェクターとバックエンドサービスを、顧客環境と同じ設定で使用してください。そして、ユースケースに最適な負荷テストツールを選択してください。MuleSoft パフォーマンスチームは Apache JMeter を使用していますが、提供されている多くの市販またはオープンソースの負荷ツールの中から、シングルスレッド、マルチスレッド、非ブロックなど、さまざまな実装に合わせて好きなツールを選んでください。 適切なテストツールを選んで使い始めた後は、一貫してテスト結果が得られるように、同じツールを使い続けてください。選んだツールがユースケースに適していないと判断してツールを変更した場合は、テストをすべてやり直してください。 ### [](#テストのコンポーネントの分離)テストのコンポーネントの分離 パフォーマンスの測定とは、多くの変動要素が結果に影響する反復プロセスであるため、問題の原因となる変動要素を特定して分離できるようにしておくことが重要です。そのためには、それぞれがフロー内の特定のコンポーネントやコネクタを対象とする、いくつかの小さいピースにアプリケーションを分割します。これによってボトルネックが特定しやすくなり、特定のフロー要素に的を絞って最適化を直接行うことができます。 ### [](#代表的なワークロードの使用)代表的なワークロードの使用 アプリケーションをテストするときには、現実的な顧客のユースケースを模倣することが重要です。そのため、実際の顧客シナリオにおける以下の特性に関する情報を収集してください。 - ユーザーの動作 - ワークロード (仮想ユーザー数、メッセージ数など) - ペイロード (種別、サイズ、複雑さ) この情報に基づいて、エラーを発生させることなく Mule のパフォーマンス限界をテストするための、反復可能で共通したいくつかの高負荷シナリオを作成できます。実際の顧客動作を模倣するには、要求間の思考時間や、バックエンドサービスに対するレイテンシーなども導入してください。 ## [](#パフォーマンステスト検証の実行)パフォーマンステスト検証の実行 テストの実行を開始する前に、スループットの計算結果に影響する可能性のある、接続、切断、エラーパーセンテージの設定を削除しておくのが理想的です。前のセクションのベストプラクティスを考慮して、テストを実行します。 1. アプリケーションのボトルネックを特定して検証するためのパフォーマンステストを適用します。 2. 反復的なアプローチで、見つけた問題の改善に取り組みます。 - CloudHub アプリケーションの場合は、Mule フローと設定をチューニングします。 - オンプレミスアプリケーションの場合: 1. Mule フローと設定をチューニングします。 2. JVM、GC、などをチューニングします。 3. オペレーティングシステム変数をチューニングします。 3. テストを数回実行して、信頼できる結果を得ます。​[「チューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.5/tuning-recommendations)​の項目を 1 つずつ変更してテストを再実行してください。 4. テスト結果を確認します。 # パフォーマンステスト検証 アプリケーションのパフォーマンスを検証する手順は次のとおりです。 1. テストの前提条件を確認する。 2. ベストプラクティスに従う。 3. パフォーマンステストを実行する。 ## [](#パフォーマンステスト検証の前提条件)パフォーマンステスト検証の前提条件 パフォーマンステストを実行する前に、以下を行ってください。 - Mule アプリケーションとその機能が想定通りに機能することを確認します。フローが正しくないと偽陽性データが生成されることがあります。 - 以下の質問を自問してパフォーマンステストの条件を確立します。 - 平均とピーク時のワークロードは? - ユースケースで対処する必要のある特定のニーズは? - 大量のトランザクションを高優先度で処理する場合のスループット。 - アクティビティの急増がユーザーエクスペリエンスに影響する場合の応答時間またはレイテンシー。 - 多くのユーザーが同時に接続する状況をサポートする必要がある場合の同時実行数。 - アプリケーションが 1 MB を超えるペイロードを転送、キャッシュ、保存、または処理する場合の大規模メッセージの管理。 - 許容できる最小スループットは? - 許容できる最大応答時間は? ## [](#パフォーマンステスト検証のベストプラクティス)パフォーマンステスト検証のベストプラクティス テストのベストプラクティスでは、テスト環境、テストツール、コンポーネントの分離、代表的なワークロードを考慮する必要があります。 ### [](#制御された環境の使用)制御された環境の使用 自己制御された環境を使用して、再現性と信頼性の高い一貫したデータを取得します。 - 3 台の専用ホストで構成されるインフラストラクチャを使用する: - オンプレミステストの場合は、Mule アプリケーション専用のホストを使用してアプリケーション情報を分離することで、他の実行プロセスによる干渉を防止します。 - 実行する負荷クライアントツールがボトルネックとならずに負荷を提供できるように、分離された専用のホストを使用します。 - データベース、Tomcat、JMS、ActiveMQ などのバックエンドサービスを実行するための専用のホストを使用します。本番環境でアプリケーションが使用しているのと同じホストを使用してテストします。 - オンプレミステストの場合は、負荷クライアント、ランタイムサーバー、バックエンドサーバーを同じ Anypoint Virtual Private Cloud (Anypoint VPC) で実行することで、ネットワークレイテンシーを抑えます。 - CloudHub テストの場合は、CloudHub ワーカーとは別でありながらも同じリージョンに存在する専用マシンで負荷クライアントとバックエンドサーバーを実行することで、ネットワークレイテンシーを抑えます。 - 優先接続された安定したネットワークを使用する。 - 顧客の環境にデプロイされている同じアプリケーションより性能が上回る可能性があるため (特に仮想化されている場合)、ノート PC は使用しない。 ![パフォーマンステストインフラストラクチャ](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-tuning-test-infrastructure.png) Figure 1. パフォーマンステストのインフラストラクチャ (ホストを分けることで干渉を防止) ### [](#適切なコンポーネントツールの選択)適切なコンポーネントツールの選択 テストで使用するコンポーネントによって、ユースケースで大きな違いが出ることがあります。現実的なパフォーマンスデータが得られるように、最も適切な負荷インジェクターとバックエンドサービスを、顧客環境と同じ設定で使用してください。そして、ユースケースに最適な負荷テストツールを選択してください。MuleSoft パフォーマンスチームは Apache JMeter を使用していますが、提供されている多くの市販またはオープンソースの負荷ツールの中から、シングルスレッド、マルチスレッド、非ブロックなど、さまざまな実装に合わせて好きなツールを選んでください。 適切なテストツールを選んで使い始めた後は、一貫してテスト結果が得られるように、同じツールを使い続けてください。選んだツールがユースケースに適していないと判断してツールを変更した場合は、テストをすべてやり直してください。 ### [](#テストのコンポーネントの分離)テストのコンポーネントの分離 パフォーマンスの測定とは、多くの変動要素が結果に影響する反復プロセスであるため、問題の原因となる変動要素を特定して分離できるようにしておくことが重要です。そのためには、それぞれがフロー内の特定のコンポーネントやコネクタを対象とする、いくつかの小さいピースにアプリケーションを分割します。これによってボトルネックが特定しやすくなり、特定のフロー要素に的を絞って最適化を直接行うことができます。 ### [](#代表的なワークロードの使用)代表的なワークロードの使用 アプリケーションをテストするときには、現実的な顧客のユースケースを模倣することが重要です。そのため、実際の顧客シナリオにおける以下の特性に関する情報を収集してください。 - ユーザーの動作 - ワークロード (仮想ユーザー数、メッセージ数など) - ペイロード (種別、サイズ、複雑さ) この情報に基づいて、エラーを発生させることなく Mule のパフォーマンス限界をテストするための、反復可能で共通したいくつかの高負荷シナリオを作成できます。実際の顧客動作を模倣するには、要求間の思考時間や、バックエンドサービスに対するレイテンシーなども導入してください。 ## [](#パフォーマンステスト検証の実行)パフォーマンステスト検証の実行 テストの実行を開始する前に、スループットの計算結果に影響する可能性のある、接続、切断、エラーパーセンテージの設定を削除しておくのが理想的です。前のセクションのベストプラクティスを考慮して、テストを実行します。 1. アプリケーションのボトルネックを特定して検証するためのパフォーマンステストを適用します。 2. 反復的なアプローチで、見つけた問題の改善に取り組みます。 - CloudHub アプリケーションの場合は、Mule フローと設定をチューニングします。 - オンプレミスアプリケーションの場合: 1. Mule フローと設定をチューニングします。 2. JVM、GC、などをチューニングします。 アプリケーションのパフォーマンスについての詳細は、​[「アプリケーションのパフォーマンス」](https://docs.mulesoft.com/jp/general/java-support#application-performance)​を参照してください。 3. オペレーティングシステム変数をチューニングします。 3. テストを数回実行して、信頼できる結果を得ます。​[「チューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.6/tuning-recommendations)​の項目を 1 つずつ変更してテストを再実行してください。 4. テスト結果を確認します。 # パフォーマンステスト検証 アプリケーションのパフォーマンスを検証する手順は次のとおりです。 1. テストの前提条件を確認する。 2. ベストプラクティスに従う。 3. パフォーマンステストを実行する。 ## [](#パフォーマンステスト検証の前提条件)パフォーマンステスト検証の前提条件 パフォーマンステストを実行する前に、以下を行ってください。 - Mule アプリケーションとその機能が想定通りに機能することを確認します。フローが正しくないと偽陽性データが生成されることがあります。 - 以下の質問を自問してパフォーマンステストの条件を確立します。 - 平均とピーク時のワークロードは? - ユースケースで対処する必要のある特定のニーズは? - 大量のトランザクションを高優先度で処理する場合のスループット。 - アクティビティの急増がユーザーエクスペリエンスに影響する場合の応答時間またはレイテンシー。 - 多くのユーザーが同時に接続する状況をサポートする必要がある場合の同時実行数。 - アプリケーションが 1 MB を超えるペイロードを転送、キャッシュ、保存、または処理する場合の大規模メッセージの管理。 - 許容できる最小スループットは? - 許容できる最大応答時間は? ## [](#パフォーマンステスト検証のベストプラクティス)パフォーマンステスト検証のベストプラクティス テストのベストプラクティスでは、テスト環境、テストツール、コンポーネントの分離、代表的なワークロードを考慮する必要があります。 ### [](#制御された環境の使用)制御された環境の使用 自己制御された環境を使用して、再現性と信頼性の高い一貫したデータを取得します。 - 3 台の専用ホストで構成されるインフラストラクチャを使用する: - オンプレミステストの場合は、Mule アプリケーション専用のホストを使用してアプリケーション情報を分離することで、他の実行プロセスによる干渉を防止します。 - 実行する負荷クライアントツールがボトルネックとならずに負荷を提供できるように、分離された専用のホストを使用します。 - データベース、Tomcat、JMS、ActiveMQ などのバックエンドサービスを実行するための専用のホストを使用します。本番環境でアプリケーションが使用しているのと同じホストを使用してテストします。 - オンプレミステストの場合は、負荷クライアント、ランタイムサーバー、バックエンドサーバーを同じ Anypoint Virtual Private Cloud (Anypoint VPC) で実行することで、ネットワークレイテンシーを抑えます。 - CloudHub テストの場合は、CloudHub ワーカーとは別でありながらも同じリージョンに存在する専用マシンで負荷クライアントとバックエンドサーバーを実行することで、ネットワークレイテンシーを抑えます。 - 優先接続された安定したネットワークを使用する。 - 顧客の環境にデプロイされている同じアプリケーションより性能が上回る可能性があるため (特に仮想化されている場合)、ノート PC は使用しない。 ![パフォーマンステストインフラストラクチャ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-tuning-test-infrastructure.png) Figure 1. パフォーマンステストのインフラストラクチャ (ホストを分けることで干渉を防止) ### [](#適切なコンポーネントツールの選択)適切なコンポーネントツールの選択 テストで使用するコンポーネントによって、ユースケースで大きな違いが出ることがあります。現実的なパフォーマンスデータが得られるように、最も適切な負荷インジェクターとバックエンドサービスを、顧客環境と同じ設定で使用してください。そして、ユースケースに最適な負荷テストツールを選択してください。MuleSoft パフォーマンスチームは Apache JMeter を使用していますが、提供されている多くの市販またはオープンソースの負荷ツールの中から、シングルスレッド、マルチスレッド、非ブロックなど、さまざまな実装に合わせて好きなツールを選んでください。 適切なテストツールを選んで使い始めた後は、一貫してテスト結果が得られるように、同じツールを使い続けてください。選んだツールがユースケースに適していないと判断してツールを変更した場合は、テストをすべてやり直してください。 ### [](#テストのコンポーネントの分離)テストのコンポーネントの分離 パフォーマンスの測定とは、多くの変動要素が結果に影響する反復プロセスであるため、問題の原因となる変動要素を特定して分離できるようにしておくことが重要です。そのためには、それぞれがフロー内の特定のコンポーネントやコネクタを対象とする、いくつかの小さいピースにアプリケーションを分割します。これによってボトルネックが特定しやすくなり、特定のフロー要素に的を絞って最適化を直接行うことができます。 ### [](#代表的なワークロードの使用)代表的なワークロードの使用 アプリケーションをテストするときには、現実的な顧客のユースケースを模倣することが重要です。そのため、実際の顧客シナリオにおける以下の特性に関する情報を収集してください。 - ユーザーの動作 - ワークロード (仮想ユーザー数、メッセージ数など) - ペイロード (種別、サイズ、複雑さ) この情報に基づいて、エラーを発生させることなく Mule のパフォーマンス限界をテストするための、反復可能で共通したいくつかの高負荷シナリオを作成できます。実際の顧客動作を模倣するには、要求間の思考時間や、バックエンドサービスに対するレイテンシーなども導入してください。 ## [](#パフォーマンステスト検証の実行)パフォーマンステスト検証の実行 テストの実行を開始する前に、スループットの計算結果に影響する可能性のある、接続、切断、エラーパーセンテージの設定を削除しておくのが理想的です。前のセクションのベストプラクティスを考慮して、テストを実行します。 1. アプリケーションのボトルネックを特定して検証するためのパフォーマンステストを適用します。 2. 反復的なアプローチで、見つけた問題の改善に取り組みます。 - CloudHub アプリケーションの場合は、Mule フローと設定をチューニングします。 - オンプレミスアプリケーションの場合: 1. Mule フローと設定をチューニングします。 2. JVM、GC、などをチューニングします。 アプリケーションのパフォーマンスについての詳細は、​[「アプリケーションのパフォーマンス」](https://docs.mulesoft.com/jp/general/java-support#application-performance)​を参照してください。 3. オペレーティングシステム変数をチューニングします。 3. テストを数回実行して、信頼できる結果を得ます。​[「チューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.7/tuning-recommendations)​の項目を 1 つずつ変更してテストを再実行してください。 4. テスト結果を確認します。 # パフォーマンステスト検証 アプリケーションのパフォーマンスを検証する手順は次のとおりです。 1. テストの前提条件を確認する。 2. ベストプラクティスに従う。 3. パフォーマンステストを実行する。 ## [](#パフォーマンステスト検証の前提条件)パフォーマンステスト検証の前提条件 パフォーマンステストを実行する前に、以下を行ってください。 - Mule アプリケーションとその機能が想定通りに機能することを確認します。フローが正しくないと偽陽性データが生成されることがあります。 - 以下の質問を自問してパフォーマンステストの条件を確立します。 - 平均とピーク時のワークロードは? - ユースケースで対処する必要のある特定のニーズは? - 大量のトランザクションを高優先度で処理する場合のスループット。 - アクティビティの急増がユーザーエクスペリエンスに影響する場合の応答時間またはレイテンシー。 - 多くのユーザーが同時に接続する状況をサポートする必要がある場合の同時実行数。 - アプリケーションが 1 MB を超えるペイロードを転送、キャッシュ、保存、または処理する場合の大規模メッセージの管理。 - 許容できる最小スループットは? - 許容できる最大応答時間は? ## [](#パフォーマンステスト検証のベストプラクティス)パフォーマンステスト検証のベストプラクティス テストのベストプラクティスでは、テスト環境、テストツール、コンポーネントの分離、代表的なワークロードを考慮する必要があります。 ### [](#制御された環境の使用)制御された環境の使用 自己制御された環境を使用して、再現性と信頼性の高い一貫したデータを取得します。 - 3 台の専用ホストで構成されるインフラストラクチャを使用する: - オンプレミステストの場合は、Mule アプリケーション専用のホストを使用してアプリケーション情報を分離することで、他の実行プロセスによる干渉を防止します。 - 実行する負荷クライアントツールがボトルネックとならずに負荷を提供できるように、分離された専用のホストを使用します。 - データベース、Tomcat、JMS、ActiveMQ などのバックエンドサービスを実行するための専用のホストを使用します。本番環境でアプリケーションが使用しているのと同じホストを使用してテストします。 - オンプレミステストの場合は、負荷クライアント、ランタイムサーバー、バックエンドサーバーを同じ Anypoint Virtual Private Cloud (Anypoint VPC) で実行することで、ネットワークレイテンシーを抑えます。 - CloudHub テストの場合は、CloudHub ワーカーとは別でありながらも同じリージョンに存在する専用マシンで負荷クライアントとバックエンドサーバーを実行することで、ネットワークレイテンシーを抑えます。 - 優先接続された安定したネットワークを使用する。 - 顧客の環境にデプロイされている同じアプリケーションより性能が上回る可能性があるため (特に仮想化されている場合)、ノート PC は使用しない。 ![負荷クライアント、Mule、バックエンドサービスなどのテストインフラストラクチャのセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-tuning-test-infrastructure.png) Figure 1. パフォーマンステストのインフラストラクチャ (ホストを分けることで干渉を防止) ### [](#適切なコンポーネントツールの選択)適切なコンポーネントツールの選択 テストで使用するコンポーネントによって、ユースケースで大きな違いが出ることがあります。現実的なパフォーマンスデータが得られるように、最も適切な負荷インジェクターとバックエンドサービスを、顧客環境と同じ設定で使用してください。そして、ユースケースに最適な負荷テストツールを選択してください。MuleSoft パフォーマンスチームは Apache JMeter を使用していますが、提供されている多くの市販またはオープンソースの負荷ツールの中から、シングルスレッド、マルチスレッド、非ブロックなど、さまざまな実装に合わせて好きなツールを選んでください。 適切なテストツールを選んで使い始めた後は、一貫してテスト結果が得られるように、同じツールを使い続けてください。選んだツールがユースケースに適していないと判断してツールを変更した場合は、テストをすべてやり直してください。 ### [](#テストのコンポーネントの分離)テストのコンポーネントの分離 パフォーマンスの測定とは、多くの変動要素が結果に影響する反復プロセスであるため、問題の原因となる変動要素を特定して分離できるようにしておくことが重要です。そのためには、それぞれがフロー内の特定のコンポーネントやコネクタを対象とする、いくつかの小さいピースにアプリケーションを分割します。これによってボトルネックが特定しやすくなり、特定のフロー要素に的を絞って最適化を直接行うことができます。 ### [](#代表的なワークロードの使用)代表的なワークロードの使用 アプリケーションをテストするときには、現実的な顧客のユースケースを模倣することが重要です。そのため、実際の顧客シナリオにおける以下の特性に関する情報を収集してください。 - ユーザーの動作 - ワークロード (仮想ユーザー数、メッセージ数など) - ペイロード (種別、サイズ、複雑さ) この情報に基づいて、エラーを発生させることなく Mule のパフォーマンス限界をテストするための、反復可能で共通したいくつかの高負荷シナリオを作成できます。実際の顧客動作を模倣するには、要求間の思考時間や、バックエンドサービスに対するレイテンシーなども導入してください。 ## [](#パフォーマンステスト検証の実行)パフォーマンステスト検証の実行 テストの実行を開始する前に、スループットの計算結果に影響する可能性のある、接続、切断、エラーパーセンテージの設定を削除しておくのが理想的です。前のセクションのベストプラクティスを考慮して、テストを実行します。 1. アプリケーションのボトルネックを特定して検証するためのパフォーマンステストを適用します。 2. 反復的なアプローチで、見つけた問題の改善に取り組みます。 - CloudHub アプリケーションの場合は、Mule フローと設定をチューニングします。 - オンプレミスアプリケーションの場合: 1. Mule フローと設定をチューニングします。 2. JVM、GC、などをチューニングします。 アプリケーションのパフォーマンスについての詳細は、​[「アプリケーションのパフォーマンス」](https://docs.mulesoft.com/jp/general/java-support#application-performance)​を参照してください。 3. オペレーティングシステム変数をチューニングします。 3. テストを数回実行して、信頼できる結果を得ます。​[「チューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.8/tuning-recommendations)​の項目を 1 つずつ変更してテストを再実行してください。 4. テスト結果を確認します。 # パフォーマンステスト検証 アプリケーションのパフォーマンスを検証する手順は次のとおりです。 1. テストの前提条件を確認する。 2. ベストプラクティスに従う。 3. パフォーマンステストを実行する。 ## [](#パフォーマンステスト検証の前提条件)パフォーマンステスト検証の前提条件 パフォーマンステストを実行する前に、以下を行ってください。 - Mule アプリケーションとその機能が想定通りに機能することを確認します。フローが正しくないと偽陽性データが生成されることがあります。 - 以下の質問を自問してパフォーマンステストの条件を確立します。 - 平均とピーク時のワークロードは? - ユースケースで対処する必要のある特定のニーズは? - 大量のトランザクションを高優先度で処理する場合のスループット。 - アクティビティの急増がユーザーエクスペリエンスに影響する場合の応答時間またはレイテンシー。 - 多くのユーザーが同時に接続する状況をサポートする必要がある場合の同時実行数。 - アプリケーションが 1 MB を超えるペイロードを転送、キャッシュ、保存、または処理する場合の大規模メッセージの管理。 - 許容できる最小スループットは? - 許容できる最大応答時間は? ## [](#パフォーマンステスト検証のベストプラクティス)パフォーマンステスト検証のベストプラクティス テストのベストプラクティスでは、テスト環境、テストツール、コンポーネントの分離、代表的なワークロードを考慮する必要があります。 ### [](#制御された環境の使用)制御された環境の使用 自己制御された環境を使用して、再現性と信頼性の高い一貫したデータを取得します。 - 3 台の専用ホストで構成されるインフラストラクチャを使用する: - オンプレミステストの場合は、Mule アプリケーション専用のホストを使用してアプリケーション情報を分離することで、他の実行プロセスによる干渉を防止します。 - 実行する負荷クライアントツールがボトルネックとならずに負荷を提供できるように、分離された専用のホストを使用します。 - データベース、Tomcat、JMS、ActiveMQ などのバックエンドサービスを実行するための専用のホストを使用します。本番環境でアプリケーションが使用しているのと同じホストを使用してテストします。 - オンプレミステストの場合は、負荷クライアント、ランタイムサーバー、バックエンドサーバーを同じ Anypoint Virtual Private Cloud (Anypoint VPC) で実行することで、ネットワークレイテンシーを抑えます。 - CloudHub テストの場合は、CloudHub ワーカーとは別でありながらも同じリージョンに存在する専用マシンで負荷クライアントとバックエンドサーバーを実行することで、ネットワークレイテンシーを抑えます。 - 優先接続された安定したネットワークを使用する。 - 顧客の環境にデプロイされている同じアプリケーションより性能が上回る可能性があるため (特に仮想化されている場合)、ノート PC は使用しない。 ![負荷クライアント、Mule、バックエンドサービスなどのテストインフラストラクチャのセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-tuning-test-infrastructure.png) Figure 1. パフォーマンステストのインフラストラクチャ (ホストを分けることで干渉を防止) ### [](#適切なコンポーネントツールの選択)適切なコンポーネントツールの選択 テストで使用するコンポーネントによって、ユースケースで大きな違いが出ることがあります。現実的なパフォーマンスデータが得られるように、最も適切な負荷インジェクターとバックエンドサービスを、顧客環境と同じ設定で使用してください。そして、ユースケースに最適な負荷テストツールを選択してください。MuleSoft パフォーマンスチームは Apache JMeter を使用していますが、提供されている多くの市販またはオープンソースの負荷ツールの中から、シングルスレッド、マルチスレッド、非ブロックなど、さまざまな実装に合わせて好きなツールを選んでください。 適切なテストツールを選んで使い始めた後は、一貫してテスト結果が得られるように、同じツールを使い続けてください。選んだツールがユースケースに適していないと判断してツールを変更した場合は、テストをすべてやり直してください。 ### [](#テストのコンポーネントの分離)テストのコンポーネントの分離 パフォーマンスの測定とは、多くの変動要素が結果に影響する反復プロセスであるため、問題の原因となる変動要素を特定して分離できるようにしておくことが重要です。そのためには、それぞれがフロー内の特定のコンポーネントやコネクタを対象とする、いくつかの小さいピースにアプリケーションを分割します。これによってボトルネックが特定しやすくなり、特定のフロー要素に的を絞って最適化を直接行うことができます。 ### [](#代表的なワークロードの使用)代表的なワークロードの使用 アプリケーションをテストするときには、現実的な顧客のユースケースを模倣することが重要です。そのため、実際の顧客シナリオにおける以下の特性に関する情報を収集してください。 - ユーザーの動作 - ワークロード (仮想ユーザー数、メッセージ数など) - ペイロード (種別、サイズ、複雑さ) この情報に基づいて、エラーを発生させることなく Mule のパフォーマンス限界をテストするための、反復可能で共通したいくつかの高負荷シナリオを作成できます。実際の顧客動作を模倣するには、要求間の思考時間や、バックエンドサービスに対するレイテンシーなども導入してください。 ## [](#パフォーマンステスト検証の実行)パフォーマンステスト検証の実行 テストの実行を開始する前に、スループットの計算結果に影響する可能性のある、接続、切断、エラーパーセンテージの設定を削除しておくのが理想的です。前のセクションのベストプラクティスを考慮して、テストを実行します。 1. アプリケーションのボトルネックを特定して検証するためのパフォーマンステストを適用します。 2. 反復的なアプローチで、見つけた問題の改善に取り組みます。 - CloudHub アプリケーションの場合は、Mule フローと設定をチューニングします。 - オンプレミスアプリケーションの場合: 1. Mule フローと設定をチューニングします。 2. JVM、GC、などをチューニングします。 アプリケーションのパフォーマンスについての詳細は、​[「アプリケーションのパフォーマンス」](https://docs.mulesoft.com/jp/general/java-support#application-performance)​を参照してください。 3. オペレーティングシステム変数をチューニングします。 3. テストを数回実行して、信頼できる結果を得ます。​[「チューニングの推奨事項」](https://docs.mulesoft.com/jp/mule-runtime/4.9/tuning-recommendations)​の項目を 1 つずつ変更してテストを再実行してください。 4. テスト結果を確認します。 # パフォーマンス監視 パフォーマンステストのベストプラクティスを補うため、Mule Runtime Engine (Mule) がテスト中にコンシュームするリソースを監視します。それぞれの主なシステムリソースを監視するために最も重要なメトリクスと、CloudHub の監視で使用するツールについて以下に説明します。 以下に示すリソース監視コマンドは、sysstat がインストールされている Linux OS で使用できます。 ## [](#cpu-リソース)CPU リソース 負荷が増大すると CPU リソースが枯渇することがあります。これらのリソースはいくつかの方法で監視できます。その中から 2 つを紹介します。 - top コマンド: `top` `%CPU`​ メトリクスは、CPU 使用量をコア数で割った値です。 ![top コマンドによる CPU 統計情報](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-tuning-monitoring-top.png) Figure 1. top コマンドによる CPU 統計情報 - sar コマンド: `sar -u ALL $INTERVAL $COUNT` `$INTERVAL`​ はメトリクスを取得する時間間隔を指定し、​`$COUNT`​ は収集するデータポイント数を指定します。 注目すべき主なメトリクスは次のとおりです。 - `%sys`​、システムレベル (カーネル) での CPU 使用量を表示 - `%sys`​、システムレベル (カーネル) での CPU 使用量を表示 - `%idle`​、CPU のアイドル時間のパーセンテージを表示 ![sar コマンドによる CPU 統計情報](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-tuning-sar-cpu.png) Figure 2. sar コマンドによる CPU 統計情報 ## [](#メモリリソース)メモリリソース ヒープやネイティブメモリ、オフヒープバッファなど、Mule によるメモリ使用状況を理解するため、メモリをいくつかの方法で監視します。その中から 2 つを紹介します。 - GC ログ GC (ガベージコレクション) のログを有効にして、割り当てレート、オブジェクトの増大などの情報を入手します。また、ヒープでのアクティビティに関する情報も入手します。GC ログを有効にすると、ディスクオーバーヘッドが若干増大します。 ![wrapper.conf](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-tuning-wrapper.png) Figure 3. CG ログ wrapper.conf - sar コマンド: `sar -r $INTERVAL $COUNT` 注目すべき主なメトリクスは次のとおりです。 - `kbmemfree`​、使用できるメモリ量をキロバイト数で表示 - `kbmemused`​、使用中のメモリ量をキロバイト数で表示 - `kbcommit`​、現在のワークロードに必要な RAM またはスワップメモリの量をキロバイト数で表示 ![sar コマンドによるメモリ統計情報](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-tuning-sar-memory.png) Figure 4. sar コマンドによるメモリ統計情報 ## [](#ディスクリソース)ディスクリソース 一部の Mule コンポーネントは、反復可能ストリームとして処理された大きなペイロードによって I/O (入出力) 要求が大量に発生し、リソースが大量に枯渇した書き込み操作やシナリオをログに記録します。ディスクリソースは sar コマンド ​`sar -d -p $INTERVAL $COUNT`​ を使用して監視します。 注目すべき主なメトリクスは次のとおりです。 - `await`​、デバイスを処理するために発行された I/O 要求の平均時間 (要求がキューに登録されていた時間と処理に要した時間の合計) を表示。 - `%util`​、デバイスの帯域幅使用量に対する、I/O 要求が発行されていた CPU 時間のパーセンテージによりデバイス飽和を表示。 ![sar コマンドによるディスク統計情報](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-tuning-sar-disk.png) Figure 5. sar コマンドによるディスク統計情報 ## [](#ネットワークリソース)ネットワークリソース Mule はネットワーク経由でいくつかのサービスと通信するため、ネットワークの使用量が飽和してボトルネックになることがあります。これを管理するには、使用できる帯域幅を把握し、使用量を監視する必要があります。これを行うためのシンプルは方法は、sar コマンド ​`sar -n DEV $INTERVAL $COUNT`​ を使用することです。 注目すべき主なメトリクスは次のとおりです。 - `rxpck/s`​、1 秒間に受信したパケットの合計数を表示。 - `txpck/s`​、1 秒間に送信したパケットの合計数を表示。 ![sar コマンドによるネットワーク統計情報](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-tuning-sar-network.png) Figure 6. sar コマンドによるネットワーク統計情報 ## [](#cloudhub-の監視)CloudHub の監視 CloudHub 環境での Mule アプリケーションのパフォーマンスは、Anypoint Runtime Manager ダッシュボードまたは Anypoint Monitoring を使用して監視できます。 - Runtime Manager ダッシュボード このツールは、メッセージ数やトランザクション数、CPU やメモリの使用量、そして過去 1 時間、過去 24 時間、先週といった特定期間のメトリクスなど、パフォーマンスの重要なメトリクスを可視化します。 ![Runtime Manager ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-tuning-runtimemanager.png) Figure 7. Runtime Manager ダッシュボード - Anypoint Monitoring このツールは、リソースを視覚的に表現する組み込みダッシュボードやカスタムダッシュボードを使用して、パフォーマンスのメトリクスを追跡して可視化します。さらに、Anypoint Monitoring では、異常の検出、問題のトラブルシューティング、未加工データを見ているだけでは気付かないトレンドの表示なども行えます。 ![Anypoint Monitoring ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-tuning-anypointmonitoring.png) Figure 8. Anypoint Monitoring ダッシュボード ## [](#関連情報)関連情報 - [top Linux コマンド](https://man7.org/linux/man-pages/man1/top.1.html) - [sar Linux コマンド](https://linux.die.net/man/1/sar) # パフォーマンス監視 パフォーマンステストのベストプラクティスを補うため、Mule Runtime Engine (Mule) がテスト中にコンシュームするリソースを監視します。それぞれの主なシステムリソースを監視するために最も重要なメトリクスと、CloudHub の監視で使用するツールについて以下に説明します。 以下に示すリソース監視コマンドは、sysstat がインストールされている Linux OS で使用できます。 ## [](#cpu-リソース)CPU リソース 負荷が増大すると CPU リソースが枯渇することがあります。これらのリソースはいくつかの方法で監視できます。その中から 2 つを紹介します。 - top コマンド: `top` `%CPU`​ メトリクスは、CPU 使用量をコア数で割った値です。 ![top コマンドによる CPU 統計情報](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-tuning-monitoring-top.png) Figure 1. top コマンドによる CPU 統計情報 - sar コマンド: `sar -u ALL $INTERVAL $COUNT` `$INTERVAL`​ はメトリクスを取得する時間間隔を指定し、​`$COUNT`​ は収集するデータポイント数を指定します。 注目すべき主なメトリクスは次のとおりです。 - `%sys`​、システムレベル (カーネル) での CPU 使用量を表示 - `%idle`​、CPU のアイドル時間のパーセンテージを表示 ![sar コマンドによる CPU 統計情報](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-tuning-sar-cpu.png) Figure 2. sar コマンドによる CPU 統計情報 ## [](#メモリリソース)メモリリソース ヒープやネイティブメモリ、オフヒープバッファなど、Mule によるメモリ使用状況を理解するため、メモリをいくつかの方法で監視します。その中から 2 つを紹介します。 - GC ログ GC (ガベージコレクション) のログを有効にして、割り当てレート、オブジェクトの増大などの情報を入手します。また、ヒープでのアクティビティに関する情報も入手します。GC ログを有効にすると、ディスクオーバーヘッドが若干増大します。 ![wrapper.conf](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-tuning-wrapper.png) Figure 3. CG ログ wrapper.conf - sar コマンド: `sar -r $INTERVAL $COUNT` 注目すべき主なメトリクスは次のとおりです。 - `kbmemfree`​、使用できるメモリ量をキロバイト数で表示 - `kbmemused`​、使用中のメモリ量をキロバイト数で表示 - `kbcommit`​、現在のワークロードに必要な RAM またはスワップメモリの量をキロバイト数で表示 ![sar コマンドによるメモリ統計情報](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-tuning-sar-memory.png) Figure 4. sar コマンドによるメモリ統計情報 ## [](#ディスクリソース)ディスクリソース 一部の Mule コンポーネントは、反復可能ストリームとして処理された大きなペイロードによって I/O (入出力) 要求が大量に発生し、リソースが大量に枯渇した書き込み操作やシナリオをログに記録します。ディスクリソースは sar コマンド ​`sar -d -p $INTERVAL $COUNT`​ を使用して監視します。 注目すべき主なメトリクスは次のとおりです。 - `await`​、デバイスを処理するために発行された I/O 要求の平均時間 (要求がキューに登録されていた時間と処理に要した時間の合計) を表示。 - `%util`​、デバイスの帯域幅使用量に対する、I/O 要求が発行されていた CPU 時間のパーセンテージによりデバイス飽和を表示。 ![sar コマンドによるディスク統計情報](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-tuning-sar-disk.png) Figure 5. sar コマンドによるディスク統計情報 ## [](#ネットワークリソース)ネットワークリソース Mule はネットワーク経由でいくつかのサービスと通信するため、ネットワークの使用量が飽和してボトルネックになることがあります。これを管理するには、使用できる帯域幅を把握し、使用量を監視する必要があります。これを行うためのシンプルは方法は、sar コマンド ​`sar -n DEV $INTERVAL $COUNT`​ を使用することです。 注目すべき主なメトリクスは次のとおりです。 - `rxpck/s`​、1 秒間に受信したパケットの合計数を表示。 - `txpck/s`​、1 秒間に送信したパケットの合計数を表示。 ![sar コマンドによるネットワーク統計情報](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-tuning-sar-network.png) Figure 6. sar コマンドによるネットワーク統計情報 ## [](#cloudhub-の監視)CloudHub の監視 CloudHub 環境での Mule アプリケーションのパフォーマンスは、Anypoint Runtime Manager ダッシュボードまたは Anypoint Monitoring を使用して監視できます。 - Runtime Manager ダッシュボード このツールは、メッセージ数やトランザクション数、CPU やメモリの使用量、そして過去 1 時間、過去 24 時間、先週といった特定期間のメトリクスなど、パフォーマンスの重要なメトリクスを可視化します。 ![Runtime Manager ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-tuning-runtimemanager.png) Figure 7. Runtime Manager ダッシュボード - Anypoint Monitoring このツールは、リソースを視覚的に表現する組み込みダッシュボードやカスタムダッシュボードを使用して、パフォーマンスのメトリクスを追跡して可視化します。さらに、Anypoint Monitoring では、異常の検出、問題のトラブルシューティング、未加工データを見ているだけでは気付かないトレンドの表示なども行えます。 ![Anypoint Monitoring ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-tuning-anypointmonitoring.png) Figure 8. Anypoint Monitoring ダッシュボード ## [](#関連情報)関連情報 - [top Linux コマンド](https://man7.org/linux/man-pages/man1/top.1.html) - [sar Linux コマンド](https://linux.die.net/man/1/sar) # パフォーマンス監視 パフォーマンステストのベストプラクティスを補うため、Mule Runtime Engine (Mule) がテスト中にコンシュームするリソースを監視します。それぞれの主なシステムリソースを監視するために最も重要なメトリクスと、CloudHub の監視で使用するツールについて以下に説明します。 以下に示すリソース監視コマンドは、sysstat がインストールされている Linux OS で使用できます。 ## [](#cpu-リソース)CPU リソース 負荷が増大すると CPU リソースが枯渇することがあります。これらのリソースはいくつかの方法で監視できます。その中から 2 つを紹介します。 - top コマンド: `top` `%CPU`​ メトリクスは、CPU 使用量をコア数で割った値です。 ![top コマンドによる CPU 統計情報](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-tuning-monitoring-top.png) Figure 1. top コマンドによる CPU 統計情報 - sar コマンド: `sar -u ALL $INTERVAL $COUNT` `$INTERVAL`​ はメトリクスを取得する時間間隔を指定し、​`$COUNT`​ は収集するデータポイント数を指定します。 注目すべき主なメトリクスは次のとおりです。 - `%sys`​、システムレベル (カーネル) での CPU 使用量を表示 - `%idle`​、CPU のアイドル時間のパーセンテージを表示 ![sar コマンドによる CPU 統計情報](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-tuning-sar-cpu.png) Figure 2. sar コマンドによる CPU 統計情報 ## [](#メモリリソース)メモリリソース ヒープやネイティブメモリ、オフヒープバッファなど、Mule によるメモリ使用状況を理解するため、メモリをいくつかの方法で監視します。その中から 2 つを紹介します。 - GC ログ GC (ガベージコレクション) のログを有効にして、割り当てレート、オブジェクトの増大などの情報を入手します。また、ヒープでのアクティビティに関する情報も入手します。GC ログを有効にすると、ディスクオーバーヘッドが若干増大します。 ![wrapper.conf](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-tuning-wrapper.png) Figure 3. CG ログ wrapper.conf - sar コマンド: `sar -r $INTERVAL $COUNT` 注目すべき主なメトリクスは次のとおりです。 - `kbmemfree`​、使用できるメモリ量をキロバイト数で表示 - `kbmemused`​、使用中のメモリ量をキロバイト数で表示 - `kbcommit`​、現在のワークロードに必要な RAM またはスワップメモリの量をキロバイト数で表示 ![sar コマンドによるメモリ統計情報](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-tuning-sar-memory.png) Figure 4. sar コマンドによるメモリ統計情報 ## [](#ディスクリソース)ディスクリソース 一部の Mule コンポーネントは、反復可能ストリームとして処理された大きなペイロードによって I/O (入出力) 要求が大量に発生し、リソースが大量に枯渇した書き込み操作やシナリオをログに記録します。ディスクリソースは sar コマンド ​`sar -d -p $INTERVAL $COUNT`​ を使用して監視します。 注目すべき主なメトリクスは次のとおりです。 - `await`​、デバイスを処理するために発行された I/O 要求の平均時間 (要求がキューに登録されていた時間と処理に要した時間の合計) を表示。 - `%util`​、デバイスの帯域幅使用量に対する、I/O 要求が発行されていた CPU 時間のパーセンテージによりデバイス飽和を表示。 ![sar コマンドによるディスク統計情報](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-tuning-sar-disk.png) Figure 5. sar コマンドによるディスク統計情報 ## [](#ネットワークリソース)ネットワークリソース Mule はネットワーク経由でいくつかのサービスと通信するため、ネットワークの使用量が飽和してボトルネックになることがあります。これを管理するには、使用できる帯域幅を把握し、使用量を監視する必要があります。これを行うためのシンプルは方法は、sar コマンド ​`sar -n DEV $INTERVAL $COUNT`​ を使用することです。 注目すべき主なメトリクスは次のとおりです。 - `rxpck/s`​、1 秒間に受信したパケットの合計数を表示。 - `txpck/s`​、1 秒間に送信したパケットの合計数を表示。 ![sar コマンドによるネットワーク統計情報](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-tuning-sar-network.png) Figure 6. sar コマンドによるネットワーク統計情報 ## [](#cloudhub-の監視)CloudHub の監視 CloudHub 環境での Mule アプリケーションのパフォーマンスは、Anypoint Runtime Manager ダッシュボードまたは Anypoint Monitoring を使用して監視できます。 - Runtime Manager ダッシュボード このツールは、メッセージ数やトランザクション数、CPU やメモリの使用量、そして過去 1 時間、過去 24 時間、先週といった特定期間のメトリクスなど、パフォーマンスの重要なメトリクスを可視化します。 ![Runtime Manager ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-tuning-runtimemanager.png) Figure 7. Runtime Manager ダッシュボード - Anypoint Monitoring このツールは、リソースを視覚的に表現する組み込みダッシュボードやカスタムダッシュボードを使用して、パフォーマンスのメトリクスを追跡して可視化します。さらに、Anypoint Monitoring では、異常の検出、問題のトラブルシューティング、未加工データを見ているだけでは気付かないトレンドの表示なども行えます。 ![Anypoint Monitoring ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-tuning-anypointmonitoring.png) Figure 8. Anypoint Monitoring ダッシュボード ## [](#関連情報)関連情報 - [top Linux コマンド](https://man7.org/linux/man-pages/man1/top.1.html) - [sar Linux コマンド](https://linux.die.net/man/1/sar) # パフォーマンス監視 パフォーマンステストのベストプラクティスを補うため、Mule Runtime Engine (Mule) がテスト中にコンシュームするリソースを監視します。それぞれの主なシステムリソースを監視するために最も重要なメトリクスと、CloudHub の監視で使用するツールについて以下に説明します。 以下に示すリソース監視コマンドは、sysstat がインストールされている Linux OS で使用できます。 ## [](#cpu-リソース)CPU リソース 負荷が増大すると CPU リソースが枯渇することがあります。これらのリソースはいくつかの方法で監視できます。その中から 2 つを紹介します。 - top コマンド: `top` `%CPU`​ メトリクスは、CPU 使用量をコア数で割った値です。 ![top コマンドによる CPU 統計情報](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-tuning-monitoring-top.png) Figure 1. top コマンドによる CPU 統計情報 - sar コマンド: `sar -u ALL $INTERVAL $COUNT` `$INTERVAL`​ はメトリクスを取得する時間間隔を指定し、​`$COUNT`​ は収集するデータポイント数を指定します。 注目すべき主なメトリクスは次のとおりです。 - `%sys`​、システムレベル (カーネル) での CPU 使用量を表示 - `%idle`​、CPU のアイドル時間のパーセンテージを表示 ![sar コマンドによる CPU 統計情報](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-tuning-sar-cpu.png) Figure 2. sar コマンドによる CPU 統計情報 ## [](#メモリリソース)メモリリソース ヒープやネイティブメモリ、オフヒープバッファなど、Mule によるメモリ使用状況を理解するため、メモリをいくつかの方法で監視します。その中から 2 つを紹介します。 - GC ログ GC (ガベージコレクション) のログを有効にして、割り当てレート、オブジェクトの増大などの情報を入手します。また、ヒープでのアクティビティに関する情報も入手します。GC ログを有効にすると、ディスクオーバーヘッドが若干増大します。 ![wrapper.conf](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-tuning-wrapper.png) Figure 3. CG ログ wrapper.conf - sar コマンド: `sar -r $INTERVAL $COUNT` 注目すべき主なメトリクスは次のとおりです。 - `kbmemfree`​、使用できるメモリ量をキロバイト数で表示 - `kbmemused`​、使用中のメモリ量をキロバイト数で表示 - `kbcommit`​、現在のワークロードに必要な RAM またはスワップメモリの量をキロバイト数で表示 ![sar コマンドによるメモリ統計情報](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-tuning-sar-memory.png) Figure 4. sar コマンドによるメモリ統計情報 ## [](#ディスクリソース)ディスクリソース 一部の Mule コンポーネントは、反復可能ストリームとして処理された大きなペイロードによって I/O (入出力) 要求が大量に発生し、リソースが大量に枯渇した書き込み操作やシナリオをログに記録します。ディスクリソースは sar コマンド ​`sar -d -p $INTERVAL $COUNT`​ を使用して監視します。 注目すべき主なメトリクスは次のとおりです。 - `await`​、デバイスを処理するために発行された I/O 要求の平均時間 (要求がキューに登録されていた時間と処理に要した時間の合計) を表示。 - `%util`​、デバイスの帯域幅使用量に対する、I/O 要求が発行されていた CPU 時間のパーセンテージによりデバイス飽和を表示。 ![sar コマンドによるディスク統計情報](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-tuning-sar-disk.png) Figure 5. sar コマンドによるディスク統計情報 ## [](#ネットワークリソース)ネットワークリソース Mule はネットワーク経由でいくつかのサービスと通信するため、ネットワークの使用量が飽和してボトルネックになることがあります。これを管理するには、使用できる帯域幅を把握し、使用量を監視する必要があります。これを行うためのシンプルは方法は、sar コマンド ​`sar -n DEV $INTERVAL $COUNT`​ を使用することです。 注目すべき主なメトリクスは次のとおりです。 - `rxpck/s`​、1 秒間に受信したパケットの合計数を表示。 - `txpck/s`​、1 秒間に送信したパケットの合計数を表示。 ![sar コマンドによるネットワーク統計情報](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-tuning-sar-network.png) Figure 6. sar コマンドによるネットワーク統計情報 ## [](#cloudhub-の監視)CloudHub の監視 CloudHub 環境での Mule アプリケーションのパフォーマンスは、Anypoint Runtime Manager ダッシュボードまたは Anypoint Monitoring を使用して監視できます。 - Runtime Manager ダッシュボード このツールは、メッセージ数やトランザクション数、CPU やメモリの使用量、そして過去 1 時間、過去 24 時間、先週といった特定期間のメトリクスなど、パフォーマンスの重要なメトリクスを可視化します。 ![Runtime Manager ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-tuning-runtimemanager.png) Figure 7. Runtime Manager ダッシュボード - Anypoint Monitoring このツールは、リソースを視覚的に表現する組み込みダッシュボードやカスタムダッシュボードを使用して、パフォーマンスのメトリクスを追跡して可視化します。さらに、Anypoint Monitoring では、異常の検出、問題のトラブルシューティング、未加工データを見ているだけでは気付かないトレンドの表示なども行えます。 ![Anypoint Monitoring ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-tuning-anypointmonitoring.png) Figure 8. Anypoint Monitoring ダッシュボード ## [](#関連情報)関連情報 - [top Linux コマンド](https://man7.org/linux/man-pages/man1/top.1.html) - [sar Linux コマンド](https://linux.die.net/man/1/sar) # パフォーマンス監視 パフォーマンステストのベストプラクティスを補うため、Mule Runtime Engine (Mule) がテスト中にコンシュームするリソースを監視します。それぞれの主なシステムリソースを監視するために最も重要なメトリクスと、CloudHub の監視で使用するツールについて以下に説明します。 以下に示すリソース監視コマンドは、sysstat がインストールされている Linux OS で使用できます。 ## [](#cpu-リソース)CPU リソース 負荷が増大すると CPU リソースが枯渇することがあります。これらのリソースはいくつかの方法で監視できます。その中から 2 つを紹介します。 - top コマンド: `top` `%CPU`​ メトリクスは、CPU 使用量をコア数で割った値です。 ![top コマンドによる CPU 統計情報](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-tuning-monitoring-top.png) Figure 1. top コマンドによる CPU 統計情報 - sar コマンド: `sar -u ALL $INTERVAL $COUNT` `$INTERVAL`​ はメトリクスを取得する時間間隔を指定し、​`$COUNT`​ は収集するデータポイント数を指定します。 注目すべき主なメトリクスは次のとおりです。 - `%sys`​、システムレベル (カーネル) での CPU 使用量を表示 - `%idle`​、CPU のアイドル時間のパーセンテージを表示 ![sar コマンドによる CPU 統計情報](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-tuning-sar-cpu.png) Figure 2. sar コマンドによる CPU 統計情報 ## [](#メモリリソース)メモリリソース ヒープやネイティブメモリ、オフヒープバッファなど、Mule によるメモリ使用状況を理解するため、メモリをいくつかの方法で監視します。その中から 2 つを紹介します。 - GC ログ GC (ガベージコレクション) のログを有効にして、割り当てレート、オブジェクトの増大などの情報を入手します。また、ヒープでのアクティビティに関する情報も入手します。GC ログを有効にすると、ディスクオーバーヘッドが若干増大します。 ![wrapper.conf](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-tuning-wrapper.png) Figure 3. CG ログ wrapper.conf - sar コマンド: `sar -r $INTERVAL $COUNT` 注目すべき主なメトリクスは次のとおりです。 - `kbmemfree`​、使用できるメモリ量をキロバイト数で表示 - `kbmemused`​、使用中のメモリ量をキロバイト数で表示 - `kbcommit`​、現在のワークロードに必要な RAM またはスワップメモリの量をキロバイト数で表示 ![sar コマンドによるメモリ統計情報](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-tuning-sar-memory.png) Figure 4. sar コマンドによるメモリ統計情報 ## [](#ディスクリソース)ディスクリソース 一部の Mule コンポーネントは、反復可能ストリームとして処理された大きなペイロードによって I/O (入出力) 要求が大量に発生し、リソースが大量に枯渇した書き込み操作やシナリオをログに記録します。ディスクリソースは sar コマンド ​`sar -d -p $INTERVAL $COUNT`​ を使用して監視します。 注目すべき主なメトリクスは次のとおりです。 - `await`​、デバイスを処理するために発行された I/O 要求の平均時間 (要求がキューに登録されていた時間と処理に要した時間の合計) を表示。 - `%util`​、デバイスの帯域幅使用量に対する、I/O 要求が発行されていた CPU 時間のパーセンテージによりデバイス飽和を表示。 ![sar コマンドによるディスク統計情報](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-tuning-sar-disk.png) Figure 5. sar コマンドによるディスク統計情報 ## [](#ネットワークリソース)ネットワークリソース Mule はネットワーク経由でいくつかのサービスと通信するため、ネットワークの使用量が飽和してボトルネックになることがあります。これを管理するには、使用できる帯域幅を把握し、使用量を監視する必要があります。これを行うためのシンプルは方法は、sar コマンド ​`sar -n DEV $INTERVAL $COUNT`​ を使用することです。 注目すべき主なメトリクスは次のとおりです。 - `rxpck/s`​、1 秒間に受信したパケットの合計数を表示。 - `txpck/s`​、1 秒間に送信したパケットの合計数を表示。 ![sar コマンドによるネットワーク統計情報](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-tuning-sar-network.png) Figure 6. sar コマンドによるネットワーク統計情報 ## [](#cloudhub-の監視)CloudHub の監視 CloudHub 環境での Mule アプリケーションのパフォーマンスは、Anypoint Runtime Manager ダッシュボードまたは Anypoint Monitoring を使用して監視できます。 - Runtime Manager ダッシュボード このツールは、メッセージ数やトランザクション数、CPU やメモリの使用量、そして過去 1 時間、過去 24 時間、先週といった特定期間のメトリクスなど、パフォーマンスの重要なメトリクスを可視化します。 ![Runtime Manager ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-tuning-runtimemanager.png) Figure 7. Runtime Manager ダッシュボード - Anypoint Monitoring このツールは、リソースを視覚的に表現する組み込みダッシュボードやカスタムダッシュボードを使用して、パフォーマンスのメトリクスを追跡して可視化します。さらに、Anypoint Monitoring では、異常の検出、問題のトラブルシューティング、未加工データを見ているだけでは気付かないトレンドの表示なども行えます。 ![Anypoint Monitoring ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-tuning-anypointmonitoring.png) Figure 8. Anypoint Monitoring ダッシュボード ## [](#関連情報)関連情報 - [top Linux コマンド](https://man7.org/linux/man-pages/man1/top.1.html) - [sar Linux コマンド](https://linux.die.net/man/1/sar) # パフォーマンス監視 パフォーマンステストのベストプラクティスを補うため、Mule Runtime Engine (Mule) がテスト中にコンシュームするリソースを監視します。それぞれの主なシステムリソースを監視するために最も重要なメトリクスと、CloudHub の監視で使用するツールについて以下に説明します。 以下に示すリソース監視コマンドは、sysstat がインストールされている Linux OS で使用できます。 ## [](#cpu-リソース)CPU リソース 負荷が増大すると CPU リソースが枯渇することがあります。これらのリソースはいくつかの方法で監視できます。その中から 2 つを紹介します。 - top コマンド: `top` `%CPU`​ メトリクスは、CPU 使用量をコア数で割った値です。 ![プロセスの詳細 (CPU やメモリ使用量など) が表示されているシステム監視出力](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-tuning-monitoring-top.png) Figure 1. top コマンドによる CPU 統計情報 - sar コマンド: `sar -u ALL $INTERVAL $COUNT` `$INTERVAL`​ はメトリクスを取得する時間間隔を指定し、​`$COUNT`​ は収集するデータポイント数を指定します。 注目すべき主なメトリクスは次のとおりです。 - `%sys`​、システムレベル (カーネル) での CPU 使用量を表示 - `%idle`​、CPU のアイドル時間のパーセンテージを表示 ![CPU 使用量の統計情報 (ユーザー時間やシステム時間) が表示されているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-tuning-sar-cpu.png) Figure 2. sar コマンドによる CPU 統計情報 ## [](#メモリリソース)メモリリソース ヒープやネイティブメモリ、オフヒープバッファなど、Mule によるメモリ使用状況を理解するため、メモリをいくつかの方法で監視します。その中から 2 つを紹介します。 - GC ログ GC (ガベージコレクション) のログを有効にして、割り当てレート、オブジェクトの増大などの情報を入手します。また、ヒープでのアクティビティに関する情報も入手します。GC ログを有効にすると、ディスクオーバーヘッドが若干増大します。 ![設定ファイルで定義された Java 仮想マシンオプションがリストされているテキスト](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-tuning-wrapper.png) Figure 3. CG ログ wrapper.conf - sar コマンド: `sar -r $INTERVAL $COUNT` 注目すべき主なメトリクスは次のとおりです。 - `kbmemfree`​、使用できるメモリ量をキロバイト数で表示 - `kbmemused`​、使用中のメモリ量をキロバイト数で表示 - `kbcommit`​、現在のワークロードに必要な RAM またはスワップメモリの量をキロバイト数で表示 ![メモリ使用量の統計情報 (時間、空きメモリ、使用メモリ、キャッシュサイズなどの列) が表示されているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-tuning-sar-memory.png) Figure 4. sar コマンドによるメモリ統計情報 ## [](#ディスクリソース)ディスクリソース 一部の Mule コンポーネントは、反復可能ストリームとして処理された大きなペイロードによって I/O (入出力) 要求が大量に発生し、リソースが大量に枯渇した書き込み操作やシナリオをログに記録します。ディスクリソースは sar コマンド ​`sar -d -p $INTERVAL $COUNT`​ を使用して監視します。 注目すべき主なメトリクスは次のとおりです。 - `await`​、デバイスを処理するために発行された I/O 要求の平均時間 (要求がキューに登録されていた時間と処理に要した時間の合計) を表示。 - `%util`​、デバイスの帯域幅使用量に対する、I/O 要求が発行されていた CPU 時間のパーセンテージによりデバイス飽和を表示。 ![ディスク I/O の統計情報 (トランザクション/秒や読み取り/書き込みセクターなどの列) が表示されているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-tuning-sar-disk.png) Figure 5. sar コマンドによるディスク統計情報 ## [](#ネットワークリソース)ネットワークリソース Mule はネットワーク経由でいくつかのサービスと通信するため、ネットワークの使用量が飽和してボトルネックになることがあります。これを管理するには、使用できる帯域幅を把握し、使用量を監視する必要があります。これを行うためのシンプルは方法は、sar コマンド ​`sar -n DEV $INTERVAL $COUNT`​ を使用することです。 注目すべき主なメトリクスは次のとおりです。 - `rxpck/s`​、1 秒間に受信したパケットの合計数を表示。 - `txpck/s`​、1 秒間に送信したパケットの合計数を表示。 ![ネットワークインターフェースの詳細な統計情報 (送受信パケットおよびバイトなど) が表示されているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-tuning-sar-network.png) Figure 6. sar コマンドによるネットワーク統計情報 ## [](#cloudhub-の監視)CloudHub の監視 CloudHub 環境での Mule アプリケーションのパフォーマンスは、Anypoint Runtime Manager ダッシュボードまたは Anypoint Monitoring を使用して監視できます。 - Runtime Manager ダッシュボード このツールは、メッセージ数やトランザクション数、CPU やメモリの使用量、そして過去 1 時間、過去 24 時間、先週といった特定期間のメトリクスなど、パフォーマンスの重要なメトリクスを可視化します。 ![Runtime Manager の経時的な CPU 使用量やメモリ使用量が表示されている折れ線グラフ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-tuning-runtimemanager.png) Figure 7. Runtime Manager ダッシュボード - Anypoint Monitoring このツールは、リソースを視覚的に表現する組み込みダッシュボードやカスタムダッシュボードを使用して、パフォーマンスのメトリクスを追跡して可視化します。さらに、Anypoint Monitoring では、異常の検出、問題のトラブルシューティング、未加工データを見ているだけでは気付かないトレンドの表示なども行えます。 ![Mule アプリケーションの CPU 使用量やメモリ使用量の統計情報が表示されている Anypoint Monitoring ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-tuning-anypointmonitoring.png) Figure 8. Anypoint Monitoring ダッシュボード ## [](#関連情報)関連情報 - [top Linux コマンド](https://man7.org/linux/man-pages/man1/top.1.html) - [sar Linux コマンド](https://linux.die.net/man/1/sar) # パフォーマンス監視 パフォーマンステストのベストプラクティスを補うため、Mule Runtime Engine (Mule) がテスト中にコンシュームするリソースを監視します。それぞれの主なシステムリソースを監視するために最も重要なメトリクスと、CloudHub の監視で使用するツールについて以下に説明します。 以下に示すリソース監視コマンドは、sysstat がインストールされている Linux OS で使用できます。 ## [](#cpu-リソース)CPU リソース 負荷が増大すると CPU リソースが枯渇することがあります。これらのリソースはいくつかの方法で監視できます。その中から 2 つを紹介します。 - top コマンド: `top` `%CPU`​ メトリクスは、CPU 使用量をコア数で割った値です。 ![プロセスの詳細 (CPU やメモリ使用量など) が表示されているシステム監視出力](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-tuning-monitoring-top.png) Figure 1. top コマンドによる CPU 統計情報 - sar コマンド: `sar -u ALL $INTERVAL $COUNT` `$INTERVAL`​ はメトリクスを取得する時間間隔を指定し、​`$COUNT`​ は収集するデータポイント数を指定します。 注目すべき主なメトリクスは次のとおりです。 - `%sys`​、システムレベル (カーネル) での CPU 使用量を表示 - `%idle`​、CPU のアイドル時間のパーセンテージを表示 ![CPU 使用量の統計情報 (ユーザー時間やシステム時間) が表示されているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-tuning-sar-cpu.png) Figure 2. sar コマンドによる CPU 統計情報 ## [](#メモリリソース)メモリリソース ヒープやネイティブメモリ、オフヒープバッファなど、Mule によるメモリ使用状況を理解するため、メモリをいくつかの方法で監視します。その中から 2 つを紹介します。 - GC ログ GC (ガベージコレクション) のログを有効にして、割り当てレート、オブジェクトの増大などの情報を入手します。また、ヒープでのアクティビティに関する情報も入手します。GC ログを有効にすると、ディスクオーバーヘッドが若干増大します。 ![設定ファイルで定義された Java 仮想マシンオプションがリストされているテキスト](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-tuning-wrapper.png) Figure 3. CG ログ wrapper.conf - sar コマンド: `sar -r $INTERVAL $COUNT` 注目すべき主なメトリクスは次のとおりです。 - `kbmemfree`​、使用できるメモリ量をキロバイト数で表示 - `kbmemused`​、使用中のメモリ量をキロバイト数で表示 - `kbcommit`​、現在のワークロードに必要な RAM またはスワップメモリの量をキロバイト数で表示 ![メモリ使用量の統計情報 (時間、空きメモリ、使用メモリ、キャッシュサイズなどの列) が表示されているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-tuning-sar-memory.png) Figure 4. sar コマンドによるメモリ統計情報 ## [](#ディスクリソース)ディスクリソース 一部の Mule コンポーネントは、反復可能ストリームとして処理された大きなペイロードによって I/O (入出力) 要求が大量に発生し、リソースが大量に枯渇した書き込み操作やシナリオをログに記録します。ディスクリソースは sar コマンド ​`sar -d -p $INTERVAL $COUNT`​ を使用して監視します。 注目すべき主なメトリクスは次のとおりです。 - `await`​、デバイスを処理するために発行された I/O 要求の平均時間 (要求がキューに登録されていた時間と処理に要した時間の合計) を表示。 - `%util`​、デバイスの帯域幅使用量に対する、I/O 要求が発行されていた CPU 時間のパーセンテージによりデバイス飽和を表示。 ![ディスク I/O の統計情報 (トランザクション/秒や読み取り/書き込みセクターなどの列) が表示されているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-tuning-sar-disk.png) Figure 5. sar コマンドによるディスク統計情報 ## [](#ネットワークリソース)ネットワークリソース Mule はネットワーク経由でいくつかのサービスと通信するため、ネットワークの使用量が飽和してボトルネックになることがあります。これを管理するには、使用できる帯域幅を把握し、使用量を監視する必要があります。これを行うためのシンプルは方法は、sar コマンド ​`sar -n DEV $INTERVAL $COUNT`​ を使用することです。 注目すべき主なメトリクスは次のとおりです。 - `rxpck/s`​、1 秒間に受信したパケットの合計数を表示。 - `txpck/s`​、1 秒間に送信したパケットの合計数を表示。 ![ネットワークインターフェースの詳細な統計情報 (送受信パケットおよびバイトなど) が表示されているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-tuning-sar-network.png) Figure 6. sar コマンドによるネットワーク統計情報 ## [](#cloudhub-の監視)CloudHub の監視 CloudHub 環境での Mule アプリケーションのパフォーマンスは、Anypoint Runtime Manager ダッシュボードまたは Anypoint Monitoring を使用して監視できます。 - Runtime Manager ダッシュボード このツールは、メッセージ数やトランザクション数、CPU やメモリの使用量、そして過去 1 時間、過去 24 時間、先週といった特定期間のメトリクスなど、パフォーマンスの重要なメトリクスを可視化します。 ![Runtime Manager の経時的な CPU 使用量やメモリ使用量が表示されている折れ線グラフ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-tuning-runtimemanager.png) Figure 7. Runtime Manager ダッシュボード - Anypoint Monitoring このツールは、リソースを視覚的に表現する組み込みダッシュボードやカスタムダッシュボードを使用して、パフォーマンスのメトリクスを追跡して可視化します。さらに、Anypoint Monitoring では、異常の検出、問題のトラブルシューティング、未加工データを見ているだけでは気付かないトレンドの表示なども行えます。 ![Mule アプリケーションの CPU 使用量やメモリ使用量の統計情報が表示されている Anypoint Monitoring ダッシュボード](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-tuning-anypointmonitoring.png) Figure 8. Anypoint Monitoring ダッシュボード ## [](#関連情報)関連情報 - [top Linux コマンド](https://man7.org/linux/man-pages/man1/top.1.html) - [sar Linux コマンド](https://linux.die.net/man/1/sar) # ビジネスイベント Mule アプリケーションは、​_ビジネストランザクション_​を処理するフローおよびメッセージプロセッサーに関する​_ビジネスイベント情報_​ (トランザクションの実行時間、エラー、成功または失敗の結果、メッセージペイロード情報など) を収集します。 - イベントはメッセージプロセッサーとコネクタにマップされるものであり、トランザクションの低レベルの詳細です。イベントは一括処理ではサポートされません。 - トランザクションは関連するイベントの論理的なグループ化であり、通常はフローレベルでシステムのビジネス面での視点に対応しています。 ## [](#ビジネスイベント種別)ビジネスイベント種別 _デフォルトイベント_​と​_カスタムイベント_​の 2 つの種別のビジネスイベントを追跡できます。 デフォルトイベント追跡は、すべてのコネクタと一部のメッセージプロセッサーでサポートされています。これらの要素のデフォルトイベントを有効にすると、実行時に高度なデバッグを実施できます。デフォルトイベント追跡は、フローレベルまたはメッセージプロセッサーレベルで有効にできます。 設定の詳細は、​[「デフォルトイベント追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events-in-components)​を参照してください。 カスタムイベント追跡は、Custom Business Event コンポーネントでサポートされています。カスタムイベントは常に追跡されるため、ビジネスに関連する、フローの高レベルのアクティビティを監視できます。 設定の詳細は、​[「Custom Business Event コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events-custom)​を参照してください。 ## [](#ビジネスイベントの監視)ビジネスイベントの監視 Runtime Manager のインサイトを有効にして、ビジネスイベントを実行時に監視できます。これらのイベントは、失敗の根本原因を分析したり、パフォーマンスのボトルネックを特定したり、会社の手続きに準拠しているかどうかをテストしたりするのに役立ちます。 特定のデフォルトイベントは、インサイトを有効にすると自動的に追跡されますが、他のイベントを追跡するには、アプリケーションでイベントを有効にする必要があります。 詳細は、​[インサイト](https://docs.mulesoft.com/jp/runtime-manager/insight)​のドキュメントを参照してください。 ## [](#ビジネスイベントのベストプラクティス)ビジネスイベントのベストプラクティス ビジネスイベント追跡を設定する場合は、以下の推奨事項を考慮してください。 - 特定の値のあるプロセスの場合にのみデフォルトイベントを有効にする。不要な情報を除外するには、ビジネストランザクション内のどのフェーズを追跡する必要があるかを決定し、そのフェーズに対してのみ追跡を有効にします。 - カスタムイベントを使用して、プロセスの重要指標 (注文合計金額や追跡番号など) を追跡し、フローの高レベルのビジネスアクティビティを明らかにする。 - トランザクションの有用な情報 (注文番号、従業員 ID 番号、出荷追跡番号など) が表示されるように、トランザクション ID をカスタマイズする。 これによって実行時に分析とデバッグが容易になり、より直感的に行えるようになります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-event) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events-in-components) - [Custom Business Event コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events-custom) # ビジネスイベント Mule アプリケーションは、​_ビジネストランザクション_​を処理するフローおよびメッセージプロセッサーに関する​_ビジネスイベント情報_​ (トランザクションの実行時間、エラー、成功または失敗の結果、メッセージペイロード情報など) を収集します。 - イベントはメッセージプロセッサーとコネクタにマップされるものであり、トランザクションの低レベルの詳細です。イベントは一括処理ではサポートされません。 - トランザクションは関連するイベントの論理的なグループ化であり、通常はフローレベルでシステムのビジネス面での視点に対応しています。 ## [](#ビジネスイベント種別)ビジネスイベント種別 _デフォルトイベント_​と​_カスタムイベント_​の 2 つの種別のビジネスイベントを追跡できます。 デフォルトイベント追跡は、すべてのコネクタと一部のメッセージプロセッサーでサポートされています。これらの要素のデフォルトイベントを有効にすると、実行時に高度なデバッグを実施できます。デフォルトイベント追跡は、フローレベルまたはメッセージプロセッサーレベルで有効にできます。 設定の詳細は、​[「デフォルトイベント追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events-in-components)​を参照してください。 カスタムイベント追跡は、Custom Business Event コンポーネントでサポートされています。カスタムイベントは常に追跡されるため、ビジネスに関連する、フローの高レベルの活動を監視できます。 設定の詳細は、​[「Custom Business Event コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events-custom)​を参照してください。 ## [](#ビジネスイベントの監視)ビジネスイベントの監視 Runtime Manager のインサイトを有効にして、ビジネスイベントを実行時に監視できます。これらのイベントは、失敗の根本原因を分析したり、パフォーマンスのボトルネックを特定したり、会社の手続きに準拠しているかどうかをテストしたりするのに役立ちます。 特定のデフォルトイベントは、インサイトを有効にすると自動的に追跡されますが、他のイベントを追跡するには、アプリケーションでイベントを有効にする必要があります。 詳細は、​[インサイト](https://docs.mulesoft.com/jp/runtime-manager/insight)​のドキュメントを参照してください。 ## [](#ビジネスイベントのベストプラクティス)ビジネスイベントのベストプラクティス ビジネスイベント追跡を設定する場合は、以下の推奨事項を考慮してください。 - 特定の値のあるプロセスの場合にのみデフォルトイベントを有効にする。不要な情報を除外するには、ビジネストランザクション内のどのフェーズを追跡する必要があるかを決定し、そのフェーズに対してのみ追跡を有効にします。 - カスタムイベントを使用して、プロセスの重要指標 (注文合計金額や追跡番号など) を追跡し、フローの高レベルのビジネス活動を明らかにする。 - トランザクションの有用な情報 (注文番号、従業員 ID 番号、出荷追跡番号など) が表示されるように、トランザクション ID をカスタマイズする。 これによって実行時に分析とデバッグが容易になり、より直感的に行えるようになります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-event) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events-in-components) - [Custom Business Event コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events-custom) # ビジネスイベント Mule アプリケーションは、​_ビジネストランザクション_​を処理するフローおよびメッセージプロセッサーに関する​_ビジネスイベント情報_​ (トランザクションの実行時間、エラー、成功または失敗の結果、メッセージペイロード情報など) を収集します。 - イベントはメッセージプロセッサーとコネクタにマップされるものであり、トランザクションの低レベルの詳細です。イベントは一括処理ではサポートされません。 - トランザクションは関連するイベントの論理的なグループ化であり、通常はフローレベルでシステムのビジネス面での視点に対応しています。 ## [](#ビジネスイベント種別)ビジネスイベント種別 _デフォルトイベント_​と​_カスタムイベント_​の 2 つの種別のビジネスイベントを追跡できます。 デフォルトイベント追跡は、すべてのコネクタと一部のメッセージプロセッサーでサポートされています。これらの要素のデフォルトイベントを有効にすると、実行時に高度なデバッグを実施できます。デフォルトイベント追跡は、フローレベルまたはメッセージプロセッサーレベルで有効にできます。 設定の詳細は、​[「デフォルトイベント追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events-in-components)​を参照してください。 カスタムイベント追跡は、Custom Business Event コンポーネントでサポートされています。カスタムイベントは常に追跡されるため、ビジネスに関連する、フローの高レベルのアクティビティを監視できます。 設定の詳細は、​[「Custom Business Event コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events-custom)​を参照してください。 ## [](#ビジネスイベントの監視)ビジネスイベントの監視 Runtime Manager のインサイトを有効にして、ビジネスイベントを実行時に監視できます。これらのイベントは、失敗の根本原因を分析したり、パフォーマンスのボトルネックを特定したり、会社の手続きに準拠しているかどうかをテストしたりするのに役立ちます。 特定のデフォルトイベントは、インサイトを有効にすると自動的に追跡されますが、他のイベントを追跡するには、アプリケーションでイベントを有効にする必要があります。 詳細は、​[インサイト](https://docs.mulesoft.com/jp/runtime-manager/insight)​のドキュメントを参照してください。 ## [](#ビジネスイベントのベストプラクティス)ビジネスイベントのベストプラクティス ビジネスイベント追跡を設定する場合は、以下の推奨事項を考慮してください。 - 特定の値のあるプロセスの場合にのみデフォルトイベントを有効にする。不要な情報を除外するには、ビジネストランザクション内のどのフェーズを追跡する必要があるかを決定し、そのフェーズに対してのみ追跡を有効にします。 - カスタムイベントを使用して、プロセスの重要指標 (注文合計金額や追跡番号など) を追跡し、フローの高レベルのビジネスアクティビティを明らかにする。 - トランザクションの有用な情報 (注文番号、従業員 ID 番号、出荷追跡番号など) が表示されるように、トランザクション ID をカスタマイズする。 これによって実行時に分析とデバッグが容易になり、より直感的に行えるようになります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-event) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events-in-components) - [Custom Business Event コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events-custom) # ビジネスイベント Mule アプリケーションは、​_ビジネストランザクション_​を処理するフローおよびメッセージプロセッサーに関する​_ビジネスイベント情報_​ (トランザクションの実行時間、エラー、成功または失敗の結果、メッセージペイロード情報など) を収集します。 - イベントはメッセージプロセッサーとコネクタにマップされるものであり、トランザクションの低レベルの詳細です。イベントは一括処理ではサポートされません。 - トランザクションは関連するイベントの論理的なグループ化であり、通常はフローレベルでシステムのビジネス面での視点に対応しています。 ## [](#ビジネスイベント種別)ビジネスイベント種別 _デフォルトイベント_​と​_カスタムイベント_​の 2 つの種別のビジネスイベントを追跡できます。 デフォルトイベント追跡は、すべてのコネクタと一部のメッセージプロセッサーでサポートされています。これらの要素のデフォルトイベントを有効にすると、実行時に高度なデバッグを実施できます。デフォルトイベント追跡は、フローレベルまたはメッセージプロセッサーレベルで有効にできます。 設定の詳細は、​[「デフォルトイベント追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events-in-components)​を参照してください。 カスタムイベント追跡は、Custom Business Event コンポーネントでサポートされています。カスタムイベントは常に追跡されるため、ビジネスに関連する、フローの高レベルの活動を監視できます。 設定の詳細は、​[「Custom Business Event コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events-custom)​を参照してください。 ## [](#ビジネスイベントの監視)ビジネスイベントの監視 Runtime Manager のインサイトを有効にして、ビジネスイベントを実行時に監視できます。これらのイベントは、失敗の根本原因を分析したり、パフォーマンスのボトルネックを特定したり、会社の手続きに準拠しているかどうかをテストしたりするのに役立ちます。 特定のデフォルトイベントは、インサイトを有効にすると自動的に追跡されますが、他のイベントを追跡するには、アプリケーションでイベントを有効にする必要があります。 詳細は、​[インサイト](https://docs.mulesoft.com/jp/runtime-manager/insight)​のドキュメントを参照してください。 ## [](#ビジネスイベントのベストプラクティス)ビジネスイベントのベストプラクティス ビジネスイベント追跡を設定する場合は、以下の推奨事項を考慮してください。 - 特定の値のあるプロセスの場合にのみデフォルトイベントを有効にする。不要な情報を除外するには、ビジネストランザクション内のどのフェーズを追跡する必要があるかを決定し、そのフェーズに対してのみ追跡を有効にします。 - カスタムイベントを使用して、プロセスの重要指標 (注文合計金額や追跡番号など) を追跡し、フローの高レベルのビジネス活動を明らかにする。 - トランザクションの有用な情報 (注文番号、従業員 ID 番号、出荷追跡番号など) が表示されるように、トランザクション ID をカスタマイズする。 これによって実行時に分析とデバッグが容易になり、より直感的に行えるようになります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-event) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events-in-components) - [Custom Business Event コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events-custom) # ビジネスイベント Mule アプリケーションは、​_ビジネストランザクション_​を処理するフローおよびメッセージプロセッサーに関する​_ビジネスイベント情報_​ (トランザクションの実行時間、エラー、成功または失敗の結果、メッセージペイロード情報など) を収集します。 - イベントはメッセージプロセッサーとコネクタにマップされるものであり、トランザクションの低レベルの詳細です。イベントは一括処理ではサポートされません。 - トランザクションは関連するイベントの論理的なグループ化であり、通常はフローレベルでシステムのビジネス面での視点に対応しています。 ## [](#ビジネスイベント種別)ビジネスイベント種別 _デフォルトイベント_​と​_カスタムイベント_​の 2 つの種別のビジネスイベントを追跡できます。 デフォルトイベント追跡は、すべてのコネクタと一部のメッセージプロセッサーでサポートされています。これらの要素のデフォルトイベントを有効にすると、実行時に高度なデバッグを実施できます。デフォルトイベント追跡は、フローレベルまたはメッセージプロセッサーレベルで有効にできます。 設定の詳細は、​[「デフォルトイベント追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events-in-components)​を参照してください。 カスタムイベント追跡は、Custom Business Event コンポーネントでサポートされています。カスタムイベントは常に追跡されるため、ビジネスに関連する、フローの高レベルの活動を監視できます。 設定の詳細は、​[「Custom Business Event コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events-custom)​を参照してください。 ## [](#ビジネスイベントの監視)ビジネスイベントの監視 Runtime Manager のインサイトを有効にして、ビジネスイベントを実行時に監視できます。これらのイベントは、失敗の根本原因を分析したり、パフォーマンスのボトルネックを特定したり、会社の手続きに準拠しているかどうかをテストしたりするのに役立ちます。 特定のデフォルトイベントは、インサイトを有効にすると自動的に追跡されますが、他のイベントを追跡するには、アプリケーションでイベントを有効にする必要があります。 詳細は、​[インサイト](https://docs.mulesoft.com/jp/runtime-manager/insight)​のドキュメントを参照してください。 ## [](#ビジネスイベントのベストプラクティス)ビジネスイベントのベストプラクティス ビジネスイベント追跡を設定する場合は、以下の推奨事項を考慮してください。 - 特定の値のあるプロセスの場合にのみデフォルトイベントを有効にする。不要な情報を除外するには、ビジネストランザクション内のどのフェーズを追跡する必要があるかを決定し、そのフェーズに対してのみ追跡を有効にします。 - カスタムイベントを使用して、プロセスの重要指標 (注文合計金額や追跡番号など) を追跡し、フローの高レベルのビジネス活動を明らかにする。 - トランザクションの有用な情報 (注文番号、従業員 ID 番号、出荷追跡番号など) が表示されるように、トランザクション ID をカスタマイズする。 これによって実行時に分析とデバッグが容易になり、より直感的に行えるようになります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-event) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events-in-components) - [Custom Business Event コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events-custom) # ビジネスイベント Mule アプリケーションは、​_ビジネストランザクション_​を処理するフローおよびメッセージプロセッサーに関する​_ビジネスイベント情報_​ (トランザクションの実行時間、エラー、成功または失敗の結果、メッセージペイロード情報など) を収集します。 - イベントはメッセージプロセッサーとコネクタにマップされるものであり、トランザクションの低レベルの詳細です。イベントは一括処理ではサポートされません。 - トランザクションは関連するイベントの論理的なグループ化であり、通常はフローレベルでシステムのビジネス面での視点に対応しています。 ## [](#ビジネスイベント種別)ビジネスイベント種別 _デフォルトイベント_​と​_カスタムイベント_​の 2 つの種別のビジネスイベントを追跡できます。 デフォルトイベント追跡は、すべてのコネクタと一部のメッセージプロセッサーでサポートされています。これらの要素のデフォルトイベントを有効にすると、実行時に高度なデバッグを実施できます。デフォルトイベント追跡は、フローレベルまたはメッセージプロセッサーレベルで有効にできます。 設定の詳細は、​[「デフォルトイベント追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events-in-components)​を参照してください。 カスタムイベント追跡は、Custom Business Event コンポーネントでサポートされています。カスタムイベントは常に追跡されるため、ビジネスに関連する、フローの高レベルの活動を監視できます。 設定の詳細は、​[「Custom Business Event コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events-custom)​を参照してください。 ## [](#ビジネスイベントの監視)ビジネスイベントの監視 Runtime Manager のインサイトを有効にして、ビジネスイベントを実行時に監視できます。これらのイベントは、失敗の根本原因を分析したり、パフォーマンスのボトルネックを特定したり、会社の手続きに準拠しているかどうかをテストしたりするのに役立ちます。 特定のデフォルトイベントは、インサイトを有効にすると自動的に追跡されますが、他のイベントを追跡するには、アプリケーションでイベントを有効にする必要があります。 詳細は、​[インサイト](https://docs.mulesoft.com/jp/runtime-manager/insight)​のドキュメントを参照してください。 ## [](#ビジネスイベントのベストプラクティス)ビジネスイベントのベストプラクティス ビジネスイベント追跡を設定する場合は、以下の推奨事項を考慮してください。 - 特定の値のあるプロセスの場合にのみデフォルトイベントを有効にする。不要な情報を除外するには、ビジネストランザクション内のどのフェーズを追跡する必要があるかを決定し、そのフェーズに対してのみ追跡を有効にします。 - カスタムイベントを使用して、プロセスの重要指標 (注文合計金額や追跡番号など) を追跡し、フローの高レベルのビジネス活動を明らかにする。 - トランザクションの有用な情報 (注文番号、従業員 ID 番号、出荷追跡番号など) が表示されるように、トランザクション ID をカスタマイズする。 これによって実行時に分析とデバッグが容易になり、より直感的に行えるようになります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-event) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events-in-components) - [Custom Business Event コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events-custom) # ビジネスイベント Mule アプリケーションは、​_ビジネストランザクション_​を処理するフローおよびメッセージプロセッサーに関する​_ビジネスイベント情報_​ (トランザクションの実行時間、エラー、成功または失敗の結果、メッセージペイロード情報など) を収集します。 - イベントはメッセージプロセッサーとコネクタにマップされるものであり、トランザクションの低レベルの詳細です。イベントは一括処理ではサポートされません。 - トランザクションは関連するイベントの論理的なグループ化であり、通常はフローレベルでシステムのビジネス面での視点に対応しています。 ## [](#ビジネスイベント種別)ビジネスイベント種別 _デフォルトイベント_​と​_カスタムイベント_​の 2 つの種別のビジネスイベントを追跡できます。 デフォルトイベント追跡は、すべてのコネクタと一部のメッセージプロセッサーでサポートされています。これらの要素のデフォルトイベントを有効にすると、実行時に高度なデバッグを実施できます。デフォルトイベント追跡は、フローレベルまたはメッセージプロセッサーレベルで有効にできます。 設定の詳細は、​[「デフォルトイベント追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events-in-components)​を参照してください。 カスタムイベント追跡は、Custom Business Event コンポーネントでサポートされています。カスタムイベントは常に追跡されるため、ビジネスに関連する、フローの高レベルの活動を監視できます。 設定の詳細は、​[「Custom Business Event コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events-custom)​を参照してください。 ## [](#ビジネスイベントの監視)ビジネスイベントの監視 Runtime Manager のインサイトを有効にして、ビジネスイベントを実行時に監視できます。これらのイベントは、失敗の根本原因を分析したり、パフォーマンスのボトルネックを特定したり、会社の手続きに準拠しているかどうかをテストしたりするのに役立ちます。 特定のデフォルトイベントは、インサイトを有効にすると自動的に追跡されますが、他のイベントを追跡するには、アプリケーションでイベントを有効にする必要があります。 詳細は、​[インサイト](https://docs.mulesoft.com/jp/runtime-manager/insight)​のドキュメントを参照してください。 ## [](#ビジネスイベントのベストプラクティス)ビジネスイベントのベストプラクティス ビジネスイベント追跡を設定する場合は、以下の推奨事項を考慮してください。 - 特定の値のあるプロセスの場合にのみデフォルトイベントを有効にする。不要な情報を除外するには、ビジネストランザクション内のどのフェーズを追跡する必要があるかを決定し、そのフェーズに対してのみ追跡を有効にします。 - カスタムイベントを使用して、プロセスの重要指標 (注文合計金額や追跡番号など) を追跡し、フローの高レベルのビジネス活動を明らかにする。 - トランザクションの有用な情報 (注文番号、従業員 ID 番号、出荷追跡番号など) が表示されるように、トランザクション ID をカスタマイズする。 これによって実行時に分析とデバッグが容易になり、より直感的に行えるようになります。 ## [](#関連情報)関連情報 - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-event) - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management) - [デフォルトイベント追跡の設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events-in-components) - [Custom Business Event コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events-custom) # ヒント: Transform Message コンポーネント UI (Anypoint Studio) - マッピングを作成する前に、入力と出力が予測できるように、フローの他の部分をすべて設定してください。 - 入力または出力構造から表示されるすべてのデータを絞り込むには、それぞれのセクションの一番上にある虫眼鏡のアイコン ​![tips transform message ui studio 69e11](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/tips-transform-message-ui-studio-69e11.png)​ をクリックして、項目名を入力します。 - 出力ペインで要素を選択すると、DataWeave コードの対応する行がハイライトされます。 - 入力項目が複数の出力項目にマップされている場合は、入力項目を右クリックして、DataWeave コードでハイライトしたい出力を選択できます。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # ヒント: Transform Message コンポーネント UI (Anypoint Studio) - マッピングを作成する前に、入力と出力が予測できるように、フローの他の部分をすべて設定してください。 - 入力または出力構造から表示されるすべてのデータを絞り込むには、それぞれのセクションの一番上にある虫眼鏡のアイコン ​![tips transform message ui studio 69e11](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/tips-transform-message-ui-studio-69e11.png)​ をクリックして、項目名を入力します。 - 出力ペインで要素を選択すると、DataWeave コードの対応する行がハイライトされます。 - 入力項目が複数の出力項目にマップされている場合は、入力項目を右クリックして、DataWeave コードでハイライトしたい出力を選択できます。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # ヒント: Transform Message コンポーネント UI (Anypoint Studio) - マッピングを作成する前に、入力と出力が予測できるように、フローの他の部分をすべて設定してください。 - 入力または出力構造から表示されるすべてのデータを絞り込むには、それぞれのセクションの一番上にある虫眼鏡のアイコン ![tips transform message ui studio 69e11](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/tips-transform-message-ui-studio-69e11.png) をクリックして、項目名を入力します。 - 出力ペインで要素を選択すると、DataWeave コードの対応する行がハイライトされます。 - 入力項目が複数の出力項目にマップされている場合は、入力項目を右クリックして、DataWeave コードでハイライトしたい出力を選択できます。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # ヒント: Transform Message コンポーネント UI (Anypoint Studio) - マッピングを作成する前に、入力と出力が予測できるように、フローの他の部分をすべて設定してください。 - 入力または出力構造から表示されるすべてのデータを絞り込むには、それぞれのセクションの一番上にある虫眼鏡のアイコン ​![tips transform message ui studio 69e11](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/tips-transform-message-ui-studio-69e11.png)​ をクリックして、項目名を入力します。 - 出力ペインで要素を選択すると、DataWeave コードの対応する行がハイライトされます。 - 入力項目が複数の出力項目にマップされている場合は、入力項目を右クリックして、DataWeave コードでハイライトしたい出力を選択できます。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # ヒント: Transform Message コンポーネント UI (Anypoint Studio) - マッピングを作成する前に、入力と出力が予測できるように、フローの他の部分をすべて設定してください。 - 入力または出力構造から表示されるすべてのデータを絞り込むには、それぞれのセクションの一番上にある虫眼鏡のアイコン ​![tips transform message ui studio 69e11](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/tips-transform-message-ui-studio-69e11.png)​ をクリックして、項目名を入力します。 - 出力ペインで要素を選択すると、DataWeave コードの対応する行がハイライトされます。 - 入力項目が複数の出力項目にマップされている場合は、入力項目を右クリックして、DataWeave コードでハイライトしたい出力を選択できます。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # ヒント: Transform Message コンポーネント UI (Anypoint Studio) - マッピングを作成する前に、入力と出力が予測できるように、フローの他の部分をすべて設定してください。 - 入力または出力構造から表示されるすべてのデータを絞り込むには、それぞれのセクションの一番上にある虫眼鏡のアイコン ​![検索アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/tips-transform-message-ui-studio-69e11.png)​ をクリックして、項目名を入力します。 - 出力ペインで要素を選択すると、DataWeave コードの対応する行がハイライトされます。 - 入力項目が複数の出力項目にマップされている場合は、入力項目を右クリックして、DataWeave コードでハイライトしたい出力を選択できます。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # ヒント: Transform Message コンポーネント UI (Anypoint Studio) - マッピングを作成する前に、入力と出力が予測できるように、フローの他の部分をすべて設定してください。 - 入力または出力構造から表示されるすべてのデータを絞り込むには、それぞれのセクションの一番上にある虫眼鏡のアイコン ​![検索アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/tips-transform-message-ui-studio-69e11.png)​ をクリックして、項目名を入力します。 - 出力ペインで要素を選択すると、DataWeave コードの対応する行がハイライトされます。 - 入力項目が複数の出力項目にマップされている場合は、入力項目を右クリックして、DataWeave コードでハイライトしたい出力を選択できます。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about) [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-workflow-create-mapping-ui-studio) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # プーリングプロファイル 単一コンポーネントとは異なり、プールコンポーネントは、同時に受信する要求を処理するための複数のコンポーネントインスタンスのプールを設定します。各プールコンポーネントは、プーリングプロファイルを持ちます。 FTP 用 Anypoint Connector (FTP Connector) や SFTP 用 Anypoint Connector (SFTP Connector) などのコネクタは、デフォルトで接続をプールし、​`pooling-profile`​ を使用して接続プールをカスタマイズします。 パフォーマンステストで必要だと判明した場合には、コネクタに ​`pooling-profile`​ パラメーターを追加してください。 ただし、データベース用 Anypoint Connector (Database Connector) は、デフォルトでは接続をプールしないため、SQL ステートメントを実行するたびに新しい接続を開き、実行の完了時に (トランザクション全体で同じ接続を使用するトランザクションが処理中ではない限り) 接続を閉じます。プーリングプロファイルを使用することで、1 回限りの接続設定を有効化して、以降の要求では既存の接続を使用することで、要求処理のパフォーマンスを高めることができます。 ```xml ``` `maxPoolSize`​ 設定は、データベースに対して開いて受信要求を処理できる接続の最大数を指定します。 # プーリングプロファイル 単一コンポーネントとは異なり、プールコンポーネントは、同時に受信する要求を処理するための複数のコンポーネントインスタンスのプールを設定します。各プールコンポーネントは、プーリングプロファイルを持ちます。 FTP 用 Anypoint Connector (FTP Connector) や SFTP 用 Anypoint Connector (SFTP Connector) などのコネクタは、デフォルトで接続をプールし、​`pooling-profile`​ を使用して接続プールをカスタマイズします。 パフォーマンステストで必要だと判明した場合には、コネクタに ​`pooling-profile`​ パラメーターを追加してください。 ただし、データベース用 Anypoint Connector (Database Connector) は、デフォルトでは接続をプールしないため、SQL ステートメントを実行するたびに新しい接続を開き、実行の完了時に (トランザクション全体で同じ接続を使用するトランザクションが処理中ではない限り) 接続を閉じます。プーリングプロファイルを使用することで、1 回限りの接続設定を有効化して、以降の要求では既存の接続を使用することで、要求処理のパフォーマンスを高めることができます。 ```xml ``` `maxPoolSize`​ 設定は、データベースに対して開いて受信要求を処理できる接続の最大数を指定します。 # プーリングプロファイル 単一コンポーネントとは異なり、プールコンポーネントは、同時に受信する要求を処理するための複数のコンポーネントインスタンスのプールを設定します。各プールコンポーネントは、プーリングプロファイルを持ちます。 FTP 用 Anypoint Connector (FTP Connector) や SFTP 用 Anypoint Connector (SFTP Connector) などのコネクタは、デフォルトで接続をプールし、​`pooling-profile`​ を使用して接続プールをカスタマイズします。 パフォーマンステストで必要だと判明した場合には、コネクタに ​`pooling-profile`​ パラメーターを追加してください。 ただし、データベース用 Anypoint Connector (Database Connector) は、デフォルトでは接続をプールしないため、SQL ステートメントを実行するたびに新しい接続を開き、実行の完了時に (トランザクション全体で同じ接続を使用するトランザクションが処理中ではない限り) 接続を閉じます。プーリングプロファイルを使用することで、1 回限りの接続設定を有効化して、以降の要求では既存の接続を使用することで、要求処理のパフォーマンスを高めることができます。 ```xml ``` `maxPoolSize`​ 設定は、データベースに対して開いて受信要求を処理できる接続の最大数を指定します。 # プーリングプロファイル 単一コンポーネントとは異なり、プールコンポーネントは、同時に受信する要求を処理するための複数のコンポーネントインスタンスのプールを設定します。各プールコンポーネントは、プーリングプロファイルを持ちます。 FTP 用 Anypoint Connector (FTP Connector) や SFTP 用 Anypoint Connector (SFTP Connector) などのコネクタは、デフォルトで接続をプールし、​`pooling-profile`​ を使用して接続プールをカスタマイズします。 パフォーマンステストで必要だと判明した場合には、コネクタに ​`pooling-profile`​ パラメーターを追加してください。 ただし、データベース用 Anypoint Connector (Database Connector) は、デフォルトでは接続をプールしないため、SQL ステートメントを実行するたびに新しい接続を開き、実行の完了時に (トランザクション全体で同じ接続を使用するトランザクションが処理中ではない限り) 接続を閉じます。プーリングプロファイルを使用することで、1 回限りの接続設定を有効化して、以降の要求では既存の接続を使用することで、要求処理のパフォーマンスを高めることができます。 ```xml ``` `maxPoolSize`​ 設定は、データベースに対して開いて受信要求を処理できる接続の最大数を指定します。 # プーリングプロファイル 単一コンポーネントとは異なり、プールコンポーネントは、同時に受信する要求を処理するための複数のコンポーネントインスタンスのプールを設定します。各プールコンポーネントは、プーリングプロファイルを持ちます。 FTP 用 Anypoint Connector (FTP Connector) や SFTP 用 Anypoint Connector (SFTP Connector) などのコネクタは、デフォルトで接続をプールし、​`pooling-profile`​ を使用して接続プールをカスタマイズします。 パフォーマンステストで必要だと判明した場合には、コネクタに ​`pooling-profile`​ パラメーターを追加してください。 ただし、データベース用 Anypoint Connector (Database Connector) は、デフォルトでは接続をプールしないため、SQL ステートメントを実行するたびに新しい接続を開き、実行の完了時に (トランザクション全体で同じ接続を使用するトランザクションが処理中ではない限り) 接続を閉じます。プーリングプロファイルを使用することで、1 回限りの接続設定を有効化して、以降の要求では既存の接続を使用することで、要求処理のパフォーマンスを高めることができます。 ```xml ``` `maxPoolSize`​ 設定は、データベースに対して開いて受信要求を処理できる接続の最大数を指定します。 # プーリングプロファイル 単一コンポーネントとは異なり、プールコンポーネントは、同時に受信する要求を処理するための複数のコンポーネントインスタンスのプールを設定します。各プールコンポーネントは、プーリングプロファイルを持ちます。 FTP 用 Anypoint Connector (FTP Connector) や SFTP 用 Anypoint Connector (SFTP Connector) などのコネクタは、デフォルトで接続をプールし、​`pooling-profile`​ を使用して接続プールをカスタマイズします。 パフォーマンステストで必要だと判明した場合には、コネクタに ​`pooling-profile`​ パラメーターを追加してください。 ただし、データベース用 Anypoint Connector (Database Connector) は、デフォルトでは接続をプールしないため、SQL ステートメントを実行するたびに新しい接続を開き、実行の完了時に (トランザクション全体で同じ接続を使用するトランザクションが処理中ではない限り) 接続を閉じます。プーリングプロファイルを使用することで、1 回限りの接続設定を有効化して、以降の要求では既存の接続を使用することで、要求処理のパフォーマンスを高めることができます。 ```xml ``` `maxPoolSize`​ 設定は、データベースに対して開いて受信要求を処理できる接続の最大数を指定します。 # プーリングプロファイル 単一コンポーネントとは異なり、プールコンポーネントは、同時に受信する要求を処理するための複数のコンポーネントインスタンスのプールを設定します。各プールコンポーネントは、プーリングプロファイルを持ちます。 FTP 用 Anypoint Connector (FTP Connector) や SFTP 用 Anypoint Connector (SFTP Connector) などのコネクタは、デフォルトで接続をプールし、​`pooling-profile`​ を使用して接続プールをカスタマイズします。 パフォーマンステストで必要だと判明した場合には、コネクタに ​`pooling-profile`​ パラメーターを追加してください。 ただし、データベース用 Anypoint Connector (Database Connector) は、デフォルトでは接続をプールしないため、SQL ステートメントを実行するたびに新しい接続を開き、実行の完了時に (トランザクション全体で同じ接続を使用するトランザクションが処理中ではない限り) 接続を閉じます。プーリングプロファイルを使用することで、1 回限りの接続設定を有効化して、以降の要求では既存の接続を使用することで、要求処理のパフォーマンスを高めることができます。 ```xml ``` `maxPoolSize`​ 設定は、データベースに対して開いて受信要求を処理できる接続の最大数を指定します。 # ファイルコネクタの移行 ファイルトランスポートは一新されています。Mule 3 のトランスポートモデルから、操作ベースのコネクタに進化しています。このため、多数の新しい機能が可能になります。 - インバウンドエンドポイントでしかポーリングされなかった旧来のトランスポートとは異なり、オンデマンドでファイルを読み込むことや、ディレクトリのコンテンツの完全リストを作成することができる。 - ファイルシステムの一般的な操作 (コピー、移動、名前変更、削除、ディレクトリの作成など) を最大限サポートする。 - ファイルシステムレベルでファイルのロックをサポートする。 - ファイルマッチング機能が向上する。 ## [](#whats_covered_here)このトピックの内容 - [ファイルコネクタ設定の移行](#file_configs) - [ファイル接続設定の参照](#file_config_refs) - [インバウンドエンドポイントの移行](#file_listener) - [アウトバウンドエンドポイントの移行](#file_write) ## [](#file_configs)ファイルコネクタ設定の移行 Mule 3 では、すべてのトランスポート設定が ​``​ という最上位要素で行われますが、ファイルコネクタでは自動削除、ストリーミング、接続の検証をデフォルトで ​`true`​ に設定します。 Mule 3 の例: デフォルトのファイル設定 ```xml ``` コネクタ設定にはまた、ファイルの読み取り、書き込み、移動など多数の設定があります。次の例は、ファイルコネクタで実行可能な Mule 3 の設定の大半を示しています。 Mule 3 の例: 実行可能なファイル接続設定 ```xml ``` Mule 4 では、​``​ がファイル接続設定の最上位要素で、​``​ は接続に関連する設定の子要素です。 Mule 4 の例 ```xml ``` - `workingDir`​ には、他のすべてのパスに使用するディレクトリへの相対パスを指定できます。指定されていない場合は、ユーザーのホームディレクトリが使用されます。Mule 3 に ​`workDirectory`​ とよく似た名前の属性がありますが、​`workDirectory`​ は入力ファイルを処理する前に移動する場合に使用するものです。 - `defaultWriteEncoding`​ は、書き込みで使用する文字エンコーディングを特定します。このグローバル設定は、Write などのファイル操作で上書きできます。 Mule 3 の他の設定パラメーターはすべて不要になりました。新しいコネクタの操作のパラメーターと置換されたか、新しいコネクタモデルでは表示する必要がないためです。 ## [](#file_config_refs)ファイル接続設定の参照 Mule 3 ではすべての操作が、​`connector-ref`​ を使用してファイルコネクタの主要な設定をポイントする、インバウンドまたはアウトバウンドエンドポイントとして設定されます。 Mule 3 の例: インバウンドエンドポイントとしてのファイル接続 ```xml ``` Mule 3 の例: アウトバウンドエンドポイントとしてのファイル接続 ```xml ``` ## [](#file_listener)インバウンドエンドポイントの移行 Mule 3 では、​``​ メッセージソースを使用してディレクトリをポーリングしてファイルを見つけていました。ファイルが検出されるごとにい、新しいメッセージがトリガーされました。このメッセージには、ペイロード内にファイルの内容が保持され、多数のファイル属性がシステムプロパティとして示されていました。同じファイルが何度も選択されることがないように、​`autoDelete`​ と ​`moveTo`​ パラメーターが用意され、ファイルが選択されるとポーリング対象のディレクトリから削除されていました。 Mule 4 ではこの方法が改良されています。​``​ コンポーネント (Studio パレットでは ​`On New File`​ という) がディレクトリをポーリングし、以前と同様のやり方で新しいメッセージをトリガーします。ただし、次の機能が追加されています。 - ``​ を使用して、特定の条件に一致するファイルのみを受け取ることができます。 - アプリケーションを起動する前にリスン ​`directory`​ を作成するか、再接続戦略を設定する必要があります。Mule 3.x では、アプリケーションの起動時にこのディレクトリが存在しなければ作成されていました。 - ファイルを強制的に削除または移動する必要がなくなりましたが、この操作を行うオプションは引き続き使用できます。 - 3.x では、エラーが発生してトランザクションがロールバックされても、入力ファイルが削除または移動されることはありませんでしたが、トランザクションがない場合はこうした操作が実行されていました。Mule 4 では、トランザクションの有無に関係なく、エラーが生じると、削除または移動操作が行われません。 - コネクタのいずれかの操作を使用して、処理されたファイルが条件に一致しなくなるように変更できます。 - ウォーターマークは自動的にサポートされ、必要に応じて作成または変更タイムスタンプに基づいて自動的に絞り込むことができます。 - Mule 3 では読み込みファイルの正規パスを使用して、そのメタデータをメッセージのインバウンドプロパティに追加していました。Mule 4 では絶対パスを使用します。 Mule 3 の例: インバウンドエンドポイント ```xml ``` Mule 4 の例: 新規ファイル ```xml ``` ## [](#file_write)アウトバウンドエンドポイントの移行 Mule 3 のトランスポートは ​``​ コンポーネントを使用して、現在のペイロードをファイルに書き込みます。Mule 4 のコネクタは、その代わりに ​``​ 操作を使用します。 特に重要な違いは次のとおりです。 - ``​ コンポーネントは非同期です。つまり、実際の書き込みがバックグラウンドで行われると同時に、フローで次のメッセージプロセッサーが実行されていました。他方、​``​ 操作は同期で、この操作が終了するまで次のメッセージプロセッサーは実行されません。操作を非同期にする場合は、​``​ 操作を ​``​ ブロックでラップします。 - ``​ は、実行時にメッセージペイロードに書き込むコンテンツが必要でした。​``​ 操作では、書き込むコンテンツを生成する DataWeave 変換を組み込むことができます。 - Mule 3 のトランスポートでは設定レベルで ​`outputAppend`​ パラメーターが設定されるのに対し、​``​ 操作にはモードパラメーターがあります。 Mule 3 の例: アウトバウンドエンドポイント ```xml ``` Mule 4 の例: Write 操作 ```xml #['Hello $(payload.name)'] ``` ファイルコネクタを使用するには、Studio パレットを使用してアプリケーションに追加するか、次の連動関係を ​`pom.xml`​ ファイルに追加します。 ```xml org.mule.connectors mule-file-connector 1.1.0 mule-plugin ``` ## [](#関連情報)関連情報 - [ファイルコネクタドキュメント](https://docs.mulesoft.com/jp/file-connector/latest/) # フローおよびサブフロー Mule アプリケーションは、アプリケーション内の Flow および Subflow コンポーネントのスコープ内でセットアップされた Mule コンポーネント、 コネクタ、およびモジュールを使用して、Mule イベントのメッセージと他の要素を処理します。 単一のフローでアプリケーションを構成したり、処理を個別のフローとサブフローに分割し、それらをまとめてアプリケーションに追加および接続したりできます。通常、本番環境の Mule アプリケーションは複数のフローとサブフローを使用して、アプリケーションを機能モジュール別または​[エラー処理](#error_handling)​目的で分割します。たとえば、1 つのフローで レコードを受信してデータを特定の形式に変換し、別の フローでそのデータを特別な方法で処理できます。 [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.3/flowref-about)​ コンポーネントを使用するか、式および変換内で DataWeave ​`lookup`​ 関数を使用して、それらを接続し、実行をトリガーできます。この関数は、現在のイベントをその後の処理を行う別の フローに渡します。Flow Reference は、イベントを入力として受け取り、変更されたイベントを返す関数コールと考えることができます。 ## [](#フローの使用)フローの使用 フローには、フローの実行をトリガーする Mule ソース (要求を受信する HTTP リスナーなど) を使用できます。ソースがフローをすぐに開始しないようにする場合、最初に停止し、後で ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/flow-management)​ を介して開始するようにフローを設定できます。 他のプログラミング言語の関数やメソッドと同様に、Web クライアントから API 要求を受信し、イベントを処理してから適切な応答を返すなど、 特定の (たとえば再利用可能な) アクティビティにフローの焦点を絞る ことをお勧めします。イベント処理が複雑になったり、他のサービスをコールする 必要がある場合は、その動作を他のフローに組み込むことができます。 ## [](#サブフローの使用)サブフローの使用 _サブフロー_​は、フローに似た方法でイベントプロセッサーをグループ化できるスコープですが、いくつかの相違点や制限があります。 - サブフローにはイベントソースがありません。 - サブフローにはエラー処理スコープがありません。 - 設計中には、サブフローはそれをコールする Flow Reference コンポーネントを置き換えるマクロとして機能します。 アプリケーションをビルドすると、サブフローをコールするすべての Flow Reference コンポーネントは、参照されるサブフローのコンテンツに置き換えられます。 - フローを参照するよりもサブフローを参照する方がパフォーマンスは高くなります。 ### [](#制限事項)制限事項 サブフローを参照する Flow Reference コンポーネントがサブフローのコンテンツに置き換えられるため、実行時には、そのサブフロー内のイベントプロセッサーの複数のインスタンスがアプリケーション内に存在します。一意の ID またはインスタンスを使用して実行するイベントプロセッサー (バッチプロセッサーなど) では、この動作が問題になる可能性があります。 たとえば、サブフロー内でバッチジョブを設定すると、そのサブフローが複数の Flow Reference コンポーネントで参照されている場合には、アプリケーションがデプロイメント中に失敗します。アプリケーションがデプロイに失敗する理由は、同じジョブインスタンス ID のバッチジョブの複数のインスタンスが存在し、それが許可されないためです。 ## [](#error_handling)エラー処理 (サブフローではない) 各フローは、独自のエラー処理を使用できます。Flow Reference コンポーネントを 介してフローをコールする理由の 1 つは、エラー処理をさまざまな コンテキストに分離することです。たとえば、Web クライアント要求を受信する親フローで HTTP 関連のエラー処理を定義するとします。この親フローで その後の処理のために JMS キューをコールする場合、JMS イベントプロセッサーを 個別の子フローに配置し、Flow Reference コンポーネントを使用してそのフローを コールできます。その後、この子フローで独自の JMS 関連エラー処理を定義できます。 この方法は、Java などの他のプログラミング言語でエラーを処理または伝達 する方法と似ています。 フローまたはサブフローのように、​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept)​も独自の エラー処理を使用してイベントプロセッサーのシーケンスをグループ化します。個別の フローまたはサブフローを作成することなく、フローまたはサブフロー内に Try スコープを配置してフロー内のエラー処理を分離できます。このトレードオフは、 Try スコープによるエラー処理がフロー内でインラインで実行されるため、 他のフローまたはサブフロー間での再利用が困難になることです。 どちらの場合も、Java コード内での Try-Catch ブロックの使用と同様に、 フローをコールするか Try スコープを含めることで、エラー処理が分離されます。たとえば、 JMS キューイベント処理 (前述) を独自のフローまたは Try スコープ内に 配置すると、まったく同じエラー処理動作になりますが、 Try スコープ内のイベントプロセッサーを別のフローからコールする ことはできません。 ## [](#イベント処理の分岐)イベント処理の分岐 フローでイベント処理を別々のスレッドに分岐し、フローの特定ポイントで イベントの非同期処理を可能にするスコープがいくつかあります。たとえば、 ​[Scatter-Gather](https://docs.mulesoft.com/jp/mule-runtime/4.3/scatter-gather-concept)​ や ​[Async](https://docs.mulesoft.com/jp/mule-runtime/4.3/async-scope-reference)​ スコープなどです。​[Choice](https://docs.mulesoft.com/jp/mule-runtime/4.3/choice-router-concept)​ ルーターでは、条件に基づいてイベントプロセッサーのダウンストリームシーケンス を変更できます。 ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/flow-component) - [Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.3/) # フローおよびサブフロー Mule アプリケーションは、アプリケーション内の Flow および Subflow コンポーネントのスコープ内でセットアップされた Mule コンポーネント、 コネクタ、およびモジュールを使用して、Mule イベントのメッセージと他の要素を処理します。 単一のフローでアプリケーションを構成したり、処理を個別のフローとサブフローに分割し、それらをまとめてアプリケーションに追加および接続したりできます。通常、本番環境の Mule アプリケーションは複数のフローとサブフローを使用して、アプリケーションを機能モジュール別または​[エラー処理](#error_handling)​目的で分割します。たとえば、1 つのフローで レコードを受信してデータを特定の形式に変換し、別の フローでそのデータを特別な方法で処理できます。 [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.4/flowref-about)​ コンポーネントを使用するか、式および変換内で DataWeave ​`lookup`​ 関数を使用して、それらを接続し、実行をトリガーできます。この関数は、現在のイベントをその後の処理を行う別の フローに渡します。Flow Reference は、イベントを入力として受け取り、変更されたイベントを返す関数コールと考えることができます。 ## [](#フローの使用)フローの使用 フローには、フローの実行をトリガーする Mule ソース (要求を受信する HTTP リスナーなど) を使用できます。ソースがフローをすぐに開始しないようにする場合、最初に停止し、後で ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/flow-management)​ を介して開始するようにフローを設定できます。 他のプログラミング言語の関数やメソッドと同様に、Web クライアントから API 要求を受信し、イベントを処理してから適切な応答を返すなど、 特定の (たとえば再利用可能な) アクティビティにフローの焦点を絞る ことをお勧めします。イベント処理が複雑になったり、他のサービスをコールする 必要がある場合は、その動作を他のフローに組み込むことができます。 ## [](#サブフローの使用)サブフローの使用 _サブフロー_​は、フローに似た方法でイベントプロセッサーをグループ化できるスコープですが、いくつかの相違点や制限があります。 - サブフローには Mule イベントソースがありません。 - サブフローにはエラー処理スコープがありません。 - 設計中には、サブフローはそれをコールする Flow Reference コンポーネントを置き換えるマクロとして機能します。 アプリケーションをビルドすると、サブフローをコールするすべての Flow Reference コンポーネントは、参照されるサブフローのコンテンツに置き換えられます。 - フローを参照するよりもサブフローを参照する方がパフォーマンスは高くなります。 ### [](#制限事項)制限事項 サブフローを参照する Flow Reference コンポーネントがサブフローのコンテンツに置き換えられるため、実行時には、そのサブフロー内のイベントプロセッサーの複数のインスタンスがアプリケーション内に存在します。一意の ID またはインスタンスを使用して実行するイベントプロセッサー (バッチプロセッサーなど) では、この動作が問題になる可能性があります。 たとえば、サブフロー内でバッチジョブを設定すると、そのサブフローが複数の Flow Reference コンポーネントで参照されている場合には、アプリケーションがデプロイメント中に失敗します。アプリケーションがデプロイに失敗する理由は、同じジョブインスタンス ID のバッチジョブの複数のインスタンスが存在し、それが許可されないためです。 ## [](#error_handling)エラー処理 (サブフローではない) 各フローは、独自のエラー処理を使用できます。Flow Reference コンポーネントを 介してフローをコールする理由の 1 つは、エラー処理をさまざまな コンテキストに分離することです。たとえば、Web クライアント要求を受信する親フローで HTTP 関連のエラー処理を定義するとします。この親フローで その後の処理のために JMS キューをコールする場合、JMS イベントプロセッサーを 個別の子フローに配置し、Flow Reference コンポーネントを使用してそのフローを コールできます。その後、この子フローで独自の JMS 関連エラー処理を定義できます。 この方法は、Java などの他のプログラミング言語でエラーを処理または伝達 する方法と似ています。 フローまたはサブフローのように、​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept)​も独自の エラー処理を使用してイベントプロセッサーのシーケンスをグループ化します。個別の フローまたはサブフローを作成することなく、フローまたはサブフロー内に Try スコープを配置してフロー内のエラー処理を分離できます。このトレードオフは、 Try スコープによるエラー処理がフロー内でインラインで実行されるため、 他のフローまたはサブフロー間での再利用が困難になることです。 どちらの場合も、Java コード内での Try-Catch ブロックの使用と同様に、 フローをコールするか Try スコープを含めることで、エラー処理が分離されます。たとえば、 JMS キューイベント処理 (前述) を独自のフローまたは Try スコープ内に 配置すると、まったく同じエラー処理動作になりますが、 Try スコープ内のイベントプロセッサーを別のフローからコールする ことはできません。 ## [](#イベント処理の分岐)イベント処理の分岐 フローでイベント処理を別々のスレッドに分岐し、フローの特定ポイントで イベントの非同期処理を可能にするスコープがいくつかあります。たとえば、 ​[Scatter-Gather](https://docs.mulesoft.com/jp/mule-runtime/4.4/scatter-gather-concept)​ や ​[Async](https://docs.mulesoft.com/jp/mule-runtime/4.4/async-scope-reference)​ スコープなどです。​[Choice](https://docs.mulesoft.com/jp/mule-runtime/4.4/choice-router-concept)​ ルーターでは、条件に基づいてイベントプロセッサーのダウンストリームシーケンス を変更できます。 ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/flow-component) - [Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.4/) # フローおよびサブフロー Mule アプリケーションは、アプリケーション内の Flow および Subflow コンポーネントのスコープ内でセットアップされた Mule コンポーネント、 コネクタ、およびモジュールを使用して、Mule イベントのメッセージと他の要素を処理します。 単一のフローでアプリケーションを構成したり、処理を個別のフローとサブフローに分割し、それらをまとめてアプリケーションに追加および接続したりできます。通常、本番環境の Mule アプリケーションは複数のフローとサブフローを使用して、アプリケーションを機能モジュール別または​[エラー処理](#error_handling)​目的で分割します。たとえば、1 つのフローで レコードを受信してデータを特定の形式に変換し、別の フローでそのデータを特別な方法で処理できます。 [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.5/flowref-about)​ コンポーネントを使用するか、式および変換内で DataWeave ​`lookup`​ 関数を使用して、それらを接続し、実行をトリガーできます。この関数は、現在のイベントをその後の処理を行う別の フローに渡します。Flow Reference は、イベントを入力として受け取り、変更されたイベントを返す関数コールと考えることができます。 ## [](#フローの使用)フローの使用 フローには、フローの実行をトリガーする Mule ソース (要求を受信する HTTP リスナーなど) を使用できます。ソースがフローをすぐに開始しないようにする場合、最初に停止し、後で ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/flow-management)​ を介して開始するようにフローを設定できます。 他のプログラミング言語の関数やメソッドと同様に、Web クライアントから API 要求を受信し、イベントを処理してから適切な応答を返すなど、 特定の (たとえば再利用可能な) アクティビティにフローの焦点を絞る ことをお勧めします。イベント処理が複雑になったり、他のサービスをコールする 必要がある場合は、その動作を他のフローに組み込むことができます。 ## [](#サブフローの使用)サブフローの使用 _サブフロー_​は、フローに似た方法でイベントプロセッサーをグループ化できるスコープですが、いくつかの相違点や制限があります。 - サブフローには Mule イベントソースがありません。 - サブフローにはエラー処理スコープがありません。 - 設計中には、サブフローはそれをコールする Flow Reference コンポーネントを置き換えるマクロとして機能します。 アプリケーションをビルドすると、サブフローをコールするすべての Flow Reference コンポーネントは、参照されるサブフローのコンテンツに置き換えられます。 - フローを参照するよりもサブフローを参照する方がパフォーマンスは高くなります。 ### [](#制限事項)制限事項 サブフローを参照する Flow Reference コンポーネントがサブフローのコンテンツに置き換えられるため、実行時には、そのサブフロー内のイベントプロセッサーの複数のインスタンスがアプリケーション内に存在します。一意の ID またはインスタンスを使用して実行するイベントプロセッサー (バッチプロセッサーなど) では、この動作が問題になる可能性があります。 たとえば、サブフロー内でバッチジョブを設定すると、そのサブフローが複数の Flow Reference コンポーネントで参照されている場合には、アプリケーションがデプロイメント中に失敗します。アプリケーションがデプロイに失敗する理由は、同じジョブインスタンス ID のバッチジョブの複数のインスタンスが存在し、それが許可されないためです。 ## [](#error_handling)エラー処理 (サブフローではない) 各フローは、独自のエラー処理を使用できます。Flow Reference コンポーネントを 介してフローをコールする理由の 1 つは、エラー処理をさまざまな コンテキストに分離することです。たとえば、Web クライアント要求を受信する親フローで HTTP 関連のエラー処理を定義するとします。この親フローで その後の処理のために JMS キューをコールする場合、JMS イベントプロセッサーを 個別の子フローに配置し、Flow Reference コンポーネントを使用してそのフローを コールできます。その後、この子フローで独自の JMS 関連エラー処理を定義できます。 この方法は、Java などの他のプログラミング言語でエラーを処理または伝達 する方法と似ています。 フローまたはサブフローのように、​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept)​も独自の エラー処理を使用してイベントプロセッサーのシーケンスをグループ化します。個別の フローまたはサブフローを作成することなく、フローまたはサブフロー内に Try スコープを配置してフロー内のエラー処理を分離できます。このトレードオフは、 Try スコープによるエラー処理がフロー内でインラインで実行されるため、 他のフローまたはサブフロー間での再利用が困難になることです。 どちらの場合も、Java コード内での Try-Catch ブロックの使用と同様に、 フローをコールするか Try スコープを含めることで、エラー処理が分離されます。たとえば、 JMS キューイベント処理 (前述) を独自のフローまたは Try スコープ内に 配置すると、まったく同じエラー処理動作になりますが、 Try スコープ内のイベントプロセッサーを別のフローからコールする ことはできません。 ## [](#イベント処理の分岐)イベント処理の分岐 フローでイベント処理を別々のスレッドに分岐し、フローの特定ポイントで イベントの非同期処理を可能にするスコープがいくつかあります。たとえば、 ​[Scatter-Gather](https://docs.mulesoft.com/jp/mule-runtime/4.5/scatter-gather-concept)​ や ​[Async](https://docs.mulesoft.com/jp/mule-runtime/4.5/async-scope-reference)​ スコープなどです。​[Choice](https://docs.mulesoft.com/jp/mule-runtime/4.5/choice-router-concept)​ ルーターでは、条件に基づいてイベントプロセッサーのダウンストリームシーケンス を変更できます。 ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/flow-component) - [Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.5/) # フローおよびサブフロー Mule アプリケーションは、アプリケーション内の Flow および Subflow コンポーネントのスコープ内でセットアップされた Mule コンポーネント、 コネクタ、およびモジュールを使用して、Mule イベントのメッセージと他の要素を処理します。 単一のフローでアプリケーションを構成したり、処理を個別のフローとサブフローに分割し、それらをまとめてアプリケーションに追加および接続したりできます。通常、本番環境の Mule アプリケーションは複数のフローとサブフローを使用して、アプリケーションを機能モジュール別または​[エラー処理](#error_handling)​目的で分割します。たとえば、1 つのフローで レコードを受信してデータを特定の形式に変換し、別の フローでそのデータを特別な方法で処理できます。 [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.6/flowref-about)​ コンポーネントを使用するか、式および変換内で DataWeave ​`lookup`​ 関数を使用して、それらを接続し、実行をトリガーできます。この関数は、現在のイベントをその後の処理を行う別の フローに渡します。Flow Reference は、イベントを入力として受け取り、変更されたイベントを返す関数コールと考えることができます。 ## [](#フローの使用)フローの使用 フローには、フローの実行をトリガーする Mule ソース (要求を受信する HTTP リスナーなど) を使用できます。ソースがフローをすぐに開始しないようにする場合、最初に停止し、後で ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/flow-management)​ を介して開始するようにフローを設定できます。 他のプログラミング言語の関数やメソッドと同様に、Web クライアントから API 要求を受信し、イベントを処理してから適切な応答を返すなど、 特定の (たとえば再利用可能な) アクティビティにフローの焦点を絞る ことをお勧めします。イベント処理が複雑になったり、他のサービスをコールする 必要がある場合は、その動作を他のフローに組み込むことができます。 ## [](#サブフローの使用)サブフローの使用 _サブフロー_​は、フローに似た方法でイベントプロセッサーをグループ化できるスコープですが、いくつかの相違点や制限があります。 - サブフローには Mule イベントソースがありません。 - サブフローにはエラー処理スコープがありません。 - 設計中には、サブフローはそれをコールする Flow Reference コンポーネントを置き換えるマクロとして機能します。 アプリケーションをビルドすると、サブフローをコールするすべての Flow Reference コンポーネントは、参照されるサブフローのコンテンツに置き換えられます。 - フローを参照するよりもサブフローを参照する方がパフォーマンスは高くなります。 ### [](#制限事項)制限事項 サブフローを参照する Flow Reference コンポーネントがサブフローのコンテンツに置き換えられるため、実行時には、そのサブフロー内のイベントプロセッサーの複数のインスタンスがアプリケーション内に存在します。一意の ID またはインスタンスを使用して実行するイベントプロセッサー (バッチプロセッサーなど) では、この動作が問題になる可能性があります。 たとえば、サブフロー内でバッチジョブを設定すると、そのサブフローが複数の Flow Reference コンポーネントで参照されている場合には、アプリケーションがデプロイメント中に失敗します。アプリケーションがデプロイに失敗する理由は、同じジョブインスタンス ID のバッチジョブの複数のインスタンスが存在し、それが許可されないためです。 ## [](#error_handling)エラー処理 (サブフローではない) 各フローは、独自のエラー処理を使用できます。Flow Reference コンポーネントを 介してフローをコールする理由の 1 つは、エラー処理をさまざまな コンテキストに分離することです。たとえば、Web クライアント要求を受信する親フローで HTTP 関連のエラー処理を定義するとします。この親フローで その後の処理のために JMS キューをコールする場合、JMS イベントプロセッサーを 個別の子フローに配置し、Flow Reference コンポーネントを使用してそのフローを コールできます。その後、この子フローで独自の JMS 関連エラー処理を定義できます。 この方法は、Java などの他のプログラミング言語でエラーを処理または伝達 する方法と似ています。 フローまたはサブフローのように、​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept)​も独自の エラー処理を使用してイベントプロセッサーのシーケンスをグループ化します。個別の フローまたはサブフローを作成することなく、フローまたはサブフロー内に Try スコープを配置してフロー内のエラー処理を分離できます。このトレードオフは、 Try スコープによるエラー処理がフロー内でインラインで実行されるため、 他のフローまたはサブフロー間での再利用が困難になることです。 どちらの場合も、Java コード内での Try-Catch ブロックの使用と同様に、 フローをコールするか Try スコープを含めることで、エラー処理が分離されます。たとえば、 JMS キューイベント処理 (前述) を独自のフローまたは Try スコープ内に 配置すると、まったく同じエラー処理動作になりますが、 Try スコープ内のイベントプロセッサーを別のフローからコールする ことはできません。 ## [](#イベント処理の分岐)イベント処理の分岐 フローでイベント処理を別々のスレッドに分岐し、フローの特定ポイントで イベントの非同期処理を可能にするスコープがいくつかあります。たとえば、 ​[Scatter-Gather](https://docs.mulesoft.com/jp/mule-runtime/4.6/scatter-gather-concept)​ や ​[Async](https://docs.mulesoft.com/jp/mule-runtime/4.6/async-scope-reference)​ スコープなどです。​[Choice](https://docs.mulesoft.com/jp/mule-runtime/4.6/choice-router-concept)​ ルーターでは、条件に基づいてイベントプロセッサーのダウンストリームシーケンス を変更できます。 ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/flow-component) - [Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.6/) # フローおよびサブフロー Mule アプリケーションは、アプリケーション内の Flow および Subflow コンポーネントのスコープ内でセットアップされた Mule コンポーネント、 コネクタ、およびモジュールを使用して、Mule イベントのメッセージと他の要素を処理します。 単一のフローでアプリケーションを構成したり、処理を個別のフローとサブフローに分割し、それらをまとめてアプリケーションに追加および接続したりできます。通常、本番環境の Mule アプリケーションは複数のフローとサブフローを使用して、アプリケーションを機能モジュール別または​[エラー処理](#error_handling)​目的で分割します。たとえば、1 つのフローで レコードを受信してデータを特定の形式に変換し、別の フローでそのデータを特別な方法で処理できます。 [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.7/flowref-about)​ コンポーネントを使用するか、式および変換内で DataWeave ​`lookup`​ 関数を使用して、それらを接続し、実行をトリガーできます。この関数は、現在のイベントをその後の処理を行う別の フローに渡します。Flow Reference は、イベントを入力として受け取り、変更されたイベントを返す関数コールと考えることができます。 ## [](#フローの使用)フローの使用 フローには、フローの実行をトリガーする Mule ソース (要求を受信する HTTP リスナーなど) を使用できます。ソースがフローをすぐに開始しないようにする場合、最初に停止し、後で ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/flow-management)​ を介して開始するようにフローを設定できます。 他のプログラミング言語の関数やメソッドと同様に、Web クライアントから API 要求を受信し、イベントを処理してから適切な応答を返すなど、 特定の (たとえば再利用可能な) アクティビティにフローの焦点を絞る ことをお勧めします。イベント処理が複雑になったり、他のサービスをコールする 必要がある場合は、その動作を他のフローに組み込むことができます。 ## [](#サブフローの使用)サブフローの使用 _サブフロー_​は、フローに似た方法でイベントプロセッサーをグループ化できるスコープですが、いくつかの相違点や制限があります。 - サブフローには Mule イベントソースがありません。 - サブフローにはエラー処理スコープがありません。 - 設計中には、サブフローはそれをコールする Flow Reference コンポーネントを置き換えるマクロとして機能します。 アプリケーションをビルドすると、サブフローをコールするすべての Flow Reference コンポーネントは、参照されるサブフローのコンテンツに置き換えられます。 - フローを参照するよりもサブフローを参照する方がパフォーマンスは高くなります。 ### [](#制限事項)制限事項 サブフローを参照する Flow Reference コンポーネントがサブフローのコンテンツに置き換えられるため、実行時には、そのサブフロー内のイベントプロセッサーの複数のインスタンスがアプリケーション内に存在します。一意の ID またはインスタンスを使用して実行するイベントプロセッサー (バッチプロセッサーなど) では、この動作が問題になる可能性があります。 たとえば、サブフロー内でバッチジョブを設定すると、そのサブフローが複数の Flow Reference コンポーネントで参照されている場合には、アプリケーションがデプロイメント中に失敗します。アプリケーションがデプロイに失敗する理由は、同じジョブインスタンス ID のバッチジョブの複数のインスタンスが存在し、それが許可されないためです。 ## [](#error_handling)エラー処理 (サブフローではない) 各フローは、独自のエラー処理を使用できます。Flow Reference コンポーネントを 介してフローをコールする理由の 1 つは、エラー処理をさまざまな コンテキストに分離することです。たとえば、Web クライアント要求を受信する親フローで HTTP 関連のエラー処理を定義するとします。この親フローで その後の処理のために JMS キューをコールする場合、JMS イベントプロセッサーを 個別の子フローに配置し、Flow Reference コンポーネントを使用してそのフローを コールできます。その後、この子フローで独自の JMS 関連エラー処理を定義できます。 この方法は、Java などの他のプログラミング言語でエラーを処理または伝達 する方法と似ています。 フローまたはサブフローのように、​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept)​も独自の エラー処理を使用してイベントプロセッサーのシーケンスをグループ化します。個別の フローまたはサブフローを作成することなく、フローまたはサブフロー内に Try スコープを配置してフロー内のエラー処理を分離できます。このトレードオフは、 Try スコープによるエラー処理がフロー内でインラインで実行されるため、 他のフローまたはサブフロー間での再利用が困難になることです。 どちらの場合も、Java コード内での Try-Catch ブロックの使用と同様に、 フローをコールするか Try スコープを含めることで、エラー処理が分離されます。たとえば、 JMS キューイベント処理 (前述) を独自のフローまたは Try スコープ内に 配置すると、まったく同じエラー処理動作になりますが、 Try スコープ内のイベントプロセッサーを別のフローからコールする ことはできません。 ## [](#イベント処理の分岐)イベント処理の分岐 フローでイベント処理を別々のスレッドに分岐し、フローの特定ポイントで イベントの非同期処理を可能にするスコープがいくつかあります。たとえば、 ​[Scatter-Gather](https://docs.mulesoft.com/jp/mule-runtime/4.7/scatter-gather-concept)​ や ​[Async](https://docs.mulesoft.com/jp/mule-runtime/4.7/async-scope-reference)​ スコープなどです。​[Choice](https://docs.mulesoft.com/jp/mule-runtime/4.7/choice-router-concept)​ ルーターでは、条件に基づいてイベントプロセッサーのダウンストリームシーケンス を変更できます。 ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/flow-component) - [Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.7/) # フローおよびサブフロー Mule アプリケーションは、アプリケーション内の Flow および Subflow コンポーネントのスコープ内でセットアップされた Mule コンポーネント、 コネクタ、およびモジュールを使用して、Mule イベントのメッセージと他の要素を処理します。 単一のフローでアプリケーションを構成したり、処理を個別のフローとサブフローに分割し、それらをまとめてアプリケーションに追加および接続したりできます。通常、本番環境の Mule アプリケーションは複数のフローとサブフローを使用して、アプリケーションを機能モジュール別または​[エラー処理](#error_handling)​目的で分割します。たとえば、1 つのフローで レコードを受信してデータを特定の形式に変換し、別の フローでそのデータを特別な方法で処理できます。 [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.8/flowref-about)​ コンポーネントを使用するか、式および変換内で DataWeave ​`lookup`​ 関数を使用して、それらを接続し、実行をトリガーできます。この関数は、現在のイベントをその後の処理を行う別の フローに渡します。Flow Reference は、イベントを入力として受け取り、変更されたイベントを返す関数コールと考えることができます。 ## [](#フローの使用)フローの使用 フローには、フローの実行をトリガーする Mule ソース (要求を受信する HTTP リスナーなど) を使用できます。ソースがフローをすぐに開始しないようにする場合、最初に停止し、後で ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/flow-management)​ を介して開始するようにフローを設定できます。 他のプログラミング言語の関数やメソッドと同様に、Web クライアントから API 要求を受信し、イベントを処理してから適切な応答を返すなど、 特定の (たとえば再利用可能な) アクティビティにフローの焦点を絞る ことをお勧めします。イベント処理が複雑になったり、他のサービスをコールする 必要がある場合は、その動作を他のフローに組み込むことができます。 ## [](#サブフローの使用)サブフローの使用 _サブフロー_​は、フローに似た方法でイベントプロセッサーをグループ化できるスコープですが、いくつかの相違点や制限があります。 - サブフローには Mule イベントソースがありません。 - サブフローにはエラー処理スコープがありません。 - 設計中には、サブフローはそれをコールする Flow Reference コンポーネントを置き換えるマクロとして機能します。 アプリケーションをビルドすると、サブフローをコールするすべての Flow Reference コンポーネントは、参照されるサブフローのコンテンツに置き換えられます。 - フローを参照するよりもサブフローを参照する方がパフォーマンスは高くなります。 ### [](#制限事項)制限事項 サブフローを参照する Flow Reference コンポーネントがサブフローのコンテンツに置き換えられるため、実行時には、そのサブフロー内のイベントプロセッサーの複数のインスタンスがアプリケーション内に存在します。一意の ID またはインスタンスを使用して実行するイベントプロセッサー (バッチプロセッサーなど) では、この動作が問題になる可能性があります。 たとえば、サブフロー内でバッチジョブを設定すると、そのサブフローが複数の Flow Reference コンポーネントで参照されている場合には、アプリケーションがデプロイメント中に失敗します。アプリケーションがデプロイに失敗する理由は、同じジョブインスタンス ID のバッチジョブの複数のインスタンスが存在し、それが許可されないためです。 ## [](#error_handling)エラー処理 (サブフローではない) 各フローは、独自のエラー処理を使用できます。Flow Reference コンポーネントを 介してフローをコールする理由の 1 つは、エラー処理をさまざまな コンテキストに分離することです。たとえば、Web クライアント要求を受信する親フローで HTTP 関連のエラー処理を定義するとします。この親フローで その後の処理のために JMS キューをコールする場合、JMS イベントプロセッサーを 個別の子フローに配置し、Flow Reference コンポーネントを使用してそのフローを コールできます。その後、この子フローで独自の JMS 関連エラー処理を定義できます。 この方法は、Java などの他のプログラミング言語でエラーを処理または伝達 する方法と似ています。 フローまたはサブフローのように、​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept)​も独自の エラー処理を使用してイベントプロセッサーのシーケンスをグループ化します。個別の フローまたはサブフローを作成することなく、フローまたはサブフロー内に Try スコープを配置してフロー内のエラー処理を分離できます。このトレードオフは、 Try スコープによるエラー処理がフロー内でインラインで実行されるため、 他のフローまたはサブフロー間での再利用が困難になることです。 どちらの場合も、Java コード内での Try-Catch ブロックの使用と同様に、 フローをコールするか Try スコープを含めることで、エラー処理が分離されます。たとえば、 JMS キューイベント処理 (前述) を独自のフローまたは Try スコープ内に 配置すると、まったく同じエラー処理動作になりますが、 Try スコープ内のイベントプロセッサーを別のフローからコールする ことはできません。 ## [](#イベント処理の分岐)イベント処理の分岐 フローでイベント処理を別々のスレッドに分岐し、フローの特定ポイントで イベントの非同期処理を可能にするスコープがいくつかあります。たとえば、 ​[Scatter-Gather](https://docs.mulesoft.com/jp/mule-runtime/4.8/scatter-gather-concept)​ や ​[Async](https://docs.mulesoft.com/jp/mule-runtime/4.8/async-scope-reference)​ スコープなどです。​[Choice](https://docs.mulesoft.com/jp/mule-runtime/4.8/choice-router-concept)​ ルーターでは、条件に基づいてイベントプロセッサーのダウンストリームシーケンス を変更できます。 ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/flow-component) - [Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.8/) # フローおよびサブフロー Mule アプリケーションは、アプリケーション内の Flow および Subflow コンポーネントのスコープ内でセットアップされた Mule コンポーネント、 コネクタ、およびモジュールを使用して、Mule イベントのメッセージと他の要素を処理します。 単一のフローでアプリケーションを構成したり、処理を個別のフローとサブフローに分割し、それらをまとめてアプリケーションに追加および接続したりできます。通常、本番環境の Mule アプリケーションは複数のフローとサブフローを使用して、アプリケーションを機能モジュール別または​[エラー処理](#error_handling)​目的で分割します。たとえば、1 つのフローで レコードを受信してデータを特定の形式に変換し、別の フローでそのデータを特別な方法で処理できます。 [Flow Reference](https://docs.mulesoft.com/jp/mule-runtime/4.9/flowref-about)​ コンポーネントを使用するか、式および変換内で DataWeave ​`lookup`​ 関数を使用して、それらを接続し、実行をトリガーできます。この関数は、現在のイベントをその後の処理を行う別の フローに渡します。Flow Reference は、イベントを入力として受け取り、変更されたイベントを返す関数コールと考えることができます。 ## [](#フローの使用)フローの使用 フローには、フローの実行をトリガーする Mule ソース (要求を受信する HTTP リスナーなど) を使用できます。ソースがフローをすぐに開始しないようにする場合、最初に停止し、後で ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/flow-management)​ を介して開始するようにフローを設定できます。 他のプログラミング言語の関数やメソッドと同様に、Web クライアントから API 要求を受信し、イベントを処理してから適切な応答を返すなど、 特定の (たとえば再利用可能な) アクティビティにフローの焦点を絞る ことをお勧めします。イベント処理が複雑になったり、他のサービスをコールする 必要がある場合は、その動作を他のフローに組み込むことができます。 ## [](#サブフローの使用)サブフローの使用 _サブフロー_​は、フローに似た方法でイベントプロセッサーをグループ化できるスコープですが、いくつかの相違点や制限があります。 - サブフローには Mule イベントソースがありません。 - サブフローにはエラー処理スコープがありません。 - 設計中には、サブフローはそれをコールする Flow Reference コンポーネントを置き換えるマクロとして機能します。 アプリケーションをビルドすると、サブフローをコールするすべての Flow Reference コンポーネントは、参照されるサブフローのコンテンツに置き換えられます。 - フローを参照するよりもサブフローを参照する方がパフォーマンスは高くなります。 ### [](#制限事項)制限事項 サブフローを参照する Flow Reference コンポーネントがサブフローのコンテンツに置き換えられるため、実行時には、そのサブフロー内のイベントプロセッサーの複数のインスタンスがアプリケーション内に存在します。一意の ID またはインスタンスを使用して実行するイベントプロセッサー (バッチプロセッサーなど) では、この動作が問題になる可能性があります。 たとえば、サブフロー内でバッチジョブを設定すると、そのサブフローが複数の Flow Reference コンポーネントで参照されている場合には、アプリケーションがデプロイメント中に失敗します。アプリケーションがデプロイに失敗する理由は、同じジョブインスタンス ID のバッチジョブの複数のインスタンスが存在し、それが許可されないためです。 ## [](#error_handling)エラー処理 (サブフローではない) 各フローは、独自のエラー処理を使用できます。Flow Reference コンポーネントを 介してフローをコールする理由の 1 つは、エラー処理をさまざまな コンテキストに分離することです。たとえば、Web クライアント要求を受信する親フローで HTTP 関連のエラー処理を定義するとします。この親フローで その後の処理のために JMS キューをコールする場合、JMS イベントプロセッサーを 個別の子フローに配置し、Flow Reference コンポーネントを使用してそのフローを コールできます。その後、この子フローで独自の JMS 関連エラー処理を定義できます。 この方法は、Java などの他のプログラミング言語でエラーを処理または伝達 する方法と似ています。 フローまたはサブフローのように、​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept)​も独自の エラー処理を使用してイベントプロセッサーのシーケンスをグループ化します。個別の フローまたはサブフローを作成することなく、フローまたはサブフロー内に Try スコープを配置してフロー内のエラー処理を分離できます。このトレードオフは、 Try スコープによるエラー処理がフロー内でインラインで実行されるため、 他のフローまたはサブフロー間での再利用が困難になることです。 どちらの場合も、Java コード内での Try-Catch ブロックの使用と同様に、 フローをコールするか Try スコープを含めることで、エラー処理が分離されます。たとえば、 JMS キューイベント処理 (前述) を独自のフローまたは Try スコープ内に 配置すると、まったく同じエラー処理動作になりますが、 Try スコープ内のイベントプロセッサーを別のフローからコールする ことはできません。 ## [](#イベント処理の分岐)イベント処理の分岐 フローでイベント処理を別々のスレッドに分岐し、フローの特定ポイントで イベントの非同期処理を可能にするスコープがいくつかあります。たとえば、 ​[Scatter-Gather](https://docs.mulesoft.com/jp/mule-runtime/4.9/scatter-gather-concept)​ や ​[Async](https://docs.mulesoft.com/jp/mule-runtime/4.9/async-scope-reference)​ スコープなどです。​[Choice](https://docs.mulesoft.com/jp/mule-runtime/4.9/choice-router-concept)​ ルーターでは、条件に基づいてイベントプロセッサーのダウンストリームシーケンス を変更できます。 ## [](#関連情報)関連情報 - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/flow-component) - [Mule Runtime](https://docs.mulesoft.com/jp/mule-runtime/4.9/) # プロセスのパフォーマンスを最大限に引き出すアプリケーションの設計 アプリケーションを設計する際には、以下のベストプラクティスを考慮して処理のパフォーマンスを高めてください。これらのプラクティスには、Mule Runtime Engine (Mule) バージョンの選択、アプリケーション設計時の問題の回避、Mule のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#mule-runtime-engine-バージョン)Mule Runtime Engine バージョン アプリケーションのチューニングを開始する前に、Mule バージョンに関する以下の推奨事項を確認してください。 - アプリケーションの作成と実行には最新バージョンの Mule を使用してください。 - 最新のパフォーマンスの向上とバグフィックスのアドバンテージを活用するため、アプリケーションの連動関係を最新のバージョンに更新してください。 - 可能な限り Mule パッチを最新バージョンに更新してください。 - アプリケーションを開発してテストする際には、環境にアプリケーションをデプロイしたときと同じ Mule バージョンを使用してください。 ## [](#処理パフォーマンスを向上させるための設計のヒント)処理パフォーマンスを向上させるための設計のヒント アプリケーションを設計する際には、パフォーマンスを向上させるための以下の推奨事項を考慮してください。 - Java Module を繰り返し使用して Java ライブラリなどのコードを再利用するのではなく、Java 呼び出しをラップする操作で SDK モジュールを作成してください。 - Java や Groovy のようなカスタムスクリプティングコードではなく、DataWeave を使用してデータを変換または強化し、ペイロードを作成してください。 - 次の例のような ​`set-variable/set-payload`​ コンポーネントのシーケンスは避けてください。 ```xml ``` その代わりに、これらを単一の ​`ee:transform`​ 操作に組み合わせることで、各コンポーネントに対して新しいイベントが生成されるのを防止してください。 ```xml ``` - 次の例の様に、​`set-variable`​ 変数を使用して一時的な値を保存することは避けてください。 ```xml ``` これらの値は、これらを必要とするコンポーネントに移動してください。 ```xml ``` - プロパティリゾルバーを使用すると、すべてのイベントで DataWeave を使用する必要があり、処理オーバーヘッドが増大するため、プロパティリゾルバーは作成しないでください。 ```xml ``` その代わりに、プロパティプレースホルダーに DataWeave ロジックを配置して、静的なフロー参照を使用してください。 ```xml ``` ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを設計する場合は、以下の推奨事項を考慮してパフォーマンスを高めてください。 ### [](#apikit)APIkit パフォーマンスを高めるため、APIkit 検証は無効化してください。ペイロードの検証が必要な場合、APIkit は API 仕様に基づいて入力された要求を検証します。 ### [](#dataweave)DataWeave DataWeave を使用する場合は、以下の方法でパフォーマンスを高めることを検討してください。 - ペイロードが大きい場合は、​`indent=false`​ を含めることでクライアントの解析を改善し、応答サイズを抑えてください。 - `content-type`​ を定義することで、ログの冗長メッセージを回避してください。 - 開発中はインライン DataWeave スクリプトを使用し、後で外部ファイルに移動することで、XML を見やすくし、スクリプトを再利用可能にしてください。 - すべての要求で複雑な DataWeave 式をログに記録しないでください。 - コレクションを反復処理して個別の項目を変換するパターンは避けてください。 ```xml { (upper(key)): value } ]]> ... ``` その代わりに、コレクション全体を変換して、後で反復処理を行ってください。 ```xml { book: item mapObject (value, key) -> { (upper(key)): value } } ]]> ... ``` ### [](#バリデーター)バリデーター Groovy スクリプトで例外をスローするのではなく、バリデーターモジュールを使用してください。 ### [](#http-と-https)HTTP と HTTPS HTTP と HTTPS では、以下の推奨事項を考慮してください。 - DataWeave 式による基本認証ヘッダーの手動生成といった手動認証を使用するのではなく、HTTP 用 Anypoint Connector (HTTP Connector) が提供する認証メカニズムを使用してください。 - HTTPS が必要な場合は、HTTP リスナーで TLS コンテキスト参照を使用して、Keytool で生成されたキー-値ペアでキーストアを設定してください。 CloudHub で専用ロードバランサーを使用するときに SSL もロードバランサーレベルで終端できる場合や、ハイブリッドシナリオでオンプレミスのロードバランサーを使用する場合には、HTTPS 設定を回避できます。 ```xml ``` ### [](#データベース)データベース パラメーター化クエリの使用。動的クエリを使用する必要がある場合は、必ず最初に入力を検証してください。動的クエリを使用すると、SQL インジェクション脆弱性の原因となる場合があります。 ### [](#file-connector)File Connector Write 操作で Transform コンポーネントを使用して変換を行うのではなく、DataWeave 式を使用してください。これにより、次の例に示すように、Write 操作後に発生するメッセージペイロードの変更を回避できます。 ```xml #[%dw 2.0 output application/csv --- payload.customers.email ] ``` recursive (再帰) パラメーターを使用して、サブフォルダー内のファイルとフォルダーをリストします。 ```xml ``` ### [](#web-service-consumer-connector)Web Service Consumer Connector プロジェクト内のすべての参照 (XSD) を含む WSDL をインポートするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を使用して、設定がローカル WSDL を参照するようにしてください。 ### [](#amqp-connector)AMQP Connector AMQP 用 Anypoint Connector (AMQP Connector) のパフォーマンスと設定はサーバーによって制約されるため、パフォーマンスの問題を調べるときには、サーバー側の設定を調べて、consume パラメーターまたは publish パラメーターが性能に影響していないかを確認してください。 #### [](#consume-パラメーター)consume パラメーター cconsume パラメーターがパフォーマンスに影響していないかを確認してください。 ##### [](#number-of-consumers-コンシューマーの数)Number Of Consumers (コンシューマーの数) AMQP 設定とリスナーソースのコンシューマー数の設定は、ソースによって実行されて AMQP メッセージを同時に受信するコンシューマーの数を決定します。各コンシューマーは異なるチャネルを作成して使用します。 メッセージのスループットは、コンシューマー数によって異なり、コンシューマー数が増えるほど大きくなります。ただし、スループットは、フローのパフォーマンス特性にも影響されます。 ##### [](#ack-mode-肯定応答モード-パラメーター)ACK Mode (肯定応答モード) パラメーター ACK モードは、AMQP ブローカーからコンシュームするときに使用する肯定応答モードを決定します。肯定応答モード (ACK) は、設定レベルで (​**\[Consumer (コンシューマー)\]**​ タブを使用して) 設定しますが、Listener 操作と Consume 操作はこのモードを変更できます。 次の 3 つの肯定応答モードがあります。 - `AUTO` フローの実行が正常に完了した場合にのみ受信メッセージの自動的な肯定応答を行うには、自動モードを使用します。 - `MANUAL` メッセージの肯定応答を行うタイミングを決定するアプリケーションロジックにすべての責任を委譲するには、手動モードを使用します。 - `IMMEDIATE` アプリケーションがメッセージを処理する前にコンシュームするときにそのメッセージの肯定応答を行うには、即時モードを使用します。 チャネルでトランザクションが開かれると、ACK Mode (肯定応答モード) パラメーターが上書きされ、コミットがプロセスメッセージの肯定応答を自動的に処理して、ロールバックが自動的に回復を処理します。 ##### [](#quality-of-service-tab-サービス品質-タブ)\[Quality of Service Tab (サービス品質)\] タブ QoS パラメーターは (​**\[Quality of Service Tab (サービス品質)\]**​ タブを使用して) 設定レベルで設定します。0 は無制限値を表します。Listener 操作は、この設定を上書きできます。 パラメーターは次のとおりです。 - Prefetch Size (プリフェッチサイズ) プリフェッチサイズウィンドウを定義します。ブローカーは、オクテット (バイト) 単位のプリフェッチサイズウィンドウを超えない範囲でできるだけ多くのメッセージを送信します。 - Prefetch Count (プリフェッチ数) メッセージ全体の最大数に関してグローバルプリフェッチウィンドウを指定します。このパラメーターを ​`prefetch-size`​ パラメーターと組み合わせて使用することで、両方のプリフェッチウィンドウサイズで可能であれば、メッセージを事前に送信できます。 ##### [](#ack-mode-肯定応答モード-と-prefetch-プリフェッチ)ACK Mode (肯定応答モード) と Prefetch (プリフェッチ) 肯定応答モードと QoS プリフェッチの値は、コンシューマーのスループットに大きく影響します。一般に、プリフェッチ値を大きくして Immediate (即時) 肯定応答モードを選択することで最高の配信レートを実現できます。ただし、この設定では配信済みで未処理のメッセージ数も増えるため、コンシューマー RAM の消費量も増えます。 Automatic (自動) または Manual (手動) 肯定応答モードで、プリフェッチ値を無制限にする場合は、注意が必要です。肯定応答のないまま大量のメッセージをコンシュームすると、ブローカーノードのメモリ消費量が増えます。適切なプリフェッチ値は試行錯誤を経て探す必要があり、最適な値はワークロードによって異なります。 #### [](#publish-パラメーター)publish パラメーター 以下のパラメーターは設定レベルで ​**\[Publisher (パブリッシャー)\]**​ タブを使用して設定します。Publish 操作と Publish-Consume 操作では、これらのパラメーターを上書きできます。ユースケースによって、これらのパラメーターのどちらか片方のみを有効化します。 ##### [](#delivery-mode-配信モード-パラメーター)Delivery Mode (配信モード) パラメーター このパラメーターは、AMQP ブローカーへのパブリッシュに使用する配信モードを決定します。可能なパラメーター値: - `PERSISTENT` 永続的なキューに配信されたメッセージは、ブローカーのディスクに記録されます。 - `TRANSIENT` 配信されたメッセージは記録されません。 永続的なメッセージで使用する記録可能なストレージメカニズムの実装はブローカーの責任となります。この機能がパフォーマンスに与える影響は、AMQP サーバーによって異なります。 ##### [](#request-broker-confirm-ブローカーの確認を要求-パラメーター)Request Broker Confirm (ブローカーの確認を要求) パラメーター ブローカーが確認を返さない場合に操作が失敗するかどうかを決定します。このパラメーターを使用すると、パブリッシュされるメッセージごとに、ブローカーとクライアントの間で通信が 1 回増えます。 ## [](#関連情報)関連情報 - [プロパティプレースホルダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-app-properties-to-configure) - [Java 用 Mule SDK 入門](https://docs.mulesoft.com/mule-sdk/latest/getting-started) - [SQL Injection (SQL インジェクション)](https://owasp.org/www-community/attacks/SQL_Injection) - [Finding bottlenecks with RabbitMQ 3.3 (RabbitMQ 3.3 でのボトルネックの特定)](https://www.rabbitmq.com/blog/2014/04/14/finding-bottlenecks-with-rabbitmq-3-3/) # プロセスのパフォーマンスを最大限に引き出すアプリケーションの設計 アプリケーションを設計する際には、以下のベストプラクティスを考慮して処理のパフォーマンスを高めてください。これらのプラクティスには、Mule Runtime Engine (Mule) バージョンの選択、アプリケーション設計時の問題の回避、Mule のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#mule-runtime-engine-バージョン)Mule Runtime Engine バージョン アプリケーションのチューニングを開始する前に、Mule バージョンに関する以下の推奨事項を確認してください。 - アプリケーションの作成と実行には最新バージョンの Mule を使用してください。 - 最新のパフォーマンスの向上とバグフィックスのアドバンテージを活用するため、アプリケーションの連動関係を最新のバージョンに更新してください。 - 可能な限り Mule パッチを最新バージョンに更新してください。 - アプリケーションを開発してテストする際には、環境にアプリケーションをデプロイしたときと同じ Mule バージョンを使用してください。 ## [](#処理パフォーマンスを向上させるための設計のヒント)処理パフォーマンスを向上させるための設計のヒント アプリケーションを設計する際には、パフォーマンスを向上させるための以下の推奨事項を考慮してください。 - Java Module を繰り返し使用して Java ライブラリなどのコードを再利用するのではなく、Java 呼び出しをラップする操作で SDK モジュールを作成してください。 - Java や Groovy のようなカスタムスクリプティングコードではなく、DataWeave を使用してデータを変換または強化し、ペイロードを作成してください。 - 次の例のような ​`set-variable/set-payload`​ コンポーネントのシーケンスは避けてください。 ```xml ``` その代わりに、これらを単一の ​`ee:transform`​ 操作に組み合わせることで、各コンポーネントに対して新しいイベントが生成されるのを防止してください。 ```xml ``` - 次の例の様に、​`set-variable`​ 変数を使用して一時的な値を保存することは避けてください。 ```xml ``` これらの値は、これらを必要とするコンポーネントに移動してください。 ```xml ``` - プロパティリゾルバーを使用すると、すべてのイベントで DataWeave を使用する必要があり、処理オーバーヘッドが増大するため、プロパティリゾルバーは作成しないでください。 ```xml ``` その代わりに、プロパティプレースホルダーに DataWeave ロジックを配置して、静的なフロー参照を使用してください。 ```xml ``` ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを設計する場合は、以下の推奨事項を考慮してパフォーマンスを高めてください。 ### [](#apikit)APIkit パフォーマンスを高めるため、APIkit 検証は無効化してください。ペイロードの検証が必要な場合、APIkit は API 仕様に基づいて入力された要求を検証します。 ### [](#dataweave)DataWeave DataWeave を使用する場合は、以下の方法でパフォーマンスを高めることを検討してください。 - ペイロードが大きい場合は、​`indent=false`​ を含めることでクライアントの解析を改善し、応答サイズを抑えてください。 - `content-type`​ を定義することで、ログの冗長メッセージを回避してください。 - 開発中はインライン DataWeave スクリプトを使用し、後で外部ファイルに移動することで、XML を見やすくし、スクリプトを再利用可能にしてください。 - すべての要求で複雑な DataWeave 式をログに記録しないでください。 - コレクションを反復処理して個別の項目を変換するパターンは避けてください。 ```xml { (upper(key)): value } ]]> ... ``` その代わりに、コレクション全体を変換して、後で反復処理を行ってください。 ```xml { book: item mapObject (value, key) -> { (upper(key)): value } } ]]> ... ``` ### [](#バリデーター)バリデーター Groovy スクリプトで例外をスローするのではなく、バリデーターモジュールを使用してください。 ### [](#http-と-https)HTTP と HTTPS HTTP と HTTPS では、以下の推奨事項を考慮してください。 - DataWeave 式による基本認証ヘッダーの手動生成といった手動認証を使用するのではなく、HTTP 用 Anypoint Connector (HTTP Connector) が提供する認証メカニズムを使用してください。 - HTTPS が必要な場合は、HTTP リスナーで TLS コンテキスト参照を使用して、Keytool で生成されたキー-値ペアでキーストアを設定してください。 CloudHub で専用ロードバランサーを使用するときに SSL もロードバランサーレベルで終端できる場合や、ハイブリッドシナリオでオンプレミスのロードバランサーを使用する場合には、HTTPS 設定を回避できます。 ```xml ``` ### [](#データベース)データベース パラメーター化クエリの使用。動的クエリを使用する必要がある場合は、必ず最初に入力を検証してください。動的クエリを使用すると、SQL インジェクション脆弱性の原因となる場合があります。 ### [](#file-connector)File Connector Write 操作で Transform コンポーネントを使用して変換を行うのではなく、DataWeave 式を使用してください。これにより、次の例に示すように、Write 操作後に発生するメッセージペイロードの変更を回避できます。 ```xml #[%dw 2.0 output application/csv --- payload.customers.email ] ``` recursive (再帰) パラメーターを使用して、サブフォルダー内のファイルとフォルダーをリストします。 ```xml ``` ### [](#web-service-consumer-connector)Web Service Consumer Connector プロジェクト内のすべての参照 (XSD) を含む WSDL をインポートするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を使用して、設定がローカル WSDL を参照するようにしてください。 ### [](#amqp-connector)AMQP Connector AMQP 用 Anypoint Connector (AMQP Connector) のパフォーマンスと設定はサーバーによって制約されるため、パフォーマンスの問題を調べるときには、サーバー側の設定を調べて、consume パラメーターまたは publish パラメーターが性能に影響していないかを確認してください。 #### [](#consume-パラメーター)consume パラメーター cconsume パラメーターがパフォーマンスに影響していないかを確認してください。 ##### [](#number-of-consumers-コンシューマーの数)Number Of Consumers (コンシューマーの数) AMQP 設定とリスナーソースのコンシューマー数の設定は、ソースによって実行されて AMQP メッセージを同時に受信するコンシューマーの数を決定します。各コンシューマーは異なるチャネルを作成して使用します。 メッセージのスループットは、コンシューマー数によって異なり、コンシューマー数が増えるほど大きくなります。ただし、スループットは、フローのパフォーマンス特性にも影響されます。 ##### [](#ack-mode-肯定応答モード-パラメーター)ACK Mode (肯定応答モード) パラメーター ACK モードは、AMQP ブローカーからコンシュームするときに使用する肯定応答モードを決定します。肯定応答モード (ACK) は、設定レベルで (​**\[Consumer (コンシューマー)\]**​ タブを使用して) 設定しますが、Listener 操作と Consume 操作はこのモードを変更できます。 次の 3 つの肯定応答モードがあります。 - `AUTO` フローの実行が正常に完了した場合にのみ受信メッセージの自動的な肯定応答を行うには、自動モードを使用します。 - `MANUAL` メッセージの肯定応答を行うタイミングを決定するアプリケーションロジックにすべての責任を委譲するには、手動モードを使用します。 - `IMMEDIATE` アプリケーションがメッセージを処理する前にコンシュームするときにそのメッセージの肯定応答を行うには、即時モードを使用します。 チャネルでトランザクションが開かれると、ACK Mode (肯定応答モード) パラメーターが上書きされ、コミットがプロセスメッセージの肯定応答を自動的に処理して、ロールバックが自動的に回復を処理します。 ##### [](#quality-of-service-tab-サービス品質-タブ)\[Quality of Service Tab (サービス品質)\] タブ QoS パラメーターは (​**\[Quality of Service Tab (サービス品質)\]**​ タブを使用して) 設定レベルで設定します。0 は無制限値を表します。Listener 操作は、この設定を上書きできます。 パラメーターは次のとおりです。 - Prefetch Size (プリフェッチサイズ) プリフェッチサイズウィンドウを定義します。ブローカーは、オクテット (バイト) 単位のプリフェッチサイズウィンドウを超えない範囲でできるだけ多くのメッセージを送信します。 - Prefetch Count (プリフェッチ数) メッセージ全体の最大数に関してグローバルプリフェッチウィンドウを指定します。このパラメーターを ​`prefetch-size`​ パラメーターと組み合わせて使用することで、両方のプリフェッチウィンドウサイズで可能であれば、メッセージを事前に送信できます。 ##### [](#ack-mode-肯定応答モード-と-prefetch-プリフェッチ)ACK Mode (肯定応答モード) と Prefetch (プリフェッチ) 肯定応答モードと QoS プリフェッチの値は、コンシューマーのスループットに大きく影響します。一般に、プリフェッチ値を大きくして Immediate (即時) 肯定応答モードを選択することで最高の配信レートを実現できます。ただし、この設定では配信済みで未処理のメッセージ数も増えるため、コンシューマー RAM の消費量も増えます。 Automatic (自動) または Manual (手動) 肯定応答モードで、プリフェッチ値を無制限にする場合は、注意が必要です。肯定応答のないまま大量のメッセージをコンシュームすると、ブローカーノードのメモリ消費量が増えます。適切なプリフェッチ値は試行錯誤を経て探す必要があり、最適な値はワークロードによって異なります。 #### [](#publish-パラメーター)publish パラメーター 以下のパラメーターは設定レベルで ​**\[Publisher (パブリッシャー)\]**​ タブを使用して設定します。Publish 操作と Publish-Consume 操作では、これらのパラメーターを上書きできます。ユースケースによって、これらのパラメーターのどちらか片方のみを有効化します。 ##### [](#delivery-mode-配信モード-パラメーター)Delivery Mode (配信モード) パラメーター このパラメーターは、AMQP ブローカーへのパブリッシュに使用する配信モードを決定します。可能なパラメーター値: - `PERSISTENT` 永続的なキューに配信されたメッセージは、ブローカーのディスクに記録されます。 - `TRANSIENT` 配信されたメッセージは記録されません。 永続的なメッセージで使用する記録可能なストレージメカニズムの実装はブローカーの責任となります。この機能がパフォーマンスに与える影響は、AMQP サーバーによって異なります。 ##### [](#request-broker-confirm-ブローカーの確認を要求-パラメーター)Request Broker Confirm (ブローカーの確認を要求) パラメーター ブローカーが確認を返さない場合に操作が失敗するかどうかを決定します。このパラメーターを使用すると、パブリッシュされるメッセージごとに、ブローカーとクライアントの間で通信が 1 回増えます。 ## [](#関連情報)関連情報 - [プロパティプレースホルダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-app-properties-to-configure) - [Java 用 Mule SDK 入門](https://docs.mulesoft.com/mule-sdk/latest/getting-started) - [SQL Injection (SQL インジェクション)](https://owasp.org/www-community/attacks/SQL_Injection) - [Finding bottlenecks with RabbitMQ 3.3 (RabbitMQ 3.3 でのボトルネックの特定)](https://www.rabbitmq.com/blog/2014/04/14/finding-bottlenecks-with-rabbitmq-3-3/) # プロセスのパフォーマンスを最大限に引き出すアプリケーションの設計 アプリケーションを設計する際には、以下のベストプラクティスを考慮して処理のパフォーマンスを高めてください。これらのプラクティスには、Mule Runtime Engine (Mule) バージョンの選択、アプリケーション設計時の問題の回避、Mule のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#mule-runtime-engine-バージョン)Mule Runtime Engine バージョン アプリケーションのチューニングを開始する前に、Mule バージョンに関する以下の推奨事項を確認してください。 - アプリケーションの作成と実行には最新バージョンの Mule を使用してください。 - 最新のパフォーマンスの向上とバグフィックスのアドバンテージを活用するため、アプリケーションの連動関係を最新のバージョンに更新してください。 - 可能な限り Mule パッチを最新バージョンに更新してください。 - アプリケーションを開発してテストする際には、環境にアプリケーションをデプロイしたときと同じ Mule バージョンを使用してください。 ## [](#処理パフォーマンスを向上させるための設計のヒント)処理パフォーマンスを向上させるための設計のヒント アプリケーションを設計する際には、パフォーマンスを向上させるための以下の推奨事項を考慮してください。 - Java Module を繰り返し使用して Java ライブラリなどのコードを再利用するのではなく、Java 呼び出しをラップする操作で SDK モジュールを作成してください。 - Java や Groovy のようなカスタムスクリプティングコードではなく、DataWeave を使用してデータを変換または強化し、ペイロードを作成してください。 - 次の例のような ​`set-variable/set-payload`​ コンポーネントのシーケンスは避けてください。 ```xml ``` その代わりに、これらを単一の ​`ee:transform`​ 操作に組み合わせることで、各コンポーネントに対して新しいイベントが生成されるのを防止してください。 ```xml ``` - 次の例の様に、​`set-variable`​ 変数を使用して一時的な値を保存することは避けてください。 ```xml ``` これらの値は、これらを必要とするコンポーネントに移動してください。 ```xml ``` - プロパティリゾルバーを使用すると、すべてのイベントで DataWeave を使用する必要があり、処理オーバーヘッドが増大するため、プロパティリゾルバーは作成しないでください。 ```xml ``` その代わりに、プロパティプレースホルダーに DataWeave ロジックを配置して、静的なフロー参照を使用してください。 ```xml ``` ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを設計する場合は、以下の推奨事項を考慮してパフォーマンスを高めてください。 ### [](#apikit)APIkit パフォーマンスを高めるため、APIkit 検証は無効化してください。ペイロードの検証が必要な場合、APIkit は API 仕様に基づいて入力された要求を検証します。 ### [](#dataweave)DataWeave DataWeave を使用する場合は、以下の方法でパフォーマンスを高めることを検討してください。 - ペイロードが大きい場合は、​`indent=false`​ を含めることでクライアントの解析を改善し、応答サイズを抑えてください。 - `content-type`​ を定義することで、ログの冗長メッセージを回避してください。 - 開発中はインライン DataWeave スクリプトを使用し、後で外部ファイルに移動することで、XML を見やすくし、スクリプトを再利用可能にしてください。 - すべての要求で複雑な DataWeave 式をログに記録しないでください。 - コレクションを反復処理して個別の項目を変換するパターンは避けてください。 ```xml { (upper(key)): value } ]]> ... ``` その代わりに、コレクション全体を変換して、後で反復処理を行ってください。 ```xml { book: item mapObject (value, key) -> { (upper(key)): value } } ]]> ... ``` ### [](#バリデーター)バリデーター Groovy スクリプトで例外をスローするのではなく、バリデーターモジュールを使用してください。 ### [](#http-と-https)HTTP と HTTPS HTTP と HTTPS では、以下の推奨事項を考慮してください。 - DataWeave 式による基本認証ヘッダーの手動生成といった手動認証を使用するのではなく、HTTP 用 Anypoint Connector (HTTP Connector) が提供する認証メカニズムを使用してください。 - HTTPS が必要な場合は、HTTP リスナーで TLS コンテキスト参照を使用して、Keytool で生成されたキー-値ペアでキーストアを設定してください。 CloudHub で専用ロードバランサーを使用するときに SSL もロードバランサーレベルで終端できる場合や、ハイブリッドシナリオでオンプレミスのロードバランサーを使用する場合には、HTTPS 設定を回避できます。 ```xml ``` ### [](#データベース)データベース パラメーター化クエリの使用。動的クエリを使用する必要がある場合は、必ず最初に入力を検証してください。動的クエリを使用すると、SQL インジェクション脆弱性の原因となる場合があります。 ### [](#ファイルコネクタ)ファイルコネクタ Write 操作で Transform コンポーネントを使用して変換を行うのではなく、DataWeave 式を使用してください。これにより、次の例に示すように、Write 操作後に発生するメッセージペイロードの変更を回避できます。 ```xml #[%dw 2.0 output application/csv --- payload.customers.email ] ``` recursive (再帰) パラメーターを使用して、サブフォルダー内のファイルとフォルダーをリストします。 ```xml ``` ### [](#web-service-consumer-connector)Web Service Consumer Connector プロジェクト内のすべての参照 (XSD) を含む WSDL をインポートするには、Web サービスコンシューマー用 Anypoint Connector (Web サービスコンシューマーコネクタ) を使用して、設定がローカル WSDL を参照するようにしてください。 ### [](#amqp-connector)AMQP Connector AMQP 用 Anypoint Connector (AMQP Connector) のパフォーマンスと設定はサーバーによって制約されるため、パフォーマンスの問題を調べるときには、サーバー側の設定を調べて、consume パラメーターまたは publish パラメーターが性能に影響していないかを確認してください。 #### [](#consume-パラメーター)consume パラメーター cconsume パラメーターがパフォーマンスに影響していないかを確認してください。 ##### [](#number-of-consumers-コンシューマーの数)Number Of Consumers (コンシューマーの数) AMQP 設定とリスナーソースのコンシューマー数の設定は、ソースによって実行されて AMQP メッセージを同時に受信するコンシューマーの数を決定します。各コンシューマーは異なるチャネルを作成して使用します。 メッセージのスループットは、コンシューマー数によって異なり、コンシューマー数が増えるほど大きくなります。ただし、スループットは、フローのパフォーマンス特性にも影響されます。 ##### [](#ack-mode-肯定応答モード-パラメーター)ACK Mode (肯定応答モード) パラメーター ACK モードは、AMQP ブローカーからコンシュームするときに使用する肯定応答モードを決定します。肯定応答モード (ACK) は、設定レベルで (​**\[Consumer (コンシューマー)\]**​ タブを使用して) 設定しますが、Listener 操作と Consume 操作はこのモードを変更できます。 次の 3 つの肯定応答モードがあります。 - `AUTO` フローの実行が正常に完了した場合にのみ受信メッセージの自動的な肯定応答を行うには、自動モードを使用します。 - `MANUAL` メッセージの肯定応答を行うタイミングを決定するアプリケーションロジックにすべての責任を委譲するには、手動モードを使用します。 - `IMMEDIATE` アプリケーションがメッセージを処理する前にコンシュームするときにそのメッセージの肯定応答を行うには、即時モードを使用します。 チャネルでトランザクションが開かれると、ACK Mode (肯定応答モード) パラメーターが上書きされ、コミットがプロセスメッセージの肯定応答を自動的に処理して、ロールバックが自動的に回復を処理します。 ##### [](#quality-of-service-tab-サービス品質-タブ)\[Quality of Service Tab (サービス品質)\] タブ QoS パラメーターは (​**\[Quality of Service Tab (サービス品質)\]**​ タブを使用して) 設定レベルで設定します。0 は無制限値を表します。Listener 操作は、この設定を上書きできます。 パラメーターは次のとおりです。 - Prefetch Size (プリフェッチサイズ) プリフェッチサイズウィンドウを定義します。ブローカーは、オクテット (バイト) 単位のプリフェッチサイズウィンドウを超えない範囲でできるだけ多くのメッセージを送信します。 - Prefetch Count (プリフェッチ数) メッセージ全体の最大数に関してグローバルプリフェッチウィンドウを指定します。このパラメーターを ​`prefetch-size`​ パラメーターと組み合わせて使用することで、両方のプリフェッチウィンドウサイズで可能であれば、メッセージを事前に送信できます。 ##### [](#ack-mode-肯定応答モード-と-prefetch-プリフェッチ)ACK Mode (肯定応答モード) と Prefetch (プリフェッチ) 肯定応答モードと QoS プリフェッチの値は、コンシューマーのスループットに大きく影響します。一般に、プリフェッチ値を大きくして Immediate (即時) 肯定応答モードを選択することで最高の配信レートを実現できます。ただし、この設定では配信済みで未処理のメッセージ数も増えるため、コンシューマー RAM の消費量も増えます。 Automatic (自動) または Manual (手動) 肯定応答モードで、プリフェッチ値を無制限にする場合は、注意が必要です。肯定応答のないまま大量のメッセージをコンシュームすると、ブローカーノードのメモリ消費量が増えます。適切なプリフェッチ値は試行錯誤を経て探す必要があり、最適な値はワークロードによって異なります。 #### [](#publish-パラメーター)publish パラメーター 以下のパラメーターは設定レベルで ​**\[Publisher (パブリッシャー)\]**​ タブを使用して設定します。Publish 操作と Publish-Consume 操作では、これらのパラメーターを上書きできます。使用事例によって、これらのパラメーターのどちらか片方のみを有効化します。 ##### [](#delivery-mode-配信モード-パラメーター)Delivery Mode (配信モード) パラメーター このパラメーターは、AMQP ブローカーへのパブリッシュに使用する配信モードを決定します。可能なパラメーター値: - `PERSISTENT` 永続的なキューに配信されたメッセージは、ブローカーのディスクに記録されます。 - `TRANSIENT` 配信されたメッセージは記録されません。 永続的なメッセージで使用する記録可能なストレージメカニズムの実装はブローカーの責任となります。この機能がパフォーマンスに与える影響は、AMQP サーバーによって異なります。 ##### [](#request-broker-confirm-ブローカーの確認を要求-パラメーター)Request Broker Confirm (ブローカーの確認を要求) パラメーター ブローカーが確認を返さない場合に操作が失敗するかどうかを決定します。このパラメーターを使用すると、パブリッシュされるメッセージごとに、ブローカーとクライアントの間で通信が 1 回増えます。 ## [](#関連情報)関連情報 - [プロパティプレースホルダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-app-properties-to-configure) - [Java 用 Mule SDK 入門](https://docs.mulesoft.com/mule-sdk/latest/getting-started) - [SQL Injection (SQL インジェクション)](https://owasp.org/www-community/attacks/SQL_Injection) - [Finding bottlenecks with RabbitMQ 3.3 (RabbitMQ 3.3 でのボトルネックの特定)](https://www.rabbitmq.com/blog/2014/04/14/finding-bottlenecks-with-rabbitmq-3-3/) # プロセスのパフォーマンスを最大限に引き出すアプリケーションの設計 アプリケーションを設計する際には、以下のベストプラクティスを考慮して処理のパフォーマンスを高めてください。これらのプラクティスには、Mule Runtime Engine (Mule) バージョンの選択、アプリケーション設計時の問題の回避、Mule のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#mule-runtime-engine-バージョン)Mule Runtime Engine バージョン アプリケーションのチューニングを開始する前に、Mule バージョンに関する以下の推奨事項を確認してください。 - アプリケーションの作成と実行には最新バージョンの Mule を使用してください。 - 最新のパフォーマンスの向上とバグフィックスのアドバンテージを活用するため、アプリケーションの連動関係を最新のバージョンに更新してください。 - 可能な限り Mule パッチを最新バージョンに更新してください。 - アプリケーションを開発してテストする際には、環境にアプリケーションをデプロイしたときと同じ Mule バージョンを使用してください。 ## [](#処理パフォーマンスを向上させるための設計のヒント)処理パフォーマンスを向上させるための設計のヒント アプリケーションを設計する際には、パフォーマンスを向上させるための以下の推奨事項を考慮してください。 - Java Module を繰り返し使用して Java ライブラリなどのコードを再利用するのではなく、Java 呼び出しをラップする操作で SDK モジュールを作成してください。 - Java や Groovy のようなカスタムスクリプティングコードではなく、DataWeave を使用してデータを変換または強化し、ペイロードを作成してください。 - 次の例のような ​`set-variable/set-payload`​ コンポーネントのシーケンスは避けてください。 ```xml ``` その代わりに、これらを単一の ​`ee:transform`​ 操作に組み合わせることで、各コンポーネントに対して新しいイベントが生成されるのを防止してください。 ```xml ``` - 次の例の様に、​`set-variable`​ 変数を使用して一時的な値を保存することは避けてください。 ```xml ``` これらの値は、これらを必要とするコンポーネントに移動してください。 ```xml ``` - プロパティリゾルバーを使用すると、すべてのイベントで DataWeave を使用する必要があり、処理オーバーヘッドが増大するため、プロパティリゾルバーは作成しないでください。 ```xml ``` その代わりに、プロパティプレースホルダーに DataWeave ロジックを配置して、静的なフロー参照を使用してください。 ```xml ``` ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを設計する場合は、以下の推奨事項を考慮してパフォーマンスを高めてください。 ### [](#apikit)APIkit パフォーマンスを高めるため、APIkit 検証は無効化してください。ペイロードの検証が必要な場合、APIkit は API 仕様に基づいて入力された要求を検証します。 ### [](#dataweave)DataWeave DataWeave を使用する場合は、以下の方法でパフォーマンスを高めることを検討してください。 - ペイロードが大きい場合は、​`indent=false`​ を含めることでクライアントの解析を改善し、応答サイズを抑えてください。 - `content-type`​ を定義することで、ログの冗長メッセージを回避してください。 - 開発中はインライン DataWeave スクリプトを使用し、後で外部ファイルに移動することで、XML を見やすくし、スクリプトを再利用可能にしてください。 - すべての要求で複雑な DataWeave 式をログに記録しないでください。 - コレクションを反復処理して個別の項目を変換するパターンは避けてください。 ```xml { (upper(key)): value } ]]> ... ``` その代わりに、コレクション全体を変換して、後で反復処理を行ってください。 ```xml { book: item mapObject (value, key) -> { (upper(key)): value } } ]]> ... ``` ### [](#バリデーター)バリデーター Groovy スクリプトで例外をスローするのではなく、バリデーターモジュールを使用してください。 ### [](#http-と-https)HTTP と HTTPS HTTP と HTTPS では、以下の推奨事項を考慮してください。 - DataWeave 式による基本認証ヘッダーの手動生成といった手動認証を使用するのではなく、HTTP 用 Anypoint Connector (HTTP Connector) が提供する認証メカニズムを使用してください。 - HTTPS が必要な場合は、HTTP リスナーで TLS コンテキスト参照を使用して、Keytool で生成されたキー-値ペアでキーストアを設定してください。 CloudHub で専用ロードバランサーを使用するときに SSL もロードバランサーレベルで終端できる場合や、ハイブリッドシナリオでオンプレミスのロードバランサーを使用する場合には、HTTPS 設定を回避できます。 ```xml ``` ### [](#データベース)データベース パラメーター化クエリの使用。動的クエリを使用する必要がある場合は、必ず最初に入力を検証してください。動的クエリを使用すると、SQL インジェクション脆弱性の原因となる場合があります。 ### [](#file-connector)File Connector Write 操作で Transform コンポーネントを使用して変換を行うのではなく、DataWeave 式を使用してください。これにより、次の例に示すように、Write 操作後に発生するメッセージペイロードの変更を回避できます。 ```xml #[%dw 2.0 output application/csv --- payload.customers.email ] ``` recursive (再帰) パラメーターを使用して、サブフォルダー内のファイルとフォルダーをリストします。 ```xml ``` ### [](#web-service-consumer-connector)Web Service Consumer Connector プロジェクト内のすべての参照 (XSD) を含む WSDL をインポートするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を使用して、設定がローカル WSDL を参照するようにしてください。 ### [](#amqp-connector)AMQP Connector AMQP 用 Anypoint Connector (AMQP Connector) のパフォーマンスと設定はサーバーによって制約されるため、パフォーマンスの問題を調べるときには、サーバー側の設定を調べて、consume パラメーターまたは publish パラメーターが性能に影響していないかを確認してください。 #### [](#consume-パラメーター)consume パラメーター cconsume パラメーターがパフォーマンスに影響していないかを確認してください。 ##### [](#number-of-consumers-コンシューマーの数)Number Of Consumers (コンシューマーの数) AMQP 設定とリスナーソースのコンシューマー数の設定は、ソースによって実行されて AMQP メッセージを同時に受信するコンシューマーの数を決定します。各コンシューマーは異なるチャネルを作成して使用します。 メッセージのスループットは、コンシューマー数によって異なり、コンシューマー数が増えるほど大きくなります。ただし、スループットは、フローのパフォーマンス特性にも影響されます。 ##### [](#ack-mode-肯定応答モード-パラメーター)ACK Mode (肯定応答モード) パラメーター ACK モードは、AMQP ブローカーからコンシュームするときに使用する肯定応答モードを決定します。肯定応答モード (ACK) は、設定レベルで (​**\[Consumer (コンシューマー)\]**​ タブを使用して) 設定しますが、Listener 操作と Consume 操作はこのモードを変更できます。 次の 3 つの肯定応答モードがあります。 - `AUTO` フローの実行が正常に完了した場合にのみ受信メッセージの自動的な肯定応答を行うには、自動モードを使用します。 - `MANUAL` メッセージの肯定応答を行うタイミングを決定するアプリケーションロジックにすべての責任を委譲するには、手動モードを使用します。 - `IMMEDIATE` アプリケーションがメッセージを処理する前にコンシュームするときにそのメッセージの肯定応答を行うには、即時モードを使用します。 チャネルでトランザクションが開かれると、ACK Mode (肯定応答モード) パラメーターが上書きされ、コミットがプロセスメッセージの肯定応答を自動的に処理して、ロールバックが自動的に回復を処理します。 ##### [](#quality-of-service-tab-サービス品質-タブ)\[Quality of Service Tab (サービス品質)\] タブ QoS パラメーターは (​**\[Quality of Service Tab (サービス品質)\]**​ タブを使用して) 設定レベルで設定します。0 は無制限値を表します。Listener 操作は、この設定を上書きできます。 パラメーターは次のとおりです。 - Prefetch Size (プリフェッチサイズ) プリフェッチサイズウィンドウを定義します。ブローカーは、オクテット (バイト) 単位のプリフェッチサイズウィンドウを超えない範囲でできるだけ多くのメッセージを送信します。 - Prefetch Count (プリフェッチ数) メッセージ全体の最大数に関してグローバルプリフェッチウィンドウを指定します。このパラメーターを ​`prefetch-size`​ パラメーターと組み合わせて使用することで、両方のプリフェッチウィンドウサイズで可能であれば、メッセージを事前に送信できます。 ##### [](#ack-mode-肯定応答モード-と-prefetch-プリフェッチ)ACK Mode (肯定応答モード) と Prefetch (プリフェッチ) 肯定応答モードと QoS プリフェッチの値は、コンシューマーのスループットに大きく影響します。一般に、プリフェッチ値を大きくして Immediate (即時) 肯定応答モードを選択することで最高の配信レートを実現できます。ただし、この設定では配信済みで未処理のメッセージ数も増えるため、コンシューマー RAM の消費量も増えます。 Automatic (自動) または Manual (手動) 肯定応答モードで、プリフェッチ値を無制限にする場合は、注意が必要です。肯定応答のないまま大量のメッセージをコンシュームすると、ブローカーノードのメモリ消費量が増えます。適切なプリフェッチ値は試行錯誤を経て探す必要があり、最適な値はワークロードによって異なります。 #### [](#publish-パラメーター)publish パラメーター 以下のパラメーターは設定レベルで ​**\[Publisher (パブリッシャー)\]**​ タブを使用して設定します。Publish 操作と Publish-Consume 操作では、これらのパラメーターを上書きできます。ユースケースによって、これらのパラメーターのどちらか片方のみを有効化します。 ##### [](#delivery-mode-配信モード-パラメーター)Delivery Mode (配信モード) パラメーター このパラメーターは、AMQP ブローカーへのパブリッシュに使用する配信モードを決定します。可能なパラメーター値: - `PERSISTENT` 永続的なキューに配信されたメッセージは、ブローカーのディスクに記録されます。 - `TRANSIENT` 配信されたメッセージは記録されません。 永続的なメッセージで使用する記録可能なストレージメカニズムの実装はブローカーの責任となります。この機能がパフォーマンスに与える影響は、AMQP サーバーによって異なります。 ##### [](#request-broker-confirm-ブローカーの確認を要求-パラメーター)Request Broker Confirm (ブローカーの確認を要求) パラメーター ブローカーが確認を返さない場合に操作が失敗するかどうかを決定します。このパラメーターを使用すると、パブリッシュされるメッセージごとに、ブローカーとクライアントの間で通信が 1 回増えます。 ## [](#関連情報)関連情報 - [プロパティプレースホルダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-app-properties-to-configure) - [Java 用 Mule SDK 入門](https://docs.mulesoft.com/mule-sdk/latest/getting-started) - [SQL Injection (SQL インジェクション)](https://owasp.org/www-community/attacks/SQL_Injection) - [Finding bottlenecks with RabbitMQ 3.3 (RabbitMQ 3.3 でのボトルネックの特定)](https://www.rabbitmq.com/blog/2014/04/14/finding-bottlenecks-with-rabbitmq-3-3/) # プロセスのパフォーマンスを最大限に引き出すアプリケーションの設計 アプリケーションを設計する際には、以下のベストプラクティスを考慮して処理のパフォーマンスを高めてください。これらのプラクティスには、Mule Runtime Engine (Mule) バージョンの選択、アプリケーション設計時の問題の回避、Mule のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#mule-runtime-engine-バージョン)Mule Runtime Engine バージョン アプリケーションのチューニングを開始する前に、Mule バージョンに関する以下の推奨事項を確認してください。 - アプリケーションの作成と実行には最新バージョンの Mule を使用してください。 - 最新のパフォーマンスの向上とバグフィックスのアドバンテージを活用するため、アプリケーションの連動関係を最新のバージョンに更新してください。 - 可能な限り Mule パッチを最新バージョンに更新してください。 - アプリケーションを開発してテストする際には、環境にアプリケーションをデプロイしたときと同じ Mule バージョンを使用してください。 ## [](#処理パフォーマンスを向上させるための設計のヒント)処理パフォーマンスを向上させるための設計のヒント アプリケーションを設計する際には、パフォーマンスを向上させるための以下の推奨事項を考慮してください。 - Java Module を繰り返し使用して Java ライブラリなどのコードを再利用するのではなく、Java 呼び出しをラップする操作で SDK モジュールを作成してください。 - Java や Groovy のようなカスタムスクリプティングコードではなく、DataWeave を使用してデータを変換または強化し、ペイロードを作成してください。 - 次の例のような ​`set-variable/set-payload`​ コンポーネントのシーケンスは避けてください。 ```xml ``` その代わりに、これらを単一の ​`ee:transform`​ 操作に組み合わせることで、各コンポーネントに対して新しいイベントが生成されるのを防止してください。 ```xml ``` - 次の例の様に、​`set-variable`​ 変数を使用して一時的な値を保存することは避けてください。 ```xml ``` これらの値は、これらを必要とするコンポーネントに移動してください。 ```xml ``` - プロパティリゾルバーを使用すると、すべてのイベントで DataWeave を使用する必要があり、処理オーバーヘッドが増大するため、プロパティリゾルバーは作成しないでください。 ```xml ``` その代わりに、プロパティプレースホルダーに DataWeave ロジックを配置して、静的なフロー参照を使用してください。 ```xml ``` ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを設計する場合は、以下の推奨事項を考慮してパフォーマンスを高めてください。 ### [](#apikit)APIkit パフォーマンスを高めるため、APIkit 検証は無効化してください。ペイロードの検証が必要な場合、APIkit は API 仕様に基づいて入力された要求を検証します。 ### [](#dataweave)DataWeave DataWeave を使用する場合は、以下の方法でパフォーマンスを高めることを検討してください。 - ペイロードが大きい場合は、​`indent=false`​ を含めることでクライアントの解析を改善し、応答サイズを抑えてください。 - `content-type`​ を定義することで、ログの冗長メッセージを回避してください。 - 開発中はインライン DataWeave スクリプトを使用し、後で外部ファイルに移動することで、XML を見やすくし、スクリプトを再利用可能にしてください。 - すべての要求で複雑な DataWeave 式をログに記録しないでください。 - コレクションを反復処理して個別の項目を変換するパターンは避けてください。 ```xml { (upper(key)): value } ]]> ... ``` その代わりに、コレクション全体を変換して、後で反復処理を行ってください。 ```xml { book: item mapObject (value, key) -> { (upper(key)): value } } ]]> ... ``` ### [](#バリデーター)バリデーター Groovy スクリプトで例外をスローするのではなく、バリデーターモジュールを使用してください。 ### [](#http-と-https)HTTP と HTTPS HTTP と HTTPS では、以下の推奨事項を考慮してください。 - DataWeave 式による基本認証ヘッダーの手動生成といった手動認証を使用するのではなく、HTTP 用 Anypoint Connector (HTTP Connector) が提供する認証メカニズムを使用してください。 - HTTPS が必要な場合は、HTTP リスナーで TLS コンテキスト参照を使用して、Keytool で生成されたキー-値ペアでキーストアを設定してください。 CloudHub で専用ロードバランサーを使用するときに SSL もロードバランサーレベルで終端できる場合や、ハイブリッドシナリオでオンプレミスのロードバランサーを使用する場合には、HTTPS 設定を回避できます。 ```xml ``` ### [](#データベース)データベース パラメーター化クエリの使用。動的クエリを使用する必要がある場合は、必ず最初に入力を検証してください。動的クエリを使用すると、SQL インジェクション脆弱性の原因となる場合があります。 ### [](#file-connector)File Connector Write 操作で Transform コンポーネントを使用して変換を行うのではなく、DataWeave 式を使用してください。これにより、次の例に示すように、Write 操作後に発生するメッセージペイロードの変更を回避できます。 ```xml #[%dw 2.0 output application/csv --- payload.customers.email ] ``` recursive (再帰) パラメーターを使用して、サブフォルダー内のファイルとフォルダーをリストします。 ```xml ``` ### [](#web-service-consumer-connector)Web Service Consumer Connector プロジェクト内のすべての参照 (XSD) を含む WSDL をインポートするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を使用して、設定がローカル WSDL を参照するようにしてください。 ### [](#amqp-connector)AMQP Connector AMQP 用 Anypoint Connector (AMQP Connector) のパフォーマンスと設定はサーバーによって制約されるため、パフォーマンスの問題を調べるときには、サーバー側の設定を調べて、consume パラメーターまたは publish パラメーターが性能に影響していないかを確認してください。 #### [](#consume-パラメーター)consume パラメーター cconsume パラメーターがパフォーマンスに影響していないかを確認してください。 ##### [](#number-of-consumers-コンシューマーの数)Number Of Consumers (コンシューマーの数) AMQP 設定とリスナーソースのコンシューマー数の設定は、ソースによって実行されて AMQP メッセージを同時に受信するコンシューマーの数を決定します。各コンシューマーは異なるチャネルを作成して使用します。 メッセージのスループットは、コンシューマー数によって異なり、コンシューマー数が増えるほど大きくなります。ただし、スループットは、フローのパフォーマンス特性にも影響されます。 ##### [](#ack-mode-肯定応答モード-パラメーター)ACK Mode (肯定応答モード) パラメーター ACK モードは、AMQP ブローカーからコンシュームするときに使用する肯定応答モードを決定します。肯定応答モード (ACK) は、設定レベルで (​**\[Consumer (コンシューマー)\]**​ タブを使用して) 設定しますが、Listener 操作と Consume 操作はこのモードを変更できます。 次の 3 つの肯定応答モードがあります。 - `AUTO` フローの実行が正常に完了した場合にのみ受信メッセージの自動的な肯定応答を行うには、自動モードを使用します。 - `MANUAL` メッセージの肯定応答を行うタイミングを決定するアプリケーションロジックにすべての責任を委譲するには、手動モードを使用します。 - `IMMEDIATE` アプリケーションがメッセージを処理する前にコンシュームするときにそのメッセージの肯定応答を行うには、即時モードを使用します。 チャネルでトランザクションが開かれると、ACK Mode (肯定応答モード) パラメーターが上書きされ、コミットがプロセスメッセージの肯定応答を自動的に処理して、ロールバックが自動的に回復を処理します。 ##### [](#quality-of-service-tab-サービス品質-タブ)\[Quality of Service Tab (サービス品質)\] タブ QoS パラメーターは (​**\[Quality of Service Tab (サービス品質)\]**​ タブを使用して) 設定レベルで設定します。0 は無制限値を表します。Listener 操作は、この設定を上書きできます。 パラメーターは次のとおりです。 - Prefetch Size (プリフェッチサイズ) プリフェッチサイズウィンドウを定義します。ブローカーは、オクテット (バイト) 単位のプリフェッチサイズウィンドウを超えない範囲でできるだけ多くのメッセージを送信します。 - Prefetch Count (プリフェッチ数) メッセージ全体の最大数に関してグローバルプリフェッチウィンドウを指定します。このパラメーターを ​`prefetch-size`​ パラメーターと組み合わせて使用することで、両方のプリフェッチウィンドウサイズで可能であれば、メッセージを事前に送信できます。 ##### [](#ack-mode-肯定応答モード-と-prefetch-プリフェッチ)ACK Mode (肯定応答モード) と Prefetch (プリフェッチ) 肯定応答モードと QoS プリフェッチの値は、コンシューマーのスループットに大きく影響します。一般に、プリフェッチ値を大きくして Immediate (即時) 肯定応答モードを選択することで最高の配信レートを実現できます。ただし、この設定では配信済みで未処理のメッセージ数も増えるため、コンシューマー RAM の消費量も増えます。 Automatic (自動) または Manual (手動) 肯定応答モードで、プリフェッチ値を無制限にする場合は、注意が必要です。肯定応答のないまま大量のメッセージをコンシュームすると、ブローカーノードのメモリ消費量が増えます。適切なプリフェッチ値は試行錯誤を経て探す必要があり、最適な値はワークロードによって異なります。 #### [](#publish-パラメーター)publish パラメーター 以下のパラメーターは設定レベルで ​**\[Publisher (パブリッシャー)\]**​ タブを使用して設定します。Publish 操作と Publish-Consume 操作では、これらのパラメーターを上書きできます。ユースケースによって、これらのパラメーターのどちらか片方のみを有効化します。 ##### [](#delivery-mode-配信モード-パラメーター)Delivery Mode (配信モード) パラメーター このパラメーターは、AMQP ブローカーへのパブリッシュに使用する配信モードを決定します。可能なパラメーター値: - `PERSISTENT` 永続的なキューに配信されたメッセージは、ブローカーのディスクに記録されます。 - `TRANSIENT` 配信されたメッセージは記録されません。 永続的なメッセージで使用する記録可能なストレージメカニズムの実装はブローカーの責任となります。この機能がパフォーマンスに与える影響は、AMQP サーバーによって異なります。 ##### [](#request-broker-confirm-ブローカーの確認を要求-パラメーター)Request Broker Confirm (ブローカーの確認を要求) パラメーター ブローカーが確認を返さない場合に操作が失敗するかどうかを決定します。このパラメーターを使用すると、パブリッシュされるメッセージごとに、ブローカーとクライアントの間で通信が 1 回増えます。 ## [](#関連情報)関連情報 - [プロパティプレースホルダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-app-properties-to-configure) - [Java 用 Mule SDK 入門](https://docs.mulesoft.com/mule-sdk/latest/getting-started) - [SQL Injection (SQL インジェクション)](https://owasp.org/www-community/attacks/SQL_Injection) - [Finding bottlenecks with RabbitMQ 3.3 (RabbitMQ 3.3 でのボトルネックの特定)](https://www.rabbitmq.com/blog/2014/04/14/finding-bottlenecks-with-rabbitmq-3-3/) # プロセスのパフォーマンスを最大限に引き出すアプリケーションの設計 アプリケーションを設計する際には、以下のベストプラクティスを考慮して処理のパフォーマンスを高めてください。これらのプラクティスには、Mule Runtime Engine (Mule) バージョンの選択、アプリケーション設計時の問題の回避、Mule のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#mule-runtime-engine-バージョン)Mule Runtime Engine バージョン アプリケーションのチューニングを開始する前に、Mule バージョンに関する以下の推奨事項を確認してください。 - アプリケーションの作成と実行には最新バージョンの Mule を使用してください。 - 最新のパフォーマンスの向上とバグフィックスのアドバンテージを活用するため、アプリケーションの連動関係を最新のバージョンに更新してください。 - 可能な限り Mule パッチを最新バージョンに更新してください。 - アプリケーションを開発してテストする際には、環境にアプリケーションをデプロイしたときと同じ Mule バージョンを使用してください。 ## [](#処理パフォーマンスを向上させるための設計のヒント)処理パフォーマンスを向上させるための設計のヒント アプリケーションを設計する際には、パフォーマンスを向上させるための以下の推奨事項を考慮してください。 - Java Module を繰り返し使用して Java ライブラリなどのコードを再利用するのではなく、Java 呼び出しをラップする操作で SDK モジュールを作成してください。 - Java や Groovy のようなカスタムスクリプティングコードではなく、DataWeave を使用してデータを変換または強化し、ペイロードを作成してください。 - 次の例のような ​`set-variable/set-payload`​ コンポーネントのシーケンスは避けてください。 ```xml ``` その代わりに、これらを単一の ​`ee:transform`​ 操作に組み合わせることで、各コンポーネントに対して新しいイベントが生成されるのを防止してください。 ```xml ``` - 次の例の様に、​`set-variable`​ 変数を使用して一時的な値を保存することは避けてください。 ```xml ``` これらの値は、これらを必要とするコンポーネントに移動してください。 ```xml ``` - プロパティリゾルバーを使用すると、すべてのイベントで DataWeave を使用する必要があり、処理オーバーヘッドが増大するため、プロパティリゾルバーは作成しないでください。 ```xml ``` その代わりに、プロパティプレースホルダーに DataWeave ロジックを配置して、静的なフロー参照を使用してください。 ```xml ``` ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを設計する場合は、以下の推奨事項を考慮してパフォーマンスを高めてください。 ### [](#apikit)APIkit パフォーマンスを高めるため、APIkit 検証は無効化してください。ペイロードの検証が必要な場合、APIkit は API 仕様に基づいて入力された要求を検証します。 ### [](#dataweave)DataWeave DataWeave を使用する場合は、以下の方法でパフォーマンスを高めることを検討してください。 - ペイロードが大きい場合は、​`indent=false`​ を含めることでクライアントの解析を改善し、応答サイズを抑えてください。 - `content-type`​ を定義することで、ログの冗長メッセージを回避してください。 - 開発中はインライン DataWeave スクリプトを使用し、後で外部ファイルに移動することで、XML を見やすくし、スクリプトを再利用可能にしてください。 - すべての要求で複雑な DataWeave 式をログに記録しないでください。 - コレクションを反復処理して個別の項目を変換するパターンは避けてください。 ```xml { (upper(key)): value } ]]> ... ``` その代わりに、コレクション全体を変換して、後で反復処理を行ってください。 ```xml { book: item mapObject (value, key) -> { (upper(key)): value } } ]]> ... ``` ### [](#バリデーター)バリデーター Groovy スクリプトで例外をスローするのではなく、バリデーターモジュールを使用してください。 ### [](#http-と-https)HTTP と HTTPS HTTP と HTTPS では、以下の推奨事項を考慮してください。 - DataWeave 式による基本認証ヘッダーの手動生成といった手動認証を使用するのではなく、HTTP 用 Anypoint Connector (HTTP Connector) が提供する認証メカニズムを使用してください。 - HTTPS が必要な場合は、HTTP リスナーで TLS コンテキスト参照を使用して、Keytool で生成されたキー-値ペアでキーストアを設定してください。 CloudHub で専用ロードバランサーを使用するときに SSL もロードバランサーレベルで終端できる場合や、ハイブリッドシナリオでオンプレミスのロードバランサーを使用する場合には、HTTPS 設定を回避できます。 ```xml ``` ### [](#データベース)データベース パラメーター化クエリの使用。動的クエリを使用する必要がある場合は、必ず最初に入力を検証してください。動的クエリを使用すると、SQL インジェクション脆弱性の原因となる場合があります。 ### [](#file-connector)File Connector Write 操作で Transform コンポーネントを使用して変換を行うのではなく、DataWeave 式を使用してください。これにより、次の例に示すように、Write 操作後に発生するメッセージペイロードの変更を回避できます。 ```xml #[%dw 2.0 output application/csv --- payload.customers.email ] ``` recursive (再帰) パラメーターを使用して、サブフォルダー内のファイルとフォルダーをリストします。 ```xml ``` ### [](#web-service-consumer-connector)Web Service Consumer Connector プロジェクト内のすべての参照 (XSD) を含む WSDL をインポートするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を使用して、設定がローカル WSDL を参照するようにしてください。 ### [](#amqp-connector)AMQP Connector AMQP 用 Anypoint Connector (AMQP Connector) のパフォーマンスと設定はサーバーによって制約されるため、パフォーマンスの問題を調べるときには、サーバー側の設定を調べて、consume パラメーターまたは publish パラメーターが性能に影響していないかを確認してください。 #### [](#consume-パラメーター)consume パラメーター cconsume パラメーターがパフォーマンスに影響していないかを確認してください。 ##### [](#number-of-consumers-コンシューマーの数)Number Of Consumers (コンシューマーの数) AMQP 設定とリスナーソースのコンシューマー数の設定は、ソースによって実行されて AMQP メッセージを同時に受信するコンシューマーの数を決定します。各コンシューマーは異なるチャネルを作成して使用します。 メッセージのスループットは、コンシューマー数によって異なり、コンシューマー数が増えるほど大きくなります。ただし、スループットは、フローのパフォーマンス特性にも影響されます。 ##### [](#ack-mode-肯定応答モード-パラメーター)ACK Mode (肯定応答モード) パラメーター ACK モードは、AMQP ブローカーからコンシュームするときに使用する肯定応答モードを決定します。肯定応答モード (ACK) は、設定レベルで (​**\[Consumer (コンシューマー)\]**​ タブを使用して) 設定しますが、Listener 操作と Consume 操作はこのモードを変更できます。 次の 3 つの肯定応答モードがあります。 - `AUTO` フローの実行が正常に完了した場合にのみ受信メッセージの自動的な肯定応答を行うには、自動モードを使用します。 - `MANUAL` メッセージの肯定応答を行うタイミングを決定するアプリケーションロジックにすべての責任を委譲するには、手動モードを使用します。 - `IMMEDIATE` アプリケーションがメッセージを処理する前にコンシュームするときにそのメッセージの肯定応答を行うには、即時モードを使用します。 チャネルでトランザクションが開かれると、ACK Mode (肯定応答モード) パラメーターが上書きされ、コミットがプロセスメッセージの肯定応答を自動的に処理して、ロールバックが自動的に回復を処理します。 ##### [](#quality-of-service-tab-サービス品質-タブ)\[Quality of Service Tab (サービス品質)\] タブ QoS パラメーターは (​**\[Quality of Service Tab (サービス品質)\]**​ タブを使用して) 設定レベルで設定します。0 は無制限値を表します。Listener 操作は、この設定を上書きできます。 パラメーターは次のとおりです。 - Prefetch Size (プリフェッチサイズ) プリフェッチサイズウィンドウを定義します。ブローカーは、オクテット (バイト) 単位のプリフェッチサイズウィンドウを超えない範囲でできるだけ多くのメッセージを送信します。 - Prefetch Count (プリフェッチ数) メッセージ全体の最大数に関してグローバルプリフェッチウィンドウを指定します。このパラメーターを ​`prefetch-size`​ パラメーターと組み合わせて使用することで、両方のプリフェッチウィンドウサイズで可能であれば、メッセージを事前に送信できます。 ##### [](#ack-mode-肯定応答モード-と-prefetch-プリフェッチ)ACK Mode (肯定応答モード) と Prefetch (プリフェッチ) 肯定応答モードと QoS プリフェッチの値は、コンシューマーのスループットに大きく影響します。一般に、プリフェッチ値を大きくして Immediate (即時) 肯定応答モードを選択することで最高の配信レートを実現できます。ただし、この設定では配信済みで未処理のメッセージ数も増えるため、コンシューマー RAM の消費量も増えます。 Automatic (自動) または Manual (手動) 肯定応答モードで、プリフェッチ値を無制限にする場合は、注意が必要です。肯定応答のないまま大量のメッセージをコンシュームすると、ブローカーノードのメモリ消費量が増えます。適切なプリフェッチ値は試行錯誤を経て探す必要があり、最適な値はワークロードによって異なります。 #### [](#publish-パラメーター)publish パラメーター 以下のパラメーターは設定レベルで ​**\[Publisher (パブリッシャー)\]**​ タブを使用して設定します。Publish 操作と Publish-Consume 操作では、これらのパラメーターを上書きできます。ユースケースによって、これらのパラメーターのどちらか片方のみを有効化します。 ##### [](#delivery-mode-配信モード-パラメーター)Delivery Mode (配信モード) パラメーター このパラメーターは、AMQP ブローカーへのパブリッシュに使用する配信モードを決定します。可能なパラメーター値: - `PERSISTENT` 永続的なキューに配信されたメッセージは、ブローカーのディスクに記録されます。 - `TRANSIENT` 配信されたメッセージは記録されません。 永続的なメッセージで使用する記録可能なストレージメカニズムの実装はブローカーの責任となります。この機能がパフォーマンスに与える影響は、AMQP サーバーによって異なります。 ##### [](#request-broker-confirm-ブローカーの確認を要求-パラメーター)Request Broker Confirm (ブローカーの確認を要求) パラメーター ブローカーが確認を返さない場合に操作が失敗するかどうかを決定します。このパラメーターを使用すると、パブリッシュされるメッセージごとに、ブローカーとクライアントの間で通信が 1 回増えます。 ## [](#関連情報)関連情報 - [プロパティプレースホルダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-app-properties-to-configure) - [Java 用 Mule SDK 入門](https://docs.mulesoft.com/mule-sdk/latest/getting-started) - [SQL Injection (SQL インジェクション)](https://owasp.org/www-community/attacks/SQL_Injection) - [Finding bottlenecks with RabbitMQ 3.3 (RabbitMQ 3.3 でのボトルネックの特定)](https://www.rabbitmq.com/blog/2014/04/14/finding-bottlenecks-with-rabbitmq-3-3/) # プロセスのパフォーマンスを最大限に引き出すアプリケーションの設計 アプリケーションを設計する際には、以下のベストプラクティスを考慮して処理のパフォーマンスを高めてください。これらのプラクティスには、Mule Runtime Engine (Mule) バージョンの選択、アプリケーション設計時の問題の回避、Mule のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 ## [](#mule-runtime-engine-バージョン)Mule Runtime Engine バージョン アプリケーションのチューニングを開始する前に、Mule バージョンに関する以下の推奨事項を確認してください。 - アプリケーションの作成と実行には最新バージョンの Mule を使用してください。 - 最新のパフォーマンスの向上とバグフィックスのアドバンテージを活用するため、アプリケーションの連動関係を最新のバージョンに更新してください。 - 可能な限り Mule パッチを最新バージョンに更新してください。 - アプリケーションを開発してテストする際には、環境にアプリケーションをデプロイしたときと同じ Mule バージョンを使用してください。 ## [](#処理パフォーマンスを向上させるための設計のヒント)処理パフォーマンスを向上させるための設計のヒント アプリケーションを設計する際には、パフォーマンスを向上させるための以下の推奨事項を考慮してください。 - Java Module を繰り返し使用して Java ライブラリなどのコードを再利用するのではなく、Java 呼び出しをラップする操作で SDK モジュールを作成してください。 - Java や Groovy のようなカスタムスクリプティングコードではなく、DataWeave を使用してデータを変換または強化し、ペイロードを作成してください。 - 次の例のような ​`set-variable/set-payload`​ コンポーネントのシーケンスは避けてください。 ```xml ``` その代わりに、これらを単一の ​`ee:transform`​ 操作に組み合わせることで、各コンポーネントに対して新しいイベントが生成されるのを防止してください。 ```xml ``` - 次の例の様に、​`set-variable`​ 変数を使用して一時的な値を保存することは避けてください。 ```xml ``` これらの値は、これらを必要とするコンポーネントに移動してください。 ```xml ``` - プロパティリゾルバーを使用すると、すべてのイベントで DataWeave を使用する必要があり、処理オーバーヘッドが増大するため、プロパティリゾルバーは作成しないでください。 ```xml ``` その代わりに、プロパティプレースホルダーに DataWeave ロジックを配置して、静的なフロー参照を使用してください。 ```xml ``` ## [](#コンポーネントコネクタのベストプラクティス)コンポーネントコネクタのベストプラクティス Mule コンポーネントとコネクタを使用してアプリケーションを設計する場合は、以下の推奨事項を考慮してパフォーマンスを高めてください。 ### [](#apikit)APIkit パフォーマンスを高めるため、APIkit 検証は無効化してください。ペイロードの検証が必要な場合、APIkit は API 仕様に基づいて入力された要求を検証します。 ### [](#dataweave)DataWeave DataWeave を使用する場合は、以下の方法でパフォーマンスを高めることを検討してください。 - ペイロードが大きい場合は、​`indent=false`​ を含めることでクライアントの解析を改善し、応答サイズを抑えてください。 - `content-type`​ を定義することで、ログの冗長メッセージを回避してください。 - 開発中はインライン DataWeave スクリプトを使用し、後で外部ファイルに移動することで、XML を見やすくし、スクリプトを再利用可能にしてください。 - すべての要求で複雑な DataWeave 式をログに記録しないでください。 - コレクションを反復処理して個別の項目を変換するパターンは避けてください。 ```xml { (upper(key)): value } ]]> ... ``` その代わりに、コレクション全体を変換して、後で反復処理を行ってください。 ```xml { book: item mapObject (value, key) -> { (upper(key)): value } } ]]> ... ``` ### [](#バリデーター)バリデーター Groovy スクリプトで例外をスローするのではなく、バリデーターモジュールを使用してください。 ### [](#http-と-https)HTTP と HTTPS HTTP と HTTPS では、以下の推奨事項を考慮してください。 - DataWeave 式による基本認証ヘッダーの手動生成といった手動認証を使用するのではなく、HTTP 用 Anypoint Connector (HTTP Connector) が提供する認証メカニズムを使用してください。 - HTTPS が必要な場合は、HTTP リスナーで TLS コンテキスト参照を使用して、Keytool で生成されたキー-値ペアでキーストアを設定してください。 CloudHub で専用ロードバランサーを使用するときに SSL もロードバランサーレベルで終端できる場合や、ハイブリッドシナリオでオンプレミスのロードバランサーを使用する場合には、HTTPS 設定を回避できます。 ```xml ``` ### [](#データベース)データベース パラメーター化クエリの使用。動的クエリを使用する必要がある場合は、必ず最初に入力を検証してください。動的クエリを使用すると、SQL インジェクション脆弱性の原因となる場合があります。 ### [](#file-connector)File Connector Write 操作で Transform コンポーネントを使用して変換を行うのではなく、DataWeave 式を使用してください。これにより、次の例に示すように、Write 操作後に発生するメッセージペイロードの変更を回避できます。 ```xml #[%dw 2.0 output application/csv --- payload.customers.email ] ``` recursive (再帰) パラメーターを使用して、サブフォルダー内のファイルとフォルダーをリストします。 ```xml ``` ### [](#web-service-consumer-connector)Web Service Consumer Connector プロジェクト内のすべての参照 (XSD) を含む WSDL をインポートするには、Web サービスコンシューマー用 Anypoint Connector (Web Service Consumer Connector) を使用して、設定がローカル WSDL を参照するようにしてください。 ### [](#amqp-connector)AMQP Connector AMQP 用 Anypoint Connector (AMQP Connector) のパフォーマンスと設定はサーバーによって制約されるため、パフォーマンスの問題を調べるときには、サーバー側の設定を調べて、consume パラメーターまたは publish パラメーターが性能に影響していないかを確認してください。 #### [](#consume-パラメーター)consume パラメーター cconsume パラメーターがパフォーマンスに影響していないかを確認してください。 ##### [](#number-of-consumers-コンシューマーの数)Number Of Consumers (コンシューマーの数) AMQP 設定とリスナーソースのコンシューマー数の設定は、ソースによって実行されて AMQP メッセージを同時に受信するコンシューマーの数を決定します。各コンシューマーは異なるチャネルを作成して使用します。 メッセージのスループットは、コンシューマー数によって異なり、コンシューマー数が増えるほど大きくなります。ただし、スループットは、フローのパフォーマンス特性にも影響されます。 ##### [](#ack-mode-肯定応答モード-パラメーター)ACK Mode (肯定応答モード) パラメーター ACK モードは、AMQP ブローカーからコンシュームするときに使用する肯定応答モードを決定します。肯定応答モード (ACK) は、設定レベルで (​**\[Consumer (コンシューマー)\]**​ タブを使用して) 設定しますが、Listener 操作と Consume 操作はこのモードを変更できます。 次の 3 つの肯定応答モードがあります。 - `AUTO` フローの実行が正常に完了した場合にのみ受信メッセージの自動的な肯定応答を行うには、自動モードを使用します。 - `MANUAL` メッセージの肯定応答を行うタイミングを決定するアプリケーションロジックにすべての責任を委譲するには、手動モードを使用します。 - `IMMEDIATE` アプリケーションがメッセージを処理する前にコンシュームするときにそのメッセージの肯定応答を行うには、即時モードを使用します。 チャネルでトランザクションが開かれると、ACK Mode (肯定応答モード) パラメーターが上書きされ、コミットがプロセスメッセージの肯定応答を自動的に処理して、ロールバックが自動的に回復を処理します。 ##### [](#quality-of-service-tab-サービス品質-タブ)\[Quality of Service Tab (サービス品質)\] タブ QoS パラメーターは (​**\[Quality of Service Tab (サービス品質)\]**​ タブを使用して) 設定レベルで設定します。0 は無制限値を表します。Listener 操作は、この設定を上書きできます。 パラメーターは次のとおりです。 - Prefetch Size (プリフェッチサイズ) プリフェッチサイズウィンドウを定義します。ブローカーは、オクテット (バイト) 単位のプリフェッチサイズウィンドウを超えない範囲でできるだけ多くのメッセージを送信します。 - Prefetch Count (プリフェッチ数) メッセージ全体の最大数に関してグローバルプリフェッチウィンドウを指定します。このパラメーターを ​`prefetch-size`​ パラメーターと組み合わせて使用することで、両方のプリフェッチウィンドウサイズで可能であれば、メッセージを事前に送信できます。 ##### [](#ack-mode-肯定応答モード-と-prefetch-プリフェッチ)ACK Mode (肯定応答モード) と Prefetch (プリフェッチ) 肯定応答モードと QoS プリフェッチの値は、コンシューマーのスループットに大きく影響します。一般に、プリフェッチ値を大きくして Immediate (即時) 肯定応答モードを選択することで最高の配信レートを実現できます。ただし、この設定では配信済みで未処理のメッセージ数も増えるため、コンシューマー RAM の消費量も増えます。 Automatic (自動) または Manual (手動) 肯定応答モードで、プリフェッチ値を無制限にする場合は、注意が必要です。肯定応答のないまま大量のメッセージをコンシュームすると、ブローカーノードのメモリ消費量が増えます。適切なプリフェッチ値は試行錯誤を経て探す必要があり、最適な値はワークロードによって異なります。 #### [](#publish-パラメーター)publish パラメーター 以下のパラメーターは設定レベルで ​**\[Publisher (パブリッシャー)\]**​ タブを使用して設定します。Publish 操作と Publish-Consume 操作では、これらのパラメーターを上書きできます。ユースケースによって、これらのパラメーターのどちらか片方のみを有効化します。 ##### [](#delivery-mode-配信モード-パラメーター)Delivery Mode (配信モード) パラメーター このパラメーターは、AMQP ブローカーへのパブリッシュに使用する配信モードを決定します。可能なパラメーター値: - `PERSISTENT` 永続的なキューに配信されたメッセージは、ブローカーのディスクに記録されます。 - `TRANSIENT` 配信されたメッセージは記録されません。 永続的なメッセージで使用する記録可能なストレージメカニズムの実装はブローカーの責任となります。この機能がパフォーマンスに与える影響は、AMQP サーバーによって異なります。 ##### [](#request-broker-confirm-ブローカーの確認を要求-パラメーター)Request Broker Confirm (ブローカーの確認を要求) パラメーター ブローカーが確認を返さない場合に操作が失敗するかどうかを決定します。このパラメーターを使用すると、パブリッシュされるメッセージごとに、ブローカーとクライアントの間で通信が 1 回増えます。 ## [](#関連情報)関連情報 - [プロパティプレースホルダーの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-app-properties-to-configure) - [Java 用 Mule SDK 入門](https://docs.mulesoft.com/mule-sdk/latest/getting-started) - [SQL Injection (SQL インジェクション)](https://owasp.org/www-community/attacks/SQL_Injection) - [Finding bottlenecks with RabbitMQ 3.3 (RabbitMQ 3.3 でのボトルネックの特定)](https://www.rabbitmq.com/blog/2014/04/14/finding-bottlenecks-with-rabbitmq-3-3/) # プロパティの設定 プロパティプレースホルダーやシステムプロパティなどのプロパティを設定できます。 ## [](#プロパティプレースホルダー)プロパティプレースホルダー Mule 設定では、 [Ant](http://ant.apache.org/)​ スタイルのプロパティプレースホルダーを使用できます。例: ```xml ``` 後続のセクションで説明されているように、これらのプレースホルダーの値は、さまざまな方法で使用可能にすることができます。 また、プロパティプレースホルダー値の解決をエスケープすることもできます。 ```xml ``` プロパティの値を返す代わりに、Logger コンポーネントは文字列 ​`"${property.value}"`​ を返します。エスケープ文字 ​`\`​ を使用して、プロパティのプレフィックス (​`${`​ 文字シーケンス) の解決をエスケープすることもできます。 ## [](#グローバルプロパティ)グローバルプロパティ ``​ 要素を使用すると、Mule 設定内 (別の Mule 設定ファイル内など) からプレースホルダーの値を設定できます。グローバルプロパティ構文を使用して、​`.yaml`​ または ​`.properties`​ ファイルの値を参照し、設定プロパティまたはセキュアな設定プロパティに連動する新しい (グローバル) プロパティを作成できます。設定プロパティを参照するには、プロパティファイルのセクションを読み取ります。 ```xml ``` ## [](#プロパティファイル)プロパティファイル カスタムファイルのプロパティを読み込むには、カスタムプロパティファイルを ​`src/main/resources`​ に配置し、​``​ タグを使用します。 ```xml ``` 複数のプロパティファイルを読み込むには、読み込むファイルごとに ​``​ タグを定義します。 - ``​ タグで参照される複数のファイルでプロパティが定義されている場合、最初の定義が保持されます。 これらのファイルは、Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。または、絶対パスを使用することもできます。 ## [](#supported_files)サポートされているファイル 設定プロパティでは、YAML 設定ファイル (​`.yaml`​) とプロパティ設定ファイル (​`.properties`​) の両方がサポートされています。 両方のファイル形式でサポートされている型は ​`String`​ のみです。自分にとって読みやすく、編集しやすい形式を使用してください。 YAML ファイルの例: ```xml ``` `ports.yaml`​ を次に示します。 ```yaml smtp: port: "8957" http: port: "8081" ``` プロパティファイルの例: ```xml ``` `ports.properties`​ を次に示します。 ```xml smtp.port=8957 http.port=8081 ``` ## [](#ファイルプロパティ)ファイルプロパティ プレースホルダーの値は、ファイルのコンテンツ全体になることもあります。プレースホルダーの値は、次のような文字列値になります。 properties-file.txt Some content ```xml ``` ペイロードの値は ​`"Some content"`​ になります。他のプロパティファイルと同様に、これらのファイルは Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。絶対パスを使用することもできます。 この方法は、設定ファイルをモジュール化する場合に役立ちます。設定ファイル、SQL クエリ、変換から大きなコンテンツを抽出して設定ファイルを明確化し、そのコンテンツを再利用できます。 ## [](#システムプロパティ)システムプロパティ Mule をオンプレミスで実行するときに JDK システムプロパティを設定し、後でそのプロパティを使用して Mule アプリケーションでコンポーネントまたはモジュールを設定できます。プロパティを指定する方法は 2 つあります。 - Mule インスタンスを開始するときに、コマンドラインから指定します。 mule -M-Dsmtp.username=JSmith -M-Dsmtp.password=ChangeMe - `$MULE_HOME/conf`​ ディレクトリに配置されている ​`wrapper.conf`​ ファイルを編集し、プロパティごとにエントリを追加します。 wrapper.java.additional.999=-Dsmtp.username=JSmith wrapper.java.additional.1000=-Dsmtp.password=ChangeMe 設定についての詳細は、​[システムプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-app-properties-system#set-properties)​を参照してください。 ## [](#カスタムプロパティプロバイダー)カスタムプロパティプロバイダー Mule API を使用して、カスタムプロパティプロバイダーの実装を作成できます。詳細は、​[「カスタム設定プロパティプロバイダー」](https://docs.mulesoft.com/jp/mule-runtime/4.3/custom-configuration-properties-provider)​を参照してください。 ### [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Anypoint Studio でプロジェクトを起動するときに、\[Run Configurations (設定を実行)\] メニューでプロパティを追加できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. **\[VM arguments (VM 引数)\]**​ 項目に引数 (プロパティ名の前に ​**\-D**​) を追加します。 ![Arguments+Tab](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/arguments-tab.png) これで、アプリケーションをデプロイするたびに Studio でプロパティを使用できるようになりました。次の構文を使用してプロパティを参照できます。 ```xml ``` ## [](#環境変数)環境変数 環境変数はさまざまな方法で定義でき、アプリケーションから環境変数にアクセスする方法も複数あります。環境変数の定義方法に関係なく、次の構文を使用して参照することをお勧めします。 ${variableName} ### [](#os-の環境変数)OS の環境変数 OS で定義された変数を参照するには、次の構文を使用します。 ```xml ``` ### [](#anypoint-studio-で環境変数を設定する)Anypoint Studio で環境変数を設定する Studio の \[Run Configuration (設定を実行)\] メニューで変数を設定できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ を選択します。 3. \[Environment (環境)\] タブを選択します。 4. **\[New (新規)\]**​ ボタンをクリックし、変数に名前と値を割り当てます。 ![Environment+Tab](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/environment-tab.png) これで、デプロイするたびに Studio で変数を使用できるようになりました。次の構文を使用して変数を参照できます。 ```xml ```
OS で定義された変数を参照する構文と、Studio で定義された変数を参照する構文は同じです。Studio で定義された変数で、OS で定義された同じ名前の変数を置き換えるかどうかを、変数の作成時に UI の対応するラジオボタンをオンにして選択することができます。
![Environment+Tab2](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/environment-tab2.png) ## [](#プロパティファイルの動的な設定)プロパティファイルの動的な設定 一般的な設定のユースケースは、プロパティに連動するファイル (​`env`​ など) を設定して、使用するファイル (開発フェーズの ​`development-properties`​ ファイルや本番ファイルなど) を決定することです。 ```xml ``` そのため、​`env`​ プロパティの値によって、設定プロパティの読み込みに使用するファイルが決まります。その ​`env`​ プロパティは、グローバルプロパティ、システムプロパティ、または環境プロパティで設定できます。設定プロパティのデフォルト値を定義する方法として、グローバルプロパティを使用できます。グローバルプロパティと同じ名前のシステムおよび環境プロパティは、そのグローバルプロパティよりも優先されます。 ```xml ``` `env`​ プロパティのデフォルト値は ​`dev`​ になりますが、システムプロパティや環境プロパティで上書きできます。この設定は、Anypoint Studio でメタデータを解決するために​**必要**​になります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらの値に連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 他にも、設定プロパティのプレースホルダーは別の設定プロパティから読み込まれるプロパティに連動できないという点も考慮する必要があります。上記の例では、プロパティ ​`env`​ は設定プロパティで定義できていません。以下の例は、​**正しくありません**​。 ```xml ``` これには、他のプロパティ種別 (セキュア設定プロパティやカスタム設定プロパティなど) も含まれます。 ## [](#runtime-manager-でプロパティ値を設定する)Runtime Manager でプロパティ値を設定する アプリケーションを ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/)​ にデプロイする場合、Runtime Manager コンソールでプロパティを設定することもできます。これらは、​[CloudHub にデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)​するときや、​[すでに実行中のアプリケーション](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​で定義できます。 環境変数またはアプリケーションプロパティを作成する手順は、次のとおりです。 1. Anypoint Platform アカウントにログインします。 2. \[Runtime Manager\] をクリックします。 3. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックして新しいアプリケーションをデプロイするか、実行中のアプリケーションを選択して ​**\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ セクションで ​**\[Properties (プロパティ)\]**​ タブを選択します。 詳細は、​[「Managing Applications on CloudHub (CloudHub でのアプリケーションの管理)」](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​および​[「Secure Application Properties (セキュアなセキュリティプロパティ)」](https://docs.mulesoft.com/cloudhub/secure-application-properties)​を参照してください。 ## [](#properties-hierarchy)プロパティ階層 設定プロパティは上書き可能です。Mule Runtime Engine は、次の階層を使用して、同じ名前の場合に優先されるプロパティを決定します。この階層では、デプロイメントプロパティは上部にあるため、他のプロパティ種別よりも優先されます。 1. デプロイメントプロパティ 2. システムプロパティ 3. 環境プロパティ 4. アプリケーションプロパティ (設定プロパティ、セキュア設定プロパティ、および他のカスタム設定プロパティを含む) 5. グローバルプロパティ そのため、たとえば、​`size`​ という名前の設定プロパティがシステムプロパティとして定義されていて、​`size`​ という名前のアプリケーション設定プロパティもある場合、アプリケーションの値は、最も優先度の高いプロパティ (この場合はシステムプロパティ) の値になります。 プロパティの値は、階層の上位に位置する他のプロパティから派生させることができます。そのため、アプリケーションプロパティの値は、環境プロパティ、システムプロパティ、デプロイメントプロパティから派生させることができます。システムプロパティの値は、デプロイメントプロパティから派生させることができます (以下同様)。たとえば、​`env`​ という名前のシステムプロパティがある場合、アプリケーション設定プロパティの値を ​`file.${env}.xml`​ のように設定できます。 一方、アプリケーションプロパティは、同じファイルで定義されていないアプリケーションプロパティの値に連動することはできません。たとえば、セキュア設定プロパティは設定プロパティに連動できません。 この階層構造のため、ファイルを読み込む Mule コンポーネントはアプリケーションやグローバルプロパティに連動することはできません。Mule Runtime Engine は、コンポーネントとアプリケーションプロパティを同じ階層で読み込みます。たとえば、Mule がアプリケーションプロパティを読み込む前に ​`import`​ コンポーネントを読み込むと、​`import`​ コンポーネントの読み込みが必要になった時点でプロパティが解決されていないため、デプロイは失敗します。 # プロパティの設定 プロパティプレースホルダーやシステムプロパティなどのプロパティを設定できます。 ## [](#プロパティプレースホルダー)プロパティプレースホルダー Mule 設定では、 [Ant](http://ant.apache.org/)​ スタイルのプロパティプレースホルダーを使用できます。例: ```xml ``` 後続のセクションで説明されているように、これらのプレースホルダーの値は、さまざまな方法で使用可能にすることができます。 また、プロパティプレースホルダー値の解決をエスケープすることもできます。 ```xml ``` プロパティの値を返す代わりに、Logger コンポーネントは文字列 ​`"${property.value}"`​ を返します。エスケープ文字 ​`\`​ を使用して、プロパティのプレフィックス (​`${`​ 文字シーケンス) の解決をエスケープすることもできます。 ## [](#グローバルプロパティ)グローバルプロパティ ``​ 要素を使用すると、Mule 設定内 (別の Mule 設定ファイル内など) からプレースホルダーの値を設定できます。グローバルプロパティ構文を使用して、​`.yaml`​ または ​`.properties`​ ファイルの値を参照し、設定プロパティまたはセキュアな設定プロパティに連動する新しい (グローバル) プロパティを作成できます。設定プロパティを参照するには、プロパティファイルのセクションを読み取ります。 ```xml ``` ## [](#プロパティファイル)プロパティファイル カスタムファイルのプロパティを読み込むには、カスタムプロパティファイルを ​`src/main/resources`​ に配置し、​``​ タグを使用します。 ```xml ``` 複数のプロパティファイルを読み込むには、読み込むファイルごとに ​``​ タグを定義します。 - ``​ タグで参照される複数のファイルでプロパティが定義されている場合、最初の定義が保持されます。 これらのファイルは、Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。または、絶対パスを使用することもできます。 ## [](#supported_files)サポートされているファイル 設定プロパティでは、YAML 設定ファイル (​`.yaml`​) とプロパティ設定ファイル (​`.properties`​) の両方がサポートされています。 両方のファイル形式でサポートされている型は ​`String`​ のみです。自分にとって読みやすく、編集しやすい形式を使用してください。 YAML ファイルの例: ```xml ``` `ports.yaml`​ を次に示します。 ```yaml smtp: port: "8957" http: port: "8081" ``` プロパティファイルの例: ```xml ``` `ports.properties`​ を次に示します。 ```xml smtp.port=8957 http.port=8081 ``` ## [](#ファイルプロパティ)ファイルプロパティ プレースホルダーの値は、ファイルのコンテンツ全体になることもあります。プレースホルダーの値は、次のような文字列値になります。 properties-file.txt Some content ```xml ``` ペイロードの値は ​`"Some content"`​ になります。他のプロパティファイルと同様に、これらのファイルは Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。絶対パスを使用することもできます。 この方法は、設定ファイルをモジュール化する場合に役立ちます。設定ファイル、SQL クエリ、変換から大きなコンテンツを抽出して設定ファイルを明確化し、そのコンテンツを再利用できます。 ## [](#システムプロパティ)システムプロパティ Mule をオンプレミスで実行するときに JDK システムプロパティを設定し、後でそのプロパティを使用して Mule アプリケーションでコンポーネントまたはモジュールを設定できます。プロパティを指定する方法は 2 つあります。 - Mule インスタンスを開始するときに、コマンドラインから指定します。 mule -M-Dsmtp.username=JSmith -M-Dsmtp.password=ChangeMe - `$MULE_HOME/conf`​ ディレクトリに配置されている ​`wrapper.conf`​ ファイルを編集し、プロパティごとにエントリを追加します。 wrapper.java.additional.999=-Dsmtp.username=JSmith wrapper.java.additional.1000=-Dsmtp.password=ChangeMe 設定についての詳細は、​[システムプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-app-properties-system#set-properties)​を参照してください。 ## [](#カスタムプロパティプロバイダー)カスタムプロパティプロバイダー Mule API を使用して、カスタムプロパティプロバイダーの実装を作成できます。詳細は、​[「カスタム設定プロパティプロバイダー」](https://docs.mulesoft.com/jp/mule-runtime/4.4/custom-configuration-properties-provider)​を参照してください。 ### [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Anypoint Studio でプロジェクトを起動するときに、\[Run Configurations (設定を実行)\] メニューでプロパティを追加できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. **\[VM arguments (VM 引数)\]**​ 項目に引数 (プロパティ名の前に ​**\-D**​) を追加します。 ![Arguments+Tab](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/arguments-tab.png) これで、アプリケーションをデプロイするたびに Studio でプロパティを使用できるようになりました。次の構文を使用してプロパティを参照できます。 ```xml ``` ## [](#環境変数)環境変数 環境変数はさまざまな方法で定義でき、アプリケーションから環境変数にアクセスする方法も複数あります。環境変数の定義方法に関係なく、次の構文を使用して参照することをお勧めします。 ${variableName} ### [](#os-の環境変数)OS の環境変数 OS で定義された変数を参照するには、次の構文を使用します。 ```xml ``` ### [](#anypoint-studio-で環境変数を設定する)Anypoint Studio で環境変数を設定する Studio の \[Run Configuration (設定を実行)\] メニューで変数を設定できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ を選択します。 3. \[Environment (環境)\] タブを選択します。 4. **\[New (新規)\]**​ ボタンをクリックし、変数に名前と値を割り当てます。 ![Environment+Tab](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/environment-tab.png) これで、デプロイするたびに Studio で変数を使用できるようになりました。次の構文を使用して変数を参照できます。 ```xml ```
OS で定義された変数を参照する構文と、Studio で定義された変数を参照する構文は同じです。Studio で定義された変数で、OS で定義された同じ名前の変数を置き換えるかどうかを、変数の作成時に UI の対応するラジオボタンをオンにして選択することができます。
![Environment+Tab2](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/environment-tab2.png) ## [](#プロパティファイルの動的な設定)プロパティファイルの動的な設定 一般的な設定のユースケースは、プロパティに連動するファイル (​`env`​ など) を設定して、使用するファイル (開発フェーズの ​`development-properties`​ ファイルや本番ファイルなど) を決定することです。 ```xml ``` そのため、​`env`​ プロパティの値によって、設定プロパティの読み込みに使用するファイルが決まります。その ​`env`​ プロパティは、グローバルプロパティ、システムプロパティ、または環境プロパティで設定できます。設定プロパティのデフォルト値を定義する方法として、グローバルプロパティを使用できます。グローバルプロパティと同じ名前のシステムおよび環境プロパティは、そのグローバルプロパティよりも優先されます。 ```xml ``` `env`​ プロパティのデフォルト値は ​`dev`​ になりますが、システムプロパティや環境プロパティで上書きできます。この設定は、Anypoint Studio でメタデータを解決するために​**必要**​になります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらの値に連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 他にも、設定プロパティのプレースホルダーは別の設定プロパティから読み込まれるプロパティに連動できないという点も考慮する必要があります。上記の例では、プロパティ ​`env`​ は設定プロパティで定義できていません。以下の例は、​**正しくありません**​。 ```xml ``` これには、他のプロパティ種別 (セキュア設定プロパティやカスタム設定プロパティなど) も含まれます。 ## [](#runtime-manager-でプロパティ値を設定する)Runtime Manager でプロパティ値を設定する アプリケーションを ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/)​ にデプロイする場合、Runtime Manager コンソールでプロパティを設定することもできます。これらは、​[CloudHub にデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)​するときや、​[すでに実行中のアプリケーション](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​で定義できます。 環境変数またはアプリケーションプロパティを作成する手順は、次のとおりです。 1. Anypoint Platform アカウントにログインします。 2. \[Runtime Manager\] をクリックします。 3. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックして新しいアプリケーションをデプロイするか、実行中のアプリケーションを選択して ​**\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ セクションで ​**\[Properties (プロパティ)\]**​ タブを選択します。 詳細は、​[「Managing Applications on CloudHub (CloudHub でのアプリケーションの管理)」](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​および​[「Secure Application Properties (セキュアなセキュリティプロパティ)」](https://docs.mulesoft.com/cloudhub/secure-application-properties)​を参照してください。 ## [](#properties-hierarchy)プロパティ階層 設定プロパティは上書き可能です。Mule Runtime Engine は、次の階層を使用して、同じ名前の場合に優先されるプロパティを決定します。この階層では、デプロイメントプロパティは上部にあるため、他のプロパティ種別よりも優先されます。 1. デプロイメントプロパティ 2. システムプロパティ 3. 環境プロパティ 4. アプリケーションプロパティ (設定プロパティ、セキュア設定プロパティ、および他のカスタム設定プロパティを含む) 5. グローバルプロパティ そのため、たとえば、​`size`​ という名前の設定プロパティがシステムプロパティとして定義されていて、​`size`​ という名前のアプリケーション設定プロパティもある場合、アプリケーションの値は、最も優先度の高いプロパティ (この場合はシステムプロパティ) の値になります。 プロパティの値は、階層の上位に位置する他のプロパティから派生させることができます。そのため、アプリケーションプロパティの値は、環境プロパティ、システムプロパティ、デプロイメントプロパティから派生させることができます。システムプロパティの値は、デプロイメントプロパティから派生させることができます (以下同様)。たとえば、​`env`​ という名前のシステムプロパティがある場合、アプリケーション設定プロパティの値を ​`file.${env}.xml`​ のように設定できます。ただし、アプリケーションプロパティは、同じファイルで定義されていないアプリケーションプロパティの値に連動することはできません。たとえば、セキュア設定プロパティは設定プロパティに連動できません。 この階層構造のため、ファイルを読み込む Mule コンポーネントはアプリケーションやグローバルプロパティに連動することはできません。Mule Runtime Engine は、コンポーネントとアプリケーションプロパティを同じ階層で読み込みます。たとえば、Mule がアプリケーションプロパティを読み込む前に ​`import`​ コンポーネントを読み込むと、​`import`​ コンポーネントの読み込みが必要になった時点でプロパティが解決されていないため、デプロイは失敗します。 ## [](#組み込みプロパティ)組み込みプロパティ Mule Runtime Engine は内部のアプリケーションプロパティを定義し、Mule インスタンスとデプロイされたアプリケーションの設定に基づいて値を割り当てます。
プロパティ 説明

app.home

Mule アプリケーションの ​/home​ ディレクトリへのパス

app.name

Mule アプリケーションの名前

domain.name

ドメインの名前

api.name

API の名前

mule.home

Mule インスタンスの ​/home​ ディレクトリへのパス
これらのプロパティは一切上書きしないでください。Mule ではこれらの値のいくつかを内部的に使用しており、上書きすると予期しない動作が発生するおそれがあります。 # プロパティの設定 プロパティプレースホルダーやシステムプロパティなどのプロパティを設定できます。 ## [](#プロパティプレースホルダー)プロパティプレースホルダー Mule 設定では、 [Ant](http://ant.apache.org/)​ スタイルのプロパティプレースホルダーを使用できます。次に例を示します。 ```xml ``` 後続のセクションで説明されているように、これらのプレースホルダーの値は、さまざまな方法で使用可能にすることができます。 また、プロパティプレースホルダー値の解決をエスケープすることもできます。 ```xml ``` プロパティの値を返す代わりに、Logger コンポーネントは文字列 ​`"${property.value}"`​ を返します。エスケープ文字 ​`\`​ を使用して、プロパティのプレフィックス (​`${`​ 文字シーケンス) の解決をエスケープすることもできます。 ## [](#グローバルプロパティ)グローバルプロパティ ``​ 要素を使用すると、Mule 設定内 (別の Mule 設定ファイル内など) からプレースホルダーの値を設定できます。グローバルプロパティ構文を使用して、​`.yaml`​ または ​`.properties`​ ファイルの値を参照し、設定プロパティまたはセキュアな設定プロパティに連動する新しい (グローバル) プロパティを作成できます。設定プロパティを参照するには、プロパティファイルのセクションを読み取ります。 ```xml ``` ## [](#プロパティファイル)プロパティファイル カスタムファイルのプロパティを読み込むには、カスタムプロパティファイルを ​`src/main/resources`​ に配置し、​``​ タグを使用します。 ```xml ``` 複数のプロパティファイルを読み込むには、読み込むファイルごとに ​``​ タグを定義します。 - ``​ タグで参照される複数のファイルでプロパティが定義されている場合、最初の定義が保持されます。 これらのファイルは、Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。または、絶対パスを使用することもできます。 ## [](#supported_files)サポートされているファイル 設定プロパティでは、YAML 設定ファイル (​`.yaml`​) とプロパティ設定ファイル (​`.properties`​) の両方がサポートされています。 両方のファイル形式でサポートされている型は ​`String`​ のみです。自分にとって読みやすく、編集しやすい形式を使用してください。 YAML ファイルの例: ```xml ``` `ports.yaml`​ を次に示します。 ```yaml smtp: port: "8957" http: port: "8081" ``` プロパティファイルの例: ```xml ``` `ports.properties`​ を次に示します。 ```xml smtp.port=8957 http.port=8081 ``` ## [](#ファイルプロパティ)ファイルプロパティ プレースホルダーの値は、ファイルの内容全体になることもあります。プレースホルダーの値は、次のような文字列値になります。 properties-file.txt Some content ```xml ``` ペイロードの値は ​`"Some content"`​ になります。他のプロパティファイルと同様に、これらのファイルは Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。絶対パスを使用することもできます。 この方法は、設定ファイルをモジュール化する場合に役立ちます。設定ファイル、SQL クエリ、変換から大きなコンテンツを抽出して設定ファイルを明確化し、そのコンテンツを再利用できます。 ## [](#システムプロパティ)システムプロパティ Mule をオンプレミスで実行するときに JDK システムプロパティを設定し、後でそのプロパティを使用して Mule アプリケーションでコンポーネントまたはモジュールを設定できます。プロパティを指定する方法は 2 つあります。 - Mule インスタンスを開始するときに、コマンドラインから指定します。 mule -M-Dsmtp.username=JSmith -M-Dsmtp.password=ChangeMe - `$MULE_HOME/conf`​ ディレクトリに配置されている ​`wrapper.conf`​ ファイルを編集し、プロパティごとにエントリを追加します。 wrapper.java.additional.999=-Dsmtp.username=JSmith wrapper.java.additional.1000=-Dsmtp.password=ChangeMe 設定についての詳細は、​[システムプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-app-properties-system#set-properties)​を参照してください。 ## [](#カスタムプロパティプロバイダー)カスタムプロパティプロバイダー Mule API を使用して、カスタムプロパティプロバイダーの実装を作成できます。詳細は、​[「カスタム設定プロパティプロバイダー」](https://docs.mulesoft.com/jp/mule-runtime/4.5/custom-configuration-properties-provider)​を参照してください。 ### [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Anypoint Studio でプロジェクトを起動するときに、\[Run Configurations (設定を実行)\] メニューでプロパティを追加できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. **\[VM arguments (VM 引数)\]**​ 項目に引数 (プロパティ名の前に ​**\-D**​) を追加します。 ![Arguments+Tab](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/arguments-tab.png) これで、アプリケーションをデプロイするたびに Studio でプロパティを使用できるようになりました。次の構文を使用してプロパティを参照できます。 ```xml ``` ## [](#環境変数)環境変数 環境変数はさまざまな方法で定義でき、アプリケーションから環境変数にアクセスする方法も複数あります。環境変数の定義方法に関係なく、次の構文を使用して参照することをお勧めします。 ${variableName} ### [](#os-の環境変数)OS の環境変数 OS で定義された変数を参照するには、次の構文を使用します。 ```xml ``` ### [](#anypoint-studio-で環境変数を設定する)Anypoint Studio で環境変数を設定する Studio の \[Run Configuration (設定を実行)\] メニューで変数を設定できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ を選択します。 3. \[Environment (環境)\] タブを選択します。 4. **\[New (新規)\]**​ ボタンをクリックし、変数に名前と値を割り当てます。 ![Environment+Tab](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/environment-tab.png) これで、デプロイするたびに Studio で変数を使用できるようになりました。次の構文を使用して変数を参照できます。 ```xml ```
OS で定義された変数を参照する構文と、Studio で定義された変数を参照する構文は同じです。Studio で定義された変数で、OS で定義された同じ名前の変数を置き換えるかどうかを、変数の作成時に UI の対応するラジオボタンをオンにして選択することができます。
![Environment+Tab2](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/environment-tab2.png) ## [](#プロパティファイルの動的な設定)プロパティファイルの動的な設定 一般的な設定のユースケースは、プロパティに連動するファイル (​`env`​ など) を設定して、使用するファイル (開発フェーズの ​`development-properties`​ ファイルや本番ファイルなど) を決定することです。 ```xml ``` そのため、​`env`​ プロパティの値によって、設定プロパティの読み込みに使用するファイルが決まります。その ​`env`​ プロパティは、グローバルプロパティ、システムプロパティ、または環境プロパティで設定できます。設定プロパティのデフォルト値を定義する方法として、グローバルプロパティを使用できます。グローバルプロパティと同じ名前のシステムおよび環境プロパティは、そのグローバルプロパティよりも優先されます。 ```xml ``` `env`​ プロパティのデフォルト値は ​`dev`​ になりますが、システムプロパティや環境プロパティで上書きできます。この設定は、Anypoint Studio でメタデータを解決するために​**必要**​になります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらの値に連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 他にも、設定プロパティのプレースホルダーは別の設定プロパティから読み込まれるプロパティに連動できないという点も考慮する必要があります。上記の例では、プロパティ ​`env`​ は設定プロパティで定義できていません。以下の例は、​**正しくありません**​。 ```xml ``` これには、他のプロパティ種別 (セキュア設定プロパティやカスタム設定プロパティなど) も含まれます。 ## [](#runtime-manager-でプロパティ値を設定する)Runtime Manager でプロパティ値を設定する アプリケーションを ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/)​ にデプロイする場合、Runtime Manager コンソールでプロパティを設定することもできます。これらは、​[CloudHub にデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)​するときや、​[すでに実行中のアプリケーション](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​で定義できます。 環境変数またはアプリケーションプロパティを作成する手順は、次のとおりです。 1. Anypoint Platform アカウントにログインします。 2. \[Runtime Manager\] をクリックします。 3. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックして新しいアプリケーションをデプロイするか、実行中のアプリケーションを選択して ​**\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ セクションで ​**\[Properties (プロパティ)\]**​ タブを選択します。 詳細は、​[「Managing Applications on CloudHub (CloudHub でのアプリケーションの管理)」](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​および​[「Secure Application Properties (セキュアなセキュリティプロパティ)」](https://docs.mulesoft.com/cloudhub/secure-application-properties)​を参照してください。 ## [](#properties-hierarchy)プロパティ階層 設定プロパティは上書き可能です。Mule Runtime Engine は、次の階層を使用して、同じ名前の場合に優先されるプロパティを決定します。この階層では、デプロイメントプロパティは上部にあるため、他のプロパティ種別よりも優先されます。 1. デプロイメントプロパティ 2. システムプロパティ 3. 環境プロパティ 4. アプリケーションプロパティ (設定プロパティ、セキュア設定プロパティ、および他のカスタム設定プロパティを含む) 5. グローバルプロパティ そのため、たとえば、​`size`​ という名前の設定プロパティがシステムプロパティとして定義されていて、​`size`​ という名前のアプリケーション設定プロパティもある場合、アプリケーションの値は、最も優先度の高いプロパティ (この場合はシステムプロパティ) の値になります。 プロパティの値は、階層の上位に位置する他のプロパティから派生させることができます。そのため、アプリケーションプロパティの値は、環境プロパティ、システムプロパティ、デプロイメントプロパティから派生させることができます。システムプロパティの値は、デプロイメントプロパティから派生させることができます (以下同様)。たとえば、​`env`​ という名前のシステムプロパティがある場合、アプリケーション設定プロパティの値を ​`file.${env}.xml`​ のように設定できます。ただし、アプリケーションプロパティは、同じファイルで定義されていないアプリケーションプロパティの値に連動することはできません。たとえば、セキュア設定プロパティは設定プロパティに連動できません。 この階層構造のため、ファイルを読み込む Mule コンポーネントはアプリケーションやグローバルプロパティに連動することはできません。Mule Runtime Engine は、コンポーネントとアプリケーションプロパティを同じ階層で読み込みます。たとえば、Mule がアプリケーションプロパティを読み込む前に ​`import`​ コンポーネントを読み込むと、​`import`​ コンポーネントの読み込みが必要になった時点でプロパティが解決されていないため、デプロイは失敗します。 ## [](#組み込みプロパティ)組み込みプロパティ Mule Runtime Engine は内部のアプリケーションプロパティを定義し、Mule インスタンスとデプロイされたアプリケーションの設定に基づいて値を割り当てます。
プロパティ 説明

app.home

Mule アプリケーションの ​/home​ ディレクトリへのパス

app.name

Mule アプリケーションの名前

domain.name

ドメインの名前

api.name

API の名前

mule.home

Mule インスタンスの ​/home​ ディレクトリへのパス
これらのプロパティは一切上書きしないでください。Mule ではこれらの値のいくつかを内部的に使用しており、上書きすると予期しない動作が発生するおそれがあります。 # プロパティの設定 プロパティプレースホルダーやシステムプロパティなどのプロパティを設定できます。 ## [](#プロパティプレースホルダー)プロパティプレースホルダー Mule 設定では、 [Ant](http://ant.apache.org/)​ スタイルのプロパティプレースホルダーを使用できます。例: ```xml ``` 後続のセクションで説明されているように、これらのプレースホルダーの値は、さまざまな方法で使用可能にすることができます。 また、プロパティプレースホルダー値の解決をエスケープすることもできます。 ```xml ``` プロパティの値を返す代わりに、Logger コンポーネントは文字列 ​`"${property.value}"`​ を返します。エスケープ文字 ​`\`​ を使用して、プロパティのプレフィックス (​`${`​ 文字シーケンス) の解決をエスケープすることもできます。 ## [](#グローバルプロパティ)グローバルプロパティ ``​ 要素を使用すると、Mule 設定内 (別の Mule 設定ファイル内など) からプレースホルダーの値を設定できます。グローバルプロパティ構文を使用して、​`.yaml`​ または ​`.properties`​ ファイルの値を参照し、設定プロパティまたはセキュアな設定プロパティに連動する新しい (グローバル) プロパティを作成できます。設定プロパティを参照するには、プロパティファイルのセクションを読み取ります。 ```xml ``` ## [](#プロパティファイル)プロパティファイル カスタムファイルのプロパティを読み込むには、カスタムプロパティファイルを ​`src/main/resources`​ に配置し、​``​ タグを使用します。 ```xml ``` 複数のプロパティファイルを読み込むには、読み込むファイルごとに ​``​ タグを定義します。 - ``​ タグで参照される複数のファイルでプロパティが定義されている場合、最初の定義が保持されます。 これらのファイルは、Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。または、絶対パスを使用することもできます。 ## [](#supported_files)サポートされているファイル 設定プロパティでは、YAML 設定ファイル (​`.yaml`​) とプロパティ設定ファイル (​`.properties`​) の両方がサポートされています。 両方のファイル形式でサポートされている型は ​`String`​ のみです。自分にとって読みやすく、編集しやすい形式を使用してください。 YAML ファイルの例: ```xml ``` `ports.yaml`​ を次に示します。 ```yaml smtp: port: "8957" http: port: "8081" ``` プロパティファイルの例: ```xml ``` `ports.properties`​ を次に示します。 ```xml smtp.port=8957 http.port=8081 ``` ## [](#file-properties)File Properties プレースホルダーの値は、ファイルのコンテンツ全体になることもあります。プレースホルダーの値は、次のような文字列値になります。 properties-file.txt Some content ```xml ``` ペイロードの値は ​`"Some content"`​ になります。他のプロパティファイルと同様に、これらのファイルは Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。絶対パスを使用することもできます。 この方法は、設定ファイルをモジュール化する場合に役立ちます。設定ファイル、SQL クエリ、変換から大きなコンテンツを抽出して設定ファイルを明確化し、そのコンテンツを再利用できます。 ## [](#システムプロパティ)システムプロパティ Mule をオンプレミスで実行するときに JDK システムプロパティを設定し、後でそのプロパティを使用して Mule アプリケーションでコンポーネントまたはモジュールを設定できます。プロパティを指定する方法は 2 つあります。 - Mule インスタンスを開始するときに、コマンドラインから指定します。 mule -M-Dsmtp.username=JSmith -M-Dsmtp.password=ChangeMe - `$MULE_HOME/conf`​ ディレクトリに配置されている ​`wrapper.conf`​ ファイルを編集し、プロパティごとにエントリを追加します。 wrapper.java.additional.999=-Dsmtp.username=JSmith wrapper.java.additional.1000=-Dsmtp.password=ChangeMe 設定についての詳細は、​[システムプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-app-properties-system#set-properties)​を参照してください。 ## [](#カスタムプロパティプロバイダー)カスタムプロパティプロバイダー Mule API を使用して、カスタムプロパティプロバイダーの実装を作成できます。詳細は、​[「カスタム設定プロパティプロバイダー」](https://docs.mulesoft.com/jp/mule-runtime/4.6/custom-configuration-properties-provider)​を参照してください。 ### [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Anypoint Studio でプロジェクトを起動するときに、\[Run Configurations (設定を実行)\] メニューでプロパティを追加できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. **\[VM arguments (VM 引数)\]**​ 項目に引数 (プロパティ名の前に ​**\-D**​) を追加します。 ![Arguments+Tab](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/arguments-tab.png) これで、アプリケーションをデプロイするたびに Studio でプロパティを使用できるようになりました。次の構文を使用してプロパティを参照できます。 ```xml ``` ## [](#環境変数)環境変数 環境変数はさまざまな方法で定義でき、アプリケーションから環境変数にアクセスする方法も複数あります。環境変数の定義方法に関係なく、次の構文を使用して参照することをお勧めします。 ${variableName} ### [](#os-の環境変数)OS の環境変数 OS で定義された変数を参照するには、次の構文を使用します。 ```xml ``` ### [](#anypoint-studio-で環境変数を設定する)Anypoint Studio で環境変数を設定する Studio の \[Run Configuration (設定を実行)\] メニューで変数を設定できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ を選択します。 3. \[Environment (環境)\] タブを選択します。 4. **\[New (新規)\]**​ ボタンをクリックし、変数に名前と値を割り当てます。 ![Environment+Tab](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/environment-tab.png) これで、デプロイするたびに Studio で変数を使用できるようになりました。次の構文を使用して変数を参照できます。 ```xml ```
OS で定義された変数を参照する構文と、Studio で定義された変数を参照する構文は同じです。Studio で定義された変数で、OS で定義された同じ名前の変数を置き換えるかどうかを、変数の作成時に UI の対応するラジオボタンをオンにして選択することができます。
![Environment+Tab2](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/environment-tab2.png) ## [](#プロパティファイルの動的な設定)プロパティファイルの動的な設定 一般的な設定のユースケースは、プロパティに連動するファイル (​`env`​ など) を設定して、使用するファイル (開発フェーズの ​`development-properties`​ ファイルや本番ファイルなど) を決定することです。 ```xml ``` そのため、​`env`​ プロパティの値によって、設定プロパティの読み込みに使用するファイルが決まります。その ​`env`​ プロパティは、グローバルプロパティ、システムプロパティ、または環境プロパティで設定できます。設定プロパティのデフォルト値を定義する方法として、グローバルプロパティを使用できます。グローバルプロパティと同じ名前のシステムおよび環境プロパティは、そのグローバルプロパティよりも優先されます。 ```xml ``` `env`​ プロパティのデフォルト値は ​`dev`​ になりますが、システムプロパティや環境プロパティで上書きできます。この設定は、Anypoint Studio でメタデータを解決するために​**必要**​になります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらの値に連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 他にも、設定プロパティのプレースホルダーは別の設定プロパティから読み込まれるプロパティに連動できないという点も考慮する必要があります。上記の例では、プロパティ ​`env`​ は設定プロパティで定義できていません。以下の例は、​**正しくありません**​。 ```xml ``` これには、他のプロパティ種別 (セキュア設定プロパティやカスタム設定プロパティなど) も含まれます。 ## [](#runtime-manager-でプロパティ値を設定する)Runtime Manager でプロパティ値を設定する アプリケーションを ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/)​ にデプロイする場合、Runtime Manager コンソールでプロパティを設定することもできます。これらは、​[CloudHub にデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)​するときや、​[すでに実行中のアプリケーション](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​で定義できます。 環境変数またはアプリケーションプロパティを作成する手順は、次のとおりです。 1. Anypoint Platform アカウントにログインします。 2. \[Runtime Manager\] をクリックします。 3. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックして新しいアプリケーションをデプロイするか、実行中のアプリケーションを選択して ​**\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ セクションで ​**\[Properties (プロパティ)\]**​ タブを選択します。 詳細は、​[「Managing Applications on CloudHub (CloudHub でのアプリケーションの管理)」](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​および​[「Secure Application Properties (セキュアなセキュリティプロパティ)」](https://docs.mulesoft.com/cloudhub/secure-application-properties)​を参照してください。 ## [](#properties-hierarchy)プロパティ階層 設定プロパティは上書き可能です。Mule Runtime Engine は、次の階層を使用して、同じ名前の場合に優先されるプロパティを決定します。この階層では、デプロイメントプロパティは上部にあるため、他のプロパティ種別よりも優先されます。 1. デプロイメントプロパティ 2. システムプロパティ 3. 環境プロパティ 4. アプリケーションプロパティ (設定プロパティ、セキュア設定プロパティ、および他のカスタム設定プロパティを含む) 5. グローバルプロパティ そのため、たとえば、​`size`​ という名前の設定プロパティがシステムプロパティとして定義されていて、​`size`​ という名前のアプリケーション設定プロパティもある場合、アプリケーションの値は、最も優先度の高いプロパティ (この場合はシステムプロパティ) の値になります。 プロパティの値は、階層の上位に位置する他のプロパティから派生させることができます。そのため、アプリケーションプロパティの値は、環境プロパティ、システムプロパティ、デプロイメントプロパティから派生させることができます。システムプロパティの値は、デプロイメントプロパティから派生させることができます (以下同様)。たとえば、​`env`​ という名前のシステムプロパティがある場合、アプリケーション設定プロパティの値を ​`file.${env}.xml`​ のように設定できます。ただし、アプリケーションプロパティは、同じファイルで定義されていないアプリケーションプロパティの値に連動することはできません。たとえば、セキュア設定プロパティは設定プロパティに連動できません。 この階層構造のため、ファイルを読み込む Mule コンポーネントはアプリケーションやグローバルプロパティに連動することはできません。Mule Runtime Engine は、コンポーネントとアプリケーションプロパティを同じ階層で読み込みます。たとえば、Mule がアプリケーションプロパティを読み込む前に ​`import`​ コンポーネントを読み込むと、​`import`​ コンポーネントの読み込みが必要になった時点でプロパティが解決されていないため、デプロイは失敗します。 ## [](#組み込みプロパティ)組み込みプロパティ Mule Runtime Engine は内部のアプリケーションプロパティを定義し、Mule インスタンスとデプロイされたアプリケーションの設定に基づいて値を割り当てます。
プロパティ 説明

app.home

Mule アプリケーションの ​/home​ ディレクトリへのパス

app.name

Mule アプリケーションの名前

domain.name

ドメインの名前

api.name

API の名前

mule.home

Mule インスタンスの ​/home​ ディレクトリへのパス
これらのプロパティは一切上書きしないでください。Mule ではこれらの値のいくつかを内部的に使用しており、上書きすると予期しない動作が発生するおそれがあります。 # プロパティの設定 プロパティプレースホルダーやシステムプロパティなどのプロパティを設定できます。 ## [](#プロパティプレースホルダー)プロパティプレースホルダー Mule 設定では、 [Ant](http://ant.apache.org/)​ スタイルのプロパティプレースホルダーを使用できます。例: ```xml ``` 後続のセクションで説明されているように、これらのプレースホルダーの値は、さまざまな方法で使用可能にすることができます。 また、プロパティプレースホルダー値の解決をエスケープすることもできます。 ```xml ``` プロパティの値を返す代わりに、Logger コンポーネントは文字列 ​`"${property.value}"`​ を返します。エスケープ文字 ​`\`​ を使用して、プロパティのプレフィックス (​`${`​ 文字シーケンス) の解決をエスケープすることもできます。 ## [](#グローバルプロパティ)グローバルプロパティ ``​ 要素を使用すると、Mule 設定内 (別の Mule 設定ファイル内など) からプレースホルダーの値を設定できます。グローバルプロパティ構文を使用して、​`.yaml`​ または ​`.properties`​ ファイルの値を参照し、設定プロパティまたはセキュアな設定プロパティに連動する新しい (グローバル) プロパティを作成できます。設定プロパティを参照するには、プロパティファイルのセクションを読み取ります。 ```xml ``` ## [](#プロパティファイル)プロパティファイル カスタムファイルのプロパティを読み込むには、カスタムプロパティファイルを ​`src/main/resources`​ に配置し、​``​ タグを使用します。 ```xml ``` 複数のプロパティファイルを読み込むには、読み込むファイルごとに ​``​ タグを定義します。 - ``​ タグで参照される複数のファイルでプロパティが定義されている場合、最初の定義が保持されます。 これらのファイルは、Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。または、絶対パスを使用することもできます。 ## [](#supported_files)サポートされているファイル 設定プロパティでは、YAML 設定ファイル (​`.yaml`​) とプロパティ設定ファイル (​`.properties`​) の両方がサポートされています。 両方のファイル形式でサポートされている型は ​`String`​ のみです。自分にとって読みやすく、編集しやすい形式を使用してください。 YAML ファイルの例: ```xml ``` `ports.yaml`​ を次に示します。 ```yaml smtp: port: "8957" http: port: "8081" ``` プロパティファイルの例: ```xml ``` `ports.properties`​ を次に示します。 ```xml smtp.port=8957 http.port=8081 ``` ## [](#ファイルプロパティ)ファイルプロパティ プレースホルダーの値は、ファイルのコンテンツ全体になることもあります。プレースホルダーの値は、次のような文字列値になります。 properties-file.txt Some content ```xml ``` ペイロードの値は ​`"Some content"`​ になります。他のプロパティファイルと同様に、これらのファイルは Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。絶対パスを使用することもできます。 この方法は、設定ファイルをモジュール化する場合に役立ちます。設定ファイル、SQL クエリ、変換から大きなコンテンツを抽出して設定ファイルを明確化し、そのコンテンツを再利用できます。 ## [](#システムプロパティ)システムプロパティ Mule をオンプレミスで実行するときに JDK システムプロパティを設定し、後でそのプロパティを使用して Mule アプリケーションでコンポーネントまたはモジュールを設定できます。プロパティを指定する方法は 2 つあります。 - Mule インスタンスを開始するときに、コマンドラインから指定します。 mule -M-Dsmtp.username=JSmith -M-Dsmtp.password=ChangeMe - `$MULE_HOME/conf`​ ディレクトリに配置されている ​`wrapper.conf`​ ファイルを編集し、プロパティごとにエントリを追加します。 wrapper.java.additional.999=-Dsmtp.username=JSmith wrapper.java.additional.1000=-Dsmtp.password=ChangeMe 設定についての詳細は、​[システムプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-app-properties-system#set-properties)​を参照してください。 ## [](#カスタムプロパティプロバイダー)カスタムプロパティプロバイダー Mule API を使用して、カスタムプロパティプロバイダーの実装を作成できます。詳細は、​[「カスタム設定プロパティプロバイダー」](https://docs.mulesoft.com/jp/mule-runtime/4.7/custom-configuration-properties-provider)​を参照してください。 ### [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Anypoint Studio でプロジェクトを起動するときに、\[Run Configurations (設定を実行)\] メニューでプロパティを追加できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. **\[VM arguments (VM 引数)\]**​ 項目に引数 (プロパティ名の前に ​**\-D**​) を追加します。 ![Anypoint Studio の JVM 引数の設定が表示されている \[Arguments (引数)\] タブ](_images/arguments-tab.png) これで、アプリケーションをデプロイするたびに Studio でプロパティを使用できるようになりました。次の構文を使用してプロパティを参照できます。 ```xml ``` ## [](#環境変数)環境変数 環境変数はさまざまな方法で定義でき、アプリケーションから環境変数にアクセスする方法も複数あります。環境変数の定義方法に関係なく、次の構文を使用して参照することをお勧めします。 ${variableName} ### [](#os-の環境変数)OS の環境変数 OS で定義された変数を参照するには、次の構文を使用します。 ```xml ``` ### [](#anypoint-studio-で環境変数を設定する)Anypoint Studio で環境変数を設定する Studio の \[Run Configuration (設定を実行)\] メニューで変数を設定できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ を選択します。 3. \[Environment (環境)\] タブを選択します。 4. **\[New (新規)\]**​ ボタンをクリックし、変数に名前と値を割り当てます。 ![\[Newf (新規)\] などのオプションが含まれる \[Environment (環境)\] タブ](_images/environment-tab.png) これで、デプロイするたびに Studio で変数を使用できるようになりました。次の構文を使用して変数を参照できます。 ```xml ```
OS で定義された変数を参照する構文と、Studio で定義された変数を参照する構文は同じです。Studio で定義された変数で、OS で定義された同じ名前の変数を置き換えるかどうかを、変数の作成時に UI の対応するラジオボタンをオンにして選択することができます。
![変数を定義するオプションが含まれる \[Environment (環境)\] タブ](_images/environment-tab2.png) ## [](#プロパティファイルの動的な設定)プロパティファイルの動的な設定 一般的な設定のユースケースは、プロパティに連動するファイル (​`env`​ など) を設定して、使用するファイル (開発フェーズの ​`development-properties`​ ファイルや本番ファイルなど) を決定することです。 ```xml ``` そのため、​`env`​ プロパティの値によって、設定プロパティの読み込みに使用するファイルが決まります。その ​`env`​ プロパティは、グローバルプロパティ、システムプロパティ、または環境プロパティで設定できます。設定プロパティのデフォルト値を定義する方法として、グローバルプロパティを使用できます。グローバルプロパティと同じ名前のシステムおよび環境プロパティは、そのグローバルプロパティよりも優先されます。 ```xml ``` `env`​ プロパティのデフォルト値は ​`dev`​ になりますが、システムプロパティや環境プロパティで上書きできます。この設定は、Anypoint Studio でメタデータを解決するために​**必要**​になります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらの値に連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 他にも、設定プロパティのプレースホルダーは別の設定プロパティから読み込まれるプロパティに連動できないという点も考慮する必要があります。上記の例では、プロパティ ​`env`​ は設定プロパティで定義できていません。以下の例は、​**正しくありません**​。 ```xml ``` これには、他のプロパティ種別 (セキュア設定プロパティやカスタム設定プロパティなど) も含まれます。 ## [](#runtime-manager-でプロパティ値を設定する)Runtime Manager でプロパティ値を設定する アプリケーションを ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/)​ にデプロイする場合、Runtime Manager コンソールでプロパティを設定することもできます。これらは、​[CloudHub にデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)​するときや、​[すでに実行中のアプリケーション](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​で定義できます。 環境変数またはアプリケーションプロパティを作成する手順は、次のとおりです。 1. Anypoint Platform アカウントにログインします。 2. \[Runtime Manager\] をクリックします。 3. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックして新しいアプリケーションをデプロイするか、実行中のアプリケーションを選択して ​**\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ セクションで ​**\[Properties (プロパティ)\]**​ タブを選択します。 詳細は、​[「Managing Applications on CloudHub (CloudHub でのアプリケーションの管理)」](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​および​[「Secure Application Properties (セキュアなセキュリティプロパティ)」](https://docs.mulesoft.com/cloudhub/secure-application-properties)​を参照してください。 ## [](#properties-hierarchy)プロパティ階層 設定プロパティは上書き可能です。Mule Runtime Engine は、次の階層を使用して、同じ名前の場合に優先されるプロパティを決定します。この階層では、デプロイメントプロパティは上部にあるため、他のプロパティ種別よりも優先されます。 1. デプロイメントプロパティ 2. システムプロパティ 3. 環境プロパティ 4. アプリケーションプロパティ (設定プロパティ、セキュア設定プロパティ、および他のカスタム設定プロパティを含む) 5. グローバルプロパティ そのため、たとえば、​`size`​ という名前の設定プロパティがシステムプロパティとして定義されていて、​`size`​ という名前のアプリケーション設定プロパティもある場合、アプリケーションの値は、最も優先度の高いプロパティ (この場合はシステムプロパティ) の値になります。 プロパティの値は、階層の上位に位置する他のプロパティから派生させることができます。そのため、アプリケーションプロパティの値は、環境プロパティ、システムプロパティ、デプロイメントプロパティから派生させることができます。システムプロパティの値は、デプロイメントプロパティから派生させることができます (以下同様)。たとえば、​`env`​ という名前のシステムプロパティがある場合、アプリケーション設定プロパティの値を ​`file.${env}.xml`​ のように設定できます。ただし、アプリケーションプロパティは、同じファイルで定義されていないアプリケーションプロパティの値に連動することはできません。たとえば、セキュア設定プロパティは設定プロパティに連動できません。 この階層構造のため、ファイルを読み込む Mule コンポーネントはアプリケーションやグローバルプロパティに連動することはできません。Mule Runtime Engine は、コンポーネントとアプリケーションプロパティを同じ階層で読み込みます。たとえば、Mule がアプリケーションプロパティを読み込む前に ​`import`​ コンポーネントを読み込むと、​`import`​ コンポーネントの読み込みが必要になった時点でプロパティが解決されていないため、デプロイは失敗します。 ## [](#組み込みプロパティ)組み込みプロパティ Mule Runtime Engine は内部のアプリケーションプロパティを定義し、Mule インスタンスとデプロイされたアプリケーションの設定に基づいて値を割り当てます。
プロパティ 説明

app.home

Mule アプリケーションの ​/home​ ディレクトリへのパス

app.name

Mule アプリケーションの名前

domain.name

ドメインの名前

api.name

API の名前

mule.home

Mule インスタンスの ​/home​ ディレクトリへのパス
これらのプロパティは一切上書きしないでください。Mule ではこれらの値のいくつかを内部的に使用しており、上書きすると予期しない動作が発生するおそれがあります。 # プロパティの設定 プロパティプレースホルダーやシステムプロパティなどのプロパティを設定できます。 ## [](#プロパティプレースホルダー)プロパティプレースホルダー Mule 設定では、 [Ant](http://ant.apache.org/)​ スタイルのプロパティプレースホルダーを使用できます。例: ```xml ``` 後続のセクションで説明されているように、これらのプレースホルダーの値は、さまざまな方法で使用可能にすることができます。 また、プロパティプレースホルダー値の解決をエスケープすることもできます。 ```xml ``` プロパティの値を返す代わりに、Logger コンポーネントは文字列 ​`"${property.value}"`​ を返します。エスケープ文字 ​`\`​ を使用して、プロパティのプレフィックス (​`${`​ 文字シーケンス) の解決をエスケープすることもできます。 ## [](#グローバルプロパティ)グローバルプロパティ ``​ 要素を使用すると、Mule 設定内 (別の Mule 設定ファイル内など) からプレースホルダーの値を設定できます。グローバルプロパティ構文を使用して、​`.yaml`​ または ​`.properties`​ ファイルの値を参照し、設定プロパティまたはセキュアな設定プロパティに連動する新しい (グローバル) プロパティを作成できます。設定プロパティを参照するには、プロパティファイルのセクションを読み取ります。 ```xml ``` ## [](#プロパティファイル)プロパティファイル カスタムファイルのプロパティを読み込むには、カスタムプロパティファイルを ​`src/main/resources`​ に配置し、​``​ タグを使用します。 ```xml ``` 複数のプロパティファイルを読み込むには、読み込むファイルごとに ​``​ タグを定義します。 - ``​ タグで参照される複数のファイルでプロパティが定義されている場合、最初の定義が保持されます。 これらのファイルは、Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。または、絶対パスを使用することもできます。 ## [](#supported_files)サポートされているファイル 設定プロパティでは、YAML 設定ファイル (​`.yaml`​) とプロパティ設定ファイル (​`.properties`​) の両方がサポートされています。 両方のファイル形式でサポートされている型は ​`String`​ のみです。自分にとって読みやすく、編集しやすい形式を使用してください。 YAML ファイルの例: ```xml ``` `ports.yaml`​ を次に示します。 ```yaml smtp: port: "8957" http: port: "8081" ``` プロパティファイルの例: ```xml ``` `ports.properties`​ を次に示します。 ```xml smtp.port=8957 http.port=8081 ``` ## [](#ファイルプロパティ)ファイルプロパティ プレースホルダーの値は、ファイルのコンテンツ全体になることもあります。プレースホルダーの値は、次のような文字列値になります。 properties-file.txt Some content ```xml ``` ペイロードの値は ​`"Some content"`​ になります。他のプロパティファイルと同様に、これらのファイルは Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。絶対パスを使用することもできます。 この方法は、設定ファイルをモジュール化する場合に役立ちます。設定ファイル、SQL クエリ、変換から大きなコンテンツを抽出して設定ファイルを明確化し、そのコンテンツを再利用できます。 ## [](#システムプロパティ)システムプロパティ Mule をオンプレミスで実行するときに JDK システムプロパティを設定し、後でそのプロパティを使用して Mule アプリケーションでコンポーネントまたはモジュールを設定できます。プロパティを指定する方法は 2 つあります。 - Mule インスタンスを開始するときに、コマンドラインから指定します。 mule -M-Dsmtp.username=JSmith -M-Dsmtp.password=ChangeMe - `$MULE_HOME/conf`​ ディレクトリに配置されている ​`wrapper.conf`​ ファイルを編集し、プロパティごとにエントリを追加します。 wrapper.java.additional.999=-Dsmtp.username=JSmith wrapper.java.additional.1000=-Dsmtp.password=ChangeMe 設定についての詳細は、​[システムプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-app-properties-system#set-properties)​を参照してください。 ## [](#カスタムプロパティプロバイダー)カスタムプロパティプロバイダー Mule API を使用して、カスタムプロパティプロバイダーの実装を作成できます。詳細は、​[「カスタム設定プロパティプロバイダー」](https://docs.mulesoft.com/jp/mule-runtime/4.8/custom-configuration-properties-provider)​を参照してください。 ### [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Anypoint Studio でプロジェクトを起動するときに、\[Run Configurations (設定を実行)\] メニューでプロパティを追加できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. **\[VM arguments (VM 引数)\]**​ 項目に引数 (プロパティ名の前に ​**\-D**​) を追加します。 ![Anypoint Studio の JVM 引数の設定が表示されている \[Arguments (引数)\] タブ](_images/arguments-tab.png) これで、アプリケーションをデプロイするたびに Studio でプロパティを使用できるようになりました。次の構文を使用してプロパティを参照できます。 ```xml ``` ## [](#環境変数)環境変数 環境変数はさまざまな方法で定義でき、アプリケーションから環境変数にアクセスする方法も複数あります。環境変数の定義方法に関係なく、次の構文を使用して参照することをお勧めします。 ${variableName} ### [](#os-の環境変数)OS の環境変数 OS で定義された変数を参照するには、次の構文を使用します。 ```xml ``` ### [](#anypoint-studio-で環境変数を設定する)Anypoint Studio で環境変数を設定する Studio の \[Run Configuration (設定を実行)\] メニューで変数を設定できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ を選択します。 3. \[Environment (環境)\] タブを選択します。 4. **\[New (新規)\]**​ ボタンをクリックし、変数に名前と値を割り当てます。 ![\[Newf (新規)\] などのオプションが含まれる \[Environment (環境)\] タブ](_images/environment-tab.png) これで、デプロイするたびに Studio で変数を使用できるようになりました。次の構文を使用して変数を参照できます。 ```xml ```
OS で定義された変数を参照する構文と、Studio で定義された変数を参照する構文は同じです。Studio で定義された変数で、OS で定義された同じ名前の変数を置き換えるかどうかを、変数の作成時に UI の対応するラジオボタンをオンにして選択することができます。
![変数を定義するオプションが含まれる \[Environment (環境)\] タブ](_images/environment-tab2.png) ## [](#プロパティファイルの動的な設定)プロパティファイルの動的な設定 一般的な設定のユースケースは、プロパティに連動するファイル (​`env`​ など) を設定して、使用するファイル (開発フェーズの ​`development-properties`​ ファイルや本番ファイルなど) を決定することです。 ```xml ``` そのため、​`env`​ プロパティの値によって、設定プロパティの読み込みに使用するファイルが決まります。その ​`env`​ プロパティは、グローバルプロパティ、システムプロパティ、または環境プロパティで設定できます。設定プロパティのデフォルト値を定義する方法として、グローバルプロパティを使用できます。グローバルプロパティと同じ名前のシステムおよび環境プロパティは、そのグローバルプロパティよりも優先されます。 ```xml ``` `env`​ プロパティのデフォルト値は ​`dev`​ になりますが、システムプロパティや環境プロパティで上書きできます。この設定は、Anypoint Studio でメタデータを解決するために​**必要**​になります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらの値に連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 他にも、設定プロパティのプレースホルダーは別の設定プロパティから読み込まれるプロパティに連動できないという点も考慮する必要があります。上記の例では、プロパティ ​`env`​ は設定プロパティで定義できていません。以下の例は、​**正しくありません**​。 ```xml ``` これには、他のプロパティ種別 (セキュア設定プロパティやカスタム設定プロパティなど) も含まれます。 ## [](#runtime-manager-でプロパティ値を設定する)Runtime Manager でプロパティ値を設定する アプリケーションを ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/)​ にデプロイする場合、Runtime Manager コンソールでプロパティを設定することもできます。これらは、​[CloudHub にデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)​するときや、​[すでに実行中のアプリケーション](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​で定義できます。 環境変数またはアプリケーションプロパティを作成する手順は、次のとおりです。 1. Anypoint Platform アカウントにログインします。 2. \[Runtime Manager\] をクリックします。 3. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックして新しいアプリケーションをデプロイするか、実行中のアプリケーションを選択して ​**\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ セクションで ​**\[Properties (プロパティ)\]**​ タブを選択します。 詳細は、​[「Managing Applications on CloudHub (CloudHub でのアプリケーションの管理)」](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​および​[「Secure Application Properties (セキュアなセキュリティプロパティ)」](https://docs.mulesoft.com/cloudhub/secure-application-properties)​を参照してください。 ## [](#properties-hierarchy)プロパティ階層 設定プロパティは上書き可能です。Mule Runtime Engine は、次の階層を使用して、同じ名前の場合に優先されるプロパティを決定します。この階層では、デプロイメントプロパティは上部にあるため、他のプロパティ種別よりも優先されます。 1. デプロイメントプロパティ 2. システムプロパティ 3. 環境プロパティ 4. アプリケーションプロパティ (設定プロパティ、セキュア設定プロパティ、および他のカスタム設定プロパティを含む) 5. グローバルプロパティ そのため、たとえば、​`size`​ という名前の設定プロパティがシステムプロパティとして定義されていて、​`size`​ という名前のアプリケーション設定プロパティもある場合、アプリケーションの値は、最も優先度の高いプロパティ (この場合はシステムプロパティ) の値になります。 プロパティの値は、階層の上位に位置する他のプロパティから派生させることができます。そのため、アプリケーションプロパティの値は、環境プロパティ、システムプロパティ、デプロイメントプロパティから派生させることができます。システムプロパティの値は、デプロイメントプロパティから派生させることができます (以下同様)。たとえば、​`env`​ という名前のシステムプロパティがある場合、アプリケーション設定プロパティの値を ​`file.${env}.xml`​ のように設定できます。ただし、アプリケーションプロパティは、同じファイルで定義されていないアプリケーションプロパティの値に連動することはできません。たとえば、セキュア設定プロパティは設定プロパティに連動できません。 この階層構造のため、ファイルを読み込む Mule コンポーネントはアプリケーションやグローバルプロパティに連動することはできません。Mule Runtime Engine は、コンポーネントとアプリケーションプロパティを同じ階層で読み込みます。たとえば、Mule がアプリケーションプロパティを読み込む前に ​`import`​ コンポーネントを読み込むと、​`import`​ コンポーネントの読み込みが必要になった時点でプロパティが解決されていないため、デプロイは失敗します。 ## [](#組み込みプロパティ)組み込みプロパティ Mule Runtime Engine は内部のアプリケーションプロパティを定義し、Mule インスタンスとデプロイされたアプリケーションの設定に基づいて値を割り当てます。
プロパティ 説明

app.home

Mule アプリケーションの ​/home​ ディレクトリへのパス

app.name

Mule アプリケーションの名前

domain.name

ドメインの名前

api.name

API の名前

mule.home

Mule インスタンスの ​/home​ ディレクトリへのパス
これらのプロパティは一切上書きしないでください。Mule ではこれらの値のいくつかを内部的に使用しており、上書きすると予期しない動作が発生するおそれがあります。 # プロパティの設定 プロパティプレースホルダーやシステムプロパティなどのプロパティを設定できます。 ## [](#プロパティプレースホルダー)プロパティプレースホルダー Mule 設定では、 [Ant](http://ant.apache.org/)​ スタイルのプロパティプレースホルダーを使用できます。例: ```xml ``` 後続のセクションで説明されているように、これらのプレースホルダーの値は、さまざまな方法で使用可能にすることができます。 また、プロパティプレースホルダー値の解決をエスケープすることもできます。 ```xml ``` プロパティの値を返す代わりに、Logger コンポーネントは文字列 ​`"${property.value}"`​ を返します。エスケープ文字 ​`\`​ を使用して、プロパティのプレフィックス (​`${`​ 文字シーケンス) の解決をエスケープすることもできます。 ## [](#グローバルプロパティ)グローバルプロパティ ``​ 要素を使用すると、Mule 設定内 (別の Mule 設定ファイル内など) からプレースホルダーの値を設定できます。グローバルプロパティ構文を使用して、​`.yaml`​ または ​`.properties`​ ファイルの値を参照し、設定プロパティまたはセキュアな設定プロパティに連動する新しい (グローバル) プロパティを作成できます。設定プロパティを参照するには、プロパティファイルのセクションを読み取ります。 ```xml ``` ## [](#プロパティファイル)プロパティファイル カスタムファイルのプロパティを読み込むには、カスタムプロパティファイルを ​`src/main/resources`​ に配置し、​``​ タグを使用します。 ```xml ``` 複数のプロパティファイルを読み込むには、読み込むファイルごとに ​``​ タグを定義します。 - ``​ タグで参照される複数のファイルでプロパティが定義されている場合、最初の定義が保持されます。 これらのファイルは、Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。または、絶対パスを使用することもできます。 ## [](#supported_files)サポートされているファイル 設定プロパティでは、YAML 設定ファイル (​`.yaml`​) とプロパティ設定ファイル (​`.properties`​) の両方がサポートされています。 両方のファイル形式でサポートされている型は ​`String`​ のみです。自分にとって読みやすく、編集しやすい形式を使用してください。 YAML ファイルの例: ```xml ``` `ports.yaml`​ を次に示します。 ```yaml smtp: port: "8957" http: port: "8081" ``` プロパティファイルの例: ```xml ``` `ports.properties`​ を次に示します。 ```xml smtp.port=8957 http.port=8081 ``` ## [](#ファイルプロパティ)ファイルプロパティ プレースホルダーの値は、ファイルのコンテンツ全体になることもあります。プレースホルダーの値は、次のような文字列値になります。 properties-file.txt Some content ```xml ``` ペイロードの値は ​`"Some content"`​ になります。他のプロパティファイルと同様に、これらのファイルは Mule プロジェクト内の ​`src/main/resources`​ に配置されている必要があります。絶対パスを使用することもできます。 この方法は、設定ファイルをモジュール化する場合に役立ちます。設定ファイル、SQL クエリ、変換から大きなコンテンツを抽出して設定ファイルを明確化し、そのコンテンツを再利用できます。 ## [](#システムプロパティ)システムプロパティ Mule をオンプレミスで実行するときに JDK システムプロパティを設定し、後でそのプロパティを使用して Mule アプリケーションでコンポーネントまたはモジュールを設定できます。プロパティを指定する方法は 2 つあります。 - Mule インスタンスを開始するときに、コマンドラインから指定します。 mule -M-Dsmtp.username=JSmith -M-Dsmtp.password=ChangeMe - `$MULE_HOME/conf`​ ディレクトリに配置されている ​`wrapper.conf`​ ファイルを編集し、プロパティごとにエントリを追加します。 wrapper.java.additional.999=-Dsmtp.username=JSmith wrapper.java.additional.1000=-Dsmtp.password=ChangeMe 設定についての詳細は、​[システムプロパティ](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-app-properties-system#set-properties)​を参照してください。 ## [](#カスタムプロパティプロバイダー)カスタムプロパティプロバイダー Mule API を使用して、カスタムプロパティプロバイダーの実装を作成できます。詳細は、​[「カスタム設定プロパティプロバイダー」](https://docs.mulesoft.com/jp/mule-runtime/4.9/custom-configuration-properties-provider)​を参照してください。 ### [](#anypoint-studio-でシステムプロパティを設定する)Anypoint Studio でシステムプロパティを設定する Anypoint Studio でプロジェクトを起動するときに、\[Run Configurations (設定を実行)\] メニューでプロパティを追加できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ をクリックします。 3. **\[Arguments (引数)\]**​ タブを選択します。 4. **\[VM arguments (VM 引数)\]**​ 項目に引数 (プロパティ名の前に ​**\-D**​) を追加します。 ![Anypoint Studio の JVM 引数の設定が表示されている \[Arguments (引数)\] タブ](_images/arguments-tab.png) これで、アプリケーションをデプロイするたびに Studio でプロパティを使用できるようになりました。次の構文を使用してプロパティを参照できます。 ```xml ``` ## [](#環境変数)環境変数 環境変数はさまざまな方法で定義でき、アプリケーションから環境変数にアクセスする方法も複数あります。環境変数の定義方法に関係なく、次の構文を使用して参照することをお勧めします。 ${variableName} ### [](#os-の環境変数)OS の環境変数 OS で定義された変数を参照するには、次の構文を使用します。 ```xml ``` ### [](#anypoint-studio-で環境変数を設定する)Anypoint Studio で環境変数を設定する Studio の \[Run Configuration (設定を実行)\] メニューで変数を設定できます。 1. Package Explorer でプロジェクトを右クリックします。 2. **\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations (設定を実行)\]**​ を選択します。 3. \[Environment (環境)\] タブを選択します。 4. **\[New (新規)\]**​ ボタンをクリックし、変数に名前と値を割り当てます。 ![\[Newf (新規)\] などのオプションが含まれる \[Environment (環境)\] タブ](_images/environment-tab.png) これで、デプロイするたびに Studio で変数を使用できるようになりました。次の構文を使用して変数を参照できます。 ```xml ```
OS で定義された変数を参照する構文と、Studio で定義された変数を参照する構文は同じです。Studio で定義された変数で、OS で定義された同じ名前の変数を置き換えるかどうかを、変数の作成時に UI の対応するラジオボタンをオンにして選択することができます。
![変数を定義するオプションが含まれる \[Environment (環境)\] タブ](_images/environment-tab2.png) ## [](#プロパティファイルの動的な設定)プロパティファイルの動的な設定 一般的な設定のユースケースは、プロパティに連動するファイル (​`env`​ など) を設定して、使用するファイル (開発フェーズの ​`development-properties`​ ファイルや本番ファイルなど) を決定することです。 ```xml ``` そのため、​`env`​ プロパティの値によって、設定プロパティの読み込みに使用するファイルが決まります。その ​`env`​ プロパティは、グローバルプロパティ、システムプロパティ、または環境プロパティで設定できます。設定プロパティのデフォルト値を定義する方法として、グローバルプロパティを使用できます。グローバルプロパティと同じ名前のシステムおよび環境プロパティは、そのグローバルプロパティよりも優先されます。 ```xml ``` `env`​ プロパティのデフォルト値は ​`dev`​ になりますが、システムプロパティや環境プロパティで上書きできます。この設定は、Anypoint Studio でメタデータを解決するために​**必要**​になります。コマンドラインで渡されるプロパティのデフォルト値を定義しないと、それらの値に連動するすべてのメッセージプロセッサーのアプリケーションモデルを作成するときにエラーが発生します。 他にも、設定プロパティのプレースホルダーは別の設定プロパティから読み込まれるプロパティに連動できないという点も考慮する必要があります。上記の例では、プロパティ ​`env`​ は設定プロパティで定義できていません。以下の例は、​**正しくありません**​。 ```xml ``` これには、他のプロパティ種別 (セキュア設定プロパティやカスタム設定プロパティなど) も含まれます。 ## [](#runtime-manager-でプロパティ値を設定する)Runtime Manager でプロパティ値を設定する アプリケーションを ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/)​ にデプロイする場合、Runtime Manager コンソールでプロパティを設定することもできます。これらは、​[CloudHub にデプロイ](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)​するときや、​[すでに実行中のアプリケーション](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​で定義できます。 環境変数またはアプリケーションプロパティを作成する手順は、次のとおりです。 1. Anypoint Platform アカウントにログインします。 2. \[Runtime Manager\] をクリックします。 3. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックして新しいアプリケーションをデプロイするか、実行中のアプリケーションを選択して ​**\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ セクションで ​**\[Properties (プロパティ)\]**​ タブを選択します。 詳細は、​[「Managing Applications on CloudHub (CloudHub でのアプリケーションの管理)」](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)​および​[「Secure Application Properties (セキュアなセキュリティプロパティ)」](https://docs.mulesoft.com/cloudhub/secure-application-properties)​を参照してください。 ## [](#properties-hierarchy)プロパティ階層 設定プロパティは上書き可能です。Mule Runtime Engine は、次の階層を使用して、同じ名前の場合に優先されるプロパティを決定します。この階層では、デプロイメントプロパティは上部にあるため、他のプロパティ種別よりも優先されます。 1. デプロイメントプロパティ 2. システムプロパティ 3. 環境プロパティ 4. アプリケーションプロパティ (設定プロパティ、セキュア設定プロパティ、および他のカスタム設定プロパティを含む) 5. グローバルプロパティ そのため、たとえば、​`size`​ という名前の設定プロパティがシステムプロパティとして定義されていて、​`size`​ という名前のアプリケーション設定プロパティもある場合、アプリケーションの値は、最も優先度の高いプロパティ (この場合はシステムプロパティ) の値になります。 プロパティの値は、階層の上位に位置する他のプロパティから派生させることができます。そのため、アプリケーションプロパティの値は、環境プロパティ、システムプロパティ、デプロイメントプロパティから派生させることができます。システムプロパティの値は、デプロイメントプロパティから派生させることができます (以下同様)。たとえば、​`env`​ という名前のシステムプロパティがある場合、アプリケーション設定プロパティの値を ​`file.${env}.xml`​ のように設定できます。ただし、アプリケーションプロパティは、同じファイルで定義されていないアプリケーションプロパティの値に連動することはできません。たとえば、セキュア設定プロパティは設定プロパティに連動できません。 この階層構造のため、ファイルを読み込む Mule コンポーネントはアプリケーションやグローバルプロパティに連動することはできません。Mule Runtime Engine は、コンポーネントとアプリケーションプロパティを同じ階層で読み込みます。たとえば、Mule がアプリケーションプロパティを読み込む前に ​`import`​ コンポーネントを読み込むと、​`import`​ コンポーネントの読み込みが必要になった時点でプロパティが解決されていないため、デプロイは失敗します。 ## [](#組み込みプロパティ)組み込みプロパティ Mule Runtime Engine は内部のアプリケーションプロパティを定義し、Mule インスタンスとデプロイされたアプリケーションの設定に基づいて値を割り当てます。
プロパティ 説明

app.home

Mule アプリケーションの ​/home​ ディレクトリへのパス

app.name

Mule アプリケーションの名前

domain.name

ドメインの名前

api.name

API の名前

mule.home

Mule インスタンスの ​/home​ ディレクトリへのパス
これらのプロパティは一切上書きしないでください。Mule ではこれらの値のいくつかを内部的に使用しており、上書きすると予期しない動作が発生するおそれがあります。 # プロパティプレースホルダーの設定 接続をはじめとする Mule アプリケーション設定の静的値を使用する代わりに、​`.yaml`​ または ​`.properties`​ ファイルを作成してプロパティを格納し、アプリケーションからプロパティを参照することができます。 プロパティファイルを設定することで、アプリケーションの構成およびメンテナンス性が向上します。 `.yaml`​ ファイルでは、プロパティは次の形式になります。 ```yaml http: path: "/service" port: "10000" host: "my-api.cloudhub.io" ``` `.properties`​ ファイルでは、プロパティは次の形式になります。 http.path=/service http.port=10000 http.host=my-api.cloudhub.io ## [](#プロパティファイルを作成して設定する)プロパティファイルを作成して設定する 1. Studio で ​**\[Package Explorer\]**​ ビューに移動して、プロジェクトの ​`/src/main/resources`​ フォルダーを右クリックします。 2. **\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択します。 ![new-file-properties](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-properties-new-file.png) 3. ファイルの名前を選択して、拡張子を ​`.yaml`​ または ​`.properties`​ (この形式を使用する場合) に設定します。 4. ファイルを編集して、必要なプロパティおよび値を定義します。 5. プロパティファイルを Mule アプリケーションに追加します。 - Studio から: 1. **\[Global Elements (グローバル要素)\]**​ タブを開き、​**\[Create (作成)\]**​ ボタンをクリックします。 2. 「Configuration Properties (設定プロパティ)」という名前の要素を検索し、​**\[OK\]**​ をクリックします。 3. **\[…​\]**​ ボタンをクリックして、​`.yaml`​ または ​`.properties`​ ファイルに移動します。 - XML エディターから: 1. ``​ 要素を ​``​ 内に含めて、プロパティファイル名を使用してその ​`file`​ パラメーターを設定します。例: ```xml ` ... ``` ## [](#アプリケーションでプロパティを使用する)アプリケーションでプロパティを使用する プロパティファイルを設定してプロジェクトに追加したら、次のような構文を使用してその属性を参照できます: `${propertyContainer.propertyName}`​。 前のセクションで設定した例に基づくと、​`path`​ 値および ​`port`​ 値を使用するには、構文はそれぞれ ​`${http.path}`​ および ​`${http.port}`​ になります。 たとえば、グローバル HTTP 要求設定を設定してプロパティファイルで定義された値を使用できます。 - Studio から: ![properties-file](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-properties-file.png) - XML エディターから ```xml ``` ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties) # プロパティプレースホルダーの設定 接続をはじめとする Mule アプリケーション設定の静的値を使用する代わりに、​`.yaml`​ または ​`.properties`​ ファイルを作成してプロパティを格納し、アプリケーションからプロパティを参照することができます。 プロパティファイルを設定することで、アプリケーションの構成およびメンテナンス性が向上します。 `.yaml`​ ファイルでは、プロパティは次の形式になります。 ```yaml http: path: "/service" port: "10000" host: "my-api.cloudhub.io" ``` `.properties`​ ファイルでは、プロパティは次の形式になります。 http.path=/service http.port=10000 http.host=my-api.cloudhub.io ## [](#プロパティファイルを作成して設定する)プロパティファイルを作成して設定する 1. Studio で ​**\[Package Explorer\]**​ ビューに移動して、プロジェクトの ​`/src/main/resources`​ フォルダーを右クリックします。 2. **\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択します。 ![new-file-properties](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-properties-new-file.png) 3. ファイルの名前を選択して、拡張子を ​`.yaml`​ または ​`.properties`​ (この形式を使用する場合) に設定します。 4. ファイルを編集して、必要なプロパティおよび値を定義します。 5. プロパティファイルを Mule アプリケーションに追加します。 - Studio から: 1. **\[Global Elements (グローバル要素)\]**​ タブを開き、​**\[Create (作成)\]**​ ボタンをクリックします。 2. 「Configuration Properties (設定プロパティ)」という名前の要素を検索し、​**\[OK\]**​ をクリックします。 3. **\[…​\]**​ ボタンをクリックして、​`.yaml`​ または ​`.properties`​ ファイルに移動します。 - XML エディターから: 1. ``​ 要素を ​``​ 内に含めて、プロパティファイル名を使用してその ​`file`​ パラメーターを設定します。例: ```xml ` ... ``` ## [](#アプリケーションでプロパティを使用する)アプリケーションでプロパティを使用する プロパティファイルを設定してプロジェクトに追加したら、次のような構文を使用してその属性を参照できます: `${propertyContainer.propertyName}`​。 前のセクションで設定した例に基づくと、​`path`​ 値および ​`port`​ 値を使用するには、構文はそれぞれ ​`${http.path}`​ および ​`${http.port}`​ になります。 たとえば、グローバル HTTP 要求設定を設定してプロパティファイルで定義された値を使用できます。 - Studio から: ![properties-file](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-properties-file.png) - XML エディターから ```xml ``` ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties) # プロパティプレースホルダーの設定 接続をはじめとする Mule アプリケーション設定の静的値を使用する代わりに、​`.yaml`​ または ​`.properties`​ ファイルを作成してプロパティを格納し、アプリケーションからプロパティを参照することができます。 プロパティファイルを設定することで、アプリケーションの構成およびメンテナンス性が向上します。 `.yaml`​ ファイルでは、プロパティは次の形式になります。 ```yaml http: path: "/service" port: "10000" host: "my-api.cloudhub.io" ``` `.properties`​ ファイルでは、プロパティは次の形式になります。 http.path=/service http.port=10000 http.host=my-api.cloudhub.io ## [](#プロパティファイルを作成して設定する)プロパティファイルを作成して設定する 1. Studio で ​**\[Package Explorer\]**​ ビューに移動して、プロジェクトの ​`/src/main/resources`​ フォルダーを右クリックします。 2. **\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択します。 ![new-file-properties](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-properties-new-file.png) 3. ファイルの名前を選択して、拡張子を ​`.yaml`​ または ​`.properties`​ (この形式を使用する場合) に設定します。 4. ファイルを編集して、必要なプロパティおよび値を定義します。 5. プロパティファイルを Mule アプリケーションに追加します。 - Studio から: 1. **\[Global Elements (グローバル要素)\]**​ タブを開き、​**\[Create (作成)\]**​ ボタンをクリックします。 2. 「Configuration Properties (設定プロパティ)」という名前の要素を検索し、​**\[OK\]**​ をクリックします。 3. **\[…​\]**​ ボタンをクリックして、​`.yaml`​ または ​`.properties`​ ファイルに移動します。 - XML エディターから: 1. ``​ 要素を ​``​ 内に含めて、プロパティファイル名を使用してその ​`file`​ パラメーターを設定します。例: ```xml ` ... ``` ## [](#アプリケーションでプロパティを使用する)アプリケーションでプロパティを使用する プロパティファイルを設定してプロジェクトに追加したら、次のような構文を使用してその属性を参照できます: `${propertyContainer.propertyName}`​。 前のセクションで設定した例に基づくと、​`path`​ 値および ​`port`​ 値を使用するには、構文はそれぞれ ​`${http.path}`​ および ​`${http.port}`​ になります。 たとえば、グローバル HTTP 要求設定を設定してプロパティファイルで定義された値を使用できます。 - Studio から: ![properties-file](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-properties-file.png) - XML エディターから ```xml ``` アプリケーションがデプロイされると、プロパティ値がさまざまなソースから計算され、静的にプレースホルダーを置き換えて、ソースコードに直接書き込まれたようになります。 前の例に基づくと、設定は次のようになります。 ```xml ``` コンテキストに基づく特殊文字のエスケープはありません。結果の値は参照元のコンテキスト内で有効である必要があります。 DataWeave スクリプトを含む次の例を考えてみます。 ```xml ``` `.properties`​ ファイルのコンテンツは次のようになります。 message=I love $ プロパティ置換が行われると、アプリケーションは次のようになります。 ```xml ``` ドル記号 ($) は特別な意味を持ち、エスケープする必要があるため、この出力は無効な DataWeave スクリプトです。​[「Dataweave - 特殊文字のエスケープ」](https://docs.mulesoft.com/dataweave/latest/dataweave-types#escape-chars-string)​を参照してください。DataWeave スクリプトが解析される前にプロパティプレースホルダーが置き換えられることを覚えておいてください。 競合を解決するには、プロパティファイル内の値をエスケープできます。 message=I love \\$ または、プロパティプレースホルダーの代わりに DataWeave の ​[p 関数](https://docs.mulesoft.com/dataweave/latest/dw-mule-functions-p)​を使用することもできます。 ```xml ``` プロパティはスクリプトの実行時に評価され、解析時にはスクリプトは構文的に有効なままになります。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties) # プロパティプレースホルダーの設定 接続をはじめとする Mule アプリケーション設定の静的値を使用する代わりに、​`.yaml`​ または ​`.properties`​ ファイルを作成してプロパティを格納し、アプリケーションからプロパティを参照することができます。 プロパティファイルを設定することで、アプリケーションの構成およびメンテナンス性が向上します。 `.yaml`​ ファイルでは、プロパティは次の形式になります。 ```yaml http: path: "/service" port: "10000" host: "my-api.cloudhub.io" ``` `.properties`​ ファイルでは、プロパティは次の形式になります。 http.path=/service http.port=10000 http.host=my-api.cloudhub.io ## [](#プロパティファイルを作成して設定する)プロパティファイルを作成して設定する 1. Studio で ​**\[Package Explorer\]**​ ビューに移動して、プロジェクトの ​`/src/main/resources`​ フォルダーを右クリックします。 2. **\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択します。 ![new-file-properties](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-properties-new-file.png) 3. ファイルの名前を選択して、拡張子を ​`.yaml`​ または ​`.properties`​ (この形式を使用する場合) に設定します。 4. ファイルを編集して、必要なプロパティおよび値を定義します。 5. プロパティファイルを Mule アプリケーションに追加します。 - Studio から: 1. **\[Global Elements (グローバル要素)\]**​ タブを開き、​**\[Create (作成)\]**​ ボタンをクリックします。 2. 「Configuration Properties (設定プロパティ)」という名前の要素を検索し、​**\[OK\]**​ をクリックします。 3. **\[…​\]**​ ボタンをクリックして、​`.yaml`​ または ​`.properties`​ ファイルに移動します。 - XML エディターから: 1. ``​ 要素を ​``​ 内に含めて、プロパティファイル名を使用してその ​`file`​ パラメーターを設定します。例: ```xml ` ... ``` ## [](#アプリケーションでプロパティを使用する)アプリケーションでプロパティを使用する プロパティファイルを設定してプロジェクトに追加したら、次のような構文を使用してその属性を参照できます: `${propertyContainer.propertyName}`​。 前のセクションで設定した例に基づくと、​`path`​ 値および ​`port`​ 値を使用するには、構文はそれぞれ ​`${http.path}`​ および ​`${http.port}`​ になります。 たとえば、グローバル HTTP 要求設定を設定してプロパティファイルで定義された値を使用できます。 - Studio から: ![properties-file](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-properties-file.png) - XML エディターから ```xml ``` アプリケーションがデプロイされると、プロパティ値がさまざまなソースから計算され、静的にプレースホルダーを置き換えて、ソースコードに直接書き込まれたようになります。 前の例に基づくと、設定は次のようになります。 ```xml ``` コンテキストに基づく特殊文字のエスケープはありません。結果の値は参照元のコンテキスト内で有効である必要があります。 DataWeave スクリプトを含む次の例を考えてみます。 ```xml ``` `.properties`​ ファイルのコンテンツは次のようになります。 message=I love $ プロパティ置換が行われると、アプリケーションは次のようになります。 ```xml ``` ドル記号 ($) は特別な意味を持ち、エスケープする必要があるため、この出力は無効な DataWeave スクリプトです。​[「Dataweave - 特殊文字のエスケープ」](https://docs.mulesoft.com/dataweave/latest/dataweave-types#escape-chars-string)​を参照してください。DataWeave スクリプトが解析される前にプロパティプレースホルダーが置き換えられることを覚えておいてください。 競合を解決するには、プロパティファイル内の値をエスケープできます。 message=I love \\$ または、プロパティプレースホルダーの代わりに DataWeave の ​[p 関数](https://docs.mulesoft.com/dataweave/latest/dw-mule-functions-p)​を使用することもできます。 ```xml ``` プロパティはスクリプトの実行時に評価され、解析時にはスクリプトは構文的に有効なままになります。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties) # プロパティプレースホルダーの設定 接続をはじめとする Mule アプリケーション設定の静的値を使用する代わりに、​`.yaml`​ または ​`.properties`​ ファイルを作成してプロパティを格納し、アプリケーションからプロパティを参照することができます。 プロパティファイルを設定することで、アプリケーションの構成およびメンテナンス性が向上します。 `.yaml`​ ファイルでは、プロパティは次の形式になります。 ```yaml http: path: "/service" port: "10000" host: "my-api.cloudhub.io" ``` `.properties`​ ファイルでは、プロパティは次の形式になります。 http.path=/service http.port=10000 http.host=my-api.cloudhub.io ## [](#プロパティファイルを作成して設定する)プロパティファイルを作成して設定する 1. Studio で ​**\[Package Explorer\]**​ ビューに移動して、プロジェクトの ​`/src/main/resources`​ フォルダーを右クリックします。 2. **\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択します。 ![new-file-properties](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-properties-new-file.png) 3. ファイルの名前を選択して、拡張子を ​`.yaml`​ または ​`.properties`​ (この形式を使用する場合) に設定します。 4. ファイルを編集して、必要なプロパティおよび値を定義します。 5. プロパティファイルを Mule アプリケーションに追加します。 - Studio から: 1. **\[Global Elements (グローバル要素)\]**​ タブを開き、​**\[Create (作成)\]**​ ボタンをクリックします。 2. 「Configuration Properties (設定プロパティ)」という名前の要素を検索し、​**\[OK\]**​ をクリックします。 3. **\[…​\]**​ ボタンをクリックして、​`.yaml`​ または ​`.properties`​ ファイルに移動します。 - XML エディターから: 1. ``​ 要素を ​``​ 内に含めて、プロパティファイル名を使用してその ​`file`​ パラメーターを設定します。次に例を示します。 ```xml ` ... ``` ## [](#アプリケーションでプロパティを使用する)アプリケーションでプロパティを使用する プロパティファイルを設定してプロジェクトに追加したら、次のような構文を使用してその属性を参照できます: `${propertyContainer.propertyName}`​。 前のセクションで設定した例に基づくと、​`path`​ 値および ​`port`​ 値を使用するには、構文はそれぞれ ​`${http.path}`​ および ​`${http.port}`​ になります。 たとえば、グローバル HTTP 要求設定を設定してプロパティファイルで定義された値を使用できます。 - Studio から: ![properties-file](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-properties-file.png) - XML エディターから ```xml ``` アプリケーションがデプロイされると、プロパティ値がさまざまなソースから計算され、静的にプレースホルダーを置き換えて、ソースコードに直接書き込まれたようになります。 前の例に基づくと、設定は次のようになります。 ```xml ``` コンテキストに基づく特殊文字のエスケープはありません。結果の値は参照元のコンテキスト内で有効である必要があります。 DataWeave スクリプトを含む次の例を考えてみます。 ```xml ``` `.properties`​ ファイルのコンテンツは次のようになります。 message=I love $ プロパティ置換が行われると、アプリケーションは次のようになります。 ```xml ``` ドル記号 ($) は特別な意味を持ち、エスケープする必要があるため、この出力は無効な DataWeave スクリプトです。​[「Dataweave - 特殊文字のエスケープ」](https://docs.mulesoft.com/dataweave/latest/dataweave-types#escape-chars-string)​を参照してください。DataWeave スクリプトが解析される前にプロパティプレースホルダーが置き換えられることを覚えておいてください。 競合を解決するには、プロパティファイル内の値をエスケープできます。 message=I love \\$ または、プロパティプレースホルダーの代わりに DataWeave の ​[p 関数](https://docs.mulesoft.com/dataweave/latest/dw-mule-functions-p)​を使用することもできます。 ```xml ``` プロパティはスクリプトの実行時に評価され、解析時にはスクリプトは構文的に有効なままになります。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties) # プロパティプレースホルダーの設定 接続をはじめとする Mule アプリケーション設定の静的値を使用する代わりに、​`.yaml`​ または ​`.properties`​ ファイルを作成してプロパティを格納し、アプリケーションからプロパティを参照することができます。 プロパティファイルを設定することで、アプリケーションの構成およびメンテナンス性が向上します。 `.yaml`​ ファイルでは、プロパティは次の形式になります。 ```yaml http: path: "/service" port: "10000" host: "my-api.cloudhub.io" ``` `.properties`​ ファイルでは、プロパティは次の形式になります。 http.path=/service http.port=10000 http.host=my-api.cloudhub.io ## [](#プロパティファイルを作成して設定する)プロパティファイルを作成して設定する 1. Studio で ​**\[Package Explorer\]**​ ビューに移動して、プロジェクトの ​`/src/main/resources`​ フォルダーを右クリックします。 2. **\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択します。 ![さまざまなソースおよびテストディレクトリが表示されている Mule プロジェクト構造](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-properties-new-file.png) 3. ファイルの名前を選択して、拡張子を ​`.yaml`​ または ​`.properties`​ (この形式を使用する場合) に設定します。 4. ファイルを編集して、必要なプロパティおよび値を定義します。 5. プロパティファイルを Mule アプリケーションに追加します。 - Studio から: 1. **\[Global Elements (グローバル要素)\]**​ タブを開き、​**\[Create (作成)\]**​ ボタンをクリックします。 2. 「Configuration Properties (設定プロパティ)」という名前の要素を検索し、​**\[OK\]**​ をクリックします。 3. **\[…​\]**​ ボタンをクリックして、​`.yaml`​ または ​`.properties`​ ファイルに移動します。 - XML エディターから: 1. ``​ 要素を ​``​ 内に含めて、プロパティファイル名を使用してその ​`file`​ パラメーターを設定します。次に例を示します。 ```xml ` ... ``` ## [](#アプリケーションでプロパティを使用する)アプリケーションでプロパティを使用する プロパティファイルを設定してプロジェクトに追加したら、次のような構文を使用してその属性を参照できます: `${propertyContainer.propertyName}`​。 前のセクションで設定した例に基づくと、​`path`​ 値および ​`port`​ 値を使用するには、構文はそれぞれ ​`${http.path}`​ および ​`${http.port}`​ になります。 たとえば、グローバル HTTP 要求設定を設定してプロパティファイルで定義された値を使用できます。 - Studio から: ![URL、ホスト、ポート、接続設定の項目が表示されている HTTP 要求設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-properties-file.png) - XML エディターから ```xml ``` アプリケーションがデプロイされると、プロパティ値がさまざまなソースから計算され、静的にプレースホルダーを置き換えて、ソースコードに直接書き込まれたようになります。 前の例に基づくと、設定は次のようになります。 ```xml ``` コンテキストに基づく特殊文字のエスケープはありません。結果の値は参照元のコンテキスト内で有効である必要があります。 DataWeave スクリプトを含む次の例を考えてみます。 ```xml ``` `.properties`​ ファイルのコンテンツは次のようになります。 message=I love $ プロパティ置換が行われると、アプリケーションは次のようになります。 ```xml ``` ドル記号 ($) は特別な意味を持ち、エスケープする必要があるため、この出力は無効な DataWeave スクリプトです。​[「Dataweave - 特殊文字のエスケープ」](https://docs.mulesoft.com/dataweave/latest/dataweave-types#escape-chars-string)​を参照してください。DataWeave スクリプトが解析される前にプロパティプレースホルダーが置き換えられることを覚えておいてください。 競合を解決するには、プロパティファイル内の値をエスケープできます。 message=I love \\$ または、プロパティプレースホルダーの代わりに DataWeave の ​[p 関数](https://docs.mulesoft.com/dataweave/latest/dw-mule-functions-p)​を使用することもできます。 ```xml ``` プロパティはスクリプトの実行時に評価され、解析時にはスクリプトは構文的に有効なままになります。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties) # プロパティプレースホルダーの設定 接続をはじめとする Mule アプリケーション設定の静的値を使用する代わりに、​`.yaml`​ または ​`.properties`​ ファイルを作成してプロパティを格納し、アプリケーションからプロパティを参照することができます。 プロパティファイルを設定することで、アプリケーションの構成およびメンテナンス性が向上します。 `.yaml`​ ファイルでは、プロパティは次の形式になります。 ```yaml http: path: "/service" port: "10000" host: "my-api.cloudhub.io" ``` `.properties`​ ファイルでは、プロパティは次の形式になります。 http.path=/service http.port=10000 http.host=my-api.cloudhub.io ## [](#プロパティファイルを作成して設定する)プロパティファイルを作成して設定する 1. Studio で ​**\[Package Explorer\]**​ ビューに移動して、プロジェクトの ​`/src/main/resources`​ フォルダーを右クリックします。 2. **\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択します。 ![さまざまなソースおよびテストディレクトリが表示されている Mule プロジェクト構造](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-properties-new-file.png) 3. ファイルの名前を選択して、拡張子を ​`.yaml`​ または ​`.properties`​ (この形式を使用する場合) に設定します。 4. ファイルを編集して、必要なプロパティおよび値を定義します。 5. プロパティファイルを Mule アプリケーションに追加します。 - Studio から: 1. **\[Global Elements (グローバル要素)\]**​ タブを開き、​**\[Create (作成)\]**​ ボタンをクリックします。 2. 「Configuration Properties (設定プロパティ)」という名前の要素を検索し、​**\[OK\]**​ をクリックします。 3. **\[…​\]**​ ボタンをクリックして、​`.yaml`​ または ​`.properties`​ ファイルに移動します。 - XML エディターから: 1. ``​ 要素を ​``​ 内に含めて、プロパティファイル名を使用してその ​`file`​ パラメーターを設定します。次に例を示します。 ```xml ` ... ``` ## [](#アプリケーションでプロパティを使用する)アプリケーションでプロパティを使用する プロパティファイルを設定してプロジェクトに追加したら、次のような構文を使用してその属性を参照できます: `${propertyContainer.propertyName}`​。 前のセクションで設定した例に基づくと、​`path`​ 値および ​`port`​ 値を使用するには、構文はそれぞれ ​`${http.path}`​ および ​`${http.port}`​ になります。 たとえば、グローバル HTTP 要求設定を設定してプロパティファイルで定義された値を使用できます。 - Studio から: ![URL、ホスト、ポート、接続設定の項目が表示されている HTTP 要求設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-properties-file.png) - XML エディターから ```xml ``` アプリケーションがデプロイされると、プロパティ値がさまざまなソースから計算され、静的にプレースホルダーを置き換えて、ソースコードに直接書き込まれたようになります。 前の例に基づくと、設定は次のようになります。 ```xml ``` コンテキストに基づく特殊文字のエスケープはありません。結果の値は参照元のコンテキスト内で有効である必要があります。 DataWeave スクリプトを含む次の例を考えてみます。 ```xml ``` `.properties`​ ファイルのコンテンツは次のようになります。 message=I love $ プロパティ置換が行われると、アプリケーションは次のようになります。 ```xml ``` ドル記号 ($) は特別な意味を持ち、エスケープする必要があるため、この出力は無効な DataWeave スクリプトです。​[「Dataweave - 特殊文字のエスケープ」](https://docs.mulesoft.com/dataweave/latest/dataweave-types#escape-chars-string)​を参照してください。DataWeave スクリプトが解析される前にプロパティプレースホルダーが置き換えられることを覚えておいてください。 競合を解決するには、プロパティファイル内の値をエスケープできます。 message=I love \\$ または、プロパティプレースホルダーの代わりに DataWeave の ​[p 関数](https://docs.mulesoft.com/dataweave/latest/dw-mule-functions-p)​を使用することもできます。 ```xml ``` プロパティはスクリプトの実行時に評価され、解析時にはスクリプトは構文的に有効なままになります。 ## [](#関連情報)関連情報 - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties) # メッセージプロパティの移行 Mule 3 には、さまざまな目的に使用できるプロパティスコープがいくつかあります。Mule 4 では、これらのスコープのほとんどが削除されました。 ## [](#呼び出しプロパティ)呼び出しプロパティ 呼び出しプロパティは、Mule 4 では ​`variables`​ と呼ばれるようになりました。動作は Mule 3 の場合とまったく同じです。 ## [](#インバウンドプロパティアウトバウンドプロパティインバウンド添付ファイルアウトバウンド添付ファイル)インバウンドプロパティ、アウトバウンドプロパティ、インバウンド添付ファイル、アウトバウンド添付ファイル これらのスコープは Mule 4 には存在しません。移行についての詳細は、​[「Mule メッセージについて」](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-mule-message)​を参照してください。 ## [](#関連情報)関連情報 [Mule 4 の概要: Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-mule-message) [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-event) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-message) [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-variables) # メッセージプロパティの移行 Mule 3 には、さまざまな目的に使用できるプロパティスコープがいくつかあります。Mule 4 では、これらのスコープのほとんどが削除されました。 ## [](#呼び出しプロパティ)呼び出しプロパティ 呼び出しプロパティは、Mule 4 では ​`variables`​ と呼ばれるようになりました。動作は Mule 3 の場合とまったく同じです。 ## [](#インバウンドプロパティアウトバウンドプロパティインバウンド添付ファイルアウトバウンド添付ファイル)インバウンドプロパティ、アウトバウンドプロパティ、インバウンド添付ファイル、アウトバウンド添付ファイル これらのスコープは Mule 4 には存在しません。移行についての詳細は、​[「Mule メッセージについて」](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-mule-message)​を参照してください。 ## [](#関連情報)関連情報 [Mule 4 の概要: Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-mule-message) [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-event) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-message) [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-variables) # メッセージプロパティの移行 Mule 3 には、さまざまな目的に使用できるプロパティスコープがいくつかあります。Mule 4 では、これらのスコープのほとんどが削除されました。 ## [](#呼び出しプロパティ)呼び出しプロパティ 呼び出しプロパティは、Mule 4 では ​`variables`​ と呼ばれるようになりました。動作は Mule 3 の場合とまったく同じです。 ## [](#インバウンドプロパティアウトバウンドプロパティインバウンド添付ファイルアウトバウンド添付ファイル)インバウンドプロパティ、アウトバウンドプロパティ、インバウンド添付ファイル、アウトバウンド添付ファイル これらのスコープは Mule 4 には存在しません。移行についての詳細は、​[「Mule メッセージについて」](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-mule-message)​を参照してください。 ## [](#関連情報)関連情報 [Mule 4 の概要: Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-mule-message) [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-event) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-message) [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-variables) # メッセージプロパティの移行 Mule 3 には、さまざまな目的に使用できるプロパティスコープがいくつかあります。Mule 4 では、これらのスコープのほとんどが削除されました。 ## [](#呼び出しプロパティ)呼び出しプロパティ 呼び出しプロパティは、Mule 4 では ​`variables`​ と呼ばれるようになりました。動作は Mule 3 の場合とまったく同じです。 ## [](#インバウンドプロパティアウトバウンドプロパティインバウンド添付ファイルアウトバウンド添付ファイル)インバウンドプロパティ、アウトバウンドプロパティ、インバウンド添付ファイル、アウトバウンド添付ファイル これらのスコープは Mule 4 には存在しません。移行についての詳細は、​[「Mule メッセージについて」](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-mule-message)​を参照してください。 ## [](#関連情報)関連情報 [Mule 4 の概要: Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-mule-message) [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-event) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-message) [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-variables) # メッセージプロパティの移行 Mule 3 には、さまざまな目的に使用できるプロパティスコープがいくつかあります。Mule 4 では、これらのスコープのほとんどが削除されました。 ## [](#呼び出しプロパティ)呼び出しプロパティ 呼び出しプロパティは、Mule 4 では ​`variables`​ と呼ばれるようになりました。動作は Mule 3 の場合とまったく同じです。 ## [](#インバウンドプロパティアウトバウンドプロパティインバウンド添付ファイルアウトバウンド添付ファイル)インバウンドプロパティ、アウトバウンドプロパティ、インバウンド添付ファイル、アウトバウンド添付ファイル これらのスコープは Mule 4 には存在しません。移行についての詳細は、​[「Mule メッセージについて」](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-mule-message)​を参照してください。 ## [](#関連情報)関連情報 [Mule 4 の概要: Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-mule-message) [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-event) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-message) [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-variables) # メッセージプロパティの移行 Mule 3 には、さまざまな目的に使用できるプロパティスコープがいくつかあります。Mule 4 では、これらのスコープのほとんどが削除されました。 ## [](#呼び出しプロパティ)呼び出しプロパティ 呼び出しプロパティは、Mule 4 では ​`variables`​ と呼ばれるようになりました。動作は Mule 3 の場合とまったく同じです。 ## [](#インバウンドプロパティアウトバウンドプロパティインバウンド添付ファイルアウトバウンド添付ファイル)インバウンドプロパティ、アウトバウンドプロパティ、インバウンド添付ファイル、アウトバウンド添付ファイル これらのスコープは Mule 4 には存在しません。移行についての詳細は、​[「Mule メッセージについて」](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-mule-message)​を参照してください。 ## [](#関連情報)関連情報 [Mule 4 の概要: Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-mule-message) [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-event) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-message) [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-variables) # メッセージプロパティの移行 Mule 3 には、さまざまな目的に使用できるプロパティスコープがいくつかあります。Mule 4 では、これらのスコープのほとんどが削除されました。 ## [](#呼び出しプロパティ)呼び出しプロパティ 呼び出しプロパティは、Mule 4 では ​`variables`​ と呼ばれるようになりました。動作は Mule 3 の場合とまったく同じです。 ## [](#インバウンドプロパティアウトバウンドプロパティインバウンド添付ファイルアウトバウンド添付ファイル)インバウンドプロパティ、アウトバウンドプロパティ、インバウンド添付ファイル、アウトバウンド添付ファイル これらのスコープは Mule 4 には存在しません。移行についての詳細は、​[「Mule メッセージについて」](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-mule-message)​を参照してください。 ## [](#関連情報)関連情報 [Mule 4 の概要: Mule メッセージ](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-mule-message) [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-event) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-message) [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-variables) # リソースのエクスポート Mule アプリケーション、Mule ドメイン、Mule ポリシーには、プロパティファイル、DataWeave 変換ファイル、Java クラスなどの一連のリソースが含まれています。 デフォルトでは、これらのすべてのファイルは、それが定義されたアーティファクト内部のものであり、他のアーティファクトからはアクセスできません。たとえば、ドメインレベルで定義されたリソースが明示的にエクスポートされなければ、その共有ドメインに属するどのアプリケーション内からもそのリソースにアクセスできません。別の例として、Java モジュールで使用されることが想定されているアプリケーションからのクラスがあります。それらのクラスがエクスポートされなければ、Java モジュールはそれらにアクセスできません。 ## [](#java-クラスのエクスポート方法)Java クラスのエクスポート方法 Java クラスをエクスポートするには、自分のアーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ 項目を使用して、これらのクラスを含む完全なパッケージをエクスポートします。クラスを個別にエクスポートすることはできません。 公開パッケージに名前を付ける場合は ​`.api.`​、非公開パッケージに名前を付ける場合は ​`.internal.`​ を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedPackages": [ "org.mule.myapp.api.customer", "org.mule.myapp.api.account" ] } } } ``` この設定では、Java クラス内部での連動関係も自動的にエクスポートされます。 ### [](#考慮事項)考慮事項 - アプリケーションが機能するのに必要な最小限の数のパッケージのみをエクスポートしてください。 そうすることで、アプリケーション内で使用する他のアーティファクト (モジュールやコネクタなど) と競合する可能性が低くなります。 - エクスポートされたパッケージに Mule アプリケーションのコンポーネントからアクセスする必要がある場合は、共有ライブラリを設定してください。 Mule で実装されているクラスローディング分離メカニズムのため、アプリケーションの連動関係が共有ライブラリとして設定されていない限り、コネクタやモジュールから連動関係にアクセスすることはできません。 ## [](#リソースファイルのエクスポート方法)リソースファイルのエクスポート方法 リソースをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedResources`​ 項目を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "/org/mule/myapp/customer-to-user.dwl", "/org/mule/myapp/beans.xml" ] } } } } ```
同じメカニズムがすべてのアーティファクトに適用されます。これには、Mule SDK を使用して開発されたカスタム拡張を含みます。
## [](#関連情報)関連情報 - [共有ライブラリ](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-classloading-isolation#shared-libraries) - [共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/mmp-concept#configure-shared-libraries) # リソースのエクスポート Mule アプリケーション、Mule ドメイン、Mule ポリシーには、プロパティファイル、DataWeave 変換ファイル、Java クラスなどの一連のリソースが含まれています。 デフォルトでは、これらのすべてのファイルは、それが定義されたアーティファクト内部のものであり、他のアーティファクトからはアクセスできません。たとえば、ドメインレベルで定義されたリソースが明示的にエクスポートされなければ、その共有ドメインに属するどのアプリケーション内からもそのリソースにアクセスできません。別の例として、Java モジュールで使用されることが想定されているアプリケーションからのクラスがあります。それらのクラスがエクスポートされなければ、Java モジュールはそれらにアクセスできません。 ## [](#java-クラスのエクスポート方法)Java クラスのエクスポート方法 Java クラスをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ 項目を使用して、これらのクラスを含む完全なパッケージをエクスポートする必要があります。クラスを個別にエクスポートすることはできません。 公開パッケージに名前を付ける場合は ​`.api.`​、非公開パッケージに名前を付ける場合は ​`.internal.`​ を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedPackages": [ "org.mule.myapp.api.customer", "org.mule.myapp.api.account" ] } } } ``` この設定では、Java クラス内部での連動関係も自動的にエクスポートされます。 ### [](#考慮事項)考慮事項 - アプリケーションが機能するのに必要な最小限の数のパッケージのみをエクスポートしてください。 そうすることで、アプリケーション内で使用する他のアーティファクト (モジュールやコネクタなど) と競合する可能性が低くなります。 - エクスポートされたパッケージに Mule アプリケーションのコンポーネントからアクセスする必要がある場合は、共有ライブラリを設定してください。 Mule で実装されているクラスローディング分離メカニズムのため、アプリケーションの連動関係が共有ライブラリとして設定されていない限り、コネクタやモジュールから連動関係にアクセスすることはできません。 ## [](#リソースファイルのエクスポート方法)リソースファイルのエクスポート方法 リソースをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedResources`​ 項目を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "/org/mule/myapp/customer-to-user.dwl", "/org/mule/myapp/beans.xml" ] } } } } ```
同じメカニズムがすべてのアーティファクトに適用されます。これには、Mule SDK を使用して開発されたカスタム拡張を含みます。
## [](#関連情報)関連情報 - [共有ライブラリ](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-classloading-isolation#shared-libraries) - [共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/mmp-concept#configure-shared-libraries) # リソースのエクスポート Mule アプリケーション、Mule ドメイン、Mule ポリシーには、プロパティファイル、DataWeave 変換ファイル、Java クラスなどの一連のリソースが含まれています。デフォルトでは、これらのすべてのファイルは、それが定義されたアーティファクト内部のものであり、他のアーティファクトからはアクセスできません。たとえば、ドメインレベルで定義されたリソースが明示的にエクスポートされなければ、その共有ドメインに属するどのアプリケーション内からもそのリソースにアクセスできません。別の例として、Java Module で使用されることが想定されているアプリケーションからのクラスがあります。それらのクラスがエクスポートされなければ、Java Module はそれらにアクセスできません。 ## [](#java-クラスのエクスポート方法)Java クラスのエクスポート方法 Java クラスをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ 項目を使用して、これらのクラスを含む完全なパッケージをエクスポートする必要があります。クラスを個別にエクスポートすることはできません。 公開パッケージに名前を付ける場合は ​`.api.`​、非公開パッケージに名前を付ける場合は ​`.internal.`​ を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedPackages": [ "org.mule.myapp.api.customer", "org.mule.myapp.api.account" ] } } } ``` この設定では、Java クラス内部での連動関係も自動的にエクスポートされます。 ### [](#考慮事項)考慮事項 - アプリケーションが機能するのに必要な最小限の数のパッケージのみをエクスポートしてください。 そうすることで、アプリケーション内で使用する他のアーティファクト (モジュールやコネクタなど) と競合する可能性が低くなります。 - エクスポートされたパッケージに Mule アプリケーションのコンポーネントからアクセスする必要がある場合は、共有ライブラリを設定してください。 Mule で実装されているクラスローディング分離メカニズムのため、アプリケーションの連動関係が共有ライブラリとして設定されていない限り、コネクタやモジュールから連動関係にアクセスすることはできません。 ## [](#リソースファイルのエクスポート方法)リソースファイルのエクスポート方法 リソースをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedResources`​ 項目を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "/org/mule/myapp/customer-to-user.dwl", "/org/mule/myapp/beans.xml" ] } } } } ```
同じメカニズムがすべてのアーティファクトに適用されます。これには、Mule SDK を使用して開発されたカスタム拡張を含みます。
## [](#関連情報)関連情報 - [共有ライブラリ](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-classloading-isolation#shared-libraries) - [共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/mmp-concept#configure-shared-libraries) # リソースのエクスポート Mule アプリケーション、Mule ドメイン、Mule ポリシーには、プロパティファイル、DataWeave 変換ファイル、Java クラスなどの一連のリソースが含まれています。 デフォルトでは、これらのすべてのファイルは、それが定義されたアーティファクト内部のものであり、他のアーティファクトからはアクセスできません。たとえば、ドメインレベルで定義されたリソースが明示的にエクスポートされなければ、その共有ドメインに属するどのアプリケーション内からもそのリソースにアクセスできません。別の例として、Java モジュールで使用されることが想定されているアプリケーションからのクラスがあります。それらのクラスがエクスポートされなければ、Java モジュールはそれらにアクセスできません。 ## [](#java-クラスのエクスポート方法)Java クラスのエクスポート方法 Java クラスをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ 項目を使用して、これらのクラスを含む完全なパッケージをエクスポートする必要があります。クラスを個別にエクスポートすることはできません。 公開パッケージに名前を付ける場合は ​`.api.`​、非公開パッケージに名前を付ける場合は ​`.internal.`​ を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedPackages": [ "org.mule.myapp.api.customer", "org.mule.myapp.api.account" ] } } } ``` この設定では、Java クラス内部での連動関係も自動的にエクスポートされます。 ### [](#考慮事項)考慮事項 - アプリケーションが機能するのに必要な最小限の数のパッケージのみをエクスポートしてください。 そうすることで、アプリケーション内で使用する他のアーティファクト (モジュールやコネクタなど) と競合する可能性が低くなります。 - エクスポートされたパッケージに Mule アプリケーションのコンポーネントからアクセスする必要がある場合は、共有ライブラリを設定してください。 Mule で実装されているクラスローディング分離メカニズムのため、アプリケーションの連動関係が共有ライブラリとして設定されていない限り、コネクタやモジュールから連動関係にアクセスすることはできません。 ## [](#リソースファイルのエクスポート方法)リソースファイルのエクスポート方法 リソースをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedResources`​ 項目を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "/org/mule/myapp/customer-to-user.dwl", "/org/mule/myapp/beans.xml" ] } } } } ```
同じメカニズムがすべてのアーティファクトに適用されます。これには、Mule SDK を使用して開発されたカスタム拡張を含みます。
## [](#関連情報)関連情報 - [共有ライブラリ](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-classloading-isolation#shared-libraries) - [共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/mmp-concept#configure-shared-libraries) # リソースのエクスポート Mule アプリケーション、Mule ドメイン、Mule ポリシーには、プロパティファイル、DataWeave 変換ファイル、Java クラスなどの一連のリソースが含まれています。 デフォルトでは、これらのすべてのファイルは、それが定義されたアーティファクト内部のものであり、他のアーティファクトからはアクセスできません。たとえば、ドメインレベルで定義されたリソースが明示的にエクスポートされなければ、その共有ドメインに属するどのアプリケーション内からもそのリソースにアクセスできません。別の例として、Java Module で使用されることが想定されているアプリケーションからのクラスがあります。それらのクラスがエクスポートされなければ、Java Module はそれらにアクセスできません。 ## [](#java-クラスのエクスポート方法)Java クラスのエクスポート方法 Java クラスをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ 項目を使用して、これらのクラスを含む完全なパッケージをエクスポートする必要があります。クラスを個別にエクスポートすることはできません。 公開パッケージに名前を付ける場合は ​`.api.`​、非公開パッケージに名前を付ける場合は ​`.internal.`​ を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedPackages": [ "org.mule.myapp.api.customer", "org.mule.myapp.api.account" ] } } } ``` この設定では、Java クラス内部での連動関係も自動的にエクスポートされます。 ### [](#考慮事項)考慮事項 - アプリケーションが機能するのに必要な最小限の数のパッケージのみをエクスポートしてください。 そうすることで、アプリケーション内で使用する他のアーティファクト (モジュールやコネクタなど) と競合する可能性が低くなります。 - エクスポートされたパッケージに Mule アプリケーションのコンポーネントからアクセスする必要がある場合は、共有ライブラリを設定してください。 Mule で実装されているクラスローディング分離メカニズムのため、アプリケーションの連動関係が共有ライブラリとして設定されていない限り、コネクタやモジュールから連動関係にアクセスすることはできません。 ## [](#リソースファイルのエクスポート方法)リソースファイルのエクスポート方法 リソースをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedResources`​ 項目を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "/org/mule/myapp/customer-to-user.dwl", "/org/mule/myapp/beans.xml" ] } } } } ```
同じメカニズムがすべてのアーティファクトに適用されます。これには、Mule SDK を使用して開発されたカスタム拡張を含みます。
## [](#関連情報)関連情報 - [共有ライブラリ](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-classloading-isolation#shared-libraries) - [共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/mmp-concept#configure-shared-libraries) # リソースのエクスポート Mule アプリケーション、Mule ドメイン、Mule ポリシーには、プロパティファイル、DataWeave 変換ファイル、Java クラスなどの一連のリソースが含まれています。 デフォルトでは、これらのすべてのファイルは、それが定義されたアーティファクト内部のものであり、他のアーティファクトからはアクセスできません。たとえば、ドメインレベルで定義されたリソースが明示的にエクスポートされなければ、その共有ドメインに属するどのアプリケーション内からもそのリソースにアクセスできません。別の例として、Java Module で使用されることが想定されているアプリケーションからのクラスがあります。それらのクラスがエクスポートされなければ、Java Module はそれらにアクセスできません。 ## [](#java-クラスのエクスポート方法)Java クラスのエクスポート方法 Java クラスをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ 項目を使用して、これらのクラスを含む完全なパッケージをエクスポートする必要があります。クラスを個別にエクスポートすることはできません。 公開パッケージに名前を付ける場合は ​`.api.`​、非公開パッケージに名前を付ける場合は ​`.internal.`​ を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedPackages": [ "org.mule.myapp.api.customer", "org.mule.myapp.api.account" ] } } } ``` この設定では、Java クラス内部での連動関係も自動的にエクスポートされます。 ### [](#考慮事項)考慮事項 - アプリケーションが機能するのに必要な最小限の数のパッケージのみをエクスポートしてください。 そうすることで、アプリケーション内で使用する他のアーティファクト (モジュールやコネクタなど) と競合する可能性が低くなります。 - エクスポートされたパッケージに Mule アプリケーションのコンポーネントからアクセスする必要がある場合は、共有ライブラリを設定してください。 Mule で実装されているクラスローディング分離メカニズムのため、アプリケーションの連動関係が共有ライブラリとして設定されていない限り、コネクタやモジュールから連動関係にアクセスすることはできません。 ## [](#リソースファイルのエクスポート方法)リソースファイルのエクスポート方法 リソースをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedResources`​ 項目を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "/org/mule/myapp/customer-to-user.dwl", "/org/mule/myapp/beans.xml" ] } } } } ```
同じメカニズムがすべてのアーティファクトに適用されます。これには、Mule SDK を使用して開発されたカスタム拡張を含みます。
## [](#関連情報)関連情報 - [共有ライブラリ](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-classloading-isolation#shared-libraries) - [共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/mmp-concept#configure-shared-libraries) # リソースのエクスポート Mule アプリケーション、Mule ドメイン、Mule ポリシーには、プロパティファイル、DataWeave 変換ファイル、Java クラスなどの一連のリソースが含まれています。 デフォルトでは、これらのすべてのファイルは、それが定義されたアーティファクト内部のものであり、他のアーティファクトからはアクセスできません。たとえば、ドメインレベルで定義されたリソースが明示的にエクスポートされなければ、その共有ドメインに属するどのアプリケーション内からもそのリソースにアクセスできません。別の例として、Java Module で使用されることが想定されているアプリケーションからのクラスがあります。それらのクラスがエクスポートされなければ、Java Module はそれらにアクセスできません。 ## [](#java-クラスのエクスポート方法)Java クラスのエクスポート方法 Java クラスをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedPackages`​ 項目を使用して、これらのクラスを含む完全なパッケージをエクスポートする必要があります。クラスを個別にエクスポートすることはできません。 公開パッケージに名前を付ける場合は ​`.api.`​、非公開パッケージに名前を付ける場合は ​`.internal.`​ を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedPackages": [ "org.mule.myapp.api.customer", "org.mule.myapp.api.account" ] } } } ``` この設定では、Java クラス内部での連動関係も自動的にエクスポートされます。 ### [](#考慮事項)考慮事項 - アプリケーションが機能するのに必要な最小限の数のパッケージのみをエクスポートしてください。 そうすることで、アプリケーション内で使用する他のアーティファクト (モジュールやコネクタなど) と競合する可能性が低くなります。 - エクスポートされたパッケージに Mule アプリケーションのコンポーネントからアクセスする必要がある場合は、共有ライブラリを設定してください。 Mule で実装されているクラスローディング分離メカニズムのため、アプリケーションの連動関係が共有ライブラリとして設定されていない限り、コネクタやモジュールから連動関係にアクセスすることはできません。 ## [](#リソースファイルのエクスポート方法)リソースファイルのエクスポート方法 リソースをエクスポートするには、アーティファクトの ​`mule-artifact.json`​ ファイルの ​`exportedResources`​ 項目を使用します。 ```json { "name": "MyApp", "minMuleVersion": "4.0.0", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [ "/org/mule/myapp/customer-to-user.dwl", "/org/mule/myapp/beans.xml" ] } } } } ```
同じメカニズムがすべてのアーティファクトに適用されます。これには、Mule SDK を使用して開発されたカスタム拡張を含みます。
## [](#関連情報)関連情報 - [共有ライブラリ](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-classloading-isolation#shared-libraries) - [共有ライブラリの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/mmp-concept#configure-shared-libraries) # ログ Mule Runtime Engine (Mule) 4 は、Log4j 2 非同期ログをデフォルトで使用するため、メッセージ処理とは別のスレッドでログ操作が実行され、ログ操作が完了するのを待たずにメッセージ処理を続行できます。 非同期ログでは、 [「Asynchronous Logging in Mule 3.6 (Mule 3.6 の非同期ログ)」](https://blogs.mulesoft.com/dev/mule-dev/mule-3-6-asynchronous-logging/)​で説明されているようにパフォーマンスと信頼性のトレードオフが発生し、ログバッファがディスクにフラッシュされる前に Mule がクラッシュした場合は一部のメッセージが失われることがあります。この場合は、非同期ロガーと同期ロガーの混在構成を検討してください。 ベストプラクティスは、本番アプリケーションでは ​`WARN`​ のログレベルを最小限に抑えて、同期ログに非同期ログを優先させて使用することです。ポリシーのインストール成功などのイベントを確認する場合や、トラブルシューティングを実施する場合などには、​`INFO`​ ログレベルを有効化します。 ログ戦略を設定するには、アプリケーションの ​`src/main/resources/log4j2.xml`​ ファイルを次の例のように編集します。 ```xml ``` - メッセージ、特にペイロードの一部をログに記録する場合は、ストリーミングがバイパスされ、大きなペイロードでは大量のディスク I/O が発生するため、注意が必要です。 - ``​ スコープを使用したメッセージのログは避けてください。 ログメカニズムはすでに Log4j2 ライブラリによってバックエンドで非同期に実装されているため、​``​ スコープにロガーを含めても並列処理は改善せず、リソースの使用量が増えて、必要なスレッド数が重複するだけです。アプリケーションでこのパターンを使用すると、スレッドの枯渇、パフォーマンスの低下、バックプレッシャーの原因となることがあります。 ```xml ``` ## [](#関連情報)関連情報 - [Logging in Mule (Mule でのログ)](https://docs.mulesoft.com/jp/mule-runtime/4.3/logging-in-mule) # ログ Mule Runtime Engine (Mule) 4 は、Log4j 2 非同期ログをデフォルトで使用するため、メッセージ処理とは別のスレッドでログ操作が実行され、ログ操作が完了するのを待たずにメッセージ処理を続行できます。 非同期ログでは、 [「Asynchronous Logging in Mule 3.6 (Mule 3.6 の非同期ログ)」](https://blogs.mulesoft.com/dev/mule-dev/mule-3-6-asynchronous-logging/)​で説明されているようにパフォーマンスと信頼性のトレードオフが発生し、ログバッファがディスクにフラッシュされる前に Mule がクラッシュした場合は一部のメッセージが失われることがあります。この場合は、非同期ロガーと同期ロガーの混在構成を検討してください。 ベストプラクティスは、本番アプリケーションでは ​`WARN`​ のログレベルを最小限に抑えて、同期ログに非同期ログを優先させて使用することです。ポリシーのインストール成功などのイベントを確認する場合や、トラブルシューティングを実施する場合などには、​`INFO`​ ログレベルを有効化します。 ログ戦略を設定するには、アプリケーションの ​`src/main/resources/log4j2.xml`​ ファイルを次の例のように編集します。 ```xml ``` - メッセージ、特にペイロードの一部をログに記録する場合は、ストリーミングがバイパスされ、大きなペイロードでは大量のディスク I/O が発生するため、注意が必要です。 - ``​ スコープを使用したメッセージのログは避けてください。 ログメカニズムはすでに Log4j2 ライブラリによってバックエンドで非同期に実装されているため、​``​ スコープにロガーを含めても並列処理は改善せず、リソースの使用量が増えて、必要なスレッド数が重複するだけです。アプリケーションでこのパターンを使用すると、スレッドの枯渇、パフォーマンスの低下、バックプレッシャーの原因となることがあります。 ```xml ``` ## [](#関連情報)関連情報 - [Logging in Mule (Mule でのログ)](https://docs.mulesoft.com/jp/mule-runtime/4.4/logging-in-mule) # ログ Mule Runtime Engine (Mule) 4 は、Log4j 2 非同期ログをデフォルトで使用するため、メッセージ処理とは別のスレッドでログ操作が実行され、ログ操作が完了するのを待たずにメッセージ処理を続行できます。 非同期ログでは、 [「Asynchronous Logging in Mule 3.6 (Mule 3.6 の非同期ログ)」](https://blogs.mulesoft.com/dev/mule-dev/mule-3-6-asynchronous-logging/)​で説明されているようにパフォーマンスと信頼性のトレードオフが発生し、ログバッファがディスクにフラッシュされる前に Mule がクラッシュした場合は一部のメッセージが失われることがあります。この場合は、非同期ロガーと同期ロガーの混在構成を検討してください。 ベストプラクティスは、本番アプリケーションでは ​`WARN`​ のログレベルを最小限に抑えて、同期ログに非同期ログを優先させて使用することです。ポリシーのインストール成功などのイベントを確認する場合や、トラブルシューティングを実施する場合などには、​`INFO`​ ログレベルを有効化します。 ログ戦略を設定するには、アプリケーションの ​`src/main/resources/log4j2.xml`​ ファイルを次の例のように編集します。 ```xml ``` - メッセージ、特にペイロードの一部をログに記録する場合は、ストリーミングがバイパスされ、大きなペイロードでは大量のディスク I/O が発生するため、注意が必要です。 - ``​ スコープを使用したメッセージのログは避けてください。 ログメカニズムはすでに Log4j2 ライブラリによってバックエンドで非同期に実装されているため、​``​ スコープにロガーを含めても並列処理は改善せず、リソースの使用量が増えて、必要なスレッド数が重複するだけです。アプリケーションでこのパターンを使用すると、スレッドの枯渇、パフォーマンスの低下、バックプレッシャーの原因となることがあります。 ```xml ``` ## [](#関連情報)関連情報 - [Logging in Mule (Mule でのログ)](https://docs.mulesoft.com/jp/mule-runtime/4.5/logging-in-mule) # ログ Mule Runtime Engine (Mule) 4 は、Log4j 2 非同期ログをデフォルトで使用するため、メッセージ処理とは別のスレッドでログ操作が実行され、ログ操作が完了するのを待たずにメッセージ処理を続行できます。 非同期ログでは、 [「Asynchronous Logging in Mule 3.6 (Mule 3.6 の非同期ログ)」](https://blogs.mulesoft.com/dev/mule-dev/mule-3-6-asynchronous-logging/)​で説明されているようにパフォーマンスと信頼性のトレードオフが発生し、ログバッファがディスクにフラッシュされる前に Mule がクラッシュした場合は一部のメッセージが失われることがあります。この場合は、非同期ロガーと同期ロガーの混在構成を検討してください。 ベストプラクティスは、本番アプリケーションでは ​`WARN`​ のログレベルを最小限に抑えて、同期ログに非同期ログを優先させて使用することです。ポリシーのインストール成功などのイベントを確認する場合や、トラブルシューティングを実施する場合などには、​`INFO`​ ログレベルを有効化します。 ログ戦略を設定するには、アプリケーションの ​`src/main/resources/log4j2.xml`​ ファイルを次の例のように編集します。 ```xml ``` - メッセージ、特にペイロードの一部をログに記録する場合は、ストリーミングがバイパスされ、大きなペイロードでは大量のディスク I/O が発生するため、注意が必要です。 - ``​ スコープを使用したメッセージのログは避けてください。 ログメカニズムはすでに Log4j2 ライブラリによってバックエンドで非同期に実装されているため、​``​ スコープにロガーを含めても並列処理は改善せず、リソースの使用量が増えて、必要なスレッド数が重複するだけです。アプリケーションでこのパターンを使用すると、スレッドの枯渇、パフォーマンスの低下、バックプレッシャーの原因となることがあります。 ```xml ``` ## [](#関連情報)関連情報 - [Logging in Mule (Mule でのログ)](https://docs.mulesoft.com/jp/mule-runtime/4.6/logging-in-mule) # ログ Mule Runtime Engine (Mule) 4 は、Log4j 2 非同期ログをデフォルトで使用するため、メッセージ処理とは別のスレッドでログ操作が実行され、ログ操作が完了するのを待たずにメッセージ処理を続行できます。 非同期ログでは、 [「Asynchronous Logging in Mule 3.6 (Mule 3.6 の非同期ログ)」](https://blogs.mulesoft.com/dev/mule-dev/mule-3-6-asynchronous-logging/)​で説明されているようにパフォーマンスと信頼性のトレードオフが発生し、ログバッファがディスクにフラッシュされる前に Mule がクラッシュした場合は一部のメッセージが失われることがあります。この場合は、非同期ロガーと同期ロガーの混在構成を検討してください。 ベストプラクティスは、本番アプリケーションでは ​`WARN`​ のログレベルを最小限に抑えて、同期ログに非同期ログを優先させて使用することです。ポリシーのインストール成功などのイベントを確認する場合や、トラブルシューティングを実施する場合などには、​`INFO`​ ログレベルを有効化します。 ログ戦略を設定するには、アプリケーションの ​`src/main/resources/log4j2.xml`​ ファイルを次の例のように編集します。 ```xml ``` - メッセージ、特にペイロードの一部をログに記録する場合は、ストリーミングがバイパスされ、大きなペイロードでは大量のディスク I/O が発生するため、注意が必要です。 - ``​ スコープを使用したメッセージのログは避けてください。 ログメカニズムはすでに Log4j2 ライブラリによってバックエンドで非同期に実装されているため、​``​ スコープにロガーを含めても並列処理は改善せず、リソースの使用量が増えて、必要なスレッド数が重複するだけです。アプリケーションでこのパターンを使用すると、スレッドの枯渇、パフォーマンスの低下、バックプレッシャーの原因となることがあります。 ```xml ``` ## [](#関連情報)関連情報 - [Logging in Mule (Mule でのログ)](https://docs.mulesoft.com/jp/mule-runtime/4.7/logging-in-mule) # ログ Mule Runtime Engine (Mule) 4 は、Log4j 2 非同期ログをデフォルトで使用するため、メッセージ処理とは別のスレッドでログ操作が実行され、ログ操作が完了するのを待たずにメッセージ処理を続行できます。 非同期ログでは、 [「Asynchronous Logging in Mule 3.6 (Mule 3.6 の非同期ログ)」](https://blogs.mulesoft.com/dev/mule-dev/mule-3-6-asynchronous-logging/)​で説明されているようにパフォーマンスと信頼性のトレードオフが発生し、ログバッファがディスクにフラッシュされる前に Mule がクラッシュした場合は一部のメッセージが失われることがあります。この場合は、非同期ロガーと同期ロガーの混在構成を検討してください。 ベストプラクティスは、本番アプリケーションでは ​`WARN`​ のログレベルを最小限に抑えて、同期ログに非同期ログを優先させて使用することです。ポリシーのインストール成功などのイベントを確認する場合や、トラブルシューティングを実施する場合などには、​`INFO`​ ログレベルを有効化します。 ログ戦略を設定するには、アプリケーションの ​`src/main/resources/log4j2.xml`​ ファイルを次の例のように編集します。 ```xml ``` - メッセージ、特にペイロードの一部をログに記録する場合は、ストリーミングがバイパスされ、大きなペイロードでは大量のディスク I/O が発生するため、注意が必要です。 - ``​ スコープを使用したメッセージのログは避けてください。 ログメカニズムはすでに Log4j2 ライブラリによってバックエンドで非同期に実装されているため、​``​ スコープにロガーを含めても並列処理は改善せず、リソースの使用量が増えて、必要なスレッド数が重複するだけです。アプリケーションでこのパターンを使用すると、スレッドの枯渇、パフォーマンスの低下、バックプレッシャーの原因となることがあります。 ```xml ``` ## [](#関連情報)関連情報 - [Logging in Mule (Mule でのログ)](https://docs.mulesoft.com/jp/mule-runtime/4.8/logging-in-mule) # ログ Mule Runtime Engine (Mule) 4 は、Log4j 2 非同期ログをデフォルトで使用するため、メッセージ処理とは別のスレッドでログ操作が実行され、ログ操作が完了するのを待たずにメッセージ処理を続行できます。 非同期ログでは、 [「Asynchronous Logging in Mule 3.6 (Mule 3.6 の非同期ログ)」](https://blogs.mulesoft.com/dev/mule-dev/mule-3-6-asynchronous-logging/)​で説明されているようにパフォーマンスと信頼性のトレードオフが発生し、ログバッファがディスクにフラッシュされる前に Mule がクラッシュした場合は一部のメッセージが失われることがあります。この場合は、非同期ロガーと同期ロガーの混在構成を検討してください。 ベストプラクティスは、本番アプリケーションでは ​`WARN`​ のログレベルを最小限に抑えて、同期ログに非同期ログを優先させて使用することです。ポリシーのインストール成功などのイベントを確認する場合や、トラブルシューティングを実施する場合などには、​`INFO`​ ログレベルを有効化します。 ログ戦略を設定するには、アプリケーションの ​`src/main/resources/log4j2.xml`​ ファイルを次の例のように編集します。 ```xml ``` - メッセージ、特にペイロードの一部をログに記録する場合は、ストリーミングがバイパスされ、大きなペイロードでは大量のディスク I/O が発生するため、注意が必要です。 - ``​ スコープを使用したメッセージのログは避けてください。 ログメカニズムはすでに Log4j2 ライブラリによってバックエンドで非同期に実装されているため、​``​ スコープにロガーを含めても並列処理は改善せず、リソースの使用量が増えて、必要なスレッド数が重複するだけです。アプリケーションでこのパターンを使用すると、スレッドの枯渇、パフォーマンスの低下、バックプレッシャーの原因となることがあります。 ```xml ``` ## [](#関連情報)関連情報 - [Logging in Mule (Mule でのログ)](https://docs.mulesoft.com/jp/mule-runtime/4.9/logging-in-mule) # ログおよびデバッグ MuleSoft は、Mule アプリケーション用のさまざまなログオプションとデバッグオプションを提供します。 アプリケーションログとランタイムログは、アプリケーションと Mule サーバーの監視とトラブルシューティングに役立ちます。詳細は、​[「ログの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.3/logging-in-mule)​を参照してください。 コネクタやモジュールで​[冗長ログを有効化](https://docs.mulesoft.com/jp/mule-runtime/4.3/enable-verbose-logging)​することで、デバッグレベルの情報をログに記録できます。 Logger コンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグすることもできます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。詳細は、コアコンポーネントのドキュメントの​[「Logger コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.3/logger-component-reference)​を参照してください。 Mule スタック追跡の表示を制御するには、コマンドライン引数を使用するか、Anypoint Studio でプロパティを設定することができます。詳細は、​[「Mule スタック追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-mule-stacktraces)​を参照してください。 Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。詳細は、​[「Studio 外でのデバッグ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/debugging-outside-studio)​を参照してください。 Mule アプリケーションを CloudHub で実行している場合は、​[「ログデータの表示」](https://docs.mulesoft.com/cloudhub/viewing-log-data)​を参照して、ログデータと永続性についての詳細を確認してください。 # ログおよびデバッグ MuleSoft は、Mule アプリケーション用のさまざまなログオプションとデバッグオプションを提供します。 アプリケーションログとランタイムログは、アプリケーションと Mule サーバーの監視とトラブルシューティングに役立ちます。詳細は、​[「ログの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.4/logging-in-mule)​を参照してください。 コネクタやモジュールで​[冗長ログを有効化](https://docs.mulesoft.com/jp/mule-runtime/4.4/enable-verbose-logging)​することで、デバッグレベルの情報をログに記録できます。 Logger コンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグすることもできます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。詳細は、コアコンポーネントのドキュメントの​[「Logger コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.4/logger-component-reference)​を参照してください。 Mule スタック追跡の表示を制御するには、コマンドライン引数を使用するか、Anypoint Studio でプロパティを設定することができます。詳細は、​[「Mule スタック追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-mule-stacktraces)​を参照してください。 Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。詳細は、​[「Studio 外でのデバッグ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/debugging-outside-studio)​を参照してください。 Mule アプリケーションを CloudHub で実行している場合は、​[「ログデータの表示」](https://docs.mulesoft.com/cloudhub/viewing-log-data)​を参照して、ログデータと永続性についての詳細を確認してください。 # ログおよびデバッグ MuleSoft は、Mule アプリケーション用のさまざまなログオプションとデバッグオプションを提供します。 アプリケーションログとランタイムログは、アプリケーションと Mule サーバーの監視とトラブルシューティングに役立ちます。詳細は、​[「ログの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.5/logging-in-mule)​を参照してください。 コネクタやモジュールで​[冗長ログを有効化](https://docs.mulesoft.com/jp/mule-runtime/4.5/enable-verbose-logging)​することで、デバッグレベルの情報をログに記録できます。 Logger コンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグすることもできます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。詳細は、コアコンポーネントのドキュメントの​[「Logger コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.5/logger-component-reference)​を参照してください。 Mule スタック追跡の表示を制御するには、コマンドライン引数を使用するか、Anypoint Studio でプロパティを設定することができます。詳細は、​[「Mule スタック追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-mule-stacktraces)​を参照してください。 Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。詳細は、​[「Studio 外でのデバッグ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/debugging-outside-studio)​を参照してください。 Mule アプリケーションを CloudHub で実行している場合は、​[「ログデータの表示」](https://docs.mulesoft.com/cloudhub/viewing-log-data)​を参照して、ログデータと永続性についての詳細を確認してください。 # ログおよびデバッグ MuleSoft は、Mule アプリケーション用のさまざまなログオプションとデバッグオプションを提供します。 アプリケーションログとランタイムログは、アプリケーションと Mule サーバーの監視とトラブルシューティングに役立ちます。詳細は、​[「ログの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.6/logging-in-mule)​を参照してください。 コネクタやモジュールで​[冗長ログを有効化](https://docs.mulesoft.com/jp/mule-runtime/4.6/enable-verbose-logging)​することで、デバッグレベルの情報をログに記録できます。 Logger コンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグすることもできます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。詳細は、コアコンポーネントのドキュメントの​[「Logger コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.6/logger-component-reference)​を参照してください。 Mule スタック追跡の表示を制御するには、コマンドライン引数を使用するか、Anypoint Studio でプロパティを設定することができます。詳細は、​[「Mule スタック追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-mule-stacktraces)​を参照してください。 Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。詳細は、​[「Studio 外でのデバッグ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/debugging-outside-studio)​を参照してください。 Mule アプリケーションを CloudHub で実行している場合は、​[「ログデータの表示」](https://docs.mulesoft.com/cloudhub/viewing-log-data)​を参照して、ログデータと永続性についての詳細を確認してください。 # ログおよびデバッグ MuleSoft は、Mule アプリケーション用のさまざまなログオプションとデバッグオプションを提供します。 アプリケーションログとランタイムログは、アプリケーションと Mule サーバーの監視とトラブルシューティングに役立ちます。詳細は、​[「ログの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.7/logging-in-mule)​を参照してください。 コネクタやモジュールで​[冗長ログを有効化](https://docs.mulesoft.com/jp/mule-runtime/4.7/enable-verbose-logging)​することで、デバッグレベルの情報をログに記録できます。 Logger コンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグすることもできます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。詳細は、コアコンポーネントのドキュメントの​[「Logger コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.7/logger-component-reference)​を参照してください。 Mule スタック追跡の表示を制御するには、コマンドライン引数を使用するか、Anypoint Studio でプロパティを設定することができます。詳細は、​[「Mule スタック追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-mule-stacktraces)​を参照してください。 Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。詳細は、​[「Studio 外でのデバッグ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/debugging-outside-studio)​を参照してください。 Mule アプリケーションを CloudHub で実行している場合は、​[「ログデータの表示」](https://docs.mulesoft.com/cloudhub/viewing-log-data)​を参照して、ログデータと永続性についての詳細を確認してください。 # ログおよびデバッグ MuleSoft は、Mule アプリケーション用のさまざまなログオプションとデバッグオプションを提供します。 アプリケーションログとランタイムログは、アプリケーションと Mule サーバーの監視とトラブルシューティングに役立ちます。詳細は、​[「ログの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.8/logging-in-mule)​を参照してください。 コネクタやモジュールで​[冗長ログを有効化](https://docs.mulesoft.com/jp/mule-runtime/4.8/enable-verbose-logging)​することで、デバッグレベルの情報をログに記録できます。 Logger コンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグすることもできます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。詳細は、コアコンポーネントのドキュメントの​[「Logger コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.8/logger-component-reference)​を参照してください。 Mule スタック追跡の表示を制御するには、コマンドライン引数を使用するか、Anypoint Studio でプロパティを設定することができます。詳細は、​[「Mule スタック追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-mule-stacktraces)​を参照してください。 Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。詳細は、​[「Studio 外でのデバッグ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/debugging-outside-studio)​を参照してください。 Mule アプリケーションを CloudHub で実行している場合は、​[「ログデータの表示」](https://docs.mulesoft.com/cloudhub/viewing-log-data)​を参照して、ログデータと永続性についての詳細を確認してください。 # ログおよびデバッグ MuleSoft は、Mule アプリケーション用のさまざまなログオプションとデバッグオプションを提供します。 アプリケーションログとランタイムログは、アプリケーションと Mule サーバーの監視とトラブルシューティングに役立ちます。詳細は、​[「ログの設定」](https://docs.mulesoft.com/jp/mule-runtime/4.9/logging-in-mule)​を参照してください。 コネクタやモジュールで​[冗長ログを有効化](https://docs.mulesoft.com/jp/mule-runtime/4.9/enable-verbose-logging)​することで、デバッグレベルの情報をログに記録できます。 Logger コンポーネントでは、エラーメッセージ、状況通知、ペイロードなどの重要な情報をログに記録するというやり方で、Mule アプリケーションを監視し、デバッグすることもできます。Logger はフローの任意の場所に追加でき、各自が指定した文字列、記述した DataWeave 式の出力、文字列と式の組み合わせをログに記録するように設定できます。詳細は、コアコンポーネントのドキュメントの​[「Logger コンポーネント」](https://docs.mulesoft.com/jp/mule-runtime/4.9/logger-component-reference)​を参照してください。 Mule スタック追跡の表示を制御するには、コマンドライン引数を使用するか、Anypoint Studio でプロパティを設定することができます。詳細は、​[「Mule スタック追跡の設定」](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-mule-stacktraces)​を参照してください。 Anypoint Studio で Mule アプリケーションのトラブルシューティングを行うには、​[Studio ビジュアルデバッガー](https://docs.mulesoft.com/studio/visual-debugger-concept)​を使用できます。これを使用すると、ブレークポイントを設定して実行を停止し、イベントを確認できます。Studio 外で Mule アプリケーションを作成する場合は、MUnit を使用してアプリケーションをテストするか、リモートデバッグをアクティブ化することができます。詳細は、​[「Studio 外でのデバッグ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/debugging-outside-studio)​を参照してください。 Mule アプリケーションを CloudHub で実行している場合は、​[「ログデータの表示」](https://docs.mulesoft.com/cloudhub/viewing-log-data)​を参照して、ログデータと永続性についての詳細を確認してください。 # ログの設定 MuleSoft は、Mule アプリケーションと Mule インスタンスの監視とトラブルシューティングに役立つアプリケーションログとランタイムログを提供します。 ## [](#アプリケーションログ)アプリケーションログ Studio でビルドするすべてのアプリケーションに、その独自の ​`log4j2.xml`​ ファイルが付属します。ログにはアプリケーションで発生したエラーに関する情報が含まれます (ただし、このエラーを処理するアプリケーションロジックがある場合を除く)。また、アプリケーション内でロジックをビルドした場合は、ログに明示的に記録する必要がある情報も含まれます。 Mule は、イベントのデバッグと追跡に役立つようにアプリケーションフロー内のいくつかのメッセージと特定の要素を自動的に記録します。また、​[Logger コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/logger-component-reference)​をフローの任意の場所に含めて、必要なメッセージを出力するようにセットアップすることもできます。 アプリケーションログは次の方法で表示できます。 - アプリケーションを Anypoint Studio から実行している場合、アプリケーションログからの出力は Anypoint Studio のコンソールウィンドウに表示されます。 - コマンドラインから Mule を使用してアプリケーションを実行している場合、アプリケーションログは OS コンソールに表示されます。 デフォルトでは、アプリケーションログファイルは ​`MULE_HOME/logs/.log`​ に保存されます。このログファイルのパスは Mule アプリケーションの ​`log4j2.xml`​ ファイルでカスタマイズできます。 ## [](#ランタイムログ)ランタイムログ ランタイムログ (​`mule_ee.log`​) にはアプリケーションとライフサイクルイベントに関する情報が含まれます。たとえば、Mule サービスまたはアプリケーションの開始、デプロイ、停止、またはアンデプロイ時にログにエントリが記録されます。 ランタイムログの設定は ​`/conf`​ ディレクトリの ​`log4j2.xml`​ ファイルに保存されます。このファイルは、オンプレミスで Mule を実行している場合にカスタマイズできます。 ### [](#anypoint-studio-でランタイムログを表示する)Anypoint Studio でランタイムログを表示する **\[Anypoint Studio\] > \[About Anypoint Studio (Anypoint Studio について)\] > \[Installation Details (インストールの詳細)\] > \[Configuration (設定)\] をクリックし、\[View Error Log (エラーログを表示)\]**​ をクリックします。 ![エラーログを表示](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/logging-in-mule-view-error-log.png) ### [](#ログレベルの変更)ログレベルの変更 `log4j2.xml`​ ファイルで次のパッケージの ​`level`​ 値を変更することで、ランタイムログのレベルを変更できます。 ```xml ``` 使用可能な値は、​`DEBUG`​、​`ERROR`​、​`INFO`​、​`TRACE`​、​`WARN`​ です。 特定のコネクタのログレベルのみを変更する場合は、​[「冗長ログの有効化」](https://docs.mulesoft.com/jp/mule-runtime/4.3/enable-verbose-logging)​を参照してください。 ## [](#ログの設定)ログの設定 設定ファイルを作成し、次の設定を定義できます。 - 記録するメッセージの種類 - メッセージの記録方法 (非同期または同期) - メッセージの記録場所 (コンソールまたはディスク、エンドポイントまたはデータベースなど) Mule は ​`slf4j`​ を使用します。これは、Apache Log4j 2 や JDK ロガーなど、クラスパスからログ戦略を検出して使用するログファサードです。デフォルトでは、Mule には Log4j 2 が含まれます。これは、​`log4j2.xml`​ というファイルで設定されます。 ## [](#同期ログと非同期ログの比較)同期ログと非同期ログの比較 デフォルトでは、Mule はメッセージを非同期で記録します。ログを同期的に記録すると、メッセージを処理しているスレッドの実行が中断し、ログメッセージが完全に処理されるまで待機した後、メッセージの処理を続行できます。 ![logger synch](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/logger-synch.png) ログを非同期的に記録すると、ログ記録の操作は個別のスレッドで実行されるため、ログ記録が完了する前にメッセージを処理できます。 ![logger asynch alternativo](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/logger-asynch-alternativo.png) MuleSoft は、ほとんどの状況で​**非同期ログ**​を使用することをお勧めします。大幅にスループットが向上し、メッセージ処理のレイテンシーが短縮されるためです。 非同期ログを使用すると、システムクラッシュが発生した場合にいくつかのアクションが記録されない可能性があります。この状況は、他のアクションとは無関係に動作する別のスレッドでログの書き込みが実行されるために発生します。この問題を緩和する方法についての詳細は、​[「非同期ログでの例外処理」](#exception_handling)​を参照してください。 アプリケーションログを監査履歴として使用する場合は、必ず​**同期**​ログを使用するようにアプリケーションを設定してください。これにより、ログメッセージの損失が防止されます。
Mule 4 では、log4j のメモリ使用量を最適化するためにスレッドローカル機能が導入されています。この機能を使用しやすくするために、システムプロパティ ​AsyncLoggerConfig.RingBufferSize​ を設定できます (​「プロパティの設定」​を参照)。 20000​ が推奨値ですが、ニーズに合わせて調整する必要があります。
### [](#パフォーマンステスト)パフォーマンステスト 以下のチャートは、同期ログと非同期ログのパフォーマンスの違いと、同時メッセージ数の増加に応じてレイテンシーがどの程度増加したかを示しています。このテストでは、各実行で使用するスレッドの量を増加しながら、アプリケーションで約 100 万件のメッセージをログに記録しました。各トランザクションの結果、1,000 件のメッセージが生成されました。 ![logging latency vs concurrency](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/logging-latency-vs-concurrency.png) このチャートで示されているように、非同期でログを記録した場合の結果は、ログを記録しない場合の結果に非常に近くなりました。 ## [](#カスタムログの設定)カスタムログの設定 デフォルトでは、Mule では、ログは非同期の方法で INFO 以上のレベルで記録されます。デフォルトのログレベルでは、DEBUG または TRACE レベルのログメッセージは破棄されます。 同期ログを使用するには、ログレベルを調整するか、カスタムカテゴリを定義します。これらのプロパティは、ロガーの動作を指定する ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを使用して設定できます。このファイルを編集しない場合、Mule はデフォルトのプロパティを使用します。 Anypoint Studio では、​`log4j2.xml`​ は各 Mule オブジェクトの ​`src/main/resources`​ パスに含まれます。 デフォルト設定では、すべてのロガー (ルートロガーを含む) が非同期として定義されます。この設定はドメインまたはアプリケーションレベルで上書きできます。この設定をアプリケーションレベルで上書きするには、​`logConfigFile`​ エントリを ​`mule-artifact.json`​ ファイルに追加します。例: ```json { "minMuleVersion": "4.0.0", "logConfigFile": "../../../test-classes/resources/logging/custom-log4j2.xml" } ``` `log4j2.xml`​ ファイルのデフォルト設定を次に示します。 ```xml ``` ## [](#runtime-manager-エージェントのログの設定)Runtime Manager エージェントのログの設定
この設定は、Runtime Manager エージェント 1.5.2 以降を使用している場合のみ有効です。
Runtime Manager エージェントの状態をデフォルトの ​`mule_agent.log`​ ファイル以外の場所に記録するには、​`mule-agent-appender`​ という新しい Log4j 2 アペンダーを含めるように ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを設定します。含まれている場合、Runtime Manager エージェントプラグインはこのアペンダーを使用して状態を記録します。 この機能を有効にするには、​`log4j2.xml`​ ファイルに次のようなスニペットが含まれている必要があります。 ```xml (...) %d %p %c{1.} [%t] %m%n (...) ``` 上の例を使用すると、Runtime Manager エージェントはその状態を ​`$MULE_HOME/logs/custom_mule_agent.log`​ 内のローリングログファイルに記録します。このファイルは、250MB サイズに達するまで毎日繰り越されます。 他の Log4j 2 アペンダー設定については、Apache Log4j 2 のドキュメントを参照してください。 ## [](#exception_handling)非同期ログでの例外処理 非同期ログを使用していて、不完全なログが生成される可能性があるシステムクラッシュが発生した場合、LMAX ​`ExceptionHandler`​ ハンドラーが役立つ可能性があります。デフォルトでは、Mule はこのハンドラーを登録し、イベントをディスク、コンソール、および ​`logs/mule_ee.log`​ に記録します。独自の例外ハンドラーを提供するには、システムプロパティ ​`AsyncLoggerConfig.ExceptionHandler`​ を、インターフェースを実装するクラスの正規名に設定します。 デフォルトの例外ハンドラーを以下に示します。 ```java /* * Copyright (c) MuleSoft, Inc. All rights reserved. http://www.mulesoft.com * The software in this package is published under the terms of the CPAL v1.0 * license, a copy of which has been included with this distribution in the * LICENSE.txt file. */ package org.mule.runtime.module.launcher.api.log4j2; import com.lmax.disruptor.ExceptionHandler; import org.apache.logging.log4j.status.StatusLogger; /** * Implementation of {@link com.lmax.disruptor.ExceptionHandler} to be used when async loggers fail to log their messages. It will * log this event using the {@link org.apache.logging.log4j.status.StatusLogger} * * @since 3.6.0 */ public class AsyncLoggerExceptionHandler implements ExceptionHandler { private static final StatusLogger LOGGER = StatusLogger.getLogger(); @Override public void handleEventException(Throwable ex, long sequence, Object event) { LOGGER.error("Failed to asynchronously log message: " + event, ex); } @Override public void handleOnStartException(Throwable ex) { LOGGER.error("Failed to start asynchronous logger", ex); } @Override public void handleOnShutdownException(Throwable ex) { LOGGER.error("Failed to stop asynchronous logger", ex); } } ``` 非同期ログと同期ログの間には、パフォーマンスと信頼性のトレードオフがあります。ログメッセージの損失のリスクが重大な問題になる場合、ロガーを同期として設定します。同期ログと非同期ログの両方を組み合わせることができます。 ## [](#設定の再読み込み)設定の再読み込み Mule Runtime はログのフレームワークとして Log4j 2 を使用します。変更の有無を Log4j 2 で確認する監視間隔を追加または変更するには、​`monitorInterval`​ を ​`log4j2.xml`​ 設定ファイルに追加します。 1. Mule インストールフォルダーで ​`conf/log4j2.xml`​ を開きます。 2. 1 行目の後に ​``​ を追加します。例: ```xml ... ``` この例では、Log4j 2 は変更の有無を 15 秒ごとに確認します。 3. ファイルを保存して、Mule サーバーを再起動します。 詳細は、Log4j 2 の自動設定に関する Apache のドキュメントを参照してください。 ## [](#http-connector-を使用するプロジェクトのデバッグ)HTTP Connector を使用するプロジェクトのデバッグ HTTP Connector を使用するプロジェクトをデバッグするには、通常よりも詳細なログを記録し、プロジェクトでの HTTP Connector の ​`http-listener`​ および ​`http-request`​ 操作の動作をすべて追跡することをお勧めします。詳細は、​[『HTTP Connector トラブルシューティングガイド』](#connectors::http/http-troubleshooting.adoc)​を参照してください。 ## [](#soap-の要求および応答のログ)SOAP の要求および応答のログ 1. `src/main/resources`​ で ​`log4j2.xml`​ ファイルを開き、​`HttpMessageLogger`​ を設定に追加します。 ```xml ``` 2. プロジェクトを保存します。 ## [](#ログのトラブルシューティング)ログのトラブルシューティング ログ出力が表示されません クラスパスのルートで ​`log4j2.xml`​ を設定します。 Log4j 2 を再設定しましたが何も起こりません この問題は、別の ​`log4j2.xml`​ ファイルがクラスパスに存在し、変更前にそのファイルが選択されているために発生します。Log4j 2 がどの設定ファイルを使用しているかを確認するには、Mule の開始時に次のスイッチを追加します (または Mule を埋め込んでいる場合はコンテナの起動スクリプトに追加します)。 \-M-Dlog4j.debug=true このスイッチにより、使用されている設定ファイルの場所を含め、Log4j 2 の起動情報が ​`stdout`​ に書き込まれます。変更した設定を機能させる前に、この設定ファイルを削除する必要があります。 # ログの設定 MuleSoft は、Mule アプリケーションと Mule インスタンスの監視とトラブルシューティングに役立つアプリケーションログとランタイムログを提供します。 ## [](#アプリケーションログ)アプリケーションログ Studio でビルドするすべてのアプリケーションに、その独自の ​`log4j2.xml`​ ファイルが付属します。ログにはアプリケーションで発生したエラーに関する情報が含まれます (ただし、このエラーを処理するアプリケーションロジックがある場合を除く)。また、アプリケーション内でロジックをビルドした場合は、ログに明示的に記録する必要がある情報も含まれます。 Mule は、イベントのデバッグと追跡に役立つようにアプリケーションフロー内のいくつかのメッセージと特定の要素を自動的に記録します。また、​[Logger コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/logger-component-reference)​をフローの任意の場所に含めて、必要なメッセージを出力するようにセットアップすることもできます。 アプリケーションログは次の方法で表示できます。 - アプリケーションを Anypoint Studio から実行している場合、アプリケーションログからの出力は Anypoint Studio のコンソールウィンドウに表示されます。 - コマンドラインから Mule を使用してアプリケーションを実行している場合、アプリケーションログは OS コンソールに表示されます。 デフォルトでは、アプリケーションログファイルは ​`MULE_HOME/logs/.log`​ に保存されます。このログファイルのパスは Mule アプリケーションの ​`log4j2.xml`​ ファイルでカスタマイズできます。 ## [](#ランタイムログ)ランタイムログ ランタイムログ (​`mule_ee.log`​) にはアプリケーションとライフサイクルイベントに関する情報が含まれます。たとえば、Mule サービスまたはアプリケーションの開始、デプロイ、停止、またはアンデプロイ時にログにエントリが記録されます。 ランタイムログの設定は ​`/conf`​ ディレクトリの ​`log4j2.xml`​ ファイルに保存されます。このファイルは、オンプレミスで Mule を実行している場合にカスタマイズできます。 ### [](#anypoint-studio-でランタイムログを表示する)Anypoint Studio でランタイムログを表示する **\[Anypoint Studio\] > \[About Anypoint Studio (Anypoint Studio について)\] > \[Installation Details (インストールの詳細)\] > \[Configuration (設定)\] をクリックし、\[View Error Log (エラーログを表示)\]**​ をクリックします。 ![エラーログを表示](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/logging-in-mule-view-error-log.png) ### [](#ログレベルの変更)ログレベルの変更 `log4j2.xml`​ ファイルで次のパッケージの ​`level`​ 値を変更することで、ランタイムログのレベルを変更できます。 ```xml ``` 使用可能な値は、​`DEBUG`​、​`ERROR`​、​`INFO`​、​`TRACE`​、​`WARN`​ です。 特定のコネクタのログレベルのみを変更する場合は、​[「冗長ログの有効化」](https://docs.mulesoft.com/jp/mule-runtime/4.4/enable-verbose-logging)​を参照してください。 ## [](#ログの設定)ログの設定 設定ファイルを作成し、次の設定を定義できます。 - 記録するメッセージの種類 - メッセージの記録方法 (非同期または同期) - メッセージの記録場所 (コンソールまたはディスク、エンドポイントまたはデータベースなど) Mule は ​`slf4j`​ を使用します。これは、Apache Log4j 2 や JDK ロガーなど、クラスパスからログ戦略を検出して使用するログファサードです。デフォルトでは、Mule には Log4j 2 が含まれます。これは、​`log4j2.xml`​ というファイルで設定されます。 ## [](#同期ログと非同期ログの比較)同期ログと非同期ログの比較 デフォルトでは、Mule はメッセージを非同期で記録します。ログを同期的に記録すると、メッセージを処理しているスレッドの実行が中断し、ログメッセージが完全に処理されるまで待機した後、メッセージの処理を続行できます。 ![logger synch](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/logger-synch.png) ログを非同期的に記録すると、ログ記録の操作は個別のスレッドで実行されるため、ログ記録が完了する前にメッセージを処理できます。 ![logger asynch alternativo](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/logger-asynch-alternativo.png) MuleSoft は、ほとんどの状況で​**非同期ログ**​を使用することをお勧めします。大幅にスループットが向上し、メッセージ処理のレイテンシーが短縮されるためです。 非同期ログを使用すると、システムクラッシュが発生した場合にいくつかのアクションが記録されない可能性があります。この状況は、他のアクションとは無関係に動作する別のスレッドでログの書き込みが実行されるために発生します。この問題を緩和する方法についての詳細は、​[「非同期ログでの例外処理」](#exception_handling)​を参照してください。 アプリケーションログを監査履歴として使用する場合は、必ず​**同期**​ログを使用するようにアプリケーションを設定してください。これにより、ログメッセージの損失が防止されます。
Mule 4 では、log4j のメモリ使用量を最適化するためにスレッドローカル機能が導入されています。この機能を使用しやすくするために、システムプロパティ ​AsyncLoggerConfig.RingBufferSize​ を設定できます (​「プロパティの設定」​を参照)。 20000​ が推奨値ですが、ニーズに合わせて調整する必要があります。
### [](#パフォーマンステスト)パフォーマンステスト 以下のチャートは、同期ログと非同期ログのパフォーマンスの違いと、同時メッセージ数の増加に応じてレイテンシーがどの程度増加したかを示しています。このテストでは、各実行で使用するスレッドの量を増加しながら、アプリケーションで約 100 万件のメッセージをログに記録しました。各トランザクションの結果、1,000 件のメッセージが生成されました。 ![logging latency vs concurrency](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/logging-latency-vs-concurrency.png) このチャートで示されているように、非同期でログを記録した場合の結果は、ログを記録しない場合の結果に非常に近くなりました。 ## [](#カスタムログの設定)カスタムログの設定 デフォルトでは、Mule では、ログは非同期の方法で INFO 以上のレベルで記録されます。デフォルトのログレベルでは、DEBUG または TRACE レベルのログメッセージは破棄されます。 同期ログを使用するには、ログレベルを調整するか、カスタムカテゴリを定義します。これらのプロパティは、ロガーの動作を指定する ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを使用して設定できます。このファイルを編集しない場合、Mule はデフォルトのプロパティを使用します。 Anypoint Studio では、​`log4j2.xml`​ は各 Mule オブジェクトの ​`src/main/resources`​ パスに含まれます。 デフォルト設定では、すべてのロガー (ルートロガーを含む) が非同期として定義されます。この設定はドメインまたはアプリケーションレベルで上書きできます。この設定をアプリケーションレベルで上書きするには、​`logConfigFile`​ エントリを ​`mule-artifact.json`​ ファイルに追加します。例: ```json { "minMuleVersion": "4.0.0", "logConfigFile": "../../../test-classes/resources/logging/custom-log4j2.xml" } ``` `log4j2.xml`​ ファイルのデフォルト設定を次に示します。 ```xml ``` ## [](#runtime-manager-エージェントのログの設定)Runtime Manager エージェントのログの設定
この設定は、Runtime Manager エージェント 1.5.2 以降を使用している場合のみ有効です。
Runtime Manager エージェントの状態をデフォルトの ​`mule_agent.log`​ ファイル以外の場所に記録するには、​`mule-agent-appender`​ という新しい Log4j 2 アペンダーを含めるように ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを設定します。含まれている場合、Runtime Manager エージェントプラグインはこのアペンダーを使用して状態を記録します。 この機能を有効にするには、​`log4j2.xml`​ ファイルに次のようなスニペットが含まれている必要があります。 ```xml (...) %d %p %c{1.} [%t] %m%n (...) ``` 上の例を使用すると、Runtime Manager エージェントはその状態を ​`$MULE_HOME/logs/custom_mule_agent.log`​ 内のローリングログファイルに記録します。このファイルは、250MB サイズに達するまで毎日繰り越されます。 他の Log4j 2 アペンダー設定については、Apache Log4j 2 のドキュメントを参照してください。 ## [](#exception_handling)非同期ログでの例外処理 非同期ログを使用していて、不完全なログが生成される可能性があるシステムクラッシュが発生した場合、LMAX ​`ExceptionHandler`​ ハンドラーが役立つ可能性があります。デフォルトでは、Mule はこのハンドラーを登録し、イベントをディスク、コンソール、および ​`logs/mule_ee.log`​ に記録します。独自の例外ハンドラーを提供するには、システムプロパティ ​`AsyncLoggerConfig.ExceptionHandler`​ を、インターフェースを実装するクラスの正規名に設定します。 デフォルトの例外ハンドラーを以下に示します。 ```java /* * Copyright (c) MuleSoft, Inc. All rights reserved. http://www.mulesoft.com * The software in this package is published under the terms of the CPAL v1.0 * license, a copy of which has been included with this distribution in the * LICENSE.txt file. */ package org.mule.runtime.module.launcher.api.log4j2; import com.lmax.disruptor.ExceptionHandler; import org.apache.logging.log4j.status.StatusLogger; /** * Implementation of {@link com.lmax.disruptor.ExceptionHandler} to be used when async loggers fail to log their messages. It will * log this event using the {@link org.apache.logging.log4j.status.StatusLogger} * * @since 3.6.0 */ public class AsyncLoggerExceptionHandler implements ExceptionHandler { private static final StatusLogger LOGGER = StatusLogger.getLogger(); @Override public void handleEventException(Throwable ex, long sequence, Object event) { LOGGER.error("Failed to asynchronously log message: " + event, ex); } @Override public void handleOnStartException(Throwable ex) { LOGGER.error("Failed to start asynchronous logger", ex); } @Override public void handleOnShutdownException(Throwable ex) { LOGGER.error("Failed to stop asynchronous logger", ex); } } ``` 非同期ログと同期ログの間には、パフォーマンスと信頼性のトレードオフがあります。ログメッセージの損失のリスクが重大な問題になる場合、ロガーを同期として設定します。同期ログと非同期ログの両方を組み合わせることができます。 ## [](#設定の再読み込み)設定の再読み込み Mule Runtime はログのフレームワークとして Log4j 2 を使用します。変更の有無を Log4j 2 で確認する監視間隔を追加または変更するには、​`monitorInterval`​ を ​`log4j2.xml`​ 設定ファイルに追加します。 1. Mule インストールフォルダーで ​`conf/log4j2.xml`​ を開きます。 2. 1 行目の後に ​``​ を追加します。例: ```xml ... ``` この例では、Log4j 2 は変更の有無を 15 秒ごとに確認します。 3. ファイルを保存して、Mule サーバーを再起動します。 詳細は、Log4j 2 の自動設定に関する Apache のドキュメントを参照してください。 ## [](#http-connector-を使用するプロジェクトのデバッグ)HTTP Connector を使用するプロジェクトのデバッグ HTTP Connector を使用するプロジェクトをデバッグするには、通常よりも詳細なログを記録し、プロジェクトでの HTTP Connector の ​`http-listener`​ および ​`http-request`​ 操作の動作をすべて追跡することをお勧めします。詳細は、​[『HTTP Connector トラブルシューティングガイド』](#connectors::http/http-troubleshooting.adoc)​を参照してください。 ## [](#soap-の要求および応答のログ)SOAP の要求および応答のログ 1. `src/main/resources`​ で ​`log4j2.xml`​ ファイルを開き、​`HttpMessageLogger`​ を設定に追加します。 ```xml ``` 2. プロジェクトを保存します。 ## [](#ログのトラブルシューティング)ログのトラブルシューティング ログ出力が表示されません クラスパスのルートで ​`log4j2.xml`​ を設定します。 Log4j 2 を再設定しましたが何も起こりません この問題は、別の ​`log4j2.xml`​ ファイルがクラスパスに存在し、変更前にそのファイルが選択されているために発生します。Log4j 2 がどの設定ファイルを使用しているかを確認するには、Mule の開始時に次のスイッチを追加します (または Mule を埋め込んでいる場合はコンテナの起動スクリプトに追加します)。 \-M-Dlog4j.debug=true このスイッチにより、使用されている設定ファイルの場所を含め、Log4j 2 の起動情報が ​`stdout`​ に書き込まれます。変更した設定を機能させる前に、この設定ファイルを削除する必要があります。 # ログの設定 MuleSoft は、Mule アプリケーションと Mule インスタンスの監視とトラブルシューティングに役立つアプリケーションログとランタイムログを提供します。 ## [](#アプリケーションログ)アプリケーションログ Studio でビルドするすべてのアプリケーションに、その独自の ​`log4j2.xml`​ ファイルが付属します。ログにはアプリケーションで発生したエラーに関する情報が含まれます (ただし、このエラーを処理するアプリケーションロジックがある場合を除く)。また、アプリケーション内でロジックをビルドした場合は、ログに明示的に記録する必要がある情報も含まれます。 Mule は、イベントのデバッグと追跡に役立つようにアプリケーションフロー内のいくつかのメッセージと特定の要素を自動的に記録します。また、​[Logger コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/logger-component-reference)​をフローの任意の場所に含めて、必要なメッセージを出力するようにセットアップすることもできます。 アプリケーションログは次の方法で表示できます。 - アプリケーションを Anypoint Studio から実行している場合、アプリケーションログからの出力は Anypoint Studio のコンソールウィンドウに表示されます。 - コマンドラインから Mule を使用してアプリケーションを実行している場合、アプリケーションログは OS コンソールに表示されます。 デフォルトでは、アプリケーションログファイルは ​`MULE_HOME/logs/.log`​ に保存されます。このログファイルのパスは Mule アプリケーションの ​`log4j2.xml`​ ファイルでカスタマイズできます。 ## [](#ランタイムログ)ランタイムログ ランタイムログ (​`mule_ee.log`​) にはアプリケーションとライフサイクルイベントに関する情報が含まれます。たとえば、Mule サービスまたはアプリケーションの開始、デプロイ、停止、またはアンデプロイ時にログにエントリが記録されます。 ランタイムログの設定は ​`/conf`​ ディレクトリの ​`log4j2.xml`​ ファイルに保存されます。このファイルは、オンプレミスで Mule を実行している場合にカスタマイズできます。 ### [](#anypoint-studio-でランタイムログを表示する)Anypoint Studio でランタイムログを表示する **\[Anypoint Studio\] > \[About Anypoint Studio (Anypoint Studio について)\] > \[Installation Details (インストールの詳細)\] > \[Configuration (設定)\] をクリックし、\[View Error Log (エラーログを表示)\]**​ をクリックします。 ![エラーログを表示](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/logging-in-mule-view-error-log.png) ### [](#ログレベルの変更)ログレベルの変更 `log4j2.xml`​ ファイルで次のパッケージの ​`level`​ 値を変更することで、ランタイムログのレベルを変更できます。 ```xml ``` 使用可能な値は、​`DEBUG`​、​`ERROR`​、​`INFO`​、​`TRACE`​、​`WARN`​ です。 特定のコネクタのログレベルのみを変更する場合は、​[「冗長ログの有効化」](https://docs.mulesoft.com/jp/mule-runtime/4.5/enable-verbose-logging)​を参照してください。 ## [](#ログの設定)ログの設定 設定ファイルを作成し、次の設定を定義できます。 - 記録するメッセージの種類 - メッセージの記録方法 (非同期または同期) - メッセージの記録場所 (コンソールまたはディスク、エンドポイントまたはデータベースなど) Mule は ​`slf4j`​ を使用します。これは、Apache Log4j 2 や JDK ロガーなど、クラスパスからログ戦略を検出して使用するログファサードです。デフォルトでは、Mule には Log4j 2 が含まれます。これは、​`log4j2.xml`​ というファイルで設定されます。 ## [](#同期ログと非同期ログの比較)同期ログと非同期ログの比較 デフォルトでは、Mule はメッセージを非同期で記録します。ログを同期的に記録すると、メッセージを処理しているスレッドの実行が中断し、ログメッセージが完全に処理されるまで待機した後、メッセージの処理を続行できます。 ![logger synch](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/logger-synch.png) ログを非同期的に記録すると、ログ記録の操作は個別のスレッドで実行されるため、ログ記録が完了する前にメッセージを処理できます。 ![logger asynch alternativo](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/logger-asynch-alternativo.png) MuleSoft は、ほとんどの状況で​**非同期ログ**​を使用することをお勧めします。大幅にスループットが向上し、メッセージ処理のレイテンシーが短縮されるためです。 非同期ログを使用すると、システムクラッシュが発生した場合にいくつかのアクションが記録されない可能性があります。この状況は、他のアクションとは無関係に動作する別のスレッドでログの書き込みが実行されるために発生します。この問題を緩和する方法についての詳細は、​[「非同期ログでの例外処理」](#exception_handling)​を参照してください。 アプリケーションログを監査履歴として使用する場合は、必ず​**同期**​ログを使用するようにアプリケーションを設定してください。これにより、ログメッセージの損失が防止されます。
Mule 4 では、log4j のメモリ使用量を最適化するためにスレッドローカル機能が導入されています。この機能を使用しやすくするために、システムプロパティ ​AsyncLoggerConfig.RingBufferSize​ を設定できます (​「プロパティの設定」​を参照)。 20000​ が推奨値ですが、ニーズに合わせて調整する必要があります。
### [](#パフォーマンステスト)パフォーマンステスト 以下のチャートは、同期ログと非同期ログのパフォーマンスの違いと、同時メッセージ数の増加に応じてレイテンシーがどの程度増加したかを示しています。このテストでは、各実行で使用するスレッドの量を増加しながら、アプリケーションで約 100 万件のメッセージをログに記録しました。各トランザクションの結果、1,000 件のメッセージが生成されました。 ![logging latency vs concurrency](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/logging-latency-vs-concurrency.png) このチャートで示されているように、非同期でログを記録した場合の結果は、ログを記録しない場合の結果に非常に近くなりました。 ## [](#カスタムログの設定)カスタムログの設定 デフォルトでは、Mule では、ログは非同期の方法で INFO 以上のレベルで記録されます。デフォルトのログレベルでは、DEBUG または TRACE レベルのログメッセージは破棄されます。 同期ログを使用するには、ログレベルを調整するか、カスタムカテゴリを定義します。これらのプロパティは、ロガーの動作を指定する ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを使用して設定できます。このファイルを編集しない場合、Mule はデフォルトのプロパティを使用します。 Anypoint Studio では、​`log4j2.xml`​ は各 Mule オブジェクトの ​`src/main/resources`​ パスに含まれます。 デフォルト設定では、すべてのロガー (ルートロガーを含む) が非同期として定義されます。この設定はドメインまたはアプリケーションレベルで上書きできます。この設定をアプリケーションレベルで上書きするには、​`logConfigFile`​ エントリを ​`mule-artifact.json`​ ファイルに追加します。次に例を示します。 ```json { "minMuleVersion": "4.0.0", "logConfigFile": "../../../test-classes/resources/logging/custom-log4j2.xml" } ``` `log4j2.xml`​ ファイルのデフォルト設定を次に示します。 ```xml ``` ## [](#runtime-manager-エージェントのログの設定)Runtime Manager エージェントのログの設定
この設定は、Runtime Manager エージェント 1.5.2 以降を使用している場合のみ有効です。
Runtime Manager エージェントの状態をデフォルトの ​`mule_agent.log`​ ファイル以外の場所に記録するには、​`mule-agent-appender`​ という新しい Log4j 2 アペンダーを含めるように ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを設定します。含まれている場合、Runtime Manager エージェントプラグインはこのアペンダーを使用して状態を記録します。 この機能を有効にするには、​`log4j2.xml`​ ファイルに次のようなスニペットが含まれている必要があります。 ```xml (...) %d %p %c{1.} [%t] %m%n (...) ``` 上の例を使用すると、Runtime Manager エージェントはその状態を ​`$MULE_HOME/logs/custom_mule_agent.log`​ 内のローリングログファイルに記録します。このファイルは、250MB サイズに達するまで毎日繰り越されます。 他の Log4j 2 アペンダー設定については、Apache Log4j 2 のドキュメントを参照してください。 ## [](#exception_handling)非同期ログでの例外処理 非同期ログを使用していて、不完全なログが生成される可能性があるシステムクラッシュが発生した場合、LMAX ​`ExceptionHandler`​ ハンドラーが役立つ可能性があります。デフォルトでは、Mule はこのハンドラーを登録し、イベントをディスク、コンソール、および ​`logs/mule_ee.log`​ に記録します。独自の例外ハンドラーを提供するには、システムプロパティ ​`AsyncLoggerConfig.ExceptionHandler`​ を、インターフェースを実装するクラスの正規名に設定します。 デフォルトの例外ハンドラーを以下に示します。 ```java /* * Copyright (c) MuleSoft, Inc. All rights reserved. http://www.mulesoft.com * The software in this package is published under the terms of the CPAL v1.0 * license, a copy of which has been included with this distribution in the * LICENSE.txt file. */ package org.mule.runtime.module.launcher.api.log4j2; import com.lmax.disruptor.ExceptionHandler; import org.apache.logging.log4j.status.StatusLogger; /** * Implementation of {@link com.lmax.disruptor.ExceptionHandler} to be used when async loggers fail to log their messages. It will * log this event using the {@link org.apache.logging.log4j.status.StatusLogger} * * @since 3.6.0 */ public class AsyncLoggerExceptionHandler implements ExceptionHandler { private static final StatusLogger LOGGER = StatusLogger.getLogger(); @Override public void handleEventException(Throwable ex, long sequence, Object event) { LOGGER.error("Failed to asynchronously log message: " + event, ex); } @Override public void handleOnStartException(Throwable ex) { LOGGER.error("Failed to start asynchronous logger", ex); } @Override public void handleOnShutdownException(Throwable ex) { LOGGER.error("Failed to stop asynchronous logger", ex); } } ``` 非同期ログと同期ログの間には、パフォーマンスと信頼性のトレードオフがあります。ログメッセージの損失のリスクが重大な問題になる場合、ロガーを同期として設定します。同期ログと非同期ログの両方を組み合わせることができます。 ## [](#設定の再読み込み)設定の再読み込み Mule Runtime はログのフレームワークとして Log4j 2 を使用します。変更の有無を Log4j 2 で確認する監視間隔を追加または変更するには、​`monitorInterval`​ を ​`log4j2.xml`​ 設定ファイルに追加します。 1. Mule インストールフォルダーで ​`conf/log4j2.xml`​ を開きます。 2. 1 行目の後に ​``​ を追加します。次に例を示します。 ```xml ... ``` この例では、Log4j 2 は変更の有無を 15 秒ごとに確認します。 3. ファイルを保存して、Mule サーバーを再起動します。 詳細は、Log4j 2 の自動設定に関する Apache のドキュメントを参照してください。 ## [](#http-connector-を使用するプロジェクトのデバッグ)HTTP Connector を使用するプロジェクトのデバッグ HTTP Connector を使用するプロジェクトをデバッグするには、通常よりも詳細なログを記録し、プロジェクトでの HTTP Connector の ​`http-listener`​ および ​`http-request`​ 操作の動作をすべて追跡することをお勧めします。詳細は、​[『HTTP Connector トラブルシューティングガイド』](#connectors::http/http-troubleshooting.adoc)​を参照してください。 ## [](#soap-の要求および応答のログ)SOAP の要求および応答のログ 1. `src/main/resources`​ で ​`log4j2.xml`​ ファイルを開き、​`HttpMessageLogger`​ を設定に追加します。 ```xml ``` 2. プロジェクトを保存します。 ## [](#ログのトラブルシューティング)ログのトラブルシューティング ログ出力が表示されません クラスパスのルートで ​`log4j2.xml`​ を設定します。 Log4j 2 を再設定しましたが何も起こりません この問題は、別の ​`log4j2.xml`​ ファイルがクラスパスに存在し、変更前にそのファイルが選択されているために発生します。Log4j 2 がどの設定ファイルを使用しているかを確認するには、Mule の開始時に次のスイッチを追加します (または Mule を埋め込んでいる場合はコンテナの起動スクリプトに追加します)。 \-M-Dlog4j.debug=true このスイッチにより、使用されている設定ファイルの場所を含め、Log4j 2 の起動情報が ​`stdout`​ に書き込まれます。変更した設定を機能させる前に、この設定ファイルを削除する必要があります。 # ログの設定 MuleSoft は、Mule アプリケーションと Mule インスタンスの監視とトラブルシューティングに役立つアプリケーションログとランタイムログを提供します。 ## [](#アプリケーションログ)アプリケーションログ Studio でビルドするすべてのアプリケーションに、その独自の ​`log4j2.xml`​ ファイルが付属します。ログにはアプリケーションで発生したエラーに関する情報が含まれます (ただし、このエラーを処理するアプリケーションロジックがある場合を除く)。また、アプリケーション内でロジックをビルドした場合は、ログに明示的に記録する必要がある情報も含まれます。 Mule は、イベントのデバッグと追跡に役立つようにアプリケーションフロー内のいくつかのメッセージと特定の要素を自動的に記録します。また、​[Logger コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/logger-component-reference)​をフローの任意の場所に含めて、必要なメッセージを出力するようにセットアップすることもできます。 アプリケーションログは次の方法で表示できます。 - アプリケーションを Anypoint Studio から実行している場合、アプリケーションログからの出力は Anypoint Studio のコンソールウィンドウに表示されます。 - コマンドラインから Mule を使用してアプリケーションを実行している場合、アプリケーションログは OS コンソールに表示されます。 デフォルトでは、アプリケーションログファイルは ​`MULE_HOME/logs/.log`​ に保存されます。このログファイルのパスは Mule アプリケーションの ​`log4j2.xml`​ ファイルでカスタマイズできます。 ## [](#ランタイムログ)ランタイムログ ランタイムログ (​`mule_ee.log`​) にはアプリケーションとライフサイクルイベントに関する情報が含まれます。たとえば、Mule サービスまたはアプリケーションの開始、デプロイ、停止、またはアンデプロイ時にログにエントリが記録されます。 ランタイムログの設定は ​`/conf`​ ディレクトリの ​`log4j2.xml`​ ファイルに保存されます。このファイルは、オンプレミスで Mule を実行している場合にカスタマイズできます。 ### [](#anypoint-studio-でランタイムログを表示する)Anypoint Studio でランタイムログを表示する **\[Anypoint Studio\] > \[About Anypoint Studio (Anypoint Studio について)\] > \[Installation Details (インストールの詳細)\] > \[Configuration (設定)\] をクリックし、\[View Error Log (エラーログを表示)\]**​ をクリックします。 ![エラーログを表示](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/logging-in-mule-view-error-log.png) ### [](#ログレベルの変更)ログレベルの変更 `log4j2.xml`​ ファイルで次のパッケージの ​`level`​ 値を変更することで、ランタイムログのレベルを変更できます。 ```xml ``` 使用可能な値は、​`DEBUG`​、​`ERROR`​、​`INFO`​、​`TRACE`​、​`WARN`​ です。 特定のコネクタのログレベルのみを変更する場合は、​[「冗長ログの有効化」](https://docs.mulesoft.com/jp/mule-runtime/4.6/enable-verbose-logging)​を参照してください。 ## [](#ログの設定)ログの設定 設定ファイルを作成し、次の設定を定義できます。 - 記録するメッセージの種類 - メッセージの記録方法 (非同期または同期) - メッセージの記録場所 (コンソールまたはディスク、エンドポイントまたはデータベースなど) Mule は ​`slf4j`​ を使用します。これは、Apache Log4j 2 や JDK ロガーなど、クラスパスからログ戦略を検出して使用するログファサードです。デフォルトでは、Mule には Log4j 2 が含まれます。これは、​`log4j2.xml`​ というファイルで設定されます。 ## [](#同期ログと非同期ログの比較)同期ログと非同期ログの比較 デフォルトでは、Mule はメッセージを非同期で記録します。ログを同期的に記録すると、メッセージを処理しているスレッドの実行が中断し、ログメッセージが完全に処理されるまで待機した後、メッセージの処理を続行できます。 ![logger synch](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/logger-synch.png) ログを非同期的に記録すると、ログ記録の操作は個別のスレッドで実行されるため、ログ記録が完了する前にメッセージを処理できます。 ![logger asynch alternativo](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/logger-asynch-alternativo.png) MuleSoft は、ほとんどの状況で​**非同期ログ**​を使用することをお勧めします。大幅にスループットが向上し、メッセージ処理のレイテンシーが短縮されるためです。 非同期ログを使用すると、システムクラッシュが発生した場合にいくつかのアクションが記録されない可能性があります。この状況は、他のアクションとは無関係に動作する別のスレッドでログの書き込みが実行されるために発生します。この問題を緩和する方法についての詳細は、​[「非同期ログでの例外処理」](#exception_handling)​を参照してください。 アプリケーションログを監査履歴として使用する場合は、必ず​**同期**​ログを使用するようにアプリケーションを設定してください。これにより、ログメッセージの損失が防止されます。
Mule 4 では、log4j のメモリ使用量を最適化するためにスレッドローカル機能が導入されています。この機能を使用しやすくするために、システムプロパティ ​AsyncLoggerConfig.RingBufferSize​ を設定できます (​「プロパティの設定」​を参照)。 20000​ が推奨値ですが、ニーズに合わせて調整する必要があります。
### [](#パフォーマンステスト)パフォーマンステスト 以下のチャートは、同期ログと非同期ログのパフォーマンスの違いと、同時メッセージ数の増加に応じてレイテンシーがどの程度増加したかを示しています。このテストでは、各実行で使用するスレッドの量を増加しながら、アプリケーションで約 100 万件のメッセージをログに記録しました。各トランザクションの結果、1,000 件のメッセージが生成されました。 ![logging latency vs concurrency](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/logging-latency-vs-concurrency.png) このチャートで示されているように、非同期でログを記録した場合の結果は、ログを記録しない場合の結果に非常に近くなりました。 ## [](#カスタムログの設定)カスタムログの設定 デフォルトでは、Mule では、ログは非同期の方法で INFO 以上のレベルで記録されます。デフォルトのログレベルでは、DEBUG または TRACE レベルのログメッセージは破棄されます。 同期ログを使用するには、ログレベルを調整するか、カスタムカテゴリを定義します。これらのプロパティは、ロガーの動作を指定する ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを使用して設定できます。このファイルを編集しない場合、Mule はデフォルトのプロパティを使用します。 Anypoint Studio では、​`log4j2.xml`​ は各 Mule オブジェクトの ​`src/main/resources`​ パスに含まれます。 デフォルト設定では、すべてのロガー (ルートロガーを含む) が非同期として定義されます。この設定はドメインまたはアプリケーションレベルで上書きできます。この設定をアプリケーションレベルで上書きするには、​`logConfigFile`​ エントリを ​`mule-artifact.json`​ ファイルに追加します。例: ```json { "minMuleVersion": "4.0.0", "logConfigFile": "../../../test-classes/resources/logging/custom-log4j2.xml" } ``` `log4j2.xml`​ ファイルのデフォルト設定を次に示します。 ```xml ``` ## [](#runtime-manager-エージェントのログの設定)Runtime Manager エージェントのログの設定
この設定は、Runtime Manager エージェント 1.5.2 以降を使用している場合のみ有効です。
Runtime Manager エージェントの状態をデフォルトの ​`mule_agent.log`​ ファイル以外の場所に記録するには、​`mule-agent-appender`​ という新しい Log4j 2 アペンダーを含めるように ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを設定します。含まれている場合、Runtime Manager エージェントプラグインはこのアペンダーを使用して状態を記録します。 この機能を有効にするには、​`log4j2.xml`​ ファイルに次のようなスニペットが含まれている必要があります。 ```xml (...) %d %p %c{1.} [%t] %m%n (...) ``` 上の例を使用すると、Runtime Manager エージェントはその状態を ​`$MULE_HOME/logs/custom_mule_agent.log`​ 内のローリングログファイルに記録します。このファイルは、250MB サイズに達するまで毎日繰り越されます。 他の Log4j 2 アペンダー設定については、Apache Log4j 2 のドキュメントを参照してください。 ## [](#exception_handling)非同期ログでの例外処理 非同期ログを使用していて、不完全なログが生成される可能性があるシステムクラッシュが発生した場合、LMAX ​`ExceptionHandler`​ ハンドラーが役立つ可能性があります。デフォルトでは、Mule はこのハンドラーを登録し、イベントをディスク、コンソール、および ​`logs/mule_ee.log`​ に記録します。独自の例外ハンドラーを提供するには、システムプロパティ ​`AsyncLoggerConfig.ExceptionHandler`​ を、インターフェースを実装するクラスの正規名に設定します。 デフォルトの例外ハンドラーを以下に示します。 ```java /* * Copyright (c) MuleSoft, Inc. All rights reserved. http://www.mulesoft.com * The software in this package is published under the terms of the CPAL v1.0 * license, a copy of which has been included with this distribution in the * LICENSE.txt file. */ package org.mule.runtime.module.launcher.api.log4j2; import com.lmax.disruptor.ExceptionHandler; import org.apache.logging.log4j.status.StatusLogger; /** * Implementation of {@link com.lmax.disruptor.ExceptionHandler} to be used when async loggers fail to log their messages. It will * log this event using the {@link org.apache.logging.log4j.status.StatusLogger} * * @since 3.6.0 */ public class AsyncLoggerExceptionHandler implements ExceptionHandler { private static final StatusLogger LOGGER = StatusLogger.getLogger(); @Override public void handleEventException(Throwable ex, long sequence, Object event) { LOGGER.error("Failed to asynchronously log message: " + event, ex); } @Override public void handleOnStartException(Throwable ex) { LOGGER.error("Failed to start asynchronous logger", ex); } @Override public void handleOnShutdownException(Throwable ex) { LOGGER.error("Failed to stop asynchronous logger", ex); } } ``` 非同期ログと同期ログの間には、パフォーマンスと信頼性のトレードオフがあります。ログメッセージの損失のリスクが重大な問題になる場合、ロガーを同期として設定します。同期ログと非同期ログの両方を組み合わせることができます。 ## [](#設定の再読み込み)設定の再読み込み Mule Runtime はログのフレームワークとして Log4j 2 を使用します。変更の有無を Log4j 2 で確認する監視間隔を追加または変更するには、​`monitorInterval`​ を ​`log4j2.xml`​ 設定ファイルに追加します。 1. Mule インストールフォルダーで ​`conf/log4j2.xml`​ を開きます。 2. 1 行目の後に ​``​ を追加します。例: ```xml ... ``` この例では、Log4j 2 は変更の有無を 15 秒ごとに確認します。 3. ファイルを保存して、Mule サーバーを再起動します。 詳細は、Log4j 2 の自動設定に関する Apache のドキュメントを参照してください。 ## [](#http-connector-を使用するプロジェクトのデバッグ)HTTP Connector を使用するプロジェクトのデバッグ HTTP Connector を使用するプロジェクトをデバッグするには、通常よりも詳細なログを記録し、プロジェクトでの HTTP Connector の ​`http-listener`​ および ​`http-request`​ 操作の動作をすべて追跡することをお勧めします。詳細は、​[『HTTP Connector トラブルシューティングガイド』](#connectors::http/http-troubleshooting.adoc)​を参照してください。 ## [](#soap-の要求および応答のログ)SOAP の要求および応答のログ 1. `src/main/resources`​ で ​`log4j2.xml`​ ファイルを開き、​`HttpMessageLogger`​ を設定に追加します。 ```xml ``` 2. プロジェクトを保存します。 ## [](#ログのトラブルシューティング)ログのトラブルシューティング ログ出力が表示されません クラスパスのルートで ​`log4j2.xml`​ を設定します。 Log4j 2 を再設定しましたが何も起こりません この問題は、別の ​`log4j2.xml`​ ファイルがクラスパスに存在し、変更前にそのファイルが選択されているために発生します。Log4j 2 がどの設定ファイルを使用しているかを確認するには、Mule の開始時に次のスイッチを追加します (または Mule を埋め込んでいる場合はコンテナの起動スクリプトに追加します)。 \-M-Dlog4j.debug=true このスイッチにより、使用されている設定ファイルの場所を含め、Log4j 2 の起動情報が ​`stdout`​ に書き込まれます。変更した設定を機能させる前に、この設定ファイルを削除する必要があります。 # ログの設定 MuleSoft は、Mule アプリケーションと Mule インスタンスの監視とトラブルシューティングに役立つアプリケーションログとランタイムログを提供します。 ## [](#アプリケーションログ)アプリケーションログ Studio でビルドするすべてのアプリケーションに、その独自の ​`log4j2.xml`​ ファイルが付属します。ログにはアプリケーションで発生したエラーに関する情報が含まれます (ただし、このエラーを処理するアプリケーションロジックがある場合を除く)。また、アプリケーション内でロジックをビルドした場合は、ログに明示的に記録する必要がある情報も含まれます。 Mule は、イベントのデバッグと追跡に役立つようにアプリケーションフロー内のいくつかのメッセージと特定の要素を自動的に記録します。また、​[Logger コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/logger-component-reference)​をフローの任意の場所に含めて、必要なメッセージを出力するようにセットアップすることもできます。 アプリケーションログは次の方法で表示できます。 - アプリケーションを Anypoint Studio から実行している場合、アプリケーションログからの出力は Anypoint Studio のコンソールウィンドウに表示されます。 - コマンドラインから Mule を使用してアプリケーションを実行している場合、アプリケーションログは OS コンソールに表示されます。 デフォルトでは、アプリケーションログファイルは ​`MULE_HOME/logs/.log`​ に保存されます。このログファイルのパスは Mule アプリケーションの ​`log4j2.xml`​ ファイルでカスタマイズできます。 ## [](#ランタイムログ)ランタイムログ ランタイムログ (​`mule_ee.log`​) にはアプリケーションとライフサイクルイベントに関する情報が含まれます。たとえば、Mule サービスまたはアプリケーションの開始、デプロイ、停止、またはアンデプロイ時にログにエントリが記録されます。 ランタイムログの設定は ​`/conf`​ ディレクトリの ​`log4j2.xml`​ ファイルに保存されます。このファイルは、オンプレミスで Mule を実行している場合にカスタマイズできます。 ### [](#anypoint-studio-でランタイムログを表示する)Anypoint Studio でランタイムログを表示する **\[Anypoint Studio\] > \[About Anypoint Studio (Anypoint Studio について)\] > \[Installation Details (インストールの詳細)\] > \[Configuration (設定)\] をクリックし、\[View Error Log (エラーログを表示)\]**​ をクリックします。 ![Anypoint Studio のエラーログビューアーインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/logging-in-mule-view-error-log.png) ### [](#ログレベルの変更)ログレベルの変更 `log4j2.xml`​ ファイルで次のパッケージの ​`level`​ 値を変更することで、ランタイムログのレベルを変更できます。 ```xml ``` 使用可能な値は、​`DEBUG`​、​`ERROR`​、​`INFO`​、​`TRACE`​、​`WARN`​ です。 特定のコネクタのログレベルのみを変更する場合は、​[「冗長ログの有効化」](https://docs.mulesoft.com/jp/mule-runtime/4.7/enable-verbose-logging)​を参照してください。 ## [](#ログの設定)ログの設定 設定ファイルを作成し、次の設定を定義できます。 - 記録するメッセージの種類 - メッセージの記録方法 (非同期または同期) - メッセージの記録場所 (コンソールまたはディスク、エンドポイントまたはデータベースなど) Mule は ​`slf4j`​ を使用します。これは、Apache Log4j 2 や JDK ロガーなど、クラスパスからログ戦略を検出して使用するログファサードです。デフォルトでは、Mule には Log4j 2 が含まれます。これは、​`log4j2.xml`​ というファイルで設定されます。 ## [](#同期ログと非同期ログの比較)同期ログと非同期ログの比較 デフォルトでは、Mule はメッセージを非同期で記録します。ログを同期的に記録すると、メッセージを処理しているスレッドの実行が中断し、ログメッセージが完全に処理されるまで待機した後、メッセージの処理を続行できます。 ![スレッド環境の同期ログ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/logger-synch.png) ログを非同期的に記録すると、ログ記録の操作は個別のスレッドで実行されるため、ログ記録が完了する前にメッセージを処理できます。 ![スレッド環境の非同期ログ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/logger-asynch-alternativo.png) MuleSoft は、ほとんどの状況で​**非同期ログ**​を使用することをお勧めします。大幅にスループットが向上し、メッセージ処理のレイテンシーが短縮されるためです。 非同期ログを使用すると、システムクラッシュが発生した場合にいくつかのアクションが記録されない可能性があります。この状況は、他のアクションとは無関係に動作する別のスレッドでログの書き込みが実行されるために発生します。この問題を緩和する方法についての詳細は、​[「非同期ログでの例外処理」](#exception_handling)​を参照してください。 アプリケーションログを監査履歴として使用する場合は、必ず​**同期**​ログを使用するようにアプリケーションを設定してください。これにより、ログメッセージの損失が防止されます。
Mule 4 では、log4j のメモリ使用量を最適化するためにスレッドローカル機能が導入されています。この機能を使用しやすくするために、システムプロパティ ​AsyncLoggerConfig.RingBufferSize​ を設定できます (​「プロパティの設定」​を参照)。 20000​ が推奨値ですが、ニーズに合わせて調整する必要があります。
### [](#パフォーマンステスト)パフォーマンステスト 以下のチャートは、同期ログと非同期ログのパフォーマンスの違いと、同時メッセージ数の増加に応じてレイテンシーがどの程度増加したかを示しています。このテストでは、各実行で使用するスレッドの量を増加しながら、アプリケーションで約 100 万件のメッセージをログに記録しました。各トランザクションの結果、1,000 件のメッセージが生成されました。 ![レイテンシーと同時実行を比較する折れ線チャート](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/logging-latency-vs-concurrency.png) このチャートで示されているように、非同期でログを記録した場合の結果は、ログを記録しない場合の結果に非常に近くなりました。 ## [](#カスタムログの設定)カスタムログの設定 デフォルトでは、Mule では、ログは非同期の方法で INFO 以上のレベルで記録されます。デフォルトのログレベルでは、DEBUG または TRACE レベルのログメッセージは破棄されます。 同期ログを使用するには、ログレベルを調整するか、カスタムカテゴリを定義します。これらのプロパティは、ロガーの動作を指定する ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを使用して設定できます。このファイルを編集しない場合、Mule はデフォルトのプロパティを使用します。 Anypoint Studio では、​`log4j2.xml`​ は各 Mule オブジェクトの ​`src/main/resources`​ パスに含まれます。 デフォルト設定では、すべてのロガー (ルートロガーを含む) が非同期として定義されます。この設定はドメインまたはアプリケーションレベルで上書きできます。この設定をアプリケーションレベルで上書きするには、​`logConfigFile`​ エントリを ​`mule-artifact.json`​ ファイルに追加します。例: ```json { "minMuleVersion": "4.0.0", "logConfigFile": "../../../test-classes/resources/logging/custom-log4j2.xml" } ``` `log4j2.xml`​ ファイルのデフォルト設定を次に示します。 ```xml ``` ## [](#runtime-manager-エージェントのログの設定)Runtime Manager エージェントのログの設定
この設定は、Runtime Manager エージェント 1.5.2 以降を使用している場合のみ有効です。
Runtime Manager エージェントの状態をデフォルトの ​`mule_agent.log`​ ファイル以外の場所に記録するには、​`mule-agent-appender`​ という新しい Log4j 2 アペンダーを含めるように ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを設定します。含まれている場合、Runtime Manager エージェントプラグインはこのアペンダーを使用して状態を記録します。 この機能を有効にするには、​`log4j2.xml`​ ファイルに次のようなスニペットが含まれている必要があります。 ```xml (...) %d %p %c{1.} [%t] %m%n (...) ``` 上の例を使用すると、Runtime Manager エージェントはその状態を ​`$MULE_HOME/logs/custom_mule_agent.log`​ 内のローリングログファイルに記録します。このファイルは、250MB サイズに達するまで毎日繰り越されます。 他の Log4j 2 アペンダー設定については、Apache Log4j 2 のドキュメントを参照してください。 ## [](#exception_handling)非同期ログでの例外処理 非同期ログを使用していて、不完全なログが生成される可能性があるシステムクラッシュが発生した場合、LMAX ​`ExceptionHandler`​ ハンドラーが役立つ可能性があります。デフォルトでは、Mule はこのハンドラーを登録し、イベントをディスク、コンソール、および ​`logs/mule_ee.log`​ に記録します。独自の例外ハンドラーを提供するには、システムプロパティ ​`AsyncLoggerConfig.ExceptionHandler`​ を、インターフェースを実装するクラスの正規名に設定します。 デフォルトの例外ハンドラーを以下に示します。 ```java /* * Copyright (c) MuleSoft, Inc. All rights reserved. http://www.mulesoft.com * The software in this package is published under the terms of the CPAL v1.0 * license, a copy of which has been included with this distribution in the * LICENSE.txt file. */ package org.mule.runtime.module.launcher.api.log4j2; import com.lmax.disruptor.ExceptionHandler; import org.apache.logging.log4j.status.StatusLogger; /** * Implementation of {@link com.lmax.disruptor.ExceptionHandler} to be used when async loggers fail to log their messages. It will * log this event using the {@link org.apache.logging.log4j.status.StatusLogger} * * @since 3.6.0 */ public class AsyncLoggerExceptionHandler implements ExceptionHandler { private static final StatusLogger LOGGER = StatusLogger.getLogger(); @Override public void handleEventException(Throwable ex, long sequence, Object event) { LOGGER.error("Failed to asynchronously log message: " + event, ex); } @Override public void handleOnStartException(Throwable ex) { LOGGER.error("Failed to start asynchronous logger", ex); } @Override public void handleOnShutdownException(Throwable ex) { LOGGER.error("Failed to stop asynchronous logger", ex); } } ``` 非同期ログと同期ログの間には、パフォーマンスと信頼性のトレードオフがあります。ログメッセージの損失のリスクが重大な問題になる場合、ロガーを同期として設定します。同期ログと非同期ログの両方を組み合わせることができます。 ## [](#設定の再読み込み)設定の再読み込み Mule Runtime はログのフレームワークとして Log4j 2 を使用します。変更の有無を Log4j 2 で確認する監視間隔を追加または変更するには、​`monitorInterval`​ を ​`log4j2.xml`​ 設定ファイルに追加します。 1. Mule インストールフォルダーで ​`conf/log4j2.xml`​ を開きます。 2. 1 行目の後に ​``​ を追加します。例: ```xml ... ``` この例では、Log4j 2 は変更の有無を 15 秒ごとに確認します。 3. ファイルを保存して、Mule サーバーを再起動します。 詳細は、Log4j 2 の自動設定に関する Apache のドキュメントを参照してください。 ## [](#http-connector-を使用するプロジェクトのデバッグ)HTTP Connector を使用するプロジェクトのデバッグ HTTP Connector を使用するプロジェクトをデバッグするには、通常よりも詳細なログを記録し、プロジェクトでの HTTP Connector の ​`http-listener`​ および ​`http-request`​ 操作の動作をすべて追跡することをお勧めします。詳細は、​[『HTTP Connector トラブルシューティングガイド』](#connectors::http/http-troubleshooting.adoc)​を参照してください。 ## [](#soap-の要求および応答のログ)SOAP の要求および応答のログ 1. `src/main/resources`​ で ​`log4j2.xml`​ ファイルを開き、​`HttpMessageLogger`​ を設定に追加します。 ```xml ``` 2. プロジェクトを保存します。 ## [](#ログのトラブルシューティング)ログのトラブルシューティング ログ出力が表示されません クラスパスのルートで ​`log4j2.xml`​ を設定します。 Log4j 2 を再設定しましたが何も起こりません この問題は、別の ​`log4j2.xml`​ ファイルがクラスパスに存在し、変更前にそのファイルが選択されているために発生します。Log4j 2 がどの設定ファイルを使用しているかを確認するには、Mule の開始時に次のスイッチを追加します (または Mule を埋め込んでいる場合はコンテナの起動スクリプトに追加します)。 \-M-Dlog4j.debug=true このスイッチにより、使用されている設定ファイルの場所を含め、Log4j 2 の起動情報が ​`stdout`​ に書き込まれます。変更した設定を機能させる前に、この設定ファイルを削除する必要があります。 # ログの設定 MuleSoft は、Mule アプリケーションと Mule インスタンスの監視とトラブルシューティングに役立つアプリケーションログとランタイムログを提供します。 ## [](#アプリケーションログ)アプリケーションログ Studio でビルドするすべてのアプリケーションに、その独自の ​`log4j2.xml`​ ファイルが付属します。ログにはアプリケーションで発生したエラーに関する情報が含まれます (ただし、このエラーを処理するアプリケーションロジックがある場合を除く)。また、アプリケーション内でロジックをビルドした場合は、ログに明示的に記録する必要がある情報も含まれます。 Mule は、イベントのデバッグと追跡に役立つようにアプリケーションフロー内のいくつかのメッセージと特定の要素を自動的に記録します。また、​[Logger コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/logger-component-reference)​をフローの任意の場所に含めて、必要なメッセージを出力するようにセットアップすることもできます。 アプリケーションログは次の方法で表示できます。 - アプリケーションを Anypoint Studio から実行している場合、アプリケーションログからの出力は Anypoint Studio のコンソールウィンドウに表示されます。 - コマンドラインから Mule を使用してアプリケーションを実行している場合、アプリケーションログは OS コンソールに表示されます。 デフォルトでは、アプリケーションログファイルは ​`MULE_HOME/logs/.log`​ に保存されます。このログファイルのパスは Mule アプリケーションの ​`log4j2.xml`​ ファイルでカスタマイズできます。 ## [](#ランタイムログ)ランタイムログ ランタイムログ (​`mule_ee.log`​) にはアプリケーションとライフサイクルイベントに関する情報が含まれます。たとえば、Mule サービスまたはアプリケーションの開始、デプロイ、停止、またはアンデプロイ時にログにエントリが記録されます。 ランタイムログの設定は ​`/conf`​ ディレクトリの ​`log4j2.xml`​ ファイルに保存されます。このファイルは、オンプレミスで Mule を実行している場合にカスタマイズできます。 ### [](#anypoint-studio-でランタイムログを表示する)Anypoint Studio でランタイムログを表示する **\[Anypoint Studio\] > \[About Anypoint Studio (Anypoint Studio について)\] > \[Installation Details (インストールの詳細)\] > \[Configuration (設定)\] をクリックし、\[View Error Log (エラーログを表示)\]**​ をクリックします。 ![Anypoint Studio のエラーログビューアーインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/logging-in-mule-view-error-log.png) ### [](#ログレベルの変更)ログレベルの変更 `log4j2.xml`​ ファイルで次のパッケージの ​`level`​ 値を変更することで、ランタイムログのレベルを変更できます。 ```xml ``` 使用可能な値は、​`DEBUG`​、​`ERROR`​、​`INFO`​、​`TRACE`​、​`WARN`​ です。 特定のコネクタのログレベルのみを変更する場合は、​[「冗長ログの有効化」](https://docs.mulesoft.com/jp/mule-runtime/4.8/enable-verbose-logging)​を参照してください。 ## [](#ログの設定)ログの設定 設定ファイルを作成し、次の設定を定義できます。 - 記録するメッセージの種類 - メッセージの記録方法 (非同期または同期) - メッセージの記録場所 (コンソールまたはディスク、エンドポイントまたはデータベースなど) Mule は ​`slf4j`​ を使用します。これは、Apache Log4j 2 や JDK ロガーなど、クラスパスからログ戦略を検出して使用するログファサードです。デフォルトでは、Mule には Log4j 2 が含まれます。これは、​`log4j2.xml`​ というファイルで設定されます。 ## [](#同期ログと非同期ログの比較)同期ログと非同期ログの比較 デフォルトでは、Mule はメッセージを非同期で記録します。ログを同期的に記録すると、メッセージを処理しているスレッドの実行が中断し、ログメッセージが完全に処理されるまで待機した後、メッセージの処理を続行できます。 ![スレッド環境の同期ログ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/logger-synch.png) ログを非同期的に記録すると、ログ記録の操作は個別のスレッドで実行されるため、ログ記録が完了する前にメッセージを処理できます。 ![スレッド環境の非同期ログ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/logger-asynch-alternativo.png) MuleSoft は、ほとんどの状況で​**非同期ログ**​を使用することをお勧めします。大幅にスループットが向上し、メッセージ処理のレイテンシーが短縮されるためです。 非同期ログを使用すると、システムクラッシュが発生した場合にいくつかのアクションが記録されない可能性があります。この状況は、他のアクションとは無関係に動作する別のスレッドでログの書き込みが実行されるために発生します。この問題を緩和する方法についての詳細は、​[「非同期ログでの例外処理」](#exception_handling)​を参照してください。 アプリケーションログを監査履歴として使用する場合は、必ず​**同期**​ログを使用するようにアプリケーションを設定してください。これにより、ログメッセージの損失が防止されます。
Mule 4 では、log4j のメモリ使用量を最適化するためにスレッドローカル機能が導入されています。この機能を使用しやすくするために、システムプロパティ ​AsyncLoggerConfig.RingBufferSize​ を設定できます (​「プロパティの設定」​を参照)。 20000​ が推奨値ですが、ニーズに合わせて調整する必要があります。
### [](#パフォーマンステスト)パフォーマンステスト 以下のチャートは、同期ログと非同期ログのパフォーマンスの違いと、同時メッセージ数の増加に応じてレイテンシーがどの程度増加したかを示しています。このテストでは、各実行で使用するスレッドの量を増加しながら、アプリケーションで約 100 万件のメッセージをログに記録しました。各トランザクションの結果、1,000 件のメッセージが生成されました。 ![レイテンシーと同時実行を比較する折れ線チャート](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/logging-latency-vs-concurrency.png) このチャートで示されているように、非同期でログを記録した場合の結果は、ログを記録しない場合の結果に非常に近くなりました。 ## [](#カスタムログの設定)カスタムログの設定 デフォルトでは、Mule では、ログは非同期の方法で INFO 以上のレベルで記録されます。デフォルトのログレベルでは、DEBUG または TRACE レベルのログメッセージは破棄されます。 同期ログを使用するには、ログレベルを調整するか、カスタムカテゴリを定義します。これらのプロパティは、ロガーの動作を指定する ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを使用して設定できます。このファイルを編集しない場合、Mule はデフォルトのプロパティを使用します。 Anypoint Studio では、​`log4j2.xml`​ は各 Mule オブジェクトの ​`src/main/resources`​ パスに含まれます。 デフォルト設定では、すべてのロガー (ルートロガーを含む) が非同期として定義されます。この設定はドメインまたはアプリケーションレベルで上書きできます。この設定をアプリケーションレベルで上書きするには、​`logConfigFile`​ エントリを ​`mule-artifact.json`​ ファイルに追加します。例: ```json { "minMuleVersion": "4.0.0", "logConfigFile": "../../../test-classes/resources/logging/custom-log4j2.xml" } ``` `log4j2.xml`​ ファイルのデフォルト設定を次に示します。 ```xml ``` ## [](#runtime-manager-エージェントのログの設定)Runtime Manager エージェントのログの設定
この設定は、Runtime Manager エージェント 1.5.2 以降を使用している場合のみ有効です。
Runtime Manager エージェントの状態をデフォルトの ​`mule_agent.log`​ ファイル以外の場所に記録するには、​`mule-agent-appender`​ という新しい Log4j 2 アペンダーを含めるように ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを設定します。含まれている場合、Runtime Manager エージェントプラグインはこのアペンダーを使用して状態を記録します。 この機能を有効にするには、​`log4j2.xml`​ ファイルに次のようなスニペットが含まれている必要があります。 ```xml (...) %d %p %c{1.} [%t] %m%n (...) ``` 上の例を使用すると、Runtime Manager エージェントはその状態を ​`$MULE_HOME/logs/custom_mule_agent.log`​ 内のローリングログファイルに記録します。このファイルは、250MB サイズに達するまで毎日繰り越されます。 他の Log4j 2 アペンダー設定については、Apache Log4j 2 のドキュメントを参照してください。 ## [](#exception_handling)非同期ログでの例外処理 非同期ログを使用していて、不完全なログが生成される可能性があるシステムクラッシュが発生した場合、LMAX ​`ExceptionHandler`​ ハンドラーが役立つ可能性があります。デフォルトでは、Mule はこのハンドラーを登録し、イベントをディスク、コンソール、および ​`logs/mule_ee.log`​ に記録します。独自の例外ハンドラーを提供するには、システムプロパティ ​`AsyncLoggerConfig.ExceptionHandler`​ を、インターフェースを実装するクラスの正規名に設定します。 デフォルトの例外ハンドラーを以下に示します。 ```java /* * Copyright (c) MuleSoft, Inc. All rights reserved. http://www.mulesoft.com * The software in this package is published under the terms of the CPAL v1.0 * license, a copy of which has been included with this distribution in the * LICENSE.txt file. */ package org.mule.runtime.module.launcher.api.log4j2; import com.lmax.disruptor.ExceptionHandler; import org.apache.logging.log4j.status.StatusLogger; /** * Implementation of {@link com.lmax.disruptor.ExceptionHandler} to be used when async loggers fail to log their messages. It will * log this event using the {@link org.apache.logging.log4j.status.StatusLogger} * * @since 3.6.0 */ public class AsyncLoggerExceptionHandler implements ExceptionHandler { private static final StatusLogger LOGGER = StatusLogger.getLogger(); @Override public void handleEventException(Throwable ex, long sequence, Object event) { LOGGER.error("Failed to asynchronously log message: " + event, ex); } @Override public void handleOnStartException(Throwable ex) { LOGGER.error("Failed to start asynchronous logger", ex); } @Override public void handleOnShutdownException(Throwable ex) { LOGGER.error("Failed to stop asynchronous logger", ex); } } ``` 非同期ログと同期ログの間には、パフォーマンスと信頼性のトレードオフがあります。ログメッセージの損失のリスクが重大な問題になる場合、ロガーを同期として設定します。同期ログと非同期ログの両方を組み合わせることができます。 ## [](#設定の再読み込み)設定の再読み込み Mule Runtime はログのフレームワークとして Log4j 2 を使用します。変更の有無を Log4j 2 で確認する監視間隔を追加または変更するには、​`monitorInterval`​ を ​`log4j2.xml`​ 設定ファイルに追加します。 1. Mule インストールフォルダーで ​`conf/log4j2.xml`​ を開きます。 2. 1 行目の後に ​``​ を追加します。例: ```xml ... ``` この例では、Log4j 2 は変更の有無を 15 秒ごとに確認します。 3. ファイルを保存して、Mule サーバーを再起動します。 詳細は、Log4j 2 の自動設定に関する Apache のドキュメントを参照してください。 ## [](#http-connector-を使用するプロジェクトのデバッグ)HTTP Connector を使用するプロジェクトのデバッグ HTTP Connector を使用するプロジェクトをデバッグするには、通常よりも詳細なログを記録し、プロジェクトでの HTTP Connector の ​`http-listener`​ および ​`http-request`​ 操作の動作をすべて追跡することをお勧めします。詳細は、​[『HTTP Connector トラブルシューティングガイド』](#connectors::http/http-troubleshooting.adoc)​を参照してください。 ## [](#soap-の要求および応答のログ)SOAP の要求および応答のログ 1. `src/main/resources`​ で ​`log4j2.xml`​ ファイルを開き、​`HttpMessageLogger`​ を設定に追加します。 ```xml ``` 2. プロジェクトを保存します。 ## [](#ログのトラブルシューティング)ログのトラブルシューティング ログ出力が表示されません クラスパスのルートで ​`log4j2.xml`​ を設定します。 Log4j 2 を再設定しましたが何も起こりません この問題は、別の ​`log4j2.xml`​ ファイルがクラスパスに存在し、変更前にそのファイルが選択されているために発生します。Log4j 2 がどの設定ファイルを使用しているかを確認するには、Mule の開始時に次のスイッチを追加します (または Mule を埋め込んでいる場合はコンテナの起動スクリプトに追加します)。 \-M-Dlog4j.debug=true このスイッチにより、使用されている設定ファイルの場所を含め、Log4j 2 の起動情報が ​`stdout`​ に書き込まれます。変更した設定を機能させる前に、この設定ファイルを削除する必要があります。 # ログの設定 MuleSoft は、Mule アプリケーションと Mule インスタンスの監視とトラブルシューティングに役立つアプリケーションログとランタイムログを提供します。 ## [](#アプリケーションログ)アプリケーションログ Studio でビルドするすべてのアプリケーションに、その独自の ​`log4j2.xml`​ ファイルが付属します。ログにはアプリケーションで発生したエラーに関する情報が含まれます (ただし、このエラーを処理するアプリケーションロジックがある場合を除く)。また、アプリケーション内でロジックをビルドした場合は、ログに明示的に記録する必要がある情報も含まれます。 Mule は、イベントのデバッグと追跡に役立つようにアプリケーションフロー内のいくつかのメッセージと特定の要素を自動的に記録します。また、​[Logger コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/logger-component-reference)​をフローの任意の場所に含めて、必要なメッセージを出力するようにセットアップすることもできます。 アプリケーションログは次の方法で表示できます。 - アプリケーションを Anypoint Studio から実行している場合、アプリケーションログからの出力は Anypoint Studio のコンソールウィンドウに表示されます。 - コマンドラインから Mule を使用してアプリケーションを実行している場合、アプリケーションログは OS コンソールに表示されます。 デフォルトでは、アプリケーションログファイルは ​`MULE_HOME/logs/.log`​ に保存されます。このログファイルのパスは Mule アプリケーションの ​`log4j2.xml`​ ファイルでカスタマイズできます。 ## [](#ランタイムログ)ランタイムログ ランタイムログ (​`mule_ee.log`​) にはアプリケーションとライフサイクルイベントに関する情報が含まれます。たとえば、Mule サービスまたはアプリケーションの開始、デプロイ、停止、またはアンデプロイ時にログにエントリが記録されます。 ランタイムログの設定は ​`/conf`​ ディレクトリの ​`log4j2.xml`​ ファイルに保存されます。このファイルは、オンプレミスで Mule を実行している場合にカスタマイズできます。 ### [](#anypoint-studio-でランタイムログを表示する)Anypoint Studio でランタイムログを表示する **\[Anypoint Studio\] > \[About Anypoint Studio (Anypoint Studio について)\] > \[Installation Details (インストールの詳細)\] > \[Configuration (設定)\] をクリックし、\[View Error Log (エラーログを表示)\]**​ をクリックします。 ![Anypoint Studio のエラーログビューアーインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/logging-in-mule-view-error-log.png) ### [](#ログレベルの変更)ログレベルの変更 `log4j2.xml`​ ファイルで次のパッケージの ​`level`​ 値を変更することで、ランタイムログのレベルを変更できます。 ```xml ``` 使用可能な値は、​`DEBUG`​、​`ERROR`​、​`INFO`​、​`TRACE`​、​`WARN`​ です。 特定のコネクタのログレベルのみを変更する場合は、​[「冗長ログの有効化」](https://docs.mulesoft.com/jp/mule-runtime/4.9/enable-verbose-logging)​を参照してください。 ## [](#ログの設定)ログの設定 設定ファイルを作成し、次の設定を定義できます。 - 記録するメッセージの種類 - メッセージの記録方法 (非同期または同期) - メッセージの記録場所 (コンソールまたはディスク、エンドポイントまたはデータベースなど) Mule は ​`slf4j`​ を使用します。これは、Apache Log4j 2 や JDK ロガーなど、クラスパスからログ戦略を検出して使用するログファサードです。デフォルトでは、Mule には Log4j 2 が含まれます。これは、​`log4j2.xml`​ というファイルで設定されます。 ## [](#同期ログと非同期ログの比較)同期ログと非同期ログの比較 デフォルトでは、Mule はメッセージを非同期で記録します。ログを同期的に記録すると、メッセージを処理しているスレッドの実行が中断し、ログメッセージが完全に処理されるまで待機した後、メッセージの処理を続行できます。 ![スレッド環境の同期ログ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/logger-synch.png) ログを非同期的に記録すると、ログ記録の操作は個別のスレッドで実行されるため、ログ記録が完了する前にメッセージを処理できます。 ![スレッド環境の非同期ログ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/logger-asynch-alternativo.png) MuleSoft は、ほとんどの状況で​**非同期ログ**​を使用することをお勧めします。大幅にスループットが向上し、メッセージ処理のレイテンシーが短縮されるためです。 非同期ログを使用すると、システムクラッシュが発生した場合にいくつかのアクションが記録されない可能性があります。この状況は、他のアクションとは無関係に動作する別のスレッドでログの書き込みが実行されるために発生します。この問題を緩和する方法についての詳細は、​[「非同期ログでの例外処理」](#exception_handling)​を参照してください。 アプリケーションログを監査履歴として使用する場合は、必ず​**同期**​ログを使用するようにアプリケーションを設定してください。これにより、ログメッセージの損失が防止されます。
Mule 4 では、log4j のメモリ使用量を最適化するためにスレッドローカル機能が導入されています。この機能を使用しやすくするために、システムプロパティ ​AsyncLoggerConfig.RingBufferSize​ を設定できます (​「プロパティの設定」​を参照)。 20000​ が推奨値ですが、ニーズに合わせて調整する必要があります。
### [](#パフォーマンステスト)パフォーマンステスト 以下のチャートは、同期ログと非同期ログのパフォーマンスの違いと、同時メッセージ数の増加に応じてレイテンシーがどの程度増加したかを示しています。このテストでは、各実行で使用するスレッドの量を増加しながら、アプリケーションで約 100 万件のメッセージをログに記録しました。各トランザクションの結果、1,000 件のメッセージが生成されました。 ![レイテンシーと同時実行を比較する折れ線チャート](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/logging-latency-vs-concurrency.png) このチャートで示されているように、非同期でログを記録した場合の結果は、ログを記録しない場合の結果に非常に近くなりました。 ## [](#カスタムログの設定)カスタムログの設定 デフォルトでは、Mule では、ログは非同期の方法で INFO 以上のレベルで記録されます。デフォルトのログレベルでは、DEBUG または TRACE レベルのログメッセージは破棄されます。 同期ログを使用するには、ログレベルを調整するか、カスタムカテゴリを定義します。これらのプロパティは、ロガーの動作を指定する ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを使用して設定できます。このファイルを編集しない場合、Mule はデフォルトのプロパティを使用します。 Anypoint Studio では、​`log4j2.xml`​ は各 Mule オブジェクトの ​`src/main/resources`​ パスに含まれます。 デフォルト設定では、すべてのロガー (ルートロガーを含む) が非同期として定義されます。この設定はドメインまたはアプリケーションレベルで上書きできます。この設定をアプリケーションレベルで上書きするには、​`logConfigFile`​ エントリを ​`mule-artifact.json`​ ファイルに追加します。例: ```json { "minMuleVersion": "4.0.0", "logConfigFile": "../../../test-classes/resources/logging/custom-log4j2.xml" } ``` `log4j2.xml`​ ファイルのデフォルト設定を次に示します。 ```xml ``` ## [](#runtime-manager-エージェントのログの設定)Runtime Manager エージェントのログの設定
この設定は、Runtime Manager エージェント 1.5.2 以降を使用している場合のみ有効です。
Runtime Manager エージェントの状態をデフォルトの ​`mule_agent.log`​ ファイル以外の場所に記録するには、​`mule-agent-appender`​ という新しい Log4j 2 アペンダーを含めるように ​`$MULE_HOME/conf/log4j2.xml`​ ファイルを設定します。含まれている場合、Runtime Manager エージェントプラグインはこのアペンダーを使用して状態を記録します。 この機能を有効にするには、​`log4j2.xml`​ ファイルに次のようなスニペットが含まれている必要があります。 ```xml (...) %d %p %c{1.} [%t] %m%n (...) ``` 上の例を使用すると、Runtime Manager エージェントはその状態を ​`$MULE_HOME/logs/custom_mule_agent.log`​ 内のローリングログファイルに記録します。このファイルは、250MB サイズに達するまで毎日繰り越されます。 他の Log4j 2 アペンダー設定については、Apache Log4j 2 のドキュメントを参照してください。 ## [](#exception_handling)非同期ログでの例外処理 非同期ログを使用していて、不完全なログが生成される可能性があるシステムクラッシュが発生した場合、LMAX ​`ExceptionHandler`​ ハンドラーが役立つ可能性があります。デフォルトでは、Mule はこのハンドラーを登録し、イベントをディスク、コンソール、および ​`logs/mule_ee.log`​ に記録します。独自の例外ハンドラーを提供するには、システムプロパティ ​`AsyncLoggerConfig.ExceptionHandler`​ を、インターフェースを実装するクラスの正規名に設定します。 デフォルトの例外ハンドラーを以下に示します。 ```java /* * Copyright (c) MuleSoft, Inc. All rights reserved. http://www.mulesoft.com * The software in this package is published under the terms of the CPAL v1.0 * license, a copy of which has been included with this distribution in the * LICENSE.txt file. */ package org.mule.runtime.module.launcher.api.log4j2; import com.lmax.disruptor.ExceptionHandler; import org.apache.logging.log4j.status.StatusLogger; /** * Implementation of {@link com.lmax.disruptor.ExceptionHandler} to be used when async loggers fail to log their messages. It will * log this event using the {@link org.apache.logging.log4j.status.StatusLogger} * * @since 3.6.0 */ public class AsyncLoggerExceptionHandler implements ExceptionHandler { private static final StatusLogger LOGGER = StatusLogger.getLogger(); @Override public void handleEventException(Throwable ex, long sequence, Object event) { LOGGER.error("Failed to asynchronously log message: " + event, ex); } @Override public void handleOnStartException(Throwable ex) { LOGGER.error("Failed to start asynchronous logger", ex); } @Override public void handleOnShutdownException(Throwable ex) { LOGGER.error("Failed to stop asynchronous logger", ex); } } ``` 非同期ログと同期ログの間には、パフォーマンスと信頼性のトレードオフがあります。ログメッセージの損失のリスクが重大な問題になる場合、ロガーを同期として設定します。同期ログと非同期ログの両方を組み合わせることができます。 ## [](#設定の再読み込み)設定の再読み込み Mule Runtime はログのフレームワークとして Log4j 2 を使用します。変更の有無を Log4j 2 で確認する監視間隔を追加または変更するには、​`monitorInterval`​ を ​`log4j2.xml`​ 設定ファイルに追加します。 1. Mule インストールフォルダーで ​`conf/log4j2.xml`​ を開きます。 2. 1 行目の後に ​``​ を追加します。例: ```xml ... ``` この例では、Log4j 2 は変更の有無を 15 秒ごとに確認します。 3. ファイルを保存して、Mule サーバーを再起動します。 詳細は、Log4j 2 の自動設定に関する Apache のドキュメントを参照してください。 ## [](#http-connector-を使用するプロジェクトのデバッグ)HTTP Connector を使用するプロジェクトのデバッグ HTTP Connector を使用するプロジェクトをデバッグするには、通常よりも詳細なログを記録し、プロジェクトでの HTTP Connector の ​`http-listener`​ および ​`http-request`​ 操作の動作をすべて追跡することをお勧めします。詳細は、​[『HTTP Connector トラブルシューティングガイド』](#connectors::http/http-troubleshooting.adoc)​を参照してください。 ## [](#soap-の要求および応答のログ)SOAP の要求および応答のログ 1. `src/main/resources`​ で ​`log4j2.xml`​ ファイルを開き、​`HttpMessageLogger`​ を設定に追加します。 ```xml ``` 2. プロジェクトを保存します。 ## [](#ログのトラブルシューティング)ログのトラブルシューティング ログ出力が表示されません クラスパスのルートで ​`log4j2.xml`​ を設定します。 Log4j 2 を再設定しましたが何も起こりません この問題は、別の ​`log4j2.xml`​ ファイルがクラスパスに存在し、変更前にそのファイルが選択されているために発生します。Log4j 2 がどの設定ファイルを使用しているかを確認するには、Mule の開始時に次のスイッチを追加します (または Mule を埋め込んでいる場合はコンテナの起動スクリプトに追加します)。 \-M-Dlog4j.debug=true このスイッチにより、使用されている設定ファイルの場所を含め、Log4j 2 の起動情報が ​`stdout`​ に書き込まれます。変更した設定を機能させる前に、この設定ファイルを削除する必要があります。 # ワークフロー: Anypoint Studio UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-input-output-structure-transformation-studio-task)​ 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-graphically-construct-mapping-studio-task)​ 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力をビルドすることもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-preview-transformation-output-studio-task)​ 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # ワークフロー: Anypoint Studio UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-input-output-structure-transformation-studio-task)​ 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-graphically-construct-mapping-studio-task)​ 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力を構築することもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-preview-transformation-output-studio-task)​ 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # ワークフロー: Anypoint Studio UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-input-output-structure-transformation-studio-task) 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-graphically-construct-mapping-studio-task) 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力を構築することもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-preview-transformation-output-studio-task) 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # ワークフロー: Anypoint Studio UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-input-output-structure-transformation-studio-task)​ 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-graphically-construct-mapping-studio-task)​ 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力をビルドすることもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-preview-transformation-output-studio-task)​ 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # ワークフロー: Anypoint Studio UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-input-output-structure-transformation-studio-task)​ 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-graphically-construct-mapping-studio-task)​ 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力をビルドすることもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-preview-transformation-output-studio-task)​ 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # ワークフロー: Anypoint Studio UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-input-output-structure-transformation-studio-task)​ 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-graphically-construct-mapping-studio-task)​ 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力をビルドすることもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-preview-transformation-output-studio-task)​ 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # ワークフロー: Anypoint Studio UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-input-output-structure-transformation-studio-task)​ 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-graphically-construct-mapping-studio-task)​ 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力をビルドすることもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-preview-transformation-output-studio-task)​ 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # ワークフロー: Design Center UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-input-output-structure-transformation-design-center-task) 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-graphically-construct-mapping-design-center-task) 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力をビルドすることもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-preview-transformation-output-design-center-task) 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # ワークフロー: Design Center UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-input-output-structure-transformation-design-center-task) 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-graphically-construct-mapping-design-center-task) 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力を構築することもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-preview-transformation-output-design-center-task) 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # ワークフロー: Design Center UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-input-output-structure-transformation-design-center-task) 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-graphically-construct-mapping-design-center-task) 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力を構築することもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-preview-transformation-output-design-center-task) 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # ワークフロー: Design Center UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-input-output-structure-transformation-design-center-task) 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-graphically-construct-mapping-design-center-task) 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力をビルドすることもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-preview-transformation-output-design-center-task) 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # ワークフロー: Design Center UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-input-output-structure-transformation-design-center-task) 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-graphically-construct-mapping-design-center-task) 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力をビルドすることもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-preview-transformation-output-design-center-task) 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # ワークフロー: Design Center UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-input-output-structure-transformation-design-center-task) 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-graphically-construct-mapping-design-center-task) 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力をビルドすることもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-preview-transformation-output-design-center-task) 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # ワークフロー: Design Center UI でのマッピングの作成 1. [変換の入力および出力構造の定義](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-input-output-structure-transformation-design-center-task) 予想される入力構造と必要な出力構造を定義します。 2. [マッピングのグラフィカルな作成](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-graphically-construct-mapping-design-center-task) 入力の要素をドラッグして、出力の要素にドロップします。固定値や関数を使用して出力をビルドすることもできます。 3. [変換の出力のプレビュー](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-preview-transformation-output-design-center-task) 変換で予想される出力が生成されることを確認します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # 一般的な開発戦略 Mule アプリケーションの開発を容易にするには、一般的な開発戦略と方法を考慮します。たとえば、再現可能なビルドを作成したり、設定ファイルをモジュール化したりします。また、信頼性パターン、トランザクションの管理、継続的インテグレーション、Mule のオーケストレーション、およびエンタープライズインテグレーションパターンを実装します。 ## [](#再現可能なビルドの作成)再現可能なビルドの作成 再現可能なビルドを作成し、特定のバージョンの Mule プロジェクトを任意のタイミングで実行することで、アプリケーションのメンテナンスを容易にします。この目標は次により達成することができます。 - Mule プロジェクトのソース制御を使用する - Apache Maven と社内マネージャーを使用して連動関係を管理する。 詳細は、​[「再現可能なビルド」](https://docs.mulesoft.com/jp/mule-runtime/4.3/reproducible-builds)​のドキュメントを参照してください。 ## [](#信頼性パターンの実装)信頼性パターンの実装 アプリケーション設計に信頼性パターンを実装し、非トランザクションコネクタからメッセージを受信した場合でも、アプリケーションで信頼性の高いメッセージングができるようにします。信頼性パターン設計では、信頼性の高い取得フローがアプリケーションロジックフローに結合されます。 詳細は、​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.3/reliability-patterns)​のドキュメントを参照してください。 ## [](#トランザクションの管理の実装)トランザクションの管理の実装 Mule アプリケーションの結果を不確定のままにしておくことができない場合、その Mule アプリケーションにトランザクション操作を実装します。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 さまざまなトランザクション種別およびトランザクションアクション操作の詳細や、メッセージソースまたは Try スコープでトランザクションを設定する方法については、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management)​のドキュメントを参照してください。 また、​[単一リソーストランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.3/single-resource-transaction)​、​[XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.3/xa-transactions)​、​[Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/using-bitronix-to-manage-transactions)​を実装することもできます。 ## [](#設定ファイルのモジュール化)設定ファイルのモジュール化 単体の設定を複数のファイルに分割することで設定ファイルをモジュール化し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込みます。Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。複数のチームが同じプロジェクトで作業を行っているか、再利用に重点が置かれている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule 設定をモジュール化すると、それらのチームに作業を分割できます。複数の設定ファイルを読み込むオプションは 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートします。 詳細は、​[「設定ファイルのモジュール化」](https://docs.mulesoft.com/jp/mule-runtime/4.3/modularizing-your-configuration-files-for-team-development)​のドキュメントを参照してください。 ## [](#継続的インテグレーションの実装)継続的インテグレーションの実装 Maven をビルドツールとして使用して、プロジェクトの継続的インテグレーション (CI) を実装します。プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行します。これにより、次のことができます。 - ソフトウェア開発ライフサイクルの問題の早期通知を取得する。 - リリース前にコードを完全にテストする。 - メイン分岐へのマージ時に正常にテストされた分岐が成功しやすくなることを確認する。 詳細は、​[「継続的インテグレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.3/continuous-integration)​のドキュメントを参照してください。 ## [](#mule-のオーケストレーションの実装)Mule のオーケストレーションの実装 Mule のオーケストレーションを実装し、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にします。オーケストレーションでは、さまざまなアプリケーションや情報システムのビジネス固有のサービスを組み合わせたビジネスレベルのプロセスが実装されます。 オーケストレーションを行うフローのユースケースを次に示します。 - シンプルなインテグレーション。 - データ処理のスケジューリング。 - クラウドアプリケーションとオンプレミスアプリケーションの接続。 - 複数のサービスを構成して同時に動作させる必要があるイベント処理。 詳細は、​[「Mule を使用したオーケストレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.3/understanding-orchestration-using-mule)​のドキュメントを参照してください。 ## [](#エンタープライズインテグレーションパターンの実装)エンタープライズインテグレーションパターンの実装 エンタープライズインテグレーションパターンをメッセージングシステムやインテグレーションシステムの設計とビルドのソリューションとして実装するだけでなく、エンタープライズインテグレーションパターンを実装して、ソリューションの設計時にチームが使用する共通言語を提供します。 詳細は、​[「Mule を使用したエンタープライズインテグレーションパターン」](https://docs.mulesoft.com/jp/mule-runtime/4.3/understanding-enterprise-integration-patterns-using-mule)​のドキュメントを参照してください。 ## [](#ビジネスイベント追跡の設定)ビジネスイベント追跡の設定 Mule アプリケーションは、ビジネストランザクションを処理するフローおよびメッセージプロセッサーに関するビジネスイベント情報を収集できます。サポートされるコンポーネントやフロー全体に対してデフォルトイベント追跡を設定できます。また、Custom Business Events コンポーネントを使用してカスタムイベント追跡を設定することもできます。 詳細は、​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.3/business-events)​のドキュメントを参照してください。 ## [](#アプリケーションの共有)アプリケーションの共有 複数のチームが同じプロジェクトで作業を行っているか、再利用が意図されている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule アプリケーションを共有して、それらのチームに作業を分割します。 詳細は、​[「アプリケーションの共有」](https://docs.mulesoft.com/jp/mule-runtime/4.3/sharing-applications)​のドキュメントを参照してください。 ## [](#mule-アプリケーション作成のベストプラクティス)Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 詳細は、​[「Mule アプリケーション作成のベストプラクティス」](https://docs.mulesoft.com/jp/mule-runtime/4.3/build-app-practices)​ドキュメントを参照してください。 # 一般的な開発戦略 Mule アプリケーションの開発を容易にするには、一般的な開発戦略と方法を考慮します。たとえば、再現可能なビルドを作成したり、設定ファイルをモジュール化したりします。また、信頼性パターン、トランザクションの管理、継続的インテグレーション、Mule のオーケストレーション、およびエンタープライズインテグレーションパターンを実装します。 ## [](#再現可能なビルドの作成)再現可能なビルドの作成 再現可能なビルドを作成し、特定のバージョンの Mule プロジェクトを任意のタイミングで実行することで、アプリケーションのメンテナンスを容易にします。この目標は次により達成することができます。 - Mule プロジェクトのソース制御を使用する - Apache Maven と社内マネージャーを使用して連動関係を管理する。 詳細は、​[「再現可能なビルド」](https://docs.mulesoft.com/jp/mule-runtime/4.4/reproducible-builds)​のドキュメントを参照してください。 ## [](#信頼性パターンの実装)信頼性パターンの実装 アプリケーション設計に信頼性パターンを実装し、非トランザクションコネクタからメッセージを受信した場合でも、アプリケーションで信頼性の高いメッセージングができるようにします。信頼性パターン設計では、信頼性の高い取得フローがアプリケーションロジックフローに結合されます。 詳細は、​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.4/reliability-patterns)​のドキュメントを参照してください。 ## [](#トランザクションの管理の実装)トランザクションの管理の実装 Mule アプリケーションの結果を不確定のままにしておくことができない場合、その Mule アプリケーションにトランザクション操作を実装します。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 さまざまなトランザクション種別およびトランザクションアクション操作の詳細や、Mule イベントソースまたは Try スコープでトランザクションを設定する方法については、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management)​のドキュメントを参照してください。 また、​[単一リソーストランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.4/single-resource-transaction)​、​[XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.4/xa-transactions)​、​[Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/using-bitronix-to-manage-transactions)​を実装することもできます。 ## [](#設定ファイルのモジュール化)設定ファイルのモジュール化 単体の設定を複数のファイルに分割することで設定ファイルをモジュール化し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込みます。Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。複数のチームが同じプロジェクトで作業を行っているか、再利用に重点が置かれている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule 設定をモジュール化すると、それらのチームに作業を分割できます。複数の設定ファイルを読み込むオプションは 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートします。 詳細は、​[「設定ファイルのモジュール化」](https://docs.mulesoft.com/jp/mule-runtime/4.4/modularizing-your-configuration-files-for-team-development)​のドキュメントを参照してください。 ## [](#継続的インテグレーションの実装)継続的インテグレーションの実装 Maven をビルドツールとして使用して、プロジェクトの継続的インテグレーション (CI) を実装します。プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行します。これにより、次のことができます。 - ソフトウェア開発ライフサイクルの問題の早期通知を取得する。 - リリース前にコードを完全にテストする。 - メイン分岐へのマージ時に正常にテストされた分岐が成功しやすくなることを確認する。 詳細は、​[「継続的インテグレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.4/continuous-integration)​のドキュメントを参照してください。 ## [](#mule-のオーケストレーションの実装)Mule のオーケストレーションの実装 Mule のオーケストレーションを実装し、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にします。オーケストレーションでは、さまざまなアプリケーションや情報システムのビジネス固有のサービスを組み合わせたビジネスレベルのプロセスが実装されます。 オーケストレーションを行うフローのユースケースを次に示します。 - シンプルなインテグレーション。 - データ処理のスケジューリング。 - クラウドアプリケーションとオンプレミスアプリケーションの接続。 - 複数のサービスを構成して同時に動作させる必要があるイベント処理。 詳細は、​[「Mule を使用したオーケストレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.4/understanding-orchestration-using-mule)​のドキュメントを参照してください。 ## [](#エンタープライズインテグレーションパターンの実装)エンタープライズインテグレーションパターンの実装 エンタープライズインテグレーションパターンをメッセージングシステムやインテグレーションシステムの設計とビルドのソリューションとして実装するだけでなく、エンタープライズインテグレーションパターンを実装して、ソリューションの設計時にチームが使用する共通言語を提供します。 詳細は、​[「Mule を使用したエンタープライズインテグレーションパターン」](https://docs.mulesoft.com/jp/mule-runtime/4.4/understanding-enterprise-integration-patterns-using-mule)​のドキュメントを参照してください。 ## [](#ビジネスイベント追跡の設定)ビジネスイベント追跡の設定 Mule アプリケーションは、ビジネストランザクションを処理するフローおよびメッセージプロセッサーに関するビジネスイベント情報を収集できます。サポートされるコンポーネントやフロー全体に対してデフォルトイベント追跡を設定できます。また、Custom Business Events コンポーネントを使用してカスタムイベント追跡を設定することもできます。 詳細は、​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.4/business-events)​のドキュメントを参照してください。 ## [](#アプリケーションの共有)アプリケーションの共有 複数のチームが同じプロジェクトで作業を行っているか、再利用が意図されている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule アプリケーションを共有して、それらのチームに作業を分割します。 詳細は、​[「アプリケーションの共有」](https://docs.mulesoft.com/jp/mule-runtime/4.4/sharing-applications)​のドキュメントを参照してください。 ## [](#mule-アプリケーション作成のベストプラクティス)Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 詳細は、​[「Mule アプリケーション作成のベストプラクティス」](https://docs.mulesoft.com/jp/mule-runtime/4.4/build-app-practices)​ドキュメントを参照してください。 # 一般的な開発戦略 Mule アプリケーションの開発を容易にするには、一般的な開発戦略と方法を考慮します。たとえば、再現可能なビルドを作成したり、設定ファイルをモジュール化したりします。また、信頼性パターン、トランザクションの管理、継続的インテグレーション、Mule のオーケストレーション、およびエンタープライズインテグレーションパターンを実装します。 ## [](#再現可能なビルドの作成)再現可能なビルドの作成 再現可能なビルドを作成し、特定のバージョンの Mule プロジェクトを任意のタイミングで実行することで、アプリケーションのメンテナンスを容易にします。この目標は次により達成することができます。 - Mule プロジェクトのソース制御を使用する - Apache Maven と社内マネージャーを使用して連動関係を管理する。 詳細は、​[「再現可能なビルド」](https://docs.mulesoft.com/jp/mule-runtime/4.5/reproducible-builds)​のドキュメントを参照してください。 ## [](#信頼性パターンの実装)信頼性パターンの実装 アプリケーション設計に信頼性パターンを実装し、非トランザクションコネクタからメッセージを受信した場合でも、アプリケーションで信頼性の高いメッセージングができるようにします。信頼性パターン設計では、信頼性の高い取得フローがアプリケーションロジックフローに結合されます。 詳細は、​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.5/reliability-patterns)​のドキュメントを参照してください。 ## [](#トランザクションの管理の実装)トランザクションの管理の実装 Mule アプリケーションの結果を不確定のままにしておくことができない場合、その Mule アプリケーションにトランザクション操作を実装します。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 さまざまなトランザクション種別およびトランザクションアクション操作の詳細や、Mule イベントソースまたは Try スコープでトランザクションを設定する方法については、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management)​のドキュメントを参照してください。 また、​[単一リソーストランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.5/single-resource-transaction)​、​[XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.5/xa-transactions)​、​[Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/using-bitronix-to-manage-transactions)​を実装することもできます。 ## [](#設定ファイルのモジュール化)設定ファイルのモジュール化 単体の設定を複数のファイルに分割することで設定ファイルをモジュール化し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込みます。Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。複数のチームが同じプロジェクトで作業を行っているか、再利用に重点が置かれている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule 設定をモジュール化すると、それらのチームに作業を分割できます。複数の設定ファイルを読み込むオプションは 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートします。 詳細は、​[「設定ファイルのモジュール化」](https://docs.mulesoft.com/jp/mule-runtime/4.5/modularizing-your-configuration-files-for-team-development)​のドキュメントを参照してください。 ## [](#継続的インテグレーションの実装)継続的インテグレーションの実装 Maven をビルドツールとして使用して、プロジェクトの継続的インテグレーション (CI) を実装します。プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行します。これにより、次のことができます。 - ソフトウェア開発ライフサイクルの問題の早期通知を取得する。 - リリース前にコードを完全にテストする。 - メイン分岐へのマージ時に正常にテストされた分岐が成功しやすくなることを確認する。 詳細は、​[「継続的インテグレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.5/continuous-integration)​のドキュメントを参照してください。 ## [](#mule-のオーケストレーションの実装)Mule のオーケストレーションの実装 Mule のオーケストレーションを実装し、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にします。オーケストレーションでは、さまざまなアプリケーションや情報システムのビジネス固有のサービスを組み合わせたビジネスレベルのプロセスが実装されます。 オーケストレーションを行うフローのユースケースを次に示します。 - シンプルなインテグレーション。 - データ処理のスケジューリング。 - クラウドアプリケーションとオンプレミスアプリケーションの接続。 - 複数のサービスを構成して同時に動作させる必要があるイベント処理。 詳細は、​[「Mule を使用したオーケストレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.5/understanding-orchestration-using-mule)​のドキュメントを参照してください。 ## [](#エンタープライズインテグレーションパターンの実装)エンタープライズインテグレーションパターンの実装 エンタープライズインテグレーションパターンをメッセージングシステムやインテグレーションシステムの設計とビルドのソリューションとして実装するだけでなく、エンタープライズインテグレーションパターンを実装して、ソリューションの設計時にチームが使用する共通言語を提供します。 詳細は、​[「Mule を使用したエンタープライズインテグレーションパターン」](https://docs.mulesoft.com/jp/mule-runtime/4.5/understanding-enterprise-integration-patterns-using-mule)​のドキュメントを参照してください。 ## [](#ビジネスイベント追跡の設定)ビジネスイベント追跡の設定 Mule アプリケーションは、ビジネストランザクションを処理するフローおよびメッセージプロセッサーに関するビジネスイベント情報を収集できます。サポートされるコンポーネントやフロー全体に対してデフォルトイベント追跡を設定できます。また、Custom Business Events コンポーネントを使用してカスタムイベント追跡を設定することもできます。 詳細は、​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.5/business-events)​のドキュメントを参照してください。 ## [](#アプリケーションの共有)アプリケーションの共有 アプリケーションの共有複数のチームが同じプロジェクトで作業を行っているか、再利用が意図されている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule アプリケーションを共有して、それらのチームに作業を分割します。 詳細は、​[「アプリケーションの共有」](https://docs.mulesoft.com/jp/mule-runtime/4.5/sharing-applications)​のドキュメントを参照してください。 ## [](#mule-アプリケーション作成のベストプラクティス)Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 詳細は、​[「Mule アプリケーション作成のベストプラクティス」](https://docs.mulesoft.com/jp/mule-runtime/4.5/build-app-practices)​ドキュメントを参照してください。 # 一般的な開発戦略 Mule アプリケーションの開発を容易にするには、一般的な開発戦略と方法を考慮します。たとえば、再現可能なビルドを作成したり、設定ファイルをモジュール化したりします。また、信頼性パターン、トランザクションの管理、継続的インテグレーション、Mule のオーケストレーション、およびエンタープライズインテグレーションパターンを実装します。 ## [](#再現可能なビルドの作成)再現可能なビルドの作成 再現可能なビルドを作成し、特定のバージョンの Mule プロジェクトを任意のタイミングで実行することで、アプリケーションのメンテナンスを容易にします。この目標は次により達成することができます。 - Mule プロジェクトのソース制御を使用する - Apache Maven と社内マネージャーを使用して連動関係を管理する。 詳細は、​[「再現可能なビルド」](https://docs.mulesoft.com/jp/mule-runtime/4.6/reproducible-builds)​のドキュメントを参照してください。 ## [](#信頼性パターンの実装)信頼性パターンの実装 アプリケーション設計に信頼性パターンを実装し、非トランザクションコネクタからメッセージを受信した場合でも、アプリケーションで信頼性の高いメッセージングができるようにします。信頼性パターン設計では、信頼性の高い取得フローがアプリケーションロジックフローに結合されます。 詳細は、​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.6/reliability-patterns)​のドキュメントを参照してください。 ## [](#トランザクションの管理の実装)トランザクションの管理の実装 Mule アプリケーションの結果を不確定のままにしておくことができない場合、その Mule アプリケーションにトランザクション操作を実装します。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 さまざまなトランザクション種別およびトランザクションアクション操作の詳細や、Mule イベントソースまたは Try スコープでトランザクションを設定する方法については、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management)​のドキュメントを参照してください。 また、​[単一リソーストランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.6/single-resource-transaction)​、​[XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.6/xa-transactions)​、​[Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/using-bitronix-to-manage-transactions)​を実装することもできます。 ## [](#設定ファイルのモジュール化)設定ファイルのモジュール化 単体の設定を複数のファイルに分割することで設定ファイルをモジュール化し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込みます。Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。複数のチームが同じプロジェクトで作業を行っているか、再利用に重点が置かれている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule 設定をモジュール化すると、それらのチームに作業を分割できます。複数の設定ファイルを読み込むオプションは 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートします。 詳細は、​[「設定ファイルのモジュール化」](https://docs.mulesoft.com/jp/mule-runtime/4.6/modularizing-your-configuration-files-for-team-development)​のドキュメントを参照してください。 ## [](#継続的インテグレーションの実装)継続的インテグレーションの実装 Maven をビルドツールとして使用して、プロジェクトの継続的インテグレーション (CI) を実装します。プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行します。これにより、次のことができます。 - ソフトウェア開発ライフサイクルの問題の早期通知を取得する。 - リリース前にコードを完全にテストする。 - メイン分岐へのマージ時に正常にテストされた分岐が成功しやすくなることを確認する。 詳細は、​[「継続的インテグレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.6/continuous-integration)​のドキュメントを参照してください。 ## [](#mule-のオーケストレーションの実装)Mule のオーケストレーションの実装 Mule のオーケストレーションを実装し、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にします。オーケストレーションでは、さまざまなアプリケーションや情報システムのビジネス固有のサービスを組み合わせたビジネスレベルのプロセスが実装されます。 オーケストレーションを行うフローのユースケースを次に示します。 - シンプルなインテグレーション。 - データ処理のスケジューリング。 - クラウドアプリケーションとオンプレミスアプリケーションの接続。 - 複数のサービスを構成して同時に動作させる必要があるイベント処理。 詳細は、​[「Mule を使用したオーケストレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.6/understanding-orchestration-using-mule)​のドキュメントを参照してください。 ## [](#エンタープライズインテグレーションパターンの実装)エンタープライズインテグレーションパターンの実装 エンタープライズインテグレーションパターンをメッセージングシステムやインテグレーションシステムの設計とビルドのソリューションとして実装するだけでなく、エンタープライズインテグレーションパターンを実装して、ソリューションの設計時にチームが使用する共通言語を提供します。 詳細は、​[「Mule を使用したエンタープライズインテグレーションパターン」](https://docs.mulesoft.com/jp/mule-runtime/4.6/understanding-enterprise-integration-patterns-using-mule)​のドキュメントを参照してください。 ## [](#ビジネスイベント追跡の設定)ビジネスイベント追跡の設定 Mule アプリケーションは、ビジネストランザクションを処理するフローおよびメッセージプロセッサーに関するビジネスイベント情報を収集できます。サポートされるコンポーネントやフロー全体に対してデフォルトイベント追跡を設定できます。また、Custom Business Events コンポーネントを使用してカスタムイベント追跡を設定することもできます。 詳細は、​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.6/business-events)​のドキュメントを参照してください。 ## [](#アプリケーションの共有)アプリケーションの共有 複数のチームが同じプロジェクトで作業を行っているか、再利用が意図されている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule アプリケーションを共有して、それらのチームに作業を分割します。 詳細は、​[「アプリケーションの共有」](https://docs.mulesoft.com/jp/mule-runtime/4.6/sharing-applications)​のドキュメントを参照してください。 ## [](#mule-アプリケーション作成のベストプラクティス)Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 詳細は、​[「Mule アプリケーション作成のベストプラクティス」](https://docs.mulesoft.com/jp/mule-runtime/4.6/build-app-practices)​ドキュメントを参照してください。 # 一般的な開発戦略 Mule アプリケーションの開発を容易にするには、一般的な開発戦略と方法を考慮します。たとえば、再現可能なビルドを作成したり、設定ファイルをモジュール化したりします。また、信頼性パターン、トランザクションの管理、継続的インテグレーション、Mule のオーケストレーション、およびエンタープライズインテグレーションパターンを実装します。 ## [](#再現可能なビルドの作成)再現可能なビルドの作成 再現可能なビルドを作成し、特定のバージョンの Mule プロジェクトを任意のタイミングで実行することで、アプリケーションのメンテナンスを容易にします。この目標は次により達成することができます。 - Mule プロジェクトのソース制御を使用する - Apache Maven と社内マネージャーを使用して連動関係を管理する。 詳細は、​[「再現可能なビルド」](https://docs.mulesoft.com/jp/mule-runtime/4.7/reproducible-builds)​のドキュメントを参照してください。 ## [](#信頼性パターンの実装)信頼性パターンの実装 アプリケーション設計に信頼性パターンを実装し、非トランザクションコネクタからメッセージを受信した場合でも、アプリケーションで信頼性の高いメッセージングができるようにします。信頼性パターン設計では、信頼性の高い取得フローがアプリケーションロジックフローに結合されます。 詳細は、​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.7/reliability-patterns)​のドキュメントを参照してください。 ## [](#トランザクションの管理の実装)トランザクションの管理の実装 Mule アプリケーションの結果を不確定のままにしておくことができない場合、その Mule アプリケーションにトランザクション操作を実装します。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 さまざまなトランザクション種別およびトランザクションアクション操作の詳細や、Mule イベントソースまたは Try スコープでトランザクションを設定する方法については、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management)​のドキュメントを参照してください。 また、​[単一リソーストランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.7/single-resource-transaction)​、​[XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.7/xa-transactions)​、​[Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/using-bitronix-to-manage-transactions)​を実装することもできます。 ## [](#設定ファイルのモジュール化)設定ファイルのモジュール化 単体の設定を複数のファイルに分割することで設定ファイルをモジュール化し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込みます。Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。複数のチームが同じプロジェクトで作業を行っているか、再利用に重点が置かれている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule 設定をモジュール化すると、それらのチームに作業を分割できます。複数の設定ファイルを読み込むオプションは 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートします。 詳細は、​[「設定ファイルのモジュール化」](https://docs.mulesoft.com/jp/mule-runtime/4.7/modularizing-your-configuration-files-for-team-development)​のドキュメントを参照してください。 ## [](#継続的インテグレーションの実装)継続的インテグレーションの実装 Maven をビルドツールとして使用して、プロジェクトの継続的インテグレーション (CI) を実装します。プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行します。これにより、次のことができます。 - ソフトウェア開発ライフサイクルの問題の早期通知を取得する。 - リリース前にコードを完全にテストする。 - メイン分岐へのマージ時に正常にテストされた分岐が成功しやすくなることを確認する。 詳細は、​[「継続的インテグレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.7/continuous-integration)​のドキュメントを参照してください。 ## [](#mule-のオーケストレーションの実装)Mule のオーケストレーションの実装 Mule のオーケストレーションを実装し、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にします。オーケストレーションでは、さまざまなアプリケーションや情報システムのビジネス固有のサービスを組み合わせたビジネスレベルのプロセスが実装されます。 オーケストレーションを行うフローのユースケースを次に示します。 - シンプルなインテグレーション。 - データ処理のスケジューリング。 - クラウドアプリケーションとオンプレミスアプリケーションの接続。 - 複数のサービスを構成して同時に動作させる必要があるイベント処理。 詳細は、​[「Mule を使用したオーケストレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.7/understanding-orchestration-using-mule)​のドキュメントを参照してください。 ## [](#エンタープライズインテグレーションパターンの実装)エンタープライズインテグレーションパターンの実装 エンタープライズインテグレーションパターンをメッセージングシステムやインテグレーションシステムの設計とビルドのソリューションとして実装するだけでなく、エンタープライズインテグレーションパターンを実装して、ソリューションの設計時にチームが使用する共通言語を提供します。 詳細は、​[「Mule を使用したエンタープライズインテグレーションパターン」](https://docs.mulesoft.com/jp/mule-runtime/4.7/understanding-enterprise-integration-patterns-using-mule)​のドキュメントを参照してください。 ## [](#ビジネスイベント追跡の設定)ビジネスイベント追跡の設定 Mule アプリケーションは、ビジネストランザクションを処理するフローおよびメッセージプロセッサーに関するビジネスイベント情報を収集できます。サポートされるコンポーネントやフロー全体に対してデフォルトイベント追跡を設定できます。また、Custom Business Events コンポーネントを使用してカスタムイベント追跡を設定することもできます。 詳細は、​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.7/business-events)​のドキュメントを参照してください。 ## [](#アプリケーションの共有)アプリケーションの共有 複数のチームが同じプロジェクトで作業を行っているか、再利用が意図されている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule アプリケーションを共有して、それらのチームに作業を分割します。 詳細は、​[「アプリケーションの共有」](https://docs.mulesoft.com/jp/mule-runtime/4.7/sharing-applications)​のドキュメントを参照してください。 ## [](#mule-アプリケーション作成のベストプラクティス)Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 詳細は、​[「Mule アプリケーション作成のベストプラクティス」](https://docs.mulesoft.com/jp/mule-runtime/4.7/build-app-practices)​ドキュメントを参照してください。 # 一般的な開発戦略 Mule アプリケーションの開発を容易にするには、一般的な開発戦略と方法を考慮します。たとえば、再現可能なビルドを作成したり、設定ファイルをモジュール化したりします。また、信頼性パターン、トランザクションの管理、継続的インテグレーション、Mule のオーケストレーション、およびエンタープライズインテグレーションパターンを実装します。 ## [](#再現可能なビルドの作成)再現可能なビルドの作成 再現可能なビルドを作成し、特定のバージョンの Mule プロジェクトを任意のタイミングで実行することで、アプリケーションのメンテナンスを容易にします。この目標は次により達成することができます。 - Mule プロジェクトのソース制御を使用する - Apache Maven と社内マネージャーを使用して連動関係を管理する。 詳細は、​[「再現可能なビルド」](https://docs.mulesoft.com/jp/mule-runtime/4.8/reproducible-builds)​のドキュメントを参照してください。 ## [](#信頼性パターンの実装)信頼性パターンの実装 アプリケーション設計に信頼性パターンを実装し、非トランザクションコネクタからメッセージを受信した場合でも、アプリケーションで信頼性の高いメッセージングができるようにします。信頼性パターン設計では、信頼性の高い取得フローがアプリケーションロジックフローに結合されます。 詳細は、​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.8/reliability-patterns)​のドキュメントを参照してください。 ## [](#トランザクションの管理の実装)トランザクションの管理の実装 Mule アプリケーションの結果を不確定のままにしておくことができない場合、その Mule アプリケーションにトランザクション操作を実装します。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 さまざまなトランザクション種別およびトランザクションアクション操作の詳細や、Mule イベントソースまたは Try スコープでトランザクションを設定する方法については、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management)​のドキュメントを参照してください。 また、​[単一リソーストランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.8/single-resource-transaction)​、​[XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.8/xa-transactions)​、​[Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/using-bitronix-to-manage-transactions)​を実装することもできます。 ## [](#設定ファイルのモジュール化)設定ファイルのモジュール化 単体の設定を複数のファイルに分割することで設定ファイルをモジュール化し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込みます。Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。複数のチームが同じプロジェクトで作業を行っているか、再利用に重点が置かれている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule 設定をモジュール化すると、それらのチームに作業を分割できます。複数の設定ファイルを読み込むオプションは 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートします。 詳細は、​[「設定ファイルのモジュール化」](https://docs.mulesoft.com/jp/mule-runtime/4.8/modularizing-your-configuration-files-for-team-development)​のドキュメントを参照してください。 ## [](#継続的インテグレーションの実装)継続的インテグレーションの実装 Maven をビルドツールとして使用して、プロジェクトの継続的インテグレーション (CI) を実装します。プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行します。これにより、次のことができます。 - ソフトウェア開発ライフサイクルの問題の早期通知を取得する。 - リリース前にコードを完全にテストする。 - メイン分岐へのマージ時に正常にテストされた分岐が成功しやすくなることを確認する。 詳細は、​[「継続的インテグレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.8/continuous-integration)​のドキュメントを参照してください。 ## [](#mule-のオーケストレーションの実装)Mule のオーケストレーションの実装 Mule のオーケストレーションを実装し、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にします。オーケストレーションでは、さまざまなアプリケーションや情報システムのビジネス固有のサービスを組み合わせたビジネスレベルのプロセスが実装されます。 オーケストレーションを行うフローのユースケースを次に示します。 - シンプルなインテグレーション。 - データ処理のスケジューリング。 - クラウドアプリケーションとオンプレミスアプリケーションの接続。 - 複数のサービスを構成して同時に動作させる必要があるイベント処理。 詳細は、​[「Mule を使用したオーケストレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.8/understanding-orchestration-using-mule)​のドキュメントを参照してください。 ## [](#エンタープライズインテグレーションパターンの実装)エンタープライズインテグレーションパターンの実装 エンタープライズインテグレーションパターンをメッセージングシステムやインテグレーションシステムの設計とビルドのソリューションとして実装するだけでなく、エンタープライズインテグレーションパターンを実装して、ソリューションの設計時にチームが使用する共通言語を提供します。 詳細は、​[「Mule を使用したエンタープライズインテグレーションパターン」](https://docs.mulesoft.com/jp/mule-runtime/4.8/understanding-enterprise-integration-patterns-using-mule)​のドキュメントを参照してください。 ## [](#ビジネスイベント追跡の設定)ビジネスイベント追跡の設定 Mule アプリケーションは、ビジネストランザクションを処理するフローおよびメッセージプロセッサーに関するビジネスイベント情報を収集できます。サポートされるコンポーネントやフロー全体に対してデフォルトイベント追跡を設定できます。また、Custom Business Events コンポーネントを使用してカスタムイベント追跡を設定することもできます。 詳細は、​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.8/business-events)​のドキュメントを参照してください。 ## [](#アプリケーションの共有)アプリケーションの共有 複数のチームが同じプロジェクトで作業を行っているか、再利用が意図されている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule アプリケーションを共有して、それらのチームに作業を分割します。 詳細は、​[「アプリケーションの共有」](https://docs.mulesoft.com/jp/mule-runtime/4.8/sharing-applications)​のドキュメントを参照してください。 ## [](#mule-アプリケーション作成のベストプラクティス)Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 詳細は、​[「Mule アプリケーション作成のベストプラクティス」](https://docs.mulesoft.com/jp/mule-runtime/4.8/build-app-practices)​ドキュメントを参照してください。 # 一般的な開発戦略 Mule アプリケーションの開発を容易にするには、一般的な開発戦略と方法を考慮します。たとえば、再現可能なビルドを作成したり、設定ファイルをモジュール化したりします。また、信頼性パターン、トランザクションの管理、継続的インテグレーション、Mule のオーケストレーション、およびエンタープライズインテグレーションパターンを実装します。 ## [](#再現可能なビルドの作成)再現可能なビルドの作成 再現可能なビルドを作成し、特定のバージョンの Mule プロジェクトを任意のタイミングで実行することで、アプリケーションのメンテナンスを容易にします。この目標は次により達成することができます。 - Mule プロジェクトのソース制御を使用する - Apache Maven と社内マネージャーを使用して連動関係を管理する。 詳細は、​[「再現可能なビルド」](https://docs.mulesoft.com/jp/mule-runtime/4.9/reproducible-builds)​のドキュメントを参照してください。 ## [](#信頼性パターンの実装)信頼性パターンの実装 アプリケーション設計に信頼性パターンを実装し、非トランザクションコネクタからメッセージを受信した場合でも、アプリケーションで信頼性の高いメッセージングができるようにします。信頼性パターン設計では、信頼性の高い取得フローがアプリケーションロジックフローに結合されます。 詳細は、​[「信頼性パターン」](https://docs.mulesoft.com/jp/mule-runtime/4.9/reliability-patterns)​のドキュメントを参照してください。 ## [](#トランザクションの管理の実装)トランザクションの管理の実装 Mule アプリケーションの結果を不確定のままにしておくことができない場合、その Mule アプリケーションにトランザクション操作を実装します。フローの一連のステップが 1 つの単位として成功または失敗する必要がある場合、Mule はトランザクションを使用して、それらのステップを単位として区分します。 さまざまなトランザクション種別およびトランザクションアクション操作の詳細や、Mule イベントソースまたは Try スコープでトランザクションを設定する方法については、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management)​のドキュメントを参照してください。 また、​[単一リソーストランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.9/single-resource-transaction)​、​[XA トランザクション](https://docs.mulesoft.com/jp/mule-runtime/4.9/xa-transactions)​、​[Bitronix を使用したトランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/using-bitronix-to-manage-transactions)​を実装することもできます。 ## [](#設定ファイルのモジュール化)設定ファイルのモジュール化 単体の設定を複数のファイルに分割することで設定ファイルをモジュール化し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込みます。Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。複数のチームが同じプロジェクトで作業を行っているか、再利用に重点が置かれている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule 設定をモジュール化すると、それらのチームに作業を分割できます。複数の設定ファイルを読み込むオプションは 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートします。 詳細は、​[「設定ファイルのモジュール化」](https://docs.mulesoft.com/jp/mule-runtime/4.9/modularizing-your-configuration-files-for-team-development)​のドキュメントを参照してください。 ## [](#継続的インテグレーションの実装)継続的インテグレーションの実装 Maven をビルドツールとして使用して、プロジェクトの継続的インテグレーション (CI) を実装します。プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行します。これにより、次のことができます。 - ソフトウェア開発ライフサイクルの問題の早期通知を取得する。 - リリース前にコードを完全にテストする。 - メイン分岐へのマージ時に正常にテストされた分岐が成功しやすくなることを確認する。 詳細は、​[「継続的インテグレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.9/continuous-integration)​のドキュメントを参照してください。 ## [](#mule-のオーケストレーションの実装)Mule のオーケストレーションの実装 Mule のオーケストレーションを実装し、フローに基づいて Mule 実装内でデータを移動するプロセスを容易にします。オーケストレーションでは、さまざまなアプリケーションや情報システムのビジネス固有のサービスを組み合わせたビジネスレベルのプロセスが実装されます。 オーケストレーションを行うフローのユースケースを次に示します。 - シンプルなインテグレーション。 - データ処理のスケジューリング。 - クラウドアプリケーションとオンプレミスアプリケーションの接続。 - 複数のサービスを構成して同時に動作させる必要があるイベント処理。 詳細は、​[「Mule を使用したオーケストレーション」](https://docs.mulesoft.com/jp/mule-runtime/4.9/understanding-orchestration-using-mule)​のドキュメントを参照してください。 ## [](#エンタープライズインテグレーションパターンの実装)エンタープライズインテグレーションパターンの実装 エンタープライズインテグレーションパターンをメッセージングシステムやインテグレーションシステムの設計とビルドのソリューションとして実装するだけでなく、エンタープライズインテグレーションパターンを実装して、ソリューションの設計時にチームが使用する共通言語を提供します。 詳細は、​[「Mule を使用したエンタープライズインテグレーションパターン」](https://docs.mulesoft.com/jp/mule-runtime/4.9/understanding-enterprise-integration-patterns-using-mule)​のドキュメントを参照してください。 ## [](#ビジネスイベント追跡の設定)ビジネスイベント追跡の設定 Mule アプリケーションは、ビジネストランザクションを処理するフローおよびメッセージプロセッサーに関するビジネスイベント情報を収集できます。サポートされるコンポーネントやフロー全体に対してデフォルトイベント追跡を設定できます。また、Custom Business Events コンポーネントを使用してカスタムイベント追跡を設定することもできます。 詳細は、​[「ビジネスイベント」](https://docs.mulesoft.com/jp/mule-runtime/4.9/business-events)​のドキュメントを参照してください。 ## [](#アプリケーションの共有)アプリケーションの共有 複数のチームが同じプロジェクトで作業を行っているか、再利用が意図されている異なる複数のプロジェクトで作業を行っているかにかかわらず、Mule アプリケーションを共有して、それらのチームに作業を分割します。 詳細は、​[「アプリケーションの共有」](https://docs.mulesoft.com/jp/mule-runtime/4.9/sharing-applications)​のドキュメントを参照してください。 ## [](#mule-アプリケーション作成のベストプラクティス)Mule アプリケーション作成のベストプラクティス アプリケーションを作成する場合は、見やすく整理された持続性の高いプロジェクトを作成するために、以下のベストプラクティスを考慮してください。これらのプラクティスには、Anypoint Studio の使用、アプリケーション作成時の問題の回避、Mule Runtime Engine (Mule) のコンポーネントやコネクタを使用するための設定に関するガイドラインが含まれています。 詳細は、​[「Mule アプリケーション作成のベストプラクティス」](https://docs.mulesoft.com/jp/mule-runtime/4.9/build-app-practices)​ドキュメントを参照してください。 # 信頼性パターン 信頼性パターンとは、アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、アプリケーションのメッセージングが信頼できるようになるデザインです。信頼性パターンでは、次の図で示しているように、信頼性の高い取得フローとアプリケーションロジックフローを組み合わせています。 ![Reliability\_Pattern](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/reliability-pattern.png) 信頼性の高い取得フロー (図の左側) は、トランザクションを実装しないメッセージソースからトランザクションを実装するコネクタのアウトバウンド操作にメッセージを確実に配信します。操作は、VM や JMS など、任意の種別のトランザクションエンドポイントにできます。信頼性の高い取得フローは、メッセージを配信できない場合でもメッセージが失われないようにします。 - HTTP などのソケットベースの接続の場合、これはクライアントが要求を再試行できるように「要求失敗」応答をクライアントに返すことを意味します。 - ファイルや FTP などのリソースベースの接続の場合、再処理できるようにファイルを削除しないことを意味します。 アプリケーションロジックフロー (図の右側) は、トランザクションコネクタを使用するメッセージソースからアプリケーションのビジネスロジックにメッセージを配信します。 ## [](#信頼性の高いメッセージング)信頼性の高いメッセージング 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。 アプリケーションで JMS、VM、DB などのトランザクション接続を使用する場合、信頼性の高いメッセージングはコネクタでのトランザクションのビルトインサポートで確保されます。つまり、たとえばトランザクションがコミットされたときに JMS サーバーからのみメッセージが削除されるようにするトランザクションを JMS リスナーで設定できます。これにより、メッセージの処理中にエラーが発生した場合でも、まだ再処理できるようになります。言い換えると、こうしたコネクタでのトランザクションサポートにより、接続元から操作に、またはフロー内のプロセッサー間でメッセージが確実に配信されるようになります。 トランザクションをサポートする異なるコネクタ間でメッセージを移動する場合は、XA トランザクションを使用して両方のコネクタのトランザクションが 1 つのユニットとしてコミットされるようにします。 XA をはじめとするトランザクションの種別についての詳細は、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management)​を参照してください。 HTTP などの非トランザクションコネクタを使用する Web アプリケーションがある場合、信頼性パターンに従ってアプリケーションで信頼性の高いメッセージングを確保してください。 ## [](#信頼性パターンでのエンドポイントの比較)信頼性パターンでのエンドポイントの比較 信頼性の高い取得フローは任意の種別のトランザクションエンドポイントと組み合わせることができます。信頼性パターンで VM エンドポイントを使用する必要はありません。次の図は、信頼性の高い取得フローがメッセージを JMS エンドポイントに配信する信頼性パターンを示しています。 ![ReliabilityPatternwithJMS](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/reliabilitypatternwithjms.png) 次の表は、信頼性の高い取得フローで VM、JMS、JDBC エンドポイントを使用した場合のメリットとデメリットを示しています。
エンドポイント メリット デメリット

ファイルベースの VM (スタンドアロン Mule)

  • Mule ですぐに使用できます。追加のソフトウェアが必要ありません。

  • 非クラスター環境にのみ適用されます。

JDBC

  • 使用できるリソースに応じて、JDBC が大量の情報を保持できます。

  • 追加のソフトウェア (データベースサーバー) が必要です。

  • 適切な DBMS スキーマが必要なため、複雑になる場合があります。

JMS (永続性に有効)

  • クラスター環境と非クラスター環境の両方に適用されます。

  • 追加のソフトウェア (メッセージキューサーバー) が必要です。
VM および JMS のメモリ内永続性セットアップは、メッセージが失われる可能性があり、信頼性が高いとみなされないため、比較には含まれません。
## [](#信頼性パターンの実装)信頼性パターンの実装 次に、信頼性の高い取得フローとアプリケーションロジックフローを含む信頼性パターンの全体像となるコード例を示します。この例では、信頼性パターンのうち信頼性の高い取得フローは「HTTP から VM」の部分です。 ### [](#例-http-から-vm)例: HTTP から VM ```xml (1) (2) ```
1メッセージは VM キューに書き込まれます。メインフローで処理できるようになりました。
2メッセージはトランザクション的に VM キューから読み取られます。これにより、エラーが発生した場合、読み取りがロールバックされ、メッセージが再処理されるようになります。
Studio でこの XML の例をテストするには、VM Connector の連動関係をプロジェクトの ​`pom.xml`​ ファイルに追加します。
この例は VM ファイルの永続性を示していますが、クラスターでは機能しません。
## [](#信頼性の高い取得フローの実装)信頼性の高い取得フローの実装 [\[implementing-a-reliability-pattern\]](#implementing-a-reliability-pattern)​で示している例は、VM のパブリッシュ操作に対する HTTP リスナーの信頼性の高い取得フローを示していました。このシナリオでは、非トランザクションメッセージソースがある信頼性の高い取得フローに重点を置きます: FTP-to-VM (または SFTP、FTPS)。 この場合、リソースベースの接続が使用されます。リソースベースの接続を使用する場合、必ずリソースを 1 回だけ読み取るようにしてください。これは、​`watermarkEnabled`​ を ​`true`​ に設定することで実行されます。 `auto-delete`​ パラメーターを ​`true`​ に設定すると、処理が別のフローによって実行された場合であってもフローが完了した時点で直ちにファイルが削除されるため、そのように設定しないでください。同じことは ​`moveToDirectory`​ にも言えます。 ### [](#例-ftp-から-vm)例: FTP から VM 次のコードでは、パブリッシュ操作による FTP リスナー (On New または Updated File) から VM キューへの信頼性の高い取得フローを実装しています。 ```xml (1) (2) ```
1VM にパブリッシュする前に変換を実行するには、最大再配信数を追加します。
2ファイルを削除したくない場合は、​ftp:delete​ 操作を使用しないでください。目的の操作が ​ftp:move​ の場合にも同じことが言えます。
他のリソースベースのコネクタについても同じような実装が行われます。 ## [](#一般的な考慮事項)一般的な考慮事項 信頼性パターンを実装するときには、次の点に注意してください。 - コネクタ (メッセージソース) で許可されている場合は、必ずトランザクションを使用してください。 - 同じトランザクション内の複数の管理対象リソースを取得する場合は、XA トランザクションを使用してメッセージソースをブリッジします。 - JMS の信頼性は MQ 実装およびその設定に関連付けられています。ほとんどの MQ 実装では、メッセージがメモリ内のみに保存されるか、それとも保持されるかを設定できます。信頼性を実現できるのは、メッセージを転送する前に永続的に保存するように MQ サーバーを設定している場合のみです。それ以外の場合、万一 MQ サーバーがクラッシュしたときにメッセージが失われるリスクがあります。 - 信頼性はパフォーマンスに影響を及ぼします。 - 信頼性の高い取得フローのアウトバウンド操作が非トランザクション (たとえば、ファイルから FTP へのフロー) の場合、その操作を ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/try-scope-concept)​内で実行します。この方法では、操作が正常に完了したかどうかを確認でき、失敗した場合はエラーメッセージが記録されきます。 # 信頼性パターン 信頼性パターンとは、アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、アプリケーションのメッセージングが信頼できるようになるデザインです。信頼性パターンでは、次の図で示しているように、信頼性の高い取得フローとアプリケーションロジックフローを組み合わせています。 ![Reliability\_Pattern](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/reliability-pattern.png) 信頼性の高い取得フロー (図の左側) は、トランザクションを実装しない Mule イベントソースからトランザクションを実装するコネクタのアウトバウンド操作にメッセージを確実に配信します。操作は、VM や JMS など、任意の種別のトランザクションエンドポイントにできます。信頼性の高い取得フローは、メッセージを配信できない場合でもメッセージが失われないようにします。 - HTTP などのソケットベースの接続の場合、これはクライアントが要求を再試行できるように「要求失敗」応答をクライアントに返すことを意味します。 - ファイルや FTP などのリソースベースの接続の場合、再処理できるようにファイルを削除しないことを意味します。 アプリケーションロジックフロー (図の右側) は、トランザクションコネクタを使用するイベントソースからアプリケーションのビジネスロジックにメッセージを配信します。 ## [](#信頼性の高いメッセージング)信頼性の高いメッセージング 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。 アプリケーションで JMS、VM、DB などのトランザクション接続を使用する場合、信頼性の高いメッセージングはコネクタでのトランザクションのビルトインサポートで確保されます。つまり、たとえばトランザクションがコミットされたときに JMS サーバーからのみメッセージが削除されるようにするトランザクションを JMS リスナーで設定できます。これにより、メッセージの処理中にエラーが発生した場合でも、まだ再処理できるようになります。言い換えると、こうしたコネクタでのトランザクションサポートにより、接続元から操作に、またはフロー内のプロセッサー間でメッセージが確実に配信されるようになります。 トランザクションをサポートする異なるコネクタ間でメッセージを移動する場合は、XA トランザクションを使用して両方のコネクタのトランザクションが 1 つのユニットとしてコミットされるようにします。 XA をはじめとするトランザクションの種別についての詳細は、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management)​を参照してください。 HTTP などの非トランザクションコネクタを使用する Web アプリケーションがある場合、信頼性パターンに従ってアプリケーションで信頼性の高いメッセージングを確保してください。 ## [](#信頼性パターンでのエンドポイントの比較)信頼性パターンでのエンドポイントの比較 信頼性の高い取得フローは任意の種別のトランザクションエンドポイントと組み合わせることができます。信頼性パターンで VM エンドポイントを使用する必要はありません。次の図は、信頼性の高い取得フローがメッセージを JMS エンドポイントに配信する信頼性パターンを示しています。 ![ReliabilityPatternwithJMS](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/reliabilitypatternwithjms.png) 次の表は、信頼性の高い取得フローで VM、JMS、JDBC エンドポイントを使用した場合のメリットとデメリットを示しています。
エンドポイント メリット デメリット

ファイルベースの VM (スタンドアロン Mule)

  • Mule ですぐに使用できます。追加のソフトウェアが必要ありません。

  • 非クラスター環境にのみ適用されます。

JDBC

  • 使用できるリソースに応じて、JDBC が大量の情報を保持できます。

  • 追加のソフトウェア (データベースサーバー) が必要です。

  • 適切な DBMS スキーマが必要なため、複雑になる場合があります。

JMS (永続性に有効)

  • クラスター環境と非クラスター環境の両方に適用されます。

  • 追加のソフトウェア (メッセージキューサーバー) が必要です。
この比較には、VM および JMS のメモリ内の永続性設定は含まれていません。これらはメッセージが失われている可能性があり、信頼性が高いとみなされないためです。
## [](#信頼性パターンの実装)信頼性パターンの実装 次に、信頼性の高い取得フローとアプリケーションロジックフローを含む信頼性パターンの全体像となるコード例を示します。この例では、信頼性パターンのうち信頼性の高い取得フローは「HTTP から VM」の部分です。 ### [](#例-http-から-vm)例: HTTP から VM ```xml (1) (2) ```
1メッセージは VM キューに書き込まれます。メインフローで処理できるようになりました。
2メッセージはトランザクション的に VM キューから読み取られます。これにより、エラーが発生した場合、読み取りがロールバックされ、メッセージが再処理されるようになります。
Studio でこの XML の例をテストするには、VM Connector の連動関係をプロジェクトの ​`pom.xml`​ ファイルに追加します。
この例は VM ファイルの永続性を示していますが、クラスターでは機能しません。
## [](#信頼性の高い取得フローの実装)信頼性の高い取得フローの実装 [\[implementing-a-reliability-pattern\]](#implementing-a-reliability-pattern)​で示している例は、VM のパブリッシュ操作に対する HTTP リスナーの信頼性の高い取得フローを示していました。このシナリオでは、非トランザクションイベントソースがある信頼性の高い取得フローに重点を置きます: FTP-to-VM (または SFTP、FTPS)。 この場合、リソースベースの接続が使用されます。リソースベースの接続を使用する場合、必ずリソースを 1 回だけ読み取るようにしてください。これは、​`watermarkEnabled`​ を ​`true`​ に設定することで実行されます。 `auto-delete`​ パラメーターを ​`true`​ に設定すると、処理が別のフローによって実行された場合であってもフローが完了した時点で直ちにファイルが削除されるため、そのように設定しないでください。同じことは ​`moveToDirectory`​ にも言えます。 ### [](#例-ftp-から-vm)例: FTP から VM 次のコードでは、パブリッシュ操作による FTP リスナー (On New または Updated File) から VM キューへの信頼性の高い取得フローを実装しています。 ```xml (1) (2) ```
1VM にパブリッシュする前に変換を実行するには、最大再配信数を追加します。
2ファイルを削除したくない場合は、​ftp:delete​ 操作を使用しないでください。目的の操作が ​ftp:move​ の場合にも同じことが言えます。
他のリソースベースのコネクタについても同じような実装が行われます。 ## [](#一般的な考慮事項)一般的な考慮事項 信頼性パターンを実装するときには、次の点に注意してください。 - コネクタ (イベントソース) で許可されている場合は、必ずトランザクションを使用してください。 - 同じトランザクション内の複数の管理対象リソースを取得する場合は、XA トランザクションを使用してイベントソースをブリッジします。 - JMS の信頼性は MQ 実装およびその設定に関連付けられています。ほとんどの MQ 実装では、メッセージがメモリ内のみに保存されるか、それとも保持されるかを設定できます。信頼性を実現できるのは、メッセージを転送する前に永続的に保存するように MQ サーバーを設定している場合のみです。それ以外の場合、万一 MQ サーバーがクラッシュしたときにメッセージが失われるリスクがあります。 - 信頼性はパフォーマンスに影響を及ぼします。 - 信頼性の高い取得フローのアウトバウンド操作が非トランザクション (たとえば、ファイルから FTP へのフロー) の場合、その操作を ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/try-scope-concept)​内で実行します。この方法では、操作が正常に完了したかどうかを確認でき、失敗した場合はエラーメッセージが記録されきます。 # 信頼性パターン 信頼性パターンとは、アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、アプリケーションのメッセージングが信頼できるようになるデザインです。信頼性パターンでは、次の図で示しているように、信頼性の高い取得フローとアプリケーションロジックフローを組み合わせています。 ![Reliability\_Pattern](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/reliability-pattern.png) 信頼性の高い取得フロー (図の左側) は、トランザクションを実装しない Mule イベントソースからトランザクションを実装するコネクタのアウトバウンド操作にメッセージを確実に配信します。操作は、VM や JMS など、任意の種別のトランザクションエンドポイントにできます。信頼性の高い取得フローは、メッセージを配信できない場合でもメッセージが失われないようにします。 - HTTP などのソケットベースの接続の場合、これはクライアントが要求を再試行できるように「要求失敗」応答をクライアントに返すことを意味します。 - ファイルや FTP などのリソースベースの接続の場合、再処理できるようにファイルを削除しないことを意味します。 アプリケーションロジックフロー (図の右側) は、トランザクションコネクタを使用するイベントソースからアプリケーションのビジネスロジックにメッセージを配信します。 ## [](#信頼性の高いメッセージング)信頼性の高いメッセージング 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。 アプリケーションで JMS、VM、DB などのトランザクション接続を使用する場合、信頼性の高いメッセージングはコネクタでのトランザクションのビルトインサポートで確保されます。つまり、たとえばトランザクションがコミットされたときに JMS サーバーからのみメッセージが削除されるようにするトランザクションを JMS リスナーで設定できます。これにより、メッセージの処理中にエラーが発生した場合でも、まだ再処理できるようになります。言い換えると、こうしたコネクタでのトランザクションサポートにより、接続元から操作に、またはフロー内のプロセッサー間でメッセージが確実に配信されるようになります。 トランザクションをサポートする異なるコネクタ間でメッセージを移動する場合は、XA トランザクションを使用して両方のコネクタのトランザクションが 1 つのユニットとしてコミットされるようにします。 XA をはじめとするトランザクションの種別についての詳細は、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management)​を参照してください。 HTTP などの非トランザクションコネクタを使用する Web アプリケーションがある場合、信頼性パターンに従ってアプリケーションで信頼性の高いメッセージングを確保してください。 ## [](#信頼性パターンでのエンドポイントの比較)信頼性パターンでのエンドポイントの比較 信頼性の高い取得フローは任意の種別のトランザクションエンドポイントと組み合わせることができます。信頼性パターンで VM エンドポイントを使用する必要はありません。次の図は、信頼性の高い取得フローがメッセージを JMS エンドポイントに配信する信頼性パターンを示しています。 ![ReliabilityPatternwithJMS](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/reliabilitypatternwithjms.png) 次の表は、信頼性の高い取得フローで VM、JMS、JDBC エンドポイントを使用した場合のメリットとデメリットを示しています。
エンドポイント メリット デメリット

ファイルベースの VM (スタンドアロン Mule)

  • Mule ですぐに使用できます。追加のソフトウェアが必要ありません。

  • 非クラスター環境にのみ適用されます。

JDBC

  • 使用できるリソースに応じて、JDBC が大量の情報を保持できます。

  • 追加のソフトウェア (データベースサーバー) が必要です。

  • 適切な DBMS スキーマが必要なため、複雑になる場合があります。

JMS (永続性に有効)

  • クラスター環境と非クラスター環境の両方に適用されます。

  • 追加のソフトウェア (メッセージキューサーバー) が必要です。
この比較には、VM および JMS のメモリ内の永続性設定は含まれていません。これらはメッセージが失われている可能性があり、信頼性が高いとみなされないためです。
## [](#信頼性パターンの実装)信頼性パターンの実装 次に、信頼性の高い取得フローとアプリケーションロジックフローを含む信頼性パターンの全体像となるコード例を示します。この例では、信頼性パターンのうち信頼性の高い取得フローは「HTTP から VM」の部分です。 ### [](#例-http-から-vm)例: HTTP から VM ```xml (1) (2) ```
1メッセージは VM キューに書き込まれます。メインフローで処理できるようになりました。
2メッセージはトランザクション的に VM キューから読み取られます。これにより、エラーが発生した場合、読み取りがロールバックされ、メッセージが再処理されるようになります。
Studio でこの XML の例をテストするには、VM Connector の連動関係をプロジェクトの ​`pom.xml`​ ファイルに追加します。
この例は VM ファイルの永続性を示していますが、クラスターでは機能しません。
## [](#信頼性の高い取得フローの実装)信頼性の高い取得フローの実装 「​[\[implementing-a-reliability-pattern\]](#implementing-a-reliability-pattern)​」で示している例は、VM のパブリッシュ操作に対する HTTP リスナーの信頼性の高い取得フローを示していました。このシナリオでは、非トランザクションイベントソースがある信頼性の高い取得フローに重点を置きます: FTP-to-VM (または SFTP、FTPS)。 この場合、リソースベースの接続が使用されます。リソースベースの接続を使用する場合、必ずリソースを 1 回だけ読み取るようにしてください。これは、​`watermarkEnabled`​ を ​`true`​ に設定することで実行されます。 `auto-delete`​ パラメーターを ​`true`​ に設定すると、処理が別のフローによって実行された場合であってもフローが完了した時点で直ちにファイルが削除されるため、そのように設定しないでください。同じことは ​`moveToDirectory`​ にも言えます。 ### [](#例-ftp-から-vm)例: FTP から VM 次のコードでは、パブリッシュ操作による FTP リスナー (On New または Updated File) から VM キューへの信頼性の高い取得フローを実装しています。 ```xml (1) (2) ```
1VM にパブリッシュする前に変換を実行するには、最大再配信数を追加します。
2ファイルを削除したくない場合は、​ftp:delete​ 操作を使用しないでください。目的の操作が ​ftp:move​ の場合にも同じことが言えます。
他のリソースベースのコネクタについても同じような実装が行われます。 ## [](#一般的な考慮事項)一般的な考慮事項 信頼性パターンを実装するときには、次の点に注意してください。 - コネクタ (イベントソース) で許可されている場合は、必ずトランザクションを使用してください。 - 同じトランザクション内の複数の管理対象リソースを取得する場合は、XA トランザクションを使用してイベントソースをブリッジします。 - JMS の信頼性は MQ 実装およびその設定に関連付けられています。ほとんどの MQ 実装では、メッセージがメモリ内のみに保存されるか、それとも保持されるかを設定できます。信頼性を実現できるのは、メッセージを転送する前に永続的に保存するように MQ サーバーを設定している場合のみです。それ以外の場合、万一 MQ サーバーがクラッシュしたときにメッセージが失われるリスクがあります。 - 信頼性はパフォーマンスに影響を及ぼします。 - 信頼性の高い取得フローのアウトバウンド操作が非トランザクション (たとえば、ファイルから FTP へのフロー) の場合、その操作を ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/try-scope-concept)​内で実行します。この方法では、操作が正常に完了したかどうかを確認でき、失敗した場合はエラーメッセージが記録されきます。 # 信頼性パターン 信頼性パターンとは、アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、アプリケーションのメッセージングが信頼できるようになるデザインです。信頼性パターンでは、次の図で示しているように、信頼性の高い取得フローとアプリケーションロジックフローを組み合わせています。 ![Reliability\_Pattern](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/reliability-pattern.png) 信頼性の高い取得フロー (図の左側) は、トランザクションを実装しない Mule イベントソースからトランザクションを実装するコネクタのアウトバウンド操作にメッセージを確実に配信します。操作は、VM や JMS など、任意の種別のトランザクションエンドポイントにできます。信頼性の高い取得フローは、メッセージを配信できない場合でもメッセージが失われないようにします。 - HTTP などのソケットベースの接続の場合、これはクライアントが要求を再試行できるように「要求失敗」応答をクライアントに返すことを意味します。 - ファイルや FTP などのリソースベースの接続の場合、再処理できるようにファイルを削除しないことを意味します。 アプリケーションロジックフロー (図の右側) は、トランザクションコネクタを使用するイベントソースからアプリケーションのビジネスロジックにメッセージを配信します。 ## [](#信頼性の高いメッセージング)信頼性の高いメッセージング 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。 アプリケーションで JMS、VM、DB などのトランザクション接続を使用する場合、信頼性の高いメッセージングはコネクタでのトランザクションのビルトインサポートで確保されます。つまり、たとえばトランザクションがコミットされたときに JMS サーバーからのみメッセージが削除されるようにするトランザクションを JMS リスナーで設定できます。これにより、メッセージの処理中にエラーが発生した場合でも、まだ再処理できるようになります。言い換えると、こうしたコネクタでのトランザクションサポートにより、接続元から操作に、またはフロー内のプロセッサー間でメッセージが確実に配信されるようになります。 トランザクションをサポートする異なるコネクタ間でメッセージを移動する場合は、XA トランザクションを使用して両方のコネクタのトランザクションが 1 つのユニットとしてコミットされるようにします。 XA をはじめとするトランザクションの種別についての詳細は、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management)​を参照してください。 HTTP などの非トランザクションコネクタを使用する Web アプリケーションがある場合、信頼性パターンに従ってアプリケーションで信頼性の高いメッセージングを確保してください。 ## [](#信頼性パターンでのエンドポイントの比較)信頼性パターンでのエンドポイントの比較 信頼性の高い取得フローは任意の種別のトランザクションエンドポイントと組み合わせることができます。信頼性パターンで VM エンドポイントを使用する必要はありません。次の図は、信頼性の高い取得フローがメッセージを JMS エンドポイントに配信する信頼性パターンを示しています。 ![ReliabilityPatternwithJMS](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/reliabilitypatternwithjms.png) 次の表は、信頼性の高い取得フローで VM、JMS、JDBC エンドポイントを使用した場合のメリットとデメリットを示しています。
エンドポイント メリット デメリット

ファイルベースの VM (スタンドアロン Mule)

  • Mule ですぐに使用できます。追加のソフトウェアが必要ありません。

  • 非クラスター環境にのみ適用されます。

JDBC

  • 使用できるリソースに応じて、JDBC が大量の情報を保持できます。

  • 追加のソフトウェア (データベースサーバー) が必要です。

  • 適切な DBMS スキーマが必要なため、複雑になる場合があります。

JMS (永続性に有効)

  • クラスター環境と非クラスター環境の両方に適用されます。

  • 追加のソフトウェア (メッセージキューサーバー) が必要です。
この比較には、VM および JMS のメモリ内の永続性設定は含まれていません。これらはメッセージが失われている可能性があり、信頼性が高いとみなされないためです。
## [](#信頼性パターンの実装)信頼性パターンの実装 次に、信頼性の高い取得フローとアプリケーションロジックフローを含む信頼性パターンの全体像となるコード例を示します。この例では、信頼性パターンのうち信頼性の高い取得フローは「HTTP から VM」の部分です。 ### [](#例-http-から-vm)例: HTTP から VM ```xml (1) (2) ```
1メッセージは VM キューに書き込まれます。メインフローで処理できるようになりました。
2メッセージはトランザクション的に VM キューから読み取られます。これにより、エラーが発生した場合、読み取りがロールバックされ、メッセージが再処理されるようになります。
Studio でこの XML の例をテストするには、VM Connector の連動関係をプロジェクトの ​`pom.xml`​ ファイルに追加します。
この例は VM ファイルの永続性を示していますが、クラスターでは機能しません。
## [](#信頼性の高い取得フローの実装)信頼性の高い取得フローの実装 [\[implementing-a-reliability-pattern\]](#implementing-a-reliability-pattern)​で示している例は、VM のパブリッシュ操作に対する HTTP リスナーの信頼性の高い取得フローを示していました。このシナリオでは、非トランザクションイベントソースがある信頼性の高い取得フローに重点を置きます: FTP-to-VM (または SFTP、FTPS)。 この場合、リソースベースの接続が使用されます。リソースベースの接続を使用する場合、必ずリソースを 1 回だけ読み取るようにしてください。これは、​`watermarkEnabled`​ を ​`true`​ に設定することで実行されます。 `auto-delete`​ パラメーターを ​`true`​ に設定すると、処理が別のフローによって実行された場合であってもフローが完了した時点で直ちにファイルが削除されるため、そのように設定しないでください。同じことは ​`moveToDirectory`​ にも言えます。 ### [](#例-ftp-から-vm)例: FTP から VM 次のコードでは、パブリッシュ操作による FTP リスナー (On New または Updated File) から VM キューへの信頼性の高い取得フローを実装しています。 ```xml (1) (2) ```
1VM にパブリッシュする前に変換を実行するには、最大再配信数を追加します。
2ファイルを削除したくない場合は、​ftp:delete​ 操作を使用しないでください。目的の操作が ​ftp:move​ の場合にも同じことが言えます。
他のリソースベースのコネクタについても同じような実装が行われます。 ## [](#一般的な考慮事項)一般的な考慮事項 信頼性パターンを実装するときには、次の点に注意してください。 - コネクタ (イベントソース) で許可されている場合は、必ずトランザクションを使用してください。 - 同じトランザクション内の複数の管理対象リソースを取得する場合は、XA トランザクションを使用してイベントソースをブリッジします。 - JMS の信頼性は MQ 実装およびその設定に関連付けられています。ほとんどの MQ 実装では、メッセージがメモリ内のみに保存されるか、それとも保持されるかを設定できます。信頼性を実現できるのは、メッセージを転送する前に永続的に保存するように MQ サーバーを設定している場合のみです。それ以外の場合、万一 MQ サーバーがクラッシュしたときにメッセージが失われるリスクがあります。 - 信頼性はパフォーマンスに影響を及ぼします。 - 信頼性の高い取得フローのアウトバウンド操作が非トランザクション (たとえば、ファイルから FTP へのフロー) の場合、その操作を ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/try-scope-concept)​内で実行します。この方法では、操作が正常に完了したかどうかを確認でき、失敗した場合はエラーメッセージが記録されきます。 # 信頼性パターン 信頼性パターンとは、アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、アプリケーションのメッセージングが信頼できるようになるデザインです。信頼性パターンでは、次の図で示しているように、信頼性の高い取得フローとアプリケーションロジックフローを組み合わせています。 ![Reliability\_Pattern](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/reliability-pattern.png) 信頼性の高い取得フロー (図の左側) は、トランザクションを実装しない Mule イベントソースからトランザクションを実装するコネクタのアウトバウンド操作にメッセージを確実に配信します。操作は、VM や JMS など、任意の種別のトランザクションエンドポイントにできます。信頼性の高い取得フローは、メッセージを配信できない場合でもメッセージが失われないようにします。 - HTTP などのソケットベースの接続の場合、これはクライアントが要求を再試行できるように「要求失敗」応答をクライアントに返すことを意味します。 - ファイルや FTP などのリソースベースの接続の場合、再処理できるようにファイルを削除しないことを意味します。 アプリケーションロジックフロー (図の右側) は、トランザクションコネクタを使用するイベントソースからアプリケーションのビジネスロジックにメッセージを配信します。 ## [](#信頼性の高いメッセージング)信頼性の高いメッセージング 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。 アプリケーションで JMS、VM、DB などのトランザクション接続を使用する場合、信頼性の高いメッセージングはコネクタでのトランザクションのビルトインサポートで確保されます。つまり、たとえばトランザクションがコミットされたときに JMS サーバーからのみメッセージが削除されるようにするトランザクションを JMS リスナーで設定できます。これにより、メッセージの処理中にエラーが発生した場合でも、まだ再処理できるようになります。言い換えると、こうしたコネクタでのトランザクションサポートにより、接続元から操作に、またはフロー内のプロセッサー間でメッセージが確実に配信されるようになります。 トランザクションをサポートする異なるコネクタ間でメッセージを移動する場合は、XA トランザクションを使用して両方のコネクタのトランザクションが 1 つのユニットとしてコミットされるようにします。 XA をはじめとするトランザクションの種別についての詳細は、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management)​を参照してください。 HTTP などの非トランザクションコネクタを使用する Web アプリケーションがある場合、信頼性パターンに従ってアプリケーションで信頼性の高いメッセージングを確保してください。 ## [](#信頼性パターンでのエンドポイントの比較)信頼性パターンでのエンドポイントの比較 信頼性の高い取得フローは任意の種別のトランザクションエンドポイントと組み合わせることができます。信頼性パターンで VM エンドポイントを使用する必要はありません。次の図は、信頼性の高い取得フローがメッセージを JMS エンドポイントに配信する信頼性パターンを示しています。 ![ReliabilityPatternwithJMS](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/reliabilitypatternwithjms.png) 次の表は、信頼性の高い取得フローで VM、JMS、JDBC エンドポイントを使用した場合のメリットとデメリットを示しています。
エンドポイント メリット デメリット

ファイルベースの VM (スタンドアロン Mule)

  • Mule ですぐに使用できます。追加のソフトウェアが必要ありません。

  • 非クラスター環境にのみ適用されます。

JDBC

  • 使用できるリソースに応じて、JDBC が大量の情報を保持できます。

  • 追加のソフトウェア (データベースサーバー) が必要です。

  • 適切な DBMS スキーマが必要なため、複雑になる場合があります。

JMS (永続性に有効)

  • クラスター環境と非クラスター環境の両方に適用されます。

  • 追加のソフトウェア (メッセージキューサーバー) が必要です。
この比較には、VM および JMS のメモリ内の永続性設定は含まれていません。これらはメッセージが失われている可能性があり、信頼性が高いとみなされないためです。
## [](#信頼性パターンの実装)信頼性パターンの実装 次に、信頼性の高い取得フローとアプリケーションロジックフローを含む信頼性パターンの全体像となるコード例を示します。この例では、信頼性パターンのうち信頼性の高い取得フローは「HTTP から VM」の部分です。 ### [](#例-http-から-vm)例: HTTP から VM ```xml (1) (2) ```
1メッセージは VM キューに書き込まれます。メインフローで処理できるようになりました。
2メッセージはトランザクション的に VM キューから読み取られます。これにより、エラーが発生した場合、読み取りがロールバックされ、メッセージが再処理されるようになります。
Studio でこの XML の例をテストするには、VM Connector の連動関係をプロジェクトの ​`pom.xml`​ ファイルに追加します。
この例は VM ファイルの永続性を示していますが、クラスターでは機能しません。
## [](#信頼性の高い取得フローの実装)信頼性の高い取得フローの実装 [\[implementing-a-reliability-pattern\]](#implementing-a-reliability-pattern)​で示している例は、VM のパブリッシュ操作に対する HTTP リスナーの信頼性の高い取得フローを示していました。このシナリオでは、非トランザクションイベントソースがある信頼性の高い取得フローに重点を置きます: FTP-to-VM (または SFTP、FTPS)。 この場合、リソースベースの接続が使用されます。リソースベースの接続を使用する場合、必ずリソースを 1 回だけ読み取るようにしてください。これは、​`watermarkEnabled`​ を ​`true`​ に設定することで実行されます。 `auto-delete`​ パラメーターを ​`true`​ に設定すると、処理が別のフローによって実行された場合であってもフローが完了した時点で直ちにファイルが削除されるため、そのように設定しないでください。同じことは ​`moveToDirectory`​ にも言えます。 ### [](#例-ftp-から-vm)例: FTP から VM 次のコードでは、パブリッシュ操作による FTP リスナー (On New または Updated File) から VM キューへの信頼性の高い取得フローを実装しています。 ```xml (1) (2) ```
1VM にパブリッシュする前に変換を実行するには、最大再配信数を追加します。
2ファイルを削除したくない場合は、​ftp:delete​ 操作を使用しないでください。目的の操作が ​ftp:move​ の場合にも同じことが言えます。
他のリソースベースのコネクタについても同じような実装が行われます。 ## [](#一般的な考慮事項)一般的な考慮事項 信頼性パターンを実装するときには、次の点に注意してください。 - コネクタ (イベントソース) で許可されている場合は、必ずトランザクションを使用してください。 - 同じトランザクション内の複数の管理対象リソースを取得する場合は、XA トランザクションを使用してイベントソースをブリッジします。 - JMS の信頼性は MQ 実装およびその設定に関連付けられています。ほとんどの MQ 実装では、メッセージがメモリ内のみに保存されるか、それとも保持されるかを設定できます。信頼性を実現できるのは、メッセージを転送する前に永続的に保存するように MQ サーバーを設定している場合のみです。それ以外の場合、万一 MQ サーバーがクラッシュしたときにメッセージが失われるリスクがあります。 - 信頼性はパフォーマンスに影響を及ぼします。 - 信頼性の高い取得フローのアウトバウンド操作が非トランザクション (たとえば、ファイルから FTP へのフロー) の場合、その操作を ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept)​内で実行します。この方法では、操作が正常に完了したかどうかを確認でき、失敗した場合はエラーメッセージが記録されきます。 # 信頼性パターン 信頼性パターンとは、アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、アプリケーションのメッセージングが信頼できるようになるデザインです。信頼性パターンでは、次の図で示しているように、信頼性の高い取得フローとアプリケーションロジックフローを組み合わせています。 ![VM を使用する信頼性の高いメッセージ処理プロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/reliability-pattern.png) 信頼性の高い取得フロー (図の左側) は、トランザクションを実装しない Mule イベントソースからトランザクションを実装するコネクタのアウトバウンド操作にメッセージを確実に配信します。操作は、VM や JMS など、任意の種別のトランザクションエンドポイントにできます。信頼性の高い取得フローは、メッセージを配信できない場合でもメッセージが失われないようにします。 - HTTP などのソケットベースの接続の場合、これはクライアントが要求を再試行できるように「要求失敗」応答をクライアントに返すことを意味します。 - ファイルや FTP などのリソースベースの接続の場合、再処理できるようにファイルを削除しないことを意味します。 アプリケーションロジックフロー (図の右側) は、トランザクションコネクタを使用するイベントソースからアプリケーションのビジネスロジックにメッセージを配信します。 ## [](#信頼性の高いメッセージング)信頼性の高いメッセージング 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。 アプリケーションで JMS、VM、DB などのトランザクション接続を使用する場合、信頼性の高いメッセージングはコネクタでのトランザクションのビルトインサポートで確保されます。つまり、たとえばトランザクションがコミットされたときに JMS サーバーからのみメッセージが削除されるようにするトランザクションを JMS リスナーで設定できます。これにより、メッセージの処理中にエラーが発生した場合でも、まだ再処理できるようになります。言い換えると、こうしたコネクタでのトランザクションサポートにより、接続元から操作に、またはフロー内のプロセッサー間でメッセージが確実に配信されるようになります。 トランザクションをサポートする異なるコネクタ間でメッセージを移動する場合は、XA トランザクションを使用して両方のコネクタのトランザクションが 1 つのユニットとしてコミットされるようにします。 XA をはじめとするトランザクションの種別についての詳細は、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management)​を参照してください。 HTTP などの非トランザクションコネクタを使用する Web アプリケーションがある場合、信頼性パターンに従ってアプリケーションで信頼性の高いメッセージングを確保してください。 ## [](#信頼性パターンでのエンドポイントの比較)信頼性パターンでのエンドポイントの比較 信頼性の高い取得フローは任意の種別のトランザクションエンドポイントと組み合わせることができます。信頼性パターンで VM エンドポイントを使用する必要はありません。次の図は、信頼性の高い取得フローがメッセージを JMS エンドポイントに配信する信頼性パターンを示しています。 ![JMS を使用する信頼性の高いメッセージ取得および応答プロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/reliabilitypatternwithjms.png) 次の表は、信頼性の高い取得フローで VM、JMS、JDBC エンドポイントを使用した場合のメリットとデメリットを示しています。
エンドポイント メリット デメリット

ファイルベースの VM (スタンドアロン Mule)

  • Mule ですぐに使用できます。追加のソフトウェアが必要ありません。

  • 非クラスター環境にのみ適用されます。

JDBC

  • 使用できるリソースに応じて、JDBC が大量の情報を保持できます。

  • 追加のソフトウェア (データベースサーバー) が必要です。

  • 適切な DBMS スキーマが必要なため、複雑になる場合があります。

JMS (永続性に有効)

  • クラスター環境と非クラスター環境の両方に適用されます。

  • 追加のソフトウェア (メッセージキューサーバー) が必要です。
この比較には、VM および JMS のメモリ内の永続性設定は含まれていません。これらはメッセージが失われている可能性があり、信頼性が高いとみなされないためです。
## [](#信頼性パターンの実装)信頼性パターンの実装 次に、信頼性の高い取得フローとアプリケーションロジックフローを含む信頼性パターンの全体像となるコード例を示します。この例では、信頼性パターンのうち信頼性の高い取得フローは「HTTP から VM」の部分です。 ### [](#例-http-から-vm)例: HTTP から VM ```xml (1) (2) ```
1メッセージは VM キューに書き込まれます。メインフローで処理できるようになりました。
2メッセージはトランザクション的に VM キューから読み取られます。これにより、エラーが発生した場合、読み取りがロールバックされ、メッセージが再処理されるようになります。
Studio でこの XML の例をテストするには、VM Connector の連動関係をプロジェクトの ​`pom.xml`​ ファイルに追加します。
この例は VM ファイルの永続性を示していますが、クラスターでは機能しません。
## [](#信頼性の高い取得フローの実装)信頼性の高い取得フローの実装 [\[implementing-a-reliability-pattern\]](#implementing-a-reliability-pattern)​で示している例は、VM のパブリッシュ操作に対する HTTP リスナーの信頼性の高い取得フローを示していました。このシナリオでは、非トランザクションイベントソースがある信頼性の高い取得フローに重点を置きます: FTP-to-VM (または SFTP、FTPS)。 この場合、リソースベースの接続が使用されます。リソースベースの接続を使用する場合、必ずリソースを 1 回だけ読み取るようにしてください。これは、​`watermarkEnabled`​ を ​`true`​ に設定することで実行されます。 `auto-delete`​ パラメーターを ​`true`​ に設定すると、処理が別のフローによって実行された場合であってもフローが完了した時点で直ちにファイルが削除されるため、そのように設定しないでください。同じことは ​`moveToDirectory`​ にも言えます。 ### [](#例-ftp-から-vm)例: FTP から VM 次のコードでは、パブリッシュ操作による FTP リスナー (On New または Updated File) から VM キューへの信頼性の高い取得フローを実装しています。 ```xml (1) (2) ```
1VM にパブリッシュする前に変換を実行するには、最大再配信数を追加します。
2ファイルを削除したくない場合は、​ftp:delete​ 操作を使用しないでください。目的の操作が ​ftp:move​ の場合にも同じことが言えます。
他のリソースベースのコネクタについても同じような実装が行われます。 ## [](#一般的な考慮事項)一般的な考慮事項 信頼性パターンを実装するときには、次の点に注意してください。 - コネクタ (イベントソース) で許可されている場合は、必ずトランザクションを使用してください。 - 同じトランザクション内の複数の管理対象リソースを取得する場合は、XA トランザクションを使用してイベントソースをブリッジします。 - JMS の信頼性は MQ 実装およびその設定に関連付けられています。ほとんどの MQ 実装では、メッセージがメモリ内のみに保存されるか、それとも保持されるかを設定できます。信頼性を実現できるのは、メッセージを転送する前に永続的に保存するように MQ サーバーを設定している場合のみです。それ以外の場合、万一 MQ サーバーがクラッシュしたときにメッセージが失われるリスクがあります。 - 信頼性はパフォーマンスに影響を及ぼします。 - 信頼性の高い取得フローのアウトバウンド操作が非トランザクション (たとえば、ファイルから FTP へのフロー) の場合、その操作を ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/try-scope-concept)​内で実行します。この方法では、操作が正常に完了したかどうかを確認でき、失敗した場合はエラーメッセージが記録されきます。 # 信頼性パターン 信頼性パターンとは、アプリケーションが非トランザクションコネクタからメッセージを受信する場合であっても、アプリケーションのメッセージングが信頼できるようになるデザインです。信頼性パターンでは、次の図で示しているように、信頼性の高い取得フローとアプリケーションロジックフローを組み合わせています。 ![VM を使用する信頼性の高いメッセージ処理プロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/reliability-pattern.png) 信頼性の高い取得フロー (図の左側) は、トランザクションを実装しない Mule イベントソースからトランザクションを実装するコネクタのアウトバウンド操作にメッセージを確実に配信します。操作は、VM や JMS など、任意の種別のトランザクションエンドポイントにできます。信頼性の高い取得フローは、メッセージを配信できない場合でもメッセージが失われないようにします。 - HTTP などのソケットベースの接続の場合、これはクライアントが要求を再試行できるように「要求失敗」応答をクライアントに返すことを意味します。 - ファイルや FTP などのリソースベースの接続の場合、再処理できるようにファイルを削除しないことを意味します。 アプリケーションロジックフロー (図の右側) は、トランザクションコネクタを使用するイベントソースからアプリケーションのビジネスロジックにメッセージを配信します。 ## [](#信頼性の高いメッセージング)信頼性の高いメッセージング 高可用性アプリケーションは、メッセージの損失の許容がゼロである必要があります。つまり、基礎となる Mule とその個別の接続の信頼性が高い必要があります。 アプリケーションで JMS、VM、DB などのトランザクション接続を使用する場合、信頼性の高いメッセージングはコネクタでのトランザクションのビルトインサポートで確保されます。つまり、たとえばトランザクションがコミットされたときに JMS サーバーからのみメッセージが削除されるようにするトランザクションを JMS リスナーで設定できます。これにより、メッセージの処理中にエラーが発生した場合でも、まだ再処理できるようになります。言い換えると、こうしたコネクタでのトランザクションサポートにより、接続元から操作に、またはフロー内のプロセッサー間でメッセージが確実に配信されるようになります。 トランザクションをサポートする異なるコネクタ間でメッセージを移動する場合は、XA トランザクションを使用して両方のコネクタのトランザクションが 1 つのユニットとしてコミットされるようにします。 XA をはじめとするトランザクションの種別についての詳細は、​[「トランザクションの管理」](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management)​を参照してください。 HTTP などの非トランザクションコネクタを使用する Web アプリケーションがある場合、信頼性パターンに従ってアプリケーションで信頼性の高いメッセージングを確保してください。 ## [](#信頼性パターンでのエンドポイントの比較)信頼性パターンでのエンドポイントの比較 信頼性の高い取得フローは任意の種別のトランザクションエンドポイントと組み合わせることができます。信頼性パターンで VM エンドポイントを使用する必要はありません。次の図は、信頼性の高い取得フローがメッセージを JMS エンドポイントに配信する信頼性パターンを示しています。 ![JMS を使用する信頼性の高いメッセージ取得および応答プロセスが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/reliabilitypatternwithjms.png) 次の表は、信頼性の高い取得フローで VM、JMS、JDBC エンドポイントを使用した場合のメリットとデメリットを示しています。
エンドポイント メリット デメリット

ファイルベースの VM (スタンドアロン Mule)

  • Mule ですぐに使用できます。追加のソフトウェアが必要ありません。

  • 非クラスター環境にのみ適用されます。

JDBC

  • 使用できるリソースに応じて、JDBC が大量の情報を保持できます。

  • 追加のソフトウェア (データベースサーバー) が必要です。

  • 適切な DBMS スキーマが必要なため、複雑になる場合があります。

JMS (永続性に有効)

  • クラスター環境と非クラスター環境の両方に適用されます。

  • 追加のソフトウェア (メッセージキューサーバー) が必要です。
この比較には、VM および JMS のメモリ内の永続性設定は含まれていません。これらはメッセージが失われている可能性があり、信頼性が高いとみなされないためです。
## [](#信頼性パターンの実装)信頼性パターンの実装 次に、信頼性の高い取得フローとアプリケーションロジックフローを含む信頼性パターンの全体像となるコード例を示します。この例では、信頼性パターンのうち信頼性の高い取得フローは「HTTP から VM」の部分です。 ### [](#例-http-から-vm)例: HTTP から VM ```xml (1) (2) ```
1メッセージは VM キューに書き込まれます。メインフローで処理できるようになりました。
2メッセージはトランザクション的に VM キューから読み取られます。これにより、エラーが発生した場合、読み取りがロールバックされ、メッセージが再処理されるようになります。
Studio でこの XML の例をテストするには、VM Connector の連動関係をプロジェクトの ​`pom.xml`​ ファイルに追加します。
この例は VM ファイルの永続性を示していますが、クラスターでは機能しません。
## [](#信頼性の高い取得フローの実装)信頼性の高い取得フローの実装 [\[implementing-a-reliability-pattern\]](#implementing-a-reliability-pattern)​で示している例は、VM のパブリッシュ操作に対する HTTP リスナーの信頼性の高い取得フローを示していました。このシナリオでは、非トランザクションイベントソースがある信頼性の高い取得フローに重点を置きます: FTP-to-VM (または SFTP、FTPS)。 この場合、リソースベースの接続が使用されます。リソースベースの接続を使用する場合、必ずリソースを 1 回だけ読み取るようにしてください。これは、​`watermarkEnabled`​ を ​`true`​ に設定することで実行されます。 `auto-delete`​ パラメーターを ​`true`​ に設定すると、処理が別のフローによって実行された場合であってもフローが完了した時点で直ちにファイルが削除されるため、そのように設定しないでください。同じことは ​`moveToDirectory`​ にも言えます。 ### [](#例-ftp-から-vm)例: FTP から VM 次のコードでは、パブリッシュ操作による FTP リスナー (On New または Updated File) から VM キューへの信頼性の高い取得フローを実装しています。 ```xml (1) (2) ```
1VM にパブリッシュする前に変換を実行するには、最大再配信数を追加します。
2ファイルを削除したくない場合は、​ftp:delete​ 操作を使用しないでください。目的の操作が ​ftp:move​ の場合にも同じことが言えます。
他のリソースベースのコネクタについても同じような実装が行われます。 ## [](#一般的な考慮事項)一般的な考慮事項 信頼性パターンを実装するときには、次の点に注意してください。 - コネクタ (イベントソース) で許可されている場合は、必ずトランザクションを使用してください。 - 同じトランザクション内の複数の管理対象リソースを取得する場合は、XA トランザクションを使用してイベントソースをブリッジします。 - JMS の信頼性は MQ 実装およびその設定に関連付けられています。ほとんどの MQ 実装では、メッセージがメモリ内のみに保存されるか、それとも保持されるかを設定できます。信頼性を実現できるのは、メッセージを転送する前に永続的に保存するように MQ サーバーを設定している場合のみです。それ以外の場合、万一 MQ サーバーがクラッシュしたときにメッセージが失われるリスクがあります。 - 信頼性はパフォーマンスに影響を及ぼします。 - 信頼性の高い取得フローのアウトバウンド操作が非トランザクション (たとえば、ファイルから FTP へのフロー) の場合、その操作を ​[Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/try-scope-concept)​内で実行します。この方法では、操作が正常に完了したかどうかを確認でき、失敗した場合はエラーメッセージが記録されきます。 # 共有リソース Mule をオンプレミスにデプロイする場合は、共有プロパティ、スケジューラープール、コネクタ設定などのグローバル設定を定義して、同じドメインにデプロイされたすべてのアプリケーションで共有できます。これを行うには、Mule ドメインを作成し、各アプリケーションからそのドメインを参照します。そうすることで、その Mule ドメインに関連付けられた各アプリケーションがドメイン内の共有リソースにアクセスできるようになります。 Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができませんので注意してください。 共有リソースにより、同じコネクタ設定セットを使用して、複数の開発チームが並行して作業を行うことができるため、チームは次のことが可能になります。 - ドメイン内の複数のサービスを同じポートから公開できます。 - 永続的なストレージへの接続を共有できます。 - きちんと定義されたインターフェースを通して Mule アプリケーション間でサービスを共有できます。 - 設定を 1 箇所のみで行うため、変更があっても Mule アプリケーション間の一貫性を保証できます。 メタデータを共有する場合は、Mule ドメインプロジェクトを Anypoint Studio で開いたままにしておいてください。そうでないと、リンク先の Mule プロジェクトでメタデータを手動で入力しなければなりません。 ## [](#前提条件)前提条件 - Anypoint Studio 7.x - Mule Runtime Engine 4.x - オンプレミスでの Mule Runtime Engine の実行 ## [](#制限事項)制限事項 フロー、サブフロー、またはメッセージプロセッサーを共有リソースとして定義することはできません。ドメインでは、動作を共有することはできません。共有できるのはリソースのみです。 ## [](#アーキテクチャ)アーキテクチャ Anypoint Studio の Mule ドメインプロジェクトには次の主要ファイルが含まれます。
ファイル名 説明

/src/main/mule/mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

pom.xml

連動関係ファイル記述子。ドメインプロジェクトに必要なプラグインが格納された Maven POM ファイルです。

/mule-artifact.json

ドメインアーティファクトの記述子。
Mule ドメインプロジェクトをデプロイ可能な JAR ファイルにパッケージ化すると、次のファイルが含まれます。
ファイル名 説明

mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

/repository

ドメインのすべての連動関係が登録された Maven に似たリポジトリ。

/META-INF/maven/groupId/artifactId/pom.xml

アーティファクトの Maven 記述子ファイル。

/META-INF/mule-artifact/classloader-model.json

連動関係の管理に使用する内部 Mule ファイル。

/META-INF/mule-artifact/mule-artifact.json

ドメインアーティファクトの記述子。
## [](#configuration-設定)Configuration (設定) Mule アプリケーションで共有リソースを使用するには、次の作業を実行します。 1. [新しいドメインを作成します](#create_domain_project)​。 2. [そのドメインで 1 つまたは複数の共有リソースを定義します](#define-shared-resources)​。 3. [アプリケーションをドメインに関連付けます](#assoc_apps_domain)​。 4. Mule アプリケーションで​[共有リソースを参照します](#reference-shared-resources)​。 5. [ドメインと Mule アプリケーションを共有リソースと共にデプロイします](#deploy-shared-resources)​。 ## [](#create_domain_project)新規ドメインの作成 Anypoint Studio で新しいドメインを作成するには、次の手順を実行します。 1. 上部のメニューバーで ​**\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Domain Project (Mule ドメインプロジェクト)\]**​ を選択します。 ![新規 + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-new-domain.png) 2. 通常の Mule プロジェクトの作成時と同じ項目に値を入力します。 ![作成 + 新規 + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-create-domain.png) - プロジェクト名を入力して Mule バージョンを選択します。 ## [](#define-shared-resources)共有リソース設定 [ドメインプロジェクト](#create_domain_project)​を設定するには、​`mule-domain-config.xml`​ ファイルで 1 つ以上の共有リソースを定義します。このファイルは、Anypoint Studio で XML エディターまたはグラフィカルインターフェースを使用して編集できます。 ### [](#設定-xml-の編集による共有リソースの設定)設定 XML の編集による共有リソースの設定 ドメインの設定 XML にモジュールまたはコネクタの設定を追加することで、共有リソースを設定します。 次の例では、HTTP リスナーを共有リソースとして設定しています。 ```xml ``` ### [](#global-elements-グローバル要素-タブを使用した共有リソースの設定)\[Global Elements (グローバル要素)\] タブを使用した共有リソースの設定 Anypoint Studio の ​**\[Global Elements (グローバル要素)\]**​ タブを使用して共有リソースを設定すると、最初にドメインプロジェクトにモジュールを追加してからグローバル要素を作成できます。 たとえば、ドメインプロジェクトに HTTP 用 Anypoint Connector (HTTP Connector) を追加する手順は、次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Manage Modules (モジュールを管理)\]**​ をクリックします。 ![ドメインのモジュール管理](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-domain-manage-modules.png) 2. **\[Add Module (モジュールを追加)\]**​ をクリックします。 ![ドメインへのモジュールの追加](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-domain-add-module.png) 3. 追加するモジュールを検索し、​**\[Add > (追加 >)\]**​ をクリックします。 ![ドメインへのモジュール追加の完了](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-domain-add-module-finish.png) 4. **\[Finish (完了)\]**​ をクリックします。 ドメインプロジェクトに HTTP Connector を追加した後に、共有リソースとして使用するグローバル要素を作成できます。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Create (作成)\]**​ をクリックします。 ![ドメインの設定の作成](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-domain-create-config.png) 2. HTTP Connector を選択し、設定プロセスを実行します。 ![ドメインのコネクタ設定の作成](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-domain-connector-config.png) 3. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 ## [](#assoc_apps_domain)アプリケーションのドメインへの関連付け Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができません。Studio を使用するか、プロジェクトの ​`pom.xml`​ ファイルを直接編集するかのどちらかの方法で、既存の Mule アプリケーションをドメインに関連付けることができます。ドメインの連動関係を設定していない場合、Mule アプリケーションでは ​`default`​ ドメインが使用されます。 Mule 4.2.2 以降のバージョンを使用する場合は、次の点を考慮してください。 - バージョンではセマンティックバージョン設定が優先されます。 たとえば、バージョンを 1.0.1 に設定した場合、バージョン 1.0.2 以降のドメインは機能しますが、バージョン 1.0.0 のドメインは機能しません。 - 同じグループ ID、アーティファクト ID、バージョンを使用して異なるドメインがデプロイされると、​`pom.xml`​ ファイル内の参照が曖昧になるおそれがあります。 この問題を回避するには、Mule アプリケーションの ​`mule-artifact.json`​ ファイルでドメインフォルダーの名前を追加します。 ```json { "domain": "mymuledomain-1.0.1-mule-domain" ... } ``` ### [](#studio-を使用して-mule-アプリケーションをドメインに関連付ける)Studio を使用して Mule アプリケーションをドメインに関連付ける Studio から Mule アプリケーションをドメインに関連付けるには、次の手順を実行します。 1. \[Project Explorer\] または \[Package Explorer\] ビューで Mule アプリケーションを右クリックします。 2. メニューが開きますので、​**\[Properties (プロパティ)\]**​ をクリックします。 3. \[Properties (プロパティ)\] で ​**\[Mule Project (Mule プロジェクト)\]**​ をクリックします。 4. **\[Domain (ドメイン)\]**​ 項目でプロジェクトのドメインを選択します。 ![割り当て + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-assign-domain.png) ドメインを選択すると、プロジェクトの Mule Runtime Engine が自動的にドメインの Mule Runtime Engine に一致します。 これらの手順を完了したら、Studio にプロジェクトの ​`pom.xml`​ のドメインが含まれます。次に例を示します。 ```xml ... com.mycompany mymuledomain 1.0.0-SNAPSHOT mule-domain provided ``` ### [](#studio-外で-mule-アプリケーションをドメインに関連付ける)Studio 外で Mule アプリケーションをドメインに関連付ける Studio 外で Mule アプリケーションをドメインに関連付けるには、前の例で示しているように、ドメインの連動関係を ​`pom.xml`​ ファイルに追加します。 ## [](#reference-shared-resources)共有リソースの参照 次の ​`mule-domain-config.xml`​ の例では、HTTP リスナーおよび HTTP 要求設定を共有リソースとして定義します。 ```xml ``` ドメインに関連付けられているすべての Mule アプリケーションは、プロジェクト自体の中でリソースを参照するのと同じように設定内でリソースを参照することによって共有リソースを利用できます。次の例では、HTTP Listener Connector が ​`HTTP_Listener_Configuration`​ という名前の共有リソースを参照しています。 ```xml ``` Studio のビジュアルエディターでは、コネクタのプロパティエディターの ​**\[Connector Configuration (コネクタ設定)\]**​ 項目にあるドロップダウンリストから共有リソースを選択できます。 ![選択 + リソース](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/pick-resource.png) ## [](#deploy-shared-resources)共有リソースとのデプロイ デフォルトでは、ドメインに関連付けられた Mule アプリケーションまたは Mule アプリケーションに関連付けられたドメインをデプロイすると、Anypoint Studio で両方がデプロイされます。このデフォルト動作を変更するには、ドメインの実行の設定を変更します。同じドメインを共有していなくても、ワークスペース内の一連の Mule アプリケーションをデプロイすることもできます。
Mule ドメインプロジェクトは、Runtime Manager ではインストールできません。
### [](#anypoint-studio-からのデプロイ)Anypoint Studio からのデプロイ Studio からドメインプロジェクトとそれに関連付けられた Mule アプリケーションをデプロイする手順は次のとおりです。 1. 再生ボタンの隣にあるドロップダウンメニューを開き、​**\[Run Configurations (設定の実行)\]**​ を選択します。 ![実行 + 設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-run-configuration.png) 2. **\[General (一般)\]**​ タブを選択し、右側のナビゲーションメニューで現在選択されている Mule アプリケーションと常に一緒にデプロイしたいプロジェクトのボックスを選択します。 ![実行 + 設定 + プロパティ](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-run-configuration-properties.png) ### [](#anypoint-studio-外でのデプロイ)Anypoint Studio 外でのデプロイ Studio 外でドメインプロジェクトと Mule アプリケーションをスタンドアロン Mule Runtime Engine にデプロイする手順は次のとおりです。 1. Studio で、​**\[File (ファイル)\]**​ > ​**\[Export (エクスポート)\]**​ を選択します。 2. **\[Mule\]**​ > ​**\[Anypoint Studio Project to Mule Deployable Archive (includes Studio metadata) (Anypoint Studio プロジェクトから Mule のデプロイ可能なアーカイブへ (Studio メタデータを含む))\]**​ を選択します。 このプロセスによって、スタンドアロン Mule Runtime Engine にデプロイできる JAR ファイルが作成されます。 ![mruntime export studio](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-export-studio.png) 3. エクスポートされたドメインの JAR ファイルを ​`MULE_HOME/domains`​ にコピーします。 4. デプロイする各 Mule アプリケーションとそれに関連付けられたドメインをエクスポートします。 5. ドメインを参照する各 Mule アプリケーションのエクスポートされた JAR ファイルを ​`MULE_HOME/apps`​ フォルダーにコピーします。 6. コマンドコンソールから Mule を起動します。 Mule が起動すると、Mule アプリケーションの起動前にすべてのドメインが完全に起動しているようにするため、Mule は先に ​`MULE_HOME/domains`​ フォルダーで見つかったドメインをすべてデプロイしてから、次に ​`MULE_HOME/apps`​ フォルダーで見つかった Mule アプリケーションをすべてデプロイします。 ### [](#mule-maven-プラグインを使用したドメインのデプロイ)Mule Maven プラグインを使用したドメインのデプロイ Mule Maven プラグインを使用してドメインをローカル Mule インスタンスにデプロイできます。 手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/deploy-on-premises#deploy-a-domain)​を参照してください。 # 共有リソース (Mule ドメイン) Mule をオンプレミスにデプロイする場合は、共有プロパティ、スケジューラープール、コネクタ設定などのグローバル設定を定義して、同じドメインにデプロイされたすべてのアプリケーションで共有できます。これを行うには、Mule ドメインを作成し、各アプリケーションからそのドメインを参照します。そうすることで、その Mule ドメインに関連付けられた各アプリケーションがドメイン内の共有リソースにアクセスできるようになります。 Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができませんので注意してください。 同じオンプレミス Mule Runtime Engine (Mule) に複数のサービスをデプロイする場合は、ドメインを使用することでパフォーマンスを高めることができます。ドメインは、すべての共有リソースに対して中央管理ポイントを提供することにより、特に ​`pom.xml`​ ファイルで宣言されているドメインの連動関係もドメインアプリケーション間で共有するため、クラスローディングプロセス (そしてメタスペースメモリの使用) をより効率的にします。 共有リソースにより、同じコネクタ設定セットを使用して、複数の開発チームが並行して作業を行うことができるため、チームは次のことが可能になります。 - ドメイン内の複数のサービスを同じポートから公開できます。 - 永続的なストレージへの接続を共有できます。 - きちんと定義されたインターフェースを通して Mule アプリケーション間でサービスを共有できます。 - 設定を 1 箇所のみで行うため、変更があっても Mule アプリケーション間の一貫性を保証できます。 メタデータを共有する場合は、Mule ドメインプロジェクトを Anypoint Studio で開いたままにしておいてください。そうでないと、リンク先の Mule プロジェクトでメタデータを手動で入力しなければなりません。 ## [](#前提条件)前提条件 - Anypoint Studio 7.x - Mule Runtime Engine 4.x - オンプレミスでの Mule Runtime Engine の実行 ## [](#制限事項)制限事項 フロー、サブフロー、またはメッセージプロセッサーを共有リソースとして定義することはできません。ドメインでは、動作を共有することはできません。共有できるのはリソースのみです。 ## [](#アーキテクチャ)アーキテクチャ Anypoint Studio の Mule ドメインプロジェクトには次の主要ファイルが含まれます。
File Name (ファイル名) 説明

/src/main/mule/mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

pom.xml

連動関係ファイル記述子。ドメインプロジェクトに必要なプラグインが格納された Maven POM ファイルです。

/mule-artifact.json

ドメインアーティファクトの記述子。
Mule ドメインプロジェクトをデプロイ可能な JAR ファイルにパッケージ化すると、次のファイルが含まれます。
File Name (ファイル名) 説明

mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

/repository

ドメインのすべての連動関係が登録された Maven に似たリポジトリ。

/META-INF/maven/groupId/artifactId/pom.xml

アーティファクトの Maven 記述子ファイル。

/META-INF/mule-artifact/classloader-model.json

連動関係の管理に使用する内部 Mule ファイル。

/META-INF/mule-artifact/mule-artifact.json

ドメインアーティファクトの記述子。
## [](#configuration-設定)Configuration (設定) Mule アプリケーションで共有リソースを使用するには、次の作業を実行します。 1. [新しいドメインを作成します](#create_domain_project)​。 2. [そのドメインで 1 つまたは複数の共有リソースを定義します](#define-shared-resources)​。 3. [アプリケーションをドメインに関連付けます](#assoc_apps_domain)​。 4. Mule アプリケーションで​[共有リソースを参照します](#reference-shared-resources)​。 5. [ドメインと Mule アプリケーションを共有リソースと共にデプロイします](#deploy-shared-resources)​。 ## [](#create_domain_project)新規ドメインの作成 Anypoint Studio で新しいドメインを作成するには、次の手順を実行します。 1. 上部のメニューバーで ​**\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Domain Project (Mule ドメインプロジェクト)\]**​ を選択します。 ![新規 + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-new-domain.png) 2. 通常の Mule プロジェクトの作成時と同じ項目に値を入力します。 ![作成 + 新規 + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-create-domain.png) - プロジェクト名を入力して Mule バージョンを選択します。 ## [](#define-shared-resources)共有リソース設定 [ドメインプロジェクト](#create_domain_project)​を設定するには、​`mule-domain-config.xml`​ ファイルで 1 つ以上の共有リソースを定義します。このファイルは、Anypoint Studio で XML エディターまたはグラフィカルインターフェースを使用して編集できます。 ### [](#設定-xml-の編集による共有リソースの設定)設定 XML の編集による共有リソースの設定 ドメインの設定 XML にモジュールまたはコネクタの設定を追加することで、共有リソースを設定します。 次の例では、HTTP リスナーを共有リソースとして設定しています。 ```xml ``` ### [](#global-elements-グローバル要素-タブを使用した共有リソースの設定)\[Global Elements (グローバル要素)\] タブを使用した共有リソースの設定 Anypoint Studio の ​**\[Global Elements (グローバル要素)\]**​ タブを使用して共有リソースを設定すると、最初にドメインプロジェクトにモジュールを追加してからグローバル要素を作成できます。 たとえば、ドメインプロジェクトに HTTP 用 Anypoint Connector (HTTP Connector) を追加する手順は、次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Manage Modules (モジュールを管理)\]**​ をクリックします。 ![ドメインのモジュール管理](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-domain-manage-modules.png) 2. **\[Add Module (モジュールを追加)\]**​ をクリックします。 ![ドメインへのモジュールの追加](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-domain-add-module.png) 3. 追加するモジュールを検索し、​**\[Add > (追加 >)\]**​ をクリックします。 ![ドメインへのモジュール追加の完了](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-domain-add-module-finish.png) 4. **\[Finish (完了)\]**​ をクリックします。 ドメインプロジェクトに HTTP Connector を追加した後に、共有リソースとして使用するグローバル要素を作成できます。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Create (作成)\]**​ をクリックします。 ![ドメインの設定の作成](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-domain-create-config.png) 2. HTTP Connector を選択し、設定プロセスを実行します。 ![ドメインのコネクタ設定の作成](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-domain-connector-config.png) 3. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 ## [](#assoc_apps_domain)アプリケーションのドメインへの関連付け Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができません。Studio を使用するか、プロジェクトの ​`pom.xml`​ ファイルを直接編集するかのどちらかの方法で、既存の Mule アプリケーションをドメインに関連付けることができます。ドメインの連動関係を設定していない場合、Mule アプリケーションでは ​`default`​ ドメインが使用されます。 Mule 4.2.2 以降のバージョンを使用する場合は、次の点を考慮してください。 - バージョンではセマンティックバージョン設定が優先されます。 たとえば、バージョンを 1.0.1 に設定した場合、バージョン 1.0.2 以降のドメインは機能しますが、バージョン 1.0.0 のドメインは機能しません。 - 同じグループ ID、アーティファクト ID、バージョンを使用して異なるドメインがデプロイされると、​`pom.xml`​ ファイル内の参照が曖昧になるおそれがあります。 この問題を回避するには、Mule アプリケーションの ​`mule-artifact.json`​ ファイルでドメインフォルダーの名前を追加します。 ```json { "domain": "mymuledomain-1.0.1-mule-domain" ... } ``` ### [](#studio-を使用して-mule-アプリケーションをドメインに関連付ける)Studio を使用して Mule アプリケーションをドメインに関連付ける Studio から Mule アプリケーションをドメインに関連付けるには、次の手順を実行します。 1. \[Project Explorer\] または \[Package Explorer\] ビューで Mule アプリケーションを右クリックします。 2. メニューが開きますので、​**\[Properties (プロパティ)\]**​ をクリックします。 3. \[Properties (プロパティ)\] で ​**\[Mule Project (Mule プロジェクト)\]**​ をクリックします。 4. **\[Domain (ドメイン)\]**​ 項目でプロジェクトのドメインを選択します。 ![割り当て + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-assign-domain.png) ドメインを選択すると、プロジェクトの Mule Runtime Engine が自動的にドメインの Mule Runtime Engine に一致します。 これらの手順を完了したら、Studio にプロジェクトの ​`pom.xml`​ のドメインが含まれます。次に例を示します。 ```xml ... com.mycompany mymuledomain 1.0.0-SNAPSHOT mule-domain provided ``` ### [](#studio-外で-mule-アプリケーションをドメインに関連付ける)Studio 外で Mule アプリケーションをドメインに関連付ける Studio 外で Mule アプリケーションをドメインに関連付けるには、前の例で示しているように、ドメインの連動関係を ​`pom.xml`​ ファイルに追加します。 ## [](#reference-shared-resources)共有リソースの参照 次の ​`mule-domain-config.xml`​ の例では、HTTP リスナーおよび HTTP 要求設定を共有リソースとして定義します。 ```xml ``` ドメインに関連付けられているすべての Mule アプリケーションは、プロジェクト自体の中でリソースを参照するのと同じように設定内でリソースを参照することによって共有リソースを利用できます。次の例では、HTTP Listener Connector が ​`HTTP_Listener_Configuration`​ という名前の共有リソースを参照しています。 ```xml ``` Studio のビジュアルエディターでは、コネクタのプロパティエディターの ​**\[Connector Configuration (コネクタ設定)\]**​ 項目にあるドロップダウンリストから共有リソースを選択できます。 ![選択 + リソース](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/pick-resource.png) ## [](#deploy-shared-resources)共有リソースとのデプロイ デフォルトでは、ドメインに関連付けられた Mule アプリケーションまたは Mule アプリケーションに関連付けられたドメインをデプロイすると、Anypoint Studio で両方がデプロイされます。このデフォルト動作を変更するには、ドメインの実行の設定を変更します。同じドメインを共有していなくても、ワークスペース内の一連の Mule アプリケーションをデプロイすることもできます。
Mule ドメインプロジェクトは、Runtime Manager ではインストールできません。
### [](#anypoint-studio-からのデプロイ)Anypoint Studio からのデプロイ Studio からドメインプロジェクトとそれに関連付けられた Mule アプリケーションをデプロイする手順は次のとおりです。 1. 再生ボタンの隣にあるドロップダウンメニューを開き、​**\[Run Configurations (設定の実行)\]**​ を選択します。 ![実行 + 設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-run-configuration.png) 2. **\[General (一般)\]**​ タブを選択し、右側のナビゲーションメニューで現在選択されている Mule アプリケーションと常に一緒にデプロイしたいプロジェクトのボックスを選択します。 ![実行 + 設定 + プロパティ](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-run-configuration-properties.png) ### [](#anypoint-studio-外でのデプロイ)Anypoint Studio 外でのデプロイ Studio 外でドメインプロジェクトと Mule アプリケーションをスタンドアロン Mule Runtime Engine にデプロイする手順は次のとおりです。 1. Studio で、​**\[File (ファイル)\]**​ > ​**\[Export (エクスポート)\]**​ を選択します。 2. **\[Mule\]**​ > ​**\[Anypoint Studio Project to Mule Deployable Archive (includes Studio metadata) (Anypoint Studio プロジェクトから Mule のデプロイ可能なアーカイブへ (Studio メタデータを含む))\]**​ を選択します。 このプロセスによって、スタンドアロン Mule Runtime Engine にデプロイできる JAR ファイルが作成されます。 ![mruntime export studio](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-export-studio.png) 3. エクスポートされたドメインの JAR ファイルを ​`MULE_HOME/domains`​ にコピーします。 4. デプロイする各 Mule アプリケーションとそれに関連付けられたドメインをエクスポートします。 5. ドメインを参照する各 Mule アプリケーションのエクスポートされた JAR ファイルを ​`MULE_HOME/apps`​ フォルダーにコピーします。 6. コマンドコンソールから Mule を起動します。 Mule が起動すると、Mule アプリケーションの起動前にすべてのドメインが完全に起動しているようにするため、Mule は先に ​`MULE_HOME/domains`​ フォルダーで見つかったドメインをすべてデプロイしてから、次に ​`MULE_HOME/apps`​ フォルダーで見つかった Mule アプリケーションをすべてデプロイします。 ### [](#mule-maven-プラグインを使用したドメインのデプロイ)Mule Maven プラグインを使用したドメインのデプロイ Mule Maven プラグインを使用してドメインをローカル Mule インスタンスにデプロイできます。 手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ドメインを使用することによるパフォーマンス向上の例)ドメインを使用することによるパフォーマンス向上の例 1 つのゲートウェイポリシー (IP 許可リストなど) も適用する HTTP プロキシアプリケーション群があるとします。各アプリケーションは同じバックエンドとやり取りします。2 GB のヒープメモリと 256 MB のメタスペースが設定された Mule インスタンスで、適切なドメインを使用せずにこれらのアプリケーションを 60 件以上、別々にデプロイすると、リソースの飽和によって TPS (毎秒のトランザクション数) が大幅に低下します。80 件のアプリケーションをデプロイすると、メモリ不足例外によってデプロイエラーとなります。 この問題は、バックエンドサーバー設定を共有するドメインを使用するだけで大幅に改善され、デプロイするアプリケーション数が 100 件を超えても、マシンリソースはバランスよく使用されて良好なパフォーマンスが維持されます。 ドメインを使用することでパフォーマンスは明らかに向上しますが、デプロイされる各アプリケーションには、共有インフラストラクチャリソースによる複雑さが追加されます。パフォーマンスへの影響を回避するため、アプリケーションを追加する前に、各アプリケーションを個別にテストすることでオーバーヘッドを特定してから、他のアプリケーションと共存させてテストしてください。 # 共有リソース (Mule ドメイン) Mule をオンプレミスにデプロイする場合は、共有プロパティ、スケジューラープール、コネクタ設定などのグローバル設定を定義して、同じドメインにデプロイされたすべてのアプリケーションで共有できます。これを行うには、Mule ドメインを作成し、各アプリケーションからそのドメインを参照します。そうすることで、その Mule ドメインに関連付けられた各アプリケーションがドメイン内の共有リソースにアクセスできるようになります。 Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができませんので注意してください。 同じオンプレミス Mule Runtime Engine (Mule) に複数のサービスをデプロイする場合は、ドメインを使用することでパフォーマンスを高めることができます。ドメインは、すべての共有リソースに対して中央管理ポイントを提供することにより、特に ​`pom.xml`​ ファイルで宣言されているドメインの連動関係もドメインアプリケーション間で共有するため、クラスローディングプロセス (そしてメタスペースメモリの使用) をより効率的にします。 共有リソースにより、同じコネクタ設定セットを使用して、複数の開発チームが並行して作業を行うことができるため、チームは次のことが可能になります。 - ドメイン内の複数のサービスを同じポートから公開できます。 - 永続的なストレージへの接続を共有できます。 - きちんと定義されたインターフェースを通して Mule アプリケーション間でサービスを共有できます。 - 設定を 1 箇所のみで行うため、変更があっても Mule アプリケーション間の一貫性を保証できます。 メタデータを共有する場合は、Mule ドメインプロジェクトを Anypoint Studio で開いたままにしておいてください。そうでないと、リンク先の Mule プロジェクトでメタデータを手動で入力しなければなりません。 ## [](#前提条件)前提条件 - Anypoint Studio 7.x - Mule Runtime Engine 4.x - オンプレミスでの Mule Runtime Engine の実行 ## [](#制限事項)制限事項 フロー、サブフロー、またはメッセージプロセッサーを共有リソースとして定義することはできません。ドメインでは、動作を共有することはできません。共有できるのはリソースのみです。 ## [](#アーキテクチャ)アーキテクチャ Anypoint Studio の Mule ドメインプロジェクトには次の主要ファイルが含まれます。
ファイル名 説明

/src/main/mule/mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

pom.xml

連動関係ファイル記述子。ドメインプロジェクトに必要なプラグインが格納された Maven POM ファイルです。

/mule-artifact.json

ドメインアーティファクトの記述子。
Mule ドメインプロジェクトをデプロイ可能な JAR ファイルにパッケージ化すると、次のファイルが含まれます。
ファイル名 説明

mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

/repository

ドメインのすべての連動関係が登録された Maven に似たリポジトリ。

/META-INF/maven/groupId/artifactId/pom.xml

アーティファクトの Maven 記述子ファイル。

/META-INF/mule-artifact/classloader-model.json

連動関係の管理に使用する内部 Mule ファイル。

/META-INF/mule-artifact/mule-artifact.json

ドメインアーティファクトの記述子。
## [](#configuration-設定)Configuration (設定) Mule アプリケーションで共有リソースを使用するには、次の作業を実行します。 1. [新しいドメインを作成します](#create_domain_project)​。 2. [そのドメインで 1 つまたは複数の共有リソースを定義します](#define-shared-resources)​。 3. [アプリケーションをドメインに関連付けます](#assoc_apps_domain)​。 4. Mule アプリケーションで​[共有リソースを参照します](#reference-shared-resources)​。 5. [ドメインと Mule アプリケーションを共有リソースと共にデプロイします](#deploy-shared-resources)​。 ## [](#create_domain_project)新規ドメインの作成 Anypoint Studio で新しいドメインを作成するには、次の手順を実行します。 1. 上部のメニューバーで ​**\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Domain Project (Mule ドメインプロジェクト)\]**​ を選択します。 ![新規 + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-new-domain.png) 2. 通常の Mule プロジェクトの作成時と同じ項目に値を入力します。 ![作成 + 新規 + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-create-domain.png) - プロジェクト名を入力して Mule バージョンを選択します。 ## [](#define-shared-resources)共有リソース設定 [ドメインプロジェクト](#create_domain_project)​を設定するには、​`mule-domain-config.xml`​ ファイルで 1 つ以上の共有リソースを定義します。このファイルは、Anypoint Studio で XML エディターまたはグラフィカルインターフェースを使用して編集できます。 ### [](#設定-xml-の編集による共有リソースの設定)設定 XML の編集による共有リソースの設定 ドメインの設定 XML にモジュールまたはコネクタの設定を追加することで、共有リソースを設定します。 次の例では、HTTP リスナーを共有リソースとして設定しています。 ```xml ``` ### [](#global-elements-グローバル要素-タブを使用した共有リソースの設定)\[Global Elements (グローバル要素)\] タブを使用した共有リソースの設定 Anypoint Studio の ​**\[Global Elements (グローバル要素)\]**​ タブを使用して共有リソースを設定すると、最初にドメインプロジェクトにモジュールを追加してからグローバル要素を作成できます。 たとえば、ドメインプロジェクトに HTTP 用 Anypoint Connector (HTTP Connector) を追加する手順は、次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Manage Modules (モジュールを管理)\]**​ をクリックします。 ![ドメインのモジュール管理](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-domain-manage-modules.png) 2. **\[Add Module (モジュールを追加)\]**​ をクリックします。 ![ドメインへのモジュールの追加](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-domain-add-module.png) 3. 追加するモジュールを検索し、​**\[Add > (追加 >)\]**​ をクリックします。 ![ドメインへのモジュール追加の完了](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-domain-add-module-finish.png) 4. **\[Finish (完了)\]**​ をクリックします。 ドメインプロジェクトに HTTP Connector を追加した後に、共有リソースとして使用するグローバル要素を作成できます。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Create (作成)\]**​ をクリックします。 ![ドメインの設定の作成](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-domain-create-config.png) 2. HTTP Connector を選択し、設定プロセスを実行します。 ![ドメインのコネクタ設定の作成](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-domain-connector-config.png) 3. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 ## [](#assoc_apps_domain)アプリケーションのドメインへの関連付け Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができません。Studio を使用するか、プロジェクトの ​`pom.xml`​ ファイルを直接編集するかのどちらかの方法で、既存の Mule アプリケーションをドメインに関連付けることができます。ドメインの連動関係を設定していない場合、Mule アプリケーションでは ​`default`​ ドメインが使用されます。 Mule 4.2.2 以降のバージョンを使用する場合は、次の点を考慮してください。 - バージョンではセマンティックバージョン設定が優先されます。 たとえば、バージョンを 1.0.1 に設定した場合、バージョン 1.0.2 以降のドメインは機能しますが、バージョン 1.0.0 のドメインは機能しません。 - 同じグループ ID、アーティファクト ID、バージョンを使用して異なるドメインがデプロイされると、​`pom.xml`​ ファイル内の参照が曖昧になるおそれがあります。 この問題を回避するには、Mule アプリケーションの ​`mule-artifact.json`​ ファイルでドメインフォルダーの名前を追加します。 ```json { "domain": "mymuledomain-1.0.1-mule-domain" ... } ``` ### [](#studio-を使用して-mule-アプリケーションをドメインに関連付ける)Studio を使用して Mule アプリケーションをドメインに関連付ける Studio から Mule アプリケーションをドメインに関連付けるには、次の手順を実行します。 1. \[Project Explorer\] または \[Package Explorer\] ビューで Mule アプリケーションを右クリックします。 2. メニューが開きますので、​**\[Properties (プロパティ)\]**​ をクリックします。 3. \[Properties (プロパティ)\] で ​**\[Mule Project (Mule プロジェクト)\]**​ をクリックします。 4. **\[Domain (ドメイン)\]**​ 項目でプロジェクトのドメインを選択します。 ![割り当て + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-assign-domain.png) ドメインを選択すると、プロジェクトの Mule Runtime Engine が自動的にドメインの Mule Runtime Engine に一致します。 これらの手順を完了したら、Studio にプロジェクトの ​`pom.xml`​ のドメインが含まれます。次に例を示します。 ```xml ... com.mycompany mymuledomain 1.0.0-SNAPSHOT mule-domain provided ``` ### [](#studio-外で-mule-アプリケーションをドメインに関連付ける)Studio 外で Mule アプリケーションをドメインに関連付ける Studio 外で Mule アプリケーションをドメインに関連付けるには、前の例で示しているように、ドメインの連動関係を ​`pom.xml`​ ファイルに追加します。 ## [](#reference-shared-resources)共有リソースの参照 次の ​`mule-domain-config.xml`​ の例では、HTTP リスナーおよび HTTP 要求設定を共有リソースとして定義します。 ```xml ``` ドメインに関連付けられているすべての Mule アプリケーションは、プロジェクト自体の中でリソースを参照するのと同じように設定内でリソースを参照することによって共有リソースを利用できます。次の例では、HTTP Listener Connector が ​`HTTP_Listener_Configuration`​ という名前の共有リソースを参照しています。 ```xml ``` Studio のビジュアルエディターでは、コネクタのプロパティエディターの ​**\[Connector Configuration (コネクタ設定)\]**​ 項目にあるドロップダウンリストから共有リソースを選択できます。 ![選択 + リソース](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/pick-resource.png) ## [](#deploy-shared-resources)共有リソースとのデプロイ デフォルトでは、ドメインに関連付けられた Mule アプリケーションまたは Mule アプリケーションに関連付けられたドメインをデプロイすると、Anypoint Studio で両方がデプロイされます。このデフォルト動作を変更するには、ドメインの実行の設定を変更します。同じドメインを共有していなくても、ワークスペース内の一連の Mule アプリケーションをデプロイすることもできます。
Mule ドメインプロジェクトは、Runtime Manager ではインストールできません。
### [](#anypoint-studio-からのデプロイ)Anypoint Studio からのデプロイ Studio からドメインプロジェクトとそれに関連付けられた Mule アプリケーションをデプロイする手順は次のとおりです。 1. 再生ボタンの隣にあるドロップダウンメニューを開き、​**\[Run Configurations (設定の実行)\]**​ を選択します。 ![実行 + 設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-run-configuration.png) 2. **\[General (一般)\]**​ タブを選択し、右側のナビゲーションメニューで現在選択されている Mule アプリケーションと常に一緒にデプロイしたいプロジェクトのボックスを選択します。 ![実行 + 設定 + プロパティ](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-run-configuration-properties.png) ### [](#anypoint-studio-外でのデプロイ)Anypoint Studio 外でのデプロイ Studio 外でドメインプロジェクトと Mule アプリケーションをスタンドアロン Mule Runtime Engine にデプロイする手順は次のとおりです。 1. Studio で、​**\[File (ファイル)\]**​ > ​**\[Export (エクスポート)\]**​ を選択します。 2. **\[Mule\]**​ > ​**\[Anypoint Studio Project to Mule Deployable Archive (includes Studio metadata) (Anypoint Studio プロジェクトから Mule のデプロイ可能なアーカイブへ (Studio メタデータを含む))\]**​ を選択します。 このプロセスによって、スタンドアロン Mule Runtime Engine にデプロイできる JAR ファイルが作成されます。 ![mruntime export studio](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-export-studio.png) 3. エクスポートされたドメインの JAR ファイルを ​`MULE_HOME/domains`​ にコピーします。 4. デプロイする各 Mule アプリケーションとそれに関連付けられたドメインをエクスポートします。 5. ドメインを参照する各 Mule アプリケーションのエクスポートされた JAR ファイルを ​`MULE_HOME/apps`​ フォルダーにコピーします。 6. コマンドコンソールから Mule を起動します。 Mule が起動すると、Mule アプリケーションの起動前にすべてのドメインが完全に起動しているようにするため、Mule は先に ​`MULE_HOME/domains`​ フォルダーで見つかったドメインをすべてデプロイしてから、次に ​`MULE_HOME/apps`​ フォルダーで見つかった Mule アプリケーションをすべてデプロイします。 ### [](#mule-maven-プラグインを使用したドメインのデプロイ)Mule Maven プラグインを使用したドメインのデプロイ Mule Maven プラグインを使用してドメインをローカル Mule インスタンスにデプロイできます。 手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ドメインを使用することによるパフォーマンス向上の例)ドメインを使用することによるパフォーマンス向上の例 1 つのゲートウェイポリシー (IP 許可リストなど) も適用する HTTP プロキシアプリケーション群があるとします。各アプリケーションは同じバックエンドとやり取りします。2 GB のヒープメモリと 256 MB のメタスペースが設定された Mule インスタンスで、適切なドメインを使用せずにこれらのアプリケーションを 60 件以上、別々にデプロイすると、リソースの飽和によって TPS (毎秒のトランザクション数) が大幅に低下します。80 件のアプリケーションをデプロイすると、メモリ不足例外によってデプロイエラーとなります。 この問題は、バックエンドサーバー設定を共有するドメインを使用するだけで大幅に改善され、デプロイするアプリケーション数が 100 件を超えても、マシンリソースはバランスよく使用されて良好なパフォーマンスが維持されます。 ドメインを使用することでパフォーマンスは明らかに向上しますが、デプロイされる各アプリケーションには、共有インフラストラクチャリソースによる複雑さが追加されます。パフォーマンスへの影響を回避するため、アプリケーションを追加する前に、各アプリケーションを個別にテストすることでオーバーヘッドを特定してから、他のアプリケーションと共存させてテストしてください。 # 共有リソース (Mule ドメイン) Mule をオンプレミスにデプロイする場合は、共有プロパティ、スケジューラープール、コネクタ設定などのグローバル設定を定義して、同じドメインにデプロイされたすべてのアプリケーションで共有できます。これを行うには、Mule ドメインを作成し、各アプリケーションからそのドメインを参照します。そうすることで、その Mule ドメインに関連付けられた各アプリケーションがドメイン内の共有リソースにアクセスできるようになります。 Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができませんので注意してください。 同じオンプレミス Mule Runtime Engine (Mule) に複数のサービスをデプロイする場合は、ドメインを使用することでパフォーマンスを高めることができます。ドメインは、すべての共有リソースに対して中央管理ポイントを提供することにより、特に ​`pom.xml`​ ファイルで宣言されているドメインの連動関係もドメインアプリケーション間で共有するため、クラスローディングプロセス (そしてメタスペースメモリの使用) をより効率的にします。 共有リソースにより、同じコネクタ設定セットを使用して、複数の開発チームが並行して作業を行うことができるため、チームは次のことが可能になります。 - ドメイン内の複数のサービスを同じポートから公開できます。 - 永続的なストレージへの接続を共有できます。 - きちんと定義されたインターフェースを通して Mule アプリケーション間でサービスを共有できます。 - 設定を 1 箇所のみで行うため、変更があっても Mule アプリケーション間の一貫性を保証できます。 メタデータを共有する場合は、Mule ドメインプロジェクトを Anypoint Studio で開いたままにしておいてください。そうでないと、リンク先の Mule プロジェクトでメタデータを手動で入力しなければなりません。 ## [](#前提条件)前提条件 - Anypoint Studio 7.x - Mule Runtime Engine 4.x - オンプレミスでの Mule Runtime Engine の実行 ## [](#制限事項)制限事項 フロー、サブフロー、またはメッセージプロセッサーを共有リソースとして定義することはできません。ドメインでは、動作を共有することはできません。共有できるのはリソースのみです。 ## [](#アーキテクチャ)アーキテクチャ Anypoint Studio の Mule ドメインプロジェクトには次の主要ファイルが含まれます。
File Name (ファイル名) 説明

/src/main/mule/mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

pom.xml

連動関係ファイル記述子。ドメインプロジェクトに必要なプラグインが格納された Maven POM ファイルです。

/mule-artifact.json

ドメインアーティファクトの記述子。
Mule ドメインプロジェクトをデプロイ可能な JAR ファイルにパッケージ化すると、次のファイルが含まれます。
File Name (ファイル名) 説明

mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

/repository

ドメインのすべての連動関係が登録された Maven に似たリポジトリ。

/META-INF/maven/groupId/artifactId/pom.xml

アーティファクトの Maven 記述子ファイル。

/META-INF/mule-artifact/classloader-model.json

連動関係の管理に使用する内部 Mule ファイル。

/META-INF/mule-artifact/mule-artifact.json

ドメインアーティファクトの記述子。
## [](#configuration-設定)Configuration (設定) Mule アプリケーションで共有リソースを使用するには、次の作業を実行します。 1. [新しいドメインを作成します](#create_domain_project)​。 2. [そのドメインで 1 つまたは複数の共有リソースを定義します](#define-shared-resources)​。 3. [アプリケーションをドメインに関連付けます](#assoc_apps_domain)​。 4. Mule アプリケーションで​[共有リソースを参照します](#reference-shared-resources)​。 5. [ドメインと Mule アプリケーションを共有リソースと共にデプロイします](#deploy-shared-resources)​。 ## [](#create_domain_project)新規ドメインの作成 Anypoint Studio で新しいドメインを作成するには、次の手順を実行します。 1. 上部のメニューバーで ​**\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Domain Project (Mule ドメインプロジェクト)\]**​ を選択します。 ![新規 + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-new-domain.png) 2. 通常の Mule プロジェクトの作成時と同じ項目に値を入力します。 ![作成 + 新規 + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-create-domain.png) - プロジェクト名を入力して Mule バージョンを選択します。 ## [](#define-shared-resources)共有リソース設定 [ドメインプロジェクト](#create_domain_project)​を設定するには、​`mule-domain-config.xml`​ ファイルで 1 つ以上の共有リソースを定義します。このファイルは、Anypoint Studio で XML エディターまたはグラフィカルインターフェースを使用して編集できます。 ### [](#設定-xml-の編集による共有リソースの設定)設定 XML の編集による共有リソースの設定 ドメインの設定 XML にモジュールまたはコネクタの設定を追加することで、共有リソースを設定します。 次の例では、HTTP リスナーを共有リソースとして設定しています。 ```xml ``` ### [](#global-elements-グローバル要素-タブを使用した共有リソースの設定)\[Global Elements (グローバル要素)\] タブを使用した共有リソースの設定 Anypoint Studio の ​**\[Global Elements (グローバル要素)\]**​ タブを使用して共有リソースを設定すると、最初にドメインプロジェクトにモジュールを追加してからグローバル要素を作成できます。 たとえば、ドメインプロジェクトに HTTP 用 Anypoint Connector (HTTP Connector) を追加する手順は、次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Manage Modules (モジュールを管理)\]**​ をクリックします。 ![ドメインのモジュール管理](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-domain-manage-modules.png) 2. **\[Add Module (モジュールを追加)\]**​ をクリックします。 ![ドメインへのモジュールの追加](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-domain-add-module.png) 3. 追加するモジュールを検索し、​**\[Add > (追加 >)\]**​ をクリックします。 ![ドメインへのモジュール追加の完了](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-domain-add-module-finish.png) 4. **\[Finish (完了)\]**​ をクリックします。 ドメインプロジェクトに HTTP Connector を追加した後に、共有リソースとして使用するグローバル要素を作成できます。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Create (作成)\]**​ をクリックします。 ![ドメインの設定の作成](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-domain-create-config.png) 2. HTTP Connector を選択し、設定プロセスを実行します。 ![ドメインのコネクタ設定の作成](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-domain-connector-config.png) 3. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 ## [](#assoc_apps_domain)アプリケーションのドメインへの関連付け Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができません。Studio を使用するか、プロジェクトの ​`pom.xml`​ ファイルを直接編集するかのどちらかの方法で、既存の Mule アプリケーションをドメインに関連付けることができます。ドメインの連動関係を設定していない場合、Mule アプリケーションでは ​`default`​ ドメインが使用されます。 Mule 4.2.2 以降のバージョンを使用する場合は、次の点を考慮してください。 - バージョンではセマンティックバージョン設定が優先されます。 たとえば、バージョンを 1.0.1 に設定した場合、バージョン 1.0.2 以降のドメインは機能しますが、バージョン 1.0.0 のドメインは機能しません。 - 同じグループ ID、アーティファクト ID、バージョンを使用して異なるドメインがデプロイされると、​`pom.xml`​ ファイル内の参照が曖昧になるおそれがあります。 この問題を回避するには、Mule アプリケーションの ​`mule-artifact.json`​ ファイルでドメインフォルダーの名前を追加します。 ```json { "domain": "mymuledomain-1.0.1-mule-domain" ... } ``` ### [](#studio-を使用して-mule-アプリケーションをドメインに関連付ける)Studio を使用して Mule アプリケーションをドメインに関連付ける Studio から Mule アプリケーションをドメインに関連付けるには、次の手順を実行します。 1. \[Project Explorer\] または \[Package Explorer\] ビューで Mule アプリケーションを右クリックします。 2. メニューが開きますので、​**\[Properties (プロパティ)\]**​ をクリックします。 3. \[Properties (プロパティ)\] で ​**\[Mule Project (Mule プロジェクト)\]**​ をクリックします。 4. **\[Domain (ドメイン)\]**​ 項目でプロジェクトのドメインを選択します。 ![割り当て + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-assign-domain.png) ドメインを選択すると、プロジェクトの Mule Runtime Engine が自動的にドメインの Mule Runtime Engine に一致します。 これらの手順を完了したら、Studio にプロジェクトの ​`pom.xml`​ のドメインが含まれます。次に例を示します。 ```xml ... com.mycompany mymuledomain 1.0.0-SNAPSHOT mule-domain provided ``` ### [](#studio-外で-mule-アプリケーションをドメインに関連付ける)Studio 外で Mule アプリケーションをドメインに関連付ける Studio 外で Mule アプリケーションをドメインに関連付けるには、前の例で示しているように、ドメインの連動関係を ​`pom.xml`​ ファイルに追加します。 ## [](#reference-shared-resources)共有リソースの参照 次の ​`mule-domain-config.xml`​ の例では、HTTP リスナーおよび HTTP 要求設定を共有リソースとして定義します。 ```xml ``` ドメインに関連付けられているすべての Mule アプリケーションは、プロジェクト自体の中でリソースを参照するのと同じように設定内でリソースを参照することによって共有リソースを利用できます。次の例では、HTTP Listener Connector が ​`HTTP_Listener_Configuration`​ という名前の共有リソースを参照しています。 ```xml ``` Studio のビジュアルエディターでは、コネクタのプロパティエディターの ​**\[Connector Configuration (コネクタ設定)\]**​ 項目にあるドロップダウンリストから共有リソースを選択できます。 ![選択 + リソース](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/pick-resource.png) ## [](#deploy-shared-resources)共有リソースとのデプロイ デフォルトでは、ドメインに関連付けられた Mule アプリケーションまたは Mule アプリケーションに関連付けられたドメインをデプロイすると、Anypoint Studio で両方がデプロイされます。このデフォルト動作を変更するには、ドメインの実行の設定を変更します。同じドメインを共有していなくても、ワークスペース内の一連の Mule アプリケーションをデプロイすることもできます。
Mule ドメインプロジェクトは、Runtime Manager ではインストールできません。
### [](#anypoint-studio-からのデプロイ)Anypoint Studio からのデプロイ Studio からドメインプロジェクトとそれに関連付けられた Mule アプリケーションをデプロイする手順は次のとおりです。 1. 再生ボタンの隣にあるドロップダウンメニューを開き、​**\[Run Configurations (設定の実行)\]**​ を選択します。 ![実行 + 設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-run-configuration.png) 2. **\[General (一般)\]**​ タブを選択し、右側のナビゲーションメニューで現在選択されている Mule アプリケーションと常に一緒にデプロイしたいプロジェクトのボックスを選択します。 ![実行 + 設定 + プロパティ](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-run-configuration-properties.png) ### [](#anypoint-studio-外でのデプロイ)Anypoint Studio 外でのデプロイ Studio 外でドメインプロジェクトと Mule アプリケーションをスタンドアロン Mule Runtime Engine にデプロイする手順は次のとおりです。 1. Studio で、​**\[File (ファイル)\]**​ > ​**\[Export (エクスポート)\]**​ を選択します。 2. **\[Mule\]**​ > ​**\[Anypoint Studio Project to Mule Deployable Archive (includes Studio metadata) (Anypoint Studio プロジェクトから Mule のデプロイ可能なアーカイブへ (Studio メタデータを含む))\]**​ を選択します。 このプロセスによって、スタンドアロン Mule Runtime Engine にデプロイできる JAR ファイルが作成されます。 ![mruntime export studio](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-export-studio.png) 3. エクスポートされたドメインの JAR ファイルを ​`MULE_HOME/domains`​ にコピーします。 4. デプロイする各 Mule アプリケーションとそれに関連付けられたドメインをエクスポートします。 5. ドメインを参照する各 Mule アプリケーションのエクスポートされた JAR ファイルを ​`MULE_HOME/apps`​ フォルダーにコピーします。 6. コマンドコンソールから Mule を起動します。 Mule が起動すると、Mule アプリケーションの起動前にすべてのドメインが完全に起動しているようにするため、Mule は先に ​`MULE_HOME/domains`​ フォルダーで見つかったドメインをすべてデプロイしてから、次に ​`MULE_HOME/apps`​ フォルダーで見つかった Mule アプリケーションをすべてデプロイします。 ### [](#mule-maven-プラグインを使用したドメインのデプロイ)Mule Maven プラグインを使用したドメインのデプロイ Mule Maven プラグインを使用してドメインをローカル Mule インスタンスにデプロイできます。 手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ドメインを使用することによるパフォーマンス向上の例)ドメインを使用することによるパフォーマンス向上の例 1 つのゲートウェイポリシー (IP 許可リストなど) も適用する HTTP プロキシアプリケーション群があるとします。各アプリケーションは同じバックエンドとやり取りします。2 GB のヒープメモリと 256 MB のメタスペースが設定された Mule インスタンスで、適切なドメインを使用せずにこれらのアプリケーションを 60 件以上、別々にデプロイすると、リソースの飽和によって TPS (毎秒のトランザクション数) が大幅に低下します。80 件のアプリケーションをデプロイすると、メモリ不足例外によってデプロイエラーとなります。 この問題は、バックエンドサーバー設定を共有するドメインを使用するだけで大幅に改善され、デプロイするアプリケーション数が 100 件を超えても、マシンリソースはバランスよく使用されて良好なパフォーマンスが維持されます。 ドメインを使用することでパフォーマンスは明らかに向上しますが、デプロイされる各アプリケーションには、共有インフラストラクチャリソースによる複雑さが追加されます。パフォーマンスへの影響を回避するため、アプリケーションを追加する前に、各アプリケーションを個別にテストすることでオーバーヘッドを特定してから、他のアプリケーションと共存させてテストしてください。 # 共有リソース (Mule ドメイン) Mule をオンプレミスにデプロイする場合は、共有プロパティ、スケジューラープール、コネクタ設定などのグローバル設定を定義して、同じドメインにデプロイされたすべてのアプリケーションで共有できます。これを行うには、Mule ドメインを作成し、各アプリケーションからそのドメインを参照します。そうすることで、その Mule ドメインに関連付けられた各アプリケーションがドメイン内の共有リソースにアクセスできるようになります。 Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができませんので注意してください。 同じオンプレミス Mule Runtime Engine (Mule) に複数のサービスをデプロイする場合は、ドメインを使用することでパフォーマンスを高めることができます。ドメインは、すべての共有リソースに対して中央管理ポイントを提供することにより、特に ​`pom.xml`​ ファイルで宣言されているドメインの連動関係もドメインアプリケーション間で共有するため、クラスローディングプロセス (そしてメタスペースメモリの使用) をより効率的にします。 共有リソースにより、同じコネクタ設定セットを使用して、複数の開発チームが並行して作業を行うことができるため、チームは次のことが可能になります。 - ドメイン内の複数のサービスを同じポートから公開できます。 - 永続的なストレージへの接続を共有できます。 - きちんと定義されたインターフェースを通して Mule アプリケーション間でサービスを共有できます。 - 設定を 1 箇所のみで行うため、変更があっても Mule アプリケーション間の一貫性を保証できます。 メタデータを共有する場合は、Mule ドメインプロジェクトを Anypoint Studio で開いたままにしておいてください。そうでないと、リンク先の Mule プロジェクトでメタデータを手動で入力しなければなりません。 ## [](#前提条件)前提条件 - Anypoint Studio 7.x - Mule Runtime Engine 4.x - オンプレミスでの Mule Runtime Engine の実行 ## [](#制限事項)制限事項 フロー、サブフロー、またはメッセージプロセッサーを共有リソースとして定義することはできません。ドメインでは、動作を共有することはできません。共有できるのはリソースのみです。 ## [](#アーキテクチャ)アーキテクチャ Anypoint Studio の Mule ドメインプロジェクトには次の主要ファイルが含まれます。
File Name (ファイル名) 説明

/src/main/mule/mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

pom.xml

連動関係ファイル記述子。ドメインプロジェクトに必要なプラグインが格納された Maven POM ファイルです。

/mule-artifact.json

ドメインアーティファクトの記述子。
Mule ドメインプロジェクトをデプロイ可能な JAR ファイルにパッケージ化すると、次のファイルが含まれます。
File Name (ファイル名) 説明

mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

/repository

ドメインのすべての連動関係が登録された Maven に似たリポジトリ。

/META-INF/maven/groupId/artifactId/pom.xml

アーティファクトの Maven 記述子ファイル。

/META-INF/mule-artifact/classloader-model.json

連動関係の管理に使用する内部 Mule ファイル。

/META-INF/mule-artifact/mule-artifact.json

ドメインアーティファクトの記述子。
## [](#configuration-設定)Configuration (設定) Mule アプリケーションで共有リソースを使用するには、次の作業を実行します。 1. [新しいドメインを作成します](#create_domain_project)​。 2. [そのドメインで 1 つまたは複数の共有リソースを定義します](#define-shared-resources)​。 3. [アプリケーションをドメインに関連付けます](#assoc_apps_domain)​。 4. Mule アプリケーションで​[共有リソースを参照します](#reference-shared-resources)​。 5. [ドメインと Mule アプリケーションを共有リソースと共にデプロイします](#deploy-shared-resources)​。 ## [](#create_domain_project)新規ドメインの作成 Anypoint Studio で新しいドメインを作成するには、次の手順を実行します。 1. 上部のメニューバーで ​**\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Domain Project (Mule ドメインプロジェクト)\]**​ を選択します。 ![新規 + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-new-domain.png) 2. 通常の Mule プロジェクトの作成時と同じ項目に値を入力します。 ![作成 + 新規 + ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-create-domain.png) - プロジェクト名を入力して Mule バージョンを選択します。 ## [](#define-shared-resources)共有リソース設定 [ドメインプロジェクト](#create_domain_project)​を設定するには、​`mule-domain-config.xml`​ ファイルで 1 つ以上の共有リソースを定義します。このファイルは、Anypoint Studio で XML エディターまたはグラフィカルインターフェースを使用して編集できます。 ### [](#設定-xml-の編集による共有リソースの設定)設定 XML の編集による共有リソースの設定 ドメインの設定 XML にモジュールまたはコネクタの設定を追加することで、共有リソースを設定します。 次の例では、HTTP リスナーを共有リソースとして設定しています。 ```xml ``` ### [](#global-elements-グローバル要素-タブを使用した共有リソースの設定)\[Global Elements (グローバル要素)\] タブを使用した共有リソースの設定 Anypoint Studio の ​**\[Global Elements (グローバル要素)\]**​ タブを使用して共有リソースを設定すると、最初にドメインプロジェクトにモジュールを追加してからグローバル要素を作成できます。 たとえば、ドメインプロジェクトに HTTP 用 Anypoint Connector (HTTP Connector) を追加する手順は、次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Manage Modules (モジュールを管理)\]**​ をクリックします。 ![ドメインのモジュール管理](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-domain-manage-modules.png) 2. **\[Add Module (モジュールを追加)\]**​ をクリックします。 ![ドメインへのモジュールの追加](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-domain-add-module.png) 3. 追加するモジュールを検索し、​**\[Add > (追加 >)\]**​ をクリックします。 ![ドメインへのモジュール追加の完了](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-domain-add-module-finish.png) 4. **\[Finish (完了)\]**​ をクリックします。 ドメインプロジェクトに HTTP Connector を追加した後に、共有リソースとして使用するグローバル要素を作成できます。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Create (作成)\]**​ をクリックします。 ![ドメインの設定の作成](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-domain-create-config.png) 2. HTTP Connector を選択し、設定プロセスを実行します。 ![ドメインのコネクタ設定の作成](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-domain-connector-config.png) 3. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 ## [](#assoc_apps_domain)アプリケーションのドメインへの関連付け Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができません。Studio を使用するか、プロジェクトの ​`pom.xml`​ ファイルを直接編集するかのどちらかの方法で、既存の Mule アプリケーションをドメインに関連付けることができます。ドメインの連動関係を設定していない場合、Mule アプリケーションでは ​`default`​ ドメインが使用されます。 Mule 4.2.2 以降のバージョンを使用する場合は、次の点を考慮してください。 - バージョンではセマンティックバージョン設定が優先されます。 たとえば、バージョンを 1.0.1 に設定した場合、バージョン 1.0.2 以降のドメインは機能しますが、バージョン 1.0.0 のドメインは機能しません。 - 同じグループ ID、アーティファクト ID、バージョンを使用して異なるドメインがデプロイされると、​`pom.xml`​ ファイル内の参照が曖昧になるおそれがあります。 この問題を回避するには、Mule アプリケーションの ​`mule-artifact.json`​ ファイルでドメインフォルダーの名前を追加します。 ```json { "domain": "mymuledomain-1.0.1-mule-domain" ... } ``` ### [](#studio-を使用して-mule-アプリケーションをドメインに関連付ける)Studio を使用して Mule アプリケーションをドメインに関連付ける Studio から Mule アプリケーションをドメインに関連付けるには、次の手順を実行します。 1. \[Project Explorer\] または \[Package Explorer\] ビューで Mule アプリケーションを右クリックします。 2. メニューが開きますので、​**\[Properties (プロパティ)\]**​ をクリックします。 3. \[Properties (プロパティ)\] で ​**\[Mule Project (Mule プロジェクト)\]**​ をクリックします。 4. **\[Domain (ドメイン)\]**​ 項目でプロジェクトのドメインを選択します。 ![Anypoint Studio の Mule プロジェクトのドメイン割り当てオプション](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/assign-domain.png) ドメインを選択すると、プロジェクトの Mule Runtime Engine が自動的にドメインの Mule Runtime Engine に一致します。 これらの手順を完了したら、Studio にプロジェクトの ​`pom.xml`​ のドメインが含まれます。次に例を示します。 ```xml ... com.mycompany mymuledomain 1.0.0-SNAPSHOT mule-domain provided ``` ### [](#studio-外で-mule-アプリケーションをドメインに関連付ける)Studio 外で Mule アプリケーションをドメインに関連付ける Studio 外で Mule アプリケーションをドメインに関連付けるには、前の例で示しているように、ドメインの連動関係を ​`pom.xml`​ ファイルに追加します。 ## [](#reference-shared-resources)共有リソースの参照 次の ​`mule-domain-config.xml`​ の例では、HTTP リスナーおよび HTTP 要求設定を共有リソースとして定義します。 ```xml ``` ドメインに関連付けられているすべての Mule アプリケーションは、プロジェクト自体の中でリソースを参照するのと同じように設定内でリソースを参照することによって共有リソースを利用できます。次の例では、HTTP Listener Connector が ​`HTTP_Listener_Configuration`​ という名前の共有リソースを参照しています。 ```xml ``` Studio のビジュアルエディターでは、コネクタのプロパティエディターの ​**\[Connector Configuration (コネクタ設定)\]**​ 項目にあるドロップダウンリストから共有リソースを選択できます。 ![選択 + リソース](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/pick-resource.png) ## [](#deploy-shared-resources)共有リソースとのデプロイ デフォルトでは、ドメインに関連付けられた Mule アプリケーションまたは Mule アプリケーションに関連付けられたドメインをデプロイすると、Anypoint Studio で両方がデプロイされます。このデフォルト動作を変更するには、ドメインの実行の設定を変更します。同じドメインを共有していなくても、ワークスペース内の一連の Mule アプリケーションをデプロイすることもできます。
Mule ドメインプロジェクトは、Runtime Manager ではインストールできません。
### [](#anypoint-studio-からのデプロイ)Anypoint Studio からのデプロイ Studio からドメインプロジェクトとそれに関連付けられた Mule アプリケーションをデプロイする手順は次のとおりです。 1. 再生ボタンの隣にあるドロップダウンメニューを開き、​**\[Run Configurations (設定の実行)\]**​ を選択します。 ![実行 + 設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-run-configuration.png) 2. **\[General (一般)\]**​ タブを選択し、右側のナビゲーションメニューで現在選択されている Mule アプリケーションと常に一緒にデプロイしたいプロジェクトのボックスを選択します。 ![実行 + 設定 + プロパティ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-run-configuration-properties.png) ### [](#anypoint-studio-外でのデプロイ)Anypoint Studio 外でのデプロイ Studio 外でドメインプロジェクトと Mule アプリケーションをスタンドアロン Mule Runtime Engine にデプロイする手順は次のとおりです。 1. Studio で、​**\[File (ファイル)\]**​ > ​**\[Export (エクスポート)\]**​ を選択します。 2. **\[Mule\]**​ > ​**\[Anypoint Studio Project to Mule Deployable Archive (includes Studio metadata) (Anypoint Studio プロジェクトから Mule のデプロイ可能なアーカイブへ (Studio メタデータを含む))\]**​ を選択します。 このプロセスによって、スタンドアロン Mule Runtime Engine にデプロイできる JAR ファイルが作成されます。 ![mruntime export studio](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-export-studio.png) 3. エクスポートされたドメインの JAR ファイルを ​`MULE_HOME/domains`​ にコピーします。 4. デプロイする各 Mule アプリケーションとそれに関連付けられたドメインをエクスポートします。 5. ドメインを参照する各 Mule アプリケーションのエクスポートされた JAR ファイルを ​`MULE_HOME/apps`​ フォルダーにコピーします。 6. コマンドコンソールから Mule を起動します。 Mule が起動すると、Mule アプリケーションの起動前にすべてのドメインが完全に起動しているようにするため、Mule は先に ​`MULE_HOME/domains`​ フォルダーで見つかったドメインをすべてデプロイしてから、次に ​`MULE_HOME/apps`​ フォルダーで見つかった Mule アプリケーションをすべてデプロイします。 ### [](#mule-maven-プラグインを使用したドメインのデプロイ)Mule Maven プラグインを使用したドメインのデプロイ Mule Maven プラグインを使用してドメインをローカル Mule インスタンスにデプロイできます。 手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ドメインを使用することによるパフォーマンス向上の例)ドメインを使用することによるパフォーマンス向上の例 1 つのゲートウェイポリシー (IP 許可リストなど) も適用する HTTP プロキシアプリケーション群があるとします。各アプリケーションは同じバックエンドとやり取りします。2 GB のヒープメモリと 256 MB のメタスペースが設定された Mule インスタンスで、適切なドメインを使用せずにこれらのアプリケーションを 60 件以上、別々にデプロイすると、リソースの飽和によって TPS (毎秒のトランザクション数) が大幅に低下します。80 件のアプリケーションをデプロイすると、メモリ不足例外によってデプロイエラーとなります。 この問題は、バックエンドサーバー設定を共有するドメインを使用するだけで大幅に改善され、デプロイするアプリケーション数が 100 件を超えても、マシンリソースはバランスよく使用されて良好なパフォーマンスが維持されます。 ドメインを使用することでパフォーマンスは明らかに向上しますが、デプロイされる各アプリケーションには、共有インフラストラクチャリソースによる複雑さが追加されます。パフォーマンスへの影響を回避するため、アプリケーションを追加する前に、各アプリケーションを個別にテストすることでオーバーヘッドを特定してから、他のアプリケーションと共存させてテストしてください。 # 共有リソース (Mule ドメイン) Mule をオンプレミスにデプロイする場合は、共有プロパティ、スケジューラープール、コネクタ設定などのグローバル設定を定義して、同じドメインにデプロイされたすべてのアプリケーションで共有できます。これを行うには、Mule ドメインを作成し、各アプリケーションからそのドメインを参照します。そうすることで、その Mule ドメインに関連付けられた各アプリケーションがドメイン内の共有リソースにアクセスできるようになります。 Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができませんので注意してください。 同じオンプレミス Mule Runtime Engine (Mule) に複数のサービスをデプロイする場合は、ドメインを使用することでパフォーマンスを高めることができます。ドメインは、すべての共有リソースに対して中央管理ポイントを提供することにより、特に ​`pom.xml`​ ファイルで宣言されているドメインの連動関係もドメインアプリケーション間で共有するため、クラスローディングプロセス (そしてメタスペースメモリの使用) をより効率的にします。 共有リソースにより、同じコネクタ設定セットを使用して、複数の開発チームが並行して作業を行うことができるため、チームは次のことが可能になります。 - ドメイン内の複数のサービスを同じポートから公開できます。 - 永続的なストレージへの接続を共有できます。 - きちんと定義されたインターフェースを通して Mule アプリケーション間でサービスを共有できます。 - 設定を 1 箇所のみで行うため、変更があっても Mule アプリケーション間の一貫性を保証できます。 メタデータを共有する場合は、Mule ドメインプロジェクトを Anypoint Studio で開いたままにしておいてください。そうでないと、リンク先の Mule プロジェクトでメタデータを手動で入力しなければなりません。 ## [](#前提条件)前提条件 - Anypoint Studio 7.x - Mule Runtime Engine 4.x - オンプレミスでの Mule Runtime Engine の実行 ## [](#制限事項)制限事項 フロー、サブフロー、またはメッセージプロセッサーを共有リソースとして定義することはできません。ドメインでは、動作を共有することはできません。共有できるのはリソースのみです。 ## [](#アーキテクチャ)アーキテクチャ Anypoint Studio の Mule ドメインプロジェクトには次の主要ファイルが含まれます。
File Name (ファイル名) 説明

/src/main/mule/mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

pom.xml

連動関係ファイル記述子。ドメインプロジェクトに必要なプラグインが格納された Maven POM ファイルです。

/mule-artifact.json

ドメインアーティファクトの記述子。
Mule ドメインプロジェクトをデプロイ可能な JAR ファイルにパッケージ化すると、次のファイルが含まれます。
File Name (ファイル名) 説明

mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

/repository

ドメインのすべての連動関係が登録された Maven に似たリポジトリ。

/META-INF/maven/groupId/artifactId/pom.xml

アーティファクトの Maven 記述子ファイル。

/META-INF/mule-artifact/classloader-model.json

連動関係の管理に使用する内部 Mule ファイル。

/META-INF/mule-artifact/mule-artifact.json

ドメインアーティファクトの記述子。
## [](#configuration-設定)Configuration (設定) Mule アプリケーションで共有リソースを使用するには、次の作業を実行します。 1. [新しいドメインを作成します](#create_domain_project)​。 2. [そのドメインで 1 つまたは複数の共有リソースを定義します](#define-shared-resources)​。 3. [アプリケーションをドメインに関連付けます](#assoc_apps_domain)​。 4. Mule アプリケーションで​[共有リソースを参照します](#reference-shared-resources)​。 5. [ドメインと Mule アプリケーションを共有リソースと共にデプロイします](#deploy-shared-resources)​。 ## [](#create_domain_project)新規ドメインの作成 Anypoint Studio で新しいドメインを作成するには、次の手順を実行します。 1. 上部のメニューバーで ​**\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Domain Project (Mule ドメインプロジェクト)\]**​ を選択します。 ![Mule プロジェクトおよびドメインを管理するメニューオプション](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-new-domain.png) 2. 通常の Mule プロジェクトの作成時と同じ項目に値を入力します。 ![ランタイムバージョンのオプション表示されている新規 Mule ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-create-domain.png) - プロジェクト名を入力して Mule バージョンを選択します。 ## [](#define-shared-resources)共有リソース設定 [ドメインプロジェクト](#create_domain_project)​を設定するには、​`mule-domain-config.xml`​ ファイルで 1 つ以上の共有リソースを定義します。このファイルは、Anypoint Studio で XML エディターまたはグラフィカルインターフェースを使用して編集できます。 ### [](#設定-xml-の編集による共有リソースの設定)設定 XML の編集による共有リソースの設定 ドメインの設定 XML にモジュールまたはコネクタの設定を追加することで、共有リソースを設定します。 次の例では、HTTP リスナーを共有リソースとして設定しています。 ```xml ``` ### [](#global-elements-グローバル要素-タブを使用した共有リソースの設定)\[Global Elements (グローバル要素)\] タブを使用した共有リソースの設定 Anypoint Studio の ​**\[Global Elements (グローバル要素)\]**​ タブを使用して共有リソースを設定すると、最初にドメインプロジェクトにモジュールを追加してからグローバル要素を作成できます。 たとえば、ドメインプロジェクトに HTTP 用 Anypoint Connector (HTTP Connector) を追加する手順は、次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Manage Modules (モジュールを管理)\]**​ をクリックします。 ![Mule ドメイン設定のモジュールを管理するインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-domain-manage-modules.png) 2. **\[Add Module (モジュールを追加)\]**​ をクリックします。 ![モジュールをプロジェクトに追加する設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-domain-add-module.png) 3. 追加するモジュールを検索し、​**\[Add > (追加 >)\]**​ をクリックします。 ![MuleSoft Exchange からプロジェクトにモジュールを追加する検索インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-domain-add-module-finish.png) 4. **\[Finish (完了)\]**​ をクリックします。 ドメインプロジェクトに HTTP Connector を追加した後に、共有リソースとして使用するグローバル要素を作成できます。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Create (作成)\]**​ をクリックします。 ![Mule ドメインのグローバル設定要素を作成および管理するインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-domain-create-config.png) 2. HTTP Connector を選択し、設定プロセスを実行します。 ![グローバル要素種別 (HTTP やソケット設定を含む) を選択するメニュー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-domain-connector-config.png) 3. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 ## [](#assoc_apps_domain)アプリケーションのドメインへの関連付け Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができません。Studio を使用するか、プロジェクトの ​`pom.xml`​ ファイルを直接編集するかのどちらかの方法で、既存の Mule アプリケーションをドメインに関連付けることができます。ドメインの連動関係を設定していない場合、Mule アプリケーションでは ​`default`​ ドメインが使用されます。 Mule 4.2.2 以降のバージョンを使用する場合は、次の点を考慮してください。 - バージョンではセマンティックバージョン設定が優先されます。 たとえば、バージョンを 1.0.1 に設定した場合、バージョン 1.0.2 以降のドメインは機能しますが、バージョン 1.0.0 のドメインは機能しません。 - 同じグループ ID、アーティファクト ID、バージョンを使用して異なるドメインがデプロイされると、​`pom.xml`​ ファイル内の参照が曖昧になるおそれがあります。 この問題を回避するには、Mule アプリケーションの ​`mule-artifact.json`​ ファイルでドメインフォルダーの名前を追加します。 ```json { "domain": "mymuledomain-1.0.1-mule-domain" ... } ``` ### [](#studio-を使用して-mule-アプリケーションをドメインに関連付ける)Studio を使用して Mule アプリケーションをドメインに関連付ける Studio から Mule アプリケーションをドメインに関連付けるには、次の手順を実行します。 1. \[Project Explorer\] または \[Package Explorer\] ビューで Mule アプリケーションを右クリックします。 2. メニューが開きますので、​**\[Properties (プロパティ)\]**​ をクリックします。 3. \[Properties (プロパティ)\] で ​**\[Mule Project (Mule プロジェクト)\]**​ をクリックします。 4. **\[Domain (ドメイン)\]**​ 項目でプロジェクトのドメインを選択します。 ![Anypoint Studio の Mule プロジェクトのドメイン割り当てオプション](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/assign-domain.png) ドメインを選択すると、プロジェクトの Mule Runtime Engine が自動的にドメインの Mule Runtime Engine に一致します。 これらの手順を完了したら、Studio にプロジェクトの ​`pom.xml`​ のドメインが含まれます。次に例を示します。 ```xml ... com.mycompany mymuledomain 1.0.0-SNAPSHOT mule-domain provided ``` ### [](#studio-外で-mule-アプリケーションをドメインに関連付ける)Studio 外で Mule アプリケーションをドメインに関連付ける Studio 外で Mule アプリケーションをドメインに関連付けるには、前の例で示しているように、ドメインの連動関係を ​`pom.xml`​ ファイルに追加します。 ## [](#reference-shared-resources)共有リソースの参照 次の ​`mule-domain-config.xml`​ の例では、HTTP リスナーおよび HTTP 要求設定を共有リソースとして定義します。 ```xml ``` ドメインに関連付けられているすべての Mule アプリケーションは、プロジェクト自体の中でリソースを参照するのと同じように設定内でリソースを参照することによって共有リソースを利用できます。次の例では、HTTP Listener Connector が ​`HTTP_Listener_Configuration`​ という名前の共有リソースを参照しています。 ```xml ``` Studio のビジュアルエディターでは、コネクタのプロパティエディターの ​**\[Connector Configuration (コネクタ設定)\]**​ 項目にあるドロップダウンリストから共有リソースを選択できます。 ![パスと許可されるメソッドが表示されている HTTP リソースの設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/pick-resource.png) ## [](#deploy-shared-resources)共有リソースとのデプロイ デフォルトでは、ドメインに関連付けられた Mule アプリケーションまたは Mule アプリケーションに関連付けられたドメインをデプロイすると、Anypoint Studio で両方がデプロイされます。このデフォルト動作を変更するには、ドメインの実行の設定を変更します。同じドメインを共有していなくても、ワークスペース内の一連の Mule アプリケーションをデプロイすることもできます。
Mule ドメインプロジェクトは、Runtime Manager ではインストールできません。
### [](#anypoint-studio-からのデプロイ)Anypoint Studio からのデプロイ Studio からドメインプロジェクトとそれに関連付けられた Mule アプリケーションをデプロイする手順は次のとおりです。 1. 再生ボタンの隣にあるドロップダウンメニューを開き、​**\[Run Configurations (設定の実行)\]**​ を選択します。 ![Mule プロジェクトを管理および実行するオプションが表示されている \[Run configurations (設定の実行)\] メニュー](_images/mruntime-run-configuration.png) 2. **\[General (一般)\]**​ タブを選択し、右側のナビゲーションメニューで現在選択されている Mule アプリケーションと常に一緒にデプロイしたいプロジェクトのボックスを選択します。 ![Mule アプリケーションおよびドメインのオプションが表示されている \[Run configuration (設定の実行)\] プロパティ](_images/mruntime-run-configuration-properties.png) ### [](#anypoint-studio-外でのデプロイ)Anypoint Studio 外でのデプロイ Studio 外でドメインプロジェクトと Mule アプリケーションをスタンドアロン Mule Runtime Engine にデプロイする手順は次のとおりです。 1. Studio で、​**\[File (ファイル)\]**​ > ​**\[Export (エクスポート)\]**​ を選択します。 2. **\[Mule\]**​ > ​**\[Anypoint Studio Project to Mule Deployable Archive (includes Studio metadata) (Anypoint Studio プロジェクトから Mule のデプロイ可能なアーカイブへ (Studio メタデータを含む))\]**​ を選択します。 このプロセスによって、スタンドアロン Mule Runtime Engine にデプロイできる JAR ファイルが作成されます。 ![Anypoint Studio からさまざまなエクスポート先にプロジェクトをエクスポートするメニュー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-export-studio.png) 3. エクスポートされたドメインの JAR ファイルを ​`MULE_HOME/domains`​ にコピーします。 4. デプロイする各 Mule アプリケーションとそれに関連付けられたドメインをエクスポートします。 5. ドメインを参照する各 Mule アプリケーションのエクスポートされた JAR ファイルを ​`MULE_HOME/apps`​ フォルダーにコピーします。 6. コマンドコンソールから Mule を起動します。 Mule が起動すると、Mule アプリケーションの起動前にすべてのドメインが完全に起動しているようにするため、Mule は先に ​`MULE_HOME/domains`​ フォルダーで見つかったドメインをすべてデプロイしてから、次に ​`MULE_HOME/apps`​ フォルダーで見つかった Mule アプリケーションをすべてデプロイします。 ### [](#mule-maven-プラグインを使用したドメインのデプロイ)Mule Maven プラグインを使用したドメインのデプロイ Mule Maven プラグインを使用してドメインをローカル Mule インスタンスにデプロイできます。 手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ドメインを使用することによるパフォーマンス向上の例)ドメインを使用することによるパフォーマンス向上の例 1 つのゲートウェイポリシー (IP 許可リストなど) も適用する HTTP プロキシアプリケーション群があるとします。各アプリケーションは同じバックエンドとやり取りします。2 GB のヒープメモリと 256 MB のメタスペースが設定された Mule インスタンスで、適切なドメインを使用せずにこれらのアプリケーションを 60 件以上、別々にデプロイすると、リソースの飽和によって TPS (毎秒のトランザクション数) が大幅に低下します。80 件のアプリケーションをデプロイすると、メモリ不足例外によってデプロイエラーとなります。 この問題は、バックエンドサーバー設定を共有するドメインを使用するだけで大幅に改善され、デプロイするアプリケーション数が 100 件を超えても、マシンリソースはバランスよく使用されて良好なパフォーマンスが維持されます。 ドメインを使用することでパフォーマンスは明らかに向上しますが、デプロイされる各アプリケーションには、共有インフラストラクチャリソースによる複雑さが追加されます。パフォーマンスへの影響を回避するため、アプリケーションを追加する前に、各アプリケーションを個別にテストすることでオーバーヘッドを特定してから、他のアプリケーションと共存させてテストしてください。 # 共有リソース (Mule ドメイン) Mule をオンプレミスにデプロイする場合は、共有プロパティ、スケジューラープール、コネクタ設定などのグローバル設定を定義して、同じドメインにデプロイされたすべてのアプリケーションで共有できます。これを行うには、Mule ドメインを作成し、各アプリケーションからそのドメインを参照します。そうすることで、その Mule ドメインに関連付けられた各アプリケーションがドメイン内の共有リソースにアクセスできるようになります。 Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができませんので注意してください。 同じオンプレミス Mule Runtime Engine (Mule) に複数のサービスをデプロイする場合は、ドメインを使用することでパフォーマンスを高めることができます。ドメインは、すべての共有リソースに対して中央管理ポイントを提供することにより、特に ​`pom.xml`​ ファイルで宣言されているドメインの連動関係もドメインアプリケーション間で共有するため、クラスローディングプロセス (そしてメタスペースメモリの使用) をより効率的にします。 共有リソースにより、同じコネクタ設定セットを使用して、複数の開発チームが並行して作業を行うことができるため、チームは次のことが可能になります。 - ドメイン内の複数のサービスを同じポートから公開できます。 - 永続的なストレージへの接続を共有できます。 - きちんと定義されたインターフェースを通して Mule アプリケーション間でサービスを共有できます。 - 設定を 1 箇所のみで行うため、変更があっても Mule アプリケーション間の一貫性を保証できます。 メタデータを共有する場合は、Mule ドメインプロジェクトを Anypoint Studio で開いたままにしておいてください。そうでないと、リンク先の Mule プロジェクトでメタデータを手動で入力しなければなりません。 ## [](#前提条件)前提条件 - Anypoint Studio 7.x - Mule Runtime Engine 4.x - オンプレミスでの Mule Runtime Engine の実行 ## [](#制限事項)制限事項 フロー、サブフロー、またはメッセージプロセッサーを共有リソースとして定義することはできません。ドメインでは、動作を共有することはできません。共有できるのはリソースのみです。 ## [](#アーキテクチャ)アーキテクチャ Anypoint Studio の Mule ドメインプロジェクトには次の主要ファイルが含まれます。
File Name (ファイル名) 説明

/src/main/mule/mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

pom.xml

連動関係ファイル記述子。ドメインプロジェクトに必要なプラグインが格納された Maven POM ファイルです。

/mule-artifact.json

ドメインアーティファクトの記述子。
Mule ドメインプロジェクトをデプロイ可能な JAR ファイルにパッケージ化すると、次のファイルが含まれます。
File Name (ファイル名) 説明

mule-domain-config.xml

共有リソース設定ファイル。ファイル名は ​mule-domain-config.xml​ でなければなりません。

/repository

ドメインのすべての連動関係が登録された Maven に似たリポジトリ。

/META-INF/maven/groupId/artifactId/pom.xml

アーティファクトの Maven 記述子ファイル。

/META-INF/mule-artifact/classloader-model.json

連動関係の管理に使用する内部 Mule ファイル。

/META-INF/mule-artifact/mule-artifact.json

ドメインアーティファクトの記述子。
## [](#configuration-設定)Configuration (設定) Mule アプリケーションで共有リソースを使用するには、次の作業を実行します。 1. [新しいドメインを作成します](#create_domain_project)​。 2. [そのドメインで 1 つまたは複数の共有リソースを定義します](#define-shared-resources)​。 3. [アプリケーションをドメインに関連付けます](#assoc_apps_domain)​。 4. Mule アプリケーションで​[共有リソースを参照します](#reference-shared-resources)​。 5. [ドメインと Mule アプリケーションを共有リソースと共にデプロイします](#deploy-shared-resources)​。 ## [](#create_domain_project)新規ドメインの作成 Anypoint Studio で新しいドメインを作成するには、次の手順を実行します。 1. 上部のメニューバーで ​**\[File (ファイル)\]**​ > ​**\[New (新規)\]**​ > ​**\[Mule Domain Project (Mule ドメインプロジェクト)\]**​ を選択します。 ![Mule プロジェクトおよびドメインを管理するメニューオプション](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-new-domain.png) 2. 通常の Mule プロジェクトの作成時と同じ項目に値を入力します。 ![ランタイムバージョンのオプション表示されている新規 Mule ドメイン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-create-domain.png) - プロジェクト名を入力して Mule バージョンを選択します。 ## [](#define-shared-resources)共有リソース設定 [ドメインプロジェクト](#create_domain_project)​を設定するには、​`mule-domain-config.xml`​ ファイルで 1 つ以上の共有リソースを定義します。このファイルは、Anypoint Studio で XML エディターまたはグラフィカルインターフェースを使用して編集できます。 ### [](#設定-xml-の編集による共有リソースの設定)設定 XML の編集による共有リソースの設定 ドメインの設定 XML にモジュールまたはコネクタの設定を追加することで、共有リソースを設定します。 次の例では、HTTP リスナーを共有リソースとして設定しています。 ```xml ``` ### [](#global-elements-グローバル要素-タブを使用した共有リソースの設定)\[Global Elements (グローバル要素)\] タブを使用した共有リソースの設定 Anypoint Studio の ​**\[Global Elements (グローバル要素)\]**​ タブを使用して共有リソースを設定すると、最初にドメインプロジェクトにモジュールを追加してからグローバル要素を作成できます。 たとえば、ドメインプロジェクトに HTTP 用 Anypoint Connector (HTTP Connector) を追加する手順は、次のとおりです。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Manage Modules (モジュールを管理)\]**​ をクリックします。 ![Mule ドメイン設定のモジュールを管理するインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-domain-manage-modules.png) 2. **\[Add Module (モジュールを追加)\]**​ をクリックします。 ![モジュールをプロジェクトに追加する設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-domain-add-module.png) 3. 追加するモジュールを検索し、​**\[Add > (追加 >)\]**​ をクリックします。 ![MuleSoft Exchange からプロジェクトにモジュールを追加する検索インターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-domain-add-module-finish.png) 4. **\[Finish (完了)\]**​ をクリックします。 ドメインプロジェクトに HTTP Connector を追加した後に、共有リソースとして使用するグローバル要素を作成できます。 1. **\[Global Elements (グローバル要素)\]**​ タブで、​**\[Create (作成)\]**​ をクリックします。 ![Mule ドメインのグローバル設定要素を作成および管理するインターフェース](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-domain-create-config.png) 2. HTTP Connector を選択し、設定プロセスを実行します。 ![グローバル要素種別 (HTTP やソケット設定を含む) を選択するメニュー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-domain-connector-config.png) 3. **\[Global Element Properties (グローバル要素のプロパティ)\]**​ ウィンドウで、グローバル要素の設定可能なパラメーターを定義します。 ## [](#assoc_apps_domain)アプリケーションのドメインへの関連付け Mule アプリケーションは、一度に 1 つのドメインにしか関連付けることができません。Studio を使用するか、プロジェクトの ​`pom.xml`​ ファイルを直接編集するかのどちらかの方法で、既存の Mule アプリケーションをドメインに関連付けることができます。ドメインの連動関係を設定していない場合、Mule アプリケーションでは ​`default`​ ドメインが使用されます。 Mule 4.2.2 以降のバージョンを使用する場合は、次の点を考慮してください。 - バージョンではセマンティックバージョン設定が優先されます。 たとえば、バージョンを 1.0.1 に設定した場合、バージョン 1.0.2 以降のドメインは機能しますが、バージョン 1.0.0 のドメインは機能しません。 - 同じグループ ID、アーティファクト ID、バージョンを使用して異なるドメインがデプロイされると、​`pom.xml`​ ファイル内の参照が曖昧になるおそれがあります。 この問題を回避するには、Mule アプリケーションの ​`mule-artifact.json`​ ファイルでドメインフォルダーの名前を追加します。 ```json { "domain": "mymuledomain-1.0.1-mule-domain" ... } ``` ### [](#studio-を使用して-mule-アプリケーションをドメインに関連付ける)Studio を使用して Mule アプリケーションをドメインに関連付ける Studio から Mule アプリケーションをドメインに関連付けるには、次の手順を実行します。 1. \[Project Explorer\] または \[Package Explorer\] ビューで Mule アプリケーションを右クリックします。 2. メニューが開きますので、​**\[Properties (プロパティ)\]**​ をクリックします。 3. \[Properties (プロパティ)\] で ​**\[Mule Project (Mule プロジェクト)\]**​ をクリックします。 4. **\[Domain (ドメイン)\]**​ 項目でプロジェクトのドメインを選択します。 ![Anypoint Studio の Mule プロジェクトのドメイン割り当てオプション](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/assign-domain.png) ドメインを選択すると、プロジェクトの Mule Runtime Engine が自動的にドメインの Mule Runtime Engine に一致します。 これらの手順を完了したら、Studio にプロジェクトの ​`pom.xml`​ のドメインが含まれます。次に例を示します。 ```xml ... com.mycompany mymuledomain 1.0.0-SNAPSHOT mule-domain provided ``` ### [](#studio-外で-mule-アプリケーションをドメインに関連付ける)Studio 外で Mule アプリケーションをドメインに関連付ける Studio 外で Mule アプリケーションをドメインに関連付けるには、前の例で示しているように、ドメインの連動関係を ​`pom.xml`​ ファイルに追加します。 ## [](#reference-shared-resources)共有リソースの参照 次の ​`mule-domain-config.xml`​ の例では、HTTP リスナーおよび HTTP 要求設定を共有リソースとして定義します。 ```xml ``` ドメインに関連付けられているすべての Mule アプリケーションは、プロジェクト自体の中でリソースを参照するのと同じように設定内でリソースを参照することによって共有リソースを利用できます。次の例では、HTTP Listener Connector が ​`HTTP_Listener_Configuration`​ という名前の共有リソースを参照しています。 ```xml ``` Studio のビジュアルエディターでは、コネクタのプロパティエディターの ​**\[Connector Configuration (コネクタ設定)\]**​ 項目にあるドロップダウンリストから共有リソースを選択できます。 ![パスと許可されるメソッドが表示されている HTTP リソースの設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/pick-resource.png) ## [](#deploy-shared-resources)共有リソースとのデプロイ デフォルトでは、ドメインに関連付けられた Mule アプリケーションまたは Mule アプリケーションに関連付けられたドメインをデプロイすると、Anypoint Studio で両方がデプロイされます。このデフォルト動作を変更するには、ドメインの実行の設定を変更します。同じドメインを共有していなくても、ワークスペース内の一連の Mule アプリケーションをデプロイすることもできます。
Mule ドメインプロジェクトは、Runtime Manager ではインストールできません。
### [](#anypoint-studio-からのデプロイ)Anypoint Studio からのデプロイ Studio からドメインプロジェクトとそれに関連付けられた Mule アプリケーションをデプロイする手順は次のとおりです。 1. 再生ボタンの隣にあるドロップダウンメニューを開き、​**\[Run Configurations (設定の実行)\]**​ を選択します。 ![Mule プロジェクトを管理および実行するオプションが表示されている \[Run configurations (設定の実行)\] メニュー](_images/mruntime-run-configuration.png) 2. **\[General (一般)\]**​ タブを選択し、右側のナビゲーションメニューで現在選択されている Mule アプリケーションと常に一緒にデプロイしたいプロジェクトのボックスを選択します。 ![Mule アプリケーションおよびドメインのオプションが表示されている \[Run configuration (設定の実行)\] プロパティ](_images/mruntime-run-configuration-properties.png) ### [](#anypoint-studio-外でのデプロイ)Anypoint Studio 外でのデプロイ Studio 外でドメインプロジェクトと Mule アプリケーションをスタンドアロン Mule Runtime Engine にデプロイする手順は次のとおりです。 1. Studio で、​**\[File (ファイル)\]**​ > ​**\[Export (エクスポート)\]**​ を選択します。 2. **\[Mule\]**​ > ​**\[Anypoint Studio Project to Mule Deployable Archive (includes Studio metadata) (Anypoint Studio プロジェクトから Mule のデプロイ可能なアーカイブへ (Studio メタデータを含む))\]**​ を選択します。 このプロセスによって、スタンドアロン Mule Runtime Engine にデプロイできる JAR ファイルが作成されます。 ![Anypoint Studio からさまざまなエクスポート先にプロジェクトをエクスポートするメニュー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-export-studio.png) 3. エクスポートされたドメインの JAR ファイルを ​`MULE_HOME/domains`​ にコピーします。 4. デプロイする各 Mule アプリケーションとそれに関連付けられたドメインをエクスポートします。 5. ドメインを参照する各 Mule アプリケーションのエクスポートされた JAR ファイルを ​`MULE_HOME/apps`​ フォルダーにコピーします。 6. コマンドコンソールから Mule を起動します。 Mule が起動すると、Mule アプリケーションの起動前にすべてのドメインが完全に起動しているようにするため、Mule は先に ​`MULE_HOME/domains`​ フォルダーで見つかったドメインをすべてデプロイしてから、次に ​`MULE_HOME/apps`​ フォルダーで見つかった Mule アプリケーションをすべてデプロイします。 ### [](#mule-maven-プラグインを使用したドメインのデプロイ)Mule Maven プラグインを使用したドメインのデプロイ Mule Maven プラグインを使用してドメインをローカル Mule インスタンスにデプロイできます。 手順は、​[「ドメインのデプロイ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/deploy-on-premises#deploy-a-domain)​を参照してください。 ## [](#ドメインを使用することによるパフォーマンス向上の例)ドメインを使用することによるパフォーマンス向上の例 1 つのゲートウェイポリシー (IP 許可リストなど) も適用する HTTP プロキシアプリケーション群があるとします。各アプリケーションは同じバックエンドとやり取りします。2 GB のヒープメモリと 256 MB のメタスペースが設定された Mule インスタンスで、適切なドメインを使用せずにこれらのアプリケーションを 60 件以上、別々にデプロイすると、リソースの飽和によって TPS (毎秒のトランザクション数) が大幅に低下します。80 件のアプリケーションをデプロイすると、メモリ不足例外によってデプロイエラーとなります。 この問題は、バックエンドサーバー設定を共有するドメインを使用するだけで大幅に改善され、デプロイするアプリケーション数が 100 件を超えても、マシンリソースはバランスよく使用されて良好なパフォーマンスが維持されます。 ドメインを使用することでパフォーマンスは明らかに向上しますが、デプロイされる各アプリケーションには、共有インフラストラクチャリソースによる複雑さが追加されます。パフォーマンスへの影響を回避するため、アプリケーションを追加する前に、各アプリケーションを個別にテストすることでオーバーヘッドを特定してから、他のアプリケーションと共存させてテストしてください。 # 再接続戦略 Mule アプリケーション内の操作が外部サーバーへの接続に失敗すると、デフォルト動作ではその操作は直ちに失敗し、接続エラーが返されます。 たとえば、FTP 用 Anypoint Connector (FTP Connector) の操作が FTP サーバーへの接続に失敗すると、操作は ​`FTP:CONNECTIVITY`​ エラーをスローします。エラー名には、​`FTP:CONNECTIVITY`​ や ​`DB:CONNECTIVITY`​ (データベース用 Anypoint Connector (Database Connector) の場合) など、コネクタ固有の名前空間が反映されます。 このデフォルト動作を変更するには、操作の再接続戦略を設定します。
操作を実行しても、接続エラーで失敗すると、FTP Connector で設定された再接続戦略はトリガーされません。この例では、新規または更新されたファイルを照会する FTP サーバーで ​ftp:listener​ を確立する必要がある接続にのみ再接続戦略が適用されます。
## [](#操作の再接続戦略の設定)操作の再接続戦略の設定 操作の再接続戦略を設定するには、操作のプロパティを変更するか、または操作のグローバル要素の設定を変更します。たとえば、FTP Connector 設定で再接続戦略を設定できます。 ![接続戦略の設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-reconnection-strategy-ftp.png) 使用できる再接続戦略とそれぞれの動作は次のとおりです。 - **None (なし)** デフォルトの動作です。接続に失敗すると直ちに接続エラーを返します。 - **Standard (標準)**​ (​`reconnect`​) 接続エラーを返すまでの再接続試行回数と再接続を実行する間隔を設定します。 - **Forever (無期限)**​ (​`reconnect-forever`​) 指定された間隔で再接続を継続して試みます。 ## [](#xml-再接続戦略設定の例)XML 再接続戦略設定の例 それぞれの再接続戦略と設定の例を示します。 - Standard 再接続戦略の例 FTP Connector 設定における Standard 再接続戦略の例です。失敗までの再接続試行回数を ​`5`​ に設定し、接続テストが失敗した場合にはアプリケーションのデプロイも失敗するように ​`failsDeployment`​ を ​`true`​ に設定します。頻度が指定されていないため、デフォルトの 2000 ms ごとに接続が再試行されます。 ```xml ``` - Forever 再接続戦略の例 FTP Connector 設定における Forever 再接続戦略の例です。コネクタは、アプリケーションが実行されている限り、4000 ms ごとに接続を再試行します。 ```xml ``` ## [](#再接続戦略リファレンス)再接続戦略リファレンス Mule アプリケーションの XML 設定ファイルを編集することで設定できる再接続戦略ごとの設定属性を以下に示します。 - ``​ の属性
Name (名前) 型 必須 デフォルト 説明

failsDeployment

boolean (ブール)

no (いいえ)

false

true​ の場合は、接続テストが失敗するとデプロイも失敗します。
- ``​ の属性
Name (名前) 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒)

count

integer (整数)

no (いいえ)

2

再接続を試みる回数
- ``​ の属性
Name (名前) 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒) を指定します。
## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-components) - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) - [グローバル要素の設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/global-elements) # 再接続戦略 Mule アプリケーション内の操作が外部サーバーへの接続に失敗すると、デフォルト動作ではその操作は直ちに失敗し、接続エラーが返されます。 たとえば、FTP 用 Anypoint Connector (FTP Connector) の操作が FTP サーバーへの接続に失敗すると、操作は ​`FTP:CONNECTIVITY`​ エラーをスローします。エラー名には、​`FTP:CONNECTIVITY`​ や ​`DB:CONNECTIVITY`​ (データベース用 Anypoint Connector (Database Connector) の場合) など、コネクタ固有の名前空間が反映されます。 このデフォルト動作を変更するには、操作の再接続戦略を設定します。
操作を実行しても、接続エラーで失敗すると、FTP Connector で設定された再接続戦略はトリガーされません。この例では、新規または更新されたファイルを照会する FTP サーバーで ​ftp:listener​ を確立する必要がある接続にのみ再接続戦略が適用されます。
## [](#操作の再接続戦略の設定)操作の再接続戦略の設定 操作の再接続戦略を設定するには、操作のプロパティを変更するか、または操作のグローバル要素の設定を変更します。たとえば、FTP Connector 設定で再接続戦略を設定できます。 ![接続戦略の設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-reconnection-strategy-ftp.png) 使用できる再接続戦略とそれぞれの動作は次のとおりです。 - **None (なし)** デフォルトの動作です。接続に失敗すると直ちに接続エラーを返します。 - **Standard (標準)**​ (​`reconnect`​) 接続エラーを返すまでの再接続試行回数と再接続を実行する間隔を設定します。 - **Forever (無期限)**​ (​`reconnect-forever`​) 指定された間隔で再接続を継続して試みます。 ## [](#xml-再接続戦略設定の例)XML 再接続戦略設定の例 それぞれの再接続戦略と設定の例を示します。 - Standard 再接続戦略の例 FTP Connector 設定における Standard 再接続戦略の例です。失敗までの再接続試行回数を ​`5`​ に設定し、接続テストが失敗した場合にはアプリケーションのデプロイも失敗するように ​`failsDeployment`​ を ​`true`​ に設定します。頻度が指定されていないため、デフォルトの 2000 ms ごとに接続が再試行されます。 ```xml ``` - Forever 再接続戦略の例 FTP Connector 設定における Forever 再接続戦略の例です。コネクタは、アプリケーションが実行されている限り、4000 ms ごとに接続を再試行します。 ```xml ``` ## [](#再接続戦略リファレンス)再接続戦略リファレンス Mule アプリケーションの XML 設定ファイルを編集することで設定できる再接続戦略ごとの設定属性を以下に示します。 - ``​ の属性
Name (名前) 型 必須 デフォルト 説明

failsDeployment

boolean (ブール)

no (いいえ)

false

true​ の場合は、接続テストが失敗するとデプロイも失敗します。
- ``​ の属性
Name (名前) 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒)

count

integer (整数)

no (いいえ)

2

再接続を試みる回数
- ``​ の属性
Name (名前) 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒) を指定します。
## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-components) - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) - [グローバル要素の設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/global-elements) # 再接続戦略 Mule アプリケーション内の操作が外部サーバーへの接続に失敗すると、デフォルト動作ではその操作は直ちに失敗し、接続エラーが返されます。 たとえば、FTP 用 Anypoint Connector (FTP Connector) の操作が FTP サーバーへの接続に失敗すると、操作は ​`FTP:CONNECTIVITY`​ エラーをスローします。エラー名には、​`FTP:CONNECTIVITY`​ や ​`DB:CONNECTIVITY`​ (データベース用 Anypoint Connector (Database Connector) の場合) など、コネクタ固有の名前空間が反映されます。 このデフォルト動作を変更するには、操作の再接続戦略を設定します。
操作を実行しても、接続エラーで失敗すると、FTP Connector で設定された再接続戦略はトリガーされません。この例では、新規または更新されたファイルを照会する FTP サーバーで ​ftp:listener​ を確立する必要がある接続にのみ再接続戦略が適用されます。
## [](#操作の再接続戦略の設定)操作の再接続戦略の設定 操作の再接続戦略を設定するには、操作のプロパティを変更するか、または操作のグローバル要素の設定を変更します。たとえば、FTP Connector 設定で再接続戦略を設定できます。 ![接続戦略の設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-reconnection-strategy-ftp.png) 使用できる再接続戦略とそれぞれの動作は次のとおりです。 - **None (なし)** デフォルトの動作です。接続に失敗すると直ちに接続エラーを返します。 - **Standard (標準)**​ (​`reconnect`​) 接続エラーを返すまでの再接続試行回数と再接続を実行する間隔を設定します。 - **Forever (無期限)**​ (​`reconnect-forever`​) 指定された間隔で再接続を継続して試みます。 ## [](#xml-再接続戦略設定の例)XML 再接続戦略設定の例 それぞれの再接続戦略と設定の例を示します。 - Standard 再接続戦略の例 FTP Connector 設定における Standard 再接続戦略の例です。失敗までの再接続試行回数を ​`5`​ に設定し、接続テストが失敗した場合にはアプリケーションのデプロイも失敗するように ​`failsDeployment`​ を ​`true`​ に設定します。頻度が指定されていないため、デフォルトの 2000 ms ごとに接続が再試行されます。 ```xml ``` - Forever 再接続戦略の例 FTP Connector 設定における Forever 再接続戦略の例です。コネクタは、アプリケーションが実行されている限り、4000 ms ごとに接続を再試行します。 ```xml ``` ## [](#再接続戦略リファレンス)再接続戦略リファレンス Mule アプリケーションの XML 設定ファイルを編集することで設定できる再接続戦略ごとの設定属性を以下に示します。 - ``​ の属性
名前 型 必須 デフォルト 説明

failsDeployment

boolean (ブール)

いいえ

false

true​ の場合は、接続テストが失敗するとデプロイも失敗します。
- ``​ の属性
名前 型 必須 デフォルト 説明

blocking

boolean (ブール)

いいえ

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

いいえ

2000

再接続する頻度 (ミリ秒)

count

integer (整数)

いいえ

2

再接続を試みる回数
- ``​ の属性
名前 型 必須 デフォルト 説明

blocking

boolean (ブール)

いいえ

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

いいえ

2000

再接続する頻度 (ミリ秒) を指定します。
## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-components) - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) - [グローバル要素の設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/global-elements) # 再接続戦略 Mule アプリケーション内の操作が外部サーバーへの接続に失敗すると、デフォルト動作ではその操作は直ちに失敗し、接続エラーが返されます。 たとえば、FTP 用 Anypoint Connector (FTP Connector) の操作が FTP サーバーへの接続に失敗すると、操作は ​`FTP:CONNECTIVITY`​ エラーをスローします。エラー名には、​`FTP:CONNECTIVITY`​ や ​`DB:CONNECTIVITY`​ (データベース用 Anypoint Connector (Database Connector) の場合) など、コネクタ固有の名前空間が反映されます。 このデフォルト動作を変更するには、操作の再接続戦略を設定します。
操作を実行しても、接続エラーで失敗すると、FTP Connector で設定された再接続戦略はトリガーされません。この例では、新規または更新されたファイルを照会する FTP サーバーで ​ftp:listener​ を確立する必要がある接続にのみ再接続戦略が適用されます。
## [](#操作の再接続戦略の設定)操作の再接続戦略の設定 操作の再接続戦略を設定するには、操作のプロパティを変更するか、または操作のグローバル要素の設定を変更します。たとえば、FTP Connector 設定で再接続戦略を設定できます。 ![接続戦略の設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-reconnection-strategy-ftp.png) 使用できる再接続戦略とそれぞれの動作は次のとおりです。 - **None (なし)** デフォルトの動作です。接続に失敗すると直ちに接続エラーを返します。 - **Standard (標準)**​ (​`reconnect`​) 接続エラーを返すまでの再接続試行回数と再接続を実行する間隔を設定します。 - **Forever (無期限)**​ (​`reconnect-forever`​) 指定された間隔で再接続を継続して試みます。 ## [](#xml-再接続戦略設定の例)XML 再接続戦略設定の例 それぞれの再接続戦略と設定の例を示します。 - Standard 再接続戦略の例 FTP Connector 設定における Standard 再接続戦略の例です。失敗までの再接続試行回数を ​`5`​ に設定し、接続テストが失敗した場合にはアプリケーションのデプロイも失敗するように ​`failsDeployment`​ を ​`true`​ に設定します。頻度が指定されていないため、デフォルトの 2000 ms ごとに接続が再試行されます。 ```xml ``` - Forever 再接続戦略の例 FTP Connector 設定における Forever 再接続戦略の例です。コネクタは、アプリケーションが実行されている限り、4000 ms ごとに接続を再試行します。 ```xml ``` ## [](#再接続戦略リファレンス)再接続戦略リファレンス Mule アプリケーションの XML 設定ファイルを編集することで設定できる再接続戦略ごとの設定属性を以下に示します。 - ``​ の属性
名前 型 必須 デフォルト 説明

failsDeployment

boolean (ブール)

no (いいえ)

false

true​ の場合は、接続テストが失敗するとデプロイも失敗します。
- ``​ の属性
名前 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒)

count

integer (整数)

no (いいえ)

2

再接続を試みる回数
- ``​ の属性
名前 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒) を指定します。
## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-components) - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) - [グローバル要素の設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/global-elements) # 再接続戦略 Mule アプリケーション内の操作が外部サーバーへの接続に失敗すると、デフォルト動作ではその操作は直ちに失敗し、接続エラーが返されます。 たとえば、FTP 用 Anypoint Connector (FTP Connector) の操作が FTP サーバーへの接続に失敗すると、操作は ​`FTP:CONNECTIVITY`​ エラーをスローします。エラー名には、​`FTP:CONNECTIVITY`​ や ​`DB:CONNECTIVITY`​ (データベース用 Anypoint Connector (Database Connector) の場合) など、コネクタ固有の名前空間が反映されます。 このデフォルト動作を変更するには、操作の再接続戦略を設定します。
操作を実行しても、接続エラーで失敗すると、FTP Connector で設定された再接続戦略はトリガーされません。この例では、新規または更新されたファイルを照会する FTP サーバーで ​ftp:listener​ を確立する必要がある接続にのみ再接続戦略が適用されます。
## [](#操作の再接続戦略の設定)操作の再接続戦略の設定 操作の再接続戦略を設定するには、操作のプロパティを変更するか、または操作のグローバル要素の設定を変更します。たとえば、FTP Connector 設定で再接続戦略を設定できます。 ![接続戦略の設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-reconnection-strategy-ftp.png) 使用できる再接続戦略とそれぞれの動作は次のとおりです。 - **None (なし)** デフォルトの動作です。接続に失敗すると直ちに接続エラーを返します。 - **Standard (標準)**​ (​`reconnect`​) 接続エラーを返すまでの再接続試行回数と再接続を実行する間隔を設定します。 - **Forever (無期限)**​ (​`reconnect-forever`​) 指定された間隔で再接続を継続して試みます。 ## [](#xml-再接続戦略設定の例)XML 再接続戦略設定の例 それぞれの再接続戦略と設定の例を示します。 - Standard 再接続戦略の例 FTP Connector 設定における Standard 再接続戦略の例です。失敗までの再接続試行回数を ​`5`​ に設定し、接続テストが失敗した場合にはアプリケーションのデプロイも失敗するように ​`failsDeployment`​ を ​`true`​ に設定します。頻度が指定されていないため、デフォルトの 2000 ms ごとに接続が再試行されます。 ```xml ``` - Forever 再接続戦略の例 FTP Connector 設定における Forever 再接続戦略の例です。コネクタは、アプリケーションが実行されている限り、4000 ms ごとに接続を再試行します。 ```xml ``` ## [](#再接続戦略リファレンス)再接続戦略リファレンス Mule アプリケーションの XML 設定ファイルを編集することで設定できる再接続戦略ごとの設定属性を以下に示します。 - ``​ の属性
名前 型 必須 デフォルト 説明

failsDeployment

boolean (ブール)

no (いいえ)

false

true​ の場合は、接続テストが失敗するとデプロイも失敗します。
- ``​ の属性
名前 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒)

count

integer (整数)

no (いいえ)

2

再接続を試みる回数
- ``​ の属性
名前 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒) を指定します。
## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-components) - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) - [グローバル要素の設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/global-elements) # 再接続戦略 Mule アプリケーション内の操作が外部サーバーへの接続に失敗すると、デフォルト動作ではその操作は直ちに失敗し、接続エラーが返されます。 たとえば、FTP 用 Anypoint Connector (FTP Connector) の操作が FTP サーバーへの接続に失敗すると、操作は ​`FTP:CONNECTIVITY`​ エラーをスローします。エラー名には、​`FTP:CONNECTIVITY`​ や ​`DB:CONNECTIVITY`​ (データベース用 Anypoint Connector (Database Connector) の場合) など、コネクタ固有の名前空間が反映されます。 このデフォルト動作を変更するには、操作の再接続戦略を設定します。
操作を実行しても、接続エラーで失敗すると、FTP Connector で設定された再接続戦略はトリガーされません。この例では、新規または更新されたファイルを照会する FTP サーバーで ​ftp:listener​ を確立する必要がある接続にのみ再接続戦略が適用されます。
## [](#操作の再接続戦略の設定)操作の再接続戦略の設定 操作の再接続戦略を設定するには、操作のプロパティを変更するか、または操作のグローバル要素の設定を変更します。たとえば、FTP Connector 設定で再接続戦略を設定できます。 ![再接続戦略が表示されている FTP 設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-reconnection-strategy-ftp.png) 使用できる再接続戦略とそれぞれの動作は次のとおりです。 - **None (なし)** デフォルトの動作です。接続に失敗すると直ちに接続エラーを返します。 - **Standard (標準)**​ (​`reconnect`​) 接続エラーを返すまでの再接続試行回数と再接続を実行する間隔を設定します。 - **Forever (無期限)**​ (​`reconnect-forever`​) 指定された間隔で再接続を継続して試みます。 ## [](#xml-再接続戦略設定の例)XML 再接続戦略設定の例 それぞれの再接続戦略と設定の例を示します。 - Standard 再接続戦略の例 FTP Connector 設定における Standard 再接続戦略の例です。失敗までの再接続試行回数を ​`5`​ に設定し、接続テストが失敗した場合にはアプリケーションのデプロイも失敗するように ​`failsDeployment`​ を ​`true`​ に設定します。頻度が指定されていないため、デフォルトの 2000 ms ごとに接続が再試行されます。 ```xml ``` - Forever 再接続戦略の例 FTP Connector 設定における Forever 再接続戦略の例です。コネクタは、アプリケーションが実行されている限り、4000 ms ごとに接続を再試行します。 ```xml ``` ## [](#再接続戦略リファレンス)再接続戦略リファレンス Mule アプリケーションの XML 設定ファイルを編集することで設定できる再接続戦略ごとの設定属性を以下に示します。 - ``​ の属性
名前 型 必須 デフォルト 説明

failsDeployment

boolean (ブール)

no (いいえ)

false

true​ の場合は、接続テストが失敗するとデプロイも失敗します。
- ``​ の属性
名前 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒)

count

integer (整数)

no (いいえ)

2

再接続を試みる回数
- ``​ の属性
名前 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒) を指定します。
## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-components) - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) - [グローバル要素の設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/global-elements) # 再接続戦略 Mule アプリケーション内の操作が外部サーバーへの接続に失敗すると、デフォルト動作ではその操作は直ちに失敗し、接続エラーが返されます。 たとえば、FTP 用 Anypoint Connector (FTP Connector) の操作が FTP サーバーへの接続に失敗すると、操作は ​`FTP:CONNECTIVITY`​ エラーをスローします。エラー名には、​`FTP:CONNECTIVITY`​ や ​`DB:CONNECTIVITY`​ (データベース用 Anypoint Connector (Database Connector) の場合) など、コネクタ固有の名前空間が反映されます。 このデフォルト動作を変更するには、操作の再接続戦略を設定します。
操作を実行しても、接続エラーで失敗すると、FTP Connector で設定された再接続戦略はトリガーされません。この例では、新規または更新されたファイルを照会する FTP サーバーで ​ftp:listener​ を確立する必要がある接続にのみ再接続戦略が適用されます。
## [](#操作の再接続戦略の設定)操作の再接続戦略の設定 操作の再接続戦略を設定するには、操作のプロパティを変更するか、または操作のグローバル要素の設定を変更します。たとえば、FTP Connector 設定で再接続戦略を設定できます。 ![再接続戦略が表示されている FTP 設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-reconnection-strategy-ftp.png) 使用できる再接続戦略とそれぞれの動作は次のとおりです。 - **None (なし)** デフォルトの動作です。接続に失敗すると直ちに接続エラーを返します。 - **Standard (標準)**​ (​`reconnect`​) 接続エラーを返すまでの再接続試行回数と再接続を実行する間隔を設定します。 - **Forever (無期限)**​ (​`reconnect-forever`​) 指定された間隔で再接続を継続して試みます。 ## [](#xml-再接続戦略設定の例)XML 再接続戦略設定の例 それぞれの再接続戦略と設定の例を示します。 - Standard 再接続戦略の例 FTP Connector 設定における Standard 再接続戦略の例です。失敗までの再接続試行回数を ​`5`​ に設定し、接続テストが失敗した場合にはアプリケーションのデプロイも失敗するように ​`failsDeployment`​ を ​`true`​ に設定します。頻度が指定されていないため、デフォルトの 2000 ms ごとに接続が再試行されます。 ```xml ``` - Forever 再接続戦略の例 FTP Connector 設定における Forever 再接続戦略の例です。コネクタは、アプリケーションが実行されている限り、4000 ms ごとに接続を再試行します。 ```xml ``` ## [](#再接続戦略リファレンス)再接続戦略リファレンス Mule アプリケーションの XML 設定ファイルを編集することで設定できる再接続戦略ごとの設定属性を以下に示します。 - ``​ の属性
名前 型 必須 デフォルト 説明

failsDeployment

boolean (ブール)

no (いいえ)

false

true​ の場合は、接続テストが失敗するとデプロイも失敗します。
- ``​ の属性
名前 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒)

count

integer (整数)

no (いいえ)

2

再接続を試みる回数
- ``​ の属性
名前 型 必須 デフォルト 説明

blocking

boolean (ブール)

no (いいえ)

true

false​ の場合は、再接続戦略が個別の非ブロックスレッドで実行されます。

frequency

long (ロング)

no (いいえ)

2000

再接続する頻度 (ミリ秒) を指定します。
## [](#関連情報)関連情報 - [コアコンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-components) - [コネクタおよびモジュール](https://docs.mulesoft.com/connectors/) - [グローバル要素の設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/global-elements) # 再接続戦略の移行 構文の観点から見れば、再接続は Mule 3 から Mule 4 ではそれほど変更されていません。ただし、動作には大きな違いがあります。 Mule 3 では、再接続戦略は各コンポーネントの config 要素で指定されていました。これらの戦略には 2 つの目的があります。 - 実行中のアプリケーションがエンドポイントとの接続を失った場合に再接続する。 - アプリケーションがデプロイされているときにすべての接続を検証する。 Mysql データベースに接続するアプリケーションがあるとします。デプロイメント時にその接続を確立できなければ、デプロイメントが失敗します。これは、デプロイされるすべてのアプリケーションが機能する状態であることを保証するための設定でした。 Mule 3 の例: 再接続設定 (MySQL データベース用) ```xml ` ` ``` ただし、接続が失敗した場合に、デプロイメントを失敗にしたくないユースケースがあります。たとえば、アプリケーションに、1 日 1 回だけ午前 3 時に外部 SFTP サーバーに到達するフローがあるとします。このアプリケーションが午前 8 時にデプロイされていて、SFTP サーバーがダウンした場合、デプロイメントを失敗にする理由がありません。実際に必要なときにサーバーが稼働していることを確認する時間はたっぷりあります。 Mule 3 でこれを実行するには、​`blocking="false"`​ オプションを使用して、再接続を非同期で行い、デプロイメントが中止されないようにする必要がありました。 Mule 3 の例: 非同期再接続設定 (MySQL データベース用) ```xml ` ``` Mule 4 では単純に、接続テストが失敗した場合にデプロイメントが失敗するかどうかを指定できます。 Mule 4 の例: 再接続設定 (SQL データベース用) ```xml ``` デフォルトでは、接続を確立できないとログに警告が生成されるだけです。 ## [](#操作レベル再接続戦略)操作レベル再接続戦略 Mule 3 では、同じ再接続戦略が config 要素で、デプロイメント時と実行時の両方に使用されました。たとえば、フローを実行しているデータベースとの接続が失われると、同じ再接続戦略が使用されます。 Mule 4 では、この動作がデフォルトになりますが、操作またはメッセージソースレベルで別の戦略を指定することもできます。 Mule 4 の例: 再接続設定 (HTTP 要求用) ```xml #[{'my': 'map'}] #[{{'content-type' : 'text/plain'}}] ``` ## [](#関連情報)関連情報 - [コネクタの移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-connectors) # 再接続戦略の移行 構文の観点から見れば、再接続は Mule 3 から Mule 4 ではそれほど変更されていません。ただし、動作には大きな違いがあります。 Mule 3 では、再接続戦略は各コンポーネントの config 要素で指定されていました。これらの戦略には 2 つの目的があります。 - 実行中のアプリケーションがエンドポイントとの接続を失った場合に再接続する。 - アプリケーションがデプロイされているときにすべての接続を検証する。 Mysql データベースに接続するアプリケーションがあるとします。デプロイメント時にその接続を確立できなければ、デプロイメントが失敗します。これは、デプロイされるすべてのアプリケーションが機能する状態であることを保証するための設定でした。 Mule 3 の例: 再接続設定 (MySQL データベース用) ```xml ` ` ``` ただし、接続が失敗した場合に、デプロイメントを失敗にしたくないユースケースがあります。たとえば、アプリケーションに、1 日 1 回だけ午前 3 時に外部 SFTP サーバーに到達するフローがあるとします。このアプリケーションが午前 8 時にデプロイされていて、SFTP サーバーがダウンした場合、デプロイメントを失敗にする理由がありません。実際に必要なときにサーバーが稼働していることを確認する時間はたっぷりあります。 Mule 3 でこれを実行するには、​`blocking="false"`​ オプションを使用して、再接続を非同期で行い、デプロイメントが中止されないようにする必要がありました。 Mule 3 の例: 非同期再接続設定 (MySQL データベース用) ```xml ` ``` Mule 4 では単純に、接続テストが失敗した場合にデプロイメントが失敗するかどうかを指定できます。 Mule 4 の例: 再接続設定 (SQL データベース用) ```xml ``` デフォルトでは、接続を確立できないとログに警告が生成されるだけです。 ## [](#操作レベル再接続戦略)操作レベル再接続戦略 Mule 3 では、同じ再接続戦略が config 要素で、デプロイメント時と実行時の両方に使用されました。たとえば、フローを実行しているデータベースとの接続が失われると、同じ再接続戦略が使用されます。 Mule 4 では、この動作がデフォルトになりますが、操作またはイベントソースレベルで別の戦略を指定することもできます。 Mule 4 の例: 再接続設定 (HTTP 要求用) ```xml #[{'my': 'map'}] #[{{'content-type' : 'text/plain'}}] ``` ## [](#関連情報)関連情報 - [コネクタの移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-connectors) # 再接続戦略の移行 構文の観点から見れば、再接続は Mule 3 から Mule 4 ではそれほど変更されていません。ただし、動作には大きな違いがあります。 Mule 3 では、再接続戦略は各コンポーネントの config 要素で指定されていました。これらの戦略には 2 つの目的があります。 - 実行中のアプリケーションがエンドポイントとの接続を失った場合に再接続する。 - アプリケーションがデプロイされているときにすべての接続を検証する。 Mysql データベースに接続するアプリケーションがあるとします。デプロイメント時にその接続を確立できなければ、デプロイメントが失敗します。これは、デプロイされるすべてのアプリケーションが機能する状態であることを保証するための設定でした。 Mule 3 の例: 再接続設定 (MySQL データベース用) ```xml ` ` ``` ただし、接続が失敗した場合に、デプロイメントを失敗にしたくないユースケースがあります。たとえば、アプリケーションに、1 日 1 回だけ午前 3 時に外部 SFTP サーバーに到達するフローがあるとします。このアプリケーションが午前 8 時にデプロイされていて、SFTP サーバーがダウンした場合、デプロイメントを失敗にする理由がありません。実際に必要なときにサーバーが稼働していることを確認する時間はたっぷりあります。 Mule 3 でこれを実行するには、​`blocking="false"`​ オプションを使用して、再接続を非同期で行い、デプロイメントが中止されないようにする必要がありました。 Mule 3 の例: 非同期再接続設定 (MySQL データベース用) ```xml ` ``` Mule 4 では単純に、接続テストが失敗した場合にデプロイメントが失敗するかどうかを指定できます。 Mule 4 の例: 再接続設定 (SQL データベース用) ```xml ``` デフォルトでは、接続を確立できないとログに警告が生成されるだけです。 ## [](#操作レベル再接続戦略)操作レベル再接続戦略 Mule 3 では、同じ再接続戦略が config 要素で、デプロイメント時と実行時の両方に使用されました。たとえば、フローを実行しているデータベースとの接続が失われると、同じ再接続戦略が使用されます。 Mule 4 では、この動作がデフォルトになりますが、操作またはイベントソースレベルで別の戦略を指定することもできます。 Mule 4 の例: 再接続設定 (HTTP 要求用) ```xml #[{'my': 'map'}] #[{{'content-type' : 'text/plain'}}] ``` ## [](#関連情報)関連情報 - [コネクタの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-connectors) # 再接続戦略の移行 構文の観点から見れば、再接続は Mule 3 から Mule 4 ではそれほど変更されていません。ただし、動作には大きな違いがあります。 Mule 3 では、再接続戦略は各コンポーネントの config 要素で指定されていました。これらの戦略には 2 つの目的があります。 - 実行中のアプリケーションがエンドポイントとの接続を失った場合に再接続する。 - アプリケーションがデプロイされているときにすべての接続を検証する。 Mysql データベースに接続するアプリケーションがあるとします。デプロイメント時にその接続を確立できなければ、デプロイメントが失敗します。これは、デプロイされるすべてのアプリケーションが機能する状態であることを保証するための設定でした。 Mule 3 の例: 再接続設定 (MySQL データベース用) ```xml ` ` ``` ただし、接続が失敗した場合に、デプロイメントを失敗にしたくないユースケースがあります。たとえば、アプリケーションに、1 日 1 回だけ午前 3 時に外部 SFTP サーバーに到達するフローがあるとします。このアプリケーションが午前 8 時にデプロイされていて、SFTP サーバーがダウンした場合、デプロイメントを失敗にする理由がありません。実際に必要なときにサーバーが稼働していることを確認する時間はたっぷりあります。 Mule 3 でこれを実行するには、​`blocking="false"`​ オプションを使用して、再接続を非同期で行い、デプロイメントが中止されないようにする必要がありました。 Mule 3 の例: 非同期再接続設定 (MySQL データベース用) ```xml ` ``` Mule 4 では単純に、接続テストが失敗した場合にデプロイメントが失敗するかどうかを指定できます。 Mule 4 の例: 再接続設定 (SQL データベース用) ```xml ``` デフォルトでは、接続を確立できないとログに警告が生成されるだけです。 ## [](#操作レベル再接続戦略)操作レベル再接続戦略 Mule 3 では、同じ再接続戦略が config 要素で、デプロイメント時と実行時の両方に使用されました。たとえば、フローを実行しているデータベースとの接続が失われると、同じ再接続戦略が使用されます。 Mule 4 では、この動作がデフォルトになりますが、操作またはイベントソースレベルで別の戦略を指定することもできます。 Mule 4 の例: 再接続設定 (HTTP 要求用) ```xml #[{'my': 'map'}] #[{{'content-type' : 'text/plain'}}] ``` ## [](#関連情報)関連情報 - [コネクタの移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-connectors) # 再接続戦略の移行 構文の観点から見れば、再接続は Mule 3 から Mule 4 ではそれほど変更されていません。ただし、動作には大きな違いがあります。 Mule 3 では、再接続戦略は各コンポーネントの config 要素で指定されていました。これらの戦略には 2 つの目的があります。 - 実行中のアプリケーションがエンドポイントとの接続を失った場合に再接続する。 - アプリケーションがデプロイされているときにすべての接続を検証する。 Mysql データベースに接続するアプリケーションがあるとします。デプロイメント時にその接続を確立できなければ、デプロイメントが失敗します。これは、デプロイされるすべてのアプリケーションが機能する状態であることを保証するための設定でした。 Mule 3 の例: 再接続設定 (MySQL データベース用) ```xml ` ` ``` ただし、接続が失敗した場合に、デプロイメントを失敗にしたくないユースケースがあります。たとえば、アプリケーションに、1 日 1 回だけ午前 3 時に外部 SFTP サーバーに到達するフローがあるとします。このアプリケーションが午前 8 時にデプロイされていて、SFTP サーバーがダウンした場合、デプロイメントを失敗にする理由がありません。実際に必要なときにサーバーが稼働していることを確認する時間はたっぷりあります。 Mule 3 でこれを実行するには、​`blocking="false"`​ オプションを使用して、再接続を非同期で行い、デプロイメントが中止されないようにする必要がありました。 Mule 3 の例: 非同期再接続設定 (MySQL データベース用) ```xml ` ``` Mule 4 では単純に、接続テストが失敗した場合にデプロイメントが失敗するかどうかを指定できます。 Mule 4 の例: 再接続設定 (SQL データベース用) ```xml ``` デフォルトでは、接続を確立できないとログに警告が生成されるだけです。 ## [](#操作レベル再接続戦略)操作レベル再接続戦略 Mule 3 では、同じ再接続戦略が config 要素で、デプロイメント時と実行時の両方に使用されました。たとえば、フローを実行しているデータベースとの接続が失われると、同じ再接続戦略が使用されます。 Mule 4 では、この動作がデフォルトになりますが、操作またはイベントソースレベルで別の戦略を指定することもできます。 Mule 4 の例: 再接続設定 (HTTP 要求用) ```xml #[{'my': 'map'}] #[{{'content-type' : 'text/plain'}}] ``` ## [](#関連情報)関連情報 - [コネクタの移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-connectors) # 再接続戦略の移行 構文の観点から見れば、再接続は Mule 3 から Mule 4 ではそれほど変更されていません。ただし、動作には大きな違いがあります。 Mule 3 では、再接続戦略は各コンポーネントの config 要素で指定されていました。これらの戦略には 2 つの目的があります。 - 実行中のアプリケーションがエンドポイントとの接続を失った場合に再接続する。 - アプリケーションがデプロイされているときにすべての接続を検証する。 Mysql データベースに接続するアプリケーションがあるとします。デプロイメント時にその接続を確立できなければ、デプロイメントが失敗します。これは、デプロイされるすべてのアプリケーションが機能する状態であることを保証するための設定でした。 Mule 3 の例: 再接続設定 (MySQL データベース用) ```xml ` ` ``` ただし、接続が失敗した場合に、デプロイメントを失敗にしたくないユースケースがあります。たとえば、アプリケーションに、1 日 1 回だけ午前 3 時に外部 SFTP サーバーに到達するフローがあるとします。このアプリケーションが午前 8 時にデプロイされていて、SFTP サーバーがダウンした場合、デプロイメントを失敗にする理由がありません。実際に必要なときにサーバーが稼働していることを確認する時間はたっぷりあります。 Mule 3 でこれを実行するには、​`blocking="false"`​ オプションを使用して、再接続を非同期で行い、デプロイメントが中止されないようにする必要がありました。 Mule 3 の例: 非同期再接続設定 (MySQL データベース用) ```xml ` ``` Mule 4 では単純に、接続テストが失敗した場合にデプロイメントが失敗するかどうかを指定できます。 Mule 4 の例: 再接続設定 (SQL データベース用) ```xml ``` デフォルトでは、接続を確立できないとログに警告が生成されるだけです。 ## [](#操作レベル再接続戦略)操作レベル再接続戦略 Mule 3 では、同じ再接続戦略が config 要素で、デプロイメント時と実行時の両方に使用されました。たとえば、フローを実行しているデータベースとの接続が失われると、同じ再接続戦略が使用されます。 Mule 4 では、この動作がデフォルトになりますが、操作またはイベントソースレベルで別の戦略を指定することもできます。 Mule 4 の例: 再接続設定 (HTTP 要求用) ```xml #[{'my': 'map'}] #[{{'content-type' : 'text/plain'}}] ``` ## [](#関連情報)関連情報 - [コネクタの移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-connectors) # 再接続戦略の移行 構文の観点から見れば、再接続は Mule 3 から Mule 4 ではそれほど変更されていません。ただし、動作には大きな違いがあります。 Mule 3 では、再接続戦略は各コンポーネントの config 要素で指定されていました。これらの戦略には 2 つの目的があります。 - 実行中のアプリケーションがエンドポイントとの接続を失った場合に再接続する。 - アプリケーションがデプロイされているときにすべての接続を検証する。 Mysql データベースに接続するアプリケーションがあるとします。デプロイメント時にその接続を確立できなければ、デプロイメントが失敗します。これは、デプロイされるすべてのアプリケーションが機能する状態であることを保証するための設定でした。 Mule 3 の例: 再接続設定 (MySQL データベース用) ```xml ` ` ``` ただし、接続が失敗した場合に、デプロイメントを失敗にしたくないユースケースがあります。たとえば、アプリケーションに、1 日 1 回だけ午前 3 時に外部 SFTP サーバーに到達するフローがあるとします。このアプリケーションが午前 8 時にデプロイされていて、SFTP サーバーがダウンした場合、デプロイメントを失敗にする理由がありません。実際に必要なときにサーバーが稼働していることを確認する時間はたっぷりあります。 Mule 3 でこれを実行するには、​`blocking="false"`​ オプションを使用して、再接続を非同期で行い、デプロイメントが中止されないようにする必要がありました。 Mule 3 の例: 非同期再接続設定 (MySQL データベース用) ```xml ` ``` Mule 4 では単純に、接続テストが失敗した場合にデプロイメントが失敗するかどうかを指定できます。 Mule 4 の例: 再接続設定 (SQL データベース用) ```xml ``` デフォルトでは、接続を確立できないとログに警告が生成されるだけです。 ## [](#操作レベル再接続戦略)操作レベル再接続戦略 Mule 3 では、同じ再接続戦略が config 要素で、デプロイメント時と実行時の両方に使用されました。たとえば、フローを実行しているデータベースとの接続が失われると、同じ再接続戦略が使用されます。 Mule 4 では、この動作がデフォルトになりますが、操作またはイベントソースレベルで別の戦略を指定することもできます。 Mule 4 の例: 再接続設定 (HTTP 要求用) ```xml #[{'my': 'map'}] #[{{'content-type' : 'text/plain'}}] ``` ## [](#関連情報)関連情報 - [コネクタの移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-connectors) # 再現可能なビルド 本番環境のプロジェクトが常に最新とは限らないため、いつでも特定のバージョンの Mule プロジェクトをビルドできると、メンテナンスが容易になります。 この目標を達成するには、次の手順を実行します。 - すべての Mule プロジェクトのソース制御を使用し、分岐、マージ、タギングをプロジェクトに適用します。 Eclipse 固有のファイルではチェックしないでください。 詳細は、 [Git Source Control](https://git-scm.com/book/en/v2)​ のドキュメントを参照してください。 - Apache Maven と、Nexus などの社内リポジトリマネージャーを使用して連動関係を厳密に管理します。 ガイドラインについては、​[「Mule での Maven のサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.3/using-maven-with-mule)​ドキュメントを参照してください。 # 再現可能なビルド 本番環境のプロジェクトが常に最新とは限らないため、いつでも特定のバージョンの Mule プロジェクトをビルドできると、メンテナンスが容易になります。 この目標を達成するには、次の手順を実行します。 - すべての Mule プロジェクトのソース制御を使用し、分岐、マージ、タギングをプロジェクトに適用します。 Eclipse 固有のファイルではチェックしないでください。 詳細は、 [Git Source Control](https://git-scm.com/book/en/v2)​ のドキュメントを参照してください。 - Apache Maven と、Nexus などの社内リポジトリマネージャーを使用して連動関係を厳密に管理します。 ガイドラインについては、​[「Mule での Maven のサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.4/using-maven-with-mule)​ドキュメントを参照してください。 # 再現可能なビルド 本番環境のプロジェクトが常に最新とは限らないため、いつでも特定のバージョンの Mule プロジェクトをビルドできると、メンテナンスが容易になります。 この目標を達成するには、次の手順を実行します。 - すべての Mule プロジェクトのソース制御を使用し、分岐、マージ、タギングをプロジェクトに適用します。 Eclipse 固有のファイルではチェックしないでください。 詳細は、 [Git Source Control](https://git-scm.com/book/en/v2)​ のドキュメントを参照してください。 - Apache Maven と、Nexus などの社内リポジトリマネージャーを使用して連動関係を厳密に管理します。 ガイドラインについては、​[「Mule での Maven のサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.5/using-maven-with-mule)​ドキュメントを参照してください。 # 再現可能なビルド 本番環境のプロジェクトが常に最新とは限らないため、いつでも特定のバージョンの Mule プロジェクトをビルドできると、メンテナンスが容易になります。 この目標を達成するには、次の手順を実行します。 - すべての Mule プロジェクトのソース制御を使用し、分岐、マージ、タギングをプロジェクトに適用します。 Eclipse 固有のファイルではチェックしないでください。 詳細は、 [Git Source Control](https://git-scm.com/book/en/v2)​ のドキュメントを参照してください。 - Apache Maven と、Nexus などの社内リポジトリマネージャーを使用して連動関係を厳密に管理します。 ガイドラインについては、​[「Mule での Maven のサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.6/using-maven-with-mule)​ドキュメントを参照してください。 # 再現可能なビルド 本番環境のプロジェクトが常に最新とは限らないため、いつでも特定のバージョンの Mule プロジェクトをビルドできると、メンテナンスが容易になります。 この目標を達成するには、次の手順を実行します。 - すべての Mule プロジェクトのソース制御を使用し、分岐、マージ、タギングをプロジェクトに適用します。 Eclipse 固有のファイルではチェックしないでください。 詳細は、 [Git Source Control](https://git-scm.com/book/en/v2)​ のドキュメントを参照してください。 - Apache Maven と、Nexus などの社内リポジトリマネージャーを使用して連動関係を厳密に管理します。 ガイドラインについては、​[「Mule での Maven のサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.7/using-maven-with-mule)​ドキュメントを参照してください。 # 再現可能なビルド 本番環境のプロジェクトが常に最新とは限らないため、いつでも特定のバージョンの Mule プロジェクトをビルドできると、メンテナンスが容易になります。 この目標を達成するには、次の手順を実行します。 - すべての Mule プロジェクトのソース制御を使用し、分岐、マージ、タギングをプロジェクトに適用します。 Eclipse 固有のファイルではチェックしないでください。 詳細は、 [Git Source Control](https://git-scm.com/book/en/v2)​ のドキュメントを参照してください。 - Apache Maven と、Nexus などの社内リポジトリマネージャーを使用して連動関係を厳密に管理します。 ガイドラインについては、​[「Mule での Maven のサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.8/using-maven-with-mule)​ドキュメントを参照してください。 # 再現可能なビルド 本番環境のプロジェクトが常に最新とは限らないため、いつでも特定のバージョンの Mule プロジェクトをビルドできると、メンテナンスが容易になります。 この目標を達成するには、次の手順を実行します。 - すべての Mule プロジェクトのソース制御を使用し、分岐、マージ、タギングをプロジェクトに適用します。 Eclipse 固有のファイルではチェックしないでください。 詳細は、 [Git Source Control](https://git-scm.com/book/en/v2)​ のドキュメントを参照してください。 - Apache Maven と、Nexus などの社内リポジトリマネージャーを使用して連動関係を厳密に管理します。 ガイドラインについては、​[「Mule での Maven のサポート」](https://docs.mulesoft.com/jp/mule-runtime/4.9/using-maven-with-mule)​ドキュメントを参照してください。 # 再配信ポリシーの設定 再配信ポリシーとは、エラーを発生するメッセージを Mule Runtime Engine (Mule) で実行する回数を制限することでリソースを節約するのに役立つ検索条件です。再配信ポリシーは、フロー内の任意のソースに追加できます。 再配信ポリシーをフローのソースに追加すると、Mule によってフローのコンポーネントが実行される前に受信データが評価されます。指定した回数メッセージ配信に失敗すると、再配信ポリシーによってフローで受信データの処理が防止され、​REDELIVERY\_EXHAUSTED​ エラーが生成されます。 ## [](#再配信ポリシーの設定パラメーター)再配信ポリシーの設定パラメーター
項目 型 デフォルト値 説明

Max Redelivery Count (最大再配信数)

Number (数値)

5

MULE:REDELIVERY_EXHAUSTED​ エラーが生成される前に、失敗してもメッセージをフローに再配信して処理できる最大回数。

Use Secure Hash (セキュアハッシュを使用)

Boolean (ブール)

True

再配信されたメッセージの識別にセキュアハッシュアルゴリズムを使用するかどうかを示します。

Message Digest Algorithm (メッセージダイジェストアルゴリズム)

String (文字列)

SHA-256

メッセージに使用するセキュアハッシュアルゴリズム。メッセージのペイロードが Java オブジェクトの場合、Mule では ​[Message Digest Algorithm (メッセージダイジェストアルゴリズム)]​ 値が無視され、ペイロードの ​hashCode()​ が返した値を返します。

ID Expression (ID の式)

Expression (式)

-

メッセージがいつ再配信されたのかを判断する 1 つ以上の式を定義します。このプロパティは、​[Use Secure Hash (セキュアハッシュを使用)]​ の値が False の場合にのみ設定できます。

Object Store

String (文字列)

Mule のデフォルトの ​ObjectStoreManager​ によって作成される Object Store。永続的ではなく、​entryTtl​ は 300 秒、​expirationInterval​ は 6 秒です。

各メッセージの再配信カウンターが保存される Object Store。Object Store は参照または内部要素として設定できます。

詳細は、​「Object Store Connector ドキュメント」​を参照してください。
## [](#再配信ポリシーのしくみ)再配信ポリシーのしくみ ソースが新しいメッセージを受信するたびに、Mule はそのキーを生成してメッセージを識別します。 - 処理フローで例外が発生すると、Mule は、メッセージキーに関連付けられているカウンターを増分します。カウンター値が、設定されている ​**maxRedeliveryCount**​ の値を超えると、Mule で MULE:REDELIVERY\_EXHAUSTED​ エラーがスローされます。 - 処理フローで例外が発生しなければ、カウンターがリセットされます。 ## [](#エラー)エラー - MULE:REDELIVERY\_EXHAUSTED エラーが発生した実行回数が設定されている ​**maxRedeliveryCount**​ 値より大きい場合にスローされます。 ## [](#例)例 次の例では、​**maxRedeliveryCount**​ である 2 を超えた場合に Mule で ​`Redelivery exhausted in http listener`​ メッセージが含まれるエラーが記録されます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule の概要](https://docs.mulesoft.com/jp/mule-runtime/4.3/) - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.3/flow-component) # 再配信ポリシーの設定 再配信ポリシーとは、エラーを発生するメッセージを Mule Runtime Engine (Mule) で実行する回数を制限することでリソースを節約するのに役立つ検索条件です。再配信ポリシーは、フロー内のあらゆる提供元に追加できます。 再配信ポリシーをフローの提供元に追加すると、Mule によってフローのコンポーネントが実行される前に受信データが評価されます。指定した回数メッセージ配信に失敗すると、再配信ポリシーによってフローで受信データの処理が防止され、​REDELIVERY\_EXHAUSTED​ エラーが生成されます。 ## [](#再配信ポリシーの設定パラメーター)再配信ポリシーの設定パラメーター
項目 型 デフォルト値 説明

Max Redelivery Count (最大再配信数)

Number (数値)

5

MULE:REDELIVERY_EXHAUSTED​ エラーが生成される前に、失敗してもメッセージをフローに再配信して処理できる最大回数。

Use Secure Hash (セキュアハッシュを使用)

Boolean (ブール)

True

再配信されたメッセージの識別にセキュアハッシュアルゴリズムを使用するかどうかを示します。

Message Digest Algorithm (メッセージダイジェストアルゴリズム)

String (文字列)

SHA-256

メッセージに使用するセキュアハッシュアルゴリズム。メッセージのペイロードが Java オブジェクトの場合、Mule では ​[Message Digest Algorithm (メッセージダイジェストアルゴリズム)]​ 値が無視され、ペイロードの ​hashCode()​ が返した値を返します。

ID Expression (ID の式)

Expression (式)

-

メッセージがいつ再配信されたのかを判断する 1 つ以上の式を定義します。このプロパティは、​[Use Secure Hash (セキュアハッシュを使用)]​ の値が False の場合にのみ設定できます。

Object Store

String (文字列)

Mule のデフォルトの ​ObjectStoreManager​ によって作成される Object Store。永続的ではなく、​entryTtl​ は 300 秒、​expirationInterval​ は 6 秒です。

各メッセージの再配信カウンターが保存される Object Store。Object Store は参照または内部要素として設定できます。

詳細は、​「Object Store Connector ドキュメント」​を参照してください。
## [](#再配信ポリシーのしくみ)再配信ポリシーのしくみ 提供元が新しいメッセージを受信するたびに、Mule はそのキーを生成してメッセージを識別します。 - 処理フローで例外が発生すると、Mule は、メッセージキーに関連付けられているカウンターを増分します。カウンター値が、設定されている ​**maxRedeliveryCount**​ の値を超えると、Mule で MULE:REDELIVERY\_EXHAUSTED​ エラーがスローされます。 - 処理フローで例外が発生しなければ、カウンターがリセットされます。 ## [](#エラー)エラー - MULE:REDELIVERY\_EXHAUSTED エラーが発生した実行回数が設定されている ​**maxRedeliveryCount**​ 値より大きい場合にスローされます。 ## [](#例)例 次の例では、​**maxRedeliveryCount**​ である 2 を超えた場合に Mule で ​`Redelivery exhausted in http listener`​ メッセージが含まれるエラーが記録されます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule の概要](https://docs.mulesoft.com/jp/mule-runtime/4.4/) - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.4/flow-component) # 再配信ポリシーの設定 再配信ポリシーとは、エラーを発生するメッセージを Mule Runtime Engine (Mule) で実行する回数を制限することでリソースを節約するのに役立つ検索条件です。再配信ポリシーは、フロー内のあらゆる提供元に追加できます。 再配信ポリシーをフローのソースに追加すると、Mule によってフローのコンポーネントが実行される前に受信データが評価されます。指定した回数メッセージ配信に失敗すると、再配信ポリシーによってフローで受信データの処理が防止され、​REDELIVERY\_EXHAUSTED​ エラーが生成されます。 ## [](#再配信ポリシーの設定パラメーター)再配信ポリシーの設定パラメーター
項目 型 デフォルト値 説明

Max Redelivery Count (最大再配信数)

Number (数値)

5

MULE:REDELIVERY_EXHAUSTED​ エラーが生成される前に、失敗してもメッセージをフローに再配信して処理できる最大回数。

Use Secure Hash (セキュアハッシュを使用)

Boolean (ブール)

True

再配信されたメッセージの識別にセキュアハッシュアルゴリズムを使用するかどうかを示します。

Message Digest Algorithm (メッセージダイジェストアルゴリズム)

String (文字列)

SHA-256

メッセージに使用するセキュアハッシュアルゴリズム。メッセージのペイロードが Java オブジェクトの場合、Mule では ​[Message Digest Algorithm (メッセージダイジェストアルゴリズム)]​ 値が無視され、ペイロードの ​hashCode()​ が返した値を返します。

ID Expression (ID の式)

Expression (式)

-

メッセージがいつ再配信されたのかを判断する 1 つ以上の式を定義します。このプロパティは、​[Use Secure Hash (セキュアハッシュを使用)]​ の値が False の場合にのみ設定できます。

Object Store

String (文字列)

Mule のデフォルトの ​ObjectStoreManager​ によって作成される Object Store。永続的ではなく、​entryTtl​ は 300 秒、​expirationInterval​ は 6 秒です。

各メッセージの再配信カウンターが保存される Object Store。Object Store は参照または内部要素として設定できます。

詳細は、​「Object Store Connector ドキュメント」​を参照してください。
## [](#再配信ポリシーのしくみ)再配信ポリシーのしくみ 提供元が新しいメッセージを受信するたびに、Mule はそのキーを生成してメッセージを識別します。 - 処理フローで例外が発生すると、Mule は、メッセージキーに関連付けられているカウンターを増分します。カウンター値が、設定されている ​**maxRedeliveryCount**​ の値を超えると、Mule で MULE:REDELIVERY\_EXHAUSTED​ エラーがスローされます。 - 処理フローで例外が発生しなければ、カウンターがリセットされます。 ## [](#エラー)エラー - MULE:REDELIVERY\_EXHAUSTED エラーが発生した実行回数が設定されている ​**maxRedeliveryCount**​ 値より大きい場合にスローされます。 ## [](#例)例 次の例では、​**maxRedeliveryCount**​ である 2 を超えた場合に Mule で ​`Redelivery exhausted in http listener`​ メッセージが含まれるエラーが記録されます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule の概要](https://docs.mulesoft.com/jp/mule-runtime/4.5/) - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.5/flow-component) # 再配信ポリシーの設定 再配信ポリシーとは、エラーを発生するメッセージを Mule Runtime Engine (Mule) で実行する回数を制限することでリソースを節約するのに役立つ検索条件です。再配信ポリシーは、フロー内のあらゆる提供元に追加できます。 再配信ポリシーをフローの提供元に追加すると、Mule によってフローのコンポーネントが実行される前に受信データが評価されます。指定した回数メッセージ配信に失敗すると、再配信ポリシーによってフローで受信データの処理が防止され、​REDELIVERY\_EXHAUSTED​ エラーが生成されます。 ## [](#再配信ポリシーの設定パラメーター)再配信ポリシーの設定パラメーター
項目 型 デフォルト値 説明

Max Redelivery Count (最大再配信数)

Number (数値)

5

MULE:REDELIVERY_EXHAUSTED​ エラーが生成される前に、失敗してもメッセージをフローに再配信して処理できる最大回数。

Use Secure Hash (セキュアハッシュを使用)

Boolean (ブール)

True

再配信されたメッセージの識別にセキュアハッシュアルゴリズムを使用するかどうかを示します。

Message Digest Algorithm (メッセージダイジェストアルゴリズム)

String (文字列)

SHA-256

メッセージに使用するセキュアハッシュアルゴリズム。メッセージのペイロードが Java オブジェクトの場合、Mule では ​[Message Digest Algorithm (メッセージダイジェストアルゴリズム)]​ 値が無視され、ペイロードの ​hashCode()​ が返した値を返します。

ID Expression (ID の式)

Expression (式)

-

メッセージがいつ再配信されたのかを判断する 1 つ以上の式を定義します。このプロパティは、​[Use Secure Hash (セキュアハッシュを使用)]​ の値が False の場合にのみ設定できます。

Object Store

String (文字列)

Mule のデフォルトの ​ObjectStoreManager​ によって作成される Object Store。永続的ではなく、​entryTtl​ は 300 秒、​expirationInterval​ は 6 秒です。

各メッセージの再配信カウンターが保存される Object Store。Object Store は参照または内部要素として設定できます。

詳細は、​「Object Store Connector ドキュメント」​を参照してください。
## [](#再配信ポリシーのしくみ)再配信ポリシーのしくみ 提供元が新しいメッセージを受信するたびに、Mule はそのキーを生成してメッセージを識別します。 - 処理フローで例外が発生すると、Mule は、メッセージキーに関連付けられているカウンターを増分します。カウンター値が、設定されている ​**maxRedeliveryCount**​ の値を超えると、Mule で MULE:REDELIVERY\_EXHAUSTED​ エラーがスローされます。 - 処理フローで例外が発生しなければ、カウンターがリセットされます。 ## [](#エラー)エラー - MULE:REDELIVERY\_EXHAUSTED エラーが発生した実行回数が設定されている ​**maxRedeliveryCount**​ 値より大きい場合にスローされます。 ## [](#例)例 次の例では、​**maxRedeliveryCount**​ である 2 を超えた場合に Mule で ​`Redelivery exhausted in http listener`​ メッセージが含まれるエラーが記録されます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule の概要](https://docs.mulesoft.com/jp/mule-runtime/4.6/) - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.6/flow-component) # 再配信ポリシーの設定 再配信ポリシーとは、エラーを発生するメッセージを Mule Runtime Engine (Mule) で実行する回数を制限することでリソースを節約するのに役立つ検索条件です。再配信ポリシーは、フロー内のあらゆる提供元に追加できます。 再配信ポリシーをフローのソースに追加すると、Mule によってフローのコンポーネントが実行される前に受信データが評価されます。指定した回数メッセージ配信に失敗すると、再配信ポリシーによってフローで受信データの処理が防止され、​REDELIVERY\_EXHAUSTED​ エラーが生成されます。 ## [](#再配信ポリシーの設定パラメーター)再配信ポリシーの設定パラメーター
項目 型 デフォルト値 説明

Max Redelivery Count (最大再配信数)

Number (数値)

5

MULE:REDELIVERY_EXHAUSTED​ エラーが生成される前に、失敗してもメッセージをフローに再配信して処理できる最大回数。

Use Secure Hash (セキュアハッシュを使用)

Boolean (ブール)

True

再配信されたメッセージの識別にセキュアハッシュアルゴリズムを使用するかどうかを示します。

Message Digest Algorithm (メッセージダイジェストアルゴリズム)

String (文字列)

SHA-256

メッセージに使用するセキュアハッシュアルゴリズム。メッセージのペイロードが Java オブジェクトの場合、Mule では ​[Message Digest Algorithm (メッセージダイジェストアルゴリズム)]​ 値が無視され、ペイロードの ​hashCode()​ が返した値を返します。

ID Expression (ID の式)

Expression (式)

-

メッセージがいつ再配信されたのかを判断する 1 つ以上の式を定義します。このプロパティは、​[Use Secure Hash (セキュアハッシュを使用)]​ の値が False の場合にのみ設定できます。

Object Store

String (文字列)

Mule のデフォルトの ​ObjectStoreManager​ によって作成される Object Store。永続的ではなく、​entryTtl​ は 300 秒、​expirationInterval​ は 6 秒です。

各メッセージの再配信カウンターが保存される Object Store。Object Store は参照または内部要素として設定できます。

詳細は、​「Object Store Connector ドキュメント」​を参照してください。
## [](#再配信ポリシーのしくみ)再配信ポリシーのしくみ 提供元が新しいメッセージを受信するたびに、Mule はそのキーを生成してメッセージを識別します。 - 処理フローで例外が発生すると、Mule は、メッセージキーに関連付けられているカウンターを増分します。カウンター値が、設定されている ​**maxRedeliveryCount**​ の値を超えると、Mule で MULE:REDELIVERY\_EXHAUSTED​ エラーがスローされます。 - 処理フローで例外が発生しなければ、カウンターがリセットされます。 ## [](#エラー)エラー - MULE:REDELIVERY\_EXHAUSTED エラーが発生した実行回数が設定されている ​**maxRedeliveryCount**​ 値より大きい場合にスローされます。 ## [](#例)例 次の例では、​**maxRedeliveryCount**​ である 2 を超えた場合に Mule で ​`Redelivery exhausted in http listener`​ メッセージが含まれるエラーが記録されます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule の概要](https://docs.mulesoft.com/jp/mule-runtime/4.7/) - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/flow-component) # 再配信ポリシーの設定 再配信ポリシーとは、エラーを発生するメッセージを Mule Runtime Engine (Mule) で実行する回数を制限することでリソースを節約するのに役立つ検索条件です。再配信ポリシーは、フロー内のあらゆる提供元に追加できます。 再配信ポリシーをフローのソースに追加すると、Mule によってフローのコンポーネントが実行される前に受信データが評価されます。指定した回数メッセージ配信に失敗すると、再配信ポリシーによってフローで受信データの処理が防止され、​REDELIVERY\_EXHAUSTED​ エラーが生成されます。 ## [](#再配信ポリシーの設定パラメーター)再配信ポリシーの設定パラメーター
項目 型 デフォルト値 説明

Max Redelivery Count (最大再配信数)

Number (数値)

5

MULE:REDELIVERY_EXHAUSTED​ エラーが生成される前に、失敗してもメッセージをフローに再配信して処理できる最大回数。

Use Secure Hash (セキュアハッシュを使用)

Boolean (ブール)

True

再配信されたメッセージの識別にセキュアハッシュアルゴリズムを使用するかどうかを示します。

Message Digest Algorithm (メッセージダイジェストアルゴリズム)

String (文字列)

SHA-256

メッセージに使用するセキュアハッシュアルゴリズム。メッセージのペイロードが Java オブジェクトの場合、Mule では ​[Message Digest Algorithm (メッセージダイジェストアルゴリズム)]​ 値が無視され、ペイロードの ​hashCode()​ が返した値を返します。

ID Expression (ID の式)

Expression (式)

-

メッセージがいつ再配信されたのかを判断する 1 つ以上の式を定義します。このプロパティは、​[Use Secure Hash (セキュアハッシュを使用)]​ の値が False の場合にのみ設定できます。

Object Store

String (文字列)

Mule のデフォルトの ​ObjectStoreManager​ によって作成される Object Store。永続的ではなく、​entryTtl​ は 300 秒、​expirationInterval​ は 6 秒です。

各メッセージの再配信カウンターが保存される Object Store。Object Store は参照または内部要素として設定できます。

詳細は、​「Object Store Connector ドキュメント」​を参照してください。
## [](#再配信ポリシーのしくみ)再配信ポリシーのしくみ 提供元が新しいメッセージを受信するたびに、Mule はそのキーを生成してメッセージを識別します。 - 処理フローで例外が発生すると、Mule は、メッセージキーに関連付けられているカウンターを増分します。カウンター値が、設定されている ​**maxRedeliveryCount**​ の値を超えると、Mule で MULE:REDELIVERY\_EXHAUSTED​ エラーがスローされます。 - 処理フローで例外が発生しなければ、カウンターがリセットされます。 ## [](#エラー)エラー - MULE:REDELIVERY\_EXHAUSTED エラーが発生した実行回数が設定されている ​**maxRedeliveryCount**​ 値より大きい場合にスローされます。 ## [](#例)例 次の例では、​**maxRedeliveryCount**​ である 2 を超えた場合に Mule で ​`Redelivery exhausted in http listener`​ メッセージが含まれるエラーが記録されます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule の概要](https://docs.mulesoft.com/jp/mule-runtime/4.8/) - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.8/flow-component) # 再配信ポリシーの設定 再配信ポリシーとは、エラーを発生するメッセージを Mule Runtime Engine (Mule) で実行する回数を制限することでリソースを節約するのに役立つ検索条件です。再配信ポリシーは、フロー内のあらゆる提供元に追加できます。 再配信ポリシーをフローのソースに追加すると、Mule によってフローのコンポーネントが実行される前に受信データが評価されます。指定した回数メッセージ配信に失敗すると、再配信ポリシーによってフローで受信データの処理が防止され、​REDELIVERY\_EXHAUSTED​ エラーが生成されます。 ## [](#再配信ポリシーの設定パラメーター)再配信ポリシーの設定パラメーター
項目 型 デフォルト値 説明

Max Redelivery Count (最大再配信数)

Number (数値)

5

MULE:REDELIVERY_EXHAUSTED​ エラーが生成される前に、失敗してもメッセージをフローに再配信して処理できる最大回数。

Use Secure Hash (セキュアハッシュを使用)

Boolean (ブール)

True

再配信されたメッセージの識別にセキュアハッシュアルゴリズムを使用するかどうかを示します。

Message Digest Algorithm (メッセージダイジェストアルゴリズム)

String (文字列)

SHA-256

メッセージに使用するセキュアハッシュアルゴリズム。メッセージのペイロードが Java オブジェクトの場合、Mule では ​[Message Digest Algorithm (メッセージダイジェストアルゴリズム)]​ 値が無視され、ペイロードの ​hashCode()​ が返した値を返します。

ID Expression (ID の式)

Expression (式)

-

メッセージがいつ再配信されたのかを判断する 1 つ以上の式を定義します。このプロパティは、​[Use Secure Hash (セキュアハッシュを使用)]​ の値が False の場合にのみ設定できます。

Object Store

String (文字列)

Mule のデフォルトの ​ObjectStoreManager​ によって作成される Object Store。永続的ではなく、​entryTtl​ は 300 秒、​expirationInterval​ は 6 秒です。

各メッセージの再配信カウンターが保存される Object Store。Object Store は参照または内部要素として設定できます。

詳細は、​「Object Store Connector ドキュメント」​を参照してください。
## [](#再配信ポリシーのしくみ)再配信ポリシーのしくみ 提供元が新しいメッセージを受信するたびに、Mule はそのキーを生成してメッセージを識別します。 - 処理フローで例外が発生すると、Mule は、メッセージキーに関連付けられているカウンターを増分します。カウンター値が、設定されている ​**maxRedeliveryCount**​ の値を超えると、Mule で MULE:REDELIVERY\_EXHAUSTED​ エラーがスローされます。 - 処理フローで例外が発生しなければ、カウンターがリセットされます。 ## [](#エラー)エラー - MULE:REDELIVERY\_EXHAUSTED エラーが発生した実行回数が設定されている ​**maxRedeliveryCount**​ 値より大きい場合にスローされます。 ## [](#例)例 次の例では、​**maxRedeliveryCount**​ である 2 を超えた場合に Mule で ​`Redelivery exhausted in http listener`​ メッセージが含まれるエラーが記録されます。 ```xml ``` ## [](#関連情報)関連情報 - [Mule の概要](https://docs.mulesoft.com/jp/mule-runtime/4.9/) - [Flow および Subflow スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.9/flow-component) # 冗長ログの有効化 さまざまなモジュールやコネクタに対して冗長ログを有効にできます。アプリケーションのパフォーマンスに大きく影響するため、冗長ログはテストやトラブルシューティングでのみ使用してください。 ## [](#冗長ログの設定)冗長ログの設定 冗長ログを設定するには、​`log4j2.xml`​ ファイルにエントリを追加し、対象とするコネクタやモジュールのパッケージ名を指定して、ログレベルを ​`DEBUG`​ に設定します。 次の例は、Anypoint Connector JMS (JMS Connector) のパッケージ名を探して冗長ログを設定する方法を示しています。 1. **\[Package Explorer\]**​ ビューで、JMS Connector パッケージライブラリを開きます。 2. `.jar`​ ファイル内で Mule 関連パッケージをすべて探します。 ![verbose-logging-package](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-verbose-log-package.png) 3. `log4j2.xml`​ ファイルにエントリを追加し、パッケージ名を指定してログレベルを ​`DEBUG`​ に設定します。 ```xml ... ... ``` ## [](#一般的なコネクタパッケージ名)一般的なコネクタパッケージ名 探す手間を省けるように、一般的ないくつかの Anypoint Connector とそれぞれのパッケージ名を下表に示します。
Connector Name (コネクタ名) Package Names (パッケージ名)

HTTP 用 Anypoint Connector

org.mule.service.http.impl.service.HttpMessageLogger

Salesforce 用 Anypoint Connector

org.mule.extension.salesforce

FTP 用 Anypoint Connector

org.mule.extension.ftp

SFTP 用 Anypoint Connector

  • org.mule.extension.sftp​

  • com.jcraft

FTPS 用 Anypoint Connector

com.mulesoft.extension.ftps

NetSuite 用 Anypoint Connector

  • httpclient.wire.header​

  • httpclient.wire.content​

  • httpclient.wire​

  • org.apache.commons.httpclient​

  • org.apache.http​

  • org.mule.module.netsuite​

  • com.netsuite.webservices​

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.mule.module.netsuite.extension.internal.connection.provider.soap.JavaWSDispatcher

Amazon SQS 用 Anypoint Connector

  • org.mule.extension.sqs​

  • org.apache.http

Microsoft Dynamics 365 用 Anypoint Connector

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.apache.http​

  • org.mule.extension.microsoftdynamics365

MuleSoft SAP 用 Anypoint Connector

org.mule.modules.sap

Anypoint MQ 用 Anypoint Connector

  • com.mulesoft.extension.mq​

  • com.mulesoft.mq

Database 用 Anypoint Connector

org.mule.extension.db

Microsoft SharePoint (バージョン 3.x) 用 Anypoint Connector

  • org.apache.http.wire​

  • org.apache.http
# 冗長ログの有効化 さまざまなモジュールやコネクタに対して冗長ログを有効にできます。アプリケーションのパフォーマンスに大きく影響するため、冗長ログはテストやトラブルシューティングでのみ使用してください。 ## [](#冗長ログの設定)冗長ログの設定 冗長ログを設定するには、​`log4j2.xml`​ ファイルにエントリを追加し、対象とするコネクタやモジュールのパッケージ名を指定して、ログレベルを ​`DEBUG`​ に設定します。 次の例は、Anypoint Connector JMS (JMS Connector) のパッケージ名を探して冗長ログを設定する方法を示しています。 1. **\[Package Explorer\]**​ ビューで、JMS Connector パッケージライブラリを開きます。 2. `.jar`​ ファイル内で Mule 関連パッケージをすべて探します。 ![verbose-logging-package](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-verbose-log-package.png) 3. `log4j2.xml`​ ファイルにエントリを追加し、パッケージ名を指定してログレベルを ​`DEBUG`​ に設定します。 ```xml ... ... ``` ## [](#一般的なコネクタパッケージ名)一般的なコネクタパッケージ名 探す手間を省けるように、一般的ないくつかの Anypoint Connector とそれぞれのパッケージ名を下表に示します。
Connector Name (コネクタ名) Package Names (パッケージ名)

HTTP 用 Anypoint Connector

org.mule.service.http.impl.service.HttpMessageLogger

Salesforce 用 Anypoint Connector

org.mule.extension.salesforce

FTP 用 Anypoint Connector

org.mule.extension.ftp

SFTP 用 Anypoint Connector

  • org.mule.extension.sftp​

  • com.jcraft

FTPS 用 Anypoint Connector

com.mulesoft.extension.ftps

NetSuite 用 Anypoint Connector

  • httpclient.wire.header​

  • httpclient.wire.content​

  • httpclient.wire​

  • org.apache.commons.httpclient​

  • org.apache.http​

  • org.mule.module.netsuite​

  • com.netsuite.webservices​

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.mule.module.netsuite.extension.internal.connection.provider.soap.JavaWSDispatcher

Amazon SQS 用 Anypoint Connector

  • org.mule.extension.sqs​

  • org.apache.http

Microsoft Dynamics 365 用 Anypoint Connector

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.apache.http​

  • org.mule.extension.microsoftdynamics365

MuleSoft SAP 用 Anypoint Connector

org.mule.modules.sap

Anypoint MQ 用 Anypoint Connector

  • com.mulesoft.extension.mq​

  • com.mulesoft.mq

Database 用 Anypoint Connector

org.mule.extension.db

Microsoft SharePoint (バージョン 3.x) 用 Anypoint Connector

  • org.apache.http.wire​

  • org.apache.http
# 冗長ログの有効化 さまざまなモジュールやコネクタに対して冗長ログを有効にできます。アプリケーションのパフォーマンスに大きく影響するため、冗長ログはテストやトラブルシューティングでのみ使用してください。 ## [](#冗長ログの設定)冗長ログの設定 冗長ログを設定するには、​`log4j2.xml`​ ファイルにエントリを追加し、対象とするコネクタやモジュールのパッケージ名を指定して、ログレベルを ​`DEBUG`​ に設定します。 次の例は、Anypoint Connector JMS (JMS Connector) のパッケージ名を探して冗長ログを設定する方法を示しています。 1. **\[Package Explorer\]**​ ビューで、JMS Connector パッケージライブラリを開きます。 2. `.jar`​ ファイル内で Mule 関連パッケージをすべて探します。 ![verbose-logging-package](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-verbose-log-package.png) 3. `log4j2.xml`​ ファイルにエントリを追加し、パッケージ名を指定してログレベルを ​`DEBUG`​ に設定します。 ```xml ... ... ``` ## [](#一般的なコネクタパッケージ名)一般的なコネクタパッケージ名 探す手間を省けるように、一般的ないくつかの Anypoint Connector とそれぞれのパッケージ名を下表に示します。
Connector Name (コネクタ名) Package Names (パッケージ名)

HTTP 用 Anypoint Connector

org.mule.service.http.impl.service.HttpMessageLogger

Salesforce 用 Anypoint Connector

org.mule.extension.salesforce

FTP 用 Anypoint Connector

org.mule.extension.ftp

SFTP 用 Anypoint Connector

  • org.mule.extension.sftp​

  • com.jcraft

FTPS 用 Anypoint Connector

com.mulesoft.extension.ftps

NetSuite 用 Anypoint Connector

  • httpclient.wire.header​

  • httpclient.wire.content​

  • httpclient.wire​

  • org.apache.commons.httpclient​

  • org.apache.http​

  • org.mule.module.netsuite​

  • com.netsuite.webservices​

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.mule.module.netsuite.extension.internal.connection.provider.soap.JavaWSDispatcher

Amazon SQS 用 Anypoint Connector

  • org.mule.extension.sqs​

  • org.apache.http

Microsoft Dynamics 365 用 Anypoint Connector

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.apache.http​

  • org.mule.extension.microsoftdynamics365

MuleSoft SAP 用 Anypoint Connector

org.mule.modules.sap

Anypoint MQ 用 Anypoint Connector

  • com.mulesoft.extension.mq​

  • com.mulesoft.mq

Database 用 Anypoint Connector

org.mule.extension.db

Microsoft SharePoint (バージョン 3.x) 用 Anypoint Connector

  • org.apache.http.wire​

  • org.apache.http
# 冗長ログの有効化 さまざまなモジュールやコネクタに対して冗長ログを有効にできます。アプリケーションのパフォーマンスに大きく影響するため、冗長ログはテストやトラブルシューティングでのみ使用してください。 ## [](#冗長ログの設定)冗長ログの設定 冗長ログを設定するには、​`log4j2.xml`​ ファイルにエントリを追加し、対象とするコネクタやモジュールのパッケージ名を指定して、ログレベルを ​`DEBUG`​ に設定します。 次の例は、Anypoint Connector JMS (JMS Connector) のパッケージ名を探して冗長ログを設定する方法を示しています。 1. **\[Package Explorer\]**​ ビューで、JMS Connector パッケージライブラリを開きます。 2. `.jar`​ ファイル内で Mule 関連パッケージをすべて探します。 ![verbose-logging-package](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-verbose-log-package.png) 3. `log4j2.xml`​ ファイルにエントリを追加し、パッケージ名を指定してログレベルを ​`DEBUG`​ に設定します。 ```xml ... ... ``` ## [](#一般的なコネクタパッケージ名)一般的なコネクタパッケージ名 探す手間を省けるように、一般的ないくつかの Anypoint Connector とそれぞれのパッケージ名を下表に示します。
Connector Name (コネクタ名) Package Names (パッケージ名)

HTTP 用 Anypoint Connector

org.mule.service.http.impl.service.HttpMessageLogger

Salesforce 用 Anypoint Connector

org.mule.extension.salesforce

FTP 用 Anypoint Connector

org.mule.extension.ftp

SFTP 用 Anypoint Connector

  • org.mule.extension.sftp​

  • com.jcraft

FTPS 用 Anypoint Connector

com.mulesoft.extension.ftps

NetSuite 用 Anypoint Connector

  • httpclient.wire.header​

  • httpclient.wire.content​

  • httpclient.wire​

  • org.apache.commons.httpclient​

  • org.apache.http​

  • org.mule.module.netsuite​

  • com.netsuite.webservices​

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.mule.module.netsuite.extension.internal.connection.provider.soap.JavaWSDispatcher

Amazon SQS 用 Anypoint Connector

  • org.mule.extension.sqs​

  • org.apache.http

Microsoft Dynamics 365 用 Anypoint Connector

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.apache.http​

  • org.mule.extension.microsoftdynamics365

MuleSoft SAP 用 Anypoint Connector

org.mule.modules.sap

Anypoint MQ 用 Anypoint Connector

  • com.mulesoft.extension.mq​

  • com.mulesoft.mq

Database 用 Anypoint Connector

org.mule.extension.db

Microsoft SharePoint (バージョン 3.x) 用 Anypoint Connector

  • org.apache.http.wire​

  • org.apache.http
# 冗長ログの有効化 さまざまなモジュールやコネクタに対して冗長ログを有効にできます。アプリケーションのパフォーマンスに大きく影響するため、冗長ログはテストやトラブルシューティングでのみ使用してください。 ## [](#冗長ログの設定)冗長ログの設定 冗長ログを設定するには、​`log4j2.xml`​ ファイルにエントリを追加し、対象とするコネクタやモジュールのパッケージ名を指定して、ログレベルを ​`DEBUG`​ に設定します。 次の例は、Anypoint Connector JMS (JMS Connector) のパッケージ名を探して冗長ログを設定する方法を示しています。 1. **\[Package Explorer\]**​ ビューで、JMS Connector パッケージライブラリを開きます。 2. `.jar`​ ファイル内で Mule 関連パッケージをすべて探します。 ![verbose-logging-package](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-verbose-log-package.png) 3. `log4j2.xml`​ ファイルにエントリを追加し、パッケージ名を指定してログレベルを ​`DEBUG`​ に設定します。 ```xml ... ... ``` ## [](#一般的なコネクタパッケージ名)一般的なコネクタパッケージ名 探す手間を省けるように、一般的ないくつかの Anypoint Connector とそれぞれのパッケージ名を下表に示します。
Connector Name (コネクタ名) Package Names (パッケージ名)

HTTP 用 Anypoint Connector

org.mule.service.http.impl.service.HttpMessageLogger

Salesforce 用 Anypoint Connector

org.mule.extension.salesforce

FTP 用 Anypoint Connector

org.mule.extension.ftp

SFTP 用 Anypoint Connector

  • org.mule.extension.sftp​

  • com.jcraft

FTPS 用 Anypoint Connector

com.mulesoft.extension.ftps

NetSuite 用 Anypoint Connector

  • httpclient.wire.header​

  • httpclient.wire.content​

  • httpclient.wire​

  • org.apache.commons.httpclient​

  • org.apache.http​

  • org.mule.module.netsuite​

  • com.netsuite.webservices​

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.mule.module.netsuite.extension.internal.connection.provider.soap.JavaWSDispatcher

Amazon SQS 用 Anypoint Connector

  • org.mule.extension.sqs​

  • org.apache.http

Microsoft Dynamics 365 用 Anypoint Connector

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.apache.http​

  • org.mule.extension.microsoftdynamics365

MuleSoft SAP 用 Anypoint Connector

org.mule.modules.sap

Anypoint MQ 用 Anypoint Connector

  • com.mulesoft.extension.mq​

  • com.mulesoft.mq

Database 用 Anypoint Connector

org.mule.extension.db

Microsoft SharePoint (バージョン 3.x) 用 Anypoint Connector

  • org.apache.http.wire​

  • org.apache.http
# 冗長ログの有効化 さまざまなモジュールやコネクタに対して冗長ログを有効にできます。アプリケーションのパフォーマンスに大きく影響するため、冗長ログはテストやトラブルシューティングでのみ使用してください。 ## [](#冗長ログの設定)冗長ログの設定 冗長ログを設定するには、​`log4j2.xml`​ ファイルにエントリを追加し、対象とするコネクタやモジュールのパッケージ名を指定して、ログレベルを ​`DEBUG`​ に設定します。 次の例は、Anypoint Connector JMS (JMS Connector) のパッケージ名を探して冗長ログを設定する方法を示しています。 1. **\[Package Explorer\]**​ ビューで、JMS Connector パッケージライブラリを開きます。 2. `.jar`​ ファイル内で Mule 関連パッケージをすべて探します。 !["開発環境のさまざまな Java パッケージおよびライブラリがリストされている \[Package Explorer](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-verbose-log-package.png) ビュー"\] 3. `log4j2.xml`​ ファイルにエントリを追加し、パッケージ名を指定してログレベルを ​`DEBUG`​ に設定します。 ```xml ... ... ``` ## [](#一般的なコネクタパッケージ名)一般的なコネクタパッケージ名 探す手間を省けるように、一般的ないくつかの Anypoint Connector とそれぞれのパッケージ名を下表に示します。
Connector Name (コネクタ名) Package Names (パッケージ名)

HTTP 用 Anypoint Connector

org.mule.service.http.impl.service.HttpMessageLogger

Salesforce 用 Anypoint Connector

org.mule.extension.salesforce

FTP 用 Anypoint Connector

org.mule.extension.ftp

SFTP 用 Anypoint Connector

  • org.mule.extension.sftp​

  • com.jcraft

FTPS 用 Anypoint Connector

com.mulesoft.extension.ftps

NetSuite 用 Anypoint Connector

  • httpclient.wire.header​

  • httpclient.wire.content​

  • httpclient.wire​

  • org.apache.commons.httpclient​

  • org.apache.http​

  • org.mule.module.netsuite​

  • com.netsuite.webservices​

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.mule.module.netsuite.extension.internal.connection.provider.soap.JavaWSDispatcher

Amazon SQS 用 Anypoint Connector

  • org.mule.extension.sqs​

  • org.apache.http

Microsoft Dynamics 365 用 Anypoint Connector

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.apache.http​

  • org.mule.extension.microsoftdynamics365

MuleSoft SAP 用 Anypoint Connector

org.mule.modules.sap

Anypoint MQ 用 Anypoint Connector

  • com.mulesoft.extension.mq​

  • com.mulesoft.mq

Database 用 Anypoint Connector

org.mule.extension.db

Microsoft SharePoint (バージョン 3.x) 用 Anypoint Connector

  • org.apache.http.wire​

  • org.apache.http
# 冗長ログの有効化 さまざまなモジュールやコネクタに対して冗長ログを有効にできます。アプリケーションのパフォーマンスに大きく影響するため、冗長ログはテストやトラブルシューティングでのみ使用してください。 ## [](#冗長ログの設定)冗長ログの設定 冗長ログを設定するには、​`log4j2.xml`​ ファイルにエントリを追加し、対象とするコネクタやモジュールのパッケージ名を指定して、ログレベルを ​`DEBUG`​ に設定します。 次の例は、Anypoint Connector JMS (JMS Connector) のパッケージ名を探して冗長ログを設定する方法を示しています。 1. **\[Package Explorer\]**​ ビューで、JMS Connector パッケージライブラリを開きます。 2. `.jar`​ ファイル内で Mule 関連パッケージをすべて探します。 !["開発環境のさまざまな Java パッケージおよびライブラリがリストされている \[Package Explorer](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-verbose-log-package.png) ビュー"\] 3. `log4j2.xml`​ ファイルにエントリを追加し、パッケージ名を指定してログレベルを ​`DEBUG`​ に設定します。 ```xml ... ... ``` ## [](#一般的なコネクタパッケージ名)一般的なコネクタパッケージ名 探す手間を省けるように、一般的ないくつかの Anypoint Connector とそれぞれのパッケージ名を下表に示します。
Connector Name (コネクタ名) Package Names (パッケージ名)

HTTP 用 Anypoint Connector

org.mule.service.http.impl.service.HttpMessageLogger

Salesforce 用 Anypoint Connector

org.mule.extension.salesforce

FTP 用 Anypoint Connector

org.mule.extension.ftp

SFTP 用 Anypoint Connector

  • org.mule.extension.sftp​

  • com.jcraft

FTPS 用 Anypoint Connector

com.mulesoft.extension.ftps

NetSuite 用 Anypoint Connector

  • httpclient.wire.header​

  • httpclient.wire.content​

  • httpclient.wire​

  • org.apache.commons.httpclient​

  • org.apache.http​

  • org.mule.module.netsuite​

  • com.netsuite.webservices​

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.mule.module.netsuite.extension.internal.connection.provider.soap.JavaWSDispatcher

Amazon SQS 用 Anypoint Connector

  • org.mule.extension.sqs​

  • org.apache.http

Microsoft Dynamics 365 用 Anypoint Connector

  • org.mule.service.http.impl.service.HttpMessageLogger​

  • org.apache.http​

  • org.mule.extension.microsoftdynamics365

MuleSoft SAP 用 Anypoint Connector

org.mule.modules.sap

Anypoint MQ 用 Anypoint Connector

  • com.mulesoft.extension.mq​

  • com.mulesoft.mq

Database 用 Anypoint Connector

org.mule.extension.db

Microsoft SharePoint (バージョン 3.x) 用 Anypoint Connector

  • org.apache.http.wire​

  • org.apache.http
# 分散ファイルのポーリング **_Enterprise Edition_** File Connector や FTP Connector など、ディレクトリをポーリングし、ポーリングしたディレクトリにファイルが作成されたときにその特定のファイルを読み取るコネクタがあります。このファイルは、Mule 高可用性 (HA) クラスターに属するノードのファイルシステムなどのリモートファイルシステムに存在できます。 Mule 4 の分散ファイルポーリングでは、すべてのクラスターノードのファイルをポーリングできます。デフォルトで有効になっているこの機能は、次のコネクタで使用されます。 - [File Connector](https://docs.mulesoft.com/jp/file-connector/latest/) - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) プライマリノード (​`@PrimaryNodeOnly`​) からのみポーリングするようにコネクタを設定できます。この場合、Mule Runtime Engine で設定されたデフォルト設定は無視されます。この機能は、Mule 4.x でのみ使用できます。 ## [](#関連情報)関連情報 - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/creating-and-managing-a-cluster-manually) - [Mule 高可用性 (HA) クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-high-availability-ha-clusters) - [File Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-connectors-file) - [FTP および SFTP Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-connectors-ftp-sftp) # 分散ファイルのポーリング **_Enterprise Edition_** File Connector や FTP Connector など、ディレクトリをポーリングし、ポーリングしたディレクトリにファイルが作成されたときにその特定のファイルを読み取るコネクタがあります。このファイルは、Mule 高可用性 (HA) クラスターに属するノードのファイルシステムなどのリモートファイルシステムに存在できます。 Mule 4 の分散ファイルポーリングでは、すべてのクラスターノードのファイルをポーリングできます。デフォルトで有効になっているこの機能は、次のコネクタで使用されます。 - [File Connector](https://docs.mulesoft.com/jp/file-connector/latest/) - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) プライマリノード (​`@PrimaryNodeOnly`​) からのみポーリングするようにコネクタを設定できます。この場合、Mule Runtime Engine で設定されたデフォルト設定は無視されます。この機能は、Mule 4.x でのみ使用できます。 ## [](#関連情報)関連情報 - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/creating-and-managing-a-cluster-manually) - [Mule 高可用性 (HA) クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-high-availability-ha-clusters) - [File Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-connectors-file) - [FTP および SFTP Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-connectors-ftp-sftp) # 分散ファイルのポーリング **_Enterprise Edition_** ファイルコネクタや FTP Connector など、ディレクトリをポーリングし、ポーリングしたディレクトリにファイルが作成されたときにその特定のファイルを読み取るコネクタがあります。このファイルは、Mule 高可用性 (HA) クラスターに属するノードのファイルシステムなどのリモートファイルシステムに存在できます。 Mule 4 の分散ファイルポーリングでは、すべてのクラスターノードのファイルをポーリングできます。デフォルトで有効になっているこの機能は、次のコネクタで使用されます。 - [ファイルコネクタ](https://docs.mulesoft.com/jp/file-connector/latest/) - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) プライマリノード (​`@PrimaryNodeOnly`​) からのみポーリングするようにコネクタを設定できます。この場合、Mule Runtime Engine で設定されたデフォルト設定は無視されます。この機能は、Mule 4.x でのみ使用できます。 ## [](#関連情報)関連情報 - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/creating-and-managing-a-cluster-manually) - [Mule 高可用性 (HA) クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-high-availability-ha-clusters) - [ファイルコネクタの移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-connectors-file) - [FTP および SFTP Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-connectors-ftp-sftp) # 分散ファイルのポーリング **_Enterprise Edition_** File Connector や FTP Connector など、ディレクトリをポーリングし、ポーリングしたディレクトリにファイルが作成されたときにその特定のファイルを読み取るコネクタがあります。このファイルは、Mule 高可用性 (HA) クラスターに属するノードのファイルシステムなどのリモートファイルシステムに存在できます。 Mule 4 の分散ファイルポーリングでは、すべてのクラスターノードのファイルをポーリングできます。デフォルトで有効になっているこの機能は、次のコネクタで使用されます。 - [File Connector](https://docs.mulesoft.com/jp/file-connector/latest/) - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) プライマリノード (​`@PrimaryNodeOnly`​) からのみポーリングするようにコネクタを設定できます。この場合、Mule Runtime Engine で設定されたデフォルト設定は無視されます。この機能は、Mule 4.x でのみ使用できます。 ## [](#関連情報)関連情報 - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/creating-and-managing-a-cluster-manually) - [Mule 高可用性 (HA) クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-high-availability-ha-clusters) - [File Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-connectors-file) - [FTP および SFTP Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-connectors-ftp-sftp) # 分散ファイルのポーリング **_Enterprise Edition_** File Connector や FTP Connector など、ディレクトリをポーリングし、ポーリングしたディレクトリにファイルが作成されたときにその特定のファイルを読み取るコネクタがあります。このファイルは、Mule 高可用性 (HA) クラスターに属するノードのファイルシステムなどのリモートファイルシステムに存在できます。 Mule 4 の分散ファイルポーリングでは、すべてのクラスターノードのファイルをポーリングできます。デフォルトで有効になっているこの機能は、次のコネクタで使用されます。 - [File Connector](https://docs.mulesoft.com/jp/file-connector/latest/) - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) プライマリノード (​`@PrimaryNodeOnly`​) からのみポーリングするようにコネクタを設定できます。この場合、Mule Runtime Engine で設定されたデフォルト設定は無視されます。この機能は、Mule 4.x でのみ使用できます。 ## [](#関連情報)関連情報 - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/creating-and-managing-a-cluster-manually) - [Mule 高可用性 (HA) クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-high-availability-ha-clusters) - [File Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-connectors-file) - [FTP および SFTP Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-connectors-ftp-sftp) # 分散ファイルのポーリング **_Enterprise Edition_** File Connector や FTP Connector など、ディレクトリをポーリングし、ポーリングしたディレクトリにファイルが作成されたときにその特定のファイルを読み取るコネクタがあります。このファイルは、Mule 高可用性 (HA) クラスターに属するノードのファイルシステムなどのリモートファイルシステムに存在できます。 Mule 4 の分散ファイルポーリングでは、すべてのクラスターノードのファイルをポーリングできます。デフォルトで有効になっているこの機能は、次のコネクタで使用されます。 - [File Connector](https://docs.mulesoft.com/jp/file-connector/latest/) - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) プライマリノード (​`@PrimaryNodeOnly`​) からのみポーリングするようにコネクタを設定できます。この場合、Mule Runtime Engine で設定されたデフォルト設定は無視されます。この機能は、Mule 4.x でのみ使用できます。 ## [](#関連情報)関連情報 - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/creating-and-managing-a-cluster-manually) - [Mule 高可用性 (HA) クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-high-availability-ha-clusters) - [File Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-connectors-file) - [FTP および SFTP Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-connectors-ftp-sftp) # 分散ファイルのポーリング **_Enterprise Edition_** File Connector や FTP Connector など、ディレクトリをポーリングし、ポーリングしたディレクトリにファイルが作成されたときにその特定のファイルを読み取るコネクタがあります。このファイルは、Mule 高可用性 (HA) クラスターに属するノードのファイルシステムなどのリモートファイルシステムに存在できます。 Mule 4 の分散ファイルポーリングでは、すべてのクラスターノードのファイルをポーリングできます。デフォルトで有効になっているこの機能は、次のコネクタで使用されます。 - [File Connector](https://docs.mulesoft.com/jp/file-connector/latest/) - [FTP Connector](https://docs.mulesoft.com/jp/ftp-connector/latest/) - [SFTP Connector](https://docs.mulesoft.com/sftp-connector/latest/) プライマリノード (​`@PrimaryNodeOnly`​) からのみポーリングするようにコネクタを設定できます。この場合、Mule Runtime Engine で設定されたデフォルト設定は無視されます。この機能は、Mule 4.x でのみ使用できます。 ## [](#関連情報)関連情報 - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/creating-and-managing-a-cluster-manually) - [Mule 高可用性 (HA) クラスター](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-high-availability-ha-clusters) - [File Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-connectors-file) - [FTP および SFTP Connector の移行](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-connectors-ftp-sftp) # 分散ロッキング Mule Runtime Engine では、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。リソースへの同時アクセスを管理するため、Mule はロックファクトリーを提供します。このロックファクトリーに、ユーザーはスクリプトを使用してプログラムでアクセスしたり、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ で作成したカスタム拡張機能でアクセスしたりできます。 Mule ロックファクトリーで作成したロックは、1 つのサーバーまたはサーバーのクラスターを使用するデプロイメントモデルでシームレスに機能します。つまり、複数のスレッドで同じフローを実行しているサーバーや、同じアプリケーションを実行しているクラスター環境がある場合、Mule ロックを使用してリソースの同期を保証できます。また、Mule ロッキングシステムは、共有されたロックにアクセスするための簡単な API を提供します。

LockFactory​ は、​java.util.concurrent.Lock​ を実装する ​Lock​ を作成しますが、メソッド ​newCondition()​ をサポートしません。​newCondition()​ を使用すると、Mule は ​UnsupportedOperationException​ をスローします。Mule は、​lockInterruptibly()​ や ​tryLock()​ など、ロックと連動する他のメソッドをサポートします。
## [](#ロックを作成する)ロックを作成する ロックを作成するには、次の手順を実行します。 1. 挿入を使用して ​`LockFactory`​ にアクセスします。 Java SDK で拡張機能を作成している場合、いずれかの操作でロッキングが必要になったときは、​`LockFactory`​ をクラスに挿入します。 2. `LockFactory`​ を使用して、ロックの作成を開始します。 以下のサンプルコードを参照してください。これは、Mule ロックを使用してコードアクセスを管理する、つまり、(Scatter-Gather スコープや異なるクラスターノードなどで) 操作を並列で実行するときの同期の問題を回避する拡張操作を宣言しています。 3. 作成するロックの識別子を使用します。 識別子を使用すると、異なるスレッド間で同じロックインスタンスを明示的に共有することなく、それらのスレッドから 1 つのロックにアクセスできます。 このロックは ​`java.util.concurrent.Lock`​ インターフェースを実装しているため、メソッド ​`lock()`​ をコールすると、スレッドはロックを取得するまで待機します。 ロックを作成したら、重要なコードセクションを実行できますが、このロックを待機している他のスレッドでのデッドロックを回避するためのロックリリースメカニズムも作成する必要があります。これを実現するには、​`lock.unlock`​ コールを ​`finally`​ ブロックで囲みます。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperation() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#スクリプティングを使用したロックの作成)スクリプティングを使用したロックの作成 スクリプティング拡張機能を使用している場合は、まずレジストリにアクセスして ​`LockFactory`​ を取得してから、スクリプティングコードを使用してロックを作成します。以下の例は Groovy を使用して前の例と同じ結果を達成します。つまり、​`LockFactory`​ を取得し (この場合は ​`Registry`​ を使用します)、特定の ID 用の新しい ​`Lock`​ を作成し、ロックを取得するまで待機して、重要なコードを実行した後、ロックをリリースします。 ```groovy lockFactory = registry.lookupByName("_muleLockFactory").get() lock = lockFactory.createLock("sharedResourceId") lock.lock() try { // Lock acquired, execute critical code. } finally { lock.unlock() } ``` ## [](#操作間でのロックの共有)操作間でのロックの共有 ロッキングは、同じ操作を実行する複数のスレッドのロックを作成するのに役立つだけでなく、並列で実行される可能性がある異なる操作で使用することもできます。同じロック ID を使用してさまざまな操作でロックを作成すると、それらの操作で同じロックへのアクセス権を取得できます。次のコードサンプルは、同じロック ID を使用してロックを作成する 2 つのカスタム操作を示しています。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperationA() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } public void sharedResourceOperationB() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#関連情報)関連情報 - [Mule 高可用性 (HA) クラスタリング](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-high-availability-ha-clusters) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/creating-and-managing-a-cluster-manually) - [分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.3/distributed-file-polling) # 分散ロッキング Mule Runtime Engine では、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。リソースへの同時アクセスを管理するため、Mule はロックファクトリーを提供します。このロックファクトリーに、ユーザーはスクリプトを使用してプログラムでアクセスしたり、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ で作成したカスタム拡張機能でアクセスしたりできます。 Mule ロックファクトリーで作成したロックは、1 つのサーバーまたはサーバーのクラスターを使用するデプロイメントモデルでシームレスに機能します。つまり、複数のスレッドで同じフローを実行しているサーバーや、同じアプリケーションを実行しているクラスター環境がある場合、Mule ロックを使用してリソースの同期を保証できます。また、Mule ロッキングシステムは、共有されたロックにアクセスするための簡単な API を提供します。

LockFactory​ は、​java.util.concurrent.Lock​ を実装する ​Lock​ を作成しますが、メソッド ​newCondition()​ をサポートしません。​newCondition()​ を使用すると、Mule は ​UnsupportedOperationException​ をスローします。Mule は、​lockInterruptibly()​ や ​tryLock()​ など、ロックと連動する他のメソッドをサポートします。
## [](#ロックを作成する)ロックを作成する ロックを作成するには、次の手順を実行します。 1. 挿入を使用して ​`LockFactory`​ にアクセスします。 Java SDK で拡張機能を作成している場合、いずれかの操作でロッキングが必要になったときは、​`LockFactory`​ をクラスに挿入します。 2. `LockFactory`​ を使用して、ロックの作成を開始します。 以下のサンプルコードを参照してください。これは、Mule ロックを使用してコードアクセスを管理する、つまり、(Scatter-Gather スコープや異なるクラスターノードなどで) 操作を並列で実行するときの同期の問題を回避する拡張操作を宣言しています。 3. 作成するロックの識別子を使用します。 識別子を使用すると、異なるスレッド間で同じロックインスタンスを明示的に共有することなく、それらのスレッドから 1 つのロックにアクセスできます。 このロックは ​`java.util.concurrent.Lock`​ インターフェースを実装しているため、メソッド ​`lock()`​ をコールすると、スレッドはロックを取得するまで待機します。 ロックを作成したら、重要なコードセクションを実行できますが、このロックを待機している他のスレッドでのデッドロックを回避するためのロックリリースメカニズムも作成する必要があります。これを実現するには、​`lock.unlock`​ コールを ​`finally`​ ブロックで囲みます。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperation() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#スクリプティングを使用したロックの作成)スクリプティングを使用したロックの作成 スクリプティング拡張機能を使用している場合は、まずレジストリにアクセスして ​`LockFactory`​ を取得してから、スクリプティングコードを使用してロックを作成します。以下の例は Groovy を使用して前の例と同じ結果を達成します。つまり、​`LockFactory`​ を取得し (この場合は ​`Registry`​ を使用します)、特定の ID 用の新しい ​`Lock`​ を作成し、ロックを取得するまで待機して、重要なコードを実行した後、ロックをリリースします。 ```groovy lockFactory = registry.lookupByName("_muleLockFactory").get() lock = lockFactory.createLock("sharedResourceId") lock.lock() try { // Lock acquired, execute critical code. } finally { lock.unlock() } ``` ## [](#操作間でのロックの共有)操作間でのロックの共有 ロッキングは、同じ操作を実行する複数のスレッドのロックを作成するのに役立つだけでなく、並列で実行される可能性がある異なる操作で使用することもできます。同じロック ID を使用してさまざまな操作でロックを作成すると、それらの操作で同じロックへのアクセス権を取得できます。次のコードサンプルは、同じロック ID を使用してロックを作成する 2 つのカスタム操作を示しています。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperationA() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } public void sharedResourceOperationB() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#関連情報)関連情報 - [Mule 高可用性 (HA) クラスタリング](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-high-availability-ha-clusters) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/creating-and-managing-a-cluster-manually) - [分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.4/distributed-file-polling) # 分散ロッキング Mule Runtime Engine では、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。リソースへの同時アクセスを管理するため、Mule はロックファクトリーを提供します。このロックファクトリーに、ユーザーはスクリプトを使用してプログラムでアクセスしたり、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ で作成したカスタム拡張機能でアクセスしたりできます。 Mule ロックファクトリーで作成したロックは、1 つのサーバーまたはサーバーのクラスターを使用するデプロイメントモデルでシームレスに機能します。つまり、複数のスレッドで同じフローを実行しているサーバーや、同じアプリケーションを実行しているクラスター環境がある場合、Mule ロックを使用してリソースの同期を保証できます。また、Mule ロッキングシステムは、共有されたロックにアクセスするための簡単な API を提供します。

LockFactory​ は、​java.util.concurrent.Lock​ を実装する ​Lock​ を作成しますが、メソッド ​newCondition()​ をサポートしません。​newCondition()​ を使用すると、Mule は ​UnsupportedOperationException​ をスローします。Mule は、​lockInterruptibly()​ や ​tryLock()​ など、ロックと連動する他のメソッドをサポートします。
## [](#ロックを作成する)ロックを作成する ロックを作成するには、次の手順を実行します。 1. 挿入を使用して ​`LockFactory`​ にアクセスします。 Java SDK で拡張機能を作成している場合、いずれかの操作でロッキングが必要になったときは、​`LockFactory`​ をクラスに挿入します。 2. `LockFactory`​ を使用して、ロックの作成を開始します。 以下のサンプルコードを参照してください。これは、Mule ロックを使用してコードアクセスを管理する、つまり、(Scatter-Gather スコープや異なるクラスターノードなどで) 操作を並列で実行するときの同期の問題を回避する拡張操作を宣言しています。 3. 作成するロックの識別子を使用します。 識別子を使用すると、異なるスレッド間で同じロックインスタンスを明示的に共有することなく、それらのスレッドから 1 つのロックにアクセスできます。 このロックは ​`java.util.concurrent.Lock`​ インターフェースを実装しているため、メソッド ​`lock()`​ をコールすると、スレッドはロックを取得するまで待機します。 ロックを作成したら、重要なコードセクションを実行できますが、このロックを待機している他のスレッドでのデッドロックを回避するためのロックリリースメカニズムも作成する必要があります。これを実現するには、​`lock.unlock`​ コールを ​`finally`​ ブロックで囲みます。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperation() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#スクリプティングを使用したロックの作成)スクリプティングを使用したロックの作成 スクリプティング拡張機能を使用している場合は、まずレジストリにアクセスして ​`LockFactory`​ を取得してから、スクリプティングコードを使用してロックを作成します。以下の例は Groovy を使用して前の例と同じ結果を達成します。つまり、​`LockFactory`​ を取得し (この場合は ​`Registry`​ を使用します)、特定の ID 用の新しい ​`Lock`​ を作成し、ロックを取得するまで待機して、重要なコードを実行した後、ロックをリリースします。 ```groovy lockFactory = registry.lookupByName("_muleLockFactory").get() lock = lockFactory.createLock("sharedResourceId") lock.lock() try { // Lock acquired, execute critical code. } finally { lock.unlock() } ``` ## [](#操作間でのロックの共有)操作間でのロックの共有 ロッキングは、同じ操作を実行する複数のスレッドのロックを作成するのに役立つだけでなく、並列で実行される可能性がある異なる操作で使用することもできます。同じロック ID を使用してさまざまな操作でロックを作成すると、それらの操作で同じロックへのアクセス権を取得できます。次のコードサンプルは、同じロック ID を使用してロックを作成する 2 つのカスタム操作を示しています。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperationA() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } public void sharedResourceOperationB() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#関連情報)関連情報 - [Mule 高可用性 (HA) クラスタリング](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-high-availability-ha-clusters) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/creating-and-managing-a-cluster-manually) - [分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.5/distributed-file-polling) # 分散ロッキング Mule Runtime Engine では、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。リソースへの同時アクセスを管理するため、Mule はロックファクトリーを提供します。このロックファクトリーに、ユーザーはスクリプトを使用してプログラムでアクセスしたり、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ で作成したカスタム拡張機能でアクセスしたりできます。 Mule ロックファクトリーで作成したロックは、1 つのサーバーまたはサーバーのクラスターを使用するデプロイメントモデルでシームレスに機能します。つまり、複数のスレッドで同じフローを実行しているサーバーや、同じアプリケーションを実行しているクラスター環境がある場合、Mule ロックを使用してリソースの同期を保証できます。また、Mule ロッキングシステムは、共有されたロックにアクセスするための簡単な API を提供します。

LockFactory​ は、​java.util.concurrent.Lock​ を実装する ​Lock​ を作成しますが、メソッド ​newCondition()​ をサポートしません。​newCondition()​ を使用すると、Mule は ​UnsupportedOperationException​ をスローします。Mule は、​lockInterruptibly()​ や ​tryLock()​ など、ロックと連動する他のメソッドをサポートします。
## [](#ロックを作成する)ロックを作成する ロックを作成するには、次の手順を実行します。 1. 挿入を使用して ​`LockFactory`​ にアクセスします。 Java SDK で拡張機能を作成している場合、いずれかの操作でロッキングが必要になったときは、​`LockFactory`​ をクラスに挿入します。 2. `LockFactory`​ を使用して、ロックの作成を開始します。 以下のサンプルコードを参照してください。これは、Mule ロックを使用してコードアクセスを管理する、つまり、(Scatter-Gather スコープや異なるクラスターノードなどで) 操作を並列で実行するときの同期の問題を回避する拡張操作を宣言しています。 3. 作成するロックの識別子を使用します。 識別子を使用すると、異なるスレッド間で同じロックインスタンスを明示的に共有することなく、それらのスレッドから 1 つのロックにアクセスできます。 このロックは ​`java.util.concurrent.Lock`​ インターフェースを実装しているため、メソッド ​`lock()`​ をコールすると、スレッドはロックを取得するまで待機します。 ロックを作成したら、重要なコードセクションを実行できますが、このロックを待機している他のスレッドでのデッドロックを回避するためのロックリリースメカニズムも作成する必要があります。これを実現するには、​`lock.unlock`​ コールを ​`finally`​ ブロックで囲みます。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperation() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#スクリプティングを使用したロックの作成)スクリプティングを使用したロックの作成 スクリプティング拡張機能を使用している場合は、まずレジストリにアクセスして ​`LockFactory`​ を取得してから、スクリプティングコードを使用してロックを作成します。以下の例は Groovy を使用して前の例と同じ結果を達成します。つまり、​`LockFactory`​ を取得し (この場合は ​`Registry`​ を使用します)、特定の ID 用の新しい ​`Lock`​ を作成し、ロックを取得するまで待機して、重要なコードを実行した後、ロックをリリースします。 ```groovy lockFactory = registry.lookupByName("_muleLockFactory").get() lock = lockFactory.createLock("sharedResourceId") lock.lock() try { // Lock acquired, execute critical code. } finally { lock.unlock() } ``` ## [](#操作間でのロックの共有)操作間でのロックの共有 ロッキングは、同じ操作を実行する複数のスレッドのロックを作成するのに役立つだけでなく、並列で実行される可能性がある異なる操作で使用することもできます。同じロック ID を使用してさまざまな操作でロックを作成すると、それらの操作で同じロックへのアクセス権を取得できます。次のコードサンプルは、同じロック ID を使用してロックを作成する 2 つのカスタム操作を示しています。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperationA() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } public void sharedResourceOperationB() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#関連情報)関連情報 - [Mule 高可用性 (HA) クラスタリング](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-high-availability-ha-clusters) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/creating-and-managing-a-cluster-manually) - [分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.6/distributed-file-polling) # 分散ロッキング Mule Runtime Engine では、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。リソースへの同時アクセスを管理するため、Mule はロックファクトリーを提供します。このロックファクトリーに、ユーザーはスクリプトを使用してプログラムでアクセスしたり、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ で作成したカスタム拡張機能でアクセスしたりできます。 Mule ロックファクトリーで作成したロックは、1 つのサーバーまたはサーバーのクラスターを使用するデプロイメントモデルでシームレスに機能します。つまり、複数のスレッドで同じフローを実行しているサーバーや、同じアプリケーションを実行しているクラスター環境がある場合、Mule ロックを使用してリソースの同期を保証できます。また、Mule ロッキングシステムは、共有されたロックにアクセスするための簡単な API を提供します。

LockFactory​ は、​java.util.concurrent.Lock​ を実装する ​Lock​ を作成しますが、メソッド ​newCondition()​ をサポートしません。​newCondition()​ を使用すると、Mule は ​UnsupportedOperationException​ をスローします。Mule は、​lockInterruptibly()​ や ​tryLock()​ など、ロックと連動する他のメソッドをサポートします。
## [](#ロックを作成する)ロックを作成する ロックを作成するには、次の手順を実行します。 1. 挿入を使用して ​`LockFactory`​ にアクセスします。 Java SDK で拡張機能を作成している場合、いずれかの操作でロッキングが必要になったときは、​`LockFactory`​ をクラスに挿入します。 2. `LockFactory`​ を使用して、ロックの作成を開始します。 以下のサンプルコードを参照してください。これは、Mule ロックを使用してコードアクセスを管理する、つまり、(Scatter-Gather スコープや異なるクラスターノードなどで) 操作を並列で実行するときの同期の問題を回避する拡張操作を宣言しています。 3. 作成するロックの識別子を使用します。 識別子を使用すると、異なるスレッド間で同じロックインスタンスを明示的に共有することなく、それらのスレッドから 1 つのロックにアクセスできます。 このロックは ​`java.util.concurrent.Lock`​ インターフェースを実装しているため、メソッド ​`lock()`​ をコールすると、スレッドはロックを取得するまで待機します。 ロックを作成したら、重要なコードセクションを実行できますが、このロックを待機している他のスレッドでのデッドロックを回避するためのロックリリースメカニズムも作成する必要があります。これを実現するには、​`lock.unlock`​ コールを ​`finally`​ ブロックで囲みます。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperation() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#スクリプティングを使用したロックの作成)スクリプティングを使用したロックの作成 スクリプティング拡張機能を使用している場合は、まずレジストリにアクセスして ​`LockFactory`​ を取得してから、スクリプティングコードを使用してロックを作成します。以下の例は Groovy を使用して前の例と同じ結果を達成します。つまり、​`LockFactory`​ を取得し (この場合は ​`Registry`​ を使用します)、特定の ID 用の新しい ​`Lock`​ を作成し、ロックを取得するまで待機して、重要なコードを実行した後、ロックをリリースします。 ```groovy lockFactory = registry.lookupByName("_muleLockFactory").get() lock = lockFactory.createLock("sharedResourceId") lock.lock() try { // Lock acquired, execute critical code. } finally { lock.unlock() } ``` ## [](#操作間でのロックの共有)操作間でのロックの共有 ロッキングは、同じ操作を実行する複数のスレッドのロックを作成するのに役立つだけでなく、並列で実行される可能性がある異なる操作で使用することもできます。同じロック ID を使用してさまざまな操作でロックを作成すると、それらの操作で同じロックへのアクセス権を取得できます。次のコードサンプルは、同じロック ID を使用してロックを作成する 2 つのカスタム操作を示しています。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperationA() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } public void sharedResourceOperationB() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#関連情報)関連情報 - [Mule 高可用性 (HA) クラスタリング](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-high-availability-ha-clusters) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/creating-and-managing-a-cluster-manually) - [分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.7/distributed-file-polling) # 分散ロッキング Mule Runtime Engine では、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。リソースへの同時アクセスを管理するため、Mule はロックファクトリーを提供します。このロックファクトリーに、ユーザーはスクリプトを使用してプログラムでアクセスしたり、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ で作成したカスタム拡張機能でアクセスしたりできます。 Mule ロックファクトリーで作成したロックは、1 つのサーバーまたはサーバーのクラスターを使用するデプロイメントモデルでシームレスに機能します。つまり、複数のスレッドで同じフローを実行しているサーバーや、同じアプリケーションを実行しているクラスター環境がある場合、Mule ロックを使用してリソースの同期を保証できます。また、Mule ロッキングシステムは、共有されたロックにアクセスするための簡単な API を提供します。

LockFactory​ は、​java.util.concurrent.Lock​ を実装する ​Lock​ を作成しますが、メソッド ​newCondition()​ をサポートしません。​newCondition()​ を使用すると、Mule は ​UnsupportedOperationException​ をスローします。Mule は、​lockInterruptibly()​ や ​tryLock()​ など、ロックと連動する他のメソッドをサポートします。
## [](#ロックを作成する)ロックを作成する ロックを作成するには、次の手順を実行します。 1. 挿入を使用して ​`LockFactory`​ にアクセスします。 Java SDK で拡張機能を作成している場合、いずれかの操作でロッキングが必要になったときは、​`LockFactory`​ をクラスに挿入します。 2. `LockFactory`​ を使用して、ロックの作成を開始します。 以下のサンプルコードを参照してください。これは、Mule ロックを使用してコードアクセスを管理する、つまり、(Scatter-Gather スコープや異なるクラスターノードなどで) 操作を並列で実行するときの同期の問題を回避する拡張操作を宣言しています。 3. 作成するロックの識別子を使用します。 識別子を使用すると、異なるスレッド間で同じロックインスタンスを明示的に共有することなく、それらのスレッドから 1 つのロックにアクセスできます。 このロックは ​`java.util.concurrent.Lock`​ インターフェースを実装しているため、メソッド ​`lock()`​ をコールすると、スレッドはロックを取得するまで待機します。 ロックを作成したら、重要なコードセクションを実行できますが、このロックを待機している他のスレッドでのデッドロックを回避するためのロックリリースメカニズムも作成する必要があります。これを実現するには、​`lock.unlock`​ コールを ​`finally`​ ブロックで囲みます。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperation() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#スクリプティングを使用したロックの作成)スクリプティングを使用したロックの作成 スクリプティング拡張機能を使用している場合は、まずレジストリにアクセスして ​`LockFactory`​ を取得してから、スクリプティングコードを使用してロックを作成します。以下の例は Groovy を使用して前の例と同じ結果を達成します。つまり、​`LockFactory`​ を取得し (この場合は ​`Registry`​ を使用します)、特定の ID 用の新しい ​`Lock`​ を作成し、ロックを取得するまで待機して、重要なコードを実行した後、ロックをリリースします。 ```groovy lockFactory = registry.lookupByName("_muleLockFactory").get() lock = lockFactory.createLock("sharedResourceId") lock.lock() try { // Lock acquired, execute critical code. } finally { lock.unlock() } ``` ## [](#操作間でのロックの共有)操作間でのロックの共有 ロッキングは、同じ操作を実行する複数のスレッドのロックを作成するのに役立つだけでなく、並列で実行される可能性がある異なる操作で使用することもできます。同じロック ID を使用してさまざまな操作でロックを作成すると、それらの操作で同じロックへのアクセス権を取得できます。次のコードサンプルは、同じロック ID を使用してロックを作成する 2 つのカスタム操作を示しています。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperationA() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } public void sharedResourceOperationB() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#関連情報)関連情報 - [Mule 高可用性 (HA) クラスタリング](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-high-availability-ha-clusters) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/creating-and-managing-a-cluster-manually) - [分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.8/distributed-file-polling) # 分散ロッキング Mule Runtime Engine では、Mule コンポーネント内のリソースへのアクセスを同期するためのロックを作成できます。リソースへの同時アクセスを管理するため、Mule はロックファクトリーを提供します。このロックファクトリーに、ユーザーはスクリプトを使用してプログラムでアクセスしたり、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ で作成したカスタム拡張機能でアクセスしたりできます。 Mule ロックファクトリーで作成したロックは、1 つのサーバーまたはサーバーのクラスターを使用するデプロイメントモデルでシームレスに機能します。つまり、複数のスレッドで同じフローを実行しているサーバーや、同じアプリケーションを実行しているクラスター環境がある場合、Mule ロックを使用してリソースの同期を保証できます。また、Mule ロッキングシステムは、共有されたロックにアクセスするための簡単な API を提供します。

LockFactory​ は、​java.util.concurrent.Lock​ を実装する ​Lock​ を作成しますが、メソッド ​newCondition()​ をサポートしません。​newCondition()​ を使用すると、Mule は ​UnsupportedOperationException​ をスローします。Mule は、​lockInterruptibly()​ や ​tryLock()​ など、ロックと連動する他のメソッドをサポートします。
## [](#ロックを作成する)ロックを作成する ロックを作成するには、次の手順を実行します。 1. 挿入を使用して ​`LockFactory`​ にアクセスします。 Java SDK で拡張機能を作成している場合、いずれかの操作でロッキングが必要になったときは、​`LockFactory`​ をクラスに挿入します。 2. `LockFactory`​ を使用して、ロックの作成を開始します。 以下のサンプルコードを参照してください。これは、Mule ロックを使用してコードアクセスを管理する、つまり、(Scatter-Gather スコープや異なるクラスターノードなどで) 操作を並列で実行するときの同期の問題を回避する拡張操作を宣言しています。 3. 作成するロックの識別子を使用します。 識別子を使用すると、異なるスレッド間で同じロックインスタンスを明示的に共有することなく、それらのスレッドから 1 つのロックにアクセスできます。 このロックは ​`java.util.concurrent.Lock`​ インターフェースを実装しているため、メソッド ​`lock()`​ をコールすると、スレッドはロックを取得するまで待機します。 ロックを作成したら、重要なコードセクションを実行できますが、このロックを待機している他のスレッドでのデッドロックを回避するためのロックリリースメカニズムも作成する必要があります。これを実現するには、​`lock.unlock`​ コールを ​`finally`​ ブロックで囲みます。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperation() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#スクリプティングを使用したロックの作成)スクリプティングを使用したロックの作成 スクリプティング拡張機能を使用している場合は、まずレジストリにアクセスして ​`LockFactory`​ を取得してから、スクリプティングコードを使用してロックを作成します。以下の例は Groovy を使用して前の例と同じ結果を達成します。つまり、​`LockFactory`​ を取得し (この場合は ​`Registry`​ を使用します)、特定の ID 用の新しい ​`Lock`​ を作成し、ロックを取得するまで待機して、重要なコードを実行した後、ロックをリリースします。 ```groovy lockFactory = registry.lookupByName("_muleLockFactory").get() lock = lockFactory.createLock("sharedResourceId") lock.lock() try { // Lock acquired, execute critical code. } finally { lock.unlock() } ``` ## [](#操作間でのロックの共有)操作間でのロックの共有 ロッキングは、同じ操作を実行する複数のスレッドのロックを作成するのに役立つだけでなく、並列で実行される可能性がある異なる操作で使用することもできます。同じロック ID を使用してさまざまな操作でロックを作成すると、それらの操作で同じロックへのアクセス権を取得できます。次のコードサンプルは、同じロック ID を使用してロックを作成する 2 つのカスタム操作を示しています。 ```java public class ClusterOperations { @Inject private LockFactory lockFactory; public void sharedResourceOperationA() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } public void sharedResourceOperationB() { Lock lock = lockFactory.createLock("sharedResourceId"); lock.lock(); try { // Lock acquired, execute critical code. } finally { lock.unlock(); } } } ``` ## [](#関連情報)関連情報 - [Mule 高可用性 (HA) クラスタリング](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-high-availability-ha-clusters) - [手動によるクラスターの作成および管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/creating-and-managing-a-cluster-manually) - [分散ファイルのポーリング](https://docs.mulesoft.com/jp/mule-runtime/4.9/distributed-file-polling) # 単一リソーストランザクション 単一リソーストランザクション (単一トランザクションやローカルトランザクションとも呼ばれる) では、単一リソースのみを使用してメッセージを送信または受信します: JMS ブローカー、VM キュー、または JDBC 接続。 次の例は、JMS Connector の接続元およびパブリッシュ操作を使用して実行される単一リソーストランザクションが含まれるフローを示しています。 ```xml ```
jms:listener​ 提供元と ​jms:publish​ 操作の両方で同じ接続設定を使用する必要があります。これは、このメカニズムが 1 つのリソースを管理することを目的としているためです。
上記の例では、​`test.in`​ キューからメッセージを受信する JMS メッセージソースとメッセージを ​`test.out`​ キューに送信する別の JMS 操作を定義しています。​`transactionalAction`​ 属性によって、Mule がトランザクションを開始する方法が決まります。このフロー内で、Mule は受信したすべてのメッセージのトランザクションを開始 (​`jms:listener`​ ソース) し、送信するすべてのメッセージについて進行中のトランザクションを必ず結合します (​`jms:publish`​ 操作)。 Mule は、完全なフローを通じて正常に渡されるメッセージのみをコミットします。フローのどこかの時点でメッセージがエラーをスローし、そのエラーが伝播される場合 (つまり、​`on-error-continue`​ で処理されない)、Mule はトランザクションをロールバックします。エラーの処理方法についての詳細は、​[「On Error スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/on-error-scope-concept)​を参照してください。 ## [](#ネストされたトランザクション)ネストされたトランザクション ネストされたトランザクションは、単一リソーストランザクションでは使用できません。詳細は、​[「XA トランザクション」](https://docs.mulesoft.com/jp/mule-runtime/4.3/xa-transactions#nested-transactions)​を参照してください。 ## [](#関連情報)関連情報 - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.3/transaction-management) # 単一リソーストランザクション 単一リソーストランザクション (単一トランザクションやローカルトランザクションとも呼ばれる) では、単一リソースのみを使用してメッセージを送信または受信します: JMS ブローカー、VM キュー、または JDBC 接続。 次の例は、JMS Connector の接続元およびパブリッシュ操作を使用して実行される単一リソーストランザクションが含まれるフローを示しています。 ```xml ```
jms:listener​ 提供元と ​jms:publish​ 操作の両方で同じ接続設定を使用する必要があります。これは、このメカニズムが 1 つのリソースを管理することを目的としているためです。
上記の例では、​`test.in`​ キューからメッセージを受信する JMS イベントソースとメッセージを ​`test.out`​ キューに送信する別の JMS 操作を定義しています。​`transactionalAction`​ 属性によって、Mule がトランザクションを開始する方法が決まります。このフロー内で、Mule は受信したすべてのメッセージのトランザクションを開始 (​`jms:listener`​ ソース) し、送信するすべてのメッセージについて進行中のトランザクションを必ず結合します (​`jms:publish`​ 操作)。 Mule は、完全なフローを通じて正常に渡されるメッセージのみをコミットします。フローのどこかの時点でメッセージがエラーをスローし、そのエラーが伝播される場合 (つまり、​`on-error-continue`​ で処理されない)、Mule はトランザクションをロールバックします。エラーの処理方法についての詳細は、​[「On Error スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/on-error-scope-concept)​を参照してください。 ## [](#ネストされたトランザクション)ネストされたトランザクション ネストされたトランザクションは、単一リソーストランザクションでは使用できません。詳細は、​[「XA トランザクション」](https://docs.mulesoft.com/jp/mule-runtime/4.4/xa-transactions#nested-transactions)​を参照してください。 ## [](#関連情報)関連情報 - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.4/transaction-management) # 単一リソーストランザクション 単一リソーストランザクション (単一トランザクションやローカルトランザクションとも呼ばれる) では、単一リソースのみを使用してメッセージを送信または受信します: JMS ブローカー、VM キュー、または JDBC 接続。 次の例は、JMS Connector の接続元およびパブリッシュ操作を使用して実行される単一リソーストランザクションが含まれるフローを示しています。 ```xml ```
jms:listener​ 提供元と ​jms:publish​ 操作の両方で同じ接続設定を使用する必要があります。これは、このメカニズムが 1 つのリソースを管理することを目的としているためです。
上記の例では、​`test.in`​ キューからメッセージを受信する JMS イベントソースとメッセージを ​`test.out`​ キューに送信する別の JMS 操作を定義しています。​`transactionalAction`​ 属性によって、Mule がトランザクションを開始する方法が決まります。このフロー内で、Mule は受信したすべてのメッセージのトランザクションを開始 (​`jms:listener`​ 提供元) し、送信するすべてのメッセージについて進行中のトランザクションを必ず結合します (​`jms:publish`​ 操作)。 Mule は、完全なフローを通じて正常に渡されるメッセージのみをコミットします。フローのどこかの時点でメッセージがエラーをスローし、そのエラーが伝播される場合 (つまり、​`on-error-continue`​ で処理されない)、Mule はトランザクションをロールバックします。エラーの処理方法についての詳細は、​[「On Error スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/on-error-scope-concept)​を参照してください。 ## [](#ネストされたトランザクション)ネストされたトランザクション ネストされたトランザクションは、単一リソーストランザクションでは使用できません。詳細は、​[「XA トランザクション」](https://docs.mulesoft.com/jp/mule-runtime/4.5/xa-transactions#nested-transactions)​を参照してください。 ## [](#関連情報)関連情報 - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.5/transaction-management) # 単一リソーストランザクション 単一リソーストランザクション (単一トランザクションやローカルトランザクションとも呼ばれる) では、単一リソースのみを使用してメッセージを送信または受信します: JMS ブローカー、VM キュー、または JDBC 接続。 次の例は、JMS Connector の接続元およびパブリッシュ操作を使用して実行される単一リソーストランザクションが含まれるフローを示しています。 ```xml ```
jms:listener​ 提供元と ​jms:publish​ 操作の両方で同じ接続設定を使用する必要があります。これは、このメカニズムが 1 つのリソースを管理することを目的としているためです。
上記の例では、​`test.in`​ キューからメッセージを受信する JMS イベントソースとメッセージを ​`test.out`​ キューに送信する別の JMS 操作を定義しています。​`transactionalAction`​ 属性によって、Mule がトランザクションを開始する方法が決まります。このフロー内で、Mule は受信したすべてのメッセージのトランザクションを開始 (​`jms:listener`​ 提供元) し、送信するすべてのメッセージについて進行中のトランザクションを必ず結合します (​`jms:publish`​ 操作)。 Mule は、完全なフローを通じて正常に渡されるメッセージのみをコミットします。フローのどこかの時点でメッセージがエラーをスローし、そのエラーが伝播される場合 (つまり、​`on-error-continue`​ で処理されない)、Mule はトランザクションをロールバックします。エラーの処理方法についての詳細は、​[「On Error スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/on-error-scope-concept)​を参照してください。 ## [](#ネストされたトランザクション)ネストされたトランザクション ネストされたトランザクションは、単一リソーストランザクションでは使用できません。詳細は、​[「XA トランザクション」](https://docs.mulesoft.com/jp/mule-runtime/4.6/xa-transactions#nested-transactions)​を参照してください。 ## [](#関連情報)関連情報 - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.6/transaction-management) # 単一リソーストランザクション 単一リソーストランザクション (単一トランザクションやローカルトランザクションとも呼ばれる) では、単一リソースのみを使用してメッセージを送信または受信します: JMS ブローカー、VM キュー、または JDBC 接続。 次の例は、JMS Connector の接続元およびパブリッシュ操作を使用して実行される単一リソーストランザクションが含まれるフローを示しています。 ```xml ```
jms:listener​ 提供元と ​jms:publish​ 操作の両方で同じ接続設定を使用する必要があります。これは、このメカニズムが 1 つのリソースを管理することを目的としているためです。
上記の例では、​`test.in`​ キューからメッセージを受信する JMS イベントソースとメッセージを ​`test.out`​ キューに送信する別の JMS 操作を定義しています。​`transactionalAction`​ 属性によって、Mule がトランザクションを開始する方法が決まります。このフロー内で、Mule は受信したすべてのメッセージのトランザクションを開始 (​`jms:listener`​ 提供元) し、送信するすべてのメッセージについて進行中のトランザクションを必ず結合します (​`jms:publish`​ 操作)。 Mule は、完全なフローを通じて正常に渡されるメッセージのみをコミットします。フローのどこかの時点でメッセージがエラーをスローし、そのエラーが伝播される場合 (つまり、​`on-error-continue`​ で処理されない)、Mule はトランザクションをロールバックします。エラーの処理方法についての詳細は、​[「On Error スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/on-error-scope-concept)​を参照してください。 ## [](#ネストされたトランザクション)ネストされたトランザクション ネストされたトランザクションは、単一リソーストランザクションでは使用できません。詳細は、​[「XA トランザクション」](https://docs.mulesoft.com/jp/mule-runtime/4.7/xa-transactions#nested-transactions)​を参照してください。 ## [](#関連情報)関連情報 - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.7/transaction-management) # 単一リソーストランザクション 単一リソーストランザクション (単一トランザクションやローカルトランザクションとも呼ばれる) では、単一リソースのみを使用してメッセージを送信または受信します: JMS ブローカー、VM キュー、または JDBC 接続。 次の例は、JMS Connector の接続元およびパブリッシュ操作を使用して実行される単一リソーストランザクションが含まれるフローを示しています。 ```xml ```
jms:listener​ 提供元と ​jms:publish​ 操作の両方で同じ接続設定を使用する必要があります。これは、このメカニズムが 1 つのリソースを管理することを目的としているためです。
上記の例では、​`test.in`​ キューからメッセージを受信する JMS イベントソースとメッセージを ​`test.out`​ キューに送信する別の JMS 操作を定義しています。​`transactionalAction`​ 属性によって、Mule がトランザクションを開始する方法が決まります。このフロー内で、Mule は受信したすべてのメッセージのトランザクションを開始 (​`jms:listener`​ 提供元) し、送信するすべてのメッセージについて進行中のトランザクションを必ず結合します (​`jms:publish`​ 操作)。 Mule は、完全なフローを通じて正常に渡されるメッセージのみをコミットします。フローのどこかの時点でメッセージがエラーをスローし、そのエラーが伝播される場合 (つまり、​`on-error-continue`​ で処理されない)、Mule はトランザクションをロールバックします。エラーの処理方法についての詳細は、​[「On Error スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/on-error-scope-concept)​を参照してください。 ## [](#ネストされたトランザクション)ネストされたトランザクション ネストされたトランザクションは、単一リソーストランザクションでは使用できません。詳細は、​[「XA トランザクション」](https://docs.mulesoft.com/jp/mule-runtime/4.8/xa-transactions#nested-transactions)​を参照してください。 ## [](#関連情報)関連情報 - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.8/transaction-management) # 単一リソーストランザクション 単一リソーストランザクション (単一トランザクションやローカルトランザクションとも呼ばれる) では、単一リソースのみを使用してメッセージを送信または受信します: JMS ブローカー、VM キュー、または JDBC 接続。 次の例は、JMS Connector の接続元およびパブリッシュ操作を使用して実行される単一リソーストランザクションが含まれるフローを示しています。 ```xml ```
jms:listener​ 提供元と ​jms:publish​ 操作の両方で同じ接続設定を使用する必要があります。これは、このメカニズムが 1 つのリソースを管理することを目的としているためです。
上記の例では、​`test.in`​ キューからメッセージを受信する JMS イベントソースとメッセージを ​`test.out`​ キューに送信する別の JMS 操作を定義しています。​`transactionalAction`​ 属性によって、Mule がトランザクションを開始する方法が決まります。このフロー内で、Mule は受信したすべてのメッセージのトランザクションを開始 (​`jms:listener`​ 提供元) し、送信するすべてのメッセージについて進行中のトランザクションを必ず結合します (​`jms:publish`​ 操作)。 Mule は、完全なフローを通じて正常に渡されるメッセージのみをコミットします。フローのどこかの時点でメッセージがエラーをスローし、そのエラーが伝播される場合 (つまり、​`on-error-continue`​ で処理されない)、Mule はトランザクションをロールバックします。エラーの処理方法についての詳細は、​[「On Error スコープ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/on-error-scope-concept)​を参照してください。 ## [](#ネストされたトランザクション)ネストされたトランザクション ネストされたトランザクションは、単一リソーストランザクションでは使用できません。詳細は、​[「XA トランザクション」](https://docs.mulesoft.com/jp/mule-runtime/4.9/xa-transactions#nested-transactions)​を参照してください。 ## [](#関連情報)関連情報 - [トランザクションの管理](https://docs.mulesoft.com/jp/mule-runtime/4.9/transaction-management) # 反復可能ストリームと反復不可能ストリーム フローのパフォーマンスを最大限に引き出すには、ストリーミング戦略を理解して、自分のユースケースに最適な戦略を選ぶことが鍵となります。 - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) または - 反復可能ストリーム (ペイロードを複数回読み取る) ## [](#反復不可能ストリーム)反復不可能ストリーム 反復不可能戦略は、反復可能ストリームを無効化します。ユースケースでペイロードを 1 回しか読み取る必要がない場合は、コネクタで ​`non-repeatable-stream`​ パラメーターを使用してください。次の例を見てください。 ```xml ``` ## [](#反復可能ストリーム)反復可能ストリーム ユースケースでペイロードを複数回、または並行して読み取る必要がある場合には、以下の戦略のいずれかを選択できます。 - ファイルに格納されたストリーミング - メモリ内ストリーミング ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルに格納された反復可能ストリーム戦略を使用する場合は、バッファサイズ ​`inMemorySize`​ を自分のユースケースに合わせてカスタマイズすることで、パフォーマンスを最適化します。 - バッファサイズを大きくすると、Mule がバッファをディスクに書き込む回数を減らせます。これによってパフォーマンスが高まりますが、より多くのメモリが必要になるため、アプリケーションが処理できる同時要求数が制限されます。 - バッファサイズを小さくすると、メモリの負荷は低減しますが、応答時間が長くなります。 次の例では、サイズが約 1 MB であるファイル用に、ファイルに格納された反復可能ストリームのバッファサイズを設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内の反復可能ストリーム戦略を使用する場合は、ファイルサイズの大小に合わせて以下を設定することでバッファサイズを設定します。 - `initialBufferSize` 初期サイズ - `bufferSizeIncrement` バッファを増やすレート。 - `maxInMemorySize` 最大バッファサイズ。 - `bufferUnit` バッファサイズ値の測定単位。 ペイロードのサイズと予想される同時実行数に基づいて、メモリ内のバッファサイズを調整します (デフォルトは 512KB)。 次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.3/streaming-about) # 反復可能ストリームと反復不可能ストリーム フローのパフォーマンスを最大限に引き出すには、ストリーミング戦略を理解して、自分のユースケースに最適な戦略を選ぶことが鍵となります。 - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) または - 反復可能ストリーム (ペイロードを複数回読み取る) ## [](#反復不可能ストリーム)反復不可能ストリーム 反復不可能戦略は、反復可能ストリームを無効化します。ユースケースでペイロードを 1 回しか読み取る必要がない場合は、コネクタで ​`non-repeatable-stream`​ パラメーターを使用してください。次の例を見てください。 ```xml ``` ## [](#反復可能ストリーム)反復可能ストリーム ユースケースでペイロードを複数回、または並行して読み取る必要がある場合には、以下の戦略のいずれかを選択できます。 - ファイルに格納されたストリーミング - メモリ内ストリーミング ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルに格納された反復可能ストリーム戦略を使用する場合は、バッファサイズ ​`inMemorySize`​ を自分のユースケースに合わせてカスタマイズすることで、パフォーマンスを最適化します。 - バッファサイズを大きくすると、Mule がバッファをディスクに書き込む回数を減らせます。これによってパフォーマンスが高まりますが、より多くのメモリが必要になるため、アプリケーションが処理できる同時要求数が制限されます。 - バッファサイズを小さくすると、メモリの負荷は低減しますが、応答時間が長くなります。 次の例では、サイズが約 1 MB であるファイル用に、ファイルに格納された反復可能ストリームのバッファサイズを設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内の反復可能ストリーム戦略を使用する場合は、ファイルサイズの大小に合わせて以下を設定することでバッファサイズを設定します。 - `initialBufferSize` 初期サイズ - `bufferSizeIncrement` バッファを増やすレート。 - `maxInMemorySize` 最大バッファサイズ。 - `bufferUnit` バッファサイズ値の測定単位。 ペイロードのサイズと予想される同時実行数に基づいて、メモリ内のバッファサイズを調整します (デフォルトは 512KB)。 次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.4/streaming-about) # 反復可能ストリームと反復不可能ストリーム フローのパフォーマンスを最大限に引き出すには、ストリーミング戦略を理解して、自分のユースケースに最適な戦略を選ぶことが鍵となります。 - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) または - 反復可能ストリーム (ペイロードを複数回読み取る) ## [](#反復不可能ストリーム)反復不可能ストリーム 反復不可能戦略は、反復可能ストリームを無効化します。ユースケースでペイロードを 1 回しか読み取る必要がない場合は、コネクタで ​`non-repeatable-stream`​ パラメーターを使用してください。次の例を見てください。 ```xml ``` ## [](#反復可能ストリーム)反復可能ストリーム ユースケースでペイロードを複数回、または並行して読み取る必要がある場合には、以下の戦略のいずれかを選択できます。 - ファイルに格納されたストリーミング - メモリ内ストリーミング ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルに格納された反復可能ストリーム戦略を使用する場合は、バッファサイズ ​`inMemorySize`​ を自分のユースケースに合わせてカスタマイズすることで、パフォーマンスを最適化します。 - バッファサイズを大きくすると、Mule がバッファをディスクに書き込む回数を減らせます。これによってパフォーマンスが高まりますが、より多くのメモリが必要になるため、アプリケーションが処理できる同時要求数が制限されます。 - バッファサイズを小さくすると、メモリの負荷は低減しますが、応答時間が長くなります。 次の例では、サイズが約 1 MB であるファイル用に、ファイルに格納された反復可能ストリームのバッファサイズを設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内の反復可能ストリーム戦略を使用する場合は、ファイルサイズの大小に合わせて以下を設定することでバッファサイズを設定します。 - `initialBufferSize` 初期サイズ - `bufferSizeIncrement` バッファを増やすレート。 - `maxInMemorySize` 最大バッファサイズ。 - `bufferUnit` バッファサイズ値の測定単位。 ペイロードのサイズと予想される同時実行数に基づいて、メモリ内のバッファサイズを調整します (デフォルトは 512KB)。 次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.5/streaming-about) # 反復可能ストリームと反復不可能ストリーム フローのパフォーマンスを最大限に引き出すには、ストリーミング戦略を理解して、自分のユースケースに最適な戦略を選ぶことが鍵となります。 - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) または - 反復可能ストリーム (ペイロードを複数回読み取る) ## [](#反復不可能ストリーム)反復不可能ストリーム 反復不可能戦略は、反復可能ストリームを無効化します。ユースケースでペイロードを 1 回しか読み取る必要がない場合は、コネクタで ​`non-repeatable-stream`​ パラメーターを使用してください。次の例を見てください。 ```xml ``` ## [](#反復可能ストリーム)反復可能ストリーム ユースケースでペイロードを複数回、または並行して読み取る必要がある場合には、以下の戦略のいずれかを選択できます。 - ファイルに格納されたストリーミング - メモリ内ストリーミング ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルに格納された反復可能ストリーム戦略を使用する場合は、バッファサイズ ​`inMemorySize`​ を自分のユースケースに合わせてカスタマイズすることで、パフォーマンスを最適化します。 - バッファサイズを大きくすると、Mule がバッファをディスクに書き込む回数を減らせます。これによってパフォーマンスが高まりますが、より多くのメモリが必要になるため、アプリケーションが処理できる同時要求数が制限されます。 - バッファサイズを小さくすると、メモリの負荷は低減しますが、応答時間が長くなります。 次の例では、サイズが約 1 MB であるファイル用に、ファイルに格納された反復可能ストリームのバッファサイズを設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内の反復可能ストリーム戦略を使用する場合は、ファイルサイズの大小に合わせて以下を設定することでバッファサイズを設定します。 - `initialBufferSize` 初期サイズ - `bufferSizeIncrement` バッファを増やすレート。 - `maxInMemorySize` 最大バッファサイズ。 - `bufferUnit` バッファサイズ値の測定単位。 ペイロードのサイズと予想される同時実行数に基づいて、メモリ内のバッファサイズを調整します (デフォルトは 512KB)。 次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.6/streaming-about) # 反復可能ストリームと反復不可能ストリーム フローのパフォーマンスを最大限に引き出すには、ストリーミング戦略を理解して、自分のユースケースに最適な戦略を選ぶことが鍵となります。 - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) または - 反復可能ストリーム (ペイロードを複数回読み取る) ## [](#反復不可能ストリーム)反復不可能ストリーム 反復不可能戦略は、反復可能ストリームを無効化します。ユースケースでペイロードを 1 回しか読み取る必要がない場合は、コネクタで ​`non-repeatable-stream`​ パラメーターを使用してください。次の例を見てください。 ```xml ``` ## [](#反復可能ストリーム)反復可能ストリーム ユースケースでペイロードを複数回、または並行して読み取る必要がある場合には、以下の戦略のいずれかを選択できます。 - ファイルに格納されたストリーミング - メモリ内ストリーミング ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルに格納された反復可能ストリーム戦略を使用する場合は、バッファサイズ ​`inMemorySize`​ を自分のユースケースに合わせてカスタマイズすることで、パフォーマンスを最適化します。 - バッファサイズを大きくすると、Mule がバッファをディスクに書き込む回数を減らせます。これによってパフォーマンスが高まりますが、より多くのメモリが必要になるため、アプリケーションが処理できる同時要求数が制限されます。 - バッファサイズを小さくすると、メモリの負荷は低減しますが、応答時間が長くなります。 次の例では、サイズが約 1 MB であるファイル用に、ファイルに格納された反復可能ストリームのバッファサイズを設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内の反復可能ストリーム戦略を使用する場合は、ファイルサイズの大小に合わせて以下を設定することでバッファサイズを設定します。 - `initialBufferSize` 初期サイズ - `bufferSizeIncrement` バッファを増やすレート。 - `maxInMemorySize` 最大バッファサイズ。 - `bufferUnit` バッファサイズ値の測定単位。 ペイロードのサイズと予想される同時実行数に基づいて、メモリ内のバッファサイズを調整します (デフォルトは 512KB)。 次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.7/streaming-about) # 反復可能ストリームと反復不可能ストリーム フローのパフォーマンスを最大限に引き出すには、ストリーミング戦略を理解して、自分のユースケースに最適な戦略を選ぶことが鍵となります。 - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) または - 反復可能ストリーム (ペイロードを複数回読み取る) ## [](#反復不可能ストリーム)反復不可能ストリーム 反復不可能戦略は、反復可能ストリームを無効化します。ユースケースでペイロードを 1 回しか読み取る必要がない場合は、コネクタで ​`non-repeatable-stream`​ パラメーターを使用してください。次の例を見てください。 ```xml ``` ## [](#反復可能ストリーム)反復可能ストリーム ユースケースでペイロードを複数回、または並行して読み取る必要がある場合には、以下の戦略のいずれかを選択できます。 - ファイルに格納されたストリーミング - メモリ内ストリーミング ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルに格納された反復可能ストリーム戦略を使用する場合は、バッファサイズ ​`inMemorySize`​ を自分のユースケースに合わせてカスタマイズすることで、パフォーマンスを最適化します。 - バッファサイズを大きくすると、Mule がバッファをディスクに書き込む回数を減らせます。これによってパフォーマンスが高まりますが、より多くのメモリが必要になるため、アプリケーションが処理できる同時要求数が制限されます。 - バッファサイズを小さくすると、メモリの負荷は低減しますが、応答時間が長くなります。 次の例では、サイズが約 1 MB であるファイル用に、ファイルに格納された反復可能ストリームのバッファサイズを設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内の反復可能ストリーム戦略を使用する場合は、ファイルサイズの大小に合わせて以下を設定することでバッファサイズを設定します。 - `initialBufferSize` 初期サイズ - `bufferSizeIncrement` バッファを増やすレート。 - `maxInMemorySize` 最大バッファサイズ。 - `bufferUnit` バッファサイズ値の測定単位。 ペイロードのサイズと予想される同時実行数に基づいて、メモリ内のバッファサイズを調整します (デフォルトは 512KB)。 次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.8/streaming-about) # 反復可能ストリームと反復不可能ストリーム フローのパフォーマンスを最大限に引き出すには、ストリーミング戦略を理解して、自分のユースケースに最適な戦略を選ぶことが鍵となります。 - 反復不可能ストリーム (ペイロードを 1 回だけ読み取る) または - 反復可能ストリーム (ペイロードを複数回読み取る) ## [](#反復不可能ストリーム)反復不可能ストリーム 反復不可能戦略は、反復可能ストリームを無効化します。ユースケースでペイロードを 1 回しか読み取る必要がない場合は、コネクタで ​`non-repeatable-stream`​ パラメーターを使用してください。次の例を見てください。 ```xml ``` ## [](#反復可能ストリーム)反復可能ストリーム ユースケースでペイロードを複数回、または並行して読み取る必要がある場合には、以下の戦略のいずれかを選択できます。 - ファイルに格納されたストリーミング - メモリ内ストリーミング ### [](#ファイルに格納された反復可能ストリーム)ファイルに格納された反復可能ストリーム ファイルに格納された反復可能ストリーム戦略を使用する場合は、バッファサイズ ​`inMemorySize`​ を自分のユースケースに合わせてカスタマイズすることで、パフォーマンスを最適化します。 - バッファサイズを大きくすると、Mule がバッファをディスクに書き込む回数を減らせます。これによってパフォーマンスが高まりますが、より多くのメモリが必要になるため、アプリケーションが処理できる同時要求数が制限されます。 - バッファサイズを小さくすると、メモリの負荷は低減しますが、応答時間が長くなります。 次の例では、サイズが約 1 MB であるファイル用に、ファイルに格納された反復可能ストリームのバッファサイズを設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ### [](#メモリ内の反復可能ストリーム)メモリ内の反復可能ストリーム メモリ内の反復可能ストリーム戦略を使用する場合は、ファイルサイズの大小に合わせて以下を設定することでバッファサイズを設定します。 - `initialBufferSize` 初期サイズ - `bufferSizeIncrement` バッファを増やすレート。 - `maxInMemorySize` 最大バッファサイズ。 - `bufferUnit` バッファサイズ値の測定単位。 ペイロードのサイズと予想される同時実行数に基づいて、メモリ内のバッファサイズを調整します (デフォルトは 512KB)。 次の例では、メモリ内の反復可能ストリームの初期バッファサイズを 512 KB、拡張単位を 256 KB、そしてメモリに読み込めるコンテンツの最大サイズを 2000 KB (2 MB) に設定しています。 ```xml ``` ユースケースで最適なバッファサイズは、必ずパフォーマンステストを実施して決めてください。 ## [](#関連情報)関連情報 - [Mule アプリケーションでのストリーミング](https://docs.mulesoft.com/jp/mule-runtime/4.9/streaming-about) # 変換コードの個別ファイルへの移動 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントの DataWeave コードは Mule XML ファイル内に記述されます。このコードを個別のファイル (​`.dwl`​) に記述して、XML から参照することもできます。これらのファイルは、ビルド時に Mule アプリケーションと一緒にバンドルされます。 DataWeave コードを ​`.dwl`​ ファイルにエクスポートするには次の手順を実行します。 1. **\[Edit Current Target (現在の対象を編集)\]**​ ボタンをクリックします。 ![対象の編集](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/dw-multiple-outputs-edit.png) 2. **\[File (ファイル)\]**​ ラジオボタンを選択します。 ![外部ファイル 2](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/dataweave-externalfile2.png) - `.dwl`​ ファイルの名前を入力します。 - **\[OK\]**​ をクリックします。 DataWeave コードが格納されたファイルがプロジェクトの ​`src/main/resources`​ フォルダーに作成されます。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about) # 変換コードの個別ファイルへの移動 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントの DataWeave コードは Mule XML ファイル内に記述されます。このコードを個別のファイル (​`.dwl`​) に記述して、XML から参照することもできます。これらのファイルは、ビルド時に Mule アプリケーションと一緒にバンドルされます。 DataWeave コードを ​`.dwl`​ ファイルにエクスポートするには次の手順を実行します。 1. **\[Edit Current Target (現在の対象を編集)\]**​ ボタンをクリックします。 ![対象の編集](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/dw-multiple-outputs-edit.png) 2. **\[File (ファイル)\]**​ ラジオボタンを選択します。 ![外部ファイル 2](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/dataweave-externalfile2.png) - `.dwl`​ ファイルの名前を入力します。 - **\[OK\]**​ をクリックします。 DataWeave コードが格納されたファイルがプロジェクトの ​`src/main/resources`​ フォルダーに作成されます。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about) # 変換コードの個別ファイルへの移動 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントの DataWeave コードは Mule XML ファイル内に記述されます。このコードを個別のファイル (​`.dwl`​) に記述して、XML から参照することもできます。これらのファイルは、ビルド時に Mule アプリケーションと一緒にバンドルされます。 DataWeave コードを ​`.dwl`​ ファイルにエクスポートするには次の手順を実行します。 1. **\[Edit Current Target (現在の対象を編集)\]**​ ボタンをクリックします。 ![対象の編集](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/dw-multiple-outputs-edit.png) 2. **\[File (ファイル)\]**​ ラジオボタンを選択します。 ![外部ファイル 2](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/dataweave-externalfile2.png) - `.dwl`​ ファイルの名前を入力します。 - **\[OK\]**​ をクリックします。 DataWeave コードが格納されたファイルがプロジェクトの ​`src/main/resources`​ フォルダーに作成されます。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about) # 変換コードの個別ファイルへの移動 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントの DataWeave コードは Mule XML ファイル内に記述されます。このコードを個別のファイル (​`.dwl`​) に記述して、XML から参照することもできます。これらのファイルは、ビルド時に Mule アプリケーションと一緒にバンドルされます。 DataWeave コードを ​`.dwl`​ ファイルにエクスポートするには次の手順を実行します。 1. **\[Edit Current Target (現在の対象を編集)\]**​ ボタンをクリックします。 ![対象の編集](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/dw-multiple-outputs-edit.png) 2. **\[File (ファイル)\]**​ ラジオボタンを選択します。 ![外部ファイル 2](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/dataweave-externalfile2.png) - `.dwl`​ ファイルの名前を入力します。 - **\[OK\]**​ をクリックします。 DataWeave コードが格納されたファイルがプロジェクトの ​`src/main/resources`​ フォルダーに作成されます。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about) # 変換コードの個別ファイルへの移動 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントの DataWeave コードは Mule XML ファイル内に記述されます。このコードを個別のファイル (​`.dwl`​) に記述して、XML から参照することもできます。これらのファイルは、ビルド時に Mule アプリケーションと一緒にバンドルされます。 DataWeave コードを ​`.dwl`​ ファイルにエクスポートするには次の手順を実行します。 1. **\[Edit Current Target (現在の対象を編集)\]**​ ボタンをクリックします。 ![Transform Message コンポーネントの編集アイコン](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/dw-multiple-outputs-edit.png) 2. **\[File (ファイル)\]**​ ラジオボタンを選択します。 ![ソースコードを選択するオプションが含まれる対象出力ペイロード](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/dataweave-externalfile2.png) - `.dwl`​ ファイルの名前を入力します。 - **\[OK\]**​ をクリックします。 DataWeave コードが格納されたファイルがプロジェクトの ​`src/main/resources`​ フォルダーに作成されます。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about) # 変換コードの個別ファイルへの移動 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントの DataWeave コードは Mule XML ファイル内に記述されます。このコードを個別のファイル (​`.dwl`​) に記述して、XML から参照することもできます。これらのファイルは、ビルド時に Mule アプリケーションと一緒にバンドルされます。 DataWeave コードを ​`.dwl`​ ファイルにエクスポートするには次の手順を実行します。 1. **\[Edit Current Target (現在の対象を編集)\]**​ ボタンをクリックします。 ![Transform Message コンポーネントの編集アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/dw-multiple-outputs-edit.png) 2. **\[File (ファイル)\]**​ ラジオボタンを選択します。 ![ソースコードを選択するオプションが含まれる対象出力ペイロード](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/dataweave-externalfile2.png) - `.dwl`​ ファイルの名前を入力します。 - **\[OK\]**​ をクリックします。 DataWeave コードが格納されたファイルがプロジェクトの ​`src/main/resources`​ フォルダーに作成されます。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about) # 変換コードの個別ファイルへの移動 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントの DataWeave コードは Mule XML ファイル内に記述されます。このコードを個別のファイル (​`.dwl`​) に記述して、XML から参照することもできます。これらのファイルは、ビルド時に Mule アプリケーションと一緒にバンドルされます。 DataWeave コードを ​`.dwl`​ ファイルにエクスポートするには次の手順を実行します。 1. **\[Edit Current Target (現在の対象を編集)\]**​ ボタンをクリックします。 ![Transform Message コンポーネントの編集アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/dw-multiple-outputs-edit.png) 2. **\[File (ファイル)\]**​ ラジオボタンを選択します。 ![ソースコードを選択するオプションが含まれる対象出力ペイロード](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/dataweave-externalfile2.png) - `.dwl`​ ファイルの名前を入力します。 - **\[OK\]**​ をクリックします。 DataWeave コードが格納されたファイルがプロジェクトの ​`src/main/resources`​ フォルダーに作成されます。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about) # 変換の入力構造と出力構造の定義 (Anypoint Studio) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform Message コンポーネントで定義する必要があります。 DataWeave コードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素を直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 コンポーネントの入力と出力が設定から予測できる場合は、フローの残りの部分に公開されます。たとえば、特定の操作を実行するように Salesforce Connector が設定されている場合、その出力構造は既知であるため、公開されます。 2. 特定のコンポーネントの入力または出力が予測できない場合、主要なコンポーネントの出力と入力を、それぞれの \[Metadata (メタデータ)\] タブで手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。 ## [](#transform-message-コンポーネントでのデータ構造の定義)Transform Message コンポーネントでのデータ構造の定義 1. 入力または出力ツリーのルートを右クリックして、\[Set Metadata (メタデータの設定)\] を選択します。 2. データ構造を手動で定義します。 ## [](#xml-でのデータ構造の定義)XML でのデータ構造の定義 [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-dataweave-xml-reference)​を参照してください。 ## [](#リーダーの設定)リーダーの設定 入力を特別な方法で解析する必要がある場合は、リーダーオブジェクトの特定のプロパティをセットアップできます。各入力形式では、設定できるプロパティが異なります (セットアップできるプロパティがない場合もあります)。これらを設定する方法は次の 2 つです。 - \[Metadata (メタデータ)\] タブを使用してフロー上の他のコンポーネントを設定します。 - Transform Message コンポーネントの入力ペインのルートをクリックして、​**\[Reader Configuration (リーダーの設定)\]**​ を選択します。 ![リーダーの設定](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/dw-reader-configuration-select.png)
このオプションは、選択したデータ型形式でリーダープロパティを設定できる場合にのみ表示されます。ペイロードが ​unknown​ 型である場合は、先に型を変更する必要があります。
各形式の \[Reader Configuration (リーダーの設定)\] で設定できるプロパティの詳細については、対応する​**リーダーのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats#xml) - [フラットファイル](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats#flat-file)
この情報は、Mule プロジェクトの XML ソースのプロパティでも追加できます。
## [](#ライターの設定)ライターの設定 出力を特別な方法で構築する必要がある場合は、ライターオブジェクトの特定のプロパティをセットアップできます。各出力形式には異なる設定プロパティがあります (プロパティがない形式もあります)。 これらのプロパティは、DataWeave コードの ​`%output`​ ディレクティブで書き込む必要があります。 各形式の \[Writer Configuration (ライターの設定)\] で設定できるプロパティの詳細については、対応する​**ライターのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats#xml) - [JSON](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats#json) - [フラットファイル](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats#flat-file) ## [](#関連情報)関連情報 [ワークフロー: Anypoint Studio UI でのマッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) [DataWeave 型](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-types) [サポートされるデータ形式](https://docs.mulesoft.com/jp/dataweave/2.3/dataweave-formats) [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-dataweave-xml-reference) # 変換の入力構造と出力構造の定義 (Anypoint Studio) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform Message コンポーネントで定義する必要があります。 DataWeave コードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素を直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 コンポーネントの入力と出力が設定から予測できる場合は、フローの残りの部分に公開されます。たとえば、特定の操作を実行するように Salesforce Connector が設定されている場合、その出力構造は既知であるため、公開されます。 2. 特定のコンポーネントの入力または出力が予測できない場合、主要なコンポーネントの出力と入力を、それぞれの \[Metadata (メタデータ)\] タブで手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。 ## [](#transform-message-コンポーネントでのデータ構造の定義)Transform Message コンポーネントでのデータ構造の定義 1. 入力または出力ツリーのルートを右クリックして、\[Set Metadata (メタデータの設定)\] を選択します。 2. データ構造を手動で定義します。 ## [](#xml-でのデータ構造の定義)XML でのデータ構造の定義 [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-dataweave-xml-reference)​を参照してください。 ## [](#リーダーの設定)リーダーの設定 入力を特別な方法で解析する必要がある場合は、リーダーオブジェクトの特定のプロパティをセットアップできます。各入力形式では、設定できるプロパティが異なります (セットアップできるプロパティがない場合もあります)。これらを設定する方法は次の 2 つです。 - \[Metadata (メタデータ)\] タブを使用してフロー上の他のコンポーネントを設定します。 - Transform Message コンポーネントの入力ペインのルートをクリックして、​**\[Reader Configuration (リーダーの設定)\]**​ を選択します。 ![リーダーの設定](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/dw-reader-configuration-select.png)
このオプションは、選択したデータ型形式でリーダープロパティを設定できる場合にのみ表示されます。ペイロードが ​unknown​ 型である場合は、先に型を変更する必要があります。
各形式の \[Reader Configuration (リーダーの設定)\] で設定できるプロパティの詳細については、対応する​**リーダーのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file)
この情報は、Mule プロジェクトの XML ソースのプロパティでも追加できます。
## [](#ライターの設定)ライターの設定 出力を特別な方法で構築する必要がある場合は、ライターオブジェクトの特定のプロパティをセットアップできます。各出力形式には異なる設定プロパティがあります (プロパティがない形式もあります)。 これらのプロパティは、DataWeave コードの ​`%output`​ ディレクティブで書き込む必要があります。 各形式の \[Writer Configuration (ライターの設定)\] で設定できるプロパティの詳細については、対応する​**ライターのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [JSON](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#json) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file) ## [](#関連情報)関連情報 [ワークフロー: Anypoint Studio UI でのマッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) [DataWeave 型](https://docs.mulesoft.com/dataweave/latest/dataweave-types) [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-dataweave-xml-reference) # 変換の入力構造と出力構造の定義 (Anypoint Studio) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform Message コンポーネントで定義する必要があります。 DataWeave コードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素を直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 コンポーネントの入力と出力が設定から予測できる場合は、フローの残りの部分に公開されます。たとえば、特定の操作を実行するように Salesforce Connector が設定されている場合、その出力構造は既知であるため、公開されます。 2. 特定のコンポーネントの入力または出力が予測できない場合、主要なコンポーネントの出力と入力を、それぞれの \[Metadata (メタデータ)\] タブで手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。 ## [](#transform-message-コンポーネントでのデータ構造の定義)Transform Message コンポーネントでのデータ構造の定義 1. 入力または出力ツリーのルートを右クリックして、\[Set Metadata (メタデータの設定)\] を選択します。 2. データ構造を手動で定義します。 ## [](#xml-でのデータ構造の定義)XML でのデータ構造の定義 [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-dataweave-xml-reference)​を参照してください。 ## [](#リーダーの設定)リーダーの設定 入力を特別な方法で解析する必要がある場合は、リーダーオブジェクトの特定のプロパティをセットアップできます。各入力形式では、設定できるプロパティが異なります (セットアップできるプロパティがない場合もあります)。これらを設定する方法は次の 2 つです。 - \[Metadata (メタデータ)\] タブを使用してフロー上の他のコンポーネントを設定します。 - Transform Message コンポーネントの入力ペインのルートをクリックして、​**\[Reader Configuration (リーダーの設定)\]**​ を選択します。 ![リーダーの設定](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/dw-reader-configuration-select.png)
このオプションは、選択したデータ型形式でリーダープロパティを設定できる場合にのみ表示されます。ペイロードが ​unknown​ 型である場合は、先に型を変更する必要があります。
各形式の \[Reader Configuration (リーダーの設定)\] で設定できるプロパティの詳細については、対応する​**リーダーのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file)
この情報は、Mule プロジェクトの XML ソースのプロパティでも追加できます。
## [](#ライターの設定)ライターの設定 出力を特別な方法で構築する必要がある場合は、ライターオブジェクトの特定のプロパティをセットアップできます。各出力形式には異なる設定プロパティがあります (プロパティがない形式もあります)。 これらのプロパティは、DataWeave コードの ​`%output`​ ディレクティブで書き込む必要があります。 各形式の \[Writer Configuration (ライターの設定)\] で設定できるプロパティの詳細については、対応する​**ライターのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [JSON](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#json) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file) ## [](#関連情報)関連情報 [ワークフロー: Anypoint Studio UI でのマッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) [DataWeave 型](https://docs.mulesoft.com/dataweave/latest/dataweave-types) [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-dataweave-xml-reference) # 変換の入力構造と出力構造の定義 (Anypoint Studio) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform Message コンポーネントで定義する必要があります。 DataWeave コードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素を直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 コンポーネントの入力と出力が設定から予測できる場合は、フローの残りの部分に公開されます。たとえば、特定の操作を実行するように Salesforce Connector が設定されている場合、その出力構造は既知であるため、公開されます。 2. 特定のコンポーネントの入力または出力が予測できない場合、主要なコンポーネントの出力と入力を、それぞれの \[Metadata (メタデータ)\] タブで手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。 ## [](#transform-message-コンポーネントでのデータ構造の定義)Transform Message コンポーネントでのデータ構造の定義 1. 入力または出力ツリーのルートを右クリックして、\[Set Metadata (メタデータの設定)\] を選択します。 2. データ構造を手動で定義します。 ## [](#xml-でのデータ構造の定義)XML でのデータ構造の定義 [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-dataweave-xml-reference)​を参照してください。 ## [](#リーダーの設定)リーダーの設定 入力を特別な方法で解析する必要がある場合は、リーダーオブジェクトの特定のプロパティをセットアップできます。各入力形式では、設定できるプロパティが異なります (セットアップできるプロパティがない場合もあります)。これらを設定する方法は次の 2 つです。 - \[Metadata (メタデータ)\] タブを使用してフロー上の他のコンポーネントを設定します。 - Transform Message コンポーネントの入力ペインのルートをクリックして、​**\[Reader Configuration (リーダーの設定)\]**​ を選択します。 ![リーダーの設定](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/dw-reader-configuration-select.png)
このオプションは、選択したデータ型形式でリーダープロパティを設定できる場合にのみ表示されます。ペイロードが ​unknown​ 型である場合は、先に型を変更する必要があります。
各形式の \[Reader Configuration (リーダーの設定)\] で設定できるプロパティの詳細については、対応する​**リーダーのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file)
この情報は、Mule プロジェクトの XML ソースのプロパティでも追加できます。
## [](#ライターの設定)ライターの設定 出力を特別な方法で構築する必要がある場合は、ライターオブジェクトの特定のプロパティをセットアップできます。各出力形式には異なる設定プロパティがあります (プロパティがない形式もあります)。 これらのプロパティは、DataWeave コードの ​`%output`​ ディレクティブで書き込む必要があります。 各形式の \[Writer Configuration (ライターの設定)\] で設定できるプロパティの詳細については、対応する​**ライターのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [JSON](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#json) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file) ## [](#関連情報)関連情報 [ワークフロー: Anypoint Studio UI でのマッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) [DataWeave 型](https://docs.mulesoft.com/dataweave/latest/dataweave-types) [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-dataweave-xml-reference) # 変換の入力構造と出力構造の定義 (Anypoint Studio) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform Message コンポーネントで定義する必要があります。 DataWeave コードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素を直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 コンポーネントの入力と出力が設定から予測できる場合は、フローの残りの部分に公開されます。たとえば、特定の操作を実行するように Salesforce Connector が設定されている場合、その出力構造は既知であるため、公開されます。 2. 特定のコンポーネントの入力または出力が予測できない場合、主要なコンポーネントの出力と入力を、それぞれの \[Metadata (メタデータ)\] タブで手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。 ## [](#transform-message-コンポーネントでのデータ構造の定義)Transform Message コンポーネントでのデータ構造の定義 1. 入力または出力ツリーのルートを右クリックして、\[Set Metadata (メタデータの設定)\] を選択します。 2. データ構造を手動で定義します。 ## [](#xml-でのデータ構造の定義)XML でのデータ構造の定義 [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-dataweave-xml-reference)​を参照してください。 ## [](#リーダーの設定)リーダーの設定 入力を特別な方法で解析する必要がある場合は、リーダーオブジェクトの特定のプロパティをセットアップできます。各入力形式では、設定できるプロパティが異なります (セットアップできるプロパティがない場合もあります)。これらを設定する方法は次の 2 つです。 - \[Metadata (メタデータ)\] タブを使用してフロー上の他のコンポーネントを設定します。 - Transform Message コンポーネントの入力ペインのルートをクリックして、​**\[Reader Configuration (リーダーの設定)\]**​ を選択します。 ![Transform Message コンポーネントの \[Reader Configuration (リーダーの設定)\]](_images/dw-reader-configuration-select.png)
このオプションは、選択したデータ型形式でリーダープロパティを設定できる場合にのみ表示されます。ペイロードが ​unknown​ 型である場合は、先に型を変更する必要があります。
各形式の \[Reader Configuration (リーダーの設定)\] で設定できるプロパティの詳細については、対応する​**リーダーのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file)
この情報は、Mule プロジェクトの XML ソースのプロパティでも追加できます。
## [](#ライターの設定)ライターの設定 出力を特別な方法で構築する必要がある場合は、ライターオブジェクトの特定のプロパティをセットアップできます。各出力形式には異なる設定プロパティがあります (プロパティがない形式もあります)。 これらのプロパティは、DataWeave コードの ​`%output`​ ディレクティブで書き込む必要があります。 各形式の \[Writer Configuration (ライターの設定)\] で設定できるプロパティの詳細については、対応する​**ライターのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [JSON](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#json) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file) ## [](#関連情報)関連情報 [ワークフロー: Anypoint Studio UI でのマッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) [DataWeave 型](https://docs.mulesoft.com/dataweave/latest/dataweave-types) [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-dataweave-xml-reference) # 変換の入力構造と出力構造の定義 (Anypoint Studio) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform Message コンポーネントで定義する必要があります。 DataWeave コードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素を直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 コンポーネントの入力と出力が設定から予測できる場合は、フローの残りの部分に公開されます。たとえば、特定の操作を実行するように Salesforce Connector が設定されている場合、その出力構造は既知であるため、公開されます。 2. 特定のコンポーネントの入力または出力が予測できない場合、主要なコンポーネントの出力と入力を、それぞれの \[Metadata (メタデータ)\] タブで手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。 ## [](#transform-message-コンポーネントでのデータ構造の定義)Transform Message コンポーネントでのデータ構造の定義 1. 入力または出力ツリーのルートを右クリックして、\[Set Metadata (メタデータの設定)\] を選択します。 2. データ構造を手動で定義します。 ## [](#xml-でのデータ構造の定義)XML でのデータ構造の定義 [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-dataweave-xml-reference)​を参照してください。 ## [](#リーダーの設定)リーダーの設定 入力を特別な方法で解析する必要がある場合は、リーダーオブジェクトの特定のプロパティをセットアップできます。各入力形式では、設定できるプロパティが異なります (セットアップできるプロパティがない場合もあります)。これらを設定する方法は次の 2 つです。 - \[Metadata (メタデータ)\] タブを使用してフロー上の他のコンポーネントを設定します。 - Transform Message コンポーネントの入力ペインのルートをクリックして、​**\[Reader Configuration (リーダーの設定)\]**​ を選択します。 ![Transform Message コンポーネントの \[Reader Configuration (リーダーの設定)\]](_images/dw-reader-configuration-select.png)
このオプションは、選択したデータ型形式でリーダープロパティを設定できる場合にのみ表示されます。ペイロードが ​unknown​ 型である場合は、先に型を変更する必要があります。
各形式の \[Reader Configuration (リーダーの設定)\] で設定できるプロパティの詳細については、対応する​**リーダーのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file)
この情報は、Mule プロジェクトの XML ソースのプロパティでも追加できます。
## [](#ライターの設定)ライターの設定 出力を特別な方法で構築する必要がある場合は、ライターオブジェクトの特定のプロパティをセットアップできます。各出力形式には異なる設定プロパティがあります (プロパティがない形式もあります)。 これらのプロパティは、DataWeave コードの ​`%output`​ ディレクティブで書き込む必要があります。 各形式の \[Writer Configuration (ライターの設定)\] で設定できるプロパティの詳細については、対応する​**ライターのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [JSON](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#json) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file) ## [](#関連情報)関連情報 [ワークフロー: Anypoint Studio UI でのマッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) [DataWeave 型](https://docs.mulesoft.com/dataweave/latest/dataweave-types) [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-dataweave-xml-reference) # 変換の入力構造と出力構造の定義 (Anypoint Studio) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform Message コンポーネントで定義する必要があります。 DataWeave コードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素を直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 コンポーネントの入力と出力が設定から予測できる場合は、フローの残りの部分に公開されます。たとえば、特定の操作を実行するように Salesforce Connector が設定されている場合、その出力構造は既知であるため、公開されます。 2. 特定のコンポーネントの入力または出力が予測できない場合、主要なコンポーネントの出力と入力を、それぞれの \[Metadata (メタデータ)\] タブで手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。 ## [](#transform-message-コンポーネントでのデータ構造の定義)Transform Message コンポーネントでのデータ構造の定義 1. 入力または出力ツリーのルートを右クリックして、\[Set Metadata (メタデータの設定)\] を選択します。 2. データ構造を手動で定義します。 ## [](#xml-でのデータ構造の定義)XML でのデータ構造の定義 [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-dataweave-xml-reference)​を参照してください。 ## [](#リーダーの設定)リーダーの設定 入力を特別な方法で解析する必要がある場合は、リーダーオブジェクトの特定のプロパティをセットアップできます。各入力形式では、設定できるプロパティが異なります (セットアップできるプロパティがない場合もあります)。これらを設定する方法は次の 2 つです。 - \[Metadata (メタデータ)\] タブを使用してフロー上の他のコンポーネントを設定します。 - Transform Message コンポーネントの入力ペインのルートをクリックして、​**\[Reader Configuration (リーダーの設定)\]**​ を選択します。 ![Transform Message コンポーネントの \[Reader Configuration (リーダーの設定)\]](_images/dw-reader-configuration-select.png)
このオプションは、選択したデータ型形式でリーダープロパティを設定できる場合にのみ表示されます。ペイロードが ​unknown​ 型である場合は、先に型を変更する必要があります。
各形式の \[Reader Configuration (リーダーの設定)\] で設定できるプロパティの詳細については、対応する​**リーダーのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file)
この情報は、Mule プロジェクトの XML ソースのプロパティでも追加できます。
## [](#ライターの設定)ライターの設定 出力を特別な方法で構築する必要がある場合は、ライターオブジェクトの特定のプロパティをセットアップできます。各出力形式には異なる設定プロパティがあります (プロパティがない形式もあります)。 これらのプロパティは、DataWeave コードの ​`%output`​ ディレクティブで書き込む必要があります。 各形式の \[Writer Configuration (ライターの設定)\] で設定できるプロパティの詳細については、対応する​**ライターのプロパティ**​セクションを参照してください。 - [CSV](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#csv) - [XML](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#xml) - [JSON](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#json) - [フラットファイル](https://docs.mulesoft.com/dataweave/latest/dataweave-formats#flat-file) ## [](#関連情報)関連情報 [ワークフロー: Anypoint Studio UI でのマッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) [DataWeave 型](https://docs.mulesoft.com/dataweave/latest/dataweave-types) [サポートされるデータ形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats) [DataWeave XML リファレンス](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-dataweave-xml-reference) # 変換の入力構造と出力構造の定義 (Design Center) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform コンポーネントで定義する必要があります。 DataWeave ソースコードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素をコードで直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 他のすべての要素が設定され、コンポーネントのデータ構造が予測できたら、構造を Transform コンポーネントに渡すことができます。 2. Design Center がデータ構造を予測できない場合は、入力データ構造と出力データ構造を手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。このペイロードの内容が分かっていれば、\[HTTP Listener (HTTP リスナー)\] ダイアログボックスの \[Input (入力)\] タブと \[Output (出力)\] タブでデータ型を設定できます。 ## [](#transform-コンポーネントでのデータ構造の定義)Transform コンポーネントでのデータ構造の定義 1. データ型設定アイコンをクリックします。 - \[Input (入力)\] ペインで、ペイロード、属性、または変数をハイライトして、\[Input (入力)\] ペインの一番下にあるデータ型設定アイコンをクリックします。 - \[Output (出力)\] ペインでは、\[Set data type (データ型の設定)\] ボタンをクリックします。すでに \[Output (出力)\] ペインにデータ型が存在する場合は、ペインの一番上にあるドロップダウンリスト矢印をクリックして、新しいデータ型を設定します。 2. サンプルまたはスキーマを提供することで、データ構造を手動で定義します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # 変換の入力構造と出力構造の定義 (Design Center) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform コンポーネントで定義する必要があります。 DataWeave ソースコードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素をコードで直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 他のすべての要素が設定され、コンポーネントのデータ構造が予測できたら、構造を Transform コンポーネントに渡すことができます。 2. Design Center がデータ構造を予測できない場合は、入力データ構造と出力データ構造を手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。このペイロードの内容が分かっていれば、\[HTTP Listener (HTTP リスナー)\] ダイアログボックスの \[Input (入力)\] タブと \[Output (出力)\] タブでデータ型を設定できます。 ## [](#transform-コンポーネントでのデータ構造の定義)Transform コンポーネントでのデータ構造の定義 1. データ型設定アイコンをクリックします。 - \[Input (入力)\] ペインで、ペイロード、属性、または変数をハイライトして、\[Input (入力)\] ペインの一番下にあるデータ型設定アイコンをクリックします。 - \[Output (出力)\] ペインでは、\[Set data type (データ型の設定)\] ボタンをクリックします。すでに \[Output (出力)\] ペインにデータ型が存在する場合は、ペインの一番上にあるドロップダウンリスト矢印をクリックして、新しいデータ型を設定します。 2. サンプルまたはスキーマを提供することで、データ構造を手動で定義します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # 変換の入力構造と出力構造の定義 (Design Center) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform コンポーネントで定義する必要があります。 DataWeave ソースコードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素をコードで直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 他のすべての要素が設定され、コンポーネントのデータ構造が予測できたら、構造を Transform コンポーネントに渡すことができます。 2. Design Center がデータ構造を予測できない場合は、入力データ構造と出力データ構造を手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。このペイロードの内容が分かっていれば、\[HTTP Listener (HTTP リスナー)\] ダイアログボックスの \[Input (入力)\] タブと \[Output (出力)\] タブでデータ型を設定できます。 ## [](#transform-コンポーネントでのデータ構造の定義)Transform コンポーネントでのデータ構造の定義 1. データ型設定アイコンをクリックします。 - \[Input (入力)\] ペインで、ペイロード、属性、または変数をハイライトして、\[Input (入力)\] ペインの一番下にあるデータ型設定アイコンをクリックします。 - \[Output (出力)\] ペインでは、\[Set data type (データ型の設定)\] ボタンをクリックします。すでに \[Output (出力)\] ペインにデータ型が存在する場合は、ペインの一番上にあるドロップダウンリスト矢印をクリックして、新しいデータ型を設定します。 2. サンプルまたはスキーマを提供することで、データ構造を手動で定義します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # 変換の入力構造と出力構造の定義 (Design Center) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform コンポーネントで定義する必要があります。 DataWeave ソースコードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素をコードで直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 他のすべての要素が設定され、コンポーネントのデータ構造が予測できたら、構造を Transform コンポーネントに渡すことができます。 2. Design Center がデータ構造を予測できない場合は、入力データ構造と出力データ構造を手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。このペイロードの内容が分かっていれば、\[HTTP Listener (HTTP リスナー)\] ダイアログボックスの \[Input (入力)\] タブと \[Output (出力)\] タブでデータ型を設定できます。 ## [](#transform-コンポーネントでのデータ構造の定義)Transform コンポーネントでのデータ構造の定義 1. データ型設定アイコンをクリックします。 - \[Input (入力)\] ペインで、ペイロード、属性、または変数をハイライトして、\[Input (入力)\] ペインの一番下にあるデータ型設定アイコンをクリックします。 - \[Output (出力)\] ペインでは、\[Set data type (データ型の設定)\] ボタンをクリックします。すでに \[Output (出力)\] ペインにデータ型が存在する場合は、ペインの一番上にあるドロップダウンリスト矢印をクリックして、新しいデータ型を設定します。 2. サンプルまたはスキーマを提供することで、データ構造を手動で定義します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # 変換の入力構造と出力構造の定義 (Design Center) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform コンポーネントで定義する必要があります。 DataWeave ソースコードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素をコードで直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 他のすべての要素が設定され、コンポーネントのデータ構造が予測できたら、構造を Transform コンポーネントに渡すことができます。 2. Design Center がデータ構造を予測できない場合は、入力データ構造と出力データ構造を手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。このペイロードの内容が分かっていれば、\[HTTP Listener (HTTP リスナー)\] ダイアログボックスの \[Input (入力)\] タブと \[Output (出力)\] タブでデータ型を設定できます。 ## [](#transform-コンポーネントでのデータ構造の定義)Transform コンポーネントでのデータ構造の定義 1. データ型設定アイコンをクリックします。 - \[Input (入力)\] ペインで、ペイロード、属性、または変数をハイライトして、\[Input (入力)\] ペインの一番下にあるデータ型設定アイコンをクリックします。 - \[Output (出力)\] ペインでは、\[Set data type (データ型の設定)\] ボタンをクリックします。すでに \[Output (出力)\] ペインにデータ型が存在する場合は、ペインの一番上にあるドロップダウンリスト矢印をクリックして、新しいデータ型を設定します。 2. サンプルまたはスキーマを提供することで、データ構造を手動で定義します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # 変換の入力構造と出力構造の定義 (Design Center) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform コンポーネントで定義する必要があります。 DataWeave ソースコードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素をコードで直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 他のすべての要素が設定され、コンポーネントのデータ構造が予測できたら、構造を Transform コンポーネントに渡すことができます。 2. Design Center がデータ構造を予測できない場合は、入力データ構造と出力データ構造を手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。このペイロードの内容が分かっていれば、\[HTTP Listener (HTTP リスナー)\] ダイアログボックスの \[Input (入力)\] タブと \[Output (出力)\] タブでデータ型を設定できます。 ## [](#transform-コンポーネントでのデータ構造の定義)Transform コンポーネントでのデータ構造の定義 1. データ型設定アイコンをクリックします。 - \[Input (入力)\] ペインで、ペイロード、属性、または変数をハイライトして、\[Input (入力)\] ペインの一番下にあるデータ型設定アイコンをクリックします。 - \[Output (出力)\] ペインでは、\[Set data type (データ型の設定)\] ボタンをクリックします。すでに \[Output (出力)\] ペインにデータ型が存在する場合は、ペインの一番上にあるドロップダウンリスト矢印をクリックして、新しいデータ型を設定します。 2. サンプルまたはスキーマを提供することで、データ構造を手動で定義します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # 変換の入力構造と出力構造の定義 (Design Center) グラフィカルビューを使用してドラッグアンドドロップでマッピングを構築するには、まず、ドラッグアンドドロップで利用できる項目についての情報を Transform コンポーネントで定義する必要があります。 DataWeave ソースコードで変換をすべて定義する場合には、入力と出力の定義は省略して、要素をコードで直接参照できます。 ## [](#他のコンポーネント上のデータ構造の定義)他のコンポーネント上のデータ構造の定義 1. フローの他の要素がすべて完全に設定されていることを確認します。 他のすべての要素が設定され、コンポーネントのデータ構造が予測できたら、構造を Transform コンポーネントに渡すことができます。 2. Design Center がデータ構造を予測できない場合は、入力データ構造と出力データ構造を手動で定義します。 たとえば、HTTP リスナーは、あらゆる種別のペイロードを含む要求を受信します。このペイロードの内容が分かっていれば、\[HTTP Listener (HTTP リスナー)\] ダイアログボックスの \[Input (入力)\] タブと \[Output (出力)\] タブでデータ型を設定できます。 ## [](#transform-コンポーネントでのデータ構造の定義)Transform コンポーネントでのデータ構造の定義 1. データ型設定アイコンをクリックします。 - \[Input (入力)\] ペインで、ペイロード、属性、または変数をハイライトして、\[Input (入力)\] ペインの一番下にあるデータ型設定アイコンをクリックします。 - \[Output (出力)\] ペインでは、\[Set data type (データ型の設定)\] ボタンをクリックします。すでに \[Output (出力)\] ペインにデータ型が存在する場合は、ペインの一番上にあるドロップダウンリスト矢印をクリックして、新しいデータ型を設定します。 2. サンプルまたはスキーマを提供することで、データ構造を手動で定義します。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # 変換の出力のプレビュー (Design Center) Transform コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはアプリケーションを実行する必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. \[Input (入力)\] ペインで、入力のいずれかの部分 (ペイロード、属性、または特定の変数) を選択します。 2. ウィンドウの一番下にあるサンプルデータ編集アイコン ​![preview transformation output design center 1a65a](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/preview-transformation-output-design-center-1a65a.png)​ を選択します。 3. \[Sample Data (サンプルデータ)\] タブが開き、情報が入力されます。 - サンプルでデータ型を定義してある場合は、同じ値が使用されます。 - スキーマでデータ型を定義してある場合、またはデータ型が自動的に定義されている場合は、​`????`​ がプレースホルダーとして表示されます。 入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。 DataWeave 形式でのサンプルデータ: \[ { message @(id: "FSD-483"): "Hello World!", date: |2017-05-06|, items: { item1: 434, item2: "344222" } }, { message @(id: "DSF-829"): "This is what DataWeave format looks like.", date: |2017-03-21|, items: { item1: 728, item2: "14422" } } \] 1. プレースホルダーに実際の値を入力します。 サンプルデータまたは変換を変更して、出力プレビューがどのように変化するかを確認してください。 トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​**\[Preview (プレビュー)\]**​ ペインに表示されます。 出力が POJO (Plain Old Java Object) 型である場合は、プレビューは JSON 形式で表示されます。 1. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。 このペインで定義されるサンプルは、​**Transform**​ コンポーネントでのみ機能します。これらのサンプルは、アプリケーションの他のコンポーネントには影響しません。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # 変換の出力のプレビュー (Design Center) Transform コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはアプリケーションを実行する必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. \[Input (入力)\] ペインで、入力のいずれかの部分 (ペイロード、属性、または特定の変数) を選択します。 2. ウィンドウの一番下にあるサンプルデータ編集アイコン ​![preview transformation output design center 1a65a](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/preview-transformation-output-design-center-1a65a.png)​ を選択します。 3. \[Sample Data (サンプルデータ)\] タブが開き、情報が入力されます。 - サンプルでデータ型を定義してある場合は、同じ値が使用されます。 - スキーマでデータ型を定義してある場合、またはデータ型が自動的に定義されている場合は、​`????`​ がプレースホルダーとして表示されます。 入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。 DataWeave 形式でのサンプルデータ: \[ { message @(id: "FSD-483"): "Hello World!", date: |2017-05-06|, items: { item1: 434, item2: "344222" } }, { message @(id: "DSF-829"): "This is what DataWeave format looks like.", date: |2017-03-21|, items: { item1: 728, item2: "14422" } } \] 1. プレースホルダーに実際の値を入力します。 サンプルデータまたは変換を変更して、出力プレビューがどのように変化するかを確認してください。 トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​**\[Preview (プレビュー)\]**​ ペインに表示されます。 出力が POJO (Plain Old Java Object) 型である場合は、プレビューは JSON 形式で表示されます。 1. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。 このペインで定義されるサンプルは、​**Transform**​ コンポーネントでのみ機能します。これらのサンプルは、アプリケーションの他のコンポーネントには影響しません。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # 変換の出力のプレビュー (Design Center) Transform コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはアプリケーションを実行する必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. \[Input (入力)\] ペインで、入力のいずれかの部分 (ペイロード、属性、または特定の変数) を選択します。 2. ウィンドウの一番下にあるサンプルデータ編集アイコン ![preview transformation output design center 1a65a](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/preview-transformation-output-design-center-1a65a.png) を選択します。 3. \[Sample Data (サンプルデータ)\] タブが開き、情報が入力されます。 - サンプルでデータ型を定義してある場合は、同じ値が使用されます。 - スキーマでデータ型を定義してある場合、またはデータ型が自動的に定義されている場合は、​`????`​ がプレースホルダーとして表示されます。 入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。 DataWeave 形式でのサンプルデータ: \[ { message @(id: "FSD-483"): "Hello World!", date: |2017-05-06|, items: { item1: 434, item2: "344222" } }, { message @(id: "DSF-829"): "This is what DataWeave format looks like.", date: |2017-03-21|, items: { item1: 728, item2: "14422" } } \] 1. プレースホルダーに実際の値を入力します。 サンプルデータまたは変換を変更して、出力プレビューがどのように変化するかを確認してください。 トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​**\[Preview (プレビュー)\]**​ ペインに表示されます。 出力が POJO (Plain Old Java Object) 型である場合は、プレビューは JSON 形式で表示されます。 1. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。 このペインで定義されるサンプルは、​**Transform**​ コンポーネントでのみ機能します。これらのサンプルは、アプリケーションの他のコンポーネントには影響しません。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # 変換の出力のプレビュー (Design Center) Transform コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはアプリケーションを実行する必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. \[Input (入力)\] ペインで、入力のいずれかの部分 (ペイロード、属性、または特定の変数) を選択します。 2. ウィンドウの一番下にあるサンプルデータ編集アイコン ​![preview transformation output design center 1a65a](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/preview-transformation-output-design-center-1a65a.png)​ を選択します。 3. \[Sample Data (サンプルデータ)\] タブが開き、情報が入力されます。 - サンプルでデータ型を定義してある場合は、同じ値が使用されます。 - スキーマでデータ型を定義してある場合、またはデータ型が自動的に定義されている場合は、​`????`​ がプレースホルダーとして表示されます。 入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。 DataWeave 形式でのサンプルデータ: \[ { message @(id: "FSD-483"): "Hello World!", date: |2017-05-06|, items: { item1: 434, item2: "344222" } }, { message @(id: "DSF-829"): "This is what DataWeave format looks like.", date: |2017-03-21|, items: { item1: 728, item2: "14422" } } \] 1. プレースホルダーに実際の値を入力します。 サンプルデータまたは変換を変更して、出力プレビューがどのように変化するかを確認してください。 トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​**\[Preview (プレビュー)\]**​ ペインに表示されます。 出力が POJO (Plain Old Java Object) 型である場合は、プレビューは JSON 形式で表示されます。 1. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。 このペインで定義されるサンプルは、​**Transform**​ コンポーネントでのみ機能します。これらのサンプルは、アプリケーションの他のコンポーネントには影響しません。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # 変換の出力のプレビュー (Design Center) Transform コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはアプリケーションを実行する必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. \[Input (入力)\] ペインで、入力のいずれかの部分 (ペイロード、属性、または特定の変数) を選択します。 2. ウィンドウの一番下にあるサンプルデータ編集アイコン ​![preview transformation output design center 1a65a](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/preview-transformation-output-design-center-1a65a.png)​ を選択します。 3. \[Sample Data (サンプルデータ)\] タブが開き、情報が入力されます。 - サンプルでデータ型を定義してある場合は、同じ値が使用されます。 - スキーマでデータ型を定義してある場合、またはデータ型が自動的に定義されている場合は、​`????`​ がプレースホルダーとして表示されます。 入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。 DataWeave 形式でのサンプルデータ: \[ { message @(id: "FSD-483"): "Hello World!", date: |2017-05-06|, items: { item1: 434, item2: "344222" } }, { message @(id: "DSF-829"): "This is what DataWeave format looks like.", date: |2017-03-21|, items: { item1: 728, item2: "14422" } } \] 1. プレースホルダーに実際の値を入力します。 サンプルデータまたは変換を変更して、出力プレビューがどのように変化するかを確認してください。 トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​**\[Preview (プレビュー)\]**​ ペインに表示されます。 出力が POJO (Plain Old Java Object) 型である場合は、プレビューは JSON 形式で表示されます。 1. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。 このペインで定義されるサンプルは、​**Transform**​ コンポーネントでのみ機能します。これらのサンプルは、アプリケーションの他のコンポーネントには影響しません。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # 変換の出力のプレビュー (Design Center) Transform コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはアプリケーションを実行する必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. \[Input (入力)\] ペインで、入力のいずれかの部分 (ペイロード、属性、または特定の変数) を選択します。 2. ウィンドウの一番下にあるサンプルデータ編集アイコン ​![編集アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/preview-transformation-output-design-center-1a65a.png)​ を選択します。 3. \[Sample Data (サンプルデータ)\] タブが開き、情報が入力されます。 - サンプルでデータ型を定義してある場合は、同じ値が使用されます。 - スキーマでデータ型を定義してある場合、またはデータ型が自動的に定義されている場合は、​`????`​ がプレースホルダーとして表示されます。 入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。 DataWeave 形式でのサンプルデータ: \[ { message @(id: "FSD-483"): "Hello World!", date: |2017-05-06|, items: { item1: 434, item2: "344222" } }, { message @(id: "DSF-829"): "This is what DataWeave format looks like.", date: |2017-03-21|, items: { item1: 728, item2: "14422" } } \] 1. プレースホルダーに実際の値を入力します。 サンプルデータまたは変換を変更して、出力プレビューがどのように変化するかを確認してください。 トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​**\[Preview (プレビュー)\]**​ ペインに表示されます。 出力が POJO (Plain Old Java Object) 型である場合は、プレビューは JSON 形式で表示されます。 1. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。 このペインで定義されるサンプルは、​**Transform**​ コンポーネントでのみ機能します。これらのサンプルは、アプリケーションの他のコンポーネントには影響しません。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # 変換の出力のプレビュー (Design Center) Transform コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはアプリケーションを実行する必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. \[Input (入力)\] ペインで、入力のいずれかの部分 (ペイロード、属性、または特定の変数) を選択します。 2. ウィンドウの一番下にあるサンプルデータ編集アイコン ​![編集アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/preview-transformation-output-design-center-1a65a.png)​ を選択します。 3. \[Sample Data (サンプルデータ)\] タブが開き、情報が入力されます。 - サンプルでデータ型を定義してある場合は、同じ値が使用されます。 - スキーマでデータ型を定義してある場合、またはデータ型が自動的に定義されている場合は、​`????`​ がプレースホルダーとして表示されます。 入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。 DataWeave 形式でのサンプルデータ: \[ { message @(id: "FSD-483"): "Hello World!", date: |2017-05-06|, items: { item1: 434, item2: "344222" } }, { message @(id: "DSF-829"): "This is what DataWeave format looks like.", date: |2017-03-21|, items: { item1: 728, item2: "14422" } } \] 1. プレースホルダーに実際の値を入力します。 サンプルデータまたは変換を変更して、出力プレビューがどのように変化するかを確認してください。 トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​**\[Preview (プレビュー)\]**​ ペインに表示されます。 出力が POJO (Plain Old Java Object) 型である場合は、プレビューは JSON 形式で表示されます。 1. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。 このペインで定義されるサンプルは、​**Transform**​ コンポーネントでのみ機能します。これらのサンプルは、アプリケーションの他のコンポーネントには影響しません。 ## [](#関連情報)関連情報 [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # 変換出力のプレビュー (Anypoint Studio) Transform Message コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはプロジェクトをデプロイする必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. 入力ペインのルートをクリックして、​**\[Edit Sample Data (サンプルデータの編集)\]**​ を選択します。 ![サンプルデータ](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/dataweave-edit-sample-data.png) 新しいタブが開き、入力構造の空の骨組みが表示されます。値の場所には ​`????`​ がプレースホルダーとして表示されます。
入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。
2. プレースホルダーにサンプル値を入力して、プレビューペインでどのように表示されるかを確認します。 ![サンプルデータ](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/dw-populate-sample-data.png)
サンプルを元のプレースホルダーが表示された骨組みに戻すには、​骨組みに戻すアイコン​ ​rescaffold​ をクリックします。入力したサンプルデータはすべて失われます。
3. プレビューペインを有効にするには、エディターの右上にある ​**\[Preview (プレビュー)\]**​ ボタンをクリックします。 DataWeave コードまたはサンプルデータを変更して、出力データ構造がどのように変化するかを確認してください。
トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​[Preview (プレビュー)]​ ペインに表示されます。
4. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。
このペインで定義されるサンプルは、​Transform Message​ コンポーネントでのみ機能し、他のコンポーネントに伝播されるメタデータを変更したり、サンプル値が他のコンポーネントに伝播されたりすることはありません。また、アプリケーションのデフォルト値としてや、他のいかなる目的にも使用されることはありません。
## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # 変換出力のプレビュー (Anypoint Studio) Transform Message コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはプロジェクトをデプロイする必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. 入力ペインのルートをクリックして、​**\[Edit Sample Data (サンプルデータの編集)\]**​ を選択します。 ![サンプルデータ](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/dataweave-edit-sample-data.png) 新しいタブが開き、入力構造の空の骨組みが表示されます。値の場所には ​`????`​ がプレースホルダーとして表示されます。
入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。
2. プレースホルダーにサンプル値を入力して、プレビューペインでどのように表示されるかを確認します。 ![サンプルデータ](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/dw-populate-sample-data.png)
サンプルを元のプレースホルダーが表示された骨組みに戻すには、​骨組みに戻すアイコン​ ​rescaffold​ をクリックします。入力したサンプルデータはすべて失われます。
3. プレビューペインを有効にするには、エディターの右上にある ​**\[Preview (プレビュー)\]**​ ボタンをクリックします。 DataWeave コードまたはサンプルデータを変更して、出力データ構造がどのように変化するかを確認してください。
トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​[Preview (プレビュー)]​ ペインに表示されます。
4. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。
このペインで定義されるサンプルは、​Transform Message​ コンポーネントでのみ機能し、他のコンポーネントに伝播されるメタデータを変更したり、サンプル値が他のコンポーネントに伝播されたりすることはありません。また、アプリケーションのデフォルト値としてや、他のいかなる目的にも使用されることはありません。
## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # 変換出力のプレビュー (Anypoint Studio) Transform Message コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはプロジェクトをデプロイする必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. 入力ペインのルートをクリックして、​**\[Edit Sample Data (サンプルデータの編集)\]**​ を選択します。 ![サンプルデータ](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/dataweave-edit-sample-data.png) 新しいタブが開き、入力構造の空の骨組みが表示されます。値の場所には ​`????`​ がプレースホルダーとして表示されます。
入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。
2. プレースホルダーにサンプル値を入力して、プレビューペインでどのように表示されるかを確認します。 ![サンプルデータ](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/dw-populate-sample-data.png)
サンプルを元のプレースホルダーが表示された骨組みに戻すには、​骨組みに戻すアイコン​ ​rescaffold​ をクリックします。入力したサンプルデータはすべて失われます。
3. プレビューペインを有効にするには、エディターの右上にある ​**\[Preview (プレビュー)\]**​ ボタンをクリックします。 DataWeave コードまたはサンプルデータを変更して、出力データ構造がどのように変化するかを確認してください。
トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​[Preview (プレビュー)]​ ペインに表示されます。
4. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。
このペインで定義されるサンプルは、​Transform Message​ コンポーネントでのみ機能し、他のコンポーネントに伝播されるメタデータを変更したり、サンプル値が他のコンポーネントに伝播されたりすることはありません。また、アプリケーションのデフォルト値としてや、他のいかなる目的にも使用されることはありません。
## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # 変換出力のプレビュー (Anypoint Studio) Transform Message コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはプロジェクトをデプロイする必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. 入力ペインのルートをクリックして、​**\[Edit Sample Data (サンプルデータの編集)\]**​ を選択します。 ![サンプルデータ](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/dataweave-edit-sample-data.png) 新しいタブが開き、入力構造の空の骨組みが表示されます。値の場所には ​`????`​ がプレースホルダーとして表示されます。
入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。
2. プレースホルダーにサンプル値を入力して、プレビューペインでどのように表示されるかを確認します。 ![サンプルデータ](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/dw-populate-sample-data.png)
サンプルを元のプレースホルダーが表示された骨組みに戻すには、​骨組みに戻すアイコン​ ​rescaffold​ をクリックします。入力したサンプルデータはすべて失われます。
3. プレビューペインを有効にするには、エディターの右上にある ​**\[Preview (プレビュー)\]**​ ボタンをクリックします。 DataWeave コードまたはサンプルデータを変更して、出力データ構造がどのように変化するかを確認してください。
トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​[Preview (プレビュー)]​ ペインに表示されます。
4. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。
このペインで定義されるサンプルは、​Transform Message​ コンポーネントでのみ機能し、他のコンポーネントに伝播されるメタデータを変更したり、サンプル値が他のコンポーネントに伝播されたりすることはありません。また、アプリケーションのデフォルト値としてや、他のいかなる目的にも使用されることはありません。
## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # 変換出力のプレビュー (Anypoint Studio) Transform Message コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはプロジェクトをデプロイする必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. 入力ペインのルートをクリックして、​**\[Edit Sample Data (サンプルデータの編集)\]**​ を選択します。 ![Anypoint Studio の \[Transform Message (メッセージの変換)\] タブの \[Edit Sample Data (サンプルデータの編集)\]](_images/dataweave-edit-sample-data.png) 新しいタブが開き、入力構造の空の骨組みが表示されます。値の場所には ​`????`​ がプレースホルダーとして表示されます。
入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。
2. プレースホルダーにサンプル値を入力して、プレビューペインでどのように表示されるかを確認します。 ![\[payload (ペイロード)\] タブの JSON スキャフォールディング](_images/dw-populate-sample-data.png)
サンプルを元のプレースホルダーが表示された骨組みに戻すには、​元に戻すボタン​ ​元に戻すアイコン​ をクリックします。入力したサンプルデータはすべて失われます。
3. プレビューペインを有効にするには、エディターの右上にある ​**\[Preview (プレビュー)\]**​ ボタンをクリックします。 DataWeave コードまたはサンプルデータを変更して、出力データ構造がどのように変化するかを確認してください。
トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​[Preview (プレビュー)]​ ペインに表示されます。
4. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。
このペインで定義されるサンプルは、​Transform Message​ コンポーネントでのみ機能し、他のコンポーネントに伝播されるメタデータを変更したり、サンプル値が他のコンポーネントに伝播されたりすることはありません。また、アプリケーションのデフォルト値としてや、他のいかなる目的にも使用されることはありません。
## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # 変換出力のプレビュー (Anypoint Studio) Transform Message コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはプロジェクトをデプロイする必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. 入力ペインのルートをクリックして、​**\[Edit Sample Data (サンプルデータの編集)\]**​ を選択します。 ![Anypoint Studio の \[Transform Message (メッセージの変換)\] タブの \[Edit Sample Data (サンプルデータの編集)\]](_images/dataweave-edit-sample-data.png) 新しいタブが開き、入力構造の空の骨組みが表示されます。値の場所には ​`????`​ がプレースホルダーとして表示されます。
入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。
2. プレースホルダーにサンプル値を入力して、プレビューペインでどのように表示されるかを確認します。 ![\[payload (ペイロード)\] タブの JSON スキャフォールディング](_images/dw-populate-sample-data.png)
サンプルを元のプレースホルダーが表示された骨組みに戻すには、​元に戻すボタン​ ​元に戻すアイコン​ をクリックします。入力したサンプルデータはすべて失われます。
3. プレビューペインを有効にするには、エディターの右上にある ​**\[Preview (プレビュー)\]**​ ボタンをクリックします。 DataWeave コードまたはサンプルデータを変更して、出力データ構造がどのように変化するかを確認してください。
トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​[Preview (プレビュー)]​ ペインに表示されます。
4. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。
このペインで定義されるサンプルは、​Transform Message​ コンポーネントでのみ機能し、他のコンポーネントに伝播されるメタデータを変更したり、サンプル値が他のコンポーネントに伝播されたりすることはありません。また、アプリケーションのデフォルト値としてや、他のいかなる目的にも使用されることはありません。
## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # 変換出力のプレビュー (Anypoint Studio) Transform Message コンポーネントにサンプル入力データを供給することで、変換動作を確認できます。この機能を使用するにはプロジェクトをデプロイする必要はありません。サンプル入力や変換に変更を加えるたびに、出力がリアルタイムで更新されます。 1. 入力ペインのルートをクリックして、​**\[Edit Sample Data (サンプルデータの編集)\]**​ を選択します。 ![Anypoint Studio の \[Transform Message (メッセージの変換)\] タブの \[Edit Sample Data (サンプルデータの編集)\]](_images/dataweave-edit-sample-data.png) 新しいタブが開き、入力構造の空の骨組みが表示されます。値の場所には ​`????`​ がプレースホルダーとして表示されます。
入力が POJO (Plain Old Java Object) 型である場合は、サンプルを DataWeave 形式で作成しなければなりません。これ自身は変換ではなく、データ構造の表現に過ぎません。
2. プレースホルダーにサンプル値を入力して、プレビューペインでどのように表示されるかを確認します。 ![\[payload (ペイロード)\] タブの JSON スキャフォールディング](_images/dw-populate-sample-data.png)
サンプルを元のプレースホルダーが表示された骨組みに戻すには、​元に戻すボタン​ ​元に戻すアイコン​ をクリックします。入力したサンプルデータはすべて失われます。
3. プレビューペインを有効にするには、エディターの右上にある ​**\[Preview (プレビュー)\]**​ ボタンをクリックします。 DataWeave コードまたはサンプルデータを変更して、出力データ構造がどのように変化するかを確認してください。
トランスフォーマーに複数の出力 (例: ペイロードと変数の両方) がある場合は、現在選択されている変換に対応する出力が ​[Preview (プレビュー)]​ ペインに表示されます。
4. 受信する可能性のあるすべての特殊文字や構造について変換をテストし、出力が予想どおりであることを確認します。
このペインで定義されるサンプルは、​Transform Message​ コンポーネントでのみ機能し、他のコンポーネントに伝播されるメタデータを変更したり、サンプル値が他のコンポーネントに伝播されたりすることはありません。また、アプリケーションのデフォルト値としてや、他のいかなる目的にも使用されることはありません。
## [](#関連情報)関連情報 [ワークフロー: マッピングの作成](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-workflow-create-mapping-ui-studio) [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # 変換対象の変更 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントはメッセージペイロードに出力します。この対象を変更することで、プロパティや変数など、他の出力部分に変換結果を出力できます。 1. DataWeave コードエディターの上にある ​**\[Edit Current Target (現在の対象を編集)\]**​ をクリックします。 ![using dataweave in studio 47984](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/using-dataweave-in-studio-47984.png) 2. DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![新規変数](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/dw-new-variable.png) ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-component-about) [Transform Message コンポーネントへの出力の追加](https://docs.mulesoft.com/jp/mule-runtime/4.3/transform-add-another-output-transform-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # 変換対象の変更 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントはメッセージペイロードに出力します。この対象を変更することで、プロパティや変数など、他の出力部分に変換結果を出力できます。 1. DataWeave コードエディターの上にある ​**\[Edit Current Target (現在の対象を編集)\]**​ をクリックします。 ![using dataweave in studio 47984](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/using-dataweave-in-studio-47984.png) 2. DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![新規変数](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/dw-new-variable.png) ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-component-about) [Transform Message コンポーネントへの出力の追加](https://docs.mulesoft.com/jp/mule-runtime/4.4/transform-add-another-output-transform-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # 変換対象の変更 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントはメッセージペイロードに出力します。この対象を変更することで、プロパティや変数など、他の出力部分に変換結果を出力できます。 1. DataWeave コードエディターの上にある ​**\[Edit Current Target (現在の対象を編集)\]**​ をクリックします。 ![using dataweave in studio 47984](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/using-dataweave-in-studio-47984.png) 2. DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![新規変数](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/dw-new-variable.png) ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-component-about) [Transform Message コンポーネントへの出力の追加](https://docs.mulesoft.com/jp/mule-runtime/4.5/transform-add-another-output-transform-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # 変換対象の変更 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントはメッセージペイロードに出力します。この対象を変更することで、プロパティや変数など、他の出力部分に変換結果を出力できます。 1. DataWeave コードエディターの上にある ​**\[Edit Current Target (現在の対象を編集)\]**​ をクリックします。 ![using dataweave in studio 47984](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/using-dataweave-in-studio-47984.png) 2. DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![新規変数](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/dw-new-variable.png) ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-component-about) [Transform Message コンポーネントへの出力の追加](https://docs.mulesoft.com/jp/mule-runtime/4.6/transform-add-another-output-transform-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # 変換対象の変更 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントはメッセージペイロードに出力します。この対象を変更することで、プロパティや変数など、他の出力部分に変換結果を出力できます。 1. DataWeave コードエディターの上にある ​**\[Edit Current Target (現在の対象を編集)\]**​ をクリックします。 ![using dataweave in studio 47984](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/using-dataweave-in-studio-47984.png) 2. DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![新規変数](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/dw-new-variable.png) ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-component-about) [Transform Message コンポーネントへの出力の追加](https://docs.mulesoft.com/jp/mule-runtime/4.7/transform-add-another-output-transform-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # 変換対象の変更 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントはメッセージペイロードに出力します。この対象を変更することで、プロパティや変数など、他の出力部分に変換結果を出力できます。 1. DataWeave コードエディターの上にある ​**\[Edit Current Target (現在の対象を編集)\]**​ をクリックします。 ![編集アイコン](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/using-dataweave-in-studio-47984.png) 2. DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![ソースコードを選択するオプションが含まれる出力](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/dw-new-variable.png) ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-component-about) [Transform Message コンポーネントへの出力の追加](https://docs.mulesoft.com/jp/mule-runtime/4.8/transform-add-another-output-transform-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # 変換対象の変更 (Anypoint Studio) デフォルトでは、Transform Message コンポーネントはメッセージペイロードに出力します。この対象を変更することで、プロパティや変数など、他の出力部分に変換結果を出力できます。 1. DataWeave コードエディターの上にある ​**\[Edit Current Target (現在の対象を編集)\]**​ をクリックします。 ![編集アイコン](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/using-dataweave-in-studio-47984.png) 2. DataWeave 変換の結果を出力 Mule メッセージのどこに配置するかを指定します。新しい変数やプロパティを作成する場合は、名前を指定する必要があります。 ![ソースコードを選択するオプションが含まれる出力](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/dw-new-variable.png) ## [](#関連情報)関連情報 [Transform Message コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-component-about) [Transform Message コンポーネントへの出力の追加](https://docs.mulesoft.com/jp/mule-runtime/4.9/transform-add-another-output-transform-studio-task) [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # 実行エンジン Mule Runtime Engine は、非ブロックで非同期の実行用に調整されたリアクティブ実行エンジンを実装します。 リアクティブプログラミングの詳細は、 [https://en.wikipedia.org/wiki/Reactive\_programming](https://en.wikipedia.org/wiki/Reactive_programming) を参照してください。 タスク指向の実行モデルでは、非ブロック I/O を高い同時実行レベルで透過的に活用できます。つまり、ユーザーはフローのスレッドや非同期性を考慮する必要がありません。Mule フロー内の各操作は実行に関するメタデータを提供するタスクで、Mule はそのメタデータに基づいて調整の決定を行います。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、I/O Intensive (I/O 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 ## [](#processing_types)処理種別 Mule イベントプロセッサーは、実行する処理の種類を Mule に示します。これは、次のいずれかです。 - CPU Light (CPU 負荷小) 短時間の操作 (約 10 ミリ秒) または非ブロック I/O 用。たとえば、ロガー (​`logger`​) や HTTP 要求操作 (​`http:request`​) など。これらのタスクではブロック I/O アクティビティを実行できません。ログで該当する文字列は ​`CPU_LIGHT`​ と ​`CPU_LIGHT_ASYNC`​ です。 - Blocking I/O (ブロック I/O) コール元スレッドをブロックする I/O 用。たとえば、Database Select 操作 (​`db:select`​) や SFTP 読み取り (​`sftp:read`​) など。ログで該当する文字列は ​`BLOCKING`​ と ​`IO`​ です。 - CPU Intensive (CPU 負荷大) CPU の負荷が大きい計算用。通常は実行時間が 10 ミリ秒を超えます。これらのタスクでは I/O アクティビティを実行できません。たとえば Transform Message コンポーネント (​`ee:transform`​) など。ログで該当する文字列は ​`CPU_INTENSIVE`​ です。 特定のコンポーネントやモジュールがサポートする処理種別については、それらのドキュメントを参照してください。指定しない場合、デフォルトの種別は CPU Light (CPU 負荷小) です。 Mule SDK を使用して作成されたコネクタの場合は、コネクタの実装方法に基づいて SDK によって最適な処理種別が決定されます。そのメカニズムについての詳細は、​[Mule SDK のドキュメント](https://docs.mulesoft.com/mule-sdk/latest/)​を参照してください。 ## [](#threading)スレッド Mule 4.3 には、UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 この 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。 ### [](#プロアクターパターン)プロアクターパターン プロアクターは非同期実行のための設計パターンです。プロアクター設計パターンのしくみを理解するには、 [https://en.wikipedia.org/wiki/Proactor\_pattern](https://en.wikipedia.org/wiki/Proactor_pattern) を参照してください。 この設計パターンに従うと、タスクは Mule 処理種別に対応するカテゴリに分類され、各タスクは UBER プールに送信されて実行されます。 パフォーマンステストにより、一意のスレッドプールが 1 つしかなくてもプロアクターパターンを適用するとパフォーマンスが向上することがわかっています。これは、スレッドをよりすばやくメインループに戻すことができ、I/O タスクがブロックされて待機している間もシステムが新しい処理の受け入れを続行できるためです。 ### [](#トランザクション)トランザクション アクティブなトランザクションがある場合は、すべてのスレッド切り替えが停止されます。トランザクションに参加するイベントプロセッサーは同じスレッドで実行されます。 ## [](#設定)設定 スレッドプールは Mule の起動時に自動的に設定され、CPU やメモリなどの利用可能なリソースを考慮する数式が適用されます。 Mule Runtime Engine をオンプレミスで実行している場合、ローカル Mule インスタンスで ​`MULE_HOME/conf/schedulers-pools.conf`​ ファイルを編集することで、これらのグローバル数式を変更できます。この設定ファイルには各プロパティをドキュメント化するコメントが含まれていますが、プール戦略に応じて、固有のプロパティを設定できます。 2 つの使用可能な戦略間で切り替えるように ​`org.mule.runtime.scheduler.SchedulerPoolStrategy`​ パラメーターを設定します。 - UBER 統合スケジュール戦略。デフォルト。 - DEDICATED 分離プール戦略。従来。 ```properties # The strategy to be used for managing the thread pools that back the 3 types of schedulers in the Mule Runtime # (cpu_light, cpu_intensive and I/O). # Possible values are: # - UBER: All three scheduler types will be backed by one uber uber thread pool (default since 4.3.0) # - DEDICATED: Each scheduler type is backed by its own Thread pool (legacy mode to Mule 4.1.x and 4.2.x) org.mule.runtime.scheduler.SchedulerPoolStrategy=UBER ``` ### [](#uber-スケジュール戦略)UBER スケジュール戦略 戦略が ​`UBER`​ に設定されていると、次の設定が適用されます。 - `org.mule.runtime.scheduler.uber.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.uber.workQueue.size=0` - `org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.coreSize=cores # The maximum number of threads to allow in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding tasks in the uber pool before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.workQueue.size=0 # When the number of threads in the uber pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000 ``` ### [](#dedicated-スケジュール戦略)DEDICATED スケジュール戦略 戦略が ​`DEDICATED`​ に設定されていると、デフォルトの UBER 戦略のパラメーターが無視されます。 この設定を有効にするには、​`schedulers-pools.conf`​ ファイルで次のパラメーターのコメントを解除します。 - `org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuLight.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.io.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000` - `org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the cpu_lite pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores # The size of the queue to use for holding cpu_lite tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.workQueue.size=0 # The number of threads to keep in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.coreSize=cores # The maximum number of threads to allow in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding I/O tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.workQueue.size=0 # When the number of threads in the I/O pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000 # The number of threads to keep in the cpu_intensive pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores # The size of the queue to use for holding cpu_intensive tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores ``` #### [](#考慮事項)考慮事項 使用するプール戦略を変更したり、その設定値を変更したりすることはお勧めしません。この設定はグローバルであり、Mule Runtime インスタンス全体に影響することに注意してください。 実際のシナリオに含まれるすべてのアプリケーションを使用して負荷テストとストレステストを実行することによって、スレッド設定への変更を検証し、Mule 4 でのスレッドプールの動作について理解することをお勧めします。 ### [](#アプリケーションレベルでの設定)アプリケーションレベルでの設定 アプリケーションコードに次のコードを追加することで、アプリケーションで使用するプール戦略を定義できます。 ```xml ``` `poolStrategy`​ パラメーターは後方互換性を確保するために存在しており、以前の Mule バージョンの 3 つのプールのスキームに戻ることができます。 ```xml ``` #### [](#考慮事項-2)考慮事項 アプリケーションレベルでプール設定を適用すると、Mule アプリケーション用の完全に新しいスレッドプールセットが作成されます。この設定によって ​`scheduler-conf.properties`​ のデフォルト設定は変更されません。オンプレミスデプロイメントでは同じ Mule インスタンスに多くの Mule アプリケーションをデプロイされるため、特にこれが重要です。 デフォルトの設定を使用して Mule を実行することをお勧めします。 Mule 4.1.x または Mule 4.2.x からアップグレードする場合、​`scheduler-conf.properties`​ に対するすべてのカスタマイズが引き続き使用されるように、DEDICATED 戦略を使用できます。ただし、最適化がまだ必要かどうかを判断するために新しいデフォルト設定をテストすることをお勧めします。また、従来のモードに戻す前に、まず新しい UBER 戦略をカスタマイズしてみてください。
CloudHub にデプロイされた Mule アプリケーションのアプリケーションレベルでプール設定を定義する場合、断片的 vCore はメモリが少ないため、ワーカーサイズに注意してください。詳細は、​「CloudHub ワーカー」​を参照してください。
## [](#カスタムスレッドプール)カスタムスレッドプール 一意の UBER スレッドプールに加えて、一部のコンポーネントによって特定の目的のために次のような追加プールが作成される場合があります。 - NIO セレクター 非ブロック I/O を有効にします。各コネクタは、必要に応じて何個でも作成できます。 - 繰り返しタスクプール 一部のコネクタやコンポーネント (有効期限監視、キューコンシューマーなど) によって、繰り返しタスクを実行するための特定のプールが作成される場合があります。 ## [](#backpressure)バックプレッシャー管理 バックプレッシャーは、負荷が大きい場合に Mule が特定のイベントを処理するために使用可能なリソースがないときに発生する可能性があります。この問題は、スレッドがすべて使用中で新しく受信したイベントのハンドオフを実行できない場合や、現在のフローの ​`maxConcurrency`​ 値をすでに超過している場合に発生する可能性があります。 Mule がイベントを処理できない場合、その状況に関する次のメッセージが記録されます: `Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。また、フローのソースには、必要なアクションを実行するように通知されます。 バックプレッシャーのために Mule が実行するアクションは、各コネクタの取得元に固有です。たとえば、​`http:listener`​ は ​`503`​ エラーコードを返す可能性があり、メッセージブローカーリスナーはリソースが使用可能になるまで待つかメッセージを削除する可能性があります。 場合によっては、取得元は処理しきれないデータを取得しないようにリモートシステムから切断し、サーバーが正常な状態に戻った後に再接続することがあります。 ## [](#upgrading-from-4-x)Mule 4.2 または 4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x にアップグレードする場合は、次のアクションを実行します。 - カスタムスレッド設定が適用されない場合 (​`scheduler-pools.conf`​ を使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - カスタムスレッド設定が適用される場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。 カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 ## [](#トラブルシューティング)トラブルシューティング Mule アプリケーションのトラブルシューティングを行う場合は、スレッドの命名規則を考慮してください。 たとえば、次のフローがあるとします。 ```xml ``` 実行後に、フローで次のログが生成されます。 ERROR 2020-03-12 19:13:45,292 \[\[MuleRuntime\].uber.07: \[echo\].echoFlow.CPU\_LITE @63e7e52c\] \[event: bd56a240-64ae-11ea-8f7d-f01898419bde\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: request at 2020-03-12T19:13:45.283-03:00\[America/Argentina/Buenos\_Aires\] この場合、スレッド名は ​`uber.07`​ です。Mule では操作の種別もログに記録します。この場合は ​`CPU_LITE`​ です。 スレッド名はスレッドダンプにも表示され、プロファイラーを使用する場合も表示されます。 ![プロファイラーのスレッドダンプ](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-thread-profiler.png) # 実行エンジン Mule Runtime Engine は、非ブロックで非同期の実行用に調整されたリアクティブ実行エンジンを実装します。 リアクティブプログラミングの詳細は、 [https://en.wikipedia.org/wiki/Reactive\_programming](https://en.wikipedia.org/wiki/Reactive_programming) を参照してください。 タスク指向の実行モデルでは、非ブロック I/O を高い同時実行レベルで透過的に活用できます。つまり、ユーザーはフローのスレッドや非同期性を考慮する必要がありません。Mule フロー内の各操作は実行に関するメタデータを提供するタスクで、Mule はそのメタデータに基づいて調整の決定を行います。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、I/O Intensive (I/O 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 ## [](#processing_types)処理種別 Mule イベントプロセッサーは、実行する処理の種類を Mule に示します。これは、次のいずれかです。 - CPU Light (CPU 負荷小) 短時間の操作 (約 10 ミリ秒) または非ブロック I/O 用。たとえば、ロガー (​`logger`​) や HTTP 要求操作 (​`http:request`​) など。これらのタスクではブロック I/O アクティビティを実行できません。ログで該当する文字列は ​`CPU_LIGHT`​ と ​`CPU_LIGHT_ASYNC`​ です。 - Blocking I/O (ブロック I/O) コール元スレッドをブロックする I/O 用。たとえば、Database Select 操作 (​`db:select`​) や SFTP 読み取り (​`sftp:read`​) など。ログで該当する文字列は ​`BLOCKING`​ と ​`IO`​ です。 - CPU Intensive (CPU 負荷大) CPU の負荷が大きい計算用。通常は実行時間が 10 ミリ秒を超えます。これらのタスクでは I/O アクティビティを実行できません。たとえば Transform Message コンポーネント (​`ee:transform`​) など。ログで該当する文字列は ​`CPU_INTENSIVE`​ です。 特定のコンポーネントやモジュールがサポートする処理種別については、それらのドキュメントを参照してください。指定しない場合、デフォルトの種別は CPU Light (CPU 負荷小) です。 Mule SDK を使用して作成されたコネクタの場合は、コネクタの実装方法に基づいて SDK によって最適な処理種別が決定されます。そのメカニズムについての詳細は、​[Mule SDK のドキュメント](https://docs.mulesoft.com/mule-sdk/latest/)​を参照してください。 ## [](#threading)スレッド Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 この 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。
以前の Mule 4.x バージョンからアップグレードする場合は、​「Threading in Mule 4.2 (Mule 4.2 のスレッド)」​を参照して Mule 4.3 のスレッドモデルに適用される違いを理解してください。
### [](#プロアクターパターン)プロアクターパターン プロアクターは非同期実行のための設計パターンです。プロアクター設計パターンのしくみを理解するには、 [https://en.wikipedia.org/wiki/Proactor\_pattern](https://en.wikipedia.org/wiki/Proactor_pattern) を参照してください。 この設計パターンに従うと、タスクは Mule 処理種別に対応するカテゴリに分類され、各タスクは UBER プールに送信されて実行されます。 パフォーマンステストにより、一意のスレッドプールが 1 つしかなくてもプロアクターパターンを適用するとパフォーマンスが向上することがわかっています。これは、スレッドをよりすばやくメインループに戻すことができ、I/O タスクがブロックされて待機している間もシステムが新しい処理の受け入れを続行できるためです。 ### [](#トランザクション)トランザクション アクティブなトランザクションがある場合は、すべてのスレッド切り替えが停止されます。トランザクションに参加するイベントプロセッサーは同じスレッドで実行されます。 ## [](#設定)設定 スレッドプールは Mule の起動時に自動的に設定され、CPU やメモリなどの利用可能なリソースを考慮する数式が適用されます。 Mule Runtime Engine をオンプレミスで実行している場合、ローカル Mule インスタンスで ​`MULE_HOME/conf/schedulers-pools.conf`​ ファイルを編集することで、これらのグローバル数式を変更できます。この設定ファイルには各プロパティをドキュメント化するコメントが含まれていますが、プール戦略に応じて、固有のプロパティを設定できます。 2 つの使用可能な戦略間で切り替えるように ​`org.mule.runtime.scheduler.SchedulerPoolStrategy`​ パラメーターを設定します。 - UBER 統合スケジュール戦略。デフォルト。 - DEDICATED 分離プール戦略。従来。 ```properties # The strategy to be used for managing the thread pools that back the 3 types of schedulers in the Mule Runtime # (cpu_light, cpu_intensive and I/O). # Possible values are: # - UBER: All three scheduler types will be backed by one uber uber thread pool (default since 4.3.0) # - DEDICATED: Each scheduler type is backed by its own Thread pool (legacy mode to Mule 4.1.x and 4.2.x) org.mule.runtime.scheduler.SchedulerPoolStrategy=UBER ``` ### [](#uber-スケジュール戦略)UBER スケジュール戦略 戦略が ​`UBER`​ に設定されていると、次の設定が適用されます。 - `org.mule.runtime.scheduler.uber.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.uber.workQueue.size=0` - `org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.coreSize=cores # The maximum number of threads to allow in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding tasks in the uber pool before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.workQueue.size=0 # When the number of threads in the uber pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000 ``` ### [](#dedicated-スケジュール戦略)DEDICATED スケジュール戦略 戦略が ​`DEDICATED`​ に設定されていると、デフォルトの UBER 戦略のパラメーターが無視されます。 この設定を有効にするには、​`schedulers-pools.conf`​ ファイルで次のパラメーターのコメントを解除します。 - `org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuLight.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.io.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000` - `org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the cpu_lite pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores # The size of the queue to use for holding cpu_lite tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.workQueue.size=0 # The number of threads to keep in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.coreSize=cores # The maximum number of threads to allow in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding I/O tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.workQueue.size=0 # When the number of threads in the I/O pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000 # The number of threads to keep in the cpu_intensive pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores # The size of the queue to use for holding cpu_intensive tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores ``` #### [](#考慮事項)考慮事項 使用するプール戦略を変更したり、その設定値を変更したりすることはお勧めしません。この設定はグローバルであり、Mule Runtime インスタンス全体に影響することに注意してください。 実際のシナリオに含まれるすべてのアプリケーションを使用して負荷テストとストレステストを実行することによって、スレッド設定への変更を検証し、Mule 4 でのスレッドプールの動作について理解することをお勧めします。 ### [](#アプリケーションレベルでの設定)アプリケーションレベルでの設定 アプリケーションコードに次のコードを追加することで、アプリケーションで使用するプール戦略を定義できます。 ```xml ``` `poolStrategy`​ パラメーターは後方互換性を確保するために存在しており、以前の Mule バージョンの 3 つのプールのスキームに戻ることができます。 ```xml ``` `gracefulShutdownTimeout`​ パラメーターは、スケジューラーサービスを停止したときにすべてのアーティファクトスレッドプールのすべてのタスクで実行を完了するまで待機する最大時間 (ミリ秒) を指定します。 次の表に、設定可能なプロパティと各項目の XML 属性を示します。
プロパティ名 XML 説明

Pool Size (プールサイズ)

poolSize

アイドル状態であってもプール内で保持するスレッドの数。

キューサイズ

queueSize

実行前にタスクを保持するために使用するキューのサイズ。

Core Pool Size (コアプールサイズ)

corePoolSize

プール内で保持するスレッドの数。

Max Pool Size (最大プールサイズ)

maxPoolSize

プールに含めることができるスレッドの最大数。

Keep Alive (キープアライブ)

keepAlive

プール内のスレッドの数が指定されたコアプールサイズを上回る場合、この値により、超過するアイドル状態のスレッドが終了前に新しいタスクを待機する最大時間 (ミリ秒) を設定します。
#### [](#考慮事項-2)考慮事項 アプリケーションレベルでプール設定を適用すると、Mule アプリケーション用の完全に新しいスレッドプールセットが作成されます。この設定によって ​`scheduler-conf.properties`​ のデフォルト設定は変更されません。オンプレミスデプロイメントでは同じ Mule インスタンスに多くの Mule アプリケーションをデプロイされるため、特にこれが重要です。 デフォルトの設定を使用して Mule を実行することをお勧めします。 Mule 4.1.x または Mule 4.2.x からアップグレードする場合、​`scheduler-conf.properties`​ に対するすべてのカスタマイズが引き続き使用されるように、DEDICATED 戦略を使用できます。ただし、最適化がまだ必要かどうかを判断するために新しいデフォルト設定をテストすることをお勧めします。また、従来のモードに戻す前に、まず新しい UBER 戦略をカスタマイズしてみてください。
CloudHub にデプロイされた Mule アプリケーションのアプリケーションレベルでプール設定を定義する場合、断片的 vCore はメモリが少ないため、ワーカーサイズに注意してください。詳細は、​「CloudHub ワーカー」​を参照してください。
## [](#カスタムスレッドプール)カスタムスレッドプール 一意の UBER スレッドプールに加えて、一部のコンポーネントによって特定の目的のために次のような追加プールが作成される場合があります。 - NIO セレクター 非ブロック I/O を有効にします。各コネクタは、必要に応じて何個でも作成できます。 - 繰り返しタスクプール 一部のコネクタやコンポーネント (有効期限監視、キューコンシューマーなど) によって、繰り返しタスクを実行するための特定のプールが作成される場合があります。 ## [](#backpressure)バックプレッシャー管理 バックプレッシャーは、負荷が大きい場合に Mule が特定のイベントを処理するために使用可能なリソースがないときに発生する可能性があります。この問題は、スレッドがすべて使用中で新しく受信したイベントのハンドオフを実行できない場合や、現在のフローの ​`maxConcurrency`​ 値をすでに超過している場合に発生する可能性があります。 Mule がイベントを処理できない場合、その状況に関する次のメッセージが記録されます: `Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。また、フローのソースには、必要なアクションを実行するように通知されます。 バックプレッシャーのために Mule が実行するアクションは、各コネクタの取得元に固有です。たとえば、​`http:listener`​ は ​`503`​ エラーコードを返す可能性があり、メッセージブローカーリスナーはリソースが使用可能になるまで待つかメッセージを削除する可能性があります。 場合によっては、取得元は処理しきれないデータを取得しないようにリモートシステムから切断し、サーバーが正常な状態に戻った後に再接続することがあります。 ## [](#upgrading-from-4-x)Mule 4.2 または 4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - カスタムスレッド設定が適用されない場合 (​`scheduler-pools.conf`​ を使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - カスタムスレッド設定が適用される場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。 カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 ## [](#トラブルシューティング)トラブルシューティング Mule アプリケーションのトラブルシューティングを行う場合は、スレッドの命名規則を考慮してください。 たとえば、次のフローがあるとします。 ```xml ``` 実行後に、フローで次のログが生成されます。 ERROR 2020-03-12 19:13:45,292 \[\[MuleRuntime\].uber.07: \[echo\].echoFlow.CPU\_LITE @63e7e52c\] \[event: bd56a240-64ae-11ea-8f7d-f01898419bde\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: request at 2020-03-12T19:13:45.283-03:00\[America/Argentina/Buenos\_Aires\] この場合、スレッド名は ​`uber.07`​ です。Mule では操作の種別もログに記録します。この場合は ​`CPU_LITE`​ です。 スレッド名はスレッドダンプにも表示され、プロファイラーを使用する場合も表示されます。 ![プロファイラーのスレッドダンプ](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-thread-profiler.png) # 実行エンジン Mule Runtime Engine は、非ブロックで非同期の実行用に調整されたリアクティブ実行エンジンを実装します。 リアクティブプログラミングの詳細は、 [https://en.wikipedia.org/wiki/Reactive\_programming](https://en.wikipedia.org/wiki/Reactive_programming) を参照してください。 タスク指向の実行モデルでは、非ブロック I/O を高い同時実行レベルで透過的に活用できます。つまり、ユーザーはフローのスレッドや非同期性を考慮する必要がありません。Mule フロー内の各操作は実行に関するメタデータを提供するタスクで、Mule はそのメタデータに基づいて調整の決定を行います。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、I/O Intensive (I/O 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 ## [](#processing_types)処理種別 Mule イベントプロセッサーは、実行する処理の種類を Mule に示します。これは、次のいずれかです。 - CPU Light (CPU 負荷小) 短時間の操作 (約 10 ミリ秒) または非ブロック I/O 用。たとえば、ロガー (​`logger`​) や HTTP 要求操作 (​`http:request`​) など。これらのタスクではブロック I/O アクティビティを実行できません。ログで該当する文字列は ​`CPU_LIGHT`​ と ​`CPU_LIGHT_ASYNC`​ です。 - Blocking I/O (ブロック I/O) コール元スレッドをブロックする I/O 用。たとえば、Database Select 操作 (​`db:select`​) や SFTP 読み取り (​`sftp:read`​) など。ログで該当する文字列は ​`BLOCKING`​ と ​`IO`​ です。 - CPU Intensive (CPU 負荷大) CPU の負荷が大きい計算用。通常は実行時間が 10 ミリ秒を超えます。これらのタスクでは I/O アクティビティを実行できません。たとえば Transform Message コンポーネント (​`ee:transform`​) など。ログで該当する文字列は ​`CPU_INTENSIVE`​ です。 特定のコンポーネントやモジュールがサポートする処理種別については、それらのドキュメントを参照してください。指定しない場合、デフォルトの種別は CPU Light (CPU 負荷小) です。 Mule SDK を使用して作成されたコネクタの場合は、コネクタの実装方法に基づいて SDK によって最適な処理種別が決定されます。そのメカニズムについての詳細は、​[Mule SDK のドキュメント](https://docs.mulesoft.com/mule-sdk/latest/)​を参照してください。 ## [](#threading)スレッド Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 この 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。
以前の Mule 4.x バージョンからアップグレードする場合は、​「Threading in Mule 4.2 (Mule 4.2 のスレッド)」​を参照して Mule 4.3 のスレッドモデルに適用される違いを理解してください。
### [](#プロアクターパターン)プロアクターパターン プロアクターは非同期実行のための設計パターンです。プロアクター設計パターンのしくみを理解するには、 [https://en.wikipedia.org/wiki/Proactor\_pattern](https://en.wikipedia.org/wiki/Proactor_pattern) を参照してください。 この設計パターンに従うと、タスクは Mule 処理種別に対応するカテゴリに分類され、各タスクは UBER プールに送信されて実行されます。 パフォーマンステストにより、一意のスレッドプールが 1 つしかなくてもプロアクターパターンを適用するとパフォーマンスが向上することがわかっています。これは、スレッドをよりすばやくメインループに戻すことができ、I/O タスクがブロックされて待機している間もシステムが新しい処理の受け入れを続行できるためです。 ### [](#トランザクション)トランザクション アクティブなトランザクションがある場合は、すべてのスレッド切り替えが停止されます。トランザクションに参加するイベントプロセッサーは同じスレッドで実行されます。 ## [](#設定)設定 スレッドプールは Mule の起動時に自動的に設定され、CPU やメモリなどの利用可能なリソースを考慮する数式が適用されます。 Mule Runtime Engine をオンプレミスで実行している場合、ローカル Mule インスタンスで ​`MULE_HOME/conf/schedulers-pools.conf`​ ファイルを編集することで、これらのグローバル数式を変更できます。この設定ファイルには各プロパティをドキュメント化するコメントが含まれていますが、プール戦略に応じて、固有のプロパティを設定できます。 2 つの使用可能な戦略間で切り替えるように ​`org.mule.runtime.scheduler.SchedulerPoolStrategy`​ パラメーターを設定します。 - UBER 統合スケジュール戦略。デフォルト。 - DEDICATED 分離プール戦略。従来。 ```properties # The strategy to be used for managing the thread pools that back the 3 types of schedulers in the Mule Runtime # (cpu_light, cpu_intensive and I/O). # Possible values are: # - UBER: All three scheduler types will be backed by one uber uber thread pool (default since 4.3.0) # - DEDICATED: Each scheduler type is backed by its own Thread pool (legacy mode to Mule 4.1.x and 4.2.x) org.mule.runtime.scheduler.SchedulerPoolStrategy=UBER ``` ### [](#uber-スケジュール戦略)UBER スケジュール戦略 戦略が ​`UBER`​ に設定されていると、次の設定が適用されます。 - `org.mule.runtime.scheduler.uber.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.uber.workQueue.size=0` - `org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.coreSize=cores # The maximum number of threads to allow in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding tasks in the uber pool before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.workQueue.size=0 # When the number of threads in the uber pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000 ``` ### [](#dedicated-スケジュール戦略)DEDICATED スケジュール戦略 戦略が ​`DEDICATED`​ に設定されていると、デフォルトの UBER 戦略のパラメーターが無視されます。 この設定を有効にするには、​`schedulers-pools.conf`​ ファイルで次のパラメーターのコメントを解除します。 - `org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuLight.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.io.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000` - `org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the cpu_lite pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores # The size of the queue to use for holding cpu_lite tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.workQueue.size=0 # The number of threads to keep in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.coreSize=cores # The maximum number of threads to allow in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding I/O tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.workQueue.size=0 # When the number of threads in the I/O pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000 # The number of threads to keep in the cpu_intensive pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores # The size of the queue to use for holding cpu_intensive tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores ``` #### [](#考慮事項)考慮事項 使用するプール戦略を変更したり、その設定値を変更したりすることはお勧めしません。この設定はグローバルであり、Mule Runtime インスタンス全体に影響することに注意してください。 実際のシナリオに含まれるすべてのアプリケーションを使用して負荷テストとストレステストを実行することによって、スレッド設定への変更を検証し、Mule 4 でのスレッドプールの動作について理解することをお勧めします。 ### [](#アプリケーションレベルでの設定)アプリケーションレベルでの設定 アプリケーションコードに次のコードを追加することで、アプリケーションで使用するプール戦略を定義できます。 ```xml ``` `poolStrategy`​ パラメーターは後方互換性を確保するために存在しており、以前の Mule バージョンの 3 つのプールのスキームに戻ることができます。 ```xml ``` `gracefulShutdownTimeout`​ パラメーターは、スケジューラーサービスを停止したときにすべてのアーティファクトスレッドプールのすべてのタスクで実行を完了するまで待機する最大時間 (ミリ秒) を指定します。 次の表に、設定可能なプロパティと各項目の XML 属性を示します。
プロパティ名 XML 説明

Pool Size (プールサイズ)

poolSize

アイドル状態であってもプール内で保持するスレッドの数。

キューサイズ

queueSize

実行前にタスクを保持するために使用するキューのサイズ。

Core Pool Size (コアプールサイズ)

corePoolSize

プール内で保持するスレッドの数。

Max Pool Size (最大プールサイズ)

maxPoolSize

プールに含めることができるスレッドの最大数。

Keep Alive (キープアライブ)

keepAlive

プール内のスレッドの数が指定されたコアプールサイズを上回る場合、この値により、超過するアイドル状態のスレッドが終了前に新しいタスクを待機する最大時間 (ミリ秒) を設定します。
#### [](#考慮事項-2)考慮事項 アプリケーションレベルでプール設定を適用すると、Mule アプリケーション用の完全に新しいスレッドプールセットが作成されます。この設定によって ​`scheduler-conf.properties`​ のデフォルト設定は変更されません。オンプレミスデプロイメントでは同じ Mule インスタンスに多くの Mule アプリケーションをデプロイされるため、特にこれが重要です。 デフォルトの設定を使用して Mule を実行することをお勧めします。 Mule 4.1.x または Mule 4.2.x からアップグレードする場合、​`scheduler-conf.properties`​ に対するすべてのカスタマイズが引き続き使用されるように、DEDICATED 戦略を使用できます。ただし、最適化がまだ必要かどうかを判断するために新しいデフォルト設定をテストすることをお勧めします。また、従来のモードに戻す前に、まず新しい UBER 戦略をカスタマイズしてみてください。
CloudHub にデプロイされた Mule アプリケーションのアプリケーションレベルでプール設定を定義する場合、断片的 vCore はメモリが少ないため、ワーカーサイズに注意してください。詳細は、​「CloudHub ワーカー」​を参照してください。
## [](#カスタムスレッドプール)カスタムスレッドプール 一意の UBER スレッドプールに加えて、一部のコンポーネントによって特定の目的のために次のような追加プールが作成される場合があります。 - NIO セレクター 非ブロック I/O を有効にします。各コネクタは、必要に応じて何個でも作成できます。 - 繰り返しタスクプール 一部のコネクタやコンポーネント (有効期限監視、キューコンシューマーなど) によって、繰り返しタスクを実行するための特定のプールが作成される場合があります。 ## [](#backpressure)バックプレッシャー管理 バックプレッシャーは、負荷が大きい場合に Mule が特定のイベントを処理するために使用可能なリソースがないときに発生する可能性があります。この問題は、スレッドがすべて使用中で新しく受信したイベントのハンドオフを実行できない場合や、現在のフローの ​`maxConcurrency`​ 値をすでに超過している場合に発生する可能性があります。 Mule がイベントを処理できない場合、その状況に関する次のメッセージが記録されます: `Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。また、フローのソースには、必要なアクションを実行するように通知されます。 バックプレッシャーのために Mule が実行するアクションは、各コネクタの取得元に固有です。たとえば、​`http:listener`​ は ​`503`​ エラーコードを返す可能性があり、メッセージブローカーリスナーはリソースが使用可能になるまで待つかメッセージを削除する可能性があります。 場合によっては、取得元は処理しきれないデータを取得しないようにリモートシステムから切断し、サーバーが正常な状態に戻った後に再接続することがあります。 ## [](#upgrading-from-4-x)Mule 4.2 または 4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - カスタムスレッド設定が適用されない場合 (​`scheduler-pools.conf`​ を使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - カスタムスレッド設定が適用される場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。 カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 ## [](#トラブルシューティング)トラブルシューティング Mule アプリケーションのトラブルシューティングを行う場合は、スレッドの命名規則を考慮してください。 たとえば、次のフローがあるとします。 ```xml ``` 実行後に、フローで次のログが生成されます。 ERROR 2020-03-12 19:13:45,292 \[\[MuleRuntime\].uber.07: \[echo\].echoFlow.CPU\_LITE @63e7e52c\] \[event: bd56a240-64ae-11ea-8f7d-f01898419bde\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: request at 2020-03-12T19:13:45.283-03:00\[America/Argentina/Buenos\_Aires\] この場合、スレッド名は ​`uber.07`​ です。Mule では操作の種別もログに記録します。この場合は ​`CPU_LITE`​ です。 スレッド名はスレッドダンプにも表示され、プロファイラを使用する場合も表示されます。 ![プロファイラのスレッドダンプ](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-thread-profiler.png) # 実行エンジン Mule Runtime Engine は、非ブロックで非同期の実行用に調整されたリアクティブ実行エンジンを実装します。 リアクティブプログラミングの詳細は、 [https://en.wikipedia.org/wiki/Reactive\_programming](https://en.wikipedia.org/wiki/Reactive_programming) を参照してください。 タスク指向の実行モデルでは、非ブロック I/O を高い同時実行レベルで透過的に活用できます。つまり、ユーザーはフローのスレッドや非同期性を考慮する必要がありません。Mule フロー内の各操作は実行に関するメタデータを提供するタスクで、Mule はそのメタデータに基づいて調整の決定を行います。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、I/O Intensive (I/O 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 ## [](#processing_types)処理種別 Mule イベントプロセッサーは、実行する処理の種類を Mule に示します。これは、次のいずれかです。 - CPU Light (CPU 負荷小) 短時間の操作 (約 10 ミリ秒) または非ブロック I/O 用。たとえば、ロガー (​`logger`​) や HTTP 要求操作 (​`http:request`​) など。これらのタスクではブロック I/O アクティビティを実行できません。ログで該当する文字列は ​`CPU_LIGHT`​ と ​`CPU_LIGHT_ASYNC`​ です。 - Blocking I/O (ブロック I/O) コール元スレッドをブロックする I/O 用。たとえば、Database Select 操作 (​`db:select`​) や SFTP 読み取り (​`sftp:read`​) など。ログで該当する文字列は ​`BLOCKING`​ と ​`IO`​ です。 - CPU Intensive (CPU 負荷大) CPU の負荷が大きい計算用。通常は実行時間が 10 ミリ秒を超えます。これらのタスクでは I/O アクティビティを実行できません。たとえば Transform Message コンポーネント (​`ee:transform`​) など。ログで該当する文字列は ​`CPU_INTENSIVE`​ です。 特定のコンポーネントやモジュールがサポートする処理種別については、それらのドキュメントを参照してください。指定しない場合、デフォルトの種別は CPU Light (CPU 負荷小) です。 Mule SDK を使用して作成されたコネクタの場合は、コネクタの実装方法に基づいて SDK によって最適な処理種別が決定されます。そのメカニズムについての詳細は、​[Mule SDK のドキュメント](https://docs.mulesoft.com/mule-sdk/latest/)​を参照してください。 ## [](#threading)スレッド Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 この 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。
以前の Mule 4.x バージョンからアップグレードする場合は、​「Threading in Mule 4.2 (Mule 4.2 のスレッド)」​を参照して Mule 4.3 のスレッドモデルに適用される違いを理解してください。
### [](#プロアクターパターン)プロアクターパターン プロアクターは非同期実行のための設計パターンです。プロアクター設計パターンのしくみを理解するには、 [https://en.wikipedia.org/wiki/Proactor\_pattern](https://en.wikipedia.org/wiki/Proactor_pattern) を参照してください。 この設計パターンに従うと、タスクは Mule 処理種別に対応するカテゴリに分類され、各タスクは UBER プールに送信されて実行されます。 パフォーマンステストにより、一意のスレッドプールが 1 つしかなくてもプロアクターパターンを適用するとパフォーマンスが向上することがわかっています。これは、スレッドをよりすばやくメインループに戻すことができ、I/O タスクがブロックされて待機している間もシステムが新しい処理の受け入れを続行できるためです。 ### [](#トランザクション)トランザクション アクティブなトランザクションがある場合は、すべてのスレッド切り替えが停止されます。トランザクションに参加するイベントプロセッサーは同じスレッドで実行されます。 ## [](#設定)設定 スレッドプールは Mule の起動時に自動的に設定され、CPU やメモリなどの利用可能なリソースを考慮する数式が適用されます。 Mule Runtime Engine をオンプレミスで実行している場合、ローカル Mule インスタンスで ​`MULE_HOME/conf/schedulers-pools.conf`​ ファイルを編集することで、これらのグローバル数式を変更できます。この設定ファイルには各プロパティをドキュメント化するコメントが含まれていますが、プール戦略に応じて、固有のプロパティを設定できます。 2 つの使用可能な戦略間で切り替えるように ​`org.mule.runtime.scheduler.SchedulerPoolStrategy`​ パラメーターを設定します。 - UBER 統合スケジュール戦略。デフォルト。 - DEDICATED 分離プール戦略。従来。 ```properties # The strategy to be used for managing the thread pools that back the 3 types of schedulers in the Mule Runtime # (cpu_light, cpu_intensive and I/O). # Possible values are: # - UBER: All three scheduler types will be backed by one uber uber thread pool (default since 4.3.0) # - DEDICATED: Each scheduler type is backed by its own Thread pool (legacy mode to Mule 4.1.x and 4.2.x) org.mule.runtime.scheduler.SchedulerPoolStrategy=UBER ``` ### [](#uber-スケジュール戦略)UBER スケジュール戦略 戦略が ​`UBER`​ に設定されていると、次の設定が適用されます。 - `org.mule.runtime.scheduler.uber.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.uber.workQueue.size=0` - `org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.coreSize=cores # The maximum number of threads to allow in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding tasks in the uber pool before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.workQueue.size=0 # When the number of threads in the uber pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000 ``` ### [](#dedicated-スケジュール戦略)DEDICATED スケジュール戦略 戦略が ​`DEDICATED`​ に設定されていると、デフォルトの UBER 戦略のパラメーターが無視されます。 この設定を有効にするには、​`schedulers-pools.conf`​ ファイルで次のパラメーターのコメントを解除します。 - `org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuLight.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.io.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000` - `org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the cpu_lite pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores # The size of the queue to use for holding cpu_lite tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.workQueue.size=0 # The number of threads to keep in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.coreSize=cores # The maximum number of threads to allow in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding I/O tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.workQueue.size=0 # When the number of threads in the I/O pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000 # The number of threads to keep in the cpu_intensive pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores # The size of the queue to use for holding cpu_intensive tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores ``` #### [](#考慮事項)考慮事項 使用するプール戦略を変更したり、その設定値を変更したりすることはお勧めしません。この設定はグローバルであり、Mule Runtime インスタンス全体に影響することに注意してください。 実際のシナリオに含まれるすべてのアプリケーションを使用して負荷テストとストレステストを実行することによって、スレッド設定への変更を検証し、Mule 4 でのスレッドプールの動作について理解することをお勧めします。 ### [](#アプリケーションレベルでの設定)アプリケーションレベルでの設定 アプリケーションコードに次のコードを追加することで、アプリケーションで使用するプール戦略を定義できます。 ```xml ``` `poolStrategy`​ パラメーターは後方互換性を確保するために存在しており、以前の Mule バージョンの 3 つのプールのスキームに戻ることができます。 ```xml ``` `gracefulShutdownTimeout`​ パラメーターは、スケジューラーサービスを停止したときにすべてのアーティファクトスレッドプールのすべてのタスクで実行を完了するまで待機する最大時間 (ミリ秒) を指定します。 次の表に、設定可能なプロパティと各項目の XML 属性を示します。
プロパティ名 XML 説明

Pool Size (プールサイズ)

poolSize

アイドル状態であってもプール内で保持するスレッドの数。

キューサイズ

queueSize

実行前にタスクを保持するために使用するキューのサイズ。

Core Pool Size (コアプールサイズ)

corePoolSize

プール内で保持するスレッドの数。

Max Pool Size (最大プールサイズ)

maxPoolSize

プールに含めることができるスレッドの最大数。

Keep Alive (キープアライブ)

keepAlive

プール内のスレッドの数が指定されたコアプールサイズを上回る場合、この値により、超過するアイドル状態のスレッドが終了前に新しいタスクを待機する最大時間 (ミリ秒) を設定します。
#### [](#考慮事項-2)考慮事項 アプリケーションレベルでプール設定を適用すると、Mule アプリケーション用の完全に新しいスレッドプールセットが作成されます。この設定によって ​`scheduler-conf.properties`​ のデフォルト設定は変更されません。オンプレミスデプロイメントでは同じ Mule インスタンスに多くの Mule アプリケーションをデプロイされるため、特にこれが重要です。 デフォルトの設定を使用して Mule を実行することをお勧めします。 Mule 4.1.x または Mule 4.2.x からアップグレードする場合、​`scheduler-conf.properties`​ に対するすべてのカスタマイズが引き続き使用されるように、DEDICATED 戦略を使用できます。ただし、最適化がまだ必要かどうかを判断するために新しいデフォルト設定をテストすることをお勧めします。また、従来のモードに戻す前に、まず新しい UBER 戦略をカスタマイズしてみてください。
CloudHub にデプロイされた Mule アプリケーションのアプリケーションレベルでプール設定を定義する場合、断片的 vCore はメモリが少ないため、ワーカーサイズに注意してください。詳細は、​「CloudHub ワーカー」​を参照してください。
## [](#カスタムスレッドプール)カスタムスレッドプール 一意の UBER スレッドプールに加えて、一部のコンポーネントによって特定の目的のために次のような追加プールが作成される場合があります。 - NIO セレクター 非ブロック I/O を有効にします。各コネクタは、必要に応じて何個でも作成できます。 - 繰り返しタスクプール 一部のコネクタやコンポーネント (有効期限監視、キューコンシューマーなど) によって、繰り返しタスクを実行するための特定のプールが作成される場合があります。 ## [](#backpressure)バックプレッシャー管理 バックプレッシャーは、負荷が大きい場合に Mule が特定のイベントを処理するために使用可能なリソースがないときに発生する可能性があります。この問題は、スレッドがすべて使用中で新しく受信したイベントのハンドオフを実行できない場合や、現在のフローの ​`maxConcurrency`​ 値をすでに超過している場合に発生する可能性があります。 Mule がイベントを処理できない場合、その状況に関する次のメッセージが記録されます: `Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。また、フローのソースには、必要なアクションを実行するように通知されます。 バックプレッシャーのために Mule が実行するアクションは、各コネクタの取得元に固有です。たとえば、​`http:listener`​ は ​`503`​ エラーコードを返す可能性があり、メッセージブローカーリスナーはリソースが使用可能になるまで待つかメッセージを削除する可能性があります。 場合によっては、取得元は処理しきれないデータを取得しないようにリモートシステムから切断し、サーバーが正常な状態に戻った後に再接続することがあります。 ## [](#upgrading-from-4-x)Mule 4.2 または 4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - カスタムスレッド設定が適用されない場合 (​`scheduler-pools.conf`​ を使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - カスタムスレッド設定が適用される場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。 カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 ## [](#トラブルシューティング)トラブルシューティング Mule アプリケーションのトラブルシューティングを行う場合は、スレッドの命名規則を考慮してください。 たとえば、次のフローがあるとします。 ```xml ``` 実行後に、フローで次のログが生成されます。 ERROR 2020-03-12 19:13:45,292 \[\[MuleRuntime\].uber.07: \[echo\].echoFlow.CPU\_LITE @63e7e52c\] \[event: bd56a240-64ae-11ea-8f7d-f01898419bde\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: request at 2020-03-12T19:13:45.283-03:00\[America/Argentina/Buenos\_Aires\] この場合、スレッド名は ​`uber.07`​ です。Mule では操作の種別もログに記録します。この場合は ​`CPU_LITE`​ です。 スレッド名はスレッドダンプにも表示され、プロファイラーを使用する場合も表示されます。 ![プロファイラーのスレッドダンプ](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-thread-profiler.png) # 実行エンジン Mule Runtime Engine は、非ブロックで非同期の実行用に調整されたリアクティブ実行エンジンを実装します。 リアクティブプログラミングの詳細は、 [https://en.wikipedia.org/wiki/Reactive\_programming](https://en.wikipedia.org/wiki/Reactive_programming) を参照してください。 タスク指向の実行モデルでは、非ブロック I/O を高い同時実行レベルで透過的に活用できます。つまり、ユーザーはフローのスレッドや非同期性を考慮する必要がありません。Mule フロー内の各操作は実行に関するメタデータを提供するタスクで、Mule はそのメタデータに基づいて調整の決定を行います。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、I/O Intensive (I/O 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 ## [](#processing_types)処理種別 Mule イベントプロセッサーは、実行する処理の種類を Mule に示します。これは、次のいずれかです。 - CPU Light (CPU 負荷小) 短時間の操作 (約 10 ミリ秒) または非ブロック I/O 用。たとえば、ロガー (​`logger`​) や HTTP 要求操作 (​`http:request`​) など。これらのタスクではブロック I/O アクティビティを実行できません。ログで該当する文字列は ​`CPU_LIGHT`​ と ​`CPU_LIGHT_ASYNC`​ です。 - Blocking I/O (ブロック I/O) コール元スレッドをブロックする I/O 用。たとえば、Database Select 操作 (​`db:select`​) や SFTP 読み取り (​`sftp:read`​) など。ログで該当する文字列は ​`BLOCKING`​ と ​`IO`​ です。 - CPU Intensive (CPU 負荷大) CPU の負荷が大きい計算用。通常は実行時間が 10 ミリ秒を超えます。これらのタスクでは I/O アクティビティを実行できません。たとえば Transform Message コンポーネント (​`ee:transform`​) など。ログで該当する文字列は ​`CPU_INTENSIVE`​ です。 特定のコンポーネントやモジュールがサポートする処理種別については、それらのドキュメントを参照してください。指定しない場合、デフォルトの種別は CPU Light (CPU 負荷小) です。 Mule SDK を使用して作成されたコネクタの場合は、コネクタの実装方法に基づいて SDK によって最適な処理種別が決定されます。そのメカニズムについての詳細は、​[Mule SDK のドキュメント](https://docs.mulesoft.com/mule-sdk/latest/)​を参照してください。 ## [](#threading)スレッド Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 この 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。
以前の Mule 4.x バージョンからアップグレードする場合は、​「Threading in Mule 4.2 (Mule 4.2 のスレッド)」​を参照して Mule 4.3 のスレッドモデルに適用される違いを理解してください。
### [](#プロアクターパターン)プロアクターパターン プロアクターは非同期実行のための設計パターンです。プロアクター設計パターンのしくみを理解するには、 [https://en.wikipedia.org/wiki/Proactor\_pattern](https://en.wikipedia.org/wiki/Proactor_pattern) を参照してください。 この設計パターンに従うと、タスクは Mule 処理種別に対応するカテゴリに分類され、各タスクは UBER プールに送信されて実行されます。 パフォーマンステストにより、一意のスレッドプールが 1 つしかなくてもプロアクターパターンを適用するとパフォーマンスが向上することがわかっています。これは、スレッドをよりすばやくメインループに戻すことができ、I/O タスクがブロックされて待機している間もシステムが新しい処理の受け入れを続行できるためです。 ### [](#トランザクション)トランザクション アクティブなトランザクションがある場合は、すべてのスレッド切り替えが停止されます。トランザクションに参加するイベントプロセッサーは同じスレッドで実行されます。 ## [](#設定)設定 スレッドプールは Mule の起動時に自動的に設定され、CPU やメモリなどの利用可能なリソースを考慮する数式が適用されます。 Mule Runtime Engine をオンプレミスで実行している場合、ローカル Mule インスタンスで ​`MULE_HOME/conf/schedulers-pools.conf`​ ファイルを編集することで、これらのグローバル数式を変更できます。この設定ファイルには各プロパティをドキュメント化するコメントが含まれていますが、プール戦略に応じて、固有のプロパティを設定できます。 2 つの使用可能な戦略間で切り替えるように ​`org.mule.runtime.scheduler.SchedulerPoolStrategy`​ パラメーターを設定します。 - UBER 統合スケジュール戦略。デフォルト。 - DEDICATED 分離プール戦略。従来。 ```properties # The strategy to be used for managing the thread pools that back the 3 types of schedulers in the Mule Runtime # (cpu_light, cpu_intensive and I/O). # Possible values are: # - UBER: All three scheduler types will be backed by one uber thread pool (default since 4.3.0) # - DEDICATED: Each scheduler type is backed by its own Thread pool (legacy mode to Mule 4.1.x and 4.2.x) org.mule.runtime.scheduler.SchedulerPoolStrategy=UBER ``` ### [](#uber-スケジュール戦略)UBER スケジュール戦略 戦略が ​`UBER`​ に設定されていると、次の設定が適用されます。 - `org.mule.runtime.scheduler.uber.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.uber.workQueue.size=0` - `org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.coreSize=cores # The maximum number of threads to allow in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding tasks in the uber pool before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.workQueue.size=0 # When the number of threads in the uber pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000 ``` ### [](#dedicated-スケジュール戦略)DEDICATED スケジュール戦略 戦略が ​`DEDICATED`​ に設定されていると、デフォルトの UBER 戦略のパラメーターが無視されます。 この設定を有効にするには、​`schedulers-pools.conf`​ ファイルで次のパラメーターのコメントを解除します。 - `org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuLight.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.io.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000` - `org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the cpu_lite pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores # The size of the queue to use for holding cpu_lite tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.workQueue.size=0 # The number of threads to keep in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.coreSize=cores # The maximum number of threads to allow in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding I/O tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.workQueue.size=0 # When the number of threads in the I/O pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000 # The number of threads to keep in the cpu_intensive pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores # The size of the queue to use for holding cpu_intensive tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores ``` #### [](#考慮事項)考慮事項 使用するプール戦略を変更したり、その設定値を変更したりすることはお勧めしません。この設定はグローバルであり、Mule Runtime インスタンス全体に影響することに注意してください。 実際のシナリオに含まれるすべてのアプリケーションを使用して負荷テストとストレステストを実行することによって、スレッド設定への変更を検証し、Mule 4 でのスレッドプールの動作について理解することをお勧めします。 ### [](#アプリケーションレベルでの設定)アプリケーションレベルでの設定 アプリケーションコードに次のコードを追加することで、アプリケーションで使用するプール戦略を定義できます。 ```xml ``` `poolStrategy`​ パラメーターは後方互換性を確保するために存在しており、以前の Mule バージョンの 3 つのプールのスキームに戻ることができます。 ```xml ``` `gracefulShutdownTimeout`​ パラメーターは、スケジューラーサービスを停止したときにすべてのアーティファクトスレッドプールのすべてのタスクで実行を完了するまで待機する最大時間 (ミリ秒) を指定します。 次の表に、設定可能なプロパティと各項目の XML 属性を示します。
プロパティ名 XML 説明

Pool Size (プールサイズ)

poolSize

アイドル状態であってもプール内で保持するスレッドの数。

キューサイズ

queueSize

実行前にタスクを保持するために使用するキューのサイズ。

Core Pool Size (コアプールサイズ)

corePoolSize

プール内で保持するスレッドの数。

Max Pool Size (最大プールサイズ)

maxPoolSize

プールに含めることができるスレッドの最大数。

Keep Alive (キープアライブ)

keepAlive

プール内のスレッドの数が指定されたコアプールサイズを上回る場合、この値により、超過するアイドル状態のスレッドが終了前に新しいタスクを待機する最大時間 (ミリ秒) を設定します。
#### [](#考慮事項-2)考慮事項 アプリケーションレベルでプール設定を適用すると、Mule アプリケーション用の完全に新しいスレッドプールセットが作成されます。この設定によって ​`scheduler-conf.properties`​ のデフォルト設定は変更されません。オンプレミスデプロイメントでは同じ Mule インスタンスに多くの Mule アプリケーションをデプロイされるため、特にこれが重要です。 デフォルトの設定を使用して Mule を実行することをお勧めします。 Mule 4.1.x または Mule 4.2.x からアップグレードする場合、​`scheduler-conf.properties`​ に対するすべてのカスタマイズが引き続き使用されるように、DEDICATED 戦略を使用できます。ただし、最適化がまだ必要かどうかを判断するために新しいデフォルト設定をテストすることをお勧めします。また、従来のモードに戻す前に、まず新しい UBER 戦略をカスタマイズしてみてください。
CloudHub にデプロイされた Mule アプリケーションのアプリケーションレベルでプール設定を定義する場合、断片的 vCore はメモリが少ないため、ワーカーサイズに注意してください。詳細は、​「CloudHub ワーカー」​を参照してください。
## [](#カスタムスレッドプール)カスタムスレッドプール 一意の UBER スレッドプールに加えて、一部のコンポーネントによって特定の目的のために次のような追加プールが作成される場合があります。 - NIO セレクター 非ブロック I/O を有効にします。各コネクタは、必要に応じて何個でも作成できます。 - 繰り返しタスクプール 一部のコネクタやコンポーネント (有効期限監視、キューコンシューマーなど) によって、繰り返しタスクを実行するための特定のプールが作成される場合があります。 ## [](#backpressure)バックプレッシャー管理 バックプレッシャーは、負荷が大きい場合に Mule が特定のイベントを処理するために使用可能なリソースがないときに発生する可能性があります。この問題は、スレッドがすべて使用中で新しく受信したイベントのハンドオフを実行できない場合や、現在のフローの ​`maxConcurrency`​ 値をすでに超過している場合に発生する可能性があります。 Mule がイベントを処理できない場合、その状況に関する次のメッセージが記録されます: `Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。また、フローのソースには、必要なアクションを実行するように通知されます。 バックプレッシャーのために Mule が実行するアクションは、各コネクタの取得元に固有です。たとえば、​`http:listener`​ は ​`503`​ エラーコードを返す可能性があり、メッセージブローカーリスナーはリソースが使用可能になるまで待つかメッセージを削除する可能性があります。 場合によっては、取得元は処理しきれないデータを取得しないようにリモートシステムから切断し、サーバーが正常な状態に戻った後に再接続することがあります。 ## [](#upgrading-from-4-x)Mule 4.2 または 4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - カスタムスレッド設定が適用されない場合 (​`scheduler-pools.conf`​ を使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - カスタムスレッド設定が適用される場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。 カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 ## [](#トラブルシューティング)トラブルシューティング Mule アプリケーションのトラブルシューティングを行う場合は、スレッドの命名規則を考慮してください。 たとえば、次のフローがあるとします。 ```xml ``` 実行後に、フローで次のログが生成されます。 ERROR 2020-03-12 19:13:45,292 \[\[MuleRuntime\].uber.07: \[echo\].echoFlow.CPU\_LITE @63e7e52c\] \[event: bd56a240-64ae-11ea-8f7d-f01898419bde\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: request at 2020-03-12T19:13:45.283-03:00\[America/Argentina/Buenos\_Aires\] この場合、スレッド名は ​`uber.07`​ です。Mule では操作の種別もログに記録します。この場合は ​`CPU_LITE`​ です。 スレッド名はスレッドダンプにも表示され、プロファイラーを使用する場合も表示されます。 ![プロファイラーのスレッドダンプ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-thread-profiler.png) # 実行エンジン Mule Runtime Engine は、非ブロックで非同期の実行用に調整されたリアクティブ実行エンジンを実装します。 リアクティブプログラミングの詳細は、 [https://en.wikipedia.org/wiki/Reactive\_programming](https://en.wikipedia.org/wiki/Reactive_programming) を参照してください。 タスク指向の実行モデルでは、非ブロック I/O を高い同時実行レベルで透過的に活用できます。つまり、ユーザーはフローのスレッドや非同期性を考慮する必要がありません。Mule フロー内の各操作は実行に関するメタデータを提供するタスクで、Mule はそのメタデータに基づいて調整の決定を行います。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、I/O Intensive (I/O 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 ## [](#processing_types)処理種別 Mule イベントプロセッサーは、実行する処理の種類を Mule に示します。これは、次のいずれかです。 - CPU Light (CPU 負荷小) 短時間の操作 (約 10 ミリ秒) または非ブロック I/O 用。たとえば、ロガー (​`logger`​) や HTTP 要求操作 (​`http:request`​) など。これらのタスクではブロック I/O アクティビティを実行できません。ログで該当する文字列は ​`CPU_LIGHT`​ と ​`CPU_LIGHT_ASYNC`​ です。 - Blocking I/O (ブロック I/O) コール元スレッドをブロックする I/O 用。たとえば、Database Select 操作 (​`db:select`​) や SFTP 読み取り (​`sftp:read`​) など。ログで該当する文字列は ​`BLOCKING`​ と ​`IO`​ です。 - CPU Intensive (CPU 負荷大) CPU の負荷が大きい計算用。通常は実行時間が 10 ミリ秒を超えます。これらのタスクでは I/O アクティビティを実行できません。たとえば Transform Message コンポーネント (​`ee:transform`​) など。ログで該当する文字列は ​`CPU_INTENSIVE`​ です。 特定のコンポーネントやモジュールがサポートする処理種別については、それらのドキュメントを参照してください。指定しない場合、デフォルトの種別は CPU Light (CPU 負荷小) です。 Mule SDK を使用して作成されたコネクタの場合は、コネクタの実装方法に基づいて SDK によって最適な処理種別が決定されます。そのメカニズムについての詳細は、​[Mule SDK のドキュメント](https://docs.mulesoft.com/mule-sdk/latest/)​を参照してください。 ## [](#threading)スレッド Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 この 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。
以前の Mule 4.x バージョンからアップグレードする場合は、​「Threading in Mule 4.2 (Mule 4.2 のスレッド)」​を参照して Mule 4.3 のスレッドモデルに適用される違いを理解してください。
### [](#プロアクターパターン)プロアクターパターン プロアクターは非同期実行のための設計パターンです。プロアクター設計パターンのしくみを理解するには、 [https://en.wikipedia.org/wiki/Proactor\_pattern](https://en.wikipedia.org/wiki/Proactor_pattern) を参照してください。 この設計パターンに従うと、タスクは Mule 処理種別に対応するカテゴリに分類され、各タスクは UBER プールに送信されて実行されます。 パフォーマンステストにより、一意のスレッドプールが 1 つしかなくてもプロアクターパターンを適用するとパフォーマンスが向上することがわかっています。これは、スレッドをよりすばやくメインループに戻すことができ、I/O タスクがブロックされて待機している間もシステムが新しい処理の受け入れを続行できるためです。 ### [](#トランザクション)トランザクション アクティブなトランザクションがある場合は、すべてのスレッド切り替えが停止されます。トランザクションに参加するイベントプロセッサーは同じスレッドで実行されます。 ## [](#設定)設定 スレッドプールは Mule の起動時に自動的に設定され、CPU やメモリなどの利用可能なリソースを考慮する数式が適用されます。 Mule Runtime Engine をオンプレミスで実行している場合、ローカル Mule インスタンスで ​`MULE_HOME/conf/schedulers-pools.conf`​ ファイルを編集することで、これらのグローバル数式を変更できます。この設定ファイルには各プロパティをドキュメント化するコメントが含まれていますが、プール戦略に応じて、固有のプロパティを設定できます。 2 つの使用可能な戦略間で切り替えるように ​`org.mule.runtime.scheduler.SchedulerPoolStrategy`​ パラメーターを設定します。 - UBER 統合スケジュール戦略。デフォルト。 - DEDICATED 分離プール戦略。従来。 ```properties # The strategy to be used for managing the thread pools that back the 3 types of schedulers in the Mule Runtime # (cpu_light, cpu_intensive and I/O). # Possible values are: # - UBER: All three scheduler types will be backed by one uber thread pool (default since 4.3.0) # - DEDICATED: Each scheduler type is backed by its own Thread pool (legacy mode to Mule 4.1.x and 4.2.x) org.mule.runtime.scheduler.SchedulerPoolStrategy=UBER ``` ### [](#uber-スケジュール戦略)UBER スケジュール戦略 戦略が ​`UBER`​ に設定されていると、次の設定が適用されます。 - `org.mule.runtime.scheduler.uber.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.uber.workQueue.size=0` - `org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.coreSize=cores # The maximum number of threads to allow in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding tasks in the uber pool before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.workQueue.size=0 # When the number of threads in the uber pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000 ``` ### [](#dedicated-スケジュール戦略)DEDICATED スケジュール戦略 戦略が ​`DEDICATED`​ に設定されていると、デフォルトの UBER 戦略のパラメーターが無視されます。 この設定を有効にするには、​`schedulers-pools.conf`​ ファイルで次のパラメーターのコメントを解除します。 - `org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuLight.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.io.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000` - `org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the cpu_lite pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores # The size of the queue to use for holding cpu_lite tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.workQueue.size=0 # The number of threads to keep in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.coreSize=cores # The maximum number of threads to allow in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding I/O tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.workQueue.size=0 # When the number of threads in the I/O pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000 # The number of threads to keep in the cpu_intensive pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores # The size of the queue to use for holding cpu_intensive tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores ``` #### [](#考慮事項)考慮事項 使用するプール戦略を変更したり、その設定値を変更したりすることはお勧めしません。この設定はグローバルであり、Mule Runtime インスタンス全体に影響することに注意してください。 実際のシナリオに含まれるすべてのアプリケーションを使用して負荷テストとストレステストを実行することによって、スレッド設定への変更を検証し、Mule 4 でのスレッドプールの動作について理解することをお勧めします。 ### [](#アプリケーションレベルでの設定)アプリケーションレベルでの設定 アプリケーションコードに次のコードを追加することで、アプリケーションで使用するプール戦略を定義できます。 ```xml ``` `poolStrategy`​ パラメーターは後方互換性を確保するために存在しており、以前の Mule バージョンの 3 つのプールのスキームに戻ることができます。 ```xml ``` `gracefulShutdownTimeout`​ パラメーターは、スケジューラーサービスを停止したときにすべてのアーティファクトスレッドプールのすべてのタスクで実行を完了するまで待機する最大時間 (ミリ秒) を指定します。 次の表に、設定可能なプロパティと各項目の XML 属性を示します。
プロパティ名 XML 説明

Pool Size (プールサイズ)

poolSize

アイドル状態であってもプール内で保持するスレッドの数。

キューサイズ

queueSize

実行前にタスクを保持するために使用するキューのサイズ。

Core Pool Size (コアプールサイズ)

corePoolSize

プール内で保持するスレッドの数。

Max Pool Size (最大プールサイズ)

maxPoolSize

プールに含めることができるスレッドの最大数。

Keep Alive (キープアライブ)

keepAlive

プール内のスレッドの数が指定されたコアプールサイズを上回る場合、この値により、超過するアイドル状態のスレッドが終了前に新しいタスクを待機する最大時間 (ミリ秒) を設定します。
#### [](#考慮事項-2)考慮事項 アプリケーションレベルでプール設定を適用すると、Mule アプリケーション用の完全に新しいスレッドプールセットが作成されます。この設定によって ​`scheduler-conf.properties`​ のデフォルト設定は変更されません。オンプレミスデプロイメントでは同じ Mule インスタンスに多くの Mule アプリケーションをデプロイされるため、特にこれが重要です。 デフォルトの設定を使用して Mule を実行することをお勧めします。 Mule 4.1.x または Mule 4.2.x からアップグレードする場合、​`scheduler-conf.properties`​ に対するすべてのカスタマイズが引き続き使用されるように、DEDICATED 戦略を使用できます。ただし、最適化がまだ必要かどうかを判断するために新しいデフォルト設定をテストすることをお勧めします。また、従来のモードに戻す前に、まず新しい UBER 戦略をカスタマイズしてみてください。
CloudHub にデプロイされた Mule アプリケーションのアプリケーションレベルでプール設定を定義する場合、断片的 vCore はメモリが少ないため、ワーカーサイズに注意してください。詳細は、​「CloudHub ワーカー」​を参照してください。
## [](#カスタムスレッドプール)カスタムスレッドプール 一意の UBER スレッドプールに加えて、一部のコンポーネントによって特定の目的のために次のような追加プールが作成される場合があります。 - NIO セレクター 非ブロック I/O を有効にします。各コネクタは、必要に応じて何個でも作成できます。 - 繰り返しタスクプール 一部のコネクタやコンポーネント (有効期限監視、キューコンシューマーなど) によって、繰り返しタスクを実行するための特定のプールが作成される場合があります。 ## [](#backpressure)バックプレッシャー管理 バックプレッシャーは、負荷が大きい場合に Mule が特定のイベントを処理するために使用可能なリソースがないときに発生する可能性があります。この問題は、スレッドがすべて使用中で新しく受信したイベントのハンドオフを実行できない場合や、現在のフローの ​`maxConcurrency`​ 値をすでに超過している場合に発生する可能性があります。 Mule がイベントを処理できない場合、その状況に関する次のメッセージが記録されます: `Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。また、フローのソースには、必要なアクションを実行するように通知されます。 バックプレッシャーのために Mule が実行するアクションは、各コネクタの取得元に固有です。たとえば、​`http:listener`​ は ​`503`​ エラーコードを返す可能性があり、メッセージブローカーリスナーはリソースが使用可能になるまで待つかメッセージを削除する可能性があります。 場合によっては、取得元は処理しきれないデータを取得しないようにリモートシステムから切断し、サーバーが正常な状態に戻った後に再接続することがあります。 ## [](#upgrading-from-4-x)Mule 4.2 または 4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - カスタムスレッド設定が適用されない場合 (​`scheduler-pools.conf`​ を使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - カスタムスレッド設定が適用される場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。 カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 ## [](#トラブルシューティング)トラブルシューティング Mule アプリケーションのトラブルシューティングを行う場合は、スレッドの命名規則を考慮してください。 たとえば、次のフローがあるとします。 ```xml ``` 実行後に、フローで次のログが生成されます。 ERROR 2020-03-12 19:13:45,292 \[\[MuleRuntime\].uber.07: \[echo\].echoFlow.CPU\_LITE @63e7e52c\] \[event: bd56a240-64ae-11ea-8f7d-f01898419bde\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: request at 2020-03-12T19:13:45.283-03:00\[America/Argentina/Buenos\_Aires\] この場合、スレッド名は ​`uber.07`​ です。Mule では操作の種別もログに記録します。この場合は ​`CPU_LITE`​ です。 スレッド名はスレッドダンプにも表示され、プロファイラーを使用する場合も表示されます。 ![プロファイリングツールのスレッドグループがリストされているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-thread-profiler.png) # 実行エンジン Mule Runtime Engine は、非ブロックで非同期の実行用に調整されたリアクティブ実行エンジンを実装します。 リアクティブプログラミングの詳細は、 [https://en.wikipedia.org/wiki/Reactive\_programming](https://en.wikipedia.org/wiki/Reactive_programming) を参照してください。 タスク指向の実行モデルでは、非ブロック I/O を高い同時実行レベルで透過的に活用できます。つまり、ユーザーはフローのスレッドや非同期性を考慮する必要がありません。Mule フロー内の各操作は実行に関するメタデータを提供するタスクで、Mule はそのメタデータに基づいて調整の決定を行います。 Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、I/O Intensive (I/O 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。 ## [](#processing_types)処理種別 Mule イベントプロセッサーは、実行する処理の種類を Mule に示します。これは、次のいずれかです。 - CPU Light (CPU 負荷小) 短時間の操作 (約 10 ミリ秒) または非ブロック I/O 用。たとえば、ロガー (​`logger`​) や HTTP 要求操作 (​`http:request`​) など。これらのタスクではブロック I/O アクティビティを実行できません。ログで該当する文字列は ​`CPU_LIGHT`​ と ​`CPU_LIGHT_ASYNC`​ です。 - Blocking I/O (ブロック I/O) コール元スレッドをブロックする I/O 用。たとえば、Database Select 操作 (​`db:select`​) や SFTP 読み取り (​`sftp:read`​) など。ログで該当する文字列は ​`BLOCKING`​ と ​`IO`​ です。 - CPU Intensive (CPU 負荷大) CPU の負荷が大きい計算用。通常は実行時間が 10 ミリ秒を超えます。これらのタスクでは I/O アクティビティを実行できません。たとえば Transform Message コンポーネント (​`ee:transform`​) など。ログで該当する文字列は ​`CPU_INTENSIVE`​ です。 特定のコンポーネントやモジュールがサポートする処理種別については、それらのドキュメントを参照してください。指定しない場合、デフォルトの種別は CPU Light (CPU 負荷小) です。 Mule SDK を使用して作成されたコネクタの場合は、コネクタの実装方法に基づいて SDK によって最適な処理種別が決定されます。そのメカニズムについての詳細は、​[Mule SDK のドキュメント](https://docs.mulesoft.com/mule-sdk/latest/)​を参照してください。 ## [](#threading)スレッド Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。 この 1 つのスレッドプールを使用することで Mule の効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。
以前の Mule 4.x バージョンからアップグレードする場合は、​「Threading in Mule 4.2 (Mule 4.2 のスレッド)」​を参照して Mule 4.3 のスレッドモデルに適用される違いを理解してください。
### [](#プロアクターパターン)プロアクターパターン プロアクターは非同期実行のための設計パターンです。プロアクター設計パターンのしくみを理解するには、 [https://en.wikipedia.org/wiki/Proactor\_pattern](https://en.wikipedia.org/wiki/Proactor_pattern) を参照してください。 この設計パターンに従うと、タスクは Mule 処理種別に対応するカテゴリに分類され、各タスクは UBER プールに送信されて実行されます。 パフォーマンステストにより、一意のスレッドプールが 1 つしかなくてもプロアクターパターンを適用するとパフォーマンスが向上することがわかっています。これは、スレッドをよりすばやくメインループに戻すことができ、I/O タスクがブロックされて待機している間もシステムが新しい処理の受け入れを続行できるためです。 ### [](#トランザクション)トランザクション アクティブなトランザクションがある場合は、すべてのスレッド切り替えが停止されます。トランザクションに参加するイベントプロセッサーは同じスレッドで実行されます。 ## [](#設定)設定 スレッドプールは Mule の起動時に自動的に設定され、CPU やメモリなどの利用可能なリソースを考慮する数式が適用されます。 Mule Runtime Engine をオンプレミスで実行している場合、ローカル Mule インスタンスで ​`MULE_HOME/conf/schedulers-pools.conf`​ ファイルを編集することで、これらのグローバル数式を変更できます。この設定ファイルには各プロパティをドキュメント化するコメントが含まれていますが、プール戦略に応じて、固有のプロパティを設定できます。 2 つの使用可能な戦略間で切り替えるように ​`org.mule.runtime.scheduler.SchedulerPoolStrategy`​ パラメーターを設定します。 - UBER 統合スケジュール戦略。デフォルト。 - DEDICATED 分離プール戦略。従来。 ```properties # The strategy to be used for managing the thread pools that back the 3 types of schedulers in the Mule Runtime # (cpu_light, cpu_intensive and I/O). # Possible values are: # - UBER: All three scheduler types will be backed by one uber thread pool (default since 4.3.0) # - DEDICATED: Each scheduler type is backed by its own Thread pool (legacy mode to Mule 4.1.x and 4.2.x) org.mule.runtime.scheduler.SchedulerPoolStrategy=UBER ``` ### [](#uber-スケジュール戦略)UBER スケジュール戦略 戦略が ​`UBER`​ に設定されていると、次の設定が適用されます。 - `org.mule.runtime.scheduler.uber.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.uber.workQueue.size=0` - `org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.coreSize=cores # The maximum number of threads to allow in the uber pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding tasks in the uber pool before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER org.mule.runtime.scheduler.uber.workQueue.size=0 # When the number of threads in the uber pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # Only applies when org.mule.runtime.scheduler.threadPool.strategy=UBER # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000 ``` ### [](#dedicated-スケジュール戦略)DEDICATED スケジュール戦略 戦略が ​`DEDICATED`​ に設定されていると、デフォルトの UBER 戦略のパラメーターが無視されます。 この設定を有効にするには、​`schedulers-pools.conf`​ ファイルで次のパラメーターのコメントを解除します。 - `org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuLight.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.coreSize=cores` - `org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120))` - `org.mule.runtime.scheduler.io.workQueue.size=0` - `org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000` - `org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores` - `org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores` `schedulers-pools.conf`​ ファイルの例: ```properties # The number of threads to keep in the cpu_lite pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores # The size of the queue to use for holding cpu_lite tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuLight.workQueue.size=0 # The number of threads to keep in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.coreSize=cores # The maximum number of threads to allow in the I/O pool. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem - 245760) / 5120)) # The size of the queue to use for holding I/O tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.workQueue.size=0 # When the number of threads in the I/O pool is greater than SchedulerService.io.coreThreadPoolSize, this is the maximum # time (in milliseconds) that excess idle threads will wait for new tasks before terminating. # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000 # The number of threads to keep in the cpu_intensive pool, even if they are idle. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores # The size of the queue to use for holding cpu_intensive tasks before they are executed. # Supports Expressions # Only applies when org.mule.runtime.scheduler.threadPool.strategy=DEDICATED org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores ``` #### [](#考慮事項)考慮事項 使用するプール戦略を変更したり、その設定値を変更したりすることはお勧めしません。この設定はグローバルであり、Mule Runtime インスタンス全体に影響することに注意してください。 実際のシナリオに含まれるすべてのアプリケーションを使用して負荷テストとストレステストを実行することによって、スレッド設定への変更を検証し、Mule 4 でのスレッドプールの動作について理解することをお勧めします。 ### [](#アプリケーションレベルでの設定)アプリケーションレベルでの設定 アプリケーションコードに次のコードを追加することで、アプリケーションで使用するプール戦略を定義できます。 ```xml ``` `poolStrategy`​ パラメーターは後方互換性を確保するために存在しており、以前の Mule バージョンの 3 つのプールのスキームに戻ることができます。 ```xml ``` `gracefulShutdownTimeout`​ パラメーターは、スケジューラーサービスを停止したときにすべてのアーティファクトスレッドプールのすべてのタスクで実行を完了するまで待機する最大時間 (ミリ秒) を指定します。 次の表に、設定可能なプロパティと各項目の XML 属性を示します。
プロパティ名 XML 説明

Pool Size (プールサイズ)

poolSize

アイドル状態であってもプール内で保持するスレッドの数。

キューサイズ

queueSize

実行前にタスクを保持するために使用するキューのサイズ。

Core Pool Size (コアプールサイズ)

corePoolSize

プール内で保持するスレッドの数。

Max Pool Size (最大プールサイズ)

maxPoolSize

プールに含めることができるスレッドの最大数。

Keep Alive (キープアライブ)

keepAlive

プール内のスレッドの数が指定されたコアプールサイズを上回る場合、この値により、超過するアイドル状態のスレッドが終了前に新しいタスクを待機する最大時間 (ミリ秒) を設定します。
#### [](#考慮事項-2)考慮事項 アプリケーションレベルでプール設定を適用すると、Mule アプリケーション用の完全に新しいスレッドプールセットが作成されます。この設定によって ​`scheduler-conf.properties`​ のデフォルト設定は変更されません。オンプレミスデプロイメントでは同じ Mule インスタンスに多くの Mule アプリケーションをデプロイされるため、特にこれが重要です。 デフォルトの設定を使用して Mule を実行することをお勧めします。 Mule 4.1.x または Mule 4.2.x からアップグレードする場合、​`scheduler-conf.properties`​ に対するすべてのカスタマイズが引き続き使用されるように、DEDICATED 戦略を使用できます。ただし、最適化がまだ必要かどうかを判断するために新しいデフォルト設定をテストすることをお勧めします。また、従来のモードに戻す前に、まず新しい UBER 戦略をカスタマイズしてみてください。
CloudHub にデプロイされた Mule アプリケーションのアプリケーションレベルでプール設定を定義する場合、断片的 vCore はメモリが少ないため、ワーカーサイズに注意してください。詳細は、​「CloudHub ワーカー」​を参照してください。
## [](#カスタムスレッドプール)カスタムスレッドプール 一意の UBER スレッドプールに加えて、一部のコンポーネントによって特定の目的のために次のような追加プールが作成される場合があります。 - NIO セレクター 非ブロック I/O を有効にします。各コネクタは、必要に応じて何個でも作成できます。 - 繰り返しタスクプール 一部のコネクタやコンポーネント (有効期限監視、キューコンシューマーなど) によって、繰り返しタスクを実行するための特定のプールが作成される場合があります。 ## [](#backpressure)バックプレッシャー管理 バックプレッシャーは、負荷が大きい場合に Mule が特定のイベントを処理するために使用可能なリソースがないときに発生する可能性があります。この問題は、スレッドがすべて使用中で新しく受信したイベントのハンドオフを実行できない場合や、現在のフローの ​`maxConcurrency`​ 値をすでに超過している場合に発生する可能性があります。 Mule がイベントを処理できない場合、その状況に関する次のメッセージが記録されます: `Flow 'flowName' is unable to accept new events at this time`​ (フロー「flowName」は、現在新しいイベントを受け付けられません)。また、フローのソースには、必要なアクションを実行するように通知されます。 バックプレッシャーのために Mule が実行するアクションは、各コネクタの取得元に固有です。たとえば、​`http:listener`​ は ​`503`​ エラーコードを返す可能性があり、メッセージブローカーリスナーはリソースが使用可能になるまで待つかメッセージを削除する可能性があります。 場合によっては、取得元は処理しきれないデータを取得しないようにリモートシステムから切断し、サーバーが正常な状態に戻った後に再接続することがあります。 ## [](#upgrading-from-4-x)Mule 4.2 または 4.1 からのアップグレード Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。 - カスタムスレッド設定が適用されない場合 (​`scheduler-pools.conf`​ を使用、または Mule アプリケーションで直接)、アクションは必要ありません。 - カスタムスレッド設定が適用される場合、デフォルト設定を使用して Mule アプリケーションをテストします。 UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。 - テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。 カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。 ## [](#トラブルシューティング)トラブルシューティング Mule アプリケーションのトラブルシューティングを行う場合は、スレッドの命名規則を考慮してください。 たとえば、次のフローがあるとします。 ```xml ``` 実行後に、フローで次のログが生成されます。 ERROR 2020-03-12 19:13:45,292 \[\[MuleRuntime\].uber.07: \[echo\].echoFlow.CPU\_LITE @63e7e52c\] \[event: bd56a240-64ae-11ea-8f7d-f01898419bde\] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: request at 2020-03-12T19:13:45.283-03:00\[America/Argentina/Buenos\_Aires\] この場合、スレッド名は ​`uber.07`​ です。Mule では操作の種別もログに記録します。この場合は ​`CPU_LITE`​ です。 スレッド名はスレッドダンプにも表示され、プロファイラーを使用する場合も表示されます。 ![プロファイリングツールのスレッドグループがリストされているテーブル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-thread-profiler.png) # 対象変数への Enricher の移行 Mule 3 の Message Enricher とその機能は、Mule 4 で ​`target`​ パラメーターに置き換わります。Enricher では、メッセージプロセッサーのグループを実行し、現在のメッセージへの副作用がなく、出力を変数にリダイレクトすることができました。Mule 4 では、すべての non-void の操作 (​``​、​``​、​``​ など) には ​`target`​ パラメーターと ​`targetValue`​ パラメーターが含まれ、各操作の出力を変数 (​`myVar`​ など) にリダイレクトできます。その後、Mule フローのその他のコンポーネントは、DataWeave セレクター (​`vars.myVar`​ など) を使用してそのデータにアクセスできます。 ## [](#例)例 HTTP 要求から発生し、第 3 のシステムにリダイレクトする必要があるメッセージを考えてください。これに、​`stateLookup`​ と呼ばれる 2 次フローを使用して抽出される ​`state`​ クエリパラメーターを追加します。元のペイロードまたはヘッダーを失いたくないので、元のメッセージに影響を及ぼさずにこの値を抽出する必要があります。Enricher は (郵便番号が含まれている) 現在のメッセージを使用してエンリッチメントリソースをコールアウトし、その結果でメッセージをエンリッチします。 Mule 3 の例 Mule 4 では、​``​ 操作で ​`target`​ パラメーターを使用できます。 Mule 4 の例 #\[{'state' : vars.state}\] ## [](#複数の-enricher-の移行)複数の Enricher の移行 Mule 4 では、操作ごとに 1 つの ​`target`​ 変数のみを設定できます。Mule 3 アプリケーションで複数の Enricher を設定している場合、Mule 4 では ​`Set Variable`​ コンポーネントを使用して同じ動作を実行できます。 Mule 3 の例 ... ... Mule 4 の例 ... ... ## [](#関連情報)関連情報 - [対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.3/target-variables) # 対象変数への Enricher の移行 Mule 3 の Message Enricher とその機能は、Mule 4 で ​`target`​ パラメーターに置き換わります。Enricher では、メッセージプロセッサーのグループを実行し、現在のメッセージへの副作用がなく、出力を変数にリダイレクトすることができました。Mule 4 では、すべての non-void の操作 (​``​、​``​、​``​ など) には ​`target`​ パラメーターと ​`targetValue`​ パラメーターが含まれ、各操作の出力を変数 (​`myVar`​ など) にリダイレクトできます。その後、Mule フローのその他のコンポーネントは、DataWeave セレクター (​`vars.myVar`​ など) を使用してそのデータにアクセスできます。 ## [](#例)例 HTTP 要求から発生し、第 3 のシステムにリダイレクトする必要があるメッセージを考えてください。これに、​`stateLookup`​ と呼ばれる 2 次フローを使用して抽出される ​`state`​ クエリパラメーターを追加します。元のペイロードまたはヘッダーを失いたくないので、元のメッセージに影響を及ぼさずにこの値を抽出する必要があります。Enricher は (郵便番号が含まれている) 現在のメッセージを使用してエンリッチメントリソースをコールアウトし、その結果でメッセージをエンリッチします。 Mule 3 の例 Mule 4 では、​``​ 操作で ​`target`​ パラメーターを使用できます。 Mule 4 の例 #\[{'state' : vars.state}\] ## [](#複数の-enricher-の移行)複数の Enricher の移行 Mule 4 では、操作ごとに 1 つの ​`target`​ 変数のみを設定できます。Mule 3 アプリケーションで複数の Enricher を設定している場合、Mule 4 では ​`Set Variable`​ コンポーネントを使用して同じ動作を実行できます。 Mule 3 の例 ... ... Mule 4 の例 ... ... ## [](#関連情報)関連情報 - [対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.4/target-variables) # 対象変数への Enricher の移行 Mule 3 の Message Enricher とその機能は、Mule 4 で ​`target`​ パラメーターに置き換わります。Enricher では、メッセージプロセッサーのグループを実行し、現在のメッセージへの副作用がなく、出力を変数にリダイレクトすることができました。Mule 4 では、すべての non-void の操作 (​``​、​``​、​``​ など) には ​`target`​ パラメーターと ​`targetValue`​ パラメーターが含まれ、各操作の出力を変数 (​`myVar`​ など) にリダイレクトできます。その後、Mule フローのその他のコンポーネントは、DataWeave セレクター (​`vars.myVar`​ など) を使用してそのデータにアクセスできます。 ## [](#例)例 HTTP 要求から発生し、第 3 のシステムにリダイレクトする必要があるメッセージを考えてください。これに、​`stateLookup`​ と呼ばれる 2 次フローを使用して抽出される ​`state`​ クエリパラメーターを追加します。元のペイロードまたはヘッダーを失いたくないので、元のメッセージに影響を及ぼさずにこの値を抽出する必要があります。Enricher は (郵便番号が含まれている) 現在のメッセージを使用してエンリッチメントリソースをコールアウトし、その結果でメッセージをエンリッチします。 Mule 3 の例 Mule 4 では、​``​ 操作で ​`target`​ パラメーターを使用できます。 Mule 4 の例 #\[{'state' : vars.state}\] ## [](#複数の-enricher-の移行)複数の Enricher の移行 Mule 4 では、操作ごとに 1 つの ​`target`​ 変数のみを設定できます。Mule 3 アプリケーションで複数の Enricher を設定している場合、Mule 4 では ​`Set Variable`​ コンポーネントを使用して同じ動作を実行できます。 Mule 3 の例 ... ... Mule 4 の例 ... ... ## [](#関連情報)関連情報 - [対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.5/target-variables) # 対象変数への Enricher の移行 Mule 3 の Message Enricher とその機能は、Mule 4 で ​`target`​ パラメーターに置き換わります。Enricher では、メッセージプロセッサーのグループを実行し、現在のメッセージへの副作用がなく、出力を変数にリダイレクトすることができました。Mule 4 では、すべての non-void の操作 (​``​、​``​、​``​ など) には ​`target`​ パラメーターと ​`targetValue`​ パラメーターが含まれ、各操作の出力を変数 (​`myVar`​ など) にリダイレクトできます。その後、Mule フローのその他のコンポーネントは、DataWeave セレクター (​`vars.myVar`​ など) を使用してそのデータにアクセスできます。 ## [](#例)例 HTTP 要求から発生し、第 3 のシステムにリダイレクトする必要があるメッセージを考えてください。これに、​`stateLookup`​ と呼ばれる 2 次フローを使用して抽出される ​`state`​ クエリパラメーターを追加します。元のペイロードまたはヘッダーを失いたくないので、元のメッセージに影響を及ぼさずにこの値を抽出する必要があります。Enricher は (郵便番号が含まれている) 現在のメッセージを使用してエンリッチメントリソースをコールアウトし、その結果でメッセージをエンリッチします。 Mule 3 の例 Mule 4 では、​``​ 操作で ​`target`​ パラメーターを使用できます。 Mule 4 の例 #\[{'state' : vars.state}\] ## [](#複数の-enricher-の移行)複数の Enricher の移行 Mule 4 では、操作ごとに 1 つの ​`target`​ 変数のみを設定できます。Mule 3 アプリケーションで複数の Enricher を設定している場合、Mule 4 では ​`Set Variable`​ コンポーネントを使用して同じ動作を実行できます。 Mule 3 の例 ... ... Mule 4 の例 ... ... ## [](#関連情報)関連情報 - [対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.6/target-variables) # 対象変数への Enricher の移行 Mule 3 の Message Enricher とその機能は、Mule 4 で ​`target`​ パラメーターに置き換わります。Enricher では、メッセージプロセッサーのグループを実行し、現在のメッセージへの副作用がなく、出力を変数にリダイレクトすることができました。Mule 4 では、すべての non-void の操作 (​``​、​``​、​``​ など) には ​`target`​ パラメーターと ​`targetValue`​ パラメーターが含まれ、各操作の出力を変数 (​`myVar`​ など) にリダイレクトできます。その後、Mule フローのその他のコンポーネントは、DataWeave セレクター (​`vars.myVar`​ など) を使用してそのデータにアクセスできます。 ## [](#例)例 HTTP 要求から発生し、第 3 のシステムにリダイレクトする必要があるメッセージを考えてください。これに、​`stateLookup`​ と呼ばれる 2 次フローを使用して抽出される ​`state`​ クエリパラメーターを追加します。元のペイロードまたはヘッダーを失いたくないので、元のメッセージに影響を及ぼさずにこの値を抽出する必要があります。Enricher は (郵便番号が含まれている) 現在のメッセージを使用してエンリッチメントリソースをコールアウトし、その結果でメッセージをエンリッチします。 Mule 3 の例 Mule 4 では、​``​ 操作で ​`target`​ パラメーターを使用できます。 Mule 4 の例 #\[{'state' : vars.state}\] ## [](#複数の-enricher-の移行)複数の Enricher の移行 Mule 4 では、操作ごとに 1 つの ​`target`​ 変数のみを設定できます。Mule 3 アプリケーションで複数の Enricher を設定している場合、Mule 4 では ​`Set Variable`​ コンポーネントを使用して同じ動作を実行できます。 Mule 3 の例 ... ... Mule 4 の例 ... ... ## [](#関連情報)関連情報 - [対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.7/target-variables) # 対象変数への Enricher の移行 Mule 3 の Message Enricher とその機能は、Mule 4 で ​`target`​ パラメーターに置き換わります。Enricher では、メッセージプロセッサーのグループを実行し、現在のメッセージへの副作用がなく、出力を変数にリダイレクトすることができました。Mule 4 では、すべての non-void の操作 (​``​、​``​、​``​ など) には ​`target`​ パラメーターと ​`targetValue`​ パラメーターが含まれ、各操作の出力を変数 (​`myVar`​ など) にリダイレクトできます。その後、Mule フローのその他のコンポーネントは、DataWeave セレクター (​`vars.myVar`​ など) を使用してそのデータにアクセスできます。 ## [](#例)例 HTTP 要求から発生し、第 3 のシステムにリダイレクトする必要があるメッセージを考えてください。これに、​`stateLookup`​ と呼ばれる 2 次フローを使用して抽出される ​`state`​ クエリパラメーターを追加します。元のペイロードまたはヘッダーを失いたくないので、元のメッセージに影響を及ぼさずにこの値を抽出する必要があります。Enricher は (郵便番号が含まれている) 現在のメッセージを使用してエンリッチメントリソースをコールアウトし、その結果でメッセージをエンリッチします。 Mule 3 の例 Mule 4 では、​``​ 操作で ​`target`​ パラメーターを使用できます。 Mule 4 の例 #\[{'state' : vars.state}\] ## [](#複数の-enricher-の移行)複数の Enricher の移行 Mule 4 では、操作ごとに 1 つの ​`target`​ 変数のみを設定できます。Mule 3 アプリケーションで複数の Enricher を設定している場合、Mule 4 では ​`Set Variable`​ コンポーネントを使用して同じ動作を実行できます。 Mule 3 の例 ... ... Mule 4 の例 ... ... ## [](#関連情報)関連情報 - [対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.8/target-variables) # 対象変数への Enricher の移行 Mule 3 の Message Enricher とその機能は、Mule 4 で ​`target`​ パラメーターに置き換わります。Enricher では、メッセージプロセッサーのグループを実行し、現在のメッセージへの副作用がなく、出力を変数にリダイレクトすることができました。Mule 4 では、すべての non-void の操作 (​``​、​``​、​``​ など) には ​`target`​ パラメーターと ​`targetValue`​ パラメーターが含まれ、各操作の出力を変数 (​`myVar`​ など) にリダイレクトできます。その後、Mule フローのその他のコンポーネントは、DataWeave セレクター (​`vars.myVar`​ など) を使用してそのデータにアクセスできます。 ## [](#例)例 HTTP 要求から発生し、第 3 のシステムにリダイレクトする必要があるメッセージを考えてください。これに、​`stateLookup`​ と呼ばれる 2 次フローを使用して抽出される ​`state`​ クエリパラメーターを追加します。元のペイロードまたはヘッダーを失いたくないので、元のメッセージに影響を及ぼさずにこの値を抽出する必要があります。Enricher は (郵便番号が含まれている) 現在のメッセージを使用してエンリッチメントリソースをコールアウトし、その結果でメッセージをエンリッチします。 Mule 3 の例 Mule 4 では、​``​ 操作で ​`target`​ パラメーターを使用できます。 Mule 4 の例 #\[{'state' : vars.state}\] ## [](#複数の-enricher-の移行)複数の Enricher の移行 Mule 4 では、操作ごとに 1 つの ​`target`​ 変数のみを設定できます。Mule 3 アプリケーションで複数の Enricher を設定している場合、Mule 4 では ​`Set Variable`​ コンポーネントを使用して同じ動作を実行できます。 Mule 3 の例 ... ... Mule 4 の例 ... ... ## [](#関連情報)関連情報 - [対象変数](https://docs.mulesoft.com/jp/mule-runtime/4.9/target-variables) # 対象変数を使用したデータの強化 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - Target (対象) (​`target`​): メッセージデータを格納する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ## [](#考慮事項)考慮事項 対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化します。通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。 ![メッセージフローの標準動作](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-payload-flow.png) 他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 ![対象変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-payload-flow-target-variable.png) 対象変数を設定すると、既存の変数の動作にも影響します。既存の変数は、対象変数の操作の処理が終了した後、元の値を保持します。たとえば、フローで変数 1 と 2 を設定したとします。その後の操作で変数 1 と 2 が変更され、対象変数 A も出力されます。この場合、操作の実行後に変数 1 と 2 は以前の値に戻ります。 ![対象変数と追加の変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/mruntime-payload-flow-target-variable-2.png)
1コンポーネントによって対象変数が設定されたため、変数 1 と 2 はコンポーネントの実行後に以前の値に戻ります。
## [](#対象変数の設定例)対象変数の設定例 次の例では、​`readme.txt`​ のペイロードを ​`myVar`​ に保存する Read 操作を設定します。 ```xml ``` デフォルトでは完全なペイロードが ​`myVar`​ 対象変数に保存されます。ペイロードとは異なる値を保存する場合は、対象値 (​`targetValue`​) を指定するだけで済みます。 この例では、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合、変数 ​`myVar`​ にはファイルのコンテンツのほか、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` この例では、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{'description' : payload}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対して Bulk Insert 操作を使用してレコードを挿入したいのですが、この操作は成功メッセージを返して現在のペイロードを置き換えてしまうため、レコードにはアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [対象変数にデータを保存するプロセッサーのテスト](https://docs.mulesoft.com/munit/latest/test-processor-that-uses-target-variable) - [Mule 4 プログラミングモデル](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-programming-model) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-variables) # 対象変数を使用したデータの強化 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - Target (対象) (​`target`​): メッセージデータを格納する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ## [](#考慮事項)考慮事項 - 対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化します。 通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。 ![メッセージフローの標準動作](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-payload-flow.png) 他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 ![対象変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-payload-flow-target-variable.png) - 対象変数を設定すると、既存の変数の動作に影響します。 既存の変数は、対象変数の操作が処理を完了した後も元の値を維持します。たとえば、フローで変数 1 と 2 を設定したとします。その後の操作で変数 1 と 2 が変更され、対象変数 A も出力されます。この場合、操作の実行後に変数 1 と 2 は以前の値に戻ります。 ![対象変数と追加の変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/mruntime-payload-flow-target-variable-2.png)
1コンポーネントによって対象変数が設定されたため、変数 1 と 2 はコンポーネントの実行後に以前の値に戻ります。
- エラーが発生した場合は、対象変数は設定されません。 エラーが発生するとフローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#対象変数の設定例)対象変数の設定例 次の例では、​`readme.txt`​ のペイロードを ​`myVar`​ に保存する Read 操作を設定します。 ```xml ``` デフォルトでは完全なペイロードが ​`myVar`​ 対象変数に保存されます。ペイロードとは異なる値を保存する場合は、対象値 (​`targetValue`​) を指定するだけで済みます。 この例では、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合、変数 ​`myVar`​ にはファイルのコンテンツのほか、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` この例では、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{'description' : payload}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対して Bulk Insert 操作を使用してレコードを挿入したいのですが、この操作は成功メッセージを返して現在のペイロードを置き換えてしまうため、レコードにはアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [対象変数にデータを保存するプロセッサーのテスト](https://docs.mulesoft.com/munit/latest/test-processor-that-uses-target-variable) - [Mule 4 プログラミングモデル](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-programming-model) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-variables) # 対象変数を使用したデータの強化 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - Target (対象) (​`target`​): メッセージデータを格納する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ## [](#考慮事項)考慮事項 - 対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化します。 通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。 ![メッセージフローの標準動作](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-payload-flow.png) 他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 ![対象変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-payload-flow-target-variable.png) - 対象変数を設定すると、既存の変数の動作に影響します。 既存の変数は、対象変数の操作が処理を完了した後も元の値を維持します。たとえば、フローで変数 1 と 2 を設定したとします。その後の操作で変数 1 と 2 が変更され、対象変数 A も出力されます。この場合、操作の実行後に変数 1 と 2 は以前の値に戻ります。 ![対象変数と追加の変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/mruntime-payload-flow-target-variable-2.png)
1コンポーネントによって対象変数が設定されたため、変数 1 と 2 はコンポーネントの実行後に以前の値に戻ります。
- エラーが発生した場合は、対象変数は設定されません。 エラーが発生するとフローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#対象変数の設定例)対象変数の設定例 次の例では、​`readme.txt`​ のペイロードを ​`myVar`​ に保存する Read 操作を設定します。 ```xml ``` デフォルトでは完全なペイロードが ​`myVar`​ 対象変数に保存されます。ペイロードとは異なる値を保存する場合は、対象値 (​`targetValue`​) を指定するだけで済みます。 この例では、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合、変数 ​`myVar`​ にはファイルのコンテンツのほか、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` この例では、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{'description' : payload}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]` そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]` そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日をキャプチャする対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]` ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対して Bulk Insert 操作を使用してレコードを挿入したいのですが、この操作は成功メッセージを返して現在のペイロードを置き換えてしまうため、レコードにはアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [対象変数にデータを保存するプロセッサーのテスト](https://docs.mulesoft.com/munit/latest/test-processor-that-uses-target-variable) - [Mule 4 プログラミングモデル](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-programming-model) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-variables) # 対象変数を使用したデータの強化 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - Target (対象) (​`target`​): メッセージデータを格納する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ## [](#考慮事項)考慮事項 - 対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化します。 通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。 ![メッセージフローの標準動作](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-payload-flow.png) 他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 ![対象変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-payload-flow-target-variable.png) - 対象変数を設定すると、既存の変数の動作に影響します。 既存の変数は、対象変数の操作が処理を完了した後も元の値を維持します。たとえば、フローで変数 1 と 2 を設定したとします。その後の操作で変数 1 と 2 が変更され、対象変数 A も出力されます。この場合、操作の実行後に変数 1 と 2 は以前の値に戻ります。 ![対象変数と追加の変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/mruntime-payload-flow-target-variable-2.png)
1コンポーネントによって対象変数が設定されたため、変数 1 と 2 はコンポーネントの実行後に以前の値に戻ります。
- エラーが発生した場合は、対象変数は設定されません。 エラーが発生するとフローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#対象変数の設定例)対象変数の設定例 次の例では、​`readme.txt`​ のペイロードを ​`myVar`​ に保存する Read 操作を設定します。 ```xml ``` デフォルトでは完全なペイロードが ​`myVar`​ 対象変数に保存されます。ペイロードとは異なる値を保存する場合は、対象値 (​`targetValue`​) を指定するだけで済みます。 この例では、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合、変数 ​`myVar`​ にはファイルのコンテンツのほか、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` この例では、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{'description' : payload}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対して Bulk Insert 操作を使用してレコードを挿入したいのですが、この操作は成功メッセージを返して現在のペイロードを置き換えてしまうため、レコードにはアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [対象変数にデータを保存するプロセッサーのテスト](https://docs.mulesoft.com/munit/latest/test-processor-that-uses-target-variable) - [Mule 4 プログラミングモデル](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-programming-model) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-variables) # 対象変数を使用したデータの強化 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - Target (対象) (​`target`​): メッセージデータを格納する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ## [](#考慮事項)考慮事項 - 対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化します。 通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。 ![メッセージフローの標準動作](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-payload-flow.png) 他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 ![対象変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-payload-flow-target-variable.png) - 対象変数を設定すると、既存の変数の動作に影響します。 既存の変数は、対象変数の操作が処理を完了した後も元の値を維持します。たとえば、フローで変数 1 と 2 を設定したとします。その後の操作で変数 1 と 2 が変更され、対象変数 A も出力されます。この場合、操作の実行後に変数 1 と 2 は以前の値に戻ります。 ![対象変数と追加の変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/mruntime-payload-flow-target-variable-2.png)
1コンポーネントによって対象変数が設定されたため、変数 1 と 2 はコンポーネントの実行後に以前の値に戻ります。
- エラーが発生した場合は、対象変数は設定されません。 エラーが発生するとフローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#対象変数の設定例)対象変数の設定例 次の例では、​`readme.txt`​ のペイロードを ​`myVar`​ に保存する Read 操作を設定します。 ```xml ``` デフォルトでは完全なペイロードが ​`myVar`​ 対象変数に保存されます。ペイロードとは異なる値を保存する場合は、対象値 (​`targetValue`​) を指定するだけで済みます。 この例では、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合、変数 ​`myVar`​ にはファイルのコンテンツのほか、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` この例では、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{'description' : payload}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対して Bulk Insert 操作を使用してレコードを挿入したいのですが、この操作は成功メッセージを返して現在のペイロードを置き換えてしまうため、レコードにはアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [対象変数にデータを保存するプロセッサーのテスト](https://docs.mulesoft.com/munit/latest/test-processor-that-uses-target-variable) - [Mule 4 プログラミングモデル](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-programming-model) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-variables) # 対象変数を使用したデータの強化 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - Target (対象) (​`target`​): メッセージデータを格納する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ## [](#考慮事項)考慮事項 - 対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化します。 通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。 ![メッセージフローの標準動作](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-payload-flow.png) 他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 ![対象変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-payload-flow-target-variable.png) - 対象変数を設定すると、既存の変数の動作に影響します。 既存の変数は、対象変数の操作が処理を完了した後も元の値を維持します。たとえば、フローで変数 1 と 2 を設定したとします。その後の操作で変数 1 と 2 が変更され、対象変数 A も出力されます。この場合、操作の実行後に変数 1 と 2 は以前の値に戻ります。 ![対象変数と追加の変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/mruntime-payload-flow-target-variable-2.png)
1コンポーネントによって対象変数が設定されたため、変数 1 と 2 はコンポーネントの実行後に以前の値に戻ります。
- エラーが発生した場合は、対象変数は設定されません。 エラーが発生するとフローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#対象変数の設定例)対象変数の設定例 次の例では、​`readme.txt`​ のペイロードを ​`myVar`​ に保存する Read 操作を設定します。 ```xml ``` デフォルトでは完全なペイロードが ​`myVar`​ 対象変数に保存されます。ペイロードとは異なる値を保存する場合は、対象値 (​`targetValue`​) を指定するだけで済みます。 この例では、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合、変数 ​`myVar`​ にはファイルのコンテンツのほか、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` この例では、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{'description' : payload}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対して Bulk Insert 操作を使用してレコードを挿入したいのですが、この操作は成功メッセージを返して現在のペイロードを置き換えてしまうため、レコードにはアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [対象変数にデータを保存するプロセッサーのテスト](https://docs.mulesoft.com/munit/latest/test-processor-that-uses-target-variable) - [Mule 4 プログラミングモデル](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-programming-model) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-variables) # 対象変数を使用したデータの強化 Mule アプリケーションでフローを作成するときに、データを変数に保存して、フローのどのコンポーネントでも使用できるようにする必要のある場合があります。non-void の操作 (File Connector に対する Read 操作など) では、返すメッセージデータを変数に保存できます。Target (対象) (​`target`​) パラメーターを指定して作成した変数を定義すると、フロー内で使用できるようになり、他の変数の場合と同じようにアクセスできます。 多くの場合は、次のパラメーターを指定して変数を定義します。 - Target (対象) (​`target`​): メッセージデータを格納する変数の名前。数字、文字、アンダースコアのみを使用できます。たとえば、名前にハイフンは使用できません。 - 対象値 (​`targetValue`​): 対象変数に保存するデータの値。このデフォルト値はメッセージペイロード (​`payload`​) です。この項目は、変数が受け入れるすべての値を受け入れます。サポートされているデータ型、DataWeave の式、​`payload`​、​`attributes`​、​`message`​ キーワードが該当しますが、​`vars`​ キーワードは​_対象外_​です。 ## [](#考慮事項)考慮事項 - 対象変数を設定すると、フローにおけるメッセージの典型的な進路が変化します。 通常、操作で出力されるメッセージは、入力として受け取ったものとは異なります。 ![メッセージフローの標準動作](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-payload-flow.png) 他方、操作からの変数を設定した場合は、操作によってフローの​_次の_​コンポーネントに、入力として受け取ったものと同じメッセージが出力されます。たとえば、フローにコンポーネント A、次に ​`myMessage`​ の対象値を指定したコンポーネント B、続いてコンポーネント C があるとします。 この場合、コンポーネント C は、B が A から受信したものと同じメッセージを受信します。 ![対象変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-payload-flow-target-variable.png) - 対象変数を設定すると、既存の変数の動作に影響します。 既存の変数は、対象変数の操作が処理を完了した後も元の値を維持します。たとえば、フローで変数 1 と 2 を設定したとします。その後の操作で変数 1 と 2 が変更され、対象変数 A も出力されます。この場合、操作の実行後に変数 1 と 2 は以前の値に戻ります。 ![対象変数と追加の変数を使用したメッセージフロー](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/mruntime-payload-flow-target-variable-2.png)
1コンポーネントによって対象変数が設定されたため、変数 1 と 2 はコンポーネントの実行後に以前の値に戻ります。
- エラーが発生した場合は、対象変数は設定されません。 エラーが発生するとフローの実行が停止して正常に終了しないため、対象変数は設定されません。 ## [](#対象変数の設定例)対象変数の設定例 次の例では、​`readme.txt`​ のペイロードを ​`myVar`​ に保存する Read 操作を設定します。 ```xml ``` デフォルトでは完全なペイロードが ​`myVar`​ 対象変数に保存されます。ペイロードとは異なる値を保存する場合は、対象値 (​`targetValue`​) を指定するだけで済みます。 この例では、​`myVar`​ にメッセージ全体が保存されます。 ```xml ``` この場合、変数 ​`myVar`​ にはファイルのコンテンツのほか、関連するすべてのメタデータも含まれます。 - ファイルのコンテンツにアクセスする式: `#[myVar.payload]` - ファイルのメタデータにアクセスする式: `#[myVar.attributes]` この例では、ファイルサイズのみが ​`myVar`​ に保存されます。 ```xml ``` 以下の各シナリオで、対象変数を使用することが考えられる数種のケースについて説明します。 ## [](#シナリオ-操作内から対象変数を設定する)シナリオ: 操作内から対象変数を設定する Database Connector の操作 (Insert など) で返されたメッセージ全体 (ペイロードと属性) をログに記録するとします。操作の後に Set Variable コンポーネントを使用するのではなく、対象変数を操作に直接追加すればメッセージデータを取得できます。 ```xml INSERT INTO PLANET(POSITION, NAME, DESCRIPTION) VALUES (777, 'Pluto', :description) #[{'description' : payload}] ``` - Insert 操作の対象変数: `result` - 対象値: Design Center の ​`message`​、Anypoint Studio の ​`#[message]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `Payload is: #[vars.result.payload] and attributes are: #[vars.result.attributes]` プラネットデータベースの最初のエントリの名前をログに記録するとします。対象変数は、Database Connector の Select 操作を使用して次のように定義できます。 ```xml select * from PLANET order by ID ``` - Select 操作の対象変数: `planetName` - 対象値: Design Center の ​`payload[0].name`​、Anypoint Studio の ​`#[payload[0].name]`​。 そうすると、Logger から次のような結果を取得するものと思われます。 ```xml ``` - メッセージ: `'Planet name is: ' ++ vars.planetName` ## [](#シナリオ-保存された値を操作の入力として使用する)シナリオ: 保存された値を操作の入力として使用する ある惑星が発見された後に発見されたすべての惑星にアクセスしたいとします。Select 操作内に ​`discoveryDate`​ という、惑星の発見日を取得する対象変数を作成することが考えられます。 ```xml select discoveryDate from PLANET where name = :name #[{'name' : 'pluto'}] ``` - Retrieve 操作の対象変数: `discoveryDate` 続いて、たとえば次のように、フローの別の操作 (Database Connector に対する Select 操作など) の入力パラメーターを使用して、クエリでその変数を使用できるようにします。 ```xml select * from PLANET where discoveryDate > :discoveryDate #[{'discoveryDate' : vars.discoveryDate}] ``` - Select 操作の入力パラメーターの定義: - キー: `discoveryDate` - 値: Design Center の ​`vars.discoveryDate`​、Anypoint Studio の ​`#[vars.discoveryDate]`​。 ## [](#シナリオ-通常のメッセージフローをバイパスする)シナリオ: 通常のメッセージフローをバイパスする メッセージのペイロードにある多数のレコードをデータベースに挿入してから、後続の処理のためにこの同じレコードをフローの次のコンポーネントに渡すとします。Database Connector に対して Bulk Insert 操作を使用してレコードを挿入したいのですが、この操作は成功メッセージを返して現在のペイロードを置き換えてしまうため、レコードにはアクセスできなくなります。そこで、ペイロードが Bulk Insert の結果に置換されることなく、結果を次のコンポーネントに渡すために、たとえば次のようにして、成功メッセージを対象変数に保存することが考えられます。 - 対象変数: `bulkInsertResult` これで、フローの次の操作でこのペイロードにあるレコードを処理できます。 ## [](#関連情報)関連情報 - [対象変数にデータを保存するプロセッサーのテスト](https://docs.mulesoft.com/munit/latest/test-processor-that-uses-target-variable) - [Mule 4 プログラミングモデル](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-programming-model) - [Mule イベント](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-event) - [Mule イベントの変数](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-variables) # 属性または変数への変換出力 (Design Center) デフォルトでは、Transform コンポーネントは Mule イベントのメッセージペイロードに出力します。データは、作成する変数や属性に出力することもできます。 まず、Transform コンポーネントに入力データを送信する基本フローをセットアップする必要があります。 1. Transform コンポーネントの \[Mapping (マッピング)\] タブで、\[Output (出力)\] 列のタイトル (デフォルトは「Output Payload (出力ペイロード)」) をクリックします。 2. \[Add Transformation (変換の追加)\] を選択します。 3. 次のいずれかを選択します。 - 属性 - 変数 4. 変数の場合は名前を入力します。 5. 属性または変数のデータ型を作成または選択します。 6. 属性または変数に出力したいトランスフォーマー入力部分をマップします。 次のようにトランスフォーマーの後にロガーを追加することで、マッピングをチェックできます。 - 属性用のロガーメッセージ: `message.attributes` - 変数 ​`myVar`​ 用のロガーメッセージ: `vars.myVar` アプリケーションをデプロイすると、ログにロガーメッセージが出力されます。 ## [](#出力変換を削除する)出力変換を削除する 1. \[Output (出力)\] 列のタイトルをクリックします。 2. 削除したい変換のゴミ箱アイコンをクリックします。 ## [](#関連情報)関連情報 [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.3/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) # 属性または変数への変換出力 (Design Center) デフォルトでは、Transform コンポーネントは Mule イベントのメッセージペイロードに出力します。データは、作成する変数や属性に出力することもできます。 まず、Transform コンポーネントに入力データを送信する基本フローをセットアップする必要があります。 1. Transform コンポーネントの \[Mapping (マッピング)\] タブで、\[Output (出力)\] 列のタイトル (デフォルトは「Output Payload (出力ペイロード)」) をクリックします。 2. \[Add Transformation (変換の追加)\] を選択します。 3. 次のいずれかを選択します。 - 属性 - 変数 4. 変数の場合は名前を入力します。 5. 属性または変数のデータ型を作成または選択します。 6. 属性または変数に出力したいトランスフォーマー入力部分をマップします。 次のようにトランスフォーマーの後にロガーを追加することで、マッピングをチェックできます。 - 属性用のロガーメッセージ: `message.attributes` - 変数 ​`myVar`​ 用のロガーメッセージ: `vars.myVar` アプリケーションをデプロイすると、ログにロガーメッセージが出力されます。 ## [](#出力変換を削除する)出力変換を削除する 1. \[Output (出力)\] 列のタイトルをクリックします。 2. 削除したい変換のゴミ箱アイコンをクリックします。 ## [](#関連情報)関連情報 [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.4/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) # 属性または変数への変換出力 (Design Center) デフォルトでは、Transform コンポーネントは Mule イベントのメッセージペイロードに出力します。データは、作成する変数や属性に出力することもできます。 まず、Transform コンポーネントに入力データを送信する基本フローをセットアップする必要があります。 1. Transform コンポーネントの \[Mapping (マッピング)\] タブで、\[Output (出力)\] 列のタイトル (デフォルトは「Output Payload (出力ペイロード)」) をクリックします。 2. \[Add Transformation (変換の追加)\] を選択します。 3. 次のいずれかを選択します。 - 属性 - 変数 4. 変数の場合は名前を入力します。 5. 属性または変数のデータ型を作成または選択します。 6. 属性または変数に出力したいトランスフォーマー入力部分をマップします。 次のようにトランスフォーマーの後にロガーを追加することで、マッピングをチェックできます。 - 属性用のロガーメッセージ: `message.attributes` - 変数 ​`myVar`​ 用のロガーメッセージ: `vars.myVar` アプリケーションをデプロイすると、ログにロガーメッセージが出力されます。 ## [](#出力変換を削除する)出力変換を削除する 1. \[Output (出力)\] 列のタイトルをクリックします。 2. 削除したい変換のゴミ箱アイコンをクリックします。 ## [](#関連情報)関連情報 [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.5/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) # 属性または変数への変換出力 (Design Center) デフォルトでは、Transform コンポーネントは Mule イベントのメッセージペイロードに出力します。データは、作成する変数や属性に出力することもできます。 まず、Transform コンポーネントに入力データを送信する基本フローをセットアップする必要があります。 1. Transform コンポーネントの \[Mapping (マッピング)\] タブで、\[Output (出力)\] 列のタイトル (デフォルトは「Output Payload (出力ペイロード)」) をクリックします。 2. \[Add Transformation (変換の追加)\] を選択します。 3. 次のいずれかを選択します。 - 属性 - 変数 4. 変数の場合は名前を入力します。 5. 属性または変数のデータ型を作成または選択します。 6. 属性または変数に出力したいトランスフォーマー入力部分をマップします。 次のようにトランスフォーマーの後にロガーを追加することで、マッピングをチェックできます。 - 属性用のロガーメッセージ: `message.attributes` - 変数 ​`myVar`​ 用のロガーメッセージ: `vars.myVar` アプリケーションをデプロイすると、ログにロガーメッセージが出力されます。 ## [](#出力変換を削除する)出力変換を削除する 1. \[Output (出力)\] 列のタイトルをクリックします。 2. 削除したい変換のゴミ箱アイコンをクリックします。 ## [](#関連情報)関連情報 [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.6/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) # 属性または変数への変換出力 (Design Center) デフォルトでは、Transform コンポーネントは Mule イベントのメッセージペイロードに出力します。データは、作成する変数や属性に出力することもできます。 まず、Transform コンポーネントに入力データを送信する基本フローをセットアップする必要があります。 1. Transform コンポーネントの \[Mapping (マッピング)\] タブで、\[Output (出力)\] 列のタイトル (デフォルトは「Output Payload (出力ペイロード)」) をクリックします。 2. \[Add Transformation (変換の追加)\] を選択します。 3. 次のいずれかを選択します。 - 属性 - 変数 4. 変数の場合は名前を入力します。 5. 属性または変数のデータ型を作成または選択します。 6. 属性または変数に出力したいトランスフォーマー入力部分をマップします。 次のようにトランスフォーマーの後にロガーを追加することで、マッピングをチェックできます。 - 属性用のロガーメッセージ: `message.attributes` - 変数 ​`myVar`​ 用のロガーメッセージ: `vars.myVar` アプリケーションをデプロイすると、ログにロガーメッセージが出力されます。 ## [](#出力変換を削除する)出力変換を削除する 1. \[Output (出力)\] 列のタイトルをクリックします。 2. 削除したい変換のゴミ箱アイコンをクリックします。 ## [](#関連情報)関連情報 [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.7/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) # 属性または変数への変換出力 (Design Center) デフォルトでは、Transform コンポーネントは Mule イベントのメッセージペイロードに出力します。データは、作成する変数や属性に出力することもできます。 まず、Transform コンポーネントに入力データを送信する基本フローをセットアップする必要があります。 1. Transform コンポーネントの \[Mapping (マッピング)\] タブで、\[Output (出力)\] 列のタイトル (デフォルトは「Output Payload (出力ペイロード)」) をクリックします。 2. \[Add Transformation (変換の追加)\] を選択します。 3. 次のいずれかを選択します。 - 属性 - 変数 4. 変数の場合は名前を入力します。 5. 属性または変数のデータ型を作成または選択します。 6. 属性または変数に出力したいトランスフォーマー入力部分をマップします。 次のようにトランスフォーマーの後にロガーを追加することで、マッピングをチェックできます。 - 属性用のロガーメッセージ: `message.attributes` - 変数 ​`myVar`​ 用のロガーメッセージ: `vars.myVar` アプリケーションをデプロイすると、ログにロガーメッセージが出力されます。 ## [](#出力変換を削除する)出力変換を削除する 1. \[Output (出力)\] 列のタイトルをクリックします。 2. 削除したい変換のゴミ箱アイコンをクリックします。 ## [](#関連情報)関連情報 [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.8/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) # 属性または変数への変換出力 (Design Center) デフォルトでは、Transform コンポーネントは Mule イベントのメッセージペイロードに出力します。データは、作成する変数や属性に出力することもできます。 まず、Transform コンポーネントに入力データを送信する基本フローをセットアップする必要があります。 1. Transform コンポーネントの \[Mapping (マッピング)\] タブで、\[Output (出力)\] 列のタイトル (デフォルトは「Output Payload (出力ペイロード)」) をクリックします。 2. \[Add Transformation (変換の追加)\] を選択します。 3. 次のいずれかを選択します。 - 属性 - 変数 4. 変数の場合は名前を入力します。 5. 属性または変数のデータ型を作成または選択します。 6. 属性または変数に出力したいトランスフォーマー入力部分をマップします。 次のようにトランスフォーマーの後にロガーを追加することで、マッピングをチェックできます。 - 属性用のロガーメッセージ: `message.attributes` - 変数 ​`myVar`​ 用のロガーメッセージ: `vars.myVar` アプリケーションをデプロイすると、ログにロガーメッセージが出力されます。 ## [](#出力変換を削除する)出力変換を削除する 1. \[Output (出力)\] 列のタイトルをクリックします。 2. 削除したい変換のゴミ箱アイコンをクリックします。 ## [](#関連情報)関連情報 [Mule メッセージ構造](https://docs.mulesoft.com/jp/mule-runtime/4.9/about-mule-message) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) # 手動によるクラスターの作成および管理 クラスターを作成および管理する方法は 2 つあります。 - Runtime Manager を使用する 設定手順は、​[「クラスター」](https://docs.mulesoft.com/jp/runtime-manager/cluster-about)​を参照してください。 - 手動で設定ファイルを使用する ## [](#クラスターの要件と制限事項)クラスターの要件と制限事項 - クラスター管理ツールを混在させないでください。 手動で行ったクラスター設定は Anypoint Runtime Manager とは同期されないため、プラットフォームで変更を行うと、クラスター設定ファイルが上書きされます。この状況を回避するには、手動での設定または Anypoint Runtime Manager を使用した設定のどちらかの方法のみでクラスターの作成と管理を行ってください。 - クラスター内のすべてのノードは、次の同じバージョンを使用する必要があります。 - Mule Runtime Engine 4.3.0-20210322 などの累積パッチリリースを使用している場合は、すべての Mule インスタンスの累積パッチバージョンが同じである必要があります。 - Runtime Manager エージェントのバージョン - Java ## [](#手動でクラスターを作成する)手動でクラスターを作成する 設定ファイルを使用して手動でクラスターを作成する手順は、次のとおりです。 1. ノードが実行されていないことと、Mule Runtime サーバーが停止していることを確認します。 2. ノードの ​`$MULE_HOME/.mule`​ ディレクトリ内に ​`mule-cluster.properties`​ という名前のファイルを作成します。 3. パラメーター = 値のペア (1 行に 1 つ) を使用してファイルを編集します。以下の例を参照してください。 **注意**​: `mule.clusterId`​ と ​`mule.clusterNodeId`​ は、プロパティファイルに存在している必要があります。 ```text ... mule.cluster.nodes=192.168.10.21,192.168.10.22,192.168.10.23 mule.cluster.multicastenabled=false mule.clusterId= mule.clusterNodeId= ... ``` 4. クラスターに含めるすべての Mule サーバーでこの手順を繰り返します。 5. ノードの Mule サーバーを開始します。 使用可能なパラメーターの完全なリストについては、​[\[Cluster Configuration Parameters\]](<#Cluster Configuration Parameters>)​を参照してください。 ## [](#手動でクラスターを管理する)手動でクラスターを管理する クラスターの手動管理は、手動で作成されたクラスターでのみ可能です。 クラスターノードの設定を手動で変更する手順は、次のとおりです。 1. ノードの Mule サーバーを停止します。 2. 必要に応じてノードの ​`mule-cluster.properties`​ を編集し、ファイルを保存します。 3. ノードの Mule サーバーを再起動します。

設定ファイルで適用するオプションがすべてのクラスターノードで有効であることを確認しておかないと、クラスター設定が壊れてクラスターが無効化される場合があります。
### [](#クォーラム管理)クォーラム管理 _手動で設定したクラスター_​を管理する場合、クラスターが稼働するのに必要なマシンの最小クォーラムを設定できるようになりました。 ネットワークをパーティション分割する場合、デフォルトでクラスターを使用できます。ただし、最小クォーラムサイズを設定すると、最小しきい値を満たしていない更新を拒否するようにクラスターを設定できます。 これにより、一貫性が向上し、予期せずにノード (クラスター内の Mule Runtime) が失われた場合にクラスターを保護できます。 通常の状況では、クラスター内のノードが停止しても、データを保存するのに十分なメモリがありますが、使用可能なノードが少なくなるため要求の処理に使用できるスレッド数が減少し、クラスター内のパーティションスレッドがすぐに不足する可能性があります。そのため、次のことが発生する場合があります。 - クライアントの要求を処理するスレッドがなくなり、クライアントが置き去りになる。 - 応答できない要求が多すぎて残りのクラスターメンバーで処理しきれなくなり、停止していると想定されてクラスターから除外されます。 メンバーが失われた場合にクラスターの残りのメンバーを保護するには、ノードの同時更新を停止する最小クォーラムサイズを設定します。これにより、クラスター内のアクティブなノードの数が設定値を下回ったとき、QuorumException がスローされます。

クラスターのクォーラムサイズを設定する場合には QuorumExceptions をキャッチして、メールの送信、プロセスの停止、ログの実行、再試行戦略の実行などを実行するようにしてください。
クォーラムを有効にするには、​`mule.cluster.quorumsize`​ プロパティをクラスター設定ファイル ​`{MULE_HOME}/.mule/mule-cluster.properties`​ に配置して、稼働状態を維持するためのクラスターの最小ノード数を定義します。

クォーラム機能は、オブジェクトストアを使用するコンポーネントでのみ有効です。
### [](#オブジェクトストアの永続性)オブジェクトストアの永続性 Mule Runtime Engine をオンプレミスで使用する場合は、すべてのクラスターノードからアクセスできる中央システムに JDBC データを永続的に保存できます。 以下のリレーショナルデータベースシステムがサポートされています。 - MySQL 5.5+ - PostgreSQL 9 - Microsoft SQL Server 2014 オブジェクトストアの永続性を有効にするには、データベースを作成し、​`{MULE_HOME}/.mule/mule-cluster.properties`​ ファイルでその設定値を定義します。 1. `mule.cluster.jdbcstoreurl`​: データベースに接続するための JDBC URL 2. `mule.cluster.jdbcstoreusername`​: データベースのユーザー名 3. `mule.cluster.jdbcstorepassword`​: データベースのユーザーパスワード 4. `mule.cluster.jdbcstoredriver`​: JDBC ドライバーのクラス名 5. `mule.cluster.jdbcstorequerystrategy`​: SQL 言語 このパラメーターで有効な設定値については、​[クラスター設定パラメーター](#cluster-config-params)​を参照してください。 この機能により、保持するオブジェクトストアごとにテーブルが作成されるため、データベースのテーブルは自動的に作成されます。 オブジェクトストアごとに 2 つのテーブルが作成されます。 - データを保存するテーブル - パーティションを保存するテーブル。 #### [](#オブジェクトストアデータベースの推奨事項)オブジェクトストアデータベースの推奨事項 - JDBC ストアでのみ使用される専用データベース/スキーマを作成することをお勧めします。 - データベースのユーザー名は、次の権限が必要です。 - データベース (​`DDL`​) でのテーブル用のオブジェクト ​`CREATE`​ および ​`DROP`​ の作成。 - 作成するオブジェクト (​`DML`​)、​`INSERT`​、​`UPDATE`​、​`DELETE`​、および ​`SELECT`​ のアクセスと管理。 - データストレージは、すべてのノードからアクセスできる中央 DB でホストする必要があることを常に念頭に置いてください。クラスターごとに複数のデータベースを使用しないでください。 これらの値の設定方法についての詳細は、​[永続性のクラスター設定リファレンス](#persistency-config)​を参照してください。 - 永続的なオブジェクトストアは、​`ComboPooledDataSource`​ Java クラスに基づいたデータベース接続プールを使用します。Mule Runtime Engine は、接続プールの動作の明示的な値を設定しません。標準設定では、各プロパティのデフォルト値を使用します。 たとえば、​`maxIdleTime`​ のデフォルト値は 0 です。これは、アイドル接続の期限が切れず、プールから削除されないことを意味します。アイドル接続は、アイドル状態でデータベースに接続されたままになります。 接続プールの動作を設定するには、次のいずれかのオプションを使用して目的のパラメーター値をランタイムに渡します。 - Mule の起動時にコマンドラインで複数のパラメーターを渡す。 ```console $ $MULE_HOME/bin/mule start \ -M-Dc3p0.maxIdleTime= \ -M-Dc3p0.maxIdleTimeExcessConnections= ``` ``​ を目的の値 (ミリ秒) に置き換えます。 - `$MULE_HOME/conf/wrapper.conf`​ ファイルに複数行を追加する。 wrapper.java.additional.=-Dc3p0.maxIdleTime= wrapper.java.additional.=-Dc3p0.maxIdleTimeExcessConnections= ``​ を ​`wrapper.conf`​ ファイルの次に大きい順次値に置き換えます。
ComboPooledDataSource​ Java クラスのプール設定についての詳細は、 この記事​を参照してください。
### [](#監視)監視 [JMX テクノロジー](http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html)​を使用して、クラスターメンバーでスローされるイベントを監視できます。 JMX 監視オプションは、デフォルトで無効になっています。有効にするには、​`mule.cluster.jmxenabled`​ プロパティを ​`{MULE_HOME}/.mule/mule-cluster.properties`​ 設定ファイルに追加します。 JMX を有効にすると、パフォーマンスのオーバーヘッドが発生する可能性があります (基盤となる構造で各ノードの統計を取得するためのリスナーが追加される場合)。 ### [](#メンバーシップリスナー)メンバーシップリスナー メンバーシップリスナーを使用すると、次のイベントが発生するたびに通知を取得できます。 1. 新しいメンバーがクラスターに追加される 2. 既存のメンバーがクラスターから離脱する これらのいずれかのイベントがトリガーされると、メンバーシップリスナーは、参加または離脱したメンバーのアドレスを出力します。 ## [](#cluster-config-params)クラスター設定パラメーター 次の表に、​`mule-cluster.properties`​ ファイルのパラメーターを示します。
プロパティ名 説明 必須

mule.clusterId

クラスターの一意の識別子。任意の英数字文字列になります。

はい

mule.clusterNodeId

クラスター内のノードの一意の ID。1 ～クラスター内のノード数の間の整数になります。

はい

mule.clusterSize

クラスターに属するノードの数。

はい

mule.cluster.networkinterfaces

Hazelcast で使用されるインターフェースのカンマ区切りリスト。以下のようにワイルドカードがサポートされています。

192.168.1.*,192.168.100.25

いいえ

mule.cluster.nodes

クラスターに属するノード。​<host:port>​ の形式になります (例: 172.16.9.24:9000​)。1 つの IP アドレスのみを指定すると、サーバーがクラスターに参加できるようになります。

ポート番号は省略可能です。設定しない場合は、デフォルトは 5701 になります。複数のホストを含めるには、カンマ区切りリストを作成します。

このオプションでは、指定した固定 IP アドレスでクラスターを設定します。クラスターノードの検出にマルチキャストを使用しない場合、このオプションを使用します。このオプションを使用する場合、​mule.cluster.multicastenabled​ を ​false​ に設定します。そのように設定しないと、クラスターを開始するときに例外がスローされます。(この表の次の項目を参照)。

例:

ポート 9000 をリスンする 2 つのノード:

172.16.9.24:9000,172.16.9.51:9000

ポート 5701 をリスンする 2 つのノード:

192.168.1.19,192.168.1.20

いいえ

mule.cluster.quorumsize

稼働状態を維持するためにクラスター内に必要なマシンの最小数を定義できます。

いいえ

mule.cluster.multicastenabled

(Boolean (ブール))​ マルチキャストを有効/無効にします。クラスターノードの検出に固定 IP アドレスを使用する場合、​false​ に設定します (上記の ​mule.cluster.nodes​ オプションを参照)。
true​ に設定する場合、​mule.cluster.nodes​ で IP アドレスを設定しないでください。

いいえ

mule.cluster.multicastgroup

使用するマルチキャストグループ IP アドレス。

いいえ

mule.cluster.multicastport

使用するマルチキャストポート番号。

いいえ

​mule.cluster.jdbcstoreurl

データベースに接続するための JDBC URL

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoreusername

データベースのユーザー名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorepassword

データベースのユーザーパスワード

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoredriver

JDBC ドライバーのクラス名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorequerystrategy

保存されているオブジェクトデータにアクセスするための SQL 言語。 このプロパティは、3 つの異なる値 (​mssql​、​mysql​、​postgresql​) を取ります。

永続データを保存する場合のみ必須。

mule.cluster.jmxenabled

(Boolean (ブール))​ 監視を有効/無効にします。

いいえ

mule.cluster.listenersenabled

(Boolean (ブール))​ メンバーシップリスナーを有効/無効にします。クラスターメンバーが参加または離脱したときにノードに通知するには、​true​ に設定します。

いいえ
# 手動によるクラスターの作成および管理 オンプレミスデプロイメントのクラスターを作成および管理する方法は 2 つあります。 - Runtime Manager を使用する 設定手順は、​[「クラスター」](https://docs.mulesoft.com/jp/runtime-manager/cluster-about)​を参照してください。 - 手動で設定ファイルを使用する ## [](#クラスターの要件と制限事項)クラスターの要件と制限事項 - クラスター管理ツールを混在させないでください。 手動で行ったクラスター設定は Anypoint Runtime Manager とは同期されないため、プラットフォームで変更を行うと、クラスター設定ファイルが上書きされます。この状況を回避するには、手動での設定または Anypoint Runtime Manager を使用した設定のどちらかの方法のみでクラスターの作成と管理を行ってください。 - クラスター内のすべてのノードは、次の同じバージョンを使用する必要があります。 - Mule Runtime Engine 4.3.0-20210322 などの累積パッチリリースを使用している場合は、すべての Mule インスタンスの累積パッチバージョンが同じである必要があります。 - Runtime Manager エージェントのバージョン - Java ## [](#手動でクラスターを作成する)手動でクラスターを作成する 設定ファイルを使用して手動でクラスターを作成する手順は、次のとおりです。 1. ノードが実行されていないことと、Mule Runtime サーバーが停止していることを確認します。 2. ノードの ​`$MULE_HOME/.mule`​ ディレクトリ内に ​`mule-cluster.properties`​ という名前のファイルを作成します。 3. パラメーター = 値のペア (1 行に 1 つ) を使用してファイルを編集します。以下の例を参照してください。 **注意**​: `mule.clusterId`​ と ​`mule.clusterNodeId`​ は、プロパティファイルに存在している必要があります。 ```text ... mule.cluster.nodes=192.168.10.21,192.168.10.22,192.168.10.23 mule.cluster.multicastenabled=false mule.clusterId= mule.clusterNodeId= ... ``` 4. クラスターに含めるすべての Mule サーバーでこの手順を繰り返します。 5. ノードの Mule サーバーを開始します。 使用可能なパラメーターの完全なリストについては、​[\[Cluster Configuration Parameters\]](<#Cluster Configuration Parameters>)​を参照してください。 ## [](#手動でクラスターを管理する)手動でクラスターを管理する クラスターの手動管理は、手動で作成されたクラスターでのみ可能です。 クラスターノードの設定を手動で変更する手順は、次のとおりです。 1. ノードの Mule サーバーを停止します。 2. 必要に応じてノードの ​`mule-cluster.properties`​ を編集し、ファイルを保存します。 3. ノードの Mule サーバーを再起動します。

設定ファイルで適用するオプションがすべてのクラスターノードで有効であることを確認しておかないと、クラスター設定が壊れてクラスターが無効化される場合があります。
### [](#クォーラム管理)クォーラム管理 _手動で設定したクラスター_​を管理する場合、クラスターが稼働するのに必要なマシンの最小クォーラムを設定できるようになりました。 ネットワークをパーティション分割する場合、デフォルトでクラスターを使用できます。ただし、最小クォーラムサイズを設定すると、最小しきい値を満たしていない更新を拒否するようにクラスターを設定できます。 これにより、一貫性が向上し、予期せずにノード (クラスター内の Mule Runtime) が失われた場合にクラスターを保護できます。 通常の状況では、クラスター内のノードが停止しても、データを保存するのに十分なメモリがありますが、使用可能なノードが少なくなるため要求の処理に使用できるスレッド数が減少し、クラスター内のパーティションスレッドがすぐに不足する可能性があります。そのため、次のことが発生する場合があります。 - クライアントの要求を処理するスレッドがなくなり、クライアントが置き去りになる。 - 応答できない要求が多すぎて残りのクラスターメンバーで処理しきれなくなり、停止していると想定されてクラスターから除外されます。 メンバーが失われた場合にクラスターの残りのメンバーを保護するには、ノードの同時更新を停止する最小クォーラムサイズを設定します。これにより、クラスター内のアクティブなノードの数が設定値を下回ったとき、QuorumException がスローされます。

クラスターのクォーラムサイズを設定する場合には QuorumExceptions をキャッチして、メールの送信、プロセスの停止、ログの実行、再試行戦略の実行などを実行するようにしてください。
クォーラムを有効にするには、​`mule.cluster.quorumsize`​ プロパティをクラスター設定ファイル ​`{MULE_HOME}/.mule/mule-cluster.properties`​ に配置して、稼働状態を維持するためのクラスターの最小ノード数を定義します。

クォーラム機能は、オブジェクトストアを使用するコンポーネントでのみ有効です。
### [](#オブジェクトストアの永続性)オブジェクトストアの永続性

クラスターオブジェクトストアの永続性を維持するには、中央 JDBC ストアをセットアップしてください。そうしないと、オブジェクトストア設定で永続性設定が有効になっていても、すべてのクラスターノードをシャットダウンした場合にオブジェクトストアのコンテンツが失われます。
Mule Runtime Engine をオンプレミスで使用する場合は、すべてのクラスターノードからアクセスできる中央システムに JDBC データを永続的に保存できます。 以下のリレーショナルデータベースシステムがサポートされています。 - MySQL 5.5+ - PostgreSQL 9 - Microsoft SQL Server 2014 オブジェクトストアの永続性を有効にするには、データベースを作成し、​`{MULE_HOME}/.mule/mule-cluster.properties`​ ファイルでその設定値を定義します。 1. `mule.cluster.jdbcstoreurl`​: データベースに接続するための JDBC URL 2. `mule.cluster.jdbcstoreusername`​: データベースのユーザー名 3. `mule.cluster.jdbcstorepassword`​: データベースのユーザーパスワード 4. `mule.cluster.jdbcstoredriver`​: JDBC ドライバーのクラス名 5. `mule.cluster.jdbcstorequerystrategy`​: SQL 言語 このパラメーターで有効な設定値については、​[クラスター設定パラメーター](#cluster-config-params)​を参照してください。 この機能により、保持するオブジェクトストアごとにテーブルが作成されるため、データベースのテーブルは自動的に作成されます。 オブジェクトストアごとに 2 つのテーブルが作成されます。 - データを保存するテーブル - パーティションを保存するテーブル。 #### [](#オブジェクトストアデータベースの推奨事項)オブジェクトストアデータベースの推奨事項 - JDBC ストアでのみ使用される専用データベース/スキーマを作成することをお勧めします。 - データベースのユーザー名は、次の権限が必要です。 - データベース (​`DDL`​) でのテーブル用のオブジェクト ​`CREATE`​ および ​`DROP`​ の作成。 - 作成するオブジェクト (​`DML`​)、​`INSERT`​、​`UPDATE`​、​`DELETE`​、および ​`SELECT`​ のアクセスと管理。 - データストレージは、すべてのノードからアクセスできる中央 DB でホストする必要があることを常に念頭に置いてください。クラスターごとに複数のデータベースを使用しないでください。 これらの値の設定方法についての詳細は、​[永続性のクラスター設定リファレンス](#persistency-config)​を参照してください。 - 一部のリレーショナルデータベースにはテーブル名の長さに関する特定の制約があります。​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して長いテーブル名を短い値に変換します。 このプロパティの設定方法についての詳細は、​[テーブル名トランスフォーマー](#table-name-transformers)​セクションを参照してください。 - 永続的なオブジェクトストアは、​`ComboPooledDataSource`​ Java クラスに基づいたデータベース接続プールを使用します。Mule Runtime Engine は、接続プールの動作の明示的な値を設定しません。標準設定では、各プロパティのデフォルト値を使用します。 たとえば、​`maxIdleTime`​ のデフォルト値は 0 です。これは、アイドル接続の期限が切れず、プールから削除されないことを意味します。アイドル接続は、アイドル状態でデータベースに接続されたままになります。 接続プールの動作を設定するには、次のいずれかのオプションを使用して目的のパラメーター値をランタイムに渡します。 - Mule の起動時にコマンドラインで複数のパラメーターを渡す。 ```console $ $MULE_HOME/bin/mule start \ -M-Dc3p0.maxIdleTime= \ -M-Dc3p0.maxIdleTimeExcessConnections= ``` ``​ を目的の値 (ミリ秒) に置き換えます。 - `$MULE_HOME/conf/wrapper.conf`​ ファイルに複数行を追加する。 wrapper.java.additional.=-Dc3p0.maxIdleTime= wrapper.java.additional.=-Dc3p0.maxIdleTimeExcessConnections= ``​ を ​`wrapper.conf`​ ファイルの次に大きい順次値に置き換えます。
ComboPooledDataSource​ Java クラスのプール設定についての詳細は、 この記事​を参照してください。
### [](#監視)監視 [JMX テクノロジー](http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html)​を使用して、クラスターメンバーでスローされるイベントを監視できます。 JMX 監視オプションは、デフォルトで無効になっています。有効にするには、​`mule.cluster.jmxenabled`​ プロパティを ​`{MULE_HOME}/.mule/mule-cluster.properties`​ 設定ファイルに追加します。 JMX を有効にすると、パフォーマンスのオーバーヘッドが発生する可能性があります (基盤となる構造で各ノードの統計を取得するためのリスナーが追加される場合)。 #### [](#table-name-transformers)テーブル名トランスフォーマー `mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して、テーブル名を変更するためのカスタムトランスフォーマーを定義できます。 たとえば、​`mule-cluster.properties`​ ファイルに次のプロパティを設定すると、Mule は MD5 とプレフィックスを使用してテーブル名をハッシュし、テーブルを Mule テーブルとして識別します。 ```none mule.cluster.jdbcstoretableNametransformerstrategy=com.mulesoft.mule.runtime.module.cluster.api.persistence.query.MD5TableNameTransformerStrategy ``` テーブル名をハッシュすることで確実に長さの制約が守られます。 `com.mulesoft.mule.runtime.module.cluster.api.persistence.query.TableNameTransformerStrategy`​ インターフェースを実装してカスタムトランスフォーマー戦略を作成してから、​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティにカスタムトランスフォーマー戦略を設定することもできます。 ### [](#メンバーシップリスナー)メンバーシップリスナー メンバーシップリスナーを使用すると、次のイベントが発生するたびに通知を取得できます。 1. 新しいメンバーがクラスターに追加される 2. 既存のメンバーがクラスターから離脱する これらのいずれかのイベントがトリガーされると、メンバーシップリスナーは、参加または離脱したメンバーのアドレスを出力します。 ## [](#cluster-config-params)クラスター設定パラメーター 次の表に、​`mule-cluster.properties`​ ファイルのパラメーターを示します。
プロパティ名 説明 必須

mule.clusterId

クラスターの一意の識別子。任意の英数字文字列になります。

はい

mule.clusterNodeId

クラスター内のノードの一意の ID。1 ～クラスター内のノード数の間の整数になります。

はい

mule.clusterSize

クラスターに属するノードの数。

はい

mule.cluster.networkinterfaces

Hazelcast で使用されるインターフェースのカンマ区切りリスト。以下のようにワイルドカードがサポートされています。

192.168.1.*,192.168.100.25

いいえ

mule.cluster.nodes

クラスターに属するノード。​<host:port>​ の形式になります (例: 172.16.9.24:9000​)。1 つの IP アドレスのみを指定すると、サーバーがクラスターに参加できるようになります。

ポート番号は省略可能です。設定しない場合は、デフォルトは 5701 になります。複数のホストを含めるには、カンマ区切りリストを作成します。

このオプションでは、指定した固定 IP アドレスでクラスターを設定します。クラスターノードの検出にマルチキャストを使用しない場合、このオプションを使用します。このオプションを使用する場合、​mule.cluster.multicastenabled​ を ​false​ に設定します。そのように設定しないと、クラスターを開始するときに例外がスローされます。(この表の次の項目を参照)。

例:

ポート 9000 をリスンする 2 つのノード:

172.16.9.24:9000,172.16.9.51:9000

ポート 5701 をリスンする 2 つのノード:

192.168.1.19,192.168.1.20

いいえ

mule.cluster.quorumsize

稼働状態を維持するためにクラスター内に必要なマシンの最小数を定義できます。

いいえ

mule.cluster.multicastenabled

(Boolean (ブール))​ マルチキャストを有効/無効にします。クラスターノードの検出に固定 IP アドレスを使用する場合、​false​ に設定します (上記の ​mule.cluster.nodes​ オプションを参照)。
true​ に設定する場合、​mule.cluster.nodes​ で IP アドレスを設定しないでください。

いいえ

mule.cluster.multicastgroup

使用するマルチキャストグループ IP アドレス。

いいえ

mule.cluster.multicastport

使用するマルチキャストポート番号。

いいえ

​mule.cluster.jdbcstoreurl

データベースに接続するための JDBC URL

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoreusername

データベースのユーザー名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorepassword

データベースのユーザーパスワード

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoredriver

JDBC ドライバーのクラス名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorequerystrategy

保存されているオブジェクトデータにアクセスするための SQL 言語。 このプロパティは、3 つの異なる値 (​mssql​、​mysql​、​postgresql​) を取ります。

永続データを保存する場合のみ必須。

mule.cluster.jmxenabled

(Boolean (ブール))​ 監視を有効/無効にします。

いいえ

mule.cluster.listenersenabled

(Boolean (ブール))​ メンバーシップリスナーを有効/無効にします。クラスターメンバーが参加または離脱したときにノードに通知するには、​true​ に設定します。

いいえ
# 手動によるクラスターの作成および管理 クラスターを作成および管理する方法は 2 つあります。 - Runtime Manager を使用する 設定手順は、​[「クラスター」](https://docs.mulesoft.com/jp/runtime-manager/cluster-about)​を参照してください。 - 手動で設定ファイルを使用する ## [](#クラスターの要件と制限事項)クラスターの要件と制限事項 - クラスター管理ツールを混在させないでください。 手動で行ったクラスター設定は Anypoint Runtime Manager とは同期されないため、プラットフォームで変更を行うと、クラスター設定ファイルが上書きされます。この状況を回避するには、手動での設定または Anypoint Runtime Manager を使用した設定のどちらかの方法のみでクラスターの作成と管理を行ってください。 - クラスター内のすべてのノードは、次の同じバージョンを使用する必要があります。 - Mule Runtime Engine 4.3.0-20210322 などの累積パッチリリースを使用している場合は、すべての Mule インスタンスの累積パッチバージョンが同じである必要があります。 - Runtime Manager エージェントのバージョン - Java ## [](#手動でクラスターを作成する)手動でクラスターを作成する 設定ファイルを使用して手動でクラスターを作成する手順は、次のとおりです。 1. ノードが実行されていないことと、Mule Runtime サーバーが停止していることを確認します。 2. ノードの ​`$MULE_HOME/.mule`​ ディレクトリ内に ​`mule-cluster.properties`​ という名前のファイルを作成します。 3. パラメーター = 値のペア (1 行に 1 つ) を使用してファイルを編集します。以下の例を参照してください。 **注意**​: `mule.clusterId`​ と ​`mule.clusterNodeId`​ は、プロパティファイルに存在している必要があります。 ```text ... mule.cluster.nodes=192.168.10.21,192.168.10.22,192.168.10.23 mule.cluster.multicastenabled=false mule.clusterId= mule.clusterNodeId= ... ``` 4. クラスターに含めるすべての Mule サーバーでこの手順を繰り返します。 5. ノードの Mule サーバーを開始します。 使用可能なパラメーターの完全なリストについては、​[\[Cluster Configuration Parameters\]](<#Cluster Configuration Parameters>)​を参照してください。 ## [](#手動でクラスターを管理する)手動でクラスターを管理する クラスターの手動管理は、手動で作成されたクラスターでのみ可能です。 クラスターノードの設定を手動で変更する手順は、次のとおりです。 1. ノードの Mule サーバーを停止します。 2. 必要に応じてノードの ​`mule-cluster.properties`​ を編集し、ファイルを保存します。 3. ノードの Mule サーバーを再起動します。

設定ファイルで適用するオプションがすべてのクラスターノードで有効であることを確認しておかないと、クラスター設定が壊れてクラスターが無効化される場合があります。
### [](#クォーラム管理)クォーラム管理 _手動で設定したクラスター_​を管理する場合、クラスターが稼働するのに必要なマシンの最小クォーラムを設定できるようになりました。 ネットワークをパーティション分割する場合、デフォルトでクラスターを使用できます。ただし、最小クォーラムサイズを設定すると、最小しきい値を満たしていない更新を拒否するようにクラスターを設定できます。 これにより、一貫性が向上し、予期せずにノード (クラスター内の Mule Runtime) が失われた場合にクラスターを保護できます。 通常の状況では、クラスター内のノードが停止しても、データを保存するのに十分なメモリがありますが、使用可能なノードが少なくなるため要求の処理に使用できるスレッド数が減少し、クラスター内のパーティションスレッドがすぐに不足する可能性があります。そのため、次のことが発生する場合があります。 - クライアントの要求を処理するスレッドがなくなり、クライアントが置き去りになる。 - 応答できない要求が多すぎて残りのクラスターメンバーで処理しきれなくなり、停止していると想定されてクラスターから除外されます。 メンバーが失われた場合にクラスターの残りのメンバーを保護するには、ノードの同時更新を停止する最小クォーラムサイズを設定します。これにより、クラスター内のアクティブなノードの数が設定値を下回ったとき、QuorumException がスローされます。

クラスターのクォーラムサイズを設定する場合には QuorumExceptions をキャッチして、メールの送信、プロセスの停止、ログの実行、再試行戦略の実行などを実行するようにしてください。
クォーラムを有効にするには、​`mule.cluster.quorumsize`​ プロパティをクラスター設定ファイル ​`{MULE_HOME}/.mule/mule-cluster.properties`​ に配置して、稼働状態を維持するためのクラスターの最小ノード数を定義します。

クォーラム機能は、オブジェクトストアを使用するコンポーネントでのみ有効です。
### [](#オブジェクトストアの永続性)オブジェクトストアの永続性

クラスターオブジェクトストアの永続性を維持するには、中央 JDBC ストアをセットアップしてください。そうしないと、オブジェクトストア設定で永続性設定が有効になっていても、すべてのクラスターノードをシャットダウンした場合にオブジェクトストアのコンテンツが失われます。
Mule Runtime Engine をオンプレミスで使用する場合は、すべてのクラスターノードからアクセスできる中央システムに JDBC データを永続的に保存できます。 以下のリレーショナルデータベースシステムがサポートされています。 - MySQL 5.5+ - PostgreSQL 9 - Microsoft SQL Server 2014 - Microsoft SQL Server 2019 - Microsoft SQL Server 2022 オブジェクトストアの永続性を有効にするには、データベースを作成し、​`{MULE_HOME}/.mule/mule-cluster.properties`​ ファイルでその設定値を定義します。 1. `mule.cluster.jdbcstoreurl`​: データベースに接続するための JDBC URL 2. `mule.cluster.jdbcstoreusername`​: データベースのユーザー名 3. `mule.cluster.jdbcstorepassword`​: データベースのユーザーパスワード 4. `mule.cluster.jdbcstoredriver`​: JDBC ドライバーのクラス名 5. `mule.cluster.jdbcstorequerystrategy`​: SQL 言語 このパラメーターで有効な設定値については、​[クラスター設定パラメーター](#cluster-config-params)​を参照してください。 この機能により、保持するオブジェクトストアごとにテーブルが作成されるため、データベースのテーブルは自動的に作成されます。 オブジェクトストアごとに 2 つのテーブルが作成されます。 - データを保存するテーブル - パーティションを保存するテーブル。 #### [](#オブジェクトストアデータベースの推奨事項)オブジェクトストアデータベースの推奨事項 - JDBC ストアでのみ使用される専用データベース/スキーマを作成することをお勧めします。 - データベースのユーザー名は、次の権限が必要です。 - データベース (​`DDL`​) でのテーブル用のオブジェクト ​`CREATE`​ および ​`DROP`​ の作成。 - 作成するオブジェクト (​`DML`​)、​`INSERT`​、​`UPDATE`​、​`DELETE`​、および ​`SELECT`​ のアクセスと管理。 - データストレージは、すべてのノードからアクセスできる中央 DB でホストする必要があることを常に念頭に置いてください。クラスターごとに複数のデータベースを使用しないでください。 これらの値の設定方法についての詳細は、​[永続性のクラスター設定リファレンス](#persistency-config)​を参照してください。 - 一部のリレーショナルデータベースにはテーブル名の長さに関する特定の制約があります。​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して長いテーブル名を短い値に変換します。 このプロパティの設定方法についての詳細は、​[テーブル名トランスフォーマー](#table-name-transformers)​セクションを参照してください。 - 永続的なオブジェクトストアは、​`ComboPooledDataSource`​ Java クラスに基づいたデータベース接続プールを使用します。Mule Runtime Engine は、接続プールの動作の明示的な値を設定しません。標準設定では、各プロパティのデフォルト値を使用します。 たとえば、​`maxIdleTime`​ のデフォルト値は 0 です。これは、アイドル接続の期限が切れず、プールから削除されないことを意味します。アイドル接続は、アイドル状態でデータベースに接続されたままになります。 接続プールの動作を設定するには、次のいずれかのオプションを使用して目的のパラメーター値をランタイムに渡します。 - Mule の起動時にコマンドラインで複数のパラメーターを渡す。 ```console $ $MULE_HOME/bin/mule start \ -M-Dc3p0.maxIdleTime= \ -M-Dc3p0.maxIdleTimeExcessConnections= ``` ``​ を目的の値 (ミリ秒) に置き換えます。 - `$MULE_HOME/conf/wrapper.conf`​ ファイルに複数行を追加する。 wrapper.java.additional.=-Dc3p0.maxIdleTime= wrapper.java.additional.=-Dc3p0.maxIdleTimeExcessConnections= ``​ を ​`wrapper.conf`​ ファイルの次に大きい順次値に置き換えます。
ComboPooledDataSource​ Java クラスのプール設定についての詳細は、 この記事​を参照してください。
### [](#監視)監視 [JMX テクノロジー](http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html)​を使用して、クラスターメンバーでスローされるイベントを監視できます。 JMX 監視オプションは、デフォルトで無効になっています。有効にするには、​`mule.cluster.jmxenabled`​ プロパティを ​`{MULE_HOME}/.mule/mule-cluster.properties`​ 設定ファイルに追加します。 JMX を有効にすると、パフォーマンスのオーバーヘッドが発生する可能性があります (基盤となる構造で各ノードの統計を取得するためのリスナーが追加される場合)。 #### [](#table-name-transformers)テーブル名トランスフォーマー `mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して、テーブル名を変更するためのカスタムトランスフォーマーを定義できます。 たとえば、​`mule-cluster.properties`​ ファイルに次のプロパティを設定すると、Mule は MD5 とプレフィックスを使用してテーブル名をハッシュし、テーブルを Mule テーブルとして識別します。 ```none mule.cluster.jdbcstoretableNametransformerstrategy=com.mulesoft.mule.runtime.module.cluster.api.persistence.query.MD5TableNameTransformerStrategy ``` テーブル名をハッシュすることで確実に長さの制約が守られます。 `com.mulesoft.mule.runtime.module.cluster.api.persistence.query.TableNameTransformerStrategy`​ インターフェースを実装してカスタムトランスフォーマー戦略を作成してから、​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティにカスタムトランスフォーマー戦略を設定することもできます。 ### [](#メンバーシップリスナー)メンバーシップリスナー メンバーシップリスナーを使用すると、次のイベントが発生するたびに通知を取得できます。 1. 新しいメンバーがクラスターに追加される 2. 既存のメンバーがクラスターから離脱する これらのいずれかのイベントがトリガーされると、メンバーシップリスナーは、参加または離脱したメンバーのアドレスを出力します。 ## [](#cluster-config-params)クラスター設定パラメーター 次の表に、​`mule-cluster.properties`​ ファイルのパラメーターを示します。
プロパティ名 説明 必須

mule.clusterId

クラスターの一意の識別子。任意の英数字文字列になります。

はい

mule.clusterNodeId

クラスター内のノードの一意の ID。1 ～クラスター内のノード数の間の整数になります。

はい

mule.clusterSize

クラスターに属するノードの数。

はい

mule.cluster.networkinterfaces

Hazelcast で使用されるインターフェースのカンマ区切りリスト。以下のようにワイルドカードがサポートされています。

192.168.1.*,192.168.100.25

いいえ

mule.cluster.nodes

クラスターに属するノード。​<host:port>​ の形式になります (例: 172.16.9.24:9000​)。1 つの IP アドレスのみを指定すると、サーバーがクラスターに参加できるようになります。

ポート番号は省略可能です。設定しない場合は、デフォルトは 5701 になります。複数のホストを含めるには、カンマ区切りリストを作成します。

このオプションでは、指定した固定 IP アドレスでクラスターを設定します。クラスターノードの検出にマルチキャストを使用しない場合、このオプションを使用します。このオプションを使用する場合、​mule.cluster.multicastenabled​ を ​false​ に設定します。そのように設定しないと、クラスターを開始するときに例外がスローされます。(この表の次の項目を参照)。

例:

ポート 9000 をリスンする 2 つのノード:

172.16.9.24:9000,172.16.9.51:9000

ポート 5701 をリスンする 2 つのノード:

192.168.1.19,192.168.1.20

いいえ

mule.cluster.quorumsize

稼働状態を維持するためにクラスター内に必要なマシンの最小数を定義できます。

いいえ

mule.cluster.multicastenabled

(Boolean (ブール))​ マルチキャストを有効/無効にします。クラスターノードの検出に固定 IP アドレスを使用する場合、​false​ に設定します (上記の ​mule.cluster.nodes​ オプションを参照)。
true​ に設定する場合、​mule.cluster.nodes​ で IP アドレスを設定しないでください。

いいえ

mule.cluster.multicastgroup

使用するマルチキャストグループ IP アドレス。

いいえ

mule.cluster.multicastport

使用するマルチキャストポート番号。

いいえ

​mule.cluster.jdbcstoreurl

データベースに接続するための JDBC URL

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoreusername

データベースのユーザー名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorepassword

データベースのユーザーパスワード

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoredriver

JDBC ドライバーのクラス名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorequerystrategy

保存されているオブジェクトデータにアクセスするための SQL 言語。 このプロパティは、3 つの異なる値 (​mssql​、​mysql​、​postgresql​) を取ります。

永続データを保存する場合のみ必須。

mule.cluster.jmxenabled

(Boolean (ブール))​ 監視を有効/無効にします。

いいえ

mule.cluster.listenersenabled

(Boolean (ブール))​ メンバーシップリスナーを有効/無効にします。クラスターメンバーが参加または離脱したときにノードに通知するには、​true​ に設定します。

いいえ
# 手動によるクラスターの作成および管理 オンプレミスデプロイメントのクラスターを作成および管理する方法は 2 つあります。 - Runtime Manager を使用する 設定手順は、​[「クラスター」](https://docs.mulesoft.com/jp/runtime-manager/cluster-about)​を参照してください。 - 手動で設定ファイルを使用する ## [](#クラスターの要件と制限事項)クラスターの要件と制限事項 - クラスター管理ツールを混在させないでください。 手動で行ったクラスター設定は Anypoint Runtime Manager とは同期されないため、プラットフォームで変更を行うと、クラスター設定ファイルが上書きされます。この状況を回避するには、手動での設定または Anypoint Runtime Manager を使用した設定のどちらかの方法のみでクラスターの作成と管理を行ってください。 - クラスター内のすべてのノードは、次の同じバージョンを使用する必要があります。 - Mule Runtime Engine 4.3.0-20210322 などの累積パッチリリースを使用している場合は、すべての Mule インスタンスの累積パッチバージョンが同じである必要があります。 - Runtime Manager エージェントのバージョン - Java ## [](#手動でクラスターを作成する)手動でクラスターを作成する 設定ファイルを使用して手動でクラスターを作成する手順は、次のとおりです。 1. ノードが実行されていないことと、Mule Runtime サーバーが停止していることを確認します。 2. ノードの ​`$MULE_HOME/.mule`​ ディレクトリ内に ​`mule-cluster.properties`​ という名前のファイルを作成します。 3. パラメーター = 値のペア (1 行に 1 つ) を使用してファイルを編集します。以下の例を参照してください。 **注意**​: `mule.clusterId`​ と ​`mule.clusterNodeId`​ は、プロパティファイルに存在している必要があります。 ```text ... mule.cluster.nodes=192.168.10.21,192.168.10.22,192.168.10.23 mule.cluster.multicastenabled=false mule.clusterId= mule.clusterNodeId= ... ``` 4. クラスターに含めるすべての Mule サーバーでこの手順を繰り返します。 5. ノードの Mule サーバーを開始します。 使用可能なパラメーターの完全なリストについては、​[\[Cluster Configuration Parameters\]](<#Cluster Configuration Parameters>)​を参照してください。 ## [](#手動でクラスターを管理する)手動でクラスターを管理する 手動で管理できるのは手動で作成されたクラスターのみです。 クラスターノードの設定を手動で変更する手順は、次のとおりです。 1. ノードの Mule サーバーを停止します。 2. 必要に応じてノードの ​`mule-cluster.properties`​ を編集し、ファイルを保存します。 3. ノードの Mule サーバーを再起動します。

設定ファイルで適用するオプションがすべてのクラスターノードで有効であることを確認しておかないと、クラスター設定が壊れてクラスターが無効化される場合があります。
### [](#クォーラム管理)クォーラム管理 _手動で設定したクラスター_​を管理する場合、クラスターが稼働するのに必要なマシンの最小クォーラムを設定できるようになりました。 ネットワークをパーティション分割する場合、デフォルトでクラスターを使用できます。ただし、最小クォーラムサイズを設定すると、最小しきい値を満たしていない更新を拒否するようにクラスターを設定できます。 これにより、一貫性が向上し、予期せずにノード (クラスター内の Mule Runtime) が失われた場合にクラスターを保護できます。 通常の状況では、クラスター内のノードが停止しても、データを保存するのに十分なメモリがありますが、使用可能なノードが少なくなるため要求の処理に使用できるスレッド数が減少し、クラスター内のパーティションスレッドがすぐに不足する可能性があります。そのため、次のことが発生する場合があります。 - クライアントの要求を処理するスレッドがなくなり、クライアントが置き去りになる。 - 応答できない要求が多すぎて残りのクラスターメンバーで処理しきれなくなり、停止していると想定されてクラスターから除外されます。 メンバーが失われた場合にクラスターの残りのメンバーを保護するには、ノードの同時更新を停止する最小クォーラムサイズを設定します。これにより、クラスター内のアクティブなノードの数が設定値を下回ったとき、QuorumException がスローされます。

クラスターのクォーラムサイズを設定する場合には QuorumExceptions をキャッチして、メールの送信、プロセスの停止、ログの実行、再試行戦略の実行などを実行するようにしてください。
クォーラムを有効にするには、​`mule.cluster.quorumsize`​ プロパティをクラスター設定ファイル ​`{MULE_HOME}/.mule/mule-cluster.properties`​ に配置して、稼働状態を維持するためのクラスターの最小ノード数を定義します。

クォーラム機能は、オブジェクトストアを使用するコンポーネントでのみ有効です。
### [](#オブジェクトストアの永続性)オブジェクトストアの永続性

クラスターオブジェクトストアの永続性を維持するには、中央 JDBC ストアをセットアップしてください。そうしないと、オブジェクトストア設定で永続性設定が有効になっていても、すべてのクラスターノードをシャットダウンした場合にオブジェクトストアのコンテンツが失われます。
Mule Runtime Engine をオンプレミスで使用する場合は、すべてのクラスターノードからアクセスできる中央システムに JDBC データを永続的に保存できます。 以下のリレーショナルデータベースシステムがサポートされています。 - MySQL 5.5+ - PostgreSQL 9 - Microsoft SQL Server 2014 - Microsoft SQL Server 2019 - Microsoft SQL Server 2022 オブジェクトストアの永続性を有効にするには、データベースを作成し、​`{MULE_HOME}/.mule/mule-cluster.properties`​ ファイルでその設定値を定義します。 1. `mule.cluster.jdbcstoreurl`​: データベースに接続するための JDBC URL 2. `mule.cluster.jdbcstoreusername`​: データベースのユーザー名 3. `mule.cluster.jdbcstorepassword`​: データベースのユーザーパスワード 4. `mule.cluster.jdbcstoredriver`​: JDBC ドライバーのクラス名 5. `mule.cluster.jdbcstorequerystrategy`​: SQL 言語 このパラメーターで有効な設定値については、​[クラスター設定パラメーター](#cluster-config-params)​を参照してください。 この機能により、保持するオブジェクトストアごとにテーブルが作成されるため、データベースのテーブルは自動的に作成されます。 オブジェクトストアごとに 2 つのテーブルが作成されます。 - データを保存するテーブル - パーティションを保存するテーブル。 #### [](#オブジェクトストアデータベースの推奨事項)オブジェクトストアデータベースの推奨事項 - JDBC ストアでのみ使用される専用データベース/スキーマを作成することをお勧めします。 - データベースのユーザー名は、次の権限が必要です。 - データベース (​`DDL`​) でのテーブル用のオブジェクト ​`CREATE`​ および ​`DROP`​ の作成。 - 作成するオブジェクト (​`DML`​)、​`INSERT`​、​`UPDATE`​、​`DELETE`​、および ​`SELECT`​ のアクセスと管理。 - データストレージは、すべてのノードからアクセスできる中央 DB でホストする必要があることを常に念頭に置いてください。クラスターごとに複数のデータベースを使用しないでください。 これらの値の設定方法についての詳細は、​[永続性のクラスター設定リファレンス](#persistency-config)​を参照してください。 - 一部のリレーショナルデータベースにはテーブル名の長さに関する特定の制約があります。​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して長いテーブル名を短い値に変換します。 このプロパティの設定方法についての詳細は、​[テーブル名トランスフォーマー](#table-name-transformers)​セクションを参照してください。 - 永続的なオブジェクトストアは、​`ComboPooledDataSource`​ Java クラスに基づいたデータベース接続プールを使用します。Mule Runtime Engine は、接続プールの動作の明示的な値を設定しません。標準設定では、各プロパティのデフォルト値を使用します。 たとえば、​`maxIdleTime`​ のデフォルトは 0 です。これは、アイドル接続の期限が切れず、プールから削除されないことを意味します。アイドル接続は、アイドル状態でデータベースに接続されたままになります。 接続プールの動作を設定するには、次のいずれかのオプションを使用して目的のパラメーター値をランタイムに渡します。 - Mule の起動時にコマンドラインで複数のパラメーターを渡す。 ```console $ $MULE_HOME/bin/mule start \ -M-Dc3p0.maxIdleTime= \ -M-Dc3p0.maxIdleTimeExcessConnections= ``` ``​ を目的の値 (ミリ秒) に置き換えます。 - `$MULE_HOME/conf/wrapper.conf`​ ファイルに複数行を追加する。 wrapper.java.additional.=-Dc3p0.maxIdleTime= wrapper.java.additional.=-Dc3p0.maxIdleTimeExcessConnections= ``​ を ​`wrapper.conf`​ ファイルの次に大きい順次値に置き換えます。
ComboPooledDataSource​ Java クラスのプール設定についての詳細は、 この記事​を参照してください。
### [](#監視)監視 [JMX テクノロジー](http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html)​を使用して、クラスターメンバーでスローされるイベントを監視できます。 JMX 監視オプションは、デフォルトで無効になっています。有効にするには、​`mule.cluster.jmxenabled`​ プロパティを ​`{MULE_HOME}/.mule/mule-cluster.properties`​ 設定ファイルに追加します。 JMX を有効にすると、パフォーマンスのオーバーヘッドが発生する可能性があります (基盤となる構造で各ノードの統計を取得するためのリスナーが追加される場合)。 #### [](#table-name-transformers)テーブル名トランスフォーマー `mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して、テーブル名を変更するためのカスタムトランスフォーマーを定義できます。 たとえば、​`mule-cluster.properties`​ ファイルに次のプロパティを設定すると、Mule は MD5 とプレフィックスを使用してテーブル名をハッシュし、テーブルを Mule テーブルとして識別します。 ```none mule.cluster.jdbcstoretableNametransformerstrategy=com.mulesoft.mule.runtime.module.cluster.api.persistence.query.MD5TableNameTransformerStrategy ``` テーブル名をハッシュすることで確実に長さの制約が守られます。 `com.mulesoft.mule.runtime.module.cluster.api.persistence.query.TableNameTransformerStrategy`​ インターフェースを実装してカスタムトランスフォーマー戦略を作成してから、​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティにカスタムトランスフォーマー戦略を設定することもできます。 ### [](#メンバーシップリスナー)メンバーシップリスナー メンバーシップリスナーを使用すると、次のイベントが発生するたびに通知を取得できます。 1. 新しいメンバーがクラスターに追加される 2. 既存のメンバーがクラスターから離脱する これらのいずれかのイベントがトリガーされると、メンバーシップリスナーは、参加または離脱したメンバーのアドレスを出力します。 ## [](#cluster-config-params)クラスター設定パラメーター 次の表に、​`mule-cluster.properties`​ ファイルのパラメーターを示します。
プロパティ名 説明 必須

mule.clusterId

クラスターの一意の識別子。任意の英数字文字列になります。

はい

mule.clusterNodeId

クラスター内のノードの一意の ID。1 ～クラスター内のノード数の間の整数になります。

はい

mule.clusterSize

クラスターに属するノードの数。

はい

mule.cluster.networkinterfaces

Hazelcast で使用されるインターフェースのカンマ区切りリスト。以下のようにワイルドカードがサポートされています。

192.168.1.*,192.168.100.25

いいえ

mule.cluster.nodes

クラスターに属するノード。​<host:port>​ の形式になります (例: 172.16.9.24:9000​)。1 つの IP アドレスのみを指定すると、サーバーがクラスターに参加できるようになります。

ポート番号は省略可能です。設定しない場合は、デフォルトは 5701 になります。複数のホストを含めるには、カンマ区切りリストを作成します。

このオプションでは、指定した固定 IP アドレスでクラスターを設定します。クラスターノードの検出にマルチキャストを使用しない場合、このオプションを使用します。このオプションを使用する場合、​mule.cluster.multicastenabled​ を ​false​ に設定します。そのように設定しないと、クラスターを開始するときに例外がスローされます。(この表の次の項目を参照)。

例:

ポート 9000 をリスンする 2 つのノード:

172.16.9.24:9000,172.16.9.51:9000

ポート 5701 をリスンする 2 つのノード:

192.168.1.19,192.168.1.20

いいえ

mule.cluster.quorumsize

稼働状態を維持するためにクラスター内に必要なマシンの最小数を定義できます。

いいえ

mule.cluster.multicastenabled

(Boolean (ブール))​ マルチキャストを有効/無効にします。クラスターノードの検出に固定 IP アドレスを使用する場合、​false​ に設定します (上記の ​mule.cluster.nodes​ オプションを参照)。
true​ に設定する場合、​mule.cluster.nodes​ で IP アドレスを設定しないでください。

いいえ

mule.cluster.multicastgroup

使用するマルチキャストグループ IP アドレス。

いいえ

mule.cluster.multicastport

使用するマルチキャストポート番号。

いいえ

​mule.cluster.jdbcstoreurl

データベースに接続するための JDBC URL

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoreusername

データベースのユーザー名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorepassword

データベースのユーザーパスワード

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoredriver

JDBC ドライバーのクラス名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorequerystrategy

保存されているオブジェクトデータにアクセスするための SQL 言語。 このプロパティは、3 つの異なる値 (​mssql​、​mysql​、​postgresql​) を取ります。

永続データを保存する場合のみ必須。

mule.cluster.jmxenabled

(Boolean (ブール))​ 監視を有効/無効にします。

いいえ

mule.cluster.listenersenabled

(Boolean (ブール))​ メンバーシップリスナーを有効/無効にします。クラスターメンバーが参加または離脱したときにノードに通知するには、​true​ に設定します。

いいえ
# 手動によるクラスターの作成および管理 オンプレミスデプロイメントのクラスターを作成および管理する方法は 2 つあります。 - Runtime Manager を使用する 設定手順は、​[「クラスター」](https://docs.mulesoft.com/jp/runtime-manager/cluster-about)​を参照してください。 - 手動で設定ファイルを使用する ## [](#クラスターの要件と制限事項)クラスターの要件と制限事項 - クラスター管理ツールを混在させないでください。 手動で行ったクラスター設定は Anypoint Runtime Manager とは同期されないため、プラットフォームで変更を行うと、クラスター設定ファイルが上書きされます。この状況を回避するには、手動での設定または Anypoint Runtime Manager を使用した設定のどちらかの方法のみでクラスターの作成と管理を行ってください。 - クラスター内のすべてのノードは、次の同じバージョンを使用する必要があります。 - Mule Runtime Engine 4.3.0-20210322 などの累積パッチリリースを使用している場合は、すべての Mule インスタンスの累積パッチバージョンが同じである必要があります。 - Runtime Manager エージェントのバージョン - Java ## [](#手動でクラスターを作成する)手動でクラスターを作成する 設定ファイルを使用して手動でクラスターを作成する手順は、次のとおりです。 1. ノードが実行されていないことと、Mule Runtime サーバーが停止していることを確認します。 2. ノードの ​`$MULE_HOME/.mule`​ ディレクトリ内に ​`mule-cluster.properties`​ という名前のファイルを作成します。 3. パラメーター = 値のペア (1 行に 1 つ) を使用してファイルを編集します。以下の例を参照してください。 **注意**​: `mule.clusterId`​ と ​`mule.clusterNodeId`​ は、プロパティファイルに存在している必要があります。 ```text ... mule.cluster.nodes=192.168.10.21,192.168.10.22,192.168.10.23 mule.cluster.multicastenabled=false mule.clusterId= mule.clusterNodeId= ... ``` 4. クラスターに含めるすべての Mule サーバーでこの手順を繰り返します。 5. ノードの Mule サーバーを開始します。 使用可能なパラメーターの完全なリストについては、​[\[Cluster Configuration Parameters\]](<#Cluster Configuration Parameters>)​を参照してください。 ## [](#手動でクラスターを管理する)手動でクラスターを管理する 手動で管理できるのは手動で作成されたクラスターのみです。 クラスターノードの設定を手動で変更する手順は、次のとおりです。 1. ノードの Mule サーバーを停止します。 2. 必要に応じてノードの ​`mule-cluster.properties`​ を編集し、ファイルを保存します。 3. ノードの Mule サーバーを再起動します。

設定ファイルで適用するオプションがすべてのクラスターノードで有効であることを確認しておかないと、クラスター設定が壊れてクラスターが無効化される場合があります。
### [](#クォーラム管理)クォーラム管理 _手動で設定したクラスター_​を管理する場合、クラスターが稼働するのに必要なマシンの最小クォーラムを設定できるようになりました。 ネットワークをパーティション分割する場合、デフォルトでクラスターを使用できます。ただし、最小クォーラムサイズを設定すると、最小しきい値を満たしていない更新を拒否するようにクラスターを設定できます。 これにより、一貫性が向上し、予期せずにノード (クラスター内の Mule Runtime) が失われた場合にクラスターを保護できます。 通常の状況では、クラスター内のノードが停止しても、データを保存するのに十分なメモリがありますが、使用可能なノードが少なくなるため要求の処理に使用できるスレッド数が減少し、クラスター内のパーティションスレッドがすぐに不足する可能性があります。そのため、次のことが発生する場合があります。 - クライアントの要求を処理するスレッドがなくなり、クライアントが置き去りになる。 - 応答できない要求が多すぎて残りのクラスターメンバーで処理しきれなくなり、停止していると想定されてクラスターから除外されます。 メンバーが失われた場合にクラスターの残りのメンバーを保護するには、ノードの同時更新を停止する最小クォーラムサイズを設定します。これにより、クラスター内のアクティブなノードの数が設定値を下回ったとき、QuorumException がスローされます。

クラスターのクォーラムサイズを設定する場合には QuorumExceptions をキャッチして、メールの送信、プロセスの停止、ログの実行、再試行戦略の実行などを実行するようにしてください。
クォーラムを有効にするには、​`mule.cluster.quorumsize`​ プロパティをクラスター設定ファイル ​`{MULE_HOME}/.mule/mule-cluster.properties`​ に配置して、稼働状態を維持するためのクラスターの最小ノード数を定義します。

クォーラム機能は、オブジェクトストアを使用するコンポーネントでのみ有効です。
### [](#オブジェクトストアの永続性)オブジェクトストアの永続性

クラスターオブジェクトストアの永続性を維持するには、中央 JDBC ストアをセットアップしてください。そうしないと、オブジェクトストア設定で永続性設定が有効になっていても、すべてのクラスターノードをシャットダウンした場合にオブジェクトストアのコンテンツが失われます。
Mule Runtime Engine をオンプレミスで使用する場合は、すべてのクラスターノードからアクセスできる中央システムに JDBC データを永続的に保存できます。 以下のリレーショナルデータベースシステムがサポートされています。 - MySQL 5.5+ - PostgreSQL 9 - Microsoft SQL Server 2014 - Microsoft SQL Server 2019 - Microsoft SQL Server 2022 オブジェクトストアの永続性を有効にするには、データベースを作成し、​`{MULE_HOME}/.mule/mule-cluster.properties`​ ファイルでその設定値を定義します。 1. `mule.cluster.jdbcstoreurl`​: データベースに接続するための JDBC URL 2. `mule.cluster.jdbcstoreusername`​: データベースのユーザー名 3. `mule.cluster.jdbcstorepassword`​: データベースのユーザーパスワード 4. `mule.cluster.jdbcstoredriver`​: JDBC ドライバーのクラス名 5. `mule.cluster.jdbcstorequerystrategy`​: SQL 言語 このパラメーターで有効な設定値については、​[クラスター設定パラメーター](#cluster-config-params)​を参照してください。 この機能により、保持するオブジェクトストアごとにテーブルが作成されるため、データベースのテーブルは自動的に作成されます。 オブジェクトストアごとに 2 つのテーブルが作成されます。 - データを保存するテーブル - パーティションを保存するテーブル。 #### [](#オブジェクトストアデータベースの推奨事項)オブジェクトストアデータベースの推奨事項 - JDBC ストアでのみ使用される専用データベース/スキーマを作成することをお勧めします。 - データベースのユーザー名は、次の権限が必要です。 - データベース (​`DDL`​) でのテーブル用のオブジェクト ​`CREATE`​ および ​`DROP`​ の作成。 - 作成するオブジェクト (​`DML`​)、​`INSERT`​、​`UPDATE`​、​`DELETE`​、および ​`SELECT`​ のアクセスと管理。 - データストレージは、すべてのノードからアクセスできる中央 DB でホストする必要があることを常に念頭に置いてください。クラスターごとに複数のデータベースを使用しないでください。 これらの値の設定方法についての詳細は、​[永続性のクラスター設定リファレンス](#persistency-config)​を参照してください。 - 一部のリレーショナルデータベースにはテーブル名の長さに関する特定の制約があります。​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して長いテーブル名を短い値に変換します。 このプロパティの設定方法についての詳細は、​[テーブル名トランスフォーマー](#table-name-transformers)​セクションを参照してください。 - 永続的なオブジェクトストアは、​`ComboPooledDataSource`​ Java クラスに基づいたデータベース接続プールを使用します。Mule Runtime Engine は、接続プールの動作の明示的な値を設定しません。標準設定では、各プロパティのデフォルト値を使用します。 たとえば、​`maxIdleTime`​ のデフォルト値は 0 です。これは、アイドル接続の期限が切れず、プールから削除されないことを意味します。アイドル接続は、アイドル状態でデータベースに接続されたままになります。 接続プールの動作を設定するには、次のいずれかのオプションを使用して目的のパラメーター値をランタイムに渡します。 - Mule の起動時にコマンドラインで複数のパラメーターを渡す。 ```console $ $MULE_HOME/bin/mule start \ -M-Dc3p0.maxIdleTime= \ -M-Dc3p0.maxIdleTimeExcessConnections= ``` ``​ を目的の値 (ミリ秒) に置き換えます。 - `$MULE_HOME/conf/wrapper.conf`​ ファイルに複数行を追加する。 wrapper.java.additional.=-Dc3p0.maxIdleTime= wrapper.java.additional.=-Dc3p0.maxIdleTimeExcessConnections= ``​ を ​`wrapper.conf`​ ファイルの次に大きい順次値に置き換えます。
ComboPooledDataSource​ Java クラスのプール設定についての詳細は、 この記事​を参照してください。
### [](#監視)監視 [JMX テクノロジー](http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html)​を使用して、クラスターメンバーでスローされるイベントを監視できます。 JMX 監視オプションは、デフォルトで無効になっています。有効にするには、​`mule.cluster.jmxenabled`​ プロパティを ​`{MULE_HOME}/.mule/mule-cluster.properties`​ 設定ファイルに追加します。 JMX を有効にすると、パフォーマンスのオーバーヘッドが発生する可能性があります (基盤となる構造で各ノードの統計を取得するためのリスナーが追加される場合)。 #### [](#table-name-transformers)テーブル名トランスフォーマー `mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して、テーブル名を変更するためのカスタムトランスフォーマーを定義できます。 たとえば、​`mule-cluster.properties`​ ファイルに次のプロパティを設定すると、Mule は MD5 とプレフィックスを使用してテーブル名をハッシュし、テーブルを Mule テーブルとして識別します。 ```none mule.cluster.jdbcstoretableNametransformerstrategy=com.mulesoft.mule.runtime.module.cluster.api.persistence.query.MD5TableNameTransformerStrategy ``` テーブル名をハッシュすることで確実に長さの制約が守られます。 `com.mulesoft.mule.runtime.module.cluster.api.persistence.query.TableNameTransformerStrategy`​ インターフェースを実装してカスタムトランスフォーマー戦略を作成してから、​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティにカスタムトランスフォーマー戦略を設定することもできます。 ### [](#メンバーシップリスナー)メンバーシップリスナー メンバーシップリスナーを使用すると、次のイベントが発生するたびに通知を取得できます。 1. 新しいメンバーがクラスターに追加される 2. 既存のメンバーがクラスターから離脱する これらのいずれかのイベントがトリガーされると、メンバーシップリスナーは、参加または離脱したメンバーのアドレスを出力します。 ## [](#cluster-config-params)クラスター設定パラメーター 次の表に、​`mule-cluster.properties`​ ファイルのパラメーターを示します。
プロパティ名 説明 必須

mule.clusterId

クラスターの一意の識別子。任意の英数字文字列になります。

はい

mule.clusterNodeId

クラスター内のノードの一意の ID。1 ～クラスター内のノード数の間の整数になります。

はい

mule.clusterSize

クラスターに属するノードの数。

はい

mule.cluster.networkinterfaces

Hazelcast で使用されるインターフェースのカンマ区切りリスト。以下のようにワイルドカードがサポートされています。

192.168.1.*,192.168.100.25

いいえ

mule.cluster.nodes

クラスターに属するノード。​<host:port>​ の形式になります (例: 172.16.9.24:9000​)。1 つの IP アドレスのみを指定すると、サーバーがクラスターに参加できるようになります。

ポート番号は省略可能です。設定しない場合は、デフォルトは 5701 になります。複数のホストを含めるには、カンマ区切りリストを作成します。

このオプションでは、指定した固定 IP アドレスでクラスターを設定します。クラスターノードの検出にマルチキャストを使用しない場合、このオプションを使用します。このオプションを使用する場合、​mule.cluster.multicastenabled​ を ​false​ に設定します。そのように設定しないと、クラスターを開始するときに例外がスローされます。(この表の次の項目を参照)。

例:

ポート 9000 をリスンする 2 つのノード:

172.16.9.24:9000,172.16.9.51:9000

ポート 5701 をリスンする 2 つのノード:

192.168.1.19,192.168.1.20

いいえ

mule.cluster.quorumsize

稼働状態を維持するためにクラスター内に必要なマシンの最小数を定義できます。

いいえ

mule.cluster.multicastenabled

(Boolean (ブール))​ マルチキャストを有効/無効にします。クラスターノードの検出に固定 IP アドレスを使用する場合、​false​ に設定します (上記の ​mule.cluster.nodes​ オプションを参照)。
true​ に設定する場合、​mule.cluster.nodes​ で IP アドレスを設定しないでください。

いいえ

mule.cluster.multicastgroup

使用するマルチキャストグループ IP アドレス。

いいえ

mule.cluster.multicastport

使用するマルチキャストポート番号。

いいえ

​mule.cluster.jdbcstoreurl

データベースに接続するための JDBC URL

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoreusername

データベースのユーザー名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorepassword

データベースのユーザーパスワード

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoredriver

JDBC ドライバーのクラス名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorequerystrategy

保存されているオブジェクトデータにアクセスするための SQL 言語。 このプロパティは、3 つの異なる値 (​mssql​、​mysql​、​postgresql​) を取ります。

永続データを保存する場合のみ必須。

mule.cluster.jmxenabled

(Boolean (ブール))​ 監視を有効/無効にします。

いいえ

mule.cluster.listenersenabled

(Boolean (ブール))​ メンバーシップリスナーを有効/無効にします。クラスターメンバーが参加または離脱したときにノードに通知するには、​true​ に設定します。

いいえ
# 手動によるクラスターの作成および管理 オンプレミスデプロイメントのクラスターを作成および管理する方法は 2 つあります。 - Runtime Manager を使用する 設定手順は、​[「クラスター」](https://docs.mulesoft.com/jp/runtime-manager/cluster-about)​を参照してください。 - 手動で設定ファイルを使用する ## [](#クラスターの要件と制限事項)クラスターの要件と制限事項 - クラスター管理ツールを混在させないでください。 手動で行ったクラスター設定は Anypoint Runtime Manager とは同期されないため、プラットフォームで変更を行うと、クラスター設定ファイルが上書きされます。この状況を回避するには、手動での設定または Anypoint Runtime Manager を使用した設定のどちらかの方法のみでクラスターの作成と管理を行ってください。 - クラスター内のすべてのノードは、次の同じバージョンを使用する必要があります。 - Mule Runtime Engine 4.3.0-20210322 などの累積パッチリリースを使用している場合は、すべての Mule インスタンスの累積パッチバージョンが同じである必要があります。 - Runtime Manager エージェントのバージョン - Java ## [](#手動でクラスターを作成する)手動でクラスターを作成する 設定ファイルを使用して手動でクラスターを作成する手順は、次のとおりです。 1. ノードが実行されていないことと、Mule Runtime サーバーが停止していることを確認します。 2. ノードの ​`$MULE_HOME/.mule`​ ディレクトリ内に ​`mule-cluster.properties`​ という名前のファイルを作成します。 3. パラメーター = 値のペア (1 行に 1 つ) を使用してファイルを編集します。以下の例を参照してください。 **注意**​: `mule.clusterId`​ と ​`mule.clusterNodeId`​ は、プロパティファイルに存在している必要があります。 ```text ... mule.cluster.nodes=192.168.10.21,192.168.10.22,192.168.10.23 mule.cluster.multicastenabled=false mule.clusterId= mule.clusterNodeId= ... ``` 4. クラスターに含めるすべての Mule サーバーでこの手順を繰り返します。 5. ノードの Mule サーバーを開始します。 使用可能なパラメーターの完全なリストについては、​[\[Cluster Configuration Parameters\]](<#Cluster Configuration Parameters>)​を参照してください。 ## [](#手動でクラスターを管理する)手動でクラスターを管理する 手動で管理できるのは手動で作成されたクラスターのみです。 クラスターノードの設定を手動で変更する手順は、次のとおりです。 1. ノードの Mule サーバーを停止します。 2. 必要に応じてノードの ​`mule-cluster.properties`​ を編集し、ファイルを保存します。 3. ノードの Mule サーバーを再起動します。

設定ファイルで適用するオプションがすべてのクラスターノードで有効であることを確認しておかないと、クラスター設定が壊れてクラスターが無効化される場合があります。
### [](#クォーラム管理)クォーラム管理 _手動で設定したクラスター_​を管理する場合、クラスターが稼働するのに必要なマシンの最小クォーラムを設定できるようになりました。 ネットワークをパーティション分割する場合、デフォルトでクラスターを使用できます。ただし、最小クォーラムサイズを設定すると、最小しきい値を満たしていない更新を拒否するようにクラスターを設定できます。 これにより、一貫性が向上し、予期せずにノード (クラスター内の Mule Runtime) が失われた場合にクラスターを保護できます。 通常の状況では、クラスター内のノードが停止しても、データを保存するのに十分なメモリがありますが、使用可能なノードが少なくなるため要求の処理に使用できるスレッド数が減少し、クラスター内のパーティションスレッドがすぐに不足する可能性があります。そのため、次のことが発生する場合があります。 - クライアントの要求を処理するスレッドがなくなり、クライアントが置き去りになる。 - 応答できない要求が多すぎて残りのクラスターメンバーで処理しきれなくなり、停止していると想定されてクラスターから除外されます。 メンバーが失われた場合にクラスターの残りのメンバーを保護するには、ノードの同時更新を停止する最小クォーラムサイズを設定します。これにより、クラスター内のアクティブなノードの数が設定値を下回ったとき、QuorumException がスローされます。

クラスターのクォーラムサイズを設定する場合には QuorumExceptions をキャッチして、メールの送信、プロセスの停止、ログの実行、再試行戦略の実行などを実行するようにしてください。
クォーラムを有効にするには、​`mule.cluster.quorumsize`​ プロパティをクラスター設定ファイル ​`{MULE_HOME}/.mule/mule-cluster.properties`​ に配置して、稼働状態を維持するためのクラスターの最小ノード数を定義します。

クォーラム機能は、オブジェクトストアを使用するコンポーネントでのみ有効です。
### [](#オブジェクトストアの永続性)オブジェクトストアの永続性

クラスターオブジェクトストアの永続性を維持するには、中央 JDBC ストアをセットアップしてください。そうしないと、オブジェクトストア設定で永続性設定が有効になっていても、すべてのクラスターノードをシャットダウンした場合にオブジェクトストアのコンテンツが失われます。
Mule Runtime Engine をオンプレミスで使用する場合は、すべてのクラスターノードからアクセスできる中央システムに JDBC データを永続的に保存できます。 以下のリレーショナルデータベースシステムがサポートされています。 - MySQL 5.5+ - PostgreSQL 9 - Microsoft SQL Server 2014 - Microsoft SQL Server 2019 - Microsoft SQL Server 2022 オブジェクトストアの永続性を有効にするには、データベースを作成し、​`{MULE_HOME}/.mule/mule-cluster.properties`​ ファイルでその設定値を定義します。 1. `mule.cluster.jdbcstoreurl`​: データベースに接続するための JDBC URL 2. `mule.cluster.jdbcstoreusername`​: データベースのユーザー名 3. `mule.cluster.jdbcstorepassword`​: データベースのユーザーパスワード 4. `mule.cluster.jdbcstoredriver`​: JDBC ドライバーのクラス名 5. `mule.cluster.jdbcstorequerystrategy`​: SQL 言語 このパラメーターで有効な設定値については、​[クラスター設定パラメーター](#cluster-config-params)​を参照してください。 この機能により、保持するオブジェクトストアごとにテーブルが作成されるため、データベースのテーブルは自動的に作成されます。 オブジェクトストアごとに 2 つのテーブルが作成されます。 - データを保存するテーブル - パーティションを保存するテーブル。 #### [](#オブジェクトストアデータベースの推奨事項)オブジェクトストアデータベースの推奨事項 - JDBC ストアでのみ使用される専用データベース/スキーマを作成することをお勧めします。 - データベースのユーザー名は、次の権限が必要です。 - データベース (​`DDL`​) でのテーブル用のオブジェクト ​`CREATE`​ および ​`DROP`​ の作成。 - 作成するオブジェクト (​`DML`​)、​`INSERT`​、​`UPDATE`​、​`DELETE`​、および ​`SELECT`​ のアクセスと管理。 - データストレージは、すべてのノードからアクセスできる中央 DB でホストする必要があることを常に念頭に置いてください。クラスターごとに複数のデータベースを使用しないでください。 これらの値の設定方法についての詳細は、​[永続性のクラスター設定リファレンス](#persistency-config)​を参照してください。 - 一部のリレーショナルデータベースにはテーブル名の長さに関する特定の制約があります。​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して長いテーブル名を短い値に変換します。 このプロパティの設定方法についての詳細は、​[テーブル名トランスフォーマー](#table-name-transformers)​セクションを参照してください。 - 永続的なオブジェクトストアは、​`ComboPooledDataSource`​ Java クラスに基づいたデータベース接続プールを使用します。Mule Runtime Engine は、接続プールの動作の明示的な値を設定しません。標準設定では、各プロパティのデフォルト値を使用します。 たとえば、​`maxIdleTime`​ のデフォルト値は 0 です。これは、アイドル接続の期限が切れず、プールから削除されないことを意味します。アイドル接続は、アイドル状態でデータベースに接続されたままになります。 接続プールの動作を設定するには、次のいずれかのオプションを使用して目的のパラメーター値をランタイムに渡します。 - Mule の起動時にコマンドラインで複数のパラメーターを渡す。 ```console $ $MULE_HOME/bin/mule start \ -M-Dc3p0.maxIdleTime= \ -M-Dc3p0.maxIdleTimeExcessConnections= ``` ``​ を目的の値 (ミリ秒) に置き換えます。 - `$MULE_HOME/conf/wrapper.conf`​ ファイルに複数行を追加する。 wrapper.java.additional.=-Dc3p0.maxIdleTime= wrapper.java.additional.=-Dc3p0.maxIdleTimeExcessConnections= ``​ を ​`wrapper.conf`​ ファイルの次に大きい順次値に置き換えます。
ComboPooledDataSource​ Java クラスのプール設定についての詳細は、 この記事​を参照してください。
### [](#監視)監視 [JMX テクノロジー](http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html)​を使用して、クラスターメンバーでスローされるイベントを監視できます。 JMX 監視オプションは、デフォルトで無効になっています。有効にするには、​`mule.cluster.jmxenabled`​ プロパティを ​`{MULE_HOME}/.mule/mule-cluster.properties`​ 設定ファイルに追加します。 JMX を有効にすると、パフォーマンスのオーバーヘッドが発生する可能性があります (基盤となる構造で各ノードの統計を取得するためのリスナーが追加される場合)。 #### [](#table-name-transformers)テーブル名トランスフォーマー `mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して、テーブル名を変更するためのカスタムトランスフォーマーを定義できます。 たとえば、​`mule-cluster.properties`​ ファイルに次のプロパティを設定すると、Mule は MD5 とプレフィックスを使用してテーブル名をハッシュし、テーブルを Mule テーブルとして識別します。 ```none mule.cluster.jdbcstoretableNametransformerstrategy=com.mulesoft.mule.runtime.module.cluster.api.persistence.query.MD5TableNameTransformerStrategy ``` テーブル名をハッシュすることで確実に長さの制約が守られます。 `com.mulesoft.mule.runtime.module.cluster.api.persistence.query.TableNameTransformerStrategy`​ インターフェースを実装してカスタムトランスフォーマー戦略を作成してから、​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティにカスタムトランスフォーマー戦略を設定することもできます。 ### [](#メンバーシップリスナー)メンバーシップリスナー メンバーシップリスナーを使用すると、次のイベントが発生するたびに通知を取得できます。 1. 新しいメンバーがクラスターに追加される 2. 既存のメンバーがクラスターから離脱する これらのいずれかのイベントがトリガーされると、メンバーシップリスナーは、参加または離脱したメンバーのアドレスを出力します。 ## [](#cluster-config-params)クラスター設定パラメーター 次の表に、​`mule-cluster.properties`​ ファイルのパラメーターを示します。
プロパティ名 説明 必須

mule.clusterId

クラスターの一意の識別子。任意の英数字文字列になります。

はい

mule.clusterNodeId

クラスター内のノードの一意の ID。1 ～クラスター内のノード数の間の整数になります。

はい

mule.clusterSize

クラスターに属するノードの数。

はい

mule.cluster.networkinterfaces

Hazelcast で使用されるインターフェースのカンマ区切りリスト。以下のようにワイルドカードがサポートされています。

192.168.1.*,192.168.100.25

いいえ

mule.cluster.nodes

クラスターに属するノード。​<host:port>​ の形式になります (例: 172.16.9.24:9000​)。1 つの IP アドレスのみを指定すると、サーバーがクラスターに参加できるようになります。

ポート番号は省略可能です。設定しない場合は、デフォルトは 5701 になります。複数のホストを含めるには、カンマ区切りリストを作成します。

このオプションでは、指定した固定 IP アドレスでクラスターを設定します。クラスターノードの検出にマルチキャストを使用しない場合、このオプションを使用します。このオプションを使用する場合、​mule.cluster.multicastenabled​ を ​false​ に設定します。そのように設定しないと、クラスターを開始するときに例外がスローされます。(この表の次の項目を参照)。

例:

ポート 9000 をリスンする 2 つのノード:

172.16.9.24:9000,172.16.9.51:9000

ポート 5701 をリスンする 2 つのノード:

192.168.1.19,192.168.1.20

いいえ

mule.cluster.quorumsize

稼働状態を維持するためにクラスター内に必要なマシンの最小数を定義できます。

いいえ

mule.cluster.multicastenabled

(Boolean (ブール))​ マルチキャストを有効/無効にします。クラスターノードの検出に固定 IP アドレスを使用する場合、​false​ に設定します (上記の ​mule.cluster.nodes​ オプションを参照)。
true​ に設定する場合、​mule.cluster.nodes​ で IP アドレスを設定しないでください。

いいえ

mule.cluster.multicastgroup

使用するマルチキャストグループ IP アドレス。

いいえ

mule.cluster.multicastport

使用するマルチキャストポート番号。

いいえ

​mule.cluster.jdbcstoreurl

データベースに接続するための JDBC URL

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoreusername

データベースのユーザー名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorepassword

データベースのユーザーパスワード

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoredriver

JDBC ドライバーのクラス名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorequerystrategy

保存されているオブジェクトデータにアクセスするための SQL 言語。 このプロパティは、3 つの異なる値 (​mssql​、​mysql​、​postgresql​) を取ります。

永続データを保存する場合のみ必須。

mule.cluster.jmxenabled

(Boolean (ブール))​ 監視を有効/無効にします。

いいえ

mule.cluster.listenersenabled

(Boolean (ブール))​ メンバーシップリスナーを有効/無効にします。クラスターメンバーが参加または離脱したときにノードに通知するには、​true​ に設定します。

いいえ
# 手動によるクラスターの作成および管理 オンプレミスデプロイメントのクラスターを作成および管理する方法は 2 つあります。 - Runtime Manager を使用する 設定手順は、​[「クラスター」](https://docs.mulesoft.com/jp/runtime-manager/cluster-about)​を参照してください。 - 手動で設定ファイルを使用する ## [](#クラスターの要件と制限事項)クラスターの要件と制限事項 - クラスター管理ツールを混在させないでください。 手動で行ったクラスター設定は Anypoint Runtime Manager とは同期されないため、プラットフォームで変更を行うと、クラスター設定ファイルが上書きされます。この状況を回避するには、手動での設定または Anypoint Runtime Manager を使用した設定のどちらかの方法のみでクラスターの作成と管理を行ってください。 - クラスター内のすべてのノードは、次の同じバージョンを使用する必要があります。 - Mule Runtime Engine 4.3.0-20210322 などの累積パッチリリースを使用している場合は、すべての Mule インスタンスの累積パッチバージョンが同じである必要があります。 - Runtime Manager エージェントのバージョン - Java ## [](#手動でクラスターを作成する)手動でクラスターを作成する 設定ファイルを使用して手動でクラスターを作成する手順は、次のとおりです。 1. ノードが実行されていないことと、Mule Runtime サーバーが停止していることを確認します。 2. ノードの ​`$MULE_HOME/.mule`​ ディレクトリ内に ​`mule-cluster.properties`​ という名前のファイルを作成します。 3. パラメーター = 値のペア (1 行に 1 つ) を使用してファイルを編集します。以下の例を参照してください。 **注意**​: `mule.clusterId`​ と ​`mule.clusterNodeId`​ は、プロパティファイルに存在している必要があります。 ```text ... mule.cluster.nodes=192.168.10.21,192.168.10.22,192.168.10.23 mule.cluster.multicastenabled=false mule.clusterId= mule.clusterNodeId= ... ``` 4. クラスターに含めるすべての Mule サーバーでこの手順を繰り返します。 5. ノードの Mule サーバーを開始します。 使用可能なパラメーターの完全なリストについては、​[\[Cluster Configuration Parameters\]](<#Cluster Configuration Parameters>)​を参照してください。 ## [](#手動でクラスターを管理する)手動でクラスターを管理する 手動で管理できるのは手動で作成されたクラスターのみです。 クラスターノードの設定を手動で変更する手順は、次のとおりです。 1. ノードの Mule サーバーを停止します。 2. 必要に応じてノードの ​`mule-cluster.properties`​ を編集し、ファイルを保存します。 3. ノードの Mule サーバーを再起動します。

設定ファイルで適用するオプションがすべてのクラスターノードで有効であることを確認しておかないと、クラスター設定が壊れてクラスターが無効化される場合があります。
### [](#クォーラム管理)クォーラム管理 _手動で設定したクラスター_​を管理する場合、クラスターが稼働するのに必要なマシンの最小クォーラムを設定できるようになりました。 ネットワークをパーティション分割する場合、デフォルトでクラスターを使用できます。ただし、最小クォーラムサイズを設定すると、最小しきい値を満たしていない更新を拒否するようにクラスターを設定できます。 これにより、一貫性が向上し、予期せずにノード (クラスター内の Mule Runtime) が失われた場合にクラスターを保護できます。 通常の状況では、クラスター内のノードが停止しても、データを保存するのに十分なメモリがありますが、使用可能なノードが少なくなるため要求の処理に使用できるスレッド数が減少し、クラスター内のパーティションスレッドがすぐに不足する可能性があります。そのため、次のことが発生する場合があります。 - クライアントの要求を処理するスレッドがなくなり、クライアントが置き去りになる。 - 応答できない要求が多すぎて残りのクラスターメンバーで処理しきれなくなり、停止していると想定されてクラスターから除外されます。 メンバーが失われた場合にクラスターの残りのメンバーを保護するには、ノードの同時更新を停止する最小クォーラムサイズを設定します。これにより、クラスター内のアクティブなノードの数が設定値を下回ったとき、QuorumException がスローされます。

クラスターのクォーラムサイズを設定する場合には QuorumExceptions をキャッチして、メールの送信、プロセスの停止、ログの実行、再試行戦略の実行などを実行するようにしてください。
クォーラムを有効にするには、​`mule.cluster.quorumsize`​ プロパティをクラスター設定ファイル ​`{MULE_HOME}/.mule/mule-cluster.properties`​ に配置して、稼働状態を維持するためのクラスターの最小ノード数を定義します。

クォーラム機能は、オブジェクトストアを使用するコンポーネントでのみ有効です。
### [](#オブジェクトストアの永続性)オブジェクトストアの永続性

クラスターオブジェクトストアの永続性を維持するには、中央 JDBC ストアをセットアップしてください。そうしないと、オブジェクトストア設定で永続性設定が有効になっていても、すべてのクラスターノードをシャットダウンした場合にオブジェクトストアのコンテンツが失われます。
Mule Runtime Engine をオンプレミスで使用する場合は、すべてのクラスターノードからアクセスできる中央システムに JDBC データを永続的に保存できます。 以下のリレーショナルデータベースシステムがサポートされています。 - MySQL 5.5+ - PostgreSQL 9 - Microsoft SQL Server 2014 - Microsoft SQL Server 2019 - Microsoft SQL Server 2022 オブジェクトストアの永続性を有効にするには、データベースを作成し、​`{MULE_HOME}/.mule/mule-cluster.properties`​ ファイルでその設定値を定義します。 1. `mule.cluster.jdbcstoreurl`​: データベースに接続するための JDBC URL 2. `mule.cluster.jdbcstoreusername`​: データベースのユーザー名 3. `mule.cluster.jdbcstorepassword`​: データベースのユーザーパスワード 4. `mule.cluster.jdbcstoredriver`​: JDBC ドライバーのクラス名 5. `mule.cluster.jdbcstorequerystrategy`​: SQL 言語 このパラメーターで有効な設定値については、​[クラスター設定パラメーター](#cluster-config-params)​を参照してください。 この機能により、保持するオブジェクトストアごとにテーブルが作成されるため、データベースのテーブルは自動的に作成されます。 オブジェクトストアごとに 2 つのテーブルが作成されます。 - データを保存するテーブル - パーティションを保存するテーブル。 #### [](#オブジェクトストアデータベースの推奨事項)オブジェクトストアデータベースの推奨事項 - JDBC ストアでのみ使用される専用データベース/スキーマを作成することをお勧めします。 - データベースのユーザー名は、次の権限が必要です。 - データベース (​`DDL`​) でのテーブル用のオブジェクト ​`CREATE`​ および ​`DROP`​ の作成。 - 作成するオブジェクト (​`DML`​)、​`INSERT`​、​`UPDATE`​、​`DELETE`​、および ​`SELECT`​ のアクセスと管理。 - データストレージは、すべてのノードからアクセスできる中央 DB でホストする必要があることを常に念頭に置いてください。クラスターごとに複数のデータベースを使用しないでください。 これらの値の設定方法についての詳細は、​[永続性のクラスター設定リファレンス](#persistency-config)​を参照してください。 - 一部のリレーショナルデータベースにはテーブル名の長さに関する特定の制約があります。​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して長いテーブル名を短い値に変換します。 このプロパティの設定方法についての詳細は、​[テーブル名トランスフォーマー](#table-name-transformers)​セクションを参照してください。 - 永続的なオブジェクトストアは、​`ComboPooledDataSource`​ Java クラスに基づいたデータベース接続プールを使用します。Mule Runtime Engine は、接続プールの動作の明示的な値を設定しません。標準設定では、各プロパティのデフォルト値を使用します。 たとえば、​`maxIdleTime`​ のデフォルト値は 0 です。これは、アイドル接続の期限が切れず、プールから削除されないことを意味します。アイドル接続は、アイドル状態でデータベースに接続されたままになります。 接続プールの動作を設定するには、次のいずれかのオプションを使用して目的のパラメーター値をランタイムに渡します。 - Mule の起動時にコマンドラインで複数のパラメーターを渡す。 ```console $ $MULE_HOME/bin/mule start \ -M-Dc3p0.maxIdleTime= \ -M-Dc3p0.maxIdleTimeExcessConnections= ``` ``​ を目的の値 (ミリ秒) に置き換えます。 - `$MULE_HOME/conf/wrapper.conf`​ ファイルに複数行を追加する。 wrapper.java.additional.=-Dc3p0.maxIdleTime= wrapper.java.additional.=-Dc3p0.maxIdleTimeExcessConnections= ``​ を ​`wrapper.conf`​ ファイルの次に大きい順次値に置き換えます。
ComboPooledDataSource​ Java クラスのプール設定についての詳細は、 この記事​を参照してください。
### [](#監視)監視 [JMX テクノロジー](http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html)​を使用して、クラスターメンバーでスローされるイベントを監視できます。 JMX 監視オプションは、デフォルトで無効になっています。有効にするには、​`mule.cluster.jmxenabled`​ プロパティを ​`{MULE_HOME}/.mule/mule-cluster.properties`​ 設定ファイルに追加します。 JMX を有効にすると、パフォーマンスのオーバーヘッドが発生する可能性があります (基盤となる構造で各ノードの統計を取得するためのリスナーが追加される場合)。 #### [](#table-name-transformers)テーブル名トランスフォーマー `mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティを使用して、テーブル名を変更するためのカスタムトランスフォーマーを定義できます。 たとえば、​`mule-cluster.properties`​ ファイルに次のプロパティを設定すると、Mule は MD5 とプレフィックスを使用してテーブル名をハッシュし、テーブルを Mule テーブルとして識別します。 ```none mule.cluster.jdbcstoretableNametransformerstrategy=com.mulesoft.mule.runtime.module.cluster.api.persistence.query.MD5TableNameTransformerStrategy ``` テーブル名をハッシュすることで確実に長さの制約が守られます。 `com.mulesoft.mule.runtime.module.cluster.api.persistence.query.TableNameTransformerStrategy`​ インターフェースを実装してカスタムトランスフォーマー戦略を作成してから、​`mule.cluster.jdbcstoretableNametransformerstrategy`​ プロパティにカスタムトランスフォーマー戦略を設定することもできます。 ### [](#メンバーシップリスナー)メンバーシップリスナー メンバーシップリスナーを使用すると、次のイベントが発生するたびに通知を取得できます。 1. 新しいメンバーがクラスターに追加される 2. 既存のメンバーがクラスターから離脱する これらのいずれかのイベントがトリガーされると、メンバーシップリスナーは、参加または離脱したメンバーのアドレスを出力します。 ## [](#cluster-config-params)クラスター設定パラメーター 次の表に、​`mule-cluster.properties`​ ファイルのパラメーターを示します。
プロパティ名 説明 必須

mule.clusterId

クラスターの一意の識別子。任意の英数字文字列になります。

はい

mule.clusterNodeId

クラスター内のノードの一意の ID。1 ～クラスター内のノード数の間の整数になります。

はい

mule.clusterSize

クラスターに属するノードの数。

はい

mule.cluster.networkinterfaces

Hazelcast で使用されるインターフェースのカンマ区切りリスト。以下のようにワイルドカードがサポートされています。

192.168.1.*,192.168.100.25

いいえ

mule.cluster.nodes

クラスターに属するノード。​<host:port>​ の形式になります (例: 172.16.9.24:9000​)。1 つの IP アドレスのみを指定すると、サーバーがクラスターに参加できるようになります。

ポート番号は省略可能です。設定しない場合は、デフォルトは 5701 になります。複数のホストを含めるには、カンマ区切りリストを作成します。

このオプションでは、指定した固定 IP アドレスでクラスターを設定します。クラスターノードの検出にマルチキャストを使用しない場合、このオプションを使用します。このオプションを使用する場合、​mule.cluster.multicastenabled​ を ​false​ に設定します。そのように設定しないと、クラスターを開始するときに例外がスローされます。(この表の次の項目を参照)。

例:

ポート 9000 をリスンする 2 つのノード:

172.16.9.24:9000,172.16.9.51:9000

ポート 5701 をリスンする 2 つのノード:

192.168.1.19,192.168.1.20

いいえ

mule.cluster.quorumsize

稼働状態を維持するためにクラスター内に必要なマシンの最小数を定義できます。

いいえ

mule.cluster.multicastenabled

(Boolean (ブール))​ マルチキャストを有効/無効にします。クラスターノードの検出に固定 IP アドレスを使用する場合、​false​ に設定します (上記の ​mule.cluster.nodes​ オプションを参照)。
true​ に設定する場合、​mule.cluster.nodes​ で IP アドレスを設定しないでください。

いいえ

mule.cluster.multicastgroup

使用するマルチキャストグループ IP アドレス。

いいえ

mule.cluster.multicastport

使用するマルチキャストポート番号。

いいえ

​mule.cluster.jdbcstoreurl

データベースに接続するための JDBC URL

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoreusername

データベースのユーザー名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorepassword

データベースのユーザーパスワード

永続データを保存する場合のみ必須。

mule.cluster.jdbcstoredriver

JDBC ドライバーのクラス名

永続データを保存する場合のみ必須。

mule.cluster.jdbcstorequerystrategy

保存されているオブジェクトデータにアクセスするための SQL 言語。 このプロパティは、3 つの異なる値 (​mssql​、​mysql​、​postgresql​) を取ります。

永続データを保存する場合のみ必須。

mule.cluster.jmxenabled

(Boolean (ブール))​ 監視を有効/無効にします。

いいえ

mule.cluster.listenersenabled

(Boolean (ブール))​ メンバーシップリスナーを有効/無効にします。クラスターメンバーが参加または離脱したときにノードに通知するには、​true​ に設定します。

いいえ
# 手動移行プロセス [移行のための準備](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-prep)​方法がわかったら、次に移行ステップの概要を理解することが重要です。 注意 Mule Migration Assistant を使用した支援による移行の場合は、代わりに MMA ユーザードキュメントにリンクしている [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ から開始してください。 完全な手動移行の場合: 1. Database Connector などの必要なすべてのモジュールを Anypoint Studio 7 パレットに追加します。 注意: - モジュールは Studio 7 パレットから追加できます。他に、Anypoint Exchange で入手できるモジュールもあります。 - モジュールをプロジェクトに追加する場合、すべての Mule プロジェクトはデフォルトで Maven に対応しています。 2. すべてのグローバル設定を移行します。 3. 設定プロパティを移行します。 4. Mule 4 でこのコンポーネントがどのように機能するかを把握し、Mule 3 から何が変更されたかを確認します。 5. Mule メッセージ構造 (属性、ペイロード、変数) に対する変更が自分の設定にどのような影響を与えるかを理解します。​[「Mule 4 入門: Mule メッセージ」](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-mule-message)​を参照してください。 6. 式およびスクリプトを DataWeave バージョン 2 に更新します。 - 特定の関数モジュールのインポートなど、DataWeave 1 と DataWeave 2 の違いに注意して、構文の変更を理解します。​[「DataWeave 1.0 から 2.x への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-dataweave)​を参照してください。 - たとえばコネクタや Choice コンポーネントで MEL 式を DataWeave 2 に変更します。​[「MEL の DataWeave への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-mel)​を参照してください。 7. 使用可能な新しい例外種別で処理するすべての例外を Mule 4 に更新します。 8. API を使用している場合は、HTTP ステータスコードの設定方法を理解します。 ## [](#関連情報)関連情報 [移行の準備](https://docs.mulesoft.com/jp/mule-runtime/4.3/migration-prep) [Mule 4 の概要](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-overview) # 手動移行プロセス [移行のための準備](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-prep)​方法がわかったら、次に移行ステップの概要を理解することが重要です。 注意 Mule Migration Assistant を使用した支援による移行の場合は、代わりに MMA ユーザードキュメントにリンクしている [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ から開始してください。 完全な手動移行の場合: 1. Database Connector などの必要なすべてのモジュールを Anypoint Studio 7 パレットに追加します。 注意: - モジュールは Studio 7 パレットから追加できます。他に、Anypoint Exchange で入手できるモジュールもあります。 - モジュールをプロジェクトに追加する場合、すべての Mule プロジェクトはデフォルトで Maven に対応しています。 2. すべてのグローバル設定を移行します。 3. 設定プロパティを移行します。 4. Mule 4 でこのコンポーネントがどのように機能するかを把握し、Mule 3 から何が変更されたかを確認します。 5. Mule メッセージ構造 (属性、ペイロード、変数) に対する変更が自分の設定にどのような影響を与えるかを理解します。​[「Mule 4 入門: Mule メッセージ」](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-mule-message)​を参照してください。 6. 式およびスクリプトを DataWeave バージョン 2 に更新します。 - 特定の関数モジュールのインポートなど、DataWeave 1 と DataWeave 2 の違いに注意して、構文の変更を理解します。​[「DataWeave 1.0 から 2.x への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-dataweave)​を参照してください。 - たとえばコネクタや Choice コンポーネントで MEL 式を DataWeave 2 に変更します。​[「MEL の DataWeave への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-mel)​を参照してください。 7. 使用可能な新しい例外種別で処理するすべての例外を Mule 4 に更新します。 8. API を使用している場合は、HTTP ステータスコードの設定方法を理解します。 ## [](#関連情報)関連情報 [移行の準備](https://docs.mulesoft.com/jp/mule-runtime/4.4/migration-prep) [Mule 4 の概要](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-overview) # 手動移行プロセス [移行のための準備](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-prep)​方法がわかったら、次に移行ステップの概要を理解することが重要です。 注意 Mule Migration Assistant を使用した支援による移行の場合は、代わりに MMA ユーザードキュメントにリンクしている [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ から開始してください。 完全な手動移行の場合: 1. Database Connector などの必要なすべてのモジュールを Anypoint Studio 7 パレットに追加します。 注意: - モジュールは Studio 7 パレットから追加できます。他に、Anypoint Exchange で入手できるモジュールもあります。 - モジュールをプロジェクトに追加する場合、すべての Mule プロジェクトはデフォルトで Maven に対応しています。 2. すべてのグローバル設定を移行します。 3. 設定プロパティを移行します。 4. Mule 4 でこのコンポーネントがどのように機能するかを把握し、Mule 3 から何が変更されたかを確認します。 5. Mule メッセージ構造 (属性、ペイロード、変数) に対する変更が自分の設定にどのような影響を与えるかを理解します。​[「Mule 4 入門: Mule メッセージ」](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-mule-message)​を参照してください。 6. 式およびスクリプトを DataWeave バージョン 2 に更新します。 - 特定の関数モジュールのインポートなど、DataWeave 1 と DataWeave 2 の違いに注意して、構文の変更を理解します。​[「DataWeave 1.0 から 2.x への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-dataweave)​を参照してください。 - たとえばコネクタや Choice コンポーネントで MEL 式を DataWeave 2 に変更します。​[「MEL の DataWeave への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-mel)​を参照してください。 7. 使用可能な新しい例外種別で処理するすべての例外を Mule 4 に更新します。 8. API を使用している場合は、HTTP ステータスコードの設定方法を理解します。 ## [](#関連情報)関連情報 [移行の準備](https://docs.mulesoft.com/jp/mule-runtime/4.5/migration-prep) [Mule 4 の概要](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-overview) # 手動移行プロセス [移行のための準備](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-prep)​方法がわかったら、次に移行ステップの概要を理解することが重要です。 注意 Mule Migration Assistant を使用した支援による移行の場合は、代わりに MMA ユーザードキュメントにリンクしている [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ から開始してください。 完全な手動移行の場合: 1. Database Connector などの必要なすべてのモジュールを Anypoint Studio 7 パレットに追加します。 注意: - モジュールは Studio 7 パレットから追加できます。他に、Anypoint Exchange で入手できるモジュールもあります。 - モジュールをプロジェクトに追加する場合、すべての Mule プロジェクトはデフォルトで Maven に対応しています。 2. すべてのグローバル設定を移行します。 3. 設定プロパティを移行します。 4. Mule 4 でこのコンポーネントがどのように機能するかを把握し、Mule 3 から何が変更されたかを確認します。 5. Mule メッセージ構造 (属性、ペイロード、変数) に対する変更が自分の設定にどのような影響を与えるかを理解します。​[「Mule 4 入門: Mule メッセージ」](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-mule-message)​を参照してください。 6. 式およびスクリプトを DataWeave バージョン 2 に更新します。 - 特定の関数モジュールのインポートなど、DataWeave 1 と DataWeave 2 の違いに注意して、構文の変更を理解します。​[「DataWeave 1.0 から 2.x への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-dataweave)​を参照してください。 - たとえばコネクタや Choice コンポーネントで MEL 式を DataWeave 2 に変更します。​[「MEL の DataWeave への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-mel)​を参照してください。 7. 使用可能な新しい例外種別で処理するすべての例外を Mule 4 に更新します。 8. API を使用している場合は、HTTP ステータスコードの設定方法を理解します。 ## [](#関連情報)関連情報 [移行の準備](https://docs.mulesoft.com/jp/mule-runtime/4.6/migration-prep) [Mule 4 の概要](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-overview) # 手動移行プロセス [移行のための準備](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-prep)​方法がわかったら、次に移行ステップの概要を理解することが重要です。 注意 Mule Migration Assistant を使用した支援による移行の場合は、代わりに MMA ユーザードキュメントにリンクしている [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ から開始してください。 完全な手動移行の場合: 1. Database Connector などの必要なすべてのモジュールを Anypoint Studio 7 パレットに追加します。 注意: - モジュールは Studio 7 パレットから追加できます。他に、Anypoint Exchange で入手できるモジュールもあります。 - モジュールをプロジェクトに追加する場合、すべての Mule プロジェクトはデフォルトで Maven に対応しています。 2. すべてのグローバル設定を移行します。 3. 設定プロパティを移行します。 4. Mule 4 でこのコンポーネントがどのように機能するかを把握し、Mule 3 から何が変更されたかを確認します。 5. Mule メッセージ構造 (属性、ペイロード、変数) に対する変更が自分の設定にどのような影響を与えるかを理解します。​[「Mule 4 入門: Mule メッセージ」](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-mule-message)​を参照してください。 6. 式およびスクリプトを DataWeave バージョン 2 に更新します。 - 特定の関数モジュールのインポートなど、DataWeave 1 と DataWeave 2 の違いに注意して、構文の変更を理解します。​[「DataWeave 1.0 から 2.x への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-dataweave)​を参照してください。 - たとえばコネクタや Choice コンポーネントで MEL 式を DataWeave 2 に変更します。​[「MEL の DataWeave への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-mel)​を参照してください。 7. 使用可能な新しい例外種別で処理するすべての例外を Mule 4 に更新します。 8. API を使用している場合は、HTTP ステータスコードの設定方法を理解します。 ## [](#関連情報)関連情報 [移行の準備](https://docs.mulesoft.com/jp/mule-runtime/4.7/migration-prep) [Mule 4 の概要](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-overview) # 手動移行プロセス [移行のための準備](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-prep)​方法がわかったら、次に移行ステップの概要を理解することが重要です。 注意 Mule Migration Assistant を使用した支援による移行の場合は、代わりに MMA ユーザードキュメントにリンクしている [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ から開始してください。 完全な手動移行の場合: 1. Database Connector などの必要なすべてのモジュールを Anypoint Studio 7 パレットに追加します。 注意: - モジュールは Studio 7 パレットから追加できます。他に、Anypoint Exchange で入手できるモジュールもあります。 - モジュールをプロジェクトに追加する場合、すべての Mule プロジェクトはデフォルトで Maven に対応しています。 2. すべてのグローバル設定を移行します。 3. 設定プロパティを移行します。 4. Mule 4 でこのコンポーネントがどのように機能するかを把握し、Mule 3 から何が変更されたかを確認します。 5. Mule メッセージ構造 (属性、ペイロード、変数) に対する変更が自分の設定にどのような影響を与えるかを理解します。​[「Mule 4 入門: Mule メッセージ」](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-mule-message)​を参照してください。 6. 式およびスクリプトを DataWeave バージョン 2 に更新します。 - 特定の関数モジュールのインポートなど、DataWeave 1 と DataWeave 2 の違いに注意して、構文の変更を理解します。​[「DataWeave 1.0 から 2.x への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-dataweave)​を参照してください。 - たとえばコネクタや Choice コンポーネントで MEL 式を DataWeave 2 に変更します。​[「MEL の DataWeave への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-mel)​を参照してください。 7. 使用可能な新しい例外種別で処理するすべての例外を Mule 4 に更新します。 8. API を使用している場合は、HTTP ステータスコードの設定方法を理解します。 ## [](#関連情報)関連情報 [移行の準備](https://docs.mulesoft.com/jp/mule-runtime/4.8/migration-prep) [Mule 4 の概要](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-overview) # 手動移行プロセス [移行のための準備](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-prep)​方法がわかったら、次に移行ステップの概要を理解することが重要です。 注意 Mule Migration Assistant を使用した支援による移行の場合は、代わりに MMA ユーザードキュメントにリンクしている [ユーザードキュメント (GitHub)](https://github.com/mulesoft/mule-migration-assistant/blob/master/docs/migration-intro.adoc)​ から開始してください。 完全な手動移行の場合: 1. Database Connector などの必要なすべてのモジュールを Anypoint Studio 7 パレットに追加します。 注意: - モジュールは Studio 7 パレットから追加できます。他に、Anypoint Exchange で入手できるモジュールもあります。 - モジュールをプロジェクトに追加する場合、すべての Mule プロジェクトはデフォルトで Maven に対応しています。 2. すべてのグローバル設定を移行します。 3. 設定プロパティを移行します。 4. Mule 4 でこのコンポーネントがどのように機能するかを把握し、Mule 3 から何が変更されたかを確認します。 5. Mule メッセージ構造 (属性、ペイロード、変数) に対する変更が自分の設定にどのような影響を与えるかを理解します。​[「Mule 4 入門: Mule メッセージ」](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-mule-message)​を参照してください。 6. 式およびスクリプトを DataWeave バージョン 2 に更新します。 - 特定の関数モジュールのインポートなど、DataWeave 1 と DataWeave 2 の違いに注意して、構文の変更を理解します。​[「DataWeave 1.0 から 2.x への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-dataweave)​を参照してください。 - たとえばコネクタや Choice コンポーネントで MEL 式を DataWeave 2 に変更します。​[「MEL の DataWeave への移行」](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-mel)​を参照してください。 7. 使用可能な新しい例外種別で処理するすべての例外を Mule 4 に更新します。 8. API を使用している場合は、HTTP ステータスコードの設定方法を理解します。 ## [](#関連情報)関連情報 [移行の準備](https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-prep) [Mule 4 の概要](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-overview) # 検索条件の移行 Mule 4 では ​`filters`​ は使用されなくなりました。Mule 3 で提供された検索条件の機能は、​[Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ を使用して実行できます。 ## [](#検索条件の適用)検索条件の適用 Mule 3 では、メッセージが絞り込まれたら、その時点で通知せずにフローが終了しました。 Validation Module では条件が一致しないとフローが失敗し、移行されたフローに ​`VALIDATION`​ エラーを処理させます。 応答を送信するための取得元があるフローが ​`VALIDATION`​ エラーを処理する必要があり、これを行うには、検証エラーのエラーハンドラーで変数を設定します。次に例を示します。 Mule 4 の例 ```xml ... ... ``` 次に、取得元のエラー応答ビルダーで set variable を照会し、クライアントに適切な応答を送信できます。たとえば、​`http:listener`​ の取得元は次のようになります。 Mule 4 の例 ```xml #[error.description] ... ``` このケースでは、イベントが絞り込まれる場合は 400 (Bad Request) コードが返されます。 ## [](#カスタム検索条件または複雑な検索条件の移行)カスタム検索条件または複雑な検索条件の移行 ほとんどの場合、式言語を使用するためにカスタムまたは複雑なネストされた検索条件を移行できます。同じ検索条件を数か所で使用する必要がある場合は、DataWeave スクリプトを外部ファイルに保存することができます。 DataWeave がサポートしない方法でデータを絞り込む場合、Java Module か Scripting Module を使用し、カスタムコードで絞り込みを実行します。 ## [](#関連情報)関連情報 [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.3/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # 検索条件の移行 Mule 4 では ​`filters`​ は使用されなくなりました。Mule 3 で提供された検索条件の機能は、​[Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ を使用して実行できます。 ## [](#検索条件の適用)検索条件の適用 Mule 3 では、メッセージが絞り込まれたら、その時点で通知せずにフローが終了しました。 Validation Module では条件が一致しないとフローが失敗し、移行されたフローに ​`VALIDATION`​ エラーを処理させます。 応答を送信するための取得元があるフローが ​`VALIDATION`​ エラーを処理する必要があり、これを行うには、検証エラーのエラーハンドラーで変数を設定します。次に例を示します。 Mule 4 の例 ```xml ... ... ``` 次に、取得元のエラー応答ビルダーで set variable を照会し、クライアントに適切な応答を送信できます。たとえば、​`http:listener`​ の取得元は次のようになります。 Mule 4 の例 ```xml #[error.description] ... ``` このケースでは、イベントが絞り込まれる場合は 400 (Bad Request) コードが返されます。 ## [](#カスタム検索条件または複雑な検索条件の移行)カスタム検索条件または複雑な検索条件の移行 ほとんどの場合、式言語を使用するためにカスタムまたは複雑なネストされた検索条件を移行できます。同じ検索条件を数か所で使用する必要がある場合は、DataWeave スクリプトを外部ファイルに保存することができます。 DataWeave がサポートしない方法でデータを絞り込む場合、Java Module か Scripting Module を使用し、カスタムコードで絞り込みを実行します。 ## [](#関連情報)関連情報 [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.4/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # 検索条件の移行 Mule 4 では ​`filters`​ は使用されなくなりました。Mule 3 で提供された検索条件の機能は、​[Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​を使用して実行できます。 ## [](#検索条件の適用)検索条件の適用 Mule 3 では、メッセージが絞り込まれたら、その時点で通知せずにフローが終了しました。 Validation Module では条件が一致しないとフローが失敗し、移行されたフローに ​`VALIDATION`​ エラーを処理させます。 応答を送信するための取得元があるフローが ​`VALIDATION`​ エラーを処理する必要があり、これを行うには、検証エラーのエラーハンドラーで変数を設定します。次に例を示します。 Mule 4 の例 ```xml ... ... ``` 次に、取得元のエラー応答ビルダーで set variable を照会し、クライアントに適切な応答を送信できます。たとえば、​`http:listener`​ の取得元は次のようになります。 Mule 4 の例 ```xml #[error.description] ... ``` このケースでは、イベントが絞り込まれる場合は 400 (Bad Request) コードが返されます。 ## [](#カスタム検索条件または複雑な検索条件の移行)カスタム検索条件または複雑な検索条件の移行 ほとんどの場合、式言語を使用するためにカスタムまたは複雑なネストされた検索条件を移行できます。同じ検索条件を数か所で使用する必要がある場合は、DataWeave スクリプトを外部ファイルに保存することができます。 DataWeave がサポートしない方法でデータを絞り込む場合、Java Module か Scripting Module を使用し、カスタムコードで絞り込みを実行します。 ## [](#関連情報)関連情報 [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.5/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # 検索条件の移行 Mule 4 では ​`filters`​ は使用されなくなりました。Mule 3 で提供された検索条件の機能は、​[Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ を使用して実行できます。 ## [](#検索条件の適用)検索条件の適用 Mule 3 では、メッセージが絞り込まれたら、その時点で通知せずにフローが終了しました。 Validation Module では条件が一致しないとフローが失敗し、移行されたフローに ​`VALIDATION`​ エラーを処理させます。 応答を送信するための取得元があるフローが ​`VALIDATION`​ エラーを処理する必要があり、これを行うには、検証エラーのエラーハンドラーで変数を設定します。次に例を示します。 Mule 4 の例 ```xml ... ... ``` 次に、取得元のエラー応答ビルダーで set variable を照会し、クライアントに適切な応答を送信できます。たとえば、​`http:listener`​ の取得元は次のようになります。 Mule 4 の例 ```xml #[error.description] ... ``` このケースでは、イベントが絞り込まれる場合は 400 (Bad Request) コードが返されます。 ## [](#カスタム検索条件または複雑な検索条件の移行)カスタム検索条件または複雑な検索条件の移行 ほとんどの場合、式言語を使用するためにカスタムまたは複雑なネストされた検索条件を移行できます。同じ検索条件を数か所で使用する必要がある場合は、DataWeave スクリプトを外部ファイルに保存することができます。 DataWeave がサポートしない方法でデータを絞り込む場合、Java Module か Scripting Module を使用し、カスタムコードで絞り込みを実行します。 ## [](#関連情報)関連情報 [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.6/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # 検索条件の移行 Mule 4 では ​`filters`​ は使用されなくなりました。Mule 3 で提供された検索条件の機能は、​[Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ を使用して実行できます。 ## [](#検索条件の適用)検索条件の適用 Mule 3 では、メッセージが絞り込まれたら、その時点で通知せずにフローが終了しました。 Validation Module では条件が一致しないとフローが失敗し、移行されたフローに ​`VALIDATION`​ エラーを処理させます。 応答を送信するための取得元があるフローが ​`VALIDATION`​ エラーを処理する必要があり、これを行うには、検証エラーのエラーハンドラーで変数を設定します。次に例を示します。 Mule 4 の例 ```xml ... ... ``` 次に、取得元のエラー応答ビルダーで set variable を照会し、クライアントに適切な応答を送信できます。たとえば、​`http:listener`​ の取得元は次のようになります。 Mule 4 の例 ```xml #[error.description] ... ``` このケースでは、イベントが絞り込まれる場合は 400 (Bad Request) コードが返されます。 ## [](#カスタム検索条件または複雑な検索条件の移行)カスタム検索条件または複雑な検索条件の移行 ほとんどの場合、式言語を使用するためにカスタムまたは複雑なネストされた検索条件を移行できます。同じ検索条件を数か所で使用する必要がある場合は、DataWeave スクリプトを外部ファイルに保存することができます。 DataWeave がサポートしない方法でデータを絞り込む場合、Java Module か Scripting Module を使用し、カスタムコードで絞り込みを実行します。 ## [](#関連情報)関連情報 [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.7/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # 検索条件の移行 Mule 4 では ​`filters`​ は使用されなくなりました。Mule 3 で提供された検索条件の機能は、​[Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ を使用して実行できます。 ## [](#検索条件の適用)検索条件の適用 Mule 3 では、メッセージが絞り込まれたら、その時点で通知せずにフローが終了しました。 Validation Module では条件が一致しないとフローが失敗し、移行されたフローに ​`VALIDATION`​ エラーを処理させます。 応答を送信するための取得元があるフローが ​`VALIDATION`​ エラーを処理する必要があり、これを行うには、検証エラーのエラーハンドラーで変数を設定します。次に例を示します。 Mule 4 の例 ```xml ... ... ``` 次に、取得元のエラー応答ビルダーで set variable を照会し、クライアントに適切な応答を送信できます。たとえば、​`http:listener`​ の取得元は次のようになります。 Mule 4 の例 ```xml #[error.description] ... ``` このケースでは、イベントが絞り込まれる場合は 400 (Bad Request) コードが返されます。 ## [](#カスタム検索条件または複雑な検索条件の移行)カスタム検索条件または複雑な検索条件の移行 ほとんどの場合、式言語を使用するためにカスタムまたは複雑なネストされた検索条件を移行できます。同じ検索条件を数か所で使用する必要がある場合は、DataWeave スクリプトを外部ファイルに保存することができます。 DataWeave がサポートしない方法でデータを絞り込む場合、Java Module か Scripting Module を使用し、カスタムコードで絞り込みを実行します。 ## [](#関連情報)関連情報 [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.8/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # 検索条件の移行 Mule 4 では ​`filters`​ は使用されなくなりました。Mule 3 で提供された検索条件の機能は、​[Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/)​ を使用して実行できます。 ## [](#検索条件の適用)検索条件の適用 Mule 3 では、メッセージが絞り込まれたら、その時点で通知せずにフローが終了しました。 Validation Module では条件が一致しないとフローが失敗し、移行されたフローに ​`VALIDATION`​ エラーを処理させます。 応答を送信するための取得元があるフローが ​`VALIDATION`​ エラーを処理する必要があり、これを行うには、検証エラーのエラーハンドラーで変数を設定します。次に例を示します。 Mule 4 の例 ```xml ... ... ``` 次に、取得元のエラー応答ビルダーで set variable を照会し、クライアントに適切な応答を送信できます。たとえば、​`http:listener`​ の取得元は次のようになります。 Mule 4 の例 ```xml #[error.description] ... ``` このケースでは、イベントが絞り込まれる場合は 400 (Bad Request) コードが返されます。 ## [](#カスタム検索条件または複雑な検索条件の移行)カスタム検索条件または複雑な検索条件の移行 ほとんどの場合、式言語を使用するためにカスタムまたは複雑なネストされた検索条件を移行できます。同じ検索条件を数か所で使用する必要がある場合は、DataWeave スクリプトを外部ファイルに保存することができます。 DataWeave がサポートしない方法でデータを絞り込む場合、Java Module か Scripting Module を使用し、カスタムコードで絞り込みを実行します。 ## [](#関連情報)関連情報 [Validation Module](https://docs.mulesoft.com/jp/validation-connector/latest/) [DataWeave 言語](https://docs.mulesoft.com/jp/mule-runtime/4.9/dataweave) [Scripting Module](https://docs.mulesoft.com/jp/scripting-module/latest/) [Java Module](https://docs.mulesoft.com/jp/java-module/latest/) # 機能フラグのメカニズム Mule Runtime Engine には機能フラグのメカニズムが組み込まれています。これを使用すると、必要な最小の Mule バージョンに基づいて Mule アプリケーションで Mule インスタンスの動作を変更することができます。この機能では、Mule アプリケーションが以降の Mule Runtime バージョンで引き続き動作できるために後方互換性が確保されます。一方、新しい Mule アプリケーションは、Mule インスタンスに実装された最新のバグ修正を活用することができます。 機能フラグのメカニズムは自動です。Mule インスタンスにデプロイされた Mule アプリケーションごとに、Mule は、Mule アプリケーションのアプリケーション記述子ファイル (​`mule-artifact.json`​) に設定されたアプリケーションの最小 Mule バージョンに基づいて有効または無効な機能を判断します。 デフォルトでは、以前の Mule バージョンで実行されている Mule アプリケーションとの後方互換性のない新機能またはバグ修正は Mule Runtime Engine によって無効化されます。ただし、各 Mule アプリケーション、または同じ Mule インスタンスで実行されるすべてのアプリケーションに設定される機能フラグを管理することができます。 ## [](#mule-アプリケーションの機能フラグの設定)Mule アプリケーションの機能フラグの設定 Mule アプリケーションの機能フラグを設定するには、アプリケーションの ​`mule-artifact.json`​ ファイルの ​`minMuleVersion`​ 値を変更します。この設定では、この特定のバージョンにリリースされたすべての機能とバグ修正を実装し、以降の Mule バージョンでデフォルトでアクティブになっている機能とバグ修正を無効化して、このアプリケーションを実行するように Mule インスタンスに指示します。 たとえば、Mule 4.4.0 で Mule アプリケーションを実行し、Mule 4.1.0 までのコア機能を変更しない機能のみを適用するように Mule インスタンスに指示できます。 `mule-artifact.json`​ ファイルの例 { "minMuleVersion": "4.1.0" } ## [](#mule-インスタンスの機能フラグの設定)Mule インスタンスの機能フラグの設定 機能フラグを設定する代替方法として、システムプロパティを使用する方法があります。この場合、使用可能な各機能フラグを有効または無効にすることができます。ただし、システムプロパティを介して機能フラグを設定すると、変更が Mule インスタンスレベルで適用されるため、この Mule インスタンスにデプロイされたすべてのアプリケーションが、設定された機能フラグに従って動作します。 システムプロパティは他のデプロイメント対象では設定できないため、この設定はオンプレミスデプロイメントのみとの互換性があります。 たとえば、このインスタンスで実行されているすべてのアプリケーションで特定の機能を有効または無効にするように Mule 4.3.0 インスタンスを設定することができます。 `wrapper.conf`​ ファイルの例 … wrapper.java.additional.999=-DHONOUR\_RESERVED\_PROPERTIES\_PROPERTY=true wrapper.java.additional.1000=-DCOMPUTE\_CONNECTION\_ERRORS\_IN\_STATS\_PROPERTY=false ## [](#機能フラグリファレンス)機能フラグリファレンス 次の表に、使用可能な機能フラグ、機能フラグの機能の説明、機能フラグが使用可能になった Mule バージョン、機能フラグをデフォルトで有効化する以前のマイナーバージョンリリース、変更が実装された課題 ID を示します。
機能フラグ 説明

mule.batch.fixed.aggregator.transaction.record.buffer

有効にした場合、固定サイズのアグリゲーターを使用する Batch Aggregator は、完全なブロックが処理されたときにのみコミットされます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

  • 4.2.2-20210304

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19218

mule.compute.connection.errors.in.stats

有効にした場合、接続エラーがアラートトリガーの一環として計算されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19020

mule.enable.default.errorhandler.not.rollback.incorrect.tx

有効にした場合、Runtime が追加したデフォルトのエラーハンドラーは、トランザクションが応答せずにロールバックが必要になっても、トランザクションをロールバックしません。

次のバージョン以降に使用可能​

  • 4.4.0-20211227

  • 4.3.0-20211222

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19919

mule.dw.remove_shadowed_implicit_inputs

有効にした場合、DataWeave は、ルートレベルで宣言されている名前と同じ名前の暗黙的な入力を削除します。

次のバージョン以降に使用可能​

  • 4.4.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-893

mule.enable.byteBuddy.objectCreation

有効にした場合、オブジェクトのファクトリーが CGLIB ではなく Byte Buddy で作成されます。

次のバージョン以降に使用可能​

  • 4.4.0-20220321

  • 4.3.0-20220321

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • W-10672687

mule.enable.policy.isolation

有効にした場合、Mule は、ポリシーによってインポートされた拡張機能を、Mule アプリケーションによってインポートされた拡張機能とは完全に切り離して管理します。また、ポリシーの初期化の一環としてアプリケーションで宣言された明示的な設定の使用が検証により回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19226

mule.enable.profiling.service

有効にした場合、Runtime プロファイリング機能が使用できるようになります。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19588

mule.entityResolver.failOnFirstError

有効にした場合、配置できないスキーマを宣言しているアプリケーションをデプロイすると、Mule XML DSL パーサーが失敗します。それ以外の場合、このようなスキーマのバインド先の名前空間もアプリケーションで使用していると、パーサーは失敗します。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • EE-7827

mule.force.runtime.profiling.consumers.enablement

有効にした場合、Runtime によって実装されたプロファイリングコンシューマーがデフォルトで有効になります。

次のバージョン以降に使用可能​

  • 4.4.0-20220221

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19967

mule.dw.handle_splitter_exception

有効にした場合、DataWeave で内部例外を適切に処理しながらペイロードを分割するため、以降のシリアル化エラーが回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-383

mule.honour.reserved.properties

有効にした場合、​app.name​ などの予約されたプロパティをグローバルプロパティで上書きできなくなります (上書きは無視されます)。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

  • 4.3.0

課題 ID​

  • MULE-17659

mule.honourErrorMappingsWhenPolicyAppliedOnOperation

有効にした場合、操作ポリシーのエラー解決が無視されます。そのため、ポリシーが適用されるプロセッサーのエラーマッピングが正常に設定されます。

次のバージョン以降に使用可能​

  • 4.4.0-20220722

  • 4.3.0-20220725

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • W-11147961

mule.detailedCompositeRoutingExceptionLog

有効にした場合、AbstractForkJoinRouter ベースのプロセッサー (例: Parallel For Each ルーターや Scatter-Gather ルーター) は、失敗したルートの詳細なエラー情報を表示します。

次のバージョン以降に使用可能​

  • 4.4.0-20220622

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • W-10965130

mule.parallelForeach.flattenMessage

有効にした場合、parallel-foreach スコープで反復処理する項目がメッセージ (結果オブジェクトを返す操作の出力など) であれば、foreach スコープと同じようにフラット化されます。

次のバージョン以降に使用可能​

  • 4.4.0-20220221

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-20067

mule.setVariable.WithNullValue

有効にした場合、変数の値が ​null​ であっても、Set Variable コンポーネントで変数が作成されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19443

mule.startExtensionComponentsWithArtifactClassloader

有効にした場合、拡張機能は、デプロイ可能なアーティファクト (アプリケーション、ポリシー、ドメイン) からエクスポートされたリソースのみを読み込むことができます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19815

mule.transformer.toString.transformIteratorElements

有効にした場合、文字列に変換される管理されたカーソルイテレーターには、汎用値 ​org.mule.runtime.core.internal.streaming.object.-ManagedCursorIteratorProvider$ManagedCursorIterator@​ ではなく要素の表現が表示されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19323

mule.suppress.mule.exceptions

有効にすると、エラー抑制が行われます。この機能により、Web Service Consumer Connector や Until Successful スコープなどのコンポーネントでその名前空間外のエラーが報告されなくなります。

Web Service Consumer での接続エラーのエラーログの抜粋の例 (HTTP:CONNECTIVITY が抑制されています):

Error type : WSC:INVALID_WSDL​
Caused by  : HTTP:CONNECTIVITY

抑制されたエラーは On Error ハンドラーでも照合できる根本原因として扱われます。

次のバージョン以降に使用可能​

  • 4.4.0-20220922

次のバージョン以降にデフォルトで有効化​

  • 4.4.0-20220922

課題 ID​

  • W-11778765

mule.errorTypes.lax

有効にすると、参照されないエラーハンドラー/コンポーネントに対してもエラー種別検証が適用されます。

次のバージョン以降に使用可能​

  • 4.4.0-20211227

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19879

mule.support.native.library.dependencies

有効にした場合、アプリケーションがネイティブライブラリにアクセスすると、宣言されたネイティブライブラリの残りも読み込まれます。これにより、アクセスしたネイティブライブラリが別のネイティブライブラリに連動している場合に ​UnsatisfiedLinkError​ などのエラーを回避することができます。ライブラリは、​sharedLibraries​ 設定で連動関係の順序に従って宣言する必要があります。つまり、ライブラリ A がライブラリ B に連動する場合、A を最初に宣言する必要があります。ドメインでネイティブライブラリを宣言することもサポートされます。

次のバージョン以降に使用可能​

  • 4.4.0-20230417

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • W-11855052

mule.forkJoin.completeChildContextsOnTimeout

有効になっていると、タイムアウトが発生したときに、フォークおよび結合作業を実行するプロセッサー (現時点では、Scatter-Gather ルーターと Parallel For Each ルーター) が子イベントコンテキストを完了します。

次のバージョン以降に使用可能​

  • 4.4.0-20250217

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • W-16941297
## [](#関連情報)関連情報 [システムプロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-app-properties-system) # 機能フラグのメカニズム Mule Runtime Engine には機能フラグのメカニズムが組み込まれています。これを使用すると、必要な最小の Mule バージョンに基づいて Mule アプリケーションで Mule インスタンスの動作を変更することができます。この機能では、Mule アプリケーションが以降の Mule Runtime バージョンで引き続き動作できるために後方互換性が確保されます。一方、新しい Mule アプリケーションは、Mule インスタンスに実装された最新のバグ修正を活用することができます。 機能フラグのメカニズムは自動です。Mule インスタンスにデプロイされた Mule アプリケーションごとに、Mule は、Mule アプリケーションのアプリケーション記述子ファイル (​`mule-artifact.json`​) に設定されたアプリケーションの最小 Mule バージョンに基づいて有効または無効な機能を判断します。 デフォルトでは、以前の Mule バージョンで実行されている Mule アプリケーションとの後方互換性のない新機能またはバグ修正は Mule Runtime Engine によって無効化されます。ただし、各 Mule アプリケーション、または同じ Mule インスタンスで実行されるすべてのアプリケーションに設定される機能フラグを管理することができます。 ## [](#mule-アプリケーションの機能フラグの設定)Mule アプリケーションの機能フラグの設定 Mule アプリケーションの機能フラグを設定するには、アプリケーションの ​`mule-artifact.json`​ ファイルの ​`minMuleVersion`​ 値を変更します。この設定では、この特定のバージョンにリリースされたすべての機能とバグ修正を実装し、以降の Mule バージョンでデフォルトでアクティブになっている機能とバグ修正を無効化して、このアプリケーションを実行するように Mule インスタンスに指示します。 たとえば、Mule 4.5.0 で Mule アプリケーションを実行し、Mule 4.1.0 までのコア機能を変更しない機能のみを適用するように Mule インスタンスに指示できます。 `mule-artifact.json`​ ファイルの例 { "minMuleVersion": "4.1.0" } ## [](#mule-インスタンスの機能フラグの設定)Mule インスタンスの機能フラグの設定 機能フラグを設定する代替方法として、システムプロパティを使用する方法があります。この場合、使用可能な各機能フラグを有効または無効にすることができます。ただし、システムプロパティを介して機能フラグを設定すると、変更が Mule インスタンスレベルで適用されるため、この Mule インスタンスにデプロイされたすべてのアプリケーションが、設定された機能フラグに従って動作します。 システムプロパティは他のデプロイメント対象では設定できないため、この設定はオンプレミスデプロイメントのみとの互換性があります。 たとえば、このインスタンスで実行されているすべてのアプリケーションで特定の機能を有効または無効にするように Mule 4.5.0 インスタンスを設定することができます。 `wrapper.conf`​ ファイルの例 … wrapper.java.additional.999=-DHONOUR\_RESERVED\_PROPERTIES\_PROPERTY=true wrapper.java.additional.1000=-DCOMPUTE\_CONNECTION\_ERRORS\_IN\_STATS\_PROPERTY=false ## [](#機能フラグリファレンス)機能フラグリファレンス 次の表に、使用可能な機能フラグ、機能フラグの機能の説明、機能フラグが使用可能になった Mule バージョン、機能フラグをデフォルトで有効化する以前のマイナーバージョンリリース、変更が実装された課題 ID を示します。
機能フラグ 説明

mule.batch.fixed.aggregator.transaction.record.buffer

有効にした場合、固定サイズのアグリゲーターを使用する Batch Aggregator は、完全なブロックが処理されたときにのみコミットされます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

  • 4.2.2-20210304

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19218

mule.compute.connection.errors.in.stats

有効にした場合、接続エラーがアラートトリガーの一環として計算されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19020

mule.enable.default.errorhandler.not.rollback.incorrect.tx

有効にした場合、Runtime が追加したデフォルトのエラーハンドラーは、トランザクションが応答せずにロールバックが必要になっても、トランザクションをロールバックしません。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20211227

  • 4.3.0-20211222

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19919

mule.dw.remove_shadowed_implicit_inputs

有効にした場合、DataWeave は、ルートレベルで宣言されている名前と同じ名前の暗黙的な入力を削除します。

次のバージョン以降に使用可能​

  • 4.4.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-893

mule.enable.byteBuddy.objectCreation

有効にした場合、オブジェクトのファクトリーが CGLIB ではなく Byte Buddy で作成されます。

次のバージョン以降に使用可能​

  • 4.4.0-20220321

  • 4.3.0-20220321

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • W-10672687

mule.enable.policy.isolation

有効にした場合、Mule は、ポリシーによってインポートされた拡張機能を、Mule アプリケーションによってインポートされた拡張機能とは完全に切り離して管理します。また、ポリシーの初期化の一環としてアプリケーションで宣言された明示的な設定の使用が検証により回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19226

mule.enable.profiling.service

有効にした場合、Runtime プロファイリング機能が使用できるようになります。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19588

mule.entityResolver.failOnFirstError

有効にした場合、配置できないスキーマを宣言しているアプリケーションをデプロイすると、Mule XML DSL パーサーが失敗します。それ以外の場合、このようなスキーマのバインド先の名前空間もアプリケーションで使用していると、パーサーは失敗します。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • EE-7827

mule.force.runtime.profiling.consumers.enablement

有効にした場合、Runtime によって実装されたプロファイリングコンシューマーがデフォルトで有効になります。

次のバージョン以降に使用可能​

  • 4.4.0-20220221

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19967

mule.dw.handle_splitter_exception

有効にした場合、DataWeave で内部例外を適切に処理しながらペイロードを分割するため、以降のシリアル化エラーが回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-383

mule.honour.reserved.properties

有効にした場合、​app.name​ などの予約されたプロパティをグローバルプロパティで上書きできなくなります (上書きは無視されます)。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

  • 4.3.0

課題 ID​

  • MULE-17659

mule.honourErrorMappingsWhenPolicyAppliedOnOperation

有効にした場合、操作ポリシーのエラー解決が無視されます。そのため、ポリシーが適用されるプロセッサーのエラーマッピングが正常に設定されます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220722

  • 4.3.0-20220725

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11147961

mule.detailedCompositeRoutingExceptionLog

有効にした場合、AbstractForkJoinRouter ベースのプロセッサー (例: Parallel For Each ルーターや Scatter-Gather ルーター) は、失敗したルートの詳細なエラー情報を表示します。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220622

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10965130

mule.parallelForeach.flattenMessage

有効にした場合、parallel-foreach スコープで反復処理する項目がメッセージ (結果オブジェクトを返す操作の出力など) であれば、foreach スコープと同じようにフラット化されます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220221

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-20067

mule.setVariable.WithNullValue

有効にした場合、変数の値が ​null​ であっても、Set Variable コンポーネントで変数が作成されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19443

mule.startExtensionComponentsWithArtifactClassloader

有効にした場合、拡張機能は、デプロイ可能なアーティファクト (アプリケーション、ポリシー、ドメイン) からエクスポートされたリソースのみを読み込むことができます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19815

mule.transformer.toString.transformIteratorElements

有効にした場合、文字列に変換される管理されたカーソルイテレーターには、汎用値 ​org.mule.runtime.core.internal.streaming.object.-ManagedCursorIteratorProvider$ManagedCursorIterator@​ ではなく要素の表現が表示されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19323

mule.suppress.mule.exceptions

有効にすると、エラー抑制が行われます。この機能により、Web Service Consumer Connector や Until Successful スコープなどのコンポーネントでその名前空間外のエラーが報告されなくなります。

Web Service Consumer での接続エラーのエラーログの抜粋の例 (HTTP:CONNECTIVITY が抑制されています):

Error type : WSC:INVALID_WSDL​
Caused by  : HTTP:CONNECTIVITY

抑制されたエラーは On Error ハンドラーでも照合できる根本原因として扱われます。

次のバージョン以降に使用可能​

  • 4.4.0-20220922

次のバージョン以降にデフォルトで有効化​

  • 4.4.0-20220922

課題 ID​

  • W-11778765

mule.errorTypes.lax

有効にすると、参照されないエラーハンドラー/コンポーネントに対してもエラー種別検証が適用されます。

次のバージョン以降に使用可能​

  • 4.4.0-20211227

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19879

mule.support.native.library.dependencies

有効にした場合、アプリケーションがネイティブライブラリにアクセスすると、宣言されたネイティブライブラリの残りも読み込まれます。これにより、アクセスしたネイティブライブラリが別のネイティブライブラリに連動している場合に ​UnsatisfiedLinkError​ などのエラーを回避することができます。ライブラリは、​sharedLibraries​ 設定で連動関係の順序に従って宣言する必要があります。つまり、ライブラリ A がライブラリ B に連動する場合、A を最初に宣言する必要があります。ドメインでネイティブライブラリを宣言することもサポートされます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20230417

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11855052

mule.rethrowExceptionsInIdempotentMessageValidator

有効にすると、​idempotent-message-validator​ のイベントを処理する際に一般的な ​MULE:DUPLICATE_MESSAGE​ をスローするのではなく、内部例外が再スローされます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11529823

com.mulesoft.dw.xml_reader.honourMixedContentStructure

このプロパティが true に設定されている場合、DataWeave ではテキストを混在コンテンツと一緒に 1 つのテキスト項目にグループ化するのでなく、混在コンテンツ構造を保持します。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11071481

ENFORCE_ERROR_TYPES_VALIDATION

有効にすると、参照されていないエラーハンドラー/コンポーネントに対してもエラー種別検証が適用されます。 この機能はシステムプロパティで設定できません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10619787

disable.attribute.parameter.whitespace.trimming

有効にすると、Mule では DSL で属性レベルで定義されたパラメーター値から空白を切り取ります。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19803

disable.pojo.text.parameter.whitespace.trimming

有効にすると、Mule では DSL の POJO の CDATA テキストパラメーターから空白を切り取ります。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-20048

enforce.expression.validation

有効にすると、式検証が ​targetValue​ について適用され、リテラル値は許可されません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19987

enforce.dw.expression.validation

有効にすると、式検証がすべての DataWeave 式について適用されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19967

force.runtime.profiling.consumers.enablement

有効にした場合、Mule によって実装されたプロファイリングコンシューマーがデフォルトで有効になります。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202202

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19967

mule.disable.registryBootstrapOptionalEntries

有効にすると、​registry-bootstrap.properties​ のエントリの ​optional​ 属性が無視されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10736301

mule.disable.applyObjectProcessor

有効にすると、​SimpleRegistry​ に登録されるオブジェクトで ​org.mule.runtime.core.privileged.registry.ObjectProcessor​ の実装が適用されません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-11737

mule.deployment.validateAppModelWithRegionClassloader

有効にすると、アプリケーションモデルがリージョンクラスローダーを使用して検証されます。無効にすると、アプリケーションクラスローダーを使用して検証されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10808757

mule.suppress.mule.exceptions

有効にすると、エラー抑制が行われます。これにより、たとえば、Web Service Consumer Connector や、対応する名前空間 (MULE や WSC) から常にエラーを報告する Until Successful スコープに影響します。抑制されたエラーは根本原因として扱われます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202210

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

  • 4.4.0-202210

  • 4.3.0-202210

課題 ID​

  • W-11308645

mule.foreachRouterRejectsMapExpressions

有効にすると、コレクション式が ​java.util.Map​ に評価される場合、'foreach' ルーターによって ​IllegalArgumentException​ が生成されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-12207110

mule.honour.insecure.tls.configuration

有効にすると、TrustStore の項目が設定されている場合であっても、非セキュアな TLS 設定が尊重されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10822938

mule.transaction.sink.index

有効にすると、キーの一部としてインデックスを使用して不安定なシンクがキャッシュされます。シンクがすでに使用されている場合は新しいシンクが作成されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.0.0

  • 4.1.0

  • 4.2.0

  • 4.3.0

  • 4.4.0

  • 4.5.0

課題 ID​

  • W-12128703

mule.enable.policy.context.parallel.scopes

有効にすると、新しい (ソース) ポリシーコンテキストが並列スコープの実行用に作成されます: ParallelForeach、ScatterGather、Async。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202306

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-13509911

mule.disableJmx.for.commons.pool2

有効にすると、MBeans は ​commons-pool2​ に登録されません。

次のバージョン以降に使用可能​

  • 4.6.0

次のバージョン以降にデフォルトで有効化​

  • 4.6.0

課題 ID​

  • W-12422473
## [](#関連情報)関連情報 [システムプロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-app-properties-system) # 機能フラグのメカニズム Mule Runtime Engine には機能フラグのメカニズムが組み込まれています。これを使用すると、必要な最小の Mule バージョンに基づいて Mule アプリケーションで Mule インスタンスの動作を変更することができます。この機能では、Mule アプリケーションが以降の Mule Runtime バージョンで引き続き動作できるために後方互換性が確保されます。一方、新しい Mule アプリケーションは、Mule インスタンスに実装された最新のバグ修正を活用することができます。 機能フラグのメカニズムは自動です。Mule インスタンスにデプロイされた Mule アプリケーションごとに、Mule は、Mule アプリケーションのアプリケーション記述子ファイル (​`mule-artifact.json`​) に設定されたアプリケーションの最小 Mule バージョンに基づいて有効または無効な機能を判断します。 デフォルトでは、以前の Mule バージョンで実行されている Mule アプリケーションとの後方互換性のない新機能またはバグ修正は Mule Runtime Engine によって無効化されます。ただし、各 Mule アプリケーション、または同じ Mule インスタンスで実行されるすべてのアプリケーションに設定される機能フラグを管理することができます。 ## [](#mule-アプリケーションの機能フラグの設定)Mule アプリケーションの機能フラグの設定 Mule アプリケーションの機能フラグを設定するには、アプリケーションの ​`mule-artifact.json`​ ファイルの ​`minMuleVersion`​ 値を変更します。この設定では、この特定のバージョンにリリースされたすべての機能とバグ修正を実装し、以降の Mule バージョンでデフォルトでアクティブになっている機能とバグ修正を無効化して、このアプリケーションを実行するように Mule インスタンスに指示します。 たとえば、Mule 4.5.0 で Mule アプリケーションを実行し、Mule 4.1.0 までのコア機能を変更しない機能のみを適用するように Mule インスタンスに指示できます。 `mule-artifact.json`​ ファイルの例 { "minMuleVersion": "4.1.0" } ## [](#mule-インスタンスの機能フラグの設定)Mule インスタンスの機能フラグの設定 機能フラグを設定する代替方法として、システムプロパティを使用する方法があります。この場合、使用可能な各機能フラグを有効または無効にすることができます。ただし、システムプロパティを介して機能フラグを設定すると、変更が Mule インスタンスレベルで適用されるため、この Mule インスタンスにデプロイされたすべてのアプリケーションが、設定された機能フラグに従って動作します。 システムプロパティは他のデプロイメント対象では設定できないため、この設定はオンプレミスデプロイメントのみとの互換性があります。 たとえば、このインスタンスで実行されているすべてのアプリケーションで特定の機能を有効または無効にするように Mule 4.5.0 インスタンスを設定することができます。 `wrapper.conf`​ ファイルの例 … wrapper.java.additional.999=-DHONOUR\_RESERVED\_PROPERTIES\_PROPERTY=true wrapper.java.additional.1000=-DCOMPUTE\_CONNECTION\_ERRORS\_IN\_STATS\_PROPERTY=false ## [](#機能フラグリファレンス)機能フラグリファレンス 次の表に、使用可能な機能フラグ、機能フラグの機能の説明、機能フラグが使用可能になった Mule バージョン、機能フラグをデフォルトで有効化する以前のマイナーバージョンリリース、変更が実装された課題 ID を示します。
機能フラグ 説明

mule.batch.fixed.aggregator.transaction.record.buffer

有効にした場合、固定サイズのアグリゲーターを使用する Batch Aggregator は、完全なブロックが処理されたときにのみコミットされます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

  • 4.2.2-20210304

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19218

mule.compute.connection.errors.in.stats

有効にした場合、接続エラーがアラートトリガーの一環として計算されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19020

mule.enable.default.errorhandler.not.rollback.incorrect.tx

有効にした場合、Runtime が追加したデフォルトのエラーハンドラーは、トランザクションが応答せずにロールバックが必要になっても、トランザクションをロールバックしません。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20211227

  • 4.3.0-20211222

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19919

mule.dw.remove_shadowed_implicit_inputs

有効にした場合、DataWeave は、ルートレベルで宣言されている名前と同じ名前の暗黙的な入力を削除します。

次のバージョン以降に使用可能​

  • 4.4.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-893

mule.enable.byteBuddy.objectCreation

有効にした場合、オブジェクトのファクトリーが CGLIB ではなく Byte Buddy で作成されます。

次のバージョン以降に使用可能​

  • 4.4.0-20220321

  • 4.3.0-20220321

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • W-10672687

mule.enable.policy.isolation

有効にした場合、Mule は、ポリシーによってインポートされた拡張機能を、Mule アプリケーションによってインポートされた拡張機能とは完全に切り離して管理します。また、ポリシーの初期化の一環としてアプリケーションで宣言された明示的な設定の使用が検証により回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19226

mule.enable.profiling.service

有効にした場合、Runtime プロファイリング機能が使用できるようになります。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19588

mule.entityResolver.failOnFirstError

有効にした場合、配置できないスキーマを宣言しているアプリケーションをデプロイすると、Mule XML DSL パーサーが失敗します。それ以外の場合、このようなスキーマのバインド先の名前空間もアプリケーションで使用していると、パーサーは失敗します。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • EE-7827

mule.force.runtime.profiling.consumers.enablement

有効にした場合、Runtime によって実装されたプロファイリングコンシューマーがデフォルトで有効になります。

次のバージョン以降に使用可能​

  • 4.4.0-20220221

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19967

mule.dw.handle_splitter_exception

有効にした場合、DataWeave で内部例外を適切に処理しながらペイロードを分割するため、以降のシリアル化エラーが回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-383

mule.honour.reserved.properties

有効にした場合、​app.name​ などの予約されたプロパティをグローバルプロパティで上書きできなくなります (上書きは無視されます)。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

  • 4.3.0

課題 ID​

  • MULE-17659

mule.honourErrorMappingsWhenPolicyAppliedOnOperation

有効にした場合、操作ポリシーのエラー解決が無視されます。そのため、ポリシーが適用されるプロセッサーのエラーマッピングが正常に設定されます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220722

  • 4.3.0-20220725

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11147961

mule.detailedCompositeRoutingExceptionLog

有効にした場合、AbstractForkJoinRouter ベースのプロセッサー (例: Parallel For Each ルーターや Scatter-Gather ルーター) は、失敗したルートの詳細なエラー情報を表示します。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220622

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10965130

mule.parallelForeach.flattenMessage

有効にした場合、parallel-foreach スコープで反復処理する項目がメッセージ (結果オブジェクトを返す操作の出力など) であれば、foreach スコープと同じようにフラット化されます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220221

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-20067

mule.setVariable.WithNullValue

有効にした場合、変数の値が ​null​ であっても、Set Variable コンポーネントで変数が作成されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19443

mule.startExtensionComponentsWithArtifactClassloader

有効にした場合、拡張機能は、デプロイ可能なアーティファクト (アプリケーション、ポリシー、ドメイン) からエクスポートされたリソースのみを読み込むことができます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19815

mule.transformer.toString.transformIteratorElements

有効にした場合、文字列に変換される管理されたカーソルイテレーターには、汎用値 ​org.mule.runtime.core.internal.streaming.object.-ManagedCursorIteratorProvider$ManagedCursorIterator@​ ではなく要素の表現が表示されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19323

mule.suppress.mule.exceptions

有効にすると、エラー抑制が行われます。この機能により、Web Service Consumer Connector や Until Successful スコープなどのコンポーネントでその名前空間外のエラーが報告されなくなります。

Web Service Consumer での接続エラーのエラーログの抜粋の例 (HTTP:CONNECTIVITY が抑制されています):

Error type : WSC:INVALID_WSDL​
Caused by  : HTTP:CONNECTIVITY

抑制されたエラーは On Error ハンドラーでも照合できる根本原因として扱われます。

次のバージョン以降に使用可能​

  • 4.4.0-20220922

次のバージョン以降にデフォルトで有効化​

  • 4.4.0-20220922

課題 ID​

  • W-11778765

mule.errorTypes.lax

有効にすると、参照されないエラーハンドラー/コンポーネントに対してもエラー種別検証が適用されます。

次のバージョン以降に使用可能​

  • 4.4.0-20211227

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19879

mule.support.native.library.dependencies

有効にした場合、アプリケーションがネイティブライブラリにアクセスすると、宣言されたネイティブライブラリの残りも読み込まれます。これにより、アクセスしたネイティブライブラリが別のネイティブライブラリに連動している場合に ​UnsatisfiedLinkError​ などのエラーを回避することができます。ライブラリは、​sharedLibraries​ 設定で連動関係の順序に従って宣言する必要があります。つまり、ライブラリ A がライブラリ B に連動する場合、A を最初に宣言する必要があります。ドメインでネイティブライブラリを宣言することもサポートされます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20230417

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11855052

mule.rethrowExceptionsInIdempotentMessageValidator

有効にすると、​idempotent-message-validator​ のイベントを処理する際に一般的な ​MULE:DUPLICATE_MESSAGE​ をスローするのではなく、内部例外が再スローされます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11529823

com.mulesoft.dw.xml_reader.honourMixedContentStructure

このプロパティが true に設定されている場合、DataWeave ではテキストを混在コンテンツと一緒に 1 つのテキスト項目にグループ化するのでなく、混在コンテンツ構造を保持します。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11071481

ENFORCE_ERROR_TYPES_VALIDATION

有効にすると、参照されていないエラーハンドラー/コンポーネントに対してもエラー種別検証が適用されます。 この機能はシステムプロパティで設定できません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10619787

disable.attribute.parameter.whitespace.trimming

有効にすると、Mule では DSL で属性レベルで定義されたパラメーター値から空白を切り取ります。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19803

disable.pojo.text.parameter.whitespace.trimming

有効にすると、Mule では DSL の POJO の CDATA テキストパラメーターから空白を切り取ります。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-20048

enforce.expression.validation

有効にすると、式検証が ​targetValue​ について適用され、リテラル値は許可されません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19987

enforce.dw.expression.validation

有効にすると、式検証がすべての DataWeave 式について適用されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19967

force.runtime.profiling.consumers.enablement

有効にした場合、Mule によって実装されたプロファイリングコンシューマーがデフォルトで有効になります。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202202

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19967

mule.disable.registryBootstrapOptionalEntries

有効にすると、​registry-bootstrap.properties​ のエントリの ​optional​ 属性が無視されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10736301

mule.disable.applyObjectProcessor

有効にすると、​SimpleRegistry​ に登録されるオブジェクトで ​org.mule.runtime.core.privileged.registry.ObjectProcessor​ の実装が適用されません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-11737

mule.deployment.validateAppModelWithRegionClassloader

有効にすると、アプリケーションモデルがリージョンクラスローダーを使用して検証されます。無効にすると、アプリケーションクラスローダーを使用して検証されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10808757

mule.suppress.mule.exceptions

有効にすると、エラー抑制が行われます。これにより、たとえば、Web Service Consumer Connector や、対応する名前空間 (MULE や WSC) から常にエラーを報告する Until Successful スコープに影響します。抑制されたエラーは根本原因として扱われます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202210

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

  • 4.4.0-202210

  • 4.3.0-202210

課題 ID​

  • W-11308645

mule.foreachRouterRejectsMapExpressions

有効にすると、コレクション式が ​java.util.Map​ に評価される場合、'foreach' ルーターによって ​IllegalArgumentException​ が生成されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-12207110

mule.honour.insecure.tls.configuration

有効にすると、TrustStore の項目が設定されている場合であっても、非セキュアな TLS 設定が尊重されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10822938

mule.transaction.sink.index

有効にすると、キーの一部としてインデックスを使用して不安定なシンクがキャッシュされます。シンクがすでに使用されている場合は新しいシンクが作成されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.0.0

  • 4.1.0

  • 4.2.0

  • 4.3.0

  • 4.4.0

  • 4.5.0

課題 ID​

  • W-12128703

mule.enable.policy.context.parallel.scopes

有効にすると、新しい (ソース) ポリシーコンテキストが並列スコープの実行用に作成されます: ParallelForeach、ScatterGather、Async。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202306

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-13509911

mule.disableJmx.for.commons.pool2

有効にすると、MBeans は ​commons-pool2​ に登録されません。

次のバージョン以降に使用可能​

  • 4.6.0

次のバージョン以降にデフォルトで有効化​

  • 4.6.0

課題 ID​

  • W-12422473

mule.disable.scheduler.logging

有効にすると、スケジューラーで例外が記録されません。

次のバージョン以降に使用可能​

  • 4.6.0

  • 4.5.1

  • 4.4.0-20231026

次のバージョン以降にデフォルトで有効化​

  • 4.6.0

課題 ID​

  • W-13881167

mule.forkJoin.completeChildContextsOnTimeout

有効になっていると、タイムアウトが発生したときに、フォークおよび結合作業を実行するプロセッサー (現時点では、Scatter-Gather ルーターと Parallel For Each ルーター) が子イベントコンテキストを完了します。

次のバージョン以降に使用可能​

  • 4.6.14

  • 4.4.0-20250217

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • W-16941297
## [](#関連情報)関連情報 [システムプロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-app-properties-system) # 機能フラグのメカニズム Mule Runtime Engine には機能フラグのメカニズムが組み込まれています。これを使用すると、必要な最小の Mule バージョンに基づいて Mule アプリケーションで Mule インスタンスの動作を変更することができます。この機能では、Mule アプリケーションが以降の Mule Runtime バージョンで引き続き動作できるために後方互換性が確保されます。一方、新しい Mule アプリケーションは、Mule インスタンスに実装された最新のバグ修正を活用することができます。 機能フラグのメカニズムは自動です。Mule インスタンスにデプロイされた Mule アプリケーションごとに、Mule は、Mule アプリケーションのアプリケーション記述子ファイル (​`mule-artifact.json`​) に設定されたアプリケーションの最小 Mule バージョンに基づいて有効または無効な機能を判断します。 デフォルトでは、以前の Mule バージョンで実行されている Mule アプリケーションとの後方互換性のない新機能またはバグ修正は Mule Runtime Engine によって無効化されます。ただし、各 Mule アプリケーション、または同じ Mule インスタンスで実行されるすべてのアプリケーションに設定される機能フラグを管理することができます。 ## [](#mule-アプリケーションの機能フラグの設定)Mule アプリケーションの機能フラグの設定 Mule アプリケーションの機能フラグを設定するには、アプリケーションの ​`mule-artifact.json`​ ファイルの ​`minMuleVersion`​ 値を変更します。この設定では、この特定のバージョンにリリースされたすべての機能とバグ修正を実装し、以降の Mule バージョンでデフォルトでアクティブになっている機能とバグ修正を無効化して、このアプリケーションを実行するように Mule インスタンスに指示します。 たとえば、Mule 4.5.0 で Mule アプリケーションを実行し、Mule 4.1.0 までのコア機能を変更しない機能のみを適用するように Mule インスタンスに指示できます。 `mule-artifact.json`​ ファイルの例 { "minMuleVersion": "4.1.0" } ## [](#mule-インスタンスの機能フラグの設定)Mule インスタンスの機能フラグの設定 機能フラグを設定する代替方法として、システムプロパティを使用する方法があります。この場合、使用可能な各機能フラグを有効または無効にすることができます。ただし、システムプロパティを介して機能フラグを設定すると、変更が Mule インスタンスレベルで適用されるため、この Mule インスタンスにデプロイされたすべてのアプリケーションが、設定された機能フラグに従って動作します。 システムプロパティは他のデプロイメント対象では設定できないため、この設定はオンプレミスデプロイメントのみとの互換性があります。 たとえば、このインスタンスで実行されているすべてのアプリケーションで特定の機能を有効または無効にするように Mule 4.5.0 インスタンスを設定することができます。 `wrapper.conf`​ ファイルの例 … wrapper.java.additional.999=-DHONOUR\_RESERVED\_PROPERTIES\_PROPERTY=true wrapper.java.additional.1000=-DCOMPUTE\_CONNECTION\_ERRORS\_IN\_STATS\_PROPERTY=false ## [](#機能フラグリファレンス)機能フラグリファレンス 次の表に、使用可能な機能フラグ、機能フラグの機能の説明、機能フラグが使用可能になった Mule バージョン、機能フラグをデフォルトで有効化する以前のマイナーバージョンリリース、変更が実装された課題 ID を示します。
機能フラグ 説明

mule.batch.fixed.aggregator.transaction.record.buffer

有効にした場合、固定サイズのアグリゲーターを使用する Batch Aggregator は、完全なブロックが処理されたときにのみコミットされます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

  • 4.2.2-20210304

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19218

mule.compute.connection.errors.in.stats

有効にした場合、接続エラーがアラートトリガーの一環として計算されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19020

mule.enable.default.errorhandler.not.rollback.incorrect.tx

有効にした場合、Runtime が追加したデフォルトのエラーハンドラーは、トランザクションが応答せずにロールバックが必要になっても、トランザクションをロールバックしません。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20211227

  • 4.3.0-20211222

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19919

mule.dw.remove_shadowed_implicit_inputs

有効にした場合、DataWeave は、ルートレベルで宣言されている名前と同じ名前の暗黙的な入力を削除します。

次のバージョン以降に使用可能​

  • 4.4.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-893

mule.enable.byteBuddy.objectCreation

有効にした場合、オブジェクトのファクトリーが CGLIB ではなく Byte Buddy で作成されます。

次のバージョン以降に使用可能​

  • 4.4.0-20220321

  • 4.3.0-20220321

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • W-10672687

mule.enable.policy.isolation

有効にした場合、Mule は、ポリシーによってインポートされた拡張機能を、Mule アプリケーションによってインポートされた拡張機能とは完全に切り離して管理します。また、ポリシーの初期化の一環としてアプリケーションで宣言された明示的な設定の使用が検証により回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19226

mule.enable.profiling.service

有効にした場合、Runtime プロファイリング機能が使用できるようになります。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19588

mule.entityResolver.failOnFirstError

有効にした場合、配置できないスキーマを宣言しているアプリケーションをデプロイすると、Mule XML DSL パーサーが失敗します。それ以外の場合、このようなスキーマのバインド先の名前空間もアプリケーションで使用していると、パーサーは失敗します。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • EE-7827

mule.force.runtime.profiling.consumers.enablement

有効にした場合、Runtime によって実装されたプロファイリングコンシューマーがデフォルトで有効になります。

次のバージョン以降に使用可能​

  • 4.4.0-20220221

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19967

mule.dw.handle_splitter_exception

有効にした場合、DataWeave で内部例外を適切に処理しながらペイロードを分割するため、以降のシリアル化エラーが回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-383

mule.honour.reserved.properties

有効にした場合、​app.name​ などの予約されたプロパティをグローバルプロパティで上書きできなくなります (上書きは無視されます)。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

  • 4.3.0

課題 ID​

  • MULE-17659

mule.honourErrorMappingsWhenPolicyAppliedOnOperation

有効にした場合、操作ポリシーのエラー解決が無視されます。そのため、ポリシーが適用されるプロセッサーのエラーマッピングが正常に設定されます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220722

  • 4.3.0-20220725

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11147961

mule.detailedCompositeRoutingExceptionLog

有効にした場合、AbstractForkJoinRouter ベースのプロセッサー (例: Parallel For Each ルーターや Scatter-Gather ルーター) は、失敗したルートの詳細なエラー情報を表示します。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220622

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10965130

mule.parallelForeach.flattenMessage

有効にした場合、parallel-foreach スコープで反復処理する項目がメッセージ (結果オブジェクトを返す操作の出力など) であれば、foreach スコープと同じようにフラット化されます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220221

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-20067

mule.setVariable.WithNullValue

有効にした場合、変数の値が ​null​ であっても、Set Variable コンポーネントで変数が作成されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19443

mule.startExtensionComponentsWithArtifactClassloader

有効にした場合、拡張機能は、デプロイ可能なアーティファクト (アプリケーション、ポリシー、ドメイン) からエクスポートされたリソースのみを読み込むことができます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19815

mule.transformer.toString.transformIteratorElements

有効にした場合、文字列に変換される管理されたカーソルイテレーターには、汎用値 ​org.mule.runtime.core.internal.streaming.object.-ManagedCursorIteratorProvider$ManagedCursorIterator@​ ではなく要素の表現が表示されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19323

mule.suppress.mule.exceptions

有効にすると、エラー抑制が行われます。この機能により、Web Service Consumer Connector や Until Successful スコープなどのコンポーネントでその名前空間外のエラーが報告されなくなります。

Web Service Consumer での接続エラーのエラーログの抜粋の例 (HTTP:CONNECTIVITY が抑制されています):

Error type : WSC:INVALID_WSDL​
Caused by  : HTTP:CONNECTIVITY

抑制されたエラーは On Error ハンドラーでも照合できる根本原因として扱われます。

次のバージョン以降に使用可能​

  • 4.4.0-20220922

次のバージョン以降にデフォルトで有効化​

  • 4.4.0-20220922

課題 ID​

  • W-11778765

mule.errorTypes.lax

有効にすると、参照されないエラーハンドラー/コンポーネントに対してもエラー種別検証が適用されます。

次のバージョン以降に使用可能​

  • 4.4.0-20211227

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19879

mule.support.native.library.dependencies

有効にした場合、アプリケーションがネイティブライブラリにアクセスすると、宣言されたネイティブライブラリの残りも読み込まれます。これにより、アクセスしたネイティブライブラリが別のネイティブライブラリに連動している場合に ​UnsatisfiedLinkError​ などのエラーを回避することができます。ライブラリは、​sharedLibraries​ 設定で連動関係の順序に従って宣言する必要があります。つまり、ライブラリ A がライブラリ B に連動する場合、A を最初に宣言する必要があります。ドメインでネイティブライブラリを宣言することもサポートされます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20230417

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11855052

mule.rethrowExceptionsInIdempotentMessageValidator

有効にすると、​idempotent-message-validator​ のイベントを処理する際に一般的な ​MULE:DUPLICATE_MESSAGE​ をスローするのではなく、内部例外が再スローされます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11529823

com.mulesoft.dw.xml_reader.honourMixedContentStructure

このプロパティが true に設定されている場合、DataWeave ではテキストを混在コンテンツと一緒に 1 つのテキスト項目にグループ化するのでなく、混在コンテンツ構造を保持します。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11071481

ENFORCE_ERROR_TYPES_VALIDATION

有効にすると、参照されていないエラーハンドラー/コンポーネントに対してもエラー種別検証が適用されます。 この機能はシステムプロパティで設定できません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10619787

disable.attribute.parameter.whitespace.trimming

有効にすると、Mule では DSL で属性レベルで定義されたパラメーター値から空白を切り取ります。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19803

disable.pojo.text.parameter.whitespace.trimming

有効にすると、Mule では DSL の POJO の CDATA テキストパラメーターから空白を切り取ります。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-20048

enforce.expression.validation

有効にすると、式検証が ​targetValue​ について適用され、リテラル値は許可されません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19987

enforce.dw.expression.validation

有効にすると、式検証がすべての DataWeave 式について適用されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19967

force.runtime.profiling.consumers.enablement

有効にした場合、Mule によって実装されたプロファイリングコンシューマーがデフォルトで有効になります。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202202

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19967

mule.disable.registryBootstrapOptionalEntries

有効にすると、​registry-bootstrap.properties​ のエントリの ​optional​ 属性が無視されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10736301

mule.disable.applyObjectProcessor

有効にすると、​SimpleRegistry​ に登録されるオブジェクトで ​org.mule.runtime.core.privileged.registry.ObjectProcessor​ の実装が適用されません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-11737

mule.deployment.validateAppModelWithRegionClassloader

有効にすると、アプリケーションモデルがリージョンクラスローダーを使用して検証されます。無効にすると、アプリケーションクラスローダーを使用して検証されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10808757

mule.suppress.mule.exceptions

有効にすると、エラー抑制が行われます。これにより、たとえば、Web Service Consumer Connector や、対応する名前空間 (MULE や WSC) から常にエラーを報告する Until Successful スコープに影響します。抑制されたエラーは根本原因として扱われます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202210

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

  • 4.4.0-202210

  • 4.3.0-202210

課題 ID​

  • W-11308645

mule.foreachRouterRejectsMapExpressions

有効にすると、コレクション式が ​java.util.Map​ に評価される場合、'foreach' ルーターによって ​IllegalArgumentException​ が生成されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-12207110

mule.honour.insecure.tls.configuration

有効にすると、TrustStore の項目が設定されている場合であっても、非セキュアな TLS 設定が尊重されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10822938

mule.transaction.sink.index

有効にすると、キーの一部としてインデックスを使用して不安定なシンクがキャッシュされます。シンクがすでに使用されている場合は新しいシンクが作成されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.0.0

  • 4.1.0

  • 4.2.0

  • 4.3.0

  • 4.4.0

  • 4.5.0

課題 ID​

  • W-12128703

mule.enable.policy.context.parallel.scopes

有効にすると、新しい (ソース) ポリシーコンテキストが並列スコープの実行用に作成されます: ParallelForeach、ScatterGather、Async。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202306

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-13509911

mule.disableJmx.for.commons.pool2

有効にすると、MBeans は ​commons-pool2​ に登録されません。

次のバージョン以降に使用可能​

  • 4.6.0

次のバージョン以降にデフォルトで有効化​

  • 4.6.0

課題 ID​

  • W-12422473

mule.disable.scheduler.logging

有効にすると、スケジューラーで例外が記録されません。

次のバージョン以降に使用可能​

  • 4.6.0

  • 4.5.1

  • 4.4.0-20231026

次のバージョン以降にデフォルトで有効化​

  • 4.6.0

課題 ID​

  • W-13881167
## [](#関連情報)関連情報 [システムプロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-app-properties-system) # 機能フラグのメカニズム Mule Runtime Engine には機能フラグのメカニズムが組み込まれています。これを使用すると、必要な最小の Mule バージョンに基づいて Mule アプリケーションで Mule インスタンスの動作を変更することができます。この機能では、Mule アプリケーションが以降の Mule Runtime バージョンで引き続き動作できるために後方互換性が確保されます。一方、新しい Mule アプリケーションは、Mule インスタンスに実装された最新のバグ修正を活用することができます。 機能フラグのメカニズムは自動です。Mule インスタンスにデプロイされた Mule アプリケーションごとに、Mule は、Mule アプリケーションのアプリケーション記述子ファイル (​`mule-artifact.json`​) に設定されたアプリケーションの最小 Mule バージョンに基づいて有効または無効な機能を判断します。 デフォルトでは、以前の Mule バージョンで実行されている Mule アプリケーションとの後方互換性のない新機能またはバグ修正は Mule Runtime Engine によって無効化されます。ただし、各 Mule アプリケーション、または同じ Mule インスタンスで実行されるすべてのアプリケーションに設定される機能フラグを管理することができます。 ## [](#mule-アプリケーションの機能フラグの設定)Mule アプリケーションの機能フラグの設定 Mule アプリケーションの機能フラグを設定するには、アプリケーションの ​`mule-artifact.json`​ ファイルの ​`minMuleVersion`​ 値を変更します。この設定では、この特定のバージョンにリリースされたすべての機能とバグ修正を実装し、以降の Mule バージョンでデフォルトでアクティブになっている機能とバグ修正を無効化して、このアプリケーションを実行するように Mule インスタンスに指示します。 たとえば、Mule 4.5.0 で Mule アプリケーションを実行し、Mule 4.1.0 までのコア機能を変更しない機能のみを適用するように Mule インスタンスに指示できます。 `mule-artifact.json`​ ファイルの例 { "minMuleVersion": "4.1.0" } ## [](#mule-インスタンスの機能フラグの設定)Mule インスタンスの機能フラグの設定 機能フラグを設定する代替方法として、システムプロパティを使用する方法があります。この場合、使用可能な各機能フラグを有効または無効にすることができます。ただし、システムプロパティを介して機能フラグを設定すると、変更が Mule インスタンスレベルで適用されるため、この Mule インスタンスにデプロイされたすべてのアプリケーションが、設定された機能フラグに従って動作します。 システムプロパティは他のデプロイメント対象では設定できないため、この設定はオンプレミスデプロイメントのみとの互換性があります。 たとえば、このインスタンスで実行されているすべてのアプリケーションで特定の機能を有効または無効にするように Mule 4.5.0 インスタンスを設定することができます。 `wrapper.conf`​ ファイルの例 … wrapper.java.additional.999=-DHONOUR\_RESERVED\_PROPERTIES\_PROPERTY=true wrapper.java.additional.1000=-DCOMPUTE\_CONNECTION\_ERRORS\_IN\_STATS\_PROPERTY=false ## [](#機能フラグリファレンス)機能フラグリファレンス 次の表に、使用可能な機能フラグ、機能フラグの機能の説明、機能フラグが使用可能になった Mule バージョン、機能フラグをデフォルトで有効化する以前のマイナーバージョンリリース、変更が実装された課題 ID を示します。
機能フラグ 説明

mule.batch.fixed.aggregator.transaction.record.buffer

有効にした場合、固定サイズのアグリゲーターを使用する Batch Aggregator は、完全なブロックが処理されたときにのみコミットされます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

  • 4.2.2-20210304

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19218

mule.compute.connection.errors.in.stats

有効にした場合、接続エラーがアラートトリガーの一環として計算されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19020

mule.enable.default.errorhandler.not.rollback.incorrect.tx

有効にした場合、Runtime が追加したデフォルトのエラーハンドラーは、トランザクションが応答せずにロールバックが必要になっても、トランザクションをロールバックしません。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20211227

  • 4.3.0-20211222

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

  • 4.4.1

  • 4.3.1

課題 ID​

  • MULE-19919

mule.dw.remove_shadowed_implicit_inputs

有効にした場合、DataWeave は、ルートレベルで宣言されている名前と同じ名前の暗黙的な入力を削除します。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-893

mule.enable.policy.isolation

有効にした場合、Mule は、ポリシーによってインポートされた拡張機能を、Mule アプリケーションによってインポートされた拡張機能とは完全に切り離して管理します。また、ポリシーの初期化の一環としてアプリケーションで宣言された明示的な設定の使用が検証により回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19226

mule.enable.profiling.service

有効にした場合、Runtime プロファイリング機能が使用できるようになります。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19588

mule.entityResolver.failOnFirstError

有効にした場合、配置できないスキーマを宣言しているアプリケーションをデプロイすると、Mule XML DSL パーサーが失敗します。それ以外の場合、このようなスキーマのバインド先の名前空間もアプリケーションで使用していると、パーサーは失敗します。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • EE-7827

mule.force.runtime.profiling.consumers.enablement

有効にした場合、Runtime によって実装されたプロファイリングコンシューマーがデフォルトで有効になります。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220221

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19967

mule.dw.handle_splitter_exception

有効にした場合、DataWeave で内部例外を適切に処理しながらペイロードを分割するため、以降のシリアル化エラーが回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-383

mule.honour.reserved.properties

有効にした場合、​app.name​ などの予約されたプロパティをグローバルプロパティで上書きできなくなります (上書きは無視されます)。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

  • 4.3.0

課題 ID​

  • MULE-17659

mule.honourErrorMappingsWhenPolicyAppliedOnOperation

有効にした場合、操作ポリシーのエラー解決が無視されます。そのため、ポリシーが適用されるプロセッサーのエラーマッピングが正常に設定されます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220722

  • 4.3.0-20220725

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11147961

mule.detailedCompositeRoutingExceptionLog

有効にした場合、AbstractForkJoinRouter ベースのプロセッサー (例: Parallel For Each ルーターや Scatter-Gather ルーター) は、失敗したルートの詳細なエラー情報を表示します。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220622

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10965130

mule.parallelForeach.flattenMessage

有効にした場合、parallel-foreach スコープで反復処理する項目がメッセージ (結果オブジェクトを返す操作の出力など) であれば、foreach スコープと同じようにフラット化されます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220221

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-20067

mule.setVariable.WithNullValue

有効にした場合、変数の値が ​null​ であっても、Set Variable コンポーネントで変数が作成されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19443

mule.startExtensionComponentsWithArtifactClassloader

有効にした場合、拡張機能は、デプロイ可能なアーティファクト (アプリケーション、ポリシー、ドメイン) からエクスポートされたリソースのみを読み込むことができます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19815

mule.transformer.toString.transformIteratorElements

有効にした場合、文字列に変換される管理されたカーソルイテレーターには、汎用値 ​org.mule.runtime.core.internal.streaming.object.-ManagedCursorIteratorProvider$ManagedCursorIterator@​ ではなく要素の表現が表示されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19323

mule.suppress.mule.exceptions

有効にすると、エラー抑制が行われます。この機能により、Web Service Consumer Connector や Until Successful スコープなどのコンポーネントでその名前空間外のエラーが報告されなくなります。

Web Service Consumer での接続エラーのエラーログの抜粋の例 (HTTP:CONNECTIVITY が抑制されています):

Error type : WSC:INVALID_WSDL​
Caused by  : HTTP:CONNECTIVITY

抑制されたエラーは On Error ハンドラーでも照合できる根本原因として扱われます。

次のバージョン以降に使用可能​

  • 4.4.0-20220922

次のバージョン以降にデフォルトで有効化​

  • 4.4.0-20220922

課題 ID​

  • W-11778765

mule.errorTypes.lax

有効にすると、参照されないエラーハンドラー/コンポーネントに対してもエラー種別検証が適用されます。

次のバージョン以降に使用可能​

  • 4.4.0-20211227

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19879

mule.support.native.library.dependencies

有効にした場合、アプリケーションがネイティブライブラリにアクセスすると、宣言されたネイティブライブラリの残りも読み込まれます。これにより、アクセスしたネイティブライブラリが別のネイティブライブラリに連動している場合に ​UnsatisfiedLinkError​ などのエラーを回避することができます。ライブラリは、​sharedLibraries​ 設定で連動関係の順序に従って宣言する必要があります。つまり、ライブラリ A がライブラリ B に連動する場合、A を最初に宣言する必要があります。ドメインでネイティブライブラリを宣言することもサポートされます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20230417

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11855052

mule.rethrowExceptionsInIdempotentMessageValidator

有効にすると、​idempotent-message-validator​ のイベントを処理する際に一般的な ​MULE:DUPLICATE_MESSAGE​ をスローするのではなく、内部例外が再スローされます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11529823

com.mulesoft.dw.xml_reader.honourMixedContentStructure

このプロパティが true に設定されている場合、DataWeave ではテキストを混在コンテンツと一緒に 1 つのテキスト項目にグループ化するのでなく、混在コンテンツ構造を保持します。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11071481

ENFORCE_ERROR_TYPES_VALIDATION

有効にすると、参照されていないエラーハンドラー/コンポーネントに対してもエラー種別検証が適用されます。 この機能はシステムプロパティで設定できません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10619787

disable.attribute.parameter.whitespace.trimming

有効にすると、Mule では DSL で属性レベルで定義されたパラメーター値から空白を切り取ります。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19803

disable.pojo.text.parameter.whitespace.trimming

有効にすると、Mule では DSL の POJO の CDATA テキストパラメーターから空白を切り取ります。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-20048

enforce.expression.validation

有効にすると、式検証が ​targetValue​ について適用され、リテラル値は許可されません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19987

enforce.dw.expression.validation

有効にすると、式検証がすべての DataWeave 式について適用されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19967

force.runtime.profiling.consumers.enablement

有効にした場合、Mule によって実装されたプロファイリングコンシューマーがデフォルトで有効になります。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202202

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19967

mule.disable.registryBootstrapOptionalEntries

有効にすると、​registry-bootstrap.properties​ のエントリの ​optional​ 属性が無視されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10736301

mule.disable.applyObjectProcessor

有効にすると、​SimpleRegistry​ に登録されるオブジェクトで ​org.mule.runtime.core.privileged.registry.ObjectProcessor​ の実装が適用されません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-11737

mule.deployment.validateAppModelWithRegionClassloader

有効にすると、アプリケーションモデルがリージョンクラスローダーを使用して検証されます。無効にすると、アプリケーションクラスローダーを使用して検証されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10808757

mule.suppress.mule.exceptions

有効にすると、エラー抑制が行われます。これにより、たとえば、Web Service Consumer Connector や、対応する名前空間 (MULE や WSC) から常にエラーを報告する Until Successful スコープに影響します。抑制されたエラーは根本原因として扱われます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202210

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

  • 4.4.0-202210

  • 4.3.0-202210

課題 ID​

  • W-11308645

mule.foreachRouterRejectsMapExpressions

有効にすると、コレクション式が ​java.util.Map​ に評価される場合、'foreach' ルーターによって ​IllegalArgumentException​ が生成されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-12207110

mule.honour.insecure.tls.configuration

有効にすると、TrustStore の項目が設定されている場合であっても、非セキュアな TLS 設定が尊重されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10822938

mule.transaction.sink.index

有効にすると、キーの一部としてインデックスを使用して不安定なシンクがキャッシュされます。シンクがすでに使用されている場合は新しいシンクが作成されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

  • 4.4.0

  • 4.3.0

  • 4.2.0

  • 4.1.0

  • 4.0.0

課題 ID​

  • W-12128703

mule.enable.policy.context.parallel.scopes

有効にすると、新しい (ソース) ポリシーコンテキストが並列スコープの実行用に作成されます: ParallelForeach、ScatterGather、Async。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202306

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-13509911

mule.put.trace.id.and.span.id.in.mdc

有効にすると、トレース ID とスパン ID が MDC に追加されます (使用可能な場合)。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-12979787

mule.enable.mule.specific.tracing.information

有効にすると、スパンが伝播されるときに ​ancestor-mule-span-id​ 値がトレース状態に追加されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • W-13215870

mule.disableJmx.for.commons.pool2

有効にすると、MBeans は ​commons-pool2​ に登録されません。

次のバージョン以降に使用可能​

  • 4.6.0

次のバージョン以降にデフォルトで有効化​

  • 4.6.0

課題 ID​

  • W-12422473

mule.disable.scheduler.logging

有効にすると、スケジューラーで例外が記録されません。

次のバージョン以降に使用可能​

  • 4.6.0

次のバージョン以降にデフォルトで有効化​

  • 4.6.0

課題 ID​

  • W-13881167

mule.tx.error.when.timeout

有効にすると、ローカルまたは XA トランザクションがタイムアウトに達したときにエラーがスローされます。このエラーはエラー処理を使用して処理できます。

次のバージョン以降に使用可能​

  • 4.6.1

次のバージョン以降にデフォルトで有効化​

  • 4.6.1

課題 ID​

  • W-14608096

mule.disableXmlSdkImplicitConfigurationCreation

有効にすると、XML SDK の暗黙的な設定が作成されなくなります。

次のバージョン以降に使用可能​

  • 4.7.0

次のバージョン以降にデフォルトで有効化​

  • 4.7.0

課題 ID​

  • W-10634129

mule.enable.xml.sdk.mdc.reset

有効にすると、XML SDK 操作の実行時に MDC コンテキストがリセットされます。

次のバージョン以降に使用可能​

  • 4.8.0

  • 4.7.1

  • 4.6.4

  • 4.4.0-20240522

次のバージョン以降にデフォルトで有効化​

  • 4.8.0

課題 ID​

  • W-15206528

mule.unsupportedExtensionsClientRunAsync

有効にすると、​org.mule.runtime.extension.api.client.ExtensionsClient​ 非推奨メソッド ​(executeAsync(String, String, OperationParameters)​ および ​execute(String, String, OperationParameters))​ で ​UnsupportedOperationException​ がスローされます。

次のバージョン以降に使用可能​

  • 1.8.0

次のバージョン以降にデフォルトで有効化​

  • 4.8.0

課題 ID​

  • W-15399821

ENFORCE_IMPORT_TARGET_SAME_TYPE

有効にすると、​インポート​対象のルート要素が設定のインポートと同じになることが検証されます。

次のバージョン以降に使用可能​

  • 4.8.0

次のバージョン以降にデフォルトで有効化​

  • 4.8.0

課題 ID​

  • W-15509819

mule.honour.persisted.flow.state

有効にすると、初期状態に関係なく、アプリケーションの再起動時に ​flows.deployment.properties​ で設定された状態がフローで考慮されます。

次のバージョン以降に使用可能​

  • 4.8.0

次のバージョン以降にデフォルトで有効化​

  • 4.8.0

課題 ID​

  • W-15750334
## [](#関連情報)関連情報 [システムプロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-app-properties-system) # 機能フラグのメカニズム Mule Runtime Engine には機能フラグのメカニズムが組み込まれています。これを使用すると、必要な最小の Mule バージョンに基づいて Mule アプリケーションで Mule インスタンスの動作を変更することができます。この機能では、Mule アプリケーションが以降の Mule Runtime バージョンで引き続き動作できるために後方互換性が確保されます。一方、新しい Mule アプリケーションは、Mule インスタンスに実装された最新のバグ修正を活用することができます。 機能フラグのメカニズムは自動です。Mule インスタンスにデプロイされた Mule アプリケーションごとに、Mule は、Mule アプリケーションのアプリケーション記述子ファイル (​`mule-artifact.json`​) に設定されたアプリケーションの最小 Mule バージョンに基づいて有効または無効な機能を判断します。 デフォルトでは、以前の Mule バージョンで実行されている Mule アプリケーションとの後方互換性のない新機能またはバグ修正は Mule Runtime Engine によって無効化されます。ただし、各 Mule アプリケーション、または同じ Mule インスタンスで実行されるすべてのアプリケーションに設定される機能フラグを管理することができます。 ## [](#mule-アプリケーションの機能フラグの設定)Mule アプリケーションの機能フラグの設定 Mule アプリケーションの機能フラグを設定するには、アプリケーションの ​`mule-artifact.json`​ ファイルの ​`minMuleVersion`​ 値を変更します。この設定では、この特定のバージョンにリリースされたすべての機能とバグ修正を実装し、以降の Mule バージョンでデフォルトでアクティブになっている機能とバグ修正を無効化して、このアプリケーションを実行するように Mule インスタンスに指示します。 たとえば、Mule 4.5.0 で Mule アプリケーションを実行し、Mule 4.1.0 までのコア機能を変更しない機能のみを適用するように Mule インスタンスに指示できます。 `mule-artifact.json`​ ファイルの例 { "minMuleVersion": "4.1.0" } ## [](#mule-インスタンスの機能フラグの設定)Mule インスタンスの機能フラグの設定 機能フラグを設定する代替方法として、システムプロパティを使用する方法があります。この場合、使用可能な各機能フラグを有効または無効にすることができます。ただし、システムプロパティを介して機能フラグを設定すると、変更が Mule インスタンスレベルで適用されるため、この Mule インスタンスにデプロイされたすべてのアプリケーションが、設定された機能フラグに従って動作します。 システムプロパティは他のデプロイメント対象では設定できないため、この設定はオンプレミスデプロイメントのみとの互換性があります。 たとえば、このインスタンスで実行されているすべてのアプリケーションで特定の機能を有効または無効にするように Mule 4.5.0 インスタンスを設定することができます。 `wrapper.conf`​ ファイルの例 … wrapper.java.additional.999=-DHONOUR\_RESERVED\_PROPERTIES\_PROPERTY=true wrapper.java.additional.1000=-DCOMPUTE\_CONNECTION\_ERRORS\_IN\_STATS\_PROPERTY=false ## [](#機能フラグリファレンス)機能フラグリファレンス 次の表に、使用可能な機能フラグ、機能フラグの機能の説明、機能フラグが使用可能になった Mule バージョン、機能フラグをデフォルトで有効化する以前のマイナーバージョンリリース、変更が実装された課題 ID を示します。
機能フラグ 説明

mule.batch.fixed.aggregator.transaction.record.buffer

有効にした場合、固定サイズのアグリゲーターを使用する Batch Aggregator は、完全なブロックが処理されたときにのみコミットされます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

  • 4.2.2-20210304

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19218

mule.compute.connection.errors.in.stats

有効にした場合、接続エラーがアラートトリガーの一環として計算されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210304

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19020

mule.enable.default.errorhandler.not.rollback.incorrect.tx

有効にした場合、Runtime が追加したデフォルトのエラーハンドラーは、トランザクションが応答せずにロールバックが必要になっても、トランザクションをロールバックしません。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20211227

  • 4.3.0-20211222

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

  • 4.4.1

  • 4.3.1

課題 ID​

  • MULE-19919

mule.dw.remove_shadowed_implicit_inputs

有効にした場合、DataWeave は、ルートレベルで宣言されている名前と同じ名前の暗黙的な入力を削除します。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-893

mule.enable.policy.isolation

有効にした場合、Mule は、ポリシーによってインポートされた拡張機能を、Mule アプリケーションによってインポートされた拡張機能とは完全に切り離して管理します。また、ポリシーの初期化の一環としてアプリケーションで宣言された明示的な設定の使用が検証により回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19226

mule.enable.profiling.service

有効にした場合、Runtime プロファイリング機能が使用できるようになります。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19588

mule.entityResolver.failOnFirstError

有効にした場合、配置できないスキーマを宣言しているアプリケーションをデプロイすると、Mule XML DSL パーサーが失敗します。それ以外の場合、このようなスキーマのバインド先の名前空間もアプリケーションで使用していると、パーサーは失敗します。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • EE-7827

mule.force.runtime.profiling.consumers.enablement

有効にした場合、Runtime によって実装されたプロファイリングコンシューマーがデフォルトで有効になります。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220221

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • MULE-19967

mule.dw.handle_splitter_exception

有効にした場合、DataWeave で内部例外を適切に処理しながらペイロードを分割するため、以降のシリアル化エラーが回避されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • DW-383

mule.honour.reserved.properties

有効にした場合、​app.name​ などの予約されたプロパティをグローバルプロパティで上書きできなくなります (上書きは無視されます)。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

  • 4.3.0

課題 ID​

  • MULE-17659

mule.honourErrorMappingsWhenPolicyAppliedOnOperation

有効にした場合、操作ポリシーのエラー解決が無視されます。そのため、ポリシーが適用されるプロセッサーのエラーマッピングが正常に設定されます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220722

  • 4.3.0-20220725

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11147961

mule.detailedCompositeRoutingExceptionLog

有効にした場合、AbstractForkJoinRouter ベースのプロセッサー (例: Parallel For Each ルーターや Scatter-Gather ルーター) は、失敗したルートの詳細なエラー情報を表示します。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220622

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10965130

mule.parallelForeach.flattenMessage

有効にした場合、parallel-foreach スコープで反復処理する項目がメッセージ (結果オブジェクトを返す操作の出力など) であれば、foreach スコープと同じようにフラット化されます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20220221

  • 4.3.0-20220221

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-20067

mule.setVariable.WithNullValue

有効にした場合、変数の値が ​null​ であっても、Set Variable コンポーネントで変数が作成されます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20210622

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19443

mule.startExtensionComponentsWithArtifactClassloader

有効にした場合、拡張機能は、デプロイ可能なアーティファクト (アプリケーション、ポリシー、ドメイン) からエクスポートされたリソースのみを読み込むことができます。

次のバージョン以降に使用可能​

  • 4.4.0

  • 4.3.0-20211026

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19815

mule.transformer.toString.transformIteratorElements

有効にした場合、文字列に変換される管理されたカーソルイテレーターには、汎用値 ​org.mule.runtime.core.internal.streaming.object.-ManagedCursorIteratorProvider$ManagedCursorIterator@​ ではなく要素の表現が表示されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.4.0

課題 ID​

  • MULE-19323

mule.suppress.mule.exceptions

有効にすると、エラー抑制が行われます。この機能により、Web Service Consumer Connector や Until Successful スコープなどのコンポーネントでその名前空間外のエラーが報告されなくなります。

Web Service Consumer での接続エラーのエラーログの抜粋の例 (HTTP:CONNECTIVITY が抑制されています):

Error type : WSC:INVALID_WSDL​
Caused by  : HTTP:CONNECTIVITY

抑制されたエラーは On Error ハンドラーでも照合できる根本原因として扱われます。

次のバージョン以降に使用可能​

  • 4.4.0-20220922

次のバージョン以降にデフォルトで有効化​

  • 4.4.0-20220922

課題 ID​

  • W-11778765

mule.errorTypes.lax

有効にすると、参照されないエラーハンドラー/コンポーネントに対してもエラー種別検証が適用されます。

次のバージョン以降に使用可能​

  • 4.4.0-20211227

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません。

課題 ID​

  • MULE-19879

mule.support.native.library.dependencies

有効にした場合、アプリケーションがネイティブライブラリにアクセスすると、宣言されたネイティブライブラリの残りも読み込まれます。これにより、アクセスしたネイティブライブラリが別のネイティブライブラリに連動している場合に ​UnsatisfiedLinkError​ などのエラーを回避することができます。ライブラリは、​sharedLibraries​ 設定で連動関係の順序に従って宣言する必要があります。つまり、ライブラリ A がライブラリ B に連動する場合、A を最初に宣言する必要があります。ドメインでネイティブライブラリを宣言することもサポートされます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-20230417

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11855052

mule.rethrowExceptionsInIdempotentMessageValidator

有効にすると、​idempotent-message-validator​ のイベントを処理する際に一般的な ​MULE:DUPLICATE_MESSAGE​ をスローするのではなく、内部例外が再スローされます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11529823

com.mulesoft.dw.xml_reader.honourMixedContentStructure

このプロパティが true に設定されている場合、DataWeave ではテキストを混在コンテンツと一緒に 1 つのテキスト項目にグループ化するのでなく、混在コンテンツ構造を保持します。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-11071481

ENFORCE_ERROR_TYPES_VALIDATION

有効にすると、参照されていないエラーハンドラー/コンポーネントに対してもエラー種別検証が適用されます。 この機能はシステムプロパティで設定できません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10619787

disable.attribute.parameter.whitespace.trimming

有効にすると、Mule では DSL で属性レベルで定義されたパラメーター値から空白を切り取ります。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19803

disable.pojo.text.parameter.whitespace.trimming

有効にすると、Mule では DSL の POJO の CDATA テキストパラメーターから空白を切り取ります。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-20048

enforce.expression.validation

有効にすると、式検証が ​targetValue​ について適用され、リテラル値は許可されません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19987

enforce.dw.expression.validation

有効にすると、式検証がすべての DataWeave 式について適用されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19967

force.runtime.profiling.consumers.enablement

有効にした場合、Mule によって実装されたプロファイリングコンシューマーがデフォルトで有効になります。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202202

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-19967

mule.disable.registryBootstrapOptionalEntries

有効にすると、​registry-bootstrap.properties​ のエントリの ​optional​ 属性が無視されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

次のバージョン以降に非推奨​

  • 4.9.0

課題 ID​

  • W-10736301

mule.disable.applyObjectProcessor

有効にすると、​SimpleRegistry​ に登録されるオブジェクトで ​org.mule.runtime.core.privileged.registry.ObjectProcessor​ の実装が適用されません。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • MULE-11737

mule.deployment.validateAppModelWithRegionClassloader

有効にすると、アプリケーションモデルがリージョンクラスローダーを使用して検証されます。無効にすると、アプリケーションクラスローダーを使用して検証されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10808757

mule.suppress.mule.exceptions

有効にすると、エラー抑制が行われます。これにより、たとえば、Web Service Consumer Connector や、対応する名前空間 (MULE や WSC) から常にエラーを報告する Until Successful スコープに影響します。抑制されたエラーは根本原因として扱われます。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202210

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

  • 4.4.0-202210

  • 4.3.0-202210

課題 ID​

  • W-11308645

mule.foreachRouterRejectsMapExpressions

有効にすると、コレクション式が ​java.util.Map​ に評価される場合、'foreach' ルーターによって ​IllegalArgumentException​ が生成されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-12207110

mule.honour.insecure.tls.configuration

有効にすると、TrustStore の項目が設定されている場合であっても、非セキュアな TLS 設定が尊重されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-10822938

mule.transaction.sink.index

有効にすると、キーの一部としてインデックスを使用して不安定なシンクがキャッシュされます。シンクがすでに使用されている場合は新しいシンクが作成されます。

次のバージョン以降に使用可能​

  • 4.4.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

  • 4.4.0

  • 4.3.0

  • 4.2.0

  • 4.1.0

  • 4.0.0

課題 ID​

  • W-12128703

mule.enable.policy.context.parallel.scopes

有効にすると、新しい (ソース) ポリシーコンテキストが並列スコープの実行用に作成されます: ParallelForeach、ScatterGather、Async。

次のバージョン以降に使用可能​

  • 4.5.0

  • 4.4.0-202306

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-13509911

mule.put.trace.id.and.span.id.in.mdc

有効にすると、トレース ID とスパン ID が MDC に追加されます (使用可能な場合)。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • 4.5.0

課題 ID​

  • W-12979787

mule.enable.mule.specific.tracing.information

有効にすると、スパンが伝播されるときに ​ancestor-mule-span-id​ 値がトレース状態に追加されます。

次のバージョン以降に使用可能​

  • 4.5.0

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • W-13215870

mule.disableJmx.for.commons.pool2

有効にすると、MBeans は ​commons-pool2​ に登録されません。

次のバージョン以降に使用可能​

  • 4.6.0

次のバージョン以降にデフォルトで有効化​

  • 4.6.0

課題 ID​

  • W-12422473

mule.disable.scheduler.logging

有効にすると、スケジューラーで例外が記録されません。

次のバージョン以降に使用可能​

  • 4.6.0

次のバージョン以降にデフォルトで有効化​

  • 4.6.0

課題 ID​

  • W-13881167

mule.tx.error.when.timeout

有効にすると、ローカルまたは XA トランザクションがタイムアウトに達したときにエラーがスローされます。このエラーはエラー処理を使用して処理できます。

次のバージョン以降に使用可能​

  • 4.6.1

次のバージョン以降にデフォルトで有効化​

  • 4.6.1

課題 ID​

  • W-14608096

mule.disableXmlSdkImplicitConfigurationCreation

有効にすると、XML SDK の暗黙的な設定が作成されなくなります。

次のバージョン以降に使用可能​

  • 4.7.0

次のバージョン以降にデフォルトで有効化​

  • 4.7.0

課題 ID​

  • W-10634129

mule.enable.xml.sdk.mdc.reset

有効にすると、XML SDK 操作の実行時に MDC コンテキストがリセットされます。

次のバージョン以降に使用可能​

  • 4.8.0

  • 4.7.1

  • 4.6.4

  • 4.4.0-20240522

次のバージョン以降にデフォルトで有効化​

  • 4.8.0

課題 ID​

  • W-15206528

mule.unsupportedExtensionsClientRunAsync

有効にすると、​org.mule.runtime.extension.api.client.ExtensionsClient​ 非推奨メソッド ​(executeAsync(String, String, OperationParameters)​ および ​execute(String, String, OperationParameters))​ で ​UnsupportedOperationException​ がスローされます。

次のバージョン以降に使用可能​

  • 1.8.0

次のバージョン以降にデフォルトで有効化​

  • 4.8.0

課題 ID​

  • W-15399821

ENFORCE_IMPORT_TARGET_SAME_TYPE

有効にすると、​インポート​対象のルート要素が設定のインポートと同じになることが検証されます。

次のバージョン以降に使用可能​

  • 4.8.0

次のバージョン以降にデフォルトで有効化​

  • 4.8.0

課題 ID​

  • W-15509819

mule.honour.persisted.flow.state

有効にすると、初期状態に関係なく、アプリケーションの再起動時に ​flows.deployment.properties​ で設定された状態がフローで考慮されます。

次のバージョン以降に使用可能​

  • 4.8.0

次のバージョン以降にデフォルトで有効化​

  • 4.8.0

課題 ID​

  • W-15750334

mule.ntlm.avoid.send.payload.on.type1

有効にすると、NTLM 種別 1 要求では本文コンテンツが送信されません。これにより、コンシュームされないペイロードが送信されなくなる (ダンスが完了するまでサーバーでペイロードが拒否される) ため、リソースを節約できます。

次のバージョン以降に使用可能​

  • 4.9.0

  • 4.8.4

  • 4.6.12

次のバージョン以降にデフォルトで有効化​

  • 4.9.0

課題 ID​

  • W-17107281

mule.forkJoin.completeChildContextsOnTimeout

有効になっていると、タイムアウトが発生したときに、フォークおよび結合作業を実行するプロセッサー (現時点では、Scatter-Gather ルーターと Parallel For Each ルーター) が子イベントコンテキストを完了します。

次のバージョン以降に使用可能​

  • 4.9.2

  • 4.6.14

  • 4.4.0-20250217

次のバージョン以降にデフォルトで有効化​

  • どの Mule バージョンでもデフォルトでは有効になりません

課題 ID​

  • W-16941297
## [](#関連情報)関連情報 [システムプロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-app-properties-system) # 環境プロパティの設定 作業している開発環境 (QA、本番前、本番など) に基づいてプロパティファイルを自動的に読み込むように Mule アプリケーションを設定できます。これにより、オンプレミスとクラウドの両方へのアプリケーションのデプロイが容易になります。この設定では、以下のタスクを完了する必要があります。 1. アプリケーション内で各開発環境のプロパティファイルを作成します。 2. 起動時に環境を探すようにアプリケーション内でプロパティプレースホルダーを設定します。 3. アプリケーションのデプロイ時に特定の開発環境を参照するように環境変数を設定します。 環境間で異なっていなくても、設定の他の側面 (タイムアウト値やポーリング頻度など) を外部化することを考慮してください。この設定により、Mule アプリケーションが 1 つのプロパティファイルで完全に設定可能になるため、調整や試験が容易になります。 [Studio のサンプルアプリケーションをダウンロードする](https://docs.mulesoft.com/jp/mule-runtime/4.3/_attachments/multiple-envs-example.jar) ## [](#環境プロパティを使用する場合の考慮事項)環境プロパティを使用する場合の考慮事項 環境プロパティを設定する場合は次のガイドラインを考慮してください。 - プロパティファイルの一貫した命名戦略を使用して、プロパティファイルがアプリケーション間で一意になるようにします。 この方法により、チーム間でファイルを容易に再利用できるようになります。適切な戦略として、アプリケーション名またはアプリケーション ID をプロパティファイル名に追加することをお勧めします。 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.3/shared-resources)​構造を介して複数のアプリケーションをデプロイする場合は、プロパティファイルに何も設定しないでください。 設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイしたアプリケーション、そのドメイン、およびそのドメイン下の他のアプリケーションのスコープにわたる環境変数を設定することができます。 Studio では、​**\[Run Configurations (設定の実行)\]**​ メニューの ​**\[Environment (環境)\]**​ タブを使用して環境変数を作成できます。\[Environment (環境)\] タブには、​**\[Play (再生)\]**​ ボタンの右にあるドロップダウンメニューからアクセスできます。 ## [](#環境プロパティ設定の基本アーキテクチャ)環境プロパティ設定の基本アーキテクチャ 次の Mule 設定フラグメントでは、​`env`​ というグローバルプロパティ、動的設定プロパティファイル (​`env`​ プロパティに基づく)、および変数設定を含む HTTP Connector を定義しています。 ```xml ``` 次の例では Spring のプロパティプレースホルダー解決メカニズムを使用しています。変数ビット (​**ベースパス**​、​**ホスト**​、​**ポート**​) が明確に示されています。これらは、このコネクタのデプロイ先の環境ごとに異なる可能性があります。 アプリケーションをデプロイするときに、​`env`​ プロパティをデプロイ先の特定の環境 (​`qa`​ や ​`prod`​ など) に動的に置き換えることができます。これにより、設定された環境に固有のプロパティを含む異なる ​`.yaml`​ ファイルを Mule アプリケーションで読み込むことができます。 これらの環境変数の値を提供するため、環境ごとに YAML 設定ファイルを使用します。 プロパティファイル: qa.yaml path: "test/products" host: "localhost" port: 8082 プロパティファイル: prod.yaml path: "products" host: "www.acme.com" port: 8081 ## [](#環境プロパティの作成と設定)環境プロパティの作成と設定 アプリケーション内で変数プロパティファイルを作成し、起動時に環境を探すように設定します。また、環境プロパティは Studio でテストすることもできます。これらの作業を完了するには、以下の手順を参照してください。 ### [](#studio-ビジュアルエディターの使用)Studio ビジュアルエディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![deploying to multiple environments 01](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![deploying to multiple environments 02](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-02.png) ![deploying to multiple environments 03](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio プロジェクトの \[Global Elements (グローバル要素)\] タブ内をクリックします。 5. 新しいグローバル要素を ​**\[Create (作成)\]**​ します。 要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Configuration properties (設定プロパティ)\]**​ を選択します。 ![deploying to multiple environments 04](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-04.png) 6. **\[File (ファイル)\]**​ 項目の値を ​`${env}.yaml`​ に設定します。 7. 新しいプロパティを ​**\[Create (作成)\]**​ し、デフォルトの環境を追加します。要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Global Property (グローバルプロパティ)\]**​ を選択します。 ![deploying to multiple environments 05](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-05.png) 8. プロパティに値を設定します。 ![deploying to multiple environments 06](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-06.png) 9. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#xml-エディターの使用)XML エディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![deploying to multiple environments 01](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![deploying to multiple environments 02](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-02.png) ![deploying to multiple environments 03](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio アプリケーションの \[Configuration XML (設定 XML)\] タブ内をクリックします。 5. **configuration-properties**​ 要素を XML ファイルに追加し、ファイル名を設定可能にします。 ```xml ``` 1. **\[Global Property (グローバルプロパティ)\]**​ 要素を追加して、デフォルトの環境名を設定します。 ```xml ``` 1. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#studio-での構成済み環境プロパティのテスト)Studio での構成済み環境プロパティのテスト 変数プロパティファイルで設定した特定の環境がアプリケーションで使用されることをテストするには、Studio に埋め込まれた Mule でアプリケーションを実行します。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Mule Application (Mule アプリケーション)\]**​ を選択します。 2. Studio は、前の手順の ​**\[Global Property (グローバルプロパティ)\]**​ で指定された環境変数に従って、アプリケーションを自動的にデプロイします。 3. 再度、\[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations…​ (設定の実行…​)\]**​ を選択します。 ![deploying to multiple environments 07](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-07.png) 4. `Arguments`​ タブでシステムプロパティを定義します。 ![deploying to multiple environments 08](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-08.png) 5. `Run`​ ボタンをクリックして手順を完了します。​`qa.yaml`​ で定義されたプロパティではなく ​`prod.yaml`​ で設定されたプロパティが使用されます。 ## [](#アプリケーションのデプロイのための環境変数の設定)アプリケーションのデプロイのための環境変数の設定 Mule は開始時に環境変数を読み込みます。そのため、デプロイメント対象 (CloudHub またはオンプレミス) に応じて、アプリケーションのデプロイ時 (CloudHub) または Mule インスタンスの開始時 (オンプレミス) に環境を設定する必要があります。 ### [](#オンプレミスでの-mule-の開始時に特定の環境を設定)オンプレミスでの Mule の開始時に特定の環境を設定 #### [](#コマンドラインの使用)コマンドラインの使用 アプリケーションをデプロイする環境を、実行時に環境変数を使用して識別します。次の例に従って、使用する環境で Mule を実行するようにコマンドを実行します。 ```console $ mule -M-Denv=prod ``` 使用する設定済みの環境で Mule が開始されたら、目的のデプロイ方法を使用してアプリケーションをデプロイできます。 #### [](#anypoint-runtime-manager-の使用)Anypoint Runtime Manager の使用 前提条件として、​[Anypoint Runtime Manager でサーバーを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​し、Mule にリンクする必要があります。次に、​[カスタムサーバープロパティを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-properties-create)​できます。 ### [](#cloudhub-へのデプロイ時に特定の環境を設定)CloudHub へのデプロイ時に特定の環境を設定 #### [](#studio-から-cloudhub-へのデプロイ)Studio から CloudHub へのデプロイ Studio から、プロパティの環境変数を設定するプロセスを開始し、アプリケーションを CloudHub にデプロイできます。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Anypoint Platform\]**​ > ​**\[Deploy to Cloud (クラウドにデプロイ)\]**​ を選択します。 ![deploying to multiple environments 09](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-09.png) 2. 要求されたデータを入力し、​**\[Properties (プロパティ)\]**​ タブをクリックします。 3. **\[Key (キー)\]**​ を​**「env」**​に設定し、その値を​**「prod」**​に設定して、新しい環境変数を追加します。 ![deploying to multiple environments 10](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/deploying-to-multiple-environments-10.png) 4. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 #### [](#runtime-manager-から-cloudhub-へのデプロイ)Runtime Manager から CloudHub へのデプロイ Anypoint Runtime Manager を介してアプリケーションを CloudHub にデプロイするには、Runtime Manager コンソールを使用して​[プロパティ値を設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties#setting-properties-values-in-runtime-manager.adoc)​できます。 ## [](#関連情報)関連情報 - [変数プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.3/shared-resources) # 環境プロパティの設定 作業している開発環境 (QA、本番前、本番など) に基づいてプロパティファイルを自動的に読み込むように Mule アプリケーションを設定できます。これにより、オンプレミスとクラウドの両方へのアプリケーションのデプロイが容易になります。この設定では、以下のタスクを完了する必要があります。 1. アプリケーション内で各開発環境のプロパティファイルを作成します。 2. 起動時に環境を探すようにアプリケーション内でプロパティプレースホルダーを設定します。 3. アプリケーションのデプロイ時に特定の開発環境を参照するように環境変数を設定します。 環境間で異なっていなくても、設定の他の側面 (タイムアウト値やポーリング頻度など) を外部化することを考慮してください。この設定により、Mule アプリケーションが 1 つのプロパティファイルで完全に設定可能になるため、調整や試験が容易になります。 [Studio のサンプルアプリケーションをダウンロードする](https://docs.mulesoft.com/jp/mule-runtime/4.4/_attachments/multiple-envs-example.jar) ## [](#環境プロパティを使用する場合の考慮事項)環境プロパティを使用する場合の考慮事項 環境プロパティを設定する場合は次のガイドラインを考慮してください。 - プロパティファイルの一貫した命名戦略を使用して、プロパティファイルがアプリケーション間で一意になるようにします。 この方法により、チーム間でファイルを容易に再利用できるようになります。適切な戦略として、アプリケーション名またはアプリケーション ID をプロパティファイル名に追加することをお勧めします。 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.4/shared-resources)​構造を介して複数のアプリケーションをデプロイする場合は、プロパティファイルに何も設定しないでください。 設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイしたアプリケーション、そのドメイン、およびそのドメイン下の他のアプリケーションのスコープにわたる環境変数を設定することができます。 Studio では、​**\[Run Configurations (設定の実行)\]**​ メニューの ​**\[Environment (環境)\]**​ タブを使用して環境変数を作成できます。\[Environment (環境)\] タブには、​**\[Play (再生)\]**​ ボタンの右にあるドロップダウンメニューからアクセスできます。 ## [](#環境プロパティ設定の基本アーキテクチャ)環境プロパティ設定の基本アーキテクチャ 次の Mule 設定フラグメントでは、​`env`​ というグローバルプロパティ、動的設定プロパティファイル (​`env`​ プロパティに基づく)、および変数設定を含む HTTP Connector を定義しています。 ```xml ``` 次の例では Spring のプロパティプレースホルダー解決メカニズムを使用しています。変数ビット (​**ベースパス**​、​**ホスト**​、​**ポート**​) が明確に示されています。これらは、このコネクタのデプロイ先の環境ごとに異なる可能性があります。 アプリケーションをデプロイするときに、​`env`​ プロパティをデプロイ先の特定の環境 (​`qa`​ や ​`prod`​ など) に動的に置き換えることができます。これにより、設定された環境に固有のプロパティを含む異なる ​`.yaml`​ ファイルを Mule アプリケーションで読み込むことができます。 これらの環境変数の値を提供するため、環境ごとに YAML 設定ファイルを使用します。 プロパティファイル: qa.yaml path: "test/products" host: "localhost" port: 8082 プロパティファイル: prod.yaml path: "products" host: "www.acme.com" port: 8081 ## [](#環境プロパティの作成と設定)環境プロパティの作成と設定 アプリケーション内で変数プロパティファイルを作成し、起動時に環境を探すように設定します。また、環境プロパティは Studio でテストすることもできます。これらの作業を完了するには、以下の手順を参照してください。 ### [](#studio-ビジュアルエディターの使用)Studio ビジュアルエディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![deploying to multiple environments 01](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![deploying to multiple environments 02](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-02.png) ![deploying to multiple environments 03](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio プロジェクトの \[Global Elements (グローバル要素)\] タブ内をクリックします。 5. 新しいグローバル要素を ​**\[Create (作成)\]**​ します。 要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Configuration properties (設定プロパティ)\]**​ を選択します。 ![deploying to multiple environments 04](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-04.png) 6. **\[File (ファイル)\]**​ 項目の値を ​`${env}.yaml`​ に設定します。 7. 新しいプロパティを ​**\[Create (作成)\]**​ し、デフォルトの環境を追加します。要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Global Property (グローバルプロパティ)\]**​ を選択します。 ![deploying to multiple environments 05](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-05.png) 8. プロパティに値を設定します。 ![deploying to multiple environments 06](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-06.png) 9. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#xml-エディターの使用)XML エディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![deploying to multiple environments 01](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![deploying to multiple environments 02](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-02.png) ![deploying to multiple environments 03](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio アプリケーションの \[Configuration XML (設定 XML)\] タブ内をクリックします。 5. **configuration-properties**​ 要素を XML ファイルに追加し、ファイル名を設定可能にします。 ```xml ``` 1. **\[Global Property (グローバルプロパティ)\]**​ 要素を追加して、デフォルトの環境名を設定します。 ```xml ``` 1. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#studio-での構成済み環境プロパティのテスト)Studio での構成済み環境プロパティのテスト 変数プロパティファイルで設定した特定の環境がアプリケーションで使用されることをテストするには、Studio に埋め込まれた Mule でアプリケーションを実行します。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Mule Application (Mule アプリケーション)\]**​ を選択します。 2. Studio は、前の手順の ​**\[Global Property (グローバルプロパティ)\]**​ で指定された環境変数に従って、アプリケーションを自動的にデプロイします。 3. 再度、\[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations…​ (設定の実行…​)\]**​ を選択します。 ![deploying to multiple environments 07](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-07.png) 4. `Arguments`​ タブでシステムプロパティを定義します。 ![deploying to multiple environments 08](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-08.png) 5. `Run`​ ボタンをクリックして手順を完了します。​`qa.yaml`​ で定義されたプロパティではなく ​`prod.yaml`​ で設定されたプロパティが使用されます。 ## [](#アプリケーションのデプロイのための環境変数の設定)アプリケーションのデプロイのための環境変数の設定 Mule は開始時に環境変数を読み込みます。そのため、デプロイメント対象 (CloudHub またはオンプレミス) に応じて、アプリケーションのデプロイ時 (CloudHub) または Mule インスタンスの開始時 (オンプレミス) に環境を設定する必要があります。 ### [](#オンプレミスでの-mule-の開始時に特定の環境を設定)オンプレミスでの Mule の開始時に特定の環境を設定 #### [](#コマンドラインの使用)コマンドラインの使用 アプリケーションをデプロイする環境を、実行時に環境変数を使用して識別します。次の例に従って、使用する環境で Mule を実行するようにコマンドを実行します。 ```console $ mule -M-Denv=prod ``` 使用する設定済みの環境で Mule が開始されたら、目的のデプロイ方法を使用してアプリケーションをデプロイできます。 #### [](#anypoint-runtime-manager-の使用)Anypoint Runtime Manager の使用 前提条件として、​[Anypoint Runtime Manager でサーバーを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​し、Mule にリンクする必要があります。次に、​[カスタムサーバープロパティを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-properties-create)​できます。 ### [](#cloudhub-へのデプロイ時に特定の環境を設定)CloudHub へのデプロイ時に特定の環境を設定 #### [](#studio-から-cloudhub-へのデプロイ)Studio から CloudHub へのデプロイ Studio から、プロパティの環境変数を設定するプロセスを開始し、アプリケーションを CloudHub にデプロイできます。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Anypoint Platform\]**​ > ​**\[Deploy to Cloud (クラウドにデプロイ)\]**​ を選択します。 ![deploying to multiple environments 09](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-09.png) 2. 要求されたデータを入力し、​**\[Properties (プロパティ)\]**​ タブをクリックします。 3. **\[Key (キー)\]**​ を​**「env」**​に設定し、その値を​**「prod」**​に設定して、新しい環境変数を追加します。 ![deploying to multiple environments 10](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/deploying-to-multiple-environments-10.png) 4. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 #### [](#runtime-manager-から-cloudhub-へのデプロイ)Runtime Manager から CloudHub へのデプロイ Anypoint Runtime Manager を介してアプリケーションを CloudHub にデプロイするには、Runtime Manager コンソールを使用して​[プロパティ値を設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties#setting-properties-values-in-runtime-manager.adoc)​できます。 ## [](#関連情報)関連情報 - [変数プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.4/shared-resources) # 環境プロパティの設定 作業している開発環境 (QA、本番前、本番など) に基づいてプロパティファイルを自動的に読み込むように Mule アプリケーションを設定できます。これにより、オンプレミスとクラウドの両方へのアプリケーションのデプロイが容易になります。この設定では、以下のタスクを完了する必要があります。 1. アプリケーション内で各開発環境のプロパティファイルを作成します。 2. 起動時に環境を探すようにアプリケーション内でプロパティプレースホルダーを設定します。 3. アプリケーションのデプロイ時に特定の開発環境を参照するように環境変数を設定します。 環境間で異なっていなくても、設定の他の側面 (タイムアウト値やポーリング頻度など) を外部化することを考慮してください。この設定により、Mule アプリケーションが 1 つのプロパティファイルで完全に設定可能になるため、調整や試験が容易になります。 [Studio のサンプルアプリケーションをダウンロードする](https://docs.mulesoft.com/jp/mule-runtime/4.5/_attachments/multiple-envs-example.jar) ## [](#環境プロパティを使用する場合の考慮事項)環境プロパティを使用する場合の考慮事項 環境プロパティを設定する場合は次のガイドラインを考慮してください。 - プロパティファイルの一貫した命名戦略を使用して、プロパティファイルがアプリケーション間で一意になるようにします。 この方法により、チーム間でファイルを容易に再利用できるようになります。適切な戦略として、アプリケーション名またはアプリケーション ID をプロパティファイル名に追加することをお勧めします。 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.5/shared-resources)​構造を介して複数のアプリケーションをデプロイする場合は、プロパティファイルに何も設定しないでください。 設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイしたアプリケーション、そのドメイン、およびそのドメイン下の他のアプリケーションのスコープにわたる環境変数を設定することができます。 Studio では、​**\[Run Configurations (設定の実行)\]**​ メニューの ​**\[Environment (環境)\]**​ タブを使用して環境変数を作成できます。\[Environment (環境)\] タブには、​**\[Play (再生)\]**​ ボタンの右にあるドロップダウンメニューからアクセスできます。 ## [](#環境プロパティ設定の基本アーキテクチャ)環境プロパティ設定の基本アーキテクチャ 次の Mule 設定フラグメントでは、​`env`​ というグローバルプロパティ、動的設定プロパティファイル (​`env`​ プロパティに基づく)、および変数設定を含む HTTP Connector を定義しています。 ```xml ``` 次の例では Spring のプロパティプレースホルダー解決メカニズムを使用しています。変数ビット (​**ベースパス**​、​**ホスト**​、​**ポート**​) が明確に示されています。これらは、このコネクタのデプロイ先の環境ごとに異なる可能性があります。 アプリケーションをデプロイするときに、​`env`​ プロパティをデプロイ先の特定の環境 (​`qa`​ や ​`prod`​ など) に動的に置き換えることができます。これにより、設定された環境に固有のプロパティを含む異なる ​`.yaml`​ ファイルを Mule アプリケーションで読み込むことができます。 これらの環境変数の値を提供するため、環境ごとに YAML 設定ファイルを使用します。 プロパティファイル: qa.yaml path: "test/products" host: "localhost" port: 8082 プロパティファイル: prod.yaml path: "products" host: "www.acme.com" port: 8081 ## [](#環境プロパティの作成と設定)環境プロパティの作成と設定 アプリケーション内で変数プロパティファイルを作成し、起動時に環境を探すように設定します。また、環境プロパティは Studio でテストすることもできます。これらの作業を完了するには、以下の手順を参照してください。 ### [](#studio-ビジュアルエディターの使用)Studio ビジュアルエディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。次に例を示します。 - `qa.yaml` - `prod.yaml` ![deploying to multiple environments 01](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![deploying to multiple environments 02](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-02.png) ![deploying to multiple environments 03](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio プロジェクトの \[Global Elements (グローバル要素)\] タブ内をクリックします。 5. 新しいグローバル要素を ​**\[Create (作成)\]**​ します。 要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Configuration properties (設定プロパティ)\]**​ を選択します。 ![deploying to multiple environments 04](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-04.png) 6. **\[File (ファイル)\]**​ 項目の値を ​`${env}.yaml`​ に設定します。 7. 新しいプロパティを ​**\[Create (作成)\]**​ し、デフォルトの環境を追加します。要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Global Property (グローバルプロパティ)\]**​ を選択します。 ![deploying to multiple environments 05](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-05.png) 8. プロパティに値を設定します。 ![deploying to multiple environments 06](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-06.png) 9. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#xml-エディターの使用)XML エディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。次に例を示します。 - `qa.yaml` - `prod.yaml` ![deploying to multiple environments 01](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![deploying to multiple environments 02](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-02.png) ![deploying to multiple environments 03](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio アプリケーションの \[Configuration XML (設定 XML)\] タブ内をクリックします。 5. **configuration-properties**​ 要素を XML ファイルに追加し、ファイル名を設定可能にします。 ```xml ``` 1. **\[Global Property (グローバルプロパティ)\]**​ 要素を追加して、デフォルトの環境名を設定します。 ```xml ``` 1. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#studio-での構成済み環境プロパティのテスト)Studio での構成済み環境プロパティのテスト 変数プロパティファイルで設定した特定の環境がアプリケーションで使用されることをテストするには、Studio に埋め込まれた Mule でアプリケーションを実行します。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Mule Application (Mule アプリケーション)\]**​ を選択します。 2. Studio は、前の手順の ​**\[Global Property (グローバルプロパティ)\]**​ で指定された環境変数に従って、アプリケーションを自動的にデプロイします。 3. 再度、\[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations…​ (設定の実行…​)\]**​ を選択します。 ![deploying to multiple environments 07](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-07.png) 4. `Arguments`​ タブでシステムプロパティを定義します。 ![deploying to multiple environments 08](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-08.png) 5. `Run`​ ボタンをクリックして手順を完了します。​`qa.yaml`​ で定義されたプロパティではなく ​`prod.yaml`​ で設定されたプロパティが使用されます。 ## [](#アプリケーションのデプロイのための環境変数の設定)アプリケーションのデプロイのための環境変数の設定 Mule は開始時に環境変数を読み込みます。そのため、デプロイメント対象 (CloudHub またはオンプレミス) に応じて、アプリケーションのデプロイ時 (CloudHub) または Mule インスタンスの開始時 (オンプレミス) に環境を設定する必要があります。 ### [](#オンプレミスでの-mule-の開始時に特定の環境を設定)オンプレミスでの Mule の開始時に特定の環境を設定 #### [](#コマンドラインの使用)コマンドラインの使用 アプリケーションをデプロイする環境を、実行時に環境変数を使用して識別します。次の例に従って、使用する環境で Mule を実行するようにコマンドを実行します。 ```console $ mule -M-Denv=prod ``` 使用する設定済みの環境で Mule が開始されたら、目的のデプロイ方法を使用してアプリケーションをデプロイできます。 #### [](#anypoint-runtime-manager-の使用)Anypoint Runtime Manager の使用 前提条件として、​[Anypoint Runtime Manager でサーバーを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​し、Mule にリンクする必要があります。次に、​[カスタムサーバープロパティを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-properties-create)​できます。 ### [](#cloudhub-へのデプロイ時に特定の環境を設定)CloudHub へのデプロイ時に特定の環境を設定 #### [](#studio-から-cloudhub-へのデプロイ)Studio から CloudHub へのデプロイ Studio から、プロパティの環境変数を設定するプロセスを開始し、アプリケーションを CloudHub にデプロイできます。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Anypoint Platform\]**​ > ​**\[Deploy to Cloud (クラウドにデプロイ)\]**​ を選択します。 ![deploying to multiple environments 09](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-09.png) 2. 要求されたデータを入力し、​**\[Properties (プロパティ)\]**​ タブをクリックします。 3. **\[Key (キー)\]**​ を​**「env」**​に設定し、その値を​**「prod」**​に設定して、新しい環境変数を追加します。 ![deploying to multiple environments 10](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/deploying-to-multiple-environments-10.png) 4. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 #### [](#runtime-manager-から-cloudhub-へのデプロイ)Runtime Manager から CloudHub へのデプロイ Anypoint Runtime Manager を介してアプリケーションを CloudHub にデプロイするには、Runtime Manager コンソールを使用して​[プロパティ値を設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties#setting-properties-values-in-runtime-manager.adoc)​できます。 ## [](#関連情報)関連情報 - [変数プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.5/shared-resources) # 環境プロパティの設定 作業している開発環境 (QA、本番前、本番など) に基づいてプロパティファイルを自動的に読み込むように Mule アプリケーションを設定できます。これにより、オンプレミスとクラウドの両方へのアプリケーションのデプロイが容易になります。この設定では、以下のタスクを完了する必要があります。 1. アプリケーション内で各開発環境のプロパティファイルを作成します。 2. 起動時に環境を探すようにアプリケーション内でプロパティプレースホルダーを設定します。 3. アプリケーションのデプロイ時に特定の開発環境を参照するように環境変数を設定します。 環境間で異なっていなくても、設定の他の側面 (タイムアウト値やポーリング頻度など) を外部化することを考慮してください。この設定により、Mule アプリケーションが 1 つのプロパティファイルで完全に設定可能になるため、調整や試験が容易になります。 [Studio のサンプルアプリケーションをダウンロードする](https://docs.mulesoft.com/jp/mule-runtime/4.6/_attachments/multiple-envs-example.jar) ## [](#環境プロパティを使用する場合の考慮事項)環境プロパティを使用する場合の考慮事項 環境プロパティを設定する場合は次のガイドラインを考慮してください。 - プロパティファイルの一貫した命名戦略を使用して、プロパティファイルがアプリケーション間で一意になるようにします。 この方法により、チーム間でファイルを容易に再利用できるようになります。適切な戦略として、アプリケーション名またはアプリケーション ID をプロパティファイル名に追加することをお勧めします。 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.6/shared-resources)​構造を介して複数のアプリケーションをデプロイする場合は、プロパティファイルに何も設定しないでください。 設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイしたアプリケーション、そのドメイン、およびそのドメイン下の他のアプリケーションのスコープにわたる環境変数を設定することができます。 Studio では、​**\[Run Configurations (設定の実行)\]**​ メニューの ​**\[Environment (環境)\]**​ タブを使用して環境変数を作成できます。\[Environment (環境)\] タブには、​**\[Play (再生)\]**​ ボタンの右にあるドロップダウンメニューからアクセスできます。 ## [](#環境プロパティ設定の基本アーキテクチャ)環境プロパティ設定の基本アーキテクチャ 次の Mule 設定フラグメントでは、​`env`​ というグローバルプロパティ、動的設定プロパティファイル (​`env`​ プロパティに基づく)、および変数設定を含む HTTP Connector を定義しています。 ```xml ``` 次の例では Spring のプロパティプレースホルダー解決メカニズムを使用しています。変数ビット (​**ベースパス**​、​**ホスト**​、​**ポート**​) が明確に示されています。これらは、このコネクタのデプロイ先の環境ごとに異なる可能性があります。 アプリケーションをデプロイするときに、​`env`​ プロパティをデプロイ先の特定の環境 (​`qa`​ や ​`prod`​ など) に動的に置き換えることができます。これにより、設定された環境に固有のプロパティを含む異なる ​`.yaml`​ ファイルを Mule アプリケーションで読み込むことができます。 これらの環境変数の値を提供するため、環境ごとに YAML 設定ファイルを使用します。 プロパティファイル: qa.yaml path: "test/products" host: "localhost" port: 8082 プロパティファイル: prod.yaml path: "products" host: "www.acme.com" port: 8081 ## [](#環境プロパティの作成と設定)環境プロパティの作成と設定 アプリケーション内で変数プロパティファイルを作成し、起動時に環境を探すように設定します。また、環境プロパティは Studio でテストすることもできます。これらの作業を完了するには、以下の手順を参照してください。 ### [](#studio-ビジュアルエディターの使用)Studio ビジュアルエディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![deploying to multiple environments 01](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![deploying to multiple environments 02](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-02.png) ![deploying to multiple environments 03](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio プロジェクトの \[Global Elements (グローバル要素)\] タブ内をクリックします。 5. 新しいグローバル要素を ​**\[Create (作成)\]**​ します。 要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Configuration properties (設定プロパティ)\]**​ を選択します。 ![deploying to multiple environments 04](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-04.png) 6. **\[File (ファイル)\]**​ 項目の値を ​`${env}.yaml`​ に設定します。 7. 新しいプロパティを ​**\[Create (作成)\]**​ し、デフォルトの環境を追加します。要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Global Property (グローバルプロパティ)\]**​ を選択します。 ![deploying to multiple environments 05](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-05.png) 8. プロパティに値を設定します。 ![deploying to multiple environments 06](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-06.png) 9. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#xml-エディターの使用)XML エディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![deploying to multiple environments 01](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![deploying to multiple environments 02](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-02.png) ![deploying to multiple environments 03](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio アプリケーションの \[Configuration XML (設定 XML)\] タブ内をクリックします。 5. **configuration-properties**​ 要素を XML ファイルに追加し、ファイル名を設定可能にします。 ```xml ``` 1. **\[Global Property (グローバルプロパティ)\]**​ 要素を追加して、デフォルトの環境名を設定します。 ```xml ``` 1. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#studio-での構成済み環境プロパティのテスト)Studio での構成済み環境プロパティのテスト 変数プロパティファイルで設定した特定の環境がアプリケーションで使用されることをテストするには、Studio に埋め込まれた Mule でアプリケーションを実行します。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Mule Application (Mule アプリケーション)\]**​ を選択します。 2. Studio は、前の手順の ​**\[Global Property (グローバルプロパティ)\]**​ で指定された環境変数に従って、アプリケーションを自動的にデプロイします。 3. 再度、\[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations…​ (設定の実行…​)\]**​ を選択します。 ![deploying to multiple environments 07](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-07.png) 4. `Arguments`​ タブでシステムプロパティを定義します。 ![deploying to multiple environments 08](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-08.png) 5. `Run`​ ボタンをクリックして手順を完了します。​`qa.yaml`​ で定義されたプロパティではなく ​`prod.yaml`​ で設定されたプロパティが使用されます。 ## [](#アプリケーションのデプロイのための環境変数の設定)アプリケーションのデプロイのための環境変数の設定 Mule は開始時に環境変数を読み込みます。そのため、デプロイメント対象 (CloudHub またはオンプレミス) に応じて、アプリケーションのデプロイ時 (CloudHub) または Mule インスタンスの開始時 (オンプレミス) に環境を設定する必要があります。 ### [](#オンプレミスでの-mule-の開始時に特定の環境を設定)オンプレミスでの Mule の開始時に特定の環境を設定 #### [](#コマンドラインの使用)コマンドラインの使用 アプリケーションをデプロイする環境を、実行時に環境変数を使用して識別します。次の例に従って、使用する環境で Mule を実行するようにコマンドを実行します。 ```console $ mule -M-Denv=prod ``` 使用する設定済みの環境で Mule が開始されたら、目的のデプロイ方法を使用してアプリケーションをデプロイできます。 #### [](#anypoint-runtime-manager-の使用)Anypoint Runtime Manager の使用 前提条件として、​[Anypoint Runtime Manager でサーバーを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​し、Mule にリンクする必要があります。次に、​[カスタムサーバープロパティを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-properties-create)​できます。 ### [](#cloudhub-へのデプロイ時に特定の環境を設定)CloudHub へのデプロイ時に特定の環境を設定 #### [](#studio-から-cloudhub-へのデプロイ)Studio から CloudHub へのデプロイ Studio から、プロパティの環境変数を設定するプロセスを開始し、アプリケーションを CloudHub にデプロイできます。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Anypoint Platform\]**​ > ​**\[Deploy to Cloud (クラウドにデプロイ)\]**​ を選択します。 ![deploying to multiple environments 09](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-09.png) 2. 要求されたデータを入力し、​**\[Properties (プロパティ)\]**​ タブをクリックします。 3. **\[Key (キー)\]**​ を​**「env」**​に設定し、その値を​**「prod」**​に設定して、新しい環境変数を追加します。 ![deploying to multiple environments 10](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/deploying-to-multiple-environments-10.png) 4. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 #### [](#runtime-manager-から-cloudhub-へのデプロイ)Runtime Manager から CloudHub へのデプロイ Anypoint Runtime Manager を介してアプリケーションを CloudHub にデプロイするには、Runtime Manager コンソールを使用して​[プロパティ値を設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties#setting-properties-values-in-runtime-manager.adoc)​できます。 ## [](#関連情報)関連情報 - [変数プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.6/shared-resources) # 環境プロパティの設定 作業している開発環境 (QA、本番前、本番など) に基づいてプロパティファイルを自動的に読み込むように Mule アプリケーションを設定できます。これにより、オンプレミスとクラウドの両方へのアプリケーションのデプロイが容易になります。この設定では、以下のタスクを完了する必要があります。 1. アプリケーション内で各開発環境のプロパティファイルを作成します。 2. 起動時に環境を探すようにアプリケーション内でプロパティプレースホルダーを設定します。 3. アプリケーションのデプロイ時に特定の開発環境を参照するように環境変数を設定します。 環境間で異なっていなくても、設定の他の側面 (タイムアウト値やポーリング頻度など) を外部化することを考慮してください。この設定により、Mule アプリケーションが 1 つのプロパティファイルで完全に設定可能になるため、調整や試験が容易になります。 [Studio のサンプルアプリケーションをダウンロードする](https://docs.mulesoft.com/jp/mule-runtime/4.7/_attachments/multiple-envs-example.jar) ## [](#環境プロパティを使用する場合の考慮事項)環境プロパティを使用する場合の考慮事項 環境プロパティを設定する場合は次のガイドラインを考慮してください。 - プロパティファイルの一貫した命名戦略を使用して、プロパティファイルがアプリケーション間で一意になるようにします。 この方法により、チーム間でファイルを容易に再利用できるようになります。適切な戦略として、アプリケーション名またはアプリケーション ID をプロパティファイル名に追加することをお勧めします。 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.7/shared-resources)​構造を介して複数のアプリケーションをデプロイする場合は、プロパティファイルに何も設定しないでください。 設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイしたアプリケーション、そのドメイン、およびそのドメイン下の他のアプリケーションのスコープにわたる環境変数を設定することができます。 Studio では、​**\[Run Configurations (設定の実行)\]**​ メニューの ​**\[Environment (環境)\]**​ タブを使用して環境変数を作成できます。\[Environment (環境)\] タブには、​**\[Play (再生)\]**​ ボタンの右にあるドロップダウンメニューからアクセスできます。 ## [](#環境プロパティ設定の基本アーキテクチャ)環境プロパティ設定の基本アーキテクチャ 次の Mule 設定フラグメントでは、​`env`​ というグローバルプロパティ、動的設定プロパティファイル (​`env`​ プロパティに基づく)、および変数設定を含む HTTP Connector を定義しています。 ```xml ``` 次の例では Spring のプロパティプレースホルダー解決メカニズムを使用しています。変数ビット (​**ベースパス**​、​**ホスト**​、​**ポート**​) が明確に示されています。これらは、このコネクタのデプロイ先の環境ごとに異なる可能性があります。 アプリケーションをデプロイするときに、​`env`​ プロパティをデプロイ先の特定の環境 (​`qa`​ や ​`prod`​ など) に動的に置き換えることができます。これにより、設定された環境に固有のプロパティを含む異なる ​`.yaml`​ ファイルを Mule アプリケーションで読み込むことができます。 これらの環境変数の値を提供するため、環境ごとに YAML 設定ファイルを使用します。 プロパティファイル: qa.yaml path: "test/products" host: "localhost" port: 8082 プロパティファイル: prod.yaml path: "products" host: "www.acme.com" port: 8081 ## [](#環境プロパティの作成と設定)環境プロパティの作成と設定 アプリケーション内で変数プロパティファイルを作成し、起動時に環境を探すように設定します。また、環境プロパティは Studio でテストすることもできます。これらの作業を完了するには、以下の手順を参照してください。 ### [](#studio-ビジュアルエディターの使用)Studio ビジュアルエディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![Anypoint Studio のさまざまな環境 (本番や QA など) のフォルダーが含まれるプロジェクト構造が表示されている Package Explorer](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![QA YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/deploying-to-multiple-environments-02.png) ![本番 YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio プロジェクトの \[Global Elements (グローバル要素)\] タブ内をクリックします。 5. 新しいグローバル要素を ​**\[Create (作成)\]**​ します。 要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Configuration properties (設定プロパティ)\]**​ を選択します。 ![Anypoint Studio の \[Global Configurations (グローバル設定)\] の \[Configuration Properties (設定プロパティ)\] などのグローバル要素種別を選択する設定パネル](_images/deploying-to-multiple-environments-04.png) 6. **\[File (ファイル)\]**​ 項目の値を ​`${env}.yaml`​ に設定します。 7. 新しいプロパティを ​**\[Create (作成)\]**​ し、デフォルトの環境を追加します。要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Global Property (グローバルプロパティ)\]**​ を選択します。 ![Anypoint Studio の \[Global Configurations (グローバル設定)\] の \[Global Propert (グローバルプロパティ)\] などのグローバル要素種別を選択する設定パネル](_images/deploying-to-multiple-environments-05.png) 8. プロパティに値を設定します。 ![Anypoint Studio の QA の環境変数が含まれる設定ダイアログ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/deploying-to-multiple-environments-06.png) 9. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#xml-エディターの使用)XML エディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![Anypoint Studio のさまざまな環境 (本番や QA など) のフォルダーが含まれるプロジェクト構造が表示されている Package Explorer](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![QA YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/deploying-to-multiple-environments-02.png) ![本番 YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio アプリケーションの \[Configuration XML (設定 XML)\] タブ内をクリックします。 5. **configuration-properties**​ 要素を XML ファイルに追加し、ファイル名を設定可能にします。 ```xml ``` 1. **\[Global Property (グローバルプロパティ)\]**​ 要素を追加して、デフォルトの環境名を設定します。 ```xml ``` 1. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#studio-での構成済み環境プロパティのテスト)Studio での構成済み環境プロパティのテスト 変数プロパティファイルで設定した特定の環境がアプリケーションで使用されることをテストするには、Studio に埋め込まれた Mule でアプリケーションを実行します。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Mule Application (Mule アプリケーション)\]**​ を選択します。 2. Studio は、前の手順の ​**\[Global Property (グローバルプロパティ)\]**​ で指定された環境変数に従って、アプリケーションを自動的にデプロイします。 3. 再度、\[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations…​ (設定の実行…​)\]**​ を選択します。 ![プロジェクト構造で設定を実行する方法が表示されている \[Package Explorer\] ビュー](_images/deploying-to-multiple-environments-07.png) 4. `Arguments`​ タブでシステムプロパティを定義します。 ![\[Run Configurations (設定を実行)\] パネル](_images/deploying-to-multiple-environments-08.png) 5. `Run`​ ボタンをクリックして手順を完了します。​`qa.yaml`​ で定義されたプロパティではなく ​`prod.yaml`​ で設定されたプロパティが使用されます。 ## [](#アプリケーションのデプロイのための環境変数の設定)アプリケーションのデプロイのための環境変数の設定 Mule は開始時に環境変数を読み込みます。そのため、デプロイメント対象 (CloudHub またはオンプレミス) に応じて、アプリケーションのデプロイ時 (CloudHub) または Mule インスタンスの開始時 (オンプレミス) に環境を設定する必要があります。 ### [](#オンプレミスでの-mule-の開始時に特定の環境を設定)オンプレミスでの Mule の開始時に特定の環境を設定 #### [](#コマンドラインの使用)コマンドラインの使用 アプリケーションをデプロイする環境を、実行時に環境変数を使用して識別します。次の例に従って、使用する環境で Mule を実行するようにコマンドを実行します。 ```console $ mule -M-Denv=prod ``` 使用する設定済みの環境で Mule が開始されたら、目的のデプロイ方法を使用してアプリケーションをデプロイできます。 #### [](#anypoint-runtime-manager-の使用)Anypoint Runtime Manager の使用 前提条件として、​[Anypoint Runtime Manager でサーバーを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​し、Mule にリンクする必要があります。次に、​[カスタムサーバープロパティを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-properties-create)​できます。 ### [](#cloudhub-へのデプロイ時に特定の環境を設定)CloudHub へのデプロイ時に特定の環境を設定 #### [](#studio-から-cloudhub-へのデプロイ)Studio から CloudHub へのデプロイ Studio から、プロパティの環境変数を設定するプロセスを開始し、アプリケーションを CloudHub にデプロイできます。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Anypoint Platform\]**​ > ​**\[Deploy to Cloud (クラウドにデプロイ)\]**​ を選択します。 ![アプリケーションを CloudHub にデプロイする方法が表示されている \[Package Explorer\] ビュー](_images/deploying-to-multiple-environments-09.png) 2. 要求されたデータを入力し、​**\[Properties (プロパティ)\]**​ タブをクリックします。 3. **\[Key (キー)\]**​ を​**「env」**​に設定し、その値を​**「prod」**​に設定して、新しい環境変数を追加します。 ![環境固有のプロパティが含まれる、アプリケーションの CloudHub デプロイメント設定](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/deploying-to-multiple-environments-10.png) 4. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 #### [](#runtime-manager-から-cloudhub-へのデプロイ)Runtime Manager から CloudHub へのデプロイ Anypoint Runtime Manager を介してアプリケーションを CloudHub にデプロイするには、Runtime Manager コンソールを使用して​[プロパティ値を設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties#setting-properties-values-in-runtime-manager.adoc)​できます。 ## [](#関連情報)関連情報 - [変数プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.7/shared-resources) # 環境プロパティの設定 作業している開発環境 (QA、本番前、本番など) に基づいてプロパティファイルを自動的に読み込むように Mule アプリケーションを設定できます。これにより、オンプレミスとクラウドの両方へのアプリケーションのデプロイが容易になります。この設定では、以下のタスクを完了する必要があります。 1. アプリケーション内で各開発環境のプロパティファイルを作成します。 2. 起動時に環境を探すようにアプリケーション内でプロパティプレースホルダーを設定します。 3. アプリケーションのデプロイ時に特定の開発環境を参照するように環境変数を設定します。 環境間で異なっていなくても、設定の他の側面 (タイムアウト値やポーリング頻度など) を外部化することを考慮してください。この設定により、Mule アプリケーションが 1 つのプロパティファイルで完全に設定可能になるため、調整や試験が容易になります。 [Studio のサンプルアプリケーションをダウンロードする](https://docs.mulesoft.com/jp/mule-runtime/4.8/_attachments/multiple-envs-example.jar) ## [](#環境プロパティを使用する場合の考慮事項)環境プロパティを使用する場合の考慮事項 環境プロパティを設定する場合は次のガイドラインを考慮してください。 - プロパティファイルの一貫した命名戦略を使用して、プロパティファイルがアプリケーション間で一意になるようにします。 この方法により、チーム間でファイルを容易に再利用できるようになります。適切な戦略として、アプリケーション名またはアプリケーション ID をプロパティファイル名に追加することをお勧めします。 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.8/shared-resources)​構造を介して複数のアプリケーションをデプロイする場合は、プロパティファイルに何も設定しないでください。 設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイしたアプリケーション、そのドメイン、およびそのドメイン下の他のアプリケーションのスコープにわたる環境変数を設定することができます。 Studio では、​**\[Run Configurations (設定の実行)\]**​ メニューの ​**\[Environment (環境)\]**​ タブを使用して環境変数を作成できます。\[Environment (環境)\] タブには、​**\[Play (再生)\]**​ ボタンの右にあるドロップダウンメニューからアクセスできます。 ## [](#環境プロパティ設定の基本アーキテクチャ)環境プロパティ設定の基本アーキテクチャ 次の Mule 設定フラグメントでは、​`env`​ というグローバルプロパティ、動的設定プロパティファイル (​`env`​ プロパティに基づく)、および変数設定を含む HTTP Connector を定義しています。 ```xml ``` 次の例では Spring のプロパティプレースホルダー解決メカニズムを使用しています。変数ビット (​**ベースパス**​、​**ホスト**​、​**ポート**​) が明確に示されています。これらは、このコネクタのデプロイ先の環境ごとに異なる可能性があります。 アプリケーションをデプロイするときに、​`env`​ プロパティをデプロイ先の特定の環境 (​`qa`​ や ​`prod`​ など) に動的に置き換えることができます。これにより、設定された環境に固有のプロパティを含む異なる ​`.yaml`​ ファイルを Mule アプリケーションで読み込むことができます。 これらの環境変数の値を提供するため、環境ごとに YAML 設定ファイルを使用します。 プロパティファイル: qa.yaml path: "test/products" host: "localhost" port: 8082 プロパティファイル: prod.yaml path: "products" host: "www.acme.com" port: 8081 ## [](#環境プロパティの作成と設定)環境プロパティの作成と設定 アプリケーション内で変数プロパティファイルを作成し、起動時に環境を探すように設定します。また、環境プロパティは Studio でテストすることもできます。これらの作業を完了するには、以下の手順を参照してください。 ### [](#studio-ビジュアルエディターの使用)Studio ビジュアルエディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![Anypoint Studio のさまざまな環境 (本番や QA など) のフォルダーが含まれるプロジェクト構造が表示されている Package Explorer](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![QA YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/deploying-to-multiple-environments-02.png) ![本番 YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio プロジェクトの \[Global Elements (グローバル要素)\] タブ内をクリックします。 5. 新しいグローバル要素を ​**\[Create (作成)\]**​ します。 要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Configuration properties (設定プロパティ)\]**​ を選択します。 ![Anypoint Studio の \[Global Configurations (グローバル設定)\] の \[Configuration Properties (設定プロパティ)\] などのグローバル要素種別を選択する設定パネル](_images/deploying-to-multiple-environments-04.png) 6. **\[File (ファイル)\]**​ 項目の値を ​`${env}.yaml`​ に設定します。 7. 新しいプロパティを ​**\[Create (作成)\]**​ し、デフォルトの環境を追加します。要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Global Property (グローバルプロパティ)\]**​ を選択します。 ![Anypoint Studio の \[Global Configurations (グローバル設定)\] の \[Global Propert (グローバルプロパティ)\] などのグローバル要素種別を選択する設定パネル](_images/deploying-to-multiple-environments-05.png) 8. プロパティに値を設定します。 ![Anypoint Studio の QA の環境変数が含まれる設定ダイアログ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/deploying-to-multiple-environments-06.png) 9. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#xml-エディターの使用)XML エディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![Anypoint Studio のさまざまな環境 (本番や QA など) のフォルダーが含まれるプロジェクト構造が表示されている Package Explorer](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![QA YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/deploying-to-multiple-environments-02.png) ![本番 YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio アプリケーションの \[Configuration XML (設定 XML)\] タブ内をクリックします。 5. **configuration-properties**​ 要素を XML ファイルに追加し、ファイル名を設定可能にします。 ```xml ``` 1. **\[Global Property (グローバルプロパティ)\]**​ 要素を追加して、デフォルトの環境名を設定します。 ```xml ``` 1. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#studio-での構成済み環境プロパティのテスト)Studio での構成済み環境プロパティのテスト 変数プロパティファイルで設定した特定の環境がアプリケーションで使用されることをテストするには、Studio に埋め込まれた Mule でアプリケーションを実行します。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Mule Application (Mule アプリケーション)\]**​ を選択します。 2. Studio は、前の手順の ​**\[Global Property (グローバルプロパティ)\]**​ で指定された環境変数に従って、アプリケーションを自動的にデプロイします。 3. 再度、\[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations…​ (設定の実行…​)\]**​ を選択します。 ![プロジェクト構造で設定を実行する方法が表示されている \[Package Explorer\] ビュー](_images/deploying-to-multiple-environments-07.png) 4. `Arguments`​ タブでシステムプロパティを定義します。 ![\[Run Configurations (設定を実行)\] パネル](_images/deploying-to-multiple-environments-08.png) 5. `Run`​ ボタンをクリックして手順を完了します。​`qa.yaml`​ で定義されたプロパティではなく ​`prod.yaml`​ で設定されたプロパティが使用されます。 ## [](#アプリケーションのデプロイのための環境変数の設定)アプリケーションのデプロイのための環境変数の設定 Mule は開始時に環境変数を読み込みます。そのため、デプロイメント対象 (CloudHub またはオンプレミス) に応じて、アプリケーションのデプロイ時 (CloudHub) または Mule インスタンスの開始時 (オンプレミス) に環境を設定する必要があります。 ### [](#オンプレミスでの-mule-の開始時に特定の環境を設定)オンプレミスでの Mule の開始時に特定の環境を設定 #### [](#コマンドラインの使用)コマンドラインの使用 アプリケーションをデプロイする環境を、実行時に環境変数を使用して識別します。次の例に従って、使用する環境で Mule を実行するようにコマンドを実行します。 ```console $ mule -M-Denv=prod ``` 使用する設定済みの環境で Mule が開始されたら、目的のデプロイ方法を使用してアプリケーションをデプロイできます。 #### [](#anypoint-runtime-manager-の使用)Anypoint Runtime Manager の使用 前提条件として、​[Anypoint Runtime Manager でサーバーを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​し、Mule にリンクする必要があります。次に、​[カスタムサーバープロパティを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-properties-create)​できます。 ### [](#cloudhub-へのデプロイ時に特定の環境を設定)CloudHub へのデプロイ時に特定の環境を設定 #### [](#studio-から-cloudhub-へのデプロイ)Studio から CloudHub へのデプロイ Studio から、プロパティの環境変数を設定するプロセスを開始し、アプリケーションを CloudHub にデプロイできます。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Anypoint Platform\]**​ > ​**\[Deploy to Cloud (クラウドにデプロイ)\]**​ を選択します。 ![アプリケーションを CloudHub にデプロイする方法が表示されている \[Package Explorer\] ビュー](_images/deploying-to-multiple-environments-09.png) 2. 要求されたデータを入力し、​**\[Properties (プロパティ)\]**​ タブをクリックします。 3. **\[Key (キー)\]**​ を​**「env」**​に設定し、その値を​**「prod」**​に設定して、新しい環境変数を追加します。 ![環境固有のプロパティが含まれる、アプリケーションの CloudHub デプロイメント設定](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/deploying-to-multiple-environments-10.png) 4. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 #### [](#runtime-manager-から-cloudhub-へのデプロイ)Runtime Manager から CloudHub へのデプロイ Anypoint Runtime Manager を介してアプリケーションを CloudHub にデプロイするには、Runtime Manager コンソールを使用して​[プロパティ値を設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties#setting-properties-values-in-runtime-manager.adoc)​できます。 ## [](#関連情報)関連情報 - [変数プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.8/shared-resources) # 環境プロパティの設定 作業している開発環境 (QA、本番前、本番など) に基づいてプロパティファイルを自動的に読み込むように Mule アプリケーションを設定できます。これにより、オンプレミスとクラウドの両方へのアプリケーションのデプロイが容易になります。この設定では、以下のタスクを完了する必要があります。 1. アプリケーション内で各開発環境のプロパティファイルを作成します。 2. 起動時に環境を探すようにアプリケーション内でプロパティプレースホルダーを設定します。 3. アプリケーションのデプロイ時に特定の開発環境を参照するように環境変数を設定します。 環境間で異なっていなくても、設定の他の側面 (タイムアウト値やポーリング頻度など) を外部化することを考慮してください。この設定により、Mule アプリケーションが 1 つのプロパティファイルで完全に設定可能になるため、調整や試験が容易になります。 [Studio のサンプルアプリケーションをダウンロードする](https://docs.mulesoft.com/jp/mule-runtime/4.9/_attachments/multiple-envs-example.jar) ## [](#環境プロパティを使用する場合の考慮事項)環境プロパティを使用する場合の考慮事項 環境プロパティを設定する場合は次のガイドラインを考慮してください。 - プロパティファイルの一貫した命名戦略を使用して、プロパティファイルがアプリケーション間で一意になるようにします。 この方法により、チーム間でファイルを容易に再利用できるようになります。適切な戦略として、アプリケーション名またはアプリケーション ID をプロパティファイル名に追加することをお勧めします。 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.9/shared-resources)​構造を介して複数のアプリケーションをデプロイする場合は、プロパティファイルに何も設定しないでください。 設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイしたアプリケーション、そのドメイン、およびそのドメイン下の他のアプリケーションのスコープにわたる環境変数を設定することができます。 Studio では、​**\[Run Configurations (設定の実行)\]**​ メニューの ​**\[Environment (環境)\]**​ タブを使用して環境変数を作成できます。\[Environment (環境)\] タブには、​**\[Play (再生)\]**​ ボタンの右にあるドロップダウンメニューからアクセスできます。 ## [](#環境プロパティ設定の基本アーキテクチャ)環境プロパティ設定の基本アーキテクチャ 次の Mule 設定フラグメントでは、​`env`​ というグローバルプロパティ、動的設定プロパティファイル (​`env`​ プロパティに基づく)、および変数設定を含む HTTP Connector を定義しています。 ```xml ``` 次の例では Spring のプロパティプレースホルダー解決メカニズムを使用しています。変数ビット (​**ベースパス**​、​**ホスト**​、​**ポート**​) が明確に示されています。これらは、このコネクタのデプロイ先の環境ごとに異なる可能性があります。 アプリケーションをデプロイするときに、​`env`​ プロパティをデプロイ先の特定の環境 (​`qa`​ や ​`prod`​ など) に動的に置き換えることができます。これにより、設定された環境に固有のプロパティを含む異なる ​`.yaml`​ ファイルを Mule アプリケーションで読み込むことができます。 これらの環境変数の値を提供するため、環境ごとに YAML 設定ファイルを使用します。 プロパティファイル: qa.yaml path: "test/products" host: "localhost" port: 8082 プロパティファイル: prod.yaml path: "products" host: "www.acme.com" port: 8081 ## [](#環境プロパティの作成と設定)環境プロパティの作成と設定 アプリケーション内で変数プロパティファイルを作成し、起動時に環境を探すように設定します。また、環境プロパティは Studio でテストすることもできます。これらの作業を完了するには、以下の手順を参照してください。 ### [](#studio-ビジュアルエディターの使用)Studio ビジュアルエディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![Anypoint Studio のさまざまな環境 (本番や QA など) のフォルダーが含まれるプロジェクト構造が表示されている Package Explorer](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![QA YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/deploying-to-multiple-environments-02.png) ![本番 YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio プロジェクトの \[Global Elements (グローバル要素)\] タブ内をクリックします。 5. 新しいグローバル要素を ​**\[Create (作成)\]**​ します。 要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Configuration properties (設定プロパティ)\]**​ を選択します。 ![Anypoint Studio の \[Global Configurations (グローバル設定)\] の \[Configuration Properties (設定プロパティ)\] などのグローバル要素種別を選択する設定パネル](_images/deploying-to-multiple-environments-04.png) 6. **\[File (ファイル)\]**​ 項目の値を ​`${env}.yaml`​ に設定します。 7. 新しいプロパティを ​**\[Create (作成)\]**​ し、デフォルトの環境を追加します。要素種別を選択する場合は、​**\[Global Configurations (グローバル設定)\]**​ の下にある ​**\[Global Property (グローバルプロパティ)\]**​ を選択します。 ![Anypoint Studio の \[Global Configurations (グローバル設定)\] の \[Global Propert (グローバルプロパティ)\] などのグローバル要素種別を選択する設定パネル](_images/deploying-to-multiple-environments-05.png) 8. プロパティに値を設定します。 ![Anypoint Studio の QA の環境変数が含まれる設定ダイアログ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/deploying-to-multiple-environments-06.png) 9. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#xml-エディターの使用)XML エディターの使用 1. アプリケーション内でサポートする環境のリストを定義します。たとえば、一般的なユースケースとして、本番環境と QA 環境の両方をサポートするようにアプリケーションを設定します。 変数 ​`variable`​ を環境 ​`prod`​ および ​`qa`​ 内で定義し、1 つのアプリケーションを使用してテストします。 1. `src/main/resources`​ フォルダーを右クリックし、​**\[New (新規)\]**​ > ​**\[File (ファイル)\]**​ を選択して、サポートする環境ごとにプロパティファイルを作成します。例: - `qa.yaml` - `prod.yaml` ![Anypoint Studio のさまざまな環境 (本番や QA など) のフォルダーが含まれるプロジェクト構造が表示されている Package Explorer](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/deploying-to-multiple-environments-01.png) 2. この新しい各ファイルをダブルクリックすると、ファイルが Studio の新しいタブで開きます。これを編集することで、ファイル名に対応する環境のプロパティを設定できます。たとえば、以下の図のようにプロパティを追加することができます。このプロパティはアプリケーションの任意の場所で使用できます。 ![QA YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/deploying-to-multiple-environments-02.png) ![本番 YAML 設定ファイル](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/deploying-to-multiple-environments-03.png) 3. プロパティファイルを閉じます。 4. キャンバスの下にある Studio アプリケーションの \[Configuration XML (設定 XML)\] タブ内をクリックします。 5. **configuration-properties**​ 要素を XML ファイルに追加し、ファイル名を設定可能にします。 ```xml ``` 1. **\[Global Property (グローバルプロパティ)\]**​ 要素を追加して、デフォルトの環境名を設定します。 ```xml ``` 1. 設定済みの ​**\[Global Property (グローバルプロパティ)\]**​ 値を編集することで、環境を変更することができます。 ### [](#studio-での構成済み環境プロパティのテスト)Studio での構成済み環境プロパティのテスト 変数プロパティファイルで設定した特定の環境がアプリケーションで使用されることをテストするには、Studio に埋め込まれた Mule でアプリケーションを実行します。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Mule Application (Mule アプリケーション)\]**​ を選択します。 2. Studio は、前の手順の ​**\[Global Property (グローバルプロパティ)\]**​ で指定された環境変数に従って、アプリケーションを自動的にデプロイします。 3. 再度、\[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Run As (別のユーザーとして実行)\]**​ > ​**\[Run Configurations…​ (設定の実行…​)\]**​ を選択します。 ![プロジェクト構造で設定を実行する方法が表示されている \[Package Explorer\] ビュー](_images/deploying-to-multiple-environments-07.png) 4. `Arguments`​ タブでシステムプロパティを定義します。 ![\[Run Configurations (設定を実行)\] パネル](_images/deploying-to-multiple-environments-08.png) 5. `Run`​ ボタンをクリックして手順を完了します。​`qa.yaml`​ で定義されたプロパティではなく ​`prod.yaml`​ で設定されたプロパティが使用されます。 ## [](#アプリケーションのデプロイのための環境変数の設定)アプリケーションのデプロイのための環境変数の設定 Mule は開始時に環境変数を読み込みます。そのため、デプロイメント対象 (CloudHub またはオンプレミス) に応じて、アプリケーションのデプロイ時 (CloudHub) または Mule インスタンスの開始時 (オンプレミス) に環境を設定する必要があります。 ### [](#オンプレミスでの-mule-の開始時に特定の環境を設定)オンプレミスでの Mule の開始時に特定の環境を設定 #### [](#コマンドラインの使用)コマンドラインの使用 アプリケーションをデプロイする環境を、実行時に環境変数を使用して識別します。次の例に従って、使用する環境で Mule を実行するようにコマンドを実行します。 ```console $ mule -M-Denv=prod ``` 使用する設定済みの環境で Mule が開始されたら、目的のデプロイ方法を使用してアプリケーションをデプロイできます。 #### [](#anypoint-runtime-manager-の使用)Anypoint Runtime Manager の使用 前提条件として、​[Anypoint Runtime Manager でサーバーを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​し、Mule にリンクする必要があります。次に、​[カスタムサーバープロパティを作成](https://docs.mulesoft.com/jp/runtime-manager/servers-properties-create)​できます。 ### [](#cloudhub-へのデプロイ時に特定の環境を設定)CloudHub へのデプロイ時に特定の環境を設定 #### [](#studio-から-cloudhub-へのデプロイ)Studio から CloudHub へのデプロイ Studio から、プロパティの環境変数を設定するプロセスを開始し、アプリケーションを CloudHub にデプロイできます。 1. \[Package Explorer\] ビューで、デプロイするプロジェクトのファイル名を右クリックし、​**\[Anypoint Platform\]**​ > ​**\[Deploy to Cloud (クラウドにデプロイ)\]**​ を選択します。 ![アプリケーションを CloudHub にデプロイする方法が表示されている \[Package Explorer\] ビュー](_images/deploying-to-multiple-environments-09.png) 2. 要求されたデータを入力し、​**\[Properties (プロパティ)\]**​ タブをクリックします。 3. **\[Key (キー)\]**​ を​**「env」**​に設定し、その値を​**「prod」**​に設定して、新しい環境変数を追加します。 ![環境固有のプロパティが含まれる、アプリケーションの CloudHub デプロイメント設定](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/deploying-to-multiple-environments-10.png) 4. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 #### [](#runtime-manager-から-cloudhub-へのデプロイ)Runtime Manager から CloudHub へのデプロイ Anypoint Runtime Manager を介してアプリケーションを CloudHub にデプロイするには、Runtime Manager コンソールを使用して​[プロパティ値を設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties#setting-properties-values-in-runtime-manager.adoc)​できます。 ## [](#関連情報)関連情報 - [変数プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties) - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.9/shared-resources) # 環境変数の設定 複数のアプリケーションを共有リソースとしてデプロイする場合、プロジェクトのプロパティファイルでプロパティを設定してはいけません。設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイするアプリケーション、そのドメイン、またはそのドメイン下の他のアプリケーションのスコープで環境変数を設定できます。 次の手順で、Studio で環境変数を設定する方法を説明します。これらの変数は、Studio からローカルでデプロイする場合のみ使用されます。アプリケーションをスタンドアロンサーバーにデプロイする場合、コマンドラインからこれらの変数を指定する必要があります。 1. **\[Run (実行)\]**​ で ​**\[Run Configurations (設定を実行)\]**​ を選択します。 2. 対応する実行設定を選択します。プロジェクトで実行設定が存在しない場合、\[new (新規)\] ボタンを使用して作成できます。 3. **\[Environment (環境)\]**​ タブを選択して、必要な変数を追加します。 作成した環境変数は、ドメインレベルで定義されます。これらの変数は、Studio を使用してローカルでデプロイしたときにそのドメインに関連付けられているすべてのアプリケーションに影響します。 環境変数の設定は、アプリケーションを Studio 内の Mule Runtime Engine で実行した場合のみ機能します。この設定は、DataSense、自動完了、検証などのデザインタイムの操作には影響しません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.3/shared-resources) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.3/configuring-properties) # 環境変数の設定 複数のアプリケーションを共有リソースとしてデプロイする場合、プロジェクトのプロパティファイルでプロパティを設定してはいけません。設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイするアプリケーション、そのドメイン、またはそのドメイン下の他のアプリケーションのスコープで環境変数を設定できます。 次の手順で、Studio で環境変数を設定する方法を説明します。これらの変数は、Studio からローカルでデプロイする場合のみ使用されます。アプリケーションをスタンドアロンサーバーにデプロイする場合、コマンドラインからこれらの変数を指定する必要があります。 1. **\[Run (実行)\]**​ で ​**\[Run Configurations (設定を実行)\]**​ を選択します。 2. 対応する実行設定を選択します。プロジェクトで実行設定が存在しない場合、\[new (新規)\] ボタンを使用して作成できます。 3. **\[Environment (環境)\]**​ タブを選択して、必要な変数を追加します。 作成した環境変数は、ドメインレベルで定義されます。これらの変数は、Studio を使用してローカルでデプロイしたときにそのドメインに関連付けられているすべてのアプリケーションに影響します。 環境変数の設定は、アプリケーションを Studio 内の Mule Runtime Engine で実行した場合のみ機能します。この設定は、DataSense、自動完了、検証などのデザインタイムの操作には影響しません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.4/shared-resources) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.4/configuring-properties) # 環境変数の設定 複数のアプリケーションを共有リソースとしてデプロイする場合、プロジェクトのプロパティファイルでプロパティを設定してはいけません。設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイするアプリケーション、そのドメイン、またはそのドメイン下の他のアプリケーションのスコープで環境変数を設定できます。 次の手順で、Studio で環境変数を設定する方法を説明します。これらの変数は、Studio からローカルでデプロイする場合のみ使用されます。アプリケーションをスタンドアロンサーバーにデプロイする場合、コマンドラインからこれらの変数を指定する必要があります。 1. **\[Run (実行)\]**​ で ​**\[Run Configurations (設定を実行)\]**​ を選択します。 2. 対応する実行設定を選択します。プロジェクトで実行設定が存在しない場合、\[new (新規)\] ボタンを使用して作成できます。 3. **\[Environment (環境)\]**​ タブを選択して、必要な変数を追加します。 作成した環境変数は、ドメインレベルで定義されます。これらの変数は、Studio を使用してローカルでデプロイしたときにそのドメインに関連付けられているすべてのアプリケーションに影響します。 環境変数の設定は、アプリケーションを Studio 内の Mule Runtime Engine で実行した場合のみ機能します。この設定は、DataSense、自動完了、検証などのデザインタイムの操作には影響しません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.5/shared-resources) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.5/configuring-properties) # 環境変数の設定 複数のアプリケーションを共有リソースとしてデプロイする場合、プロジェクトのプロパティファイルでプロパティを設定してはいけません。設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイするアプリケーション、そのドメイン、またはそのドメイン下の他のアプリケーションのスコープで環境変数を設定できます。 次の手順で、Studio で環境変数を設定する方法を説明します。これらの変数は、Studio からローカルでデプロイする場合のみ使用されます。アプリケーションをスタンドアロンサーバーにデプロイする場合、コマンドラインからこれらの変数を指定する必要があります。 1. **\[Run (実行)\]**​ で ​**\[Run Configurations (設定を実行)\]**​ を選択します。 2. 対応する実行設定を選択します。プロジェクトで実行設定が存在しない場合、\[new (新規)\] ボタンを使用して作成できます。 3. **\[Environment (環境)\]**​ タブを選択して、必要な変数を追加します。 作成した環境変数は、ドメインレベルで定義されます。これらの変数は、Studio を使用してローカルでデプロイしたときにそのドメインに関連付けられているすべてのアプリケーションに影響します。 環境変数の設定は、アプリケーションを Studio 内の Mule Runtime Engine で実行した場合のみ機能します。この設定は、DataSense、自動完了、検証などのデザインタイムの操作には影響しません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.6/shared-resources) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.6/configuring-properties) # 環境変数の設定 複数のアプリケーションを共有リソースとしてデプロイする場合、プロジェクトのプロパティファイルでプロパティを設定してはいけません。設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイするアプリケーション、そのドメイン、またはそのドメイン下の他のアプリケーションのスコープで環境変数を設定できます。 次の手順で、Studio で環境変数を設定する方法を説明します。これらの変数は、Studio からローカルでデプロイする場合のみ使用されます。アプリケーションをスタンドアロンサーバーにデプロイする場合、コマンドラインからこれらの変数を指定する必要があります。 1. **\[Run (実行)\]**​ で ​**\[Run Configurations (設定を実行)\]**​ を選択します。 2. 対応する実行設定を選択します。プロジェクトで実行設定が存在しない場合、\[new (新規)\] ボタンを使用して作成できます。 3. **\[Environment (環境)\]**​ タブを選択して、必要な変数を追加します。 作成した環境変数は、ドメインレベルで定義されます。これらの変数は、Studio を使用してローカルでデプロイしたときにそのドメインに関連付けられているすべてのアプリケーションに影響します。 環境変数の設定は、アプリケーションを Studio 内の Mule Runtime Engine で実行した場合のみ機能します。この設定は、DataSense、自動完了、検証などのデザインタイムの操作には影響しません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.7/shared-resources) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.7/configuring-properties) # 環境変数の設定 複数のアプリケーションを共有リソースとしてデプロイする場合、プロジェクトのプロパティファイルでプロパティを設定してはいけません。設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイするアプリケーション、そのドメイン、またはそのドメイン下の他のアプリケーションのスコープで環境変数を設定できます。 次の手順で、Studio で環境変数を設定する方法を説明します。これらの変数は、Studio からローカルでデプロイする場合のみ使用されます。アプリケーションをスタンドアロンサーバーにデプロイする場合、コマンドラインからこれらの変数を指定する必要があります。 1. **\[Run (実行)\]**​ で ​**\[Run Configurations (設定を実行)\]**​ を選択します。 2. 対応する実行設定を選択します。プロジェクトで実行設定が存在しない場合、\[new (新規)\] ボタンを使用して作成できます。 3. **\[Environment (環境)\]**​ タブを選択して、必要な変数を追加します。 作成した環境変数は、ドメインレベルで定義されます。これらの変数は、Studio を使用してローカルでデプロイしたときにそのドメインに関連付けられているすべてのアプリケーションに影響します。 環境変数の設定は、アプリケーションを Studio 内の Mule Runtime Engine で実行した場合のみ機能します。この設定は、DataSense、自動完了、検証などのデザインタイムの操作には影響しません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.8/shared-resources) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.8/configuring-properties) # 環境変数の設定 複数のアプリケーションを共有リソースとしてデプロイする場合、プロジェクトのプロパティファイルでプロパティを設定してはいけません。設定すると、ドメインを共有するさまざまなアプリケーション間で競合が起こる可能性があります。代わりに、デプロイするアプリケーション、そのドメイン、またはそのドメイン下の他のアプリケーションのスコープで環境変数を設定できます。 次の手順で、Studio で環境変数を設定する方法を説明します。これらの変数は、Studio からローカルでデプロイする場合のみ使用されます。アプリケーションをスタンドアロンサーバーにデプロイする場合、コマンドラインからこれらの変数を指定する必要があります。 1. **\[Run (実行)\]**​ で ​**\[Run Configurations (設定を実行)\]**​ を選択します。 2. 対応する実行設定を選択します。プロジェクトで実行設定が存在しない場合、\[new (新規)\] ボタンを使用して作成できます。 3. **\[Environment (環境)\]**​ タブを選択して、必要な変数を追加します。 作成した環境変数は、ドメインレベルで定義されます。これらの変数は、Studio を使用してローカルでデプロイしたときにそのドメインに関連付けられているすべてのアプリケーションに影響します。 環境変数の設定は、アプリケーションを Studio 内の Mule Runtime Engine で実行した場合のみ機能します。この設定は、DataSense、自動完了、検証などのデザインタイムの操作には影響しません。 ## [](#関連情報)関連情報 - [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.9/shared-resources) - [プロパティの設定](https://docs.mulesoft.com/jp/mule-runtime/4.9/configuring-properties) # 継続的インテグレーション プロジェクトの継続的インテグレーション (CI) のニーズは、非常に重要です。Maven をビルドツールとして使用すると、プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行できます。 CI の利点は次のとおりです。 - ソフトウェア開発ライフサイクルの問題を早期の通知できる。 - リリース前にコードを完全にテストできる。 - 適切にテストされた分岐により、メイン分岐へのマージに成功しやすくなる。 ## [](#継続的インテグレーションの目的)継続的インテグレーションの目的 CI システムは、次のすべての作業を行います。 1. プロジェクトのソースコード管理システムへの新規コミットをリスンする。CI システムは、多数の分岐の新規コミットを監視します。ポーリングを使用して新規コミットを検索したり、管理システムでコミットをプログラムに通知するイベントをトリガーしたりできます。 2. 最新の分岐を中央サーバーに取り込む。 3. 中央サーバーでビルドジョブを作成する。 4. Sandbox でプロジェクトをコンパイル、テスト、パッケージ化、デプロイしてプロジェクトが正常に機能することを確認する設定可能な単体テストとインテグレーションテストをコードベースで実行する。 5. リポジトリにアーティファクトを保存する。 6. 各ビルドの結果を表示する。 7. ビルドを本番にデプロイする。 これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#mulesoft-ci-ツール)MuleSoft CI ツール 以下を使用して、Mule アプリケーションをデプロイできます。 - [API Manager](https://docs.mulesoft.com/jp/api-manager/latest/getting-started-proxy) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/)​を使用して、機能テストを作成できます。 mule-maven-plugin では、以下へのデプロイメントがサポートされています。 - CloudHub - Runtime Fabric - オンプレミス Mule インスタンス - スタンドアロンデプロイメント - Anypoint Runtime Manager REST API の使用 - Runtime Manager エージェントの使用 Jenkins や Maven を使用する CI の完全な例については、 [MuleSoft トレーニングサイト](https://training.mulesoft.com/course-catalog)​の「Anypoint Platform Development: Advanced (Anypoint Platform 開発: 上級)」クラスを参照してください。トレーニングサイトには、関連するクラスや認定試験もあります。 ## [](#外部-ci-ツール)外部 CI ツール 一般的な CI ツールを次に示します。 - Jenkins - Hudson - TeamCity - Bamboo これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#インテグレーションの注意事項)インテグレーションの注意事項 機能テストケースでコネクタを使用する場合、継続的なビルドサーバーで発生する可能性のある潜在的なポートの競合に注意してください。 デプロイ可能な対象が Mule アプリケーションではなく Web アプリケーションの場合、Junit インテグレーションテストランナーを使用して機能テストを実行し、ポートの競合を回避することを検討してください。 ## [](#関連情報)関連情報 - [Mule での Maven のサポート](https://docs.mulesoft.com/jp/mule-runtime/4.3/using-maven-with-mule) - [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/) # 継続的インテグレーション プロジェクトの継続的インテグレーション (CI) のニーズは、非常に重要です。Maven をビルドツールとして使用すると、プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行できます。 CI の利点は次のとおりです。 - ソフトウェア開発ライフサイクルの問題を早期の通知できる。 - リリース前にコードを完全にテストできる。 - 適切にテストされた分岐により、メイン分岐へのマージに成功しやすくなる。 ## [](#継続的インテグレーションの目的)継続的インテグレーションの目的 CI システムは、次のすべての作業を行います。 1. プロジェクトのソースコード管理システムへの新規コミットをリスンする。CI システムは、多数の分岐の新規コミットを監視します。ポーリングを使用して新規コミットを検索したり、管理システムでコミットをプログラムに通知するイベントをトリガーしたりできます。 2. 最新の分岐を中央サーバーに取り込む。 3. 中央サーバーでビルドジョブを作成する。 4. Sandbox でプロジェクトをコンパイル、テスト、パッケージ化、デプロイしてプロジェクトが正常に機能することを確認する設定可能な単体テストとインテグレーションテストをコードベースで実行する。 5. リポジトリにアーティファクトを保存する。 6. 各ビルドの結果を表示する。 7. ビルドを本番にデプロイする。 これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#mulesoft-ci-ツール)MuleSoft CI ツール 以下を使用して、Mule アプリケーションをデプロイできます。 - [API Manager](https://docs.mulesoft.com/jp/api-manager/latest/getting-started-proxy) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/)​を使用して、機能テストを作成できます。 mule-maven-plugin では、以下へのデプロイメントがサポートされています。 - CloudHub - Runtime Fabric - オンプレミス Mule インスタンス - スタンドアロンデプロイメント - Anypoint Runtime Manager REST API の使用 - Runtime Manager エージェントの使用 Jenkins や Maven を使用する CI の完全な例については、 [MuleSoft トレーニングサイト](https://training.mulesoft.com/course-catalog)​の「Anypoint Platform Development: Advanced (Anypoint Platform 開発: 上級)」クラスを参照してください。トレーニングサイトには、関連するクラスや認定試験もあります。 ## [](#外部-ci-ツール)外部 CI ツール 一般的な CI ツールを次に示します。 - Jenkins - Hudson - TeamCity - Bamboo これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#インテグレーションの注意事項)インテグレーションの注意事項 機能テストケースでコネクタを使用する場合、継続的なビルドサーバーで発生する可能性のある潜在的なポートの競合に注意してください。 デプロイ可能な対象が Mule アプリケーションではなく Web アプリケーションの場合、Junit インテグレーションテストランナーを使用して機能テストを実行し、ポートの競合を回避することを検討してください。 ## [](#関連情報)関連情報 - [Mule での Maven のサポート](https://docs.mulesoft.com/jp/mule-runtime/4.4/using-maven-with-mule) - [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/) # 継続的インテグレーション プロジェクトの継続的インテグレーション (CI) のニーズは、非常に重要です。Maven をビルドツールとして使用すると、プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行できます。 CI の利点は次のとおりです。 - ソフトウェア開発ライフサイクルの問題を早期の通知できる。 - リリース前にコードを完全にテストできる。 - 適切にテストされた分岐により、メイン分岐へのマージに成功しやすくなる。 ## [](#継続的インテグレーションの目的)継続的インテグレーションの目的 CI システムは、次のすべての作業を行います。 1. プロジェクトのソースコード管理システムへの新規コミットをリスンする。CI システムは、多数の分岐の新規コミットを監視します。ポーリングを使用して新規コミットを検索したり、管理システムでコミットをプログラムに通知するイベントをトリガーしたりできます。 2. 最新の分岐を中央サーバーに取り込む。 3. 中央サーバーでビルドジョブを作成する。 4. Sandbox でプロジェクトをコンパイル、テスト、パッケージ化、デプロイしてプロジェクトが正常に機能することを確認する設定可能な単体テストとインテグレーションテストをコードベースで実行する。 5. リポジトリにアーティファクトを保存する。 6. 各ビルドの結果を表示する。 7. ビルドを本番にデプロイする。 これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#mulesoft-ci-ツール)MuleSoft CI ツール 以下を使用して、Mule アプリケーションをデプロイできます。 - [API Manager](https://docs.mulesoft.com/jp/api-manager/latest/getting-started-proxy) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/)​を使用して、機能テストを作成できます。 mule-maven-plugin では、以下へのデプロイメントがサポートされています。 - CloudHub - Runtime Fabric - オンプレミス Mule インスタンス - スタンドアロンデプロイメント - Anypoint Runtime Manager REST API の使用 - Runtime Manager エージェントの使用 Jenkins や Maven を使用する CI の完全な例については、 [MuleSoft トレーニングサイト](https://training.mulesoft.com/course-catalog)​の「Anypoint Platform Development: Advanced (Anypoint Platform 開発: 上級)」クラスを参照してください。トレーニングサイトには、関連するクラスや認定試験もあります。 ## [](#外部-ci-ツール)外部 CI ツール 一般的な CI ツールを次に示します。 - Jenkins - Hudson - TeamCity - Bamboo これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#インテグレーションの注意事項)インテグレーションの注意事項 機能テストケースでコネクタを使用する場合、継続的なビルドサーバーで発生する可能性のある潜在的なポートの競合に注意してください。 デプロイ可能な対象が Mule アプリケーションではなく Web アプリケーションの場合、Junit インテグレーションテストランナーを使用して機能テストを実行し、ポートの競合を回避することを検討してください。 ## [](#関連情報)関連情報 - [Mule での Maven のサポート](https://docs.mulesoft.com/jp/mule-runtime/4.5/using-maven-with-mule) - [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/) # 継続的インテグレーション プロジェクトの継続的インテグレーション (CI) のニーズは、非常に重要です。Maven をビルドツールとして使用すると、プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行できます。 CI の利点は次のとおりです。 - ソフトウェア開発ライフサイクルの問題を早期の通知できる。 - リリース前にコードを完全にテストできる。 - 適切にテストされた分岐により、メイン分岐へのマージに成功しやすくなる。 ## [](#継続的インテグレーションの目的)継続的インテグレーションの目的 CI システムは、次のすべての作業を行います。 1. プロジェクトのソースコード管理システムへの新規コミットをリスンする。CI システムは、多数の分岐の新規コミットを監視します。ポーリングを使用して新規コミットを検索したり、管理システムでコミットをプログラムに通知するイベントをトリガーしたりできます。 2. 最新の分岐を中央サーバーに取り込む。 3. 中央サーバーでビルドジョブを作成する。 4. Sandbox でプロジェクトをコンパイル、テスト、パッケージ化、デプロイしてプロジェクトが正常に機能することを確認する設定可能な単体テストとインテグレーションテストをコードベースで実行する。 5. リポジトリにアーティファクトを保存する。 6. 各ビルドの結果を表示する。 7. ビルドを本番にデプロイする。 これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#mulesoft-ci-ツール)MuleSoft CI ツール 以下を使用して、Mule アプリケーションをデプロイできます。 - [API Manager](https://docs.mulesoft.com/jp/api-manager/latest/getting-started-proxy) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/)​を使用して、機能テストを作成できます。 mule-maven-plugin では、以下へのデプロイメントがサポートされています。 - CloudHub - Runtime Fabric - オンプレミス Mule インスタンス - スタンドアロンデプロイメント - Anypoint Runtime Manager REST API の使用 - Runtime Manager エージェントの使用 Jenkins や Maven を使用する CI の完全な例については、 [MuleSoft トレーニングサイト](https://training.mulesoft.com/course-catalog)​の「Anypoint Platform Development: Advanced (Anypoint Platform 開発: 上級)」クラスを参照してください。トレーニングサイトには、関連するクラスや認定試験もあります。 ## [](#外部-ci-ツール)外部 CI ツール 一般的な CI ツールを次に示します。 - Jenkins - Hudson - TeamCity - Bamboo これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#インテグレーションの注意事項)インテグレーションの注意事項 機能テストケースでコネクタを使用する場合、継続的なビルドサーバーで発生する可能性のある潜在的なポートの競合に注意してください。 デプロイ可能な対象が Mule アプリケーションではなく Web アプリケーションの場合、Junit インテグレーションテストランナーを使用して機能テストを実行し、ポートの競合を回避することを検討してください。 ## [](#関連情報)関連情報 - [Mule での Maven のサポート](https://docs.mulesoft.com/jp/mule-runtime/4.6/using-maven-with-mule) - [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/) # 継続的インテグレーション プロジェクトの継続的インテグレーション (CI) のニーズは、非常に重要です。Maven をビルドツールとして使用すると、プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行できます。 CI の利点は次のとおりです。 - ソフトウェア開発ライフサイクルの問題を早期の通知できる。 - リリース前にコードを完全にテストできる。 - 適切にテストされた分岐により、メイン分岐へのマージに成功しやすくなる。 ## [](#継続的インテグレーションの目的)継続的インテグレーションの目的 CI システムは、次のすべての作業を行います。 1. プロジェクトのソースコード管理システムへの新規コミットをリスンする。CI システムは、多数の分岐の新規コミットを監視します。ポーリングを使用して新規コミットを検索したり、管理システムでコミットをプログラムに通知するイベントをトリガーしたりできます。 2. 最新の分岐を中央サーバーに取り込む。 3. 中央サーバーでビルドジョブを作成する。 4. Sandbox でプロジェクトをコンパイル、テスト、パッケージ化、デプロイしてプロジェクトが正常に機能することを確認する設定可能な単体テストとインテグレーションテストをコードベースで実行する。 5. リポジトリにアーティファクトを保存する。 6. 各ビルドの結果を表示する。 7. ビルドを本番にデプロイする。 これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#mulesoft-ci-ツール)MuleSoft CI ツール 以下を使用して、Mule アプリケーションをデプロイできます。 - [API Manager](https://docs.mulesoft.com/jp/api-manager/latest/getting-started-proxy) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/)​を使用して、機能テストを作成できます。 mule-maven-plugin では、以下へのデプロイメントがサポートされています。 - CloudHub - Runtime Fabric - オンプレミス Mule インスタンス - スタンドアロンデプロイメント - Anypoint Runtime Manager REST API の使用 - Runtime Manager エージェントの使用 Jenkins や Maven を使用する CI の完全な例については、 [MuleSoft トレーニングサイト](https://training.mulesoft.com/course-catalog)​の「Anypoint Platform Development: Advanced (Anypoint Platform 開発: 上級)」クラスを参照してください。トレーニングサイトには、関連するクラスや認定試験もあります。 ## [](#外部-ci-ツール)外部 CI ツール 一般的な CI ツールを次に示します。 - Jenkins - Hudson - TeamCity - Bamboo これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#インテグレーションの注意事項)インテグレーションの注意事項 機能テストケースでコネクタを使用する場合、継続的なビルドサーバーで発生する可能性のある潜在的なポートの競合に注意してください。 デプロイ可能な対象が Mule アプリケーションではなく Web アプリケーションの場合、Junit インテグレーションテストランナーを使用して機能テストを実行し、ポートの競合を回避することを検討してください。 ## [](#関連情報)関連情報 - [Mule での Maven のサポート](https://docs.mulesoft.com/jp/mule-runtime/4.7/using-maven-with-mule) - [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/) # 継続的インテグレーション プロジェクトの継続的インテグレーション (CI) のニーズは、非常に重要です。Maven をビルドツールとして使用すると、プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行できます。 CI の利点は次のとおりです。 - ソフトウェア開発ライフサイクルの問題を早期の通知できる。 - リリース前にコードを完全にテストできる。 - 適切にテストされた分岐により、メイン分岐へのマージに成功しやすくなる。 ## [](#継続的インテグレーションの目的)継続的インテグレーションの目的 CI システムは、次のすべての作業を行います。 1. プロジェクトのソースコード管理システムへの新規コミットをリスンする。CI システムは、多数の分岐の新規コミットを監視します。ポーリングを使用して新規コミットを検索したり、管理システムでコミットをプログラムに通知するイベントをトリガーしたりできます。 2. 最新の分岐を中央サーバーに取り込む。 3. 中央サーバーでビルドジョブを作成する。 4. Sandbox でプロジェクトをコンパイル、テスト、パッケージ化、デプロイしてプロジェクトが正常に機能することを確認する設定可能な単体テストとインテグレーションテストをコードベースで実行する。 5. リポジトリにアーティファクトを保存する。 6. 各ビルドの結果を表示する。 7. ビルドを本番にデプロイする。 これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#mulesoft-ci-ツール)MuleSoft CI ツール 以下を使用して、Mule アプリケーションをデプロイできます。 - [API Manager](https://docs.mulesoft.com/jp/api-manager/latest/getting-started-proxy) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/)​を使用して、機能テストを作成できます。 mule-maven-plugin では、以下へのデプロイメントがサポートされています。 - CloudHub - Runtime Fabric - オンプレミス Mule インスタンス - スタンドアロンデプロイメント - Anypoint Runtime Manager REST API の使用 - Runtime Manager エージェントの使用 Jenkins や Maven を使用する CI の完全な例については、 [MuleSoft トレーニングサイト](https://training.mulesoft.com/course-catalog)​の「Anypoint Platform Development: Advanced (Anypoint Platform 開発: 上級)」クラスを参照してください。トレーニングサイトには、関連するクラスや認定試験もあります。 ## [](#外部-ci-ツール)外部 CI ツール 一般的な CI ツールを次に示します。 - Jenkins - Hudson - TeamCity - Bamboo これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#インテグレーションの注意事項)インテグレーションの注意事項 機能テストケースでコネクタを使用する場合、継続的なビルドサーバーで発生する可能性のある潜在的なポートの競合に注意してください。 デプロイ可能な対象が Mule アプリケーションではなく Web アプリケーションの場合、Junit インテグレーションテストランナーを使用して機能テストを実行し、ポートの競合を回避することを検討してください。 ## [](#関連情報)関連情報 - [Mule での Maven のサポート](https://docs.mulesoft.com/jp/mule-runtime/4.8/using-maven-with-mule) - [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/) # 継続的インテグレーション プロジェクトの継続的インテグレーション (CI) のニーズは、非常に重要です。Maven をビルドツールとして使用すると、プロジェクトの変更ごとにトリガーされるビルドを作成し、その単体テストと機能テストをすべて自動的に実行できます。 CI の利点は次のとおりです。 - ソフトウェア開発ライフサイクルの問題を早期の通知できる。 - リリース前にコードを完全にテストできる。 - 適切にテストされた分岐により、メイン分岐へのマージに成功しやすくなる。 ## [](#継続的インテグレーションの目的)継続的インテグレーションの目的 CI システムは、次のすべての作業を行います。 1. プロジェクトのソースコード管理システムへの新規コミットをリスンする。CI システムは、多数の分岐の新規コミットを監視します。ポーリングを使用して新規コミットを検索したり、管理システムでコミットをプログラムに通知するイベントをトリガーしたりできます。 2. 最新の分岐を中央サーバーに取り込む。 3. 中央サーバーでビルドジョブを作成する。 4. Sandbox でプロジェクトをコンパイル、テスト、パッケージ化、デプロイしてプロジェクトが正常に機能することを確認する設定可能な単体テストとインテグレーションテストをコードベースで実行する。 5. リポジトリにアーティファクトを保存する。 6. 各ビルドの結果を表示する。 7. ビルドを本番にデプロイする。 これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#mulesoft-ci-ツール)MuleSoft CI ツール 以下を使用して、Mule アプリケーションをデプロイできます。 - [API Manager](https://docs.mulesoft.com/jp/api-manager/latest/getting-started-proxy) - [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent) [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/)​を使用して、機能テストを作成できます。 mule-maven-plugin では、以下へのデプロイメントがサポートされています。 - CloudHub - Runtime Fabric - オンプレミス Mule インスタンス - スタンドアロンデプロイメント - Anypoint Runtime Manager REST API の使用 - Runtime Manager エージェントの使用 Jenkins や Maven を使用する CI の完全な例については、 [MuleSoft トレーニングサイト](https://training.mulesoft.com/course-catalog)​の「Anypoint Platform Development: Advanced (Anypoint Platform 開発: 上級)」クラスを参照してください。トレーニングサイトには、関連するクラスや認定試験もあります。 ## [](#外部-ci-ツール)外部 CI ツール 一般的な CI ツールを次に示します。 - Jenkins - Hudson - TeamCity - Bamboo これらのツールについては、それぞれの Web サイトを参照してください。 ## [](#インテグレーションの注意事項)インテグレーションの注意事項 機能テストケースでコネクタを使用する場合、継続的なビルドサーバーで発生する可能性のある潜在的なポートの競合に注意してください。 デプロイ可能な対象が Mule アプリケーションではなく Web アプリケーションの場合、Junit インテグレーションテストランナーを使用して機能テストを実行し、ポートの競合を回避することを検討してください。 ## [](#関連情報)関連情報 - [Mule での Maven のサポート](https://docs.mulesoft.com/jp/mule-runtime/4.9/using-maven-with-mule) - [MUnit 単体テスト](https://docs.mulesoft.com/munit/latest/) # 設定ファイルのモジュール化 Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。そのため、単体の設定を複数のファイルに分割し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込むことをお勧めします。 設定を複数のファイルに分割すると、チーム間で再利用しやすくなります。 Mule には、複数の設定ファイルを読み込む方法が 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートできるようにします。 実際には、両方の手法を同時に使用するのが一般的です。 設定ファイルは同じコンテキストで読み込まれるため、設定要素に一意の名前を使用する必要があります。設定ファイルで名前が競合している場合、Mule はアプリケーションを読み込みません。 どのような場合に設定要素を複数のファイルに分割して、どの要素をまとめておくかを判断するお勧めの方法をいくつか紹介します。 - ビジネスドメインは通常自然な境界となり、これを使用して設定要素を分割できます。 - 似たような理由で変更された要素はまとめておきます。これにより、アプリケーションの関連性の低い側面に影響を及ぼすリスクが低減されます。 - 管理コンポーネント、セキュリティ、外部システム設定などの技術的要素は境界として適しています。 - 機能テストをしやすくするため、サイドバイサイドコネクタ設定を分離します。 (この推奨は、プロパティファイルを使用する環境固有のコネクタ設定には適用されません)。 - 設定要素を分離する場合はチームおよびプロジェクト間で再利用することを検討します。
デフォルトでは、Mule はアプリケーションをサイドバイサイド方式でパッケージ化して読み込むときにすべての XML 設定ファイルを設定として扱います。
## [](#インポートされた設定ファイル)インポートされた設定ファイル Mule には、設定ファイルを相互にインポートするための専用の ​`import`​ 設定コンポーネントがあります。このコンポーネントは ​`file`​ パラメーターを取り、このパラメーターには目的の設定ファイルへの参照が含まれています。 次の例は、他の 3 つの設定要素 ​`global-configurations.xml`​、​`admin-config.xml`​、​`audit-flows.xml`​ をインポートするメインの設定ファイルを示しています。 ```xml ```
このインポートメカニズムを使用するには、XML ファイルがクラスパスにあることが必要です。
## [](#関連情報)関連情報 - [Mule 4 の概要: アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.3/intro-packaging) # 設定ファイルのモジュール化 Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。そのため、単体の設定を複数のファイルに分割し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込むことをお勧めします。 設定を複数のファイルに分割すると、チーム間で再利用しやすくなります。 Mule には、複数の設定ファイルを読み込む方法が 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートできるようにします。 実際には、両方の手法を同時に使用するのが一般的です。 設定ファイルは同じコンテキストで読み込まれるため、設定要素に一意の名前を使用する必要があります。設定ファイルで名前が競合している場合、Mule はアプリケーションを読み込みません。 どのような場合に設定要素を複数のファイルに分割して、どの要素をまとめておくかを判断するお勧めの方法をいくつか紹介します。 - ビジネスドメインは通常自然な境界となり、これを使用して設定要素を分割できます。 - 似たような理由で変更された要素はまとめておきます。これにより、アプリケーションの関連性の低い側面に影響を及ぼすリスクが低減されます。 - 管理コンポーネント、セキュリティ、外部システム設定などの技術的要素は境界として適しています。 - 機能テストをしやすくするため、サイドバイサイドコネクタ設定を分離します。 (この推奨は、プロパティファイルを使用する環境固有のコネクタ設定には適用されません)。 - 設定要素を分離する場合はチームおよびプロジェクト間で再利用することを検討します。
デフォルトでは、Mule はアプリケーションをサイドバイサイド方式でパッケージ化して読み込むときにすべての XML 設定ファイルを設定として扱います。
## [](#インポートされた設定ファイル)インポートされた設定ファイル Mule には、設定ファイルを相互にインポートするための専用の ​`import`​ 設定コンポーネントがあります。このコンポーネントは ​`file`​ パラメーターを取り、このパラメーターには目的の設定ファイルへの参照が含まれています。 次の例は、他の 3 つの設定要素 ​`global-configurations.xml`​、​`admin-config.xml`​、​`audit-flows.xml`​ をインポートするメインの設定ファイルを示しています。 ```xml ```
このインポートメカニズムを使用するには、XML ファイルがクラスパスにあることが必要です。
## [](#関連情報)関連情報 - [Mule 4 の概要: アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.4/intro-packaging) # 設定ファイルのモジュール化 Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。そのため、単体の設定を複数のファイルに分割し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込むことをお勧めします。 設定を複数のファイルに分割すると、チーム間で再利用しやすくなります。 Mule には、複数の設定ファイルを読み込む方法が 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートできるようにします。 実際には、両方の手法を同時に使用するのが一般的です。 設定ファイルは同じコンテキストで読み込まれるため、設定要素に一意の名前を使用する必要があります。設定ファイルで名前が競合している場合、Mule はアプリケーションを読み込みません。 どのような場合に設定要素を複数のファイルに分割して、どの要素をまとめておくかを判断するお勧めの方法をいくつか紹介します。 - ビジネスドメインは通常自然な境界となり、これを使用して設定要素を分割できます。 - 似たような理由で変更された要素はまとめておきます。これにより、アプリケーションの関連性の低い側面に影響を及ぼすリスクが低減されます。 - 管理コンポーネント、セキュリティ、外部システム設定などの技術的要素は境界として適しています。 - 機能テストをしやすくするため、サイドバイサイドコネクタ設定を分離します。 (この推奨は、プロパティファイルを使用する環境固有のコネクタ設定には適用されません)。 - 設定要素を分離する場合はチームおよびプロジェクト間で再利用することを検討します。
デフォルトでは、Mule はアプリケーションをサイドバイサイド方式でパッケージ化して読み込むときにすべての XML 設定ファイルを設定として扱います。
## [](#インポートされた設定ファイル)インポートされた設定ファイル Mule には、設定ファイルを相互にインポートするための専用の ​`import`​ 設定コンポーネントがあります。このコンポーネントは ​`file`​ パラメーターを取り、このパラメーターには目的の設定ファイルへの参照が含まれています。 次の例は、他の 3 つの設定要素 ​`global-configurations.xml`​、​`admin-config.xml`​、​`audit-flows.xml`​ をインポートするメインの設定ファイルを示しています。 ```xml ```
このインポートメカニズムを使用するには、XML ファイルがクラスパスにあることが必要です。
## [](#関連情報)関連情報 - [Mule 4 の概要: アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.5/intro-packaging) # 設定ファイルのモジュール化 Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。そのため、単体の設定を複数のファイルに分割し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込むことをお勧めします。 設定を複数のファイルに分割すると、チーム間で再利用しやすくなります。 Mule には、複数の設定ファイルを読み込む方法が 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートできるようにします。 実際には、両方の手法を同時に使用するのが一般的です。 設定ファイルは同じコンテキストで読み込まれるため、設定要素に一意の名前を使用する必要があります。設定ファイルで名前が競合している場合、Mule はアプリケーションを読み込みません。 どのような場合に設定要素を複数のファイルに分割して、どの要素をまとめておくかを判断するお勧めの方法をいくつか紹介します。 - ビジネスドメインは通常自然な境界となり、これを使用して設定要素を分割できます。 - 似たような理由で変更された要素はまとめておきます。これにより、アプリケーションの関連性の低い側面に影響を及ぼすリスクが低減されます。 - 管理コンポーネント、セキュリティ、外部システム設定などの技術的要素は境界として適しています。 - 機能テストをしやすくするため、サイドバイサイドコネクタ設定を分離します。 (この推奨は、プロパティファイルを使用する環境固有のコネクタ設定には適用されません)。 - 設定要素を分離する場合はチームおよびプロジェクト間で再利用することを検討します。
デフォルトでは、Mule はアプリケーションをサイドバイサイド方式でパッケージ化して読み込むときにすべての XML 設定ファイルを設定として扱います。
## [](#インポートされた設定ファイル)インポートされた設定ファイル Mule には、設定ファイルを相互にインポートするための専用の ​`import`​ 設定コンポーネントがあります。このコンポーネントは ​`file`​ パラメーターを取り、このパラメーターには目的の設定ファイルへの参照が含まれています。 次の例は、他の 3 つの設定要素 ​`global-configurations.xml`​、​`admin-config.xml`​、​`audit-flows.xml`​ をインポートするメインの設定ファイルを示しています。 ```xml ```
このインポートメカニズムを使用するには、XML ファイルがクラスパスにあることが必要です。
## [](#関連情報)関連情報 - [Mule 4 の概要: アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.6/intro-packaging) # 設定ファイルのモジュール化 Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。そのため、単体の設定を複数のファイルに分割し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込むことをお勧めします。 設定を複数のファイルに分割すると、チーム間で再利用しやすくなります。 Mule には、複数の設定ファイルを読み込む方法が 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートできるようにします。 実際には、両方の手法を同時に使用するのが一般的です。 設定ファイルは同じコンテキストで読み込まれるため、設定要素に一意の名前を使用する必要があります。設定ファイルで名前が競合している場合、Mule はアプリケーションを読み込みません。 どのような場合に設定要素を複数のファイルに分割して、どの要素をまとめておくかを判断するお勧めの方法をいくつか紹介します。 - ビジネスドメインは通常自然な境界となり、これを使用して設定要素を分割できます。 - 似たような理由で変更された要素はまとめておきます。これにより、アプリケーションの関連性の低い側面に影響を及ぼすリスクが低減されます。 - 管理コンポーネント、セキュリティ、外部システム設定などの技術的要素は境界として適しています。 - 機能テストをしやすくするため、サイドバイサイドコネクタ設定を分離します。 (この推奨は、プロパティファイルを使用する環境固有のコネクタ設定には適用されません)。 - 設定要素を分離する場合はチームおよびプロジェクト間で再利用することを検討します。
デフォルトでは、Mule はアプリケーションをサイドバイサイド方式でパッケージ化して読み込むときにすべての XML 設定ファイルを設定として扱います。
## [](#インポートされた設定ファイル)インポートされた設定ファイル Mule には、設定ファイルを相互にインポートするための専用の ​`import`​ 設定コンポーネントがあります。このコンポーネントは ​`file`​ パラメーターを取り、このパラメーターには目的の設定ファイルへの参照が含まれています。 次の例は、他の 3 つの設定要素 ​`global-configurations.xml`​、​`admin-config.xml`​、​`audit-flows.xml`​ をインポートするメインの設定ファイルを示しています。 ```xml ```
このインポートメカニズムを使用するには、XML ファイルがクラスパスにあることが必要です。
## [](#関連情報)関連情報 - [Mule 4 の概要: アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-packaging) # 設定ファイルのモジュール化 Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。そのため、単体の設定を複数のファイルに分割し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込むことをお勧めします。 設定を複数のファイルに分割すると、チーム間で再利用しやすくなります。 Mule には、複数の設定ファイルを読み込む方法が 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートできるようにします。 実際には、両方の手法を同時に使用するのが一般的です。 設定ファイルは同じコンテキストで読み込まれるため、設定要素に一意の名前を使用する必要があります。設定ファイルで名前が競合している場合、Mule はアプリケーションを読み込みません。 どのような場合に設定要素を複数のファイルに分割して、どの要素をまとめておくかを判断するお勧めの方法をいくつか紹介します。 - ビジネスドメインは通常自然な境界となり、これを使用して設定要素を分割できます。 - 似たような理由で変更された要素はまとめておきます。これにより、アプリケーションの関連性の低い側面に影響を及ぼすリスクが低減されます。 - 管理コンポーネント、セキュリティ、外部システム設定などの技術的要素は境界として適しています。 - 機能テストをしやすくするため、サイドバイサイドコネクタ設定を分離します。 (この推奨は、プロパティファイルを使用する環境固有のコネクタ設定には適用されません)。 - 設定要素を分離する場合はチームおよびプロジェクト間で再利用することを検討します。
デフォルトでは、Mule はアプリケーションをサイドバイサイド方式でパッケージ化して読み込むときにすべての XML 設定ファイルを設定として扱います。
## [](#インポートされた設定ファイル)インポートされた設定ファイル Mule には、設定ファイルを相互にインポートするための専用の ​`import`​ 設定コンポーネントがあります。このコンポーネントは ​`file`​ パラメーターを取り、このパラメーターには目的の設定ファイルへの参照が含まれています。 次の例は、他の 3 つの設定要素 ​`global-configurations.xml`​、​`admin-config.xml`​、​`audit-flows.xml`​ をインポートするメインの設定ファイルを示しています。 ```xml ```
このインポートメカニズムを使用するには、XML ファイルがクラスパスにあることが必要です。
## [](#関連情報)関連情報 - [Mule 4 の概要: アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.8/intro-packaging) # 設定ファイルのモジュール化 Mule 設定を 1 つのファイルにまとめるのは便利そうに思えるかもしれませんが、XML ファイルが大きすぎると急激に管理しにくくなります。そのため、単体の設定を複数のファイルに分割し、Mule の容量を利用してアプリケーションの起動時に複数の設定ファイルを読み込むことをお勧めします。 設定を複数のファイルに分割すると、チーム間で再利用しやすくなります。 Mule には、複数の設定ファイルを読み込む方法が 2 つあります。 - サイドバイサイド: 読み込む個別の設定ファイルのリストを提供します。 - インポート: 1 つの設定ファイルで複数のファイルをインポートし、次にインポートされたファイルで他のファイルをインポートできるようにします。 実際には、両方の手法を同時に使用するのが一般的です。 設定ファイルは同じコンテキストで読み込まれるため、設定要素に一意の名前を使用する必要があります。設定ファイルで名前が競合している場合、Mule はアプリケーションを読み込みません。 どのような場合に設定要素を複数のファイルに分割して、どの要素をまとめておくかを判断するお勧めの方法をいくつか紹介します。 - ビジネスドメインは通常自然な境界となり、これを使用して設定要素を分割できます。 - 似たような理由で変更された要素はまとめておきます。これにより、アプリケーションの関連性の低い側面に影響を及ぼすリスクが低減されます。 - 管理コンポーネント、セキュリティ、外部システム設定などの技術的要素は境界として適しています。 - 機能テストをしやすくするため、サイドバイサイドコネクタ設定を分離します。 (この推奨は、プロパティファイルを使用する環境固有のコネクタ設定には適用されません)。 - 設定要素を分離する場合はチームおよびプロジェクト間で再利用することを検討します。
デフォルトでは、Mule はアプリケーションをサイドバイサイド方式でパッケージ化して読み込むときにすべての XML 設定ファイルを設定として扱います。
## [](#インポートされた設定ファイル)インポートされた設定ファイル Mule には、設定ファイルを相互にインポートするための専用の ​`import`​ 設定コンポーネントがあります。このコンポーネントは ​`file`​ パラメーターを取り、このパラメーターには目的の設定ファイルへの参照が含まれています。 次の例は、他の 3 つの設定要素 ​`global-configurations.xml`​、​`admin-config.xml`​、​`audit-flows.xml`​ をインポートするメインの設定ファイルを示しています。 ```xml ```
このインポートメカニズムを使用するには、XML ファイルがクラスパスにあることが必要です。
## [](#関連情報)関連情報 - [Mule 4 の概要: アプリケーションのパッケージ化](https://docs.mulesoft.com/jp/mule-runtime/4.9/intro-packaging) # 通知設定リファレンス このトピックでは、通知のために設定する要素について詳しく説明します。通知についての詳細は、​[「Mule サーバーの通知」](https://docs.mulesoft.com/jp/mule-runtime/4.3/mule-server-notifications)​を参照してください。 ## [](#notifications-通知)Notifications (通知) 通知のためにリスナーを登録し、インターフェースを特定のイベントに関連付けます。 ### [](#通知の属性)通知の属性
名前 説明

dynamic

通知マネージャーが動的な場合、実行時に動的に登録されるようにリスナーをセットアップできます。それ以外の場合、効率のために Mule の一部で通知設定がキャッシュされ、新たに有効になった通知またはリスナーのためにイベントが生成されません。
型​: boolean
必須​: いいえ
デフォルト​: false
### [](#通知の子要素)通知の子要素 `notification`​ 要素と ​`disable-notification`​ 要素を使用してインターフェースとイベント間のリレーションを設定します。
名前 基数 説明

notification

0..*

イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。

disable-notification

0..*

特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​notification-listener​ などの他の要素よりも優先されます。

notification-listener

0..*

通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。
## [](#notification-通知)Notification (通知) イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。 ### [](#通知の属性-2)通知の属性
名前 説明

event-class

インターフェースに配信する通知イベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

配信する通知イベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

通知イベントを受信するインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

通知イベントを受信するインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`notification`​ の子要素はありません。 ## [](#通知の無効化)通知の無効化 特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​`notification-listener`​ などの他の要素よりも優先されます。 ### [](#disable-notification-の属性)disable-notification の属性
名前 説明

event-class

インターフェースに配信されなくなったイベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

もう配信しないイベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

イベントを受信しなくなったインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

イベントを受信しなくなったインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`disable-notification`​ の子要素はありません。 ## [](#通知リスナー)通知リスナー 通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。 ## [](#通知種別)通知種別 `notification`​ 要素と ​`disable-notification`​ 要素の ​`event`​ 属性を使用して、次の種別の通知を指定できます。 - ASYNC-MESSAGE - CONNECTION - CONNECTOR-MESSAGE - CONTEXT - CUSTOM - EXCEPTION - EXCEPTION-STRATEGY - MANAGEMENT - MESSAGE-PROCESSOR - PIPELINE-MESSAGE - ROUTING - SECURITY - TRANSACTION # 通知設定リファレンス このトピックでは、通知のために設定する要素について詳しく説明します。通知についての詳細は、​[「Mule サーバーの通知」](https://docs.mulesoft.com/jp/mule-runtime/4.4/mule-server-notifications)​を参照してください。 ## [](#notifications-通知)Notifications (通知) 通知のためにリスナーを登録し、インターフェースを特定のイベントに関連付けます。 ### [](#通知の属性)通知の属性
名前 説明

dynamic

通知マネージャーが動的な場合、実行時に動的に登録されるようにリスナーをセットアップできます。それ以外の場合、効率のために Mule の一部で通知設定がキャッシュされ、新たに有効になった通知またはリスナーのためにイベントが生成されません。
型​: boolean
必須​: いいえ
デフォルト​: false
### [](#通知の子要素)通知の子要素 `notification`​ 要素と ​`disable-notification`​ 要素を使用してインターフェースとイベント間のリレーションを設定します。
名前 基数 説明

notification

0..*

イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。

disable-notification

0..*

特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​notification-listener​ などの他の要素よりも優先されます。

notification-listener

0..*

通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。
## [](#notification-通知)Notification (通知) イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。 ### [](#通知の属性-2)通知の属性
名前 説明

event-class

インターフェースに配信する通知イベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

配信する通知イベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

通知イベントを受信するインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

通知イベントを受信するインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`notification`​ の子要素はありません。 ## [](#通知の無効化)通知の無効化 特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​`notification-listener`​ などの他の要素よりも優先されます。 ### [](#disable-notification-の属性)disable-notification の属性
名前 説明

event-class

インターフェースに配信されなくなったイベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

もう配信しないイベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

イベントを受信しなくなったインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

イベントを受信しなくなったインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`disable-notification`​ の子要素はありません。 ## [](#通知リスナー)通知リスナー 通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。 ## [](#通知種別)通知種別 `notification`​ 要素と ​`disable-notification`​ 要素の ​`event`​ 属性を使用して、次の種別の通知を指定できます。 - ASYNC-MESSAGE - CONNECTION - CONNECTOR-MESSAGE - CONTEXT - CUSTOM - EXCEPTION - EXCEPTION-STRATEGY - MANAGEMENT - MESSAGE-PROCESSOR - PIPELINE-MESSAGE - ROUTING - SECURITY - TRANSACTION # 通知設定リファレンス このトピックでは、通知のために設定する要素について詳しく説明します。通知についての詳細は、​[「Mule サーバーの通知」](https://docs.mulesoft.com/jp/mule-runtime/4.5/mule-server-notifications)​を参照してください。 ## [](#notifications-通知)Notifications (通知) 通知のためにリスナーを登録し、インターフェースを特定のイベントに関連付けます。 ### [](#通知の属性)通知の属性
名前 説明

dynamic

通知マネージャーが動的な場合、実行時に動的に登録されるようにリスナーをセットアップできます。それ以外の場合、効率のために Mule の一部で通知設定がキャッシュされ、新たに有効になった通知またはリスナーのためにイベントが生成されません。
型​: boolean
必須​: いいえ
デフォルト​: false
### [](#通知の子要素)通知の子要素 `notification`​ 要素と ​`disable-notification`​ 要素を使用してインターフェースとイベント間のリレーションを設定します。
名前 基数 説明

notification

0..*

イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。

disable-notification

0..*

特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​notification-listener​ などの他の要素よりも優先されます。

notification-listener

0..*

通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。
## [](#notification-通知)Notification (通知) イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。 ### [](#通知の属性-2)通知の属性
名前 説明

event-class

インターフェースに配信する通知イベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

配信する通知イベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

通知イベントを受信するインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

通知イベントを受信するインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`notification`​ の子要素はありません。 ## [](#通知の無効化)通知の無効化 特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​`notification-listener`​ などの他の要素よりも優先されます。 ### [](#disable-notification-の属性)disable-notification の属性
名前 説明

event-class

インターフェースに配信されなくなったイベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

もう配信しないイベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

イベントを受信しなくなったインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

イベントを受信しなくなったインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`disable-notification`​ の子要素はありません。 ## [](#通知リスナー)通知リスナー 通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。 ## [](#通知種別)通知種別 `notification`​ 要素と ​`disable-notification`​ 要素の ​`event`​ 属性を使用して、次の種別の通知を指定できます。 - ASYNC-MESSAGE - CONNECTION - CONNECTOR-MESSAGE - CONTEXT - CUSTOM - EXCEPTION - EXCEPTION-STRATEGY - MANAGEMENT - MESSAGE-PROCESSOR - PIPELINE-MESSAGE - ROUTING - SECURITY - TRANSACTION # 通知設定リファレンス このトピックでは、通知のために設定する要素について詳しく説明します。通知についての詳細は、​[「Mule サーバーの通知」](https://docs.mulesoft.com/jp/mule-runtime/4.6/mule-server-notifications)​を参照してください。 ## [](#notifications-通知)Notifications (通知) 通知のためにリスナーを登録し、インターフェースを特定のイベントに関連付けます。 ### [](#通知の属性)通知の属性
名前 説明

dynamic

通知マネージャーが動的な場合、実行時に動的に登録されるようにリスナーをセットアップできます。それ以外の場合、効率のために Mule の一部で通知設定がキャッシュされ、新たに有効になった通知またはリスナーのためにイベントが生成されません。
型​: boolean
必須​: いいえ
デフォルト​: false
### [](#通知の子要素)通知の子要素 `notification`​ 要素と ​`disable-notification`​ 要素を使用してインターフェースとイベント間のリレーションを設定します。
名前 基数 説明

notification

0..*

イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。

disable-notification

0..*

特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​notification-listener​ などの他の要素よりも優先されます。

notification-listener

0..*

通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。
## [](#notification-通知)Notification (通知) イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。 ### [](#通知の属性-2)通知の属性
名前 説明

event-class

インターフェースに配信する通知イベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

配信する通知イベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

通知イベントを受信するインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

通知イベントを受信するインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`notification`​ の子要素はありません。 ## [](#通知の無効化)通知の無効化 特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​`notification-listener`​ などの他の要素よりも優先されます。 ### [](#disable-notification-の属性)disable-notification の属性
名前 説明

event-class

インターフェースに配信されなくなったイベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

もう配信しないイベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

イベントを受信しなくなったインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

イベントを受信しなくなったインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`disable-notification`​ の子要素はありません。 ## [](#通知リスナー)通知リスナー 通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。 ## [](#通知種別)通知種別 `notification`​ 要素と ​`disable-notification`​ 要素の ​`event`​ 属性を使用して、次の種別の通知を指定できます。 - ASYNC-MESSAGE - CONNECTION - CONNECTOR-MESSAGE - CONTEXT - CUSTOM - EXCEPTION - EXCEPTION-STRATEGY - MANAGEMENT - MESSAGE-PROCESSOR - PIPELINE-MESSAGE - ROUTING - SECURITY - TRANSACTION # 通知設定リファレンス このトピックでは、通知のために設定する要素について詳しく説明します。通知についての詳細は、​[「Mule サーバーの通知」](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-server-notifications)​を参照してください。 ## [](#notifications-通知)Notifications (通知) 通知のためにリスナーを登録し、インターフェースを特定のイベントに関連付けます。 ### [](#通知の属性)通知の属性
名前 説明

dynamic

通知マネージャーが動的な場合、実行時に動的に登録されるようにリスナーをセットアップできます。それ以外の場合、効率のために Mule の一部で通知設定がキャッシュされ、新たに有効になった通知またはリスナーのためにイベントが生成されません。
型​: boolean
必須​: いいえ
デフォルト​: false
### [](#通知の子要素)通知の子要素 `notification`​ 要素と ​`disable-notification`​ 要素を使用してインターフェースとイベント間のリレーションを設定します。
名前 基数 説明

notification

0..*

イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。

disable-notification

0..*

特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​notification-listener​ などの他の要素よりも優先されます。

notification-listener

0..*

通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。
## [](#notification-通知)Notification (通知) イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。 ### [](#通知の属性-2)通知の属性
名前 説明

event-class

インターフェースに配信する通知イベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

配信する通知イベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

通知イベントを受信するインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

通知イベントを受信するインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`notification`​ の子要素はありません。 ## [](#通知の無効化)通知の無効化 特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​`notification-listener`​ などの他の要素よりも優先されます。 ### [](#disable-notification-の属性)disable-notification の属性
名前 説明

event-class

インターフェースに配信されなくなったイベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

もう配信しないイベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

イベントを受信しなくなったインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

イベントを受信しなくなったインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`disable-notification`​ の子要素はありません。 ## [](#通知リスナー)通知リスナー 通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。 ## [](#通知種別)通知種別 `notification`​ 要素と ​`disable-notification`​ 要素の ​`event`​ 属性を使用して、次の種別の通知を指定できます。 - ASYNC-MESSAGE - CONNECTION - CONNECTOR-MESSAGE - CONTEXT - CUSTOM - EXCEPTION - EXCEPTION-STRATEGY - MANAGEMENT - MESSAGE-PROCESSOR - PIPELINE-MESSAGE - ROUTING - SECURITY - TRANSACTION # 通知設定リファレンス このトピックでは、通知のために設定する要素について詳しく説明します。通知についての詳細は、​[「Mule サーバーの通知」](https://docs.mulesoft.com/jp/mule-runtime/4.8/mule-server-notifications)​を参照してください。 ## [](#notifications-通知)Notifications (通知) 通知のためにリスナーを登録し、インターフェースを特定のイベントに関連付けます。 ### [](#通知の属性)通知の属性
名前 説明

dynamic

通知マネージャーが動的な場合、実行時に動的に登録されるようにリスナーをセットアップできます。それ以外の場合、効率のために Mule の一部で通知設定がキャッシュされ、新たに有効になった通知またはリスナーのためにイベントが生成されません。
型​: boolean
必須​: いいえ
デフォルト​: false
### [](#通知の子要素)通知の子要素 `notification`​ 要素と ​`disable-notification`​ 要素を使用してインターフェースとイベント間のリレーションを設定します。
名前 基数 説明

notification

0..*

イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。

disable-notification

0..*

特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​notification-listener​ などの他の要素よりも優先されます。

notification-listener

0..*

通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。
## [](#notification-通知)Notification (通知) イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。 ### [](#通知の属性-2)通知の属性
名前 説明

event-class

インターフェースに配信する通知イベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

配信する通知イベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

通知イベントを受信するインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

通知イベントを受信するインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`notification`​ の子要素はありません。 ## [](#通知の無効化)通知の無効化 特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​`notification-listener`​ などの他の要素よりも優先されます。 ### [](#disable-notification-の属性)disable-notification の属性
名前 説明

event-class

インターフェースに配信されなくなったイベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

もう配信しないイベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

イベントを受信しなくなったインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

イベントを受信しなくなったインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`disable-notification`​ の子要素はありません。 ## [](#通知リスナー)通知リスナー 通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。 ## [](#通知種別)通知種別 `notification`​ 要素と ​`disable-notification`​ 要素の ​`event`​ 属性を使用して、次の種別の通知を指定できます。 - ASYNC-MESSAGE - CONNECTION - CONNECTOR-MESSAGE - CONTEXT - CUSTOM - EXCEPTION - EXCEPTION-STRATEGY - MANAGEMENT - MESSAGE-PROCESSOR - PIPELINE-MESSAGE - ROUTING - SECURITY - TRANSACTION # 通知設定リファレンス このトピックでは、通知のために設定する要素について詳しく説明します。通知についての詳細は、​[「Mule サーバーの通知」](https://docs.mulesoft.com/jp/mule-runtime/4.9/mule-server-notifications)​を参照してください。 ## [](#notifications-通知)Notifications (通知) 通知のためにリスナーを登録し、インターフェースを特定のイベントに関連付けます。 ### [](#通知の属性)通知の属性
名前 説明

dynamic

通知マネージャーが動的な場合、実行時に動的に登録されるようにリスナーをセットアップできます。それ以外の場合、効率のために Mule の一部で通知設定がキャッシュされ、新たに有効になった通知またはリスナーのためにイベントが生成されません。
型​: boolean
必須​: いいえ
デフォルト​: false
### [](#通知の子要素)通知の子要素 `notification`​ 要素と ​`disable-notification`​ 要素を使用してインターフェースとイベント間のリレーションを設定します。
名前 基数 説明

notification

0..*

イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。

disable-notification

0..*

特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​notification-listener​ などの他の要素よりも優先されます。

notification-listener

0..*

通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。
## [](#notification-通知)Notification (通知) イベントをインターフェースに関連付けます。インターフェースを実装するリスナーがイベントのインスタンスを受信します。 ### [](#通知の属性-2)通知の属性
名前 説明

event-class

インターフェースに配信する通知イベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

配信する通知イベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

通知イベントを受信するインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

通知イベントを受信するインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`notification`​ の子要素はありません。 ## [](#通知の無効化)通知の無効化 特定のインターフェースとのイベントの関連付けをブロックします。これにより、インターフェースとの関連付けが行われた後にイベントを絞り込むため、​`notification-listener`​ などの他の要素よりも優先されます。 ### [](#disable-notification-の属性)disable-notification の属性
名前 説明

event-class

インターフェースに配信されなくなったイベントのクラス名。この属性を ​event​ 属性の代わりに使用してカスタムクラスを指定できます。
型​: class name
必須​: いいえ
デフォルト​: なし

event

もう配信しないイベント。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし

interface-class

イベントを受信しなくなったインターフェースのクラス名。
型​: class name
必須​: いいえ
デフォルト​: なし

interface

イベントを受信しなくなったインターフェースの名前。
型​: notificationTypes
必須​: いいえ
デフォルト​: なし
`disable-notification`​ の子要素はありません。 ## [](#通知リスナー)通知リスナー 通知システムに対するリスナーとして Bean を登録します。イベントは反映によってディスパッチされます。つまり、リスナーは実装するインターフェースに関連付けられているすべてのイベントを受信します。 ## [](#通知種別)通知種別 `notification`​ 要素と ​`disable-notification`​ 要素の ​`event`​ 属性を使用して、次の種別の通知を指定できます。 - ASYNC-MESSAGE - CONNECTION - CONNECTOR-MESSAGE - CONTEXT - CUSTOM - EXCEPTION - EXCEPTION-STRATEGY - MANAGEMENT - MESSAGE-PROCESSOR - PIPELINE-MESSAGE - ROUTING - SECURITY - TRANSACTION # 高可用性および障害回復 計画しているかどうかに関わらず、インフラストラクチャやアプリケーションのダウンタイムは、いつでも、どこからでも、どのような形でも発生する可能性があります。テクノロジーの停止、設備の破壊、人材の損失、重要なサードパーティサービスの損失の際に組織の稼働を継続できる能力は、ビジネスへの取り返しのつかないダメージを防ぐために不可欠です。世界的に E コマースへのシフトが進み、アプリケーションの 365 日 24 時間のアップタイムへの依存が高まっているため、高可用性 (HA) と障害回復 (DR) は、組織の財政状態に影響を及ぼします。 次の表は、少しのダウンタイムでも積み上げれば組織に悪影響を及ぼす可能性があることを示しています。
アップタイム率 ダウンタイム率 週間ダウンタイム 年間ダウンタイム

99%

1%

1.68 時間

3.65 日

99.9%

0.1%

10.1 分

8.75 時間

99.99%

0.01%

1 分

52.5 分

99.999%

0.001%

6 秒

5.25 分
## [](#高可用性と障害回復の比較)高可用性と障害回復の比較 - **高可用性 (HA)**​ - システムコンポーネントの障害が発生した際にシステムがアクセス可能な状態を維持する能力の基準。一般に HA は、システムに複数レベルのフォールトトレランス機能や負荷分散機能を構築することで実装されます。 - **障害回復 (DR)**​ - 自然災害 (洪水、竜巻、地震、火事など) や人災 (停電、サーバー障害、設定の誤りなど) が発生した後に、システムを以前の許容される状態に復元するプロセス。 どちらも全体的な可用性を高めますが、注目すべき違いは、HA では一般にサービスが停止しないことです。HA はサービスを保持し、DR はデータを保持しますが、DR では通常、DR 計画が実行されシステムが復元するまでの間にわずかなサービス停止が発生します。 ## [](#ha-および-dr-戦略のための-mule-のデプロイ)HA および DR 戦略のための Mule のデプロイ HA および DR 戦略に対応するために、さまざまなトポロジーで Mule Runtime をデプロイできます。1 つの方法は、クラスタリングを使用することです。これについては、このドキュメントの後のセクションで説明します。Mule 高可用性クラスタリングでは、Mule の基本的なフェールオーバー機能が提供されます。 JVM またはハードウェアの致命的な障害が発生したり、メンテナンスのためにオフラインになったりしたために、プライマリ Mule Runtime が使用できなくなった場合、バックアップ Mule Runtime が即座にプライマリノードになり、障害の発生したインスタンスが中断したところから処理を再開します。 システム管理者が障害が発生した Mule Runtime を回復してオンラインに戻すと、そのサーバーは自動的にバックアップノードになります。 ![hadr cluster](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/hadr-cluster.png) シームレスなフェールオーバーは、クラスター化された Mule Runtime ですべての一時的な状態の情報を共有する次のような分散メモリストアによって実現します。 - SEDA サービスイベントキュー - メモリ内メッセージキュー Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。 ## [](#効果的な-sla-の作成)効果的な SLA の作成 サービスレベル契約 (SLA) では、何が許容されるかについて具体的な定義の概要を定めます。 高可用性の基本的な定義は、サービスが起動して機能している、つまり適切に要求と応答を処理しているということです。これは、サービスが常に完全な機能を維持して稼働しているという意味ではありません。高可用性を考慮して設計されたシステムは、中断を防ぎ、第一に停止の発生を防ぎます。SLA では、すべての関係者に対する期待事項を定めます。 SLA 要件 - 単一障害点が排除されている - トラフィック/要求がリダイレクト/処理される - 障害の検出 たとえば、基本的なサービスの SLA は次のようになります。 - サービスの通常の運用では、1 秒あたり 1000 件のトランザクションを応答時間 1 秒で処理する。 - 1 年間の合計ダウンタイムは 0.5% (1.83 日) とする。 - 最小許容サービス影響レベルは、1 秒あたり 100 件のトランザクション、応答時間 1 秒を 1 週間に 2 時間とする。 関連情報 - [Defining SLA Tiers (SLA ティアの定義)](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) - [Rate Limiting and Throttling - SLA-Based Policies (レート制限および調整 - SLA ベースのポリシー)](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) ## [](#高可用性オプション)高可用性オプション 高可用性は、クラスタリングの使用やノードの負荷分散によって実現できます。定義された SLA に応じて、Mule には 4 つの HA オプションがあります。 - [\[Cold Standby\]](<#Cold Standby>) - [\[Warm Standby\]](<#Warm Standby>) - [\[Hot Standby - Active-Passive\]](<#Hot Standby - Active-Passive>) - [Active-Active](#active-active)
多くの場合、これらのオプションは障害回復戦略に関連します。
### [](#コールドスタンバイ)コールドスタンバイ
図 説明 ダウンタイム

hadr cold standby

Mule 環境がインストールされ、設定されています。ただし、1 つ以上のオペレーティングシステムが実行中ではありません。これは、本番システム/仮想マシンのバックアップとして使用できます。停止が検出された後にオペレーティングシステムの環境と Mule Runtime が起動されます。

あり。環境を起動してトラフィックを転送するのにかかる時間。
### [](#ウォームスタンバイ)ウォームスタンバイ
図 説明 ダウンタイム

hadr warm standby

Mule 環境がインストールされ、設定されています。ただし、Mule Runtime は実行されておらず、オペレーティングシステムのみが実行されています。停止が検出された後に Mule Runtime が起動されます。

少ない。Mule Runtime を起動し、トラフィックを環境に転送するのにかかる時間。
### [](#ホットスタンバイ-アクティブ-パッシブ)ホットスタンバイ - アクティブ-パッシブ
図 説明 ダウンタイム

hadr active passive

Mule 環境がインストールされ、設定され、完全に実行しています。ただし、停止が検出されるまでは要求を処理していません。

最小限またはなし。トラフィックを環境に転送する時間。
### [](#active-active)Active-Active
図 説明 ダウンタイム

hadr active active1

負荷分散クラスター環境。 完全に稼働している 2 つ以上の Mule 環境 (各環境に固有のクラスター) があります。ロードバランサーがすべての環境にトラフィックを転送します。

なし。サービスダウンタイムはありません。

hadr active active2

負荷分散単一クラスター環境。 2 つ以上の Mule 環境がありますが、それらは同じクラスター環境の一部です。このシナリオを実現するには、環境間のネットワークレイテンシーが 10 ミリ秒未満である必要があります。

なし。サービスダウンタイムはありません。
## [](#高可用性デプロイモデル)高可用性デプロイモデル - [\[Active-Active Clustering Deployment Model\]](<#Active-Active Clustering Deployment Model>) - [\[Active-Active Clustering Fault Tolerance Deployment Model\]](<#Active-Active Clustering Fault Tolerance Deployment Model>) - [\[Zero Downtime Deployment Model\]](<#Zero Downtime Deployment Model>) ### [](#アクティブ-アクティブクラスタリングデプロイモデル)アクティブ-アクティブクラスタリングデプロイモデル クラスター化され負荷が分散されている環境の 2 つのノードで、応答時間 1 秒で 1,500 TPS をサポート可能です。この状態で、SLA の通常運用の条件を満たしています。ノードに障害が発生すると、サービスは影響を受けます。ただし、ノードは応答時間 1 秒で 700 TPS を処理でき、これは許容される影響レベルを大きく上回っているため、この障害による影響は SLA に違反しません。 ![hadr aa clustering](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/hadr-aa-clustering.png) 複数の Mule ノードに負荷を均等に分散させます。 - すべてのノードの機能は同じです。 - すべてのノードが同時にアクティブです。 **コスト** SLA 要件によって異なります。このモデルでは、SLA を満たすために 2 つのノードが必要です。SLA の許容可能なサービス影響が通常運用で指定されているのと同じ条件に変更されると、1 つのノード障害に対応するために環境に少なくとも 3 つのノードが必要です。2 つ以上のノードが実行中である状態を維持できない確率によっては、さらに多くのノードが必要な場合もあります。 ### [](#アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル)アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル フォールトトレランスの基本的な定義は、システム内の障害がサービスに全く影響を及ぼさないということです。これは、サービスの影響とダウンタイムへの耐性があるという点で高可用性とは異なります。 ![hadr fault tolerant](/mulesoft/current/ja-jp/mule-runtime/4.3/_images/hadr-fault-tolerant.png) フォールトトレランスでは、高可用性とは異なり、コンポーネント障害後にアプリケーションが中断なく機能し続けられるようにするための追加のリソースが提供されます。フォールトトレランス環境は高可用性環境よりもコストがかかります。 フォールトトレランスの度合を判断するには、システム障害の確率が必要です。高可用性のセクションで取り上げた SLA の例を使用して、最小許容サービス影響レベルが通常運用の要件と同じであるとします。 新しい全体的な SLA では、システムが 1 秒あたり 1000 件のトランザクションを処理し、応答時間 1 秒、ダウンタイムなし、サービスへの影響なしにする必要があります。 2 つ以上のノードで障害が発生する確率が低ければ、このアーキテクチャに必要なノードは 3 つで済みます。一方、2 つ以上のノードで障害が発生する確率が許容できないほど高い場合は、複数障害に対応するために 4 つ以上のノードが必要になります。 **コスト** 定義された SLA を満たすために冗長性が必要なので、よりコストがかかります。 ### [](#ゼロダウンタイムデプロイモデル)ゼロダウンタイムデプロイモデル 目標は、SLA に影響を与えずに環境をすばやく変更することです。この変更には、インフラストラクチャやインフラストラクチャ上で実行中のアプリケーションのアップグレードを含みます。通常、ゼロダウンタイムデプロイでは、新旧のシステムが短期間共存するサイドバイサイドのデプロイが使用されます。これは、機能の低下や完全なダウンタイムが発生するインプレースのデプロイとは対照的です。 [Gartner](http://www.gartner.com/it-glossary/continuous-operations/)​ は連続稼働を次のように定義しています。「データ処理システムの特性で、定期メンテナンスなどの計画されたダウンタイムを低減または排除すること。24 時間 365 日稼働の 1 つの要素。」 ベースライン本番環境は、現在稼働中の環境です。変更 (ランタイムのアップグレード、設定、新しいアプリケーションなど) された新しい環境が作成されます。 ごく一部のトラフィックが新しい環境に送信され、新しい環境の信頼度が高まるにつれて増えていきます。新しい環境が完全稼働状態 (トラフィックの 100% を処理) になるまで、ベースライン本番環境は引き続き使用されます。新しい環境がすべてのトラフィックを受け入れるようになると、それが新しいベースライン本番環境となり、以前のベースライン本番環境は終了します。 下の例では、各環境は同じ数の Mule Runtime とコアを使用していると想定しています。実際には新しい環境がベースライン環境よりも多くなったり少なくなったりする可能性もあります。
デプロイの手順 図

新しい本番環境がデプロイされ、ごく一部のトラフィックが新しい環境に転送されます。

hadr zero downtime 1

新しい環境の信頼度が高まり、転送されるトラフィックが増えます。

hadr zero downtime 2

すべてのトラフィックが新しい環境に転送されます。

hadr zero downtime 3

すべてのトラフィックが新しい環境に転送され、新しい環境がベースライン本番環境に昇格します。以前のベースライン環境は終了します。

hadr zero downtime 4
**コスト** このデプロイ方法では、一時的にサービスの容量が追加される場合があります (数分間、数時間、または数日間)。 ## [](#障害回復)障害回復 **あなたの会社は、IT の緊急事態が発生した後にどれだけ迅速に業務に戻ることができますか?** 障害回復は、自然災害や人災が発生した後に、システムを以前の許容される状態に復元するプロセスです。ビジネス要件に沿って適切な DR 戦略を選択することが重要です。DR では、目標復旧時間 (RTO) や目標復旧時点 (RPO) などの測定可能な特性を使用して DR 計画を推進します。 障害回復で重要なのは目標復旧時点 (RPO) と目標復旧時間 (RTO) です。RPO は、IT 障害の後に戻る時点です。たとえば、24 時間ごとにバックアップしている場合、RPO は最長で 24 時間前になります。一方、RTO は、どれだけ迅速に RPO に戻して、業務に戻れるかということです。これには、プライマリ機器が機能しなくなったときに、予備の機器でバックアップの実行を開始する時間などの活動が含まれます。 システムバックアップは、しっかりとした障害回復プログラムの重要な要素です。回復には、コールド、ウォーム、ホットの 3 種類があります。
用語 定義 例

目標復旧時間 (RTO)

どれだけ迅速にこのアセットを復旧する必要があるか?

1 分? 15 分? 1 時間? 4 時間? 1 日?

目標復旧時点 (RPO)

このアセットはどれだけ新しいものに復旧する必要があるか?

データロスなし、15 分の有効期限?
CloudHub を使用した障害回復についての詳細は、​[「CloudHub High Availability and Disaster Recovery (CloudHub の高可用性と障害回復)」](https://docs.mulesoft.com/cloudhub/cloudhub-hadr)​を参照してください。 ## [](#ステートレスなインテグレーション)ステートレスなインテグレーション 一般的な設計原理として、インテグレーションが本質的にステートレスであることが常に重要です。つまり、さまざまなクライアントの呼び出しや実行 (スケジュールされたサービスの場合) の間でトランザクション情報を共有しないということです。システムの制約によって一部のデータをミドルウェアで管理する必要がある場合、そのデータはデータベースやメッセージングキューなどの外部ストアで保持し、ミドルウェアのインフラストラクチャやメモリの内部では保持しないようにする必要があります。拡張 (特にクラウドでの拡張) の際には、各ワーカー/ノードで使用される状態やリソースは他のワーカーとは独立している必要があることに注意することが重要です。このモデルを使用することで、パフォーマンス、スケーラビリティ、信頼性が向上します。 # 高可用性および障害回復 計画しているかどうかに関わらず、インフラストラクチャやアプリケーションのダウンタイムは、いつでも、どこからでも、どのような形でも発生する可能性があります。テクノロジーの停止、設備の破壊、人材の損失、重要なサードパーティサービスの損失の際に組織の稼働を継続できる能力は、ビジネスへの取り返しのつかないダメージを防ぐために不可欠です。世界的に E コマースへのシフトが進み、アプリケーションの 365 日 24 時間のアップタイムへの依存が高まっているため、高可用性 (HA) と障害回復 (DR) は、組織の財政状態に影響を及ぼします。 次の表は、少しのダウンタイムでも積み上げれば組織に悪影響を及ぼす可能性があることを示しています。
アップタイム率 ダウンタイム率 週間ダウンタイム 年間ダウンタイム

99%

1%

1.68 時間

3.65 日

99.9%

0.1%

10.1 分

8.75 時間

99.99%

0.01%

1 分

52.5 分

99.999%

0.001%

6 秒

5.25 分
## [](#高可用性と障害回復の比較)高可用性と障害回復の比較 - **高可用性 (HA)**​ - システムコンポーネントの障害が発生した際にシステムがアクセス可能な状態を維持する能力の基準。一般に HA は、システムに複数レベルのフォールトトレランス機能や負荷分散機能を構築することで実装されます。 - **障害回復 (DR)**​ - 自然災害 (洪水、竜巻、地震、火事など) や人災 (停電、サーバー障害、設定の誤りなど) が発生した後に、システムを以前の許容される状態に復元するプロセス。 どちらも全体的な可用性を高めますが、注目すべき違いは、HA では一般にサービスが停止しないことです。HA はサービスを保持し、DR はデータを保持しますが、DR では通常、DR 計画が実行されシステムが復元するまでの間にわずかなサービス停止が発生します。 ## [](#ha-および-dr-戦略のための-mule-のデプロイ)HA および DR 戦略のための Mule のデプロイ HA および DR 戦略に対応するために、さまざまなトポロジーで Mule Runtime をデプロイできます。1 つの方法は、クラスタリングを使用することです。これについては、このドキュメントの後のセクションで説明します。Mule 高可用性クラスタリングでは、Mule の基本的なフェールオーバー機能が提供されます。 JVM またはハードウェアの致命的な障害が発生したり、メンテナンスのためにオフラインになったりしたために、プライマリ Mule Runtime が使用できなくなった場合、バックアップ Mule Runtime が即座にプライマリノードになり、障害の発生したインスタンスが中断したところから処理を再開します。 システム管理者が障害が発生した Mule Runtime を回復してオンラインに戻すと、そのサーバーは自動的にバックアップノードになります。 ![hadr cluster](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/hadr-cluster.png) シームレスなフェールオーバーは、クラスタリングされた Mule Runtime ですべての一時的な状態の情報を共有する次のような分散メモリストアによって実現します。 - SEDA サービスイベントキュー - メモリ内メッセージキュー Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。 ## [](#効果的な-sla-の作成)効果的な SLA の作成 サービスレベル契約 (SLA) では、何が許容されるかについて具体的な定義の概要を定めます。 高可用性の基本的な定義は、サービスが起動して機能している、つまり適切に要求と応答を処理しているということです。これは、サービスが常に完全な機能を維持して稼働しているという意味ではありません。高可用性を考慮して設計されたシステムは、中断を防ぎ、第一に停止の発生を防ぎます。SLA では、すべての関係者に対する期待事項を定めます。 SLA 要件 - 単一障害点が排除されている - トラフィック/要求がリダイレクト/処理される - 障害の検出 たとえば、基本的なサービスの SLA は次のようになります。 - サービスの通常の運用では、1 秒あたり 1000 件のトランザクションを応答時間 1 秒で処理する。 - 1 年間の合計ダウンタイムは 0.5% (1.83 日) とする。 - 最小許容サービス影響レベルは、1 秒あたり 100 件のトランザクション、応答時間 1 秒を 1 週間に 2 時間とする。 関連情報 - [Defining SLA Tiers (SLA ティアの定義)](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) - [Rate Limiting and Throttling - SLA-Based Policies (レート制限および調整 - SLA ベースのポリシー)](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) ## [](#高可用性オプション)高可用性オプション 高可用性は、クラスタリングの使用やノードの負荷分散によって実現できます。定義された SLA に応じて、Mule には 4 つの HA オプションがあります。 - [\[Cold Standby\]](<#Cold Standby>) - [\[Warm Standby\]](<#Warm Standby>) - [\[Hot Standby - Active-Passive\]](<#Hot Standby - Active-Passive>) - [Active-Active](#active-active)
多くの場合、これらのオプションは障害回復戦略に関連します。
### [](#コールドスタンバイ)コールドスタンバイ
図 説明 ダウンタイム

hadr cold standby

Mule 環境がインストールされ、設定されています。ただし、1 つ以上のオペレーティングシステムが実行中ではありません。これは、本番システム/仮想マシンのバックアップとして使用できます。停止が検出された後にオペレーティングシステムの環境と Mule Runtime が起動されます。

あり。環境を起動してトラフィックを転送するのにかかる時間。
### [](#ウォームスタンバイ)ウォームスタンバイ
図 説明 ダウンタイム

hadr warm standby

Mule 環境がインストールされ、設定されています。ただし、Mule Runtime は実行されておらず、オペレーティングシステムのみが実行されています。停止が検出された後に Mule Runtime が起動されます。

少ない。Mule Runtime を起動し、トラフィックを環境に転送するのにかかる時間。
### [](#ホットスタンバイ-アクティブ-パッシブ)ホットスタンバイ - アクティブ-パッシブ
図 説明 ダウンタイム

hadr active passive

Mule 環境がインストールされ、設定され、完全に実行しています。ただし、停止が検出されるまでは要求を処理していません。

最小限またはなし。トラフィックを環境に転送する時間。
### [](#active-active)Active-Active
図 説明 ダウンタイム

hadr active active1

負荷分散クラスター環境。 完全に稼働している 2 つ以上の Mule 環境 (各環境に固有のクラスター) があります。ロードバランサーがすべての環境にトラフィックを転送します。

なし。サービスダウンタイムはありません。

hadr active active2

負荷分散単一クラスター環境。 2 つ以上の Mule 環境がありますが、それらは同じクラスター環境の一部です。このシナリオを実現するには、環境間のネットワークレイテンシーが 10 ミリ秒未満である必要があります。

なし。サービスダウンタイムはありません。
## [](#オンプレミスデプロイメントモデルの高可用性)オンプレミスデプロイメントモデルの高可用性 - [\[Active-Active Clustering Deployment Model\]](<#Active-Active Clustering Deployment Model>) - [\[Active-Active Clustering Fault Tolerance Deployment Model\]](<#Active-Active Clustering Fault Tolerance Deployment Model>) - [\[Zero Downtime Deployment Model\]](<#Zero Downtime Deployment Model>) ### [](#アクティブ-アクティブクラスタリングデプロイモデル)アクティブ-アクティブクラスタリングデプロイモデル クラスタリングされ負荷が分散されている環境の 2 つのノードで、応答時間 1 秒で 1,500 TPS をサポート可能です。この状態で、SLA の通常運用の条件を満たしています。ノードに障害が発生すると、サービスは影響を受けます。ただし、ノードは応答時間 1 秒で 700 TPS を処理でき、これは許容される影響レベルを大きく上回っているため、この障害による影響は SLA に違反しません。 ![hadr aa clustering](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/hadr-aa-clustering.png) 複数の Mule ノードに負荷を均等に分散させます。 - すべてのノードの機能は同じです。 - すべてのノードが同時にアクティブです。 **コスト** SLA 要件によって異なります。このモデルでは、SLA を満たすために 2 つのノードが必要です。SLA の許容可能なサービス影響が通常運用で指定されているのと同じ条件に変更されると、1 つのノード障害に対応するために環境に少なくとも 3 つのノードが必要です。2 つ以上のノードが実行中である状態を維持できない確率によっては、さらに多くのノードが必要な場合もあります。 ### [](#アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル)アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル フォールトトレランスの基本的な定義は、システム内の障害がサービスに全く影響を及ぼさないということです。これは、サービスの影響とダウンタイムへの耐性があるという点で高可用性とは異なります。 ![hadr fault tolerant](/mulesoft/current/ja-jp/mule-runtime/4.4/_images/hadr-fault-tolerant.png) フォールトトレランスでは、高可用性とは異なり、コンポーネント障害後にアプリケーションが中断なく機能し続けられるようにするための追加のリソースが提供されます。フォールトトレランス環境は高可用性環境よりもコストがかかります。 フォールトトレランスの度合を判断するには、システム障害の確率が必要です。高可用性のセクションで取り上げた SLA の例を使用して、最小許容サービス影響レベルが通常運用の要件と同じであるとします。 新しい全体的な SLA では、システムが 1 秒あたり 1000 件のトランザクションを処理し、応答時間 1 秒、ダウンタイムなし、サービスへの影響なしにする必要があります。 2 つ以上のノードで障害が発生する確率が低ければ、このアーキテクチャに必要なノードは 3 つで済みます。一方、2 つ以上のノードで障害が発生する確率が許容できないほど高い場合は、複数障害に対応するために 4 つ以上のノードが必要になります。 **コスト** 定義された SLA を満たすために冗長性が必要なので、よりコストがかかります。 ### [](#ゼロダウンタイムデプロイモデル)ゼロダウンタイムデプロイモデル 目標は、SLA に影響を与えずに環境をすばやく変更することです。この変更には、インフラストラクチャやインフラストラクチャ上で実行中のアプリケーションのアップグレードを含みます。通常、ゼロダウンタイムデプロイでは、新旧のシステムが短期間共存するサイドバイサイドのデプロイが使用されます。これは、機能の低下や完全なダウンタイムが発生するインプレースのデプロイとは対照的です。 [Gartner](http://www.gartner.com/it-glossary/continuous-operations/)​ は連続稼働を次のように定義しています。「データ処理システムの特性で、定期メンテナンスなどの計画されたダウンタイムを低減または排除すること。24 時間 365 日稼働の 1 つの要素。」 ベースライン本番環境は、現在稼働中の環境です。変更 (ランタイムのアップグレード、設定、新しいアプリケーションなど) された新しい環境が作成されます。 ごく一部のトラフィックが新しい環境に送信され、新しい環境の信頼度が高まるにつれて増えていきます。新しい環境が完全稼働状態 (トラフィックの 100% を処理) になるまで、ベースライン本番環境は引き続き使用されます。新しい環境がすべてのトラフィックを受け入れるようになると、それが新しいベースライン本番環境となり、以前のベースライン本番環境は終了します。 下の例では、各環境は同じ数の Mule Runtime とコアを使用していると想定しています。実際には新しい環境がベースライン環境よりも多くなったり少なくなったりする可能性もあります。
デプロイの手順 図

新しい本番環境がデプロイされ、ごく一部のトラフィックが新しい環境に転送されます。

hadr zero downtime 1

新しい環境の信頼度が高まり、転送されるトラフィックが増えます。

hadr zero downtime 2

すべてのトラフィックが新しい環境に転送されます。

hadr zero downtime 3

すべてのトラフィックが新しい環境に転送され、新しい環境がベースライン本番環境に昇格します。以前のベースライン環境は終了します。

hadr zero downtime 4
**コスト** このデプロイ方法では、一時的にサービスの容量が追加される場合があります (数分間、数時間、または数日間)。 ## [](#障害回復)障害回復 **あなたの会社は、IT の緊急事態が発生した後にどれだけ迅速に業務に戻ることができますか?** 障害回復は、自然災害や人災が発生した後に、システムを以前の許容される状態に復元するプロセスです。ビジネス要件に沿って適切な DR 戦略を選択することが重要です。DR では、目標復旧時間 (RTO) や目標復旧時点 (RPO) などの測定可能な特性を使用して DR 計画を推進します。 障害回復で重要なのは目標復旧時点 (RPO) と目標復旧時間 (RTO) です。RPO は、IT 障害の後に戻る時点です。たとえば、24 時間ごとにバックアップしている場合、RPO は最長で 24 時間前になります。一方、RTO は、どれだけ迅速に RPO に戻して、業務に戻れるかということです。これには、プライマリ機器が機能しなくなったときに、予備の機器でバックアップの実行を開始する時間などの活動が含まれます。 システムバックアップは、しっかりとした障害回復プログラムの重要な要素です。回復には、コールド、ウォーム、ホットの 3 種類があります。
用語 定義 例

目標復旧時間 (RTO)

どれだけ迅速にこのアセットを復旧する必要があるか?

1 分? 15 分? 1 時間? 4 時間? 1 日?

目標復旧時点 (RPO)

このアセットはどれだけ新しいものに復旧する必要があるか?

データロスなし、15 分の有効期限?
CloudHub を使用した障害回復についての詳細は、​[「CloudHub High Availability and Disaster Recovery (CloudHub の高可用性と障害回復)」](https://docs.mulesoft.com/cloudhub/cloudhub-hadr)​を参照してください。 ## [](#ステートレスなインテグレーション)ステートレスなインテグレーション 一般的な設計原理として、インテグレーションが本質的にステートレスであることが常に重要です。つまり、さまざまなクライアントの呼び出しや実行 (スケジュールされたサービスの場合) の間でトランザクション情報を共有しないということです。システムの制約によって一部のデータをミドルウェアで管理する必要がある場合、そのデータはデータベースやメッセージングキューなどの外部ストアで保持し、ミドルウェアのインフラストラクチャやメモリの内部では保持しないようにする必要があります。拡張 (特にクラウドでの拡張) の際には、各ワーカー/ノードで使用される状態やリソースは他のワーカーとは独立している必要があることに注意することが重要です。このモデルを使用することで、パフォーマンス、スケーラビリティ、信頼性が向上します。 # 高可用性および障害回復 計画しているかどうかに関わらず、インフラストラクチャやアプリケーションのダウンタイムは、いつでも、どこからでも、どのような形でも発生する可能性があります。テクノロジーの停止、設備の破壊、人材の損失、重要なサードパーティサービスの損失の際に組織の稼働を継続できる能力は、ビジネスへの取り返しのつかないダメージを防ぐために不可欠です。世界的に E コマースへのシフトが進み、アプリケーションの 365 日 24 時間のアップタイムへの依存が高まっているため、高可用性 (HA) と障害回復 (DR) は、組織の財政状態に影響を及ぼします。 次の表は、少しのダウンタイムでも積み上げれば組織に悪影響を及ぼす可能性があることを示しています。
アップタイム率 ダウンタイム率 週間ダウンタイム 年間ダウンタイム

99%

1%

1.68 時間

3.65 日

99.9%

0.1%

10.1 分

8.75 時間

99.99%

0.01%

1 分

52.5 分

99.999%

0.001%

6 秒

5.25 分
## [](#高可用性と障害回復の比較)高可用性と障害回復の比較 - **高可用性 (HA)**​ - システムコンポーネントの障害が発生した際にシステムがアクセス可能な状態を維持する能力の基準。一般に HA は、システムに複数レベルのフォールトトレランス機能や負荷分散機能を構築することで実装されます。 - **障害回復 (DR)**​ - 自然災害 (洪水、竜巻、地震、火事など) や人災 (停電、サーバー障害、設定の誤りなど) が発生した後に、システムを以前の許容される状態に復元するプロセス。 どちらも全体的な可用性を高めますが、注目すべき違いは、HA では一般にサービスが停止しないことです。HA はサービスを保持し、DR はデータを保持しますが、DR では通常、DR 計画が実行されシステムが復元するまでの間にわずかなサービス停止が発生します。 ## [](#ha-および-dr-戦略のための-mule-のデプロイ)HA および DR 戦略のための Mule のデプロイ HA および DR 戦略に対応するために、さまざまなトポロジーで Mule Runtime をデプロイできます。1 つの方法は、クラスタリングを使用することです。これについては、このドキュメントの後のセクションで説明します。Mule 高可用性クラスタリングでは、Mule の基本的なフェールオーバー機能が提供されます。 JVM またはハードウェアの致命的な障害が発生したり、メンテナンスのためにオフラインになったりしたために、プライマリ Mule Runtime が使用できなくなった場合、バックアップ Mule Runtime が即座にプライマリノードになり、障害の発生したインスタンスが中断したところから処理を再開します。 システム管理者が障害が発生した Mule Runtime を回復してオンラインに戻すと、そのサーバーは自動的にバックアップノードになります。 ![hadr cluster](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/hadr-cluster.png) シームレスなフェールオーバーは、クラスター化された Mule Runtime ですべての一時的な状態の情報を共有する次のような分散メモリストアによって実現します。 - SEDA サービスイベントキュー - メモリ内メッセージキュー Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。 ## [](#効果的な-sla-の作成)効果的な SLA の作成 サービスレベル契約 (SLA) では、何が許容されるかについて具体的な定義の概要を定めます。 高可用性の基本的な定義は、サービスが起動して機能している、つまり適切に要求と応答を処理しているということです。これは、サービスが常に完全な機能を維持して稼働しているという意味ではありません。高可用性を考慮して設計されたシステムは、中断を防ぎ、第一に停止の発生を防ぎます。SLA では、すべての関係者に対する期待事項を定めます。 SLA 要件 - 単一障害点が排除されている - トラフィック/要求がリダイレクト/処理される - 障害の検出 たとえば、基本的なサービスの SLA は次のようになります。 - サービスの通常の運用では、1 秒あたり 1000 件のトランザクションを応答時間 1 秒で処理する。 - 1 年間の合計ダウンタイムは 0.5% (1.83 日) とする。 - 最小許容サービス影響レベルは、1 秒あたり 100 件のトランザクション、応答時間 1 秒を 1 週間に 2 時間とする。 関連情報 - [Defining SLA Tiers (SLA ティアの定義)](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) - [Rate Limiting and Throttling - SLA-Based Policies (レート制限および調整 - SLA ベースのポリシー)](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) ## [](#高可用性オプション)高可用性オプション 高可用性は、クラスタリングの使用やノードの負荷分散によって実現できます。定義された SLA に応じて、Mule には 4 つの HA オプションがあります。 - [コールドスタンバイ](#コールドスタンバイ) - [ウォームスタンバイ](#ウォームスタンバイ) - [ホットスタンバイ - アクティブ-パッシブ](#ホットスタンバイ-アクティブ-パッシブ) - [Active-Active](#active-active)
多くの場合、これらのオプションは障害回復戦略に関連します。
### [](#コールドスタンバイ)コールドスタンバイ
図 説明 ダウンタイム

hadr cold standby

Mule 環境がインストールされ、設定されています。ただし、1 つ以上のオペレーティングシステムが実行中ではありません。これは、本番システム/仮想マシンのバックアップとして使用できます。停止が検出された後にオペレーティングシステムの環境と Mule Runtime が起動されます。

あり。環境を起動してトラフィックを転送するのにかかる時間。
### [](#ウォームスタンバイ)ウォームスタンバイ
図 説明 ダウンタイム

hadr warm standby

Mule 環境がインストールされ、設定されています。ただし、Mule Runtime は実行されておらず、オペレーティングシステムのみが実行されています。停止が検出された後に Mule Runtime が起動されます。

少ない。Mule Runtime を起動し、トラフィックを環境に転送するのにかかる時間。
### [](#ホットスタンバイ-アクティブ-パッシブ)ホットスタンバイ - アクティブ-パッシブ
図 説明 ダウンタイム

hadr active passive

Mule 環境がインストールされ、設定され、完全に実行しています。ただし、停止が検出されるまでは要求を処理していません。

最小限またはなし。トラフィックを環境に転送する時間。
### [](#active-active)Active-Active
図 説明 ダウンタイム

hadr active active1

負荷分散クラスター環境。 完全に稼働している 2 つ以上の Mule 環境 (各環境に固有のクラスター) があります。ロードバランサーがすべての環境にトラフィックを転送します。

なし。サービスダウンタイムはありません。

hadr active active2

負荷分散単一クラスター環境。 2 つ以上の Mule 環境がありますが、それらは同じクラスター環境の一部です。このシナリオを実現するには、環境間のネットワークレイテンシーが 10 ミリ秒未満である必要があります。

なし。サービスダウンタイムはありません。
## [](#高可用性デプロイモデル)高可用性デプロイモデル - [アクティブ-アクティブクラスタリングデプロイモデル](#アクティブ-アクティブクラスタリングデプロイモデル) - [アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル](#アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル) - [ゼロダウンタイムデプロイモデル](#ゼロダウンタイムデプロイモデル) ### [](#アクティブ-アクティブクラスタリングデプロイモデル)アクティブ-アクティブクラスタリングデプロイモデル クラスター化され負荷が分散されている環境の 2 つのノードで、応答時間 1 秒で 1,500 TPS をサポート可能です。この状態で、SLA の通常運用の条件を満たしています。ノードに障害が発生すると、サービスは影響を受けます。ただし、ノードは応答時間 1 秒で 700 TPS を処理でき、これは許容される影響レベルを大きく上回っているため、この障害による影響は SLA に違反しません。 ![hadr aa clustering](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/hadr-aa-clustering.png) 複数の Mule ノードに負荷を均等に分散させます。 - すべてのノードの機能は同じです。 - すべてのノードが同時にアクティブです。 **コスト** SLA 要件によって異なります。このモデルでは、SLA を満たすために 2 つのノードが必要です。SLA の許容可能なサービス影響が通常運用で指定されているのと同じ条件に変更されると、1 つのノード障害に対応するために環境に少なくとも 3 つのノードが必要です。2 つ以上のノードが実行中である状態を維持できない確率によっては、さらに多くのノードが必要な場合もあります。 ### [](#アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル)アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル フォールトトレランスの基本的な定義は、システム内の障害がサービスに全く影響を及ぼさないということです。これは、サービスの影響とダウンタイムへの耐性があるという点で高可用性とは異なります。 ![hadr fault tolerant](/mulesoft/current/ja-jp/mule-runtime/4.5/_images/hadr-fault-tolerant.png) フォールトトレランスでは、高可用性とは異なり、コンポーネント障害後にアプリケーションが中断なく機能し続けられるようにするための追加のリソースが提供されます。フォールトトレランス環境は高可用性環境よりもコストがかかります。 フォールトトレランスの度合を判断するには、システム障害の確率が必要です。高可用性のセクションで取り上げた SLA の例を使用して、最小許容サービス影響レベルが通常運用の要件と同じであるとします。 新しい全体的な SLA では、システムが 1 秒あたり 1000 件のトランザクションを処理し、応答時間 1 秒、ダウンタイムなし、サービスへの影響なしにする必要があります。 2 つ以上のノードで障害が発生する確率が低ければ、このアーキテクチャに必要なノードは 3 つで済みます。一方、2 つ以上のノードで障害が発生する確率が許容できないほど高い場合は、複数障害に対応するために 4 つ以上のノードが必要になります。 **コスト** 定義された SLA を満たすために冗長性が必要なので、よりコストがかかります。 ### [](#ゼロダウンタイムデプロイモデル)ゼロダウンタイムデプロイモデル 目標は、SLA に影響を与えずに環境をすばやく変更することです。この変更には、インフラストラクチャやインフラストラクチャ上で実行中のアプリケーションのアップグレードを含みます。通常、ゼロダウンタイムデプロイでは、新旧のシステムが短期間共存するサイドバイサイドのデプロイが使用されます。これは、機能の低下や完全なダウンタイムが発生するインプレースのデプロイとは対照的です。 [Gartner](http://www.gartner.com/it-glossary/continuous-operations/)​ は連続稼働を次のように定義しています。「データ処理システムの特性で、定期メンテナンスなどの計画されたダウンタイムを低減または排除すること。24 時間 365 日稼働の 1 つの要素。」 ベースライン本番環境は、現在稼働中の環境です。変更 (ランタイムのアップグレード、設定、新しいアプリケーションなど) された新しい環境が作成されます。 ごく一部のトラフィックが新しい環境に送信され、新しい環境の信頼度が高まるにつれて増えていきます。新しい環境が完全稼働状態 (トラフィックの 100% を処理) になるまで、ベースライン本番環境は引き続き使用されます。新しい環境がすべてのトラフィックを受け入れるようになると、それが新しいベースライン本番環境となり、以前のベースライン本番環境は終了します。 下の例では、各環境は同じ数の Mule Runtime とコアを使用していると想定しています。実際には新しい環境がベースライン環境よりも多くなったり少なくなったりする可能性もあります。
デプロイの手順 図

新しい本番環境がデプロイされ、ごく一部のトラフィックが新しい環境に転送されます。

hadr zero downtime 1

新しい環境の信頼度が高まり、転送されるトラフィックが増えます。

hadr zero downtime 2

すべてのトラフィックが新しい環境に転送されます。

hadr zero downtime 3

すべてのトラフィックが新しい環境に転送され、新しい環境がベースライン本番環境に昇格します。以前のベースライン環境は終了します。

hadr zero downtime 4
**コスト** このデプロイ方法では、一時的にサービスの容量が追加される場合があります (数分間、数時間、または数日間)。 ## [](#障害回復)障害回復 **あなたの会社は、IT の緊急事態が発生した後にどれだけ迅速に業務に戻ることができますか?** 障害回復は、自然災害や人災が発生した後に、システムを以前の許容される状態に復元するプロセスです。ビジネス要件に沿って適切な DR 戦略を選択することが重要です。DR では、目標復旧時間 (RTO) や目標復旧時点 (RPO) などの測定可能な特性を使用して DR 計画を推進します。 障害回復で重要なのは目標復旧時点 (RPO) と目標復旧時間 (RTO) です。RPO は、IT 障害の後に戻る時点です。たとえば、24 時間ごとにバックアップしている場合、RPO は最長で 24 時間前になります。一方、RTO は、どれだけ迅速に RPO に戻して、業務に戻れるかということです。これには、プライマリ機器が機能しなくなったときに、予備の機器でバックアップの実行を開始する時間などの活動が含まれます。 システムバックアップは、しっかりとした障害回復プログラムの重要な要素です。回復には、コールド、ウォーム、ホットの 3 種類があります。
用語 定義 例

目標復旧時間 (RTO)

どれだけ迅速にこのアセットを復旧する必要があるか?

1 分? 15 分? 1 時間? 4 時間? 1 日?

目標復旧時点 (RPO)

このアセットはどれだけ新しいものに復旧する必要があるか?

データロスなし、15 分の有効期限?
CloudHub を使用した障害回復についての詳細は、​[「CloudHub High Availability and Disaster Recovery (CloudHub の高可用性と障害回復)」](https://docs.mulesoft.com/cloudhub/cloudhub-hadr)​を参照してください。 ## [](#ステートレスなインテグレーション)ステートレスなインテグレーション 一般的な設計原理として、インテグレーションが本質的にステートレスであることが常に重要です。つまり、さまざまなクライアントの呼び出しや実行 (スケジュールされたサービスの場合) の間でトランザクション情報を共有しないということです。システムの制約によって一部のデータをミドルウェアで管理する必要がある場合、そのデータはデータベースやメッセージングキューなどの外部ストアで保持し、ミドルウェアのインフラストラクチャやメモリの内部では保持しないようにする必要があります。拡張 (特にクラウドでの拡張) の際には、各ワーカー/ノードで使用される状態やリソースは他のワーカーとは独立している必要があることに注意することが重要です。このモデルを使用することで、パフォーマンス、スケーラビリティ、信頼性が向上します。 # 高可用性および障害回復 計画しているかどうかに関わらず、インフラストラクチャやアプリケーションのダウンタイムは、いつでも、どこからでも、どのような形でも発生する可能性があります。テクノロジーの停止、設備の破壊、人材の損失、重要なサードパーティサービスの損失の際に組織の稼働を継続できる能力は、ビジネスへの取り返しのつかないダメージを防ぐために不可欠です。世界的に E コマースへのシフトが進み、アプリケーションの 365 日 24 時間のアップタイムへの依存が高まっているため、高可用性 (HA) と障害回復 (DR) は、組織の財政状態に影響を及ぼします。 次の表は、少しのダウンタイムでも積み上げれば組織に悪影響を及ぼす可能性があることを示しています。
アップタイム率 ダウンタイム率 週間ダウンタイム 年間ダウンタイム

99%

1%

1.68 時間

3.65 日

99.9%

0.1%

10.1 分

8.75 時間

99.99%

0.01%

1 分

52.5 分

99.999%

0.001%

6 秒

5.25 分
## [](#高可用性と障害回復の比較)高可用性と障害回復の比較 - **高可用性 (HA)**​ - システムコンポーネントの障害が発生した際にシステムがアクセス可能な状態を維持する能力の基準。一般に HA は、システムに複数レベルのフォールトトレランス機能や負荷分散機能を構築することで実装されます。 - **障害回復 (DR)**​ - 自然災害 (洪水、竜巻、地震、火事など) や人災 (停電、サーバー障害、設定の誤りなど) が発生した後に、システムを以前の許容される状態に復元するプロセス。 どちらも全体的な可用性を高めますが、注目すべき違いは、HA では一般にサービスが停止しないことです。HA はサービスを保持し、DR はデータを保持しますが、DR では通常、DR 計画が実行されシステムが復元するまでの間にわずかなサービス停止が発生します。 ## [](#ha-および-dr-戦略のための-mule-のデプロイ)HA および DR 戦略のための Mule のデプロイ HA および DR 戦略に対応するために、さまざまなトポロジーで Mule Runtime をデプロイできます。1 つの方法は、クラスタリングを使用することです。これについては、このドキュメントの後のセクションで説明します。Mule 高可用性クラスタリングでは、Mule の基本的なフェールオーバー機能が提供されます。 JVM またはハードウェアの致命的な障害が発生したり、メンテナンスのためにオフラインになったりしたために、プライマリ Mule Runtime が使用できなくなった場合、バックアップ Mule Runtime が即座にプライマリノードになり、障害の発生したインスタンスが中断したところから処理を再開します。 システム管理者が障害が発生した Mule Runtime を回復してオンラインに戻すと、そのサーバーは自動的にバックアップノードになります。 ![hadr cluster](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/hadr-cluster.png) シームレスなフェールオーバーは、クラスタリングされた Mule Runtime ですべての一時的な状態の情報を共有する次のような分散メモリストアによって実現します。 - SEDA サービスイベントキュー - メモリ内メッセージキュー Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。 ## [](#効果的な-sla-の作成)効果的な SLA の作成 サービスレベル契約 (SLA) では、何が許容されるかについて具体的な定義の概要を定めます。 高可用性の基本的な定義は、サービスが起動して機能している、つまり適切に要求と応答を処理しているということです。これは、サービスが常に完全な機能を維持して稼働しているという意味ではありません。高可用性を考慮して設計されたシステムは、中断を防ぎ、第一に停止の発生を防ぎます。SLA では、すべての関係者に対する期待事項を定めます。 SLA 要件 - 単一障害点が排除されている - トラフィック/要求がリダイレクト/処理される - 障害の検出 たとえば、基本的なサービスの SLA は次のようになります。 - サービスの通常の運用では、1 秒あたり 1000 件のトランザクションを応答時間 1 秒で処理する。 - 1 年間の合計ダウンタイムは 0.5% (1.83 日) とする。 - 最小許容サービス影響レベルは、1 秒あたり 100 件のトランザクション、応答時間 1 秒を 1 週間に 2 時間とする。 関連情報 - [Defining SLA Tiers (SLA ティアの定義)](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) - [Rate Limiting and Throttling - SLA-Based Policies (レート制限および調整 - SLA ベースのポリシー)](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) ## [](#高可用性オプション)高可用性オプション 高可用性は、クラスタリングの使用やノードの負荷分散によって実現できます。定義された SLA に応じて、Mule には 4 つの HA オプションがあります。 - [\[Cold Standby\]](<#Cold Standby>) - [\[Warm Standby\]](<#Warm Standby>) - [\[Hot Standby - Active-Passive\]](<#Hot Standby - Active-Passive>) - [Active-Active](#active-active)
多くの場合、これらのオプションは障害回復戦略に関連します。
### [](#コールドスタンバイ)コールドスタンバイ
図 説明 ダウンタイム

hadr cold standby

Mule 環境がインストールされ、設定されています。ただし、1 つ以上のオペレーティングシステムが実行中ではありません。これは、本番システム/仮想マシンのバックアップとして使用できます。停止が検出された後にオペレーティングシステムの環境と Mule Runtime が起動されます。

あり。環境を起動してトラフィックを転送するのにかかる時間。
### [](#ウォームスタンバイ)ウォームスタンバイ
図 説明 ダウンタイム

hadr warm standby

Mule 環境がインストールされ、設定されています。ただし、Mule Runtime は実行されておらず、オペレーティングシステムのみが実行されています。停止が検出された後に Mule Runtime が起動されます。

少ない。Mule Runtime を起動し、トラフィックを環境に転送するのにかかる時間。
### [](#ホットスタンバイ-アクティブ-パッシブ)ホットスタンバイ - アクティブ-パッシブ
図 説明 ダウンタイム

hadr active passive

Mule 環境がインストールされ、設定され、完全に実行しています。ただし、停止が検出されるまでは要求を処理していません。

最小限またはなし。トラフィックを環境に転送する時間。
### [](#active-active)Active-Active
図 説明 ダウンタイム

hadr active active1

負荷分散クラスター環境。 完全に稼働している 2 つ以上の Mule 環境 (各環境に固有のクラスター) があります。ロードバランサーがすべての環境にトラフィックを転送します。

なし。サービスダウンタイムはありません。

hadr active active2

負荷分散単一クラスター環境。 2 つ以上の Mule 環境がありますが、それらは同じクラスター環境の一部です。このシナリオを実現するには、環境間のネットワークレイテンシーが 10 ミリ秒未満である必要があります。

なし。サービスダウンタイムはありません。
## [](#オンプレミスデプロイメントモデルの高可用性)オンプレミスデプロイメントモデルの高可用性 - [\[Active-Active Clustering Deployment Model\]](<#Active-Active Clustering Deployment Model>) - [\[Active-Active Clustering Fault Tolerance Deployment Model\]](<#Active-Active Clustering Fault Tolerance Deployment Model>) - [\[Zero Downtime Deployment Model\]](<#Zero Downtime Deployment Model>) ### [](#アクティブ-アクティブクラスタリングデプロイモデル)アクティブ-アクティブクラスタリングデプロイモデル クラスタリングされ負荷が分散されている環境の 2 つのノードで、応答時間 1 秒で 1,500 TPS をサポート可能です。この状態で、SLA の通常運用の条件を満たしています。ノードに障害が発生すると、サービスは影響を受けます。ただし、ノードは応答時間 1 秒で 700 TPS を処理でき、これは許容される影響レベルを大きく上回っているため、この障害による影響は SLA に違反しません。 ![hadr aa clustering](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/hadr-aa-clustering.png) 複数の Mule ノードに負荷を均等に分散させます。 - すべてのノードの機能は同じです。 - すべてのノードが同時にアクティブです。 **コスト** SLA 要件によって異なります。このモデルでは、SLA を満たすために 2 つのノードが必要です。SLA の許容可能なサービス影響が通常運用で指定されているのと同じ条件に変更されると、1 つのノード障害に対応するために環境に少なくとも 3 つのノードが必要です。2 つ以上のノードが実行中である状態を維持できない確率によっては、さらに多くのノードが必要な場合もあります。 ### [](#アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル)アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル フォールトトレランスの基本的な定義は、システム内の障害がサービスに全く影響を及ぼさないということです。これは、サービスの影響とダウンタイムへの耐性があるという点で高可用性とは異なります。 ![hadr fault tolerant](/mulesoft/current/ja-jp/mule-runtime/4.6/_images/hadr-fault-tolerant.png) フォールトトレランスでは、高可用性とは異なり、コンポーネント障害後にアプリケーションが中断なく機能し続けられるようにするための追加のリソースが提供されます。フォールトトレランス環境は高可用性環境よりもコストがかかります。 フォールトトレランスの度合を判断するには、システム障害の確率が必要です。高可用性のセクションで取り上げた SLA の例を使用して、最小許容サービス影響レベルが通常運用の要件と同じであるとします。 新しい全体的な SLA では、システムが 1 秒あたり 1000 件のトランザクションを処理し、応答時間 1 秒、ダウンタイムなし、サービスへの影響なしにする必要があります。 2 つ以上のノードで障害が発生する確率が低ければ、このアーキテクチャに必要なノードは 3 つで済みます。一方、2 つ以上のノードで障害が発生する確率が許容できないほど高い場合は、複数障害に対応するために 4 つ以上のノードが必要になります。 **コスト** 定義された SLA を満たすために冗長性が必要なので、よりコストがかかります。 ### [](#ゼロダウンタイムデプロイモデル)ゼロダウンタイムデプロイモデル 目標は、SLA に影響を与えずに環境をすばやく変更することです。この変更には、インフラストラクチャやインフラストラクチャ上で実行中のアプリケーションのアップグレードを含みます。通常、ゼロダウンタイムデプロイでは、新旧のシステムが短期間共存するサイドバイサイドのデプロイが使用されます。これは、機能の低下や完全なダウンタイムが発生するインプレースのデプロイとは対照的です。 [Gartner](http://www.gartner.com/it-glossary/continuous-operations/)​ は連続稼働を次のように定義しています。「データ処理システムの特性で、定期メンテナンスなどの計画されたダウンタイムを低減または排除すること。24 時間 365 日稼働の 1 つの要素。」 ベースライン本番環境は、現在稼働中の環境です。変更 (ランタイムのアップグレード、設定、新しいアプリケーションなど) された新しい環境が作成されます。 ごく一部のトラフィックが新しい環境に送信され、新しい環境の信頼度が高まるにつれて増えていきます。新しい環境が完全稼働状態 (トラフィックの 100% を処理) になるまで、ベースライン本番環境は引き続き使用されます。新しい環境がすべてのトラフィックを受け入れるようになると、それが新しいベースライン本番環境となり、以前のベースライン本番環境は終了します。 下の例では、各環境は同じ数の Mule Runtime とコアを使用していると想定しています。実際には新しい環境がベースライン環境よりも多くなったり少なくなったりする可能性もあります。
デプロイの手順 図

新しい本番環境がデプロイされ、ごく一部のトラフィックが新しい環境に転送されます。

hadr zero downtime 1

新しい環境の信頼度が高まり、転送されるトラフィックが増えます。

hadr zero downtime 2

すべてのトラフィックが新しい環境に転送されます。

hadr zero downtime 3

すべてのトラフィックが新しい環境に転送され、新しい環境がベースライン本番環境に昇格します。以前のベースライン環境は終了します。

hadr zero downtime 4
**コスト** このデプロイ方法では、一時的にサービスの容量が追加される場合があります (数分間、数時間、または数日間)。 ## [](#障害回復)障害回復 **あなたの会社は、IT の緊急事態が発生した後にどれだけ迅速に業務に戻ることができますか?** 障害回復は、自然災害や人災が発生した後に、システムを以前の許容される状態に復元するプロセスです。ビジネス要件に沿って適切な DR 戦略を選択することが重要です。DR では、目標復旧時間 (RTO) や目標復旧時点 (RPO) などの測定可能な特性を使用して DR 計画を推進します。 障害回復で重要なのは目標復旧時点 (RPO) と目標復旧時間 (RTO) です。RPO は、IT 障害の後に戻る時点です。たとえば、24 時間ごとにバックアップしている場合、RPO は最長で 24 時間前になります。一方、RTO は、どれだけ迅速に RPO に戻して、業務に戻れるかということです。これには、プライマリ機器が機能しなくなったときに、予備の機器でバックアップの実行を開始する時間などの活動が含まれます。 システムバックアップは、しっかりとした障害回復プログラムの重要な要素です。回復には、コールド、ウォーム、ホットの 3 種類があります。
用語 定義 例

目標復旧時間 (RTO)

どれだけ迅速にこのアセットを復旧する必要があるか?

1 分? 15 分? 1 時間? 4 時間? 1 日?

目標復旧時点 (RPO)

このアセットはどれだけ新しいものに復旧する必要があるか?

データロスなし、15 分の有効期限?
CloudHub を使用した障害回復についての詳細は、​[「CloudHub High Availability and Disaster Recovery (CloudHub の高可用性と障害回復)」](https://docs.mulesoft.com/cloudhub/cloudhub-hadr)​を参照してください。 ## [](#ステートレスなインテグレーション)ステートレスなインテグレーション 一般的な設計原理として、インテグレーションが本質的にステートレスであることが常に重要です。つまり、さまざまなクライアントの呼び出しや実行 (スケジュールされたサービスの場合) の間でトランザクション情報を共有しないということです。システムの制約によって一部のデータをミドルウェアで管理する必要がある場合、そのデータはデータベースやメッセージングキューなどの外部ストアで保持し、ミドルウェアのインフラストラクチャやメモリの内部では保持しないようにする必要があります。拡張 (特にクラウドでの拡張) の際には、各ワーカー/ノードで使用される状態やリソースは他のワーカーとは独立している必要があることに注意することが重要です。このモデルを使用することで、パフォーマンス、スケーラビリティ、信頼性が向上します。 # 高可用性および障害回復 計画しているかどうかに関わらず、インフラストラクチャやアプリケーションのダウンタイムは、いつでも、どこからでも、どのような形でも発生する可能性があります。テクノロジーの停止、設備の破壊、人材の損失、重要なサードパーティサービスの損失の際に組織の稼働を継続できる能力は、ビジネスへの取り返しのつかないダメージを防ぐために不可欠です。世界的に E コマースへのシフトが進み、アプリケーションの 365 日 24 時間のアップタイムへの依存が高まっているため、高可用性 (HA) と障害回復 (DR) は、組織の財政状態に影響を及ぼします。 次の表は、少しのダウンタイムでも積み上げれば組織に悪影響を及ぼす可能性があることを示しています。
アップタイム率 ダウンタイム率 週間ダウンタイム 年間ダウンタイム

99%

1%

1.68 時間

3.65 日

99.9%

0.1%

10.1 分

8.75 時間

99.99%

0.01%

1 分

52.5 分

99.999%

0.001%

6 秒

5.25 分
## [](#高可用性と障害回復の比較)高可用性と障害回復の比較 - **高可用性 (HA)**​ - システムコンポーネントの障害が発生した際にシステムがアクセス可能な状態を維持する能力の基準。一般に HA は、システムに複数レベルのフォールトトレランス機能や負荷分散機能を構築することで実装されます。 - **障害回復 (DR)**​ - 自然災害 (洪水、竜巻、地震、火事など) や人災 (停電、サーバー障害、設定の誤りなど) が発生した後に、システムを以前の許容される状態に復元するプロセス。 どちらも全体的な可用性を高めますが、注目すべき違いは、HA では一般にサービスが停止しないことです。HA はサービスを保持し、DR はデータを保持しますが、DR では通常、DR 計画が実行されシステムが復元するまでの間にわずかなサービス停止が発生します。 ## [](#ha-および-dr-戦略のための-mule-のデプロイ)HA および DR 戦略のための Mule のデプロイ HA および DR 戦略に対応するために、さまざまなトポロジーで Mule Runtime をデプロイできます。1 つの方法は、クラスタリングを使用することです。これについては、このドキュメントの後のセクションで説明します。Mule 高可用性クラスタリングでは、Mule の基本的なフェールオーバー機能が提供されます。 JVM またはハードウェアの致命的な障害が発生したり、メンテナンスのためにオフラインになったりしたために、プライマリ Mule Runtime が使用できなくなった場合、バックアップ Mule Runtime が即座にプライマリノードになり、障害の発生したインスタンスが中断したところから処理を再開します。 システム管理者が障害が発生した Mule Runtime を回復してオンラインに戻すと、そのサーバーは自動的にバックアップノードになります。 ![送受信メッセージを処理するクラスターサーバー環境](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/hadr-cluster.png) シームレスなフェールオーバーは、クラスタリングされた Mule Runtime ですべての一時的な状態の情報を共有する次のような分散メモリストアによって実現します。 - SEDA サービスイベントキュー - メモリ内メッセージキュー Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。 ## [](#効果的な-sla-の作成)効果的な SLA の作成 サービスレベル契約 (SLA) では、何が許容されるかについて具体的な定義の概要を定めます。 高可用性の基本的な定義は、サービスが起動して機能している、つまり適切に要求と応答を処理しているということです。これは、サービスが常に完全な機能を維持して稼働しているという意味ではありません。高可用性を考慮して設計されたシステムは、中断を防ぎ、第一に停止の発生を防ぎます。SLA では、すべての関係者に対する期待事項を定めます。 SLA 要件 - 単一障害点が排除されている - トラフィック/要求がリダイレクト/処理される - 障害の検出 たとえば、基本的なサービスの SLA は次のようになります。 - サービスの通常の運用では、1 秒あたり 1000 件のトランザクションを応答時間 1 秒で処理する。 - 1 年間の合計ダウンタイムは 0.5% (1.83 日) とする。 - 最小許容サービス影響レベルは、1 秒あたり 100 件のトランザクション、応答時間 1 秒を 1 週間に 2 時間とする。 関連情報 - [Defining SLA Tiers (SLA ティアの定義)](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) - [Rate Limiting and Throttling - SLA-Based Policies (レート制限および調整 - SLA ベースのポリシー)](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) ## [](#高可用性オプション)高可用性オプション 高可用性は、クラスタリングの使用やノードの負荷分散によって実現できます。定義された SLA に応じて、Mule には 4 つの HA オプションがあります。 - [\[Cold Standby\]](<#Cold Standby>) - [\[Warm Standby\]](<#Warm Standby>) - [\[Hot Standby - Active-Passive\]](<#Hot Standby - Active-Passive>) - [Active-Active](#active-active)
多くの場合、これらのオプションは障害回復戦略に関連します。
### [](#コールドスタンバイ)コールドスタンバイ
図 説明 ダウンタイム

サーバーセットアップのコールドスタンバイ設定

Mule 環境がインストールされ、設定されています。ただし、1 つ以上のオペレーティングシステムが実行中ではありません。これは、本番システム/仮想マシンのバックアップとして使用できます。停止が検出された後にオペレーティングシステムの環境と Mule Runtime が起動されます。

あり。環境を起動してトラフィックを転送するのにかかる時間。
### [](#ウォームスタンバイ)ウォームスタンバイ
図 説明 ダウンタイム

サーバーの冗長性を確保するためのウォームスタンバイセットアップ

Mule 環境がインストールされ、設定されています。ただし、Mule Runtime は実行されておらず、オペレーティングシステムのみが実行されています。停止が検出された後に Mule Runtime が起動されます。

少ない。Mule Runtime を起動し、トラフィックを環境に転送するのにかかる時間。
### [](#ホットスタンバイ-アクティブ-パッシブ)ホットスタンバイ - アクティブ-パッシブ
図 説明 ダウンタイム

高可用性設定のアクティブ-パッシブサーバーセットアップ

Mule 環境がインストールされ、設定され、完全に実行しています。ただし、停止が検出されるまでは要求を処理していません。

最小限またはなし。トラフィックを環境に転送する時間。
### [](#active-active)Active-Active
図 説明 ダウンタイム

アクティブ-アクティブ設定の Mule インスタンスのクラスターにトラフィックを分散するロードバランサー

負荷分散クラスター環境。 完全に稼働している 2 つ以上の Mule 環境 (各環境に固有のクラスター) があります。ロードバランサーがすべての環境にトラフィックを転送します。

なし。サービスダウンタイムはありません。

ロードバランサーとクラスタリングが含まれるアクティブ-アクティブサーバー設定

負荷分散単一クラスター環境。 2 つ以上の Mule 環境がありますが、それらは同じクラスター環境の一部です。このシナリオを実現するには、環境間のネットワークレイテンシーが 10 ミリ秒未満である必要があります。

なし。サービスダウンタイムはありません。
## [](#オンプレミスデプロイメントモデルの高可用性)オンプレミスデプロイメントモデルの高可用性 - [\[Active-Active Clustering Deployment Model\]](<#Active-Active Clustering Deployment Model>) - [\[Active-Active Clustering Fault Tolerance Deployment Model\]](<#Active-Active Clustering Fault Tolerance Deployment Model>) - [\[Zero Downtime Deployment Model\]](<#Zero Downtime Deployment Model>) ### [](#アクティブ-アクティブクラスタリングデプロイモデル)アクティブ-アクティブクラスタリングデプロイモデル クラスタリングされ負荷が分散されている環境の 2 つのノードで、応答時間 1 秒で 1,500 TPS をサポート可能です。この状態で、SLA の通常運用の条件を満たしています。ノードに障害が発生すると、サービスは影響を受けます。ただし、ノードは応答時間 1 秒で 700 TPS を処理でき、これは許容される影響レベルを大きく上回っているため、この障害による影響は SLA に違反しません。 ![ロードバランサーと複数のサーバーが含まれるアクティブ-アクティブクラスタリングセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/hadr-aa-clustering.png) 複数の Mule ノードに負荷を均等に分散させます。 - すべてのノードの機能は同じです。 - すべてのノードが同時にアクティブです。 **コスト** SLA 要件によって異なります。このモデルでは、SLA を満たすために 2 つのノードが必要です。SLA の許容可能なサービス影響が通常運用で指定されているのと同じ条件に変更されると、1 つのノード障害に対応するために環境に少なくとも 3 つのノードが必要です。2 つ以上のノードが実行中である状態を維持できない確率によっては、さらに多くのノードが必要な場合もあります。 ### [](#アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル)アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル フォールトトレランスの基本的な定義は、システム内の障害がサービスに全く影響を及ぼさないということです。これは、サービスの影響とダウンタイムへの耐性があるという点で高可用性とは異なります。 ![冗長性ノードとロードバランサーが含まれるフォールトトレランスシステム](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/hadr-fault-tolerant.png) フォールトトレランスでは、高可用性とは異なり、コンポーネント障害後にアプリケーションが中断なく機能し続けられるようにするための追加のリソースが提供されます。フォールトトレランス環境は高可用性環境よりもコストがかかります。 フォールトトレランスの度合を判断するには、システム障害の確率が必要です。高可用性のセクションで取り上げた SLA の例を使用して、最小許容サービス影響レベルが通常運用の要件と同じであるとします。 新しい全体的な SLA では、システムが 1 秒あたり 1000 件のトランザクションを処理し、応答時間 1 秒、ダウンタイムなし、サービスへの影響なしにする必要があります。 2 つ以上のノードで障害が発生する確率が低ければ、このアーキテクチャに必要なノードは 3 つで済みます。一方、2 つ以上のノードで障害が発生する確率が許容できないほど高い場合は、複数障害に対応するために 4 つ以上のノードが必要になります。 **コスト** 定義された SLA を満たすために冗長性が必要なので、よりコストがかかります。 ### [](#ゼロダウンタイムデプロイモデル)ゼロダウンタイムデプロイモデル 目標は、SLA に影響を与えずに環境をすばやく変更することです。この変更には、インフラストラクチャやインフラストラクチャ上で実行中のアプリケーションのアップグレードを含みます。通常、ゼロダウンタイムデプロイでは、新旧のシステムが短期間共存するサイドバイサイドのデプロイが使用されます。これは、機能の低下や完全なダウンタイムが発生するインプレースのデプロイとは対照的です。 [Gartner](http://www.gartner.com/it-glossary/continuous-operations/)​ は連続稼働を次のように定義しています。「データ処理システムの特性で、定期メンテナンスなどの計画されたダウンタイムを低減または排除すること。24 時間 365 日稼働の 1 つの要素。」 ベースライン本番環境は、現在稼働中の環境です。変更 (ランタイムのアップグレード、設定、新しいアプリケーションなど) された新しい環境が作成されます。 ごく一部のトラフィックが新しい環境に送信され、新しい環境の信頼度が高まるにつれて増えていきます。新しい環境が完全稼働状態 (トラフィックの 100% を処理) になるまで、ベースライン本番環境は引き続き使用されます。新しい環境がすべてのトラフィックを受け入れるようになると、それが新しいベースライン本番環境となり、以前のベースライン本番環境は終了します。 下の例では、各環境は同じ数の Mule Runtime とコアを使用していると想定しています。実際には新しい環境がベースライン環境よりも多くなったり少なくなったりする可能性もあります。
デプロイの手順 図

新しい本番環境がデプロイされ、ごく一部のトラフィックが新しい環境に転送されます。

高可用性デプロイメントの現在の本番環境から新しい本番環境へのトラフィック分散 (新しい本番環境への割合の方が少ない)

新しい環境の信頼度が高まり、転送されるトラフィックが増えます。

高可用性デプロイメントの現在の本番環境から新しい本番環境へのトラフィック分散 (新しい本番環境への割合の方が多い)

すべてのトラフィックが新しい環境に転送されます。

現在の環境から新しい環境にトラフィックを切り替える、ダウンタイムなしのデプロイメント

すべてのトラフィックが新しい環境に転送され、新しい環境がベースライン本番環境に昇格します。以前のベースライン環境は終了します。

高可用性環境の新しい本番環境へのトラフィックルーティング (新しい本番環境への割合が 100%)
**コスト** このデプロイ方法では、一時的にサービスの容量が追加される場合があります (数分間、数時間、または数日間)。 ## [](#障害回復)障害回復 **あなたの会社は、IT の緊急事態が発生した後にどれだけ迅速に業務に戻ることができますか?** 障害回復は、自然災害や人災が発生した後に、システムを以前の許容される状態に復元するプロセスです。ビジネス要件に沿って適切な DR 戦略を選択することが重要です。DR では、目標復旧時間 (RTO) や目標復旧時点 (RPO) などの測定可能な特性を使用して DR 計画を推進します。 障害回復で重要なのは目標復旧時点 (RPO) と目標復旧時間 (RTO) です。RPO は、IT 障害の後に戻る時点です。たとえば、24 時間ごとにバックアップしている場合、RPO は最長で 24 時間前になります。一方、RTO は、どれだけ迅速に RPO に戻して、業務に戻れるかということです。これには、プライマリ機器が機能しなくなったときに、予備の機器でバックアップの実行を開始する時間などの活動が含まれます。 システムバックアップは、しっかりとした障害回復プログラムの重要な要素です。回復には、コールド、ウォーム、ホットの 3 種類があります。
用語 定義 例

目標復旧時間 (RTO)

どれだけ迅速にこのアセットを復旧する必要があるか?

1 分? 15 分? 1 時間? 4 時間? 1 日?

目標復旧時点 (RPO)

このアセットはどれだけ新しいものに復旧する必要があるか?

データロスなし、15 分の有効期限?
CloudHub を使用した障害回復についての詳細は、​[「CloudHub High Availability and Disaster Recovery (CloudHub の高可用性と障害回復)」](https://docs.mulesoft.com/cloudhub/cloudhub-hadr)​を参照してください。 ## [](#ステートレスなインテグレーション)ステートレスなインテグレーション 一般的な設計原理として、インテグレーションが本質的にステートレスであることが常に重要です。つまり、さまざまなクライアントの呼び出しや実行 (スケジュールされたサービスの場合) の間でトランザクション情報を共有しないということです。システムの制約によって一部のデータをミドルウェアで管理する必要がある場合、そのデータはデータベースやメッセージングキューなどの外部ストアで保持し、ミドルウェアのインフラストラクチャやメモリの内部では保持しないようにする必要があります。拡張 (特にクラウドでの拡張) の際には、各ワーカー/ノードで使用される状態やリソースは他のワーカーとは独立している必要があることに注意することが重要です。このモデルを使用することで、パフォーマンス、スケーラビリティ、信頼性が向上します。 # 高可用性および障害回復 計画しているかどうかに関わらず、インフラストラクチャやアプリケーションのダウンタイムは、いつでも、どこからでも、どのような形でも発生する可能性があります。テクノロジーの停止、設備の破壊、人材の損失、重要なサードパーティサービスの損失の際に組織の稼働を継続できる能力は、ビジネスへの取り返しのつかないダメージを防ぐために不可欠です。世界的に E コマースへのシフトが進み、アプリケーションの 365 日 24 時間のアップタイムへの依存が高まっているため、高可用性 (HA) と障害回復 (DR) は、組織の財政状態に影響を及ぼします。 次の表は、少しのダウンタイムでも積み上げれば組織に悪影響を及ぼす可能性があることを示しています。
アップタイム率 ダウンタイム率 週間ダウンタイム 年間ダウンタイム

99%

1%

1.68 時間

3.65 日

99.9%

0.1%

10.1 分

8.75 時間

99.99%

0.01%

1 分

52.5 分

99.999%

0.001%

6 秒

5.25 分
## [](#高可用性と障害回復の比較)高可用性と障害回復の比較 - **高可用性 (HA)**​ - システムコンポーネントの障害が発生した際にシステムがアクセス可能な状態を維持する能力の基準。一般に HA は、システムに複数レベルのフォールトトレランス機能や負荷分散機能を構築することで実装されます。 - **障害回復 (DR)**​ - 自然災害 (洪水、竜巻、地震、火事など) や人災 (停電、サーバー障害、設定の誤りなど) が発生した後に、システムを以前の許容される状態に復元するプロセス。 どちらも全体的な可用性を高めますが、注目すべき違いは、HA では一般にサービスが停止しないことです。HA はサービスを保持し、DR はデータを保持しますが、DR では通常、DR 計画が実行されシステムが復元するまでの間にわずかなサービス停止が発生します。 ## [](#ha-および-dr-戦略のための-mule-のデプロイ)HA および DR 戦略のための Mule のデプロイ HA および DR 戦略に対応するために、さまざまなトポロジーで Mule Runtime をデプロイできます。1 つの方法は、クラスタリングを使用することです。これについては、このドキュメントの後のセクションで説明します。Mule 高可用性クラスタリングでは、Mule の基本的なフェールオーバー機能が提供されます。 JVM またはハードウェアの致命的な障害が発生したり、メンテナンスのためにオフラインになったりしたために、プライマリ Mule Runtime が使用できなくなった場合、バックアップ Mule Runtime が即座にプライマリノードになり、障害の発生したインスタンスが中断したところから処理を再開します。 システム管理者が障害が発生した Mule Runtime を回復してオンラインに戻すと、そのサーバーは自動的にバックアップノードになります。 ![送受信メッセージを処理するクラスターサーバー環境](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/hadr-cluster.png) シームレスなフェールオーバーは、クラスタリングされた Mule Runtime ですべての一時的な状態の情報を共有する次のような分散メモリストアによって実現します。 - SEDA サービスイベントキュー - メモリ内メッセージキュー Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。 ## [](#効果的な-sla-の作成)効果的な SLA の作成 サービスレベル契約 (SLA) では、何が許容されるかについて具体的な定義の概要を定めます。 高可用性の基本的な定義は、サービスが起動して機能している、つまり適切に要求と応答を処理しているということです。これは、サービスが常に完全な機能を維持して稼働しているという意味ではありません。高可用性を考慮して設計されたシステムは、中断を防ぎ、第一に停止の発生を防ぎます。SLA では、すべての関係者に対する期待事項を定めます。 SLA 要件 - 単一障害点が排除されている - トラフィック/要求がリダイレクト/処理される - 障害の検出 たとえば、基本的なサービスの SLA は次のようになります。 - サービスの通常の運用では、1 秒あたり 1000 件のトランザクションを応答時間 1 秒で処理する。 - 1 年間の合計ダウンタイムは 0.5% (1.83 日) とする。 - 最小許容サービス影響レベルは、1 秒あたり 100 件のトランザクション、応答時間 1 秒を 1 週間に 2 時間とする。 関連情報 - [Defining SLA Tiers (SLA ティアの定義)](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) - [Rate Limiting and Throttling - SLA-Based Policies (レート制限および調整 - SLA ベースのポリシー)](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) ## [](#高可用性オプション)高可用性オプション 高可用性は、クラスタリングの使用やノードの負荷分散によって実現できます。定義された SLA に応じて、Mule には 4 つの HA オプションがあります。 - [\[Cold Standby\]](<#Cold Standby>) - [\[Warm Standby\]](<#Warm Standby>) - [\[Hot Standby - Active-Passive\]](<#Hot Standby - Active-Passive>) - [Active-Active](#active-active)
多くの場合、これらのオプションは障害回復戦略に関連します。
### [](#コールドスタンバイ)コールドスタンバイ
図 説明 ダウンタイム

サーバーセットアップのコールドスタンバイ設定

Mule 環境がインストールされ、設定されています。ただし、1 つ以上のオペレーティングシステムが実行中ではありません。これは、本番システム/仮想マシンのバックアップとして使用できます。停止が検出された後にオペレーティングシステムの環境と Mule Runtime が起動されます。

あり。環境を起動してトラフィックを転送するのにかかる時間。
### [](#ウォームスタンバイ)ウォームスタンバイ
図 説明 ダウンタイム

サーバーの冗長性を確保するためのウォームスタンバイセットアップ

Mule 環境がインストールされ、設定されています。ただし、Mule Runtime は実行されておらず、オペレーティングシステムのみが実行されています。停止が検出された後に Mule Runtime が起動されます。

少ない。Mule Runtime を起動し、トラフィックを環境に転送するのにかかる時間。
### [](#ホットスタンバイ-アクティブ-パッシブ)ホットスタンバイ - アクティブ-パッシブ
図 説明 ダウンタイム

高可用性設定のアクティブ-パッシブサーバーセットアップ

Mule 環境がインストールされ、設定され、完全に実行しています。ただし、停止が検出されるまでは要求を処理していません。

最小限またはなし。トラフィックを環境に転送する時間。
### [](#active-active)Active-Active
図 説明 ダウンタイム

アクティブ-アクティブ設定の Mule インスタンスのクラスターにトラフィックを分散するロードバランサー

負荷分散クラスター環境。 完全に稼働している 2 つ以上の Mule 環境 (各環境に固有のクラスター) があります。ロードバランサーがすべての環境にトラフィックを転送します。

なし。サービスダウンタイムはありません。

ロードバランサーとクラスタリングが含まれるアクティブ-アクティブサーバー設定

負荷分散単一クラスター環境。 2 つ以上の Mule 環境がありますが、それらは同じクラスター環境の一部です。このシナリオを実現するには、環境間のネットワークレイテンシーが 10 ミリ秒未満である必要があります。

なし。サービスダウンタイムはありません。
## [](#オンプレミスデプロイメントモデルの高可用性)オンプレミスデプロイメントモデルの高可用性 - [\[Active-Active Clustering Deployment Model\]](<#Active-Active Clustering Deployment Model>) - [\[Active-Active Clustering Fault Tolerance Deployment Model\]](<#Active-Active Clustering Fault Tolerance Deployment Model>) - [\[Zero Downtime Deployment Model\]](<#Zero Downtime Deployment Model>) ### [](#アクティブ-アクティブクラスタリングデプロイモデル)アクティブ-アクティブクラスタリングデプロイモデル クラスタリングされ負荷が分散されている環境の 2 つのノードで、応答時間 1 秒で 1,500 TPS をサポート可能です。この状態で、SLA の通常運用の条件を満たしています。ノードに障害が発生すると、サービスは影響を受けます。ただし、ノードは応答時間 1 秒で 700 TPS を処理でき、これは許容される影響レベルを大きく上回っているため、この障害による影響は SLA に違反しません。 ![ロードバランサーと複数のサーバーが含まれるアクティブ-アクティブクラスタリングセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/hadr-aa-clustering.png) 複数の Mule ノードに負荷を均等に分散させます。 - すべてのノードの機能は同じです。 - すべてのノードが同時にアクティブです。 **コスト** SLA 要件によって異なります。このモデルでは、SLA を満たすために 2 つのノードが必要です。SLA の許容可能なサービス影響が通常運用で指定されているのと同じ条件に変更されると、1 つのノード障害に対応するために環境に少なくとも 3 つのノードが必要です。2 つ以上のノードが実行中である状態を維持できない確率によっては、さらに多くのノードが必要な場合もあります。 ### [](#アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル)アクティブ-アクティブクラスタリングフォールトトレランスデプロイモデル フォールトトレランスの基本的な定義は、システム内の障害がサービスに全く影響を及ぼさないということです。これは、サービスの影響とダウンタイムへの耐性があるという点で高可用性とは異なります。 ![冗長性ノードとロードバランサーが含まれるフォールトトレランスシステム](/mulesoft/current/ja-jp/mule-runtime/4.8/_images/hadr-fault-tolerant.png) フォールトトレランスでは、高可用性とは異なり、コンポーネント障害後にアプリケーションが中断なく機能し続けられるようにするための追加のリソースが提供されます。フォールトトレランス環境は高可用性環境よりもコストがかかります。 フォールトトレランスの度合を判断するには、システム障害の確率が必要です。高可用性のセクションで取り上げた SLA の例を使用して、最小許容サービス影響レベルが通常運用の要件と同じであるとします。 新しい全体的な SLA では、システムが 1 秒あたり 1000 件のトランザクションを処理し、応答時間 1 秒、ダウンタイムなし、サービスへの影響なしにする必要があります。 2 つ以上のノードで障害が発生する確率が低ければ、このアーキテクチャに必要なノードは 3 つで済みます。一方、2 つ以上のノードで障害が発生する確率が許容できないほど高い場合は、複数障害に対応するために 4 つ以上のノードが必要になります。 **コスト** 定義された SLA を満たすために冗長性が必要なので、よりコストがかかります。 ### [](#ゼロダウンタイムデプロイモデル)ゼロダウンタイムデプロイモデル 目標は、SLA に影響を与えずに環境をすばやく変更することです。この変更には、インフラストラクチャやインフラストラクチャ上で実行中のアプリケーションのアップグレードを含みます。通常、ゼロダウンタイムデプロイでは、新旧のシステムが短期間共存するサイドバイサイドのデプロイが使用されます。これは、機能の低下や完全なダウンタイムが発生するインプレースのデプロイとは対照的です。 [Gartner](http://www.gartner.com/it-glossary/continuous-operations/)​ は連続稼働を次のように定義しています。「データ処理システムの特性で、定期メンテナンスなどの計画されたダウンタイムを低減または排除すること。24 時間 365 日稼働の 1 つの要素。」 ベースライン本番環境は、現在稼働中の環境です。変更 (ランタイムのアップグレード、設定、新しいアプリケーションなど) された新しい環境が作成されます。 ごく一部のトラフィックが新しい環境に送信され、新しい環境の信頼度が高まるにつれて増えていきます。新しい環境が完全稼働状態 (トラフィックの 100% を処理) になるまで、ベースライン本番環境は引き続き使用されます。新しい環境がすべてのトラフィックを受け入れるようになると、それが新しいベースライン本番環境となり、以前のベースライン本番環境は終了します。 下の例では、各環境は同じ数の Mule Runtime とコアを使用していると想定しています。実際には新しい環境がベースライン環境よりも多くなったり少なくなったりする可能性もあります。
デプロイの手順 図

新しい本番環境がデプロイされ、ごく一部のトラフィックが新しい環境に転送されます。

高可用性デプロイメントの現在の本番環境から新しい本番環境へのトラフィック分散 (新しい本番環境への割合の方が少ない)

新しい環境の信頼度が高まり、転送されるトラフィックが増えます。

高可用性デプロイメントの現在の本番環境から新しい本番環境へのトラフィック分散 (新しい本番環境への割合の方が多い)

すべてのトラフィックが新しい環境に転送されます。

現在の環境から新しい環境にトラフィックを切り替える、ダウンタイムなしのデプロイメント

すべてのトラフィックが新しい環境に転送され、新しい環境がベースライン本番環境に昇格します。以前のベースライン環境は終了します。

高可用性環境の新しい本番環境へのトラフィックルーティング (新しい本番環境への割合が 100%)
**コスト** このデプロイ方法では、一時的にサービスの容量が追加される場合があります (数分間、数時間、または数日間)。 ## [](#障害回復)障害回復 **あなたの会社は、IT の緊急事態が発生した後にどれだけ迅速に業務に戻ることができますか?** 障害回復は、自然災害や人災が発生した後に、システムを以前の許容される状態に復元するプロセスです。ビジネス要件に沿って適切な DR 戦略を選択することが重要です。DR では、目標復旧時間 (RTO) や目標復旧時点 (RPO) などの測定可能な特性を使用して DR 計画を推進します。 障害回復で重要なのは目標復旧時点 (RPO) と目標復旧時間 (RTO) です。RPO は、IT 障害の後に戻る時点です。たとえば、24 時間ごとにバックアップしている場合、RPO は最長で 24 時間前になります。一方、RTO は、どれだけ迅速に RPO に戻して、業務に戻れるかということです。これには、プライマリ機器が機能しなくなったときに、予備の機器でバックアップの実行を開始する時間などの活動が含まれます。 システムバックアップは、しっかりとした障害回復プログラムの重要な要素です。回復には、コールド、ウォーム、ホットの 3 種類があります。
用語 定義 例

目標復旧時間 (RTO)

どれだけ迅速にこのアセットを復旧する必要があるか?

1 分? 15 分? 1 時間? 4 時間? 1 日?

目標復旧時点 (RPO)

このアセットはどれだけ新しいものに復旧する必要があるか?

データロスなし、15 分の有効期限?
CloudHub を使用した障害回復についての詳細は、​[「CloudHub High Availability and Disaster Recovery (CloudHub の高可用性と障害回復)」](https://docs.mulesoft.com/cloudhub/cloudhub-hadr)​を参照してください。 ## [](#ステートレスなインテグレーション)ステートレスなインテグレーション 一般的な設計原理として、インテグレーションが本質的にステートレスであることが常に重要です。つまり、さまざまなクライアントの呼び出しや実行 (スケジュールされたサービスの場合) の間でトランザクション情報を共有しないということです。システムの制約によって一部のデータをミドルウェアで管理する必要がある場合、そのデータはデータベースやメッセージングキューなどの外部ストアで保持し、ミドルウェアのインフラストラクチャやメモリの内部では保持しないようにする必要があります。拡張 (特にクラウドでの拡張) の際には、各ワーカー/ノードで使用される状態やリソースは他のワーカーとは独立している必要があることに注意することが重要です。このモデルを使用することで、パフォーマンス、スケーラビリティ、信頼性が向上します。 # 高可用性および障害回復 計画しているかどうかに関わらず、インフラストラクチャやアプリケーションのダウンタイムは、いつでも、どこからでも、どのような形でも発生する可能性があります。テクノロジーの停止、設備の破壊、人材の損失、重要なサードパーティサービスの損失の際に組織の稼働を継続できる能力は、ビジネスへの取り返しのつかないダメージを防ぐために不可欠です。世界的に E コマースへのシフトが進み、アプリケーションの 365 日 24 時間のアップタイムへの依存が高まっているため、高可用性 (HA) と障害回復 (DR) は、組織の財政状態に影響を及ぼします。 次の表は、少しのダウンタイムでも積み上げれば組織に悪影響を及ぼす可能性があることを示しています。
アップタイム率 ダウンタイム率 週間ダウンタイム 年間ダウンタイム

99%

1%

1.68 時間

3.65 日

99.9%

0.1%

10.1 分

8.75 時間

99.99%

0.01%

1 分

52.5 分

99.999%

0.001%

6 秒

5.25 分
## [](#高可用性と障害回復の比較)高可用性と障害回復の比較 - **高可用性 (HA)**​ - システムコンポーネントの障害が発生した際にシステムがアクセス可能な状態を維持する能力の基準。一般に HA は、システムに複数レベルのフォールトトレランス機能や負荷分散機能を構築することで実装されます。 - **障害回復 (DR)**​ - 自然災害 (洪水、竜巻、地震、火事など) や人災 (停電、サーバー障害、設定の誤りなど) が発生した後に、システムを以前の許容される状態に復元するプロセス。 どちらも全体的な可用性を高めますが、注目すべき違いは、HA では一般にサービスが停止しないことです。HA はサービスを保持し、DR はデータを保持しますが、DR では通常、DR 計画が実行されシステムが復元するまでの間にわずかなサービス停止が発生します。 ## [](#ha-および-dr-戦略のための-mule-のデプロイ)HA および DR 戦略のための Mule のデプロイ HA および DR 戦略に対応するために、さまざまなトポロジーで Mule Runtime をデプロイできます。1 つの方法は、クラスタリングを使用することです。これについては、このドキュメントの後のセクションで説明します。Mule 高可用性クラスタリングでは、Mule の基本的なフェールオーバー機能が提供されます。 JVM またはハードウェアの致命的な障害が発生したり、メンテナンスのためにオフラインになったりしたために、プライマリ Mule Runtime が使用できなくなった場合、バックアップ Mule Runtime が即座にプライマリノードになり、障害の発生したインスタンスが中断したところから処理を再開します。 システム管理者が障害が発生した Mule Runtime を回復してオンラインに戻すと、そのサーバーは自動的にバックアップノードになります。 ![送受信メッセージを処理するクラスターサーバー環境](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/hadr-cluster.png) シームレスなフェールオーバーは、クラスタリングされた Mule Runtime ですべての一時的な状態の情報を共有する次のような分散メモリストアによって実現します。 - SEDA サービスイベントキュー - メモリ内メッセージキュー Mule アプリケーションをビルドする場合、目的の可用性、フォールトトレランス、パフォーマンス特性を実現するために、アプリケーションの最適な設計方法についてよく考えることが重要です。 ## [](#効果的な-sla-の作成)効果的な SLA の作成 サービスレベル契約 (SLA) では、何が許容されるかについて具体的な定義の概要を定めます。 高可用性の基本的な定義は、サービスが起動して機能している、つまり適切に要求と応答を処理しているということです。これは、サービスが常に完全な機能を維持して稼働しているという意味ではありません。高可用性を考慮して設計されたシステムは、中断を防ぎ、第一に停止の発生を防ぎます。SLA では、すべての関係者に対する期待事項を定めます。 SLA 要件 - 単一障害点が排除されている - トラフィック/要求がリダイレクト/処理される - 障害の検出 たとえば、基本的なサービスの SLA は次のようになります。 - サービスの通常の運用では、1 秒あたり 1000 件のトランザクションを応答時間 1 秒で処理する。 - 1 年間の合計ダウンタイムは 0.5% (1.83 日) とする。 - 最小許容サービス影響レベルは、1 秒あたり 100 件のトランザクション、応答時間 1 秒を 1 週間に 2 時間とする。 関連情報 - [Defining SLA Tiers (SLA ティアの定義)](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) - [Rate Limiting and Throttling - SLA-Based Policies (レート制限および調整 - SLA ベースのポリシー)](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) ## [](#高可用性オプション)高可用性オプション 高可用性は、クラスタリングの使用やノードの負荷分散によって実現できます。定義された SLA に応じて、Mule には 4 つの HA オプションがあります。 - [\[Cold Standby\]](<#Cold Standby>) - [\[Warm Standby\]](<#Warm Standby>) - [\[Hot Standby - Active-Passive\]](<#Hot Standby - Active-Passive>) - [Active-Active](#active-active)
多くの場合、これらのオプションは障害回復戦略に関連します。
### [](#コールドスタンバイ)コールドスタンバイ
図 説明 ダウンタイム

サーバーセットアップのコールドスタンバイ設定

Mule 環境がインストールされ、設定されています。ただし、1 つ以上のオペレーティングシステムが実行中ではありません。これは、本番システム/仮想マシンのバックアップとして使用できます。停止が検出された後にオペレーティングシステムの環境と Mule Runtime が起動されます。

あり。環境を起動してトラフィックを転送するのにかかる時間。
### [](#ウォームスタンバイ)ウォームスタンバイ
図 説明 ダウンタイム

サーバーの冗長性を確保するためのウォームスタンバイセットアップ

Mule 環境がインストールされ、設定されています。ただし、Mule Runtime は実行されておらず、オペレーティングシステムのみが実行されています。停止が検出された後に Mule Runtime が起動されます。

少ない。Mule Runtime を起動し、トラフィックを環境に転送するのにかかる時間。
### [](#ホットスタンバイ-アクティブ-パッシブ)ホットスタンバイ - アクティブ-パッシブ
図 説明 ダウンタイム

高可用性設定のアクティブ-パッシブサーバーセットアップ

Mule 環境がインストールされ、設定され、完全に実行しています。ただし、停止が検出されるまでは要求を処理していません。

最小限またはなし。トラフィックを環境に転送する時間。
### [](#active-active)Active-Active
図 説明 ダウンタイム

アクティブ-アクティブ設定の Mule インスタンスのクラスターにトラフィックを分散するロードバランサー

負荷分散クラスター環境。 完全に稼働している 2 つ以上の Mule 環境 (各環境に固有のクラスター) があります。ロードバランサーがすべての環境にトラフィックを転送します。

なし。サービスダウンタイムはありません。

ロードバランサーとクラスタリングが含まれるアクティブ-アクティブサーバー設定

負荷分散単一クラスター環境。 2 つ以上の Mule 環境がありますが、それらは同じクラスター環境の一部です。このシナリオを実現するには、環境間のネットワークレイテンシーが 10 ミリ秒未満である必要があります。

なし。サービスダウンタイムはありません。
## [](#オンプレミスデプロイメントモデルの高可用性)オンプレミスデプロイメントモデルの高可用性 - [\[Active-Active Clustering Deployment Model\]](<#Active-Active Clustering Deployment Model>) - [\[Active-Active Clustering Fault Tolerance Deployment Model\]](<#Active-Active Clustering Fault Tolerance Deployment Model>) - [\[Zero Downtime Deployment Model\]](<#Zero Downtime Deployment Model>) ### [](#アクティブ-アクティブクラスタリングデプロイメントモデル)アクティブ-アクティブクラスタリングデプロイメントモデル クラスタリングされ負荷が分散されている環境の 2 つのノードで、応答時間 1 秒で 1,500 TPS をサポート可能です。この状態で、SLA の通常運用の条件を満たしています。ノードに障害が発生すると、サービスは影響を受けます。ただし、ノードは応答時間 1 秒で 700 TPS を処理でき、これは許容される影響レベルを大きく上回っているため、この障害による影響は SLA に違反しません。 ![ロードバランサーと複数のサーバーが含まれるアクティブ-アクティブクラスタリングセットアップ](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/hadr-aa-clustering.png) 複数の Mule ノードに負荷を均等に分散させます。 - すべてのノードの機能は同じです。 - すべてのノードが同時にアクティブです。 **コスト** SLA 要件によって異なります。このモデルでは、SLA を満たすために 2 つのノードが必要です。SLA の許容可能なサービス影響が通常運用で指定されているのと同じ条件に変更されると、1 つのノード障害に対応するために環境に少なくとも 3 つのノードが必要です。2 つ以上のノードが実行中である状態を維持できない確率によっては、さらに多くのノードが必要な場合もあります。 ### [](#アクティブ-アクティブクラスタリングフォールトトレランスデプロイメントモデル)アクティブ-アクティブクラスタリングフォールトトレランスデプロイメントモデル フォールトトレランスの基本的な定義は、システム内の障害がサービスに全く影響を及ぼさないということです。これは、サービスの影響とダウンタイムへの耐性があるという点で高可用性とは異なります。 ![冗長性ノードとロードバランサーが含まれるフォールトトレランスシステム](/mulesoft/current/ja-jp/mule-runtime/4.9/_images/hadr-fault-tolerant.png) フォールトトレランスでは、高可用性とは異なり、コンポーネント障害後にアプリケーションが中断なく機能し続けられるようにするための追加のリソースが提供されます。フォールトトレランス環境は高可用性環境よりもコストがかかります。 フォールトトレランスの度合を判断するには、システム障害の確率が必要です。高可用性のセクションで取り上げた SLA の例を使用して、最小許容サービス影響レベルが通常運用の要件と同じであるとします。 新しい全体的な SLA では、システムが 1 秒あたり 1000 件のトランザクションを処理し、応答時間 1 秒、ダウンタイムなし、サービスへの影響なしにする必要があります。 2 つ以上のノードで障害が発生する確率が低ければ、このアーキテクチャに必要なノードは 3 つで済みます。一方、2 つ以上のノードで障害が発生する確率が許容できないほど高い場合は、複数障害に対応するために 4 つ以上のノードが必要になります。 **コスト** 定義された SLA を満たすために冗長性が必要なので、よりコストがかかります。 ### [](#ゼロダウンタイムデプロイメントモデル)ゼロダウンタイムデプロイメントモデル 目標は、SLA に影響を与えずに環境をすばやく変更することです。この変更には、インフラストラクチャやインフラストラクチャ上で実行中のアプリケーションのアップグレードを含みます。通常、ゼロダウンタイムデプロイメントでは、新旧のシステムが短期間共存するサイドバイサイドのデプロイが使用されます。これは、機能の低下や完全なダウンタイムが発生するインプレースのデプロイメントとは対照的です。 [Gartner](http://www.gartner.com/it-glossary/continuous-operations/)​ は連続稼働を次のように定義しています。「データ処理システムの特性で、定期メンテナンスなどの計画されたダウンタイムを低減または排除すること。24 時間 365 日稼働の 1 つの要素。」 ベースライン本番環境は、現在稼働中の環境です。変更 (ランタイムのアップグレード、設定、新しいアプリケーションなど) された新しい環境が作成されます。 ごく一部のトラフィックが新しい環境に送信され、新しい環境の信頼度が高まるにつれて増えていきます。新しい環境が完全稼働状態 (トラフィックの 100% を処理) になるまで、ベースライン本番環境は引き続き使用されます。新しい環境がすべてのトラフィックを受け入れるようになると、それが新しいベースライン本番環境となり、以前のベースライン本番環境は終了します。 下の例では、各環境は同じ数の Mule Runtime とコアを使用していると想定しています。実際には新しい環境がベースライン環境よりも多くなったり少なくなったりする可能性もあります。
デプロイメントの手順 図

新しい本番環境がデプロイされ、ごく一部のトラフィックが新しい環境に転送されます。

高可用性デプロイメントの現在の本番環境から新しい本番環境へのトラフィック分散 (新しい本番環境への割合の方が少ない)

新しい環境の信頼度が高まり、転送されるトラフィックが増えます。

高可用性デプロイメントの現在の本番環境から新しい本番環境へのトラフィック分散 (新しい本番環境への割合の方が多い)

すべてのトラフィックが新しい環境に転送されます。

現在の環境から新しい環境にトラフィックを切り替える、ダウンタイムなしのデプロイメント

すべてのトラフィックが新しい環境に転送され、新しい環境がベースライン本番環境に昇格します。以前のベースライン環境は終了します。

高可用性環境の新しい本番環境へのトラフィックルーティング (新しい本番環境への割合が 100%)
**コスト** このデプロイメント方法では、一時的にサービスの容量が追加される場合があります (数分間、数時間、または数日間)。 ## [](#障害回復)障害回復 **あなたの会社は、IT の緊急事態が発生した後にどれだけ迅速に業務に戻ることができますか?** 障害回復は、自然災害や人災が発生した後に、システムを以前の許容される状態に復元するプロセスです。ビジネス要件に沿って適切な DR 戦略を選択することが重要です。DR では、目標復旧時間 (RTO) や目標復旧時点 (RPO) などの測定可能な特性を使用して DR 計画を推進します。 障害回復で重要なのは目標復旧時点 (RPO) と目標復旧時間 (RTO) です。RPO は、IT 障害の後に戻る時点です。たとえば、24 時間ごとにバックアップしている場合、RPO は最長で 24 時間前になります。一方、RTO は、どれだけ迅速に RPO に戻して、業務に戻れるかということです。これには、プライマリ機器が機能しなくなったときに、予備の機器でバックアップの実行を開始する時間などの活動が含まれます。 システムバックアップは、しっかりとした障害回復プログラムの重要な要素です。回復には、コールド、ウォーム、ホットの 3 種類があります。
用語 定義 例

目標復旧時間 (RTO)

どれだけ迅速にこのアセットを復旧する必要があるか?

1 分? 15 分? 1 時間? 4 時間? 1 日?

目標復旧時点 (RPO)

このアセットはどれだけ新しいものに復旧する必要があるか?

データロスなし、15 分の有効期限?
CloudHub を使用した障害回復についての詳細は、​[「CloudHub High Availability and Disaster Recovery (CloudHub の高可用性と障害回復)」](https://docs.mulesoft.com/cloudhub/cloudhub-hadr)​を参照してください。 ## [](#ステートレスなインテグレーション)ステートレスなインテグレーション 一般的な設計原理として、インテグレーションが本質的にステートレスであることが常に重要です。つまり、さまざまなクライアントの呼び出しや実行 (スケジュールされたサービスの場合) の間でトランザクション情報を共有しないということです。システムの制約によって一部のデータをミドルウェアで管理する必要がある場合、そのデータはデータベースやメッセージングキューなどの外部ストアで保持し、ミドルウェアのインフラストラクチャやメモリの内部では保持しないようにする必要があります。拡張 (特にクラウドでの拡張) の際には、各ワーカー/ノードで使用される状態やリソースは他のワーカーとは独立している必要があることに注意することが重要です。このモデルを使用することで、パフォーマンス、スケーラビリティ、信頼性が向上します。