As part of the iFIX-2.0-alpha release, we have migrated the following master data from ifix_db to mgramseva_db:

1. Adapter Master Data Service

   1. Department

   2. Expenditure

   3. Project

2. Department Entity Service

   1. Department Entity

   2. Department Hierarchy

Out of these, the project data SHOULD NOT be copied to the new DB because a new feature of the multi-tenant (GP) project is introduced with this release. New projects can be created and linked to multiple GPs.

Other master data can be copied.

Pre-requisites

1. Make sure the playground pod is “dwssio/playground:mongo-v2” or newer.

2. Keep the MongoDB Credentials handy in the following format

   • Host(in this format): “<host-address>:27017”

   • Username - a user that has access to BOTH source and destination dbs

   • Password

   • Source and Destination DB Names

   • List of collection names to be copied

3. The mongo-migration.sh script copied to the playground pod. (You must have necessary kube permissions to copy a file to a pod.)

   • Sample Command to copy the file: kubectl cp mongo_migration.sh ifix/<playground pod>:/

Migration Instructions

A MongoDB Dump script is provided that will copy a list of collections from a source DB to the destination DB.

1. Execute the provided script using following parameters:

   • -h = Host Address

   • -u = username

   • -p = password

   • -s = source db

   • -d = destination db

   • -c = collection name - You can provide multiple collection as depicted in the following example

2. ./mongo-migration.sh -h <host-address>:27017 -u <ifix username> -p <ifix password> - s <ifix db> -d <mgramseva db> -c department -c expenditure -c departmentHierarchyLevel -c departmentEntity

This section provides the steps and details required to migrate the data from one service to another.

​All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

The mGramSeva iFIX Adapter receives multiple event requests from the mGramSeva service and helps in attributes conversion to map with fix-fiscal-event-service request data.

Setup Steps

1. Environment variable

   Configure "fiscal-event-service", "adapter-master-data-service" and "ifix-department-entity-service" in egov-service-host in respective environment yaml file ( ).

2. Redis data clean up

   Execute the below commands on redis-cli before doing any activity on the mgramseva iFix adapter while performing the deployment first time.

   • Connecting Redis Client:

     kubectl exec -it <redis-pod> -n mgramseva -- /bin/bash

     redis-cli

     e.g.

     kubectl exec -it redis-647449f6b9-gg4gw -n mgramseva -- /bin/bash

     redis-cli

     keys * (check all keys)

   • Redis cleanup command

     del <key>

     e.g.

     del "10101" "10102" "10201" "20101" "20201" "20301" "20401"

     keys * (check all keys)

   Note: Make sure all client codes, which have been mentioned in the "ifix_adapter_coa_map" table, are listed in the redis "DEL" command list and recheck those are removed using "keys *" command.

Steps To Use mGramSeva iFIX Adapter Service

Use the postman tool to verify mGramSeva iFix adapter API end. It is open-end and therefore does not require any access token.

Technical Doc

The fiscal event post-processor receives a collection of fiscal event lists and after processing those events it pushes them to the Mongo DB and Druid DB. Before deploying the fiscal event post-processor build to the respective environment, make sure you have ingested the updated druid config file to the Druid DB as per the instructions given .

Fiscal Events Data Clean up

Before upgrading the iFIX fiscal event service v2.0, clean up the existing fiscal event data. This is a one-time activity. Follow the steps outlined in the .

Steps To Use iFIX Fiscal Event Service

Get the access token from keycloak server and pass it as a bearer token while requesting to iFIX fiscal event service.

Technical Doc

All content on this page by is licensed under a .

Department Entity service manages the department and its hierarchies metadata. It deals with department entities and department hierarchy only. Department Entity and Department Hierarchy were earlier in the iFIX core. Now, they have been moved to the mGramSeva iFIX adapter side. This page provides details on how to migrate that data from iFIX DB to mGramSeva iFIX adapter DB.

Steps To Migrate

1. Create (if it's not available) DB schema (Mongo) in mgramseva namespace.

2. Create (if it's not available) DB schema (Mongo) in mgramseva namespace.

3. We can drop unused collections from iFix DB using the below steps :

   1. Connect to ifix namespace playground pod

      kubectl exec -it <playground-pod-name> -n ifix -- /bin/bash

   2. Connect to the particular mongo db

      mongo --host <hostname>:27017 -u <username> -p <password>

   3. Use db

      use <db_name>

   4. Check the above-mentioned collection name using the below commands

      db.getCollectionNames();

   5. If above mentioned (highlighted in bold) collections are there then drop them off using below commands

      db.departmentEntity.drop();

      db.departmentHierarchyLevel.drop();

Steps To Use Department Entity Service

Port-forward the Department Entity service in localhost from a specific environment (like QA/UAT/Prod). Below is the command to port-forward :

kubectl port-forward <pod-name> 8032:8080 -n mgramseva

Technical Doc

Department Entity Service v2.0

Adapter Master Data Service v1.0 And iFIX Master Data Service v2.0

This page provides step-wise details on how to migrate Department, Project and Expenditure from iFix Master Data Service to Adapter Master Data Service.

Steps To Migrate To The Master Data Service

1. Yaml configurations

   • Update "mongo-db-username", "mongo-db-password" and "mongo-db-authenticated-uri" in secrets db config in respective environment secret yaml file (iFix-DevOps/mgramseva-qa-secrets.yaml at mgramseva · misdwss/iFix-DevOps ).

   • Update "mongo-db-name", "mongo-db-host" and "mongo-db-url" in egov-config of configmaps in respective environment yaml file (iFix-DevOps/mgramseva-qa.yaml at mgramseva · misdwss/iFix-DevOps ).

   • Update "adapter-master-data-service" and "ifix-department-entity-service" in egov-service-host in respective environment yaml file (iFix-DevOps/mgramseva-qa.yaml at mgramseva · misdwss/iFix-DevOps ).

2. Create a new DB in the MongoDB instance for these new services.

3. Next, create the same master data again in the new (mgramseva) database using the adapter-master-data-service's /_create APIs.

4. After restoring DB collections, drop the unused collections from the iFIX MongoDB.

   Follow the steps below to drop the unused collections.

   1. Connect to ifix namespace playground pod

      kubectl exec -it <playground-pod> -n ifix -- /bin/bash

   2. Connect to the particular mongo db mongo --host <hostname>:27017 -u <username> -p <password>

   3. Use db

      use <db_name>

   4. Check the above-mentioned collection name using the below commands

      db.getCollectionNames();

   5. If collections are there then drop them off using the below commands

      e.g.

      db.department.drop();

      db.expenditure.drop();

      db.project.drop();

Steps To Use Adapter Master Data Service

Port-forward the Adapter master data service in localhost from a specific environment (like QA/UAT/Prod).

Below is the command to port-forward :

e.g.

kubectl port-forward <pod-name> 8030:8080 -n mgramseva

Steps To Use iFix Master Data Service

We need the access token from keycloak server and pass it as a bearer token while requesting the ifix-master-data-service create APIs.

Technical Docs

Adapter Master Data Service v1.0

IFIX Core Master Data Service v2.0