OFTP
To be able to use the OFTP service, it must be licensed and activated. Please contact our support or sales staff if you are interested.
OFTP (ODETTE FILE TRANSFER PROTOCOL) is a type of FTP over ISDN or TCP/IP.
OFTP means receiving and sending data via Odette file transfer in accordance with VDA 4914-2. The communication is initiated by a partner. After the exchange of so-called Odette IDs that are issued by the "Verband der Automobilindustrie" in Germany and passwords, it is possible to exchange files in both directions. The files contain a preconfigured file name for the transfer. Since OFTP version 2, it is possible to transfer encrypted or unencrypted data. Previously, only the latter was possible.
A confirmation in the form of an End to End Response (EERP) is issued after the transfer. This can either occur immediately after the transfer within the same connection or the recipient independently logs in again to the original sender of the transfer. If the transfer takes place via a third party, the EERP will be sent by the final recipient.
The Lobster Integration Server supports all OFTP versions. Our software was certified for OFTP 2 by Odette and Lobster GmbH is listed as an OFTP2-compliant software manufacturer.
The transfer can be based on several transport layers.
ISDN (B and D channel)
TCP/IP
TLS
For the operation with ISDN, a CAPI-compatible ISDN card and a CAPI driver installed on the system, with which the ISDN card can be accessed, are required. Since the operation of the driver with Java strictly requires the insertion of a so-called JNI layer, it might be necessary, depending on the operating system, to compile a special C file. Precompiled files are already available for the following operating systems.
All supported versions of Windows
Linux systems with CAPI 2.0 drivers (no l4i)
BSD
There is a Java-based driver, which does not require platform-specific components, for devices that have the RCAPI protocol. In this case, no JNI layer is required.
When using the transport layer TCP/IP, the OFTP service has to be configured accordingly. The following listing shows the entry in the configuration file ./etc/oftp.xml required for this purpose.
<Set name="useVersion2ReceiveThreads">True</Set> <!-- Version 2 or 1.3 else --><Call name ="enableTCPListener"> <Arg>127.0.0.1</Arg> <!-- IP address binding to --> <Arg type="int">3305</Arg> <!-- Port listening to --> <Arg type="int">2</Arg> <!-- Number of acceptor threads --></Call>Even if protocol version 2 is specified, it is possible for the server to communicate with partners that do not yet support this version. For this purpose, the highest version that is supported by both sides is dynamically negotiated.
Using OFTP2 features
If the TLS encryption for OFTP over TCP/IP is actually to be used, additional requirements of the configuration of the OFTP server have to be considered. The following listing shows the necessary entry in the configuration file ./etc/oftp.xml to activate a TLS listener. The TLS listener uses a different TCP port than the unencrypted TCP listener.
<Call name="enableTLSListener"> <Arg>0.0.0.0</Arg> <!-- IP address binding to --> <Arg type="int">6619</Arg> <!-- TLS port listening to --> <Arg type="int">2</Arg> <!-- Number of acceptor threads --></Call><Set name="serverCertSubjectName">*CN=OFTP2TLSSECAUTH*</Set>The OFTP service with TLS listener requires a certificate in order to prove its identity to the clients, analogous to the case of a safe web server. The OFTP service looks for this certificate in its local certificates, which can be managed, for example, by using the Partner Administration. The service finds this local certificate with the X.500 address of the certificate by comparing it to parameter "serverCertSubjectName". In case a part of the address, e.g. the canonical name ("CN=..."), is enough for the unique identification of the certificate, it is possible to replace the other parts of the address with the placeholder "*". Of course, the certificate has to exist in the Partner Administration. Thereby, the service is able to accept the incoming TLS connection requests from the clients.
There are more configurations for outgoing connections in file ./etc/oftp.xml. The following listing shows the configuration for using Trusted Server Lists (TSL). The first argument in "addSCXHandlerSettings" with value "OFTP2" is the name of a list of permitted certification authorities (CA), by which a certificate has to be approved in order to be valid. The second argument is a URL, under which this list is provided. It is possible to configure several SCX handlers with different names. Odette administers both the list "OFTP2" for productive OFTP2 connections as well as the list "TEST".
<Call name ="addSCXHandlerSettings"> <Arg>OFTP2</Arg> <!-- Name of the list --> <Arg>http://www.odette.org/TSL/</Arg> <!-- Managed by Odette --></Call><Set name="acceptAllTLSCertificates">true</Set> <!-- Version 2, otherwise, 1.3 -->It is possible to bypass this list by setting parameter "acceptAllTLSCerticates" to "true". In this case, all certificates are accepted, which particularly includes self-signed certificates.
Note: Please notice the difference between TLS (Transport Layer Security) and TSL (Trusted Server List).
Note: Please make sure that your communication partner accepts self-signed certificates as well. This might potentially save time and money for the authentication of your certificate. If the authentication by a certification authority (CA) that is contained in the TSL is strictly required, then the signature process corresponds to the one in section "Self-signed or Certified by the Certification Authority".
Note: For many users, the reason for the transition from OFTP1 to OFTP2 was due to the replacement of ISDN connections by TCP connections. In this case, the Internet connection should take place using a secure channel, that has similar security features to an ISDN connection. In order to achieve this goal, it is usually sufficient to encrypt the Internet connection using TLS (Transport Layer Security). Additional possibilities for encryption and signing of the transmitted data that are additionally implemented in the OFTP2 protocol are not used in this case, but only the secure channel via TLS. Please make sure that the unsecured TCP listener in ./etc/oftp.xml is not activated parallelly to the secure TLS listener unless unencrypted TCP connections should be explicitly enabled. Please also make sure that the permitted subtype TCP/IP in the OFTP2 partner channel is only marked, if you explicitly want to allow unencrypted transmissions. Outbound connections are configured in field "Partner address" of the OFTP channel. The address has to start with "oftps://" for TLS connections and with "oftp://" for unencrypted TCP connections.
Multiple OFTP service instances
For exceptional cases, it might be necessary to configure more than one OFTP service, e.g. if several ISDN devices are to be accessed. It is necessary to assign a name to the second and all further OFTP services in their configuration files (e.g. ./etc/oftp_2.xml), but not to the first OFTP service.
<Set name="name">OftpService_2</Set>The available service names can be selected in the dialogues for the time-driven Input Agent "OFTP" and the Response "OFTP".