Trigger/External Call
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.
The following screenshot shows how to configure the triggering via an HTTP request in a time-driven Input Agent.
(1) 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. Note : If the checkbox Can be triggered on any server is 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). Note: 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.
(2) Indicates whether the profile can be triggered by an HTTP request (GET or POST) , see also (3), (4), (5) . If this option is selected, the profile can still be triggered by another profile. Note: See also the system variables MSG_CALL_HEADER_HTTP_(...).
(3) Specifies the string with which the HTTP request must end. See below. Note: If a file <URL suffix>.ok or <URL suffix>.err has been created (see below), then icons appear here for these, which can be used to edit the files. These files can be created directly via the pencil icon.
(4) If this option is activated, the HTTP response will not be returned until the job for the profile has ended. Attention: If the job is very time-consuming, the remote site of the HTTP request may run into a timeout.
(5) This checkbox will only be active if (4) is set. If this checkbox is set and you are using one of the custom classes PassBackDataResponse, PassBackBinaryDataResponse, DefaultWebserviceResponse or DefaultWebserviceResponseBinary, the return data of the class will be sent in the HTTP response. See also section Profile Chains. Note: If in addition variables of the form VAR_RESPONSE_HTTP_HEADER_<HEADERNAME> are defined, corresponding response headers are set with the initial values of the variables. Example: The variable VAR_RESPONSE_HTTP_HEADER_TEST with the initial value mytest creates the HTTP response header TEST with value mytest.
(6) Here you can specify the MIME type of the HTTP response. Note: For normal text you can use the default value text/html.
(7) Specification of mandatory parameters for requests. A detailed description can be found in section HTTP Request Parameter and HTTP Headers. 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.
(8) If an authentication is necessary, user and password can either explicitly be specified here. Alternatively, a partner channel can be selected, whose credentials are then used instead. See also system variable MSG_CALL_HTTP_AUTH_USER.
Procedure
For an incoming request, the HTTP servlet first looks for the right profile. All profiles that have a time-driven Input Agent with option Trigger/HTTP request and whose URL ends with (3) are searched. Additionally, the HTTP(S) request parameters must match the HTTP(S) request parameter definition (7) (see section HTTP Request Parameter and HTTP Headers). The first matching profile is selected and processing is initiated. If other profiles meet the conditions, these profiles will not be considered.
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.
If, for example, you enter value myprofile in (3) and two parameters (p1=value1, p2=value2) in the parameter list (7), the URL must look like this.
|
http://servername[:port]/dw/trigger/myprofile?p1=value1&p2=value2 |
If user and password are set up in the profile, the profile will only be triggered after a successful login.
If triggered by HTTP, the text OK is returned to the client if the triggering of the profile was successful. It is also possible to specify the responses for success and errors in text files. The following file is searched for and if it exists, is readable and not empty, the content of the file is returned as the response to the HTTP client. Where <URL suffix> is the value in (3) and path separators / must be replaced with an underscore _. These files can be created in (3) directly via the pencil icon.
|
Success |
./conf/http_trigger/<URL suffix>.ok |
|
Error |
./conf/http_trigger/<URL suffix>.err |
Response Status
If the profile was successfully triggered and (4) and (5) are not set, the response status is 200, even if an error occurs in the profile.
If (4) and (5) 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. Subsequent changes to the variable value are not taken into account.
Set Variables in Triggered Profile
You can set variables in the profile via HTTP request headers. For example, if the HTTP request contains the VAR_TEST header, variable MSG_CALL_HEADER_HTTP_VAR_TEST in the profile is set (must be created).