The profile can either be triggered by another profile or an HTTP request , 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 .

Settings

(1) Can be triggered on any server: If the checkbox "Can be triggered on any server" 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.

(2) Trigger message context, Trigger message queue: An optional context (default: "System") and an optional queue (default: "DWForwardReceiver") can be specified here for the triggering via message. 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.

Settings

(1) Triggered by HTTP request: 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) URL address suffix: Specifies the string with which the HTTP request must end. See section "Request procedure" below for the total URL.

(3) Send HTTP response after cron job ended: 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) Return data: 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 (phase 6), the return data of the class will be sent in the HTTP response.

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

(6) HTTP parameters: Specification of the mandatory request parameters. See sections " Request procedure" and " Request parameters" below for details.

(7) HTTP access control: 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) WWW authentication: 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).

Schematic structure of the HTTP address

To send data to or start a profile using HTTP, you have to use a specific URL. The schematic structure of the URL is

<protocol>://<server>:<port><URL context>/<URL suffix><query>

Placeholder	Description
<protocol>	"http" or " https" . See also section Adding an HTTPS listener .
<server> and <port>	Here the DNS name or IP address of the Integration Server and optionally the port number as configured for the HTTP listener and/or HTTPS listener are expected. The default ports ("80" for HTTP and "443" for HTTPS) do not have to be specified. If a firewall provides external access to the inside via port forwarding, the parameters of the external connection must be used when accessing from outside. If a DMZ server is used, the external connections of the DMZ server are valid for access.
<URL context>	Normally, "/dw/Request" is used when accessing a profile with an event-driven Input Agent "HTTP" and "/dw/trigger" is used to trigger a profile with a time-driven Input Agent. However, these default settings can be modified in configuration file "./etc/startup.xml". <Call name="addServletContext"> <Arg>DW trigger</Arg> <Arg>/dw/trigger</Arg> <Arg>/</Arg> </Call> <Call name="addServletContext"> <Arg>DW request</Arg> <Arg>/dw/Request</Arg> <Arg>/</Arg> </Call>
<URL suffix>	Is configured in the profile in the Input Agent.
<query>	Here you can specify additional request parameters. The formal structure is "?name1=value1&name2=value2".

Request procedure

The HTTP servlet responds by default to both the HTTP context "/dw/trigger" and "/dw/Trigger".

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

Defining mandatory request parameters

You can determine which parameters at least have to be contained in the respective HTTP request. The following screenshot shows an example of how to set the HTTP request parameters.

images/download/attachments/135168359/1004-version-2-modificationdate-1742530367400-api-v2.png

(9) Name: Name of the HTTP request parameter that must be contained. Note: You can use system constants . Note: If you want to allow multiple values for a parameter, you can create the parameter name multiple times.

(10) Value: If a value is entered in this field, then the affected parameter must have exactly this value in the HTTP request. If the symbol "*" is entered in this field instead of a value, the parameter can have any value. This way, you can specify that the relevant parameter only has to be in the request but does not have to have a specific value. Note: You can use system constants and regular expressions with prefix " regex:" or " regex2:".

The following HTTP requests are accepted in the example.

...?param1=value1&param2=value2&param3=value3&param4=value4
...?param1=value1&param2=value2&param3=value3&param4=valueX
...?param1=value1&param2=value2&param3=value3&param4=valueX&param5=value5

The following HTTP requests are not accepted.

...?param1=value1&param2=value2&param3=value3
...?param1=value1&param2=value2&param3=valueX&param4=valueY

If there are several profiles with the same URL suffix for an incoming HTTP request and an appropriate HTTP request parameter definition, these profiles are equally prepared to accept the request. In this case, the first profile that fits will be used.

Reading HTTP request parameters

You can access the values of HTTP request parameters via variables with the following syntax.

MSG_CALL_<name of the parameter in capital letters>

For example, the parameters "param1" and "param2" of the following HTTP request can be accessed via the variables MSG_CALL_PARAM1" and "MSG_CALL_PARAM2.

http://192.168.213.64:8080/dw/trigger/example?param1=value1&param2=value2

Request headers

Request headers can be read with the system variables MSG_CALL_HEADER_HTTP_<name of header in uppercase letters>.

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.