Introduction: You can find a description of this phase in section Phase 1 (Introduction). See also section HTTP and Lobster_data.

(1) You can obtain these templates (with presets) from the Update Center.

(2) The URL suffix. The URL for this profile is http(s)://<URL or IP of the Integration Server>/dw/Request/example or .../request/example. See section Request Procedure below. Note: You can see the leading part of the endpoint URL via the question mark icon on the left. This, together with the suffix, then results in the total URL.

(3) Only available in mode REST web service (7). Path parameters can be specified here. Exactly one path parameter can be defined between the slashes (see screenshot). Each specified path parameter can be read out with a system variable MSG_CALL_REST_API_PATH_<name of path parameter> (must be defined). Example and notes:

(4) The allowed HTTP methods. Note: If data is to be delivered with a DELETE, the checkbox (5) has to be used. If no payload is delivered, an error is generated in that case. Note: Body Data is supplied depending on the set document type.

(5) See note in (4).

(6) If this checkbox is set, several instances of this profile can work in parallel. The checkbox Profile may only run in one instance must not be set then for this profile. Only works with a fixed response (13). The response then takes place immediately and not when the profile job is completed. Note: If this option is set, jobs of this profile are processed in a Thread Queue.

(7) The mode of the HTTP Input Agent.

(8) If this checkbox is set, the mapping is active and option REST web service (7) is set, a Swagger/OpenAPI interface description is provided in JSON or YAML format. Note: The profile must be saved first.

Example: https://localhost/dw/Request/example?api or https://localhost/dw/Request/example?api&yaml

You can also create your own swagger files via (19), which are then used instead of the automatically generated ones. These files have the name <profile name>. json or <profile name>.yaml and are located in the directory ./conf/openapi. The structure of these files is not described here, please refer to the OpenAPI documentation.

Additionally, a Swagger/OpenAPI interface description in YAML format will be provided to you in a graphical tool (see link on the right). There you can send requests to the interface. URL: http(s)://<URL or IP of the Integration Server>/api/?endpoint=<URL suffix>

Example: https://localhost/api/?endpoint=example

See generally section System Interaction via HTTP (REST API) (instructions there). The data for authentication for profile interfaces comes directly from (17). Important note: You can combine several such profiles into an overall REST API. See section Main Settings (Data Flow).

(9) Only available in mode REST web service (7). All stored test files are displayed here in a further dialogue. There you can specify for each file for which HTTP method (4) they are available in (8). These are then displayed (left) in (8) and can be selected (right) for a request (e.g. with POST).

(10) The MIME type of the response.

(11) 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.

(12) An empty HTTP body (e.g. with POST) is not considered an error.

(13) The response for the success case can be defined in two different ways. The response in the event of an error is always defined in (15).

• Fixed response value, see (14).

• Dynamic response value. Use a Response Route Custom Class with class PassBackDataResponse or set option Return data in a Response Route HTTP or Message. See also section HTTP Response Chains.

(14) Fixed response value, see (13). Line breaks can be inserted with <br>. Note: The placeholders {--jobnr--} or @VAR_JOBNR@ and {--uuid--} or @VAR_SYS_MESSAGE_ID@ are available. Phase 3 variables can also be used with {--@MYVAR@--} or @MYVAR@. Phase 3 must be active for this.

(15) Static response that is sent in case of an error, for both cases in (13). Note: You can use the placeholder {--Exception--} to return the exception that occurred. If 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!. Alternatively, the placeholder {--FullStackTraceException--} can be used to output the full stack trace.

(16) The HTTP status code returned in case of an error. The button can be used to enter further codes with the corresponding response on error (15). These entries can be used by function throw http exception(a,b) (see description there).

(17) Either no access control or access control either via one or more selected partner channels (Your Access) or with directly specified login data. If access control is used, the authentication method (BASIC, DIGEST, OAUTH2, SYSTEM) can be selected. See also system variable MSG_CALL_HTTP_AUTH_USER.

• For SYSTEM, the setting from the configuration file ./etc/startup.xml (→ forceDigestAuthentication) is used. Is shown on page Start .

• If OAUTH2 is used, you must specify an HTTP channel with OAUTH2 configuration.

(18) Specification of the mandatory request parameters (you can also select system constants and specify regular expressions with the prefix regex: or regex2: ) . See sections Request Procedure and Request Parameters below.

(19) See (8).