Jaspersoft Report Writing Best Practices

The following is a set of guidelines for developing reports with iReport and JasperReports Server. It was compiled with the help of Frau Klein

Best Practice - report resources:

Report units contain references to the resources they use: images, styles, sub-reports, queries, input controls - example

Why?

Promotes re-usability (nothing is local to report unit). Easy maintenance around moving report units, replacing resources in a mass scale. 

 Best Practice - references:

 Never hard code an entire repository path to resource, the image repo:/reports/images/image.png should come in as a reference like repo:image.png - example

Why?

When you use js-export with --uris option it only resolves repository dependencies, it doesn't look for expressions that maybe use an absolute repository path

 Best Practice - styles:

Do not hard code any style information to JRXML. Develop central style templates (jrtx, jrctx) for all your reports, add as a reference to reports - example

Why?

Fast change management, when the company style changes you will edit a couple of resources vs hundreds. Note that conditional styles are not in the jrtx

Best Practice - logged in user 

 Don't log in as superuser, use an organization specific user like jasperadmin - example

Why?

 Complicates repo: paths. If logged in as superuser you must pass in the full uri ex: repo:/organizations/organization_1/reports/drill_down_report where being part of an organization you would just use repo:/reports/drill_down_report. Also, it's good for testing around multi-tenancy to be a "real" user.

Best Practice - input controls

Create shared input controls if they apply to more than one report, bring them in as a link - example

Why?

Reduce development time, useful for dashboards. Note: Datasources won't switch if your sub-report switches

Best Practice - Use JNDI Datasources (contributed by Guillaume AUTIER)

Have a unique entry point to change datasource details (ip:port:credentials)
Why ?
When deploying the server in a different location, you would only have to change the datasource definition in one file: context.xml (this is valid in tomcat, see your app server settings for JNDI)

When using export scripts the datasource will remain untouched, so you can use the same export on multiple servers without having to change the datasource detail after the import

You can take advantage of Application Server pooling instead of creating many connections to the database (performance).

Best Practice – parametrized references with sub-reports (contributed by Guillaume AUTIER)

Using the previous advice you can also access a report (with subreports) both locally and on the server without touching your expressions.
Why?
This is useful when you want to quickly preview in iReport a report taken from the server. We assume that all reports and subreports .jasper files resides in the same local folder.

• Create a parameter $P{SUB_REPORTDIR} (string type, use as prompt, default value “repo:”)
• Then have the following formula in your subreport expressions

$P{SUB_REPORTDIR }.equals(“”)?”mySubReport.jasper”: $P{ SUB_REPORTDIR} + ”mySubReport.jrxml”

• Publish your report on the server as usual : do not create(or link) an input control for the SUB_REPORTDIR parameter

Run your report :

• In iReport you will be prompted for the SUB_REPORTDIR parameter leave it blank.
• On the server : Without an input control for the SUB_REPORTDIR parameter the server will then take the default.

If you have any other best practices tips, post them in the comments and I'll include into the post, happy reporting!