1 of 18

Resident Service Audits

Resident services are the self-services which is used by the resident themselves via a portal. Functionalities such as lock/unlock authentication types, reprint UIN, view authentication history etc. are available. The services use OTP method of authentication.

System Events

The following events are triggered as part of System Event Type in Residence Service module

Request Info for System Event Type

Sl No.

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

Success response for System Event Type

Failure response for System Event Type

ID Repository Audits

ID Repository contains the record of identity for an individual, and provides API based mechanism to store, retrieve and update identity details by other MOSIP modules.

ID Repository Service

The ID Repository functionality will store identity data and documents and also retrieve stored identity details by UIN or VID upon receiving the request.

User Event Type

The following events are triggered as part of System Event Type in ID Repository Service module

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

Kernel

Overview

Kernel is on which MOSIP services are built. Kernel is a platform to build higher-level services as well as a secure sandbox within which the higher-level service functions. Kernel provides a bedrock to build and run the services by providing several significant necessary technical functions so that individual services are concerned with specific business functions.

Kernel is not a distinct module but a bunch of services and libraries that are shared across different modules.

Components

Refer to commons repo/kernel for all components of Kernel.

Detailed functionality

Kernel has many services and functions. Details of some of them are mentioned below:

Common Services
UIN & VID Generation Service
Data Services
Master Data Services
Key Manager
Audit Manager
Authentication and Authorization
Packet Manager
Web Sub

Services and libraries

Details of all services and libraries along with code, design are available in commons repo/kernel.

Build and deploy

Refer to build and deploy instructions in commons repo/kernel.

APIs

Kernel APIs

Registration Client Audits

The registration client is a thick Java-based client where the resident's demographic and biometric details are captured along with the supporting documents in online or offline mode. The captured information is packaged in a secure tamper-proof way and send to the server for processing.

The Login and Authentication Service ia about the process of logging into the Registration Client by Operator or Supervisor using various authentication modes such as user id, password, OTP and biometrics.

User Event Type

The following events are triggered as part of User Event Type in Login and Authentication Service

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

The navigation links in home screen keeps the user oriented and makes its esier for them to move around to desired sections of the application.

User Event Type

The following events are triggered as part of User Event Type under Home Screen Navigation

System Event Type

The following events are triggered as part of System Event Type under Home Screen Navigation

New Registration Flow

An operator can initiate the process of registering an new applicant in the MOSIP ecosystem by filling the new registration form with the resident.

User Event Type

The following events are triggered as part of New Registration

Success Response for User Event Type

Failure Response for User Event Type

End of Day Activities

As a part of EOD activities the supervisor can review the registration acknowledgement, retrieve the packets, approve or reject the packets and finally upload the packets to the server.

User Event Type

The following events are triggered as part of end of day activities

System Event Type

The following events are triggered as part of end of day activities

Synchronization Activities

The Synchronization service gives information about the various sync activities that take place between the server and the registration client, such as Pre-Reg Sync, packet count,Geo sync etc.

User Event Type

The following events are triggered as part of synchronization activities

Scheduler Service

The scheduler service periodically check all the open sessions to determine which ones have been idle for a time greater than the idle timeout set.

System Event Type

The following events are triggered as part of scheduler service

Mosip Device Manager Service

Thw Mosip Device Manager Service which runs on a particular port automatically scans all the devices (Eg. Biometric Device) and stores the information in device registry.The service gives the information about the device availabilty.

User Event Type

The following events are triggered as part of Mosip Device Manager service

Success Response for User Event Type

Failure Response for User Event Type

Auth Adapter

Auth adapter is a package that needs to be injected into Mosip's applications exposing REST API's inorder to secure them.

Auth Adapter includes following class definitions:

SecurityConfig

Holds the main configuration for authentication and authorization using spring security.

Inclusions:

AuthenticationManager bean configuration:
- RETURNS an instance of the ProviderManager.
- This extends AbstractAuthenticationProcessingFilter.
- Binds the AuthenticationManager instance created with the filter.
RestTemplate bean configuration:
- RETURNS an instance of the RestTemplate.
Secures endpoints using antMatchers and adds filters in a sequence for execution.

AuthFilter

AuthFilter is bound with AuthenticationManager to attempt authentication.

Attempt Authentication tasks:

Receives "Authorization" Header from request headers.
Use the assigned Authentication manager to authenticate with the token.

AuthHeadersFilter

Tasks:

Sets headers to allow cross origin requests.
Sets header to allow and expose "Authorization" header.

AuthProvider

Contacts auth server to verify token validity.

Tasks:

Contacts auth server to verify token validity.
Updates token into SecurityContext.

AuthSuccessHandler

Handles successful authentication. If any action needs to be done after successful authentication, this is where you have to do it.

AuthEntryPoint

Captures and sends "UnAuthorized" error.

AuthToken

This extends UsernamePasswordAuthenticationToken class.

AuthUserDetails

Used by spring security to store user details like roles and use this across the application for Authorization purpose.

ClientInterceptor

It is used to intercept any http calls made using rest template from this application.

Config:

Tasks:

Intercept all the requests from the application and do the below tasks.
Intercept a request to add auth token to the "Authorization" header.
Intercept a response to modify the stored token with the "Authorization" header of the response.

MosipUser

Mosip user is the standard spec that will be tuned based on the details stored in ldap for a user.

AuthControllerAdvice

Adds latest token to the response headers before it is committed.

Admin Service Audits

The admin portal provides various services for MOSIP administrators such as Login, Account management, Resource Management, Master data management and Packet status check based on RID.

Packet Status Service

The packet status service allows us to view the status of a packet by giving the RID of the packet. The packet status will contain all the stages the packet has passed through along with the last stage the packet is in. In case the packet has not been processed or is marked for Re-Send/Re-Register, the admin will be able to view specific comments indicating the reason for that particular status.

User Events

The following events are triggered as part of User Event Type in Packet Status Service module of Admin Services

Failure response for User Event Type

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

System Events

The following events are triggered as part of System Event Type in Packet Status Service module of Admin Services

Request Info for System Event Type

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

Success response for System Event Type

Failure response for System Event Type

Bulk Data Service

The bulk data service provides a feature for the mosip administrator to bulk insert, upload or delete - master data using csv’s. The bulk data upload operation can be performed based on various parameters.

System Events

The following events are triggered as part of System Event Type in Bulk Data Service module of Admin Services

Request Info for System Event Type

Success response for System Event Type

Failure response for System Event Type

Master Data Services Functionality

Master Data Management

Location Hierarchy

Create Location Hierarchy

Upon receiving a request to add Location hierarchy (e.g., Country - Region - Province - City- LAA) with the input parameters (code, name, hierarchy_level, hierarchy_level_name, parent_loc_code ,lang_code and is_active), the system stores the Location hierarchy in the Database

While storing the location hierarchy in the database, the system performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- name - character (128) - Mandatory
- hierarchy_level - smallint - Mandatory
- hierarchy_level_name - character (64) - Mandatory
- parent_loc_code - character (32) - Optional
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
Validate if the Location name received does not already exist in the hierarchy for which the location is getting created
- If Location name already exist under the hierarchy level, throw an appropriate error
The API should not allow creation of the Location if the data is not received in default language
If the data for the Location is not received in all the configured languages, the API should allow the Location to be created given the Point 3 is satisfied.
The API should activate the Location while creation provided the data for all the configured languages is received during the initial creation
- If the data for all the configured languages is not received, deactivate the Location while creation
While storing the location,
- cr_by should be the Username of the user who is accessing this API
- cr_dtimes should be the date-time at which the user is creating the Location
Responds with the Location Hierarchy created successfully
The component restricts the bulk creation of Master Data through API. However it could be done through a script as need be depending on the requirement of the country.
In case of exceptions, system triggers error messages as received from the Database

Update a Location

On receiving a request to update a Location with the input parameters (code, name, hierarchy_level, hierarchy_level_name, parent_loc_code, lang_code and is_active), the system updates the Location in the Location Database for the code received.

The system performs the following steps to update the location in the Master Database:

Validates if all required input parameters have been received as listed below for each specific request
- code character (36) - Mandatory
- name character (128) - Mandatory
- hierarchy_level smallint - Mandatory
- hierarchy_level_name character (64) - Mandatory
- parent_loc_code character (32) - Mandatory
- lang_code character (3) - Mandatory
- is_active boolean - Mandatory
Validate if the Location name received does not already exist in the hierarchy of the Location
- If Location name already exist under the hierarchy level, throw an appropriate error
The API should not allow activation of Location if the data for the Location is not present in all the languages which are configured for a country
For the code received in the request, replaces all the data received in the request against the data existing in the Location database against the same code.
While receiving the request for activation, If the Location is already Active, the API should throw an error message. Refer messages section.
While receiving the request for deactivation, If the Location is already Inactive, the API should throw an error message. Refer messages section
If for a Location data, is_active flag is being sent as “False” and there are active child Locations (also the subsequent child locations) being mapped to received location, do not deactivate the location. Respond with appropriate message. Refer messages section
Deleted record are not be updated
upd_by should be the Username of the user who is accessing this API
upd_dtimes should be the date-time when the Location is being updated
Responds with data not found error if deleted record is received in the request
Responds with appropriate message if the Location is updated successfully
In case of Exceptions, system triggers relevant error messages

Verify Location

Upon receiving a request to validate the Location Name with input parameters (Location Name), the system checks the Location Name in the Master Database

While checking the location in the Database, the system performs the following steps:

Validates if the request contains the following input parameters
- Location Name - Mandatory
If the mandatory input parameters are missing, throw the appropriate message
In case of Exceptions, system triggers relevant error messages

Fetch Location Hierarchy Levels based on a Language Code

Upon receiving a request to fetch the Location Hierarchy Levels with input parameters (Language Code), the system fetches the Location Hierarchy Levels in the requested language. The following steps are performed by the system:

Validates if the request contains following input parameters (Language Code)
- Language Code - Mandatory
Validates if the response contains the Location Hierarchy Levels with the following attributes
- Hierarchy Level
- Hierarchy Name
- IsActive
In case of Exceptions, system triggers relevant error messages

Fetch the Location Hierarchy Data based on a Location Code and a Language Code

Upon receiving a request to fetch all the Location Hierarchy Data with input parameters (Location Code and Language Code), the system fetches the Location Hierarchy Data based on requested Location code and language code. The following steps are performed by the system:

Validates if the request contains the following input parameters
- Location Code - Mandatory
- Language Code - Mandatory
If the mandatory input parameters are missing, throw the appropriate message.
Validates if the response contains the following location hierarchy data and the corresponding attributes against the Location Code and Language Code received in the input parameter (i) List of Countries against the Location Code
- Country Code
- Country Name
- IsActive
(ii) List of Regions against the Location Code
- Region Code
- Region Name
- IsActive
(iii) List of Provinces against the Location Code
- Province Code
- Province Name
- IsActive
(iv) List of Cities against the Location Code
- City Code
- City Name
- IsActive
(v) List of Local Administrative authorities against the Location Code
- Local Administrative Authority Code
- Local Administrative Authority Name
- IsActive
(vi) List of Pincodes against the Location Code
- Pincode
- IsActive
Responds to the source with all the Location Hierarchy Data based on the Location Code
In case of Exceptions, system triggers relevant error messages.

Fetch the Location Hierarchy Data for the bottom next hierarchy based on a Location Code and a Language Code

Upon receiving a request to fetch all the Location Hierarchy Data with input parameters (Location Code and Language Code), the system fetches the Location Hierarchy Data for the next hierarchy level. The following steps are performed by the system:

Validates if the request contains the following input parameters
- Location Code - Mandatory
- Language Code - Mandatory
If the mandatory input parameters are missing, throws the appropriate message.
Fetches the Location data of only the child hierarchy of location code received (For e.g., if the location code for a particular Province is received, responds with the data of all the Cities existing in that Province, similarly if location code of a City is received, responds all the data regarding the Local Administrative Authorities existing under that City)
Responds to the source with the data fetched
In case of Exceptions, system should trigger an error message.

Delete a Location

On receiving a request to delete a Location with the input parameters (code), the system updates the is_deleted flag to true in the Location Database against the code received.

The system performs the following steps in order to delete the loaction received in the code:

Validates if all required input parameters have been received as listed below for each specific request
Delete all records for the code received
Deleted record are not be deleted again
Responds with data not found error if deleted record is received in the request
Responds with dependency found error if a record to be deleted is used as foreign key in the dependent table
Responds with the Code for the Location Hierarchy deleted successfully
- code - character (36) - Mandatory
In case of Exceptions, system triggers relevant error messages.

List of Holidays

Create Holiday

Upon receiving a request to add Holiday Data with the input parameters (location_code, holiday_date, holiday_name, holiday_desc, lang_code and is_active), the system stores the Holiday in the Database. The following steps are performed by the system:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- location_code - Character - 128 - Mandatory
- holiday_date - Date Format (yyyy-mm-dd) - Mandatory
- holiday_name - Character - 64 - Mandatory
- holiday_desc - Character - 128 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message.
'location_code' received should be from list of 'codes' from 'location' masterdata table
- If not, the API should throw an error.
If all the above validations are successfull, the API should update the data in the database agianst the id received
API should perfrom below multi-language validations on the Holiday data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Holiday as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Holiday details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Update Holiday

This API should only be accessible to Global Admin
The API should accept only the below parameter
- id - Character - 36 - Mandatory
- location_code - Character - 128 - Mandatory
- holiday_date - Date Format (yyyy-mm-dd) - Mandatory
- holiday_name - Character - 64 - Mandatory
- holiday_desc - Character - 128 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message.
- 'location_code' received should be from list of 'codes' from 'location' masterdata table
If not, the API should throw an error.
If all the above validations are successfull, the API should update the data in the database agianst the id received
API should perfrom below multi-language validations on the Template data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Template as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Template details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Fetch List of Holidays based on a Registration Center ID, a Year and a Language Code

On receiving a request to fetch the list of Holidays with the input parameters (Registration Center ID, Year and Language Code), the system fetches the list of Holidays mapped to a Registration Center and for the year and Language Code received in input parameter as per the below steps:

Validates if the received request contains the following input parameters
- Registration Center ID - Mandatory
- Year - Mandatory
- Language Code - Mandatory
If the mandatory input parameters are missing, throws the appropriate message
Validates if the response contains the List of Holidays against the Registration Center ID and the year received and contains the following attributes for a Region
- Holiday ID
- Holiday Date
- Holiday Name
- IsActive
Responds to the source with the List of Holidays
In case of Exceptions, system triggers relevant error messages

Biometric Authentication Type

Create Biometric Authentication Type

On receiving a request to add Biometric Authentication Type (e.g., Fingerprint, Iris) with the input parameters (code, name, descr, lang_code and is_active), the system stores the Biometric Authentication Type in the Database as per the below steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- name - character (64) - Mandatory
- descr - character (256) - Optional
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
Responds with the Biometric Authentication Type Code and Language Code for the Biometric Authentication Type created successfully
The component restricts the bulk creation of Master Data
In case of Exceptions, system triggers error messages as received from the Database.

Fetch the List of Biometric Authentication Type based on a Language Code

On receiving a request to fetch the List of Biometric Authentication Type with input parameters (Language Code), the system fetches the List of Biometric Authentication Type against the Language Code as per the below steps:

Validates if the request to add Biometric Authentication Type contains the following parameters
- Language Code - Mandatory
If the mandatory input parameters are missing, responds with all the data.
Validates if the response contains the List of Biometric Authentication Type against the Language Code along with the IsActive Flag for each Biometric Authentication Type
Responds to the source with List of Biometric Authentication Type
In case of Exceptions, system triggers relevant error messages

Biometric Attribute Type

Create Biometric Attribute

On receiving a request to add Biometric Attribute (e.g., Right Thumb, Left Thumb) with the input parameters (code, name, descr, bmtyp_code, lang_code and is_active), the system stores the Biometric Attribute in the Database as per the below steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- name - character (64) - Mandatory
- descr - character (128) - Optional
- bmtyp_code - character (36) - Mandatory
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
Responds with the Biometric Attribute Code and Language Code for the Biometric Attribute created successfully
The component restricts the bulk creation of Master Data
Responds to the source with the appropriate message.
In case of Exceptions, system triggers error messages as received from the Database

Fetch the List of Biometric Attributes based on the Biometric Authentication Type and a Language Code

On receiving a request to fetch the List of Biometric Attributes with input parameters (Biometric Authentication Type and Language Code), the system fetches the List of Biometric Attributes against the Biometric Authentication Type and the Language Code Received as per the below steps:

Validates if the request contains the following input parameters
- Biometric Authentication Type - Mandatory
- Language Code - Mandatory
If no data is present in the Database for the input parameter received, responds with an appropriate message.
If both the input parameter is missing, responds with all the data.
If one of the input parameters is missing, throw the appropriate message. Refer "Messages" section.
Validates if the response contains the List of Biometric Attributes with all the attributes against Biometric Authentication Type and Language Code Received
- Biometric Attribute Code - Mandatory
- Biometric Attribute Name - Mandatory
- Biometric Attribute Description - Optional
- IsActive – Mandatory
Responds to the source with the Fetched Data
In case of Exceptions, system triggers relevant error messages

Gender

Create Gender Types

This API should only be accessible to Global Admin
The API should accept only the below parameters
- name - Character - 64 - Mandatory
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
API should perfrom below multi-language validations on the Gender Type data recieved
If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Gender Type and throw an error message. Refer messages section
If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Gender Type as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
If all the above validations are successfull, the API should store the data the the database Gender Type Code should be generated at the back-end for any Gender Type added using a UUID generator
API should store cr_by as the Username of the user who is accessing this API
API should store cr_dtimes as the date-time at which the user is creating the Gender Type
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Update a Gender Type

On receiving a request to update a Gender Type with the input parameters (code, name, lang_code and is_active), the system updates the Gender Type in the Gender Type Database for the code received as per the below steps:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- code - Character - 36 - Mandatory
- name - Character - 64 - Mandatory
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
If all the above validations are successfull, the API should update the data in the database agianst the code received
API should perfrom below multi-language validations on the Gender Type data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Gender Type as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Gender Type details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Check the existence of a Gender in Master Database

On receiving a request to validate the Gender Name with input parameters (Gender Name), the system checks the Gender Name in the Master Database as per the below listed steps:

Validates if the request contains the following input parameters
- Gender Name - Mandatory
If the mandatory input parameters are missing, throws the appropriate message.
Responds to the source with the appropriate message
In case of Exceptions, system triggers relevant error messages

Fetch the List of Gender Types based on a Language Code

On receiving a request to fetch the List of Gender Types with the input parameters (Language Code), the system fetches the List of Gender Types against the Language Code received as per the below listed steps:

Validates if the request contains the following input parameters
- Language Code - Mandatory
If the Language code is missing, responds with all the data.
Validates if the response contains the List of Gender Types with the following attributes
- Gender Code
- Gender Name
- isActive
Responds to the source with the List of Gender Types
In case of Exceptions, system triggers relevant error messages

Document Category

Create Document Category in Master Database

On receiving a request to add Document Category with the input parameters (code, name, descr, lang_code and is_active), the system stores the Document Category in the Database as per the below listed steps:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- name - Character - 64 - Mandatory
- descr - Character - 128 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message.
API should perfrom below multi-language validations on the Document Category data recieved
If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Document Category and throw an error message.
If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Document Category as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
If all the above validations are successfull, the API should store the data the the database
Document Category Code should be generated at the back-end for any Document Category added using a UUID generator
API should store cr_by as the Username of the user who is accessing this API
API should store cr_dtimes as the date-time at which the user is creating the Document Category
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Update a Document Category in the Document Category Master Database

On receiving a request to update a Document Category with the input parameters (code, name, descr, lang_code and is_active), the system update the Document Category in the Document Category Database for the Code received as per the below listed steps:

The API should only be accessible to Global Admin
The API should accept only the below parameters
- code - Character - 36 - Mandatory
- name - Character - 64 - Mandatory
- descr - Character - 128 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message.
If all the above validations are successfull, the API should update the data in the database agianst the code received
API should perfrom below multi-language validations on the Document Category data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Document Category as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Document Category details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Fetch list of Document Categories based on a Language Code

On receiving a request to fetch Document Category Details with the input parameters (Language Code), the system fetches all the Document Categories for the Language Code Received as per the below listed steps:

Validates if all required input parameters have been received as listed below for each specific request
- Language Code - Mandatory
If the mandatory input parameters are missing, responds with all the data.
Validates if the response contains the following attributes for the Document Category Code
- Document Category Code - Mandatory
- Document Category Name - Mandatory
- Document Category Description - Optional
- IsActive - Mandatory
In case of Exceptions, system triggers relevant error messages

Document Type

Create Document Type

On receiving a request to add Document Type with the input parameters (code, name, descr, lang_code and is_active), the system stores the Document Type in the Database

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- name - character (64) - Mandatory
- descr - character (128) - Optional
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
The API should not allow creation of the Document Type if the data is not received in default language
If the data for the Document Type is not received in all the configured languages, the API should allow the Document Type to be created given the Point 2 is satisfied.
The API should activate the Document Type while creation provided data for all the configured languages is received during the initial creation
cr_by should be the Username of the user who is accessing this API
cr_dtimes should be the date-time when the user is creating the Document Type
If the data for all the configured languages is not received, deactivate the Document Type while creation
Responds with an appropriate message for the Document Type created successfully
In case of Exceptions, system triggers relevant error messages

Update a Document Type

On receiving a request to update a Document Type with the input parameters (code, name, descr, lang_code and is_active), the system updates the Document Type in the Document Type Database for the Code received

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- name - character (64) - Mandatory
- descr - character (128) - Optional
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
For the code received in the request, replaces all the data received in the request against the data existing in the Document Type database against the same code
upd_by should be the Username of the user who is accessing this API upd_dtimes should be the date-time when the user updates the Document Type Details
The API should not allow activation of Document Type if the data for the Document Type is not present in all the languages which are configured for a country
While receiving the request for activation, If the Document Type is already Active, the API should throw an error message. Refer messages section.
While receiving the request for deactivation, If the Document Type is already Inactive, the API should throw an error message. Refer messages section.
Deleted record are not be updated
Responds with data not found error if deleted record is received in the request
Responds with the appropriate message for the Document Category updated successfully
In case of Exceptions, system triggers relevant error messages

Delete a Document Type

On receiving a request to delete a Document Type with the input parameters (code), the system updates the is_deleted flag to true in the Document Type Database against the code received

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
Delete all records for the code received
Deleted record are not be deleted again
Responds with data not found error if deleted record is received in the request
Responds with dependency found error if a record to be deleted is used as foreign key in the dependent table
Responds with the Document Category Code for the Document Category deleted successfully
In case of Exceptions, system triggers relevant error messages

Applicant Type - Document Category - Document Type Mapping

Fetch list of Document Categories based on Applicant Type from Master Database

Upon receiving a request to fetch List of Document Categories with the input parameters (Applicant Type Code), the system fetches all the Document Categories for the Applicant Type Code Received

While fetching the list of documents, the system performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- Applicant Type Code - Mandatory
If the mandatory input parameter is missing, responds with the appropriate error message
Validates if the response contains the following attributes for each Document Category Code
- Document Category Code
- Name
- Description
- Language Code
- Is Active
In case of Exceptions, system triggers relevant error messages

Fetch List of Document Category-Document Type mappings based on Applicant Type and a List of Language Codes

Upon receiving a request to fetch List of Document Category-Document Type mappings with input parameters (Applicant Type and List of Language Codes), the system fetches the required data

While fetching the data, the system performs the following steps:

Validates if the request contains the following input parameters
- Applicant Type - Mandatory
- List of Language Codes - Mandatory
If the mandatory input parameters are missing, throws the appropriate message.
Fetches the Document Category-Document Type mapping for all language codes received in response
The response contains the List of Mappings of Document Category and Document Type against each Document Category
Each Document Category contains the below attributes
- Document Category Code
- Name
- Description
- Language Code
- Is Active
Each Document Type contains the below attributes
- Document Type Code
- Name
- Description
- Language Code
- Is Active
In case of Exceptions, system triggers relevant error messages

Delete a Document Category-Type mapping in the Document Category-Type mapping Master Database

On receiving a request to delete a Document Category-Type mapping with the input parameters (doccat_code, doctyp_code), the system updates the is_deleted flag to true in the Document Category-Type mapping Database against the input received

The system performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- doccat_code - character (36) - Mandatory
- doctyp_code - character (36) - Mandatory
Responds with the doc_type Code and doccat_code for the Document Category-Type mapping deleted successfully
In case of Exceptions, system triggers relevant error messages.

Fetch applicant type based on Individual Type Code, Date of Birth, Gender Type Code and Biometric Exception Type

On receiving a request to get Applicant type with input parameters (Individual Type Code, Date of Birth, Gender Type Code and Biometric Exception Type), the system derives the Applicant Type from the input parameter and performs the following steps:

Validates if the request contains the following input parameters
- Individual Type Code - Mandatory
- Date of Birth - Mandatory
- Gender Type Code - Mandatory
- Biometric Exception Type - Optional
Derives the Age Group Type based on following logic
- Child if Age < 5
- Adult if Age >= 5
If the mandatory input parameters are missing, throws the appropriate message
Derives the applicant type as per the define logic
In case of Exceptions, system triggers relevant error messages

Check the mapping of Applicant Type-Document Category Name-Document Type Name

On receiving a request to check the mapping of Applicant Type-Document Category-Document Type mapping parameters (Applicant Type, Document Category Name and Document Type Name), the system checks the mapping and performs the following steps:

Validates if the request contains the following input parameters
- Applicant Type Code
- Document Category Name
- Document Type Name
If the mandatory input parameters are missing, throws the appropriate message.
If the mapping exists, responds with "Valid".
If the mapping does not exist, responds with "Invalid".
In case of Exceptions, system triggers relevant error messages

List of Rejection Reasons

Create a Rejection Reason in Reason List Master Database

Upon receiving a request to add a Reason with the input parameters (code, name, descr, rsncat_code, lang_code and is_active), the system stores the Reason in the Database

The system performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- code - character (64) - Mandatory
- descr - character (256) - Mandatory
- rsncat_code - character (36) – Mandatory (The parameter rsncat_code refers to a Language stored in Language Masterdata)
- lang_code - character (3) – Mandatory (The parameter lang_code refers to a Language stored in Language Masterdata)
- is_active - boolean - Mandatory
Validates if the response contains the following attributes for a Reason Category Code added
- Code
- Language Code
- Rsncat_code (Reason Category Code)
Responds to the source with the appropriate message.
In case of Exceptions, system triggers relevant error messages.

Fetch the requested list of reasons based on Reason Category Code and Language Code

Upon receiving a request to Fetch the requested List of Reasons with the required input parameters (Reason 1. Category Code, Language Code), the system fetches the requested List of reasons stored against the Reason Category Code and Language Code received.

The system performs the following steps:

Validates if the request contains the following input parameters
- Language Code - Mandatory
- Reason Category Code - Mandatory
If either of the mandatory input parameters is missing, responds with the appropriate message as define below in message sections
Validates if the response contains the:
- Requested list based on the requested Language Code and Reason Category Code
- List of Reasons with the corresponding attributes for the list
  - Reason ID
  - Reason Name (per Reason ID)
  - Language Code
  - Reason Category Code
  - IsActive
Responds to the source with the relevant List of Reasons, as per the stated business rules
In case of Exceptions, system triggers relevant error messages as listed below

List of Languages

Create List of Languages

After receiving a request to add Language Details with the input parameters (code, name, family, native_name and is_active), the system stores the Language Details in the Database and performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (3) - Mandatory
- name - character (64) - Mandatory
- family - character (64) - Optional
- native_name - character (64) - Optional
- is_active - boolean - Mandatory
Responds with the Language Code for the language successfully created
In case of Exceptions, system triggers relevant error messages

Fetch the List of Languages

After receiving a request to fetch the List of Languages, the system fetches the List of Languages and performs the following steps:

Validates if the response contains the List of all Languages with the following attributes
- Language Code - Mandatory
- Language Name - Mandatory
- IsActive – Mandatory
Responds to the source with the List of Languages
In case of Exceptions, system triggers relevant error messages

Update and Delete a Language in the List of Languages Master Database

Update

After receiving a request to update a Language with the input parameters (code, name, family, native_name and is_active), the system updates the Language Details in the List of languages Database for the Code received in request

The system performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (3) - Mandatory
- name - character (64) - Mandatory
- family - character (64) - Optional
- native_name - character (64) - Optional
- is_active - boolean - Mandatory
For the Code received in the request, replaces all the data received in the request against the data existing in the List of languages database against the same code.
Deleted record are not updated
Responds with data not found error if deleted record is received in the request
Responds with the Language Code for the language successfully updated
In case of Exceptions, system triggers relevant error messages

Delete

After receiving a request to delete a Language with the input parameters (code), the system updates the is_deleted flag to true in the List of languages Database against the code received in request

The system performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (3) - Mandatory
Deleted record should not be deleted again
Responds with data not found error if deleted record is received in the request
Responds with the Language Code for the language successfully deleted
In case of Exceptions, system triggers relevant error messages.

List of Titles

Create a Title

On receiving a request to add a Title (e.g., MR., Mrs.) with the input parameters (code, name, descr, lang_code and is_active), the system stores the Title in the Database and performs the following steps:

The API should only be accessible to Global Admin
The API should accept only the below parameters
- name - Character - 64 - Mandatory
- descr - Character - 128 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
API should perfrom below multi-language validations on the Title data recieved
If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Title and throw an error message. Refer messages section
If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Title as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
If all the above validations are successfull, the API should store the data the the database
Title Code should be generated at the back-end for any Title added using a UUID generator
API should store cr_by as the Username of the user who is accessing this API
API should store cr_dtimes as the date-time at which the user is creating the Title
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Update a Title

On receiving a request to update a Title with the input parameters (code, name, descr, lang_code and is_active), the system updates the Title in the Title Database for the code received and performs the following steps:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- code - Character - 36 - Mandatory
- name - Character - 64 - Mandatory
- descr - Character - 128 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
If all the above validations are successfull, the API should update the data in the database agianst the code received
API should perfrom below multi-language validations on the Title data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Title as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Title details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Fetch the List of Titles

On receiving a request to fetch Title Details with the input parameters (Language Code), the system fetches all the Titles with all the attributes for the Language Code Received

The system performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- Language Code - Mandatory
If the mandatory input parameters are missing, responds with all the data.
Validates if the response contains List of Titles against the received Language Code along with the following attributes for the Title Code
- Title Code - Mandatory
- Title Name - Mandatory
- Title Description - Optional
- IsActive - Mandatory
In case of Exceptions, system triggers relevant error messages

Template File Format

Create Template File Format

On receiving a request to add Template File Format with the input parameters (code, descr, lang_code and is_active), the system stores the Template File Format in the Database and performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- descr - character (256) - Mandatory
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
Validates if the response contains the following attributes for a Template File Format added
- Code
- Language Code
Responds with the Template File Format Code and Language Code for the Template File Format created successfully
In case of Exceptions, system triggers relevant error messages.

Create Template File Format

Update and Delete a Template File Format in Template File Format Master Database

Update

On receiving a request to update a Template File Format with the input parameters (code, descr, lang_code and is_active), the system updates the Template File Format in the Template File Format Database for the Code received

While updating the Template File Format, the system performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- descr - character (256) - Optional
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
For the code received in the request, replaces all the data received in the request against the data existing in the Template File Format database against the same code.
Deleted record are not updated
Responds with data not found error if deleted record is received in the request
Responds with the Template File Format Code and Language Code for the Template File Format updated successfully
In case of Exceptions, system triggers relevant error messages

Delete

On receiving a request to delete a Template File Format with the input parameters (code), the system updates the is_deleted flag to true in the Template File Format Database against the code received

While deleting the Template File Format, the system performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
Delete all records for the code received
Deleted record are not deleted again
Responds with data not found error if deleted record is received in the request
Responds with dependency found error (Refer Acceptance criteria) if a record to be deleted is used as foreign key in the dependent table
Responds with the Template File Format Code for the Template File Format deleted successfully
In case of Exceptions, system triggers relevant error messages.

List of Template Types

MOSIP system can create Template Type in the Master Database.

Upon receiving a request to add Template Type (e.g., SMS Notification template - New Registration) with the input parameters (code, descr, lang_code and is_active), the system stores the Template Type in the Database and performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- descr - character (256) - Mandatory
- lang_code - character (3) - Mandatory
- is_active - boolean – Mandatory
Responds with the Template Type Code and Language Code for the Template Type created successfully
This component also restricts the bulk creation of Master Database
In case of Exceptions, system triggers relevant error messages as listed below.

List of Templates

Create Template

On receiving a request to add a Template with the input parameters (id, name, descr, file_format_code, model, file_txt, module_id, module_name, template_typ_code, lang_code and is_active), the system stores the Template in the Database and performs the following steps:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- name - Character - 128 - Mandatory
- descr - Character - 256 - Optional
- file_format_code - 36 - Mandatory
- model - Character - 128 - Optional
- file_txt - Character - 4086 - Mandatory
- module_id - Character - 36 - Mandatory
- module_name - Character - 128 - Mandatory
- template_typ_code - Character - 36 - Mandatory
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message.
'file_format_code' received should be from list of 'codes' from 'template_file_format' masterdata table
- If not, the API should throw an error.
'template_typ_code' received should be from list of 'codes' from 'template_type' masterdata table
- If not, the API should throw an error.
If all the above validations are successfull, the API should update the data in the database agianst the id received
API should perfrom below multi-language validations on the Template data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Template as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Template details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Fetch Template based on a Template Type and a Language Code

On receiving a request to fetch a Template with the input parameters (Template Type Code and List of Language Code), the system fetches the Template for the Template Type Code and all Language Codes received

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- Template Type Code - Mandatory
- List of Language Code - Mandatory
If the mandatory input parameters are missing, throws the appropriate message. Refer "Messages" section.
Response must contain templates for all the language codes received in the input parameter
Validates if the response contains the Template along with the following attributes
- Template Type Code - Mandatory
- Template - Mandatory
- IsActive
In case of Exceptions, system triggers relevant error messages

Update a Template

On receiving a request to update a Template with the input parameters (id, name, descr, file_format_code, model, file_txt, module_id, module_name, template_typ_code, lang_code and is_active), the system updates the Template in the Template Database for the id received and performs the following steps:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- id - Character - 36 - Mandatory
- name - Character - 128 - Mandatory
- descr - Character - 256 - Optional
- file_format_code - 36 - Mandatory
- model - Character - 128 - Optional
- file_txt - Character - 4086 - Mandatory
- module_id - Character - 36 - Mandatory
- module_name - Character - 128 - Mandatory
- template_typ_code - Character - 36 - Mandatory
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
'file_format_code' received should be from list of 'codes' from 'template_file_format' masterdata table
- If not, the API should throw an error.
'template_typ_code' received should be from list of 'codes' from 'template_type' masterdata table
- If not, the API should throw an error.
If all the above validations are successfull, the API should update the data in the database agianst the id received
API should perfrom below multi-language validations on the Template data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Template as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Template details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

List of Blacklisted Words

Create Blacklisted Words

Upon receiving a request to add a Blacklisted Word with the input parameters (code, name, descr, lang_code and is_active), the system stores the Blacklisted Word in the Database and performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- word - character (128) - Mandatory
- descr - character (256) - Optional
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
cr_by should be the Username of the user who is accessing this API
cr_dtimes should be the date-time when the user is creating the Blacklisted Word
Responds with the appropriate message for the Device created successfully
The component should restricts the bulk creation of Master Database
In case of Exceptions, system triggers error messages as received from the Database.

Update a Blacklisted Word

Upon receiving request to update a Blacklisted Word with the input parameters (code, name, descr, lang_code and is_active), the system updates the Blacklisted Word in the Blacklisted Word Database for the code received and performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- word- character (128) - Mandatory
- descr - character (256) - Optional
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
For the code received in the request, replaces all the data received in the request against the data existing in the Blacklisted Word database against the same code
upd_by should be the Username of the user who is accessing this API
upd_dtimes should be the date-time when the user updates the Blacklisted Word Details
Deleted record are not updated
Responds with data not found error if deleted record is received in the request
Responds with the appropriate message for the Blacklisted word updated successfully
In case of Exceptions, system triggers relevant error messages as listed below

Delete a Blacklisted Word

Upon receiving a request to delete a Blacklisted Word with the input parameters (code), the system updates the is_deleted flag to true in the Blacklisted Word Database against the code received and performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- word- int - Mandatory
Deleted record are not deleted again
Responds with data not found error if deleted record is received in the request
Responds with the Word for the Blacklisted word deleted successfully
In case of Exceptions, system triggers relevant error messages as listed below

Fetch List of Blacklisted words based on a Language Code

Upon receiving a request to Fetch the List of Blacklisted words with input parameters (Language Code), the system fetches the List of Blacklisted words against the Language Code received

While fetching the black listed words, the system performs the following steps:

Validates if the request contains the following input parameters
- Language Code - Mandatory
If the mandatory input parameters are missing, throws the appropriate message.
Validates if the response contains the List of Blacklisted words against Language Code and the corresponding attributes for the Blacklisted word
- Blacklisted Word
- IsActive
In case of Exceptions, system triggers relevant error messages.

List of Reason Categories

MOSIP system can create a Reason Category in Master Database

Upon receiving a request to add Reason Category with the input parameters (code, name, descr, lang_code and is_active), the system stores the Reason Category in the Database and performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- name - character (64) - Mandatory
- descr - character (256) - Mandatory
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
Validates if the response contains the following attributes for a Reason Category added
- Code
- Language Code
Responds with the Reason Category code and Language Code for the Reason Category created successfully
In case of Exceptions, system triggers relevant error messages as listed below

List of Applications

Create a List of Applications

Upon receiving a request to add Application with the input parameters (code, name, descr, lang_code and is_active), the system stores the Application in the Database

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- name - character (64) - Mandatory
- descr- character (256) - Mandatory
- lang_code - character (3) – Mandatory (The parameter lang_code refers to a Language stored in Language Masterdata. Refer)
- is_active - boolean - Mandatory
Validates if the response contains the following attributes for an Application added
- Code
- Language Code
Responds with the Application ID and Language Code for the Application created successfully
In case of Exceptions, system triggers relevant error messages as listed below

Fetch List of Applications based on received input parameter

Fetch the List of all Applications

Upon receiving a request to Fetch List of Applications, the system fetches all the List of Applications and performs the following steps:

Validates if the response contains the following attributes for each Application
- Application ID
- Application Detail
- IsActive
The response must contain the list of applications in all the languages present in the Database
Responds to the source with all the Application attributes.

Fetch the Application detail based on a Language Code and Application ID

Upon receiving a request to Fetch List of Applications with the required input parameters (Application ID, Language Code), the system fetches the Application Detail based on the Application ID and Language Code received

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- Application ID - Mandatory
- Language Code - Mandatory
Responds with the Application Data against the Application ID and Language Code Received
Validates if the response contains the following attributes for each Application
- Application ID
- Application Detail
- IsActive
Responds to the source with the Application Detail
If the mandatory input parameters are missing, responds with all the data.
In case of Exceptions, system triggers relevant error messages as listed below

List of ID Types

Create an ID type

Upon receiving a request to add an ID Type with the input parameters (code, name, descr, lang_code and is_active), the system stores the ID Type in the Database

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- code - character (36) - Mandatory
- code - character (64) - Mandatory
- descr - character (256) - Mandatory
- lang_code - character (3) – Mandatory (refers to a Language stored in Language Masterdata)
- is_active - boolean - Mandatory
Validates if the response contains the following attributes for an ID Type added
- Code
- Language Code
Responds with the ID Type Code and Language Code for the ID type created successfully
In case of Exceptions, system triggers relevant error messages as listed below.

Fetch the List of ID Types based on Language Code

Upon receiving a request to fetch the List of ID Types with input parameters (Language Code), the system fetches the List of ID Types against the Language Code Received

Refer below for the process:

Validates if the request contains the following input parameters
- Language Code - Mandatory
If the mandatory input parameters are missing, throws the appropriate message. Refer "Messages" section below.
Validates if the response contains the List of ID Types with the following attributes
- ID Type Name
- ID Type Code
- IsActive
In case of Exceptions, system triggers relevant error messages.

User Details

Upon receiving a request to fetch the user history record with input parameters (User ID and Date Timestamp), the system fetches all the attributes of the user from the history table and performs the following steps:

Validates if all required input parameters have been received as listed below for each specific request.
- User ID - Mandatory
- Date Timestamp - Mandatory
The record fetched are the latest record existing on or before the date received in the input parameter.
If the mandatory input parameters are missing, then the system triggers the appropriate message.
Response will contain all the attributes for the user including the Active/Inactive status.
In case of exceptions, system triggers relevant error messages.

Fetch RID based on a User ID

Receive request to retrieve RID based on input parameter (User ID, App ID)
- User ID and App ID both will be mandatory
Fetch the RID
Respond to the source with the fetched data
Respond with error 'User doesn't exist' if no user is found for User ID received

Document Type to Category Mapping

Create a mapping record of Document Type and Document Category in Valid Document Mapping Master Database

Upon receiving a request to add a mapping of Document Type and Document Category with the input parameters (doctyp_code, doccat_code) the system stores the Mapping of Document type and Document category in the Database

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- doctyp_code - character - 36 - mandatory
- doccat_code - character - 36 - mandatory
If the mapping does not exist
- is_active flag should be stored as true when the mapping is created
- Store the default language code against the mapping
- cr_by should be the User ID of the user who is accessing this API
- cr_dtimes should be the date-time at which the user is creating the Document Category - Document Type Mapping
if the mapping already exist but is in inactive state
- Update the is_acitve flag as “True”
- Updated the upd_by and upd_dtimes values against the mapping
If the mapping already exist in active state, throw appropriate error message
Responds with the appropriate message for the mapping being created successfully
The API restricts the bulk creation of Master Data
In case of Exceptions, system triggers error messages as received from the Database.

Remove a mapping record of Document Type and Document Category in Valid Document Mapping Master Database

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- doctyp_code - character - 36 - mandatory
- doccat_code - character - 36 - mandatory
If the Document Type is already un-mapped from Document Category, throw an appropriate error message
upd_by should be the User ID of the user who is accessing this API
upd_dtimes should be the date-time when the Document Category - Document Type Mapping is being updated
Change the Is_active flag to “False” for removing the mapping
Responds with the appropriate message for the mapping being created successfully
The API restricts the bulk creation of Master Data
In case of Exceptions, system triggers error messages as received from the Database.

Working and Non-Working Days

API should be able to fetch working days for a Center based on a Center ID

Refer below for the process:

The API should support taking Center ID and Language Code as an mandatory input parameter
The API should respond to the source with all the days of the week for the Center in the language received
Each day should have an attribute marking whether the day is a working day or off-work day
Each day should have an attribute defing the calenday order of days of the week

If the working days are not defined against the Center, the API should fetch the globally defined working and non-working days.

The API should throw error messages in scenarios mentioned in error messages section.

Exceptional Holidays for a Center

API should be able to fetch any defined exceptional holiday dates for a Center based on a Center ID

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- Center ID - character - 10 - mandatory
API should respond to the source with all the exceptional holiday dates for the Center ID received
API should throw relevant error messages in any error scenarios

Registration Management

Registration Center Type

Create Registration Center Type

On receiving a request to add Registration Center Type with the input parameters (code, name, descr, lang_code and is_active), the system stores the Registration Center Type in the Database

Refer below for the process:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- name - Character - 64 - Mandatory
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
API should perfrom below multi-language validations on the Gender Type data recieved
If, the data is recieved in secondary language and the data for primary language is not present in the database, the 8. API should not allow creation of the Gender Type and throw an error message.
If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Gender Type as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
If all the above validations are successfull, the API should store the data the the database
Gender Type Code should be generated at the back-end for any Gender Type added using a UUID generator
API should store cr_by as the Username of the user who is accessing this API
API should store cr_dtimes as the date-time at which the user is creating the Gender Type
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Update a Registration Center Type

On receiving a request to update a Registration Center Type with the input parameters (code, name, descr, lang_code and is_active), the system Updates the Registration Center Type Details in the Registration Center Type Database for the Code received

Refer below for the process:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- code - Character - 36 - Mandatory
- name - Character - 64 - Mandatory
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
If all the above validations are successfull, the API should update the data in the database agianst the code received
API should perfrom below multi-language validations on the Gender Type data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Gender Type as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Gender Type details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Registration Center

Create a Registration Center

Upon receiving a request to add Registration Center with the input parameters, the system Stores the Registration Center in the Database

Refer below for the process:

The system validates if all required input parameters have been received as listed below for each specific request
- name - character (128) - mandatory
- cntrtyp_code - character (36) - mandatory
- addr_line1 - character (256) - mandatory
- addr_line2 - character (256) - optional
- addr_line3 - character (256) - optional
- latitude - character (32) - mandatory
- longitude - character (32) - mandatory
- location_code - character (36) - mandatory
- contact_phone - character (16) - optional
- contact_person - character (256) - optional
- working_hours - character (32) - mandatory
- per_kiosk_process_time - time - mandatory
- center_start_time - time - mandatory
- center_end_time - time - mandatory
- lunch_start_time - time - optional
- lunch_end_time - time - optional
- holiday_loc_code - character (36) - mandatory
- timezone - string (128) - optional
- lang_code - character (3) - mandatory
- zone_code - character (36) - mandatory
is_active should be set as “False”
number_of_kiosks should be kept as zero for creation of a Registration Center
center_end_time should not be before the center_start_time
Latitude and Longitude should be in format of “(-)XX.XXXX”
- Latitude and Longitude should contain at-least 4 digits after decimal
If lunch_end_time and lunch_start_time is sent in the request,
- lunch_end_time should not be before the lunch_start_time
The Zone received should be either same as the Zone mapped of the Administrator or a child zone of the Administrator's Zone
cr_by should be the Username of the user who is accessing this API
cr_dtimes should be the date-time at which the user is creating the Registration Center
Center ID should be generated by calling the Registration Center ID Generator and stored against every new Center Created
If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Registration Center
Responds with the appropriate message for the Registration Center created successfully
History record should be stores for every creation of a new Registration Center
The API should restricts the bulk creation of Master Data
In case of Exceptions, system triggers error messages as received from the Database.

Update a Registration Center

On receiving a request to update a Registration Center with the input parameters, the system updates the Registration Center Details in the List of Registration Center Database for the center_id received

Refer below for the process:

The system validates if all required input parameters have been received as listed below for each specific request
- center_id - character (36) - mandatory
- name - character (128) - mandatory
- cntrtyp_code - character (36) - mandatory
- addr_line1 - character (256) - mandatory
- addr_line2 - character (256) - optional
- addr_line3 - character (256) - optional
- latitude - character (32) - mandatory
- longitude - character (32) - mandatory
- location_code - character (36) - mandatory
- contact_phone - character (16) - optional
- contact_person - character (256) - optional
- working_hours - character (32) - mandatory
- per_kiosk_process_time - time - mandatory
- center_start_time - time - mandatory
- center_end_time - time - mandatory
- lunch_start_time - time - optional
- lunch_end_time - time - optional
- holiday_loc_code - character (36) - mandatory
- timezone - string (128) - optional
- lang_code - character (3) - mandatory
- zone_code - character (36) - mandatory
- is_active - boolean - mandatory
For the center_id received in the request, replaces all the data received in the request against the data existing in the List of Registration Center database against the same center_id.
All the mandatory input parameters should be present
center_end_time should not be before the center_start_time
Latitude and Longitude should be in format of “(-)XX.XXXX”
- Latitude and Longitude should contain at-least 4 digits after decimal
If lunch_end_time and lunch_start_time is sent in the request,
- lunch_end_time should not be before the lunch_start_time
The Zone received should be either same as the Zone mapped of the Administrator or a child zone of the Administrator's Zone
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Registration Center as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
upd_by should be the Username of the user who is accessing this API
upd_dtimes should be the date-time at which the user is creating the Registration Center
History record should be stores for every modification of a Registration Center
Responds with the Registration Center Code and Language Code for the Registration Center updated successfully
In case of Exceptions, system triggers relevant error messages

Decommission a Registration Center

Upon receiving a request to Decommission a Registration Center with the input parameters (center_id), the system updates the is_deleted flag to true in the List of Registration Center Database against the center_id received

Refer below for the process:

Validate if all required input parameters have been received as listed below for each specific request
- center_id - character (36) - Mandatory
Change the “is_Deleted” flag against Registration Center ID to “True”
Change the “is_Active” flag to “False” against the Registration Center.
upd_by should be the Username of the user who is accessing this API
del_dtimes should be the date-time when the Registration Center is being decommissioned
Validate if any Machine, Devices or Users are mapped to the Registration Center
- If any Machine, Device or User is assigned to the Registration Center, do no decommission the Registration Center, throw an appropriate error message. Refer “Messages Section”.
The User accessing the API should only be able to decommission a Center under its administrative zone only
Responds with the appropriate message for the Registration Center decommissioned successfully
In case of Exceptions, system triggers relevant error messages

Fetch Registration Center details based on a Registration Center ID and Language Code.

On receiving a request to fetch Registration Center Details with the input parameters (Registration Center ID and Language Code), the system fetches all the Registration Center attributes for the Registration Center ID and Language Code received. The system only fetches active Registration Centers.

Refer below for the process:

While fetching the registration center details the system validates if all required input parameters have been received as listed below for each specific request
- Registration Center ID - Mandatory
- Language Code - Mandatory
If the mandatory input parameters are missing, throws the appropriate message.
System also validates if the response contains the following attributes for the Registration Center ID along with values as applicable
- Registration Center ID
- Registration Center Name
- Longitude
- Latitude
- IsActive
- Center Type Code
- Address
- Working Hours
- Contact Number
- No. of kiosk
- Per kiosk Processing time
- Starting time
- End time
- IsActive
In case of Exceptions, system triggers relevant error messages.

Fetch Registration Center record based on a Registration center ID, Date and Language Code from the Registration Center Updation/Creation History table

On receiving a request to fetch Registration Center Creation/Updation History Detail with the input parameters (Registration Center ID, Date and Language Code), the system fetches all the attributes of Registration Center from the history table for the Registration Center ID, Date and Language Code received

Refer below for the process:

While fetching registration center records the system validates if all required input parameters have been received as listed below for each specific request
- Registration Center ID - Mandatory
- Date - Mandatory
- Language Code - Mandatory
The record fetched is the latest record existing on or before the date received in the input parameter
If the mandatory input parameters are missing, system throws the appropriate message.
Validates if the response contains the following attributes for the Registration Center ID along with values as applicable
- Registration Center ID
- Registration Center Name
- Longitude
- Latitude
- IsActive
- Center Type Code
- Address
- Working Hours
- Contact Number
- No. of kiosk
- Per koisk Processing time
- Starting time
- End time
- IsActive
In case of Exceptions, system triggers relevant error messages.

Fetch Registration Center details based on a Location Code and a Language Code

Upon receiving a request to fetch the List of Registration Centers with the input parameter (Location Code and Language Code), the system fetches the list of all the Registration Centers against the Location Code and Language Code received with all the attributes for each Registration Center. The system only fetches active Registration Centers.

Refer below for the process:

While fetching the registration center details the system validates if all required input parameters have been received as listed below for each specific request
- Location Code
- Language Code
If the mandatory input parameters are missing, throws the appropriate message
Validates if the response contains all the Registration Center against the Location Code received with the following attributes for the Registration Centers
- Registration Center ID
- Registration Center Name
- Longitude
- Latitude
- IsActive
- Center Type
- Address
- Working Hours
- Contact Number
- No. of kiosk
- Per koisk Processing time
- Starting time
- End time
- IsActive
In case of Exceptions, system triggers relevant error messages

Fetch Registration Center details based on a Longitude and a Latitude, Proximity Distance and Language Code

On receiving a request to fetch the List of Registration Centers with the input parameter (Longitude and Latitude, Proximity distance and Language Code), the system fetches the List of Registration Centers against the input parameters received. The system only fetches active Registration Centers.

Refer below for the process:

While fetching the registration center details the system validates if all required input parameters have been received as listed below for each specific request
- Longitude
- Latitude
- Proximity Distance
- Language Code
If the mandatory input parameters are missing, throw the appropriate message
The responses contain the list of all the Registration Centers in the radius of Proximity distance radius of the Longitude and the Latitude received with all the attributes for each Registration Center
System fetches the record against the Language Code Received
Validates if the response contains all the Registration Center against the Longitude and the Latitude and the Language Code received with the following attributes for the Registration Centers
- Registration Center ID
- Registration Center Name
- Longitude
- Latitude
- IsActive
- Center Type
- Address
- Working Hours
- Contact Number
- No. of kiosk
- Per koisk Processing time
- Starting time
- End time
- IsActive
In case of Exceptions, system triggers relevant error messages

Fetch the List of Registration Centers based on Location Hierarchy Level, text input and a Language Code

Upon receiving a request to fetch the List of Registration centers with input parameters (Location Hierarchy Level, Text Input and a Language Code), the system fetches the List of Registration centers. The system only fetches active Registration Centers.

Refer below for the process:

While fetching the list of registration centers the system validates if the request contains the following input parameters
- Location Hierarchy Level - Mandatory
- Text Input - Mandatory
- Language Code - Mandatory
If the mandatory input parameters are missing, throws the appropriate message
The list of registration center is fetched based on the combination of Location Hierarchy level and Text received.
System also fetches the list based on the language code received.
The response contains below mentioned attributes for each registration center
- Registration Center ID
- Registration Center Name
- Longitude
- Latitude
- IsActive
- Center Type Code
- Address
- Working Hours
- Contact Number
- No. of kiosk
- Per kiosk Processing time
- Starting time
- End time
- IsActive
In case of Exceptions, system triggers relevant error messages.

Validates whether a Registration Center is under working hours based on a timestamp received

On receiving a request to fetch Registration Center Details with the input parameters (Registration Center ID and Date-Timestamp), the system determines the status of the Registration center as per the logic defined.

Refer below for the process:

While determining the status of registration center the system validates if all required input parameters have been received as listed below for each specific request
- Registration Center ID - Mandatory
- Date-Timestamp - Mandatory
If the mandatory input parameters are missing, system throws the appropriate message.
Responds with "Accept" message if both the following conditions are met:
- The Registration Center corresponding to the Registration Center ID received must be not on a holiday on the date received in the input parameter.
- The Timestamp received in the input parameter must be greater the Registration Center Opening time and Less than or equal to Closing time + 1 Hour.
Responds with the reject scenario if the above two conditions together are not met.
E.g., If the Registration center in not on a holiday and its opening and closing time is (9:00 AM to 5:00 PM). Find the sample response below for different timestamp received.
- Timestamp - 4:00 PM - Accepted
- Timestamp - 5:00 PM - Accepted
- Timestamp - 6:00 PM - Accepted
- Timestamp - 6:01 PM - Rejected
In case of Exceptions, system triggers relevant error messages

List of Machine Types

Creation of a Machine Type

Upon receiving a request to add Machine Type (e.g., Dongle/Desktop) with the input parameters (code, name, descr, lang_code and is_active), the system stores the Machine Type in the Database

Refer below for the process:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- name - Character - 64 - Mandatory
- descr - Character - 128 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
API should perfrom below multi-language validations on the Machine Type data recieved
If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Machine Type and throw an error message. Refer messages section
If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Machine Type as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
If all the above validations are successfull, the API should store the data the the database
Machine Type Code should be generated at the back-end for any Machine Type added using a UUID generator
API should store cr_by as the Username of the user who is accessing this API
API should store cr_dtimes as the date-time at which the user is creating the Machine Type
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Update of a Machine Type

This API should only be accessible to Global Admin
The API should accept only the below parameters
- code - Character - 36 - Mandatory
- name - Character - 64 - Mandatory
- descr - Character - 128 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
If all the above validations are successfull, the API should update the data in the database agianst the code received
API should perfrom below multi-language validations on the Machine Type data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Machine Type as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Machine Type details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

List of Machine Specifications

Create Machine Specifications

On receiving a request to add Machine Specifications with the input parameters (name, brand, model, mtyp_code, min_driver_ver, descr, lang_code and is_active) the system stores the Machine Specifications in the Database

Refer below for the process:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- name - Character - 64 - Mandatory
- brand - Character - 32 - Mandatory
- model - Character - 16 - Mandatory
- mtyp_code - Character - 36 - Mandatory
- min_driver_version - Character - 16 - Mandatory
- descr - Character - 256 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
mtyp_code received should be from list of 'codes' from machine_type masterdata table
- If not, the API should throw an error. Refer messages section
API should perfrom below multi-language validations on the Machine Specification data recieved
If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Machine Specification and throw an error message. Refer messages section
If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Machine Specification as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
If all the above validations are successfull, the API should store the data the the database
Machine Specification Id should be generated at the back-end for any Machine Specification added using a UUID generator
API should store cr_by as the Username of the user who is accessing this API
API should store cr_dtimes as the date-time at which the user is creating the Machine Specification
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Update a Machine Specification

On receiving a request to update a Machine Specification with the input parameters (id, name, brand, model, mtyp_code, min_driver_ver, descr, lang_code and is_active), the system updates the Machine Specification Details in the Machine Specification Database for the id received

This API should only be accessible to Global Admin
The API should accept only the below parameters
- id - Character - 36 - Mandatory
- name - Character - 64 - Mandatory
- brand - Character - 32 - Mandatory
- model - Character - 16 - Mandatory
- mtyp_code - Character - 36 - Mandatory
- min_driver_version - Character - 16 - Mandatory
- descr - Character - 256 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
- mtyp_code received should be from list of 'codes' from machine_type masterdata table
If not, the API should throw an error.
If all the above validations are successfull, the API should update the data in the database agianst the id received
API should perfrom below multi-language validations on the Machine Specification data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Machine Specification as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Machine Specification details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

List of Machines

Create a Machine in Master Database

On receiving a request to add Machine with the input parameters, the system Stores the Machine Details in the Database

Refer below for the process:

While creating the machine IDs the system validates if all required input parameters have been received as listed below for each specific request
- machine_id - character (36) - mandatory
- name - character (64) - mandatory
- mac_address - character (64) - mandatory
- serial_num - character (64) - mandatory
- ip_address- character (17) - optional
- validity_end_dtimes - timestamp
- mspec_id - character (36) - mandatory
- lang_code - character (3) - mandatory
- zone_code - character (36) - mandatory
- is_active - boolean - mandatory
The Zone received should be either same as the Zone mapped of the Administrator or a child zone of the Administrator's Zone
cr_by should be the Username of the user who is accessing this API
cr_dtimes should be the date-time at which the user is creating the Machine
Machine ID should be generated by calling the Machine ID Generator and stored against every new Machine Created
If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Machine and throw an error message. Refer messages section
If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Machine as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
If the request has been received for Deactivating an active machine, and the machine is mapped to a Registration Center, reduce the number of kiosk by 1 for that Registration Center in the Registration Center Master DB.
If the request has been received for Activating an Inactive machine, and the machine is mapped to a Registration Center, increase the number of kiosk by 1 for that Registration Center in the Registration Center Master DB.
Responds with the appropriate message for the Machine created successfully
History record should be stores for every creation of a new Machine
The API should restricts the bulk creation of Master Data
In case of Exceptions, system triggers error messages as received from the Database.

Update a Machine in the List of Machines Master Database

On receiving a request to update a Machine with the input parameters, the system Updates the Machine Details in the List of Machines Database for the machine_id received

Refer below for the process:

While updating the machine ID the system Validates if all required input parameters have been received as listed below for each specific request
- machine_id - character (36) - mandatory
- name - character (64) - mandatory
- mac_address - character (64) - mandatory
- serial_num - character (64) - mandatory
- ip_address- character (17) - optional
- validity_end_dtimes - timestamp
- mspec_id - character (36) - mandatory
- lang_code - character (3) - mandatory
- zone_code - character (36) - mandatory
- is_active - boolean - mandatory
For the machine_id received in the request, replaces all the data received in the request against the data existing in the List of Registration Center database against the same machine_id.
All the mandatory input parameters should be present
The Zone received should be either same as the Zone mapped of the Administrator or a child zone of the Administrator's Zone
The API should not allow activation of Machine if the data for the Machine is not present in all the languages which are configured for a country
If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Machine as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
upd_by should be the Username of the user who is accessing this API
upd_dtimes should be the date-time at which the user is creating the Machine
History record should be stores for every modification of a Machine
Responds with the Registration Center Code and Language Code for the Machine updated successfully
In case of Exceptions, system triggers relevant error messages

Decommission a Machine in the List of Machines Master Database

On receiving a request to decommission a Machine with the input parameters (machine_id), the system Updates the is_deleted flag to true in the List of Machines Database against the machine_id received

Refer below for the process:

While deleting the machine IDs the system Validates if all required input parameters have been received as listed below for each specific request
- machine_id - character (36) - Mandatory
Change the “is_Deleted” flag against Machine ID to “True”
Change the “is_Active” flag to “False” against the Machine.
upd_by should be the Username of the user who is accessing this API
del_dtimes should be the date-time when the Machine is being decommissioned
Validate if the Machine is mapped to the Registration Center
- If yes, do no decommission the Machine, throw an appropriate error message. Refer “Messages Section”.
The User accessing the API should only be able to decommission a Machine under its administrative zone only
Responds with the appropriate message for the Machine decommissioned successfully
In case of Exceptions, system triggers relevant error messages

Fetch Machine Registration/Updation History detail based on a Machine ID and Language Code

Upon receiving a request to fetch Machine History Registration/Updation Detail with the input parameters (Machine ID, Date and Language Code), the system Fetches all the attributes of Machine from the history table for the Machine ID, Date and Language Code received

The record fetched is the latest record existing on or before the date received in the input parameter

Refer below for the process:

While fetching the machine registration and updation history the system Validates if all required input parameters have been received as listed below for each specific request
- Machine ID - Mandatory
- Date - Mandatory
- Language Code - Mandatory
If the mandatory input parameters are missing, throws the appropriate message
Validates if the response contains the following attributes for the Machine ID and Language Code Received
- Machine ID
- Machine Name
- Mac Address
- IP Address
- Serial Number
- Machine Spec ID
- IsActive
In case of Exceptions, system triggers relevant error messages

Fetch Machine Details based on a Machine ID and a Language Code

On receiving a request to Fetch Machine Details with the input parameters (Machine ID and Language Code), the system Fetches all the Machine attributes for the Machine ID and the Language Code Received

Refer below for the process:

While fetching the machine IDs the system Validates if all required input parameters have been received as listed below for each specific request
- Machine ID - Mandatory
- Language Code
If the request has come for fetching all the machine details, responds with all the list of machines
If the mandatory input parameters are missing, throws the appropriate message.
Validates if the response contains the following attributes for the Machine ID
- Machine ID
- Machine Name
- Mac Address
- IP Address
- Serial Number
- Machine Spec ID
- IsActive
In case of Exceptions, system triggers relevant error messages.

Mappings of Registration Center, Machine and User Mappings

Create a mapping record of Center, User and Machine in Center-User-Machine Mapping Master Database

On receiving a request to add a mapping of Center, User and Machine with the input parameters (regcntr_id, usr_id, machine_id and is_active), the system Stores the Mapping of Center, User and Machine in the Database

Refer below for the process:

While mapping the system Validates if all required input parameters have been received as listed below for each specific request
- regcntr_id - character (10) - Mandatory
- usr_id- character (36) - Mandatory
- machine_id - character (10) - Mandatory
- is_active - boolean - Mandatory
Responds with the Center ID, Machine ID ad User ID for the Center, User and Machine mapping created successfully
The component restricts the bulk creation of Master Data
In case of Exceptions, system triggers error messages as received from the Database.

Delete a Center-Machine-User mapping in the Center-Machine-User mapping Master Database

On receiving a request to delete a Center-Machine-User mapping with the input parameters (regcntr_id, machine_id, usr_id), the system Updates the is_deleted flag to true in the Center-Machine-User mapping Database against the input received

Refer below for the process:

While deleting the system Validates if all required input parameters have been received as listed below for each specific request
- regcntr_id - character (36) - Mandatory
- machine_id - character (36) - Mandatory
- usr_id - character (36) - Mandatory
Responds with the Center ID, Machine ID ad User ID for the Center, User and Machine mapping deleted successfully
In case of Exceptions, system triggers relevant error messages.

Fetch Mapping History of Registration Center, Machine and User based on Registration Centre ID, Machine ID, User ID and Date

On receiving a request to fetch Mapping History of Registration, Machine and User with input parameters (Registration Centre ID, Machine ID, User ID and Date), the system Fetches all the attributes of Registration, Machine and User Mapping from the history table for the Machine ID and Date received

The record fetched is the latest record existing on or before the date received in the input parameter

Refer below for the process:

While fetching the mappings the system Validates if all required input parameters have been received as listed below for each specific request
- Registration Center ID - Mandatory
- Machine ID - Mandatory
- User ID - Mandatory
- Date - Mandatory
If the mandatory input parameters are missing, system throws the appropriate message.
Validates if the response contains following attributes
- Registration Center ID
- Machine ID
- User ID
- IsActive
In case of Exceptions, system triggers relevant error messages.

List of Devices

Create a Device

On receiving request to add a device with the input parameters, the system Stores the device in the Database

Refer below for the process:

While creating a device the system Validates if all required input parameters have been received as listed below for each specific request
- name - character (64) - Mandatory
- mac_address - character (64) - Mandatory
- serial_num - character (64) - Mandatory
- ip_address - character (17) - Optional
- dspec_id - character (36) - Mandatory
- validity_end_date - date - Optional
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
The Zone received should be either same as the Zone mapped of the Administrator or a child zone of the Administrator's Zone
cr_by should be the Username of the user who is accessing this API
cr_dtimes should be the date-time at which the user is creating the Device
Device ID should be generated by calling the Device ID Generator and stored against every new Device Created
If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Device and throw an error message. Refer messages section
If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Device as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
Responds with the appropriate message for the Device created successfully
History record should be stores for every creation of a new Device
The API should restricts the bulk creation of Master Data
In case of Exceptions, system triggers error messages as received from the Database.

Update a Device

Upon receiving a request update a Device with the input parameters, the system Updates the Device Details in the List of Devices Database for the id received

Refer below for the process:

While updating the device in device type list the system Validates if all required input parameters have been received as listed below for each specific request
- id - character (36) - Mandatory
- name - character (64) - Mandatory
- mac_address - character (64) - Mandatory
- serial_num - character (64) - Mandatory
- ip_address - character (17) - Optional
- dspec_id - character (36) - Mandatory
- validity_end_date - date - Optional
- lang_code - character (3) - Mandatory
- is_active - boolean - Mandatory
For the device_id received in the request, replaces all the data received in the request against the data existing in the List of Registration Center database against the same device_id.
All the mandatory input parameters should be present
The Zone received should be either same as the Zone mapped of the Administrator or a child zone of the Administrator's Zone
The API should not allow activation of Device if the data for the Device is not present in all the languages which are configured for a country
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Device as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
upd_by should be the Username of the user who is accessing this API
upd_dtimes should be the date-time at which the user is creating the Device
History record should be stores for every modification of a Device
Responds with the Registration Center Code and Language Code for the Device updated successfully
In case of Exceptions, system triggers relevant error messages

Decommission a Device

Upon receiving a request to decommission a Device with the input parameters (id) and Update the is_deleted flag to true in the List of Devices Database against the id received

Refer below for the process:

While deleting the device in the device list the system validates if all required input parameters have been received as listed below for each specific request
- id - character (36) - Mandatory
Change the “is_Deleted” flag against Device ID to “True”
Change the “is_Active” flag to “False” against the Device.
upd_by should be the Username of the user who is accessing this API
del_dtimes should be the date-time when the Device is being decommissioned
Validate if the Device is mapped to the Registration Center
- If yes, do no decommission the Device, throw an appropriate error message. Refer “Messages Section”.
The User accessing the API should only be able to decommission a Device under its administrative zone only
Responds with the appropriate message for the Machine decommissioned successfully
In case of Exceptions, system triggers relevant error messages

Fetch all the List of Devices based on Device Type and Language Code

On receiving request to Fetch list of all Device with the requirement input parameter (Language Code and/or Device Type), the system Fetches all the Devices against the Language Code and/or Device Type as requested

Refer below for the process:

While fetching the device types the system Validates if the request contains the following input parameters
- Device Type - Optional
- Language Code - Mandatory
If the mandatory input parameters are missing, system throws the appropriate message.
If the input parameters contain only Language Code:
- The response contains all the list of devices for all device types against the Languages code received
If the input parameters contain both Device Type and Language Code:
- The response contains the list of devices against the Languages code for that Device Type only
After validation, the above listed parameters system responds with an appropriate message if data does not exist against the Language code/Device Type received.
Validates if the response contains the following attributes for each Device ID, if the input parameters contain only Language Code:
- Device ID - Mandatory
- Machine Name - Mandatory
- Mac Address - Mandatory
- IP address - Optional
- Serial Number - Mandatory
- Device Spec ID - Mandatory
- IsActive - Mandatory
Validates if the response contains the following attributes for each Device ID, if the input parameters contain Device Type and Language Code:
- Device Type-Mandatory
- Device ID - Mandatory
- Machine Name - Mandatory
- Mac Address - Mandatory
- IP address - Optional
- Serial Number - Mandatory
- Device Spec ID - Mandatory
- IsActive - Mandatory
In case of Exceptions, system triggers relevant error messages.

Fetch Device Registration/Update History detail based on a Device ID and Language Code

On receiving request to fetch Device History Registration/Update Detail with the input parameters (Device ID, Date and Language Code), the system fetches all the attributes of Device from the history table for the Device ID, Date and Language Code received

The record fetched is the latest record existing on or before the date received in the input parameter

Refer below for the process:

While fetching the device registration and update history the system validates if all required input parameters have been received as listed below for each specific request
- Device ID - Mandatory
- Date - Mandatory
- Language Code - Mandatory
If the mandatory input parameters are missing, system throws the appropriate message
Validates if the response contains the following attributes for the Device ID and Language Code Received
- Device ID - Mandatory
- Device Name - Mandatory
- Mac Address - Mandatory
- IP address - Optional
- Serial Number - Mandatory
- Device Spec ID - Mandatory
- Validity Time - Optional
- Language Code - Mandatory
- IsActive - Mandatory
In case of Exceptions, system triggers relevant error messages.

List of Device Specifications

Create Device Specifications

On receiving request to add Device Specifications with the input parameters (name, brand, model, dtype_code, min_driver_ver, descr, lang_code and is_active), the system Stores the Device Specifications in the Database

Refer below for the process:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- name - Character - 64 - Mandatory
- brand - Character - 32 - Mandatory
- model - Character - 16 - Mandatory
- dtyp_code - Character - 36 - Mandatory
- min_driver_version - Character - 16 - Mandatory
- descr - Character - 256 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
dtyp_code received should be from list of 'codes' from device_type masterdata table
- If not, the API should throw an error. Refer messages section
API should perfrom below multi-language validations on the Device Specification data recieved
If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Device Specification and throw an error message. Refer messages section
If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Device Specification as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
If all the above validations are successfull, the API should store the data the the database
Device Specification Id should be generated at the back-end for any Device Specification added using a UUID generator
API should store cr_by as the Username of the user who is accessing this API
API should store cr_dtimes as the date-time at which the user is creating the Device Specification
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Fetch List of Device Specifications based on a Language Code

On receiving request to fetch the List of Device Specifications with input parameters (Language Code and/or Device Type) the system fetches the List of Device Specifications against the Language Code and/or Device Type

While fetching the List of Device Specifications against the Language Code and/or Device Type the system performs the following steps

Validates if the request contains the following input parameters
- Language Code - Mandatory
- Device Type - Optional
If the mandatory input parameters are missing, throws the appropriate message.
If the input parameters contain only Language Code:
- The response contains all the list of device specs against all the devices for the requested Language Code
If the input parameters contain Device Type and Language Code:
- The response contains only the list of device specs against the requested device type for the requested Language Code
Validates if the response contains the List of Device Specifications with the following attributes, if the input parameters contain only Language Code
- Device Specification ID
- Device Name
- Device Brand
- Device Model
- Device Type
- Minimum Driver Version
- IsActive
Validates if the response contains the List of Device Specifications with the following attributes, if the input parameters contain Device Type and Language Code
- Device Type
- Device Specification ID
- Device Name
- Device Brand
- Device Model
- Device Type
- Minimum Driver Version
- IsActive
In case of Exceptions, system triggers relevant error messages

Update a Device Specification

On receiving a request to update a Device Specification with the input parameters (id, name, brand, model, dtype_code, min_driver_ver, descr, lang_code and is_active) the system updates the Device Specification Details in the Device Specification Database for the id received

This API should only be accessible to Global Admin
The API should accept only the below parameters
- id - Character - 36 - Mandatory
- name - Character - 64 - Mandatory
- brand - Character - 32 - Mandatory
- model - Character - 16 - Mandatory
- dtyp_code - Character - 36 - Mandatory
- min_driver_version - Character - 16 - Mandatory
- descr - Character - 256 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
- dtyp_code received should be from list of 'codes' from device_type masterdata table
If not, the API should throw an error.
If all the above validations are successfull, the API should update the data in the database agianst the id received
API should perfrom below multi-language validations on the Device Specification data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Device Specification as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Device Specification details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

List of Device Types

Create Device Type

Upon receiving a request to add Device Type with the input parameters (code, name, descr, lang_code and is_active), the system Stores the Device Type in the Database

Refer below for the process:

This API should only be accessible to Global Admin
The API should accept only the below parameters
- name - Character - 64 - Mandatory
- descr - Character - 128 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
API should perfrom below multi-language validations on the Device Type data recieved
If, the data is recieved in secondary language and the data for primary language is not present in the database, the API should not allow creation of the Device Type and throw an error message. Refer messages section
If in the request, all the mandatory data is received in primary langauge but not in the secondary langauge, API should store the data but mark the Device Type as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
If all the above validations are successfull, the API should store the data the the database
Device Type Code should be generated at the back-end for any Device Type added using a UUID generator
API should store cr_by as the Username of the user who is accessing this API
API should store cr_dtimes as the date-time at which the user is creating the Device Type
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Update Device Type

This API should only be accessible to Global Admin
The API should accept only the below parameters
- code - Character - 36 - Mandatory
- name - Character - 64 - Mandatory
- descr - Character - 128 - Optional
- lang_code - Character - 3 - Mandatory
- is_active - boolean (true/false) - Mandatory
All the mandatory input parameter(s) should be present in the reqeust. If not, throw an appropriate error message
The API should validate the data type and length for each attribute as mentioned above.
In case of any failed validation, API should respond with appropriate error message. Refer messages section
If all the above validations are successfull, the API should update the data in the database agianst the code received
API should perfrom below multi-language validations on the Device Type data recieved
If in the database, all the mandatory data is present in primary langauge but not in the secondary langauge, API should update the data but mark the Device Type as Inactive (is_acitve = false) regardless of what is received in the request for is_active flag
API should store upd_by as the Username of the user who is accessing this API
API should store upd_dtimes as the date-time at which the user is modiying the Device Type details
API should only allow creation of one record at a time and should restrict bulk creation
API should audit the relevant data when the API is called successfully or when an error is encountered

Mappings of Registration Center and Machine

Create a mapping record of Machine and Center

Upon receiving a request to add a mapping of Machine and Center with the input parameters (regcntr_id, machine_id, and is_active), the system stores the Mapping of Machine and Center in the Database

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- regcntr_id - character (10) – Mandatory (refers to a Registration Center stored in Registration Center)
- machine_id - character (10) – Mandatory (refers to a Machine stored in Machine Masterdata)
- is_active - boolean - Mandatory
Validate if the Registration Center belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
Validate if the Registration Center belongs to the Zone of Machine or belongs to a child Zone of the Machine's Zone
Validate if the Machine belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
Validate if the Registration Center and Machine received are not in decommissioned state
If the above conditions in point 2, 3, 4 and 5 are not met, throw respective error messages. Refer messages section
If the Machine ID is already mapped to another Registration Center ID and the mapping is Active, throw an appropriate error
If the mapping is Inactive, create the new mapping
Store the default language code against the mapping
If the Registration Center ID - Machine ID mapping already exist but is in Inactive state, re-activate the mapping
In case of Exceptions/Success, system should trigger relevant messages. Refer “Messages” sectione.

Delete a Center-Machine mapping

Upon receiving a request to delete a Center-Machine mapping with the input parameters (regcntr_id, machine_id), the system updates the is_active flag to false in the Center-Machine mapping Database against the input received

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- regcntr_id - character (36) - Mandatory
- machine_id - character (36) - Mandatory
Validate if the Registration Center belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
Validate if the Machine belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
If the above conditions in point 3 and 4 are not met, throw respective error messages. Refer messages section
If the mapping does not exist or is in inactive state, throw an appropriate error
In case of Exceptions/Success, system should trigger relevant messages. Refer “Messages” section

Mappings of Registration Center and Device

Create a mapping record of Device and Center

Upon receiving a request to add a mapping of Device and Center with the input parameters (regcntr_id, device_id), the system stores the Mapping of Device and Center in the Database

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- regcntr_id - character (10) – Mandatory (refers to a Registration Center stored in Registration Center)
- device_id - character (36) – Mandatory (refers to a Device stored in Device Masterdata)
Validate if the Registration Center belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
Validate if the Registration Center belongs to the Zone of Device or belongs to a child Zone of the Device's Zone
Validate if the Device belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
Validate if the Registration Center and Device received are not in decommissioned state
If the above conditions in point 2, 3, 4 and 5 are not met, throw respective error messages. Refer messages section
If the Device ID is already mapped to another Registration Center ID and the mapping is Active, throw an appropriate error
If the mapping is Inactive, create the new mapping
Store the default language code against the mapping
If the Registration Center ID - Device ID mapping already exist but is in Inactive state, re-activate the mapping
In case of Exceptions/Success, system should trigger relevant messages. Refer “Messages” section

Unmap a Center-Device mapping

Upon receiving a request to delete a Center-Device mapping with the input parameters (regcntr_id, device_id), the system updates the is_active flag to false in the Center-Device mapping Database against the input received

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- regcntr_id - character (36) - Mandatory
- device_id - character (36) - Mandatory
Validate if the Registration Center belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
Validate if the Device belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
If the above conditions in point 3 and 4 are not met, throw respective error messages. Refer messages section 5 If the mapping does not exist or is in inactive state, throw an appropriate error
In case of Exceptions/Success, system should trigger relevant messages. Refer “Messages” section

Fetch Device-Center History record based on the timestamp received

On receiving a request to fetch Mapping History of Center and Device with input parameters (Registration Center ID, Device ID and Date Timestamp) the system fetches all the attributes of Center and Device Mapping from the history table for the Registration Center ID, Device ID and Date received

The record fetched is the latest record existing on or before the date received in the input parameter

While fetching the attributes of Center and Device Mapping from the history table the system performs the following steps

Validates if all required input parameters have been received as listed below for each specific request
- Registration Center ID - Mandatory
- Device ID - Mandatory
- Date Timestamp - Mandatory
If the mandatory input parameters are missing, throws the appropriate message.
Validates if the response contains following attributes
- Registration Center ID
- Device ID
- IsActive
- Effective date
In case of Exceptions, system triggers relevant error messages

Mappings of Registration Center, Machine, and Device

Create a mapping record of Center, Machine and Device

Upon receiving a request to add a mapping of Center, Machine and Device with the input parameters (regcntr_id, machine_id, device_id, and is_active), the system stores the Mapping of Center, Machine and Device in the Database

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- regcntr_id - character (36) – Mandatory (refers to a Registration Center stored in Registration Center Masterdata)
- machine_id - character (36) – Mandatory (refers to a Registration Center stored in Registration Center Masterdata)
- device_id - character (36) – Mandatory (refers to a Device stored in Device Masterdata)
- is_active - boolean - Mandatory
Responds with the Device Id, Machine ID and Center ID for the mapping of Center, Machine and Device created successfully
The component restricts the bulk creation of Master Data
In case of Exceptions, system triggers error messages as received from the Database.

Delete a Center-Machine-Device mapping

Upon receiving a request to delete a Center-Machine-Device mapping with the input parameters (regcntr_id, machine_id, device_id), the system updates the is_deleted flag to true in the Center-Machine-Device mapping Database against the input received

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- regcntr_id - character (36) - Mandatory
- machine_id - character (36) - Mandatory
- device_id - character (36) - Mandatory
Deleted record are not be deleted again
Responds with data not found error if deleted record is received in the request
Responds with the Device Id, Machine ID and Center ID for the mapping of Center, Machine and Device deleted successfully
In case of Exceptions, system triggers relevant error messages.

Mappings of Registration Center and User

Create a mapping record of User and Center

Upon receiving a request to add a mapping of User and Center with the input parameters (regcntr_id, usr_id, and is_active), the system stores the Mapping of User and Center in the Database

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- regcntr_id - character (10) – Mandatory (refers to a Registration Center stored in Registration Center)
- usr_id - character (36) – Mandatory (refers to a User stored in User Masterdata)
- is_active - boolean - Mandatory
Validate if the Registration Center belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
Validate if the Registration Center belongs to the Zone of User or belongs to a child Zone of the User's Zone
Validate if the User belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
Validate if the Registration Center and User received are not in decommissioned state
If the above conditions in point 2, 3, 4 and 5 are not met, throw respective error messages. Refer messages section
If the User ID is already mapped to another Registration Center ID and the mapping is Active, throw an appropriate error
If the mapping is Inactive, create the new mapping
Store the default language code against the mapping
If the Registration Center ID - User ID mapping already exist but is in Inactive state, re-activate the mapping
In case of Exceptions/Success, system should trigger relevant messages. Refer “Messages” section

Delete a Center-User mapping

Upon receiving a request to delete a Center-User mapping with the input parameters (regcntr_id, usr_id), the system updates the is_active flag to false in the Center-User mapping Database against the input received

Refer below for the process:

Validates if all required input parameters have been received as listed below for each specific request
- regcntr_id - character (36) - Mandatory
- usr_id - character (36) - Mandatory
Validate if the Registration Center belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
Validate if the User belongs to the Zone of Admin or belongs to a child Zone of the Admin's Zone
If the above conditions in point 3 and 4 are not met, throw respective error messages. Refer messages section
If the mapping does not exist or is in inactive state, throw an appropriate error
In case of Exceptions/Success, system should trigger relevant messages. Refer “Messages” section

MISP Management

License Key Allocation

Create MISP

The system receives a request to create a MISP with input parameters (MISP ID, MISP Organization Name, MISP Contact Number, MISP Email ID, MISP Address, MISP User name, MISP Password, MISP License Key, MISP License Key Status, IsActive)
Stores the data in the database
Responds to the source with the required message
If the mandatory input parameters are missing, throws the appropriate message.
In case of exceptions, system triggers relevant error messages.

Read MISP

The system receives a request to fetch a MISP with input parameters (MISP ID and/or MISP Organization Name)
Fetches the data existing against the input parameter received.
If only MISP ID is received, fetches data against the MISP ID from the database
If MISP Organization Name is received, fetches data against the MISP Organization Name from the database
If both MISP ID and MISP Organization Name is received, fetches data against the combination of both the input parameters (Complete match of Org name and MISP ID)
Fetches only active data from the database
If the input parameter received is null or empty, fetches all the data
If the mandatory input parameters are missing, throws the appropriate message.
If the data does not exist for input parameters received, throws the appropriate message.
In case of Exceptions, system triggers relevant error messages.

Update MISP

The system receives a request to update a MISP with input parameters (MISP ID, MISP Organization Name, MISP Contact Number, MISP Email ID, MISP Address, MISP User name, MISP Password, MISP License Key, MISP License Key Status, IsActive
Updates the data and Responds to the source with the required message
MISP ID will serves as search criteria to update the record in the database
The system updates the data received against the data already existing in the database against the MISP ID received
If the mandatory input parameters are missing, throws the appropriate message.
In case of Exceptions, system triggers relevant error messages.

Delete MISP

The system receives a request to delete a MISP with input parameters (MISP ID)
Deletes the data as mentioned as requested
Responds to the source with the required message
If the mandatory input parameters are missing, throws the appropriate message.
In case of exceptions, system triggers relevant error messages.

UIN and VID Generation Service Functionality

UIN Generation

MOSIP generates a pool of UINs before the registration process and stores them. The UIN generation policies can be defined or modified by country as per their requirement.

The UINs generated for the current implementation, follow the following policies:

UIN should not contain any alphanumeric characters
UIN should not contain any repeating numbers for 2 or more than 2 digits
UIN should not contain any sequential number for 3 or more than 3 digits
UIN should not be generated sequentially
UIN should not have repeated block of numbers for 2 or more than 2 digits
The last digit in the number should be reserved for a checksum
The number should not contain '0' or '1' as the first digit.
First 5 digits should be different from the last 5 digits (example - 4345643456)
First 5 digits should be different to the last 5 digits reversed (example - 4345665434)
UIN should not be a cyclic figure (example - 4567890123, 6543210987)
UIN should be different from the repetition of the first two digits 5 times (example - 3434343434)
UIN should not contain three even adjacent digits (example - 3948613752)
UIN should not contain admin defined restricted number

Note: The number of UINs to be generated in a pool depends on a configuration to be done by the country depending on the peak registration requirements. UIN generation service will receive a request by Registration Processor to get a UIN. The service responds with an un-allocated UIN from the generated pool. When the pool reaches a configured number of minimum UINs, MOSIP generates another pool of UIN.

VID Generation

MOSIP will generate a pool of VIDs through a Batch Job. The number of VIDs generated will be configurable by the country. All the VIDs generated will be assigned a status “Available” which means that the VID is available for allocation to a UIN. Any request for VID allocation will pick up VIDs which have this status. The Batch Job to generate the pool will run every time the number of VIDs in the pool reduces to a configured number.

VID generation will happen according to the below logic:

VID generated should contain the number of digits as configured.
A generated VID should follow the below logic a. The number should not contain any alphanumeric characters b. The number should not contain any repeating numbers for 2 or more than 2 digits c. The number should not contain any sequential number for 3 or more than 3 digits d. The numbers should not be generated sequentially e. The number should not have repeated block of numbers for 2 or more than 2 digits f. The number should not contain the restricted numbers defined by the ADMIN g. The last digit in the number should be reserved for a checksum h. The number should not contain '0' or '1' as the first digit.

MOSIP has a VID generator service which will receive a call to generate a VID. The service will also support receiving an expiry period (optional Parameter). This service when called will pick up a VID from the pre-generated pool and respond it to the source. The Service will also mark that VID in the pool as “Assigned” and attach the expiry period to the VID if received. The service will also make an asynchronous call to the batch job to check the remaining VIDs and generate the pool if needed.

MOSIP also has a VID revoke service which will receive a VID and expire it. When received a request along with the VID, the service will change the status of the VID as “Expired”.

MOSIP also has a batch Job to auto-expire VIDs and mark expired VIDs as to be available to be allocated again.

All the VIDs will be marked as ‘Expired’ through the batch job based on the expiry period assigned to them
All the VIDs which are in expired state for a configured amount of days should be marked as ‘Available’ through a daily batch job thus enabling re-usability of them

Common Services Functionality

OTP Manager

OTP Generation

OTP Manager Component handles OTP Generation and OTP Validation
For OTP Generation, system receives a request to generate an OTP along with a Key in input parameter.
This Key can be a Mobile number, Email ID or a combination of Mobile Number and Email ID.
The component generates an OTP as per the configured length and responds back with the OTP to the source. OTP manager maps an expiry period with the OTP as configured by the Administrator.

OTP Validation

For OTP Validation, system receives a request to validate an OTP with a Key and OTP in input parameter.
The component validates the OTP against the expiry and then validates the OTP against the Key if the OTP is not expired.
If the OTP is not expired and is valid against the Key, it will respond with message “Valid” else responds with “Invalid”.
A user will have a maximum configured number of tries to get the OTP wrong after which he/she will be blocked for a configured amount of time. During this blocked period, he/she cannot generate or validate another OTP.

QR Code Generator

QR code generator takes the content received along with the version number and converts the content into a QR code. The version number is configurable and determines how much data a QR code can store. The more the version number, the more data can be stored in a QR Code.

Crypto Services

Cryptography Services

Crypto service encrypts or decrypts data across MOSIP with the help of Public/Private Keys.

For Encryption

The Crypto Service receives a request from an application with input parameters – Application ID, Reference ID, Timestamp and the Data which needs to be encrypted. The Service then calls the Key Generator API to get a symmetric Key and encrypts the data using that symmetric Key.

The Service then calls the Key Manager Service with the Application ID and timestamp received in the input parameters and gets the public key.

The Service then encrypts the symmetric key using the Public key and joins the Encrypted data and Encrypted Symmetric Key using a Key splitter and respond to the source with the joined data.

For Decryption

The Crypto Service will receive a request from an application with input parameters – Application ID, Reference ID, Timestamp and Data that needs to be decrypted.

The Application ID received will be the one, which was sent for encryption of data in the above flow.

The Crypto Service then splits the received data into Encrypted Content and Encrypted Symmetric Key using the Key Splitter and then calls the Key Manager Service with the Encrypted Symmetric Key, Application ID and Timestamp to decrypt the data using private key.

The Key Manager instead of responding with the private key, decrypts the symmetric itself and send it back to the crypto service. The service then uses this symmetric key to decrypt data and send the decrypted data back to the source.

Key Generator

Generate a Symmetric Key

Upon receiving a request to generate symmetric key pair the system generates a key pair (public and private key) as defined below and responds with the symmetric key

The symmetric key generated supports AES algorithm
The symmetric key generated is of 256 bit size
The symmetric will be returned as a byte array

Generate an Asymmetric Key

Upon receiving a request to generate asymmetric key pair the system generates a key pair (public and private key) as defined below and responds with the Asymmetric key

The asymmetric key pair is generated using the RSA encryption
The asymmetric key pair generated is of 2048 bit size
The asymmetric is returned as a byte array

Key Management

The Key Manager Service works together with the Crypto Service.
It receives a request from Crypto Service from Public Key with the Application ID and Timestamp.
Key Manager Service then sends a valid Public key against the application ID received to Crypto Service.
In case, the public key is expired against that Application ID, it will generate a new Public Key and respond with it.
When there is a request to decrypt data, the private key of the application id or reference id is used. The Key manager will not respond with Private Key but instead takes the encrypted data from the source and decrypts it itself and responds with decrypted content

Crypto Utility

The crypto utility is supports encryption and decryption. It provides a utility called as key splitter which performs following functions:

It combines the encrypted data and encrypted the symmetric key while sending encrypted content to the source
It also splits the encrypted data and encrypted the symmetric key while receiving the content for decryption

Hash Utility

Identifies hash util methods
Creates wrapper class for methods defined in apache-commons hash util
Raises an alert in case of listed

HMAC Utility/Checksum Utility

A HMAC/checksum function is a way to create a compact representation of an arbitrarily large amount of data

Notification

OTP Notification Services

OTP Notification Services is a combined service, which receives a request to generate an OTP and responds directly to the User using SMS or Email Notification.
The service receives a request to generate and send OTP with User ID, OTP Channel (MOBILE and/or EMAIL), Template Variables, and Template Context (SMS and/or Email).
It then calls OTP Generator Service to generate an OTP against a Key (Mobile Number or Email).
It calls the Template Merger Service to merge OTP with the Template (SMS and/or Email).
It calls SMS and/or Email Notification Service to send the notification as per the template.
The choice of sending SMS and/or Email depends on the Notification Type Flag received in Input.
The system responds with the error message if a particular User ID does not have an Email or Mobile number registered against it if the otp channel received is Email or Mobile number respectively

Email Notification

This service triggers an Email Notification upon receiving a request to trigger notification with Recipient Email-ID, CC Recipients Email-IDs, Subject, Email Content, and Attachment as input parameter.
The restriction on Attachment and its size is configurable.
The Third-Party Email Vendor is configurable and any country specific vendor can be used.

SMS Notification

This service triggers an SMS Notification upon receiving a request to trigger notification with Phone Number and Content as input parameter. The third-party SMS Vendor is configurable and any country specific vendor can be used.

PDF Generator

This utility enables creation of PDF from the content received. It will receive a content in input parameter, convert it into a PDF document, and respond with it to the source.

PDF Generator also supports the feature to generate a Password Protected PDF with an additional input parameter “Password”, which is an optional parameter.

NOTE: If a Password is not received, then PDF Generator will generate the PDF of received content without the password protection.

Template Merger

This utility merges a Template with Placeholders with the dynamic values to form the content to be sent as Notifications or Acknowledgement. The Utility will receive a template and dynamic values from a source. It will merge the values and template and respond with the processed content.

Transliteration

MOSIP system can facilitate transliteration by integrating with a third party service provider. Receive a request for transliteration with the required input parameters (Word, Input Language Code, and Output Language Code)

Validates if all required input parameters have been received as listed below for each specific request
- User Input Word - Mandatory
- Input Language Code - Mandatory
- Output Language Code - Mandatory
Transliterates the Word received from Input Language to Output Language
In case of Exceptions, system triggers relevant error messages.

MOSIP Utils

Mobile Data Validator

Upon receiving a request to validate a mobile number against configured mobile number policy, the system validates the mobile number against the policy

Validates if all required input parameters have been received as listed below for each specific request
- Mobile number
Validates if the mobile no. against the following policies
- Mobile no. should contain no of digits configured by the ADMIN
- Mobile no. should only be numerical.
In case of Exceptions, system should trigger relevant error messages. Refer “Messages” section
Responds to the source with the result (Valid/Invalid)
Raises an alert in case of exceptions.

Email Data Validator

Upon receiving a request to validate an Email ID against the standard Email ID policy, system validates the Email ID against the Standard Email ID format

Validates if all required input parameters have been received as listed below for each specific request
- Email ID
Validates if the Email ID contains the minimum no. of characters as configured
Validates if the Email ID contains less than 254 max length
Validates if the Email ID only contains following characters
- Digits 0 to 9
- Uppercase and lowercase English letters (a–z, A–Z)
- Characters ! # $ % & ' * + - / = ? ^ _ ` { | }
- ~ .
Validates if the Email ID contains "@" and domain name within the Email ID.
Responds to the source with the result (Valid/Invalid)
Raises an alert in case of exceptions

Exception Framework

MOSIP system provides base exception framework.

Calendar Utility

Identifies Calendar util methods
Creates wrapper class for methods defined in apache-commons Calendar util
Raises an alert in case of listed exceptions

Date Utility

Identifies File util methods
Creates wrapper class for methods defined in apache-commons date and time util
Raises an alert in case of listed exceptions

File Utility

Identifies File util methods
Creates wrapper class for methods defined in apache-commons File util
Raises an alert in case of listed exceptions

JSON Utility

Identifies JSON util methods
Creates wrapper class for methods defined in apache-commons JSON util
Raises an alert in case of listed exceptions

Math Utility

Identifies Math util methods
Creates wrapper class for methods defined in apache-commons Math util
Raises an alert in case of listed exceptions

String Utility

Identifies String util methods
Creates wrapper class for methods defined in apache-commons String util
Raises an alert in case of listed exceptions

UUID Utility

Upon receiving a request to generate UUID the system generates UUID as per default UUID generation logic
UUID generated should be as per UUID Version 5
UUID generated should be of 36 characters (32 alphanumeric characters and four hyphens e.g. 123e4567-e89b-12d3-a456-426655440000)
Any application in MOSIP can use this UUID utility
Responds with the UUID to the source
Raises an alert in case of listed exceptions

Zip-Unzip Utility

Identifies Zip-Unzip util methods
Creates wrapper class for methods defined in apache-commons Zip-Unzip util
Raises an alert in case of listed exceptions

Log Utility

Generate logs across the application
Store generated logs in configured location
Raises an alert in case of listed exceptions

ID Object Validator Utility

Validate the Attributes in ID object against the Pre-Defined pattern and Master data values
- Validate Gender Types against country defined Masterdata
- Validate Document Categories against country defined Masterdata
- Validate Document Types country against defined Masterdata
- Validate Location and Location hierarchy against country defined Masterdata
- Validate Date of Birth against country configured pattern
- Validate Phone Number against country configured pattern
- Validate Email ID against country configured pattern
- Validate Age against country configured pattern
- Validate Full Name against country configured pattern
- Validate Address line 1,2 and 3 against country configured pattern
- Validate Reference Identity Number against country configured pattern
- Validate Country Code against country configured pattern
Respond with proper error messages in case of any validation faliure

Virus Scanner

Virus Scanner utility allows for virus scanning across MOSIP at various places. This includes:

Scanning of Document uploaded in Pre-registration
Scanning in Registration Client Software
Scanning of Registration packet in Registration Processor

Currently for Virus Scanner, MOSIP has integrated with Clam Antivirus which allows for 290 concurrent users. A Country may integrate their own Licensed version of antivirus as per their requirement.

Data Services Functionality

Data mapper

Data mapper is used across MOSIP to facilitate mapping between DTO (Data Transfer Object) and entity.

Data Access Manager

Data Access Manager provides a DAO (Data Access Object) interface to do the following:

Provide an interface for connection to a Database
Provide an interface to support Database CRUD (Create, Read, Update, Delete) operation
Provide an interface to support a custom SQL
Provide an interface to call Database functions.

Sync Handler

Sync Handler allows registration client to sync Master data, List of User, Roles and Respective Mappings and Configurations (Registration Client specific and Global Configs).
Sync Handler also allows Registration Client to push data from Client local database to Master Database.
As part of Master data Sync, the service receives a Machine ID and Timestamp, looks for a mapped Center ID to that Machine ID and responds to the Registration Client with the Center specific Master data for the following tables.
- Registration Center Type
- List of Registration Center
- Template File Format
- Template Type
- Templates
- Reason Category
- List of Reasons
- Document Category
- Document Type
- Mapping of Applicant Type-Document Category-Document Type (refer table "Valid Documents")
- Machine Type
- Machine Specifications
- List of Machines
- Device Types
- Device Specifications
- List of Devices
- Location Hierarchy
- List of Languages
- List of Genders
- Biometric Authentication Type
- Biometric Attribute
- Center-Machine Mapping
- Center-Device Mapping
- Center-Machine-Device Mapping
- Center-Machine-User Mapping
- Center-User Mapping
- Sync Job Definition
The Sync Handler service only sends incremental changes based on the Timestamp received by the service.
For configuration, sync handler receives a request to sync configurations and will respond back with Registration Client specific and Global Configurations.
For User, Roles and Respective User-Role mappings, Sync handler receives Center ID and Timestamp and will respond to the Registration Client with Center specific incremental changes.

ID Generator and Validator

ID Generator

Machine ID Generator

Upon receiving a request to generate Machine ID, the system generates Machine ID as per default Machine ID generation logic as mentioned below:

Machine ID should only be numeric
Machine ID generated should be of length of 5 digits
Each new Machine ID should be incremented by 1 for each new request
Machine ID generation should start from 10000
The number should not contain the restricted numbers defined by the ADMINs.

Responds with the Machine ID to the source.

Raises an alert in case of exceptions.

Registration Center ID Generator

Upon receiving a request to generate Registration Center ID, the system generates it as per default Registration Center ID generation logic.

Refer below for the process:

Registration Center ID is generated as per the defined logic mentioned below:
- Registration Center ID should only be numeric
- Registration Center ID generated should be of length of 5 digits
- Each new Registration Center ID should be incremented by 1 for each new request
- Registration Center ID generation should start from 10000
- The number should not contain the restricted numbers defined by the ADMIN
In case of exceptions, system triggers relevant error messages
Responds with the Registration Center ID to the source
Raises an alert in case of exceptions.

RID Generator

Upon receiving a request to generate RID with Machine ID and Center ID as input, the system generates it as per default RID generation logic.

Refer below for the process:

RID should be generated as per the defined logic mentioned below:
RID should only be numeric
First 5 Digit should be Registration Center ID
Next 5 Digits should be Machine ID
Next 5 Digits should be Running sequence
Last 14 Digits should be Timestamp
Total: 29 Digits
Responds with the RID to the source
Raises an alert in case of exceptions and triggers the messages.

MISP ID Generator

Upon receiving a request to generate MISP ID, the system generates it as per default MISP ID generation logic.

Refer below for the process:

MISP ID should be generated as per the defined logic mentioned below:
- MISP ID should only be numeric
- MISP ID generated should be of length of 3 digits (Configurable)
MISP ID generation should start from 100
Each new MISP ID should be incremented by one for each new request
The number should not contain the restricted numbers defined by the ADMIN
Responds with the MISP ID to the source
Raises an alert in case of exceptions and triggers the messages.

PRID Generator

Upon receiving a request to generate PRID with input parameters, the system generates PRID as per default PRID generation logic.

Refer below for the process:

PRID generated should contain number of digits as configured by the ADMIN
PRID is generated as per the defined logic mentioned below:
- The number should not contain any alphanumeric characters
- The number should not contain any repeating numbers for 2 or more than 2 digits
- The number should not contain any sequential number for 3 or more than 3 digits
- The numbers should not be generated sequentially
- The number should not have repeated block of numbers for 2 or more than 2 digits
- The number should not contain the restricted numbers defined by the ADMIN
- The last digit in the number should be reserved for a checksum
- The number should not contain '0' or '1' as the first digit
Responds with the PRID to the source
Raises an alert in case of exceptions.

VID Generator

Upon receiving a request to generate VID, the system generates PRID as per default PRID generation logic.

Refer below for the process:

VID should be generated as per the defined logic mentioned below:
Responds with the VID to the source
Raises an alert in case of exceptions.

VID generation policy

VID generated should contain the number of digits as configured.
Validates if the VID is generated as per the defined logic mentioned below:
- The number should not contain any alphanumeric characters
- The number should not contain any repeating numbers for 2 or more than 2 digits
- The number should not contain any sequential number for 3 or more than 3 digits
- The numbers should not be generated sequentially
- The number should not have repeated block of numbers for 2 or more than 2 digits
- The number should not contain the restricted numbers defined by the ADMIN
- The last digit in the number should be reserved for a checksum
- The number should not contain '0' or '1' as the first digit.
Expired VID should not be sent in response.

Token ID Generator

Upon receiving a request to generate Token ID (with input parameters (TSP ID, UIN), the system generates token ID as per default Token ID generation logic

Refer below for the process:

Token ID should be generated based on the below logic using received UIN and Partner ID
Token ID = SHA256( SHA256(UIN + SALT) + Partner ID + SALT
Validate if all mandatory input parameters have been received as listed below for each specific request
- UIN - Mandatory
- Partner ID - Mandatory
Raise an exception if input parameter is missing. Refer messages section
Token ID length should be of 36 digits

Partner ID Generator

Upon receiving a request to generate partner ID, the system generates it as per default partner ID generation logic.

Refer below for the process:

Partner ID is only be numeric
Partner ID generated is be of length of 4 digits
Partner ID length is be configurable
Each new Partner ID should be incremented by 1 for each new request
Partner ID generation is start from 1000
In case of exceptions, system triggers relevant error messages.

MISP License Key Generator

Upon receiving a request to generate License Key, the system generates it as per default License Key generation logic and responds with the License Key to the source

License Key is generated as per the defined logic mentioned below:
- License Key Generation follows a random generation pattern
- License Key is alphanumeric
- License Key generated is of length of 8 digits
- License Key is mapped to expiry (Expiry to be configured by admin).
In case of exceptions, system triggers relevant error messages

ID Validator

UIN Validator

Upon receiving a request to validate the UIN, the system validates the UIN against the defined policy

Refer below for the process:

Validates if the UIN is of configured length.
Validates the UIN by verifying the checksum
Validates if the UIN received as per the UIN generation logic
Responds to the source with an appropriate message
Raises an alert in case of exceptions.

PRID Validator

Upon receiving a request to validate the PRID, the system validates the PRID against the defined policy

Refer below for the process:

Validates if the received PRID contains number of digits as configured by the ADMIN
Validates the PRID received as per the PRID generation logic
Responds to the source with an appropriate message
Raises an alert in case of exceptions.

VID Validator

Upon receiving a request to validate the VID with input parameters (UIN), the system validates the VID against the defined VID policy

Refer below for the process:

Validates if the VID is of configured length.
Validates the VID by verifying the checksum
Validates if the VID received as per the VID generation logic
Responds to the source with an appropriate message and raises an alert in case of exceptions.

RID Validator

RID is generated in the following manner:

First 5 Digit: Registration Center ID
Next 5 Digits: Machine ID
Next 5 Digits: Running sequence
Last 14 Digits: Timestamp
Total: 29 Digits

RID Validation performs pattern validation on RID and provides three methods to validate RID.

Receive a RID, check whether RID is of configured length or not and respond with whether RID is valid or invalid
Receive a RID along with Registration Center ID and Machine ID. Check whether RID is of configured length or not and whether Registration Center ID and Machine ID are attached to the RID or not. Respond with whether RID is valid or invalid
Receive a RID along with Registration Center ID, Machine ID, Sequence Length and Timestamp Length. Check whether RID is proper or not as per the input received. Respond with whether RID is valid or invalid.

Partner ID Validator

The system receives a request to check status of a Partner with an input parameter (Partner ID)
Checks the length of the Partner ID
Checks the status of the Partner ID
Responds to the source according to the conditions mentioned below:
- If the length of Partner ID is not of the configured length, respond with message "INVALID"
- If the Partner ID is Inactive, respond with message "INACTIVE"
- If the Partner ID is of configured length and is Active, respond with "ACTIVE"
Throws an error if an input parameter is empty
In case of exceptions, system triggers relevant error messages.

License Key Status Validator

The system receives a request to check status of the License Key with an input parameter (License Key)

Checks the length of the License Key
Fetches the status of the License Key
Throw an error if an input parameter is empty
Responds to the source according to the conditions mentioned below:
- If the length of License Key is not 8 digits, respond with message "INVALID"
- If the License Key is expired as per the expiry period configured, respond with message "EXPIRED"
- If the status of License Key is "SUSPENDED", respond with message "SUSPENDED"
- If the status of License Key is "BLOCKED", respond with message "BLOCKED"
- If the status of License Key is "ACTIVE", respond with message "ACTIVE"
- License Key should be mapped to expiry (Expiry to be configured by admin).
In case of exceptions, system triggers relevant error messages.

Partner Management Audits

Partner Management provides services for various types of partners associated with the MOSIP system. Currently, in MOSIP we have identified some types of partners, but the adopters can choose to add many more partners.

Partner Management Service

Partners in MOSIP are created in a self-service mode. The partner visit the MOSIP partner management portal and requests for collaborating with MOSIP by providing basic details such as organization name & email id, purpose of registration (how they want to collaborate with MOSIP as a device provider, authentication partner, print partner, etc), basic credentials and performing an OTP based verification.

User Event Type

The following events are triggered as part of User Event Type in Partner Management Service module

Request Information for User Event Type

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

Success Response for User Event Type

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

System Event Type

The following events are triggered as part of System Event Type in Partner Management Service module.

Request Information for System Event Type

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

Success Response for System Event Type

Failure Response for System Event Type

Policy Management Service

The Partner Management service also involves policy management for Partners. Each partner can access various services only based on a defined policy.In order to create a policy we must have a policy group first. The policy admin needs to first create a policy group using the partner management portal.

System Event Type

The following events are triggered as part of System Event Type in Policy Management Service.

Request Information for System Event Type

Success Response for System Event Type

Failure Response for System Event Type

Event ID | Event Type | Event Name | Description | Reference ID | Reference ID Type -------|----------|------------|------------|-------------|--------------|------------------- PMS_PRT_475 | System | Create Policy Group | This event describes that the API call to create policy group has failed. | No ID | No ID Type PMS_PRT_416 | System | Create Policy Group | This event specifies that the API call to fetch the policy group details has failed. | Policy Group ID | Policy Group ID PMS_PRT_456 | System | Update Policy Group | This event describes that the API call to update policy group has failed. | Policy Group ID | Policy Group ID PMS_PRT_437 | System | Create Policy | This event describes that the API call to create a policy for a policy group has failed. | No ID | No ID Type PMS_PRT_487 | System | Create Policy | This event specifies that the API call to fetch the policy details has failed. | Policy ID | Policy ID PMS_PRT_483 | System | Update Policy | This event describes that the API call to update a policy for a policy group has failed. | Policy ID | Policy ID

MISP Management Service

MISP (MOSIP Infrastructure Service Provider) who provides infrastructure to send authentication request through a secure channel.

User Event Type

The following events are triggered as part of User Event Type in MISP management module

Request Information for User Event Type

Success response for User Event Type

System Event Type

The following events are triggered as part of System Event Type in MISP management module

Request Info for System Event Type

Success response for System Event Type

Failure response for System Event Type

VID Generator

Background

A virtual ID can be requested by an Indivudual against his UIN. The request is received to fetch a VID, which is unallocated yet at the time of request. There are many types of VIDs such as Perpetual VIDs, Transactional, Long term, short term.

Solution

The key solution considerations are

A pool of the VIDs are maintained for the faster dispatch of the VIDs to the requestor.

Vert.x REST Services: Following are the services which are available for the VID generator component,

VID Fetcher Service
- This service requests for an unassigned VIDs.
- Expiry days is passed as a parameter to this service. So, the VID pool knows when to expire this VID.
- In case of perpetual VIDs, the expiry days is not passed. So that, the expiry of the VIDs have to be called back specifically.
- Each time when this service is called, a call is triggered to the "VID pool size checker"
- Once the VID assigned, the status is changed to ASSIGNED

Flowchart diagram for fetcher

VID Revoke Service
- This service revokes the VID and allocates the VID in the free pool.
- This service accepts the VID as input.
- The requested VID status is changed to EXPIRED
- The expired VID can be reallocated after the configured cool-off period

Flowchart diagram for revoker

Vert.x Verticles: Following are the various verticles which are available,

VID pool size checker
- This vertical checks whether the pool has the available sufficient VIDs.
- The configuration for the Shrink pool size, number of VIDs to be generated etc., are retrieved from the config server.
- If the pool had shrunk below the configured size, the next "VID Pool Populator" vertical is notified.
- The "VID pool size checker" vertical is called whenever a request is received for the VID generator.
VID Pool Populator
- When the notification is received from the "VID pool size checker", this vertical is notified to generate the next set of VIDs are generated and placed in the pool.
- When this vertical runs, it creates a lock. So that no multiple populator runs.
- The worker verticle size is double as "VID Genertor Service".
- The status of the new generated VIDs is AVAILABLE

Vert.x expirer:
- The expired VIDs status' have to be changed back to available. This scheduler runs at night when the traffic is minimal. The entire database have to be scanned for the expired VIDs.
- The VID's status is changed back to AVAILABLE, if the VID is expired and crossed the cool-off period.

Flowchart diagram for expirer

Database:

A separate schema is needed for the VID.
VID Statuses are maintained in the database.

Module diagram

Registration Processor Audits

Registration Processor processes the data (demographic and biometric) of an Individual for quality and uniqueness and then issues a Unique Identification Number (UIN). It also provides functionality to update demographic and biometric data and issue a new UIN if lost.

All modules

System Events

The following events are triggered as part of System Event Type for all modules in Registration Processor

Failure response for System Event Type

Sl No.

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

Packet Receiver Stage

User Events

The following events are triggered as part of User Event Type in Packet Receiver Stage

Success response for User Event Type in Packet Receiver Stage

System Events

The following events are triggered as part of System Event Type in Packet Receiver Stage

Failure response for System Event Type in Packet Receiver Stage

OSI Validator Stage

User Events

The following events are triggered as part of User Event Type in OSI Validator Stage

Success response for User Event Type in OSI Validator Stage

System Events

The following events are triggered as part of System Event Type in OSI Validator Stage

Failure response for System Event Type in OSI Validator Stage

Packet Classifier Stage

User Events

The following events are triggered as part of User Event Type in Packet Classifier Stage

Success response for User Event Type in Packet Classifier Stage

The following events are triggered as part of System Event Type in Packet Classifier Stage

Failure response for System Event Type in Packet Classifier Stage

Packet Uploader Stage

User Events

The following events are triggered as part of User Event Type in Packet Uploader Stage

Success response for User Event Type in Packet Uploader Stage

The following events are triggered as part of System Event Type in Packet Uploader Stage

Failure response for System Event Type in Packet Uploader Stage

Packet Validator Stage

User Events

The following events are triggered as part of User Event Type in Packet Validator Stage

Success response for User Event Type in Packet Validator Stage

The following events are triggered as part of System Event Type in Packet Validator Stage

Failure response for System Event Type in Packet Validator Stage

Quality Checker Stage

User Events

The following events are triggered as part of User Event Type in Quality Checker Stage

Success response for User Event Type in Quality Checker Stage

The following events are triggered as part of System Event Type in Quality Checker Stage

Failure response for System Event Type in Quality Checker Stage

Secure Zone Notification Stage

User Events

The following events are triggered as part of User Event Type in Secure Zone Notification Stage

Success response for User Event Type in Secure Zone Notification Stage

The following events are triggered as part of System Event Type in Secure Zone Notification Stage

Failure response for System Event Type in Secure Zone Notification Stage

Message Sender Stage

User Events

The following events are triggered as part of User Event Type in Message Sender Stage

Success response for User Event Type in Message Sender Stage

The following events are triggered as part of System Event Type in Message Sender Stage

Failure response for System Event Type in Message Sender Stage

Print Stage

User Events

The following events are triggered as part of User Event Type in Print Stage

Success response for User Event Type in Print Stage

The following events are triggered as part of System Event Type in Print Stage

Failure response for System Event Type in Print Stage

Re-Processor Stage

User Events

The following events are triggered as part of User Event Type in Re-Processor Stage

Success response for User Event Type in Re-Processor Stage

The following events are triggered as part of System Event Type in Re-Processor Stage

Failure response for System Event Type in Re-Processor Stage

ABIS Handler Stage

User Events

The following events are triggered as part of User Event Type in ABIS Handler Stage

Success response for User Event Type in ABIS Handler Stage

The following events are triggered as part of System Event Type in ABIS Handler Stage

Failure response for System Event Type in ABIS Handler Stage

Bio Dedupe Stage

User Events

The following events are triggered as part of User Event Type in Bio Dedupe Stage

Success response for User Event Type in Bio Dedupe Stage

The following events are triggered as part of System Event Type in Bio Dedupe Stage

Failure response for System Event Type in Bio Dedupe Stage

Biometric Authentication Stage

User Events

The following events are triggered as part of User Event Type in Biometric Authentication Stage

Success response for User Event Type in Biometric Authentication Stage

The following events are triggered as part of System Event Type in Biometric Authentication Stage

Failure response for System Event Type in Biometric Authentication Stage

Demo Dedupe Stage

User Events

The following events are triggered as part of User Event Type in Demo Dedupe Stage

Success response for User Event Type in Demo Dedupe Stage

The following events are triggered as part of System Event Type in Demo Dedupe Stage

Failure response for System Event Type in Demo Dedupe Stage

Manual Verification Stage

User Events

The following events are triggered as part of User Event Type in Manual Verification Stage

Success response for User Event Type in Manual Verification Stage

The following events are triggered as part of System Event Type in Manual Verification Stage

Failure response for System Event Type in Manual Verification Stage

UIN Generator Stage

User Events

The following events are triggered as part of User Event Type in UIN Generator Stage

Success response for User Event Type in UIN Generator Stage

The following events are triggered as part of System Event Type in UIN Generator Stage

Failure response for System Event Type in UIN Generator Stage

Pre-registration Audits

The Pre-Registration module enables a resident to: - Enter demographic data & upload supporting documents - Book an appointment for one or many users for registration by choosing a suitable registration center and time slot - Receive appointment notifications - Reschedule and cancel appointments - Resident data is sent to the designated registration center before appointment that can be used during the registration process.

Pre-Registration Service

This service manages to provide the following service to the Pre-registration application. - Demographic - This service details used by Pre-Registration portal to maintain the demographic data by providing his/her basic details. - Document - This service enables Pre-Registration portal to request for uploading the document for a particular pre-registration. - QrCodeGenerator - This service details used by Pre-Registration portal to generate QR Code. - Transliteration - This service details used by Pre-Registration portal to provide transliteration from primary to secondary language. - Notification - This service details used by Pre-Registration portal to trigger notification via SMS or email. - Login - This service details used by Pre-Registration portal to authenticate user by sending OTP to the user, validating with userid and OTP.

User Event Type

The following events are triggered as part of User Event Type in ID Pre-Registration Service

Retrieval Event Information for User Event Type

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

Update Event Information for User Event Type

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

Delete Event Information for User Event Type

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

Upload Event Information for User Event Type

Event ID

Event Type

Event Name

Description

Reference ID

Reference ID Type

Data Sync Event Information for User Event Type

Reverse Sync Event Information for User Event Type

Copy Event Information for User Event Type

Authentication Event Information for User Event Type

Consumed Status Event Information for User Event Type

Expired Status Event Information for User Event Type

System Event Type

The following events are triggered as part of System Event Type in ID Pre-Registration Service

Exception Event Information for System Event Type

Persist Event Information for System Event Type

Notification Event Information for System Event Type

Authentication and Authorization Functionality

In MOSIP, Authentication largely falls into the below categories:

Authentication via web channel (for Pre-Registration web application, Admin web application and Resident portal)
Authentication via local system i.e., offline authentication (for Registration client)

In MOSIP, Authorization falls into the below categories:

Authorization of API's accessed via web channel
Authorization to access specific data

A country will have its own hierarchy of system users especially the Registration staff and system administration staff. So, instead of defining a fixed hierarchy, by default MOSIP will depend on an LDAP implementation to manage users, organizational hierarchy and roles for users in the hierarchy. MOSIP will use an open source LDAP server as the LDAP implementation. Administrators can create hierarchy and users using Apache Directory Studio.

MOSIP system can handle Authorization across core services and restricts access to Web-services as per the roles defined.

For details on the APIs for authentication and authorization please view our documentation on .

Resident Service Audits

System Events

Request Info for System Event Type

Success response for System Event Type

Failure response for System Event Type

ID Repository Audits

ID Repository Service

User Event Type

Resident Service Audits

System Events

Request Info for System Event Type

Success response for System Event Type

Failure response for System Event Type

ID Repository Audits

ID Repository Service

User Event Type

Kernel

Overview

Components

Detailed functionality

Services and libraries

Build and deploy

APIs

Registration Client Audits

Login and Authentication Service

User Event Type

Navigation Events in Home Screen

User Event Type

System Event Type

New Registration Flow

User Event Type

Success Response for User Event Type

Failure Response for User Event Type

End of Day Activities

User Event Type

System Event Type

Synchronization Activities

User Event Type

Scheduler Service

System Event Type

Mosip Device Manager Service

User Event Type

Success Response for User Event Type

Failure Response for User Event Type

Auth Adapter

SecurityConfig

AuthFilter

AuthHeadersFilter

AuthProvider

AuthSuccessHandler

AuthEntryPoint

AuthToken

AuthUserDetails

ClientInterceptor

MosipUser

AuthControllerAdvice

Auth Implementation

Documentations for the Auth Implementations

Admin Service Audits

Packet Status Service

User Events

Failure response for User Event Type

System Events

Bulk Data Service

System Events

Request Info for System Event Type

Success response for System Event Type

Failure response for System Event Type

Master Data Services Functionality

Master Data Management

Location Hierarchy

Create Location Hierarchy

Update a Location

Verify Location

List of Holidays

Create Holiday

Update Holiday

Fetch List of Holidays based on a Registration Center ID, a Year and a Language Code

Biometric Authentication Type

Create Biometric Authentication Type