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.
...
[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.
...
[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
But if you want a ULB level sequence, the sequence name should be dynamic based on the tenantid as given in below example
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 eGovcore-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.
...
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