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.
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. |
| Service encapsulates and centralizes the Jasper engine | Consumer Services need to specially retrieve and prepare the content for each report |
| 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
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.
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