Response Route HTTP(S)
Introduction: Phase 6 and HTTP and Lobster_data.
(1) 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.
(2) You can assign a local certificate as a client certificate. The client certificate is only used if option (12) is active at the same time.
(3) Computer name or IP address of the computer (not the entire URL) on which the web server to be addressed runs and the port number. 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.
(4) If set in a DMZ environment, the connection is established from the DMZ server instead of the internal server.
(5) Optional values for user name and password. For Windows users with NTLMv1 or NTLMv2 authentication, see also section Windows Authentication at HTTP Server.
(6) The link to be called on the web server (3), without query (9).
(7) Here additional HTTP headers can be inserted.
(8) The HTTP method, e.g. GET or POST.
(9) Query or message (body), see section Method GET/Method POST.
(10) 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.
(11) 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. 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.
(12) If the checkbox is set, the web server is addressed via SSL, so HTTPS is used and the Response Route acts as an HTTPS client. The default port number will then be 443 instead of 80.
(13) See section Web Services.
(14) See section Multipart/Form-Data.
(15) File name pattern for the file to be created. See (14).
(16) If set, the values of variables in field (9) will not be URL-encoded. This option does not work if option (14) is active.
(17) If set, the response of the request can be forwarded to a subsequent profile via a synchronous, asynchronous or persistent Message. In this case, the check in (10) 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.
Notes
Variables can be used in the fields (3), (6) and (9) in addition to static entries. The URL encoding of variables can be turned off with (16) to generate valid values for a URL. Example: A URI (6) can be defined as follows.
/orders/@var__CUSTOMERNAME@/input.cgi
A query (9) might look like this.
ORDNO=@var__ORDERNUMBER@
It is also possible to include the complete data generated during the mapping in a GET query with placeholder <http-data>. However, only small strings should be included in a GET query. For large amounts of data or complex data structures (XML, etc.), we recommend using the method POST, that is, sending the data in the body.
System Variables
The system variables MSG_CALL_VAR_RESPONSE_HTTP_HEADER_STATUS_CODE, MSG_CALL_VAR_RESPONSE_HTTP_HEADER_STATUS_LINE and MSG_CALL_VAR_HTTP_<name of header in uppercase letters> are relevant for reading out HTTP response headers in subsequent profiles, see (17).