The AS2 module provides monitoring tools that can assist you in troubleshooting AS2 connections to EFT Server. Below are some important things to consider when troubleshooting failed AS2 connections.
When you install the AS2 module, if you receive the error "Could not register AS2 component," this indicates an error in the ASP.net registration. Refer to The Secure Ad Hoc Transfer Module help for details of the ASP.NET IIS Registration Tool. The tool can be used to register the ASP.NET version.
Ensure that your partner-provided information (AS2 ID, certificates, host information) is accurate and that your provider has configured your account correctly on the remote server.
Provide your certificate file (public key) to your partner and obtain your partner’s public key (unless your partner will be sending you non-encrypted, non-signed messages and does not request an MDN).
Send a test file to your partner. The Test button on the AS2 Configuration wizard sends a test file to a defined AS2 partner to verify connection. The success or failure results are displayed in a prompt that contains each stage of the transfer. The stages include the presence of certificates necessary to sign and/or verify signatures, connection to the host and navigation to the correct path, upload of the test file, and receipt and verification of the MDN receipt. The complete HTTP sent and received headers are captured and displayed in a list box under the success/failure stages. You can select and copy the text of this log for analysis.
Contact your partner and ask them to connect and transfer a test file to EFT Server. If the test is not successful, examine reports and the AS2 Transactions node in EFT Server:
ARM report - AS2 Transactions (Detailed) - Review the report to determine why the problem transaction occurred.
AS2 Transactions node - Review the sub-node on the Status tab to view recent AS2 transactions (retrieved from EFT Server’s ARM database) to identify possible configuration errors.
If you receive an out-of-memory error, the computer on which the Server is installed does not have enough RAM for the size of files that you are sending/receiving. You must have more than the minimum required RAM if you are transferring large non-EDI files over AS2. The maximum concurrent send and receive file size limit is approximately 40% of the Server's RAM. For example, on a Server with 2GB of system memory, the cumulative size of all files being sent or received from/to that AS2 client at one time must not exceed roughly 800MB. Each time a file transfer starts, EFT Server's AS2 module must reserve a slice of memory for that file. The reserved memory is not released until the transfer is complete. If the reserved memory is more than what is available, the operating system (Windows) resorts to using the hard disk cache, which is much slower than RAM and can drastically reduce EFT Server performance.
You must have the Auditing and Reporting module installed to use the AS2 module. If the ARM database is not installed, configured properly, or fails, AS2 functionality is not available.
If the ARM database fails:
For outbound transactions, the transaction is cancelled, and EFT Server sends e-mails, execute commands, and triggers events. (This includes any outbound transaction, whether initiated by AS2 Send File Action or by folder monitor specified in partner AS2 outbound tab.)
For inbound transaction, EFT Server replies to the partner with “500 Internal server error: database failure,” then sends e-mails, executes commands, and triggers events.