Solved

Document Management - Moving File Repository

J
Rank
Userlevel 5
Badge +9

We are currently on IFS Apps10 UPD6.  When we originally implemented IFS at Apps8 SP1+, we made the decision to setup Document Management to be stored in the Oracle database.

When we upgrade to Apps10, we moved our quote process into IFS.   With that and other changes, we are seeing significant DB growth, which is mainly due to the number of documents we are storing in Doc Man.  Feedback from our IT team is it’s taking noticeably longer to back up Oracle and to refresh our development environments from Production.   I’m starting to thing about moving our doc man repository out of Oracle.  

Looking for guidance / words of wisdom / lessons learned

  1. Does anyone have experience to share moving document management out of the Oracle database
  2. Pros/Cons for the different doc man repository options?
    1. Do we lose functionality if we move out of Oracle?
  3. At what point would you consider an Oracle database to be “too big”?
icon

Best answer by david.harmer 27 April 2020, 15:35

View original

33 replies

Mathias Dahl
Rank
Userlevel 7
Badge +30

…

 

/Mathias
Mathias Dahl
Rank
Userlevel 7
Badge +30

Currently one of the customers I am working with, use DBMS_LOB.getlength function in a custom field to get the size of a document directly from Edm File Storage. 

In case we move documents from database to a FTP , will it be possible to fetch the file size? Is there any method we can fetch the size from a FTP/Shared folder? 

Hi,

It is possible, but I'm not sure I would recommend it. We have a method for it but, as you might expect, it needs to get "outside" the database, communicating with the FTP server. We do this via our middle tier code in Java, and we call that Java code via the PL/SQL access provider.

Having that being called as the user populate data is asking for performance problems. If I am right and they get problems, we would not accept that as a bug.

The warning aside, this is the method:

Edm_File_API.Get_Repository_File_Size

Why are they doing this in the first place? What is this information telling the user?

Thanks!

/Mathias
 

/Mathias
N
Rank
Badge +2

Thank you Mathias for the answer. 

 

Customer use this custom field to see whether the physical file is connected to ORIGINAL or VIEW record in EDM_FILE_STORAGE. 

 

/Nicum

Mathias Dahl
Rank
Userlevel 7
Badge +30

Thank you Mathias for the answer. 

Customer use this custom field to see whether the physical file is connected to ORIGINAL or VIEW record in EDM_FILE_STORAGE. 

Do they use the size to determine if it is an original file or a view copy? Why not look at the file type?

 

 

/Mathias
B
Rank
Userlevel 1
Badge +3

Thank you Mathias for the answer. 

Customer use this custom field to see whether the physical file is connected to ORIGINAL or VIEW record in EDM_FILE_STORAGE. 

Do they use the size to determine if it is an original file or a view copy? Why not look at the file type?

 

 

I do believe majority of customers in Norway have this set in base profile. Both nice to see the size of file before you download (largest we have is 5,5 GB), as well as seeing there actually is a file there and not only an “empty” record. For documents with Original files you can also see if a View file exist.

Bjørn T. Hetland
Mathias Dahl
Rank
Userlevel 7
Badge +30

Thanks for the input, @BjornH !

/Mathias
B
Rank
Userlevel 1
Badge +3

Hi @Mathias Dahl 

I have the same question as @nicwlk. Almost sure I’ve seen somewhere that it is possible, but not recommended for performance issues, though may mix up with something else.

We have currently moved majority of documents out from DB to local shares on application server, that way we are 100% sure there are never mix up between Prod and Test environment. There are some API’s not working well with “share”, but nothing we haven’t been able to work our way around, except the file-size that is needed on occasions. 

Cheers, Bjørn

Bjørn T. Hetland
Mathias Dahl
Rank
Userlevel 7
Badge +30

Hi @Mathias Dahl 

I have the same question as @nicwlk. Almost sure I’ve seen somewhere that it is possible, but not recommended for performance issues, though may mix up with something else.

If you mean check the file size, yes it is discussed above, and I also mention a possible performance impact there.

 

 

We have currently moved majority of documents out from DB to local shares on application server, that way we are 100% sure there are never mix up between Prod and Test environment. There are some API’s not working well with “share”, but nothing we haven’t been able to work our way around, except the file-size that is needed on occasions. 

Good to know, thanks!

 

/Mathias

Reply


Terms & ConditionsCookie settings