Jump to content
Changes to the Jaspersoft community edition download ×

Looking for suggestions on improving use of JR


Recommended Posts

I've got a Java applet that talks to a backend server (all under my control). There's a MySQL database involved on a separate box, that is _only_ accessed by the backend server. That database has the data I wish to report on. I'm currently using JasperReports 1.3.0 for reporting functionality (and I see that many newer versions have come out since).


Currently, I've got a tab in my applet UI that lets the user specify some data - usually a date or date range, and some selected items to report on. When the user clicks the "Get Report" button, that data gets sent to a servlet on the backend server, and that servlet figures out what parameters to pass, which .jasper file to use, and establishes a connection to the database server. Then it does a


jPrint = JasperFillManager.fillReport(sb.toString(), paramMap, conn);


operation to get a JasperPrint object for the desired report. I then send that JasperPrint object back to my applet as a ByteArray[], and once back in my applet, I cast it as a JasperPrint object again and call the JasperViewer to show it to the user.


So far, so good. Mostly. There are two things happening now that are problematic:

Some users have WAY more data than we expected at this point - one user has a data table with 100 million rows. So the queries take a long time and the report doesn't show up. I'm working on that - it looks to be more of a query optimization (and really needs a database schema change to improve things, probably).

I have a "Save" function enabled in the JasperViewer I display. Most clients want XLS or CSV because they want to put data into another database or into Excel for their own purposes, but they like to look at the neatly formatted report initially produced to make sure that the data is indeed what they were expecting. But when they save, the output isn't "useful" to them - they don't want the formatting, the titles, the wrapped cell entries, etc.[/ol]


So - I'm currently leaning toward changing my reporting parameter collection to also let the user select the report format. If they choose "viewable", I'll do what I do now and put the data into a JasperViewer and disable the "Save" function (or at least remove the XLS and CSV options). If they select XLS or CSV, I'll resend the parameters, re-run the query, and select a different .jasper file that doesn't have all the headers, etc. and simply saves the data in the desired format (and I may end up with more questions about doing that effectively later).



I'd toyed with the idea of reworking the servlet to actually run the query I need and sending the data back to the applet, and letting the JasperReport stuff happen at the user's machine, but that gets into a lot of tricky areas that I really don't want to deal with (pushing .jasper files out, dealing with resource limits and lack of files at the user side, etc.)



Can anyone suggest any other options for dealing with getting the output saved in a different format and layout? Are there options in some of the export*() functions that I'm overlooking? Are there new features in the 2.0.3 release that I haven't found yet?




Link to comment
Share on other sites

  • Replies 1
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

GuyWithDogs wrote:

Can anyone suggest any other options for dealing with getting the output saved in a different format and layout?




Based on what I understand of your current design, I think the easiest would be to create a new servlet which accepts a JasperPrint object and a requested output format. Take a look at these parts of the API, where you can go from a JasperPrint object to any of the available export formats:





You could also consider just making those output formats parameters to your existing servlet, but I think you'll gain more flexibility by keeping the concepts separate. You can always call the new servlet from your original one and you can even expose convenience methods to save on TCP traffic when it's all local to the same servlet engine.


Your idea of sending the data back to the applet is a good one, but it doesn't necessarily require that all the JasperReports libraries end up in the applet, either. On the first request, you could send back an XML representation of the data and a JasperPrint object that is its preview. Then, the applet could post the data back and request a different JasperDesign or JRXML and a different export format. Temper this idea, though, with the notion that it encourages round trips of the entire set of data. This has both performance and security implications. There's a lot of flexibility you gain, though. Perhaps you could cache the data on the server and send a reference to it to the client.


Kind regards,


Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...