hi..

i'm developing the front-end for reports using java and delivering with web service.
when i pass the report output format as HTML, i'm getting the result.
but, when i pass the output parameter as Excel or PDF, i'm getting FILE NOT FOUND error.
yet, the source code of those shows records being fetched from DB with no other error.
please help me solve this.

This message has been edited. Last edited by: Kerry,

Huh?

I have no idea how to read this. Can you provide more detail?

For example: Where does the web service fit in here? Who/what is getting the file not found?

Hi..

The front end is developed using java . Parameters are passed (example Ouput format : HTML , Excel, PDF ) from Java via webservice to WebFOCUS. Then we are generating the repors.

Issue i am facing is : If the output format is HTML , then we are getting the report perfectly.
But If the output format is Excel, then a blank window is opened and showing "File not found" error. When we view the source, it is showing the number of records correctly as below.




<script type="text/javascript" Language="JavaScript">
< !--
function getrep()
{
if(parseInt(window.navigator.appVersion,10)<4)
location.assign("/ibi_apps/WFServlet?PG_REQTYPE=REDIRECT&PG_MRsaved=false&PG_Func=GETBINARY&PG_File=lncxxmdn.xmh");
else
location.replace("/ibi_apps/WFServlet?PG_REQTYPE=REDIRECT&PG_MRsaved=false&PG_Func=GETBINARY&PG_File=lncxxmdn.xmh");
} //-->


< !--
0 NUMBER OF RECORDS IN TABLE= 4 LINES= 4
0 NUMBER OF RECORDS IN TABLE= 4 LINES= 4


Please do the needful.

Are you consuming a WebFOCUS web service? If so, which one?

Based on your post, I will assume that you are not using a WebFOCUS web service, and you are probably just issuing a query string to WebFOCUS. Effectively, you are just issuing a URL, and the container you built for the result is not following the default redirect for pdf and xls responses ... aka the container is not executing the javascript commands.

Log onto the client admin console for WebFOCUS and change the redirect setting for excel and pdf to "no". If your container can manage context types then this should solve your problem.

Where does the PG_FILE value come from?

quote:

Originally posted by Gokul Raj:
PG_File=lncxxmdn.xmh");

Is this hard coded? If so that will never work as the PG_FILE value changes everytime you create an excel report - same for PDFs

As per dhagen - what is your URL to call the "webservice"?

quote:

Originally posted by dhagen:
...and the container you built for the result is not following the default redirect for pdf and xls responses...

I ran into a similar problem a while ago when trying to issue an ajax request for a report. I knew there was a redirect involved but I was astonished that WebFocus was issuing an HTML document with a JavaScript redirect. At the very least it should use a meta redirect in the HTML for those unfortunate souls without JavaScript, but really there should only be a 301 or 302 header and no document body

You shouldn't be that astonished. Most commercial sites do not allow Meta redirects anymore as you are hiding your intention from the browser and they could be viewed as a hijack attempt. 301/2 are not suppose to support dynamic URLs. Therefore the excel or pdf file would have to be web addressable, and now IB would have to do a bunch of other stuff to enforce security. All together it is a simple solution for a fairly complicated process.

We're getting a little off subject here, so back to the "problem"

Gokul, you are NOT consuming a WebFOCUS web service from your Java application. If you are consuming a web service, then you are having that web service issue a query sting to WebFOCUS. OR, you are trying to consume the WebFOCUS query sting as if it is a restful web service (which it is not). Let me be clear, there is NO ANOMALY here. WebFOCUS is behaving as it should based on what you are asking it to do.

All that being said, you should re-architect your application to consume a WebFOCUS web service. I suggest you read up on the "WebFocusRunFex" web service. If you consume an actual web service, then HTML, PDF, and EXCEL output will be encoded in the "output" element of the SOAP response object. This will eliminate problems like re-directions or anything else that may cause you problems downstream.

Hi all,

Thanks for all your reply.
I have fixed the issue by setting the REDIRECT_COOKIE value to OFF in the administration console.

Extremely sorry for the late reply.

quote:

Originally posted by dhagen:
You shouldn't be that astonished...

Sorry for being a pain, but now that the original issue has been resolved I must come back to this point - I can't agree that the best practice approach for a redirect is to use JavaScript. The reasons identified for not using meta or 30x may be valid, I'm not sure enough of myself to say not (though I've read the HTTP specification and didn't see anything precluding dynamic URLs in 30x), but what I do know is that HTTP is a technology-agnostic protocol. All HTTP clients should follow an HTTP redirect (HTTP compliance). All web browsers will follow a meta redirect (including screen readers) unless prevented by the user. However only a web browser with JavaScript enabled will follow a JavaScript redirect.

All I'm getting at is that IBI's redirect approach is the least flexible and least reliable of all the options. This is why I was surprised to see it being used. Not trying to start an argument, simply pointing out what I see as a poor design decision.