AS2 Host: AS2 Tab

Specifies whether the trading partner is capable of sending and receiving certificates through Certificate Exchange Messaging (CEM) and allows you to enable Send in Certificate Exchange. See Exchanging certificates with your trading partner.

Possible values:

True: Indicates your trading partner specifies their AS2 product is capable of processing CEM messages but they have not yet sent messages with the header designating their AS2 product's CEM capability.
Note: This field should only be manually set to True if your trading partner has specifically stated that their AS2 product is CEM-Capable.
False: Indicates your trading partner is not CEM-capable. However, when messages are received from a trading partner with the appropriate header designating that it is CEM-capable, this value is automatically changed to True.
False and Ignore Further Detection: Indicates your trading partner is not CEM-capable and disables automatic updating of this value based on inbound trading partner messages.

Default value: False

Use Override AS2 Service Filename Preservation MDN Response Settings to select settings different from the system settings defined in the AS2 Service > AS2 Tab (see Configuring AS2 Service,) and then use Generate Filename Preservation MDN Responses to toggle Filename Preservation for this trading partner.

Filename Preservation is a feature designed for trading relationships requiring stringent file-naming rules. AS2 products complying with Filename Preservation use the Content-Disposition header within the message payload to name the file and when this feature is enabled, a file name must be included in the payload and must conform to specific file-naming rules. Additionally, this feature detects when a file name has already been used within a designated period of time (defined in the AS2 Service: AS2 Tab) and alerts the trading partner with the appropriate warning or error disposition in the returned MDN.

When selected and different from the system setting, the Duplicate Filename Action is also enabled, allowing the following choices:

Retain as Unique, Return Warning: A warning will be returned to the trading partner in the MDN, the message payload will be stored in the rejectbox subdirectory (it will not be made available for back-end processing) and an error will be logged.
Reject Payload, Return Error: An error will be returned to the trading partner in the MDN, no payload will be stored and an Exception will be logged.
Note: Whenever Generate Filename Preservation MDN Responses is selected (either using or overriding the system setting), Overwrite duplicate file names and Use default file name are disabled.

Allows for unique naming of stored files. When this check box is selected, any files that exist in the specified inbox will be overwritten. When cleared, incoming files with the same name as one that already exists will be appended with a unique number beginning with 1 and incremented each time a new file is saved.

Allows the incoming file to be given the name specified in its associated field. Use this option to override the file name specified by the sender. This feature is useful in situations where the received file name must be something other than its original file name, and is common for IBM i / iSeries (AS/400) platforms where the file name must be specified with a .mbr extension. This field can also include any of the supported macros allowing for the incoming file to be named, for example, with a date-time stamp. Subdirectory path identifiers (i.e., ‘/’ or ‘\’) can also be used in conjunction with macros to allow filtering of the incoming file to a specific subdirectory under the inbox based on the value of the macro variable. See Using macro variables (Destination File context) for a discussion of all applicable macros.

Note: If a subdirectory path is specified and it does not already exist, it will automatically be created as needed unless the subdirectory path is under an inbox on the AS/400 Native File System. In that case, the physical file denoting the subdirectory path (in the form: DIRECTORY.FILE) must be created under the specified inbox before files can be written to it.

allows for sorting of incoming messages based on content-type to a subdirectory (under the Inbox specified on the General tab). Specify each of the Content-Types that you would like directed to specific subdirectories by entering a name in the Directory field. Directory entries may be made for Content-Types of: EDIFACT, X12, XML, Binary, Plain Text, EDI Consent and Other (a default catch-all for messages with all other Content-Types you could receive). The same subdirectory can be used for multiple Content-Types. You can also leave Directory entries blank, which will cause any received messages of that Content-Type to be stored in the Inbox specified on the General tab.

For IBM i / iSeries (AS/400) usage, see AS/400 Setup and installation or AS/400 PC network access setup for information on configuring the Content-Type Inbox settings to access the Native File System (NFS).

Note: If you use this feature, incoming messages will be placed in the specified folder based on the content type specified in the HTTP header of the message. The VersaLex application does not check the actual content of the message to determine its content type.