Work with specific protocols and standards > MLLP > Add or modify an MLLP trading delivery

Add or modify an MLLP trading delivery

Add an MLLP trading delivery

About partner deliveries for MLLP

A trading partner delivery is an object that specifies how you want your local community to send messages over the Internet to a remote partner. This topic describes how to create a trading partner delivery for sending client requests to an MLLP server.

Prerequisites

The partner delivery resides in a partner object. Before you add a partner delivery you must add a partner object to represent the MLLP client partner.

Procedure

In the user interface, select Partners >Manage partners to open the Partners page.
Select the partner you want to use to represent your MLLP client partner.
On the partner map of the partner summary page, click the Partner delivery icon.
On the Delivery exchanges page, click Add a delivery.
On the Choose message protocol page, select No packaging and click Next.
On the Choose transport protocol page, select MLLP and click Next.
On the Configure the MLLP settings page, complete the fields:
- MLLP server – Enter the address of the MLLP server to which you are connecting.
- Port – Enter the server port for MLLP connections.
- Client must use TLS to connect to this server – Select this option if TLS is required for the client connection to the MLLP server.
- Enable host name verification – If you require TLS use for connection to the server, you can optionally select this additional security feature.
On the Exchange name page, enter a name for the partner delivery.
Click Finish.

Modify an MLLP trading delivery

After you create an MLLP trading partner delivery, you can view and modify fields that define the delivery.

MLLP settings tab

MLLP server – Network address of the MLLP server.
Port – Access port of the MLLP server.

Schedule tab

See Schedule tab.

Advanced tab

Retries – The number of times Activator retries connecting to the partner’s transport if the initial attempt to connect and send the message failed. The following are common reasons for triggering retries.
- The connection attempt failed immediately for a reason such as host not found.
- The host was found, but the connection process took longer than the connect timeout interval specified on the Advanced tab.
- The connection was successful, but the partner’s HTTP server took longer than the response timeout interval to return a 200 OK response indicating the message was successfully received. A 200 OK response is a transport response, separate from a message protocol response such as an AS2 receipt.
Note that in the last case, the 200 OK response also will include the receipt if synchronous receipts were requested. Otherwise, it will be a simple 200 OK response with no payload. And if an asynchronous receipt was requested, the partner will connect later to send it.
Retries occur according to an algorithm that starts at 5 minutes. The interval between retries increases with each subsequent retry in this pattern: 10 minutes, 15 minutes, 30 minutes, 60 minutes. The interval plateaus at 60 minutes. This means if the retry value is greater than 5, the fifth and each subsequent retry occurs at 60 minute intervals.
For example, if retries is 3, the system will try connecting again in 5 minutes if the initial connection attempt fails. If this retry attempt also fails, the system attempts a second retry in 10 minutes. The third retry attempt is made 15 minutes later. If the third retry attempt fails, the message is given a failed status. So after four attempts (the first attempt plus 3 retries), the message fails. You can search for and manually resubmit failed messages in Message Tracker.
Retries do not occur precisely at these intervals because each connection attempt takes some seconds, which varies by computer. So retries actually occur after the connection attempt time plus the interval.
This control applies only to retrying to send messages, not receiving. It applies only to retrying to send related to transport issues. It does not apply to successfully sent messages for which receipts have not been received as expected. Another control, resends, determines how many times the system will resend a message when a receipt is not received from the partner. For information about resends, see reliable messaging in the collaboration settings chapter.

Connect timeout (seconds) – Time in seconds Activator waits for a connection to the delivery exchange before the attempt times out. Although the default value is 30 seconds, this may be longer than the interval allowed by your operating system (OS). For example, Windows XP by default allows a maximum timeout of 20 seconds. The actual connect timeout interval is the lesser of the OS timeout and the value set in Activator.
Read timeout (seconds) – Time in seconds Activator waits to read data from the delivery exchange before terminating the connection.
Start block character – The decimal byte value to use for the start block character. Start and stop block characters enclose the message data that is sent or received in through MLLP messages. At runtime Activator converts this decimal value to hexadecimal. Default = 11 (hexadecimal B). The default value is the customary MLLP value. You must use the same values for the client and server sides of the MLLP exchange.
End block character – The decimal byte value to use for the end block character. Start and stop block characters enclose the message data that is sent or received in through MLLP messages. At runtime Activator converts this decimal value to hexadecimal. Default = 28 (hexadecimal 1C). The default value is the customary MLLP value. You must use the same values for the client and server sides of the MLLP exchange.
Acknowledgement expected from the target MLLP server – Select this option to keep the connection with the MLLP server open while waiting for acknowledgement.
Back up the files that go through this transport – Indicates whether the system backs up copies of the messages it retrieves from integration or receives from partners.
Backing up files is strongly recommended. This is required for the system to perform fail-over operations such as attempting to send messages again (retries) in case of a transport connection failure. Without backups, a message in process cannot be recovered if the server stops or restarts. Backups also are needed if you want the ability to resubmit messages to back-end applications or resend messages to partners. Backup files are stored in \<install directory>\common\data\backup, unless you specify otherwise.
Post-processing script – The full path to an executable file that contains post-processing commands.