GUI

(1) This option causes the Response Routes 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) Lobster_data deactivates the checkbox because the Response Route 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 Response Routes are executed and the caller thus has no information as to whether a Response Route was successful. If this information is not required, the Response Routes 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 Route configured as a thread will be restarted but from the beginning, i.e. from phase 1.

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

(3) See section Internal Number Range and Placeholder <n>.

(4) Normally a job is not necessarily considered to be erroneous if a single Response Route fails (see section Status of Response Route - Error Behaviour). But it can be enforced with this option here.

(5) Here you can specify an additional log text for the error case.

(6) See section 2. Inhalts-Einstellungen.

(7) See section 1. Antwortweg-Typen.

(8) See section Dependencies.

(9) See section Connection settings.

(10) See section ASM settings.

General note on saving

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

Context menu

File names and file patterns

See section File Names, File Patterns and Paths.

Standard process

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

However, a profile does not necessarily need to have a Response Route. 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 Route determines how (e.g. via which network protocol) the file is sent to a target system.

For each Response Route, 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 Route, with which the output file can be additionally manipulated.

Important note: All Response Routes 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 Response Routes and state of phase 6

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

Postexecution

Backups of output files

See section Response Route "File".