Tweet
I already have that configured in my web server configuration. Anything else?
-
-
What is the value passed back to the browser?
In Chrome, you would see it listed under the Response Headers for the vvCall that is the download - here is a sample:
Connection:Keep-Alive
Content-Disposition:attachment; filename="Component Requirements 2012-02-07.xls"
Content-Type:application/vnd.ms-excel
Date:Wed, 08 Feb 2012 01:45:49 GMT
Keep-Alive:timeout=300, max=96
Server:Apache
Transfer-Encoding:chunked
The filename is the one that the browser should use as the filename. If it is, then the browser isn't interpreting the filename. Have you tried more than one browser?Comment
-
In Chrome my Response Headers comes up blank. Chrome comes up with a message that says "Aw. Snap! Something went wrong with this web page. To continue, reload or go to another page."
I tried IE and get the same result as FireFox which is asking whether I want to open or save vvcall.pgm.
I tried Safari and I get the same thing as IE and FireFox. What should we try next?Comment
-
Sorry if this feels like taking a few steps back, but I had an idea. You mentioned to me that you use this same code pattern in other places and it works...If you take these pieces of code and try to serve up a .pdf or .doc, does it work as expected or is the same thing?
I hope this will help us narrow it down to a .docx issue or other possibilities.Comment
-
The code I used on the client side is virtually the same code as we are using with this option. The only difference is that we are outputting a .docx to the browser as opposed to a .csv. The details are slightly different obviously on the html side. On the RPG side the difference is that for a csv file we use procedure vvout-toCSV. For the .docx we are using vvOut-File.
The .csv options work as expected. I just ran the option again to make sure and it works with no problem. We have a number of these options and they have been working for sometime.Comment
-
Want to get on a meeting this afternoon and debug through the code together?Comment
-
It is my code to do the word merge function that is causing the problem. If I skip past my word merge code and send a document previously merged then it works as expected.
I will probably have to take the word merge code and put it into another program. Some trial and error may be required but we are closer to a working solution.Comment
-
I moved the word merge code to a separate program. In the big picture this is probably the right thing to do anyway. I called this program directly from my web program and I still get the same problem. I was not surprised that this happened because they are still running within the same job.
My next attempt will be to use a data queue to pass back information between the web program and my word merge program. I will submit the word merge program as a batch job to get the data queue part working.
Long term it probably would make sense to have the word merge programming already running. But baby steps. I will report back later with my results.Comment
-
Great news GordS! Good luck with your code. Post about your solution if you find something.Comment
-
We got it working with the help of data queues. After we retrieve all the relevant information we need to do the merge, we write an entry to our data queue. At the moment we submit a batch job to do the merge.
The batch job then reads the data queue so it knows what to do. It does the merge of data onto the template and saves a new document. We then write an entry back to the data queue to tell the web program that the file is ready.
The web program in the meantime is waiting to read the information from the data queue. When it gets the record back from the data queue, it downloads the file to the browser user.
It actually is quite quick. The only thing we may change is to make the Word Merge program to always be running.
For more information on how the Word Merge process works go to the following URL. http://www.systeminetwork.com/articl...t-in-rpg-65833Comment
-
Wow, nice solution!Comment
Comment