Jump to content

Jasper Server Improvement Suggestions


developerdude

Recommended Posts

 Excuse me if there is a better or more specific place to provide these suggestions, but I searched the forum and didn't see a likely candidate. I also didn't see an explicit list of what is in the 3.5 RC - just an overview.

 

I thought I would provide some of my personal observations (and some of those of my co-workers) after using JasperServer for a while. I am a Java dev with some experience on both server and client side and my co-workers are technical too just so you have an idea of where we are coming from. We use JasperServer to automate some internal, but mostly external reports. The external reports get sent to our clients - they do not log into JasperServer. We either use the email report feature or we export the reports ourselves to an FTP server. I believe the version we are using is 3.1.0 (see suggestion below about displaying version somewhere in the app itself).

 

These suggestions are in order as they occur to me, not necessarily the order of importance. Feel free to correct me if I am mistaken about my assumptions in any of these suggestions - maybe I did not read the manual thoroughly enough or just missed how to do something.

 

1) Somewhere in the JS UI, display the current version of the app. I don't see any obvious way to find this.

 

2) When editing a report setup, whether it is the data source setup, which JRXML to use, the schedule, whatever, display the report name/lable/something to tell me which report I am editing - don't rely on me remembering.

 

3) When I am submitting a JRXML file use for the report, if one is already being used, it would be nice to know the file name of that report when it was submitted so I can make sure I am submitting the same JRXML. 

 

4) I would like to be able to at least examine the JRXML that is being used for a report. Editing it would be nice too, but I at least want to look at it.

 

5) Via the web services there doesn't seem to be any way to pull out a report that has been run and resulted in a file in the repository. The 'resources' can be retrieved, but not the report itself from what I can tell. In order to retrieve a scheduled report, I have written an app that uses Quartz to schedule an export shortly after the report is run. I use the HTTP protocol to download the report from the expected view URL for the report which I construct from some constants and report/schedule data I get via the web services. I know this is something a lot of people want and I have it working on our systems, but the whole thing of downloading via HTTP is crude when I should just be able to ask for it from the repository.

 

6) Of course there is the suggestion that JasperServer should be able to export scheduled reports to a file system, whether it is a network share, an FTP server or whatever. Using Apache Commons VFS would make this a fairly straighforward feature to add.

 

6) The default setting for the DBCP pool should contain a 'testOnBorrow=true' and a validationQuery. This is a common problem for JDBC connection pools, especially for mySQL (which is the default DBMS installed) and a common problem posted here when people encounter the mySQL timeout exceptions.

 

7) The log4j setup should use the "DATE" param, not "ABSOLUTE": Since the appender is not a rolling date appender and a bunch of days get put into one log, I have no idea what date a particular log entry happened. I have changed our local setup to use the %d{DATE} param and to use a org.apache.log4j.DailyRollingFileAppender 

 

8) The positioning of the checkbox and clock next to the report name in the repository is problematic: it is easy to mistakenly run a report by clicking on the report name instead of the clock or check box. This is not a small thing to us: many of our reports are not idempotent and require manual resetting if they are mistakenly run.

 

9) Occasionally we have had reports that were scheduled not run, or run and not be emailed or some other problem that intereferes with what we want to be an automated report system. The difficulty of searching the logs makes it very hard to determine what happened. The DBCP connection timeout issues have cause problems. Adding mechanisms to proactively email or otherwise notify admins of problems and/or success of scheduled jobs would be valuable to people who use JasperServer as we do. As it is I am having to create external apps to examine various breakpoints in the process to notify admins of problems.

 

10) Empty Reports. I have changed most of our reports to use "whenNoDataType” == “noPages”, but from what I can tell, for some formats this causes some reports to be empty and some to not be created at all (I am waiting for the next run to gather data on this - but this is what I can tell from my online research here at the forums and from googling it).  Basically I would prefer that no report file at all be created for any format when this option is set to "noPages", or add another option of "noOutput" or "noFile" or something along those lines. I have read enough posts/threads on what people want to know that everybody wants something different, including custom output of "No Data Available", but for our process no file at all would be the best outcome. My exporter has no easy way of knowing if an XLS or PDF file is empty because these generally have some bytes of data even when empty - I would have to open them and analyze them programmatically to determine if they are empty shells or not.

 

11) Related to #9 and #10. Some mechanism via web services to get more info about the status of scheduled report jobs after they have been run. Whether the run resulted in an empty report. Whether the run resulted in an exception and what the exception was. Whether the run was successful. I know there is a "messages" area in the UI, but I have seen more failure that resulted in no message than there are failures that have a message there. There should be separate failure and success notification mechanisms: our clients don't like to be emailed Java exceptions instead of reports (I have heard that this was actually a requested feature - but I would turn it off if I could). If something fails and JS is going to email that failure, then have a separate list for failures and a list for successful reports. That is how my exporter works.

 

I will probably think of some more issues, but I hope these are helpful and constructive.

 

Link to comment
Share on other sites

  • Replies 13
  • Created
  • Last Reply

Top Posters In This Topic

At least one more I forgot: Report file output. 

 

a) The use of a hyphen separator between the base file name and the timestamp pattern. That should be configurable via the UI. Some people may want no separator, or a period or an underscore.

 

b) The hardcoding of a format as the extension for a filename. The default setting for Windows desktops is to open a CSV file with Excel which munges the file. Many people would therefore prefer a CSV file to be sent to them with a 'txt' extension. I would prefer if I could set the extension for the file in the JS UI. CUrrently I have my exporter convert it.

 

c) The placement of the timestamp pattern in the file name. It would be nice to be able to define where that is. Some people want it to appear in between a prefix and a suffix. Currently it is always just appended to the filename before the extension.

Link to comment
Share on other sites

Hi developerdude  , very good suggestion. I'll share my comments as well.

#1 - Yes, this is important and good to have. In my case, i have put this version next to title

#2 - Ya, good suggestion. Sometime i will go back and check again the report name :-)

#3 - That is the reason i always name it same as my actual xml file name.

#6 (1) - Good suggestion. New things for me to learn

#9 - Yes, JS have improve by sending error message to scheduled report recipient, but i have requested to enhance this feature. Refer to "Tracker"

#10 - You can use "NoData" band section to write custom messages and display to user if the report is empty.

Post 2 -(b) - It is not make sense to change a file extension (eg: *.xls to *.zip), but it really have meaning changing *.csv to *.txt Even my current requirement is to generate a txt file with some field delimiter (actually a CSV file just the extension is .txt). So, to make it more useful, i would love to see all report export option (eg: csv-> field delimiter, xls-> remove blank row) to be available in UI, so that i can set right in UI instead editing the xml file . This can be extend to create more report export with different option. Meaning, i'll choose "CSV" as report type and set option "delimiter" as "|" and name it as "CSV 1". Then create the same type with "," as delimiter and name it as "CSV 2"

 

One more suggestion, if somehow the report fail to generate/send email, JS will re-try for n times before it concluded as "fail" and notify the JS admin.



Post Edited by Anandharaj @ Raj at 03/19/09 01:48
Link to comment
Share on other sites

Hello!

i would like to add to following to this list are:

1. Most importent Cascaded Input controls.

2. Pass Collection from Parent report to child in case of multi-select input controls.

    On parent report i have selected the some values from Multi-Select Control, now i want to drill to a child report with the options 

   selected on parent report and wants to show values selected in Multi-Select control on child report.

3. Customized input control placing on report (by default it depends on the sequence of adding input controls to the  report)

4. Cache option is also importent.

 

Thanks & Regards,

Yash

 

 

 

Link to comment
Share on other sites

anandharaj: "One more suggestion, if somehow the report fail to generate/send email, JS will re-try for n times before it concluded as "fail" and notify the JS admin."

 

I believe there may be an option/setting in the Quartz/scheduler config that will get this behavior for you - you might want to check into that if you wish.

Link to comment
Share on other sites

 A couple more suggestions:

 

a) When trying to access a report file that doesn't exist via the 'fileview' URL (e.g., http://localhost:8080/jasperserver/fileview/fileview/some file name), if the file doesn't exist then I get back a 500 response code. This should be a 404 response code ('not found') IMO. A 500 response code could mean anything.

 

b) I patched our server instance code to not generate a report file if the report result is empty - similar to what happens when the 'skip if empty' option is set for the email notifications (code below). This is related to #9, #10 and #11 suggestions.

 

c) Log when a scheduled job starts, when it ends, and whether it was successful or not.

Code:
if ((result != null) && !isEmpty(result)){	outputs = createReportOutputs(result);	saveToRepository(outputs);}else	if (isEmpty(result))		log.warn("No data results found for Job: " + jobDetails.getLabel());
Link to comment
Share on other sites

hi anandharaj!

Thanks for comments, can u tell me how to configure JRVirtualizer in application-context.xml, report-scheduling....xml etc.

I would like to add one more point to Improve the Jasper Server.

JS Should support Trigger/Condition Based report scheduling.....

Thanks & Regarads,

Yash

 

Link to comment
Share on other sites

  • 1 month later...

 I kept quiet on this suggestion until I saw 3.5

 

I had hoped that 3.5 would be different, but nope.

 

Here is the suggestion: use fairly up to date version of libs.

 

I have noticed a strong trend towards using out of date libs. For example, the Acegi security lib used is three years old. 

 

Use of such old libs makes it difficult on those people who need to modify either code or configuration. For example, I am trying to get the security config to work with Active Directory (yes, I know there are examples here and elsewhere - but every LDAP/AD install/config is different and it is not easy to take someone else's example and apply it to your own instance). I have my own working Spring Security app that talks to AD just fine with v 2.04, but I am struggling with Acegi because it is enough different that what works with Spring doesn't work with Acegi.

 

There are problems with trying to get older libs working - just to name a few:

 

1) Much fewer examples online.

2) The older libs often have bugs that newer libs have fixed.

3) Newer libs are often refactored to be easier to use.

4) It is harder to find support for older versions of libs.

 

As a developer, I understand that for various reasons, the libs used can't always be the latest and greatest, but using libs that are three years old? Come on!

Link to comment
Share on other sites

  • 2 years later...

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...