I am new to JasperReports, I need a few heads up before going forward with my development. My colleagues told me they are able to generate a basic report, but they are stuck with what approach should be used.
I was told we could:
write the queries in each report
run the queries outside the report, and pass it to the report as a
datasource
Which approach is preferable? Does passing the datasource have any performance hits compared to passing the bean? Also would like to know does first approach run in a different jvm?
Current Project Architecture
Struts 2 - Spring 2.5 - Spring JDBC
If you and your team are just starting out with JasperReports I would recommend embedding the SQL query into each report. It makes building the reports in iReport much easier, since you can constantly preview your report with live data while working on it.
As far as performance, I do not think it really is not going to matter in the most basic of examples. If it is just a SQL query then no matter what scenario you use it is going to be using JDBC with the connection you give it. So I would ignore performance for now.
With that said, if you already have the data (i.e you have displayed on a screen and you want to allow the users to then export it to PDF or whatever), you could simply pass it in as a datasource and not take the performance hit of running the query again.
Another scenario you may want to use your own datasource is if you wanted to manipulate the data before it was exported in the report. Maybe some crazy sort that you could not pull off in SQL or something.
As far as your last question, it should all run in the same JVM (at least from my understanding).
Related
So I know the JDBC Rivers plugin is deprecated so even though it is being used I'd ideally not want to look at using something that is no longer supported.
However I have a few tables in a Postgres database with values that I need to be able to search in a Kibana view. Im new to the ELK stack but i've been messing around with some of their samples to get familiar.
I've seen some mentions of using Stored Procedures/Triggers from Postgres to send to Logstash. Although im not sure if this is the best way. Im not a developer but a QA so my coding skills are "ok" as im used to writing automation tests/etc...
What would be the best way to do this? I would want to probably capture updates to these tables (probably new inserts or updates) OR be able to poll the data every X period of time (30s or something). Lets pretend it's for a weather station and the tables contain humidity data from different weather sensors.
I'd want to be able to search in a Kibana view the Values/Station ID/etc...
Is this doable? Is there maybe a better way than using Triggers/Stored procedures?
I ended up using the JDBC driver and following https://www.elastic.co/blog/logstash-jdbc-input-plugin to get it moving and working (Which it does move). But it was a lot of setup for anyone that may see this answer.
I am working on a web application for a client that uses a postgresql database. I want the client to be able to go to a certain area of the site where the data from the database is displayed in graph form (for example, sales figures over a 6 month period). Is there a plugin I could use for this (I don't have any experience of this, so an easy one, or one with tutorials available would be great). I had a look at BIRT, which says it has a web based option but I couldn't really figure it out. I don't want the client to have to download and go through another program, I just want them to go to a url within their site, and it's all just presented to them there and then.
Any sort of pointers in the right direction would be greatly appreciated.
Thank you.
HighCharts, at http://www.highcharts.com/, works well for this case -- I use it fairly often. It supports Ajax data feeds in JSON format, so you can write an endpoint which returns the JSON representing the data from Postgres and which gets called from a JavaScript function which creates the graphs using that data (you would place that call in a ready function).
Also, if you're using Postgres 9.3 or higher, it supports JSON natively, so you can do the JSON conversion in the SQL query itself, as opposed to post-processing the results in your Python or other backend code.
Highcharts is reasonably flexible and allows for a variety of nice-looking, functional charts and graphs. If you want to get much fanicer, d3 may be worth a look. These are some the types of graphs/charts it can do: https://github.com/mbostock/d3/wiki/Gallery
I have not used d3 myself, however.
For the scenario you described above, Highcharts seems like it would work just fine.
It's been a while, and a lot has happened since 2016. There is now ChartJS as well - http://chartjs.org/, for example, which is easier to use than HighCharts and very flexible (I've used both).
What they both don't do is dynamic data. If you want that your client decides which data he wants to watch - that part you need to write yourself.
Working with Crystal Reports over a multiple database environment. In the past reports have been written un-generically (go figure). Trying to clean this mess up while providing new deliverables. Clients do not understand and always pushing for the shortest possible way and do not see the need for cleaning/tuning up existing reports to make them generic for all systems.
Have come across a number of reports built using a specifically written view for each report. The drama comes when cloning a view based crystal report and then trying to run the report via crystal designer on a database different from the original database the report was built on.
The report holds onto the original view object. Runs but delivers no output. At first I thought there were grants issues with the underlying views.
The solution is to update the view reference in the "Set Datasource Location" panel.
Wondering peoples opinions on using views in crystal reports. And if they have hit this situation before.
Obviously views have their uses but I do not see the point of adding another layer between a report and the sql statement(s) by making a specific view for the report when the sql can be plugged straight into the report. Only database procedures make sense to me when you are wanting to do more complex calculations and output.
Notes
The report runs fine from the application menus for the differing
systems (without changing the crystal datasource) SAP B1.
Those reports using views indirectly are NOT affected by this issue.
Pseudo screenshot:
Set Datasource Location (panel)
Current Datasource:
Report
server
properties
initial catalog: other database
view
properties
catalog: original database
From our experience using views for multiple servers/databases (or even tables with N-N relations) is preferred way. If anything changes in database layout or servers configuration, what you prefer - alter one view or multiple related reports?
Of course it can be related to fact that our reports are designed to work on single database. Our application always replaces all included datasource locations (tables, views) to current database, this allows easy reporting on different databases (including MSAccess and MSSQL ones). Such approach excludes cross-database reports, unless using views. Our reporting uses OLEDB interface too, not linked to datasources-connections, opened in application.
There are sometimes problems in designer, when it is opened directly with report file; set datasource location usually corrects them (you may need to set location for specific views too). If opened through our application, which saves report copy with corrected database information, designer works flawless.
And there are sometimes problems with underlying views, which cannot be easily transferred to different database layout. Fortunately view definitions can be altered without changing output layout :)
About customers - they of course do not want to change their working reports. You can be sure that you introduce some errors when replacing their reports with more universal ones - who wants that? No one.
I have a Crystal 2008 report that will be deployed to an InfoView server. There are four different databases the user might want to execute the report against. Each of the four databases have exactly the same schema. Only the data in each is different. Each database corresponds to a plant we have around the world.
Instead of creating four different reports (each one connected to one of the four databases), am I able to dynamically change the server/database the report hits based on a value the user enters into a parameter? I'm really trying to avoid having to create four identical reports except for the database connection on each. If this isn't possible, how do developers typically deal with this sort of scenario? I would imagine it's fairly common.
Thanks very much.
InfoView doesn't support dynamically changing a report's datasource. You certainly could modify InfoView source to suit your needs with the BusinessObjects Enterprise SDK, but that will be a challenge and won't be supported by BO.
Another option is to build a custom portal with the BusinessObjects Enterprise SDK, but this will require quite a bit of coding as well.
Probably the best option is to publish the report multiple times, set each datasource as appropriate (via the CMC), and change the name of the report to give an indication of its datasource (via the CMC). I there is a report property in the CMC that will save the datasource settings so you can quickly republish the reports if you make a change to the original.
I'm not familiar with InfoView, but it is quite common to do what you describe, I've done similar things with Asp.Net and Winforms; if you have access to the Crystal Reports object model, there are extensive options for setting logon info, I think it is SetDatabaseLogon; if you have subreports, you have to set the login for each of those separately.
The schemas do have to be completely identical, or the user will get warnings.
I'm looking at embedding JasperReports into an existing web app for reporting. The webapp sits on top of an existing database which is ancient and complex, and really not suitable for report writers to use to write reports against directly.
What I want to look at is writing some kind of wrapper around our existing data access layer (written to make our life easier talking to aforementioned ancient and complex db). Does anyone have any experience of writing custom data sources for JasperResports, or of doing anything like this?
Updated
I guess I probably wasn't clear in my question - which is probably because my requirements aren't clear either. I want to provide some way that the end-users can use something like iReport to author reports against the database, and then to use JasperReportServer for scheduling/viewing of the reports. However, the database is really, really nasty and was never designed for use in this way. We've got a access layer around it that the webapp uses to talk to it. I want to keep my end users away from the DB altogether, and the idea of a custom data source that used the access layer seemed a good option. However, I've found very little documentation on how to do that. Maybe it's just a whole lot easier than I think it is, and I'm just trying to make a dead simple thing too complicated.
Updated
Thanks for the answers. I don't think my problem has been solved, but I think the answers have helped to inform the requirements phase.
Jasper reports allows you to use a "JavaBean" data source. You can load your data into any Java Bean structure and build the reports against that. Works well.
See the "Custom Data Source" section here.
Every JasperReports template can have two different data sources. One is hooking it directly to a database using some jdbc driver or, in your case, providing a collection of java beans (POJO's), usually list.
JasperReports template is similar to a method definition. It has a name, i.e. compiled JR object and parameters (data source and a list of input parameters of some of the most popular Java types).
My suggestion is to use iReport tool. Open some example that comes with the JasperReports bundle, analyze it and tweak it. It's not so complicated.
UPDATE
Letting customers authoring JasperReports templates, compiling and adding to the classpath means that you'll need to open your system too much. Usually clients provide description of a desired report and developer(s) create the data source and design the template. JasperReports can have parameters. If these parameters are exposed through UI users can change the behavior of reports in the runtime.
If you really need to allow more flexibility then use the API provided by JasperReports for authoring templates. I could imagine some simple DLS for advanced users to communicate with your system creating on-fly reports.