• Package: org.egov.works.service

• Source File: NotificationConsumerService.java

• Dependencies: Spring Framework, Kafka, Lombok

Overview

The NotificationConsumerService class is responsible for routing Kafka messages to specific service components based on the topic they belong to within the eGov Works module.

Attributes

1. contractNotificationService: Service for processing contract-related notifications.

2. estimateNotificationService: Service for processing estimate-related notifications.

3. notificationServiceConfiguration: Configuration settings for notification services.

4. expenseNotificationService: Service for processing expense-related notifications.

5. musterRollNotificationService: Service for processing muster roll related notifications.

6. measurementNotificationService: Service for processing measurement related notifications.

7. organizationNotificationService: Service for processing organization related notifications.

8. individualNotificationService: Service for processing individual related notifications.

Methods

• fetchServiceBasedOnTopic(final String record, @Header(KafkaHeaders.RECEIVED_TOPIC) String topic): Determines the appropriate service handler based on the topic of the received message and delegates the message processing to that specific service.

Usage

Instantiate and configure the NotificationConsumer class within the application context to enable message consumption from Kafka topics. Ensure that the NotificationConsumerService class is properly injected into the NotificationConsumer class for seamless message processing.

Overview

The SMS Adapter Service, part of the Mukta_IMPL repository, is a crucial component designed to facilitate SMS notifications. It listens for incoming data on specific Kafka topics and triggers the sending of SMS notifications

Repository Information

• Repository Name: Mukta_IMPL

• Branch: UAT

• Branch: click here for branch link

• Environment: mukta-uat

• Port: 8080

• Context Path: /sms-adapter

Dependencies

• Database(Postgres): digit_works

• Kafka Server

• idGenService

• attendanceService

• workflowService

• mdmsService

• hrmsService

• estimateService

• worksProjectManagementSystemService

• locationService

• contractService

• localizationService

• urlShortnerService

• organisationService

• expenseCalculatorService

• Package: org.egov.works.kafka

• Source File: NotificationConsumer.java

• Dependencies: Spring Framework, Kafka, Lombok

Overview

The NotificationConsumer class is responsible for consuming messages from Kafka topics and forwarding them to the NotificationConsumerService for further processing within the eGov Works module.

Functionality

The primary functionality of the NotificationConsumer class includes:

Consuming Kafka Messages: Messages are consumed from specified Kafka topics using Kafka listeners.

Forwarding Messages: Consumed messages are forwarded to the NotificationConsumerService for processing based on the topic.

Usage

The NotificationConsumer class acts as a bridge between Kafka topics and the NotificationConsumerService, ensuring seamless message consumption and processing within the eGov Works module.

• Package: org.egov.works.service

• Source File: ContractNotificationService.java

• Dependencies: Spring Framework, Kafka, Lombok

Overview

The ContractNotificationService class manages the notification workflow for contract-related actions within the eGov Works module. It processes contract-related Kafka messages and sends appropriate notifications to relevant stakeholders.

Attributes

1. notificationServiceConfiguration: Configuration settings for notification services.

2. restTemplate: Template for making RESTful HTTP requests.

3. producer: Kafka producer for sending notifications.

4. mapper: Object mapper for JSON serialization and deserialization.

5. hrmsUtils: Utility class for HRMS (Human Resource Management System) operations.

6. estimateServiceUtil: Utility class for estimate-related operations.

7. projectServiceUtil: Utility class for project-related operations.

8. locationServiceUtil: Utility class for location-related operations.

9. organisationServiceUtil: Utility class for organization-related operations.

10. repository: Repository for service request operations.

11. localizationUtil: Utility class for localization operations.

12. contractsUtil: Utility class for contract-related operations.

Methods

• process(final String record, @Header(KafkaHeaders.RECEIVED_TOPIC) String topic): Processes the Kafka message for contract-related actions and sends notifications accordingly.

• sendNotification(ContractRequest request): Sends notifications based on the type of contract action.

• pushNotificationForRevisedContract(ContractRequest request): Sends notifications for revised contracts.

• pushNotificationToOriginator(ContractRequest request, String message, String cboMobileNumber): Sends notifications to the originator.

• pushNotificationToCreatorForRejectAction(ContractRequest request): Sends notifications to the creator for reject actions.

• pushNotificationToCreatorForApproveAction(ContractRequest request): Sends notifications to the creator for approve actions.

• pushNotificationToCreatorForDeclineAction(ContractRequest request): Sends notifications to the creator for decline actions.

• pushNotificationToCreatorForAcceptAction(ContractRequest request): Sends notifications to the creator for accept actions.

• pushNotificationToCBOForApproveAction(ContractRequest request): Sends notifications to the(CBO) for approve actions.

• getDetailsForSMS(ContractRequest request, String uuid): Retrieves details required for SMS notifications.

• getProjectNumber(ContractRequest request): Retrieves project details for SMS notifications.

• getOrgDetailsForCBOAdmin(ContractRequest request): Retrieves organization details for CBO administrators.

• getMessage(ContractRequest request, boolean isCBORole): Retrieves the message based on the contract action.

• getMessage(ContractRequest request, String msgCode): Retrieves the message from localization.

• buildMessageForRevisedContract(Map<String, String> userDetailsForSMS, String message, Boolean isSendBack): Builds the message for revised contracts.

• buildMessageForRejectAction(Contract contract, Map<String, String> userDetailsForSMS, String message): Builds the message for reject actions.

• buildMessageForApproveActionWOCBO(Contract contract, Map<String, String> userDetailsForSMS, String message): Builds the message for approve actions by WO creator.

• buildMessageForWOCreator(Contract contract, Map<String, String> userDetailsForSMS, String message): Builds the message for WO creator.

• buildMessageForDeclineAction_WOCreator(Contract contract, Map<String, String> userDetailsForSMS, String message): Builds the message for decline actions by WO creator.

• buildMessageForAcceptAction_WOCreator(Contract contract, Map<String, String> userDetailsForSMS, String message): Builds the message for accept actions by WO creator.

• getLocalisedMessages(RequestInfo requestInfo, String tenantId, String locale, String module): Retrieves localized messages.

• getShortnerURL(String actualURL): Retrieves the shortened URL.

• setAdditionalFields(ContractRequest request, String localizationCode,Map<String, Object> additionalField ): Sets additional fields for notifications.

• checkAdditionalFieldAndPushONSmsTopic(String customizedMessage, Map<String, Object> additionalField,Map<String,String> smsDetails): Checks additional fields and pushes notifications onto the SMS topic.

• Package: org.egov.works.service

• Source File: MeasurementNotificationService.java

Overview

The MeasurementNotificationService class is responsible for processing notifications related to measurements within the eGov Works module. It handles the generation and sending of notifications to relevant personnel based on different actions performed on measurements, such as approval or rejection.

Attributes

1. mapper: ObjectMapper for JSON serialization/deserialization.

2. notificationServiceConfiguration: Configuration settings for notification services.

3. measurementServiceUtil: Utility class for measurement-related operations.

4. producer: Kafka producer for sending notifications.

Methods

• process(final String record, @Header(KafkaHeaders.RECEIVED_TOPIC) String topic): Processes the incoming Kafka message containing measurement details and delegates the notification sending process to the appropriate method.

• sendNotification(MeasurementServiceRequest request): Sends notifications to relevant personnel based on the action performed on the measurement (e.g., approval, rejection).

• setAdditionalFields(MeasurementServiceRequest request, String localizationCode, Map<String, Object> additionalField): Sets additional fields for the notification if required.

• checkAdditionalFieldAndPushONSmsTopic(String customizedMessage, Map<String, Object> additionalField, Map<String, String> smsDetails): Checks if additional fields are present and sends the SMS request accordingly.

• getCustomMessage(String message, String measurementNumber, String projectNumber): Replaces variables in a message template with actual measurement and project numbers.

• getMessage(MeasurementServiceRequest request, String msgCode): Retrieves the localized message for a given code and locale.

Usage

Instantiate and configure the MeasurementNotificationService class within the application context to handle notifications related to measurements. Ensure that dependencies such as ObjectMapper, configuration settings, and utility classes are properly injected.

• Package: org.egov.works.service

• Source File: EstimateNotificationService.java

• Dependencies: Spring Framework, Kafka, Jackson, Lombok, Apache Commons Lang3

Overview

The EstimateNotificationService class is a part of the SMS adapter service in the eGov Works module. This service facilitates the sending of notifications related to estimate workflows via SMS.

Attributes

1. producer: Kafka producer for sending notifications.

2. config: NotificationServiceConfiguration for accessing configuration settings.

3. hrmsUtils: HRMSUtils for fetching employee details.

4. projectServiceUtil: ProjectServiceUtil for fetching project details.

5. locationServiceUtil: LocationServiceUtil for fetching location details.

6. mapper: ObjectMapper for JSON serialization/deserialization.

7. repository: ServiceRequestRepository for fetching data from external services.

8. localizationUtil: LocalizationUtil for fetching localized messages.

Methods

• process(final String record, @Header(KafkaHeaders.RECEIVED_TOPIC) String topic): Processes Kafka messages containing EstimateRequest data.

• sendNotification(EstimateRequest request): Determines the action type and invokes corresponding notification methods.

• pushNotificationToCreatorForRejectAction(EstimateRequest request): Sends a notification for the rejection action in the estimate workflow.

• pushNotificationToCreatorForApproveAction(EstimateRequest request): Sends a notification for the approval action in the estimate workflow.

• getDetailsForSMS(EstimateRequest request, String uuid): Retrieves details necessary for constructing SMS notifications, such as project and user information.

• getMessage(EstimateRequest request): Retrieves the appropriate message template based on the workflow action.

• buildMessageForRejectAction(Estimate estimate, Map<String, String> userDetailsForSMS, String message): Constructs the SMS content for the rejection action.

• buildMessageForApproveActionCreator(Estimate estimate, Map<String, String> userDetailsForSMS, String message): Constructs the SMS content for the approval action by the estimate creator.

• getLocalisedMessages(RequestInfo requestInfo, String rootTenantId, String locale, String module): Retrieves localized messages based on the user's locale and module.

• setAdditionalFields(EstimateRequest request, String localizationCode, Map<String, Object> additionalField): Sets additional fields required for customizing SMS content.

• checkAdditionalFieldAndPushONSmsTopic(String customizedMessage, Map<String, Object> additionalField, Map<String, String> smsDetails): Checks if additional fields are required and pushes the SMS message to the appropriate Kafka topic.

Usage

The EstimateNotificationService class is utilized within the eGov Works module for sending SMS notifications related to estimate workflows. It integrates with Kafka for message processing and supports dynamic message construction based on predefined templates and user-specific data.

• Package: org.egov.works.service

• Source File: MusterRollNotificationService.java

Overview

The MusterRollNotificationService class is responsible for processing notifications related to muster rolls within the eGov Works module. It handles the generation and sending of notifications to CBO (Central Billing Office) personnel based on different actions performed on muster rolls.

Attributes

1. producer: Kafka producer for sending notifications.

2. config: Configuration settings for notification services.

3. hrmsUtils: A utility class for interacting with the HRMS (Human Resource Management System).

4. projectServiceUtil: Utility class for project-related operations.

5. locationServiceUtil: Utility class for location-related operations.

6. mapper: Object mapper for JSON serialization/deserialization.

7. repository: Repository for service requests.

8. notificationUtil: Utility class for notification-related operations.

9. localizationUtil: Utility class for localization operations.

Methods

• process(final String record, @Header(KafkaHeaders.RECEIVED_TOPIC) String topic): Processes the incoming Kafka message containing muster roll details and delegates the notification sending process to the appropriate method.

• sendNotificationToCBO(MusterRollRequest musterRollRequest): Sends notifications to CBO personnel based on the action performed on the muster roll (e.g., send back for correction, approval).

• setAdditionalFields(MusterRollRequest request, String localizationCode,Map<String, Object> additionalField ): Sets additional fields for the notification if required.

• checkAdditionalFieldAndPushONSmsTopic(String customizedMessage , Map<String, Object> additionalField,Map<String,String> smsDetails): Checks if additional fields are present and sends the SMS request accordingly.

• getMessage(MusterRollRequest musterRollRequest, String msgCode): Retrieves the localized message for a given code and locale.

• buildMessageReplaceVariables(String message, String musterRollName, String amount): Replaces variables in a message template with actual values.

Usage

Instantiate and configure the MusterRollNotificationService class within the application context to handle notifications related to muster rolls. Ensure that dependencies such as Kafka producer, configuration settings, and utility classes are properly injected.

• Package: org.egov.works.service

• Source File: ExpenseNotificationService.java

Overview

The ExpenseNotificationService class is responsible for processing notifications related to expenses within the eGov Works module. It handles the generation and sending of notifications for both purchase bills and supervision bills.

Attributes

1. producer: Kafka producer for sending notifications.

2. config: Configuration settings for notification services.

3. hrmsUtils: Utility class for interacting with the HRMS (Human Resource Management System).

4. projectServiceUtil: Utility class for project-related operations.

5. locationServiceUtil: Utility class for location-related operations.

6. mapper: Object mapper for JSON serialization/deserialization.

7. repository: Repository for service requests.

8. notificationUtil: Utility class for notification-related operations.

9. localizationUtil: Utility class for localization operations.

Methods

• process(final String record, @Header(KafkaHeaders.RECEIVED_TOPIC) String topic): Processes the incoming Kafka message, determining whether it pertains to a purchase bill or a supervision bill, and sends the appropriate notification accordingly.

• sendNotificationForPurchaseBill(BillRequest billRequest): Sends notifications for purchase bills, handling approval and rejection actions.

• sendNotificationForSupervisionBill(BillRequest billRequest): Sends notifications for supervision bills.

• getMessage(RequestInfo requestInfo, String tenantId, String msgCode, Map<String,Object> additionalFields): Retrieves the localized message for a given code and locale, optionally adding additional fields if required.

• buildMessageReplaceVariables(String message, String billNumber, String amount): Replaces variables in a message template with actual values.

• setAdditionalFields(RequestInfo requestInfo,String tenantId, String localizationCode, Map<String,Object> additionalFields): Sets additional fields for the notification if required.

• checkAdditionalFieldAndPushONSmsTopic(String customizedMessage, Map<String, Object> additionalFields, String mobileNumber): Checks if additional fields are present and sends the SMS request accordingly.

Usage

Instantiate and configure the ExpenseNotificationService class within the application context to handle notifications related to expenses. Ensure that dependencies such as Kafka producer, configuration settings, and utility classes are properly injected.

• Package: org.egov.works.service

• Source File: OrganizationNotificationService.java

Overview

The OrganizationNotificationService class is responsible for handling notifications related to organization management within the eGov Works module. It facilitates the generation and sending of notifications to relevant parties when organizations are created or updated.

Attributes

1. mapper: ObjectMapper for JSON serialization/deserialization.

2. notificationServiceConfiguration: Configuration settings for notification services.

3. producer: Kafka producer for sending notifications.

4. restTemplate: RestTemplate for making HTTP requests.

5. repository: ServiceRequestRepository for fetching data from external services.

Methods

• process(final String record, @Header(KafkaHeaders.RECEIVED_TOPIC) String topic, boolean isCreateOperation): Processes the incoming Kafka message containing organization details and delegates the notification sending process based on whether it's a create or update operation.

• sendNotification(OrgRequest request, boolean isCreateOperation): Sends notifications for organization creation or update based on the boolean flag.

• pushNotificationForCreate(OrgRequest request): Pushes notifications for organization creation to relevant personnel.

• pushNotificationForUpdate(OrgRequest request): Pushes notifications for organization updates to relevant personnel.

• getOrganisations(OrgSearchRequest orgSearchRequest): Fetches organization details based on search criteria.

• setAdditionalFields(OrgRequest request, String localizationCode, Map<String, Object> additionalField): Sets additional fields for the notification if required.

• checkAdditionalFieldAndPushONSmsTopic(String customizedMessage, Map<String, Object> additionalField, String mobileNumber): Checks if additional fields are present and pushes the SMS notification accordingly.

• getDetailsForSMS(Organisation organisation): Retrieves details necessary for composing the SMS notification for organization creation.

  getShortnerURL(String actualURL): Shortens the provided URL using a URL

• getSMSDetailsForUpdate(OrgRequest request): Retrieves details necessary for composing the SMS notification for organization update.

• getMessage(OrgRequest request, boolean isCreateOperation): Retrieves the localized message for organization creation or update based on the operation type.

• getMessage(OrgRequest request, String msgCode): Retrieves the localized message for the specified code and locale.

• buildMessageForCreateAction(Map<String, String> userDetailsForSMS, String message): Builds the message for organization creation based on the provided user details.

• buildMessageForUpdateAction(Map<String, String> userDetailsForSMS, String message): Builds the message for organization update based on the provided user details.

• getLocalisedMessages(RequestInfo requestInfo, String rootTenantId, String locale, String module): Fetches localized messages from the localization service based on the specified parameters.

• getShortnerURL(String actualURL): Shortens the provided URL using a URL shortening service.

Usage

Instantiate and configure the OrganizationNotificationService class within the application context to handle notifications related to organization management. Ensure that dependencies such as ObjectMapper, configuration settings, Kafka producer, and RestTemplate are properly injected. Additionally, ensure that the ServiceRequestRepository is configured to communicate with external services for fetching data.

• Package: org.egov.works.service

• Source File: IndividualNotificationService.java

Overview

The IndividualNotificationService class is responsible for managing notifications related to individual entities within the eGov Works module. It handles the generation and sending of notifications when individual entities are created or updated.

Attributes

1. config: NotificationServiceConfiguration for accessing configuration settings.

2. producer: Kafka producer for sending notifications.

3. repository: ServiceRequestRepository for fetching data from external services.

4. restTemplate: RestTemplate for making HTTP requests.

5. mapper: ObjectMapper for JSON serialization/deserialization.

Methods

• process(final String record, @Header(KafkaHeaders.RECEIVED_TOPIC) String topic, boolean isCreateOperation): Processes the incoming Kafka message containing individual details and delegates the notification sending process based on whether it's a create or update operation.

• sendNotification(IndividualRequest request, boolean isCreateOperation): Sends notifications for individual creation or update based on the boolean flag.

• pushNotificationForCreate(IndividualRequest request): Pushes notifications for individual creation to relevant parties.

• pushNotificationForUpdate(IndividualRequest request): Pushes notifications for individual update to relevant parties.

• getDetailsForSMS(IndividualRequest request): Retrieves details necessary for composing the SMS notification for individual creation or update.

• getMessageForCreate(IndividualRequest request): Retrieves the localized message for individual creation.

• getMessageForUpdate(IndividualRequest request): Retrieves the localized message for individual update.

• getMessage(IndividualRequest request, String msgCode): Retrieves the localized message for the specified code and locale.

• buildMessageForCreate(Map<String, String> userDetailsForSMS, String message): Builds the message for individual creation based on the provided user details.

• buildMessageForUpdate(Map<String, String> userDetailsForSMS, String message): Builds the message for individual updates based on the provided user details.

• getLocalisedMessages(RequestInfo requestInfo, String rootTenantId, String locale, String module): Fetches localized messages from the localization service based on the specified parameters.

• setAdditionalFields(IndividualRequest request, String localizationCode, Map<String, Object> additionalField): Sets additional fields for the notification if required.

• checkAdditionalFieldAndPushONSmsTopic(String customizedMessage, Map<String, Object> additionalField, Map<String, String> smsDetails): Checks if additional fields are present and push the SMS notification accordingly.

Usage

Instantiate and configure the IndividualNotificationService class within the application context to handle notifications related to individual entities. Ensure that dependencies such as NotificationServiceConfiguration, Kafka producer, ServiceRequestRepository, RestTemplate, and ObjectMapper are properly injected. Additionally, configure the methods to handle individual creation and update notifications as per the application's requirements.

Overview

The expense calculator is an implementation-specific service that works in tandem with the expense service. This service holds all the specific business logic in computing expenses and calls the billing service with the correct payload to create a bill.

There are three types of bills in Mukta:

• Wage bill - auto-generated from an approved muster roll and to be paid to wage seekers on completion of work

• Purchase bill - submitted by a JE or ME on behalf of the vendor

• Supervision bill - computed on top of wage and purchase bills to be paid to the CBO (community-based organisation).

The calculator performs the calculation for all three types of bills and creates a bill.

Dependency

• DIGIT backbone services

• Persister

• MDMS

• IDgen

• Expense

Key Functionalities

• Listens for muster roll approval on a Kafka topic and creates a wage bill based on the muster roll.

• Calculates supervision bill (if required) on any bills that have not been included so far and submits it to expense service

• Allows update of purchase bill.

• Search for meta information related to bills

Code

Deployment

Master Data

• HeadCodes

• ApplicableCharges

• LabourCharges

• BusinessService

• PayerList

Integration

• API spec

• Postman collection

MDMS Changes

Mukta v2.1 UI & API Test Cases

1. UI Test Cases

   • Mobile Employee Login Page & Home Page

   • Mobile Employee Work Order

   • Mobile:Measurement Book

   • Moving Skills dataset into SOR

   • search & add template to detailed estimate

   • CBO-Download Analysis

2. UI & API Test Cases:

   • Estimate Generate, view and download analysis

   • MB Generate, view and download analysis statements

   • Add/Edit, View Rate Analysis

   • Search SOR

   • show rate revision jobs

   • Shedular-Revision of SOR

Mukta v2.1 UI & API Test Cases

Overview

The page provides detailed steps on how to deploy the MUKTASoft services.

Steps: Follow the visual map below and click on the step links to view the details.

Service Builds

Please refer to this link for the service builds used.

Deploy Helm Charts

Helm charts for all MUKTASoft services are available here. To override the environment variables, please create a Helm environment chart like this for your DIGIT environment and customise the values.

Configure Master Data Management Service (MDMS)

1. Create Common Masters

   • Create IdFormat.json that will be used by egov-id-gen service.

   • Create StateInfo.json which will configure eligible languages for the tenant

2. Create tenants by following this doc.

3. Create sample boundary data. Refer to this document for more details

4. Create configs for -

   • Access Control services

   • Role mapping

   • Role-Action mappings

5. Configure map-config for the tenant

6. Restart the MDMS server and restart the Zuul API gateway.

Deploy DIGIT Core Services

Refer to the section for a list of core services to be deployed.

Deploy DIGIT Works Services

Refer to the section for a list of Works platform services to be deployed.

Deploy MUKTASoft Services

Refer to the section for a list of MUKTASoft services to be deployed.

Configure MUKTASoft

Find below the breakdown of the steps:

• Step 1: Create a persister config for each backend service. The persister service will use these configurations.

• Step 2: Create an indexer config for each backend service. The indexer service will use these configurations.

• Step 3: Create workflow configuration for the defined business services.

Create Users

Create users following this document.

Upsert Localisation

Upsert localisation following this document.

Release Summary

The MUKTASoft 2.1 release offers multiple new features and enhancements including rate analysis, estimate templates, Kibana dashboard and mobile application.

Release Highlights

• Rate Analysis - determines the cost of a Schedule of Rates (SOR), a unit of work, and is published by the Public Works Department (PWD).

• Estimate Template - a set of SORs required to prepare an estimate for a specific type of work, allowing for easy reuse when preparing estimates for similar projects.

• Analysis Statements - break down the estimated costs of all Schedule of Rates (SORs) into labour, material, and machinery - for better planning, budgeting, and resource allocation.

• Utilization Statements – break down work costs from the measurement book for all Schedule of Rates (SORs) into labour, materials, and machinery, to validate wages, supervision, and purchase payments.

• Mobile Application (Measurement Book) - mobile version of the measurement book, designed to help users capture measurements directly from the site and submit them for verification and approval.

• Kibana Dashboard - developed with additional KPIs to help stakeholders track and monitor the progress of the MUKTA scheme.

• The MUKTA CBO App has been enhanced with an employee login facility and renamed as the MUKTASoft App.

• All the skills (MDMS v1) have been migrated into the Schedule of Rates registry (MDMS v2) as labor SORs.

New Features/Enhancements

Kibana Dashboard

Bug Fixes

None

Known Issues

Below are the known issues including Bug-bashes, ULB feedback and ULB-reports.

Upcoming Release Features

1. Data Security and Privacy (New Feature)

2. Work review and Project Closure (New Feature)

3. Bulk Purchase: Vendor Invoicing and Payments (Without a purchase order) (New Feature)

4. JIT Integration: Fund Allocation and Utilization Register (New Feature)

5. Allow addition of wage seekers after muster roll submission. (Enhancements)

6. Implement wage seekers search Criteria in the CBO App. (Enhancements)

7. Carry forward differential amounts of MB in muster roll. (Enhancements)

8. Reflect revised estimate costs accurately in view work orders details. (Enhancements)

9. Add CBO search option by various criteria during work order creation by PC MUKTA. (Enhancements)

10. Dashboard: Remaining KPIs, incorporating drill-down and filerts. (Enhancements)

11. Project types to be modified, moving from MDMS v1 to v2 (Change Request)

Related Docs & Links

This section provides the detailed specifications, deployment and configuration details for MuktaSoft services.

Click on the service links below for details.

• Revise Rates Job

Rates Migration to SOR

To convert Labour Skills rates to SOR rates in MDMS-v2, we need to map skill_codes to sorId. We'll use skill_codes to get rates from MDMS v1 and sorId to upload them into MDMS v2. Upload an Excel file in the required format and execute the curl command. Note: The migration script is already present in our earlier build; only the input file will be changed.

Migration Steps

To migrate skills rate follow the steps given below:

1. Create skill_codes and sorId mapping :

   • An Excel sheet is with fields (heads, rates as total, Sor Id, Valid From, and Valid To). Example:

     LC.7

     MHA.3

     ADC.4

     CA.9

     EMF.6

     DMF.5

     MA.2

     LA.1

     RA.8

     Total

     Sor Id

     Valid From

     Valid To

2. Use the Specific Build:

   • egovio/bulk-upload:UAT-f91e96b8-18

   • to access the branch and change details

3. Build and Deploy:

   • Deploy the build provided above or build and deploy from the code linked above if custom changes are required.

   • Upload the Excel file in the body.

   • Use the curl below to migrate the data.

1. Verification in DB: Query on the eg_mdms_data table and check if the Rates uploaded are present in the data. Example: select * from eg_mdms_data where schemacode ='WORKS-SOR.Rates' and data- >>'sorId' = 'Eg.SOR_000002';

Upload SOR Composition

Works SOR requires SOR Composition, for existing SORs it requires uploading data using script.

Migration Steps

2. Checkout to the branch sor-composition-migration

4. Port-forward MDMS-v2

5. Update these details in .env

   1. MDMS_V2_HOST url

   2. MDMS_v2_SOR_COMPOSITION_CREATE url if it's changed - Make sure that WORKS-SOR.Composition schema is created

6. Install dependencies on your local pip3 install -f requirements.txt

7. Run main.py file

Overview

Integration with Odisha IFMS (Integrated Financial Management System) is via the Just-in-Time (JIT) APIs provided by the Odisha treasury.

Components

Master Data

The following pieces of information are shared offline:

• clientId

• clientSecret

• publicKey from JIT systems

• Head of accounts to be used for the Mukta scheme at the state level - to be provided by HUDD

• Spending unit details specific to each ULB are to be provided by HUDD.

Sequence Diagram

Success Flow

API Specifications

DB Diagram

IFMS Adapter Description

Dependent Services

• expense service

• expense-calculator service

• bank-account service

• individual service

• organisation service

• audit-log service

• IDGen service

• MDMS service

• encryption service

Key Functionality

Funds Summary

1. IFMS adapter manages funds summary based on the head of accounts and SSU codes. It creates sanctions for each head of accounts and SSU details based on ULB tenant ID.

2. There are three types of transactions that can be received from the JIT VA API -

   • Initial Allotment - A new sanction will be created only if AllotmentTxnType is Initial Allotment.

   • Additional allotment - For this type of transaction it will update the amount of existing sanction.

   • Allotment withdrawal - It deducts the transaction amount from the sanction for this type of transaction.

Payment Instructions

• When a bill is approved this service creates payment using the expense service.

• There are consumers who keep listening to the payment create Kafka topic and generate payment instructions (PI) using payment and bill details and post the PI to the IFMS system using JIT API.

• A new PI will be generated when enough funds are available for any head of accounts for that tenantId.

• Before posting the PI there were multiple enrichments like bankaccount details, org and individual details, etc.

• After creating the PI it deducts the available balance from the funds summary.

• If a PI is created for any payment then the user can not generate a PI again till the PI fails.

• It keeps a log of each status call of PI and saves it in the DB

JIT Connection Flow

IFMS adapter connects JIT with two APIs -

• authentication - webservices/jitfs/v1.0/authenticate

• service request - webservices/jitfs/v1.0/get-jit-service-data

Cronjobs

There are multiple cronjobs for the IFMS adapter, all jobs are built using a single codebase with multiple charts, these charts are required to configure cronjobs with multiple configurations.

All cronjobs uses ifms/scheduler?serviceId={SERVICE_ID} API, the business logic is defined for each service code.

Service codes are -

Indexes

All requests and responses are logged in an encrypted fashion in two indexes in ES.

• ifms-request-logs

• ifms-error-logs

Request logs

Each request that is sent to JIT will be logged in the ifms-request-logs index. The index name is configurable in application.properties, Helm chart and environment file. There are multiple fields for the request:

• id - uuid of the request

• serviceId - Contains service ID of jit request like VA, PI, PIS etc

• jitBillNo - Contains bill number for which it’s calling the JIT API, it’s applicable for PI, PIS, PAG, PD, FTPS, and FTFPS. Note: For Auth request jitBillNo will be AUTH

• encRequest - Contains request body which is encrypted using ifms.request.enc.secret value. You can decrypt this using the same secret.

• decryptionRek - Contains decryption rek which helps to decrypt the JIT response received from JIT.

• encResponse - Response received from JIT.

• createdtime - The time when the request was sent to the JIT system

Error logs

When the user sends any request to JIT and gets an error response, then it will store the details in ifms-error-logs index. It has multiple fields

• serviceId - Contains service ID of jit request like VA, PI, PIS etc

• requestId - This is uuid of ifms-request-logs index

• statusCode - Status code of Network response

• jitEncRequest - Encrypted request which is sent to the JIT, we can not decrypt this request.

• errorMsg - Error response which was received from JIT

• encryptionRek - Encryption rek using which request is encrypted

• decryptionRek - Contains decryption rek which helps to decrypt the JIT response

• authToken - Auth token which request was sent to the JIT

• sekString - sek which was received from the login

• createdtime - The time when the request was sent to the JIT system

Overview

This bill scheduler is a cronjob scheduler for calculating the supervision bill. It runs based on environment configuration. It triggers multiple APIs to generate the supervision bill.

Dependency

• MDMS

• User

• Contract

• Expense Calculator

Key Functionalities

• It creates supervision bills based on ACTIVE contracts using expense-calculate service /v1/_calculate API.

Code

Bill Scheduler

Configuration

• Create a role in ACCESSCONTROL-ROLES/roles.json MDMS like this.

• Create a SYSTEM user with BILL_CREATOR and SYSTEM roles. Find the curl below.

• The same username will be used to generate bills BILL_GEN_CRONJOB, it’s defined in the environment config.

• Cron job duration will be configured using environment variables from here.

curl --location 'http://localhost:8082/user/users/_createnovalidate' \
--header 'Content-Type: application/json' \
--data-raw '{
    "RequestInfo": {
        "api_id": "1",
        "ver": "1",
        "ts": null,
        "action": "create",
        "did": "",
        "key": "",
        "msg_id": "",
        "requester_id": "",
        "userInfo": {
            "userName": "BillCreator",
            "name": "BillCreator",
            "gender": "male",
            "mobileNumber": "9999999999",
            "active": true,
            "type": "EMPLOYEE",
            "tenantId": "{STATE_TANENT_ID}",
            "password": "eGov@123",
            "roles": [
                {
                    "code": "SUPERUSER",
                    "tenantId": "{STATE_TANENT_ID}"
                }
            ]
        }
    },
    "User": {
        "userName": "BILL_GEN_CRONJOB",
        "name": "Bill Generator",
        "gender": "male",
        "mobileNumber": "0000000000",
        "active": true,
        "type": "SYSTEM",
        "tenantId": "{STATE_TANENT_ID}",
        "password": "eGov@123",
        "roles": [
            {
                "code": "SYSTEM",
                "tenantId": "{STATE_TANENT_ID}"
            },
            {
                "code": "BILL_CREATOR",
                "name": "BILL_CREATOR",
                "tenantId": "{STATE_TANENT_ID}"
            }
        ]
    }
}'

Deployment

Helm Charts

Update Scheduler

There are two ways to update the configuration of the scheduler:

1. Add the config in the DevOps environment file, and restart the service. This will trigger the scheduler based on the updated environment configuration and restart the expense-cronjob service.

expense-cronjob:
  cron:
    schedule: "*/1 * * * *"
    suspend: "false"

1. Use the commands given below: Change schedule - kubectl patch cronjobs expense-cronjob -p '{"spec" : {"schedule": "*/10 * * * *" }}'

   Pause cron job - kubectl patch cronjobs expense-cronjob -p '{"spec" : {"suspend" : true }}' Resume cron job - kubectl patch cronjobs expense-cronjob -p '{"spec" : {"suspend" : false}}' Create a new cronjob scheduler - kubectl create job --from=cronjob/expense-cronjob expense-cronjob

Objective:

To implement a secure bank account search service in Mukta that masks Personally Identifiable Information (PII) in the response based on the user’s role and predefined security policies. PII data - Branch name, Account number, IFSC

The response would be based on the config set in MDMS-V2 which masks the above fields in appropriate patterns.

Key Components

1. Masking Methodology

• Masking is applied to sensitive attributes such as accountHolderName, accountNumber, and ifscCode.

• A regular expression-based masking technique is used, replacing parts of the sensitive values with asterisks (*).

• Example: For a pattern - (?=.{4}), the value 12345678 would be masked as ****5678.

2. Security Policy:

• Role-Based Access Control (RBAC):

  • Defines which roles can access attributes in plain text.

  • Example roles: BILL_ACCOUNTANT, MUKTA_ADMIN.

• Attribute Visibility Levels:

  • PLAIN: The attribute is fully visible.

  • MASKED: Attribute is partially masked.

Policy Configuration Example:

{
  "model": "BankAccountSearch",
  "attributes": [
    {
      "name": "accountHolderName",
      "jsonPath": "accountHolderName",
      "patternId": "001",
      "defaultVisibility": "MASKED"
    },
    {
      "name": "accountNumber",
      "jsonPath": "accountNumber",
      "patternId": "001",
      "defaultVisibility": "MASKED"
    },
    {
      "name": "ifscCode",
      "jsonPath": "bankBranchIdentifier/code",
      "patternId": "009",
      "defaultVisibility": "MASKED"
    }
  ],
  "roleBasedDecryptionPolicy": [
    {
      "roles": ["BILL_ACCOUNTANT", "MUKTA_ADMIN"],
      "attributeAccessList": [
        {
          "attribute": "accountHolderName",
          "firstLevelVisibility": "PLAIN",
          "secondLevelVisibility": "PLAIN"
        },
        {
          "attribute": "accountNumber",
          "firstLevelVisibility": "PLAIN",
          "secondLevelVisibility": "PLAIN"
        },
        {
          "attribute": "ifscCode",
          "firstLevelVisibility": "PLAIN",
          "secondLevelVisibility": "PLAIN"
        }
      ]
    }
  ]
}

3. Masking Pattern Configuration:

• Patterns define how sensitive attributes are masked.

Example configuration:

[
  {
    "patternId": "001",
    "pattern": ".(?=.{4})"
  },
  {
    "patternId": "009",
    "pattern": "(?<=.{4}).(?=.{2})"
  }]

Pattern Example:

• Pattern.(?=.{4}): Masks all characters except the last 4.

• Pattern (?<=.{4}).(?=.{2}): Masks characters except the first 4 and last 2.

4. Implementation Details:

• The service retrieves security policies and masking patterns from MDMS.

• User roles are validated to determine access levels for each attribute.

• Masking is applied dynamically to sensitive data if the user’s role lacks plain text access.

5. Code Highlights:

• Role Access Check: Ensures attributes are visible in plain text only if the user’s role has access.

• Masking Application: Masks attribute values using patterns fetched from the configuration.

• Nested JSON Handling: Retrieves and updates attribute values dynamically using JSON paths

Curl:

curl 'https://mukta-uat.digit.org/mukta-services/bankaccount/v1/_search?_=1734091757871' \
  -H 'authority: mukta-uat.digit.org' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
  -H 'content-type: application/json' \
  -H 'cookie: _gid=GA1.2.1202491491.1734070501; _ga_V2CPZCVTXQ=GS1.1.1734070500.1.0.1734070502.0.0.0; _ga=GA1.1.829748430.1733136966; _ga_H9YC8FEN6F=GS1.1.1734069891.2.1.1734072381.60.0.0; _ga_3LN58ZJ5KN=GS1.1.1734072575.3.1.1734072581.54.0.0; _ga_4FTREDCS0G=GS1.1.1734072575.3.1.1734072581.0.0.0; _ga_FS7DJ7SGKL=GS1.1.1734072575.3.1.1734072581.0.0.0; _ga_EHCDQF6VQ5=GS1.1.1734072575.3.1.1734072581.0.0.0' \
  -H 'origin: https://mukta-uat.digit.org' \
  -H 'referer: https://mukta-uat.digit.org/works-ui/employee/masters/view-wageseeker?tenantId=od.testing&individualId=IND-2024-12-06-004156' \
  -H 'sec-ch-ua: "Chromium";v="118", "Google Chrome";v="118", "Not=A?Brand";v="99"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Linux"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36' \
  --data-raw '{"bankAccountDetails":{"tenantId":"od.testing","serviceCode":"IND","referenceId":["7e302cf3-6eb4-4392-89e7-42ab75b13672"]},"RequestInfo":{"apiId":"Rainmaker","authToken":"fdaaf53d-b05d-4659-aa86-45f0ae305f40","userInfo":{"id":271,"uuid":"81b1ce2d-262d-4632-b2a3-3e8227769a11","userName":"MUKTAUAT","name":"MUKTAUAT","mobileNumber":"9036146615","emailId":"a@gmail.com","locale":null,"type":"EMPLOYEE","roles":[{"name":"Organization viewer","code":"ORG_VIEWER","tenantId":"od.testing"},{"name":"MB_VERIFIER","code":"MB_VERIFIER","tenantId":"od.testing"},{"name":"MB_VIEWER","code":"MB_VIEWER","tenantId":"od.testing"},{"name":"MDMS Admin","code":"MDMS_ADMIN","tenantId":"od.testing"},{"name":"MUKTA Admin","code":"MUKTA_ADMIN","tenantId":"od.testing"},{"name":"BILL_ACCOUNTANT","code":"BILL_ACCOUNTANT","tenantId":"od.testing"},{"name":"WORK_ORDER_VIEWER","code":"WORK_ORDER_VIEWER","tenantId":"od.testing"},{"name":"ESTIMATE VERIFIER","code":"ESTIMATE_VERIFIER","tenantId":"od.testing"},{"name":"ESTIMATE VIEWER","code":"ESTIMATE_VIEWER","tenantId":"od.testing"},{"name":"WORK ORDER APPROVER","code":"WORK_ORDER_APPROVER","tenantId":"od.testing"},{"name":"OFFICER IN CHARGE","code":"OFFICER_IN_CHARGE","tenantId":"od.testing"},{"name":"BILL_VIEWER","code":"BILL_VIEWER","tenantId":"od.testing"},{"name":"PROJECT VIEWER","code":"PROJECT_VIEWER","tenantId":"od.testing"},{"name":"BILL_APPROVER","code":"BILL_APPROVER","tenantId":"od.testing"},{"name":"MB_CREATOR","code":"MB_CREATOR","tenantId":"od.testing"},{"name":"MUSTER ROLL VERIFIER","code":"MUSTER_ROLL_VERIFIER","tenantId":"od.testing"},{"name":"ESTIMATE APPROVER","code":"ESTIMATE_APPROVER","tenantId":"od.testing"},{"name":"WORK ORDER CREATOR","code":"WORK_ORDER_CREATOR","tenantId":"od.testing"},{"name":"ESTIMATE CREATOR","code":"ESTIMATE_CREATOR","tenantId":"od.testing"},{"name":"Employee Common","code":"EMPLOYEE_COMMON","tenantId":"od.testing"},{"name":"MDMS STATE VIEW ADMIN","code":"MDMS_STATE_VIEW_ADMIN","tenantId":"od.testing"},{"name":"Localisation admin","code":"LOC_ADMIN","tenantId":"od.testing"},{"name":"TECHNICAL SANCTIONER","code":"TECHNICAL_SANCTIONER","tenantId":"od.testing"},{"name":"Dashboard Viewer","code":"DASHBOARD_VIEWER","tenantId":"od.testing"},{"name":"BILL_CREATOR","code":"BILL_CREATOR","tenantId":"od.testing"},{"name":"Revision of rates","code":"REVISION_OF_RATES","tenantId":"od.testing"},{"name":"BILL_VERIFIER","code":"BILL_VERIFIER","tenantId":"od.testing"},{"name":"MUSTER ROLL APPROVER","code":"MUSTER_ROLL_APPROVER","tenantId":"od.testing"},{"name":"MB_APPROVER","code":"MB_APPROVER","tenantId":"od.testing"},{"name":"MDMS CITY ADMIN","code":"MDMS_CITY_ADMIN","tenantId":"od.testing"},{"name":"PROJECT CREATOR","code":"PROJECT_CREATOR","tenantId":"od.testing"},{"name":"Employee Organization Admin","code":"EMP_ORG_ADMIN","tenantId":"od.testing"},{"name":"WORK ORDER VERIFIER","code":"WORK_ORDER_VERIFIER","tenantId":"od.testing"},{"name":"HRMS Admin","code":"HRMS_ADMIN","tenantId":"od.testing"}],"active":true,"tenantId":"od.testing","permanentCity":"Testing"},"msgId":"1734091757871|en_IN","plainAccessRequest":{}}}' \
 --compressed

Objective

The Mukta Individual Search service is designed to retrieve and handle individual-related data securely. The service masks personally identifiable information (PII) based on configurable patterns and enforces role-based access control to ensure sensitive data is visible only to authorized users.

PII data - Name, Identity number, Father/ husband name, Relationship, Address, Date of birth, Gender, Mobile Number, Social category, Email ID, Photo.

The response would be based on the config set in MDMS-V2 which masks the above fields in appropriate patterns.

Masking Methodology

1. Masking Patterns:

   1. Configured in the DataSecurity module.

   2. Patterns define the masking logic for attributes, e.g.,

      1. 001: .\*(?=.{4}) masks all but the last 4 characters.

      2. 009: (?<=.{4}).(?=.{2}) masks characters except the first 4 and last 2.

2. Role-Based Security Policies:

   1. Defined in the MaskingUIConfig module.

   2. Specifies the visibility of attributes based on user roles.

   3. Attributes can have PLAIN or MASKED visibility.

3. Implementation:

   1. Attributes are extracted from the response using JSON paths.

   2. If a user's role does not permit plain text access, the attribute is masked based on the configured pattern.

Security Policy Example

{
  "model": "IndividualSearch",
  "attributes": [
    { "name": "fullName", "jsonPath": "fullName", "patternId": "001", "defaultVisibility": "MASKED" },
    { "name": "phoneNumber", "jsonPath": "contact/phone", "patternId": "001", "defaultVisibility": "MASKED" },
    { "name": "address", "jsonPath": "address", "patternId": "009", "defaultVisibility": "MASKED" }
  ],
  "roleBasedDecryptionPolicy": [
    {
      "roles": ["ADMIN", "SUPERVISOR"],
      "attributeAccessList": [
        { "attribute": "fullName", "firstLevelVisibility": "PLAIN", "secondLevelVisibility": "PLAIN" },
        { "attribute": "phoneNumber", "firstLevelVisibility": "PLAIN", "secondLevelVisibility": "PLAIN" },
        { "attribute": "address", "firstLevelVisibility": "PLAIN", "secondLevelVisibility": "PLAIN" }
      ]
    }
  ]
}

Curl:

curl 'https://mukta-uat.digit.org/mukta-services/individual/v1/_search?tenantId=od.testing&offset=0&limit=100&_=1734091757683' \
  -H 'authority: mukta-uat.digit.org' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
  -H 'content-type: application/json' \
  -H 'cookie: _gid=GA1.2.1202491491.1734070501; _ga_V2CPZCVTXQ=GS1.1.1734070500.1.0.1734070502.0.0.0; _ga=GA1.1.829748430.1733136966; _ga_H9YC8FEN6F=GS1.1.1734069891.2.1.1734072381.60.0.0; _ga_3LN58ZJ5KN=GS1.1.1734072575.3.1.1734072581.54.0.0; _ga_4FTREDCS0G=GS1.1.1734072575.3.1.1734072581.0.0.0; _ga_FS7DJ7SGKL=GS1.1.1734072575.3.1.1734072581.0.0.0; _ga_EHCDQF6VQ5=GS1.1.1734072575.3.1.1734072581.0.0.0' \
  -H 'origin: https://mukta-uat.digit.org' \
  -H 'referer: https://mukta-uat.digit.org/works-ui/employee/masters/view-wageseeker?tenantId=od.testing&individualId=IND-2024-12-06-004156' \
  -H 'sec-ch-ua: "Chromium";v="118", "Google Chrome";v="118", "Not=A?Brand";v="99"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Linux"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36' \
  --data-raw '{"Individual":{"individualId":["IND-2024-12-06-004156"]},"RequestInfo":{"apiId":"Rainmaker","authToken":"fdaaf53d-b05d-4659-aa86-45f0ae305f40","userInfo":{"id":271,"uuid":"81b1ce2d-262d-4632-b2a3-3e8227769a11","userName":"MUKTAUAT","name":"MUKTAUAT","mobileNumber":"9036146615","emailId":"a@gmail.com","locale":null,"type":"EMPLOYEE","roles":[{"name":"Organization viewer","code":"ORG_VIEWER","tenantId":"od.testing"},{"name":"MB_VERIFIER","code":"MB_VERIFIER","tenantId":"od.testing"},{"name":"MB_VIEWER","code":"MB_VIEWER","tenantId":"od.testing"},{"name":"MDMS Admin","code":"MDMS_ADMIN","tenantId":"od.testing"},{"name":"MUKTA Admin","code":"MUKTA_ADMIN","tenantId":"od.testing"},{"name":"BILL_ACCOUNTANT","code":"BILL_ACCOUNTANT","tenantId":"od.testing"},{"name":"WORK_ORDER_VIEWER","code":"WORK_ORDER_VIEWER","tenantId":"od.testing"},{"name":"ESTIMATE VERIFIER","code":"ESTIMATE_VERIFIER","tenantId":"od.testing"},{"name":"ESTIMATE VIEWER","code":"ESTIMATE_VIEWER","tenantId":"od.testing"},{"name":"WORK ORDER APPROVER","code":"WORK_ORDER_APPROVER","tenantId":"od.testing"},{"name":"OFFICER IN CHARGE","code":"OFFICER_IN_CHARGE","tenantId":"od.testing"},{"name":"BILL_VIEWER","code":"BILL_VIEWER","tenantId":"od.testing"},{"name":"PROJECT VIEWER","code":"PROJECT_VIEWER","tenantId":"od.testing"},{"name":"BILL_APPROVER","code":"BILL_APPROVER","tenantId":"od.testing"},{"name":"MB_CREATOR","code":"MB_CREATOR","tenantId":"od.testing"},{"name":"MUSTER ROLL VERIFIER","code":"MUSTER_ROLL_VERIFIER","tenantId":"od.testing"},{"name":"ESTIMATE APPROVER","code":"ESTIMATE_APPROVER","tenantId":"od.testing"},{"name":"WORK ORDER CREATOR","code":"WORK_ORDER_CREATOR","tenantId":"od.testing"},{"name":"ESTIMATE CREATOR","code":"ESTIMATE_CREATOR","tenantId":"od.testing"},{"name":"Employee Common","code":"EMPLOYEE_COMMON","tenantId":"od.testing"},{"name":"MDMS STATE VIEW ADMIN","code":"MDMS_STATE_VIEW_ADMIN","tenantId":"od.testing"},{"name":"Localisation admin","code":"LOC_ADMIN","tenantId":"od.testing"},{"name":"TECHNICAL SANCTIONER","code":"TECHNICAL_SANCTIONER","tenantId":"od.testing"},{"name":"Dashboard Viewer","code":"DASHBOARD_VIEWER","tenantId":"od.testing"},{"name":"BILL_CREATOR","code":"BILL_CREATOR","tenantId":"od.testing"},{"name":"Revision of rates","code":"REVISION_OF_RATES","tenantId":"od.testing"},{"name":"BILL_VERIFIER","code":"BILL_VERIFIER","tenantId":"od.testing"},{"name":"MUSTER ROLL APPROVER","code":"MUSTER_ROLL_APPROVER","tenantId":"od.testing"},{"name":"MB_APPROVER","code":"MB_APPROVER","tenantId":"od.testing"},{"name":"MDMS CITY ADMIN","code":"MDMS_CITY_ADMIN","tenantId":"od.testing"},{"name":"PROJECT CREATOR","code":"PROJECT_CREATOR","tenantId":"od.testing"},{"name":"Employee Organization Admin","code":"EMP_ORG_ADMIN","tenantId":"od.testing"},{"name":"WORK ORDER VERIFIER","code":"WORK_ORDER_VERIFIER","tenantId":"od.testing"},{"name":"HRMS Admin","code":"HRMS_ADMIN","tenantId":"od.testing"}],"active":true,"tenantId":"od.testing","permanentCity":"Testing"},"msgId":"1734091757683|en_IN","plainAccessRequest":{}}}' \
  --compressed

Objective

The Mukta Organisation Search service is designed to provide secure and efficient access to organisation data. It incorporates configurable masking patterns and role-based policies to safeguard sensitive information while maintaining accessibility for authorized users.

PII data - Door No, Street Name, Locality, Mobile Number, Email ID, PAN, GSTIN.

The response would be based on the config set in MDMS-V2 which masks the above fields in appropriate patterns.

Features

1. Role-Based Attribute Access:

   1. Ensures that only authorized roles can access sensitive organisation attributes in plain text.

   2. Configurable access levels for each role.

2. Configurable Masking Patterns:

   1. Provides flexibility to define masking patterns for each attribute.

   2. Masks sensitive information to ensure data security.

3. Dynamic Masking Configurations:

   1. Uses MDMS (Master Data Management System) for dynamic retrieval of masking configurations.

Input Request Example

{
  "RequestInfo": {
    "userInfo": {
      "roles": [
        { "code": "USER_ROLE" }
      ]
    }
  },
  "SearchCriteria": {
    "tenantId": "tenant123",
    "organisationId": "org123"
  }
}

Output Response Example

• For a user without plain text access:

{
  "organisations": [
    {
      "name": "O*** L***",
      "registrationNumber": "***789",
      "address": "1*** S**** St****",
      "geoLocation": {
        "boundaryCode": "CS_COMMON_UNDISCLOSED",
        "isWardMasked": true
      }
    }
  ],
  "TotalCount": 1
}

• For a user with plain text access:

{
  "organisations": [
    {
      "name": "Org Legal",
      "registrationNumber": "123789",
      "address": "123 Sample Street",
      "geoLocation": {
        "boundaryCode": "12345",
        "isWardMasked": false
      }
    }
  ],
  "TotalCount": 1
}

Key Components

1. MDMS Configuration Fetching:

   1. Retrieves masking patterns and role-based policies dynamically from MDMS.

2. Role-Based Masking Logic:

   1. Determines access levels for each role.

   2. Applies appropriate masking patterns to sensitive attributes.

3. Dynamic Masking of Attributes:

   1. Masks attributes such as name, registration number, and address based on user roles and configurations.

   2. Handles complex paths within objects (e.g., geoLocation.boundaryCode).

Example Workflow

1. User Request:

   1. The user sends a search request with RequestInfo and SearchCriteria.

2. Configuration Fetching:

   1. Service fetches masking patterns and role-based policies from MDMS.

3. Attribute Masking:

   1. Attributes are masked/unmasked based on user roles and configurations.

4. Response Generation:

   1. Returns the masked/unmasked organisation data to the user.

Curl:

curl 'https://mukta-uat.digit.org/mukta-services/org-services/organisation/v1/_search' \
  -H 'authority: mukta-uat.digit.org' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
  -H 'content-type: application/json' \
  -H 'cookie: _gid=GA1.2.1202491491.1734070501; _ga_V2CPZCVTXQ=GS1.1.1734070500.1.0.1734070502.0.0.0; _ga=GA1.1.829748430.1733136966; _ga_H9YC8FEN6F=GS1.1.1734069891.2.1.1734072381.60.0.0; _ga_3LN58ZJ5KN=GS1.1.1734072575.3.1.1734072581.54.0.0; _ga_4FTREDCS0G=GS1.1.1734072575.3.1.1734072581.0.0.0; _ga_FS7DJ7SGKL=GS1.1.1734072575.3.1.1734072581.0.0.0; _ga_EHCDQF6VQ5=GS1.1.1734072575.3.1.1734072581.0.0.0' \
  -H 'origin: https://mukta-uat.digit.org' \
  -H 'referer: https://mukta-uat.digit.org/works-ui/employee/masters/view-organization?tenantId=od.testing&orgId=ORG-001629' \
  -H 'sec-ch-ua: "Chromium";v="118", "Google Chrome";v="118", "Not=A?Brand";v="99"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Linux"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36' \
  --data-raw '{"SearchCriteria":{"orgNumber":"ORG-001629","tenantId":"od.testing"},"RequestInfo":{"apiId":"Rainmaker","authToken":"fdaaf53d-b05d-4659-aa86-45f0ae305f40","userInfo":{"id":271,"uuid":"81b1ce2d-262d-4632-b2a3-3e8227769a11","userName":"MUKTAUAT","name":"MUKTAUAT","mobileNumber":"9036146615","emailId":"a@gmail.com","locale":null,"type":"EMPLOYEE","roles":[{"name":"Organization viewer","code":"ORG_VIEWER","tenantId":"od.testing"},{"name":"MB_VERIFIER","code":"MB_VERIFIER","tenantId":"od.testing"},{"name":"MB_VIEWER","code":"MB_VIEWER","tenantId":"od.testing"},{"name":"MDMS Admin","code":"MDMS_ADMIN","tenantId":"od.testing"},{"name":"MUKTA Admin","code":"MUKTA_ADMIN","tenantId":"od.testing"},{"name":"BILL_ACCOUNTANT","code":"BILL_ACCOUNTANT","tenantId":"od.testing"},{"name":"WORK_ORDER_VIEWER","code":"WORK_ORDER_VIEWER","tenantId":"od.testing"},{"name":"ESTIMATE VERIFIER","code":"ESTIMATE_VERIFIER","tenantId":"od.testing"},{"name":"ESTIMATE VIEWER","code":"ESTIMATE_VIEWER","tenantId":"od.testing"},{"name":"WORK ORDER APPROVER","code":"WORK_ORDER_APPROVER","tenantId":"od.testing"},{"name":"OFFICER IN CHARGE","code":"OFFICER_IN_CHARGE","tenantId":"od.testing"},{"name":"BILL_VIEWER","code":"BILL_VIEWER","tenantId":"od.testing"},{"name":"PROJECT VIEWER","code":"PROJECT_VIEWER","tenantId":"od.testing"},{"name":"BILL_APPROVER","code":"BILL_APPROVER","tenantId":"od.testing"},{"name":"MB_CREATOR","code":"MB_CREATOR","tenantId":"od.testing"},{"name":"MUSTER ROLL VERIFIER","code":"MUSTER_ROLL_VERIFIER","tenantId":"od.testing"},{"name":"ESTIMATE APPROVER","code":"ESTIMATE_APPROVER","tenantId":"od.testing"},{"name":"WORK ORDER CREATOR","code":"WORK_ORDER_CREATOR","tenantId":"od.testing"},{"name":"ESTIMATE CREATOR","code":"ESTIMATE_CREATOR","tenantId":"od.testing"},{"name":"Employee Common","code":"EMPLOYEE_COMMON","tenantId":"od.testing"},{"name":"MDMS STATE VIEW ADMIN","code":"MDMS_STATE_VIEW_ADMIN","tenantId":"od.testing"},{"name":"Localisation admin","code":"LOC_ADMIN","tenantId":"od.testing"},{"name":"TECHNICAL SANCTIONER","code":"TECHNICAL_SANCTIONER","tenantId":"od.testing"},{"name":"Dashboard Viewer","code":"DASHBOARD_VIEWER","tenantId":"od.testing"},{"name":"BILL_CREATOR","code":"BILL_CREATOR","tenantId":"od.testing"},{"name":"Revision of rates","code":"REVISION_OF_RATES","tenantId":"od.testing"},{"name":"BILL_VERIFIER","code":"BILL_VERIFIER","tenantId":"od.testing"},{"name":"MUSTER ROLL APPROVER","code":"MUSTER_ROLL_APPROVER","tenantId":"od.testing"},{"name":"MB_APPROVER","code":"MB_APPROVER","tenantId":"od.testing"},{"name":"MDMS CITY ADMIN","code":"MDMS_CITY_ADMIN","tenantId":"od.testing"},{"name":"PROJECT CREATOR","code":"PROJECT_CREATOR","tenantId":"od.testing"},{"name":"Employee Organization Admin","code":"EMP_ORG_ADMIN","tenantId":"od.testing"},{"name":"WORK ORDER VERIFIER","code":"WORK_ORDER_VERIFIER","tenantId":"od.testing"},{"name":"HRMS Admin","code":"HRMS_ADMIN","tenantId":"od.testing"}],"active":true,"tenantId":"od.testing","permanentCity":"Testing"},"msgId":"1734091873033|en_IN","plainAccessRequest":{}}}' \
  --compressed

Overview

Works-PDF is an intermediary service that bridges the gap between the pdf-service and client requests. Within works-pdf, there are several APIs available for producing various PDFs. This service gathers data from multiple sources, amalgamates it, and then forwards the request to the PDF service for PDF generation.

Further, Works PDF can produce an Excel file when a payment is initiated. It actively listens to the "expense-payment-create" topic, capturing relevant payment data to trigger this process.

Dependency

• MDMS

• PDF

• Project

• Estimates

• Muster Roll

• Contract

• Organization

• Localization

• Expense

• Expense calculator

• Bank account

• Filestore

Key Functionalities

• The system retrieves data from various sources to create multiple PDFs such as estimates, muster reports, and project documents.

• When a payment is generated, it produces Excel files corresponding to the payment bills. This is triggered by a payment creation event communicated through a topic.

• Users also have the option to recreate the Excel files for a specific payment using the same payment ID. This functionality allows for the regeneration of payment-related Excel documents.

Code

Works-PDF

Deployment

• Helm Chart

• Environment

  • Add all pdf configurations under pdf-service data config and format config

  • Add file type 'application/zip' under xlsx format in egov-filestore allowed-file-formats-map.

PDF Configuration

• Estimates PDF - Data Config, Format Config

• Muster Roll PDF - Data Config, Format Config

• Project PDF - Data Config, Format Config

• Work order PDF - Data Config, Format Config

Role Action

Create Account For Deductions

Create accounts for purchase and wage bills, for head codes where the category is deduction.

Example: Below is the head code object:

{
      "id": "5",
      "code": "LC",
      "category": "deduction",
      "service": "works.purchase",
      "description": "Labour Cess",
      "active": true,
      "effectiveFrom": 1682164954037,
      "effectiveTo": null
}

Where tenantId is pg.citya

The format of referenceId is Deduction_{tanentId}_{headcode}

Then create a bank account with the field referenceId value Deduction_pg.citya_LC

Overview

MUKTA Services is an intermediary service that bridges the gap between the API and client requests. It helps Clients/UI gather all the required information from different services.

Dependency

• MDMS

• MDMS V2

• Estimates

• Muster Roll

• Contract

• Measurement

• Bank Accounts

• Individual

• Organisation

Code

Mukta-services

Deployment

• Helm Chart

Role Action

Measurement Create

Flow Diagram

Measurement Create Criteria

This service handles all the measurement creation criteria and helps the UI consolidate all information. The measurement period is calculated in the mukta-services based on the same criteria.

 {
        "reference": "CONTRACT", //this criteria is for the measurement created using contract
        "period": 7, // default measurement period 
        "contractStatus":"ACTIVE", // measurement can be created if the referenced contract is in the following status
        "measurementWorkflowStatus": "APPROVED", // measurement can be created if previously created measurement in this status
        "enableMeasurementAfterContractEndDate":false, // measurement can be created even if the contract has expired
        "active": true
      }

Measurement Response

The measurement response would be based on the config https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/pg/works/MeasurementBFFConfig.json which transforms the final consolidated object of Estimate, Contract, measurement, and Muster roll into the user-requested object.

{
            "path": "contract",   // reponse objects path
            "jsonPath": "$.contract"  // path from the consolidated object
        },

Data Masking Controller

This service masks the search response before displaying it in the UI. This middleware eliminates the need to make major changes in the backend. The masking is done based on the user roles for sensitive PII data.

Flow Diagram

Three APIs have been defined under the data privacy controller as follows:

• BankAccountSearch: Unmasking Role - VIEW_DED_UNMASKED

• IndividualSearch: Unmasking Role - VIEW_WS_UNMASKED

• OrganisatonSearch: Unmasking Role - VIEW_ORG_UNMAKSED

Objective

This section is designed with the objective of helping implementation parties and end-users collect the required master data through minimal interaction and iterations and ensure the quality, consistency and shape of data needed to configure the system.

Audience

This page is intended to help stakeholders as given below on data gathering activities.

1. State Team

2. eGov Onsite Team/ Implementation Team

3. ULB Team (Nodal and DEO)

4. Implementation Partners

Output Artefacts

The artefacts of this document are the data template of a configurable entity, a page with content defining the entity template and helping on how to fill the template with required data.

Data Entry

1. Download the data template attached to this page.

2. Find the meaning of the different headers in the Data Definition section on this page

3. Make sure all the headers, data type, field size and definition/ description are clear. In case of any doubt, please reach out to the person who has shared this document with you to discuss the same and clear out the doubts.

4. Identify the different types of user roles on the basis of ULB functions.

5. Start filling the data starting from serial no. and complete a record at once. Repeat this exercise until the entire data is filled into a template.

6. Verify the data once again by going through the checklist and taking care of each and every point mentioned in the checklist.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities specific to the entity.

Overview

The service generates rate analysis for SOR (Schedule of Rates) compositions using four APIs:

1. Job Management:

   • Create Job API: Creates a new job.

   • Search Job API: Searches for existing jobs.

2. Rate Analysis:

   • Generate Rate Analysis API: Generates rate analysis.

   • Create Rate Analysis API: Saves the rate analysis.

To save the rate analysis per unit, the scheduler/create API is triggered. This internally calls the Create API and computes the rates generated with the help of the Calculate API.

This streamlined process ensures accurate rate analysis for SOR compositions.

Dependency

• DIGIT backbone services

• Persister

• MDMSV2

• IDgen

Sequence Diagram

API Specifications

https://raw.githubusercontent.com/egovernments/DIGIT-Specs/works-v2/Domain%20Services/Works/Rate-Analysis-v1.0.0.yaml

DB Diagram

Description

The Rate Analysis Save API internally calls the existing MDMSv2 API to save the rates, eliminating the need for a new database design. The Rate Analysis Create API generates the rate analysis in real-time.

The client should call the Scheduler Create API to save the generated rate analysis. This API creates a job that includes a list of SORs requiring rate revisions (even a single SOR is passed as a list).

Overview

The statements service is used to generate and save the statement. The business logic for both types of statements differs based on the request. Hence, there are 4 APIs (2- Create and 2- Search).

MUKTASoft provides two types of statements: Analysis Statements and Utilization Statements.

Analysis Statement

• Purpose: Generated for estimates already created and present in the system.

• Accessibility: Employees can view the Analysis Statement from the estimate view screen.

• Linkage: The statement is linked to the specific estimate for which it is generated.

Utilization Statement

• Purpose: Generated for measurement books already created and present in the system.

• Accessibility: Employees can view the Utilization Statement from the measurement view screen.

• Linkage: The statement is linked to the specific measurement for which it is generated.

Dependency

• DIGIT backbone services

• Persister

• MDMSV2

• IDgen

• Rate Analysis

• Estimate

• Measurement Book

• Contract

Sequence Diagram

API Specifications

https://raw.githubusercontent.com/egovernments/DIGIT-Specs/works-v2/Domain%20Services/Works/Statement-v1.0.0.yaml

DB Diagram

Introduction

Project types are the category of works which are included and executed under the scheme MUKTA.

Data Table

Data Definition

Attachments

Overview

Dashboard reindexing is a way to refresh and update both wage bill and muster roll indices once the "gender" field is added to the additional details of an individual. The following sections explain how to do this.

Reindex Elastic Search Indices - Steps

1. In Elasticsearch, back up the original index and create a new migrate index.

2. Define a new migrate topic in the indexer and link it to the migrate index.

3. Ensure you have Python3 installed on your local system.

4. Start a Kafka client and set up port forwarding for Elasticsearch, pointing Kafka bootstrap servers to the Elasticsearch port (usually localhost:9200).

5. Launch an indexer service using indexer files.

6. Retrieve data from services via API, either in bulk or individual search.

7. Formulate an insert request for the indexer, whether for bulk or single data.

8. Send the insert request to the migrate topic.

9. Verify the data in the migrate index.

10. Delete the original index, create a new one, and transfer data from the migrate index to the new original index.

These steps help you update and manage Elasticsearch indices effectively.

Services To Reindex

• expense-bill-index

• muster-inbox

Reindexing Scripts

Introduction

MUKTA is known as a scheme and it is configured in the system along with its HOAs.

Data Table

Data Definition

Attachments

Introduction

In MUKA community-based organizations have different roles to play based on the work value. The role defined is Implementation Agengency and Implementation Partner.

Data Table

Data Definition