Introduction: You can find a description of this phase in section Phase 1 (Introduction).

The profile can either be triggered by another profile or an HTTP request ( GET or POST ) via an HTTP servlet in Lobster_data, which means the profile is controlled by an event. In contrast to profiles with time-driven Input Agents, multiple jobs per profile can be processed in parallel.

Another Profile

If this option is selected, the profile can be triggered by any other profile . Note : See also section Second Possibility - Message and Trigger regarding profile chains.

images/download/attachments/135168359/1529-version-2-modificationdate-1690860292862-api-v2.png

(1) If this checkbox i s not set and the checkbox Profile may only run in one instance is also not set and no value is set in field Start on IS only, a triggered cronjob in a load balancing system is forced to remain on the Working Node on which it was triggered. See also section Settings for Profiles (Load Balancing).

(2) An optional context (default: System) and an optional queue (default: DWForwardReceiver) can be specified here. However, these values must then also be specified in the calling profile, otherwise communication will continue to run via the default values.

HTTP Request

If this option is selected, the profile can be called via HTTP. Note: See also sections Crontab Syntax & HTTP Trigger and HTTP and Lobster_data .

images/download/attachments/135168359/547-version-2-modificationdate-1690862291855-api-v2.png

(1) Indicates whether the profile can be triggered by an HTTP request (GET or POST). If this option is selected, the profile can still be triggered by another profile.

(2) Specifies the string with which the HTTP request must end. See section Request Procedure below.

(3) If this option is activated, the HTTP response will not be returned until the job for the profile has ended. See also sections Request Procedure, Response Header and Response Status below. Attention: If the job is very time-consuming, the remote site of the HTTP request may run into a timeout.

(4) This checkbox will only be active if (3) is set. If this checkbox is set and you are using one of the custom classes PassBackDataResponse, PassBackBinaryDataResponse, DefaultWebserviceResponse or DefaultWebserviceResponseBinary in the Response Route, the return data of the class will be sent in the HTTP response. See also section Profile Chains.

(5) Here you can specify the MIME type of the HTTP response. Note: For normal text you can use the default value text/html.

(6) Specification of mandatory parameters for requests (you can also specify regular expressions with the prefix regex: or regex2: ) . See sections Request Procedure and Request Parameters below. You can select system constants as values. Note: This is also possible with POST requests, but then the parameters must be passed in the URL as with GET.

(7) If an authentication is necessary, user and password can either explicitly be specified here. Alternatively, a partner channel can be selected, whose credentials (Your Access) are then used instead. See also system variable MSG_CALL_HTTP_AUTH_USER.

(8) The authentication method (BASIC, DIGEST, OAUTH2, SYSTEM).

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 also specify an HTTP channel with OAUTH2 configuration in (7).

Request Procedure

The HTTP servlet is started when Lobster_data is started and responds by default to both the HTTP context /dw/trigger and /dw/Trigger. Please also see section Defining URL Context System-wide.

http://<URL/IP Integration Server>/dw/trigger/

For an incoming request, the HTTP servlet first looks for the right profile. All active profiles that have a time-driven Input Agent with schedule type Trigger/External call or Crontab syntax & HTTP Trigger and whose suffix (2) matches the suffix in the request are considered.

http://<URL/IP Integration Server>/dw/trigger/<suffix>

Additionally, the HTTP request parameters must match the HTTP request parameter definition (6). If, for example, you enter value myprofile in (2) and two parameters (p1=value1, p2=value2) in the parameter list (6), the URL must look like this.

http://<URL/IP Integration Server>/dw/trigger/myprofile?p1=value1&p2=value2

The first matching profile is triggered. If the profile requires authentication (7), however, the profile is triggered only after successful authentication. If other profiles meet the conditions, these profiles will not be considered.

Request Parameters

Request parameters can be read with the system variables MSG_CALL_<name of parameter in uppercase letters>. See also section HTTP Request Parameters and HTTP Headers.

Request Headers

Request headers can be read with the system variables MSG_CALL_HEADER_HTTP_<name of header in uppercase letters>. See also section HTTP Request Parameters and HTTP Headers.

Further system variables: MSG_CALL_HEADER_HTTP_METHOD, MSG_CALL_HEADER_HTTP_PROTOCOL, MSG_CALL_HEADER_HTTP_REMOTE_HOST, MSG_CALL_HEADER_HTTP_URI, MSG_CALL_HTTP_AUTH_USER, MSG_CALL_HEADER_HTTP_QUERY.

Response Procedure

There are several options for the response.

By default, if (3) is not set, the text OK is returned as response in case of success. This only means that the profile was successfully triggered. If an error occurs in the profile, this is not apparent. If the profile could not be triggered, you will get a message back that no suitable profile was found.

If (3) is set, the text OK is returned as a response after a successful profile run, followed by a colon and the job number. If an error occurs during the profile run, the error message of the profile is returned. If (4) is also set, the response from the class is returned after a successful profile run (see there).

However, it is also possible to store the response for success and for error each as a text file. These files can be created in (2) directly via the pencil icon. If the respective file exists, is readable and not empty, the file content is returned to the HTTP client as a response. If you want to edit these files manually, you can find them under the following path. The placeholder <URL suffix> stands for the value in (2). If a path separator / is used in (2), e.g. path/myprofile, then the path separator must be replaced by _, e.g. path_myprofile.ok.

Success	./conf/http_trigger/<URL suffix>.ok
Error	./conf/http_trigger/<URL suffix>.err

Response Header

If (3) or (4) are set and system variables of the form VAR_RESPONSE_HTTP_HEADER_<name of response header> are defined, corresponding response headers are set with the initial values of the variables. Example: The system variable VAR_RESPONSE_HTTP_HEADER_Test with the initial value mytest creates the HTTP response header Test with value mytest. Note: The response header Content-Length is ignored, i.e. it cannot be overwritten.

Response Status

If the profile was successfully triggered and (3) and (4) are not set, the response status is 200, even if an error occurs in the profile.

If (3) or (4) are set, the response status is 200 if the profile ran successfully. If an error occurred in the profile, the response status is always 500. In both cases, the response status 200 can also be overwritten with the system variable VAR_RESPONSE_HTTP_HEADER_RESP_STATUS in case of success. However, only the initial value of the variable is used (phase 3 has to be active). Subsequent changes to the variable value are not taken into account.