Alternative to Jasper Reports? AsciiDoc?

[Phil Beauvoir]

Let's face it, modifying or creating Jasper Reports is not easy. In fact it can be a nightmare.

I would like to be able to create report templates using a human readable markup such as AsciiDoc (https://asciidoctor.org/docs/what-is-asciidoc/) that could access an Archi model from a data source (maybe Java, maybe XML, not sure) and insert data elements into the markup and then generate HTML, PDF or other formats. AsciiDoc is a good contender but I don't know if it can update fields from an external data source. Or maybe via some XSLT transformations or similar. The goal would be:

1. The template must be easy to read and edit and maintain.
2. Data source should be not to hard to either access or customise

Just a thought.

[Hervé]

Hi Phil,

Few years ago, I was thinking about creating a plugin to export a model to a wiki where we were storing our architecture documents (creating pages if they do not exist or updating them if they do). I did not create that plugin because in my company, we're using several wiki solutions, each having different languages and I couldn't create one plugin per wiki brand.

So I've been looking to export the model in markdown or asciidoc and then use external converters, but then, I never found time to start this plugin.

Personally, I'd be very interested by your asciidoc export 

[Phil Beauvoir]

Hi Hervé,

thanks for your interest.

I like the idea of using something like AsciiDoc markup to create a template but I'm not sure at this stage if it, or something else, supports fields that take data objects from a data source. Or maybe, this could be written as part of a plug-in that could could parse custom fields and replace them with model data before generating the PDF, HTML, etc.

[Jean-Baptiste Sarrodie]

Hi,

I don't think asciidoc or markdown would do it. They are not meant for the same purpose (reporting).

Jasper is really a good library for that. Of course it is a bit complicated, but I'm not aware of anything similar in goal and easier to use (I've worked with proprietary solutions like Cognos and Business Object and they are worse).

I think the main difficulty is related to the use of a Java datasource instead of a SQL DB one. This is not flexible enough for users as several needs require changing the code. I think we could make it simpler by changing the way the plugin work: it could first generate a sqlite db in a temporary folder together with the export all views, and then we would create the report. This report would then use SQL queries instead of java code. Of course I would suggest to generate the same datamodel than the one we have included in the embedded DB of HTML report (this would allow people to easily test their queries before creating a report).

BTW, one can easily export the query result (inside HTML report) into a CSV, making it easy to then create a report on excel (but that's not a single button option).

jArchi is another option I'm looking at. There is several web-oriented report library that might be easier to use.

Regards,

JB

[Phil Beauvoir]

I agree that AsciiDoc is not the right thing, but I think a major pain point with Jasper is editing those .jrxml files.

[JanC]

Interesting viewpoints that I largely agree with. Working with .jrxml files is indeed quite painful. The "Customizable Report" though already allows for quite some flexibility providing localization, using tags and the various hide options. So the real pain is understanding what goes on in these .jrmxl file if you want a different look & feel. That is complicated by the fact that you cannot make annotations so that other people can understand the choices and design decisions made. 

I have started to work on adding some more flexibility (e.g. specifying which layers one wants to get detailed under each view) - and that brings back the complexibility to setting the 'right' properties. Reflecting on this ... that choice never can be part of a template. This is where the architect has to make the decision of what is the intended audience of the report, what is the message he wants to convey.

If the problem is really in the layout (and not in the options of what we can show or hide), than the question remains to "how 'nice' can we make a Jasper template?". And honestly ... any fancy markup template requires some deep understanding of both the model and the layout options and consequences using a specific layout for some model element in relation to the other model elements. In my experience (working for example with Microsoft's Reporting Server) that always requires some good thought. Even moving from portrait to landscape (for example to adapt better to the typical Powerpoint layout) requires some good thought.

The Jaspersoft Studio does help quite a lot when working with these templates ... if invoked as a standalone application. The built in datasource support is more or less limited to JDBC or XML datasources. I have not found a way to get hold of the Archi datasource in the Jasperstudio Preview environment. That kinds of hints to use an intermediate format, but my experience is too limited in really judging this.

[Phil Beauvoir]

> That kinds of hints to use an intermediate format, but my experience is too limited in really judging this.

Yes. even if we have a different data source (sql) those jrxml files are really hard to edit.

[JanC]

Thus we should go back to the requirements - why does someone want to modify het .jrxml files? What kind of changes are wanted?

From my point of view - my main desire was some more granularity on the content (which I have largely able to achieve) in still a professional presenation (which Jasper PDF reports bring to the table). The one feature missing is the Table of Contents (for which I have started to work with Jasper 'parts' kind of knowing that there is light at the end of the tunnel).

Both kind of changes have not been trivial in the understanding of Jasper - fully agreed. Is there a generic report generating environment that is easier? Or would I loose al the built in 'professionality' already present in Jasper?

[Phil Beauvoir]

> Is there a generic report generating environment that is easier?

I looked at BIRT once (https://www.eclipse.org/birt/) it seemed massively heavyweight.

My ideal scenario would be:

- An accessible DataSource from the Archi model
- Easily editable template/pre-processor files
- Intermediate output format like AsciiDoc
- Post process into PDF, HTML etc

[Jean-Baptiste Sarrodie]

Hi,

If we want something simple, then we have to leave the world of Jasper, Birt and similar framework. IMHO, the perfect solution would be one that uses MsWord itself (or compatible wordprocessor) to create a template, and a template engine that takes it and merge it with model content. This is the kind of things that docxtemplater does (but it is limited in the opensource version). This is also what modelio is using. The biggest advantage is that user already know how to use MsWord, so only a (small) templating language is to be learnt.

But a possible drawback is that it will become impossible to create matrices and graphics (Jasper does).

Regards,

JB

[rchevallier]

Matrices and graphics are IMHO a MUST HAVE

[geoffrey]

Just want to share some experimantion I have doing lately outside of Archi in search of documenting an architecture without a model and modelling tool. As a kind of lightweight back on a napkin way of describing an architecture.

I've written an application architecture document using the ARC42 template, entirely in Markdown using Microsoft Visual Studio Code in combination with the Markdown Preview Enhanced plugin. The latter one supports different diagramming libraries such as PlantUML which makes it possible to add class diagrams, sequence diagrams etc all using text.

The ARC42 diagrams for Context & Scope and the different Building Block Levels were based on the C4 Model, for which there also exist a set of macros to do it using PlantUML. Last but not least, I created some ArchiMate views using PlantUML as well to give some context in the appication architecture description.

For the ArchiMate views I did not use the default PlantUML macros but a set of open source ones found on Github.

The advantage of using a text based syntax for making views that it is very fast and easliy adjustable during a workshop. Using the Markdown Preview Enhanced plugin, I'm able to export the Markdown document to Microsoft Word, PDF, wikitext and other formats.

I also included some Architectural Decision Records in the document using the Markdown syntax proposed by MADR.

Everything is stored in plain text files, which for some is an advantage because you can add it to a version control system close to the source code, and for others a huge drawback because it is not really a model.

In below you find some links to the tools used:

https://code.visualstudio.com/
https://arc42.org/
https://c4model.com/
https://shd101wyy.github.io/markdown-preview-enhanced/#/diagrams
https://github.com/RicardoNiepel/C4-PlantUML
https://github.com/ebbypeter/Archimate-PlantUML
https://github.com/adr/madr

In the future I'll still use some of these techniques to quickly make some visualisations, because I can explain something building block per building block using a readable text notation.

[Phil Beauvoir]

Thanks for sharing, Geoffrey!