Moving MDMS to Sunbird-RC

Overview

The responsibility of MDMS services is to serve master data to all the services which require, but the issue is we can not update the MDMS data using API, requires check-in files to Git Hub and restarting the service.

Another issue is for simple CRUD operations we are creating a registry every time.

Sunbird RC

Sunbird RC provides a registry, which generates REST APIs for the schemas that are created dynamically. It has other services also

Setting up sunbird RC

There are two ways to run Sunbird RC.

Install the registry provided by Sunbird RC, if you want to use other services also, and change the docker-compose.yml file according to your requirement. check the installation guide.
Set up core-service only on your system and run them.

Prerequisites

git
Java 8
maven
PostgreSQL
Elasticsearch (If you want to use it for searching)

Steps to setup registry

Clone the sunbird-rc-core repository
git clone https://github.com/sunbird-rc/sunbird-rc-core.git
Move to the sunbird-rc-core directory and run
sh configure-dependencies.sh
Move to the java directory of the repository and run ./mvnw clean install -DskipTests. It will create a JAR file in the sunbird-rc-core/java/registry/target directory.
Open the registry on an editor and run the application.

Use case

MDMS manages master data for all other services. There is a growing requirement to provide CRUD APIs to manage this to master data (A must for developing a sandbox environment). MDMS data doesn’t have business validation except for generic data type validations like sting, integer etc.

Schema

Sunbird-RC uses standard JSON-LD based schema.

Supported types

string
integer
number
boolean
array
object,
enum

Indexing

"indexFields": [ "field" ]

Unique field

"uniqueIndexFields": [ "field" ]

For more details, please go to this link.

Example schema

The simple structure which has only a single level of attributes

File name AccessoriesCategory.json

{
    "$schema": "http://json-schema.org/draft-07/schema",
    "type": "object",
    "properties": {
        "AccessoriesCategory": {
            "$ref": "#/definitions/AccessoriesCategory"
        }
    },
    "required": [
        "AccessoriesCategory"
    ],
    "title": "AccessoriesCategory",
    "definitions": {
        "AccessoriesCategory": {
            "$id": "#/properties/AccessoriesCategory",
            "type": "object",
            "title": "AccessoriesCategoryschema",
            "required": [
                "tenantId",
                "moduleName",
                "code",
                "active"
            ],
            "uniqueIndexFields": [
                "code"
            ],
            "properties": {
                "tenantId": {
                    "$id": "#/properties/tenantId",
                    "type": "string",
                    "minLength": 2,
                    "maxLength": 8
                },
                "moduleName": {
                    "$id": "#/properties/moduleName",
                    "type": "string",
                    "minLength": 5
                },
                "code": {
                    "$id": "#/properties/code",
                    "type": "string"
                },
                "uom": {
                    "$id": "#/properties/uom",
                    "type": "string"
                },
                "active": {
                    "$id": "#/properties/active",
                    "type": "boolean"
                }
            }
        }
    }
}

Multi-level attributes structure

API’s

For each data config file, it creates the following set of APIs

GET /api/docs/AccessoriesCategory.json returns the AccessoriesCategory schema.
POST /api/v1/AccessoriesCategory/invite helps you to create a new AccessoriesCategory.
GET /api/v1/AccessoriesCategory/{entityId} returns AccessoriesCategory details by id.
PUT /api/v1/AccessoriesCategory/{entityId} Update given AccessoriesCategory details by id.
POST /api/v1/AccessoriesCategory/search returns the search result based on the given query.
GET /api/v1/AccessoriesCategory/{entityId}/{property}/{propertyId} - returns the value of the child when using an object or array of objects.
PUT /api/v1/AccessoriesCategory/{entityId}/{property}/{propertyId}
POST /api/v1/AccessoriesCategory/{entityId}/{property}
POST /api/v1/AccessoriesCategory/{entityId}/{property}/{propertyId}/send
GET /api/v1/AccessoriesCategory/sign returns signed token if you are using Keycloak service.

Pros

Don’t need to create registries if you have a simple CRUD operation on tables.
Creating a schema is very easy, it’s similar to a swagger contract.

Cons

Don’t have control over tables, because it creates tables dynamically.
Can not migrate the data, because it creates a complex table structure when you are trying to create multi-level data.