Adding an AS2 Partner

Watch video ▶️

1 What is an AS2 Partner

An AS2 Partner definition within the MFTGateway specifies details about a trading partner, with which your Organization would be exchanging messages using AS2. Similar to an AS2 Station, a Partner has a unique AS2 ID, URL and certificates. You will select the Partner, when sending AS2 messages through the MFTGateway. When messages are received into your AS2 inbox, they will also list the Partner from whom they have been received.

2 Creating an AS2 Partner

Partners need to be added/declared on MFT Gateway, before you can send, as well as receive, messages from them. Declaring a Partner requires some information from the respective remote party, such as its AS2 ID, URL and certificate/s. (These are the information of the remote trading station corresponding to the ‘Partner Configuration’ that we saw on our local trading station page in the previous section).

To add a partner, first go to the partners view using the ‘Partners’ icon on the left navigation menu. Then click the ‘New Partner’ button.

2.1 Basic information of a Partner

Provide the required information to configure the trading partner you are about to add. Your Partner would be sending you this information, usually through email.

1. Specify a name for the trading partner. This is a textual identifier for you to easily distinguish this partner from others in the system. This will be very helpful when your partners use cryptic AS2 identifiers, such as 08925485US00 by Walmart. The name will not be used within the AS2 communications.
2. Specify the AS2 Identifier of the partner, which will be provided to you by your Partner.
3. Specify the partner URL that your Partner will provide you. It will be used to send messages to this partner, and the partner would be listening on this URL for incoming messages.
4. Provide a default message subject (similar to an email subject line) which will be used if a subject has not been specified when sending messages. A subject line is optional, and you can leave this to its default value.
5. Check the ‘Advanced Options’ section below if you would be needing to configure any advanced configuration options
6. Upload the partner’s public certificate, which will be provided by your Partner. MFT Gateway will use this to encrypt messages (if encryption has been enabled for outgoing messages), so that they can only be decrypted on the partner’s end, using the corresponding private key.
7. Click the Create button to submit the form.

Once the partner has been created, you will land back in the partner list view. Now that we have a station and a partner, we can proceed to sending our first message!

2.2 Advanced configuration for an AS2 Partner

While most AS2 partners use the same certificate and key-pair for both encryption and digital signatures, there are some partners who use two different ones. If your partner uses two certificates, slide the ‘Use Different Certificate for Signature Verification’ to enable you to upload a separate certificate for digital signatures. In addition, if your partner requires a custom SSL certificate to be trusted to establish a TLS/SSL connection, you can upload it by sliding the ‘HTTPS Certificate’ switch.

Under advanced options, you can specify if the messages sent to this Partner should:

• be encrypted, and if so using which algorithm. (Triple DES is most commonly used)
• be digitally signed, and if so using what sign digest algorithm. (SHA-1 is most commonly used)

Unless your partner has specified specific encryption and digital signature algorithms, it’s best to leave these at their default values. Some partners now choose to use SHA-256 as the sign digest algorithm.

To ensure incoming message security, you can configure unencrypted and/or unsigned incoming messages to be rejected without further processing. Furthermore, you can enforce incoming messages to be signed and encrypted using the same algorithms as outgoing messages and reject otherwise. When rejecting an incoming message, a negative MDN will be sent in return including error details.

In addition, you can specify if compression should be used, and if so, should it be performed before or after signing and encryption. If your Partner supports compression, large EDI files could be compressed well for transmission as smaller payloads.

Finally, you will specify if messages sent to this Partner should ‘Request asynchronous MDN’. By default, this is off, and the MFT Gateway will be requesting a synchronous MDN. However, if your Partner specifies that it will be issuing an asynchronous MDN, you would need to switch this on.

The option to use a static IP address for outgoing AS2 messages to this Partner is an optional value added service, available to Business and Enterprise subscription tiers. If you enable this option, you will need to subscribe to such a tier after your free trial ends.

You can also customize the Transmission Timeout for the partner, which represents the amount of time that MFT Gateway will allocate for a send operation to complete, before marking transmission as failed. If you intend to send larger files to your partner, it is recommended to configure a higher value for this.

2.2.1 Error handling when message transmissions fail

During message sending, if any error prevents the MFTGateway from safely retrying, the MFTGateway will not attempt a retransmission by default. For example, after a message has been sent by the MFTGateway to a Partner, the partner can take a long time to issue a synchronous MDN. During this time the socket connection could timeout and get terminated, but the partner might have successfully enqueued the file after all. In such a scenario, a retransmission will send a duplicate copy of the same file. Usually this would be fine, since higher level applications should safely detect and ignore duplicates. However, to be safe, the MFTGateway will not attempt retransmission of such partially completed operations, unless the ‘Auto Retry Send Incomplete Messages’ is turned on.

Note: This does not apply if the MFTGateway could not send the messages at all in the first place. For example, where maintenance or unexpected downtime of partner systems prevents the MFTGateway from submitting a file, it will be automatically retried ten more times by default, with an exponential backoff between retries. If the message still does not succeed after the retries are exhausted, it will be placed into the Failed state. A user may trigger a retransmission attempt again, by logging into the system, navigating to the Failed messages list, and clicking on the retry button.