Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The application overview page shows the details of the application selected and the action that a specific user is allowed to take on that application.
Documents required for NOC approval are gathered from DocumentTypeMapping MDMS.
Common documents that are required are fetched from DocumentType config from MDMS.
Forward application with the uploaded NOC certificate to forward the application to concerned authorities for approval.
Reject application to reject the application.
For multiple uploading of documents, we have used MultiUploadWrapper which encapsulates API calls and abstracts the whole process providing the fileData and fileStoreIds.
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
We are using re-indexing to get all the data to the respective indexer. We have 2 steps for this. First is to run the connector from the playground, which is followed by legacyindexer service call from the indexer service, which internally calls the respective plain search service to get the data and to send it to the respective indexer.
Access to kubectl of the environment targetted
Postman scripts
Plain search APIs in the respective services
fire noc-services reindexing steps
Configure the fire noc indexer with the configKey as LEGACYINDEX with the new topic name in the respective indexer yaml file
Connect to playground pod.
Delete the kafka connector if already exists with the kafka connection, using below command through playground pod.
Run below kafka connector curl from playground pod:
port forward to egov-indexer pod and run below curl throw postman.
Delete the kafka connection after all the data has been re-indexed by following below command through playground pod.
Alias firenoc-services-enriched as water-services through kibana server.
NOW your firenoc-services index is update with the data of firenoc till now in the system.
Service configuration
The main objective of the Fire-NOC module is to provide a No Objection Certificate indicating that the building is designed as per fire safety norms and regulations.
Before you proceed with the documentation, make sure the following pre-requisites are met -
Prior knowledge of JavaScript.
Prior knowledge of Node.js platform.
Kafka server is up and running
JSONPath for filtering required data from json objects.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
egov-persister service is running and has firenoc-services persister config path added in it
PSQL server is running and database is created
Prior knowledge of eGov-mdms service, eGov-persister, eGov-user, eGov-location, eGov-localization, eGov-idgen
Used for No Objection Certificate generations indicating that the building is designed as per fire safety norms and regulations.
Generate application number and fire noc number
Support workflow
Provide notification on various status changes for an application
Add mdms configs required for firenoc service and restart mdms service.
Deploy the latest version of firenoc-services service.
Add firenoc-services persister yaml path in persister configuration and restart persister service.
Add Role-Action mapping for APIs.
Create businessService (workflow configuration) according to firenoc registration.
Following are the properties in application.properties file in trade firenoc-service which are configurable.
MDMS Configuration
Firenoc service makes calls to egov-mdms-service to fetch required masters. These are significant in the validation of the application.
Create businessService (workflow configuration) using the __/businessservice/_create. Following is the product configuration for firenoc service
Persister Config
https://github.com/egovernments/configs/blob/DEV/egov-persister/firenoc_persiter.yaml
Id Gen Config
BasePath /firenoc-services/v1/[API endpoint]
Method
a) _create
Create API call is called with INITIATED action to create a new application. In this API call, we validate the request body(using ajv module for contract-specific validation and explicit checking for user-related validation checks), enrich audit details, generate application no using idgen, persist data using persister and return response.
Allowed user roles: NOC_CEMP, CITIZEN
b) _update
Once the application is created it can be updated by citizens or employees while taking action on the application
Allowed user roles: NOC_CEMP, CITIZEN, NOC_DOC_VERIFIER, NOC_FIELD_INSPECTOR, NOC_APPROVER
c) _search
The search API call is used to search for applications. If a search call is being made by CITIZEN then only his application would be fetched by applying other search filters. For employee search based on search filter will return data.
Allowed user roles: NOC_CEMP, CITIZEN, NOC_DOC_VERIFIER, NOC_FIELD_INSPECTOR, NOC_APPROVER, EMPLOYEE
The Fire-Noc service is used to provide a No Objection Certificate indicating that the building is designed as per fire safety norms and regulations.
Provide backend support for the No Objection Certificate registration process for a different building.
SMS notifications on application status changes.
Supports workflow which is configurable
To integrate, the host of firenoc-services service should be overwritten in the helm chart.
firenoc-services/v1/_create should be added as the create endpoint for creating the fire noc application in the system.
firenoc-services/v1/_search should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria.
firenoc-services/v1/_update should be added as the update endpoint. This method is used to update fields in existing records or to update the status of the application based on workflow.
(Note: All the API’s are in the same postman collection therefore same link is added in each row)
__
__
Fire-Noc calculator service is used to calculate the fire noc charges for the building based on the billing slab defined in the system. This service allows an employee with SUPERUSER role to create the billing slab with different combination of the height of the building, built_-_up area, plot size, number of floors etc.
Before you proceed with the configuration, make sure the following pre-requisites are met -
Prior knowledge of JavaScript.
Prior knowledge of Node.js platform.
Kafka server is up and running
egov-persister service is running and has firenoc-calculator-persister config path added in it
PSQL server is running and database is created to store firenoc application data
Following services should be up and running:
egov-persister
egov-mdms
firenoc-services
billing-service
An employee with SUPERUSER role can create, update billing slab(s)
ULB Employee with NOC_CEMP, NOC_DOC_VERIFIER, NOC_FIELD_INSPECTOR, NOC_APPROVER, EMPLOYEE can search billing slab(s)
firenoc-services internally call firenoc-calculator to generate demand.
Deploy the latest version of firenoc-services and firenoc-calculator.
Add firenoc-calculator-persister.yml file in config folder in git and add that path in persister . (The file path is to be added in environment yaml file in param called persist-yml-path )
Firenoc Calculator makes calls to egov-mdms-service to fetch required master files. These are significant in validations of application.
firenoc-calculator will be integrated with firenoc-services. firenoc-services internally invoke the firenoc-calculator service to calculate and generate demand for the charges.
Firenoc calculator application is used to calculate the fire noc charges for the building based on the different billing slabs in the DB that's why the calculation and demand generation logic will be separate out from firenoc services. So in future, if calculation logic needs to modify then changes can be carried out for each implementation without modifying the Firenoc services.
Firenoc application to call /firenoc-calculator/v1/_calculate to calculate and generate the demand for the Firenoc application
/firenoc-calculator/v1/_getbill this API updates demand with time based penalty if applicable and generates bill for the given criteria.
ULB Employee can create billing slab calling /firenoc-calculator/billingslab/_create
ULB Employee can update billing slab calling /firenoc-calculator/billingslab/_update
ULB Employee can search billing slab calling /firenoc-calculator/billingslab/_search
(Note: All the API’s are in the same postman collection therefore same link is added in each row)
__
__
Technical Doc
DSS has two sides to it. One is the process in which the data is pooled into ElasticSearch and the other is the way it is fetched, aggregated, computed, transformed and sent across.
As this revolves around a variety of data sets, there is a need for making this configurable. So that, tomorrow, given a new scenario is introduced, then it is just a configuration away from getting the newly introduced scenario involved in this flow of the process.
This document explains the steps on how to define the configurations for the analytics side Of DSS for FireNoc.
What is analytics?
Analytics: Micro Service which is responsible for building, fetching, aggregating and computing the Data on ElasticSearch to a consumable Data Response. Which shall be later used for visualizations and graphical representations.
Analytics Configurations: Analytics contains multiple configurations. we need to add the changes related to firenoc in this dashboard-analytics. File location : Below is a list of configurations that need to be changed to run firenoc successfully.
Chart API Configuration
Master Dashboard Configuration
Role Dashboard Mappings Configuration
Each visualization has its own properties. Each visualization comes from different data sources (Sometimes it is a combination of different data sources)
In order to configure each visualization and its properties, we have a Chart API Configuration document.
In this, visualization code, which happens to be the key, has its properties configured as a part of the configuration and are easily changeable.
Here is the sample ChartApiConfiguration.json data for the FireNoc.
Master Dashboard Configuration is the main configuration which defines the dashboards to be painted on the screen.
It includes all the visualizations, their groups, the charts which come within them and even their dimensions as what should be their height and width.
Master Dashboard Configuration which was explained earlier holds the list of dashboards which are available.
Given the instance where Role Action Mapping is not maintained in the Application Service, this configuration will act as Role - Dashboard Mapping Configuration
In this, each Role is mapped against the Dashboard which they are authorized to see
This was used earlier when the Role Action Mapping of eGov was not integrated.
Later, when the Role Action Mapping started controlling the Dashboards to be seen on the client side, this configuration was just used to enable the Dashboards for viewing.
MDMS Configuration to be added:common-masters/uiCommonConstants.json
roleaction.json
Action test.json:
FireNoc-State DSS Consists of multiple graphs which represent the data of FireNoc. Each graph has its own configuration which will describe the chart and its type.
State DSS consists of following charts in FireNoc:
FireNoc Page
Overview
Total Cumulative Collection
Total applications vs Provisional NOCs issued vs Actual NOCs issued
Collection by Payment Mode
Total NOCs issued by type
Actual Fire NOCs by usage type
Top 3 Performing States
Bottom 3 Performing States
Service Report
Overview
The overview graph contains multiple data information as below in the selected time period.
Today’s Collection: This represents the sum of revenue collected from the issuance of a Provisional and Actual Fire NOC which is Application fee + NOC Issuance fee.
Total Collection: Sum of revenue collected from Fire NOC for the applied date filter.
Total Applications: Total number of applications submitted for a new FireNOC.
Provisional NOCs Issued: The Provisional NOC is to be obtained to ensure that the proposed constructions meet the fire safety-compliant norms.
Actual NOCs Issued: The Actual NOC is to be obtained to ensure that the proposed constructions meet the fire safety compliant norms.
Avg. days to issue Provisional Fire NOC: Average number of days taken to issue a Provisional NOC.
Avg. days to issue Actual Fire NOC: Average number of days taken to issue an Actual NOC.
SLA Compliance (Actual FIre NOC): % of Actual NOCs issued within SLA.
SLA Compliance (Provisional FIre NOC): % of Provisional NOCs issued within SLA.
Total Cumulative Collection
This Graph contains the Fire NOC collection amount information on a monthly basis as a cumulative line graph for each Fire NOC collection separately. This will change as per the denomination amount filter selection.
line - this graph/chart is data representation on date histograms or date groupings.
Total applications vs Provisional NOCs issued vs Actual NOCs issued
This Graph contains the Fire NOC showing total applications submitted vs provisional NOCs issued vs actual NOCs issued for a given month collection separately. This will change as per the denomination amount filter selection.
line - this graph/chart is data representation on date histograms or date groupings.
Collection by Payment Mode: This will be a pie chart showing the bifurcation of total collections by payment mode (online, cash, card, cheque) which is the sum of revenue collected from Fire NOC for the applied date filter.
Total NOCs issued by type: This will be a pie chart showing the bifurcation of Total NOCs issued into Provisional and Actual Fire NOCs. Sum of Provisional and Actual Fire NOCs issued.
Actual Fire NOCs by usage type: This will be a pie chart showing a bifurcation of Actual Fire NOCs by usage type. The total number of Fire NOCs issued by the concerned authority.
Top 3 Performing States: This card will show the Top 3 Performing States/ULBs/Wards based on % NOCs issued. The number of Fire NOCs issued / Number of applications depends on whether a user selects 'Provisional' or 'Actual'.
On click of Actual it shows the % of NOCs issued for Actual FireNocs.
On click of Provisional it shows the % of NOCs issued for Actual FireNocs.
On click of Show More, it shows the information of all the states.
Bottom 3 Performing States: This card will show the Bottom 3 Performing States/ULBs/Wards based on % NOCs issued. The number of Fire NOCs issued / Number of applications depends on whether a user selects 'Provisional' or 'Actual'.
On click of Actual it shows the % of NOCs issued for Actual FireNocs.
On click of Provisional it shows the % of NOCs issued for Actual FireNocs.
On click of Show More, it shows the information of all the states.
Service Report: This tabular chart representation graph shows multiple Fire NOC information like Total Collection, Applications Submitted, Provisional FireNoc issued, New FireNOC Issued, Average days to issue Provisional NOC, SLA Compliance (Provisional NOC), Average days to issue New NOC, SLA Compliance (New NOC). And this table shows the data at the state level and also has the drill-down chart for each state to ULB and from ULB to ward level data for the same.
xtable type allows the addition of multiple computed fields with the aggregated fields dynamically added.
To add multiple computed columns, computedFields [] where actionName (IComputedField<T> interface), fields [] names as in exist in query key, newField as name to appear for computation must be defined.
Clicking on any region name provides a drill down to the specific state data.
Clicking on the ULB navigates to the wards under that specific ULB and each ward shows the specific data for that ward.
isRoundOff: This property is introduced to round off the decimal values. Ex: if the value is 25.43 by using isRoundOff property in the configuration we will get it as 25. if the value is 22.56 round of value will be 23. This can be used for insights configuration as well for overview graphs.
Key(eg: fsmTotalrequest): This is the Visualization Code. This key will be referred to in further visualization configurations.
This is the key which will be used by the client application to indicate which visualization is needed for display.
chartName: The name of the Chart which has to be used as a label on the Dashboard. The name of the Chart will be a detailed name.
In this configuration, the Name of the Chart will be the code of Localization which will be used by the Client Side.
queries: Some visualizations are derived from a specific data source. While some others are derived from different data sources and are combined together to get a meaningful representation.
The queries of aggregation which are to be used to fetch the right data in the right aggregated format are configured here.
queries.module: The module/domain level, on which the query should be applied on. Fire NOC is FIRENOC.
queries.indexName: The name of the index upon which the query has to be executed is configured here.
queries.aggrQuery: The aggregation query in itself is added here. Based on the Module and the Index name specified, this query is attached to the filter part of the complete search request and then executed against that index
queries.requestQueryMap: Client Request would carry certain fields which are to be filtered. The parameters specified in the Client Request are different from the parameters in each of these indexed documents.
In order to map the parameters of the request to the parameters of the ElasticSearch Document, this mapping is maintained.
queries.dateRefField: Each of these modules have separate indexes. And all of them have their own date fields.
When there is a date filter applied against these visualizations, each of them has to apply it against their own date reference fields.
In order to maintain what is the date field in which index, we have this configured in this configuration parameter.
chartType: As there are different types of visualizations, this field defines what is the type of chart/visualization that this data should be used to represent.
metric - this represents the aggregated amount/value for records filtered by the aggregate query
pie - this represents the aggregated data on grouping. This is can be used to represent any line graph, bar graph, pie chart or donuts
line - this graph/chart is data representation on date histograms or date groupings
perform - this chart represents groping data performance-wise.
table - represents a form of plots and values with headers as grouped on and a list of its key, values pairs.
xtable - represents an advanced feature of the table, it has addition capabilities for dynamic adding header values.
valueType : Instance of data, the values which are sent for plotting, might be a percentage, sometimes an amount and sometimes it is just a count.
In order to represent them and differentiate the numbers from the amount from the percentage, this field is used to indicate the type of value that this Visualization will be sending.
action: Some of the visualizations are not just aggregations of data sources. There might be some cases where we have to do a post-aggregation computation.
For Example, in the case of the Top 3 Performing ULBs, the Target and Total Collection are obtained and then the percentage is calculated. In these kinds of cases, the action that has to be performed on the data obtained is defined in this parameter.
documentType: The type of document upon which the query has to be executed is defined here.
drillChart: If there is a drill down on the visualization, then the code of the Drill Down Visualization is added here. This will be used by Client Service to manage drill-downs.
aggregationPaths: All the queries will be having Aggregation names in them. In order to fetch the value out of each Aggregation Response, the name of the aggregation in the query will be an easy bet. These aggregation paths will have the names of Aggregation in them.
insights: It is to show the data with the comparison of last year with arrow symbols, it will show the data in how much % is increased or decreased.
_comment: In order to display information on the “i” symbol of each visualization, Visualization Information is maintained in this field.
The index that contains data for State-FireNoc is- firenoc-services
The mapping for this index is:
(Note: All the APIs are in the same postman collection therefore the same link is added in each row)
Users can view all the applications assigned to them in the employee inbox. And it provides multiple filters and search options to filter the applications.
NOC Inbox uses InboxComposer React HOC to create the Inbox through various child components, for both mobile and desktop components.
The API used to fetch applications in the inbox
NOCAccess function to view NOC Inbox
Config for risk type definition
All content on this page by is licensed under a .
| Property | Value | Remarks |
|---|---|---|
| Fire-NOC masters | Description |
|---|---|
__All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by is licensed under a .
Use the MDMS (available as blue hyperlinks) for selecting OBPS , , risk type with business service and status filter.
All content on this page by is licensed under a .
EGOV_APPLICATION_FORMATE
PB-FN-[cy:yyyy-MM-dd]-[SEQ_EG_TL_APL]
The format of the firenoc application number
EGOV_CIRTIFICATE_FORMATE
PB-FN-[cy:yyyy-MM-dd]-[SEQ_EG_PT_LN]
The format of the firenoc certificate number
EGOV_DEFAULT_STATE_ID
pb
Variable store the default value of state tenantid
EGOV_FN_DEFAULT_LIMIT
100
Max number of records to be returned
KAFKA_TOPICS_FIRENOC_CREATE
save-fn-firenoc
The name of kafka topic on which create request is published
KAFKA_TOPICS_FIRENOC_UPDATE
update-fn-firenoc
The name of kafka topic on which update request is published
KAFKA_TOPICS_FIRENOC_WORKFLOW
update-fn-workflow
The name of kafka topic on which status update request is published
ACTION_PAY
PAY
This is workflow action for making payment against the application
SENDBACK
SENDBACK
This is workflow action for sending application to the previous state of the workflow.
SENDBACKTOCITIZEN
SENDBACKTOCITIZEN
This is a workflow action for sending application to the citizen for correction.
This master contains the list of application type.
This master contains the details about which unit of measurement is use for a particular building type.
This master contains the list of firestation present in city.
This master contains the list of property type.
This master contains the list of minimum charges of each application type.
Title
Link
API Swagger Documentation
Firer Noc Calculator Service
Title
Link
firenoc-services/v1/_create
firenoc-services/v1/_search
firenoc-services/v1/_update
Link |
firenoc-services/v1/_create |
firenoc-services/v1/_search |
firenoc-services/v1/_update |
Fire-NOC masters | Description |
This master file contains the details about which unit of measurement is use for a particular building type. |
This master file contains state level constants and their values. |
This master file contains list of unit of measurements for firenoc |
This master file contains the list of state level constants and their values.. |
Title | Link |
API Swagger Contract |
Fire Noc Service Document |
Title | Link |
firenoc-calculator/billingslab/_create |
firenoc-calculator/billingslab/_search |
firenoc-calculator/billingslab/_update |
firenoc-calculator/v1/_calculate |
firenoc-calculator/v1/_getbill |
