The UAFI program provided by X.400 providers is not supported.

With extremely large files, the communication between the Integration Server and the DMZ server can lead to a timeout. A solution is described in section Dealing with Timeouts Due to Extremely Large Files.

Settings

(1) Channel selection: You have to select an X.400 channel for this Response.

(2) Via DMZ: Specifies whether to send from the Integration Server directly or via the DMZ server. If no DMZ is configured, this checkbox will not be displayed. Note: We advise against this option, as it can lead to performance losses and there is no loss of security for a purely outbound connection if you do not use a DMZ.

(3) From/To/Subject: The values coming from the selected channel (yellow fields) can be overwritten.

(4) Body encoding: If the data is sent in the body, (X.400-specific) encodings are available.

(5) Attach data: Here you can choose if and how the data should be attached (body/attachment).

(6) Activate optional attachments: Here you can additionally attach files from the file system. If you use the prefix "filter:", you can use an entry to define an entire list of files instead of just one file. So all files "orders*.pdf" in this example. The names of the files are also used as names of the attachments. Note: The files are deleted after they have been attached. This behaviour can be prevented by creating a profile variable "VAR_MAIL_SKIP_DELETE_ATTACHMENT" ("type Boolean") with value "true". Phase 3 must be active for this.

(7) MIME type: When data is sent in the attachments (5), the MIME type can be selected. If the MIME type is set to "lobster/unzip", the payload will be considered as a zip file and the contained files will be added as individual attachments.

(8) Name of attachment: The name of the main attachment. Not relevant for (6).

(9) Request confirmation of receipt: This option will only be active after the channel (1) has been selected. If the option is set, an acknowledgement of receipt for the sent X.400 message is requested from the recipient. If option "Use Comm Log" has been set for the channel, the acknowledgement of receipt appears in the MDN. If not, then the acknowledgement of receipt is ignored.

(10) Transmit empty data: If this checkbox is set, empty files are transferred as well.

(11) 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.

(12) Additional text on error: Here you can specify an additional log text for the error case.