I'm working on a project that aims to replace our current PDF generator with JasperReports Server. The plan is to use the REST/HTTP API to reach a high level of abstraction between the systems.
Optimally, we do not want to let JasperReports Server pull the data from the database, since this would bypass the existing logging and authorization in the calling application's architecture. Instead, we'd like to start with extracting the content in the calling application, and then pass that content to JasperReports Server.
We've done quite a bit of investigating, and the lack of relevant results indicates that this is not how you typically use JasperReports Server. The input parameters in the tutorials we've found are typically scalar values (integers, booleans or strings), and not complex structures or objects. Furthermore, it seems like more or less every sample assumes that you want to let JasperReports Server connect to a database.
If it's possible to pass in complex structures (like an array of maps, where some map elements are arrays or maps themselves), what's the best practice for doing this? I have no idea of how such a structure should be formatted in the request body. Is the SOAP API a better fit?
If this is not at all how you should design a JasperReports Server solution, what alternative products/solutions are more suitable?
Thanks in advance for any input.
After several hours spent on research, I think I'm ready to answer my own question.
JasperReports Server ("JRS" below) is fundamentally designed to fetch data by itself. Although it would be possible to force feed JRS with data, I've decided not to.
One of the most obvious drawback of not letting JRS fetch the data itself is that it would no longer be possible to generate reports from the JRS web interface. Integration from other systems also becomes impossible or difficult if the client application is responsible for supplying the data in a predefined format.
In the project I'm working on, we've decided to build a custom JRS DataSource based on the Remote XML DataSource, that invokes the client application's XML API. In other words, the client application requests a report from JRS, and JRS then requests it's data from the client application. The XML API will have to be expanded to cover all of our reporting needs, but that's a good thing in my opinion. Good API coverage will come in handy in the future.
I hope these thoughts helps someone having similar questions.
As you wrote, fetching data is more natural way for JRS. However, I needed to go the opposite way - I POST data to report sitting in JRS repo via a REST call.
I pass XML data in my parameter "xmlDocument" and, by means of a "trick", an executed report can use this XML for further X-path queries.
xmlDocument is just a simple String:
<parameter name="xmlDocument" class="java.lang.String">
<defaultValueExpression><![CDATA["<?xml version=\"1.0\" encoding=\"UTF-8\"?><documentData></documentData>"]]></defaultValueExpression>
</parameter>
At designing phase I create XML data adapter with XML file that I use for previewing. Note that a new parameter XML_INPUT_STREAM appeared after choosing XML adapter.
Then I publish the report to JRS.
During report execution, when the report is not linked to any data source, it reads XML_INPUT_STREAM parameter instead (as fallback data source), that looks as follows:
<parameter name="XML_INPUT_STREAM" class="java.io.InputStream" isForPrompting="false">
<defaultValueExpression><![CDATA[new java.io.ByteArrayInputStream($P{xmlDocument}.getBytes("UTF-8"))]]></defaultValueExpression>
</parameter>
I wrap "xmlDocument" string to InputStream.