Create an AS2 receiver profile - AS2 Server
In order to receive AS2 messages and MDNs from a partner, an AS2 server needs to be created. Several AS2 server entities may be created on the system. Every created AS2 server must be bound to a free address/port. For instance, it is possible to create an AS2 server for every partner. On the defined address/port, the AS2 server waits for inbound AS2 messages. Furthermore, if AS2 messages are to be sent with asynchronous MDN request, one server must be defined as reception server for requested asynchronous MDNs. For further information see parameter description "Asynch MDN Server?"
To reach the menu where an AS2 reception profile can be added, select menu item 52 in the i-effect main menu. A list of existing communication profiles will appear.
Press F6 to call up the menu where a new communication profile can be added. Then, select AS2 communication using option number 1 in the corresponding choice box. In the following menu, please select *RECEIVE.
The following display will appear:
The following parameters can be configured:
| Name/IP | Enter the hostname/IP address to which the AS2 server is bound. |
| TCP/IP port | The port on which the AS2 server waits for incoming connections. |
| Path for Received Data | Determine an IFS directory to store received data. |
This parameter will be dropped in the next version. Indicating a general reception path is unnecessary because AS2 messages are always received partner related.
| Path for Received Headers | If necessary, define a different IFS directory in which header files of inbound AS2 messages are stored. |
This parameter allows IFS directories only.
| Path for Received MDN | If necessary, define a different IFS directory in which successfully received MDNs are stored. |
This parameter allows IFS directories only.
| Path for Sent MDN | If necessary, define a different IFS directory in which successfully sent MDNs are stored. |
This parameter allows IFS directories only.
| Path for Open MDN (asynchronous) | If necessary, define a different IFS directory in which received AS2 messages with asynchronous MDN request are temporarily stored until the requested MDN is transmitted. |
This parameter allows IFS directories only.
| Async MDN Server | AS2 allows to request receipt confirmations for sent AS2 messages. These receipts, so-called MDNs (Message Disposition Notification), can be synchronous or asynchronous. Synchronous means: The requested MDN is returned to the originator during the same connection. If a synchronous MDN is not successfully transmitted via the established connection, the sending process is considered invalid, even if the transmission of the AS2 message was successful. This is necessary due to the lack of proof of reception and processing of the AS2 message on the partner's system without a received MDN. This might happen if an AS2 message is relatively large. The time required to process this message and to return an MDN to the sender on the same connection may exceed the maximum configured time defined in the AS2 sending profile reception timeout. The AS2 client cancels the established connection before the MDN could have been sent to the partner. In order to avoid these situations, an asynchronous MDN for AS2 messages can be requested. But before, please check whether your partner's AS2 system supports asynchronous MDN requests. Asynchronous means: The connection will be closed after the AS2 message has been transmitted to the partner. The requested MDN is sent on a separate connection established by the partner after successful processing on the receiving system. This option is very practical with large messages because processing huge amounts of data easily exceeds the maximum configured time defined in the AS2 sending profile reception timeout. Regrettably, there is no general rule to define the maximum size of a message that still allows a synchronous MDN requests because too many factors have an impact on this process (processing time on the target system, root, etc.). In order to receive asynchronous MDNs for sent AS2 messages, one of the created AS2 servers must be determined as reception server for requested asynchronous MDNs. If only one server was created, use option *YES in this parameter in order to make sure that asynchronous MDNs can be received on this server. This server is then determined as reception server for requested asynchronous MDNs.
| ||||
|
In the current AS2 version only ONE server can be determined to receive asynchronous MDNs. It is not possible to define several MDN servers in the system. | |||||
| Maximum Server Threads | This parameter defines the maximum number of connections an AS2 server will process at the same time. If this maximum number of simultaneous connections is reached, further incoming connections will be put into a waiting line. They are processed as soon as a free connection is available. | ||||
| Reception Timeout | Define the maximum time (in seconds) an AS2 server will wait for data of an incoming connection. If no data is received within the configured time, a timeout error notification is sent and the connection will be closed. | ||||
| Scan Interval Open MDN | After decryption and verification, received AS2 messages with asynchronous MDN request are stored as AS2 object files (.as2) in the IFS directory defined in the parameter "Path for Open MDN (asynchronous)". Therefore, it is necessary to scan this directory for new AS2 object files in regular time intervals to send back outstanding MDNs. The time (in seconds) for this interval can be defined in this parameter. | ||||
| MDN Retry Count | Determine the maximum number of attempts to send requested asynchronous MDNs. | ||||
| External IP, DNS Name | Enter an URL/IP for requested asynchronous MDNs. The partner sends the requested MDN to this address. Therefore, it must be transmitted to the partner system when sending an AS2 message with asynchronous MDN request. In a HTTP/HTTPS transmission, it is the AS2 server's external DNS name or the external IP address. This address must be accessible from outside. | ||||
| External TCP/IP Port | Enter the AS2 server's external TCP/IP port. On this port, the AS2 server accepts MDNs. It must be accessible from outside. | ||||
| SSL | This parameter determines the protocol to be used by the AS2 server. Possible options are *YES and *NO. If *NO is selected, the AS2 server uses the HTTP protocol and is therefore reachable via standard HTTP connections. If *YES is selected, the AS2 server uses the SSL (TLS) protocol and is therefore only reachable via HTTPS connections. If option *YES is set, AS2 server settings can be specified in the parameters "Use Client Authentication ?" "Import Untrustworthy Certificates ?" and "SSL Connection Certificate".
| ||||
| Import Untrustworthy Certificates | If *YES is set in the "SSL" parameter, it is possible to allow the AS2 server to automatically import client certificates that do not exist in the keystore. Therefore, select *YES in this parameter. This might be a security risk inasmuch as every client is considered trustworthy due to automatic import of the client's certificate into the keystore. If *NO is set and the certificate does not exist in the keystore when a connection is established, the connection will automatically be closed. It is correct to abort the connection because the client's identity cannot be verified due to the missing certificate in the keystore. Automatic import of certificates into the keystore is only possible if the parameter "Use Client Authentication ?" is set *YES.
| ||||
| Use Client Authentication | If *YES is set in the "SSL" parameter, this parameter determines if the client sending an AS2 message must authenticate with it's X.509 certificate to the AS2 server. If *YES is set here and *NO is set in the previous parameter "Import Untrustworthy Certificates ?", the partner's certificate must exist in the keystore before establishing a connection. By this, the partner's certificate, automatically sent via an established HTTPS connection, can be verified by the AS2 server. The AS2 server only accepts the incoming connection after successful verification of the client's certificate (check with certificate in the keystore). Otherwise, the connection will be closed due to the lack of proof that it is the partner sending an AS2 message. If *NO is set in this parameter, certificate verification is not requested when establishing a connection.
| ||||
|
This form of SSL authentication is supported by only a few clients and is generally not common on the Internet. | |||||
| SSL Connection Certificate | Enter the name of the key pair containing the public key (certificate) in the keystore. The certificate is transmitted to every client establishing an SSL connection to the AS2 server. The server identifies itself to the client. Therefore the certificate must exist in the client's keystore before connecting. This form of HTTPS authentication is standard practice on the Internet. | ||||
| Description | A short description of the created AS2 server can be created here. This field has only a descriptive character, its content is arbitrary. | ||||