Let me first qualify my question by stating that I have basically 0 knowledge of WebFocus. There are other members on my team that do, we're working together to solve a problem, and as the systems engineer on the team, I'm doing what I can to help:

Having said that, we are in a configuration with WebFocus split across a client and reporting server on two different machines. We are using WFServlet to make calls to the repoting server. The reporting server application is shelling out and calling another program that is creating a binary file on disk, that we then want to serve back to the user. Is there a means for doing this? From what I can see, the only connection between the client WebFocus server and the reporting server is through WFServlet. What I am failing to find are the parameters to pass to it to simply serve up a static file and stream it back, like you might if you had created a PDF or excel document on the fly.

I hope I've made some sense, enough anyway to keep any flaming to a minimum. Thanks

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

Well, scooter, this is partially an architectural problem. If you save something on the reporting server, the only way to get it to the WebFOCUS client machine is to ftp it. But once it gets over there, then you still have to figure out how to get it to the requestor's machine. Since you are one Windows, you might want to consider Report Caster and/or shared drives.

I'm sure that someone else will come up with an idea.

There are a few ways to skin this cat. First let me state that Ginny way is generally a good solution. I an going to assume that the file is an htm or html file. lets say that the file is in the temp folder on the c drive and that it is called output.htm. There are may possible solutions here is 1.

APP MAP xxx C:\TEMP
APP PREPENDPATH xxx
-RUN
-HTMLFORM output.htm

Hope this helps

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

So to be clear, there's no way to serve that file back to the users browser without first copying it to the WebFOCUS client server? And again, its a binary file, not HTML. I know you can generate PDF, XLS etc files on the fly in WebFOCUS and then it streams back to the user through the WFServlet. I thought maybe there would be an option to do some type of binarywrite stream from an existing file rather than having to generate the file dynamically.

As I said before, it is a question of architecture. A browser talks to an http server which in turn talks to the WebFOCUS servlet. It points to its ibi\apps directory. If you have a reporting server on another machine, it has its own ibi\apps directory where your file actually gets written when you do an APP HOLD or FILEDEF. In order for a browser, with whatever means you want to use to display it, to get to the file, it must reside in the ibi\apps of the WebFOCUS client box. The only ways I know to get it from the reporting side to the web side would be ftp or shared drives.

Now once it is over on the web side, I have no idea how you would display it in a browser, javascript perhaps?

I think one of us is getting caught up on the wrong thing here, and its more than likely me, but just to be sure I'm going to try to explain this in more detail. The end user is making an HTTP request to our web server with the WebFOCUS software installed, calling WFServlet. That calls the reporting server passing various parameters like application names, FEX files etc. On the WebFOCUS application server/reporting server in our fex file we shell out and call a script that generates an Excel file. Now if that file that is generated were an HTML file, we could simply use the HTMLFORM parameter at the bottom of our FEX file and include that HTML file, and then return back to the HTTP server and display it. But since its not an HTML document, its going to be an excel document, we can't do that (fyi its excel but we cant use the built in functionality of WebFOCUS to generate the excel document because of some of the functionality the document needs. I wasn't there for those conversations so I don't know what the issues are exactly) I think I keep getting hung up because I know you can generate PDF, EXCEL and other data on the reporting server, and send it back to the HTTP server. So whats the difference in generating it in memory and returning it, vs just grabbing an existing file and returning it? Is there any functionality to do that?

Dont know if this is any use... we have a limitation on the size of files we can mail & arent allowed to use ftp. One procedure created a large file & the job itself took a considerable amount of time. To save the user running it...we set the job up in report caster to build a file in an app path, then used the copy command to copy it over to a folder within our our webserver. The user received a notification when the job has run then pulls it
back using their browser.

quote:

So whats the difference in generating it in memory and returning it, vs just grabbing an existing file and returning it?

When you say ON TABLE PCHOLD FORMAT EXL2K, the architecture of WebFOCUS takes care of transporting the document to the client. That is what PCHOLD does. If you are saying in your fex ON TABLE HOLD FORMAT EXL2K, by definition your file will be written on the reporting server platform and you've taken WF out of the transportation business.

But I'm thinking that there was something in a recent post about this. I'll look around and if I find something, I'll post the link here.

https://forums.informationbuilders.com/eve/forums/a/tpc/...061054582#6061054582

Check this one out. There are a couple more. Go to the Search button, pick Advanced, and type in HTMLFORM and EXCEL. You can also try your own combinations. Maybe one of those solutions will work for you.

Thanks Ginny that got me on the right track. I'm very close, but it appears the servlet is mangling the file. So at this point I'm waiting for a call back from our IBI customer service folks. For the record, as a test I did the following:

-SET &TEMPTEST = 'E:\XLSTemp\mytest.xls'
FILEDEF NEWFILE DISK &TEMPTEST
-RUN
SET HTMLFORMTYPE = XLS
-HTMLFORM NEWFILE

XLS file downloads, and the downloaded version is ALMOST the same byte size as the version on the reporting server. And if you open it in a hex editor or even notepad, you see some parts resembling an excel spreadsheet..but it's not the original. Maybe its not possible.

(BNSF:Fort Worth? On Western Center Blvd? I was driving that Sunday on my way home from Saginaw )

quote:

(BNSF:Fort Worth? On Western Center Blvd? I was driving that Sunday on my way home from Saginaw )

Yup!

Also try this

FILEDEF OUTPUT DISK E:\XLSTemp\mytest.xls
-RUN
SET HTMLFORMTYPE = XLS
-HTMLFORM BEGIN
!IBI.FIL.OUTPUT;
-HTMLFORM END 

Hope this helps

I suspect the issue here is the XLS file is a real XLS file.

Is that the case ?

If it is, can you try saving the XLS file as an HTML file and change the extension to XLS and try again ?

I just did a quick test, the XLS format file was corrupted, so was the MHT format file, but the HTML format file returned OK into XL

It would appear that WFServlet does not like binary. Its as if its passing the binary xls file through a text filter. When I attempt to open the file in excel it complains about the file being corrupt. Maybe if I tried

!IBI.FIL.OUTPUT.PLEASE.CONVERT.THIS.TO.BINARY

Hello everybody,

I am not completely sure why this post has been marked as solved, as the problem still seems to be an unresolved issue for binary files. I came across this issue as I also required to "serve" static files via WF.
My current solution a little different to those proposed here and might also be interesting:

I have embedded the binary files to be served in an MHT file (base64 coded) so that WebFOCUS should not meddle with the Bytes inside -HTMLFORM. The files themselves are then made downloadable (link) inside the HTML part of that mht file. With SET HTMLFORMTYPE = MHT WebFOCUS is able to provide these file using -HTMLFORM
base64 conversion is a little tedious to be achieved for binary files in WebFOCUS (nevertheless possible using a

  
FILEDEF INFILE DISK &MYURL (LRECL 1 RECFM F

file and converting more or less directly with a TABLE FILE INFILE request to a base64 representation. However I have written a little java program to perform that task and base64 converted binaries, writing them into WF's apppath so they can easily be read by FOCUS as they have a rather fixed form:

 
FILENAME=base64infile, SUFFIX=FIX     , $
  SEGMENT=BASE64INFILE, SEGTYPE=S0, $
    FIELDNAME=LINE, ALIAS=E02, USAGE=A76, ACTUAL=A76, $

Reading such a file is also straightforward:

 
FILEDEF BASE64INFILE DISK &MYURL (RECFM V
-RUN

TABLE FILE BASE64INFILE
PRINT LINE
ON TABLE HOLD AS MYHOLD FORMAT ALPHA
END

FILEDEF BASE64INFILE CLEAR
-RUN

Afterwards the file, in this case a pdf, only has to be embedded into an MHT file and linked (when JS is enabled, the link is even clicked automatically). Like this:

  
-SET &CRLF=HEXBYT(13, 'A1') | HEXBYT(10, 'A1');
-SET &MYHEAD='' ||
- 'From: Test' | &CRLF |
- 'Subject: ' | &CRLF |
- 'Date: Thu, 6 Jan 2011 12:00:00 +0100' | &CRLF |
- 'MIME-Version: 1.0' | &CRLF |
- 'Content-Type: multipart/related;' | &CRLF |
- ' type="text/html";' | &CRLF |
- ' boundary="----=_NextPart_000_0000_01CB84D1.7F897FE0"' | &CRLF |
- 'X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931' | &CRLF |
- '' || &CRLF ||
- 'This is a multi-part message in MIME format.' | &CRLF |
- '' || &CRLF ||
- '------=_NextPart_000_0000_01CB84D1.7F897FE0' | &CRLF |
- 'Content-Type: text/html; charset=us-ascii' | &CRLF |
- 'Content-Transfer-Encoding: 7bit' | &CRLF |
- '' || &CRLF ||
- '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">' | &CRLF |
- '<HTML><HEAD>' | &CRLF |
- '<META http-equiv=Content-Type content="text/html; =' | &CRLF |
- 'charset=windows-1252">' | &CRLF |
- '<script>' | &CRLF |
- 'window.onload=function(){' | &CRLF |
- 'document.getElementById("link").click();' | &CRLF |
- '};' | &CRLF |
- '</script>' | &CRLF |
- '<META content="MSHTML 6.00.6000.21294" name=GENERATOR></HEAD>' | &CRLF |
- '<BODY><span>File downloaded! Click ' | &CRLF |
- '<a id="link" href="cid:tmp.pdf">here</a>' | &CRLF |
- ' to open it.</div>' | &CRLF |
- '</BODY></HTML>' | &CRLF |
- '' || &CRLF ||
- '------=_NextPart_000_0000_01CB84D1.7F897FE0' | &CRLF |
- 'Content-Type: application/octet-stream' | &CRLF |
- 'Content-ID: <tmp.pdf>' | &CRLF |
- 'Content-Transfer-Encoding: base64' | &CRLF |
- 'Content-Disposition: inline; filename="tmp.pdf"' | &CRLF;
-SET &MYFOOT='' ||
- '------=_NextPart_000_0000_01CB84D1.7F897FE0' | &CRLF;


SET HTMLFORMTYPE = MHT

-HTMLFORM BEGIN
!IBI.AMP.MYHEAD;
!IBI.FIL.MYHOLD;
!IBI.AMP.MYFOOT;
-HTMLFORM END

The solution works fine for me using IE7 and automatically downloads the desired static pdf file when the fex is run. The advantage to a link to that file is you may add your own FOCUS code before and after the "download" to be executed, e.g. a security check if your are implementing your own roles & rights management in WF rather than the in-house WF security-system. Or you may just check, whether the file is still existing and accessible before it can be downloaded.
Yet, the disadvantages of this solution should not be forgotten: higher network traffic (base64 coded binary streams are approx. 37% larger than the original) + compatibility of todays browsers with MHT files. Today, MHT files are natively supported by MS Internet Explorer and Opera, but Plugins are required for FireFox and Chrome.

Hope my solution can be of use to other WF people.