INTRODUCTION:

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.

Requirements:

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.

Functionality:

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}]

**The sequence must have been created in the db in case of usage of a sequence in your id format~~, failing which error will be thrown if sequence is not found.~~
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

SETUP AND USAGE:

The Application is present among the core group of applications available in the core-services git repository. It can be run as any other spring boot application but needs lombok extension added in your ide to load it. Once the application is up and running API requests can be posted to the url and ids can be generated.

**in case of intellij the plugin can be installed directly, for eclipse the lombok jar location has to be added in eclipse.ini file in this format -javaagent:lombok.jar.

For the API information please refer the swagger yaml

API Contract:

https://raw.githubusercontent.com/egovernments/egov-services/master/docs/idgen/contracts/v1-0-0.yml

Features to be :

The current api design requires you to send multiple idgen-request object in the request array (* please refer the yaml) depending on the number of ids you want even in the case of id with same formats. This has to be upgraded so that the count ids needed by the requester can be mention in a single object instead of providing multiple requests.

You can add count parameter to the json request to create multiple ids

{

"idRequests": [{

"idName": "pt.receipt.id",

"tenantId": "pb.jalandhar",

"format": "PT/[SEQ_PT_RECEIPT_ID]",

"count": 4

}]

}