Response "Message"
Messages are used to transfer data to other profiles (or to communicate with other Integration Servers).
The calling of a profile in a Response, in addition to the output data, also transfers the variables to the subsequent profile, where their values can be accessed. Note: See also sections Variables with prefix MSG_CALL_ and Profile chains.
Settings
(1) Profile name: Specifies which profile is to be called. Please note that profiles with time-driven Input Agent will only be displayed in the selection list if "Trigger profile" (see the note on changed values for context and queue ) has previously been selected in option "Content" on the Content settings page.
(2) Context name and (3) Queue name together form a unique key. The values can be freely assigned. As a convention, a generic term such as System or Cluster is specified in the context. This generic term groups similar queues. Both the Message Context and the Message Queue can be specified with variables. This makes it possible to route messages to different queues depending on the data.
(4) Max. execution/life time: Specifies the time in seconds the sending and processing of a message are allowed to take.
With a synchronous message, the profile waits until the target profile has finished processing (successfully or with errors). If the time set here is exceeded, this Response terminates with an error, although the target profile may eventually finish successfully.
In the case of an asynchronous or persistent message, the profile does not wait for the target profile, but the Response ends successfully after the data has been transferred. The message itself has a finite lifetime. If it could not be accepted by the target profile after this time, it will be deleted. The time set here is the maximum lifetime of the message. Note: The minimum lifetime is 12 hours (regardless of the set value).
(5) Message type: There are three different types of messages.
Synchronous. The profile sends the message and does not continue until the response has been received.
Asynchronous. The profile sends the message and continues immediately. The response is irrelevant for the further profile execution.
Persistent. Works almost like Asynchronous. Additionally, however, if the remote system cannot be reached, the message will be stored and resend every 50 ms. If the message could not be delivered after a maximum time (4), it is lost.
(6) Pass data via file: The data is not passed directly to the subsequent profile via the Message Queue. Instead, the data is stored in a file. This file will then be read by the subsequent profile. This procedure is particularly appropriate for very large amounts of data. Note: See also section Phase 6: Responses (OutOfMemoryError) and Phase 6: Responses (performance).
(7) Return data: If the profile has an Input Agent of type "HTTP" and (5) is set to Synchronous, the response (the first converted result of the subsequent profile that has been triggered by this Response) including the HTTP headers can be returned to the external client that had sent the request to the profile. See section Profile chains for details.
(8) Append log of directly following process: With this option, the logs of the called profile can be attached to this job.
(9) Send to a remote system: This checkbox ensures that if this message is to be sent to a remote Integration Server (see section below), it cannot be processed on the local system. Therefore, the checkbox should always be set in this case.
(10) Mark whole job as failed if this response fails: Normally a job is not necessarily considered to be erroneous if a single Response fails (see section Status of Response - Error Behaviour). But it can be enforced with this option here.
(11) Additional text on error: Here you can specify an additional log text for the error case.