A channel bundles the essential parameters of a communication connection to a partner. For example, the URL of the server, the login name, the password, etc. for an FTP connection. The name of a channel must be unique.

Bundling in a channel has the advantage that this connection data can be managed centrally. This provides an overview and also facilitates adjustments to the connection data. If a partner server has a new URL/IP, for example, you only have to change it once centrally in the channel and it will automatically be applied to all your profiles, ASM entries and Content Inspection entries if they use the channel. This saves work and also prevents corrupt/inconsistent connection data.

All available channel types are shown in the screenshot above.

All general configuration areas are shown below (using an exemplary FTP channel). Special features of the respective channel types are listed separately.

(1) The channel ID is assigned when the channel is stored for the first time. See also function find channel(partner a, name b, [c]) and system variable VAR_SYS_CHANNEL_RESPONSE[1..n].

(2) If this checkbox is not set, the channel is not active and cannot be used for communication. Even if a channel is active, it cannot be used if the partner to which the channel belongs is not active. See partner list, item (3).

(3) If this checkbox is set, the data of this channel will not be passed on to the DMZ server (if it exists). The channel then does not exist for a DMZ server, so to speak. This can be used to define channels that are not to be accessible to external users and are only used internally. For channel types AS2, X.400, HTTP(S) and all subtypes of FTP also see section Sending via Dynamically Assigned Alternative DMZ. Note: This setting is not available for channel type SMB.

(4) The data direction of the channel. Outgoing (me to partner) means that data from Lobster_data can be transferred to the partner. Incoming (partner to me) means that data from the partner can be transferred to Lobster_data.

(5) If this checkbox is set, the individual steps of the communication with the partner system are additionally logged for this channel. In addition, the messages for the MDNs are logged if the respective partner channel supports MDNs (e.g. channel type AS2). These messages can be viewed in a separate area of the Control Center. Each generated Comm Log entry triggers an event that can be intercepted by the Comm Log Input Agent. Note: The behaviour is slightly different for HTTP channels. Comm Log events are only triggered in the HTTP Response Route and for ASM transmissions via HTTP (MDN for HTTP code >= 200 and < 300, otherwise NDN). However, these are not displayed in the Control Center, but can be intercepted by the Comm Log Inbound Agent. Note: See also option No processing of files already treated.

(6) See section Retention Periods of Backup Files, Logs, Crashed Jobs.