ID Generation Service

Overview

In a bid to avoid unnecessary repetition of codes which generate ids and to have central control over the logic so that the 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.

Pre-requisites

1. Prior knowledge of Java/J2EE.

2. Prior knowledge of Spring Boot and Flyway.

3. Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.

Key Functionalities

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, , random number, and sequence generated number. Id can be generated by providing a request with any of the above-mentioned information.

For example:

The Id Amritsar-PT-2019/09/12-000454-99 contains

• Amritsar - which is the name of the city

• PT - a 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 Configuration

By default, the IDGen service will now read its 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 the financial year, the string will be replaced by the value of starting year and the last two numbers of the ending year separated by a hyphen. For instance: 2018-19 in case of the financial year 2018 to 2019.

• [cy:] - any string that starts with cy will be considered as the 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 of 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 location services.

• [SEQ_*] - String starting with seq will be considered as sequence names, which will be queried to get the next seq number. If your sequence does not start with the namespace containing “SEQ” then the application will not consider it as a sequence. In the 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 the format for the given idName exists, if not then the format will be used.

STATE v/s ULB Level Sequences:

If you want a state-level sequence then you need to 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 the below example.

{
"format": "PT/[CITY.CODE]/[fy:yyyy-yy]/[SEQ_RCPT_PT_[TENANT_ID]]",
"idname": "pt.receipt.id"
}

Sequences & Its Creation

The SEQ_* replaceable used in id generation are by default expected for the sequence to already exist in the DB. But this behaviour can be changed and controlled using two environmental 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 that no DB configuration needs to be done as long as MDMS has been configured. It is recommended that each service using idgen should generate an 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 keep as false, as anyone with access to idgen can create any number of sequences in DB and overload the DB. Though during the 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 generate the sequences. And afterwards, the flags should be disabled.

Deployment Details

1. Add MDMS configs required for ID Gen service and restart the MDMS service.

2. Deploy the latest version of the ID generation service.

3. Add role-action mapping for APIs.

Integration Details

Integration Scope

The ID Gen service is used to generate unique ID numbers for all miscellaneous/ad-hoc services which citizens avail from ULBs.

Integration Benefits

• 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.

Integration Steps

1. To integrate, the host of idgen-services module should be overwritten in the helm chart.

2. /egov-idgen/id/_generate should be added as the endpoint for generating ID numbers in the system

Play around with the API's : DIGIT-Playground

API Contract

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