HTTP 用 Anypoint Connector (HTTP Connector) の Request 操作を使用すると、デフォルトの GET メソッドを使用して外部 HTTP サービスをコンシュームできます。それ以外の場合は、操作が受け入れるメソッドを選択できます。
-
GET および OPTIONS メソッドは要求でペイロードを送信しません (HTTP リクエストボディは空です)。 -
CONNECT、DELETE、PATCH、POST、PUT メソッドは、HTTP リクエストボディとしてメッセージペイロードを送信します。
HTTP Request 操作によって HTTP 要求が送信された後、コネクタは HTTP 応答を受信し、それを Mule アプリケーションのフローの次の要素に渡します。HTTP 応答は、さまざまな状況コードを使用して成功か失敗かを示します。また、操作によって HTTP 応答がどのように生成されるかをコネクタ操作のグローバル設定でカスタマイズすることができます。
デフォルトでは、操作は Mule メッセージペイロードを HTTP リクエストボディとして送信しますが、これは DataWeave スクリプトまたは式を使用してカスタマイズできます。要求の本文に加えて、以下を設定できます。
-
要求および応答のサイズ制限
-
ヘッダー
-
クエリパラメーター
-
URI パラメーター
-
複数ヘッダーまたはパラメーターのマップ
| Mule 4 では、HTTP Connector のバックエンドで処理される HTTP 要求の Server Name Indication (SNI) がサポートされます。 |
HTTP 要求接続を設定する
HTTP Request 操作を使用するには、接続プロバイダーを使用して要求のグローバル設定をホスト URI に設定する必要があります。ホスト URI にはパスを含めることができます。さらに、受信ポートと通信プロトコルを設定できます。
-
Host (ホスト)
要求が送信される場所を示します。ホスト名または IP を指定することもできます。 -
Port (ポート)
要求が送信される場所を示します。 -
Protocol (プロトコル)
通信のプロトコルを示します。標準接続の場合は HTTP、セキュアな TLS 接続の場合は HTTPS を使用します。
HTTPS を介したセキュアな接続を有効にするには、接続に TLS 設定コンテキストを定義し、次を指定する必要があります。
-
サーバーのキーストア
-
トラストストア (相互認証が必要な場合)
TLS 設定についての詳細は、「キーストアとトラストストアを使用した TLS の設定」を参照してください。
さらに、[Authentication (認証)] 項目を次の種別で設定できます。
-
Basic authentication (基本認証)
-
Digest authentication (ダイジェスト認証)
-
Ntlm authentication (NTLM 認証) (NT LAN Manager)
認証種別と例についての詳細は、「HTTP 要求の認証の設定」を参照してください。
次の例は、Studio で HTTP Request 接続を設定する方法を示しています。
-
[Mule Palette (Mule パレット)] ビューで、[HTTP] > [Request] を選択します。
-
[Request] を Studio キャンバスにドラッグします。
-
[Connector configuration (コネクタ設定)] 項目の横にあるプラス記号 (+) をクリックして、アプリケーション内の HTTP Request のすべてのインスタンスで使用できるグローバル要素を設定します。
-
[Host (ホスト)] を
localhost に、[Port (ポート)] を 8081 に設定します。
-
[TLS configuration (TLS 設定)] を [Edit inline (インライン編集)] に設定します。
-
[Trust Store Configuration (トラストストア設定)] セクションで、[Path (パス)] を
keystore.jks に、[Password (パスワード)] を Mypassword に設定します。
-
[Authentication (認証)] を [Basic authentication (基本認証)] に設定します。
-
[Username (ユーザー名)] を
testuser、[Password (パスワード)] を Mypassword に設定します。
-
[OK] をクリックします。
-
HTTP Request 設定画面で、[Path (パス)] を
/testpath に設定します。
設定 XML エディターでは、host、port、path、trust-store、および authentication の設定は次の例のように記述されます。
<http:request-config name="HTTP_Request_configuration">
<http:request-connection host="localhost" port="8081">
<tls:context >
<tls:trust-store path="keystore.jks" password="Mypassword" />
</tls:context>
<http:authentication >
<http:basic-authentication username="testuser" password="Mypassword" />
</http:authentication>
</http:request-connection>
</http:request-config>
<flow name="httplistenerresponseFlow1" >
<http:request method="GET" config-ref="HTTP_Request_configuration" path="/testpath"/>
</flow>
HTTP 要求および応答のサイズ制限の設定
デフォルトでは、HTTP 要求サイズ、応答サイズ、リクエスト/レスポンスヘッダーサイズの最大値が Mule によって定義されます。ただし、これらの値は wrapper.conf ファイルで次のプロパティを変更することで変更できます。
| 名前 | プロパティ | 説明 | デフォルト値 (バイト) |
|---|---|---|---|
リクエスト/レスポンスヘッダーサイズ |
|
HTTP リクエストヘッダーセクション (要求行 + ヘッダー) で受け入れられる最大サイズ (バイト) |
|
要求サイズ |
|
送信する肯定応答されていない最大バイト数を保持および反映するために、未読バイト数を制御する受信バッファの最大サイズ。 |
|
応答サイズ |
|
受信側システムから肯定応答があるまで送信パッケージを制御する送信バッファの最大サイズ。 |
|
wrapper.conf ファイルで次のシステムプロパティを変更して、サーバーレスポンスヘッダー、サーバーリクエストヘッダー、クライアントリクエストヘッダーの最大値を変更することもできます。
| 名前 | プロパティ | 説明 | デフォルト値 |
|---|---|---|---|
Server Response Headers (サーバーレスポンスヘッダー) |
|
HTTP サーバーから送信される応答で許容されるヘッダーの最大量。 |
|
Server Request Headers (サーバーリクエストヘッダー) |
|
HTTP サーバーから送信される要求で許容されるヘッダーの最大量。 |
|
Client Request Headers (クライアントリクエストヘッダー) |
|
HTTP クライアントから送信される要求で許容されるヘッダーの最大量。 |
|
クライアントの HTTP レスポンスヘッダーには最大量の制限がないため、Max Client Response Header のようなシステムプロパティはありません。
wrapper.conf ファイルでシステムプロパティを設定する方法についての詳細は、「wrapper.conf ファイルでシステムプロパティを設定する」を参照してください。
ヘッダーを設定する
ヘッダーを次の 2 つのレベルのいずれかで HTTP 要求に追加します。
-
Header (ヘッダー)
HTTP Request 操作レベル -
Default headers (デフォルトヘッダー)
HTTP Request グローバル設定レベル
要求のたびにヘッダーを指定することを避けるために、HTTP グローバル設定レベルでデフォルトヘッダーを設定します。この設定を使用すると、HTTP Request 操作レベルで設定したヘッダーと共にこのヘッダーがすべてのアウトバウンド要求に追加されます。 デフォルトヘッダーを含む一部のパラメーターでは式も受け入れられるため、動的値を使用できます。
次の例は、Studio で HTTP Request 操作レベルで [Headers (ヘッダー)] 項目を設定する方法を示しています。
-
フローから HTTP の [Request] 操作を選択します。
-
[General (一般)] の [Request (要求)] セクションで、[Headers (ヘッダー)] タブを選択します。
-
プラス記号 (+) をクリックして、新しいヘッダーを追加します。
-
[Name (名前)] 列で、"Key" を
"HeaderName1" に変更します。 -
[Value (値)] 列で、"Value" を
"HeaderValue1" に変更します。
設定 XML エディターでは、headers 設定は次のように記述されます。
<http:request method="GET" config-ref="HTTP_Request_configuration" path="/testpath">
<http:headers ><![CDATA[#[output application/java
---
{
"HeaderName1" : "HeaderValue1"
}]]]></http:headers>
</http:request>
DataWeave 式を使用してヘッダーを追加することもできます。
-
HTTP Request 操作設定ウィンドウで [Headers (ヘッダー)] タブを選択します。
-
[fx] をクリックしてリテラルモードに切り替えます。
-
[fx] ボタンの右にあるボックスに、DataWeave 式
[{'HeaderName1' : 'HeaderValue1'}] を追加します。
設定 XML エディターでは、headers 設定は次のように記述されます。
<http:request method="GET" config-ref="HTTP_Request_configuration" path="/testpath">
<http:headers ><![CDATA[#[[{'HeaderName1' : 'HeaderValue1'}]]]]></http:headers>
</http:request>
次の例は、Studio で HTTP Request グローバル設定レベルで [Default headers (デフォルトヘッダー)] 項目を設定する方法を示しています。
-
フローから HTTP の [Request] 操作を選択します。
-
[Connector configuration (コネクタ設定)] 項目の横にあるプラス記号 (+) をクリックして、アプリケーション内の HTTP Request のすべてのインスタンスで使用できるグローバル要素を設定します。設定がすでに作成されている場合は、[編集] ボタンをクリックします。
-
[Settings (設定)] をクリックします。
-
[Default headers (デフォルトヘッダー)] を [Edit inline (インライン編集)] に設定します。
-
プラス記号 (+) をクリックして、新しいヘッダーを追加します。
-
[Key (キー)] を
x-csrf-token に設定します。 -
[Value (値)] を
Fetch に設定します。
-
[Finish (完了)] をクリックします。
設定 XML エディターでは、default-headers 設定は次のように記述されます。
<http:default-headers >
<http:default-header key="x-csrf-token" value="Fetch" />
</http:default-headers>
次の例は、DataWeave 式を使用してデフォルトヘッダーを設定し、動的値を使用できるようにする方法を示しています。
-
[Default headers (デフォルトヘッダー)] 設定ウィンドウで
-
[Value (値)] の [fx] をクリックしてリテラルモードに切り替えます。
-
[Value (値)] を
#[vars.role] に設定します。
設定 XML エディターでは、default-headers 設定は次のように記述されます。
<http:request-config name="requestConfig">
<http:default-headers >
<http:default-header key="custom-role" value="#[vars.role]" />
</http:default-headers>
</http:request-config>
設定要素内で DataWeave 式を使用すると、動的設定が構成されます。Mule アプリケーションが HTTP Request 操作を使用するたびに、設定内のすべての式が評価され、異なる値セットごとに新しい設定インスタンスが作成および初期化されます。
| HTTP Connector では、デフォルトヘッダーには値の小さい式を使用してください。そうしなければ、評価のたびに異なる値が返され、HTTP クライアントのインスタンスが複数作成されるため、貴重なリソースをコンシュームし、パフォーマンスが低下します。 |
そのような場合は、HTTP Request 操作レベルで式を使用したヘッダーを設定します。
<http:request config-ref="requestConfig" method="#[attributes.method]" path="#[attributes.maskedRequestPath]">
<http:headers>#[{'custom-role':vars.role}]</http:headers>
</http:request>
クエリパラメーターを設定する
HTTP 要求のクエリパラメーターを設定する手順は、次のとおりです。
-
Studio で、フローから HTTP の [Request] 操作を選択します。
-
[General (一般)] の [Request (要求)] セクションで、[Query Parameters (クエリパラメーター)] タブを選択します。
-
プラス記号 (+) をクリックして、パラメーターを要求に追加します。
-
[Name (名前)] 列で、"Key" を
"Keyquery" に変更します。 -
[Value (値)] 列で、"Value" を
"Valuequery" に変更します。
設定 XML エディターでは、query-params 設定は次のように記述されます。
<http:request method="GET" config-ref="HTTP_Request_configuration" path="/testpath">
<http:query-params ><![CDATA[#[output application/java
---
{
"keyquery" : "Valuequery"
}]]]></http:query-params>
</http:request>
DataWeave 式を使用してクエリパラメーターを追加することもできます。
-
HTTP Request 操作設定ウィンドウで [Query Parameters (クエリパラメーター)] タブを選択します。
-
[fx] をクリックしてリテラルモードに切り替えます。
-
[fx] ボタンの右にあるボックスに、DataWeave 式
[{'Keyquery' : 'Valuequery'}] を追加します。
設定 XML エディターでは、query-params 設定は次のように記述されます。
<http:request method="GET" config-ref="HTTP_Request_configuration" path="/testpath">
<http:query-params ><![CDATA[#[[{'Keyquery' : 'Valuequery'}]]]]></http:query-params>
</http:request>
URI パラメーターを設定する
要求のパスにプレースホルダー (/customer/{customerId} など) を使用する場合は、URI パラメーターを設定します。
次の例は、Studio で [URI Parameters (URI パラメーター)] 項目を設定する方法を示しています。
-
フローから HTTP の [Request] 操作を選択します。
-
[General (一般)] で、[Path (パス)] を
/customer/{customerId} に設定します。 -
[URI Parameters (URI パラメーター)] タブを選択します。
-
プラス記号 (+) をクリックして、新しい URI パラメーターを追加します。
-
[Name (名前)] 列で、"Key" を
"customerID" に変更します。 -
[Value (値)] 列で、"Value" を
"20" に変更します。
設定 XML エディターでは、uri-params 設定は次のように記述されます。
<http:request method="GET" config-ref="HTTP_Request_configuration" path="/customer/{customerId}">
<http:uri-params ><![CDATA[#[output application/java
---
{
"customerID" : "20"
}]]]></http:uri-params>
</http:request>
DataWeave 式を使用して URI パラメーターを追加することもできます。
-
HTTP Request 操作設定ウィンドウで [URI Parameters (URI パラメーター)] タブを選択します。
-
[fx] をクリックしてリテラルモードに切り替えます。
-
[fx] ボタンの右にあるボックスに、DataWeave 式
[{'customerID' : '20'}] を追加します。
設定 XML エディターでは、uri-params 設定は次のように記述されます。
<http:request method="GET" config-ref="HTTP_Request_configuration" path="/customer/{customerId}">
<http:uri-params ><![CDATA[#[[{'customerID' : '20'}]]]]></http:uri-params>
</http:request>
Mule アプリケーションが実行されると、http://www.example.com/customer/20 への GET 要求が実行されます。
動的パラメーターおよびヘッダーを設定する
アプリケーションの設計時に HTTP 要求で何個のパラメーターやヘッダーが必要かわからない場合、DataWeave 式と変数マップを使用して動的にパラメーターまたはヘッダーを HTTP 要求に割り当てます。
ヘッダーを動的に設定するには、変数マップを作成し、DataWeave 式を使用して変数値を割り当てます。次に、その変数を使用してリクエストヘッダーをセットアップします。たとえば、customMap という変数マップを使用して、次のヘッダーを要求にセットアップします。#[vars.customMap ++ {'HeaderName1' : 'HeaderValue1'}]
URI パラメーターを動的に設定するには、パラメーターのマップを返す DataWeave 式を使用します。たとえば、次の手順を実行します。
-
[Path (パス)] を
/test/{p1}/{p2} に設定します。 -
[General (一般)] の [Request (要求)] セクションで、[URI Parameters (URI パラメーター)] をクリックします。
-
[fx] ボタンをクリックしてリテラルモードに切り替えます。
-
次の式
vars.customMap ++ {'p2': 'customer'} を設定します。 -
[Request] 操作の前に [Set Variable] 操作を追加します。
-
[Name (名前)] を
customMap に設定します。 -
[Value (値)] を式
{'p1': 'some'} に設定します。
XML は次のようになります。
<set-variable value="#[{'p1': 'some'}]" variableName="customMap"/>
<http:request method="GET" config-ref="HTTP_Request_configuration" path="/test/{p1}/{p2}">
<http:uri-params ><![CDATA[#[vars.customMap ++ {'p2': 'customer'}]]]></http:uri-params>
</http:request>
このフローをトリガーすると、Request 操作によって要求がパス /test/some/customer に送信されます。
HTTP Connector は要求ごとにパラメーターを解決し、要求で指定された順序に従って現在のメッセージのコンテキストで DataWeave 式を評価します。1 つのパラメーターが複数回定義されている場合、最新の値が使用されます。
フォームパラメーターを送信する
POST 要求でフォームパラメーターを送信する手順は、次のとおりです。
-
Studio で、フローから HTTP の [Request] 操作を選択します。
-
[General (一般)] で、[Method (メソッド)] を POST に設定します。
-
[Body (本文)] で、Mule メッセージのペイロードを、送信するパラメーターの名前と値を指定した
application/x-www-form-urlencoded として作成します。次に例をし召します。
[output application/x-www-form-urlencoded --- {'key1':'value1', 'key2':'value2'}
設定 XML エディターでは、body 設定は次のように記述されます。
<flow name="httprequestFlow" >
<http:request method="POST" config-ref="HTTP_Request_configuration" path="testpath">
<http:body ><![CDATA[#[output application/x-www-form-urlencoded --- {'key1':'value1', 'key2':'value2'}]]]></http:body>
</http:request>
</flow>
HTTP Request 操作は POST 要求をホストの場所に送信します。HTTP 要求には Content-Type: application/x-www-form-urlencoded が含まれており、本文は key1=value1&key2=value2 です。
ラウンドロビン方式の要求の設定
この HTTP Request 操作は、設定されたホストにラウンドロビン DNS を使用して接続します。Mule は、指定されたホストに関連付けられているすべての IP アドレスを解決し、要求をすべての返された IP 間に分散することで負荷分散を行います。
認証が必要なリソースに操作を接続するとき、要求が拒否されることを避けるために、外部サービスはサービスのホスト内の IP アドレス間でセッション情報を複製する必要があります。
セッション維持を外部リソースが管理しない場合は、サービスホスト名を mule.http.disableRoundRobin システムプロパティに追加します。HTTP 要求は設定されたホストに接続するときにラウンドロビン DNS を使用しません。
Mule を開始するときに次のシステムプロパティを設定してください。
./mule -M-Dmule.http.disableRoundRobin=serverhostname.com
応答バリデーターを設定する
HTTP Request 操作は、HTTP 応答を受信すると応答状況コードで応答を検証します。デフォルトでは、状況コードが 400 以上であれば HTTP Connector は HTTP エラー応答をスローします。そのため、サーバーが 404 (リソースが見つかりません) や 500 (内部サーバーエラー) を返した場合、失敗となり、コネクタによってエラー処理がトリガーされます。
2 つの ASCII ピリオド文字 (..) で失敗状況コードの範囲が定義されます。つまり、200..399 のように状況コード検証の範囲を設定できます。XML では次のようになります。
<http:response-validator >
<http:success-status-code-validator values="200..399" />
</http:response-validator>
500 ~ 599 の値は失敗とみなされ、エラーが発生します。HTTP 応答の状況コードの値がそれ以外の場合、成功とみなされます。
HTTP Request 操作では、HTTP 応答受信時に次の属性が Mule メッセージに追加されます。
-
attributes.statusCode
HTTP 応答の状況を表すコード -
attributes.reasonPhrase
HTTP 応答の理由を説明する語句
HTTP 要求コール中の HTTP レスポンスボディの詳細な例は、「HTTP エラー応答の例」を参照してください。
HTTP Request 操作設定で、[Response validator (応答バリデーター)] 項目を次のいずれかのオプションに設定して HTTP 応答をカスタマイズできます。
-
None (なし)
デフォルトのバリデーターを使用します。このバリデーターは、、状況コードが 400 以上の場合はエラーをスローします。 -
Expression or Bean reference (式または bean 参照)
DataWeave 式または bean 参照を使用して状況コードを定義します。 -
Failure status code validator (失敗状況コード検証)
エラーをスローする失敗状況コードを定義します。 -
Success status code validator (成功状況コード検証)
成功を示す状況コードを定義します。
次の例は、Studio で [Response validator (応答バリデーター)] 項目を設定する方法を示しています。
-
フローから HTTP の [Request] 操作を選択します。
-
[General (一般)] で、[Response (応答)] タブをクリックします。
-
[Response validator (応答バリデーター)] を [Success status code validator (成功状況コード検証)] に設定します。
-
[Values (値)] に、受け入れ可能な状況コードのカンマ区切りリスト (
200,201 など) を追加します。
HTTP 応答で返された状況コードの値がそれ以外の場合、操作は失敗となり、エラーが発生します。
設定 XML エディターでは、response-validator 設定は次のように記述されます。
<http:request method="POST" config-ref="HTTP_Request_configuration" path="testpath">
<http:response-validator >
<http:success-status-code-validator values="200,201" />
</http:response-validator>
</http:request>
対象変数を設定する
デフォルトでは、HTTP リクエストボディは受信 Mule メッセージの [payload] から取得され、HTTP 応答は出力 Mule メッセージの [payload] として送信されます。
HTTP Request 操作のこのデフォルトの動作は、[Body (本文)] 項目セクションか、[Target Variable (対象変数)] 項目の値を更新して変更できます。この値は出力データの場所をペイロード以外 (変数など) に指定します。
次の例は、Studio で [Target Variable (対象変数)] 項目を設定する方法を示しています。
-
フローから HTTP の [Request] 操作を選択します。
-
[General (一般)] で、[Advanced (詳細)] タブを選択します。
-
[Target Variable (対象変数)] を
testvariable に設定します。 -
[Target Value (対象値)] を
testvalue に設定します。
設定 XML エディターでは、target および targetValue の設定は次の例のように記述されます。
<http:request method="POST" config-ref="HTTP_Request_configuration" path="testpath" target="testvariable" targetValue="testvalue">
</http:request>
要求ストリーミングモードを設定する
HTTP Connector は、リクエストボディの管理時に送信するデータの種類を考慮します。HTTP 要求をチャンクで送信するように HTTP Request 操作を設定できます。デフォルトでは、ペイロード種別がストリームの場合、ストリーミングメカニズムを使用して HTTP 要求が送信されます。
この動作を制御するには、[Request streaming mode (要求ストリーミングモード)] 項目を次のいずれかのオプションに設定します。
-
ALWAYS (常時)
ペイロード種別に関係なく常にストリーミングが有効になります。 -
AUTO (自動) (デフォルト)
動作はペイロード種別に応じて異なります。ペイロードがストリームの場合、ストリーミングが有効になりになります。それ以外の場合は無効になります。 -
NEVER (なし)
ペイロードがストリームの場合も含め、ストリーミングしません。
ストリーミングの場合、HTTP 要求には Content-Length ヘッダーが含まれません。要求に含まれるのは Transfer-Encoding ヘッダーで、本文はストリーミングが完全にコンシュームされるまでチャンクで送信されます。
次の例は、Studio で [Request streaming mode (要求ストリーミングモード)] 項目を設定する方法を示しています。
-
[Mule Palette (Mule パレット)] ビューで、[HTTP] > [Request] を選択します。
-
[Request] を Studio キャンバスにドラッグします。
-
[Path (パス)] を
/path に設定します。 -
HTTP Request 操作設定画面で [Request (要求)] タブをクリックします。
-
[Request streaming mode (要求ストリーミングモード)] を
ALWAYS に設定します。
設定 XML エディターでは、requestStreamingMode 設定は次のように記述されます。
<flow name="httprequestFlow" >
<http:request method="GET" requestStreamingMode="ALWAYS" config-ref="HTTP_Request_configuration" path="/path"/>
</flow>
要求ストリーミングのシステムプロパティの設定
[Request streaming mode (要求ストリーミングモード)] を ALWAYS に設定すると、Mule アプリケーションは HTTP 要求をチャンクで送信しますが、この設定は Mule アプリケーションがペイロードを内部でストリーミングすることを意味するわけではありません。HTTP Request 操作では、HTTP 操作を送信する前にすべてのデータがメモリに格納されている必要があります。したがって、Mule アプリケーションが非常に大きなリクエストボディを送信する必要がある場合、大量のメモリを消費することになり、メモリ不足エラーが発生する可能性があります。この問題を防ぐために、内部要求ストリーミングを有効にする mule.http.requestStreaming.enable システムプロパティが提供されています。
このシステムプロパティを設定すると、HTTP Request 操作では、すべてのデータがメモリに格納される前にリクエストボディの送信が開始されます。したがって、Mule アプリケーションは、このプロパティを設定しない場合よりもメモリを必要としません。
Mule を開始するときに次のシステムプロパティを設定してください。
./mule -M-Dmule.http.requestStreaming.enable=true
このプロパティのデフォルト値は、Mule Runtime バージョンによって異なります。Mule 4.4 以前では、このプロパティはデフォルトで false になります。Mule 4.5 以降では、このプロパティはデフォルトで true になります。
また、ストリーミングメカニズムの内部バッファの mule.http.requestStreaming.bufferSize システムプロパティを設定することもできます。
Mule を開始するときに次のシステムプロパティを設定してください。
./mule -M-Dmule.http.requestStreaming.bufferSize=value
Anypoint Studio で、またはオンプレミスデプロイでシステムプロパティを設定する方法については、システムプロパティのドキュメントを参照してください。
応答ストリーミングを設定する
大きなペイロードを要求する場合、HTTP Request グローバル設定で [Stream response (応答のストリーミング)] 項目をオンにすることで、応答をストリーミングするように選択できます。
デフォルトでは、[Stream response (応答のストリーミング)] ボックスはオフ (false) です。このボックスをオン (true) にすると、Mule がチャンクをメモリ内バッファに保存して、HTTP 応答をストリームとして管理できるようになります。[Response buffer size (応答バッファサイズ)] のデフォルト値 1024 を大きな値に再設定することもできますが、バッファの問題を回避するには、ストリーミング時に応答をコンシュームすることが重要です。
次の例は、Studio で [Request streaming mode (要求ストリーミングモード)] 項目と [Response buffer size (応答バッファサイズ)] 項目を設定する方法を示しています。
-
[Mule Palette (Mule パレット)] ビューで、[HTTP] > [Request] を選択します。
-
[Request] を Studio キャンバスにドラッグします。
-
[Path (パス)] を
/path に設定します。 -
プラス記号 (+) をクリックして HTTP Request グローバル設定を開きます。
-
[Stream response (応答のストリーミング)] ボックスをオンにします。
-
[Response buffer size (応答バッファサイズ)] を `100 に設定します。
設定 XML エディターでは、streamResponse および responseBufferSize の設定は次の例のように記述されます。
<http:request-config name="requestConfig">
<http:request-connection host="localhost" port="8081" streamResponse="true" responseBufferSize="100"/>
</http:request-config>
再試行メカニズムの設定
HTTP Request 操作では、再試行のために再接続戦略は使用しません。再接続戦略は、ConnectionException エラーが発生した場合に Mule SDK で接続を再確立するために使用するメカニズムです。このメカニズムは、HTTP Request 操作により作成された HTTP サービスへの接続には影響しません。
接続についての詳細は、Mule SDK の接続のドキュメントを参照してください。
HTTP Connector では、外部 HTTP サービスのコンシュームの試行回数を設定できる再試行メカニズムが使用されます。コネクタはこのメカニズムを使用して HTTP クライアントを HTTP サービスに再接続します。HTTP Connector では TCP 接続が管理されないため、このメカニズムでソケットは再接続されません。
HTTP Request 操作が外部 HTTP サービスのコンシュームを試行できる回数 (再試行回数) を設定するには、次のいずれかを使用できます。
-
Until Successful スコープコンポーネント
-
HTTP Request 操作の組み込み再試行メカニズム
Until Successful スコープを使用して再試行メカニズムを設定する
Until Successful スコープは、スコープ内のコンポーネントが成功するか、または最大再試行回数に達するまで、内部のコンポーネントを順番に処理します。このスコープで HTTP Request 操作を囲むと、[Max Retries (最大試行回数)] 項目と [Milliseconds Between Retries (再試行回数間のミリ秒)] 項目を設定できます。
次の例は、Studio で Until Successful スコープを使用して再試行メカニズムを設定する方法を示しています。
-
[Mule Palette (Mule パレット)] ビューで、[Core (コア)] > [Until Successful] を選択します。
-
[Until Successful] スコープコンポーネントを Studio キャンバスにドラッグします。
-
[Max retries (最大再試行回数)] を
5 に設定します。 -
[Milliseconds Between Retries (再試行回数間のミリ秒数)] を
10000 に設定します。 -
[Mule Palette (Mule パレット)] ビューで、[HTTP] > [Request] を選択します。
-
[Request] を [Until Successful] スコープコンポーネントにドラッグします。
設定 XML エディターでは、until-successful、maxRetries、および millisBetweenRetries の設定は次の例のように記述されます。
<until-successful maxRetries="5" millisBetweenRetries="10000">
<http:request method="GET" config-ref="requestConfig" />
</until-successful>
このスコープについての詳細は、「Until Successful スコープ」を参照してください。
組み込み再試行メカニズムの設定
HTTP Request 操作は、Remotely Closed 種別のエラーを受信すると、冪等性メソッド PUT、DELETE、GET、HEAD、OPTIONS、TRACE を失敗するまで自動的に 3 回再試行します。このメカニズムは 2 つのシステムプロパティを設定してカスタマイズできます。
-
mule.http.client.maxRetries=5
このシステムプロパティでは、HTTP Request 操作が失敗するまでの再試行回数を設定できます。また、システムプロパティ値を 0 に設定して、組み込みメカニズムを使用しないようにすることもできます。
Mule を開始するときに次のシステムプロパティを設定してください。
./mule -M-Dmule.http.client.maxRetries=5
-
mule.http.client.retryOnAllMethods=true
このシステムプロパティを使用すると、組み込みメカニズムが冪等性メソッドだけでなくすべてのメソッドに拡張されます。
Mule を開始するときに次のシステムプロパティを設定してください。
./mule -M-Dmule.http.client.retryOnAllMethods=true
システムプロパティを設定する方法については、「システムプロパティ」を参照してください。POST などの非冪等性メソッドがデフォルトで再試行されない理由については、 RFC 7230 を参照してください。