Objective

OBPS search application is used to search all the applications independent from the workflow/process instance data, which eliminates the presence of valid roles to search for an application from any business service.

Make use of the already documented applicationType and serviceType MDMS. Create a couple of hooks to coordinate and easily use the available filters.

Objective

To provide the facility for the employee users to update the BPA application state.

Localization

The localization module used across the OBPS module was rainmaker-bpa and rainmaker-common, out of which we initialized rainmaker-bpa with module initialization.

Application Details

The application details page is used to display the details of the application and also showcase all the actions that can be taken on the application.

The various step for the application:

Document Verification

In this step, the user can upload multiple documents and/or approve the already uploaded documents.

NOC Verification

The user approves the uploaded NOC documents.

Inspection Report

The user fills in the inspection details (date, time, question, remarks) and submits.

Permit Condition

Here the user approves the required permit conditions and can also add new conditions.

UI Implementation

All the screens are developed using the new-UI structure followed previously in FSM, PGR, PT, and TL. Certain new components have been introduced such as Multi-Document Upload, Approval Checks, etc.

MDMS Data

Throughout the flow, some data is imported from the MDMS. Following are the list of MDMS data:

1. CheckList

2. RiskTypeComputation

Below is the MDMS config used to fetch MDMS data:

curl 'https://qa.digit.org/egov-mdms-service/v1/_search?tenantId=pb' \
  -H 'authority: qa.digit.org' \
  -H 'sec-ch-ua: "Chromium";v="94", "Google Chrome";v="94", ";Not A Brand";v="99"' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'content-type: application/json;charset=UTF-8' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36' \
  -H 'sec-ch-ua-platform: "Linux"' \
  -H 'origin: https://qa.digit.org' \
  -H 'sec-fetch-site: same-origin' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-dest: empty' \
  -H 'referer: https://qa.digit.org/digit-ui/employee/obps/bpa/PB-BP-2021-10-19-002931' \
  -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
  -H 'cookie: amplitude_id_fef1e872c952688acd962d30aa545b9edigit.org=eyJkZXZpY2VJZCI6IjYxMDYxMWFjLTY5MjMtNDQ1Yi04ZWZlLTUxNGVkMmE5MzRjOFIiLCJ1c2VySWQiOm51bGwsIm9wdE91dCI6ZmFsc2UsInNlc3Npb25JZCI6MTYzMzA4NTYwNzE5MiwibGFzdEV2ZW50VGltZSI6MTYzMzA4NTYwNzk2OCwiZXZlbnRJZCI6MSwiaWRlbnRpZnlJZCI6MSwic2VxdWVuY2VOdW1iZXIiOjJ9; _ga=GA1.2.1811666557.1633085608' \
  --data-raw '{"MdmsCriteria":{"tenantId":"pb","moduleDetails":[{"moduleName":"BPA","masterDetails":[{"name":"RiskTypeComputation"}]}]},"RequestInfo":{"apiId":"Rainmaker"}}' \
  --compressed

Users can view all the applications assigned to them in the stakeholder inbox. And it provides multiple filters and search options to filter the applications.

Stakeholder Inbox uses InboxComposer React HOC to create the Inbox through various child components, for both mobile and Desktop Components.

Inbox wrapper API used to fetch the inbox data :-

curl 'https://qa.digit.org/inbox/v1/_search?_=1638883408487' \
  -H 'Connection: keep-alive' \
  -H 'sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"' \
  -H 'Accept: application/json, text/plain, */*' \
  -H 'DNT: 1' \
  -H 'Content-Type: application/json;charset=UTF-8' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Safari/537.36' \
  -H 'sec-ch-ua-platform: "Windows"' \
  -H 'Origin: https://qa.digit.org' \
  -H 'Sec-Fetch-Site: same-origin' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Referer: https://qa.digit.org/digit-ui/employee/obps/stakeholder-inbox' \
  -H 'Accept-Language: en-US,en;q=0.9,hi;q=0.8' \
  --data-raw '{"inbox":{"tenantId":"pb","processSearchCriteria":{"moduleName":"BPAREG","businessService":["ARCHITECT","BUILDER","ENGINEER","STRUCTURALENGINEER"]},"moduleSearchCriteria":{"assignee":"ASSIGNED_TO_ALL","sortOrder":"DESC"},"limit":10,"offset":0},"RequestInfo":{"apiId":"Rainmaker","authToken":"ee9dc3b7-b0c1-4f02-b751-44b921beb937","userInfo":{"id":12588,"uuid":"a56bae11-e18b-4dd3-b70f-b29f2abb1edf","userName":"EMP-BPA","name":"SR DV FI","mobileNumber":"9999999445","emailId":null,"locale":null,"type":"EMPLOYEE","roles":[{"name":"BPAREG doc verifier","code":"BPAREG_DOC_VERIFIER","tenantId":"pb"},{"name":"Employee","code":"EMPLOYEE","tenantId":"pb.amritsar"},{"name":"BPAREG Employee","code":"BPAREG_EMPLOYEE","tenantId":"pb.amritsar"},{"name":"BPAREG Approver","code":"BPAREG_APPROVER","tenantId":"pb"},{"name":"BPA Services verifier","code":"BPA_VERIFIER","tenantId":"pb.amritsar"},{"name":"QA Automation","code":"QA_AUTOMATION","tenantId":"pb.amritsar"},{"name":"State Administrator","code":"STADMIN","tenantId":"pb.amritsar"},{"name":"Super User","code":"SUPERUSER","tenantId":"pb.amritsar"},{"name":"BPAREG Approver","code":"BPAREG_APPROVER","tenantId":"pb.amritsar"},{"name":"Employee","code":"EMPLOYEE","tenantId":"pb"},{"name":"BPAREG doc verifier","code":"BPAREG_DOC_VERIFIER","tenantId":"pb.amritsar"},{"name":"BPA NOC Verifier","code":"BPA_NOC_VERIFIER","tenantId":"pb.amritsar"}],"active":true,"tenantId":"pb.amritsar","permanentCity":null}}}' \
  --compressed

For viewing OBPS inbox these roles are necessary "BPAREG_APPROVER", "BPAREG_DOC_VERIFIER"

Objective

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.

Application Details

OBPS 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

For viewing OBPS inbox these roles are necessary "BPA_FIELD_INSPECTOR", "BPA_NOC_VERIFIER", "BPA_APPROVER", "BPA_VERIFIER", "CEMP"

Refer to the config below for risk type definition:-

Objective

To provide the facility for the stakeholder users to create and submit the eDCR Application. Stakeholders include Architect, Builder.....etc.

File Path:

Apply for eDCR Application

Users can apply for the eDCR application by clicking on the “Registered Architect Login”, through which only registered stakeholders (Stakeholder includes Architect, Builder.....etc) can log in. Other users will not be able to proceed further.

Stakeholders can generate the eDCR scrutiny number by clicking on Plan Scrutiny For New Construction link. They can add all the information, according to the questions asked, after filling the information in the eDCR form click on the Submit button. This triggers the Create API call. The success or failure of the API routes the user to the acknowledgement screen. If eDCR API is Success => it routes to the acknowledgement screen. Stakeholders can see the eDCR number, application number and download option. If eDCR API is Failure => it routes to the acknowledgement screen. Stakeholders can see the application number and download option but not eDCR number.

eDCR Scrutiny

Users need to provide City, Applicant Name and Upload dxf file in order to generate the eDCR number.

Success Screen

Acknowledgement Page gets displayed after the success of eDCR create call. Here stakeholders can see -

1. eDCR Number

2. Application Number

3. Download option for downloading the scrutiny report

5. Go Back To Home button to navigate to the home page

Failure Screen

Failure acknowledgement page gets displayed if the eDCR Create API call results in failure due to some reason. Here stakeholders can see -

1. Application Number

2. Download option for downloading the scrutiny report

3. Go Back To Home button to navigate back to the home page

Applying for OC eDCR Application

Users can apply for OC eDCR application by clicking on the Registered Architect Login link through which only registered stakeholders (Stakeholder includes Architect, Builder.....etc) can log in. Other users will not be able to proceed further. Stakeholders can generate the OC eDCR scrutiny number by clicking on the OC Plan Scrutiny for new Construction link. They can add all the information, according to the question asked, and after filling the information in the eDCR form steps clicking on the Submit button triggers the Create API call. Depending on the success or failure of the API call users are routed to the acknowledgement screen.

Permit Date and Permit Number of BPA is required to generate the OC eDCR. The permit details enables the search for specific BPA record followed by a search for the OLD eDCR details (BPA eDCR). These details are used to generate the OC eDCR Number.

1. Data Required

Click on OC Plan Scrutiny for new Construction link. This routes the user to the Data required screen and the screen provides information about the data required to generate OC eDCR number.

Clicking on the Next button routes the user to the OC eDCR scrutiny details screen.

2. OC eDCR Scrutiny Details

After entering the permit number and permit date, stakeholders need to click the Search button. Internally BPA and eDCR search fetches the required data.

The BPA and eDCR search results display all details regarding the application along with the proceed for OC scrutiny button on a separate card.

On clicking the Procced for OC scrutiny button users are redirected to the Upload OC Plan Diagram screen.

File Path:

3. Upload OC Plan Diagram

Users have to upload the dxf file and click on the Submit button that triggers the Create API call.

File Path:

Success Screen

The Succss Acknowledgement Page gets displayed after a successful eDCR create call. Here stakeholders can see -

1. eDCR Number

2. Application Number

3. Download option, for downloading the scrutiny report

5. Go Back To Home button to navigate back to the home screen

Creating preview...

File Path:

Failure Screen

The Failure Acknowledgement Page gets displayed in case the eDCR create call fails for some reason. Here stakeholders can see -

1. Application Number

2. Download option, for downloading the scrutiny report

3. Go Back To Home button to navigate back to the home screen

Creating preview...

File Path:

Technical Implementation Details

All screens have been developed using the new-UI structure followed previously in FSM, PGR, PT and TL.

The link for the eDCR & OC eDCR Main Index is given below. It helps in understanding the starting point of the flow:

Config responsible for the routing of each flow

eDCR:

OC eDCR:

MDMS Data

Throughout the flow, a few of the page data is imported from MDMS. Following is the list of pages that are using MDMS data. These pages .js files can be found under page components.

For calling the MDMS data React Hooks has been used, so that it can be shared across modules. Below is the little code snippet for the call used for MDMS.

Localization

Localization keys are added under the ‘rainmaker-bpa’ locale module. In future, if any new labels are implemented in the OBPS - Architect (Citizen) they should also be pushed to the locale DB under rainmaker-bpa locale module. Below is an example of a few locale labels.

API Call Role Action Mapping

Objective

The employee stakeholder flow consists of 2 independent screens and 1 application details page. Users have access to this flow using links in the Inbox and the Search application page.

Localization

The localization module used in the OBPS module comprises rainmaker-bpareg and rainmaker-common. The rainmaker-bpareg is initialized for module localization.

MDMS

The stakeholder MDMS data is used to filter views and service types displayed on the screen in accordance with the existing user role. The TradeTypeToRoleMapping MDMS data is also used to filter views based on the selected business service.

Roles

User access to the stakeholder flows and BPAREG business service is role-based. Roles can be - "BPAREG_EMPLOYEE", "BPAREG_APPROVER", "BPAREG_DOC_VERIFIER", "BPAREG_DOC_VERIFIER"

The stakeholder search application screen is used to search all the applications independent of its workflow or process instance data, which eliminates the presence of valid roles to search an application from any business service.

The details for this screen is the same as discussed in the OBPS search application. Please refer to the same.

​All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Objective

This page provides details on the Stakeholder Registration workflow in the OBPAS module. Citizens have the option to submit the registration applications for various Stakeholders such as architects and construction companies.

Apply For Stakeholder Application

Users can apply for stakeholder application by clicking on the “Register as a Stakeholder”, and while going through the workflow, can add all the information, according to the question asked, in the middle of the workflow after correspondence address Create API will be called, and at the end of the flow, a summary screen will be visible for the review of the answers and on clicking the submit button an Update API will be called which will change the status from Initiated to Applied and Registration Application will get updated.

Registration Flow

The stakeholder Document Required screen is displayed after login, which helps the user to understand the necessary documents needed to complete the new registration for stakeholders. A citizen info card is also shown at the bottom of the page containing additional information such as the maximum size of the file that can be uploaded.

TimeLine Component

The TimeLine component is present on all pages. It informs the users about the steppers in completing the application for registration.

Licensee Details

In this step, users need to provide information about the License type and Licensee.

License Type

The system asks for the type of license that the user is registering for. If the user selects architecture, then a new field is displayed i.e. architecture number. For all other roles, no additional information user is required. All the roles are populated from the MDMS.

Licensee Details

Here users have to provide the information of the person for whom the license application is being generated. By default, the name and mobile number field will be automatically pre-filled with the logged-in user data. Edits to this detail are disabled. Applicants must fill in the remaining information accordingly.

Address Details

In this step, users have to enter their address details.

Permanent Address

Users have to provide a permanent address. This is mandatory information that the user needs to provide to move to proceed with the application.

Correspondence Address

Here user gets the option to either pre-fill the form with the permanent address provided earlier or enter a different address. Users can also skip this step as it is non-mandatory.

Clicking on the Next button calls the Create API. Further information is available in the technical Implementation details section.

Document Details

Licensee Document Details

This screen displays a list of documents and their type (in dropdown format) from the MDMS. The document list displayed is as per the role selected by the user in license step. Users have to upload all the mandatory documents in order to proceed further.

Summary Page and Acknowledgement Screen

Users can cross-verify the data entered throughout the flow on the Summary page. In case of any change or update required, the edit icon available adjacent to the section header allows the users to make the changes. It redirects users to the particular section page and the whole flow is repeated again in order to submit the application.

Along with the application details, the fee estimate for the corresponding application is also shown on the summary page.

The Update API is called for the BPAREG Application update. Update API snippet given below:

bpaRegUpdate: "/tl-services/v1/BPAREG/_update"

If the API response is successful, the Acknowledgement Screen is displayed. Else, the Failed Acknowledgement Screen is displayed.

Clicking on the Make Payment option to pay the registration fees is said in the summary screen.

Technical Implementation Details

All the screen has been developed using the new-UI structure followed previously in FSM, PGR, PT and TL, few new components have been introduced such as TimeLine, Multi upload Document etc

The link for the Stakeholder Registration Main Index is given below, it can be used to understand the starting point of the flow:

https://github.com/egovernments/DIGIT-Dev/blob/develop/frontend/micro-ui/web/micro-ui-internals/packages/modules/obps/src/pages/citizen/StakeholderRegistration/index.js

The OBPAS module is segregated into a specified structure. The screen configuration details are available in the PageComponent folder and the configuration for routing of the pages are available in the config folder which is common for both citizens as well as employees. New components like TimeLine is defined in the component folder. Below is the snippet for folder structure and routing configuration.

The Stakeholder config responsible for the routing of the pages is defined under config folder. Click on the link below to access the code.

 {
      head: "ES_NEW_APPLICATION_PROPERTY_ASSESSMENT",
      body: [
        {
          route: "stakeholder-docs-required",
          component: "StakeholderDocsRequired",
          key: "data",
          nextStep: "provide-license-type"
        },
        {
          type: "component",
          route: "provide-license-type",
          isMandatory: true,
          component: "LicenseType",
          texts: {
            headerCaption: "BPA_LICENSE_DET_CAPTION",
            header: "BPA_LICENSE_TYPE_LABEL",
            cardText: "BPA_LICENSE_TYPE_TEXT",
            submitBarLabel: "CS_COMMON_NEXT",
          },
          nextStep: "license-details",
          key: "LicneseType",
          withoutLabel: true,
          hideInEmployee: true,
        },

The Pages folder contains the high-level configuration for controlling the whole flow for citizens and employees. The flows for citizens include Apply flows, Send Back flows, Application details etc. These carry the index (the main starting point of the whole flow).

The main difference of Stakeholder registration flow from the apply flow in other modules is that the Create API is called in between the flow and at the end, the Update API is called.

The code for Create API request object generation is found inside the correspondence address component. This API call is triggered when the user clicks on the Next button on the correspondence address page.

The hook used for this API call is Digit.OBPSService.BPAREGCreate(payload, tenantId) and payload can be found inside the gonext() method in the following file:

Code reference:

https://github.com/egovernments/DIGIT-Dev/blob/develop/frontend/micro-ui/web/micro-ui-internals/packages/modules/obps/src/pageComponents/CorrospondenceAddress.js

The Utils folder basically contains all the methods that are used throughout the OBPAS module, and if any common method needs to be declared here, which in turn can be imported in other files.

For updating an application the Update API from BPAREG is called using the React hooks, which has been declared under hooks/elements/obps as OBPSService.

The response object from the Create API is used for the request object of Update API, with the addition of document details which the user has entered. This marks the status of the Application as Applied instead of initiated.

Below is the hook used for fetching the update API call.

const mutation = Digit.Hooks.obps.useStakeholderAPI(
    data?.address?.city ? data.address?.city?.code : tenantId,
    true
  );

This API is called in the Stakeholder Acknowledgement code, using the useEffect Hook.

Code reference:

MDMS Data

Throughout the flow, a few of the page data is imported from MDMS. Following are the list of pages that use MDMS data. These pages .js files can be found under page components.

For calling the MDMS data, React Hooks are used, so that it could be shared throughout the modules. Below is the little code snippet for the MDMS call.

const { data, isLoading } = Digit.Hooks.obps.useMDMS(state, "StakeholderRegistraition", "TradeTypetoRoleMapping");

Localization

Localization keys are added in the ‘rainmaker-bpareg’ locale module. In future, if any new labels are implemented in the OBPS - Stakeholder (Citizen) they should be pushed in the locale DB under rainmaker-bpareg locale module. Below is an example of a few locale labels.

API Call Role Action Mapping

Objective

To provide the facility for the user for creating New Building Permit Application by the citizen. Every application which is created is a part of the workflow.

Apply for New Building Permit Application (BPA)

Users can apply for a new building permit application by clicking on the “Registered Architect Login”. This option can be used only by registered architects to log in. Other users will not be able to proceed further.

Architects will first need to generate an eDCR Scrutiny Number if it is not already available. For this click on “Plan Scrutiny For New Construction”. If the eDCR Scrutiny Number is available, navigate directly to “Building Plan Permit For New Construction”. Add all required information while going through the workflow.

The Create API is called in the middle of the workflow after owner details. And, at the end of the flow, a summary screen is visible for the review of the entered details. Click on the submit button calls the Update API that changes the status from Initiated to Applied and the Registration Application gets updated.

eDCR Scrutiny Registration

Users must provide the City, Applicant Name and upload the dxf file in order to generate eDCR number.

Acknowledgement Page gets displayed. Users can apply for the building permit by clicking on the Apply for Building Plan Permit button. Or, they can go back and apply from the home page as mentioned in the previous section.

New Building Plan Permit Registration

The New Building Permit Document Required screen is displayed after login, which helps the user to understand the necessary documents needed to complete the new registration for New Building Permit. A Citizen Info card is also shown at the bottom of the page for any additional information such as the maximum size of the file that can be uploaded.

TimeLine Component

The TimeLine component is present on all pages of the application. It informs the user about each stepper in completing the registration application.

Scrutiny Details Step

In this step, the users need to provide and verify the details from scrutiny API.

Basic Details

Users will need to verify the basic details received from the API, using the eDCR scrutiny number. In case the scrutiny number is not entered, users can enter the number and search for the result.

Plot Details

The data asked here is not compulsory - users can enter or skip it too.

Scrutiny Details

On this page, half of the details are received from the scrutiny details API and a drop-down for sub occupancy which is multiple in nature. Users can select accordingly.

Location Details

Users can click on the GIS icon and select and pinpoint the current address on the geolocation component.

If the user does not want to select the location on the map, they can enter the Pincode. The city and locality get selected accordingly.

Owner & Document Step

In this step, users have to provide details about the owner. Owners could be single or multiple.

Owner Details

Select the type of owner and enter owner details

In case, multiple owner option is selected, the Add Owner button is visible. The Primary Owner checkbox is also available. Click on the Add Owner button allows users to add multiple owners accordingly. Click on the Next button calls the Create API.

Document Details

Users have to select the document type. The upload multiple documents if needed using the document upload component. If the type is only one, then it came pre-selected for user convenience. Also, the documents which are mandatory are defined in MDMS from where it is fetched.

An info card is also visible which informs the user about the application number of the application created in the create API call.

NOC Details

Users need to verify and upload the documents, if required, for the NOC details. This information is also fetched from the MDMS.

Summary Page and Acknowledgement Screen

Users can cross-verify the data entered throughout the flow on the Summary page. In case any change or update is required, they can click on the edit icon available adjacent to the section headers. This redirects them to the relevant page and the entire flow is repeated again in order to submit the application.

Along with this Fee estimate for the corresponding application is also shown on the summary page.

For BPA Application the Update API call is made. Below is the snippet of the Update API used:

If the API response is successful, then the Acknowledgement Screen is displayed. Else, the Failed Acknowledgement Screen is displayed.

OC Apply For New Building Permit Application (BPA)

The OCBPA flow is similar to the BPA flow detailed above with the exception of a few steps that are not necessary and therefore omitted in this flow.

OC Plan Scrutiny For New Construction

Click on the OC Plan Scrutiny for New Construction button to generate an OC eDCR number. Users need the Permit Number and the Date that is generated upon the completion of the BPA application.

Documents Required

The Documents Required screen lists all the documents or data required to generate the OC eDCR number.

OC eDCR scrutiny details

Once the user provides the Permit Number and Date, the application details are pre-populated.

After verifying the details the user needs to upload the DXF file in order to generate the OC Scrutiny number.

The success acknowledgement page is shown in case of no errors in the application.

Click on the Apply for OC New Construction redirects users to the Apply for new building permit form page. The Location & Owner Details will get auto-populated from the previous application details. The application triggers the Create API call from the scrutiny details page. The remaining flow is the same as for New Building Plan Permit.

Technical Implementation Details

All the screens have been developed using the new-UI structure followed previously in FSM, PGR, PT and TL. Some new components have been introduced such as the TimeLine, Multi-Document Upload feature etc.

The links for the BPA & EDCR Main Index are given below. These help in understanding the starting point of the flow:

The links for the OCBPA & OCEDCR Main Index are given below. These help in understanding the starting point of the flow:

The OBPS Module is segregated into a specified structure. All the screen configurations are available inside the PageComponent Folder and the configuration for routing of the pages are available within the config folder which is common for both Citizen as well as Employees. New components like TimeLine is defined within the component folder. Below is the snippet for folder structure and routing configuration.

Config responsible for the routing of each flow

BPA (new building permit application):

EDCR (scrutiny number):

OCBPA (OC new building permit application):

OCEDCR (OC Scrutiny number):

The Pages Folder is where the high-level configuration for controlling the whole flow is defined, for citizens and employees. Citizen configuration details include Apply flows, send back flows, Application details etc. The folder contains the index (the main starting point of the whole flow).

The main difference in the BPA/OCBPA registration flow from other modules is in the apply flow. The create API is called in between the flow and the Update API is called at the end.

The code for Create API request object generation is available inside the Owner details or scrutiny details component for BPA & OCBPA respectively. This API call is triggered when the user clicks on the Next button on the Correspondence Address page.

The BPA/OBPS create API call uses the Digit.OBPSService.create method to call the API. The code details are available within the gonext() method in the following files respectively.

Code reference:

The Utils Folder basically contains all the methods which are being used throughout the OBPS module, and if any common method needs to be declared here, it can be imported to other files.

Throughout the flow, the Download button is mentioned according to the current state of the Application. These documents are generated from the server side and are dependent on the business service of the application. Refer to the code below to define the business service and the following keys.

Following are the hooks used for the download PDF call:

For Occupancy Certificate use: occupancy-certificate and for Permit order: buildingpermit-low

For updating an Application, the update API from BPA is called using the React hooks, which is declared under hooks/elements/obps as OBPSService.

The response object from the Create API is used for the request object of Update API, in addition to the document details that users have entered. This changes the status of the Application as Applied instead of initiated. Along with this NOC Update API is also called which updates the status of the NOC aligned with the particular application.

for update API for NOC, BPA & OCBPA, the hook used for calling the API is:

1Digit.Hooks.obps.useObpsAPI( 2 data?.address?.city ? data.address?.city?.code : tenantId, 3 true 4 );

This API is called in the respective Acnowledgement Page:

MDMS Data

Throughout the flow, a few of the page data is imported from the MDMS. Following is the list of pages that are using MDMS data. These pages .js files can be found under page components.

For calling of MDMS data React Hooks has been used, so that it can be shared throughout the modules. Below is the little code snippet used for MDMS call.

Localization

Localization keys are added in the ‘rainmaker-bpa’ locale module. In future, if any new labels are implemented in the OBPS - Architect (Citizen) they should also be pushed in the locale DB under rainmaker-bpa locale module. Below is an example of a few locale labels.

API Call Role Action Mapping

Objective

To provide the facility for the citizen user to view the application details, updating the BPA application state and make the payment.

Users can review the list of applications and their status registered using their mobile number on the My Applications page. Each Application initially displays the Application Number, Application Type, Service Type, status, SLA with the View Details option.

View Application By Citizen

Click on the View Applications by Citizen link routes users to the My Applications screen. The screen provides BPA, OC-BPA and stakeholder registration applications and details. The BPA search API and the Stakeholder Registration search APIs are called and the application cards are visible after getting the response from the APIs.

File Path

Click on the View Details button. It routes users to the application details screen. 1. BPA Application Details

Clicking on the BPA/OC BPA application card routes users to the BPA application details page. The application details page displays the details of the application and also showcases all the actions that can be taken on the application.

Clicking on the Action button provides the citizen users with the actions list. Clicking on any one of the options opens a popup window. Users can enter the comments and upload documents. Clicking on the Submit or Forward button triggers the Update API call.

File Path

Send Back To Citizen

When employees click on the Send Back to Citizen button, the applications are routed back to the My Applications list of the citizen. The Application Details screen allows users to make the required changes. The forward action button routes the citizen to the Summary screen. Users can attach the documents and submit the application.

File Path

Download

Citizens can download the receipts which include Application Fee, Sanction Fee, Permit order, Revocation pdf, Comparison report etc based on the conditions.

File Path

Stakeholder Registration Application Details

Clicking on the Stakeholder Application card routes the user to the stakeholder application details. The application details page displays the details of the application and also showcases all the actions that can be taken on the application.

File Path

Timeline Component

The Timeline component is present at the end of the application details and provides information on the current status.

Technical Implementation Details

All the screens have been developed using the new-UI structure followed previously in FSM, PGR, PT and TL.

OBPS Hooks Details

File Path

OBPS Search API Hook

OBPS Update API Hook

OBPS WorkFlow API Hook

OBPS MDMS Hooks

Collection Services Hooks(For Receipts and Amount display)

Stakeholder Hooks

File Path

Search Hook

MDMS Hook

Collection Service Hook(For Receipts and Amount display)

Localisation

Localisation keys are added under the ‘rainmaker-bpa’ and ‘rainmaker-bpareg’ locale modules. In future, if any new labels are implemented in the OBPS - Architect (Citizen) they should also be pushed to the locale DB under 'rainmaker-bpa' locale module. Below is an example of a few locale labels.

API Call Role Action Mapping