|
I think where I got lost in your presentation is how you actually passran
parms from RPG to the report. Here is the sample RPG code:
gen = new_RREGenerator();
lReportName = new_String(peReportName);
lReportOut = new_String(peReportOut);
lOutFormat = new_String(%trim(peOutFormat));
lEngine = new_String(peEngine);
success =
RREGenerator_iPrintCompiledReport(
gen:
lReportName:
lReportOut:
peRepParam:
lOutFormat:
lEngine);
Where is peRepParam occupied? I am curious to know how it would
handle a report that had many hundreds of detail lines along with
header type data.
The way I approach this is to have two generic tables - one for header
information and one for detail level information. Then I pass the
GUID key of those DB records to the Java process and have it process
from there. Then I don't have to store all of that business data in
memory. Obviously my approach has MANY more DB I/O calls, which could
degrade performance, but it seems to work well for me on the RPG Chart
Engine project.
Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog/
On Wed, May 12, 2010 at 11:33 AM, Pete Helgren<Pete@xxxxxxxxxx> wrote:
The report design is done with iReport or the BIRT Report designer and
you can add whatever parameters to the report that you need for each
iteration. What RRE does is pass parameters to the report (if needed)
and then run the report for you, outputting to the IFS or emailing the
report. The API is generic so you just pass it the report file and the
output location (or email parameters if that is what you need) and it
runs and delivers the report. So, no, there isn't any additional Java
programming needed for each report.
The idea is that if you had a "stock" report, like an invoice, that you
just needed to pass a customer ID and date to, you could have a green
screen or web front end that prompted for the parameters and then it
andthe report. So, depending upon the report that you have designed, you
pass the API the parameters for the report, the file location of the
report template and the output options and RRE takes care of running
ratherdelivery. The assumption is that the report has already been designed
and just needs to be run.
The iText stuff is a bit more involved because you are programmatically
creating the report on the fly. You pass the API the report title and
heading, you pass the column headings you want, and then iteratively
write the data to the report columns. It is roughly analogous to using
an internally defined report format except you are writing to PDF
Ithan spool file.
Pete
On 5/12/2010 10:17 AM, Aaron Bartell wrote:
I have been meaning to dive into your RPG Report Engine for awhile and
http://www.opensource4i.com/Open_Source_Report_Writing_Tools_for_IBM_i%20-_Orlando_2010.pdfjust now skimmed your presentation. Does each new report require Java
coding to be done? I wasn't quite sure on that.
Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog/
On Wed, May 12, 2010 at 11:06 AM, Pete Helgren<Pete@xxxxxxxxxx> wrote:
FWIW I presented a session at the recent Orlando Common Conference on
"Open Source Report Writing Tools for IBM i". You can find the
presentation here:
which
I also finished up some additional work on the RPG Report Engine
fromnow has an RPG wrapper for iText (rudimentary) and can run reports
(andRPG created for Jasper or BIRT. The BIRT addition took the zip file
from about 10mb to 150mb (!) and I haven't had time to strip out jars
and plugins that aren't relevant to the BIRT report features that the
Report Engine supports but it is all open source and the complete
download.large) zip file can be found here:
http://www.opensource4i.com/downloads/2008042811495836/rrepackage.zip
Even with my new Comcast service it'll probably take a while to
handles
RRE still suffers from not having a "server" piece in place that
generatingthe problem of JVM warm up. A report "server" is the next thing that
will be added but you might find the iText stuff useful for
--PDF directly from RPG.
Pete
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
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.