Hello Sri,

A few quick questions,

• Do you know if this document repository is FTP or stored in the database?
• Are all documents you tested broken or just some of them?

If you find these documents are stored in the database and not over the network...

Do you know if the IFS backup and restore process uses the legacy EXP/IMP utilities? If so, you would need to upgrade to the Data Pump EXPDP/IMPDP utilities to get LOB capabilities.

To quickly test this, can you open any PDFs in the report archive?

The documents are stored inside the DB and none of them were opening.

We enabled debugging and figured out that the documents were referencing to a temp directory - same one referenced by the original environment cloned.

Once we created the same physical folder on the Apps Server of the newly created environment, the issue went away.

Thanks for your inputs!

I guess it was the “ticket temp path” used to store a copy of a document while being transferred from the server to the client.

I had exactly the same issue, Cloned copy of our live IFS created for us by IFS.
I replicated the path - c:\IFS\IFSDocMan\Temp - on the cloned server, but user is still getting “Bad Request” error. The sever cloned for us by IFS has the directory structure on the E drive.

Is there not somewhere where the config of “DOCUMENT_TICKET_TEMP_PATH” can be changed within IFS Applications?

For anyone else viewing this. I found the settings at Document Management > Basic Data > Document Basic > Document Default Values.

However the “DOCUMENT_TICKET_TEMP_PATH” cannot be updated from this screen, so I had to do go through “Reconfigure” through the installer on the App Server. I was certain I had already done this on our cloned instance, but anyway the “DOCUMENT_TICKET_TEMP_PATH” setting under Document Default Values now correctly matches the physical location on the App Server.