Resident Services are the self-services used by residents themselves via a portal. The Resident Portal is a web-based UI application that provides residents of a country with services related to their Unique Identification Number (UIN).
The documentation here will guide you through the prerequisites required for the developer's setup.
Below is a list of tools required in Resident Services:
JDK 11
Any IDE (like Eclipse, IntelliJ IDEA)
Apache Maven (zip folder)
pgAdmin
Postman
Git
Notepad++ (optional)
lombok.jar (file)
settings.xml (document)
Follow the steps below to set up Resident Services on your local system:
Download lombok.jar
and settings.xml
from here.
Install Apache Maven.
Copy the settings.xml
to ".m2" folder C:\Users\<username>\.m2
.
Install Eclipse.
Open the lombok.jar
file and wait for some time until it completes the scan for Eclipse IDE and then click Install/Update
. Specify the eclipse installation location if required by clicking the ‘Specify location…’ button. Then, click Install/Update
the button to proceed.
Check the Eclipse installation folder C:\Users\userName\eclipse\jee-2021-12\eclipse
to see if lombok.jar
is added. By doing this, you will not have to add the dependency of lombok
in your pom.xml
file separately as it is auto-configured by Eclipse.
Configure the JDK (Standard VM) with your Eclipse by traversing through Preferences → Java → Installed JREs
.
For the code setup, clone the repository and follow the guidelines mentioned in the Code Contributions.
Open the project folder where pom.xml
is present.
Open the command prompt from the same folder.
Run the command mvn clean install -Dgpg.skip=true -DskipTests=true
to build the project and wait for the build to complete successfully.
After building a project, open Eclipse and select Import Projects → Maven → Existing Maven Projects → Next → Browse to project directory → Finish
.
After successful importing of the project, update the project by right-clicking on Project → Maven → Update Project
.
For the environment setup, you need an external JAR that is available here with different versions. Download the below-mentioned JARs with appropriate latest/appropriate versions. You will need to input the appropriate artifact ID and version and other inputs.
a. icu4j.jar
b. kernel-auth-adapter.jar
c. kernel-ref-idobjectvalidator.jar
d. kernel-transliteration-icu4j.jar
E.g.: You can download kernel-auth-adapter.jar
and add to the project Libraries → Classpath → Add External JARs → Select Downloaded JAR → Add → Apply and Close
).
Clone mosip-config repository.
a. As Resident Services is using two properties files- resident-default.properties
and application-default.properties
. But for the local running of the application, you need to provide additional/overriding properties such as secrets, passwords, and properties passed by the environment which can be added to new files application-dev-default.properties
(common properties for all modules) and resident-dev-default.properties
(Resident service-specific properties).
b. You will have to create both the property files according to your environment and put them in mosip-config folder
(cloned). The same files are available below for reference.
These two files are loaded by the application by specifying the application names in the Application VM arguments like- Dspring.cloud.config.name=application,resident,application-dev
, resident-dev
(also detailed in a later section).
To run the server, two files are required- kernel-config-server.jar
and config-server-start.bat
.
Put both files in the same folder and point to the property- Dspring.cloud.config.server.native.search-locations
to mosip-config
folder in config-server-start.bat
file and also check the version of kernel-config-server.jar
towards the end of the command.
Example:
As mentioned earlier, you will have to create property files according to your environment like resident-env-default
and application-env-default
(here env represents environment name). Both files will contain different configurations such as resident-env-default
will have config properties (e.g., secrets, passcodes, etc) used for the resident-services module only and application-env-default
is used for environment-specific changes and can be used for other modules as well.
In this example, currently, these two files are created for the dev environment and hence the files have suffixes of -dev
. If you want to run it for a different environment such as qa, create these two files with -qa
suffixes, and then you will also need to provide the appropriate VM argument for that referring to qa environment.
For instance,
Add mosip.resident.client.secret=***********
property to be able to use a decrypted passcode and run it on your local machine.
If you check the URLs present in application-default
the file, they are set to module-specific URLs, but you need to use internal/external environment URLs to access the APIs by using an application-dev-default file.
In application-dev-default
file, assign environment domain URL to mosipbox.public.url
, and change all other URLs with ${mosipbox.public.url}.
It results in mosipbox.public.url=internal/externalAPI
(e.g., mosipbox.public.url=https://api-internal.dev.mosip.net) and it will connect with the Development environment.
Run the server by opening the config-server-start.bat
file.
Open Eclipse and run the project for one time as a Java application, so that it will create a Java application which you can see in debug configurations, and then change its name. (e.g.: project name with the environment - "Resident-dev").
Open the Arguments tab and specify Application VM arguments: For example, for a development environment:
Save this run configuration as ‘Resident-dev’ .
For qa
environment, you can create Resident-qa
run configuration with VM argument as below.
Example:
Click Apply
and then debug it (starts running). In the console, you can see a message like Started ResidentBootApplication in 34.078 seconds (JVM running for 38.361)
.
For API documentation, refer here.
The APIs can be tested with the help of Postman or Swagger-UI.
Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster. It is a widely used tool for API testing. Below you will find the APIs postman collection of resident-services.
Swagger is an interface description language for describing restful APIs expressed using JSON. You can access Swagger-UI of resident-services for the dev-environment from https://api-internal.dev.mosip.net/resident/v1/swagger-ui.html
and localhost from http://localhost:8099/resident/v1/swagger-ui.html
.
Download the JSON collection available below and import it to your postman. Resident-Service-APIs.postman_collection-latest.json.
Create an environment as shown in the image below.
This environment is created for dev. Give the variable name as url
and set both values as https://api-internal.dev.mosip.net
.
Similarly, create another environment as shown below.
This environment is created for localhost. Give the variable name as url
and set both values as http://localhost:8099
.
This repository contains the UI code for the Resident portal. To know more about the features and functions present on the portal, refer here.
The code is written in Angular JS.
Install node.js
- To build the angular code using angular cli that runs on node, recommended Node: 14.17.3, Package Manager: npm 6.14.13
Install angular cli
– To install angular cli for building the code into deployable artifacts. Follow the following steps to install angular cli on your system.
npm install -g @angular/cli
(to install angular cli)
ng --version
(to verify angular is installed in the system) We recommend Angular CLI: 7.2.1
Check out the source code from GIT – To download the source code from git, follow the steps below to download the source code on your local system.
git clone https://github.com/mosip/resident-ui.git (to clone the source code repository from git)
Build the code
Follow the steps below to build the source code on your system.
Navigate to the resident-ui directory inside the cloned repository.
Run the command ng build "--prod" "--base-href" "." "--output-path=dist"
in that directory to build the code.
Build Docker image
Follow the steps below to build the docker image on your system.
docker build -t name .
(replace name
with the name of the image you want, "." signifies the current directory from where the docker file has to be read.)
Example: docker build -t residentui .
Run the Docker image
Follow the steps to build a docker image on your system.
docker run –d –p 80:80 --name container-name image-name
(to run the docker image created with the previous step,-d
signifies to run the container in detached mode, -p
signifies the port mapping left side of the":" is the external port that will be exposed to the outside world and the right side is the internal port of the container that is mapped with the external port. Replace container-name
with the name of your choice for the container, replace image-name
with the name of the image specified in the previous step)
Example: docker run -d -p 8080:8080 --name nginx residentui
Now you can access the user interface over the internet via a browser.
Example: http://localhost:8080/#/dashboard
Build & deploy the code locally
Follow the steps below to build the source code on your system.
Navigate to the resident-ui directory inside the cloned repository. Then, run the following command in that directory:
npm install
ng serve
Now, you can access the user interface via the browser.
Example: http://localhost:4200
The table below outlines the frameworks, tools, and technologies employed by Resident Portal.
7.2.1
AngularJS is a toolset for building the framework most suited to your application development. It is fully extensible and works well with other libraries.
16.2.0
Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine.
The table below outlines the frameworks, tools, and technologies employed by Resident Services.
Java SE 11
OpenJDK 11
Language Runtime in Docker Image
GNU General Public License, version 2, with the Classpath Exception
Ubuntu Server
20.04
Docker base image Operating System
Free
Spring
5
Application Framework
Apache License 2.0
Apache commons
Version compatible with Spring 5
Utilities
Apache License 2.0
Hibernate
5.2.17.Final
ORM
Apache Software License 2.0
Hibernate validator
6.0.12.Final
validator
Apache Software License 2.0
mvel2
2.4.7.Final
Expression language
Apache License 2.0
Jackson
2.9.x
JSON marshal/unmarshal
Apache Software License 2.0
Junit
4.x and above
Unit Testing
Common Public License - v 1.0
mockito
2.22.0
Junit - Mock Objects
MIT
power-mock
2.0.7
Junit - Mock Static Classes
Apache Software License 2.0
logback
1.2.3
Log
GNU Lesser GPL Version 2.1
velocity
1.7
Templating
Apache Software License 2.0
Swagger
Open API - 3
API Documentation
Apache Software License 2.0
Tomcat server
8
Application Server
Apache Software License 2.0
PostgreSQL
Server: 10
Database
Postgres License BSD 2-clause "Simplified License"
Sonar
7.2
Code quality Checking
Open Source License
Micrometer Prometheus
1.4.2
Metrics
Apache Software License 2.0
gson
2.8.4
JSON parser
Apache Software License 2.0
h2 database
1.4.197
JUnit Test DB
EPL 1.0, MPL 2.0
lombok
1.18.8
Development - reduce the boilerplate code
MIT
IText PDF
5.5.13.3
PDF Generation
AGPL 3.0
icu4j
63.1
Transliteration
Unicode-3.0
UI specs of resident module are used to configure the form fields across Resident Portal. UI specs are saved as a JSON file with a list of fields. Each field has a set of attributes/ properties that can be configured which affects the look and feel along with the functionality of the field.
Below is the list of all the properties available for each field in the Resident Portal UI specs:
Property Name
Details
Sample Value
id
The id property is the unique id provided to a field to uniquely identify it. The id can be alpha-numeric without any spaces between them.
"id":"zone"
description
This is a non-mandatory property used to describe the field.
"description": "zone"
labelName
This property defines label name for the field. This property has sub-attributes as the language code (eng, fra, ara) to store data in different languages based on the country's configuration.
"labelName": { <br>"eng": "Zone", <br>"ara": "منطقة", <br>"fra": "Zone"}
controlType
This property defines the kind of UI component to be used to capture data in UI. Currently the values that can be used are: <br/> • textbox (creates multiple textboxes for each field to capture input in all the languages configured for the setup)<br/>• dropdown <br/>• fileupload <br/> • date (creates a date picker)<br/> • ageDate (creates a date picker along with number toggle to provide age directly)<br/> • checkbox (creates a toggle checkbox for the field which can be checked or unchecked)<br/> • button (creates dropdown options as buttons, which user can select easily)
inputRequired
This property decides if the field is to be displayed in the UI form or not. It is useful for some internal fields which do not need any input from the user.
required
This is a mandatory property which decides if the field is a required form field or not. If true, user must provide some value for the field.
type
This property defines the data type of the value corresponding to this field. The data types supported are “number”, “string” and “simpleType”.<br/> The type “simpleType” means that language specific value will be saved along with the language code.
fieldType
This property is relevant when control type is “dropdown” or “button”. It defines if the field is of type “default” or “dynamic”. <br/>If it is “dynamic” then all the options for the dropdown are populated from the “master.dynamic_field” table otherwise they are populated from corresponding table example “master.gender”
subType
This is relevant for 2 cases:<br/>1. When control type is “dropdown”/ “button” and the type is “dynamic” then “subtype” can be used to populate the options for the field with the data available in “master.dynamic_field” table.<br/>2. When the control type is “fileupload”, then the property ”subtype” is used to map the field to a “code” in the “master.doc_category” table.
validators
This property enables us to add the list of language specific validators for the field. <br/>* Each validator can have the below fields,<br/>“langCode”,<br/>“type”,<br/>“validator”,<br/>“arguments”,<br/>“errorMessageCode”<br/><br/>* The “type” defines the validation engine type.<br/>* The “validator” gives the pattern/ methodName/ scriptName/ expression<br/>* The “arguments” array to is used to hold parameter or dependent field ids required for validation<br/>* The “errorMessageCode” can be given to add custom error message which will be shown to the user when the validation fails. The error message corresponding to this code will be picked from language specific i18n translation files. In case “errorMessageCode” is not given then generic error message will be displayed to the user when validation fails. <br/><br/>Currently, regex is supported by MOSIP.<br/>If “langCode” is not added then same “validator” is used for all languages of the field.
<br>"validators": [{ <br>"langCode": "eng", <br>"type": "regex", <br>"validator": "^(?=.{0,50}$).*", <br>"arguments": [], <br>"errorMessageCode": "UI_1000"<br>},{ <br>"langCode": "ara", <br>"type": "regex", <br>"validator": "^[A-Z]+$", <br>"arguments": []<br>},{ <br>"langCode": "fra", <br>"type": "regex",<br>"validator": "^[A-Z]+$", <br>"arguments": []<br>}]
locationHierarchyLevel
This attribute is mandatory for the location dropdown fields. <br/>The value will be as per corresponding location hierarchy level from the master.loc_hierarchy_list table.
{<br>"id":"region",<br>"controlType":"dropdown",<br>"fieldType":"default",<br>"type":"simpleType",<br>"parentLocCode":"MOR",<br>"locationHierarchyLevel":1<br>..}
parentLocCode
This attribute is to be used only for location dropdown fields and it is optional. <br/>The corresponding location dropdown will be pre populated in UI based on the value in “parentLocCode”. <br/>If this attribute is NOT mentioned in UI specs, then the dropdown will be populated based on selection in its parent dropdown, as before. <br/>For the first dropdown, in case this attribute is not mentioned in UI specs then the value from “mosip.country.code” configuration will be used for backward compatibility.
{<br>"id":"region",<br>"controlType":"dropdown",<br>"fieldType":"default",<br>"type":"simpleType",<br>"parentLocCode":"MOR",<br>"locationHierarchyLevel":1<br>..}
alignmentGroup
* This property is used to group the fields on the screen. <br>* If it is skipped, then all the fields will appear in same sequence (horizontally layout) as they appear in UI specs. <br>* If you want the first and fifth field to be in same row in the screen, you can add this attribute with same group name. <br>* The UI is responsive so it will accommodate as many fields in one row as they will fit comfortably.
containerStyle
This is used to optionally apply some CSS styles to the UI field container.
"containerStyle": {<br>"width": "600px",<br>"margin-right": "10px"<br>}