• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Media Object Feature – 9.2.1.0

jdelisths

Reputable Poster
Just an FYI - with 9.2.1.0, media objects and reports are now stored in the database instead of files.
 

craig_welton

Legendary Poster
Yep. Plus business function source, business services source, business view headers, table triggers etc. are stored in tables in central objects. Seems like they are removing any operating system file dependencies. Maybe cloud integration support? Getting rid of the deployment server? (or at least making it less of a dependency)
 

jdelisths

Reputable Poster
Yes, a good portion of the upcoming enhancements are geared towards cloud (these should have been done eons ago, IMO). They have been trying to get rid of the deployment server for a while. Not sure if they will be able to get rid of the fat client as all design tools are still heavily dependent on Windows.
 

Larry_Jones

Legendary Poster
Regarding storage of documents/objects in the database - what about existing media objects? Is there a conversion?
 

JDEE1Tips

Well Known Member
Regarding storage of documents/objects in the database - what about existing media objects? Is there a conversion?
R98MODAT File Conversion
=====================

The R98MODAT Media Object Load UBE was created to move the media object files from the file system to the F98MODAT table and can be used to periodically upload new media object template files as needed. The following are some attributes of the report.

The report driver is over the Media Object Queues (F98MOQUE) table in order to know where to retrieve the content from.
Only queues of type 01, 02, and 05 are processed by the report.
Type 01 are shared queues.
Type 02 and 05 are personal queues.
The report will display a list of all files processed, including each file’s status.

In Tools Release 9.2.1, the UBE cannot run on the iSeries server or the fat client. Tentative: In a subsequent Tools maintenance pack the plan is to allow for the UBE to be able to run on all platforms, including the fat client.the fat client.

For more information refer

E1: MOBJ: Understanding Advanced Media Object (MOBJ) functionality available in 9.2.1 and newer (Doc ID 2199562.1)
E1: MOBJ: Media Object Attachments Moved into the Database starting with Tools Release 9.2.1 (Doc ID 2212744.1)
 

RussellCodlin

Reputable Poster
A couple of notes on this. Firstly, be very careful with the file conversion because the same UBE can also be set to DELETE the files in the source directory. Secondly, if you're using multiple queues then you need to have a serious review of how you utilise media objects in JDE. Access to upload and download media objects is going to be through JDE rather than providing users with access to shares etc. It would be worthwhile looking at moving to a DMS and migrating to HTML links rather than uploading the media objects.

Also, for customers that have a significant volume of media objects, it will be a rather expensive way to store this data. That is, your database generally runs on tier one storage solutions where as media objects can realistically be stored on low cost tier 3 storage without impacting user performance. You also need to take into account the impact it will have on your backup strategy.

Last thing to consider, this is a brand new for JDE so tread carefully because the bleeding edge of technology can get very bloody! Media object are stored within the system tables so this is an instance wide deal so this can't go through the usual DV -> PY -> UA -> PD path for JDE changes.
 

Larry_Jones

Legendary Poster
Good advice Russell. We have approximately 1/2 Terabyte of MO Files that I'm not looking forward to moving into expensive RAID 10 storage.
We can place the new tables on a separate tablespace that maps to a RAID 1 drive but I like the idea of using URL links for some of these files (all our scanned documents are stored as PDFs for example).
 

mdalton

Well Known Member
Craig,I believe that oracle wants to get rid of the deployment server. Oracle wants to run its' software in the Oracle Public Cloud, and not pay MSFT a rip on every install.
 

mdalton

Well Known Member
Hi Larry, your point was my first thought when I heard about Media Objects and Specs moving into the db. Aren't customers going to lose their collective minds when they realize they are paying a huge cost to store MO files. I am very interested in your opinion on this subject.
 

BOster

Legendary Poster
Good advice Russell. We have approximately 1/2 Terabyte of MO Files that I'm not looking forward to moving into expensive RAID 10 storage.
We can place the new tables on a separate tablespace that maps to a RAID 1 drive but I like the idea of using URL links for some of these files (all our scanned documents are stored as PDFs for example).
It would be nice if JDE would support FILESTEAM for MS SQL blob data types (and equivalent on other DBs if it exists). Then you could have the best of both worlds.
 

Larry_Jones

Legendary Poster
I'm also wondering what the impact on database backups / exports will be ...

The one good thing out of this is that this is the first time I've read of Oracle providing a method to convert those awful STG (OLE) files. How were people getting away from ActiveX before this?
 

RussellCodlin

Reputable Poster
No way would I include these tables in the primary database. OCM for the win...
Except that a lot of environments don't present tiered storage to their enterprise database servers so it may take some reconfiguration or even the acquisition of new storage solutions to support this. The other curiosity is whether the Oracle Cloud Provisioning of JDE will give you the flexibility to deploy a tiered database architecture for E1.

Obviously this is just an option at the moment but you would expect at some future tools release will become the only option.
 

JDEE1Tips

Well Known Member
Except that a lot of environments don't present tiered storage to their enterprise database servers so it may take some reconfiguration or even the acquisition of new storage solutions to support this. The other curiosity is whether the Oracle Cloud Provisioning of JDE will give you the flexibility to deploy a tiered database architecture for E1.

Obviously this is just an option at the moment but you would expect at some future tools release will become the only option.
Exactly ! From TR 9.2.1.0, we will be able to store the media object in File system or Database. Jas.ini setting will decide whether media object needs to be stored in Database or File System.
 

Larry_Jones

Legendary Poster
Hey E1Tips, my read of Document 2212744.1 doesn't indicate that we will still have a option of choosing File System or Database.
We either batch convert or it will automatically move MO files to the database as they are opened by users (terrible approach IMO).

Anyway 2212744.1 says:
"With Tools Release 9.2.1, media objects are now written to and read from the database instead of the file system. All new media objects are automatically inserted into the database table F98MODAT. All existing media objects need to be migrated from the file system to the database so they can be accessed by users going forward. This can be done on-demand or by batch process. "
. . .
"With 9.2.1, all media object files will be stored in the database. There is no option to choose between file and database."
 

TFZ

Active Member
Granted, I haven't messed with this much yet as I had to rush it in to a sandbox a few weeks ago, but on my box with Use Win File Sharing still ticked on the JAS server, new stuff's going in to F98MODAT. Even better, it GTFILENAME is basically exactly how it would look if it was going to the share. Fantastic!

I guess it's okay though because all future upgrades are going the magical Oracle cloud, right... right....
 

JDEE1Tips

Well Known Member
Hey E1Tips, my read of Document 2212744.1 doesn't indicate that we will still have a option of choosing File System or Database.
We either batch convert or it will automatically move MO files to the database as they are opened by users (terrible approach IMO).

Anyway 2212744.1 says:
"With Tools Release 9.2.1, media objects are now written to and read from the database instead of the file system. All new media objects are automatically inserted into the database table F98MODAT. All existing media objects need to be migrated from the file system to the database so they can be accessed by users going forward. This can be done on-demand or by batch process. "
. . .
"With 9.2.1, all media object files will be stored in the database. There is no option to choose between file and database."
Refer the document E1: MOBJ: Understanding Advanced Media Object (MOBJ) functionality available in 9.2.1 and newer (Doc ID 2199562.1)

If you choose to use html text attachments (eTXT) and the classic user interface with 9.2.1, then your settings would be:
useEnhancedMediaObjects=false
SupportActiveXIE=false


Media Object Can be Still Stored on File System with 9.2.1.0.jpg

2212744.1 talks for the customer who enabled the Advanced Media Objects Attachments (Release 9.2.1)" .
 
Last edited:

TFZ

Active Member
Still, htmluploads queue is pretty much axed, and attachments go in to F98MODAT - which means regardless - this is going to hit your db and needs to be accounted for in any install/upgrade to 9.2.1 install (until it's maybe fixed...?)
 

Arjun Damodar

Active Member
I looked in the the knowledge garden but it says that the change is compulsory now and there is an existing enhancement request to make it optional Ref:25550813 (https://support.oracle.com/epmos/faces/BugDisplay?parent=DOCUMENT&sourceId=2212744.1&id=25550813) and the status is "Enhancement Req. Internal (Oracle) Review". We are currently not in a position to use this feature due to the dependencies of other systems but we want to move to 9.2.1 because of the workflow message bug fix. I hope we have a solution soon.
 
Top