Phase 6 controls the output of processed data. Here you configure Responses, which the job uses to transfer files to target systems.
Settings
(1) Execute Responses in a separate thread: With this option, the platform runs the Responses in a separate thread. The job does not wait for them to complete. For more information: Thread Queues and Threads.
Note the following special cases:
The option only makes sense if the profile is not already running in a separate thread. For more information: Phase 1.
For Input Agent Rule or HTTP, the platform automatically deactivates the checkbox if the HTTP request response is to come from the customer class. The Response answers the HTTP request directly.
For Input Agent Message, the option only takes effect if the profile is called synchronously. In this case, the platform returns control to the calling profile before the Responses are sent. The calling profile receives no feedback about the send status. If you do not need this feedback, use thread mode. This avoids timeout problems when target systems are unreachable.
CAUTION If the server crashes or stops, the platform restarts all running jobs with threaded Responses. The restart begins from phase 1.
(2) Base file name: Reference the base file name in input fields using the placeholder <basefile>.
(3) Set number range value: For more information: Internal number range and placeholder <n>.
(4) Responses: List of configured Responses with position number. Use the context menu to perform the following actions:
Menu item | Description |
|---|---|
Deactivate response | Deactivates the selected Response. Not available if a variable is entered as a condition in the dependencies. |
Show/edit | Opens the selected Response for viewing and editing. |
Copy entry | Creates a copy of the Response in the list. |
Activate all responses | Activates all Responses for the profile. |
Deactivate all responses | Deactivates all Responses for the profile. |
Delete response | Permanently deletes the selected Response. |
Delete all responses | Permanently deletes all Responses for the profile. |
New response | Adds a new Response to the list. |
Note on saving
If you change a Response, save the profile afterward. Only then does the platform apply the changes.
File names and file patterns
For more information: File names, file patterns, paths, system constants, and variables.
Standard process
Phase 6 transfers the created files via configurable Responses. You can add any number of Responses per profile. You may also use the same Response type multiple times.
A Response is not required. For example, this applies if the Integration Unit already handles all output. It also applies if the mapping process writes data directly to a database.
The Response type determines the transfer protocol, for example FTP or HTTP(S).
For each Response, you set the content type separately. The content type determines the output format of the transmitted file. This way, a job can transfer the same data in multiple formats, for example:
save a CSV file locally
send an XML file (from the XMLMemSaveTemplateParserUnit) to a server
forward the original file to another target
Optionally, configure a postexecuter for each Response. It modifies the file specifically before sending.
IMPORTANT By default, all Responses run once per job. An option allows Responses to run once per data record. For more information: Parsing and When does the parser start a new data record?
States and dependencies
Each Response has a status. You use the status to define dependencies between Responses. For example, Response 2 only runs if Response 1 was successful. The status of all Responses determines the overall status of phase 6. For more information: Dependencies.
Postexecution
Postexecution at the end of phase 6
Optionally, call a Java class at the end of phase 6. The call occurs between the creation and the sending of the output file. The Postexecution class can still modify the file before sending.
Postexecution after the Integration Unit (phase 5)
You can also call a postexecution class in phase 5 (Integration Unit). If multiple Responses use the same postexecuter, a single call in phase 5 is sufficient. You do not need to configure the postexecuter separately in each Response.
Calling a preparser class via a postexecution class (phase 6)
The postexecution class PreParserPostExecuter calls a preparser class in phase 6. This has no connection to the actual parsing process. The preparser class runs here as a postexecution class on the output format.
Backups of output files
For more information: Response file.