HTTP (Input Agent)
Introduction: Phase 1 and HTTP and Lobster_data.
Base URL: http(s)://<URL or IP of the Integration Server>/dw/Request (for details see item 1 below)
(1) The URL suffix. The URL for this profile is http(s)://<URL or IP of the Integration Server>/dw/Request/example. See more details in section HTTP Address of Lobster_data.
(2) The allowed HTTP methods. Note: See also the system variables MSG_CALL_HEADER_HTTP_(...).
(3) The Input Agent acts as REST interface. So, for example, if the URL of the Input Agent is http://localhost/dw/Request/example, a request http://localhost/dw/Request/example/orders would be accepted as well. The additional request suffix /orders would then be stored in system variable MSG_CALL_HTTP_PATH_DATA. Otherwise, the Input Agent behaves like for a 'normal' request.
(4) Allows the profile to act as a web service. See sections A Profile Acting as a Web Service (without response) and A Profile Acting as a Web Service (with response).
(5) The MIME type of the response.
(6) Optional name for the multipart of the main data. Normally, Lobster_data will search for a part with name file. If the name is not file, you can enter the alternative part name here. Note: This only applies to multipart requests and if no part with the name file was found! See also section Handling HTTP Multipart Messages below.
(7) An empty HTTP body is not considered an error.
(8) and (9) The response can be sent in two different ways in the case of success:
As a fixed value (9): A static response is sent.
Dynamically (8) with a custom class in a Response Route or with option Return data in Response Routes of type HTTP and Message. See section HTTP Response Chains.
Important note: The system variable VAR_RESPONSE_HTTP_HEADER_RESP_STATUS can be used to set the HTTP response status. If option (8) is set, the variable value will be used by the class to set the HTTP response status. See also system variable VAR_RESPONSE_HTTP_HEADER_<name of the response header>.
(10) Static response that is sent in case of an error. Note: You can use the placeholder {--Exception--} here. If an error occurs in phases 2-6 of the job and the exception message contains a substring §...§, then the placeholder is replaced by the substring text. Example: If you call the function throw exception("§Sorry!§")) in phase 3 of the profile, the placeholder {--Exception--} is replaced by the string Sorry!.
(11) The HTTP status code returned in case of an error.
(12) Either no access control or access control either via one or more selected partner channels or with directly specified login data (user and password). See also system variable MSG_CALL_HTTP_AUTH_USER.
(13) Specification of the request parameters. See section HTTP Request Parameters and HTTP Headers for an explanation of how to access parameter values in the profile via variables.
Note: The system variable MSG_CALL_HEADER_HTTP_METHOD is filled with the method of the HTTP request (e.g. GET, POST, ...), to allow the profile to recognise the request method. The HTTP servlet that forwards the request to the profile is automatically started when Lobster_data is started and reacts by default to the HTTP context /dw/Request or /dw/request. The following component /<suffix> in the URL results from the URL address suffix (1). The servlet first looks for the correct profile for the received request. All profiles that have an HTTP Input Agent and whose URL ends with the value in (1) are searched.
In addition, the HTTP(S) request parameters must match the HTTP(S) request parameter settings (13). The first applicable profile is selected by the servlet and the processing is initiated. If other profiles meet the conditions, these profiles will not be considered.
Example: HTTP requests with the following URL lead to a call of the profile with the Input Agent above and the following request parameter configuration.
|
http://<host>[:<port >]/dw/Request/example?param1=value1¶m2=value2¶m3=value3¶m4=value4 |
Where host refers to the DNS name or IP address of the machine running Lobster_data's Integration Server and port the port of the HTTP(S) service of Lobster_data.
Note: Please also see section Define URL Context System-wide.
Handling HTTP Multipart Messages
The Input Agent always only reads the first multipart, see (6). But the other parts are not lost. They are stored in system variables.
The name of the second part would be saved in variable MSG_CALL_HTTP_MULTIPART1_NAME and its value in MSG_CALL_HTTP_MULTIPART1_VALUE. The third part in MSG_CALL_HTTP_MULTIPART2_NAME and MSG_CALL_HTTP_MULTIPART2_VALUE, etc.
The total number of parts, including the main part (6), is saved in system variable MSG_CALL_HTTP_MULTIPARTS.
Note: Ideally, you know how many parts you will receive and create the variables accordingly. If this is not possible, you can use a little trick to avoid creating the variables. Simply use system variable MSG_CALL_HTTP_MULTIPARTS (of course you can create this variable beforehand) to find out how many parts were received. You then use this value to iterate over a node and read the respective variable values with function copy field by name(variable/result a). You can create the name of the variable with functions iteration-level and concat(a,b,c,d,e,f,g,h). Note: Please do not forget that variable MSG_CALL_HTTP_MULTIPARTS contains the total number of all parts. But you can only read from the second part on from the variables.