Response Route HTTP(S)
Introduction: You can find a description of this phase in section Phase 6 (Introduction). See also section HTTP and Lobster_data.
Note: See also section File Names, File Patterns, Paths, System Constants and Variables.
(1) You can obtain these templates from the Update Center.
(2) Here you can select a channel of type HTTP. Note: If possible, always use channels to centrally manage connection parameters. In addition to the increased clarity that also facilitates maintenance. If the connection parameters change, you only have to adjust the data in one place and you do not forget a profile.
(3) You can assign a local certificate as a client certificate. The client certificate is only used if option (8) is active at the same time.
(4) The HTTP method ( GET , GET (with content) , POST , PUT , PATCH , DELETE , DELETE (with content) , HEAD ) . Note: If the GET method is used, for example, the Content must be set to No content.
(5) Here you can add additional HTTP request headers. You can use variables for the header names and the values. Syntax: @<Variable name>@. See also section Request Headers below. It is also possible to pass several headers with values in one variable. To do this, enter the header name dyn_header_entries in the dialogue and as value the name of the variable (surrounded by @ characters) that contains the headers and header values. Note: If a channel is used, headers can also be defined there in the additional IDs.
The content of the variable (here var__myHeader) must be structured as follows:
|
headername1:headervalue + linebreak (\n or \r\n) |
Use the functions concat(a,b,c,d,e,f,g,h, [CR-support i]) and save variable a(b) type-safe for that.
(6) See section SOAP Web Services.
(7) See section Multipart/Form-Data below.
(8) The protocol to be used. See also section HTTPS client.
(9) Domain name or IP address of the server (not the entire URL).
(10) The port. A value greater than 0 for the port overrides the value of the selected channel. If value 0 is set, the port set in the channel is used.
(11) The path to be called on the server . Note: The placeholder <serverurl> is replaced by the URI part of the value of channel field Partner address if a channel (2) has been selected
(12) Wizard for entering the complete URL.
(13) Query or message body. Depending on the HTTP method (4) and the content set for the Response Route ( No content or other setting). Note: The complete data generated during mapping can also be included in a GET query. This is done with the placeholder <http-data>. Please also note that the content of the Response Route must not be set to No content then.
(14) If set, the connection is established from the DMZ server (if there is one) instead of the internal server. Note: This also affects the OAuth token refresh if a channel (2) with configured OAuth was specified.
(15) Optional values for user name and password. For Windows users with NTLMv1 or NTLMv2 authentication, see also section Windows Authentication at HTTP Server.
(16) The MIME-Type (Header Content-Type ) . Note: By default, the encoding (from the Response Route settings) is also specified in the Content-Type, e.g. application/octet-stream;charset=ISO-8859-1. If you want to prevent this, you can specify value application/octet-stream;raw in the field instead. In that case, only the value application/octet-stream is used for the Content-Type.
(17) Specifies the expected HTTP response. If the response differs, the request is evaluated as erroneous and thus the Response Route as failed. If the entered value begins with regex:, the value is evaluated as a regular expression. But this setting is ignored if (18) or (20) is set.
(18) If the profile has an HTTP(S) Input Agent, this option can be used to return the response (of this HTTP request here), including HTTP headers, to the external client that sent the first request to the profile. See also section Profile Chains. Alternatively, the response can also be generated by a following/error profile, see (20). Note: If you do not get back an HTTP status code 2xx and the option Mark whole job as failed if this response fails is not set, the Response Route is still regarded as successful. That is, the HTTP status code and any existing payload will be returned to the Input Agent. This only works if all other existing Response Routes are successful. Note: See also section Status of Phase 6 - Error Behaviour.
(19) If set, the values of variables in field (13) will not be URL-encoded. This option does not work if option (7) is active.
(20) If set, the response of the request can be forwarded to a subsequent profile via a synchronous, asynchronous, persistent (or direct) Message. In this case, the check in (17) will not be performed, but an error will be triggered if the response does not contain any payload at all. So you can force that the forwarded response contains data. The response can also be forwarded to an error profile in the event of an error (HTTP status >= 300). This is especially important for web services because in that case the fault response must be sent with HTTP Error 500. Note: The HTTP status code (e.g. 200, 404, ...) can be retrieved via the system variable MSG_CALL_VAR_RESPONSE_HTTP_HEADER_STATUS_CODE in a subsequent/error profile. Note: If you want to return data (HTTP response), see (18), this can also be done via a following/ error profile. However, the message type must then be Direct (type only exists in this Response Route). In addition, one of the Response Route classes ( PassBackDataResponse , DefaultWebServiceResponse , PassBackBinaryDataResponse , DefaultWebServiceResponseBinary) must then also be used in the following/error profile . See also section Third Possibility - HTTP Response Chain .
(21) If the HTTP response does not contain body data, this will lead to an error in the subsequent profile (20). To avoid this, you can define a default body content that is used in this case.
Multipart/Form-Data
For creating a multipart request. You can insert parts or file parts.
|
HTTP method |
Only HTTP methods (4) POST, PUT, PATCH and DELETE (with content) are supported. If a wrong method is used, method POST will automatically be set. |
|
Multipart mode |
Allowed values: STRICT, RFC6532, COMPATIBLE, SYSTEM. Headers: STRICT (Content-Disposition, Content-Type, Content-Transfer-Encoding), RFC6532 (Content-Disposition, Content-Type, Content-Transfer-Encoding), COMPATIBLE (only Content-Disposition a nd additionally Content-Type for a file part). The Multipart mode when using value SYSTEM is determined by the system property -Dhub.datawizard.multipart.browserMode. If -Dhub.datawizard.multipart.browserMode=true, COMPATIBLE applies. If the property is not set or is set to false, STRICT applies. |
|
Is file |
If not set, a part is inserted. If set, then a file part. |
|
Key |
Must be set. Keys are arbitrary, but must be unique. Note: If the value dyn_multipart_entries is specified here as key (selectable in the list), the specified Value is broken down into n multiparts at runtime. A variable is usually specified for the value, e.g. @MY_VAR@. The value of the variable must be structured as follows: dynPart1=1&dynPart2=2&dynPart3=3 The following three parts would then be inserted at runtime: dynPart1=1 If the value of the variable is empty, nothing is inserted. The Content-Type and the Encoding of the parts are taken from the main entry. Note: The value of the variable must not be URL-encoded. It should also be noted that the & character is used as a control character for the splitting and must therefore be escaped with & in order to be able to use it in the value of a part. The variable content dynPart1=1&dynPart2=2&dynPart3=&3 therefore becomes the following three parts: dynPart1=1 |
|
Value/Path |
The content of column Value/Path is inserted as a part with UTF-8 encoding. If you set the checkbox Is file, then it is inserted as a file part. If the prefix file: is used in column Value/Path, e.g. file:./webapps/root/upload/my.pdf, the file ./webapps/root/upload/my.pdf is loaded at runtime and inserted as a file part. You have to set checkbox Is file. You can also use the data of the Response Route with file:<http-data>. Please note that the Encoding column is then ignored and the encoding of the Response Route is used (→ see Content Settings). |
|
File name |
Column File name is optional. If the prefix file: is used in Value/Path, the name of the specified file is replaced with the set file name. If you use File name, you have to set checkbox Is file. Note: You can use placeholders like <n> and <yyyy>. |
|
Content-Type |
Must be set. Note: By default, the encoding is also specified in the Content-Type, e.g. application/octet-stream;charset=ISO-8859-1. If you want to prevent this, you can use value application/octet-stream;raw in the field instead. In that case, only the value application/octet-stream is used for the Content-Type. Note: In the Content-Transfer-Encoding header, the value binary is used by default for file parts and 8bit for parts. This can be overwritten in the Content-Type with the suffix #, e.g. application/octet-stream#7bit or application/octet-stream;raw#7bit (only in this order). |
|
Encoding |
The Encoding is optional. UTF-8 is used by default for parts. |
Request Header
Additional request headers can be inserted via (5). If a channel (2) is used, request headers can also be set there, see section Additional IDs (in channel). If a header with the same name is set, the one set in the profile has priority.
Note: You can use header Set-Cookie to write cookies.
Response
Since we are practically at the end of the profile in the Response Route, an evaluation of the response is only possible to a limited extent here, but you can define the expected content of the response via (17).
It is also possible to forward the response to a subsequent profile. See item (20) for this. There you can also use the system variables MSG_CALL_VAR_HTTP_STATUS_CODE, MSG_CALL_VAR_HTTP_STATUS_LINE und MSG_CALL_VAR_HTTP_<name of header in capital letters>.
If the profile has an HTTP(S) Input Agent, option (18) can be used to return the response to the external client that sent the initial request to the profile.
Raw Request/Response
If you want to see the raw request and the raw response (and the respective headers) for test purposes when using HTTP method POST (especially with multipart), you will find these in the log overview as a Base64-encoded string if you activate the trace messages for phase 6 in the logging configuration. You can decode this string with the plugin Encode/Decode. Alternatively, you can of course use external tools such as https://requestcatcher.com/.