This post is kinda to inform/warn other users of an issue i ran into today when getting a watermark from an external http source and to expose this "issue" to the devs of FFC.
We have this workflow that puts a watermark on an incoming document. This is done with a manifest hotfolder. The manifest contains the http url to this pdf document that should be used as the watermark.
The pdf at the url can be different each time a manifest is being submitted but the url in the manifest stays the same. After the first time the flow is completed, FFC reuses/caches this PDF for each next time the same url is being used in the manifest. So changing the pdf on the server has no effect since FFC uses the local one.
The way that FFC saves the file is by using the last part of the supplied url path, so the watermark at this url:
http://file-url-location.com/assets/file?id=12345
FFC saves as: file.pdf. And each time this url is being used, the watermark that FFC uses is the local saved: file.pdf, even when the pdf on the server is changed. In the Mantis log this looks like:
17-Jun-2022 12:10:08,212 [00000000-0000-0000-0000-000000000000][read1]: [INFO ] Node RefreshResource - Refreshed resource = ResourceDescAttr(260315/http://file-url-location.com/assets/file?id=12345/ resourceUri = C:/Xerox/FreeFlow/Core/00000000-0000-0000-0000-000000000000/Platform/Spool/22ce683a-fada-4e6f-8487-5c76e9745a31/file.pdf cmId = 22ce683a..., content=[0], resourceJobId = 74584.0)
The solution for us is to make each last part of the url path unique in the manifest line. In our situation:
http://file-url-location.com/assets/file/0e1ca0d4-12345?id=12345
Then FFC saves this as: 0e1ca0d4-12345.pdf. Whenever we update the file on our server and submit it to FFC again we use a new unique id which results in the pulling of the updated PDF document.
---
This was quite the pain to figure out, i would have expected FFC to save the file differently, by it's filename (so we could rotate that on the server with for example a timestamp) or any other method. This also feels a bit dangerous since users could think they use an update file, while in fact they are using an old one.
TLDR: FFC reuses downloaded files whenever the URL is not being changed, no matter what is changed server side. FFC saves the downloaded pdf file as the last path paramter in the supplied url.
