In a bid to avoid unnecessary repetition of codes which generates ids and to have central control over the logic so that burden of maintenance is reduced from the developers.
To create a config based application which can be used without writing even a single line of coding.
Prior Knowledge of Java/J2EE.
Prior Knowledge of Spring Boot, Flyway.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
The application exposes a Rest API to take in requests and provide the ids in response in the requested format.
The request format varies from current date information , tenantId*, random number, sequence generated number.
Id can be generated by providing request with any of the above mentioned information.
*TenantId - is the string representing the individual units called tenants in DIGIT system which can be a city, town or village.
For eg:
An Id Amritsar-PT-2019/09/12-000454-99 contains
Amritsar - which is the name of the city
PT - fixed string representing the module code(PROPERTY TAX)
2019/09/12 - date
000454 - sequence generated number
99 - random number
The id generated in the above mentioned eg needs the following format
[city]-PT-[cy:yyyy/mm/dd]-[SEQ_SEQUENCE_NAME]-[d{4}]
Everything in the square brackets will be replaced with the appropriate values by the app.
ID-FORMAT COFNIGURATION:
By default the IDGen service will now read it configuration from MDMS. DB Configuration requires access to the DB, so the new preferred method for the configuration is MDMS. The configuration needs to be stored in common-masters/IdFormat.json in MDMS
It is recommended to have the IdFormat as a state level master. To disable the configuration to be read from DB instead, the environment variable IDFORMAT_FROM_MDMS should be set to false
ID-FORMAT-REPLACEABLES:
[FY:] - represents financial year, the string will be replaced by the value of starting year and last two numbers of ending year separated by a hyphen. For eg: 2018-19 incase of financial year 2018 to 2019.
[cy:] - any string that starts with cy will be considered as date format. The values after the cy: is the format using which output will be generated.
[d{5}] - d represents the random number generator, the length if the random number can be specified in flower brackets next to d. If the value is not provided then the random length of 2 will be assigned.
[city] - The string city will be replaced by the city code provided by the respective ulb in the location services.
[SEQ_*] - String starting with seq will be considered as sequence names, which will be queried to get the next seq number. If the your sequence doesn’t start with the namespace containing “SEQ” then application will not consider it as a sequence. In absence of the sequence from DB error will be thrown.
[tenantid] - replaces the placeholder with the tenantid passed in the request object
[tenant_id] - replaces the placeholder with the tenantid passed in the request object. Replaces all `.` with `_`
[TENANT_ID] - replaces the placeholder with the tenantid passed in the request object. Replaces all `.` with `_`, and changes the case to upper case
idName v/s format:
When you use both idName and format in a request. IDGEN will first try to see if format for the given idName exists, if not then format will be used
STATE v/s ULB LEVEL SEQUENCES:
If you want a state level sequence then you need use a fixed sequence name
{
"format": "PT/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_RCPT_PT_RECEIPT]",
"idname": "pt.receipt.id"
}
But if you want a ULB level sequence, the sequence name should be dynamic based on the tenantid as given in below example
{
"format": "PT/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_RCPT_PT_[TENANT_ID]]",
"idname": "pt.receipt.id"
}
SEQUENCES AND THEIR CREATION:
The SEQ_* replaceable used in id generation are by default expected the sequence to already exists in the DB. But this behavior can be changed and controlled using two environment variables while deploying the service
AUTOCREATE_NEW_SEQ: Default to false. When set to true, this will auto create sequences when the format has been derived using provided idName. Since the idName format comes from DB or MDMS, it is a trusted value and this value should be set to true. This will make sure the no DB configuration needs to be done as long as MDMS has been configured. It is recommended that each service using idgen should generated id using idName instead of just using passing the format directly. This will make sure that no DB configuration needs to be done for creating sequences
AUTOCREATE_REQUEST_SEQ: Default to false. When set to true, this will auto create sequences when the format has been derived using the format parameter from the request. This is recommended to kept as false, as anyone with access to idgen can create any number of sequences in DB and overload the DB. Though during initial setup of an environment this variable can be kept as true to create all the sequences when the initial flows are run from the UI, to generated the sequences. And afterward the flags should be disabled
Add mdms configs required for ID Gen Service and restart mdms service.
Deploy the latest version of ID Generation Service.
Add Role-Action mapping for API’s.
The ID Gen service is used to generate unique ID numbers for all miscellaneous / adhoc services which citizens avail from ULBs.
Can perform service-specific business logic without impacting the other module.
Provides the capability of generating the unique identifier of the entity calling ID Gen service.
To integrate, host of idgen-services module should be overwritten in helm chart.
/egov-idgen/id/_generate should be added as the endpoint for generating ID number in the system
https://raw.githubusercontent.com/egovernments/egov-services/master/docs/idgen/contracts/v1-0-0.yml