| Gliffy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
The following component diagram lays out the high-level components and how they interact within the Routine Report Service. As it's name implies the functionality of this Service is to provide the capability to store report definitions and retrieve generated Reporting and Analytics.
| Gliffy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
As we can see from the diagram this Service owns the Routine Report definitions, interacts with the Reference Data service to add/remove rights based on those report definitions, and finally retrieve filled in Routine Reports on-demand when given the Routine Report content (i.e. the data to be used in filling the report definition).
Pros/Cons
| Pro | Con |
|---|---|
| Service owns compiled storage and management, centralizing this in the system while allowing the non-compiled definition to be owned by other Services | Report content needs to be given to this service, which being bounded by APIs means that retrieving and aggregating that data will be slow. It'll not be suitable for running most routine reports requiring aggregation.SQL will have to have a direct connection to each Service's private database - this means that Reports will likely break often as this internal database(s) change. |
| Service encapsulates and centralizes the Jasper engineConsumer Services need to specially retrieve and prepare the content for each report | Service's will need to store their data all in one database - i.e. if a Service wanted to use it's own PostgreSQL instance, or a separate database, this Report service couldn't handle the multiple connections or types of databases |
| Report right management (the when and what to add to Reference Data Rights) is centralized here |
Problem
Along with this Service will be an associated Routine Report UI for seeing which reports the logged in user may run, and allow the user to run them at that time (). To preserve this functionality, presumably the UI will want to query only this service for the reports that may be run, and then ask for a specific report to be run. As currently shown, this Service needs the report content (data) to be given to it to generate the PDF/XLS/etc report. The Routine Report UI module will not have this data. The alternatives:
- this Service has access to all Service's content databases. The con, and it's a big one, is that the reports held in this service are tightly coupled directly to every Service's private database.
- somehow, the UI which allows a report to be run actually ends up as a call to a RESTful endpoint in the service from which the report definition comes, so that Java code in that service may prepare the report content (data) to be given to this Service. No clear path is evident for how these complex RESTful calls will be defined or triggered from one Routine Report UI module.
Out-of-scope
...
Out-of-scope
- Currently data-pumps, event-based or otherwise, are considered out of scope. Should alternative 1 to the problem above be considered, then this should be re-evaluated for certain data, with an eye to keeping LOE low. E.g.
Gliffy imageAttachmentId att112742241 baseUrl https://openlmis.atlassian.net/wiki size 300 migration 1 name Simple Data Pump (ETL) diagramAttachmentId att112742237 containerId 112496858 - Jaspersoft Server, which could help us with report filters, scheduling, etc is considered out-of-scope. We should re-visit this when we'd like these additional features / desire to have a less hack-y filtering solution.
Neither of these two options block the other - they're orthogonal and could be pulled in at any future point.
Alternative - Data wrapper
It's worth noting that an alternative was considered which extended work that had been done in the Requisition Service. This approach is mainly the same, however instead of the Service having access to the report content database(s), this service expected the report content to be given to it through the RESTful interface. This has approach has two critical flaws:
- the report content needs to come from somewhere that's external to the Jasper report definition. In practice this would mean that if a new report was defined, that a Java programmer would have to write code in the Requisition service (as an example) that was just for providing the data in a neat form to the Report service, along with the Report definition itself. This is inflexible and works against some of the advantages of encapsulating Reports in a separate service.
- The Report service would ideally come with a UI module which allowed reports to be administered as well as run. The UI module that would allow running a report would be problematic: the user would click a link to run a report, which ideally would just link to this Report service to run the report, however before the report would be run, some sort of call to another Service would likely need to be done to gather the data first (as noted in previous bullet point). A clean workaround to this didn't seem likely.
- Preparing the report content would likely involve numerous API calls between services. For example a Requisition Report would need to pull in facility names and the like from Reference Data. While this API access is clean (as in the databases are separate), for reports which involve aggregation it's predicted to be unacceptable slow.
For these reasons, this approach of passing the report content data to the Service, was deemed undesirable.
| Gliffy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Next Steps
- Josh Zamor and Paweł Nawrocki (Deactivated) to sync on mw-reports
- Josh Zamor to update diagram to go with alternative 1 (SQL over Java Beans)
- Josh Zamor, Paweł Nawrocki (Deactivated), and Jakub Kondrat to sync again after Service is built and reports are available - we'll look again at functionality plus design and pull into product