Configuring a report for a module requires adding the required report configuration as per the standard format and with the minimum development time.
UI can have different types of filters such as date, dropdown etc.. and even the sum of a column can also be easily displayed in UI. Pagination and downloading the report in pdf format, xls format is already present in the report UI.
Type of reports which can be configured :
Count of applications
Statewide collections
Application status
Cancelled receipts
Migrated records / Data entry records
The limitation of this framework is for reports having requirements with complex queries with multiple joins as the report uses the query to fetch the data from the database, It is resource-intensive and response might be slow in those scenarios.
Before you proceed with the configuration, make sure the following pre-requisites are met -
User with permission to edit the git repository to add the report configuration.
User with permission to add action and role action in the MDMS.
Showcase the data in the required and cleaner format.
The UI is rendered with the help of configuration in the report and there is no extra effort in building UI for different reports.
For Implementation specific report requirements, customization is easy and turnaround time is less.
After adding the new report/ editing the existing report configuration in the respective module, the report service needs to be restarted.
Create a reports.yml file and add report configuration as per standard format.
Add the action and role action in the MDMS.
Add the GitHub raw path of the report.yml file in the report.config file.
Through report service, useful data get shown for a specific module based on some given criteria like date, locality, financial year, etc.
For example, PT dump report of property tax service you have to select from date to date, financial year etc and based on the criteria we can see all the data fulfilling the criteria. In the response, we see all the details of a property which is paid between the given from date and to date. In case we select the financial year, the property which is paid for that specific financial year is visible.
Before you proceed with the configuration, make sure the following pre-requisites are met -
User with permission to edit the git repository where Reports are configured and knowledge on YAML.
Prior Knowledge of YAML.
Prior Knowledge of SQL queries.
Prior Knowledge of the relation between the tables for which module you are going to write a report.
Users can write queries (like SQL queries) for fetching real-time data to display in a UI application.
Users can apply filters like from date, to date, financial year, etc based on the report configuration.
Users can download the result in PDF and XLS format.
User can select or deselect the columns user wants to see.
User can choose the number of records he/she wants to see on a page.
Once the changes have been done in the report configuration file we have to restart the report service so the report service will read the new configuration.
<Module Name>=file:///work-dir/configs/reports/config/<report file name>.yml
ex: pgr=file:///work-dir/configs/reports/config/pgr-reports.yml
Create a new file and name the file that you have given in the file reportFileLocationsv1.
Write the report configuration. Once it is done commit those changes.
Add the role and actions for the new report.
Restart the MDMS and report service.
| Title |
|---|
To add a new report first add the file path in the . (In this file, the path of the report configuration files gets stored).
Once the file path is added in the file reportFileLocationsv1, go to the folder .
| Title |
|---|
Rainmaker has a reporting framework to configure new reports. As part of the report configuration, we have to write a native SQL query to get the required data for the report. So if the query takes huge time to execute or the query result has huge data, then it will impact the whole application's performance.
The following cases are where we can see the application performance issue because of heavy reports.
Filtering with long date range data or applying fewer filters which in turn returns huge data.
Join the multiple tables for getting required data and missing creating an index on join columns.
Implementing conditional logic inside the queries itself.
Writing multiple sub-queries inside a single query for getting the required data.
Because of heavy reports, the following are the impacts on the platform -
When we execute a complex query on the database, a thread from the connection pool will block to execute the query.
When threads from the connection pool are blocked completely, the application will become very slow for incoming requests.
When max request timeout is crossed, the API gateway will return a timeout error, But still, the connection thread on the database is active, Then all these types of idle threads will occupy database resources like memory, and CPU which in turns increase the load on the database.
Sometimes when running huge queries, the time taken by the query will lead to a broken pipe issue which causes more memory leaks and out-of-heap memory type issues. Because of this, the service will frequently restart automatically.
If a query returns huge data, the browser will become unresponsive and the application will become unresponsive.