Webpage can not find document

Hello ​@Mark Leunissen ,

How are you attempting to download the file? Is this trough a process flow or just by clicking on the file in a grid/form?

I expect that the problem lies within the fact that your file is saved to a local file storage location that cannot be accessed by the Indicium pool user. If you want this to work you should change the storage location to one that can actually be accessed, which is typically the same server as the one Indicium is running on.

Hope this helps. Feel free to ask additional questions if needed 😊

Kind regards,

Renée

Hi Renée,

The action is indeed through clicking on the file in a grid.

The pool user does have the db_owner rights for the IAM and application databases. The local storage location should be accessible for, since it is already possible to create folders and place documents in the same local storage location. The following screen shot is the only thing I could find about the database pool user permissions. Is there anything else that could be missing?

Kind regards,

Mark

Heyhey,

It is not about whether the pool user has the db_owner rights for the IAM and application database. The point is that the pool user of Indicium or the user accessing the file from the grid needs to be able to access the storage location where the files are saved.

Your original post mentioning that the file_id is null has me believing that you’re trying to open it through use of Indicium, meaning that the pool user is in fact the one trying to reach the file.

However, it’s a bit tough for me to assess the situation with the information that you're currently providing.

Could you provide a bit more detail on how you have set up the file storage location SF-side and what the location that the file is saved at looks like?

Hi Renée,

This is how it's set up in the SF:

The path is configured in the IAM of the Accept environment. This works for the write file process action in a system flow which creates folders and files for the storage location cases_document.

This is how the folders and files are created by the write file:
 

In the IAM of ACC the path is changed to E:\P2P.

The column where the file name is inserted in has a domain which also has the storage location cases_document. Which looks like this:
 

Clicking the file name results in the screenshot from the topic.

Hope this paint a better picture of the situation.

Kind regards,

Mark

Hi ​@Renée Evertzen 

Do you have any further suggestions that I could look into? Or do you need any additional information?

Kind regards,

Mark

The file_id=null simply means that the file has not been pre-cached. This shouldn't further affect anything.

When the disk file points to a directory or when the file cannot be found, a 404 will be returned.

You can check the Indicium logs to see if there are any possible errors on reaching the disks.

To further investigate, you can set up a small process flow which uses the 'Download file' process action on the selected file path and file storage provider and check the output status code using the process flow monitor.

Hi ​@Anne Buit 

Trying to open de file via clicking the folder location in the application doesn't log any errors/messages in the indicium logs. The only this that happens, is the 'Pagina kan niet gevonden worden’ error.

I have built the test flow you mentioned. This works perfectly. I used a table task that starts of the flow for the selected row, which sets the parameters for a read file action. The read file action correctly finds the folder that the pdf is stored in. The output of the read file connector is used in the download file action, which leaves me with the pdf of the selected row. 

Which brings me back to the original question: How do I set opening/downloading the documents via clicking the folder, instead of downloading via a task?

Hello ​@Mark Leunissen,

If you strip off the last segment of the URL (including the forward slash) and just fetch the record by its PK, do you get a result then?

Hi ​@Mark Leunissen 

What is the underlying object for the data? Is it a table or a view? We experience almost the same error when the file is presented from a table. When we use a view instead (with exactly the same columns) everything works as expected

We already raised an issue for that in TCP (#11683).