outbound virtual filename is 'NOT-CATEGORIZED'

By runtux on Mon, 02/25/2019 - 13:27

I'm trying to send a file to a remote partner. The local (Linux-) filename is not reflected in the OFTP virtial filename, instead the virtual filename is always 'NOT-CATEGORIZED'.
How can I set the virtual filename? I was under the impression I just have to drop a file into the outbound directory and it would retain the file name.

OFTP version is build 39 from 4.01.19

Forum
OFTP2

Comments

Profile picture for user service

Submitted by service on Mon, 02/25/2019 - 16:37

Runtux,

the VFN in OFTP2 is not related to the file name on your OS. It's more a category for the data (e.g. INVOIC, DESADV) and could assigned per additional directory polling in the partner management.

Regards

Submitted by runtux on Tue, 02/26/2019 - 11:30

I need a filename that changes for each transmission. Is there a way to schedule a transfer with a filename that I can specify?
The filename needs to be set by my side, we're transmitting engineering data using ENGDAT, so the filename is specified to start with "ENG" and the date of the transfer plus some additional info in the filename. In addition all files of an ENGDAT transfer need to follow specific filename requirements (so all files of an engdat package need to start with the same prefix).
I've looked into the code and it seems I cannot currently do what I want.
My approach would be to change the poll code to use the local filename and mangle it (uppercase, remove characters that are not permitted for oftp) so that it is a valid oftp filename. What do you think?

Profile picture for user service

Submitted by service on Wed, 02/27/2019 - 08:52

Hello,

There is a field in OFTP2 for the filename but I have seen no software so far that uses that. Please never rely on filenames for EDI data transmission nor put any information into them.
Why don't you zip all your files into a single archive and send this, then the internal file structure and filename is preserved?

Regards

Submitted by runtux on Wed, 02/27/2019 - 09:43

Thanks for the feedback.
We're using ENGDAT (v2 the current standard would be v3) that *does* use the oftp filename.
The standard defines that an engdat package consists of files starting with "ENG", a timestamp, a free field of 5 characters, the number of files in the package and a sequence number, each file is 26 chars in length, examples:
ENG190226160550EEFMT003001
ENG190226160550EEFMT003002
ENG190226160550EEFMT003003
The files have to be transmitted with these filenames, I have no option to change this requirement of the OEM.

I'm currently using the following patch that uses the original filename for the OFTP virtual filename:
diff -r mendelson_opensource_oftp2_1.0b39_src/de/mendelson/comm/oftp2/server/poll/DirPollThread.java mendelson_opensource_oftp2_1.0b39_src-hacked/de/mendelson/comm/oftp2/server/poll/DirPollThread.java
298a299,302
> String virtfile = originalFileName.trim ();
> if (originalFileName == null) {
> virtfile = this.row.getVirtualfilename ();
> }
308c312
< this.row.getVirtualfilename(), this.row.getFileDescription(),
---
> virtfile, this.row.getFileDescription(),

So maybe you want to add an option to a future version to retain the original filename from the spool file:
- make the patch above optional and configurable in the partner dialog
- add more filename sanitizing, e.g. convert to uppercase and remove/replace characters not present in the oftp allowed characters, limit the length

I think this would be an addition that is valid at least for some use-cases of the automotive industry.

Note that there is another (un-answered) ticket with the same request in
http://mendelson-e-c.com/node/3144
that also request this feature (and also seems to be using ENGDAT).

A link to the current ENGDAT spec, this is a newer version that uses XML, the older version v2 we're using uses a special edifact message for transmitting the meta-information but the new version uses the same filename conventions:

https://www.vda.de/dam/vda/publications/1264693439_de_426195488.pdf

The description of the filename convention starts on p.9.

Thanks for your help, I think I can live with my patched version for now but would appreciate a configurable option to retain the spool filename as suggested above.
Best Regards
Ralf Schlatterbeck