Response "HTTP"
Settings
(1) Select template: You can obtain these templates from the Update Center.
(2) Channel selection: 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) Certificate selection: 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) HTTP method: 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) Adjust HTTP headers: 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, e.g. @ var__myHeader@) 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) Is SOAP-WS call: See section SOAP web services.
(7) Multipart/Form-Data: See section "Multipart/Form-Data" below.
(8) Protocol selection field ("HTTP" or "HTTPS" . See also section HTTPS client.
(9) Target system: Domain name or IP address of the server (not the entire URL).
(10) 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) HTTP URI: 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) Magic wand icon on the left. Wizard for entering the complete URL.
(13) Query or Body : Query or message body. Depending on the HTTP method (4) and the content set for the Response (" 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 must not be set to "No content" then.
Response has content set to "No content":
|
HTTP method (4) |
Data target |
|
GET |
Field data lands in query. |
|
GET (with content) |
Field data lands in body. |
|
POST |
Field data lands in body. |
|
PUT |
Field data lands in body. |
|
PATCH |
Field data lands in body. |
|
DELETE |
Field data lands in query. |
|
DELETE (with content) |
Field data lands in body. |
|
HEAD |
Field data lands in query. |
Response has content not set to "No content":
|
HTTP method (4) |
Data target |
|
GET |
Error if <http-data> is not used in the field. With <http-data> the content of the Response lands up in the query. |
|
GET (with content) |
If <http-data> is not used in the field, the field data lands in the query and the content of the Response in the body. With <http-data>, only the content of the Response lands in the body. |
|
POST |
If <http-data> is not used in the field, the field data lands in the query and the content of the Response in the body. With <http-data>, only the content of the Response lands in the body. |
|
PUT |
If <http-data> is not used in the field, the field data lands in the query and the content of the Response in the body. With <http-data>, only the content of the Response lands in the body. |
|
PATCH |
If <http-data> is not used in the field, the field data lands in the query and the content of the Response in the body. With <http-data>, only the content of the Response lands in the body. |
|
DELETE |
Error if <http-data> is not used in the field. With <http-data> the content of the Response lands up in the query. |
|
DELETE (with content) |
If <http-data> is not used in the field, the field data lands in the query and the content of the Response in the body. With <http-data>, only the content of the Response lands in the body. |
|
HEAD |
Error if <http-data> is not used in the field. With <http-data> the content of the Response lands up in the query. |
(14) Via DMZ: If set, the connection is established from the DMZ server (if there is one) instead of the internal server. If no DMZ is configured, this checkbox will not be displayed. Note: This also affects the OAuth token refresh if a channel (2) with configured OAuth was specified.
(15) User/Password: Optional values for user name and password. For Windows users with NTLMv1 or NTLMv2 authentication:
If the HTTP server to which you want to connect is a Microsoft IIS and expects an integrated Windows NTLM authentication of version 1 or 2, a domain name can be prefixedto the username. The following syntax is expected in the user name field (please note the double backslash).
|
domain\\user |
(16) Content type: The MIME-Type (Header Content-Type). Note: By default, the encoding (from the Response 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) Expected response: Specifies the expected HTTP response. If the response differs, the request is evaluated as erroneous and thus the Response 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) Return data: If the profile has an Input Agent "HTTP", 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 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 Responses are successful. Note: See also section Status of Phase 6 - Error Behaviour.
(19) No URL encode of variables: 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) Pass on HTTP response as message: 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). In addition, one of the Response custom classes ( PassBackDataResponse , DefaultWebServiceResponse , PassBackBinaryDataResponse , DefaultWebServiceResponseBinary) must then also be used in the following/error profile . See also section Third Possibility - HTTP Response Chain .
(21) Default answer: 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.
(22) Mark whole job as failed if this response fails: Normally a job is not necessarily considered to be erroneous if a single Response fails (see section Status of Response - Error Behaviour). But it can be enforced with this option here.
(23) Additional text on error: Here you can specify an additional log text for the error 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 with file:<http-data>. Please note that the "Encoding" column is then ignored and the encoding of the Response is used. |
|
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 and response header
Since we are practically at the end of the profile in the Response, 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 following system variables:
MSG_CALL_VAR_HTTP_STATUS_CODE
MSG_CALL_VAR_HTTP_STATUS_LINE
MSG_CALL_VAR_HTTP_<name of header in capital letters>.
If the profile has an Input Agent "HTTP", 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/.