Stakeholder - Registration Flow
- Tulika Kundu
Objective
To provide the facility for the user which allows to create Stakeholder Application by the citizen. every application which is created is a part of the workflow.
Apply for Stakeholder Application
User 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
Stakeholder Document Required screen will be displayed after login, which helps the user to understand the necessary documents needed to complete the new registration for Stakeholder. A Citizen Info card is also shown at the bottom of the page for any additional information, in here it’s about the maximum size of the file that can be uploaded.
Time Line Component
In all the pages Time Line component is present which informs the user about each stepper in completing the whole application registration.
Licensee Details Step:
In this Step User need to provide information about the License type and Licensee.
License Type Stepper:
First it will ask for the type of license for which the user is registering for, if the user selects and architecture, then a new field will gets displayed i.e. architecture number. for all other roles no additional information user needed to provide. All this roles are populated from MDMS.
Licensee Details Stepper:
In this step user need to provide the information f the person for whom the license application is being generated, by default the name and mobile number field will be automatically prefilled with data of login-ed user and will be disabled in nature, rest of the information user can enter accordingly.
Address Details Step:
In this step user will need to enter its own address details.
Permanent Address Stepper:
User need to provide its permanent address, this is an mandatory information, which user needs to provide to move to next step.
Correspondence Address Stepper:
Here user gets an option to either prefill it with the permanent address enter at the last step, or skip it all together as it is non-mandatory.
Here on clicking on Next button Create API will be called, further information at technical Implementation details section.
Document Details Step
Licensee Document Details:
here a list of documents and its type (in drop down) will be displayed from MDMS according to the role selected by the user in license step. user need to enter all the mandatory documents in order to proceed further.
Summary Page and Acknowledgement Screen:
Users can cross-verify the data entered throughout the flow in the Summary page and also if needed to change/update any data, can do that by clicking on the edit icon just mentioned in front of the section header, it will credit them to the said page which data needs to be changed and then the whole flow needs to be repeated again in order to submit the application.
Along with this Fee estimate for the corresponding application is also shown in the summary page.
For Applying of BPAREG updated API is being called, following is the snippet of the Update API being used:
bpaRegUpdate: "/tl-services/v1/BPAREG/_update"If the API response is successful, then the Acknowledgement Screen will be displayed, otherwise Failed Acknowledgement Screen will be displayed.
On clicking on the Make Payment option user can pay the registration fees 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 Time Line, 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:
OBPS Module has been segregated into a specified structure, All the screen configuration is inside PageComponent Folder, and the configuration for routing of the pages are mentioned under config folder which is common for both Citizen as well as Employee. New component like Time Line is defined under component folder. Below is the snippet for folder structure and routing configuration.
Stake holder config which is responsible for routing of the pages are defined under config folder, the code can be found in the below link:
{
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,
},Pages Folder is where the high level configuration for controlling the whole flow is mentioned, for citizens and employees. Citizen includes Apply flows, send back flows, Application details etc. Which inside carry the index (the main starting point of the whole flow).
The main difference of Stakeholder registration flow from other modules apply flow is that the create API is being called in between the flow and at the end the update API is called.
The code for create API request object generation can be found inside the correspondence address component. this API call is triggered when user clicks on the next button in correspondence address page.
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:
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, which in turn can be imported in other files.
For updating an Application the update API from BPAREG is being called using the React hooks, which has been declare under hooks/elements/obps as OBPSService.
The response object from create API is being used for the request object of update API, with addition of document details which user had entered, it will make the status of the Application as Applied instead of initiated.
Hook used for fetching the update API call is :
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.
MDMS data:
Throughout the flow, few of the pages data are being imported from MDMS, Following are the list of pages which are using MDMS data, These pages .js files can be found under page components.
PageComponent | MDMS Detail | Module Details Name | Master Detail Name |
|---|---|---|---|
StakeholderDocsRequired | List of documents required for registration |
|
|
LicenseType | License role options |
|
|
LicenseDetails | Gender |
|
|
StakeholderDocsRequired | Documents and its drop downs |
|
|
For calling of MDMS data React Hooks has been used, so that it could be shared throughout the modules. Below is the little code snippet for the call used for MDMS.
Localization :
Localization keys are added under the ‘rainmaker-bpareg’ locale module. In future if any new labels are implemented in the OBPS - Stakeholder (Citizen) that should also be pushed in the locale DB under rainmaker-bpareg locale module. Below is the example of few locale labels.
API Call Role Action mapping:
S.No. | API
| Action id | Roles |
|---|---|---|---|
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
|