--- schema_version: "1" id: 69a6b9076995e4e13da20cd16349ed057528703fa298d95e962f1157b9ad092a title: HTTP Connector の使用の移行 collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/mule-runtime/4.9/migration-connectors-http.md canonical_url: https://docs.mulesoft.com/jp/mule-runtime/4.9/migration-connectors-http source_site: docs.mulesoft.com content_type: documentation content_hash: afb94dd4a6ef7d7087288d81287fa28897134ef2be67116c4a440f065db2e78e description: MuleSoft Documentation Site release: "4.9" latest: false --- # 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)