|
Buck, I work for a company that specializes in the telecom billing and everything else that goes with it. So I'll suggest you what I thing is a right way to do it, based on my experience. Of course, no need to mention that what ever I write is my personal professional opinion, and is not in any way connected to the company I work for :))) So, the best way to do that is to convert the invoice into pdf format. I can send you some samples privately if you are interested. PDF approach has advantages: doesn't depend on customers choice of browser or settings, customer can print and mail remittance page. You can put all the postal bar codes necessary there. Bookmarks can be put to mark parts of bigger invoice, reports can be separated, company logo inserted ... one word looks much better and more professional than html. I had to deal with a large (huge) invoices that contained over 80 000 pages (big corporate accounts that track call details within hierarchy). PDF can be split into pieces and provide links between predecessors/successors (5000 pages looks like a reasonable limit for a typical PC today). There are two ways to approach creation of invoice images: real time through servlets or JSP, or create them as you run your billing. First approach is possible and has its appeal but second is more efficient as most customers will come to create/view their invoice anyway, and for the rest you might want to print them. Either way, I found JAVA based solutions for PDF creation way better than proprietary iSeries ways (no flames please :))) my personal favorite is iText library of classes. Feel free to mail me personally if you think I can be of more help. Vanja Jovic, Canada Buck.Calabro@commsoft.net wrote:
I am the RPG guy, not a Web guy and so my question needs to be viewed in that light. Our Web person is struggling with her adaptation to the iSeries. We have customers who have multi-million record database files and this is apparently none too common in the Java/Web universe. In particular, we're looking at ways to present a telephone bill on the web. Most residential users' bills can fit on two or three printed pages, and that's easy to do. What's harder is a commercial customer who might have 5,000 toll calls a month. Or more. We started by using the Java toolbox and direct program calls to RPG programs to fetch the data. Call the "customer summary" program and get back the 20 or so data elements that make up the top of the bill. Call the "taxes" program and get back the dozen or so data elements that make up the taxes section. The ProgramCall class is nice because it has connection pooling. Then we get to long distance calls. First, the direct program call method has a 35 parameter limitation. Second, it costs about .3 seconds per call. Doing the math, it would take 25 minutes to call the "get a toll record" program 5000 times. Not a bargain. By blocking the call records up (that is, stuffing as many records as we can into a 64kb parameter) we can reduce the number of calls considerably. This does not seem terribly promising from a maintenance standpoint. Ultimately, there's a limit. We're prototyping a JDBC solution now, but data queues have been bandied about too. So. Has anyone tried to routinely display a list that contains five or ten thousand entries on the web? What architectural approach did you take? --buck _______________________________________________ This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/web400 or email: WEB400-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.