E9.2 Image Media Object - File Name Pointer format / API questions

[BOster]

On our tools release when uploading a PDF, jpg, attachment, etc. it gets stored in either F98MODATA or the file system with a file "pointer" stored in F00165. Here is an example file "pointer" name:

\\server\e920\mediaobj\HTML Upload\FILE-10-1-13-144-7685498787654768-1604678955151.pdf

Also on our tools release the api call JDB_InsertMediaObjectFile will insert a file into F98MODATA and return the semi-randomly generated file name shown above which can be used to construct the F00165 record. However this API is broken (bug wont be fixed until TR9.2.6), additionally we are configured to store attachments on the file system which kind of makes that API call useless but I could still use it to generate the semi-randomly generated file name shown above (insert 1 byte file, grab name, delete).

Questions:
1. Is there a C API equivalent to JDB_InsertMediaObjectFile which will insert to the file system instead of F98MODATA and return the generated file name shown above or even better insert to the file system and create the F00165 record. Most APIs I have used/found only ever write to F00165 and, depending on type, any binary data is stored in the BLOB field of F00165... I have not found one that inserts to the file system and creates the "pointer" shown above or writes to both F98MODATA and F00165.

2. Is there an API that will at least generate the file name "pointer" shown above? I can easily build my own with jdeUniqueId to gen a uid or other call to gen a GUID but the name above looks to have some structure to it. All the names seem to start with "FILE-10-1-13-" followed by a random number + extension. Which leads me to my final question:

3. Does the name structure matter? In other words is there additional meta-data encoded in the file name? Does "FILE-10-1-13-" mean something? Does it indicate file type, etc.

3a. If I just gen a file name pointer as FILE-[GUID].ext will that work or cause issues later on even if it does appear to work?


Edit:
I can't discern any appreciable pattern to the file name. Following are the unique combos I found from our F00165 table:
FILE-10-1-13-153 bmp
FILE-10-1-13-154 bmp
FILE-10-1-13-155 bmp
FILE-10-1-13-142 csv
FILE-10-1-13-145 csv
FILE-10-1-13-142 doc
FILE-10-1-13-143 doc
FILE-10-1-13-145 doc
FILE-10-1-13-151 doc
FILE-10-1-13-152 doc
FILE-10-1-13-153 doc
FILE-10-1-13-154 doc
FILE-10-1-13-155 doc
FILE-10-1-13-152 GIF
FILE-10-1-13-154 gif
FILE-10-1-13-155 GIF
FILE-10-1-13-141 iff
FILE-10-1-13-142 iff
FILE-10-1-13-143 iff
FILE-10-1-13-145 iff
FILE-10-1-13-153 iff
FILE-10-1-13-154 iff
FILE-10-1-13-141 jpg
FILE-10-1-13-142 jpg
FILE-10-1-13-143 jpg
FILE-10-1-13-144 jpg
FILE-10-1-13-145 jpg
FILE-10-1-13-151 jpg
FILE-10-1-13-152 jpg
FILE-10-1-13-153 JPG
FILE-10-1-13-154 jpg
FILE-10-1-13-155 jpg
FILE-10-1-13-141 lsx
FILE-10-1-13-142 lsx
FILE-10-1-13-143 lsx
FILE-10-1-13-144 lsx
FILE-10-1-13-145 lsx
FILE-10-1-13-151 lsx
FILE-10-1-13-152 lsx
FILE-10-1-13-153 lsx
FILE-10-1-13-154 lsx
FILE-10-1-13-155 LSX
FILE-10-1-13-141 ocx
FILE-10-1-13-142 ocx
FILE-10-1-13-143 ocx
FILE-10-1-13-144 ocx
FILE-10-1-13-145 ocx
FILE-10-1-13-151 ocx
FILE-10-1-13-152 ocx
FILE-10-1-13-153 ocx
FILE-10-1-13-154 ocx
FILE-10-1-13-155 ocx
FILE-10-1-11-148 pdf
FILE-10-1-13-129 pdf
FILE-10-1-13-141 pdf
FILE-10-1-13-142 pdf
FILE-10-1-13-143 pdf
FILE-10-1-13-144 pdf
FILE-10-1-13-145 pdf
FILE-10-1-13-151 pdf
FILE-10-1-13-152 pdf
FILE-10-1-13-153 pdf
FILE-10-1-13-154 pdf
FILE-10-1-13-155 pdf
FILE-10-1-13-141 peg
FILE-10-1-13-142 peg
FILE-10-1-13-143 peg
FILE-10-1-13-144 PEG
FILE-10-1-13-145 peg
FILE-10-1-13-151 peg
FILE-10-1-13-152 peg
FILE-10-1-13-153 peg
FILE-10-1-13-154 peg
FILE-10-1-13-155 PEG
FILE-10-1-13-141 PNG
FILE-10-1-13-142 PNG
FILE-10-1-13-143 PNG
FILE-10-1-13-144 PNG
FILE-10-1-13-145 PNG
FILE-10-1-13-151 PNG
FILE-10-1-13-152 PNG
FILE-10-1-13-153 png
FILE-10-1-13-154 PNG
FILE-10-1-13-155 PNG
FILE-10-1-13-143 tif
FILE-10-1-13-151 tif
FILE-10-1-13-152 tif
FILE-10-1-13-153 tif
FILE-10-1-13-154 tif
FILE-10-1-13-155 TIF
FILE-10-1-13-141 txt
FILE-10-1-13-152 txt
FILE-10-1-13-153 txt
FILE-10-1-13-155 txt
FILE-10-1-13-141 xls
FILE-10-1-13-143 xls
FILE-10-1-13-144 xls
FILE-10-1-13-145 xls
FILE-10-1-13-151 xls
FILE-10-1-13-152 xls
FILE-10-1-13-153 xls
FILE-10-1-13-154 xls
FILE-10-1-13-155 xls

 

[Alex_Pastuhov]

File names do not matter, so 3a - yes, you can do it and there won't be any issues. The only issue you may encounter is if you hit the same/existing name - you will be overwriting an existing file then. So if instead of generating meaningless names you start with the original file name, you can check if the target exists and then append a letter or a number to your file name in a loop until it becomes unique, then use it.

And then in light of the above, you may not need any special BSFN's.

 

[Larry_Jones]

Brian,
in our instance (also storing MO Files on File System) we went a different route then using APIs.
Created a DB After Update Trigger on F00165 that moves and renames the file to a different folder (using the Defined Queues in P98MOQUE) and updates the folder and location name in F00165. We implemented that at the beginning of 2019 when we went to 9.2.
As far as File Naming convention as Alex said there isn't one. We borrowed a page from Everest and include the owning document information in the file name, so 2 PO Header attachments for the same PO looks like this
GT4301_292027-OP-00022-000_1.pdf
GT4301_292027-OP-00022-000_2.pdf
Where GT4301 is the MO Object Name, 292027 is the PO #, OP is the Doc Type, 000 is Rev, and the last number is the MO Sequence # incremented.

By Using MO Queues you have flexibility to break up the MOs into folders that aren't a million files in size AND you can get imaginative and redefine those queue definitions as web server folders ...

We also wrote an external to JDE tool that periodically scans files in folders (placed there by users) and moves them into the appropriate MO queue folder and inserts an accompanying F001655 entry for them using the same naming convention. Its a poor man's Document Management system

 

[BOster]

Thanks for the confirmations and information.

I got it all working. just wanted to make sure I wasn't painting myself into a corner with some unknown image MO thing.

I am generating a GUID to construct the file name, actually using the jde API jdeUniqueId which appears to be even stronger than a GUID (returns 64 char string and is "unique amoung all JDE implementations")... I'll take my chances with a uid/guid collision... pretty sure we (the world) will run out of storage space before that happens.

 

[czupet]

I have tried the same approach adding PDF files. But when I click on attachment in E1 I am getting Media Object Fetch Image Failed error message. I still can open the attachment but only after I click OK on the error message. It seems it's something with the file name. Is there another table that needs to be updated besides F00165?