This documentation outlines the process for replacing the egov-mdms-service with MDMS V2, which is database-driven and offers enhanced API capabilities for CRUD operations (Create, Read, Update, and Disable). By renaming the context path of MDMS V2 to egov-mdms-service, we ensure that core and other services can seamlessly interact with the new MDMS service without requiring changes.
Key Changes
MDMS V2:
Database-based: Stores master data in a database rather than static files in a GitHub repository.
CRUD APIs: Allows users to dynamically interact with the master data through APIs for adding, updating, and disabling records.
Backward Compatibility: MDMS V2 retains compatibility with MDMS V1 search APIs, allowing services using egov-mdms-service to function without changes.
egov-mdms-service:
File-based: Managed master data as static JSON files stored in a GitHub repository.
Limited Interaction: Primarily served data without allowing user modification through APIs.
Migration Steps
1. Rename MDMS V2 Context Path
Rename the context path of MDMS V2 to egov-mdms-servicein your environment. This ensures that all existing core and dependent services will seamlessly point to the new MDMS V2 without the need for any modifications.
For example, if MDMS V2 is running on /mdms-v2, change it to /egov-mdms-service in the environment configurations.
2. Remove Existing egov-mdms-service
Delete the existing egov-mdms-service setup:
Pods: Remove the running pods related to the old egov-mdms-service.
Service: Delete the service definition.
Ingress: Remove or update the ingress to redirect to the new MDMS V2.
3. Deploy MDMS V2 with Configuration
Deploy or redeploy MDMS V2 with the updated context path (/egov-mdms-service) and database configurations enabled.
Once MDMS V2 is deployed and running, restart the Zuul Gateway (or any API gateway) to ensure that it picks up the new routing mappings to the renamed MDMS service (egov-mdms-service).
5. Restart Dependent Services
Restart all core and dependent services with configuration changes enabled so that they point to the newly deployed MDMS V2. This ensures that the services can now interact with the updated APIs provided by MDMS V2.
Note: Some services, such as ENC service and User service, have direct dependencies on egov-mdms-service and specific data sets. Ensure that necessary data is added to the tenant(s) where this activity is being performed.
Use the below scripts to add default data for the roles and security policy so that user service will get started and we can proceed with adding more data.
-- Create the table if it doesn't already exist
CREATE TABLE IF NOT EXISTS public.eg_mdms_data
(
id VARCHAR(64) NOT NULL,
tenantid VARCHAR(255) NOT NULL,
uniqueidentifier VARCHAR(255) NOT NULL,
schemacode VARCHAR(255) NOT NULL,
data JSONB NOT NULL,
isactive BOOLEAN NOT NULL,
createdby VARCHAR(64),
lastmodifiedby VARCHAR(64),
createdtime BIGINT,
lastmodifiedtime BIGINT,
CONSTRAINT pk_eg_mdms_data PRIMARY KEY (tenantid, schemacode, uniqueidentifier),
CONSTRAINT uk_eg_mdms_data UNIQUE (id)
);
-- Insert data into the table
INSERT INTO public.eg_mdms_data (
id, tenantid, uniqueidentifier, schemacode, data, isactive, createdby, lastmodifiedby, createdtime, lastmodifiedtime
) VALUES
(
'503fc752-4702-4236-jaga-3f9fdc2e664e',
'mz',
'SUPERUSER',
'ACCESSCONTROL-ROLES.roles',
'{"code": "SUPERUSER", "name": "Super User", "description": "Super User. Can change all master data and has access to all the system screens."}',
true,
'0da6b089-265e-44ef-bf7f-9e0d3ef47bf9',
'0da6b089-265e-44ef-bf7f-9e0d3ef47bf9',
1700735390109,
1700735390109
),
(
'503fc752-4702-4236-jaga-3f9fdc2e1234',
'mz',
'EMPLOYEE',
'ACCESSCONTROL-ROLES.roles',
'{"code": "EMPLOYEE", "name": "EMPLOYEE", "description": "EMPLOYEE Can change all master data and has access to all the system screens."}',
true,
'0da6b089-265e-44ef-bf7f-9e0d3ef47bf9',
'0da6b089-265e-44ef-bf7f-9e0d3ef47bf9',
1700735390109,
1700735390109
)
RETURNING tenantid, uniqueidentifier, schemacode;
Data migration is a separate and essential activity that must be handled master by master. The migration process includes:
Schema Creation:
For each master, ensure that the necessary schema is created in the database.
Verify that the structure aligns with the expected format in MDMS V2.
Data Migration:
Migrate data master by master into the corresponding database tables.
Ensure that the migrated data is valid and adheres to the schema.
Refer to this document to learn more about data migration.
I have attached the default MDMS data and schema that were created in UAT. This can be used to load the default MDMS for the HCM Product & Console. It can be imported into any environment, and you can change the tenant from 'mz' by using the 'find and replace' function. After that, delete any unnecessary masters and add new ones according to your use case.
Additional Notes
Backward Compatibility: Since MDMS V2 supports the V1 search APIs, all core and dependent services will continue to function normally without modification.
Database Configuration: Ensure that database replication and backups are in place, especially during the migration, to prevent data loss.
Service Downtime: Depending on your infrastructure, plan for potential service downtime while removing the old egov-mdms-service and deploying MDMS V2.
The migration to MDMS V2 is successfully completed in the Unified UAT environment.
All MDMS data for -
HCM (including HCM Prod and HCM Console)
Sanitation
Core Master Data
is migrated.
Database Dump & Schema Information
A database dump containing all the necessary schemas and data will be provided. This includes:
Core-related master data.
Health and Console-related masters.
You can filter the Core-related data from the dump and update your database accordingly for future environments.
Conclusion
By following this migration guide, you can seamlessly transition from egov-mdms-service to the more dynamic and API-driven MDMS V2. The new system enhances user interaction while maintaining compatibility with existing services, ensuring a smooth integration into the ecosystem.
