Skip to main content

Hi,

We are in middle of upgrading from Apps 9 (IFS Hosted) to Cloud 23R1 (IFS Hosted) and exploring migrating documents from database to FSS repository in IFS Cloud.

While the transfer documents process is working as expected, we have few questions on how this will impact the next Upgrade iterations.

Let’s assume, we create a FSS repository IFS_FSS_IT1 for Iteration 1 and migrate all documents from Database → IFS_FSS_IT1.

For the next upgrade iteration can we create another FSS repository IFS_FSS_IT2 and migrate documents again and will this overwrite/affect files in IFS_FSS_IT1?

The same question can be raised for creating separate storage repositories for each of the three Use Place instances - CFG, UAT & PRD, so they have separate FSS repositories?

Hi @Srikanth 

> For the next upgrade iteration can we create another FSS repository IFS_FSS_IT2 and migrate documents again and will this overwrite/affect files in IFS_FSS_IT1?

I think so, if the file names are the same. Even if you have multiple repos using File Storage, all files will end up in the same “container” (as it is called in Azure Blob Storage), named “docman”.

 


It might also be the case that you will get an error because the file already exist. What is the behavior that you want?


Thank you for you reply.

Ideally, we would like to be able to reset the FSS storage to blank prior to each upgrade iteration so that we will be able to migrate documents using Transfer documents screen from DB to FSS to ensure any new document revisions created between upgrade iterations are available as well.

Based on your second response above, if files which exist throw ‘already exist’ error, will the net new documents between iterations migrate OK ensuring the complete set of documents are available?

However, this also means that the documents which already exist in FSS Repository from previous upgrade itreration and failed to migrate will still reside in the database? This may not work for what we are trying to achieve and already a concern raised by our Upgrade TSM.


...to ensure any new document revisions created between upgrade iterations are available as well.

 

The FS mig tool should take that into account though. That is, pick up new documents, or changed ones. That relies on the logs being preserved in the source database though, and also that the FS file meta data (fss_file_tab) is intact. We don't directly use the latter, but the FS is picky about it being correct.


Just to confirm my question is based on using Transfer Documents screen in IFS Cloud not FS Mig Tool.
Also, the unanswered question is what happens to the documents which already exist in FSS Repository from previous upgrade itreration - will they still reside in the database? 


Just to confirm my question is based on using Transfer Documents screen in IFS Cloud not FS Mig Tool.
Also, the unanswered question is what happens to the documents which already exist in FSS Repository from previous upgrade itreration - will they still reside in the database? 

Aha!

The Transfer Documents screen has not been designed with "upgrade iterations" in mind. It will try to move (not copy) a file from repository A to repository B and, if the file is already there in repository B, what happens is unknown to me, since that's not something we support.

If the file is truly moved, it's very strange, from the perspective of the purpose of that tool, that it suddenly appears in repository A again.

I'm afraid you need to find out what happens by trial and error since you are using this tool in a scenario it was not made for.

There might be errors or it might behave exactly like you want it to.
 


Reply