Jasper Report Server Environment Architecture Question

Hi Jaspersoft Community,

We as a development house are using Jasper Reports within our applications. We are running the reports from within the different applications using the Jasper Java API libraries.

This is working fine and has been for a number of years now, but we want to now look at externalizing our reporting environment to take some of the stress off of our application servers. We hope that the Jasper Report Server is the answer for doing this.

We are in the process of setting up a Jasper Report Server Environment, and after doing some initial research within the Jaspersoft Community we have constructed a design.

The Jasper Report Server installation and setup is fairly easy to understand and implement, but our concerns are with managing the development environment.

Our developers are using the IReport Tool to build the Jasper Report “.jrxml” files and then commit them into our source control repository.

We are using Hudson for continuous integration which poll’s the source control repository for any changes. If a change is detected we want it to take the “*.jrxml” file and upload it to the Jasper Report Server along with any Images / sub-reports.

From what I understand, the only way to do this is via web service calls. I have played around with many scripting languages, Ant, Python, Shell where people show examples of how they have done it to try and accomplish this but I have gotten the best results from doing this myself within Java.

I need to read the “*.jrxml” file and build up the ReportUnit Resource Descriptor, searching for sub-reports / image references and uploading these, searching for parameters and building input controls / data types and uploading these as well.

Needless to say it is all very complicated to do this and we are concerned about this complexity. So my question is if there is an easier way to do this or if this is the correct approach to follow. How do other companies who care about change control and an automated continuous integration system accomplish this? We do not want Developers logging into the Jasper Report Server via IReport and willy-nilly upload / change / delete reports as they see fit. We also do not want to hire a team of full time Jasper Report Administrators whose job it is to move reports from source control into the Jasper Report Server.

We would like to have the maintenance of Jasper Reports, Jasper sub-reports, Images, input controls and data types to be automated and only have the data sources manually created initially and maintained by the application server team. What would the best approach be to get to this stage? Are we using the correct products? Is there a Jaspersoft product that can assist us with this?

I have attached a rough diagram of the initial design of the environment.

Any feedback would be much appreciated.

Thank you




jarrydb's picture
Joined: May 19 2014 - 12:23am
Last seen: 9 years 1 week ago

2 Answers:

There is a rest client project on github that might help for the uploader:


Here's the description:

"With this library you can easily write Java applications which can interact with one or more JasperReports servers simultaneously in a very simple way. Library provides very friendly API for user, it minimizes possibility of building wrong requests." 

elizam's picture
Joined: Mar 5 2012 - 9:19am
Last seen: 3 years 1 month ago

I have tried playing around with the jrs-rest-java-client, from the documentation it looks like it will reduce my code complexity, but it has too many dependencies to be a viable option. I finally managed to get some sort of output from running a test case but ended up with 14 + jar dependencies.

jarrydb - 9 years 4 months ago

Just wondering more about the dependency issue. Is it that there are too many, or it's difficult to make sure you have them all? The project is Maven-based, but I see there aren't any instructions for building from source. Is there anything that would make it easier to get going with this library?

bobtins - 9 years 4 months ago

It would be great if it could be compiled as One Jar, I am sure I can also do this myself with a jar utility that extracts all the dependencies into one artifact, but I am just worried that one day if we were to upgrade our Jasper Server from version X.X to version Y.Y we will be at the mercy of all these libraries and how well they are being kept up to date, where if I were to write the code myself using the java.net libraries, yes its a lot of extra coding and exception handling but we can maintain it ourselves. To be honest I am not sure if this is a good or bad approach to follow.

jarrydb - 9 years 4 months ago

Should be using Studio instead of iReport. Studio is based on Eclipse so there's more of team development plugins.

hozawa's picture
Joined: Apr 24 2010 - 4:31pm
Last seen: 4 years 3 months ago

Agreed, it should be less of a problem with JSS. In addition, eventually, you will need to go to JSS, since iReport will be end-of-lifed. However, it sounds like you have a big investment in iReport and the transition to JSS can be difficult for people not familiar with Eclipse. So it depends partly on your priorities and resources.

elizam - 9 years 4 months ago

I will look into Studio, we might use the migration to Jasper Report Server and join it with the Migration to Studio from iReport if iReport is EOL, however this does not solve the issues we are experiencing with the complexity of source control and automated deployments to the Jasper Report Server by introducing new and improved plugins within the IDE. The source control will still happen within SVN and the automated deployment of the reports still needs to be scripted and added within out CI Engine. :)

jarrydb - 9 years 4 months ago