Settings

(1) Execute response in own thread: This option causes the Responses to be executed in a separate thread and the termination of the job does not wait for their execution. See also sections Thread Queues and Threads.

There are a few things to consider though. The splitting into a separate thread only makes sense if the profile itself is not already processed in its own thread. For profiles with Input Agent "Rule" or "HTTP" (if the response of the HTTP request should be taken from the custom class) the checkbox is automatically deactivated, because the Response is needed to respond to the HTTP request. For profiles with an Input Agent of type "Message", the option only has an effect if the profile is called via a synchronous message. In this case, the control is returned to the calling profile before the Responses are executed and the caller thus has no information as to whether a Response was successful. If this information is not required, the Responses in profiles using an Input Agent of type Message should always run in a separate thread, so that the caller cannot run in timeout problems if the target systems are unreachable. Note: If the server crashes or terminates, any jobs still to be processed that have a Response configured as a thread will be restarted but from the beginning, i.e. from phase 1.

(2) Base file name: The base file name can be referenced with placeholder <basefile> in input fields.

(3) Set number range value: See section Internal Number Range and Placeholder <n>.

(4) Responses: List of selected Responses (with position number). Context menu:

General note on saving

If you make changes to a Response, you also have to save the profile itself.

File names and file patterns

See section File Names, File Patterns and Paths.

Standard process

The created data can be output via different types of Responses. For each profile, any number of Responses can be defined. Each of the possible Response types can also occur multiple times.

However, a profile does not necessarily need to have a Response. This might, for example, be the case if either the Integration Unit already handles all the outputs or the data is only written to a database during the mapping process. The type of a Response determines how (e.g. via which network protocol) the file is sent to a target system.

For each Response, the content type (i.e. the output format of the transmitted file) can be set individually. This allows a profile job to pass the same data in multiple formats to different destinations, for example, saving it as a CSV file locally and sending it as an XML file to a server and also sending the input file (as received) to another destination. A postexecuter can be configured for each Response, with which the output file can be additionally manipulated.

Important note: All Responses are usually executed once per job, but you also have the option to do that once per record. See also sections Parsing and When does the parser start a new record?

States and dependencies of Responses and state of phase 6

Each individual Response has a state. Via these states, dependencies between Responses can be defined (e.g. Response 2 should only be executed if Response 1 was successful) and the states of all Responses determine the overall state of phase 6.

Postexecution

Backups of output files

See section Response "File".