Is there a way to change the file name for PDF's that WebFOCUS automatically assigns?

I am generating a PDF report using a query string and get back in a browser window. The URL of the generated report contains an automatically assigned filename.

For example, for one report I will get "&PG_File=hgnioxas.pdf" as part of the URL and 5 or 6 minutes later, if I run the report again, I get something else.

I would like it to be a name we choose like "Sales2007.pdf" everytime.

The user will either print the report, save it with a meaningful name (what we're trying to do for them), or close the browser window after viewing.

Since it is cached on the client, we don't want to have the Temporary Internet Files directory fill up with a bunch of cached PDF's if they are running the same report with different criteria.

Please advise.

Thanks,

Jim Woods

This message has been edited. Last edited by: <JimW>,

Hi Jim,

I ran some search on Information Builders' online documents as well as Focal Point old topics, and here are some topics that may be of interest:

How to name a file to be held in PDF format

Change default name for one report

Hope this helps.

Cheers,

Kerry

Kerry,

Thanks for the reply.

I tried ON TABLE PCHOLD AS 'MYPDF' FORMAT PDF as a test, and the file name was ignored. An automatically assigned PDF file name was sent back in the URL to the browser as before.

Additionally, I looked at the APP HOLD suggestion and the docs mentions APP HOLD is intended to be used to refresh files that are common for all users of the application.

That wouldn't work as we could have several users running the report with different parameters.

I was thinking there might be a parameter that could be sent in the query string where the report file name could be specified.

While I understand that this technique of automatically assigning the report file name for caching makes report generation faster, it creates the issue of filling the Temporary Internet Files folder on the client with expired reports that may never get cleared.

The desired solution would be to send the report directly to the browser (as it's working now...), and cache it on the client with the same report file name each time.

Regards,

Jim Woods

Well this is the way an IBI person told me to do this a couple of years ago...notice it has .doc on it.
Then it can be e-mailed

FILEDEF VPDOC DISK \\webfsahq01\d$\ibi\apps\chddb_magic\vpdoc.doc

Then in the fex

ON TABLE HOLD AS VPDOC FORMAT HTMTABLE

I hope there's a better way..but this worked.

Thanks for the reply Prarie.

What we're doing is streaming report content directly to the browser rather than saving it to disk.

In that case we would need the unique report file names each time so that one user would not clobber the other's report content by using the same report file name.

The problem is that EXPIRE_REPORTS being set to 300 seconds causes a new PDF report file to be cached after 5 minutes, and the content is stored in the Temporary Internet Files folder on the client.

We don't control the EXPIRE_REPORTS setting (we are a dotNET development group using WebFOCUS), so the net effect is that we get a bunch of expired report files accumulating in that folder that may never be cleared.

We were hoping we could set a parameter to indicate the report file name we want WebFOCUS to use and it would simply overwrite the cache with that report file name; instead of generating a new one each time the cache expires.

Regards,

Jim Woods

IBI Tech Support reply on this issue:

This has never been possible with WebFOCUS and has been requested functionality for some time. There is no workaround.

i wonder if the random variable trick would work? (for the cacheing part of the problem..not the naming) this is a very interesting problem...
and i will have the same one soon , as my current client is pdf-intensive.
in html, if you use a random variable as a parameter in your fex, then the 'page name' (full url with fexname and parms) is never the same as the ones run just before it...
but that's an html trick.
(See how if you 'Publish' a fex from mre, you'll see that ibi random variable in the launch page? )
I wonder if some form of the same technique would work with pdf?
wait..here's another idea...if you bring up the pdf in a frame of a frameset, the user never sees the icky pdf filename, but is still able to click on the pdf buttons to save, email, print, whatever...that is if you have Adobe 8 reader...its quite nice.

The way I see it, you have two things that you are trying to do here:

1) Enter a custom name for your PDF.
2) Prevent the users cache from getting full.

The first one can be resolved by implementing the same type of custom web application filter much like I suggested for opening multiple excel files. The issue there was the name of the excel file was interpreted as WFServlet, so by making that name unique, we were able to open multiple excel files at one time. The same type of technique could be implemented to allow a parm to become the pdf file name.

The second problem can be resolved right now! IE's cache would currently be filled with a pdf reference with the entire query string that is the pdf postback. Look into your cache and you'll see what I mean. If you edit the appropriate wfs file, you can change the java script function to parse the query string and build a form with a post method. When that happens, IE will force the cached file reference to be called WFServlet.pdf or just WFServlet. Therefore every pdf you retrieve will overwrite the current one that is already in the cache. The only issue here is that the current java script function uses a location.replace when calling the querystring. A location.replace is suppose to replace the current browser history file with the one that is being called. Now we all know that IE will only respect the location.replace if the called querystring returns html. When a non-html file is returned, then IE does not perform an actual replace on the history .... thus the back button problem with excel and pdf's. I guess what I'm trying to say here is that for those of us using IE, there would be no change in the user's experience, but for those of you who use other supported browsers that support the location.replace as documented, you would now get the back button issue we all know and love.

I haven't tested any of this yet, just thinking about it. Anyone out there want to give it a try?