OFTP overview

Communities can use the Odette File Transfer Protocol V1 or V2 to trade messages with partners.

To use OFTP V1, your partner must use Interchange or Activator 5.8 or later or an interoperable trading engine that supports OFTP V1. For information about OFTP V1 over X.25 see OFTP.

To use OFTP V2, your partner must use Interchange or Activator 5.5.2 or later or an interoperable trading engine that supports OFTP V2. (OFTP V2 is commonly known as OFTP2.)

Note If you are upgrading from a pre-5.8.0 version of Activator and have any ODETTE File Transfer Protocol (OFTP) delivery exchanges, delete the exchanges before upgrading to this release. After installing the upgrade, you can reconfigure the exchanges. If OFTP exchanges are not deleted before upgrading, Activator server will fail to start after upgrading.

Activator implements OFTP as an embedded server. In a community, OFTP is configured as a embedded server to receive messages from clients (your partners). In a partner, the client connection is set up to send messages to a community embedded server.

Bi-directional messaging

OFTP supports bi-directional messaging. When Activator has connected to a partner’s OFTP server to send a message, it also can receive messages from the partner via the same connection. If the partner has multiple messages queued, all can be sent on the same connection. Similarly, Activator can send multiple messages to the partner over the same connection.

Work-around for OFTP file name length limit

OFTP can handle files with names no longer than 26 characters. This is a limitation of the protocol and not of Activator.

However, Activator compensates for this. If an OFTP delivery exchange consumes a file with a name longer than 26 characters, Activator shortens the name to an acceptable length. Without this change, the message would fail due to the protocol limitation.

For example, if a file whose name is too long is consumed, such as:

windows_TO_linux_39001001.edi

Activator renames the file as:

1_ws_TO_linux_39001001.edi

Activator makes sure the changed names are unique by attaching an incremental counter as a prefix. In this example, the counter number is 1_.

In Message Tracker the consumed, long file name is reported as the original file name and the shortened file name is reported as the delivery file name. The renaming also is reported in Activator events log file.

Troubleshooting

To generate debug-level events related to OFTP delivery exchanges, do the following:

Set the following property in the log4j.properties file to debug:

In addition, add the following property to the file:

The log4j.properties file is at <install directory>\conf. See Troubleshooting with the log4j file for more information about using the file.

For OFTP V1 delivery exchanges the statistics monitor also can generate information useful in troubleshooting.

Resource links

Related topics

Related Links