Use Case Implementation

OpenG2P Registry provides a base platform to create a Registry but it still needs a manifestation specific to your use case. A typical implementation will involve the following process.

Phase 1: Requirements

Purpose

In this phase we understand the use case and your requirements in as much detail as possible to map it the product and identify and gaps vis a vis what OpenG2P offers. In this phase we also understand the plan for doing a pilot or full rollout, the scale of the pilot/rollout, timelines and so on.

Information to collect

• Your country? -> "country"

• Your department/organisation that wants to use OpenG2P Registry. -> "department"

• What is your end2end use case — is this a benefit delivery program, if so what is the name of the program for which Registry is required? -> "program". Or your mandate is just to create a registry like a National Social Registy or Farmer Registry, or Family Registry that will serve several programs, use cases and several departements? Desicribe the type of registry - like 'Social Registry', 'Workers Registry', 'Farmer Registry', 'Disability Registry', 'Family Registry', 'Students Registry', 'Health Workers Registry', 'Crop Registry', 'Land Registry', 'Vehicle Registry' etc -> "registry_type"

• Describe your use case in detail. How will the data be consumed/used from this registry — who are the consumers. Would you like to share the data with other departments, systems, agencies, applications? -> "use_case_info".

• What is the process of registration? would it be online via portal, or offline via agents collecting information? -> "offline_registrations" (true/false)

• What kind of documents are required for registration? -> "documents"

• Is this a 'green field' implementation or 'brown field'. 'green field' means a fresh data colloection. While 'brown field' implies you already have existing data that you would like to import. In which in what form is the data available - is it Excel sheets, or some database? Or is this data available via APIs of some of other system. -> "existing_data_import" (true/false)

• What are the various functionalities you are looking for your use case that must be supported by OpenG2P Registry?

• Are you ok with having developement sandbox installed on a public cloud? -> "sandbox_on_cloud" (true/false)

• Will your pilot and production system run on on-prem hardware or you are ok with running the same on cloud? -> "production_on_cloud" (true/false)

• What is the number of primary records of the subjects (e.g. farmer, citizen, vehicles, families etc) expected the registry? -> "n_records"

• Which ID(s) will be used for the records? "id_types"

• Any specific interoperability requirements? -> "interoperability"

Output

Requirement analysis report comprising of

• Mapping of features/functionality, and importantly gaps between what is required versus what is offered by OpenG2P. The gaps should be clearly marked out separately.

• Guidance on the compute resources and other resource requirements for creating the setups for development, pilot and rollout

Phase Transition Protocol (completion criteria)

After the phase report is generated, the following protocol must be strictly followed to move to the next phase

1. The user must be informed about the requirements report and asked to review it carefully.

2. If there are any changes, the same should be captured and report generated again.

3. The user's approval must be taken for the report.

4. The user must be informed briefly about the next phase and asked if the user is ok to start the next phase.

Phase 2: Build

Purpose

In this phase the code changes and configurations are done after obtaining fine grained details of registry like registry parameters, constraints, number of registers, number of tables etc. Deployment artifacts like Docker, Helm are created after building the code.

Information to collect

• What the full name of your registry? Keep the name as short as possible. This will appear on all user interface text fields. Example 'Health Workers Registry' -> "registry_name"

• What is the registry name menemonic? Keep this very short. This is be used in code, file names, Docker name, Service name etc. Suggested is lower case of registry name separated by hyphens, e.g. 'health-worker'. Do not add add 'registry' as a prefix or suffix to the name as it will be added automatically. -> "registry_mnemonic".

• How many registers does it contain? Give name of each register. -> "registers[]"

• Give exact names of the database columns for each register. -> "register[name, [columns]".

• What are the various constraints between the tables (database contraints) -> "database_constraints[]"

• What is the number of digits required for your functional ID? -> "id_length"

Actions

• Git clone the following repositories in your local machine in a "build folder". Make sure the "build folder" is created fresh everytime, and is empty - does not contain any previous repos or contents:

  • Repo 1: https://github.com/OpenG2P/openg2p-registry-gen2-extensions branch 'develop'

  • Repo 2: https://github.com/OpenG2P/openg2p-registry-gen2-docker branch 'develop'

• Inside Repo 1, in the root folder, make a copy of the entire folder openg2p-registry-farmer-extension to openg2p-registry-<registry_menomic>-extension

• Inside Repo 2 inside each of the following folders, create a copy of farmer-develop.txt file. Change the name to <registry_menemonic>-develop.txt .

  • staff-portal-api

  • partner-api

  • celery

• Inside each of <registry_menemonic>-develop.txt in the above folders, apply the following changes

  • Replace the line git://develop//https://github.com/openg2p/openg2p-registry-gen2-extensions#subdirectory=openg2p-registry-farmer-extension with {{workDir}}/openg2p-registry-gen2-extensions/openg2p-registry-<registry_mneominic>-extension (note there is no '#' or 'subdirectory' in this path).

  • In the first line which contains the Docker name, replace the word 'farmer' with <registry_mnemonic>.

• From the root directory of Repo 2 run the follwing commands:

  • scripts/build.sh staff-portal-api/<registry-menemonic>-develop.txt

  • scripts/build.sh partner-api/<registry-menemonic>-develop.txt

  • scripts/build.sh celery/<registry-menemonic>-develop.txt

Phase Transition Protocol (completion criteria)

• All Dockers built successfully

• Code specific to this impelmentation checked in git repo (TBD)

Output

• Dockers for all of these available

  • staff-portal-api

  • partner-api

  • celery

• Customization report consisting of

  • List of modifications at a high level - major changes and their repositories.

  • Git final commit id for after checkin the code.

  • Names of all the Dockers created along with their tags.

Phase 3: Sandbox

Phase 4: Pilot

Phase 5: Full rollout