Major issue(s) with reports & deployment of same O_o

Support
,
#1

I’ll apologize in advance for this post being long and rather negative. But… this must be said.

So, we’re getting to a completion level in our conversion of our legacy application from the ancient DataFlex to Jmix (via CUBA, which you guys paid-assisted us with moving from CUBA–>Jmix) where thinking about reports seemed like a good idea.

And unless I’m missing something major, reports in your world are only a design time thing. I can find nothing in the reports documentation (Reports :: Jmix Documentation) that suggests otherwise. This is odd.

I’ve been working on our legacy application (a large, complex business application) for 29 years now, and before that I worked on other large, complex business applications. One thing in common with all of them is that reports are always part of the application; that is they are a development time thing, indivisible from the application - when the app is deployed, the reports go with it.

There are literally hundreds of reports in our application, many of them extremely complex (such as aging reports, balance sheets, etc), such that no user anywhere would be able to design/program them (nor should they have access to tinker with them).

When finished and deployed to our clients, our application will be deployed in a container, one for each client. We have hundreds of clients, so there will be hundreds of containers. Are we meant to go into each one of hundreds of containers, and manually import all hundreds of the reports - and re-do this every time a new report is added, or one is updated!?!?!?!

Or did I miss something major in the documentation, whereby reports can be handled at development-time and deployed with the application? (As it should be…)

#5

Perhaps you mean that reports in Jmix can be created only at runtime.
Right, and this has important advantages:

  • Reports can be created by system administrators and power users without rebuilding the application and restarting the server
  • Short feedback loop when developing report - you can instantly run it and see the results.

I understand that there are cases like yours when reports are created only by the application developers. We have an issue for that: Design-time reports · Issue #667 · jmix-framework/jmix · GitHub, but it’s currently not in our immediate plans, just because of the limited bandwidth.

But inability to define reports in code does not prevent you from automatic deployment of predefined reports. Jmix provides the ReportImportExport API which allows you to import ZIP files with exported reports.

See an example of automatic deployment of reports in the reports-sample project. How it works:

  • Reports are manually exported and saved to the resources directory of the project
  • The ReportImporting bean runs the import on application start.
  • ReportImporting uses the InitFlags entity for storing a flag which is set to true after the first import. The flag is read with pessimistic lock on the database, which prevents concurrent execution if multiple servers in a cluster are starting up simultaneously. Of course you can design other conditions when your reports should be created/updated, or even invoke ReportImportExport by a manual command from the application UI.
  • The ReportImportExport bean does actual import.
#7

Yup, I’m already working on a solution that uses the ReportImportExport and a special directory mapped into the containers via a Docker volume.

I’ll even have a mechanism to track which zips were already imported and such.

If anyone is interested in the final solution, let me know. I’m happy to share.

#8

Hi,

I would be interested in how you solved this, but more, I have a question for you and that is, how do you plan to update all those docker containers when the application itself needs an update? Will you have some sort of CI/CD pipeline for that? How are you distributing the data and changes? (e.g. dropdown values and various related tables)

Regarding the reports, for my use case I decided to go with Jasper. There is Eclipse based Jasper Studio where you design the reports (basically define a SQL query and the page layout and bands and fields), and you can publish them to Jasper Server, which is then apart from cuba/jmix application as it reads the database only. You can have access permissions on various reports, and there are scheduling and emailing options. Design-time only.

Ad-hoc run-time reports are also valid use case and a norm in the corporate world, although they often include the letters “BI” into that. There are various solutions, and they often come or are on top of solutions that are integrating data from various sources and create the ability to query them and make reports. Naturally, an average John Smith would not be able to make a complex report, that’s what analysts do. It also removes the workload from the application developers to make every day some more reports or changes.

Right tool for right job.

Kind regards,
Mladen

#9

That’s an easy one. :wink:

The WAR file is outside the container, in a directory (/var/medflex-wars in our case) in the physical filesystem. It’s mapped into the container via a volume. When that WAR changes… all of the container’s Tomcat processes see it changed and redeploy it automatically. This is built into Tomcat.